[gentoo-dev] Gnome Stabilization 3.6 or 3.8

[gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michael Weber]

Greetings,

Gnome Herd decided to target stablilization of 3.8 [1] which requires
systemd.

What are the reasons to stable 3.8 and not 3.6, a version w/o this
restriction, enabling all non systemd users to profit from this
eye-candy as well.

I raise the freedom of choice card here. And deliberately choosing an
uncooperative version doesn't shine a good light.

Facts, pls!

   Michael

[1] https://bugs.gentoo.org/show_bug.cgi?id=478252
-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alexandre Rostovtsev]

On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
> Greetings,
> 
> Gnome Herd decided to target stablilization of 3.8 [1] which requires
> systemd.
> 
> What are the reasons to stable 3.8 and not 3.6, a version w/o this
> restriction, enabling all non systemd users to profit from this
> eye-candy as well.
> 
> I raise the freedom of choice card here. And deliberately choosing an
> uncooperative version doesn't shine a good light.
> 
> Facts, pls!
> 
>    Michael
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252

To stabilize gnome-3.6, we would need
1. one or (preferably) two *active* gentoo developers;
2. who are familiar with gnome's internals and are able to backport
bugfixes from 3.8/3.10 without support from upstream developers; and
3. who volunteer to run openrc+gnome-3.6 for a long time on their main
machines so that they can give a stable 3.6 the support that the word
'stable' implies.

We do not have such people on the gnome team.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Wed, 07 Aug 2013 09:14:14 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:

> On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
>
> > What are the reasons to stable 3.8 and not 3.6, a version w/o this
> > restriction, enabling all non systemd users to profit from this
> > eye-candy as well.
> > 
> > I raise the freedom of choice card here. And deliberately choosing
> > an uncooperative version doesn't shine a good light.
> 
> To stabilize gnome-3.6, we would need
>
> 1. one or (preferably) two *active* gentoo developers;
> 2. who are familiar with gnome's internals and are able to backport
> bugfixes from 3.8/3.10 without support from upstream developers; and
> 3. who volunteer to run openrc+gnome-3.6 for a long time on their main
> machines so that they can give a stable 3.6 the support that the word
> 'stable' implies.
> 
> We do not have such people on the gnome team.

There's going to be a lot of complaints and rant about this, some of
which has already started in some places like the forums; as far as I
see I barely see people raising their hands to put in the work. At most
I recall some work here and there by one or two individuals, but in all
seriousness I don't think that's enough to pull it off.

While people can scream, complaint and rant all they want about choice;
it isn't going to happen if nobody is going to implement it, until that
happens following whatever upstream does is the only reasonable thing
to do. Or if you really want to help, help implement the choice... :)

It's not enough to just re-introduce support as well as to port back
part of that support, which they don't seem to even have currently for
3.8; it goes a lot further than that, as mentioned by tetromino, the
fixes have to be ported back as well.

Let's say if they ignore all that and do stabilize 3.6; then they are
just moving this problem, because then they won't end up getting 3.8 or
later stabilized in the future because of the same objection.

Using systemd and GNOME 3.8.3 on a daily basis, I haven't been able to
run the entire 3.6 and 3.8 until a late fix [1] that took me weeks to
find in all the seas of debugging information I have enabled; there are
some other reports of users having similar and other issues, so I deem
fixes like those are necessary for stabilization. Because really, they
shouldn't be stabilizing something they know is heavily broken for some
users; thus in its current state, 3.6 isn't really a good candidate.

 [1]: https://bugzilla.gnome.org/show_bug.cgi?id=704286

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El mié, 07-08-2013 a las 14:45 +0200, Michael Weber escribió:
> Greetings,
> 
> Gnome Herd decided to target stablilization of 3.8 [1] which requires
> systemd.
> 
> What are the reasons to stable 3.8 and not 3.6, a version w/o this
> restriction, enabling all non systemd users to profit from this
> eye-candy as well.
> 
> I raise the freedom of choice card here. And deliberately choosing an
> uncooperative version doesn't shine a good light.
> 
> Facts, pls!
> 
>    Michael
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252

Gnome 3.6 is not maintained by upstream now -> bugs are being fixed in
3.8 and 3.9. Also, stabilizing 3.6 will point Gnome2 users to this two
options:
- Run gnome-shell
- Run 3.6 fallback mode -> 3.6 fallback mode is using old gnome-panel
stuff that was dropped in 3.8 because it wasn't really maintained

They will also be able to run 3.6 with openrc... but that will be the
last version "working" with it, we will hit the same problem again when
we want to stabilize 3.8 (well, 3.10 is going to be released in October,
I think we have been waiting enough)

Also, I think we should stop spending a lot of time trying to keep it
working with openrc, we simply don't have resources to do that at the
moment (even Debian/Ubuntu people are stick with systemd-204 because
they don't have resources to keep logind working without systemd in
newer versions). Now, we are needing to put a lot of effort on trying to
provide unit files and provide systemd related fixes in the tree because
we haven't (in general) pay attention to systemd at all => I think we
should put more efforts on it than trying to work on hacks to prevent
systemd dependency.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Wed, Aug 7, 2013 at 9:56 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> While people can scream, complaint and rant all they want about choice;
> it isn't going to happen if nobody is going to implement it, until that
> happens following whatever upstream does is the only reasonable thing
> to do. Or if you really want to help, help implement the choice... :)
>

++

If somebody wants to do the work to create another choice and others
get in their way I'm all for helping to clear the roadblocks (in a
reasonable way).

However, just standing up and demanding choice isn't going to get
anybody anywhere, especially not with me.  The Gnome team isn't
required to support any particular configuration.  Heck, they're not
even required to maintain Gnome at all (though obviously if they don't
it will get treecleaned).

Upstream Gnome has tied their fates to systemd.  Patching it to enable
other configs is noble, but nothing that anybody should be forced to
do.  If anybody wants to maintain Gnome sans systemd knock yourself
out.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote:
> On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
>> Greetings,
>>
>> Gnome Herd decided to target stablilization of 3.8 [1] which requires
>> systemd.
>>
>> What are the reasons to stable 3.8 and not 3.6, a version w/o this
>> restriction, enabling all non systemd users to profit from this
>> eye-candy as well.
>>
>> I raise the freedom of choice card here. And deliberately choosing an
>> uncooperative version doesn't shine a good light.
>>
>> Facts, pls!
>>
>>    Michael
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252
> 
> To stabilize gnome-3.6, we would need
> 1. one or (preferably) two *active* gentoo developers;
> 2. who are familiar with gnome's internals and are able to backport
> bugfixes from 3.8/3.10 without support from upstream developers; and
> 3. who volunteer to run openrc+gnome-3.6 for a long time on their main
> machines so that they can give a stable 3.6 the support that the word
> 'stable' implies.
> 
> We do not have such people on the gnome team.
> 

Seeing the noise in #gentoo from people getting whacked in the kidney by
the systemd sidegrade ... that's a very optimistic decision.

It'll cause lots of pain for users that suddenly can't start lvm
properly and other nasty landmines hidden in the "upgrade path". By
stabilizing this early you're causing lots of extra work for others.

I hope you understand that some of us will be very rude and just suggest
to unmerge gnome on all support requests as it now moves outside our
support range ...

Have a nice day,

Patrick

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alex Alexander]

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

On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer <patrick@gentoo.org> wrote:

> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote:
> > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
> >> Greetings,
> >>
> >> Gnome Herd decided to target stablilization of 3.8 [1] which requires
> >> systemd.
> >>
> >> What are the reasons to stable 3.8 and not 3.6, a version w/o this
> >> restriction, enabling all non systemd users to profit from this
> >> eye-candy as well.
> >>
> >> I raise the freedom of choice card here. And deliberately choosing an
> >> uncooperative version doesn't shine a good light.
> >>
> >> Facts, pls!
> >>
> >>    Michael
> >>
> >> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252
> >
> > To stabilize gnome-3.6, we would need
> > 1. one or (preferably) two *active* gentoo developers;
> > 2. who are familiar with gnome's internals and are able to backport
> > bugfixes from 3.8/3.10 without support from upstream developers; and
> > 3. who volunteer to run openrc+gnome-3.6 for a long time on their main
> > machines so that they can give a stable 3.6 the support that the word
> > 'stable' implies.
> >
> > We do not have such people on the gnome team.
> >
>
> Seeing the noise in #gentoo from people getting whacked in the kidney by
> the systemd sidegrade ... that's a very optimistic decision.
>
> It'll cause lots of pain for users that suddenly can't start lvm
> properly and other nasty landmines hidden in the "upgrade path". By
> stabilizing this early you're causing lots of extra work for others.
>
> I hope you understand that some of us will be very rude and just suggest
> to unmerge gnome on all support requests as it now moves outside our
> support range ...
>
> Have a nice day,
>
> Patrick
>

Although I understand your frustration, I don't see any other options for
the Gentoo gnome team. People who don't like this should take their
complaints upstream.

-- 
Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

[-- Attachment #2: Type: text/html, Size: 2923 bytes --]

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Daniel Campbell]

On 08/07/2013 10:16 AM, Pacho Ramos wrote:
> Also, I think we should stop spending a lot of time trying to keep it
> working with openrc, we simply don't have resources to do that at the
> moment (even Debian/Ubuntu people are stick with systemd-204 because
> they don't have resources to keep logind working without systemd in
> newer versions). Now, we are needing to put a lot of effort on trying to
> provide unit files and provide systemd related fixes in the tree because
> we haven't (in general) pay attention to systemd at all => I think we
> should put more efforts on it than trying to work on hacks to prevent
> systemd dependency.

I agree that there's no point in hacking software that voluntarily ties
itself to systemd to *not* be tied to it, but dependency on any single
init system is a bad idea. There are multiple kernels, multiple libc's,
multiple device management layers, multiple inits, etc. Preventing
dependency on certain things is a good way to enforce software diversity.

Granted, in systemd's case Gentoo's not the place to do it. It's the
upstreams that should be convinced or told not to depend on a single
init system.

Forgive me if my interpretation is wrong; it just seemed to me that you
were all for vertical integration (systemd dependency as a whole) and
the systemd creep is one of the reasons I came to Gentoo. I'd hate to
see developers abandoning their work on OpenRC or other Gentoo projects
to embrace the Red Hat campaign.

[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Duncan]

Alex Alexander posted on Thu, 08 Aug 2013 05:51:38 +0300 as excerpted:

> On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer wrote:
> 
>> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote:
>> > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
>> >>
>> >> Gnome Herd decided to target stablilization of 3.8 [1] which
>> >> requires systemd.
>> >>
>> >> What are the reasons to stable 3.8 and not 3.6, a version w/o this
>> >> restriction, enabling all non systemd users to profit from this
>> >> eye-candy as well.
>> >
>> > To stabilize gnome-3.6, we would need [people willing to do it].
>> > We do not have such people on the gnome team.
>> >
>> Seeing the noise in #gentoo from people getting whacked in the kidney
>> by the systemd sidegrade ... that's a very optimistic decision.
>>
>> It'll cause lots of pain for users that suddenly can't start lvm
>> properly and other nasty landmines

>> I hope you understand that some of us will be very rude and just
>> suggest to unmerge gnome on all support requests as it now moves
>> outside our support range ...
>>
> Although I understand your frustration, I don't see any other options
> for the Gentoo gnome team. People who don't like this should take their
> complaints upstream.

That reads to me like resigned acceptance.

Gentoo/gnome is simply working with what upstream gnome gives them, which 
for gentoo/gnome users now means a choice between gnome with systemd and 
if no systemd, no gnome either.  Upstream decision that gentoo/gnome is 
dealing with too.

...

[Those uninterested in gentoo/kde can stop reading here, as the rest of 
the post is a complaint about that project not taking the same position.]

Gentoo/kde users would be so lucky!

As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing 
to continue support for the options kde upstream *ARE* still providing -- 
kde4 with the semantic-desktop options turned off.  Yes, this does mean 
doing without kdepim, but that has been the case for several versions, no 
upstream change there for 4.11, at least not for kde's base packages as 
necessary to run a kde desktop, yet gentoo carried support for building 
kde without semantic-desktop in 4.10, and doesn't in 4.11.

Meanwhile, while the same build-time options that worked in 4.10 still 
work in 4.11 (I know, as I put a lot of work into patching the ebuilds 
here when gentoo/kde removed the options despite upstream continuing to 
have them), the gentoo/kde project has decided to force the semantic-
desktop option ON for gentooers even where upstream continues to provide 
the option to turn it off!


None-the-less, I do understand the problem of a gentoo project supporting 
an option no devs on the project are actually interested in running.  
Testing would be left to users, and quality would suffer a bit as a 
result, but I know for a fact that there's users out there DOING that 
testing, even with the additional cost of having to maintain ebuild 
patches themselves to do it, because I'm one of them!  Further, I'm 
running 4.11.49.9999 live-branch and was running the betas before the 
branch from trunk, so there's at least one user actually doing that 
testing early enough to catch a good share of that feature's problems 
before they get anywhere close to ~arch, let alone stable.

Despite, or perhaps /because/ of, all the previous pain kde upstream has 
caused its users with the 4.x bump (which unlike the 4.10/4.11 bump was 
at LEAST a major version bump) and with kdepim's switch to akonadi 
mid-4.x (which unfortunately was NOT a major version bump), this time 
there's no indication of upstream kde changing semantic-desktop horses 
mid-stream and mid-major-version and forcing it on like that; it's
gentoo/kde that's doing it, pure and simple.

And I've already posted that regardless of what upstream kde or gentoo/kde 
does, after all the trouble I went thru to rid my system of semantic-
desktop earlier in the kde4 series, I'm not ABOUT to enable it again now, 
yes indeed, even if that means I unmerge the kde desktop entirely and 
switch to something else -- which after all I've already done for major 
portions of kde, including switching kmail->claws-mail when kdepim 
unfortunately jumped the shark mid-major-version.


So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde project 
took the same position gentoo/gnome's taking here, that they support what 
upstream offers, that gentoo/gnome's only forcing systemd because 
upstream gnome's forcing it.  Were that the case, semantic-desktop 
wouldn't be forced by gentoo/kde in kde 4.11, where upstream still offers 
the same options they did in 4.10, where gentoo/kde offered the option as 
well.

Meanwhile, I guess I know what the kde-sunset users felt like now... 
except in that case as well as the gentoo/gnome case but unlike this one, 
upstream WAS dropping support, and the gentoo project was simply 
following upstream...

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

Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Daniel Campbell]

On 08/08/2013 01:21 AM, Duncan wrote:
> Alex Alexander posted on Thu, 08 Aug 2013 05:51:38 +0300 as excerpted:
> 
>> On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer wrote:
>>
>>> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote:
>>>> On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
>>>>>
>>>>> Gnome Herd decided to target stablilization of 3.8 [1] which
>>>>> requires systemd.
>>>>>
>>>>> What are the reasons to stable 3.8 and not 3.6, a version w/o this
>>>>> restriction, enabling all non systemd users to profit from this
>>>>> eye-candy as well.
>>>>
>>>> To stabilize gnome-3.6, we would need [people willing to do it].
>>>> We do not have such people on the gnome team.
>>>>
>>> Seeing the noise in #gentoo from people getting whacked in the kidney
>>> by the systemd sidegrade ... that's a very optimistic decision.
>>>
>>> It'll cause lots of pain for users that suddenly can't start lvm
>>> properly and other nasty landmines
> 
>>> I hope you understand that some of us will be very rude and just
>>> suggest to unmerge gnome on all support requests as it now moves
>>> outside our support range ...
>>>
>> Although I understand your frustration, I don't see any other options
>> for the Gentoo gnome team. People who don't like this should take their
>> complaints upstream.
> 
> That reads to me like resigned acceptance.
> 
> Gentoo/gnome is simply working with what upstream gnome gives them, which 
> for gentoo/gnome users now means a choice between gnome with systemd and 
> if no systemd, no gnome either.  Upstream decision that gentoo/gnome is 
> dealing with too.
> 
> ...
> 
> [Those uninterested in gentoo/kde can stop reading here, as the rest of 
> the post is a complaint about that project not taking the same position.]
> 
> Gentoo/kde users would be so lucky!
> 
> As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing 
> to continue support for the options kde upstream *ARE* still providing -- 
> kde4 with the semantic-desktop options turned off.  Yes, this does mean 
> doing without kdepim, but that has been the case for several versions, no 
> upstream change there for 4.11, at least not for kde's base packages as 
> necessary to run a kde desktop, yet gentoo carried support for building 
> kde without semantic-desktop in 4.10, and doesn't in 4.11.
> 
> Meanwhile, while the same build-time options that worked in 4.10 still 
> work in 4.11 (I know, as I put a lot of work into patching the ebuilds 
> here when gentoo/kde removed the options despite upstream continuing to 
> have them), the gentoo/kde project has decided to force the semantic-
> desktop option ON for gentooers even where upstream continues to provide 
> the option to turn it off!
> 
> 
> None-the-less, I do understand the problem of a gentoo project supporting 
> an option no devs on the project are actually interested in running.  
> Testing would be left to users, and quality would suffer a bit as a 
> result, but I know for a fact that there's users out there DOING that 
> testing, even with the additional cost of having to maintain ebuild 
> patches themselves to do it, because I'm one of them!  Further, I'm 
> running 4.11.49.9999 live-branch and was running the betas before the 
> branch from trunk, so there's at least one user actually doing that 
> testing early enough to catch a good share of that feature's problems 
> before they get anywhere close to ~arch, let alone stable.
> 
> Despite, or perhaps /because/ of, all the previous pain kde upstream has 
> caused its users with the 4.x bump (which unlike the 4.10/4.11 bump was 
> at LEAST a major version bump) and with kdepim's switch to akonadi 
> mid-4.x (which unfortunately was NOT a major version bump), this time 
> there's no indication of upstream kde changing semantic-desktop horses 
> mid-stream and mid-major-version and forcing it on like that; it's
> gentoo/kde that's doing it, pure and simple.
> 
> And I've already posted that regardless of what upstream kde or gentoo/kde 
> does, after all the trouble I went thru to rid my system of semantic-
> desktop earlier in the kde4 series, I'm not ABOUT to enable it again now, 
> yes indeed, even if that means I unmerge the kde desktop entirely and 
> switch to something else -- which after all I've already done for major 
> portions of kde, including switching kmail->claws-mail when kdepim 
> unfortunately jumped the shark mid-major-version.
> 
> 
> So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde project 
> took the same position gentoo/gnome's taking here, that they support what 
> upstream offers, that gentoo/gnome's only forcing systemd because 
> upstream gnome's forcing it.  Were that the case, semantic-desktop 
> wouldn't be forced by gentoo/kde in kde 4.11, where upstream still offers 
> the same options they did in 4.10, where gentoo/kde offered the option as 
> well.
> 
> Meanwhile, I guess I know what the kde-sunset users felt like now... 
> except in that case as well as the gentoo/gnome case but unlike this one, 
> upstream WAS dropping support, and the gentoo project was simply 
> following upstream...
> 

Wow, that really sucks. I'm not posting this to the ML since I have
nothing to offer to their discussion. All this mess with GNOME and KDE
makes me happy to run vanilla X with Fluxbox, though. :P Which options
have you considered, if Gentoo/KDE doesn't re-enable the option to
disable semantic desktop?

Regards,

Daniel

KDE/semantic-desktop, was: Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Andreas K. Huettel]

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

Am Donnerstag, 8. August 2013, 08:21:47 schrieb Duncan:
> ...
> 
> [Those uninterested in gentoo/kde can stop reading here, as the rest of
> the post is a complaint about that project not taking the same position.]
> 
> Gentoo/kde users would be so lucky!
> 
> As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing
> to continue support for the options kde upstream *ARE* still providing --
> kde4 with the semantic-desktop options turned off.  

Let me quote a user comment from my blog [who was in the beginning very much 
concerned about this decision as well]:

"I decided it might be wise to rebuild +semantic-desktop globally, to see for 
myself what would actually happen. After 8 hours of compiling (Atom N270) the 
answer is about 10 additional megs of ram at idle and about 2 extra seconds to 
boot. There is no performance penalty to load gwenview or dolphin. kdelibs 
took an additional 10 minutes to compile (2h 15 vs 2h 5); the flag system wide 
should not increase my compile times by more than a percentage point or two. 
Given that the hit is extremely minimal: I do apologise for getting 
prematurely butthurt, and I welcome our new semantic overlords."

It's simply a matter of priorities. If the resulting damage is that minimal, 
it is not worth the effort.

(I mean, it's not as if you'd have to switch to a totally different init 
system or such. :)

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

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

[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Duncan]

Daniel Campbell posted on Thu, 08 Aug 2013 01:26:47 -0500 as excerpted:

> [Duncan wrote...]
>> Gentoo/gnome is simply working with what upstream gnome gives them,
>> which for gentoo/gnome users now means a choice between gnome with
>> systemd and if no systemd, no gnome either.  Upstream decision that
>> gentoo/gnome is dealing with too.
>> 
>> ...
>> 
>> So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde
>> project took the same position gentoo/gnome's taking here, that they
>> support what upstream offers, that gentoo/gnome's only forcing systemd
>> because upstream gnome's forcing it.  Were that the case,
>> semantic-desktop wouldn't be forced by gentoo/kde in kde 4.11, where
>> upstream still offers the same options they did in 4.10, where
>> gentoo/kde offered the option as well.
>> 
> Wow, that really sucks. I'm not posting this to the ML since I have
> nothing to offer to their discussion.

The best of intents... you did. =:^\

> All this mess with GNOME and KDE
> makes me happy to run vanilla X with Fluxbox, though. :P Which options
> have you considered, if Gentoo/KDE doesn't re-enable the option to
> disable semantic desktop?

[This is probably a rather longer reply than you expected, but eh... it 
helps me order my thoughts and plans by putting them into words, as 
well...]

For now, I'm carrying the necessary patches (generated by examining the 
diffs between the ebuilds with and without that support, updating as 
needed) myself.  This is in fact how I can state with such certainty that 
upstream still provides the required options -- I'm still using them!

But I started a thread on the gentoo-desktop list (which is where the kde-
sunset people gathered as well as where gentoo/kde announces meetings, 
etc) asking if anyone else were interested in helping, with the idea of 
doing something like the user maintained kde-sunset overlay.  That 
generated a number of hits, and there's a thread on the forums discussing 
the topic (and linking to the list thread) as well, so I'm definitely not 
the only one unhappy with the current situation.  Tho I've let that sit 
for a couple weeks as "real life" got in the way, unfortunately.

Meanwhile, if all goes well, the effort should be reasonably short term, 
as upstream kde has already announced that for kde5 they're going far 
more modularized, splitting off most packages to have independent 
releases no longer necessarily synced to the kde core release cycle and 
versioning, and indeed, for kde5, they're calling that core
kde-frameworks-5 -- which then itself becomes a much smaller kde5, as all 
the newly independent packages WILL have their own release cycle and 
versioning.

Given the further modularization for kde5/frameworks as the primary 
declared and apparently well under way goal (an early preview release of 
this core/framework is apparently already available, tho I've not tried 
it) and no indications to the contrary, it seems unlikely that they'd 
actually DE-modularize the semantic-desktop components, making them LESS 
optional for frameworks and the basic desktop in the supposedly MORE 
modularized kde5/frameworks than in current kde4, and in fact, kde's 
plasma desktop itself has evolved to target (non-kde) mobile deployment 
as its own "mobile-top" in the mean time too, so it really doesn't seem 
that plasma2's likely to force a dependency that even on the desktop 
takes enough resources to cause people to care strongly enough about 
getting it off their systems that they'll go to extreme lengths to do it.

So I'm /reasonably/ optimistic about kde5/frameworks not requiring 
semantic-desktop at the global level.  Which of course makes gentoo/kde's 
choice so late in the game (with 4.11 being declared the last 4-series 
feature release for many kde4 apps including the plasma-desktop itself) 
even *MORE* galling than it'd otherwise be!

Never-the-less, realistically, I don't see myself continuing "forever" 
with these patches, particularly if the "kde-slim" overlay idea doesn't 
pan out...

Should that happen, and should I be wrong about kde5/frameworks not hard-
requiring semantic-desktop (or should gentoo/kde continue to hard-enable 
it in kde5/frameworks despite upstream's support for the option)...

My current plan is in that worst-case to switch, with my "investigate-
further-short-list" currently including:

* The new and still evolving razor-qt/lxde-qt

http://wiki.lxde.org/en/LXDE-Qt

* enlightenment

* Possibly something gtk-related like xfce, given how far toward the gtk 
side I've tipped since kde4.  But currently that's all gtk2, and with 
gtk2's own future in doubt and gtk3's close ties to the our-way-or-the-
highway gnome, so that even formerly gtk-based desktops like lxde are 
turning qt, for all I can see that'd be a jump from the frying pan into 
the fire, so I'd have to see some potential resolution to the gtk2/gtk3 
issue, before considering that for anything longer term.  (I've actually 
been wondering what claws-mail's position is on this, but I did some 
research on firefox about a year ago and their gtk3 implementation was 
still hugely missing, and I'm reasonably confident that as long as firefox 
remains gtk2 and at least so long as chromium doesn't eat /all/ of 
firefox's Linux share, gtk2's own support status can't be /terribly/ 
dire, so...)


Of course the other big upcoming "paradigm switch" is wayland.  Qt5 and 
kde5/frameworks already support it to some degree, and indeed, there's 
early experimental wayland support in the kde-frameworks preview I 
mentioned as well as in kde 4.11 (with a very early wayland preview of 
its own), and of course gtk3 has its own wayland support, but I've seen 
nothing about gtk2-wayland, and I suspect wayland is actually what's 
bringing the curtain down on continuing gtk2 support more than anything 
else.

But I suspect the wayland switch could effectively turn the current Linux/
GUI/X world as we know it on its head -- it *CERTAINLY* has that 
potential -- and 2-3 years from now (or possibly by the end of 2014 (!!)) 
what remains of the linux desktop, with "modern" desktops on wayland by 
then altho X certainly won't be dead for awhile longer, very likely 
looking like an entirely different competitive landscape.  Beyond that, 
my "crystal ball" goes opaque, and I really don't have much of a clue 
/what/ I'll be looking at in terms of desktop choices, except that I have 
the strong feeling some of our currently familiar desktop environment 
names will be replaced!  But I won't even venture a guess as to which 
ones...  Totally opaque, the crystal ball, at that point.


But that's in the future.  For now, I'm hoping to jump back into to the 
kde-slim overlay discussion, hopefully boosting it with some of the 
patches I've already deployed here.  And if/when there's signals of any 
of these three: kde5/frameworks NOT going optional/modular with semantic-
desktop, gentoo/kde CONTINUING their un-gentoo-line forced-semantic 
options into kde5/frameworks, or kde5/frameworks getting stuck in "duke-
nukem-forever" mode, /then/ I'll have to see where the kde-lean overlay 
project is at, as well as take a deeper look at lxde-qt, enlightenment, 
and other options.  (That's if I haven't already explored them by then.  
I tend to sit on stuff like that for some time, sometimes years, then all 
of a sudden decide I happen to have the time and the inclination, and 
"just do it", generally with only a day or two's inkling I might be 
headed that way, if that.  My switch to grub2, trying lvm for a year or 
two, trying mdraid for several years, deploying ssds and btrfs here a few 
months ago, setting up bind, and setting up ntp, were all that way.  By 
contrast, my MS->Linux switch, my kmail->claws-mail conversion, my kde3-
>4 upgrade, and my konqueror->firefox switch, all were similarly 
intensive and ASAP focused action switches, but much more deliberatively 
planned ahead and generally undertaken as the externally forcing event 
came to pass. (After two years of planning, I actually began my full 
switch to Linux the week eXPrivacy came out, for instance, being 
similarly backed into a corner by MS as I was simply NOT going to give 
them their demanded remote root and possible deactivation rights, the 
same way I'm simply NOT going to have gentoo/kde dictate my semantic-
desktop policy, tho with lots of warning it was going to occur (as 
similarly I had months of warning of the gentoo/kde semantic-desktop 
policy change from project meeting announcements on the gentoo-desktop 
list, before I actually needed to deal with it, when the 4.11-beta1 
ebuilds came out), thus the two years...))

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

[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Duncan]

Duncan posted on Thu, 08 Aug 2013 08:27:58 +0000 as excerpted:

> Daniel Campbell posted on Thu, 08 Aug 2013 01:26:47 -0500 as excerpted:
> 
>> [Duncan wrote...]

Ooopps!  That too... WAS intended to be sent privately.

I goofed!  Sorry everyone!

(Note to self, change the followup BEFORE you start composing the reply, 
so you don't forget before hitting the send button! =:^(

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/08/2013 01:49 AM, Patrick Lauer wrote:
> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote:
>> On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
>>> Greetings,
>>>
>>> Gnome Herd decided to target stablilization of 3.8 [1] which requires
>>> systemd.
>>>
>>> What are the reasons to stable 3.8 and not 3.6, a version w/o this
>>> restriction, enabling all non systemd users to profit from this
>>> eye-candy as well.
>>>
>>> I raise the freedom of choice card here. And deliberately choosing an
>>> uncooperative version doesn't shine a good light.
>>>
>>> Facts, pls!
>>>
>>>    Michael
>>>
>>> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252
>>
>> To stabilize gnome-3.6, we would need
>> 1. one or (preferably) two *active* gentoo developers;
>> 2. who are familiar with gnome's internals and are able to backport
>> bugfixes from 3.8/3.10 without support from upstream developers; and
>> 3. who volunteer to run openrc+gnome-3.6 for a long time on their main
>> machines so that they can give a stable 3.6 the support that the word
>> 'stable' implies.
>>
>> We do not have such people on the gnome team.
>>
> 
> Seeing the noise in #gentoo from people getting whacked in the kidney by
> the systemd sidegrade ... that's a very optimistic decision.
> 
> It'll cause lots of pain for users that suddenly can't start lvm
> properly and other nasty landmines hidden in the "upgrade path". By
> stabilizing this early you're causing lots of extra work for others.
> 
> I hope you understand that some of us will be very rude and just suggest
> to unmerge gnome on all support requests as it now moves outside our
> support range ...
> 
> Have a nice day,
> 
> Patrick
> 
> 
> 

+1

Stabilizing it is wrong.

Leave it in ~arch forever, because it is incompatible with system
packages. (virtual/service-manager)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ben de Groot]

On 7 August 2013 20:45, Michael Weber <xmw@gentoo.org> wrote:
> Greetings,
>
> Gnome Herd decided to target stablilization of 3.8 [1] which requires
> systemd.
>
> What are the reasons to stable 3.8 and not 3.6, a version w/o this
> restriction, enabling all non systemd users to profit from this
> eye-candy as well.
>
> I raise the freedom of choice card here. And deliberately choosing an
> uncooperative version doesn't shine a good light.

People are free to use a saner desktop environment...

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 08 Aug 2013 11:29:06 +0200
hasufell <hasufell@gentoo.org> wrote:

> Leave it in ~arch forever, because it is incompatible with system
> packages. (virtual/service-manager)

But compatible with virtual/service-manager[-prefix,kernel_linux].

Jokes aside; I'm not aware of any requirement to be compatible with this
particular package, so I think a blocker would suffice for this matter.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/08/2013 08:21 AM, Duncan wrote:
> 
> None-the-less, I do understand the problem of a gentoo project supporting 
> an option no devs on the project are actually interested in running.  

I do not. If that is the policy, then the project is doing something wrong.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 8 Aug 2013 17:39:25 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 7 August 2013 20:45, Michael Weber <xmw@gentoo.org> wrote:
> > Gnome Herd decided to target stablilization of 3.8 [1] which
> > requires systemd.
> >
> > What are the reasons to stable 3.8 and not 3.6, a version w/o this
> > restriction, enabling all non systemd users to profit from this
> > eye-candy as well.
> >
> > I raise the freedom of choice card here. And deliberately choosing
> > an uncooperative version doesn't shine a good light.
> 
> People are free to use a saner desktop environment...

This thread is about stabilization, not about usage.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michał Górny]

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

Dnia 2013-08-08, o godz. 11:29:06
hasufell <hasufell@gentoo.org> napisał(a):

> On 08/08/2013 01:49 AM, Patrick Lauer wrote:
> > Seeing the noise in #gentoo from people getting whacked in the kidney by
> > the systemd sidegrade ... that's a very optimistic decision.
> > 
> > It'll cause lots of pain for users that suddenly can't start lvm
> > properly and other nasty landmines hidden in the "upgrade path". By
> > stabilizing this early you're causing lots of extra work for others.
> > 
> > I hope you understand that some of us will be very rude and just suggest
> > to unmerge gnome on all support requests as it now moves outside our
> > support range ...
> 
> +1
> 
> Stabilizing it is wrong.
> 
> Leave it in ~arch forever, because it is incompatible with system
> packages. (virtual/service-manager)

If it's going to stay in ~arch, we should also drop all stable GNOME
versions to ~arch. I don't really see keeping old and unsupported
software stable for that long.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 08/08/13 13:05, Michał Górny wrote:
> Dnia 2013-08-08, o godz. 11:29:06
> hasufell <hasufell@gentoo.org> napisał(a):
>
>> On 08/08/2013 01:49 AM, Patrick Lauer wrote:
>>> Seeing the noise in #gentoo from people getting whacked in the kidney by
>>> the systemd sidegrade ... that's a very optimistic decision.
>>>
>>> It'll cause lots of pain for users that suddenly can't start lvm
>>> properly and other nasty landmines hidden in the "upgrade path". By
>>> stabilizing this early you're causing lots of extra work for others.
>>>
>>> I hope you understand that some of us will be very rude and just suggest
>>> to unmerge gnome on all support requests as it now moves outside our
>>> support range ...
>>
>> +1
>>
>> Stabilizing it is wrong.
>>
>> Leave it in ~arch forever, because it is incompatible with system
>> packages. (virtual/service-manager)
>
> If it's going to stay in ~arch, we should also drop all stable GNOME
> versions to ~arch. I don't really see keeping old and unsupported
> software stable for that long.
>

+1, the old libraries gnome 2.x needs in stable is already causing trouble.
to name the first one that comes to mind, the stable gnome-base/gvfs 
gnome 2.x needs fails with UDisks2.
overall i'm not intrested in stabilization of gnome 3.x but getting rid 
of 'the blocker called gnome 2.x*

- Samuli

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 08/08/13 12:39, Ben de Groot wrote:
> On 7 August 2013 20:45, Michael Weber <xmw@gentoo.org> wrote:
>> Greetings,
>>
>> Gnome Herd decided to target stablilization of 3.8 [1] which requires
>> systemd.
>>
>> What are the reasons to stable 3.8 and not 3.6, a version w/o this
>> restriction, enabling all non systemd users to profit from this
>> eye-candy as well.
>>
>> I raise the freedom of choice card here. And deliberately choosing an
>> uncooperative version doesn't shine a good light.
>
> People are free to use a saner desktop environment...
>

/me points to XFCE that will *not* be removing ConsoleKit support, or 
require systemd
(however I'm going to append systemd support to 4.10, but the patches 
currently available are sub-par and none in upstream git yet)

does anyone know if Cinnamon, MATE, or whatever GNOME forks there are 
will keep ConsoleKit support or not?
i'm not volunteering but I never really got why our GNOME maintainers 
insisted on staying with it instead of going with the distribution after 
it was clear logind is a dead end on non-systemd systemd

- Samuli

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 5:43 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 08 Aug 2013 11:29:06 +0200
> hasufell <hasufell@gentoo.org> wrote:
>
>> Leave it in ~arch forever, because it is incompatible with system
>> packages. (virtual/service-manager)
>
> But compatible with virtual/service-manager[-prefix,kernel_linux].
>
> Jokes aside; I'm not aware of any requirement to be compatible with this
> particular package, so I think a blocker would suffice for this matter.

A blocker for what?

It should have a dependency on systemd if that is what is required.
Obviously that is not a dependency that can be satisfied on all
configurations, but that's what the dependency is.

I don't see what exactly gnome is doing that should require anything
else to be a block.  I don't think that gnome cares if you have openrc
or udev or whatever installed.  Now, _systemd_ might need to block
those packages if there are collisions.

Rich

Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 5:45 AM, hasufell <hasufell@gentoo.org> wrote:
> On 08/08/2013 08:21 AM, Duncan wrote:
>>
>> None-the-less, I do understand the problem of a gentoo project supporting
>> an option no devs on the project are actually interested in running.
>
> I do not. If that is the policy, then the project is doing something wrong.
>

Feel free to join it and do something right then.  :)

I don't know what it was costing them to support
USE=-semantic-desktop.  Their logic for no longer providing the option
was that the effects of the option were now configurable in the
control panel.  Granted, you'd still end up pulling in the deps, but
they wouldn't actually do anything.

I like being able to use kdepim (or would if it didn't prompt me to
re-authenticate with Google two factor on every login), so this is an
improvement.  I could see why others might want the flag to remain.
If it works and somebody is willing to proxy-maintain the necessary
elements to support it, they should be allowed to do so unless it
causes some other problem.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 8 Aug 2013 07:19:39 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Aug 8, 2013 at 5:43 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> > On Thu, 08 Aug 2013 11:29:06 +0200
> > hasufell <hasufell@gentoo.org> wrote:
> >
> >> Leave it in ~arch forever, because it is incompatible with system
> >> packages. (virtual/service-manager)
> >
> > But compatible with virtual/service-manager[-prefix,kernel_linux].
> >
> > Jokes aside; I'm not aware of any requirement to be compatible with
> > this particular package, so I think a blocker would suffice for
> > this matter.
> 
> A blocker for what?

No idea what incompatibility is being talked about, I wonder about that
as well; a dependency as you suggest, can act as a blocker as well, it
doesn't literally have to be blocking syntax but just a dependency that
would properly act in the same way. Otherwise said, an indirect blocker.

We are on the same line here.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Fabio Erculiani]

On Thu, Aug 8, 2013 at 1:49 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> Seeing the noise in #gentoo from people getting whacked in the kidney by
> the systemd sidegrade ... that's a very optimistic decision.

Yes it is, because our policy has always been to follow upstream as
much as possible. So your sarcasm is not fun.

>
> It'll cause lots of pain for users that suddenly can't start lvm
> properly and other nasty landmines hidden in the "upgrade path". By
> stabilizing this early you're causing lots of extra work for others.

How much time did you spend on trying to make GNOME 3.8 work with openrc?
Because I spent so much that I ended up suggesting the GNOME team to
require systemd.
And systemd is the only thing that at this time, properly works with
current and future GNOME releases. And GNOME 3.8 is at this time, only
fully working with systemd (fully: if you don't think you need to be
able to shutdown your computer and have proper session management...
well, I'd remove the "fully" word myself.)

Moreover, the lvm problem is caused by a very ancient and ill decision
about doing what upstream tells you to avoid: have mdev in the
initramfs and udev on the final pivot rooted system. This was just
looking for troubles but the smarties at the time decided that they
knew better... And now, tadam, the bug is served...
People can use genkernel-next, which comes with _proper_ udev support
(see --udev).

>
> I hope you understand that some of us will be very rude and just suggest
> to unmerge gnome on all support requests as it now moves outside our
> support range ...
>
> Have a nice day,
>
> Patrick
>
>



-- 
Fabio Erculiani

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> Moreover, the lvm problem is caused by a very ancient and ill decision
> about doing what upstream tells you to avoid: have mdev in the
> initramfs and udev on the final pivot rooted system. This was just
> looking for troubles but the smarties at the time decided that they
> knew better... And now, tadam, the bug is served...
> People can use genkernel-next, which comes with _proper_ udev support
> (see --udev).

I won't comment about the entire gnome monolithic windows like, vendor
controlled system that we cooperate with.

But the above statement is way too much... there should be nothing
wrong in having mdev during boot. initramfs should be simple as
possible and busybox provides this functionality well. The problem is
in udev not in any other component, that probably expects now to run
first and have total control over the boot process. I hope eudev does
not suffer from this.

If genkernel will start using udev instead of busybox, it will
probably be the last day of me use it.

I am just waiting for the point in which you claim that systemd should
be run at initramfs, because of the dependency lock-in, so you have
almost the entire system within initramfs.

Regards,
Alon

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/08/2013 10:01 PM, Fabio Erculiani wrote:
> On Thu, Aug 8, 2013 at 1:49 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>
>> Seeing the noise in #gentoo from people getting whacked in the kidney by
>> the systemd sidegrade ... that's a very optimistic decision.
> 
> Yes it is, because our policy has always been to follow upstream as
> much as possible. So your sarcasm is not fun.

What sarcasm?

Any users trying this sidegrade will be left without support and risk
being ridiculed by annoyed bystanders.

... and that's with our improved tolerant stance of, well, tolerating
this madness instead of Just Saying No.

>>
>> It'll cause lots of pain for users that suddenly can't start lvm
>> properly and other nasty landmines hidden in the "upgrade path". By
>> stabilizing this early you're causing lots of extra work for others.
> 
> How much time did you spend on trying to make GNOME 3.8 work with openrc?
I quit caring for gnome years ago, when every upgrade broke basic stuff
like icons, or copy&paste, and upstream actively removed the features I
relied on because You Don't Need That.

I have no interest in enabling such an abusive relationship.

> Because I spent so much that I ended up suggesting the GNOME team to
> require systemd.
> And systemd is the only thing that at this time, properly works with
> current and future GNOME releases. And GNOME 3.8 is at this time, only
> fully working with systemd (fully: if you don't think you need to be
> able to shutdown your computer and have proper session management...
> well, I'd remove the "fully" word myself.)

Well then, bye bye GnomeOS.

And to think that it wouldn't even be that much work for upstream to
allow deviant behaviour ... so much time and motivation lost for no real
reason.

Le Sigh :)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Fabio Erculiani]

On Thu, Aug 8, 2013 at 4:10 PM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
>> Moreover, the lvm problem is caused by a very ancient and ill decision
>> about doing what upstream tells you to avoid: have mdev in the
>> initramfs and udev on the final pivot rooted system. This was just
>> looking for troubles but the smarties at the time decided that they
>> knew better... And now, tadam, the bug is served...
>> People can use genkernel-next, which comes with _proper_ udev support
>> (see --udev).
>
> I won't comment about the entire gnome monolithic windows like, vendor
> controlled system that we cooperate with.
>
> But the above statement is way too much... there should be nothing
> wrong in having mdev during boot. initramfs should be simple as
> possible and busybox provides this functionality well. The problem is
> in udev not in any other component, that probably expects now to run
> first and have total control over the boot process. I hope eudev does
> not suffer from this.
>
> If genkernel will start using udev instead of busybox, it will
> probably be the last day of me use it.

Fellow developer, let me tell you one thing, go clone the git repo and
see how --udev is implemented and realize that mdev is still supported
as it was before.

>
> I am just waiting for the point in which you claim that systemd should
> be run at initramfs, because of the dependency lock-in, so you have
> almost the entire system within initramfs.

While it may have several advantages, there is no pressing need in
supporting systemd in the initramfs for now.

>
> Regards,
> Alon
>



-- 
Fabio Erculiani

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ben Kohler]

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

On Thu, Aug 8, 2013 at 9:17 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>
>
> Any users trying this sidegrade will be left without support and risk
> being ridiculed by annoyed bystanders.
>
>
There are many of us supporting systemd + gnome 3.8 in #gentoo right now
today, and I am strongly discouraging this "ridicule".  We also discourage
ridicule when someone asks for support on KDE, Gnome, Pulseaudio,
NetworkManager, proprietary drivers, or any of the other packages that tend
to draw such polar opinions-- but are fully supported.

I do think it's a good idea to get all this out in the open though-- make
sure users know exactly what they're getting into, how much it's going to
turn their gentoo world upside down (for a day or 2), WHY this is
happening, and what the alternatives are.  Most of this has been covered in
this thread already.  But it's not unsupported just because some people
don't know how (or have no desire) to support it.

As for the stabilization issue-- it seems like most people against
stabilization just want ~arch as a barrier or "whoa, wait up a sec" warning
to stable users don't stumble upon systemd, which makes sense.  But I think
there are better ways to accomplish this, rather than abusing keywords.

-Ben

[-- Attachment #2: Type: text/html, Size: 1829 bytes --]

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michał Górny]

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

Dnia 2013-08-08, o godz. 17:10:24
Alon Bar-Lev <alonbl@gentoo.org> napisał(a):

> On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> > Moreover, the lvm problem is caused by a very ancient and ill decision
> > about doing what upstream tells you to avoid: have mdev in the
> > initramfs and udev on the final pivot rooted system. This was just
> > looking for troubles but the smarties at the time decided that they
> > knew better... And now, tadam, the bug is served...
> > People can use genkernel-next, which comes with _proper_ udev support
> > (see --udev).
> 
> I won't comment about the entire gnome monolithic windows like, vendor
> controlled system that we cooperate with.
> 
> But the above statement is way too much... there should be nothing
> wrong in having mdev during boot. initramfs should be simple as
> possible and busybox provides this functionality well. The problem is
> in udev not in any other component, that probably expects now to run
> first and have total control over the boot process. I hope eudev does
> not suffer from this.

Thanks for your insight. I see you really took a while to do that
research and give us the answers we were seeking. Your help improving
Gentoo is much appreciated.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/08/2013 04:34 PM, Ben Kohler wrote:
> 
> As for the stabilization issue-- it seems like most people against
> stabilization just want ~arch as a barrier or "whoa, wait up a sec" warning
> to stable users don't stumble upon systemd, which makes sense.  But I think
> there are better ways to accomplish this, rather than abusing keywords.
> 

That has nothing to do with abusing keywords.

Gentoo supports systemd, fine. Still, OpenRC is our default
implementation and I don't think something should be called stable _on
gentoo_ that doesn't work with the system tools we have designed and
advertise.

If it works with both, then it's fine.

Let me quote myself from another thread:

> Maintaining a package in gentoo implies a few things for me:
> We are able to support it properly which either means that we can
> communicate with upstream or at least (if that fails) fix bugs on our
> own.

There is nothing "properly" about forcing a particular init system,
upstream obviously doesn't care and our own devs gave up on trying to
fix it.
So nothing of that seems to apply here.

[gentoo-dev] Re: KDE/semantic-desktop

[Martin Vaeth]

Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>
> answer is about 10 additional megs of ram at idle
> and about 2 extra seconds to boot.

huge waste of compile time (not so much for KDE but more for the
databases), opening to all sort of possible attacks by bugs in these
databases whose servers need to be running etc.

I doubt that if you count these servers the difference is only 10 megs.
And on my machines with 512 MB RAM also losing 10 megs of RAM for
nothing (well - for increasing the attack vector) is an issue.

For "Take the full bloat or nothing" one can better choose a
binary distribution.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[William Hubbs]

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

On Thu, Aug 08, 2013 at 01:19:34AM -0500, Daniel Campbell wrote:
> On 08/07/2013 10:16 AM, Pacho Ramos wrote:
> > Also, I think we should stop spending a lot of time trying to keep it
> > working with openrc, we simply don't have resources to do that at the
> > moment (even Debian/Ubuntu people are stick with systemd-204 because
> > they don't have resources to keep logind working without systemd in
> > newer versions). Now, we are needing to put a lot of effort on trying to
> > provide unit files and provide systemd related fixes in the tree because
> > we haven't (in general) pay attention to systemd at all => I think we
> > should put more efforts on it than trying to work on hacks to prevent
> > systemd dependency.
> 
> I agree that there's no point in hacking software that voluntarily ties
> itself to systemd to *not* be tied to it, but dependency on any single
> init system is a bad idea. There are multiple kernels, multiple libc's,
> multiple device management layers, multiple inits, etc. Preventing
> dependency on certain things is a good way to enforce software diversity.
> 
> Granted, in systemd's case Gentoo's not the place to do it. It's the
> upstreams that should be convinced or told not to depend on a single
> init system.

As the primary upstream for OpenRc, I can assure you that work on it is
not stopping; OpenRc isn't dead.

I agree with this position too though. It isn't up to the gentoo teams
to try to force things like gnome-3.8 to work with OpenRc; the upstream
projects should be convinced that depending on systemd (or any other
init system specifically) is not a good idea.

William


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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Damien Levac]

Just a user point of view:

When a user decide to restrict the packages on his system to "stable", I
think the user expect stability in the sense works properly under most
(if not all) situations.
Therefore, for a user, if real stability demand a lot of restriction, it
is a price to pay. I think it would be harsh to stabilize buggy software
just because it is able to run with the distro defaults (especially when
defaults mean so little to a distro about freedom of choices). At the
very least, if stabilization of 3.6 is really something a lot of people
here are looking forward for, it should probably be a fork since the
work required to maintain it will be that of a full project anyways
(i.e. call it gentoo-gnome or something similar).

Also, I think the problem here is more idealogy than anything else,
people who do care about keeping OpenRC should leave Gnome IMHO (like I
did myself), I mean they will need to switch to systemd or change
environement in the future anyways. Because, even a gentoo-gnome project
won't have the manpower upstream gnome and upstream systemd have and
will probably be full of frustration for users...

Damien

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 08 Aug 2013 16:56:16 +0200
hasufell <hasufell@gentoo.org> wrote:

> Gentoo supports systemd, fine. Still, OpenRC is our default
> implementation and I don't think something should be called stable _on
> gentoo_ that doesn't work with the system tools we have designed and
> advertise.

Gentoo advertises choice [1]; if it advertises OpenRC, state where. 

 [1]: http://www.gentoo.org/main/en/about.xml
      "for just about any application or need"

      http://www.gentoo.org/main/en/philosophy.xml
      "as they see fit"

      http://www.gentoo.org/doc/en/faq.xml#differences
      "You have complete control over what packages are or aren't
      installed. Gentoo provides you with numerous choices, so you can
      install Gentoo to your own preferences, which is why Gentoo is
      called a meta-distribution."

None of these advertise OpenRC or that things do need to work with it.

> Let me quote myself from another thread:
> 
> > Maintaining a package in gentoo implies a few things for me:
> > We are able to support it properly which either means that we can
> > communicate with upstream or at least (if that fails) fix bugs on
> > our own.
> 
> There is nothing "properly" about forcing a particular init system,

That's just your opinion, it depends on how you define "properly"; not
all combination of choices are possible, incompatibility with packages
that can be replaced has never been a reason to not maintain a package.
If it is a reason that has been agreed on; then, please state where.

> upstream obviously doesn't care and our own devs gave up on trying to
> fix it.
>
> So nothing of that seems to apply here.

Why does it need to apply? Without reference, what does the quote mean?

Even if it did; the package is maintained, so this is not a problem...

Can we please stop brainstorming subjective reasons that block choice?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 10:56 AM, hasufell <hasufell@gentoo.org> wrote:
> Gentoo supports systemd, fine. Still, OpenRC is our default
> implementation and I don't think something should be called stable _on
> gentoo_ that doesn't work with the system tools we have designed and
> advertise.

If a package requires libav should it never be stabilized, because
ffmpeg is the default on that virtual?  How about something that only
supports vim or emacs, since nano is our default editor (something
chosen as much for its size as the fact that everybody can agree that
it isn't either vim or emacs)?

OpenRC is just one init system that Gentoo supports.  Gentoo does not
require the use of OpenRC any more than it requires the use of portage
as the package manager.

Honestly, we're probably getting to the point where we should offer a
choice of init systems in our handbook.  It doesn't make sense for
Gnome users to go configuring openrc in the handbook only to throw out
all that work and start over with systemd.

Don't get me wrong - there is nothing wrong with using OpenRC.  There
is just not anything special about it any longer.  It is still common
in the same way that baselayout-1 was common before it.  It may or may
not ever go away.  However, it seems likely to me that the percentage
of Gentoo systems that have systemd installed is only going to rise,
and we need to deal with that.  That isn't a choice we'll force on our
users, but we can't really stop upstream from doing so.  Right now I
run both, in the future, I'm not so sure.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ian Stakenvicius]

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

On 08/08/13 11:16 AM, Damien Levac wrote:
> Just a user point of view:
> 
> When a user decide to restrict the packages on his system to
> "stable", I think the user expect stability in the sense works
> properly under most (if not all) situations.

That makes a lot of sense, and on that basis keeping gnome-3.8+ in
~arch is probably not warranted.  HOWEVER, part of keeping things
stable is also a stable upgrade path, and -at least at this point- it
is -not- trivial to go from gnome-2/openrc to gnome-3.8/systemd
without a fair bit of work on the part of the end-user.

Before anything does go stable, I implore our gnome devs to provide
cut-and-paste level instructions to do the upgrade, or provide a tool
to help significantly (if not fully) automate the process.  Our stable
users should be able to emerge -uDN without spending massive amounts
of time and who-knows-how-many reboots to resolve the blockages.

It may be pertinent for this reason (a "smoother" upgrade path) and
this reason alone, to stabilize gnome-3.6 first -- just to get into
gnome3 (and get gnome-2 removed) without having to also deal with the
systemd migration at the same time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlIDvAoACgkQ2ugaI38ACPC8WQD/cUNKSx0mf6ELG77RWOfwresP
2zjG+sPTvQhiZtZd2PsA/ipgGei3j/CmcJooORwqjl3w9eztr90tSeTaoHtm+gdh
=LGcF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 08 Aug 2013 11:40:58 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 08/08/13 11:16 AM, Damien Levac wrote:
> > Just a user point of view:
> > 
> > When a user decide to restrict the packages on his system to
> > "stable", I think the user expect stability in the sense works
> > properly under most (if not all) situations.
> 
> That makes a lot of sense, and on that basis keeping gnome-3.8+ in
> ~arch is probably not warranted.  HOWEVER, part of keeping things
> stable is also a stable upgrade path, and -at least at this point- it
> is -not- trivial to go from gnome-2/openrc to gnome-3.8/systemd
> without a fair bit of work on the part of the end-user.

Introducing a new profile [1] to easy the switch in configuration, an
explanation what is being replaced by what, why, and steps to follow;
shouldn't be too hard to follow. When I switched, it wasn't too much.

 [1]: https://bugs.gentoo.org/show_bug.cgi?id=479986
      Please provide a Gnome3 profile enabling "systemd" USE flag

While the bug doesn't mention the other details; this could also include
the other things like disabling the consolekit USE flag, and so on...

> Before anything does go stable, I implore our gnome devs to provide
> cut-and-paste level instructions to do the upgrade, or provide a tool
> to help significantly (if not fully) automate the process.  Our stable
> users should be able to emerge -uDN without spending massive amounts
> of time and who-knows-how-many reboots to resolve the blockages.

+1

> It may be pertinent for this reason (a "smoother" upgrade path) and
> this reason alone, to stabilize gnome-3.6 first -- just to get into
> gnome3 (and get gnome-2 removed) without having to also deal with the
> systemd migration at the same time.

The problem is that GNOME 3.6 is broken for a set of people; which will
cause a lot of unnecessary troubleshooting and bugs, for things that
are already fixed in GNOME 3.8. I'm not convinced that this is smoother.

The concept to not stabilize something you know is more broken applies.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

iQEcBAEBAgAGBQJSA74kAAoJEJWyH81tNOV9pAEH/iyo5cOBKSI9X4Xgh3Eor+N+
glBGplKMgDI15KQISHyhCQSeE9HxKLqNdUcHMob4v9dHHAtKCQP8GV9T3ngfeBiK
e2HW/JPD8N6eFfBYnlakKVSI37bhMuTLRgQ8n6WSmhIy8lT/kZtdIo6KNeF4vxIU
FBRxNIUO5fuZJX4gm7gtmBrPWgfnoQi/+N2sgLjuMewKemg+mHLXA7wUPzAN2y2n
RFY+beNG/O8JpP3KZoMysAndzx39WSdgKYWddqPA7xoG+4iy3Msg6Gn+7tOsSFxQ
wcpsoWkDaBXi5arMl3xihcm/1c5Dv75VpUWw09b+r3bkiE5tiiBYi8ryB60iqzo=
=qpn9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El jue, 08-08-2013 a las 11:40 -0400, Ian Stakenvicius escribió:
[...]
> That makes a lot of sense, and on that basis keeping gnome-3.8+ in
> ~arch is probably not warranted.  HOWEVER, part of keeping things
> stable is also a stable upgrade path, and -at least at this point- it
> is -not- trivial to go from gnome-2/openrc to gnome-3.8/systemd
> without a fair bit of work on the part of the end-user.
> 
> Before anything does go stable, I implore our gnome devs to provide
> cut-and-paste level instructions to do the upgrade, or provide a tool
> to help significantly (if not fully) automate the process.  Our stable
> users should be able to emerge -uDN without spending massive amounts
> of time and who-knows-how-many reboots to resolve the blockages.
> 

We are working on it, I am spending *a lot of effort* on making
transition smoother, oh please, I am also trying to help systemd team
with my limited knowledge about systemd to try to improve situation.

There will be an upgrade guide (as has been the case for *all* gnome
releases), we are working on improving gnome profile defaults and many
more.

Please stop making all lose our time discussing this forever here, we
are not going to stabilize Gnome 3.8 without providing that "cut and
paste level instructions"

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 11:40 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> It may be pertinent for this reason (a "smoother" upgrade path) and
> this reason alone, to stabilize gnome-3.6 first -- just to get into
> gnome3 (and get gnome-2 removed) without having to also deal with the
> systemd migration at the same time.

I'd defer to Pacho who seems to be giving thought to planning for the
upgrade path.

My suggestion would be that it would make more sense to first switch
to systemd running the current gnome.  Switching to systemd is really
the harder change here, and systemd works just fine with earlier
versions of gnome AFAIK.  There are already migration guides for
systemd (though I haven't tried them recently - the last time I did I
got burned by the fact that dhcpcd doesn't run by default as it does
in openrc-oldnet (or whatever we're going to call it)).  Migrating to
systemd on a system that doesn't run many services isn't actually that
hard.  The biggest pain is hunting down unit files if you have a lot
of things that don't provide them, and doing all the config (anything
in /etc/conf.d basically needs a redo).

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alex Xu]

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

On 08/08/13 11:26 AM, Rich Freeman wrote:
> Honestly, we're probably getting to the point where we should offer a
> choice of init systems in our handbook.  It doesn't make sense for
> Gnome users to go configuring openrc in the handbook only to throw out
> all that work and start over with systemd.

The only lingering problem is that bug 373219, after over 2 years, is
still not fixed in-tree.

"wget https://bugs.gentoo.org/attachment.cgi?id=303775 -O
/etc/init.d/functions.sh" should not be part of the handbook.


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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[William Hubbs]

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

On Thu, Aug 08, 2013 at 12:05:02PM -0400, Alex Xu wrote:
> On 08/08/13 11:26 AM, Rich Freeman wrote:
> > Honestly, we're probably getting to the point where we should offer a
> > choice of init systems in our handbook.  It doesn't make sense for
> > Gnome users to go configuring openrc in the handbook only to throw out
> > all that work and start over with systemd.
> 
> The only lingering problem is that bug 373219, after over 2 years, is
> still not fixed in-tree.

I am working on this, along with the release of OpenRc-0.12. They have
to happen at the same time basically because of the
/etc/init.d/functions.sh symbolic link.

William


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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El jue, 08-08-2013 a las 12:02 -0400, Rich Freeman escribió:
> On Thu, Aug 8, 2013 at 11:40 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> > It may be pertinent for this reason (a "smoother" upgrade path) and
> > this reason alone, to stabilize gnome-3.6 first -- just to get into
> > gnome3 (and get gnome-2 removed) without having to also deal with the
> > systemd migration at the same time.
> 
> I'd defer to Pacho who seems to be giving thought to planning for the
> upgrade path.
> 
> My suggestion would be that it would make more sense to first switch
> to systemd running the current gnome.  Switching to systemd is really
> the harder change here, and systemd works just fine with earlier
> versions of gnome AFAIK.  There are already migration guides for
> systemd (though I haven't tried them recently - the last time I did I
> got burned by the fact that dhcpcd doesn't run by default as it does
> in openrc-oldnet (or whatever we're going to call it)).  Migrating to
> systemd on a system that doesn't run many services isn't actually that
> hard.  The biggest pain is hunting down unit files if you have a lot
> of things that don't provide them, and doing all the config (anything
> in /etc/conf.d basically needs a redo).
> 
> Rich
> 
> 

In my case, I updated from 2.32 to 3.7.9x and, some weeks ago, moved
from openrc to systemd. I don't know how is systemd working with 2.32
then. 

My idea would be to suggest to do all at the same time -> once all is
ready and Gnome 3.8 is stabilized, people will see a news item telling
them that they need to update their systems (telling them how to skip
blockers and such things) and pointing them to migrate to systemd after
that (and finally reboot).

Regarding the blockers, we are working about how to handle them in a
better way currently (or, at least, explain people how to skip them).
About migration to systemd, I have followed:
http://wiki.gentoo.org/wiki/Systemd

without any problems. Most of the problems comes from packages still not
providing unit files in their stable versions (that tries to be covered
in https://bugs.gentoo.org/show_bug.cgi?id=unit-in-stable before Gnome
3.8 hits stable, that way people will have a better working systemd
setup)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ian Stakenvicius]

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

On 08/08/13 12:13 PM, Pacho Ramos wrote:
> El jue, 08-08-2013 a las 12:02 -0400, Rich Freeman escribió:
>> On Thu, Aug 8, 2013 at 11:40 AM, Ian Stakenvicius
>> <axs@gentoo.org> wrote:
>>> It may be pertinent for this reason (a "smoother" upgrade path)
>>> and this reason alone, to stabilize gnome-3.6 first -- just to
>>> get into gnome3 (and get gnome-2 removed) without having to
>>> also deal with the systemd migration at the same time.
>> 
>> I'd defer to Pacho who seems to be giving thought to planning for
>> the upgrade path.
>> 
>> My suggestion would be that it would make more sense to first
>> switch to systemd running the current gnome.  Switching to
>> systemd is really the harder change here, and systemd works just
>> fine with earlier versions of gnome AFAIK.  There are already
>> migration guides for systemd (though I haven't tried them
>> recently - the last time I did I got burned by the fact that
>> dhcpcd doesn't run by default as it does in openrc-oldnet (or
>> whatever we're going to call it)).  Migrating to systemd on a
>> system that doesn't run many services isn't actually that hard.
>> The biggest pain is hunting down unit files if you have a lot of
>> things that don't provide them, and doing all the config
>> (anything in /etc/conf.d basically needs a redo).
>> 
>> Rich
>> 
>> 
> 
> In my case, I updated from 2.32 to 3.7.9x and, some weeks ago,
> moved from openrc to systemd. I don't know how is systemd working
> with 2.32 then.
> 
> My idea would be to suggest to do all at the same time -> once all
> is ready and Gnome 3.8 is stabilized, people will see a news item
> telling them that they need to update their systems (telling them
> how to skip blockers and such things) and pointing them to migrate
> to systemd after that (and finally reboot).
> 
> Regarding the blockers, we are working about how to handle them in
> a better way currently (or, at least, explain people how to skip
> them). About migration to systemd, I have followed: 
> http://wiki.gentoo.org/wiki/Systemd
> 
> without any problems. Most of the problems comes from packages
> still not providing unit files in their stable versions (that tries
> to be covered in
> https://bugs.gentoo.org/show_bug.cgi?id=unit-in-stable before
> Gnome 3.8 hits stable, that way people will have a better working
> systemd setup)
> 
> 

Somewhat related question -- a new(?) profile was mentioned as being
required for gnome-3 ; if this is definitely happening, would it be a
good idea to mask gnome in the other profiles?  Would that help with
the migration or just cause more issues?



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

iF4EAREIAAYFAlIDxTEACgkQ2ugaI38ACPABEAD+JgMjEw4WiGKDQyaJdrywG5xr
Tlg2+rx1WB4L+11neHoBAKGp4UxYGUkOECigN9WB7JcbUfTpyJBCWtxjtH/oNNP2
=nUmi
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El jue, 08-08-2013 a las 12:20 -0400, Ian Stakenvicius escribió:
[...]
> Somewhat related question -- a new(?) profile was mentioned as being
> required for gnome-3 ; if this is definitely happening, would it be a
> good idea to mask gnome in the other profiles?  Would that help with
> the migration or just cause more issues?
> 

I don't think any change on other profiles is needed: the new gnome3
profile would simply enable "systemd" USE flag, mask the "static-libs"
for virtual/udev and co... and we are still seeing what more could be
needed to improve the upgrade path

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/08/2013 05:23 PM, Tom Wijsman wrote:
> On Thu, 08 Aug 2013 16:56:16 +0200
> hasufell <hasufell@gentoo.org> wrote:
> 
>> Gentoo supports systemd, fine. Still, OpenRC is our default
>> implementation and I don't think something should be called stable _on
>> gentoo_ that doesn't work with the system tools we have designed and
>> advertise.
> 
> Gentoo advertises choice [1]; if it advertises OpenRC, state where. 
> 
>  [1]: http://www.gentoo.org/main/en/about.xml
>       "for just about any application or need"
> 
>       http://www.gentoo.org/main/en/philosophy.xml
>       "as they see fit"
> 
>       http://www.gentoo.org/doc/en/faq.xml#differences
>       "You have complete control over what packages are or aren't
>       installed. Gentoo provides you with numerous choices, so you can
>       install Gentoo to your own preferences, which is why Gentoo is
>       called a meta-distribution."
> 
> None of these advertise OpenRC or that things do need to work with it.

Look into stage3.

> 
>> Let me quote myself from another thread:
>>
>>> Maintaining a package in gentoo implies a few things for me:
>>> We are able to support it properly which either means that we can
>>> communicate with upstream or at least (if that fails) fix bugs on
>>> our own.
>>
>> There is nothing "properly" about forcing a particular init system,
> 
> That's just your opinion, it depends on how you define "properly";

I just defined it. Read my quote again.

> not
> all combination of choices are possible, incompatibility with packages
> that can be replaced has never been a reason to not maintain a package.
> If it is a reason that has been agreed on; then, please state where.

I am only talking about stabilization here, maybe that wasn't clear enough?

The virtual is in @system and the default pre-installed implementation
is INCOMPATIBLE with gnome-3.8. Until that is solved (in what way I
don't care), then it should not enter stable arch.



On 08/08/2013 05:26 PM, Rich Freeman wrote:
> OpenRC is just one init system that Gentoo supports.  Gentoo does not
> require the use of OpenRC any more than it requires the use of portage
> as the package manager.

So would you stabilize a package that works with paludis, but not with
portage? Ouch. It should probably not be in the tree in the first place,
but I that's not what I have in mind here.

I generally expect packages to work with... now be surprised... BOTH
init systems, although I don't like systemd. If it doesn't work with
one, then it's a bug. Bugs block stabilization.
It is a _REGRESSION_. Ask the arch team about the meaning of regression
if unsure.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El jue, 08-08-2013 a las 18:36 +0200, hasufell escribió:
[...]
> I am only talking about stabilization here, maybe that wasn't clear enough?
> 
> The virtual is in @system and the default pre-installed implementation
> is INCOMPATIBLE with gnome-3.8. Until that is solved (in what way I
> don't care), then it should not enter stable arch.

You simply need to install the basic stuff and, before installing Gnome,
install systemd, follow the guide and that is all. Did you even tried to
do that?

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/08/2013 06:48 PM, Pacho Ramos wrote:
> El jue, 08-08-2013 a las 18:36 +0200, hasufell escribió:
> [...]
>> I am only talking about stabilization here, maybe that wasn't clear enough?
>>
>> The virtual is in @system and the default pre-installed implementation
>> is INCOMPATIBLE with gnome-3.8. Until that is solved (in what way I
>> don't care), then it should not enter stable arch.
> 
> You simply need to install the basic stuff and, before installing Gnome,
> install systemd, follow the guide and that is all. Did you even tried to
> do that?
> 
> 
> 

http://blogs.gentoo.org/ago/2012/08/22/when-you-should-block-a-stabilization/

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 08 Aug 2013 18:36:24 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 08/08/2013 05:23 PM, Tom Wijsman wrote:
>
> Look into stage3.
> 

Not sure which bits or bytes of stage3 you are referring to; but it
coming as default doesn't mean that it advertises it. What's so
problematic about replacing something that comes by default?

Ignoring defaults, incompatibility doesn't really matter...

Should we block stabilization of newer kernels or nvidia-drivers just
because they aren't present in stage3, incompatible with each other; I
think not. The case for systemd and GNOME 3.8 shouldn't be different...

> >> Let me quote myself from another thread:
> >>
> >>> Maintaining a package in gentoo implies a few things for me:
> >>> We are able to support it properly which either means that we can
> >>> communicate with upstream or at least (if that fails) fix bugs on
> >>> our own.
> >>
> >> There is nothing "properly" about forcing a particular init system,
> > 
> > That's just your opinion, it depends on how you define "properly";
> 
> I just defined it. Read my quote again.

I did not state you did not define it, your definition is your opinion;
in my opinion there's no problem with upstream choosing for systemd.

Why should upstream drop progress for supporting a minority anyway?

> > not
> > all combination of choices are possible, incompatibility with
> > packages that can be replaced has never been a reason to not
> > maintain a package. If it is a reason that has been agreed on;
> > then, please state where.
> 
> I am only talking about stabilization here, maybe that wasn't clear
> enough?

You've stated that the quote doesn't apply, which is about maintenance.

> The virtual is in @system and the default pre-installed implementation
> is INCOMPATIBLE with gnome-3.8. Until that is solved (in what way I
> don't care), then it should not enter stable arch.

Thanks for pointing that out; sounds like something our GNOME team wants
to look into, though I wonder if it really is a problem if the upgrade
path will just deal with this matter.

> On 08/08/2013 05:26 PM, Rich Freeman wrote:
> > OpenRC is just one init system that Gentoo supports.  Gentoo does
> > not require the use of OpenRC any more than it requires the use of
> > portage as the package manager.
> 
> So would you stabilize a package that works with paludis, but not with
> portage? Ouch. It should probably not be in the tree in the first
> place, but I that's not what I have in mind here.

This isn't a good example, because the PMS compliance governs over this.

> I generally expect packages to work with... now be surprised... BOTH
> init systems, although I don't like systemd. If it doesn't work with
> one, then it's a bug. Bugs block stabilization.
> It is a _REGRESSION_. Ask the arch team about the meaning of
> regression if unsure.

It's not a regression; actually, it's quite common to drop features
that can no longer be supported. I don't see us blocking stabilization
for other cases in the Portage tree where a feature has been dropped.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ian Stakenvicius]

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

On 08/08/13 12:24 PM, Pacho Ramos wrote:
> El jue, 08-08-2013 a las 12:20 -0400, Ian Stakenvicius escribió: 
> [...]
>> Somewhat related question -- a new(?) profile was mentioned as
>> being required for gnome-3 ; if this is definitely happening,
>> would it be a good idea to mask gnome in the other profiles?
>> Would that help with the migration or just cause more issues?
>> 
> 
> I don't think any change on other profiles is needed: the new
> gnome3 profile would simply enable "systemd" USE flag, mask the
> "static-libs" for virtual/udev and co... and we are still seeing
> what more could be needed to improve the upgrade path
> 

I was thinking more for an easier way to handle emerge -uDN @world for
end-users with gnome2 installed but that don't want to immediately
switch to systemd and gnome3 to get the rest of their updates.  If the
package(s) are masked by profile and so the -uDN doesn't do the
upgrade until after the profile is switched, this might provide the
end users with time to prepare themselves while still keeping the rest
of their world up-to-date and not needing to mess with package.mask in
the meantime.



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

iF4EAREIAAYFAlIDzjYACgkQ2ugaI38ACPCZDgD7BfBFfsBKDYPa6SEo3o9J8l51
gVVhQAT19txT2gFRAQoA/2fJn2OZJDUGvAwRPcaY2RDgclpqsgLSn3JEH2QhiogE
=loRa
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El jue, 08-08-2013 a las 18:52 +0200, hasufell escribió:
> On 08/08/2013 06:48 PM, Pacho Ramos wrote:
> > El jue, 08-08-2013 a las 18:36 +0200, hasufell escribió:
> > [...]
> >> I am only talking about stabilization here, maybe that wasn't clear enough?
> >>
> >> The virtual is in @system and the default pre-installed implementation
> >> is INCOMPATIBLE with gnome-3.8. Until that is solved (in what way I
> >> don't care), then it should not enter stable arch.
> > 
> > You simply need to install the basic stuff and, before installing Gnome,
> > install systemd, follow the guide and that is all. Did you even tried to
> > do that?
> > 
> > 
> > 
> 
> http://blogs.gentoo.org/ago/2012/08/22/when-you-should-block-a-stabilization/
> 
> 

And? We explain people how to migrate to systemd, pointing to the guide
from packages currently not completely working with openrc

(We..., or at least I, are not bots, we should be able to think)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 12:53 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 08 Aug 2013 18:36:24 +0200
> hasufell <hasufell@gentoo.org> wrote:
>> On 08/08/2013 05:26 PM, Rich Freeman wrote:
>> > OpenRC is just one init system that Gentoo supports.  Gentoo does
>> > not require the use of OpenRC any more than it requires the use of
>> > portage as the package manager.
>>
>> So would you stabilize a package that works with paludis, but not with
>> portage? Ouch. It should probably not be in the tree in the first
>> place, but I that's not what I have in mind here.
>
> This isn't a good example, because the PMS compliance governs over this.
>

PMS really only covers the format of the ebuilds themselves, and stuff
like built-in functions that these rely on - the interface between
ebuilds and package managers.

If you have some fancy utility that edits config files (like a
USE-flag editor) then PMS won't cover that.  The meaning of a USE flag
is covered by PMS, but how you tell the package manager what flags to
use is not.

Right now paludis doesn't have any stable versions.  I would not have
a problem with that changing, and if it did I'd have no problem with
having other stable packages that require paludis.  I would have a
problem with ebuilds that don't follow PMS, but if somebody has a
helper utility or front-end or something that is paludis-oriented I
see no reason it couldn't be in the tree.  We already have PM-agnostic
utilities, like python-updater.

We provide sensible defaults, and right now OpenRC is the most
sensible default.  That doesn't mean that things that require systemd
or something else can't be stable.

Stability is about the quality of the ebuilds and the user experience
in general.  It is not a statement that all Gentoo developers think
that the package is useful.  Many would say that nobody should be
using MySQL/MariaDB for production work, but that has nothing to do
with its stability as a package either.

Rich

[gentoo-dev] Re: KDE/semantic-desktop

[Martin Vaeth]

Sorry for reposting: Somehow the first line got lost
making the whole posting not understandable...

Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>
> answer is about 10 additional megs of ram at idle
> and about 2 extra seconds to boot.

..and two huge database servers which lots of disk and ram space and a
huge waste of compile time (not so much for KDE but more for the
databases), opening to all sort of possible attacks by bugs in these
databases whose servers need to be running etc.

I doubt that if you count these servers the difference is only 10 megs.
And on my machines with 512 MB RAM also losing 10 megs of RAM for
nothing (well - for increasing the attack vector) is an issue.

For "Take the full bloat or nothing" one can better choose a
binary distribution.

Re: [gentoo-dev] Re: KDE/semantic-desktop

[Rich Freeman]

On Thu, Aug 8, 2013 at 1:44 PM, Martin Vaeth
<vaeth@mathematik.uni-wuerzburg.de> wrote:
> Sorry for reposting: Somehow the first line got lost
> making the whole posting not understandable...
>
> Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>>
>> answer is about 10 additional megs of ram at idle
>> and about 2 extra seconds to boot.
>
> ..and two huge database servers which lots of disk and ram space and a
> huge waste of compile time (not so much for KDE but more for the
> databases), opening to all sort of possible attacks by bugs in these
> databases whose servers need to be running etc.
>

Do those servers still run if you disable the features in the control
panel?  I already run MySQL so the only annoyance for me was getting
it to use the existing instance rather than spawning a new one.

If somebody is willing to join the KDE team to support keeping that
option (even as a proxy maintainer) I think the team should work with
them.  I think that we should generally offer any choice as long as
somebody steps up to support it properly (and I do mean properly).
While I'm sure the KDE team has their faults they do announce their
meetings/etc and I suspect it would be an easy team for an outsider to
get involved with as a result.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
> Stability is about the quality of the ebuilds and the user experience
> in general.  It is not a statement that all Gentoo developers think
> that the package is useful.  Many would say that nobody should be
> using MySQL/MariaDB for production work, but that has nothing to do
> with its stability as a package either.

This is not entirely correct.

If from now on, a bug with systemd of new version of a package blocks
that package stabilization, it means that all developers must support
systemd. So having systemd stable is a decision that should be made by
the entire community, and have huge overhead on us all.

So apart of the politic message, there are implications of maintenance
efforts, stabilization efforts.

I appreciate the discussion at debian, it is not wise to support [I am
adding: at stable] more than one solution for layout.

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 12:52 PM, hasufell <hasufell@gentoo.org> wrote:
> On 08/08/2013 06:48 PM, Pacho Ramos wrote:
>> El jue, 08-08-2013 a las 18:36 +0200, hasufell escribió:
>> [...]
>>> I am only talking about stabilization here, maybe that wasn't clear enough?
>>>
>>> The virtual is in @system and the default pre-installed implementation
>>> is INCOMPATIBLE with gnome-3.8. Until that is solved (in what way I
>>> don't care), then it should not enter stable arch.
>>
>> You simply need to install the basic stuff and, before installing Gnome,
>> install systemd, follow the guide and that is all. Did you even tried to
>> do that?
>
> http://blogs.gentoo.org/ago/2012/08/22/when-you-should-block-a-stabilization/
>

I don't see how that article is related to the issue at hand - this
isn't about a regression, but about alternative implementations that
block each other.  I'm not saying that an upgrade guide shouldn't be
in place (nobody is saying that - the Gnome team just committed to
having one).

That said, ago's article is an excellent one, and I only wish the QA
at my workplace actually appreciated this sort of thing.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 08/08/13 20:57, Alon Bar-Lev wrote:
> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> Stability is about the quality of the ebuilds and the user experience
>> in general.  It is not a statement that all Gentoo developers think
>> that the package is useful.  Many would say that nobody should be
>> using MySQL/MariaDB for production work, but that has nothing to do
>> with its stability as a package either.
>
> This is not entirely correct.
>
> If from now on, a bug with systemd of new version of a package blocks
> that package stabilization, it means that all developers must support
> systemd. So having systemd stable is a decision that should be made by
> the entire community, and have huge overhead on us all.

That's not really true with systemd when the unit files (and related) 
are in a format that they can be carried also by upstream and can be 
shared between distributions. They are comparable to logrotate or 
bash-completion files.

You don't necessarily use distcc, ccache, clang, ... and yet you let 
people compile packages you maintain using them.
You don't necessarily use uclibc, yet you allow users to compile the 
packages against it and expect them to file bugs if something is broken.
You don't necessarily use selinux and yet support building against 
libselinux where possible.
You don't necessarily use zsh as your shell and yet let zsh-completion 
files to be installed when requested.

Yet any of the mentioned packages can be stabilized, what makes systemd 
so special that it can't follow the same rules as other packages?

> So apart of the politic message, there are implications of maintenance
> efforts, stabilization efforts.

Just the normal efforts.

>
> I appreciate the discussion at debian, it is not wise to support [I am
> adding: at stable] more than one solution for layout.
>
> Regards,
> Alon Bar-Lev.
>

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 8 Aug 2013 13:41:02 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> > This isn't a good example, because the PMS compliance governs over
> > this.
> 
> PMS really only covers the format of the ebuilds themselves, and stuff
> like built-in functions that these rely on - the interface between
> ebuilds and package managers.

As stated in 1.1, it also describes certain aspects of the PM behavior
that is required to support such repository. If a PM misbehaves, it's
not the package that is the problem; but the PM that's problematic.

> [ ... Snipped paragraph about config files. ... ]

This is not what this thread is about; but yes, that is stated in 1.1.

> [ ... Snipped paragraph about Paludis and PM-agnostic utilities. ...]

+1 Agreed.

> We provide sensible defaults, and right now OpenRC is the most
> sensible default.  That doesn't mean that things that require systemd
> or something else can't be stable.

The word "sensible" might not be the right choice; or well, at least
one could argue systemd is not necessarily a less sensible choice.

As far as I am aware there isn't any consensus based reason of this type
blocking stabilization, just some opinions; from what I see it really is
mostly the upgrade path and some minor bugs that are still in the way.

> [ ... Snipped paragraph about "stability" not meaning "useful". ...]

+1 Agreed.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: KDE/semantic-desktop

[Chris Reffett]

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

On 08/08/2013 01:52 PM, Rich Freeman wrote:
> On Thu, Aug 8, 2013 at 1:44 PM, Martin Vaeth 
> <vaeth@mathematik.uni-wuerzburg.de> wrote:
>> Sorry for reposting: Somehow the first line got lost making the
>> whole posting not understandable...
>> 
>> Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>>> 
>>> answer is about 10 additional megs of ram at idle and about 2
>>> extra seconds to boot.
>> 
>> ..and two huge database servers which lots of disk and ram space
>> and a huge waste of compile time (not so much for KDE but more
>> for the databases), opening to all sort of possible attacks by
>> bugs in these databases whose servers need to be running etc.
>> 
> 
> Do those servers still run if you disable the features in the
> control panel?  I already run MySQL so the only annoyance for me
> was getting it to use the existing instance rather than spawning a
> new one.
> 
> If somebody is willing to join the KDE team to support keeping
> that option (even as a proxy maintainer) I think the team should
> work with them.  I think that we should generally offer any choice
> as long as somebody steps up to support it properly (and I do mean
> properly). While I'm sure the KDE team has their faults they do
> announce their meetings/etc and I suspect it would be an easy team
> for an outsider to get involved with as a result.
> 
> Rich
> 
Lies! Blatant lies! The KDE team has no faults! :)
...but seriously, if someone were willing to work with us and put in
the effort, I'm sure we could work something out. I'll skip the usual
part about explaining our motivations behind the original removal
since that's been discussed ad nauseam in bugs and on the -desktop list.

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

iKYEARECAGYFAlID4FpfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TlrQCfXM1Pmi1lwwBCsSEfwyC3E5MJ
zQUAn2OZ8pvujwUnu+bLtCZ0e4lacuui
=tus9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 08/08/13 20:57, Alon Bar-Lev wrote:
>>
>> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>>
>>> Stability is about the quality of the ebuilds and the user experience
>>> in general.  It is not a statement that all Gentoo developers think
>>> that the package is useful.  Many would say that nobody should be
>>> using MySQL/MariaDB for production work, but that has nothing to do
>>> with its stability as a package either.
>>
>>
>> This is not entirely correct.
>>
>> If from now on, a bug with systemd of new version of a package blocks
>> that package stabilization, it means that all developers must support
>> systemd. So having systemd stable is a decision that should be made by
>> the entire community, and have huge overhead on us all.
>
>
> That's not really true with systemd when the unit files (and related) are in
> a format that they can be carried also by upstream and can be shared between
> distributions. They are comparable to logrotate or bash-completion files.
>
> You don't necessarily use distcc, ccache, clang, ... and yet you let people
> compile packages you maintain using them.
> You don't necessarily use uclibc, yet you allow users to compile the
> packages against it and expect them to file bugs if something is broken.
> You don't necessarily use selinux and yet support building against
> libselinux where possible.
> You don't necessarily use zsh as your shell and yet let zsh-completion files
> to be installed when requested.
>
> Yet any of the mentioned packages can be stabilized, what makes systemd so
> special that it can't follow the same rules as other packages?

logrotate, autocompletion are not functional dependencies.

uclibc - is not mainline, people who use it for embedded are aware the
it may be broken every bump.

autocompletion, distcc, ccache etc... are optional components which
can be disabled, while having usable system until issue is resolved.

selinux - if a package breaks selinux it will be reverted (if
maintainer care about his users) until resolution is found.

as you may have unusable system if a bump does not support specific
stable init layout, you do expect rollback similar to libselinux
issue. init layout is not optional package nor optional feature, it
how the system operates.

>> So apart of the politic message, there are implications of maintenance
>> efforts, stabilization efforts.
>
>
> Just the normal efforts.
>
>
>>
>> I appreciate the discussion at debian, it is not wise to support [I am
>> adding: at stable] more than one solution for layout.
>>
>> Regards,
>> Alon Bar-Lev.
>>
>
>

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 8 Aug 2013 20:57:15 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
> > Stability is about the quality of the ebuilds and the user
> > experience in general.  It is not a statement that all Gentoo
> > developers think that the package is useful.  Many would say that
> > nobody should be using MySQL/MariaDB for production work, but that
> > has nothing to do with its stability as a package either.
> 
> This is not entirely correct.
> 
> If from now on, a bug with systemd of new version of a package blocks
> that package stabilization, it means that all developers must support
> systemd.

This is not entirely correct either.

Not necessarily, one can opt to mask this combination and stabilize
this combination later by removing the mask; it's an implementation
detail, but certainly there's no need to imply that they must.

Another example is that when you add a package to the tree, you are not
required to initially commit both an OpenRC unit and systemd service
file; you are suggested to provide them for the convenience of the
user, if you don't know systemd service files then you aren't obligated
to support them as far as I am aware of. There are people that can help
you in supporting them as well as following up on their bugs; and if
you wonder, the ebuild change to support a systemd service is trivial.

> So having systemd stable is a decision that should be made by
> the entire community, and have huge overhead on us all.

systemd is already stable, it has not found to be an huge overhead;
whether it should have been a decision made by the entire community, I
doubt it, it neither seems to show any problematic wide spread problems.

> So apart of the politic message, there are implications of maintenance
> efforts, stabilization efforts.

Agreed; though, they are quite small and shouldn't be a bother. It's
worth doing these small implications to provide choice to our users...

> I appreciate the discussion at debian, it is not wise to support [I am
> adding: at stable] more than one solution for layout.

Can you share the link? I'm yet to see good reasoning why it's not wise.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:26 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 8 Aug 2013 20:57:15 +0300
> Alon Bar-Lev <alonbl@gentoo.org> wrote:
>
>> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> > Stability is about the quality of the ebuilds and the user
>> > experience in general.  It is not a statement that all Gentoo
>> > developers think that the package is useful.  Many would say that
>> > nobody should be using MySQL/MariaDB for production work, but that
>> > has nothing to do with its stability as a package either.
>>
>> This is not entirely correct.
>>
>> If from now on, a bug with systemd of new version of a package blocks
>> that package stabilization, it means that all developers must support
>> systemd.
>
> This is not entirely correct either.
>
> Not necessarily, one can opt to mask this combination and stabilize
> this combination later by removing the mask; it's an implementation
> detail, but certainly there's no need to imply that they must.
>
> Another example is that when you add a package to the tree, you are not
> required to initially commit both an OpenRC unit and systemd service
> file; you are suggested to provide them for the convenience of the
> user, if you don't know systemd service files then you aren't obligated
> to support them as far as I am aware of. There are people that can help
> you in supporting them as well as following up on their bugs; and if
> you wonder, the ebuild change to support a systemd service is trivial.

1. There is huge difference between adding a new package that lacks
feature and maintaining existing features.

2. When people say that something is trivial, my immediate reaction is
fear. systemd is far from being trivial, but let's don't get into that
one again.

>
>> So having systemd stable is a decision that should be made by
>> the entire community, and have huge overhead on us all.
>
> systemd is already stable, it has not found to be an huge overhead;
> whether it should have been a decision made by the entire community, I
> doubt it, it neither seems to show any problematic wide spread problems.
>
>> So apart of the politic message, there are implications of maintenance
>> efforts, stabilization efforts.
>
> Agreed; though, they are quite small and shouldn't be a bother. It's
> worth doing these small implications to provide choice to our users...
>
>> I appreciate the discussion at debian, it is not wise to support [I am
>> adding: at stable] more than one solution for layout.
>
> Can you share the link? I'm yet to see good reasoning why it's not wise.

Latest[1], you can search for "debian openrc" for more.

[1] http://www.marshut.com/rnvrp/survey-answers-part-3-systemd-is-not-portable-and-what-this-means-for-our-ports.html

> --
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)

[Tom Wijsman]

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

On Thu, 8 Aug 2013, 20:57:18 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> If from now on, a bug with systemd of new version of a package blocks
> that package stabilization, it means that all developers must support
> systemd. So having systemd stable is a decision that should be made by
> the entire community, and have huge overhead on us all.  

On Thu, 8 Aug 2013 21:23:29 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> selinux - if a package breaks selinux it will be reverted (if
> maintainer care about his users) until resolution is found.
> 
> as you may have unusable system if a bump does not support specific
> stable init layout, you do expect rollback similar to libselinux
> issue. init layout is not optional package nor optional feature, it
> how the system operates.

Reverting and rolling back isn't really the good way going forward, it
implies waiting and that's going to certainly make people sad because
they need to wait for something that doesn't affect the package
combination that the user uses; we need to look at a different approach.

What if we could stabilize package combinations instead of packages? Or
rather, when during stabilization it was found that a certain package
combination doesn't work, exclude that combination from stabilization?

This is a concept that shouldn't be too hard to implement; it could
even be implemented using existing USE flag mask opportunities, although
we probably would have to figure out a solution for those occasions
where an USE flag is not present.

Perhaps specify in the ebuild that the package shouldn't be regarded as
keyworded for a certain dependency?

Since it's just an idea that jumps to mind, I'm not sure if this is the
best approach to do this; but we'll probably want to start brainstorming
in this field if this is going to stay or become a big problem.

Multiple implementations shouldn't block Gentoo going forward.

We need to come up with a solution similar to the above to avoid this...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:47 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 8 Aug 2013, 20:57:18 +0300
> Alon Bar-Lev <alonbl@gentoo.org> wrote:
>
>> If from now on, a bug with systemd of new version of a package blocks
>> that package stabilization, it means that all developers must support
>> systemd. So having systemd stable is a decision that should be made by
>> the entire community, and have huge overhead on us all.
>
> On Thu, 8 Aug 2013 21:23:29 +0300
> Alon Bar-Lev <alonbl@gentoo.org> wrote:
>
>> selinux - if a package breaks selinux it will be reverted (if
>> maintainer care about his users) until resolution is found.
>>
>> as you may have unusable system if a bump does not support specific
>> stable init layout, you do expect rollback similar to libselinux
>> issue. init layout is not optional package nor optional feature, it
>> how the system operates.
>
> Reverting and rolling back isn't really the good way going forward, it
> implies waiting and that's going to certainly make people sad because
> they need to wait for something that doesn't affect the package
> combination that the user uses; we need to look at a different approach.
>
> What if we could stabilize package combinations instead of packages? Or
> rather, when during stabilization it was found that a certain package
> combination doesn't work, exclude that combination from stabilization?
>
> This is a concept that shouldn't be too hard to implement; it could
> even be implemented using existing USE flag mask opportunities, although
> we probably would have to figure out a solution for those occasions
> where an USE flag is not present.
>
> Perhaps specify in the ebuild that the package shouldn't be regarded as
> keyworded for a certain dependency?
>
> Since it's just an idea that jumps to mind, I'm not sure if this is the
> best approach to do this; but we'll probably want to start brainstorming
> in this field if this is going to stay or become a big problem.
>
> Multiple implementations shouldn't block Gentoo going forward.
>
> We need to come up with a solution similar to the above to avoid this...

This is called a 'profile'.

You can have systemd and openrc profiles, and then able to mask
specific packages...

It is a technical solution, but won't make lives much easier in this regard.

Regards,
Alon Bar-Lev

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 08/08/13 21:23, Alon Bar-Lev wrote:
> On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> On 08/08/13 20:57, Alon Bar-Lev wrote:
>>>
>>> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>>>
>>>> Stability is about the quality of the ebuilds and the user experience
>>>> in general.  It is not a statement that all Gentoo developers think
>>>> that the package is useful.  Many would say that nobody should be
>>>> using MySQL/MariaDB for production work, but that has nothing to do
>>>> with its stability as a package either.
>>>
>>>
>>> This is not entirely correct.
>>>
>>> If from now on, a bug with systemd of new version of a package blocks
>>> that package stabilization, it means that all developers must support
>>> systemd. So having systemd stable is a decision that should be made by
>>> the entire community, and have huge overhead on us all.
>>
>>
>> That's not really true with systemd when the unit files (and related) are in
>> a format that they can be carried also by upstream and can be shared between
>> distributions. They are comparable to logrotate or bash-completion files.
>>
>> You don't necessarily use distcc, ccache, clang, ... and yet you let people
>> compile packages you maintain using them.
>> You don't necessarily use uclibc, yet you allow users to compile the
>> packages against it and expect them to file bugs if something is broken.
>> You don't necessarily use selinux and yet support building against
>> libselinux where possible.
>> You don't necessarily use zsh as your shell and yet let zsh-completion files
>> to be installed when requested.
>>
>> Yet any of the mentioned packages can be stabilized, what makes systemd so
>> special that it can't follow the same rules as other packages?
>
> logrotate, autocompletion are not functional dependencies.
>
> uclibc - is not mainline, people who use it for embedded are aware the
> it may be broken every bump.
>
> autocompletion, distcc, ccache etc... are optional components which
> can be disabled, while having usable system until issue is resolved.
>
> selinux - if a package breaks selinux it will be reverted (if
> maintainer care about his users) until resolution is found.
>
> as you may have unusable system if a bump does not support specific
> stable init layout, you do expect rollback similar to libselinux
> issue. init layout is not optional package nor optional feature, it
> how the system operates.

<Replying very loosely>

I guess that's why we call Gentoo a meta-distribution instead of 
distribution since we are not bound to one certain type of system 
operation like eg. Debian is or any other binary distribution is.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:58 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 08/08/13 21:23, Alon Bar-Lev wrote:
>>
>> On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen <ssuominen@gentoo.org>
>> wrote:
>>>
>>> On 08/08/13 20:57, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>>>>
>>>>>
>>>>> Stability is about the quality of the ebuilds and the user experience
>>>>> in general.  It is not a statement that all Gentoo developers think
>>>>> that the package is useful.  Many would say that nobody should be
>>>>> using MySQL/MariaDB for production work, but that has nothing to do
>>>>> with its stability as a package either.
>>>>
>>>>
>>>>
>>>> This is not entirely correct.
>>>>
>>>> If from now on, a bug with systemd of new version of a package blocks
>>>> that package stabilization, it means that all developers must support
>>>> systemd. So having systemd stable is a decision that should be made by
>>>> the entire community, and have huge overhead on us all.
>>>
>>>
>>>
>>> That's not really true with systemd when the unit files (and related) are
>>> in
>>> a format that they can be carried also by upstream and can be shared
>>> between
>>> distributions. They are comparable to logrotate or bash-completion files.
>>>
>>> You don't necessarily use distcc, ccache, clang, ... and yet you let
>>> people
>>> compile packages you maintain using them.
>>> You don't necessarily use uclibc, yet you allow users to compile the
>>> packages against it and expect them to file bugs if something is broken.
>>> You don't necessarily use selinux and yet support building against
>>> libselinux where possible.
>>> You don't necessarily use zsh as your shell and yet let zsh-completion
>>> files
>>> to be installed when requested.
>>>
>>> Yet any of the mentioned packages can be stabilized, what makes systemd
>>> so
>>> special that it can't follow the same rules as other packages?
>>
>>
>> logrotate, autocompletion are not functional dependencies.
>>
>> uclibc - is not mainline, people who use it for embedded are aware the
>> it may be broken every bump.
>>
>> autocompletion, distcc, ccache etc... are optional components which
>> can be disabled, while having usable system until issue is resolved.
>>
>> selinux - if a package breaks selinux it will be reverted (if
>> maintainer care about his users) until resolution is found.
>>
>> as you may have unusable system if a bump does not support specific
>> stable init layout, you do expect rollback similar to libselinux
>> issue. init layout is not optional package nor optional feature, it
>> how the system operates.
>
>
> <Replying very loosely>
>
> I guess that's why we call Gentoo a meta-distribution instead of
> distribution since we are not bound to one certain type of system operation
> like eg. Debian is or any other binary distribution is.

As this alternate layout did not exist at that time, I don't think it
had not been the reason for this term.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 2:26 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> > Stability is about the quality of the ebuilds and the user
>> > experience in general.  It is not a statement that all Gentoo
>> > developers think that the package is useful.  Many would say that
>> > nobody should be using MySQL/MariaDB for production work, but that
>> > has nothing to do with its stability as a package either.
>>
>> This is not entirely correct.
>>
>> If from now on, a bug with systemd of new version of a package blocks
>> that package stabilization, it means that all developers must support
>> systemd.
>
> Not necessarily, one can opt to mask this combination and stabilize
> this combination later by removing the mask; it's an implementation
> detail, but certainly there's no need to imply that they must.

Package updates that break other packages is not an issue unique to
the stable tree - we just have less tolerance for it there.  If
libfoo-5 breaks stable systemd, then there needs to be coordination,
just as is the case if libfoo-5 breaks stable xeyes or openoffice.

Usually in these situations things get straightened out and we're
usually the better for it because such incompatibilities tend to be
the result of brain-dead behavior in one upstream or the other.  If it
can't be straightened out then sometimes we accept blocking deps/etc.
I'm sure in the history of every glibc upgrade in Gentoo there has
been some stable package or another that couldn't keep up, and I even
recall one that basically required rebuilding everything in ages past.

And this is cooperation - everybody benefits from it.

>
> Another example is that when you add a package to the tree, you are not
> required to initially commit both an OpenRC unit and systemd service
> file; you are suggested to provide them for the convenience of the
> user,
>

Indeed, when you add a package to the tree you're not required to
initially commit any kind of service files for it at all (openrc or
systemd).  Supporting both is to be encouraged all the same, and
accepting patches to add service files should not be discretionary (if
another maintainer/proxy is willing to do the work).

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 8 Aug 2013 21:38:55 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> On Thu, Aug 8, 2013 at 9:26 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> > Not necessarily, one can opt to mask this combination and stabilize
> > this combination later by removing the mask; it's an implementation
> > detail, but certainly there's no need to imply that they must.
> >
> > Another example is that when you add a package to the tree, you are
> > not required to initially commit both an OpenRC unit and systemd
> > service file; you are suggested to provide them for the convenience
> > of the user, if you don't know systemd service files then you
> > aren't obligated to support them as far as I am aware of. There are
> > people that can help you in supporting them as well as following up
> > on their bugs; and if you wonder, the ebuild change to support a
> > systemd service is trivial.
> 
> 1. There is huge difference between adding a new package that lacks
> feature and maintaining existing features.

True, that's why it's another example; as for my first paragraph, see
the mail <20130808204701.3b419e58@TOMWIJ-GENTOO> I just send out
titled "Multiple implementations shouldn't block Gentoo's progress.
Stabilize package combinations? (was: ...)" which details that.

(By the time of finishing this mail, it appears you've answered already)

> 2. When people say that something is trivial, my immediate reaction is
> fear. systemd is far from being trivial, but let's don't get into that
> one again.

systemd's triviality is irrelevant; this is an ebuild change, and I
don't see what you have fear of. A good way to deal with fear, is risk
analysis; in which of the following fields do you find to be a risk?

 1. Known knowns.
 2. Unknown knowns.
 3. Known unknowns.
 4. Unknown unknowns.

For what reason do you think that a particular field has a huge risk?
What do you anticipate happening? What is the risk worth fearing?

> > On Thu, 8 Aug 2013 20:57:15 +0300
> > Alon Bar-Lev <alonbl@gentoo.org> wrote:
> >
> > > I appreciate the discussion at debian, it is not wise to support
> > > [I am adding: at stable] more than one solution for layout.
> >
> > Can you share the link? I'm yet to see good reasoning why it's not
> > wise.
> 
> Latest[1], you can search for "debian openrc" for more.
> 
> [1]
> http://www.marshut.com/rnvrp/survey-answers-part-3-systemd-is-not-portable-and-what-this-means-for-our-ports.html

It not being portable indeed implies that it's not supportable on
certain architectures, platforms and so on it can't be ported to;
but that doesn't imply that we can't support more than one solution for
the layout for architectures, platforms and so on where it does work.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)

[Rich Freeman]

On Thu, Aug 8, 2013 at 2:57 PM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> This is called a 'profile'.
>
> You can have systemd and openrc profiles, and then able to mask
> specific packages...
>
> It is a technical solution, but won't make lives much easier in this regard.

++

I don't think that this is really sustainable.  We can't really afford
to have a bazillion profiles with a multitude of rules about what does
and doesn't work together on top of the simple dependencies that
already exist.  This is the reason why nobody tends to use POSIX ACLs
either.

I could see value in convenience profiles here just as we have them
for kde/gnome.  Those profiles aren't about masking incompatible
packages so much as providing a pre-packaged configuration that tends
to work (emphasis on tends - when I've built from stage3 I usually
find there is some USE flag I need to tweak).

I don't really see that as being necessary for systemd though - it
really just involves one USE flag and one package and then a bunch of
manual configuration.  Systemd isn't a collection of 100+ individual
packages which each have their own IUSE/etc.

Rich

Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)

[Tom Wijsman]

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

On Thu, 8 Aug 2013 21:57:37 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> > Multiple implementations shouldn't block Gentoo going forward.
> >
> > We need to come up with a solution similar to the above to avoid
> > this...
> 
> This is called a 'profile'.
> 
> You can have systemd and openrc profiles, and then able to mask
> specific packages...

That's an interesting solution. Though, I wonder if it constitutes as
use or as misuse of profiles as we haven't thought this out; also, I
wonder how different people's stance is over having profiles like this.

There are probably other solutions as well, let's see what comes...

> It is a technical solution, but won't make lives much easier in this
> regard.

Why not? What risk or disadvantageous implication do you foresee?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Thu, 8 Aug 2013 15:02:55 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Aug 8, 2013 at 2:26 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> Package updates that break other packages is not an issue unique to
> the stable tree - we just have less tolerance for it there.  If
> libfoo-5 breaks stable systemd, then there needs to be coordination,
> just as is the case if libfoo-5 breaks stable xeyes or openoffice.

These are libraries; I don't see a direct problem, so I guess this
logic applies to a package like OpenRC or systemd as well. Good point.

> Usually in these situations things get straightened out and we're
> usually the better for it because such incompatibilities tend to be
> the result of brain-dead behavior in one upstream or the other.  If it
> can't be straightened out then sometimes we accept blocking deps/etc.

Oh, right, I forgot [1] about the possibility to block and stabilize
with the blocker; I wish I hadn't posted the "stabilize package combos"
thread now, but well, maybe some good thoughts could evolve from it.

Thank you for bringing this up!

 [1]: ... and want to blame my two weeks of absence ... :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

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

On 08/08/13 11:38, Samuli Suominen wrote:
> i'm not volunteering but I never really got why our GNOME
> maintainers insisted on staying with it instead of going with the
> distribution after it was clear logind is a dead end on non-systemd
> systemd

Ok,

So there's lots of people that don't want systemd.  Can't we group
together and have some kind of an affect on upstream?  Upstream
appears to be suffering the same split we found with portage, in that
the specification that people are working to is in fact the only
implementation (as least, that's how I read the fact that a separate
logind which follows the specification will no longer work without
systemd explicitly?).  We now have paludis, pkgcore and the PMS.  Is
there some way, we as the Gentoo Foundation, Developers or even just
Users can form a petition, or an open letter, that might make enough
impact on the Gnome foundation for them to reconsider their position?

Perhaps if there were an "init system specification" project, separate
from systemd, that systemd had to adhere to rather than deciding to
change the rules at a random version (like 205), then Gnome could
potentially have other options than just systemd?

Does anyone know how Gnome is dealing with being run under non-linux
systems given the new systemd hard dependency?  Is it simply not
shutting down, etc?  Can we introduce a similar build capability so
that people can have a "non-full" Gnome installation that still
includes most of the apps?

Either way, bickering amongst ourselves won't have any effect,
fighting against upstream's changes seems similarly futile (they have
no reason to improve the situation if we're happy to do the extra work
when things are bad), so the best chance we have is communicating with
upstream and asking them to reconsider.  That's not guaranteed to
work, but focusing our efforts on that, rather than lengthy arguments
about time-intensive Gentoo solutions seems like a better option...

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIEAiAACgkQu7rWomwgFXpYUgCgk+XJynbo4MCRcFlqHrYtDgyV
U+UAnAnn6tnrYYx/3ptOU7EGJF0efCyu
=R4BF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El jue, 08-08-2013 a las 21:40 +0100, Mike Auty escribió:
[...]
> Ok,
> 
> So there's lots of people that don't want systemd.  Can't we group
> together and have some kind of an affect on upstream?  Upstream
> appears to be suffering the same split we found with portage, in that
> the specification that people are working to is in fact the only
> implementation (as least, that's how I read the fact that a separate
> logind which follows the specification will no longer work without
> systemd explicitly?).  We now have paludis, pkgcore and the PMS.  Is
> there some way, we as the Gentoo Foundation, Developers or even just
> Users can form a petition, or an open letter, that might make enough
> impact on the Gnome foundation for them to reconsider their position?
> 
> Perhaps if there were an "init system specification" project, separate
> from systemd, that systemd had to adhere to rather than deciding to
> change the rules at a random version (like 205), then Gnome could
> potentially have other options than just systemd?
> 
> Does anyone know how Gnome is dealing with being run under non-linux
> systems given the new systemd hard dependency?  Is it simply not
> shutting down, etc?  Can we introduce a similar build capability so
> that people can have a "non-full" Gnome installation that still
> includes most of the apps?
> 
> Either way, bickering amongst ourselves won't have any effect,
> fighting against upstream's changes seems similarly futile (they have
> no reason to improve the situation if we're happy to do the extra work
> when things are bad), so the best chance we have is communicating with
> upstream and asking them to reconsider.  That's not guaranteed to
> work, but focusing our efforts on that, rather than lengthy arguments
> about time-intensive Gentoo solutions seems like a better option...
> 
> Mike  5:)

The situation could be summarized as follows:
- Debian/Ubuntu are still trying to make Gnome work with upstart -> that
lead them to make all the tricks that let logind (that is the currently
important part) work without systemd being running UNTIL systemd 205
(due cgroups handling being merged completely inside systemd). This was
implemented on Gentoo by lxnay in systemd-love overlay. The problem is
that any version newer than 204 won't work. I contacted the
Ubuntu/Debian guy that did most of the work there, and he told me that,
for now, will need to stick with 204 for a long time until Ubuntu
"council" (I don't remember how they call it) decides what to do. He
even admitted that would be interesting if they would simply move to
systemd...
- Other desktop oriented distributions have already migrated to systemd,
and then, they won't probably make any effort to make Gnome work in
their old systems (I am talking about Fedora, OpenSuSE, Mageia,
Mandriva, Arch...). The main advantage they had moving to systemd is to
don't need to maintain their own system, and also being able to share
efforts between distributions.
- openBSD is simply supplying the "semibroken" Gnome stuff running with
their setup (without multiseat working, neither power management, gdm
service handling, and any new issues that could rise from logind not
being running)

No idea about Solaris and others.

Anyway, are you sure openRC is better than systemd for desktop systems
(for deserving the effort to keep maintaining consolekit, that is
currently orphan, cgroups stuff and any other things I am probably
forgetting now) ? In that case, if you decide to try to suggest that to
upstream, I would try to contact with Ubuntu/Debian guys, openBSD
maintainer and Solaris one (Brian Cameron I think)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Greg KH]

On Thu, Aug 08, 2013 at 09:40:00PM +0100, Mike Auty wrote:
> On 08/08/13 11:38, Samuli Suominen wrote:
> > i'm not volunteering but I never really got why our GNOME
> > maintainers insisted on staying with it instead of going with the
> > distribution after it was clear logind is a dead end on non-systemd
> > systemd
> 
> Ok,
> 
> So there's lots of people that don't want systemd.  Can't we group
> together and have some kind of an affect on upstream?

Become upstream developers and create fixes to remove the dependancy
either by working on openrc features to emulate the same things that
systemd has that GNOME requires, or split things out of GNOME so that it
does not require systemd dependencies.

But to complain to upstream without providing patches is a bit futile,
don't you think?  That's not how open source projects work, we all know
that.

greg k-h

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

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

On 08/08/13 22:06, Pacho Ramos wrote:
> Anyway, are you sure openRC is better than systemd for desktop
> systems (for deserving the effort to keep maintaining consolekit,
> that is currently orphan, cgroups stuff and any other things I am
> probably forgetting now) ? In that case, if you decide to try to
> suggest that to upstream, I would try to contact with Ubuntu/Debian
> guys, openBSD maintainer and Solaris one (Brian Cameron I think)

I'm not, systemd may be excellent for desktop systems, and for binary
systems that can build it once and have it work fine it may fit the
use case perfectly.  I do believe that openrc is a more reliable init
system (not least because, after having tried to swap to systemd, I
was presented with a kernel panic and no rescue shell, which realized
all my fears immediately).

Cgroups, and other new features may be excellent, but I'm not in so
much of a rush that I can't have things that need them started from a
small reliable init, rather than instead of it.

Thanks for your suggestions, I know the Gnome Gentoo guys and lxnay
have tried hard to maintain the option of not using systemd, and I
really appreciate all the hard work you guys put in.  I'm more
disappointed in Gnome itself for failing to be happy at being a great
Desktop Environment, and instead dictating the rest of my operating
system requirements for me...

Mike  5:\
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIENSQACgkQu7rWomwgFXr4zQCfejaFh0R2Dslx07E9zOeZT1mc
IKwAnRsZwH7CHDoxHbIhk32g7SNn3O+A
=kRAJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michael Weber]

Citing from Pachos blog,

"[...] we are now forcing people to *run* systemd to be able to properly
run Gnome 3.8, otherwise power management and multiseat support are
lost, [...]" [1].

Pacho, would you accept patches and USE flags to make gdm an optional
component to gnome virtual? Power management is not crucial for window
management.

[1]
http://my.opera.com/pacho/blog/2013/07/24/gnome-3-8-requiring-systemd-on-gentoo

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

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

On 09/08/13 00:19, Greg KH wrote:
> Become upstream developers and create fixes to remove the
> dependancy either by working on openrc features to emulate the same
> things that systemd has that GNOME requires, or split things out of
> GNOME so that it does not require systemd dependencies.
> 
> But to complain to upstream without providing patches is a bit
> futile, don't you think?  That's not how open source projects work,
> we all know that.
> 
> greg k-h
> 

I would like to think that open source developers working on such a
large and integral project might listen to their users.  The way open
source is supposed to work is that people write something, and if it's
good people use it, and if it's not they don't.

I would very much like to have seen systemd succeed, but based on its
own merits, whereas it seems to have been accepted by being championed
at certain distributions, made indispensable to desktop environments
like Gnome, and by dropping the responsibility of developing udev in
favour of developing systemd.

I have heard the systemd developers say that no one has been forced to
use systemd, and that in the open source world, if I don't like
something I can write something different.  That's a wholly selfish
perspective, each and every person that contributes to open source
does so in their own way, and we're entirely dependent upon each other
to make the community and choices as vibrant as they are.  I could be
a KDE developer, or a Gentoo documenter, or work on mplayer.  All
those people are open source contributors and necessary ones, but that
doesn't mean that any of them necessarily has the skills or the time
to look after udev.  Does that invalidate their opinion on the choices
of upstream project they rely on?

There are certain key projects (like the kernel, glibc and udev) which
nearly every system has come to rely upon and, I believe, with that
reliance comes responsibility.  I wouldn't expect Linus to just one
day and walk away to go developing a new kernel he thought was better,
but he could.  If he did though, I would expect him to leave
infrastructure in place behind him to look after the project he made
which people all over the world now depend upon, and I'd continue
using that until his new kernel had proved its worth.  I certainly
wouldn't expect him to use his natural monopoly to force his new idea
on everyone!

I'm not trying to hinder advancement, the trying out of new ideas is
what open source is all about.  We've got source-based distributions
because someone wanted to see if it would work, it did and there's a
good community around it.  However, that hasn't come at the cost of
binary distributions, they both co-exist peacefully and people use
whichever one they want.

I don't have the skills to make a difference, so all I can do is vote
with my feet.  Even after sticking with Gnome 3 through its early
phases, I don't think I can continue using it at this point and I am
investigating alternatives, one of which is to try to remind the Gnome
developers, if not the systemd ones, of why UNIX succeeded even with
such a distributed development base; it was not because of enforced
uniformity...

Mike  5:\
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIENyAACgkQu7rWomwgFXrv9wCdGHA4IhltnJBSt/2uY1XP6Xcs
QM4AoKS2V5AWgfD+EAeyE43Jm1hwRaVT
=DcNA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Chí-Thanh Christopher Nguyễn]

Pacho Ramos schrieb:
> - openBSD is simply supplying the "semibroken" Gnome stuff running with
> their setup (without multiseat working, neither power management, gdm
> service handling, and any new issues that could rise from logind not
> being running)

If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
patches that make it possible to install Gnome 3.8 without systemd again?
Only make it possible, not turn it into a configuration which the Gnome team
supports.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

[snip]
>> On 08/08/2013 05:26 PM, Rich Freeman wrote:
>>> OpenRC is just one init system that Gentoo supports.  Gentoo does
>>> not require the use of OpenRC any more than it requires the use of
>>> portage as the package manager.
>>
>> So would you stabilize a package that works with paludis, but not with
>> portage? Ouch. It should probably not be in the tree in the first
>> place, but I that's not what I have in mind here.
> 
> This isn't a good example, because the PMS compliance governs over this.
> 

It is an excellent example. If it doesn't work with portage that's a
QA-failure and reason to mask until fixed. As PMS is incomplete and
often not reflecting reality it's not a good baseline.


>> I generally expect packages to work with... now be surprised... BOTH
>> init systems, although I don't like systemd. If it doesn't work with
>> one, then it's a bug. Bugs block stabilization.
>> It is a _REGRESSION_. Ask the arch team about the meaning of
>> regression if unsure.
> 
> It's not a regression; actually, it's quite common to drop features
> that can no longer be supported. I don't see us blocking stabilization
> for other cases in the Portage tree where a feature has been dropped.
> 

It is a regression: If it doesn't work with OpenRC I can't use it (same
with portage), and thus it deserves a liberal dose of bugs and masking
if bugs don't get fixed on time.

What makes this situation so difficult is that it's not a single random
package, but one of the bigger desktop environments that has painted
itself into a corner. (Plus an uncooperative upstream, so all the
"blame" gets thrown at the gentoo maintainers from both sides. Awesome
way to destroy crew morale :) )

[gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Zac Medico]

On 08/08/2013 12:11 PM, Tom Wijsman wrote:
> On Thu, 8 Aug 2013 21:57:37 +0300
> Alon Bar-Lev <alonbl@gentoo.org> wrote:
> 
>>> Multiple implementations shouldn't block Gentoo going forward.
>>>
>>> We need to come up with a solution similar to the above to avoid
>>> this...
>>
>> This is called a 'profile'.
>>
>> You can have systemd and openrc profiles, and then able to mask
>> specific packages...
> 
> That's an interesting solution. Though, I wonder if it constitutes as
> use or as misuse of profiles as we haven't thought this out; also, I
> wonder how different people's stance is over having profiles like this.

This seems like a possible applicatio for "mix-in" profiles like Funtoo
uses:

  http://www.funtoo.org/wiki/Flavors_and_Mix-ins
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Dustin C. Hatch]

On 8/8/2013 20:05, Zac Medico wrote:
> On 08/08/2013 12:11 PM, Tom Wijsman wrote:
>> On Thu, 8 Aug 2013 21:57:37 +0300
>> Alon Bar-Lev <alonbl@gentoo.org> wrote:
>>
>>>> Multiple implementations shouldn't block Gentoo going forward.
>>>>
>>>> We need to come up with a solution similar to the above to avoid
>>>> this...
>>>
>>> This is called a 'profile'.
>>>
>>> You can have systemd and openrc profiles, and then able to mask
>>> specific packages...
>>
>> That's an interesting solution. Though, I wonder if it constitutes as
>> use or as misuse of profiles as we haven't thought this out; also, I
>> wonder how different people's stance is over having profiles like this.
>
> This seems like a possible applicatio for "mix-in" profiles like Funtoo
> uses:
>
>    http://www.funtoo.org/wiki/Flavors_and_Mix-ins
>
+1 for mix-ins, been hoping to see that hit mainline for a while now.

-- 
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[William Hubbs]

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

The decision to depend on systemd for part of its functionality is with
gnome upstream, not the gnome team of Gentoo.

Pacho wrote a good summary of what is going on. I can see why OpenBSD
would provide the missing functionality of systemd for gnome (systemd
does not, and will not, exist on the *BSDs). Someone could provide the
missing functionality of systemd so that gnome could run without
systemd, or they could provide patches to gnome upstream to make sure it
works without the need for systemd.

I suggest that if you really want to keep this going, convincing gnome
upstream that running without systemd is still important is the way to
go, not taking it out on the Gentoo gnome team, and the best way to
convince gnome would probably be to provide patches.

All of the complaining and taking it out on our gnome team is not
productive. Asking our gnome team to carry downstream patches is also
not productive, because they would end up being forced to update these
patches against every new gnome release.

It is not a regression if a new version of gnome mrequires systemd
and does not work with OpenRc; it is a design choice.

The community doesn't need to decide whether systemd can go stable;
The community would only need to decide if we switch the default init
system to systemd. No one is proposing this.

Thanks for your time,

William Hubbs
Gentoo Developer and Council Member

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Thu, Aug 8, 2013 at 8:27 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>>> On 08/08/2013 05:26 PM, Rich Freeman wrote:
>> It's not a regression; actually, it's quite common to drop features
>> that can no longer be supported. I don't see us blocking stabilization
>> for other cases in the Portage tree where a feature has been dropped.
>
> It is a regression: If it doesn't work with OpenRC I can't use it (same
> with portage), and thus it deserves a liberal dose of bugs and masking
> if bugs don't get fixed on time.

Not supporting OpenRC is specified behavior, in this case.  Bugs are
by definition unspecified behavior.  If it isn't a bug, it isn't a
regression.  In any case, the whole point of having a stable tree is
to provide a service to users (including devs) who want to run a set
of packages that have been tested by others.  Gnome 3.x fits that
bill, even if it doesn't work with OpenRC.  Who benefits from keeping
it unstable, let alone masking it?  This isn't a project where we have
to exterminate anything that offends our sense of aesthetics.  If
somebody does an emerge -puD world and sees systemd show up in the
list, and doesn't realize what that means (or be willing to learn it
the hard way), they probably should stick with Ubuntu.

Gentoo has some packages that don't work with Openrc, or Portage, or
FreeBSD, and likely even Linux.  In the future it will probably have
more of them.  That's why we say that we're about choice.  Would I
like to see optional Openrc support in Gnome?  Sure.  Will I see it?
Well, maybe someday if the FreeBSD folks or others put a lot of work
into it.  If somebody wants to maintain it they should be welcome to
do so.  However, somebody has to do the work.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 09/08/13 03:25, Michael Weber wrote:
> Citing from Pachos blog,
>
> "[...] we are now forcing people to *run* systemd to be able to properly
> run Gnome 3.8, otherwise power management and multiseat support are
> lost, [...]" [1].
>
> Pacho, would you accept patches and USE flags to make gdm an optional
> component to gnome virtual? Power management is not crucial for window
> management.
>
> [1]
> http://my.opera.com/pacho/blog/2013/07/24/gnome-3-8-requiring-systemd-on-gentoo
>

<Just pointing this out>

http://bugs.gentoo.org/show_bug.cgi?id=242750

Quoting:

"Pacho Ramos gentoo-dev 2008-10-19 15:13:07 EEST

Currently, I am mainly (there are other apps that I prefer not install 
in all systems but adding a USE flag for each of them would be excesive) 
using gnome-light instead of gnome ebuild because I don't want to 
install vinagre and vino in my systems and, in some of them, I don't 
install evolution (bacause users that will use affected system use 
thunderbird instead of evo)

I have seen that there are already USE flags for these apps in 
/usr/portage/profiles/use.desc :
evo - Adds support for mail-client/evolution
vnc - Enable VNC (remote desktop viewer) support

Then, I seems reasonable (at least for me) use this global USE flags for 
not forcing people to install evolution and vnc related apps

Thanks a lot"

;-)

Re: [gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Samuli Suominen]

On 09/08/13 04:05, Zac Medico wrote:
> On 08/08/2013 12:11 PM, Tom Wijsman wrote:
>> On Thu, 8 Aug 2013 21:57:37 +0300
>> Alon Bar-Lev <alonbl@gentoo.org> wrote:
>>
>>>> Multiple implementations shouldn't block Gentoo going forward.
>>>>
>>>> We need to come up with a solution similar to the above to avoid
>>>> this...
>>>
>>> This is called a 'profile'.
>>>
>>> You can have systemd and openrc profiles, and then able to mask
>>> specific packages...
>>
>> That's an interesting solution. Though, I wonder if it constitutes as
>> use or as misuse of profiles as we haven't thought this out; also, I
>> wonder how different people's stance is over having profiles like this.
>
> This seems like a possible applicatio for "mix-in" profiles like Funtoo
> uses:
>
>    http://www.funtoo.org/wiki/Flavors_and_Mix-ins
>

I've always disliked unnecessary profiles, a lot, but this whole 
selecting of init plus packages supporting it plus the /usr-move issue 
the systemd maintainers are bundling together with it by forcing the 
unstandard systemd installation to /usr...
imho, would be good enough reason for a one or two more sub profiles

What if eg. profiles/targets/desktop would have sub directory 
profiles/targets/desktop/systemd which would have a 'parent' of '..' 
with USE="-consolekit systemd" and more importantly, the could-be kludge 
to setup the /usr-move, the could-be environment variable to disable 
functionality of gen_usr_ldscript...
profiles/targets/desktop/gnome with 'parent' of '..' and '../../systemd' 
that mask the core packages GNOME 3.x that will pull in systemd 
unconditionally, and profiles/targets/desktop/systemd unmasking those 
packages

(I hope that was readable, it seems a lot simpler in my head ;-)

- Samuli

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El vie, 09-08-2013 a las 02:26 +0200, Chí-Thanh Christopher Nguyễn
escribió:
> Pacho Ramos schrieb:
> > - openBSD is simply supplying the "semibroken" Gnome stuff running with
> > their setup (without multiseat working, neither power management, gdm
> > service handling, and any new issues that could rise from logind not
> > being running)
> 
> If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
> patches that make it possible to install Gnome 3.8 without systemd again?
> Only make it possible, not turn it into a configuration which the Gnome team
> supports.
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 

We have discussed this some times in the team, the problem is that we
don't think we should provide "by default" a setup that is not working
properly: powermanagement, multiseat support and gdm service handling
are the more noticeable problems and the known ones... but there could
be more problems (for example, I remember to have lots of dbus rejection
messages from gnome-session and gnome-shell that I never was able to
know what was causing). Also, if that people reports problems, we would
close them as WONTFIX -> migrate to systemd (and expect them to not try
to lie us and causes us to break our heads thinking about what could be
causing their strange problem)

Anyway, you can still run it in the "openBSD" way:
- You can ignore the warnings, news and suggestions and, even moving
from udev to systemd ebuild, keep booting with openRC and using systemd
as device manager
- You can put systemd in package.provides to even keep running udev

But we (gnome team) cannot support that setups and, then, we prefer to
point people to run the supported one (with systemd running), keeping
the other "alternatives" for people that will be able to live with a
semi broken desktop and don't expect us to fix their bugs and fight to
upstream because XX thing doesn't work out of systemd.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El vie, 09-08-2013 a las 02:25 +0200, Michael Weber escribió:
> Citing from Pachos blog,
> 
> "[...] we are now forcing people to *run* systemd to be able to properly
> run Gnome 3.8, otherwise power management and multiseat support are
> lost, [...]" [1].

> Pacho, would you accept patches and USE flags to make gdm an optional
> component to gnome virtual? Power management is not crucial for window
> management.
> 
> [1]
> http://my.opera.com/pacho/blog/2013/07/24/gnome-3-8-requiring-systemd-on-gentoo
> 

I would use gnome-light virtual instead (gnome meta will be kept pulling
gdm as gnome session will behave in some kind of "fallback mode" when
gdm is not being used to login in (for example, the user switching will
change)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El vie, 09-08-2013 a las 08:29 +0300, Samuli Suominen escribió:
> On 09/08/13 03:25, Michael Weber wrote:
> > Citing from Pachos blog,
> >
> > "[...] we are now forcing people to *run* systemd to be able to properly
> > run Gnome 3.8, otherwise power management and multiseat support are
> > lost, [...]" [1].
> >
> > Pacho, would you accept patches and USE flags to make gdm an optional
> > component to gnome virtual? Power management is not crucial for window
> > management.
> >
> > [1]
> > http://my.opera.com/pacho/blog/2013/07/24/gnome-3-8-requiring-systemd-on-gentoo
> >
> 
> <Just pointing this out>
> 
> http://bugs.gentoo.org/show_bug.cgi?id=242750
> 
> Quoting:
> 
> "Pacho Ramos gentoo-dev 2008-10-19 15:13:07 EEST
> 
> Currently, I am mainly (there are other apps that I prefer not install 
> in all systems but adding a USE flag for each of them would be excesive) 
> using gnome-light instead of gnome ebuild because I don't want to 
> install vinagre and vino in my systems and, in some of them, I don't 
> install evolution (bacause users that will use affected system use 
> thunderbird instead of evo)
> 
> I have seen that there are already USE flags for these apps in 
> /usr/portage/profiles/use.desc :
> evo - Adds support for mail-client/evolution
> vnc - Enable VNC (remote desktop viewer) support
> 
> Then, I seems reasonable (at least for me) use this global USE flags for 
> not forcing people to install evolution and vnc related apps
> 
> Thanks a lot"
> 
> ;-)
> 
> 

Please open a *new* bug suggesting this change -> I agree with it, but
needs to be considered by the rest of gnome team :)

Thanks

[gentoo-dev] Re: Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Steven J. Long]

On Fri, Aug 09, 2013 at 08:39:20AM +0300, Samuli Suominen wrote:
> I've always disliked unnecessary profiles, a lot, but this whole 
> selecting of init plus packages supporting it plus the /usr-move issue 
> the systemd maintainers are bundling together with it by forcing the 
> unstandard systemd installation to /usr...
> imho, would be good enough reason for a one or two more sub profiles
> 
> What if eg. profiles/targets/desktop would have sub directory 

> profiles/targets/desktop/systemd:
>  which would have a 'parent' of '..'
>  with USE="-consolekit systemd" and [systemd-specific settings]

Yeah, the changes seem to warrant a sub-profile.

> profiles/targets/desktop/gnome:
>  with 'parent' of '..' and '../../systemd' 

Should that latter be '../systemd' ?

> that mask the core packages GNOME 3.x that will pull in systemd 
> unconditionally, and profiles/targets/desktop/systemd unmasking those 
> packages

Er doesn't it make more sense for the gnome sub-profile to unmask what it
needs? Or does gnome apply to 2 and 3 both?

It would seem to make sense if the packages are unmasked conditionally
in the parent, or the linux profile, and then unmasked in the profiles
that need them. Sorry if I'm misunderstanding.

> (I hope that was readable, it seems a lot simpler in my head ;-)

With a bit of separation, yeah ;) Makes sense as an overall approach.

regards,
igli
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] [typo] Re: Re: Multiple implementations shouldn't block Gentoo's progress.

[Steven J. Long]

<clumsy fool> wrote:
> It would seem to make sense if the packages are unmasked conditionally
s/ conditionally//

> in the parent, or the linux profile, and then unmasked in the profiles
> that need them. Sorry if I'm misunderstanding.

And for noise.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] [typo] Re: Re: Multiple implementations shouldn't block Gentoo's progress.

[William Hubbs]

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

On Fri, Aug 09, 2013 at 07:51:15AM +0100, Steven J. Long wrote:
> <clumsy fool> wrote:
> > It would seem to make sense if the packages are unmasked conditionally
> s/ conditionally//
> 
> > in the parent, or the linux profile, and then unmasked in the profiles
> > that need them. Sorry if I'm misunderstanding.

What needs to be masked though? Like I said in my
message earlier in this thread, there is no need for any major
acrobatics here. If you upgrade to gnome-3.8, you switch over to systemd.
The gnome team is working on an upgrade guide, so let's leave that to
them. :-)

William


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

Re: [gentoo-dev] [typo] Re: Re: Multiple implementations shouldn't block Gentoo's progress.

[Samuli Suominen]

On 09/08/13 10:19, William Hubbs wrote:
> On Fri, Aug 09, 2013 at 07:51:15AM +0100, Steven J. Long wrote:
>> <clumsy fool> wrote:
>>> It would seem to make sense if the packages are unmasked conditionally
>> s/ conditionally//
>>
>>> in the parent, or the linux profile, and then unmasked in the profiles
>>> that need them. Sorry if I'm misunderstanding.
>
> What needs to be masked though? Like I said in my
> message earlier in this thread, there is no need for any major
> acrobatics here. If you upgrade to gnome-3.8, you switch over to systemd.
> The gnome team is working on an upgrade guide, so let's leave that to
> them. :-)
>
> William
>

For example, gnome-base/gnome-settings-daemon could be p.mask in 
non-systemd profiles instructing the users to switch to the systemd 
profile and point to the guide you were referring to
As in, the benefit would be informative mask message

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Gilles Dartiguelongue]

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

Le jeudi 08 août 2013 à 21:03 -0500, William Hubbs a écrit :
> The decision to depend on systemd for part of its functionality is with
> gnome upstream, not the gnome team of Gentoo.
> 
> Pacho wrote a good summary of what is going on. I can see why OpenBSD
> would provide the missing functionality of systemd for gnome (systemd
> does not, and will not, exist on the *BSDs). Someone could provide the
> missing functionality of systemd so that gnome could run without
> systemd, or they could provide patches to gnome upstream to make sure it
> works without the need for systemd.
> 
> I suggest that if you really want to keep this going, convincing gnome
> upstream that running without systemd is still important is the way to
> go, not taking it out on the Gentoo gnome team, and the best way to
> convince gnome would probably be to provide patches.
> 
> All of the complaining and taking it out on our gnome team is not
> productive. Asking our gnome team to carry downstream patches is also
> not productive, because they would end up being forced to update these
> patches against every new gnome release.
> 
> It is not a regression if a new version of gnome mrequires systemd
> and does not work with OpenRc; it is a design choice.
> 
> The community doesn't need to decide whether systemd can go stable;
> The community would only need to decide if we switch the default init
> system to systemd. No one is proposing this.

+10000

We, the gnome team, did our best to delay this dependency by talking to
upstream submitting patches, etc. But as many have written already, not
all of gnome upstream cares as they decided Gnome should be monolithic
now.

This is not our decision but we still have to handle the consequences.

For the record we did and still do support setups that upstream does not
care about.
 * In the past, we had policykit/polkit optional, we had to stop that
since it is now too tied in to be decently maintained at our level
 * We had pulseaudio optional, again, this is now over in some of the
core components of Gnome, but we do keep it optional were possible
 * We maintain networkmanager and bluetooth support optional, and this
has been the case since 3.2 iirc even though upstream flat out refuses
to merge our perfectly fine patches

Keeping systemd optional in Gnome cannot be achieved by the Gentoo Gnome
team. If someone comes up with a solution to have logind without
systemd, we will gladly include it but remember that a few devs (4/5
afaik) already tried and sadly failed.

So until there is an alternative, Gnome 3.8 is going stable as the gnome
team decided because it provides the best Gnome 3 experience yet. Gnome
3.6 is almost one year old and unsupported, Gnome 2 is over 4 years old
and should already have left the tree but we didn't do so because we
wanted our users to have a decently stable desktop to work with,
whatever it is made of.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

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

Re: [gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Tom Wijsman]

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

On Fri, 09 Aug 2013 08:39:20 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 09/08/13 04:05, Zac Medico wrote:
>
> > This seems like a possible applicatio for "mix-in" profiles like
> > Funtoo uses:
> >
> >    http://www.funtoo.org/wiki/Flavors_and_Mix-ins

Thanks, that definitely looks interesting; reading it I actually would
love to see this implemented to ease the user from switching from one
to another init system, or whatever needs switching in the future.

> What if eg. profiles/targets/desktop would have sub directory 
>
> profiles/targets/desktop/systemd which would have a 'parent' of '..' 
> with USE="-consolekit systemd" and more importantly, the could-be
> kludge to setup the /usr-move, the could-be environment variable to
> disable functionality of gen_usr_ldscript...
>
> profiles/targets/desktop/gnome with 'parent' of '..' and
> '../../systemd' ...

Let me stop you right here; part of this idea came to mind yesterday,
but I saw a flaw in it so I did not suggest it:

  What if a certain profile needs to support two such profiles (eg.
  upstart and systemd) that have conflicting choices (eg. one profile
  lists -systemd, the other systemd); then you can no longer list both
  as a parent as they will simply clash and make conflicting changes.

Of course this isn't a problem for this situation, but it may become a
problem in a future situation if we're going to follow this practice;
that's why I think now that mix-in profiles fit the purpose better.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Samuli Suominen]

On 09/08/13 11:46, Tom Wijsman wrote:
> On Fri, 09 Aug 2013 08:39:20 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> On 09/08/13 04:05, Zac Medico wrote:
>>
>>> This seems like a possible applicatio for "mix-in" profiles like
>>> Funtoo uses:
>>>
>>>     http://www.funtoo.org/wiki/Flavors_and_Mix-ins
>
> Thanks, that definitely looks interesting; reading it I actually would
> love to see this implemented to ease the user from switching from one
> to another init system, or whatever needs switching in the future.
>
>> What if eg. profiles/targets/desktop would have sub directory
>>
>> profiles/targets/desktop/systemd which would have a 'parent' of '..'
>> with USE="-consolekit systemd" and more importantly, the could-be
>> kludge to setup the /usr-move, the could-be environment variable to
>> disable functionality of gen_usr_ldscript...
>>
>> profiles/targets/desktop/gnome with 'parent' of '..' and
>> '../../systemd' ...
>
> Let me stop you right here; part of this idea came to mind yesterday,
> but I saw a flaw in it so I did not suggest it:
>
>    What if a certain profile needs to support two such profiles (eg.
>    upstart and systemd) that have conflicting choices (eg. one profile
>    lists -systemd, the other systemd); then you can no longer list both
>    as a parent as they will simply clash and make conflicting changes.

Sure you can, simply by counter effecting the parent as suggested, if 
parent lists '-systemd' then the actual profile can set 'systemd'
Plus it would be the main systemd sub profile that would be 'top most' 
in the parent file, causing it to enable 'systemd' even if the 'second 
top most' disables it

> Of course this isn't a problem for this situation, but it may become a
> problem in a future situation if we're going to follow this practice;
> that's why I think now that mix-in profiles fit the purpose better.

I'm not seeing the problem...

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 09 Aug 2013 08:27:23 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> [snip]
> >> So would you stabilize a package that works with paludis, but not
> >> with portage? Ouch. It should probably not be in the tree in the
> >> first place, but I that's not what I have in mind here.
> > 
> > This isn't a good example, because the PMS compliance governs over
> > this.
> > 
> 
> It is an excellent example. If it doesn't work with portage that's a
> QA-failure and reason to mask until fixed. As PMS is incomplete and
> often not reflecting reality it's not a good baseline.

So, this can also be interpreted as masking Portage until it is fixed;
there is no implication that the package not working with Portage is a
QA failure of the package, as it might be Portage having a PMS failure
which the package. This is not an excellent example, it is confusing...

I do not argue that packages get masked due to QA failures; but I don't
see how GNOME 3.8 only working with systemd, is to be a QA failure?

So, unless you come with a better example and show it is a QA failure,
I won't see what meaning this confusing example has in this discussion.

> >> I generally expect packages to work with... now be surprised...
> >> BOTH init systems, although I don't like systemd. If it doesn't
> >> work with one, then it's a bug. Bugs block stabilization.
> >> It is a _REGRESSION_. Ask the arch team about the meaning of
> >> regression if unsure.
> > 
> > It's not a regression; actually, it's quite common to drop features
> > that can no longer be supported. I don't see us blocking
> > stabilization for other cases in the Portage tree where a feature
> > has been dropped.
> 
> It is a regression: If it doesn't work with OpenRC I can't use it
> (same with portage), and thus it deserves a liberal dose of bugs and
> masking if bugs don't get fixed on time.

It doesn't intend to work with OpenRC; so, it is not a regression.

Regression testing is done to test whether functionality broke,
functionality that is specified as requirements of the package; as
OpenRC is no longer a requirement, it can not be a regression.

There are also no bugs as a result of that, or at least not in the
terms of those that need fixing; they are rather a feature request.

> What makes this situation so difficult is that it's not a single
> random package, but one of the bigger desktop environments that has
> painted itself into a corner.

It's better for them to be vivid in a corner than for them to dry out;
the situation might or might not be interpretable as difficult, either
way things are the way things are and it's not so easy to change.

> (Plus an uncooperative upstream, so all the "blame" gets thrown at
> the gentoo maintainers from both sides. Awesome way to destroy crew
> morale :) )

Why should upstream do additional work, causing them extra time,
keeping them back from progressing; there is much more work they need
to do than to support an alternative init system some minority uses.

If we can't write up the patches to make it work, why can they; they
need to do the equal amount of work that we do. For this to happen
some big initiatives are needed; ranging from trying to really convince
upstream people to do the work, or convincing downstream people to jump
in and help port it to work with the alternative init system.

Until either of that happens; upstream won't really see the need and
downstream won't be able to provide a patch, so "uncooperative"
people upstream and "blame" downstream are just normal things. What
we're really missing is enough people that want to make it happen;
which means, they give up part of their time to it that they could
perhaps invest in something else that might be more necessary.

Though, an init system standard might be the most promising approach.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Chí-Thanh Christopher Nguyễn]

Pacho Ramos schrieb:
>> If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
>> patches that make it possible to install Gnome 3.8 without systemd again?
>> Only make it possible, not turn it into a configuration which the Gnome team
>> supports.
> 
> We have discussed this some times in the team, the problem is that we
> don't think we should provide "by default" a setup that is not working
> properly: powermanagement, multiseat support and gdm service handling

I don't say that it should be the default.

> Also, if that people reports problems, we would
> close them as WONTFIX -> migrate to systemd

That's what I meant when I wrote not a configuration that Gnome team supports.

> - You can ignore the warnings, news and suggestions and, even moving
> from udev to systemd ebuild, keep booting with openRC and using systemd
> as device manager
> - You can put systemd in package.provides to even keep running udev

The good part about package.provided is that users definitely know that they
are running an unsupported configuration with it. The bad part is that
putting systemd in package.provided is a bit dangerous, as this can lead to
udev unmerge on depclean if you are not careful.

> But we (gnome team) cannot support that setups and, then, we prefer to
> point people to run the supported one (with systemd running), keeping
> the other "alternatives" for people that will be able to live with a
> semi broken desktop and don't expect us to fix their bugs and fight to
> upstream because XX thing doesn't work out of systemd.

We agree on the following I think:
* If you install Gnome, then systemd should be installed along with it by
default.
* Gnome team can ignore any reports of breakage on systems that don't run
systemd.

The remaining question is only whether you will accept patches to ebuilds
that make the systemd dependency optional.
If you are too concerned about invalid bug reports, even a new profile could
be created. systemd could then be package.use.force'd in the base profile and
only un-forced in a special gnome-nosystemd profile, which contains a
profile.bashrc warning (like from the server profile) that tells users to not
report any bugs about Gnome.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
> It is not a regression if a new version of gnome mrequires systemd
> and does not work with OpenRc; it is a design choice.

I could claim the "design choice" thing for anything as well.

Actually blender upstream does that for the brokenness of their build
system. Now what? I just stop fixing it? Maybe, but then I will
definitely not stabilize it.

We are not just talking about random ebuild features here that have been
dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
_regression_.

You see, I am not criticising the work of the gnome team, only the
stabilization matter. I personally don't care about gnome, but about our
policy to a certain extend. And I feel our policy is being violated
here. Not because you ignore it, but because you disagree.

But none of your arguments make any logical sense to me why this
regression should be treated differently. "Upstream does..." is _never_
a reason to say a regression is a feature. It is a reason to not support
it in stable arch or even not at all, depending on the case.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 09 Aug 2013 01:26:08 +0100
Mike Auty <ikelos@gentoo.org> wrote:

> I would like to think that open source developers working on such a
> large and integral project might listen to their users.

Listening comes at a price; you can't listen to everyone at the same
time, all you will hear is noise because all the voices clash. So,
you've got to listen to a selective bit of users and satisfy them;
after all you can't satisfy everyone. Resources are finite...

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

iQEcBAEBAgAGBQJSBLfqAAoJEJWyH81tNOV9ng4IAIIZwecBzyvZT+5fsHN9aT4z
xzdIS+HDqsXzyBnxmHMK1HNgDCW3hEc+subJtOih9uKZrwGwFjAF/pWstNsCZ1sw
1U1Z/vN1vOiP/WbkhaKo5AvsMBLWENLTDeXuJF8QUDOuMVUlJ2/nSKwkyGQaK2pA
1qijdGBmqK4+LwmaUtSIAQEYsUTPaPW1lE7+aFycxELzYRCg74Tve3j7QOPDP9c2
sivyU+89dX59w3I2EQG63ZGntYt2XJ3kEui7VXApY6Z8h0tGq2oVm6qtpc9cPJ0n
0XhQqfhE7eGzXerO0WG3+5h7SipqDC9R3NeSlipChs1Mqy9j53RAe7geGyT1Egg=
=G3RF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn
escribió:
> Pacho Ramos schrieb:
> >> If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
> >> patches that make it possible to install Gnome 3.8 without systemd again?
> >> Only make it possible, not turn it into a configuration which the Gnome team
> >> supports.
> > 
> > We have discussed this some times in the team, the problem is that we
> > don't think we should provide "by default" a setup that is not working
> > properly: powermanagement, multiseat support and gdm service handling
> 
> I don't say that it should be the default.
> 
> > Also, if that people reports problems, we would
> > close them as WONTFIX -> migrate to systemd
> 
> That's what I meant when I wrote not a configuration that Gnome team supports.
> 
> > - You can ignore the warnings, news and suggestions and, even moving
> > from udev to systemd ebuild, keep booting with openRC and using systemd
> > as device manager
> > - You can put systemd in package.provides to even keep running udev
> 
> The good part about package.provided is that users definitely know that they
> are running an unsupported configuration with it. The bad part is that
> putting systemd in package.provided is a bit dangerous, as this can lead to
> udev unmerge on depclean if you are not careful.
> 

This makes me think what is the problem with people moving to systemd as
udev provider (even running openrc) :/
1. The first solution (moving to systemd as udev provider) would be
"easy" and would behave as bad as openBSD does (having the unsupported
and mid working setup)
2. About the other one: probably somebody adding systemd to
package.provide *on purpose* will remember to know that he needs a
device manager (either udev or eudev) and don't let depclean remove
it :|

Other possible solution would be the following:
3. Add a "openrc-force" USE flag to offending packages. This USE flag
would be masked in all profiles, needing users to unmask it locally (the
packages would warn about it when enabling and so)

Re: [gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Tom Wijsman]

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

On Fri, 09 Aug 2013 11:58:11 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 09/08/13 11:46, Tom Wijsman wrote:
> > On Fri, 09 Aug 2013 08:39:20 +0300
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >
> >> On 09/08/13 04:05, Zac Medico wrote:
> >>
> >>> This seems like a possible applicatio for "mix-in" profiles like
> >>> Funtoo uses:
> >>>
> >>>     http://www.funtoo.org/wiki/Flavors_and_Mix-ins
> >
> > Thanks, that definitely looks interesting; reading it I actually
> > would love to see this implemented to ease the user from switching
> > from one to another init system, or whatever needs switching in the
> > future.
> >
> >> What if eg. profiles/targets/desktop would have sub directory
> >>
> >> profiles/targets/desktop/systemd which would have a 'parent' of
> >> '..' with USE="-consolekit systemd" and more importantly, the
> >> could-be kludge to setup the /usr-move, the could-be environment
> >> variable to disable functionality of gen_usr_ldscript...
> >>
> >> profiles/targets/desktop/gnome with 'parent' of '..' and
> >> '../../systemd' ...
> >
> > Let me stop you right here; part of this idea came to mind
> > yesterday, but I saw a flaw in it so I did not suggest it:
> >
> >    What if a certain profile needs to support two such profiles (eg.
> >    upstart and systemd) that have conflicting choices (eg. one
> > profile lists -systemd, the other systemd); then you can no longer
> > list both as a parent as they will simply clash and make
> > conflicting changes.
> 
> Sure you can, simply by counter effecting the parent as suggested, if 
> parent lists '-systemd' then the actual profile can set 'systemd'
> Plus it would be the main systemd sub profile that would be 'top
> most' in the parent file, causing it to enable 'systemd' even if the
> 'second top most' disables it
> 
> > Of course this isn't a problem for this situation, but it may
> > become a problem in a future situation if we're going to follow
> > this practice; that's why I think now that mix-in profiles fit the
> > purpose better.
> 
> I'm not seeing the problem...

Eh, I'm having a hard time to wrap my head around your paragraph; but I
think that you're referring to different things than I do, so I don't
really see how it can be done that way. Let's talk in terms of files.

Let me pose it differently to get it more clear:

  profiles/targets/desktop/something
    with 'parent' of '..' and '../systemd' and '../upstart'.

  profiles/targets/desktop/systemd
    which sets some USE flags, masks and / or unmasks.

  profiles/targets/desktop/upstart
    which sets things that conflict with the systemd profile.

If you now select profiles/targets/desktop/something; it doesn't allow
you to run something with both systemd and upstart, 'cause it conflicts.

What actual file change would you make to solve this? I don't see it...

(If the user instead selects a mix-in on top of a profile, it works.)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Chí-Thanh Christopher Nguyễn]

Pacho Ramos schrieb:

> This makes me think what is the problem with people moving to systemd as
> udev provider (even running openrc) :/

You can't use eudev in that case.

> 2. About the other one: probably somebody adding systemd to
> package.provide *on purpose* will remember to know that he needs a
> device manager (either udev or eudev) and don't let depclean remove
> it :|

package.provided is dangerous, and users better avoid it if there is an
alternative way to achieve the same thing.

> Other possible solution would be the following:
> 3. Add a "openrc-force" USE flag to offending packages. This USE flag
> would be masked in all profiles, needing users to unmask it locally (the
> packages would warn about it when enabling and so)

Ok so we have these options:

1. keep systemd as hard dependency (current)
2. IUSE="+systemd" or "openrc-force" with ewarn when set to unsupported state
3. #2 + systemd in package.use.force, can be unforced via profile or manually
4. #2 + openrc-force in package.use.mask, can be unmasked by the user

In any case, a user running Gnome without systemd will have to take extra
actions that acknowledge that his configuration is unsupported.

Question is, which solutions are acceptable to the Gnome team? :)


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>> It is not a regression if a new version of gnome mrequires systemd
>> and does not work with OpenRc; it is a design choice.
>
> We are not just talking about random ebuild features here that have been
> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
> _regression_.

How does not supporting OpenRC matter for Gentoo?  Gentoo isn't
OpenRC.  OpenRC is just one init system that Gentoo supports.  You can
run Gentoo without it - indeed you can run Gentoo without any init at
all (via Prefix).

>
> You see, I am not criticising the work of the gnome team, only the
> stabilization matter. I personally don't care about gnome, but about our
> policy to a certain extend. And I feel our policy is being violated
> here. Not because you ignore it, but because you disagree.

I don't see any policy being violated here.  If I did, I'd be happy to
ask that it be changed.  The Gnome team already plans to issue
news/docs/etc so that stable users don't get sidegraded or whatever
you want to call it without warning, and so that they understand the
full implications of upgrading to 3.8.  Once users do move to 3.8,
they're going to have a nice stable experience, just with a different
init system.

That's basically what stable is about IMHO.

Sure, systemd isn't completely supported by every package in the tree
with unit files/etc, but that has been steadily improving and all
indications are that this trend will continue.  Missing unit files are
also relatively easy for users to fetch on their own (and hopefully
submit back to us in bugs) - one of the main advantages of systemd is
that unit files are more cross-platform and there are examples
floating around for just about everything already.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El vie, 09-08-2013 a las 12:22 +0200, Chí-Thanh Christopher Nguyễn
escribió:
[...]
> Ok so we have these options:
> 
> 1. keep systemd as hard dependency (current)
> 2. IUSE="+systemd" or "openrc-force" with ewarn when set to unsupported state
> 3. #2 + systemd in package.use.force, can be unforced via profile or manually
> 4. #2 + openrc-force in package.use.mask, can be unmasked by the user
> 
> In any case, a user running Gnome without systemd will have to take extra
> actions that acknowledge that his configuration is unsupported.
> 
> Question is, which solutions are acceptable to the Gnome team? :)
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 

I vote for the openrc-force in package.use.mask, relying on people
unmasking it locally after knowing what problems will hit:
https://bugs.gentoo.org/show_bug.cgi?id=480336

The systemd USE flag issue is already being worked in:
https://bugs.gentoo.org/show_bug.cgi?id=479986

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 09 Aug 2013 11:30:17 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
> > It is not a regression if a new version of gnome mrequires systemd
> > and does not work with OpenRc; it is a design choice.
> 
> I could claim the "design choice" thing for anything as well.

That's the whole point about it; because it is their (upstream) design
choice, it is not a regression for them. So, the only one here claiming
it now to be a regression is you; let's get back to the link you gave

http://blogs.gentoo.org/ago/2012/08/22/when-you-should-block-a-stabilization/

which mentions some types in an example

    1) builsystem issue
    2) ebuild issue
    3) means specific software problem

but does not actually define what a regression is; so, because the lack
of downstream definition all we can do is follow what upstream does,
alternatively discuss this to death but that would be bike shedding.

Anyone here can claim here that it is a regression or design choice,
but nobody can actually prove it because of the lack of a definition;
so, we should just resort to what upstream intends to do in this case.

Even assuming the types as a definition, a "specific software problem"
is again free for interpretation; so, it doesn't properly define it.

> Actually blender upstream does that for the brokenness of their build
> system. Now what? I just stop fixing it? Maybe, but then I will
> definitely not stabilize it.

We're not talking about brokenness here, rather about intents; please
note that users in the first place choose for a package because of what
upstream intends, there is no obligation for you to keep it unstable
because upstream made the design choice to remove a certain use case.

If we had to stop stabilization for every use case in the tree that was
removed, we wouldn't have any recent version of anything stabilized;
why should GNOME 3.8 be an exception to this, I really don't see why...

> It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
> _regression_.

I could state that the exact opposite easily; so, here it is:

  It _was_ a major feature, therefore it can not be a regression. It
  does not matter for Gentoo or its users.

Without a definition or consensus, such statements are meaningless.

> You see, I am not criticising the work of the gnome team, only the
> stabilization matter. I personally don't care about gnome, but about
> our policy to a certain extend.
>
> And I feel our policy is being violated here.

Not sure which policy you are referring to; all I am reading are
merely opinions, that don't stabilization without any consensus.

> Not because you ignore it, but because you disagree.

I disagree with you, I do not disagree with any policy; if so, which?

> But none of your arguments make any logical sense to me why this
> regression should be treated differently.

As far as I am aware; there are two sides to this so I can state the
exact same that I don't see any logical sense in what you say, so
I can just say that you're trying to treat it differently too.

There isn't even an agreement that this is an actual regression.

> "Upstream does..." is _never_ a reason to say a regression is a
> feature.
>
> It is a reason to not support it in stable arch or even not
> at all, depending on the case.

Why not? Those reasons are merely your opinions; without evidence or
argreement, you can't say it is or isn't. It might or might not be...

Let's await for that to decide whether this is a regression, before we
start reasoning; otherwise we would be basing ourselves on assumptions.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] [typo] Re: Re: Multiple implementations shouldn't block Gentoo's progress.

[Rich Freeman]

On Fri, Aug 9, 2013 at 3:26 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>
> For example, gnome-base/gnome-settings-daemon could be p.mask in non-systemd
> profiles instructing the users to switch to the systemd profile and point to
> the guide you were referring to
> As in, the benefit would be informative mask message
>

I'm not convinced that is a good idea unless maybe we do something
like mix-ins (and I just haven't though through that  - there might be
issues with that as well).

Right now there is no requirement to use the gnome profile in order to
use gnome - it is just a convenience.  Granted, you could unmask it
and stay on base, but unmasking things creates other problems - you
can't tie an unmask to a particular reason for something being masked
(so if you unmask it you don't get warning before something gets
treecleaned, for example).  That issue doesn't apply as much to
gnome-settings-daemon, but in general I don't think we should go
masking things just to get the user to change profiles.

In general I'd avoid any requirement to use a non-base profile.
Obviously using the right arch/prefix profile makes sense as those are
fundamental config changes and they're all minimalist profiles anyway.
 The issues come when you force users to use non-minimalist profiles
where we start forcing packages/decisions the users don't agree with.
(And yes, I realize the whole thread is about forcing a decision users
don't agree with - but we don't have much choice there.)

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 09 Aug 2013 19:31:22 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> You just removed the upgrade path for users.

The upgrade path is to install systemd or to implement openrc support.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/09/2013 06:27 PM, Rich Freeman wrote:
> On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>>> It is not a regression if a new version of gnome mrequires systemd
>>> and does not work with OpenRc; it is a design choice.
>>
>> We are not just talking about random ebuild features here that have been
>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
>> _regression_.
> 
> How does not supporting OpenRC matter for Gentoo?  Gentoo isn't
> OpenRC.  OpenRC is just one init system that Gentoo supports.  You can
> run Gentoo without it - indeed you can run Gentoo without any init at
> all (via Prefix).

You just removed the upgrade path for users.

If that's not a regression ... well ... err ...

Somehow I get really confused by this selective perception (anyone
remembering the KDE overlay getting paludised and the fallout from that?)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ciaran McCreesh]

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

On Fri, 09 Aug 2013 19:31:22 +0800
Patrick Lauer <patrick@gentoo.org> wrote:
> Somehow I get really confused by this selective perception (anyone
> remembering the KDE overlay getting paludised and the fallout from
> that?)

That's a very selective perception there. If you mean the fully
documented kdebuild-1 EAPI, whose features are mostly in EAPI 5 now,
then I remember Gentoo getting a lot of valuable experience that was
used to decide how to improve the package format.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
> > On Fri, 09 Aug 2013 19:31:22 +0800
> > Patrick Lauer <patrick@gentoo.org> wrote:
> > 
> >> You just removed the upgrade path for users.
> > 
> > The upgrade path is to install systemd or to implement openrc support.
> > 
> Invalid upgrade path.
> 
> "The upgrade path is to install Fedora" is about as reasonable, and also
> not acceptable.
> 
> 

The upgrade path is to run systemd, not migrate to fedora. As simply as
such

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/09/2013 07:26 PM, Tom Wijsman wrote:
> On Fri, 09 Aug 2013 19:31:22 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
>> You just removed the upgrade path for users.
> 
> The upgrade path is to install systemd or to implement openrc support.
> 
Invalid upgrade path.

"The upgrade path is to install Fedora" is about as reasonable, and also
not acceptable.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 09 Aug 2013 19:39:08 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
> > On Fri, 09 Aug 2013 19:31:22 +0800
> > Patrick Lauer <patrick@gentoo.org> wrote:
> > 
> >> You just removed the upgrade path for users.
> > 
> > The upgrade path is to install systemd or to implement openrc
> > support.
> > 
> Invalid upgrade path.
> 
> "The upgrade path is to install Fedora" is about as reasonable, and
> also not acceptable.

Your upgrade path is no longer an upgrade; the other ones are, and as
said before, running Gentoo has no implication that OpenRC must be ran.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 9 Aug 2013 12:37:26 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Fri, 09 Aug 2013 19:31:22 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
> > Somehow I get really confused by this selective perception (anyone
> > remembering the KDE overlay getting paludised and the fallout from
> > that?)
> 
> That's a very selective perception there. If you mean the fully
> documented kdebuild-1 EAPI, whose features are mostly in EAPI 5 now,
> then I remember Gentoo getting a lot of valuable experience that was
> used to decide how to improve the package format.

Not sure how this is still relevant to the Gnome 3.8 stabilization;
Patrick's example brought some irrelevant matters to mind, but what
this really is about as he intended is a "QA violation".

He just clarified in the other thread as well as on IRC that by this QA
violation he means that there is no proper upgrade path; so, I no
longer see any use in that example as it has became clear without it.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[vivo75]

On 08/09/13 13:38, Pacho Ramos wrote:
> El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
>> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>>> On Fri, 09 Aug 2013 19:31:22 +0800
>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>
>>>> You just removed the upgrade path for users.
>>> The upgrade path is to install systemd or to implement openrc support.
>>>
>> Invalid upgrade path.
>>
>> "The upgrade path is to install Fedora" is about as reasonable, and also
>> not acceptable.
>>
>>
> The upgrade path is to run systemd, not migrate to fedora. As simply as
> such
>
>
is systemd useful if not run with PID=1 ? Honest question

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> You just removed the upgrade path for users.
>

Just install systemd.  There really isn't any practical alternative.
Gentoo with systemd is as Gentooish a configuration as Gentoo with
OpenRC, or Gentoo with libav, or Gentoo with emacs.

>
> Somehow I get really confused by this selective perception (anyone
> remembering the KDE overlay getting paludised and the fallout from that?)

I never had a problem with it.  I would have concerns with non-PMS
EAPIs in the main tree, but overlays can do whatever they want.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/09/2013 12:27 PM, Rich Freeman wrote:
> On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>>> It is not a regression if a new version of gnome mrequires systemd
>>> and does not work with OpenRc; it is a design choice.
>>
>> We are not just talking about random ebuild features here that have been
>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
>> _regression_.
> 
> How does not supporting OpenRC matter for Gentoo?

The question puzzles me. For one it is
* an implementation of virtual/service-manager which is in @system
* it is the default init system in stage3
* OpenRC is developed by gentoo devs, which means we especially want to
make/keep it a usable tool. If we can't, then there is a regression. It
doesn't matter whose fault it is. This is not about blame.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Walter Dnes]

On Thu, Aug 08, 2013 at 11:40:58AM -0400, Ian Stakenvicius wrote

> It may be pertinent for this reason (a "smoother" upgrade path) and
> this reason alone, to stabilize gnome-3.6 first -- just to get into
> gnome3 (and get gnome-2 removed) without having to also deal with the
> systemd migration at the same time.

  If you've followed the user mailing list, you'll know that I'm not
exactly a systemd fanboi, and as per my sig, I don't have any stake in
this battle.  But if you want to do a 2-step switch to GNOME 3.8, then
why not...

1) switch from openrc to systemd first

2) once you have that working, then worry about upgrading to GNOME 3.8

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 09 Aug 2013 14:36:05 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 08/09/2013 12:27 PM, Rich Freeman wrote:
> 
> > How does not supporting OpenRC matter for Gentoo?
> 
> The question puzzles me. For one it is
> * an implementation of virtual/service-manager which is in @system

But systemd is an implementation of that as well; isn't it sufficient
that only one implementation satisfies it to run GNOME 3.8, and that the
others implementations are blocked until supported?

> * it is the default init system in stage3

What if the default were systemd? It would be a whole different story.

Nothing prohibits a systemd stage3 from being brought out as well;
and when that happens, it isn't really a default but rather a choice...

> * OpenRC is developed by gentoo devs, which means we especially want
> to make/keep it a usable tool.

Let's say that I were to develop a system with some other Gentoo devs;
that doesn't mean we are able to make everything in the tree support
that system, making it an usable tool for everything is unrealistic
especially in a world where people will pursue alternatives and not
collaborate. There's nothing bad about them doing that, we can't
satisfy everyone; if we were, we wouldn't even have systemd in tree...

> If we can't, then there is a regression.

If I tried to make something support that system, but failed to, and
the develpers fail as well; I see that as a failure and we decide to 
not support each other, unless resources become available to do so.

An attempt to support, which follows by a decision to not support it;
is not a regression, it's a design choice to move forward.

> It doesn't matter whose fault it is. This is not about blame.

Making such a design choice isn't a fault. There is no need for blame.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 09/08/13 14:31, Patrick Lauer wrote:
> On 08/09/2013 06:27 PM, Rich Freeman wrote:
>> On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
>>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>>>> It is not a regression if a new version of gnome mrequires systemd
>>>> and does not work with OpenRc; it is a design choice.
>>>
>>> We are not just talking about random ebuild features here that have been
>>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
>>> _regression_.
>>
>> How does not supporting OpenRC matter for Gentoo?  Gentoo isn't
>> OpenRC.  OpenRC is just one init system that Gentoo supports.  You can
>> run Gentoo without it - indeed you can run Gentoo without any init at
>> all (via Prefix).
>
> You just removed the upgrade path for users.

Upgrade with an requirement of reading a guide to finish it is still an 
upgrade.  This became possible thanks to Portage news items, but I don't 
count that as mandatory either.

> If that's not a regression ... well ... err ...
>
> Somehow I get really confused by this selective perception (anyone
> remembering the KDE overlay getting paludised and the fallout from that?)

...

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 09/08/13 15:36, hasufell wrote:
> On 08/09/2013 12:27 PM, Rich Freeman wrote:
>> On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
>>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>>>> It is not a regression if a new version of gnome mrequires systemd
>>>> and does not work with OpenRc; it is a design choice.
>>>
>>> We are not just talking about random ebuild features here that have been
>>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
>>> _regression_.
>>
>> How does not supporting OpenRC matter for Gentoo?
>
> The question puzzles me. For one it is
> * an implementation of virtual/service-manager which is in @system
> * it is the default init system in stage3
> * OpenRC is developed by gentoo devs, which means we especially want to
> make/keep it a usable tool. If we can't, then there is a regression. It
> doesn't matter whose fault it is. This is not about blame.

baselayout-1, then later baselayout-2 and OpenRC were all created 
because there was an need and no suitable ready solutions
systemd however is starting to look like a viable ready solution to 
switch to
it's definately not an regression to switch to actively maintained 
software, it's more of an improvement because OpenRC has been stalled 
ever since Roy stopped hacking on it (all work put in by vapier, 
WilliamH, and others is of course appericiated)
you know it's true if you have been with gentoo enough long

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michał Górny]

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

Dnia 2013-08-09, o godz. 14:14:12
"vivo75@gmail.com" <vivo75@gmail.com> napisał(a):

> On 08/09/13 13:38, Pacho Ramos wrote:
> > El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
> >> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
> >>> On Fri, 09 Aug 2013 19:31:22 +0800
> >>> Patrick Lauer <patrick@gentoo.org> wrote:
> >>>
> >>>> You just removed the upgrade path for users.
> >>> The upgrade path is to install systemd or to implement openrc support.
> >>>
> >> Invalid upgrade path.
> >>
> >> "The upgrade path is to install Fedora" is about as reasonable, and also
> >> not acceptable.
> >>
> >>
> > The upgrade path is to run systemd, not migrate to fedora. As simply as
> > such
> >
> >
> is systemd useful if not run with PID=1 ? Honest question

Not a honest question but either honest troll, or you're awfully lazy
and just making noise here.

So the answer is: yes, it's quite useful when run with PID!=1. It's
called systemd user instance (something OpenRC totally can't handle)
and it can be used to manage user services.

But I have no idea how is that relevant since you obviously know that
the problem here requires running systemd as PID 1.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michał Górny]

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

Dnia 2013-08-09, o godz. 13:45:25
Tom Wijsman <TomWij@gentoo.org> napisał(a):

> On Fri, 09 Aug 2013 19:39:08 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
> > On 08/09/2013 07:26 PM, Tom Wijsman wrote:
> > > On Fri, 09 Aug 2013 19:31:22 +0800
> > > Patrick Lauer <patrick@gentoo.org> wrote:
> > > 
> > >> You just removed the upgrade path for users.
> > > 
> > > The upgrade path is to install systemd or to implement openrc
> > > support.
> > > 
> > Invalid upgrade path.
> > 
> > "The upgrade path is to install Fedora" is about as reasonable, and
> > also not acceptable.
> 
> Your upgrade path is no longer an upgrade; the other ones are, and as
> said before, running Gentoo has no implication that OpenRC must be ran.

I can think of at least a few examples where 'upgrade path' actually
involved replacing one package with another and yet nobody complains
about that.

This one is *so special* just because we have a few folks which really
have nothing useful to do and instead spit their systemd hatred on
gentoo-dev@ and expect others to join their stupid vendetta.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> You just removed the upgrade path for users.
>>
>
> Just install systemd.  There really isn't any practical alternative.
> Gentoo with systemd is as Gentooish a configuration as Gentoo with
> OpenRC, or Gentoo with libav, or Gentoo with emacs.

Again, I repeat my-self.

Please stop writing these statements!

There was no decision to support Gentoo using any other layout than
openrc (baselayout).

There is *HUGE* difference between optional components and core components.

Claiming that Gentoo can use alternate layout is same as alternate
that freebsd port is stable or that intel icc can be used as compiler.
It has broad implications, which is far from the actual component
usage or its own dependencies.

If you have the agenda to switch to systemd, and you hide your
intention in the argument of supporting multiple layouts, please do
not hide and state so clearly.

But do not claim that Gentoo with different layout than baselayout is
still formal Gentoo, and is supported by the Gentoo developers.

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 4:49 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 09/08/13 15:36, hasufell wrote:
>>
>> On 08/09/2013 12:27 PM, Rich Freeman wrote:
>>>
>>> On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
>>>>
>>>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>>>>>
>>>>> It is not a regression if a new version of gnome mrequires systemd
>>>>> and does not work with OpenRc; it is a design choice.
>>>>
>>>>
>>>> We are not just talking about random ebuild features here that have been
>>>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
>>>> _regression_.
>>>
>>>
>>> How does not supporting OpenRC matter for Gentoo?
>>
>>
>> The question puzzles me. For one it is
>> * an implementation of virtual/service-manager which is in @system
>> * it is the default init system in stage3
>> * OpenRC is developed by gentoo devs, which means we especially want to
>> make/keep it a usable tool. If we can't, then there is a regression. It
>> doesn't matter whose fault it is. This is not about blame.
>
>
> baselayout-1, then later baselayout-2 and OpenRC were all created because
> there was an need and no suitable ready solutions
> systemd however is starting to look like a viable ready solution to switch
> to
> it's definately not an regression to switch to actively maintained software,
> it's more of an improvement because OpenRC has been stalled ever since Roy
> stopped hacking on it (all work put in by vapier, WilliamH, and others is of
> course appericiated)
> you know it's true if you have been with gentoo enough long
>

At least we know what ssuominen thinks... some prople are trying to
hijack the Gentoo project at the excuse of Gnome to switch into
specific vendor solution, and be on its mercies from now on. This was
the exact plan of whoever put all these $$ in
udev/systemd/gnome/fedora and effect the entire ecosystem, and slowly
own the entire solutions. As Linux userland become more and more
monolithic per the plan of that vendor, and if we yield, there will be
no real difference between Fedora and Gentoo, so what have we
accomplished? There come the new Microsoft and conquered the free open
source world using $$ and ambassadors.

What we basically say is that Gentoo cannot have their own agenda and
now submit to dictation of a single vendor of how Linux should be
managed and run.

To provide good service to our users we need a clear stand, what will
developers (throughout the tree) will be maintaining. If a user
installs a component he does expect it to work and maintained. And we
cannot force all developers to support two different layouts, and we
cannot allow developers to support layout of their choice, as users
will get a totally broken solution, because of the aspirations of
developer/herd they get different level of support.

I don't care if systemd is worked on by people, however it must be
clearly mark as unstable as long as there is no decision to switch.

Regards,
Alon Bar-Lev

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Chí-Thanh Christopher Nguyễn]

Alon Bar-Lev schrieb:
> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>> You just removed the upgrade path for users.
>>>
>> Just install systemd.  There really isn't any practical alternative.
>> Gentoo with systemd is as Gentooish a configuration as Gentoo with
>> OpenRC, or Gentoo with libav, or Gentoo with emacs.
> Again, I repeat my-self.
>
> Please stop writing these statements!
>
> There was no decision to support Gentoo using any other layout than
> openrc (baselayout).

I think there may be a misunderstanding here. He only said that if you
want to run Gnome 3.8, then switch to systemd. Because the Gnome team
will not support any other configuration.

He did not say that everyone should install systemd, nor that you need
to support such a configuration.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Alon Bar-Lev schrieb:
>> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>>> You just removed the upgrade path for users.
>>>>
>>> Just install systemd.  There really isn't any practical alternative.
>>> Gentoo with systemd is as Gentooish a configuration as Gentoo with
>>> OpenRC, or Gentoo with libav, or Gentoo with emacs.
>> Again, I repeat my-self.
>>
>> Please stop writing these statements!
>>
>> There was no decision to support Gentoo using any other layout than
>> openrc (baselayout).
>
> I think there may be a misunderstanding here. He only said that if you
> want to run Gnome 3.8, then switch to systemd. Because the Gnome team
> will not support any other configuration.
>
> He did not say that everyone should install systemd, nor that you need
> to support such a configuration.

So users will have gnome working but not any other component? How can
this a good service for  users?

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Arun Raghavan]

On 9 August 2013 20:20, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>> Alon Bar-Lev schrieb:
>>> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>>>> You just removed the upgrade path for users.
>>>>>
>>>> Just install systemd.  There really isn't any practical alternative.
>>>> Gentoo with systemd is as Gentooish a configuration as Gentoo with
>>>> OpenRC, or Gentoo with libav, or Gentoo with emacs.
>>> Again, I repeat my-self.
>>>
>>> Please stop writing these statements!
>>>
>>> There was no decision to support Gentoo using any other layout than
>>> openrc (baselayout).
>>
>> I think there may be a misunderstanding here. He only said that if you
>> want to run Gnome 3.8, then switch to systemd. Because the Gnome team
>> will not support any other configuration.
>>
>> He did not say that everyone should install systemd, nor that you need
>> to support such a configuration.
>
> So users will have gnome working but not any other component? How can
> this a good service for  users?

What do you mean by "any other component" here?

-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Chí-Thanh Christopher Nguyễn]

Alon Bar-Lev schrieb:
>> I think there may be a misunderstanding here. He only said that if you
>> want to run Gnome 3.8, then switch to systemd. Because the Gnome team
>> will not support any other configuration.
>>
>> He did not say that everyone should install systemd, nor that you need
>> to support such a configuration.
> So users will have gnome working but not any other component? How can
> this a good service for  users?

I am not sure what you mean by that. But every developer is free to
commit and support in Gentoo whatever package he wishes to, within
limitations set by policy.
And when a package is 30 days in tree and there is no objection from QA
or security teams then it can go stable.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Walter Dnes]

On Fri, Aug 09, 2013 at 11:16:37AM +0200, Tom Wijsman wrote


> Though, an init system standard might be the most promising approach.

  Ahemmm http://xkcd.com/927/

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 9 Aug 2013 17:22:38 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> There was no decision to support Gentoo using any other layout than
> openrc (baselayout).

Was there the decision to only support a single layout on Gentoo? Where?

> There is *HUGE* difference between optional components and core
> components.

Neither OpenRC or systemd is selected in @system; both are optional,
which one comes as default depends on how you obtain Gentoo. While
there's only a stage3 for OpenRC that does not exclude the possibility
that a stage3 for systemd may be made in the near future.

Since one is replaceable by the other, it's an optional component where
you can pick one or the other; neither of both is therefore a core
component. You're however required to pick one of both as a core
component; so, interpreted otherwise both are core components.

Of course there is a huge difference, but it does not apply here.

> Claiming that Gentoo can use alternate layout is same as alternate
> that freebsd port is stable or that intel icc can be used as compiler.

Claiming that Gentoo can only support one layout is the same as FreeBSD
is unstable or that the Intel ICC can't be used as a compiler at all.

> It has broad implications, which is far from the actual component
> usage or its own dependencies.

Implications that do not broadly affect you, as far as I am aware; if
they do, please state the problems and concerns that you foresee.

> If you have the agenda to switch to systemd, and you hide your
> intention in the argument of supporting multiple layouts, please do
> not hide and state so clearly.

Same for you, is your agenda to keep OpenRC and block any alternatives?

Our agenda is to keep Gentoo what Gentoo is defined as, follow its
philosophy and therefore do whatever is needed to provide our users a
choice to use Gnome 3.8 in a stable manner.

I don't see what all this has to do with an agenda of switching to
systemd, nobody is keeping you or anybody else from implementing or
porting support for OpenRC into GNOME 3.8; even if this were an agenda,
it would have been a very inefficient way to switch people to systemd.

> But do not claim that Gentoo with different layout than baselayout is
> still formal Gentoo, and is supported by the Gentoo developers.

Are you sure your claim about formal Gentoo is what formal Gentoo is?

http://www.gentoo.org/main/en/about.xml
http://www.gentoo.org/main/en/philosophy.xml
http://www.gentoo.org/doc/en/faq.xml#differences

A different layout is acceptable for a meta-distribution.

There are a lot of Gentoo developers supporting it.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 5:57 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Alon Bar-Lev schrieb:
>>> I think there may be a misunderstanding here. He only said that if you
>>> want to run Gnome 3.8, then switch to systemd. Because the Gnome team
>>> will not support any other configuration.
>>>
>>> He did not say that everyone should install systemd, nor that you need
>>> to support such a configuration.
>> So users will have gnome working but not any other component? How can
>> this a good service for  users?
>
> I am not sure what you mean by that. But every developer is free to
> commit and support in Gentoo whatever package he wishes to, within
> limitations set by policy.
> And when a package is 30 days in tree and there is no objection from QA
> or security teams then it can go stable.

This is so narrow interpretation of the policy.
You talk about a process, and user do not care about the process.
30 days? and what if a user has an issue 31 days after?
And what if QA decides that now systemd must be supported? so we delay
stabilization?

People here tend to forget that Gentoo is not just ebuilds, but also
an organization which requires a policy for the sake of its *USERS*.

Regards,
Alon

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 9 Aug 2013 17:50:24 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> So users will have gnome working but not any other component? How can
> this a good service for  users?

Just like we can't ensure that everything builds with LLVM doesn't mean
we shouldn't support packages that only build with GCC, neither does it
mean we can't support packages that only build with LLVM; we do our
best to aim them to build with both as a means of good service to our
users, but if it doesn't build for one of the other there's not much we
can do about that other than trying to fix. The same applies to build
systems, documentation generation, the compression used and so on....

If we didn't support alternatives, we would only have stuff in the tree
that solely supports GCC, plain Makefiles and so on; and anything that
only works with LLVM, CMake and so on would never be a part. This isn't
the Gentoo that I want to pursue; I agree that an alternative not being
supported isn't a good service for "all" users, but for "some" users it
is a good alternative. Let's not put those users in the dark.

The support for systemd is increasing; the support for other components
looks good to most of us, and those that don't work will likely work in
the near future except for those that have a hard dependency on OpenRC.

I'm willing to belief that the small set of software that has that kind
of hard dependency can also be made supported or simply replaced.

Good service in a meta distro is making alternative choices available.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[hasufell]

On 08/09/2013 04:57 PM, Chí-Thanh Christopher Nguyễn wrote:
> Alon Bar-Lev schrieb:
>>> I think there may be a misunderstanding here. He only said that if you
>>> want to run Gnome 3.8, then switch to systemd. Because the Gnome team
>>> will not support any other configuration.
>>>
>>> He did not say that everyone should install systemd, nor that you need
>>> to support such a configuration.
>> So users will have gnome working but not any other component? How can
>> this a good service for  users?
> 
> I am not sure what you mean by that. But every developer is free to
> commit and support in Gentoo whatever package he wishes to, within
> limitations set by policy.
> And when a package is 30 days in tree and there is no objection from QA
> or security teams then it can go stable.
> 
> 

No, that is definitely not how stabilization works and I was told
something different during my recruitment process.

* the package must be _stable_ (as in... it works on different setups...
this is already not true for gnome), no severe outstanding bugs either
upstream or in gentoo (broken openrc compatibility is a severe bug)
* 30 days is just a guideline, nothing more. Just following that without
caring about anything else will not improve our stable branch
* QA and security do not monitor every stabilization bug. the maintainer
has to track those issues in the first place
* reverse deps have to work

I don't care what people think about OpenRC or systemd. I support BOTH.
If a package only supports one, that is a BUG (and in this case... a
regression even).

This is similar to gcc vs clang. Clang is not ready yet to be used
system-wide, so gcc is still our main implementation and the default (as
in: shipped in stage3). Even if clang was stable... a package that does
not compile with gcc would never be allowed to go stable. We want it to
work on BOTH compilers.

If you can't make that happen, then that's okay. But don't attempt to
call that package stable then. It's not.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 9 Aug 2013 17:40:28 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> At least we know what ssuominen thinks... some prople are trying to
> hijack the Gentoo project at the excuse of Gnome to switch into
> specific vendor solution, and be on its mercies from now on. This was
> the exact plan of whoever put all these $$ in
> udev/systemd/gnome/fedora and effect the entire ecosystem, and slowly
> own the entire solutions. As Linux userland become more and more
> monolithic per the plan of that vendor, and if we yield, there will be
> no real difference between Fedora and Gentoo, so what have we
> accomplished? There come the new Microsoft and conquered the free open
> source world using $$ and ambassadors.

As far as I am aware this discussion is not about yielding; so, there
is nothing to be concerned about with the outcome of this discussion.

> What we basically say is that Gentoo cannot have their own agenda and
> now submit to dictation of a single vendor of how Linux should be
> managed and run.

Gentoo has its own agenda; but, I'm under the impression that you aren't
following that agenda, instead opposing to some non-existing dictation.

> To provide good service to our users we need a clear stand, what will
> developers (throughout the tree) will be maintaining.

Developers are free in that as long as policy, QA and security permit.

> If a user installs a component he does expect it to work and
> maintained. And we cannot force all developers to support two
> different layouts, and we cannot allow developers to support layout
> of their choice, as users will get a totally broken solution, because
> of the aspirations of developer/herd they get different level of
> support.

We don't need to force all developers to support multiple layouts.

If someone cannot support it, another developer can jump in and support
it; as an end result, you don't get a totally broken solution.

> I don't care if systemd is worked on by people, however it must be
> clearly mark as unstable as long as there is no decision to switch.

It is marked as stable; if you wish to see it unstable, you will
probably want to file another thread stating the reasons why you
believe it must be marked as such. The Gnome 3.8 stabilization thread
we are in now is not the place to request to mark systemd unstable.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 9 Aug 2013 10:57:49 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Fri, Aug 09, 2013 at 11:16:37AM +0200, Tom Wijsman wrote
> 
> 
> > Though, an init system standard might be the most promising
> > approach.
> 
>   Ahemmm http://xkcd.com/927/

Are there existing init system standards then? Isn't this the first one?

Either way, it will require a lot of effort to convince people or a lot
of work to get things done; whether that is by a new standard making
it more easy or by writing a big set of commits for upstream to apply.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 09 Aug 2013 17:25:10 +0200
hasufell <hasufell@gentoo.org> wrote:

> No, that is definitely not how stabilization works and I was told
> something different during my recruitment process.
> 
> * _stable_ (as in... it works on different setups... this is already
> not true for gnome)

Current documentation and ebuild policy does not reflect the different
setups bit; that is, it merely mentions that it must be widely tested
but it is not clear whether that includes different setups or not.

http://devmanual.gentoo.org/keywording/#moving-from-~arch-to-arch
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap4_sect4

Even stronger, the ebuild policy mentions in the same section that "It
is up to the maintainer of the package to deem which versions are
stable or if development versions should be in package.mask or left in
~arch."; and in this sense, I think only instances like QA, security,
*Rel and the Council stand above that.

So, under strict ebuild policy, we can not block stabilization without
calling one of those instances with an objection to the change; we
both know that a lot of people don't really follow this anymore, but
it is still written down and should be corrected if we want this to be
different. I'm really surprised to find the policy to state this rule.

> I don't care what people think about OpenRC or systemd. I support
> BOTH. If a package only supports one, that is a BUG (and in this
> case... a regression even).

You keep repeating this, I'm yet to see agreement on this; so "maybe".

> This is similar to gcc vs clang. Clang is not ready yet to be used
> system-wide, so gcc is still our main implementation and the default
> (as in: shipped in stage3). Even if clang was stable... a package
> that does not compile with gcc would never be allowed to go stable.
> We want it to work on BOTH compilers.

The difference between systemd and Clang is that systemd is marked
stable whereas Clang is not; so, you can in fact not stabilize a
package because Clang as a dependency is not yet stable.

The difference between OpenRC and GCC is that OpenRC is not selected in
@system whereas GCC is selected in @system; so, you can replace OpenRC
whereas you can't replace GCC until @system adjusts.

You are comparing apples and eggs here.

GCC is currently a core requirement, OpenRC is not and thus replaceable.

> If you can't make that happen, then that's okay. But don't attempt to
> call that package stable then. It's not.

What does incompatibility have to do with stability?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Fri, Aug 9, 2013 at 7:14 AM, vivo75@gmail.com <vivo75@gmail.com> wrote:
> On 08/09/13 13:38, Pacho Ramos wrote:
>> El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
>>> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>>>> On Fri, 09 Aug 2013 19:31:22 +0800
>>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>>
>>>>> You just removed the upgrade path for users.
>>>> The upgrade path is to install systemd or to implement openrc support.
>>>>
>>> Invalid upgrade path.
>>>
>>> "The upgrade path is to install Fedora" is about as reasonable, and also
>>> not acceptable.
>>>
>>>
>> The upgrade path is to run systemd, not migrate to fedora. As simply as
>> such
>>
>>
> is systemd useful if not run with PID=1 ? Honest question

(Answering as a GNOME+systemd user since 2011).

AFAIU, systemd is completely useless if it isn't running as PID 1. In
particular (and the reason systemd is now a hard requirement for
GNOME), logind will not work correctly (if at all) if systemd isn't
PID 1. All the cgroups handling (for one) is non existent (or
completely different) in OpenRC.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 09/08/13 17:40, Alon Bar-Lev wrote:
> On Fri, Aug 9, 2013 at 4:49 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> On 09/08/13 15:36, hasufell wrote:
>>>
>>> On 08/09/2013 12:27 PM, Rich Freeman wrote:
>>>>
>>>> On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
>>>>>
>>>>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>>>>>>
>>>>>> It is not a regression if a new version of gnome mrequires systemd
>>>>>> and does not work with OpenRc; it is a design choice.
>>>>>
>>>>>
>>>>> We are not just talking about random ebuild features here that have been
>>>>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
>>>>> _regression_.
>>>>
>>>>
>>>> How does not supporting OpenRC matter for Gentoo?
>>>
>>>
>>> The question puzzles me. For one it is
>>> * an implementation of virtual/service-manager which is in @system
>>> * it is the default init system in stage3
>>> * OpenRC is developed by gentoo devs, which means we especially want to
>>> make/keep it a usable tool. If we can't, then there is a regression. It
>>> doesn't matter whose fault it is. This is not about blame.
>>
>>
>> baselayout-1, then later baselayout-2 and OpenRC were all created because
>> there was an need and no suitable ready solutions
>> systemd however is starting to look like a viable ready solution to switch
>> to
>> it's definately not an regression to switch to actively maintained software,
>> it's more of an improvement because OpenRC has been stalled ever since Roy
>> stopped hacking on it (all work put in by vapier, WilliamH, and others is of
>> course appericiated)
>> you know it's true if you have been with gentoo enough long
>>
>
> At least we know what ssuominen thinks... some prople are trying to
> hijack the Gentoo project at the excuse of Gnome to switch into
> specific vendor solution, and be on its mercies from now on. This was
> the exact plan of whoever put all these $$ in
> udev/systemd/gnome/fedora and effect the entire ecosystem, and slowly
> own the entire solutions. As Linux userland become more and more
> monolithic per the plan of that vendor, and if we yield, there will be
> no real difference between Fedora and Gentoo, so what have we
> accomplished? There come the new Microsoft and conquered the free open
> source world using $$ and ambassadors.

bleh

I don't see systemd in Gentoo threatening OpenRC any more than emacs 
threatens vim in-tree. You can improve OpenRC so it can compete better 
with systemd. You can improve GNOME to work without systemd. It's really 
that simple and there is no agenda.
And I use OpenRC mainly, and we speak and maintain software like 
ConsoleKit, XFCE to keep systemd away because I know people still use
them.
Really, why so aggressive about what the system should be? You don't 
have to use GNOME and systemd if you don't want -- or you can help them 
if you don't like the direction they are going.

>
> What we basically say is that Gentoo cannot have their own agenda and
> now submit to dictation of a single vendor of how Linux should be
> managed and run.
>
> To provide good service to our users we need a clear stand, what will
> developers (throughout the tree) will be maintaining. If a user
> installs a component he does expect it to work and maintained. And we
> cannot force all developers to support two different layouts, and we
> cannot allow developers to support layout of their choice, as users
> will get a totally broken solution, because of the aspirations of
> developer/herd they get different level of support.
>
> I don't care if systemd is worked on by people, however it must be
> clearly mark as unstable as long as there is no decision to switch.
>
> Regards,
> Alon Bar-Lev
>

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Fri, Aug 9, 2013 at 8:54 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-08-09, o godz. 14:14:12
> "vivo75@gmail.com" <vivo75@gmail.com> napisał(a):
>
>> On 08/09/13 13:38, Pacho Ramos wrote:
>> > El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
>> >> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>> >>> On Fri, 09 Aug 2013 19:31:22 +0800
>> >>> Patrick Lauer <patrick@gentoo.org> wrote:
>> >>>
>> >>>> You just removed the upgrade path for users.
>> >>> The upgrade path is to install systemd or to implement openrc support.
>> >>>
>> >> Invalid upgrade path.
>> >>
>> >> "The upgrade path is to install Fedora" is about as reasonable, and also
>> >> not acceptable.
>> >>
>> >>
>> > The upgrade path is to run systemd, not migrate to fedora. As simply as
>> > such
>> >
>> >
>> is systemd useful if not run with PID=1 ? Honest question
>
> Not a honest question but either honest troll, or you're awfully lazy
> and just making noise here.
>
> So the answer is: yes, it's quite useful when run with PID!=1. It's
> called systemd user instance (something OpenRC totally can't handle)
> and it can be used to manage user services.

I forgot thtat when I answered, but that requires that systemd is also
running as PID 1. If I understand the question correctly (and I didn't
perceived any "trollism"), it was about if you can install systemd,
but run OpenRC as PID 1, and have everything working.

In that case, the answer is no.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Fri, Aug 9, 2013 at 9:50 AM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>> Alon Bar-Lev schrieb:
>>> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>>>> You just removed the upgrade path for users.
>>>>>
>>>> Just install systemd.  There really isn't any practical alternative.
>>>> Gentoo with systemd is as Gentooish a configuration as Gentoo with
>>>> OpenRC, or Gentoo with libav, or Gentoo with emacs.
>>> Again, I repeat my-self.
>>>
>>> Please stop writing these statements!
>>>
>>> There was no decision to support Gentoo using any other layout than
>>> openrc (baselayout).
>>
>> I think there may be a misunderstanding here. He only said that if you
>> want to run Gnome 3.8, then switch to systemd. Because the Gnome team
>> will not support any other configuration.
>>
>> He did not say that everyone should install systemd, nor that you need
>> to support such a configuration.
>
> So users will have gnome working but not any other component? How can
> this a good service for  users?

For the record, everything I use (desktop, laptop, media center,
servers, etc.) uses Gentoo with systemd. Several of them doesn't have
GNOME (the servers obviously don't even have X). All the "components"
in my use cases (which I confess are really standard) work.

In my experience, if it works in Gentoo with OpenRC, it will work with
systemd (and, IMHO, sometimes better).

The other way around is, obviously as per this whole thread, not true.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 09/08/13 16:49, Samuli Suominen wrote:
> On 09/08/13 15:36, hasufell wrote:
>> On 08/09/2013 12:27 PM, Rich Freeman wrote:
>>> On Fri, Aug 9, 2013 at 5:30 AM, hasufell <hasufell@gentoo.org> wrote:
>>>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:
>>>>> It is not a regression if a new version of gnome mrequires systemd
>>>>> and does not work with OpenRc; it is a design choice.
>>>>
>>>> We are not just talking about random ebuild features here that have
>>>> been
>>>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
>>>> _regression_.
>>>
>>> How does not supporting OpenRC matter for Gentoo?
>>
>> The question puzzles me. For one it is
>> * an implementation of virtual/service-manager which is in @system
>> * it is the default init system in stage3
>> * OpenRC is developed by gentoo devs, which means we especially want to
>> make/keep it a usable tool. If we can't, then there is a regression. It
>> doesn't matter whose fault it is. This is not about blame.
>
> baselayout-1, then later baselayout-2 and OpenRC were all created
> because there was an need and no suitable ready solutions
> systemd however is starting to look like a viable ready solution to
> switch to
> it's definately not an regression to switch to actively maintained
> software, it's more of an improvement because OpenRC has been stalled
> ever since Roy stopped hacking on it (all work put in by vapier,
> WilliamH, and others is of course appericiated)
> you know it's true if you have been with gentoo enough long
>

wrong choice of words as someone pointed out,
s/stalled/slowed down/
or even
s/stalled/slowed down a bit/
it came out too harsh. sorry for the noise.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[William Hubbs]

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

On Fri, Aug 09, 2013 at 05:22:38PM +0300, Alon Bar-Lev wrote:
> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman <rich0@gentoo.org> wrote:
> > On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> >> You just removed the upgrade path for users.
> >>
> >
> > Just install systemd.  There really isn't any practical alternative.
> > Gentoo with systemd is as Gentooish a configuration as Gentoo with
> > OpenRC, or Gentoo with libav, or Gentoo with emacs.
> 
> Again, I repeat my-self.
> 
> Please stop writing these statements!
> 
> There was no decision to support Gentoo using any other layout than
> openrc (baselayout).

 Baselayout and OpenRc are two separate things. In baselayout-1 it was
 true that the init scripts were part of Baselayout. However, this is
 not the case now, since OpenRc is separated from Baselayout.

> There is *HUGE* difference between optional components and core components.
 
 The "core" component, that all gentoo systems are required to have, is
 baselayout, not OpenRc.

I've been a dev since 2004, and I have never heard of a
policy that mandates that everything must work with OpenRc in order to
be stable. Yes, OpenRc is the default init scripts in stage 3, but that
in no way implies that everything is mandated to work with it. It just
means we chose that as the default.

> Claiming that Gentoo can use alternate layout is same as alternate
> that freebsd port is stable or that intel icc can be used as compiler.
> It has broad implications, which is far from the actual component
> usage or its own dependencies.
 
What implications are those other than, in this case, providing systemd
units for packages that need them? Since there is an active team of
Gentoo developers that work on systemd, shouldn't they be the ones to
handle those implications?

> If you have the agenda to switch to systemd, and you hide your
> intention in the argument of supporting multiple layouts, please do
> not hide and state so clearly.

As has been stated a thousand times, we are not changing the default
init system to systemd. Gnome (upstream) has decided to require it, so
if you use Gnome you will need to switch over, but that's it. This does
not mean that the default is changing. This also does not fit the
definition of a regression, since 1) we do not mandate that everything
must work with OpenRc and 2) they make it clear upstream that they
require systemd.

> But do not claim that Gentoo with different layout than baselayout is
> still formal Gentoo, and is supported by the Gentoo developers.

baselayout is used on systemd systems, so nothing has changed here, and,
systemd is supported by gentoo developers. It is not the default init
setup, but it is fully supported. Systemd is a full citizen of gentoo.

Regards,

William

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ben de Groot]

On 9 August 2013 21:57, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-08-09, o godz. 13:45:25
> Tom Wijsman <TomWij@gentoo.org> napisał(a):
>
>> On Fri, 09 Aug 2013 19:39:08 +0800
>> Patrick Lauer <patrick@gentoo.org> wrote:
>>
>> > On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>> > > On Fri, 09 Aug 2013 19:31:22 +0800
>> > > Patrick Lauer <patrick@gentoo.org> wrote:
>> > >
>> > >> You just removed the upgrade path for users.
>> > >
>> > > The upgrade path is to install systemd or to implement openrc
>> > > support.
>> > >
>> > Invalid upgrade path.
>> >
>> > "The upgrade path is to install Fedora" is about as reasonable, and
>> > also not acceptable.
>>
>> Your upgrade path is no longer an upgrade; the other ones are, and as
>> said before, running Gentoo has no implication that OpenRC must be ran.
>
> I can think of at least a few examples where 'upgrade path' actually
> involved replacing one package with another and yet nobody complains
> about that.
>
> This one is *so special* just because we have a few folks which really
> have nothing useful to do and instead spit their systemd hatred on
> gentoo-dev@ and expect others to join their stupid vendetta.

Please keep your insults off this list. You may want to deny them, but
there are valid reasons why people oppose systemd. It doesn't help to
keep so aggressively pushing it.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Matt Turner]

On Fri, Aug 9, 2013 at 12:11 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> It doesn't help to keep so aggressively pushing it.

Neither does so aggressively pushing against it.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michał Górny]

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

Dnia 2013-08-10, o godz. 03:11:55
Ben de Groot <yngwin@gentoo.org> napisał(a):

> On 9 August 2013 21:57, Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2013-08-09, o godz. 13:45:25
> > Tom Wijsman <TomWij@gentoo.org> napisał(a):
> >
> >> On Fri, 09 Aug 2013 19:39:08 +0800
> >> Patrick Lauer <patrick@gentoo.org> wrote:
> >>
> >> > On 08/09/2013 07:26 PM, Tom Wijsman wrote:
> >> > > On Fri, 09 Aug 2013 19:31:22 +0800
> >> > > Patrick Lauer <patrick@gentoo.org> wrote:
> >> > >
> >> > >> You just removed the upgrade path for users.
> >> > >
> >> > > The upgrade path is to install systemd or to implement openrc
> >> > > support.
> >> > >
> >> > Invalid upgrade path.
> >> >
> >> > "The upgrade path is to install Fedora" is about as reasonable, and
> >> > also not acceptable.
> >>
> >> Your upgrade path is no longer an upgrade; the other ones are, and as
> >> said before, running Gentoo has no implication that OpenRC must be ran.
> >
> > I can think of at least a few examples where 'upgrade path' actually
> > involved replacing one package with another and yet nobody complains
> > about that.
> >
> > This one is *so special* just because we have a few folks which really
> > have nothing useful to do and instead spit their systemd hatred on
> > gentoo-dev@ and expect others to join their stupid vendetta.
> 
> Please keep your insults off this list. You may want to deny them, but
> there are valid reasons why people oppose systemd. It doesn't help to
> keep so aggressively pushing it.

And what does help? 143-mail thread with people crying out how bad
the world goes for them? There are people actually reading this list,
and if I'm insulting anyone, those people are insulting the whole
Gentoo community by wasting their time and making this list less
and less useful.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sat, 10 Aug 2013 03:11:55 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 9 August 2013 21:57, Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2013-08-09, o godz. 13:45:25
> > Tom Wijsman <TomWij@gentoo.org> napisał(a):
> >
> >> Your upgrade path is no longer an upgrade; the other ones are, and
> >> as said before, running Gentoo has no implication that OpenRC must
> >> be ran.
> >
> > I can think of at least a few examples where 'upgrade path' actually
> > involved replacing one package with another and yet nobody complains
> > about that.
> >
> > This one is *so special* just because we have a few folks which
> > really have nothing useful to do and instead spit their systemd
> > hatred on gentoo-dev@ and expect others to join their stupid
> > vendetta.
> 
> Please keep your insults off this list. You may want to deny them, but
> there are valid reasons why people oppose systemd. It doesn't help to
> keep so aggressively pushing it.

Neither does it help to make statements like "People are free to use a
saner desktop environment..." which add nothing to the discussion,
which in fact can be seen as an insult as well; because "sane"
basically stands for "free from mental derangement" or "free from
being unreasonably, unsound judgment or bad sense" where both come
close to what people will perceive as the negative form of "stupid".

(Of course, his message can be perceived to insult in other ways; I
won't comment on those, they seem to be based on a bit of annoyance)

I don't see why this needs to be done almost every time a discussion
that mentions the word systemd comes up; okay, there are people that
oppose to it but can't they just ignore the discussion instead of making
statements that really add nothing to the actual discussion?

You may perceive things are being denied and think things are
aggressively being pushed; but please note the "action, reaction"
concept applies here and you are perceiving the reaction to what people
that oppose to systemd are irrelevantly inserting into the discussion.

"A saner DE" or "unmerge GNOME" doesn't answer "stabilize 3.6 or 3.8?";
I'm not going to summarize on the rest, but a fair bit doesn't answer.

As for whether to stabilize GNOME, that's the maintainer's decision;
unless the maintainer is forced to do otherwise by a higher instance,
see the paragraphs of "Moving package versions from ~ARCH to ARCH" in
the ebuild policy [1] which mentions that it is up to the maintainer.

I think that the reasoning whether to stabilize 3.6 or 3.8 has long
been given; so, unless someone wants to make a remark on that alone,
there's probably no need to bump this out of bounds discussion anymore.

There are different approaches to request that higher instances oppose;
I'm pretty sure that they are willing to deal with systemd pushers, as
in those that trying to go besides community and / or council consensus.

Please, give it a rest; there is too much unnecessary talk for nothing.

 [1]: Ebuild policy - "Moving package versions from ~ARCH to ARCH"
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap4_sect4

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 09/08/13 19:17, Canek Peláez Valdés wrote:
> On Fri, Aug 9, 2013 at 7:14 AM, vivo75@gmail.com <vivo75@gmail.com> wrote:
>> On 08/09/13 13:38, Pacho Ramos wrote:
>>> El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
>>>> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>>>>> On Fri, 09 Aug 2013 19:31:22 +0800
>>>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>>>
>>>>>> You just removed the upgrade path for users.
>>>>> The upgrade path is to install systemd or to implement openrc support.
>>>>>
>>>> Invalid upgrade path.
>>>>
>>>> "The upgrade path is to install Fedora" is about as reasonable, and also
>>>> not acceptable.
>>>>
>>>>
>>> The upgrade path is to run systemd, not migrate to fedora. As simply as
>>> such
>>>
>>>
>> is systemd useful if not run with PID=1 ? Honest question
>
> (Answering as a GNOME+systemd user since 2011).
>
> AFAIU, systemd is completely useless if it isn't running as PID 1. In
> particular (and the reason systemd is now a hard requirement for
> GNOME), logind will not work correctly (if at all) if systemd isn't
> PID 1. All the cgroups handling (for one) is non existent (or
> completely different) in OpenRC.
>
> Regards.
>

Correct.   Ubuntu has logind working without systemd but they are stuck 
at version 204.  At systemd version 205 it became impossible to run 
logind without systemd.
The only reason why sys-apps/systemd being installed would be useful if 
it isn't PID=1 (all the time) user wants to support dualboot between 
OpenRC and systemd, with different init='s, since the systemd-udevd can 
be used with OpenRC.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

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



On 09/08/13 10:35, Tom Wijsman wrote:
> Listening comes at a price; you can't listen to everyone at the
> same time, all you will hear is noise because all the voices clash.
> So, you've got to listen to a selective bit of users and satisfy
> them; after all you can't satisfy everyone. Resources are
> finite...

That's exactly why I'm trying to get all the frustrated voices on the
Gentoo-dev mailing list making one single concerted comment to the
developers, so that they only need to listen once, and can see from
the number how many people feel the same way...

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIFcToACgkQu7rWomwgFXo0UgCfXYsL4VtS2HjWDxop5+E6mFJQ
6mQAnjM6fQqDSL6xGigE0AncqyqQjIhJ
=Enah
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

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

On 09/08/13 21:32, Tom Wijsman wrote:
> On Sat, 10 Aug 2013 03:11:55 +0800 Ben de Groot <yngwin@gentoo.org>
> wrote:
> 
>> On 9 August 2013 21:57, Michał Górny <mgorny@gentoo.org> wrote:
>>> This one is *so special* just because we have a few folks
>>> which really have nothing useful to do and instead spit their
>>> systemd hatred on gentoo-dev@ and expect others to join their
>>> stupid vendetta.
>> 
>> Please keep your insults off this list. You may want to deny
>> them, but there are valid reasons why people oppose systemd. It
>> doesn't help to keep so aggressively pushing it.
> 
> Neither does it help to make statements like "People are free to
> use a saner desktop environment..." which add nothing to the
> discussion, which in fact can be seen as an insult as well; because
> "sane" basically stands for "free from mental derangement" or "free
> from being unreasonably, unsound judgment or bad sense" where both
> come close to what people will perceive as the negative form of
> "stupid".

I'm not sure where you're quoting from, it doesn't appear to have been
the thread Ben was commenting on.

I'm glad someone stepped in and said something, Michael's comments
appeared overly aggressive, as they would have even if the word hatred
had read agenda.  I'm not sure why there were so many rebuttals of his
request to keep things civil.  It wasn't a statement for or against
systemd, it was a request to maintain a hospitable environment...

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

iEYEARECAAYFAlIFe/gACgkQu7rWomwgFXr5sACeJkIl6rDKmyVdNmaQW9HupK35
s4MAn3EvU9agxaAOJI5Gf7uHUqcEJ7Mv
=x6Dm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sat, 10 Aug 2013 00:32:08 +0100
Mike Auty <ikelos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/08/13 21:32, Tom Wijsman wrote:
> > On Sat, 10 Aug 2013 03:11:55 +0800 Ben de Groot <yngwin@gentoo.org>
> > wrote:
> > 
> >> On 9 August 2013 21:57, Michał Górny <mgorny@gentoo.org> wrote:
> >>> This one is *so special* just because we have a few folks
> >>> which really have nothing useful to do and instead spit their
> >>> systemd hatred on gentoo-dev@ and expect others to join their
> >>> stupid vendetta.
> >> 
> >> Please keep your insults off this list. You may want to deny
> >> them, but there are valid reasons why people oppose systemd. It
> >> doesn't help to keep so aggressively pushing it.
> > 
> > Neither does it help to make statements like "People are free to
> > use a saner desktop environment..." which add nothing to the
> > discussion, which in fact can be seen as an insult as well; because
> > "sane" basically stands for "free from mental derangement" or "free
> > from being unreasonably, unsound judgment or bad sense" where both
> > come close to what people will perceive as the negative form of
> > "stupid".
> 
> I'm not sure where you're quoting from, it doesn't appear to have been
> the thread Ben was commenting on.

http://article.gmane.org/gmane.linux.gentoo.devel/87206

> I'm glad someone stepped in and said something, Michael's comments
> appeared overly aggressive, as they would have even if the word hatred
> had read agenda.  I'm not sure why there were so many rebuttals of his
> request to keep things civil. It wasn't a statement for or against
> systemd, it was a request to maintain a hospitable environment...

We're on the same line for that part.

Note that I do not disagree with Ben's request, thus did not re[bf]ute;
I wanted to point out why people that try to construct were annoyed. If
he then makes such request it doesn't help that he did a similar thing
earlier himself, therefore I am making the same request back to him.

In a conflict, there are always two sides; in order to maintain a
hospitable environment, both sides have to make an effort to reach that.

So, both sides calling things more sane or more hateful is not civil...

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

iQEcBAEBAgAGBQJSBYNvAAoJEJWyH81tNOV9ltgH/0wO7hjA3+cnkuZGyaqEBHN4
iQL9ZDuASegxIMkg1D4k9AZ+kZDqYPwRNL07nsvQRZNceXEtc3sOx0AeLb/pcDe7
GZHR7S30ACvo9U/Fj6Bgd/FeQulyQ4ztfUJRKBTa9JRp+iBn8Y8HuxC88MARXtTN
Qaptxq1JpaOa69AvotuybH35DgW9SsiHcpQgP1j8JnU0ykev4uCk4KFpy6SwB9Sa
oAFF3VLsXivZdZeh1EomtaoDngQkCCU2eAftDEwUEfDL4RQ3U1LvcztT5mn5UB6p
ntgD/mHWeLPWVuLMInanet6O/8bIeaLyed6yW3OsFFkslIfzYik9vX6aGq4oKTw=
=yAvQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Walter Dnes]

On Fri, Aug 09, 2013 at 08:27:23AM +0800, Patrick Lauer wrote

> What makes this situation so difficult is that it's not a single
> random package, but one of the bigger desktop environments that
> has painted itself into a corner. (Plus an uncooperative upstream,
> so all the "blame" gets thrown at the gentoo maintainers from both
> sides. Awesome way to destroy crew morale :) )

  I don't think you realize what you're asking for.  This is a lot more
than just a few patches.  You're effectively asking for fork of GNOME,
just like eudev has forked from udev.  GNOME forks already exist.  Just
off the top of my head... XFCE, Cinnamon, Consort, Mint, Mate, Kate,
Unity, etc, etc.  If you don't like GNOME, try one of them.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 10/08/13 07:03, Walter Dnes wrote:
> On Fri, Aug 09, 2013 at 08:27:23AM +0800, Patrick Lauer wrote
>
>> What makes this situation so difficult is that it's not a single
>> random package, but one of the bigger desktop environments that
>> has painted itself into a corner. (Plus an uncooperative upstream,
>> so all the "blame" gets thrown at the gentoo maintainers from both
>> sides. Awesome way to destroy crew morale :) )
>
>    I don't think you realize what you're asking for.  This is a lot more
> than just a few patches.  You're effectively asking for fork of GNOME,
> just like eudev has forked from udev.  GNOME forks already exist.  Just
> off the top of my head... XFCE, Cinnamon, Consort, Mint, Mate, Kate,
> Unity, etc, etc.  If you don't like GNOME, try one of them.
>

XFCE is far from being a fork of GNOME, you must have confused something

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/09/2013 07:37 PM, Ciaran McCreesh wrote:
> On Fri, 09 Aug 2013 19:31:22 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
>> Somehow I get really confused by this selective perception (anyone
>> remembering the KDE overlay getting paludised and the fallout from
>> that?)
> 
> That's a very selective perception there. If you mean the fully
> documented kdebuild-1 EAPI,
... which was disallowed from being used in-tree, which most users could
not use without breaking their current setup ...

It lead to a fork of the overlay which in a short time absorbed almost
all users, which should tell you how popular the decision of "lol don't
portage" was.

The difference now is that forking Gnome is not a viable option


> whose features are mostly in EAPI 5 now,
> then I remember Gentoo getting a lot of valuable experience that was
> used to decide how to improve the package format.
> 
And lots of good policies like "all ebuilds in-tree must work with
portage", or "all ebuilds in tree must use approved EAPIs" (hello
pro-gress overlay ;) )

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/09/2013 07:45 PM, Tom Wijsman wrote:
> On Fri, 09 Aug 2013 19:39:08 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
>> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>>> On Fri, 09 Aug 2013 19:31:22 +0800
>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>
>>>> You just removed the upgrade path for users.
>>>
>>> The upgrade path is to install systemd or to implement openrc
>>> support.
>>>
>> Invalid upgrade path.
>>
>> "The upgrade path is to install Fedora" is about as reasonable, and
>> also not acceptable.
> 
> Your upgrade path is no longer an upgrade;

I like it when you violently agree with me

> the other ones are, and as
> said before, running Gentoo has no implication that OpenRC must be ran.
> 
not must, but if I choose to run the official supported configuration,
well, then telling me to go to an unsupported state is quite confusing
and sends the wrong signal.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/09/2013 08:28 PM, Rich Freeman wrote:
> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> You just removed the upgrade path for users.
>>
> 
> Just install systemd.  There really isn't any practical alternative.
> Gentoo with systemd is as Gentooish a configuration as Gentoo with
> OpenRC, or Gentoo with libav, or Gentoo with emacs.
> 
>>
>> Somehow I get really confused by this selective perception (anyone
>> remembering the KDE overlay getting paludised and the fallout from that?)
> 
> I never had a problem with it. 

A rare bug ;)

Lots of users ran into troubles, and like in the current situation they
were unable to get support as they ran an actively unsupported
configuration.

(And I thought you were usually in favour of adhering to policies and
not doing ADHD-fuelled random let's break stuff I'm hungry hahaha)

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Sat, Aug 10, 2013 at 6:51 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> not must, but if I choose to run the official supported configuration,
> well, then telling me to go to an unsupported state is quite confusing
> and sends the wrong signal.
>

There is no one official supported configuration of Gentoo.  Nobody
has to agree to make systemd an official supported configuration,
because OpenRC isn't an official supported configuration either.  At
least, not in the way that the terms seems to be being used.  There is
no policy that requires packages to run when OpenRC is the service
manager, and there is no policy that requires packages to supply an
OpenRC init.d script.

Now, I'm all in favor of a policy that would require maintainers to
accept well-maintained patches to add such support to packages that
lack it, just as I support this for systemd, or really for anything
else.  Well-maintained of course means timely, regression-free, no
burdens beyond fetching and patching, and so on.

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/09/2013 10:59 PM, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 17:22:38 +0300
> Alon Bar-Lev <alonbl@gentoo.org> wrote:
> 
>> There was no decision to support Gentoo using any other layout than
>> openrc (baselayout).
> 
> Was there the decision to only support a single layout on Gentoo? Where?
> 

You kids don't remember the past ;)

We had lots of people experimenting with non-baselayout/OpenRC
solutions, but our support stance was always "You deviate from that,
you're on your own" - einit, monit, s6 etc. have always been options,
but never supported.

>> There is *HUGE* difference between optional components and core
>> components.
> 
> Neither OpenRC or systemd is selected in @system; both are optional,
> which one comes as default depends on how you obtain Gentoo. While
> there's only a stage3 for OpenRC that does not exclude the possibility
> that a stage3 for systemd may be made in the near future.

Let me put it into simple words:

Do not break my boot path. Again.

I'm slowly reaching a zero-tolerance stance on regressions that make
booting unreliable or broken, and just replacing OpenRC is about the
worst way to trigger unexpected behaviour.

> 
[snip]

> Same for you, is your agenda to keep OpenRC and block any alternatives?

I tolerate alternatives, but don't actively support them.

> Our agenda is to keep Gentoo what Gentoo is defined as, follow its
> philosophy and therefore do whatever is needed to provide our users a
> choice to use Gnome 3.8 in a stable manner.

... while still providing reasonable support and stability

> I don't see what all this has to do with an agenda of switching to
> systemd, nobody is keeping you or anybody else from implementing or
> porting support for OpenRC into GNOME 3.8; even if this were an agenda,
> it would have been a very inefficient way to switch people to systemd.

You say that as if we cared for Gnome.

[snip]

> There are a lot of Gentoo developers supporting it.
Flashback to 2006... so it is true, the wheel keeps turning ...

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Patrick Lauer]

On 08/09/2013 11:12 PM, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 17:50:24 +0300
> Alon Bar-Lev <alonbl@gentoo.org> wrote:
> 
>> So users will have gnome working but not any other component? How can
>> this a good service for  users?
> 
> Just like we can't ensure that everything builds with LLVM doesn't mean
> we shouldn't support packages that only build with GCC, neither does it
> mean we can't support packages that only build with LLVM; we do our
> best to aim them to build with both as a means of good service to our
> users, but if it doesn't build for one of the other there's not much we
> can do about that other than trying to fix. The same applies to build
> systems, documentation generation, the compression used and so on....
> 
> If we didn't support alternatives, we would only have stuff in the tree
> that solely supports GCC, plain Makefiles and so on; and anything that
> only works with LLVM, CMake and so on would never be a part. 

Using llvm doesn't imply removing gcc ...

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Sat, Aug 10, 2013 at 6:55 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Lots of users ran into troubles, and like in the current situation they
> were unable to get support as they ran an actively unsupported
> configuration.

Since when was installing half the packages on your system a supported
configuration (whatever exactly that means)?  Also, I suspect the KDE
team would be fairly eager to address issues in their own overlay.

As far as running paludis goes, in my experience anything resembling a
technical flaw tends to be addressed fairly eagerly when posted on
their lists/etc, and anything else tends to be greeted with all the
kinds of behavior that we're trying to get rid of around here but
haven't quite managed (ie, I'm not really ready to go pointing fingers
yet).

>
> (And I thought you were usually in favour of adhering to policies and
> not doing ADHD-fuelled random let's break stuff I'm hungry hahaha)

In an overlay?  The whole point of overlays is allowing more
ADHD-fuelled random breakage, from which we obtain new features that
make the whole world better.

I'm perfectly fine with PMS-compliant-only in the tree.  Frankly many
of the features we rely on in newer APIs derive from the cooperation
of the Portage/Paludis maintainers and I think any of the Portage
maintainers around here would be among the first to agree.

I'm all for adhering to policy, but not to policies that aren't even
written down.  I'm also for getting rid of roadblocks to doing things
that are new and useful.  I'm all for reasonable QA, but that doesn't
mean demoting non-traditional implementations to second-class
citizens.  As I stated in my Council manifesto I will not vote for
policies that require maintainers to author systemd units, but I will
sponsor policies to require maintainers cooperate with those who do.
I think that is the right balance, at least until it causes a real
problem (beyond theological differences like the one that keeps Debian
off the FSF list of Free distros).

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Sat, Aug 10, 2013 at 1:59 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sat, Aug 10, 2013 at 6:51 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> not must, but if I choose to run the official supported configuration,
>> well, then telling me to go to an unsupported state is quite confusing
>> and sends the wrong signal.
>>
>
> There is no one official supported configuration of Gentoo.  Nobody
> has to agree to make systemd an official supported configuration,
> because OpenRC isn't an official supported configuration either.  At
> least, not in the way that the terms seems to be being used.  There is
> no policy that requires packages to run when OpenRC is the service
> manager, and there is no policy that requires packages to supply an
> OpenRC init.d script.

Every long lawyer like response make me re-check my sanity.

The split of openrc was done by Roy in the past to be usable by other
audiences, especially busybox and *bsd configurations.

OpenRC is baselayout-1, just packaged in different way.

Gentoo, well up to now, did have a policy that packages should support
the baselayout which was single one, no alternatives where formally
supported. The fact that OpenRC is now provided as own package
(technical bit) could not have changed the policy of providing stable
coherent solution for users.

The fact that someone decided that init system may be virtual means
nothing if the implications of users and developers were not been
understood.

Of course it matches the gnome and affiliated vendor agenda.... but
for that do we break the entire tree and produce extra load for
developers who maintain unrelated packages?

Alon

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sat, 10 Aug 2013 14:12:42 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> On Sat, Aug 10, 2013 at 1:59 PM, Rich Freeman <rich0@gentoo.org>
> wrote:
> > On Sat, Aug 10, 2013 at 6:51 AM, Patrick Lauer <patrick@gentoo.org>
> > wrote:
> >> not must, but if I choose to run the official supported
> >> configuration, well, then telling me to go to an unsupported state
> >> is quite confusing and sends the wrong signal.
> >>
> >
> > There is no one official supported configuration of Gentoo.  Nobody
> > has to agree to make systemd an official supported configuration,
> > because OpenRC isn't an official supported configuration either.  At
> > least, not in the way that the terms seems to be being used.  There
> > is no policy that requires packages to run when OpenRC is the
> > service manager, and there is no policy that requires packages to
> > supply an OpenRC init.d script.
> 
> Gentoo, well up to now, did have a policy 

This is missing a reference. Where is this policy?

> that packages should support the baselayout

It appears to support, I don't see a problem here; what's not supported?

> which was single one, no alternatives where formally supported.

This is missing a reference. Where is this stated?

> The fact that OpenRC is now provided as own package (technical bit)
> could not have changed the policy of providing stable coherent
> solution for users.

Whether or not the existence of such policy, it makes me wonder:

Why do you think the discussed solution is not stable or not coherent?

> The fact that someone decided that init system may be virtual means
> nothing if the implications of users and developers were not been
> understood.

Is this really the case? Where do you think it is misunderstood?

> Of course it matches the gnome and affiliated vendor agenda....

Or perhaps Gentoo's meta-distribution agenda to provide choice?

> but for that do we break the entire tree and produce extra load for
> developers who maintain unrelated packages?

What entire tree breakage you are talking about? I see no such thing.

As stated multiple times before, there's no extra load involved; but
I'll enumerate it again, it is easy to add and there are enough people
that are willing to help maintain the systemd part of a package.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ciaran McCreesh]

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

On Sat, 10 Aug 2013 18:50:49 +0800
Patrick Lauer <patrick@gentoo.org> wrote:
> On 08/09/2013 07:37 PM, Ciaran McCreesh wrote:
> > On Fri, 09 Aug 2013 19:31:22 +0800
> > Patrick Lauer <patrick@gentoo.org> wrote:
> >> Somehow I get really confused by this selective perception (anyone
> >> remembering the KDE overlay getting paludised and the fallout from
> >> that?)
> > 
> > That's a very selective perception there. If you mean the fully
> > documented kdebuild-1 EAPI,
> ... which was disallowed from being used in-tree, which most users
> could not use without breaking their current setup ...

No-one ever proposed using kdebuild-1 in the main tree.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sat, 10 Aug 2013 19:04:09 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> Using llvm doesn't imply removing gcc ...

Using systemd doesn't imply removing openrc ...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Michael Weber]

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

On 08/10/2013 01:42 PM, Tom Wijsman wrote:
> On Sat, 10 Aug 2013 19:04:09 +0800 Patrick Lauer
> <patrick@gentoo.org> wrote:
> 
>> Using llvm doesn't imply removing gcc ...
> 
> Using systemd doesn't imply removing openrc ...
> 
Running systemd as PID=1 does imply not running openrc as PID=1 *haha*

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlIGKTEACgkQknrdDGLu8JB+dQEAnAxly8GBLd4h2SFj6/3NURwk
AJrKeTi4SQ4GH28QyhQA/jjzc5QQVYr6XH+IKZ+ZPorLQeyfHs4GAO6t1jP6TRRa
=7sZv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sat, 10 Aug 2013 19:03:10 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> On 08/09/2013 10:59 PM, Tom Wijsman wrote:
> > On Fri, 9 Aug 2013 17:22:38 +0300
> > Alon Bar-Lev <alonbl@gentoo.org> wrote:
> > 
> >> There was no decision to support Gentoo using any other layout than
> >> openrc (baselayout).
> > 
> > Was there the decision to only support a single layout on Gentoo?
> > Where?
> > 
> 
> You kids don't remember the past ;)
>
> We had lots of people experimenting with non-baselayout/OpenRC
> solutions, but our support stance was always "You deviate from that,
> you're on your own" - einit, monit, s6 etc. have always been options,
> but never supported.

So, you'll have to refer me to it; otherwise, we won't believe you. ;)

> >> There is *HUGE* difference between optional components and core
> >> components.
> > 
> > Neither OpenRC or systemd is selected in @system; both are optional,
> > which one comes as default depends on how you obtain Gentoo. While
> > there's only a stage3 for OpenRC that does not exclude the
> > possibility that a stage3 for systemd may be made in the near
> > future.
> 
> Let me put it into simple words:
> 
> Do not break my boot path. Again.
>
> I'm slowly reaching a zero-tolerance stance on regressions that make
> booting unreliable or broken, and just replacing OpenRC is about the
> worst way to trigger unexpected behaviour.

Please state how your boot path has broken. Or is this hypothetical?

> > Same for you, is your agenda to keep OpenRC and block any
> > alternatives?
> 
> I tolerate alternatives, but don't actively support them.

We're not asking you to actively support it.

> > Our agenda is to keep Gentoo what Gentoo is defined as, follow its
> > philosophy and therefore do whatever is needed to provide our users
> > a choice to use Gnome 3.8 in a stable manner.
> 
> ... while still providing reasonable support and stability

Which appears to be provided.

> > I don't see what all this has to do with an agenda of switching to
> > systemd, nobody is keeping you or anybody else from implementing or
> > porting support for OpenRC into GNOME 3.8; even if this were an
> > agenda, it would have been a very inefficient way to switch people
> > to systemd.
> 
> You say that as if we cared for Gnome.

As you are in a thread that is deciding whether to stabilize 3.6 or
3.8, I take the assumption that you care for it; if not, I'm not sure
what you are trying to reach here.

> > There are a lot of Gentoo developers supporting it.
>
> Flashback to 2006... so it is true, the wheel keeps turning ...

Support can possibly change over 7 years, for any software product.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sat, 10 Aug 2013 18:55:03 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> Lots of users ran into troubles, and like in the current situation
> they were unable to get support as they ran an actively unsupported
> configuration.

Support for it is given all over the place; like for instance in #gentoo
and #gentoo-desktop on the FreeNode IRC network, on the Gentoo Forums,
on the gentoo-user ML as well as for bugs on the Bugzilla bug tracker.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Ben Kohler]

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

On Sat, Aug 10, 2013 at 6:59 AM, Tom Wijsman <TomWij@gentoo.org> wrote:

>
>
> Support for it is given all over the place; like for instance in #gentoo
> and #gentoo-desktop on the FreeNode IRC network, on the Gentoo Forums,
> on the gentoo-user ML as well as for bugs on the Bugzilla bug tracker.
>
> The people saying this is unsupported are either WISHING it was
unsupported, or they are completely uninformed (w.r.t. systemd usability on
gentoo) and are just here to express general anti-systemd sentiment.  In
either case, they are not really contributing anything worthwhile to this
discussion.

People are running gnome-3.8 and systemd today, on gentoo.  It's working
great for tons of people out there.  We're supporting it in #gentoo and on
the forums today, with much success.  If you ("people out there", not you
Tom) don't realize that yet, please pull your head out of the sand.

-Ben

[-- Attachment #2: Type: text/html, Size: 1362 bytes --]

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[William Hubbs]

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

On Sat, Aug 10, 2013 at 01:51:13PM +0200, Michael Weber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 08/10/2013 01:42 PM, Tom Wijsman wrote:
> > On Sat, 10 Aug 2013 19:04:09 +0800 Patrick Lauer
> > <patrick@gentoo.org> wrote:
> > 
> >> Using llvm doesn't imply removing gcc ...
> > 
> > Using systemd doesn't imply removing openrc ...
> > 
> Running systemd as PID=1 does imply not running openrc as PID=1 *haha*

No, it implies not running init (sysvinit) or runit as pid 1. OpenRc
really isn't an init system; see virtual/init for those. OpenRc is just a
set of init *scripts*.

William


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

[gentoo-dev] Re: [typo] Re: Re: Multiple implementations shouldn't block Gentoo's progress.

[Steven J. Long]

Rich Freeman wrote:
> In general I'd avoid any requirement to use a non-base profile.
> Obviously using the right arch/prefix profile makes sense as those are
> fundamental config changes and they're all minimalist profiles anyway.
>  The issues come when you force users to use non-minimalist profiles
> where we start forcing packages/decisions the users don't agree with.
> (And yes, I realize the whole thread is about forcing a decision users
> don't agree with - but we don't have much choice there.)

That's the point though: given that certain decisions are forced if you want to
use gnome3 (ie you must use systemd, which in turn forces a whole set of decisions
about all the functionality you can no longer mix and match) it makes sense to
wrap those into a profile or some sort of configuration that ensures they get what
they need, by default, until such time as they want to tweak things, and pick up
the pieces.

It's also easier for developers to handle, similar to the KDE profiles. Though I'm
not sure why it's necessary to use a "non-base" profile. We have several
"non-minimalist" profiles already, and the suggestion seems to fit into the
existing framework well: what profiles (and sub-directories thereof) were designed
for, afaict.

Mixins appear to be akin to the eblit/eclass separation, and from what i've read so
far most other profiles don't appear to force so many decisions, just enable what
they need. However if a configuration set does require more, it would appear to be
even _more_ incumbent to use a profile, not less, since it has more consequences
for the end-user than simply adding a defined set of functionality that does not
conflict with anything else.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Steven J. Long]

Tom Wijsman wrote:
> Let's say that I were to develop a system with some other Gentoo devs;
> that doesn't mean we are able to make everything in the tree support
> that system, making it an usable tool for everything is unrealistic

This isn't just "any tool" though: it's the core init-system. Your reasoning
is on shaky ground during this part of your mail, for that reason. If we were
discussing one app against another, or even one DE against another, it would
be a different matter.

The core system has to be a usable basis to build "everything" from. Even if
one end-user choice precludes another. Somehow I don't like the idea of
switching from a systemd-stage3 to openrc, whereas the inverse seems like a
viable option.

> Making such a design choice isn't a fault. There is no need for blame.

Design choices have consequences in terms of where manpower can go, as well as
in terms of end-user capability and flexibility, especially when one of the
"options" has far-reaching implications for the rest of the stack, such that it
is a question of "my way or the high way," which seems counter to the idea of
choice i hear so much about.

It appears to be akin to the argument that freedom means the freedom to hurt
whoever you want without concern.

So it's perfectly reasonable for them to be questioned and criticised.

Please note: I fully support gnome-3.8 stabilising with a hard-requirement
on systemd. News just in: software requires another piece of software to
work.

It's also been obvious for ages that the consensus is to supply unit files
where available, be that from upstream or a Gentoo user/developer, so I wish
people would stop banging on about it (not you, just in general: it's a dead
argument yet it keeps being raised as if that's what the concerns are about.)

The rest of us don't really need to worry that much, imo. It's not like the
kernel's going away, and we now have a viable to alternative to udev once
that gets fully absorbed into the spaghetti-lasagne-fest that is systemd.

The stuff we rely on, the simplicity and modularity, always wins out in the
end, because it's more efficient and more robust in the long-term, and the
wheel turns again, til in a decade there'll be another "amazing innovation"
that "changes everything" if you could just see the light/drink the kool-aid.

It just doesn't get discussed much, since it's in the background doing all
the boring stuff. And has done for decades.

regards,
igli
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sat, 10 Aug 2013 20:34:58 +0100
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> Tom Wijsman wrote:
> > Let's say that I were to develop a system with some other Gentoo
> > devs; that doesn't mean we are able to make everything in the tree
> > support that system, making it an usable tool for everything is
> > unrealistic
> 
> This isn't just "any tool" though: it's the core init-system. Your
> reasoning is on shaky ground during this part of your mail, for that
> reason. If we were discussing one app against another, or even one DE
> against another, it would be a different matter.
> 
> The core system has to be a usable basis to build "everything" from.

I do agree with this except for "shaky"; it is a nice goal to pursue...

That still does not make us able to do it or make it a realistic goal.

> Even if one end-user choice precludes another. Somehow I don't like
> the idea of switching from a systemd-stage3 to openrc, whereas the
> inverse seems like a viable option.

That's a path people can consider to work on in the future, I guess.

> > Making such a design choice isn't a fault. There is no need for
> > blame.
> 
> Design choices have consequences in terms of where manpower can go,
> as well as in terms of end-user capability and flexibility,
> especially when one of the "options" has far-reaching implications
> for the rest of the stack, such that it is a question of "my way or
> the high way," which seems counter to the idea of choice i hear so
> much about.

"My way or the high way" is giving good service to just a set of users,
because you can't listen and support everyone with limited resources;
as a result it causes alternatives to be created, effectively giving
choice. This is a natural thing to happen, as everything supporting
everything does not sound possible at all; it is therefore unrealistic.

> It appears to be akin to the argument that freedom means the freedom
> to hurt whoever you want without concern.
>
> So it's perfectly reasonable for them to be questioned and criticised.

Not sure what and whom you mean to refer to by this.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[vivo75]

On 08/09/13 15:54, Michał Górny wrote:
> Dnia 2013-08-09, o godz. 14:14:12
> "vivo75@gmail.com" <vivo75@gmail.com> napisał(a):
>> On 08/09/13 13:38, Pacho Ramos wrote:
>>> El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
>>>> On 08/09/2013 07:26 PM, Tom Wijsman wrote:
>>>>> On Fri, 09 Aug 2013 19:31:22 +0800
>>>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>>>
>>>>>> You just removed the upgrade path for users.
>>>>> The upgrade path is to install systemd or to implement openrc support.
>>>>>
>>>> Invalid upgrade path.
>>>>
>>>> "The upgrade path is to install Fedora" is about as reasonable, and
also
>>>> not acceptable.
>>>>
>>> The upgrade path is to run systemd, not migrate to fedora. As simply as
>>> such
>>>
>> is systemd useful if not run with PID=1 ? Honest question
> Not a honest question but either honest troll, or you're awfully lazy
> and just making noise here.

No really, I've tried systemd but only as init, and,
since I'm not a gnome user I'm rather ignorant on it's internals.
Yet gnome it's an important piece of the opensource ecosystem, and
decision taken for gnome sometimes have repercusions also on different
DE like kde which is my main interest.

> So the answer is: yes, it's quite useful when run with PID!=1. It's
> called systemd user instance (something OpenRC totally can't handle)
> and it can be used to manage user services.
>
> But I have no idea how is that relevant since you obviously know that
> the problem here requires running systemd as PID 1.

I could have argued it was relevant, but again no, I didn't know for sure.
My experience with systemd has only been as only init system (PID=1)
even when using the (now dead?) overlay from Fabio which tried to make
openrc and systemd coexist.

Thanks to everyone responded

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Roy Bamford]

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

On 2013.08.07 13:45, Michael Weber wrote:
> Greetings,
> 
> Gnome Herd decided to target stablilization of 3.8 [1] which requires
> systemd.
> 
[snip]
> 
>    Michael
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252
> -- 
> Michael Weber
> Gentoo Developer
> web: https://xmw.de/
> mailto: Michael Weber <xmw@gentoo.org>
> 
> 

The Gnome team has made their choice.  I'm the light of that, users can 
now make their own choices.

That's what Gentoo is about after all ... choice.

I fully support the Gnome teams choice ... now I have to make one of my 
own. 
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Wulf C. Krueger]

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

On 09.08.2013 02:26, Mike Auty wrote:
> I could be a KDE developer, or a Gentoo documenter, or work on 
> mplayer.  All those people are open source contributors and
> necessary ones, but that doesn't mean that any of them necessarily
> has the skills or the time to look after udev.  Does that
> invalidate their opinion on the choices of upstream project they
> rely on?

Yes, it does.

- -- 
Best regards, Wulf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIGwcwACgkQnuVXRcSi+5qGZwCcC22pW4P93IIeHx6srfFsxkJ9
bzsAoLiEjyzBFXoaglE5uHv9giNk5B43
=Y30t
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

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

On 10/08/13 23:42, Wulf C. Krueger wrote:
> On 09.08.2013 02:26, Mike Auty wrote:
>> I could be a KDE developer, or a Gentoo documenter, or work on 
>> mplayer.  All those people are open source contributors and 
>> necessary ones, but that doesn't mean that any of them
>> necessarily has the skills or the time to look after udev.  Does
>> that invalidate their opinion on the choices of upstream project
>> they rely on?
> 
> Yes, it does.

In that situation then, developers are only developing for themselves?
 What's more likely is that they've taken a gamble that most users
will simply accept their changes, which they deem as necessary to move
forward.

That would be fine if there were alternative options, but as more and
more things are "vertically integrated" the choices made by one
project are knocking over into others.  Before I could simply ignore
systemd and choose something else, now I'm having to choose between
using both Gnome and systemd, or neither.

It is a difficult choice, but just as Gnome has chosen to forsake my
desire for a simplistic init system at the expense of a little boot
speed and some "features" I've never needed in the past, I'm having to
walk away to some other less well developed desktop environment.  The
cost of ignoring their users opinions is losing the users themselves.
 I don't know how many users they'll have to lose before someone
decides to take the ship in a new direction, but I would like to see
how many they stand to lose, by asking those who care to speak up and
find a way of being heard before the damage is too much to repair...

Mike  5:\
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIGyGUACgkQu7rWomwgFXpeugCeMGQmjB7tcnpZd12DF8Baml0s
xcsAn12+EXQwTSwTeK0lautDxJmwgC7r
=tgWV
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Sat, Aug 10, 2013 at 6:10 PM, Mike Auty <ikelos@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/08/13 23:42, Wulf C. Krueger wrote:
>> On 09.08.2013 02:26, Mike Auty wrote:
>>> I could be a KDE developer, or a Gentoo documenter, or work on
>>> mplayer.  All those people are open source contributors and
>>> necessary ones, but that doesn't mean that any of them
>>> necessarily has the skills or the time to look after udev.  Does
>>> that invalidate their opinion on the choices of upstream project
>>> they rely on?
>>
>> Yes, it does.
>
> In that situation then, developers are only developing for themselves?
>  What's more likely is that they've taken a gamble that most users
> will simply accept their changes, which they deem as necessary to move
> forward.
>
> That would be fine if there were alternative options, but as more and
> more things are "vertically integrated" the choices made by one
> project are knocking over into others.  Before I could simply ignore
> systemd and choose something else, now I'm having to choose between
> using both Gnome and systemd, or neither.
>
> It is a difficult choice, but just as Gnome has chosen to forsake my
> desire for a simplistic init system at the expense of a little boot
> speed and some "features" I've never needed in the past, I'm having to
> walk away to some other less well developed desktop environment.  The
> cost of ignoring their users opinions is losing the users themselves.
>  I don't know how many users they'll have to lose before someone
> decides to take the ship in a new direction, but I would like to see
> how many they stand to lose, by asking those who care to speak up and
> find a way of being heard before the damage is too much to repair...

We have been having this discussion since GNOME 3.0 came out, and some
would argue that since GNOME 2.0, or even before.

The GNOME project will go where the developers of the GNOME project
decide to, period. There is MATE if you really want the old GNOME 2,
Cinnamon if you only want something similar to the old interface, or
KDE/Xfce/E17 if you want to switch. Arguing with the GNOME developers
like they don't know what they are doing is pointless at best, and
frankly insulting at worst.

They thought deeply about the changes that are being made to the
desktop, and they discussed it and reached a consensus about what the
direction of the project is; you can usually read about in the mailing
lists, Planet GNOME, or even watch the videos from the GUADEC
presentations. You can of course disagree with that direction: but
acting like they, poor things, don't know what they are doing and need
that someone go an tell them so they can know "before the damage is
much to repair", is quite condescending.

People have been predicting the dead of GNOME since before the 1.0
version came out, but right now it has more contributors than ever in
the past, and at least half a dozen companies actually pay money to
people to work in it, so perhaps they actually know what they are
doing. But even if they don't, there are a couple forks you can try or
several alternatives you can switch to if "the damage is too much to
repair".

And at the end of the day, all that code is 100% Free Software, with
public repositories with all the history of the components of the
project for all the world to see and use.

The GNOME developers already made their decision. The GNOME
maintainers in Gentoo followed through (like they have been doing in
almost every other distro). Now it's up to each user to decide if she
keeps using GNOME (and therefore switches, if necessary, to systemd
since 3.8), or if she stops using it.

Arguing about it is quite useless.

Regards from a  (very happy, very proudly) GNOME+systemd Gentoo user.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Sun, 11 Aug 2013 00:10:29 +0100
Mike Auty <ikelos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/08/13 23:42, Wulf C. Krueger wrote:
> > On 09.08.2013 02:26, Mike Auty wrote:
> >> I could be a KDE developer, or a Gentoo documenter, or work on 
> >> mplayer.  All those people are open source contributors and 
> >> necessary ones, but that doesn't mean that any of them
> >> necessarily has the skills or the time to look after udev.  Does
> >> that invalidate their opinion on the choices of upstream project
> >> they rely on?
> > 
> > Yes, it does.
> 
> In that situation then, developers are only developing for themselves?
>  What's more likely is that they've taken a gamble that most users
> will simply accept their changes, which they deem as necessary to move
> forward.
> 
> That would be fine if there were alternative options, but as more and
> more things are "vertically integrated" the choices made by one
> project are knocking over into others.  Before I could simply ignore
> systemd and choose something else, now I'm having to choose between
> using both Gnome and systemd, or neither.
> 
> It is a difficult choice, but just as Gnome has chosen to forsake my
> desire for a simplistic init system at the expense of a little boot
> speed and some "features" I've never needed in the past, I'm having to
> walk away to some other less well developed desktop environment.  The
> cost of ignoring their users opinions is losing the users themselves.
>  I don't know how many users they'll have to lose before someone
> decides to take the ship in a new direction, but I would like to see
> how many they stand to lose, by asking those who care to speak up and
> find a way of being heard before the damage is too much to repair...

You are basing yourself on too much FUD[1] which may or may not happen;
the only influence you can have is as you said yourself, it sounds like
that people that are deeply concerned with this should step up and
start a petition[2] for this and find like minded people.

Direct yourself upstream[3] or take a gamble whether to use it or not.

 [1]: http://www.wordnik.com/words/FUD
 [1]: http://article.gmane.org/gmane.linux.gentoo.devel/87264
 [2]: http://www.gnome.org/contact/

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

iQEcBAEBAgAGBQJSBtQ9AAoJEJWyH81tNOV99dAH/16/nfLiHrHlv1vv1EnUB3RQ
oET5MpWIrAxEx6e1CxA5A4/eu0l79QK23DnDrDl3VAL/K2d2+tppVx24IMQeWt4H
jw1+l4tm9KnNlF9WWSsehY7uoe7dIhzmOTJVTF1VfTo/DdIqiOlTya5/SraGTlkC
WCJjGIqK3rHu872af2mjKxprr7UaT4mv9/VhYcjFiw+z0arXRy4F8oDGHE7VUTDZ
dLknKEf3zEUoxGRSZAE+vGi1fNRKONNoNS+W0EyBSRWyFQ+DepGhH3j71tXwCgXi
9o4D+wUMFORfF1s1ZLRpUPBH2M/aFJpb5pyZP4bZQ5NqSsqXFWaW8YIUmIK5MYE=
=1t6r
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

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

On 11/08/13 00:45, Canek Peláez Valdés wrote:
> They thought deeply about the changes that are being made to the 
> desktop, and they discussed it and reached a consensus about what
> the direction of the project is; you can usually read about in the
> mailing lists, Planet GNOME, or even watch the videos from the
> GUADEC presentations. You can of course disagree with that
> direction: but acting like they, poor things, don't know what they
> are doing and need that someone go an tell them so they can know
> "before the damage is much to repair", is quite condescending.

I'm not trying to be condescending and I'm not suggesting they don't
know what they're doing.  If I were to suggest it, doing so on a
Gentoo thread about stabilization would be futile.  The only reason
I'm responding on here is to find out from others in my community if
there's a place that people are collecting their opinions such that it
might be heard/discussed by the people at Gnome.

> People have been predicting the dead of GNOME since before the 1.0 
> version came out, but right now it has more contributors than ever
> in the past, and at least half a dozen companies actually pay money
> to people to work in it, so perhaps they actually know what they
> are doing. But even if they don't, there are a couple forks you can
> try or several alternatives you can switch to if "the damage is too
> much to repair".

Just because companies pour money into something does not mean they
know what they're doing, or that they've done their market research
into what their users want.  I've tried several of the forks, and
sadly Gnome, because of the backing it's had, hangs together as a
Desktop Environment the best which is precisely why it's so
disappointing they've chosen this strong a demand of their users.  I
have even tried systemd, which realized rather than allayed my fears,
but this isn't the place for my personal experiences with that.

I'm interested in solutions, specifically to get the most out of Gnome
without being forced to make changes lower down my system's stack.  If
necessary, I'd at least like to have a logind that works distinct from
systemd, according to a well defined specification that can be created
separate to any one implementation (like the PMS provided for package
managers), and ask Gnome to work to that specification.  Until
systemd-205, that was possible.  The fact that systemd has the power
to remove that ability in a single version bump, and did so without
thought for the impact on Gnome, should be worrying to Gnome for the
future, not just to the users that were affected now.  The hope for a
clear specification that can't be changed or dictated by a single
implementation feels like a fair compromise, but unless I know where
to suggest that, or where it has already been suggested, it won't help
in the slightest.

> And at the end of the day, all that code is 100% Free Software,
> with public repositories with all the history of the components of
> the project for all the world to see and use.

I've already addressed how this doesn't help those who contribute to
open source software, but don't have the skills to manage such a large
and important project.

> The GNOME developers already made their decision. The GNOME 
> maintainers in Gentoo followed through (like they have been doing
> in almost every other distro). Now it's up to each user to decide
> if she keeps using GNOME (and therefore switches, if necessary, to
> systemd since 3.8), or if she stops using it.
> 
> Arguing about it is quite useless.

Having read my emails, you'll have seen that I haven't been arguing,
I've been expressing a desire to collect together those who disagree
with the decision and communicate it such that the decision might get
discussed publicly.  I have yet to be pointed to the processes and
procedures whereby the decision to make systemd a hard dependency was
carried out.  In Gnome 2 there were specific meetings, well
documented, to discuss and decide the "blessed dependencies", but
those and several other key decision-making meetings now appear to
happen outside of the public infrastructure.  This is to the point
where there were public emails saying systemd would not become a hard
dependency for gnome-3.8 and yet here we are.

The Gentoo Gnome herd tried their hardest to avoid the move to
systemd, and I have mentioned my appreciation for their efforts in my
previous emails.  I am currently exploring my options, as you
reiterated my point back to me, but one of those is to not give up
hope on the Gnome project or their developers and to try to
communicate with them.  However, having people assume I'm arguing
because I'm keen to get to the bottom of their decision making doesn't
help...

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIG5ZQACgkQu7rWomwgFXrWVACeJakbnBmoJfYP91wOrC/EmG6W
EMAAn1yZItvdNyz6AuPhcnbk9MBxcYVb
=iOpy
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Sat, Aug 10, 2013 at 9:15 PM, Mike Auty <ikelos@gentoo.org> wrote:
> Just because companies pour money into something does not mean they
> know what they're doing, or that they've done their market research
> into what their users want.  I've tried several of the forks, and
> sadly Gnome, because of the backing it's had, hangs together as a
> Desktop Environment the best which is precisely why it's so
> disappointing they've chosen this strong a demand of their users.

Sounds like a complaint many have had about Unity.  In the case of
Ubuntu they decided that the typical linux user of the past was not
the target market for the user of the future.

In the case of Gnome there is no market - volunteer-based FOSS
communities tend to be bound by common values and they pursue those
values regardless of whether it grows the community.  If I suggested
that binary distros are far more popular therefore Gentoo should
become one, I doubt that anybody would take it as anything but a joke.
 What we think is great in a distro and what the average Debian user
thinks is great is bound to be different.

That's basically how the Gnome devs feel - they're pursuing what they
feel is the best solution.  Whether anybody else uses it is a
secondary concern for them.  They probably will aim to make it as
usable to newcomers as they can, as far as they see usability.

Rich

Re: [gentoo-dev] Re: [typo] Re: Re: Multiple implementations shouldn't block Gentoo's progress.

[Rich Freeman]

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

On Aug 10, 2013 2:41 PM, "Steven J. Long" <slong@rathaus.eclipse.co.uk>
wrote:
> It's also easier for developers to handle, similar to the KDE profiles.
Though I'm
> not sure why it's necessary to use a "non-base" profile. We have several
> "non-minimalist" profiles already, and the suggestion seems to fit into
the
> existing framework well: what profiles (and sub-directories thereof) were
designed
> for, afaict.

To clarify, I have no issues with the existing gnome profile installing
systemd and such. That just makes sense.  Not doing so makes the existing
profile less useful

I just don't think that you should HAVE to use that profile to use gnome,
or that we should have a systemd profile that must be used to run systemd
in general. If we go along that route we'll end up with a bazillion
combinations of profiles for various packages where it is convenient for
maintainers to limit config variability. Every application is easier to
support with less variability, and that is why binary distros just take the
choices away.

If the differences between openrc and systemd were more significant (in
terms of the necessary configuration changes to work with them), then
mandatory profile use would make sense.

Rich

[-- Attachment #2: Type: text/html, Size: 1488 bytes --]

[gentoo-dev] Re: [typo] Re: Re: Multiple implementations shouldn't block Gentoo's progress.

[Duncan]

Steven J. Long posted on Sat, 10 Aug 2013 19:42:11 +0100 as excerpted:

> That's the point though: given that certain decisions are forced if you
> want to use gnome3 (ie you must use systemd, which in turn forces a
> whole set of decisions about all the functionality you can no longer mix
> and match) it makes sense to wrap those into a profile or some sort of
> configuration that ensures they get what they need, by default

++

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 09/08/13 12:51, Pacho Ramos wrote:
> El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn
> escribió:
>> Pacho Ramos schrieb:
>>>> If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
>>>> patches that make it possible to install Gnome 3.8 without systemd again?
>>>> Only make it possible, not turn it into a configuration which the Gnome team
>>>> supports.
>>>
>>> We have discussed this some times in the team, the problem is that we
>>> don't think we should provide "by default" a setup that is not working
>>> properly: powermanagement, multiseat support and gdm service handling
>>
>> I don't say that it should be the default.
>>
>>> Also, if that people reports problems, we would
>>> close them as WONTFIX -> migrate to systemd
>>
>> That's what I meant when I wrote not a configuration that Gnome team supports.
>>
>>> - You can ignore the warnings, news and suggestions and, even moving
>>> from udev to systemd ebuild, keep booting with openRC and using systemd
>>> as device manager
>>> - You can put systemd in package.provides to even keep running udev
>>
>> The good part about package.provided is that users definitely know that they
>> are running an unsupported configuration with it. The bad part is that
>> putting systemd in package.provided is a bit dangerous, as this can lead to
>> udev unmerge on depclean if you are not careful.
>>
>
> This makes me think what is the problem with people moving to systemd as
> udev provider (even running openrc) :/

Because sys-apps/systemd is installed in wrong directory structure in /usr
I still carry systemd in my local overlay instead of using it from 
Portage, just to put it in / as per upstream recommendation :-/
We have tried to reach consensus, but there is a disagreement that we 
have left at "We agree that we don't agree."

Pushing that aside, there is also the heavy dependencies of 
sys-apps/systemd in comparison to sys-fs/udev

> 1. The first solution (moving to systemd as udev provider) would be
> "easy" and would behave as bad as openBSD does (having the unsupported
> and mid working setup)
> 2. About the other one: probably somebody adding systemd to
> package.provide *on purpose* will remember to know that he needs a
> device manager (either udev or eudev) and don't let depclean remove
> it :|
>
> Other possible solution would be the following:
> 3. Add a "openrc-force" USE flag to offending packages. This USE flag
> would be masked in all profiles, needing users to unmask it locally (the
> packages would warn about it when enabling and so)
>
>
>
>

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El dom, 11-08-2013 a las 08:41 +0300, Samuli Suominen escribió:
> On 09/08/13 12:51, Pacho Ramos wrote:
> > El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn
> > escribió:
> >> Pacho Ramos schrieb:
> >>>> If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
> >>>> patches that make it possible to install Gnome 3.8 without systemd again?
> >>>> Only make it possible, not turn it into a configuration which the Gnome team
> >>>> supports.
> >>>
> >>> We have discussed this some times in the team, the problem is that we
> >>> don't think we should provide "by default" a setup that is not working
> >>> properly: powermanagement, multiseat support and gdm service handling
> >>
> >> I don't say that it should be the default.
> >>
> >>> Also, if that people reports problems, we would
> >>> close them as WONTFIX -> migrate to systemd
> >>
> >> That's what I meant when I wrote not a configuration that Gnome team supports.
> >>
> >>> - You can ignore the warnings, news and suggestions and, even moving
> >>> from udev to systemd ebuild, keep booting with openRC and using systemd
> >>> as device manager
> >>> - You can put systemd in package.provides to even keep running udev
> >>
> >> The good part about package.provided is that users definitely know that they
> >> are running an unsupported configuration with it. The bad part is that
> >> putting systemd in package.provided is a bit dangerous, as this can lead to
> >> udev unmerge on depclean if you are not careful.
> >>
> >
> > This makes me think what is the problem with people moving to systemd as
> > udev provider (even running openrc) :/
> 
> Because sys-apps/systemd is installed in wrong directory structure in /usr
> I still carry systemd in my local overlay instead of using it from 
> Portage, just to put it in / as per upstream recommendation :-/
> We have tried to reach consensus, but there is a disagreement that we 
> have left at "We agree that we don't agree."
> 
> Pushing that aside, there is also the heavy dependencies of 
> sys-apps/systemd in comparison to sys-fs/udev
> 

Maybe the second point could be solved having some kind of "minimal" USE
flag for systemd building it with only the minimum set for running udev
without adding so many dependencies. Regarding the first issue, I have
also seen that will be nearly impossible to reach a consensus because we
are currently in a strange intermediate situation: we don't have a setup
ready to run without /usr but neither /usr merge work :|

Then, I guess will have to live with this two alternatives more time :/,
but people running Gnome will need to keep /usr mounted and, then, they
won't suffer the first problem of place installation. Also, the extra
dependencies won't be so "extra" for gnome users, letting them to move
to systemd ebuild easily

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Samuli Suominen]

On 11/08/13 10:31, Pacho Ramos wrote:
> El dom, 11-08-2013 a las 08:41 +0300, Samuli Suominen escribió:
>> On 09/08/13 12:51, Pacho Ramos wrote:
>>> El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn
>>> escribió:
>>>> Pacho Ramos schrieb:
>>>>>> If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
>>>>>> patches that make it possible to install Gnome 3.8 without systemd again?
>>>>>> Only make it possible, not turn it into a configuration which the Gnome team
>>>>>> supports.
>>>>>
>>>>> We have discussed this some times in the team, the problem is that we
>>>>> don't think we should provide "by default" a setup that is not working
>>>>> properly: powermanagement, multiseat support and gdm service handling
>>>>
>>>> I don't say that it should be the default.
>>>>
>>>>> Also, if that people reports problems, we would
>>>>> close them as WONTFIX -> migrate to systemd
>>>>
>>>> That's what I meant when I wrote not a configuration that Gnome team supports.
>>>>
>>>>> - You can ignore the warnings, news and suggestions and, even moving
>>>>> from udev to systemd ebuild, keep booting with openRC and using systemd
>>>>> as device manager
>>>>> - You can put systemd in package.provides to even keep running udev
>>>>
>>>> The good part about package.provided is that users definitely know that they
>>>> are running an unsupported configuration with it. The bad part is that
>>>> putting systemd in package.provided is a bit dangerous, as this can lead to
>>>> udev unmerge on depclean if you are not careful.
>>>>
>>>
>>> This makes me think what is the problem with people moving to systemd as
>>> udev provider (even running openrc) :/
>>
>> Because sys-apps/systemd is installed in wrong directory structure in /usr
>> I still carry systemd in my local overlay instead of using it from
>> Portage, just to put it in / as per upstream recommendation :-/
>> We have tried to reach consensus, but there is a disagreement that we
>> have left at "We agree that we don't agree."
>>
>> Pushing that aside, there is also the heavy dependencies of
>> sys-apps/systemd in comparison to sys-fs/udev
>>
>
> Maybe the second point could be solved having some kind of "minimal" USE
> flag for systemd building it with only the minimum set for running udev
> without adding so many dependencies. Regarding the first issue, I have
> also seen that will be nearly impossible to reach a consensus because we
> are currently in a strange intermediate situation: we don't have a setup
> ready to run without /usr but neither /usr merge work :|
>
> Then, I guess will have to live with this two alternatives more time :/,
> but people running Gnome will need to keep /usr mounted and, then, they
> won't suffer the first problem of place installation. Also, the extra
> dependencies won't be so "extra" for gnome users, letting them to move
> to systemd ebuild easily

I'm propably opening a can of worms here but...

I've been considering packaging systemd in sys-fs/udev with 
USE="systemd" and use of 'if' and 'else' plus creating virtual/systemd 
for proper / installation and some other minor, but bad design choices 
done in the systemd packaging

Previously, which isn't really true anymore because logind without 
systemd is a dead end, there was also a reasoning of packaging logind, 
and this type of packaging would have reduced the ebuild number to just 
'udev', from 'udev, logind, systemd' since it's all from the same tarball

But now, the reason I haven't gone forward with it, is that I'm still 
maintaining too much OpenRC related software that systemd has made 
'deprecated' and I need OpenRC based system to be able to do that, and 
using VM, dualboot or second machine for that is creating too much 
overhead for my limited time

As in, I haven't made the final switch to systemd yet as a primary init 
system on the main development machine which I consider a prereq for 
packaging it, thus I'm keeping my hands off it and stick to the overlay

So with that said, I'm committed to keeping sys-fs/udev maintained and 
the default for long as sys-apps/openrc is the default
If sys-fs/udev ever stops working without systemd, I'll maintain a 
minimal patchset that reverts those changes, and if that becomes 
unsustainable, we might consider forking it, but thistype of speculation 
is far in the future (and the reason why sys-fs/eudev at this early 
stage is stupid)

- Samuli

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Sun, Aug 11, 2013 at 2:31 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> El dom, 11-08-2013 a las 08:41 +0300, Samuli Suominen escribió:
>> On 09/08/13 12:51, Pacho Ramos wrote:
>> > El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn
>> > escribió:
>> >> Pacho Ramos schrieb:
>> >>>> If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
>> >>>> patches that make it possible to install Gnome 3.8 without systemd again?
>> >>>> Only make it possible, not turn it into a configuration which the Gnome team
>> >>>> supports.
>> >>>
>> >>> We have discussed this some times in the team, the problem is that we
>> >>> don't think we should provide "by default" a setup that is not working
>> >>> properly: powermanagement, multiseat support and gdm service handling
>> >>
>> >> I don't say that it should be the default.
>> >>
>> >>> Also, if that people reports problems, we would
>> >>> close them as WONTFIX -> migrate to systemd
>> >>
>> >> That's what I meant when I wrote not a configuration that Gnome team supports.
>> >>
>> >>> - You can ignore the warnings, news and suggestions and, even moving
>> >>> from udev to systemd ebuild, keep booting with openRC and using systemd
>> >>> as device manager
>> >>> - You can put systemd in package.provides to even keep running udev
>> >>
>> >> The good part about package.provided is that users definitely know that they
>> >> are running an unsupported configuration with it. The bad part is that
>> >> putting systemd in package.provided is a bit dangerous, as this can lead to
>> >> udev unmerge on depclean if you are not careful.
>> >>
>> >
>> > This makes me think what is the problem with people moving to systemd as
>> > udev provider (even running openrc) :/
>>
>> Because sys-apps/systemd is installed in wrong directory structure in /usr
>> I still carry systemd in my local overlay instead of using it from
>> Portage, just to put it in / as per upstream recommendation :-/
>> We have tried to reach consensus, but there is a disagreement that we
>> have left at "We agree that we don't agree."
>>
>> Pushing that aside, there is also the heavy dependencies of
>> sys-apps/systemd in comparison to sys-fs/udev
>>
>
> Maybe the second point could be solved having some kind of "minimal" USE
> flag for systemd building it with only the minimum set for running udev
> without adding so many dependencies. Regarding the first issue, I have
> also seen that will be nearly impossible to reach a consensus because we
> are currently in a strange intermediate situation: we don't have a setup
> ready to run without /usr but neither /usr merge work :|
>
> Then, I guess will have to live with this two alternatives more time :/,
> but people running Gnome will need to keep /usr mounted and, then, they
> won't suffer the first problem of place installation.

systemd doesn't support separated /usr without an initramfs, so there
is no problem now that GNOME requires it.

>  Also, the extra
> dependencies won't be so "extra" for gnome users, letting them to move
> to systemd ebuild easily

And there is that. Although the only hard (runtime) dependencies of
systemd-206-r3 are:

sys-apps/dbus
sys-apps/util-linux
sys-libs/libcap
sys-apps/baselayout
sys-apps/hwids

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Rich Freeman]

On Sun, Aug 11, 2013 at 3:51 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> I've been considering packaging systemd in sys-fs/udev with USE="systemd"
> and use of 'if' and 'else' plus creating virtual/systemd for proper /
> installation and some other minor, but bad design choices done in the
> systemd packaging

What is the consensus of the systemd team regarding those choices?
Would it make more sense to just fix the packaging rather than forking
it?  I'm not sure what all the issues are, or how widespread the
disagreement is.

As far as installation in / vs /usr goes - that seems like something
that could be made configurable in the systemd package.  I believe
others have been wondering if an optional usr-move config setting of
some kind (might or might not be a USE flag) would be useful.  The
profile default would be for things to stay as they are, but those who
want to do a move could set the flag.  That is worth some further
discussion before implementing it - it might also make sense to
install compatibility symlinks in / when using it unless it is
detected that / already contains symlinks (individual symlinks is not
how Fedora is proposing handling the move, but I would think that it
would work and it has the virtue of letting users migrate bit by bit
until / is empty and they can replace the root dirs with symlinks).

Rich

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Walter Dnes]

On Thu, Aug 08, 2013 at 04:19:26PM -0700, Greg KH wrote
> On Thu, Aug 08, 2013 at 09:40:00PM +0100, Mike Auty wrote:
> > On 08/08/13 11:38, Samuli Suominen wrote:
> > > i'm not volunteering but I never really got why our GNOME
> > > maintainers insisted on staying with it instead of going with the
> > > distribution after it was clear logind is a dead end on non-systemd
> > > systemd
> > 
> > Ok,
> > 
> > So there's lots of people that don't want systemd.  Can't we group
> > together and have some kind of an affect on upstream?
> 
> Become upstream developers and create fixes to remove the dependancy
> either by working on openrc features to emulate the same things that
> systemd has that GNOME requires, or split things out of GNOME so that it
> does not require systemd dependencies.
> 
> But to complain to upstream without providing patches is a bit futile,
> don't you think?  That's not how open source projects work, we all know
> that.
> 
> greg k-h
> 
> 

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Walter Dnes]

On Thu, Aug 08, 2013 at 09:40:00PM +0100, Mike Auty wrote

> So there's lots of people that don't want systemd.  Can't we group
> together and have some kind of an affect on upstream?

  The answer is... probably not, given the "My way or the Highway"
attitude of the GNOME developers.

GNOME users who are unhappy about systemd, are being forced to choose...

* either they run GNU/Linu-x

* or else they run GNOME/Lenna-x

...pick 1 of the above.

> Is there some way, we as the Gentoo Foundation, Developers or even
> just Users can form a petition, or an open letter, that might make
> enough impact on the Gnome foundation for them to reconsider their
> position?

  Again, no, they haven't listened to end users in the past, and they
will not listen to end users now.  Even more so if you're a 
Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy

http://lalists.stanford.edu/lad/2009/06/0191.html

> Perhaps if there were an "init system specification" project, separate
> from systemd, that systemd had to adhere to rather than deciding to
> change the rules at a random version (like 205), then Gnome could
> potentially have other options than just systemd?

  Again, how do you force a rogue upstream development team to follow
*YOUR* rules?  Answer; you can't.  If you want GNOME-like "goodness",
consider Cinnamon/Consort/Mate/Kate/etc/etc.  I'm a neutral observer of
this entire mess... see my sig.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Steven J. Long]

On Sat, Aug 10, 2013:
Tom Wijsman wrote:
> "Steven J. Long" wrote:
> 
> > The core system has to be a usable basis to build "everything" from.
> 
> I do agree with this except for "shaky"; it is a nice goal to pursue...
> 
> That still does not make us able to do it or make it a realistic goal.

But it's exactly what the standard Gentoo install supplies, or used to. So
it's very realistic, since it's the basis we've been using for a decade.

And you are able to do it. Losing that capability is nothing more or less
than a regression for a meta-distribution.

> > > Making such a design choice isn't a fault. There is no need for
> > > blame.
> > 
> > Design choices have consequences in terms of where manpower can go,
> > as well as in terms of end-user capability and flexibility,
> > especially when one of the "options" has far-reaching implications
> > for the rest of the stack, such that it is a question of "my way or
> > the high way," which seems counter to the idea of choice i hear so
> > much about.
> 
> "My way or the high way" is giving good service to just a set of users,
> because you can't listen and support everyone with limited resources;
> as a result it causes alternatives to be created, effectively giving
> choice.

This is a total non-sequitur, given that we already have choice. Taking it
away does not create choice: it merely restricts everyone until a "hate"
fork happens, or some other alternative is provided, to restore the previous
state of affairs.

Though to be honest, your argument is more akin to a conceptual discussion as
to "whether an argument could be made" rather than "what is the best way
forward in the long-term for the diverse user-base." Not very practical, imo.

"Giving service to a set of users" is not at all the same as "my way or the
high way." The latter is what happens when you get non-modular software that
tries to do too much, under the banner of "One True Way" to disguise the awful
coupling, however it's dressed up.

The former is what happens when you install say an httpd to serve an intranet.
It doesn't dictate what other pieces of software you can use for orthogonal
purposes (or suddenly expand its feature-base to include everything else so it
isn't orthogonal any more.)

> This is a natural thing to happen, as everything supporting
> everything does not sound possible at all; it is therefore unrealistic.

What's unrealistic is expecting us to swallow regressions as progress.
 
> > So it's perfectly reasonable for them to be questioned and criticised.
> 
> Not sure what and whom you mean to refer to by this.

"Design choices." Hell, that's one of the main purposes of this list; it's
why the GLEP process mentions the list, for example.


Sorry for delay, missed this in my inbox.
Regards,
steveL.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8

[Tom Wijsman]

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

On Fri, 23 Aug 2013 14:27:02 +0100
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> On Sat, Aug 10, 2013:
> Tom Wijsman wrote:
> > "Steven J. Long" wrote:
> > 
> > > The core system has to be a usable basis to build "everything"
> > > from.
> > 
> > I do agree with this except for "shaky"; it is a nice goal to
> > pursue...
> > 
> > That still does not make us able to do it or make it a realistic
> > goal.
> 
> But it's exactly what the standard Gentoo install supplies, or used
> to. So it's very realistic, since it's the basis we've been using for
> a decade.

You start from something small, which does the described thing; but
once you grow to something bigger, you are suddenly no longer able to
satisfy that description.

In order to continue to grow bigger, you need to cut corners and take
decisions; in other words, you can no longer hold on to the prototype
that was made but start to need to face the realism that is out there.

Just because you can start with something, doesn't mean it is scalable;
supporting more comes at its own cost, which may not give enough ROI.

> And you are able to do it.

At the cost of other things; so, in the whole picture, one can think of
it as an unrealistic goal unless someone does want to do all the work
without leaving other users that use the software product in the dark.

> Losing that capability is nothing more or less than a regression for
> a meta-distribution.

It is as much a loss as it is a gain; a software product that doesn't
deal with bugs because it has to be busy with supporting everything
that is out there, is going to leave other regressions behind as well.

> > > Design choices have consequences in terms of where manpower can
> > > go, as well as in terms of end-user capability and flexibility,
> > > especially when one of the "options" has far-reaching implications
> > > for the rest of the stack, such that it is a question of "my way
> > > or the high way," which seems counter to the idea of choice i
> > > hear so much about.
> > 
> > "My way or the high way" is giving good service to just a set of
> > users, because you can't listen and support everyone with limited
> > resources; as a result it causes alternatives to be created,
> > effectively giving choice.
> 
> This is a total non-sequitur, given that we already have choice.

You have a choice, but don't have support for it; it is still their
choice whether to choose to support you, and when they do, they are
giving less support in other places as a result of a cost in time.

> Taking it away does not create choice: it merely restricts everyone
> until a "hate" fork happens, or some other alternative is provided,
> to restore the previous state of affairs.

Well, such happenings would introduce a supported choice.

> Though to be honest, your argument is more akin to a conceptual
> discussion as to "whether an argument could be made" rather than
> "what is the best way forward in the long-term for the diverse
> user-base." Not very practical, imo.

As long as nobody wants to do the work, it remains conceptual; the best
way forward is to work with what we are given, until someone gives us
what we want or we really want to do the work we want ourselves.

> "Giving service to a set of users" is not at all the same as "my way
> or the high way." The latter is what happens when you get non-modular
> software that tries to do too much, under the banner of "One True
> Way" to disguise the awful coupling, however it's dressed up.

There are not a lot of products that can give service to everyone; so,
people use what they believe is the "One True Way" for them.

> The former is what happens when you install say an httpd to serve an
> intranet. It doesn't dictate what other pieces of software you can
> use for orthogonal purposes (or suddenly expand its feature-base to
> include everything else so it isn't orthogonal any more.)

When you buy a small row house without a garage or a ramp; you will not
be able to park your car in your just bought house. If you try to do it
anyway, you will break it.

> > This is a natural thing to happen, as everything supporting
> > everything does not sound possible at all; it is therefore
> > unrealistic.
> 
> What's unrealistic is expecting us to swallow regressions as progress.

The opposite is also unrealistic; so, they had to make a design choice.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Olav Vitters]

[ Apologies for replying so late

  I am not intending to startup the discussion regarding systemd ]

On Fri, Aug 09, 2013 at 09:36:47AM +0200, Gilles Dartiguelongue wrote:
> For the record we did and still do support setups that upstream does not
> care about.
>  * In the past, we had policykit/polkit optional, we had to stop that
> since it is now too tied in to be decently maintained at our level
>  * We had pulseaudio optional, again, this is now over in some of the
> core components of Gnome, but we do keep it optional were possible
>  * We maintain networkmanager and bluetooth support optional, and this
> has been the case since 3.2 iirc even though upstream flat out refuses
> to merge our perfectly fine patches

Feel free to cc release-team@gnome.org on such patches. I am not saying
something would change, however, Bluetooth is optional in gnome-shell
(though in 3.9.x it crashed if you disabled it). Seems a bit strange to
have it optional in one place, forced in another.

> Keeping systemd optional in Gnome cannot be achieved by the Gentoo Gnome
> team. If someone comes up with a solution to have logind without
> systemd, we will gladly include it but remember that a few devs (4/5
> afaik) already tried and sadly failed.

Intention was not to force systemd. It just seems to have ended up that
way. The various times I asked there has been a lot of work going on
into supporting non-systemd configurations as changes are made. However,
that work is mostly untested and likely buggy (things needs to be used).
I thought the work was good enough (though knew that Debian would go
with requiring systemd as a dependency)

It seems that for Wayland support we somehow do need to require logind
(I forgot why exactly, though I do have IRC logs somewhere). At the
moment that seems unlikely to change. I'm planning to write a proper
message about this to distributor-list.

As development goes on, more and more does indeed depend on systemd.
However, if I look at http://cgit.freedesktop.org/ConsoleKit/log/, most
of the development was made by people involved in GNOME. There are no
recent development for at least 1.5 year. The intention is not to force
things, but seems rather logical the way it ends up.

Most of the development was done within ConsoleKit, now mostly done
within systemd. It would be nice if the logind part was optional like it
was initially, but I don't know if that would still be a no-go for
Gentoo. E.g. does it have to be ConsoleKit, or is a logind also ok? Note
that Ubuntu is going with Qt, so I don't expect them to do much
development on keeping logind separate from systemd.

It seems a bit weird that although work is done to ensure systemd is
optional, in the end just a systemd dependency is taken (Debian,
Gentoo).

  ---> Not trying to start this up again. <---


-- 
Regards,
Olav

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos]

El mié, 11-09-2013 a las 11:41 +0200, Olav Vitters escribió:
[...]
> >  * We maintain networkmanager and bluetooth support optional, and this
> > has been the case since 3.2 iirc even though upstream flat out refuses
> > to merge our perfectly fine patches
> 
> Feel free to cc release-team@gnome.org on such patches. I am not saying
> something would change, however, Bluetooth is optional in gnome-shell
> (though in 3.9.x it crashed if you disabled it). Seems a bit strange to
> have it optional in one place, forced in another.
> 

Upstream (I think most Bastien) strongly refuses to include that
patches, should we send you via mail to release team? (I can try to find
the bugs again and CC you there, but you will only see those closed as
WONTFIX because we aren't supposed to disable that support (colord,
networkmanager, kerberos...)

[...]
> Intention was not to force systemd. It just seems to have ended up that
> way. The various times I asked there has been a lot of work going on
> into supporting non-systemd configurations as changes are made. However,
> that work is mostly untested and likely buggy (things needs to be used).
> I thought the work was good enough (though knew that Debian would go
> with requiring systemd as a dependency)

It's "de facto" forced, otherwise, gdm cannot be stopped properly (until
cgroups support is not implemented in other RCs alternatives), power
management support is lost...

> 
> It seems that for Wayland support we somehow do need to require logind
> (I forgot why exactly, though I do have IRC logs somewhere). At the
> moment that seems unlikely to change. I'm planning to write a proper
> message about this to distributor-list.

Then, it will also need systemd to be running as systemd >= 205 cannot
have logind working alone. 

> Most of the development was done within ConsoleKit, now mostly done
> within systemd. It would be nice if the logind part was optional like it
> was initially, but I don't know if that would still be a no-go for
> Gentoo. E.g. does it have to be ConsoleKit, or is a logind also ok? Note
> that Ubuntu is going with Qt, so I don't expect them to do much
> development on keeping logind separate from systemd.

Ubuntu people made a huge effort to let logind work with Upstart
running, but that will only work for <=204 version.