Bug#800052: How can I help with zulip-server packaging?
Hi Luke, is there any WIP packaging for your WNPP zulip-server? How can I help? -john
Bug#788539: [PATCH] Find Python module dependencies
Thanks for packaging caffe for Debian!
I noticed that python-caffe-* didn't have their Python module dependencies
listed.
The attached patch (which I tested on Ubutnu 14.04, but should be relevant
to Debian unstable, the latest debhelper, etc.) fixes dependency
autodetection.
-john
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -93,8 +93,8 @@ ifeq (y, $(flag_build_caffe_cuda))
-- runtest LD_LIBRARY_PATH=${CAFFE_CUDA_BUILDDIR}/lib/
endif
-override_dh_pysupport:
- dh_python2
+override_dh_python2:
+ dh_python2 --requires=python/requirements.txt
override_dh_auto_install:
dh_auto_install --builddirectory=${CAFFE_CPU_BUILDDIR} \
Bug#782675: mutt: always complains "No news server defined!" when moving to inbox view
Package: mutt Version: 1.5.23-3 Severity: important If I view a message (pager view) and hit 'i' to return to the inbox view, I get this message, and mutt pauses for a second or two: No news server defined! I don't have any news servers defined in my mailbox list, or anywhere in my muttrc (I've never used its NNTP support). My muttrc is at: https://raw.githubusercontent.com/jwm/homedir/master/.muttrc Building without mutt-patched/nntp.patch works around it. -- Package-specific info: Mutt 1.5.23 (2014-03-12) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.16.0-4-amd64 (x86_64) ncurses: ncurses 5.9.20140913 (compiled with 5.9) libidn: 1.29 (compiled with 1.29) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-4) Configure options: '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' '--with-mailpath=/var/mail' '--disable-dependency-tracking' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' '--enable-nntp' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm' Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_NNTP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode.patch features/ifdef.patch features/xtitles.patch features/trash-folder.patch features/purge-message.patch features/imap_fast_trash.patch features/sensible_browser_position.patch features-old/patch-1.5.4.vk.pgp_verbose_mime.patch features/compressed-folders.patch features/compressed-folders.debian.patch debian-specific/Muttrc.patch debian-specific/Md.etc_mailname_gethostbyname.patch debian-specific/use_usr_bin_editor.patch debian-specific/correct_docdir_in_man_page.patch debian-specific/dont_document_not_present_features.patch debian-specific/document_debian_defaults.patch debian-specific/assumed_charset-compat.patch debian-specific/467432-write_bcc.patch debian-specific/566076-build_doc_adjustments.patch misc/define-pgp_getkeys_command.patch misc/gpg.rc-paths.patch misc/smime.rc.patch misc/fix-configure-test-operator.patch upstream/531430-imapuser.patch upstream/543467-thread-segfault.patch upstream/542817-smimekeys-tmpdir.patch upstream/548577-gpgme-
Bug#711147: lvm2 still doesn't active volume group at boot time
On Tue, Apr 01, 2014 at 01:03:24PM +0200, Bjoern Buerger wrote: > For the second time since mid-2013, I got hit by the "lvm2 still doesn't > active volume group at boot time" bug: > > lvm2 version is 2.02.104-2 in both cases. FWIW, I experienced this with a freshly installed wheezy system this week. I used the latest wheezy netinst image to install a single LV to a micro-SD card, and the resulting system had lvm2 2.02.95-8. When the system boots, the VG and LV are present, but not active. Making a change similar to Bjoern's (I needed to sleep for a few seconds before activating the VG, not after) allows the system to boot without manual intervention. -john -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544898: #544898 still applies to freeradius-client
reopen 544898 package freeradius-client found 544898 1.1.6-7 tags 544898 + patch thanks Just looked at the freeradius-client packaging. As far as I tell, this bug still applies to the new package. -john -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721451: O: nagircbot -- IRC bot that announces Nagios status
Package: wnpp Severity: normal I'm orphaning the nagircbot package. There are plenty of (IMO) better and more actively maintained alternatives now, like hubot+hubot-irc (MIT license) or Bot::BasicBot::Pluggable::Module::Nagios (GPL), and popcon stats for this package are in the single digits. The package description is: An IRC (Internet Relay Chat) bot that reads Nagios' status information and emits alerts to an IRC channel. It can filter alerts based on severity (CRITICAL, HARD, SOFT, and/or UNKNOWN) or by regular expression. It can connect to IRC servers protected by password or SSL, and can optionally set the topic to the current Nagios status. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666843: libapache2-mod-ldap-userdir: diff for NMU version 1.1.19-2.1
On Wed, Jul 10, 2013 at 09:44:16PM +0100, Colin Watson wrote: > I've prepared an NMU for libapache2-mod-ldap-userdir (versioned as > 1.1.19-2.1) and uploaded it to DELAYED/2. Please feel free to tell me > if I should delay it longer. Thanks, Colin. I haven't had a chance to look over this package for the transition. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712929: ganglia-monitor: please add status target to init script
Package: ganglia-monitor
Version: 3.6.0-1
Severity: minor
Would you please add a status target to the ganglia init scripts (patch
attached)? Tools like Puppet assume init scripts provide a status target,
or they try to start the daemon every time they're run.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ganglia-monitor depends on:
ii adduser 3.113+nmu3
ii libapr1 1.4.6-4
ii libc62.17-5
ii libconfuse0 2.7-4
ii libexpat12.1.0-3
ii libganglia1 3.6.0-1
ii libpcre3 1:8.31-2
ii zlib1g 1:1.2.8.dfsg-1
ganglia-monitor recommends no packages.
ganglia-monitor suggests no packages.
-- Configuration Files:
/etc/init.d/ganglia-monitor changed [not included]
-- no debconf information
diff --git a/debian/ganglia-monitor.init b/debian/ganglia-monitor.init
index e6c7cc9..657aaa3 100644
--- a/debian/ganglia-monitor.init
+++ b/debian/ganglia-monitor.init
@@ -34,6 +34,9 @@ case "$1" in
$0 stop
$0 start
;;
+ status)
+ status_of_proc "$DAEMON" "$NAME"
+ ;;
*)
N=/etc/init.d/$NAME
# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
diff --git a/debian/gmetad.init b/debian/gmetad.init
index 1d3ef5b..811cf0d 100644
--- a/debian/gmetad.init
+++ b/debian/gmetad.init
@@ -34,6 +34,9 @@ case "$1" in
$0 stop
$0 start
;;
+ status)
+ status_of_proc "$DAEMON" "$NAME"
+ ;;
*)
N=/etc/init.d/$NAME
# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
Bug#680137: [Pkg-openssl-devel] Bug#680137: irssi: Can't connect to SSL-enabled server after upgrading libssl
On Sun, Apr 07, 2013 at 12:44:22AM +0200, Kurt Roeckx wrote: > On Sat, Apr 06, 2013 at 06:25:42PM -0400, John Morrissey wrote: > > On Sat, Apr 06, 2013 at 09:07:50PM +0200, Kurt Roeckx wrote: > > > On Sat, Apr 06, 2013 at 01:47:51PM -0400, John Morrissey wrote: > > > > On Fri, Jan 11, 2013 at 03:10:32PM +0100, Clement Hermann (nodens) > > > > wrote: > > > > > With some more test and some help from a friend, we made some > > > > > progress. > > > > > > > > > > It *does* work when adding -no_tls1_1 option to openssl s_client. > > > > > > > > > > It works if the server allows renegociation : I can connect to > > > > > freenode. > > > > > > > > > > It seems to be #665452 again, or a variant. > > > > > > > > > > Anyway, that explains why it works in ubuntu. The patch > > > > > tls12_workarounds.patch (attached) works around it (but I'm not > > > > > qualified to tell whether this is an acceptable solution or not). > > > > > > > > I noticed the same thing with ircd-hybrid (rebuilt per the package's > > > > instructions to enable SSL support) after upgrading to wheezy recently. > > > > > > > > wheezy's irssi refused to connect to the ircd, which was running on the > > > > local host and linked to the same version of OpenSSL: > > > > > > > > 140308295767720:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no > > > > shared cipher:s3_srvr.c:1355: > > > > > > Can you reproduce this problem with s_client trying to connect to > > > the irc server? > > > > > > Looking at the hybrid source, it doesn't seem to contain any > > > calls to something like OpenSSL_add_all_algorithms(). My > > > guess would be that adding that call would fix the problem. > > > > Hm, I tried just now, but couldn't reproduce with s_client. However, the > > issue was still reproducible with irssi+openssl 1.0.1e. > > I tried conneting with irssi to something and that gave me a > working TLS 1.2 connection. I currently don't see irssi doing > anything wrong. > > Do you have a public irc server I can try and connect to? I dug into this a little more, and it turns out I *can't* reproduce it now, even with 1.0.1e installed. When I checked earlier today, I wasn't connecting to the ircd with the right password. I have a super low reconns interval, so the initial connection scrolled past, and subsequent connections failed with a handshake error. I'm guessing that's due to irssi's misbehavior, since when I put gdb on the ircd, it seemed to be working properly given the input irssi was sending. I got the 'no shared ciphers' error above by modifying the ircd-hybrid source to call ERR_print_errors_fp() in ssl_handshake(), so it was definitely a problem at one point. I'm not sure why I can't reproduce now. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680137: [Pkg-openssl-devel] Bug#680137: irssi: Can't connect to SSL-enabled server after upgrading libssl
On Sat, Apr 06, 2013 at 09:07:50PM +0200, Kurt Roeckx wrote: > On Sat, Apr 06, 2013 at 01:47:51PM -0400, John Morrissey wrote: > > On Fri, Jan 11, 2013 at 03:10:32PM +0100, Clement Hermann (nodens) wrote: > > > With some more test and some help from a friend, we made some progress. > > > > > > It *does* work when adding -no_tls1_1 option to openssl s_client. > > > > > > It works if the server allows renegociation : I can connect to > > > freenode. > > > > > > It seems to be #665452 again, or a variant. > > > > > > Anyway, that explains why it works in ubuntu. The patch > > > tls12_workarounds.patch (attached) works around it (but I'm not > > > qualified to tell whether this is an acceptable solution or not). > > > > I noticed the same thing with ircd-hybrid (rebuilt per the package's > > instructions to enable SSL support) after upgrading to wheezy recently. > > > > wheezy's irssi refused to connect to the ircd, which was running on the > > local host and linked to the same version of OpenSSL: > > > > 140308295767720:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no > > shared cipher:s3_srvr.c:1355: > > Can you reproduce this problem with s_client trying to connect to > the irc server? > > Looking at the hybrid source, it doesn't seem to contain any > calls to something like OpenSSL_add_all_algorithms(). My > guess would be that adding that call would fix the problem. Hm, I tried just now, but couldn't reproduce with s_client. However, the issue was still reproducible with irssi+openssl 1.0.1e. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680137: irssi: Can't connect to SSL-enabled server after upgrading libssl
On Fri, Jan 11, 2013 at 03:10:32PM +0100, Clement Hermann (nodens) wrote: > With some more test and some help from a friend, we made some progress. > > It *does* work when adding -no_tls1_1 option to openssl s_client. > > It works if the server allows renegociation : I can connect to freenode. > > It seems to be #665452 again, or a variant. > > Anyway, that explains why it works in ubuntu. The patch > tls12_workarounds.patch (attached) works around it (but I'm not > qualified to tell whether this is an acceptable solution or not). I noticed the same thing with ircd-hybrid (rebuilt per the package's instructions to enable SSL support) after upgrading to wheezy recently. wheezy's irssi refused to connect to the ircd, which was running on the local host and linked to the same version of OpenSSL: 140308295767720:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1355: After some trial an error, I realized that the cert I had been successfully using with squeeze's ircd-hybrid was part of the problem. Removing the key and cert and letting ircd-hybrid's maintainer scripts generate a default key and cert allowed irssi to connect. AFAICT the only meaningful difference between the two certs is that the non-working cert was cert format version 3 (0x2), whereas the autogenerated cert is format version 1 (0x0). Also, patching wheezy's openssl 1.0.1e-2 with Ubuntu's tls12_workarounds.patch allows the previous cert to work again. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688806: Crufty stdout fd3 comment in debconf/confmodule
Package: debconf Version: 1.5.46 Severity: minor debconf/confmodule has a crufty comment about stdout on fd3: # To actually send something to standard output, send it to fd 3. fd3 is used to send commands to the frontend, and stdout isn't carried over from the original shell script invocation, so you can't use fd3 (or stdout at all) to emit output to stdout. Originally from debconf-devel@: http://lists.alioth.debian.org/pipermail/debconf-devel/2012-August/003417.html -- Date: Tue, 28 Aug 2012 12:23:33 -0700 From: John Morrissey To: Debconf Developers Subject: Crufty stdout comment in confmodule? I was looking at /usr/share/debconf/confmodule recently, and the comment about stdout and fd 3 seems crufty. The script winds up with its write pipe to the frontend on fd 3: debconf.sh 17810 jwm0r FIFO0,8 0t0 9443796 pipe debconf.sh 17810 jwm1w CHR 136,13 0t0 16 /dev/pts/13 debconf.sh 17810 jwm2u CHR 136,13 0t0 16 /dev/pts/13 debconf.sh 17810 jwm3w FIFO0,8 0t0 9443797 pipe If I redirect stderr to a file (by invoking the shell fragment below as './debconf.sh 2>foo', for example), I see stdout is completely gone: debconf.sh 18022 jwm0r FIFO0,8 0t0 9445266 pipe debconf.sh 18022 jwm1w REG 254,6 112 1951755 /home/jwm/newbug/foo debconf.sh 18022 jwm2w REG 254,6 112 1951755 /home/jwm/newbug/foo debconf.sh 18022 jwm3w FIFO0,8 0t0 9445267 pipe The frontend starts the shell script with its two pipes on the script's fd0 and fd1, so stdout is never available to the script. john /usr/share/debconf/confmodule -- if [ -z "$DEBCONF_REDIR" ]; then # Redirect standard output to standard error. This prevents common # mistakes by making all the output of the postinst or whatever # script is using this library not be parsed as confmodule commands. # # To actually send something to standard output, send it to fd 3. exec 3>&1 if [ "$DEBCONF_USE_CDEBCONF" ]; then exec 1>&5 else exec 1>&2 fi [...] fi -- debconf.sh: -- #!/bin/sh lsof +c 12 -p $$ . /usr/share/debconf/confmodule lsof +c 12 -p $$ -- -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678694: Tagging with preseed version from wheezy d-i beta2
found 678694 1.54 thanks Looks like this is present in wheezy's d-i beta2, so tagging this with the appropriate version. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#439763: [Debconf-devel] Bug#439763: debconf: hangs on puppet installs on preseed install
On Thu, Aug 23, 2012 at 11:42:44AM +0200, Juan Carlos Moreno [ackstorm] wrote: > Oppsss, sorry! I have made a lot of changes... > > Redirecting puppet logdest is not the solution but setting > 'DEBCONF_REDIR' to empty, it works! > > This is how I call puppet, and it works for me (now): > > [..] > env = environ.copy() > env['DEBCONF_DEBUG']='developer' > env['DEBCONF_REDIR']='' > p = Popen(['puppet', 'apply', '--detailed-exitcodes', >'--debug','--apply', data_pson], > cwd=cwd, stdin=None, env=env) > stdout, stderr = p.communicate() > [..] Thanks for the info, Juan. At least for me with d-i wheezy beta1, if I only unset DEBCONF_REDIR, scripts in the chroot still try to communicate with the d-i debconf frontend (outside the chroot), and block because something seems amiss with the file descriptor manipulation. I suspect this is because DEBCONF_HAS_FRONTEND is still set, so confmodule doesn't spawn a different frontend. As a result, man-db.postinst's call to db_version emits the debconf command to stdout, where it gets caught by log-output (if I chroot my script with in-target, the same blocked postinst happens if I simply chroot my script): Aug 23 16:55:01 log-output: VERSION 2.0 And the postinst blocks on reading the unchrooted debconf frontend's response, since the frontend never got the request: root 12444 0.1 5.2 62140 26556 tty1 S+ 16:54 0:00 \_ apt-get -y install php5-cli root 12461 0.0 2.1 29580 10760 tty1 S+ 16:55 0:00 \_ /usr/bin/dpkg --status-fd 22 --unpack --auto-deconfigure /var/cache/apt/archives/php5-common_5.4.4-4_amd64.deb /var/cache/apt/archives/php5-cli_5.4.4-4_amd64.deb root 12483 0.0 0.1 4164 628 tty1 S+ 16:55 0:00 \_ /bin/sh -e /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man root@debian:/# strace -p 12483 Process 12483 attached - interrupt to quit read(0, ^C root@debian:/# lsof -p 12483 | grep 0[rwu] man-db.po 12483 root0r FIFO0,8 0t0 3215 pipe root 235 1.1 3.9 50268 20180 tty1 S+ 16:39 0:14 debconf -o d-i /usr/bin/main-menu root@debian:/# lsof -p 235 | grep 3125 debconf 235 root4w FIFO0,8 0t0 3215 pipe I also tried unsetting DEBIAN_HAS_FRONTEND, so a separate debconf frontend gets spawned in the chroot. Unfortunately, the chrooted frontend apparently can't interact with the console, since its 0 and 1 FDs are still pipes to the unchrooted debconf frontend. If I unset DEBCONF_REDIR and DEBIAN_HAS_FRONTEND, then use 'debconf-disconnect chroot /target myscript', Puppet package installations still get EBADF when trying to interact with file descriptor 3. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#439763: debconf: hangs on puppet installs on preseed install
On Tue, Dec 18, 2007 at 05:16:03PM +, Colin Watson wrote: > On Mon, Aug 27, 2007 at 10:42:41AM +0100, Adrian Bridgett wrote: > > When postfix.config runs /usr/share/debconf/confmodules, at line 45 it > > complains that FD3 is a bad file descriptor. Listing /proc/$$/fd > > shows that FD3 doesn't exist. FD2 points to the overall stderr, FD1 > > is a pipe back to FD8 of dpkg-preconfigure. FD0 is FD7 from > > dpkg-preconfigure. > > > > FD3 exists and DEBCONF_REDIR is set when ConfModule::startup() is > > called, however it looks like FD3 does not persist into the open2() > > call. > > On the other hand, it might be something completely different. I note > that both sysstat and postfix call db_stop. I don't think this should > actually break the cdebconf instance way down at the bottom of the > stack, but it's possible that it will confuse the debconf running > debconf-apt-progress. If you could run the whole install under > DEBCONF_DEBUG=developer (you did something like this earlier), then this > might shed some light on exactly which debconf frontend is seeing what > commands. [snip] > I think I'd rather figure out the underlying problem. It may be that we > need to ignore db_stop in some circumstances. I came across this with d-i wheezy beta1. I have a late_command that runs Puppet in /target, and most package installations were failing due to EBADF on fd3, mostly when handling man-db triggers. man-db.postinst fails when the first db_* tries to write to fd3. Adding an lsof to man-db.postinst shows that fd3 isn't present. I can reproduce with something as simple as 'chroot /target apt-get -y install php5-cli' in late_command. I've posted the d-i syslog with DEBCONF_DEBUG=developer, late_command, and env/lsof/strace output at http://horde.net/~jwm/debian/bug439763/ . Could someone more knowledgable about debconf internals take a look at this, please? I'm happy to help debug further, but I'm at a loss on how to continue. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678694: preseed_fetch absolute paths broken when preseed/include isn't used
I noticed the same behavior with the 7.0beta1 d-i snapshot.
preseed_location() only sets /var/run/preseed.last_location for
preseed/include files, not for the original (main) preseed file.
make_absolute_url() in bin/preseed_fetch prepends a null value and returns
"/./path/being/fetched".
The attached patch writes preseed.last_location for the main preseed file,
as well.
john
--
John Morrissey _o/\ __o
j...@horde.net_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
>From 05037bd5f57277dd7c05943e81b0b12809dd4c84 Mon Sep 17 00:00:00 2001
From: John Morrissey
Date: Fri, 17 Aug 2012 11:08:21 -0700
Subject: [PATCH] always set /var/run/preseed.last_location, not just for includes
---
preseed.sh |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/preseed.sh b/preseed.sh
index f5225c4..76dd2c9 100644
--- a/preseed.sh
+++ b/preseed.sh
@@ -69,6 +69,7 @@ preseed_location () {
log "successfully loaded preseed file from $location"
[ -e /var/run/delay_choosers ] && rm /var/run/delay_choosers
local last_location="$location"
+ echo $last_location > /var/run/preseed.last_location
while true ; do
db_get preseed/include
--
1.7.2.5
Bug#483971: Patch for squeeze: grub2 support for multipath
found 483971 1.98+20100804-14
fixed 483971 1.99-12
thanks
grub2 1.99-12 (from sid) works fine, but I ran into this upgrading our
multipathed lenny machines to squeeze. Attached is the patch from #442382
that fixes this, updated for squeeze's grub2 (1.98+20100804-14).
FWIW, unmodified 1.98+20100804-14 on squeeze fails with:
[j...@syslog01.roch.ny:pts/4 ~> sudo dpkg-reconfigure grub-pc
Generating core.img
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/mapper/rootvol-part1 failed.
Please report this together with the output of "/usr/sbin/grub-probe
--device-map=/boot/grub/device.map --target=fs -v /boot/grub" to
john
--
John Morrissey _o/\ __o
j...@horde.net_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
Index: grub2-1.98+20100804/include/grub/emu/getroot.h
===
--- grub2-1.98+20100804.orig/include/grub/emu/getroot.h 2010-06-02 23:13:14.0 +
+++ grub2-1.98+20100804/include/grub/emu/getroot.h 2011-09-11 00:23:17.522687000 +
@@ -19,12 +19,15 @@
#ifndef GRUB_UTIL_GETROOT_HEADER
#define GRUB_UTIL_GETROOT_HEADER 1
+#include
+
enum grub_dev_abstraction_types {
GRUB_DEV_ABSTRACTION_NONE,
GRUB_DEV_ABSTRACTION_LVM,
GRUB_DEV_ABSTRACTION_RAID,
};
+char *find_root_device (const char *dir, dev_t dev);
char *grub_guess_root_device (const char *dir);
int grub_util_get_dev_abstraction (const char *os_dev);
char *grub_util_get_grub_dev (const char *os_dev);
Index: grub2-1.98+20100804/kern/emu/getroot.c
===
--- grub2-1.98+20100804.orig/kern/emu/getroot.c 2011-09-11 00:23:08.292457000 +
+++ grub2-1.98+20100804/kern/emu/getroot.c 2011-09-11 00:23:08.909378000 +
@@ -32,6 +32,10 @@
#include
#include
+#ifdef HAVE_DEVICE_MAPPER
+# include
+#endif
+
#ifdef __GNU__
#include
#include
@@ -242,7 +246,7 @@
#elif ! defined(__CYGWIN__)
-static char *
+char *
find_root_device (const char *dir, dev_t dev)
{
DIR *dp;
@@ -547,32 +551,66 @@
}
static int
-grub_util_is_dmraid (const char *os_dev)
+grub_util_is_lvm (const char *os_dev)
{
- if (! strncmp (os_dev, "/dev/mapper/nvidia_", 19))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/isw_", 16))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/hpt37x_", 19))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/hpt45x_", 19))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/via_", 16))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/lsi_", 16))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/pdc_", 16))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/jmicron_", 20))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/asr_", 16))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/sil_", 16))
-return 1;
- else if (! strncmp (os_dev, "/dev/mapper/ddf1_", 17))
-return 1;
+ if ((strncmp ("/dev/mapper/", os_dev, 12) != 0))
+return 0;
+
+#ifdef HAVE_DEVICE_MAPPER
+ {
+struct dm_tree *tree;
+uint32_t maj, min;
+struct dm_tree_node *node = NULL, *child;
+void *handle;
+const char *node_uuid, *mapper_name = NULL, *child_uuid, *child_name;
+struct stat st;
- return 0;
+if (stat (os_dev, &st) < 0)
+ return 0;
+
+tree = dm_tree_create ();
+if (! tree)
+ {
+ grub_printf ("Failed to create tree\n");
+ grub_dprintf ("hostdisk", "dm_tree_create failed\n");
+ return 0;
+ }
+
+maj = major (st.st_rdev);
+min = minor (st.st_rdev);
+
+if (! dm_tree_add_dev (tree, maj, min))
+ {
+ grub_dprintf ("hostdisk", "dm_tree_add_dev failed\n");
+ dm_tree_free (tree);
+ return 0;
+ }
+
+node = dm_tree_find_node (tree, maj, min);
+if (! node)
+ {
+ grub_dprintf ("hostdisk", "dm_tree_find_node failed\n");
+ dm_tree_free (tree);
+ return 0;
+ }
+node_uuid = dm_tree_node_get_uuid (node);
+if (! node_uuid)
+ {
+ grub_dprintf ("hostdisk", "%s has no DM uuid\n", os_dev);
+ dm_tree_free (tree);
+ return 0;
+ }
+if (strncmp (node_uuid, "LVM-", 4) != 0)
+ {
+ dm_tree_free (tree);
+ return 0;
+ }
+dm_tree_free (tree);
+return 1;
+ }
+#else
+ return 1;
+#endif /* HAVE_DEVICE_MAPPER */
}
int
@@ -580,9 +618,7 @@
{
#ifdef __linux__
/* Check for LVM. */
- if (!strncmp (os_dev, "/dev/mapper/", 12)
- && ! grub_util_is_dmraid (os_dev)
- && strncmp (os_dev, "/dev/mapper/mpath", 17) != 0)
+ if (grub_util_is_lvm (os_dev))
return GRUB_DEV_ABSTRACTION_LVM;
/* Check for RA
Bug#607720: [PATCH] Fix for extra show_bug path output
tags 607720 + patch
thanks
50patchtemplatefordebian shouldn't be adding the debian_webpath tag to
bug/show-header.html.tmpl, since that template just sets javascript_urls,
which are then emitted by global/header.html.tmpl with debian_webpath
already prepended.
I'm guessing the regex in 50patchtemplatefordebian didn't match
bug/show-header.html.tmpl in the past, and changes in a newer upstream
version caused it to start matching accidentally.
Attached is a patch against the bugzilla3 packaging in sid.
john
--
John Morrissey _o/\ __o
j...@horde.net_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
--- ./debian/pre-checksetup.d/50patchtemplatefordebian~ 2010-11-15 03:47:40.0 -0500
+++ ./debian/pre-checksetup.d/50patchtemplatefordebian 2011-04-09 11:19:05.0 -0400
@@ -12,10 +12,10 @@
debian_webpath="[% Locations('debian_webpath') %]"
for f in `find "$BUGZILLA_TEMPLATEDIR" -type f -name "*.tmpl" 2>/dev/null`; do
- if ! grep -q " Locations('debian_webpath') " "$f" && grep -q "=\"skins/\|\[% \"skins/\|\[% style_url[\.[:space:]]\|\[% javascript_url\|\[% atomlink\|\[% Param('urlbase') " "$f"; then
+ if ! grep -q " Locations('debian_webpath') " "$f" && grep -q "=\"skins/\|\[% \"skins/\|\[% style_url[\.[:space:]]\|=\"\[% javascript_url\|\[% atomlink\|\[% Param('urlbase') " "$f"; then
sed -e "s,\[% Param('urlbase') %\]bugzilla.dtd,${debian_webpath}bugzilla.dtd,g" \
-e "s,\(.\+\)\(\[% style_url[\.[:space:]]\),\1${debian_webpath}\2,g" \
- -e "s,\(\[% javascript_url\),${debian_webpath}\1,g" \
+ -e "s,\(=\"\[% javascript_url\),${debian_webpath}\1,g" \
-e "s,=\"skins/,=\"${debian_webpath}skins/,g" \
-e "s,\[% \"skins,${debian_webpath}[% \"skins,g" \
-e "s,\(\[% atomlink\),${debian_webpath}\1,g" \
Bug#618525: please add p.d.o and .dsc links for more suites
Package: qa.debian.org Severity: wishlist Tags: patch .dsc and p.d.o links for more/all suites would be useful. The attached patch: - adds .dsc links for security, -p-u, and the new -updates. - adds p.d.o links for security updates (p.d.o doesn't seem to have -p-u and -updates data) - removes volatile support in the stylesheet (afaict, it was never added to generate_html.sh nor sources_to_xml.py so this was cruft) I'm not a DD so I didn't have a straightforward way to test parts of this; hopefully I haven't missed anything serious and it's a reasonable start. <<< text/html; charset="us-ascii": Unrecognized >>>
Bug#546481: nagircbot packaging ready
I have packaging ready for nagircbot. It's lintian-clean and builds cleanly in a pbuilder chroot. Martijn, would you be willing to sponsor my uploads for this package? If you don't have the time right now, I could try asking the Nagios packaging team, too. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600858: add netstat(8) support for RcvbufErrors, SndbufErrors
Package: net-tools
Version: 1.60-23
Severity: normal
Tags: patch
netstat(8) doesn't have support for /proc/net/snmp's {Rcv,Snd}bufErrors.
This causes the value to be treated as signed, with negative numbers emitted
for large values:
Udp:
499161083 packets received
3258712 packets to unknown port received.
3310376146 packet receive errors
268245155 packets sent
RcvbufErrors: -984591164
I originally reported this upstream, at
https://developer.berlios.de/bugs/?func=detailbug&bug_id=17645&group_id=4537
This is similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561161,
but is a different bug.
--- statistics.c.orig 2010-10-20 16:28:01.47532 +
+++ statistics.c 2010-10-20 16:39:10.42747 +
@@ -137,6 +137,8 @@
{"NoPorts", N_("%u packets to unknown port received."), number},
{"InErrors", N_("%u packet receive errors"), number},
{"OutDatagrams", N_("%u packets sent"), number},
+{"RcvbufErrors", N_("%u receive buffer errors"), number},
+{"SndbufErrors", N_("%u send buffer errors"), number},
};
struct entry Tcpexttab[] =
Bug#483930: MASQUERADE_AS() is useless unless it comes after FEATURE(nullclient)
Package: sendmail-base
Version: 8.14.3-5+lenny1
Followup-For: Bug #483930
sendmailconfig(8) sets MASQUERADE_AS() on the mail name, but
FEATURE(nullclient) overrides the masquerade hostname by declaring
MASQUERADE_AS() itself.
It seems better to set MASQUERADE_AS() *after* FEATURE(nullclient), which
causes sendmail to masquerade as sendmailconfig(8) states.
--
input "Null client forward host" nullclient NONE;
if [ ! -z "$nullclient" ]; then
echo "EXPOSED_USER(root uucp)dnl # users exempt from masquerading" >&3;
echo "LOCAL_USER(root)dnl" >&3;
echo "MASQUERADE_AS(\`$mailname')dnl" >&3;
echo "FEATURE(\`allmasquerade')dnl" >&3;
echo "FEATURE(\`masquerade_envelope')dnl" >&3;
echo "FEATURE(\`nullclient', $nullclient)dnl" >&3;
fi;
--
-- Package-specific info:
Ouput of /usr/share/bug/sendmail-base/script:
ls -alR /etc/mail:
/etc/mail:
total 280
drwxr-sr-x 7 smmta smmsp 4096 2010-10-04 17:25 .
drwxr-xr-x 108 root root 12288 2010-10-04 17:20 ..
-rwxr-xr-- 1 root smmsp 10022 2010-10-04 17:25 Makefile
-rw--- 1 root root 4261 2010-10-04 17:20 access
-rw-r- 1 smmta smmsp 12288 2010-10-04 17:20 access.db
-rw-r--r-- 1 root root281 2008-07-15 22:30 address.resolve
lrwxrwxrwx 1 root smmsp10 2009-12-23 14:14 aliases -> ../aliases
-rw-r- 1 smmta smmsp 12288 2009-12-23 14:14 aliases.db
-rw-r--r-- 1 root smmsp 130 2010-10-04 17:09 authinfo
-rw-r- 1 smmta smmsp 12288 2010-10-04 17:09 authinfo.db
-rw-r--r-- 1 root smmsp 3246 2010-10-04 17:25 databases
-rw-r--r-- 1 root root 5657 2008-07-15 22:31 helpfile
-rw-r--r-- 1 root smmsp41 2009-12-23 14:14 local-host-names
drwxr-sr-x 2 smmta smmsp 4096 2009-12-23 14:14 m4
drwxr-xr-x 2 root root 4096 2010-02-02 18:43 peers
drwxr-xr-x 2 root smmsp 4096 2008-07-15 22:29 sasl
-rw-r--r-- 1 root smmsp 64957 2010-10-04 17:25 sendmail.cf
-rw-r--r-- 1 root smmsp 442 2010-10-04 17:25 sendmail.cf.errors
-rw-r--r-- 1 root root 12236 2010-10-04 17:20 sendmail.conf
-rw-r--r-- 1 root smmsp 4333 2010-10-04 17:29 sendmail.mc
-rw-r--r-- 1 root smmsp 4329 2010-10-04 17:12 sendmail.mc.old
-rw-r--r-- 1 root smmsp 4333 2010-10-04 17:20 sendmail.mce
-rw-r--r-- 1 root root149 2008-07-15 22:30 service.switch
-rw-r--r-- 1 root root180 2008-07-15 22:30 service.switch-nodns
drwxr-sr-x 2 smmta smmsp 4096 2009-12-23 14:14 smrsh
-rw-r--r-- 1 root smmsp 44022 2010-10-04 17:20 submit.cf
-rw-r--r-- 1 root smmsp 2374 2010-10-04 17:20 submit.mc
drwxr-xr-x 2 smmta smmsp 4096 2009-12-23 14:14 tls
-rw-r--r-- 1 root smmsp 0 2009-12-23 14:14 trusted-users
/etc/mail/m4:
total 8
drwxr-sr-x 2 smmta smmsp 4096 2009-12-23 14:14 .
drwxr-sr-x 7 smmta smmsp 4096 2010-10-04 17:25 ..
-rw-r- 1 root smmsp0 2009-12-23 14:14 dialup.m4
-rw-r- 1 root smmsp0 2009-12-23 14:14 provider.m4
/etc/mail/peers:
total 12
drwxr-xr-x 2 root root 4096 2010-02-02 18:43 .
drwxr-sr-x 7 smmta smmsp 4096 2010-10-04 17:25 ..
-rw-r--r-- 1 root root 328 2008-07-15 22:30 provider
/etc/mail/sasl:
total 8
drwxr-xr-x 2 root smmsp 4096 2008-07-15 22:29 .
drwxr-sr-x 7 smmta smmsp 4096 2010-10-04 17:25 ..
/etc/mail/smrsh:
total 8
drwxr-sr-x 2 smmta smmsp 4096 2009-12-23 14:14 .
drwxr-sr-x 7 smmta smmsp 4096 2010-10-04 17:25 ..
lrwxrwxrwx 1 root smmsp 26 2009-12-23 14:14 mail.local ->
/usr/lib/sm.bin/mail.local
lrwxrwxrwx 1 root smmsp 17 2009-12-23 14:14 procmail -> /usr/bin/procmail
/etc/mail/tls:
total 48
drwxr-xr-x 2 smmta smmsp 4096 2009-12-23 14:14 .
drwxr-sr-x 7 smmta smmsp 4096 2010-10-04 17:25 ..
-rw-r--r-- 1 root root 7 2009-12-23 14:14 no_prompt
-rw--- 1 root root 1191 2009-12-23 14:14 sendmail-client.cfg
-rw-r--r-- 1 root smmsp 1310 2009-12-23 14:14 sendmail-client.crt
-rw--- 1 root root 1054 2009-12-23 14:14 sendmail-client.csr
-rw-r- 1 root smmsp 1675 2009-12-23 14:14 sendmail-common.key
-rw-r- 1 root smmsp 1582 2009-12-23 14:14 sendmail-common.prm
-rw--- 1 root root 1191 2009-12-23 14:14 sendmail-server.cfg
-rw-r--r-- 1 root smmsp 1310 2009-12-23 14:14 sendmail-server.crt
-rw--- 1 root root 1054 2009-12-23 14:14 sendmail-server.csr
-rwxr--r-- 1 root root 3283 2010-10-04 17:20 starttls.m4
sendmail.conf:
DAEMON_NETMODE="Static";
DAEMON_NETIF="eth0";
DAEMON_MODE="Daemon";
DAEMON_PARMS="";
DAEMON_HOSTSTATS="No";
DAEMON_MAILSTATS="No";
QUEUE_MODE="${DAEMON_MODE}";
QUEUE_INTERVAL="10m";
QUEUE_PARMS="";
MSP_MODE="Cron";
MSP_INTERVAL="20m";
MSP_PARMS="";
MSP_MAILSTATS="${DAEMON_MAILSTATS}";
MISC_PARMS="";
CRON_MAILTO="root";
CRON_PARMS="";
LOG_CMDS="No";
HANDS_OFF="No";
AGE_DATA="";
DAEMON_RUNASUSER="No";
DAEMON_STATS="${DAEMON_MAILSTATS}";
MSP_STATS="${MSP_MAILSTATS}";
sendmail.mc:
divert(-1)dnl
divert(0)dnl
define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: sendmail.mc, v 8.14.3-5+lenny1 2010-01-29 14:02:50 cowboy Exp
$')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
undefine(
Bug#597966: ITP: php-net-dns -- PEAR module to perform DNS queries without system resolver
On Fri, Sep 24, 2010 at 11:18:37PM +0200, Adam Borowski wrote: > Please, could you make it clear that this module should _not_ be used in a > vast majority of cases, ie those where the system resolver is enough? How does something like this (appended to the description) sound? This library should only be used when the system resolver library is unsuitable, such as when a specific DNS server must be queried. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597966: ITP: php-net-dns -- PEAR module to perform DNS queries without system resolver
Package: wnpp Severity: wishlist Owner: John Morrissey * Package name: php-net-dns Version : 1.0.5 * URL : http://pear.php.net/package/Net_DNS * License : PHP Programming Lang: PHP Description : PEAR module to perform DNS queries without system resolver Communicates directly with name servers to perform DNS queries, zone transfers, dynamic DNS updates, etc., bypassing the system resolver library. Makes all information in DNS responses available under an object hierarchy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597324: ITP: php-crypt-blowfish -- PEAR module to encrypt/decrypt using the Blowfish algorithm
Package: wnpp Severity: wishlist Owner: John Morrissey * Package name: php-crypt-blowfish Version : 1.1.0rc2 * URL : http://pear.php.net/package/Crypt_Blowfish * License : BSD Programming Lang: PHP Description : PEAR module to encrypt/decrypt using the Blowfish algorithm Performs Blowfish encryption in PHP without requiring the MCrypt PHP extension, although it can make use of the extension if available. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594243: please add -dbg package
Package: pdns-recursor
Version: 3.2-4
Severity: wishlist
Tags: patch
I did some source-level debugging on PowerDNS recently and thought it would
be nice if a -dbg package was available, so I added one (debdiff attached).
diff -u pdns-recursor-3.1.7/debian/rules pdns-recursor-3.1.7/debian/rules
--- pdns-recursor-3.1.7/debian/rules
+++ pdns-recursor-3.1.7/debian/rules
@@ -67,7 +67,7 @@
dh_installman -a
dh_installlogcheck -a
dh_link -a
- dh_strip -a
+ dh_strip -a --dbg-package=pdns-recursor-dbg
dh_compress -a
dh_fixperms -a
dh_installdeb -a
diff -u pdns-recursor-3.1.7/debian/control pdns-recursor-3.1.7/debian/control
--- pdns-recursor-3.1.7/debian/control
+++ pdns-recursor-3.1.7/debian/control
@@ -23,0 +24,11 @@
+Package: pdns-recursor-dbg
+Architecture: alpha amd64 i386 ia64 m68k powerpc s390 kfreebsd-i386 kfreebsd-amd64
+Depends: pdns-recursor (= ${binary:Version})
+Description: debugging symbols for PowerDNS recursor
+ PowerDNS is a versatile nameserver which supports a large number
+ of different backends ranging from simple zonefiles to relational
+ databases and load balancing/failover algorithms.
+ PowerDNS tries to emphasize speed and security.
+ .
+ This package contains debugging symbols for PowerDNS to assist in
+ debugging, such as with gdb. It is not required for normal operation.
Bug#594242: please add -dbg package
Package: pdns
Version: 2.9.22-7
Severity: wishlist
Tags: patch
I did some source-level debugging on PowerDNS recently and thought it would
be nice if a -dbg package was available, so I added one (debdiff attached).
diff -u pdns-2.9.22/debian/control pdns-2.9.22/debian/control
--- pdns-2.9.22/debian/control
+++ pdns-2.9.22/debian/control
@@ -129,0 +130,12 @@
+Package: pdns-server-dbg
+Architecture: any
+Priority: extra
+Depends: pdns-server (= ${binary:Version}), ${misc:Depends}
+Description: debugging symbols for PowerDNS
+ PowerDNS is a versatile nameserver which supports a large number
+ of different backends ranging from simple zonefiles to relational
+ databases and load balancing/failover algorithms.
+ PowerDNS tries to emphasize speed and security.
+ .
+ This package contains debugging symbols for PowerDNS to assist in
+ debugging, such as with gdb. It is not required for normal operation.
diff -u pdns-2.9.22/debian/rules pdns-2.9.22/debian/rules
--- pdns-2.9.22/debian/rules
+++ pdns-2.9.22/debian/rules
@@ -119,7 +119,7 @@
dh_installexamples -a
dh_lintian -a
dh_link -a
- dh_strip -a
+ dh_strip -a --dbg-package=pdns-server-dbg
dh_compress -a
dh_fixperms -a
chmod 755 $(CURDIR)/debian/pdns-server/etc/resolvconf/update.d/pdns
Bug#592362: please include passwd-netscape module
Package: slapd Version: 2.4.23-2 Severity: wishlist Tags: patch We use the passwd-netscape contrib module locally, so slapd can grok NS-MTA-MD5 password hashes. This debdiff adds support for building/packaging this module. The upstream Makefile isn't usable directly (the build fails due to missing include paths, plus its install target wants to build all of the other modules in that directory). Calling libtool directly from debian/rules seems like the most straightforward way to build, short of patching the upstream Makefile. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ diff -u openldap-2.4.23/debian/slapd.install openldap-2.4.23/debian/slapd.install --- openldap-2.4.23/debian/slapd.install +++ openldap-2.4.23/debian/slapd.install @@ -2,6 +2,7 @@ debian/tmp/usr/lib/slapd usr/sbin debian/tmp/usr/lib/ldap/*.so* usr/lib/ldap debian/tmp/usr/lib/ldap/*.la usr/lib/ldap +debian/tmp/usr/lib/ldap/passwd-netscape.so* usr/lib/ldap debian/tmp/usr/lib/libslapi-*.so.* usr/lib debian/ldiftopasswd usr/share/slapd debian/DB_CONFIG usr/share/slapd diff -u openldap-2.4.23/debian/rules openldap-2.4.23/debian/rules --- openldap-2.4.23/debian/rules +++ openldap-2.4.23/debian/rules @@ -104,6 +104,9 @@ $(MAKE) -C $(builddir) $(MAKEVARS) $(MAKE) -C contrib/slapd-modules/smbk5pwd $(MAKE) -C contrib/slapd-modules/autogroup + mkdir -p $(builddir)/contrib/slapd-modules/passwd + $(builddir)/libtool --mode=compile $(CC) $(CPPFLAGS) -Iinclude -Iservers/slapd -I$(builddir)/include -c contrib/slapd-modules/passwd/netscape.c -o $(builddir)/contrib/slapd-modules/passwd/passwd-netscape.o + $(builddir)/libtool --mode=link $(CC) -version-info 0:0:0 -rpath $(builddir)/libraries/libldap -module -o $(builddir)/contrib/slapd-modules/passwd/passwd-netscape.la $(builddir)/contrib/slapd-modules/passwd/passwd-netscape.lo ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) RESOLV_MULTI=off $(MAKE) -C $(builddir) test endif @@ -118,6 +121,8 @@ $(MAKE) -C $(builddir) $(MAKEVARS) install $(MAKE) -C contrib/slapd-modules/smbk5pwd install DESTDIR=$(installdir) $(MAKE) -C contrib/slapd-modules/autogroup install DESTDIR=$(installdir) + $(builddir)/libtool --mode=install cp $(builddir)/contrib/slapd-modules/passwd/passwd-netscape.la $(installdir)/usr/lib/ldap + $(builddir)/libtool --finish $(installdir)/usr/lib/ldap for F in $(installdir)/usr/lib/*.so.*.*.*; do \ if echo "$$F" | grep -q libslapi ; then \ continue; \
Bug#566312: BUG: unable to handle kernel paging request, in skb_copy_bits
On Sun, Aug 01, 2010 at 05:48:53PM -0400, Moritz Muehlenhoff wrote: > On Fri, Jan 22, 2010 at 03:36:23PM -0500, John Morrissey wrote: > > linux-image-2.6.30-2-686-bigmem=2.6.30-8 (from squeeze) made no > > difference, but linux-image-2.6.32-trunk-686-bigmem=2.6.32-5 from > > unstable has gone without a crash for over a week now. > > The next release of Debian (6.0, code name Squeeze) will be based > on 2.6.32. > > Has the 2.6.32 persisted to not show the bug in question? Yes. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576705: SIGSEGV due to NULL pointer dereference in handle_ldap_getgroups()
On Tue, Apr 06, 2010 at 06:27:00PM +0200, Arnaud Fontaine wrote: > I might be missing something though but as the code is not documented, > this is a bit hard to tell ;). On Sun, Apr 11, 2010 at 02:54:21PM +0200, Arnaud Fontaine wrote: > It's up to you ;). Anyway, I think the LDAP modules does seem to require > some care because it's a bit messy and undocumented, but maybe it's just > because the upstream author didn't have time to do so. Are you aware of > any plan of partial/complete rewrite of this bit? I can't speak for the Debian maintainer, but as upstream author of mod_ldap, I feel your comments would have been far more helpful if you stated what you felt was "messy" or "undocumented" about mod_ldap and perhaps what you felt could be done to improve the situation. Also, I feel that your comment that the code is "not documented" is incorrect. As with all ProFTPD configuration directives, mod_ldap directives are documented on the ProFTPD web site: http://proftpd.org/docs/directives/linked/config_ref_mod_ldap.html and in the ProFTPD source distribution. A number of sections in the mod_ldap source code contain comments when I felt they were important or required additional explanation. Without knowing in what specific ways you felt mod_ldap deficient, I can't offer any suggestions or implement any improvements. As stated in the README included with ProFTPD and mod_ldap (README.LDAP and README, respectively): -- If you're using mod_ldap successfully, are having problems getting mod_ldap up and running at your site, or have some code improvements or ideas for development, please let me know! -- In that spirit, I would appreciate any specific and constructive suggestions you have for improving mod_ldap. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#584151: HAVE_LT_DLADVISE_INIT definition adds implicit dependency on libltdl 2.2+
Package: freeradius Version: 2.1.9+dfsg-1 Severity: normal Unconditionally defining HAVE_LT_DLADVISE_INIT adds an implicit dependency on libtool 2.2 or newer, since earlier versions don't have lt_dladvise_init(). Both squeeze and sid have libtool 2.2.6, but lenny doesn't. It's straightforward to backport to the older libtool (just remove lt_dladvise.diff), but it'd be nice to have the backport be a simple rebuild. If you don't fancy adding an autoconf check for lt_dladvise_init(), would you please make the build dependency on libtool versioned, instead? thanks, john modules.c: In function 'fr_dlopenext': modules.c:218: error: 'lt_dladvise' undeclared (first use in this function) modules.c:218: error: (Each undeclared identifier is reported only once modules.c:218: error: for each function it appears in.) modules.c:218: error: expected ';' before 'advise' modules.c:220: warning: implicit declaration of function 'lt_dladvise_init' modules.c:220: warning: nested extern declaration of 'lt_dladvise_init' modules.c:220: error: 'advise' undeclared (first use in this function) modules.c:221: warning: implicit declaration of function 'lt_dladvise_ext' modules.c:221: warning: nested extern declaration of 'lt_dladvise_ext' modules.c:222: warning: implicit declaration of function 'lt_dladvise_global' modules.c:222: warning: nested extern declaration of 'lt_dladvise_global' modules.c:223: warning: implicit declaration of function 'lt_dlopenadvise' modules.c:223: warning: nested extern declaration of 'lt_dlopenadvise' modules.c:223: warning: assignment makes pointer from integer without a cast modules.c:226: warning: implicit declaration of function 'lt_dladvise_destroy' modules.c:226: warning: nested extern declaration of 'lt_dladvise_destroy' modules.c: In function 'setup_modules': modules.c:1360: warning: nested extern declaration of 'lt_preloaded_symbols' make[5]: *** [modules.lo] Error 1 -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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#582434: qemu-kvm: VNC console does not accept keyboard input once PXELinux loads during PXE boot
On Fri, May 21, 2010 at 02:21:33AM +0400, Michael Tokarev wrote: > I never had any problems with network at that place, and I always use > pxelinux boot menu to choose the thing to run on the diskless (kvm) > workstation, and edit kernel command line while in pxelinux. > > I used all supported network adaptors, and I re-verified it again before > replying - it all works for me. For pxelinux, we've been running: # lenny PXELINUX 3.71 Debian-2008-09-06 Copyright (C) 1994-2008 H. Peter Anvin # Ubuntu lucid PXELINUX 3.63 Debian-2008-07-15 On a whim, I just now tried: # squeeze/sid PXELINUX 3.86 debian-20100418 Copyright (C) 1994-2010 H. Peter Anvin et al and this seems to have fixed it. I looked over the syslinux Debian and upstream changelogs, but nothing jumps out at me. Our other hosts run KVM 85 or qemu-kvm 0.11.1+dfsg-1. They had been fine with pxelinux 3.63 or 3.71 (we PXE boot nearly all our new VMs for OS installation). FWIW, they also seem to be fine with 3.86. > 20.05.2010 22:20, Matthew Ernisse wrote: > >We are using the following version of libvirt > >ii libvirt-bin 0.8.1-1 > >ii libvirt0 0.8.1-1 > > > >the XML for this domains is as follows: > > Um. How this translates into kvm command line please? Sorry. It winds up being (switched to pcnet to avoid e1000): /usr/bin/kvm -S -M pc-0.11 -enable-kvm -m 1024 \ -smp 1,sockets=1,cores=1,threads=1 -name d-i.lab.isis \ -uuid b3ae7b86-d390-e563-bba9-4a1cd9966480 -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/d-i.lab.isis.monitor,server,nowait \ -mon chardev=monitor,mode=readline -rtc base=utc \ -boot n -drive file=/var/lib/libvirt/images/d-i.lab.isis.raw,if=none,id=drive-ide0-0-0 \ -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ -device pcnet,vlan=0,id=net0,mac=02:00:00:60:a7:70,bus=pci.0,addr=0x4 \ -net tap,fd=29,vlan=0,name=hostnet0 -chardev pty,id=serial0 \ -device isa-serial,chardev=serial0 -usb -vnc 0.0.0.0:12 \ -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 > Does the problem occurs with other network cards? It happened with the three we tried: e1000, virtio (bootrom built with rom-o-matic) and pcnet. We usually use virtio; the e1000 was just us flailing around trying to affect the problem. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566312: BUG: unable to handle kernel paging request, in skb_copy_bits
Package: linux-image-2.6.26-2-686-bigmem Version: 2.6.26-19lenny2 Severity: normal One of our i386 KVM VMs has been crashing every couple of days, with the following oops output. linux-image-2.6.30-2-686-bigmem=2.6.30-8 (from squeeze) made no difference, but linux-image-2.6.32-trunk-686-bigmem=2.6.32-5 from unstable has gone without a crash for over a week now. BUG: unable to handle kernel paging request at fffb8000 IP: [] skb_copy_bits+0x55/0x20d Oops: 0002 [#1] SMP Modules linked in: ipt_LOG xt_limit ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack_ftp nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc ipv6 loop evdev virtio_balloon virtio_net psmouse pcspkr i2c_piix4 i2c_core button ext3 jbd mbcache virtio_blk ide_cd_mod cdrom ide_pci_generic floppy virtio_pci virtio_ring virtio uhci_hcd usbcore piix ide_core ata_generic libata scsi_mod dock thermal processor fan thermal_sys [last unloaded: scsi_wait_scan] Pid: 24440, comm: netstats-script Not tainted (2.6.26-2-686-bigmem #1) EIP: 0060:[] EFLAGS: 00010282 CPU: 0 EIP is at skb_copy_bits+0x55/0x20d EAX: 0524 EBX: f40cfc04 ECX: 0149 EDX: f6dbd080 ESI: f58a68d6 EDI: fffb8000 EBP: fffb8000 ESP: f40cfb8c DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process netstats-script (pid: 24440, ti=f40ce000 task=f44e3b40 task.ti=f40ce000) Stack: 0084 f6dbd080 05dc 05a8 0008 f40cfc04 0524 1000 fffb8000 f8baf02f 0524 1000 f8baeeb7 f40cfc04 f585408c f7fff6e4 007c 107c f40cfc04 05a0 f5993800 f8bb04b1 Call Trace: [] xdr_skb_read_bits+0x1c/0x30 [sunrpc] [] xdr_partial_copy_from_skb+0x11f/0x179 [sunrpc] [] xs_tcp_data_recv+0x238/0x3c6 [sunrpc] [] xdr_skb_read_bits+0x0/0x30 [sunrpc] [] tcp_read_sock+0xa2/0x1ef [] xs_tcp_data_recv+0x0/0x3c6 [sunrpc] [] xs_tcp_data_ready+0x52/0x62 [sunrpc] [] mod_timer+0x19/0x36 [] sk_reset_timer+0xc/0x16 [] tcp_rcv_established+0x3b3/0x637 [] tcp_v4_do_rcv+0x262/0x3e8 [] tcp_v4_rcv+0x545/0x597 [] ip_local_deliver_finish+0xe8/0x183 [] ip_rcv_finish+0x286/0x2a3 [] netif_receive_skb+0x31c/0x349 [] virtnet_poll+0x167/0x258 [virtio_net] [] net_rx_action+0x9c/0x177 [] __do_softirq+0x66/0xd3 [] do_softirq+0x45/0x53 [] irq_exit+0x35/0x67 [] do_IRQ+0x52/0x63 [] common_interrupt+0x23/0x28 [] kvm_leave_lazy_mmu+0x29/0x31 [] unmap_vmas+0x57a/0x7c4 [] do_sync_read+0xbf/0xfe [] exit_mmap+0x65/0xd1 [] mmput+0x20/0x7e [] flush_old_exec+0x3e5/0x677 [] kernel_read+0x32/0x43 [] load_elf_binary+0x310/0x108a [] page_address+0x73/0x93 [] kmap_high+0x1c/0x1a2 [] page_address+0x73/0x93 [] copy_strings+0x169/0x173 [] search_binary_handler+0x8f/0x1a4 [] do_execve+0x138/0x1c6 [] sys_execve+0x2a/0x4a [] syscall_call+0x7/0xb [] xenfb_probe+0x221/0x35b === Code: d0 2b 44 24 04 89 54 24 10 85 c0 7e 39 39 44 24 2c 89 ef 0f 4e 44 24 2c 8b 54 24 08 8b 74 24 04 89 c1 c1 e9 02 03 b2 a4 00 00 00 a5 89 c1 83 e1 03 74 02 f3 a4 29 44 24 2c 0f 84 92 01 00 00 EIP: [] skb_copy_bits+0x55/0x20d SS:ESP 0068:f40cfb8c Kernel panic - not syncing: Fatal exception in interrupt -- Package-specific info: -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686-bigmem (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-2-686-bigmem depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.26-2-686-bigmem recommends: ii libc6-i6862.7-18 GNU C Library: Shared libraries [i Versions of packages linux-image-2.6.26-2-686-bigmem suggests: ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 (no description available) -- debconf information: linux-image-2.6.26-2-686-bigmem/preinst/overwriting-modules-2.6.26-2-686-bigmem: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-2-686-bigmem/preinst/lilo-has-ramdisk: linux-image-2.6.26-2-686-bigmem/postinst/bootloader-test-error-2.6.26-2-686-bigmem: linux-image-2.6.26-2-686-bigmem/postinst/depmod-error-2.6.26-2-686-bigmem: false linux-image-2.6.26-2-686-bigmem/preinst/initrd-2.6.26-2-686-bigmem: linux-image-2.6.26-2-686-bigmem/preinst/abort-overwrite-2.6.26-2-686-bigmem: linux-image-2.6.26-2-686-bigmem/preinst/bootloader-initrd-2.6.26-2-686-bigmem: true linux-image-2.6.26-2-686-bigmem/postinst/depmod-error-initrd-2.6.26-2-686-bigmem: false linux-image-2.6.26-2-686-bigmem/postinst/create-kimage-link-2.6.26-2-686-bigmem: true linux-image-2.6.26-2-686-bigmem/preinst/lilo-initrd-2.6.26-2-686-bigmem: true linux-image-2.6.26-2-686-bigme
Bug#563014: please add argument to scriptreplay(1) to set maximum delay between output
Package: bsdutils
Version: 1:2.17~rc3-1
Severity: wishlist
Tags: patch
We use script(1) to record major upgrades or maintenance. Sometimes, there
are long pauses as commands execute or we pause to check documentation, etc.
When replaying these scripts, it would be nice to have a limit on the delay
between output so we don't have to wait for minutes at a time in these
situations.
The existing divisor argument is useful, but we'd like to have quick
operations played back at regular speed so they're easy to watch. If we set
the divisor argument high enough to shorten long delays, the rest of the
output speeds by too quickly.
The attached patch (which should apply cleanly to the version of util-linux
in experimental, hence the Version:) adds a "limit" argument to
scriptreplay(1) that sets the maximum amount of delay between output. It
also fixes a think-o in argument parsing (&& -> || in the argc check).
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages bsdutils depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
Versions of packages bsdutils recommends:
ii bsdmainutils 6.1.10 collection of more utilities from
bsdutils suggests no packages.
-- no debconf information
--- scriptreplay.c.orig 2009-12-29 23:19:20.107793000 +
+++ scriptreplay.c 2009-12-29 23:33:31.592856000 +
@@ -35,7 +35,7 @@
void __attribute__((__noreturn__))
usage(int rc)
{
- printf(_("%s [ []]\n"),
+ printf(_("%s [ [ []]]\n"),
program_invocation_short_name);
exit(rc);
}
@@ -118,7 +118,7 @@
{
FILE *tfile, *sfile;
const char *sname, *tname;
- double divi;
+ double divi, limit;
int c;
unsigned long line;
size_t oldblk = 0;
@@ -133,12 +133,13 @@
bindtextdomain(PACKAGE, LOCALEDIR);
textdomain(PACKAGE);
- if (argc < 2 && argc > 4)
+ if (argc < 2 || argc > 5)
usage(EXIT_FAILURE);
tname = argv[1];
- sname = argc > 2 ? argv[2] : "typescript";
- divi = argc == 4 ? getnum(argv[3]) : 1;
+ sname = argc >= 3 ? argv[2] : "typescript";
+ divi = argc >= 4 ? getnum(argv[3]) : 1;
+ limit = argc == 5 ? getnum(argv[4]) : -1;
tfile = fopen(tname, "r");
if (!tfile)
@@ -167,6 +168,9 @@
tname, line);
}
delay /= divi;
+ if (limit != -1 && delay > limit) {
+ delay = limit;
+ }
if (delay > SCRIPT_MIN_DELAY)
delay_for(delay);
--- scriptreplay.1.orig 2009-12-29 23:20:48.541585000 +
+++ scriptreplay.1 2009-12-29 23:22:48.793858000 +
@@ -148,6 +148,7 @@
.I timingfile
.RI [ typescript
.RI [ divisor ]]
+.RI [ ceiling ]]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
This program replays a typescript, using timing information to ensure that
@@ -180,6 +181,11 @@
.B scriptreplay
go twice as fast and a speed-up of 0.1 makes it go ten times slower
than the original session.
+.PP
+If the fourth parameter is specified, it is used as a delay limit. For
+example, a limit of 2 makes
+.B scriptreplay
+never pause between output for more than two seconds.
.SH "EXAMPLE"
.IX Header "EXAMPLE"
.Vb 7
Bug#522179: closed by Marco Rodrigues (Package kvm has been removed from Debian)
reopen 522179 notfixed 522179 85+dfsg-4.1+rm reassign 522179 qemu-kvm 0.11.0+dfsg-1 tags 522179 + patch thanks On Mon, Dec 28, 2009 at 08:47:06PM +, Marco Rodrigues wrote: > You filled the bug http://bugs.debian.org/522179 in Debian BTS > against the package kvm. I'm closing it at *unstable*, but it will > remain open for older distributions. qemu-kvm 0.11.0+dfsg-1 has build support for the virtio bootrom, thank you. etherboot 5.4.4 moved bootroms from /usr/share -> /usr/lib and ships the virtio bootrom with a different filename than the qemu-kvm packaging expects (virtio -> virtio-net). The attached patch should fix this. I didn't know what your policy was on backwards compatibility, so I left support for bootroms in /usr/share to make things easier for backports. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ diff --git a/debian/rules b/debian/rules index a3af31a..310d006 100755 --- a/debian/rules +++ b/debian/rules @@ -173,14 +173,19 @@ ifeq (x86,$(BASE_ARCH)) install -m0644 pc-bios/optionrom/multiboot.bin pc-bios/optionrom/extboot.bin \ $(tbdir)/ # pxe roms are x86-specific - cp -p /usr/share/etherboot/e1000-82540em.zrom.gz $(tbdir)/pxe-e1000.bin.gz - cp -p /usr/share/etherboot/rtl8029.zrom.gz $(tbdir)/pxe-ne2k_pci.bin.gz - cp -p /usr/share/etherboot/pcnet32.zrom.gz $(tbdir)/pxe-pcnet.bin.gz - cp -p /usr/share/etherboot/rtl8139.zrom.gz $(tbdir)/pxe-rtl8139.bin.gz -# virtio bootrom is in git version of etherboot, not packaged in debian yet - if [ -f /usr/share/etherboot/virtio.zrom.gz ]; then \ - cp -p /usr/share/etherboot/virtio.zrom.gz $(tbdir)/pxe-virtio.bin.gz; \ - fi + for bootrom_hier in /usr/lib/etherboot /usr/share/etherboot; do \ + if [ ! -e "$$bootrom_hier" ]; then \ + continue; \ + fi; \ + cp -p $$bootrom_hier/e1000-82540em.zrom.gz $(tbdir)/pxe-e1000.bin.gz; \ + cp -p $$bootrom_hier/rtl8029.zrom.gz $(tbdir)/pxe-ne2k_pci.bin.gz; \ + cp -p $$bootrom_hier/pcnet32.zrom.gz $(tbdir)/pxe-pcnet.bin.gz; \ + cp -p $$bootrom_hier/rtl8139.zrom.gz $(tbdir)/pxe-rtl8139.bin.gz; \ + # virtio bootrom is in etherboot 5.4.4 and newer. \ + if [ -f $$bootrom_hier/virtio-net.zrom.gz ]; then \ + cp -p $$bootrom_hier/virtio-net.zrom.gz $(tbdir)/pxe-virtio.bin.gz; \ + fi; \ + done gzip -d $(tbdir)/pxe-*.bin.gz endif
Bug#560712: libapache2-mod-ldap-userdir: backport fix for 515952 to stable
tags 560712 + wontfix thanks On Fri, Dec 11, 2009 at 10:23:20AM -0500, Branden Moore wrote: > After finally upgrading to Lenny from Etch, bug #515952 bit me. I > worked around it by installing 1.1.17-1 from Testing, but I would prefer > to pull upgraded packages from the backports collection, versus tracking > a mix of stable and testing. > > Could you please perform an upload of libapache2-mod-ldap-userdir to the > lenny-backports tree? I appreciate your polite request, but I've decided against uploading this to backports.org (presumably the backports collection you're asking about). I'm not a DD, so I rely on others to make uploads for me, and this process is the same for backports.org. This would also add an additional "distribution" to maintain for some time (squeeze+1y or more). Granted, mod_ldap_userdir releases don't happen often, but I have a lot of these small projects that I take care of and find that, in order to keep my sanity, I need to occasionally say 'no.' Again, I empathize. I'll leave this bug open for now in case some else fancies maintaining libapache2-mod-ldap-userdir on backports.org, which I would have no problem with. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525605: libldap-2.4-2: setting LDAP_OPT_X_TLS_REQUIRE_CERT is not handled correctly
On Sat, Apr 25, 2009 at 11:14:33PM +0200, Arthur de Jong wrote: > I've been busy tracking down a LDAP/TLS related bug in my package > (#521617) and found that the correct certificate checks are not done > correctly if I only set the LDAP_OPT_X_TLS_REQUIRE_CERT option on a > connection: > tls_reqcert=LDAP_OPT_X_TLS_NEVER; > ldap_set_option(NULL,LDAP_OPT_X_TLS_REQUIRE_CERT,&tls_reqcert); > I get at entering ldap_start_tls_s(): > TLS: peer cert untrusted or revoked (0x42) > TLS: can't connect: (unknown error code). > > If I set the option globally, after opening the connection: > ldap_set_option(NULL,LDAP_OPT_X_TLS_REQUIRE_CERT,&tls_reqcert); > I get: > TLS: hostname (192.168.12.1) does not match common name in certificate > (server.host.name.tld). [snip] > I think (but haven't investigated further) that some of the > option-checks that are done should be done on the connection options, > not on the global ones. As much as I'm sure Quanah would love for everyone to upgrade to the latest OpenLDAP release every couple of months, I don't think OpenLDAP is misbehaving in this case. I recently ran into a similar problem with nss_ldap wherein it was calling ldap_set_option() on LDAP_OPT_X_TLS_REQUIRE_CERT *after* the LDAP handle was initialized with ldap_initialize(). According to the latest (albeit expired) LDAP C API draft: -- 11.2. LDAP Session Handle Options [...] ld The session handle. If this is NULL, a set of global defaults is accessed. New LDAP session handles created with ldap_init() or ldap_open() inherit their characteristics from these global defaults. -- global defaults are inherited by new LDAP handles when they're initialized. As a result, global defaults set after initializing an LDAP handle do not apply to that handle. IOW, they're global *defaults*, not global *settings.* AFAICT with OpenLDAP 2.4.20, it implements this part of the draft correctly. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516374: New workloads trigger 'INFO: task * blocked for more than 120 seconds.'
cho 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [22652485.379503] kvm D 0 5135 1 [22652485.379503] 81042401fbe8 0082 810008a652f0 [22652485.379503] 81042bbdf7b0 804f8480 81042bbdfa38 b6acf690 [22652485.379503] [22652485.379503] Call Trace: [22652485.379503] [] sync_page+0x0/0x41 [22652485.379503] [] io_schedule+0x5c/0x9e [22652485.379503] [] sync_page+0x3c/0x41 [22652485.379503] [] __wait_on_bit+0x40/0x6e [22652485.379503] [] wait_on_page_bit+0x6b/0x71 [22652485.379503] [] wake_bit_function+0x0/0x23 [22652485.379503] [] pagevec_lookup_tag+0x1a/0x21 [22652485.379503] [] wait_on_page_writeback_range+0x66/0x113 [22652485.379503] [] do_writepages+0x27/0x2d [22652485.379503] [] generic_osync_inode+0x5e/0xcf [22652485.379503] [] generic_file_aio_write+0xa6/0xc1 [22652485.379503] [] :ext3:ext3_file_write+0x16/0x94 [22652485.379503] [] do_sync_write+0xc9/0x10c [22652485.379503] [] autoremove_wake_function+0x0/0x2e [22652485.379503] [] :kvm:kvm_vm_ioctl+0x19c/0x1b5 [22652485.379503] [] sys_rt_sigtimedwait+0xf1/0x25f [22652485.379503] [] vfs_write+0xad/0x156 [22652485.379503] [] sys_write+0x45/0x6e [22652485.379503] [] system_call_after_swapgs+0x8a/0x8f -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550143: init script should set $PATH
Package: freeradius
Version: 2.0.4+dfsg-6
Severity: normal
Tags: patch
The init script doesn't set $PATH, so start-stop-daemon can't be executed
unless the caller already has /sbin in $PATH.
Adding something like:
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
to the init script fixes this.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages freeradius depends on:
ii freeradius-common2.0.4+dfsg-6FreeRadius common files
ii libc62.7-18 GNU C Library: Shared libraries
ii libfreeradius2 2.0.4+dfsg-6FreeRADIUS shared library
ii libgdbm3 1.8.3-3 GNU dbm database routines (runtime
ii libltdl3 1.5.26-4A system independent dlopen wrappe
ii libpam0g 1.0.1-5+lenny1 Pluggable Authentication Modules l
ii libperl5.10 5.10.0-19lenny2 Shared Perl library
ii libsnmp155.4.1~dfsg-12 SNMP (Simple Network Management Pr
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii python2.52.5.2-15An interactive high-level object-o
Versions of packages freeradius recommends:
ii freeradius-utils2.0.4+dfsg-6 FreeRadius client utilities
Versions of packages freeradius suggests:
pn freeradius-krb5(no description available)
ii freeradius-ldap 2.0.4+dfsg-6 LDAP module for FreeRADIUS server
ii freeradius-mysql2.0.4+dfsg-6 MySQL module for FreeRADIUS server
pn freeradius-postgresql (no description available)
-- 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#548207: interfaces(5) has incorrect "see also" reference manual URL
Package: ifupdown Version: 0.7~alpha3 Severity: minor interfaces(5)'s SEE ALSO section references this nonexistent URL: http://www.debian.org/doc/manuals/reference/ch-gateway.en.html Best I can tell, this should be: http://www.debian.org/doc/manuals/reference/ch05.en.html now? -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686-bigmem (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ifupdown depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii net-tools 1.60-22The NET-3 networking toolkit ifupdown recommends no packages. Versions of packages ifupdown suggests: ii dhcp3-client 3.1.1-6+lenny3 DHCP client ii iproute 20080725-2 networking and traffic control too pn ppp(no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#536500: etch -> lenny upgrade breaks local mail submission
On Wed, Sep 16, 2009 at 10:01:10PM -0700, Richard A Nelson wrote: > To: 536500-d...@debian.org I figure you meant @b.d.o? > Unfortunately, it isn't as simple as it sounds... [snip] > Coupled with the fact that while sendmail.mc and submit.mc are > occasionally edited via sed for safe upgrades, this was one of those > things that may have been deliberate by the sysadmin, or the package > screwup... So I couldn't blindly set already existing files to use > port 25 :( Of course. I don't mean to ignore the difficulty in determining who/what made the mess and cleaning it up correctly and automatically. Rather than writing the problem off as unsolvable, wouldn't it be better to include a notification in the package (as a debconf template item) or in the lenny release notes, to eliminate the chance of locally generated mail quietly breaking unnoticed after the upgrade? john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544898: rc_send_server() unconditionally adds PW_NAS_IP_ADDRESS value
Package: libradiusclient-ng2
Version: 0.5.5-1
Severity: normal
Tags: patch
rc_send_server() unconditionally adds a PW_NAS_IP_ADDRESS value to the
outgoing request:
--
/*
* Fill in NAS-IP-Address
*/
if (sinlocal.sin_addr.s_addr == htonl(INADDR_ANY)) {
if (rc_get_srcaddr(SA(&sinlocal), SA(&sinremote)) != 0) {
close (sockfd);
memset (secret, '\0', sizeof (secret));
return ERROR_RC;
}
}
nas_ipaddr = ntohl(sinlocal.sin_addr.s_addr);
rc_avpair_add(rh, &(data->send_pairs), PW_NAS_IP_ADDRESS,
&nas_ipaddr, 0, 0);
--
This causes problems for callers (such as nagios-plugins-standard's
check_radius) that specify their own PW_NAS_IP_ADDRESS to override
rc_send_server()'s autoselected value. Multiple NAS-IP-Address values
are added to the Auth-Request:
AVP: l=6 t=NAS-IP-Address(4): 1.2.3.4
AVP: l=6 t=NAS-IP-Address(4): 1.2.3.5
The attached patch sets PW_NAS_IP_ADDRESS only if not already present
in the request.
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686-bigmem (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libradiusclient-ng2 depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
libradiusclient-ng2 recommends no packages.
libradiusclient-ng2 suggests no packages.
-- no debconf information
--- lib/sendserver.c.orig 2009-09-03 15:42:05.487495000 +
+++ lib/sendserver.c 2009-09-03 15:42:27.881682000 +
@@ -254,8 +254,10 @@
}
}
nas_ipaddr = ntohl(sinlocal.sin_addr.s_addr);
- rc_avpair_add(rh, &(data->send_pairs), PW_NAS_IP_ADDRESS,
- &nas_ipaddr, 0, 0);
+ if (!rc_avpair_get(data->send_pairs, PW_NAS_IP_ADDRESS, 0)) {
+ rc_avpair_add(rh, &(data->send_pairs), PW_NAS_IP_ADDRESS,
+ &nas_ipaddr, 0, 0);
+ }
/* Build a request */
auth = (AUTH_HDR *) send_buffer;
Bug#536500: etch -> lenny upgrade breaks local mail submission
Package: sendmail-cf Version: 8.14.3-5 Severity: normal After upgrading some machines from etch to lenny, we noticed that local mail submission no longer functioned. submit.mc on etch machines and etch->lenny upgraded machines both have: FEATURE(`msp', `[127.0.0.1]', `MSA')dnl It seems that sendmail did not require SMTP auth on port 587 in etch, but does in lenny? Interestingly, fresh lenny installs have: FEATURE(`msp', `[127.0.0.1]', `25')dnl [...@lenny:pts/2 /etc/mail> sudo sendmail -v j...@isis.example.com j...@isis.example.com... Connecting to [127.0.0.1] port 587 via relay... 220 lenny.example.com ESMTP Sendmail 8.14.3/8.14.3/Debian-5; Fri, 10 Jul 2009 14:46:03 GMT; (No UCE/UBE) logging access from: localhost(OK)-sm...@localhost [127.0.0.1] >>> EHLO lenny.example.com 250-lenny.example.com Hello sm...@localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-DELIVERBY 250 HELP >>> VERB 250 2.0.0 Verbose mode >>> MAIL From: 530 5.7.0 Authentication required jwm... Using cached ESMTP connection to [127.0.0.1] via relay... >>> RSET 250 2.0.0 Reset state >>> MAIL From:<> SIZE=1024 530 5.7.0 Authentication required postmaster... Using cached ESMTP connection to [127.0.0.1] via relay... >>> RSET 250 2.0.0 Reset state >>> MAIL From:<> SIZE=2048 530 5.7.0 Authentication required MAILER-DAEMON... Saved message in /var/lib/sendmail/dead.letter Closing connection to [127.0.0.1] >>> QUIT 221 2.0.0 lenny.example.com closing connection [...@etch:pts/82 ~> sendmail -v j...@isis.example.com j...@isis.example.com... Connecting to [127.0.0.1] port 587 via relay... 220 etch.example.com ESMTP Sendmail 8.13.8/8.13.8/Debian-3; Fri, 10 Jul 2009 14:46:49 GMT; (No UCE/UBE) logging access from: localhost(OK)-...@localhost [127.0.0.1] >>> EHLO etch.example.com 250-etch.example.com Hello j...@localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> VERB 250 2.0.0 Verbose mode >>> MAIL From: auth=...@etch.example.com 250 2.1.0 ... Sender ok >>> RCPT To: >>> DATA 250 2.1.5 ... Recipient ok 354 Enter mail, end with "." on a line by itself >>> . 050 ... Connecting to relay.example.com. via relay... 050 220 mailhub.example.com ESMTP Postfix 050 >>> EHLO etch.example.com 050 250-mailhub.example.com 050 250-PIPELINING 050 250-SIZE 26214400 050 250-ETRN 050 250-AUTH PLAIN LOGIN 050 250-AUTH=PLAIN LOGIN 050 250-ENHANCEDSTATUSCODES 050 250-8BITMIME 050 250 DSN 050 >>> MAIL From: SIZE=365 AUTH=<> 050 250 2.1.0 Ok 050 >>> RCPT To: 050 >>> DATA 050 250 2.1.5 Ok 050 354 End data with . 050 >>> . 050 250 2.0.0 Ok: queued as 42A3918E2C7 on mailhub.example.com 050 ... Sent (Ok: queued as 42A3918E2C7 on mailhub.example.com) 250 2.0.0 n6AEknQG005348 Message accepted for delivery j...@isis.example.com... Sent (n6AEknQG005348 Message accepted for delivery) Closing connection to [127.0.0.1] >>> QUIT 221 2.0.0 etch.example.com closing connection -- Package-specific info: Ouput of /usr/share/bug/sendmail-cf/script: ls -alR /etc/mail: /etc/mail: total 252 drwxr-sr-x 7 smmta smmsp 4096 2009-07-10 14:35 . drwxr-xr-x 79 root root 4096 2009-07-10 14:39 .. -rwxr-xr-- 1 root smmsp 10024 2009-07-10 14:35 Makefile -rw--- 1 root root 4211 2009-07-10 14:35 access -rw-r- 1 smmta smmsp 12288 2009-07-10 14:35 access.db -rw-r--r-- 1 root root281 2006-12-09 04:22 address.resolve lrwxrwxrwx 1 root smmsp10 2009-07-10 13:07 aliases -> ../aliases -rw-r- 1 smmta smmsp 12288 2009-07-10 13:07 aliases.db -rw-r--r-- 1 root root 3248 2009-07-10 14:35 databases -rw-r--r-- 1 root root 5657 2008-07-15 22:31 helpfile -rw-r--r-- 1 root smmsp42 2009-07-10 13:07 local-host-names drwxr-sr-x 2 smmta smmsp 4096 2009-07-10 13:07 m4 drwxr-xr-x 2 root root 4096 2009-07-10 14:19 peers drwxr-xr-x 2 root smmsp 4096 2006-12-09 04:22 sasl -rw-r--r-- 1 root smmsp 65632 2009-07-10 14:35 sendmail.cf -rw-r--r-- 1 root smmsp 442 2009-07-10 14:35 sendmail.cf.errors -rw-r--r-- 1 root root 12236 2009-07-10 14:35 sendmail.conf -rw-r--r-- 1 root smmsp 4327 2009-07-10 14:35 sendmail.mc -rw-r--r-- 1 root smmsp 4217 2009-07-10 14:22 sendmail.mc.old -rw-r--r-- 1 root root149 2006-12-09 04:22 service.switch -rw-r--r-- 1 root root180 2006-12-09 04:22 service.switch-nodns drwxr-sr-x 2 smmta smmsp 4096 2009-07-10 13:07 smrsh -rw-r--r-- 1 root smmsp 43900 2009-07-10 14:35 submit.cf -rw-r--r-- 1 root smmsp 2284 2009-07-10 14:35 submit.mc drwxr-xr-x 2 smmta smmsp 4096 2009-07-10 13:07 tls -rw-r--r-- 1 root smmsp 0 2009-07-10 13:07 trusted-users /etc/mail/m4: total 12 drwxr-sr-x 2 smmta smmsp 4096 2009-07-10 13:07 . drwxr-sr-x 7 smmta smmsp 4096 2009-07-10 14:35 .. -rw-r- 1 root smmsp 834 2009-07-10 14:17 dialup.m4 -rw-r- 1 root smmsp0 2009-07-10 13:07 provider.m4 /etc/mail/pe
Bug#483111: apache's mod_mime_magic does not support newer libmagic functionality
mod_mime_magic's parse() does not grok the search/[[:digit:]]\{1,\} magic
type and emits errors:
[error] mod_mime_magic: type search/400\tsetlength\ttext/x-tex invalid
for every line in /usr/share/file/magic.mime that uses it (6 lines in
file=4.26-1). In addition, mime_magic logs errors:
mod_mime_magic: invalid type 0 in mconvert()., referer: [...]
for every request it's invoked on, one error per "invalid" line in
magic.mime.
It seems #483111 could be folded into #366023, and the latter assigned to
apache2.2-common, since they share a root cause.
As Reuben Thomas mentions, mod_mime_magic probably shouldn't
be reading /usr/share/file/magic.mime, as libmagic may be updated with new
functionality that mod_mime_magic won't be able to grok. I'm not sure if
it's appropriate/best to link mod_mime_magic against libmagic for parsing
duty; upstream apache2 trunk is still parsing the file itself.
john
--
John Morrissey _o/\ __o
j...@horde.net_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516374: INFO: task * blocked for more than 120 seconds. in numerous non-SCHED_IDLE workloads
On Mon, Jun 08, 2009 at 07:14:44PM -0400, John Morrissey wrote: > Thanks, Ben. Rebuilt with this patch and threw the resulting kernel on a > couple of machines running several KVM VMs. I'll be able to provide > confident feedback in a couple of days. These machines have been stable since running kernels including this patch. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516374: INFO: task * blocked for more than 120 seconds. in numerous non-SCHED_IDLE workloads
On Fri, Jun 05, 2009 at 03:37:33AM +0100, Ben Hutchings wrote: > Please try the patch I posted here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=54;bug=517449 > > It includes a fix made between 2.6.26 and .28 that may address this bug. Thanks, Ben. Rebuilt with this patch and threw the resulting kernel on a couple of machines running several KVM VMs. I'll be able to provide confident feedback in a couple of days. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531056: leaks memory when vlan subinterfaces present
On Sun, May 31, 2009 at 09:03:23AM +0200, Thomas Anders wrote:
> John Morrissey wrote:
> > Just tried this; snmpd does *not* leak when kernel IPv6 support is
> > absent.
>
> Thanks for your great help so far. Do you also have a chance to test
> upstream's 5.4.x SVN and/or SVN trunk (with IPv6 support enabled again)?
5.4.x svn didn't leak. Found the upstream commit that fixed this; a debdiff
is attached.
john
--
John Morrissey _o/\ __o
j...@horde.net_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
diff -u net-snmp-5.4.1~dfsg/debian/changelog
net-snmp-5.4.1~dfsg/debian/changelog
--- net-snmp-5.4.1~dfsg/debian/changelog
+++ net-snmp-5.4.1~dfsg/debian/changelog
@@ -1,3 +1,11 @@
+net-snmp (5.4.1~dfsg-13) unstable; urgency=low
+
+ * Fix memory leak when multiple interfaces have the same IPv6 address,
+such as link-local addresses when VLAN subinterfaces are in use.
+ (Closes: #531056)
+
+ -- John Morrissey Sun, 31 May 2009 23:07:32 +
+
net-snmp (5.4.1~dfsg-12) unstable; urgency=high
* Urgency high because of RC bug fix.
only in patch2:
unchanged:
--- net-snmp-5.4.1~dfsg.orig/debian/patches/56_fix_ipv6_memleak.patch
+++ net-snmp-5.4.1~dfsg/debian/patches/56_fix_ipv6_memleak.patch
@@ -0,0 +1,17 @@
+Index: agent/mibgroup/ip-mib/data_access/ipaddress_linux.c
+===
+--- agent/mibgroup/ip-mib/data_access/ipaddress_linux.c(revision 17254)
agent/mibgroup/ip-mib/data_access/ipaddress_linux.c(revision 17255)
+@@ -325,7 +325,11 @@
+ /*
+ * add entry to container
+ */
+-CONTAINER_INSERT(container, entry);
++if (CONTAINER_INSERT(container, entry) < 0) {
++DEBUGMSGTL(("access:ipaddress:container","error with
ipaddress_entry: insert into container failed.\n"));
++netsnmp_access_ipaddress_entry_free(entry);
++continue;
++}
+ }
+
+ fclose(in);
only in patch2:
unchanged:
--- net-snmp-5.4.1~dfsg.orig/debian/patches/56_fix_ipv6_memleak.README
+++ net-snmp-5.4.1~dfsg/debian/patches/56_fix_ipv6_memleak.README
@@ -0,0 +1,2 @@
+Upstream Changeset 17255: CHANGES: snmpd: fix memory leak when multiple
+interfaces have the same IPv6 address
Bug#531056: [Pkg-net-snmp-devel] Bug#531056: leaks memory when vlan subinterfaces present
On Fri, May 29, 2009 at 08:53:08PM +0200, Jochen Friedrich wrote: > Do you have a chance to test the same on a system without IPv6 > support? I still suspect the leak when trying to add duplicate (link > local) IPv6 addresses to the interface table. Just tried this; snmpd does *not* leak when kernel IPv6 support is absent. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531056: leaks memory when vlan subinterfaces present
On Fri, May 29, 2009 at 02:42:25PM +, John Morrissey wrote: > This version of net-snmp is also in sid, so I'm currently trying the > latest upstream release (5.4.2.1) to see if it's any different. 5.4.2.1 leaks in the same way/amount as 5.4.1~dfsg-12. After ~3.5 hours of uptime: ==25243== 1,456,858 (765,648 direct, 691,210 indirect) bytes in 10,634 blocks are definitely lost in loss record 107 of 107 ==25243==at 0x4C203E4: calloc (vg_replace_malloc.c:397) ==25243==by 0x53684DC: netsnmp_access_ipaddress_entry_create (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==25243==by 0x5369054: _load_v6 (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==25243==by 0x53694F3: netsnmp_arch_ipaddress_container_load (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==25243==by 0x5368936: netsnmp_access_ipaddress_container_load (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==25243==by 0x534B495: ipAddressTable_container_load (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==25243==by 0x5076F83: (within /usr/lib/libnetsnmphelpers.so.15.1.0) ==25243==by 0x564343B: run_alarms (in /usr/lib/libnetsnmp.so.15.1.0) ==25243==by 0x40456C: main (in /usr/sbin/snmpd) john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531056: leaks memory when vlan subinterfaces present
Package: snmpd Version: 5.4.1~dfsg-12 Severity: normal lenny's snmpd leaks memory when VLAN subinterfaces are present. For example, machines here with 13 VLAN subints leak about 200mbytes of memory every couple of weeks. Other amd64 machines without VLAN subints do not leak. The observed behavior is similar to #510495 (default install of snmpd leaks memory when VLAN interfaces present), but the fix for etch's snmpd isn't applicable to lenny's snmpd, so I figure the leak is different. This version of net-snmp is also in sid, so I'm currently trying the latest upstream release (5.4.2.1) to see if it's any different. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-11-server (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages snmpd depends on: ii adduser3.110 add and remove users and groups ii debconf1.5.24Debian configuration management sy ii libc6 2.7-18GNU C Library: Shared libraries ii libsnmp15 5.4.1~dfsg-12 SNMP (Simple Network Management Pr ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra snmpd recommends no packages. snmpd suggests no packages. -- debconf information: snmpd/upgradefrom521: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516374: Kernel scheduler problem (#516374)
On Fri, May 08, 2009 at 02:07:16PM +0200, Martin Kos wrote: > i am experiencing the same ""INFO: task * blocked for more than 120 > seconds" freezes (or "pause") on my openvz host machine. have you got > nearer to a solution as there was no traffic on the bug report recently? Nothing new since: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516374#20 I haven't been able to raise anybody on debian-kernel@ about this, and I've reached the point where I don't know how to continue. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525889: exitcode behavior for source packaging contradictory to man page
8-6 text-based mailreader supporting M
pn svn-buildpackage (no description available)
-- no debconf information
--
John Morrissey _o/\ __o
j...@horde.net_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
--- /usr/bin/debdiff 2009-02-11 08:41:58.0 +
+++ debdiff 2009-04-27 17:28:29.097401000 +
@@ -528,6 +528,14 @@
# Execute diff and remove the common prefixes $dir1/$dir2, so the patch can be used with -p1,
# as if when interdiff would have been used:
system(join(" ", @command)) || fatal "Failed to execute @command!";
+ if ($? & 127) {
+ fatal sprintf("@command exited due to signal %d.", $? & 127);
+ }
+ # We include == 2, since diff(1) returns "failure" when
+ # encountering binary files that differ.
+ elsif ($? >> 8 == 1 || $? >> 8 == 2) {
+ $exit_status = 1;
+ }
if ($have_diffstat and $show_diffstat) {
print "diffstat for $sdir1 $sdir2\n\n";
@@ -547,7 +555,7 @@
close DIFF;
}
-exit 0;
+exit $exit_status;
}
else {
fatal "Internal error: \$type = $type unrecognised";
Bug#520926: [Pkg-db-devel] Bug#520926: should be built with --enable-posixmutexes --with-mutex=POSIX/pthreads
On Fri, Apr 10, 2009 at 12:57:40PM +0200, Florian Weimer wrote: > * John Morrissey: > > tl;dr summary: It seems BerkeleyDB should be built with: > > > > --enable-posixmutexes --with-mutex=POSIX/pthreads > > > > on NPTL Linux systems, since native POSIX mutexes substantially > > lower context switches, at least with OpenLDAP's slapd. > > Wasn't it the other way round for previous versions? Anyway, I think > this is the way to go, but we can't do it on all architectures because > some of them are still not NPTL-enabled. We also should get it right > early because changing the mutex algorithm changes the database > environment layout in a way which cannot detected by Berkeley DB. > > If you think it's not too late for that, we can make the change now, > or with the release of version 4.8. Hm, I'm really not sure I'm the one to answer that question (if it's indeed me you're asking it of). I've already backported and forked libdb4.7 locally, so I filed this bug mostly as an FYI that this is a change you might want to make to the Debian packaging, since it seems to result in more optimal outcomes on NPTL systems. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524199: test build
On Thu, Apr 16, 2009 at 12:23:20AM -0600, dann frazier wrote: > Can you test this build to see if it fixes the issue? > http://people.debian.org/~dannf/bugs/524199/ I've been waiting for a local amd64 rebuild to finish, but given that Anton is still seeing the same behavior, I'm hesitant to try this on one of our machines. Dann, I'll hold off for now, but let me know if the additional feedback would be useful to you and I'll give it a shot. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524199: linux-image-2.6.26-1-686: nfs unusable
On Wed, Apr 15, 2009 at 01:30:51PM +0100, Anton Ivanov wrote: > Overtime any system with NFS usage grinds to a crawl. While root or /usr > on NFS are most affected the same problem should affect other NFS usage. > The symptoms are extremely high system load, [snip] > The reason seems to be: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=23918b03060f6e572168fdde1798a905679d2e06 FWIW, we're also seeing this, on machines mounting several large NFS volumes that serve virtual accounts (i.e., they all have the same UID/GID and no shell access). After ~two days of uptime, these moderately loaded machines (running Apache, ProFTPD, and Courier IMAP) start spending >90% of CPU time in system state and become so unresponsive that they must be rebooted. Running the 2.6.28 that was recently in sid (which contains the commit Anton mentions) fixed this. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522703: logrotate postrotate script causes errors when icecast2 not running
Package: icecast2 Version: 2.3.2-2 Severity: normal icecast2's logrotate postrotate script tries to do the right thing when the daemon isn't running: pgrep icecast2 >/dev/null && invoke-rc.d --quiet icecast2 reload > /dev/null However, since shell lists return the exitcode of the last executed portion, pgrep(1)'s exit code of 1 is returned and causes logrotate output: /etc/cron.daily/logrotate: error: error running postrotate script for /var/log/icecast2/error.log run-parts: /etc/cron.daily/logrotate exited with return code 1 This uglier version fixes this: ! pgrep icecast2 >/dev/null || invoke-rc.d --quiet icecast2 reload > /dev/null but is logically unwieldy. Might be better to use a full-blown if statement. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Kernel: Linux 2.6.18-6-alpha-smp (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages icecast2 depends on: ii adduser 3.110 add and remove users and groups ii libc6.1 2.7-18 GNU C Library: Shared libraries ii libcurl3-gnutls 7.18.2-8lenny2 Multi-protocol file transfer libra ii libogg0 1.1.3-4Ogg Bitstream Library ii libspeex1 1.2~rc1-1 The Speex codec runtime library ii libtheora01.0~beta3-1The Theora Video Compression Codec ii libvorbis0a 1.2.0.dfsg-3.1 The Vorbis General Audio Compressi ii libxml2 2.6.32.dfsg-5 GNOME XML library ii libxslt1.11.1.24-2 XSLT processing library - runtime Versions of packages icecast2 recommends: pn ices2 (no description available) icecast2 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#499745: Experiencing this with KVM, too
[sorry for the cc/bug spam, but the symptoms of these bugs seem similar, so this information might be useful beyond debbugs #516374] On Fri, Mar 06, 2009 at 02:06:43PM -0500, John Morrissey wrote: > I'm experiencing the same thing sporadically with two machines running a > handful of KVM VMs. It usually starts with one VM blocking, then spreads > to the rest, and eventually the host itself stops responding. > > I cherry-picked the three patches in LP 276476 and applied them to the > 2.6.28 kernel currently in sid. So far so good, but I don't have a solid > test case to reproduce and it usually takes a couple days for this to show > itself. This machine has been stable for over three weeks now with 2.6.28 + these cherry-picked patches, whereas with the stock lenny 2.6.26 kernel, it would lock up at least once a week. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522179: Please ship virtio PXE ROM
Package: kvm Version: 84+dfsg-2 Severity: wishlist We PXE boot all our machines and have moved to virtio for both disk and network access. It would be nice if the kvm packaging shipped a pxe-virtio.bin; the one generated by rom-o-matic.net with the default options works fine for us. -- Package-specific info: selected information from lshal(1): /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz stepping: 6 cpu MHz : 2833.778 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips: 5667.55 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz stepping: 6 cpu MHz : 2833.778 cache size : 6144 KB physical id : 1 siblings: 4 core id : 0 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips: 5667.32 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz stepping: 6 cpu MHz : 2833.778 cache size : 6144 KB physical id : 0 siblings: 4 core id : 1 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips: 5667.29 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz stepping: 6 cpu MHz : 2833.778 cache size : 6144 KB physical id : 0 siblings: 4 core id : 2 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips: 5667.29 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 4 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz stepping: 6 cpu MHz : 2833.778 cache size : 6144 KB physical id : 0 siblings: 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips: 5667.27 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 5 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz stepping: 6 cpu MHz : 2833.778 cache size : 6144 KB
Bug#521855: bugzilla3: ucf warning on upgrade from bugzilla package in etch
Package: bugzilla3 Version: 3.0.4.1-2+lenny1 Severity: minor When upgrading a machine from etch (bugzilla=2.22.1-2) to lenny, ucf emits a warning: Setting up bugzilla3 (3.0.4.1-2+lenny1) ... dbconfig-common: writing config to /etc/dbconfig-common/bugzilla3.conf *** WARNING: ucf was run from a maintainer script that uses debconf, but the script did not pass --debconf-ok to ucf. The maintainer script should be fixed to not stop debconf before calling ucf, and pass it this parameter. For now, ucf will revert to using old-style, non-debconf prompting. Ugh! Please inform the package maintainer about this problem. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Kernel: Linux 2.6.18-6-alpha-smp (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages bugzilla3 depends on: ii apache2 2.2.9-10+lenny2 Apache HTTP Server metapackage ii apache2-mpm-prefork [ht 2.2.9-10+lenny2 Apache HTTP Server - traditional n ii dbconfig-common 1.8.39 common framework for packaging dat ii debconf 1.5.24 Debian configuration management sy ii libappconfig-perl 1.56-2 Perl module for configuration file ii libcgi-pm-perl 3.38-2 Simple Common Gateway Interface Cl ii libdbd-mysql-perl 4.007-1 A Perl5 database interface to the ii libemail-mime-modifier- 1.442-3 Modify Email::MIME objects easily ii libemail-send-perl 2.192-3 Simply Sending Email ii libtemplate-perl2.19-1.1lenny1.1 template processing system written ii libtimedate-perl1.1600-9 Time and date functions for Perl ii mysql-client-5.0 [mysql 5.0.51a-24 MySQL database client binaries ii patch 2.5.9-5 Apply a diff file to an original ii perl-modules [libcgi-pm 5.10.0-19Core Perl modules ii postfix [mail-transport 2.5.5-1.1High-performance mail transport ag ii ucf 3.0016 Update Configuration File: preserv Versions of packages bugzilla3 recommends: ii libchart-perl 2.4.1-5 Chart Library for Perl ii libxml-parser-p 2.36-1.1+b1 Perl module for parsing XML files ii mysql-server-5. 5.0.51a-24 MySQL database server binaries ii perlmagick 7:6.3.7.9.dfsg1-3~lenny1 Perl interface to the libMagick gr Versions of packages bugzilla3 suggests: pn bugzilla3-doc (no description available) ii graphviz 2.20.2-3 rich set of graph drawing tools ii libgd-gd2-perl1:2.39-2 Perl module wrapper for libgd - gd ii libgd-graph-perl 1.44-3 Graph Plotting Module for Perl 5 ii libgd-text-perl 0.86-5 Text utilities for use with GD ii libhtml-parser-perl 3.56-1+b1 A collection of modules that parse ii libhtml-scrubber-perl 0.08-4 Perl extension for scrubbing/sanit ii libmailtools-perl 2.03-1 Manipulate email in perl programs ii libmime-tools-perl5.427-1Perl5 modules for MIME-compliant m pn libnet-ldap-perl (no description available) pn libsoap-lite-perl (no description available) ii libwww-perl 5.813-1WWW client/server library for Perl ii libxml-twig-perl 1:3.32-1 Perl module for processing huge XM -- debconf information: bugzilla3/database-type: mysql bugzilla3/remove-error: abort bugzilla3/dbconfig-remove: * bugzilla3/dbconfig-install: false bugzilla3/internal/reconfiguring: false bugzilla3/remote/newhost: bugzilla3/internal/skip-preseed: true bugzilla3/remote/host: bugzilla3/install-error: abort bugzilla3/upgrade-backup: true bugzilla3/db/dbname: bugzilla3/missing-db-package-error: abort bugzilla3/passwords-do-not-match: bugzilla3/mysql/admin-user: root bugzilla3/upgrade-error: abort bugzilla3/db/app-user: bugzilla3/dbconfig-reinstall: false bugzilla3/mysql/method: unix socket bugzilla3/remote/port: bugzilla3/dbconfig-upgrade: true bugzilla3/purge: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521852: sasl2-bin: upgrade from etch fails due to nonexistent /etc/sasldb2
Package: sasl2-bin Version: 2.1.22.dfsg1-23 Severity: normal Upgrading an etch machine to lenny fails on the sasl2-bin package because /etc/sasldb2 doesn't exist. From the postinst: -- # If the database contains no users, just wipe it out, # it will be recreated later in the current format if [ -e $SASLDB_FILE ] && \ [ `sasldblistusers2 | wc -l -eq 0` ]; then rm $SASLDB_FILE else # The database had users, begin upgrade procedure # Make backup and handle errors db_get cyrus-sasl2/backup-sasldb2 if ! cp --archive $SASLDB_FILE "$RET" >/dev/null 2>&1; then db_input high cyrus-sasl2/upgrade-sasldb2-backup-failed || true db_go || true exit 1 fi -- If $SASLDB_FILE (/etc/sasldb2) doesn't exist, the else branch is hit and the cp(1) fails, aborting the package upgrade. Perhaps something like the following would be better? -- if [ -e $SASLDB_FILE ]; then if [ `sasldblistusers2 | wc -l -eq 0` ]; then rm $SASLDB_FILE else # The database had users, begin upgrade procedure [...] fi -- -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Kernel: Linux 2.6.18-6-alpha-smp (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages sasl2-bin depends on: ii db4.6-util4.6.21-11 Berkeley v4.6 Database Utilities ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6.1 2.7-18 GNU C Library: Shared libraries ii libcomerr21.41.3-1 common error description library ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [ ii libkrb53 1.6.dfsg.4~beta1-5 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpam0g 1.0.1-5Pluggable Authentication Modules l ii libsasl2-22.1.22.dfsg1-23Cyrus SASL - authentication abstra ii libssl0.9.8 0.9.8g-15 SSL shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip sasl2-bin recommends no packages. sasl2-bin suggests no packages. -- debconf information: cyrus-sasl2/upgrade-sasldb2-failed: cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak * cyrus-sasl2/upgrade-sasldb2-backup-failed: cyrus-sasl2/purge-sasldb2: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520926: should be built with --enable-posixmutexes --with-mutex=POSIX/pthreads
Package: libdb4.7 Version: 4.7.25-6 Severity: normal tl;dr summary: It seems BerkeleyDB should be built with: --enable-posixmutexes --with-mutex=POSIX/pthreads on NPTL Linux systems, since native POSIX mutexes substantially lower context switches, at least with OpenLDAP's slapd. I've been working out a final OpenLDAP 2.4/BDB 4.x configuration, and wound up backporting DB4.7 to lenny (it's a straight rebuild except for the Java bindings, which my cursory examination suggests need Java 5). It was observed that Debian's BDB4.7 isn't built with POSIX mutexes (--enable-posixmutexes --with-mutex=POSIX/pthreads), which makes a big difference on modern Linux (NPTL) systems: http://marc.info/?l=openldap-software&m=123619904013849&w=2 The difference in context switches is huge, going from regular peaks of 120k-140k context switches in vmstat(1) output to a steady <2k cs when POSIX mutexes are enabled. This is with a fairly heavily loaded OpenLDAP slapd. FWIW, the only difference in the build is that mut_tas.c is linked in. I'm not super familiar with Linux threading support, but I surmise that adds support for native POSIX mutexes. The BDB test suite (run automatically by the packaging) is successful after adding these two build options. Stock Debian BDB4.7 packaging: procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 1 0 7376 43448 38868 3536772006228 621 4512 9 5 81 6 0 0 7376 42936 38868 353724800 100 0 720 135739 11 23 60 6 0 0 7376 42680 38868 3537548005272 801 1337 8 6 83 3 0 0 7376 42308 38876 3537900007428 953 1570 12 8 74 6 0 0 7376 41812 38876 353840400 10412 625 59447 9 15 71 5 0 0 7376 41564 38876 35386800054 0 726 76962 15 15 64 6 4 1 7376 41192 38884 3538996005626 650 127990 10 20 56 14 0 0 7376 40820 38884 3539332006856 702 39495 15 12 67 7 1 0 7376 40584 38884 35396520066 0 486 874 6 4 86 5 0 0 7376 40336 38892 3539928005022 617 1158 6 3 83 9 1 0 7376 40076 38900 3540140003836 517 888 5 4 85 7 0 1 7376 38976 38908 354121200 26032 629 927 5 2 26 67 4 1 7376 37952 38916 354221600 23842 581 4725 7 16 0 78 0 1 7376 37480 38916 35426800090 0 1121 7524 13 11 69 7 0 0 7376 36988 38916 35431880074 0 960 166086 15 21 52 13 0 0 7376 36852 38924 3543316001824 693 36271 13 13 69 6 2 0 7376 36604 38924 35435400048 0 481 40781 11 12 72 4 0 0 7376 36368 38924 35438640072 112 591 15125 10 5 79 7 0 1 7376 36112 38924 35441640062 6 678 35590 9 7 18 67 0 1 7376 35984 38932 3544584008436 690 1076 6 4 18 72 0 2 7376 35776 38948 3545056009250 374 603 3 2 48 47 BDB4.7 built with --enable-posixmutexes --with-mutex=POSIX/pthreads: 0 0 7380 1262216 37808 2388312001812 410 1056 3 3 87 6 0 0 7380 1261864 37808 23887160016 2 419 932 3 3 93 1 0 0 7380 1260768 37824 239017600 14058 719 1612 5 8 66 21 1 0 7380 1259792 37832 2391188006636 756 1267 6 9 80 6 0 0 7380 1266724 37856 2391804002490 579 957 4 4 86 5 2 0 7380 1265228 37872 2392276003652 593 946 5 5 85 4 0 0 7380 1260760 37896 239376800 23858 747 1314 7 7 78 8 0 0 7380 1260108 37896 23944480026 0 656 1741 5 6 89 1 0 0 7380 1259404 37904 2395168003420 709 1778 6 5 85 4 0 0 7380 1259896 37912 2395940003026 655 1625 7 6 83 4 0 1 7380 1259636 37920 2396616002812 598 1236 5 3 87 5 0 0 7380 1259016 37920 23971680028 0 553 1217 4 4 88 3 0 0 7380 1255232 37936 23978000032 100 791 1471 14 14 70 3 -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libdb4.7 depends on: ii libc6 2.7-18 GNU C Library: Shared libraries libdb4.7 recommends no packages. libdb4.7 suggests no packages. -- no debconf information -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE,
Bug#516374: Experiencing this with KVM, too
I'm experiencing the same thing sporadically with two machines running a handful of KVM VMs. It usually starts with one VM blocking, then spreads to the rest, and eventually the host itself stops responding. I cherry-picked the three patches in LP 276476 and applied them to the 2.6.28 kernel currently in sid. So far so good, but I don't have a solid test case to reproduce and it usually takes a couple days for this to show itself. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510495: memory profiler results
On Sun, Jan 18, 2009 at 02:03:32PM -0500, Dave Johnson wrote:
> It's unclear if ipAddressTable_cache_load is meant to handle IPv6
> addresses and if so, there is clearly brokenness for duplicate IPv6
> link local addresses (which will of course exist when VLANs are
> present)
>
> _check_entry_for_updates() only does a binary search for the first
> matching ipv4/ipv6 address, ignoring the fact duplicate ip addresses
> appear to be present in the list. Again, unclear if these duplicates
> should be in the list or not. someone more familiar with this code
> would have to comment.
Dug around in the upstream bug tracker a little, and found:
[ 1521999 ] ipAddrTable caching code leaks memory
https://sourceforge.net/tracker/index.php?func=detail&aid=1521999&group_id=12694&atid=112694
The patch attached to this upstream bug goes a little too far and
double-frees ipaddress_entry (ipAddressTable_release_rowreq_ctx() frees its
associated data automatically). I've modified it to remove the snmp_log()
noise and double-free; the resulting packaging diff is attached and has not
leaked during the ~half day it's been up here.
The lenny leak must be different, since this fix is already applied upstream
in the lenny snmpd.
john
--
John Morrissey _o/\ __o
j...@horde.net_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
--- net-snmp-5.2.3.orig/debian/patches/50_ipaddrtable_memleak.README
+++ net-snmp-5.2.3/debian/patches/50_ipaddrtable_memleak.README
@@ -0,0 +1 @@
+Fix IP address table memory leak.
--- net-snmp-5.2.3.orig/debian/patches/50_ipaddrtable_memleak.patch
+++ net-snmp-5.2.3/debian/patches/50_ipaddrtable_memleak.patch
@@ -0,0 +1,19 @@
+--- net-snmp-5.3.orig/agent/mibgroup/ip-mib/ipAddressTable/ipAddressTable_data_access.c 2005-12-01 11:00:57.0 -0600
net-snmp-5.3/agent/mibgroup/ip-mib/ipAddressTable/ipAddressTable_data_access.c 2006-07-13 10:39:52.816059620 -0500
+@@ -229,9 +229,13 @@ _add_new_entry(netsnmp_ipaddress_entry *
+ ipaddress_entry->ia_address_len,
+ ipaddress_entry->ia_address,
+ ipaddress_entry->ia_address_len))) {
+-CONTAINER_INSERT(container, rowreq_ctx);
+-rowreq_ctx->ipAddressLastChanged =
+-rowreq_ctx->ipAddressCreated = netsnmp_get_agent_uptime();
++if (CONTAINER_INSERT(container, rowreq_ctx) < 0) {
++DEBUGMSGTL (("ipAddressTable:access","container insert failed for new entry\n"));
++ipAddressTable_release_rowreq_ctx(rowreq_ctx);
++return;
++}
++rowreq_ctx->ipAddressLastChanged =
++rowreq_ctx->ipAddressCreated = netsnmp_get_agent_uptime();
+ } else {
+ if (NULL != rowreq_ctx) {
+ snmp_log(LOG_ERR, "error setting index while loading "
Bug#510495: memory profiler results
Ran valgrind on etch and lenny snmpds. The code has changed a bit between the two versions, but they leak in substantially the same way: while periodically fetching interface information to store in an in-memory cache. Not sure why valgrind(1) could resolve some symbols and not others in the same library; the libraries were stripped in both cases, since I used the stock Debian net-snmp binaries. I don't see any smoking guns, but in the lenny case, I suspect something's going sideways in ipAddressTable_container_load() where it's iterating over the list of interface information to find updates. I haven't had a chance to look that closely at the etch case. The next step would probably involve running snmpd in debug mode and comparing the output to what's being done in the source. Poking at the functions in these backtraces with gdb(1) might be more productive. etch: $ sudo valgrind --leak-check=full -- /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -f [...] ==19648== 411,201 (355,752 direct, 55,449 indirect) bytes in 549 blocks are definitely lost in loss record 87 of 87 ==19648==at 0x401C6CA: calloc (vg_replace_malloc.c:279) ==19648==by 0x409BB7E: ipAddressTable_allocate_rowreq_ctx (in /usr/lib/libnetsnmpmibs.so.9.0.1) ==19648==by 0x409F377: (within /usr/lib/libnetsnmpmibs.so.9.0.1) ==19648==by 0x4260D23: (within /usr/lib/libnetsnmp.so.9.0.1) ==19648==by 0x409F20A: ipAddressTable_cache_load (in /usr/lib/libnetsnmpmibs.so.9.0.1) ==19648==by 0x409C717: (within /usr/lib/libnetsnmpmibs.so.9.0.1) ==19648==by 0x41D0D47: (within /usr/lib/libnetsnmphelpers.so.9.0.1) ==19648==by 0x42466E2: run_alarms (in /usr/lib/libnetsnmp.so.9.0.1) ==19648==by 0x804AF57: (within /usr/sbin/snmpd) ==19648==by 0x42FD3BD: (below main) (libc-start.c:237) ==19648== ==19648== LEAK SUMMARY: ==19648==definitely lost: 359,396 bytes in 558 blocks. ==19648==indirectly lost: 58,689 bytes in 2,242 blocks. ==19648== possibly lost: 0 bytes in 0 blocks. ==19648==still reachable: 441,165 bytes in 15,242 blocks. ==19648== suppressed: 0 bytes in 0 blocks. lenny: $ sudo valgrind --leak-check=full -- /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -f [...] ==29991== 358,392 (188,352 direct, 170,040 indirect) bytes in 2,616 blocks are definitely lost in loss record 112 of 113 ==29991==at 0x4C203E4: calloc (vg_replace_malloc.c:397) ==29991==by 0x53684DC: netsnmp_access_ipaddress_entry_create (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==29991==by 0x5369054: _load_v6 (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==29991==by 0x53694F3: netsnmp_arch_ipaddress_container_load (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==29991==by 0x5368936: netsnmp_access_ipaddress_container_load (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==29991==by 0x534B495: ipAddressTable_container_load (in /usr/lib/libnetsnmpmibs.so.15.1.0) ==29991==by 0x5076F83: (within /usr/lib/libnetsnmphelpers.so.15.1.0) ==29991==by 0x564343B: run_alarms (in /usr/lib/libnetsnmp.so.15.1.0) ==29991==by 0x40456C: main (in /usr/sbin/snmpd) ==29991== ==29991== LEAK SUMMARY: ==29991==definitely lost: 189,639 bytes in 2,628 blocks. ==29991==indirectly lost: 171,048 bytes in 7,861 blocks. ==29991== possibly lost: 0 bytes in 0 blocks. ==29991==still reachable: 1,144,617 bytes in 17,142 blocks. ==29991== suppressed: 0 bytes in 0 blocks. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510495: default install of snmpd leaks memory when VLAN interfaces present
I can confirm this. I have a small handful of lenny machines and the ones with VLAN subints are leaking the same way. If I have some time next week, I'll try to throw a memory profiler on it to see how it's leaking. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511914: domain kernel BUGs on SCSI disk access
On Thu, Jan 15, 2009 at 06:29:03PM +0100, Guido Günther wrote: > On Thu, Jan 15, 2009 at 11:47:23AM -0500, John Morrissey wrote: > > Domains with a SCSI disk attached: > > > > > > > > > > > > > > BUG after accessing the SCSI disk. This is readily reproducible with a lenny > > amd64 host installing lenny amd64 in a domain. mkfsing the domain's > > filesystems fails, d-i prompts you to Retry, Ignore, or Cancel, and choosing > > Cancel generates the Oops (below). > > Could you try to verify if this also hits with a raw iscsi partition > instead of qcow? You mean an image of type 'raw' via scsi? I tried a couple installs that way and could not reproduce this behavior. > As to your question how to run without libvirt to try the > -no-kvm/-no-kvm-irqchip options. Try: > > /usr/bin/kvm -M pc -m 512 -smp 1 -name test \ > -boot c -drive file=image.qcow,if=scsi,index=0,boot=on > -serial pty -parallel none -usb -vnc 0.0.0.0:1 ach, I see now; -S tripped me up. Thanks. john -- John Morrissey _o/\ __o j...@horde.net_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511914: domain kernel BUGs on SCSI disk access
Package: kvm Version: 82+dfsg-1 Severity: important Domains with a SCSI disk attached: BUG after accessing the SCSI disk. This is readily reproducible with a lenny amd64 host installing lenny amd64 in a domain. mkfsing the domain's filesystems fails, d-i prompts you to Retry, Ignore, or Cancel, and choosing Cancel generates the Oops (below). Removing CVE-2008-0928-fedora.patch from the kvm packaging in experimental "fixes" this behavior. FWIW, I originally thought this was fixed by updating to the latest CVE-2008-0928-fedora.patch from Fedora, for KVM 81 and up (http://marc.info/?l=kvm&m=123032725115808&w=2), but it appears I was mistaken or my testing flawed somehow, since I can reproduce this behavior every time I try to boot/install any host from/to a SCSI disk. [ 475.585212] BUG: unable to handle kernel NULL pointer dereference at 0358 [ 475.588015] IP: [] :sym53c8xx:sym_int_sir+0x5d9/0x12d5 [ 475.588015] PGD 1d155067 PUD 1b0f7067 PMD 0 [ 475.588015] Oops: [1] SMP [ 475.588015] CPU 0 [ 475.588015] Modules linked in: dm_mod md_mod xfs reiserfs jfs ext3 jbd vfat fat nls_base ext2 mbcache sd_mod ide_cd_mod cdrom sym53c8xx scsi_transport_spi piix ide_core usb_storage scsi_mod fan virtio_balloon floppy virtio_pci virtio_ring virtio e1000 uhci_hcd thermal processor thermal_sys [ 475.588015] Pid: 8378, comm: parted_server Not tainted 2.6.26-1-amd64 #1 [ 475.588015] RIP: 0010:[] [] :sym53c8xx:sym_int_sir+0x5d9/0x12d5 [ 475.588015] RSP: 0018:805e2d38 EFLAGS: 00010287 [ 475.588015] RAX: 000a RBX: 000b RCX: 0046 [ 475.588015] RDX: 81001f80d000 RSI: 1b5a2090 RDI: c2162006 [ 475.588015] RBP: 81001b5a2000 R08: 805e2f10 R09: 0046 [ 475.588015] R10: 81001b5a2000 R11: a00694d9 R12: 81001b5a2090 [ 475.588015] R13: R14: R15: 1dcba901 [ 475.588015] FS: 7f9a023bf6e0() GS:8053b000() knlGS: [ 475.588015] CS: 0010 DS: ES: CR0: 8005003b [ 475.588015] CR2: 0358 CR3: 1b4b7000 CR4: 06e0 [ 475.588015] DR0: DR1: DR2: [ 475.588015] DR3: DR6: 0ff0 DR7: 0400 [ 475.588015] Process parted_server (pid: 8378, threadinfo 81001e05, task 81001d54c340) [ 475.588015] Stack: 80604c5c 002e 1dcba902 [ 475.588015] 0096 0282 22de72ef 0282 [ 475.588015] 373420205b3e343c 0001 81001b5a2000 [ 475.588015] Call Trace: [ 475.588015][] ? :sym53c8xx:sym_interrupt+0x431/0x64a [ 475.588015] [] ? :sym53c8xx:sym53c8xx_intr+0x40/0x65 [ 475.588015] [] ? handle_IRQ_event+0x2c/0x61 [ 475.588015] [] ? handle_fasteoi_irq+0x90/0xc8 [ 475.588015] [] ? :scsi_mod:scsi_next_command+0x2d/0x39 [ 475.588015] [] ? do_IRQ+0x6d/0xd9 [ 475.588015] [] ? ret_from_intr+0x0/0x19 [ 475.588015] [] ? :scsi_mod:scsi_done+0x0/0x18 [ 475.588015] [] ? __do_softirq+0x4a/0xd1 [ 475.588015] [] ? ack_apic_level+0x53/0xd8 [ 475.588015] [] ? call_softirq+0x1c/0x28 [ 475.588015] [] ? do_softirq+0x3c/0x81 [ 475.588015] [] ? irq_exit+0x3f/0x83 [ 475.588015] [] ? do_IRQ+0xb9/0xd9 [ 475.588015] [] ? ret_from_intr+0x0/0x19 [ 475.588015][] ? _spin_unlock_irqrestore+0x7/0xe [ 475.588015] [] ? :scsi_mod:scsi_dispatch_cmd+0x1ea/0x26c [ 475.588015] [] ? :scsi_mod:scsi_request_fn+0x2be/0x395 [ 475.588015] [] ? elv_insert+0x153/0x220 [ 475.588015] [] ? __make_request+0x3af/0x3fb [ 475.588015] [] ? generic_make_request+0x2fe/0x339 [ 475.588015] [] ? bio_alloc_bioset+0x89/0xd9 [ 475.588015] [] ? submit_bio+0xdb/0xe2 [ 475.588015] [] ? dio_bio_submit+0x52/0x66 [ 475.588015] [] ? __blockdev_direct_IO+0x7bd/0x9f2 [ 475.588015] [] ? blkdev_direct_IO+0x45/0x4a [ 475.588015] [] ? blkdev_get_blocks+0x0/0x96 [ 475.588015] [] ? generic_file_direct_IO+0xff/0x118 [ 475.588015] [] ? generic_file_direct_write+0x60/0xf5 [ 475.588015] [] ? __generic_file_aio_write_nolock+0x286/0x3a9 [ 475.588015] [] ? generic_file_aio_read+0xce/0x4a9 [ 475.588015] [] ? path_walk+0x7e/0x8b [ 475.588015] [] ? generic_file_aio_write_nolock+0x34/0x80 [ 475.588015] [] ? do_sync_write+0xc9/0x10c [ 475.588015] [] ? autoremove_wake_function+0x0/0x2e [ 475.588015] [] ? vfs_write+0xad/0x156 [ 475.588015] [] ? sys_write+0x45/0x6e [ 475.588015] [] ? system_call_after_swapgs+0x8a/0x8f [ 475.588015] [ 475.588015] [ 475.588015] Code: 48 89 c6 48 c7 c7 94 37 0e a0 eb 5d 48 8d bb 20 01 00 00 e8 00 32 2a e0 48 8d 93 58 02 00 00 48 89 c6 48 c7 c7 ce 37 0e a0 eb 67 <49> 8b 95 58 03 00 00 48 8b 82 d0 00 00 00 48 8b 1a 48 8b a8 a0 [ 475.588015] RIP [] :sym53c8xx:sym_int_sir+0x5d9/0x12d5 [ 475.588015] RSP [ 475.588015] CR2: 0
Bug#500731: Default search scope for LDAPServer URLs is 'base'
On Thu, Oct 02, 2008 at 01:36:54PM -0400, John Morrissey wrote: > [apologies if you're receiving duplicates of this, Christoph and Frankie; > I always forget who the BTS copies by default] > > This thread on the ProFTPD forums is related: > > http://forums.proftpd.org/smf/index.php?topic=3528.0 On a related note, I've committed changes that prevent the use of LDAPSearchScope (and LDAPUseSSL) when LDAPServer specifies a URL. http://proftp.cvs.sourceforge.net/viewvc/proftp/proftpd/contrib/mod_ldap.c?view=log#rev1.69 john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500731: Default search scope for LDAPServer URLs is 'base'
[apologies if you're receiving duplicates of this, Christoph and Frankie; I always forget who the BTS copies by default] This thread on the ProFTPD forums is related: http://forums.proftpd.org/smf/index.php?topic=3528.0 In a nutshell, RFC 2255 specifies that the default search scope for an LDAP URL is 'base' (when no scope is explicitly specified). I understand that 'subtree' is generally what people want in this case, but I'm inclined to follow what's outlined in the RFC. Arguments to the contrary are welcome, but please keep in mind that I like to adhere to standards as much as possible. :-) FWIW, I updated the docs for LDAPServer at the time to mention this: Note that the default search scope for LDAP URLs is 'base' if a scope is not explicitly specified in the URL. This behavior differs from the LDAPSearchScope directive, which defaults to 'subtree'. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500709: nagios3: Home directory should not be in an ephemeral hier
Package: nagios3 Version: 3.0.3-2 Severity: normal The nagios user's home directory is set to /var/run/nagios3, but /var/run is cleared on every boot per the FHS. /var/run is emptied on every boot, which removes all ssh known host keys and causes subsequent check_ssh service checks to fail (the corresponding services go critical) until the remote servers' host keys are manually added to ~nagios/.ssh/known_hosts. It seems like /var/lib/nagios3 might be a better choice for the nagios user's home directory, to avoid this kind of failure mode. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-alpha-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492345: quagga: bgpd picks wrong nexthop on point-to-point interfaces
On Fri, Jul 25, 2008 at 07:20:55PM +0200, Christian Hammers wrote: > You better ask again on the quagga-dev/user mailing list for a comment > on this bug and, if you have time, add some examples how a Cisco would act > or what the RFCs say etc. Thanks for your reply; I followed up to quagga-dev. This problem seems fairly straightforward; unless I'm missing something, there is absolutely no reason for bgpd(8) to see the *local* end of a point-to-point link as the proper nexthop when announcements are being received from the *remote* end of the tunnel. We'll see what they have to say. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492345: quagga: bgpd picks wrong nexthop on point-to-point interfaces
Package: quagga
Version: 0.99.5-5etch3horde1
Severity: normal
I reported this bug upstream a few months ago and haven't been able to get
any response, though this seems broken in a fairly obvious manner(?).
It's probably too late to have any fix make the lenny freeze, but I'm hoping
that giving this bug more exposure might help bring it to the attention of
the right people. Christian, I'm sure you know the quagga source better than
I do, and maybe you know someone who hacks on Quagga that might be
interested in looking at this?
http://marc.info/?l=quagga-users&m=120576712714935&w=2
http://bugzilla.quagga.net/show_bug.cgi?id=445
I'm running IBGP over a GRE tunnel:
[EMAIL PROTECTED]:pts/5 ~> ifconfig gre1
gre1 Link encap:UNSPEC HWaddr
AC-10-41-02-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.17.65.2 P-t-P:172.17.65.1 Mask:255.255.255.255
zebra gets the endpoints right:
boost# sh int gre1
Interface gre1 is up, line protocol detection is disabled
index 18 metric 1 mtu 1476
flags:
HWaddr: ac:10:41:02
inet 172.17.65.2/32 pointopoint 172.17.65.1
374 input packets (0 multicast), 30117 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
544 output packets, 47274 bytes, 0 dropped
3 output errors, 0 aborted, 3 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
as does bgpd, but it detects the wrong end of the tunnel as the nexthop
(i.e., it sees itself as the only legitimate nexthop instead of the opposite
end of the tunnel):
boost# sh ip bgp nei
[...]
Local host: 172.17.65.2, Local port: 36205
Foreign host: 172.17.65.1, Foreign port: 179
Nexthop: 172.17.65.2
Since I have 'set nexthop self' in the peer (OpenBSD bgpd(8)), quagga bgpd
rejects all of its announcements:
172.17.65.1 rcvd UPDATE about 192.168.197.16/28 -- DENIED due to: martian
next-hop;
If I remove the bgp_nexthop_self() check:
--- quagga-0.99.5.orig/bgpd/bgp_route.c
+++ quagga-0.99.5/bgpd/bgp_route.c
@@ -1934,8 +1934,7 @@
/* Next hop must not be 0.0.0.0 nor Class E address. Next hop
must not be my own address. */
- if (bgp_nexthop_self (afi, &new_attr)
- || new_attr.nexthop.s_addr == 0
+ if (new_attr.nexthop.s_addr == 0
|| ntohl (new_attr.nexthop.s_addr) >= 0xe000)
{
reason = "martian next-hop;";
the announcements are accepted and have the correct next hop:
[EMAIL PROTECTED]:pts/5 ~> netstat -rn
[...]
192.168.197.16 172.17.65.1 255.255.255.240 UG0 0 0
gre1
Shouldn't BGP neighbor output be showing the opposite end of the GRE tunnel
as the next hop, not itself?
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: alpha
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-alpha-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages quagga depends on:
ii adduser3.102 Add and remove users and groups
ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy
ii iproute20061002-3Professional tools to control the
ii libc6.12.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii libcap11:1.10-14 support for getting/setting POSIX.
ii libpam0g 0.79-5Pluggable Authentication Modules l
ii libreadline5 5.2-2 GNU readline and history libraries
ii logrotate 3.7.1-3 Log rotation utility
quagga recommends no packages.
-- debconf information:
* quagga/really_stop: true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#248061: some link detection code all ready there
On Sun, Mar 02, 2008 at 08:30:17PM +0100, Frans Pop wrote: > On Wednesday 27 February 2008, John Morrissey wrote: > > These interfaces take a while to negotiate a link, probably because > > spanning tree is enabled on the switch ports they're attached to, so it > > necessarily takes a while for the port to enter the forwarding state. Is > > there a way to have d-i/netcfg sleep for a longer (configurable?) period > > of time before assuming no link has been negotiated? > > OK. One way to test this theory would be to run an installation with > 'install priority=medium' and wait for some time between the network > hardware detection step and the network configuration step. > And maybe check dmesg or VT4 in between for link detection messages. > > Does that result in reliable automatic selection of the connected NIC? > > If it does, how long is the delay between the driver being loaded and the > link coming up (/var/log/syslog should be able to tell you)? According to the switch, the link comes up when the machine boots (we PXE boot for our installs), ascends to spanning-tree listening state, and remains up when d-i starts. When the module for the interfaces is loaded, the link stays up (on the switch side; d-i syslogs don't indicate anything about link, and ifconfig(8) shows them as down: i.e., they do not appear in 'ifconfig' output, but do appear in 'ifconfig -a' as 'BROADCAST MULTICAST' and not 'UP' or 'RUNNING'). When I hit 'Configure network interfaces,' netcfg must throb the interface somehow, since it goes from forwarding state to listening state on the switch: sw06.roch.ny#sh int g0/31 GigabitEthernet0/31 is up, line protocol is up (connected) [...] sw06.roch.ny#sh spanning-tree interface g0/31 Vlan Role Sts Cost Prio.Nbr Type --- - VLAN0090 Desg FWD 4 128.31 P2p [... select 'Configure Network Interfaces'] sw06.roch.ny#sh spanning-tree interface g0/31 Vlan Role Sts Cost Prio.Nbr Type --- - VLAN0090 Desg LIS 19128.31 P2p [... time goes by] sw06.roch.ny#sh spanning-tree interface g0/31 Vlan Role Sts Cost Prio.Nbr Type --- - VLAN0090 Desg FWD 4 128.31 P2p The interface list does not indicate that either interface has link, and the syslogs say: main-menu[1188]: INFO: Menu item 'netcfg' selected kernel: bnx2: eth0: using MSI netcfg[2842]: INFO: eth0 is disconnected. (MII) netcfg[2842]: INFO: eth0 is not a wireless interface. Continuing. Once I choose to use DHCP on the interface, dhclient starts and, two seconds later, the kernel shows that the device has link: kernel: bnx2: eth0: using MSI kernel: bnx2: eth0 NIC Link is Up, 1000Mbps full duplex However, something has again booted the switch port back into spanning-tree listening state and the port must again ascend to forwarding state. Because of this, dhclient spins for a while and successfully gets an IP address 37 seconds after link is detected by the kernel. I don't know what the default timeout is OTTOMH, but without overriding it, network autoconfiguration fails every time. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468409: libnss-ldap: way of being less noisy when LDAP server unavailable
Package: libnss-ldap Version: 251-7.5etch1 Severity: wishlist nss_ldap is fairly chatty when reporting lookup failures or problems reaching the configured LDAP server(s). For example: Feb 28 03:52:05 coral sshd[5454]: nss_ldap: reconnected to LDAP server ldap://1.2.3.4 after 1 attempt If the LDAP server is unreachable, it seems to log a warning for each nameservice call that fails. Some of our machines only have intermittent connectivity to their LDAP servers, so they log several megabytes of this daily. For now, we're going to look at filtering it out at the syslog level (we run syslog-ng). I looked at the source, and there doesn't seem to be a way to disable these log messages. Would adding that be useful for others, or perhaps implementing some very basic rate limiting? -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-alpha-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#248061: some link detection code all ready there
On Fri, Nov 09, 2007 at 11:50:32AM +0100, Geert Stappers wrote: > After some research, I found out that my eth1 indeed had no MII ioctl > support. So the installer was right to ask for choosing a NIC. > > People with multiple NICs, that do have MII ioctl support, > in their installed system and see that the live interface is detected, > please be carefull with closing this bugreport, because it is merged > with other bugreports. > > Confirming that "link detection" works is appreciated. We have a number of Dell PowerEdge machines that do not indicate which interface has link when running d-i. dmesg(8) says the adapters are: eth0: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet eth1: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet and mii-tool(8) does detect the presence or absence of link: eth0: negotiated 100baseTx-FD, link ok eth1: no link These interfaces take a while to negotiate a link, probably because spanning tree is enabled on the switch ports they're attached to, so it necessarily takes a while for the port to enter the forwarding state. Is there a way to have d-i/netcfg sleep for a longer (configurable?) period of time before assuming no link has been negotiated? john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463260: apt-utils: apt-ftparchive caches hashes too aggressively?
On Thu, Jan 31, 2008 at 12:31:19PM -0500, Lord of, St. Luke Valor wrote: > Any software engineer will willfully tell you that software development > involves planned chaos. It is obvious to this computer scientist that you > have enough experience with networking and system management to know that > 'keep it simple' is the order of the day. The easy way is scientific > enough. I suggest the easy solution to be the investigation, acquisition > and installation of software from the subversion project. It is a > replacement for CVS, which supersedes RCS and complements the apt suite. > > Think of it as one more tool in the toolkit. Yes, we already make extensive use of Subversion in our environment. We store package sources in Subversion, build them into .debs, and insert them into a local APT repository. Our goal is to have our infrastructure follow the core operating system's lead as much as possible, and this goal seems to dovetail nicely with using locally maintained .debs and a local APT repo. Subversion, on the other hand, is not a packaging system and is not integrated with the core OS. We could very well distribute a set of scripts (using Subversion) that would apply the necessary configuration changes to our dozens of machines running Debian, but then we're back to the question of how to invoke these scripts, enforce dpkg dependencies, handle failure, interact with the user, and all of the other problems that dpkg and APT have already solved quite nicely. So I'm not sure how your suggestion to expand our use of Subversion will fix or work around the behavior in apt-ftparchive I'm asking about in this bug. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463260: apt-utils: apt-ftparchive caches hashes too aggressively?
Package: apt-utils Version: 0.6.46.4-0.1 Severity: normal A little background (thought this might be useful to understand our use cases): We preseed d-i to build new machines, and have local packages that can turn this base installation into nearly every type of machine we manage (e-mail, web servers, application servers, etc.) simply by installing the appropriate .deb from our local APT repository. These packages Depends: on the appropriate packages, and have file contents and maintainer scripts that set the machine up automatically. These packages are built with dpkg-deb(1), since there isn't really any "source" to build a binary package from. Instead, we have a hier (with a DEBIAN directory) for each package that we drop files and maintainer scripts into. We then have a wrapper around dpkg-deb(1) that builds the .deb and inserts it into our local repo, then runs apt-ftparchive to update the repo metadata. We have apt-ftparchive use its cache, since it obviously makes a significant reduction in how long it takes to update the metadata. It seems apt-ftparchive might be too aggressive with its caching. When a .deb changes, apt-ftparchive doesn't notice and continues to use metadata (file size, MD5sum, etc.) from the cache. When attempting to install a package affected by this, apt-get(1) yields: Failed to fetch http://example.com/debian/dists/isis/main/binary-i386/isis-mx-server_1.8-1_all.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Generally, a package shouldn't change once built with a given version, but people occasionally forget to bump a package's version before building, which creates a lot of confusion until they realize what happened, and the reason for it. Sometimes people mistakenly rebuild a package, too, and a simple rebuild (with no content change) causes the .deb's MD5sum to change. Occasionally, it's also useful for us to make changes to the existing version of a package so we can avoid an unnecessary package update on machines with it installed. For example, if we make an emergency configuration change on the machines themselves, it's useful to modify the package hier and rebuild with the same version number, saving a package update on the machines that would have no net effect. I realize this isn't (AFAIK) a typical use case in Debian proper. Lastly, the version of apt-ftparchive in sarge did not exhibit this aggressive caching; if a .deb in the repo changed, the cache metadata was updated. I'm not sure what apt-ftparchive checked; maybe file mtime on the .deb? Is there a way to avoid/change this aggressive caching without having to stop using the cache? Our repo isn't huge by Debian standards, but it still takes a couple minutes to rebuild without the cache, and we'd like to avoid going cacheless or having to periodically remove the cache when we encounter this behavior. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-alpha-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages apt-utils depends on: ii apt [libapt-pkg-libc6. 0.6.46.4-0.1 Advanced front-end for dpkg ii libc6.12.3.6.ds1-13etch4 GNU C Library: Shared libraries ii libdb4.4 4.4.20-8 Berkeley v4.4 Database Libraries [ ii libgcc11:4.1.1-21GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 apt-utils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463156: separate postfix- subpackage for postmap
Package: postfix Version: 2.3.8-2 Severity: wishlist We have a number of machines running Postfix with large (~100MB) hash maps. These maps are identical across all machines, and given the time it takes postmap(1) to generate them, we would like to build the binary maps (*.db) on a central host for distribution to these machines, instead of distributing the map sources to the machines and having each one build its own copy. We'd rather not install the full postfix package on this central host, so it would be nice to have a separate package containing support binaries for Postfix. Currently, this looks like just postmap(1). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-alpha-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages postfix depends on: ii adduser3.102 Add and remove users and groups ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii dpkg 1.13.25 package maintenance system for Deb ii libc6.12.3.6.ds1-13etch4 GNU C Library: Shared libraries ii libdb4.3 4.3.29-8 Berkeley v4.3 Database Libraries [ ii libsasl2-2 2.1.22.dfsg1-8Authentication abstraction library ii libssl0.9.80.9.8c-4etch1 SSL shared libraries ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii netbase4.29 Basic TCP/IP networking system ii ssl-cert 1.0.14Simple debconf wrapper for openssl Versions of packages postfix recommends: ii mailx [mail-read 1:8.1.2-0.20050715cvs-1 A simple mail user agent ii mutt [mail-reade 1.5.13-1.1etch1 text-based mailreader supporting M -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440812: num_backups in svn-hot-backup is overwritten on package upgrade
Package: subversion-tools Version: 1.4.2dfsg1-2 Severity: normal svn-hot-backup has a configuration directive at the top of the script to control how many backup iterations to keep, which defaults to 64: # Number of backups to keep around (0 for "keep them all") num_backups = 64 Our repo is quite large, and we don't have the disk space to keep 64 copies. Editing /usr/bin/svn-hot-backup is required to change this value, and since the script is not a conffile, the change is overwritten when the package is reinstalled. I would include a patch, but there are other configurable items and I'm not sure if the best way is to add command line arguments for them all or have a separate configuration file. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages subversion-tools depends on: ii subversion 1.4.2dfsg1-2 Advanced version control system Versions of packages subversion-tools recommends: pn libconfig-inifiles-perl(no description available) pn libsvn-perl(no description available) ii liburi-perl 1.35-2 Manipulates and accesses URI strin pn python-subversion (no description available) ii sendmail-bin [mail-transport- 8.13.8-3 powerful, efficient, and scalable pn xsltproc (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429162: bulkwalk completely broken in asynchronous mode
On Sat, Jun 16, 2007 at 02:00:58AM +, John Morrissey wrote: > bulkwalk is completely broken when used in asynchronous mode. Sorry, I misspoke and should have said *synchronous* mode. Asynchronous mode (whereby the fetched values are returned via a Perl callback) seems to be working fine. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429162: bulkwalk completely broken in asynchronous mode
Package: libsnmp-perl
Version: 5.2.3-7
Severity: important
Tags: patch
bulkwalk is completely broken when used in asynchronous mode. The version in
sarge (5.1.2-6.2) works fine, and bulkwalk() returns:
$VAR1 = [
bless( [
bless( [
'.1.3.6.1.2.1.1.3',
'0',
'68110026',
'TICKS'
], 'SNMP::Varbind' )
], 'SNMP::VarList' ),
bless( [
bless( [
'.1.3.6.1.2.1.2.1',
'0',
'6',
'INTEGER32'
], 'SNMP::Varbind' )
], 'SNMP::VarList' ),
[...]
However, the version in etch (5.2.3-7) returns:
$VAR1 = [
bless( {
'UseLongNames' => 2,
'UseEnums' => 0,
'UseNumeric' => 1,
'BestGuess' => 0,
'SessPtr' => bless( do{\(my $o = 136870504)},
'SnmpSessionPtr' ),
'LocalPort' => 0,
'ErrorStr' => '',
'UseSprintValue' => 0,
'Community' => 'elided',
'ErrorNum' => 0,
'RetryNoSuch' => 0,
'UseEnum' => 0,
'Retries' => -1,
'RemotePort' => 161,
'Version' => '2c',
'ErrorInd' => 0,
'DestHost' => 'localhost:161',
'Timeout' => -1
}, 'SNMP::Session' ),
2,
16,
bless( [
bless( [
'sysUpTime'
], 'SNMP::Varbind' ),
bless( [
'ifNumber'
], 'SNMP::Varbind' ),
bless( [
'ifSpeed'
], 'SNMP::Varbind' ),
bless( [
'ifDescr'
], 'SNMP::Varbind' )
], 'SNMP::VarList' )
];
This is apparently because SNMP.xs isn't modifying the Perl stack pointer
correctly, which makes sense because bulkwalk() in the second case is
returning a value suspiciously similar to its arguments.
This upstream bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1533078&group_id=12694&atid=112694
contains a patch (192507: perlpatch) that makes bulkwalk() work correctly in
asynchronous mode. This also seems to affect 5.3.1-6, currently in unstable.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libsnmp-perl depends on:
ii libsnmp95.2.3-7 NET SNMP (Simple Network Managemen
ii perl5.8.8-7 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.8. 5.8.8-7 The Pathologically Eclectic Rubbis
libsnmp-perl recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422557: mutt: thread markers make index lines wrap incorrectly in UTF-8 locales
On Wed, May 09, 2007 at 10:03:03AM +0200, Alain Bench wrote: > On Sunday, May 6, 2007 at 17:50:29 -0400, John Morrissey wrote: > > When displaying an index in threaded mode, the thread markers (for > > messages nested in a thread) make lines wrap correctly. After some > > movement of the highlight bar, the display becomes fairly unable > > without an explicit refresh (^L). > > When looking at your UTF-8 screen copy, the primary problem seems to > be broken thread markers. The incorrect wrapping seems to only be a > secondary consequence. > > But why are semi-graphic chars broken? There could be a lot of > reasons to explore, but I'd first guess that may look like an UTF-8 > locale on a Latin-1 terminal. What happens in PuTTY when you set > Window --> Translation --> UTF-8, in addition to LANG=en_US.UTF-8? Sorry for the delay, Alain; I've been tinkering with several terminal programs, checking my encoding settings. That seems to be it, at least for PuTTY; I must have had the encoding set to ISO-8859-1. I can't reproduce this any more with gnome-terminal; perhaps there was a similar situation. I tried Mac OS X's Terminal again and the index lines are still wrapping with LANG=en_US.UTF-8 and Terminal -> Window Settings... -> Display -> Character Set Encoding set to "Unicode (UTF-8)". I've attached a screen shot (FWIW, this is with TERM=vt100. TERM=xterm-color is similar, but in color). iTerm (http://iterm.sourceforge.net/) exhibits similar behavior, but I can't find any character encoding settings in its preferences. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ <>
Bug#424692: --remove-files complains that directories "changed as we read it"
Package: tar
Version: 1.16-2
Severity: normal
When creating an archive when --remove-files is specified, tar iterates over
the files in each directory, adding them to the archive and unlinking them.
Once the directory is empty, the directory itself is removed.
However, since tar(1) itself modified the directory, the directory has
changed since tar started operating on it, and tar complains. This also
causes tar's exit status to become non-zero (i.e., failure).
Here is a simple example:
[EMAIL PROTECTED]:pts/6 ~> mkdir foo
[EMAIL PROTECTED]:pts/6 ~> echo hi >foo/bar
[EMAIL PROTECTED]:pts/6 ~> tar cf tarball.tar --remove-files foo
tar: foo: file changed as we read it
[EMAIL PROTECTED]:pts/6 ~/a> echo $?
1
Here is strace(1) output (not for the example mentioned above, but a similar
case where I first noticed this behavior):
[pid 13977] lstat64("./DEBIAN/.svn/text-base", {st_mode=S_IFDIR|0755,
st_size=1024, ...}) = 0
[pid 13977] open("./DEBIAN/.svn/text-base",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
[pid 13977] open("/proc/self/fd/4/.",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
[pid 13977] fstat64(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13977] fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
[pid 13977] close(4)= 0
[pid 13977] getdents64(5, /* 8 entries */, 32768) = 288
[pid 13977] getdents64(5, /* 0 entries */, 32768) = 0
[pid 13977] close(5)= 0
[...]
[pid 13977] lstat64("./DEBIAN/.svn/text-base/conffiles.svn-base",
{st_mode=S_IFREG|0444, st_size=261, ...}) = 0
[pid 13977] open("./DEBIAN/.svn/text-base/conffiles.svn-base",
O_RDONLY|O_LARGEFILE) = 4
[pid 13977] read(4, "/etc/iptables.d/10isis-www-serve"..., 261) = 261
[pid 13977] fstat64(4, {st_mode=S_IFREG|0444, st_size=261, ...}) = 0
[pid 13977] close(4)= 0
[pid 13977] unlink("./DEBIAN/.svn/text-base/conffiles.svn-base") = 0
[pid 13977] lstat64("./DEBIAN/.svn/text-base", {st_mode=S_IFDIR|0755,
st_size=1024, ...}) = 0
[pid 13977] write(2, "tar: ", 5tar: )= 5
[pid 13977] write(2, "./DEBIAN/.svn/text-base: file ch"...,
51./DEBIAN/.svn/text-base: file changed as we read it) = 51
[pid 13977] write(2, "\n", 1) = 1
[pid 13977] rmdir("./DEBIAN/.svn/text-base") = 0
It's noteworthy that the tar(1) from sarge (1.14-2.3) does not exhibit this
behavior. I suspect this is because that version does not unlink empty
directories when --remove-files is specified. Rather, it leaves them for the
user to clean up. strace(1) output from the older tar is the same, except
for the write() for the error message and rmdir().
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages tar depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
tar recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410933: Workaround for percpu, relocation errors with SMP kernels
On Mon, May 14, 2007 at 04:55:19PM -0700, Steve Langasek wrote: > Well, very much a kludge. :) Certainly; you'll hear no argument from me. :-) > The patch already in the BTS for raising the size of the percpu storage is > much cleaner, but it hasn't been applied to the Debian kernels yet because > so many of the modules that fail to load because of percpu also fail with > the percpu fix because of relocation problems that I don't have a handle > on. But ISTR that it did fix the ipv6 module in particular, so it might > be worth trying for you? Yes, I had tried the percpu patch and it did fix the ipv6 module. The kludge from my last post also applies it, since it doesn't hurt anything and might fix other modules whose brokenness hasn't been noticed. Unfortunately, as you mention, the netfilter modules can't be loaded due to relocation errors unrelated to the percpu problem. So while I was packing the shot, I figured I'd just build ipv6 staticly and be done with it. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410933: Workaround for percpu, relocation errors with SMP kernels
In case anyone else is interested in a kludge/workaround for this, attached is the patch I use locally to apply the percpu data patch and build the IPv6 and Netfilter modules staticly (= not as modules), as these have been the only problematic modules on Alpha SMP that I've run into. Some caveats: - This patch will only build a -smp kernel, since that's all I need. - The ABI check was complaining; I didn't bother making it happy in a proper manner, but rather shut it up by commenting it out. john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ diff -urN stock/linux-2.6-2.6.18.dfsg.1/debian/arch/alpha/defines linux-2.6-2.6.18.dfsg.1/debian/arch/alpha/defines --- stock/linux-2.6-2.6.18.dfsg.1/debian/arch/alpha/defines 2007-03-23 13:12:57.0 -0400 +++ linux-2.6-2.6.18.dfsg.1/debian/arch/alpha/defines 2007-03-22 15:24:35.0 -0400 @@ -1,8 +1,8 @@ [base] -flavours: alpha-generic alpha-smp alpha-legacy +flavours: alpha-smp kernel-arch: alpha kernel-header-dirs: alpha -subarches: vserver +subarches: [image] suggests: aboot, fdutils diff -urN stock/linux-2.6-2.6.18.dfsg.1/debian/arch/config linux-2.6-2.6.18.dfsg.1/debian/arch/config --- stock/linux-2.6-2.6.18.dfsg.1/debian/arch/config 2007-03-23 13:12:57.0 -0400 +++ linux-2.6-2.6.18.dfsg.1/debian/arch/config 2007-03-22 23:00:28.0 -0400 @@ -409,13 +409,13 @@ # IPVS application helper # CONFIG_IP_VS_FTP=m -CONFIG_IPV6=m +CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y -CONFIG_INET6_AH=m -CONFIG_INET6_ESP=m -CONFIG_INET6_IPCOMP=m -CONFIG_INET6_TUNNEL=m -CONFIG_IPV6_TUNNEL=m +CONFIG_INET6_AH=y +CONFIG_INET6_ESP=y +CONFIG_INET6_IPCOMP=y +CONFIG_INET6_TUNNEL=y +CONFIG_IPV6_TUNNEL=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y @@ -423,96 +423,96 @@ # # IP: Netfilter Configuration # -CONFIG_IP_NF_CONNTRACK=m +CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y -CONFIG_IP_NF_CT_PROTO_SCTP=m -CONFIG_IP_NF_FTP=m -CONFIG_IP_NF_IRC=m -CONFIG_IP_NF_TFTP=m -CONFIG_IP_NF_AMANDA=m -CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_IPRANGE=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_OWNER=m -CONFIG_IP_NF_MATCH_ADDRTYPE=m -CONFIG_IP_NF_MATCH_HASHLIMIT=m -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -CONFIG_IP_NF_NAT=m +CONFIG_IP_NF_CT_PROTO_SCTP=y +CONFIG_IP_NF_FTP=y +CONFIG_IP_NF_IRC=y +CONFIG_IP_NF_TFTP=y +CONFIG_IP_NF_AMANDA=y +CONFIG_IP_NF_QUEUE=y +CONFIG_IP_NF_IPTABLES=y +CONFIG_IP_NF_MATCH_IPRANGE=y +CONFIG_IP_NF_MATCH_TOS=y +CONFIG_IP_NF_MATCH_RECENT=y +CONFIG_IP_NF_MATCH_ECN=y +CONFIG_IP_NF_MATCH_DSCP=y +CONFIG_IP_NF_MATCH_TTL=y +CONFIG_IP_NF_MATCH_OWNER=y +CONFIG_IP_NF_MATCH_ADDRTYPE=y +CONFIG_IP_NF_MATCH_HASHLIMIT=y +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +CONFIG_IP_NF_TARGET_LOG=y +CONFIG_IP_NF_TARGET_ULOG=y +CONFIG_IP_NF_TARGET_TCPMSS=y +CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -CONFIG_IP_NF_TARGET_NETMAP=m -CONFIG_IP_NF_TARGET_SAME=m -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_CLUSTERIP=m -CONFIG_IP_NF_RAW=m -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m +CONFIG_IP_NF_TARGET_MASQUERADE=y +CONFIG_IP_NF_TARGET_REDIRECT=y +CONFIG_IP_NF_TARGET_NETMAP=y +CONFIG_IP_NF_TARGET_SAME=y +CONFIG_IP_NF_NAT_SNMP_BASIC=y +CONFIG_IP_NF_NAT_IRC=y +CONFIG_IP_NF_NAT_FTP=y +CONFIG_IP_NF_NAT_TFTP=y +CONFIG_IP_NF_NAT_AMANDA=y +CONFIG_IP_NF_MANGLE=y +CONFIG_IP_NF_TARGET_TOS=y +CONFIG_IP_NF_TARGET_ECN=y +CONFIG_IP_NF_TARGET_DSCP=y +CONFIG_IP_NF_TARGET_CLUSTERIP=y +CONFIG_IP_NF_RAW=y +CONFIG_IP_NF_ARPTABLES=y +CONFIG_IP_NF_ARPFILTER=y +CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration (EXPERIMENTAL) # -CONFIG_IP6_NF_QUEUE=m -CONFIG_IP6_NF_IPTABLES=m -CONFIG_IP6_NF_MATCH_RT=m -CONFIG_IP6_NF_MATCH_OPTS=m -CONFIG_IP6_NF_MATCH_FRAG=m -CONFIG_IP6_NF_MATCH_HL=m -CONFIG_IP6_NF_MATCH_OWNER=m -CONFIG_IP6_NF_MATCH_IPV6HEADER=m -CONFIG_IP6_NF_MATCH_EUI64=m -CONFIG_IP6_NF_FILTER=m -CONFIG_IP6_NF_TARGET_LOG=m -CONFIG_IP6_NF_MANGLE=m -CONFIG_IP6_NF_RAW=m +CONFIG_IP6_NF_QUEUE=y +CONFIG_IP6_NF_IPTABLES=y +CONFIG_IP6_NF_MATCH_RT=y +CONFIG_IP6_NF_MATCH_OPTS=y +CONFIG_IP6_NF_MATCH_FRAG=y +CONFIG_IP6_NF_MATCH_HL=y +CONFIG_IP6_NF_MATCH_OWNER=y +CONFIG_IP6_NF_MATCH_IPV6HEADER=y +CONFIG_IP6_NF_MATCH_EUI64=y +CONFIG_IP6_NF_FILTER=y +CONFIG_IP6_NF_TARGET_LOG=y +CONFIG_IP6_NF_MANGLE=y +CONFIG_IP6_NF
Bug#423874: please increase limit on kernel command line length
Package: linux-2.6 Version: 2.6.20-3 Severity: wishlist Please increase the limit on the kernel's command line length. We're using debian-installer's preseed support for performing unattended installations and it's difficult to fit the necessary preseed information into 256 bytes (this is on i386). For example, here is the command line we're using to perform installations via serial console: append DEBIAN_FRONTEND=text initrd=e/i locale=en_US console-keymaps-at/keymap=us netcfg/no_default_route=true netcfg/dhcp_timeout=90 url=http://server:[EMAIL PROTECTED]/install/etch.cfg console=ttyS1,57600n81 -- The preseed URL has been obscured, but the full length is ~230 characters. We've moved everything we possibly can out of the kernel command line and into the preseed file, but some things must still be on the command line, such as network configuration (d-i must obviously set up the network before it can retrieve the preseed file over it :-) We've even taken to making single-character symlinks for the initrd to squeeze a few more bytes out. COMMAND_LINE_SIZE (in include/asm-*/setup.h) is set per arch, but I'm not sure what arch-related constraints there are to increasing its size. Some arches have length limits as high as 1024 or even 4096 bytes. 512 would be a great benefit, and 1024 is probably more than anyone would need for preseeding. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422869: please don't disable local (non-serial) consoles when installing via serial console
Package: finish-install Version: 2.10 Severity: wishlist #274649 modified finish-install to have the finished system start a getty on the serial port used for installation and update /etc/securetty so root can log into it (thank you!). At the same time, it disables the gettys on the local console (tty[1-6]). We often install via serial console with ipmitool(1), but also use the local console from time to time. It would be nice if finish-install simply kept these gettys around, or offered an option to do so (perhaps a debconf question that we could preseed?). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422864: segfaults in ipmi_lanplus_recv_sol
Package: ipmitool Version: 1.8.8-3 Severity: important Tags: patch ipmitool(1) segfaults on a regular basis in ipmi_lanplus_recv_sol(): Program received signal SIGSEGV, Segmentation fault. ipmi_lanplus_recv_sol (intf=0x80a2c80) at lanplus.c:2459 2459 if(rsp->session.authtype != 0) (gdb) bt #0 ipmi_lanplus_recv_sol (intf=0x80a2c80) at lanplus.c:2459 #1 0x0807aee5 in ipmi_lanplus_send_payload (intf=0x80a2c80, payload=0xbfff7cd4) at lanplus.c:2167 #2 0x0807c8bd in ipmi_lanplus_send_sol (intf=0x80a2c80, v2_payload=0xbfff7cd4) at lanplus.c:2298 #3 0x08059875 in ipmi_sol_activate (intf=0x80a2c80, looptest=0, interval=0) at ipmi_sol.c:1259 #4 0x08059fb6 in ipmi_sol_main (intf=0x80a2c80, argc=1, argv=0xbfff8394) at ipmi_sol.c:1716 #5 0x080728fb in ipmi_cmd_run (intf=0x80a2c80, name=0xbfff8d18 "sol", argc=1, argv=0xbfff8394) at ipmi_main.c:207 #6 0x080735ec in ipmi_main (argc=9, argv=0xbfff8374, cmdlist=0x8099b40, intflist=0x0) at ipmi_main.c:601 #7 0x0804aea1 in main (argc=134846668, argv=0x1) at ipmitool.c:115 ipmi_lan_poll_recv() can return NULL, and ipmi_lanplus_recv_sol() doesn't check for this case. ipmitool 1.8.9 fixes this; their source changed like so: - if(rsp->session.authtype != 0) + if (rsp && rsp->session.authtype != 0) We're using ipmitool with several Dell PowerEdge 1950s; without this change, ipmitool's serial console segfaults randomly, often after it's connected for only a few seconds. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages ipmitool depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libncurses5 5.5-5Shared libraries for terminal hand ii libreadline55.2-2GNU readline and history libraries ii libssl0.9.8 0.9.8c-4 SSL shared libraries ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip ipmitool recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422557: mutt: thread markers make index lines wrap incorrectly in UTF-8 locales
Package: mutt Version: 1.5.13-1.1 Severity: normal When displaying an index in threaded mode, the thread markers (for messages nested in a thread) make lines wrap correctly. After some movement of the highlight bar, the display becomes fairly unable without an explicit refresh (^L). I've reproduced this in several terminal emulators; (IIRC), iTerm on OS X, PuTTY on Windows, and gnome-terminal under Linux. The "corruption after highlight bar movement" is most profound when running mutt in a screen(1). This only happens when LANG=en_US.UTF-8 (en_US.UTF-8.png, attached). If I set LANG=en_US, the display is fine (en_US.png, attached). FWIW, this seems similar to #328921 and #415277. I tried the latest mutt from experimental, but the behavior is unchanged. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-alpha-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mutt depends on: ii libc6.1 2.3.6.ds1-13 GNU C Library: Shared libraries ii libdb4.4 4.4.20-8 Berkeley v4.4 Database Libraries [ ii libgnutls13 1.4.4-3the GNU TLS library - runtime libr ii libidn11 0.6.5-1GNU libidn library, implementation ii libncursesw5 5.5-5 Shared libraries for terminal hand ii libsasl2-22.1.22.dfsg1-8 Authentication abstraction library ii postfix [mail-transport-a 2.3.8-2A high-performance mail transport Versions of packages mutt recommends: ii locales 2.3.6.ds1-13 GNU C Library: National Language ( ii mime-support3.39-1 MIME files 'mime.types' & 'mailcap -- no debconf information <><>
Bug#419720: apache2.2-common: unaligned trap in mod_ssl on alpha
Package: apache2.2-common Version: 2.2.3-4 Severity: minor mod_ssl is causing unaligned traps on alpha (backtrace is below). Here's the offending section of code: 1153 shmcb_safe_clear(idx, sizeof(SHMCBIndex)); 1154 shmcb_set_safe_time(&(idx->expires), expiry_time); 1155 shmcb_set_safe_uint(&(idx->offset), new_offset); 1156 1157 /* idx->removed = (unsigned char)0; */ /* Not needed given the memset above. */ 1158 idx->s_id2 = session_id[1]; 1159 ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, 1160 "session_id[0]=%u, idx->s_id2=%u", 1161 session_id[0], session_id[1]); I'm pretty new to the alpha, but I'm guessing the access to session_id[1] is causing the trap, since session_id is an unsigned char * and idx->s_id2 seems to be aligned on a 4- or 8-byte boundary. I'm not sure of the best way to fix this. If there is anything I can do (patch testing, etc.), please let me know! Also, there seem to be a couple other less-frequent unaligned traps in apache2 that I'm also trying to track down. Should I append them to this bug, or is a separate one for each trap better? Thanks! #0 0x0200017ffe54 in shmcb_insert_encoded_session (s=0x12023e428, queue=0x11fef8b00, cache=0x11fef8b20, encoded=0x11fef8b40 "0\201\221\002\001\001\002\002\003\001\004\002", encoded_len=148, session_id=0x1205e6b28 "\217\236�\234\210��߭u�\020!w�6�taaй\024rU|G� ", expiry_time=1176822685) at /home/jwm/apache2-2.2.3/modules/ssl/ssl_scache_shmcb.c:1158 #1 0x0200017fe8a0 in shmcb_store_session (s=0x12023e428, shm_segment=0x20003c94008, id=0x1205e6b28 "\217\236�\234\210��߭u�\020!w�6�taaй\024rU|G� ", idlen=32, pSession=0x1205e6ae0, timeout=1176822685) at /home/jwm/apache2-2.2.3/modules/ssl/ssl_scache_shmcb.c:697 #2 0x0200017fd68c in ssl_scache_shmcb_store (s=0x12023e428, id=0x1205e6b28 "\217\236�\234\210��߭u�\020!w�6�taaй\024rU|G� ", idlen=32, timeout=1176822685, pSession=0x1205e6ae0) at /home/jwm/apache2-2.2.3/modules/ssl/ssl_scache_shmcb.c:411 #3 0x0200017fb4e4 in ssl_scache_store (s=0x12023e428, id=0x1205e6b28 "\217\236�\234\210��߭u�\020!w�6�taaй\024rU|G� ", idlen=32, expiry=1176822685, sess=0x1205e6ae0) at /home/jwm/apache2-2.2.3/modules/ssl/ssl_scache.c:99 #4 0x0200017f0294 in ssl_callback_NewSessionCacheEntry (ssl=0x1205cbbe0, session=0x1205e6ae0) at /home/jwm/apache2-2.2.3/modules/ssl/ssl_engine_kernel.c:1638 #5 0x0280af98 in ssl_update_cache () from /usr/lib/libssl.so.0.9.8 #6 0x027f0e20 in ssl3_accept () from /usr/lib/libssl.so.0.9.8 #7 0x0280a890 in SSL_accept () from /usr/lib/libssl.so.0.9.8 #8 0x027fbb18 in ssl23_get_client_hello () from /usr/lib/libssl.so.0.9.8 #9 0x027fc750 in ssl23_accept () from /usr/lib/libssl.so.0.9.8 #10 0x0280a890 in SSL_accept () from /usr/lib/libssl.so.0.9.8 #11 0x0200017ea408 in ssl_io_filter_connect (filter_ctx=0x120506490) at /home/jwm/apache2-2.2.3/modules/ssl/ssl_engine_io.c:1047 #12 0x0200017eaeac in ssl_io_filter_input (f=0x1205d1308, bb=0x1205c71c0, mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0) at /home/jwm/apache2-2.2.3/modules/ssl/ssl_engine_io.c:1292 #13 0x00012005bb98 in ap_get_brigade (next=0x1205d1308, bb=0x1205c71c0, mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0) at /home/jwm/apache2-2.2.3/server/util_filter.c:489 #14 0x00012002f458 in ap_rgetline_core (s=0x1205c5c78, n=8192, read=0x11fefb868, r=0x1205c5c48, fold=0, bb=0x1205c71c0) at /home/jwm/apache2-2.2.3/server/protocol.c:231 #15 0x00012002ff0c in read_request_line (r=0x1205c5c48, bb=0x1205c71c0) at /home/jwm/apache2-2.2.3/server/protocol.c:596 #16 0x000120030e04 in ap_read_request (conn=0x120505b88) at /home/jwm/apache2-2.2.3/server/protocol.c:891 #17 0x000120061468 in ap_process_http_connection (c=0x120505b88) at /home/jwm/apache2-2.2.3/modules/http/http_core.c:177 #18 0x000120055918 in ap_run_process_connection (c=0x120505b88) at /home/jwm/apache2-2.2.3/server/connection.c:43 #19 0x000120055fa8 in ap_process_connection (c=0x120505b88, csd=0x120505998) at /home/jwm/apache2-2.2.3/server/connection.c:178 #20 0x00012006d894 in child_main (child_num_arg=0) at /home/jwm/apache2-2.2.3/server/mpm/prefork/prefork.c:640 #21 0x00012006db58 in make_child (s=0x1200a6970, slot=0) at /home/jwm/apache2-2.2.3/server/mpm/prefork/prefork.c:736 #22 0x00012006dc00 in startup_children (number_to_start=5) at /home/jwm/apache2-2.2.3/server/mpm/prefork/prefork.c:754 #23 0x00012006e2dc in ap_mpm_run (_pconf=0x1200a0208, plog=0x1200d43a8, s=0x1200a6970) at /home/jwm/apache2-2.2.3/server/mpm/prefork/prefork.c:975 #24 0x000120022e28 in main (argc=3, argv=0x11fefbcb8) at /home/jwm/apache2-2.2.3/server/main.c:717 -- System Information: Debian Release: 4.0
Bug#419249: linux-image-2.6.18-4-alpha-smp: epoll always returns ENOSYS
Package: linux-image-2.6.18-4-alpha-smp Version: 2.6.18.dfsg.1-11 Severity: normal I recently installed squid, and noticed that it was complaining: comm_select_init: epoll_create(): (78) Function not implemented It seems epoll_*() always return ENOSYS on alpha; more details can be found in this Gentoo bug and l-k thread: http://bugs.gentoo.org/show_bug.cgi?id=160637 http://marc.info/?l=linux-kernel&w=2&r=1&s=alpha+epoll+&q=b -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-alpha-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-4-alpha-smp depends on: ii coreutils 5.97-5.3 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85g tools for generating an initramfs ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo linux-image-2.6.18-4-alpha-smp recommends no packages. -- debconf information: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-4-alpha-smp/postinst/depmod-error-2.6.18-4-alpha-smp: false linux-image-2.6.18-4-alpha-smp/preinst/failed-to-move-modules-2.6.18-4-alpha-smp: linux-image-2.6.18-4-alpha-smp/preinst/initrd-2.6.18-4-alpha-smp: linux-image-2.6.18-4-alpha-smp/preinst/abort-install-2.6.18-4-alpha-smp: linux-image-2.6.18-4-alpha-smp/postinst/old-dir-initrd-link-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/postinst/depmod-error-initrd-2.6.18-4-alpha-smp: false * linux-image-2.6.18-4-alpha-smp/preinst/already-running-this-2.6.18-4-alpha-smp: linux-image-2.6.18-4-alpha-smp/prerm/would-invalidate-boot-loader-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/postinst/create-kimage-link-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/preinst/bootloader-initrd-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/postinst/old-initrd-link-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/prerm/removing-running-kernel-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/postinst/kimage-is-a-directory: linux-image-2.6.18-4-alpha-smp/preinst/overwriting-modules-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/postinst/old-system-map-link-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/preinst/abort-overwrite-2.6.18-4-alpha-smp: linux-image-2.6.18-4-alpha-smp/preinst/elilo-initrd-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/postinst/bootloader-test-error-2.6.18-4-alpha-smp: linux-image-2.6.18-4-alpha-smp/preinst/lilo-has-ramdisk: linux-image-2.6.18-4-alpha-smp/preinst/lilo-initrd-2.6.18-4-alpha-smp: true linux-image-2.6.18-4-alpha-smp/postinst/bootloader-error-2.6.18-4-alpha-smp: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325600: closed by Aurelien Jarno <[EMAIL PROTECTED]> (Closing bugs fixed in unreleased version 2.4-1 of the glibc)
On Fri, Apr 13, 2007 at 11:45:13AM +0200, Aurelien Jarno wrote: > Could you please try this patch instead: > http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/alpha/sysdep.h.diff?r1=1.26&r2=1.26.2.1&cvsroot=glibc > > It looks a lot better, and it's always easier to convince the release > managers to accept a patch if it has been accepted upstream first. Call me crazy, but it seems that this change is already in the upstream glibc tarball (glibc-2.3.6.ds1.tar.bz2) included with the 2.3.6.ds1-13 packaging for etch? john -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417928: bugzilla: update README.Debian for apache2
Package: bugzilla Version: 2.22.1-2 Severity: minor Tags: patch README.Debian says: You will need to enable the Apache mod_env module first: # apache-modconf apache enable mod_env but for apache2, you must: # a2enmod env -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-alpha-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages bugzilla depends on: ii apache22.2.3-4 Next generation, scalable, extenda ii apache2-mpm-prefork [httpd 2.2.3-4 Traditional model for Apache HTTPD ii dbconfig-common1.8.29+etch1 common framework for packaging dat ii debconf [debconf-2.0] 1.5.11Debian configuration management sy ii libappconfig-perl 1.56-2Perl module for configuration file ii libdbd-mysql-perl 3.0008-1 A Perl5 database interface to the ii libmailtools-perl 1.74-1Manipulate email in perl programs ii libmime-perl 5.420-0.1 Perl5 modules for MIME-compliant m ii libtemplate-perl 2.14-1template processing system written ii libtimedate-perl 1.1600-5 Time and date functions for Perl ii mysql-client-5.0 [mysql-cl 5.0.32-7etch1 mysql database client binaries ii patch 2.5.9-4 Apply a diff file to an original ii postfix [mail-transport-ag 2.3.8-2 A high-performance mail transport ii ucf2.0020Update Configuration File: preserv Versions of packages bugzilla recommends: ii libchart-perl 2.4.1-4 Chart Library for Perl ii libxml-parser-perl 2.34-4.2 Perl module for parsing XML files ii mysql-server-5.0 [m 5.0.32-7etch1mysql database server binaries ii perlmagick 7:6.2.4.5.dfsg1-0.14 A perl interface to the libMagick -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417386: [EMAIL PROTECTED]: Re: Transaction support in SQLite-PHP]
- Forwarded message from Bruno Fleisch <[EMAIL PROTECTED]> - Date: Thu, 05 Apr 2007 10:00:41 +0200 From: Bruno Fleisch <[EMAIL PROTECTED]> To: John Morrissey <[EMAIL PROTECTED]> Subject: Re: Transaction support in SQLite-PHP Selon John Morrissey <[EMAIL PROTECTED]>: > On Wed, Apr 04, 2007 at 09:33:36AM +0200, Bruno Fleisch wrote: > > My deepest apologies - I thought this patch was already committed. I can > > manage to find it on my backups - could you forward it to me ? I have an > > other patch to merge (better support for BLOB columns), and will prepare a > > new release. > > It's attached. Thanks! > > john > -- Hi John, Thanks! The new release is available at this location: http://sourceforge.net/project/showfiles.php?group_id=150569 Best regards, Bruno - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417386: autocommit is always on, breaking transactions
Package: php4-sqlite3
Version: 0.4-1frontier1
Severity: important
Tags: patch
I contacted the maintainer for this package about a year ago about
transaction support in php4-sqlite3; below are a couple of the messages we
exchanged.
It would be nice if this patch could be included in the Debian packaging.
Unfortunately, it looks like it hasn't been committed upstream yet, but I've
pinged Bruno to see what's up. I'll post any followup I receive.
thanks,
john
Date: Wed, 31 May 2006 16:41:29 -0400
From: John Morrissey <[EMAIL PROTECTED]>
To: Bruno Fleisch <[EMAIL PROTECTED]>
Subject: Transaction support in SQLite-PHP
Hi Bruno--
I tried e-mailing Chris Burton, who's listed as the maintainer for the
SourceForge project, but my message bounced[1]. I found your contact
information in the Debian packaging for SQLite-PHP - I hope you're an
appropriate person to contact. If not, could you please let me know who I
should be in touch with?
I'm having a problem with transaction support with SQLite-PHP 0.4 and SQLite
3.3.5 (the Debian versions of both, FWIW). Based on the symptoms, it acts
like autocommit mode is never being disabled. I can create a simple table,
start a transaction, insert a row, then ROLLBACK, but the row I inserted
remains. Here's a simple test case I got it down to:
getMessage() . "\n");
}
foreach (array(
"BEGIN TRANSACTION;",
"INSERT INTO user (uid) VALUES('jwm2');",
"ROLLBACK;") as $query) {
print "$query\n";
$result = $db->query($query);
if (PEAR::isError($result)) {
die($query->getMessage() . "\n");
}
}
The system() part to create the table isn't significant; the same symptoms
appear if I create the table via SQLite-PHP. If I execute the same
statements with the command line SQLite client, the behavior is as I would
expect - after the ROLLBACK, the table is empty.
Am I doing something wrong, or making a false assumption? I haven't had a
chance to delve into the SQLite-PHP source yet, but I would appreciate it if
you could have a look at this.
thanks!
john
[1] <[EMAIL PROTECTED]>: host
mail.sourceforge.net[66.35.250.206] said: 550-This
@users.sourceforge.net account doesn't exist or isn't currently
550-functioning (mail to them is bouncing). You can check that you have
the 550-right address by checking http://sourceforge.net/users/cburton/.
It's also 550-possible that this alias just isn't active yet. It may
take a few minutes 550 for new accounts to become active. (in reply to
RCPT TO command)
--
John Morrissey _o/\ __o
[EMAIL PROTECTED]_-< \_ / \ < \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
Date: Fri, 02 Jun 2006 10:09:36 +0200
From: Bruno Fleisch <[EMAIL PROTECTED]>
To: John Morrissey <[EMAIL PROTECTED]>
Subject: Re: Transaction support in SQLite-PHP
Selon John Morrissey <[EMAIL PROTECTED]>:
> On Thu, Jun 01, 2006 at 05:56:24PM +0200, Bruno Fleisch wrote:
> > Attached is a patch made against DB/sqlite3.php that should solve this
> > issue.
> >
> > I've discovered that the BEGIN & END/ROLLBACK statments are executed by
> > sqlite3_query(), like all regualar SELECT queries. Such queries are NOT
> > performed until a fetchInto-like function is called.
> >
> > I've changed a bit that function. sqlite3_query() gets called by SELECT
> > queries, all others are handled by sqlite3_exec().
> >
> > Let me know if it works for you,
>
> Nifty - thanks for the quick response. There was no patch attached, though.
>
Let's try again...
Below is the patch's content.
Regards,
Bruno
--- sqlite3.php.org 2006-06-01 17:42:41.0 +0200
+++ sqlite3.php 2006-06-01 17:42:12.0 +0200
@@ -19,7 +19,7 @@
* @author Bruno Fleisch
* @copyright 1997-2005 The PHP Group
* @licensehttp://www.php.net/license/3_0.txt PHP License 3.0 3.0
- * @versionCVS: $Id: sqlite3.php,v 1.2 2006/03/28 15:33:30 bfleisch Exp $
+ * @versionCVS: $Id: sqlite3.php,v 1.1.1.1 2005/10/13 20:24:55 bfleisch Exp
$
* @link http://pear.php.net/package/DB
*/
@@ -124,10 +124,10 @@
function simpleQuery($query)
{
-
-$isManip = DB::isManip($query);
-
-if ($isManip)
+
+$isSelect = preg_match ("/^\s*SELECT/i", $query);
+
+if (! $isSelect)
$this->result = sqlite3_exec($this->connection, $query);
else
$this->result = sqlite3_query($this->connection, $query);
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.12-10-xeon
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages php4-sqlite3 depends on:
Bug#416834: cricket: grapher.cgi doesn't display current values on alpha
Package: cricket
Version: 1.0.5-6
Severity: important
Tags: patch
On the alpha architecture, instead of displaying the current values for a
target, grapher.cgi displays the error:
Current values not available: Architecture alpha-linux-gnu-thread-multi not
supported yet.
This is similar to this Cricket bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=477899&group_id=1210&atid=101210
and this patch seems to fix it:
--- /home/jwm/Format.pm 2007-03-30 11:35:49.0 -0400
+++ /usr/share/cricket/lib/RRD/Format.pm2007-03-30 11:36:24.0
-0400
@@ -150,7 +150,7 @@
$self->{'liveHead'} = "L";
$self->{'rraPtr'} = "L";
$self->{'element'} = "d";
+} elsif ( $archname eq 'alpha-linux' or $archname eq 'alpha-linux-gnu') {
-} elsif ( $archname eq 'alpha-linux' ) {
$self->{'statHead'} = "a4 a5 x7 d Q Q Q x80";
$self->{'dsDef'} = "a20 a20 Q d d x56";
$self->{'rraDef'} = "a20 x4 Q Q d x72";
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: alpha
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-alpha-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages cricket depends on:
ii adduser 3.102 Add and remove users and groups
ii cron 3.0pl1-100 management of regular background p
ii librrds-perl 1.2.15-0.3 Time-series data storage and displ
ii libsnmp-session-perl 1.08-1 Perl support for accessing SNMP-aw
ii libtimedate-perl 1.1600-5 Time and date functions for Perl
ii perl [libdigest-md5-perl] 5.8.8-7Larry Wall's Practical Extraction
ii perl-suid 5.8.8-7Runs setuid Perl scripts
Versions of packages cricket recommends:
ii apache2 2.2.3-3.3 Next generation, scalable, extenda
ii apache2-mpm-prefork [httpd] 2.2.3-3.3 Traditional model for Apache HTTPD
ii logrotate 3.7.1-3Log rotation utility
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401758: Raising severity to release-critical
severity 401758 critical thanks It'd be awfully nice to get this fix into etch. Given its imminent release and (more importantly) the fact that this bug "makes unrelated software on the system (or the whole system) break,"[1] critical seems to be justified. We've been running a libnss-ldap with this patch on several systems under high load and have experienced no problems. john [1] Once nscd(8) leaks enough file descriptors, any further name service activity blocks, preventing most any other activity on the machine. If you're lucky, you can log in on the console and restart nscd or reboot the machine. If not, it's time for a hard power cycle. -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#415711: typo in h2ph man page's default destination path ($Config{'installsitsearch'})
Package: perl
Version: 5.8.8-7
Severity: minor
Tags: patch
There's a typo in the default destination directory mentioned by the man
page h2ph(1):
..IP "\-d destination_dir" 4
..IX Item "-d destination_dir"
Put the resulting \fB.ph\fR files beneath \fBdestination_dir\fR, instead of
beneath the default Perl library location (\f(CW$Config{'installsitsearch'}\fR).
Instead of installsitsearch, this should be installsitearch:
$ perl -MConfig -e 'print $Config{installsitearch} . "\n"'
/usr/local/lib/perl/5.8.4
$ perl -MConfig -e 'print $Config{installsitsearch} . "\n"'
$
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages perl depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libdb4.44.4.20-8 Berkeley v4.4 Database Libraries [
ii libgdbm31.8.3-3 GNU dbm database routines (runtime
ii perl-base 5.8.8-7 The Pathologically Eclectic Rubbis
ii perl-modules5.8.8-7 Core Perl modules
Versions of packages perl recommends:
pn perl-doc (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414491: cron complains: /etc/cron.daily/sysstat exited with return code 1
Package: sysstat Version: 7.0.4-1 Severity: normal Tags: patch The daily sysstat job causes cron to complain: > Subject: Cron <[EMAIL PROTECTED]> test -x /usr/sbin/anacron || ( cd / && > run-parts --report /etc/cron.daily ) > > run-parts: /etc/cron.daily/sysstat exited with return code 1 /usr/lib/sysstat/sa2 seems to be the culprit; its last operation is: rmdir [0-9]? > /dev/null 2>&1 No files matching /var/log/sysstat/[0-9]? exist on this machine, so rmdir(1) returns failure. A simple 'exit 0' at the end of /usr/lib/sysstat/sa2 should silence this. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages sysstat depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip ii ucf 2.0020 Update Configuration File: preserv Versions of packages sysstat recommends: ii cron 3.0pl1-100 management of regular background p -- debconf information: sysstat/notice: * sysstat/enable: true sysstat/remove_files: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401758: [patch] stop fd leak in libnss-ldap
tags 401758 + patch thanks We've since installed a patched version of libnss-ldap on several machines, all of which have stopped leaking file descriptors. Thanks for the patch, Dean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
