Bug#782463: debconf: purging package that uses debconf fails if postrm writes to stdout
Doh. With word wrap: Packages that use debconf automatically get a postrm fragment for purge that sources confmodule. This breaks if the maintainer has a custom postrm that can write to stdout before the #DEBHELPER# line, because the redirection of stdout to stderr does not occur until the #DEBHELPER# line is reached for the second time. This results in an unpurgeable package. Here is a minimal package that repros the problem: ... The problem can be fixed by having the re-exec in confmodule go through a helper script to do the redirection before running any maintainer code, such as with this patch: ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782463: debconf: purging package that uses debconf fails if postrm writes to stdout
Package: debconf Version: 1.5.51 Severity: normal Packages that use debconf automatically get a postrm fragment for purge that sources confmodule. This breaks if the maintainer has a custom postrm that can write to stdout before the #DEBHELPER# line, because the redirection of stdout to stderr does not occur until the #DEBHELPER# line is reached for the second time. This results in an unpurgeable package. Here is a minimal package that repros the problem: diff -urN nosuchdir/debian/changelog debconfbugrepro-1.0/debian/changelog --- nosuchdir/debian/changelog 1969-12-31 19:00:00.0 -0500 +++ debconfbugrepro-1.0/debian/changelog2015-04-12 12:33:57.974322459 -0400 @@ -0,0 +1,5 @@ +debconfbugrepro (1.0) unstable; urgency=low + + * Test. + + -- Nobody Sun, 12 Apr 2015 12:33:11 -0400 diff -urN nosuchdir/debian/compat debconfbugrepro-1.0/debian/compat --- nosuchdir/debian/compat 1969-12-31 19:00:00.0 -0500 +++ debconfbugrepro-1.0/debian/compat 2015-04-12 12:29:18.490332697 -0400 @@ -0,0 +1 @@ +9 diff -urN nosuchdir/debian/control debconfbugrepro-1.0/debian/control --- nosuchdir/debian/control1969-12-31 19:00:00.0 -0500 +++ debconfbugrepro-1.0/debian/control 2015-04-12 12:30:40.090329708 -0400 @@ -0,0 +1,10 @@ +Source: debconfbugrepro +Section: misc +Priority: optional +Maintainer: Nobody +Standards-Version: 3.9.6 + +Package: debconfbugrepro +Architecture: all +Description: test + Test. diff -urN nosuchdir/debian/postrm debconfbugrepro-1.0/debian/postrm --- nosuchdir/debian/postrm 1969-12-31 19:00:00.0 -0500 +++ debconfbugrepro-1.0/debian/postrm 2015-04-12 12:31:34.758327706 -0400 @@ -0,0 +1,4 @@ +#!/bin/sh +echo 'Simulate doing something that writes to stdout' +#DEBHELPER# +exit 0 diff -urN nosuchdir/debian/rules debconfbugrepro-1.0/debian/rules --- nosuchdir/debian/rules 1969-12-31 19:00:00.0 -0500 +++ debconfbugrepro-1.0/debian/rules2015-04-12 12:34:39.242320948 -0400 @@ -0,0 +1,3 @@ +#!/usr/bin/make -f +%: + dh $@ diff -urN nosuchdir/debian/templates debconfbugrepro-1.0/debian/templates --- nosuchdir/debian/templates 1969-12-31 19:00:00.0 -0500 +++ debconfbugrepro-1.0/debian/templates2015-04-12 12:32:03.550326651 -0400 @@ -0,0 +1,4 @@ +Template: debconfbugrepro/test +Type: string +Description: test + Test. Purging this package fails: $ sudo dpkg -P debconfbugrepro (Reading database ... 577471 files and directories currently installed.) Removing debconfbugrepro (1.0) ... Simulate doing something that writes to stdout Purging configuration files for debconfbugrepro (1.0) ... Simulate doing something that writes to stdout dpkg: error processing package debconfbugrepro (--purge): subprocess installed post-removal script returned error exit status 128 Errors were encountered while processing: debconfbugrepro $ The problem can be fixed by having the re-exec in confmodule go through a helper script to do the redirection before running any maintainer code, such as with this patch: diff -urN debconf.bak/confmodule debconf/confmodule --- debconf.bak/confmodule 2015-04-12 13:11:31.850239896 -0400 +++ debconf/confmodule 2015-04-12 13:07:16.898249235 -0400 @@ -12,28 +12,13 @@ # Since there is no FrontEnd, this program execs a FrontEnd. # It will then run a new copy of $0 that can talk to it. if [ "$DEBCONF_USE_CDEBCONF" ]; then - exec /usr/lib/cdebconf/debconf $0 "$@" + exec /usr/lib/cdebconf/debconf /usr/share/debconf/wrapper.sh "$0" "$@" else - exec /usr/share/debconf/frontend $0 "$@" + exec /usr/share/debconf/frontend /usr/share/debconf/wrapper.sh "$0" "$@" fi fi -# Only do this once. -if [ -z "$DEBCONF_REDIR" ]; then - # Redirect standard output to standard error. This prevents common - # mistakes by making all the output of the postinst or whatever - # script is using this library not be parsed as confmodule commands. - # - # To actually send something to standard output, send it to fd 3. - exec 3>&1 - if [ "$DEBCONF_USE_CDEBCONF" ]; then - exec 1>&5 - else - exec 1>&2 - fi - DEBCONF_REDIR=1 - export DEBCONF_REDIR -fi +. /usr/share/debconf/setup-redir ### # Commands. diff -urN debconf.bak/setup-redir debconf/setup-redir --- debconf.bak/setup-redir 1969-12-31 19:00:00.0 -0500 +++ debconf/setup-redir 2015-04-12 13:03:50.642256791 -0400 @@ -0,0 +1,17 @@ +#!/bin/sh +# Only do this once. +if [ -z "$DEBCONF_REDIR" ]; then +# Redirect standard output to standard error. This prevents common +# mistakes by making all the output of the postinst or whatever +# script is using this library not be parsed as confmodule commands. +# +# To actually send something to standard output,
Bug#774175: RFS: libgaminggear/0.5.0-1 [ITP]
retitle 774175 RFS: libgaminggear/0.6.0-1 [ITP] thanks Uploaded 0.6.0-1 with new upstream revision. On Thu, Jan 22, 2015 at 8:10 AM, Tristan Schmelcher wrote: > I've uploaded a new revision that fixes the issues Riley pointed out and more. > > FYI, I am pretty sure the hardening-no-fortify-functions is a false > positive since the build is blhc-clean. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776103: debhelper: dh_shlibdeps doesn't support multiple -L options
Sorry for the lack of line breaks. Here is the same text with line breaks added: dpkg-shlibdeps supports multiple -S options, which dh_shlibdeps wraps as -L. But dh_shlibdeps does not support multiple -L options. The last one is the only one that has an effect. This means that a source package that ships private shared libraries in multiple binary packages and ships other packages that depend on them cannot use -L to inform dh_shlibdeps where to find them. The package instead has to use -l, which defeats some of the smarts in dpkg-shlibdeps. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776103: debhelper: dh_shlibdeps doesn't support multiple -L options
Package: debhelper Version: 9.20150101 Severity: normal dpkg-shlibdeps supports multiple -S options, which dh_shlibdeps wraps as -L. But dh_shlibdeps does not support multiple -L options. The last one is the only one that has an effect. This means that a source package that ships private shared libraries in multiple binary packages and ships other packages that depend on them cannot use -L to inform dh_shlibdeps where to find them. The package instead has to use -l, which defeats some of the smarts in dpkg-shlibdeps. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774175: RFS: libgaminggear/0.5.0-1 [ITP]
I've uploaded a new revision that fixes the issues Riley pointed out and more. FYI, I am pretty sure the hardening-no-fortify-functions is a false positive since the build is blhc-clean. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774175: New revision
I've uploaded a new revision that fixes the issues Riley pointed out and more. FYI, I am pretty sure the hardening-no-fortify-functions is a false positive since the build is blhc-clean. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774175: RFS: libgaminggear/0.5.0-1 [ITP]
On Jan 1, 2015 4:37 PM, "Riley Baird" < bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch> wrote: > > Hi, I'm not a DD, so I can't sponsor your package, but I looked at your > package and here are some things that I noticed: > > * You should add DEP-3 headers to your patches: > http://dep.debian.net/deps/dep3/ > > * To comply with Debian's policy on convenience copies, you'll have to > remove the local copy of jquery.js and depend on libjs-query. (Unless, > of course your version is different. I haven't checked.) > > * In d/control, since you've already defined Section:libs in the source > package, you can remove the section field from libgaminggear0 and > libgaminggear-common. > > Good luck getting your package into Debian! > > Riley Baird Thanks for the feedback. I'll add the DEP-3 headers and remove the redundant sections fields. I am unsure what to do about jquery though. That file gets embedded into the binary package by the doxygen run. It's not even shipped in upstream libgaminggear. It seems to me that depending on libjs-query would be fragile since doxygen's internal jquery version and libjs-query's version would not be guaranteed to have compatible APIs as those packages evolve. It seems there are lots of doxygen-generated package violating this policy. Is this considered an exception to the rule, I wonder?
Bug#774175: RFS: libgaminggear/0.5.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libgaminggear". Packaging this library is a prerequisite for packaging "roccat-tools", which I intend to do too. * Package name: libgaminggear Version : 0.5.0-1 Upstream Author : Stefan Achatz * URL : https://sourceforge.net/projects/libgaminggear/ * License : GPL-2+ with CC-BY-3.0 icons Section : libs It builds those binary packages: libgaminggear-common - Icons for libgaminggear libgaminggear-dev - Development files for libgaminggear libgaminggear-doc - Documentation for libgaminggear libgaminggear0 - Provides functionality for gaming input devices To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libgaminggear Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libg/libgaminggear/libgaminggear_0.5.0-1.dsc Regards, Tristan Schmelcher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718032: Working on it
I am working on packaging roccat-tools, starting with its dependency, libgaminggear. I've opened bug 773402 for packaging libgaminggear. I'm not a DD so I'm going to find a sponsor. The libgaminggear package is pretty much done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773402: ITP: libgaminggear -- Provides functionality for gaming input devices
Package: wnpp Severity: wishlist Owner: Tristan Schmelcher * Package name: libgaminggear Version : 0.5.0 Upstream Author : Stefan Achatz * URL : https://sourceforge.net/projects/libgaminggear/ * License : GPL2 Programming Lang: C Description : Provides functionality for gaming input devices libgaminggear is a support library for userspace device input drivers to facilitate implementation of advanced features commonly found in gaming peripherals, such as macros. This library needs to be packaged in order to package roccat-tools. I am planning to package and maintain both of them (I will need a sponsor). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634073: Svn launches kwallet
+1 to not launching kwallet by default.
Bug#640158: vnc4server: 100% CPU hang when run from inetd in nowait mode
FYI, the Ubuntu bug report is https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/819473 On Fri, Sep 2, 2011 at 3:29 PM, Tristan Schmelcher wrote: > Package: vnc4 > Version: 4.1.1+X4.3.0-37 > Severity: normal > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu oneiric ubuntu-patch > > > I have been experiencing this bug for several years but I finally decided to > investigate it. I run Xvnc through xinetd and I often find that there are > left-over Xvnc processes each consuming 100% CPU. They tend to crop up when a > client disconnects. In particular, scanning ports with nmap produces the > problem every time. > > I've tracked down the problem and implemented a fix. The issue is that Xvnc > in inetd mode detects whether it is run as "wait" or "nowait" by checking if > the inetd socket has a valid peer name with getpeername(). If it has a valid > peer name then it assumes nowait mode, otherwise it assumes wait mode. But > this is unreliable, because if it is run in nowait mode and a client connects > and disconnects very quickly then the socket will no longer have a valid peer > name when Xvnc checks and it will mistakenly use wait mode. The 100% CPU > results from repeatedly trying to call accept() on the socket in the select > loop. > > My solution is to instead detect wait vs. nowait via getsockopt(..., > SOL_SOCKET, SO_ACCEPTCONN, ...), which works reliably in both modes. > > *** /tmp/tmpkCQys0 > I have sent the attached patch to Ubuntu, but I am sending it to Debian too > because there is nothing Ubuntu-specific about it. > > > * Fix 100% CPU hang when run from inetd in nowait mode if a client connects > and disconnects quickly (e.g., nmap). > > > Thanks for considering the patch. > > > -- System Information: > Debian Release: squeeze/sid > APT prefers natty-updates > APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.38-10-generic (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 > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#450693: metacity: Desktop randomly hangs on mouse input
Yup, upgrading fixed it. Thanks for the quick reply! On Fri, 2007-11-09 at 21:24 +0100, Josselin Mouette wrote: > Hi, > > Le vendredi 09 novembre 2007 à 01:35 -0800, Tristan Schmelcher a écrit : > > Package: metacity > > Version: 1:2.14.5-4 > > > Versions of packages metacity depends on: > > ii libgtk2.0-0 2.12.1-1 The GTK+ graphical user > > interface > > This is a known issue; metacity < 2.19.1 locks up with GTK+ 2.12. > Upgrading metacity should be enough to fix your issue, then. > > I'll add a conflict to prevent such breakage to occur. > > Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450693: metacity: Desktop randomly hangs on mouse input
Package: metacity
Version: 1:2.14.5-4
Severity: important
Within the last month or so, my desktop has started regularly hanging
when I click on window buttons such as the minimize button or close
("X") button. The cursor still moves, but thereafter both mouse clicks
and keyboard input are ignored. Position-sensitive behaviours still
function, such as icons that highlight when you move over them or that
pop-up descriptions, but if I click a second time anywhere on the
screen
while in this state then even that stops working.
Typing and clicking on things within applications does not trigger this
problem. Switching to a terminal with Ctrl+Alt+Fn and killing metacity
(which restarts) clears the condition.
-- System Information:
Debian Release: lenny/sid
APT prefers stable
APT policy: (1001, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-2-amd64 (SMP w/2 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 metacity depends on:
ii libatk1.0-0 1.20.0-1 The ATK accessibility
toolkit
ii libc6 2.6.1-1 GNU C Library: Shared
libraries
ii libgconf2-4 2.20.0-1 GNOME configuration
database syste
ii libglib2.0-02.14.1-5 The GLib library of C
routines
ii libgtk2.0-0 2.12.1-1 The GTK+ graphical user
interface
ii libice6 2:1.0.4-1X11 Inter-Client Exchange
library
ii libmetacity01:2.14.5-4 library of lightweight GTK2
based
ii libpango1.0-0 1.18.3-1 Layout and rendering of
internatio
ii libsm6 2:1.0.3-1+b1 X11 Session Management
library
ii libstartup-notification00.9-1library for program launch
feedbac
ii libx11-62:1.0.3-7X11 client-side library
ii libxcursor1 1:1.1.9-1X cursor management library
ii libxext61:1.0.3-2X11 miscellaneous extension
librar
ii libxinerama11:1.0.2-1X11 Xinerama extension
library
ii libxrandr2 2:1.2.2-1X11 RandR extension library
ii libxrender1 1:0.9.4-1X Rendering Extension
client libra
ii metacity-common 1:2.14.5-4 Shared files of lightweight
GTK2 b
metacity recommends no packages.
-- no debconf information
Bug#434872: Kernel related, working now
Negative; still happening to me on 2.6.22-2-amd64. On Sun, 2007-14-10 at 15:35 +0200, Luca Bruno wrote: > Hi, > On my machine, this bug seems to be gone after a kernel upgrade. > Now, with a 2.6.22-2-686, wodim is working fine (at least here). > All kernel versions refers to the prepacked ones shipped in sid. > Actually: > iilinux-image-2.6.22-2-686 2.6.22-4 > > Cheers, Luca >
Bug#427299: Different behaviour in 0.6.5-1
I have upgraded to 0.6.5-1 and tested, and the behaviour has changed, but for the worse. When switching networks, NM no longer permanently shuts down the interface (and thus there is no need for my keep-up.sh work-around). However, it only occasionally will successfully connect to the new network. The rest of the time it silently fails and re-connects to the previous one after about the same amount of time that it would normally take to switch. In precisely the failed cases, it prints an error to the syslog: NetworkManager: Error opening supplicant global control interface. NetworkManager: real_act_stage2_config(): Activation (eth2/wireless): couldn't connect to the supplicant. The full output from a failed switching attempt and a successful switching attempt is attached. For both, I was attempting to switch from 'OpenWrt2' to 'Bridge' (formerly OpenWrt). My kernel is now 2.6.22-1-amd64. I'm going to downgrade to version 0.6.4-6 now, since at least there I had a work-around for this bug. Let me know if you'd like me to get you additional info. Sep 10 13:50:20 tinygod3 last message repeated 6 times Sep 10 13:50:23 tinygod3 NetworkManager: [1189457423.554579] nm_device_802_11_wireless_get_activation_ap(): Forcing AP 'Bridge' Sep 10 13:50:23 tinygod3 NetworkManager: User Switch: /org/freedesktop/NetworkManager/Devices/eth2 / Bridge Sep 10 13:50:23 tinygod3 NetworkManager: Deactivating device eth2. Sep 10 13:50:23 tinygod3 dhclient: There is already a pid file /var/run/dhclient.eth2.pid with pid 16222 Sep 10 13:50:23 tinygod3 dhclient: killed old client process, removed PID file Sep 10 13:50:23 tinygod3 dhclient: DHCPRELEASE on eth2 to 192.168.3.1 port 67 Sep 10 13:50:23 tinygod3 avahi-daemon[4798]: Withdrawing address record for 192.168.3.108 on eth2. Sep 10 13:50:23 tinygod3 avahi-daemon[4798]: Leaving mDNS multicast group on interface eth2.IPv4 with address 192.168.3.108. Sep 10 13:50:23 tinygod3 avahi-daemon[4798]: Interface eth2.IPv4 no longer relevant for mDNS. Sep 10 13:50:24 tinygod3 avahi-daemon[4798]: Withdrawing address record for fe80::218:deff:fe3d:57a2 on eth2. Sep 10 13:50:24 tinygod3 NetworkManager: Device eth2 activation scheduled... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) started... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 1 of 5 (Device Prepare) scheduled... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 1 of 5 (Device Prepare) started... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 2 of 5 (Device Configure) scheduled... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 1 of 5 (Device Prepare) complete. Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 2 of 5 (Device Configure) starting... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2/wireless): access point 'Bridge' is encrypted, but NO valid key exists. New key needed. Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) New wireless user key requested for network 'Bridge'. Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 2 of 5 (Device Configure) complete. Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) New wireless user key for network 'Bridge' received. Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 1 of 5 (Device Prepare) scheduled... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 1 of 5 (Device Prepare) started... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 2 of 5 (Device Configure) scheduled... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 1 of 5 (Device Prepare) complete. Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2) Stage 2 of 5 (Device Configure) starting... Sep 10 13:50:24 tinygod3 NetworkManager: Activation (eth2/wireless): access point 'Bridge' is encrypted, and a key exists. No new key needed. Sep 10 13:50:25 tinygod3 kernel: bridge-eth2: disabling the bridge Sep 10 13:50:25 tinygod3 kernel: bridge-eth2: down Sep 10 13:50:26 tinygod3 NetworkManager: Error getting killswitch power: org.freedesktop.Hal.Device.KillSwitch.NotSupported - Access type not supported Sep 10 13:50:27 tinygod3 NetworkManager: Error opening supplicant global control interface. Sep 10 13:50:27 tinygod3 NetworkManager: real_act_stage2_config(): Activation (eth2/wireless): couldn't connect to the supplicant. Sep 10 13:50:27 tinygod3 NetworkManager: Activation (eth2) failure scheduled... Sep 10 13:50:27 tinygod3 NetworkManager: Activation (eth2) Stage 2 of 5 (Device Configure) complete. Sep 10 13:50:27 tinygod3 NetworkManager: Activation (eth2) failed for access point (Bridge) Sep 10 13:50:27 tinygod3 NetworkManager: Activation (eth2) failed. Sep 10 13:50:27 tinygod3 NetworkManager: Deactivating device eth2. Sep 10 13:50:27 tinygod3 NetworkManager: SWITCH: no current connection, found better con
Bug#434872: Confirmed
Occurs for me too on both 2.6.18-5-amd64 and 2.6.22-1-amd64 with same package version. It does not occur with package version 9:1.1.2-1. I previously opened a bug with GnomeBaker about the freeze that this causes (see https://sourceforge.net/tracker/?func=detail&atid=708499&aid=1781535&group_id=127397), but I have marked it as invalid now since this is definitely a wodim problem. I see that this report is over a month old. Is anyone investigating this?
Bug#377423: Similar problem
I have also experienced this problem on 2.6.18 through 2.6.22 (amd64). I have an internal SATA drive with my Debian installation on it and an external eSATA drive with documents and such. The eSATA drive was incorrectly chosen as /dev/sda on approximately 75% of boots, which resulted in the kernel failing to find "init". See the bug that I opened at kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=8935 I have used Christian's recommended workaround, but it would be nice for it to have not been necessary. As the kernel developer that answered the above bug said, the problem is that Debian's initrd has indeterminate module loading order: ata_piix is sometimes loaded before ahci, and sometimes the opposite. If it is feasible to _automatically_ constrain the module loading order so that this does not happen, then it would be desirable to do that. Failing that, though, I support Christian's suggestion to include the options he mentioned in partman, with the default being uuid like in Ubuntu.
Bug#428640: xserver-xorg-core: Loading of certain drivers is broken
Package: xserver-xorg-core Version: 2:1.3.0.0.dfsg-6 Severity: important I just upgraded my Lenny system and found that the X server was broken. It fails to start, complaining that the nvidia driver module does not exist, which is bogus: [EMAIL PROTECTED]:~$ ls -al /usr/lib/xorg/modules/drivers/ total 1452 drwxr-xr-x 2 root root4096 2007-06-12 22:17 . drwxr-xr-x 8 root root4096 2007-06-12 23:24 .. -rw-r--r-- 1 root root 1473248 2007-01-04 20:37 nvidia_drv.o See the Xorg.0.log that reportbug included for the actual error. I have straced the Xorg binary (compressed strace log attached) and the problem seems to be due to a change in driver module loading behaviour. In both 1.3.0.0.dfsg-6 and the 1.1.1-21 in stable, Xorg stat()s the driver module paths to check that they exist. However, in 1.3.0.0.dfsg-6, it does not specify the full path; it just gives the filename. And it doesn't chdir() first. It does however _open_ the right directory first, which suggests to me that the author may have meant to use fstatat(2). As written it does not though, so every stat() for a driver module fails. For all my other drivers (which, I might note, are all from xserver-xorg-* packages), it regardless seems to open the correct driver module path thereafter. However, for the nvidia driver it doesn't try and instead reports that the module does not exist. I'm not sure what causes that difference. Perhaps because it is third-party? In any event, it appears that there will be a certain class of drivers that Xorg will be unable to load. -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /etc/X11/X target does not match checksum in /var/lib/x11/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 13 2007-01-07 11:48 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1904064 2007-06-01 07:24 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0298 (rev a1) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 6030 2007-06-12 22:00 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 1.0 ([EMAIL PROTECTED]) Sun Mar 19 06:25:19 UTC 2006 # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen 0" Screen 1 "Screen 1" RightOf "Screen 0" #Option "Xinerama" "true" InputDevice"Generic Keyboard" InputDevice"Configured Mouse" InputDevice"Synaptics Touchpad" EndSection Section "Files" # path to defoma fonts FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/X11R6/lib/X11/fonts/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/X11R6/lib/X11/fonts/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/X11R6/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/X11R6/lib/X11/fonts/75dpi" FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load "i2c" Load "bitmap" Load "ddc" Load "extmod" Load "freetype" Load "glx" Load "int10" Load "vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" Option "XkbVariant" "dvorak" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" Option "Protocol" "Im
Bug#427299: [Pkg-utopia-maintainers] Bug#427299: Automated work-around
No joy on either account. /etc/network/interfaces: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback ps -ef | grep wpa: root 21719 1 0 15:32 ?00:00:00 /sbin/wpa_supplicant -dd -g /var/run/wpa_supplicant-global tristan 22023 12861 0 15:33 pts/000:00:00 grep wpa If I disable networking with nm-applet, that single wpa_supplicant process disappears, so its definitely the NM one. I'm not too surprised that you can't reproduce this--it has the smell of a hardware-dependent bug. Perhaps I should strace the NM processes? On Tue, 2007-12-06 at 23:13 +0200, Michael Biebl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tristan Schmelcher wrote: > > First of all, I should mention that I have tested version 0.6.4-8 and > > the behaviour is no different. > > > > Now, for other users that are having this problem, I have written a > > simple shell script that automates my work-around. It is attached. You > > can run it from a shell as follows: > > > > sudo keep-up.sh ethX > > > > where ethX is the wireless interface that NetworkManager keeps > > mistakenly shutting down. > > > > The script simply checks every 5 seconds to see if the interface is > > down, and if so then it brings it up. If you want to run it > > automatically on boot, then put it in /usr/local/sbin add this line > > to /etc/rc.local: > > > > /usr/local/sbin/keep-up.sh ethX & > > Unfortunately I can't reproduce your problem. What does your > /etc/network/interfaces look like? Do you perhaps have another instance of > wpasupplicant running which interferes with the one started by NM? > > Cheers, > Michael > - -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGbwyTh7PER70FhVQRAuofAJ9v1NZYfiB7OkPt6l+nVPmH2Evi+ACdHJ1c > iIWjZv4mYzcp8HXJ7O8IG2I= > =Y/Yk > -END PGP SIGNATURE-
Bug#427299: Automated work-around
First of all, I should mention that I have tested version 0.6.4-8 and the behaviour is no different. Now, for other users that are having this problem, I have written a simple shell script that automates my work-around. It is attached. You can run it from a shell as follows: sudo keep-up.sh ethX where ethX is the wireless interface that NetworkManager keeps mistakenly shutting down. The script simply checks every 5 seconds to see if the interface is down, and if so then it brings it up. If you want to run it automatically on boot, then put it in /usr/local/sbin add this line to /etc/rc.local: /usr/local/sbin/keep-up.sh ethX & Hopefully this will only be temporary. keep-up.sh Description: application/shellscript
Bug#425562: Ditto
I too can confirm this bug. Please incorporate the patch soon. The offending package version is already in testing.
Bug#411012: Here, here!
I can confirm this. I am running Debian unstable and I did what James did (downloaded the compiz-gtk .deb from experimental, unpacked it into a directory and reconstructed the DEBIAN subdirectory, removed the "Conflicts" line from the control file, remade it with dpkg-deb, and installed with dpkg) and it is working fine. [EMAIL PROTECTED]:~$ apt-show-versions compiz compiz/experimental uptodate 0.3.6-1 [EMAIL PROTECTED]:~$ apt-show-versions compiz-core compiz-core/experimental uptodate 0.3.6-1 [EMAIL PROTECTED]:~$ apt-show-versions compiz-gtk compiz-gtk/experimental uptodate 0.3.6-1 [EMAIL PROTECTED]:~$ apt-show-versions compiz-gnome compiz-gnome/experimental uptodate 0.3.6-1 [EMAIL PROTECTED]:~$ apt-show-versions compiz-plugins compiz-plugins/experimental uptodate 0.3.6-1 [EMAIL PROTECTED]:~$ apt-show-versions metacity metacity/unstable uptodate 1:2.18.2-3 [EMAIL PROTECTED]:~$ apt-show-versions metacity-common metacity-common/unstable uptodate 1:2.18.2-3 [EMAIL PROTECTED]:~$ apt-show-versions libmetacity0 libmetacity0/unstable uptodate 1:2.18.2-3 [EMAIL PROTECTED]:~$ uname -a Linux 2.6.18-4-amd64 #1 SMP Wed Apr 18 17:35:10 UTC 2007 x86_64 GNU/Linux (You'll have to take my word for it that those things are also all actually running :) .) Another thing. This should be fixed and compiz 0.3.6 moved from experimental to unstable sometime in the not-too-distant future, because currently the (legitimate, I assume) conflict between compiz 0.2.2 and libmetacity0 >= 2.15.21 prevents anyone from having both compiz and metacity up-to-date in unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408203: Xen kernel has no /dev/snapshot support
Package: linux-image-2.6.18-3-xen-amd64 Version: 2.6.18-7 The packaged amd64 Xen kernel (and perhaps others) in etch does not have the /dev/snapshot node or underlying char device, and so is unable to do userspace suspend. (The non-Xen kernel includes it.) Observe: (in /var/log/hibernate.log) Starting suspend at Tue Jan 23 21:19:49 EST 2007 hibernate: [00] Executing MiscLaunchAuxFunc1 ... hibernate: [01] Executing CheckLastResume ... hibernate: [01] Executing CheckRunlevel ... hibernate: [01] Executing LockFileGet ... hibernate: [01] Executing MiscLaunchAuxFunc2 ... hibernate: [01] Executing NewKernelFileCheck ... hibernate: [10] Executing EnsureUSuspendCapable ... /dev/snapshot device not found. hibernate: EnsureUSuspendCapable refuses to let us continue. hibernate: Aborting. hibernate: [01] Executing NoteLastResume ... hibernate: [01] Executing MiscLaunchAuxFunc3 ... hibernate: [01] Executing LockFilePut ... Resumed at Tue Jan 23 21:19:50 EST 2007 Checking manually reveals this is indeed the problem: [USER AND HOSTNAME REMOVED]:~$ uname -a Linux [HOSTNAME REMOVED] 2.6.18-3-xen-amd64 #1 SMP Mon Dec 4 17:56:42 CET 2006 x86_64 GNU/Linux [USER AND HOSTNAME REMOVED]:~$ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 13 2007-01-07 13:23 /lib/libc.so.6 -> libc-2.3.6.so [USER AND HOSTNAME REMOVED]:~$ ls -al /dev/snapshot ls: /dev/snapshot: No such file or directory [USER AND HOSTNAME REMOVED]:~$ sudo mknod /dev/snapshot c 10 231 [USER AND HOSTNAME REMOVED]:~$ sudo head -c 1 /dev/snapshot head: cannot open `/dev/snapshot' for reading: No such device The expected behaviour is of course that the Xen kernel includes /dev/snapshot support and that userspace suspend works. It should be noted that when this same system boots 2.6.18-3-amd64 instead, suspend works as expected. This system is a Dell XPS M1710 laptop with a 2GHz Intel Core 2 Duo processor. (Other hardware details are presumably not pertinent.) The suggested fix is to rebuild and repackage the Xen kernels with /dev/snapshot support turned on, assuming the Xen kernels do currently have that option. If not, then open a corresponding bug in the Xen project's tracker. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
