I lack the suspend/hibernate on my KDE5 session. pm-suspend and pm-hibernate work as expected, so it is a software issue. upower 0.99.3 in installed. This version does no longer, when called with -d, advertise can-suspend and can-hibernate. powerdevil is up and running according to systemsettings5. As it is a Devuan system, without systemd, there is no libpam-systemd installed. Reproducible: Always Steps to Reproduce: 1. Have Devuan system, without systemd/libpam-systemd 2. 3. Expected Results: Same as pm-suspend and pm-resume.
This works fine on Debian testing. Please get in contact with your distribution to figure out why this broke in your Debian fork. You might consider of course to install systemd.
Newer versions of upower drop the support in favour of systemd. I think 0.9.23 was the last version that still supported the old behaviour.
Martin Gräßlin, "This works fine on Debian testing. Please get in contact with your distribution to figure out why this broke in your Debian fork. You might consider of course to install systemd." Basically, your answer is: to avoid a bug linked to systemd dependancy, I should use systemd? Is this Debian bug tracker or KDE bug tracker? I'm using KDE on GNU/Linux since more than 10 years, as KDE user, I'd like KDE to still be working, no matter what systemd or flavor of GNU/Linux I decided to use. Unless KDE is prepared to make a statement that it depends on systemd (which is exactly the kind of notion that makes people suspicious about systemd), please consider fixing this regression. Please, do not mark this bug as RESOLVED: it is not. Please, do not mark this bug as DOWNSTREAM: if it is that you force support of systemd, then it is definitely not a packaging issue. Rather mark is as WONTFIX, if you dont care.
How do you expect KDE to fix a problem caused by features removed by upower upstream?
I expect: 1. a bug not to be marked as resolved when it is open. 2. a bug that is due to UPSTREAM (upower) to be marked as such and not mistakingly marked DOWNSTREAM (because of likely animosity - I never seen any report of Ubuntu users discarded in such fashion) So please mark this bug appropriately, if you do not intend to fix it.
> Unless KDE is prepared to make a statement that it depends on systemd of course not. Powerdevil recently also gained support for ConsoleKit2, see: http://commits.kde.org/powerdevil/10f2be4f0a2b482008937b1e378e914a637d83be Which turns it into a distro problem. Your distribution configured the system in a way that suspend/hibernate is broken. It doesn't come with any of the supported solutions Plasma provides. Which makes it a distro problem. The distro integrates various parts of the software stack. This includes it's the distro's task to ensure that components work together. It failed here by ripping out systemd and replace it with well nothing.
"Which turns it into a distro problem. Your distribution configured the system in a way that suspend/hibernate is broken" This statement is wrong. As said earlier, pm-suspend and pm-hibernate works fine, as they do since years. "It doesn't come with any of the supported solutions Plasma provides. Which makes it a distro problem" It is a regression for KDE to drop support for perfectly working solution in favor of... broken ones. And when you say "any of the supported solutions", you mean only one, actually. Is there any alternative? "It failed here by ripping out systemd and replace it with well nothing." Well, if the plan with KDE is now to alter every feature that users are used to, so they only support some systemd feature (is that what you refers as "any of the supported solutions"), with no user perceptible benefit, I think that should be advertised clearly. If you are curious, you will see many bugs reports of Ubuntu users - with a common workaround being using an outdated upower version. Anyway, so now you give a pointer to consolekit2 support. Didn't powerdevil supported pm-utils in the past?
(In reply to Mathieu Roy from comment #7) > "Which turns it into a distro problem. Your distribution configured the > system in a way that suspend/hibernate is broken" > > This statement is wrong. As said earlier, pm-suspend and pm-hibernate works > fine, as they do since years. The statement is correct. It is libupower-glib that has changed. See the commit for yourself: http://cgit.freedesktop.org/upower/commit/?id=030e2c9d3633e35e8beeecc1f41f6e0ff77b57dc > > "It doesn't come with any of the supported solutions Plasma provides. Which > makes it a distro problem" > > It is a regression for KDE to drop support for perfectly working solution in > favor of... broken ones. And when you say "any of the supported solutions", > you mean only one, actually. Is there any alternative? As already mentioned it is upower that has dropped support - KDE has dropped nothing. Current working solutions are: * Using systemd * Using ConsoleKit2 * Using upower <=0.9.23 > "It failed here by ripping out systemd and replace it with well nothing." > > Well, if the plan with KDE is now to alter every feature that users are used > to, so they only support some systemd feature (is that what you refers as > "any of the supported solutions"), with no user perceptible benefit, I think > that should be advertised clearly. No feature has been altered and there is no systemd dependency. I've even seen KDE developers take the time to resolve ConsoleKit bugs even though they are not using it. > If you are curious, you will see many bugs reports of Ubuntu users - with a > common workaround being using an outdated upower version. This is becauase of upower changes, see above. > > Anyway, so now you give a pointer to consolekit2 support. Didn't powerdevil > supported pm-utils in the past? powerdevil continues to support upower just fine. Feel free to contact me if I can assist with packaging improvements - we ship powerdevil that works just fine both with and without systemd.
> This statement is wrong. As said earlier, pm-suspend and pm-hibernate works > fine, as they do since years. The statement is correct. It is libupower-glib that has changed. See the commit for yourself: http://cgit.freedesktop.org/upower/commit/?id=030e2c9d3633e35e8beeecc1f41f6e0ff77b57dc Clearly, I think we're getting lost in translation. Writting "Your distribution configured the >> system in a way that suspend/hibernate is broken" is obviously wrong when you speak of a system with a working suspend hibernate mechanism. It is more "Your distribution configured the system in a way that Powerdevil suspend/hibernate is broken". It may not looks like such, but actually it really means something else. suspend/hibernate does work. > As already mentioned it is upower that has dropped support - KDE has dropped nothing. > Current working solutions are: > * Using systemd > * Using ConsoleKit2 > * Using upower <=0.9.23 So we agree that this bug is UPSTREAM, if anything. Thanks! I'd gladly try ConsoleKit2 but I dont think it has been packaged yet. Which version of upower is known to include ConsoleKit2 support? >powerdevil continues to support upower just fine. Feel free to contact me if I can assist with > packaging improvements - we ship powerdevil that works just fine both with > and without systemd. That is very nice of you Michael (and, BTW, I thank you for your meaningful comments) but it looks like I'll end up using an outdated upower (http://snapshot.debian.org/package/upower/0.9.23-2/ Seen in debian on 2013-10-23!) waiting for PolicyKit2 to be actually packaged. Still, days after days, I cannot help but feeling pressured to use systemd, which actually makes more more suspicious about it. I understand that powerdevil depends on upower that in turned somehow dropped support for pm-utils, endgame being that for the desktop user, it is just a regression, even though you are not responsible for it. I sincerily wonder if I'll be able to keep using KDE next year without systemd or whether more and more parts will stop to work similarly.
I posted this https://yeupou.wordpress.com/2015/11/25/getting-back-suspendresume-with-kde-5s-powerdevil-and-no-systemd-by-installing-an-obsolete-version-of-upower/ that describe step by step how to put back an old version of upower. This is really a terrible band aid.
Setting back to resolved downstream. From our side there is just nothing to do and to me it's an integration issue (bundling of non-compatible versions) which means downstream.
Martin Gräßlin, have it your way. As you are perfectly aware, the current only immediately available fix consist to install an obsolete version of upower. Right now, Powerdevil is unusable, under normal conditions, without systemd because of a deliberate choice made by upower. That is not some downstream choice of packaging (is it a serious choice of packaging to provide obsolete unsupported software?), but upstream choice of development (made even before Devuan existed). Beside forking upower, there is no real sane solution. If ConsoleKit2 wants to replace systemd role in this, it'll have to be some systemd clone. It means a lot, notably that actually systemd cannot really be replaced - make a clone with another name, now, that would be stupid. When you tag this as resolved downstream, you are just making a statement about who is to blame and how much you care about the issue.
> When you tag this as resolved downstream, you are just making a statement about who is to blame and how much you care about the issue. huh? You might be interpreting too much into this. Please step a little bit away from the "systemd conspiracy" if I might call it that way. We absolutely don't care what init systems our users use - not our business. If you are not happy with the possibilities for power management provided by Plasma I can only recommend to do what those who wanted to use ConsoleKit2 did: sit down and write the code. This is free software: scratch your own itch. Don't expect that others scratch your itch.
Martin Gräßlin, [off topic to this bug report that will anyway not amount to anything] Quotes should be used only to quote. No one ever wrote anything about a "systemd conspiracy" here, so let's drop this whole notion. You don't care what I'm using, though in your first reply you immediately suggest to me to use systemd. A bit much for someone that actually have no opinion about it. A quick look at your blog tells a lot. You wrote "To me it is clear for quite some time already that I won’t accept patches any more for non-Linux. Including another code path or even a build flag for non-Linux systems is not worth the increasing maintaining costs. If non-Linux systems want to include patches they should do it downstream", "Yes and I fully agree with Lennart on not including non-Linux OS in systemd. And I hope that Debian will decide for systemd and the motivation for this blog post was mostly systemd with both Debian and KDE in my mind" http://blog.martin-graesslin.com/blog/2011/08/thoughts-about-kde-plasma-on-non-linux-systems/ Downstream, isn't it a thing for you? There is no conspiracy (what, are we 5 year old?) but you surely look like someone not totally neutral about systemd. And you have the right too. It is not a problem per se. What I really said, though, is I find unlikely that coding an alternative to systemd is feasible in the long run. I scratched my itch, as you see, I went back using an outdated upower. I do not have time to do more than that and, most importantly, I dont think it is sensible to actually do more than that. Now, if we are here to give opinions, I'd just say that since this whole systemd story started, it looks like we are talking about something major in computing. Conspiracies? Seriously? Well, how to put it? Almost no one I know in life knows KDE. No one. Or one. KDE is a considerably minor desktop environment on a system still unfit for many simple desktop users. If using it itches too much, there is another option: looking somewhere else. Long time ago, ten years before you were even working on KDE, I was puzzled by what was going with GNOME. I was using GNOME and thought that their plans for GNOME 2 was a joke, for instance deciding to give to a company that came out of nowhere ( https://en.wikipedia.org/wiki/Eazel ) the task to write a new file manager out of the blue. Despite user community questioning this approach, they went with it. Turns out it was not at all a success story. I stopped using GNOME at that time. It was not such a big issue for me, I lived with it with no problem. It did not change everything for GNOME, they just lost users with GNOME 2. This systemd whole story looks to me more the business of young software developers that found a way to have a central role in GNU/Linux than anything else. So what's next? Maybe you are right, maybe systemd will turns out to be the best choice and ten years from now no one would imagine GNU/Linux without it. If you are wrong, well, KDE will continue to lag behind Apple OS X and MS Windows, despite its qualities. I already stopped using Konqueror two years ago. I was tempted to stop using kmail and I was forced to make people I know using thunderbird because of the unreliability of kmail2. It is not like quitting KDE is impossible. There is no killer feature.
PowerDevil Maintainer here. It is just not feasible for me to maintain all kinds of exotic setups. I also removed the HAL backend because it is obsolete and I just don't have any means of testing it. This has been communicated in advance and so it is a downstream issue if nobody objected and/or fixed the integration issues. I happily accepted patches to add ConsoleKit 2 support to PowerDevil but I'm not going to invest any of my personal time into "fixing" this. Also, PowerDevil might just be the first component to break for you because we started using systemd services here. I'm quite sure if this downstream "denial trend" continues there'll be breakage for you in other components as well. See [1] for potential significant improvements to our codebase possible thanks for "d" services. [1] http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
Well, this seems rather simple to me. Plasma supports the interfaces offered by (previously) upower and (now) systemd. If you replace systemd, you will have to implement something offering these interfaces. We're not pushing systemd onto anybody, but if you don't want the solutions most of our downstreams are happy with, you get to fix what you broke (by either upgrading your upower to something new and incompatible) or by removing systemd. In any case, the interfaces are well defined, and it's probably not the first time you have to fill in functionality offered by systemd after you decided to remove it. That is entirely your choice, don't make it our problem.
thanks for submitting to slashdot. Next time we can just set to invalid to make sure there is no stupid discussion which then gets mirrored to slashdot.
Martin Gräßlin, your last comment is like your first: completely useless. You can set the report to invalid, for all I care, for all it can actually change! Does that annoys you that is being discussed on slashdot. To paraphrase you, don't make it my problem. As Sebastian Kügler suggested, it is actually not the first time I had to fill in functionality offered by systemd after I decided to remove it. Well, obviously, the lack of perpective is the fact that we are talking of functionalities that were there long before systemd. Fact is, I submitted this report, while I already knew the stupid workaround (hence upower version number in the title of my report). I wanted to know how KDE was to handle this. Now, I think it is pretty clear. So, Martin, because you are young (aren't you?) and employed to work on KDE, you may think the world resolves around that. I know KDE since, well... 17 years. When I started using it, no one knew about it, besides geek. It is not really different as of today. KDE, even renamed Plasma, is unknown besides to people in computing industry. I'd rather see KDE succeed than fail. But I dont care that much in the end. I'm sure there will be always some good software to run.
Kai Uwe Broulik, as I actually already provided the link you referred to in the ./ article that Martin think stupid, I am familiar with it. Obviously there are good reasons for KDE to use systemd. He said it all in "In many cases it allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it as an optional extra defeats the main benefit.". Right now, stuff I'm using since years, with no progress, is being thrown out because it makes your development easier. Since systemd cannot be optional, as it would defeats the main benefit, not using systemd breaks it. That is exactly my point. Right now, I am not satisfied with systemd and more by what existed and run before. It is clear that using KDE in the long run without systemd probably wont makes sense. We already know that the other options are a joke. So I think were KDE stands now is pretty clear. We'll see how it develops.
Please remain on topic and please stick to the facts. Especially on this kind of contagious topics, offtopic ranting muddies the problem and makes a solution harder to achieve. KDE has not thrown out anything. We have explained the problem and proposed three different solutions to you: * Using systemd * Using ConsoleKit2 * Using upower <=0.9.23 (see (see https://bugs.kde.org/show_bug.cgi?id=355892#c8 ) All of those solutions work with Plasma. If you're unhappy about all of them, you can work on solution #4 (an obvious approach would be to offer the DBus interfaces you're missing in a component of your own). In case you need feedback from us, let us know, we're always happy to help those that want to solve problems in a constructive manner.