[opensuse-factory] hplip starts too early
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem. However I can't find where this program gets started. Any suggestion? -- fr.gr. member openSUSE Freek de Kruijf -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Freek de Kruijf <freek@opensuse.org> writes:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
A sleep can never solve a race condition.
However I can't find where this program gets started.
/etc/xdg/autostart/hplip-systray.desktop Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op dinsdag 9 juni 2015 12:42:22 schreef Andreas Schwab:
Freek de Kruijf <freek@opensuse.org> writes:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
A sleep can never solve a race condition.
However I can't find where this program gets started.
/etc/xdg/autostart/hplip-systray.desktop
Andreas.
hplip-systray doesn't work with plasma5's systemtray. To avoid it from even trying copy the /etc/xdg/autostart/hplip-systray.desktop to ~/.config/autostart, then change the Exec= to "echo something" or whatever. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 09, 2015 at 01:05:23PM +0200, Knurpht - Gertjan Lettink wrote:
hplip-systray doesn't work with plasma5's systemtray. To avoid it from even trying copy the /etc/xdg/autostart/hplip-systray.desktop to ~/.config/autostart, then change the Exec= to "echo something" or whatever.
If I dismiss the error message at startup and then run hp-systray & it behaves as expected. -- ======================== Roger Whittaker roger@disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op dinsdag 9 juni 2015 12:10:57 schreef Roger Whittaker:
On Tue, Jun 09, 2015 at 01:05:23PM +0200, Knurpht - Gertjan Lettink wrote:
hplip-systray doesn't work with plasma5's systemtray. To avoid it from even trying copy the /etc/xdg/autostart/hplip-systray.desktop to ~/.config/autostart, then change the Exec= to "echo something" or whatever.
If I dismiss the error message at startup and then run
hp-systray &
it behaves as expected.
I also have that behavior, so it works with systemtray of plasma5. Can I change the Exec in "sleep 10;hp-systray -x" -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2015-06-09 14:39, Freek de Kruijf wrote:
Op dinsdag 9 juni 2015 12:10:57 schreef Roger Whittaker:
On Tue, Jun 09, 2015 at 01:05:23PM +0200, Knurpht - Gertjan Lettink wrote:
hplip-systray doesn't work with plasma5's systemtray. To avoid it from even trying copy the /etc/xdg/autostart/hplip-systray.desktop to ~/.config/autostart, then change the Exec= to "echo something" or whatever.
If I dismiss the error message at startup and then run
hp-systray &
it behaves as expected.
I also have that behavior, so it works with systemtray of plasma5.
Can I change the Exec in "sleep 10;hp-systray -x"
As Andreas said: a sleep won't fix it. Who says that after 10 seconds, the conditions are right enough for hp-systray to succeed launching? ...also note the difference between "hp-systray" and "hp-systray -x". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09.06.2015 14:56, Jan Engelhardt wrote:
On Tuesday 2015-06-09 14:39, Freek de Kruijf wrote:
Op dinsdag 9 juni 2015 12:10:57 schreef Roger Whittaker:
On Tue, Jun 09, 2015 at 01:05:23PM +0200, Knurpht - Gertjan Lettink wrote:
hplip-systray doesn't work with plasma5's systemtray. To avoid it from even trying copy the /etc/xdg/autostart/hplip-systray.desktop to ~/.config/autostart, then change the Exec= to "echo something" or whatever.
If I dismiss the error message at startup and then run
hp-systray &
it behaves as expected.
I also have that behavior, so it works with systemtray of plasma5.
Can I change the Exec in "sleep 10;hp-systray -x"
As Andreas said: a sleep won't fix it. Who says that after 10 seconds, the conditions are right enough for hp-systray to succeed launching?
...also note the difference between "hp-systray" and "hp-systray -x".
Agreed that a sleep won't be a true solution for the underlying problem (which probably would require some sort of dependency control). However, for the individual user it might be a sufficient workaround if a startup delay raises the success rate to 90% or more. For such cases, I tend to create a small shell script that handles the delay, and specify that in the *.desktop file. On a side note: this fails, however, if the application is started by session management and not by some autostart entry (as currently happens for me with kontact & plasma5 - annoying, but I'll live with it until kontact goes KDE Applications 15...). -- Cahn's Axiom: When all else fails, read the instructions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
However I can't find where this program gets started.
Any suggestion?
hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt. hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards. Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Brüns, Stefan <Stefan.Bruens@rwth-aachen.de> [06-09-15 12:22]:
On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
However I can't find where this program gets started.
Any suggestion?
hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.
hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.
Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.
I also see this "anomaly" on three of my four local boxes, all with sni-qt installed and like settings. One desktop work and two laps and another dt fail, complaining missing setting-tray. All systems are Tw. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, June 09, 2015 13:12:24 Patrick Shanahan wrote:
* Brüns, Stefan <Stefan.Bruens@rwth-aachen.de> [06-09-15 12:22]:
On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
However I can't find where this program gets started.
Any suggestion?
hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.
hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.
Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.
I also see this "anomaly" on three of my four local boxes, all with sni-qt installed and like settings. One desktop work and two laps and another dt fail, complaining missing setting-tray.
All systems are Tw.
Hm, there may be a race condition in the bus startup, tray startup and hp- systray startup. Does it also happen if you invoke hp-systray after the desktop has started? You can trace the hp-systray startup by copying the attached hplip- systray.desktop to your ~/.config/autostart/ directory. It will dump the relevant dbus messages to /tmp/dbus_sni_$pid.out Kill the dbus-monitor process after your session has started: killall dbus-monitor The added tracing may change the timing, thus the trace might be useless. I have attached a trace of the hplip-systray startup. You can see the folllowing: The unique name :1.2707 gets a new owner as result of a "Hello" method call (NameOwnerChanged, [:1.2707, "", :1.2707] The requester is informed of its aquired name (Hello -> ":1.2707") :1.2707 adds a match for the StatusNotifierHostRegistered signal :1.2707 asks the bus for the StatusNotifierWatcher owner :1.2707 asks org.kde.StatusNotifierItem to Register a new StatusNotifierItem Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424
* Brüns, Stefan <Stefan.Bruens@rwth-aachen.de> [06-09-15 15:42]:
On Tuesday, June 09, 2015 13:12:24 Patrick Shanahan wrote:
* Brüns, Stefan <Stefan.Bruens@rwth-aachen.de> [06-09-15 12:22]:
On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
However I can't find where this program gets started.
Any suggestion?
hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.
hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.
Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.
I also see this "anomaly" on three of my four local boxes, all with sni-qt installed and like settings. One desktop work and two laps and another dt fail, complaining missing setting-tray.
All systems are Tw.
Hm, there may be a race condition in the bus startup, tray startup and hp- systray startup.
Does it also happen if you invoke hp-systray after the desktop has started?
No, there appear to be at least two pids of hp-systray -x after the failure to find the system tray. I kill those processes but it is not required and issue "hp-systray -x" and have normal and expected function.
You can trace the hp-systray startup by copying the attached hplip- systray.desktop to your ~/.config/autostart/ directory. It will dump the relevant dbus messages to /tmp/dbus_sni_$pid.out
Kill the dbus-monitor process after your session has started: killall dbus-monitor
The added tracing may change the timing, thus the trace might be useless.
I have attached a trace of the hplip-systray startup. You can see the folllowing:
The unique name :1.2707 gets a new owner as result of a "Hello" method call (NameOwnerChanged, [:1.2707, "", :1.2707] The requester is informed of its aquired name (Hello -> ":1.2707")
:1.2707 adds a match for the StatusNotifierHostRegistered signal :1.2707 asks the bus for the StatusNotifierWatcher owner :1.2707 asks org.kde.StatusNotifierItem to Register a new StatusNotifierItem
I will do this on one of the lap tops and post a link. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <ptilopteri@gmail.com> [06-09-15 17:21]:
* Brüns, Stefan <Stefan.Bruens@rwth-aachen.de> [06-09-15 15:42]:
On Tuesday, June 09, 2015 13:12:24 Patrick Shanahan wrote:
* Brüns, Stefan <Stefan.Bruens@rwth-aachen.de> [06-09-15 12:22]:
On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
However I can't find where this program gets started.
Any suggestion?
hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.
hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.
Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.
I also see this "anomaly" on three of my four local boxes, all with sni-qt installed and like settings. One desktop work and two laps and another dt fail, complaining missing setting-tray.
All systems are Tw.
Hm, there may be a race condition in the bus startup, tray startup and hp- systray startup.
Does it also happen if you invoke hp-systray after the desktop has started?
No, there appear to be at least two pids of hp-systray -x after the failure to find the system tray. I kill those processes but it is not required and issue "hp-systray -x" and have normal and expected function.
You can trace the hp-systray startup by copying the attached hplip- systray.desktop to your ~/.config/autostart/ directory. It will dump the relevant dbus messages to /tmp/dbus_sni_$pid.out
Kill the dbus-monitor process after your session has started: killall dbus-monitor
The added tracing may change the timing, thus the trace might be useless.
I have attached a trace of the hplip-systray startup. You can see the folllowing:
The unique name :1.2707 gets a new owner as result of a "Hello" method call (NameOwnerChanged, [:1.2707, "", :1.2707] The requester is informed of its aquired name (Hello -> ":1.2707")
:1.2707 adds a match for the StatusNotifierHostRegistered signal :1.2707 asks the bus for the StatusNotifierWatcher owner :1.2707 asks org.kde.StatusNotifierItem to Register a new StatusNotifierItem
I will do this on one of the lap tops and post a link.
trace is at: http://wahoo.no-ip.org/~pat/dbus_sni_16030.txt -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Jun 9 16:22 Brüns, Stefan wrote:
On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
However I can't find where this program gets started.
Any suggestion?
hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.
hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.
Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.
In general I have zero knowledge about desktop-related stuff (I do not use a desktop) so that there is basically nothing what I could do here. As far as I understand it had worked in the past with older KDE but now it does no longer work with newer KDE. Accordingly I assume it is a generic issue in HPLIP with newer KDE but not an openSUSE specific issue. If I am right, the proper way to get it really solved is to report it directly to the HPLIP upstream authors via http://hplipopensource.com/hplip-web/support.html This way the issue could be solved in HPLIP for all desktops for all Linux distributions instead of openSUSE specific hacks. Or is the only issue that for current openSUSE:Factory the hplip binary RPM should require sni-qt and then all would again "just work"? In this case I would appreciate an OBS submitrequest with an appropriate conditional RPM requirement for sni-qt for the hplip binary RPM (sni-qt is neither available for openSUSE:13.1 nor SLE12 nor SLE11 but HPLIP is built in the OBS Printing project for all of them). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)
Op woensdag 10 juni 2015 10:58:34 schreef Johannes Meixner:
Hello,
On Jun 9 16:22 Brüns, Stefan wrote:
On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:
After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.
However I can't find where this program gets started.
Any suggestion?
hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.
hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.
Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.
In general I have zero knowledge about desktop-related stuff (I do not use a desktop) so that there is basically nothing what I could do here.
As far as I understand it had worked in the past with older KDE but now it does no longer work with newer KDE.
Accordingly I assume it is a generic issue in HPLIP with newer KDE but not an openSUSE specific issue.
If I am right, the proper way to get it really solved is to report it directly to the HPLIP upstream authors via http://hplipopensource.com/hplip-web/support.html
This way the issue could be solved in HPLIP for all desktops for all Linux distributions instead of openSUSE specific hacks.
Or is the only issue that for current openSUSE:Factory the hplip binary RPM should require sni-qt and then all would again "just work"?
In this case I would appreciate an OBS submitrequest with an appropriate conditional RPM requirement for sni-qt for the hplip binary RPM (sni-qt is neither available for openSUSE:13.1 nor SLE12 nor SLE11 but HPLIP is built in the OBS Printing project for all of them).
Kind Regards Johannes Meixner
Agreed, it's up to HP to fix this. In the meantime, this works on my laptop as a workaround: - Copy the hplip-systray.desktop from /etc/xdg/autostart to ~/.config/autostart, then edit it to make it like this: cat ~/.config/autostart/hplip-systray.desktop [Desktop Entry] Categories=Application;Utility; Comment[nl_NL]=HP System Tray Service Comment=HP System Tray Service Exec=sleep 20;hp-systray -x & GenericName[nl_NL]=Printer Status Applet GenericName=Printer Status Applet Icon=/usr/share/hplip/data/images/128x128/hp_logo.png MimeType= Name[nl_NL]=HP System Tray Service Name=HP System Tray Service Path= StartupNotify=false Terminal=false TerminalOptions= Type=Application Version=0.6 X-DBUS-ServiceName= X-DBUS-StartupType= X-KDE-StartupNotify=false X-KDE-SubstituteUID=false X-KDE-Username= X-SuSE-translate=true -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Andreas Mahel -
Andreas Schwab -
Brüns, Stefan -
Freek de Kruijf -
Jan Engelhardt -
Johannes Meixner -
Knurpht - Gertjan Lettink -
Patrick Shanahan -
Roger Whittaker