Bug#604463: sqlrelay: typo in debian/rules' configure call (disable-freetds-rapth)
Package: sqlrelay Version: 0.39.4-11 Severity: normal debian/rules calls the configure-command using an option 'disable-freetds-rapth'; this is a typo, the correct option is named 'disable-freetds-rpath'. -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-rc8 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548056: libspreadsheet-writeexcel-perl: missing dependency to libole-storage-lite-perl
Package: libspreadsheet-writeexcel-perl Version: 2.22-1 Severity: normal libspreadsheet-writeexcel-perl includes /usr/bin/chartex, which in turn requires the perl module OLE::Storage_Lite: and...@ista:~$ chartex something.xls Can't locate OLE/Storage_Lite.pm in @INC (@INC contains: /etc/perl /usr/local/li b/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/ lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/chart ex line 18. BEGIN failed--compilation aborted at /usr/bin/chartex line 18. OLE::Storage_Lite is provided by libole-storage-lite-perl, so adding this dependency or suggestion should fix this issue. Thanks, Anders -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libspreadsheet-writeexcel-perl depends on: ii libparse-recdescent-perl 1.95.1+dfsg-3 generates recursive-descent parser ii perl 5.10.0-19lenny2 Larry Wall's Practical Extraction Versions of packages libspreadsheet-writeexcel-perl recommends: ii libdate-calc-perl 5.4-5+b1 Perl library for accessing dates ii libdate-manip-perl5.54-1 a perl library for manipulating da libspreadsheet-writeexcel-perl suggests no packages. -- 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#517674: bind directive in tinyproxy.conf does not work
I'd like to note that the directive does work in etch's release (e.g. tinyproxy_1.6.3-2_i386.deb). The bind directive enables one to set the ip address of outgoing packets. For example, I'm running such a setup: -box has two IP adresses, an internal and an external one. -default route via internal network. -tinyproxy is configured to listen to the internal IP address, and bind to the external IP address. -Effect: Outgoing traffic is sent with the external IP address. Using Tinyproxy 1.6.3-3.2 from Lenny results in outgoing traffic being sent by using the standard routing tables (with the internal IP address rather the bind-configured IP address). Anders -- 11 Internet AGSystems Architect Brauerstrasse 48 v://49.721.91374.0 D-76135 Karlsruhe f://49.721.91374.225 Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen Aufsichtsratsvorsitzender: Michael Scheeren -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476651: missing build-dependency to libgnutls-dev
Package: snort Version: 2.7.0-13 Severity: normal Dear Debian maintainer, while backporting the package to etch in order to have a snort with prelude support, I've learnt the hard way that the includes configure skript tries a test compile against libprelude-dev where it also requires libgnutls-dev (which may not be installed on a build host). The interesting point is, that in this combination --enable-prelude is given on the configure line but the resulting package doesn't include prelude support. Simple QA-checks won't fail, but if you're trying to use the prelude functions, the resulting binary might fail. ---cut checking for libprelude - version = 0.9.6... no *** Could not run libprelude test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means LIBPRELUDE was incorrectly installed *** or that you have moved LIBPRELUDE since it was installed. In the latter case, you *** may want to edit the libprelude-config script: /usr/bin/libprelude-config ---cut Reason from config.log: ---cut configure:23977: checking for libprelude-config configure:23995: found /usr/bin/libprelude-config configure:24008: result: /usr/bin/libprelude-config configure:24016: checking for libprelude - version = 0.9.6 configure:24104: gcc -o conftest -g -O2 -D_GNU_SOURCE -Wall -I/usr/include/mysql -DENABLE_MYSQL -L/usr/lib -lpcre -L/usr/lib -pthread conftest.c -lmysqlclient -lz -lpcre -lpcap -lm -lnsl -L/usr/lib -lprelude -L/usr/lib -lgnutls -lgcrypt -lgpg-error -lrt -ldl 5 /usr/bin/ld: cannot find -lgnutls collect2: ld returned 1 exit status configure:24107: $? = 1 configure: program exited with status 1 [...] configure:24175: gcc -o conftest -g -O2 -D_GNU_SOURCE -Wall -I/usr/include/mysql -DENABLE_MYSQL -L/usr/lib -lpcre -L/usr/lib -pthread conftest.c -lmysqlclient -lz -lpcre -lpcap -lm -lnsl -L/usr/lib -lprelude -L/usr/lib -lgnutls -lgcrypt -lgpg-error -lrt -ldl 5 /usr/bin/ld: cannot find -lgnutls collect2: ld returned 1 exit status configure:24181: $? = 1 ---cut From some point of view, libgnutls-dev ought to be a dependency in libprelude-dev, but libprelude-dev is also usable without gnutls. Snort's use of libprelude-dev seems to includes the usage of libgnutls-dev, so in my eyes, adding a build-dependency to libgnutls-dev should resolve this issue. Anders -- 11 Internet AG System Design Brauerstrasse 48 v://49.721.91374.50 D-76135 Karlsruhef://49.721.91374.225 Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409008: mount --move screws up mtab
Package: mount Version: 2.12r-19etch1 Also verified for 2.12r-19etch1. By repeating such a --move operations a few times, /etc/mtab grows by even more bind-mounts: /drive /mnt none rw 0 0 /mnt /drive none rw 0 0 /drive /mnt none rw 0 0 /mnt /drive none rw 0 0 /proc/mounts correctly notices the move and promptly gives only a single line with the correct device. I believe that /etc/mtab should behave more like /proc/mounts. This bug is certainly annoying, as a moved subtree is no longer correctly printed from e.g. df: move a subtree, df will stick to the old mountpoint. Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462494: ldconfig: /lib/libe2p.so.2.3 is not an ELF file in UML on AMD64
Package: e2fslibs Version: 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 Severity: wishlist I'm running user mode linux on an x86_64-host running vanilla 2.6.23.14, the guest kernel is also a vanilla 2.6.23.14 for x86_64, the guest image is a Debian 4.0 (Etch) installed using debootstrap --arch amd64 --include=ssh, file etch /mnt/ $mirror, so a pretty plain base system. When running ldconfig within the UML system, ldconfig spews: ldconfig: /lib/libe2p.so.2.3 is not an ELF file - it has the wrong magic bytes at the start. ... which is wrong, according to 'file': test55:~# file /lib/libe2p.so.2.3 /lib/libe2p.so.2.3: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped To rule out any issues, I've compared the md5sum of the library against the one installed on a non-UML-but-x86_64-Debian-4.0-host: test55:~# md5sum /lib/libe2p.so.2.3 307efefd378716de11961ef93a440b71 /lib/libe2p.so.2.3 dnr:~# md5sum /lib/libe2p.so.2.3 307efefd378716de11961ef93a440b71 /lib/libe2p.so.2.3 (The non-UML-host's ldconfig works fine and doesnt bark at me) ldconfig is in the libc6-package, whis is also the same release on both UML and non-UML host (both by package version as well as md5sum of /sbin/ldconfig), so from my point of view, im quite stuck. I've also tried the UML-root-FS from http://uml.nagafix.co.uk/Debian-4.0/Debian-4.0-AMD64-root_fs.bz2 ... whichs exhibits the same behaviour both running my kernel as well as http://uml.nagafix.co.uk/kernels/kernel64-2.6.23.12.bz2, so I'm pretty sure that this issue is related to the debian package. One difference between the UML guest kernel and the host kernel is that the host kernel allows to run IA32 binaries, something UML doesn't offer; however, the library is identical to the one installed in /lib64/ (and which isn't being barked at by ldconfig): test55:/lib# ls -la /lib64/libe2p.so.2* /lib/libe2p.so.2.3 -rw-r--r-- 1 root root 24200 Dec 6 15:55 /lib/libe2p.so.2.3 -rw-r--r-- 1 root root 24200 Dec 6 15:55 /lib64/libe2p.so.2.3 test55:/lib# md5sum /lib64/libe2p.so.2.3 /lib/libe2p.so.2.3 307efefd378716de11961ef93a440b71 /lib64/libe2p.so.2.3 307efefd378716de11961ef93a440b71 /lib/libe2p.so.2.3 Another UML image http://uml.nagafix.co.uk/CentOS-5/CentOS5-AMD64-root_fs.bz2 has a quite empty /lib/, the libraries are found only in /lib64/, including libe2p.so.2.3, and this UML image doesn't exhibit this behaviour. The image http://uml.nagafix.co.uk/Ubuntu-Feisty/Ubuntu-FeistyFawn-amd64-root_fs.bz2 is closer to Debian 4.0 and also contains the same libraries in /lib and /lib64, but running ldconfig doesn't provoke the error message. So in the end, I'm quite unclear wether this might be an issue for ldconfig (libc6 package), UML or e2fslibs. Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462265: dependency for libtemplate-html-perl is missing
Package: mysql-server-5.0 Version: 5.0.45-5 Severity: normal Issue appears on 5.0.45-5~bpo40 as well as 5.0.32-7etch4 ... The package contains a perl script /usr/bin/ndb_size, who tries to estimate the memory usage if a given database where put onto an ndb cluster and creates a HTML report using 'use HTML::Template;'. So some dependency to libhtml-template-perl were fine in order to ease the automated installation of the mysql-server-package for any case. Yes, most people do live fine without this, but at least a Suggests: libhtml-template-perl were fine. Regards, Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446075: optionally turn off persistent device naming
Am 10.10.2007 schrieb Marco d'Itri: On Oct 10, Anders Henke [EMAIL PROTECTED] wrote: My suggestion is to enable/disable persistent net device naming via some variable in a to-be-created /etc/default/udev, either globally or for some specific device. rm /etc/udev/rules.d/z45_persistent-net-generator.rules This link is automatically regenerated within the postinstall script: if [ $(dpkg --print-architecture) != s390 ]; then ln -s ../persistent-net-generator.rules z45_persistent-net-generator.rules fi So the just delete the link-way of resolving this isn't really friendly, as the problem is about to reappear after every udev update. The link's name isn't also that easy to find, so this solution also isn't that nice to the user. E.g. after changing a box due to a failed on-board SCSI HBA, the kernel (!) spews out warnings like this: ---cut e1000: :04:02.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:30:48:2f:c1:54 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection Uniform watchdog device driver v0.01 loaded iTCO_vendor_support: vendor-support=0 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 (17-Aug-2007) iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0x1060) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) eth0 renamed to eth2 sysfs: duplicate filename 'eth2' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() Call Trace: [802b5183] sysfs_add_one+0x54/0xbd [802b5eba] sysfs_create_link+0xc4/0x11e [80360849] device_rename+0x175/0x1d6 [803fdb6f] dev_change_name+0x138/0x22c [803fe3b1] dev_ioctl+0x376/0x459 [8032f517] __up_read+0x13/0x8a [803f1615] sock_ioctl+0x1e1/0x1ef [80280cc9] do_ioctl+0x21/0x6b [80280f60] vfs_ioctl+0x24d/0x266 [8027432d] fd_install+0x25/0x59 [80280fb5] sys_ioctl+0x3c/0x5f [8020b55e] system_call+0x7e/0x83 net eth2: device_rename: sysfs_create_symlink failed (-17) e1000: :04:02.1: e1000_probe: (PCI-X:133MHz:64-bit) 00:30:48:2f:c1:55 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth0 renamed to eth3 sysfs: duplicate filename 'eth3' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() [...] ---cut It took me a while to find out who tried to rename my interfaces, provoked kernel warnings and renamed interfaces just after changing a box's hardware; main reason for this is that I didn't assume that udev tries to manage devices who don't leave a footprint in /dev. Personally, I think that it's a good idea to have consistent interface names, but at least it's worth to take a note about this either during upgrading from an older (pre-persistent-devicename) udev or non-udev box to a current udev install or at least with a note in the README.Debian file, as this may become a very significant change to the way the system works. If the idea of persistent interface names is being used in a consistent way (e.g. renaming network devices from eth0 to e.g. lan and making users switch their configs to the new lan device), it's a cool way to migrate between e.g. 2.4 and 2.6-based kernels (who enumerate e100/e1000 devices in a different way) or to work with hotpluggable network interfaces (USB, PCMICA, ...). However, there are clearly situations where the old behaviour is much more appreciated, and I've given a few examples for this. Regards, Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446075: optionally turn off persistent device naming
Am 11.10.2007 schrieb Marco d'Itri: On Oct 11, Anders Henke [EMAIL PROTECTED] wrote: This link is automatically regenerated within the postinstall script: It's not. E.g. after changing a box due to a failed on-board SCSI HBA, the kernel (!) spews out warnings like this: Surprise: you have a buggy kernel. The Problem occured both using kernel-image-2.6-em64t-p4 (2.6.18+6etch1) as well as an own built 2.6.22.6 and 2.6.23-rc8-mm2. Well, in this case I think that first udev freed eth0/eth1 for the reserved MAC-adresses by renaming eth0/eth1 to eth2/eth3, while write_net_rules afterwards created new entries for the freshly-created eth2/eth3. The variable NAME isn't yet set, so persistent-net-generator.rules first tried to create persistent entries for eth2/eth3 and then tried to rename the devices e.g. from eth2 to eth2 (which made the kernel warn). But that's just an idea. However, there are clearly situations where the old behaviour is much more appreciated, and I've given a few examples for this. And are a small-enough number that persistent interface names are going to stay. Fine. My idea was to simply make this optional or at least document it, as there are known problems with this behaviour. However, it's your decision and I've filed this only as a wishlist bug, so you're free to close this issue. Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446075: optionally turn off persistent device naming
Package: udev Version: 0.105-4 Severity: wishlist The persistent device naming in udev does give quite persistently headaches ... Since udev, swapping hardware isn't that easy anymore, as the persistent device names try to reserve device names. E.g. if some NIC has been confirmed to be broken and is going to be replaced, udev's /etc/udev/rules.d/z25_persistent-net.rules reserves eth0 for some device with the MAC adress of the broken NIC, so the new (and only one) NIC in that box is being renamed from eth0 to eth1. I'm also deploying servers by cloning the installed files onto different boxes, changing /etc/network/interfaces to the new ip address, alter /etc/hostname, /etc/mailname and /etc/hosts to the new network configuration. Of course, the same problems occur (net devices become renamed). This minor change creates quite a few problems: as the device name eth0 is in use by quite a few applications and configurations (/etc/network/interfaces, /etc/default/dhcp3-server, ...), so automatically renaming the device creates new problems and so swapping the NIC (or the whole box including its onboard NIC due to some other error) Other applications like e.g. airmon-ng makes udev create new devices on the fly (with rising interface numbers); http://aircrack-ng.org/doku.php?id=airmon-ng is an example for this. My suggestion is to enable/disable persistent net device naming via some variable in a to-be-created /etc/default/udev, either globally or for some specific device. For my own services, I've created a new /etc/udev/rules.d/z25_persistent-net.rules file: ---cut # NEVER rename eth*: KERNEL==eth*, NAME=$KERNEL ---cut This in turn does match a rule in persistent-net-generator.rules both not to run /lib/udev/write_net_rules and makes udev believe that the device has already been renamed. However, a more userfriendly solution to accomplish basically the same thing would be great. Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332229: raidutils: raideng Segmentation fault
Package: raidutils Version: 0.0.6-3 I'm running the raidutils package on a fresh Etch/amd64 install. Using the etch-kernel '2.6.18-5-amd64', the raideng doesn't seem to detect any i2o controllers at all: ---cut anders3:~# raideng /VERBOSE osdOpenEngine : 08/31/107-15:10:18 Return = 0 - 0 hbas found osdCreateSemaphore : Rtn = 5354b0 dpteng Is Ready. ---cut However, the install is on a RAID1 on that i2o controller and /proc/i2o/iop0/status also states that I'm running an OPERATIONAL ADAPTEC 2015S: ---cut Organization ID: 0x001b IOP ID : 0xfff Host Unit ID : 0x Segment Number : 0x000 I2O version: 1.5 IOP State : OPERATIONAL Messenger Type : Memory mapped Inbound Frame Size : 512 bytes Max Inbound Frames : 256 Current Inbound Frames : 256 Max Outbound Frames: 256 Product ID : ADAPTEC 2015S Expected LCT Size : 3702 bytes IOP Capabilities Context Field Size Support : Supports only 32-bit context fields Current Context Field Size : not configured Inbound Peer Support : Not supported Outbound Peer Support : Not supported Peer to Peer Support : Not supported Desired private memory size : 0 kB Allocated private memory size : 0 kB Private memory base address : 0x Desired private I/O size : 0 kB Allocated private I/O size: 0 kB Private I/O base address : 0x ---cut anders3:~# df -h FilesystemSize Used Avail Use% Mounted on /dev/i2o/hda1 486M 116M 344M 26% / tmpfs 2.0G 0 2.0G 0% /lib/init/rw udev 10M 56K 10M 1% /dev tmpfs 2.0G 0 2.0G 0% /dev/shm /dev/shm 2.0G 4.0K 2.0G 1% /tmp /dev/i2o/hda5 2.0G 712M 1.3G 36% /usr /dev/i2o/hda6 3.9G 68M 3.9G 2% /var When using a self-customized current kernel 2.6.22.5, the system also works and raideng detects a hba: ---cut anders3:~# raideng /VERBOSE osdOpenEngine : 08/31/107-14:53:59 Return = 0 - 1 hbas found osdCreateSemaphore : Rtn = 5354b0 dpteng Is Ready. ---cut When calling raidutil -L raid to show the RAID status, raideng happens to do this: ---cut Engine Calls : 08/31/107-14:54:07 Engine Echo Message Engine Calls : 08/31/107-14:54:07 DPT_OpenEngine Engine Calls : 08/31/107-14:54:07 DPT_CallEngine EngTag = 0, Event = 10, Target = 0 Offset = 421 fromEng_P = f04a9421 toEng_P = f04a9000 osdRequestSemaphore : Rtn = 0 osdReleaseSemaphore : Rtn = 0 osdIOrequest : Return = 0 osdRequestSemaphore : Rtn = 0 osdReleaseSemaphore : Rtn = 0 osdConnected : 08/31/107-14:54:07 ioMethod = 1 Engine Calls : 08/31/107-14:54:07 DPT_CallEngine EngTag = 1, Event = 14, Target = 0 Offset = 421 fromEng_P = f04a9421 toEng_P = f04a9000 osdRequestSemaphore : Rtn = 0 osdReleaseSemaphore : Rtn = 0 osdGetCtlrs: 08/31/107-14:54:07 Enter osdGetCtlrs: 08/31/107-14:54:07 Return = 0 osdSendCCB : 08/31/107-14:54:07 (0,0,7,0) OpCode = c1 ProcessEataToI2o:08/31/107-14:54:07 Enter _osdStartCp: 08/31/107-14:54:07 Enter, callback = 40b540 osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff osdSendMessage : IoAddress is zero for HbaNum=0 osdSendMessage : 08/31/107-14:54:07 Return = 8000 _osdStartCp: 08/31/107-14:54:07 Return = _osdStartCp: 08/31/107-14:54:07 Enter, callback = 40b540 osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff osdSendMessage : IoAddress is zero for HbaNum=0 osdSendMessage : 08/31/107-14:54:07 Return = 8000 _osdStartCp: 08/31/107-14:54:07 Return = _osdStartCp: 08/31/107-14:54:07 Enter, callback = 40b540 osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff osdSendMessage : IoAddress is zero for HbaNum=0 osdSendMessage : 08/31/107-14:54:07 Return = 8000 _osdStartCp: 08/31/107-14:54:07 Return = _osdStartCp: 08/31/107-14:54:07 Enter, callback = 40b540 osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff osdSendMessage : IoAddress is zero for HbaNum=0 osdSendMessage : 08/31/107-14:54:07 Return = 8000 _osdStartCp: 08/31/107-14:54:07 Return = Segmentation fault ---cut The kernel syslog also logs the Segfault: ---cut Aug 31 14:54:07 anders3 kernel: raideng[31961] general protection rip:40da2f rsp:7fffbaef0130 error:0 ---cut raidutil then hangs quite infinetely (well, I've waited for a few minutes) and can be aborted using Ctrl-C. Maybe this segmentation fault isn't related to the other segfaults in this bug, but maybe they also do relate to each other. /proc/i2o/iop0/status looks fishy to me; the io-adresses of 0x0 do correspond to the output IoAddress is zero for HbaNum=0 of the running dpteng and it were to simple that raideng would try to connect to the adress of 0x0. In my case, I think that the i2o-Controller responds
Bug#440072: source-local common options unrecognized
Package: syslog-ng
Version: 2.0.0-1
http://www.balabit.com/dl/html/syslog-ng-admin-guide_en.html/ch08s01.html#sourcecommonopts
declares a couple of options, which have been previously available as
global options or only as local option for some sources (e.g. log_prefix
has been available for the file()-source only).
http://osdir.com/ml/syslog-ng/2005-06/msg00138.html also verifies this
reading, that such log_prefix became a general source-specific option
in syslog-ng 1.9.x, available to all source drivers.
However, a configuration like this:
source s_chroot{
unix-stream(/home/jail1/dev/log log_prefix(jail1: ));
};
is rejected by syslog-ng with the error message syntax error at 91
(use syslog-ng -s to verify the config).
To resolve this issue for me, I've recompiled the source by fetching
http://www.balabit.com/downloads/files/syslog-ng/sources/stable/src/syslog-ng-2.0.5.tar.gz,
installing the depency packages (devscripts debhelper libevtlog-dev
libnet1-dev libglib2.0-dev pkg-config) from etch and recompiled the
package by running dpkg-buildpackage -b -uc on the source
before installing it using dpkg -i ../syslog-ng_2.0.5_i386.deb.
The recompiled package works without this issue.
I didn't find any update on this in the upstream changelog or NEWS-file,
so maybe this issue only shows up on Debian boxes (or has been silently
fixed in a release later than 2.0.0).
I'm using Debian GNU/Linux 4.0, kernel 2.6.22.4 and libc6 2.3.6.ds1-13.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401532: fixing EFI GPT table on expanded device results in segfault
Package: parted Version: 1.7.1-2 Severity: important I'm running Debian 3.1/AMD64 on Kernel 2.6.18.3 with a 2 TB fibrechannel-connected external RAID controller. The kernel is a custom build and includes EFI-GPT and LBD-support. ---cut sdb : very big device. try to use READ CAPACITY(16). SCSI device sdb: 10741948416 512-byte hdwr sectors (5499878 MB) sdb: Write Protect is off sdb: Mode Sense: bf 00 10 08 SCSI device sdb: drive cache: write back w/ FUA sdb: sdb1 ---cut The single partition on that device is an EFI GPT partition at the full device size with an XFS filesystem on it. The partition has been created with GNU parted as well. The RAID controller is an Overland Ultamusraid 5200, which in turn seems to be an Ario Networks OEM'd device. The controller allows array expansion, where newly added drives enable the administrator to both add a new logical device (from Linux view: new disk device; from Controller view: some kind of partition on the same RAID set) as well as expand currently existing logical devices (from Linux' point of view, your devices do become bigger). After expanding the RAID by another disk and extending the existing logical drive's capacity to the new maximum, the RAID controller simply exports a new disk size under the same LUN, so /sbin/blockdev --rereadpt /dev/sdb makes Linux rescan the new disk size: ---cut sdb : very big device. try to use READ CAPACITY(16). SCSI device sdb: 11716890624 512-byte hdwr sectors (5999048 MB) sdb: Write Protect is off sdb: Mode Sense: bf 00 10 08 SCSI device sdb: drive cache: write back w/ FUA sdb: sdb1 ---cut The new device is about 0.5 TB larger. EFI GPT contains a backup of the partiton table at the end of the disk, obviously now that space has become empty. I think that similar situation (at least for parted) can also be reproduced via standard Linux LVM (lvcreate some logical volume, create a EFI-GPT-partition on it via parted, lvextend the logical volume, re-run parted). I know that the partitioned LVM device is likely unusable for you, but it should work for parted and reproduce this bug. parted from sarge, 1.6.21-1: ---cut anders1:~# parted /dev/sdb GNU Parted 1.6.21 with HFS shrink patch 16 Copyright (C) 1998 - 2004 Free Software Foundation, Inc. This program is free software, covered by the GNU General Public License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Using /dev/sdb (parted) p Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Cancel? fix Segmentation fault anders1:~# dmesg [...] program parted is using a deprecated SCSI ioctl, please convert it to SG_IO parted[20231]: segfault at rip 2b09224c28f2 rsp 7fff88c681b8 error 4 program parted is using a deprecated SCSI ioctl, please convert it to SG_IO parted[20233]: segfault at rip 2ad2333758f2 rsp 7fff77db72f8 error 4 ---cut parted 1.7.1-2, backported to sarge: ---cut anders1:~# parted /dev/sdb GNU Parted 1.7.1 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Cancel? fix You found a bug in GNU Parted! Here's what you have to do: Don't panic! The bug has most likely not affected any of your data. Help us to fix this bug by doing the following: Check whether the bug has already been fixed by checking the last version of GNU Parted that you can find at: http://ftp.gnu.org/gnu/parted/ Please check this version prior to bug reporting. If this has not been fixed yet or if you don't know how to check, please visit the GNU Parted website: http://www.gnu.org/software/parted for further information. Your report should contain the version of this release (1.7.1) along with the error message below, the output of parted DEVICE unit co print unit s print and additional information about your setup you consider important. Assertion (n 0) at ../../libparted/exception.c:112 in function ped_log2() failed. Ignore/Cancel? c You found a bug in GNU Parted! Here's what you have to do: [...] and additional information about your setup you consider important.
Bug#360116: a2ps should depend on file
Package: a2ps Version: 4.13b-4.3 /etc/a2ps.cfg used FileCommand: /usr/bin/file -L to check what kind of file is being printed, but a2ps doesn't have a dependency on the file package. Regards, Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360119: a2ps-lpr-wrapper should include support for the rlpr package
Package: a2ps Version: 4.13b-4.3 Tags: patch /usr/bin/a2ps-lpr-wrapper tries to guess wether /usr/bin/lp or /usr/bin/lpr are to be used. However, I'm a big fan of the rlpr package, which installs /usr/bin/rlpr with a 100% compatible interface to lpr, but doesn't require one to run a local queue with a lpr daemon. Proposed patch to include support: ---cut --- /usr/bin/a2ps-lpr-wrapper 2005-01-20 22:47:16.0 +0100 +++ /tmp/a2ps-lpr-wrapper 2006-03-30 19:32:40.820765000 +0200 @@ -5,8 +5,15 @@ # If /usr/bin/lp (from cupsys-client) exists, just use it. if [ -x /usr/bin/lp ]; then - /usr/bin/lp $* -else + /usr/bin/lp $@ +elsif [ -x /usr/bin/lpr ] # In case /usr/bin/lp is not available, then fall back /usr/bin/lpr. - /usr/bin/lpr $* + /usr/bin/lpr $@ +elsif [ -x /usr/bin/rlpr ] + # In case /usr/bin/lpr is not available, then fall back /usr/bin/rlpr. + /usr/bin/rlpr $@ +else + # If lp,lpr and rlpr are not available, fail + echo $0: lp/lpr/rlpr missing! + exit 1 fi ---cut Regards, Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316074: email-adress from initial configure isn't written to config file
Package: apticron Version: 1.1.12 During the first (fresh) install of apticron, the configure script asks for an email adress to report pending updates to. No matter what I'm telling it, apticron won't take it into its configfile at that time. After the install has finished, I can manually run 'dpkg-reconfigure apticron' and the email-adress given then is correctly imported into /etc/apticron/apticron.conf. Source of the problem lies in /var/lib/dpkg/info/apticron.config: ---cut db_get apticron/notification || true if [ -e /etc/apticron/apticron.conf ] ; then sed -e s/^EMAIL=.*/EMAIL=\$RET\/ /etc/apticron/apticron.conf /etc/apticron/apticron.conf.new mv -f /etc/apticron/apticron.conf.new /etc/apticron/apticron.conf fi ---cut During the initial install, there is no /etc/apticron/apticron.conf yet, so the db_get asks for an email-adress, but doesn't use it then. Regards, Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316101: add random wait to prevent mirror overload
Package: apticron Version: 1.1.12 Severity: wishlist Basically I'd like to have the feature in apticron which cron-apt currently offers to prevent mirror-overloading; in short, it can be described as sleep(rand(3600));. Like cron-apt, apticron is also run via cron. If you're running dozens of servers (or take a look at debian worldwide), all those servers are about to hammer on your local debian mirror on 6:25am - to prevent such a situation, cron-apt has a feature which delays the check a random amount of seconds, but limits this to an hour. Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316101: add random wait to prevent mirror overload
Am 28.06.2005 schrieb Colm MacCarthaigh: On Tue, Jun 28, 2005 at 02:46:18PM +0200, Anders Henke wrote: Package: apticron Version: 1.1.12 Severity: wishlist [...] So, instead what I'd like to propose is that at install time, I'll have the install scripts do a one-time calculation of some random numbers and produce an /etc/cron.d/apticron file. Ie: rand(60) rand(24) * * * test -x /usr/sbin/apticron /usr/sbin/apticron Since those random numbers are calculated only once, at install time, the update will be scheduled for the same time every day. However accross a large number of servers, there should still be a good even distribution of requests. Would this be o.k.? For me: certainly; well, most :) We're setting up our servers by extracting a pre-configured tarball onto a freshly partitioned and mkfs'd disk. Of course, we might change our installations procedures in a way to re-calculate those random numbers automatically,but I'd rather like to avoid that (as there are already too many things to alter after extracting the tarball). But on the other hand, as there are already so many things which require a change ... Any problems I'm not seeing? You're likely to receive tons of bug reports make apticron run in the night, as most people assume that some regular maintenance is being done during the night and has to be completed in the morning. Maybe there are also other people who don't wish to have any maintenance jobs in the night (e.g. typical bedroom servers). I think that adding both explaining texts as well as a good sample of choices to such a configure dialogue would be a good idea: Apticron automatically runs once a day. You shouldn't run apticron e.g. at midnight, as at such prominent times there are already too many tools who wish to do so and in turn create load peaks on mirror sites. So it's usually a good idea to let apticron choose the time when to check packages for you. You can choose from either anytime, during the night or manually choose when to run apticron. Please tell apticron when to run: (*) anytime ( ) during the night (midnight to 6 AM) ( ) manually enter hour and minute to run on Of course, the second option would take the hour from rand(6) and help those ones who do regularly schedule all cronjobs for @midnight even they only need the results at 9 AM :-) Like cron-apt, apticron is also run via cron. If you're running dozens of servers (or take a look at debian worldwide), all those servers are about to hammer on your local debian mirror on 6:25am - to prevent such a situation, cron-apt has a feature which delays the check a random amount of seconds, but limits this to an hour. I run ftp.ie.debian.org, I know all about the peaks from such things :) It's not a huge problem (we certainly don't have any issues from it) - but it is still worth fixing and to be honest, it's a bug rather than a wishlist item. If it's a bug for apticron, there are far more packages where this is also supposed to be a bug. Thanks for this, and your other bug report. I'll get on em! Thank you for so actively maintaining your package :-) Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315063: clamav-freshclam: logrotate fails when freshclam is not running as daemon
Package: clamav-freshclam Version: 0.84-2 No, this is no dupe to #315042 :-) The postrotate script in /etc/logrotate.d/clamav-freshclam contains a line [ -f /var/run/clamav/freshclam.pid ] kill -HUP `cat /var/run/clamav/freshclam.pid` Well, if the test -f -command fails, it returns a non-zero exit status and logrotate will report an error running postrotate script. Others might prefer to add || /bin/true, but a more creative solution is to negate the script: [ ! -f /var/run/clamav/freshclam.pid ] || kill -HUP `cat /var/run/clamav/freshclam.pid` That way freshclam is only HUPed if the test fails - which either means that the test command is broken or the pid-file does exist. Regards, Anders -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.28-grsec Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages clamav-freshclam depends on: ii clamav-base 0.84-2 base package for clamav, an anti-v ii debconf [debconf-2.0] 1.4.30.13Debian configuration management sy ii debianutils 2.8.4Miscellaneous utilities specific t ii libbz2-1.0 1.0.2-7 high-quality block-sorting file co ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libclamav1 0.85.1-2 virus scanner library ii libcurl37.13.2-2 Multi-protocol file transfer libra ii libgmp3 4.1.4-6 Multiprecision arithmetic library ii libidn110.5.13-1.0 GNU libidn library, implementation ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii logrotate 3.7-5Log rotation utility ii ucf 1.17 Update Configuration File: preserv ii zlib1g 1:1.2.2-4compression library - runtime -- debconf information: * clamav-freshclam/autoupdate_freshclam: cron clamav-freshclam/proxy_user: * clamav-freshclam/NotifyClamd: true * clamav-freshclam/local_mirror: db.de.clamav.net (Germany) * clamav-freshclam/http_proxy: clamav-freshclam/mirrors.txt-note: * clamav-freshclam/update_interval: 24 clamav-freshclam/internet_interface: -- Schlund + Partner AG Systemadministration Brauerstrasse 48 v://49.721.91374.50 D-76135 Karlsruhe f://49.721.91374.225 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
