Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
forwarded 635644 https://sourceforge.net/tracker/?func=detailatid=757308aid=3381993group_id=143975 tags 635644 upstream thanks On Thu, Jul 28, 2011 at 12:00 PM, Francesco Poli invernom...@paranoici.org wrote: [please remember to Cc: me, otherwise I will only be able to see your replies on the BTS web interface] Sorry, will do! Maybe the first time Fluxbox is started, it is not fast enough to do something that is needed by Conky, and the latter fails to start because of this. The next times Fluxbox is started (without rebooting the box), it is faster to load, due to memory caches and similar tricks performed by the kernel: as a consequence, Conky finds Fluxbox fully initialized (or more initialized, anyway) and is able to start properly. This is all I can imagine, as a guessed explanation... Could it be? Or am I completely off-track? At the moment, that sounds like the most reasonable explanation for this bug... Well, I think it *is* a bug, even though we *may* have found a way to work around it. Hence, it would be very nice of you, if you could forward the bug report upstream... I've just forwarded the bug upstream; see https://sourceforge.net/tracker/?func=detailatid=757308aid=3381993group_id=143975 (if there's anything I've overlooked, feel free to add a comment). - Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
On Fri, 29 Jul 2011 03:15:27 -0700 Vincent Cheng wrote: forwarded 635644 https://sourceforge.net/tracker/?func=detailatid=757308aid=3381993group_id=143975 tags 635644 upstream thanks It seems to me that the bug does not yet show up as forwarded on the BTS web interface: I suspect that breaking the forwarded command line confused the control bot... On Thu, Jul 28, 2011 at 12:00 PM, Francesco Poli invernom...@paranoici.org wrote: [...] Maybe the first time Fluxbox is started, it is not fast enough to do something that is needed by Conky, and the latter fails to start because of this. The next times Fluxbox is started (without rebooting the box), it is faster to load, due to memory caches and similar tricks performed by the kernel: as a consequence, Conky finds Fluxbox fully initialized (or more initialized, anyway) and is able to start properly. This is all I can imagine, as a guessed explanation... Could it be? Or am I completely off-track? At the moment, that sounds like the most reasonable explanation for this bug... Good, let's hope it helps to pinpoint the cause of the bug. Well, I think it *is* a bug, even though we *may* have found a way to work around it. Hence, it would be very nice of you, if you could forward the bug report upstream... I've just forwarded the bug upstream; see https://sourceforge.net/tracker/?func=detailatid=757308aid=3381993group_id=143975 (if there's anything I've overlooked, feel free to add a comment). Thank you so much! I think you summarized the bug report adequately, and there's the URL of the full Debian bug report, anyway. Let's wait and see. Thanks again for your kind assistance! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpTPdTbcfFUK.pgp Description: PGP signature
Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
On Fri, Jul 29, 2011 at 9:23 AM, Francesco Poli invernom...@paranoici.org wrote: It seems to me that the bug does not yet show up as forwarded on the BTS web interface: I suspect that breaking the forwarded command line confused the control bot... Yes, I've noticed that as well, but for some reason, the BTS seems to be wrapping my commands and breaking it up into multiple lines; I'm also having problems trying to set up a forwarded-to address for #635637. This wouldn't be an issue if SourceForge bug URIs could be shortened somehow, but I don't know if that's possible. Or maybe this is just a problem with Gmail wrapping my e-mail before the control bot receives it? Hmmm...could you try mailing the control bot yourself and setting up a forwarded-to address for this bug (and if it works, #635637 as well)? I'd appreciate your help, thanks! Thank you so much! I think you summarized the bug report adequately, and there's the URL of the full Debian bug report, anyway. Let's wait and see. Thanks again for your kind assistance! No problem, it's my duty as maintainer to deal with bug reports and forward them upstream, after all. :) - Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
forwarded 635644 https://sourceforge.net/tracker/?func=detailatid=757308aid=3381993group_id=143975 forwarded 635637 https://sourceforge.net/tracker/?func=detailaid=3084509group_id=143975atid=757308 thanks On Fri, 29 Jul 2011 10:19:50 -0700 Vincent Cheng wrote: On Fri, Jul 29, 2011 at 9:23 AM, Francesco Poli invernom...@paranoici.org wrote: It seems to me that the bug does not yet show up as forwarded on the BTS web interface: I suspect that breaking the forwarded command line confused the control bot... Yes, I've noticed that as well, [...] Or maybe this is just a problem with Gmail wrapping my e-mail before the control bot receives it? I suspect the issue is due to Google Gmail (you should really abandon that huge privacy-hurting non-standard-conforming pain in the neck...). Hmmm...could you try mailing the control bot yourself and setting up a forwarded-to address for this bug (and if it works, #635637 as well)? I'd appreciate your help, thanks! Let's try and see. I would be glad to help! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpRkHa7WBBwm.pgp Description: PGP signature
Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
On Fri, Jul 29, 2011 at 10:31 AM, Francesco Poli invernom...@paranoici.org wrote: Let's try and see. I would be glad to help! So I guess this is indeed an issue with Gmail, not with the BTS itself. Oh well...regardless, thanks! - Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
On Fri, 29 Jul 2011 14:37:24 -0700 Vincent Cheng wrote: On Fri, Jul 29, 2011 at 10:31 AM, Francesco Poli invernom...@paranoici.org wrote: Let's try and see. I would be glad to help! So I guess this is indeed an issue with Gmail, not with the BTS itself. Oh well...regardless, thanks! You're welcome, really! Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpdAtKq4p9KR.pgp Description: PGP signature
Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
On Wed, 27 Jul 2011 15:47:14 -0700 Vincent Cheng wrote: Hi, [please remember to Cc: me, otherwise I will only be able to see your replies on the BTS web interface] I'm not quite sure what to make of this bug; I don't know of any specific changes between conky 1.7 and 1.8 that could have possibly caused this bug, and the fact that this bug can't be reproduced reliably makes it even harder to pinpoint the cause. I am beginning to suspect that it is triggered the first time I start a Fluxbox session, after booting the box. It does not seem to kick in, whenever I start a Fluxbox session again (without rebooting). Maybe the first time Fluxbox is started, it is not fast enough to do something that is needed by Conky, and the latter fails to start because of this. The next times Fluxbox is started (without rebooting the box), it is faster to load, due to memory caches and similar tricks performed by the kernel: as a consequence, Conky finds Fluxbox fully initialized (or more initialized, anyway) and is able to start properly. This is all I can imagine, as a guessed explanation... Could it be? Or am I completely off-track? However, as a workaround, can you try introducing a delay before starting conky? For example, in ~/.xsession: sleep 15 conky I am trying the following strategy: I set background no in my ~/.conkyrc, then postponed the conky command as much as possible within my ~/.xsession and replaced it with sleep 5 conky In a few tests performed today, it seems to work around the bug. Now I am tired of rebooting the box, just for the fun of it... ;-) I'll see whether it goes on fine in the next days. Besides that, I don't have any other suggestions. If delaying conky's startup doesn't fix this, let me know and I'll file a bug report upstream. Well, I think it *is* a bug, even though we *may* have found a way to work around it. Hence, it would be very nice of you, if you could forward the bug report upstream... Thanks for your time and for your fast and kind replies! Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpVPdR2OOMNS.pgp Description: PGP signature
Bug#635644: conky-std: often fails to start from .xsession (Alarm clock error)
Package: conky-std Version: 1.8.1-1 Severity: normal Hi and thanks again for adopting conky! I think I noticed a regression of conky-std/1.8.x with respect to the old conky/1.7.x versions. Since I began using conky-std/1.8.x (first a locally rebuilt modification of conky-std/1.8.0-1.1, with disabled nvidia support for conky-all, so that I could rebuild the package inside my main-only sid chroot, see bug #579102 ; now, thanks to you, just conky-std/1.8.1-1 from sid main), I have often (but not always, unfortunately) experienced an annoying bug. Let me explain. I use Fluxbox and I start a number of programs from my ~/.xsession file. Among the others, I start conky with the following .xsession line: conky This used to work fine with the old conky/1.7.x versions. Now, with conky-std/1.8.x, I often see that conky fails to show up, when I start a Fluxbox session (with startx). Indeed, as soon as I check with $ ps aux | grep conky I find out that conky is not running at all. And I see the following error message in my ~/.xsession-errors /home/$MYUSERNAME/.xsession: line 15: 1952 Alarm clock conky After these checks, I start an xterm and I manually issue the following command: $ conky This seems to always start conky, without any glitch. I seem to experience this bug more often, if I start a Fluxbox session soon after booting the box, much less often, if I start a Fluxbox session on a box which already has a long uptime. I am not sure of this correlation, though. What's wrong? Is there anything I failed to understand? Should I change anything to adapt to the new conky-std/1.8.x ? If you need to review my ~/.conkyrc , it's documented on my website http://www.inventati.org/frx/ Here, to be more precise: http://www.inventati.org/frx/doc/nanodocs/testing_workstation_desktopconf.html#system-monitor Thanks for your attention so far and for any help you can provide! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages conky-std depends on: ii libc6 2.13-10Embedded GNU C Library: Shared lib ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libiw30 30~pre9-5 Wireless tools - library ii liblua5.1-0 5.1.4-5Simple, extensible, embeddable pro ii libncurses5 5.9-1 shared libraries for terminal hand ii libx11-6 2:1.4.3-2 X11 client-side library ii libxdamage1 1:1.1.3-2 X11 damaged region extension libra ii libxext6 2:1.3.0-3 X11 miscellaneous extension librar ii libxfixes31:5.0-4X11 miscellaneous 'fixes' extensio ii libxft2 2.2.0-3FreeType-based font drawing librar conky-std recommends no packages. Versions of packages conky-std suggests: pn apcupsd none (no description available) pn moc none (no description available) pn mpd none (no description available) -- 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#635644: conky-std: often fails to start from .xsession (Alarm clock error)
Hi, I'm not quite sure what to make of this bug; I don't know of any specific changes between conky 1.7 and 1.8 that could have possibly caused this bug, and the fact that this bug can't be reproduced reliably makes it even harder to pinpoint the cause. However, as a workaround, can you try introducing a delay before starting conky? For example, in ~/.xsession: sleep 15 conky Besides that, I don't have any other suggestions. If delaying conky's startup doesn't fix this, let me know and I'll file a bug report upstream. Kind regards, - Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
