[gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

UPower upstream removed sys-power/pm-utils support from 0.99 release
(currently unkeyworded in tree),
as in, from current git master.
UPower upstream created 0.9 bit branch that has the old legacy upower
with sys-power/pm-utils support
available still with --enable-deprecated.

So, sys-power/upower will move on to 0.99 and is, thus, mostly usable
only for sys-apps/systemd users,
however, Xfce upstream in git master already moved the
sys-power/pm-utils code that upower had
over directly to the apps, like xfce4-session and xfce4-power-manager,
and will, after next releases,
still work without sys-apps/systemd even with 0.99 version.

What was done?

sys-power/upower-pm-utils was created where we will maintain upower 0.9
git branch, currently it's identical
to =sys-power/upower-0.9.23-r2, but will soon be a git snapshot instead.

What needs to be done before we can keyword >=sys-power/upower-0.99?

See examples of uevt, wmbattery, xfce4-session, xfce4-settings,
xfce4-power-manager, xfce4-systemload-plugin,
xfce4-weather-plugin which I already converted (mostly) from this list:

http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-power/upower

Other are all undone, as in, converting deps to what they actually support:

|| ( sys-power/upower sys-power/upower-pm-utils ) where everything is
supported
|| ( <sys-power/upower-0.99 sys-power/upower-pm-utils ) where only
upower with pm-utils is supported
>=sys-power/upower-0.99 where new API is mandatory, currently this would
only be >= GNOME 3.12 stuff
well, figure it out, these are just examples

Confusing bug 508920 also exists, but most of the conversation there is
outdated

I'm going to spinal surgery this friday, and I propably don't have
health, time, or motivation to open a Tracker
bug and file all the bugs for the reverse deps this week at all.
Thus, I propably won't be working on this much this week at all. Things
are OK as they are now in Portage,
because >=sys-power/upower-0.99 is not keyworded yet, so nothing is
broken, it's just work undone.

I know GNOME folks want to get it done, because GNOME 3.12 stuff
actually needs upower-0.99, but I'm
saying they can NOT keyword the version without fixing rest of the tree
before doing so as described
above. So help me out, or wait it out (like 2 weeks).

Thanks,
Samuli

[gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

Note: If you want to convert your ebuild, you can /msg ssuominen on
Freenode and
post an ebuild diff, I can quickly review if the dependency changes are
OK for you,
or clarify anything else you want regarding this.

Sorry, I know this unorthodox workflow, but I'm too sick to even
properly sit in the
chair currently, and people keep poking me regarding the issue, over any
other issues ;-(

On 26/05/14 23:15, Samuli Suominen wrote:
> UPower upstream removed sys-power/pm-utils support from 0.99 release
> (currently unkeyworded in tree),
> as in, from current git master.
> UPower upstream created 0.9 bit branch that has the old legacy upower
> with sys-power/pm-utils support
> available still with --enable-deprecated.
>
> So, sys-power/upower will move on to 0.99 and is, thus, mostly usable
> only for sys-apps/systemd users,
> however, Xfce upstream in git master already moved the
> sys-power/pm-utils code that upower had
> over directly to the apps, like xfce4-session and xfce4-power-manager,
> and will, after next releases,
> still work without sys-apps/systemd even with 0.99 version.
>
> What was done?
>
> sys-power/upower-pm-utils was created where we will maintain upower 0.9
> git branch, currently it's identical
> to =sys-power/upower-0.9.23-r2, but will soon be a git snapshot instead.
>
> What needs to be done before we can keyword >=sys-power/upower-0.99?
>
> See examples of uevt, wmbattery, xfce4-session, xfce4-settings,
> xfce4-power-manager, xfce4-systemload-plugin,
> xfce4-weather-plugin which I already converted (mostly) from this list:
>
> http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-power/upower
>
> Other are all undone, as in, converting deps to what they actually support:
>
> || ( sys-power/upower sys-power/upower-pm-utils ) where everything is
> supported
> || ( <sys-power/upower-0.99 sys-power/upower-pm-utils ) where only
> upower with pm-utils is supported
>> =sys-power/upower-0.99 where new API is mandatory, currently this would
> only be >= GNOME 3.12 stuff
> well, figure it out, these are just examples
>
> Confusing bug 508920 also exists, but most of the conversation there is
> outdated
>
> I'm going to spinal surgery this friday, and I propably don't have
> health, time, or motivation to open a Tracker
> bug and file all the bugs for the reverse deps this week at all.
> Thus, I propably won't be working on this much this week at all. Things
> are OK as they are now in Portage,
> because >=sys-power/upower-0.99 is not keyworded yet, so nothing is
> broken, it's just work undone.
>
> I know GNOME folks want to get it done, because GNOME 3.12 stuff
> actually needs upower-0.99, but I'm
> saying they can NOT keyword the version without fixing rest of the tree
> before doing so as described
> above. So help me out, or wait it out (like 2 weeks).
>
> Thanks,
> Samuli

Re: [gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

Dnia 2014-05-26, o godz. 23:15:34
Samuli Suominen <ssuominen@gentoo.org> napisał(a):

> UPower upstream removed sys-power/pm-utils support from 0.99 release
> (currently unkeyworded in tree), as in, from current git master.

Don't worry. Looking at the past, I can guess this is only a temporary
inconvenience. I'm pretty sure upower will be discontinued soon
and replaced with systemd-powerd or something :D.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 27/05/14 08:34, Michał Górny wrote:
> Dnia 2014-05-26, o godz. 23:15:34
> Samuli Suominen <ssuominen@gentoo.org> napisał(a):
>
>> UPower upstream removed sys-power/pm-utils support from 0.99 release
>> (currently unkeyworded in tree), as in, from current git master.
> Don't worry. Looking at the past, I can guess this is only a temporary
> inconvenience. I'm pretty sure upower will be discontinued soon
> and replaced with systemd-powerd or something :D.
>

That's more or less what they already did, they forced eg.
xfce4-power-manager upstream
to move the deleted pm-utils code from upower directly to the power
manager (application)
itself, likewise for xfce4-session
Which means applications will now need to duplicate the pm-utils related
code per application
basis
So I expect upower to be more or less dead for everything but systemd
users, except for
those upstreams that will actually follow the Xfce path and do the
duplication
Yet, still, small portition of the code is still 'generic', so
xfce4-power-manager will still need
both, upower, even 0.99, and then pm-utils, depending on the version,
codepath is selected

This was sort of expected, since pm-utils has been abandoned for ~5
years now at upstream,
so nobody is maintaining non-systemd related power management tools
anymore, and
falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be
necessary again,
it's like going back to 90s for non-systemd users :P

- Samuli

[gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Steven J. Long]

On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote:
> 
> On 27/05/14 08:34, Michał Górny wrote:
> > Dnia 2014-05-26, o godz. 23:15:34
> > Samuli Suominen <ssuominen@gentoo.org> napisał(a):
> >
> >> UPower upstream removed sys-power/pm-utils support from 0.99 release
> >> (currently unkeyworded in tree), as in, from current git master.
> > Don't worry. Looking at the past, I can guess this is only a temporary
> > inconvenience. I'm pretty sure upower will be discontinued soon
> > and replaced with systemd-powerd or something :D.
> >
> 
> That's more or less what they already did, they forced eg.
> xfce4-power-manager upstream
> to move the deleted pm-utils code from upower directly to the power
> manager (application)
> itself, likewise for xfce4-session
> Which means applications will now need to duplicate the pm-utils related
> code per application
> basis
> So I expect upower to be more or less dead for everything but systemd
> users, except for
> those upstreams that will actually follow the Xfce path and do the
> duplication
> Yet, still, small portition of the code is still 'generic', so
> xfce4-power-manager will still need
> both, upower, even 0.99, and then pm-utils, depending on the version,
> codepath is selected
> 
> This was sort of expected, since pm-utils has been abandoned for ~5
> years now at upstream,
> so nobody is maintaining non-systemd related power management tools
> anymore, and
> falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be
> necessary again,
> it's like going back to 90s for non-systemd users :P

I can't believe I'm reading that from a distro-developer. Basically this
entire thread is "systemd is deprecating the existing tools, so let's dump
them and half our userbase back to the 90s, isn't that a great thing?"

I speak now only so that we don't get told a year later "you had your chance,
too late now." So in that light, what packages besides current pm-utils, do
people who don't use systemd, need to keep running after the putsch? Do any
of them go away as requirements if we don't use *kit? Eg if we don't use
udisks and upower already, but do use udev or eudev (likely what we'll switch
to given current state of play.)

Especially if we don't want to reduplicate a lib across several apps, as you
outlined above; somehow it smells.

Hope your operation went well,
steveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 31/05/14 05:47, Steven J. Long wrote:
> On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote:
>> On 27/05/14 08:34, Michał Górny wrote:
>>> Dnia 2014-05-26, o godz. 23:15:34
>>> Samuli Suominen <ssuominen@gentoo.org> napisał(a):
>>>
>>>> UPower upstream removed sys-power/pm-utils support from 0.99 release
>>>> (currently unkeyworded in tree), as in, from current git master.
>>> Don't worry. Looking at the past, I can guess this is only a temporary
>>> inconvenience. I'm pretty sure upower will be discontinued soon
>>> and replaced with systemd-powerd or something :D.
>>>
>> That's more or less what they already did, they forced eg.
>> xfce4-power-manager upstream
>> to move the deleted pm-utils code from upower directly to the power
>> manager (application)
>> itself, likewise for xfce4-session
>> Which means applications will now need to duplicate the pm-utils related
>> code per application
>> basis
>> So I expect upower to be more or less dead for everything but systemd
>> users, except for
>> those upstreams that will actually follow the Xfce path and do the
>> duplication
>> Yet, still, small portition of the code is still 'generic', so
>> xfce4-power-manager will still need
>> both, upower, even 0.99, and then pm-utils, depending on the version,
>> codepath is selected
>>
>> This was sort of expected, since pm-utils has been abandoned for ~5
>> years now at upstream,
>> so nobody is maintaining non-systemd related power management tools
>> anymore, and
>> falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be
>> necessary again,
>> it's like going back to 90s for non-systemd users :P
> I can't believe I'm reading that from a distro-developer. Basically this
> entire thread is "systemd is deprecating the existing tools, so let's dump
> them and half our userbase back to the 90s, isn't that a great thing?"

Then you misunderstood. Notice the ":P" as an indicator of sarcasm.
I've already created sys-power/upower-pm-utils where the sys-power/pm-utils
0.9 git branch will continue to live.

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[J. Roeleveld]

On Saturday, May 31, 2014 02:17:32 PM Samuli Suominen wrote:
> On 31/05/14 05:47, Steven J. Long wrote:
> > On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote:
> >> On 27/05/14 08:34, Michał Górny wrote:
> >>> Dnia 2014-05-26, o godz. 23:15:34
> >>> 
> >>> Samuli Suominen <ssuominen@gentoo.org> napisał(a):
> >>>> UPower upstream removed sys-power/pm-utils support from 0.99 release
> >>>> (currently unkeyworded in tree), as in, from current git master.
> >>> 
> >>> Don't worry. Looking at the past, I can guess this is only a temporary
> >>> inconvenience. I'm pretty sure upower will be discontinued soon
> >>> and replaced with systemd-powerd or something :D.
> >> 
> >> That's more or less what they already did, they forced eg.
> >> xfce4-power-manager upstream
> >> to move the deleted pm-utils code from upower directly to the power
> >> manager (application)
> >> itself, likewise for xfce4-session
> >> Which means applications will now need to duplicate the pm-utils related
> >> code per application
> >> basis
> >> So I expect upower to be more or less dead for everything but systemd
> >> users, except for
> >> those upstreams that will actually follow the Xfce path and do the
> >> duplication
> >> Yet, still, small portition of the code is still 'generic', so
> >> xfce4-power-manager will still need
> >> both, upower, even 0.99, and then pm-utils, depending on the version,
> >> codepath is selected
> >> 
> >> This was sort of expected, since pm-utils has been abandoned for ~5
> >> years now at upstream,
> >> so nobody is maintaining non-systemd related power management tools
> >> anymore, and
> >> falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be
> >> necessary again,
> >> it's like going back to 90s for non-systemd users :P
> > 
> > I can't believe I'm reading that from a distro-developer. Basically this
> > entire thread is "systemd is deprecating the existing tools, so let's dump
> > them and half our userbase back to the 90s, isn't that a great thing?"
> 
> Then you misunderstood. Notice the ":P" as an indicator of sarcasm.
> I've already created sys-power/upower-pm-utils where the sys-power/pm-utils
> 0.9 git branch will continue to live.

Would have been nice to fix all the dependencies BEFORE marking the systemd-
depending "sys-power/upower-pm-utils" stable.

--
Joost

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 14:40, J. Roeleveld wrote:
> Would have been nice to fix all the dependencies BEFORE marking the
> systemd- depending "sys-power/upower-pm-utils" stable. -- Joost 

No clue what you mean, sys-power/upower-pm-utils doesn't depend on
sys-apps/systemd,
and whole Portage tree is converted to proper dependencies and the
conversion went in
the correct steps.
If you need support for understanding Portage's output, try the
gentoo-user mailing list.

- Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Rich Freeman]

On Tue, Jun 3, 2014 at 7:25 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>
> On 03/06/14 14:40, J. Roeleveld wrote:
>> Would have been nice to fix all the dependencies BEFORE marking the
>> systemd- depending "sys-power/upower-pm-utils" stable. -- Joost
>
> No clue what you mean, sys-power/upower-pm-utils doesn't depend on
> sys-apps/systemd,
> and whole Portage tree is converted to proper dependencies and the
> conversion went in
> the correct steps.
> If you need support for understanding Portage's output, try the
> gentoo-user mailing list.

This probably could have used a news item, as the change impacts both
stable and ~arch users.  They need to do an "emerge -1
sys-power/upower-pm-utils" to actually get the new package, otherwise
portage is going to try to switch them from udev to systemd, since
packages like kdelibs list upower first, and portage has no way of
knowing that this is a big change.

I posted the same on -user...

Rich

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Tue, 3 Jun 2014 07:35:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> This probably could have used a news item, as the change impacts both
> stable and ~arch users.

Are we going to write a news item every time systemd acquires a new
mandatory relationship with a reverse dependency?

> They need to do an "emerge -1 sys-power/upower-pm-utils" to actually
> get the new package,

But the user doesn't want systemd; so, then why does the user have to
perform a manual step every time that systemd has an acquirement?

> otherwise portage is going to try to switch them from udev to
> systemd,

There is the problem, the user doesn't want systemd; so, why is Portage
(regardless of a systemd mask) trying to bring it to the user anyway?

> since packages like kdelibs list upower first, and portage
> has no way of knowing that this is a big change.

And this is where you can make Portage smarter.

http://www.funtoo.org/Flavors_and_Mix-ins

We don't have to go through all this if you had a "no-systemd" mix-in,
where you could simply make out the choices in favor of the user
instead of having to document and announce them all over the place.

That mix-in could do something like masking the new upower that
depends on systemd; when doing so, no more blockers all over the place.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 15:08, Tom Wijsman wrote:
> On Tue, 3 Jun 2014 07:35:42 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> This probably could have used a news item, as the change impacts both
>> stable and ~arch users.
> Are we going to write a news item every time systemd acquires a new
> mandatory relationship with a reverse dependency?

IMHO, not every singular dependency change (even blocker) needs one.
For those failing to read `eix upower` or `emerge -C upower` or masking
systemd, or number of other ways the blocker can be solved, the answer
is in Gentoo news letter, forums, first hits in Google, /topic of #gentoo at
Freenode, MLs, pretty much everywhere.

But news item has been planned all along for when UPower 0.99.0 goes
stable, propably
GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to
accumulate as news worthy.

- Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]

On Tue, 03 Jun 2014 15:24:22 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 03/06/14 15:08, Tom Wijsman wrote:
> > On Tue, 3 Jun 2014 07:35:42 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >
> >> This probably could have used a news item, as the change impacts
> >> both stable and ~arch users.
> > Are we going to write a news item every time systemd acquires a new
> > mandatory relationship with a reverse dependency?
> 
> IMHO, not every singular dependency change (even blocker) needs one.

Regardless of that, most acquirements have lead to a news item.

> For those failing to read `eix upower`

That command doesn't tell anything helpful for this blocker.

> or `emerge -C upower`

For that you need to already know that you have to unmerge upower; it is
also not going to help anything in terms of dependency calculation,
except for a small amount of users that might have selected it.

> or masking systemd,

Masking systemd has the same effect as having udev selected; so, taking
this action has zero effect and results in the blocker to still be
there. The output has perhaps changed a little, the idea is the same.

> or number of other ways the blocker can be solved,

There is the problem, new Gentoo users can't solve it; that's why it's
all over the place, as you've mentioned below. And some of it contains
misinformation, like the gentoo-user thread you have responded to.

Why do the users need to keep solving these nasty blockers?

You could solve it if you use --tree --unordered-display; go through
the dependency chain to check the reverse dependencies, write down what
is going on and finally come to the conclusion of it all. But how are
new users supposed to know all that?

Why is --tree --unordered-display still not a default?

In other words, why is the list of packages still flat by default?

> the answer is in Gentoo news letter,

Hidden somewhere in the middle, assuming users read about the update.

> forums,

As long as the activity of these topics last.

> first hits in Google,

Nothing found when I search for things like gentoo systemd blocker.

> /topic of #gentoo at Freenode, MLs, pretty much everywhere.

Which amounts to only a certain share of the users.

> But news item has been planned all along for when UPower 0.99.0 goes
> stable, propably
> GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to
> accumulate as news worthy.

Your reply doesn't answer the posed questions; instead, it demonstrates
that it costs a lot more human resources the way we do things now.

Users have to figure it out the hard way, developers then have to
bring out the news the hard way; just like most of the previous times.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Rich Freeman]

On Tue, Jun 3, 2014 at 8:24 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 03/06/14 15:08, Tom Wijsman wrote:
>> On Tue, 3 Jun 2014 07:35:42 -0400
>> Rich Freeman <rich0@gentoo.org> wrote:
>>
>>> This probably could have used a news item, as the change impacts both
>>> stable and ~arch users.
>> Are we going to write a news item every time systemd acquires a new
>> mandatory relationship with a reverse dependency?
>
> IMHO, not every singular dependency change (even blocker) needs one.
> For those failing to read `eix upower` or `emerge -C upower` or masking
> systemd, or number of other ways the blocker can be solved, the answer
> is in Gentoo news letter, forums, first hits in Google, /topic of #gentoo at
> Freenode, MLs, pretty much everywhere.

The whole point of news is to tell people about an action they need to
take before they have to take it.  The output of portage doesn't
really tell you what is going on.

The article in GMN doesn't provide clear instructions on what needs to
be done, and refers to 0.99.0 when the issue impacts 0.9.23 as well.

>
> But news item has been planned all along for when UPower 0.99.0 goes
> stable, propably
> GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to
> accumulate as news worthy.

This has already hit stable.  The dependency on systemd is present in
sys-power/upower-0.9.23-r3, which was just stablized.

Rich

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On Tue, 3 Jun 2014 09:04:23 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> The whole point of news is to tell people about an action they need to
> take before they have to take it.  The output of portage doesn't
> really tell you what is going on.

Note that I'm not against a news item in the short term; what I am
suggesting with mix-ins is even a step before that, but that's
something only achievable in the long term and of course not now.

So, yes, please write and send a news item out as soon as possible.

> The article in GMN doesn't provide clear instructions on what needs to
> be done, and refers to 0.99.0 when the issue impacts 0.9.23 as well.

Besides that, a longer title would help; currently it reads to me like
"X update", which means that if I don't care about X or don't know X
that I'm very likely to skip it. Mentioning systemd somewhere in there,
as well as "transition"; could help with drawing attention to it.

But given a news item, this GMN entry would become less important;
regardless, it can help for those that manage to skip reading the item.

> This has already hit stable.  The dependency on systemd is present in
> sys-power/upower-0.9.23-r3, which was just stablized.

Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; in
comparison, 0.99.0 mainly wants you to run it with systemd:

  26 May 2014; Samuli Suominen <ssuominen@gentoo.org>
  upower-0.99.0.ebuild: This release is mainly for use with
  sys-apps/systemd because upstream removed support for
  sys-power/pm-utils completely from git master. The 0.9 branch is for
  sys-power/pm-utils use. Adjust ebuild accordingly.

Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency;
I thought it had one, but maybe it is in another package I'm unaware of.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 16:20, Tom Wijsman wrote:
>> This has already hit stable.  The dependency on systemd is present in
>> sys-power/upower-0.9.23-r3, which was just stablized.
> Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag;

No, it doesn't.

>  in comparison, 0.99.0 mainly wants you to run it with systemd:

"mainly", as in, since 0.99.0 removed support for hibenate/suspend
in favour of systemd, the power/session managers need to integrate
their own hibernate/suspend support diffently.
For example, I'm using Xfce, OpenRC, UPower 0.99.0, pm-utils, Xfce 4.11+
and I have hibernate/suspend working just fine without systemd.
And UPower is for much more than hibernate/suspend, it has dozens of
features, so anykind of systemd dependency on 0.99.0 wouldn't make sense

>
>   26 May 2014; Samuli Suominen <ssuominen@gentoo.org>
>   upower-0.99.0.ebuild: This release is mainly for use with
>   sys-apps/systemd because upstream removed support for
>   sys-power/pm-utils completely from git master. The 0.9 branch is for
>   sys-power/pm-utils use. Adjust ebuild accordingly.
>
> Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency;
> I thought it had one, but maybe it is in another package I'm unaware of.
>

Outdated ChangeLog entry from March, those were the facts we dealt back
then,
only partly true anymore, consumers have evolved

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

On Tue, 03 Jun 2014 16:28:47 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 03/06/14 16:20, Tom Wijsman wrote:
> > Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag;
> 
> No, it doesn't.

Nevermind, `cvs up`-ed; heh, I don't understand how you've got to
that change, I thought there only was a problem with 0.99.0?

> >  in comparison, 0.99.0 mainly wants you to run it with systemd:
> 
> "mainly", as in, since 0.99.0 removed support for hibenate/suspend
> in favour of systemd, the power/session managers need to integrate
> their own hibernate/suspend support diffently.

Ah, right; thinking of MATE, I understand the 0.99.0 bit now.

> >   26 May 2014; Samuli Suominen <ssuominen@gentoo.org>
> >   upower-0.99.0.ebuild: This release is mainly for use with
> >   sys-apps/systemd because upstream removed support for
> >   sys-power/pm-utils completely from git master. The 0.9 branch is
> > for sys-power/pm-utils use. Adjust ebuild accordingly.
> >
> > Though I'm a bit confused why 0.99.0 doesn't list a systemd
> > dependency; I thought it had one, but maybe it is in another
> > package I'm unaware of.
> >
> 
> Outdated ChangeLog entry from March, those were the facts we dealt
> back then,
> only partly true anymore, consumers have evolved

Which means that the situation I am assuming right now is outdated; so,
if you don't mind feel free to highlight why 0.9.23-r3 needs systemd.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 16:40, Tom Wijsman wrote:
> On Tue, 03 Jun 2014 16:28:47 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> On 03/06/14 16:20, Tom Wijsman wrote:
>>> Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag;
>> No, it doesn't.
> Nevermind, `cvs up`-ed; heh, I don't understand how you've got to
> that change, I thought there only was a problem with 0.99.0?
>
>>>  in comparison, 0.99.0 mainly wants you to run it with systemd:
>> "mainly", as in, since 0.99.0 removed support for hibenate/suspend
>> in favour of systemd, the power/session managers need to integrate
>> their own hibernate/suspend support diffently.
> Ah, right; thinking of MATE, I understand the 0.99.0 bit now.
>
>>>   26 May 2014; Samuli Suominen <ssuominen@gentoo.org>
>>>   upower-0.99.0.ebuild: This release is mainly for use with
>>>   sys-apps/systemd because upstream removed support for
>>>   sys-power/pm-utils completely from git master. The 0.9 branch is
>>> for sys-power/pm-utils use. Adjust ebuild accordingly.
>>>
>>> Though I'm a bit confused why 0.99.0 doesn't list a systemd
>>> dependency; I thought it had one, but maybe it is in another
>>> package I'm unaware of.
>>>
>> Outdated ChangeLog entry from March, those were the facts we dealt
>> back then,
>> only partly true anymore, consumers have evolved
> Which means that the situation I am assuming right now is outdated; so,
> if you don't mind feel free to highlight why 0.9.23-r3 needs systemd.
>

To prevent OpenRC users from installing this version because it's
an old UPower with no pm-utils support, with no hibernate/suspend support,
to ensure desktops don't end up with greyed out Hibernate/Suspend
buttons
To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or
other
To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0
because they are going away, to indicate this is the best time to make
informed decision and take manual action regarding choosing which
features set he/she wants, to read up upstream announcements regarding
UPower, to follow-up and do what admins do

- Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Rich Freeman]

On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> To prevent OpenRC users from installing this version because it's
> an old UPower with no pm-utils support, with no hibernate/suspend support,
> to ensure desktops don't end up with greyed out Hibernate/Suspend
> buttons

So, I get why you did it, but my concern is that when you tell portage
that non-systemd users shouldn't use this package, portage helpfully
solves that problem by turning all the non-systemd users into systemd
users, instead of switching them to the alternative that works without
systemd.

Whatever - short of profiles/mix-ins or whatever you want to do on a
big scale there isn't a simple solution to problems like this.  It
just isn't obvious to users who haven't read GMN that there is a
simple fix.  Even users who do read GMN might get confused by the
version number issue, as the change impacts stable users who aren't
using the version of upower mentioned in GMN.

Plus, GMN isn't in-your-face like portage news.

Rich

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

On Tue, 3 Jun 2014 09:53:45 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> Whatever - short of profiles/mix-ins or whatever you want to do on a
> big scale there isn't a simple solution to problems like this.

Why is the mix-in not a simple solution?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Rich Freeman]

On Tue, Jun 3, 2014 at 10:05 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Tue, 3 Jun 2014 09:53:45 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> Whatever - short of profiles/mix-ins or whatever you want to do on a
>> big scale there isn't a simple solution to problems like this.
>
> Why is the mix-in not a simple solution?

It involves a tree-level change.  Granted, for something like systemd
it probably makes sense.  However, there are always going to be
dependency resolution situations where the PM won't guess the user's
intent.  Maybe in these cases the PM should make it more clear that
there was an alternative option.

Rich

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Tue, 3 Jun 2014 10:09:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> Maybe in these cases the PM should make it more clear that
> there was an alternative option.

Yes, Portage could also be helped out with some output improvements.

It requires an analysis on its own, among the kind of collecting "bad
non understandable output" and the solution to it; then try to make up
"favorable output" for it. After which it has to be seen if the needed
information can be obtained, as well as the algorithms for that
favorable output can be implemented.

Somewhere in that flow we also need to have some kind of quality review
cycle to see if the "favorable output" helps; otherwise, it could make
the situation worse instead of better.

Because, really, ...

http://bpaste.net/raw/Pp9Iv18ehzzHKVbm4Sbe/

... does not give away upower as a root blocker cause; even going
further than that, it doesn't suggest upower-pm-utils as an alternative.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Tue, 3 Jun 2014 17:48:05 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:
> On Tue, 3 Jun 2014 10:09:42 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> > Maybe in these cases the PM should make it more clear that
> > there was an alternative option.
> 
> Yes, Portage could also be helped out with some output improvements.

That isn't the issue... Developers need to stop being "clever" in
expressing dependencies, and start giving the package mangler explicit
information about what a dependency means. Relying upon heuristics to
figure out what a complicated mess of || ( ) and blockers means just
leads to things intermittently going horribly wrong.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On Tue, 3 Jun 2014 16:52:30 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 3 Jun 2014 17:48:05 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> > On Tue, 3 Jun 2014 10:09:42 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> > > Maybe in these cases the PM should make it more clear that
> > > there was an alternative option.
> > 
> > Yes, Portage could also be helped out with some output improvements.
> 
> That isn't the issue... Developers need to stop being "clever" in
> expressing dependencies, and start giving the package mangler explicit
> information about what a dependency means. Relying upon heuristics to
> figure out what a complicated mess of || ( ) and blockers means just
> leads to things intermittently going horribly wrong.

Which brings me back to the mix-in suggestion, which improves input. :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 16:53, Rich Freeman wrote:
> On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> To prevent OpenRC users from installing this version because it's
>> an old UPower with no pm-utils support, with no hibernate/suspend support,
>> to ensure desktops don't end up with greyed out Hibernate/Suspend
>> buttons
> So, I get why you did it, but my concern is that when you tell portage
> that non-systemd users shouldn't use this package, portage helpfully
> solves that problem by turning all the non-systemd users into systemd
> users, instead of switching them to the alternative that works without
> systemd.

Portage doesn't do anything on it's own, surely it needs an admin to accept
or reject the changes

It seems we are seeing the severity of something like this diffently, to me,
this belongs to normal Portage functionality, I see something like this
from other packages constantly, I don't understand why this package has
suddently been highlighted like this
It just seems to me people are up in the arms again re: seeing word
"systemd",
when ironically all of this hassle was *for* OpenRC users,
to ensure continuity for them in sys-power/upower-pm-utils where 0.9 git
branch will continue to live
If I hadn't stepped up and blocked the 0.99.0 keywording when it was
originally
about to happen, and then figured a migration path, and then stepped up with
help from pacho2 and tomwij, and migrated the tree like this, we'd have
everyone
on 0.99.0 and no hibernate/suspend for anyone else except systemd users

So, after all the effort we've put in and prepared the tree with OpenRC
users
specifically in mind, if people have to take one or two manual emerge
commands
themselfs, I'm totally fine with that, that's what Gentoo is all about,
choices,
and people who complain about it, really seem like ungrateful over
anything else,
and I'm disappointed. I keep expecting more from our users, the
handholding has
lately gone overboard

I hope that didn't come out wrong, and it certainly wasn't a reply
directly aimed
at you, it was to the thread in general

(I'm still with my original plan, when 0.99.0 goes stable, there will be
multiple bulletin
points to document, news item will be issued)

- Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
> On 03/06/14 16:53, Rich Freeman wrote:
>> So, I get why you did it, but my concern is that when you tell
>> portage that non-systemd users shouldn't use this package, portage
>> helpfully solves that problem by turning all the non-systemd users
>> into systemd users, instead of switching them to the alternative that
>> works without systemd. 
> Portage doesn't do anything on it's own, surely it needs an admin to accept
> or reject the changes

I disagree. It would have been straightforward to create a transitional
package sys-power/upower-10000 which makes openrc users transition to
sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd
or something similar.

And please keep such changes out of stable until proper documentation is
in place (and the 30 day period has elapsed, etc.)


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 17:45, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>> On 03/06/14 16:53, Rich Freeman wrote:
>>> So, I get why you did it, but my concern is that when you tell
>>> portage that non-systemd users shouldn't use this package, portage
>>> helpfully solves that problem by turning all the non-systemd users
>>> into systemd users, instead of switching them to the alternative that
>>> works without systemd. 
>> Portage doesn't do anything on it's own, surely it needs an admin to accept
>> or reject the changes
> I disagree. It would have been straightforward to create a transitional
> package sys-power/upower-10000 which makes openrc users transition to
> sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd
> or something similar.

No, it wouldn't have, because 0.99.0 is the superior version to which
we are all working towards and 10000 would have superceded it
And 0.99.0 is for both, systemd and openrc users

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
> On 03/06/14 17:45, Chí-Thanh Christopher Nguyễn wrote:
>> Samuli Suominen schrieb:
>>> On 03/06/14 16:53, Rich Freeman wrote:
>>>> So, I get why you did it, but my concern is that when you tell
>>>> portage that non-systemd users shouldn't use this package, portage
>>>> helpfully solves that problem by turning all the non-systemd users
>>>> into systemd users, instead of switching them to the alternative that
>>>> works without systemd. 
>>> Portage doesn't do anything on it's own, surely it needs an admin to accept
>>> or reject the changes
>> I disagree. It would have been straightforward to create a transitional
>> package sys-power/upower-10000 which makes openrc users transition to
>> sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd
>> or something similar.
> No, it wouldn't have, because 0.99.0 is the superior version to which
> we are all working towards and 10000 would have superceded it
> And 0.99.0 is for both, systemd and openrc users
>
>

sys-power/upower-10000 would not install any files and be treecleaned
some months after the transition is complete.

upower-10000.ebuild: DEPEND="systemd? ( sys-power/upower-systemd )
!systemd? ( sys-power/upower-pm-utils )

upower-pm-utils-0.9.23.ebuild: DEPEND="!<sys-power/upower-10000
!sys-power/upower-systemd"

upower-systemd-0.9.23-r3.ebuild: DEPEND="!<sys-power/upower-10000
sys-apps/systemd"

I will attach the proposed ebuilds to bug 512252.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Tue, 03 Jun 2014 16:57:12 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Samuli Suominen schrieb:
> > And 0.99.0 is for both, systemd and openrc users
> 
> sys-power/upower-10000 would not install any files and be treecleaned
> some months after the transition is complete.
> 
> upower-10000.ebuild: DEPEND="systemd? ( sys-power/upower-systemd )
> !systemd? ( sys-power/upower-pm-utils )

Read Samuli's comment again, please; what you suggest introduces a
problem for users, like me, that have 0.99 installed regardless of
whether we are using OpenRC or systemd.

Besides that, there is no need for a sys-power/upower-systemd package.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[J. Roeleveld]

On Tuesday, June 03, 2014 04:45:36 PM Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
> > On 03/06/14 16:53, Rich Freeman wrote:
> >> So, I get why you did it, but my concern is that when you tell
> >> portage that non-systemd users shouldn't use this package, portage
> >> helpfully solves that problem by turning all the non-systemd users
> >> into systemd users, instead of switching them to the alternative that
> >> works without systemd.
> > 
> > Portage doesn't do anything on it's own, surely it needs an admin to
> > accept
> > or reject the changes
> 
> I disagree. It would have been straightforward to create a transitional
> package sys-power/upower-10000 which makes openrc users transition to
> sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd
> or something similar.
> 
> And please keep such changes out of stable until proper documentation is
> in place (and the 30 day period has elapsed, etc.)

+1

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[J. Roeleveld]

On Tuesday, June 03, 2014 04:46:18 PM Samuli Suominen wrote:
> On 03/06/14 16:40, Tom Wijsman wrote:
> > On Tue, 03 Jun 2014 16:28:47 +0300
> > 
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >> On 03/06/14 16:20, Tom Wijsman wrote:
> >>> Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag;
> >> 
> >> No, it doesn't.
> > 
> > Nevermind, `cvs up`-ed; heh, I don't understand how you've got to
> > that change, I thought there only was a problem with 0.99.0?
> > 
> >>>  in comparison, 0.99.0 mainly wants you to run it with systemd:
> >> "mainly", as in, since 0.99.0 removed support for hibenate/suspend
> >> in favour of systemd, the power/session managers need to integrate
> >> their own hibernate/suspend support diffently.
> > 
> > Ah, right; thinking of MATE, I understand the 0.99.0 bit now.
> > 
> >>>   26 May 2014; Samuli Suominen <ssuominen@gentoo.org>
> >>>   upower-0.99.0.ebuild: This release is mainly for use with
> >>>   sys-apps/systemd because upstream removed support for
> >>>   sys-power/pm-utils completely from git master. The 0.9 branch is
> >>> 
> >>> for sys-power/pm-utils use. Adjust ebuild accordingly.
> >>> 
> >>> Though I'm a bit confused why 0.99.0 doesn't list a systemd
> >>> dependency; I thought it had one, but maybe it is in another
> >>> package I'm unaware of.
> >> 
> >> Outdated ChangeLog entry from March, those were the facts we dealt
> >> back then,
> >> only partly true anymore, consumers have evolved
> > 
> > Which means that the situation I am assuming right now is outdated; so,
> > if you don't mind feel free to highlight why 0.9.23-r3 needs systemd.
> 
> To prevent OpenRC users from installing this version because it's
> an old UPower with no pm-utils support, with no hibernate/suspend support,
> to ensure desktops don't end up with greyed out Hibernate/Suspend
> buttons
> To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or
> other
> To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0
> because they are going away, to indicate this is the best time to make
> informed decision and take manual action regarding choosing which
> features set he/she wants, to read up upstream announcements regarding
> UPower, to follow-up and do what admins do

All this should have been in a news item, BEFORE it got stabilized.

--
Joost

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Rich Freeman]

On Tue, Jun 3, 2014 at 9:20 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Tue, 3 Jun 2014 09:04:23 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> This has already hit stable.  The dependency on systemd is present in
>> sys-power/upower-0.9.23-r3, which was just stablized.
>
> Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; in
> comparison, 0.99.0 mainly wants you to run it with systemd:

From upower-0.9.23-r3.ebuild:
RDEPEND="${COMMON_DEPEND}
        kernel_linux? (
                app-shells/bash
                >=sys-apps/systemd-200
        )"

No use conditional there...

>
> Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency;
> I thought it had one, but maybe it is in another package I'm unaware of.

Did somebody stick the dependency in the wrong version?  :)

Rich

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Tue, 3 Jun 2014 09:29:59 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> No use conditional there...

Yeah, I was a checkout behind; I'm clueless wrt the new revision bump.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/06/14 08:08 AM, Tom Wijsman wrote:
> On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman <rich0@gentoo.org>
> wrote:
> 
>> This probably could have used a news item, as the change impacts
>> both stable and ~arch users.
> 
> Are we going to write a news item every time systemd acquires a
> new mandatory relationship with a reverse dependency?
> 
>> They need to do an "emerge -1 sys-power/upower-pm-utils" to
>> actually get the new package,
> 
> But the user doesn't want systemd; so, then why does the user have
> to perform a manual step every time that systemd has an
> acquirement?


That's easy -- we don't have a way to do vdb updates that will split a
package, only move a package.  And since this isn't a package move (as
the original package still exists) we can't leverage that.

> 
>> otherwise portage is going to try to switch them from udev to 
>> systemd,
> 
> There is the problem, the user doesn't want systemd; so, why is
> Portage (regardless of a systemd mask) trying to bring it to the
> user anyway?
> 
>> since packages like kdelibs list upower first, and portage has no
>> way of knowing that this is a big change.
> 
> And this is where you can make Portage smarter.
> 
> http://www.funtoo.org/Flavors_and_Mix-ins
> 
> We don't have to go through all this if you had a "no-systemd"
> mix-in, where you could simply make out the choices in favor of the
> user instead of having to document and announce them all over the
> place.
> 
> That mix-in could do something like masking the new upower that 
> depends on systemd; when doing so, no more blockers all over the
> place.
> 

Technically we could do this via a systemd profile too -- ie, mask new
upower everywhere but systemd profiles, and in systemd profile mask
upower-pm-utils.  However, that doesn't get around the actual need to
- --unmerge upower and emerge upower-pm-utils (or hopefully just do the
latter as a soft-block will do the unmerge?)



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlONzPEACgkQ2ugaI38ACPDI5AD/eEbk4156UrMNHmCPIA+xwNfe
nlGC5pnZ3Zs0gu/88EAA/A9hNlNfGzhqorE+8cEz3lkTVuxxq8gv++7Ogm0zY8DU
=I7Mw
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 03 Jun 2014 09:26:09 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 03/06/14 08:08 AM, Tom Wijsman wrote:
> > On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman <rich0@gentoo.org>
> > wrote:
> > 
> >> This probably could have used a news item, as the change impacts
> >> both stable and ~arch users.
> > 
> > Are we going to write a news item every time systemd acquires a
> > new mandatory relationship with a reverse dependency?
> > 
> >> They need to do an "emerge -1 sys-power/upower-pm-utils" to
> >> actually get the new package,
> > 
> > But the user doesn't want systemd; so, then why does the user have
> > to perform a manual step every time that systemd has an
> > acquirement?
> 
> That's easy -- we don't have a way to do vdb updates that will split a
> package, only move a package.  And since this isn't a package move (as
> the original package still exists) we can't leverage that.

- From the dependency viewpoint this isn't a package split or move, it is
rather an introduction of || ( A B ) "alternatives" in the dependency
chain. In this case, the first option (A) is tried and exhausted; this
complexity results in other options (B) not being thoroughly considered.

If you want Portage to make a transition to alternatives, you need to
get a mask in place for the first option; so, we can leverage this:

1. || ( A B ) with A masked causes Portage to install B instead;
2. || ( <A-0.99 B ) with >=A-0.99 masked causes a downgrade to <A-2.

So, what misses here is that mask; which you could put in a mix-in.

(In this specific case A is upower and B is upower-pm-utils.)

> >> otherwise portage is going to try to switch them from udev to 
> >> systemd,
> > 
> > There is the problem, the user doesn't want systemd; so, why is
> > Portage (regardless of a systemd mask) trying to bring it to the
> > user anyway?
> > 
> >> since packages like kdelibs list upower first, and portage has no
> >> way of knowing that this is a big change.
> > 
> > And this is where you can make Portage smarter.
> > 
> > http://www.funtoo.org/Flavors_and_Mix-ins
> > 
> > We don't have to go through all this if you had a "no-systemd"
> > mix-in, where you could simply make out the choices in favor of the
> > user instead of having to document and announce them all over the
> > place.
> > 
> > That mix-in could do something like masking the new upower that 
> > depends on systemd; when doing so, no more blockers all over the
> > place.
> > 
> 
> Technically we could do this via a systemd profile too -- ie, mask new
> upower everywhere but systemd profiles, and in systemd profile mask
> upower-pm-utils.

In doing so, you assume that non-systemd profiles are anti-systemd;
however, that's not the case. Currently GNOME and KDE have systemd
profiles; but, there are a lot of other desktop environments in the
Portage tree that have support for systemd.

So, this means we would have to go and create a profile for each
desktop environment and within such profile yet another profile for
systemd; this becomes somewhat tedious if you can cover all that in a
mixin instead.

You're going to need mixins at some point when it's not just "systemd"
that is a specialization but something else as well; unless you want to
create even more directories for the possible combinations:

 - gnome/somethingelse
 - gnome/systemd
 - gnome/systemd+somethingelse

> However, that doesn't get around the actual need to
> - --unmerge upower and emerge upower-pm-utils (or hopefully just do
> the latter as a soft-block will do the unmerge?)

Portage does this for you if you mask upower and provide it with
sufficient backtracking; so, there's no need to do this manually.

More explicitly noted: An upower mask allows us to say that an upgrade
should do `emerge -C upower` and `emerge upower-pm-utils`, in the case
that there is || ( upower upower-pm-utils ) listed as a dependency.

Unless you have selected upower on purpose; which would be a different
case than the one we're discussing here, also giving different output as
it'll point out that @selected brings in what (upower) has been masked.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJTjdWXAAoJEPWZc8roOL/QTwAIAJeYIYpF4JIclsGY67ZHDpuM
D2rY3JlCEof4iMcPGccR+lsiTWp0inRRkR5YYejPTMupD/MUqmhuxAogLcUE79m6
lBGQOmO9G4Iduvuoesa99x7UUW6Ihx9TrmoPmn++S9Bn8FrFq+52rUkRDFrlbsrP
+wyrc2Dh8SQlI7Bf2r0WcloE9xb+TVXKeyJeZs9eN0afQXqtFJraoGuPYsj7yF7f
JWHq26HWRBd+EM8Gyx0OHgPW4Uc7mwhabywxfh44HcjLvh5DN+4/fXbLXc6ytBvi
Z5+4UMMXNEUloovKKHT45uVCJ159njFk9KW5SQhKRihaQD63USMm+sKGm0Kx0Ek=
=Sugk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Patrick Lauer]

On 06/03/2014 07:25 PM, Samuli Suominen wrote:
> 
> On 03/06/14 14:40, J. Roeleveld wrote:
>> Would have been nice to fix all the dependencies BEFORE marking the
>> systemd- depending "sys-power/upower-pm-utils" stable. -- Joost 
> 
> No clue what you mean, sys-power/upower-pm-utils doesn't depend on
> sys-apps/systemd,
> and whole Portage tree is converted to proper dependencies and the
> conversion went in
> the correct steps.


The only step missing is:

Mask the new version on all non-systemd profiles so that portage doesn't
try to install it

(I wonder why systemd and the related stuff isn't masked on non-systemd
profiles anyway ...)

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On Wed, 04 Jun 2014 07:55:50 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> On 06/03/2014 07:25 PM, Samuli Suominen wrote:
> > 
> > On 03/06/14 14:40, J. Roeleveld wrote:
> >> Would have been nice to fix all the dependencies BEFORE marking the
> >> systemd- depending "sys-power/upower-pm-utils" stable. -- Joost 
> > 
> > No clue what you mean, sys-power/upower-pm-utils doesn't depend on
> > sys-apps/systemd,
> > and whole Portage tree is converted to proper dependencies and the
> > conversion went in
> > the correct steps.
> 
> The only step missing is:
> 
> Mask the new version on all non-systemd profiles so that portage
> doesn't try to install it
> 
> (I wonder why systemd and the related stuff isn't masked on
> non-systemd profiles anyway ...)

There is no such thing as a non-systemd profile; a sub directory is a
specialization, that doesn't mean that it parents suddenly become the
opposite of that. No, the parents are just generalizations that aren't
as specific as the sub directory.

Doing what you've suggested everywhere but in gnome/systemd and
kde/systemd is a recipe to upset everyone whom runs systemd on another
desktop environment than GNOME or KDE; so, that's not a way forward.

Another option is to create no-systemd sub directories; but such
profiles will be highly controversial, besides helping the exponential
grow of the profiles directories as well as be a non-default profile.

Mix-ins from Funtoo, anyone?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Patrick Lauer]

On 06/04/2014 08:24 AM, Tom Wijsman wrote:
> On Wed, 04 Jun 2014 07:55:50 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
>> On 06/03/2014 07:25 PM, Samuli Suominen wrote:
>>>
>>> On 03/06/14 14:40, J. Roeleveld wrote:
>>>> Would have been nice to fix all the dependencies BEFORE marking the
>>>> systemd- depending "sys-power/upower-pm-utils" stable. -- Joost 
>>>
>>> No clue what you mean, sys-power/upower-pm-utils doesn't depend on
>>> sys-apps/systemd,
>>> and whole Portage tree is converted to proper dependencies and the
>>> conversion went in
>>> the correct steps.
>>
>> The only step missing is:
>>
>> Mask the new version on all non-systemd profiles so that portage
>> doesn't try to install it
>>
>> (I wonder why systemd and the related stuff isn't masked on
>> non-systemd profiles anyway ...)
> 
> There is no such thing as a non-systemd profile; a sub directory is a
> specialization, that doesn't mean that it parents suddenly become the
> opposite of that. No, the parents are just generalizations that aren't
> as specific as the sub directory.

Since systemd needs special profiles to be easy to use ...

... it'd be the boring and easy way to restrict it to those profiles so
that dependency changes don't cause this needless amount of work for
users, and this indecent amount of mail on this mailinglist
> 
> Doing what you've suggested everywhere but in gnome/systemd and
> kde/systemd is a recipe to upset everyone whom runs systemd on another
> desktop environment than GNOME or KDE; so, that's not a way forward.

I have no idea what you are trying to say, but there's a desktop profile

> Another option is to create no-systemd sub directories; but such
> profiles will be highly controversial, besides helping the exponential
> grow of the profiles directories as well as be a non-default profile.

The "default" is already that, all I'm suggesting is masking systemd
there so that portage doesn't needlessly antagonize users

> Mix-ins from Funtoo, anyone?
No thanks

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

On Wed, 04 Jun 2014 08:44:45 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> On 06/04/2014 08:24 AM, Tom Wijsman wrote:
> > On Wed, 04 Jun 2014 07:55:50 +0800
> > Patrick Lauer <patrick@gentoo.org> wrote:
> > 
> >> On 06/03/2014 07:25 PM, Samuli Suominen wrote:
> >>>
> >>> On 03/06/14 14:40, J. Roeleveld wrote:
> >>>> Would have been nice to fix all the dependencies BEFORE marking
> >>>> the systemd- depending "sys-power/upower-pm-utils" stable. --
> >>>> Joost 
> >>>
> >>> No clue what you mean, sys-power/upower-pm-utils doesn't depend on
> >>> sys-apps/systemd,
> >>> and whole Portage tree is converted to proper dependencies and the
> >>> conversion went in
> >>> the correct steps.
> >>
> >> The only step missing is:
> >>
> >> Mask the new version on all non-systemd profiles so that portage
> >> doesn't try to install it
> >>
> >> (I wonder why systemd and the related stuff isn't masked on
> >> non-systemd profiles anyway ...)
> > 
> > There is no such thing as a non-systemd profile; a sub directory is
> > a specialization, that doesn't mean that it parents suddenly become
> > the opposite of that. No, the parents are just generalizations that
> > aren't as specific as the sub directory.
> 
> Since systemd needs special profiles to be easy to use ...

No, these systemd profiles are only introduced for GNOME and KDE ...
 
> ... it'd be the boring and easy way to restrict it to those profiles
> so that dependency changes don't cause this needless amount of work
> for users, and this indecent amount of mail on this mailinglist

..., which means that your restriction doesn't hold ...

> > Doing what you've suggested everywhere but in gnome/systemd and
> > kde/systemd is a recipe to upset everyone whom runs systemd on
> > another desktop environment than GNOME or KDE; so, that's not a way
> > forward.
> 
> I have no idea what you are trying to say, but there's a desktop
> profile

...; because systemd users also use the desktop profiles ...

> > Another option is to create no-systemd sub directories; but such
> > profiles will be highly controversial, besides helping the
> > exponential grow of the profiles directories as well as be a
> > non-default profile.
> 
> The "default" is already that, all I'm suggesting is masking systemd
> there so that portage doesn't needlessly antagonize users

..., which makes your suggestion not an option.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Greg Woodbury]

On 06/03/2014 08:24 PM, Tom Wijsman wrote:
> On Wed, 04 Jun 2014 07:55:50 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:

[Lots of comments about upower updates and interactions between
 systemd and Open-rc...]

I'm sorry, but it seems to me that this is *another* power grab by the
"systemd Cabal."

More and more a small group of developers are making
non-well-thought-out changes to the Linux environment that have the
effect of pushing systemd as the default model for init systems.

First, they abrogated the FHS by putting boot necessary stuff in the
/usr hierarchy (deliberately ignoring the FHS rationale and history)
forcing many users to redo systems to not have separate /usr trees.

Then, they "steal" a general kernel command line parameter (debug) that
makes booting impossible in certain cases. (Linus had to put his foot
down on that one.)

And now, another useful process is forced to make workarounds for users
so that they don't get switched to systemd willy-nilly.

(Don't get me started on the GD linkage between Gnome and systemd!)

As one of the uncredited makers of the SysV init system (I was a lowly
consultant sysadmin during the Unix System IV roll out) I know more of
the history than most.  SysV init "punted" the hard problem of getting
sequencing and dependency during startup to the more agile mind of a
human because we didn't have the time to develop a general dependency
solver for the boot sequence.  (And someone who was supposed to document
that need for examination in the SysV development cycle seems ti have
neglected the item.)

OpenRC does some logical and straight-forward extensions to the SysV
paradigm and handles the problem well enough.  SystemD goes for a total
rewrite (and suffers second system syndrome) and seems to be
masterminded by folks with Napoleonic ideation.

Mind you, I am *not* anti-systemd. In many ways it is a good system that
automates a lot of stuff that needed automation.  I just have some
strong disagreements with some of the choices its implementors and
advocates have made in relation to other aspects of system management.

I have thought that Linux and the FOSS movement was about user choice.
Not a small band of folks deciding that "users" shouldn't be expected to
know what their systems are doing under-the-hood and forcing that vision
on everyone, whether they want it or not.

I moved to Gentoo (from a long history with RedHat and then Fedora)
because it seemed to me that the concept of maximum choice was a
treasured and honored position. Recent events, however, seem to indicate
that even here in Gentoo-land there is a power struggle occurring.  As
I'm getting to the stage of being a "senior citizen" I probably will not
have to deal with the fallout of this struggle for too long, but it
disheartens me to see it occurring.

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Olav Vitters]

On Tue, Jun 03, 2014 at 09:20:51PM -0400, Greg Woodbury wrote:
> Then, they "steal" a general kernel command line parameter (debug) that
> makes booting impossible in certain cases. (Linus had to put his foot
> down on that one.)

Almost your entire statement here is incorrect. Systemd still looks at
the debug flag until jorunald is available. There was a bug which caused
lots of output from systemd to the kernel, making the kernel hang. Linus
subsequently said kernel should rate limit the output from any process,
plus was upset the way that Kay handled a bugreport.

However, Linus is and was totally fine with the debug flag usage. Aside
from that there are various other tools that make use of the debug flag.

Apologies if this conflicts with your systemd is taking over the world
and evil evil evil talk :-P

References (these are more thorough):
https://plus.google.com/115547683951727699051/posts/VYRaUuh1tkt
https://lwn.net/Articles/593676/

-- 
Regards,
Olav

Re: Off-list: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Alan McKinnon]

On 04/06/2014 02:24, Tom Wijsman wrote:

> There is no such thing as a non-systemd profile; a sub directory is a
> specialization, that doesn't mean that it parents suddenly become the
> opposite of that. No, the parents are just generalizations that aren't
> as specific as the sub directory.
> 
> Doing what you've suggested everywhere but in gnome/systemd and
> kde/systemd is a recipe to upset everyone whom runs systemd on another
> desktop environment than GNOME or KDE; so, that's not a way forward.
> 
> Another option is to create no-systemd sub directories; but such
> profiles will be highly controversial, besides helping the exponential
> grow of the profiles directories as well as be a non-default profile.
> 
> Mix-ins from Funtoo, anyone?

p.s. off-list :-)


mix-ins? Awesome idea. We should do more of those.

I don't understand why people are punting this idea of a non-systemd
profile, I can see how that could ever work. Profiles *add* stuff or set
some defaults, taking things away in a profile is really hard. The only
thing it works for is globally setting stuff that can never be used eg,
you need to remove all x86 cpu flags from arm


Desktop profiles with and without systemd or KDE or Gnome or whatever
looks exactly like an inherited class plus interfaces problem. Which is
what mix-ins do :-)

So once again - mixins, an awesome idea



-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Duncan]

Tom Wijsman posted on Wed, 04 Jun 2014 02:24:31 +0200 as excerpted:

> On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer <patrick@gentoo.org>
> wrote:
> 
>> The only step missing is:
>> 
>> Mask the new version on all non-systemd profiles so that portage
>> doesn't try to install it
>> 
>> (I wonder why systemd and the related stuff isn't masked on non-systemd
>> profiles anyway ...)
> 
> There is no such thing as a non-systemd profile; a sub directory is a
> specialization, that doesn't mean that it parents suddenly become the
> opposite of that. No, the parents are just generalizations that aren't
> as specific as the sub directory.
> 
> Doing what you've suggested everywhere but in gnome/systemd and
> kde/systemd is a recipe to upset everyone whom runs systemd on another
> desktop environment than GNOME or KDE; so, that's not a way forward.

+1

Currently I'm default/linux/amd64/13.0/no-multilib.

I certainly don't want systemd masked as I switched to it a few months 
ago, but there's no no-multilib systemd profile for me to switch to.  Not 
that I actually need one unless someone goes mad and starts masking 
packages without a good reason (like it doesn't work on that arch!) in 
general purpose profiles.

Of course it wouldn't be a big deal for me anyway; given that I'm 
advanced enough to have no @system at all as I've negated the whole thing 
in /etc/portage/profile/packages, I'm sure I could unmask systemd if I 
needed to.  But for other no-multilib systemd users, and for others using 
similar profiles, masking systemd in a general purpose profile is NOT the 
way to go.

The alternatives are a combinatorial profile explosion (impractical),
mix-ins, as TomWij suggests (medium-term solution, more likely long-term 
given gentoo politics, but we need short-term here), or status-quo, not 
masking packages that work just fine in general-purpose profiles.

Which basically means news items noting the manual action necessary for 
things like this, as is now being done. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Alexey Shvetsov]

Michał Górny писал 27-05-2014 09:34:
> Dnia 2014-05-26, o godz. 23:15:34
> Samuli Suominen <ssuominen@gentoo.org> napisał(a):
> 
>> UPower upstream removed sys-power/pm-utils support from 0.99 release
>> (currently unkeyworded in tree), as in, from current git master.
> 
> Don't worry. Looking at the past, I can guess this is only a temporary
> inconvenience. I'm pretty sure upower will be discontinued soon
> and replaced with systemd-powerd or something :D.

So again there will be mad bycicle on scrappers called systemd =\

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Alexey Shvetsov]

Michał Górny писал 27-05-2014 09:34:
> Dnia 2014-05-26, o godz. 23:15:34
> Samuli Suominen <ssuominen@gentoo.org> napisał(a):
> 
>> UPower upstream removed sys-power/pm-utils support from 0.99 release
>> (currently unkeyworded in tree), as in, from current git master.
> 
> Don't worry. Looking at the past, I can guess this is only a temporary
> inconvenience. I'm pretty sure upower will be discontinued soon
> and replaced with systemd-powerd or something :D.

So again there will be mad bycicle on scrappers called systemd =\

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru