Bug#1012713: nvidia-graphics-drivers: Fails to build from source: 510.73.08 missing upstream
Source: nvidia-graphics-drivers Version: 510.73.08-1 Severity: serious Tags: upstream ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I am trying to build the associated flathub packages for 510.73.08 and they seem to be completely absent upstream * What exactly did you do (or not do) that was effective (or ineffective)? I tried to build the git 510 branch from source. * What was the outcome of this action? The get-orig-source command failed. * What outcome did you expect instead? The upstream source should exist? curl https://download.nvidia.com/XFree86/Linux-x86_64/510.73.08/NVIDIA-Linux-x86_64-510.73.08.run results in 404 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> 404 - Not Found 404 - Not Found It seems that the version 510.73.08 is completely absent upstream. The archive page only lists 510.73.05 from this series. I'm not sure where this version came from, there seems to be little reference to it outside of debian's ecosystem. Perhaps this was a prelude to the opensourcing somehow?? It's frustrating that this is completely unbuildable now. I'm guessing the adoption of the 515 branch is going to be held up in debian-legal for some time, because of obvious reasons. Is it perhaps that this is secretly 510.73.05 and got the wrong number somehow? Christian -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.1-tkg-pds (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1005311: This bug also affects experimental version 510.47.03-1
This bug also affects experimental version 510.47.03-1 - it looks like the dependencies need updating on the experimental driver as well.
Bug#1003611: Acknowledgement (systemd: Upgrade from 249.7 to 250.2 seems to have crashed the systemd root process, leaving system unstable)
I have attached the journal from the 10 minutes prior. I was trying to mount a CD in an external CD rom drive at the time. It seems that something went wrong and killed systemd. I apparently didn't notice for another 10 days. /facepalm I have the core file, if you want me to analyze it somehow, just tell me what to do. Christian On Wed, 2022-01-12 at 19:21 +0100, Michael Biebl wrote: > > Am 12.01.22 um 18:20 schrieb Christian Weeks: > > I don't see anything in the journal, I've had a fairly long look. I do not > > have > > the coredump utility installed. > > As I have mentioned, rebooting fixed whatever caused the problem during the > > upgrade, so I have no idea how I can help you further. > > > > In looking at my running system since, I notice that systemd isn't > > defaulting to > > running, so I guess the problem was actually that dbus was failing to > > activate > > systemd properly, during the upgrade. > > Once PID 1 has been frozen, you can't reactivate it. dbus tried to talk > to it but eventually timed out. dbus is not supposed to "start" PID1. > > The only option to recover from such a scenario is to reboot > (forcefully) as you did. > > > I have found a core file, but it's dated from 10 days ago, not today, which > > is > > weird. There was no activity on the computer at the time, I believe, and > > this > > went unnoticed, perhaps for 10 days?! > > I'd say this observation is correct. > > If you still have the journal, maybe attach the preceeding 10 mins > before the crash, i.e. all log messages from > Jan 2 10:00:00 until Jan 2 10:14:48 Jan 02 10:05:01 cheesypuffs CRON[1425173]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0) Jan 02 10:05:01 cheesypuffs CRON[1425174]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Jan 02 10:05:01 cheesypuffs CRON[1425173]: pam_unix(cron:session): session closed for user root Jan 02 10:06:59 cheesypuffs NetworkManager[958]: [1641136019.2397] device (wlp41s0): set-hw-addr: set MAC address to 36:F4:36:8B:48:E4 (scanning) Jan 02 10:06:59 cheesypuffs NetworkManager[958]: [1641136019.2890] device (wlp41s0): supplicant interface state: inactive -> disconnected Jan 02 10:06:59 cheesypuffs NetworkManager[958]: [1641136019.2890] device (p2p-dev-wlp41s0): supplicant management interface state: inactive -> disconnected Jan 02 10:06:59 cheesypuffs NetworkManager[958]: [1641136019.2941] device (wlp41s0): supplicant interface state: disconnected -> inactive Jan 02 10:06:59 cheesypuffs NetworkManager[958]: [1641136019.2941] device (p2p-dev-wlp41s0): supplicant management interface state: disconnected -> inactive Jan 02 10:07:41 cheesypuffs kernel: usb 1-2: USB disconnect, device number 3 Jan 02 10:07:41 cheesypuffs kernel: usb 1-2.4: USB disconnect, device number 9 Jan 02 10:07:41 cheesypuffs kernel: usb 1-2.4.4: USB disconnect, device number 12 Jan 02 10:07:41 cheesypuffs kernel: usb 1-2.4.4.2: USB disconnect, device number 13 Jan 02 10:07:42 cheesypuffs kernel: usb 2-2: USB disconnect, device number 3 Jan 02 10:07:42 cheesypuffs kernel: usb 2-2.4: USB disconnect, device number 4 Jan 02 10:07:42 cheesypuffs kernel: usb 2-2.4.4: USB disconnect, device number 5 Jan 02 10:07:42 cheesypuffs kernel: usb 2-2: new SuperSpeed USB device number 6 using xhci_hcd Jan 02 10:07:42 cheesypuffs kernel: usb 2-2: New USB device found, idVendor=2109, idProduct=0817, bcdDevice= 3.64 Jan 02 10:07:42 cheesypuffs kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jan 02 10:07:42 cheesypuffs kernel: usb 2-2: Product: USB3.0 Hub Jan 02 10:07:42 cheesypuffs kernel: usb 2-2: Manufacturer: VIA Labs, Inc. Jan 02 10:07:42 cheesypuffs kernel: hub 2-2:1.0: USB hub found Jan 02 10:07:42 cheesypuffs kernel: hub 2-2:1.0: 4 ports detected Jan 02 10:07:42 cheesypuffs upowerd[1429]: treating change event as add on /sys/devices/pci:00/:00:01.2/:20:00.0/:21:08.0/:2a:00.1/usb2/2-2 Jan 02 10:07:43 cheesypuffs kernel: usb 1-2: new high-speed USB device number 14 using xhci_hcd Jan 02 10:07:43 cheesypuffs kernel: usb 1-2: New USB device found, idVendor=2109, idProduct=2817, bcdDevice= 3.64 Jan 02 10:07:43 cheesypuffs kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jan 02 10:07:43 cheesypuffs kernel: usb 1-2: Product: USB2.0 Hub Jan 02 10:07:43 cheesypuffs kernel: usb 1-2: Manufacturer: VIA Labs, Inc. Jan 02 10:07:43 cheesypuffs kernel: hub 1-2:1.0: USB hub found Jan 02 10:07:43 cheesypuffs kernel: hub 1-2:1.0: 4 ports detected Jan 02 10:07:43 cheesypuffs upowerd[1429]: treating change event as add on /sys/devices/pci:00/:00:01.2/:20:00.0/:21:08.0/:2a:00.1/usb1/1-2 Jan 02 10:07:43 cheesypuffs kernel: usb 2-2.4: new SuperSpeed USB d
Bug#1003611: Acknowledgement (systemd: Upgrade from 249.7 to 250.2 seems to have crashed the systemd root process, leaving system unstable)
I don't see anything in the journal, I've had a fairly long look. I do not have the coredump utility installed. As I have mentioned, rebooting fixed whatever caused the problem during the upgrade, so I have no idea how I can help you further. In looking at my running system since, I notice that systemd isn't defaulting to running, so I guess the problem was actually that dbus was failing to activate systemd properly, during the upgrade. I have found a core file, but it's dated from 10 days ago, not today, which is weird. There was no activity on the computer at the time, I believe, and this went unnoticed, perhaps for 10 days?! Jan 2 10:14:48 cheesypuffs kernel: [336844.954825] systemd[1]: segfault at 18 ip 55bd29c926ea sp 7ffdcd0c56c8 error 4 in systemd[55bd29c38000+d9000] ls -l /core -rw--- 1 root root 22482944 Jan 2 10:14 /core I can share this core file with you if you wish (how?), though perhaps it's not so related to the upgrade anymore? Christian On Wed, 2022-01-12 at 18:01 +0100, Michael Biebl wrote: > Control: tags -1 + moreinfo > > Hello, > > systemd freezes execution when it crashes (you should see a > corresponding log message in the journal). > > For this bug report to be actionable, we will need at the very least a > backtrace of the crash. > In case you had systemd-coredump installed, coredumpctl should show you. > Or maybe you still have a core file in /. > > > Regards, > Michael >
Bug#1003611: Acknowledgement (systemd: Upgrade from 249.7 to 250.2 seems to have crashed the systemd root process, leaving system unstable)
The reboot fixed the issue - I now have a working computer again, though getting to a reboot was a bit painful. > systemctl reboot Failed to reboot system via logind: Connection timed out Failed to start reboot.target: Connection timed out See system logs and 'systemctl status reboot.target' for details. It is possible to perform action directly, see discussion of --force --force in man:systemctl(1). > systemctl reboot --force Failed to execute operation: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) It is possible to perform action directly, see discussion of --force --force in man:systemctl(1). > systemctl reboot --force --force On Wed, 2022-01-12 at 15:36 +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1003611: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003611. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian systemd Maintainers > > If you wish to submit further information on this problem, please > send it to 1003...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. >
Bug#1003611: systemd: Upgrade from 249.7 to 250.2 seems to have crashed the systemd root process, leaving system unstable
Package: systemd Version: 250.2-1 Severity: critical Justification: breaks the whole system Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I upgraded my local sid installation, which was about a week out of date. * What exactly did you do (or not do) that was effective (or ineffective)? Nothing * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I have just performed an upgrade of sid, which included the 250.2 systemd update. It seems that during that update the root systemd process has died, and now every request of systemd is timing out, causing packages to fail to install and who knows what other issues. I'm reluctant to reboot, but I will have to I guess, and hope that systemd manages to load itself properly afterwards. Some relevant snippets from the upgrade in flight: ... Unpacking xserver-xorg-core (2:1.20.14-1) over (2:1.20.13-3) ... Preparing to unpack .../15-systemd-timesyncd_250.2-1_amd64.deb ... Unpacking systemd-timesyncd (250.2-1) over (249.7-1) ... Preparing to unpack .../16-libpam-systemd_250.2-1_amd64.deb ... Unpacking libpam-systemd:amd64 (250.2-1) over (249.7-1) ... Setting up libc6:amd64 (2.33-2) ... (Reading database ... 639000 files and directories currently installed.) Preparing to unpack .../systemd_250.2-1_amd64.deb ... Unpacking systemd (250.2-1) over (249.7-1) ... Setting up libc6:i386 (2.33-2) ... (Reading database ... 639034 files and directories currently installed.) Preparing to unpack .../00-libsystemd0_250.2-1_amd64.deb ... De-configuring libsystemd0:i386 (249.7-1), to allow configuration of libsystemd0:amd64 (249.7-1) ... Unpacking libsystemd0:amd64 (250.2-1) over (249.7-1) ... Preparing to unpack .../01-libsystemd0_250.2-1_i386.deb ... Unpacking libsystemd0:i386 (250.2-1) over (249.7-1) ... Preparing to unpack .../02-libudev-dev_250.2-1_i386.deb ... De-configuring libudev-dev:amd64 (249.7-1), to allow configuration of libudev-dev:i386 (249.7-1) ... Unpacking libudev-dev:i386 (250.2-1) over (249.7-1) ... Preparing to unpack .../03-libudev-dev_250.2-1_amd64.deb ... Unpacking libudev-dev:amd64 (250.2-1) over (249.7-1) ... Preparing to unpack .../04-udev_250.2-1_amd64.deb ... Unpacking udev (250.2-1) over (249.7-1) ... Preparing to unpack .../05-libudev1_250.2-1_amd64.deb ... De-configuring libudev1:i386 (249.7-1), to allow configuration of libudev1:amd64 (249.7-1) ... Unpacking libudev1:amd64 (250.2-1) over (249.7-1) ... Preparing to unpack .../06-libudev1_250.2-1_i386.deb ... Unpacking libudev1:i386 (250.2-1) over (249.7-1) ... Preparing to unpack .../07-libglx-dev_1.4.0-1_i386.deb ... De-configuring libglx-dev:amd64 (1.3.4-2+b1), to allow configuration of libglx-dev:i386 (1.3.4-2+b1) ... ... De-configuring libglvnd0:i386 (1.3.4-2+b1), to allow configuration of libglvnd0:amd64 (1.3.4-2+b1) ... Unpacking libglvnd0:amd64 (1.4.0-1) over (1.3.4-2+b1) ... Preparing to unpack .../53-libglvnd0_1.4.0-1_i386.deb ... Unpacking libglvnd0:i386 (1.4.0-1) over (1.3.4-2+b1) ... Setting up libsystemd0:amd64 (250.2-1) ... Setting up systemd (250.2-1) ... Installing new version of config file /etc/systemd/logind.conf ... Installing new version of config file /etc/systemd/system.conf ... Failed to try-restart systemd-networkd.service: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) See system logs and 'systemctl status systemd-networkd.service' for details. Failed to try-restart systemd-resolved.service: Connection timed out See system logs and 'systemctl status systemd-resolved.service' for details. Failed to try-restart systemd-journald.service: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) See system logs and 'systemctl status systemd-journald.service' for details. (Reading database ... 639016 files and directories currently installed.) Preparing to unpack .../00-systemd-sysv_250.2-1_amd64.deb ... Unpacking systemd-sysv (250.2-1) over (249.7-1) ... Preparing to unpack .../01-libgnutls28-dev_3.7.2-5_amd64.deb ... De-configuring libgnutls28-dev:i386 (3.7.2-4), to allow configuration of libgnutls28-dev:amd64 (3.7.2-4) ... ... Setting up udev (250.2-1) ... Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) Failed to restart udev.service: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) See system logs and 'systemctl status udev.service' for details. invoke-rc.d: initscript udev, action "restart" failed. Failed to get properties: Connection timed out dpkg: error processing package udev (--configure): installed udev package post-installation script subprocess returned error exit status 1 Setting up libss2:amd64 (1.46.5-2) ... ... Errors were encountered while processing: udev ed
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
On Sat, 2020-06-27 at 04:35 +0200, Guilhem Moulin wrote: > On Fri, 26 Jun 2020 at 20:39:32 -0400, Christian Weeks wrote: > > After some more googling, it seems that the REAL culprit might be > > libmount1. > > Should this be reassigned to util-linux/2.35.2-5 then? I guess so? I don't know how to do that. > > > This seems like a really messy tangled web of nastiness. Good luck > > figuring it out. > > Unless there is a reproducer involving a targeted libcryptsetup12 > upgrade I don't think this belong here :-P Aside from documentation > files, the only thing libcryptsetup12 (2:2.1.0-5+deb10u2 and 2:2.3.3-1) > ships is libcryptsetup.so.12*. It doesn't touch libssl. > It seems that libcryptsetup + the new libmount1 dependency on same are the root cause somehow. Sorry for the confusion.
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Update. I just discovered steam is still broken. After some more googling, it seems that the REAL culprit might be libmount1. Specifically, it seems that libmount1 v2.35.2-5 (bug #951048) has started building with libcryptsetup-dev, but that is causing weird SSL leakages everywhere, crashing unrelated software (minecraft launcher, steam, other stuff using SSL). I have upgraded libcryptsetup12 and downgraded libmount1 to 2.35.2-4 and it has resolved the problem as well. This seems like a really messy tangled web of nastiness. Good luck figuring it out. I'm going to speculate that the guys at Mandriva found a similar problem: https://github.com/ValveSoftware/steam-for-linux/issues/6861 Perhaps they might have a solution too? Thanks On Fri, 2020-06-26 at 11:40 -0400, Christian Weeks wrote: > Attached is the output of the various console commands, as well > as the backtrace from the broken launcher with the new lib. > > Note that I am installing both amd64 and i386 versions. I do not > have cryptsetup even installed on this machine, I think this lib > is coming in from a dependency in gnome disks. > > There is one key difference: in the older version, there is an > explicit libssl in the linker, but in the new version, there > is not, even though it is somehow still being loaded. > > Perhaps another lib is pulling a differing version somehow, and > this lib is stamping on it? > > Thanks! > > On Fri, 2020-06-26 at 17:23 +0200, Guilhem Moulin wrote: > > Control: tag -1 moreinfo > > > > Hi Christian, > > > > On Thu, 25 Jun 2020 at 21:58:43 -0400, Christian Weeks wrote: > > > I installed the newest version of libcryptsetup12. > > > > Unfortunately you appeared to file this bug using Buster's > > libcryptsetup12 so the metada doesn't describe the buggy environment > > (Version: 2:2.1.0-5+deb10u2). Please show the output of `apt upgrade > > libcryptsetup12` that yields the buggy environment. (I.e., you don't > > encounter the bug before the command but do after the upgrade.) The > > output of > > > > ldd /lib/*-linux-gnu/libcryptsetup.so.12.6.0 /sbin/cryptsetup > > > > and > > > > dpkg-query -l "*cryptsetup*" > > > > before *and* after the upgrade might be helpful too. > > > > > Suddenly, minecraft would not run! > > > Backtraces in gdb indicate that something is broken in SSL. > > > > Care to share said backtrace also? > > > > cheers
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Attached is the output of the various console commands, as well as the backtrace from the broken launcher with the new lib. Note that I am installing both amd64 and i386 versions. I do not have cryptsetup even installed on this machine, I think this lib is coming in from a dependency in gnome disks. There is one key difference: in the older version, there is an explicit libssl in the linker, but in the new version, there is not, even though it is somehow still being loaded. Perhaps another lib is pulling a differing version somehow, and this lib is stamping on it? Thanks! On Fri, 2020-06-26 at 17:23 +0200, Guilhem Moulin wrote: > Control: tag -1 moreinfo > > Hi Christian, > > On Thu, 25 Jun 2020 at 21:58:43 -0400, Christian Weeks wrote: > > I installed the newest version of libcryptsetup12. > > Unfortunately you appeared to file this bug using Buster's > libcryptsetup12 so the metada doesn't describe the buggy environment > (Version: 2:2.1.0-5+deb10u2). Please show the output of `apt upgrade > libcryptsetup12` that yields the buggy environment. (I.e., you don't > encounter the bug before the command but do after the upgrade.) The > output of > > ldd /lib/*-linux-gnu/libcryptsetup.so.12.6.0 /sbin/cryptsetup > > and > > dpkg-query -l "*cryptsetup*" > > before *and* after the upgrade might be helpful too. > > > Suddenly, minecraft would not run! > > Backtraces in gdb indicate that something is broken in SSL. > > Care to share said backtrace also? > > cheers /lib/i386-linux-gnu/libcryptsetup.so.12.4.0: linux-gate.so.1 (0xf7f31000) libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf7e83000) libdevmapper.so.1.02.1 => /lib/i386-linux-gnu/libdevmapper.so.1.02.1 (0xf7e1e000) libssl.so.1.1 => /lib/i386-linux-gnu/libssl.so.1.1 (0xf7d87000) libcrypto.so.1.1 => /lib/i386-linux-gnu/libcrypto.so.1.1 (0xf7ac4000) libargon2.so.1 => /lib/i386-linux-gnu/libargon2.so.1 (0xf7ab6000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7aac000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7aa6000) libjson-c.so.3 => /lib/i386-linux-gnu/libjson-c.so.3 (0xf7a99000) libblkid.so.1 => /lib/i386-linux-gnu/libblkid.so.1 (0xf7a3e000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf785a000) /lib/ld-linux.so.2 (0xf7f33000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xf782b000) libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xf77ff000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf76fb000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf76d9000) libpcre2-8.so.0 => /lib/i386-linux-gnu/libpcre2-8.so.0 (0xf7642000) /lib/x86_64-linux-gnu/libcryptsetup.so.12.4.0: linux-vdso.so.1 (0x7ffefefa) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8855e44000) libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 (0x7f8855dd8000) libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7f8855d46000) libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7f8855a5a000) libargon2.so.1 => /lib/x86_64-linux-gnu/libargon2.so.1 (0x7f8855a5) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f8855a45000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8855a3e000) libjson-c.so.3 => /lib/x86_64-linux-gnu/libjson-c.so.3 (0x7f8855a31000) libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7f88559e) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f885581d000) /lib64/ld-linux-x86-64.so.2 (0x7f8855eda000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7f88557f2000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f88557c6000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f885567f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f885565e000) libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x7f88555ce000) /sbin/cryptsetup: ldd: /sbin/cryptsetup: No such file or directory dpkg-query -l "*cryptsetup*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=-- un cryptsetup-initramfs (no description available) ii libcryptsetup12:amd64 2:2.1.0-5+deb10u2 amd64disk encryption support - shared library ii libcryptsetup12:i386 2:2.1.0-5+deb10u2 i3
Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Package: libcryptsetup12 Version: 2:2.1.0-5+deb10u2 Severity: critical Justification: breaks unrelated software Dear Maintainer, * What led up to the situation? I installed the newest version of libcryptsetup12. Suddenly, minecraft would not run! Backtraces in gdb indicate that something is broken in SSL. Reverting libcryptsetup12 to the buster version fixed the issue immediately. * What exactly did you do (or not do) that was effective (or ineffective)? Reverting to the buster version of libcryptsetup12. I would have picked the previous version 2.3.2 but I don't have the deb handy. * What was the outcome of this action? The spurious SSL issues were resolved and I can play again. * What outcome did you expect instead? -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcryptsetup12 depends on: ii libargon2-1 0~20171227-0.2 ii libblkid1 2.35.2-5 ii libc6 2.30-8 ii libdevmapper1.02.1 2:1.02.167-1+b1 ii libjson-c3 0.12.1+ds-2 ii libssl1.1 1.1.1g-1 ii libuuid12.35.2-5 libcryptsetup12 recommends no packages. libcryptsetup12 suggests no packages. -- no debconf information
Bug#956086: obs-studio: Please build the obs-browser plugin somehow
Package: obs-studio Version: 25.0.3-0-g3c78a8aa-1 Severity: wishlist Dear Maintainer, OBS 25 supports the obs-browser plugin. Sadly, this is not an independently buildable module, and needs to be built as part of building the rest of OBS. I have had some conversations with the developers on this on the OBS discord and they confirmed this is by design and won't change. It is designed to be linked into the source tree at OBS build time and built that way. It is separated for development reasons only. The legacy obs-linux-browser plugin has retired in favour of the official plugin. Therefore, at present, I have to build my own packages of OBS to use the browser plugin. Many new features of OBS are likely to be dependent on the OBS browser plugin in future (as is already seen in the Windows version). I realize this feature relies on the Chrome Embedded Framework to work, so it may be challenging? Is there debian policy on CEF? It seems many "browsery" features of other products use this strategy these days rather than deal with the hideous mess that is modern browser standards. I hope that the official debian can somehow figure out a way to fix this. Thanks, Christian -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#946249: firefox 71 breaks most addons because of local storage errors
Package: firefox Version: 71.0-1 Followup-For: Bug #946249 Dear Maintainer, KeepassXC is also experiencing this issue, tracked here https://github.com/keepassxreboot/keepassxc-browser/issues/704 It should be noted that that github issue identifies an upstream bug with patch that seems it might resolve this problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1601707 I hope you can incorporate this patch into the next build of firefox on debian. Thanks -- Package-specific info: -- Addons package information -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-3-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox depends on: ii debianutils 4.9.1 ii fontconfig2.13.1-2+b1 ii libatk1.0-0 2.34.1-1 ii libc6 2.29-6 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-2 ii libdbus-glib-1-2 0.110-5 ii libevent-2.1-72.1.11-stable-1 ii libffi6 3.2.1-9 ii libfontconfig12.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libgcc1 1:9.2.1-21 ii libgdk-pixbuf2.0-02.40.0+dfsg-1 ii libglib2.0-0 2.62.3-2 ii libgtk-3-03.24.13-1 ii libnspr4 2:4.23-1 ii libnss3 2:3.47.1-1 ii libpango-1.0-01.42.4-7 ii libsqlite3-0 3.30.1-1 ii libstartup-notification0 0.12-6 ii libstdc++69.2.1-21 ii libx11-6 2:1.6.8-1 ii libx11-xcb1 2:1.6.8-1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.5-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii procps2:3.3.15-2+b1 ii zlib1g1:1.2.11.dfsg-1+b1 Versions of packages firefox recommends: ii libavcodec58 10:4.2.1-dmo7 Versions of packages firefox suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-6 ii libgtk2.0-02.24.32-4 ii pulseaudio 13.0-3 -- no debconf information
Bug#917640: closed by Stephen Kitt (Re: Bug#917640: steam: Missing .desktop file to launch steam from desktop env)
Fascinating. My local copy of the steam deb file was missing that file. It only included /usr/share/applications (the directory) and not the desktop file associated with it. The reinstall fixed it (redownloading the deb?). Weird. I only filed the bug because it seemed to be completely missing here. Thanks for your help. On Sat, 29 Dec, 2018 at 3:06 PM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the steam package: #917640: steam: Missing .desktop file to launch steam from desktop env It has been closed by Stephen Kitt . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Stephen Kitt by replying to this email. -- 917640: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917640 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#917640: steam: Missing .desktop file to launch steam from desktop env
Package: steam Version: 1.0.0.56-2 Severity: normal Dear Maintainer, I seem to be missing a .desktop file to launch steam. I can run it from the command line (/usr/games/steam is in $PATH), but there is no sign of a .desktop file, so I can't find it in gnome anywhere. This seems to be a significant oversight? I have .desktop files for games installed through steam, but none for steam itself. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages steam depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.28-4 ii libgl1-mesa-dri18.2.8-2 ii libgl1-mesa-glx18.2.8-2 ii libgpg-error0 1.33-3 ii libstdc++6 8.2.0-13 ii libtxc-dxtn0 1.0.1-dmo3 ii libudev1 240-2 ii libx11-6 2:1.6.7-1 ii libxinerama1 2:1.1.4-1 ii steam-devices 1.0.0.56-2 ii xz-utils 5.2.2-1.3 Versions of packages steam recommends: ii ca-certificates 20180409 ii fontconfig2.13.1-2 ii fonts-liberation 1:1.07.4-9 ii gnome-terminal [x-terminal-emulator] 3.30.2-2 ii libxss1 1:1.2.3-1 ii mesa-vulkan-drivers 18.2.8-2 ii xterm [x-terminal-emulator] 341-1 Versions of packages steam suggests: ii nvidia-driver-libs-i386 410.78-2 ii nvidia-vulkan-icd410.78-2 -- debconf information: steam/purge: * steam/question: I AGREE * steam/license:
Bug#917374: pam: Patch pam-limits-nofile-fd-setsize-cap is having serious negative interactions with SystemD 240
Source: pam Version: 1.1.8-3.8 Severity: important Dear Maintainer, The SystemD 240 update has changed the handling of NOFILE for the init process and processes it directly spawns. See: https://github.com/systemd/systemd/pull/10244 Unfortunately, it seems that the patch above, which is forcing NOFILE to "infinity" (effectively 1G?) is now having a serious adverse effect on various processes that are spawned by SystemD directly, see: https://github.com/systemd/systemd/issues/10921 and a KDE init bug similarly. I can't find a bug reporting this to debian, even though the root cause seems to be this patch to force "infinity" onto PID 1. Hope this helps. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#878834: freetype: Upgrade to 2.8.1 breaks font rendering in various applications
Source: freetype Version: 2.8.1-0.1 Severity: important Dear Maintainer, I upgraded freetype from 2.8.0 to 2.8.1 today and font rendering in both thunderbird and discord took a really steep nosedive. Freetype 2.8.0: https://imgur.com/8QLHYDK Freetype 2.8.1: https://imgur.com/TtDN0pE Thanks Christian -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#848615: hexchat: Still an issue here
Package: hexchat Version: 2.12.3-4 Followup-For: Bug #848615 Hi So this is still an apparent issue with latest sid from today (19/Dec/2016). The problem is this bug https://github.com/hexchat/hexchat/commit/4c178782a779f013fafab476506f7d4dae372b8a which is caused by this bug: https://bugzilla.gnome.org/show_bug.cgi?id=776105 Fun! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hexchat depends on: ii hexchat-common 2.12.3-4 ii libatk1.0-0 2.22.0-1 ii libc62.24-8 ii libcairo21.14.8-1 ii libcanberra0 0.30-3 ii libdbus-1-3 1.10.14-1 ii libdbus-glib-1-2 0.108-1 ii libfontconfig1 2.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libgdk-pixbuf2.0-0 2.36.1-1 ii libglib2.0-0 2.50.2-2 ii libgtk2.0-0 2.24.31-1 ii libnotify4 0.7.7-1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-01.40.3-3 ii libproxy1v5 0.4.13-1.1 ii libssl1.11.1.0c-2 Versions of packages hexchat recommends: ii gvfs-bin 1.30.2-2 ii hexchat-otr 0.2.1-3 ii hexchat-perl 2.12.3-4 ii hexchat-plugins 2.12.3-4 ii hexchat-python3 2.12.3-4 Versions of packages hexchat suggests: pn unifont -- no debconf information
Bug#848615: hexchat: Confirming downgrade to libgdk-pixbuf2.0-0 2.36.0-1 fixes
Package: hexchat Version: 2.12.3-4 Followup-For: Bug #848615 This is an addendum to my previous submission. Confirming that downgrading libgdk-pixbuf2.0-0 to 2.36.0-1 (from stretch) fixes the missing icons problem. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hexchat depends on: ii hexchat-common 2.12.3-4 ii libatk1.0-0 2.22.0-1 ii libc62.24-8 ii libcairo21.14.8-1 ii libcanberra0 0.30-3 ii libdbus-1-3 1.10.14-1 ii libdbus-glib-1-2 0.108-1 ii libfontconfig1 2.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libgdk-pixbuf2.0-0 2.36.0-1 ii libglib2.0-0 2.50.2-2 ii libgtk2.0-0 2.24.31-1 ii libnotify4 0.7.7-1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-01.40.3-3 ii libproxy1v5 0.4.13-1.1 ii libssl1.11.1.0c-2 Versions of packages hexchat recommends: ii gvfs-bin 1.30.2-2 ii hexchat-otr 0.2.1-3 ii hexchat-perl 2.12.3-4 ii hexchat-plugins 2.12.3-4 ii hexchat-python3 2.12.3-4 Versions of packages hexchat suggests: pn unifont -- no debconf information
Bug#824544: empathy: A backtrace from the segfault
Package: empathy Version: 3.12.11-3 Followup-For: Bug #824544 Dear Maintainer, Same problem as submitter. If I run the empathy-call application separately, it *mostly* crashes, but on occasion, it does actually work, so I think this is a race condition where we lose 90% of the time. Attaching a gdb bt full for the process when it crashes. It looks like there's something going wrong in libcairo (XrmQGetResource is crashing under cairo_surface_get_font_options). Googling indicates that there was, a long time ago, a problem with cairo being given invalid surfaces (Error surfaces?). I'll note that the window has not drawn onto the screen at the point the crash occurs. One other factor: I am using the NVIDIA proprietary driver underneath X. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages empathy depends on: ii dbus-x11 1.10.8-1 ii dconf-gsettings-backend [gsettings-backend] 0.26.0-1 ii empathy-common 3.12.11-3 ii geoclue-2.0 2.4.3-1 ii gnome-icon-theme 3.12.0-1 ii gsettings-desktop-schemas3.20.0-3 ii gstreamer1.0-pulseaudio 1.8.1-1 ii libc62.22-9 ii libcairo21.14.6-1+b1 ii libcanberra-gtk3-0 0.30-3 ii libcanberra0 0.30-3 ii libchamplain-0.12-0 0.12.13-1 ii libchamplain-gtk-0.12-0 0.12.13-1 ii libcheese-gtk25 3.20.2-1 ii libclutter-1.0-0 1.26.0-2 ii libclutter-gst-3.0-0 3.0.18-1 ii libclutter-gtk-1.0-0 1.8.0-1 ii libcogl-path20 1.22.0-2 ii libcogl201.22.0-2 ii libdbus-glib-1-2 0.106-1 ii libenchant1c2a 1.6.0-11+b1 ii libfarstream-0.2-5 0.2.7-1 ii libfolks-telepathy25 0.11.2-1 ii libfolks25 0.11.2-1 ii libgcr-base-3-1 3.20.0-2 ii libgcr-ui-3-13.20.0-2 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libgee-0.8-2 0.18.0-1 ii libgeocode-glib0 3.20.1-1 ii libglib2.0-0 2.48.1-1 ii libgnutls30 3.4.11-4 ii libgoa-1.0-0b3.20.1-1 ii libgstreamer-plugins-base1.0-0 1.8.1-1 ii libgstreamer1.0-01.8.1-1 ii libgtk-3-0 3.20.4-1 ii libgudev-1.0-0 230-3 ii libmission-control-plugins0 1:5.16.3-2 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.40.1-1 ii libpulse-mainloop-glib0 8.0-2+b2 ii libpulse08.0-2+b2 ii libsecret-1-00.18.5-1 ii libsoup2.4-1 2.54.1-1 ii libtelepathy-farstream3 0.6.2-1+b1 ii libtelepathy-glib0 0.24.1-1.1 ii libtelepathy-logger3 0.8.2-1 ii libwayland-server0 1.10.0-2 ii libwebkitgtk-3.0-0 2.4.11-1 ii libx11-6 2:1.6.3-1 ii libxml2 2.9.3+dfsg1-1 ii telepathy-logger 0.8.2-1 ii telepathy-mission-control-5 1:5.16.3-2 Versions of packages empathy recommends: ii gnome-contacts 3.19.91-2 ii gvfs-backends1.28.2-1 ii sound-theme-freedesktop 0.8-1 ii telepathy-gabble 0.18.3-2+b1 ii telepathy-haze 0.8.0-2 ii telepathy-salut 0.8.1-5+b1 Versions of packages empathy suggests: ii telepathy-idle 0.2.0-2 ii vino3.20.2-1 Versions of packages empathy is related to: ii telepathy-gabble [telepathy-connection-manager] 0.18.3-2+b1 ii telepathy-haze [telepathy-connection-manager]0.8.0-2 ii telepathy-idle [telepathy-connection-manager]0.2.0-2 ii telepathy-rakia [telepathy-connection-manager] 0.8.0-3 ii telepathy-salut [telepathy-connection-manager] 0.8.1-5+b1 -- no debconf information Thread 12 (Thre
Bug#812927: xserver-xorg-input-evdev depend on xorg-input-abi-21 - xserver-xorg-core provide xorg-input-abi-22
Source: xserver-xorg-input-evdev Version: 1:2.10.1-1 Followup-For: Bug #812927 Dear Maintainer, The xserver-xorg-input-evdev package and xserver-xorg-input-all package have both been completely removed. The lack of evdev means that xserver is now unusable, as it is lacking the evdev driver for all input devices. I would consider this a critical bug, as the system is completely unusable. I will attempt to rollback xorg, but it's a big complex messy package, and I'm pretty sure it won't work. This change in xorg:1:7.7+12: * Remove redundant xserver-xorg-input-evdev from xserver-xorg (Already in -input-all). May well be why the system allowed what is a completely broken xorg setup to occur on upgrade. I suspect many others will report this problem as they uptake the broken xorg that is in sid today. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#810986: hicolor-icon-theme: New upstream available
Package: hicolor-icon-theme Version: 0.13-1 Severity: normal Dear Maintainer, There is a newer upstream version available at https://wiki.freedesktop.org/www/Software/icon-theme/ v0.15 Without this, some contemporary software such as corebird: https://github.com/baedert/corebird fails to work properly, with missing icons. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#801904: Info received (Filed upstream)
Correction: Upstream bug filed: https://bugzilla.gnome.org/show_bug.cgi?id=757883
Bug#806463: java-package: Make-jpkg corrupts the Java Mission Control tool such that it is unable to run.
Package: java-package Version: 0.59 Severity: important Make-jpkg is breaking the packaging of the embedded eclipse that runs jmc (Java Mission Control). The tool will not run from within the installed .deb file. It runs just fine from the tar extracted directly onto disk. Error message when running JMC from installed package: Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:284) at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:238) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:273) at java.util.jar.JarVerifier.update(JarVerifier.java:228) at java.util.jar.JarFile.initializeVerifier(JarFile.java:383) at java.util.jar.JarFile.getInputStream(JarFile.java:450) at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:940) at sun.misc.Resource.cachedInputStream(Resource.java:77) at sun.misc.Resource.getByteBuffer(Resource.java:160) at java.net.URLClassLoader.defineClass(URLClassLoader.java:454) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495) Thanks! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages java-package depends on: ii debhelper9.20151117 ii dpkg-dev 1.18.3 ii fakeroot 1.20.2-1 ii libasound2 1.0.29-1 ii libfontconfig1 2.11.0-6.3 ii libgl1-mesa-glx 11.0.5-1 ii libgtk2.0-0 2.24.28-1 ii libx11-6 2:1.6.3-1 ii libxslt1.1 1.1.28-2.1 ii libxtst6 2:1.2.2-1+b1 ii libxxf86vm1 1:1.1.4-1 ii unzip6.0-20 Versions of packages java-package recommends: ii gcc 4:5.2.1-4 Versions of packages java-package suggests: ii openjdk-7-jre 7u91-2.6.3-1 -- no debconf information
Bug#801904: Filed upstream
Filed upstream bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801904 since it seems no one was looking here :(
Bug#801904: empathy: Outbound audio is not working since gst 1.6 update
Package: empathy Version: 3.12.11-1 Severity: normal Dear Maintainer, I believe that since updating gstreamer to 1.6, I have not had functioning outbound audio on telephone calls using empathy. I am unable to test, since reverting gst to 1.4.5 (~jessie) is a mammoth task. I've debugged the gstreamer pipeline (wow, it's complicated) and it seems? as if its working OK, but sound is definitely not travelling over the wire to my asterisk server. I can hear the incoming audio fine, no one can hear me, is all. When I trace the network, about every two seconds is the only time the outbound audio is sent, and it's a tiny packet as well, in contrast, there are dozens of packets from asterisk to my computer (incoming sound). Perhaps, the RTP muxer is not set up quite right with GST 1.6? I notice there are some changes in the GStreamer repo around the RTP code. Thanks Christian -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages empathy depends on: ii dbus-x11 1.10.0-3 ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii empathy-common 3.12.11-1 ii geoclue-2.0 2.3.0-2 ii gnome-icon-theme 3.12.0-1 ii gsettings-desktop-schemas3.18.0-1 ii gstreamer1.0-pulseaudio 1.6.0-1 ii libc62.19-22 ii libcairo21.14.2-2 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libchamplain-0.12-0 0.12.11-1 ii libchamplain-gtk-0.12-0 0.12.11-1 ii libcheese-gtk23 3.16.1-1 ii libclutter-1.0-0 1.24.2-1 ii libclutter-gst-2.0-0 2.0.16-1 ii libclutter-gtk-1.0-0 1.6.6-1 ii libcogl-path20 1.22.0-1 ii libcogl201.22.0-1 ii libdbus-glib-1-2 0.102-1 ii libenchant1c2a 1.6.0-10.1 ii libfarstream-0.2-2 0.2.4-1 ii libfolks-telepathy25 0.11.1-2+b1 ii libfolks25 0.11.1-2+b1 ii libgcr-base-3-1 3.18.0-1 ii libgcr-ui-3-13.18.0-1 ii libgdk-pixbuf2.0-0 2.32.1-1 ii libgee-0.8-2 0.18.0-1 ii libgeocode-glib0 3.18.0-1 ii libglib2.0-0 2.46.0-2 ii libgnutls-deb0-283.3.18-1 ii libgoa-1.0-0b3.18.0-1 ii libgstreamer-plugins-base1.0-0 1.6.0-1 ii libgstreamer1.0-01.6.0-1 ii libgtk-3-0 3.18.2-1 ii libgudev-1.0-0 230-2 ii libmission-control-plugins0 1:5.16.3-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.38.0-3 ii libpulse-mainloop-glib0 7.0-1 ii libpulse07.0-1 ii libsecret-1-00.18.3-1 ii libsoup2.4-1 2.52.1-1 ii libtelepathy-farstream3 0.6.2-1 ii libtelepathy-glib0 0.24.1-1.1 ii libtelepathy-logger3 0.8.1-1 ii libwayland-server0 1.9.0-1 ii libwebkitgtk-3.0-0 2.4.9-2+b1 ii libx11-6 2:1.6.3-1 ii libxml2 2.9.2+zdfsg1-4 ii telepathy-logger 0.8.1-1 ii telepathy-mission-control-5 1:5.16.3-1 Versions of packages empathy recommends: ii gnome-contacts 3.18.0-1+b1 ii gvfs-backends1.26.1-1 ii sound-theme-freedesktop 0.8-1 ii telepathy-gabble 0.18.3-1+b1 ii telepathy-haze 0.8.0-2 ii telepathy-salut 0.8.1-4 Versions of packages empathy suggests: ii telepathy-idle 0.2.0-2 ii vino3.18.0-1 Versions of packages empathy is related to: ii telepathy-gabble [telepathy-connection-manager] 0.18.3-1+b1 ii telepathy-haze [telepathy-connection-manager]0.8.0-2 ii telepathy-idle [telepathy-connection-manager]0.2.0-2 ii telepathy-rakia [telepathy-conn
Bug#800592: Extension "workaround"
There is an extension workaround provided at the bottom of upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=1009894: "calendar-timezones-1.2015a.xpi" Installing this into Icedove on Jessie does resolve the issue, but you have to disable cached events and refresh the calendar for the changes to show up. You can re-enable caching once the events have refreshed. I hope this helps someone who's confused about what's happening with Jessie's icedove/iceowl extension.
Bug#800592: iceowl-extension: Timezone data is out of date in Jessie. Moscow timezone is an hour out
Package: iceowl-extension Version: 31.8.0-1~deb8u1 Severity: important Dear Maintainer, * What led up to the situation? I recieved a calendar event in the Moscow timezone, and spent 30 minutes waiting for others to join. The timezone data is an hour out: https://bugzilla.mozilla.org/show_bug.cgi?id=1009894 This is a known issue with the way lightning tracks timezones - it ships its own copy of the tzdata information, which needs to be updated regularly. Sadly, it appears Jessie's iceowl-extension now contains out of date information and most of Russia is now in the wrong timezone, so calendar events are an hour out. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (399, 'experimental'), (399, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages iceowl-extension depends on: ii icedove 31.8.0-1~deb8u1 ii libc6 2.19-18 ii libgcc1 1:4.9.2-10 ii libnspr42:4.10.7-1 ii libstdc++6 4.9.2-10 Versions of packages iceowl-extension recommends: ii calendar-google-provider 31.8.0-1~deb8u1 Versions of packages iceowl-extension suggests: ii fonts-lyx 2.1.2-2 -- no debconf information
Bug#792688: empathy: Empathy doesn't show popup on incoming calls
Package: empathy Version: 3.12.10-1 Severity: normal Dear Maintainer, Hi, I upgraded to gnome 3.16 from sid and latest empathy. It seems that incoming voip calls no longer show any kind of popup allowing me to answer the call, whereas they used to in gnome 3.14. It appears that gnome 3.16 has deferred the notification to empathy, whereas it used to be handled through a telepathy handler in gnome-shell. Empathy is making the ringing tone when the call arrives, so it's obviously reached empathy, but the dialog allowing me to answer the call that is obviously supposed to show as well, is definitely not showing. I'm not sure if it's an upstream bug or not, but it's very frustrating - I've been using empathy telephony handling for a while and I have to use something else temporarily. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages empathy depends on: ii dbus-x11 1.8.18-1 ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii empathy-common 3.12.10-1 ii geoclue-2.0 2.1.10-2 ii gnome-icon-theme 3.12.0-1 ii gsettings-desktop-schemas3.16.1-1 ii gstreamer1.0-pulseaudio 1.4.5-2+b1 ii libc62.19-19 ii libcairo21.14.2-2 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libchamplain-0.12-0 0.12.10-1 ii libchamplain-gtk-0.12-0 0.12.10-1 ii libcheese-gtk23 3.16.1-1 ii libclutter-1.0-0 1.22.4-1 ii libclutter-gst-2.0-0 2.0.16-1 ii libclutter-gtk-1.0-0 1.6.2-1 ii libcogl-path20 1.20.0-2 ii libcogl201.20.0-2 ii libdbus-glib-1-2 0.102-1 ii libenchant1c2a 1.6.0-10.1 ii libfarstream-0.2-2 0.2.4-1 ii libfolks-telepathy25 0.11.1-2 ii libfolks25 0.11.1-2 ii libgcr-base-3-1 3.16.0-1 ii libgcr-ui-3-13.16.0-1 ii libgdk-pixbuf2.0-0 2.31.4-2 ii libgee-0.8-2 0.18.0-1 ii libgeocode-glib0 3.16.2-1 ii libglib2.0-0 2.44.1-1.1 ii libgnutls-deb0-283.3.16-1 ii libgoa-1.0-0b3.16.3-1 ii libgstreamer-plugins-base1.0-0 1.4.5-2 ii libgstreamer1.0-01.4.5-2 ii libgtk-3-0 3.16.5-1 ii libgudev-1.0-0 230-2 ii libmission-control-plugins0 1:5.16.3-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-3 ii libpulse-mainloop-glib0 6.0-2 ii libpulse06.0-2 ii libsecret-1-00.18.2-1 ii libsoup2.4-1 2.50.0-2 ii libtelepathy-farstream3 0.6.2-1 ii libtelepathy-glib0 0.24.1-1 ii libtelepathy-logger3 0.8.1-1 ii libwayland-server0 1.8.1-1 ii libwebkitgtk-3.0-0 2.4.9-2 ii libx11-6 2:1.6.3-1 ii libxml2 2.9.2+dfsg1-3 ii telepathy-logger 0.8.1-1 ii telepathy-mission-control-5 1:5.16.3-1 Versions of packages empathy recommends: ii gnome-contacts 3.16.2-1 ii gvfs-backends1.24.1-2+b2 ii sound-theme-freedesktop 0.8-1 ii telepathy-gabble 0.18.3-1+b1 ii telepathy-haze 0.8.0-2 ii telepathy-salut 0.8.1-4 Versions of packages empathy suggests: ii telepathy-idle 0.2.0-2 ii vino3.16.0-1 Versions of packages empathy is related to: ii telepathy-gabble [telepathy-connection-manager] 0.18.3-1+b1 ii telepathy-haze [telepathy-connection-manager]0.8.0-2 ii telepathy-idle [telepathy-connection-manager]0.2.0-2 ii telepathy-rakia [telepathy-connection-manager] 0.8.0-3 ii telepathy-salut [telepathy-connection-manager] 0.8.1-4 -- no debconf
Bug#789529: Info received (Bug#789529: Acknowledgement (gnome-settings-daemon: Segfault when usb headset is plugged in))
I can confirm that the fix in upstream bug 749844 fixes the issue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789529: Acknowledgement (gnome-settings-daemon: Segfault when usb headset is plugged in)
I have filed an upstream bug report at https://bugzilla.gnome.org/show_bug.cgi?id=751439 for this issue. I will try the fix I mention in 749844 to see if it makes a difference. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789529: gnome-settings-daemon: Segfault when usb headset is plugged in
Package: gnome-settings-daemon Version: 3.16.2-3 Severity: important Tags: upstream Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrading from jessie to sid * What exactly did you do (or not do) that was effective (or ineffective)? Unplugged my usb headset * What was the outcome of this action? gnome-settings-daemon didn't segfault on startup *** End of the template - remove these template lines *** I spent a fair bit of time diagnosing this issue. I suspect it's an upstream bug. The input to output mapping layer seems to misidentify the input (there's a couple of buttons) section of my usb headset (logitech H800) as a touchscreen input, and tries to map it into the gsettings layer, where the gsettings layer crashes because I suspect it's not got a proper GSETTINGS schema. Attached is a gdb backtrace (with full variables showing) showing where the gsettings set value is called with a usb id of my headset. (046d:0a29) Key things to notice: 1. There seem to be no debugging symbols for the gsd plugins. I had to build my own to get them. (backtrace here is from the packaged gsd). 2. g_settings_set_value is being called (it's not called in many places. Here it's being called by settings_set_display, from the input_info_remap function. It's clear that the device code here believes my headset is a touchscreen input device.) 3. The path being set is "/org/gnome/desktop/peripherals/touchscreens/046d:0a29/display". I don't know why this is failing, but it is. I suspect that other parts realize that my headset is NOT a touchscreen so the path is never initialized. Hope this helps, and thanks! Christian -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-settings-daemon depends on: ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii gsettings-desktop-schemas3.16.1-1 ii libc62.19-18 ii libcairo21.14.2-2 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libcolord2 1.2.1-1+b2 ii libcups2 1.7.5-12 ii libfontconfig1 2.11.0-6.3 ii libgdk-pixbuf2.0-0 2.31.4-2 ii libgeocode-glib0 3.16.2-1 ii libglib2.0-0 2.44.1-1 ii libgnome-desktop-3-103.16.2-2 ii libgtk-3-0 3.16.4-2 ii libgudev-1.0-0 230-1 ii libgweather-3-6 3.16.1-1 ii liblcms2-2 2.6-3+b3 ii libnm-glib4 1.0.2-2 ii libnm-util2 1.0.2-2 ii libnotify4 0.7.6-2 ii libnspr4 2:4.10.8-2 ii libnspr4-0d 2:4.10.8-2 ii libnss3 2:3.19.2-1 ii libnss3-1d 2:3.19.2-1 ii libpackagekit-glib2-18 1.0.6-1 ii libpam-systemd 220-7 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpolkit-gobject-1-00.112-5 ii libpulse-mainloop-glib0 6.0-2 ii libpulse06.0-2 ii librsvg2-2 2.40.9-2 ii libupower-glib3 0.99.3-1+b1 ii libwacom20.8-1 ii libwayland-client0 1.8.1-1 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxi6 2:1.7.4-1+b2 ii libxtst6 2:1.2.2-1+b1 ii nautilus-data3.14.2-1 Versions of packages gnome-settings-daemon recommends: ii pulseaudio 6.0-2 Versions of packages gnome-settings-daemon suggests: ii gnome-screensaver 3.6.1-4 ii kde-window-manager [x-window-manager] 4:4.11.13-2 ii metacity [x-window-manager]1:3.17.2-3+b1 ii mutter [x-window-manager] 3.16.2-2 ii x11-xserver-utils 7.7+4 -- no debconf information #0 0x76102f78 in g_bit_lock (address=addres
Bug#764716: libmutter0: SIGABRT with gnome shell 3.14, when switching workspaces sometimes
Package: libmutter0e Version: 3.14.0-1 Severity: important File: libmutter0 Dear Maintainer, When switching workspaces with gnome-shell 3.14, sometimes gnome-shell seems to crash and then reload. Its very annoying. I performed the steps in https://wiki.gnome.org/Projects/GnomeShell/Debugging and captured the following backtrace from gdb. Also, journalctl shows these lines whenever the crash occurs (not very helpful, I know). I'm reporting this to libmutter because that's the top of the stack and seems to be the cause of the crash. Oct 10 09:01:00 xx gnome-session[1837]: gnome-session[1837]: WARNING: Application 'gnome-shell.desktop' killed by signal 6 Oct 10 09:01:00 xx gnome-session[1837]: WARNING: Application 'gnome-shell.desktop' killed by signal 6 (gdb) t a a bt Thread 8 (Thread 0x7fb57b000700 (LWP 15346)): #0 0x7fb58d2690ed in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7fb58d79aee4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fb58d79affc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fb58d79b039 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fb58d7c1925 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fb58d53c0a4 in start_thread (arg=0x7fb57b000700) at pthread_create.c:309 #6 0x7fb58d271c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 7 (Thread 0x7fb57972c700 (LWP 15347)): #0 0x7fb58d2690ed in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7fb58d79aee4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fb58d79b272 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fb58df9af06 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x7fb58d7c1925 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fb58d53c0a4 in start_thread (arg=0x7fb57972c700) at pthread_create.c:309 #6 0x7fb58d271c2d in clone () ---Type to continue, or q to quit--- at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 6 (Thread 0x7fb5713eb700 (LWP 15350)): #0 0x7fb58d2690ed in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7fb58d79aee4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fb58d79affc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fb5782dd27d in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so #4 0x7fb58d7c1925 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fb58d53c0a4 in start_thread (arg=0x7fb5713eb700) at pthread_create.c:309 #6 0x7fb58d271c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 5 (Thread 0x7fb570bea700 (LWP 15351)): #0 0x7fb58d2690ed in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7fb5893dfc20 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #2 0x7fb5893cc258 in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #3 0x7fb5893cc619 in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #4 0x7fb5893cc68b in pa_mainloop_run () ---Type to continue, or q to quit--- from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #5 0x7fb5893dfc9d in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #6 0x7fb57f60cac8 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-5.0.so #7 0x7fb58d53c0a4 in start_thread (arg=0x7fb570bea700) at pthread_create.c:309 #8 0x7fb58d271c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 4 (Thread 0x7fb55fffe700 (LWP 15352)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fb57eb742fd in PR_WaitCondVar () from /usr/lib/x86_64-linux-gnu/libnspr4.so #2 0x7fb588dd4b34 in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #3 0x7fb57eb79848 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so #4 0x7fb58d53c0a4 in start_thread (arg=0x7fb55fffe700) at pthread_create.c:309 #5 0x7fb58d271c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7fb55f7fd700 (LWP 15353)): #0 pthread_cond_wait@@GLIBC_2.3.2 () ---Type to continue, or q to quit--- at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fb57eb742fd in PR_WaitCondVar () from /usr/lib/x86_64-linux-gnu/libnspr4.so #2 0x7fb588e47f2e in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #3 0x7fb57eb79848 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so #4 0x7fb58d53c0a4 in start_thread (arg=0x7fb55f7fd700) at pthread_create.c:309 #5 0x7fb58d271c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7fb5907bca40 (LWP 8072)): #0 0x7fb58d1c1077 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7fb58d1c2458 in __GI_abort () at abort.c:89 #2 0x00
Bug#764715: gnome-shell: Missing dependency on mutter
Package: gnome-shell Version: 3.14.0-1 Severity: normal Dear Maintainer, Mutter is now shipping a "restart helper" program that provides for a "smoother" gnome shell restart experience. Gnome-shell 3.14 doesn't depend on mutter, just libmutter, and so the helper is not available by default. Oct 09 14:17:42 xx gnome-session[4990]: Window manager warning: Failed to start restart helper: Failed to execute child process "/usr/lib/mutter/mutter-restart-helper" (No such file or directory) Installing mutter allows the shell to do the "pretty" restart. Restart helper added here: https://mail.gnome.org/archives/commits-list/2014-July/msg04103.html Hope this helps Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'stable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii evolution-data-server3.12.6-1.1 ii gir1.2-accountsservice-1.0 0.6.37-3+b1 ii gir1.2-atspi-2.0 2.14.0-1 ii gir1.2-caribou-1.0 0.4.15-1 ii gir1.2-clutter-1.0 1.20.0-1 ii gir1.2-freedesktop 1.42.0-2 ii gir1.2-gcr-3 3.14.0-2 ii gir1.2-gdesktopenums-3.0 3.14.0-1 ii gir1.2-gdm3 3.14.0-1 ii gir1.2-gkbd-3.0 3.6.0-1 ii gir1.2-glib-2.0 1.42.0-2 ii gir1.2-gnomebluetooth-1.03.14.0-1 ii gir1.2-gnomedesktop-3.0 3.14.0-1 ii gir1.2-gtk-3.0 3.14.1-1 ii gir1.2-ibus-1.0 1.5.8-3 ii gir1.2-mutter-3.03.14.0-1 ii gir1.2-networkmanager-1.00.9.10.0-3 ii gir1.2-nmgtk-1.0 0.9.10.0-2 ii gir1.2-pango-1.0 1.36.8-2 ii gir1.2-polkit-1.00.112-3 ii gir1.2-soup-2.4 2.48.0-1 ii gir1.2-telepathyglib-0.120.24.1-1 ii gir1.2-telepathylogger-0.2 0.8.1-1 ii gir1.2-upowerglib-1.00.99.1-3 ii gjs 1.42.0-1 ii gnome-backgrounds3.14.0-1 ii gnome-icon-theme-symbolic3.12.0-1 ii gnome-settings-daemon3.14.0-2 ii gnome-shell-common 3.14.0-1 ii gnome-themes-standard3.14.0-1 ii gsettings-desktop-schemas3.14.0-1 ii libatk-bridge2.0-0 2.14.0-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-11 ii libcairo21.12.16-5 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libclutter-1.0-0 1.20.0-1 ii libcogl-pango20 1.18.2-2 ii libcogl201.18.2-2 ii libcroco30.6.8-3 ii libdbus-glib-1-2 0.102-1 ii libecal-1.2-16 3.12.6-1.1 ii libedataserver-1.2-183.12.6-1.1 ii libgcr-base-3-1 3.14.0-2 ii libgdk-pixbuf2.0-0 2.31.1-2 ii libgirepository-1.0-11.42.0-2 ii libgjs0e [libgjs0-libmozjs-24-0] 1.42.0-1 ii libglib2.0-0 2.42.0-2 ii libgstreamer1.0-01.4.3-1 ii libgtk-3-0 3.14.1-1 ii libical1 1.0-1 ii libjson-glib-1.0-0 1.0.2-1 ii libmozjs-24-024.2.0-2 ii libmutter0e 3.14.0-1 ii libnm-glib4 0.9.10.0-3 ii libnm-util2 0.9.10.0-3 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpolkit-agent-1-0 0.112-3 ii libpolkit-gobject-1-00.112-3 ii libpulse-mainloop-glib0 5.0-6+b1 ii libpulse05.0-6+b1 ii libsecret-1-00.18-1+b1 ii libstartup-notification0 0.12-4 ii libsystemd0 215-5+b1 ii libtelepathy-
Bug#757952: libvirt-daemon-system: upgrade from 1.2.4-3 to 1.2.7-6 fails- the old daemon is still running
Package: libvirt-daemon-system Version: 1.2.7-6 Severity: normal Dear Maintainer, I just ran a dist-upgrade to uptake the latest sid updates. libvirt appears to have upgraded from 1.2.4-3 to 1.2.7-6, and is failing during upgrade. # dpkg --configure --pending Setting up libvirt-daemon-system (1.2.7-6) ... Job for libvirtd.service failed. See 'systemctl status libvirtd.service' and 'journalctl -xn' for details. invoke-rc.d: initscript libvirtd, action "start" failed. dpkg: error processing package libvirt-daemon-system (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of libvirt-bin: libvirt-bin depends on libvirt-daemon-system (>= 1.2.7-6); however: Package libvirt-daemon-system is not configured yet. dpkg: error processing package libvirt-bin (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of gnome-boxes: gnome-boxes depends on libvirt-bin; however: Package libvirt-bin is not configured yet. dpkg: error processing package gnome-boxes (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: libvirt-daemon-system libvirt-bin gnome-boxes The systemd journal doesn't contain much that is useful: # systemctl status libvirtd.service libvirtd.service - Virtualization daemon Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled) Active: failed (Result: start-limit) since Tue 2014-08-12 13:13:10 EDT; 4min 55s ago Docs: man:libvirtd(8) http://libvirt.org Process: 11588 ExecStart=/usr/sbin/libvirtd $libvirtd_opts (code=exited, status=1/FAILURE) Main PID: 11588 (code=exited, status=1/FAILURE) CGroup: /system.slice/libvirtd.service Aug 12 13:13:10 smartie systemd[1]: Failed to start Virtualization daemon. Aug 12 13:13:10 smartie systemd[1]: Unit libvirtd.service entered failed state. Aug 12 13:13:10 smartie systemd[1]: libvirtd.service holdoff time over, scheduling restart. Aug 12 13:13:10 smartie systemd[1]: Stopping Virtualization daemon... Aug 12 13:13:10 smartie systemd[1]: Starting Virtualization daemon... Aug 12 13:13:10 smartie systemd[1]: libvirtd.service start request repeated too quickly, refus...art. Aug 12 13:13:10 smartie systemd[1]: Failed to start Virtualization daemon. Aug 12 13:13:10 smartie systemd[1]: Unit libvirtd.service entered failed state. However, running the daemon doesn't work: # libvirtd 2014-08-12 17:19:27.217+: 11832: info : libvirt version: 1.2.7, package: 6 (root 2014-08-08-16:09:22 bogon) 2014-08-12 17:19:27.217+: 11832: error : virPidFileAcquirePath:414 : Failed to acquire pid file '/var/run/libvirtd.pid': Resource temporarily unavailable It appears the pid file already exists, owned by the previous libvirt daemon: # ps aux | fgrep virt root 1202 0.0 0.0 413344 15744 ?Ssl Aug08 0:00 /usr/sbin/libvirtd My guess: you're not shutting down the old daemon during the upgrade. Killing the old daemon fixes the issue: root@smartie:~# kill 1202 root@smartie:~# root@smartie:~# root@smartie:~# dpkg --configure --pending Setting up libvirt-daemon-system (1.2.7-6) ... Setting up libvirt-bin (1.2.7-6) ... Setting up gnome-boxes (3.12.3-1) ... I hope this helps. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'stable'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvirt-daemon-system depends on: ii adduser 3.113+nmu3 ii gettext-base 0.19.2-1 ii init-system-helpers 1.20 ii libapparmor1 2.8.0-5.1+b1 ii libaudit11:2.3.7-1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libblkid12.20.1-5.8 ii libc62.19-7 ii libcap-ng0 0.7.3-1.1 ii libdbus-1-3 1.8.6-1 ii libdevmapper1.02.1 2:1.02.85-2 ii libgnutls-deb0-283.2.16-1 ii libnl-3-200 3.2.24-2 ii libnl-route-3-2003.2.24-2 ii libnuma1 2.0.9-1 ii librados20.80.5-1 ii librbd1 0.80.5-1 ii libsasl2-2 2.1.26.dfsg1-11 ii libselinux1 2.3-1 ii libssh2-11.4.3-3 ii libsystemd-daemon0 208-7 ii libvirt-clients 1.2.7-6 ii libvirt-daemon 1.2.7-6 ii libvirt0 1.2.7-6 ii libxml2 2.9.1+dfsg1-4 ii libyajl2 2.1.0-1 ii logrotate3.8.7-1 Versions of packages libvirt-daemon-system recommends: ii bridge-utils 1.5-9 ii dmidecode 2.12-3 ii dnsmasq-base 2.71-1 ii ebtables 2.0.10.4-3 ii iproute2 3.16.0-1 ii iptables 1.4.21-2 ii parted3.2-4 ii pm-utils 1.4.1-15 Versions of packages libvirt-daemon-system suggests: pn app
Bug#751169: libc6: Segmentation fault during libc upgrade, leaving system very unstable
Hi, On 10/06/14 05:50 PM, Aurelien Jarno wrote: Hi, On Tue, Jun 10, 2014 at 04:49:34PM -0400, Christian Weeks wrote: Package: libc6 Severity: important Dear Maintainer, Whenever I upgrade either elibc or gcc, my system enters a state where almost all software segmentation faults, including the upgrade itself. This happens repeatably on any upgrade of either of those packages, and has done for some time. I finally managed to capture a trace of the upgrade in progress which is why I am filing this report now. I have attached the output of both the upgrade output and my subsequent repair. There are 3 phases: the original upgrade, the first pass at repair (using dpkg), and finally the second pass at repair, which is exactly the same command as the first pass, but works completely. If I run dpkg -i with the list of packages seen (libc6:amd64, libc6:i386,libgcc:amd64,libgcc:i386) then the system becomes usable again. In this case, and very often when I do this repair, I have to run it twice to actually get the "repair" to stick. It appears the problem is when libc is deconfigured for upgrade. libgcc stops functioning (it depends on libc, obviously) and the segmentation fault means dpkg is unable to recover (I guess one of the configure scripts is failing). The segmentation fault is likely due to some incompatible libc version being mixed, one being the unpacked version, one being on the filesystem at a different location. I suspect the problem is somehow related to multi-arch, since it seems that multiarch is causing one side to deconfigure, breaking that side and then creating a dependency conflict situation. Indeed, we also suspect it is related to that. I am only filing this as important because obviously it breaks my system but it is recoverable. The non-existence of others reporting this makes me wonder if there isn't something weird, however, I have two machines and both exhibit the same symptoms. We already have one bug similar to yours (#741031) although it concerns the previous upgrade from 2.17 to 2.18. Unfortunately we are not able to understand the bug, as we have not been able to get a status of the system *before* any repair action is taken. Do you by chance still have a system in the broken state? If so, could you please send us the output of: dpkg -l "libc*" ls -l /lib /lib32 /lib64 /lib/i386-linux-gnu/ /lib/x86_64-linux-gnu/ Sadly, I don't have a broken state right now. I just tried on another machine, as jessie just got libc6 2.19 - however this issue did not occur there, and I noticed that libgcc did not update in jessie simultaneously. I wonder if you have to update both at once to cause the problem to occur. I've only noticed it when libgcc and libc have simultaneously updated previously, though this could be selective memory on my part. Next time gcc and libc update simultaneously, I'll capture pre-break and post-break state for your perusal, before fixing it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751169: libc6: Segmentation fault during libc upgrade, leaving system very unstable
Package: libc6 Severity: important Dear Maintainer, Whenever I upgrade either elibc or gcc, my system enters a state where almost all software segmentation faults, including the upgrade itself. This happens repeatably on any upgrade of either of those packages, and has done for some time. I finally managed to capture a trace of the upgrade in progress which is why I am filing this report now. I have attached the output of both the upgrade output and my subsequent repair. There are 3 phases: the original upgrade, the first pass at repair (using dpkg), and finally the second pass at repair, which is exactly the same command as the first pass, but works completely. If I run dpkg -i with the list of packages seen (libc6:amd64, libc6:i386,libgcc:amd64,libgcc:i386) then the system becomes usable again. In this case, and very often when I do this repair, I have to run it twice to actually get the "repair" to stick. It appears the problem is when libc is deconfigured for upgrade. libgcc stops functioning (it depends on libc, obviously) and the segmentation fault means dpkg is unable to recover (I guess one of the configure scripts is failing). I suspect the problem is somehow related to multi-arch, since it seems that multiarch is causing one side to deconfigure, breaking that side and then creating a dependency conflict situation. I am only filing this as important because obviously it breaks my system but it is recoverable. The non-existence of others reporting this makes me wonder if there isn't something weird, however, I have two machines and both exhibit the same symptoms. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'stable'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Phase 1: the original upgrade. Extracting templates from packages: 100% Preconfiguring packages ... (Reading database ... 313318 files and directories currently installed.) Preparing to unpack .../locales_2.19-1_all.deb ... Unpacking locales (2.19-1) over (2.18-7) ... Preparing to unpack .../archives/libc6_2.19-1_i386.deb ... De-configuring libc6:amd64 (2.18-7) ... Checking for services that may need to be restarted... Checking init scripts... Unpacking libc6:i386 (2.19-1) over (2.18-7) ... Preparing to unpack .../libc6_2.19-1_amd64.deb ... dpkg: error processing archive /var/cache/apt/archives/libc6_2.19-1_amd64.deb (--unpack): subprocess new pre-installation script was killed by signal (Segmentation fault) Preparing to unpack .../libgcc1_1%3a4.9.0-6_i386.deb ... De-configuring libgcc1:amd64 (1:4.9.0-5) ... Unpacking libgcc1:i386 (1:4.9.0-6) over (1:4.9.0-5) ... Preparing to unpack .../libgcc1_1%3a4.9.0-6_amd64.deb ... Unpacking libgcc1:amd64 (1:4.9.0-6) over (1:4.9.0-5) ... Preparing to unpack .../gcc-4.9-base_4.9.0-6_i386.deb ... De-configuring gcc-4.9-base:amd64 (4.9.0-5) ... Unpacking gcc-4.9-base:i386 (4.9.0-6) over (4.9.0-5) ... Preparing to unpack .../gcc-4.9-base_4.9.0-6_amd64.deb ... Unpacking gcc-4.9-base:amd64 (4.9.0-6) over (4.9.0-5) ... Processing triggers for man-db (2.6.7.1-1) ... dpkg: error processing package man-db (--unpack): subprocess installed post-installation script was killed by signal (Segmentation fault) Errors were encountered while processing: /var/cache/apt/archives/libc6_2.19-1_amd64.deb man-db E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up man-db (2.6.7.1-1) ... dpkg: error processing package man-db (--configure): subprocess installed post-installation script was killed by signal (Segmentation fault) dpkg: dependency problems prevent configuration of locales: locales depends on glibc-2.19-1; however: Package glibc-2.19-1 is not installed. dpkg: error processing package locales (--configure): dependency problems - leaving unconfigured Setting up gcc-4.9-base:amd64 (4.9.0-6) ... Setting up gcc-4.9-base:i386 (4.9.0-6) ... dpkg: error processing package libc6:i386 (--configure): package libc6:i386 2.19-1 cannot be configured because libc6:amd64 is at a different version (2.18-7) Setting up libgcc1:amd64 (1:4.9.0-6) ... dpkg: dependency problems prevent configuration of libgcc1:i386: libgcc1:i386 depends on libc6 (>= 2.2.4); however: Package libc6:i386 is not configured yet. dpkg: error processing package libgcc1:i386 (--configure): dependency problems - leaving unconfigured Processing triggers for libc-bin (2.18-7) ... Errors were encountered while processing: man-db locales libc6:i386 libgcc1:i386 Phase 2: repair attempt #1 dpkg -i /var/cache/apt/archives/libc6_2.19-1_i386.deb /var/cache/apt/archives/libc6-i686_2.19-1_i386.deb /var/cache/apt/archives/libc6_2.19-1_amd64.deb /var/cache/apt/archives/libgcc1_1%3a4.9.0-6_i386.deb /var/cache/apt/archives/libgcc1_1%3
Bug#748892: file: Many zip files are being misidentified as Microsoft Office OOXML
Package: file Version: 1:5.18-1 Severity: normal There are many files that are plain zip files being misidentified as Microsoft Office OOXML. A file for testing can be downloaded from Oracle: http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html?ssSourceSiteId=otnpt The version 4.0.2 is identified as Microsoft Office OOXML. Many others that include plain text near the start seem to be misidentified as well: ReproComposites.zip: Microsoft OOXML sqldeveloper-4.0.0.13.80-no-jre.zip: Microsoft OOXML sqldeveloper-4.0.2.15.21-no-jre.zip: Microsoft OOXML All of the above are actually zip files. Thanks! Christian -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'stable'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages file depends on: ii libc6 2.18-6 ii libmagic1 1:5.18-1 ii zlib1g 1:1.2.8.dfsg-1 file recommends no packages. file 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#748699: libgtk-3-0: ListView hammers a11y via dbus causing slow response in many gtk applications
Package: libgtk-3-0 Version: 3.12 Severity: important Tags: upstream Dear Maintainer, This problem has been uncovered using the libgtk + other gnome components from experimental. It was found for me when using synaptic, however, other reports involve other applications with large listviews. Upstream has a bug https://bugzilla.gnome.org/show_bug.cgi?id=730118 I felt it important to log it here though so debian users can find this - it took me two days to discover what the cause was. Using the workaround (NO_AT_BRIDGE=1 ) has worked for me for synaptic, and rhythmbox. Hope this helps! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'stable'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 01:11 PM, Andreas Beckmann wrote: On 2013-04-07 18:58, Christian Weeks wrote: OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. and having a bad version number that looks like an official Debian package Sorry about that. It's because I try and pbuild exactly what's in the git. (Not subversion like I said before- this is all from the pkg-xorg sub projects- wayland and mesa and, with the recent updates, now libdrm too *sigh*). I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. probably an intentional library rename done by upstream you'll have to divert libGL.so.1.2.0 to move it away from /usr/lib/, otherwise ldconfig (which is run from many maintainer scripts - so nearly every packaging operation "breaks" the setup) will always recreate (and overwrite) the libGL.so.1 link Ah, yes, OK, that's the guilty party here then I guess. I'll see what I can come up with and share it here. No doubt others are or will soon be in the same boat. Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 12:52 PM, Andreas Beckmann wrote: Control: severity -1 wishlist Control: retitle -1 does not divert libGL.so.1.2.0 from mesa 9.0.1-1 On 2013-04-07 18:26, Christian Weeks wrote: Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 This is not the Debian libgl1-mesa-glx. That would contain /usr/lib/x86_64-linux-gnu/libGL.so.1.2 which is properly diverted. On 2013-04-07 18:30, Christian Weeks wrote: Versions of packages glx-diversions is related to: ii libgl1-mesa-glx [libgl1] 9.0.1-1 Exactly :-) $ rmadison --arch amd64 libgl1-mesa-glx libgl1-mesa-glx | 7.7.1-5 | squeeze | amd64 libgl1-mesa-glx | 7.10.3-4~bpo60+1 | squeeze-backports | amd64 libgl1-mesa-glx | 8.0.5-4 | wheezy| amd64 libgl1-mesa-glx | 8.0.5-4 | sid | amd64 Andreas OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-diversions: More system information
Package: glx-diversions Version: 0.2.90 Followup-For: Bug #704914 Data from reportbug -- Package-specific info: Diversions: diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib32/libGL.so to /usr/lib32/nvidia/diversions/libGL.so by libgl1-nvidia-alternatives-ia32 diversion of /usr/lib32/libGL.so.1 to /usr/lib32/nvidia/diversions/libGL.so.1 by libgl1-nvidia-alternatives-ia32 diversion of /usr/lib32/libGL.so.1.2 to /usr/lib32/nvidia/diversions/libGL.so.1.2 by libgl1-nvidia-alternatives-ia32 /usr/lib/mesa-diverted: total 64 drwxr-xr-x 4 root root 4096 Oct 1 2012 . drwxr-xr-x 236 root root 49152 Apr 7 11:36 .. drwxr-xr-x 2 root root 4096 Mar 18 12:30 i386-linux-gnu drwxr-xr-x 2 root root 4096 Mar 18 12:31 x86_64-linux-gnu /usr/lib/mesa-diverted/i386-linux-gnu/: total 8 drwxr-xr-x 2 root root 4096 Mar 18 12:30 . drwxr-xr-x 4 root root 4096 Oct 1 2012 .. lrwxrwxrwx 1 root root 14 Dec 29 23:03 libGL.so.1 -> libGL.so.1.2.0 /usr/lib/mesa-diverted/x86_64-linux-gnu/: total 8 drwxr-xr-x 2 root root 4096 Mar 18 12:31 . drwxr-xr-x 4 root root 4096 Oct 1 2012 .. lrwxrwxrwx 1 root root 14 Dec 29 22:24 libGL.so -> libGL.so.1.6.0 lrwxrwxrwx 1 root root 14 Dec 29 22:24 libGL.so.1 -> libGL.so.1.2.0 Alternative 'glx': glx - auto mode link currently points to /usr/lib/nvidia /usr/lib/nvidia - priority 100 slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 slave glx--libGL.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 slave glx--libnvidia-cfg.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 slave glx--libnvidia-cfg.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 slave glx--linux-libglx.so: /usr/lib/nvidia/libglx.so slave glx--nvidia-blacklists-nouveau.conf: /etc/nvidia/nvidia-blacklists-nouveau.conf slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh slave glx--nvidia_drv.so: /usr/lib/nvidia/nvidia_drv.so Current 'best' version is '/usr/lib/nvidia'. lrwxrwxrwx 1 root root 15 Apr 7 12:23 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 41 Apr 7 12:23 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Apr 7 12:23 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Apr 7 12:23 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 51 Apr 7 12:23 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Apr 7 12:23 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Apr 7 12:23 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Apr 7 12:23 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Apr 7 12:23 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so File System: lrwxrwxrwx 1 root root 21 Apr 7 09:54 /usr/lib/glx -> /etc/alternatives/glx lrwxrwxrwx 1 root root 48 Apr 7 12:23 /usr/lib/i386-linux-gnu/libGL.so.1 -> /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -rw-r--r-- 1 root root 387532 Dec 29 23:03 /usr/lib/i386-linux-gnu/libGL.so.1.2.0 lrwxrwxrwx 1 root root 50 Apr 7 12:23 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 431600 Feb 23 09:57 /usr/lib/xorg/modules/extensions/libglx.so -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (501, 'unstable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU core
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 12:17 PM, Andreas Beckmann wrote: Control: reassign -1 glx-diversions 0.2.90 Control: tag -1 moreinfo On 2013-04-07 17:43, Christian Weeks wrote: There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other "current" parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). I'm sorry, but what exactly is the problem you experienced? libGL is brokenly referring to the libgl from mesa whereas it should be referring to the libGL from the nvidia packages. This breaks the gnome desktop. Gnome shell fails to start with an error, or any gnome application fails to launch, as the link is gone, replaced by the actual lib from that libgl-mesa-glx package. This affects almost all desktop applications that are linked against gnome. This is with the current gnome 3.8 environment in experimental. The only fix is to re-run "update-alternatives --configure glx", which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. So what is broken before this command and fixed afterwards? Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 Running the command: # update-alternatives --config glx There is only one alternative in link group glx (providing /usr/lib/glx): /usr/lib/nvidia Nothing to configure. update-alternatives: warning: forcing reinstallation of alternative /usr/lib/nvidia because link group glx is broken After: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 Apr 7 12:23 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu If I do not run this command, after any package installation or update, Gnome is completely broken, because mesa isn't functional on this system, because it is using the NVIDIA libraries. # dpkg --remove libgl1-mesa-glx:amd64 and why would you want to do that? Because it's the wrong thing for this system? It keeps replacing the nvidia GL with it's own? But I added it here because it shows how the libgl1 virtual dependency has crept from the base packages into the gnome packages. Unfortunately you reported this against the source package, so no scripts were run that could collect additional information. I've reassigned this bug to the glx-diversions package, please run reportbug -N 704914 on the *broken* system, that should collect some helpful information. Acknowledged. That'll be run forthwith. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
Source: glx-alternatives Version: 0.2.90 Severity: grave Justification: renders package unusable There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other "current" parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). This means the gnome desktop in 3.8 is NOT co-installable with nvidia graphics drivers, a situation this diversion was meant to prevent. The only fix is to re-run "update-alternatives --configure glx", which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. I read bug 389971, on the reasons the nvidia-glx* packages don't directly provide libgl1, but it may be that unless the gnome team changes their libgl deps, this might be the only solution (or, alternatively, making the glx-alternatives packages provide libgl1?) It should be noted, that the nvidia alternative clearly *works*, however, making it so is pretty challenging. Info on my system as it stands at present: # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1 diversion by glx-diversions from: /usr/lib/x86_64-linux-gnu/libGL.so.1 diversion by glx-diversions to: /usr/lib/mesa-diverted/x86_64-linux- gnu/libGL.so.1 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1 # dpkg --remove libgl1-mesa-glx:amd64 dpkg: dependency problems prevent removal of libgl1-mesa-glx:amd64: gnome-session-bin depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. libvisual-0.4-plugins:amd64 depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. libglew1.7:amd64 depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. enblend depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. mplayer depends on libgl1-mesa-glx | libgl1; however: Package libgl1-me dpkg: error processing libgl1-mesa-glx:amd64 (--remove): dependency problems - not removing Errors were encountered while processing: libgl1-mesa-glx:amd64 Thanks Christian -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (501, 'unstable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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#649334: accountsservice: Doesn't play nicely with LDAP
Package: accountsservice Version: 0.6.15-1 Severity: important Dear Maintainer, I run an LDAP enabled system. I use the pam-ldapd versions, rather than the older pam-ldap versions. Network manager is installed and working well. The system also runs systemd. Sometimes (it's clearly a bit of a race condition) gdm won't allow me to login to an LDAP account. Killing GDM doesn't help. getent passwd shows that the nsswitch is working fine and loads the LDAP accounts. GDM login screens remain frustratingly non-working however. To fix the problem I have to kill the accountsservice/accounts-daemon process that's running. I think GDM respawns it, but I'm not sure. However, it's clear that accountsservice/accounts-daemon loaded prior to LDAP becoming available because it beat the network in coming up. It should probably be a bit smarter in how it works with pam/nss to resolve users and authorization. As a corollary if accountsservice beats the network and doesn't know the LDAP users, GDM won't show them in the user list. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (501, 'unstable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages accountsservice depends on: ii dbus 1.5.8-1 ii libaccountsservice00.6.15-1 ii libc6 2.13-21 ii libdbus-1-31.5.8-1 ii libdbus-glib-1-2 0.98-1 ii libglib2.0-0 2.30.2-4 ii libpolkit-gobject-1-0 0.102-1 accountsservice recommends no packages. Versions of packages accountsservice suggests: ii gnome-control-center 1:3.2.2-1 -- 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#622881: Info received (Bug#622881: Acknowledgement (systemd with dbus requires /var/run/dbus/ directory at boot which isn't created))
I agree, the circularity is the problem, but the means of resolving the circular depends is clearly a bit lacking if it results in killing essential services for trivial ones that are just badly configured. I agree that the nfs-common and rpcbind services are both in the wrong, but it doesn't mean that systemd shouldn't be able to do a better job of ignoring the problem. Perhaps, if it sees rcS and rcN runlevels for a service, it should demote them to rcN and issue a big fat warning. Thanks for looking anyway Christian On 16/04/11 01:24 AM, Tollef Fog Heen wrote: ]] Christian Weeks | OK, so I've found the root cause. nfs-common and rpcbind both have | Default-Start: S and create symlinks in /etc/rcS.d/ This appears to | confuse systemd which makes them a dependent of | sysinit.target. nfs-common.service and rpcbind.service meta-services | created by systemd are already dependent on basic.target. This causes | a loop and the loop breaking kills (among other things!) dbus.socket | to break the loop. This is NOT GOOD. Well, the circular depends are the problem, not the loop breaking. The problem is that nfs-common and rcpbind both try to start in rcS.d and rcN.d. It's not at all clear why some maintainers thinks that makes any sort of sense. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622881: Info received (Bug#622881: Acknowledgement (systemd with dbus requires /var/run/dbus/ directory at boot which isn't created))
retitle systemd causes dbus socket init failure if sysv init files are flagged as Default-start:S thanks OK, so I've found the root cause. nfs-common and rpcbind both have Default-Start: S and create symlinks in /etc/rcS.d/ This appears to confuse systemd which makes them a dependent of sysinit.target. nfs-common.service and rpcbind.service meta-services created by systemd are already dependent on basic.target. This causes a loop and the loop breaking kills (among other things!) dbus.socket to break the loop. This is NOT GOOD. Probably, systemd wants to be a little more cautious about the things it depends sysinit.target on, so that fundamental system services like dbus don't get killed by rogue sysv services in the S startup group. Hope this helps Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622881: Acknowledgement (systemd with dbus requires /var/run/dbus/ directory at boot which isn't created)
As a further discovery I found this in one of my startup log files. It explains why dbus.socket didn't start: Apr 15 09:51:18 allie kernel: [6.223804] systemd[1]: Found ordering cycle on basic.target/start Apr 15 09:51:18 allie kernel: [6.223996] systemd[1]: Walked on cycle path to sockets.target/start Apr 15 09:51:18 allie kernel: [6.224185] systemd[1]: Walked on cycle path to dbus.socket/start Apr 15 09:51:18 allie kernel: [6.224370] systemd[1]: Walked on cycle path to sysinit.target/start Apr 15 09:51:18 allie kernel: [6.224559] systemd[1]: Walked on cycle path to rpcbind.service/start Apr 15 09:51:18 allie kernel: [6.224744] systemd[1]: Walked on cycle path to basic.target/start Apr 15 09:51:18 allie kernel: [6.224931] systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start Apr 15 09:51:18 allie kernel: [6.225152] systemd[1]: Found ordering cycle on basic.target/start Apr 15 09:51:18 allie kernel: [6.225337] systemd[1]: Walked on cycle path to sockets.target/start Apr 15 09:51:18 allie kernel: [6.225526] systemd[1]: Walked on cycle path to avahi-daemon.socket/start Apr 15 09:51:18 allie kernel: [6.225716] systemd[1]: Walked on cycle path to sysinit.target/start Apr 15 09:51:18 allie kernel: [6.225905] systemd[1]: Walked on cycle path to rpcbind.service/start Apr 15 09:51:18 allie kernel: [6.226094] systemd[1]: Walked on cycle path to basic.target/start Apr 15 09:51:18 allie kernel: [6.226283] systemd[1]: Breaking ordering cycle by deleting job avahi-daemon.socket/start Apr 15 09:51:18 allie kernel: [6.226506] systemd[1]: Found ordering cycle on basic.target/start Apr 15 09:51:18 allie kernel: [6.226689] systemd[1]: Walked on cycle path to sysinit.target/start Apr 15 09:51:18 allie kernel: [6.226878] systemd[1]: Walked on cycle path to rpcbind.service/start Apr 15 09:51:18 allie kernel: [6.227066] systemd[1]: Walked on cycle path to basic.target/start Apr 15 09:51:18 allie kernel: [6.227253] systemd[1]: Breaking ordering cycle by deleting job rpcbind.service/start Apr 15 09:51:18 allie kernel: [6.227475] systemd[1]: Found ordering cycle on basic.target/start Apr 15 09:51:18 allie kernel: [6.227670] systemd[1]: Walked on cycle path to sysinit.target/start Apr 15 09:51:18 allie kernel: [6.227857] systemd[1]: Walked on cycle path to nfs-common.service/start Apr 15 09:51:18 allie kernel: [6.228043] systemd[1]: Walked on cycle path to basic.target/start Apr 15 09:51:18 allie kernel: [6.228230] systemd[1]: Breaking ordering cycle by deleting job nfs-common.service/start However, it raises a new question. Why is there a cycle... It looks like nfs-common and rpcbind are both wanted by sysinit, but I can't see why... Given that this is breaking the startup pretty badly to have these nfs services in there, I'm going to look at removing them... Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622881: systemd with dbus requires /var/run/dbus/ directory at boot which isn't created
Package: systemd Version: 20-1 Severity: important Since recently my computer doesn't boot correctly with systemd installed. Network and graphical desktop don't start for example. Errors from network- manager indicate that it can't connect the dbus system socket at /var/run/dbus/system_bus_socket. Examination indicates that this file is on a temp filesystem mounted at boot time and so it doesn't get created or something dunring the boot sequence. If I create the directory manually then stop and start dbus through systemctl I can then carry on to start network-manager and gdm normally. However, this is very frustrating because it means my computer just won't boot normally. One oddity is that if I start it using the grub "rescue" mode, this problem doesn't occur. I am therefore suspicious that during the normal boot sequence this mount overwrites the systemd dbus socket. Perhaps there's a systemd incompatibility with something early on in the boot sequence that causes /var/run to be mounted as a tmpfs? dbus: Installed: 1.4.6-1 network-manager: Installed: 0.8.3.999-1 Interestingly the owner of /var/run is mountkernfs.sh as you probably know. However, $RAMRUN is no in my environment: root@allie:/etc/default# fgrep RAMRUN * rcS:RAMRUN=no Yet it is clearly mounted as a tmpfs: root@allie:/etc/default# mount | fgrep /var/run tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) But it's not in fstab: root@allie:/etc/default# cat /etc/fstab # /etc/fstab: static file system information. # # Use 'vol_id --uuid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # proc/proc procdefaults0 0 # / was on /dev/sdc2 during installation UUID=6ed62e14-2a42-450e-9b1c-8a395564bdf4 / ext4errors =remount-ro,discard 0 1 # /home was on /dev/sdd2 during installation UUID=7b1c0169-dbb6-4b16-9c20-c7d91268e186 /home ext4defaults 0 2 # swap was on /dev/sdc1 during installation UUID=ee759df1-f898-4171-b04a-b3e66b38696e noneswapsw 0 0 mediacentre:/ /media/mediacentre nfs4 defaults,user,noauto0 0 (as you can see this was a fairly fresh install from late last year using squeeze almost release then upgraded to sid). I think that the problem may be with /lib/systemd/system/var-run.mount. This appears to be remounting /var/run, and probably stamping on the existing dbus socket listener in the dbus subdir. Thoughts? Christian -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (701, 'unstable'), (601, 'testing'), (501, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii libaudit01.7.13-1+b2 Dynamic library for security audit ii libc62.11.2-13 Embedded GNU C Library: Shared lib ii libcap2 1:2.20-1support for getting/setting POSIX. ii libcryptsetup1 2:1.2.0-2 libcryptsetup shared library ii libdbus-1-3 1.4.6-1 simple interprocess messaging syst ii libpam0g 1.1.2-2 Pluggable Authentication Modules l ii libselinux1 2.0.96-1SELinux runtime shared libraries ii libudev0 167-2 libudev shared library ii libwrap0 7.6.q-19Wietse Venema's TCP wrappers libra ii util-linux 2.17.2-9.1 Miscellaneous system utilities Versions of packages systemd recommends: ii libpam-systemd20-1 system and service manager - PAM m Versions of packages systemd suggests: ii systemd-gui 20-1 system and service manager - GUI -- 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#594416: nvidia-graphics-drivers: Breaking some GL applications linked to mesa
On Wed, 2010-08-25 at 23:39 +0200, Andreas Beckmann wrote: > On 2010-08-25 22:35, Christian Weeks wrote: > > Found a problem with your diversion setup code. For some reason I had an old > > version of libGL.so.1 lying around linked directly to a file outside of dpkg > > control (probably last time I ran the installer directly from NVIDIA a few > > years ago). > > Unless there is an easy fix, this is an unsupported setup. > I know. But recovering to a "supported" setup was my goal those many moons ago. I never noticed the problem until today. The fix was very simple indeed: force the alternatives links onto /usr/lib/libGL.* Here's a listing of what had accidently gotten dropped there: allie:/usr/lib# ls -l libGL* lrwxrwxrwx 1 root root 22 Aug 24 14:02 libGLcore.so.1 -> libGLcore.so.195.36.31 -rwxr-xr-x 1 root root 10869224 Dec 17 2007 libGLcore.so.169.04 -rw-r--r-- 1 root root 28862968 Jun 3 12:46 libGLcore.so.195.36.31 lrwxrwxrwx 1 root root 18 Jul 20 10:19 libGLEWmx.so.1.5 -> libGLEWmx.so.1.5.4 -rw-r--r-- 1 root root 334176 Jun 12 02:50 libGLEWmx.so.1.5.4 lrwxrwxrwx 1 root root 16 Jun 17 11:36 libGLEW.so.1.5 -> libGLEW.so.1.5.4 -rw-r--r-- 1 root root 387984 Jun 12 02:50 libGLEW.so.1.5.4 lrwxrwxrwx 1 root root 26 Aug 24 14:03 libGL.so -> /etc/alternatives/libGL.so lrwxrwxrwx 1 root root 15 Aug 25 12:22 libGL.so.1 -> libGL.so.169.04 -rwxr-xr-x 1 root root 839560 Dec 17 2007 libGL.so.169.04 -rw-r--r-- 1 root root 929006 Jul 15 08:23 libGLU.a lrwxrwxrwx 1 root root 11 Jul 16 10:40 libGLU.so -> libGLU.so.1 lrwxrwxrwx 1 root root 20 Jul 16 10:40 libGLU.so.1 -> libGLU.so.1.3.070701 -rw-r--r-- 1 root root 461624 Jul 15 08:23 libGLU.so.1.3.070701 As you can see, libGL.so.1 was linked directly to libGL.so.169.04. It must've been like this for about 2.5-3 years and I'd never noticed. Heh. Your new alternatives stuff didn't take over that bad libGL link with a good one. It's speculation but at times in the past (when debian has lagged) I have installed the upstream drivers directly. Clearly, this is an artifact of those days (though I didn't want it there, it got overlooked). Since your new stuff is trying to do it right, it would be helpful maybe for it to actually fix the mess the upstream installer drops in (or at least tell me about it so I can fix it myself). > > Your update alternatives code looks like it didn't replace this file, and so > > suddenly I was getting linkage errors from GL programs. > > For further investigation I would need detailed output of the > install/upgrade process and complete version information. > > > Andreas > Thanks for your help Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594416: nvidia-graphics-drivers: Breaking some GL applications linked to mesa
Package: nvidia-graphics-drivers Severity: normal Hi Found a problem with your diversion setup code. For some reason I had an old version of libGL.so.1 lying around linked directly to a file outside of dpkg control (probably last time I ran the installer directly from NVIDIA a few years ago). Your update alternatives code looks like it didn't replace this file, and so suddenly I was getting linkage errors from GL programs. Once I manually corrected the libGL.so.1 link to /etc/alternatives, it worked nicely. Hope this helps Christian -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (700, 'unstable'), (600, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589979: [Pkg-utopia-maintainers] Bug#589979: dbus-daemon-launch-helper needs to be a+x to work
On Tue, 2010-07-27 at 19:41 +0100, Simon McVittie wrote some really useful debug information. Thanks! My apologies for the noise. It turns out that a config change made some years ago (swapping the mythtv and messagebus groups for compat over nfs) only had an impact now. I'd failed to change the gid in /etc/passwd from 104 to 134 (the gid of the messagebus group). It probably broke with the 1.2 upgrade because, as you speculate, you only then added the helper and it's dependence on having the right gid. Thanks again for your help. Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589979: [Pkg-utopia-maintainers] Bug#589979: dbus-daemon-launch-helper needs to be a+x to work
Hi Michael, On Fri, 2010-07-23 at 00:01 +0200, Michael Biebl wrote: > On 22.07.2010 18:55, Christian Weeks wrote: > > Package: dbus > > Version: 1.2.24-2 > > Severity: important > > > > Hi, > > I noted on 569058 that the problem seen in 569058 is not > > restricted to btrfs filesystems. Since you have closed that bug > > I feel that it is important to open a new bug, because this problem > > is still occuring for me, on every single upgrade of dbus on any > > of my computers. > > > > Basically, if I don't chmod a+x /usr/lib/dbus-1.0/dbus-daemon-launch-helper > > then very little of my desktop environments work: pulse is broken, > > menus are broken, launching apps is broken. Basically, the entire gnome > > desktop is broken (not surprising given how much is dependent on dbus). > > > > The only hypothesis I have (because I am NOT using btrfs, I am using ext3 > > on LVM) is that it's actually to do with LDAP in some way, because all > > real local users are actually in an LDAP repository. I would guess that > > somehow that's breaking the helper's user credentials (though the messagebus > > user _is_ a local user, not an LDAP user). > > > > Given that I see this on at least 2 different desktops, I think it's pretty > > reproducible, and spans many versions of dbus now. > > > > To follow up on this: > > I don't think your particular issue is related to 569058. > 569058 was about the setuid bit not being set correctly. > From your comment on 569058, where you showed an ls -la of the helper, the > setuid was set correctly. OK. Here's ls -al now. Setuid is correct, but it's not correct because the o+x bit has to be set as well, otherwise it doesn't work (the package ships with o-x) -rwsr-xr-x 1 root messagebus 45936 Jul 17 09:31 /usr/lib/dbus-1.0/dbus-daemon-launch-helper I have to manually, on each upgrade of dbus, do the chmod to add o+x, otherwise DBus fails to launch stuff. (This is probably a big security hole which is why it's not set that way but..) If I change it back (chmod o-x) my desktop will break again. I know it's NOT supposed to be chmod o+x, that is clear, but something is causing it to break in my environments if it's not. You're right that it probably isn't directly 569058, but that's what grabbed my attention to this problem, and yesterday (for me) a new dbus dropped in unstable and reminded me of this problem. > > To understand you correctly: are you saying, that the messagebus user is only > stored in LDAP? (if so, that's a very bad idea btw) and I guess the ldap > service > runs after the dbus service (check /etc/rc2.d/)? Nope. messagebus is a local user (from /etc/passwd): messagebus:x:101:104::/var/run/dbus:/bin/false It's local (and a different id) on each machine. The local desktop users, _are_ however, sourced from LDAP. LDAP is remote by the way. > Under which user is your dbus system bus process running (ps aux | grep dbus)? > dbus appears to be running as messagebus: > 101 2492 0.0 0.0 56664 3204 ?Ss Jul22 0:02 /usr/bin/dbus-daemon --system However, when it tries to use it's helper, I get this: devkit-power-gobject-WARNING: Error invoking GetAll() to get properties: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success The only way to fix is the chmod o+x. This happens with any service that gets launched through the launcher btw: so far pulseaudio, devkit, powerkit, consolekit, polkit. They all break and make the desktop basically unusable. This happens on at least two different machines by the way. Both are configured for LDAP users. > I'll keep this bug closed, as it smells very much like a local > misconfiguration. Fine, however, I don't understand how I have misconfigured, if I have. It was a working setup for the prior three years and only broke when the new dbus landed about 6 months ago (The upgrade from dbus 1.2.16-2 to 1.2.20-2 is where I noticed the problem start occuring). > > Michael > > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589979: dbus-daemon-launch-helper needs to be a+x to work
Package: dbus Version: 1.2.24-2 Severity: important Hi, I noted on 569058 that the problem seen in 569058 is not restricted to btrfs filesystems. Since you have closed that bug I feel that it is important to open a new bug, because this problem is still occuring for me, on every single upgrade of dbus on any of my computers. Basically, if I don't chmod a+x /usr/lib/dbus-1.0/dbus-daemon-launch-helper then very little of my desktop environments work: pulse is broken, menus are broken, launching apps is broken. Basically, the entire gnome desktop is broken (not surprising given how much is dependent on dbus). The only hypothesis I have (because I am NOT using btrfs, I am using ext3 on LVM) is that it's actually to do with LDAP in some way, because all real local users are actually in an LDAP repository. I would guess that somehow that's breaking the helper's user credentials (though the messagebus user _is_ a local user, not an LDAP user). Given that I see this on at least 2 different desktops, I think it's pretty reproducible, and spans many versions of dbus now. (I think the last working version of dbus was about 1.2.16) Thanks Christian -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (700, 'unstable'), (600, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dbus depends on: ii adduser 3.112 add and remove users and groups ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libdbus-1-3 1.2.24-2 simple interprocess messaging syst ii libexpat1 2.0.1-7XML parsing C library - runtime li ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip dbus recommends no packages. Versions of packages dbus suggests: ii dbus-x11 1.2.24-2 simple interprocess messaging syst -- 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#586685: gdm3: User's .Xauthority file is ignored
Package: gdm3 Version: 2.30.2-4 Severity: important It appears that my ~/.Xauthority file is being ignored with gdm3. This appears to be an undocumented change to gdm functionality for upgrade from gdm. It's breaking several of my ssh related scripts, since ssh is still honouring the .Xauthority file, so I can no longer pass authority from one machine to another. (The old x2x trick doesn't work for example: ssh -fX myotherhost x2x -west -to :0 ) without a newly required xhost + on the target machine. Also, it seems that the xauth program doesn't want to work quite correctly- importing authority from .Xauthority with xauth file doesn't quite take correctly. (The above trick should, I believe, work, after I do that, but doesn't). These weird sideeffects of what is no doubt an attempt to tighten up security for gdm3 are why I'm filing this as important- it's clear that either ssh and other programs need to know about the new default in gdm3 (fun!) or gdm3 should expose a setting for the old behaviour (which it doesn't appear to, though documentation is very very sparse at this point). Thanks Christian -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (700, 'unstable'), (600, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gdm3 depends on: ii adduser 3.112add and remove users and groups ii awesome [x-window-manag 3.4.5-1 highly configurable, next generati ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy ii gconf2 2.28.1-3 GNOME configuration database syste ii gnome-session [x-sessio 2.30.0-1 The GNOME Session Manager - GNOME ii gnome-session-bin 2.30.0-1 The GNOME Session Manager - Minima ii gnome-terminal [x-termi 2.30.1-1 The GNOME terminal emulator applic ii kde-window-manager [x-w 4:4.4.4-1the KDE 4 window manager (KWin) ii konsole [x-terminal-emu 4:4.4.4-1X terminal emulator for KDE 4 ii libart-2.0-22.3.21-1 Library of functions for 2D graphi ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libattr11:2.4.44-2 Extended attribute shared library ii libaudit0 1.7.13-1+b1 Dynamic library for security audit ii libbonobo2-02.24.3-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.24.3-1 The Bonobo UI library ii libc6 2.11.2-1 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libcanberra-gtk00.24-1 Gtk+ helper for playing widget eve ii libcanberra00.24-1 a simple abstract interface for pl ii libdbus-1-3 1.2.24-1 simple interprocess messaging syst ii libdbus-glib-1-20.86-1 simple interprocess messaging syst ii libdevkit-power-gobject 1:0.9.4-2abstraction for power management - ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.1-3 GNOME configuration database syste ii libglib2.0-02.24.1-1 The GLib library of C routines ii libgnome2-0 2.30.0-1 The GNOME library - runtime files ii libgnomecanvas2-0 2.30.1-1 A powerful object-oriented display ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii liborbit2 1:2.14.18-0.1libraries for ORBit2 - a CORBA ORB ii libpam-modules 1.1.1-3 Pluggable Authentication Modules f ii libpam-runtime 1.1.1-3 Runtime support for the PAM librar ii libpam0g1.1.1-3 Pluggable Authentication Modules l ii libpanel-applet2-0 2.30.0-2 library for GNOME Panel applets ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libpolkit-gobject-1-0 0.96-2 PolicyKit Authorization API ii libpolkit-gtk-1-0 0.96-2 PolicyKit GTK+ API ii libpopt01.16-1 lib for parsing cmdline parameters ii librsvg2-common 2.26.3-1 SAX-based renderer library for SVG ii libselinux1 2.0.94-1 SELinux runtime shared libraries ii libwrap07.6.q-19 Wietse Venema's TCP wrappers libra ii libx11-62:1.3.3-3X11 client-side library ii libxau6 1:1.0.5-2X11 authorisation library ii libxdmcp6 1:1.0.3-2X11 Display Manager Control Protoc ii libxklavier16 5.0-2X Keyboard Extens
Bug#569058: Clearly NOT just btrfs
Because I am running on ext3 and I experienced the problem on two different systems. /dev/mapper/alliecore-root on / type ext3 (rw,errors=remount-ro) 2010-02-18 10:26:49 upgrade dbus 1.2.16-2 1.2.20-2 I have LVM under my filesystem. Dunno if that's a factor. My workaround, make it x for all: -rwsr-xr-x 1 root messagebus 45792 Feb 3 22:45 /usr/lib/dbus-1.0/dbus-daemon-launch-helper Other systems have worked fine however. It's a peculiar issue for sure. Thanks Joey for linking this bug, it's been annoying me for days! Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543504: pidgin: Fails to read gnome proxy information correctly
Package: pidgin Version: 2.6.1-1 Severity: important There is an upstream issue: http://developer.pidgin.im/ticket/10051 that causes pidgin 2.6.1 not to read the gnome proxy information correctly This means pidgin will not work in a proxied environment, pretty much at all. There is a (very) simple patch in the bug report that I suggest you apply, it fixed the problem on my local build. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (700, 'unstable'), (600, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pidgin depends on: ii gconf2 2.26.2-3 GNOME configuration database syste ii libatk1.0-01.26.0-1 The ATK accessibility toolkit ii libc6 2.9-25GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libdbus-1-31.2.16-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.82-1simple interprocess messaging syst ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libglib2.0-0 2.20.4-1 The GLib library of C routines ii libgstreamer0.10-0 0.10.24-1 Core GStreamer libraries and eleme ii libgtk2.0-02.16.5-1 The GTK+ graphical user interface ii libgtkspell0 2.0.13-2 a spell-checking addon for GTK's T ii libice62:1.0.5-1 X11 Inter-Client Exchange library ii libpango1.0-0 1.24.5-1 Layout and rendering of internatio ii libpurple0 2.6.1-1 multi-protocol instant messaging l ii libsm6 2:1.1.0-2 X11 Session Management library ii libstartup-notificatio 0.10-1library for program launch feedbac ii libx11-6 2:1.2.2-1 X11 client-side library ii libxss11:1.1.3-1 X11 Screen Saver extension library ii perl 5.10.0-25 Larry Wall's Practical Extraction ii perl-base [perlapi-5.1 5.10.0-25 minimal Perl system ii pidgin-data2.6.1-1 multi-protocol instant messaging c ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime Versions of packages pidgin recommends: ii gstreamer0.10-plugins-base0.10.24-1 GStreamer plugins from the "base" ii gstreamer0.10-plugins-good0.10.15-2 GStreamer plugins from the "good" Versions of packages pidgin suggests: ii evolution-data-server2.26.3-1+b1 evolution database backend server ii gnome-panel 2.26.3-1launcher and docking facility for ii kdebase-workspace-bin4:4.3.0-3 core binaries for the KDE 4 base w ii libsqlite3-0 3.6.17-2SQLite 3 shared library -- 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#525987: evolution: Expunging a folder crashes the email reader thread so no more mail is read from the server
Package: evolution Version: 2.26.1.1-1 Severity: normal It appears that when you "Expunge" a folder in Evolution, it crashes the reader thread, resulting in no more mail being read from the server for the mail folder you are visiting (e.g. expunge Inbox, get no more mail into the Inbox). Running with CAMEL_DEBUG=all it appears there's an exception: DELETE FROM 'Unread' WHERE vuid = 'CTpjBccN31356' removing uid '31357' Camel SQL Exec: DELETE FROM 'Unread' WHERE vuid = 'CTpjBccN31357' removing uid '31358' Camel SQL Exec: DELETE FROM 'Unread' WHERE vuid = 'CTpjBccN31358' removing uid '31359' Camel SQL Exec: DELETE FROM 'Unread' WHERE vuid = 'CTpjBccN31359' removing uid '31360' Camel SQL Exec: DELETE FROM 'Unread' WHERE vuid = 'CTpjBccN31360' removing uid '31361' Camel SQL Exec: DELETE FROM 'Unread' WHERE vuid = 'CTpjBccN31361' DB Operation ended. Time Taken : 0.007640 ### camel_db_select: SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'INBOX' WHERE uid = '31360' === DB SQL operation [SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'INBOX' WHERE uid = '31360'] started DB Operation ended. Time Taken : 0.000113 ### CamelException.set(0x7f6f97ce1ee0, 2, 'no uid [31360] exists') Note that 31360 probably corresponds to the email I had selected in the shell at that time. After this, no more email is received, and the client will now also hang forever when you come to shutdown (probably waiting on the excepted thread). This is clearly a bug in the code somewhere. I'll update if I have time to look at it and see what's going on. Christian -- System Information: Debian Release: squeeze/sid APT prefers feisty APT policy: (500, 'feisty'), (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages evolution depends on: ii dbus 1.2.12-1simple interprocess messaging syst ii debconf [deb 1.5.26 Debian configuration management sy ii evolution-co 2.26.1.1-1 architecture independent files for ii evolution-da 2.26.1.1-1 evolution database backend server ii gconf2 2.26.0-1GNOME configuration database syste ii gnome-icon-t 2.24.0-4GNOME Desktop icon theme ii libart-2.0-2 2.3.20-2Library of functions for 2D graphi ii libatk1.0-0 1.26.0-1The ATK accessibility toolkit ii libbluetooth 3.36-1 Library to use the BlueZ Linux Blu ii libbonobo2-0 2.24.1-1Bonobo CORBA interfaces library ii libbonoboui2 2.24.1-1The Bonobo UI library ii libc62.9-8 GNU C Library: Shared libraries ii libcairo21.8.6-2+b1 The Cairo 2D vector graphics libra ii libcamel1.2- 2.26.1.1-1 The Evolution MIME message handlin ii libdbus-1-3 1.2.12-1simple interprocess messaging syst ii libdbus-glib 0.80-4 simple interprocess messaging syst ii libebackend1 2.26.1.1-1 Utility library for evolution data ii libebook1.2- 2.26.1.1-1 Client library for evolution addre ii libecal1.2-7 2.26.1.1-1 Client library for evolution calen ii libedataserv 2.26.1.1-1 Utility library for evolution data ii libedataserv 2.26.1.1-1 GUI utility library for evolution ii libegroupwis 2.26.1.1-1 Client library for accessing group ii libenchant1c 1.4.2-3.3 a wrapper library for various spel ii libexchange- 2.26.1.1-1 Client library for accessing Excha ii libfontconfi 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-4.1 FreeType 2 font engine, shared lib ii libgconf2-4 2.26.0-1GNOME configuration database syste ii libgdata-goo 2.26.1.1-1 Client library for accessing Googl ii libgdata1.2- 2.26.1.1-1 Client library for accessing Googl ii libglade2-0 1:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.20.1-1The GLib library of C routines ii libgnome-pil 2.0.15-2.4 Support libraries for gnome-pilot ii libgnome2-0 2.24.1-2The GNOME 2 library - runtime file ii libgnomecanv 2.20.1.1-1 A powerful object-oriented display ii libgnomeui-0 2.24.1-1The GNOME 2 libraries (User Interf ii libgnomevfs2 1:2.24.1-1 GNOME Virtual File System (runtime ii
Bug#489212: hpodder: A couple of nice options and a small fix
Package: hpodder
Version: 1.1.5.0
Severity: wishlist
Tags: patch
Hi,
Attached is a working (I hope) patch for hpodder 1.1.5 which adds the "EPID" to
the
id3v2 callout. This is great for allowing sorting by episode ID in things like
gtkpod.
Also fixed the "FEEDURL" which has a typo (FEDDURL) in the Config.hs file.
Hope this helps,
Christian
-- System Information:
Debian Release: lenny/sid
APT prefers feisty
APT policy: (500, 'feisty'), (500, 'unstable'), (500, 'testing'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages hpodder depends on:
ii curl 7.18.2-5 Get a file from an HTTP, HTTPS or
ii id3v2 0.1.11-3 A command line id3v2 tag editor
ii libc6 2.7-12 GNU C Library: Shared libraries
ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
ii libsqlite3-0 3.5.9-3SQLite 3 shared library
hpodder recommends no packages.
-- no debconf information
diff -aur hpodder-1.1.5.0/Commands/Download.hs
hpodder-1.1.5.0+1/Commands/Download.hs
--- hpodder-1.1.5.0/Commands/Download.hs2008-07-02 11:29:00.0
-0400
+++ hpodder-1.1.5.0+1/Commands/Download.hs 2008-07-03 23:40:36.0
-0400
@@ -284,6 +284,7 @@
("FEEDURL", feedurl . podcast $ ep),
("SAFECASTTITLE", sanitize_fn . castname . podcast $
ep),
("SAFEEPTITLE", sanitize_fn . eptitle $ ep),
+ ("EPID", show . epid $ ep),
("EPTITLE", eptitle ep)]
-- | Runs a hook script.
diff -aur hpodder-1.1.5.0/Config.hs hpodder-1.1.5.0+1/Config.hs
--- hpodder-1.1.5.0/Config.hs 2008-04-08 15:20:54.0 -0400
+++ hpodder-1.1.5.0+1/Config.hs 2008-07-03 23:42:52.0 -0400
@@ -74,7 +74,7 @@
cp <- set cp "DEFAULT" "renametypes"
"audio/mpeg:.mp3,audio/mp3:.mp3,x-audio/mp3:.mp3"
cp <- set cp "DEFAULT" "postproctypes"
"audio/mpeg,audio/mp3,x-audio/mp3"
cp <- set cp "DEFAULT" "gettypecommand" "file -b -i
\"${EPFILENAME}\""
- cp <- set cp "DEFAULT" "postproccommand" "id3v2 -A
\"${CASTTITLE}\" -t \"${EPTITLE}\" --WOAF \"${EPURL}\" --WOAS \"${FEDDURL}\"
\"${EPFILENAME}\""
+ cp <- set cp "DEFAULT" "postproccommand" "id3v2 -T
\"${EPID}\" -A \"${CASTTITLE}\" -t \"${EPTITLE}\" --WOAF \"${EPURL}\" --WOAS
\"${FEEDURL}\" \"${EPFILENAME}\""
return cp
startingcp = emptyCP {accessfunc = interpolatingAccess 10}
@@ -114,4 +114,4 @@
Right x -> Just (splitit x)
Left _ -> Nothing
where splitit x = filter (/= "") . map strip . split "," $ x
Bug#487995: 2.4.3 fixes problem?
Hi This is just to update you that it appears that 2.4.3-1 has apparently fixed the problem. I speculate that the Network Manager fix was interfering with dbus somehow and causing the segfault. Thanks Christian
Bug#487995: pidgin: Segfaults randomly on dbus message
Update: A stack trace without cap plugin running: (13:20:23) jabber: Recv (ssl)(164): Disconnected. (13:20:23) blist: Updating buddy status for [EMAIL PROTECTED] (XMPP) [New Thread 0xb52f8b90 (LWP 3316)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb71c8720 (LWP 3161)] 0xb786c5a2 in ?? () from /usr/lib/libdbus-1.so.3 (gdb) bt full #0 0xb786c5a2 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #1 0x097d8ca8 in ?? () No symbol table info available. #2 0x08ee3100 in ?? () No symbol table info available. #3 0xbfcea538 in ?? () No symbol table info available. #4 0xb787cff4 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #5 0xbfcea564 in ?? () No symbol table info available. #6 0x08ee3100 in ?? () No symbol table info available. #7 0xbfcea538 in ?? () No symbol table info available. #8 0xb786c6e7 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #9 0xb78543eb in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #10 0x097d8ca8 in ?? () No symbol table info available. #11 0xbfcea588 in ?? () No symbol table info available. #12 0xb7854eb2 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #13 0xbfcea564 in ?? () No symbol table info available. #14 0x in ?? () No symbol table info available. (gdb) Same problem :( C On Wed, 2008-06-25 at 12:29 -0400, Ari Pollak wrote: > Do you have pidgin-dbg installed? Are you using Network Manager? Does > this still happen if you unload the Contact Availability Prediction > plugin? > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487995: pidgin: Segfaults randomly on dbus message
On Wed, 2008-06-25 at 12:29 -0400, Ari Pollak wrote: > Do you have pidgin-dbg installed? Yes > Are you using Network Manager? Yes > Does this still happen if you unload the Contact Availability Prediction > plugin? > Yes, I think so. Helpful I know ;) Another stack trace: (12:31:22) cap: Executing: insert into cap_status (buddy, account, protocol, status, event_time) values([EMAIL PROTECTED], [EMAIL PROTECTED]/Gaim, prpl-jabber, available, now()); [New Thread 0xb58dbb90 (LWP 822)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7120720 (LWP 32705)] 0xb77c45a2 in ?? () from /usr/lib/libdbus-1.so.3 (gdb) bt #0 0xb77c45a2 in ?? () from /usr/lib/libdbus-1.so.3 #1 0xb410e618 in ?? () #2 0x083cb900 in ?? () #3 0xbf942198 in ?? () #4 0xb77d4ff4 in ?? () from /usr/lib/libdbus-1.so.3 #5 0xbf9421c4 in ?? () #6 0x083cb900 in ?? () #7 0xbf942198 in ?? () #8 0xb77c46e7 in ?? () from /usr/lib/libdbus-1.so.3 #9 0xb77ac3eb in ?? () from /usr/lib/libdbus-1.so.3 #10 0xb410e618 in ?? () #11 0xbf9421e8 in ?? () #12 0xb77aceb2 in ?? () from /usr/lib/libdbus-1.so.3 #13 0xbf9421c4 in ?? () #14 0x in ?? () (gdb) bt full #0 0xb77c45a2 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #1 0xb410e618 in ?? () No symbol table info available. #2 0x083cb900 in ?? () No symbol table info available. #3 0xbf942198 in ?? () No symbol table info available. #4 0xb77d4ff4 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #5 0xbf9421c4 in ?? () No symbol table info available. #6 0x083cb900 in ?? () No symbol table info available. #7 0xbf942198 in ?? () No symbol table info available. #8 0xb77c46e7 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #9 0xb77ac3eb in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #10 0xb410e618 in ?? () No symbol table info available. #11 0xbf9421e8 in ?? () No symbol table info available. #12 0xb77aceb2 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #13 0xbf9421c4 in ?? () No symbol table info available. #14 0x in ?? () No symbol table info available. (gdb) Again with DBus. Interestingly the cap is there again, but no HAL message. Hmmm. I wonder if it's the dbus contact status notifier code? Trying to verify problem without cap. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487995: pidgin: Segfaults randomly on dbus message
Package: pidgin Version: 2.4.2-2 Severity: important Hi, Pidgin seems to be randomly segfaulting on receiving a particular dbus message. The gdb backtrace and debug log are not very informative: (11:10:44) cap: Executing: insert into cap_status (buddy, account, protocol, status, event_time) values([EMAIL PROTECTED], [EMAIL PROTECTED]/Gaim, prpl-jabber, available, now()); [New Thread 0xb515cb90 (LWP 29009)] libhal.c 3476 : Error unsubscribing to signals, error=Connection is closed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb71a2720 (LWP 28710)] 0xb7845766 in ?? () from /usr/lib/libdbus-1.so.3 (gdb) bt #0 0xb7845766 in ?? () from /usr/lib/libdbus-1.so.3 #1 0xbfbc2378 in ?? () #2 0xb78451aa in ?? () from /usr/lib/libdbus-1.so.3 #3 0x in ?? () (gdb) bt full #0 0xb7845766 in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #1 0xbfbc2378 in ?? () No symbol table info available. #2 0xb78451aa in ?? () from /usr/lib/libdbus-1.so.3 No symbol table info available. #3 0x in ?? () No symbol table info available. (gdb) The first line is the last element of debug output. The I see the peculiar hal warning, which always seems to occur just prior to the segfault. It may well be that the dbus/hal environment on this machine is slightly hosed (though I don't really see how), but I think that that is not a valid cause for pidgin to segfault when it receives a bad dbus message, do you? Thanks Christian -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pidgin depends on: ii gconf22.22.0-1 GNOME configuration database syste ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libc6 2.7-12 GNU C Library: Shared libraries ii libcairo2 1.6.4-6The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.1-2simple interprocess messaging syst ii libdbus-glib-1-2 0.76-1 simple interprocess messaging syst ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libgstreamer0.10-00.10.20-1 Core GStreamer libraries and eleme ii libgtk2.0-0 2.12.10-2 The GTK+ graphical user interface ii libgtkspell0 2.0.13-1 a spell-checking addon for GTK's T ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libpango1.0-0 1.20.2-2 Layout and rendering of internatio ii libpurple02.4.2-2multi-protocol instant messaging l ii libsm62:1.0.3-2 X11 Session Management library ii libstartup-notification0 0.9-1 library for program launch feedbac ii libx11-6 2:1.1.4-2 X11 client-side library ii libxss1 1:1.1.3-1 X11 Screen Saver extension library ii perl 5.10.0-11 Larry Wall's Practical Extraction ii perl-base [perlapi-5.10.0]5.10.0-11 The Pathologically Eclectic Rubbis ii pidgin-data 2.4.2-2multi-protocol instant messaging c Versions of packages pidgin recommends: ii gstreamer0.10-plugins-base0.10.20-1 GStreamer plugins from the "base" ii gstreamer0.10-plugins-good0.10.8-4 GStreamer plugins from the "good" -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427516: Bad DNS hangs squid
Package: squid Version: 2.6.5-6 Severity: grave Justification: renders package unusable Hi, I'm not sure, but this could be quite a serious issue for any user of squid out there, hence the grave setting. It appears that etch squid hangs completely when fed bad DNS data- and the only recovery is a full machine reboot. Here is the relevant part of the log file (with squid debug turned on to find the problem- this is the 4th time in 4 days): 2007/06/04 12:10:52| clientProcessRequest: GET 'http://cpacampaigns.directtrack.com/42/2631/8130' 2007/06/04 12:10:52| storeGet: looking up 78649369EDB1EC1103A78743E32E896B 2007/06/04 12:10:52| clientProcessRequest2: storeGet() MISS 2007/06/04 12:10:52| clientProcessRequest: TCP_MISS for 'http://cpacampaigns.directtrack.com/42/2631/8130' 2007/06/04 12:10:52| clientProcessMiss: 'GET http://cpacampaigns.directtrack.com/42/2631/8130' 2007/06/04 12:10:52| storeCreateEntry: 'http://cpacampaigns.directtrack.com/42/2631/8130' 2007/06/04 12:10:52| creating rep: 0x8f82078 2007/06/04 12:10:52| init-ing hdr: 0x8f820b8 owner: 3 2007/06/04 12:10:52| 0x8f820b8 lookup for 38 2007/06/04 12:10:52| 0x8f820b8 lookup for 9 2007/06/04 12:10:52| 0x8f820b8 lookup for 38 2007/06/04 12:10:52| 0x8f820b8 lookup for 9 2007/06/04 12:10:52| 0x8f820b8 lookup for 22 2007/06/04 12:10:52| new_MemObject: returning 0x8f82930 2007/06/04 12:10:52| new_StoreEntry: returning 0x8501470 2007/06/04 12:10:52| storeKeyPrivate: GET http://cpacampaigns.directtrack.com/42/2631/8130 2007/06/04 12:10:52| storeHashInsert: Inserting Entry 0x8501470 key '02C887D62B71CA3E5B3AFAC3EE24F1CD' 2007/06/04 12:10:52| storeLockObject: key '02C887D62B71CA3E5B3AFAC3EE24F1CD' count=2 2007/06/04 12:10:52| storeClientCopy: 02C887D62B71CA3E5B3AFAC3EE24F1CD, seen 0, want 0, size 4096, cb 0x8069690, cbdata 0x86734d0 2007/06/04 12:10:52| cbdataLock: 0x86734d0 2007/06/04 12:10:52| cbdataLock: 0x858bef8 2007/06/04 12:10:52| storeClientCopy2: 02C887D62B71CA3E5B3AFAC3EE24F1CD 2007/06/04 12:10:52| storeClientCopy3: Waiting for more 2007/06/04 12:10:52| cbdataUnlock: 0x858bef8 2007/06/04 12:10:52| aclCheckFast: list: (nil) 2007/06/04 12:10:52| aclCheckFast: no matches, returning: 1 2007/06/04 12:10:52| fwdStart: 'http://cpacampaigns.directtrack.com/42/2631/8130' 2007/06/04 12:10:52| storeLockObject: key '02C887D62B71CA3E5B3AFAC3EE24F1CD' count=3 2007/06/04 12:10:52| peerSelect: http://cpacampaigns.directtrack.com/42/2631/8130 2007/06/04 12:10:52| storeLockObject: key '02C887D62B71CA3E5B3AFAC3EE24F1CD' count=4 2007/06/04 12:10:52| cbdataLock: 0x88f91d0 2007/06/04 12:10:52| peerSelectFoo: 'GET cpacampaigns.directtrack.com' 2007/06/04 12:10:52| peerCheckNetdbDirect: MY RTT = 0 msec 2007/06/04 12:10:52| peerCheckNetdbDirect: minimum_direct_rtt = 400 msec 2007/06/04 12:10:52| peerCheckNetdbDirect: MY hops = 0 2007/06/04 12:10:52| peerCheckNetdbDirect: minimum_direct_hops = 4 2007/06/04 12:10:52| whichPeer: from 0.0.0.0 port 0 2007/06/04 12:10:52| peerSelectFoo: direct = DIRECT_MAYBE 2007/06/04 12:10:52| neighborsDigestSelect: choices: 0 (0) 2007/06/04 12:10:52| peerNoteDigestLookup: peer , lookup: LOOKUP_NONE 2007/06/04 12:10:52| peerSelectIcpPing: http://cpacampaigns.directtrack.com/42/2631/8130 2007/06/04 12:10:52| neighborsCount: 0 2007/06/04 12:10:52| peerSelectIcpPing: counted 0 neighbors 2007/06/04 12:10:52| peerGetSomeParent: GET cpacampaigns.directtrack.com 2007/06/04 12:10:52| getDefaultParent: returning NULL 2007/06/04 12:10:52| peerSourceHashSelectParent: Calculating hash for 10.254.1.191 2007/06/04 12:10:52| getRoundRobinParent: returning NULL 2007/06/04 12:10:52| getFirstUpParent: returning NULL 2007/06/04 12:10:52| getAnyParent: returning NULL 2007/06/04 12:10:52| peerAddFwdServer: adding DIRECT DIRECT 2007/06/04 12:10:52| peerSelectCallback: http://cpacampaigns.directtrack.com/42/2631/8130 2007/06/04 12:10:52| cbdataValid: 0x88f91d0 2007/06/04 12:10:52| fwdStartComplete: http://cpacampaigns.directtrack.com/42/2631/8130 2007/06/04 12:10:52| fwdConnectStart: http://cpacampaigns.directtrack.com/42/2631/8130 2007/06/04 12:10:52| fwdConnectStart: got addr 0.0.0.0, tos 0 2007/06/04 12:10:52| comm_open: FD 83 is a new socket 2007/06/04 12:10:52| fd_open FD 83 http://cpacampaigns.directtrack.com/42/2631/8130 2007/06/04 12:10:52| comm_add_close_handler: FD 83, handler=0x807bbb0, data=0x88f91d0 2007/06/04 12:10:52| cbdataLock: 0x88f91d0 2007/06/04 12:10:52| commSetTimeout: FD 83 timeout 60 2007/06/04 12:10:52| commConnectStart: FD 83, cpacampaigns.directtrack.com:80 2007/06/04 12:10:52| cbdataLock: 0x88f91d0 2007/06/04 12:10:52| comm_add_close_handler: FD 83, handler=0x806fee0, data=0x88fa168 2007/06/04 12:10:52| cbdataLock: 0x88fa168 2007/06/04 12:10:52| ipcache_nbgethostbyname: Name 'cpacampaigns.directtrack.com'. 2007/06/04 12:10:52| ipcache_nbgethostbyname: MISS for 'cpacampaigns.directtrack.com' 2007/06/04 12:10:52| cbdataLock: 0x88fa168 2007/06/04 12:10:52| idnsALookup: buf is 46 bytes for cpacampaigns.directt
Bug#379780: autofs: Automounts fail to automount after a few days of uptime
Package: autofs Version: 4.1.3+4.1.4beta2-10 Severity: normal I've been running an NIS automap for the past few weeks, trying to provide automatic homes to people in our NIS domain. I also personally provision ssh keys to this server. The issue is that after the automounter has been running for a couple of days the ssh authorized_keys file stops being read from the filesystem- it appears that the automounter is refusing to mount /home/cweeks (my home directory) in response to ssh's request for the .ssh/authorized_keys file. Note that if I restart the automounter, this works perfectly (I can use my ssh key to login). Also note that I can access my home directory, by cding to it, so the automount is not not working, it just seems confused. Here's some output when we're in this state: ~#> cd /home/cweeks/.ssh -bash: cd: /home/cweeks/.ssh: No such file or directory ~#> cat /home/cweeks/.ssh/authorized_keys cat: /home/cweeks/.ssh/authorized_keys: No such file or directory ~#> cd /home/cweeks /home/cweeks#> cd /home/cweeks/.ssh /home/cweeks/.ssh#> cat /home/cweeks/.ssh/authorized_keys As you can see, it seems that the automounter is failing to automount when a subdirectory is requested. Thanks, Christian -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-686-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages autofs depends on: ii debconf 1.4.30.13 Debian configuration management sy ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an -- debconf information: autofs/upgrade-from-broken-version: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375786: initramfs-tools: Volume group not activated with LILO
Package: initramfs-tools Version: 0.65b Severity: important Tags: patch Hi. It appears that the new volume group activation code doesn't work with LILO. The culprit is that LILO's fe00 is substituted for /dev/root. I have attached a patch that should fix this behaviour to be correct. I have inspected 0.60 (from testing) and this patch appears to make us conform more closely to how it worked there (where fe00 and /dev/root worked apparently). Thanks, Christian -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages initramfs-tools depends on: ii busybox 1:1.1.3-1 Tiny utilities for small and embed ii cpio 2.6-13 GNU cpio -- a program to manage ar ii klibc-utils 1.3.35-1 small statically-linked utilities ii module-init-tools 3.2.2-3tools for managing Linux kernel mo ii udev 0.093-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information --- /tmp/ext/usr/share/initramfs-tools/scripts/local-top/lvm +++ /usr/share/initramfs-tools/scripts/local-top/lvm @@ -30,6 +30,10 @@ vgchange -ay exit 0 ;; +/dev/root) + vgchange -ay + exit 0 + ;; esac # Make sure that we have a d-m path
Bug#368920: evolution: Evolution crash with bad ics attachment
Package: evolution Version: 2.6.1-2 Severity: normal Evolution crashes with the attached dump (from bug buddy) when it receives a bad (but not corrupted) ics attachment in an email (embedded below in case you read this in evolution and it crashes for you). It's annoying because I now have to delete the email through an alternate means to be able to use Evolution again (because it remembers that email as the last I selected when it starts up again *sigh*). BTW: I think it's clear that the problem is that the date is before 1900 (I know it's the broken Outlook that the real problem but anyway, Evolution should crash and burn because of it). Thanks, Christian --BEGIN ICAL BEGIN:VCALENDAR METHOD:PUBLISH PRODID:-//Oracle/Outlook Connector//EN VERSION:2.0 BEGIN:VEVENT DTEND:16010101T00Z DTSTART:16010101T00Z ORGANIZER;SENT-BY=xxx;CN=xxx DESCRIPTION:Proposed By: XXX\nSensitivity:Normal\nImportance: Normal\n\nWhen: Friday\, May 26\, 2006 11:00 AM-12:00 PM (GMT-05:00) Eastern Time (US & Canada).\n\n*~*~*~*~*~*~*~*~*~*\n\n SUMMARY:XXX PRIORITY:5 SEQUENCE:0 TRANSP:OPAQUE ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE;CN=xxx ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE;CN= DTSTAMP:20060525T193504Z UID:xxx END:VEVENT END:VCALENDAR --END ICAL -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages evolution depends on: ii dbus 0.61-5 simple interprocess messaging syst ii evolution-dat 1.6.1-2evolution database backend server ii gconf22.14.0-1 GNOME configuration database syste ii gnome-icon-th 2.14.2-1 GNOME Desktop icon theme ii gtkhtml3.83.10.1-1 HTML rendering/editing library - b ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.11.4-2 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6Open-source version of SGI's audio ii libavahi-clie 0.6.10-1 Avahi client library ii libavahi-comm 0.6.10-1 Avahi common library ii libavahi-glib 0.6.10-1 Avahi glib integration library ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libbonoboui2- 2.14.0-2 The Bonobo UI library ii libc6 2.3.6-9GNU C Library: Shared libraries ii libcairo2 1.0.4-2The Cairo 2D vector graphics libra ii libcamel1.2-8 1.6.1-2The Evolution MIME message handlin ii libcomerr21.38+1.39-WIP-2006.04.09-2 common error description library ii libdbus-1-2 0.61-5 simple interprocess messaging syst ii libdbus-glib- 0.61-5 simple interprocess messaging syst ii libebook1.2-5 1.6.1-2Client library for evolution addre ii libecal1.2-3 1.6.1-2Client library for evolution calen ii libedataserve 1.6.1-2Utility library for evolution data ii libedataserve 1.6.1-2GUI utility library for evolution ii libesd-alsa0 0.2.36-3 Enlightened Sound Daemon (ALSA) - ii libfontconfig 2.3.2-5.1 generic font configuration library ii libfreetype6 2.2.1-2FreeType 2 font engine, shared lib ii libgail-commo 1.8.11-2 GNOME Accessibility Implementation ii libgail17 1.8.11-2 GNOME Accessibility Implementation ii libgconf2-4 2.14.0-1 GNOME configuration database syste ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libglade2-0 1:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.10.2-2 The GLib library of C routines ii libgnome-keyr 0.4.9-1GNOME keyring services library ii libgnome-pilo 2.0.12-1.6 Support libraries for gnome-pilot ii libgnome2-0 2.14.1-2 The GNOME 2 library - runtime file ii libgnomecanva 2.14.0-2 A powerful object-oriented display ii libgnomeprint 2.12.1-3 The GNOME 2.2 print architecture - ii libgnomeprint 2.12.1-3 GNOME 2.2 print architecture User ii libgnomeui-0 2.14.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2- 2.14.1-2 GNOME virtual file-system (runtime ii libgnutls13 1.3.5-1.1 the GNU TLS library - runtime libr ii libgpg-error0 1.2-1 library for common error values an ii libgtk2.0-0 2.8.17-2 The GTK+ graphical user interface ii libgtkhtml3.8 3.10.1-1
Bug#355013: initramfs-tools: device mapper device ordering breaks boot (sometimes)
On Sun, 2006-04-16 at 11:33 +0200, maximilian attems wrote: > ok, adding discs works much better with grub. I know. I've used grub for non-LVM installations. But I also love the reorganizing convenience of LVM. Does grub now work with LVM roots then? This was the reason I used lilo (well, actually, debian-installer selected lilo for me, because I'd done an LVM root installation). I know of and loathe the /boot partition workaround (see RedHat)- it's nasty and uses up disk that I would like for other things. > lowering the severity as lilo is not default. > but please become familiar with the carriage return on your keyboard > and format mails to ~80 columns. Evolution is stupid sometimes, my apologies. > > can you paste your lilo.conf? OK. Here it is. I've edited all the verbage from the installer. As you can see it's a vanilla lilo config generated by the installer. # /etc/lilo.conf - See: `lilo(8)' and `lilo.conf(5)', boot=/dev/hda root=/dev/mapper/cweekslap-root map=/boot/map delay=20 vga=normal default=Linux image=/vmlinuz label=Linux read-only # restricted # alias=1 initrd=/initrd.img image=/vmlinuz.old label=LinuxOLD read-only optional # restricted # alias=2 initrd=/initrd.img.old > > > Nothing is able to work permanently though. I can't make a lilo root= > > option stick- it turns into numbers. > > have you tried to use the append="root=/dev/mapper/cweekslap-root" > instead and without the root lilo.conf param? > afaik that is the way that is recommended for evms on lilo too see end > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357538 > I have not. I will look into this. Thank you. I have another tentative solution that I will investigate as well when time permits. It appears that LVM allows you to make the minor node of a partition persistent. I shall see if I can use that to force the minor node of the root partition to zero. Thank you for your help, Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362005: RFP: network-manager-vpnc -- vpnc VPN connection agent for NetworkManager
Package: wnpp Severity: wishlist * Package name: network-manager-vpnc Version : 0.6.2 Upstream Author : GNOME * URL : http://www.gnome.org/projects/NetworkManager * License : GPL Programming Lang: C Description : vpnc VPN connection agent for NetworkManager This is the vpnc vpn connection agent from the NetworkManager suite. Filing an RFP as requested in bug #356944 Note that there is no definitive URL for this particular component. You have to grab it from CVS at present. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356944: network-manager: Grab and build the vpn modules from cvs please
Package: network-manager Version: 0.5.1-3 Severity: wishlist Please can you grab the vpn connection modules from the network manager cvs repository. It appears that upstream is trying to figure out a way to distribute these more "sanely". But at present, you have to grab them from CVS. See the thread at http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00105.html for more information. Thanks! -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-k8-1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages network-manager depends on: ii dhcdbd 1.12-1 dbus interface to the ISC DHCP cli ii iproute 20051007-3 Professional tools to control the ii iputils-arping 3:20020927-3 Tool to send ICMP echo requests to ii libc6 2.3.6-3 GNU C Library: Shared libraries an ii libdbus-1-2 0.61-4 simple interprocess messaging syst ii libdbus-glib-1-20.61-4 simple interprocess messaging syst ii libgcrypt11 1.2.2-1 LGPL Crypto library - runtime libr ii libglib2.0-02.8.6-1 The GLib library of C routines ii libgpg-error0 1.2-1library for common error values an ii libhal1 0.5.7-1 Hardware Abstraction Layer - share ii lsb-base3.0-16 Linux Standard Base 3.0 init scrip network-manager recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355013: initramfs-tools: device mapper device ordering breaks boot (sometimes)
Package: initramfs-tools Version: 0.53 Severity: important I use LVM on all my disks. I swapped an old laptop disk into another laptop for testing and my laptop now fails to boot normally but rather drops into the busybox. An analysis of this problem indicates that there are issues with LILO, the initramfs and/or the device mapper. Here's what appears to be happening. I run lilo, and (after spinning the CPU for about 30-60 seconds!) it deduces that my LVM disk cweekslap/root has id FE00 (I am not sure this is correct, however). So it spits this onto the command line. With a single disk in the laptop we will now boot correctly. I add in the second disk and at boot time, for some reason, the secondary disk (helenlap/home!) is now device FE00. Of course helenlap/home is not a valid root disk (it never was) and the system drops to busybox when it can't find init. I have recovered the situation temporarily with one of three fixes: 1. Use a boot parameter root=/dev/mapper/cweekslap-root 2. remount /dev/mapper/cweekslap-root at the /root mountpoint in the initram disk 3. recreate the /dev/root with mknod /dev/root b 254 2 Nothing is able to work permanently though. I can't make a lilo root= option stick- it turns into numbers. Note that versions are probably wrong- this report is being filed from another machine. The actual machine setup is newly upgraded from sid yesterday, with stock 2.6.15 686 kernel and mkinitramfs as the ramdisk generator. Hope this helps, Thanks, Christian -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-k8-1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-4 Tiny utilities for small and embed ii cpio 2.6-10 GNU cpio -- a program to manage ar ii klibc-utils 1.2.2-3small statically-linked utilities ii udev 0.085-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337045: linux-image-2.6.14-1-686: I hate to "me too", but "me too"
I didn't think the module build was the problem either. You're right though- my laptop is a Dell D600 latitude, with a 1.6 GHz Centrino chipset. One thing I did notice is that it's using the "generic" ide chipset module, rather than one for my laptop. I will verify that this is the same with the 2.6.12 fallback kernel, but I wonder if maybe it's that it tries a different module for the ide chipset? Mind you, I was also reading bug #333052, and I wonder if this problem is related to that problem- they both seem like "race" problems to me. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337045: linux-image-2.6.14-1-686: I hate to "me too", but "me too"
Package: linux-image-2.6.14-1-686 Version: 2.6.14-2 Followup-For: Bug #337045 I have experienced exactly the same problem, just once, at boot-up time. It dumped me to busybox and I snooped around- there didn't appear to be anything dramatically different, but it reported the exact same error. For your information I have attached my lsmod output. One thing I did do directly before this error is try and remove tg3 and replace with the non-free bcm5700 network card driver (the reboot was supposed to finish the replacement, until I realised the initramfs is loading all my modules now- which is a different bag of fun for a different bug report). I am willing to try and help reproduce and fix this bug. Christian -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages linux-image-2.6.14-1-686 depends on: ii initramfs-tools [linux-initra 0.37 tools for generating an initramfs ii module-init-tools 3.2-pre9-3 tools for managing Linux kernel mo linux-image-2.6.14-1-686 recommends no packages. -- no debconf information Module Size Used by radeon109888 1 drm73940 2 radeon vmnet 29604 15 vmmon 176652 3 binfmt_misc11880 1 af_packet 22504 2 ipv6 266400 10 nfsd 243488 13 exportfs5728 1 nfsd lockd 65416 2 nfsd nfs_acl 3680 1 nfsd sunrpc147740 9 nfsd,lockd,nfs_acl parport_pc 36804 1 lp 11812 0 parport37064 2 parport_pc,lp autofs419044 1 button 6384 0 ac 4612 0 battery 9348 0 md_mod 67024 0 cpufreq_userspace 4412 1 cpufreq_powersave 1600 0 speedstep_centrino 7572 1 freq_table 4452 1 speedstep_centrino sd_mod 19280 0 scsi_mod 141768 1 sd_mod ide_cd 43556 0 cdrom 40896 1 ide_cd snd_intel8x0 35072 1 snd_intel8x0m 18692 0 snd_pcm_oss55040 0 snd_mixer_oss 19744 2 snd_pcm_oss snd_ac97_codec 98556 2 snd_intel8x0,snd_intel8x0m snd_pcm92200 4 snd_intel8x0,snd_intel8x0m,snd_pcm_oss,snd_ac97_codec snd_timer 24644 1 snd_pcm snd55620 7 snd_intel8x0,snd_intel8x0m,snd_pcm_oss,snd_mixer_oss,snd_ac97_codec,snd_pcm,snd_timer soundcore 9696 2 snd psmouse39492 0 serio_raw 7108 0 pcmcia 40604 4 evdev 9536 3 mousedev 11520 0 ext3 143528 4 jbd56564 1 ext3 mbcache 9252 1 ext3 dm_mod 60508 4 thermal13288 0 processor 22460 2 speedstep_centrino,thermal fan 4516 0 usbhid 38784 0 ide_disk 18720 5 ipw210086612 0 firmware_class 10464 2 pcmcia,ipw2100 ieee80211 23112 1 ipw2100 ieee80211_crypt 5188 1 ieee80211 ide_generic 1152 0 [permanent] yenta_socket 28268 6 rsrc_nonstatic 14144 1 yenta_socket pcmcia_core42960 3 pcmcia,yenta_socket,rsrc_nonstatic bcm5700 155628 0 ehci_hcd 35880 0 generic 4292 0 [permanent] piix 10404 0 [permanent] ide_core 131452 5 ide_cd,ide_disk,ide_generic,generic,piix snd_ac97_bus2080 1 snd_ac97_codec snd_page_alloc 10888 3 snd_intel8x0,snd_intel8x0m,snd_pcm uhci_hcd 33296 0 usbcore 124544 4 usbhid,ehci_hcd,uhci_hcd pci_hotplug28468 0 intel_agp 24124 1 agpgart35592 2 drm,intel_agp unix 27856 919
Bug#159803: Any update on this old bug?
Is there any update on this old bug? This problem is killing my home server- when the connection drops it fails to reconnect entirely. I have partially worked around the problem by putting a call to ifup in the post-ifdown of the interfaces file and removing the retry parameters from my dsl-provider script, but if there is some transient problem that prevents the reconnection attempt once, this configuration will not retry the connection again. Given that this apparently works with upstream's code (according to the previous submission to the bug, I have not tested that yet myself, though I would like to) and it's actually quite a serious problem (all pppoe connections, whatever quality, will encounter transients that cause termination occasionally) that could render a server inaccessible, I think this should be investigated as soon as possible. I am happy to attempt to contribute resources to the investigation. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315030: writes gateway ip to /etc/resolv.conf when using preseeded settings
I too have noticed this problem. It is very annoying when I'm trying to do a network console based install. I've looked at the code and I think the problem is in netcfg-common.c, function netcfg_get_nameservers. Lines 823-835 appear to try and be smart by offering the gateway IP address when prompting for a nameserver. The problem is that they don't look for a preseeded value first, and appear to simply debconf_set() the gateway IP. Obviously this isn't useful for preseeding, unless by happy chance your DNS was on your gateway. I have attached what I think is a patch to the netcfg (1.08) that appears to fix the problem on my test environment. It appears to work for both preseeded and unseeded values (defaulting to previous behaviour correctly, while supplying preseeded values when preseeded). Hope this helps, Christian --- netcfg-common.c.old 2005-06-21 11:22:27.0 -0400 +++ netcfg-common.c 2005-06-21 16:00:18.0 -0400 @@ -829,7 +829,11 @@ } else ptr = ""; -debconf_set(client, "netcfg/get_nameservers", ptr); + // Don't set the value if it already exists (consider preseeds) + debconf_get(client,"netcfg/get_nameservers"); + if (!strlen(client->value)) + debconf_set(client, "netcfg/get_nameservers", ptr); + debconf_input(client, "critical", "netcfg/get_nameservers"); ret = debconf_go(client);
Bug#312213: initrd-tools: patch fixes other modules too
Package: initrd-tools Version: 0.1.81.1 Followup-For: Bug #312213 The attached 1 line patch above fixes a serious problem with one of my computers where the bttv and sk98lin (eth0) modules are being loaded way too early (by the initrd) and are thus causing some unexpected configuration issues. It seems that the fact these modules are listed in /etc/modules is sufficient to cause them to be loaded by the initrd, since for some reason they are loaded by the dependency search engine. The patch fixes that behaviour- they are not included in the initrd any longer and get loaded at the correct time (and in the correct order) instead. I am using MODULES=dep and sarge initrd-tools, with the stock sarge 2.6.8-2-k7 kernel. I hope you will be able to fix the sarge initrd-tools too, since I don't want to run sid on the machine with the problem. (not the machine filing this bug report). Thanks, Christian -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii cpio 2.5-1.2GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.2-5The Debian Almquist Shell ii util-linux2.12p-4Miscellaneous system utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Yup. That worked a treat. Thanks! Christian On Wed, 2005-05-25 at 09:04 +0100, Patrick Caulfield wrote: Thanks. Can you try the updated package on http://people.debian.org/~patrick/ please? -- Christian Weeks <[EMAIL PROTECTED]>
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Patrick, I've verified my recreation of the problem. You can find working and non-working initrd images in http://weeksfamily.ca/lvmproblem/ There's also a package report showing the status of relevant packages. The only difference between the working and the non-working is the upgrade (well, downgrade- I built a non-working one first, then downgraded to a working one) from lvm-common 1.5.17 to 1.5.18 I built the initrd images by running: apt-get --reinstall install kernel-image-2.6.11-1-686, which I figure is the easiest way to build these things. I shall try this on another piece of equipment that also has an lvm root partition in the morning and let you know if the problem also exists there. Have fun and thanks for looking at this. -- Christian Weeks <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Hmm, I've regenerated a working one now... When I was examining it, it did have vgchange contained within it, and also another vgchange under /lib/lvm-200/ (or something similar)... I figured that one of the scripts was somehow choking when it tried to execute the vgchange executable in the initrd environment. After I finish work this evening (about 10 hours from now) I'll build and test that it's broken a broken one, for your perusal.. Is that OK? Thanks, Christian On Tue, 2005-05-24 at 07:54 +0100, Patrick Caulfield wrote: Christian Weeks wrote: > Package: lvm-common > Version: 1.5.18 > Severity: critical > Justification: breaks the whole system > > > I ran an upgrade this morning and picked up this package, among others, > including a new kernel image. This generated a new initrd which rendered > my "Root on LVM" system unbootable into the new kernel. Fortunately, I > had a recovery kernel on hand that still worked. > > After some frantic recovery work, I have determined that rolling back > lvm-common to 1.5.17 enables the generation of an unbroken initrd that > can be booted. > > The error reported during the boot process is "No program "vgchange" > exists for your LVM version". Root is unmountable and the kernel panics > shortly afterward. > > Frankly, this is a bit of a surprise- I didn't think this particular > package would be the problem cause. > > Sorry to create an RC bug, but this almost hosed my system completely > and my guess is it will break anyone who uses lvm on root after a kernel > upgrade. > So your initrd doesn't contain vgchange! hmmm. How ws the initrd generated and can you send me it please ? -- Christian Weeks <[EMAIL PROTECTED]>
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Package: lvm-common Version: 1.5.18 Severity: critical Justification: breaks the whole system I ran an upgrade this morning and picked up this package, among others, including a new kernel image. This generated a new initrd which rendered my "Root on LVM" system unbootable into the new kernel. Fortunately, I had a recovery kernel on hand that still worked. After some frantic recovery work, I have determined that rolling back lvm-common to 1.5.17 enables the generation of an unbroken initrd that can be booted. The error reported during the boot process is "No program "vgchange" exists for your LVM version". Root is unmountable and the kernel panics shortly afterward. Frankly, this is a bit of a surprise- I didn't think this particular package would be the problem cause. Sorry to create an RC bug, but this almost hosed my system completely and my guess is it will break anyone who uses lvm on root after a kernel upgrade. Christian -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages lvm-common depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo ii modutils2.4.27.0-3 Linux module utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310228: pmount: Pmount ignores a lot of hal policy mount option
Package: pmount Version: 0.8-2 Severity: important hal release 0.4.7-4 provided some new options to control mount policy, stuff like umask and gid for mountable devices. Unfortunately, pmount-hal completely ignores anything specified there. I think that pmount needs to be patched to query and use these options if they are set. I think that these two fixes in combination will allow the closing of 296914. I think this is an important bug to fix, since there is a CLEARLY defined policy now available through a well specified mechanism, and pmount is completely ignoring it- rendering the package useless to me as the mounted device could be exploited by an undesireable by simply sitting at my computer and plugging the device in. I'm going to look at providing a patch to pmount to add this in. Hopefully will be done soon. Thanks, Christian -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages pmount depends on: ii dbus-1 0.23.4-1 simple interprocess messaging syst ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libhal0 0.4.7-4 Hardware Abstraction Layer - share ii libsysfs1 1.2.0-5 interface library to sysfs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298950: /sbin/udevsend breaks hotplug firmware loading?
Package: udev Version: 0.054-2 Severity: important Hello, I just done a clean install of my laptop. I had had my ipw2100 wireless card working for some time, however, after the clean install it simply has refused to work. I just noticed that udev has recently changed the /proc/sys/kernel/hotplug value to /sbin/udevsend. It appears that /sbin/udevsend is somehow swallowing the firmware load request event? A walkthrough of what happens: Set the hotplug agend to udevsend: cweeks-lap:/home/cpw# echo /sbin/udevsend >/proc/sys/kernel/hotplug Try probing my module: cweeks-lap:/home/cpw# modprobe -v ipw2100 insmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ieee80211_crypt.ko insmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ieee80211.ko insmod /lib/modules/2.6.8-2-686/kernel/drivers/base/firmware_class.ko insmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ipw2100.ko The kernel doesn't like it: cweeks-lap:/home/cpw# tail -10 /var/log/kern.log Mar 10 14:14:48 localhost kernel: ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.5 Mar 10 14:14:48 localhost kernel: ipw2100: Copyright(c) 2003-2004 Intel Corporation Mar 10 14:14:48 localhost kernel: ACPI: PCI interrupt :02:03.0[A] -> GSI 7 (level, low) -> IRQ 7 Mar 10 14:14:48 localhost kernel: ipw2100: Detected Intel PRO/Wireless 2100 Network Connection Mar 10 14:14:58 localhost kernel: ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. Mar 10 14:14:58 localhost kernel: ipw2100: eth1: ipw2100_get_firmware failed: -2 Mar 10 14:14:58 localhost kernel: ipw2100: eth1: Failed to power on the adapter. Mar 10 14:14:58 localhost kernel: ipw2100: eth1: Failed to start the firmware. Mar 10 14:14:58 localhost kernel: ipw2100Error calling register_netdev. Mar 10 14:14:58 localhost kernel: ipw2100: probe of :02:03.0 failed with error -5 Cleanup: cweeks-lap:/home/cpw# modprobe -v -r ipw2100 rmmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ipw2100.ko rmmod /lib/modules/2.6.8-2-686/kernel/drivers/base/firmware_class.ko rmmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ieee80211.ko rmmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ieee80211_crypt.ko Set the hotplug agent to hotplug: cweeks-lap:/home/cpw# echo /sbin/hotplug >/proc/sys/kernel/hotplug Try probing again: cweeks-lap:/home/cpw# modprobe -v ipw2100 insmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ieee80211_crypt.ko insmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ieee80211.ko insmod /lib/modules/2.6.8-2-686/kernel/drivers/base/firmware_class.ko insmod /lib/modules/2.6.8-2-686/kernel/drivers/net/wireless/ipw2100.ko No errors this time: cweeks-lap:/home/cpw# tail -10 /var/log/kern.log Mar 10 14:14:58 localhost kernel: ipw2100: eth1: Failed to power on the adapter. Mar 10 14:14:58 localhost kernel: ipw2100: eth1: Failed to start the firmware. Mar 10 14:14:58 localhost kernel: ipw2100Error calling register_netdev. Mar 10 14:14:58 localhost kernel: ipw2100: probe of :02:03.0 failed with error -5 Mar 10 14:16:18 localhost kernel: ieee80211_crypt: unregistered algorithm 'NULL' (deinit) Mar 10 14:17:03 localhost kernel: ieee80211_crypt: registered algorithm 'NULL' Mar 10 14:17:03 localhost kernel: ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.5 Mar 10 14:17:03 localhost kernel: ipw2100: Copyright(c) 2003-2004 Intel Corporation Mar 10 14:17:03 localhost kernel: ACPI: PCI interrupt :02:03.0[A] -> GSI 7 (level, low) -> IRQ 7 Mar 10 14:17:03 localhost kernel: ipw2100: Detected Intel PRO/Wireless 2100 Network Connection And my wireless device is visible: cweeks-lap:/home/cpw# cat /proc/net/wireless Inter-| sta-| Quality| Discarded packets | Missed | WE face | tus | link level noise | nwid crypt frag retry misc | beacon | 16 eth1: 08000.0.0. 0 0 0 0 0 0 Thanks, Christian -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 0 lrwxrwxrwx 1 root root 19 2005-03-09 23:30 cd-aliases.rules -> ../cd-aliases.rules lrwxrwxrwx 1 root root 13 2005-03-09 23:30 udev.rules -> ../udev.rules lrwxrwxrwx 1 root root 12 2005-03-09 23:29 z_hal-plugdev.rules -> ../hal.rules -- /sys/: /sys/block/dm-0/dev /sys/block/dm-1/dev /sys/block/dm-2/dev /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hdc/dev /sys/block/hdc/hdc1/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/class/drm/radeon/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/event2/dev /sys/class/input/event3/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/input/mouse1/dev /sys/class/input/ts0/dev /sys/class
