Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On Tue, 2011-06-07 at 20:16 +0200, Ulrich Mueller wrote: > Even if it fulfills the restrictions for global variables, it is still > an abuse of the spec, because PMS defines S as follows: > "The full path to the temporary build directory, used by src_compile, > src_install etc." I don't see how setting S violates this specification. For each ruby implementation that we build for the definition of S holds. It just has a different value for each implementation. > And for EAPI 4 it will fail, because S is required to exist as initial > working directory in most src_* phase functions. Correct, so in EAPI 4 we now set the RUBY_S variable to handle the initial setup, and then we set S as part of the environment setup when we are iterating through each ruby implementation within each of the PMS phases. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Mike Frysinger wrote: On Tuesday, June 07, 2011 19:41:20 Dale wrote: I have a question or two. I don't care if you, or others, reply to this with a answer, just think on it. A policy, rule if you will, has been decided on by the council. This after MUCH discussion on this list and the council hearing both sides of the argument. You, apparently on your own or with a few others, have decided to ignore the policy or rule. umm, no, ive done no such thing. try again. -mike Let me see if I understand this correctly. Most devs and some users wants things put in the changelog. I don't know if it was you before but in the past someone didn't want to put when versions are removed. That person, whoever it was, said they were not going to do it because it was silly or whatever. This was taken to the council and it was decided that all changes had to be put in the changelog. Now in this thread, about the same thing from my understanding. You said "waste of time" and the policy is not "sane". So, council says it has to be done. You say you won't. Tell me where I missed the point here. Thanks for the reply but I think this is going to be headed back up the food chain again. It appears that either rules mean nothing or they have to be enforced on everyone. The rule makers need to decide this. I suspect the reason this thread has gotten quiet is because it has already been discussed off this list about what is coming next. Just me reading tea leaves here. My advice, follow the rules or get the rules changed. Don't break them tho. It doesn't matter to me if you take that advice or not. Just saying. Dale :-) :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, 7 Jun 2011 17:45:03 -0400 Mike Frysinger wrote: > On Tuesday, June 07, 2011 17:36:59 Ciaran McCreesh wrote: > > On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote: > > > > And yes, it should be automated. I agree. Doesn't change the > > > > current situation. > > > > > > of course it does. it makes the current situation irrelevant. > > > > Does this mean we should shortly be expecting to see you do the > > work to migrate the tree to Git and to automate ChangeLog > > generation? > > the tree has already been migrated. automatic ChangeLog generation > is trivial to implement, and many many projects already have scripts > to do it. Including portage's egencache which can generate ChangeLogs from git. Just a side note. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal: include dbus session handling in baselayout (or somewhere, in which case where?)
On Tuesday, June 07, 2011 22:02:23 Nirbheek Chauhan wrote: > On Wed, Jun 8, 2011 at 3:41 AM, Mike Frysinger wrote: > > On Saturday, April 30, 2011 12:20:15 Leho Kraav wrote: > >> /etc/profile.d/dbus-session.sh attached, looking for feedback about > >> problems with it and if the whole approach even makes sense. I might be > >> not knowing something important. > > > > i dont think this makes sense in baselayout. it works great without > > dbus. > > > > doesnt the login manager already take care of launching a dbus-session ? > > I believe the use-case is being able to control applications from the > VTs without having to launch a dbus session manually. Which should be > done via ~/.bashrc, to be honest. Makes no sense to have a global dbus > session, since it's supposed to be per-user. i imagine this could be done via pam too i dont think this is a global dbus session. it's in profile.d which means it gets executed at shell login time. i think you meant .bash_login rather than .bashrc. probably the only place this could be integrated is in the dbus ebuild itself. install it as a doc file and elog the info to make the user aware of it. i don't think this is something we want to install automatically. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 19:41:20 Dale wrote: > I have a question or two. I don't care if you, or others, reply to this > with a answer, just think on it. A policy, rule if you will, has been > decided on by the council. This after MUCH discussion on this list and > the council hearing both sides of the argument. You, apparently on your > own or with a few others, have decided to ignore the policy or rule. umm, no, ive done no such thing. try again. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: catalyst should use pbzip2 for stages
On Wed, Jun 8, 2011 at 1:55 AM, Mike Frysinger wrote: > isnt there a gentoo-release mailing list for catalyst and such ? > I presume this is so that users can extract stages using pbzip2 in parallel? Since pbzip2 can only parallel-extract bzip2 archives made with pbzip2? What's wrong with using lbzip2 instead of pbzip2? It can parallel decompress (and compress) *all* bzip2 archives, not just those made with pbzip2/lbzip2. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Proposal: include dbus session handling in baselayout (or somewhere, in which case where?)
On Wed, Jun 8, 2011 at 3:41 AM, Mike Frysinger wrote: > On Saturday, April 30, 2011 12:20:15 Leho Kraav wrote: >> /etc/profile.d/dbus-session.sh attached, looking for feedback about >> problems with it and if the whole approach even makes sense. I might be >> not knowing something important. > > i dont think this makes sense in baselayout. it works great without dbus. > > doesnt the login manager already take care of launching a dbus-session ? > I believe the use-case is being able to control applications from the VTs without having to launch a dbus session manually. Which should be done via ~/.bashrc, to be honest. Makes no sense to have a global dbus session, since it's supposed to be per-user. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Council 2011 / 2012 election nomination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I nominate William Hubbs (williamh) - -- David Abbott (dabbott) Gentoo http://dev.gentoo.org/~dabbott/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ux2EACgkQcZ+z4vAcSsyhSgCfWH0HzQlTZrJWRiN1RTAjAssg vUsAoIGfiX6KwumNhC8UtzRNaJJLFjHO =ofLL -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Mike Frysinger wrote: seems we gauge things differently as i dont think it's that black& white, although it probably is further in your white than in my black. further, i dont believe people actually get useful information out of this, they just think they do (perception vs reality). when an actual bug arises, the information contained in the ChangeLog doesnt assist in the bug triage/fixing. depgraph broken -> file removed -> reason is irrelevant to the user. maintainer of the package causing the depgraph breakage gets a bug in bugzilla and they address it by either re-adding, or trimming more, or tweaking deps, or something else. so if someone wants a fuzzy security blanket, they can look to autogeneration and then it's no longer my problem. -mike Mike and others as it applies, I have a question or two. I don't care if you, or others, reply to this with a answer, just think on it. A policy, rule if you will, has been decided on by the council. This after MUCH discussion on this list and the council hearing both sides of the argument. You, apparently on your own or with a few others, have decided to ignore the policy or rule. What would you think if someone else ignores another rule that affects you, negatively of course? What would you do? What do you think should be done to the person ignoring the rule? Should that person be allowed to do so with no consequences at all? Just everyone do as they wish regardless of the rules. What affect would that have on Gentoo as a whole? Do you really want to see this happen after all the mess Gentoo has been through in the past? Think on that for a bit. Give it a day or so or better yet, sleep on it. Again, I don't care for you to answer or reply. Just think. Dale :-) :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 18:08:17 Matt Turner wrote: > There _was_ a policy before, but it was unclear about documenting > version removals and arguably didn't require it, so after a few > developers (you've been often mentioned as one of them) refused to > document version removals in the changelog, even after prompting on > gentoo-dev@ the council fixed the policy. i'm aware of the history. it still doesnt validate the logic cited earlier. > Of course the policy doesn't exist simply because you disagree with > others, the policy exists (and was instituted/clarified) because you > wouldn't do something that most developers and users find useful and > thought was already policy, even after being asked. > > Why does this have to be such a struggle. It's pretty clear that the > policy is going to be changed again to fix the oversight of silly > situations like I mentioned previously, but there's a near unanimous > agreement that documenting version removals _is_ useful. So, please, > just start doing it. It's really not a lot of work. I'm sure something > more can be done to make this more automated, but until then please > just fucking do it and let's stop all this silliness. seems we gauge things differently as i dont think it's that black & white, although it probably is further in your white than in my black. further, i dont believe people actually get useful information out of this, they just think they do (perception vs reality). when an actual bug arises, the information contained in the ChangeLog doesnt assist in the bug triage/fixing. depgraph broken -> file removed -> reason is irrelevant to the user. maintainer of the package causing the depgraph breakage gets a bug in bugzilla and they address it by either re-adding, or trimming more, or tweaking deps, or something else. so if someone wants a fuzzy security blanket, they can look to autogeneration and then it's no longer my problem. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposal: include dbus session handling in baselayout (or somewhere, in which case where?)
On Saturday, April 30, 2011 12:20:15 Leho Kraav wrote: > This is something like net-misc/keychain is for key management. My main > use case so far is to do with gnome-keyring-daemon for Subversion. If > you want to have a password-locked keyring, you will have to unlock it > every time you have a new dbus instance, which can pretty much happen > every time you open a new shell in tmux or whatnot since Subversion > needs dbus to communicate with keyring. > > /etc/profile.d/dbus-session.sh attached, looking for feedback about > problems with it and if the whole approach even makes sense. I might be > not knowing something important. i dont think this makes sense in baselayout. it works great without dbus. doesnt the login manager already take care of launching a dbus-session ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 5:47 PM, Mike Frysinger wrote: > On Tuesday, June 07, 2011 17:32:03 Matt Turner wrote: >> On Tue, Jun 7, 2011 at 5:09 PM, Mike Frysinger wrote: >> > On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: >> >> To be perfectly blunt, no small part of what caused this current fiasco >> >> was this exact attitude. I don't like the current policy either, it's >> >> far too wide. However, if you go back and look at why it even *got* to >> >> council, it was because you (and others), decided that they weren't >> >> going to give any regard to the requests of some of their fellow devs >> >> about ChangeLogging removals. >> > >> > how is this relevant at all ? i dont find value in these entries, other >> > people do. my attitude towards how worthless they are has 0 bearing on >> > the policy towards creating it. >> >> Plenty of people have, successfully I though, argued that removal >> Changelog entries _are_ useful and have cited relevant situations. >> >> Make a case about how the current policy is stupid in that it requires >> changelog entries for trivial whitespace changes or for documenting >> removals of packages even when it means the changelog is deleted as >> well, but for god sake, stop the nonsense about documenting version >> removals being useless. > > that wasnt my point, although it is a good one. the idea that policy exists > because i disagree with others is bunk. whether it be people complaining to > other devs to do XYZ or the council makes it official XYZ, there is still a > policy XYZ. > -mike There _was_ a policy before, but it was unclear about documenting version removals and arguably didn't require it, so after a few developers (you've been often mentioned as one of them) refused to document version removals in the changelog, even after prompting on gentoo-dev@ the council fixed the policy. Of course the policy doesn't exist simply because you disagree with others, the policy exists (and was instituted/clarified) because you wouldn't do something that most developers and users find useful and thought was already policy, even after being asked. Why does this have to be such a struggle. It's pretty clear that the policy is going to be changed again to fix the oversight of silly situations like I mentioned previously, but there's a near unanimous agreement that documenting version removals _is_ useful. So, please, just start doing it. It's really not a lot of work. I'm sure something more can be done to make this more automated, but until then please just fucking do it and let's stop all this silliness. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:32:03 Matt Turner wrote: > On Tue, Jun 7, 2011 at 5:09 PM, Mike Frysinger wrote: > > On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: > >> To be perfectly blunt, no small part of what caused this current fiasco > >> was this exact attitude. I don't like the current policy either, it's > >> far too wide. However, if you go back and look at why it even *got* to > >> council, it was because you (and others), decided that they weren't > >> going to give any regard to the requests of some of their fellow devs > >> about ChangeLogging removals. > > > > how is this relevant at all ? i dont find value in these entries, other > > people do. my attitude towards how worthless they are has 0 bearing on > > the policy towards creating it. > > Plenty of people have, successfully I though, argued that removal > Changelog entries _are_ useful and have cited relevant situations. > > Make a case about how the current policy is stupid in that it requires > changelog entries for trivial whitespace changes or for documenting > removals of packages even when it means the changelog is deleted as > well, but for god sake, stop the nonsense about documenting version > removals being useless. that wasnt my point, although it is a good one. the idea that policy exists because i disagree with others is bunk. whether it be people complaining to other devs to do XYZ or the council makes it official XYZ, there is still a policy XYZ. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:36:59 Ciaran McCreesh wrote: > On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote: > > > And yes, it should be automated. I agree. Doesn't change the current > > > situation. > > > > of course it does. it makes the current situation irrelevant. > > Does this mean we should shortly be expecting to see you do the work to > migrate the tree to Git and to automate ChangeLog generation? the tree has already been migrated. automatic ChangeLog generation is trivial to implement, and many many projects already have scripts to do it. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 2:36 PM, Ciaran McCreesh wrote: > On Tue, 7 Jun 2011 17:35:11 -0400 > Mike Frysinger wrote: >> > And yes, it should be automated. I agree. Doesn't change the current >> > situation. >> >> of course it does. it makes the current situation irrelevant. > > Does this mean we should shortly be expecting to see you do the work to > migrate the tree to Git and to automate ChangeLog generation? Automated changelog entries do not require git. -A > > -- > Ciaran McCreesh >
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote: > > And yes, it should be automated. I agree. Doesn't change the current > > situation. > > of course it does. it makes the current situation irrelevant. Does this mean we should shortly be expecting to see you do the work to migrate the tree to Git and to automate ChangeLog generation? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:23:23 Dane Smith wrote: > On 06/07/11 17:09, Mike Frysinger wrote: > > On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: > >> To be perfectly blunt, no small part of what caused this current fiasco > >> was this exact attitude. I don't like the current policy either, it's > >> far too wide. However, if you go back and look at why it even *got* to > >> council, it was because you (and others), decided that they weren't > >> going to give any regard to the requests of some of their fellow devs > >> about ChangeLogging removals. > > > > how is this relevant at all ? i dont find value in these entries, other > > people do. my attitude towards how worthless they are has 0 bearing on > > the policy towards creating it. > > There never would have been any such policy had people been a little > considerate of the requests of others. This could have ended like so: sorry, but that's utter bs. there is a disconnect between what you find valuable and what i find valuable. all you're doing is assuming your position is right and mine is wrong and thus i'm in the wrong and thus any disagreement that causes strife after that is my fault. if common ground between developers cannot be attained, then it is the council's job to step in and make a decision. > And yes, it should be automated. I agree. Doesn't change the current > situation. of course it does. it makes the current situation irrelevant. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 5:09 PM, Mike Frysinger wrote: > On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: >> To be perfectly blunt, no small part of what caused this current fiasco >> was this exact attitude. I don't like the current policy either, it's >> far too wide. However, if you go back and look at why it even *got* to >> council, it was because you (and others), decided that they weren't >> going to give any regard to the requests of some of their fellow devs >> about ChangeLogging removals. > > how is this relevant at all ? i dont find value in these entries, other > people do. my attitude towards how worthless they are has 0 bearing on the > policy towards creating it. Plenty of people have, successfully I though, argued that removal Changelog entries _are_ useful and have cited relevant situations. Make a case about how the current policy is stupid in that it requires changelog entries for trivial whitespace changes or for documenting removals of packages even when it means the changelog is deleted as well, but for god sake, stop the nonsense about documenting version removals being useless. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 5:09 PM, Samuli Suominen wrote: > On 06/07/2011 10:53 PM, Mike Frysinger wrote: >> On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: >>> "Mike Frysinger (vapier)" said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old >>> >>> Please document removal of ebuilds in ChangeLogs. >> >> waste of time. i simply wont bother removing old versions until changelogs >> start being autogenerated or the policy is sane again. > > +1, see: http://bugs.gentoo.org/show_bug.cgi?id=368097#c75 > > and I have to say it's all on councils shoulders how bad of an impact > this will have on the tree with several devs leaving old files around or > leaving trivial fixes uncommitted to workaround bad policy. To avoid cluttering that bug report more, I'll respond here. It seems like the obvious answer is yes. The devrel resolution simply says that you can have commit access back after promising to follow the policy, and I can't see any way you wouldn't be following the policy by not making commits where you'd have otherwise left the changelog untouched. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/11 17:09, Mike Frysinger wrote: > On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: >> To be perfectly blunt, no small part of what caused this current fiasco >> was this exact attitude. I don't like the current policy either, it's >> far too wide. However, if you go back and look at why it even *got* to >> council, it was because you (and others), decided that they weren't >> going to give any regard to the requests of some of their fellow devs >> about ChangeLogging removals. > > how is this relevant at all ? i dont find value in these entries, other > people do. my attitude towards how worthless they are has 0 bearing on the > policy towards creating it. > There never would have been any such policy had people been a little considerate of the requests of others. This could have ended like so: Dev y: "Hey dev x, can you please ChangeLog removals please. I find it very useful." Dev x: "Sure. I don't see use in the information, but if it's going to make your job easier, I'll try to remember to do it." Dev y: "Thanks!" Then this never would have even gotten to council, council never would have passed the current policy, and we never would have gotten to the bloody crapfest that it is now. I personally want people to heed my requests. The only way that will work is if I try to heed others. The only way to work in a community is a little give and take. >> You and I both know that a removal can (and sometimes does) cause breakage. >> These kinds of changes are things that your fellow devs (as well as many >> users) would like to see in ChangeLogs. I do *not* think that this is an >> unreasonable request. I find it to be a little.. inconsiderate I guess, when >> any developer fails to heed a reasonable request from another developer or >> user. I know I personally try to accommodate people if they ask me to do >> something slightly differently to make their lives easier. Why is it that >> you can't do that? Is running echangelog (or hell, scripting something) for >> a removal really that hard or undesirable? Can you really not spare the >> extra 10 seconds? I mean, come on. > > if you want useless information, then automate it. there's no reason at all > to not do so. i prefer to keep useful information in the changelogs of > packages i maintain without cluttering up with noise. Just because you deem it useless doesn't make it so. If someone else sees use in the information, I fail to see why it is such a huge deal to log it. Even if for no other reason than to make someone else's life a bit easier. And yes, it should be automated. I agree. Doesn't change the current situation. Regards, - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN7pbLAAoJEEsurZwMLhUxPTkP/AtB5skbFy9GOOpw1kKEu+jI 8z60RD/usXB+TAuHJGKqEDGg8mHzaY7xHMp8PaIoGSzUMGLFHYvnpfkiG1iMzGzF r/F6uLpxpDS35vDHJs5TWMZpiefK8D2SGF/mup68a75R3f7c7+FV2iFUSsJgqq5M iNJGHjzmnGG7utFIO4yRafuSFD1+dn3cZvWjUA6pRvZrMpY+hDRJ9ntuOeqn8CX9 Uw75PXWGEk8ebtR1hewR6sLQWJR1SVucexICCfOHEmLygpM3WJ9mPGxiiOT0iXRD Z7zO5bajoun6lv+xbAW5G4ITpk0s4eqXUQQ9Y1sWMmctXXkbmRn0MeGzK5EEhEen v+L7dRs7ZXjrD+rY+eni87rGNyS/GnUlq6Kx9cuJQJ/OrTB93wu1metnOlOIUH5N oEfvQq3gfsIshxGLmrkuwPZT6FkMxVCmEpyawMc2teSrZXrkHxWRVsW4W8u5+WQp fxp0HcLc4yS8BPTTgrAlT5UI/Tm3qPf+7UhgvH9Sx8AkmMgVD3sUOl38i4wiLvCu VsjRbCQ7tjrjM5VemaBOJzubcg0pbnHd9mhNK/2I1BDQjStb7EeXxiRvxJh61L6C u52mLmgHCvIcxkJkfdmDyl4We1BhvRp8u6lqIDjuxjgm5ge+JA2YtvYyOAYz4Ay4 zwPb45qd/GK9/dGAgtEf =7Ajj -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:14:05 Andreas K. Huettel wrote: > > On 06/07/11 15:53, Mike Frysinger wrote: > > > waste of time. i simply wont bother removing old versions until > > > changelogs start being autogenerated or the policy is sane again. > > For the record, I support Dane's statement 100%. > > In addition, I would like to say that you're behaving pretty much childish > and obstructive. in no way whatsoever am i obstructing anyone. look up the word and try again. as for childish, that's your opinion of course and everyone has one. here's another: forcing useless information which can be automatically dumped is a waste of developer time. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thursday, June 02, 2011 05:13:38 Fabian Groffen wrote: > Simple pros I see mentioned: additional pro: automatic culling of information no longer relevant. entries dating back to 2002 rarely are useful today. we could easily implement a cap via date, size, files still in the tree, # of entries, etc... reality is, if developers want to see what's going on, go to the VCS and get the full history. > Simple cons I see mentioned: > - useless information on removals of ebuilds/files if people are forcing this crap either way, i dont see it being a con > - useless information on whitespace changes could easily be mitigated by prefixing the message with '[trivial]' and then the generator skips those > - inability to edit ChangeLog entries (typos, bug refs, etc.) in practice, i rarely see this being an issue. it certainly hasnt impeded any of the huge projects out there (many of which are bigger than Gentoo) that only have a changelog in the VCS history. typos happen, no one cares, and people get over it. > 1) it appears echangelog messages more than just a couple of times >differ from the repoman commit messages; sometimes useful information >is lost when just using the VCS logs just bite our lip and move on. as time moves forward, the desync will become relegated to history. > 2) typo fixing on VCS-generated logs is sometimes necessary, but >probably impossible in practice, it's rarely (if ever) necessary > 4) package moves might lose all history for essentially the same files this is a technical matter of the generator that can be overcome > > -# $Header: /var/cvsroot/gentoo-x86/dev-vcs/git/ChangeLog,v 1.95 > > 2011/05/31 06:4 7:22 grobian Exp $ > > +# $Header: this/file/is/a/generated/ChangeLog,v 1.1 2011/06/02 09:47:14 > > cvsps2changelog Exp $ > > The $Header line is likely going to be useless, and probably is best > removed. Is there something useful that can be substituted here? the VCS ids used to generate the log (and perhaps their associated dates) > sys-devel/gcc-config: > > - 16 Mar 2008; Christian Heim Manifest: > > - Fixing the Manifest (emerge is complaining about missing > > - $FILESDIR/wrapper-1.5.0.o). > > This entry disappears because Manifest and ChangeLog changes are ignored. which is fine -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On 06/07/2011 10:53 PM, Mike Frysinger wrote: > On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: >> "Mike Frysinger (vapier)" said: >>> vapier 11/05/16 03:30:02 >>> >>> Removed: bzip2-1.0.5-r1.ebuild >>> Log: >>> old >> >> Please document removal of ebuilds in ChangeLogs. > > waste of time. i simply wont bother removing old versions until changelogs > start being autogenerated or the policy is sane again. +1, see: http://bugs.gentoo.org/show_bug.cgi?id=368097#c75 and I have to say it's all on councils shoulders how bad of an impact this will have on the tree with several devs leaving old files around or leaving trivial fixes uncommitted to workaround bad policy.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
> On 06/07/11 15:53, Mike Frysinger wrote: (...) > > waste of time. i simply wont bother removing old versions until > > changelogs start being autogenerated or the policy is sane again. For the record, I support Dane's statement 100%. In addition, I would like to say that you're behaving pretty much childish and obstructive. -- 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] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: > To be perfectly blunt, no small part of what caused this current fiasco > was this exact attitude. I don't like the current policy either, it's > far too wide. However, if you go back and look at why it even *got* to > council, it was because you (and others), decided that they weren't > going to give any regard to the requests of some of their fellow devs > about ChangeLogging removals. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. > You and I both know that a removal can (and sometimes does) cause breakage. > These kinds of changes are things that your fellow devs (as well as many > users) would like to see in ChangeLogs. I do *not* think that this is an > unreasonable request. I find it to be a little.. inconsiderate I guess, when > any developer fails to heed a reasonable request from another developer or > user. I know I personally try to accommodate people if they ask me to do > something slightly differently to make their lives easier. Why is it that > you can't do that? Is running echangelog (or hell, scripting something) for > a removal really that hard or undesirable? Can you really not spare the > extra 10 seconds? I mean, come on. if you want useless information, then automate it. there's no reason at all to not do so. i prefer to keep useful information in the changelogs of packages i maintain without cluttering up with noise. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/11 15:53, Mike Frysinger wrote: > On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: >> "Mike Frysinger (vapier)" said: >>> vapier 11/05/16 03:30:02 >>> >>> Removed: bzip2-1.0.5-r1.ebuild >>> Log: >>> old >> >> Please document removal of ebuilds in ChangeLogs. > > waste of time. i simply wont bother removing old versions until changelogs > start being autogenerated or the policy is sane again. > snip > -mike Mike, To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. You and I both know that a removal can (and sometimes does) cause breakage. These kinds of changes are things that your fellow devs (as well as many users) would like to see in ChangeLogs. I do *not* think that this is an unreasonable request. I find it to be a little.. inconsiderate I guess, when any developer fails to heed a reasonable request from another developer or user. I know I personally try to accommodate people if they ask me to do something slightly differently to make their lives easier. Why is it that you can't do that? Is running echangelog (or hell, scripting something) for a removal really that hard or undesirable? Can you really not spare the extra 10 seconds? I mean, come on. Regards, - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN7o5hAAoJEEsurZwMLhUx2RcP/ip1lKohjB46iWA/T0Mb2eoa Vro488IDBMSOXy6L+JvKW4vh2EOfJl8g5PGgJuJhM9OmiLgYxmOgBCPpbCtu21hj FlJc5jKc3qN+0So1ka0Tez/toccA5d0lxPpZWitxDnEtMzQ6M46eEUv00EZN8yle o/UP94Inlp4miYXTGeyw2HKL8GP5su53/gYFidWQyzewEBYlvIFaIvyTPmJmbT5b ztgdlEr/xWS12OcUM8PymoOIw86dc8VcGPlPP5PaAx97T8o8OTG3q8lzx6naqYGN IyWFCNCrJJXSjQptIDALm3TU3qGe4/2pDbo7JuRCA8fG/i6+bKDEhJuKwBCnvIp/ YJR/PL6IlOInsBrTdew78MG2MqRnsOebBZ5a7rRDMfqSLrB4GHLisuyE8oHlyU8W A6ABRIi9yZIQrQG9TMcywNjTT8ejse9gL+Xrm03Aveb37FdrbQV5Nu+a5/wkaYOU 3e/3X9eRTFK7FdaWsAjXzGyS/8b7WtKioCEFTo4giP5R6lucLpVqqMYkuhAxAzMX y1u+57aZVUfZTBVksfQyQApVU/j+4UgUdMUBWuoX7F4i19almlm7U5egWh7wmBNi oKsUz6OcsvZ00x5Hr8xTrFEWaxE5CGyThjX0npblPLni9ZyppJyEz9P2YZ9OscGH FL1nIoSPHBeBznWaKnzO =z3hd -END PGP SIGNATURE-
[gentoo-dev] Re: catalyst should use pbzip2 for stages
isnt there a gentoo-release mailing list for catalyst and such ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Reducing glibc's default locale.gen
On Tuesday, June 07, 2011 15:53:01 Matt Turner wrote: > No user has a need for more than some small subset of the total > available locales. the rub is in which locales the user cares about > I filed bug [1] to request the ability to select locales in catalyst > spec files, but no responses after six months -- which is totally > typical of catalyst bugs. i thought catalyst had a way of overlaying custom files. if it does, couldnt you simply overlay the /etc/locale.gen file ? > I commented in bug [2] suggesting that we perhaps reduce the default > locale.gen to only 'en_US.UTF-8 UTF-8' or some other limited subset. > > The default subset should be sufficient for a large number of users, > and users whose locales aren't shipped by default would simply be able > to edit /etc/locale.gen (which I'm sure almost everyone does anyway) > to select their desired locale and then run locale-gen to generate it > and remove unwanted locales. i dont think the subset should ever be arbitrarily reduced by whatever we feel like picking. you could however make an argument about filtering the default set based on LINGUAS that my brain matter would be open to accepting. feel free to open a glibc enhancement bug with a patch or PoC in that direction. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Crossdev / glib news item
On Sunday, May 15, 2011 14:24:16 Andreas K. Huettel wrote: > I volunteered to help Diego summarize a news item on "crossdev, glib and > binary compatibility" i really dont think crossdev merits a news item considering its general support status and the likely hood of actual users who are affected by this -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: > "Mike Frysinger (vapier)" said: > > vapier 11/05/16 03:30:02 > > > > Removed: bzip2-1.0.5-r1.ebuild > > Log: > > old > > Please document removal of ebuilds in ChangeLogs. waste of time. i simply wont bother removing old versions until changelogs start being autogenerated or the policy is sane again. > It'd also be better to do this all as one commit and run repoman with > each commit. seems you left out "imo" in this statement. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Reducing glibc's default locale.gen
Hi, Building 400~ locales is not fun on mips when building stages. No user has a need for more than some small subset of the total available locales. I filed bug [1] to request the ability to select locales in catalyst spec files, but no responses after six months -- which is totally typical of catalyst bugs. I commented in bug [2] suggesting that we perhaps reduce the default locale.gen to only 'en_US.UTF-8 UTF-8' or some other limited subset. The default subset should be sufficient for a large number of users, and users whose locales aren't shipped by default would simply be able to edit /etc/locale.gen (which I'm sure almost everyone does anyway) to select their desired locale and then run locale-gen to generate it and remove unwanted locales. Please provide feedback. I'd love to get this resolved one way or another. Thanks, Matt [1] http://bugs.gentoo.org/show_bug.cgi?id=348454 [2] http://bugs.gentoo.org/show_bug.cgi?id=146882#c13
Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
> On Tue, 7 Jun 2011, Donnie Berkholz wrote: >> But it is not compliant with PMS: >> "If S is assigned in the global scope of an ebuild, then the >> restrictions of section 12.2 for global variables apply." (section 12.1) >> "Global variables must only contain invariant values." (section 12.2) > It seems compliant to me, as S is assigned an invariant value that > happens to contain the character '*', which is overwritten with a new > value as a local variable in ebuild functions. Sample code in listing > 12.1 in my copy of the PMS seems to suggest this is perfectly fine > behavior as long as the global invariant is restored after each > function. Even if it fulfills the restrictions for global variables, it is still an abuse of the spec, because PMS defines S as follows: "The full path to the temporary build directory, used by src_compile, src_install etc." And for EAPI 4 it will fail, because S is required to exist as initial working directory in most src_* phase functions. Ulrich
Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On 13:21 Mon 30 May , Ulrich Mueller wrote:
> > On Mon, 30 May 2011, Diego Elio Pettenò wrote:
> > Il giorno lun, 30/05/2011 alle 08.27 +0200, Michał Górny ha scritto:
> >> S="${WORKDIR}/solutious-${PN}-*"
> >>
> >> I'm surprised if that actually works. I'd say that seems not
> >> PMS-compliant but in fact PMS seems to almost not mention S.
>
> > Because you didn't follow the whole eclass tree ;)
>
> > ruby-ng handles the star as a special case, given how many of those
> > we had to use over time, [...]
>
> But it is not compliant with PMS:
> "If S is assigned in the global scope of an ebuild, then the
> restrictions of section 12.2 for global variables apply." (section 12.1)
> "Global variables must only contain invariant values." (section 12.2)
It seems compliant to me, as S is assigned an invariant value that
happens to contain the character '*', which is overwritten with a new
value as a local variable in ebuild functions. Sample code in listing
12.1 in my copy of the PMS seems to suggest this is perfectly fine
behavior as long as the global invariant is restored after each
function.
--
Thanks,
Donnie
Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com
pgpm4QVAvdoo9.pgp
Description: PGP signature
Re: [gentoo-dev] [rfc] Rendering the official Gentoo logo / Blender,2.04, Python 2.2
Hi folks, Sebastian told me about the problem of not being able to render the logo in recent blender versions. So this is were I stepped in: I tried it and used the geometries from the old .blender file, and the yellowish reflecting image. Problem was to recreate the exact representation of the original logo, by new means of rendering and relighting. I tried to solve them by creating a new material for the g and carefully adjusting the parameters. Also I added a new modifier for the geometry to get rid of the ugly seam at the sharp edge. (This does not modify the geometry, only the rendering of it) However, here are my preliminary results: - the modified .blend-file[1] (tested with blender 2.57b) - new rendered logo image [2] - original logo image (for comparison)[3] What do you think? Greetings, Mario. [1] http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal.blend;hb=master [2] http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal.png;hb=images [3] http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal-orig.png;hb=images
Re: [gentoo-dev] RFC: removal of
On 6/3/11 9:18 AM, dev-ran...@mail.ru wrote: > On Fri, Jun 03, 2011 at 08:40:26AM +0200, "Paweł Hajdan, Jr." wrote: >> ... >> We can't have a tarball, most of the files from the package are >> non-redistributable. >> ... > > Then why do ebuilds contain line LICENSE="GPL-2"? Good catch. Well, the situation here is really unclear. Most of the package obviously is under GPL-2. Files downloaded by getweb script are copyrighted, but they have no clear license. I'm not a maintainer of the package, I'm just trying to make it work a bit better and remove the brokenness. ;-) signature.asc Description: OpenPGP digital signature
