Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64
After running further tests today, I think this is in fact *not* related to gcc but to the kernel itself. I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the kernels fail to boot (balck screen just after grub and nothing in the logs). A few days ago (beginning of this week, I was able to compile the 4.9-rc6+ kernel fine (with gcc-6 6.2.1-4) so something must have changed in the kernel itself (or elsewhere on the system?). I am not able to bisect now, but at least this seems to clear gcc from being the main culprit. Best regards Damien
Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64
Replying to myself: sorry for the false lead, this is not the same problem. The one from gcc bugtracker is not related to the stable gcc-6 branch used in Debian unstable, so the problem must be somewhere else. The -fno-printf-return-value is not recognized with gcc 6 from Sid. Best regards Damien
Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64
Hi, The problem is discussed here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 In the meantime, a workaround is to add -fno-printf-return-value to CFLAGS. Best regards Damien
Bug#791829: fixed in openvpn 2.3.7-2
Hi, I am surprised not to find more followups on this (maybe people running systemd are now OK with version 2.3.7-2?). As I wrote earlier in the thread, applying debian packaging files from 2.3.7-1 on top of vanilla 2.3.8 works fine for me (provided that I add --askpass in DAEMONARGS inside /etc/init.d/openvpn). But using 2.3.7-2 does NOT work for me (with sysvinit). After doing some diffs and digging in openvpn's git repo, I think some password fixes from 2.3.8 have not been included in 2.3.7-2, notably commits (the first one being the most important): 315f6fbc7f657a7f1127628bd714f468709d5185 (fix regression: query password before becoming daemon) 079e5b9c13bf81d7afc6f932b5417d2f08f8e64b (Produce a meaningful error message if --daemon gets in the way of asking for passwords.) b6ec7fbe96f4e200b8962ef6bb572bbb2228133e (Document --daemon changes and consequences (--askpass, --auth-nocache)) Could you have a look at this, please? Thanks, -- Damien Wyart
Bug#791829: fixed in openvpn 2.3.7-2
Hi, After some testing, I still get the problem with 2.3.7-2 on a sysvinit based system. Even adding "--askpass" explicitely in the DAEMONARGS doesn't work (it worked with 2.3.7-1), so the added fix seems broken, at least with sysvinit. Could someone confirm this? I had to go back to an older version for now. Thanks, -- Damien Wyart
Bug#791829: new upstream
Hi, I confirm that a manually built packages with 2.3.8 sources and the addition of --askpass in DAEMONARG works fine (without this addition it did not work, as 2.3.8 fixed the use of this option, but it is not used in the package startup script). I guess --askpass should be also added in openvpn@.service, but I did not test that as I am not using systemd. Cheers, -- Damien Wyart
Bug#722549: closed by David Kalnischkies kalnischkies+deb...@gmail.com (Re: Bug#722549: apt-get source with more than one argument fails)
Can you confirm that this is fixed in 0.9.11.4 with the more general pkgTagFile fix included in it? In a quick try on my system it seems to work with current git, while 0.9.11.3 is broken, so I will be bold and mark it as done, but please reopen if you can still reproduce it. Indeed, this looks fixed in 0.9.11.4, I can't reproduce it any more. Thanks, I was getting bored to write shell loops to get several sources at once :) -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722549: apt-get source with more than one argument fails
Package: apt Version: 0.9.11.3 Severity: normal Dear Maintainer, Starting with version 0.9.11, I can't use apt-get source with several package names : $ apt-get source perl coreutils Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'perl' packaging is maintained in the 'Git' version control system at: git://anonscm.debian.org/perl/perl.git -b debian-5.18 E: Unable to find a source package for coreutils As a workaround, I can do $ for p in perl coreutils; do apt-get source $p; done So this is not so annoying, but might be irritating. Thanks -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages apt depends on: ii debian-archive-keyring 2012.4 ii gnupg 1.4.14-1 ii libapt-pkg4.12 0.9.11.3 ii libc6 2.17-92+b1 ii libgcc1 1:4.8.1-10 ii libstdc++6 4.8.1-10 apt recommends no packages. Versions of packages apt suggests: pn apt-doc none ii aptitude0.6.8.2-1.2 ii dpkg-dev1.17.1 ii python-apt 0.8.9.1+b1 ii xz-utils5.1.1alpha+20120614-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628550: grub-pc: Since 1.99-1, /usr/share/images/desktop-base/spacefun-grub.png is not displayed any more at boot
Package: grub-pc
Version: 1.99-5
Severity: normal
Hi,
Since 1.99-1, the spacefun-gurb background image is not displayed
anymore.
On another computer with a different partitioning scheme, the problem is
not present, so that might be related to partitions and filesystems.
Here is the /etc/fstab file from THIS OTHER COMPUTER, WHERE THE PROBLEM
DOES NOT OCCUR :
# /dev/sda7 noneswapsw 0 0
# /dev/sda5 / xfs defaults,errors=remount-ro,relatime,logbsize=262144 0 1
# tmpfs /tmptmpfs defaults,nosuid,nodev,size=2G 0 0
# /dev/sda6 /home xfs default,noatime,nodiratime,logbsize=262144 0 2
The main difference with the computer where the background is NOT
displayed is that /usr and /var are not on a different partition.
Thanks
Damien Wyart
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/root / ext3
rw,noatime,nodiratime,errors=remount-ro,barrier=0,data=writeback 0 0
/dev/sda3 /usr xfs rw,noatime,nodiratime,attr2,delaylog,logbsize=256k,noquota 0 0
/dev/sdb1 /var xfs rw,relatime,attr2,delaylog,logbsize=256k,noquota 0 0
/dev/sdb2 /home xfs rw,noatime,nodiratime,attr2,delaylog,logbsize=256k,noquota
0 0
/dev/sdb5 /storage xfs
rw,noatime,nodiratime,attr2,delaylog,logbsize=256k,noquota 0 0
/dev/sdb7 /backup xfs
rw,noatime,nodiratime,attr2,delaylog,logbsize=256k,noquota 0 0
/dev/sdb8 /backupwin vfat
rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,quiet,showexec,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-SSDSA2SH032G1GN_INTEL_CVEM9081004C032HGN
(hd1) /dev/disk/by-id/ata-WDC_WD3000HLFS-01G6U0_WD-WXLY08133320
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=0
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod part_msdos
insmod xfs
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 754ba6c4-a454-4f49-9a1e-5f92f7c27db5
if loadfont /share/grub/unicode.pf2 ; then
set gfxmode=1024x768
load_video
insmod gfxterm
fi
terminal_output gfxterm
set timeout=15
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod xfs
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 754ba6c4-a454-4f49-9a1e-5f92f7c27db5
insmod png
if background_image /share/images/desktop-base/spacefun-grub.png; then
set color_normal=light-gray/black
set color_highlight=white/black
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 2.6.39' --class debian --class
gnu-linux --class gnu --class os {
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root
425b2f08-f303-47e9-b8f2-7a9db0618593
echo'Loading Linux 2.6.39 ...'
linux /boot/vmlinuz-2.6.39 root=/dev/sda2 ro vga=0x345 selinux=0
elevator=cfq rootflags=data=writeback quiet
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/22_invaders ###
menuentry GRUB Invaders {
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root
425b2f08-f303-47e9-b8f2-7a9db0618593
multiboot /boot/invaders.exec
}
### END /etc/grub.d/22_invaders ###
### BEGIN /etc/grub.d/30_os-prober ###
menuentry Windows Vista (loader) (on /dev/sda1) --class windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 5094333894331FC0
chainloader +1
}
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
#menuentry Windows Vista (loader) (on /dev/sda1) {
#insmod part_msdos
#insmod ntfs
#set root=(hd0,1)
#search --no-floppy --fs-uuid --set 5094333894331fc0
#chainloader +1
#}
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg
Bug#624010: Experiencing a similar problem but without LVM
Hi, I am not using LVM, so I do not reproduce the exact same problem, but after upgrading to udev 168-1 my system also became unbootable. It looks like root gets mounted (I do not use an initrd), but some disk device nodes in /dev are not yet present when the fsck are started, so they fail, and I get an emergency prompt. If I press C-d, boot continues normaly. The devices which fail to be fscked are different each time, so it looks a bit like a timing problem. With 167-3, everything is fine. I do not have a /run directory. I am a bit surprised nobody has reported this earlier, maybe people do not reboot that often... Best, -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624010: Experiencing a similar problem but without LVM
* m...@linux.it (Marco d'Itri) [110426 15:21]: It looks like root gets mounted (I do not use an initrd), but some disk device nodes in /dev are not yet present when the fsck are started, so they fail, and I get an emergency prompt. If I press C-d, boot continues So you are using a custom kernel without devtmpfs, for a start. That's right; enabling devtmpfs in my custom kernelmade the problem go away. May I ask how you guessed that my problem could be related to this? I thought udev creating a tmpfs for /dev when devtmpfs is not enabled was not affecting its subsequent behaviour. Does this somehow mean that devtmpfs is now required for udev to work properly, at least in Debian? Thanks, -- Damien Wyart pgpaSepBKgJYA.pgp Description: PGP signature
Bug#601601: libnetaddr-ip-perl: Reopen
Sorry to break the thread, I had not subscribed to the bug (done now). Did a quick test of applying Dominique's suggestion on top of libnetaddr-ip-perl v4.035, and this doesn't seem to solve the problem with spamassassin. The message with lead to creation of 601601 is still appearing. Please not I am not a Perl expert, so my test might not be highly reliable but this gives a hint... Best, -- Damien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601601: libnetaddr-ip-perl: Reopen
Ok, no problem. Thanks for your explanation. As the last message in 601601 was refering to 517361, I thought there was a technical link between the two. So let's hope some SA hackers will be able to help on these two issues... Best, Damien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601601: libnetaddr-ip-perl: Reopen
What was wrong with my own 4.035 build was SpamAssassin's behaviour (this is what I wrote in my reports, msgs 59 and 64), NOT Noah's test.pl script. The test script was OK, but from the start I have wanted to highlight that the SA problem, at the origin of 601601, was still there, so the test and its associated patch in 4.035 were not enough concerning 601601. With 4.035 (my build or the official one), I still see the problematic messages from SA when starting, learning or when the daily cron runs. But the test.pl script if fine. So I am in the same situation as Elimar. -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601601: spamassassin: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included
NetAddr-IP-4.035 should fix this bug, but after upgrading manually /usr/lib/perl5/NetAddr/IP/Lite.pm to 1.21, I still see the problem when spamassassin starts, learns new spam or when the daily cron job is called. So not sure the upstream fix in netAddr::IP has cured the initial problem reported for spamassassin in but 601601. Or maybe I did something stupid when doing these tests... Best, -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601601: spamassassin: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included
To test in a more clean way, I manually built libnetaddr-ip-perl_4.035+dfsg-1_amd64.deb using the sources from CPAN and the 4.035 packaging from Debian, and I can confirm the cannot include messages from spamassassin are still there, so I guess the fix might have corrected part of the problem, but we are not yet back to 4.033 situation wrt spamassassin. Could someone with better knowledge of all this reopen the upstream bug after some further analysis? Many thanks in advance. Best, Damien NetAddr-IP-4.035 should fix this bug, but after upgrading manually /usr/lib/perl5/NetAddr/IP/Lite.pm to 1.21, I still see the problem when spamassassin starts, learns new spam or when the daily cron job is called. So not sure the upstream fix in netAddr::IP has cured the initial problem reported for spamassassin in but 601601. Or maybe I did something stupid when doing these tests... Best, -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542489: [Pkg-fonts-devel] Bug#542489: ttf-inconsolata: No italics in Emacs 23 Gtk+
Hello, I am also annoyed by this bug. Inconsolata fits my needs very well, but having italic/oblique working in Emacs 23 would be a plus for complex editing. Anything I can do to help on this problem? This is a very, very quick and dirty solution: I think that you can open the font with fontforge, let it slant the fonts automatically, save the result with a different name and use it. Sorry for my quite dumb question. I realized that I had convinced myself that oblique was already included in Inconsolata but not available in Emacs. Further checking showed this was not the case (the original bugreport was a bit misleading). I prefer not to start using hacks to get fake oblique... BTW, I find Inconsolata good for high-resolution devices (e.g., print), but the blurry (and even colored) shapes make my eyes hurt. I am not entierely conviced myself, but as Terminus, which I prefer, doesn't have a good-quality oblique, I have looked at alternatives. After getting your answer, I made some tests with DejaVu Sans Mono (quite good) and Anonymous Pro (surprising at first, but quite usable). Best, -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542489: [Pkg-fonts-devel] Bug#542489: ttf-inconsolata: No italics in Emacs 23 Gtk+
I realized that I had convinced myself that oblique was already included in Inconsolata but not available in Emacs. Further checking showed this was not the case (the original bugreport was a bit misleading). Yes, I don't see any kind of italics or oblique here. I guess the initial bug reporter did not know about this and was just (as I did at first) supposing Emacs was not able to use the (supposedly existing) oblique variant because of a packaging problem in the font. Maybe the bug should be closed? BTW, is Anonymous Pro packaged already? I could not find it with a quick search, but seeing as it is Free Software---Open Font Licence---, it could be packaged (if anybody else has not started it yet). There is a RFP here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551955 Best, -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542489: ttf-inconsolata: No italics in Emacs 23 Gtk+
Hello, I am also annoyed by this bug. Inconsolata fits my needs very well, but having italic/oblique working in Emacs 23 would be a plus for complex editing. Anything I can do to help on this problem? -- Damien Wyart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403269: fonty version 1.0-23.5 (unstable) display wrong chars for drawing lines
Package: fonty Version: 1.0-23.5 Severity: important With versions 1.0-23.N, lines are displayed incorrectly, for example in links2 dialog boxes. 1.0-22 does not have the problem. I am surprised nobody reported this yet... Maybe this is related to the yada problems ? -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-rc6-mm2-28112006dw Locale: LANG=C, LC_CTYPE=fr_FR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages fonty depends on: ii console-data 2:1.01-4 Keymaps, fonts, charset maps, fall ii console-tools 1:0.2.3dbs-65 Linux console and font utilities ii debconf1.5.10Debian configuration management sy fonty recommends no packages. -- debconf information: * fonty/charset: iso1 (Western European) * fonty/restart: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397796: Additional info on 397796
In fact, after further testing, I realised the mboxes I had tested on were corrupt (bad separators at some places), so the bug can be closed. -- Damien Wyart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397796: grepmail: Tons of Use of uninitialized value in numeric gt () at /usr/share/perl5/Mail/Mbox/MessageParser/Grep.pm line 266.
Package: grepmail Version: 5.3032-2 Severity: important Using grepmail (the content of the mbox doesn't change anything, I get the behaviour with all the files I tested) triggers a handful of messages : Use of uninitialized value in numeric gt () at /usr/share/perl5/Mail/Mbox/MessageParser/Grep.pm line 266. grepmail has to be interrupted after a while to stop this (and the corresponding results are correctly sent to stdout). This seems close to 338447, but not the same. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-rc4-mm2-02112006dw Locale: LANG=C, LC_CTYPE=fr_FR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages grepmail depends on: ii libmail-mbox-messageparser-pe 1.4005-1 fast and simple mbox folder reader ii libtimedate-perl 1.1600-5 Time and date functions for Perl ii perl 5.8.8-6.1 Larry Wall's Practical Extraction ii perl-base [libscalar-list-uti 5.8.8-6.1 The Pathologically Eclectic Rubbis grepmail recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314847: maildrop does not deliver because of dotlock problem
* Josip Rodin [EMAIL PROTECTED] [2006-08-30 11:51]: For now maildrop has a fixed dependency, and later when bugs filed against courier-authlib are fixed (#378249 and/or #378241), it will get it automatically. Ok, thanks for the information. But I still do not understand why depending on courier-authlib is necessary at all. I think this is necessary when courier is used as part of a courier server, but I thought the maildrop package of debian was intended to be used standalone. So why not a maildrop package, with maildrop compiled using --disable-authlib and not requiring any courier lib and a courier-maildrop package, with the appropriate dependancies on courier libs ? What do you think ? In my case, when I was using maildrop compiled by hand, it did not have any dependancy on courier-authlib, and it worked fine. I did not have to use --disable-authlib because the lib was not on my system, so I guess it is present on the build machine of Debian, and gets enabled by default during the build of the official package. -- Damien Wyart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314847: maildrop does not deliver because of dotlock problem
Hello,
Thanks for your feedback on this problem.
* Josip Rodin [EMAIL PROTECTED] [060828 02:28]:
This was supposed to be delivering to /var/mail, or some other folder?
What are the permissions on it?
This was /var/mail, with standard permissions. Version 1.5 of maildrop
was working without problem.
Also, courier-authlib is not listed in dependencies, so if it is not
installed by hand, maildrop fails because it doesn't find authlib.
maildrop 2.x, available in package since recently, tries to use
authdaemon when you run it with -d, and even then you need
a privileged user to run it, I think.
After seeing that 2.0.2 was in experimental --- had not followed it
closely (my tests bug were from 1.8), I retried installing it again
today, and first got messages like this :
Command died with status 127: /usr/bin/maildrop -d ${USER}. Command
output: /usr/bin/maildrop: error while loading shared libraries:
libcourierauth.so.0: cannot open shared object file: No such file or
directory
So the problem of dependency on courier-authlib is still the same.
Installing maildrop should have it work by default, not complain on
a missing lib !
After installing courier-authlib, errors messages indicated that
I should install courier-authdaemon... And after installing this one,
messages read like this from the MTA :
temporary failure. Command output: ERR: authdaemon: s_connect() failed:
Permission denied /usr/bin/maildrop: Temporary authentication failure.
So I guess I would again need to configure something else to make it
work, which is inacceptable.
maildrop 1.5 was working like a charm without configuring anything, so
2.0.2 should work the same way. And of course the problems I just
described are not described anywhere in the maildrop debian docs...
Just in case you reply that maildrop 2.0.X works like this, I have to
answer no, because since this bug report last year, as I got no reply,
I compiled maildrop 2.0.2 by hand (some months ago) without any special
option, and it worked flawlessly, like 1.5 (Debian package) was.
So I guess the packaging of 2.0.2 is broken, and that it has been
compiled in depending on the full courier framework mode instead of
standalone mode (seems the configure script is trying to detect this,
but this can be bypassed with --disable-authlib --- not I did not have
to use it on my computer to get it right).
* Josip Rodin [EMAIL PROTECTED] [060828 02:49]:
Oh, I think I get it. Do you perhaps use relative paths in your
.mailfilter file? What is the current working directory of the
maildrop process at that point?
Just to be precise : no, my paths in .mailfilter are not relative.
If you need more info, do not hesitate to contact me.
Best regards,
--
Damien Wyart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314847: maildrop does not deliver because of dotlock problem
* Josip Rodin [EMAIL PROTECTED] [2006-08-28 17:22]: I've tried to
reproduce it now, and it seems that it's a full-blown link instead of
a dynamic open. Please install courier-authlib in the meantime. I'll
investigate if it should become more optional.
Ok, I have installed it to test once again.
temporary failure. Command output: ERR: authdaemon: s_connect() failed:
Permission denied /usr/bin/maildrop: Temporary authentication failure.
What user are you running maildrop with? That's what I meant by even
then you need a privileged user to run it, I think.
maildrop is only run by one local user, from his .forward file.
[...] But more to the point, what user are you trying to run
maildrop -d with, and what is your expected behaviour? What do you
expect from the -d option?
-d ${USER} in .forward has been used because of a suggestion to do so in
MAILDROP_README of the postfix distribution... I guess this is not
correct (with recent maildrops).
Since the initial bug report says you run it from a .forward file, can you
instead try simply omitting the -d option altogether?
When -d is omitted, this works ok (when courier-authlib is installed).
Thanks for clarifying this.
The last thing I do not understand is that the maildrop that had been
compiled and installed manually is not suid at all, and the -d ${USER}
works ok. I guess this is because the ${USER} is replaced by same id as
the one owning the maildrop process (this is the same user). The doc of
maildrop seems to tell that this case of using -d is ok.
But with the debian version (2.0.2), this doesn't work, so this seems
related to courier-authlib... With my own compiled version, I do not get
the ERR: authdaemon: s_connect() failed: No such file or directory
/usr/bin/maildrop: Temporary authentication failure. error at all when
using -d ${USER} in .forward.
Thanks for your help,
--
Damien Wyart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314847: maildrop does not deliver because of dotlock problem
What about this suggestion I made : So I guess the packaging of 2.0.2 is broken, and that it has been compiled in depending on the full courier framework mode instead of standalone mode (seems the configure script is trying to detect this, but this can be bypassed with --disable-authlib --- not I did not have to use it on my computer to get it right). ? Does maildrop really have to use courier-authlib at all ? I thought this package was inteded for standalone use only, else it would be called courier-maildrop... Best, -- Damien Wyart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314847: more info about maildrop does not deliver because of dotlock problem
maildrop from experimental doesn't deliver at all. I use it with postfix, and I get messages like this : Jun 18 22:19:09 brouette postfix/local[3990]: 6F36E45BBC: to=[EMAIL PROTECTED], relay=local, delay=9, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Unable to create a dot-lock. ) After further investigation, this comes from the fact that the patch lockmail-setgid.patch, present in Debian 1.5, is not here any more in Experimental 1.8. I also tested by hand the latest 2.0.1 version, and at configure stage, as the spool mail directory is has no sticky bit, dotlocking is disabled (enabling it by hand leads to same problem, without it maildrops works fine). Maybe this behaviour should me made the default in the future new package ? Is flocking sufficient ? Why has dotlocking been enabled by default in Debian ? Of course, 2.0.1, relying on more robust PCRE, should be considered for packaging in experimental. -- Damien Wyart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314847: more info about maildrop does not deliver because of dotlock problem
After further investigation, this comes from the fact that the patch lockmail-setgid.patch, present in Debian 1.5, is not here any more in Experimental 1.8. Not sure, in fact, because applying the patch to 2.0.1 doesn't make it work when dotlocking is enabled. So further investigation is again needed... -- Damien Wyart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314847: maildrop does not deliver because of dotlock problem
Package: maildrop
Version: 1.8.1-2
Severity: grave
Justification: renders package unusable
I have used maildrop from unstable with succes for many months, and with
the same config (based of .forward containing :
|/usr/bin/maildrop -d ${USER}
) maildrop from experimental doesn't deliver at all.
I use it with postfix, and I get messages like this :
Jun 18 22:19:09 brouette postfix/local[3990]: 6F36E45BBC:
to=[EMAIL PROTECTED], relay=local, delay=9, status=deferred (temporary
failure. Command output: /usr/bin/maildrop: Unable to create a dot-lock.
)
Also, courier-authlib is not listed in dependencies, so if it is not
installed by hand, maildrop fails because it doesn't find authlib.
I have looked at authlib config, but did not see something relevant to
tune.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=C, LC_CTYPE=fr_FR.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages maildrop depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.0-9GCC support library
ii libgdbm31.8.3-2 GNU dbm database routines (runtime
ii libstdc++5 1:3.3.6-6The GNU Standard C++ Library v3
ii postfix [mail-transport-age 2.2.3-3 A high-performance mail transport
maildrop recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
