Re: [systemd-devel] systemd version debus call changed
On Tue, 04.03.14 01:06, Timothée Ravier (sios...@gmail.com) wrote: On 03/03/2014 14:28, Àlex Fiestas wrote: On Friday 28 February 2014 02:28:20 Lennart Poettering wrote: They should just invoke the methods. If they get org.freedesktop.DBus.Error.UnknownMethod, org.freedesktop.DBus.Error.UnknownObject or org.freedesktop.DBus.Error.UnknownInterface back they should assume that logind is too old and doesn't support the call. (Actually, to make this really robust, they should just treat any error like that). Check for features by trying to make use of them. Don't check for version numbers. The problem was that long ago logind supported suspend (methods were in the bus) but they did not work, at least not for opensuse so that work around was added. This code will certainly die in the near future. I'm working on fixing this for KDE (https://git.reviewboard.kde.org/r/116527/). But now that I've looked at it little bit closer I think I may understand why they did version checks: As far as I understand, between v183 (d889a2069a87e4617b32dd) and v198 (314b4b0a68d9ab35de98192), PrepareForSleep signal is sent before suspending, but no signal is sent on resume, thus one must use upower to get this info; From v198 and onward, PrepareForSleep signal is also sent on resume, thus no need for upower anymore. Am I correct here? Did I miss something? Are there are any other solutions than checking for the version number to know if PrepareForSleep will be sent on resume? Should we just give up trying to support versions of systemd older than 198 (for systemd-based systems)? So, the old interface really didn't support any notification for system resume at all. We always assumed the kernel would eventually provide something for this, but we came to the conclusion that even if the kernel would provide userspace with a notification scheme for this (which it still doesn't do to this point) we should probably distuingish between low-level suspends (possibly done by the kernel itself with aggressive kernel-level auto-suspend), from high-level suspends managed by logind. So, this wasn't really a compat breakage, since we just generated signals that previously were only available for specific clients so that all clients would get them. However, that certianly doesn't help userspace apps like yours, since for them it cannot be determined whether they are running on a system that only generates PrepareForSleep() sometimes, or always... I'd probably recommend using upower when it is there (and support for it is compiled in), and then use logind as a fallback otherwise. That should make your code work with any system. Or alternatively, just declare that you require 198 at least... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Friday 28 February 2014 02:28:20 Lennart Poettering wrote: On Fri, 28.02.14 02:21, Timothée Ravier (sios...@gmail.com) wrote: On 26/02/2014 02:38, Lennart Poettering wrote: On Wed, 26.02.14 02:01, Jason A. Donenfeld (ja...@zx2c4.com) wrote: Upstream KDE patch is here: https://projects.kde.org/projects/kde/kde-workspace/repository/revision s/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backe nds/upower/powerdevilupowerbackend.cpp?format=diff Wow. Just wow. I am feeling tempted to just randomly change the version string exposed on the bus now, until they give that up. Whate else can I do than actually document that the string isn't stable? It is totally non-sensical to check for software versions the way KDE does it. We supply them with a call to check whether a certain operation is available (CanSuspend(), CanHibernate(), ...). They should just call that. It will tell them precisely whether the operation is not implemented in the code, or whether it is available on the hardware, and so on. But no, they decided to involve version checks... It looks like they check both systemd version and CanSuspend(), CanHibernate() results: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/m aster/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp# L229 Could it be for compatibility with older systemd releases? They should just invoke the methods. If they get org.freedesktop.DBus.Error.UnknownMethod, org.freedesktop.DBus.Error.UnknownObject or org.freedesktop.DBus.Error.UnknownInterface back they should assume that logind is too old and doesn't support the call. (Actually, to make this really robust, they should just treat any error like that). Check for features by trying to make use of them. Don't check for version numbers. The problem was that long ago logind supported suspend (methods were in the bus) but they did not work, at least not for opensuse so that work around was added. This code will certainly die in the near future. signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On 03/03/2014 14:28, Àlex Fiestas wrote: On Friday 28 February 2014 02:28:20 Lennart Poettering wrote: They should just invoke the methods. If they get org.freedesktop.DBus.Error.UnknownMethod, org.freedesktop.DBus.Error.UnknownObject or org.freedesktop.DBus.Error.UnknownInterface back they should assume that logind is too old and doesn't support the call. (Actually, to make this really robust, they should just treat any error like that). Check for features by trying to make use of them. Don't check for version numbers. The problem was that long ago logind supported suspend (methods were in the bus) but they did not work, at least not for opensuse so that work around was added. This code will certainly die in the near future. I'm working on fixing this for KDE (https://git.reviewboard.kde.org/r/116527/). But now that I've looked at it little bit closer I think I may understand why they did version checks: As far as I understand, between v183 (d889a2069a87e4617b32dd) and v198 (314b4b0a68d9ab35de98192), PrepareForSleep signal is sent before suspending, but no signal is sent on resume, thus one must use upower to get this info; From v198 and onward, PrepareForSleep signal is also sent on resume, thus no need for upower anymore. Am I correct here? Did I miss something? Are there are any other solutions than checking for the version number to know if PrepareForSleep will be sent on resume? Should we just give up trying to support versions of systemd older than 198 (for systemd-based systems)? -- Timothée Ravier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On 26/02/2014 02:38, Lennart Poettering wrote: On Wed, 26.02.14 02:01, Jason A. Donenfeld (ja...@zx2c4.com) wrote: Upstream KDE patch is here: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff Wow. Just wow. I am feeling tempted to just randomly change the version string exposed on the bus now, until they give that up. Whate else can I do than actually document that the string isn't stable? It is totally non-sensical to check for software versions the way KDE does it. We supply them with a call to check whether a certain operation is available (CanSuspend(), CanHibernate(), ...). They should just call that. It will tell them precisely whether the operation is not implemented in the code, or whether it is available on the hardware, and so on. But no, they decided to involve version checks... It looks like they check both systemd version and CanSuspend(), CanHibernate() results: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L229 Could it be for compatibility with older systemd releases? -- Timothée Ravier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Fri, 28.02.14 02:21, Timothée Ravier (sios...@gmail.com) wrote: On 26/02/2014 02:38, Lennart Poettering wrote: On Wed, 26.02.14 02:01, Jason A. Donenfeld (ja...@zx2c4.com) wrote: Upstream KDE patch is here: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff Wow. Just wow. I am feeling tempted to just randomly change the version string exposed on the bus now, until they give that up. Whate else can I do than actually document that the string isn't stable? It is totally non-sensical to check for software versions the way KDE does it. We supply them with a call to check whether a certain operation is available (CanSuspend(), CanHibernate(), ...). They should just call that. It will tell them precisely whether the operation is not implemented in the code, or whether it is available on the hardware, and so on. But no, they decided to involve version checks... It looks like they check both systemd version and CanSuspend(), CanHibernate() results: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L229 Could it be for compatibility with older systemd releases? They should just invoke the methods. If they get org.freedesktop.DBus.Error.UnknownMethod, org.freedesktop.DBus.Error.UnknownObject or org.freedesktop.DBus.Error.UnknownInterface back they should assume that logind is too old and doesn't support the call. (Actually, to make this really robust, they should just treat any error like that). Check for features by trying to make use of them. Don't check for version numbers. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Tuesday, February 25, 2014 23:47:39 Jason A. Donenfeld wrote: FYI to others experiencing weirdness, the Version api function changed between 208 and 209: in 208: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version systemd 208 in 209 and 210: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version 210 This apparently, as of writing, causes in KDE: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/mas ter/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L48 In KDE, this breaks suspend support. In case anyone else hits this snag, here's the issue. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Thanks for that, it is perfect timing since I just migrated my systems to 210 a couple of hours ago. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Tue, 25.02.14 23:47, Jason A. Donenfeld (ja...@zx2c4.com) wrote: FYI to others experiencing weirdness, the Version api function changed between 208 and 209: in 208: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version systemd 208 in 209 and 210: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version 210 This apparently, as of writing, causes in KDE: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L48 In KDE, this breaks suspend support. In case anyone else hits this snag, here's the issue. Yeah, KDE shouldn't have done that. This has been reported before. It's even documented in the wiki page that we take the liberty to change the formatting of that string any time: http://www.freedesktop.org/wiki/Software/systemd/dbus/ It is totally non-sensical to check for software versions the way KDE does it. We supply them with a call to check whether a certain operation is available (CanSuspend(), CanHibernate(), ...). They should just call that. It will tell them precisely whether the operation is not implemented in the code, or whether it is available on the hardware, and so on. But no, they decided to involve version checks... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Wed, 26.02.14 02:01, Jason A. Donenfeld (ja...@zx2c4.com) wrote: Upstream KDE patch is here: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff Wow. Just wow. I am feeling tempted to just randomly change the version string exposed on the bus now, until they give that up. Whate else can I do than actually document that the string isn't stable? And even involving a regex now... Yuck, does KDE think it is written in Perl? Meh. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
