[gentoo-dev] Re: CPU use flag detection
On Sat, 18 May 2013 12:14:35 -0700 Matt Turner wrote: > > MMX2/MMXEXT still confuses me. > > SSE1 and /Enhanced/ 3DNow! added some extra MMX instructions. Some > (pshufw and pmulhuw particularly) turn out to be rather useful in > software compositing. I use them in the pixman MMX code. > > See http://mattst88.com/programming/asmref/ (Sorry about the broken > search box. It works, you just don't see what you type) Oh I am going to get a lot of use out of this. > Set Requires = Enhanced 3DNow!. The instructions that are listed as > 'Enhanced 3DNow! or SSE1' are what are known as MMX2 or MMXEXT. > > The particularly annoying thing about using them is that there's no > -mmmx2 or -mmmxext, but turning on -msse causes illegal instructions > to be generated for old AMD or Geode CPUs, while -m3dnow causes the > same problems for Intel CPUs. And, there's not actually even an > -m3dnowext flag (anymore?) anyway, so it's kind of a mess. Ah, that explains why I always thought they were Enh 3DNow options. Looks like I have them spread out between MMX and Enh 3DNow in analyze-x86. Oops. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/21/2013 07:43 PM, Thomas Sachau wrote: > Rick "Zero_Chaos" Farina schrieb: >> On 05/21/2013 09:20 AM, Markos Chandras wrote: >>> On 21 May 2013 13:21, Thomas Sachau wrote: "Paweł Hajdan, Jr." schrieb: > Remember this is supposed to _help_ Gentoo. You can opt out of the bugs > (there is a package name and maintainer name regex in the script). You > don't need to "hunt them down" - if you do nothing another script will > just CC arches after 30 days. > > Paweł > Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer >> >>> If you don't read your bugmail in 30 days then that is a different >>> problem. I like the way Paweł handles this at the moment. 30 days is >>> enough time for active maintainers to object. We just can't afford >>> waiting months for inactive maintainers to act. > > Who said, that bugmail is ignored? Repeating myself, it may be > accidently deleted by the dev or some software (hint: spam filters), it > may actually even be ignored to re-use the bug later. Since i dont > remember even seing a hint for the "will stable in 30 days without > objection", the arch addition is even more a bad surprise for a maintainer. With respect, if a dev is having their bugzie mail deleted by a spam filter they need to get that fixed, and I should hope accidental deletion is a rare enough event as to not play a significant role here. I do, however, completely agree that there should be some way to leave the bug open and state that it will be stabled later. Would a comment trigger this in the script? That seems semi-sane. If the maintainer wanted to stabilize things they would cc arches, any other comment could likely be understood to mean "don't auto-stable this". > >> >> I have to agree very strongly with this sentiment. If I'm ignoring my >> bugmail for 30 days and there are no (new) active bugs against the >> package it should be stabilized. The only time this shouldn't happen is >> if there is a bug in the new version which isn't present in the old version. > > See above > >> >> We all need to learn to either be more responsive or stop complaining >> when other people fix our stuff. If you don't respond to your bugmail >> in 30 days then "active" maintainer is a bit of a stretch unless you >> have devaway setup. > > So with a devaway setup pointing to another dev, which wont get CCed nor > asked, so cannot deny it, the package would become stable too, even when > it should not. ;-) > Specifically I meant we should exempt packages with a maintainer on devaway from the auto-stabilization. Please understand I don't mean to suggest that this process is perfect, but it is valuable and it seems people are willing to improve it where possible so I for one would love the help getting more things stabilized. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRnD+AAAoJEKXdFCfdEflKpYAP/Am/3l/94jNFmWld8mn7QPes IYN+GMYOxBw1s/ZXCrPHybloq8a3os49Y50710xxqsKLjK/JnlGpYohl3IQxZdlL +9aS2r/HubRc50dDbXNjXByzMRjVYY0ej/c7lLEk3G3AfxD35AD3gxXerxXZ5j4I jRyiQ3Ee74ramZbam+iSAs4dg91uM1aMPgpNU0UySa8Lj9JquJ4JZeLGX/gKgA6n NcBnTN+8fWr8ketsPSnfrHlnECeYhLDw3dMNB4d5L8p8vzk8ronHIG23/dxNZvst 93LTUGPPJBirTBcxS0SEDWp6kOyhHeO7jyCYEOIvFn8RO/5gu7bsmaL734HRZx41 xl89Tvbw9aA2EAZKFhoyc6vv4/L+Put82A3GiPFYh896L3iZmP7xIFYfeUSR7aTo rKpIshaRNS0TJIyGgI0eWSLeR1bvi3WF0heAHfMYOzbdx54Is3GpIbhAjww3xbDq oRppTnCZAD/Y3WmdgaUosKIBzRBOFuZOGlAbD/2HvQB5KPvp8cgSlFhs8G7zx7RW II9frccgLSY5A7SAwhSRIhU8/3uAVpHHq6dfvWtuVZbEY6SP3sD1xblwituqFcqz WPLXo0uYF1GlkZHqIK/ZhmeJMXggstnQP0q2H1PNzEm2SlYcToHVizaeZAs6i4hd q1OrR+URh7KqM5GCzYaA =vISF -END PGP SIGNATURE-
[gentoo-dev] Re: Making systemd more accessible to "normal" users
Tom Wijsman posted on Wed, 22 May 2013 00:52:15 +0200 as excerpted: > In the Portage tree we could avoid users from having to mask files, > because that could break their system anyway; eg. Go mask some typical > files [1], you'll end up breaking package compilations in the long run > as they need these files installed on your system. And a knife or hammer can be used to murder or commit suicide as well; that doesn't mean they're bad tools, it means the user is misusing them. > In Portage the /etc/package.* files are a good example, more advanced > include / exclude file masking in the same way would certainly be a > benefit and some kind of base / profile forced install unmask too. Not a bad idea. There's more advanced knives and hammers too, but you don't have to procure the most expensive one to do the job. In some cases, even a heavy screwdriver can be used as a hammer, if that's what you have in your hand and the hammer's down the ladder in the toolbox. > In other Package managers, I assume this madness isn't supported. That might be part of why I don't use other PMs... > In its current state, it certainly has its use cases; though it is often > misused by unaware users that don't know what removal of certain files > has as a consequence, that means it can do more bad than good... > > [1]: http://forums.gentoo.org/viewtopic-t-670094.html > First INSTALL_MASK I came across searching for it online, > particularly masking *.h, *.pc and Makefile* are very bad ideas. Did you read the use case? He is (was, that was 2008) doing the builds for his 2GB drive netbook on different build system, then doing binpkg installs on the netbook. In that case, INSTALL_MASKING those filetypes for installation to the netbook, where he has no intention of doing any building anyway, makes quite a lot of sense. In fact, I have a netbook (tho it has a much larger 100+ gig drive) and could use the idea myself (altho currently I don't run a PM at all on the netbook, instead rsyncing from the build image on the main machine, so I'd have to modify his use case... or mine... somewhat). As for people misusing the available tools, gentoo has always taken the position that we make the tools available and document how to use them, but we aren't a babysitting or handholding distro, and if handholding is what people want/need, they better look elsewhere as gentoo's simply not in that market, and doesn't pretend to be. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: robo-stable bugs
On Sun, 19 May 2013 15:40:27 +0200 Jeroen Roovers wrote: > > OS: Linux > > Status: CONFIRMED > > Severity: enhancement > > Is a stabilisation an enhancement per se? If all stabilisations are > enhancements, then why isn't Severity set to Normal instead? (What is > an enhanced severity to begin with, Mozilla?) Huh? The severity of the bug is it's an enhancement. Yes stabilizations are enhancements. Always have been. > Also, your script does not set the STABLEREQ keyword. People are having > to hunt down your robo-stabilisation requests and add it themselves. > You should just do it yourself or turn your script off. Did you read the message? The point is you're supposed to add that yourself. It's not a STABLEREQ until you add arches. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 16:17:30 -0400 Alexis Ballier wrote: > On Tue, 21 May 2013 20:51:52 +0100 > Markos Chandras wrote: > > I'd rather not see this process changes, because it has helped > > bringing the stable tree up2date. However, given that *a few* people > > don't like it, I suggest you don't file bugs for packages owned by > > them. > > +1 > > I am (was) unhappy with some corner cases that used to happen (like > bug #428968 ) but overall I consider it very useful; I'm even > becoming more lazy and do not look for stable candidates because I know > some day I'll have an automated request :P Yes my laziness won out against any objections too. :) -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] robo-stable bugs
Am Mittwoch, 22. Mai 2013, 01:43:15 schrieb Thomas Sachau: > > Who said, that bugmail is ignored? Repeating myself, it may be > accidently deleted by the dev or some software (hint: spam filters), it > may actually even be ignored to re-use the bug later. Since i dont > remember even seing a hint for the "will stable in 30 days without > objection", the arch addition is even more a bad surprise for a maintainer. > Yep. Sounds like this is another case of "maintainer does not read -dev ml, pops up half a year after policies become active, and starts complaining". Come on, I also have a hard time with this list. However, I'm at least skimming the thread titles. (And for stuff like "OMG systemd killed my kittens" my mail client has a nice "ignore thread" feature.) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
Rick "Zero_Chaos" Farina schrieb: > On 05/21/2013 09:20 AM, Markos Chandras wrote: >> On 21 May 2013 13:21, Thomas Sachau wrote: >>> "Paweł Hajdan, Jr." schrieb: Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to "hunt them down" - if you do nothing another script will just CC arches after 30 days. Paweł >>> >>> Uhm, automagic stabilization without maintainer ok? This sounds like a >>> bad idea. >>> >>> Doing a batch CC-ing after maintainer gave his ok or anything similar, >>> which starts, when someone actually aproved the stable going is all ok, >>> but doing this automaticly may get packages become stable, which are not >>> intended to become so and should have never been there. >>> >>> -- >>> >>> Thomas Sachau >>> Gentoo Linux Developer >>> > >> If you don't read your bugmail in 30 days then that is a different >> problem. I like the way Paweł handles this at the moment. 30 days is >> enough time for active maintainers to object. We just can't afford >> waiting months for inactive maintainers to act. Who said, that bugmail is ignored? Repeating myself, it may be accidently deleted by the dev or some software (hint: spam filters), it may actually even be ignored to re-use the bug later. Since i dont remember even seing a hint for the "will stable in 30 days without objection", the arch addition is even more a bad surprise for a maintainer. > > I have to agree very strongly with this sentiment. If I'm ignoring my > bugmail for 30 days and there are no (new) active bugs against the > package it should be stabilized. The only time this shouldn't happen is > if there is a bug in the new version which isn't present in the old version. See above > > We all need to learn to either be more responsive or stop complaining > when other people fix our stuff. If you don't respond to your bugmail > in 30 days then "active" maintainer is a bit of a stretch unless you > have devaway setup. So with a devaway setup pointing to another dev, which wont get CCed nor asked, so cannot deny it, the package would become stable too, even when it should not. ;-) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
"Paweł Hajdan, Jr." schrieb: > On 5/21/13 6:38 AM, Thomas Sachau wrote: >> And if a maintainer is not responding within 30 days, you can ping him >> or, without a response, try to get a different maintainer. Just assuming >> that a stable request is ok without a maintainer response is really not >> a good idea. > > Thomas, this effort is going on for over a year now (and has been > discussed on gentoo-dev). If it's only now you've noticed, maybe the sky > isn't falling after all. I dont remember any auto-stabilization being accepted, but maybe this happened in number 30 or 50 of some thread, where i already got bored and did not follow it any more. And how should i notice your script, when it never applies to my packages? ;-) > Note that there is a tradeoff here: I really started the stabilizations > after I've noticed how many bugs are fixed in ~arch that still affect > stable, but the fixing version didn't get stabilized. This is the > downside of an opt-in approach, since inactive maintainers are not going > to opt-in. > > Finally, everyone from metadata.xml is CC-ed. There is no "trying a > different maintainer" - all of them are there since day one. "trying a different maintainer" did mean re-assigning the package, when a maintainer is gone/inactive > > Please let me know if you still have concerns - ideally back them with > data and actual cases showing problems (or scenarios that can reasonably > be likely) instead of just saying it _might_ lead to breakages. Anything > _might_ lead to breakages, including taking no action here and allowing > bugs to be not fixed for stable. :) Give me the needed amount of time to create such data, dont miss the motivation for such project and i may do it. ;-) Some show cases: When a maintainer wants to stable at a later point in time or another version and keeps the bug open to re-use it, he would suddenly get your suggested version stable, also he did explicitly not give his go and did not add arches. And if a maintainer does not respond for a certain amount of time, i would not take it as a sign for a package to be stable, but instead of a sign, that the package will need a new maintainer, who can then check for the best fit for a stable candidate. After all, the latest version may be the upstream development branch, while latest stable already follows upstream stable branch. So creating stable bugs with your above requirements looks ok, the point i have a problem with is still the opt-out setting. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Tue, 21 May 2013 21:37:25 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > [snip] FIRE! [snip] "hacks" of tools, thank you very much! =:^) Glad you like it! Something that breaks isn't a solution though... > It's a specifically designed part of the whole gentoo support of > choice system you mention. I wouldn't call something that's added to our red herring (make.conf) as an afterthought "designed", but rather a lack of better approaches. In the Portage tree we could avoid users from having to mask files, because that could break their system anyway; eg. Go mask some typical files [1], you'll end up breaking package compilations in the long run as they need these files installed on your system. In Portage the /etc/package.* files are a good example, more advanced include / exclude file masking in the same way would certainly be a benefit and some kind of base / profile forced install unmask too. In other Package managers, I assume this madness isn't supported. In its current state, it certainly has its use cases; though it is often misused by unaware users that don't know what removal of certain files has as a consequence, that means it can do more bad than good... [1]: http://forums.gentoo.org/viewtopic-t-670094.html First INSTALL_MASK I came across searching for it online, particularly masking *.h, *.pc and Makefile* are very bad ideas. -- 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] robo-stable bugs
On Tue, 21 May 2013 13:46:18 -0700 ""Paweł Hajdan, Jr."" wrote: > On 5/21/13 1:17 PM, Alexis Ballier wrote: > > On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras > > wrote: > >> I'd rather not see this process changes, because it has helped > >> bringing the stable tree up2date. However, given that *a few* > >> people don't like it, I suggest you don't file bugs for packages > >> owned by them. > > > > +1 > > > > I am (was) unhappy with some corner cases that used to happen (like > > bug #428968 ) but overall I consider it very useful; > > Thanks, Alexis. > > One note about that bug: with lots of bugs being filed, it's not > really feasible for me to track comments like that one. I know its not really feasible; in this case the annoying part is, besides the noise, the automated ccing of arches if there is no answer when there actually was one on the first request. Anyway, you seem to have fixed it because its been a while since I have not seen it (maybe by ignoring packages that have a wontfix automated stablereq bug?). Alexis.
[gentoo-dev] Re: Making systemd more accessible to "normal" users
Ciaran McCreesh posted on Tue, 21 May 2013 14:50:04 +0100 as excerpted: > On Tue, 21 May 2013 04:45:12 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> But the point you're missing is that INSTALL_MASK is NOT a hack. > > Sure it is. It's a hack and remains a hack until there's a way of using > it without risk of breakage. LOL. Better turn off that computer then. By your definition it's a hack. Or at least remove anything gentoo related from it. That's a hack too. Oh, and that stove and microwave, better throw them away too, because leave something cooking too long and... FIRE! So they're hacks too. You can go back to your tool-less pre-caveman existence if you like. I'll keep my "hacks" of tools, thank you very much! =:^) -- 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] robo-stable bugs
Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: > > And if a maintainer is not responding within 30 days, you can ping him > or, without a response, try to get a different maintainer. Just assuming > that a stable request is ok without a maintainer response is really not > a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
Pawel, > > Note that there are several things my script will ignore: > > 1. Packages with any bugs open. > 2. Packages which have at least one ~arch dependency. > how about putting up a webpage documenting your script policies? Just to shorten discussions like this one... The page need not be elaborate, but you could link to it in the bugreports. Something like This bug has been filed automatically, see http://... (and to everyone else, please don't complain about the extra text line in your bugmails now!) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/21/2013 09:20 AM, Markos Chandras wrote: > On 21 May 2013 13:21, Thomas Sachau wrote: >> "Paweł Hajdan, Jr." schrieb: >>> Remember this is supposed to _help_ Gentoo. You can opt out of the bugs >>> (there is a package name and maintainer name regex in the script). You >>> don't need to "hunt them down" - if you do nothing another script will >>> just CC arches after 30 days. >>> >>> Paweł >>> >> >> Uhm, automagic stabilization without maintainer ok? This sounds like a >> bad idea. >> >> Doing a batch CC-ing after maintainer gave his ok or anything similar, >> which starts, when someone actually aproved the stable going is all ok, >> but doing this automaticly may get packages become stable, which are not >> intended to become so and should have never been there. >> >> -- >> >> Thomas Sachau >> Gentoo Linux Developer >> > > If you don't read your bugmail in 30 days then that is a different > problem. I like the way Paweł handles this at the moment. 30 days is > enough time for active maintainers to object. We just can't afford > waiting months for inactive maintainers to act. > I have to agree very strongly with this sentiment. If I'm ignoring my bugmail for 30 days and there are no (new) active bugs against the package it should be stabilized. The only time this shouldn't happen is if there is a bug in the new version which isn't present in the old version. We all need to learn to either be more responsive or stop complaining when other people fix our stuff. If you don't respond to your bugmail in 30 days then "active" maintainer is a bit of a stretch unless you have devaway setup. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRm+WEAAoJEKXdFCfdEflKNr4QAJoknm4/y8kCAjvYRbz8MfVF Ncgis7d6gzDW0yjypHvj8WO40xzok6WSYR6PsdZ+ZZYbviGjPmuTAvnu4eq0XNKN /CVc2cxsPrvgH+vD7dU8zaIkYI/0lrMhB3ZF6jmAyNx5NI0VFcsd+ktL/o7oh3Mz 4Um5Di25GXhoHFxmxRS03geS/k01CHHpJhP13zH8cEyzEAwqIlqPMIu+SAGPtSnm LE7R0/sXYECM3TDaw1hF2TU3maBUv9ZJoSNRmwUYznL1Tm8M2Ns7q+L+OBGwBicB 1RZN+FabyEZenW34bhZfA1l49g8cA4l9QZPL+Zi5QudLoCuyjXCGPuyr0bL04hIy WTI4K4gZed1eKhtjOtt12tcc6LLsnCMmueTcGVDu0n1u8dV6BgX4YGjpdmyvREAP 3R7uaFAxx7c7t+uKzDodC4lCFKeE6rn6MPWQ0lVpNM05cxusi0X84iU6W0OmCKNE ef3GtsWbW2RevwoOE8MuY3fC87RtCi6z8sb35+IuXxsNzIBdrSFdRAf5Xh9AoEQ/ pbJTQxqxCx0oiX0JAJfE51bYSWN2Q9HY/U7Es/lcT8DimKXX569jgcrSx4OoFJgR erpB7tTn9WWr2B3wYL1FXLDOlcvJy6VzSEhssHO/51TeUQ20ZKl33GTuOuFRmVr4 jUMivXf1nrKnwB7ZQA6b =qesr -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
On 5/21/13 1:17 PM, Alexis Ballier wrote: > On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras > wrote: >> I'd rather not see this process changes, because it has helped >> bringing the stable tree up2date. However, given that *a few* >> people don't like it, I suggest you don't file bugs for packages >> owned by them. > > +1 > > I am (was) unhappy with some corner cases that used to happen (like > bug #428968 ) but overall I consider it very useful; Thanks, Alexis. One note about that bug: with lots of bugs being filed, it's not really feasible for me to track comments like that one. If there was a bug on file about dev-ml/camlp5 breaking coq, my script wouldn't consider dev-ml/camlp5 for stabilization - I think this is the right thing for you to do in such cases, much better than "implicit" bugs that are not in the bug tracker. :) > I'm even becoming more lazy and do not look for stable candidates > because I know some day I'll have an automated request :P Note that there are several things my script will ignore: 1. Packages with any bugs open. 2. Packages which have at least one ~arch dependency. I still recommend doing some pass over packages you maintain to look for any stable candidates. Hopefully thanks to the script you should need to do that less often. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras wrote: > I'd rather not see this process changes, because it has helped > bringing the stable tree up2date. However, given that *a few* people > don't like it, I suggest you don't file bugs for packages owned by > them. +1 I am (was) unhappy with some corner cases that used to happen (like bug #428968 ) but overall I consider it very useful; I'm even becoming more lazy and do not look for stable candidates because I know some day I'll have an automated request :P Alexis.
Re: [gentoo-dev] robo-stable bugs
On 21 May 2013 19:32, "Paweł Hajdan, Jr." wrote: > On 5/21/13 6:38 AM, Thomas Sachau wrote: >> And if a maintainer is not responding within 30 days, you can ping him >> or, without a response, try to get a different maintainer. Just assuming >> that a stable request is ok without a maintainer response is really not >> a good idea. > > Thomas, this effort is going on for over a year now (and has been > discussed on gentoo-dev). If it's only now you've noticed, maybe the sky > isn't falling after all. > > Note the criteria for the bugs to be filed: > > 1. No open bugs for the package. > 2. No bugs (including closed) for that particular version of the package > (so for example closing the stabilization bug will prevent it from being > opened again; it also takes into account bugs closed with e.g. NEEDINFO, > which can be real issues). > 3. At least 30 days in tree. > 4. No repoman errors when trying to stabilize it (so all deps already > stable). > > Also, arch teams are responsible for at least shallow (compile) testing > of the package, and ideally smoke testing on run and possibly testing > with various USE flag combinations and reverse dependencies testing (the > latter is a regular part of my stabilization workflow, and the script > for that is part of the same suite that files bugs). > > Note that there is a tradeoff here: I really started the stabilizations > after I've noticed how many bugs are fixed in ~arch that still affect > stable, but the fixing version didn't get stabilized. This is the > downside of an opt-in approach, since inactive maintainers are not going > to opt-in. > > Finally, everyone from metadata.xml is CC-ed. There is no "trying a > different maintainer" - all of them are there since day one. > > Please let me know if you still have concerns - ideally back them with > data and actual cases showing problems (or scenarios that can reasonably > be likely) instead of just saying it _might_ lead to breakages. Anything > _might_ lead to breakages, including taking no action here and allowing > bugs to be not fixed for stable. :) > > Paweł > > I'd rather not see this process changes, because it has helped bringing the stable tree up2date. However, given that *a few* people don't like it, I suggest you don't file bugs for packages owned by them. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] robo-stable bugs
On 5/21/13 6:38 AM, Thomas Sachau wrote: > And if a maintainer is not responding within 30 days, you can ping him > or, without a response, try to get a different maintainer. Just assuming > that a stable request is ok without a maintainer response is really not > a good idea. Thomas, this effort is going on for over a year now (and has been discussed on gentoo-dev). If it's only now you've noticed, maybe the sky isn't falling after all. Note the criteria for the bugs to be filed: 1. No open bugs for the package. 2. No bugs (including closed) for that particular version of the package (so for example closing the stabilization bug will prevent it from being opened again; it also takes into account bugs closed with e.g. NEEDINFO, which can be real issues). 3. At least 30 days in tree. 4. No repoman errors when trying to stabilize it (so all deps already stable). Also, arch teams are responsible for at least shallow (compile) testing of the package, and ideally smoke testing on run and possibly testing with various USE flag combinations and reverse dependencies testing (the latter is a regular part of my stabilization workflow, and the script for that is part of the same suite that files bugs). Note that there is a tradeoff here: I really started the stabilizations after I've noticed how many bugs are fixed in ~arch that still affect stable, but the fixing version didn't get stabilized. This is the downside of an opt-in approach, since inactive maintainers are not going to opt-in. Finally, everyone from metadata.xml is CC-ed. There is no "trying a different maintainer" - all of them are there since day one. Please let me know if you still have concerns - ideally back them with data and actual cases showing problems (or scenarios that can reasonably be likely) instead of just saying it _might_ lead to breakages. Anything _might_ lead to breakages, including taking no action here and allowing bugs to be not fixed for stable. :) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 05/21/2013 10:02 AM, Ciaran McCreesh wrote: > On Tue, 21 May 2013 09:57:53 -0400 > Michael Mol wrote: >> On 05/21/2013 09:50 AM, Ciaran McCreesh wrote: >>> On Tue, 21 May 2013 04:45:12 + (UTC) >>> Duncan <1i5t5.dun...@cox.net> wrote: But the point you're missing is that INSTALL_MASK is NOT a hack. >>> >>> Sure it is. It's a hack and remains a hack until there's a way of >>> using it without risk of breakage. >> >> That's a silly requirement. Every time I sit down with one of my >> systems and start playing/exploring (If I've gone a month without >> getting somewhat competent with something completely new to me, it's >> been a bad month) with USE flags, I break my system with within >> hours. USE flags are awesome at what they do, and they're incredibly >> robust, but that doesn't mean that toggling features on and off isn't >> dangerous. > > And you're reporting bugs for all these missing or automagic > dependencies, right? > Actually, yes. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Tue, 21 May 2013 09:57:53 -0400 Michael Mol wrote: > On 05/21/2013 09:50 AM, Ciaran McCreesh wrote: > > On Tue, 21 May 2013 04:45:12 + (UTC) > > Duncan <1i5t5.dun...@cox.net> wrote: > >> But the point you're missing is that INSTALL_MASK is NOT a hack. > > > > Sure it is. It's a hack and remains a hack until there's a way of > > using it without risk of breakage. > > That's a silly requirement. Every time I sit down with one of my > systems and start playing/exploring (If I've gone a month without > getting somewhat competent with something completely new to me, it's > been a bad month) with USE flags, I break my system with within > hours. USE flags are awesome at what they do, and they're incredibly > robust, but that doesn't mean that toggling features on and off isn't > dangerous. And you're reporting bugs for all these missing or automagic dependencies, right? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 05/21/2013 09:50 AM, Ciaran McCreesh wrote: > On Tue, 21 May 2013 04:45:12 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> But the point you're missing is that INSTALL_MASK is NOT a hack. > > Sure it is. It's a hack and remains a hack until there's a way of using > it without risk of breakage. > That's a silly requirement. Every time I sit down with one of my systems and start playing/exploring (If I've gone a month without getting somewhat competent with something completely new to me, it's been a bad month) with USE flags, I break my system with within hours. USE flags are awesome at what they do, and they're incredibly robust, but that doesn't mean that toggling features on and off isn't dangerous. On a working system, *anything* you might touch in /etc/portage/make.conf carries with it the risk of breakage. This is what makes Gentoo a place for people who are willing to get their hands dirty understanding how their system works. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Tue, 21 May 2013 04:45:12 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > But the point you're missing is that INSTALL_MASK is NOT a hack. Sure it is. It's a hack and remains a hack until there's a way of using it without risk of breakage. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] robo-stable bugs
Markos Chandras schrieb: > On 21 May 2013 13:21, Thomas Sachau wrote: >> "Paweł Hajdan, Jr." schrieb: >>> Remember this is supposed to _help_ Gentoo. You can opt out of the bugs >>> (there is a package name and maintainer name regex in the script). You >>> don't need to "hunt them down" - if you do nothing another script will >>> just CC arches after 30 days. >>> >>> Paweł >>> >> >> Uhm, automagic stabilization without maintainer ok? This sounds like a >> bad idea. >> >> Doing a batch CC-ing after maintainer gave his ok or anything similar, >> which starts, when someone actually aproved the stable going is all ok, >> but doing this automaticly may get packages become stable, which are not >> intended to become so and should have never been there. >> >> -- >> >> Thomas Sachau >> Gentoo Linux Developer >> > > If you don't read your bugmail in 30 days then that is a different > problem. I like the way Paweł handles this at the moment. 30 days is > enough time for active maintainers to object. We just can't afford > waiting months for inactive maintainers to act. > > -- > Regards, > Markos Chandras - Gentoo Linux Developer > http://dev.gentoo.org/~hwoarang > > So you are a perfect human with a perfect computer and a perfect environment? :-) For everyone else, there are already enough possible issues with the starting point of the bug mails (mail accidently deleted by user or some spam setup, read mail, planned for later, forget or just planned to keep the stable request bug open for some later stabilization time etc). So again: I accept opt-in solutions, but opt-out is a no go for stable request bugs. And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Chí-Thanh Christopher Nguyễn schrieb: > Thomas Sachau schrieb: >> Uhm, automagic stabilization without maintainer ok? This sounds like a >> bad idea. Doing a batch CC-ing after maintainer gave his ok or >> anything similar, which starts, when someone actually aproved the >> stable going is all ok, but doing this automaticly may get packages >> become stable, which are not intended to become so and should have >> never been there. > > This is why the maintainer can object within 30 days (or so) or block > the stabilization bug with another one which details the reasons why the > package should not be stabilized. > > > Best regards, > Chí-Thanh Christopher Nguyễn > > > I guess, you missed my point, so let me repeat it: Automagic stabilization is a bad idea. And just because a maintainer can opt-out per bug, it does not change the automagic behaviour nor does it make this thing any better. In this case, there are enough possible cases, where a maintainer does miss the bug, so again a package may become stable, also it should never have been a stable candidate. So again: Automatic scripts with maintainer opt-in are ok, anything else is a bad idea. Beside this, i have never seen any announcement about such scripting behaviour, which makes this automagic even worse, since it is unexpected for maintainers, who might e.g. keep a stable request bug open for later or to avoid dups. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 21 May 2013 13:21, Thomas Sachau wrote: > "Paweł Hajdan, Jr." schrieb: >> Remember this is supposed to _help_ Gentoo. You can opt out of the bugs >> (there is a package name and maintainer name regex in the script). You >> don't need to "hunt them down" - if you do nothing another script will >> just CC arches after 30 days. >> >> Paweł >> > > Uhm, automagic stabilization without maintainer ok? This sounds like a > bad idea. > > Doing a batch CC-ing after maintainer gave his ok or anything similar, > which starts, when someone actually aproved the stable going is all ok, > but doing this automaticly may get packages become stable, which are not > intended to become so and should have never been there. > > -- > > Thomas Sachau > Gentoo Linux Developer > If you don't read your bugmail in 30 days then that is a different problem. I like the way Paweł handles this at the moment. 30 days is enough time for active maintainers to object. We just can't afford waiting months for inactive maintainers to act. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 05/20/2013 11:34 PM, Canek Peláez Valdés wrote: > On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell > wrote: [snip] >> That's missing the point. If you don't run systemd, having unit >> files is pointless. Thankfully there's INSTALL_MASK and whatnot, >> but that seems like a hack instead of something more robust. Why >> include systemd unit files (by default, with no systemd USE flag, >> thanks to the council...) on a system that's not using it? 154 >> files isn't negligible unless you're flippant with your system and >> don't care about bloat. Unused software sitting around *is* a >> waste of disk-space. > > Unit files are not software; they are data. That's like saying "shell scripts are not software, they are data". Unit files, semantically and collectively, are a system-behavior-defining set of interpreted modules written in a declarative language. In fact, that's what makes them even remotely appealing, on comparison to shell-based init scripts; they make declarations of requirements, the "what", and leave it to the system resolver to work out the "how". (It's from this perspective that I like the idea of using unit files as a point of origin for *generating* init configurations like systemv, openrc or runit scripts. You'd be compiling the init script for the target init system, and your result should be more robust for it.) > > And I believe you are the one missing the point. I don't run OpenRC; > I don't need no files in /etc/init.d. But you don't see me (nor any > other systemd user) complaining about pointless scripts in > /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with > my life. > > Non-systemd users should do the same for files under > /usr/lib/systemd, if they really are that worried about systemd > "infecting" their systems. Complaining about a council-decided policy > (and, I believe, backed up by the developers that matter, including > the OpenRC maintainers) is just beating on a dead horse. The push to keep USE flags specific to enabling and disabling program features seems weird to me; the semantics of USE flags seem valuable for a great deal more than that. > > Get over it. > >> Some people (like myself) came to Gentoo to avoid putting systemd >> on their systems and to make use of the great choice that Gentoo >> allows. This push to make systemd a "first level citizen" or >> whatever reeks of marketing. > > If Gentoo is about choice, then systemd is one of those choices. This I take no issue with. > And systemd will become a first class citizen inside Gentoo, like it > or not. ... > Support for it has been getting better and better, and more and more > Gentoo users are running with systemd. And users are switching to eudev and mdev as well. Personally, I think heterogeneity is a good thing...That's a huge part of why I like Gentoo; it's a crucible for open-source software that tends to bring breakages in edge-case (but theoretically "supported") configurations to upstream attention. > > If some fundamentalists ... > users don't want even one file in their systems with "systemd" on > their paths, they can install eudev/mdev, put the necessary > directories in INSTALL_MASK, and do the extra work. If some other > fundamentalists users (like myself) don't want even one OpenRC > related file on our systems, we can create an overlay to remove the > dependency of baselayout on OpenRC, put /etc/init.d in INSTALL_MASK, > and do the extra work. > > Neither case covers the average systemd/OpenRC user, who doesn't > care about a few scattered files in /etc/init.d nor /usr/lib/systemd, > and just want to run her machine with the init system of her choice. > If Gentoo is really about choice. It is, and it should be. > >> If there is desire among users for unit files, they can contact >> upstream or maintain their own set of unit files. It's not like >> they're hard to write. > > So, Gentoo is about choice, but only for the choices you agree with. > Great. Nobody says the devs must do whatever the users demand of them; the devs are unpaid. The best arguments in this thread, to my eye, have been to encourage devs to accept user-contributed unit files. As users, you and I can't force devs to do anything. But we can always pull up our sleeves and dig in ourselves. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Thomas Sachau schrieb: > Uhm, automagic stabilization without maintainer ok? This sounds like a > bad idea. Doing a batch CC-ing after maintainer gave his ok or > anything similar, which starts, when someone actually aproved the > stable going is all ok, but doing this automaticly may get packages > become stable, which are not intended to become so and should have > never been there. This is why the maintainer can object within 30 days (or so) or block the stabilization bug with another one which details the reasons why the package should not be stabilized. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] robo-stable bugs
"Paweł Hajdan, Jr." schrieb: > Remember this is supposed to _help_ Gentoo. You can opt out of the bugs > (there is a package name and maintainer name regex in the script). You > don't need to "hunt them down" - if you do nothing another script will > just CC arches after 30 days. > > Paweł > Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] TLDNR; Re: Making systemd more accessible to "normal" users
William Hubbs wrote: > Steven J. Long wrote: > > I haven't seen anyone say that in this entire discussion, but I might have > > missed something. "If a user wants to run GNOME, he [can] switch to systemd" > > is clearly not saying that, so we're left with an enigmatic "some" who > > haven't > > posted to this thread, afaics. > > The point I'm trying to make here is that for gnome >=3.8, upstream > gnome does not support running gnome without systemd afaik. Then I don't know why you think repeating stuff we already know adds anything to the discussion. The point you actually made was: > Some folks want to use gnome without systemd and are putting that under the > gentoo > is about choice banner and want us to support them. And that's what I answered, so my point still stands, in response to what you actually wrote. > > It's clear to me that users have been forced through lots of changes over > > the > > last 5 years, even where we just want to carry on using our machines the way > > we always have. Isn't that what convenience layers are about? So Walter's > > point stands. > > No it doesn't, because Gentoo Linux isn't requiring you to run systemd. Again, you appear to be deliberately misrepresenting the discussion, this time in order to make it just about whether one must run systemd or not. That's not the only concern. Nor have the changes that have been forced upon users by this upstream, to zero tangible benefit afaic but causing an awful lot of pain, been restricted to systemd; the "last 5 years" I referred to. This is the point Walter actually made: >> If a user wants to run GNOME badly enough, he'll switch to systemd. I don't >> see >> why the rest of us (i.e. non-users of GNOME) should have to follow along and >> reconfigure our systems. This is a case of the tail wagging the dog. Your strawman is that no-one is talking about anything but GNOME. Yet in another post we have: > Today the source of all our troubles is just GNOME, I am afraid that tomorrow > it > will expand beyond it. The usual eleventy-eleven nonsense, akin to the nonsense about split /usr being "broken", and here's a load of spurious reasons why from people who never saw the point, so let's change everyone's setup, when /really/ it was just about udev initscripts requiring /usr. And delaying start till after localmount if you have stuff for rootfs builtin (which most of us do after an install: that's how we booted to setup the rest of the system) works perfectly well, without requiring you to throw another point of failure and maintenance into the mix. So, lots of changes foisted upon us, to support corner-cases that aren't even designed very well[1], and will require more changes in the future, since upstream think they know better than everyone else. *Making the simple cases complex, to support the complex ones is simply doing it wrong.* Especially when your idiot-box can't cope with unexpected situations, and instead you rely on rubbishing users' experience, with a patronising "no-one needs that" so you don't even support the complex cases very well. Mainly because you refuse to keep it simple, as you want to display your virtuosity, instead of providing tools that users and other developers can tie together as they see fit. "Tail wagging the dog" sounds exactly right. So Walter's point still stands imo. When you forego modularity, you get a ripple effect of changes. Exactly what we've seen happen more and more over the last 5 years. Providing mechanisms to handle the complex cases, or to allow the user to handle them, is fine. Just don't wag the dog. > > > >> Fabio Erculiani wrote > > > >>> So what do we want to do then? Isolate from the rest of the world? > > Gnome can depend on w/e upstream require. How is that the whole world? > > It's not even the whole Linux ecosystem, and I can't see Qt giving up cross- > > platform independence, just to work with systemd. That was never going to > > happen, so it was never going to happen in KDE either, however enthused a > > few of its volunteers were, since KDE is a showcase for Qt. > > > > Matthew Thode wrote: > > > If upstream gnome has that dep on systemd then I kinda think we should > > > too (technical decision, not one I like personally) > > > > I think we should too: all anyone has said is "Gnome is not Linux". > > Presenting > > its choices as representative of every DE and upstream project is simply > > misleading. > > I haven't done that, and I don't know of anyone else who has. "the rest of the world" and the above comment quoted seem pretty clear to me. So we agree it's only GNOME-3 that has the hard requirement on systemd. KDE, the other big DE, which ime has brought more non-Linux users to Linux than any other, and certainly represents the only one left of the two which still works like a desktop, has no such limitation. Neither do the forks of GNOME-2, nor lxde, and indeed people have original GNOME-2 working
Re: Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Mon, May 20, 2013 at 11:03 PM, Daniel Campbell wrote: > Well, I have to at least thank you for turning this from just a typical Gentoo flame-war into a breeding ground for LWN Quote of the Week candidates. Rich
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Mon, May 20, 2013, at 11:03 PM, Daniel Campbell wrote: > That's missing the point. If you don't run systemd, having unit files is > pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems > like a hack instead of something more robust. Why include systemd unit > files (by default, with no systemd USE flag, thanks to the council...) > on a system that's not using it? 154 files isn't negligible unless > you're flippant with your system and don't care about bloat. Unused > software sitting around *is* a waste of disk-space. > You've either won the "Unreasonably Pedantic Award" or the "Will Say Any Stupid Thing Prove His/Her Point Award". Please let me know which one to send to you. -a
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Tue, 21 May 2013 09:03:54 +0200 Alan McKinnon wrote: > On 21/05/2013 05:03, Daniel Campbell wrote: > > That's missing the point. If you don't run systemd, having unit files is > > pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems > > like a hack instead of something more robust. Why include systemd unit > > files (by default, with no systemd USE flag, thanks to the council...) > > on a system that's not using it? 154 files isn't negligible unless > > you're flippant with your system and don't care about bloat. Unused > > software sitting around *is* a waste of disk-space. > > > > Some people (like myself) came to Gentoo to avoid putting systemd on > > their systems and to make use of the great choice that Gentoo allows. > > This push to make systemd a "first level citizen" or whatever reeks of > > marketing. If there is desire among users for unit files, they can > > contact upstream or maintain their own set of unit files. It's not like > > they're hard to write. > > > > > > This is such a weak argument it's quite laughable. > > I don't like gnu info files. Neither me nor anyone I know can figure out > how to drive info. Arrows move the cursor, enter follows links, '/' searches. And don't dare touch anything else because nobody knows what could happen! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 21/05/2013 05:03, Daniel Campbell wrote: > That's missing the point. If you don't run systemd, having unit files is > pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems > like a hack instead of something more robust. Why include systemd unit > files (by default, with no systemd USE flag, thanks to the council...) > on a system that's not using it? 154 files isn't negligible unless > you're flippant with your system and don't care about bloat. Unused > software sitting around *is* a waste of disk-space. > > Some people (like myself) came to Gentoo to avoid putting systemd on > their systems and to make use of the great choice that Gentoo allows. > This push to make systemd a "first level citizen" or whatever reeks of > marketing. If there is desire among users for unit files, they can > contact upstream or maintain their own set of unit files. It's not like > they're hard to write. > This is such a weak argument it's quite laughable. I don't like gnu info files. Neither me nor anyone I know can figure out how to drive info. So, let's rip all the info files out of every package; leaving the 3 users who do know info free to grab their copies from upstream. I mean it's not like it's hard or anything, and info files are easy to write. Daniel, you should just get over it. Having choices means you let the other guy have his choices too. Sometimes that means you have to let that guy have a little bit of his infra lying around so his choice is possible. And no-one ever said having choices means your exact personal preferences wrt every little thing will be baked in. -- Alan McKinnon alan.mckin...@gmail.com
