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
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.
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
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
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
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
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,
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
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
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
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!
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
, 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
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
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
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
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
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
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
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)
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
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
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
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
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
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,
-
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
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
28 matches
Mail list logo
