Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Saturday, May 31, 2014 02:17:32 PM Samuli Suominen wrote: On 31/05/14 05:47, Steven J. Long wrote: On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote: On 27/05/14 08:34, Michał Górny wrote: Dnia 2014-05-26, o godz. 23:15:34 Samuli Suominen ssuomi...@gentoo.org napisał(a): UPower upstream removed sys-power/pm-utils support from 0.99 release (currently unkeyworded in tree), as in, from current git master. Don't worry. Looking at the past, I can guess this is only a temporary inconvenience. I'm pretty sure upower will be discontinued soon and replaced with systemd-powerd or something :D. That's more or less what they already did, they forced eg. xfce4-power-manager upstream to move the deleted pm-utils code from upower directly to the power manager (application) itself, likewise for xfce4-session Which means applications will now need to duplicate the pm-utils related code per application basis So I expect upower to be more or less dead for everything but systemd users, except for those upstreams that will actually follow the Xfce path and do the duplication Yet, still, small portition of the code is still 'generic', so xfce4-power-manager will still need both, upower, even 0.99, and then pm-utils, depending on the version, codepath is selected This was sort of expected, since pm-utils has been abandoned for ~5 years now at upstream, so nobody is maintaining non-systemd related power management tools anymore, and falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be necessary again, it's like going back to 90s for non-systemd users :P I can't believe I'm reading that from a distro-developer. Basically this entire thread is systemd is deprecating the existing tools, so let's dump them and half our userbase back to the 90s, isn't that a great thing? Then you misunderstood. Notice the :P as an indicator of sarcasm. I've already created sys-power/upower-pm-utils where the sys-power/pm-utils 0.9 git branch will continue to live. Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. If you need support for understanding Portage's output, try the gentoo-user mailing list. - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 7:25 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. If you need support for understanding Portage's output, try the gentoo-user mailing list. This probably could have used a news item, as the change impacts both stable and ~arch users. They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, otherwise portage is going to try to switch them from udev to systemd, since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. I posted the same on -user... Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 15:08, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? IMHO, not every singular dependency change (even blocker) needs one. For those failing to read `eix upower` or `emerge -C upower` or masking systemd, or number of other ways the blocker can be solved, the answer is in Gentoo news letter, forums, first hits in Google, /topic of #gentoo at Freenode, MLs, pretty much everywhere. But news item has been planned all along for when UPower 0.99.0 goes stable, propably GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to accumulate as news worthy. - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 15:24:22 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 15:08, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? IMHO, not every singular dependency change (even blocker) needs one. Regardless of that, most acquirements have lead to a news item. For those failing to read `eix upower` That command doesn't tell anything helpful for this blocker. or `emerge -C upower` For that you need to already know that you have to unmerge upower; it is also not going to help anything in terms of dependency calculation, except for a small amount of users that might have selected it. or masking systemd, Masking systemd has the same effect as having udev selected; so, taking this action has zero effect and results in the blocker to still be there. The output has perhaps changed a little, the idea is the same. or number of other ways the blocker can be solved, There is the problem, new Gentoo users can't solve it; that's why it's all over the place, as you've mentioned below. And some of it contains misinformation, like the gentoo-user thread you have responded to. Why do the users need to keep solving these nasty blockers? You could solve it if you use --tree --unordered-display; go through the dependency chain to check the reverse dependencies, write down what is going on and finally come to the conclusion of it all. But how are new users supposed to know all that? Why is --tree --unordered-display still not a default? In other words, why is the list of packages still flat by default? the answer is in Gentoo news letter, Hidden somewhere in the middle, assuming users read about the update. forums, As long as the activity of these topics last. first hits in Google, Nothing found when I search for things like gentoo systemd blocker. /topic of #gentoo at Freenode, MLs, pretty much everywhere. Which amounts to only a certain share of the users. But news item has been planned all along for when UPower 0.99.0 goes stable, propably GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to accumulate as news worthy. Your reply doesn't answer the posed questions; instead, it demonstrates that it costs a lot more human resources the way we do things now. Users have to figure it out the hard way, developers then have to bring out the news the hard way; just like most of the previous times. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 8:24 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 15:08, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? IMHO, not every singular dependency change (even blocker) needs one. For those failing to read `eix upower` or `emerge -C upower` or masking systemd, or number of other ways the blocker can be solved, the answer is in Gentoo news letter, forums, first hits in Google, /topic of #gentoo at Freenode, MLs, pretty much everywhere. The whole point of news is to tell people about an action they need to take before they have to take it. The output of portage doesn't really tell you what is going on. The article in GMN doesn't provide clear instructions on what needs to be done, and refers to 0.99.0 when the issue impacts 0.9.23 as well. But news item has been planned all along for when UPower 0.99.0 goes stable, propably GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to accumulate as news worthy. This has already hit stable. The dependency on systemd is present in sys-power/upower-0.9.23-r3, which was just stablized. Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:04:23 -0400 Rich Freeman ri...@gentoo.org wrote: The whole point of news is to tell people about an action they need to take before they have to take it. The output of portage doesn't really tell you what is going on. Note that I'm not against a news item in the short term; what I am suggesting with mix-ins is even a step before that, but that's something only achievable in the long term and of course not now. So, yes, please write and send a news item out as soon as possible. The article in GMN doesn't provide clear instructions on what needs to be done, and refers to 0.99.0 when the issue impacts 0.9.23 as well. Besides that, a longer title would help; currently it reads to me like X update, which means that if I don't care about X or don't know X that I'm very likely to skip it. Mentioning systemd somewhere in there, as well as transition; could help with drawing attention to it. But given a news item, this GMN entry would become less important; regardless, it can help for those that manage to skip reading the item. This has already hit stable. The dependency on systemd is present in sys-power/upower-0.9.23-r3, which was just stablized. Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; in comparison, 0.99.0 mainly wants you to run it with systemd: 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/06/14 08:08 AM, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? That's easy -- we don't have a way to do vdb updates that will split a package, only move a package. And since this isn't a package move (as the original package still exists) we can't leverage that. otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. Technically we could do this via a systemd profile too -- ie, mask new upower everywhere but systemd profiles, and in systemd profile mask upower-pm-utils. However, that doesn't get around the actual need to - --unmerge upower and emerge upower-pm-utils (or hopefully just do the latter as a soft-block will do the unmerge?) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlONzPEACgkQ2ugaI38ACPDI5AD/eEbk4156UrMNHmCPIA+xwNfe nlGC5pnZ3Zs0gu/88EAA/A9hNlNfGzhqorE+8cEz3lkTVuxxq8gv++7Ogm0zY8DU =I7Mw -END PGP SIGNATURE-
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 9:20 AM, Tom Wijsman tom...@gentoo.org wrote:
On Tue, 3 Jun 2014 09:04:23 -0400
Rich Freeman ri...@gentoo.org wrote:
This has already hit stable. The dependency on systemd is present in
sys-power/upower-0.9.23-r3, which was just stablized.
Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; in
comparison, 0.99.0 mainly wants you to run it with systemd:
From upower-0.9.23-r3.ebuild:
RDEPEND=${COMMON_DEPEND}
kernel_linux? (
app-shells/bash
=sys-apps/systemd-200
)
No use conditional there...
Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency;
I thought it had one, but maybe it is in another package I'm unaware of.
Did somebody stick the dependency in the wrong version? :)
Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 16:20, Tom Wijsman wrote: This has already hit stable. The dependency on systemd is present in sys-power/upower-0.9.23-r3, which was just stablized. Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. For example, I'm using Xfce, OpenRC, UPower 0.99.0, pm-utils, Xfce 4.11+ and I have hibernate/suspend working just fine without systemd. And UPower is for much more than hibernate/suspend, it has dozens of features, so anykind of systemd dependency on 0.99.0 wouldn't make sense 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 16:28:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 16:20, Tom Wijsman wrote: Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. Nevermind, `cvs up`-ed; heh, I don't understand how you've got to that change, I thought there only was a problem with 0.99.0? in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. Ah, right; thinking of MATE, I understand the 0.99.0 bit now. 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved Which means that the situation I am assuming right now is outdated; so, if you don't mind feel free to highlight why 0.9.23-r3 needs systemd. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:29:59 -0400 Rich Freeman ri...@gentoo.org wrote: No use conditional there... Yeah, I was a checkout behind; I'm clueless wrt the new revision bump. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 16:40, Tom Wijsman wrote: On Tue, 03 Jun 2014 16:28:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 16:20, Tom Wijsman wrote: Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. Nevermind, `cvs up`-ed; heh, I don't understand how you've got to that change, I thought there only was a problem with 0.99.0? in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. Ah, right; thinking of MATE, I understand the 0.99.0 bit now. 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved Which means that the situation I am assuming right now is outdated; so, if you don't mind feel free to highlight why 0.9.23-r3 needs systemd. To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or other To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0 because they are going away, to indicate this is the best time to make informed decision and take manual action regarding choosing which features set he/she wants, to read up upstream announcements regarding UPower, to follow-up and do what admins do - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen ssuomi...@gentoo.org wrote: To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Whatever - short of profiles/mix-ins or whatever you want to do on a big scale there isn't a simple solution to problems like this. It just isn't obvious to users who haven't read GMN that there is a simple fix. Even users who do read GMN might get confused by the version number issue, as the change impacts stable users who aren't using the version of upower mentioned in GMN. Plus, GMN isn't in-your-face like portage news. Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Jun 2014 09:26:09 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/06/14 08:08 AM, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? That's easy -- we don't have a way to do vdb updates that will split a package, only move a package. And since this isn't a package move (as the original package still exists) we can't leverage that. - From the dependency viewpoint this isn't a package split or move, it is rather an introduction of || ( A B ) alternatives in the dependency chain. In this case, the first option (A) is tried and exhausted; this complexity results in other options (B) not being thoroughly considered. If you want Portage to make a transition to alternatives, you need to get a mask in place for the first option; so, we can leverage this: 1. || ( A B ) with A masked causes Portage to install B instead; 2. || ( A-0.99 B ) with =A-0.99 masked causes a downgrade to A-2. So, what misses here is that mask; which you could put in a mix-in. (In this specific case A is upower and B is upower-pm-utils.) otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. Technically we could do this via a systemd profile too -- ie, mask new upower everywhere but systemd profiles, and in systemd profile mask upower-pm-utils. In doing so, you assume that non-systemd profiles are anti-systemd; however, that's not the case. Currently GNOME and KDE have systemd profiles; but, there are a lot of other desktop environments in the Portage tree that have support for systemd. So, this means we would have to go and create a profile for each desktop environment and within such profile yet another profile for systemd; this becomes somewhat tedious if you can cover all that in a mixin instead. You're going to need mixins at some point when it's not just systemd that is a specialization but something else as well; unless you want to create even more directories for the possible combinations: - gnome/somethingelse - gnome/systemd - gnome/systemd+somethingelse However, that doesn't get around the actual need to - --unmerge upower and emerge upower-pm-utils (or hopefully just do the latter as a soft-block will do the unmerge?) Portage does this for you if you mask upower and provide it with sufficient backtracking; so, there's no need to do this manually. More explicitly noted: An upower mask allows us to say that an upgrade should do `emerge -C upower` and `emerge upower-pm-utils`, in the case that there is || ( upower upower-pm-utils ) listed as a dependency. Unless you have selected upower on purpose; which would be a different case than the one we're discussing here, also giving different output as it'll point out that @selected brings in what (upower) has been masked. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTjdWXAAoJEPWZc8roOL/QTwAIAJeYIYpF4JIclsGY67ZHDpuM D2rY3JlCEof4iMcPGccR+lsiTWp0inRRkR5YYejPTMupD/MUqmhuxAogLcUE79m6 lBGQOmO9G4Iduvuoesa99x7UUW6Ihx9TrmoPmn++S9Bn8FrFq+52rUkRDFrlbsrP +wyrc2Dh8SQlI7Bf2r0WcloE9xb+TVXKeyJeZs9eN0afQXqtFJraoGuPYsj7yF7f JWHq26HWRBd+EM8Gyx0OHgPW4Uc7mwhabywxfh44HcjLvh5DN+4/fXbLXc6ytBvi Z5+4UMMXNEUloovKKHT45uVCJ159njFk9KW5SQhKRihaQD63USMm+sKGm0Kx0Ek= =Sugk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:53:45 -0400 Rich Freeman ri...@gentoo.org wrote: Whatever - short of profiles/mix-ins or whatever you want to do on a big scale there isn't a simple solution to problems like this. Why is the mix-in not a simple solution? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 10:05 AM, Tom Wijsman tom...@gentoo.org wrote: On Tue, 3 Jun 2014 09:53:45 -0400 Rich Freeman ri...@gentoo.org wrote: Whatever - short of profiles/mix-ins or whatever you want to do on a big scale there isn't a simple solution to problems like this. Why is the mix-in not a simple solution? It involves a tree-level change. Granted, for something like systemd it probably makes sense. However, there are always going to be dependency resolution situations where the PM won't guess the user's intent. Maybe in these cases the PM should make it more clear that there was an alternative option. Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 16:53, Rich Freeman wrote: On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen ssuomi...@gentoo.org wrote: To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes It seems we are seeing the severity of something like this diffently, to me, this belongs to normal Portage functionality, I see something like this from other packages constantly, I don't understand why this package has suddently been highlighted like this It just seems to me people are up in the arms again re: seeing word systemd, when ironically all of this hassle was *for* OpenRC users, to ensure continuity for them in sys-power/upower-pm-utils where 0.9 git branch will continue to live If I hadn't stepped up and blocked the 0.99.0 keywording when it was originally about to happen, and then figured a migration path, and then stepped up with help from pacho2 and tomwij, and migrated the tree like this, we'd have everyone on 0.99.0 and no hibernate/suspend for anyone else except systemd users So, after all the effort we've put in and prepared the tree with OpenRC users specifically in mind, if people have to take one or two manual emerge commands themselfs, I'm totally fine with that, that's what Gentoo is all about, choices, and people who complain about it, really seem like ungrateful over anything else, and I'm disappointed. I keep expecting more from our users, the handholding has lately gone overboard I hope that didn't come out wrong, and it certainly wasn't a reply directly aimed at you, it was to the thread in general (I'm still with my original plan, when 0.99.0 goes stable, there will be multiple bulletin points to document, news item will be issued) - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. And please keep such changes out of stable until proper documentation is in place (and the 30 day period has elapsed, etc.) Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 17:45, Chí-Thanh Christopher Nguyễn wrote: Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. No, it wouldn't have, because 0.99.0 is the superior version to which we are all working towards and 1 would have superceded it And 0.99.0 is for both, systemd and openrc users
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
Samuli Suominen schrieb: On 03/06/14 17:45, Chí-Thanh Christopher Nguyễn wrote: Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. No, it wouldn't have, because 0.99.0 is the superior version to which we are all working towards and 1 would have superceded it And 0.99.0 is for both, systemd and openrc users sys-power/upower-1 would not install any files and be treecleaned some months after the transition is complete. upower-1.ebuild: DEPEND=systemd? ( sys-power/upower-systemd ) !systemd? ( sys-power/upower-pm-utils ) upower-pm-utils-0.9.23.ebuild: DEPEND=!sys-power/upower-1 !sys-power/upower-systemd upower-systemd-0.9.23-r3.ebuild: DEPEND=!sys-power/upower-1 sys-apps/systemd I will attach the proposed ebuilds to bug 512252. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] RFC: news item for upower
I find this useless at this time because the work is in-progress, but in order to silence the loud minority, please review the news item. Thanks! - Samuli Title: UPower discontinued hibernate/suspend support Author: Samuli Suominen ssuomi...@gentoo.org Content-Type: text/plain Posted: 2014-06-03 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-power/upower-0.99.0 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 users are recommended to choose between: # emerge --noreplace 'sys-power/upower-pm-utils' or # emerge --noreplace '=sys-power/upower-0.99.0'
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. It requires an analysis on its own, among the kind of collecting bad non understandable output and the solution to it; then try to make up favorable output for it. After which it has to be seen if the needed information can be obtained, as well as the algorithms for that favorable output can be implemented. Somewhere in that flow we also need to have some kind of quality review cycle to see if the favorable output helps; otherwise, it could make the situation worse instead of better. Because, really, ... http://bpaste.net/raw/Pp9Iv18ehzzHKVbm4Sbe/ ... does not give away upower as a root blocker cause; even going further than that, it doesn't suggest upower-pm-utils as an alternative. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] RFC: news item for upower
On 03/06/14 18:43, Samuli Suominen wrote: I find this useless at this time because the work is in-progress, but in order to silence the loud minority, please review the news item. Thanks! - Samuli Added a line, exception for systemd users Title: UPower discontinued hibernate/suspend support Author: Samuli Suominen ssuomi...@gentoo.org Content-Type: text/plain Posted: 2014-06-03 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-power/upower-0.99.0 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.
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 16:52:30 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 3 Jun 2014 17:48:05 +0200 Tom Wijsman tom...@gentoo.org wrote: On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. That isn't the issue... Developers need to stop being clever in expressing dependencies, and start giving the package mangler explicit information about what a dependency means. Relying upon heuristics to figure out what a complicated mess of || ( ) and blockers means just leads to things intermittently going horribly wrong. Which brings me back to the mix-in suggestion, which improves input. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 16:57:12 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Samuli Suominen schrieb: And 0.99.0 is for both, systemd and openrc users sys-power/upower-1 would not install any files and be treecleaned some months after the transition is complete. upower-1.ebuild: DEPEND=systemd? ( sys-power/upower-systemd ) !systemd? ( sys-power/upower-pm-utils ) Read Samuli's comment again, please; what you suggest introduces a problem for users, like me, that have 0.99 installed regardless of whether we are using OpenRC or systemd. Besides that, there is no need for a sys-power/upower-systemd package. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 17:48:05 +0200 Tom Wijsman tom...@gentoo.org wrote: On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. That isn't the issue... Developers need to stop being clever in expressing dependencies, and start giving the package mangler explicit information about what a dependency means. Relying upon heuristics to figure out what a complicated mess of || ( ) and blockers means just leads to things intermittently going horribly wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: news item for upower
On Tue, 2014-06-03 at 18:43 +0300, Samuli Suominen wrote: I find this useless at this time because the work is in-progress, but in order to silence the loud minority, please review the news item. Thanks! - Samuli I appreciate your work on this - and you may call them the loud minority - but this could definitely have been handled better. Instead of viewing their complaints as an annoyance, view it as a learning point to possibly realize that you're affecting a lot of desktops and people's updates are suddenly stopping. I realize that this was mentioned in the GWN, but not everyone subscribes to every possible news outlet for Gentoo even if they use Gentoo, and the only one that is guaranteed to get to them is a portage checkout, which is why news items are good, especially when something like this occurs. Instead of belittling the users because they are wasting so much of your time, try to empathize with them a bit and realize that they are running into an actual issue that could have been avoided easily with this news item. That said, the news item looks good to me, and yeah it may be a bit late now since this already happened.
Re: [gentoo-dev] RFC: news item for upower
On Tue, 03 Jun 2014 18:53:26 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Title: UPower discontinued hibernate/suspend support https://wiki.gentoo.org/wiki/GLEP:42#News_Item_Headers You're going to hate me for mentioning this, but that is one character too much; 45 44 characters. Besides that, I think it would be nice if this could indicate systemd somehow. Some suggestions to brainstorm further: Title: UPower loses hibernate / suspend to systemd Title: UPower loses suspension to systemd, new fork Title: UPower's suspend in systemd or pm-utils fork (As systemd user, I'm not intending to give it a negative feeling) Author: Samuli Suominen ssuomi...@gentoo.org Content-Type: text/plain Posted: 2014-06-03 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-power/upower-0.99.0 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. The rest of the news item looks good to me. -- 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-dev] RFC: news item for upower
On 03/06/14 19:26, Tom Wijsman wrote: On Tue, 03 Jun 2014 18:53:26 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Title: UPower discontinued hibernate/suspend support https://wiki.gentoo.org/wiki/GLEP:42#News_Item_Headers You're going to hate me for mentioning this, but that is one character too much; 45 44 characters. Besides that, I think it would be nice if this could indicate systemd somehow. Some suggestions to brainstorm further: Title: UPower loses hibernate / suspend to systemd This works. Title: UPower loses suspension to systemd, new fork Title: UPower's suspend in systemd or pm-utils fork I don't want to call it a fork just yet. Albeit, I'm sure it will evolve into one.
Re: [gentoo-dev] RFC: news item for upower
On 03/06/14 18:43, Samuli Suominen wrote: I find this useless at this time because the work is in-progress, but in order to silence the loud minority, please review the news item. Thanks! - Samuli Will commit this tonight, unless someone has more - Samuli Title: UPower loses hibernate / suspend to systemd Author: Samuli Suominen ssuomi...@gentoo.org Content-Type: text/plain Posted: 2014-06-03 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-power/upower-0.99.0 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 --oneshot --noreplace 'sys-power/upower-pm-utils' or # emerge --oneshot --noreplace '=sys-power/upower-0.99.0' However, all systemd users are recommended to stay with sys-power/upower.
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tuesday, June 03, 2014 04:46:18 PM Samuli Suominen wrote: On 03/06/14 16:40, Tom Wijsman wrote: On Tue, 03 Jun 2014 16:28:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 16:20, Tom Wijsman wrote: Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. Nevermind, `cvs up`-ed; heh, I don't understand how you've got to that change, I thought there only was a problem with 0.99.0? in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. Ah, right; thinking of MATE, I understand the 0.99.0 bit now. 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved Which means that the situation I am assuming right now is outdated; so, if you don't mind feel free to highlight why 0.9.23-r3 needs systemd. To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or other To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0 because they are going away, to indicate this is the best time to make informed decision and take manual action regarding choosing which features set he/she wants, to read up upstream announcements regarding UPower, to follow-up and do what admins do All this should have been in a news item, BEFORE it got stabilized. -- Joost
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tuesday, June 03, 2014 04:45:36 PM Chí-Thanh Christopher Nguyễn wrote: Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. And please keep such changes out of stable until proper documentation is in place (and the 30 day period has elapsed, etc.) +1
[gentoo-dev] /sys/fs/cgroup/openrc/???/tasks sometimes missing
If I boot a 32 bit stable Gentoo Linux as a user mode linux guest with current kernels (host is a 32 bit stable Gentoo too), then I do observe sometimes during the boot process error messages from the init system of Gentoo (OpenRC) like the following (for subsystem rngd in this example) : * Starting haveged ... [ ok ] /lib/rc/sh/rc-cgroup.sh: line 87: /sys/fs/cgroup/openrc/rngd/tasks: No such file or directory * Starting rngd ... [ ok ] And indeed, that directory is missing. A restart of the appropriate service however creates those entries. The Gentoo bug entry https://bugs.gentoo.org/show_bug.cgi?id=489386 tells me : It's known race in cgroups, I'm going to address this issue on one of the following weekends. The problem is that issue is not reproducible on my systems. but that's all since 5 months. Now I'm wondering if this just happens for an UML guest and who knows how to fix it ? -- Toralf
Re: [gentoo-dev] /sys/fs/cgroup/openrc/???/tasks sometimes missing
On 03/06/14 02:08 PM, Toralf Förster wrote: If I boot a 32 bit stable Gentoo Linux as a user mode linux guest with current kernels (host is a 32 bit stable Gentoo too), then I do observe sometimes during the boot process error messages from the init system of Gentoo (OpenRC) like the following (for subsystem rngd in this example) : * Starting haveged ... [ ok ] /lib/rc/sh/rc-cgroup.sh: line 87: /sys/fs/cgroup/openrc/rngd/tasks: No such file or directory * Starting rngd ... [ ok ] And indeed, that directory is missing. A restart of the appropriate service however creates those entries. The Gentoo bug entry https://bugs.gentoo.org/show_bug.cgi?id=489386 tells me : It's known race in cgroups, I'm going to address this issue on one of the following weekends. The problem is that issue is not reproducible on my systems. but that's all since 5 months. Now I'm wondering if this just happens for an UML guest and who knows how to fix it ? Please address these mails to gentoo-user@. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: news item for upower
Steev Klimaszewski wrote: Instead of belittling the users because they are wasting so much of your time Causing a rougher transition than neccessary is a waste of users' time. I don't think that's awesome. //Peter
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Fri, 30 May 2014 19:17:31 +0200 Tom Wijsman tom...@gentoo.org wrote: On Fri, 30 May 2014 18:14:11 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: A more reasonable approach would be for the Council to permit the tree to contain at most 6 wrong lines at any given time. That way any developer wishing to add a new wrong line must previously fix an existing wrong line. You can suggest that to the Gentoo Council by replying to the Council agenda thread on the gentoo-project mailing list. whooosh jer
Re: [gentoo-dev] RFC: news item for upower
On 03/06/14 21:58, Peter Stuge wrote: Steev Klimaszewski wrote: Instead of belittling the users because they are wasting so much of your time Causing a rougher transition than neccessary is a waste of users' time. I don't think that's awesome. //Peter I still don't understand how the news item helps anything, it's all matter of running one command, or two at most, `eix upower` after seeing blockers, seeing 2 different options, selecting which one to go with, emerging it I'd say such handholding distracts real admins from the real news items that actually require paying attention :/ - Samuli
Re: [gentoo-dev] RFC: news item for upower
On 03/06/2014 21:50, Samuli Suominen wrote: On 03/06/14 21:58, Peter Stuge wrote: Steev Klimaszewski wrote: Instead of belittling the users because they are wasting so much of your time Causing a rougher transition than neccessary is a waste of users' time. I don't think that's awesome. //Peter I still don't understand how the news item helps anything, it's all matter of running one command, or two at most, `eix upower` after seeing blockers, seeing 2 different options, selecting which one to go with, emerging it I'd say such handholding distracts real admins from the real news items that actually require paying attention :/ Yes, it *is* a simple matter of running one easy command. Portage does that for you with trivial ease. But portage doesn't tell you *which* is the one easy command. A news item does that. Please realise that groking Portage's output takes considerable skill, understanding and familiarity with the scene. It's much easier when you know what will be printed before you run it - perhaps you are in that position? I've been using Gentoo for 10 years and portage still baffles me more often than it should. I resort to reading the ebuild to figure it out. Funny thing is, portage has the same information available as I do so why doesn't it print more human-friendly output? At least we got past that satisfied by no parents in slot stuff and now we have cute carets that point to stuff like some compilers. The point is, human communication is vastly more powerful than machine communication in cases like these, and a news item fits the bill perfectly. There are still 1000s of users out there who haven't run across this upower stumble yet, a news item will help them a lot and will be very well accepted (aka Samuli gets brownie points from user for caring) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Tue, 3 Jun 2014 20:58:46 +0200 Jeroen Roovers j...@gentoo.org wrote: On Fri, 30 May 2014 19:17:31 +0200 Tom Wijsman tom...@gentoo.org wrote: On Fri, 30 May 2014 18:14:11 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: A more reasonable approach would be for the Council to permit the tree to contain at most 6 wrong lines at any given time. That way any developer wishing to add a new wrong line must previously fix an existing wrong line. You can suggest that to the Gentoo Council by replying to the Council agenda thread on the gentoo-project mailing list. whooosh jer boom splat -- 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-dev] RFC: news item for upower
On Tue, 03 Jun 2014 22:24:11 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: The point is, human communication is vastly more powerful +1 It might not be clear in the moment, because it looks like a ton of bikeshedding and other ways some individuals would label this; but it will be useful some time from now, when it leads to useful results. Having some people talk about things on a chat, forum, blog, ... might have a short lived effect now with an occasional spike in the future; but, a news item reaches a much wider public for a much longer item. Let's say someone upgrades his system in some weeks / months from now, that person will be thankful that a news item was written about this; instead of having this be part of the already though job of updating. Of course, there is a thing like too much handholding but I think that's not the case here as the upower case pops up in a lot of places; one does not have to forget that there is also too little handholding. If it weren't for genkernel or a kernel seed to help me start out with a booting system, I perhaps might have never started using Gentoo; I've afterwards managed to change my config over time to look nowhere near the original, but at least it makes me happy to have experienced the handholding to bring me where I am today. These little things matter. -- 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-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
Tom Wijsman: On Tue, 3 Jun 2014 20:58:46 +0200 Jeroen Roovers j...@gentoo.org wrote: On Fri, 30 May 2014 19:17:31 +0200 Tom Wijsman tom...@gentoo.org wrote: On Fri, 30 May 2014 18:14:11 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: A more reasonable approach would be for the Council to permit the tree to contain at most 6 wrong lines at any given time. That way any developer wishing to add a new wrong line must previously fix an existing wrong line. You can suggest that to the Gentoo Council by replying to the Council agenda thread on the gentoo-project mailing list. whooosh jer boom splat Stop spamming and stop telling obvious things. We can write a bot that gives that kind of information.
Re: [gentoo-dev] RFC: news item for upower
On 04/06/2014 00:32, Tom Wijsman wrote: On Tue, 03 Jun 2014 22:24:11 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: The point is, human communication is vastly more powerful +1 It might not be clear in the moment, because it looks like a ton of bikeshedding and other ways some individuals would label this; but it will be useful some time from now, when it leads to useful results. Having some people talk about things on a chat, forum, blog, ... might have a short lived effect now with an occasional spike in the future; but, a news item reaches a much wider public for a much longer item. Let's say someone upgrades his system in some weeks / months from now, that person will be thankful that a news item was written about this; instead of having this be part of the already though job of updating. Of course, there is a thing like too much handholding but I think that's not the case here as the upower case pops up in a lot of places; one does not have to forget that there is also too little handholding. If it weren't for genkernel or a kernel seed to help me start out with a booting system, I perhaps might have never started using Gentoo; I've afterwards managed to change my config over time to look nowhere near the original, but at least it makes me happy to have experienced the handholding to bring me where I am today. These little things matter. Indeed. It really comes down to a judgement call whether to compose a news item or not. I myself in my sysadmin day job get this right about 50% of the time if I'm lucky. I've learned (via hard knocks) that if a number of people raise concerns, then it very well might not be bikeshedding, it might be valid. Often as the BOFH I'm too close to the technical problem to notice the human elements - that needs a view from 10 feet back. News items are probably one of Gentoo's best ideas ever. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Tue, 03 Jun 2014 22:35:13 + hasufell hasuf...@gentoo.org wrote: Tom Wijsman: On Tue, 3 Jun 2014 20:58:46 +0200 Jeroen Roovers j...@gentoo.org wrote: On Fri, 30 May 2014 19:17:31 +0200 Tom Wijsman tom...@gentoo.org wrote: On Fri, 30 May 2014 18:14:11 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: A more reasonable approach would be for the Council to permit the tree to contain at most 6 wrong lines at any given time. That way any developer wishing to add a new wrong line must previously fix an existing wrong line. You can suggest that to the Gentoo Council by replying to the Council agenda thread on the gentoo-project mailing list. whooosh jer boom splat Stop spamming and stop telling obvious things. We can write a bot that gives that kind of information. We can also write a bot that points out that it is nonsense, doesn't matter and breakage as in your original response to this sub thread. Can you instead tell us what you think makes sense, matters and works? In this case, for me; whooosh boom splat makes sense, matters and works. -- 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
[OT] Re: [gentoo-dev] RFC: news item for upower
On Wed, 04 Jun 2014 00:49:48 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: Indeed. It really comes down to a judgement call whether to compose a news item or not. True, it is not always easy; although some of us want or try to figure this out in advance, even predictions won't help to determine how well the users will experience these kind of effects. The more these events happen, the more I think they're aftermath is inevitable, the more it would be nice to redesign to prevent the events from happening. Especially when you get to know the Portage output better, it is hard to judge how well the Portage output still is for existing users; I have no motivation to improve the Portage output for myself, given I can find my way in it in a reasonable amount of time (given the parameters --tree and --unordered-display which are not default). But that's where it stops; though I recognize that it is not as helpful for new users, as well as want to improve it for them, it is hard to know where to start and what kind of output to go for. We're locked down to a particular view; thinking of other views, it'll be hard to see one where there is a benefit that outweighs the costs implementing it. So, then you can come to the conclusion that we have good enough output considering the conditions in which the output can be changed; and as a result of it not changing, we rely more and more on its knowledge. I myself in my sysadmin day job get this right about 50% of the time if I'm lucky. I've learned (via hard knocks) that if a number of people raise concerns, then it very well might not be bikeshedding, it might be valid. What I'm trying to say was that it is still in some way valid when you bike shed; it isn't so much anymore about the central point being discussed about being valid, but the idea behind why you're discussing that central point. Among other things, this highlights things in the organization and/or respect of the matter at hand; it won't result a change wrt to the central point, but it'll result in a change of organization and/or respect. Just because you can't quickly find out a date to go out with someone doesn't mean you can't do it more organized and respectful next time. Often as the BOFH I'm too close to the technical problem to notice the human elements - that needs a view from 10 feet back. When faced with a technical problem; there are 3 or more ways to take a stance, some of which conflicting stances make the human part matter: 1. Aggressive: You want your work to happen and lead to results. 2. Defensive: You want to prevent your work from changing, you want to prevent the results of your work from changing. 3. Neutral: You don't know much about the work, it's not clear what you want; given that, you'll play devil's advocate to learn more of it. Now, with any of these; it is easy to get into the human elements, which have to do with a problem in the organization (expectations, planning, reports, ...) or respect (finding out what works for both). Sometimes the view is too far back, because you're as explained above grown used to the situation; when that happens, you get stuck and either need to make a comprise not in your favor or need to move on. A lot of compromises, some recently, get made; which I'm happy about. A lot of us are here for improving Gentoo, we can't just always agree on the particular way in which to do that; but it'll be the net result of all those (dis)agreements, compromises and walks that count. News items are probably one of Gentoo's best ideas ever. True that. -- 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...)
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...) There is no such thing as a non-systemd profile; a sub directory is a specialization, that doesn't mean that it parents suddenly become the opposite of that. No, the parents are just generalizations that aren't as specific as the sub directory. Doing what you've suggested everywhere but in gnome/systemd and kde/systemd is a recipe to upset everyone whom runs systemd on another desktop environment than GNOME or KDE; so, that's not a way forward. Another option is to create no-systemd sub directories; but such profiles will be highly controversial, besides helping the exponential grow of the profiles directories as well as be a non-default profile. Mix-ins from Funtoo, anyone? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : 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-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 06/04/2014 08:24 AM, Tom Wijsman wrote: On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...) There is no such thing as a non-systemd profile; a sub directory is a specialization, that doesn't mean that it parents suddenly become the opposite of that. No, the parents are just generalizations that aren't as specific as the sub directory. Since systemd needs special profiles to be easy to use ... ... it'd be the boring and easy way to restrict it to those profiles so that dependency changes don't cause this needless amount of work for users, and this indecent amount of mail on this mailinglist Doing what you've suggested everywhere but in gnome/systemd and kde/systemd is a recipe to upset everyone whom runs systemd on another desktop environment than GNOME or KDE; so, that's not a way forward. I have no idea what you are trying to say, but there's a desktop profile Another option is to create no-systemd sub directories; but such profiles will be highly controversial, besides helping the exponential grow of the profiles directories as well as be a non-default profile. The default is already that, all I'm suggesting is masking systemd there so that portage doesn't needlessly antagonize users Mix-ins from Funtoo, anyone? No thanks
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 06/03/2014 08:24 PM, Tom Wijsman wrote: On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: [Lots of comments about upower updates and interactions between systemd and Open-rc...] I'm sorry, but it seems to me that this is *another* power grab by the systemd Cabal. More and more a small group of developers are making non-well-thought-out changes to the Linux environment that have the effect of pushing systemd as the default model for init systems. First, they abrogated the FHS by putting boot necessary stuff in the /usr hierarchy (deliberately ignoring the FHS rationale and history) forcing many users to redo systems to not have separate /usr trees. Then, they steal a general kernel command line parameter (debug) that makes booting impossible in certain cases. (Linus had to put his foot down on that one.) And now, another useful process is forced to make workarounds for users so that they don't get switched to systemd willy-nilly. (Don't get me started on the GD linkage between Gnome and systemd!) As one of the uncredited makers of the SysV init system (I was a lowly consultant sysadmin during the Unix System IV roll out) I know more of the history than most. SysV init punted the hard problem of getting sequencing and dependency during startup to the more agile mind of a human because we didn't have the time to develop a general dependency solver for the boot sequence. (And someone who was supposed to document that need for examination in the SysV development cycle seems ti have neglected the item.) OpenRC does some logical and straight-forward extensions to the SysV paradigm and handles the problem well enough. SystemD goes for a total rewrite (and suffers second system syndrome) and seems to be masterminded by folks with Napoleonic ideation. Mind you, I am *not* anti-systemd. In many ways it is a good system that automates a lot of stuff that needed automation. I just have some strong disagreements with some of the choices its implementors and advocates have made in relation to other aspects of system management. I have thought that Linux and the FOSS movement was about user choice. Not a small band of folks deciding that users shouldn't be expected to know what their systems are doing under-the-hood and forcing that vision on everyone, whether they want it or not. I moved to Gentoo (from a long history with RedHat and then Fedora) because it seemed to me that the concept of maximum choice was a treasured and honored position. Recent events, however, seem to indicate that even here in Gentoo-land there is a power struggle occurring. As I'm getting to the stage of being a senior citizen I probably will not have to deal with the fallout of this struggle for too long, but it disheartens me to see it occurring.
Re: Off-list: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 04/06/2014 02:24, Tom Wijsman wrote: There is no such thing as a non-systemd profile; a sub directory is a specialization, that doesn't mean that it parents suddenly become the opposite of that. No, the parents are just generalizations that aren't as specific as the sub directory. Doing what you've suggested everywhere but in gnome/systemd and kde/systemd is a recipe to upset everyone whom runs systemd on another desktop environment than GNOME or KDE; so, that's not a way forward. Another option is to create no-systemd sub directories; but such profiles will be highly controversial, besides helping the exponential grow of the profiles directories as well as be a non-default profile. Mix-ins from Funtoo, anyone? p.s. off-list :-) mix-ins? Awesome idea. We should do more of those. I don't understand why people are punting this idea of a non-systemd profile, I can see how that could ever work. Profiles *add* stuff or set some defaults, taking things away in a profile is really hard. The only thing it works for is globally setting stuff that can never be used eg, you need to remove all x86 cpu flags from arm Desktop profiles with and without systemd or KDE or Gnome or whatever looks exactly like an inherited class plus interfaces problem. Which is what mix-ins do :-) So once again - mixins, an awesome idea -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC: news item for upower
On 04/06/14 01:49, Alan McKinnon wrote: On 04/06/2014 00:32, Tom Wijsman wrote: On Tue, 03 Jun 2014 22:24:11 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: The point is, human communication is vastly more powerful +1 It might not be clear in the moment, because it looks like a ton of bikeshedding and other ways some individuals would label this; but it will be useful some time from now, when it leads to useful results. Having some people talk about things on a chat, forum, blog, ... might have a short lived effect now with an occasional spike in the future; but, a news item reaches a much wider public for a much longer item. Let's say someone upgrades his system in some weeks / months from now, that person will be thankful that a news item was written about this; instead of having this be part of the already though job of updating. Of course, there is a thing like too much handholding but I think that's not the case here as the upower case pops up in a lot of places; one does not have to forget that there is also too little handholding. If it weren't for genkernel or a kernel seed to help me start out with a booting system, I perhaps might have never started using Gentoo; I've afterwards managed to change my config over time to look nowhere near the original, but at least it makes me happy to have experienced the handholding to bring me where I am today. These little things matter. Indeed. It really comes down to a judgement call whether to compose a news item or not. I myself in my sysadmin day job get this right about 50% of the time if I'm lucky. I've learned (via hard knocks) that if a number of people raise concerns, then it very well might not be bikeshedding, it might be valid. Often as the BOFH I'm too close to the technical problem to notice the human elements - that needs a view from 10 feet back. News items are probably one of Gentoo's best ideas ever. I agree, and I'm using news items actively (everyone remembers my udev related news items you have gotten on every major change, even on quite small things like configuration filename changes) All I'm saying is that instructions for simple emerge commands is going overboard As in, don't you think I've considered, as a active GLEP 42 user, if there was a need for one this time? I weighted my options for 3 months before acting, and people actually agreed with me it wasn't necessary at this time. I'm really suprised about this, how small group of loud people on ML can have this kind of effect. It's like, pick a $package_name, raise enough noise on ML about it, get a news item saying 'emerge this' I'm just expecting more from our users. I don't think the news items were ever designed for simplistic things like this. - Samuli
Re: [gentoo-dev] RFC: news item for upower
On 04/06/14 07:11, Samuli Suominen wrote: I'm just expecting more from our users. I don't think the news items were ever designed for simplistic things like this. As in, GLEP 42 Critical News Item != Learning tool for understanding Portage output
