Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Am I being forced to use systemd now?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5 ... 18, 19, 20  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4254
Location: USA

PostPosted: Thu Jun 05, 2014 3:30 pm    Post subject: Reply with quote

When will there be a stage3 available with systemd :D
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
OldTango
Guru
Guru


Joined: 21 Feb 2004
Posts: 503

PostPosted: Thu Jun 05, 2014 5:32 pm    Post subject: Reply with quote

Princess Nell wrote:
I updated the overlay and package.accept_keywords, but no change. For some reason, the 1.8 packages are now being pulled, not 1.6.

I found the ebuilds causing the problem and hacked upower-pm-utils support into them: mate-applets-1.8.0, mate-power-manager-1.8.0-r1 and mate-session-manager-1.8.1. What I couldn't figure out was how to unmask the portage versions of those three and use them instead of the overlay.

Code:
emerge -C upower
emerge --oneshot --noreplace 'sys-power/upower-pm-utils'

See This Post to move from the mate overlay to the one in the portage tree.
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2946

PostPosted: Thu Jun 05, 2014 7:12 pm    Post subject: Reply with quote

Zwisel wrote:
Funny post ;) but... I still have a choice and my choice is to NOT install systemd. And it is still working.

Zwisel ... I'm not sure whats funny about it, the statements in quotes are from the main systemd developer. Anyhow, your "but" is not a rejoinder as I was speaking about this "gentle push" toward a "standard base system" in general and not upower in particular, you may currently have the choice, but that choice may not be open to you in future.

Zwisel wrote:
Of course it needs a bit technical understanding and a bit googling, too. But who's using Gentoo without this skills?! I expect this from a Gentoo-user, otherwise there are many "simpler" distros out there (even if I'm missing the comfort of Portage in most other distros :)).

"skill" is not an definitive quality one can acquire, its something that is accumulative, context dependent, etc. I too expect that the a "gentoo user" acquire the skills required to maintain their system, but this is only a certain level of skill that may not include writing their own ebuilds, maintaining their own overlay, etc. There are problems that some users don't have the requisite skills to handle, and that is in part why the forums exist. So, while there are "simpler distros" out there that doesn't mean that one should switch to them once a problem is encountered that is beyond your current skill level, skill isn't a measure of ones suitability for a certain distro, its something everyone is lacking to some degree, or in some area.

Naib wrote:
I am sure at some point some REALLY nasty update will pretty much force systemd on the general user so much so that the effort to not use it will be a massive detriment to the end-user. But that isn't now (wait till apache/nginx depends on sysd for instance ..)

I don't think it'll happen like that, its already the case that the majority of distributions are now supporting it (either as the default, or as an option) this means that the scales are weighed in favour of systemd, so it's more likely for things (dependencies of the "standard base system", etc) to gravitate in that direction. As for apache, nginx and other services these would be less likely to explicitly depend on systemd as they also have a footing in *BSD (including OS X), if they did there would mostly likely be a fork. The main strategy (for want of a better word) is to have the higher level DE components depend on it, and so gradually have the "users" (meaning those who's use is primarily in the form of a DE) depend on it being there for some functionality. That's more a process of adoption by stealth than a sudden "nasty update".

best ... khay
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3328
Location: The Peanut Gallery

PostPosted: Thu Jun 05, 2014 8:59 pm    Post subject: Reply with quote

I don't think anyone's being forced; pushed perhaps, and that's what I thought the whole point of systemd profiles was about. In any event, with respect to moving forward, how vital is upower to people, or does hibernate-script cover all the bases?

sys-power/hibernate-script http://www.tuxonice.net/ | Hibernate script supporting multiple suspend methods
alonbl has been maintaining it for gentoo so I'm just wondering if that's enough.

It would certainly be easy enough to maintain a upower fork; the commits aren't a massive long list at this stage, so review would start now. I don't use it, so can someone point out the commit/s which disable/s "sys-power/pm-utils support for hibernate/suspend"? since last on 0.9 branch: "2013-10-22 linux: Clamp percentage for overfull batteries"

Main thing I see is moving polling from daemon to backend (there are other commits involved), and then several commits that "use the daemon polling" which sounds a bit contradictory. Is the daemon not used for upower under openrc?

However if the only reason we're doing that is to support pm-utils, which is shell script, and there's a better option in hibernate-script, I'm tempted to stick with -upower -udisks et al when I install my laptop, assuming that's viable.

Just trying to get a handle on it all; info appreciated.
Back to top
View user's profile Send private message
patrix_neo
Guru
Guru


Joined: 08 Jan 2004
Posts: 384
Location: Svedala

PostPosted: Thu Jun 05, 2014 10:22 pm    Post subject: Reply with quote

mackal wrote:
patrix_neo wrote:
This was not in the news read and it fixed it for me.


That's because it shouldn't be needed. I'm guessing something on your system is set up in a way that causes issues (either something masked that shouldn't be or an older ebuild that needs to be updated [maybe in an overlay?])

I would recommend trying to figure out what is causing the issue and fixing it, it will probably cause more issues down the road for you is all.


And why is it that it need an other approach?
I use stable as much as it goes
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2946

PostPosted: Thu Jun 05, 2014 10:49 pm    Post subject: Reply with quote

steveL wrote:
However if the only reason we're doing that is to support pm-utils, which is shell script, and there's a better option in hibernate-script, I'm tempted to stick with -upower -udisks et al when I install my laptop, assuming that's viable. Just trying to get a handle on it all; info appreciated.

steve ... well, yes its just shell script, but its claim is to "standardise" and be "distribution agnostic" and so all manner of things (like upower) came to expect to operate with it in mind. So, DE's have some interface to change preferences, and buttons (or what-have-you) to 'suspend' or 'hibernate' that use pm-utils exclusively, and this is where the dependency actually exists. hibernate-script on the other hand was developed by the same person(s) who develop TuxOnIce and isn't integrated in a similar manner, you only have various config files under /etc/hibernate and two scripts 'hibernate' and 'hibernate-ram' (it does however work with both the in kernel uswsusp or out of kernel TuxOnIce).

To use hibernate-script you need to configure /etc/hibernate/* via the cli, and provide acpid with definitions of what button triggers hibernation (if you want that), but none of the DE's provide a means of working with it, rather than pm-utils (though I seem to remember some hackery posted on the ubuntu forums which uses hibernate-script via pm-utils).

Its been a long while since I looked at pm-utils so perhaps the situation has changed in that time, but that's unlikely, otherwise we would be advised to "use hibernate-script" in place of pm-utils.

As for kernel API changes mentioned, well, this just seems to be a red herring, there isn't likely to be a replacement for uswsusp nor any major changes that would suddenly, or drastically, effect userland (this is the kernel, not freedesktop, after all) it won't happen because ... well, look at all the bikeshedding re TuxOnIce (a far better implementation), uswsusp should have been replaced by TuxOnIce some time ago, but it didn't happen for two reasons 1). its a big change (and generally Linus is fairly conservative in that regard), and 2). those who didn't write it, but maintain that section of the code, didn't want it replaced. This tends to suggest things are moving rather slowly ... to put it mildly.

best ... khay
Back to top
View user's profile Send private message
schorsch_76
Apprentice
Apprentice


Joined: 19 Jun 2012
Posts: 225

PostPosted: Fri Jun 06, 2014 5:43 am    Post subject: Reply with quote

steveL wrote:
It would certainly be easy enough to maintain a upower fork; the commits aren't a massive long list at this stage, so review would start now. I don't use it, so can someone point out the commit/s which disable/s "sys-power/pm-utils support for hibernate/suspend"? since last on 0.9 branch: "2013-10-22 linux: Clamp percentage for overfull batteries"


I think this is the commit you look for: http://cgit.freedesktop.org/upower/commit/?h=systemd-suspend&id=b6dcab79ae3291fc39206ee5b81554292e6e43a5
Back to top
View user's profile Send private message
pygoscelis
Guru
Guru


Joined: 07 Jun 2003
Posts: 349

PostPosted: Fri Jun 06, 2014 7:13 am    Post subject: Reply with quote

Trying to emerge upower-pm-utils but this wants to pull in systemd.

Code:
emerge -p --oneshot --noreplace 'sys-power/upower-pm-utils'

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-apps/systemd-212-r5  USE="acl filecaps firmware-loader gudev introspection kmod pam (policykit) seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -python -qrcode (-selinux) (-ssl) {-test} -vanilla -xattr" ABI_X86="(64) (-32) (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python3_2 -python3_3" PYTHON_TARGETS="python2_7 python3_3 -python3_2"
[ebuild  N     ] sys-apps/gentoo-systemd-integration-4
[ebuild  N     ] virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios"
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-208)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-fs/udev-208::gentoo, installed) pulled in by
    >=sys-fs/udev-208[abi_x86_64(-),gudev,introspection,kmod] required by (virtual/udev-208-r1::gentoo, installed)

  (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-apps/systemd-208:0/2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs(-)?] (>=sys-apps/systemd-208:0/2[abi_x86_64(-),gudev,introspection]) required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge)
    >=sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge)


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked


Why?
_________________
!זה הכי, אחי Gentoo
Back to top
View user's profile Send private message
Naib
Advocate
Advocate


Joined: 21 May 2004
Posts: 4339
Location: Removed by Neddy

PostPosted: Fri Jun 06, 2014 7:25 am    Post subject: Reply with quote

Did you remove upower?
This sounds like a virtual is needed
_________________
the table is made from wood. forget what you learnt, the table is made from carbon. forget what you learnt, the table is made from protons. forget what you learnt, the table is made from quarks. forget what you learnt, the table is good for shagging on
Back to top
View user's profile Send private message
pygoscelis
Guru
Guru


Joined: 07 Jun 2003
Posts: 349

PostPosted: Fri Jun 06, 2014 7:53 am    Post subject: Reply with quote

Naib wrote:
Did you remove upower?
This sounds like a virtual is needed


I have unmerged upower, but the problem was the same before I did that.
I have emerged upower-pm-utils with --nodeps for the time being so I can continue to update world.
_________________
!זה הכי, אחי Gentoo
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3328
Location: The Peanut Gallery

PostPosted: Fri Jun 06, 2014 9:10 pm    Post subject: Reply with quote

khayyam wrote:
steveL wrote:
However if the only reason we're doing that is to support pm-utils, which is shell script, and there's a better option in hibernate-script, I'm tempted to stick with -upower -udisks et al when I install my laptop, assuming that's viable.

steve ... well, yes its just shell script, but its claim is to "standardise" and be "distribution agnostic" and so all manner of things (like upower) came to expect to operate with it in mind. So, DE's have some interface to change preferences, and buttons (or what-have-you) to 'suspend' or 'hibernate' that use pm-utils exclusively, and this is where the dependency actually exists.

Well I didn't say "just", I feel I must point out, and am sure my learned friend would understand that this is not pettiness. Pedantry, perhaps.. ;-)

If they're going to "standardise" they could at least avoid bashishms and unrobust sh.. It's not as bad as some, though it looks like it's been patched by an amateur (or amateurs) after the original author, which is why I'm asking now: which one do you want working? (see below.)

Although "this is where the dependency actually exists" makes me laugh, on so many levels. Not at you, ofc.
Quote:
hibernate-script on the other hand was developed by the same person(s) who develop TuxOnIce and isn't integrated in a similar manner, you only have various config files under /etc/hibernate and two scripts 'hibernate' and 'hibernate-ram' (it does however work with both the in kernel uswsusp or out of kernel TuxOnIce).

To use hibernate-script you need to configure /etc/hibernate/* via the cli, and provide acpid with definitions of what button triggers hibernation (if you want that), but none of the DE's provide a means of working with it, rather than pm-utils (though I seem to remember some hackery posted on the ubuntu forums which uses hibernate-script via pm-utils).

Its been a long while since I looked at pm-utils so perhaps the situation has changed in that time, but that's unlikely, otherwise we would be advised to "use hibernate-script" in place of pm-utils.

Hmm ISTR someone saying that pm-utils falls back to hibernate, but I can't find the posts (I had to an eix search to find hibernate-script at all.)

Whole thing sounds like spaghetti to me: I'd rather sort out the machine's ACPI buttons at install, making it obvious to the admin that we have done, and where to look. Though /etc/acpi appeals much more than /lib/fubar, /usr/lib/fubar and /var/lib/fubar in addition to /etc/fubar, plus the same round for some other bit of turgid integration, that is in fact just coopting long-standing projects, then crippling them so they only work with the rest of "our" brouha in a later "upgrade".
Quote:
As for kernel API changes mentioned, well, this just seems to be a red herring, there isn't likely to be a replacement for uswsusp nor any major changes that would suddenly, or drastically, effect userland (this is the kernel, not freedesktop, after all)

Lul, yeah so much of this seems like junior developers who cut their teeth learning about the kernel, and were then moved to less-demanding roles when it became clear that no-one in kernel-space likes their approach (apart from one documentation guy.) Trouble with that is they learn "userspace can do crazy things" and take it as some sort of methodology, instead of realising the wider version of Torvalds mantra:

"You do not break the consumer. EOD."

Keeping the pm-utils "API" isn't hard; and I quite like the script-running, then in reverse. So if you like we can just gut most of the crap and use the hibernate-script impl. Some of the warning info in the README (about data loss) sounds a bit worrying though, so I can understand why people just use what they're given, and would prefer you there to oversee soundness.

Likely easiest just to merge from "scratch", ime. Quoted because nothing is really from scratch: you always have an idea of what you want to happen, and usually an existing impl to replace, as in this case. We have excellent QA testers, after all :-)

Question is: if we have suspend, hibernate (and s2ram) on top of traditional shutdown/reboot, is that enough for people?

My gut tells me that's not my problem, as in: I'd be happy with just the above, so why worry about anything else? But my head tells me that I'm not the only (potential) user. It does sound like we can simply avoid upower though.
Back to top
View user's profile Send private message
ct85711
Apprentice
Apprentice


Joined: 27 Sep 2005
Posts: 279

PostPosted: Fri Jun 06, 2014 9:20 pm    Post subject: Reply with quote

The part I am wondering on, with upower-pm-utils is now unmaintained by upstream. Is it better off, if we just bite the bullet and not have hibernate & suspend or what? While this isn't too big of deal for me on XFCE right now; I'm more interested in the future on what will happen with upower-pm-utils, as I'd assume it would eventually be slotted for removal if it's not picked up by someone. Right now, from what I am seeing; I'm not having much faith in upower not having a direct dependency of systemd later on. So just sticking with >=upower-0.99 makes me more uncertain than anything.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3328
Location: The Peanut Gallery

PostPosted: Fri Jun 06, 2014 9:23 pm    Post subject: Reply with quote

schorsch_76 wrote:
steveL wrote:
It would certainly be easy enough to maintain a upower fork; the commits aren't a massive long list at this stage, so review would start now. I don't use it, so can someone point out the commit/s which disable/s "sys-power/pm-utils support for hibernate/suspend"? since last on 0.9 branch: "2013-10-22 linux: Clamp percentage for overfull batteries"


I think this is the commit you look for: http://cgit.freedesktop.org/upower/commit/?h=systemd-suspend&id=b6dcab79ae3291fc39206ee5b81554292e6e43a5

Ah thanks schorsch; yeah that'd do it.

Based on the description of the problem on dev ML (where to raise not breaking existing installs, means I am a complainer..) I assumed it was some change since the older version of upower in October 2013. Not one from July 2012.

Guess they just switched branches or something? Irrelevant to fixing it though, ofc. I won't be able to to dig into the code for a bit; the cursory review took an hour already and I'm backlogged atm. But by the sounds of it, we don't need to, in any case.

Again: if someone on openrc has real reasons for using upower, beyond suspend/hibernate, please tell us what that is, and why you need upower in the mix. I'm sure there are use-cases, I just don't know what they are, and don't particularly want to spend code time on it, if I can just help out with hibernate-utils.

I will however, if it's needed, since I feel sure it won't be just me who wants things working, so it's hardly going to be a solo effort.
If past experience is anything to go by, I won't have to do anything at all :-)
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3328
Location: The Peanut Gallery

PostPosted: Fri Jun 06, 2014 9:28 pm    Post subject: Reply with quote

Naib wrote:
Did you remove upower?
This sounds like a virtual is needed

What makes you think that?
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4566

PostPosted: Sat Jun 07, 2014 7:04 am    Post subject: Reply with quote

steveL wrote:
"You do not break the consumer. EOD."

Strictly speaking, the consumer is not broken: It is the backend which has changed, not the frontend. (Also in the linux kernel backends change rather frequently.)

In some sense upower's decision is understandable: If you have the choice between a backend which is unmaintained since years and an actively maintained backend, it is time to think about supporting the new backend. What is a worse decision is that support for the older backend has been dropped; this would also be understandable if it would be a lot of work to maintain it, but it seems to be only a few lines of code. A little change in the configure script to support both would not have been a big deal.

Quote:
if someone on openrc has real reasons for using upower, beyond suspend/hibernate

Maybe I misunderstand, but isn't the main purpose of upower to report the status of power device like battery state or UPS (is nut actually supported by upower?) And suspend/hibernate is only an independent feature for which upower does not much more than checking permissions with policykit and calling the backend?

(I conjecture this just from the decsripion on the upower homepage, so maybe my impression is completely wrong.)

If my impression is right, it would be great if actually the full suspend/hibernate part could be decoupled: Then one could use upower for what it actually was made for without policykit/systemd/anything else.
Back to top
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2552
Location: Austria

PostPosted: Sat Jun 07, 2014 9:53 am    Post subject: Reply with quote

So yesterday I finally made the switch:
Code:
emerge -C upower && emerge -1 upower-pm-utils

Easy.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Budoka
Guru
Guru


Joined: 03 Jun 2012
Posts: 482
Location: Tokyo, Japan

PostPosted: Tue Jun 10, 2014 2:08 am    Post subject: Reply with quote

Thanks everyone. Removing upower and replacing it with upower-pm-utils resolved it for me but I must agree that as a user I would have never figured that out with the forums given the news item was released after the fact.

My immediate problem has been resolved but given the wealth of information in this thread I won't tag it as "solved" unless advised otherwise.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3328
Location: The Peanut Gallery

PostPosted: Tue Jun 10, 2014 3:40 am    Post subject: Reply with quote

mv wrote:
steveL wrote:
"You do not break the consumer. EOD."

Strictly speaking, the consumer is not broken: It is the backend which has changed, not the frontend. (Also in the linux kernel backends change rather frequently.)

That comment was not in reference to this specific case; it was in response to "kernel API changes mentioned [which] just seems to be a red herring.. this is the kernel, not freedesktop, after all." The kernel does not break userspace, and kernel devs expect userspace to do crazy things. It seems to me like what we have are kernel rejects, who couldn't handle the first, and who've taken the latter as some sort of license to break whatever they like, since this is userspace. I would never trust them to maintain an ABI contract, for a start, based on the history of the codebases, and that has only been exacerbated by the underhand manner with which they coopt other people's work, then cripple it so no-one else can still use it. "Gentle" pushes and all that.

I'd go so far as to label this a variant on Microsoft's behaviour: "Embrace, cripple, extinguish" (the competition.)
Quote:
A little change in the configure script to support both would not have been a big deal.

Exactly. Just as it would have been easy to keep udev building on its own, but patches were rejected (after the project had been coopted and crippled: it always used to build on its own) because they don't fit with the "vision" of the upstream.

No offence but anyone talking about "vision" in computing has got to be a management nuspeek wannabe, afaic. I'd much rather talk about design, which this ain't on a CS level: only at a business level.
Quote:
Maybe I misunderstand, but isn't the main purpose of upower to report the status of power device like battery state or UPS (is nut actually supported by upower?) And suspend/hibernate is only an independent feature for which upower does not much more than checking permissions with policykit and calling the backend?

(I conjecture this just from the decsripion on the upower homepage, so maybe my impression is completely wrong.)

No idea, I don't use the thing. It used to be installed by default, but I got rid of it when I dumped nubkit thanks to Dominique's how-to.
Quote:
If my impression is right, it would be great if actually the full suspend/hibernate part could be decoupled: Then one could use upower for what it actually was made for without policykit/systemd/anything else.

Heh: well I'm up for the former. Thanks for letting us know about battery and UPS-monitoring. Do you think it's viable to do what you suggest given what is going on with upower? It's effectively a systemd module now, afaict.

I don't have a UPS anymore, though I wish I hadn't thrown that old one away now. (It just seemed really heavy, and didn't have any USB capability anyhow. But it really helped with power blinkage.) But they're both areas that need to be addressed; istr lots of applets for battery status over the years, so that can't be too hard, though idk anything about it ofc :-)

Again, info appreciated.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4566

PostPosted: Tue Jun 10, 2014 6:42 am    Post subject: Reply with quote

steveL wrote:
Do you think it's viable to do what you suggest given what is going on with upower?

I have no idea: I never looked at the full sourcecode/detailed documentation to see what upower actually does; this was pure speculation based on the description of the main website and the commits which were posted here. Certainly, I will not have the time and interest to maintain an upower fork; it is not even clear whether I would have a use for it if somebody else does, but I expect several people woiuld have such a use: After all, since systemd supports "systemctl susdpend/hibernate" and also pm-utils has its own pm-{suspdend,hibernate} commands, everybody who has a use for upower probably only has it because of its other features.
Back to top
View user's profile Send private message
schorsch_76
Apprentice
Apprentice


Joined: 19 Jun 2012
Posts: 225

PostPosted: Tue Jun 10, 2014 6:53 am    Post subject: Reply with quote

I had a relativly short look into the upower sources. upower seems to hook into dbus and accept the dbus commands to execute the suspend/hibernate/whatever. (Ok, check policykit for permission.) After i have thought about this, i think the whole dbus/upower/udisk architecture is classic unix style (one thing for one task) to seperate the call to the hibernate/whatever command from the application. So there is only one point in the whole system which calls this scripts. The other upower features i haven't looked at.

From my point of view, there is no real reason why this "old" upower should not work in the future. The kernel API is really stable and dont change a lot.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3328
Location: The Peanut Gallery

PostPosted: Tue Jun 10, 2014 8:22 am    Post subject: Reply with quote

mv wrote:
I never looked at the full sourcecode/detailed documentation to see what upower actually does; this was pure speculation based on the description of the main website and the commits which were posted here. Certainly, I will not have the time and interest to maintain an upower fork; it is not even clear whether I would have a use for it

Fair enough.
Quote:
..but I expect several people woiuld have such a use: After all, since systemd supports "systemctl susdpend/hibernate" and also pm-utils has its own pm-{suspdend,hibernate} commands, everybody who has a use for upower probably only has it because of its other features.

Yes, everybody who has such a use: many don't, but have it installed by default. So let's do the simple use-cases first; as you say suspend and hibernate have been around for a while now, though I've never liked the idea myself, so don't have any knowledge.

It's certainly easy enough to either continue patching pm-utils, and/or improve hibernate if that is desired, from a scripting pov.
schorsch_76 wrote:
I had a relativly short look into the upower sources. upower seems to hook into dbus and accept the dbus commands to execute the suspend/hibernate/whatever. (Ok, check policykit for permission.) After i have thought about this, i think the whole dbus/upower/udisk architecture is classic unix style (one thing for one task) to seperate the call to the hibernate/whatever command from the application. So there is only one point in the whole system which calls this scripts. The other upower features i haven't looked at.

It's more of a design issue: why do you want random apps able to suspend or hibernate the machine? To my mind that's best handled at DE level, and isn't a concern of apps. The most that would be is the ability to say "don't suspend while running a video" or w/e and again that's much better handled at DE level as well, so the user can decide/configure which apps get that permission.

It doesn't have anything to do with an app asking to suspend the machine though, which I find a very odd concept.
Quote:
From my point of view, there is no real reason why this "old" upower should not work in the future. The kernel API is really stable and dont change a lot.

Yes, so we might as well just use that, from the DE, imo; with hooks ofc, should the user require them.

What about battery status? Is that just acpi or something more?
Back to top
View user's profile Send private message
schorsch_76
Apprentice
Apprentice


Joined: 19 Jun 2012
Posts: 225

PostPosted: Tue Jun 10, 2014 9:04 am    Post subject: Reply with quote

About the battery status i have not yet looked about it....

It is not that upower hiberantes by itself, it hooks into dbus, that other applications can use it. Other applications like a DE. Just take look at yourself, it is not very difficult to understand.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3328
Location: The Peanut Gallery

PostPosted: Tue Jun 10, 2014 2:20 pm    Post subject: Reply with quote

schorsch_76 wrote:
It is not that upower hiberantes by itself, it hooks into dbus, that other applications can use it. Other applications like a DE. Just take look at yourself, it is not very difficult to understand.

I'd rather not, unless it's the only way to understand what it does. If other apps = DE, is there any other app you think should have the ability to do that?

If so, why would a simple command be inappropriate?
Back to top
View user's profile Send private message
schorsch_76
Apprentice
Apprentice


Joined: 19 Jun 2012
Posts: 225

PostPosted: Tue Jun 10, 2014 4:37 pm    Post subject: Reply with quote

steveL wrote:
schorsch_76 wrote:
It is not that upower hiberantes by itself, it hooks into dbus, that other applications can use it. Other applications like a DE. Just take look at yourself, it is not very difficult to understand.

I'd rather not, unless it's the only way to understand what it does. If other apps = DE, is there any other app you think should have the ability to do that?

If so, why would a simple command be inappropriate?

Good question. I cant answer it, because i wasn't involved at the design. As far as i understand it, they wanted to put polkit between the command and the execution of the actual hibernate command (from every point where it could be called from the system). As far as i understand polkit, it should provide a better right management than standard groups (but dont ask me if it is better or not). I actually dont know any permission thing which could not be managed by groups or ACL's from the kernel. Maybe some other person has more insight into polkit.

From my point of view, they wanted to control the whole system through dbus and control user sessions with consolekit and permissions with polkit.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2788

PostPosted: Tue Jun 10, 2014 6:14 pm    Post subject: Reply with quote

schorsch_76 wrote:
steveL wrote:
schorsch_76 wrote:
It is not that upower hiberantes by itself, it hooks into dbus, that other applications can use it. Other applications like a DE. Just take look at yourself, it is not very difficult to understand.

I'd rather not, unless it's the only way to understand what it does. If other apps = DE, is there any other app you think should have the ability to do that?

If so, why would a simple command be inappropriate?

Good question. I cant answer it, because i wasn't involved at the design. As far as i understand it, they wanted to put polkit between the command and the execution of the actual hibernate command (from every point where it could be called from the system). As far as i understand polkit, it should provide a better right management than standard groups (but dont ask me if it is better or not). I actually dont know any permission thing which could not be managed by groups or ACL's from the kernel. Maybe some other person has more insight into polkit.

From my point of view, they wanted to control the whole system through dbus and control user sessions with consolekit and permissions with polkit.


I believe the goal here is to confer rights on the console user, not on any specific user. So individual users have no console rights, the DE knows who is at the console, and consolekit/polkit do the privileged stuff on their behalf. At that point I might have to agree that using dbus as the communications medium, but maybe not. At first blush command-line options seem more subject to abuse than dbus messages. But then again, that belief is itself security-by-obscurity, since I'm sure some sort of malware could come out that issues dbus messages to do its dirty work. If the people listening to dbus to do stuff like this think that they're safe, then they are very likely not.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5 ... 18, 19, 20  Next
Page 4 of 20

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum