Bug#993905: lxc-create fails GPG checkserver due to keyserver depreciation

[Kyle Spam marketing]

> Normally I'd send a message to 993905-d...@bugs.debian.org to close the
bug
> with the mentioned version, but I have a feeling that this issue is
primarily
> about a backported fix to stable and oldstable?
> Can you confirm that?

Yes, that is correct. So manually specifying a working key server would not
be required in order to use lxc-create for normal use.

>The sks-keyservers.net https certificate expired on 2021-04-23 and last
time I
> checked, it's completely defunct, so it's even worse then 'deprecated'.

Correct. Unfortunately the entire project was forced to shut down due to
issues complying with GDPR requirements.

On Thu, Oct 28, 2021 at 7:00 PM Diederik de Haas 
wrote:

> Control: fixed -1 1:4.0.10-1
>
> On Tue, 07 Sep 2021 20:21:12 -0400 Kyle  wrote:
> > Package: lxc
> > Version: 1:4.0.6-2
> >
> > lxc-create fails with the following error message caused by
> > sks-keyservers.net going offline, The lxc package currently in testing
> > includes a patch that fixes the issue by changing the keyserver from
> > pool.sks-keyservers.net to keyserver.ubuntu.com.
>
> Yes and the fix is part of version 4.0.10-1, so marking it accordingly.
>
> > This impacts both oldstable and stable as of writing this.
> >
> > -- System Information:
> > Debian Release: 11.0
> >   APT prefers stable-security
> >   APT policy: (500, 'stable-security'), (500, 'stable')
>
> Normally I'd send a message to 993905-d...@bugs.debian.org to close the
> bug
> with the mentioned version, but I have a feeling that this issue is
> primarily
> about a backported fix to stable and oldstable?
> Can you confirm that?
>
> The sks-keyservers.net https certificate expired on 2021-04-23 and last
> time I
> checked, it's completely defunct, so it's even worse then 'deprecated'.
>
> Cheers,
>   Diederik

Bug#940724: Fixed upstream

[spam-debian]

There is a 0.7.1 release upstream which should fix this crash.

Bug#940724: forward 940724 https://github.com/profanity-im/profanity/issues/1193

[spam-debian]

forward 940724 https://github.com/profanity-im/profanity/issues/1193
forward #940724 https://github.com/profanity-im/profanity/issues/1193



signature.asc
Description: PGP signature

Bug#940724: backtrace

[spam-debian]

I could reproduce it on my testing machine:

Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: Datei oder Verzeichnis nicht 
gefunden.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x7695c45f in __GI___strdup (s=0x0) at strdup.c:41
#2  0x555a840e in _create_tab (win=win@entry=19, wintype=, 
   identifier=identifier@entry=0x5d0b6490 "someone", highlight=highlight@entry=0) at src/ui/statusbar.c:201
#3  0x555a8477 in status_bar_active (win=win@entry=19, wintype=, 
   identifier=identifier@entry=0x5d0b6490 "someone") at src/ui/statusbar.c:218

#4  0x555a4f98 in ui_focus_win (window=0x5d0cac60) at 
src/ui/core.c:676
#5  ui_focus_win (window=window@entry=0x5d0cac60) at src/ui/core.c:645
#6  0x555bd76e in cmd_msg (window=0x5578f710, command=, 
args=)
   at src/command/cmd_funcs.c:2152
#7  0x555b9c27 in _cmd_execute (window=window@entry=0x5578f710, 
   command=command@entry=0x5a909890 "/msg", inp=inp@entry=0x5d0d5f70 "/msg someone")

   at src/command/cmd_funcs.c:7936
#8  0x555b9afe in cmd_process_input (inp=0x5d0d5f70 "/msg someone", 
window=0x5578f710)
   at src/command/cmd_funcs.c:139
#9  cmd_process_input (window=0x5578f710, inp=inp@entry=0x5d0d5f70 "/msg 
someone")
   at src/command/cmd_funcs.c:116
#10 0x55588a80 in prof_run (log_level=, 
account_name=) at src/profanity.c:116
#11 0x5558525f in main (argc=, argv=) at 
src/main.c:172



signature.asc
Description: PGP signature

Bug#872257: Possible memory leak

[spam]

Package: qemu-system-x86

Version: 1:2.8+dfsg-6+deb9u2

 
With this version every running domU slowly fills up the available RAM and 
random oom-kills happens.

I have only HVM domUs, so don’t know if the same happens with PV domUs.

 
I tried the following in grub:

-  dom0_mem=8192M

-  dom0_mem=8192M,max:8192M

-  dom0_mem=8192M,min:8192M,max:8192M

with ballooning disabled, didn’t work.

 
I tried it with ballooning and without the dom0_mem parameter, didn’t work.

I tried it with downgraded kernel package, didn’t work.

 
On every tries, the behavior is the same:

-  VM starts

-  Top’s output of a domU that has „memory=2048M” in config and Xen 
booted up with ballooning disabled:
17781 root  20   0 3871,7m 3,178g   3,6m S   2,9 41,6   3:18.95   
qemu-system-x86   6 4   3:18   0,0m 0

 
Once I reverted the qemu-system-x86 package back to version 1:2.8+dfsg-6 the 
error went away.

 
Regards,

Csaba

<>

Bug#854712: popularity-contest.postinst is doing silly things with /dev/urandom

[sacrificial-spam-address]

>> When this code was written, uuidgen was Essential: yes and so was available
>> on every Debian system, so the second method was never used.

Makes sense, but the fallback code has come to life.

> Which kernel version provides /proc/sys/kernel/random/uuid ?

It predates the start of the git era in 2.6.12-rc2, and a quick search
of earlier history shows it was in 2.3.16, and was not in 2.3.15pre3.

http://repo.or.cz/davej-history.git/blob/0d447745e5268dca6201eaa095a28cc79bd28be0:/drivers/char/random.c
http://repo.or.cz/davej-history.git/blob/9ec0c4e2f8eff2496373ebbd1010aa8484b59495:/drivers/char/random.c

The 2.3.16 file is dated 30 August 1999.

> What about kfreebsd ?

FreeBSD appears to use a uuidgen(2) system call rather than a /proc
file:
https://www.freebsd.org/cgi/man.cgi?query=uuidgen=2

... however, that uses the clock+MAC form

https://github.com/freebsd/freebsd/blob/386ddae58459341ec567604707805814a2128a57/sys/kern/kern_uuid.c

Bug#854712: popularity-contest.postinst is doing silly things with /dev/urandom

[sacrificial-spam-address]

Package: popularity-contest
Version: 1.64

generate_id() {
if which uuidgen >/dev/null 2>&1; then
MY_HOSTID=`uuidgen | tr -d -`
else
MY_HOSTID=`dd if=/dev/urandom bs=1k count=1 2>/dev/null | 
md5sum | sed 's/  -//'''`
fi

}

A few notes:

1) You do not need, and should not use, 1 kilobyte of entropy to generate
   a 16-byte random number.  You should use 128 bits of seed material,
   not 8192!
2) If you want a random uuid, then /proc/sys/kernel/random/uuid will
   provide one for you, just like uuidgen.
3) There's no need to hash the output of /dev/urandom.  Simpler would be
   to just use "od -x -An -N16 /dev/urandom".  (od and md5sum are both
   in coreutils.)

I'd suggest:

if which uuidgen >/dev/null 2>&1; then
MY_HOSTID=`uuidgen -r | tr -d -`
else if test -r /proc/sys/kernel/random/uuid; then
MY_HOSTID=`tr -d - < /proc/sys/kernel/random/uuid`
else
MY_HOSTID=`od -x -An -N16 /dev/urandom | tr -d ' '`
fi

Bug#817232: Stil present in 1.158

[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#823882: bonnie++ -s 0 -n 1:-2:0:32 doesn't work

[sacrificial-spam-address]

Package: bonnie++
Version: 1.97.1+b1

If you ask for symlinks and subdirectories, bonnie++ creates
dangling symlinks and fails:

$ /usr/sbin/bonnie++ -d /tmp -s 0 -n 1:-2:0:32
Create files in sequential order...done.
Stat files in sequential order...Can't stat file 20P
Cleaning up test directory after error.

The criticial operations are:

22368 chdir("/tmp") = 0
22368 mkdir("./Bonnie.22368", 0700) = 0
22368 chdir("./Bonnie.22368")   = 0
22368 mkdir("0", 0700)  = 0
...
22368 mkdir("00031", 0700)  = 0
22368 open("0/00D", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
22368 symlink("0/00D", "0/01d6l5hxs") = 0
...
22368 symlink("0/00D", "0/20P") = 0
...
22368 symlink("0/00D", "00031/0003ffPO") = 0
22368 chdir("0")= 0
22368 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
22368 stat64("20P", 0xffb551b0) = -1 ENOENT (No such file or directory)

The problem is that /tmp/Bonnie.22368/0/20P is a symlink to
/tmp/Bonnie.22368/0/0/00D, which doesn't exist.


There are two obvious fixes, but I'm not sure which is preferred:
1) add "../" to the front of the symlink targets
2) create one real file per directory and remove the directory
   name from the symlink targets.

Bug#803420: gnome-packagekit: should depend on packagekit (gpk-application window is blank)

[Fu Spam]

Package: gnome-packagekit
Version: 3.18.0-1
Followup-For: Bug #803420

Dear Maintainer,

I can confirm gnome-packagekit doesn't work without packagekit. It
doesn't update and doesn't show any packages, just a blank window.

It should depend on packagekit. Installing it fixed it for mee too.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-packagekit depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gnome-packagekit-data3.18.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-7
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.0-1
ii  libgtk-3-0   3.20.3-2
ii  libnotify4   0.7.6-2
ii  libpackagekit-glib2-18   1.1.0-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libsqlite3-0 3.12.2-1
ii  libx11-6 2:1.6.3-1

gnome-packagekit recommends no packages.

gnome-packagekit suggests no packages.

-- no debconf information

Bug#820056: writeable file 'foo': already in use

[sacrificial-spam-address]

Package: bind9
Version: 1:9.10.3.dfsg.P4-6
Architecture: i386
Severity: important

Discussion of this issue can be found at
http://bind-users-forum.2342410.n4.nabble.com/Single-slave-zone-definition-for-two-view-cache-file-name-problem-td12.html
https://www.linuxquestions.org/questions/linux-server-73/bind-9-10-same-zone-in-two-views-4175572231-print/

Like many people running split DNS (multiple views), a large number
of my zones are common to the two.  So when setting this up, I did the
obvious thing:

zone "internal" {
match-clients { ... };
recursion yes;
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
include "/etc/bind/named.conf.common";

/* Zones private to this view */
};

zone "external" {
match-clients { any; };
recursion no;
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
include "/etc/bind/named.conf.common";

/* Zones private to this view */
};

Where named.conf.common contains various zones my name server
is authoritative for, and some zones it is secondary for like like:

zone "foo" {
type slave;
file "/etc/bind/cache/db.cache.foo";
masters { foo_name_servers; };
allow-transfer { any; };
};

While comments from the BIND maintainers suggest that it may have been
buggy, it was a sensible thing to do and worked for many years.  BIND 9.10
now detects this and fails to start, producing error messages like:

Apr  4 20:55:00 ns named[27115]: /etc/bind/named.conf.common:81: writeable file 
'/etc/bind/cache/db.cache.foo': already in use: /etc/bind/named.conf.common:81

Needless to say, named not starting leads to complete DNS failure and
is a pretty unhappy state to upgrade to.  (Thus the "Severity: important".)

At first, I thought this was a bug (how can a config file line conflict
with itself?), but then I realized that the conflict was between the
two views.

There does not appear to be any simple workaround.  The best solution
appears to be to use the new BIND 9.10 "in-view" feature, which allows a
zone in one view to be a reference to the same zone in a different view.
When this is done, both views may share the same cache file.

The down side is that this violates one of the important principles of
programming: only specify something in one place.  Instead, I have to have
a "master" definition and several "in-view" declarations referencing
the master.

I wish BIND would either deal with the problem after noticing it (by
automatically doing the equivalent of the in-view), or provide a way to
import every zone in a view, avoiding the need for a long list of in-view
declarations.


In case it helps anyone else, here's my current workaround:

One file declares a non-published view "common" as follows:

view "common" {
match-clients { none; };

zone "foo" {
...
};
...
};

Then I use the following sed script on that file (which relies on each
"zone" header being on a line by itself, preceded by a tab)

# Script to convert each zone in a view to a series of in-view declarations
1i\
// Automatically generated by Makefile and in-view.sed\
// MANUAL EDITS WILL BE LOST
/^  zone/{
a\
in-view "common";\
};
p
}

And I created a Makefile that applies the recipe
sed -n -f in-view.sed $< > $@
to produce a series of references that can then be included within
each view:

zone "foo" {
in-view "common";
};

Bug#812589: fsck -M has stopped working

[sacrificial-spam-address]

>> The "802" is the root= argument passed to the kernel by the boot loader.
>> Major device 8, minor 2.  What I don't understand is why libmount thinks
>> it's a file name (in $PWD, no less).

> The boot loader should be passing "/dev/sda2", not "802".  Are you using
> an ancient boot loader ( like the dos linload.com ) or something?

Package: lilo
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 649
Maintainer: Joachim Wiedorn 
Architecture: i386
Version: 1:24.2-1

And regardless of the boot loader, if the kernel is documented as accepting
a root= format, code that parses /proc/cmdlike should handle it gracefully.

At an *absolute* minimum provide a specific error message that a
particular format is not supported, as opposed to implementing RFC 748
and losing randomly.

Bug#812589: fsck -M has stopped working

[sacrificial-spam-address]

> Thanks for your bug report, but I'm not able to reproduce it and
> it lacks information needed to investigate it. (Tagged as such
> in a separate email to the bug tracking system.)

Sorry, I tried to include pretty much everything.

> Also adding -V (for verbose) would give some additional information.

Actually, the additional info is very limited (basically, showing
the invocation of f2ck.ext4) which is already after is_mounted()
has returned the wrong answer, so it wasn't helpful.

> 7320: libmount: INIT: library debug mask: 0x
> 7320: libmount: INIT: library version: 2.27.0
> 7320: libmount: INIT: feature: selinux
> 7320: libmount: INIT: feature: assert
> 7320: libmount: INIT: feature: debug
> Available "LIBMOUNT_DEBUG=[,...]|" debug masks:
>all  [0x] : info about all subsystems
>cache[0x0004] : paths and tags cache
>cxt  [0x0200] : library context (handler)
>diff [0x0400] : mountinfo changes tracking
>fs   [0x0040] : FS abstraction
>help [0x0001] : this help
>locks[0x0010] : mtab and utab locking
>options  [0x0008] : mount options parsing
>tab  [0x0020] : fstab, mtab, mounninfo routines
>update   [0x0080] : mtab, utab updates
>utils[0x0100] : misc library utils
>monitor  [0x0800] : mount tables monitor
> 7320: libmount:CACHE: [0x9480048]: alloc
> fsck from util-linux 2.27.1
> 7320: libmount:  TAB: [0x9480068]: alloc
> 7320: libmount:  TAB: [0x9480068]: /etc/fstab: start parsing [entries=0, 
> filter=not]
> 7320: libmount:  TAB: [0x9480068]: add entry: /dev/sda2 /
> 7320: libmount:  TAB: [0x9480068]: add entry: UUID=[swap device] none
> 7320: libmount:  TAB: [0x9480068]: add entry: proc /proc
> 7320: libmount:  TAB: [0x9480068]: add entry: sys /sys
> 7320: libmount:  TAB: [0x9480068]: add entry: dev /dev
> 7320: libmount:  TAB: [0x9480068]: add entry: devpts /dev/pts
> 7320: libmount:  TAB: [0x9480068]: add entry: [network mount redacted]
> 7320: libmount:  TAB: [0x9480068]: add entry: /dev/sr0 /media/cdrom0
> 7320: libmount:  TAB: [0x9480068]: add entry: /dev/mmcblk0p1 /mnt
> 7320: libmount:   FS: [0x9480b30]: free [refcount=0]
> 7320: libmount:  TAB: [0x9480068]: /etc/fstab: stop parsing (9 entries)
> 7320: libmount:  TAB: [0x9480068]: parsing done [filename=/etc/fstab, 
> rc=0]
> 7320: libmount:CACHE: [0x9480048]: canonicalize path /dev/sda2
> 7320: libmount:CACHE: [0x9480048]: add entry [ 1] (path): /dev/sda2: 
> /dev/sda2
> 7320: libmount:  TAB: [0x9480068]: lookup TARGET: '/'
> 7320: libmount:  TAB: [0x9480130]: alloc
> 7320: libmount:  TAB: [0x9480130]: mtab parse: ignore mtab
> 7320: libmount:  TAB: [0x9480130]: mtab parse: #1 read mountinfo
> 7320: libmount:  TAB: [0x9480130]: /proc/self/mountinfo: start parsing 
> [entries=0, filter=not]
> 7320: libmount:  TAB: [0x9480130]: add entry: /dev/root /
> 7320: libmount:CACHE: canonicalize path /proc/self/mountinfo
> 7320: libmount:  TAB: TID for /proc/self/mountinfo is 7320
> 7320: libmount:  TAB: [0x9480130]: root FS: 802
> 7320: libmount:CACHE: [0x9480048]: canonicalize path 802
> 7320: libmount:CACHE: [0x9480048]: add entry [ 2] (path): 802: 802
> 7320: libmount:  TAB: [0x9480130]: canonical root FS: 802

> This '802' business looks weird. Having your complete
> /proc/self/mountinfo would be useful.

The "802" is the root= argument passed to the kernel by the boot loader.
Major device 8, minor 2.  What I don't understand is why libmount thinks
it's a file name (in $PWD, no less).

13 0 8:2 / / rw,relatime - ext4 /dev/root rw,errors=remount-ro,data=ordered
14 13 0:13 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
15 13 0:14 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs 
rw,size=335456k,mode=755
16 15 0:15 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs 
rw,size=5120k
17 13 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
18 13 0:6 / /dev rw,nosuid,relatime - devtmpfs devtmpfs 
rw,size=10240k,nr_inodes=216237,mode=755
19 15 0:16 / /run/shm rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs 
rw,size=1454860k
20 18 0:11 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620

> This is where things should return true for is_mounted(...) but
> apparently doesn't for you. In verbose mode you should get:
> "/dev/sda2 is mounted"

I get "is not mounted", followed by e2fsck saying "is mounted".

> Without access to your mountinfo there's not much I can do to help you
> out and without a proper submitter address I'm not able to reach you,

Oh, it's a proper address.  At first I was worried about spammers address
harvesing the BTS and cr

Bug#812589: fsck -M has stopped working

[sacrificial-spam-address]

Package: util-linux
Version: 2.27.1-1
Architecture: i386

(libmount1 and libblkid1 are also 2.27.1.)

My most recent reboot (and it's been a while, so it may be some dependent
library or new 4.4 kernel or something) failed in checkfs.sh.

Upon debugging, it appeared that the invocation of "fsck -C -M -A -a"
was, despite the -M flag, trying to check /dev/sda2, my root file
system.

e2fsck of course complained about this, leading to a recovery shell
and a need for manual intervention.

$ cat /var/log/fsck/checkfs
Log of fsck -C -M -A -a 
Sun Jan 24 20:36:30 2016

fsck from util-linux 2.27.1
/dev/sda2 is mounted.
e2fsck: Cannot continue, aborting.


fsck exited with status code 8

Sun Jan 24 20:36:30 2016



Running fsck under strace shows the following interesting parts
(boring bits like memory allocation elided):

open("/etc/fstab", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, ...)
close(3) = 0
lstat64("/dev", {st_mode=S_IFDIR|0755, st_size=3420, ...}) = 0
lstat64("/dev/sda2", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 2), ...}) = 0
stat64("/dev/sda2", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 2), ...}) = 0
# NFclue why it needs a stat() after lstat() says it's not a symlink
stat64("/sbin/fsck.ext4", ...) = 0  # Path search
open("/proc/self/mountinfo", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "13 0 8:2 / / rw,relatime - ext4 "..., 1024) = 638
# That's the right root file system
readlink("/proc/self", "2690", 4095)= 4
lstat64("/proc/2690/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
# Not sure what's being reverified here
open("/proc/cmdline", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
read(5, "auto BOOT_IMAGE=Linux ro root=802 "..., 1024) = 155
close(5)= 0
getcwd("$HOME", 4096)
# No, not literally, I've substituted
lstat64("$HOME/802", ...) = -1 ENOENT
# This looks wrong
read(3, "", 1024)   = 0
close(3)= 0
... then it clone()s and tries to run fsck.ext4.

I'd think the process of elimination would go as follows:
- For each line in /etc/fstab
- If it's a real file system for which we have an fsck, stat
  the device node.
- Search /proc/self/mountinfo for the same device mode.  If it's
  mounted already (rw or ro), skip it.

Poking around the code, I also found some debug options.
Trying LIBMOUNT_DEBUG=all LIBBLKID_DEBUG=all fsck -C -M -A
produces:

7320: libmount: INIT: library debug mask: 0x
7320: libmount: INIT: library version: 2.27.0
7320: libmount: INIT: feature: selinux
7320: libmount: INIT: feature: assert
7320: libmount: INIT: feature: debug
Available "LIBMOUNT_DEBUG=[,...]|" debug masks:
   all  [0x] : info about all subsystems
   cache[0x0004] : paths and tags cache
   cxt  [0x0200] : library context (handler)
   diff [0x0400] : mountinfo changes tracking
   fs   [0x0040] : FS abstraction
   help [0x0001] : this help
   locks[0x0010] : mtab and utab locking
   options  [0x0008] : mount options parsing
   tab  [0x0020] : fstab, mtab, mounninfo routines
   update   [0x0080] : mtab, utab updates
   utils[0x0100] : misc library utils
   monitor  [0x0800] : mount tables monitor
7320: libmount:CACHE: [0x9480048]: alloc
fsck from util-linux 2.27.1
7320: libmount:  TAB: [0x9480068]: alloc
7320: libmount:  TAB: [0x9480068]: /etc/fstab: start parsing [entries=0, 
filter=not]
7320: libmount:  TAB: [0x9480068]: add entry: /dev/sda2 /
7320: libmount:  TAB: [0x9480068]: add entry: UUID=[swap device] none
7320: libmount:  TAB: [0x9480068]: add entry: proc /proc
7320: libmount:  TAB: [0x9480068]: add entry: sys /sys
7320: libmount:  TAB: [0x9480068]: add entry: dev /dev
7320: libmount:  TAB: [0x9480068]: add entry: devpts /dev/pts
7320: libmount:  TAB: [0x9480068]: add entry: [network mount redacted]
7320: libmount:  TAB: [0x9480068]: add entry: /dev/sr0 /media/cdrom0
7320: libmount:  TAB: [0x9480068]: add entry: /dev/mmcblk0p1 /mnt
7320: libmount:   FS: [0x9480b30]: free [refcount=0]
7320: libmount:  TAB: [0x9480068]: /etc/fstab: stop parsing (9 entries)
7320: libmount:  TAB: [0x9480068]: parsing done [filename=/etc/fstab, rc=0]
7320: libmount:CACHE: [0x9480048]: canonicalize path /dev/sda2
7320: libmount:CACHE: [0x9480048]: add entry [ 1] (path): /dev/sda2: 
/dev/sda2
7320: libmount:  TAB: [0x9480068]: lookup TARGET: '/'
7320: libmount:  TAB: [0x9480130]: alloc
7320: libmount:  TAB: [0x9480130]: mtab parse: ignore mtab
7320: libmount:  TAB: [0x9480130]: mtab parse: #1 read mountinfo
7320: libmount:  TAB: [0x9480130]: /proc/self/mountinfo: start parsing 
[entries=0, filter=not]
7320: libmount:  TAB: [0x9480130]: add entry: /dev/root /
7320: libmount:CACHE: canonicalize path /proc/self/mountinfo
7320: libmount:  TAB: TID for /proc/self/mountinfo is 7320
7320: 

Bug#802638: "rlimit memlock -1" fixes it

[sacrificial-spam-address]

I was having the same problem, and indeed this fixes it.

Bug#801275: iceweasel wakes up at 60 Hz when idle

[sacrificial-spam-address]

Package: iceweasel
Version: 41.0.1-1
Architecture: i386

This is probably a generic firefox bug, but I'm starting here to
respoect the firefox/iceweasel split.

Basicallly, when I have iceweasel idling with a lot of tabs open,
it burns 10-20% CPU doing nothing.

The desired behaviour, when there is no UI activity and all pages have
finished loading, is that it use zero.  Not approximately zero, but each
and every thread blocked on a system call with no timeout.  (If pressed,
I will accept long (> 1000 second) timeouts for cache discard, software
update checks, and so on.)

Upon investigation, I discovered that there is one thread that seems
to be spinning doing (blank lines added):

$ strace -r -p 12917

 0.60 write(27, "\372", 1)  = 1
 0.57 clock_gettime(CLOCK_MONOTONIC, {51966, 125267419}) = 0
 0.51 clock_gettime(CLOCK_MONOTONIC, {51966, 125317984}) = 0
 0.49 clock_gettime(CLOCK_MONOTONIC, {51966, 125367361}) = 0
 0.45 clock_gettime(CLOCK_MONOTONIC, {51966, 125412268}) = 0
 0.46 clock_gettime(CLOCK_MONOTONIC, {51966, 125458852}) = 0
 0.47 clock_gettime(CLOCK_MONOTONIC, {51966, 125504807}) = 0
 0.46 clock_gettime(CLOCK_MONOTONIC, {51966, 125550762}) = 0
 0.45 clock_gettime(CLOCK_MONOTONIC, {51966, 125597486}) = 0
 0.55 clock_gettime(CLOCK_MONOTONIC, {51966, 125652590}) = 0
 0.37 clock_gettime(CLOCK_MONOTONIC, {51966, 125694075}) = 0
 0.52 futex(0x9a5f910c, FUTEX_WAIT_BITSET_PRIVATE, 1, {51966, 
142406075}, ) = -1 ETIMEDOUT (Connection timed out)
 0.016789 clock_gettime(CLOCK_MONOTONIC, {51966, 142533466}) = 0
 0.42 futex(0x9a5f90f0, FUTEX_WAKE_PRIVATE, 1) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 142604773}) = 0
 0.35 clock_gettime(CLOCK_MONOTONIC, {51966, 142640252}) = 0

 0.40 write(27, "\372", 1)  = 1
 0.38 clock_gettime(CLOCK_MONOTONIC, {51966, 142718194}) = 0
 0.38 clock_gettime(CLOCK_MONOTONIC, {51966, 142756187}) = 0
 0.38 clock_gettime(CLOCK_MONOTONIC, {51966, 142793971}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 142827425}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 142860878}) = 0
 0.35 clock_gettime(CLOCK_MONOTONIC, {51966, 142896078}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 142929462}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 142963195}) = 0
 0.35 clock_gettime(CLOCK_MONOTONIC, {51966, 142998744}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 143031848}) = 0
 0.35 futex(0x9a5f910c, FUTEX_WAIT_BITSET_PRIVATE, 1, {51966, 
158823848}, ) = -1 ETIMEDOUT (Connection timed out)
 0.015913 clock_gettime(CLOCK_MONOTONIC, {51966, 158985591}) = 0
 0.50 futex(0x9a5f90f0, FUTEX_WAKE_PRIVATE, 1) = 0
 0.42 clock_gettime(CLOCK_MONOTONIC, {51966, 159072403}) = 0
 0.37 clock_gettime(CLOCK_MONOTONIC, {51966, 159109069}) = 0

 0.55 write(27, "\372", 1)  = 1
 0.42 clock_gettime(CLOCK_MONOTONIC, {51966, 159205589}) = 0
 0.37 clock_gettime(CLOCK_MONOTONIC, {51966, 159243023}) = 0
 0.38 clock_gettime(CLOCK_MONOTONIC, {51966, 159281017}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 159314191}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 159347575}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 159381517}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 159415320}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 159448564}) = 0
 0.36 clock_gettime(CLOCK_MONOTONIC, {51966, 159484951}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 159517986}) = 0
 0.34 futex(0x9a5f910c, FUTEX_WAIT_BITSET_PRIVATE, 1, {51966, 
175309986}, ) = -1 ETIMEDOUT (Connection timed out)
 0.015914 clock_gettime(CLOCK_MONOTONIC, {51966, 175473195}) = 0
 0.52 futex(0x9a5f90f0, FUTEX_WAKE_PRIVATE, 1) = 0
 0.45 clock_gettime(CLOCK_MONOTONIC, {51966, 175562731}) = 0
 0.37 clock_gettime(CLOCK_MONOTONIC, {51966, 175599258}) = 0
 0.39 clock_gettime(CLOCK_MONOTONIC, {51966, 175639625}) = 0
 0.46 clock_gettime(CLOCK_MONOTONIC, {51966, 175685022}) = 0
 0.39 clock_gettime(CLOCK_MONOTONIC, {51966, 175723993}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 175757237}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 175791598}) = 0
 0.35 clock_gettime(CLOCK_MONOTONIC, {51966, 175825750}) = 0
 0.34 clock_gettime(CLOCK_MONOTONIC, {51966, 175858994}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 175892937}) = 0
 0.37 clock_gettime(CLOCK_MONOTONIC, {51966, 175929813}) = 0
 0.33 clock_gettime(CLOCK_MONOTONIC, {51966, 175962847}) = 0
 0.35 futex(0x9a5f910c, FUTEX_WAIT_BITSET_PRIVATE, 1, {51966, 
191752847}, ) = -1 ETIMEDOUT (Connection timed out)
 0.015947 clock_gettime(CLOCK_MONOTONIC, {51966, 191950603}) = 0

Bug#794983: vlc does weird things with the .lock file

[sacrificial-spam-address]

Package: vlc
Version: 2.2.1-2+b2
Architecture: i386
Severity: minor

Somehow (it may have been a transient error caused by C++ ABI upgrades),
I ended up with:

$ ls ~/.config/vlc/
vlc-qt-interface.conf
vlc-qt-interface.conf.lock
vlc-qt-interface.conf.lock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock
...
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock

and ended up with vlc stuck looping retrying

open(/home/xxx/.config/vlc/vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock,
 O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE|O_CLOEXEC, 0644) = -1 ENAMETOOLONG (File 
name too long)

(Note that at no point did I have more than two copies of vlc running.)


Once I deleted all those files, things started working.  But shouldn't it be
able to figure out that ENAMETOOLONG won't be solved by retrying?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#794594: aptitude: undefined symbol: _ZN7cwidget7widgets5pager8set_textERKSsPKc

[sacrificial-spam-address]

Axel Beckert wrote:
 I am a bit lost with this, what is it exactly that it doesn't work?
 aptitude failing to load (or compile) with the binNMUed cwidget?

If you install libcwidget_0.5.17-3+b1, then aptitude 0.6.11-1+b1
fails with

# aptitude
aptitude: symbol lookup error: aptitude: undefined symbol: 
_ZN7cwidget7widgets5pager8set_textERKSsPKc

Reverting libcwidget fixes the error.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[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-dist-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.

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788942: Dependency on non-multiarch libepoxy0 breaks multiarch

[sacrificial-spam-address]

Package: libgtk-3-0
Version: 3.16.4-2

I can't upgrade libgtk-3-0:i386 and libgtk-3-0:amd64, because both want
the corresponding libepoxy0, and it's not multiarch, so that's not possible.

The fix might be to make libepoxy multiarch (it already puts its
library in the right directory), but adding that dependency before
fixing libepoxy is a bug in gtk+3.0.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785643: Multi-Arch: foreign would be nice

[sacrificial-spam-address]

Package: liberror-perl
Version: 0.17-1.1
Severity: wishlist

Trying to install amd64 git (because git repack really likes VM) on a mostly
i386 system, apt gets all grumpy because the current package can't satisfy
an amd64 dependency.

But adding

Multi-Arch: foreign
Depends: perl:any

makes things much happier.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781055: Mute button behaves oddly

[sacrificial-spam-address]

Package: linphone
Version: 3.6.1-2.4+b1
Architecture: i386

Pressing the mute button draws a red X on the button and audio is
muted.

After a minute or so, the red X disappears, but audio remains muted.

If I click again, the red X re-appears for another minute, then
disappears again.  The audio remains muted.

To un-mute audio, the user has to click once to make the X appear,
then again to make it disappear.

It's an annoying UI-out-of-sync-with-engine problem.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778443: Installation report on HP 635

[spam]

Package: installation-reports

Boot method: Network
Image version: I used the daily jigdo CD download from 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/jigdo-cd/

Date: Sun, Feb 15, 02:00 CET

Machine: HP 635
Processor: AMD E-450 APU with 1,65 GHz
Memory: 4 GB
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
/dev/sda5  ext4  31287200 6025940  23648924  21% /
udev   devtmpfs 10240   0 10240   0% /dev
tmpfs  tmpfs   7301089320720788   2% /run
tmpfs  tmpfs  18252642256   1823008   1% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
tmpfs  tmpfs  1825264   0   1825264   0% /sys/fs/cgroup
tmpfs  tmpfs   365056   8365048   1% /run/user/1000

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
14h Processor Root Complex [1022:1510]
Subsystem: Advanced Micro Devices, Inc. [AMD] Family 14h 
Processor Root Complex [1022:1510]
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Wrestler [Radeon HD 6320] [1002:9806]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: fglrx_pci
00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
Wrestler HDMI Audio [1002:1314]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: snd_hda_intel
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: ahci
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: ohci-pci
00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: ehci-pci
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus 
Controller [1002:4385] (rev 42)

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: piix4_smbus
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
SBx00 Azalia (Intel HDA) [1002:4383] (rev 40)

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: snd_hda_intel
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40)

Subsystem: Hewlett-Packard Company Device [103c:3577]
00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 
PCI to PCI Bridge [1002:4384] (rev 40)
00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: ohci-pci
00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) [1002:43a0]

Kernel driver in use: pcieport
00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB700/SB800/SB900 PCI to PCI bridge (PCIE port 1) [1002:43a1]

Kernel driver in use: pcieport
00:15.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SB900 
PCI to PCI bridge (PCIE port 3) [1002:43a3]

Kernel driver in use: pcieport
00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: ohci-pci
00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]

Subsystem: Hewlett-Packard Company Device [103c:3577]
Kernel driver in use: ehci-pci
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h Processor Function 0 [1022:1700] (rev 43)
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h Processor Function 1 [1022:1701]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h Processor Function 2 [1022:1702]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h Processor Function 3 [1022:1703]

Kernel driver in use: k10temp
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h Processor Function 4 [1022:1704]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h Processor Function 6 [1022:1718]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h Processor Function 5 [1022:1716]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
12h/14h 

Bug#759652: spamd doesn't restart after perl upgrade

[sacrificial-spam-address]

Package: spamassassin
Version: 3.4.0-2

When installing the recent Perl 5.20 upgrade, I noticed that
/etc/init.d/spamassassin wasn't restarting spamd.  Even though the
$PIDFILE was correct.

This is because the interpreter was no longer named /usr/bin/perl, and
so the --exec $XNAME condition refused to believe it, did not stop
the daemon, and the new one couldn't start because the socket was in use.

The is really something of a more general problem with start-stop-daemon
and maybe this bug should be reassigned to dpkg, but I encountered it
with spamd and I'll let you decide.

In my particular case, prelink also had a hand in the situation, so it's
not just package upgrades that can trigger it:

lrwxrwxrwx  1 root root 0 Aug  6 10:34 exe - /usr/bin/perl.#prelink#.WTKInn 
(deleted)


To reproduce:

# cp -a /usr/bin/perl{,2}
# mv /usr/bin/perl{2,}
# /etc/init.d/spamassassin restart

Thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759651: file says /usr/sbin/spamd: awk script, ASCII text

[sacrificial-spam-address]

Package: file
Version: 1:5.19-1
Architecture: i386

The script from spamassassin_3.4.0-2 starts with:
 #!/usr/bin/perl -T -w
 
 eval 'exec /usr/bin/perl -T -w -S $0 ${1+$@}'
 if 0; # not running under some shell

I'm not sure how that gets mistaken for an awk script

Thanks for the utility and its packaging!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758396: [PATCH] /etc/init.dudev start fails if CONFIG_UDEV_HELPER=n

[sacrificial-spam-address]

Package: udev
Version: 208-7
Severity: important

After upgrading to a 3.16 kernel, I noticed X wasn't detecting mouse
and keyboard any more.

After way more wild goose chasing than you want to hear about, this
turned out to be due to /dev/input/event* not being created, which was
due to devtmpfs not being mounted on /dev.

I had enough devices there to manage a normal-looking boot, but
X's AutoAddDevices wasn't working.

Anyway, this was due to my disabling the new 3.16 config option
CONFIG_UEVENT_HELPER, as the kernel documentation said it was obsolete
and I don't even have an /sbin/hotplug binary.

But!  Line 176 of /etc/init.d/udev contains the command:

echo  /sys/kernel/uevent_helper

which is supposed to disable that helper.  But if the file doesn't exist,
the fact that we're running with -e (errors are fatal) means that the
script aborts and most of the udev startup doesn't happen.

I fixed it with
--- udev.dpkg-dist  2014-08-17 04:28:56.570734578 +
+++ udev2014-08-17 04:23:00.298853946 +
@@ -173,7 +173,7 @@
warn_if_interactive
 fi
 
-echo  /sys/kernel/uevent_helper
+!  /sys/kernel/uevent_helper
 
 move_udev_database
 
... but alternatives that don't depend on /sys/kernel being unwriteable
by root are possible, like

+test -f /sys/kernel/uevent_helper   /sys/kernel/uevent_helper

(Redirect with no command produces a 0-byte O_TRUNC write, which is
just as good as the single newline that echo produces.  And prepending
! to invert the return code also disables errexit for that command.)

Of course, after fixing this, I first tried /etc/init.d/udev restart,
and when that didn't do enough work, tried /etc/init.d/udev stop;
/etc/init.d udev start but then had to find mountdevsubfs.sh to get
/dev/pts back.

Anyway, the whole thing is working now.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757462: vlc burls CPU when paused

[sacrificial-spam-address]

Package: vlc
Version: 2.1.5-1
Architecture: i386
Severity: wishlist

To reproduce:
1. Play any video in vlc
2. Pause playback
3. (optional) iconify VLC
4. strace -f -p `pgrep -x vlc`

Expected: Process blocked waiting for messages from X server.
(Similar to what happens when vlc is stopped.)
Observed: Huge amounts of activity.

To minimize laptop power, it really would be nice if VLC sould
avoid unnecessary wakeups.  It's only 0.3% CPU, but it burns battery
power.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757463: vlc unblanks X screen when paused

[sacrificial-spam-address]

Package: vlc
Version: 2.1.5-1
Architecture: i386

To reproduce:
1. Play any video in vlc
2. Pause playback
3. (optional) iconify VLC
4. xset dpms force off
5. Wait about 30 seconds

Expected: Screen stays off indefinitely
Observed: Screen unblanks in less than a minute

If VLC is not running, or is stopped, this doesn't happen.

(I know that VLC causes this and other X applications I have tested
do not, but it's possible it's am X server bug in response to some
message that's not supposed to unblank the screen.)

Given that xset dpms force off is essentially what the default
laptop lid-close  script does, the fact that the backlight comes back
on is rather annoying.  It achieves nothing but draining the
battery and wearing out the backlight,

This is an up-to-date Debian unstable i386 machine, using Intel
945 integrated graphics with the xserver-xorg-video-intel driver.

This might be related to my earlier bug about vlc keeping busy during
pause, but I'm not sure so I'm submitting them as two spearate issues.

Thank you very much!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751134: That should be Breaks: libtirpc1 ( 0.2.3)

[sacrificial-spam-address]

The fix was committed in version 0.2.3; version 2.3 is a long long
way in the future.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747349: postfix-policyd-spf-python freezes with some DNS servers

[spam]

# dpkg -l | grep python-dns
ii  python-dns2.3.6-1+deb7u1
all  DNS client module for Python


I've checked /usr/lib/python2.7/dist-packages/DNS/Base.py and patch for 
that earlier DNS bug (#718547) is applied.


Regards,
Zielony


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747349: postfix-policyd-spf-python freezes with some DNS servers

[spam]

W dniu 2014-05-07 21:03, Scott Kitterman napisał(a):

On Wednesday, May 07, 2014 20:25:58 s...@spam.charonski.pl wrote:

# dpkg -l | grep python-dns
ii  python-dns2.3.6-1+deb7u1
all  DNS client module for Python

I've checked /usr/lib/python2.7/dist-packages/DNS/Base.py and patch 
for

that earlier DNS bug (#718547) is applied.


I did investigate this and found that the default timeouts in 
python-spf and

python-dns are rather long.  With a series of non-responsive DNS
servers as in
the bug, it can take a very long time to get a result, but one does 
return.


I agree it's a bug, but not a grave one.  Python-spf 2.0.9 that's in 
jessie
will default to a shorter period.  I do plan to backport that, which 
will
help.  I will also, in a future release, add a configuration option 
of the

policy server so you can adjust the timeout.

Scott K


The problem may not be timeouts, but some bug by which python-dns can't 
resolve correctly got DNS answer. The servers, I attached, work (at last 
checking with dig/host). Maybe some DNS record needed by SPF is filtered 
by them and it's the cause? I think it freezes, because DNS server 
returns some incomplete answer and python-dns can't handle it and wait 
on timeout, but I didn't check it with any sniffer.


However, shorter timeouts should be good workaround.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739595: mcelog 100-1 does not recognize AMD CPUs properly

[sacrificial-spam-address]

Package: mcelog
Version: 100-1
Architecture: i386
Severity: important

I think this is what caused #738927 to be noticed, but this is a separate issue.

# strace -efile,read,ioctl,exit_group mcelog 
execve(/usr/sbin/mcelog, [mcelog], [/* 15 vars */]) = 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\213^B4\0\0\0..., 
512) = 512
open(/etc/mcelog/mcelog.conf, O_RDONLY) = 3
read(3, #\n# Example config file for mcel..., 4096) = 4096
read(3, the hardware does not report DIM..., 4096) = 1966
read(3, , 4096)   = 0
open(/proc/cpuinfo, O_RDONLY) = 3
read(3, processor\t: 0\nvendor_id\t: Authen..., 1024) = 1024
mcelog: AMD Processor family 16: Please load edac_mce_amd module.
: Success
CPU is unsupported
exit_group(1)   = ?

The error message appears to be bogus for three separate reasons:
1) The module is named amd64_edac_mod.ko
2) I have CONFIG_EDAC_AMD64=y, so don't need the module
3) It prints the error before doing anything that could theoretically
   detect the presence of such a module in the kernel, so loading
   the module wouldn't helo.

For comparison, specifying the CPU results in normal operation:
# strace -efile,read,ioctl,exit_group mcelog --cpu k8
execve(/usr/sbin/mcelog, [mcelog, --cpu, k8], [/* 15 vars */]) = 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\213^B4\0\0\0..., 
512) = 512
open(/etc/mcelog/mcelog.conf, O_RDONLY) = 3
read(3, #\n# Example config file for mcel..., 4096) = 4096
read(3, the hardware does not report DIM..., 4096) = 1966
read(3, , 4096)   = 0
open(/dev/mem, O_RDONLY)  = 3
open(/sys/firmware/efi/systab, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/proc/efi/systab, O_RDONLY)  = -1 ENOENT (No such file or directory)
access(/etc/mcelog, R_OK|X_OK)= 0
access(/etc/mcelog/cache-error-trigger, R_OK|X_OK) = 0
open(/dev/mcelog, O_RDONLY)   = 3
ioctl(3, MCE_GET_RECORD_LEN or MTRRIOC_SET_ENTRY, 0xfff90ca8) = 0
ioctl(3, MCE_GET_LOG_LEN or MTRRIOC_DEL_ENTRY, 0xfff90ca4) = 0
read(3, , 2816)   = 0
exit_group(0)   = ?

FWIW, here's 1/4 of my /proc/cpuinfo:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 2
model name  : AMD Phenom(tm) 9850 Quad-Core Processor
stepping: 3
microcode   : 0x183
cpu MHz : 2500.164
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni 
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs hw_pstate npt lbrv svm_lock
bogomips: 5002.67
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722604: Workaround patch

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722604: Workaround patch

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722604: I also had a non-booting machine...

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722604: Workaround patch

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722604: Workaround patch

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#721589: realloc error during make test with perl 5.18

[sacrificial-spam-address]

Package: pdl
Version: 1:2.4.11-4
Architecture: i386

I'm trying to recompile pdl with perl 5.18, and it's failing in the
make test phase with:

 cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
 -Werror=format-security -Wall -ffunction-sections -Wl,-z,relro 
 -Wl,--as-needed -o blib/bin/pdl pdl.o
 make[1]: Leaving directory `/tmp/pdl-2.4.11'
 mkdir -p blib/lib/PDL/Config
 perl -Mblib debian/write_config_debian.pl  blib/lib/PDL/Config/Debian.pm
 pod2man debian/dh_pdl  debian/dh_pdl.1
 touch build-stamp
  fakeroot debian/rules binary
 dh_testdir
 BEGIN test normal
 /usr/bin/make TEST_VERBOSE=0 LC_ALL=C test | perl debian/filter-test.pl
 *** Error in `/usr/bin/perl': realloc(): invalid next size: 0x0a30f950 ***

Interestingly, things hang there rather than exiting.

I'm not qure quite what the problem is, but it's very reproducible for me
(only the hex next size value varies), and I notice the debian autobuilder
has similar errors on i386.


Here's two unfiltered test logs (boring leading parts snipped).  The second
includes a hopefully-useful backtrace.

PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(1, 
'blib/lib', 'blib/arch') t/*.t
t/aaa_load.t  
1..1
ok 1
ok
t/argtest.t . 
1..3
EXPECT ERROR NEXT:
-
Error - tried to use an unknown data structure as a PDL at (eval 23) line 1.
-
ok 1
EXPECT ERROR NEXT:
-
Hash given as a pdl - but not {PDL} key! at t/argtest.t line 37.
-
ok 2
EXPECT ERROR NEXT:
-
Error - tried to use an unknown data structure as a PDL at t/argtest.t line 44.
-
ok 3
ok
t/autoload.t  
1..3
ok 1 - use PDL::AutoLoader;
*** Error in `/usr/bin/perl': realloc(): invalid next size: 0x08e77090 ***
Dims: 2,2 DLen: 32
^Cmake: *** [test_dynamic] Interrupt



PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(1, 
'blib/lib', 'blib/arch') t/*.t
t/aaa_load.t  
1..1
ok 1
ok
t/argtest.t . 
1..3
EXPECT ERROR NEXT:
-
Error - tried to use an unknown data structure as a PDL at (eval 23) line 1.
-
ok 1
EXPECT ERROR NEXT:
-
Hash given as a pdl - but not {PDL} key! at t/argtest.t line 37.
-
ok 2
EXPECT ERROR NEXT:
-
Error - tried to use an unknown data structure as a PDL at t/argtest.t line 44.
-
ok 3
ok
t/autoload.t  
1..3
*** Error in `/usr/bin/perl': double free or corruption (out): 0x09287190 ***
ok 1 - use PDL::AutoLoader;
Dims: 2,2 DLen: 32
=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6[0x4e42]
/lib/i386-linux-gnu/i686/cmov/libc.so.6[0x42223b80]
/tmp/pdl-2.4.11/blib/arch/auto/PDL/Core/Core.so(pdl_freethreadloop+0x2f)[0xf76a199f]
/tmp/pdl-2.4.11/blib/arch/auto/PDL/Ops/Ops.so(pdl_plus_free+0x2e)[0xf7673eae]
/tmp/pdl-2.4.11/blib/arch/auto/PDL/Core/Core.so(pdl_destroytransform_nonmutual+0x78)[0xf76a00d8]
/tmp/pdl-2.4.11/blib/arch/auto/PDL/Core/Core.so(pdl_make_trans_mutual+0x248)[0xf76a0dd8]
/tmp/pdl-2.4.11/blib/arch/auto/PDL/Ops/Ops.so(+0x4d499)[0xf7673499]
/usr/bin/perl(Perl_pp_entersub+0x4a6)[0x80f4a86]
/usr/bin/perl(Perl_amagic_call+0x45a)[0x808662a]
/usr/bin/perl(Perl_try_amagic_bin+0x76)[0x8087886]
/usr/bin/perl(Perl_pp_add+0x178)[0x80eebd8]
/usr/bin/perl(Perl_runops_standard+0x18)[0x80ecf48]
/usr/bin/perl(perl_run+0x3db)[0x808056b]
/usr/bin/perl(main+0x13f)[0x805ed6f]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf5)[0x421c68c5]
/usr/bin/perl[0x805eda1]
=== Memory map: 
08048000-081c1000 r-xp  09:01 10585194   
/usr/bin/perl
081c1000-081c2000 r--p 00179000 09:01 10585194   
/usr/bin/perl
081c2000-081c5000 rw-p 0017a000 09:01 10585194   
/usr/bin/perl
09147000-0969c000 rw-p  00:00 0  [heap]
4218a000-421a9000 r-xp  09:01 10436637   
/lib/i386-linux-gnu/ld-2.17.so
421a9000-421aa000 r--p 0001f000 09:01 10436637   
/lib/i386-linux-gnu/ld-2.17.so
421aa000-421ab000 rw-p 0002 09:01 10436637   
/lib/i386-linux-gnu/ld-2.17.so
421ad000-42356000 r-xp  09:01 10436922   
/lib/i386-linux-gnu/i686/cmov/libc-2.17.so
42356000-42358000 r--p 001a9000 09:01 10436922   
/lib/i386-linux-gnu/i686/cmov/libc-2.17.so
42358000-42359000 rw-p 001ab000 09:01 10436922   
/lib/i386-linux-gnu/i686/cmov/libc-2.17.so
42359000-4235c000 rw-p  00:00 0 
4235e000-42361000 r-xp  09:01 10436982   
/lib/i386-linux-gnu/i686/cmov/libdl-2.17.so
42361000-42362000 r--p 2000 09:01 10436982   
/lib/i386-linux-gnu/i686/cmov/libdl-2.17.so
42362000-42363000 rw-p 3000 09:01 10436982   
/lib/i386-linux-gnu/i686/cmov/libdl-2.17.so
42365000-423a6000 r-xp  09:01 10437166   

Bug#717891: Apt 0.9.9.3 + Acquire::http::Proxy = 400 Bad Request

[sacrificial-spam-address]

Thanks for the rapid feedback!  Unless you specifically want me to test
the patch (seems unnecessary, given how easy it is to reproduce), I'll
just wait for 0.9.9.4 to show up.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#717891: Apt 0.9.9.3 + Acquire::http::Proxy = 400 Bad Request

[sacrificial-spam-address]

Package: apt
Version: 0.9.9.3
Architecture: i386
Severity: important

When proxying through a squid3 cache, an attempt to apt-get update
fails with all errors.

The old apt package, which worked, sent the following request
to the proxy:

GET http://http.us.debian.org/debian/dists/unstable/InRelease HTTP/1.1
Host: http.us.debian.org
Cache-Control: max-age=0
Accept: text/*
If-Modified-Since: Fri, 26 Jul 2013 02:41:21 GMT
User-Agent: Debian APT-HTTP/1.3 (0.9.9.2)

The new one sends the following, which omits the protocol and host
prefix fron the GET line, making it not a proper proxy request:

GET /debian/dists/unstable/InRelease HTTP/1.1
Host: http.us.debian.org
Cache-Control: max-age=0
Accept: text/*
If-Modified-Since: Fri, 26 Jul 2013 02:41:21 GMT
User-Agent: Debian APT-HTTP/1.3 (0.9.9.3)

This causes squid3 to complain

HTTP/1.1 400 Bad Request
Server: squid/3.3.8
Mime-Version: 1.0
Date: Fri, 26 Jul 2013 05:32:43 GMT
Content-Type: text/html
Content-Length: 3232
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from ...

I have specifically verified that it's the apt_0.9.9.3_i386.deb package
which does this; libapt-inst1.5, libapt-pkg4.12, apt-utils and apt-doc
can be either 0.9.9.2 or 0.9.9.3 without affecting the results.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#591526: fixed in units 2.01-1

[sacrificial-spam-address]

Thanks for this!

Of course, since this report, the 2010 CODATA values came out, and while
the ones I reported have been updated, there are still some discrepancies.


Units DB2010 CODATA value

planckmass  2.17644e-8 kg   2.17651(13)
http://physics.nist.gov/cgi-bin/cuu/Value?plkm
K_J 483597.870 GHz/V483597.9 (exact)
http://physics.nist.gov/cgi-bin/cuu/Value?kj90
R_K 25812.8074434 ohm   25812.807 (exact)
http://physics.nist.gov/cgi-bin/cuu/Value?rk90
Rinfinity   10973731.568527 /m  10973731.568539(55)
http://physics.nist.gov/cgi-bin/cuu/Value?ryd

These values are the 1990 conventional values; thus the comment is currently
wrong, but will be correct when they are corrected.

The comment on Rinfinity (saying that it is known much less well than R_H)
seems incorrect, too.


Is this a new bug, or an incomplete fix of the existing one?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713836: regcomp(3) writes past end of regex_t

[sacrificial-spam-address]

 I am personally not able to to reproduce the issue with your test
 program on an up to date i386 sid system. Could you please provide us
 the command you are using to compile the test code and the locale you
 are using?

Very interesting!  I'm also using an up-to-date sid system.
No locale is set.

I had been holding off on upgrading other machines to 2.17-6 because
of this, but I just went and upgraded one and it also does
not show the problem.  WTF?  The one major difference is that it's 
running a 32-bit kernel as opposed to a 64-bit one.

Anyway, here's some hopefully useful information (blank lines added
for readability)

Script started on Thu Jun 27 01:13:16 2013
[500]$ gcc -v bug.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.8/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-4' 
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.8 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586 
--with-multili
 b-list=m32,m64,mx32 --with-tune=generic --enable-checking=release 
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.8.1 (Debian 4.8.1-4) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i586'
 /usr/lib/gcc/i486-linux-gnu/4.8/cc1 -quiet -v -imultilib . -imultiarch 
i386-linux-gnu bug.c -quiet -dumpbase bug.c -mtune=generic -march=i586 -auxbase 
bug -version -o /tmp/ccnfNMA2.s
GNU C (Debian 4.8.1-4) version 4.8.1 (i486-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/i386-linux-gnu
ignoring nonexistent directory 
/usr/lib/gcc/i486-linux-gnu/4.8/../../../../i486-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/lib/gcc/i486-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.8/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
GNU C (Debian 4.8.1-4) version 4.8.1 (i486-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b99bb83419f5bdeabc03ef14532498a2
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i586'
 as -v --32 -o /tmp/ccOPAAts.o /tmp/ccnfNMA2.s
GNU assembler version 2.23.52 (i486-linux-gnu) using BFD version (GNU Binutils 
for Debian) 2.23.52.20130620
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.8/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i586'
 /usr/lib/gcc/i486-linux-gnu/4.8/collect2 --sysroot=/ --build-id --eh-frame-hdr 
-m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 
/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crt1.o 
/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crti.o 
/usr/lib/gcc/i486-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.8 
-L/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu 
-L/usr/lib/gcc/i486-linux-gnu/4.8/../../../../lib -L/lib/i386-linux-gnu 
-L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/i486-linux-gnu/4.8/../../.. /tmp/ccOPAAts.o -lgcc --as-needed 
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc/i486-linux-gnu/4.8/crtend.o 
/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o
[501]$ ./a.out
array[1] confirmed all-zero
J'accuse!  buf[0] = 0x18
Bug!  array[1] has been overwritten!

[502]$ gcc -O bug.c
[503]$ ./a.out
array[1] confirmed all-zero
J'accuse!  buf[0] = 0x18
Bug!  array[1] has been overwritten!

[504]$ gcc -O2 bug.c
[505]$ ./a.out
array[1] confirmed 

Bug#713836: regcomp(3) writes past end of regex_t

[sacrificial-spam-address]

Okay, I did a bit of comparison.  The machine the binary was *compiled*
on seemed to matter, not the one it was *run* on.  A bit of extra
printing revealed the obvious culprit:

[539]$ ./a.out
sizeof regex_t = 28
array[1] confirmed all-zero
J'accuse!  buf[0] = 0x18
Bug!  array[1] has been overwritten!

[524]$ ./a.out
sizeof regex_t = 32
array[1] confirmed all-zero
array[1] confirmed all-zero

It's obviously a header file issue.  I will go investigate.
The /usr/include/regex.h files are identical between the machines,
it must be something else...

Aha!  Where did /usr/local/include/sys/types.h come from?  It's
been there since 2007 and never caused a problem until now...

Anyway, the difference seems to boil down to the following gcc -E difference:
(- = buggy, + = works)

   unsigned char *__buffer;
 
 
   unsigned long int __allocated;
 
 
-  unsigned long int __attribute__((__used__));
+  unsigned long int __used;
 
 
   reg_syntax_t __syntax;

Sorry to jump to conclusions and blame you.  Thanks for trying to
reproduce and putting me on the right track!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713836: regcomp(3) writes past end of regex_t

[sacrificial-spam-address]

Package: libc6
Version: 2.17-6
Architecture: i386
Severity: important

This problem cropped up while compiling the kernel; it breaks
arch/x86/tools/relocs.c.  I've tracked it down and reduced
it to a small test case.

With the given arguments, regcomp() corrupts the byte past the end of
its supplied regex_t buffer.  This obviously can cause any manner of
undesired program behavior.

Note that this is 32-bit i386, not 64-bit.

Here's a simple test program:

#include regex.h
#include stdio.h
#include stdbool.h

regex_t array[2];

static bool
is_zero(void const *p, size_t len)
{
size_t i;
unsigned char const *pp = p;
bool rv = true;

for (i = 0; i  len; i++) {
if (pp[i]) {
printf(J'accuse!  buf[%zu] = %#x\n,
i, pp[i]);
rv = false;
}
}
return rv;
}

int
main(void)
{
if (is_zero(array+1, sizeof array[1]))
printf(array[1] confirmed all-zero\n);
regcomp(array+0, ^pa_, REG_EXTENDED|REG_NOSUB);
if (is_zero(array+1, sizeof array[1]))
printf(array[1] confirmed all-zero\n);
else
printf(Bug!  array[1] has been overwritten!\n);
return 0;
}

And here's what running it produces:
$ ./a.out
array[1] confirmed all-zero
J'accuse!  buf[0] = 0x18
Bug!  array[1] has been overwritten!
$ ldd ./a.out
linux-gate.so.1 (0xf7784000)
libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf75ea000)
/lib/ld-linux.so.2 (0xf7785000)

(The fact that the libc6-i686 libraries, which I have installed, are
not being used is due libc6-i686 postinst not handling multiarch; I'll
report that separately.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713837: libc6-i686 postinst fails to parse dpkg-query output

[sacrificial-spam-address]

Package: libc6-i686
Version: 2.17-6
Architecture: i386
Severity: important

With dpkg 1.16.10, the output for dpkg-query -l libc6-i686 is

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
 Architecture Description
+++--===--
ii  libc6-i686:i386  2.17-6 
 i386 Embedded GNU C Library: Shared libraries [i686 optimized]

The libc6-i686 postinst doesn't like the :i386 suffix, sets
$all_upgraded to no, and leaves /etc/ld.so.nohwcap in place.
Although this doesn't break anything else, it renders the package useless.

Thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713837: libc6-i686 postinst fails to parse dpkg-query output

[sacrificial-spam-address]

 It does break stuff. The nvidia driver for example -- it loads
 /usr/lib/i386-linux-gnu/libnvidia-tls.so.319.23 instead of
 /usr/lib/i386-linux-gnu/tls/libnvidia-tls.so.319.23, and the non-tls library
 writes to %gs and segfaults when starting X, making the system very much
 unusable.

Ah, I wasn't aware that there was any difference but efficiency.
Thanks for spotting that!

It kind of calls into question the entire /etc/ld.so.nohwcap mechanism
for temporarily disabling access to the optimized libraries on upgrade.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#712657: An alternative solution

[sacrificial-spam-address]

Pehaps a better solution would be to update the symlink resolution code
at the top of sh.vim (line 30 et seq.) to know about dash.

That seems like it would have a better chance of being accepted upstream.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713922: sh.vim is confused by $(cmd --)

[sacrificial-spam-address]

Package: vim-runtime
Version: 2:7.3.923-2

I ran into this on line 289 of /var/lib/dpkg/info/libc6:i386.preinst:
if [ ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} = armhf ]; 
then

All lines after this have the syntax messed up, apparently due to losing
track of the double-quote state.

Although $() is involved, this is not Bug#712657, because I have b:is_bash
set, and $() is recognized in other contexts.

The key thing appears to be the -- in the subcommand.
I can reduce it to:

#!/bin/bash
echo $(foo --) this should be purple
: and this line should not

But the quotes, the $(), and the -- all appear to be necessary.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713836: A workaround for the kernel compile

[sacrificial-spam-address]

If you need to get a kernel compiling in the meantime, the
following small kernel patch works around the buffer overrun.

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index f7bab68..9978f8b 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -99,7 +99,7 @@ static const char * const sym_regex_realmode[S_NSYMTYPES] = {
 
 static const char * const *sym_regex;
 
-static regex_t sym_regex_c[S_NSYMTYPES];
+static regex_t sym_regex_c[S_NSYMTYPES+1];
 static int is_reloc(enum symtype type, const char *sym_name)
 {
return sym_regex[type] 

Because the structures are initialized in increasing order, only the
last one's overrun steps on important data.  The +1 provides some
unused space for the bug to harmlessly corrupt.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709818: Error compiling lilo

[sacrificial-spam-address]

Package: cpp-4.8
Version: 4.8.0-7
Tags: patch
X-Debbugs-CC: ad_deb...@joonet.de

The lilo (1:23.2-4) build system does some moderately evil things with
the preprocessor.  src/Makefile does:

gcc -E -C -traditional -DLILO_ASM -o common.s common.h

Then as86 is run on first.s, which includes common.s.

The evil thing is that common.h includes asm code hidden from
C program inside C comments, while the C comment delimiters
(which as86 does not understand) are in turn hidden from as86.


Anyway, with current gcc and cpp, this fails somewhat
spectacularly due to the automatic inclusion of
/usr/include/stdc-predef.h (and /usr/include/bits/predefs.h).

With -C, the /* */ comments in those files appear in common.s,
without the special escaping that prevents as86 from choking
on them, and things go downhill from there.


Looking for the least intrusive workaround, my first thought was
just to strip out the comments from stdc-predef.h, but messing
with copyright notices is, well, messy.

However, I figured out that prefixing each /* with a # makes
a null directive, which is stiripped out by cpp, even in
-C mode.  The output includes some blank and linemarker lines,
but those are relatively harmess for non-C languages, and
can already be suppressed with -P.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708720: Bug #708720's fix breaks file-rc

[sacrificial-spam-address]

Package: debhelper
Version: 9.20130518
Severity: serious

Since this went in, packages are appearing which depend depend (via
${misc:Depends}) on sysv-rc (= 2.88dsf-24), which 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
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 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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709502: Debhelper 9.20130518 breaks file-rc

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705587: As of 3.8-rc2, kernel building requires bc(1)

[sacrificial-spam-address]

Package: kernel-package
Version: 12.036+nmu3
Tags: patch

As of commit 70730bca1331fc50c3caacaea00439de1325bd6e
(kernel: Replace timeconst.pl with a bc script)
Linux kernel building depends on bc(1).  Without it,
building fails with:

  CC  kernel/exit.o
  CC  kernel/itimer.o
  BC  kernel/timeconst.h
/bin/sh: bc: command not found
make[1]: *** [kernel/timeconst.h] Error 127
make: *** [kernel] Error 2

However, it is not a dependency of kernel-package,
resulting in a non-working make-kpkg if one should happen
to not have it installed.

The obvious fix is to make it a dependency.

Thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704193: guaranteed Segmentation fault

[sacrificial-spam-address]

Control: tags 704193 patch

 Does
 http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=4b7c8a448651fe96b72fd1e48fe0003778efe85a
 fix the issue for you? For your convenience I have generated test
 packages with this patch included and have uploaded these to
 http://people.debian.org/~ametzler/

Confirmed that your pathced package makes the segfault go away.
Switched back and forth to confirm that plain 4.5.11-1 degfaults,
+bugfix+1 does not.

Yay, thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704193: guaranteed Segmentation fault

[sacrificial-spam-address]

 is the su - nobody necessary or do you see this as regular user,
 too? 

Me, I see this as a regular user.

 The whole thing seems to depend on the specific
 /var/cache/locate/locatedb (please make backup copy), I cannot reproduce
 it here. - Does locate 4.4.2-5 work with this locate-db?

I tested with 4.4.2-5, 4.5.10-1 and 4.5.10-2.  None segfault.
Re-installing 4.5.11-1 produces a segfault.  (I ran these tests
as root for simplicity.)

Note that this is a locatedb rebuilt today, which is different
from the one when I first reported.  But I made a snapshot anyway.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704193: guaranteed Segmentation fault

[sacrificial-spam-address]

s Re-installing 4.5.11-1 produces a segfault.
 OK I'm glad you guys can reproduce it! I'll leave it in your hands.

Er... I'm just a second schlub who reported the same symptoms.
Even though the maintainer wrote to you, and not me, I figured
I'd volunteer the requested information.

But same symptom doesn't necessarily mean same problem.  It's
only likely.

You're still not off the hook.  Does 4.5.11-1 word for you?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704193: guaranteed Segmentation fault

[sacrificial-spam-address]

 You're still not off the hook.  Does 4.5.11-1 word for you?
 That's the version I reported.

Oops, my cut-and-paste error.  I meant 4.4.2-5.

 P.S., try strace on it. (Which is also broken for me due to
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702309 so I can't.)

Already done in my first bug report.  Also, that bug report says you
can downgrade to the unstable version (4.5.20-2.3) and it works fine.
That's the version I'm using.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704193: I also see this (i386)

[sacrificial-spam-address]

Control: found 704193 4.5.11-1
Architecture: i386

Here's an strace.  The segfault happens just AFTER locatedb is closed.
It also happns on a successful lookup.  I'm running i386 sid userland
on an x86_64 kernel.

execve(/usr/bin/locate, [locate, ], [/* 24 vars */]) = 0
brk(0)  = 0x84a9000
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf77cd000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=145521, ...}) = 0
mmap2(NULL, 145521, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf77a9000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\372\202M4\0\0\0..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1756536, ...}) = 0
mmap2(0x4d816000, 1764124, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x4d816000
mmap2(0x4d9bf000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a9) = 0x4d9bf000
mmap2(0x4d9c2000, 11036, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4d9c2000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf77a8000
set_thread_area({entry_number:-1 - 12, base_addr:0xf77a8900, limit:1048575, 
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, 
useable:1}) = 0
mprotect(0x805a000, 4096, PROT_READ)= 0
mprotect(0x4d9bf000, 8192, PROT_READ)   = 0
mprotect(0x4d812000, 4096, PROT_READ)   = 0
munmap(0xf77a9000, 145521)  = 0
open(/var/cache/locate/locatedb, O_RDONLY|O_LARGEFILE) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
geteuid32() = $UID
getuid32()  = $UID
getgid32()  = $GID
setgid32($GID)  = 0
brk(0)  = 0x84a9000
brk(0x84ca000)  = 0x84ca000
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=21917714, ...}) = 0
time(NULL)  = 1364566351
fcntl64(3, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=21917714, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf77cc000
_llseek(3, 0, [0], SEEK_CUR)= 0
read(3, ..., 4096) = 4096

(Lots of additional reads omitted)

read(3, , 4096)   = 0
close(3)= 0
munmap(0xf77cc000, 4096)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695285: /etc/cron.daily/apt backup RNG is very wasteful

[sacrificial-spam-address]

 Thanks for checking this. I like this, its more compact than the
 current code. However the reason why I did not use this, was that the
 following fragment:
 
 $ while true; do res=$(od -N2 -d /dev/urandom | cut -s -d' ' -f2); echo
 $res; if [ -z $res ]; then break;  fi ; done
 61581
 42056
 38021
 
 $ 
 
 give me a empty string in $res sometimes. I haven't really put any
 though into why this is, maybe just a side effect of running it in th
 while loop?

No, it's a side effect of od printing a decimal number which is sometimes less 
than 1 and so
is space-padded on the left.

Try:
while : ; do x=$(od -N2 -d /dev/urandom); y=$(echo $x | cut -s -d' ' -f2); 
echo $y; if test -z $y; then echo $x; break; fi; done

When it errors out, $x contains:
000  9611
002

Now is it clear?

Include *all* the fields other than 1 and it will never fail:

while :; do res=$(od -N2 -d /dev/urandom | cut -s -d' ' -f2-); echo $res; if [ 
-z $res ]; then break;  fi ; done

The other way is to use a number format that is zero-padded:
while :; do res=0x$(od -N2 -x /dev/urandom | cut -s -d' ' -f2-); echo $res; if 
[ -z $res ]; then break;  fi ; done


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695285: /etc/cron.daily/apt backup RNG is very wasteful

[sacrificial-spam-address]

 Thanks, I fixed this now in my bzr tree and it will be part of the
 next upload.

Er, assuming that's revision 2269:
http://anonscm.debian.org/loggerhead/apt/debian-sid/revision/2269/debian/apt.cron.daily

You don't need the final cut -c1-5.  It is true that cksum returns an
unsigned 32-bit number, and some shells only do 32-bit signed math, but
they simply convert the number to negative.

You either mask off the sign bit with
RANDOM=$(($(dd if=/dev/urandom bs=2 count=1 2 /dev/null | cksum | cut -d' ' 
-f1) % 0x7fff))

Or, of you want to emulate the range of Bash $RANDOM exactly:
RANDOM=$(($(dd if=/dev/urandom bs=2 count=1 2 /dev/null | cksum | cut -d' ' 
-f1) % 0x7fff))

The od -d -N2 -An solution works with a recent enough od.
I was looking to see how old that can be.  The uppercase option flags
are not in 7th edition, but are in POSIX.1 as of 2001:
http://www.unix.com/man-page/posix/0/od/
It also appears to be in xpg4:
http://docs.oracle.com/cd/E19963-01/html/821-1461/od-1.html
And in SunOD 5.8 (2000):
http://www.manpages.info/sunos/od.1.html
GNU textutils 2.0 (1999):
http://sunsite.ualberta.ca/Documentation/Gnu/textutils-2.0/man/od.1.html

Apparently the spec was in POSIX.1 as of 1992, alyhough not NetBSD
as of 2000:
http://gnats.netbsd.org/11204
It was added to NetBSD in 2008:
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/hexdump/od.1?rev=1.23content-type=text/x-cvsweb-markupf=Honly_with_tag=MAIN


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695285: /etc/cron.daily/apt backup RNG is very wasteful

[sacrificial-spam-address]

Package: apt
Version: 0.9.7.6
Severity: minor

/etc/cron.daily/apt does:
random_sleep()
{
RandomSleep=1800
eval $(apt-config shell RandomSleep APT::Periodic::RandomSleep)
if [ $RandomSleep -eq 0 ]; then
return
fi
if [ -z $RANDOM ] ; then
# A fix for shells that do not have this bash feature.
RANDOM=$(dd if=/dev/urandom count=1 2 /dev/null | cksum | cut -c1-5)
fi
TIME=$(($RANDOM % $RandomSleep))
debug_echo sleeping for $TIME seconds
sleep $TIME
}

This backup for a missing $RANDOM reads 512 bytes out of /dev/urandom, only
to reduce it (incorrectly) to a 5-digit number (16.6 bits max, although
the distribution is skewed), then to 10.8 bits (modulo 1800).

It's incorrect because cksum produces a 32-bit checksum, formatted as
%u, so some small fraction of the time (1 in 4.3 million times), it'll
be less than 1000 and the cut will produce a result of the form 123 4, 
causing the evaluation
of TIME to fail.

Two other options, which both use a lot less entropy and don't have the
bug, are:
RANDOM=$(dd if=/dev/urandom bs=2 count=1 2/dev/null | cksum | cut -d' 
' -f1)
RANDOM=$(od -N2 -d /dev/urandom | cut -s -d' ' -f2)

or, using more shell builtins:

read x RANDOM EOF
$(od -N2 -d /dev/urandom)
EOF

(The fact that you can't just pipe into read is a well-known sh problem.)


Also, you don't need to prefix variables with $ inside $(()); you can
use TIME=$((RANDOM % RandomSleep))


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694989: postgres ($pid): /proc/$pid/oom_adj is deprecated, please use /proc/$pid/oom_score_adj instead.

[sacrificial-spam-address]

Package: postgresql-9.2
Version: 9.2.1-1
Severity: minor

The above kernel complaint is generated when postgres starts up.
Presumably, it would be nice to shut it up.
(Kernel is 3.6.7, i686, FWIW.)

The PID does not correspond to any running process, but is in the range:

   PID TTY  STAT  TIME COMMAND
$pid-6 ?S 0:00 /usr/lib/postgresql/9.2/bin/postgres -D 
/var/lib/postgresql/9.2/main -c 
config_file=/etc/postgresql/9.2/main/postgresql.conf
$pid+3 ?Ss0:00  \_ postgres: checkpointer process   
   
$pid+4 ?Ss0:00  \_ postgres: writer process 
   
$pid+5 ?Ss0:00  \_ postgres: wal writer process 
   
$pid+6 ?Ss0:00  \_ postgres: autovacuum launcher process
   
$pid+7 ?Ss0:00  \_ postgres: stats collector process
   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#693670: Rebuilding against xfce4-panel 4.10 didn't seem to take...

[sacrificial-spam-address]

Package: orage
Version: 4.8.3-2
Architecture: i386

Despite the claims in the changelog:
 orage (4.8.3-3) experimental; urgency=low
 
   * Rebuild against xfce4-panel 4.10.
   * debian/control:
 - update standards version to 3.9.3.
 - update debhelper build-dep to 9.
 
  -- Yves-Alexis Perez cor...@debian.org  Mon, 17 Sep 2012 23:52:46 +0200

It's still
 Depends: [...] xfce4-panel (= 4.7.7), xfce4-panel ( 4.9)

I've been waiting for this, to allow me to install xfce 4.10, so thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691311: Upgrading liboctave1 confirmed to fix

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691311: error: feval: function `unimplemented' not found

[sacrifial-spam-address]

Package: octave
Version: 3.6.3-2
Architecture: i386

Upgrading from 3.6.2-5 is failing:

# dpkg --configure octave
Setting up octave (3.6.3-2) ...
error: feval: function `unimplemented' not found

dpkg: error processing octave (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for menu ...
Errors were encountered while processing:
 octave

This error seems to affect a lot:

# octave
GNU Octave, version 3.6.2
Copyright (C) 2012 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.

Octave was configured for i486-pc-linux-gnu.

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.

For information about changes from previous versions, type `news'.

octave:1 help
error: feval: function `unimplemented' not found
octave:1 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691047: gimp: Gimp steals focus, and migrates between desktops while opening files

[Send Spam here]

Hi

I am using Xfce.

BR
Lehel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#680749: Additional info

[Send Spam here]

After some digging I had to realize, that the thinkpad_acpi module is 
functioning well, the error is in XFCE-s display brightness setter.

This is a duplicate of:
https://bugzilla.xfce.org/show_bug.cgi?id=7541
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627336

Workaround solution:
http://www.n0nb.us/blog/2012/02/restoring-screen-brightness-step-size-on-xfce4/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#682689: closed by Hector Oron zu...@debian.org (Re: Bug#682689: buildcross fails to build gcc-4.7)

[sacrificial-spam-address]

Thank you!  I'm looking forward to trying it once it filters through the FTP 
servers.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#682689: buildcross fails to build gcc-4.7

[sacrificial-spam-address]

Package: buildcross
Version: 0.0.12

This is due to line 1095 of /usr/lib/buildcross/functions, which
defines the em_cross function:

case ${1} in
# (other cases omitted)
gcc-3.[3-4]|gcc-4.[0-6])
GCCVER=${1#gcc-}
myecho INFO I: Building GCC ${GCCVER}
checkinstalled gcc-${GCCVER}
install-gcc-build-deps ${GCCVER}
build-gcc ${GCCVER}  $LOGPATH/$HOSTARCH-$DEBARCH-$PKG.log 21
#install-gcc ${GCCVER}
;;

There is no obvious reason why this case couldn't be extended, and in
fact I have successfully built a gcc-4.7 package by doing so.

Another useful addition to this function would be a catch-all error
case, rather than failing silently.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#682104: control.m4 produces syntax error in control

[sacricifial-spam-address]

Package: src:gcc-4.7
Version: 4.7.1-5

I was trying to build a cross-compiler, and it kept failing because of
a syntax error in debian/control at line 41:

 Package: libgcc1-dbg-armel-cross
 Architecture: all
 Section: debug
 Priority: extra
 Depends: gcc-4.7-arm-linux-gnueabi-base (= ${gcc:Version}), 
 libgcc1-armel-cross (= ${gcc:EpochVersion}), ${misc:Depends}
 dnldnl
 Description: GCC support library (debug symbols)
  Debug symbols for the GCC support library.
  .
  This package contains files for armel architecture, for use in cross-compile
  environment.

Notice the dnldnl.  This is caused by the corresponding part of
debian/control.m4:

 Package: libgcc1-dbg`'LS
 Architecture: ifdef(`TARGET',`all',`any')
 Section: debug
 Priority: extra
 Depends: BASEDEP, libgcc1`'LS (= ${gcc:EpochVersion}), ${misc:Depends}
 ifdef(`TARGET',`dnl',`dnl
 ifdef(`MULTIARCH',`Multi-Arch: same
 ')dnl
 Provides: libgcc1-dbg-armel [armel], libgcc1-dbg-armhf [armhf]
 ')dnl
 Description: GCC support library (debug symbols)`'ifdef(`TARGET)',` 
 (TARGET)', `')
  Debug symbols for the GCC support library.
 ifdef(`TARGET', `dnl
  .
  This package contains files for TARGET architecture, for use in cross-compile
  environment.
 ')`'dnl

If TARGET is defined, then the part after Depends: turns into

ifdef(`target',`dnl')dnl

Which expands to

dnldnl

The solution is to EITHER delete the first quoted dnl, OR move the
final dnl inside the macro and closing quote.  Having them both there
causes problems.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#680749: 680749

[Send Spam here]

Additional info:
If brightness setting does not work at all (scenario where brightness was not 
set during text boot screen),  the values of /proc/acpi/ibm/brightness go from 
0 to 7 with an increment of one, without any effect on the actual brightness, 
which does not change. After reaching the value of 7 by pressing the brightness 
increase button again, and they they loop around again from 0 to 7, then it is 
not possible to do another loop. Stepping the brightness down displays the same 
behavior, 7..0,7..0 without any effect on actual brightness. Echoing a value 
into the control file does not have any effect on screen brightness either.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#641278: Still present in 9.1.4-2

[sacrificial-spam-address]

E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up postgresql-client-9.1 (9.1.4-2) ...
update-alternatives: error: alternative pg_basebackup.1.gz can't be slave of 
psql.1.gz: it is a slave of postmaster.1.gz
dpkg: error processing postgresql-client-9.1 (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of postgresql-9.1:
 postgresql-9.1 depends on postgresql-client-9.1; however:
  Package postgresql-client-9.1 is not configured yet.
dpkg: error processing postgresql-9.1 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of postgresql-contrib-9.1:
 postgresql-contrib-9.1 depends on postgresql-9.1 (= 9.1.4-2); however:
  Package postgresql-9.1 is not configured yet.
dpkg: error processing postgresql-contrib-9.1 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 postgresql-client-9.1
 postgresql-9.1
 postgresql-contrib-9.1

This is caused by having the 9.2 betas on the machine as well.  I thought
the idea was that it was possible to have both?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678145: FTBFS: ar: /usr/lib/liblapack_pic.a: No such file or directory

[sacrificial-spam-address]

Package: src:atlas
Version: 3.8.4-7
Architecture: i386

On an i386 system, trying fakeroot debian/rules custom as recommended
aborts with an error

ATLAS install complete.  Examine
ATLAS/bin/arch/INSTALL_LOG/SUMMARY.LOG for details.
cd lib/ ; /usr/bin/make atlas/libblas.a
make[4]: Entering directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
mkdir tmp
(cd tmp  ar x ../libatlas.a);
(cd tmp  ar x ../libptf77blas.a);
(cd tmp  ar x ../libptcblas.a);
ar r atlas/libblas.a tmp/*.o
ar: creating atlas/libblas.a
rm -rf tmp
make[4]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
cd lib/ ; /usr/bin/make atlas/liblapack.a
make[4]: Entering directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
mkdir tmp
(cd tmp  ar x /usr/lib/liblapack_pic.a);
ar: /usr/lib/liblapack_pic.a: No such file or directory
make[4]: *** [atlas/liblapack.a] Error 9
make[4]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
make[3]: *** [build] Error 2
make[3]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base'
make[1]: *** [build-arch-stamp] Error 2
make[1]: Leaving directory `/tmp/atlas-3.8.4'
make: *** [custom-stamp] Error 2

Adding a symlink to /usr/lib/lapack/liblapack_pic.a lets the build
continue, and it then dies with

ATLAS install complete.  Examine 
ATLAS/bin/arch/INSTALL_LOG/SUMMARY.LOG for details.
cd lib/ ; /usr/bin/make atlas/libblas.a
make[4]: Entering directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
mkdir tmp
mkdir: cannot create directory `tmp': File exists
make[4]: *** [atlas/libblas.a] Error 1
make[4]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
make[3]: *** [build] Error 2
make[3]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base'
make[1]: *** [build-arch-stamp] Error 2
make[1]: Leaving directory `/tmp/atlas-3.8.4'
make: *** [custom-stamp] Error 2

Deleting that directory then leads to

cd lib/ ; /usr/bin/make fullshared
make[4]: Entering directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
rm -f atlas/libblas.so.3.0 atlas/liblapack.so.3.0
/usr/bin/make atlas/libblas.so.3.0 atlas/liblapack.so.3.0
make[5]: Entering directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
ld -melf_i386 -shared -soname libblas.so.3 -o atlas/libblas.so.3.0 \
   --whole-archive atlas/libblas.a \
   --no-whole-archive -L/usr/lib/gcc/i486-linux-gnu/4.7/ -lgfortran 
-lgcc_s -lpthread -lm -lc
rm -f atlas/libblas.so.3
(cd atlas  ln -s libblas.so.3.0 libblas.so.3)
rm -f atlas/libblas.so
(cd atlas  ln -s libblas.so.3 libblas.so)
ld -melf_i386 -shared -soname liblapack.so.3 -o atlas/liblapack.so.3.0 \
   --whole-archive atlas/liblapack.a \
   --no-whole-archive -L . -lblas -L/usr/lib/gcc/i486-linux-gnu/4.7/ 
-lgfortran -lgcc_s -lpthread -lm -lc
ld: cannot find -lblas
make[5]: *** [atlas/liblapack.so.3.0] Error 1
make[5]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
make[4]: *** [fullshared] Error 2
make[4]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base/lib'
make[3]: *** [build] Error 2
make[3]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/tmp/atlas-3.8.4/build/atlas-base'
make[1]: *** [build-arch-stamp] Error 2
make[1]: Leaving directory `/tmp/atlas-3.8.4'
make: *** [custom-stamp] Error 2

-lblas is actually located in the atlas/ subdirectory, so the linker isn't
finding it.  Adding more symlinks and restarting the build finally
produces .deb files.

On AMD64, the build seems to work smoothly.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678145: FTBFS: ar: /usr/lib/liblapack_pic.a: No such file or directory

[sacrificial-spam-address]

 Is the liblapack-pic package installed on your system?

Yes.  But you may have your finger on the problem anyway.

||/ Name  Version Description
+++-=-===-=
un  liblapack-3.sonone  (no description available)
iU  liblapack-dev 3.4.1-3 Library of linear algebra routines 3 - static 
version
iU  liblapack-pic 3.4.1-3 Library of linear algebra routines 3 - static 
PIC version
un  liblapack.so.3none  (no description available)
un  liblapack.so.3gf  none  (no description available)
iU  liblapack33.4.1-3 Library of linear algebra routines 3 - shared 
version
un  liblapack3gf  none  (no description available)

Although I installed the packages, due to conflicts between
libatlas3gf-sse2 and libblas3 (which I was trying to resolve by installing
a customized libatlas3), the packages were not configured (and I haven't
fixed it yet, see above).

I assumed that these were files-only packages with no significant
postinst configuration, but looking at the scripts, there are some
alternatives that may have been missing.

I just did a dpkg --configure -a, removed the symlinks I added, and
the rebuild ran properly.

If so, apologies for the false alarm.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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?

[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-dist-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?

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675942: fq_codel support would be nice in advance of 3.5

[sacrificial-spam-address]

Package: iproute
Version: 20120521-2
Severity: wishlist

Some of us are *very* interested in playing with the new codel feature
in 3.5-rc1, and it would be convenient to have a tc command that includes
support.  (In experimental, presumably.)

The commits went in just a few days after the 3.4 snapshot, so just
grabbing another from git would do.

Of course, you can say that if I can build my own kernel, I can build
my own package, amd there's a lot of truth to that, but if there are
lot of people interested like I am, it would save us all work.

(Having done it, using git to merge the pkg-iproute and iproute2 trees
produces a lot of conflicts, which can fortunately all be resolved by
taking the iproute2 version; somehow pkg-iproute isn't recording merges
properly.  I would also suggest adding a few rules to .gitignore:

# Generated docs
doc/*.aux
doc/*.dvi
doc/*.html
doc/*.log
doc/*.ps
doc/*.toc
doc/*.txt

# Debian build generated files
debian/*.log
debian/*.substvars
debian/files
debian/iproute-dev/
debian/iproute-doc/
debian/iproute/
debian/tmp/

# vim files
.*.swp  )





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675942: closed by Andreas Henriksson andr...@fatal.se (Bug#675942: fixed in iproute 20120521-2+codel)

[sacrificial-spam-address]

Talk about service, thanks!  It's made its way through the
FTP servers and I have it installed.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673102: gdm3 greeter shows ALL users with non-/bin/false shells

[sacrificial-spam-address]

Package: gdm3
Version: 3.0.4-4
Severity:important
Architecture: i386

I'm tracking debian/unstable, and my computer was down for a week or so
with a bad power supply.  After bringing it up to date, I found a stupid
number of users listed in the gdm3 greeter.

Users like backup, Majordomo (ud 31), gnats (uid 41), etc.

This is, if I understand correctly, Not Supposed To Happen.

Changing shells to /bin/false makes users disappear from the list,
but /bin/symlink-to-bash does not.

System is 64-bit kernel, i386 userland, 16 GB RAM, i7-2700K processor,
3.3.0-rc5 kernel (upgrading soon), onboard (Intel HD 3000) graphics.

The bug might not be in the gdm3 binary proper, but rather one of the
support libraries, but I'm not up to figuring out what is going on.
gdm3 is ultimately responsible.


Attempts to specify only listed users in /etc/gdm3/daemon.comf,
section [greeter], using IncludeAll=false and Include=user,user2
did not work.  Nor did Exclude=majordomo.

Neither did equivalent edits to /usr/share/gdm/gdm.schemas.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#669330: Internal compiler error on i586

[sacrificial-spam-address]

Package: gcc-4.7
Architecture: i386
Version: 4.7.0-3

The compiler blows up on an Intel Pentium, because it uses cmove
internally.  (I.e. is compiled for i686+)

I realize running current Debian experimental packages on a Pentium
166 is perhaps more an exercise in retrocomputing than practicality,
but I thought it was supposed to work.  Certainly most other binaries do.

(Note that gcc-4.6_4.6.3-1 has the same problem which may be demonstrated
on a 0-byte null.c file.)

Running gcc normally reports illegal instruction and internal compiler
error; cc1 under the debugger makes it clearer:
(The Linux kernel source tree is v3.3.2, if it matters.)

Script started on Thu Apr 19 04:32:24 2012
[/usr/src/linux]$ gdb --args `cat /tmp/command`
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/lib/gcc/i486-linux-gnu/4.7/cc1...(no debugging 
symbols found)...done.
(gdb) run
Starting program: /usr/lib/gcc/i486-linux-gnu/4.7/cc1 -E -lang-asm -quiet 
-nostdinc -v -I /usr/src/linux/arch/x86/include -I arch/x86/include/generated 
-I include -imultiarch i386-linux-gnu -D __KERNEL__ -D __ASSEMBLY__ -D 
CONFIG_AS_CFI=1 -D CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SECTIONS=1 
-isystem /usr/lib/gcc/i486-linux-gnu/4.7/include -include 
/usr/src/linux/include/linux/kconfig.h arch/x86/kernel/entry_32.S -o 
/tmp/entry_32.s -m32 -mtune=generic -march=i586 -fno-directives-only
#include ... search starts here:
#include ... search starts here:
 /usr/src/linux/arch/x86/include
 arch/x86/include/generated
 include
 /usr/lib/gcc/i486-linux-gnu/4.7/include
End of search list.

Program received signal SIGILL, Illegal instruction.
0x088abfa7 in cpp_avoid_paste(cpp_reader*, cpp_token const*, cpp_token const*)
()
(gdb) disassemble
Dump of assembler code for function 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_:
   0x088abf80 +0: sub$0xc,%esp
   0x088abf83 +3: mov$0x35,%edx
   0x088abf88 +8: mov0x14(%esp),%ecx
   0x088abf8c +12:mov%ebx,(%esp)
   0x088abf8f +15:mov0x18(%esp),%ebx
   0x088abf93 +19:mov%edi,0x8(%esp)
   0x088abf97 +23:mov%esi,0x4(%esp)
   0x088abf9b +27:movzbl 0x4(%ecx),%eax
   0x088abf9f +31:testb  $0x10,0x6(%ecx)
   0x088abfa3 +35:movzbl 0x4(%ebx),%edi
= 0x088abfa7 +39:cmove  %eax,%edx
   0x088abfaa +42:movzwl 0x6(%ebx),%eax
   0x088abfae +46:test   $0x10,%al
   0x088abfb0 +48:jne0x88ac008 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_+136
   0x088abfb2 +50:and$0xff,%edi
   0x088abfb8 +56:mov%edi,%esi
   0x088abfba +58:test   $0x2,%al
   0x088abfbc +60:je 0x88abfe8 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_+104
   0x088abfbe +62:mov0x8aaf7dc(,%esi,4),%eax
   0x088abfc5 +69:movzbl (%eax),%esi
   0x088abfc8 +72:cmp$0x3d,%esi
   0x088abfcb +75:jne0x88abff8 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_+120
   0x088abfcd +77:cmp$0xd,%edx
   0x088abfd0 +80:mov$0x1,%eax
   0x088abfd5 +85:jg 0x88abff8 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_+120
   0x088abfd7 +87:mov(%esp),%ebx
   0x088abfda +90:mov0x4(%esp),%esi
   0x088abfde +94:mov0x8(%esp),%edi
   0x088abfe2 +98:add$0xc,%esp
   0x088abfe5 +101:   ret
   0x088abfe6 +102:   xchg   %ax,%ax
   0x088abfe8 +104:   mov0x8aaf5e0(,%esi,8),%eax
   0x088abfef +111:   test   %eax,%eax
   0x088abff1 +113:   je 0x88ac020 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_+160
   0x088abff3 +115:   mov$0x,%esi
   0x088abff8 +120:   cmp$0x3c,%edx
   0x088abffb +123:   jbe0x88ac018 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_+152
   0x088abffd +125:   xor%eax,%eax
   0x088abfff +127:   jmp0x88abfd7 
_Z15cpp_avoid_pasteP10cpp_readerPK9cpp_tokenS3_+87
   0x088ac001 +129:   lea0x0(%esi,%eiz,1),%esi
---Type return to continue, or q return to quit---q
Quit
(gdb) quit
A debugging session is active.

Inferior 1 [process 16796] will be killed.

Quit anyway? (y or n) y
[/usr/src/linux]$ exit

Script done on Thu Apr 19 04:38:54 2012



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668418: FTBFS on i386

[sacrificial-spam-address]

Package: samba
Version: 2:3.6.3-2

I disabled the office samba servers last night after hearing about
CVE-2012-1182 (Bug#668309), and I expected to see a fixed binary make
its way through security.debian.org sometime this morning.

But fixed binaries don't seem to be forthcoming, so I decided to build my own.
I used

$ wget 
https://www.samba.org/samba/ftp/patches/security/samba-3.6.3-CVE-2012-1182.patch
$ apt-get source samba
$ cd samba-3.6.3
$ QUILT_PATCHES=debian/patches quilt import ../samba-3.6.3-CVE-2012-1182.patch
$ QUILT_PATCHES=debian/patches quilt push
$ vi debian/changelog   # Add a local version 2:3.6.4-0
$ debuild -uc -us -b

Now, on an amd64 machine, this worked fine.

But on an i386 machine (64-bit kernel, but 32-bit userland), the build failed:

[... snip beginning ...]
Compiling printing/tests/vlp.c
printing/tests/vlp.c: In function 'set_printer_status':
printing/tests/vlp.c:114:6: warning: variable 'result' set but not used 
[-Wunused-but-set-variable]
Linking bin/vlp
make -f Makefile-smbtorture4 bin/smbtorture4
make[3]: Entering directory `$DIR/samba-3.6.3/source3'
Waf: Entering directory `$DIR/samba-3.6.3/bin'
input file '../heimdal/lib/wind/rfc3454.txt' could not be found 
('$DIR/samba-3.6.3/source4/heimdal_build')
Checking for program gcc or cc   : /usr/bin/gcc 
Checking for program cpp : /usr/bin/cpp 
Checking for program ar  : /usr/bin/ar 
Checking for program ranlib  : /usr/bin/ranlib 
Checking for gcc : ok  
Checking for program git : /usr/bin/git 
[...snippage...]
Checking linker accepts -Wl,-no-undefined   
: yes 
Checking linker accepts -Wl,--as-needed 
: yes 
Checking for -lc not needed 
: ok  
'configure' finished successfully (37.278s)
cd ..  WAF_MAKE=1 buildtools/bin/waf --targets=smbtorture
Waf: Entering directory `$DIR/samba-3.6.3/bin'
Waf: Leaving directory `$DIR/samba-3.6.3/bin'
input file '../heimdal/lib/wind/rfc3454.txt' could not be found 
('$DIR/samba-3.6.3/source4/heimdal_build')
make[3]: *** [bin/smbtorture4] Error 1
make[3]: Leaving directory `$DIR/samba-3.6.3/source3'
make[2]: *** [bin/smbtorture4] Error 2
make[2]: Leaving directory `$DIR/samba-3.6.3/source3'
dh_auto_build: make -j1 everything nsswitch returned exit code 2
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `$DIR/samba-3.6.3'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1350:
dpkg-buildpackage -rfakeroot -D -us -uc -b failed

Strange.  I searched through the bug report archives to find out why
that file wasn't included, and decided the easy workaround would be to
install it.  Easily enough done.  Then I try again:

[... snip beginning ...]
Compiling printing/tests/vlp.c
printing/tests/vlp.c: In function 'set_printer_status':
printing/tests/vlp.c:114:6: warning: variable 'result' set but not used 
[-Wunused-but-set-variable]
Linking bin/vlp
make -f Makefile-smbtorture4 bin/smbtorture4
make[3]: Entering directory `$DIR/samba-3.6.3/source3'
Waf: Entering directory `$DIR/samba-3.6.3/bin'
'reconfigure' finished successfully (2.879s)
cd ..  WAF_MAKE=1 buildtools/bin/waf --targets=smbtorture
Waf: Entering directory `$DIR/samba-3.6.3/bin'
[  69/2412] Generating VERSION
[2229/2412] Linking default/lib/tdb/pytdb.so
/usr/lib/gcc/i486-linux-gnu/4.7/../../../i386-linux-gnu/Scrt1.o(.text+0x28): 
error: undefined reference to 'main'
collect2: error: ld returned 1 exit status
Waf: Leaving directory `$DIR/samba-3.6.3/bin'
Build failed:  - task failed (err #1): 
{task: cc_link pytdb_1.o - pytdb.so}
make[3]: *** [bin/smbtorture4] Error 1
make[3]: Leaving directory `$DIR/samba-3.6.3/source3'
make[2]: *** [bin/smbtorture4] Error 2
make[2]: Leaving directory `$DIR/samba-3.6.3/source3'
dh_auto_build: make -j1 everything nsswitch returned exit code 2
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `$DIR/samba-3.6.3'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1350:
dpkg-buildpackage -rfakeroot -D -us -uc -b failed


This is getting annoying, and wading through three layers of build
system (debian/rules invokes a Makefile invokes waf) looks to be very
time-consuming.

I don't mean to delay the critical security fix in any way, but maybe
this could be looked at afterward.  It's preventing me from applying the
fix myself, which is preventing UPS labels from being printed, which is
causing problems.

(There are workarounds, such as connecting a printer via USB, but it's
all pretty annoying.)

Thank you!



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact 

Bug#663402: getkeycodes(1) misreports first non-identity-mapped key

[sacrificial-spam-address]

Package: console-tools
Version: 0.2.3dbs-70
Tags: patch

The bug is in debian/patches/260_kernel26fix.patch, in this hunk:

diff -ruN console-tools-0.2.3-old/kbdtools/dumpkeys.c 
console-tools-0.2.3/kbdtools/dumpkeys.c
--- console-tools-0.2.3-old/kbdtools/getkeycodes.c  2004-06-26 
11:53:20.0 +0100
+++ console-tools-0.2.3/kbdtools/getkeycodes.c  2004-06-26 11:53:20.0 
+0100
@@ -52,7 +74,7 @@
  printf(\ne0 %02x: , sc-128);
}
   
-  if (sc = 88) 
+  if (sc = sc0) 
{
  printf( %3d, sc);
  continue;

This prints the identity map for characters up to and includeing sc0.
However, sc0 is the first character for which the mapping is NOT
the identity.

The comparison should be  sc0.


Demonstration of bug:

I have scancode 29 (left control) remapped.  I don't *want* it remapped,
and figuring out who's remapping it is the bug I was working on when this
bug interfered, but that's a different story.  Anyway, getkeycodes starts
out saying that the identity map stops at 0x1c, but displays 0x1d - 29.

If I actually set that explicitly, then it announces an identity map up
to 0x53 - 83, but now displays 0x54 - 84, rather than - 203.

[503]# getkeycodes ; setkeycodes 1d 29 ; getkeycodes
Plain scancodes xx (hex) versus keycodes (dec)
for 1-28 (0x01-0x1c) scancode equals keycode

 0x18:   24  25  26  27  28  29  30  31
 0x20:   32  33  34  35  36  37  38  39
 0x28:   40  41  42  43  44  45  46  47
 0x30:   48  49  50  51  52  53  54  55
 0x38:   56  57  58  59  60  61  62  63
 0x40:   64  65  66  67  68  69  70  71
 0x48:   72  73  74  75  76  77  78  79
 0x50:   80  81  82  83 203   0  86  87
 0x58:   88 117   0   0  95 183 184 185
 0x60:0   0   0   0   0   0   0   0
 0x68:0   0   0   0   0   0   0   0
 0x70:   93   0   0  89   0   0  85  91
 0x78:   90  92   0  94   0 124 121   0

Escaped scancodes e0 xx (hex)

e0 00:0   0   0 148   0   0 167   0
e0 08:0   0 148   0 213   0 226   0
e0 10:  165   0   0   0 211   0   0   0
e0 18:  161 163   0   0  96  97   0   0
e0 20:  113 140 164 150 166   0 358   0
e0 28:0   0 255   0   0   0 114   0
e0 30:  115 138 172   0   0  98 255  99
e0 38:  100   0   0   0   0   0   0   0
e0 40:0   0   0   0   0 119 119 102
e0 48:  103 104   0 105 112 106 118 107
e0 50:  108 109 110 111   0   0   0   0
e0 58:0   0   0 125 126 127 116 142
e0 60:0   0   0 143   0 217 156 173
e0 68:  128 159 158 157 155 226   0 112
e0 70:0   0   0   0   0   0   0   0
e0 78:0   0   0   0   0   0   0   0
Plain scancodes xx (hex) versus keycodes (dec)
for 1-83 (0x01-0x53) scancode equals keycode

 0x50:   80  81  82  83  84   0  86  87
 0x58:   88 117   0   0  95 183 184 185
 0x60:0   0   0   0   0   0   0   0
 0x68:0   0   0   0   0   0   0   0
 0x70:   93   0   0  89   0   0  85  91
 0x78:   90  92   0  94   0 124 121   0

Escaped scancodes e0 xx (hex)

e0 00:0   0   0 148   0   0 167   0
e0 08:0   0 148   0 213   0 226   0
e0 10:  165   0   0   0 211   0   0   0
e0 18:  161 163   0   0  96  97   0   0
e0 20:  113 140 164 150 166   0 358   0
e0 28:0   0 255   0   0   0 114   0
e0 30:  115 138 172   0   0  98 255  99
e0 38:  100   0   0   0   0   0   0   0
e0 40:0   0   0   0   0 119 119 102
e0 48:  103 104   0 105 112 106 118 107
e0 50:  108 109 110 111   0   0   0   0
e0 58:0   0   0 125 126 127 116 142
e0 60:0   0   0 143   0 217 156 173
e0 68:  128 159 158 157 155 226   0 112
e0 70:0   0   0   0   0   0   0   0
e0 78:0   0   0   0   0   0   0   0



As a meta-question, I notice that console-tools has an impressive number
of very old bugs, some marked pending upload, and no release activity
or mainainer comments on oncoming bugs since February 2011.

Is there is fact an active maintainer?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572367: rtorrent: Unsnubbing doesn't seem to work

[sacrificial-spam-address]

 In case you're not following the upstream ticket:

I'm not; I don't even know where their bug tracker is.

 Would you be able to build libtorrent [1] and rtorrent [2] from source,
 in their latest revision from github, and see if the issue is still
 there?

Done.  Exact git commits are
libtorrent ff60f659e3270b995c1df7cec991aec43b62b29f
rtorrent   d25c4b25aec09d19ae10941f7e22b97b00a94bfc 

I've only let the connection sit choked for 5 minutes or so, but here:
  IP   UP DOWN   PEER   CT/RE/LO  QSDONE  REQ   
SNUB  FAILED
* 78.180.99.43 0.00.075.1   r /cn/ci  0/016 
 uTorrent 3.0.0.0
  203.161.79.192   0.00.0163.8  r /Cn/cn  0/0   100 
 uTorrent 1.8.5.0
  24.142.56.27 0.00.0163.8  r /Cn/cn  0/0   100 
 uTorrent 1.8.5.0
  68.60.53.4   0.00.0163.8  r /Cn/cn  0/0   100 
 uTorrent 1.8.5.0
  95.34.190.1850.00.0163.8  r /Cn/cn  0/0   100 
 uTorrent 3.1.2.0
  68.231.118.970.00.0163.8  r /cn/ci  0/0   100 
 uTorrent 3.0.0.0
  14.201.139.177   0.00.0163.8  r /Cn/cn  0/0   100 
 uTorrent 3.0.0.0
  71.127.1.172 0.00.00.0R /Cn/cn  0/098 
 uTorrent 3.1.2.0
  80.202.31.1470.00.00.0R /Cn/cn  0/0   100 
 uTorrent 2.2.0.0
  109.224.133.220  0.00.0163.8  r /Cn/cn  0/0   100 
 uTorrent 3.1.2.0
  68.114.141.450.00.0163.8  r /Cn/cn  0/0   100 
 uTorrent 1.8.2.0

That first peer was receiving data at a good clip before I briefly choked it 
with *.
If I kick, it'll reconnect in a few seconds and start downloading...

* 78.180.99.43 11.8   0.068.3   r /ci/ui  13/0   16 
 uTorrent 3.0.0.0



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#662112: keytouch-editor segfaults on receiving KEY_NUMERIC_1

[sacrificial-spam-address]

Package: keytouch-editor
Version: 1:3.2.0~beta-3
Architecture: i386

When I click new and press a remote control key mapped to
513  # KEY_NUMERIC_1
keytouch-editor segfaults.  Other keys I've tried, not in the
KEY_NUMERIC_x range, work as expected.

An strace log beginning at the read of the input device follows.

select(1024, [5], NULL, NULL, {0, 1000}) = 1 (in [5], left {0, 998})
read(5, 
-\2SO#H\1\0\4\0\4\0\r\0\0\0-\2SO%H\1\0\1\0\1\2\1\0\0\0-\2SO%H\1\0\0\0\0\0\0\0\0\0-\2SO(H\1\0\1\0\1\2\0\0\0\0-\2SO(H\1\0\0\0\0\0\0\0\0\0,
 1024) = 80
write(4, \1\0\0\0\0\0\0\0, 8) = 8
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{+\6\1\0, 4}, {NULL, 0}, {, 0}], 3) = 4
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recv(3, \1\2c\17\0\0\0\0\21\2\200\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, 
4096, 0) = 32
recv(3, 0x8aa4fa0, 4096, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
recv(3, 0x8aa4fa0, 4096, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{+\6\1\0, 4}, {NULL, 0}, {, 0}], 3) = 4
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recv(3, \1\2d\17\0\0\0\0\21\2\200\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, 
4096, 0) = 32
recv(3, 0x8aa4fa0, 4096, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
recv(3, 0x8aa4fa0, 4096, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
write(4, \1\0\0\0\0\0\0\0, 8) = 8
close(5)= 0
access(/usr/share/keytouch-editor/pixmaps/icon.png, F_OK) = 0
open(/usr/share/keytouch-editor/pixmaps/icon.png, O_RDONLY|O_LARGEFILE) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=4254, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf1e1a000
read(5, \211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0 \0\0\0 
\10\6\0\0\0szz\364\0\0\0\6bKGD\0\377\0\377\0\377\240\275\247\223\0\0\0\tpHYs\0\0\v\21\0\0\v\21\1\177d_\221\0\0\0\7tIME\7\324\f\31\22\24:Z\232xt\0\0\20+IDATx\1\1
 \20\337\357\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096
gettimeofday({1330840109, 104462}, NULL) = 0
gettimeofday({1330840109, 104548}, NULL) = 0
gettimeofday({1330840109, 104575}, NULL) = 0
gettimeofday({1330840109, 104598}, NULL) = 0
gettimeofday({1330840109, 104617}, NULL) = 0
gettimeofday({1330840109, 104635}, NULL) = 0
gettimeofday({1330840109, 104654}, NULL) = 0
gettimeofday({1330840109, 104671}, NULL) = 0
gettimeofday({1330840109, 104687}, NULL) = 0
gettimeofday({1330840109, 104712}, NULL) = 0
gettimeofday({1330840109, 104730}, NULL) = 0
gettimeofday({1330840109, 104748}, NULL) = 0
gettimeofday({1330840109, 104769}, NULL) = 0
gettimeofday({1330840109, 104786}, NULL) = 0
gettimeofday({1330840109, 104802}, NULL) = 0
gettimeofday({1330840109, 104819}, NULL) = 0
gettimeofday({1330840109, 104835}, NULL) = 0
gettimeofday({1330840109, 104851}, NULL) = 0
gettimeofday({1330840109, 104867}, NULL) = 0
gettimeofday({1330840109, 104884}, NULL) = 0
gettimeofday({1330840109, 104900}, NULL) = 0
gettimeofday({1330840109, 104916}, NULL) = 0
gettimeofday({1330840109, 104932}, NULL) = 0
gettimeofday({1330840109, 104948}, NULL) = 0
gettimeofday({1330840109, 104964}, NULL) = 0
gettimeofday({1330840109, 104980}, NULL) = 0
gettimeofday({1330840109, 104996}, NULL) = 0
gettimeofday({1330840109, 105012}, NULL) = 0
gettimeofday({1330840109, 105028}, NULL) = 0
gettimeofday({1330840109, 105044}, NULL) = 0
gettimeofday({1330840109, 105060}, NULL) = 0
gettimeofday({1330840109, 105076}, NULL) = 0
gettimeofday({1330840109, 105092}, NULL) = 0
gettimeofday({1330840109, 105108}, NULL) = 0
gettimeofday({1330840109, 105124}, NULL) = 0
gettimeofday({1330840109, 105140}, NULL) = 0
gettimeofday({1330840109, 105156}, NULL) = 0
gettimeofday({1330840109, 105172}, NULL) = 0
gettimeofday({1330840109, 105188}, NULL) = 0
gettimeofday({1330840109, 105204}, NULL) = 0
gettimeofday({1330840109, 105219}, NULL) = 0
gettimeofday({1330840109, 105235}, NULL) = 0
gettimeofday({1330840109, 105251}, NULL) = 0
gettimeofday({1330840109, 105267}, NULL) = 0
gettimeofday({1330840109, 105284}, NULL) = 0
gettimeofday({1330840109, 105300}, NULL) = 0
gettimeofday({1330840109, 105316}, NULL) = 0
gettimeofday({1330840109, 105332}, NULL) = 0
gettimeofday({1330840109, 105348}, NULL) = 0
gettimeofday({1330840109, 105364}, NULL) = 0
gettimeofday({1330840109, 105380}, NULL) = 0
gettimeofday({1330840109, 105396}, NULL) = 0
gettimeofday({1330840109, 105412}, NULL) = 0
gettimeofday({1330840109, 105428}, NULL) = 0
gettimeofday({1330840109, 105444}, NULL) = 0
gettimeofday({1330840109, 105460}, NULL) = 0
gettimeofday({1330840109, 105476}, NULL) = 0
gettimeofday({1330840109, 105492}, NULL) = 0
gettimeofday({1330840109, 105508}, NULL) = 0
gettimeofday({1330840109, 105523}, NULL) = 0
gettimeofday({1330840109, 105539}, NULL) = 0
gettimeofday({1330840109, 105556}, NULL) = 0
gettimeofday({1330840109, 

Bug#661265: munin-doc munin-node both contain /usr/share/man/man1/munin-run.1p.gz

[sacrificial-spam-address]

Package: munin-doc
Version: 1.999.4603-1

dpkg -i /var/cache/apt/archives/munin-doc_1.999.4603-1_all.deb
(Reading database ... 287067 files and directories currently installed.)
Unpacking munin-doc (from .../munin-doc_1.999.4603-1_all.deb) ...
dpkg: error processing /var/cache/apt/archives/munin-doc_1.999.4603-1_all.deb 
(--install):
 trying to overwrite '/usr/share/man/man1/munin-run.1p.gz', which is also in 
package munin-node 1.999.4603-1
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/munin-doc_1.999.4603-1_all.deb

Hopefully simple enough.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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)

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660029: Wrong dtd path validating XHTML 1.0 frameset web page.

[Anti Spam]

Package: w3c-dtd-xhtml
Version: 1.1-5


I think that this is a bug because transitional xhtml 1.0 pages are correctly 
validated.
I receive an error message validating a xhtml 1.0 FRAMESET web page. The same 
page is correctly validated with the online w3c validator.

The error message i receive is the following:

Sorry! This document can not be checked.
Fatal Error:  cannot find 
/usr/share/xml/shtml/schema/dtd/1.0/xhtml1-frameset.dtd; tried 
I could not parse this document, because it makes reference to a 
system-specific file instead of using a well-known public identifier to specify 
the type of markup being used.
You should place a DOCTYPE declaration as the very first thing in your HTML 
document. For example, for a typical XHTML 1.0 document: !DOCTYPE html PUBLIC 
-//W3C//DTD XHTML 1.0 Strict//EN 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html 
xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en head 
titleTitle/title /head body !-- ... body of document ... -- /body 
/html

The strange thing is that the path /usr/share/xml/shtml doesn't exist. I think 
that the correct one is /usr/share/xml/xhtml.
If  I duplicate the existing xhtml folder in shtml then i'm able to validate 
the page.


This is my web page:

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Frameset//EN 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=it lang=it
head
      meta name=DC.Title content=Il titolo/
      meta name=description content=La descrizione della pagina/
      meta name=keywords content= le parole chiave separate da virgole/
      meta http-equiv=Content-Type content=text/html; 
charset=windows-1252/
      titleNo Title/title
/head

frameset cols=170, *
  frame noresize=noresize frameborder=0 name=menu  id=menu 
src=menu.html /
  frame noresize=noresize frameborder=0 name=corpo id=corpo 
src=corpo.html /
noframes
body
      pSpiacente. Il tuo browser non supporta i frames/p
/body
/noframes
/frameset
/html


-- System Information:
Debian squeeze            6.0.4
Kernel  Linux             2.6.32-5-686
w3c-markup-validator      0.7.4-5.2
apache2                             2.2.16-6+squeeze6
Locale                           LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8

Versions of packages w3c-dtd-xhtml depends on:
ii  sgml-base 1.26+nmu1
ii  sgml-data 2.0.4
ii  xml-core  0.13 
-- no debconf information

Best regards
Iam.

Bug#658258: Cups 1.5.0-16 breaks plain text printing

[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

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649408: WARNING: gnome-keyring:: no socket to connect to breaks CUPS lpd support

[sacrificial-spam-address]

severity 649408 critical
affects 649408 cups

makes unrelated software on the system (or the whole system) break

I don't know what the HELL a gnome component has to do with Berkeley lpd
protocol support, but I just finished figuring out that not only does
this stupid warning message appear every time I ask lpq, but it confuses
cups-lpd to the point that it doesn't accept print jobs on port 515.

Which led to a print queue backlog I just finished debugging.

(Arguably, the dependency is a CUPS bug, and if you want to shout at
Apple for writing an overcomplicated impenetrable mess with inadequate
debugging support, I'll hand you the megaphone.  But still.)

Applying Karol Kozlpwski's workaround (editing
/etc/pkcs11/modules/gnome-keyring-module to comment out the line
module: gnome-keyring-pkcs11.so
makes printing start working again.
(CAUTION: You may NOT save a .dpkg-dist file in the same directory;
it will be read and parsed and lead to the same error.)


Actually, I found a better workaround: uninstall gnome-keyring!  It came
in via a Recommends: somehow, but libgnome-keyring0 sure doesn't need
it and nuking the entire package solves the problem very nicely, too.

/grouchy



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#653355: Preinst can fail if readlink doesn't support -e

[sacrificial-spam-address]

Package: libc6
Version: 2.13-24
Severity: minor

I was trying to upgrade a Very Old installation, and the preinst failed with

 Checking for services that may need to be restarted...
 Checking init scripts...
 readlink: invalid option -- e
 Try `readlink --help' for more information.
 dpkg: error processing libc6_2.13-24_i386.deb (--install):
  subprocess pre-installation script returned error exit status 1

coreutils 5.2.1-2 doesn't support the -e or -m flags, only -f.

I know it's a pretty annoying corner case, but libc is kind of *important*
and it would be nice if it worked even in extreme cases like this.
I can't install a current coreutils until I get libc upgraded, and
it's being a bit of a pain.

(It's being very exciting because apt-get segfaults trying to read
a current Packages file, so I'm doing lots of manual downloading and
dpkg -i to get apt upgraded.)


I got around it by patching /var/lib/dpkg/tmp.ci/preinst before the
preinst was run, and have now hit the kernel version 2.6.26 check.
The exceitement continues...



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652597: gcc-4.7-base trying to overwrite '/usr/lib/gcc/i486-linux-gnu/4.6.1'

[sacrificial-spam-address]

Package: gcc-4.7-base
Version: 4.7-20111217-1
Severity: important

gcc-4.6-base and gcc-4.7-base disagree on the target of the symlink:
lrwxrwxrwx root/root 0 2011-12-17 07:54 
./usr/lib/gcc/i486-linux-gnu/4.6.1 - 4.6
lrwxrwxrwx root/root 0 2011-12-17 18:11 
./usr/lib/gcc/i486-linux-gnu/4.6.1 - 4.7

This renders it uninstallable (without some --force options to dpkg), thereby
breaking quite a few packages that depend on it.

It looks like the symlink in the 4.7 package is a mistake.
(For now, I have forced 4.6-base to overwrite 4.7-base.)

(Severity not serious because I can't find an explicit must
or required in Debian policy mandating Conflicts: declarations.
Section 3.5 requires declaration of prerequisites, but I cannot
find an explicit requirement for conflicts.)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#648990: get_myaddress: getifaddrs: Connection refused

[sacrificial-spam-address]

Package: nis
Version: 3.17-32

I'm not sure what happened recently; I am running sid (unstable) and a
reasonably recent kernel (3.1.0).  I just upgraded to perl 5.14.
The machine is an NIS client, and for some reason ypbind is not starting.
This causes all sorts of problems with userid-name mappings not working.

The tail of an strace -f trying to start the ypbind server is:

17044 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
17044 close(1022)   = -1 EBADF (Bad file descriptor)
17044 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
17044 close(1023)   = -1 EBADF (Bad file descriptor)
17044 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
17044 umask(0)  = 022
17044 open(/dev/null, O_RDWR) = 0
17044 dup(0)= 1
17044 dup(0)= 2
17044 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT SEGV PIPE TERM CHLD], NULL, 8) = 0
17044 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6aa5000
17044 mprotect(0xb6aa5000, 4096, PROT_NONE) = 0
17044 clone(child_stack=0xb72a5434, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0xb72a5bd8, {entry_number:6, base_addr:0xb72a5b70, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
seg_not_present:0, useable:1}, child_tidptr=0xb72a5bd8) = 17045
17045 set_robust_list(0xb72a5be0, 0xc)  = 0
17045 open(/var/run/ypbind.pid, O_RDWR|O_CREAT, 0644) = 3
17045 fcntl64(3, F_GETFD)   = 0
17045 fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
17045 fcntl64(3, F_GETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0, 
pid=3077939200}) = 0
17045 fcntl64(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
17045 write(3, 17044\n, 6)= 6
17045 futex(0x8052b24, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x8052afc, 2) 
= 0
17045 rt_sigtimedwait([HUP INT QUIT SEGV TERM CHLD], NULL, NULL, 8 unfinished 
...
17044 futex(0x8052b24, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource 
temporarily unavailable)
17044 futex(0x8052afc, FUTEX_WAKE_PRIVATE, 1) = 0
17044 socket(PF_NETLINK, SOCK_RAW, 0)   = 4
17044 bind(4, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
17044 getsockname(4, {sa_family=AF_NETLINK, pid=17044, groups=}, [12]) 
= 0
17044 time(NULL)= 1321461087
17044 sendto(4, \24\0\0\0\22\0\1\3_\345\303N\0\0\0\0\0\0\0\0, 20, 0, 
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = -1 ECONNREFUSED 
(Connection refused)
17044 close(4)  = 0
17044 dup(2)= 4
17044 fcntl64(4, F_GETFL)   = 0x2 (flags O_RDWR)
17044 fstat64(4, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
17044 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfa3fb68) = -1 ENOTTY 
(Inappropriate ioctl for device)
17044 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0xb781
17044 _llseek(4, 0, [0], SEEK_CUR)  = 0
17044 write(4, get_myaddress: getifaddrs: Connection refused\n, 46) = 46
17044 close(4)  = 0
17044 munmap(0xb781, 4096)  = 0
17044 exit_group(1) = ?
17043 exit_group(0) = ?
17042 exit_group(0) = ?
17041 exit_group(0) = ?

I tried statically configuring the YP server in /etc/yp.conf rather than
using -broadcast; no apparent difference.  (The above trace is actually
from this test.)

Trying to decode the netlink message, I see a NETLINK_ROUTE socket created, and 
the header is:
\24\0\0\0 = 024 = 20 (nlmsg_len)
\22\0 = 022 = 18 (nlmsg_type) RTM_GETLINK
\1\3 = 0x301 (nlmsg_flags): NLM_F_REQUEST | NLM_F_DUMP
_\345\303N = 0x4ec3e55f (nlmsg_seq)
\0\0\0\0 = 0 (nlmsg_pid)
\0\0\0\0 = 0 (not sure)

Searching the kernel source, this appears to be generated in netlink_dump_start
at net/netlink/af_netlink.c:1749, if netlink_lookup() fails.  But I don't know
enough about what the #$#$% is going on inside the netlink code to now if it
should be failing or not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#648990: get_myaddress: getifaddrs: Connection refused

[sacrificial-spam-address]

This may be a non-bug.  My machine crashed (kernel panic), and on reboot it has 
gone away.

If it's random hardware flakiness, sorry about the noise.
I'll try to remember to close it in a week if it hasn't reoccurred.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#647179: Acknowledgement (ALL_TRUSTED is firing when it shouldn't)

[sacrificial-spam-address]

Some advice on the spamassassin mailing lists suggests that there's a
bug in NetAddr::IP 4.049 (Debian package libnetaddr-ip-perl).

The recommended fix is to use 4.048 or 4.055+.

(Bug #601601 has similar symptoms, but I think it's different.)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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

[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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org