Bug#398004: #398004 lynx-cur: Bad default for system mailer
On Tue, 28 Aug 2007 06:18:57 -0400 (EDT), Thomas Dickey wrote: It doesn't _overwrite_ userdefs.h, but many of the definitions in userdefs.h are ignored in favor of the definitions generated (by the configure script) in lynx_cfg.h Sorry my English is not precise, and yes, what I intended to say is exactly what you wrote. configure script) in lynx_cfg.h -- it's relatively simple to see in userdefs.h where this is done via #ifndef HAVE_CONFIG_H ifdef's. Thanks I get it now. I suspect installing a MTA is simpler than fiddling with userdefs.h or so. Regards, 2007-8-29(Wed) -- Debian Developer Debian JP Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398004: #398004 lynx-cur: Bad default for system mailer
Hi Sébastien, On Mon, 27 Aug 2007 21:18:30 +0200, Sébastien Hinderer wrote: However: I am not sure that adding exim4-daemon-light to the build deps is the right way to solve the problem. Yes, very suspicious. I first tried to use userdefs.h but failed to fix the problem. It seems configure overwrites userdefs.h but there might be an option for configure not to search SYSTEM_MAIL etc. (Hmm, I forgot to update changelog.Deian, I'll fix it in the next upload.) I didn't think it was the best way but I wanted to fix this bug rapidly for non-i386 architecture which should be built by buildd. This indeed enforces the use of exim4 as MTA, where as things will, I guess, also work with any other MTA. Therefore, I'd suggest to replace exim4-daemonq-light by the virtual package mail-transport-agent in the build dependencies. I doubt that to put exim4 in Build-Depends (not Depends) enforces the use of exim4 as MTA. Am I missing something? Anyway I'll try more good solution (including your suggestion) later. Thanks for your comments. Regards,2007-8-28(Tue) -- Debian Developer Debian JP Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima
Bug#398004: #398004 lynx-cur: Bad default for system mailer
On Tue, 28 Aug 2007, Atsuhito Kohda wrote: Hi Sébastien, On Mon, 27 Aug 2007 21:18:30 +0200, Sébastien Hinderer wrote: However: I am not sure that adding exim4-daemon-light to the build deps is the right way to solve the problem. Yes, very suspicious. I first tried to use userdefs.h but failed to fix the problem. It seems configure overwrites userdefs.h but there might be an option for configure not It doesn't _overwrite_ userdefs.h, but many of the definitions in userdefs.h are ignored in favor of the definitions generated (by the configure script) in lynx_cfg.h -- it's relatively simple to see in userdefs.h where this is done via #ifndef HAVE_CONFIG_H ifdef's. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Bug#398004: #398004 lynx-cur: Bad default for system mailer
Hi Atsuhito, Thanks for having replied so quickly. I didn't think it was the best way but I wanted to fix this bug rapidly for non-i386 architecture which should be built by buildd. Thanks for that. This indeed enforces the use of exim4 as MTA, where as things will, I guess, also work with any other MTA. Therefore, I'd suggest to replace exim4-daemonq-light by the virtual package mail-transport-agent in the build dependencies. I doubt that to put exim4 in Build-Depends (not Depends) enforces the use of exim4 as MTA. Am I missing something? I ment at compile-time, sorry. Anyway I'll try more good solution (including your suggestion) later. Thanks for your comments. Thanks, Sébastien.
Bug#398004: #398004 lynx-cur: Bad default for system mailer
Hello everybody, I changed a packaging since 2.8.7dev5-1 to build with pbuilder but this means the package was built under the smallest basic system, i.e. without sendmail, bzip2 etc. so configure failed to find sendmail, so you was encountered this bug. I'll fix this and the same kind of bug, #439070 as soon as possible. Please wait for a while. Thanks for the bugfix. However: I am not sure that adding exim4-daemon-light to the build deps is the right way to solve the problem. This indeed enforces the use of exim4 as MTA, where as things will, I guess, also work with any other MTA. Therefore, I'd suggest to replace exim4-daemonq-light by the virtual package mail-transport-agent in the build dependencies. Cheers, Sébastien.
Bug#398004: #398004 lynx-cur: Bad default for system mailer
Hi all, On Tue, 17 Jul 2007 06:24:38 -0400 (EDT), Thomas Dickey wrote: For example, on one of my shell accounts, following View the file lynx.cfg. to See also * compile time options shows (just searching for mail): system_mail_flags '-t -oi' and SYSTEM_MAIL /usr/sbin/sendmail SYSTEM_MAIL_FLAGS -t -oi SYSTEM_MAIL /usr/sbin/sendmail First, sorry but I overlooked the original (or first) bug mail. I'm almost sure that Sébastien's bug was caused by my mistake. I changed a packaging since 2.8.7dev5-1 to build with pbuilder but this means the package was built under the smallest basic system, i.e. without sendmail, bzip2 etc. so configure failed to find sendmail, so you was encountered this bug. I'll fix this and the same kind of bug, #439070 as soon as possible. Please wait for a while. # the original report was not irrelevant with this. Thanks for your report and comments. Regards,2007-8-24(Fri) -- Debian Developer Debian JP Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima
Bug#398004: #398004 lynx-cur: Bad default for system mailer
On Tue, 17 Jul 2007, Sébastien Hinderer wrote: Hi, Thomas Dickey : I don't see where the problem lies: the configure script finds the same value as the one you want to uncomment. The compiled-in value (which you can inspect by looking at LYNXCOMPILEOPTS:/) shows this string. I noticed the very same problem on my system, and uncommenting the lines SYSTEM_MAIL:/usr/mmdf/bin/submit SYSTEM_MAIL_FLAGS:-mlruxto,cc\* in /etc/lynx-cur/lynx.cfg solved the problem: lynx restarted to behave in the way it always did. None of my configs require uncommenting the value, since it's been working as designed for a long time. May be the pre-compiled value is overriden at some point ? possibly. Values that are set via the configs can be traced (see the -trace and -trace-mask options) at runtime. The compiled-in values generally do not show up there, but (assuming that's not disabled), you can inspect the values following the link at the bottom of the options menu. For example, on one of my shell accounts, following View the file lynx.cfg. to See also * compile time options shows (just searching for mail): system_mail_flags '-t -oi' and SYSTEM_MAIL /usr/sbin/sendmail SYSTEM_MAIL_FLAGS -t -oi SYSTEM_MAIL /usr/sbin/sendmail -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Bug#398004: #398004 lynx-cur: Bad default for system mailer
Hi, Thomas Dickey : I don't see where the problem lies: the configure script finds the same value as the one you want to uncomment. The compiled-in value (which you can inspect by looking at LYNXCOMPILEOPTS:/) shows this string. I noticed the very same problem on my system, and uncommenting the lines SYSTEM_MAIL:/usr/mmdf/bin/submit SYSTEM_MAIL_FLAGS:-mlruxto,cc\* in /etc/lynx-cur/lynx.cfg solved the problem: lynx restarted to behave in the way it always did. None of my configs require uncommenting the value, since it's been working as designed for a long time. May be the pre-compiled value is overriden at some point ? Sébastien.
Bug#398004: #398004 lynx-cur: Bad default for system mailer
I don't see where the problem lies: the configure script finds the same value as the one you want to uncomment. The compiled-in value (which you can inspect by looking at LYNXCOMPILEOPTS:/) shows this string. None of my configs require uncommenting the value, since it's been working as designed for a long time. So I'm guessing there's some problem with your configuration which needs some analysis. -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
