Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
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
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. 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
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
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. 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
[gentoo-dev] Re: Response to a friendly note about changing bug reports
On 8/08/2013 07:52, Gilles Dartiguelongue wrote: Guys, please, if you want to bikeshed about bug summary, please do it in a constructive way and get the automated bug assignment project going. I think at least one bug wrangler already uses a local script to do something similar to that. Any idea what is blocking it being implemented in Bugzilla? Infra being understaffed?
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On Wed, 7 Aug 2013, Robin H Johnson wrote: You also asked about PMS, and I'm wondering if PMS specifies the Manifest contents at all, and/or if it needs updates for MetaManifest. PMS doesn't specify the Manifest format, but refers to GLEP 44, so probably this reference should be updated. Also, Manifest files are only mentioned in connection with package directories. Ulrich
KDE/semantic-desktop, was: Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
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) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Removing support for Python 2.5, 3.1 and PyPy 1.9
Dnia 2013-08-08, o godz. 00:26:26 Robin H. Johnson robb...@gentoo.org napisał(a): On Thu, Aug 08, 2013 at 01:56:58AM +0200, Michał Górny wrote: Hello, fellow developers. On behalf of Python team, I would like to announce that we're officially discontinuing support for Python 2.5, Python 3.1 and PyPy 1.9. Could you please update: http://www.gentoo.org/proj/en/Python/python-r1/policy-guide.xml I think 3.0 should be added back to there, with a new group for unsupported implementations that have been fully cleaned from the tree. Updated. I've added them as 'removed'. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
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
[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
Duncan posted on Thu, 08 Aug 2013 08:27:58 + 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
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] Re: Response to a friendly note about changing bug reports
On Thu, 08 Aug 2013 16:30:50 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 8/08/2013 07:52, Gilles Dartiguelongue wrote: Guys, please, if you want to bikeshed about bug summary, please do it in a constructive way and get the automated bug assignment project going. I think at least one bug wrangler already uses a local script to do something similar to that. Yes, I do, it's a matter of copying the package atom, if it were consistent this could even be put on clipboard with the hit of a button. But ideally, a hit on the button should just fill in the form. Then the package atom has to be provided to a bash alias which obtains the matadata.xml from sources.gentoo.org to ensure it is up to date as well as displays eix output for versions. As a result it puts the e-mail addresses on the clipboard which I then can paste into a special text box on the form. It speeds up assignment a lot compared to doing it more manually. Besides that I've also ported the duplicates to the bug page; I wouldn't invite everyone to use that to spare some extra requests infra wise, the aim for this script is solely for it to be used for bug wrangling. I agree these things being implemented in Bugzilla itself, using an atom field, we no longer even need the bash alias; would be a much more appropriate solution for wide spread usage. https://gist.github.com/TomWij/1772ee0f685749324977 http://i.imgur.com/uNHNXZM.png?1 The text the bash alias puts on clipboard can be inserted in the text box at the top of the page; as it detects the keyboard sequence, it will empty the text box and fill in the assignee and CC fields of the form. The duplicates show up once you edit the summary or press a key in it. Those inside upstream tags I correct depending on the description /; they often want to be CC-ed on the bug, if there is no description / then I remove them from the CC field. What misses from metadata for scripts is a XML attribute stating to CC. Currently this uses lame non-XML compliant grep-and-sed magic; it would be much more neat to parse the actual XML here, but I have no idea how to do that from Bash. Maybe I'll rewrite that bit in a Python script... Further suggestions, complaints, ... are welcome; if they are not relevant to this thread, please drop gentoo-dev@l.g.o from To. :) Any idea what is blocking it being implemented in Bugzilla? Infra being understaffed? As far as I am aware there is only one person working on that; as you can see on http://www.gentoo.org/proj/en/infrastructure/, this is idl0r. From as far as I see he doesn't seem active on this field lately except for the bigger Bugzilla updates; so, from my point of view it looks understaffed and I am wondering if they are looking for more people to help them with implementation, patches and bugs. I'm pretty sure there are people (like you and me) willing to help a hand; but, I'm not sure if infra or idl0r is looking for more people currently. Not sure about the rest of the infra team; but from earlier talk, I have the impression that they either don't have time or don't want to touch the Bugzilla code. That's also what the git logs indicate. Granted, there's a lot more work infra does than just Bugzilla. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 7 August 2013 20:45, Michael Weber x...@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] Re: Gnome Stabilization 3.6 or 3.8
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
On Thu, 08 Aug 2013 11:29:06 +0200 hasufell hasuf...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, 8 Aug 2013 17:39:25 +0800 Ben de Groot yng...@gentoo.org wrote: On 7 August 2013 20:45, Michael Weber x...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
Dnia 2013-08-08, o godz. 11:29:06 hasufell hasuf...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 08/08/13 13:05, Michał Górny wrote: Dnia 2013-08-08, o godz. 11:29:06 hasufell hasuf...@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
On 08/08/13 12:39, Ben de Groot wrote: On 7 August 2013 20:45, Michael Weber x...@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] renaming gentoo-oldnet
Am Mittwoch, 7. August 2013, 12:00:57 schrieb William Hubbs: On Tue, Aug 06, 2013 at 11:26:16AM -0500, William Hubbs wrote: On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote: I'm replying the start of this thread, rather than picking a single person to respond to. I DO want more brainstorming on ideas for the naming of the package, and I think people need to cast a wider net for naming ideas. Robin, I would like the decision to be made soon. I need to release OpenRc-0.12 in the next day or so, and if I do not have the answer I will have to do the split in OpenRc-0.13. I thought of a name based on your last suggestion and a comment on the list. Instead of networkrc, maybe netifrc (network interface rc). So, my choices, in no particular order, would be, netifrc, networkrc or, if neither of those fly, keep gentoo-oldnet. All, Robin hasn't responded, so my choice for this is netifrc (network interface rc). Someone made a comment about rc implying old school, RC means run control. I'm not sure an implication of old school is a big concern. Ich think it was me who was telling that. What I meant was that old school configuration file names are often called somethingrc which may imply that netifrc might be a configiration file for a tool called netif. -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 5:43 AM, Tom Wijsman tom...@gentoo.org wrote: On Thu, 08 Aug 2013 11:29:06 +0200 hasufell hasuf...@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
On Thu, Aug 8, 2013 at 5:45 AM, hasufell hasuf...@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
On Thu, 8 Aug 2013 07:19:39 -0400 Rich Freeman ri...@gentoo.org wrote: On Thu, Aug 8, 2013 at 5:43 AM, Tom Wijsman tom...@gentoo.org wrote: On Thu, 08 Aug 2013 11:29:06 +0200 hasufell hasuf...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 1:49 AM, Patrick Lauer patr...@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
On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani lx...@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
On 08/08/2013 10:01 PM, Fabio Erculiani wrote: On Thu, Aug 8, 2013 at 1:49 AM, Patrick Lauer patr...@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 copypaste, 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
On Thu, Aug 8, 2013 at 4:10 PM, Alon Bar-Lev alo...@gentoo.org wrote: On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani lx...@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
On Thu, Aug 8, 2013 at 9:17 AM, Patrick Lauer patr...@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
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
Dnia 2013-08-08, o godz. 17:10:24 Alon Bar-Lev alo...@gentoo.org napisał(a): On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani lx...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
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
Andreas K. Huettel dilfri...@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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
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
On Thu, Aug 8, 2013 at 10:56 AM, hasufell hasuf...@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
On Thu, 08 Aug 2013 16:56:16 +0200 hasufell hasuf...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 08 Aug 2013 11:40:58 -0400 Ian Stakenvicius a...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.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
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
On Thu, Aug 8, 2013 at 11:40 AM, Ian Stakenvicius a...@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
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
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 signature.asc Description: Digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
El jue, 08-08-2013 a las 12:02 -0400, Rich Freeman escribió: On Thu, Aug 8, 2013 at 11:40 AM, Ian Stakenvicius a...@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
-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 a...@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
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
On 08/08/2013 05:23 PM, Tom Wijsman wrote: On Thu, 08 Aug 2013 16:56:16 +0200 hasufell hasuf...@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
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
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
On Thu, 08 Aug 2013 18:36:24 +0200 hasufell hasuf...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-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
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
On Thu, Aug 8, 2013 at 12:53 PM, Tom Wijsman tom...@gentoo.org wrote: On Thu, 08 Aug 2013 18:36:24 +0200 hasufell hasuf...@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
Sorry for reposting: Somehow the first line got lost making the whole posting not understandable... Andreas K. Huettel dilfri...@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
On Thu, Aug 8, 2013 at 1:44 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Sorry for reposting: Somehow the first line got lost making the whole posting not understandable... Andreas K. Huettel dilfri...@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
On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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
On Thu, Aug 8, 2013 at 12:52 PM, hasufell hasuf...@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
On 08/08/13 20:57, Alon Bar-Lev wrote: On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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] Re: KDE/semantic-desktop
-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 va...@mathematik.uni-wuerzburg.de wrote: Sorry for reposting: Somehow the first line got lost making the whole posting not understandable... Andreas K. Huettel dilfri...@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/ iKYEARECAGYFAlID4FpfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TlrQCfXM1Pmi1lwwBCsSEfwyC3E5MJ zQUAn2OZ8pvujwUnu+bLtCZ0e4lacuui =tus9 -END PGP SIGNATURE-
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, 8 Aug 2013 13:41:02 -0400 Rich Freeman ri...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 08/08/13 20:57, Alon Bar-Lev wrote: On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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
On Thu, 8 Aug 2013 20:57:15 +0300 Alon Bar-Lev alo...@gentoo.org wrote: On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:26 PM, Tom Wijsman tom...@gentoo.org wrote: On Thu, 8 Aug 2013 20:57:15 +0300 Alon Bar-Lev alo...@gentoo.org wrote: On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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 : tom...@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)
On Thu, 8 Aug 2013, 20:57:18 +0300 Alon Bar-Lev alo...@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 alo...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)
On Thu, Aug 8, 2013 at 9:47 PM, Tom Wijsman tom...@gentoo.org wrote: On Thu, 8 Aug 2013, 20:57:18 +0300 Alon Bar-Lev alo...@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 alo...@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
On 08/08/13 21:23, Alon Bar-Lev wrote: On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 08/08/13 20:57, Alon Bar-Lev wrote: On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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
On Thu, Aug 8, 2013 at 9:58 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 08/08/13 21:23, Alon Bar-Lev wrote: On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 08/08/13 20:57, Alon Bar-Lev wrote: On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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
On Thu, Aug 8, 2013 at 2:26 PM, Tom Wijsman tom...@gentoo.org wrote: On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@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
On Thu, 8 Aug 2013 21:38:55 +0300 Alon Bar-Lev alo...@gentoo.org wrote: On Thu, Aug 8, 2013 at 9:26 PM, Tom Wijsman tom...@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 alo...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)
On Thu, Aug 8, 2013 at 2:57 PM, Alon Bar-Lev alo...@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)
On Thu, 8 Aug 2013 21:57:37 +0300 Alon Bar-Lev alo...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, 8 Aug 2013 15:02:55 -0400 Rich Freeman ri...@gentoo.org wrote: On Thu, Aug 8, 2013 at 2:26 PM, Tom Wijsman tom...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-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
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] Vanilla sources stabilization policy change
On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote: On Wed, 7 Aug 2013 16:19:43 -0700 Greg KH gre...@gentoo.org wrote: On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote: Greg KH wrote: See above for why it is not easy at all, and, why even if we do know some fixes are security ones, we would not tag them as such anyway. I think this supports the argument that the better kernel is always the one with the most fixes. Define better; because 3.10.0 has also been worse than the last 3.9 release in some ways, despite it having more fixes than the last 3.9. How was it worse? You don't seem to define that either :) Yes, there are always going to be bugs and regressions, but as long as we are fixing them more than we are making them, we are doing ok. greg k-h
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote: On Wed, 7 Aug 2013 15:44:34 -0700 Greg KH gre...@gentoo.org wrote: On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote: Some kind of annotation with tags would make this kind of thing easy; I'm not saying it is your task to apply such annotations to commits, but it would rather be the task of the person who makes an individual patch. I am not going to impose an additional burden on developers to get their patches into the stable kernel releases like this, sorry. As I said, it's not your task; so, what you impose doesn't matter. What do you mean by that? I am the upstream stable kernel maintainer, as well as a subsystem maintainer. I don't want to do the extra work of tagging all of my stable patches with this type of information, I can barely keep on top of the ones that I have to mark for stable as it is. As the stable kernel maintainer, all I ask for is that subsystem maintainers tag their patches for the stable tree. If I have questions about them, I ask, otherwise I accept them. Can you judge which bug fixes are security ones, and which are not? And do so for 100+ patches a week? 52 weeks a year? Great, please do so, as no one has ever been able to do this (others have tried.) Yes, that is easy on the premise that they are annotated. But I will argue that you can not annotate them properly. That is imposing more work on me, a subsystem maintainer, that I will not do. Hint, the line between a bugfix and a security fix is not always obvious, or even known at all. The developer knows; and if not, he can probably just mark it as a fix. Ok, so you have just now divided everything into fix or feature. As the feature patches are quite obvious, everything else must be fix. So why tag anything, your classification is already done for you. And what about all of the fixes I merge in, that _are_ really security fixes, yet we do not want to shout it out to the world at the moment? For known security bugs, being aware of a fix earlier helps. I don't understand what you mean here at all. greg k-h
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
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] Vanilla sources stabilization policy change
Greg KH wrote: See above for why it is not easy at all, and, why even if we do know some fixes are security ones, we would not tag them as such anyway. I think this supports the argument that the better kernel is always the one with the most fixes. That's what us kernel developers have been saying for 10+ years, nice to see it's finally getting some traction :) It has been obvious for me for a very long time as well, but I am just one person, and my idea doesn't seem to have much traction in Gentoo. :\ Rather than separating bug fixes from security fixes maybe it's wiser to think about separating fixes from features - this may be easier, but still not neccessarily easy. For stable kernel releases, that type of thing should be quite easy for someone to do, if they want to do it, as the only type of features I take for them are new device ids. But I fail to see how marking 5 patches out of 100 as features is really doing to do much for anyone, do you? For stable kernel releases there would be no need. I think they should be stabilized automatically in Gentoo. It's simply a more accurate model of upstream. //Peter
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-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
[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 :) )
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
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 x...@gentoo.org
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
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
-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-
[gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?
On 08/08/2013 12:11 PM, Tom Wijsman wrote: On Thu, 8 Aug 2013 21:57:37 +0300 Alon Bar-Lev alo...@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?
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 alo...@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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 8:27 PM, Patrick Lauer patr...@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
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?
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 alo...@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
