Bug#1029384: ro option fails when used to mount a previously umounted partition
Package: mount Version: 2.38.1-4 Severity: normal Hello, I have been trying different commands to temporarily mount a partition as read-only in a different place than the one declared in fstab (which will be used by a different partition). I tried simple commands and ended passing all long parameters hoping it was a misunderstanding: ---8<--- # umount /dev/mapper/VGSeagate1500-LVStorageA # mount --verbose --type ext4 --options-source disable --options ro,noload --source /dev/mapper/VGSeagate1500-LVStorageA --target /mnt/storage-b mount: /mnt/storage-b: /dev/mapper/VGSeagate1500-LVStorageA already mounted or mount point busy. dmesg(1) may have more information after failed mount system call. # mount --verbose --type ext4 --options-source disable --options relatime --source /dev/mapper/VGSeagate1500-LVStorageA --target /mnt/storage-b mount: /dev/mapper/VGSeagate1500-LVStorageA mounted on /mnt/storage-b. --->8--- The man page says "To prevent this kind of write access, you may want to mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block device itself to read-only mode, see the blockdev(8) command." That is "or", not "and", and failed anyway. Replacing "ro,noload" with "relatime" lets it mount, but RW. The only text in dmesg is "dm-10: Can't mount, would change RO state" when it fails. I also tried removing the line from /etc/fstab (assuming it was getting in the way, even with "--options-source disable"), still not mounting as read-only. OK, lets try with blockdev too: ---8<--- # umount /dev/mapper/VGSeagate1500-LVStorageA # blockdev --getro /dev/mapper/VGSeagate1500-LVStorageA 0 # blockdev --setro /dev/mapper/VGSeagate1500-LVStorageA # blockdev --getro /dev/mapper/VGSeagate1500-LVStorageA 1 # mount --verbose --type ext4 --options-source disable --options ro,noload --source /dev/mapper/VGSeagate1500-LVStorageA --target /mnt/storage-b mount: /mnt/storage-b: /dev/mapper/VGSeagate1500-LVStorageA already mounted or mount point busy. dmesg(1) may have more information after failed mount system call. # mount --verbose --type ext4 --options-source disable --options relatime --source /dev/mapper/VGSeagate1500-LVStorageA --target /mnt/storage-b mount: /mnt/storage-b: /dev/mapper/VGSeagate1500-LVStorageA already mounted or mount point busy. dmesg(1) may have more information after failed mount system call. # blockdev --setrw /dev/mapper/VGSeagate1500-LVStorageA # blockdev --getro /dev/mapper/VGSeagate1500-LVStorageA 0 # mount --verbose --type ext4 --options-source disable --options relatime --source /dev/mapper/VGSeagate1500-LVStorageA --target /mnt/storage-b mount: /dev/mapper/VGSeagate1500-LVStorageA mounted on /mnt/storage-b. --->8--- This is even worse, no mount possible until "--setrw". dmesg showed "/dev/mapper/VGSeagate1500-LVStorageA: Can't open blockdev" and "dm-10: Can't mount, would change RO state" after the first "--options realtime" cmd (while getro = 1). I assume the "change RO state" now means to writable, and the other times was to not writable. Maybe the bug is in the man page (needs update to newer procedure?), maybe bug in code (mount? filesystem? LVM?). There must be a way to mount read-only as initial state (not via second invocation with "remount,ro", which works), to avoid even the tiniest window of writability (not important for my usage, but surely for others). And if not possible anymore (uh? since when?), it could be explicitly documented. Cheers, GSR -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages mount depends on: ii libblkid1 2.38.1-4 ii libc6 2.36-7 ii libmount1 2.38.1-4 ii libselinux13.3-1+b1 ii libsmartcols1 2.38.1-4 mount recommends no packages. Versions of packages mount suggests: ii nfs-common 1:1.3.4-4 -- no debconf information
Bug#1016561: sysvinit-core: Please recommend systemd-tmpfiles and systemd-tmpfiles
Package: sysvinit-core Version: 3.03-1 Severity: normal Hi: The package already "Recommends: orphan-sysvinit-scripts", in same fashion it could recommend systemd-tmpfiles and systemd-tmpfiles (or the packages that provide those, systemd-standalone-tmpfiles and systemd-standalone-sysusers, whatever follows Debian policy better). Otherwise in cases like upgrading lvm2 (see bug #1014565) the full systemd is installed unnecessarily. Cheers, GSR -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages sysvinit-core depends on: ii debconf [debconf-2.0] 1.5.79 ii initscripts3.03-1 ii libc6 2.33-8 ii libselinux13.3-1+b1 ii mount 2.38-6 ii sysv-rc3.03-1 ii sysvinit-utils 3.03-1 Versions of packages sysvinit-core recommends: ii orphan-sysvinit-scripts 0.11 Versions of packages sysvinit-core suggests: pn bootlogd -- debconf information: sysvinit/hurd-fix-inittab:
Bug#1014565: lvm2: Please reorder "systemd | systemd-tmpfiles" dependency
Package: lvm2 Version: 2.03.15-2 Severity: normal Hello: Thanks for supporting other inits, IMO it would be even better if the Depency would be swapped. Those with systemd should see no change, but the rest will have to install before (or at the same time) the systemd-standalone-tmpfiles package (provider of systemd-tmpfiles), or take other measures like some pinning rules. Thanks and cheers, GSR -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages lvm2 depends on: ii dmeventd2:1.02.183-2 ii dmsetup 2:1.02.183-2 ii init-system-helpers 1.64 ii libaio1 0.3.111-1 ii libblkid1 2.37.2-1 ii libc6 2.33-7 ii libdevmapper-event1.02.12:1.02.145-1 ii libedit23.1-20181209-1 ii libselinux1 3.3-1+b1 ii libsystemd0 246.3-1 ii libudev1251.2-8 ii lsb-base11.2 ii systemd-standalone-tmpfiles [systemd-tmpfiles] 251.2-7 Versions of packages lvm2 recommends: pn thin-provisioning-tools lvm2 suggests no packages. -- no debconf information
Bug#1009798: key-mon: New upstream location with recent releases
Package: key-mon Version: 1.17-1 Severity: normal Dear Maintainer, upstream appears to be https://github.com/scottkirkwood/key-mon now and version 1.20 was released recently. Please consider packaging it for future Debian releases instead of letting it expire. Thank you, GSR
Bug#1005788: mupdf: Incomplete rendering "jbig2dec error: incompatible jbig2dec header (0.19) and library (0.16)"
Package: mupdf Version: 1.19.0+ds1-1 Severity: normal Hi: There seems to be a small problem with lib dependencies because https://tomlehrersongs.com/wp-content/uploads/2018/11/so-long-mom.pdf renders nothing. xpdf rendered it fine. Exact message is: ---8<--- warning: ICC support is not available warning: jbig2dec error: incompatible jbig2dec header (0.19) and library (0.16) versions (segment 4294967295) error: cannot allocate jbig2 context warning: Ignoring error during interpretation mupdf: warning: Errors found on page. Page rendering may be incomplete. --->8--- Manually upgrading libjbig2dec0 to 0.19-3 got the text to render (must be a scanned page), just the warning about ICC support left. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages mupdf depends on: ii freeglut32.8.1-3 ii libc62.33-5 ii libfreetype6 2.10.4+dfsg-1 ii libgl1 1.4.0-1 ii libgumbo10.10.1+dfsg-2.4 ii libharfbuzz0b2.1.1-1 ii libjbig2dec0 0.16+20190905-3 ii libjpeg62-turbo 1:2.1.2-1 ii libmujs1 1.0.7-1 ii libopenjp2-7 2.4.0-3 ii libssl1.11.1.1m-1 ii libx11-6 2:1.7.2-2+b1 ii libxext6 2:1.3.4-1 ii zlib1g 1:1.2.11.dfsg-2 mupdf recommends no packages. Versions of packages mupdf suggests: ii mupdf-tools 1.19.0+ds1-1 -- no debconf information
Bug#1000354: host: error while loading shared libraries: libisc-9.17.19-3-Debian.so
Package: bind9-host Version: 1:9.17.19-3 Severity: normal Hello, after update host command fails with: ---8<--- $ host example.com host: error while loading shared libraries: libisc-9.17.19-3-Debian.so: cannot open shared object file: No such file or directory $ ldd /usr/bin/host | grep "not found" libisc-9.17.19-3-Debian.so => not found libdns-9.17.19-3-Debian.so => not found libisccfg-9.17.19-3-Debian.so => not found libirs-9.17.19-3-Debian.so => not found libbind9-9.17.19-3-Debian.so => not found --->8--- The issue seems to be it has "dep: bind9-libs (>= 1:9.17.19)". bind9-dnsutils OTOH has "dep: bind9-libs (= 1:9.17.19-3)", exact match. Upgrading bind9-libs (previously 1:9.17.19-1) makes host work again, but that should have happened automatically by means of proper dependency values. Easy fix I guess, just configure in same way than dnsutils. Cheers, GSR -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages bind9-host depends on: ii bind9-libs 1:9.17.19-1 ii libc6 2.32-4 ii libidn2-0 2.2.0-2 bind9-host recommends no packages. bind9-host suggests no packages. -- no debconf information
Bug#986296: i7z generates two kernel messages per second while running
Package: i7z Version: 0.27.2+git2013.10.12-g5023138-7 Followup-For: Bug #986296 Hi: The reports happen with CPUs older than haswell too. The issue seems to be newer kernels checking what access the MSR registers. Previously i7z worked without triggering the logging. Other software is also being affected, for example https://github.com/erpalma/throttled/issues/228 Cheers, GSR
Bug#970574: xserver-xorg-video-amdgpu: ABI changed (24.0 to 24.1) but not the dependencies
Hi, deb...@iremonger.me.uk (2021-06-19 at 1704.32 +0100): > In short, I think this bug report should now be closed unless there > is an apparent issue specifically in buster or bullseye now [??] ? Currently I have xserver-xorg-video-amdgpu 19.1.0-2 with xserver-xorg-core 2:1.20.11-1 and it keeps working (updating Sid every now and then). The issue existed for a brief time, but probably does not matter in releases if they have debs in sync. Even if they do not explicitly request a given version, the avaliable versions implicitly avoid the problem (sorry, no machines to test them, but by numbers, Buster has an older video-amdgpu package, 18.1.99+git20190207-1, and Bullseye is like Sid now). Thus I agree it can be closed. For the record, in the rare case someone hits the issue, old log also had: ---8<--- [ 144.270] (II) Module ABI versions: [ 144.270]X.Org ANSI C Emulation: 0.4 [ 144.270]X.Org Video Driver: 24.0 [ 144.270]X.Org XInput driver : 24.1 [ 144.270]X.Org Server Extension : 10.0 --->8--- Notice the 24.0. Last ones have lines like: ---8<--- [24.338] (II) Module ABI versions: [24.338]X.Org ANSI C Emulation: 0.4 [24.339]X.Org Video Driver: 24.1 [24.339]X.Org XInput driver : 24.1 [24.339]X.Org Server Extension : 10.0 ... [24.374] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so [24.380] (II) Module amdgpu: vendor="X.Org Foundation" [24.380]compiled for 1.20.9, module version = 19.1.0 [24.380]Module class: X.Org Video Driver [24.380]ABI class: X.Org Video Driver, version 24.1 --->8--- Notice the two 24.1 for video drivers. xserver-xorg-video-amdgpu's "Depends" line still lists xorg-video-abi-24, without .1. Cheers, GSR
Bug#988304: exim4: rsyslog log files not getting any new info
Hi,
ametz...@bebt.de (2021-05-10 at 1938.37 +0200):
> what log_file_path setting are you using? I am aware that
> log_file_path = :syslog
> does not duplicate the entries to syslog but only logs to /var/log/exim4
> (See https://bugs.exim.org/show_bug.cgi?id=2733#c5 and later.)
Same config. To be exact, these are the config lines about syslog,
which have worked for years (log msgs once to syslog without time as
it will be added by logger and log to own files+syslog):
---8<---
syslog_duplication = false
syslog_timestamp = false
log_file_path = :syslog
--->8---
I just checked the documentation at exim.org and it seems their
purpose has not changed.
I see in the bugreport that explicit "/var/log/exim4/%slog : syslog"
works, but not ":syslog". So Debian 988304 is upstream 2733#c3.
Are we sure exim4 contacts rsyslog at all? Got the source, and all
those "else" & "if" without {} in src/log.c write_syslog() make me
doubt the compiler and humans agree what the source means.
Cheers,
GSR
Bug#988304: exim4: rsyslog log files not getting any new info
Package: exim4 Version: 4.94.2-2 Severity: normal After updating from 4.94.2-1 any info stopped appearing in rsyslog (8.2102.0-2) files like /var/log/mail.log. Mail can be sent and received, and /var/log/exim4/mainlog gets new lines. So it seems to be something about talking with syslog. Cheers, GSR -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages exim4 depends on: ii debconf [debconf-2.0] 1.5.76 ii exim4-base 4.94.2-2 ii exim4-daemon-light 4.94.2-2 exim4 recommends no packages. exim4 suggests no packages.
Bug#981706: maim: Improve man page for better apropos results
Package: maim Version: 5.6.3-1 Severity: minor Tags: patch Hello: The man page could be improved to have better apropos(1) results. IOW, to make the program appear with search terms that come to mind first, as "make image" is true but too abstract. See attached patch. Background: I was looking for avaliable screenshot tools, I knew I had more installed and had no idea why at least one was missing. I ended finding it again because I remembered about slop (which IMHO could also get the man page name section improved), "apropos select" worked. The use will be a bash oneliner like "zbarimg -q <( maim -f png ) | xsel" to decode barcodes that are on screen and load them into the selection. Cheers, GSR --- maim.1 2021-02-03 00:19:10.204608451 +0100 +++ maim.1.new 2021-02-03 00:27:20.882598240 +0100 @@ -1,8 +1,8 @@ .\" Manpage for maim. .\" Contact naelst...@gmail.com to correct errors or typos. -.TH maim 1 2017-03-21 Linux "maim man page" +.TH maim 1 2021-02-03 Linux "maim man page" .SH NAME -maim \- make image +maim \- capture screenshot of desktop and make image .SH SYNOPSIS maim [OPTIONS] [FILEPATH] .SH DESCRIPTION
Bug#981703: slop: Improve man page for better apropos results
Package: slop Version: 7.5-1+b1 Severity: minor Tags: patch Hello: The man page could be improved to have better apropos(1) results. IOW, to make the program appear with search terms that come to mind first, as "select operation" is true but too abstract. See attached patch. Background: managed to find forgotten maim(1) via slop, but realized both have rather short name blocks, making them rather invisible to apropos unless you get the right word (of two possible). man -K uses full man page text (slow, also in the sense of having to hit C-d many times), while man -k or apropos seem to only use the one line name part. Cheers, GSR --- slop.1 2021-02-03 00:44:14.845211670 +0100 +++ slop.1.new 2021-02-03 00:45:37.046820924 +0100 @@ -1,8 +1,8 @@ .\" Manpage for slop. .\" Contact naelst...@gmail.com to correct errors or typos. -.TH SLOP 1 2017-03-21 Linux "slop man page" +.TH SLOP 1 2021-02-03 Linux "slop man page" .SH NAME -slop \- select operation +slop \- select operation, either mark screen region or pick window .SH SYNOPSIS slop [-klqn] [OPTIONS] .SH DESCRIPTION
Bug#976427: closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.3-1)
Hi, ow...@bugs.debian.org (2020-12-19 at 0051.03 +): >* Make debian/cron.daily/plocate executable. (Closes: #976427) A freshly installed package will have it executable. If previously installed from any of the buggy versions, the non-executable mode is kept. No idea if that needs extra actions (eg, force executable if upgrading from those versions) or not. Maybe worth consulting with other packagers, or something already covered in the packaging policies. Cheers, GSR
Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)
Version: 1.1.2-2
The cron script still not installed as executable, which is required
by run-parts.
Hi,
se...@debian.org (2020-12-10 at 0107.36 +0100):
> On Thu, Dec 10, 2020 at 12:58:09AM +0100, GSR wrote:
> > The solution I meant is "try working with less concurrently opened
> > files" or something similar.
>
> Yes, and that's fundamentally hard without creating races and still
> maintaining the desired ordering of locate output. updatedb.mlocate
> tries, and has to do a very complicated dance with chdir() back and forth.
> It runs into lots of icky cases and has to just silently ignore some errors
> (with associated races); the only winning move is not to play.
Unsorted output of locate, or updatedb.plocate not building the db
correctly? If the first, eg "apt-cache search locate" too gives poorly
sorted results. Following Unix philosophy by adding a tool ("| sort")
that does one thing well solves that cosmetic problem.
Cheers,
GSR
Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)
Hi, se...@debian.org (2020-12-08 at 0109.08 +0100): > On Tue, Dec 08, 2020 at 01:04:07AM +0100, GSR wrote: > > And the ulimit line is missing, so when testing manually it fails with > > ---8<--- > > /some/dir/somewhere: Too many open files > > Hint: Try `ulimit -n 8192' or similar (current limit is 4096). > > --->8--- > > That's odd; it should do setrlimit() itself at startup (LimitNOFILE= > in the systemd unit is just to set the hard limit). How can ulimit > in the shell succeed but setrlimit() fail? That bash ulimit call (just -n, without -H or -S) sets both hard and soft at the same time (see bash(1)), and as it is run as root, it can change to anything including beyond current hard. If setrlimit() only request a change of rlim_cur, hard will act as ceiling. > > When run for personal databases the solution must come from the > > binary, as users will not be able to raise limit beyond the hard > > number. > > updatedb isn't privileged, so it's no more able to raise the hard limit than > the user is. The solution I meant is "try working with less concurrently opened files" or something similar. I understand the concept beyond io_uring, but I have not checked any code, so maybe it can be asked to behave inside the limits, or the calling code must limit the requests or the processing of the answers, or maybe something else completly. mlocate seems to work fine with 1024 as limit (or 4096 if it is also raising soft to hard). I just tried to create a private db of the troublesome tree using "/usr/sbin/updatedb.plocate -l 0 -o /tmp/ploc.db -U /path/" and failed again. "/usr/bin/updatedb.mlocate -l 0 -o /tmp/mloc.db -U /path/" created the database without issues. I would need to use root to generate the plocate db for normal accounts (not good, even if I have access to root), or keep mlocate and convert. BTW, notice sbin vs bin. Also plocate-build is under sbin. They are supposed to be usable by normal accounts. Cheers, GSR
Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)
Package: plocate Version: 1.1.1-2 Followup-For: Bug #976427 Hi, ow...@bugs.debian.org (2020-12-07 at 1009.05 +): > plocate (1.1.1-2) unstable; urgency=medium > . >* Install a new /etc/cron.daily/plocate, for non-systemd users; > based on work by GSR, which based it on the mlocate cron job. > (Closes: #976427) Script must be chmod a+x or Debian's cron ignores it (see run-parts(8) and all other scripts under /etc/cron.daily/). And the ulimit line is missing, so when testing manually it fails with ---8<--- /some/dir/somewhere: Too many open files Hint: Try `ulimit -n 8192' or similar (current limit is 4096). --->8--- A big limit is needed, or the binary must be changed to work inside typical limits (IIRC soft 1024 / hard 4096 are the defaults for non privileged accounts, root must be ignoring soft one). When run for personal databases the solution must come from the binary, as users will not be able to raise limit beyond the hard number. Cheers, GSR
Bug#976427: plocate: Please keep cron script for use without systemd
Package: plocate Version: 1.1.1-1 Tags: patch Hi, se...@debian.org (2020-12-05 at 0032.04 +0100): > The cron script did the wrong thing from 1.1.0: > > - It depended on mlocate's database. > - It would do double-work on top of the systemd timer. As mlocate is also installed here, it went without issues. > I'm happy taking a patch to add back a script that fixes both of these > issues, ie., runs updatedb.plocate instead of plocate-build, and does not run > if the systemd timer would run instead. Would you like to contribute one? Changing mlocate script to work with plocate was easy, so it does all that and more. See attached file. Cheers, GSR #! /bin/bash set -e UPDATEDB=/usr/sbin/updatedb.plocate # skip in favour of systemd timer if [ -d /run/systemd/system ]; then exit 0 fi [ -x $UPDATEDB ] || exit 0 if which on_ac_power >/dev/null 2>&1; then ON_BATTERY=0 on_ac_power >/dev/null 2>&1 || ON_BATTERY=$? if [ "$ON_BATTERY" -eq 1 ]; then exit 0 fi fi # See ionice(1) IONICE= if [ -x /usr/bin/ionice ] && /usr/bin/ionice -c3 true 2>/dev/null; then IONICE="/usr/bin/ionice -c3" fi # See nocache(1) NOCACHE= if [ -x /usr/bin/nocache ]; then NOCACHE="/usr/bin/nocache" fi # It can open many files at once, ensure a big limit ulimit -n 1048576 flock --nonblock /run/plocate.daily.lock $NOCACHE $IONICE nice $UPDATEDB
Bug#976427: plocate: Please keep cron script for use without systemd
Package: plocate Version: 1.1.0-4 Severity: normal Dear Maintainer, Last update removed cron script, which was working OK. Not everyone uses systemd timers, so please keep the script. Thank you, GSR -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages plocate depends on: ii libc6 2.31-5 ii libgcc-s1 10.2.0-23 ii libstdc++6 10.2.0-23 ii liburing1 0.7-1 ii libzstd11.4.5+dfsg-2 plocate recommends no packages. plocate suggests no packages. -- no debconf information
Bug#975935: linux-image-5.9.0-1-amd64: HDA Digital PCBeep not registered anymore
Line Out Surround as /devices/pci:00/:00:1b.0/sound/card0/input16 [4.925818] input: HDA Intel MID Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card0/input17 [4.925867] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input20 [4.925895] input: HDA Intel MID Line Out Side as /devices/pci:00/:00:1b.0/sound/card0/input18 [4.925938] input: HDA Intel MID Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input19 [4.925981] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input21 [4.926023] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input22 [4.926180] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input23 [4.926503] input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input24 [4.927323] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input25 --->8--- ---8<--- [0.00] Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.1-1 (2020-10-17) ... [4.855297] snd_hda_intel :01:00.1: Force to non-snoop mode [4.936580] snd_hda_codec_via hdaudioC0D0: autoconfig for VT1828S: line_outs=4 (0x24/0x25/0x26/0x27/0x0) type:line [4.936582] snd_hda_codec_via hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [4.936584] snd_hda_codec_via hdaudioC0D0:hp_outs=1 (0x28/0x0/0x0/0x0/0x0) [4.936586] snd_hda_codec_via hdaudioC0D0:mono: mono_out=0x0 [4.936587] snd_hda_codec_via hdaudioC0D0:dig-out=0x2d/0x2e [4.936588] snd_hda_codec_via hdaudioC0D0:inputs: [4.936590] snd_hda_codec_via hdaudioC0D0: Front Mic=0x29 [4.936592] snd_hda_codec_via hdaudioC0D0: Rear Mic=0x2b [4.936593] snd_hda_codec_via hdaudioC0D0: Line=0x2a [4.936594] snd_hda_codec_via hdaudioC0D0: CD=0x2c [4.949948] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input12 [4.950016] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input13 [4.950073] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input14 [4.950126] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input15 [4.950192] input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input16 [4.950252] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input17 [4.952642] input: HDA Intel MID Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input18 [4.952699] input: HDA Intel MID Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input19 [4.952761] input: HDA Intel MID Line as /devices/pci:00/:00:1b.0/sound/card0/input20 [4.952820] input: HDA Intel MID Line Out Front as /devices/pci:00/:00:1b.0/sound/card0/input21 [4.952882] input: HDA Intel MID Line Out Surround as /devices/pci:00/:00:1b.0/sound/card0/input22 [4.952942] input: HDA Intel MID Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card0/input23 [4.952998] input: HDA Intel MID Line Out Side as /devices/pci:00/:00:1b.0/sound/card0/input24 [4.953058] input: HDA Intel MID Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input25 --->8--- Maybe it is related (at least based in release dates) to changes in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/pci/hda/hda_beep.c?id=45571bb871b217f1031045a27d935ea7c6ea5d12 Thank you for any help, GSR -- Package-specific info: ** Version: Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.1-1 (2020-10-17) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-1-amd64 root=/dev/mapper/VGIntelSSD-LVIntelRoot ro quiet intel_iommu=on scsi_mod.use_blk_mq=1 log_buf_len=1M amdgpu.audio=0 ** Not tainted ** Kernel log: ... ** Model information sys_vendor: System manufacturer product_name: System Product Name product_version: System Version chassis_vendor: Chassis Manufacture chassis_version: Chassis Version bios_vendor: American Megatrends Inc. bios_version: 1807 board_vendor: ASUSTeK Computer INC. board_name: P7P55D board_version: Rev 1.xx ** Loaded modules: bnep bluetooth jitterentropy_rng drbg aes_generic crypto_simd cryptd glue_helper ansi_cprng ecdh_generic ecc rfkill libaes binfmt_misc brd nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc loop firewire_sbp2 intel_powerclamp coretemp amdgpu kvm_intel snd_hda_codec_via snd
Bug#971578: firejail: overlay-named not working with newer kernels, causes ELOOP
Package: firejail
Version: 0.9.62.4-2
Severity: normal
Dear Maintainer,
"firejail --overlay-named=foobar bash" fails with "Error mounting
overlayfs for mounted home directory: fs.c:1064 fs_overlayfs: Too many
levels of symbolic links".
Similar to upstream https://github.com/netblue30/firejail/issues/2799
This points to overlayfs improvements in recent kernels. It works with
linux-image-4.17.0-1-amd64 4.17.8-1, but with newer ones I tested,
linux-image-5.2.0-2-amd64 5.2.9-2 & linux-image-5.8.0-2-amd64
5.8.10-1, a possible loop is detected and mount aborts.
I hope I found the concept for a solution, but it would need to be
adapted for firejail. Lets prepare the dir tree for the demo, /tmp is
a tmpfs, /home is physical ext4:
---8<---
# mkdir -p /tmp/merged{1,2} /tmp/step1/{upper1,work1}
# export DEMO=username
# mkdir -p /home/$DEMO/.firejail/step2/{upper2,work2}
--->8---
Currently firejail seems to go direct to what I call step 2, creating
a loop which the kernel does not allow, similar to this:
---8<---
# mount -t overlay overlay
-olowerdir=/home/,upperdir=/home/$DEMO/.firejail/step2/upper2/,workdir=/home/$DEMO/.firejail/step2/work2/
/tmp/merged2
mount: /tmp/merged2: mount(2) system call failed: Too many levels of symbolic
links.
--->8---
The workaround I found is to first create an overlay to delete where
the looping point would appear:
---8<---
# mount -t overlay overlay
-olowerdir=/home/,upperdir=/tmp/step1/upper1/,workdir=/tmp/step1/work1/
/tmp/merged1
# rm -fr /tmp/merged1/$DEMO/.firejail/
--->8---
And now proceed with the desired overlay, that stores data in the user
directory for future mounts:
---8<---
# mount -t overlay overlay
-olowerdir=/tmp/merged1,upperdir=/home/$DEMO/.firejail/step2/upper2/,workdir=/home/$DEMO/.firejail/step2/work2/
/tmp/merged2
# touch /tmp/merged2/$DEMO/overlay-test
# umount /tmp/merged2
# mount -t overlay overlay
-olowerdir=/tmp/merged1,upperdir=/home/$DEMO/.firejail/step2/upper2/,workdir=/home/$DEMO/.firejail/step2/work2/
/tmp/merged2
# ls /tmp/merged2/$DEMO/overlay-test
--->8---
So instead of "overlay over home storing data in home", first "overlay
over home storing data in memory" (reusable for concurrent firejails
until next reboot?), then delete the problematic directory in it, and
another "overlay over the memory one", so this time we can use home
for storage without problems, and hiding it from current (and
concurrent) firejail(s).
Seeing the complexity of doing it by hand, maybe there could be cmds
"firejail --[u]mount-overlay=overlay_name /some/dir/" to make
inspection of (non live?) overlays easier. root could run a script,
but if user alone can check own overlays, it would be a lot better.
(Existing --join-filesystem makes me think the following could be
tricky or unsafe or require some kind of network based fs... still
learning about namespaces:)
Related to above maybe there could be a param "--export-fs=/some/dir"
to launch a jail with the filesystem viewable from outside (as
alternative to multiple --get, --ls and --put); and cmds "firejail
--bind-[u]mount={name|pid} /some/dir" to mount the fs view of a
running jail and keep it after it ends down. They would help debugging
configs and allowing extraction of data even if you forget to launch
with overlays instead of any of the "all discarded on exit" options.
Well, I hope the double overlay is the solution, or leads to something
that makes the feature work again.
Cheers,
GSR
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages firejail depends on:
ii libapparmor1 2.13.4-3
ii libc6 2.31-3
Versions of packages firejail recommends:
ii firejail-profiles 0.9.62.4-2
ii iproute2 5.8.0-1
ii iptables 1.8.5-3
ii xauth 1:1.0.10-1
ii xpra 3.0.9+dfsg1-1+b2
ii xserver-xephyr 2:1.20.9-2
ii xvfb 2:1.20.9-2
firejail suggests no packages.
-- no debconf information
Bug#970574: xserver-xorg-video-amdgpu: ABI changed (24.0 to 24.1) but not the dependencies
Package: xserver-xorg-video-amdgpu Version: 19.1.0-2 Severity: important Dear Maintainer, After updating xserver-xorg-video-amdgpu from 19.1.0-1 to 19.1.0-2, startx stopped working. It seems to be a mismatch of ABI versions and .deb metadata (provides, breaks, conflicts, etc). The log had: ---8<--- [ 144.299] (II) LoadModule: "amdgpu" [ 144.299] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so [ 144.305] (II) Module amdgpu: vendor="X.Org Foundation" [ 144.305]compiled for 1.20.9, module version = 19.1.0 [ 144.305]Module class: X.Org Video Driver [ 144.305]ABI class: X.Org Video Driver, version 24.1 [ 144.306] (EE) amdgpu: module ABI minor version (1) is newer than the server's version (0) [ 144.306] (EE) Failed to load module "amdgpu" (module requirement mismatch, 0) [ 144.306] (II) LoadModule: "wacom" [ 144.306] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so [ 144.307] (II) Module wacom: vendor="X.Org Foundation" [ 144.307]compiled for 1.20.4, module version = 0.34.99 [ 144.307]Module class: X.Org XInput Driver [ 144.307]ABI class: X.Org XInput driver, version 24.1 ... [ 144.309] (EE) No drivers available. [ 144.309] (EE) Fatal server error: [ 144.309] (EE) no screens found(EE) [ 144.309] (EE) --->8--- The solution was updating xserver-xorg-core by hand, from 2:1.20.3-1 to 2:1.20.9-1. ABI 24.0 does not seem to be good enough for video drivers and debs like xserver-xorg-video-amdgpu should request a newer xserver-xorg-core, or drivers should stay compatible with core (wacom reports 24.1, and it was working days ago with that, so for xinput drivers it did not matter). Cheers, GSR
Bug#908533: compton: Change compton sources
Hi all: See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96143 If I understood correctly, migration will be manual. It would be nicer if automatic (fake compton that depends on real picom?), or at least some kind of notification beyond emails like this one. Cheers, GSR
Bug#908533: compton: Change compton sources
*blush* Copy paste error, missed the 2 at the end. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961432 Sorry for the noise. GSR
Bug#941532: brz: bash completion fails
Package: brz Version: 3.0.1-6 Severity: normal Hello: brz - does nothing, unlike many other commands. Quick look shows that file /usr/share/bash-completion/completions/brz is a single line "contrib/bash/bzr", which looks like a path. Checked the tarball and it has such path, which is a shell snippet to invoke brz and generate the completion functions. That code works once placed under /usr/... , listing multiple options. The package build process must be mixing things, writing a path instead of copying the code. Cheers, GSR -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages brz depends on: ii python3 3.7.3-1 ii python3-breezy 3.0.1-6 Versions of packages brz recommends: ii python3-dulwich 0.19.13-1 pn python3-gpg Versions of packages brz suggests: pn brz-doc pn python3-breezy.tests ii python3-fastimport0.9.8-2 -- no debconf information
Bug#922667: beep: Error: could not open any device
Package: beep Followup-For: Bug #922667 Before it worked fine via sound card speakers as normal user, now not even root can get beeps. I understand the user perms setup part being not done yet, but not why root fails too (the only difference is if it prints "Error: Could not open any device" or not). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages beep depends on: ii libc6 2.28-7 beep recommends no packages. beep suggests no packages. -- no debconf information
Bug#922178: /lib/security/pam_unix.so: cannot open shared object file: No such file or directory
Package: libpam-runtime Version: 1.3.1-1 Followup-For: Bug #922178 Hi: Same thing. "/etc/init.d/cron restart" seems to get things back to normal. Just after upgrade: ---8<--- CRON[12874]: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file: No such file or directory CRON[12874]: PAM adding faulty module: pam_unix.so CRON[12874]: Authentication failure --->8--- After restarting cron, things work again: ---8<--- CRON[26043]: pam_unix(cron:session): session opened for user root by (uid=0) CRON[26043]: pam_unix(cron:session): session closed for user root --->8--- Upgrading a package should automatically restart services that depend on it, like it happens with ssh server. Thanks, GSR -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libpam-runtime depends on: ii debconf [debconf-2.0] 1.5.70 ii libpam-modules 1.3.1-1 libpam-runtime recommends no packages. libpam-runtime suggests no packages. -- debconf information: libpam-runtime/conflicts: libpam-runtime/title: libpam-runtime/override: false * libpam-runtime/no_profiles_chosen: libpam-runtime/you-had-no-auth: * libpam-runtime/profiles: unix, capability
Bug#917306: libopenvdb-dev should depend on libtbb-dev & libblosc-dev
Package: libopenvdb-dev Version: 5.2.0-5 Severity: normal Header files from libopenvdb-dev include headers from libtbb-dev, so it should depend on it, similar to libilmbase-dev. One example: openvdb.h includes own tree/Tree.h, which includes tbb/atomic.h. And probably libblosc-dev should also be a dep, as libopenvdb5.2 depends on libblosc1 and while VDB can be compiled without Blosc, the Debian version has it. Thanks, GSR -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libopenvdb-dev depends on: ii libilmbase-dev 2.2.1-2 ii libopenvdb5.2 5.2.0-5 libopenvdb-dev recommends no packages. libopenvdb-dev suggests no packages. -- no debconf information
Bug#915261: SysV init regression thanks to broken "container detection" logic
Package: udev Version: 239-14 Followup-For: Bug #915261 I tried to set severity to serious but it was reverted. An unbootable system is not nice, I had to look around for a rescue disk (luckly I still had one around) to change the script (it was obvious by message, and also I roughly remembered the etckeeper diff). It could be a bit more troublesome if combined (no other local machines to help, no USB sticks, issues in remote machines, failures without output...). ---8<--- if [ -w /sys ]; then log_warning_msg "udev does not support containers BUT BUG WORKAROUND" # exit 0 fi --->8--- Bug 915415 is about losing X11 mouse and keyboard, which is bad too. Bug 915361 was reported as grave. Avoiding more people to get into issues when cause is known seems reasonable, it saves everyone time. I don't mind finding new bugs and help solving them, but getting hit by old ones like this is discouraging. Confused about apt-listbugs purpose, GSR
Bug#915261: SysV init regression thanks to broken "container detection" logic
Package: udev Version: 239-14 Followup-For: Bug #915261 Severity: serious Severity should be at least serious, for two reasons. First so it gets listed with apt-listbugs default levels and people can decide what to do. And second, it does not affect every user, but those affected have to handle a broken boot, which is not nice. Per https://release.debian.org/testing/rc_policy.txt it is release critical. ---8<--- * makes unrelated software on the system (or the whole system) break --->8--- GSR
Bug#914267: mesa: [regression] with Mesa 18.2.5-2 the charackter model in Tomb Raider is no longer rendered.
Package: mesa Version: 18.2.5-2 Followup-For: Bug #914267 That looks like missing shaders. I hit a similar thing with mpv (just blue window, sound but no video) after upgrading 18.2.5-1 => 18.2.5-2, luckly showing some output that later helped with searches. ---8<--- [vo/gpu/opengl] fragment shader compile log (status=0): [vo/gpu/opengl] 0:36(27): error: invalid input layout qualifier used [vo/gpu/opengl] [vo/gpu/opengl] shader link log (status=0): error: linking with uncompiled/unspecialized shader --->8--- Bug 914303 could be the same too, garbled or single color output could mean shaders not working because they failed to compile. Looking up the error text, I found the culprit could be gcc, creating faulty mesa binaries. https://bugs.freedesktop.org/show_bug.cgi?id=108646 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 Cheers, GSR
Bug#913849: xcalib -a -i does not invert with amdgpu, goes with "pure" colors
Package: xcalib
Version: 0.8.dfsg1-2+b2
Severity: normal
"xcalib -a -i" should invert the colors, but instead changes
everything into some colors (white, black, cyan, blue, magenta, etc),
like if every component was only 0 or 255 for 8 bit channels. I fear
it could be related to amdgpu driver or Polaris chip videocard as
inversion worked time ago, before changing the card.
Sadly previous card, Cypress with radeon driver, is not avaliable
anymore, so unable to confirm if xcalib is doing the wrong calls to
generic code that changed since or driver / card is the culprit.
redshift changes the colors with the new card to something
apparently correct.
"xcalib -a -p" prints tables that look correct, 1024 lines to 0
or 0 to . In the inverted case, it also prints lots of "Warning -
{red,green,blue} gamma table not monotonic" messages (they are, but
decreasing, xcalib git changed it, still no good if you run "-a -i"
then "-a -p" instead of "-a -i -p").
"xrandr --prop | grep -i gamma" reports LUT sizes to be 4096, not
1024, making things more confusing, or maybe a clue of where the
problem resides.
Please reassign if you can test the culprit is the driver/card.
Thanks,
GSR
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages xcalib depends on:
ii libc62.27-8
ii libx11-6 2:1.6.4-3
ii libxext6 2:1.3.3-1+b2
ii libxxf86vm1 1:1.1.4-1+b2
xcalib recommends no packages.
Versions of packages xcalib suggests:
pn icc-profiles
-- no debconf information
Bug#738112: No support for XRandR
Package: xcalib Version: 0.8.dfsg1-2+b2 Followup-For: Bug #738112 https://github.com/OpenICC/xcalib.git has 0.10 and some extra commits. Found out it moved via https://sourceforge.net/p/xcalib/bugs/1/#a35b Thanks, GSR
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
Hi, sergi...@debian.org (2018-07-27 at 0024.07 -0400): > Ever since I started working on GDB I noticed that the gcore script is a > bit "forgotten". [...] > Honestly, I don't think this bug is important enough to justify > complicating the script. I'll send the upstream patch to clarify the > manpage (and Cc you); I hope this is enough to address the issue. Being a script, it can be locally adjusted as last resort. *shrug* The gcore of, at least, NetBSD uses the name without changes. FreeBSD also seems to have its own (both descending from a 4.2BSD tool). Most users probably invoke the commands inside gdb if no tool provided by the OS, that could explain why the script is not a priority. Cheers, GSR
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
Hi,
sergi...@debian.org (2018-07-26 at 0008.50 -0400):
> Sorry, I'm not sure I understand the problem. The '-o' option works as
> expected here:
>
> $ bash /usr/bin/gcore 21153
> 0x7f11fc3d0404 in __GI___nanosleep (requested_time=0x7ffc3cb70240,
> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
> Saved corefile core.21153
>
> $ bash /usr/bin/gcore -o blabla 21258
> 0x7f3531233404 in __GI___nanosleep (requested_time=0x7fff80925a40,
> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
> Saved corefile blabla.21258
>
> $ bash /usr/bin/gcore -o blabla 21549 21550
> 0x7fc267908404 in __GI___nanosleep (requested_time=0x7ffc76bc1c80,
> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
> Saved corefile blabla.21549
> 0x7fab24ce5404 in __GI___nanosleep (requested_time=0x7ffc2d80a380,
> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
> Saved corefile blabla.21550
The man page says you can ask for filename blabla, then uses
blabla.21258. That is the problem, it's not a filename, more like a
template, and between getting blabla.21258 or core.21258, no big win,
IMO. If it needs extra handling to end in the file you really wanted,
probably you can rename any of them, or wrap with pushd/popd to change
directory.
Compare also to many other programs, when they talk about a file or
filename, they normally use what is provided, unchanged. wget -i -o -a
and -O, sed -f, etc. wget doesn't force url files to end in .url, or
logging ones in .log, or ... You want to use .txt or no extension? All
work. You can even feed device names or connect to processes if the
shell supports "making files". They are flexible.
Thing talks about filename, I expect filename result, not that it
magically means template. Just as mayority of programs do.
> > While checking what was going on, I found -a is not documented in man
> > page, and script has not comment at all about what it really does
> > (options are found in 10.19 of info docs, it toggles two defaults,
> > Linux only).
>
> For some reason (probably because of the non-free aspect of it), the
> version of gdb.texinfo present in the salsa GDB repo is not the one
> shipped on upstream GDB 8.1. The gcore manpage is generated from this
> file, so this is why you're seeing an old version of it.
Indeed, very old, it says 6.8.
> > Suggestions:
> >
> > - change man page and -h output to say "pid[s]".
>
> This change would be welcome, IMO.
See patches... manpage one is probably moot, if generated from other
source, but could be used as reference.
Other option is simplifying the script, and users do multiple calls,
one per PID. Which I guess it was how it worked before as that is the
man page "tone" (process, not processes, pid, not pids, etc).
> > - support single PID with exact filename (no .pid extension). If you
> > can get a list of PIDs, you can also probably do the loop, so the
> > feature isn't so helpful but more importantly it disallows things
> > like '-o >( gzip - > "path/${PID}.gz" )' (on the fly compression) or
> > '-o "$T"' (a safe T created by tempfile(1)).
> >
> > - fix man page for -o "write core file to filename if one PID, or
> > filename.pid if multiple PIDs, instead of default core.pid".
>
> I don't really understand the two proposals above.
IOW: If you ask for a file to be used, it should be that one when
possible (single PID case), not something else. "Do what I say,
cooperate". And document that.
Cheers,
GSR
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
Package: gdb Version: 8.1-4 Followup-For: Bug #904628 Tags: patch Patch for possible update of man page. And a note: the suggested compression trick doesn't work (seek errors). Maybe there is other way, maybe not possible. The other example, about using securely created destination, works. GSR --- gcore.1 2018-07-26 04:50:01.066541238 +0200 +++ gcore.1-old 2018-07-11 17:49:59.0 +0200 @@ -1,26 +1,20 @@ -.TH gcore "1" "Jul 2018" "gdb 8.1" "GNU Tools" +.TH gcore "1" "May 2007" "gdb 6.8" "GNU Tools" .SH NAME -gcore \- Generate core files for running processes +gcore \- Generate a core file for a running process .SH SYNOPSIS .B gcore -[-a] [-o \fIfilename\fR] \fIpid[s]\fR +[-o \fIfilename\fR] \fIpid\fR .SH DESCRIPTION .\" Add any additional description here .PP -gcore generates a core file for the process(es) specified by process IDs, -\fIpid[s]\fR. By default, each core file is written to core.\fIpid\fR, in the +gcore generates a core file for the process specified by its process ID, +\fIpid\fR. By default, the core file is written to core.\fIpid\fR, in the current directory. .TP -\fB\-a\fR -(Linux only) ignore /proc/PID/coredump_filter and also dump memory mappings -marked with the 'VM_DONTDUMP' flag. See info node Core File Generation for -longer explanation. -.TP \fB\-o\fR \fIfilename\fR -write core file to \fIfilename\fR if one PID, or \fIfilename.pid\fR if -multiple PIDs, instead of default core.\fIpid\fR +write core file to \fIfilename\fR instead of core.\fIpid\fR .SH COPYING -Copyright \(co 2003, 2005, 2007, 2008, 2018 Free Software Foundation, Inc. +Copyright \(co 2003, 2005, 2007, 2008 Free Software Foundation, Inc. .PP Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
Package: gdb
Version: 8.1-4
Severity: normal
Tags: patch
Hello:
Current man page says "write core file to filename instead of
core.pid" but the real outcome is that dump is written to
filename.pid. Probably because it's not just a single PID, but a list
of PIDs, which neither man page nor -h talk about.
While checking what was going on, I found -a is not documented in man
page, and script has not comment at all about what it really does
(options are found in 10.19 of info docs, it toggles two defaults,
Linux only).
Suggestions:
- change man page and -h output to say "pid[s]".
- support single PID with exact filename (no .pid extension). If you
can get a list of PIDs, you can also probably do the loop, so the
feature isn't so helpful but more importantly it disallows things
like '-o >( gzip - > "path/${PID}.gz" )' (on the fly compression) or
'-o "$T"' (a safe T created by tempfile(1)).
- fix man page for -o "write core file to filename if one PID, or
filename.pid if multiple PIDs, instead of default core.pid".
- fix man page for -a (point to info? small text explaining?).
See patch for the script changes.
Thanks,
GSR.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gdb depends on:
ii libbabeltrace1 1.5.5-1
ii libc6 2.27-5
ii libexpat1 2.2.1-1
ii libipt1 1.5-1
ii liblzma55.2.2-1.3
ii libncursesw66.1+20180210-2
ii libpython3.63.6.5-9
ii libreadline77.0-1
ii libtinfo6 6.1+20180210-2
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages gdb recommends:
pn libc-dbg
Versions of packages gdb suggests:
ii gdb-doc8.1-1
pn gdbserver
-- no debconf information
--- bin/gcore 2018-07-26 00:49:09.671883982 +0200
+++ /usr/bin/gcore 2018-07-23 04:55:10.0 +0200
@@ -41,7 +41,7 @@
name=$OPTARG
;;
*)
-echo "usage: gcore [-a] [-o filename] pid[s]"
+echo "usage: gcore [-a] [-o filename] pid"
exit 2
;;
esac
@@ -51,7 +51,7 @@
if [ "$#" -eq "0" ]
then
-echo "usage: gcore [-a] [-o filename] pid[s]"
+echo "usage: gcore [-a] [-o filename] pid"
exit 2
fi
@@ -95,24 +95,17 @@
# Loop through pids
for pid in "$@"
do
- # If single dump, allow total control of output file with -o
- if [ "$#" -eq 1 -a "$name" != "core" ] ; then
- path="$name"
- else
- path="$name.$pid"
- fi
-
# `
Bug#904160: gdb: bashism(s) in gcore (or wrong shebang)
Package: gdb
Version: 8.1-3
Severity: important
Hello:
The shebang line of gcore script points to sh (dash here), and when
trying to use it stops immediately with:
---8<---
/usr/bin/gcore: 28: /usr/bin/gcore: Syntax error: "(" unexpected
--->8---
Changing sh to bash in the first line of the script makes it work
again. That or fix line 28 (and any other) to be compatible with basic
sh syntax.
Thanks,
GSR
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gdb depends on:
ii libbabeltrace1 1.5.5-1
ii libc6 2.27-5
ii libexpat1 2.2.1-1
ii libipt1 1.5-1
ii liblzma55.2.2-1.3
ii libncursesw66.1+20180210-2
ii libpython3.63.6.5-9
ii libreadline77.0-1
ii libtinfo6 6.1+20180210-2
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages gdb recommends:
pn libc-dbg
Versions of packages gdb suggests:
ii gdb-doc8.1-1
pn gdbserver
-- no debconf information
Bug#903141: intel-microcode: lynnfield microcode does not match intel announcements
Package: intel-microcode Version: 3.20180703.2 Severity: normal Hi: Intel reports in page 13 of https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf that Lynnfield CPUs (ID 106E5) should have microcode 0x09 and that they made 0x0A avaliable. Earlier document https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf mentions 0x09 in page 11. But latest updates have neither, still stuck at 0x07, which is very old. ---8<--- iucode-tool -l /lib/firmware/intel-ucode/ | grep -i 106e5 005/001: sig 0x000106e5, pf_mask 0x13, 2013-08-20, rev 0x0007, size 7168 --->8--- Does Debian need to source additional microcode packages? Is Intel limiting the distribution of fixes? Are both documents wrong? Thanks for any help you can provide, GSR -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages intel-microcode depends on: ii iucode-tool 2.3.1-1 Versions of packages intel-microcode recommends: ii initramfs-tools 0.130 intel-microcode suggests no packages. -- no debconf information
Bug#895005: procps: init script ignores local (all?) configuration
Package: procps
Version: 2:3.3.13-1
Followup-For: Bug #895005
Tags: patch
Hi again:
I think I found the issue, and some extras. Please see attached diff,
the important part is the last exit 0 that broke the sourcing done in
init-d-script. I also removed the useless check (that other script
checks if DAEMON is set and executable) and fixed QUIENT typo and the
function redefinitions.
Tested all commands avaliable in usage info (start, stop, status,
restart, try-restart, force-reload), all them work (ok or silent), but
try-restart prints things poorly (making status function return 1
makes thing look better but report "fail", which is probably worse).
I believe the QUIET_SYSCTL line and comment above it could become a
file named /etc/defaults/procps, init-d-script should take care of
including it.
Thanks,
GSR
--- procps 2018-04-07 04:01:42.155079422 +0200
+++ /etc/init.d/procps 2018-04-07 04:02:57.744576691 +0200
@@ -21,14 +21,20 @@
DAEMON=/sbin/sysctl
PIDFILE=none
+
+test -x $SYSCTL || exit 0
+
# Comment this out for sysctl to print every item changed
QUIET_SYSCTL="-q"
do_start_cmd() {
STATUS=0
- $DAEMON $QUIET_SYSCTL --system || STATUS=$?
+ $DAEMON $QUIENT_SYSCTL --system || STATUS=$?
return $STATUS
}
-do_stop() { return 0; }
-do_status() { return 0; }
+do_stop() {}
+do_stop_cmd() {}
+do_status() {}
+
+exit 0
Bug#895005: procps: init script ignores local (all?) configuration
Package: procps Version: 2:3.3.13-1 Severity: normal Hello: After updating from 2:3.3.12-4, the local sysctl configuration under /etc/sysctl.d/ seems to be ignored, at boot or when called manually (running the script or via "service procps start"). sysctl.conf is just comments, but I fear it's ignored too. Calling "sysctl --system" changes the variables correctly. First wild guess was that "Update the init script to use new LSB features" (from changelog) should also make sure such changes are there, by forcing update of whatever lsb packages are involved. But more inspection suggests it could be typos in the code, because reading init-d-script(5) man page says the shebang line (in the example) is #!/lib/init/init-d-script instead of #!/bin/sh. Yet changing that line and adding echo RUNNING in do_start_cmd prints nothing. More investigation, sysctl is $DAEMON now, and "test -x $SYSCTL || exit 0" doesn't really return (confirmed via adding set -u, then it really stops). The plot thickens. BTW /etc/init.d/skeleton says "implemend" in the comments, that sure is a typo. Thank you. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages procps depends on: ii init-system-helpers 1.51 ii libc62.27-3 ii libncurses5 6.1-1 ii libncursesw5 6.1-1 ii libprocps6 2:3.3.13-1 ii libtinfo56.1-1 ii lsb-base 9.20170808 Versions of packages procps recommends: ii psmisc 23.1-1 procps suggests no packages. -- no debconf information
Bug#892713: etckeeper: help detect config changes related to symlinks
Package: etckeeper Version: 1.18.7-1 Severity: wishlist As time passes, more and more files are moving away from /etc, only leaving a symlink, yet still being configuration. As result, when the contents change and the behaviour changes, etckeeper is useless to track the issues and you have to resort to other methods. One quick example are symlinks in /etc/fonts/conf.d/ pointing to /usr/share/fontconfig/conf.avail/ files. Before they pointed to ones in /etc/fonts/conf.avail/ so the contents were tracked and changes detected (some files still reside there, but they are disappearing with updates). It would be nice if etckeeper kept hashes of the linked files (or some other way to flag changes) so figuring what, since when or why something is happening is easier. It could be stored in the .etckeeper file, like the chmod lines. This would be half way between not keeping any info about config changes (due to the indirections) and fully tracking directories and files outside /etc (which seems to be beyond upstream plans). Thanks. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages etckeeper depends on: ii bzr2.7.0+bzr6622-10 ii debconf [debconf-2.0] 1.5.64 ii git1:2.16.2-1 ii mercurial 4.5-1 Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-128.1 Versions of packages etckeeper suggests: pn sudo -- debconf information: * etckeeper/commit_failed: etckeeper/purge: true
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
Hi, k...@debian.org (2017-09-17 at 0732.32 +0200): > It seems there were no functional changes between both versions, only > translation updates plus an extra CHANGES file (which looks like the > last changelog entry). BTW, Christian, a git push seems to be missing. Updated 1.167 to 1.169 and it did it again. So "flipped bit that has barely valid outcome without crashing" is now out of question, too much concidence. ---8<--- -loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null' +loadkeys '/tmp/tmpkbd.V1Nv35' > '/dev/null' --->8--- Running manually "setupcon --save-only" fixes it. :-? ---8<--- -loadkeys '/tmp/tmpkbd.V1Nv35' > '/dev/null' +loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null' --->8--- Cheers, GSR
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
Hi, k...@debian.org (2017-09-17 at 0732.32 +0200): > GSR <gsr.b...@infernal-iceberg.com> (2017-09-17): > > Package: console-setup > > Version: 1.167 > > Severity: normal > > > > Updated from 166 to 167 and when verifying changes in /etc/ noticed > > there was only one change, in console-setup/cached_setup_keyboard.sh: > > > > ---8<--- > > -loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null' > > +loadkeys '/tmp/tmpkbd.31u83e' > '/dev/null' > > --->8--- > > > > File in /tmp/, named tmpkbd and with (random) extension that looks > > like one from mktemp? And before it was a file in /etc/ with > > understable name? Suspicious. [...] > It seems there were no functional changes between both versions, only > translation updates plus an extra CHANGES file (which looks like the > last changelog entry). BTW, Christian, a git push seems to be missing. The diff above is what etckeeper commited when upgrading console-setup, console-setup-linux and keyboard-configuration, all from 1.166 to 1.167. And there have been previous commits, so it wasn't something pending from way past, it took place in the upgrade. Also, as predicted, "cannot open file /tmp/tmpkbd.31u83e" appeared on boot, yet mapping looked OK. Anyway, I invoked the other loadkeys by hand to be sure. After reading the man page, I decided to run "setupcon --save-only" by hand... and now the file is back to sane value. Uh!? A bit flipped during upgrade and naming choice got mangled? GSR
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
Package: console-setup Version: 1.167 Severity: normal Updated from 166 to 167 and when verifying changes in /etc/ noticed there was only one change, in console-setup/cached_setup_keyboard.sh: ---8<--- -loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null' +loadkeys '/tmp/tmpkbd.31u83e' > '/dev/null' --->8--- File in /tmp/, named tmpkbd and with (random) extension that looks like one from mktemp? And before it was a file in /etc/ with understable name? Suspicious. Running the script by hand returns the obvious "cannot open file /tmp/tmpkbd.31u83e" while calling the other version of loadkeys invocation works fine. Prediction is that in next boot it will complain too and require manually calling with the proper kmap file. Also while tracking the calls for boot sequence, found that usage line for /etc/init.d/keyboard-setup.sh and console-setup.sh forgot the .sh extension (two mount*.sh forgot the extension too, but that would be for another report). Most scripts properly report their name with .sh and one even just uses $0 so it reacts automatically to however it was called. Minor cosmetic details. Thanks, GSR -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages console-setup depends on: ii console-setup-linux 1.167 ii debconf 1.5.62 ii keyboard-configuration 1.167 ii xkb-data2.5.1-3 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales 2.24-17 ii lsb-base 9.20170808 Versions of packages keyboard-configuration depends on: ii debconf 1.5.62 ii liblocale-gettext-perl 1.07-3+b3 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.49 ii initscripts 2.88dsf-59.9 ii kbd 1.15.5-1 ii keyboard-configuration 1.167 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools pn gnome-control-center ii kbd 1.15.5-1 -- debconf information: keyboard-configuration/store_defaults_in_debconf_db: true * keyboard-configuration/altgr: Right Alt (AltGr) console-setup/use_system_font: * console-setup/fontface47: Fixed keyboard-configuration/layoutcode: es keyboard-configuration/xkb-keymap: es console-setup/codesetcode: Lat15 keyboard-configuration/other: keyboard-configuration/layout: console-setup/framebuffer_only: keyboard-configuration/unsupported_layout: true console-setup/fontsize-text47: 8x16 console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages * console-setup/fontsize-fb47: 8x16 keyboard-configuration/toggle: No toggling keyboard-configuration/switch: No temporary switch * keyboard-configuration/compose: Menu key keyboard-configuration/optionscode: lv3:ralt_switch,compose:menu,terminate:ctrl_alt_bksp keyboard-configuration/modelcode: pc105 keyboard-configuration/variantcode: keyboard-configuration/unsupported_config_options: true console-setup/guess_font: * keyboard-configuration/model: Generic 105-key (Intl) PC debian-installer/console-setup-udeb/title: * keyboard-configuration/variant: Spanish console-setup/store_defaults_in_debconf_db: true keyboard-configuration/unsupported_options: true * keyboard-configuration/ctrl_alt_bksp: true console-setup/charmap47: UTF-8 console-setup/fontsize: 8x16 keyboard-configuration/unsupported_config_layout: true
Bug#821291: Program received signal SIGSEGV, Segmentation fault.
Package: xpra
Version: 0.17.6+dfsg-1+b1
Followup-For: Bug #821291
By chance I think I hit this bug too, and also found the factor that
makes it happen. I created small scripts to test the idea. The culprit
is something in the icon themes, so maybe the bug should be assigned
to them (or maybe not and xpra should ignore the error and use a
fallback theme).
First create multiple rc files, one per icon theme avaliable based in
the current one (new setting at end, so it overrides previous value):
---8<---
mkdir /tmp/rc-xpra
for i in in /usr/share/icons/*/ ; do
THEME=$( basename $i )
cp ~/.gtkrc-2.0 /tmp/rc-xpra/gtkrc2-$THEME
echo gtk-icon-theme-name = \"$THEME\" >> "/tmp/rc-xpra/gtkrc2-$THEME"
done
--->8---
Start xpra as normal in one console and note down the display, for
example 7.
Then identify the problematic themes for attach command in another
console, by hitting C-c if it works or letting the process crash
(SIGSEGV 11, 128 + 11 = 139):
---8<---
XPRADISP=7
mkdir /tmp/rc-fail
cd /tmp/
for i in /tmp/rc-xpra/* ; do
echo === TESTING $i ===
GTK2_RC_FILES=$i xpra attach :$XPRADISP
if [ 139 -eq $? ] ; then
mv $i /tmp/rc-fail/
fi
echo === FINISHED $i ===
done
--->8---
"default" theme works but complains with:
---8<---
/usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:360:
GtkWarning: Theme file for default has no name
log("contexts: %s", it.list_contexts())
/usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:360:
GtkWarning: Theme file for default has no directories
log("contexts: %s", it.list_contexts())
--->8---
Meaning it can handle settings that have problems, at least sometimes.
Of the other small collection I have, icon theme Fog has empty
directory, yet works.
ContrastHigh and HighContrast fail with the g_str_hash +
gtk_icon_theme_list_contexts backtrace.
So if this is the case, workaround until proper fix could be creating
a new rc file with a working icon theme, and always launching with:
---8<---
GTK2_RC_FILES=~/.xpra/gtkrc-2.0 xpra attach [params]
--->8---
Cheers,
GSR
Bug#859978: linux-cpupower: wrong turbo speeds reported on Nehalem
Hi, b...@decadent.org.uk (2017-04-10 at 1904.15 +0100): > I've attached the patch that should fix this. Please either test this > patch or the modified packages (linux-cpupower & libcpupower1 version > 4.9.18-2~a.test) from <https://people.debian.org/~benh/packages/>. Works, now it reports 3200, 3200, 3467, 3600 MHz. Maybe it should report 3.200 GHz etc like all the other lines (= standardise on one unit and format). :) Thank you, GSR
Bug#859979: firejail: Option --overlay-path=path not supported but documented
Package: firejail Version: 0.9.44.10-1 Severity: normal Dear Maintainer, Man page talks about overlay-path but it fails as in: ---8<--- firejail --overlay-path=/tmp/testdir --overlay-named=testname Error: invalid --overlay-path=/tmp/testdir command line option --->8--- Checked the source, it seems to be unsupported yet (around line 1471 of main.c). Maybe man page should drop any mention until the issues are solved. Thanks, GSR -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages firejail depends on: ii libapparmor1 2.10-2+b1 ii libc6 2.24-9 Versions of packages firejail recommends: ii iptables 1.6.0+snapshot20161117-5 ii xauth 1:1.0.9-1 pn xpra | xserver-xephyr firejail suggests no packages. -- no debconf information
Bug#859978: linux-cpupower: wrong turbo speeds reported on Nehalem
Package: linux-cpupower Version: 4.9.13-1 Severity: normal Dear Maintainer, On i7-870 Nehalem, "cpupower frequency-info -n" reports the wrong speeds for boost states. It seems to take the right multipliers (24, 24, 26 and 27) but the wrong base clock (100 as per newer chips, instead of correct 133). Thus the reported speeds (2400-2700 Mhz) are even lower than the normal maximum (2934 Mhz). Output should be approx 3192-3591. i7z tool figures the 100 vs 133 correctly (yet has other bug and says the chip to be Nehalem Haswell at the same time, which has been reported too). It may serve as reference to figure where to extract the proper clock value for the cpupower command. Thanks, GSR -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages linux-cpupower depends on: ii libc6 2.24-9 ii libcpupower1 4.8.11-1 ii libpci3 1:3.5.2-1 linux-cpupower recommends no packages. linux-cpupower suggests no packages. -- no debconf information
Bug#856806: i7z: Possible wrong output with Nehalem
Package: i7z Version: 0.27.2+git2013.10.12-g5023138-3 Severity: normal Dear Maintainer, Running i7z in i7-870 Nehalem, it prints "i7z DEBUG: Detected a nehalem (i7/i5/Xeon) - 45nm" first and "i7z DEBUG: guessing Haswell" near the end. Haswell is a different newer family (i7-4170 eg, Sandy and Ivy are generations between it and Nehalem). The file helper_functions.c around line 420 has: *nehalem = true; *sandy_bridge = false; *ivy_bridge = false; *haswell = true; And other blocks always set one to true and the other three to false. Could that be a bug and the reason for the mixed reports? Just setting last to false could fix it, if no more tests needed to differentiate. The program also reports two conflicting values once running, first "True Frequency (without accounting Turbo) 2942 MHz" and below "Max Frequency without considering Turbo 3075.73 MHz (133.73 x [23])". The official value is ~2.9 GHz, the 23 multiplier is between official normal max (22) and minimum turbo (24 and up). Again I looked at the code, and in i7z_Single_Socket.c below line 285 I see it adds one when TURBO_MODE is 1. Maybe wrong? Maybe it should use another string to explain why? In other similar part of the file, below line 944, it says "True Frequency" instead (safety margin to allow transitions to/from turbo modes?). That function seems to be commented out. Other than those two, all looks OK. It even let me notice a bug in "cpupower frequency-info -n", which seems to be confused too and reports turbo levels as X * 100 instead of X * 133 (Nehalem vs newer), with the absurd result of normal max being well above the single core turbo. Thanks, GSR -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages i7z depends on: ii libc6 2.24-9 ii libncurses5 6.0+20151024-2 ii libtinfo5 6.0+20151024-2 ii msr-tools 1.3-2 ii ruby 1:2.1.0.4 ii ruby1.8 [ruby-interpreter]1.8.7.358-7 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1+b1 ii ruby2.1 [ruby-interpreter]2.1.2-3 i7z recommends no packages. i7z suggests no packages. -- no debconf information
Bug#445286: readline frontend for debconf and previous values
Hi: Already possible to have the previous values typed in. See reports 635032 & 537870. Install libterm-readline-gnu-perl to make the values appear ready to be edited. So what probably should do is include the values in prompt text when the package is not installed. Then allow pressing enter to accept, and only edits would require retyping. Cheers, GSR
Bug#838852: etckeeper: Missed package in listings
Package: etckeeper Version: 1.18.5-1 Severity: normal Dear Maintainer, Installing spamassassin reported: --8<-- The following additional packages will be installed: libdigest-hmac-perl libnet-dns-perl libnet-ip-perl libnetaddr-ip-perl libsys-hostname-long-perl ... The following NEW packages will be installed: libdigest-hmac-perl libnet-dns-perl libnet-ip-perl libnetaddr-ip-perl libsys-hostname-long-perl spamassassin -->8-- But the etckeeper commit contains only the lib* ones: --8<-- Package changes: +libdigest-hmac-perl 1.03+dfsg-1 all +libnet-dns-perl 1.06-1 all +libnet-ip-perl 1.26-1 all +libnetaddr-ip-perl 4.079+dfsg-1+b1 amd64 +libsys-hostname-long-perl 1.5-1 all -->8-- Spamassassin was removed previously due a problem with libnet-ip-perl that was solved hours later with the above install. But investigating I noticed it was not seen for removal either: --8<-- Package changes: -info 6.3.0.dfsg.1-1 amd64 +info 6.3.0.dfsg.1-1+b1 amd64 -install-info 6.3.0.dfsg.1-1 amd64 +install-info 6.3.0.dfsg.1-1+b1 amd64 -libapt-pkg-perl 0.1.29+b5 amd64 +libapt-pkg-perl 0.1.29+b6 amd64 -libclone-perl 0.38-1+b1 amd64 -libdbi-perl 1.634-1+b1 amd64 +libdbi-perl 1.636-1+b1 amd64 -libfile-fcntllock-perl 0.22-3+b1 amd64 -libfile-fnmatch-perl 0.02-2+b2 amd64 +libfile-fcntllock-perl 0.22-3+b2 amd64 +libfile-fnmatch-perl 0.02-2+b3 amd64 -libhtml-parser-perl 3.71-2+b1 amd64 +libhtml-parser-perl 3.72-2+b1 amd64 -libio-pty-perl 1:1.08-1.1+b1 amd64 +libio-pty-perl 1:1.08-1.1+b2 amd64 -liblist-moreutils-perl 0.413-1+b1 amd64 +liblist-moreutils-perl 0.416-1+b1 amd64 -liblocale-gettext-perl 1.07-1+b1 amd64 +liblocale-gettext-perl 1.07-3+b1 amd64 -libnet-dns-perl 0.81-2+b1 amd64 +libnet-dns-perl 1.06-1 all -libnet-ssleay-perl 1.72-1+b2 amd64 +libnet-ssleay-perl 1.77-1+b1 amd64 -libnetaddr-ip-perl 4.078+dfsg-1+b1 amd64 +libperl5.24 5.24.1~rc3-2 amd64 -libsocket6-perl 0.25-1+b2 amd64 +libsocket6-perl 0.27-1+b1 amd64 -libtext-charwidth-perl 0.04-7+b4 amd64 -libtext-iconv-perl 1.7-5+b3 amd64 +libtext-charwidth-perl 0.04-7+b5 amd64 +libtext-iconv-perl 1.7-5+b4 amd64 -libxml-libxml-perl 2.0123+dfsg-1+b1 amd64 +libxml-libxml-perl 2.0128+dfsg-1+b1 amd64 -libxml-parser-perl 2.44-1+b1 amd64 +libxml-parser-perl 2.44-2+b1 amd64 -perl 5.22.2-5 amd64 -perl-base 5.22.2-5 amd64 +perl 5.24.1~rc3-2 amd64 +perl-base 5.24.1~rc3-2 amd64 +perl-modules-5.24 5.24.1~rc3-2 all -texinfo 6.3.0.dfsg.1-1 amd64 +texinfo 6.3.0.dfsg.1-1+b1 amd64 -->8-- There must be something wrong with the code that generates the listings. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages etckeeper depends on: ii bzr2.7.0+bzr6619-2 ii debconf [debconf-2.0] 1.5.58 ii git1:2.9.3-1 ii mercurial 3.9.1-1 pn python:any Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-127 Versions of packages etckeeper suggests: pn sudo -- debconf information: * etckeeper/commit_failed: etckeeper/purge: true
Bug#834256: firejail: Please don't force PS1
Package: firejail
Version: 0.9.40-3
Severity: normal
Dear Maintainer,
firejail seems to force PS1. A grep in the git source shows it is done
by setting PROMPT_COMMAND (!?) in two different places (join.c and
env.c), but no explanation why in source or documentation.
If there is a security reason to force PS1 (or even the roundabout way
with PROMPT_COMMAND) it should be documented. Also using only colors
to inform of something can backfire, not all terminals support them.
Otherwise PS1 and PROMPT_COMMAND should be left under shell control
from the start. They can be overridden once you figure what is going
on anyway, and I would had not noticed anything if I had used
PROMPT_COMMAND for something.
While investigating this, I found out ${container} env var too with a
comment talking about Linux Containers. LXC doesn't seem to document
that one either, and the ones documented follow the standard of all
upper case (LXC_*), so I also have doubts about its correctness (some
left over from a LXC script? bug and will be fixed to be upper case?).
Thanks,
GSR
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages firejail depends on:
ii libc6 2.23-4
Versions of packages firejail recommends:
pn xpra | xserver-xephyr
firejail suggests no packages.
-- no debconf information
Bug#662895: closed by Ben Hutchings <b...@debian.org> (Closing bugs assigned to linux-2.6 package)
reopen 662895 reassign 662895 src:linux 4.4-1~exp1 quit Hi, ow...@bugs.debian.org (2016-02-09 at 1528.20 +): > If you can still reproduce this bug in a newer release, please reopen > the bug report and reassign it to 'src:linux' and the affected version > of the package. You can find the package version for the running > kernel by running: > > uname -v I have been using "#1 SMP Debian 3.16.7-ckt11-1 (2015-05-24)" for some time, and today installed a new kernel "#1 SMP Debian 4.4-1~exp1 (2016-01-19)". It keeps happening with both. It took over 7 hours to happen with the 4.4, but still seems the ATK0110 or something else in ACPI system is not playing nice, like reading too much or too few from a stack and then crap spreading. All these years I just managed to keep the system "usable" by brute forcing constant resets of the keyboard. Side effect: sometimes normal keys get stuck until all settles, sometimes modifiers get stuck (even if not pressed before... shift tends to do that) and you have to manually release & press them so they really release. GSR
Bug#663024: procps: 'w' not listing users in VTs
Hi, csm...@debian.org (2015-06-13 at 1606.25 +1000): I just checked my w program and its listing tty users fine. Are you still seeing this problem? If so I'll need to run some tests with you to find out why things are different. At some point it got fixed. Please close the report. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775174: iceweasel: Crash while loading pages with 3D, like get.webgl.org
Package: iceweasel
Version: 31.3.0esr-1
Severity: normal
Dear Maintainer,
iceweasel crashes as soon as any webgl feature appears in a
page. Simplest test is trying to load http://get.webgl.org/ but
http://www.vill.ee/eye also crashes.
After installing iceweasel-dbg I tried again with -safe-mode and the
crash happened again, see attached backtrace. Also attached glxinfo
output. Other 3D programs like glxgears or blender load fine.
I hope someone can figure what is going on, as everything just
disappears, without time to react. For now I will set webgl.disable to
true to avoid any other nasty surprise.
Thanks.
-- Package-specific info:
-- Extensions information
Using -safe-mode.
-- Plugins information
Name: Shockwave Flash (11.2.202.425)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled
-- Addons package information
ii iceweasel 31.3.0esr-1 amd64Web browser based on Firefox
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.17-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages iceweasel depends on:
ii debianutils 4.3.4
ii fontconfig2.9.0-7.1
ii libasound21.0.27.1-1
ii libatk1.0-0 2.8.0-2
ii libc6 2.19-13
ii libcairo2 1.12.14-4
ii libdbus-1-3 1.6.10-1
ii libdbus-glib-1-2 0.100.2-1
ii libevent-2.0-52.0.21-stable-1
ii libffi6 3.0.13-4
ii libfontconfig12.11.0-1
ii libfreetype6 2.5.2-2
ii libgcc1 1:4.8.1-8
ii libgdk-pixbuf2.0-02.28.2-1
ii libglib2.0-0 2.42.1-1
ii libgtk2.0-0 2.24.18-1
ii libhunspell-1.3-0 1.3.3-3
ii libnspr4 2:4.10.7-1
ii libnss3 2:3.17.2-1.1
ii libpango-1.0-01.36.3-1
ii libsqlite3-0 3.8.7.4-1
ii libstartup-notification0 0.12-3
ii libstdc++64.9.1-12
ii libvpx1 1.3.0-2
ii libx11-6 2:1.6.0-1
ii libxext6 2:1.3.3-1
ii libxrender1 1:0.9.7-1+deb7u1
ii libxt61:1.1.3-1+deb7u1
ii procps1:3.3.8-2
ii zlib1g1:1.2.8.dfsg-1
iceweasel recommends no packages.
Versions of packages iceweasel suggests:
pn fonts-mathjax none
pn fonts-oflb-asana-math none
pn fonts-stix | otf-stix none
pn libcanberra0 none
pn libgnomeui-0 none
ii libgssapi-krb5-2 1.12.1+dfsg-3
pn mozplugger none
-- Configuration Files:
/etc/iceweasel/iceweaselrc a7f1bcffd6febdb02e86652a60ebfd16 [Errno 2] No such
file or directory: u'/etc/iceweasel/iceweaselrc
a7f1bcffd6febdb02e86652a60ebfd16'
-- no debconf information
#0 0x7fa3b9a0279b in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x7fa3b61ccb29 in nsProfileLock::FatalSignalHandler (signo=11,
info=0x7fff00bb85b0, context=0x7fff00bb8480) at
/tmp/buildd/iceweasel-31.3.0esr/profile/dirserviceprovider/src/nsProfileLock.cpp:175
unblock_sigs = {__val = {1024, 0 repeats 15 times}}
oldact = optimized out
#2 signal handler called
No symbol table info available.
#3 0x7fa38f98e0eb in ?? () from /lib/x86_64-linux-gnu/libbsd.so.0
No symbol table info available.
#4 0x7fa3b9c1e9fa in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#5 0x7fa3b9c1eae3 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#6 0x7fa3b9c22c48 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#7 0x7fa3b9c1e8b4 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#8 0x7fa3b9c2243b in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#9 0x7fa3b97f002b in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#10 0x7fa3b9c1e8b4 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#11 0x7fa3b97f05dd in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#12 0x7fa3b97f00c1 in dlopen () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#13 0x7fa3943ad0b6 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
No symbol table info available.
#14 0x7fa3943b0b9c in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
No symbol table info available.
#15 0x7fa394385994 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
No symbol table info available.
#16 0x7fa3943818d1 in glXQueryVersion () from
/usr/lib/x86_64-linux-gnu/libGL.so.1
No symbol table info available.
#17 0x7fa3b546ef8b in
Bug#763406: geeqie: Float window uses image window dimensions
Hi, kl...@ethgen.de (2014-09-30 at 1012.55 +0100): After updating, it seems the saved state for the ile list window is the same of the image window. What do you mean with ile list window? Maybe I missed that word due my english is not the best but I do not know the word ile. Sorry, typo: file list window. The one you get by pressing l, to toggle from integrated as side column in the image window to floating alone. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763406: geeqie: Float window uses image window dimensions
Package: geeqie Version: 1:1.2-2 Severity: important Dear Maintainer, After updating, it seems the saved state for the ile list window is the same of the image window. Move or resize any of them, and in next use they both will appear as the image one was when closing. This worked fine in 1.1, each window was remembered correctly, all the state X, Y, width and height. The worst is that the file list get all the contents rearranged (if not hidden for lack of space) when the size is too small. Verified by looking at the config file, the values match perfectly every time, whatever main_window has, appears for float_window: ---8--- main_window.x = 267 main_window.y = 191 main_window.w = 200 main_window.h = 70 float_window.x = 267 float_window.y = 191 float_window.w = 200 float_window.h = 70 ---8--- Please check what went wrong with the 1.1 to 1.2 changes, thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages geeqie depends on: ii geeqie-common1:1.2-2 ii libatk1.0-0 2.8.0-2 ii libc62.19-9 ii libcairo21.12.14-4 ii libexiv2-13 0.24-4 ii libfontconfig1 2.11.0-1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.8.1-8 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-0 2.40.0-2 ii libgtk2.0-0 2.24.18-1 ii libjpeg621:1.3.1-3 ii liblcms2-2 2.2+git20110628-2.2 ii liblircclient0 0.9.0~pre1-1 ii liblua5.1-0 5.1.5-7 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 ii libstdc++6 4.9.1-12 ii libtiff5 4.0.3-5 Versions of packages geeqie recommends: pn exiftran none pn exiv2none ii imagemagick 8:6.8.9.6-4 ii librsvg2-common 2.36.4-2 pn lpr none pn ufraw-batch none pn zenity none Versions of packages geeqie suggests: pn geeqie-dbg none ii gimp 2.6.12-1+b2 ii libjpeg-progs 8d-1 pn ufraw none pn xpaint none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659832: Method using plain su found for Bug#659832
[BCC to everyone that seems involved, 12 extra addresses, and trying CC bug report too, just in case it works and the info can be stored for public reference] Hi, ow...@bugs.debian.org (2014-01-01 at 1730.21 +): [...] This time I had more luck when investigating alternatives... and I think I have the solution using su, no need of wrappers, just PAM. Probably also the reason sux is dead upstream and sux was pretty much a Debian issue. To /etc/pam.d/su add: ---8--- # Forward xauth keys between users if invoker is root or UID 1000 or higher session optional pam_xauth.so systemuser=999 ---8--- Proper change(s) so this stops biting so many people: - patch /etc/pam.d/su (login package), commented out or (preferably) active - patch su(1) man page (login package) - patch xauth(1) man page (xauth package) The man page changes should hint users towards pam_xauth(8), as it seems to be simpler and more in line with current methods. The su(1) doc talks about $XAUTHORITY and a general Other environments might be set by PAM modules, which is not what pam_xauth does (it generates keys as needed, while $XAUTHORITY from invoker could be an unreadable file). Worst case just the pam.d/su file should have the info/example, like it does for pam_wheel.so, pam_time.so or pam_limits.so, but I would like more docs being also updated, even with just small changes to SEE ALSO sections. Best would be enabled config and docs, so it works and no need of having luck when searching what is going on. So should 659832 be reopened and reassigned? New bug(s) opened against other packages so config and documentation finally solves the issue? GSR sux-solution.tgz Description: application/gtar-compressed
Bug#721878: libsvn1: outdated libsqlite dependency
Package: libsvn1 Version: 1.7.9-1+nmu4 Severity: normal After manually upgrading subversion package (and dependencies), svn commands report: ---8--- svn: E200029: Couldn't perform atomic initialization svn: E200030: SQLite compiled for 3.8.0.1, but running with 3.7.17 ---8--- Upgrading sqlite3 (which also upgraded libsqlite3-0 automatically) makes the commands work again, so it seems the libsvn1 package has outdated dependency information. Please investigate, thank you. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsvn1 depends on: ii libapr11.4.6-4 ii libaprutil11.5.2-1 ii libc6 2.17-92+b1 ii libdb5.1 5.1.29-6 ii libexpat1 2.1.0-3 ii libldap-2.4-2 2.4.31-1+nmu2 ii libneon27-gnutls 0.29.6-3 ii libsasl2-2 2.1.25.dfsg1-7 ii libserf1 1.1.0-2 ii libsqlite3-0 3.8.0.1-1 ii multiarch-support 2.17-5 ii zlib1g 1:1.2.8.dfsg-1 libsvn1 recommends no packages. libsvn1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707158: sawfish implemented a workaround
Package: iceweasel Version: 17.0.8esr-2 Severity: important Tags: patch Hi: Thanks to Robert Bihlmeyer Lionel Elie Mamane (see bug #711846) Debian's sawfish has a backport of the workaround for the window size, taken from latest SF. Firefox still has program specified maximum size: 1073741824 by 1073741824 set for their windows but SF became immune to those values. The patch that upstream does not want to apply to the ESR should fix problems in other software like olvwm. The other option seems to be installing FF/Iceweasel 23 from experimental. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707158: iceweasel: Absurd maximum window size causes issues with some window managers
Package: iceweasel Version: 17.0.5esr-1 Severity: important Tags: patch Hi: Iceweasel/Firefox has a serious issue related to asking for an absurdly big maximum image window. xprop reports 1073741824 by 1073741824 when X server seems to handle up to 32768 and other apps also assume this 16 bit limit. This means some window managers, like Sawfish, are unable to handle FF windows correctly, making it unusable. There is a report upstream which explains it and has a patch to limit the values to a more normal range. https://bugzilla.mozilla.org/show_bug.cgi?id=813997 Please, consider adding the patch to Debian packaging, as it seems it will not go into ESR, but Debian will use ESR for time to come. Thanks a lot. -- Addons package information ii iceweasel 17.0.5esr-1 amd64Web browser based on Firefox -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.7-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iceweasel depends on: ii debianutils 4.3.4 ii fontconfig 2.9.0-7.1 ii libc6 2.17-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libnspr42:4.9.6-1 ii libnspr4-0d 2:4.9.6-1 ii libsqlite3-03.7.16.2-1 ii libstdc++6 4.8.0-5 ii procps 1:3.3.6-1 ii xulrunner-17.0 17.0.5esr-1 iceweasel recommends no packages. Versions of packages iceweasel suggests: pn fonts-stix | otf-stix none ii libgssapi-krb5-2 1.10.1+dfsg-5 pn mozplugger none Versions of packages xulrunner-17.0 depends on: ii libasound21.0.25-4 ii libatk1.0-0 2.4.0-2 ii libbz2-1.01.0.6-4 ii libc6 2.17-1 ii libcairo2 1.12.14-2 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100.2-1 ii libevent-2.0-52.0.19-stable-3 ii libfontconfig12.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.8.0-5 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libhunspell-1.3-0 1.3.2-4 ii libjpeg8 8d-1 ii libmozjs17d 17.0.5esr-1 ii libnspr4 2:4.9.6-1 ii libnss3 2:3.14.3-1 ii libnss3-1d2:3.14.3-1 ii libpango1.0-0 1.30.0-1 ii libpixman-1-0 0.26.0-4 ii libsqlite3-0 3.7.16.2-1 ii libstartup-notification0 0.12-1 ii libstdc++64.8.0-5 ii libvpx1 1.1.0-1 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxrender1 1:0.9.7-1 ii libxt61:1.1.3-1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages xulrunner-17.0 suggests: pn libcanberra0 none pn libgnomeui-0 none -- no debconf information GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681027: openjpeg-tools: Requires gconf2 for no good reason
Package: openjpeg-tools Version: 1.3+dfsg-4.2 Severity: normal Dear Maintainer, up to 1.3+dfsg-4.1 this package did not require gconf2, it just provided a config file for it, in case it was avaliable. Now it requires installing gconf2 even if there is no app using it. See the 1.3+dfsg-4 list of files for example, the 10_openjpeg-tools is there too and goes fine with gconf2 listed as dependency: http://packages.debian.org/squeeze/amd64/openjpeg-tools/filelist Please consider dropping the dependency. Many programs are in similar situation, providing bash_completion config for example, but they do not require bash. Thanks. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.4-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659832: Workaround for sux
Hi: More info: jobs works ... but fg fails. So scratch what I said about things working. I also got bitten by cancelling programs and the console failing to print things properly, etc. It seems you can use a workaround, by using sux and su; just open a sux session to get the Xauth, and then use a su session to launch X apps and perform all other operations that would make the console go mad (there seems to be no Xauth clean up, so su can launch X). GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662895: i8042: keys get stuck and keyboard stops responding
Hi, jrnie...@gmail.com (2012-03-17 at 2018.23 -0500): And now I can confirm it happens with with 2.6.32-5-amd64 too, in less than 4 hours (pretty much like with 3.2 and 3.3). The interrupts file is from the moment after it hung. If you really need a version just after boot up, please tell me so I can boot it up again, I had my mind busy and forgot about capturing it then. GSR CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0:2798575 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 36707 0 0 0 0 0 0 0 IO-APIC-edge i8042 8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc0 9: 151887 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi 16: 81 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 17: 21 0 0 0 0 0 0 0 IO-APIC-fasteoi HDA Intel 18: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ahci 19:215 0 0 0 0 0 0 0 IO-APIC-fasteoi pata_jmicron, firewire_ohci 22: 632131 0 0 0 0 0 0 0 IO-APIC-fasteoi HDA Intel 23: 82539 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2 24:1625677 0 0 0 0 0 0 0 HPET_MSI-edge hpet2 25: 01679644 0 0 0 0 0 0 HPET_MSI-edge hpet3 26: 0 0 857256 0 0 0 0 0 HPET_MSI-edge hpet4 27: 0 0 0 552478 0 0 0 0 HPET_MSI-edge hpet5 28: 0 0 0 01392446 0 0 0 HPET_MSI-edge hpet6 35: 656967 0 0 0 0 0 0 0 PCI-MSI-edge eth0 36: 67154 0 0 0 0 0 0 0 PCI-MSI-edge ahci NMI: 0 0 0 0 0 0 0 0 Non-maskable interrupts LOC:1801811551291031240775 1122810 494149 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 0 0 0 0 Performance pending work RES: 3451 1784843528 4525 1394 360559 Rescheduling interrupts CAL: 24 79 77 79 75 77 79 76 Function call interrupts TLB: 18750 21857 9305 6839 23871 16879 9929 6667 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 47 47 47 47 47 47 47 47 Machine check polls ERR: 0 MIS: 0
Bug#662895: i8042: keys get stuck and keyboard stops responding
Hi, jrnie...@gmail.com (2012-03-17 at 2018.23 -0500): [...] So far no issues after 3 sessions with the asus_atk0110 module blacklisted. Probably I will try 2.6.32 now and see if the hangs happen then. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662895: Workaround found to recover the kbd after it dies
Hi, more information: After searching some more and finding I am not alone with respect to stuck keyboard, I also found that someone suggests (in https://bugzilla.redhat.com/show_bug.cgi?id=676446 ) to invoke echo -n reconnect /sys/devices/platform/i8042/serio0/drvctl and so far it seems to recover the keyboard, even if the logs are not the same (symptoms are: stuck key and the rest of keys do nothing). Just a workaround, but at least this means no full reboot needed, just ssh from another machine or some kind of automatic triggering. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663024: procps: 'w' not listing users in VTs
Package: procps Version: 1:3.3.2-3 Severity: normal Dear Maintainer, w.procps lists users in pts/# terminals (X11 terminal, remote logins, etc) but not in tty# ones. last -xa has no problem showing the logins, so the records are kept correctly. No idea why w ignores VTs, I think it listed them until recently, but I am unable to point the exact date. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages procps depends on: ii initscripts 2.88dsf-22 ii libc6 2.13-27 ii libncurses5 5.9-4 ii libncursesw5 5.9-4 ii libprocps01:3.3.2-3 ii libtinfo5 5.9-4 ii lsb-base 3.2+Debian30 Versions of packages procps recommends: ii psmisc 22.16-1 procps suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659832: sux: bash prints ioctl warnings
Package: sux Version: 1.0.1-6 Severity: normal Hi: After updating to the new login package, when invoking sux the following bash warnings are printed every time: ---8--- user1$ /usr/bin/sux - user2 Password: bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell user2$ ---8--- Things seem to work anyway, commands can be launched, shell's jobs shows running jobs and so on. Maybe this is related to Debian report #628843 but invoking su instead of sux generates no warnings, so it must be something specific to sux. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash sux depends on no packages. Versions of packages sux recommends: ii xauth 1:1.0.6-1 sux suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599680: blender: crashes with: illegal hardware instruction
Package: blender Followup-For: Bug #599680 Ooops, it crashes, same issue as before: ---8--- Program received signal SIGILL, Illegal instruction. 0x08bd903e in RNA_def_property_range () (gdb) bt full #0 0x08bd903e in RNA_def_property_range () No symbol table info available. #1 0x08bdd440 in RNA_def_int () No symbol table info available. #2 0x0832a012 in WM_operator_properties_filesel () No symbol table info available. #3 0x0832a5e8 in ?? () No symbol table info available. #4 0x08328ca4 in WM_operatortype_append () No symbol table info available. #5 0x0832ca39 in wm_operatortype_init () No symbol table info available. #6 0x08320823 in WM_init () No symbol table info available. #7 0x0830e8e7 in main () No symbol table info available. (gdb) disassemble Dump of assembler code for function RNA_def_property_range: ... 0x08bd9038 +136: fxch %st(1) 0x08bd903a +138: fstpl 0x20(%esp) = 0x08bd903e +142: cvttsd2si 0x20(%esp),%ecx 0x08bd9044 +148: mov%ecx,0x7c(%eax) 0x08bd9047 +151: fstpl 0x20(%esp) 0x08bd904b +155: cvttsd2si 0x20(%esp),%edx ---8--- -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages blender depends on: ii libavcodec53 5:0.9.1-0.0 ii libavdevice53 5:0.9.1-0.0 ii libavformat53 5:0.9.1-0.0 ii libavutil51 5:0.9.1-0.0 ii libc6 2.13-24 ii libfftw3-33.3-1 ii libfreetype6 2.4.8-1 ii libgcc1 1:4.6.2-11 ii libgl1-mesa-glx [libgl1] 7.11.2-1 ii libglew1.61.6.0-4 ii libglu1-mesa [libglu1]7.11.2-1 ii libgomp1 4.6.2-11 ii libilmbase6 1.0.1-3 ii libjack-jackd2-0 [libjack-0.116] 1.9.8~dfsg.1-1 ii libjpeg8 8c-2 ii libopenal11:1.13-4 ii libopenexr6 1.6.1-4.1 ii libopenjpeg2 1.3+dfsg-4 ii libpng12-01.2.46-4 ii libpython3.2 3.2.2-4 ii libsdl1.2debian 1.2.14-7 ii libsndfile1 1.0.25-4 ii libstdc++64.6.2-11 ii libswscale2 5:0.9.1-0.0 ii libtiff4 3.9.5-2 ii libx11-6 2:1.4.4-4 ii libxi62:1.4.5-1 ii python3.2 3.2.2-4 ii ttf-dejavu2.33-2 ii zlib1g1:1.2.3.4.dfsg-3 blender recommends no packages. Versions of packages blender suggests: pn yafaray none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630327: spamassassin: Examinining mails causes lots of goto warnings
Package: spamassassin Version: 3.3.1-2 Severity: normal For every mail that SA checks, it generates a line like: Jun 1 02:33:51.411 [2759] warn: Use of goto to jump into a construct is deprecated at /usr/share/perl5/Mail/SpamAssassin/Plugin/Check.pm line 409. which are filing the log (fetchmail, procmail setup) with noise. And at some point, will become an error instead of just a warning. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages spamassassin depends on: pn libarchive-tar-perl none (no description available) ii libdigest-sha1-perl 2.13-1+b1NIST SHA-1 message digest algorith ii libhtml-parser-perl 3.68-1+b1collection of modules that parse H ii libnet-dns-perl 0.66-2+b1Perform DNS queries from a Perl sc ii libnetaddr-ip-perl 4.044+dfsg-1 IP address manipulation module ii libsocket6-perl 0.23-1+b1Perl extensions for IPv6 ii libsys-hostname-long-perl 1.4-2Figure out the long (fully-qualifi ii libwww-perl 6.02-1 simple and consistent interface to ii perl5.12.3-7 Larry Wall's Practical Extraction ii perl-modules [libio-zlib-pe 5.12.3-7 Core Perl modules Versions of packages spamassassin recommends: ii gcc 4:4.6.0-5 The GNU C compiler ii gnupg 1.4.11-3 GNU privacy guard - a free PGP rep ii libc6-dev 2.13-6 Embedded GNU C Library: Developmen pn libio-socket-inet6-perl none (no description available) pn libmail-spf-perl none (no description available) ii make 3.81-8.1 An utility for Directing compilati ii perl [libsys-syslog-perl] 5.12.3-7 Larry Wall's Practical Extraction pn re2c none (no description available) pn spamc none (no description available) Versions of packages spamassassin suggests: ii libcompress-zlib-perl 2.035-1Transitional dummy package for Com ii libdbi-perl 1.616-1+b1 Perl Database Interface (DBI) ii libio-compress-perl [libcompr 2.035-1bundle of IO::Compress modules ii libio-socket-ssl-perl 1.43-1 Perl module implementing object or pn libmail-dkim-perl none (no description available) pn libnet-ident-perl none (no description available) ii perl [libcompress-zlib-perl] 5.12.3-7 Larry Wall's Practical Extraction pn pyzor none (no description available) pn razor none (no description available) -- debconf information: spamassassin/upgrade/2.40: spamassassin/upgrade/2.40w: spamassassin/upgrade/cancel: Continue spamassassin/upgrade/2.42m: No spamassassin/upgrade/2.42u: No -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587650: git-svn: copes poorly with .git/svn dir from older perl
Package: git-svn Version: 1:1.7.5.1-1 Followup-For: Bug #587650 Perl Git were updated recently (lots of updates going on in Sid), and that seems to have caused a similar issue, end of import failed with: ---8--- Byte order is not compatible at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 380, at /usr/share/perl/5.12.3/Memoize/Storable.pm line 21 Could not unmemoize function `lookup_svn_merge', because it was not memoized to begin with at /usr/lib/git-core/git-svn line 3213 END failed--call queue aborted at /usr/lib/git-core/git-svn line 40. ---8--- Moving away the .caches dir made the import work again. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-svn depends on: ii git 1:1.7.5.1-1 fast, scalable, distributed revisi ii libsvn-perl 1.6.16dfsg-1+b2 Perl bindings for Subversion ii libterm-readkey-perl 2.30-4+b1 A perl module for simple terminal ii libwww-perl 6.01-3 simple and consistent interface to git-svn recommends no packages. Versions of packages git-svn suggests: pn git-doc none (no description available) ii subversion 1.6.16dfsg-1+b2 Advanced version control system -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624734: apt-file unable to find Index file, and thus downloads full .gz file
Package: apt-file Version: 2.4.2 Severity: normal When running apt-file update lots of lines like the following appear, one per entry in sources.list: ---8--- Downloading Index http://ftp.fi.debian.org/debian/dists/unstable/Contents-i386.diff/Index: No Index available. Downloading complete file http://ftp.fi.debian.org/debian/dists/unstable/Contents-i386.gz ---8--- So it proceeds to get the full .gz, which normally is 10-20MB, instead of the diff ones. The following URIs exist and the two .gz ones have the same md5sum: http://ftp.fi.debian.org/debian/dists/unstable/Contents-i386.gz http://ftp.fi.debian.org/debian/dists/unstable/main/Contents-i386.gz http://ftp.fi.debian.org/debian/dists/unstable/main/Contents-i386.diff/Index Thus for whatever reason, apt-file is missing the existence of the subdir, which would reduce server bandwith, and make everything faster. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-file depends on: ii curl 7.21.6-1 Get a file from an HTTP, HTTPS or ii libapt-pkg-perl 0.1.24+b1 Perl interface to libapt-pkg ii libconfig-file-perl 1.50-2 Parses simple configuration files ii liblist-moreutils-perl0.25~02-1 Perl module with additional list f ii libregexp-assemble-perl 0.34-6 Assemble multiple Regular Expressi ii perl 5.10.1-20 Larry Wall's Practical Extraction ii perl-modules [libfile-temp-pe 5.10.1-20 Core Perl modules Versions of packages apt-file recommends: ii python-apt 0.7.100.3+b1 Python interface to libapt-pkg Versions of packages apt-file suggests: ii openssh-client1:5.8p1-4 secure shell (SSH) client, for sec pn sudo none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621898: i2c-tools: Upgrade problem still happens
Package: i2c-tools Version: 3.0.3-3 Followup-For: Bug #621898 While upgrading to 3.0.3-3, the MAKEDEV error is avoided, but then fails in something else: ---8--- Setting up i2c-tools (3.0.3-3) ... .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation. chmod: cannot access `/dev/i2c-0': No such file or directory dpkg: error processing i2c-tools (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: i2c-tools E: Sub-process /usr/bin/dpkg returned an error code (1) ---8--- -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages i2c-tools depends on: ii adduser 3.112+nmu2 add and remove users and groups ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii makedev 2.3.1-89 creates device files in /dev ii perl 5.10.1-19 Larry Wall's Practical Extraction ii udev 167-1 /dev/ and hotplug management daemo i2c-tools recommends no packages. Versions of packages i2c-tools suggests: pn libi2c-devnone (no description available) pn python-smbus none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621898: i2c-tools: Upgrade problem still happens
Hi, aurel...@aurel32.net (2011-04-10 at 2354.59 +0200): On Sun, Apr 10, 2011 at 10:56:53PM +0200, GSR wrote: Package: i2c-tools Version: 3.0.3-3 Followup-For: Bug #621898 While upgrading to 3.0.3-3, the MAKEDEV error is avoided, but then fails in something else: ---8--- Setting up i2c-tools (3.0.3-3) ... .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation. chmod: cannot access `/dev/i2c-0': No such file or directory dpkg: error processing i2c-tools (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: i2c-tools E: Sub-process /usr/bin/dpkg returned an error code (1) Yes, this is because you don't have any i2c devices. Fixed in 3.0.3-4. Nothing in /dev, but there are i2c devices in the system: ---8--- ls -l /sys/bus/i2c/devices/ total 0 lrwxrwxrwx 1 root root 0 Apr 11 01:11 0-004c - ../../../devices/pci:00/:00:11.0/i2c-0/0-004c/ lrwxrwxrwx 1 root root 0 Apr 11 01:11 i2c-0 - ../../../devices/pci:00/:00:11.0/i2c-0/ lrwxrwxrwx 1 root root 0 Apr 11 01:11 i2c-1 - ../../../devices/i2c-1/ lrwxrwxrwx 1 root root 0 Apr 11 01:11 i2c-2 - ../../../devices/i2c-2/ lrwxrwxrwx 1 root root 0 Apr 11 01:11 i2c-3 - ../../../devices/i2c-3/ lrwxrwxrwx 1 root root 0 Apr 11 01:11 i2c-4 - ../../../devices/i2c-4/ ---8--- GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613137: xserver-xorg-video-radeon: no video signal or kbd after manually launching X
Hi, jcris...@debian.org (2011-02-13 at 1104.39 +0100): back, the screen shows the bg (or maybe it was left from previous run) and then monitor goes into sleep immediately, ignoring kbd as original report. You should probably trim your xorg.conf down to just monitor sections to stop other stuff interfering... Spliting it into files inside xorg.conf.d/ and playing renaming game (easier to move foo.conf to foo.conf- to see what part is wrong) I found the problem of the black screen, but also issues with how things are done with outputs and config. Maybe worth new bugs? The problem line was 'FontPath unix/:7100' XFS is running, but seems that having that line in the conf makes it go nuts in unrelated ways. The left issues are: System sees an inexistant monitor on VGA connector. The cable is there, but the monitor is off and not responding (otherwise it would had seen valid vendor name, etc via DDC, right?). Even so, the system insists in giving it some random settings and keep the output fully enabled. Once that monitor is configured via .conf file(s) with better Modelines than DDC ever provided, it keeps the output enabled even when the config has 'Option Enable false'. At least xrandr keeps the modelines right. Set DVI-0 to be primary wihth 'Option Primary true', but that one is ignored and VGA is still enabled. It is trully obsessed with having that output even if not needed and told to forget about it for now. ;] Workaround is to issue xrandr --output VGA-0 --off in ~/.xsession, so apps do not get confused with false overlapping monitors (maximize, etc). I guess this bug can be closed. Thanks for the help. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607510: Suggestion about slow radeon, debian bug 607510
Hi, daen...@debian.org (2011-02-11 at 1035.03 +0100): On Fre, 2011-02-11 at 05:54 +0100, GSR wrote: Could you check MigrationHeuristic setting? And try with greedy? This option doesn't have any effect with current upstream xserver and KMS, and even with older xservers where it accidentally had an effect, it's probably better to use the radeon driver option EXAPixmaps off if you want to prevent acceleration on all pixmaps other than the visible screen. Might be worth trying the current X server and driver in sid first though to see if they're doing better. With KMS 6.13.1-2+squeeze1 (Sid has 6.13.2-2, update scheduled in some days) removing MigrationHeuristic from xorg.conf gives acceptable speed, same than with it. So at some point in the past, the issue that required greedy was solved. The obvious test was 5 sec canvas refreshes in GIMP when repositioning the content. Thanks for the tip. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607510: Suggestion about slow radeon, debian bug 607510
Hi: Could you check MigrationHeuristic setting? And try with greedy? ---8--- Section Device ... Driver radeon ... # Option MigrationHeuristic smart # Near as slow as with default/always http://nouveau.freedesktop.org/wiki/EXA Option MigrationHeuristic greedy # Fast as XAA, X.Org X Server 1.6.5, 2009-10-29 http://lists.freedesktop.org/archives/xorg/2008-May/thread.html#35451 ... EndSection ---8--- GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607751: snort: Update gives current Snort configuration is invalid error and it will not start
Package: snort Version: 2.8.5.2-3 Severity: grave Justification: renders package unusable After updating and with default configuration files the following happens: ---8--- Configuring snort-common Configuration error The current Snort configuration is invalid and will prevent Snort starting up normally. Please review and correct it. To diagnose an error in a Snort configuration file, use '/usr/sbin/snort -T -c file'. Setting up snort (2.8.5.2-3) ... Stopping Network Intrusion Detection System : snortNo running snort instance found ... (warning). Starting Network Intrusion Detection System : snort (eth0 using /etc/snort/snort.conf ...ERROR: failed (check /var/log/daemon.log, /var/log/syslog and /var/log/snort/)) failed! invoke-rc.d: initscript snort, action start failed. dpkg: error processing snort (--configure): subprocess installed post-installation script returned error exit status 1 Setting up libva1 (1.0.4-1.3) ... configured to not write apport reports Errors were encountered while processing: snort E: Sub-process /usr/bin/dpkg returned an error code (1) ---8--- Trying the command to check the config gives: ---8--- # /usr/sbin/snort -T -c /etc/snort/snort.conf Running in Test mode --== Initializing Snort ==-- Initializing Output Plugins! Initializing Preprocessors! Initializing Plug-ins! Parsing Rules file /etc/snort/snort.conf PortVar 'HTTP_PORTS' defined : [ 80 ] PortVar 'SHELLCODE_PORTS' defined : [ 0:79 81:65535 ] PortVar 'ORACLE_PORTS' defined : [ 1521 ] PortVar 'FTP_PORTS' defined : [ 21 ] Tagged Packet Limit: 256 Loading dynamic engine /usr/lib/snort_dynamicengine/libsf_engine.so... done Loading all dynamic preprocessor libs from /usr/lib/snort_dynamicpreprocessor/... Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//libsf_ssl_preproc.so... done Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//libsf_dns_preproc.so... done Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//lib_sfdynamic_preprocessor_example.so... done Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//libsf_smtp_preproc.so... done Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//libsf_ssh_preproc.so... done Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//libsf_dce2_preproc.so... done Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//libsf_ftptelnet_preproc.so... done Loading dynamic preprocessor library /usr/lib/snort_dynamicpreprocessor//libsf_dcerpc_preproc.so... done Finished Loading all dynamic preprocessor libs from /usr/lib/snort_dynamicpreprocessor/ Frag3 global config: Max frags: 65536 Fragment memory cap: 4194304 bytes Frag3 engine config: Target-based policy: FIRST Fragment timeout: 60 seconds Fragment min_ttl: 1 Fragment Problems: 1 Overlap Limit: 10 Min fragment Length: 0 Stream5 global config: Track TCP sessions: ACTIVE Max TCP sessions: 8192 Memcap (for reassembly packet storage): 8388608 Track UDP sessions: INACTIVE Track ICMP sessions: INACTIVE Log info if session memory consumption exceeds 1048576 Stream5 TCP Policy config: Reassembly Policy: FIRST Timeout: 30 seconds Min ttl: 1 Maximum number of bytes to queue per session: 1048576 Maximum number of segs to queue per session: 2621 Reassembly Ports: 21 client (Footprint) 23 client (Footprint) 25 client (Footprint) 42 client (Footprint) 53 client (Footprint) 80 client (Footprint) 110 client (Footprint) 111 client (Footprint) 135 client (Footprint) 136 client (Footprint) 137 client (Footprint) 139 client (Footprint) 143 client (Footprint) 445 client (Footprint) 513 client (Footprint) 514 client (Footprint) 1433 client (Footprint) 1521 client (Footprint) 2401 client (Footprint) 3306 client (Footprint) HttpInspect Config: GLOBAL CONFIG Max Pipeline Requests:0 Inspection Type: STATELESS Detect Proxy Usage: NO IIS Unicode Map Filename: /etc/snort/unicode.map IIS Unicode Map Codepage: 1252 DEFAULT SERVER CONFIG: Server profile: All Ports: 80 8080 8180 Server Flow Depth: 300 Client Flow Depth: 300 Max Chunk Length: 50 Max Header Field Length: 0 Max Number Header Fields: 0 Inspect Pipeline Requests: YES URI Discovery Strict Mode: NO Allow Proxy Usage: NO Disable Alerting: NO Oversize Dir Length: 500 Only inspect URI: NO Normalize HTTP Headers: NO Normalize HTTP Cookies: NO Ascii: YES alert: NO Double Decoding: YES alert: YES %U Encoding: YES alert: YES Bare Byte: YES alert: YES Base36:
Bug#607751: Updating other software gets snort running again
Hi: Updating other (unrelated?) software got it running with the following: ---8--- Reading package lists... Done Building dependency tree... 0% Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: dbus dbus-x11 libdbus-1-3 libdbus-1-dev libtalloc-dev libtalloc2 6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0 B/665 kB of archives. After this operation, 32.8 kB of additional disk space will be used. Reading package fields... Done Reading package status... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done (Reading database ... 147181 files and directories currently installed.) Preparing to replace dbus-x11 1.2.24-3 (using .../dbus-x11_1.2.24-4_i386.deb) ... Unpacking replacement dbus-x11 ... Preparing to replace libdbus-1-dev 1.2.24-3 (using .../libdbus-1-dev_1.2.24-4_i386.deb) ... Unpacking replacement libdbus-1-dev ... Preparing to replace libdbus-1-3 1.2.24-3 (using .../libdbus-1-3_1.2.24-4_i386.deb) ... Unpacking replacement libdbus-1-3 ... Preparing to replace dbus 1.2.24-3 (using .../dbus_1.2.24-4_i386.deb) ... Unpacking replacement dbus ... Preparing to replace libtalloc-dev 2.0.1-1 (using .../libtalloc-dev_2.0.4-1_i386.deb) ... Unpacking replacement libtalloc-dev ... Preparing to replace libtalloc2 2.0.1-1 (using .../libtalloc2_2.0.4-1_i386.deb) ... Unpacking replacement libtalloc2 ... Processing triggers for man-db ... Setting up snort (2.8.5.2-3) ... Stopping Network Intrusion Detection System : snortNo running snort instance found ... (warning). Starting Network Intrusion Detection System : snort (eth0 using /etc/snort/snort.conf ...done). Setting up libdbus-1-3 (1.2.24-4) ... Setting up dbus (1.2.24-4) ... Reloading system message bus config...done. system message bus already started; not starting.. Setting up dbus-x11 (1.2.24-4) ... Setting up libdbus-1-dev (1.2.24-4) ... Setting up libtalloc2 (2.0.4-1) ... Setting up libtalloc-dev (2.0.4-1) ... ---8--- No idea why the config is now valid. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588287: linux-image-2.6.34-1-686: Heavy disk activity triggers a warn_slowpath_common at fs-writeback.c:589
Hi, b...@decadent.org.uk (2010-07-07 at 0017.43 +0100): On Tue, 2010-07-06 at 23:47 +0200, GSR wrote: Package: linux-2.6 Version: 2.6.34-1~experimental.1 Severity: normal When the disk system is used heavily, for example installing software or writing a big file, a warning is reported. It happens multiple times in a short time, I trimmed the report below to show the first and second warnings only (third etc were like second). The report is always about fs-writeback.c:589. I think this was fixed in 2.6.34-1~experimental.2; please check. I think it has been checked enough, no more errors in logs, even with some heavy disk activity, so probably time to close the report. Thanks and sorry for the noise. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588287: linux-image-2.6.34-1-686: Heavy disk activity triggers a warn_slowpath_common at fs-writeback.c:589
Hi, b...@decadent.org.uk (2010-07-07 at 0017.43 +0100): On Tue, 2010-07-06 at 23:47 +0200, GSR wrote: Package: linux-2.6 Version: 2.6.34-1~experimental.1 Severity: normal When the disk system is used heavily, for example installing software or writing a big file, a warning is reported. It happens multiple times in a short time, I trimmed the report below to show the first and second warnings only (third etc were like second). The report is always about fs-writeback.c:589. I think this was fixed in 2.6.34-1~experimental.2; please check. Thanks for the info, updates were ignoring .2 due to dependencies. Now it is installed, we will see what happens in next days. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588287: linux-image-2.6.34-1-686: Heavy disk activity triggers a warn_slowpath_common at fs-writeback.c:589
Package: linux-2.6 Version: 2.6.34-1~experimental.1 Severity: normal When the disk system is used heavily, for example installing software or writing a big file, a warning is reported. It happens multiple times in a short time, I trimmed the report below to show the first and second warnings only (third etc were like second). The report is always about fs-writeback.c:589. -- Package-specific info: ** Version: Linux version 2.6.34-1-686 (Debian 2.6.34-1~experimental.1) (m...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-10) ) #1 SMP Thu May 20 12:14:21 UTC 2010 ** Command line: root=/dev/md0 ro rootdelay=10 ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 447.097950] [drm] Loading R300 Microcode [ 447.098643] platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin [ 447.134165] [drm] Num pipes: 1 [ 447.134175] [drm] writeback test succeeded in 1 usecs [ 484.973729] EXT3-fs (sdd8): using internal journal [ 5963.212493] [ cut here ] [ 5963.212513] WARNING: at /build/buildd-linux-2.6_2.6.34-1~experimental.1-i386-8CcrsV/linux-2.6-2.6.34/debian/build/source_i386_none/fs/fs-writeback.c:589 writeback_inodes_wb+0x236/0x4b3() [ 5963.212519] Hardware name: [ 5963.212521] Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit inet_diag sco bridge stp bnep rfcomm l2cap crc16 bluetooth rfkill ext2 brd fuse lm90 it87 hwmon_vid snd_ca0106 snd_ac97_codec snd_wavefront snd_cs4236 ac97_bus snd_pcm_oss snd_wss_lib snd_mixer_oss snd_pcm snd_opl3_lib snd_hwdep snd_mpu401 snd_mpu401_uart via_ircc snd_seq_midi irda snd_rawmidi snd_seq_midi_event snd_seq crc_ccitt snd_timer snd_seq_device tpm_tis joydev i2c_viapro snd tpm parport_pc tpm_bios shpchp pcspkr soundcore emu10k1_gp parport processor button evdev ns558 snd_page_alloc i2c_core gameport pci_hotplug ext3 jbd mbcache raid1 md_mod sg usbhid hid sr_mod cdrom sd_mod crc_t10dif ata_generic pata_via uhci_hcd libata aic79xx thermal firewire_ohci scsi_transport_spi ehci_hcd 3c59x floppy thermal_sys firewire_core crc_itu_t usbcore nls_base mii scsi_mod [last unloaded: scsi_wait_scan] [ 5963.212617] Pid: 3143, comm: flush-9:3 Not tainted 2.6.34-1-686 #1 [ 5963.212620] Call Trace: [ 5963.212632] [c10302d5] ? warn_slowpath_common+0x5e/0x8a [ 5963.212636] [c103030b] ? warn_slowpath_null+0xa/0xc [ 5963.212641] [c10caa4d] ? writeback_inodes_wb+0x236/0x4b3 [ 5963.212645] [c10cae20] ? wb_writeback+0x156/0x1bd [ 5963.212649] [c10caf72] ? wb_do_writeback+0x68/0x12c [ 5963.212654] [c103ac06] ? process_timeout+0x0/0x5 [ 5963.212659] [c10cb057] ? bdi_writeback_task+0x21/0x7d [ 5963.212665] [c1098966] ? bdi_start_fn+0x59/0xa3 [ 5963.212669] [c109890d] ? bdi_start_fn+0x0/0xa3 [ 5963.212676] [c1044111] ? kthread+0x61/0x66 [ 5963.212680] [c10440b0] ? kthread+0x0/0x66 [ 5963.212686] [c100353e] ? kernel_thread_helper+0x6/0x10 [ 5963.212689] ---[ end trace 5d7f5efb0eeaafa8 ]--- [ 5998.292571] [ cut here ] [ 5998.292591] WARNING: at /build/buildd-linux-2.6_2.6.34-1~experimental.1-i386-8CcrsV/linux-2.6-2.6.34/debian/build/source_i386_none/fs/fs-writeback.c:589 writeback_inodes_wb+0x236/0x4b3() [ 5998.292596] Hardware name: [ 5998.292598] Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit inet_diag sco bridge stp bnep rfcomm l2cap crc16 bluetooth rfkill ext2 brd fuse lm90 it87 hwmon_vid snd_ca0106 snd_ac97_codec snd_wavefront snd_cs4236 ac97_bus snd_pcm_oss snd_wss_lib snd_mixer_oss snd_pcm snd_opl3_lib snd_hwdep snd_mpu401 snd_mpu401_uart via_ircc snd_seq_midi irda snd_rawmidi snd_seq_midi_event snd_seq crc_ccitt snd_timer snd_seq_device tpm_tis joydev i2c_viapro snd tpm parport_pc tpm_bios shpchp pcspkr soundcore emu10k1_gp parport processor button evdev ns558 snd_page_alloc i2c_core gameport pci_hotplug ext3 jbd mbcache raid1 md_mod sg usbhid hid sr_mod cdrom sd_mod crc_t10dif ata_generic pata_via uhci_hcd libata aic79xx thermal firewire_ohci scsi_transport_spi ehci_hcd 3c59x floppy thermal_sys firewire_core crc_itu_t usbcore nls_base mii scsi_mod [last unloaded: scsi_wait_scan] [ 5998.292684] Pid: 3143, comm: flush-9:3 Tainted: GW 2.6.34-1-686 #1 [ 5998.292687] Call Trace: [ 5998.292699] [c10302d5] ? warn_slowpath_common+0x5e/0x8a [ 5998.292704] [c103030b] ? warn_slowpath_null+0xa/0xc [ 5998.292708] [c10caa4d] ? writeback_inodes_wb+0x236/0x4b3 [ 5998.292712] [c10cae20] ? wb_writeback+0x156/0x1bd [ 5998.292716] [c10caf72] ? wb_do_writeback+0x68/0x12c [ 5998.292722] [c103ac06] ? process_timeout+0x0/0x5 [ 5998.292726] [c10cb057] ? bdi_writeback_task+0x21/0x7d [ 5998.292732] [c1098966] ? bdi_start_fn+0x59/0xa3 [ 5998.292736] [c109890d] ? bdi_start_fn+0x0/0xa3 [ 5998.292744] [c1044111] ? kthread+0x61/0x66 [ 5998.292748] [c10440b0] ? kthread+0x0/0x66 [ 5998.292754] [c100353e] ? kernel_thread_helper+0x6/0x10 [ 5998.292757] ---[ end trace 5d7f5efb0eeaafa9 ]--- ** Model information not available ** Loaded modules: Module Size Used by
Bug#586058: geeqie: Crash as soon as it loads an image
Package: geeqie
Version: 1:1.0-3
Severity: grave
Justification: renders package unusable
A soon as I click in one image, it crashes. Backtrace shows:
#0 0xb714360f in Exiv2::Exifdatum::Exifdatum(Exiv2::Exifdatum const) ()
from /usr/lib/libexiv2.so.6
No symbol table info available.
#1 0x08095af2 in std::listExiv2::Exifdatum, std::allocatorExiv2::Exifdatum
::operator=(std::listExiv2::Exifdatum, std::allocatorExiv2::Exifdatum
const) ()
No symbol table info available.
#2 0x0809322d in ?? ()
No symbol table info available.
#3 0x080916b7 in ?? ()
No symbol table info available.
#4 0x080a48c3 in ?? ()
No symbol table info available.
#5 0x080a58cb in ?? ()
No symbol table info available.
#6 0x080a39ed in ?? ()
No symbol table info available.
#7 0x080a3e6f in ?? ()
No symbol table info available.
#8 0x080b4613 in ?? ()
No symbol table info available.
#9 0x080b47ca in ?? ()
No symbol table info available.
---Type return to continue, or q return to quit---
#10 0x080b48f0 in ?? ()
No symbol table info available.
#11 0x080b4e94 in ?? ()
No symbol table info available.
#12 0xb73ae328 in g_cclosure_marshal_VOID__BOXED ()
from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#13 0xb73a1142 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#14 0xb73b762d in ?? () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#15 0xb73b8c04 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#16 0xb73b9086 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#17 0x080d4363 in ?? ()
No symbol table info available.
#18 0xb7603e24 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#19 0xb73a1142 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#20 0xb73b762d in ?? () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#21 0xb73b8a83 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#22 0xb73b9086 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#23 0xb77301c6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#24 0xb75fc47d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#25 0xb75fd807 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#26 0xb7486dda in ?? () from /usr/lib/libgdk-x11-2.0.so.0
No symbol table info available.
#27 0xb73022f5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
No symbol table info available.
#28 0xb7305fd8 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#29 0xb7306517 in g_main_loop_run () from /lib/libglib-2.0.so.0
No symbol table info available.
#30 0xb75fddc9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#31 0x080bcd2c in ?? ()
No symbol table info available.
#32 0xb6e5ac76 in __libc_start_main (main=0x80bc580, argc=1,
ubp_av=0xbffc2254, init=0x810f380, fini=0x810f370,
rtld_fini=0xb78c20d0 _dl_fini, stack_end=0xbffc224c) at libc-start.c:228
result = value optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1225232396, 0, 0,
-1073995224, -1524350688, -1774233806}, mask_was_saved = 0}},
priv = {pad = {0x0, 0x0, 0x1, 0x805ad40}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 1}}}
not_first_call = value optimized out
#33 0x0805ad61 in ?? ()
No symbol table info available.
Downgrading libexiv2-6 to 0.19-1 does not help, I have to downgrade
geeqie and geeqie-common to 1:1.0-2 too.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.34-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages geeqie depends on:
ii geeqie-common 1:1.0-3 data files for Geeqie
ii libc6 2.11.2-1 Embedded GNU C Library: Shared lib
ii libexiv2-6 0.19-3 EXIF/IPTC metadata manipulation li
ii libgcc1 1:4.4.4-5GCC support library
ii libglib2.0-02.24.1-1 The GLib library of C routines
ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface
ii liblcms11.18.dfsg-1.2+b1 Color management library
ii liblircclient0 0.8.3-5 infra-red remote control support -
ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio
ii libstdc++6 4.4.4-5 The GNU Standard C++ Library v3
Versions of packages geeqie recommends:
pn exiftran none (no description available)
ii exiv20.19-3 EXIF/IPTC metadata
Bug#580825: mdadm: Exit code 1 when running checkarray
Package: mdadm Version: 3.1.1-1 Severity: normal Tags: patch Hi: I got the same email. But I think I understand why it does that and have a fix so it stops causing false alarms. It happens because the cron command tries to run once per month, but only the first sunday should checks be performed. So the second test in pipeline fails around 3 weeks per month, ending the pipe with error, when in reality that error is not a problem. Plausible fix: [ -x /usr/share/mdadm/checkarray ] [ $(date +\%d) -gt 7 ] || /usr/share/mdadm/checkarray --cron --all --quiet This checks for command availability (as before) and then checks if day is not in 1-7 (le becomes gt), so for 8 and after it will stop there with exit code 0 (cron is happy). If that fails ( becomes ||) it executes the check and cron gets whatever error code the vital command returns. Hope this helps. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576845: initramfs-tools: Forgets to add mdadm and related scripts
Package: initramfs-tools Version: 0.94.1 Severity: important Tags: sid Last update to initrd.img left the system unbootable due to lack of sbin/mdadm and scripts/local-top/mdadm (even scripts/local-top/ is missing), as checked by manual inspection with zcat -d /boot/initrd.img-... | cpio -i. Currently I am booting thanks to initrd backups. I looked at other bugs and found a suggestion to install lvm2 (I do not use it, RAID here is plain /dev/md*, but nothing to lose...), then local-top was added to the initrd, with lvm2 in it, but still no trace of mdadm. -- Package-specific info: -- /proc/cmdline root=/dev/md0 ro rootdelay=10 -- /proc/filesystems ext3 fuseblk ext2 -- lsmod Module Size Used by dm_mod 46074 0 radeon398727 2 ttm26172 1 radeon drm_kms_helper 17247 1 radeon drm 107671 5 radeon,ttm,drm_kms_helper i2c_algo_bit3497 1 radeon sco 5837 2 bridge 32983 0 stp 996 1 bridge bnep7444 2 rfcomm 25131 0 l2cap 21677 6 bnep,rfcomm crc16 1027 1 l2cap bluetooth 36327 6 sco,bnep,rfcomm,l2cap rfkill 10260 2 bluetooth inet_diag 5930 1 ext2 46289 1 brd 2984 1 fuse 43750 1 lm907728 0 it87 11447 0 hwmon_vid 1528 1 it87 snd_cs4236 21379 0 snd_wavefront 24702 0 snd_wss_lib16653 2 snd_cs4236,snd_wavefront snd_opl3_lib6022 2 snd_cs4236,snd_wavefront snd_ca0106 23755 2 snd_hwdep 4054 2 snd_wavefront,snd_opl3_lib snd_mpu401 3604 0 snd_mpu401_uart 4067 3 snd_cs4236,snd_wavefront,snd_mpu401 snd_ac97_codec 79140 1 snd_ca0106 ac97_bus 710 1 snd_ac97_codec snd_pcm_oss28671 0 snd_mixer_oss 10461 1 snd_pcm_oss via_ircc 13311 0 snd_pcm47362 6 snd_cs4236,snd_wss_lib,snd_ca0106,snd_ac97_codec,snd_pcm_oss snd_seq_midi3576 0 snd_rawmidi12505 4 snd_wavefront,snd_ca0106,snd_mpu401_uart,snd_seq_midi snd_seq_midi_event 3684 1 snd_seq_midi snd_seq35459 3 snd_seq_midi,snd_seq_midi_event snd_timer 12258 5 snd_wss_lib,snd_opl3_lib,snd_pcm,snd_seq snd_seq_device 3673 4 snd_opl3_lib,snd_seq_midi,snd_rawmidi,snd_seq joydev 6771 0 irda 75920 1 via_ircc crc_ccitt 1039 1 irda i2c_viapro 4419 0 emu10k1_gp 1238 0 parport_pc 15799 0 wacom 15640 0 ns558 1599 0 snd34363 19 snd_cs4236,snd_wavefront,snd_wss_lib,snd_opl3_lib,snd_ca0106,snd_hwdep,snd_mpu401,snd_mpu401_uart,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device parport22554 1 parport_pc processor 26571 1 i2c_core 12648 5 radeon,drm,i2c_algo_bit,lm90,i2c_viapro shpchp 21220 0 pcspkr 1207 0 gameport6057 4 emu10k1_gp,ns558 evdev 5609 11 pci_hotplug18065 1 shpchp soundcore 3450 1 snd snd_page_alloc 5041 3 snd_wss_lib,snd_ca0106,snd_pcm ext3 94192 13 jbd32161 1 ext3 mbcache 3762 2 ext2,ext3 raid1 16099 5 md_mod 67165 6 raid1 sd_mod 25781 16 crc_t10dif 1012 1 sd_mod usbhid 27888 0 hid50657 1 usbhid ide_cd_mod 21076 0 cdrom 26487 1 ide_cd_mod ide_gd_mod 17171 8 ata_generic 2015 0 libata114408 1 ata_generic ide_pci_generic 1924 0 uhci_hcd 16045 0 via82cxxx 4390 6 firewire_ohci 16509 0 3c59x 24525 0 aic79xx 112160 14 via_agp 4608 1 floppy 40923 0 ehci_hcd 27574 0 ide_core 64146 4 ide_cd_mod,ide_gd_mod,ide_pci_generic,via82cxxx scsi_transport_spi 14866 1 aic79xx firewire_core 31139 1 firewire_ohci crc_itu_t 1035 1 firewire_core button 3598 0 mii 2714 1 3c59x usbcore98126 5 wacom,usbhid,uhci_hcd,ehci_hcd nls_base4541 1 usbcore scsi_mod 101297 4 sd_mod,libata,aic79xx,scsi_transport_spi agpgart19516 3 ttm,drm,via_agp thermal 9206 0 fan 2586 0 thermal_sys 9378 3
Bug#576845: initramfs-tools: Forgets to add mdadm and related scripts
Hi: I forgot to say it, I downgraded to initramfs-tools 0.93.4, that is the one I used to generate the working initrd. But then upgraded to 0.94.2 once 33 was working again, and inspected the file to be sure mdadm files are still there (yes, they are). And rebooted again to be sure the initrd worked too. *sigh* It does, all seem solved. Thanks again. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576845: initramfs-tools: Forgets to add mdadm and related scripts
Hi, m...@stro.at (2010-04-07 at 1952.55 +0200): On Wed, Apr 07, 2010 at 07:30:03PM +0200, GSR wrote: Package: initramfs-tools Version: 0.94.1 Severity: important Tags: sid Last update to initrd.img left the system unbootable due to lack of sbin/mdadm and scripts/local-top/mdadm (even scripts/local-top/ is missing), as checked by manual inspection with zcat -d /boot/initrd.img-... | cpio -i. Currently I am booting thanks to initrd backups. I looked at other bugs and found a suggestion to install lvm2 (I do not use it, RAID here is plain /dev/md*, but nothing to lose...), then local-top was added to the initrd, with lvm2 in it, but still no trace of mdadm. post output of: update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.33-2-686 I reported the bug from 32 (as all other mails), but 33 was the one that failed to boot completly. In 32 I had to enable md[1-4] by hand (after fsck failure), but md0 worked automatically. With 33 it just was unable to find any md at all, failing earlier in boot. dpkg -l mdadm rc mdadm 3.1.1-1tool to administer Linux MD arrays (software Uh, I am surprised, it was removed!? That explains why I had to use the binary from old initrd to get 32 into multiuser. Sorry if it was my fault to let an upgrade remove such deb, I normally verify the list of packages to avoid bad conflicts. Reinstalled and 32 boots fine again. mount | grep /tmp Yeah, tmpfs type. if it is on tmpfs, please try TMPDIR=mnt mkinitramfs -o /tmp/initramfs-test mktemp: failed to create directory via template `mnt/mkinitramfs_XX': No such file or directory With a TMPDIR pointing to a HDD backed directory, it generates /tmp/initramfs-test of 8265948 bytes. And as I had installed back mdadm (no conflicts, still no idea why it was removed), it managed to get the right mdadm files in sbin and scripts/local-top/. Renamed it into /boot/ and rebooted, now it complained about missing dep file, but I am not sure which path it was exactly. I have /lib/modules/2.6.32-3-686/ and /lib/modules/2.6.33-2-686/ on HDD with dep files in them, while the initramfs-test had lib/modules/2.6.32-3-686/ and no dep file (path 32 and booting kernel 33... I think it was an bad idea). So I put back one of the backups without mdadm then used uptdate-initramfs -u so it does not complain about modified and unable to update. It seems it works then, now I am running 33 again, no manual fixes while booting. Thanks a lot for your patience. I looked in /var/log/dpkg to see when mdadm was removed, the dist-upgrade where it happened is: ---8--- 2010-04-07 00:00:53 startup packages remove 2010-04-07 00:00:53 status installed mdadm 3.1.1-1 2010-04-07 00:01:09 remove mdadm 3.1.1-1 3.1.1-1 2010-04-07 00:01:09 status half-configured mdadm 3.1.1-1 2010-04-07 00:01:10 status half-installed mdadm 3.1.1-1 2010-04-07 00:01:10 status triggers-pending man-db 2.5.7-2 2010-04-07 00:01:10 status half-installed mdadm 3.1.1-1 2010-04-07 00:01:11 status triggers-pending initramfs-tools 0.94 2010-04-07 00:01:11 status config-files mdadm 3.1.1-1 2010-04-07 00:01:11 status config-files mdadm 3.1.1-1 2010-04-07 00:01:11 trigproc man-db 2.5.7-2 2.5.7-2 2010-04-07 00:01:11 status half-configured man-db 2.5.7-2 2010-04-07 00:01:16 status installed man-db 2.5.7-2 2010-04-07 00:01:16 trigproc initramfs-tools 0.94 0.94 2010-04-07 00:01:16 status half-configured initramfs-tools 0.94 2010-04-07 00:01:47 status installed initramfs-tools 0.94 2010-04-07 00:01:49 startup archives unpack 2010-04-07 00:02:12 upgrade x11proto-dri2-dev 2.2-2 2.3-1 2010-04-07 00:02:12 status half-configured x11proto-dri2-dev 2.2-2 2010-04-07 00:02:12 status unpacked x11proto-dri2-dev 2.2-2 2010-04-07 00:02:12 status half-installed x11proto-dri2-dev 2.2-2 2010-04-07 00:02:12 status half-installed x11proto-dri2-dev 2.2-2 2010-04-07 00:02:12 status unpacked x11proto-dri2-dev 2.3-1 2010-04-07 00:02:13 status unpacked x11proto-dri2-dev 2.3-1 2010-04-07 00:02:13 upgrade bsdmainutils 8.0.9 8.0.10 2010-04-07 00:02:13 status half-configured bsdmainutils 8.0.9 2010-04-07 00:02:13 status unpacked bsdmainutils 8.0.9 2010-04-07 00:02:13 status half-installed bsdmainutils 8.0.9 2010-04-07 00:02:14 status triggers-pending man-db 2.5.7-2 2010-04-07 00:02:14 status half-installed bsdmainutils 8.0.9 2010-04-07 00:02:16 status half-installed bsdmainutils 8.0.9 2010-04-07 00:02:16 status unpacked bsdmainutils 8.0.10 2010-04-07 00:02:16 status unpacked bsdmainutils 8.0.10 2010-04-07 00:02:16 upgrade cpio 2.11-1 2.11-2 2010-04-07 00:02:16 status half-configured cpio 2.11-1 2010-04-07 00:02:17 status unpacked cpio 2.11-1 2010-04-07 00:02:17 status half-installed cpio 2.11-1 2010-04-07 00:02:17 status triggers-pending install-info 4.13a.dfsg.1-5 2010-04-07 00:02:17 status half-installed cpio 2.11-1 2010-04-07 00:02:17 status half-installed cpio 2.11-1 2010-04-07 00:02:18 status half-installed cpio 2.11-1 2010-04-07 00:02:18 status unpacked
Bug#576442: linux-base: Migration to UUID forgets about mdadm.conf
Package: linux-base Version: 2.6.33-1~experimental.4 Severity: important Tags: experimental Hi: I tried the kernel in experimental and it nicely suggested and even updated itself some config files to use UUIDs instead of device names. ---8--- These configuration files will be updated: /etc/fstab, /etc/udev/rules.d/70-persistent-cd.rules, /etc/initramfs-tools/conf.d/resume ---8--- But it forgot to mention /etc/mdadm/mdadm.conf could be affected as DEVICE line allows direct naming of devices which get a different name in .33 (changing the line to DEVICE partitions should work). So mentioning the mdadm file or even upgrading that line would be nice. Thanks. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-base depends on: ii debconf [debconf-2.0] 1.5.30 Debian configuration management sy ii libapt-pkg-perl 0.1.24 Perl interface to libapt-pkg ii libuuid-perl 0.02-3+b1 Perl extension for using UUID inte linux-base recommends no packages. linux-base suggests no packages. -- debconf information: * linux-base/disk-id-manual: linux-base/disk-id-convert-plan-no-relabel: true * linux-base/disk-id-convert-plan: true * linux-base/disk-id-convert-auto: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576442: linux-base: Migration to UUID forgets about mdadm.conf (and more)
Hi: Another file that is affected is /etc/hdparm.conf. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576442: linux-base: Migration to UUID forgets about mdadm.conf (and more)
Hi, b...@decadent.org.uk (2010-04-04 at 2255.55 +0100): Another file that is affected is /etc/hdparm.conf. hdparm tweaks might not work properly with the new drivers, so I think that should be warned about but not updated. There I am using /dev/disk/by-id/... names now. But warning is better than nothing, for sure. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576442: linux-base: Migration to UUID forgets about mdadm.conf (and more)
Hi, b...@decadent.org.uk (2010-04-05 at 0008.01 +0100): There I am using /dev/disk/by-id/... names now. But warning is better than nothing, for sure. I've implemented warnings for hdparm.conf and mdadm.conf. Thanks for reporting these. I did a deeper search to be sure I was not missing other appearances of hda, sda... that could cause problems later and found other probable paths: /etc/smartd.conf /etc/mtools.conf /etc/sysfs.conf /etc/schroot/schroot.conf /etc/laptop-mode/laptop-mode.conf /etc/default/smartmontools /etc/default/hdparm /etc/blkid.tab Maybe some are already handled, but better be sure. Thanks for the fixes. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546588: Suggestion for slow radeon (debian bug 546588)
Hi, daen...@debian.org (2010-03-28 at 1513.22 +0200): On Sun, 2010-03-28 at 05:30 +0200, GSR wrote: I was reading the list of radeon reports and found yours. Time ago I experienced a problem with similar symptoms, that got fixed by adding Option MigrationHeuristic greedy (that go back to XAA, as other ^ ... that or go ... person suggested). What do you mean? That option has nothing to do with XAA. Sorry, or was missing. To sum up, I meant new EXA with greedy mode gives a similar speed than plain old XAA. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546588: Suggestion for slow radeon (debian bug 546588)
Hi: I was reading the list of radeon reports and found yours. Time ago I experienced a problem with similar symptoms, that got fixed by adding Option MigrationHeuristic greedy (that go back to XAA, as other person suggested). Maybe your case is the same. I got the idea to test that option from: http://lists.freedesktop.org/archives/xorg/2008-May/thread.html#35451 GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574153: python-pkg-resources: Missing file leaves it unconfigured
Package: python-pkg-resources Version: 0.6.10-3 Severity: grave Justification: renders package unusable While dist-upgrading: ---8--- Setting up python-pkg-resources (0.6.10-3) ... file does not exist: /usr/lib/python3.1/dist-packages/pkg_resources.py pycentral: pycentral pkginstall: error byte-compiling files (1) pycentral pkginstall: error byte-compiling files (1) dpkg: error processing python-pkg-resources (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of python-setuptools: python-setuptools depends on python-pkg-resources (= 0.6.10-3); however: Package python-pkg-resources is not configured yet. dpkg: error processing python-setuptools (--configure): dependency problems - leaving unconfigured Setting up python2.6-minimal (2.6.5~rc2-2) ... [...] Errors were encountered while processing: python-pkg-resources python-setuptools E: Sub-process /usr/bin/dpkg returned an error code (1) ---8--- -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pkg-resources depends on: ii python 2.5.4-9 An interactive high-level object-o ii python-central 0.6.14+nmu2 register and build utility for Pyt python-pkg-resources recommends no packages. Versions of packages python-pkg-resources suggests: pn python-distribute none (no description available) pn python-distribute-doc none (no description available) -- no debconf information GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524670: XF86VidModeGetGammaRamp errors
Hi, k...@debian.org (2010-03-03 at 0339.01 +0100): I fear you didn't receive the following message: No, and I had forgotten completly about this bug. Kevin Shanahan kmsha...@disenchant.net (13/09/2009): Hi, I came up against this error too. Just thought I'd let you know that the reason you are seeing this error is that the new xserver breaks the assumption a lot of apps make that the gamma ramp is always of size 256. Try querying the size using XF86VidModeGetGammaRampSize first and then use a buffer of the returned size to get and set the gamma. That sounds like it's not a bug in the end? To avoid messing with the arrays I tried a dirty and quick hack based in the suggested query (rewrite the define after printing what was returned). Well, it says 256 so the define is unchanged. No idea why it failed for some time, maybe then the ramp was other size in the meanwhile (bigger to support all cards, then back to what each card really does?). Anyway I will try to improve the code so the define can go away. Thanks for the tip and the reminder. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568958: mypaint: needs to depend on python-protobuf
Package: mypaint Version: 0.8.0-1 Severity: grave Justification: renders package unusable Launching the program fails with: ---8--- Psyco being used Traceback (most recent call last): File /usr/bin/mypaint, line 109, in module from gui import main File /usr/share/mypaint/gui/main.py, line 15, in module from gui import application File /usr/share/mypaint/gui/application.py, line 14, in module import filehandling, keyboard, brushmanager File /usr/share/mypaint/gui/filehandling.py, line 17, in module from lib import document, helpers File /usr/share/mypaint/lib/document.py, line 17, in module import command, stroke, layer File /usr/share/mypaint/lib/command.py, line 9, in module import layer File /usr/share/mypaint/lib/layer.py, line 11, in module import tiledsurface, strokemap, strokemap_pb2 File /usr/share/mypaint/lib/strokemap.py, line 13, in module import tiledsurface, idletask, strokemap_pb2 File /usr/share/mypaint/lib/strokemap_pb2.py, line 3, in module from google.protobuf import descriptor ImportError: No module named google.protobuf ---8--- After manually installing python-protobuf, it worked. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mypaint depends on: ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.3-2GCC support library ii libglib2.0-02.22.4-1 The GLib library of C routines ii libstdc++6 4.4.3-2 The GNU Standard C++ Library v3 ii mypaint-data0.8.0-1 Brushes and backgrounds for the my ii python 2.5.4-9 An interactive high-level object-o ii python-numpy1:1.3.0-3+b1 Numerical Python adds a fast array ii python2.5 2.5.5-2 An interactive high-level object-o mypaint recommends no packages. mypaint suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560775: fluid-soundfont: size reporting is way off, leaves unmanaged files
Hi: I found there is a tool, piuparts, that can help detecting issues: http://piuparts.debian.org/sid/fail/fluid-soundfont-gm_3.1-4.log GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560775: fluid-soundfont: size reporting is way off, leaves unmanaged files
Package: fluid-soundfont Version: 3.1-4 Severity: normal While upgrading from 3.1-2 it reported it would free 73.4MB. I checked with df, out of curiosity as it was a rather huge change, and real change was minimal. Uninstalling (with purge) said it would free 78.4MB, and I decided to check again with same results, minimal space recovered. I investigated a bit what was going on. The new compress with flac maybe be nice to reduce downloads, but it causes disk usage reporting to be really off and leaves two huge files: ---8--- ls -l /usr/share/sounds/sf2/ -rw-r--r-- 1 root root 148398306 Dec 12 05:09 FluidR3_GM.sf2 -rw-r--r-- 1 root root 3201926 Dec 12 05:09 FluidR3_GS.sf2 ---8--- A diff of ~75M of reported vs real usage is a number important for apt-get's space checks that abort an install before leaving the system in bad state for lack of free space, and leaving those huge files without md5 info and totally orphan (dpkg knows nothing) is not very nice. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.31-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555492: colormake: Cross compiler patch breaks other things
Package: colormake
Version: 0.2-6
Severity: normal
Hi:
I upgraded to 0.2-6 and notice some lines are coloured strangely. I
diffed the scripts and the diff that seems to matter is:
@@ -73,7 +73,7 @@
{
$in = 'make';
}
- elsif ($thisline =~ s/^(\s*(g?cc|(g|c)\+\+).*)$/$col_gcc$1$col_norm/)
+ elsif ($thisline =~ s/^(\s*(.*g?cc|(g|c)\+\+).*)$/$col_gcc$1$col_norm/)
{
$in = 'gcc';
}
Which seems to come from colormake-0.2/debian/patches/07_colormake.pl.
In the following two lines, now first is multicolour (file, line,
warning word, message), second is all pink. Before, all were
multicolour:
BL_ShapeActionActuator.cpp:451: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)
BL_ShapeActionActuator.cpp:451: warning: invalid access to non-static data
member ‘BL_ShapeActionActuator::m_startframe’ of NULL object
ar output lines are yellow if they have a g, or pink if not (or so I
think, because other ar run in a different place left all plain
white). Before, all plain white:
a - rna_world_gen.o
a - rna_access.o
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.30.crossbow1 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages colormake depends on:
ii less 436-1 pager program similar to more
ii make 3.81-7 An utility for Directing compilati
ii perl 5.10.1-7 Larry Wall's Practical Extraction
colormake recommends no packages.
colormake suggests no packages.
-- debconf information:
* colormake/renamed:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
Hi, jcris...@debian.org (2009-11-06 at 1838.42 +0100): What's the status of this bug? Updated and the DRI info now is: OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 (RV350 4152) 20090101 AGP 8x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.5 Mesa 7.6 Currently they do not redraw on top of other windows, but screen captures still cause problems (black zones for 2D apps over 3D apps, when using ImageMagick's import). Better, but still some issues. GSR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
