Bug#523824: gtk-qt-engine prevents iceweasel from closing properly
Package: gtk-qt-engine Version: 1:1.1+svn5-4+b1 Severity: normal Just writing to support Mike's finding (see above and bug #492059). After running: "apt-get purge gtk-qt-engine", I no longer had any trouble with "firefox-bin" or "xulrunner-stub" continuing to run after I had closed the browser. Thanks, - Eric -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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 Versions of packages gtk-qt-engine depends on: ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1 FreeType 2 font engine, shared lib ii libgcc11:4.4.5-8 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libpango1.0-0 1.28.3-1+squeeze1 Layout and rendering of internatio ii libqtcore4 4:4.6.3-4 Qt 4 core module ii libqtgui4 4:4.6.3-4 Qt 4 GUI module ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-4 X11 client-side library Versions of packages gtk-qt-engine recommends: pn kde-config-gtk-style (no description available) gtk-qt-engine 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#492059: one solution = disabling KDE/Qt styles for GTK applications
Package: iceweasel
Severity: normal
Mike's prediction was correct. Disabling KDE/Qt styles for GTK applications
solves the problem (for me, anyway).
After running: "apt-get purge gtk-qt-engine", I no longer had any trouble with
"firefox-bin" or "xulrunner-stub" continuing to run after I had closed the
browser.
Thanks,
- Eric
-- Package-specific info:
-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Status: enabled
Name: Default
Location: /usr/lib/iceweasel/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: Duplicate This Tab
Location: ${PROFILE_EXTENSIONS}/duplicate-this-...@mozilla.org
Status: enabled
Name: NoScript
Location: ${PROFILE_EXTENSIONS}/{73a6fe31-595d-460b-a920-fcc0f8843232}
Status: enabled
Name: Noia 2.0 (eXtreme)
Location: ${PROFILE_EXTENSIONS}/{9f08cb5a-76b1-4bcf-aff9-90e1a5d60b1e}
Status: enabled
Name: Noia 2.0 eXtreme OPT
Location: ${PROFILE_EXTENSIONS}/noia2_opt...@kk.noia
Status: enabled
Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}
Status: enabled
Name: Undo Closed Tabs Button
Location: ${PROFILE_EXTENSIONS}/undoclosedtabsbut...@supernova00.biz
Status: enabled
-- Plugins information
Name: DivX Browser Plug-In
Location: /usr/lib/mozilla/plugins/mplayerplug-in-dvx.so
Package: mozilla-mplayer
Status: enabled
Name: Java(TM) Plug-in 1.6.0_22
Location: /usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib/amd64/libnpjp2.so
Package: sun-java6-bin
Status: enabled
Name: QuickTime Plug-in 7.4.5
Location: /usr/lib/mozilla/plugins/mplayerplug-in-qt.so
Package: mozilla-mplayer
Status: enabled
Name: RealPlayer 9
Location: /usr/lib/mozilla/plugins/mplayerplug-in-rm.so
Package: mozilla-mplayer
Status: enabled
Name: Shockwave Flash
Location: /usr/lib/gnash/libgnashplugin.so
Package: browser-plugin-gnash
Status: enabled
Name: Skype Buttons for Kopete
Location: /usr/lib/mozilla/plugins/skypebuttons.so
Package: kopete
Status: enabled
Name: Windows Media Player Plug-in
Location: /usr/lib/mozilla/plugins/mplayerplug-in-wmp.so
Package: mozilla-mplayer
Status: enabled
Name: mplayerplug-in 3.55
Location: /usr/lib/mozilla/plugins/mplayerplug-in.so
Package: mozilla-mplayer
Status: enabled
-- Addons package information
ii browser-plugin 0.8.8-9GNU Shockwave Flash (SWF) player - Plugin fo
ii iceweasel 3.5.16-4 Web browser based on Firefox
ii kopete 4:4.4.5-2 instant messaging and chat application
ii mozilla-mplaye 3.55-1.1 MPlayer-Plugin for Mozilla
ii sun-java6-bin 6.22-1 Sun Java(TM) Runtime Environment (JRE) 6 (ar
-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-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
Versions of packages iceweasel depends on:
ii debianutils 3.4Miscellaneous utilities specific t
ii fontconfig2.8.0-2.1 generic font configuration library
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libglib2.0-0 2.24.2-1 The GLib library of C routines
ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface
ii libnspr4-0d 4.8.6-1NetScape Portable Runtime Library
ii libstdc++64.4.5-8The GNU Standard C++ Library v3
ii procps1:3.2.8-9 /proc file system utilities
ii xulrunner-1.9.1 1.9.1.16-4 XUL + XPCOM application runner
iceweasel recommends no packages.
Versions of packages iceweasel suggests:
ii libgssapi-krb5-21.8.3+dfsg-4 MIT Kerberos runtime libraries - k
ii libkrb531.8.3+dfsg-4 transitional package for MIT Kerbe
pn mozplugger (no description available)
pn ttf-lyx | latex-xft-fonts (no description available)
pn ttf-mathematica4.1 (no description available)
pn xfonts-mathml (no description available)
pn xprint (no description available)
Versions of packages xulrunner-1.9.1 depends on:
ii libasound2 1.0.23-2.1shared library for ALSA applicatio
ii libatk1.0-01.30.0-1 The ATK accessibility toolkit
ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra
ii libdbus-1-31.2.24-4 simple interprocess messaging syst
ii libfontconfig1 2.8.0-2.1 generic font configuration library
ii libfreetype6 2.4.2-2.1 FreeType 2 font engine, shared lib
ii libgcc11:4.4.5-8 GCC support library
ii
Bug#501339: automounting vfat as utf8
Hi Sune, I'm writing in regard to the very old -- but very important -- bug about case-sensitive automounting of FAT-formatted devices. My main purpose in writing is to attract a little attention to this bug. A second purpose is to describe a workaround that spares the life of users' USB flash-drives. I've noticed that placing the following line in my /etc/fstab file: /dev/sda1 /media/sda1 autorw,user,noauto,exec 0 0 and running: mkdir /media/sda1 mounts a FAT-formatted USB flash drive case-insensitive: [ Fri 11-Sep-2009 11.29 eric ] ~ $ mount /dev/sda1 [ Fri 11-Sep-2009 11.30 eric ] ~ $ mount ... /dev/sda1 on /media/sda1 type vfat (rw,nosuid,nodev,user=eric) [ Fri 11-Sep-2009 11.30 eric ] ~ $ [ Fri 11-Sep-2009 11.30 eric ] ~ $ cd /media/sda1 [ Fri 11-Sep-2009 11.30 eric ] sda1 $ [ Fri 11-Sep-2009 11.30 eric ] sda1 $ echo hello > hello.txt [ Fri 11-Sep-2009 11.30 eric ] sda1 $ echo hello > Hello.txt bash: Hello.txt: File exists [ Fri 11-Sep-2009 11.30 eric ] sda1 $ [ Fri 11-Sep-2009 11.30 eric ] sda1 $ ls -l total 12 -rwxr-xr-x 1 eric eric6 2009-09-11 11:30 hello.txt ... [ Fri 11-Sep-2009 11.31 eric ] sda1 $ In regard to the KDE question (i.e. automounting a USB drive upon insertion) ... The /etc/fstab line above does not prevent automounting. The difference is that the /etc/fstab line above will mount the device case insensitive. Have a great weekend, - Eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517581: pdfedit: "Set page transformation matrix" across a range of pages does not work properly
Package: pdfedit Version: 0.4.2-3 Severity: normal Tags: patch One of the great new features in PDFEdit 0.4.2 is its ability to apply "Edit page metrics" and "Set page transformation matrix" across a range of pages. When I attempt to set the transformation matrix on all (or a large share) of the pages of a 30 page document however, PDFEdit sets the transformation matrix of one or two pages (sometimes three pages) and then stops. I notified the developers of PDFedit about this bug (and a couple of other bugs). Developer Michal Hocko produced the attached set of patches, which squash the bugs. He also encouraged me to send the patches to you. This bug report corresponds to PDFedit bug #291.[1] Thank you for your attention to this issue, - Eric Doviak ps: I attempted to report this bug yesterday, but it doesn't appear to have gone through. Apologies if you receive a duplicate bug report. [1] http://pdfedit.petricek.net/bt/view.php?id=291 -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) 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 pdfedit depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc11:4.3.2-1.1 GCC support library ii libqt3-mt 3:3.3.8b-5+b1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime pdfedit recommends no packages. pdfedit suggests no packages. -- no debconf information pdfedit-patches.tar.gz Description: GNU Zip compressed data
Bug#517582: pdfedit: Why are my pages disappearing?
Package: pdfedit Version: 0.4.2-3 Severity: normal Tags: patch While trying to work with a pair of PDF files, some of my pages disappeared. This occurred when using the "Edit page metrics" utility and also when using the "Set page transformation matrix" utility. I notified the developers of PDFedit about this bug (and a couple of other bugs). Developer Michal Hocko produced the attached set of patches, which squash the bugs. He also encouraged me to send the patches to you. This bug report corresponds to PDFedit bug #295.[1] Thank you for your attention to this issue, - Eric Doviak ps: I attempted to report this bug yesterday, but it doesn't appear to have gone through. Apologies if you receive a duplicate bug report. [1] http://pdfedit.petricek.net/bt/view.php?id=295 -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) 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 pdfedit depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc11:4.3.2-1.1 GCC support library ii libqt3-mt 3:3.3.8b-5+b1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime pdfedit recommends no packages. pdfedit suggests no packages. -- no debconf information pdfedit-patches.tar.gz Description: GNU Zip compressed data
Bug#517580: pdfedit: "Edit page metrics" should transform both CropBox and MediaBox
Package: pdfedit Version: 0.4.2-3 Severity: normal Tags: patch Suppose that you want to enlarge the page of a PDF file from 5 by 8 inches to 8.5 by 11 inches. To do that in PDFedit 0.4.2, you would use "Edit page metrics" (to enlarge the page) and "Set page transformation matrix" (to enlarge the text). In practice, it appears to work, but when you open the PDF file outside of PDFedit, the text is enlarged but the page is not. After much experimentation, I discovered that the error occurs because the changes to the MediaBox are not applied to the CropBox. (To make the necessary fixes, you have to open the object tree, expand "Pages," expand the page numbers, expand "Dictionary" and copy the values from "MediaBox" to "CropBox"). I notified the developers of PDFedit about this bug (and a couple of other bugs). Developer Michal Hocko produced the attached set of patches, which squash the bugs. He also encouraged me to send the patches to you. This bug report corresponds to PDFedit bug #290.[1] Thank you for your attention to this issue, - Eric Doviak ps: I attempted to report this bug yesterday, but it doesn't appear to have gone through. Apologies if you receive a duplicate bug report. [1] http://pdfedit.petricek.net/bt/view.php?id=290 -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) 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 pdfedit depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc11:4.3.2-1.1 GCC support library ii libqt3-mt 3:3.3.8b-5+b1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime pdfedit recommends no packages. pdfedit suggests no packages. -- no debconf information pdfedit-patches.tar.gz Description: GNU Zip compressed data
Bug#486400: splashy does or doesn't work with hibernation ??
Hi Luis, Tim and Yves-Alexis, I received the notice that the Splashy hibernate bug has been closed, but I promised to follow up, so I'm writing to follow up. I just reinstalled and tested Splashy on my Dell Latitude C510. It works fine now. Because I'm curious ... What change was made that corrected Splashy's behavior? Thanks for your time and attention to this issue and -- most importantly -- thanks for taking the time to add a touch of beauty to my Debian machines. - Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486400: splashy does or doesn't work with hibernation ??
Hi Yves-Alexis, I am the person who originally submitted the bug report on Splashy's troubles with hibernation. I encountered the problem a few months ago on a Dell Latitude. Shortly thereafter, several other people wrote in to say that they were experiencing similar difficulties. At the moment, I am away from home working on a (recently acquired) Compaq Evo N410c. I just installed Splashy on this machine and it works perfectly with kernels 2.6.25 and 2.6.26. To be more precise, I had no difficulty resuming after calling /usr/sbin/hibernate nor did I have any difficulty resuming after calling /usr/sbin/s2disk When I return home tomorrow, I will reinstall and test Splashy on my Dell Latitude, let you know if it works and provide you with some feedback. Hopefully, everything will work and you will get some cookies from the Bug Sprint! Cheers, - Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501951: klaptopdaemon: Bring back KLaptop !!! ... Yes! It is possible !!!
Package: klaptopdaemon Version: 4:3.5.9-1 Severity: wishlist JOY !!! Oh, joy! I just noticed that I don't have to recompile my kernel to use KLaptop on Debian Lenny! Check out the following lines in /boot/config-2.6.26-1-686 CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y KLaptop works with the latest stock Debian kernel! And it works a heck of a lot better than KPowersave! "So long KPowersave! I never liked the way you made me restart my wireless drivers upon resume from hibernation! Our relationship is over! I'm getting back with my old girl, KLaptop. She treats me much better than you ever did!" Please bring this joy to others! Please bring KLaptop back to Debian Lenny! - Eric -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) 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 klaptopdaemon depends on: ii kdelibs4c2a4:3.5.9.dfsg.1-6 core libraries and binaries for al ii libc6 2.7-13GNU C Library: Shared libraries ii libgcc11:4.3.2-1 GCC support library ii libqt3-mt 3:3.3.8b-5Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime klaptopdaemon recommends no packages. Versions of packages klaptopdaemon suggests: ii khelpcente 4:4.0.0.really.3.5.9.dfsg.1-5 help center for KDE -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491300: desktop selection doesn't install desktop
Just a note to confirm this bug. I ran into it in the Debian Lenny installer KDE CD 1 weekly build 21 July 2008. Looking forward to the fix in the official builds, - Eric
Bug#452689: KPowersave and KNetworkManager
Hello, Let me begin by thanking Ana Guerrero and the rest of Debian's KDE team for their prompt response to the problems caused when a very stubborn Debian kernel maintainer disabled support for /proc/acpi.[1] Thank you for taking the time to provide people like me with a great desktop! == When I recently upgraded my Lenny system and brought in KPowersave, I had no trouble suspending or resuming. However, KNetworkManager was unable to reinitialize my wireless connection (Atheros with proprietary Madwifi drivers). Specifically, KNetworkManager would show me that it had detected 5 or 6 networks, but it was unable to connect to any of them. So I ran "iwlist scan" and here's what I got: [ Wed 23-Jul-2008 23.42 root ] eric # iwlist scan loInterface doesn't support scanning. eth0 Interface doesn't support scanning. wifi0 Interface doesn't support scanning. ath1 No scan results [ Wed 23-Jul-2008 23.42 root ] eric # [ Wed 23-Jul-2008 23.42 root ] eric # This bug has been reported [2] and rumor has it that this is a well-known issue [3]. (I cannot say that I knew about it however!). I can unequivocally state that KPowersave caused the problem. I downgraded to kernel 2.6.24 and reverted to KLaptop 3.5.9-1 and the problem vanished. Is their a workaround for this problem? or do we have to suffer in silence? Thanks, - Eric
Bug#490686: KLaptop, kernel 2.6.25 and Bug #490686
Thanks Ana. I had seen the first link you sent, but it doesn't explain WHY support for /proc/acpi has been disabled. I missed the second link you sent. Next time, I'll remember to check the user mailing lists before asking questions! Thanks again, - Eric Ana Guerrero wrote: > On Tue, Jul 15, 2008 at 11:59:08PM -0400, Eric Doviak wrote: >> 1.) why support for /proc/acpi has been disabled in the 2.6.25 kernel, > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463253 > >> 2.) if the KLaptop daemon (3.5.9) will be ported to the new sysfs >> interface and > > I do not think so. > >> 3.) if there's anything an end-user (like me) can do to make sure KDE >> has functional power management when it ships with Debian Lenny next >> September. >> > > Read http://lists.debian.org/debian-kde/2008/07/msg00017.html I am still > waiting for some feedback, but it looks like klaptopdaemon will be removed and > kpowersave recommended as a replacement in the next couple of days. > > > Ana >
Bug#490686: KLaptop, kernel 2.6.25 and Bug #490686
Hi, I'm writing to ask: 1.) why support for /proc/acpi has been disabled in the 2.6.25 kernel, 2.) if the KLaptop daemon (3.5.9) will be ported to the new sysfs interface and 3.) if there's anything an end-user (like me) can do to make sure KDE has functional power management when it ships with Debian Lenny next September. Question #1 == I'm having a very difficult time understanding why support for /proc/acpi has been disabled. In the past, HAL would detect two batteries if both the SYSFS and PROCFS power options were set in the kernel [1], but that is no longer a problem [2]. I know that /proc/acpi is deprecated in favor of the sysfs interface [3][4], but does that mean /proc/acpi should never be used? Or does that simply mean that the sysfs interface is better? If the former, then what is so bad about /proc/acpi? What dangers does it pose? If the latter, then why not ship the kernel for Debian Lenny with support for both interfaces? Why break packages unnecessarily? Question #2 == Given the fact that KLaptop daemon 3.5.9 does not currently work with the sysfs interface, the 2.6.25 kernel -- in which support for /proc/acpi is disabled -- breaks power management in KDE. Will this be fixed in time for Lenny's release or will KDE ship in a broken state? KPowersave (the KDE alternative to KLaptop) does work with the sysfs interface. Will this be shipped as part of the default KDE desktop in Debian Lenny? (Please say no. I just need a battery monitor and automatic hibernation. I don't feel like sifting through thousands of options buried beneath hundreds of tabs in four different profiles just to accomplish those two tasks). Question #3 == Quite frankly, this issue doesn't affect me. I know how to compile a kernel and I know how to configure KPowersave, but I'd like to recommend Debian with KDE to people who don't know how to do these things, so if there's anything I can do to help, please let me know. I'm not a computer scientist -- so go easy on me -- but if I can help, please let me know. Thanks, - Eric References: [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00976.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463253#33 [3] http://cateee.net/lkddb/web-lkddb/ACPI_PROCFS_POWER.html [4] http://cateee.net/lkddb/web-lkddb/ACPI_SYSFS_POWER.html
Bug#490686: linux-image-2.6.25-2-686 does not work with KLaptop
Thank you for taking the time to answer my report. Just to follow up ... It appears that CONFIG_ACPI_PROCFS_POWER was set in the 2.6.24 kernel: [ Sun 13-Jul-2008 20.45 eric ] ~ $ cat /boot/config-2.6.24-1-686 | grep CONFIG_ACPI_PROCFS_POWER CONFIG_ACPI_PROCFS_POWER=y [ Sun 13-Jul-2008 20.45 eric ] ~ $ cat /boot/config-2.6.25-2-686 | grep CONFIG_ACPI_PROCFS_POWER # CONFIG_ACPI_PROCFS_POWER is not set
Bug#490686: linux-image-2.6.25-2-686 does not work with KLaptop
Package: linux-image-2.6.25-2-686 Version: 2.6.25-6 Severity: important linux-image-2.6.25-2-686 does not work with KLaptop. I'm not sure why. It's always worked with the other stock Debian kernels and ACPI does work with this kernel, but when I run the "klaptop_check" command, KLaptop fails to start. When I open the "Low Battery Warning" and "Low Battery Critical" tabs of the "Laptop Battery" page in KDE's Control Center, I see the following message: "Your computer seems to have a partial ACPI installation. ACPI was probably enabled, but some of the sub-options were not - you need to enable at least 'AC Adaptor' and 'Control Method Battery' and then rebuild your kernel." I looked through the "/boot/config-2.6.24-1-686" and "/boot/config-2.6.25-2-686" files to find those options, but I couldn't find them in either file. (In other words, I cannot find those options in the config file of the kernel that works with KLaptop, nor can I find them in the config file of the kernel that doesn't work with KLaptop). Just to confirm that ACPI works: [ Sun 13-Jul-2008 12.58 eric ] ~ $ acpi Battery 0: Discharging, 73%, 00:00:47 remaining [ Sun 13-Jul-2008 12.58 eric ] ~ $ Let me know if I can provide you with any more information or otherwise be of assistance to you. Thanks! - Eric -- Package-specific info: ** Version: Linux version 2.6.25-2-686 (Debian 2.6.25-6) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Fri Jun 27 03:23:20 UTC 2008 ** Command line: root=/dev/hda2 ro vga=791 splash laptop ** Tainted: P (1) ** Kernel log: [ 19.623768] ACPI: Power Button (CM) [PBTN] [ 19.623909] input: Sleep Button (CM) as /class/input/input6 [ 19.651847] ACPI: Sleep Button (CM) [SBTN] [ 20.534779] ACPI: PCI Interrupt :00:1f.6[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [ 20.534814] PCI: Setting latency timer of device :00:1f.6 to 64 [ 20.608082] ACPI: PCI Interrupt :00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [ 20.608122] PCI: Setting latency timer of device :00:1f.5 to 64 [ 21.363844] intel8x0_measure_ac97_clock: measured 55462 usecs [ 21.363854] intel8x0: clocking to 48000 [ 21.677330] input: Video Bus as /class/input/input7 [ 21.711943] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 22.010199] Real Time Clock Driver v1.12ac [ 22.052203] input: PC Speaker as /class/input/input8 [ 22.271957] Yenta: CardBus bridge found at :02:01.0 [1028:00e3] [ 22.271983] Yenta: Using CSCINT to route CSC interrupts to PCI [ 22.271988] Yenta: Routing CardBus interrupts to PCI [ 22.271994] Yenta TI: socket :02:01.0, mfunc 0x01261222, devctl 0x64 [ 22.504409] Yenta: ISA IRQ mask 0x0498, PCI irq 11 [ 22.504420] Socket status: 3006 [ 22.504428] pcmcia: parent PCI bridge I/O window: 0xe000 - 0x [ 22.504434] cs: IO port probe 0xe000-0x: clean. [ 22.505315] pcmcia: parent PCI bridge Memory window: 0xf400 - 0xfbff [ 22.505321] pcmcia: parent PCI bridge Memory window: 0x5000 - 0x59ff [ 22.528706] Yenta: CardBus bridge found at :02:01.1 [1028:00e3] [ 22.528730] Yenta: Using CSCINT to route CSC interrupts to PCI [ 22.528734] Yenta: Routing CardBus interrupts to PCI [ 22.528741] Yenta TI: socket :02:01.1, mfunc 0x01261222, devctl 0x64 [ 22.760439] Yenta: ISA IRQ mask 0x0498, PCI irq 11 [ 22.760449] Socket status: 3020 [ 22.760457] pcmcia: parent PCI bridge I/O window: 0xe000 - 0x [ 22.760463] cs: IO port probe 0xe000-0x: clean. [ 22.761344] pcmcia: parent PCI bridge Memory window: 0xf400 - 0xfbff [ 22.761350] pcmcia: parent PCI bridge Memory window: 0x5000 - 0x59ff [ 22.793659] parport_pc 00:0e: reported by Plug and Play ACPI [ 22.793718] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] [ 23.399977] pccard: CardBus card inserted into slot 1 [ 23.725345] Synaptics Touchpad, model: 1, fw: 5.7, id: 0x9b48b1, caps: 0x804793/0x0 [ 23.725361] serio: Synaptics pass-through port at isa0060/serio1/input0 [ 23.764506] input: SynPS/2 Synaptics TouchPad as /class/input/input9 [ 24.470755] cs: IO port probe 0x100-0x3af: clean. [ 24.471637] cs: IO port probe 0x3e0-0x4ff: clean. [ 24.472069] cs: IO port probe 0x820-0x8ff: clean. [ 24.472139] cs: IO port probe 0xc00-0xcf7: clean. [ 24.472636] cs: IO port probe 0xa00-0xaff: clean. [ 24.509502] cs: IO port probe 0x100-0x3af: clean. [ 24.510394] cs: IO port probe 0x3e0-0x4ff: clean. [ 24.510780] cs: IO port probe 0x820-0x8ff: clean. [ 24.510849] cs: IO port probe 0xc00-0xcf7: clean. [ 24.511566] cs: IO port probe 0xa00-0xaff: clean. [ 24.740253] ath_hal: module license 'Proprietary' taints kernel. [ 24.743209] ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) [ 24.792396] wlan: 0.9.4 [ 24.816146] ath_pci: 0.9.4 [ 24.816211] PCI: Enabling device :07:00.0 ( -> 0002) [ 24.816229]
Bug#486400: a hack that WORKS !!!
Yet another typo! I forgot to send this to Debian Bugs! Sorry for the double email! - Eric Luis Mondesi wrote: if you pass "splashy" then Splashy won't work. You need to pass "splash" as a kernel parameter. Is this a typo on this email or are you actually using this keyword? Back to the drawing board? Thanks for your help on this though. I'm trying to reproduce this on my own system. Whoops! The typo was in my message. The typo was NOT in my "/boot/grub/menu.lst" I was passing "vga=791 splash" and "vga=791 splash laptop" when I ran the tests. - Eric here's the relevant section of my "/boot/grub/menu.lst" title Debian GNU/Linux, kernel 2.6.24-1-686 root(hd0,1) kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/hda2 ro vga=791 splash laptop initrd /boot/initrd.img-2.6.24-1-686 title Debian GNU/Linux, kernel 2.6.24-1-686 (single-user mode) root(hd0,1) kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/hda2 ro single initrd /boot/initrd.img-2.6.24-1-686 title Debian GNU/Linux, kernel 2.6.21.7-emd root(hd0,1) kernel /boot/vmlinuz-2.6.21.7-emd root=/dev/hda2 ro vga=791 splash laptop initrd /boot/initrd.img-2.6.21.7-emd title Debian GNU/Linux, kernel 2.6.21.7-emd (single-user mode) root(hd0,1) kernel /boot/vmlinuz-2.6.21.7-emd root=/dev/hda2 ro single initrd /boot/initrd.img-2.6.21.7-emd
Bug#486400: a hack that WORKS !!!
Luis Mondesi wrote:
When $resume is not set, does Splashy start from initramfs init-top?
Why does Splashy starts "late"?
Hi Luis,
I ran some diagnostics using the hack that I sent yesterday.
Specifically, I ran "splashy_config -s kubuntusplashy" but I did NOT run
"update-initramfs -u". That enables me to see when Splashy is running
from the initial RAM disk and when it is running from the regular file
system. When I see "debian-moreblue," then I know that Splashy is
running from the initial RAM disk. When I see "kubuntusplashy," then I
know that Splashy is running from the regular file system.
Or more simply: "'Debian' is right. 'Kubuntu' is wrong." ;-)
When I pass the arguments "vga=791 splashy", I see:
* Start-up -- Debian
* Shut-down -- Kubuntu
* Hibernate -- Kubuntu
* Resume-- Debian -- and then it freezes
When I pass the arguments "vga=791 splashy laptop", I see:
* Start-up -- Kubuntu
* Shut-down -- Kubuntu
* Hibernate -- Kubuntu
* Resume-- Debian -- resumes successfully
== == == == == == == == == == == == ==
IMPLICATION #1
Those tests tell me that the line:
test $LAPTOP != "true" || if [ ! -z "${resume}" ]; then SPLASH=false ; fi
always evaluates to "SPLASH=false" because "${resume}" is never zero in
length. Then when the script reads:
test $SPLASH = "true" || exit
it exits.
When the "laptop" kernel argument is passed during start-up, Splashy
starts when the initial RAM disk quits and the regular file system takes
over. The Kubuntu splash screen at start-up confirms this.
For further confirmation, I also paid very close attention to the boot
messages that I saw during start-up. Here (more or less) are the last
lines that I saw prior to Splashy starting:
Running scripts/init-bottom
Done.
INIT version 2.86 Booting
* (Re)generating splash steps for
* rc2.d ...
* rc0.d ...
* rc6.d ...
Starting boot manager Splashy
Splashy ERROR connection refused
Splashy ERROR connection refused
I think the "connection refused" messages occur because it's trying to
connect to a running version of Splashy (but none is running, of course).
== == == == == == == == == == == == ==
IMPLICATION #2
OK, so what does this mean in terms of the "resume bug?" Why doesn't
Splashy allow my computer to resume from hibernation without my hack?
In my amateur opinion, there are two ways of finding a "real solution."
One way is to determine what "${resume}" should look like when the
system is starting-up and what it should look like when it is resuming.
Once we determine that, we can have the "init-top/splashy" script
perform the appropriate tests. My hack simply doesn't perform the
correct test. "${resume}" is always non-zero in length.
The other way is to fix the connection between the part of Splashy that
runs immediately upon boot and the part of Splashy that runs when the
resume process begins. The fact that the Debian splash screen always
appeared during resume (i.e. when I passed "vga=791 splashy" and when I
passed "vga=791 splashy laptop") indicates that this connection occurs
entirely within the initial RAM disk.
== == == == == == == == == == == == ==
That's about all I can think of. I hope this helps and I apologize if
I'm driving you nuts about this bug.
Have a great weekend,
- Eric
Bug#486400: a hack that WORKS !!!
Eric Doviak wrote:
Luis Mondesi wrote:
When $resume is not set, does Splashy start from initramfs init-top?
Why does Splashy starts "late"?
When "$resume" is not set, Splashy does not start from "init-top". It
appears to start from "init-bottom". My guess is that Splashy starts
"late" because the script is waiting for information about "$resume".
I tried adding the "case" structure from "local-premount/resume", but
I didn't have any luck.
- Eric
Just to clarify ... Simply testing this condition:
> if [ ! -z "${resume}" ]; then
> SPLASH=false
> fi
causes Splashy to start late. That's why I created the "laptop" kernel
argument.
When I tested my hack by not passing the "laptop" kernel argument,
Splashy starts from "init-top" (like it is supposed to), but I can only
start-up, shutdown and suspend. I cannot resume. The "laptop" kernel
argument fixes the "resume bug," but it causes Splashy to start late on
start-up.
- Eric
Bug#486400: a hack that WORKS !!!
Hi Luis,
After days of struggling with the "resume bug," I have finally found a
hack that fixes the problem. It's not ideal, but it squashes the bug and
it provides laptop users with a boot splash without compromising the
quality that desktop users currently enjoy.
Specifically, I started by adding the following code after line 44 of
the "/usr/share/initramfs-tools/scripts/init-top/splashy" file:
if [ ! -z "${resume}" ]; then
SPLASH=false
fi
That condition allows me to resume from hibernation, but it causes
Splashy to start rather late in the boot sequence. Specifically, it
starts when the "init-bottom" scripts are run. Adding such a condition
to Splashy would be useful to laptop users, but the late start would
degrade Splashy in the eyes of desktop users.
I see no reason why desktop users should be penalized just to make
laptop users happy, so I created another condition that only runs the
condition above if "laptop" is passed as a kernel argument. The code is
below.
By creating a "laptop" kernel argument, desktop users would continue to
see a splash screen early in the boot sequence and laptop users would
get a user-space boot splash system that works during start-up,
shutdown, suspend and resume.
It certainly isn't the ideal solution that I had in mind a few days ago
(when I thought we could provide everyone with a splash screen that
starts early in the boot sequence), but it squashes the bug and it makes
Splashy usable for laptop users. Importantly, it achieves those
objectives without degrading Splashy's performance on desktop computers.
Let me know if there's anything else I can do,
- Eric
SPLASH=false
LAPTOP=false
SINGLE=false
FBMODESET=false
for x in $(cat /proc/cmdline); do
case $x in
single)
SINGLE=true
;;
splash)
SPLASH=true
;;
laptop)
LAPTOP=true
;;
nosplash)
SPLASH=false
;;
vga=*|video=*)
FBMODESET=true
;;
esac
done
test $LAPTOP != "true" || if [ ! -z "${resume}" ]; then SPLASH=false ; fi
test $SINGLE = "false" || exit
test $SPLASH = "true" || exit
test $FBMODESET = "true" || exit
Bug#486400: [Splashy-devel] Bug#486400: Splashy works with hibernation, but ...
Just to clarify (in case my previous message was unclear) ... In the "/usr/share/initramfs-tools/scripts/init-top" file, the lines: for x in $(cat /proc/cmdline); do case $x in single) SINGLE=true ;; splash) SPLASH=true ;; nosplash) SPLASH=false ;; vga=*|video=*) FBMODESET=true ;; esac done should be immediately followed by a test to see if a resume image is available. If one is available, then "SPLASH=false" Hope this helps, - Eric
Bug#486400: [Splashy-devel] Bug#486400: Splashy works with hibernation, but ...
I think I know how to fix this bug. ... Of course, knowing how to fix
the bug and being able to fix the bug are two totally different things.
If I understand correctly ... When the "vga=791 splash" arguments are
passed to the kernel, some of the first scripts that the initial RAM
disk runs is a script that starts the framebuffer
("init-top/framebuffer") and a script that checks to see if Splashy
should start ("init-top/splashy").
Later, the initial RAM disk checks to see if there's a hibernation image
from which to resume "local-premount/{resume,uswsusp}". If it detects a
resume image, then it loads the resume image. The trouble then occurs
because the resume image also contains Splashy.
So if you could move (some of) the checks for the resume image into the
the "init-top/splashy" script and cause the "init-top/splashy" script to
exit if it detects a resume image, then:
* on a boot following a complete shutdown, the "init-top/splashy"
script would start Splashy
* on a boot following hibernation, the "init-top/splashy" script
would exit and allow the resume features to start Splashy
That would provide the best of both worlds! A userspace bootsplash that
starts early in the boot sequence and a bootsplash that is capable of
working with hibernation!
I hope this helps! Please let me know if there's anything else I can do!
Thanks,
- Eric
Bug#486400: Splashy works with hibernation, but ...
This is interesting: Splashy really does work with hibernation! I have Splashy (almost) completely configured. I left the "splash = y" line in my /etc/uswsusp.conf file and I set the "vga=791" argument -- but NOT the "splash" argument -- on the kernel line of my /boot/grub/menu.lst file. When shutting down and when starting after a complete shutdown, I obviously do not see the splash screen, but when I hibernate or when I resume from hibernation, I see the splash screen and it works rather well. I really hope you can fix this bug in time for Lenny's release and I'd like to help you if I can. I've been looking at Splashy and uswsusp's source code. I'm trying to understand it, but I don't know C, so it ain't easy. Nonetheless, if there's anything I can do to help, please let me know. Thanks, - Eric Here's my /etc/uswsusp.conf file: # /etc/uswsusp.conf(8) -- Configuration file for s2disk/s2both resume device = /dev/hda5 splash = y compress = y early writeout = y image size = 488091648 RSA key file = /etc/uswsusp.key shutdown method = platform and here are the relevant lines from my /boot/grub/menu.lst file: title Debian GNU/Linux, kernel 2.6.24-1-686 root(hd0,1) kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/hda2 ro vga=791 initrd /boot/initrd.img-2.6.24-1-686
Bug#486400: splashy doesn't work with hibernation
Marcel Dischinger wrote: > I have the same issue here. I found that the problem only occurs if > splashy is activated in grub (add "splash" as a kernel parameter) _and_ > in uswsusp. Then, splashy hangs while resuming from hibernation. > If I either remove splashy from grub or uswsusp, it works just fine. What do you mean when you say: "If I ... remove splashy from ... uswsusp, it works just fine." ??? I've tried adding "splash = n" to /etc/uswsusp.conf and regenerating the initial RAM disk, but that doesn't stop Splashy from hanging while resuming from hibernation. Thanks, - Eric
Bug#486400: splashy doesn't work with hibernation
Package: splashy Version: 0.3.10-1 Severity: normal I love watching Splashy's Debian-moreblue theme appear when I start my computer, but I'd also like to start my computer. Splashy works well on a clean boot, but it doesn't allow the computer to resume from hibernation. I've tried appending the line "splash = y" to my "/etc/uswsusp.conf" file and regenerating the initial RAM disk (with the "update-initramfs -u" command), but neither seem to work. For what it's worth, usplash appears to have the same bug (#468735 -- "usplash does not work with hibernation"). I do not know if they are related. Thanks, - Eric -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) 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 splashy depends on: ii initramfs-tools0.92b tools for generating an initramfs ii libc6 2.7-10GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-9 direct frame buffer graphics - sha ii libgcc11:4.3.0-5 GCC support library ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libmagic1 4.24-2File type determination library us ii libsplashy10.3.10-1 Library to draw splash screen on b ii lsb-base 3.2-12Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime splashy recommends no packages. -- no debconf information -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) 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 uswsusp depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-5 GCC support library ii libgcrypt11 1.4.1-1LGPL Crypto library - runtime libr ii liblzo2-2 2.03-1 data compression library ii libpci3 1:3.0.0-4 Linux PCI Utilities (shared librar ii libsplashy1 0.3.10-1 Library to draw splash screen on b ii libx86-1 0.99+ds1-2 x86 real-mode library Versions of packages uswsusp recommends: ii initramfs-tools 0.92b tools for generating an initramfs ii mount 2.13.1.1-1 Tools for mounting and manipulatin -- debconf information: uswsusp/suspend_loglevel: uswsusp/no_swap: uswsusp/resume_offset: uswsusp/early_writeout: true uswsusp/image_size: 121068584 uswsusp/snapshot_device: uswsusp/max_loglevel: uswsusp/shutdown_method: platform uswsusp/encrypt: false uswsusp/RSA_key_bits: 1024 * uswsusp/continue_without_swap: true uswsusp/compute_checksum: false uswsusp/no_snapshot: uswsusp/compress: true uswsusp/create_RSA_key: false uswsusp/RSA_key_file: /etc/uswsusp.key uswsusp/resume_device: /dev/hda5 uswsusp/splash: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468735: usplash: workaround
Forgive me for sending a third message, but I've just spent the better
part of the night trying to figure out how to get usplash to work when
the computer resumes from hibernation.
The workaround proposed above allows the computer to boot, but it
disables usplash at the very beginning of the boot process and leaves
the user with a splashless splash screen. What's the fun in that?
Here's what I have figured out.
One, you only need to place the "/sbin/usplash_write QUIT" command in
your "/usr/share/initramfs-tools/scripts/local-premount/resume" file.
Two, the best place to place that command is just before the "resume"
command and you can restart usplash after the resume command. For
example, this works (a little bit):
[ -e /sbin/usplash_write ] && /sbin/usplash_write QUIT
if [ -n "${resume_offset}" ]; then
/bin/resume ${resume} ${resume_offset}
else
/bin/resume ${resume}
fi
[ -e /sbin/usplash ] && /sbin/usplash
Although that last line restarts usplash, it starts a crippled version
of usplash. After restarting there are no messages or throbber and
usplash quits when the initial ramdisk completes its task. For
comparison, if you do not have to restart usplash, then it will run
almost all the way up to the point when X starts.
I've tried adding the lines below, running "update-initramfs -u" and
restarting/resuming my computer, but I have not had much luck.
[ -e /sbin/usplash ] && /sbin/usplash -v
[ -e /sbin/usplash_write ] && /sbin/usplash_write PULSATE
[ -e /sbin/usplash_write ] && /sbin/usplash_write VERBOSE true
Cheers,
- Eric
Bug#468735: usplash workaround works after regenerating initial ramdisk
Package: usplash Version: 0.5.19-1 Followup-For: Bug #468735 Here's an update and some more information on my system. Apologies for sending two bug reports. I added the line: "/sbin/usplash_write QUIT" to the beginning of the "resume" and "uswsusp" files in the "/usr/share/initramfs-tools/scripts/local-premount/" directory. That did not solve the problem. Frustrated, I turned to the little gremlin in the back of my mind for help and he said: "Regenerate the initial ramdisk!" so I ran: # apt-get install --reinstall usplash libusplash0 usplash-theme-debian which regenerated "/boot/initrd.img-2.6.24-1-686". I then hibernated my laptop and turned it back on to a successful resume. Yay! What I don't like about this workaround is the frightening blackscreen which appears when usplash quits. It defeats the purpose of having a splash screen. Cheers, - Eric -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) 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 usplash depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii initramfs-tools 0.92b tools for generating an initramfs ii libc6 2.7-10 GNU C Library: Shared libraries ii libusplash0 0.5.19-1 userspace bootsplash library ii usplash-theme-debian [usplash 4 Debian usplash theme usplash recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468735: usplash: workaround
Sorry to spoil the fun, but adding "usplash_write QUIT" at the beginning
of /usr/share/initramfs-tools/scripts/local-premount/{resume,uswsusp}
does not fix the problem for me.
Is there a particular place in those files where I should add the
command? or is this workaround limited?
Thanks,
- Eric
Bug#478154: deborphan: orphaner removes non-orphaned packages (like my kernels!)
Jörg Sommer wrote: I think the problem was that your system was in an broken state. I think your last install/update went wrong and initramfs-tools ended up with not being marked as installed (maybe marked as unpacked). So deborphan worked correct. I was wondering what went wrong, so I appreciate your reply. Jörg Sommer wrote: This is really easy. We can drop the -y option of apt-get and you get prompted by apt-get if it is okay to remove the packages. Thank you for your attention to this issue. - Eric
