Bug#817232: Stil present in 1.158

2017-01-20 Thread sacrificial-spam-address 
# dpkg -s keyboard-configuration
Package: keyboard-configuration
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 2502
Maintainer: Debian Install System Team 
Architecture: 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

2015-10-22 Thread sacrificial-spam-address 
I was having the same problem, and indeed this fixes it.

Bug#793745: [PATCH] I'm seeing it too.

2015-08-02 Thread sacrificial-spam-address 
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.

2015-08-02 Thread sacrificial-spam-address 
 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

2013-09-20 Thread sacrificial-spam-address 
 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

2013-09-18 Thread sacrificial-spam-address 
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...

2013-09-17 Thread sacrificial-spam-address 
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

2013-09-17 Thread sacrificial-spam-address 
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

2013-09-17 Thread sacrificial-spam-address 
 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

2013-05-23 Thread sacrificial-spam-address 
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

2012-12-06 Thread sacrificial-spam-address 
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

2012-10-25 Thread sacrificial-spam-address 
 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?

2012-06-13 Thread sacrificial-spam-address 
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?

2012-06-13 Thread sacrificial-spam-address 
 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)

2012-02-24 Thread sacrificial-spam-address 
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

2012-02-07 Thread sacrificial-spam-address 
 # 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

2012-02-01 Thread sacrificial-spam-address 
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

2011-12-29 Thread sacrificial-spam-address 
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

2011-11-17 Thread sacrificial-spam-address 
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

2011-11-07 Thread sacrificial-spam-address 
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

2011-10-01 Thread sacrificial-spam-address 
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

2009-07-23 Thread sacrificial-spam-address 
 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

2009-07-11 Thread sacrificial-spam-address 
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

2009-06-22 Thread sacrificial-spam-address 
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

2009-03-15 Thread sacrificial-spam-address 
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

2009-03-15 Thread sacrificial-spam-address 
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

2009-03-08 Thread sacrificial-spam-address 
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

2006-10-03 Thread sacrificial-spam-address 
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

2005-07-30 Thread sacrificial-spam-address 
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]