Testing can be done by compiling some stable power managers against this version. If you don't see compile-time problems, there likely won't be runtime problem either (except that of retired suspend/hibernate, and users of those features have been moved to sys-power/upower-pm-utils) So, test and stabilize: =sys-power/upower-0.99.0-r1
Ooops, I was planning to stabilize this in conjuntion with gnome 3.10 and mate 1.8 that will make use of it :/, but if you prefer upower-0.99 sooner...
(In reply to Pacho Ramos from comment #1) > Ooops, I was planning to stabilize this in conjuntion with gnome 3.10 and > mate 1.8 that will make use of it :/, but if you prefer upower-0.99 sooner... Yes, sooner, because qa@g.o broke the gentoo-x86 tree for stable systemd users[1] for which this stabilization is a fix to. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/base/package.mask?r1=1.64&r2=1.65 So, in fact, raising severity too...
(In reply to Samuli Suominen from comment #2) > (In reply to Pacho Ramos from comment #1) > > Ooops, I was planning to stabilize this in conjuntion with gnome 3.10 and > > mate 1.8 that will make use of it :/, but if you prefer upower-0.99 sooner... > > Yes, sooner, because qa@g.o broke the gentoo-x86 tree for stable systemd > users[1] for which this stabilization is a fix to. > > [1] > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/base/ > package.mask?r1=1.64&r2=1.65 > > So, in fact, raising severity too... I just love how this mask has been in place for nearly two weeks and this is literally the first I'm hearing of how I "broke the gentoo-x86 tree". Honestly, if you learned even the smallest communications skills I would be happy to work with you, but instead you seem content to work around me. Your call, but if you drop the dime I will pick up and listen.
the mask wrongly points all openrc users to upower-pm-utils, preventing them from getting incremental upgrades of upower. the mask annoyingly adds extra step of unmasking perfectly working version to systemd users. the mask message wasn't vetted in ML like the news item was. the mask was put in tree without consulting the package maintainers. so yeah, the mask should be reverted immediately, as there is nothing that can be improved in tree in this way, as the situation is not as simple as you wrote in the mask message. amd64/arm/x86 stable, so at least users who haven't upgraded yet, will not be moving to upower-pm-utils pointlessly
(In reply to Samuli Suominen from comment #4) > the mask wrongly points all openrc users to upower-pm-utils, preventing them > from getting incremental upgrades of upower. The mask purposely didn't include >=0.99 because I recalled you saying that everyone would be able to use that. If the mask is improperly masking more than I intended, I'm happy to amend it. >the mask annoyingly adds extra > step of unmasking perfectly working version to systemd users. Yes, unfortunately it seems that a lot of systemd users aren't using the systemd profile. I pointed them to it and suggested it, but I'd imagine the ones who aren't didn't find the mask all that difficult to fix. >the mask > message wasn't vetted in ML like the news item was. the mask was put in tree > without consulting the package maintainers. Yes, unfortunately you were unavailable during the discussion. Honestly, I wish you would have considered having a virtual or transitional package like creffett originally suggested, but since that was refused this was the only way I could find to make portage navigate the dep tree without blockers for the majority of gentoo users (openrc users) > so yeah, the mask should be reverted immediately, as there is nothing that > can be improved in tree in this way, as the situation is not as simple as > you wrote in the mask message. Sorry, but that's not happening unless you come up with a better transitional technique. I am completely open to anything that prevents blockers for the highest percentage of users physically possible. My way blocks less users than yours did, and if we can further improve in any way I'm all ears. > > amd64/arm/x86 stable, so at least users who haven't upgraded yet, will not > be moving to upower-pm-utils pointlessly Well, yes and know, as I recall only some power managers like xfce were able to work with the new upower right? So a lot of users who are migrating are sadly not doing so "pointlessly". Even still, if the dep tree is right, users should end up with "the correct package", be it upower-pm-utils or upower. Again, if we can improve the situation, I'm happy to do that. We can continue to bloat your stablereq bug, or you can email myself or QA directly. I am open to improvements, but "reverting the mask immediately" would be the opposite of that, so if you like, we can try to find a way to help all users, or at least a higher percentage.
ppc* stable (compile test only)
Just an FYI re: > Yes, unfortunately it seems that a lot of systemd users aren't using the systemd > profile. I pointed them to it and suggested it, but I'd imagine the ones who > aren't didn't find the mask all that difficult to fix. The systemd profiles only cover KDE and Gnome desktops. No XFCE. No servers. No embedded.
You can follow-up the broken behavior of Portage in bug 515230 -- the systemd profiles, or `emerge` pulling in wrong provider from simple || ( ) construct doesn't belong here alpha/ia64/sparc: continue with the stabilization as normal
I thought I'd provide my two cents regarding a comment *here* providing my reason for not using the systemd profiles.
Will handle the remaining arches in parent bug as it's preferred by Ago and this can wait for those arches until the rest is done *** This bug has been marked as a duplicate of bug 512012 ***
