The new release includes both Mail->News gatewaying and News->Mail gatewaying. The latter uses a polling strategy. If you have direct access to your nntp server, it would be possible not to have to poll. In fact, it would be fairly easy. Unfortunately, I don't have that sort of access available. If anyone is interested in getting non-polling gatewaying working, please contact me, I'm interested in writing the necessary code, I just need someone who can test it, etc.
John
I've downloaded the distribution and tried running configure. Here's the error messages.
bash$ ./configure creating cache ./config.cache checking for --with-python... checking for python... /usr/local/bin/python checking Python interpreter... /usr/local/bin/python checking for a BSD compatible install... /usr/bin/install -c checking whether make sets ${MAKE}... yes checking for --without-gcc... no checking for gcc... no checking for cc... /usr/bin/cc checking whether the C compiler (/usr/bin/cc ) works... yes checking whether the C compiler (/usr/bin/cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether #! works in shell scripts... yes checking for --with-mail-gid... other mail daemon checking for mail_wrapper GID... ./configure: python: not found cat: conftest.out: No such file or directory configure: error:
***** Group other mail daemon not found! You must first ***** set up the other mail daemon entry in /etc/group ***** or set the MAIL_GID shell variable on the ***** configure command line
I don't understand this comment.
My system administrator has set up the directory structure as follows:
bash$ cd /home/
bash$ ls -ldg mailman
lrwxrwxrwx 1 root wheel 13 Jun 3 18:51 mailman -> /bolt/mailman
bash$
The web server is running on bolt so the /bold/mailman directory is visible on that system. The mail server runs on sparky and sparky uses some Solaris automouter magic to make /home/mailman appear as a directory, but /bolt/mailman doesn't appear.
I'll ask if I can get the /home/mailman directory to be changed to ownership by mailman and put in group mailman. For now it is owned by root and in group wheel.
On Wed, Jun 03, 1998 at 07:01:17PM -0400, Michael McLay wrote:
checking for --with-mail-gid... other mail daemon checking for mail_wrapper GID... ./configure: python: not found cat: conftest.out: No such file or directory configure: error:
***** Group other mail daemon not found! You must first ***** set up the other mail daemon entry in /etc/group ***** or set the MAIL_GID shell variable on the ***** configure command line
Well, it looks like Python isn't in your path when installing, and it needs to be. The configure script is trying to run Python to guess which group your SMTPD runs under, but can't run Python, and thus can't come up with a guess.
John
"JV" == John Viega <viega@list.org> writes:
JV> Well, it looks like Python isn't in your path when installing,
JV> and it needs to be. The configure script is trying to run
JV> Python to guess which group your SMTPD runs under, but can't
JV> run Python, and thus can't come up with a guess.
John's right. The problem is that the configure script looks on your $PATH for python (which it didn't find), but defaults to /usr/local/bin/python (which it did find). If configure never found a python binary, it would have exited earlier.
The problem is that other tests in the configure script assume python is on your path, and in your case it isn't. This is exactly the kind of bug I was hoping would get fleshed out by this beta, so... thanks Mike! :-)
Try this patch. It changes the tests so that it uses the python binary it found in the earlier test.
-Barry
P.S. The error message isn't very good, so I'll change that, but not for this patch.
-------------------- snip snip -------------------- Index: configure
RCS file: /projects/cvsroot/mailman/configure,v retrieving revision 1.9 diff -C2 -r1.9 configure *** configure 1998/06/03 22:25:49 1.9 --- configure 1998/06/04 14:39:13
*** 1,5 **** #! /bin/sh
! # From configure.in Revision: 1.9
# Guess values for system-dependent variables and create Makefiles. --- 1,5 ---- #! /bin/sh
! # From configure.in Revision: 1.10
# Guess values for system-dependent variables and create Makefiles.
*** 1005,1009 ****
fp.close()
EOF
! python conftest.py
MAIL_GID=cat conftest.out
fi
--- 1005,1009 ----
fp.close()
EOF
! $PYTHON conftest.py
MAIL_GID=cat conftest.out
fi
*** 1061,1065 ****
fp.close()
EOF
! python conftest.py
CGI_GID=cat conftest.out
fi
--- 1061,1065 ----
fp.close()
EOF
! $PYTHON conftest.py
CGI_GID=cat conftest.out
fi
*** 1110,1114 **** fp.close() EOF ! python conftest.py
echo $ac_n "checking for default fully qualified host name""... $ac_c" 1>&6 --- 1110,1114 ---- fp.close() EOF ! $PYTHON conftest.py
echo $ac_n "checking for default fully qualified host name""... $ac_c" 1>&6
Barry A. Warsaw writes:
"JV" == John Viega <viega@list.org> writes:
JV> Well, it looks like Python isn't in your path when installing, JV> and it needs to be. The configure script is trying to run JV> Python to guess which group your SMTPD runs under, but can't JV> run Python, and thus can't come up with a guess.
John's right. The problem is that the configure script looks on your $PATH for python (which it didn't find), but defaults to /usr/local/bin/python (which it did find). If configure never found a python binary, it would have exited earlier.
The problem is that other tests in the configure script assume python is on your path, and in your case it isn't. This is exactly the kind of bug I was hoping would get fleshed out by this beta, so... thanks Mike! :-)
Try this patch. It changes the tests so that it uses the python binary it found in the earlier test.
Hmm, I fixed the problem so python is found so I didn't exercise this patch.
There's one small buglet in the code generated by configure. The script which generates the crontab.in file adds blank lines to the file. This bombs the crontab command on the old SunOS system we are using.
There is also a link error when building the source code on SunOS using gcc version 2.7.2. Here's the snippet that shows the error.
make[1]: Entering directory /usr/local/mailman/mailman-1.0b4/src' gcc -c -I. -DPREFIX="\"/usr/local/mailman\"" -DPYTHON="\"/usr/local/bin/python\"" -g -O2 -DHAVE_SYSLOG_H=1 -DGETGROUPS_T=int -DHAVE_VPRINTF=1 common.c gcc -DSCRIPT="\"admin\"" -I. -DCGI_GID=55 -g -O2 -DHAVE_SYSLOG_H=1 -DGETGROUPS_T=int -DHAVE_VPRINTF=1 common.o -o admin cgi-wrapper.c collect2: ld returned 2 exit status ld: Undefined symbol _strerror make[1]: *** [admin] Error 1 make[1]: Leaving directory
/usr/local/mailman/mailman-1.0b4/src'
make[1]: Entering directory /usr/local/mailman/mailman-1.0b4/templates' for f in archives.html handle_opts.html listinfo.html options.html roster.html subscribe.html; \ do \ /bin/install -c -m 644 $f /usr/local/mailman/templates; \ done make[1]: Leaving directory
/usr/local/mailman/mailman-1.0b4/templates'
"MM" == Michael McLay <mclay@nist.gov> writes:
MM> There's one small buglet in the code generated by configure.
MM> The script which generates the crontab.in file adds blank
MM> lines to the file. This bombs the crontab command on the old
MM> SunOS system we are using.
It doesn't seem to add blank lines for me, although the crontab.in.in file already contains a blank line, in the middle of the file. Is that the problem? If so, it's trivial to fix (but I want to be sure that's your problem first).
-Barry
On Thu, Jun 04, 1998 at 04:43:01PM -0400, Michael McLay wrote:
There is also a link error when building the source code on SunOS using gcc version 2.7.2. Here's the snippet that shows the error.
Okay, it took me a while to find a machine to use sunning sunOS 4 and gcc 2.7.2 :)
ld: Undefined symbol _strerror
Yes, apparently strerror() is nowhere to be found on such a system. I have 2 functions that I just wrote up. The first duplicates the behavior that strerror gives on other systems. The second saves the large static buffer, and will do for our purposes. Just drop your pick into common.c, and it should then compile:
Version 1 (Compatible):
#define STACK_BUFSIZE 8192
extern char *sys_errlist[];
char* strerror(int errno) { static char msg[STACK_BUFSIZE];
strcpy(msg, sys_errlist[errno]); return msg; }
Version 2 (Efficient):
extern char *sys_errlist[];
char* strerror(int errno) { return sys_errlist[errno]; }
Um, whoops, s/STACK/STATIC throughout that snipit of code, I don't know where my mind is today.
#define STACK_BUFSIZE 8192
Anyway, Here's what I recommend we use in the dist, if and only if strerror can't be found by the autoconf process:
extern char *sys_errlist[]; extern int sys_nerr;
char* strerror(int errno) { if(errno < 0 || errno >= sys_nerr) { return "unknown error"; } else { return sys_errlist[errno]; } }
I tried changing the compiler form gcc to gcc and reran make install. This time stdarg.h isn't found.
make[1]: Entering directory /usr/local/mailman/mailman-1.0b4/src' cc -c -I. -DPREFIX="\"/usr/local/mailman\"" -DPYTHON="\"/usr/local/bin/python\"" -O -DHAVE_SYSLOG_H=1 -DGETGROUPS_T=int -DHAVE_VPRINTF=1 common.c ./common.h: 22: Can't find include file stdarg.h make[1]: *** [common.o] Error 2 make[1]: Leaving directory
/usr/local/mailman/mailman-1.0b4/src'
make[1]: Entering directory /usr/local/mailman/mailman-1.0b4/templates' for f in archives.html handle_opts.html listinfo.html options.html roster.html subscribe.html; \ do \ /bin/install -c -m 644 $f /usr/local/mailman/templates; \ done make[1]: Leaving directory
/usr/local/mailman/mailman-1.0b4/templates'
"MM" == Michael McLay <mclay@nist.gov> writes:
MM> I tried changing the compiler form gcc to gcc and reran make
--------------------------------------------------^^^ you meant to say "to the bundled SunOS cc"?
If so, note that that's a non-ANSI compiler and so old that I can't imagine we'd want to support it.
The gcc 2.7.2 bug is valid though. I *think* I've got an old gcc laying around I can try.
-Barry
Barry A. Warsaw writes:
"MM" == Michael McLay <mclay@nist.gov> writes:
MM> I tried changing the compiler form gcc to gcc and reran make
--------------------------------------------------^^^ you meant to say "to the bundled SunOS cc"?
Opps, yes I did mean cc.
If so, note that that's a non-ANSI compiler and so old that I can't imagine we'd want to support it.
Fine with me. I think we need to get rid of this old hardware anyway and if you refuse to support K&R then it actually helps my case.
The gcc 2.7.2 bug is valid though. I *think* I've got an old gcc laying around I can try.
Yea, I know this is out of date too. It probably isn't even installed properly. Time to fire off a message to our system administrator.
In the mean time... I need a fix to get this working with what I have.
"MM" == Michael McLay <mclay@nist.gov> writes:
MM> Fine with me. I think we need to get rid of this old hardware
MM> anyway and if you refuse to support K&R then it actually helps
MM> my case.
Okay, then I refuse! :-)
>> The gcc 2.7.2 bug is valid though. I *think* I've got an old
>> gcc laying around I can try.
MM> Yea, I know this is out of date too. It probably isn't even
MM> installed properly. Time to fire off a message to our system
MM> administrator.
MM> In the mean time... I need a fix to get this working with
MM> what I have.
Looks like I don't have an old gcc anymore. If I can pull down 2.7.*.* from an ftp site then I'll give that a whirl. Stay tuned.
If anybody else has an older version of gcc and can work up a patch in the meantime, that would be greatly appreciated!
-Barry
participants (3)
-
Barry A. Warsaw
-
John Viega
-
Michael McLay