[gentoo-user] Systemd upower

[gentoo-user] Systemd upower

[Silvio Siefke]

Hello,

mean this i must install now systemd? What can do when i not want systemd. 
The system what i have is good, i want not change to systemd.

[ebuild     U ~] sys-devel/gettext-0.19 [0.18.3.2] USE="acl cxx ncurses nls openmp -cvs -doc -emacs -git -java -static-libs" 16,221 kB
[ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="(mime%*) -debug (-fam) (-selinux) -static-libs -systemtap {-test} -utils -xattr" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[ebuild  N     ] sys-apps/systemd-208-r3:0/1  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python tcpd -audit -cryptsetup -doc -gcrypt -http -lzma -qrcode (-selinux) {-test} -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7 -python3_2 -python3_3" PYTHON_TARGETS="python2_7 python3_3 -python3_2" 2,335 kB
[ebuild  N     ] sys-apps/gentoo-systemd-integration-2  51 kB
[ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc -ios" 0 kB
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-208-r3)
[blocks B      ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-212-r1)


Thank you for help & Nice Day
Silvio

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 9:14 AM, Silvio Siefke <siefke_listen@web.de> wrote:
> Hello,
>
> mean this i must install now systemd? What can do when i not want systemd.
> The system what i have is good, i want not change to systemd.
>
> [ebuild     U ~] sys-devel/gettext-0.19 [0.18.3.2] USE="acl cxx ncurses nls openmp -cvs -doc -emacs -git -java -static-libs" 16,221 kB
> [ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="(mime%*) -debug (-fam) (-selinux) -static-libs -systemtap {-test} -utils -xattr" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
> [ebuild  N     ] sys-apps/systemd-208-r3:0/1  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python tcpd -audit -cryptsetup -doc -gcrypt -http -lzma -qrcode (-selinux) {-test} -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7 -python3_2 -python3_3" PYTHON_TARGETS="python2_7 python3_3 -python3_2" 2,335 kB
> [ebuild  N     ] sys-apps/gentoo-systemd-integration-2  51 kB
> [ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc -ios" 0 kB
> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-208-r3)
> [blocks B      ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-212-r1)
>

If I understood correctly, you need to:

emerge -C sys-power/upower
emerge -1v sys-power/upower-pm-utils

and then update world as usual.

The changes in upower does not make systemd mandatory, but you need to
switch from upower (which now has systemd as a hard dependency) to
upower-pm-utils (which depends on the unmaintined pm-utils).

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Peter Humphrey]

On Tuesday 03 June 2014 09:29:35 Canek Peláez Valdés wrote:

> If I understood correctly, you need to:
> 
> emerge -C sys-power/upower
> emerge -1v sys-power/upower-pm-utils
> 
> and then update world as usual.

That worked for me - thanks Canek. Portage no longer tries to break a blockage 
circle, and even though upower-pm-utils is emerged with -1, emerge -c doesn't 
want to remove it.

Maybe a news item explaining the switch of upower would help those who haven't 
blundered into this yet.

> The changes in upower does not make systemd mandatory, but you need to
> switch from upower (which now has systemd as a hard dependency) to
> upower-pm-utils (which depends on the unmaintined pm-utils).

-- 
Regards
Peter

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 9:52 AM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> On Tuesday 03 June 2014 09:29:35 Canek Peláez Valdés wrote:
>
>> If I understood correctly, you need to:
>>
>> emerge -C sys-power/upower
>> emerge -1v sys-power/upower-pm-utils
>>
>> and then update world as usual.
>
> That worked for me - thanks Canek. Portage no longer tries to break a blockage
> circle, and even though upower-pm-utils is emerged with -1, emerge -c doesn't
> want to remove it.

Good to know; I don't use OpenRC, so this doesn't affect me, and I
have no way to test the proposed solution.

> Maybe a news item explaining the switch of upower would help those who haven't
> blundered into this yet.

Maybe. The thing is, this is going to keep happening, as more and more
infrastructure migrates towards systemd. Perhaps a news item everytime
it happens is unrealistic?

I would expect Gentoo users to search for viable solutions by
themselves, or asking for ways to solve it in the proper channels
(like Silvio did).

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 03/06/14 18:10, Canek Peláez Valdés wrote:
>> Maybe a news item explaining the switch of upower would help those who haven't
>> blundered into this yet.
> Maybe. The thing is, this is going to keep happening, as more and more
> infrastructure migrates towards systemd. Perhaps a news item everytime
> it happens is unrealistic?
>
> I would expect Gentoo users to search for viable solutions by
> themselves, or asking for ways to solve it in the proper channels
> (like Silvio did).

Yes, thank you. That's exactly how I've seen the situation, but am I
expecting
too much from our users?

(I think I'll be forced to write up some minimal news item just to shut up
the loud minority who can't be bothered to do anything themselfs, like even
read package ChangeLogs if they stumble upon something manual.)

[gentoo-user] Re: Systemd upower

[»Q«]

On Tue, 03 Jun 2014 18:14:56 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> (I think I'll be forced to write up some minimal news item just to
> shut up the loud minority who can't be bothered to do anything
> themselfs, like even read package ChangeLogs if they stumble upon
> something manual.)

I figured out what I wanted to do (uninstall upower, install
upower-pm-utils) by reading the changelogs, but I don't know what my
other options were.  Could I have stuck with upower, letting it pull in
systemd, without messing up openrc?

ISTM as long as openrc is Gentoo's default init system, it would be
nice to have a news item outline all the available paths for openrc
users every time something like this happens.

Re: [gentoo-user] Re: Systemd upower

[Peter Humphrey]

On Tuesday 03 June 2014 10:39:10 »Q« wrote:

> I figured out what I wanted to do (uninstall upower, install
> upower-pm-utils) by reading the changelogs, but I don't know what my
> other options were.  Could I have stuck with upower, letting it pull in
> systemd, without messing up openrc?

Apparently not, or at least I couldn't, because of package blocks.

-- 
Regards
Peter

Re: [gentoo-user] Systemd upower

[Greg Woodbury]

On 06/03/2014 11:14 AM, Samuli Suominen wrote:
> 
> On 03/06/14 18:10, Canek Peláez Valdés wrote:
>>> Maybe a news item explaining the switch of upower would help those who haven't
>>> blundered into this yet.
>> Maybe. The thing is, this is going to keep happening, as more and more
>> infrastructure migrates towards systemd. Perhaps a news item everytime
>> it happens is unrealistic?
>>
>> I would expect Gentoo users to search for viable solutions by
>> themselves, or asking for ways to solve it in the proper channels
>> (like Silvio did).
> 
> Yes, thank you. That's exactly how I've seen the situation, but am I
> expecting
> too much from our users?
> 
> (I think I'll be forced to write up some minimal news item just to shut up
> the loud minority who can't be bothered to do anything themselfs, like even
> read package ChangeLogs if they stumble upon something manual.)
> 

If someone is going to change the basic rules and expectations of a
system in radical ways it is *not* unreasonable to expect that change to
be explained in an easy-to-find way (and not buried in a changelog.)

-- 
G.Wolfe Woodbury

Re: [gentoo-user] Systemd upower

[Tanstaafl]

On 6/3/2014 11:10 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> Maybe. The thing is, this is going to keep happening, as more and more
> infrastructure migrates towards systemd. Perhaps a news item everytime
> it happens is unrealistic?

Weren't you the one saying that those of us who were voicing concerns 
that systemd proponents were ultimately wanting to FORCE systemd on 
everyone were just scare-mongering conspiracy theorists?

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 11:48 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 6/3/2014 11:10 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> Maybe. The thing is, this is going to keep happening, as more and more
>> infrastructure migrates towards systemd. Perhaps a news item everytime
>> it happens is unrealistic?
>
>
> Weren't you the one saying that those of us who were voicing concerns that
> systemd proponents were ultimately wanting to FORCE systemd on everyone were
> just scare-mongering conspiracy theorists?

Who is "forcing"  anything? pm-utils has been unmaintained FOR FIVE
YEARS. Any project that decides to stop using it is making just the
right decision; UPower just did the correct thing. And systemd had
*nothing* to do with it, except for providing a better, more reliable
alternative.

That's what you and many others don't seem to understand: systemd is a
*BETTER* implementation for basically *ALL* the hodgepodge of
"solutions" that we had before in our plumbing layer.

Since systemd provides a better alternative for everything in the
stack just above the kernel, more and more projects (probably) will
start using it exclusively. That is no systemd's fault; they just
worked in a good, integrated solution. Why any project will want to
support multiple alternatives for the same functionality, if systemd
provides the better one, and almost no distribution works without it?
Perhaps if somebody wrote the code they'll do it, but almost all
programmers who know what they are doing refuse to work with anything
else than systemd

You don't like it? Go ahead and take maintainership of pm-utils. Fork
UPower. Make better replacements for the components that systemd
provides.

There is no conspiracy here (although for *SURE* there are
scare-mongering conspiracy theorists); there is only developers
working in the best possible implementation for our plumbing layer,
and other developers realizing that, in Linux at least, supporting
anything besides systemd is a freakin' waste of time and resources.

Again; you don't like it? Then do something about it instead of
posting in *-user lists.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Alan McKinnon]

On 03/06/2014 19:08, Canek Peláez Valdés wrote:
> Who is "forcing"  anything? pm-utils has been unmaintained FOR FIVE
> YEARS. Any project that decides to stop using it is making just the
> right decision; UPower just did the correct thing. And systemd had
> *nothing* to do with it, except for providing a better, more reliable
> alternative.
> 
> That's what you and many others don't seem to understand: systemd is a
> *BETTER* implementation for basically *ALL* the hodgepodge of
> "solutions" that we had before in our plumbing layer.


<weak attempt to inject humour and lighten the thread mood>

This whole systemd thing looks awfully like the switch from a hosts file
to DNS so many years ago.

On the one had a hosts file worked and you could throw vi at it.
On the other hand this DNS thing could be evil and we'd have to hand
control over to <insert name of nebulous party here>.

Trouble is, a host file is an awful solution and really just does
everything badly. Much like shell init scripts.

We all, sysadmins and devs alike, agree that consistent interfaces are a
very good idea, so we pick a standard and stick with it. And yet,
strangely, there's so much resistance to doing just that with early user
space.

I'm not a systemd user, but I do find this whole thing quite funny :-)

</weak attempt to inject humour and lighten the thread mood>


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Systemd upower

[Marc Stürmer]

Am 03.06.2014 22:14, schrieb Alan McKinnon:
> This whole systemd thing looks awfully like the switch from a hosts file
> to DNS so many years ago.

Not really. What many people bothers about systemd is that it is getting 
more and more

a) a hard dependancy for software projects, e.g. like GNOME, although 
there's no such thing like systemd e.g. on FreeBSD, (MATE instead tries 
to be init system agnostic), making it harder to port

and

b) that systemd seems to be on a track to reinvent the wheel or so more 
and more.

They are really working on their own DHCP server and client at the 
moment, also their own NTP client. Some people coined the term 
Lennartware for it, because it's from Lennart Poettering, like also 
pulseaudio and avahi.

Some people are already joking that it wants to become the next Emacs.

Even Linus Torvalds himself ranted about the attitude of systemd's 
developers at the beginning of May this year.

Re: [gentoo-user] Systemd upower

[Alan McKinnon]

On 03/06/2014 23:01, Marc Stürmer wrote:
> Am 03.06.2014 22:14, schrieb Alan McKinnon:
>> This whole systemd thing looks awfully like the switch from a hosts file
>> to DNS so many years ago.
> 
> Not really. What many people bothers about systemd is that it is getting
> more and more
> 
> a) a hard dependancy for software projects, e.g. like GNOME, although
> there's no such thing like systemd e.g. on FreeBSD, (MATE instead tries
> to be init system agnostic), making it harder to port
> 
> and
> 
> b) that systemd seems to be on a track to reinvent the wheel or so more
> and more.
> 
> They are really working on their own DHCP server and client at the
> moment, also their own NTP client. Some people coined the term
> Lennartware for it, because it's from Lennart Poettering, like also
> pulseaudio and avahi.
> 
> Some people are already joking that it wants to become the next Emacs.
> 
> Even Linus Torvalds himself ranted about the attitude of systemd's
> developers at the beginning of May this year.



I am very familiar with all of that, along with every other regular here
- the topic has been discussed to death here repeatedly[1]

Also, please don't assign all the evils of the free software world to
Lennart. systemd is a large team comprising many more persons than just
Lennart.

Now, ranting about Lennart ain't gonna solve nuthin'.
Writing code will.

The systemd devs have an itch to scratch and they are scratching it by
writing code. I don't see too many other folks writing anything like the
same amount of code and yet for those that want to counter systemd, that
is the only thing that will.

So where's the alternative code? It's not in SysVinit.

For the record, I'm not a systemd fan, I actually run it nowhere.
FWIW, I agree with Lennart's ideas as they have sound technical merit in
principle. It's his implementation I don't like.

Incidentally, what exactly is wrong with systemd writing a dhcp server &
client, and an ntp client? Is that project prohibited from writing such
software? Are they not allowed to do it? Does it break legal laws? Is
there an NDA or non-compete clause in the mix that I'm not aware of?
Because they are the only things that could stop systemd from writing
such code; without such prohibitions they are free to spend their time
doing whatever they damn well please and if that means yet another dhcp
implementation, so be it.

Let's take that argument a little further:
Paul Vixie wrote a dhcp package. Per your logic, it would then not beOK
for Roy Marples to write dhcpcd. but he did, and no-one is complaining.

I can predict the likely response - systemd will bundle their dhcp and
ntp code. So what? It's their time and effort, they are free to choose
to spend it how they wish.

And you are equally free to write something better if you so choose.




[1] For the purpose of this exercise, lets assign a value of "more than
10" to "repeatedly"



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
[...]
> Incidentally, what exactly is wrong with systemd writing a dhcp server &
> client, and an ntp client? Is that project prohibited from writing such
> software? Are they not allowed to do it? Does it break legal laws? Is
> there an NDA or non-compete clause in the mix that I'm not aware of?
> Because they are the only things that could stop systemd from writing
> such code; without such prohibitions they are free to spend their time
> doing whatever they damn well please and if that means yet another dhcp
> implementation, so be it.

Alan, thanks for succinctly putting why is absurd to complain about
someone else's desire to write whatever code she desires to write. And
to sharing it to the world! The HORROR!

How *DARE* they to release their code? For free!

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Alon Bar-Lev]

On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> [...]
> > Incidentally, what exactly is wrong with systemd writing a dhcp server &
> > client, and an ntp client? Is that project prohibited from writing such
> > software? Are they not allowed to do it? Does it break legal laws? Is
> > there an NDA or non-compete clause in the mix that I'm not aware of?
> > Because they are the only things that could stop systemd from writing
> > such code; without such prohibitions they are free to spend their time
> > doing whatever they damn well please and if that means yet another dhcp
> > implementation, so be it.
>
> Alan, thanks for succinctly putting why is absurd to complain about
> someone else's desire to write whatever code she desires to write. And
> to sharing it to the world! The HORROR!
>
> How *DARE* they to release their code? For free!
>

Once again, you do not understand the claim.

If a user of Gentoo chooses to use non systemd profile, it means that
we need to make sure systemd will not be a valid option, ever.

In this case, if it is to disable the upower USE flag, or to provide
alternative, block newer version, whatever make it possible to have a
system working without systemd.

systemd should not be visible at any time, nor its implications.

Alon

Re: [gentoo-user] Systemd upower

[Alan McKinnon]

On 04/06/2014 00:06, Alon Bar-Lev wrote:
> On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> [...]
>>> Incidentally, what exactly is wrong with systemd writing a dhcp server &
>>> client, and an ntp client? Is that project prohibited from writing such
>>> software? Are they not allowed to do it? Does it break legal laws? Is
>>> there an NDA or non-compete clause in the mix that I'm not aware of?
>>> Because they are the only things that could stop systemd from writing
>>> such code; without such prohibitions they are free to spend their time
>>> doing whatever they damn well please and if that means yet another dhcp
>>> implementation, so be it.
>>
>> Alan, thanks for succinctly putting why is absurd to complain about
>> someone else's desire to write whatever code she desires to write. And
>> to sharing it to the world! The HORROR!
>>
>> How *DARE* they to release their code? For free!
>>
> 
> Once again, you do not understand the claim.
> 
> If a user of Gentoo chooses to use non systemd profile, it means that
> we need to make sure systemd will not be a valid option, ever.
> 
> In this case, if it is to disable the upower USE flag, or to provide
> alternative, block newer version, whatever make it possible to have a
> system working without systemd.
> 
> systemd should not be visible at any time, nor its implications.
> 
> Alon


Alon,

You need to read the massive thread on -dev about this and understand
the technical reason why portage is doing something strange.

I'm not going to give you opinion or rant here, I'm going to give you fact:

Nobody is shoving systemd down anyone's throat because that is not what
the portage code did. UPower removed their support for pm-utils
(unmaintained for 5 years) and now support that same functionality
provided by systems. UPower has the right to make that call.

Samuli picked up that this is an issue for non-systemd users - they will
not have the ability to suspend/hiberate. So a package was created
called upower-pm-utils which contains the pm-utils code prior to the
UPower change. If you want UPower to work as it always did for you,
simply unmerge upower and merge upower-pm-utils. To have
suspend/hibernate done the systmed way, just leave UPower installed and
let portage do it's thing.

Now, this is where the snag comes in. Portage sees you have UPower and
you now need pm functionality, and portage needs to merge something to
fill that dependency. Because of the way the code works, portage finds
UPower+systemd first always, and decides to use that. It's software, not
a human, so it doesn't question your decision and proceeds. It's
analogous to having a virtual - if you don't tell portage which one to
use, it picks the first. You tell portage which one you want by
installing it, and portage is happy with that.

Should there have been some USE flag-type solution to definitely
indicate your choice? Sounds good in practice but in this case it's not
a good idea (see the -dev thread for reasons why). Besides, this is a
transitional phase and things will change again in a month. It's really
not worth the effort to set up a USE for one package for a month.

Those are the facts as laid out by our Gentoo devs and those facts do
not support a conspiracy theory.

Summary;

You yourself do not want systemd. OK. Here's how to not get it in this case:

emerge -C upower && emerge -1 upower-pm-utils





-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 5:06 PM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> [...]
>> > Incidentally, what exactly is wrong with systemd writing a dhcp server &
>> > client, and an ntp client? Is that project prohibited from writing such
>> > software? Are they not allowed to do it? Does it break legal laws? Is
>> > there an NDA or non-compete clause in the mix that I'm not aware of?
>> > Because they are the only things that could stop systemd from writing
>> > such code; without such prohibitions they are free to spend their time
>> > doing whatever they damn well please and if that means yet another dhcp
>> > implementation, so be it.
>>
>> Alan, thanks for succinctly putting why is absurd to complain about
>> someone else's desire to write whatever code she desires to write. And
>> to sharing it to the world! The HORROR!
>>
>> How *DARE* they to release their code? For free!
>>
>
> Once again, you do not understand the claim.

It is you who does not understand how software workds. See Alan response.

> If a user of Gentoo chooses to use non systemd profile, it means that
> we need to make sure systemd will not be a valid option, ever.

Again, you don't understand how software works: this has nothing to do
with "profiles", it has to do with the fact that UPower now relies on
systemd, and therefore people who has UPower installed now, *by
default*, require systemd. If they don't want systemd, there is a way
to do it, but it requires manual intervention since they now need to
first uninstall UPower.

> In this case, if it is to disable the upower USE flag, or to provide
> alternative, block newer version, whatever make it possible to have a
> system working without systemd.

It is provided:

emerge -C upower
emerge -1v upower-pm-utils

It has to be done manually, though; otherwise you step on systemd users.

> systemd should not be visible at any time, nor its implications.

Nobody is here to deal with other people's OCD.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Jim Burwell]

On 6/3/2014 16:13, Canek Peláez Valdés wrote:
> On Tue, Jun 3, 2014 at 5:06 PM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
>> On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>> [...]
>>>> Incidentally, what exactly is wrong with systemd writing a dhcp server &
>>>> client, and an ntp client? Is that project prohibited from writing such
>>>> software? Are they not allowed to do it? Does it break legal laws? Is
>>>> there an NDA or non-compete clause in the mix that I'm not aware of?
>>>> Because they are the only things that could stop systemd from writing
>>>> such code; without such prohibitions they are free to spend their time
>>>> doing whatever they damn well please and if that means yet another dhcp
>>>> implementation, so be it.
>>> Alan, thanks for succinctly putting why is absurd to complain about
>>> someone else's desire to write whatever code she desires to write. And
>>> to sharing it to the world! The HORROR!
>>>
>>> How *DARE* they to release their code? For free!
>>>
>> Once again, you do not understand the claim.
> It is you who does not understand how software workds. See Alan response.
>
>> If a user of Gentoo chooses to use non systemd profile, it means that
>> we need to make sure systemd will not be a valid option, ever.
> Again, you don't understand how software works: this has nothing to do
> with "profiles", it has to do with the fact that UPower now relies on
> systemd, and therefore people who has UPower installed now, *by
> default*, require systemd. If they don't want systemd, there is a way
> to do it, but it requires manual intervention since they now need to
> first uninstall UPower.
>
>> In this case, if it is to disable the upower USE flag, or to provide
>> alternative, block newer version, whatever make it possible to have a
>> system working without systemd.
> It is provided:
>
> emerge -C upower
> emerge -1v upower-pm-utils
>
> It has to be done manually, though; otherwise you step on systemd users.
>
>> systemd should not be visible at any time, nor its implications.
> Nobody is here to deal with other people's OCD.
>
> Regards.
FWIW, on my system, I had to mask "sys-apps/gentoo-systemd-integration"
for it to merge the udev update w/o trying to pull in systemd, et al.  i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from trying
to build a systemd based system.

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

On 06/03/2014 07:24 PM, Jim Burwell wrote:

> FWIW, on my system, I had to mask "sys-apps/gentoo-systemd-integration"
> for it to merge the udev update w/o trying to pull in systemd, et al.  i
> didn't deep dive on what was trying to pull that in, but masking it
> (plus a ton of other stuff I have masked) prevented portage from trying
> to build a systemd based system.
> 
> 
> 
> 

OK - I have followed the advice given in <eselect news read>; I have
also followed the advice on this and the related thread today and
uninstalled "sys-power/upower" and installed
"sys-power/upower-pm-utils".  That didn't work.  Then, given the above,
I have masked (first) "sys-apps/gentoo-systemd-integration" and when
that had no effect, masked "sys-apps/systemd."

I am still hard-blocked out of updating:

Calculating dependencies... done!
[ebuild  N     ] sys-libs/libseccomp-2.1.1  USE="-static-libs" 111 kB
[ebuild  r  U  ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
-examples -static-libs {-test}" 7,484 kB
[ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
(-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[ebuild   R   ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
[ebuild  rR    ] net-print/cups-filters-1.0.53  USE="dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf" 0 kB
[ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild  N    #] sys-apps/systemd-212-r5:0/2  USE="acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-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" 0 kB
[ebuild  N    #] sys-apps/gentoo-systemd-integration-4  52 kB
[ebuild  N     ] virtual/libudev-208:0/1  USE="-static-libs"
ABI_X86="(64) (-32) (-x32)" 0 kB
[ebuild     U  ] virtual/udev-208-r2 [208-r1] USE="gudev -introspection
-static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32) (-x32)" 0 kB
[ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc
-ios" 0 kB
[uninstall     ] sys-power/upower-pm-utils-0.9.23  USE="introspection
-doc -ios"
[blocks b      ] sys-power/upower ("sys-power/upower" is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-212-r1)
[blocks B      ] sys-apps/gentoo-systemd-integration
("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)

Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)


I'm not sure what else to mask/uninstall/reinstall at this point.  Any
suggestions?

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham <stoa@gmx.us> wrote:
> On 06/03/2014 07:24 PM, Jim Burwell wrote:
>
>> FWIW, on my system, I had to mask "sys-apps/gentoo-systemd-integration"
>> for it to merge the udev update w/o trying to pull in systemd, et al.  i
>> didn't deep dive on what was trying to pull that in, but masking it
>> (plus a ton of other stuff I have masked) prevented portage from trying
>> to build a systemd based system.
>>
>>
>>
>>
>
> OK - I have followed the advice given in <eselect news read>; I have
> also followed the advice on this and the related thread today and
> uninstalled "sys-power/upower" and installed
> "sys-power/upower-pm-utils".  That didn't work.  Then, given the above,
> I have masked (first) "sys-apps/gentoo-systemd-integration" and when
> that had no effect, masked "sys-apps/systemd."
>
> I am still hard-blocked out of updating:
>
> Calculating dependencies... done!
> [ebuild  N     ] sys-libs/libseccomp-2.1.1  USE="-static-libs" 111 kB
> [ebuild  r  U  ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
> -examples -static-libs {-test}" 7,484 kB
> [ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
> (-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
> (-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
> [ebuild   R   ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
> [1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
> [ebuild  rR    ] net-print/cups-filters-1.0.53  USE="dbus foomatic jpeg
> -perl -png -static-libs -tiff -zeroconf" 0 kB
> [ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
> [ebuild  N    #] sys-apps/systemd-212-r5:0/2  USE="acl filecaps
> firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
> -gcrypt -gudev -http -introspection (-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" 0 kB
> [ebuild  N    #] sys-apps/gentoo-systemd-integration-4  52 kB
> [ebuild  N     ] virtual/libudev-208:0/1  USE="-static-libs"
> ABI_X86="(64) (-32) (-x32)" 0 kB
> [ebuild     U  ] virtual/udev-208-r2 [208-r1] USE="gudev -introspection
> -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32) (-x32)" 0 kB
> [ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc
> -ios" 0 kB
> [uninstall     ] sys-power/upower-pm-utils-0.9.23  USE="introspection
> -doc -ios"
> [blocks b      ] sys-power/upower ("sys-power/upower" is blocking
> sys-power/upower-pm-utils-0.9.23)
> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
> sys-fs/udev-212-r1)
> [blocks B      ] sys-apps/gentoo-systemd-integration
> ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
> sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
>
> Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
> of downloads: 45,580 kB
> Conflict: 4 blocks (3 unsatisfied)
>
>
> I'm not sure what else to mask/uninstall/reinstall at this point.  Any
> suggestions?

Something is pulling upower. You need to find out what; supposedly
everything in the tree already should handle upower-pm-utils as a
upower replacement.

Perhaps try to sync again?

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
> On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham <stoa@gmx.us> wrote:
>> On 06/03/2014 07:24 PM, Jim Burwell wrote:
>>
>>> FWIW, on my system, I had to mask "sys-apps/gentoo-systemd-integration"
>>> for it to merge the udev update w/o trying to pull in systemd, et al.  i
>>> didn't deep dive on what was trying to pull that in, but masking it
>>> (plus a ton of other stuff I have masked) prevented portage from trying
>>> to build a systemd based system.
>>>
>>>
>>>
>>>
>>
>> OK - I have followed the advice given in <eselect news read>; I have
>> also followed the advice on this and the related thread today and
>> uninstalled "sys-power/upower" and installed
>> "sys-power/upower-pm-utils".  That didn't work.  Then, given the above,
>> I have masked (first) "sys-apps/gentoo-systemd-integration" and when
>> that had no effect, masked "sys-apps/systemd."
>>
>> I am still hard-blocked out of updating:
>>
>> Calculating dependencies... done!
>> [ebuild  N     ] sys-libs/libseccomp-2.1.1  USE="-static-libs" 111 kB
>> [ebuild  r  U  ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
>> -examples -static-libs {-test}" 7,484 kB
>> [ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
>> (-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
>> (-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
>> [ebuild   R   ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
>> [1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
>> [ebuild  rR    ] net-print/cups-filters-1.0.53  USE="dbus foomatic jpeg
>> -perl -png -static-libs -tiff -zeroconf" 0 kB
>> [ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
>> [ebuild  N    #] sys-apps/systemd-212-r5:0/2  USE="acl filecaps
>> firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
>> -gcrypt -gudev -http -introspection (-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" 0 kB
>> [ebuild  N    #] sys-apps/gentoo-systemd-integration-4  52 kB
>> [ebuild  N     ] virtual/libudev-208:0/1  USE="-static-libs"
>> ABI_X86="(64) (-32) (-x32)" 0 kB
>> [ebuild     U  ] virtual/udev-208-r2 [208-r1] USE="gudev -introspection
>> -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32) (-x32)" 0 kB
>> [ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc
>> -ios" 0 kB
>> [uninstall     ] sys-power/upower-pm-utils-0.9.23  USE="introspection
>> -doc -ios"
>> [blocks b      ] sys-power/upower ("sys-power/upower" is blocking
>> sys-power/upower-pm-utils-0.9.23)
>> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
>> sys-fs/udev-212-r1)
>> [blocks B      ] sys-apps/gentoo-systemd-integration
>> ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
>> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
>> sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
>>
>> Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
>> of downloads: 45,580 kB
>> Conflict: 4 blocks (3 unsatisfied)
>>
>>
>> I'm not sure what else to mask/uninstall/reinstall at this point.  Any
>> suggestions?
> 
> Something is pulling upower. You need to find out what; supposedly
> everything in the tree already should handle upower-pm-utils as a
> upower replacement.
> 
> Perhaps try to sync again?
> 
> Regards.
> 
Thanks, Canek.

I did re-sync, with the same results.  I also ran a <equery depends
upower> with the following result:

dutch@gentoo ~ $ sudo equery depends upower
 * These packages depend on upower:
mate-base/mate-applets-1.6.2-r1 (>=sys-power/upower-0.9.4)
                                (<sys-power/upower-0.99)
mate-base/mate-session-manager-1.6.1-r1 (>=sys-power/upower-0.9.0)
mate-extra/mate-power-manager-1.6.3 (>=sys-power/upower-0.9.1)
xfce-base/xfce4-session-4.10.1-r1 (udev ? <sys-power/upower-0.99)
xfce-extra/xfce4-power-manager-1.2.0-r2 (<sys-power/upower-0.99)
dutch@gentoo ~ $

But as you said, "upower-pm-utils" should be handling these
dependencies.  Is anyone else having these problems with MATE or XFCE?

Re: [gentoo-user] Systemd upower

[Michael Cook]

On 06/03/2014 09:48 PM, Dutch Ingraham wrote:
> On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
>> On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham <stoa@gmx.us> wrote:
>>> On 06/03/2014 07:24 PM, Jim Burwell wrote:
>>>
>>>> FWIW, on my system, I had to mask "sys-apps/gentoo-systemd-integration"
>>>> for it to merge the udev update w/o trying to pull in systemd, et al.  i
>>>> didn't deep dive on what was trying to pull that in, but masking it
>>>> (plus a ton of other stuff I have masked) prevented portage from trying
>>>> to build a systemd based system.
>>>>
>>>>
>>>>
>>>>
>>>
>>> OK - I have followed the advice given in <eselect news read>; I have
>>> also followed the advice on this and the related thread today and
>>> uninstalled "sys-power/upower" and installed
>>> "sys-power/upower-pm-utils".  That didn't work.  Then, given the above,
>>> I have masked (first) "sys-apps/gentoo-systemd-integration" and when
>>> that had no effect, masked "sys-apps/systemd."
>>>
>>> I am still hard-blocked out of updating:
>>>
>>> Calculating dependencies... done!
>>> [ebuild  N     ] sys-libs/libseccomp-2.1.1  USE="-static-libs" 111 kB
>>> [ebuild  r  U  ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
>>> -examples -static-libs {-test}" 7,484 kB
>>> [ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
>>> (-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
>>> (-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
>>> [ebuild   R   ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
>>> [1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
>>> [ebuild  rR    ] net-print/cups-filters-1.0.53  USE="dbus foomatic jpeg
>>> -perl -png -static-libs -tiff -zeroconf" 0 kB
>>> [ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
>>> [ebuild  N    #] sys-apps/systemd-212-r5:0/2  USE="acl filecaps
>>> firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
>>> -gcrypt -gudev -http -introspection (-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" 0 kB
>>> [ebuild  N    #] sys-apps/gentoo-systemd-integration-4  52 kB
>>> [ebuild  N     ] virtual/libudev-208:0/1  USE="-static-libs"
>>> ABI_X86="(64) (-32) (-x32)" 0 kB
>>> [ebuild     U  ] virtual/udev-208-r2 [208-r1] USE="gudev -introspection
>>> -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32) (-x32)" 0 kB
>>> [ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc
>>> -ios" 0 kB
>>> [uninstall     ] sys-power/upower-pm-utils-0.9.23  USE="introspection
>>> -doc -ios"
>>> [blocks b      ] sys-power/upower ("sys-power/upower" is blocking
>>> sys-power/upower-pm-utils-0.9.23)
>>> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
>>> sys-fs/udev-212-r1)
>>> [blocks B      ] sys-apps/gentoo-systemd-integration
>>> ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
>>> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
>>> sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
>>>
>>> Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
>>> of downloads: 45,580 kB
>>> Conflict: 4 blocks (3 unsatisfied)
>>>
>>>
>>> I'm not sure what else to mask/uninstall/reinstall at this point.  Any
>>> suggestions?
>>
>> Something is pulling upower. You need to find out what; supposedly
>> everything in the tree already should handle upower-pm-utils as a
>> upower replacement.
>>
>> Perhaps try to sync again?
>>
>> Regards.
>>
> Thanks, Canek.
>
> I did re-sync, with the same results.  I also ran a <equery depends
> upower> with the following result:
>
> dutch@gentoo ~ $ sudo equery depends upower
>   * These packages depend on upower:
> mate-base/mate-applets-1.6.2-r1 (>=sys-power/upower-0.9.4)
>                                  (<sys-power/upower-0.99)
> mate-base/mate-session-manager-1.6.1-r1 (>=sys-power/upower-0.9.0)
> mate-extra/mate-power-manager-1.6.3 (>=sys-power/upower-0.9.1)
> xfce-base/xfce4-session-4.10.1-r1 (udev ? <sys-power/upower-0.99)
> xfce-extra/xfce4-power-manager-1.2.0-r2 (<sys-power/upower-0.99)
> dutch@gentoo ~ $
>
> But as you said, "upower-pm-utils" should be handling these
> dependencies.  Is anyone else having these problems with MATE or XFCE?
>
>
Do you have newer sys-fs/udev masked by chance? What version do you have 
installed? I noticed the MATE stuff is in an overlay, so it might take a 
bit longer for them to make things right.

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

On 06/03/2014 09:57 PM, Michael Cook wrote:
> On 06/03/2014 09:48 PM, Dutch Ingraham wrote:
>> On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
>>> On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham <stoa@gmx.us> wrote:
>>>> On 06/03/2014 07:24 PM, Jim Burwell wrote:
>>>>
>>>>> FWIW, on my system, I had to mask
>>>>> "sys-apps/gentoo-systemd-integration"
>>>>> for it to merge the udev update w/o trying to pull in systemd, et
>>>>> al.  i
>>>>> didn't deep dive on what was trying to pull that in, but masking it
>>>>> (plus a ton of other stuff I have masked) prevented portage from
>>>>> trying
>>>>> to build a systemd based system.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> OK - I have followed the advice given in <eselect news read>; I have
>>>> also followed the advice on this and the related thread today and
>>>> uninstalled "sys-power/upower" and installed
>>>> "sys-power/upower-pm-utils".  That didn't work.  Then, given the above,
>>>> I have masked (first) "sys-apps/gentoo-systemd-integration" and when
>>>> that had no effect, masked "sys-apps/systemd."
>>>>
>>>> I am still hard-blocked out of updating:
>>>>
>>>> Calculating dependencies... done!
>>>> [ebuild  N     ] sys-libs/libseccomp-2.1.1  USE="-static-libs" 111 kB
>>>> [ebuild  r  U  ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
>>>> -examples -static-libs {-test}" 7,484 kB
>>>> [ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
>>>> (-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
>>>> (-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
>>>> [ebuild   R   ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
>>>> [1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
>>>> [ebuild  rR    ] net-print/cups-filters-1.0.53  USE="dbus foomatic jpeg
>>>> -perl -png -static-libs -tiff -zeroconf" 0 kB
>>>> [ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831]
>>>> 37,935 kB
>>>> [ebuild  N    #] sys-apps/systemd-212-r5:0/2  USE="acl filecaps
>>>> firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
>>>> -gcrypt -gudev -http -introspection (-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" 0 kB
>>>> [ebuild  N    #] sys-apps/gentoo-systemd-integration-4  52 kB
>>>> [ebuild  N     ] virtual/libudev-208:0/1  USE="-static-libs"
>>>> ABI_X86="(64) (-32) (-x32)" 0 kB
>>>> [ebuild     U  ] virtual/udev-208-r2 [208-r1] USE="gudev -introspection
>>>> -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32) (-x32)" 0 kB
>>>> [ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc
>>>> -ios" 0 kB
>>>> [uninstall     ] sys-power/upower-pm-utils-0.9.23  USE="introspection
>>>> -doc -ios"
>>>> [blocks b      ] sys-power/upower ("sys-power/upower" is blocking
>>>> sys-power/upower-pm-utils-0.9.23)
>>>> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
>>>> sys-fs/udev-212-r1)
>>>> [blocks B      ] sys-apps/gentoo-systemd-integration
>>>> ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
>>>> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
>>>> sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
>>>>
>>>> Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
>>>> of downloads: 45,580 kB
>>>> Conflict: 4 blocks (3 unsatisfied)
>>>>
>>>>
>>>> I'm not sure what else to mask/uninstall/reinstall at this point.  Any
>>>> suggestions?
>>>
>>> Something is pulling upower. You need to find out what; supposedly
>>> everything in the tree already should handle upower-pm-utils as a
>>> upower replacement.
>>>
>>> Perhaps try to sync again?
>>>
>>> Regards.
>>>
>> Thanks, Canek.
>>
>> I did re-sync, with the same results.  I also ran a <equery depends
>> upower> with the following result:
>>
>> dutch@gentoo ~ $ sudo equery depends upower
>>   * These packages depend on upower:
>> mate-base/mate-applets-1.6.2-r1 (>=sys-power/upower-0.9.4)
>>                                  (<sys-power/upower-0.99)
>> mate-base/mate-session-manager-1.6.1-r1 (>=sys-power/upower-0.9.0)
>> mate-extra/mate-power-manager-1.6.3 (>=sys-power/upower-0.9.1)
>> xfce-base/xfce4-session-4.10.1-r1 (udev ? <sys-power/upower-0.99)
>> xfce-extra/xfce4-power-manager-1.2.0-r2 (<sys-power/upower-0.99)
>> dutch@gentoo ~ $
>>
>> But as you said, "upower-pm-utils" should be handling these
>> dependencies.  Is anyone else having these problems with MATE or XFCE?
>>
>>
> Do you have newer sys-fs/udev masked by chance? What version do you have
> installed? I noticed the MATE stuff is in an overlay, so it might take a
> bit longer for them to make things right.
> 
> 
No, "sys-fs/udev" is not masked, but an update is indicated in the
emerge above.  That's a good catch, the MATE stuff is from the overlay.
 Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 04/06/14 05:17, Dutch Ingraham wrote:
> No, "sys-fs/udev" is not masked, but an update is indicated in the
> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>  Unfortunately, the xfce stuff is not, so even if the overlay currency
> was an issue, I'll still be showing some dependencies.
>

Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage

- Samuli

Re: [gentoo-user] Systemd upower

[Daniel Troeder]

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

Am 04.06.2014 06:05, schrieb Samuli Suominen:
> 
> On 04/06/14 05:17, Dutch Ingraham wrote:
>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>> was an issue, I'll still be showing some dependencies.
>>
> 
> Try re-emerging on un-emerging the offending packages, like
> xfce4-session and xfce4-power-manager,
> it has helped some people, to refresh the .ebuild copy that is installed
> with the .ebuild copy from
> Portage
> 
> - Samuli
> 
Thanks - that fixed it for me:

# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin


Greetings
Daniel

-- 
Get my PGP key at:
*
http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x837FB8B5BB9D4887
* $ gpg --recv-keys --keyserver keyserver.ubuntu.com 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-user] Systemd upower

[Daniel Troeder]

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

Am 04.06.2014 13:22, schrieb Daniel Troeder:
> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>
>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>> was an issue, I'll still be showing some dependencies.
>>>
>>
>> Try re-emerging on un-emerging the offending packages, like
>> xfce4-session and xfce4-power-manager,
>> it has helped some people, to refresh the .ebuild copy that is installed
>> with the .ebuild copy from
>> Portage
>>
>> - Samuli
>>
> Thanks - that fixed it for me:
> 
> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
> xfce-extra/xfce4-systemload-plugin
> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
> xfce-extra/xfce4-systemload-plugin
> 
> 
> Greetings
> Daniel
> 
BTW: I also had to unmerge gnome-base/gnome-control-center and
gnome-base/gnome-settings-daemon and mask all gnome-* >3.10



-- 
Get my PGP key at:
*
http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x837FB8B5BB9D4887
* $ gpg --recv-keys --keyserver keyserver.ubuntu.com 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 04/06/14 15:15, Daniel Troeder wrote:
> Am 04.06.2014 13:22, schrieb Daniel Troeder:
>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>> was an issue, I'll still be showing some dependencies.
>>>>
>>> Try re-emerging on un-emerging the offending packages, like
>>> xfce4-session and xfce4-power-manager,
>>> it has helped some people, to refresh the .ebuild copy that is installed
>>> with the .ebuild copy from
>>> Portage
>>>
>>> - Samuli
>>>
>> Thanks - that fixed it for me:
>>
>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>> xfce-extra/xfce4-systemload-plugin
>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>> xfce-extra/xfce4-systemload-plugin
>>
>>
>> Greetings
>> Daniel
>>
> BTW: I also had to unmerge gnome-base/gnome-control-center and
> gnome-base/gnome-settings-daemon and mask all gnome-* >3.10
>
>
>

Yes, GNOME 3.12 is the first desktop in Portage that is forcing
>=sys-power/upower-0.99.0, therefore
GNOME 3.12 can't be installed together with sys-power/upower-pm-utils

It's expected that more and more packages will start requiring
>=sys-power/upower-0.99.0, so this
sys-power/upower-pm-utils, is to be considered as a temporary solution,
specially considering it has
no upstream anymore

So, if package you need sys-power/upower-pm-utils for, doesn't migrate
it's code like Xfce did and
directly use sys-power/pm-utils, so that it allows 0.99.0 installation,
the package is bound to die

That's the whole point of this requirement for manual intervention of
user, he needs to make an
informed decision what route he wants to go -- like extreme route, such
as switching desktops from
LXDE to Xfce, and such

(This reply is not directly aimed at you, but to whole thread, just
trying to raise public awareness,
because maybe it will get someone to actually contribute some code to
improve the situation)

- Samuli

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

On 06/04/2014 07:22 AM, Daniel Troeder wrote:
> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>
>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>> was an issue, I'll still be showing some dependencies.
>>>
>>
>> Try re-emerging on un-emerging the offending packages, like
>> xfce4-session and xfce4-power-manager,
>> it has helped some people, to refresh the .ebuild copy that is installed
>> with the .ebuild copy from
>> Portage
>>
>> - Samuli
>>
> Thanks - that fixed it for me:
> 
> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
> xfce-extra/xfce4-systemload-plugin
> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
> xfce-extra/xfce4-systemload-plugin
> 
> 
> Greetings
> Daniel
> 

Unfortunately, this doesn't work for me.  So let me re-cap:  I have

1. removed upower and installed upower-pm-utils; that did not work;
2. masked first gentoo-systemd-integration, which didn't work, then
masked systemd as well; that hasn't worked;
3. ran "equery depends upower" and removed the remaining
upower-dependent MATE and XFCE packages; that has not worked;
4. masked virtual/udev-208-r2; that has not worked.

I am still left with:

"Calculating dependencies... done!
[ebuild  N     ] sys-libs/libseccomp-2.1.1  USE="-static-libs" 111 kB
[ebuild  r  U  ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
-examples -static-libs {-test}" 7,484 kB
[ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
(-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[ebuild   R   ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
[ebuild  rR    ] net-print/cups-filters-1.0.53  USE="dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf" 0 kB
[ebuild  N    #] sys-apps/systemd-212-r5:0/2  USE="acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-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" 0 kB
[ebuild  N    #] sys-apps/gentoo-systemd-integration-4  52 kB
[ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc
-ios" 0 kB
[uninstall     ] sys-power/upower-pm-utils-0.9.23  USE="introspection
-doc -ios"
[blocks b      ] sys-power/upower ("sys-power/upower" is blocking
sys-power/upower-pm-utils-0.9.23)
[ebuild  N     ] xfce-base/xfce4-session-4.10.1-r1  USE="nls udev
xscreensaver -debug -systemd" 0 kB
[ebuild  N     ] mate-base/mate-applets-1.6.2-r1  USE="X ipv6 policykit
-networkmanager" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)"
PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE="applet policykit -gnome-keyring -man {-test}" 0 kB
[ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE="ipv6 -debug -systemd" 0 kB
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-212-r1)
[blocks B      ] sys-apps/gentoo-systemd-integration
("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)

Total: 13 packages (2 upgrades, 8 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)"

Does anyone have any further suggestions?

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 04/06/14 20:11, Dutch Ingraham wrote:
> On 06/04/2014 07:22 AM, Daniel Troeder wrote:
>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>> was an issue, I'll still be showing some dependencies.
>>>>
>>> Try re-emerging on un-emerging the offending packages, like
>>> xfce4-session and xfce4-power-manager,
>>> it has helped some people, to refresh the .ebuild copy that is installed
>>> with the .ebuild copy from
>>> Portage
>>>
>>> - Samuli
>>>
>> Thanks - that fixed it for me:
>>
>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>> xfce-extra/xfce4-systemload-plugin
>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>> xfce-extra/xfce4-systemload-plugin
>>
>>
>> Greetings
>> Daniel
>>
> Unfortunately, this doesn't work for me.  So let me re-cap:  I have
>
> 4. masked virtual/udev-208-r2; that has not worked.

First, remove that mask. Masking it will certainly cause more blockers,
than solve them.

> [ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
> USE="applet policykit -gnome-keyring -man {-test}" 0 kB
> [ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
> USE="ipv6 -debug -systemd" 0 kB
>

see "::mate-overlay", it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:

/etc/portage/package.mask

mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay

- Samuli

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

On 06/04/2014 03:17 PM, Samuli Suominen wrote:
> 
> On 04/06/14 20:11, Dutch Ingraham wrote:
>> On 06/04/2014 07:22 AM, Daniel Troeder wrote:
>>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>>> was an issue, I'll still be showing some dependencies.
>>>>>
>>>> Try re-emerging on un-emerging the offending packages, like
>>>> xfce4-session and xfce4-power-manager,
>>>> it has helped some people, to refresh the .ebuild copy that is installed
>>>> with the .ebuild copy from
>>>> Portage
>>>>
>>>> - Samuli
>>>>
>>> Thanks - that fixed it for me:
>>>
>>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>>> xfce-extra/xfce4-systemload-plugin
>>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>>> xfce-extra/xfce4-systemload-plugin
>>>
>>>
>>> Greetings
>>> Daniel
>>>
>> Unfortunately, this doesn't work for me.  So let me re-cap:  I have
>>
>> 4. masked virtual/udev-208-r2; that has not worked.
> 
> First, remove that mask. Masking it will certainly cause more blockers,
> than solve them.
> 
>> [ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
>> USE="applet policykit -gnome-keyring -man {-test}" 0 kB
>> [ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
>> USE="ipv6 -debug -systemd" 0 kB
>>
> 
> see "::mate-overlay", it's presumably broken or outdated. stop using the
> overlay and use MATE from Portage instead.
> or you can mask the packages from overlay, the syntax is like:
> 
> /etc/portage/package.mask
> 
> mate-extra/mate-power-manager::mate-overlay
> mate-base/mate-session-manager::mate-overlay
> 
> - Samuli
> 
> 

Thanks everybody for your help.  I've made the further suggested
changes, but I remain with the three hard blocks.

I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update.  I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.

I suppose its now time for an uninstall.  Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true.  I made the
choice to use a pure openRC system.  The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.

The sine qua non is unarguably systemd.  Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it.  Quite the inelegant
end to my once-trusty OS.

Re: [gentoo-user] Systemd upower

[Alon Bar-Lev]

On Thu, Jun 5, 2014 at 2:15 AM, Dutch Ingraham <stoa@gmx.us> wrote:
> On 06/04/2014 03:17 PM, Samuli Suominen wrote:
>>
>> On 04/06/14 20:11, Dutch Ingraham wrote:
>>> On 06/04/2014 07:22 AM, Daniel Troeder wrote:
>>>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>>>> was an issue, I'll still be showing some dependencies.
>>>>>>
>>>>> Try re-emerging on un-emerging the offending packages, like
>>>>> xfce4-session and xfce4-power-manager,
>>>>> it has helped some people, to refresh the .ebuild copy that is installed
>>>>> with the .ebuild copy from
>>>>> Portage
>>>>>
>>>>> - Samuli
>>>>>
>>>> Thanks - that fixed it for me:
>>>>
>>>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>>>> xfce-extra/xfce4-systemload-plugin
>>>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>>>> xfce-extra/xfce4-systemload-plugin
>>>>
>>>>
>>>> Greetings
>>>> Daniel
>>>>
>>> Unfortunately, this doesn't work for me.  So let me re-cap:  I have
>>>
>>> 4. masked virtual/udev-208-r2; that has not worked.
>>
>> First, remove that mask. Masking it will certainly cause more blockers,
>> than solve them.
>>
>>> [ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
>>> USE="applet policykit -gnome-keyring -man {-test}" 0 kB
>>> [ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
>>> USE="ipv6 -debug -systemd" 0 kB
>>>
>>
>> see "::mate-overlay", it's presumably broken or outdated. stop using the
>> overlay and use MATE from Portage instead.
>> or you can mask the packages from overlay, the syntax is like:
>>
>> /etc/portage/package.mask
>>
>> mate-extra/mate-power-manager::mate-overlay
>> mate-base/mate-session-manager::mate-overlay
>>
>> - Samuli
>>
>>
>
> Thanks everybody for your help.  I've made the further suggested
> changes, but I remain with the three hard blocks.
>
> I've now spent about 7 hours over the last two days on this issue (about
> 2x the fresh install time), when all I wanted to do was a routine
> update.  I've reworked a large part of my system, adding a new
> package.mask file and populating it with six packages.
>
> I suppose its now time for an uninstall.  Kind of disappointing; we are
> told Gentoo is about choices, and in fact that's true.  I made the
> choice to use a pure openRC system.  The last 7 hours of free time,
> though, was spent trying, and ultimately failing, to correct a problem
> not chosen, not wanted, and not invited.
>
> The sine qua non is unarguably systemd.  Even though my choice was to
> not deploy it, apparently it takes a significant time commitment and/or
> developer-level knowledge to choose to not use it.  Quite the inelegant
> end to my once-trusty OS.
>

You are right, all I can say is that I am sorry we treat users like
that. We forget that our task is to ease deployment of upstream
projects to end users. What we experience is only the start of the
mess of having two separate contradictory layouts within stable tree,
without decent profile setups to protect users from pulling layout
they are not interested in.

Alon

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 05/06/14 02:25, Alon Bar-Lev wrote:
> On Thu, Jun 5, 2014 at 2:15 AM, Dutch Ingraham <stoa@gmx.us> wrote:
>> On 06/04/2014 03:17 PM, Samuli Suominen wrote:
>>> On 04/06/14 20:11, Dutch Ingraham wrote:
>>>> On 06/04/2014 07:22 AM, Daniel Troeder wrote:
>>>>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>>>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>>>>> was an issue, I'll still be showing some dependencies.
>>>>>>>
>>>>>> Try re-emerging on un-emerging the offending packages, like
>>>>>> xfce4-session and xfce4-power-manager,
>>>>>> it has helped some people, to refresh the .ebuild copy that is installed
>>>>>> with the .ebuild copy from
>>>>>> Portage
>>>>>>
>>>>>> - Samuli
>>>>>>
>>>>> Thanks - that fixed it for me:
>>>>>
>>>>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>>>>> xfce-extra/xfce4-systemload-plugin
>>>>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>>>>> xfce-extra/xfce4-systemload-plugin
>>>>>
>>>>>
>>>>> Greetings
>>>>> Daniel
>>>>>
>>>> Unfortunately, this doesn't work for me.  So let me re-cap:  I have
>>>>
>>>> 4. masked virtual/udev-208-r2; that has not worked.
>>> First, remove that mask. Masking it will certainly cause more blockers,
>>> than solve them.
>>>
>>>> [ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
>>>> USE="applet policykit -gnome-keyring -man {-test}" 0 kB
>>>> [ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
>>>> USE="ipv6 -debug -systemd" 0 kB
>>>>
>>> see "::mate-overlay", it's presumably broken or outdated. stop using the
>>> overlay and use MATE from Portage instead.
>>> or you can mask the packages from overlay, the syntax is like:
>>>
>>> /etc/portage/package.mask
>>>
>>> mate-extra/mate-power-manager::mate-overlay
>>> mate-base/mate-session-manager::mate-overlay
>>>
>>> - Samuli
>>>
>>>
>> Thanks everybody for your help.  I've made the further suggested
>> changes, but I remain with the three hard blocks.
>>
>> I've now spent about 7 hours over the last two days on this issue (about
>> 2x the fresh install time), when all I wanted to do was a routine
>> update.  I've reworked a large part of my system, adding a new
>> package.mask file and populating it with six packages.
>>
>> I suppose its now time for an uninstall.  Kind of disappointing; we are
>> told Gentoo is about choices, and in fact that's true.  I made the
>> choice to use a pure openRC system.  The last 7 hours of free time,
>> though, was spent trying, and ultimately failing, to correct a problem
>> not chosen, not wanted, and not invited.
>>
>> The sine qua non is unarguably systemd.  Even though my choice was to
>> not deploy it, apparently it takes a significant time commitment and/or
>> developer-level knowledge to choose to not use it.  Quite the inelegant
>> end to my once-trusty OS.
>>
> You are right, all I can say is that I am sorry we treat users like
> that. We forget that our task is to ease deployment of upstream
> projects to end users. What we experience is only the start of the
> mess of having two separate contradictory layouts within stable tree,
> without decent profile setups to protect users from pulling layout
> they are not interested in.
>
>

We? The ::mate-overlay maintainers? You are involved in the
::mate-overlay development then?

Re: [gentoo-user] Systemd upower

[Alon Bar-Lev]

On Thu, Jun 5, 2014 at 3:07 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>
> On 05/06/14 02:25, Alon Bar-Lev wrote:
>> On Thu, Jun 5, 2014 at 2:15 AM, Dutch Ingraham <stoa@gmx.us> wrote:
>>> On 06/04/2014 03:17 PM, Samuli Suominen wrote:
>>>> On 04/06/14 20:11, Dutch Ingraham wrote:
>>>>> On 06/04/2014 07:22 AM, Daniel Troeder wrote:
>>>>>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>>>>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>>>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>>>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>>>>>> was an issue, I'll still be showing some dependencies.
>>>>>>>>
>>>>>>> Try re-emerging on un-emerging the offending packages, like
>>>>>>> xfce4-session and xfce4-power-manager,
>>>>>>> it has helped some people, to refresh the .ebuild copy that is installed
>>>>>>> with the .ebuild copy from
>>>>>>> Portage
>>>>>>>
>>>>>>> - Samuli
>>>>>>>
>>>>>> Thanks - that fixed it for me:
>>>>>>
>>>>>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>>>>>> xfce-extra/xfce4-systemload-plugin
>>>>>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>>>>>> xfce-extra/xfce4-systemload-plugin
>>>>>>
>>>>>>
>>>>>> Greetings
>>>>>> Daniel
>>>>>>
>>>>> Unfortunately, this doesn't work for me.  So let me re-cap:  I have
>>>>>
>>>>> 4. masked virtual/udev-208-r2; that has not worked.
>>>> First, remove that mask. Masking it will certainly cause more blockers,
>>>> than solve them.
>>>>
>>>>> [ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
>>>>> USE="applet policykit -gnome-keyring -man {-test}" 0 kB
>>>>> [ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
>>>>> USE="ipv6 -debug -systemd" 0 kB
>>>>>
>>>> see "::mate-overlay", it's presumably broken or outdated. stop using the
>>>> overlay and use MATE from Portage instead.
>>>> or you can mask the packages from overlay, the syntax is like:
>>>>
>>>> /etc/portage/package.mask
>>>>
>>>> mate-extra/mate-power-manager::mate-overlay
>>>> mate-base/mate-session-manager::mate-overlay
>>>>
>>>> - Samuli
>>>>
>>>>
>>> Thanks everybody for your help.  I've made the further suggested
>>> changes, but I remain with the three hard blocks.
>>>
>>> I've now spent about 7 hours over the last two days on this issue (about
>>> 2x the fresh install time), when all I wanted to do was a routine
>>> update.  I've reworked a large part of my system, adding a new
>>> package.mask file and populating it with six packages.
>>>
>>> I suppose its now time for an uninstall.  Kind of disappointing; we are
>>> told Gentoo is about choices, and in fact that's true.  I made the
>>> choice to use a pure openRC system.  The last 7 hours of free time,
>>> though, was spent trying, and ultimately failing, to correct a problem
>>> not chosen, not wanted, and not invited.
>>>
>>> The sine qua non is unarguably systemd.  Even though my choice was to
>>> not deploy it, apparently it takes a significant time commitment and/or
>>> developer-level knowledge to choose to not use it.  Quite the inelegant
>>> end to my once-trusty OS.
>>>
>> You are right, all I can say is that I am sorry we treat users like
>> that. We forget that our task is to ease deployment of upstream
>> projects to end users. What we experience is only the start of the
>> mess of having two separate contradictory layouts within stable tree,
>> without decent profile setups to protect users from pulling layout
>> they are not interested in.
>>
>>
>
> We? The ::mate-overlay maintainers? You are involved in the
> ::mate-overlay development then?
>

This effected stable tree of Gentoo as well, pulling undesired
different layout into stable is something that should have been
avoided. It is about time we split the profiles, systemd is not option
for people who runs openrc.

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 05/06/14 03:22, Alon Bar-Lev wrote:
> This effected stable tree of Gentoo as well, pulling undesired
> different layout into stable is something that should have been
> avoided. It is about time we split the profiles, systemd is not option
> for people who runs openrc. 

Indeed, I support the idea of having separate systemd profiles too,
could have simply
dropped a package.mask entry in base/ then, and then counter-effected it
in systemd
profiles

- Samuli

Re: [gentoo-user] Systemd upower

[Rich Freeman]

On Wed, Jun 4, 2014 at 8:46 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>
> On 05/06/14 03:22, Alon Bar-Lev wrote:
>> This effected stable tree of Gentoo as well, pulling undesired
>> different layout into stable is something that should have been
>> avoided. It is about time we split the profiles, systemd is not option
>> for people who runs openrc.
>
> Indeed, I support the idea of having separate systemd profiles too,
> could have simply
> dropped a package.mask entry in base/ then, and then counter-effected it
> in systemd
> profiles

There is apparently an interest in building a profile which doesn't
install openrc (which still needs some work), so you might eventually
get your wish.

Rich

Re: [gentoo-user] Systemd upower

[Neil Bothwick]

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

On Wed, 04 Jun 2014 19:15:22 -0400, Dutch Ingraham wrote:

> I suppose its now time for an uninstall.  Kind of disappointing; we are
> told Gentoo is about choices, and in fact that's true.  I made the
> choice to use a pure openRC system.  The last 7 hours of free time,
> though, was spent trying, and ultimately failing, to correct a problem
> not chosen, not wanted, and not invited.

...and not of Gentoo's doing. You are trying to blame Gentoo for a
problem arising from an overlay. A more productive use of your time would
be to inform the overlay's maintainers about your problem and request a
fix, which may well be a simple ebuild tweak.


-- 
Neil Bothwick

...and that is how we know the Earth to be banana-shaped.

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

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Thu, 5 Jun 2014 00:27:28 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Wed, 04 Jun 2014 19:15:22 -0400, Dutch Ingraham wrote:
> 
> > I suppose its now time for an uninstall.  Kind of disappointing; we
> > are told Gentoo is about choices, and in fact that's true.  I made
> > the choice to use a pure openRC system.  The last 7 hours of free
> > time, though, was spent trying, and ultimately failing, to correct
> > a problem not chosen, not wanted, and not invited.
> 
> ...and not of Gentoo's doing. You are trying to blame Gentoo for a
> problem arising from an overlay. A more productive use of your time
> would be to inform the overlay's maintainers about your problem and
> request a fix, which may well be a simple ebuild tweak.

It has been fixed two days ago; so, Ingraham needs to sync the overlay:

https://github.com/Sabayon/mate-overlay/commit/0e4acf73e81083d87d43e2a0b0be2b959f1e6a78

A news item was put out that it was being migrated to the Portage tree:

https://github.com/Sabayon/mate-overlay/blob/master/metadata/news/2014-02-21-portage-import/2014-02-21-portage-import.en.txt

And they are now planning to retire the overlay to make people switch:

https://github.com/Sabayon/mate-overlay/issues/76

-- 
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-user] Systemd upower

[Samuli Suominen]

On 05/06/14 02:15, Dutch Ingraham wrote:
> On 06/04/2014 03:17 PM, Samuli Suominen wrote:
>> On 04/06/14 20:11, Dutch Ingraham wrote:
>>> On 06/04/2014 07:22 AM, Daniel Troeder wrote:
>>>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>>>> was an issue, I'll still be showing some dependencies.
>>>>>>
>>>>> Try re-emerging on un-emerging the offending packages, like
>>>>> xfce4-session and xfce4-power-manager,
>>>>> it has helped some people, to refresh the .ebuild copy that is installed
>>>>> with the .ebuild copy from
>>>>> Portage
>>>>>
>>>>> - Samuli
>>>>>
>>>> Thanks - that fixed it for me:
>>>>
>>>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>>>> xfce-extra/xfce4-systemload-plugin
>>>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>>>> xfce-extra/xfce4-systemload-plugin
>>>>
>>>>
>>>> Greetings
>>>> Daniel
>>>>
>>> Unfortunately, this doesn't work for me.  So let me re-cap:  I have
>>>
>>> 4. masked virtual/udev-208-r2; that has not worked.
>> First, remove that mask. Masking it will certainly cause more blockers,
>> than solve them.
>>
>>> [ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
>>> USE="applet policykit -gnome-keyring -man {-test}" 0 kB
>>> [ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
>>> USE="ipv6 -debug -systemd" 0 kB
>>>
>> see "::mate-overlay", it's presumably broken or outdated. stop using the
>> overlay and use MATE from Portage instead.
>> or you can mask the packages from overlay, the syntax is like:
>>
>> /etc/portage/package.mask
>>
>> mate-extra/mate-power-manager::mate-overlay
>> mate-base/mate-session-manager::mate-overlay
>>
>> - Samuli
>>
>>
> Thanks everybody for your help.  I've made the further suggested
> changes, but I remain with the three hard blocks.
>
> I've now spent about 7 hours over the last two days on this issue (about
> 2x the fresh install time), when all I wanted to do was a routine
> update.  I've reworked a large part of my system, adding a new
> package.mask file and populating it with six packages.
>
> I suppose its now time for an uninstall.  Kind of disappointing; we are
> told Gentoo is about choices, and in fact that's true.  I made the
> choice to use a pure openRC system.  The last 7 hours of free time,
> though, was spent trying, and ultimately failing, to correct a problem
> not chosen, not wanted, and not invited.
>
> The sine qua non is unarguably systemd.  Even though my choice was to
> not deploy it, apparently it takes a significant time commitment and/or
> developer-level knowledge to choose to not use it.  Quite the inelegant
> end to my once-trusty OS.
>

Gentoo doesn't have write access to ::mate-overlay, it's completely
unofficial
Gentoo developers are just as much users as you are for ::mate-overlay

Enough said

- Samuli

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

On 06/04/2014 08:02 PM, Samuli Suominen wrote:
> 
> On 05/06/14 02:15, Dutch Ingraham wrote:
>> On 06/04/2014 03:17 PM, Samuli Suominen wrote:
>>> On 04/06/14 20:11, Dutch Ingraham wrote:
>>>> On 06/04/2014 07:22 AM, Daniel Troeder wrote:
>>>>> Am 04.06.2014 06:05, schrieb Samuli Suominen:
>>>>>> On 04/06/14 05:17, Dutch Ingraham wrote:
>>>>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the
>>>>>>> emerge above.  That's a good catch, the MATE stuff is from the overlay.
>>>>>>>  Unfortunately, the xfce stuff is not, so even if the overlay currency
>>>>>>> was an issue, I'll still be showing some dependencies.
>>>>>>>
>>>>>> Try re-emerging on un-emerging the offending packages, like
>>>>>> xfce4-session and xfce4-power-manager,
>>>>>> it has helped some people, to refresh the .ebuild copy that is installed
>>>>>> with the .ebuild copy from
>>>>>> Portage
>>>>>>
>>>>>> - Samuli
>>>>>>
>>>>> Thanks - that fixed it for me:
>>>>>
>>>>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
>>>>> xfce-extra/xfce4-systemload-plugin
>>>>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
>>>>> xfce-extra/xfce4-systemload-plugin
>>>>>
>>>>>
>>>>> Greetings
>>>>> Daniel
>>>>>
>>>> Unfortunately, this doesn't work for me.  So let me re-cap:  I have
>>>>
>>>> 4. masked virtual/udev-208-r2; that has not worked.
>>> First, remove that mask. Masking it will certainly cause more blockers,
>>> than solve them.
>>>
>>>> [ebuild  N    ~] mate-extra/mate-power-manager-1.6.3::mate-overlay
>>>> USE="applet policykit -gnome-keyring -man {-test}" 0 kB
>>>> [ebuild  N    ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
>>>> USE="ipv6 -debug -systemd" 0 kB
>>>>
>>> see "::mate-overlay", it's presumably broken or outdated. stop using the
>>> overlay and use MATE from Portage instead.
>>> or you can mask the packages from overlay, the syntax is like:
>>>
>>> /etc/portage/package.mask
>>>
>>> mate-extra/mate-power-manager::mate-overlay
>>> mate-base/mate-session-manager::mate-overlay
>>>
>>> - Samuli
>>>
>>>
>> Thanks everybody for your help.  I've made the further suggested
>> changes, but I remain with the three hard blocks.
>>
>> I've now spent about 7 hours over the last two days on this issue (about
>> 2x the fresh install time), when all I wanted to do was a routine
>> update.  I've reworked a large part of my system, adding a new
>> package.mask file and populating it with six packages.
>>
>> I suppose its now time for an uninstall.  Kind of disappointing; we are
>> told Gentoo is about choices, and in fact that's true.  I made the
>> choice to use a pure openRC system.  The last 7 hours of free time,
>> though, was spent trying, and ultimately failing, to correct a problem
>> not chosen, not wanted, and not invited.
>>
>> The sine qua non is unarguably systemd.  Even though my choice was to
>> not deploy it, apparently it takes a significant time commitment and/or
>> developer-level knowledge to choose to not use it.  Quite the inelegant
>> end to my once-trusty OS.
>>
> 
> Gentoo doesn't have write access to ::mate-overlay, it's completely
> unofficial
> Gentoo developers are just as much users as you are for ::mate-overlay
> 
> Enough said
> 
> - Samuli
> 
> 
Sorry, but this isn't just a MATE overlay problem.  Once I made your
suggested changes, the MATE "mask change" requests disappeared.  What I
did get was XFCE mask requirements:

[snip]

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=xfce-base/xfce4-session-4.10.1-r1
# required by virtual/udev-208-r2
# required by sys-power/upower-0.9.23-r3
# required by xfce-base/xfce4-session-4.10.1-r1[udev]
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/systemd-212-r5
# required by sys-apps/systemd-212-r5[-vanilla]
# required by sys-power/upower-0.9.23-r3
# required by xfce-base/xfce4-session-4.10.1-r1[udev]
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/gentoo-systemd-integration-4

[snip]

I had already <emerge - C>'d those two XFCE applications because, early
in this process an <equery depends upower> had shown them to be
dependent upon "upower" even after emerging "upower-pm-utils."  I have
no confidence at this point that my particular problem is reasonably
solvable, as I have been caught in this circle for three days now.

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 05/06/14 14:39, Dutch Ingraham wrote:
> On 06/04/2014 08:02 PM, Samuli Suominen wrote:
>> Gentoo doesn't have write access to ::mate-overlay, it's completely
>> unofficial
>> Gentoo developers are just as much users as you are for ::mate-overlay
>>
>> Enough said
>>
>> - Samuli
>>
>>
> Sorry, but this isn't just a MATE overlay problem.  Once I made your
> suggested changes, the MATE "mask change" requests disappeared.  What I
> did get was XFCE mask requirements:
>
> [snip]
>
> The following mask changes are necessary to proceed:
>  (see "package.unmask" in the portage(5) man page for more details)
> # required by xfce-base/xfce4-meta-4.10
> # required by @selected
> # required by @world (argument)
> # /etc/portage/package.mask:
> # problems with systemd, upower shift to upower.pm.utils
> =xfce-base/xfce4-session-4.10.1-r1
> # required by virtual/udev-208-r2
> # required by sys-power/upower-0.9.23-r3
> # required by xfce-base/xfce4-session-4.10.1-r1[udev]
> # required by xfce-base/xfce4-meta-4.10
> # required by @selected
> # required by @world (argument)
> # /etc/portage/package.mask:
> # problems with systemd, upower shift to upower.pm.utils
> =sys-apps/systemd-212-r5
> # required by sys-apps/systemd-212-r5[-vanilla]
> # required by sys-power/upower-0.9.23-r3
> # required by xfce-base/xfce4-session-4.10.1-r1[udev]
> # required by xfce-base/xfce4-meta-4.10
> # required by @selected
> # required by @world (argument)
> # /etc/portage/package.mask:
> # problems with systemd, upower shift to upower.pm.utils
> =sys-apps/gentoo-systemd-integration-4
>
> [snip]
>
> I had already <emerge - C>'d those two XFCE applications because, early
> in this process an <equery depends upower> had shown them to be
> dependent upon "upower" even after emerging "upower-pm-utils."  I have
> no confidence at this point that my particular problem is reasonably
> solvable, as I have been caught in this circle for three days now.
>

There is no need to mask any Xfce packages, in fact, masking them would
cause more blockers.
So that output would be bogus, as it would include the wrong Xfce masks,
and futhermore it's only end of
the output, so it wouldn't tell the necessary information required for
solving it anyway.
Remove anykind of Xfce masks and post complete output, and don't forget
to use the --tree flag (-t) to see
what is pulling in what.
That is, if you still want help solving the issue.

- Samuli

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

On 06/05/2014 08:00 AM, Samuli Suominen wrote:
> 
> On 05/06/14 14:39, Dutch Ingraham wrote:
>> On 06/04/2014 08:02 PM, Samuli Suominen wrote:
>>> Gentoo doesn't have write access to ::mate-overlay, it's completely
>>> unofficial
>>> Gentoo developers are just as much users as you are for ::mate-overlay
>>>
>>> Enough said
>>>
>>> - Samuli
>>>
>>>
>> Sorry, but this isn't just a MATE overlay problem.  Once I made your
>> suggested changes, the MATE "mask change" requests disappeared.  What I
>> did get was XFCE mask requirements:
>>
>> [snip]
>>
>> The following mask changes are necessary to proceed:
>>  (see "package.unmask" in the portage(5) man page for more details)
>> # required by xfce-base/xfce4-meta-4.10
>> # required by @selected
>> # required by @world (argument)
>> # /etc/portage/package.mask:
>> # problems with systemd, upower shift to upower.pm.utils
>> =xfce-base/xfce4-session-4.10.1-r1
>> # required by virtual/udev-208-r2
>> # required by sys-power/upower-0.9.23-r3
>> # required by xfce-base/xfce4-session-4.10.1-r1[udev]
>> # required by xfce-base/xfce4-meta-4.10
>> # required by @selected
>> # required by @world (argument)
>> # /etc/portage/package.mask:
>> # problems with systemd, upower shift to upower.pm.utils
>> =sys-apps/systemd-212-r5
>> # required by sys-apps/systemd-212-r5[-vanilla]
>> # required by sys-power/upower-0.9.23-r3
>> # required by xfce-base/xfce4-session-4.10.1-r1[udev]
>> # required by xfce-base/xfce4-meta-4.10
>> # required by @selected
>> # required by @world (argument)
>> # /etc/portage/package.mask:
>> # problems with systemd, upower shift to upower.pm.utils
>> =sys-apps/gentoo-systemd-integration-4
>>
>> [snip]
>>
>> I had already <emerge - C>'d those two XFCE applications because, early
>> in this process an <equery depends upower> had shown them to be
>> dependent upon "upower" even after emerging "upower-pm-utils."  I have
>> no confidence at this point that my particular problem is reasonably
>> solvable, as I have been caught in this circle for three days now.
>>
> 
> There is no need to mask any Xfce packages, in fact, masking them would
> cause more blockers.
> So that output would be bogus, as it would include the wrong Xfce masks,
> and futhermore it's only end of
> the output, so it wouldn't tell the necessary information required for
> solving it anyway.
> Remove anykind of Xfce masks and post complete output, and don't forget
> to use the --tree flag (-t) to see
> what is pulling in what.
> That is, if you still want help solving the issue.
> 
> - Samuli
> 
> 
I I've removed the XFCE masks.  Note that mate-power-manager is masked.
 Here's the output without them:

dutch@gentoo ~ $ emerge --tree --unordered-display --pretend -uDNv @world

These are the packages that would be merged:

Calculating dependencies... done!
[nomerge       ] xfce-extra/thunar-volman-0.8.0  USE="-debug -libnotify"
[nomerge       ]  xfce-base/libxfce4util-4.10.1  USE="-debug"
[ebuild   R    ]   dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
(-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[nomerge       ]    app-text/docbook-xml-dtd-4.1.2-r6:4.1.2
[nomerge       ]     app-text/build-docbook-catalog-1.19.1
[nomerge       ]      sys-apps/util-linux-2.24.1-r2
USE="bash-completion cramfs ncurses nls pam suid udev unicode -caps
-cytune -fdformat -python (-selinux) -slang -static-libs {-test}
-tty-helpers" PYTHON_SINGLE_TARGET="python2_7 -python3_2 -python3_3
(-python3_4)" PYTHON_TARGETS="python2_7 python3_3 -python3_2 (-python3_4)"
[nomerge       ]       sys-libs/pam-1.1.6-r2  USE="berkdb cracklib nls
-audit -debug -nis (-selinux) {-test} -vim-syntax"
[nomerge       ]        sys-auth/pambase-20120417-r3  USE="consolekit
cracklib sha512 -debug -gnome-keyring -minimal -mktemp -pam_krb5
-pam_ssh -passwdqc (-selinux) -systemd"
[nomerge       ]         sys-auth/consolekit-0.4.6  USE="acl pam
policykit -debug -doc (-selinux) -systemd-units {-test}"
[ebuild     U  ]          virtual/udev-208-r2 [208-r1] USE="gudev
-introspection -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32)
(-x32)" 0 kB
[ebuild  N    #]           sys-apps/systemd-212-r5:0/2  USE="acl
filecaps firmware-loader kmod pam policykit seccomp -audit -cryptsetup
-doc -gcrypt -gudev -http -introspection (-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" 0 kB
[ebuild  N     ]            sys-libs/libseccomp-2.1.1
USE="-static-libs" 111 kB
[ebuild  N    #]            sys-apps/gentoo-systemd-integration-4  52 kB
[ebuild  N     ]           virtual/libudev-208:0/1  USE="-static-libs"
ABI_X86="(64) (-32) (-x32)" 0 kB
[nomerge       ] net-print/gutenprint-5.2.9  USE="nls readline -cups
-foomaticdb -gimp -gtk -ppds -static-libs"
[nomerge       ]  app-text/ghostscript-gpl-9.10-r2  USE="X bindist cups
dbus djvu -gtk -idn -static-libs" LINGUAS="-de -ja -ko -zh_CN -zh_TW"
[nomerge       ]   net-print/cups-1.7.1-r1  USE="X acl dbus pam ssl
threads zeroconf -debug -gnutls -java -kerberos -lprng-compat -python
(-selinux) -static-libs -systemd -usb -xinetd" LINGUAS="ca es fr it ja
ru" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)"
PYTHON_TARGETS="python2_7 (-python2_6)"
[ebuild  rR    ]    net-print/cups-filters-1.0.53  USE="dbus foomatic
jpeg -perl -png -static-libs -tiff -zeroconf" 0 kB
[ebuild  r  U  ]     app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
-examples -static-libs {-test}" 7,484 kB
[nomerge       ] xfce-base/xfce4-meta-4.10  USE="svg -minimal"
[ebuild  N     ]  xfce-base/xfce4-session-4.10.1-r1  USE="nls udev
xscreensaver -debug -systemd" 0 kB
[ebuild  N     ]   sys-power/upower-0.9.23-r3  USE="introspection -doc
-ios" 0 kB
[nomerge       ] mate-base/mate-1.6.0::mate-overlay  USE="extras
(-bluetooth)"
[ebuild  N    #]  mate-base/mate-session-manager-1.6.1-r1::mate-overlay
 USE="ipv6 -debug -systemd" 0 kB
[ebuild  N    #]  mate-extra/mate-power-manager-1.6.3::mate-overlay
USE="applet policykit -gnome-keyring -man {-test}" 0 kB
[ebuild  N     ]  mate-base/mate-applets-1.6.2-r1  USE="X ipv6 policykit
-networkmanager" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)"
PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[blocks b      ] sys-power/upower ("sys-power/upower" is blocking
sys-power/upower-pm-utils-0.9.23)
[uninstall     ]  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/gentoo-systemd-integration
("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-212-r1)

Total: 14 packages (3 upgrades, 9 new, 2 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)

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

  (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-apps/systemd-207 required by
(sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge)
    >=sys-apps/systemd-208:0 required by (virtual/udev-208-r2::gentoo,
ebuild scheduled for merge)
    >=sys-apps/systemd-200 required by
(sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge)

>=sys-apps/systemd-208:0/2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs(-)?]
(>=sys-apps/systemd-208:0/2[abi_x86_64(-)]) required by
(virtual/libudev-208::gentoo, ebuild scheduled for merge)

  (sys-fs/udev-212-r1::gentoo, installed) pulled in by

>=sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs?]
(>=sys-fs/udev-208-r1:0/0[abi_x86_64(-),gudev]) required by
(virtual/libgudev-208::gentoo, installed)
    >=sys-fs/udev-208 required by (virtual/udev-208-r2::gentoo, ebuild
scheduled for merge)

>=sys-fs/udev-208:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs?]
(>=sys-fs/udev-208:0/0[abi_x86_64(-)]) required by
(virtual/libudev-208::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


The following packages are causing rebuilds:

  (app-text/qpdf-5.1.1::gentoo, ebuild scheduled for merge) causes
rebuilds for:
    (net-print/cups-filters-1.0.53::gentoo, ebuild scheduled for merge)

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by virtual/udev-208-r2
# required by sys-power/upower-0.9.23-r3
# required by mate-extra/mate-power-manager-1.6.3::mate-overlay
# required by mate-base/mate-1.6.0::mate-overlay[extras]
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/systemd-212-r5
# required by sys-apps/systemd-212-r5[-vanilla]
# required by virtual/udev-208-r2
# required by sys-power/upower-0.9.23-r3
# required by mate-extra/mate-power-manager-1.6.3::mate-overlay
# required by mate-base/mate-1.6.0::mate-overlay[extras]
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/gentoo-systemd-integration-4

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.

 * IMPORTANT: 1 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 05/06/14 15:17, Dutch Ingraham wrote:
> On 06/05/2014 08:00 AM, Samuli Suominen wrote:
>> On 05/06/14 14:39, Dutch Ingraham wrote:
>>> On 06/04/2014 08:02 PM, Samuli Suominen wrote:
>>>> Gentoo doesn't have write access to ::mate-overlay, it's completely
>>>> unofficial
>>>> Gentoo developers are just as much users as you are for ::mate-overlay
>>>>
>>>> Enough said
>>>>
>>>> - Samuli
>>>>
>>>>
>>> Sorry, but this isn't just a MATE overlay problem.  Once I made your
>>> suggested changes, the MATE "mask change" requests disappeared.  What I
>>> did get was XFCE mask requirements:
>>>
>>> [snip]
>>>
>>> The following mask changes are necessary to proceed:
>>>  (see "package.unmask" in the portage(5) man page for more details)
>>> # required by xfce-base/xfce4-meta-4.10
>>> # required by @selected
>>> # required by @world (argument)
>>> # /etc/portage/package.mask:
>>> # problems with systemd, upower shift to upower.pm.utils
>>> =xfce-base/xfce4-session-4.10.1-r1
>>> # required by virtual/udev-208-r2
>>> # required by sys-power/upower-0.9.23-r3
>>> # required by xfce-base/xfce4-session-4.10.1-r1[udev]
>>> # required by xfce-base/xfce4-meta-4.10
>>> # required by @selected
>>> # required by @world (argument)
>>> # /etc/portage/package.mask:
>>> # problems with systemd, upower shift to upower.pm.utils
>>> =sys-apps/systemd-212-r5
>>> # required by sys-apps/systemd-212-r5[-vanilla]
>>> # required by sys-power/upower-0.9.23-r3
>>> # required by xfce-base/xfce4-session-4.10.1-r1[udev]
>>> # required by xfce-base/xfce4-meta-4.10
>>> # required by @selected
>>> # required by @world (argument)
>>> # /etc/portage/package.mask:
>>> # problems with systemd, upower shift to upower.pm.utils
>>> =sys-apps/gentoo-systemd-integration-4
>>>
>>> [snip]
>>>
>>> I had already <emerge - C>'d those two XFCE applications because, early
>>> in this process an <equery depends upower> had shown them to be
>>> dependent upon "upower" even after emerging "upower-pm-utils."  I have
>>> no confidence at this point that my particular problem is reasonably
>>> solvable, as I have been caught in this circle for three days now.
>>>
>> There is no need to mask any Xfce packages, in fact, masking them would
>> cause more blockers.
>> So that output would be bogus, as it would include the wrong Xfce masks,
>> and futhermore it's only end of
>> the output, so it wouldn't tell the necessary information required for
>> solving it anyway.
>> Remove anykind of Xfce masks and post complete output, and don't forget
>> to use the --tree flag (-t) to see
>> what is pulling in what.
>> That is, if you still want help solving the issue.
>>
>> - Samuli
>>
>>
> I I've removed the XFCE masks.  Note that mate-power-manager is masked.

I see you didn't follow the recommendation of getting rid of the
::mate-overlay because
I'm still seeing mate-base/mate::mate-overlay and more in the output
I don't know how we could possible get forward if you don't follow-up on
the already
suggested instructions, no wonder you've been running circles.

Uninstall mate-overlay, emerge -C mate mate-power-manager
mate-session-manager and
anything else you have installed from there. Let Portage pull them back
in from the actual
Portage tree.

Re: [gentoo-user] Systemd upower

[Dutch Ingraham]

[-- Attachment #1: Type: text/html, Size: 5382 bytes --]

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Wed, 04 Jun 2014 19:15:22 -0400
Dutch Ingraham <stoa@gmx.us> wrote:

> Thanks everybody for your help.  I've made the further suggested
> changes, but I remain with the three hard blocks.

Can you provide the emerge output of the following command?

    emerge --tree --unordered-diplay -uDNv @world

This makes it more clear what pulls in systemd.

Once you know that, you can mask the chain and use an alternative;
other than that, MATE is in the Portage tree and therefore you can
remove the MATE overlay to avoid running into unnecessary blockers.

This happening has nothing to do with Gentoo or systemd; around four
years ago the development of pm-utils stopped, which causes UPower to
nowadays take a decision. This results in the following scenarios:

 1. If you need pm-utils, you either need to switch to the
 upower-pm-utils fork or to systemd;

 2. If you don't need pm-utils, you either need to

        a) upgrade to upower-0.99 once reverse dependencies support it
        and it is stabilized (this has no dependency on systemd);

        b) switch to upower-pm-utils despite not needing pm-utils;

        c) switch to systemd.

Gentoo reflects that decision as magic can't happen from one day to
the other; while trying to keep a fork upower-pm-utils alive as long as
it can be kept working given the manpower, kernel API and so on...

-- 
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-user] Systemd upower

[Dutch Ingraham]

On 06/05/2014 05:40 AM, Tom Wijsman wrote:
> On Wed, 04 Jun 2014 19:15:22 -0400
> Dutch Ingraham <stoa@gmx.us> wrote:
> 
>> Thanks everybody for your help.  I've made the further suggested
>> changes, but I remain with the three hard blocks.
> 
> Can you provide the emerge output of the following command?
> 
>     emerge --tree --unordered-diplay -uDNv @world
> 
> This makes it more clear what pulls in systemd.
> 
> Once you know that, you can mask the chain and use an alternative;
> other than that, MATE is in the Portage tree and therefore you can
> remove the MATE overlay to avoid running into unnecessary blockers.
> 
> This happening has nothing to do with Gentoo or systemd; around four
> years ago the development of pm-utils stopped, which causes UPower to
> nowadays take a decision. This results in the following scenarios:
> 
>  1. If you need pm-utils, you either need to switch to the
>  upower-pm-utils fork or to systemd;
> 
>  2. If you don't need pm-utils, you either need to
> 
>         a) upgrade to upower-0.99 once reverse dependencies support it
>         and it is stabilized (this has no dependency on systemd);
> 
>         b) switch to upower-pm-utils despite not needing pm-utils;
> 
>         c) switch to systemd.
> 
> Gentoo reflects that decision as magic can't happen from one day to
> the other; while trying to keep a fork upower-pm-utils alive as long as
> it can be kept working given the manpower, kernel API and so on...
> 
Here's the output you requested, Tom:

dutch@gentoo ~ $ emerge --tree --unordered-display --pretend -uDNv @world

These are the packages that would be merged:

Calculating dependencies... done!
[nomerge       ] virtual/shadow-0
[nomerge       ]  sys-apps/shadow-4.1.5.1-r1  USE="acl cracklib nls pam
-audit (-selinux) -skey -xattr"
[nomerge       ]   virtual/pam-0
[nomerge       ]    sys-libs/pam-1.1.6-r2  USE="berkdb cracklib nls
-audit -debug -nis (-selinux) {-test} -vim-syntax"
[nomerge       ]     sys-auth/pambase-20120417-r3  USE="consolekit
cracklib sha512 -debug -gnome-keyring -minimal -mktemp -pam_krb5
-pam_ssh -passwdqc (-selinux) -systemd"
[nomerge       ]      sys-auth/consolekit-0.4.6  USE="acl pam policykit
-debug -doc (-selinux) -systemd-units {-test}"
[nomerge       ]       sys-auth/polkit-0.112-r1  USE="introspection nls
pam -examples -gtk -kde (-selinux) -systemd"
[nomerge       ]        dev-libs/gobject-introspection-1.38.0
USE="-cairo -doctool {-test}" PYTHON_SINGLE_TARGET="python2_7"
PYTHON_TARGETS="python2_7"
[nomerge       ]         virtual/pkgconfig-0
[nomerge       ]          dev-util/pkgconfig-0.28  USE="-hardened
-internal-glib"
[ebuild   R    ]           dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug
(-fam) (-selinux) -static-libs -systemtap {-test} -utils -xattr"
ABI_X86="(64) (-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[nomerge       ]            app-text/docbook-xml-dtd-4.1.2-r6:4.1.2
[nomerge       ]             app-text/build-docbook-catalog-1.19.1
[nomerge       ]              sys-apps/util-linux-2.24.1-r2
USE="bash-completion cramfs ncurses nls pam suid udev unicode -caps
-cytune -fdformat -python (-selinux) -slang -static-libs {-test}
-tty-helpers" PYTHON_SINGLE_TARGET="python2_7 -python3_2 -python3_3
(-python3_4)" PYTHON_TARGETS="python2_7 python3_3 -python3_2 (-python3_4)"
[ebuild     U  ]               virtual/udev-208-r2 [208-r1] USE="gudev
-introspection -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32)
(-x32)" 0 kB
[ebuild  N     ]                virtual/libudev-208:0/1
USE="-static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB
[ebuild  N    #]                 sys-apps/systemd-212-r5:0/2  USE="acl
filecaps firmware-loader kmod pam policykit seccomp -audit -cryptsetup
-doc -gcrypt -gudev -http -introspection (-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" 0 kB
[ebuild  N     ]                  sys-libs/libseccomp-2.1.1
USE="-static-libs" 111 kB
[ebuild  N    #]                  sys-apps/gentoo-systemd-integration-4
 52 kB
[nomerge       ] mate-base/mate-1.6.0::mate-overlay  USE="extras
(-bluetooth)"
[ebuild  N    #]  mate-base/mate-session-manager-1.6.1-r1::mate-overlay
 USE="ipv6 -debug -systemd" 0 kB
[ebuild  N     ]   sys-power/upower-0.9.23-r3  USE="introspection -doc
-ios" 0 kB
[ebuild  N    #]  mate-extra/mate-power-manager-1.6.3::mate-overlay
USE="applet policykit -gnome-keyring -man {-test}" 0 kB
[nomerge       ]   mate-base/mate-panel-1.6.1::mate-overlay
USE="introspection -networkmanager"
[ebuild   R   ~]    x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
[nomerge       ]  app-text/mate-document-viewer-1.6.2-r1  USE="dbus djvu
introspection ps -caja -debug -dvi -gnome-keyring -t1lib -tiff -xps"
[nomerge       ]   app-text/libspectre-0.2.7  USE="-debug -doc
-static-libs"
[nomerge       ]    app-text/ghostscript-gpl-9.10-r2  USE="X bindist
cups dbus djvu -gtk -idn -static-libs" LINGUAS="-de -ja -ko -zh_CN -zh_TW"
[nomerge       ]     net-print/cups-1.7.1-r1  USE="X acl dbus pam ssl
threads zeroconf -debug -gnutls -java -kerberos -lprng-compat -python
(-selinux) -static-libs -systemd -usb -xinetd" LINGUAS="ca es fr it ja
ru" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)"
PYTHON_TARGETS="python2_7 (-python2_6)"
[ebuild  rR    ]      net-print/cups-filters-1.0.53  USE="dbus foomatic
jpeg -perl -png -static-libs -tiff -zeroconf" 0 kB
[ebuild  r  U  ]       app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
-examples -static-libs {-test}" 7,484 kB
[ebuild  N     ]  mate-base/mate-applets-1.6.2-r1  USE="X ipv6 policykit
-networkmanager" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)"
PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
[ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[nomerge       ] xfce-base/xfce4-meta-4.10  USE="svg -minimal"
[ebuild  N    #]  xfce-base/xfce4-session-4.10.1-r1  USE="nls udev
xscreensaver -debug -systemd" 0 kB
[blocks b      ] sys-power/upower ("sys-power/upower" is blocking
sys-power/upower-pm-utils-0.9.23)
[uninstall     ]  sys-power/upower-pm-utils-0.9.23  USE="introspection
-doc -ios"
[blocks B      ] sys-apps/gentoo-systemd-integration
("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/udev-212-r1)
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
sys-apps/gentoo-systemd-integration-4, sys-apps/systemd-212-r5)

Total: 15 packages (3 upgrades, 9 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)

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

  (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-apps/systemd-200 required by
(sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge)
    >=sys-apps/systemd-208:0 required by (virtual/udev-208-r2::gentoo,
ebuild scheduled for merge)
    >=sys-apps/systemd-207 required by
(sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge)

>=sys-apps/systemd-208:0/2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs(-)?]
(>=sys-apps/systemd-208:0/2[abi_x86_64(-)]) required by
(virtual/libudev-208::gentoo, ebuild scheduled for merge)

  (sys-fs/udev-212-r1::gentoo, installed) pulled in by

>=sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs?]
(>=sys-fs/udev-208-r1:0/0[abi_x86_64(-),gudev]) required by
(virtual/libgudev-208::gentoo, installed)
    >=sys-fs/udev-208 required by (virtual/udev-208-r2::gentoo, ebuild
scheduled for merge)

>=sys-fs/udev-208:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs?]
(>=sys-fs/udev-208:0/0[abi_x86_64(-)]) required by
(virtual/libudev-208::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


The following packages are causing rebuilds:

  (app-text/qpdf-5.1.1::gentoo, ebuild scheduled for merge) causes
rebuilds for:
    (net-print/cups-filters-1.0.53::gentoo, ebuild scheduled for merge)

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=xfce-base/xfce4-session-4.10.1-r1
# required by virtual/udev-208-r2
# required by sys-power/upower-0.9.23-r3
# required by mate-base/mate-applets-1.6.2-r1
# required by mate-base/mate-1.6.0::mate-overlay
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/systemd-212-r5
# required by sys-apps/systemd-212-r5[-vanilla]
# required by virtual/libudev-208
# required by virtual/udev-208-r2
# required by sys-power/upower-0.9.23-r3
# required by mate-base/mate-applets-1.6.2-r1
# required by mate-base/mate-1.6.0::mate-overlay
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/gentoo-systemd-integration-4

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.

!!! The following installed packages are masked:
- xfce-base/xfce4-meta-4.10::gentoo (masked by: package.mask)
/etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.


 * IMPORTANT: 1 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

dutch@gentoo ~ $


Please note (1) I have changed to "upower-pm-utils" and (2) there are
XFCE problems here as well as MATE overlay problems, so removing the
overlay is not necessarily a path off the circle.

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Thu, 05 Jun 2014 08:11:31 -0400
Dutch Ingraham <stoa@gmx.us> wrote:

> [nomerge       ] mate-base/mate-1.6.0::mate-overlay

You are still using the MATE overlay, which wasn't synced up with
the latest changes; make layman sync, but if you want to be really sure
just remove the overlay from layman and use MATE from the Portage tree.

> [ebuild  N    #] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
> [ebuild  N     ]  sys-power/upower-0.9.23-r3

Don't mask MATE, it causes more blockers; mate-base/mate requires it.

As you can see above, your old checkout of the MATE overlay pulls in
sys-power/upower; the MATE in the portage tree doesn't do this as it
allows upower-pm-utils to satisfy this, I think this has also been
fixed up in the MATE overlay recently which a sync could solve.

> [blocks B      ] sys-apps/gentoo-systemd-integration
> ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
> sys-fs/udev-212-r1)
> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
> sys-apps/gentoo-systemd-integration-4, sys-apps/systemd-212-r5)

Fixing what was said above, for MATE (maybe XFCE too), will fix it ... 

>   (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge)
> pulled in by
>     >=sys-apps/systemd-200 required by
> (sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge)

... as well as this; this last thing points out that something is
still pulling in upower, that's due to the old MATE overlay checkout.

The MATE overlay plans to retire itself in less than a week from now.

https://github.com/Sabayon/mate-overlay/issues/76

If you need help with switching to MATE in the Portage tree, feel free
to let me know; this migration is supposed to go very fluent, so,
removing the overlay from layman should work out well.

-- 
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-user] Systemd upower

[Dutch Ingraham]

[-- Attachment #1: Type: text/html, Size: 3742 bytes --]

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Thu, 5 Jun 2014 16:15:11 +0200
"Dutch Ingraham" <stoa@gmx.us> wrote:

> If you could point me to the proper command set to make the switch,
> I'd appreciate it.

Remove the overlay (`layman -d mate`) and then do a world upgrade.

It is as simple as that, as it'll upgrade all those packages to the
versions that are in the Portage tree; if not, please let me know.

Good luck and thank you in advance.

-- 
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-user] Systemd upower

[Dutch Ingraham]

On 06/05/2014 11:40 AM, Tom Wijsman wrote:
> On Thu, 5 Jun 2014 16:15:11 +0200
> "Dutch Ingraham" <stoa@gmx.us> wrote:
> 
>> If you could point me to the proper command set to make the switch,
>> I'd appreciate it.
> 
> Remove the overlay (`layman -d mate`) and then do a world upgrade.
> 
> It is as simple as that, as it'll upgrade all those packages to the
> versions that are in the Portage tree; if not, please let me know.
> 
> Good luck and thank you in advance.
> 
OK Tom, I'll try that tonight.  Thanks to everyone who offered
solutions, and especially to TomWij and Samuli for their extra effort.

For my future reference, could someone point me to the documentation
that provides for the situation where an application installed under
layman is migrated to the portage tree?  I understand now the procedure
seems simple, but without that information, I wouldn't ordinarily just
presume such a simple fix (kudos to the portage devs/maintainers)(I
certainly would have done it long ago when Tom first populated the tree).

I have checked the following sources and find nothing but how to install
and work with overlays, but only the command above for removing one -
nothing on migration:  Gentoo Overlays User's Guide, the Gentoo wikis on
overlays and layman, the layman, portage, and emerge manpages, and the
Gentoo Handbook.

Thanks again for all the help.

Re: [gentoo-user] Systemd upower

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 551 bytes --]

On Thursday 05 Jun 2014 15:15:11 Dutch Ingraham wrote:
> <html><head></head><body><div style="font-family: Verdana;font-size:
> 12.0px;"><div>&nbsp; <div>&nbsp;
> 
> <div name="quoted-content">&nbsp;</div>
> 
> <div name="quoted-content">If you could point me to the proper command set
> to make the switch, I&#39;d appreciate it.</div> </div>
> </div>
> </div></div></body></html>

Please see if you can switch off HTML when posting to this list.

Check man layman, the delete command is:

 layman -d <overlay>

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Tue, 03 Jun 2014 22:17:21 -0400
Dutch Ingraham <stoa@gmx.us> wrote:

> That's a good catch, the MATE stuff is from the overlay.

MATE 1.6 is stable in the Portage tree, MATE 1.8 is testing in the
Portage tree; both had their upower dependencies fixed up days ago.

-- 
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-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 8:48 PM, Dutch Ingraham <stoa@gmx.us> wrote:
> On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
>> On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham <stoa@gmx.us> wrote:
>>> On 06/03/2014 07:24 PM, Jim Burwell wrote:
>>>
>>>> FWIW, on my system, I had to mask "sys-apps/gentoo-systemd-integration"
>>>> for it to merge the udev update w/o trying to pull in systemd, et al.  i
>>>> didn't deep dive on what was trying to pull that in, but masking it
>>>> (plus a ton of other stuff I have masked) prevented portage from trying
>>>> to build a systemd based system.
>>>>
>>>>
>>>>
>>>>
>>>
>>> OK - I have followed the advice given in <eselect news read>; I have
>>> also followed the advice on this and the related thread today and
>>> uninstalled "sys-power/upower" and installed
>>> "sys-power/upower-pm-utils".  That didn't work.  Then, given the above,
>>> I have masked (first) "sys-apps/gentoo-systemd-integration" and when
>>> that had no effect, masked "sys-apps/systemd."
>>>
>>> I am still hard-blocked out of updating:
>>>
>>> Calculating dependencies... done!
>>> [ebuild  N     ] sys-libs/libseccomp-2.1.1  USE="-static-libs" 111 kB
>>> [ebuild  r  U  ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE="-doc
>>> -examples -static-libs {-test}" 7,484 kB
>>> [ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="mime%* -debug (-fam)
>>> (-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="(64)
>>> (-32) (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
>>> [ebuild   R   ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
>>> [1.6.1:0::gentoo] USE="introspection startup-notification (-X%*)" 0 kB
>>> [ebuild  rR    ] net-print/cups-filters-1.0.53  USE="dbus foomatic jpeg
>>> -perl -png -static-libs -tiff -zeroconf" 0 kB
>>> [ebuild     U  ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
>>> [ebuild  N    #] sys-apps/systemd-212-r5:0/2  USE="acl filecaps
>>> firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
>>> -gcrypt -gudev -http -introspection (-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" 0 kB
>>> [ebuild  N    #] sys-apps/gentoo-systemd-integration-4  52 kB
>>> [ebuild  N     ] virtual/libudev-208:0/1  USE="-static-libs"
>>> ABI_X86="(64) (-32) (-x32)" 0 kB
>>> [ebuild     U  ] virtual/udev-208-r2 [208-r1] USE="gudev -introspection
>>> -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32) (-x32)" 0 kB
>>> [ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc
>>> -ios" 0 kB
>>> [uninstall     ] sys-power/upower-pm-utils-0.9.23  USE="introspection
>>> -doc -ios"
>>> [blocks b      ] sys-power/upower ("sys-power/upower" is blocking
>>> sys-power/upower-pm-utils-0.9.23)
>>> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking
>>> sys-fs/udev-212-r1)
>>> [blocks B      ] sys-apps/gentoo-systemd-integration
>>> ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
>>> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking
>>> sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
>>>
>>> Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
>>> of downloads: 45,580 kB
>>> Conflict: 4 blocks (3 unsatisfied)
>>>
>>>
>>> I'm not sure what else to mask/uninstall/reinstall at this point.  Any
>>> suggestions?
>>
>> Something is pulling upower. You need to find out what; supposedly
>> everything in the tree already should handle upower-pm-utils as a
>> upower replacement.
>>
>> Perhaps try to sync again?
>>
>> Regards.
>>
> Thanks, Canek.
>
> I did re-sync, with the same results.  I also ran a <equery depends
> upower> with the following result:
>
> dutch@gentoo ~ $ sudo equery depends upower
>  * These packages depend on upower:
> mate-base/mate-applets-1.6.2-r1 (>=sys-power/upower-0.9.4)
>                                 (<sys-power/upower-0.99)
> mate-base/mate-session-manager-1.6.1-r1 (>=sys-power/upower-0.9.0)
> mate-extra/mate-power-manager-1.6.3 (>=sys-power/upower-0.9.1)
> xfce-base/xfce4-session-4.10.1-r1 (udev ? <sys-power/upower-0.99)
> xfce-extra/xfce4-power-manager-1.2.0-r2 (<sys-power/upower-0.99)
> dutch@gentoo ~ $
>
> But as you said, "upower-pm-utils" should be handling these
> dependencies.  Is anyone else having these problems with MATE or XFCE?

If, as Michael says, you are using MATE from an overlay, then it will
take a while for all of them to sync with the new
upower/upower-pm-utils dichotomy.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 04/06/14 02:13, Canek Peláez Valdés wrote:
>> systemd should not be visible at any time, nor its implications.
> Nobody is here to deal with other people's OCD.
>
>

+1

your assesment in this threads seems to be accurate otherwise too, I'm
glad not everyone has
lost their mind over _a word_ like "systemd"

thanks,
samuli

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Wed, 4 Jun 2014 01:06:52 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> Once again, you do not understand the claim.
> 
> If a user of Gentoo chooses to use non systemd profile, it means that
> we need to make sure systemd will not be a valid option, ever.

There is no such thing as a "non systemd profile" on Gentoo at the
moment; you have ".../systemd" profiles, which are specializations of
the more generic case "..." which you can fill in with "gnome" or "kde".

So, I'm here running this agnostic MATE with a make.profile symlink
that doesn't point to a ".../systemd" profile; what is remarkable, is
that systemd is a valid option in this case.

Similarly, if I pick a ".../systemd" profile; what is remarkable, is
that OpenRC is also a valid option in that case.

For there to be a "make sure systemd will not be a valid option, ever"
there would have to be a ".../no-systemd" profile or something like
that; in such profile, one could then mask anything that tries to pull
in systemd and not have to deal with further transitions later on.

Splitting up profiles this way becomes a pain to maintain; other than
that, it is also a controversial way to go about it given that a
"no-..." type of profile hasn't been commonly used before yet.

In this train of thoughts Funtoo mix-ins could help to do it more clean.

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

But until we've got something, we've got to accept that other options
remain valid choices; profiles are just there, well, to ensure a
particular choice is properly supported without further implications.

> In this case, if it is to disable the upower USE flag, or to provide
> alternative, block newer version, whatever make it possible to have a
> system working without systemd.
> 
> systemd should not be visible at any time, nor its implications.
> 
> Alon

It is easy to make such a statement, but it is hard to make it happen;
upstreams change over time, which makes such implications happen sooner
or later in one place or the other. Which becomes visible over time...

The manpower that we have to keep implications away are limited; to
make a change to those implications, one could write code as suggested.

-- 
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-user] Systemd upower

[Neil Bothwick]

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

On Tue, 03 Jun 2014 23:01:20 +0200, Marc Stürmer wrote:

> Even Linus Torvalds himself ranted about the attitude of systemd's 
> developers at the beginning of May this year.

Linus rants about everything and everyone, usually at least twice, once
for and once against. It proves nothing beyond Linus is still Linus.


-- 
Neil Bothwick

GOTO: (n.) an efficient and general way of controlling a program, much
despised by academics and others whose brains have been ruined by
overexposure to Pascal.

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

Re: [gentoo-user] Systemd upower

[Alan McKinnon]

On 04/06/2014 00:59, Neil Bothwick wrote:
> On Tue, 03 Jun 2014 23:01:20 +0200, Marc Stürmer wrote:
> 
>> Even Linus Torvalds himself ranted about the attitude of systemd's 
>> developers at the beginning of May this year.
> 
> Linus rants about everything and everyone, usually at least twice, once
> for and once against. It proves nothing beyond Linus is still Linus.
> 
> 


He *did* rant about Gnome not giving him choices about middle clicking
on the window frame and rejecting his patch to do that, so he switched
to KDE.

Then he ranted about KDE giving the users too much choice with weird
config dialogues and not getting their shit together to fix actual bugs,
so he switched to Gnome.

I eagerly anticipate Linus' switch to E17. Oops sorry, make that E19.

So Linus is still Linus? Yep, that's how I see it too.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 6:07 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 04/06/2014 00:59, Neil Bothwick wrote:
>> On Tue, 03 Jun 2014 23:01:20 +0200, Marc Stürmer wrote:
>>
>>> Even Linus Torvalds himself ranted about the attitude of systemd's
>>> developers at the beginning of May this year.
>>
>> Linus rants about everything and everyone, usually at least twice, once
>> for and once against. It proves nothing beyond Linus is still Linus.
>>
>>
>
>
> He *did* rant about Gnome not giving him choices about middle clicking
> on the window frame and rejecting his patch to do that, so he switched
> to KDE.
>
> Then he ranted about KDE giving the users too much choice with weird
> config dialogues and not getting their shit together to fix actual bugs,
> so he switched to Gnome.
>
> I eagerly anticipate Linus' switch to E17. Oops sorry, make that E19.
>
> So Linus is still Linus? Yep, that's how I see it too.

At some point, someone is going to ask Linus point blank what does he
think about systemd. I would not be surprised if he says it's a great
idea. I would neither be surprised if he says it's a terrible idea.

And then some weeks/months/years later, he *will* say the opposite.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Greg Woodbury]

On 06/03/2014 01:08 PM, Canek Peláez Valdés wrote:
> Who is "forcing"  anything? pm-utils has been unmaintained FOR FIVE
> YEARS. Any project that decides to stop using it is making just the
> right decision; UPower just did the correct thing. And systemd had
> *nothing* to do with it, except for providing a better, more reliable
> alternative.
> 
> That's what you and many others don't seem to understand: systemd is a
> *BETTER* implementation for basically *ALL* the hodgepodge of
> "solutions" that we had before in our plumbing layer.

<snip>

> 
> There is no conspiracy here (although for *SURE* there are
> scare-mongering conspiracy theorists); there is (sic) only developers
> working in the best possible implementation for our plumbing layer,
> and other developers realizing that, in Linux at least, supporting
> anything besides systemd is a freakin' waste of time and resources.
> 
> Again; you don't like it? Then do something about it instead of
> posting in *-user lists.

You are certainly keen in pressing your *opinions* here there and
everywhere.

Sure, systemd is a more elegant solution than the patchworks that have
been applied several times to the original SysV concept.

However, the implementors and advocates of systemd have stepped on the
concerns and violated certain basic freedoms of many folks in their zeal
to see their vision become predominate.

-- 
G.Wolfe Woodbury

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Tue, Jun 3, 2014 at 8:37 PM, Greg Woodbury <redwolfe@gmail.com> wrote:
> On 06/03/2014 01:08 PM, Canek Peláez Valdés wrote:
>> Who is "forcing"  anything? pm-utils has been unmaintained FOR FIVE
>> YEARS. Any project that decides to stop using it is making just the
>> right decision; UPower just did the correct thing. And systemd had
>> *nothing* to do with it, except for providing a better, more reliable
>> alternative.
>>
>> That's what you and many others don't seem to understand: systemd is a
>> *BETTER* implementation for basically *ALL* the hodgepodge of
>> "solutions" that we had before in our plumbing layer.
>
> <snip>
>
>>
>> There is no conspiracy here (although for *SURE* there are
>> scare-mongering conspiracy theorists); there is (sic) only developers

(Sorry; I'm not a native English writer).

>> working in the best possible implementation for our plumbing layer,
>> and other developers realizing that, in Linux at least, supporting
>> anything besides systemd is a freakin' waste of time and resources.
>>
>> Again; you don't like it? Then do something about it instead of
>> posting in *-user lists.
>
> You are certainly keen in pressing your *opinions* here there and
> everywhere.

Well, I also did what I could to help systemd in Gentoo get to its
currently state. Certainly I did not *just* complained on this mailing
list about why I could not use systemd and uninstall OpenRC; I helped
make it happen.

And it worked.

> Sure, systemd is a more elegant solution than the patchworks that have
> been applied several times to the original SysV concept.

Glad to see you recognize that.

> However, the implementors and advocates of systemd have stepped on the
> concerns and violated certain basic freedoms of many folks in their zeal
> to see their vision become predominate.

Oh FFS. What "freedoms" have you had "violated"? The "freedom" to
mandate what other developers should write, or what packages they can
use as hard dependencies?

You never had that "freedom". That's the developer freedom; if you
want some of that, become a developer.

Or help Samuli to maintain upower-pm-utils; that would be *much* more
helpful than spreding FUD about cabals and conspiracies.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Greg Woodbury]

On 06/03/2014 10:05 PM, Canek Peláez Valdés wrote:
> On Tue, Jun 3, 2014 at 8:37 PM, Greg Woodbury <redwolfe@gmail.com> wrote:

> 
>> Sure, systemd is a more elegant solution than the patchworks that have
>> been applied several times to the original SysV concept.
> 
> Glad to see you recognize that.
> 
>> However, the implementors and advocates of systemd have stepped on the
>> concerns and violated certain basic freedoms of many folks in their zeal
>> to see their vision become predominate.
> 
> Oh FFS. What "freedoms" have you had "violated"? The "freedom" to
> mandate what other developers should write, or what packages they can
> use as hard dependencies?
> 
> You never had that "freedom". That's the developer freedom; if you
> want some of that, become a developer.

I was a developer for more years than I really care to remember.  I
still try to contribute in ways and areas that I'm not so out-of-date with.

Furthermore, it is a two-way street (as I see it.) The developers write
things they find interesting and enjoyable to work on, and users use
things that are interesting and work well.  For many, seeing other folks
use what they have written provides a significant measure of the
enjoyment derived from the exercise.

To see this as only freedom for the developer is part of an attitude
shift over the years that only lessens the overall usefulness of Linux
and FOSS. It does, in fact, push quite a few folk I know away from the
Linux arena. It is, to use a political analogy, like the people who
claim there "is not any real difference" between *any* opposing
political movements -- that neglects taking into account a great deal of
technical and historical details.

I occasionally think about forking projects and fixing some of the
things I think are the most egregious fsck-ups in some of them, but then
I really look at what I'm doing and what I enjoy doing, and realize that
I won't get enough (emotional?) reward for giving up time in other
significant parts of my life.

> Or help Samuli to maintain upower-pm-utils; that would be *much* more
> helpful than spreding FUD about cabals and conspiracies.

There is no need for me to invent Fear, Uncertainty, and Doubt -- the
folks involved are doing quite well on their own.  Also, history (for
those not doomed to repeat it [1]) provides all that is required to make
calling it a "cabal"  [TINC - there is no cabal![2]]  There never was a
Usenet Backbone Cabal in any formal sense, but there was plenty of
semi-(un)coordinated activity -- based largely on shared ideals -- that
gave that appearance.  {I was there when Usenet/Netnews was invented,
closely observing, making minor and not-so-minor contributions, and was
responsible for some of the "cabal-like" activities.}

The mere coinage of terms like "Lennertware," whether or not deserved,
show that there is a widespread awareness that some developers, in my
opinion, have over developed egos. [3]

It is all so trite to say "become a developer and DO something instead
of complaining"  but it is not a realistic thing to say when the
problems are getting so large and interconnected.  Furthermore, it
denigrates and devalues the "pseudo-democratic" processes that FOSS and
Linux have worked for years to nurture.


[1] Those who forget history are doomed to repeat it.
    (paraphrase of George Santayana)

[2] See, for starters:
       http://http://en.wikipedia.or/wiki/Backbone_cabal

[3] All Gods have feet of clay.
       source uncertain.
       (perhaps a reference to "Ozymandias"?

-- 
G.Wolfe Woodbury
{once upon a time AKA ...!duke!ggw}

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Wed, Jun 4, 2014 at 5:28 AM, Greg Woodbury <redwolfe@gmail.com> wrote:
> On 06/03/2014 10:05 PM, Canek Peláez Valdés wrote:
>> On Tue, Jun 3, 2014 at 8:37 PM, Greg Woodbury <redwolfe@gmail.com> wrote:
>
>>
>>> Sure, systemd is a more elegant solution than the patchworks that have
>>> been applied several times to the original SysV concept.
>>
>> Glad to see you recognize that.
>>
>>> However, the implementors and advocates of systemd have stepped on the
>>> concerns and violated certain basic freedoms of many folks in their zeal
>>> to see their vision become predominate.
>>
>> Oh FFS. What "freedoms" have you had "violated"? The "freedom" to
>> mandate what other developers should write, or what packages they can
>> use as hard dependencies?
>>
>> You never had that "freedom". That's the developer freedom; if you
>> want some of that, become a developer.
>
> I was a developer for more years than I really care to remember.  I
> still try to contribute in ways and areas that I'm not so out-of-date with.

Good for you. Now, imagine you don't only contribute, but that you
actually *maintain* (as in, *you* are in charge) of project X. And
then you see that project X is so much easier to maintain if you
depend on project Y. So you make project Y a hard dependency of
project X.

And then a bunch of people who don't really know how to maintain code,
start yelling at you because you made project X dependant on project
Y. And they *demand* of you that you should not depend on Y, but they
don't provide the code to do it,

Will you drop dependency on project Y, even if it makes your life as a
maintainer several times easier?

> Furthermore, it is a two-way street (as I see it.) The developers write
> things they find interesting and enjoyable to work on, and users use
> things that are interesting and work well.  For many, seeing other folks
> use what they have written provides a significant measure of the
> enjoyment derived from the exercise.

That does not contradicts anything I have said.

> To see this as only freedom for the developer is part of an attitude
> shift over the years that only lessens the overall usefulness of Linux
> and FOSS. It does, in fact, push quite a few folk I know away from the
> Linux arena. It is, to use a political analogy, like the people who
> claim there "is not any real difference" between *any* opposing
> political movements -- that neglects taking into account a great deal of
> technical and historical details.

I have no idea what do you mean by the last paragraph. This is not a
political discusion (although many would like to see it that way). It
is a *technical* discusion, and therefore there is no real discusion:
the general consensus is that systemd is the technological superior
alternative.

> I occasionally think about forking projects and fixing some of the
> things I think are the most egregious fsck-ups in some of them, but then
> I really look at what I'm doing and what I enjoy doing, and realize that
> I won't get enough (emotional?) reward for giving up time in other
> significant parts of my life.

And that's your right, and it's fine. But let *other* developers
choose whatever technologies they want to choose, and (consequently)
drop support for obsolete technologies like pm-utils.

That's the reason for this whole thread: developers chose the
technological superior alternative; saying that the reason for that is
that there is cabals and conspiracies is blatant ignorance (in the
best case), or spreading FUD (in the worst case).

>> Or help Samuli to maintain upower-pm-utils; that would be *much* more
>> helpful than spreding FUD about cabals and conspiracies.
>
> There is no need for me to invent Fear, Uncertainty, and Doubt -- the
> folks involved are doing quite well on their own.

I never said you "invented" it. I say you are spreading it, and I
still think that's the case.

> Also, history (for
> those not doomed to repeat it [1]) provides all that is required to make
> calling it a "cabal"  [TINC - there is no cabal![2]]  There never was a
> Usenet Backbone Cabal in any formal sense, but there was plenty of
> semi-(un)coordinated activity -- based largely on shared ideals -- that
> gave that appearance.  {I was there when Usenet/Netnews was invented,
> closely observing, making minor and not-so-minor contributions, and was
> responsible for some of the "cabal-like" activities.}

Great; so any kind of group work "semi-(un)coordinated" can be called
a cabal, and it has no (inherent) negative connotation. Then the Linux
Kernel developers is a Cabal; the GNOME devs is a Cabal; the KDE ones
are also a Cabal; and of course the Gentoo Developers who *oppose*
systemd is a Cabal, and so are the ones that *support* systemd.

So you yourself are saying that calling out a "Cabal" of systemd
proponents have no meaning at all whatsoever, because *EVERYTHING* is
a Cabal.

> The mere coinage of terms like "Lennertware," whether or not deserved,
> show that there is a widespread awareness that some developers, in my
> opinion, have over developed egos. [3]

Yeah, please go and check out the "contributions" (when they exist) of
the people that seriously use the term "Lennartware". Doesn't matter
to what project, check out what they have contributed over the years.
Go on, I wait; it would not take you long, because they usually are
NOT developers, and the few that are actually developers haven't
contributed really that much.

Now go on and check out the contributions of the people that say that,
please, do not use the term Lennartware.

There is *NO* "widespread awareness". There is a small but really loud
group of people that are unwilling and/or unable to create good code
that all distributions wants to use, and therefore use childish
tactics like coining terms like "Lennartware".

> It is all so trite to say "become a developer and DO something instead
> of complaining"  but it is not a realistic thing to say when the
> problems are getting so large and interconnected.

And that's the root of your misunderstanding Greg. There are no
"problems"; this "interconnection" is by design, because many
developers are fed up with a Lego-like plumbing where you can
interchange any basic component like a Lego block, all of them equally
weak and fragile, which makes the testing matrices of all
distributions a nightmare to maintain.

So they are creating a single plumbing layer that we are calling
systemd. This is not a "problem", although there are developers that
see it that way; this is a technical solution to a technical problem.

Furthermore, it works GREAT, and the best proof of that is that
basically Gentoo and Slackware (I think) are the only distributions
not using it by default.

> Furthermore, it
> denigrates and devalues the "pseudo-democratic" processes that FOSS and
> Linux have worked for years to nurture.

There was *never* a "pseudo-democratic" process in FOSS or Linux.
NEVER. It would be a *terrible* mistake.

It has always been a *meritocratic* process. That's why we have
"benevolent dictators" everywhere in the community:

THOSE WHO WRITE THE CODE, MAKE THE RULES.

So if you want to change the rules, start writing some code.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Greg Woodbury]

On 06/04/2014 11:11 AM, Canek Peláez Valdés wrote:
> On Wed, Jun 4, 2014 at 5:28 AM, Greg Woodbury <redwolfe@gmail.com> wrote:

>> To see this as only freedom for the developer is part of an attitude
>> shift over the years that only lessens the overall usefulness of Linux
>> and FOSS. It does, in fact, push quite a few folk I know away from the
>> Linux arena. It is, to use a political analogy, like the people who
>> claim there "is not any real difference" between *any* opposing
>> political movements -- that neglects taking into account a great deal of
>> technical and historical details.
> 
> I have no idea what do you mean by the last paragraph. This is not a
> political discusion (although many would like to see it that way). It
> is a *technical* discusion, and therefore there is no real discusion:
> the general consensus is that systemd is the technological superior
> alternative.

It is a discussion about technological things, yes, but the art of
dealing with other people *is* politics [1].

Systemd *may* well be technologically superior in terms of having a
better method of doing things. (It certainly makes adding items to the
mix easier than re-doing all the numbering in SysVinit.)

Unfortunately, the advocates and implementers made some major political
choices when they (apparently deliberately) chose to put the systemd
stuff in /usr/lib instead of /lib.  It was pointed out that this
abrogated certain parts of the FHS, forced those who would like to adopt
it to *not* being able to continue using their machines they way they
wished to (I.e. they had to choose between several potentially major
changes to do so -- don't have a separate /usr or be forced to use a
kernel initrd/initramfs method in order to do so.)

These were not mere technical choices, but highly political/social
choices.  Early on, the violation of the "principle of least surprise"
could have been easily fixed by simply correcting the placement of
things from /usr back to / but the developers doing the work *chose* not
to see it as a mistake or poor choice, and steadfastly refused to accept
corrections or patches to improve the work by fixing what many saw as a
mistake.

That placement error was not the only social/political mistake they made
either.  Other suggestions and improvements were offered and were
ignored or rejected in rather flammable verbiage.

As it happens, some of the parties involved work for companies that
actually pay them to do work on Linux and FOSS, and have leveraged that
role to the fullest.

>> I occasionally think about forking projects and fixing some of the
>> things I think are the most egregious fsck-ups in some of them, but then
>> I really look at what I'm doing and what I enjoy doing, and realize that
>> I won't get enough (emotional?) reward for giving up time in other
>> significant parts of my life.
> 
> And that's your right, and it's fine. But let *other* developers
> choose whatever technologies they want to choose, and (consequently)
> drop support for obsolete technologies like pm-utils.

Actually, that is not the objection.  Developers do and have always done
that, but often observed much more concern with a) letting folks who use
their stuff know what they were doing, and b) giving a bit more lead
time when introducing major changes.

> 
> That's the reason for this whole thread: developers chose the
> technological superior alternative; saying that the reason for that is
> that there is cabals and conspiracies is blatant ignorance (in the
> best case), or spreading FUD (in the worst case).
> 
>>> Or help Samuli to maintain upower-pm-utils; that would be *much* more
>>> helpful than spreding FUD about cabals and conspiracies.
>>
>> There is no need for me to invent Fear, Uncertainty, and Doubt -- the
>> folks involved are doing quite well on their own.
> 
> I never said you "invented" it. I say you are spreading it, and I
> still think that's the case.
> 
>> Also, history (for
>> those not doomed to repeat it [1]) provides all that is required to make
>> calling it a "cabal"  [TINC - there is no cabal![2]]  There never was a
>> Usenet Backbone Cabal in any formal sense, but there was plenty of
>> semi-(un)coordinated activity -- based largely on shared ideals -- that
>> gave that appearance.  {I was there when Usenet/Netnews was invented,
>> closely observing, making minor and not-so-minor contributions, and was
>> responsible for some of the "cabal-like" activities.}
> 
> Great; so any kind of group work "semi-(un)coordinated" can be called
> a cabal, and it has no (inherent) negative connotation. Then the Linux
> Kernel developers is a Cabal; the GNOME devs is a Cabal; the KDE ones
> are also a Cabal; and of course the Gentoo Developers who *oppose*
> systemd is a Cabal, and so are the ones that *support* systemd.

Mo, you misunderstand.  TINC is/was a humorous reminder that there was
NOT a real "cabal", but merely the appearance of one in the minds of
those not involved in the day-to-day operations of real systems and
networks.  The human mind sees patterns and invents explanations when
there is not enough information available.  There is no reason to
ascribe to malice that which is adequately explained by ignorance or
stupidity (willful ignorance.)


>> The mere coinage of terms like "Lennertware," whether or not deserved,
>> show that there is a widespread awareness that some developers, in my
>> opinion, have over developed egos. [3]
> 
> Yeah, please go and check out the "contributions" (when they exist) of
> the people that seriously use the term "Lennartware". Doesn't matter
> to what project, check out what they have contributed over the years.
> Go on, I wait; it would not take you long, because they usually are
> NOT developers, and the few that are actually developers haven't
> contributed really that much.

In *your* opinion.  I have heard some surprising folks say things in
private that they would never choose to state publicly.  And that covers
a lot of people in over 53 years of programming.


>> It is all so trite to say "become a developer and DO something instead
>> of complaining"  but it is not a realistic thing to say when the
>> problems are getting so large and interconnected.
> 
> And that's the root of your misunderstanding Greg. There are no
> "problems"; this "interconnection" is by design, because many
> developers are fed up with a Lego-like plumbing where you can
> interchange any basic component like a Lego block, all of them equally
> weak and fragile, which makes the testing matrices of all
> distributions a nightmare to maintain.

I *do* no misunderstand this at all.  You attribute to folks (myself
included) motivations or misunderstandings that you simply do not have
the information or knowledge to know for certain.  If someone sees
something as a problems that you don't agree is a "problem" it may just
be that your experience or expertise is different.

There is a large amount of ego preservation and self-promotion involved
in these arguments, and many don't have enough insight to recognize that
humor and social skill are necessary to succeed.

>> Furthermore, it
>> denigrates and devalues the "pseudo-democratic" processes that FOSS and
>> Linux have worked for years to nurture.
> 
> There was *never* a "pseudo-democratic" process in FOSS or Linux.
> NEVER. It would be a *terrible* mistake.
> 
> It has always been a *meritocratic* process. That's why we have
> "benevolent dictators" everywhere in the community:

It merely claims to be a meritocracy. But like several other *political*
models, it boils down to an oligarchy, where those who obtain power by
whatever means, whether consciously or unconsciously, do what they must
to preserve it.

And the early days of Usenet was deliberately modeled in a
pseudo-democratic manner.  An opinion poll was set up in order to gain
some idea about the potential and perceived use for a topic area.  If
one wanted a topic group established on a widespread basis one needed a
fair bit of social skill and perception in order to do so.
> 
> THOSE WHO WRITE THE CODE, MAKE THE RULES.
Those who has the gold makes the rules?
> 
> So if you want to change the rules, start writing some code.

Been there. Done That. Have the T-shirt.
BUT, for *some* reason, I still care.

------------ Footnotes  --------

[1] Those who are politically active constantly deal with the more
politically naive who complain "there isn't really any difference
between <group_a> or <group_b> - they all suck."  This can be compared
to a technologically naive person saying "major software projects can be
thrown together by a bunch of programmers just sitting around together
at a coffee shop over the weekend."  (Don't laugh -- a US Supreme Court
Justice said almost exactly that within the past two weeks.)

-- 
G.Wolfe Woodbury
<No clever .sig found.>

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Thu, 05 Jun 2014 02:34:49 -0400
Greg Woodbury <redwolfe@gmail.com> wrote:

> On 06/04/2014 11:11 AM, Canek Peláez Valdés wrote:
> It is a discussion about technological things, yes, but the art of
> dealing with other people *is* politics [1].

Politics are also about dealing with power, not alone people; it is
possible to give a robot a lot of power, that doesn't imply that the
creator or buyer of that robot has power. The robot will have its own
will; that will isn't necessarily depending on what people tell the
robot to do, but also on what the robot will percept from nature. This
then all boils down to the nature's will; there may be a person, robot
or server with a lot of power, but one day the power of nature decides.

> Systemd *may* well be technologically superior in terms of having a
> better method of doing things. (It certainly makes adding items to the
> mix easier than re-doing all the numbering in SysVinit.)
> 
> Unfortunately, the advocates and implementers made some major
> political choices when they (apparently deliberately) chose to put
> the systemd stuff in /usr/lib instead of /lib.  It was pointed out
> that this abrogated certain parts of the FHS, forced those who would
> like to adopt it to *not* being able to continue using their machines
> they way they wished to (I.e. they had to choose between several
> potentially major changes to do so -- don't have a separate /usr or
> be forced to use a kernel initrd/initramfs method in order to do so.)

This is the power of putting things in such places against the power of
the FHS; Gentoo uses its power to allow parts of these powers to exist,
as "Gentoo does not consider the Filesystem Hierarchy Standard to be an
authoritative standard, although much of our policy coincides with it.".

http://devmanual.gentoo.org/general-concepts/filesystem

You note how it abrogates part of the power of the FHS, but you don't
mention its consequences and how Gentoo deals with those consequences;
this highlights a power, instead of how that power affects people.

So, yes, eventually politics deal with people; but it does so through
means of dealing with power, only looking at the power or only looking
at the people deceives one from the total picture. Look at both instead.

> These were not mere technical choices, but highly political/social
> choices.  Early on, the violation of the "principle of least surprise"
> could have been easily fixed by simply correcting the placement of
> things from /usr back to / but the developers doing the work *chose*
> not to see it as a mistake or poor choice, and steadfastly refused to
> accept corrections or patches to improve the work by fixing what many
> saw as a mistake.

Where did we agree with the power of the "principle of least surprise"?

What kind of surprise towards the users are we talking about? Short
term surprise? Long term surprise? How does that affect our users?

It can be a mistake in the short term, but that doesn't make it one in
the long term; things work out well, it seems, where is the problem?

> That placement error was not the only social/political mistake they
> made either.  Other suggestions and improvements were offered and were
> ignored or rejected in rather flammable verbiage.

This paragraph misses a reference to the mistakes and verbiage.
 
> As it happens, some of the parties involved work for companies that
> actually pay them to do work on Linux and FOSS, and have leveraged
> that role to the fullest.

Some people give up on money, to reach something else in their life;
"Hey, honey, I don't want you to move to Silicon Valley; stay with me.".

> Actually, that is not the objection.  Developers do and have always
> done that, but often observed much more concern with a) letting folks
> who use their stuff know what they were doing, and b) giving a bit
> more lead time when introducing major changes.

The "road map" concept exists for that purpose; however, a lot of
developers don't use such thing or use it in some other way (TODOs,
bugs that capture feature requests and important changes, ...); what is
however a more used concept are "change logs", where these kind of
things are mentioned. But can users track all upstream's major changes?

> Mo, you misunderstand.  TINC is/was a humorous reminder that there was
> NOT a real "cabal", but merely the appearance of one in the minds of
> those not involved in the day-to-day operations of real systems and
> networks.  The human mind sees patterns and invents explanations when
> there is not enough information available.  There is no reason to
> ascribe to malice that which is adequately explained by ignorance or
> stupidity (willful ignorance.)

This leaves out "possibilities"; a possible explanation doesn't make it
a factual true explanation of the matter at hand, like how you've
mentioned mistakes and verbiage above.

It might be true to you, because you might have these references; it
could also be a possibility to you, because you think you saw such
pattern but can't bring it back up; ...

Now, to me it will by default be a possibility; because for it to be
a factual true to me, I need to be given the reference I've requested.

> In *your* opinion.  I have heard some surprising folks say things in
> private that they would never choose to state publicly.  And that
> covers a lot of people in over 53 years of programming.

I could've heard the opposite; who of us both will people believe?

> I *do* no misunderstand this at all.  You attribute to folks (myself
> included) motivations or misunderstandings that you simply do not have
> the information or knowledge to know for certain.

Consider that similar attributions are seen from you.

> If someone sees something as a problems that you don't agree is a
> "problem" it may just be that your experience or expertise is
> different.
> 
> There is a large amount of ego preservation and self-promotion
> involved in these arguments, and many don't have enough insight to
> recognize that humor and social skill are necessary to succeed.

Boring jokes and social interruptions stall[1] instead of succeed.

> It merely claims to be a meritocracy. But like several other
> *political* models, it boils down to an oligarchy, where those who
> obtain power by whatever means, whether consciously or unconsciously,
> do what they must to preserve it.
> 
> And the early days of Usenet was deliberately modeled in a
> pseudo-democratic manner.  An opinion poll was set up in order to gain
> some idea about the potential and perceived use for a topic area.  If
> one wanted a topic group established on a widespread basis one needed
> a fair bit of social skill and perception in order to do so.

Nothing holds you from starting a poll on a poll site and do that
today; you'll however note that such poll, either now or back in the
days, doesn't force people to do things.

Power's will goes hand in hand with people's will.

> Those who has the gold makes the rules?

In Belgium we say "Klant is koning",
which translates to "The customer is the king";
you might have a lot of money, that doesn't mean you can set up
whichever rule you want and expect that behavior to be blindly followed.

No, customers will just move on to the next company; regardless of the
gold a company has. The same goes with people in politics, you might
have all the gold to advertise yourself; but that doesn't mean you get a
majority of votes and a political reformation in your favor.

> > So if you want to change the rules, start writing some code.
> 
> Been there. Done That. Have the T-shirt.
> BUT, for *some* reason, I still care.

No, really; if you want to form rules, write some code and get the
people you want to change the rules for to be interested in your work. 
 
> ------------ Footnotes  --------
> 
> [1] Those who are politically active constantly deal with the more
> politically naive who complain "there isn't really any difference
> between <group_a> or <group_b> - they all suck."  This can be compared
> to a technologically naive person saying "major software projects can
> be thrown together by a bunch of programmers just sitting around
> together at a coffee shop over the weekend."  (Don't laugh -- a US
> Supreme Court Justice said almost exactly that within the past two
> weeks.)

[1] It really does.

-- 
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-user] Systemd upower

[Rich Freeman]

On Thu, Jun 5, 2014 at 2:34 AM, Greg Woodbury <redwolfe@gmail.com> wrote:
> Unfortunately, the advocates and implementers made some major political
> choices when they (apparently deliberately) chose to put the systemd
> stuff in /usr/lib instead of /lib.  It was pointed out that this
> abrogated certain parts of the FHS, forced those who would like to adopt
> it to *not* being able to continue using their machines they way they
> wished to (I.e. they had to choose between several potentially major
> changes to do so -- don't have a separate /usr or be forced to use a
> kernel initrd/initramfs method in order to do so.)

My understanding is that the systemd developers intend for systemd to
not be installed in /usr unless /lib and so on are symlinks to their
counterparts in /usr (ie the /usr-merge is completed).

That has been the subject of some debate for Gentoo.

I think the reason so much stuff is migrating to /usr is the sense
that keeping things split up is becoming more hassle than it is worth
due to all the vertical integration.  If you have a bluetooth keyboard
then you're going to be hard-pressed to use your system without /usr
mounted.  That is the standard example, but the sense is that this is
the way the wind is blowing.  Virtually every distro out there uses an
initramfs anyway - we're a bit of an aberration in that it seems that
using an initramfs is rare among Gentoo users.

Just look at an initramfs as the new root filesystem.  There really
isn't anything you could do with a shell without /usr mounted that you
can't do with a shell in an initramfs.

Rich

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 05/06/14 14:11, Rich Freeman wrote:
> On Thu, Jun 5, 2014 at 2:34 AM, Greg Woodbury <redwolfe@gmail.com> wrote:
>> Unfortunately, the advocates and implementers made some major political
>> choices when they (apparently deliberately) chose to put the systemd
>> stuff in /usr/lib instead of /lib.  It was pointed out that this
>> abrogated certain parts of the FHS, forced those who would like to adopt
>> it to *not* being able to continue using their machines they way they
>> wished to (I.e. they had to choose between several potentially major
>> changes to do so -- don't have a separate /usr or be forced to use a
>> kernel initrd/initramfs method in order to do so.)
> My understanding is that the systemd developers intend for systemd to
> not be installed in /usr unless /lib and so on are symlinks to their
> counterparts in /usr (ie the /usr-merge is completed).

Correct. As in, if you git clone system repository, and run ./autogen.sh
on it,
it will recommend options that will put systemd to /, not /usr
And multiple systemd upstream developers think it's an bad idea to install
systemd to /usr if the /usr-merge is not complete, Kay, Lennart, and others
have said it out loud on ML and #systemd, Freenode
So, it's entirely Gentoo systemd maintainers decision to install into /usr
even without the /usr-merge

>
> I think the reason so much stuff is migrating to /usr is the sense
> that keeping things split up is becoming more hassle than it is worth
> due to all the vertical integration.  If you have a bluetooth keyboard
> then you're going to be hard-pressed to use your system without /usr
> mounted.  That is the standard example, but the sense is that this is
> the way the wind is blowing.  Virtually every distro out there uses an
> initramfs anyway - we're a bit of an aberration in that it seems that
> using an initramfs is rare among Gentoo users.
>
> Just look at an initramfs as the new root filesystem.  There really
> isn't anything you could do with a shell without /usr mounted that you
> can't do with a shell in an initramfs.
>
>

That'd be accurate.

Re: [gentoo-user] Systemd upower

[Tanstaafl]

On 6/3/2014 1:08 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Tue, Jun 3, 2014 at 11:48 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> On 6/3/2014 11:10 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> Maybe. The thing is, this is going to keep happening, as more and more
>>> infrastructure migrates towards systemd. Perhaps a news item everytime
>>> it happens is unrealistic?

>> Weren't you the one saying that those of us who were voicing concerns that
>> systemd proponents were ultimately wanting to FORCE systemd on everyone were
>> just scare-mongering conspiracy theorists?

> Who is "forcing"  anything?

I was specifically referring to your comment that:

> The thing is, this is going to keep happening, as more and more
> infrastructure migrates towards systemd.

That comment right there - specifically the word *infrastructure* - 
screams to me 'we intend to take over the world'.

And yes, as devs get lazier (decide to rely on systemd rather than build 
it to work independently of the init system), this will in fact result 
in *users* (read: those lacking the skills to code every program out 
there to work without systemd) eventually being *forced* to switch to 
systemd.

That is simply the reality. You can ignore it if you like, but it 
doesn't change it. Forced is forced.

> That's what you and many others don't seem to understand: systemd is a
> *BETTER* implementation for basically *ALL* the hodgepodge of
> "solutions" that we had before in our plumbing layer.

Time will tell, and you may even be right. The problem is, average users 
really don't have a way to prove this to themselves, all we see is the 
wailing and gnashing of teeth as stuff constantly *breaks* that *never* 
broke before.

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 04/06/14 15:21, Tanstaafl wrote:
> On 6/3/2014 1:08 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Tue, Jun 3, 2014 at 11:48 AM, Tanstaafl
>> <tanstaafl@libertytrek.org> wrote:
>>> On 6/3/2014 11:10 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>> Maybe. The thing is, this is going to keep happening, as more and more
>>>> infrastructure migrates towards systemd. Perhaps a news item everytime
>>>> it happens is unrealistic?
>
>>> Weren't you the one saying that those of us who were voicing
>>> concerns that
>>> systemd proponents were ultimately wanting to FORCE systemd on
>>> everyone were
>>> just scare-mongering conspiracy theorists?
>
>> Who is "forcing"  anything?
>
> I was specifically referring to your comment that:
>
>> The thing is, this is going to keep happening, as more and more
>> infrastructure migrates towards systemd.
>
> That comment right there - specifically the word *infrastructure* -
> screams to me 'we intend to take over the world'.
>
> And yes, as devs get lazier (decide to rely on systemd rather than
> build it to work independently of the init system), this will in fact
> result in *users* (read: those lacking the skills to code every
> program out there to work without systemd) eventually being *forced*
> to switch to systemd.

You can still install GNOME without systemd from Portage using the
USE="openrc-force" (which needs to be unmasked using
/etc/portage/profile/use.mask line like
-openrc-force)

And nobody is ever forced to do anything within Open Source, you always
have the option to contibute code, or donate money to get someone
else contribute the code

Calling volunteers who work without paycheck lazy is just bad behavior

>
> That is simply the reality. You can ignore it if you like, but it
> doesn't change it. Forced is forced.
>
>> That's what you and many others don't seem to understand: systemd is a
>> *BETTER* implementation for basically *ALL* the hodgepodge of
>> "solutions" that we had before in our plumbing layer.
>
> Time will tell, and you may even be right. The problem is, average
> users really don't have a way to prove this to themselves, all we see
> is the wailing and gnashing of teeth as stuff constantly *breaks* that
> *never* broke before.
>

Nothing has been broken so far yet. People are just facing hard
realities and noticing some packages have been abandoned for years, even
before systemd became popular as it is now. You can't blame systemd,
upower, and other developers for ditching such outdated code and
using what they like as they code it for their application.

- Samuli

Re: [gentoo-user] Systemd upower

[Rich Freeman]

On Wed, Jun 4, 2014 at 8:21 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> And yes, as devs get lazier (decide to rely on systemd rather than build it
> to work independently of the init system), this will in fact result in
> *users* (read: those lacking the skills to code every program out there to
> work without systemd) eventually being *forced* to switch to systemd.
>
> That is simply the reality. You can ignore it if you like, but it doesn't
> change it. Forced is forced.

Well, if your goal is to persuade people to change, I'd suggest taking
that to the upower mailing list, since they're the ones who added the
systemd requirement.  All anybody at Gentoo did was fork it and
provide an alternative.  The fiasco was the result of it being unclear
that the option existed.

However, the general trend I've seen is that when people complain to
upstreams that they don't want them to depend on systemd, upstream
tends to tell them to go make their own upstream.  So, instead they
complain on lists that don't ban them, like this one.  It doesn't
really fix anything though - it just gets everybody upset and often
results in misdirected anger.  The only thing Samuli did was give
non-systemd users a workaround for an upstream problem, and the news
clarifying this came out a bit late.

I generally intend to switch over to systemd, but I for one would love
for there to be the option to use alternatives. Simply wishing that
won't make it happen, and since i don't really intend to use the
alternatives it is a bit hard to get the motivation to help fork the
world.  That's just the way the wind seems to be blowing these days.

Rich

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 04/06/14 15:58, Rich Freeman wrote:
> On Wed, Jun 4, 2014 at 8:21 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> And yes, as devs get lazier (decide to rely on systemd rather than build it
>> to work independently of the init system), this will in fact result in
>> *users* (read: those lacking the skills to code every program out there to
>> work without systemd) eventually being *forced* to switch to systemd.
>>
>> That is simply the reality. You can ignore it if you like, but it doesn't
>> change it. Forced is forced.
> Well, if your goal is to persuade people to change, I'd suggest taking
> that to the upower mailing list, since they're the ones who added the
> systemd requirement.  

General misconseption here, let me clarify a bit.
 Instead, UPower upstream simply dropped unmaintained pm-utils code
since pm-utils has been abandoned for years and nobody picked it up
during these years.
So, UPower didn't add any systemd requiring code, they simply dropped
Hibernate/Suspend capability,
and left it to other programs (such as systemd).
Notice how UPower 0.99.0 doesn't have anykind of systemd dependency. The
package simply, by design,
isn't a package that does Hibernate/Suspend anymore.
Fact that OpenRC doesn't have Hibernate/Suspend support is due to
problem in "our end", nobody
is working on such code for OpenRC, like there are people working on
such code for systemd.

> The only thing Samuli did was give non-systemd users a workaround for
an upstream problem, and the news clarifying this came out a bit late. I
generally intend to switch > over to systemd, but I for one would love
for there to be the option to use alternatives. Simply wishing that
won't make it happen, and since i don't really intend to use the >
alternatives it is a bit hard to get the motivation to help fork the
world. That's just the way the wind seems to be blowing these days. Rich

You are right as for rest of the mail goes. Nobody can possible expect
me to suddently come up with Hibernate/Suspend patch for OpenRC myself.
I can state that I have no plans to work on anything like that without
getting paid for it, and propably not even then, as I suspect it would
be too
big task for me to take up. I have no intentions in picking up pm-utils
maintainership either.
I have no idea how people will do Hibernate/Suspend in the future
without systemd, I suspect it will get harder and harder. If I were to buy
a new laptop today, I'd propably install systemd on it, to get
up-to-date code for those tasks.

So yeah, only working with what upstreams provide as a distribution
maintainer/packager, and people shouldn't try to dump this somehow on
me. Fact that
they have some fallback, like upower-pm-utils at all, is something they
should be grateful instead.

(I hope I didn't mess up quoting in this mail.)

Re: [gentoo-user] Systemd upower

[Marc Joliet]

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

Am Wed, 04 Jun 2014 16:08:02 +0300
schrieb Samuli Suominen <ssuominen@gentoo.org>:

[...]
> So yeah, only working with what upstreams provide as a distribution
> maintainer/packager, and people shouldn't try to dump this somehow on
> me. Fact that
> they have some fallback, like upower-pm-utils at all, is something they
> should be grateful instead.
[...]

I'm grateful!  In fact, since I have this opportunity: thank you and all the
other devs for your hard work, and for withstanding insufferable users :) .

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

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

Re: [gentoo-user] Systemd upower

[Peter Humphrey]

On Wednesday 04 June 2014 20:28:22 Marc Joliet wrote:

> I'm grateful!  In fact, since I have this opportunity: thank you and all the
> other devs for your hard work, and for withstanding insufferable users :) .

[AOL]

Me too.

[/AOL]

-- 
Regards
Peter

Re: [gentoo-user] Systemd upower

[Neil Bothwick]

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

On Wed, 04 Jun 2014 08:21:51 -0400, Tanstaafl wrote:

> And yes, as devs get lazier (decide to rely on systemd rather than
> build it to work independently of the init system),

Reusing existing, proven code is not laziness, it is efficiency. Yes,
they could code their own version, but all the time they spend coding and
testing it will not be spent on the actual project, we all end up with an
inferior product. Also, by adding to the software the uses systemd, or
any other underlying code, the number of users/testers of that code
increases.

You seem to think the Upower devs simply decided to use systemd instead
of doing it themselves. In fact, they were always using code, from either
systemd or pm-utils. The fact that development stopped on pm-utils is
neither the fault of the Upower or systemd people. They were reduced to a
choice of one and you blame them for making the wrong choice?


-- 
Neil Bothwick

"Theory and practice are the same in theory, but different in practice"

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

Re: [gentoo-user] Systemd upower

[Samuli Suominen]

On 04/06/14 16:47, Neil Bothwick wrote:
> On Wed, 04 Jun 2014 08:21:51 -0400, Tanstaafl wrote:
>
>> And yes, as devs get lazier (decide to rely on systemd rather than
>> build it to work independently of the init system),
> Reusing existing, proven code is not laziness, it is efficiency. Yes,
> they could code their own version, but all the time they spend coding and
> testing it will not be spent on the actual project, we all end up with an
> inferior product. Also, by adding to the software the uses systemd, or
> any other underlying code, the number of users/testers of that code
> increases.
>
> You seem to think the Upower devs simply decided to use systemd instead
> of doing it themselves. In fact, they were always using code, from either
> systemd or pm-utils. The fact that development stopped on pm-utils is
> neither the fault of the Upower or systemd people. They were reduced to a
> choice of one and you blame them for making the wrong choice?
>
>

Well said.

Apologies - WAS: Re: [gentoo-user] Systemd upower

[Tanstaafl]

On 6/4/2014 9:47 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> You seem to think the Upower devs simply decided to use systemd instead
> of doing it themselves. In fact, they were always using code, from either
> systemd or pm-utils. The fact that development stopped on pm-utils is
> neither the fault of the Upower or systemd people. They were reduced to a
> choice of one and you blame them for making the wrong choice?

Actually, I wasn't talking about upower specifically, I was talking 
about this whole slippery slope that is systemd - but you are right, and 
I absolutely apologize for my comment about 'lazy devs', and most of my 
other negative comments.

I still don't like the way systemd seems to be devouring everything to 
the point that it is apparently inevitable that it will become the 
default init system for all linux system.

But I also admit that this is more just personal bias against 
Lennart/Kay/etc and all things related to them, all coming just from the 
many threads I've read, and also just fear of change in general (being 
that I am *not* a programmer, and am *not* capable of doing anything 
about this myself, regardless of if I would have the time or not).

So, I will absolutely cease and desist denigrating systemd, at least 
until such time as I can speak from direct personal experience.

First question: is there a decent guide to installing a gentoo system 
from scratch using systemd as the init system?

Second question: is there a decent guide to how to switch from OpenRC to 
systemd?

Third question: is there a decent guide on how to switch from systemd 
back to OpenRC, if I encounter any serious problems on a production box?

Thanks, and again, my apologies for starting another flame-fest, and 
especially for basically abandoning the thread afterwards (busy week 
last week)...

Re: Apologies - WAS: Re: [gentoo-user] Systemd upower

[Rich Freeman]

On Sun, Jun 8, 2014 at 1:26 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>
> First question: is there a decent guide to installing a gentoo system from
> scratch using systemd as the init system?

I've done this a few times on VMs.  Just follow the handbook, but skip
steps about configuring hostname/timezone/locale/etc since systemd
does this (but do set up locale.gen).  Then follow the systemd install
guide.  If you follow both guides to completion you won't hurt
anything, but you'll just end up configuring some things twice (but
systemd does migrate some of your settings over).

>
> Second question: is there a decent guide to how to switch from OpenRC to
> systemd?

Yes, the systemd wiki page is the best place to go for this.  It is
pretty straightfoward.

The only thing I'd do differently is just use networkd.  The guide
doesn't include that yet.

cat > /etc/systemd/network/dhcp.network
[Match]
Name=en*

[Network]
DHCP=yes
--- end file ---

(as long as you keep the extension you can call that file whatever you
want, and if your interface doesn't match that glob you can tweak it)

Also, if you have any network filesystems be sure to set the _netdev
option in fstab.

>
> Third question: is there a decent guide on how to switch from systemd back
> to OpenRC, if I encounter any serious problems on a production box?

For the most part you can just change the init setting on your kernel
line to switch back and forth.  You'll end up using udev packaged with
systemd, but for the most part that shouldn't cause too many problems.
Oh, if you're using dracut there is a chance it won't realize you
aren't running systemd in your kernel and that could cause some issues
(I was getting some of that before I intended to cut over to systemd
in my last migration, but I didn't mess with it for long).

Just keep in mind that immediately following the migration you won't
have any services enabled.  That means no network, no sshd, etc.
Starting that stuff up is pretty easy, but it is just like having a
fresh OpenRC install.

Rich

Re: [gentoo-user] Systemd upower

[Canek Peláez Valdés]

On Wed, Jun 4, 2014 at 7:21 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 6/3/2014 1:08 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
[ ... ]
>> Who is "forcing"  anything?
>
>
> I was specifically referring to your comment that:
>
>> The thing is, this is going to keep happening, as more and more
>> infrastructure migrates towards systemd.
>
> That comment right there - specifically the word *infrastructure* - screams
> to me 'we intend to take over the world'.

Well, yeah; that has been the objective from day 1. That systemd is
used by default by almost all Linux users and distributions. Nobody
has ever claimed anything on the contrary. And we are pretty advanced
in that objective, by the way.

That doesn't mean that anything is being force on anyone. SysV is
still available, and so it is OpenRC, and so it is pm-utils (although
it's been 5 years since last updated). Go on and use them if you want.

Oh, you want *someone else* to do that work for you? Sorry, is not
going to happen.

You want that ALL the infrastructure to keep working with something
else besides systemd? Go on and make it work with OpenRC, pm-utils,
ConsoleKit and HAL.

Oh, you want *someone else* to do that work for you? Sorry, not gonna happen.

If the people *IN CHARGE* of the infrastructure decides to use
systemd, they are not forcing nothing on no one. They are taking
*their code* and making it better by using the technologically
superior option.

> And yes, as devs get lazier (decide to rely on systemd rather than build it
> to work independently of the init system),

Really? They are lazy? That means is "easy" to not rely on systemd,
right? So go on and make their projects not to rely on systemd, if it
is so easy.

> this will in fact result in
> *users* (read: those lacking the skills to code every program out there to
> work without systemd) eventually being *forced* to switch to systemd.

NO THEY ARE NOT. Really, almost *all* the code we Linux users get to
use is a freakin' *GIFT*, and the developers responsible for it decide
to use A BETTER OPTION (like systemd is), and some people have the
*audacity* to call that "forcing" them something?

THE CODE IS FREE, for all the meanings of the word "free". Therefore,
there is no "forcing" of NOTHING on NO ONE.

There can't be.

Seriously, I haven't ever said what I'm about to say, but I'm getting
really tired of this same old discussion about some users thinking
they have the right to tell developers what they can or can't use in
their code.

You want your Linux to behave like the Unices of the 70's? Forget it;
that train is gone. Linux (as in mainstream) is going to use systemd
everywhere, from embedded to big iron, and that is for the best.

If you want a 70's-like Unix, go on and install FreeBSD.

> That is simply the reality. You can ignore it if you like, but it doesn't
> change it. Forced is forced.

No, it's a "reality" you invented in your head. Take the code and do
wonders with it; is free.

Oh, you can't? Then you are not being forced anything; you are just
unable to make the things work like you want.

That's totally different.

>> That's what you and many others don't seem to understand: systemd is a
>> *BETTER* implementation for basically *ALL* the hodgepodge of
>> "solutions" that we had before in our plumbing layer.
>
> Time will tell, and you may even be right. The problem is, average users
> really don't have a way to prove this to themselves, all we see is the
> wailing and gnashing of teeth as stuff constantly *breaks* that *never*
> broke before.

Really, Tanstaafl? Because in this list I usually see the *SAME* small
group of people complaining about systemd. From time to time some new
systemd user asks about some issues they found, but for the most part
they (with the list help) solve those issues.

And the world goes on. Users didn't abandoned Fedora, OpenSuse, Arch,
Debian nor Ubuntu "en masse" when they decided to switch to systemd.
There were complains, sure; but now it seems to have calmed down. Most
systemd users (wether they chose to use systemd or their distributions
did it for them) seem to be happy.

And guess what? They will not abandon Gentoo if it ever decides to
switch to systemd.

Although I'm pretty sure a small (tiny, really) number of
fundamentalist users will go to *BSD. And that's their choice.

Perhaps you should consider doing that? And I'm saying that with all
due respect; but be aware that on *BSD, the developers there also make
their own decisions.

If you want your systemd *exactly* the way you want it, you have to
write it yourself. Nobody is going to do it for you.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd upower

[Alan McKinnon]

On 03/06/2014 18:48, Tanstaafl wrote:
> On 6/3/2014 11:10 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> Maybe. The thing is, this is going to keep happening, as more and more
>> infrastructure migrates towards systemd. Perhaps a news item everytime
>> it happens is unrealistic?
> 
> Weren't you the one saying that those of us who were voicing concerns
> that systemd proponents were ultimately wanting to FORCE systemd on
> everyone were just scare-mongering conspiracy theorists?
> 
> 
> 


I don't think that is what is happening here.

The upower devs decided to stop inventing their own wheel wrt
hibernate/suspend and instead use the code for the same purpose that is
in systemd, lower down the stack. In some way this makes sense, much
like if you had your own hand-rolled ssl code and decided to drop it in
favour of linking with openssl.

The bad news is that upower was the last project actively working on
hibernate/suspend outside of systemd, so it can look like conspiracy theory.

The good news is that the version of upower prior to this decision still
works fine and likely will for ages to come. That code has been bundled
into a new package upower-pm-utils.

Anyone that feels like doing it can now step up to the plate and
continue the work upower was doing earlier.

Perhaps it really is a case of projects are migrating to systemd because
there's an advantage to doing so and makes a dev's life easier.





-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Systemd upower

[»Q«]

On Tue, 03 Jun 2014 22:06:07 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> The good news is that the version of upower prior to this decision
> still works fine and likely will for ages to come. That code has been
> bundled into a new package upower-pm-utils.
> 
> Anyone that feels like doing it can now step up to the plate and
> continue the work upower was doing earlier.

I don't understand the development status of upower-pm-utils.  Is there
someone either upstream or with Gentoo committed to maintaining it?  Or
is it a git branch created just to meet the current needs of
non-systemd Gentoo users?

Re: [gentoo-user] Re: Systemd upower

[Samuli Suominen]

On 05/06/14 01:14, »Q« wrote:
> On Tue, 03 Jun 2014 22:06:07 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
>> The good news is that the version of upower prior to this decision
>> still works fine and likely will for ages to come. That code has been
>> bundled into a new package upower-pm-utils.
>>
>> Anyone that feels like doing it can now step up to the plate and
>> continue the work upower was doing earlier.
> I don't understand the development status of upower-pm-utils.  Is there
> someone either upstream or with Gentoo committed to maintaining it?  

No, nobody is actively working on it, it's the abandoned upstream git
branch that used to be master before 0.99.0's release:

Current sys-power/upower-pm-utils is same as latest code from
http://cgit.freedesktop.org/upower/log/?h=0.9
And last commit is 2013

I might backport some fixes from git master over at some point later,
but I won't do any promises

> Or
> is it a git branch created just to meet the current needs of
> non-systemd Gentoo users?
>
>

It's to be considered as a temporary solution for applications that need
the Hibernate and Suspend functionality
from UPower for non-systemd users, applications like
mate-session-manager, lxsession, uevt, and so forth

Migrating to >=sys-power/upower-0.99.0 is the recommended path to take
if at all possible. It's possible for eg.
Xfce users, because Xfce in ~arch integrated sys-power/pm-utils support
directly for Hibernate and Suspend
Also, GNOME 3.12 requires 0.99.0

- Samuli

Re: [gentoo-user] Re: Systemd upower

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1902 bytes --]

On Wednesday 04 Jun 2014 23:27:05 Samuli Suominen wrote:
> On 05/06/14 01:14, »Q« wrote:
> > On Tue, 03 Jun 2014 22:06:07 +0200
> > 
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >> The good news is that the version of upower prior to this decision
> >> still works fine and likely will for ages to come. That code has been
> >> bundled into a new package upower-pm-utils.
> >> 
> >> Anyone that feels like doing it can now step up to the plate and
> >> continue the work upower was doing earlier.
> > 
> > I don't understand the development status of upower-pm-utils.  Is there
> > someone either upstream or with Gentoo committed to maintaining it?
> 
> No, nobody is actively working on it, it's the abandoned upstream git
> branch that used to be master before 0.99.0's release:
> 
> Current sys-power/upower-pm-utils is same as latest code from
> http://cgit.freedesktop.org/upower/log/?h=0.9
> And last commit is 2013
> 
> I might backport some fixes from git master over at some point later,
> but I won't do any promises
> 
> > Or
> > is it a git branch created just to meet the current needs of
> > non-systemd Gentoo users?
> 
> It's to be considered as a temporary solution for applications that need
> the Hibernate and Suspend functionality
> from UPower for non-systemd users, applications like
> mate-session-manager, lxsession, uevt, and so forth
> 
> Migrating to >=sys-power/upower-0.99.0 is the recommended path to take
> if at all possible. It's possible for eg.
> Xfce users, because Xfce in ~arch integrated sys-power/pm-utils support
> directly for Hibernate and Suspend
> Also, GNOME 3.12 requires 0.99.0

Hi Samuli,

Are you saying that as things stand it is a matter of time before a gentoo 
user will have to switch from openrc to systemd, if they want/need to continue 
using sleep and hibernate?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: Systemd upower

[Samuli Suominen]

On 05/06/14 08:23, Mick wrote:
> On Wednesday 04 Jun 2014 23:27:05 Samuli Suominen wrote:
>> On 05/06/14 01:14, »Q« wrote:
>>> On Tue, 03 Jun 2014 22:06:07 +0200
>>>
>>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>> The good news is that the version of upower prior to this decision
>>>> still works fine and likely will for ages to come. That code has been
>>>> bundled into a new package upower-pm-utils.
>>>>
>>>> Anyone that feels like doing it can now step up to the plate and
>>>> continue the work upower was doing earlier.
>>> I don't understand the development status of upower-pm-utils.  Is there
>>> someone either upstream or with Gentoo committed to maintaining it?
>> No, nobody is actively working on it, it's the abandoned upstream git
>> branch that used to be master before 0.99.0's release:
>>
>> Current sys-power/upower-pm-utils is same as latest code from
>> http://cgit.freedesktop.org/upower/log/?h=0.9
>> And last commit is 2013
>>
>> I might backport some fixes from git master over at some point later,
>> but I won't do any promises
>>
>>> Or
>>> is it a git branch created just to meet the current needs of
>>> non-systemd Gentoo users?
>> It's to be considered as a temporary solution for applications that need
>> the Hibernate and Suspend functionality
>> from UPower for non-systemd users, applications like
>> mate-session-manager, lxsession, uevt, and so forth
>>
>> Migrating to >=sys-power/upower-0.99.0 is the recommended path to take
>> if at all possible. It's possible for eg.
>> Xfce users, because Xfce in ~arch integrated sys-power/pm-utils support
>> directly for Hibernate and Suspend
>> Also, GNOME 3.12 requires 0.99.0
> Hi Samuli,
>
> Are you saying that as things stand it is a matter of time before a gentoo 
> user will have to switch from openrc to systemd, if they want/need to continue 
> using sleep and hibernate?
>

For those tasks you mentioned...

...if other desktops don't migrate like Xfce, then something like:

Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
support in session and power managers),
OR c) switching to command line pm-* utilities directly from pm-utils

...might be inevitable

And if Linux kernel does changes that break pm-utils, which haven't had
a single commit since 2010
in upstream repository:

Switching to a) systemd, OR, b) wait, no other possibilities

Yes, that's really how poor the situation is, and don't shoot me, I'm
only the messenger :-)

- Samuli

Re: [gentoo-user] Re: Systemd upower

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1340 bytes --]

On Thursday 05 Jun 2014 08:25:30 Samuli Suominen wrote:
> On 05/06/14 08:23, Mick wrote:

> > Are you saying that as things stand it is a matter of time before a
> > gentoo user will have to switch from openrc to systemd, if they
> > want/need to continue using sleep and hibernate?
> 
> For those tasks you mentioned...
> 
> ...if other desktops don't migrate like Xfce, then something like:
> 
> Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
> support in session and power managers),
> OR c) switching to command line pm-* utilities directly from pm-utils
> 
> ...might be inevitable
> 
> And if Linux kernel does changes that break pm-utils, which haven't had
> a single commit since 2010
> in upstream repository:
> 
> Switching to a) systemd, OR, b) wait, no other possibilities
> 
> Yes, that's really how poor the situation is, and don't shoot me, I'm
> only the messenger :-)

Thanks Samuli, I don't shoot people, especially when they try to help me!  :-)

I use enlightenment on most machines and KDE on a couple of desktops, so I 
guess these would be the only two desktops that may be an issue for me.  
However, I had forgotten about the pm-* commands.  I just tried:

pm-is-supported --suspend-hybrid

and didn't get anything ... what am I missing?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: Systemd upower

[Samuli Suominen]

On 05/06/14 12:03, Mick wrote:
> On Thursday 05 Jun 2014 08:25:30 Samuli Suominen wrote:
>> On 05/06/14 08:23, Mick wrote:
>>> Are you saying that as things stand it is a matter of time before a
>>> gentoo user will have to switch from openrc to systemd, if they
>>> want/need to continue using sleep and hibernate?
>> For those tasks you mentioned...
>>
>> ...if other desktops don't migrate like Xfce, then something like:
>>
>> Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
>> support in session and power managers),
>> OR c) switching to command line pm-* utilities directly from pm-utils
>>
>> ...might be inevitable
>>
>> And if Linux kernel does changes that break pm-utils, which haven't had
>> a single commit since 2010
>> in upstream repository:
>>
>> Switching to a) systemd, OR, b) wait, no other possibilities
>>
>> Yes, that's really how poor the situation is, and don't shoot me, I'm
>> only the messenger :-)
> Thanks Samuli, I don't shoot people, especially when they try to help me!  :-)
>
> I use enlightenment on most machines and KDE on a couple of desktops, so I 
> guess these would be the only two desktops that may be an issue for me.  
> However, I had forgotten about the pm-* commands.  I just tried:
>
> pm-is-supported --suspend-hybrid
>
> and didn't get anything ... what am I missing?
>

null ssuominen # pm-is-supported --suspend
null ssuominen # echo $?
0
null ssuominen # pm-is-supported --hibernate
null ssuominen # echo $?
0
null ssuominen # pm-is-supported --suspend-hybrid
null ssuominen # echo $?
0

see `man pm-is-supported`, this particular command is silent, and only
returns
return codes, and 0 means it succeeded

- Samuli

Re: [gentoo-user] Re: Systemd upower

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2024 bytes --]

On Thursday 05 Jun 2014 10:08:53 Samuli Suominen wrote:
> On 05/06/14 12:03, Mick wrote:
> > On Thursday 05 Jun 2014 08:25:30 Samuli Suominen wrote:
> >> On 05/06/14 08:23, Mick wrote:
> >>> Are you saying that as things stand it is a matter of time before a
> >>> gentoo user will have to switch from openrc to systemd, if they
> >>> want/need to continue using sleep and hibernate?
> >> 
> >> For those tasks you mentioned...
> >> 
> >> ...if other desktops don't migrate like Xfce, then something like:
> >> 
> >> Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
> >> support in session and power managers),
> >> OR c) switching to command line pm-* utilities directly from pm-utils
> >> 
> >> ...might be inevitable
> >> 
> >> And if Linux kernel does changes that break pm-utils, which haven't had
> >> a single commit since 2010
> >> in upstream repository:
> >> 
> >> Switching to a) systemd, OR, b) wait, no other possibilities
> >> 
> >> Yes, that's really how poor the situation is, and don't shoot me, I'm
> >> only the messenger :-)
> > 
> > Thanks Samuli, I don't shoot people, especially when they try to help me!
> >  :-)
> > 
> > I use enlightenment on most machines and KDE on a couple of desktops, so
> > I guess these would be the only two desktops that may be an issue for
> > me. However, I had forgotten about the pm-* commands.  I just tried:
> > 
> > pm-is-supported --suspend-hybrid
> > 
> > and didn't get anything ... what am I missing?
> 
> null ssuominen # pm-is-supported --suspend
> null ssuominen # echo $?
> 0
> null ssuominen # pm-is-supported --hibernate
> null ssuominen # echo $?
> 0
> null ssuominen # pm-is-supported --suspend-hybrid
> null ssuominen # echo $?
> 0
> 
> see `man pm-is-supported`, this particular command is silent, and only
> returns
> return codes, and 0 means it succeeded

Yes, I had seen the man page and was expecting a return code, your echo string 
worked.  Thank you.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: Systemd upower

[Tom Wijsman]

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

On Thu, 5 Jun 2014 06:23:38 +0100
Mick <michaelkintzios@gmail.com> wrote:

> Are you saying that as things stand it is a matter of time before a
> gentoo user will have to switch from openrc to systemd, if they
> want/need to continue using sleep and hibernate?

For them to have support for sleep and hibernate, someone needs to
develop / maintain it in order to adapt to kernel API changes; as long
as the only one doing this is systemd, you'll work towards only it
being supported there in the future.

In other words, if people want to see this be continued in other places
than systemd; they need to either be verbal enough to convince someone
to do the work, or do the work involved themselves.

There are easily at least 100 users interested in further support.

So, if some developers and/or users can find the time, will and
interest to do so the cost to implement it; it will certainly be worth
to do for the benefit of making a ton of users happy in the future.

TL;DR: A simple equation: If someone stops development upstream,
someone else needs to start developing to keep that work{,ing}.

-- 
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-user] Re: Systemd upower

[Samuli Suominen]

On 05/06/14 13:47, Tom Wijsman wrote:
> On Thu, 5 Jun 2014 06:23:38 +0100
> Mick <michaelkintzios@gmail.com> wrote:
>
>> Are you saying that as things stand it is a matter of time before a
>> gentoo user will have to switch from openrc to systemd, if they
>> want/need to continue using sleep and hibernate?
> For them to have support for sleep and hibernate, someone needs to
> develop / maintain it in order to adapt to kernel API changes; as long
> as the only one doing this is systemd, you'll work towards only it
> being supported there in the future.

Correct, and to name an example, pm-utils is still using the old
wireless stack and
'wireless-utils' instead of 'iw'
As in, pm-utils is using kernel options that are marked as DEPRECATED in the
menuconfig, and DEPRECATED means they are going away at some point
So it won't be long the package is broken for every machine that has
wireless
card
I'm sure there are multiple other examples available, but this one pops
up to
mind immediately

Re: [gentoo-user] Re: Systemd upower

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1303 bytes --]

On Thursday 05 Jun 2014 12:26:09 Samuli Suominen wrote:
> On 05/06/14 13:47, Tom Wijsman wrote:
> > On Thu, 5 Jun 2014 06:23:38 +0100
> > 
> > Mick <michaelkintzios@gmail.com> wrote:
> >> Are you saying that as things stand it is a matter of time before a
> >> gentoo user will have to switch from openrc to systemd, if they
> >> want/need to continue using sleep and hibernate?
> > 
> > For them to have support for sleep and hibernate, someone needs to
> > develop / maintain it in order to adapt to kernel API changes; as long
> > as the only one doing this is systemd, you'll work towards only it
> > being supported there in the future.
> 
> Correct, and to name an example, pm-utils is still using the old
> wireless stack and
> 'wireless-utils' instead of 'iw'
> As in, pm-utils is using kernel options that are marked as DEPRECATED in
> the menuconfig, and DEPRECATED means they are going away at some point So
> it won't be long the package is broken for every machine that has wireless
> card
> I'm sure there are multiple other examples available, but this one pops
> up to
> mind immediately

Fair enough, I've keyworded sys-power/upower-0.99.0 for now on one machine and 
it seems to work fine, without imposing systemd at the moment.  :-)

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: Systemd upower

[Peter Humphrey]

On Thursday 05 June 2014 13:58:45 Mick wrote:

> .., I've keyworded sys-power/upower-0.99.0 for now on one machine
> and it seems to work fine, without imposing systemd at the moment.  :-)

I bet you have quite a lot of systemd components lurking in the background 
though, ready to take over the world the next time you aren't looking :-)

-- 
Regards
Peter

Re: [gentoo-user] Re: Systemd upower

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 699 bytes --]

On Friday 06 Jun 2014 00:15:02 Peter Humphrey wrote:
> On Thursday 05 June 2014 13:58:45 Mick wrote:
> > .., I've keyworded sys-power/upower-0.99.0 for now on one machine
> > and it seems to work fine, without imposing systemd at the moment.  :-)
> 
> I bet you have quite a lot of systemd components lurking in the background
> though, ready to take over the world the next time you aren't looking :-)

Ha! I can already see this one:

  338 ?        Ss     0:00 /lib/systemd/systemd-udevd --daemon

I have set USE="-systemd", but if/when Gentoo migrates to systemd as the 
default startup I will probably have to remove it and then learn how to use 
systemd.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: Systemd upower

[Rich Freeman]

On Fri, Jun 6, 2014 at 1:46 AM, Mick <michaelkintzios@gmail.com> wrote:
> On Friday 06 Jun 2014 00:15:02 Peter Humphrey wrote:
>>
>> I bet you have quite a lot of systemd components lurking in the background
>> though, ready to take over the world the next time you aren't looking :-)
>
> Ha! I can already see this one:
>
>   338 ?        Ss     0:00 /lib/systemd/systemd-udevd --daemon
>
> I have set USE="-systemd", but if/when Gentoo migrates to systemd as the
> default startup I will probably have to remove it and then learn how to use
> systemd.

That would be udev.  It has been around long before systemd, and you
must have missed the huge flamewar when they renamed it to
systemd-udevd.  Maybe we'll see "java" renamed to
"java-by-oracle-with-ask-toolbar" next.  :)

If you ever migrate to systemd you really just need to set USE=systemd
and install systemd.  Portage will swap out your udev in the process,
though nothing there will really change as systemd and udev install
the same udev components.  There is a guide for installing systemd
that you should follow which gets into all the details.

Rich

Re: [gentoo-user] Re: Systemd upower

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1141 bytes --]

On Friday 06 Jun 2014 12:18:09 Rich Freeman wrote:

> That would be udev.  It has been around long before systemd, and you
> must have missed the huge flamewar when they renamed it to
> systemd-udevd.  Maybe we'll see "java" renamed to
> "java-by-oracle-with-ask-toolbar" next.  :)

TBH I wouldn't be surprised.  At least java offers a choice of avoiding it.  
;-)


> If you ever migrate to systemd you really just need to set USE=systemd
> and install systemd.  Portage will swap out your udev in the process,
> though nothing there will really change as systemd and udev install
> the same udev components.  There is a guide for installing systemd
> that you should follow which gets into all the details.

I didn't miss the flamewar.  Actually I recall joining in the fun and posting 
the odd message about systemd.  I know that I could use eudev or systemd-udev 
(or even mdev as kindly shared in this list by Walter).

I am mostly happy with openrc and therefore have no reason to move to the 
systemd monoculture, unless gentoo falls in line with Debian et al. and leaves 
me no choice.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: Systemd upower

[Rich Freeman]

On Fri, Jun 6, 2014 at 3:13 PM, Mick <michaelkintzios@gmail.com> wrote:
>
> I am mostly happy with openrc and therefore have no reason to move to the
> systemd monoculture, unless gentoo falls in line with Debian et al. and leaves
> me no choice.
>

I don't really see that happening anytime soon - it will be more
likely to become an issue for the more complex desktop environments
(Gnome is already going this way - KDE may very well go this way
later).  Historically they're the first packages to require things
like HAL, udev, dbus, pulseaudio, etc (and on Gentoo the maintainers
tend to do a good job of minimizing dependencies).

I think many will switch to systemd anyway, simply because that is the
way the wind is blowing and it does have some benefits depending on
your situation (but so do a number of other configurations).  I tend
to use it by default on new installs, and anytime I find myself
tweaking my monit rules I keep bumping up migrating entirely to
systemd a little higher on my to-do list.

Rich

Re: [gentoo-user] Systemd upower

[Silvio Siefke]

On Tue, 3 Jun 2014 09:29:35 -0500 Canek Peláez Valdés
<caneko@gmail.com> wrote:

> If I understood correctly, you need to:
> 
> emerge -C sys-power/upower
> emerge -1v sys-power/upower-pm-utils
> 
> and then update world as usual.

Yes is correct, i has find out after read ebuilds from the packages which
need upower.

Thanks for help & Nice Day
Silvio

Re: [gentoo-user] Systemd upower

[Alan Mackenzie]

On Tue, Jun 03, 2014 at 05:11:32PM +0200, Silvio Siefke wrote:
> On Tue, 3 Jun 2014 09:29:35 -0500 Canek Peláez Valdés
> <caneko@gmail.com> wrote:

> > If I understood correctly, you need to:

> > emerge -C sys-power/upower
> > emerge -1v sys-power/upower-pm-utils

> > and then update world as usual.

> Yes is correct, i has find out after read ebuilds from the packages which
> need upower.

I do this:

    emerge --unmerge upower
    emerge -1vp sys-power/upower-pm-utils

, and I still get portage threatening to merge that other init system:

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

    Calculating dependencies... done!
    [ebuild  N     ] dev-python/lxml-3.3.5  USE="threads -beautifulsoup3 -doc -examples" PYTHON_TARGETS="python2_7 python3_3 -python3_2 (-python3_4)" 3,387 kB
    [ebuild  N     ] sys-apps/systemd-212-r5:0/2  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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" 2,659 kB
    [ebuild  N     ] sys-apps/gentoo-systemd-integration-4  52 kB
    [ebuild  N     ] virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB
    [ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios" 416 kB
    [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)

    Total: 5 packages (5 new), Size of downloads: 6,513 kB
    Conflict: 2 blocks (2 unsatisfied)

Would somebody please help me sort this out.  What am I doing wrong?
Where is systemd coming from?  I look in upower-pm-utils-0.9.23.ebuild,
and the only reference to systemd seems to be right at the beginning:

    EAPI=5
    inherit eutils systemd

(, plus a couple of inconsequential references near the end.)  I'm not
quite sure exactly what "inherit" means here, but the FM (man (5) ebuild)
says:

    Inherit  is  portage's  maintenance  of  extra  classes of functions that
    are external to ebuilds and provided as inheritable capabilities and
    data. They define functions and set data types as drop-in replacements,
    expanded, and simplified routines for extremely common tasks to
    streamline the build process. Call to inherit cannot depend on conditions
    which can vary in given ebuild.  Specification  of the  eclasses contains
    only their name and not the .eclass extension.  Also note that the
    inherit statement must come before other variable declarations unless
    these variables are used in global scope of eclasses.

, which, being vague, leaves me still unsure what "inherit" means.  ;-(
Is there any documentation anywhere of what "inherit" actually DOES?

What am I doing wrong?

> Thanks for help & Nice Day
> Silvio

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Systemd upower

[Rick "Zero_Chaos" Farina]

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

On 06/09/2014 11:34 AM, Alan Mackenzie wrote:
> On Tue, Jun 03, 2014 at 05:11:32PM +0200, Silvio Siefke wrote:
>> On Tue, 3 Jun 2014 09:29:35 -0500 Canek Peláez Valdés
>> <caneko@gmail.com> wrote:
> 
>>> If I understood correctly, you need to:
> 
>>> emerge -C sys-power/upower
>>> emerge -1v sys-power/upower-pm-utils
> 
>>> and then update world as usual.
> 
>> Yes is correct, i has find out after read ebuilds from the packages which
>> need upower.
> 
> I do this:
> 
>     emerge --unmerge upower
>     emerge -1vp sys-power/upower-pm-utils
> 
> , and I still get portage threatening to merge that other init system:
> 
>     These are the packages that would be merged, in order:
> 
>     Calculating dependencies... done!
>     [ebuild  N     ] dev-python/lxml-3.3.5  USE="threads -beautifulsoup3 -doc -examples" PYTHON_TARGETS="python2_7 python3_3 -python3_2 (-python3_4)" 3,387 kB
>     [ebuild  N     ] sys-apps/systemd-212-r5:0/2  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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" 2,659 kB
>     [ebuild  N     ] sys-apps/gentoo-systemd-integration-4  52 kB
>     [ebuild  N     ] virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB
>     [ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios" 416 kB
>     [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)
> 
>     Total: 5 packages (5 new), Size of downloads: 6,513 kB
>     Conflict: 2 blocks (2 unsatisfied)

It would be helpful to build with --tree so we can get some idea of what
is depending on systemd.
> 
> Would somebody please help me sort this out.  What am I doing wrong?
> Where is systemd coming from?  I look in upower-pm-utils-0.9.23.ebuild,
> and the only reference to systemd seems to be right at the beginning:
> 
>     EAPI=5
>     inherit eutils systemd

This is pulling in an eclass to use it's code in the ebuild.  You can
see them in /usr/portage/eclass/*.eclass

Thanks,
Zero
> 
> (, plus a couple of inconsequential references near the end.)  I'm not
> quite sure exactly what "inherit" means here, but the FM (man (5) ebuild)
> says:
> 
>     Inherit  is  portage's  maintenance  of  extra  classes of functions that
>     are external to ebuilds and provided as inheritable capabilities and
>     data. They define functions and set data types as drop-in replacements,
>     expanded, and simplified routines for extremely common tasks to
>     streamline the build process. Call to inherit cannot depend on conditions
>     which can vary in given ebuild.  Specification  of the  eclasses contains
>     only their name and not the .eclass extension.  Also note that the
>     inherit statement must come before other variable declarations unless
>     these variables are used in global scope of eclasses.
> 
> , which, being vague, leaves me still unsure what "inherit" means.  ;-(
> Is there any documentation anywhere of what "inherit" actually DOES?
> 
> What am I doing wrong?
> 
>> Thanks for help & Nice Day
>> Silvio
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTld5hAAoJEKXdFCfdEflKeOAQAIcjAiB4F8B8j79Nfe0OPdV6
S2s3k1gjTomWzBEp5HMmVUEwzNkdOxoKE/1nOg+joodfTRuDb3KqzmD90ExoQbyU
goU9Fs80RjkJgNorh3Qv5M84QrtOmtUyny0lBb4n6yzpaJCjjSrXoWhknE8lntvu
U/0KhqeDLmLpPtoSYy/dxaLNxqbPUvIPkIwmumlRWzHrxOhfWiXPiFNzZ1U2ZEwi
BwK2+rO00RAcsN00w4JIUimtJhhCNE4pjIUrErJXGdBRmB7zn4JTaBsfS0K6VyP3
8GPWpBNb+pAdeGz+sKfwvarH+/g1FvK6WY6SPw/d7jdO673IOLXgacY9MyL7IfrW
7olBIq8LFs3B/oC2btDu96RcEGKJ5ghiTiLBbnRV9NezbPxRN9XX5iPnDMqFv/o2
+xFKQkeGtDDAu9BaBHg09cQZOdZi8XoqquzIJNvqqqFUMimk43fLChX1/itc28P6
q6Kj2VV8vIE6HeSmN9KAG/5XuYEvZkDGbuS92SJ4L7n7DvK1IXgmM1cKJQku0C7L
VSM5GLYhKw0G0k8wRaJO/h32N7yGLCuaxiJ9kg2PpipSSDhPYDsGv+58ulAsS27a
kcDjP44lL8TRt9bHAVcNr45R5GDvh28TLF6I8K8nvwAM+77hSglzlEKS8EsYVxDF
PKpH/jfaqC9GzaweE0hr
=QIFF
-----END PGP SIGNATURE-----

Re: [gentoo-user] Systemd upower

[Alan Mackenzie]

Hello, Rick, thanks for the reply.

On Mon, Jun 09, 2014 at 12:18:41PM -0400, Rick "Zero_Chaos" Farina wrote:
> On 06/09/2014 11:34 AM, Alan Mackenzie wrote:

> > I do this:

> >     emerge --unmerge upower
> >     emerge -1vp sys-power/upower-pm-utils

> > , and I still get portage threatening to merge that other init system:

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

> >     Calculating dependencies... done!
> >     [ebuild  N     ] dev-python/lxml-3.3.5  USE="threads -beautifulsoup3 -doc -examples" PYTHON_TARGETS="python2_7 python3_3 -python3_2 (-python3_4)" 3,387 kB
> >     [ebuild  N     ] sys-apps/systemd-212-r5:0/2  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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" 2,659 kB
> >     [ebuild  N     ] sys-apps/gentoo-systemd-integration-4  52 kB
> >     [ebuild  N     ] virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB
> >     [ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios" 416 kB
> >     [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)

> >     Total: 5 packages (5 new), Size of downloads: 6,513 kB
> >     Conflict: 2 blocks (2 unsatisfied)

> It would be helpful to build with --tree so we can get some idea of what
> is depending on systemd.

OK.  emerge -1vpt sys-power/upower-pm-utils gives me:

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

    Calculating dependencies  ... done!
    [ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios" 416 kB
    [ebuild  N     ]  virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB
    [nomerge       ] virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)"
    [nomerge       ]  sys-apps/systemd-212-r5:0/2  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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  52 kB
    [ebuild  N     ]    sys-apps/systemd-212-r5:0/2  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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" 2,659 kB
    [ebuild  N     ]     dev-python/lxml-3.3.5  USE="threads -beautifulsoup3 -doc -examples" PYTHON_TARGETS="python2_7 python3_3 -python3_2 (-python3_4)" 3,387 kB
    [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-208)
    [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)

    Total: 5 packages (5 new), Size of downloads: 6,513 kB
    Conflict: 2 blocks (2 unsatisfied)

.  Taking a hint from the emerge man page, and adding --update, I get:

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

    Calculating dependencies  ... done!
    [ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios" 416 kB
    [ebuild  N     ]  virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB
    [ebuild     U  ]   sys-fs/udev-212-r1 [208] USE="acl firmware-loader gudev introspection kmod -doc (-selinux) -static-libs (-openrc%*)" ABI_X86="(64) (-32) (-x32)" 2,660 kB
    [ebuild     U  ]    sys-apps/hwids-20140317 [20130915.1] USE="udev" 1,585 kB
    [ebuild     U  ]    sys-apps/kmod-17 [15] USE="python%* tools zlib -debug -doc -lzma -static-libs (-openrc%*)" PYTHON_TARGETS="python2_7%* python3_3%* -python3_2% (-python3_4)" 1,450 kB

    Total: 5 packages (3 upgrades, 2 new), Size of downloads: 6,110 kB

, which seems like what I wanted in the first place.  

Then again, I call

   emerge -1vpuND --color y --tree sys-power/upower-pm-utils 2>&1 | less -F

, things go pear shaped again, with:

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

    Calculating dependencies  .... ............. .. .... .............. .... done!

    !!! Multiple package instances within a single package slot have been pulled
    !!! into the dependency graph, resulting in a slot conflict:

    dev-lang/perl:0

      (dev-lang/perl-5.16.3::gentoo, ebuild scheduled for merge) pulled in by
        >=dev-lang/perl-5.16 required by (dev-perl/XML-Parser-2.410.0::gentoo, installed)

      (dev-lang/perl-5.12.4-r1::gentoo, installed) pulled in by
        dev-lang/perl:0/0= required by (net-print/cups-filters-1.0.53::gentoo, installed)

    app-text/poppler:0

      (app-text/poppler-0.24.3::gentoo, installed) pulled in by
        app-text/poppler:0/43=[cxx,jpeg,lcms,tiff,xpdf-headers(+)] required by (net-print/cups-filters-1.0.53::gentoo, installed)

      (app-text/poppler-0.26.1::gentoo, ebuild scheduled for merge) pulled in by
        (no parents that aren't satisfied by other packages in this slot)


What the heck is going on, when a package management system can't even
make a decision on which version of perl to use, and stick to that
decision?  And it can only be described as a bug, that the gobbledegook
"(no parents that aren't satisfied by other packages in this slot)"
passes for a supposedly informative message.

Anyhow, thanks indeed for the help.  Maybe, someday in the distant
future, I'll succeed in updating my Gentoo system after all.

Have a great evening!

> Thanks,
> Zero

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Systemd upower

[Tom Wijsman]

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

On Mon, 9 Jun 2014 18:43:04 +0000
Alan Mackenzie <acm@muc.de> wrote:

> Hello, Rick, thanks for the reply.
> 
> [... cut all the emerge output, quotes and text in between ...]
> 
> What the heck is going on, when a package management system can't even
> make a decision on which version of perl to use, and stick to that
> decision?  And it can only be described as a bug, that the
> gobbledegook "(no parents that aren't satisfied by other packages in
> this slot)" passes for a supposedly informative message.
> 
> Anyhow, thanks indeed for the help.  Maybe, someday in the distant
> future, I'll succeed in updating my Gentoo system after all.

To start with, please avoid using -p (--pretend); sometimes emerge will
continue regardless of what is displayed, which can help you forward.
Though, that still might imply that you need to resolve that output.

A very first thing you'll notice is that the Perl conflict seems to
suggest that there is an old Perl version installed and a new Perl
version scheduled to be merged.

When you do a merge of an individual package, it won't consider the
reverse dependencies of Perl and therefore it will result in a conflict
instead of upgrading the reverse dependencies of Perl.

A solution to this is to upgrade your entire system (@world) such that
your entire system is in a consistent and upgraded state; however, this
only is a way forward as long as it doesn't bring up a conflict.

So ... In order to proceed here, you have to unmerge sys-power/upower
(which you've already done) and mask sys-power/upower as well as
sys-apps/systemd (yet to do), then an `emerge -auvDNt @world` should
help you forward; if not, its output can help you bring it forward.

If there is a mention about backtracking, try --backtrack=9001 or so;
also, if it still tries to bring in sys-power/upower then you might
have an overlay that attempts to do this (sync and/or contact author).

As a result of the unmerge and mask, it picks upower-pm-utils for you.

> Have a great evening!

You too.

-- 
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-user] Systemd upower

[Alexander Kapshuk]

On 06/09/2014 06:34 PM, Alan Mackenzie wrote:
> On Tue, Jun 03, 2014 at 05:11:32PM +0200, Silvio Siefke wrote:
>> On Tue, 3 Jun 2014 09:29:35 -0500 Canek Peláez Valdés
>> <caneko@gmail.com> wrote:
>>> If I understood correctly, you need to:
>>> emerge -C sys-power/upower
>>> emerge -1v sys-power/upower-pm-utils
>>> and then update world as usual.
>> Yes is correct, i has find out after read ebuilds from the packages which
>> need upower.
> I do this:
>
>     emerge --unmerge upower
>     emerge -1vp sys-power/upower-pm-utils
>
> , and I still get portage threatening to merge that other init system:
>
>     These are the packages that would be merged, in order:
>
>     Calculating dependencies... done!
>     [ebuild  N     ] dev-python/lxml-3.3.5  USE="threads -beautifulsoup3 -doc -examples" PYTHON_TARGETS="python2_7 python3_3 -python3_2 (-python3_4)" 3,387 kB
>     [ebuild  N     ] sys-apps/systemd-212-r5:0/2  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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" 2,659 kB
>     [ebuild  N     ] sys-apps/gentoo-systemd-integration-4  52 kB
>     [ebuild  N     ] virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB
>     [ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios" 416 kB
>     [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)
>
>     Total: 5 packages (5 new), Size of downloads: 6,513 kB
>     Conflict: 2 blocks (2 unsatisfied)
>
> Would somebody please help me sort this out.  What am I doing wrong?
> Where is systemd coming from?  I look in upower-pm-utils-0.9.23.ebuild,
> and the only reference to systemd seems to be right at the beginning:
>
>     EAPI=5
>     inherit eutils systemd
>
> (, plus a couple of inconsequential references near the end.)  I'm not
> quite sure exactly what "inherit" means here, but the FM (man (5) ebuild)
> says:
>
>     Inherit  is  portage's  maintenance  of  extra  classes of functions that
>     are external to ebuilds and provided as inheritable capabilities and
>     data. They define functions and set data types as drop-in replacements,
>     expanded, and simplified routines for extremely common tasks to
>     streamline the build process. Call to inherit cannot depend on conditions
>     which can vary in given ebuild.  Specification  of the  eclasses contains
>     only their name and not the .eclass extension.  Also note that the
>     inherit statement must come before other variable declarations unless
>     these variables are used in global scope of eclasses.
>
> , which, being vague, leaves me still unsure what "inherit" means.  ;-(
> Is there any documentation anywhere of what "inherit" actually DOES?
>
> What am I doing wrong?
>
>> Thanks for help & Nice Day
>> Silvio
Can you please verify that:
(1). sys-power/upower is gone by running this:
equery l (that's a lower case 'l') sys-power/upower
(2). sys-power/upower-pm-utils has been installed:
equery l sys-power/upower-pm-utils
(3). the 'p' flag does not actually install anything:
emerge(1)
--pretend (-p)
              Instead  of  actually  performing the merge, simply
display what
              *would* have been installed if --pretend  weren't  used.
So if step 2 results in the negative, you may want to run the command
line without the 'p' flag, like so:
emerge -av1 sys-power/upower-pm-utils

Re: [gentoo-user] Systemd upower

[Alan McKinnon]

On 03/06/2014 16:29, Canek Peláez Valdés wrote:
> On Tue, Jun 3, 2014 at 9:14 AM, Silvio Siefke <siefke_listen@web.de> wrote:
>> Hello,
>>
>> mean this i must install now systemd? What can do when i not want systemd.
>> The system what i have is good, i want not change to systemd.
>>
>> [ebuild     U ~] sys-devel/gettext-0.19 [0.18.3.2] USE="acl cxx ncurses nls openmp -cvs -doc -emacs -git -java -static-libs" 16,221 kB
>> [ebuild   R    ] dev-libs/glib-2.38.2-r1:2  USE="(mime%*) -debug (-fam) (-selinux) -static-libs -systemtap {-test} -utils -xattr" PYTHON_TARGETS="python2_7 (-python2_6)" 0 kB
>> [ebuild  N     ] sys-apps/systemd-208-r3:0/1  USE="acl filecaps firmware-loader gudev introspection kmod pam policykit python tcpd -audit -cryptsetup -doc -gcrypt -http -lzma -qrcode (-selinux) {-test} -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7 -python3_2 -python3_3" PYTHON_TARGETS="python2_7 python3_3 -python3_2" 2,335 kB
>> [ebuild  N     ] sys-apps/gentoo-systemd-integration-2  51 kB
>> [ebuild  N     ] sys-power/upower-0.9.23-r3  USE="introspection -doc -ios" 0 kB
>> [blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-208-r3)
>> [blocks B      ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/udev-212-r1)
>> [blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-212-r1)
>>
> 
> If I understood correctly, you need to:
> 
> emerge -C sys-power/upower
> emerge -1v sys-power/upower-pm-utils
> 
> and then update world as usual.
> 
> The changes in upower does not make systemd mandatory, but you need to
> switch from upower (which now has systemd as a hard dependency) to
> upower-pm-utils (which depends on the unmaintined pm-utils).
> 
> Regards.
> 



That is correct. There is a vocal debate going on in -dev right now
about this and a proposed news item is in the works. here's the current
proposed item which might change but at least explains what is going on:

Do note that emerging upower-pm-utils (what you should do is you want to
keep things the way they were) needs upower to be unmerged first. That
part isn't mentioned in the news item, but portage lets you know real
quick anyway. i.e. upower-pm-utils replaces current upower to restore
old upower feature set



==========
 UPower discontinued hibernate and suspend support in favor of systemd.
Because of this, we have created a compability package at
sys-power/upower-pm-utils which will give you the old UPower with
sys-power/pm-utils support back.
Some desktops have integrated the sys-power/pm-utils support directly
to their code, like Xfce, and as a result, they work also with the new
UPower as expected.

All non-systemd users are recommended to choose between:

# emerge --noreplace 'sys-power/upower-pm-utils'

or

# emerge --noreplace '>=sys-power/upower-0.99.0'

However, all systemd users are recommended to stay with sys-power/upower.
===========

-- 
Alan McKinnon
alan.mckinnon@gmail.com