Re: [gentoo-user] Systemd upower
On 06/04/2014 11:11 AM, Canek Peláez Valdés wrote:
On Wed, Jun 4, 2014 at 5:28 AM, Greg Woodbury redwo...@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
Re: [gentoo-user] Re: Systemd upower
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.mckin...@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
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Systemd upower
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] Systemd upower
On Wed, 04 Jun 2014 19:15:22 -0400 Dutch Ingraham s...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On Thu, 5 Jun 2014 00:27:28 +0100 Neil Bothwick n...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] Re: Systemd upower
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Systemd upower
On Thu, 05 Jun 2014 02:34:49 -0400 Greg Woodbury redwo...@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;
Re: [gentoo-user] Re: Systemd upower
On Thu, 5 Jun 2014 06:23:38 +0100
Mick michaelkintz...@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 : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-user] Systemd upower
On Thu, Jun 5, 2014 at 2:34 AM, Greg Woodbury redwo...@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
On 05/06/14 14:11, Rich Freeman wrote: On Thu, Jun 5, 2014 at 2:34 AM, Greg Woodbury redwo...@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] Re: Systemd upower
On 05/06/14 13:47, Tom Wijsman wrote: On Thu, 5 Jun 2014 06:23:38 +0100 Mick michaelkintz...@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] Systemd upower
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
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
On 06/05/2014 05:40 AM, Tom Wijsman wrote:
On Wed, 04 Jun 2014 19:15:22 -0400
Dutch Ingraham s...@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
Re: [gentoo-user] Systemd upower
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
Re: [gentoo-user] Systemd upower
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
On Thu, 05 Jun 2014 08:11:31 -0400 Dutch Ingraham s...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] Re: Systemd upower
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 michaelkintz...@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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Systemd upower
Sent:Thursday, June 05, 2014 at 8:18 AM From:Samuli Suominen ssuomi...@gentoo.org To:gentoo-user@lists.gentoo.org Subject:Re: [gentoo-user] Systemd upower 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 doesnt have write access to ::mate-overlay, its completely unofficial Gentoo developers are just as much users as you are for ::mate-overlay Enough said - Samuli Sorry, but this isnt 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 - Cd 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 its only end of the output, so it wouldnt tell the necessary information required for solving it anyway. Remove anykind of Xfce masks and post complete output, and dont 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 Ive removed the XFCE masks. Note that mate-power-manager is masked. I see you didnt follow the recommendation of getting rid of the ::mate-overlay because Im still seeing mate-base/mate::mate-overlay and more in the output I dont know how we could possible get forward if you dont follow-up on the already suggested instructions, no wonder youve 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. Samuli - thanks for your response. I had already done the emerge -C mate-power-manager and mate-session. I did not uninstall the overlay because equery depends upower showed no remaining dependencies. I will give it a go and try and convert from the overlay to the portage repository.
Re: [gentoo-user] Systemd upower
Sent:Thursday, June 05, 2014 at 8:31 AM From:Tom Wijsman tom...@gentoo.org To:gentoo-user@lists.gentoo.org Subject:Re: [gentoo-user] Systemd upower On Thu, 05 Jun 2014 08:11:31 -0400 Dutch Ingraham s...@gmx.us wrote: [nomerge ] mate-base/mate-1.6.0::mate-overlay You are still using the MATE overlay, which wasnt 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 Dont 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 doesnt 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, thats 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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D Thanks, Tom. I have actually looked, ever since you began your work on the portage version of MATE, for some guidance on how to transfer from the overlay to the general portage repository, but, and maybe I just didnt look hard enough, I never found the proper guidance for making that switch. If you could point me to the proper command set to make the switch, Id appreciate it.
Re: [gentoo-user] Systemd upower
On Thu, 5 Jun 2014 16:15:11 +0200 Dutch Ingraham s...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On Thursday 05 Jun 2014 15:15:11 Dutch Ingraham wrote: htmlhead/headbodydiv style=font-family: Verdana;font-size: 12.0px;divnbsp; divnbsp; div name=quoted-contentnbsp;/div div name=quoted-contentIf 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 signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: quick installs on older/embedded hardware
Walter Dnes waltdnes at waltdnes.org writes: You may be interested in buildroot http://buildroot.net/ and http://buildroot.net/about.html It's nominally aimed at cross-compiling for embedded systems, but it looks like it handles just about everything. I'm not a developer, so I don't know if this is what you're looking for, but it sounds interesting. Buildroot is great for embedded system and cross compiling. It more for after you get a basic system up, imho. What I need is a basic, minimal image that I can dd over to a hard drive, and build out whatever gentoo I need. In fact I may need several images: (1) basic image to build up a amd64 workstation or server (2) a basic image to build up a 586 (or greater) system from (3) a basic image to build up x86 embedded systems from (4) a basic image to build up 32 bit arm systems from (5) a basic image to build up 64 bit arm images The idea would be to dd these images to a blank HD and install the basic gentoo system, then customize from there. This would avoid hours and hours of custom (handbook) derived installation hours for new system that are only slightly different and are all gentoo systems, as the base system would have the file system inside the image, the make.conf with minimal necessary files, profile etc etc. Just the minimal necessary to get the kernel+system up. The basic system would change (be updated with new kernel) from time to time, but only every few months. emerge --sync would bring the systems current. Them, according to what I want to build, there would be a guide sheet that details the flags necessary and the key packages (software-ebuild) config file edits etc to realize the final test box(gentoo) system. I'm thinking out loud here on the list for folks to chime in and refine the idea. Starting with (1) and (2) only above would get me started. I'm quite certain this is going to be a work in progress. maybe a custom cd/dvd via catalyst for each of the (5) categories ? I do want as much as possible (practical and reasonable to support) from the handbook into the boot image. I think most of what is therein before entering chroot is a reasonable first draft idea? And yes this would mean all the decisions like file system type, partitions, fstab, mtab etc would be made ahead of time, generically for one size works reasonable well with all setups. It has been pointed out to me that lilo works best for the booting as there are no issues wtih embedded builds or the various C libraries one can use: glibc, uClibc, BSDs, bionic, musl. I'll probable start with stable and one I have (1) and (2) working move to a hardened version (at least the kernel and tool chain) It may not end up as clean as I like, but surely there is a way to streamline various categories of systems, as a referenced starting point? ?? James
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On Thu, Jun 05, 2014 at 12:24:22AM +0100, Neil Bothwick wrote: On Wed, 4 Jun 2014 21:59:18 +0200, Frank Steinmetzger wrote: I encrypt my home partition with LUKS and enter a passphrase during boot. But I always wanted to get decryption upon login running, especially because it would require me to enter one less password. But haven’t gotten around to that yet. Are you the only use of the computer? If so, set your display manager to auto-login, you have already authenticated yourself by unlocking the home partition. Now that’s an interesting idea I haven’t thought of yet. Thanks. My LUKS passphrase is much more secure than my ancient user password anyway *hehe*. With one notable exception. There is sometimes sensitive information in /etc, like wireless passwords. For that reason I put this stuff into /home/etc/$hostname/ (I back up my machines’ /etc on all other machines, also to have a reference if I need to know “How did I do this on $other_host?”). And then I symlink to that from the real location, i.e.: I used to do that, now I have an encrypted /, which contains the keys for any other encrypted volumes, so I still only need to enter one password. That falls into the category of using initrds which is also far down on my todo. I understand the mechanics and had played with dracut in the past, but nothing workable has come out of it yet. Nothing is illegal if one hundred businessmen decide to do it. Like stealing taglines. :-) -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. Please notify me if you did not receive this message. signature.asc Description: Digital signature
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On Thu, Jun 5, 2014 at 12:52 PM, Frank Steinmetzger war...@gmx.de wrote: Now that’s an interesting idea I haven’t thought of yet. Thanks. My LUKS passphrase is much more secure than my ancient user password anyway *hehe*. Only if it isn't the same. :) In theory neither really need be algorithmically more secure than the other, but there is more opportunity for somebody to capture your password after the system is running than while it is booting up. Rich
Re: [gentoo-user] Systemd upower
On 06/05/2014 11:40 AM, Tom Wijsman wrote: On Thu, 5 Jun 2014 16:15:11 +0200 Dutch Ingraham s...@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] Re: Systemd upower
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
[gentoo-user] OT: Mapping random numbers (PRNG)
Hi, I am experimenting with the C code of the ISAAC pseudo random number generator (http://burtleburtle.net/bob/rand/isaacafa.html). Currently the implementation creates (on my embedded linux) 32 bit hexadecimal output. From this I want to create random numbers in the range of [a-Za-z0-9] *without violating randomness* and (if possible) without throwing away bits of the output. How can I do this mathemtically (in concern of the quality of output) correct? Thank you very much in advance for any help! Best regards, mcc
Re: [gentoo-user] OT: Mapping random numbers (PRNG)
On Thu, Jun 5, 2014 at 9:56 PM, meino.cra...@gmx.de wrote:
Hi,
I am experimenting with the C code of the ISAAC pseudo random number generator
(http://burtleburtle.net/bob/rand/isaacafa.html).
Currently the implementation creates (on my embedded linux) 32 bit
hexadecimal output.
So it's a 32 bit integer.
From this I want to create random numbers in the range of [a-Za-z0-9]
*without violating randomness* and (if possible) without throwing
away bits of the output.
You mean *characters* int the range [A-Za-z0-9]?
How can I do this mathemtically (in concern of the quality of output)
correct?
The easiest thing to do would be:
---
#include time.h
#include stdio.h
#include stdlib.h
#define N (26+26+10)
static char S[] = { 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J',
'K', 'L', 'M',
'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', 'Z',
'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j',
'k', 'l', 'm',
'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
'x', 'y', 'z',
'0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
int
next_character()
{
// Use the correct call for ISAAC instead of rand()
unsigned int idx = rand() % N;
return S[idx];
}
int
main(int argc, char* argv[])
{
// Use the correct call for initializing the ISAAC seed
srand((unsigned int)time(NULL));
for (int i = 0; i 20; i++) // --std=c99
printf(%c\n, next_character());
return 0;
}
---
If the ISAAC RNG has a good distribution, then the next_character()
function will give a good distribution among the set [A-Za-z0-9].
Unless I missunderstood what you meant with create random numbers in
the range of [a-Za-z0-9].
Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México
[gentoo-user] systemd not shutting down all the way
Hi. Whenever I issue the command shutdown -h now to shutdown the system, having booted under systemd, the computer never actually shuts down. It does stop some services, but eventually just sits there -- about the last one I see is something about sound card state and that is all, it just waits there forever. How can I trouble shoot this problem? There is no gui running before I issue the shutdown command. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: Systemd upower
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 signature.asc Description: This is a digitally signed message part.
