Bug#817232: Stil present in 1.158
# dpkg -s keyboard-configuration Package: keyboard-configuration Status: install ok installed Priority: optional Section: utils Installed-Size: 2502 Maintainer: Debian Install System TeamArchitecture: all Multi-Arch: foreign Source: console-setup Version: 1.137 Replaces: console-setup (<< 1.47), console-setup-mini (<< 1.47) Depends: liblocale-gettext-perl, initscripts Pre-Depends: debconf (>= 1.5.34) Breaks: console-setup (<< 1.71), console-setup-mini (<< 1.47) Conffiles: /etc/init.d/console-setup 0db5a9bc1f799d7ce34a971a8aa43264 /etc/init.d/keyboard-setup 6ecdd8d7eae634bc48cbc82a73c12c25 Description: system-wide keyboard preferences This package maintains the keyboard preferences in /etc/default/keyboard. Other packages can use the information provided by this package in order to configure the keyboard on the console or in X Window. # dpkg -L keyboard-configuration /. /etc /etc/init.d /etc/init.d/keyboard-setup /etc/init.d/console-setup /usr /usr/share /usr/share/man /usr/share/man/man5 /usr/share/man/man5/keyboard.5.gz /usr/share/doc /usr/share/doc/keyboard-configuration /usr/share/doc/keyboard-configuration/copyright /usr/share/doc/keyboard-configuration/copyright.fonts.gz /usr/share/doc/keyboard-configuration/changelog.gz /usr/share/doc/keyboard-configuration/FAQ.gz /usr/share/doc/keyboard-configuration/README.Debian /usr/share/doc/keyboard-configuration/copyright.xkb.gz /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/keyboard-configuration /usr/share/bug /usr/share/bug/keyboard-configuration /usr/share/bug/keyboard-configuration/control /usr/share/console-setup /usr/share/console-setup/keyboard /usr/share/console-setup/kbdnames-maker /usr/share/console-setup/KeyboardNames.pl /usr/share/doc/keyboard-configuration/xorg.lst # dpkg -i keyboard-configuration_1.158_all.deb (Reading database ... 297104 files and directories currently installed.) Preparing to unpack keyboard-configuration_1.158_all.deb ... update-rc.d: warning /etc/init.d/keyboard-setup still exist. Terminating dpkg: error processing archive keyboard-configuration_1.158_all.deb (--install): subprocess new pre-installation script returned error exit status 1 Errors were encountered while processing: keyboard-configuration_1.158_all.deb I could force this by manually removing the file, but an earlier version of keyboard-configuration created the file, and the later version should cope with it. The bug is that update-rc.d expects the script to have been deleted, and will fail if not. But the preinst script only removes the files *after* running update-rc.d: #!/bin/sh set -e if [ -x "/etc/init.d/keyboard-setup" ]; then update-rc.d keyboard-setup remove >/dev/null fi if [ -x "/etc/init.d/console-setup" ]; then update-rc.d console-setup remove >/dev/null fi dpkg-maintscript-helper rm_conffile /etc/init.d/keyboard-setup 1.138~ -- "$@" dpkg-maintscript-helper rm_conffile /etc/init.d/console-setup 1.138~ -- "$@" Either add -f to the update-rc.d invocation, or try something more like: #!/bin/sh set -e for file in keyboard-setup console-setup; do if [ -x /etc/init.d/$file ]; then dpkg-maintscript-helper rm_conffile /etc/init.d/$file 1.138~ -- "$@" update-rc.d $file remove >/dev/null fi done
Bug#802638: "rlimit memlock -1" fixes it
I was having the same problem, and indeed this fixes it.
Bug#793745: [PATCH] I'm seeing it too.
Since I run a pool server, I have a customized config. That means that I have the pool servers commented out, and the comment on the rlimit command says it's not needed in that case, so I left it out of my config. And ran into the same problem. Really, ntpd should make calls like getpwuid() before calling mlock, This requires breaking -u option processing has to be broken into two phases (since you can't mlock after changing uid), but it's not that hard. Appended is a (working for me) patch to do just that. The mlockall() fails because it exceeds the available limit, but ntpd just logs the error and continues. In the original, earlier location it succeeds, but then later allocations fail due to the same limit. diff -ru ntp-4.2.8p3+dfsg.orig/ntpd/ntpd.c ntp-4.2.8p3+dfsg/ntpd/ntpd.c --- ntp-4.2.8p3+dfsg.orig/ntpd/ntpd.c 2015-08-01 22:46:20.0 -0400 +++ ntp-4.2.8p3+dfsg/ntpd/ntpd.c2015-08-02 14:53:20.879051191 -0400 @@ -792,37 +792,6 @@ */ getconfig(argc, argv); - if (do_memlock) { -# if defined(HAVE_MLOCKALL) - /* -* lock the process into memory -*/ - if (!HAVE_OPT(SAVECONFIGQUIT) - 0 != mlockall(MCL_CURRENT|MCL_FUTURE)) - msyslog(LOG_ERR, mlockall(): %m); -# else /* !HAVE_MLOCKALL follows */ -# ifdef HAVE_PLOCK -# ifdef PROCLOCK - /* -* lock the process into memory -*/ - if (!HAVE_OPT(SAVECONFIGQUIT) 0 != plock(PROCLOCK)) - msyslog(LOG_ERR, plock(PROCLOCK): %m); -# else /* !PROCLOCK follows */ -#ifdef TXTLOCK - /* -* Lock text into ram -*/ - if (!HAVE_OPT(SAVECONFIGQUIT) 0 != plock(TXTLOCK)) - msyslog(LOG_ERR, plock(TXTLOCK) error: %m); -#else /* !TXTLOCK follows */ - msyslog(LOG_ERR, plock() - don't know what to lock!); -#endif /* !TXTLOCK */ -# endif /* !PROCLOCK */ -# endif /* HAVE_PLOCK */ -# endif/* !HAVE_MLOCKALL */ - } - loop_config(LOOP_DRIFTINIT, 0); report_event(EVNT_SYSRESTART, NULL, NULL); initializing = FALSE; @@ -931,6 +900,49 @@ exit (-1); } } + } +# endif /* HAVE_DROPROOT */ + + /* +* DROPROOT is divided into two phases. Gathering information +* is done before locking us into memory, since /etc/nsswitch.conf +* can mess with our address space. Actually dropping privileges +* is done after. (We can chroot() before, since the mlock() +* system call doesn't depend on that.) +*/ + if (do_memlock) { +# if defined(HAVE_MLOCKALL) + /* +* lock the process into memory +*/ + if (!HAVE_OPT(SAVECONFIGQUIT) + 0 != mlockall(MCL_CURRENT|MCL_FUTURE)) + msyslog(LOG_ERR, mlockall(): %m); +# else /* !HAVE_MLOCKALL follows */ +# ifdef HAVE_PLOCK +# ifdef PROCLOCK + /* +* lock the process into memory +*/ + if (!HAVE_OPT(SAVECONFIGQUIT) 0 != plock(PROCLOCK)) + msyslog(LOG_ERR, plock(PROCLOCK): %m); +# else /* !PROCLOCK follows */ +#ifdef TXTLOCK + /* +* Lock text into ram +*/ + if (!HAVE_OPT(SAVECONFIGQUIT) 0 != plock(TXTLOCK)) + msyslog(LOG_ERR, plock(TXTLOCK) error: %m); +#else /* !TXTLOCK follows */ + msyslog(LOG_ERR, plock() - don't know what to lock!); +#endif /* !TXTLOCK */ +# endif /* !PROCLOCK */ +# endif /* HAVE_PLOCK */ +# endif/* !HAVE_MLOCKALL */ + } + +# ifdef HAVE_DROPROOT + if (droproot) { # ifdef HAVE_SOLARIS_PRIVS if ((lowprivs = priv_str_to_set(LOWPRIVS, ,, NULL)) == NULL) { msyslog(LOG_ERR, priv_str_to_set() failed:%m); Only in ntp-4.2.8p3+dfsg/ntpd: ntpd.c.orig -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793745: [pkg-ntp-maintainers] Bug#793745: [PATCH] I'm seeing it too.
Maybe the comment is a little misleading. How about # Preventing ntpd from swapping (with mlockall()) reduces time delays, # but resource limits (ulimit -l) cause out-of-meory errors that lead to # ntpd quitting with strange (or no) error messages. Particular trouble # spots are the -u option (depending on /etc/nsswitch.conf) and the pool # command (which does DNS lookups at run time). It's more reliable with # this disabled. # # Note that the busier your NTP server, the less swapping is a concern # in the first place. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Workaround patch
Thank you very much, your positive feedback is appreciated as well. When you do this in your spare time a nice word now and then makes a huge difference. Although I tried not to be a complete asshole about it, I was pretty pissed off at the beginning, and in particular I saw some friction developing around my patch and your or use 204-4 response. So I want to do what I can to make the light at the end of the tunnel a bit brighter! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Workaround patch
I've been installing 204-4 on various machines, and I wanted to thank you for both the nice clear informative warning *and* the override provision so that I can do the upgrade before rebooting into the new kernel. Much appreciated! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: I also had a non-booting machine...
Just to send a me, too!, I also recently bumped udev to the systemd version and also had a non-booting machine. Now, most of my machines had a sufficiently well-populated static /dev that I could boot and actually didn't notice the lack of udevd. On the non-booting machine, it was getting somewhere into the init scripts, but I noticed some command line syntax error complaints from mount when I hit scroll lock at the appropriate time. Fortunately, I managed to boot with init=/bin/bash and MAKEDEV or mknod the necessary device nodes. So now it's running without udev either. I spent a long time digging through /etc/init.d/mountkernfs trying to find the problem before I came across this bug. The question before me is whether to proceed to fix udev or just remove the PoS from my ststem. I've been running Debian on this machine with hand-compiled kernels since the late 1990s, updating unstable at least weekly, and this is the first time an update has failed to boot to at least a single-user shell. I've had sshd break, which was pretty bad, but this is the worst. The initial introduction of udev didn't cause this kind of mess. When an essential early-boot utility is adding a kernel config dependency, I expect *prominent* notice in changelog and the NEWS file. But I notice, despite the reference to it in the 204-1 changelog.Debian entry, no such file is packaged with udev. And finding it in the systemd source tree, there's no mention of the new requirement there. Hunting through the systemd git tree logs, I find that the requriement was added in commit 220893b3cbdbf8932f95c44811b169a8f0d33939 (udev version 176), and the old udev NEWS file which documented it was deleted in commit 3e2147858f21943d5f4a781c60f33ac22c6096ed. Gosh, maybe that could be hidden more thoroughly? Because Debian jumped from 175-7.2 to 204, there was literally no opportunity to see it. (This is primarily upstream's fault. While it would have been highly deisrable for the Debian maintainer to notice and reinstate things, this cavalier destruction of important history is reprehensible. Cc: to Kay Sievers to vent my ire in the correct direction.) The init.d/udev problem causing the mount syntax errors appears to be someone using `-o $dev_mount_options` rather than `-o $dev_mount_options`, which works fine with a null options string. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Workaround patch
Control: tags 722604 + patch udev 204-3 will work, with a hand-rolled kernel and no initramfs, if you do the following: 1. Enable CONFIG_DEVTMPFS=y. DEVTMPFS_MOUNT is not required. 2. Apply the following patch to /etc/init.d/udev. There are five parts to this patch: 1. Add the quotes to `mount -n -o $dev_mount_options` so that an empty $dev_mount_options string will not produce a syntax error. 2. Change from mounting tmpfs on /dev to devtmpfs 3. Check for the existence of devtmpfs in /proc/filesystems 4. Update error messages to reflect devtmpfs 5. Update comments and rename the mount_tmpfs shell function to mount_devtmpfs to reflect the preceding change. This part is purely cosmetic. --- /etc/init.d/udev.dpkg-dist 2013-09-17 18:42:58.0 -0400 +++ /etc/init.d/udev2013-09-17 18:58:50.0 -0400 @@ -8,7 +8,7 @@ # Short-Description: Start udevd, populate /dev and load drivers. ### END INIT INFO -# we need to unmount /dev/pts/ and remount it later over the tmpfs +# we need to unmount /dev/pts/ and remount it later over the devtmpfs unmount_devpts() { if mountpoint -q /dev/pts/; then umount -n -l /dev/pts/ @@ -19,15 +19,15 @@ fi } -# mount a tmpfs over /dev, if somebody did not already do it -mount_tmpfs() { +# mount a devtmpfs over /dev, if somebody did not already do it +mount_devtmpfs() { if grep -E -q ^[^[:space:]]+ /dev (dev)?tmpfs /proc/mounts; then -mount -n -o remount,${dev_mount_options} -t tmpfs tmpfs /dev +mount -n -o remount,${dev_mount_options} -t devtmpfs devtmpfs /dev return fi - if ! mount -n -o $dev_mount_options -t devtmpfs devtmpfs /dev; then -log_failure_msg udev requires tmpfs support, not started + if ! mount -n -o $dev_mount_options -t devtmpfs devtmpfs /dev; then +log_failure_msg udev requires devtmpfs support, not started log_end_msg 1 fi @@ -113,8 +113,8 @@ log_end_msg 1 fi -if ! grep -q '[[:space:]]tmpfs$' /proc/filesystems; then - log_failure_msg udev requires tmpfs support, not started +if ! grep -q '[[:space:]]devtmpfs$' /proc/filesystems; then + log_failure_msg udev requires devtmpfs support, not started log_end_msg 1 fi @@ -165,7 +165,7 @@ if [ -z $TMPFS_MOUNTED ]; then unmount_devpts - mount_tmpfs + mount_devtmpfs [ -d /proc/1 ] || mount -n /proc fi More changes would be desirable, such as actually using the $tmpfs_size variable, using $udev_root consistently, etc. I'd also really appreciate more details in the error message about running /etc/init.d/udev from a tty explaining exactly what will happen instead of what I expect. I also wonder if the test on that warn_if_interactive is correct. It skips the test if /dev/.udev exists or if /run/udev exists. Isn't that exactly the case that udev is already running, when you *do* want the test? And skip it if udev *isn't* running? -if [ ! -e $udev_root/.udev/ -a ! -e /run/udev/ ]; then +if [ -d $udev_root/.udev/ -o -d /run/udev/ ]; then -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Workaround patch
Or you just update to 204-4 which has been uploaded a few hours ago. Well, yes, thank you, but it wasn't even in the BTS when I started work on the bug, and it still isn't on ftp.debian.org as of a few seconds before I send this message. ftp ls udev_* 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rw-r--r--1 1176 1176 760246 Sep 11 22:45 udev_204-3_amd64.deb -rw-r--r--1 1176 1176 744706 Sep 12 03:11 udev_204-3_armel.deb -rw-r--r--1 1176 1176 744204 Sep 12 00:56 udev_204-3_armhf.deb -rw-r--r--1 1176 1176 762282 Sep 11 23:10 udev_204-3_i386.deb -rw-r--r--1 1176 1176 931828 Sep 11 23:40 udev_204-3_ia64.deb -rw-r--r--1 1176 1176 753796 Sep 12 04:26 udev_204-3_mips.deb -rw-r--r--1 1176 1176 1093170 Sep 12 02:26 udev_204-3_mipsel.deb -rw-r--r--1 1176 1176 757232 Sep 11 23:25 udev_204-3_powerpc.deb -rw-r--r--1 1176 1176 756502 Sep 11 23:10 udev_204-3_s390.deb -rw-r--r--1 1176 1176 755510 Sep 11 23:15 udev_204-3_s390x.deb -rw-r--r--1 1176 1176 738086 Sep 11 23:45 udev_204-3_sparc.deb 226 Directory send OK. I'll compare 204-4 when I can find a copy. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709502: Debhelper 9.20130518 breaks file-rc
Package: debhelper Version: 9.20130518 Severity: serious (I already sent this with a different title, but submit@ appended it to the closed bug 708720, which isn't helpful, as this is a different bug; the connection is just that the fix for that introduced this.) Since this version, packages are appearing which Depend (via ${misc:Depends}) on sysv-rc (= 2.88dsf-24). This makes them difficult to install by people who don't have sysv-rc installed. For example, I am unable to upgrade past openssh-server 1:6.2p2-1 or binfmt-support 2.0.13 because of this issue. Unfortunately, what I think this bug-fix really wanted was Conflicts: sysv-rc ( 2.88dsf-24), but there's no way to do that via the available substvars hooks. I'm kind of guessing on the Severity:. Looking for a Debian policy must that this violates, my best guess so far is 9.3.1: it must not be assumed by maintainer scripts that this method is being used, but that's maybe not exactly what is meant. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677650: Here's a patch that APPEARS to work
I don't know Ruby AT ALL, but I did a bit of googling and this appears to make unhide.rb work with 1.9: --- unhide.rb.orig 2012-12-06 23:53:57.0 -0500 +++ unhide.rb 2012-12-06 23:52:51.0 -0500 @@ -29,7 +29,11 @@ # Support for libc functions not covered by the standard Ruby # libraries module LibC - extend DL::Importable + if RUBY_VERSION =~ /^1\.8/ +extend DL::Importable + else +extend DL::Importer + end dlload libc.so.6 # PID scanning functions @@ -147,7 +151,7 @@ $ps_pids[pid] }], - [/proc, proc { |pid| + [/proc, lambda { |pid| # Is there a /proc entry for this pid? unless File.directory?(/proc/#{pid}) break The first hunk changes from DL::Importable to DL::Importer on versions above 1.8. Since the only method actually used is extern(), and the only change in 1.9 is addition optional flags, that's all the change yo need. Patch stolen from https://github.com/mwotton/Hubris/commit/84515473e079e36f799b8210b424d61b7248798a The second hunk deals with what appears to be a core change between 1.8 and 1.9. In 1.8, proc was an alias for lambda. In 1.9, there's a difference: lambda creates a new function scope (which things like break and return can jump to), while proc does not (so break and return try to return from the caller's scope) Explained at: http://www.skorks.com/2010/05/ruby-procs-and-lambdas-and-the-difference-between-them/#difference http://stackoverflow.com/questions/626/when-to-use-lambda-when-to-use-proc-new http://railspikes.com/2008/9/8/lambda-in-ruby-1-9 The other methods don't use break or return, so there's no need to change them. (I presume proc has somewhat less overhead.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691311: Upgrading liboctave1 confirmed to fix
I confirm this. The solution is to upgrade your liboctave1 package to version 3.6.3-2. Thanks for the tip; I would have upgraded that at the same time, but managed to overlook it since it's a long way away in an alphabetical list. That does indeed fix it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659784: Which version of libblas3 is #659784 fixed in?
As I reported on June 6, I'm still seeing the bug in libblas3 version 1.2.20110419-3: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=75;bug=659784 I notice it was re-marked fixed on the 9th, but I don't actually see a fixed version anywhere. I waited a few days for one to propagate through the package mirror system, but 1.2.20110419-3 still seems to be the current version. Setting up libblas3 (1.2.20110419-3) ... update-alternatives: error: alternative libblas.so.3gf can't be slave of libblas.so.3: it is a master alternative. dpkg: error processing libblas3 (--configure): subprocess installed post-installation script returned error exit status 2 dpkg: dependency problems prevent configuration of liblapack3: liblapack3 depends on libblas3 | libblas.so.3 | libatlas3-base; however: Package libblas3 is not configured yet. Package libblas.so.3 is not installed. Package libblas3 which provides libblas.so.3 is not configured yet. Package libatlas3-base is not installed. dpkg: error processing liblapack3 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of octave-control: octave-control depends on libblas3 | libblas.so.3 | libatlas3-base; however: Package libblas3 is not configured yet. Package libblas.so.3 is not installed. Package libblas3 which provides libblas.so.3 is not configured yet. Package libatlas3-base is not installed. octave-control depends on liblapack3; however: Package liblapack3 is not configured yet. dpkg: error processing octave-control (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of octave-optim: octave-optim depends on libblas3 | libblas.so.3 | libatlas3-base; however: Package libblas3 is not configured yet. Package libblas.so.3 is not installed. Package libblas3 which provides libblas.so.3 is not configured yet. Package libatlas3-base is not installed. octave-optim depends on liblapack3; however: Package liblapack3 is not configured yet. dpkg: error processing octave-optim (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: libblas3 liblapack3 octave-control octave-optim The symlink chain operates as follows: lrwxrwxrwx 1 root root 32 Apr 8 2010 /usr/lib/libblas.so.3gf - /etc/alternatives/libblas.so.3gf lrwxrwxrwx 1 root root 39 Apr 8 2010 /etc/alternatives/libblas.so.3gf - /usr/lib/atlas-sse/atlas/libblas.so.3gf lrwxrwxrwx 1 root root 16 Jul 8 2010 /usr/lib/atlas-sse/atlas/libblas.so.3gf - libblas.so.3gf.0 -rw-r--r-- 1 root root 2955532 Jul 8 2010 /usr/lib/atlas-sse/atlas/libblas.so.3gf.0 The currently selected altnerative is: # update-alternatives --query libblas.so.3gf Link: libblas.so.3gf Status: auto Best: /usr/lib/atlas-sse/atlas/libblas.so.3gf Value: /usr/lib/atlas-sse/atlas/libblas.so.3gf Alternative: /usr/lib/atlas-sse/atlas/libblas.so.3gf Priority: 40 Slaves: libatlas.so.3gf /usr/lib/atlas-sse/libatlas.so.3gf libcblas.so.3gf /usr/lib/atlas-sse/libcblas.so.3gf libf77blas.so.3gf /usr/lib/atlas-sse/libf77blas.so.3gf liblapack_atlas.so.3gf /usr/lib/atlas-sse/liblapack_atlas.so.3gf # dlocate libblas.so libatlas3gf-sse: /usr/lib/atlas-sse/atlas/libblas.so.3gf.0 libatlas3gf-sse: /usr/lib/atlas-sse/atlas/libblas.so.3gf libblas3: /usr/lib/libblas/libblas.so.3.0 libblas3: /usr/lib/libblas/libblas.so.3 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659784: Which version of libblas3 is #659784 fixed in?
Make sure atlas is also updated. It is likely to be your problem. Especially if you mix testing unstable. Huh; I've used unstable (not testing) for years. I actually do have testing in the sources.list, but I'm not using it. I think what's happened is that I have a specialized atlas package installed. They went away as of 3.8.3-25, but that never affected me, because I didn't have the base package installed. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-==-=-= un libatlas.so.3gfnone(no description available) un libatlas3-base none(no description available) un libatlas3gf-3dnow none(no description available) un libatlas3gf-base none(no description available) ii libatlas3gf-sse3.8.3-24 Automatically Tuned Linear Algebra Software, SSE1 shared un libatlas3gf-sse2 none(no description available) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641873: closed by Michael Gilbert michael.s.gilb...@gmail.com (Bug#641873: fixed in xpdf 3.03-9)
Thanks, I'll test it as soon as it reaches the FTP site. Sorry I haven't been following all the activity this last month... -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658258: Cups 1.5.0-16 breaks plain text printing
# grep texttops /etc/cups/mine.convs application/x-cshell application/postscript 33 texttops This is a local configuration file, not shipped by cups. So this does not break the package for everybody, but nevertheless is a rather important upgrade issue. But I don't want to argue about the severity of the report, we need to fix it one way or the other anyway. Um! That's very odd. dpkg -L cups and dpkg -S /etc/cups/mime.convs agree that the file is owned by the cups package. But you're right, it's not part of the contents of the current cups_1.5.0 packages. How the hell did *that* happen? Does it consitute a bug or misfeature in dpkg? This might be some historical leftover from an old version or something. (The Debian installation has been continuously tracking unstable since 1999 or so.) Unfortunately, my archive of old binary packages got trashed recently, so it's hard to check history. There could be a debconf warning, but I think it would be better to reintroduce a simple texttops shell wrapper which more or less does texttopdf | pdftops. Till wanted to look into this. You'd think it would be easy enough to log an error message like execve: /usr/lib/cups/filter/texttops: No such file or directory to bestow upon the humble sysadmin a clue as to *why* the document format is not supported. Amen.. :/ Hopefully the rant tag helped keep it from feeling too much like a personal attack. There should be a log message somewhere explaining the sequence of filters that cups chooses to apply, and detailed error output if any of them fail. I think it does when you do cupsctl --debug-logging. Already turned on. No such logs. :-( $ /usr/sbin/cupsctl _debug_logging=1 _remote_admin=1 _remote_any=0 _remote_printers=1 _share_printers=1 _user_cancel_any=1 BrowseLocalProtocols=CUPS dnssd lpd smb BrowseRemoteProtocols=CUPS DefaultAuthType=Basic JobPrivateAccess=default JobPrivateValues=default MaxLogSize=0 RIPCache=2044719k ServerAlias=$ALIAS.horizon.com ServerName=$HOST.horizon.com SubscriptionPrivateAccess=default SubscriptionPrivateValues=default SystemGroup=root lpadmin WebInterface=Yes $ COLUMNS=80 dpkg -l cups dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 497840 package 'cnews': error in Version string 'cr.g7-40.4': version number does not start with digit Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii cups 1.5.0-15 Common UNIX Printing System(tm) - server $ dpkg -L cups /. /etc /etc/fonts /etc/fonts/conf.d /etc/logrotate.d /etc/logrotate.d/cups /etc/pam.d /etc/pam.d/cups /etc/init.d /etc/init.d/cups /etc/cups /etc/cups/ssl /etc/cups/cupsd.conf /etc/cups/snmp.conf /etc/cups/ppd /etc/cups/cupsd.conf.default /etc/modprobe.d /etc/modprobe.d/blacklist-cups-usblp.conf /etc/default /etc/default/cups /usr /usr/lib /usr/lib/cups /usr/lib/cups/monitor /usr/lib/cups/monitor/bcp /usr/lib/cups/monitor/tbcp /usr/lib/cups/daemon /usr/lib/cups/daemon/cups-lpd /usr/lib/cups/daemon/cups-deviced /usr/lib/cups/daemon/cups-driverd /usr/lib/cups/daemon/cups-exec /usr/lib/cups/daemon/cups-polld /usr/lib/cups/notifier /usr/lib/cups/notifier/dbus /usr/lib/cups/notifier/rss /usr/lib/cups/notifier/mailto /usr/lib/cups/backend-available /usr/lib/cups/backend-available/dnssd /usr/lib/cups/backend-available/ipp /usr/lib/cups/backend-available/parallel /usr/lib/cups/backend-available/usb /usr/lib/cups/backend-available/lpd /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend-available/socket /usr/lib/cups/backend-available/serial /usr/lib/cups/cgi-bin /usr/lib/cups/cgi-bin/printers.cgi /usr/lib/cups/cgi-bin/admin.cgi /usr/lib/cups/cgi-bin/help.cgi /usr/lib/cups/cgi-bin/classes.cgi /usr/lib/cups/cgi-bin/jobs.cgi /usr/lib/cups/backend /usr/lib/cups/driver /usr/lib/cups/filter /usr/lib/cups/filter/cpdftocps /usr/lib/cups/filter/commandtops /usr/lib/cups/filter/rastertolabel /usr/lib/cups/filter/oopstops /usr/lib/cups/filter/rastertohp /usr/lib/cups/filter/gziptoany /usr/lib/cups/filter/texttops /usr/lib/cups/filter/bannertops /usr/lib/cups/filter/imagetops /usr/lib/cups/filter/rastertoepson /usr/lib/cups/filter/rastertopwg /usr/lib/cups/filter/pstops /usr/share /usr/share/man /usr/share/man/man8 /usr/share/man/man8/cups-driverd.8.gz /usr/share/man/man8/cups-polld.8.gz /usr/share/man/man8/cupsfilter.8.gz /usr/share/man/man8/cupsd.8.gz /usr/share/man/man8/cups-deviced.8.gz /usr/share/man/man5 /usr/share/man/man5/printers.conf.5.gz /usr/share/man/man5/mime.types.5.gz /usr/share/man/man5/cups-snmp.conf.5.gz /usr/share/man/man5/cupsd.conf.5.gz /usr/share/man/man5/mime.convs.5.gz /usr/share/man/man5/classes.conf.5.gz /usr/share/man/man5/mailto.conf.5.gz /usr/share/man/man5/subscriptions.conf.5.gz
Bug#658258: Cups 1.5.0-16 breaks plain text printing
Package: cups Version: 1.5.0-16 Severity: grave [521]$ echo Hello, world | lpr lpr: Unsupported document-format text/plain. The split off of a separate cups-filters package omits the texttops command which is called for in /etc/cups/mime.convs. # dpkg-deb -c cups-filters_1.0~b1-3_i386.deb | grep filter/ drwxr-xr-x root/root 0 2012-01-30 01:41 ./usr/lib/cups/filter/ -rwxr-xr-x root/root 34076 2012-01-30 01:41 ./usr/lib/cups/filter/rastertoescpx -rwxr-xr-x root/root 55960 2012-01-30 01:41 ./usr/lib/cups/filter/imagetoraster -rwxr-xr-x root/root149088 2012-01-30 01:41 ./usr/lib/cups/filter/pdftoopvp -rwxr-xr-x root/root 9500 2012-01-30 01:41 ./usr/lib/cups/filter/commandtoescpx -rwxr-xr-x root/root 89192 2012-01-30 01:41 ./usr/lib/cups/filter/texttopdf -rwxr-xr-x root/root 6481 2012-01-30 01:41 ./usr/lib/cups/filter/pstopdf -rwxr-xr-x root/root155740 2012-01-30 01:41 ./usr/lib/cups/filter/pdftopdf -rwxr-xr-x root/root 21904 2012-01-30 01:41 ./usr/lib/cups/filter/pdftoijs -rwxr-xr-x root/root 17752 2012-01-30 01:41 ./usr/lib/cups/filter/bannertopdf -rwxr-xr-x root/root 34076 2012-01-30 01:41 ./usr/lib/cups/filter/rastertopclx -rwxr-xr-x root/root 5404 2012-01-30 01:41 ./usr/lib/cups/filter/commandtopclx -rwxr-xr-x root/root 34196 2012-01-30 01:41 ./usr/lib/cups/filter/pdftoraster -rwxr-xr-x root/root 3561 2012-01-30 01:21 ./usr/lib/cups/filter/textonly -rwxr-xr-x root/root 34120 2012-01-30 01:41 ./usr/lib/cups/filter/imagetopdf -rwxr-xr-x root/root 21968 2012-01-30 01:41 ./usr/lib/cups/filter/pdftops # grep texttops /etc/cups/mine.convs application/x-cshellapplication/postscript 33 texttops application/x-csource application/postscript 33 texttops application/x-perl application/postscript 33 texttops application/x-shell application/postscript 33 texttops text/plain application/postscript 33 texttops text/html application/postscript 33 texttops This is Extremely Not Okay, thus the high severity level. grave: makes the package in question unusable or mostly so rant Have I also mentioned that cups error reporting (or, more specifically, the catastrophic lack of it) is a festering reeking maggot-ridden mountain of suppurating shit? You'd think it would be easy enough to log an error message like execve: /usr/lib/cups/filter/texttops: No such file or directory to bestow upon the humble sysadmin a clue as to *why* the document format is not supported. But no, all I get is: D [01/Feb/2012:14:35:11 +] Send-Document ipp://localhost:631/printers/lablp D [01/Feb/2012:14:35:11 +] cupsdIsAuthorized: requesting-user-name=$USER D [01/Feb/2012:14:35:11 +] [Job 138052] Auto-typing file... D [01/Feb/2012:14:35:11 +] [Job 138052] Request file type is text/plain. D [01/Feb/2012:14:35:11 +] Send-Document client-error-document-format-not-supported: Unsupported document-format text/plain. E [01/Feb/2012:14:35:11 +] Returning IPP client-error-document-format-not-supported for Send-Document (ipp://localhost:631/printers/lablp) from localhost D [01/Feb/2012:14:35:11 +] cupsdSetBusyState: newbusy=Dirty files, busy=Active clients and dirty files D [01/Feb/2012:14:35:11 +] cupsdReadClient: 17 WAITING Closing on EOF D [01/Feb/2012:14:35:11 +] cupsdCloseClient: 17 D [01/Feb/2012:14:35:11 +] cupsdSetBusyState: newbusy=Dirty files, busy=Dirty files ... leaving me to grovel though the configuration files and figure out not just which step of cups' byzantine internal processes is not working, but what those steps are in the first place! There should be a log message somewhere explaining the sequence of filters that cups chooses to apply, and detailed error output if any of them fail. Maybe I could just go back to lprng + magicfilter... /rant -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647598: chgrp: cannot access `/var/run/named': No such file or directory
Package: bind9 Version: 1:9.8.1.dfsg-1.1 I was updating an old system from bind 8, and there was no existing pid file in /var/run. Thus, postinst failed: Installing new version of config file /etc/bind/db.root ... Installing new version of config file /etc/bind/db.local ... Adding group `bind' (GID 101) ... Done. Adding system user `bind' (UID 101) ... Adding new user `bind' (UID 101) with group `bind' ... Not creating home directory `/var/cache/bind'. wrote key file /etc/bind/rndc.key NOT updating named.conf.options to include DNSSEC enablement # chgrp: cannot access `/var/run/named': No such file or directory dpkg: error processing bind9 (--configure): subprocess installed post-installation script returned error exit status 1 The fix is simple and obvious (touch the file in postinst), and this bug has been tagged pending upload since Nov. 6. What's the holdup? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649099: BIND 9 Resolver crashes after logging an error in query.c
Package: bind9 Version: 1:9.8.1.dfsg-1 Severity: serious Tags: security upstream As you have probably heard, someone has found a way to remotely crash a bind9 server: http://isc.sans.edu/diary.html?storyid=12049 https://www.isc.org/software/bind/advisories/cve-2011-4313 A stopgap patch (9.8.1-p1) is available, and should presumably be included in a Debian release ASAP. Severity only serious because so far it appears to be only a DoS. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647909: NetAddr::IP versions 4.045 through 4.053 are BROKEN
Package: libnetaddr-ip-perl Version: 4.056+dfsg-0 Severity: serious CPAN bug #71925 is preventing spamassassin from functioning correctly. The bug was fixed in 4.053. An additonal buglet (affecting only Perl 5.6.1 and older) was fixed in 4.054, which doesn't affect Debian, but the author recommends using only 4.054 and up (4.056 is current): https://rt.cpan.org/Public/Bug/Display.html?id=71925#txn-992867 I have hand-built a 4.056 package and can verify that it makes spamassassin start working. Please build a new package ASAP. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643967: prelink -u fails on some binaries; this breaks debsums
Package: prelink Version: 0.0.20090925-1 Severity: serious On i386, consider the following series of commands: # dpkg -i psmisc_22.14-1_i386.deb (snipped) # /usr/sbin/prelink -y --md5 /usr/bin/pstree bb296a950a089ec8a837a1c97b47eeb9 /usr/bin/pstree # /usr/sbin/prelink -mR -T /usr/bin/pstree # /usr/sbin/prelink -y --md5 /usr/bin/pstree prelink: Could not write temporary for /usr/bin/pstree: Layout error: overlapping sections The problem also happens with: 5d81333c2cf40ddee6d18139b01afd4b /usr/bin/peekfd prelink: Could not write temporary for /usr/bin/peekfd: Layout error: overlapping sections 95ae7ca0bc1685de6f840469efee /usr/bin/killall prelink: Could not write temporary for /usr/bin/killall: Layout error: overlapping sections ffc1b9a380a7afb6fdf32f9cd5b3c7d0 /bin/fuser prelink: Could not write temporary for /bin/fuser: Layout error: overlapping sections The same error crops uo when attempting any sort of undo operation. This breaks debsums runs, which is a pretty serious security problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536640: [Pkg-samba-maint] Bug#536640: Bug#536640: Samba 2:3.4.0-1 crashes on startup
Nothing unfortunately happened about that bug report. To submitter: I guess the problem is still happening, right? Er, well, I of course backed the version down and haven't tried again, but I expect it to fail exactly the same way. Testing... yes, it still blows up. Backing down to 3.3.6-1 again. Thank you for the response! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536640: Samba 2:3.4.0-1 crashes on startup
Package: samba Version: 2:3.4.0-1 Severity: grave After upgrading a working 3.3.6-1 configuration to 3.4.0-1, smbd started exploding on startup. This is an i386 (32-bit) userland on an AMD quad-processor (Phenom) with a 64-bit kernel. All packages from current debian/unstable. The failure is consistent. I haven't diffed thr output, but it looks the same each time. # strace -o /tmp/t -f /etc/init.d/samba start Starting Samba daemons: nmbd smbd*** glibc detected *** /usr/sbin/smbd: corrupted double-linked list: 0x08f5a4d0 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0x419b18c4] /lib/i686/cmov/libc.so.6[0x419b362b] /lib/i686/cmov/libc.so.6(cfree+0x96)[0x419b3866] /lib/i686/cmov/libc.so.6(freeifaddrs+0x1d)[0x41a453ad] /usr/sbin/smbd(get_interfaces+0x1e3)[0x831af23] /usr/sbin/smbd(load_interfaces+0x8f)[0x832990f] /usr/sbin/smbd(reload_services+0x94)[0x8614824] /usr/sbin/smbd(main+0x51c)[0x8615d8c] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0x41959775] /usr/sbin/smbd[0x80c3a41] === Memory map: 08047000-08728000 r-xp 09:05 4391449 /usr/sbin/smbd 08728000-08733000 r--p 006e1000 09:05 4391449 /usr/sbin/smbd 08733000-0873b000 rw-p 006ec000 09:05 4391449 /usr/sbin/smbd 0873b000-0873c000 rw-p 00:00 0 08eb-08f79000 rw-p 00:00 0 [heap] 41923000-4193f000 r-xp 09:05 2813335 /lib/ld-2.9.so 4193f000-4194 r--p 0001b000 09:05 2813335 /lib/ld-2.9.so 4194-41941000 rw-p 0001c000 09:05 2813335 /lib/ld-2.9.so 41943000-41a9b000 r-xp 09:05 2813355 /lib/i686/cmov/libc-2.9.so 41a9b000-41a9d000 r--p 00158000 09:05 2813355 /lib/i686/cmov/libc-2.9.so 41a9d000-41a9e000 rw-p 0015a000 09:05 2813355 /lib/i686/cmov/libc-2.9.so 41a9e000-41aa1000 rw-p 00:00 0 41aa3000-41aa5000 r-xp 09:05 2813099 /lib/i686/cmov/libdl-2.9.so 41aa5000-41aa6000 r--p 1000 09:05 2813099 /lib/i686/cmov/libdl-2.9.so 41aa6000-41aa7000 rw-p 2000 09:05 2813099 /lib/i686/cmov/libdl-2.9.so 41aa9000-41acd000 r-xp 09:05 2813385 /lib/i686/cmov/libm-2.9.so 41acd000-41ace000 r--p 00023000 09:05 2813385 /lib/i686/cmov/libm-2.9.so 41ace000-41acf000 rw-p 00024000 09:05 2813385 /lib/i686/cmov/libm-2.9.so 41ad1000-41ae6000 r-xp 09:05 2813444 /lib/i686/cmov/libpthread-2.9.so 41ae6000-41ae7000 r--p 00014000 09:05 2813444 /lib/i686/cmov/libpthread-2.9.so 41ae7000-41ae8000 rw-p 00015000 09:05 2813444 /lib/i686/cmov/libpthread-2.9.so 41ae8000-41aea000 rw-p 00:00 0 41aec000-41b0 r-xp 09:05 6721906 /usr/lib/libz.so.1.2.3.3 41b0-41b01000 rw-p 00013000 09:05 6721906 /usr/lib/libz.so.1.2.3.3 41c37000-41c41000 r-xp 09:05 2813458 /lib/libpam.so.0.81.12 41c41000-41c42000 rw-p 9000 09:05 2813458 /lib/libpam.so.0.81.12 41fbc000-41fe6000 r-xp 09:05 2813293 /lib/libgcc_s.so.1 41fe6000-41fe7000 rw-p 00029000 09:05 2813293 /lib/libgcc_s.so.1 4221d000-42223000 r-xp 09:05 2813469 /lib/libacl.so.1.1.0 42223000-42224000 rw-p 5000 09:05 2813469 /lib/libacl.so.1.1.0 42226000-4222a000 r-xp 09:05 2813278 /lib/libattr.so.1.1.0 4222a000-4222b000 rw-p 3000 09:05 2813278 /lib/libattr.so.1.1.0 42273000-42285000 r-xp 09:05 2813169 /lib/i686/cmov/libresolv-2.9.so 42285000-42286000 r--p 00011000 09:05 2813169 /lib/i686/cmov/libresolv-2.9.so 42286000-42287000 rw-p 00012000 09:05 2813169 /lib/i686/cmov/libresolv-2.9.so 42287000-42289000 rw-p 00:00 0 4270f000-42724000 r-xp 09:05 2813431 /lib/i686/cmov/libnsl-2.9.so 42724000-42725000 r--p 00014000 09:05 2813431 /lib/i686/cmov/libnsl-2.9.so 42725000-42726000 rw-p 00015000 09:05 2813431 /lib/i686/cmov/libnsl-2.9.so 42726000-42728000 rw-p 00:00 0 4275f000-42768000 r-xp 09:05 2813449 /lib/i686/cmov/libcrypt-2.9.so 42768000-42769000 r--p 8000 09:05 2813449
Bug#532517: Blum-Blum-Shub is unnecessary overkill
You want a cryptographically secure PRNG, but you don't need something as provably secure as BBS. Even more importantly, you need a cryptographically secure seed. (Fortunately, easy on Linux, where you can just use /dev/urandom.) There are any number of suitable CPRNGs. Probably a good safe bet would be the ANSI SP800-90 Deterministic Random Bit Generator (CTR-DRBG). Given something like 128-bit AES, the generator reduces to maintaining a 128-bit IV and a 128-bit key, and for each 128 bits of PRNG output, increment the IV and encrypt it with the key. I can supply implementation code if desired. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515720: [Pkg-hpijs-devel] Bug#515720: hp-setup -i dies when picking PPD
Mark Purcell m...@debian.org wrote: Can I ask you to try: the workaround: LANG= gksu hp-setup Actually, I did # LANG= hp-setup -i (I don't have the python-qt4 packages installed, so couldn't run GUI mode if I wanted to.) And it indeed did not blow up, although test page printing failed. Now I have to figure out just what it actually did... -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515720: [Pkg-hpijs-devel] Bug#515720: hp-setup -i dies when picking PPD
Mark Purcell m...@debian.org wrote: Actually, I did # LANG= hp-setup -i (I don't have the python-qt4 packages installed, so couldn't run GUI mode if I wanted to.) And it indeed did not blow up, although test page printing failed. Excellent. At least we are getting somewhere now. Have a look at the bug I referenced. There is an issue as CUPS returns details according to locale setting (LANG) but hplip only understands LANG=en responses. It has been forwarded upstream, but they haven't done much about it :-( Thanks. What's odd is that I had LANG unset, which usually defaults to en, especially for a California company like HP. But set to the empty string seems to make a difference. Odd. (Oops... I spoke too soon. It worked when I just tried it again. Maybe I had LANG set to something odd last time.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515720: hp-setup -i dies when picking PPD
I suspect this is the same bug, so I'm appending it to the existing bug report. When I run hp-setup -i, it starts out working okay. Select connection type... network/ethernet Select device... (probe delay)... hp:/net/HP_LaserJet_4100_Series?ip=192.35.100.71 HP_LaserJet_4100_Series,HP_LaserJet_4100_Series,lj4100 But then it explodes trying to find a PPD... Please enter a name for this print queue (m=use model name:'HP_LaserJet_4100'*, q=quit) ?lj4100 Using queue name: lj4100 error: No PPD found for model laserjet_4100. Trying old algorithm... warning: Found multiple possible PPD files Choose a PPD file that most closely matches your device: (Note: The model number may vary slightly from the actual model number on the device.) Num. PPD Filename Description - Traceback (most recent call last): File /usr/bin/hp-setup, line 496, in module mins_list = mins.keys() AttributeError: 'tuple' object has no attribute 'keys' hp-check complains noisily about not finding python-qt3 or python-qt4, and can't figure out the cups version, but has no other significant complaints. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.29-rc6-00063-gc3925d8 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages hplip depends on: ii adduser3.110 add and remove users and groups ii coreutils 7.1-2 The GNU core utilities ii cups 1.3.9-14+b1 Common UNIX Printing System(tm) - ii hplip-data 2.8.12-3 HP Linux Printing and Imaging - da ii libc6 2.9-4 GNU C Library: Shared libraries ii libcups2 1.3.9-14+b1 Common UNIX Printing System(tm) - ii libdbus-1-31.2.12-1 simple interprocess messaging syst ii libsane1.0.19-26 API library for scanners ii libsnmp15 5.4.1~dfsg-12 SNMP (Simple Network Management Pr ii libssl0.9.80.9.8g-15 SSL shared libraries ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii python 2.5.4-2 An interactive high-level object-o ii python-dbus0.83.0-1 simple interprocess messaging syst ii python-imaging 1.1.6-3 Python Imaging Library ii python-support 0.8.7 automated rebuilding support for P Versions of packages hplip recommends: ii cups-client 1.3.9-14+b1 Common UNIX Printing System(tm) - ii hpijs2.8.12-3HP Linux Printing and Imaging - gs ii sane-utils 1.0.19-26 API library for scanners -- utilit Versions of packages hplip suggests: ii gtklp 1.2.3-1.1 printing tool for CUPS on the GNOM ii hplip-doc 2.8.12-3 HP Linux Printing and Imaging - do pn hplip-gui none (no description available) pn openprinting-ppds none (no description available) -- no debconf information Other possibly relevant packages: pn cupsomatic-ppd none (no description available) pn foomatic-bin none (no description available) ii foomatic-db20090301-2 OpenPrinting printer support - database ii foomatic-db-en 4.0-20090301-1 OpenPrinting printer support - programs pn foomatic-db-gi none (no description available) pn foomatic-db-gu none (no description available) ii foomatic-db-hp 20090301-1 OpenPrinting printer support - database for ii foomatic-filte 4.0-20090301-3 OpenPrinting printer support - filters pn foomatic-filte none (no description available) pn foomatic-gui none (no description available) pn gnustep-ppdnone (no description available) pn hp-ppd none (no description available) pn hpijs-ppds none (no description available) pn hplip-ppds none (no description available) pn ipppd none (no description available) pn libppd-dev none (no description available) ii libppd02:0.10-7 postscript PPD file library pn linuxprinting. none (no description available) pn lpr-ppdnone (no description available) pn openprinting-p none (no description available) pn ppd-gs none (no description available) ii ppdfilt2:0.10-7 filter that inserts printer specific command pn pppdcapiplugin none (no description available) pn
Bug#390893: The apache2-common removal workaround
Oh, I'm sorry it wasn't obvious. The problem is that 1) apache2-common's prerm runs /etc/init.d/apache2 stop, which 2) runs /usr/sbin/apache2 -t, which 3) parses the config files, and does a full apache setup, which 4) tries to load all the modules, but 5) apache2-mpm-prefork has already been removed, so 6) it can't run. Or, more simply, apache2-common's prerm Depends: on all the apache2 stuff, and the fact that it isn't declared to causes a mess. The simple workaround is to ensure that there are no apache2 processes running (pgrep apache2), and then just comment the /etc/init.d/apache2 stop call out of /var/lib/dpkg/info/apache2-common.prerm. Actually, I just add exit 0 before all the dh_installinit stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320621: libdjvulibre1 3.5.14-6 changes soname without warning
Package: libdjvulibre1 Version: 3.5.14-6 Severity: serious Any number of packages that link to /usr/lib/libdjvulibre.so.14 (I hit evince 0.3.0-2 first) break horribly when libdjvulibre.so.15 is installed ahead. I'm not sure how this should be handled, but neither the changelog nor the version number change (3.5.14-5 to 3.5.14-6) gave any warning of such an important change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]