Hello Stephen,
Stephen Gran schrieb:
> I have supplied /path/to/sendmail to configure, as it's known on Debian
> systems. I have also patched clamav-milter.c so that if sendmail's
> version is undefined previously, it will be defined as the version
> currently in Debian.
But I think it's not okay to *assume* sendmail (or something that should
behave like sendmail) is installed, if you do not provide a build-depend
on it (whatever 'it' means).
>>The attached patch takes the version of the package libmilter-dev as the
>>version of sendmail. Since libmilter-dev is in clamav's build-deps this
>>should provide a more reliable way of detecting the sendmail version -
>>even if it's an ugly hack too. :)
>
>
>>+dpkg -s libmilter-dev | sed -n '/^Version:/s/-[^-]*$//p'
Well, that's the content of the additional script which should be called
to simulate sendmail more *reliable*. It outputs for instance
Version: 8.13.4
which is okay as long as the configure script grabbs the second word in
the first line of output, as it does currently:
configure.in:
174: sendmailver=`$sendmailprog -d0 < /dev/null | head -1 | \
awk '{print $2}'`
175:
176: if test -n "$sendmailver"; then
177: sendmailver_a=`echo $sendmailver | awk -F. '{printf $1}'`
178: sendmailver_b=`echo $sendmailver | awk -F. '{printf $2}'`
179: sendmailver_c=`echo $sendmailver | awk -F. '{printf $3}'`
180:
181: AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, \
[major version of Sendmail])
182: AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, \
[minor version of Sendmail])
183: AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, \
[subversion of Sendmail])
184: fi
> [EMAIL PROTECTED]:~/Debian/clamav/0.87/clamav-0.87$ ./configure --help | grep
> sendmail
> --with-sendmail=PATH specify location of Sendmail binary (default=auto
> find)
>
> So that patch won't work - it will give configure a path to the binary
> 8.13.5-1, which I'm having trouble imaging exists on most systems :)
No, trats wrong. My patch gives configure the path to my additional
script debian/libmilter-version.sh as sendmail binary. Then configure is
calling this script in order to detect the sendmail version. I tested
it, it works. And since libmilter-dev is built from the same source like
sendmail it should always provide the correct version string. :)
> Let me look at what went wrong ...
As I said above: The configure script grabbs the second word of the
first line of the output given by the specified sendmail binary.
But nullmailer, which is installed in my sid-chroot, behaves different
from sendmail in giving no propper version string (okay, this might be a
nullmailer-bug too...). It just ignores the unknown options and tries to
send mail. But since there are no recipients given it outputs:
No recipients were listed
resulting in the sendmail version string 'recipients' (I found it in the
config.log) which is not null but also not parsable later on. Thus
building the package fails with nullmailer.
> I don't see it. In my local tree, the patch to supply a sendmail
> version is there. Checking the buildd logs, I see that none of the
> build daemons had this problem.
Probably because they didn't install nullmailer but a real mailer. Yes,
from this point of view, you're right: there is no error. But I thought
Debian tries hardly to aim for quality software, and my patch might
improve the source package as it will enhance it to build even on
systems having nullmailer installed as mailer.
> Does the build actually fail for you, or do you just see configure
> generate a warning?
Yes, it fails with the same error as reported in the original bug report.
Yours
Micha
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
