Bug#997925: qemu-system-data: keymap files placed in wrong directory?
Package: qemu-system-data Version: 1:6.1+dfsg-7 Severity: important X-Debbugs-Cc: dbr...@schutzwerk.com Dear Maintainer, since today I receive the following error when launching qemu: $ /usr/bin/qemu-system-x86_64 -device virtio-rng-pci \ -device virtio-net,netdev=user.0 -m 1024M \ -name packer_base_image -machine type=pc,accel=kvm -display gtk \ -boot once=d -netdev user,id=user.0,hostfwd=tcp::2235-:22 \ -vnc 127.0.0.1:76 \ -drive file=output-qemu/packer_base_image,if=virtio,cache=writeback,discard=ignore,format=raw \ -drive file=,media=cdrom qemu-system-x86_64: -vnc 127.0.0.1:76: could not read keymap file: 'en-us' Now, using strace I can see that qemu is trying to access the paths /usr/share/qemu/keymaps/en-us, /usr/share/seabios/keymaps/en-us and /usr/lib/ipxe/qemu/keymaps/en-us before failing. According to the package database, at least /usr/share/qemu/keymaps/en-us should be provided by qemu-system-data (https://packages.debian.org/bullseye/all/qemu-system-data/filelist). However, the directory /usr/share/qemu/keymaps does not exist. I observed that the file /usr/share/qemu/en-us exists instead of /usr/share/qemu/keymaps/en-us. And the following commands can actually be used to work around the problem: sudo mkdir /usr/share/qemu/keymaps; \ sudo cp /usr/share/qemu/en-us /usr/share/qemu/keymaps So it appears to me that the keymap files are placed in the wrong directory? According to my dpkg logs, I upgraded qemu-system-data from 1:6.1+dfsg-6 to 1:6.1+dfsg-7 this morning (27.10.2021). However, it might have been broken for longer since I haven't used qemu for a few weeks. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information OpenPGP_signature Description: OpenPGP digital signature
Bug#766284: still an issue Re: openjdk-8-jre-jamvm: JamVM fails with incorrect ClassBlock padding
Package: openjdk-8-jre-jamvm Version: 8u40~b22-2 Followup-For: Bug #766284 Dear Maintainer, dbrown@debian:~$ java -jamvm -version Error initialising VM (initialiseClassStage2) ClassBlock padding is less than java.lang.Class fields! Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 3.2.0-4-kirkwood Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openjdk-8-jre-jamvm depends on: ii libc6 2.19-14 ii openjdk-8-jre-headless 8u40~b22-2 ii zlib1g 1:1.2.7.dfsg-13 openjdk-8-jre-jamvm recommends no packages. openjdk-8-jre-jamvm suggests no packages. -- no debconf information -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64), Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-8-jre-jamvm depends on: ii libc6 2.19-16 ii openjdk-8-jre-headless 8u40~b22-2 ii zlib1g 1:1.2.8.dfsg-2+b1 openjdk-8-jre-jamvm recommends no packages. openjdk-8-jre-jamvm suggests no packages. -- no debconf information David Brown
Bug#741698: [Pkg-xfce-devel] Bug#741698:
On 05/10/2014 08:32 PM, L. David Brown, Jr. wrote: > On Thu, 27 Mar 2014 22:31:06 +, Chris Bainbridge wrote: >> On 27 March 2014 21:16, Yves-Alexis Perez wrote: >>> Installing systemd-sysv makes systemd your init system. That's not >>> something we're ready to do. >> >> The other bug does mention some kind of shim that implements the dbus >> service that could be used. I'm not sure how much testing or >> development it will get now that systemd is default though. >> >>> lightdm (and Xfce, for what matters) still works fine with sysvrc and >>> consolekit. >> >> Ok, but in that case suspend does not happen if the user switches to a >> virtual terminal and closes the lid. The org.freedesktop.systemd1 >> error gets printed to the virtual terminal. Suspend does happen from >> within XFCE even though the org.freedesktop.systemd1 error is shown. >> It is not a big problem - switching to a virtual terminal and then >> closing the laptop is probably a rare sequence of actions. > > Sorry if this gets totally hosed by not getting to the proper thread. > > If this helps any, I have sysv-rc installed, which seems to bring > systemd et.al., to the party. I noticed this starting to happen within > the last week, though, I can't remember exactly when. When I try to > switch from sysv-rc to openrc, the only conflict is that resolvconf does > not accept openrc as an alternative for sysv-rc. The version of > resolvconf I have installed is 1.74 on a jessie system. > > I can't see why I have resolvconf installed to be honest. May be a > hold-over from previous installations as I use puppet to manage my > systems. Going to try to removing resolvconf, switching to openrc from > sysv-rc, then see what happens. Will report back after a bit of > testing. I know doesn't affect root cause, but may provide a > work-around for systemd getting installed! Good news so far in that I have seen no ill-effects from zapping resolvconf and sysv-rc in favor of openrc. The only gotcha I have seen so far was I needed to upgrade the VMware Player software I had on the machine. Not a huge deal as I probably should have done that a while ago. May mean a reinstall of VMware, though. > On a related note--maybe--in th past I relied on hal to provide group > powerdev, of which I was a member. Not sure exactly when hal was > obsoleted. May or not be an related though. I have purged hal as it > was obsolete. However, once I performed the above removal of sysv-rc, > additional hal related packages removed as well--not sure if due to > sysv-rc being removed or just aptitude catching up with the removal of > the hal package from a previous run, though! This seems to be a red herring so can be ignored, I believe. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741698: [Pkg-xfce-devel] Bug#741698:
On Thu, 27 Mar 2014 22:31:06 +, Chris Bainbridge wrote: > On 27 March 2014 21:16, Yves-Alexis Perez wrote: > > Installing systemd-sysv makes systemd your init system. That's not > > something we're ready to do. > > The other bug does mention some kind of shim that implements the dbus > service that could be used. I'm not sure how much testing or > development it will get now that systemd is default though. > > > lightdm (and Xfce, for what matters) still works fine with sysvrc and > > consolekit. > > Ok, but in that case suspend does not happen if the user switches to a > virtual terminal and closes the lid. The org.freedesktop.systemd1 > error gets printed to the virtual terminal. Suspend does happen from > within XFCE even though the org.freedesktop.systemd1 error is shown. > It is not a big problem - switching to a virtual terminal and then > closing the laptop is probably a rare sequence of actions. Sorry if this gets totally hosed by not getting to the proper thread. If this helps any, I have sysv-rc installed, which seems to bring systemd et.al., to the party. I noticed this starting to happen within the last week, though, I can't remember exactly when. When I try to switch from sysv-rc to openrc, the only conflict is that resolvconf does not accept openrc as an alternative for sysv-rc. The version of resolvconf I have installed is 1.74 on a jessie system. I can't see why I have resolvconf installed to be honest. May be a hold-over from previous installations as I use puppet to manage my systems. Going to try to removing resolvconf, switching to openrc from sysv-rc, then see what happens. Will report back after a bit of testing. I know doesn't affect root cause, but may provide a work-around for systemd getting installed! On a related note--maybe--in th past I relied on hal to provide group powerdev, of which I was a member. Not sure exactly when hal was obsoleted. May or not be an related though. I have purged hal as it was obsolete. However, once I performed the above removal of sysv-rc, additional hal related packages removed as well--not sure if due to sysv-rc being removed or just aptitude catching up with the removal of the hal package from a previous run, though! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666257: libderiving-ocsigen-ocaml works
Given that libderiving-ocsigen-ocaml seems to work, this could probably be consider low priority, and possibly this package isn't even necessary. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666257: Compile command for test program
To build the test program: ocamlfind ocamlc -linkpkg -package deriving -pp deriving -o dtest dtest.ml which only works with the updated META file. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666257: libderiving-ocaml: Programs using libderiving fail to link (archive missing in META)
Package: libderiving-ocaml
Version: 0.1.1a-3+b1
Severity: normal
Dear Maintainer,
There are two problems with the META file in /usr/lib/ocaml/deriving/META
- The archives aren't mentioned, so ocamlfind doesn't try bringing
in the appropriate libraries.
- The files depend on the num package which is not mentioned.
With this version of the META file, I am able to link the program
below. Without the archive lines, it fails to link because of a
reference to the Show module. Without the 'requires' line, it fails
to link because of a reference to Num.
--
version = "0.1.1a-3+b1"
name = "deriving"
requires = "num"
description = "deriving functions"
archive(byte) = "deriving.cma"
archive(native) = "deriving.cmxa"
--
type foo = { a: int } deriving (Show)
let () = Printf.printf "%s\n" (Show.show {a=42})
--
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libderiving-ocaml depends on:
ii ocaml-base-nox [ocaml-base-nox-3.12.1] 3.12.1-2
Versions of packages libderiving-ocaml recommends:
ii ocaml-findlib 1.2.8+debian-1
libderiving-ocaml 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#658567: gnat: Compiler assertion on precondition
Package: gnat-4.6 Version: 4.6.2-3 Severity: normal Tags: upstream Dear Maintainer, Reported in upstream gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52121 sources available on the GCC bts % gcc-4.6 -c -gnat12 -gnata heap_sieve.adb +===GNAT BUG DETECTED==+ | 4.6.2 (x86_64-pc-linux-gnu) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:353 | | Error detected at heap.ads:18:22 [heap_sieve.ads:39:4] | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.6 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnat-4.6 depends on: ii gcc-4.64.6.2-12 ii gnat-4.6-base 4.6.2-3 ii libc6 2.13-24 ii libc6-dev 2.13-24 ii libgcc11:4.6.2-12 ii libgmp10 2:5.0.2+dfsg-2 ii libgnat-4.64.6.2-3 ii libgnatprj4.6 4.6.2-3 ii libgnatvsn4.6 4.6.2-3 ii libmpc20.9-4 ii libmpfr4 3.1.0-3 ii multiarch-support 2.13-24 ii zlib1g 1:1.2.3.4.dfsg-3 gnat-4.6 recommends no packages. Versions of packages gnat-4.6 suggests: pn ada-reference-manual-html 1:2005.2-1 pn ada-reference-manual-info pn ada-reference-manual-pdf pn ada-reference-manual-text 1:2005.2-1 pn gnat-4.6-doc pn gnat-4.6-sjlj -- 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#658566: gnat: Compiler assertion in iterator
Package: gnat-4.6 Version: 4.6.2-3 Severity: normal Tags: upstream Dear Maintainer, Bug also reported in upstream at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52120 attachment available there Compiling with gcc-4.6 -c -gnat12 heap_sieve.adb +===GNAT BUG DETECTED==+ | 4.6.2 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:1072| | Error detected at heap_sieve.adb:83:30 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.6 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnat-4.6 depends on: ii gcc-4.64.6.2-12 ii gnat-4.6-base 4.6.2-3 ii libc6 2.13-24 ii libc6-dev 2.13-24 ii libgcc11:4.6.2-12 ii libgmp10 2:5.0.2+dfsg-2 ii libgnat-4.64.6.2-3 ii libgnatprj4.6 4.6.2-3 ii libgnatvsn4.6 4.6.2-3 ii libmpc20.9-4 ii libmpfr4 3.1.0-3 ii multiarch-support 2.13-24 ii zlib1g 1:1.2.3.4.dfsg-3 gnat-4.6 recommends no packages. Versions of packages gnat-4.6 suggests: pn ada-reference-manual-html 1:2005.2-1 pn ada-reference-manual-info pn ada-reference-manual-pdf pn ada-reference-manual-text 1:2005.2-1 pn gnat-4.6-doc pn gnat-4.6-sjlj -- 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#655273: Correct duplicate bug
Ugh. The other bug is #655275. Please keep 655275, and delete 655273. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655273: Duplicate.
This bug is a partially aborted first attempt. Please see #655273 for more information. Probably best fo just close 655273. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655275: clisp: on armel architecture not specified in *FEATURES*
Package: clisp Version: 1:2.49-8 Severity: normal On the armel target, clisp doesn't set anything in *FEATURES* that allows the architecture to be uniquely determined. This causes a warning from packages, such as swank: WARNING: No architecture feature found in (POWERPC PPC X86 X86-64 X86_64 AMD64 I686 I586 I486 PC386 IAPX386 SPARC64 SPARC HPPA64 HPPA ARM PENTIUM3 PENTIUM4 JAVA-1.4 JAVA-1.5 ...). I think the correct solution is to set :ARM in *FEATURES* when built on this target. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv7l) Kernel: Linux 3.1.0-rc7-d3 (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/dash Versions of packages clisp depends on: ii libc6 2.13-21 ii libffcall11.10+cvs20100619-2 ii libgcc1 1:4.6.2-5 ii libncurses5 5.9-4 ii libreadline5 5.2-11 ii libsigsegv2 2.9-4 clisp recommends no packages. Versions of packages clisp suggests: ii clisp-dev ii clisp-doc ii gdb ii slime 1:20111027-2 -- 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#655273: clisp: armel doesn't set :ARM in *features*
Package: clisp Version: 1:2.49-8 Severity: normal On other architectures, clisp sets a *features* flag indicating the architecture. It seems other tools, such as swank, are expecing :ARM to be set in this. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv7l) Kernel: Linux 3.1.0-rc7-d3 (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/dash Versions of packages clisp depends on: ii libc6 2.13-21 ii libffcall11.10+cvs20100619-2 ii libgcc1 1:4.6.2-5 ii libncurses5 5.9-4 ii libreadline5 5.2-11 ii libsigsegv2 2.9-4 clisp recommends no packages. Versions of packages clisp suggests: ii clisp-dev ii clisp-doc ii gdb ii slime 1:20111027-2 -- 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#624343: linux-image-2.6.38-2-amd64: frequent message "bio too big device md0 (248 > 240)" in kern.log
On 02/05/11 18:38, Jameson Graef Rollins wrote: On Mon, 02 May 2011 11:11:25 +0200, David Brown wrote: This is not directly related to your issues here, but it is possible to make a 1-disk raid1 set so that you are not normally degraded. When you want to do the backup, you can grow the raid1 set with the usb disk, want for the resync, then fail it and remove it, then "grow" the raid1 back to 1 disk. That way you don't feel you are always living in a degraded state. Hi, David. I appreciate the concern, but I am not at all concerned about "living in a degraded state". I'm far more concerned about data loss and the fact that this bug has seemingly revealed that some commonly held assumptions and uses of software raid are wrong, with potentially far-reaching affects. I also don't see how the setup you're describing will avoid this bug. If this bug is triggered by having a layer between md and the filesystem and then changing the raid configuration by adding or removing a disk, then I don't see how there's a difference between hot-adding to a degraded array and growing a single-disk raid1. In fact, I would suspect that your suggestion would be more problematic because it involves *two* raid reconfigurations (grow and then shrink) rather than one (hot-add) to achieve the same result. I imagine that each raid reconfiguration could potentially triggering the bug. But I still don't have a clear understanding of what is going on here to be sure. I didn't mean to suggest this as a way around these issues - I was just making a side point. Like you and others in this thread, I am concerned about failures that could be caused by having the sort of layered and non-homogeneous raid you describe. I merely mentioned single-disk raid1 "mirrors" as an interesting feature you can get with md raid. Many people don't like to have their system in a continuous error state - it can make it harder to notice when you have a /real/ problem. And single-disk "mirrors" gives you the same features, but no "degraded" state. As you say, it is conceivable that adding or removing disks to the raid could make matters worse. From what I have read so far, it looks like you can get around problems here if the usb disk is attached when the block layers are built up (i.e., when the dm-crypt is activated, and the lvm and filesystems on top of it). It should then be safe to remove it, and re-attach it later. Of course, it's hardly ideal to have to attach your backup device every time you boot the machine! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624343: linux-image-2.6.38-2-amd64: frequent message "bio too big device md0 (248 > 240)" in kern.log
On 02/05/2011 00:06, Jameson Graef Rollins wrote: On Fri, 29 Apr 2011 05:39:40 +0100, Ben Hutchings wrote: On Wed, 2011-04-27 at 09:19 -0700, Jameson Graef Rollins wrote: I run what I imagine is a fairly unusual disk setup on my laptop, consisting of: ssd -> raid1 -> dm-crypt -> lvm -> ext4 I use the raid1 as a backup. The raid1 operates normally in degraded mode. For backups I then hot-add a usb hdd, let the raid1 sync, and then fail/remove the external hdd. This is not directly related to your issues here, but it is possible to make a 1-disk raid1 set so that you are not normally degraded. When you want to do the backup, you can grow the raid1 set with the usb disk, want for the resync, then fail it and remove it, then "grow" the raid1 back to 1 disk. That way you don't feel you are always living in a degraded state. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#468131: aplus crashes at start
Subject: aplus-fsf: A+ crashes at start Package: aplus-fsf Version: 4.20.2-5 Severity: important *** Please type your report below this line *** Like bug #422970, aplus crashes immediately upon hitting F4. However,after reading bug #422970, I installed xfonts-kapl before starting xemacs and trying to start A+. I get the following result in xemacs: Starting... A+ Copyright (c) 1990-2005 Morgan Stanley. All rights reserved. This version is Release 4.20 *** glibc detected *** free(): invalid next size (normal): 0x005e47c0 *** Process `a' aborted Note that on the same machine, using the Intel x86 (32-bit) Debian Etch on a different partition, I do NOT get this error. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages aplus-fsf depends on: ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298148: kdebase-bin: kcheckpass needs setuid bit for ldap authentication
Package: kdebase-bin Severity: normal Subject: kdebase-bin: kcheckpass won't use ldap authentication without setuid Package: kdebase-bin Version: 4:3.3.2-1 Severity: normal -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (650, 'unstable'), (600, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages kdebase-bin depends on: ii kdelibs4 4:3.3.2-1 KDE core libraries ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6 client library to control the FAM ii libgcc1 1:3.4.3-9 GCC support library ii libice6 4.3.0.dfsg.1-10 Inter-Client Exchange library ii libidn11 0.5.2-3 GNU libidn library, implementation ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt3:3.3.3-8 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-10 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxtst6 4.3.0.dfsg.1-10 X Window System event recording an ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information More potentially useful stuff: ii libldap2 2.1.30-3 OpenLDAP libraries ii libnss-ldap220-1 NSS module for using LDAP as a naming servic ii libpam-ldap169-1 Pluggable Authentication Module allowing LDA ii kdebase-bin3.3.2-1KDE Base (binaries) ii libpam-modules 0.76-22Pluggable Authentication Modules for PAM ii libpam-runtime 0.76-22Runtime support for the PAM library ii libpam0g 0.76-22Pluggable Authentication Modules library This may somewhat relate to bug #212212... It looks like it is a known issue with kcheckpass and ldap authentication that kcheckpass needs to be setuid. See http://lists.fini.net/pipermail/ldap-interop/2005-January/000208.html and search for kcheckpass. kscreensaver invokes kcheckpass like so: kcheckpass -c kscreensaver -m classic -S 13 This results in: Communication breakdown on write Once kcheckpass is setuid it works. According to the post referenced above, the real fix is to write a setuid wrapper to access the credentials cache. I don't know if debian is even using that cache; I can't find it. Regardless, kcheckpass will fail when ldap authentication is used currently. Adding the setuid bit fixes it. This should probably be considered a workaround until a safer, more permanent fix is found. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (650, 'unstable'), (600, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-1-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
