Re: [gentoo-dev] Slacker archs
On 19-02-2007 20:21:49 -0800, Brian Harring wrote: Granted, ppc-macos has more, but mips has 7x the number of packages... plus ppc-macos is effectively a dead arch, they've gone on to prefix land for the most part. I just want to apologise to everyone that somehow gets messed up because of ppc-macos packages. I'm working on a list given to me by Diego to fix the ppc-macos mess, but I still got 500 to go it seems. Just feel free to assign a bug to us (well, me) so I might be able to move the packages that give problems up in the priority list. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
Stefan Schweizer wrote: comments? just find a scriptable system to manage server side mass keywording... as in $EDITOR tokeywordfile (same syntax as package.keywords) repoman tokeywords tokeywordfile (repoman first checks it is applicable locally and then push it over the server while it will produce the same modify) people just rsyncing a portion of the tree will be fine, the bandwidth to upload the thing would be minimal, if we are willing to feel the pain we could use the same trick for the mirrors... I'm against changing the ebuild structure. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
As other have pointed out these statistics are not rappresentative of how mips is stopping developers to do work on their packages. Also as stated in http://bugs.gentoo.org/show_bug.cgi?id=163795 Stephen Becker alias geoman has promised us all to retire soon, so the situation can only become worse for mips and much more breathable for everyone else. Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. I think the first step is to establish what all the problem architectures are. We all know that mips is by far the worst offender, but by how much? Rather than speculating wildly, I decided to make use of adjutrix and wc to find out. So, here we have a table showing just how much mips is a slacker arch: Snipped a pure numeric comparison. As expected, supporting minority archs is leading to tree-wide bloat and huge initial rsync times for users. Clearly something has to be done to protect Gentoo from those useless minority archs! I mean, how many users do we *really* have using amd64 or x86? Better protect gentoo and it's developer, especially the more active ones from the gravitational waves of those few, very annoying satellites. Then it will be possible to actually work to the rest. P.S. yes the mispell of ciranm is childly intentional. -- Francesco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Tue, Feb 20, 2007 at 01:00:12PM +0100, Francesco Riosa wrote: Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard mkay, but sometimes is _really_ difficult, missing flameeyes and keep geoman does not make it easyer. Might be dificult but maybe you could explain how it helps to bash geoman? A good advice before sending any mail like that is to take at least 10 minutes break to cool off and then read it again before sending it. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] CVS/SVN Migration, downtime Friday 23 Feb, 07h00-09h00 UTC
Hi folks, We'll be migrating to some new hardware for cvs.gentoo.org later this week. I am making a worst-case estimate that the migration will take two hours, but if everything goes right, it should take much less. CVS and SVN on the old machine (lark) will stop accepting commits at Friday morning 07h00 UTC. The new machine (stork) will take all commits after we come up again afterwards. Again, that's Friday 23rd February 07h00 thru 09h00 UTC. Status updates will be posted to the topic of #gentoo-dev as per previous migrations. For almost all developers, you will not need to redo any checkouts or anything, just inform SSH that yes, the fingerprints have indeed changed, and there isn't anything strange going on. The SSH hostkey public key fingerprint for stork.gentoo.org is: RSA: 2048 32:3c:c7:4e:51:b9:eb:5b:16:d5:0a:f8:51:08:b8:6b DSA: 1024 7f:ca:6d:6a:50:a9:6d:f1:d9:5e:d5:21:b7:77:ce:9c If you want an entries to put in your known_hosts files: cvs.gentoo.org,64.127.104.133 ssh-rsa B3NzaC1yc2EBIwAAAQEAxzjjwMHdneSqt9lrcanN48efFyvZTj4pmd/qrLlZPTblFvmoO0ssDsU4Ut28ZHWpKLcCOi5yXizpDM6nVFmlsaof2haJCHH5TN1nxi+ZM9gTDfuXJtS+H5Va7OIbTiyE/p2+0LDmnSCeitP7dmmZfg4iBYu8wXHIx1+Aa4UzoczzYv5sEgyf6E+tSJh4V4RURFtyiBOtNKHM/wTOyRMGwk99SdfwIRJKtgRC7QKwSxJWX0CstKhAUpeRIQAcheNBfzenDEMjx9iVZkwaJvMwfc/s8rUDcRiHBvY1xmFZRFVQHkP5OtRhjtbDd0TeuF9b7nFT46IE6TQWfeS1jkBLgQ== cvs.gentoo.org,64.127.104.133 ssh-dss B3NzaC1kc3MAAACBANhcvOluD5vXHOvIRYQ7FM5nJosQdihryHLQVMXtXexr4fJA/hMtirx3nTaqrLHDe7LVdlAJ/7kMGqm4eA+3IfBTLklwbdICbU8Se39VTkGmlHnl2UWTL0xVONIEpMbLxPEcBGLXTRvsKAw/kEAIfcHMKc07oneBQb9EdypMx8tDFQC0UrGZrPWHuimVHAGrld6LKW9IuwAAAIBLOOoQeW8uj0FHgmLyJ6B89zyRUxoD5JEWUAIctDx1OycO0BBNrxawo8Qm1DXmik4DsmS5YcqDC3A2px63Sgw+Vnz86AobKU1lYyz3ch25Jq2Zx3NmAHMQXiMEYHuXUYfrWZjKsfwkmfu+Plq7VS+/+4arkerFbiBzCgWKsj20dwAAAIBwb/madZsxK0ts+c36NDsTvju3HcG98DdECWsWp7v0rqSVKPEs5PoGBd10UJ6w34TZDi+GH+eBewn4DfEekHvP9xd8luSFpcpWFpxBSctgEkUAC/UhS0ZeFOQJMg1GfWxfsL4hQHOGAdzCphItxNptzfLuYpLyvyP2RBGCF6QmOg== Now you're wondering why I said _almost_ all developers. Per my email earlier in the week to -core about SSH keys in LDAP, if you were on the list of folks with key weirdness AND have not yet contacted me AND LDAP does not contain the active keys you are really using THEN you will not be able to commit! I'll send out personal reminders to all of you shortly. -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpYJmuUKVMDa.pgp Description: PGP signature
[gentoo-dev] let's clear things up (was Slacker archs)
On Tue, 20 Feb 2007 01:35:32 + Ciaran McCreesh [EMAIL PROTECTED] wrote: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. snip Wow, I almost don't know where to begin. The amount of FUD, misinformation, and outright lies floating around all of this bullshit is astounding. If you believe everything you've read from some incessantly obsessive blogger and some extremely loud and misinformed bug wrangler, you would believe that the mips team killed the baby jesus, caused the plagues, invaded Europe, and invaded Iraq...all with me as their supreme dictator. And yes, to you so impaired, that was indeed sarcasm. It seems like many of you are under some sort of warped impression that *I* am actively trying to hold back the tree, with my sole reason to piss of ebuild maintainers. That is so incredibly far from the truth as to be completely insane. So, let's try to clear some of this up, shall we? First of all, to you vivo, before you say something else you might regret later, you should consider that mips *has* gotten help recently, and said help is doing a very good job. The situation is only improving. More on this later. And also, it is *not* my fault that Diego quit. But if you want to keep loudly whining on the mailing list here about how I'm still around (I'm not actually) and Diego is gone, keep on going. More on this later too. You can say whatever you want about me, I actually have thick skin, unlike certain other people, however you are not making the situation any better. I suggest you stop. To t3h Harring and Mr. Parallel Grapefruit, I agree with you, Lies, Damn Lies, and Statistics. Citing percentages is circling around the point that Ciaran made. Some arch could only have 10 packages keyworded out of the entire tree, with 3 of them being slackers as defined here. This arch would lead your list by a wide margin. The fact is, tree bloat is measured purely by the *absolute number* of packages which are behind another arch. All of that said, how about we clear up all of the misinformation about how arch keywording really works, how deps get wrongly dropped, and then explain why mips has generally fallen behind. This isn't an excuse, but is merely a statement of facts which describe the situation. First, the ~arch tree. This one is easy. In most cases, you can merely compile test something against the ~arch tree, and then do a fairly quick run test to make sure things seem to be working as they should. If additional deps are required, they must be similarly tested. Another rule of thumb is that if other arches already have ~arch keywords and there have been no bugs saying something like this is complete crap and shouldn't be in the tree, then you can have fairly good assurance that you haven't missed any critical bugs (aside from really really wacky arch specific stuff...more on this later). Furthermore, ebuild maintainers are allowed (and encouraged) to carry ~arch keywords forward during version bumps. How about the stable arch tree? This one is trickier. In order to bump an ebuild into the stable tree, the arch team has to be far more careful. Not only must this ebuild have been in ~arch for 30 days without any bug reports, but it must have been *extensively* tested against the current stable tree to ensure no breakages. Furthermore, all required deps of said ebuild which are also ~arch must be similarly tested. This is extremely tedious work that requires a lot of time, both machine and developer. For those arches where the best possible supported machines might be on par with a pentium2 300mhz box, the machine time becomes almost ridiculous. Now, consider the mips arch. As I insinuated above, the fastest of our supported machines really isn't a speed demon. However, there is even *more* complexity with mips. We support both big endian *and* little endian configurations across *multiple* ABIs. This makes testing even more difficult and tedious. I can only speak for myself, but I always strived to make sure anything I ever keyworded worked on *both* our standard 32-bit ABI, and the more experimental n32 (for simplicity, it is a quasi 64-bit ABI with a lot of funkiness). The compile time required for all this testing is ridiculous. It might take two weeks or longer to get something very large compiled (accounting for compile failures and other unforeseen stuff) on the machines I had available. Other developers are similarly constrained by the speed of their machines. Again, not an excuse, but just a fact of how things are. If I had infinite time to work on Gentoo, this would not be an issue. I fully admit that for pretty much the entire past year, I have not had time to do any of this, so I have slacked, and is the reason that I have ultimately retired. It seems like time constraints have similarly affected the rest of
Re: [gentoo-dev] Slacker archs
Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 01:00:12PM +0100, Francesco Riosa wrote: Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard mkay, but sometimes is _really_ difficult, missing flameeyes and keep geoman does not make it easyer. Might be dificult but maybe you could explain how it helps to bash geoman? A good advice before sending any mail like that is to take at least 10 minutes break to cool off and then read it again before sending it. Regards, Bryan Østergaard Bashing Stephen Becker for comments like the one you can found at http://bugs.gentoo.org/show_bug.cgi?id=163795#c6; may survive also the 10 minutes break, even a night of sleep, and bashing is not enough. FYI the offence has been reiterated in #c12 still from geoman, and enforced by ciaranm in c#16, same bug, same attitude. Regards, Francesco Riosa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Mon, 19 Feb 2007 20:21:49 -0800 Brian Harring [EMAIL PROTECTED] wrote: Lots of good info Please Brian, make this a monthly. :) Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] app-admin/gkrellm + x11-plugins/gkrell* stuff needs a maintainer
Jakub Moc wrote: The maintainer has been MIA for quite some time and has a retirement bug open, so the bugs are piling up. Please, have a look at the tracker Bug 165185 if you are interested in taking over this. Basically, gkrellm-1* and ebuilds that depend on it need to be removed (Bug 151446), couple of version bumps and couple of other bugs that need some loving. Well, no one else has taken this yet, so I suppose I will, since I still use the beast :) Not sure what herd I should throw it/them in, though, as most of these packages (er, the ones that even *have* a metadata.xml) have 'no-herd' in them... Maybe 'desktop-dock' is most appropriate? -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
[gentoo-dev] Re: let's clear things up (was Slacker archs)
Stephen P. Becker wrote: All of that said, how about we clear up all of the misinformation about how arch keywording really works, how deps get wrongly dropped, and then explain why mips has generally fallen behind. This isn't an excuse, but is merely a statement of facts which describe the situation. Thanks for the clear explanation of the process; it helps to put this in context for non-devs. snip loads of stuff i'm not qualified to comment on All of this has gotten us to the current situation, where ebuild maintainers are really pissed off at the mips team, and where the mips team is pissed off at ebuild developers for breaking our tree. This is why I get so mad sometimes. Anyone knows me knows that I have *consistently* screamed at people for breaking arch deps (rather than just being an asshole because I'm retiring, as a certain group seems to think). I would much rather have something that I know has been tested in the tree, rather than expend unnecessary and unavailable time to answer to every single security bug. Um not being rude, but why do you think screaming at people is a good way to work? Personally it switches me right off, and i find it hard not to flip the `bozo bit' on someone who carries on like that. Normally a day or two is sufficient for me to work out why that person was being rude to me (eg on irc ;) or at least what they were trying to say. It has never been enough for me to accept the way they said it mind; I just try to bear in mind that they have issues. Considering all that I have said above, it was no surprise that I got a bit irritated by bug #163795. However, I will say that I merely started out by saying it would have been nice for Diego to actually attempt to contact one of us on irc for a quick chat before dropping mips from all of KDE. His notoriously short fuse caused that discussion to rapidly proceed to all-out flame. I don't know either of you. What I do know is you called him a very offensive term (and saying someone is like something is just the same imo) and in the context of that discussion you were out of order. Period. TBH I don't care what discussion went on prior- imo ppl should be polite and professional. (If nothing else, it shows a real lack of imagination to resort to cuss-words. ;) In my experience when I've wanted to mouth off (not on gentoo) I've tried to make myself: read, take a break and re-read. Typically by expressing my concerns in better language, I can make my point far more effectively. snip Instead of being constructive, Diego resorted to outright preemptive harassing, which I believe to be a direct result of sour grapes from bug #163795. That would be the bug above where you called him a dick? `Sour grapes'?! I don't want to get into the whys and wherefores. I'd just like to say to all devs: PLEASE BE POLITE. It doesn't cost you anything except thinking time which will make your case _better_. I know it's hard for those of you who believe that Diego's shit smells like roses, but he was harassing an arch developer who was only trying to do his job correctly. I took exception, so I screamed at Diego as I have many other people during my time in Gentoo (yes, shocking as it may be, I have called people twats and fuckheads without them quitting as a result). And frankly that's just bad form. The fact that ppl stuck around doesn't say one iota about you or your methods; it speaks far more to their motivation. And let's face it- we all love gentoo. Or why would ciaran and you still be posting to bugs and dev-ml? Why not just fork off? Apparently that was just too much for him, so not only did he quit, but he attempted to blackmail devrel into firing me instantly. Perhaps, I should have been slightly less blunt with him, but I stand by my comments. I do not feel I was wrong to tell him off for harassing eroyf. Ah but that's not what you did, is it? If you are seriously taking the position that you stand by your rude, unprofessional manner then TBH I'm glad you're retiring, for gentoo's sake. And while I understand kloeri's statements on the blog, I don't get why you've gotten away with calling people twats and fuckheads. I can only put it down to devrel overwork. Now this is just my opinion and not fact, but Diego was merely looking for an excuse to quit, so don't blame me. I didn't force him to quit, he did that of his own free will. Anyone who knows Diego knows that he has been talking of quitting for a long time now. If not me, he would surely have found another excuse, but whatever. What is done is done. I indeed have retired, so those of you who are so upset and offended that I am still around can sleep a little easier at night knowing that Satan^H^H^H^H^HGeoman won't be screaming at you for doing stupid things any longer. Frankly I value your and ciaranm's input *when you are polite* but the rest of the time it just leaves a bad feeling in my mouth, even tho it's nothing
EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 03:11:20PM +, Steve Long wrote: Before you go- were you working on EAPI? I've been waiting ages on that.. No, that's spb's project (with apparent help from ciaranm). http://cia.navi.cx/stats/project/PMS Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Honestly, way too much is riding on it being completed; some form of tracking is needed (yes it's annoying, but there are still too many arguements over is portages behaviour the standard?). ~harring pgpVUYKM0jApE.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Feb 20, 2007 at 03:11:20PM +, Steve Long wrote: | Before you go- were you working on EAPI? I've been waiting ages on | that.. | | No, that's spb's project (with apparent help from ciaranm). | http://cia.navi.cx/stats/project/PMS | | Possible they've gone and shifted the name (or disabled | notification); either way, think it's probably worth getting a status | update on it in council this coming month. The offer of we'll let council people read it if they promise not to let anyone else get their hands on it is still open. However, in the interests of it ever getting finished, we have to ensure that certain people don't get their hands on it or we'll have to spend all our spare time arguing over pointless nonsense. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Slacker archs
On Mon, 19 Feb 2007 20:21:49 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Feb 20, 2007 at 01:35:32AM +, Ciaran McCreesh wrote: | It is widely perceived that Gentoo has a huge problem with slacker | archs cluttering up the tree and making maintainers' work harder. | Clearly, something needs to be done about this. | | I think the first step is to establish what all the problem | architectures are. We all know that mips is by far the worst | offender, but by how much? Rather than speculating wildly, I | decided to make use of adjutrix and wc to find out. So, here we | have a table showing just how much mips is a slacker arch: | | Lies, Damn Lies, and Statistics. Exactly my point. | As expected, supporting minority archs is leading to tree-wide bloat | and huge initial rsync times for users. Clearly something has to be | done to protect Gentoo from those useless minority archs! I mean, | how many users do we *really* have using amd64 or x86? | | Actually digging into the data rather then doing the lies, damn | lies, and statistics approach shows a pattern of mips having a large | % of their stable packages lagging the others. Which isn't at all relevant when it comes to the question of causing tree bloat. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Slacker archs
On Tue, Feb 20, 2007 at 03:52:07PM +, Ciaran McCreesh wrote: On Mon, 19 Feb 2007 20:21:49 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Feb 20, 2007 at 01:35:32AM +, Ciaran McCreesh wrote: | It is widely perceived that Gentoo has a huge problem with slacker | archs cluttering up the tree and making maintainers' work harder. | Clearly, something needs to be done about this. | | I think the first step is to establish what all the problem | architectures are. We all know that mips is by far the worst | offender, but by how much? Rather than speculating wildly, I | decided to make use of adjutrix and wc to find out. So, here we | have a table showing just how much mips is a slacker arch: | | Lies, Damn Lies, and Statistics. Exactly my point. | As expected, supporting minority archs is leading to tree-wide bloat | and huge initial rsync times for users. Clearly something has to be | done to protect Gentoo from those useless minority archs! I mean, | how many users do we *really* have using amd64 or x86? | | Actually digging into the data rather then doing the lies, damn | lies, and statistics approach shows a pattern of mips having a large | % of their stable packages lagging the others. Which isn't at all relevant when it comes to the question of causing tree bloat. Tree bloat is commonly defined as crap packages hanging around, crap versions. Arches trailing behind in stabling means that their *are* older versions that can't be punted, which frankly, is inducing 'tree bloat'. Regardless, data was presented as see, mips isn't behind; which... isn't the case as your own data shows. ~harring pgpyPtYgJoh6W.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 03:49:56PM +, Ciaran McCreesh wrote: On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Feb 20, 2007 at 03:11:20PM +, Steve Long wrote: | Before you go- were you working on EAPI? I've been waiting ages on | that.. | | No, that's spb's project (with apparent help from ciaranm). | http://cia.navi.cx/stats/project/PMS | | Possible they've gone and shifted the name (or disabled | notification); either way, think it's probably worth getting a status | update on it in council this coming month. The offer of we'll let council people read it if they promise not to let anyone else get their hands on it is still open. I can understand wait until we've got something to show; that's fairly standard- that's about the only case I consider valid however. So... how far a long are they? Further, since this *is* something gentoo needs, when will it potentially be finished? We've been told repeatedly it's being worked on, and it's referred to as if it's almost finished. In light of that, don't really see any reason for the council to *not* get a status update on it. However, in the interests of it ever getting finished, we have to ensure that certain people don't get their hands on it or we'll have to spend all our spare time arguing over pointless nonsense. What, like the existing portage devs? Flamewar aside, it's a simple request; can the council please look into it. If this is the route to go (ie, closed development and they're doing it), fine, but I'm requesting folks take a look at it, see if it's progressing. If it's not, then time to find another way to get it done. ~harring pgpFY81jVDzjh.pgp Description: PGP signature
Re: [gentoo-dev] Slacker archs
On Tue, 20 Feb 2007 08:09:27 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Regardless, data was presented as see, mips isn't behind; which... | isn't the case as your own data shows. As my own data shows, mips is not behind in absolute terms. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 08:13:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: | So... how far a long are they? Better to say what we don't have: * descriptions of all those pesky little helper programs. * clarity and detail for certain sections. | Further, since this *is* something gentoo needs, when will it | potentially be finished? We've been told repeatedly it's being | worked on, and it's referred to as if it's almost finished. It will be finished when it's ready. | However, in the interests of it ever getting finished, we have to | ensure that certain people don't get their hands on it or we'll | have to spend all our spare time arguing over pointless nonsense. | | What, like the existing portage devs? Access is open to individual people who ask for it, if we think that a) they'll be useful rather than just going around attempting to sabotage the thing and b) they won't give it to the wrong people. | Flamewar aside, it's a simple request; can the council please look | into it. If this is the route to go (ie, closed development and | they're doing it), fine, but I'm requesting folks take a look at it, | see if it's progressing. | | If it's not, then time to find another way to get it done. *shrug* It's not so much about getting it done as having something decent when it is done. For it to be useful, it has to be quality, not wiki. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Slacker archs
On Tue, 20 Feb 2007 11:46:32 +0100 Francesco Riosa [EMAIL PROTECTED] wrote: | Better protect gentoo and it's developer, especially the more active | ones from the gravitational waves of those few, very annoying | satellites. Then it will be possible to actually work to the rest. You mean the developers who try to blackmail devrel into firing people they don't like? The developers who go around abusing arch teams at every given opportunity because they won't do exactly what that person wants when he wants it? The developers who manage to make a huge deal out of fixing up some small package by blogging about it incessantly instead of doing real work? The developers who resort to childish personal attacks like misspelling someone's name whilst skipping all factual content in their replies? The developers who refuse to handle bugs submitted by people they don't like? I agree entirely. Gentoo does need to be protected from those kinds of people. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Slacker archs
On Tue, 20 Feb 2007 16:22:46 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 08:09:27 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Regardless, data was presented as see, mips isn't behind; which... | isn't the case as your own data shows. As my own data shows, mips is not behind in absolute terms. Only a Sith deals in absolutes -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] let's clear things up (was Slacker archs)
On Tue, 2007-02-20 at 08:11 -0500, Stephen P. Becker wrote: On Tue, 20 Feb 2007 01:35:32 + Ciaran McCreesh [EMAIL PROTECTED] wrote: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. snip Wow, I almost don't know where to begin. The amount of FUD, misinformation, and outright lies floating around all of this bullshit is astounding. snip again I'd like to chime in here, if I may, with some personal experience. I've been involved with arch keywording from both sides (being in the amd64 herd, and being the current gnome lead), and I have to say that it's definitely blown out of proportion. Yes, keyword bugs slip through the cracks. Some of my gnome keyword bugs hang around forever; sometimes, in my bug sweeps for amd64, I find keyword bugs that have been hanging around forever. It happens. However, there have been a number of cases recently for gnome where we wanted to punt old versions of gnome. We like to only keep 1-2 old versions around, so we remove whole sets of packages every 6-8 months. In this, we're probably close to unique. Many of these are newest keyworded versions on some arch or other. Generally, all the arches have been responsive to the problem, either by keywording newer versions, or by agreeing to drop keywords. Again, there's the odd case; but that seems to mostly be oversight. Summary: I don't see a real problem with any arch, mips included, either from the arch side or from the gnome side. There's more gnome cruft in the tree from us failing to clean intermediate versions up than there is from slacker arches. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Tue, Feb 20, 2007 at 02:29:32PM +0100, Francesco Riosa wrote: Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 01:00:12PM +0100, Francesco Riosa wrote: Bryan Østergaard ha scritto: On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard mkay, but sometimes is _really_ difficult, missing flameeyes and keep geoman does not make it easyer. Might be dificult but maybe you could explain how it helps to bash geoman? A good advice before sending any mail like that is to take at least 10 minutes break to cool off and then read it again before sending it. Regards, Bryan Østergaard Bashing Stephen Becker for comments like the one you can found at http://bugs.gentoo.org/show_bug.cgi?id=163795#c6; may survive also the 10 minutes break, even a night of sleep, and bashing is not enough. FYI the offence has been reiterated in #c12 still from geoman, and enforced by ciaranm in c#16, same bug, same attitude. I honestly find it offensive to break archs likewise. But while we can all decide to continue to be dicks over this I still completely fail to see how it *helps* solve anything. And I guess we want to solve the problems instead of just continuing the flames, right? So please ignore previous flames and lets focus on the actual problems. Problems like MIPS being behind on some packages and latest stable or testing version getting dropped for archs quite often. That's something I'd like to see people spending their time on fixing instead of just adding fuel to the flames. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Right now I'm placing a higher priority on getting a degree. It'll be done when it's done, which is not now. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
Hi Ciaran, Can you please refrain from making inflammatory accusations in your posts? This is not a forum for airing personal grievances, and they do not serve any purpose besides encouraging others to do the same to you - as you have discovered. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 11:46:32 +0100 Francesco Riosa [EMAIL PROTECTED] wrote: | Better protect gentoo and it's developer, especially the more active | ones from the gravitational waves of those few, very annoying | satellites. Then it will be possible to actually work to the rest. You mean the developers who try to blackmail devrel into firing people they don't like? The developers who go around abusing arch teams at every given opportunity because they won't do exactly what that person wants when he wants it? The developers who manage to make a huge deal out of fixing up some small package by blogging about it incessantly instead of doing real work? The developers who resort to childish personal attacks like misspelling someone's name whilst skipping all factual content in their replies? The developers who refuse to handle bugs submitted by people they don't like? I agree entirely. Gentoo does need to be protected from those kinds of people. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
On Tue, 20 Feb 2007 10:12:26 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | Can you please refrain from making inflammatory accusations in your | posts? This is not a forum for airing personal grievances, and they do | not serve any purpose besides encouraging others to do the same to you | - as you have discovered. So, wait... It's ok for people to post wild conspiracies blaming the whole Diego thing on me, but it's not ok to post factual material in response? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 05:22:59PM +, Stephen Bennett wrote: On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Right now I'm placing a higher priority on getting a degree. It'll be done when it's done, which is not now. Thanks for the clarification (and just to be clear, I am not being sarcastic and I do truly mean thank you for the info). Council- y'all were after getting this finished as far as I know, perhaps you could discuss intentions? ~harring pgp3Yo7MxdA7v.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Am Dienstag, 20. Februar 2007 18:33 schrieb Brian Harring: On Tue, Feb 20, 2007 at 05:22:59PM +, Stephen Bennett wrote: On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Right now I'm placing a higher priority on getting a degree. It'll be done when it's done, which is not now. Council- y'all were after getting this finished as far as I know, perhaps you could discuss intentions? Why? There is work done on this, and there will be further work being done. Several council member have access to it - including me - and are quite confident about what is already done. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
First, by directing this email at you, I am not in any way suggesting that others are justified in attacking you or that you are at fault in a technical sense. That being said, it's generally futile to bitterly demand that people treat you with respect. It doesn't work. So, that means that if you are falsely accused of something, and you post an equally accusatory or biting response, you have now become part of the problem by descending to their level, and it's no longer clear that only one party is at fault. The best strategy is to just be genuinely considerate and bambi-like even when people don't deserve it, and hope that it catches on. People tend to respond in kind. You have reaped a bit of a whirlwind with your regularly caustic/sarcastic posts, and I am sure that this has contributed to people perceiving you in a negative light and instinctively responding to you in a negative way. You also tend to keep the flame alive with your very good recollection of the faults of others. It really isn't an issue of who is right or wrong, but an issue of exercising basic social graces so that people aren't continually out to get you. It's not about changing the subject, but rather discussing the subject without engaging in biting dialogue. Really, I think the root of it is that your frequent caustic sarcasm is often interpreted as a personal attack or put down by nearly all cultures of the world. Sarcasm doesn't work well over email, and it's easily interpreted in a way that you might not intend. So from the perspective of many, right or wrong, it is you who is starting the fight. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 10:12:26 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | Can you please refrain from making inflammatory accusations in your | posts? This is not a forum for airing personal grievances, and they do | not serve any purpose besides encouraging others to do the same to you | - as you have discovered. So, wait... It's ok for people to post wild conspiracies blaming the whole Diego thing on me, but it's not ok to post factual material in response? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 10:22:14 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Perhaps not all of the council; distinctly recall diego pushing about | it though. Quick look through council logs, robbat2 was asking about | timeline also (jan. meeting specifically). You've gotta ask *why* certain people are so keen on pushing it through... Perhaps if they explained why they needed it in such a hurry we would prioritise it differently. | Several council member have access to it - including me - and | are quite confident about what is already done. | | The question was specifically in regards to timelines; completion so | that ongoing paludis vs pkgcore vs portage crap can be put to rest. *shrug* I don't see PMS as being viable until there's a fully conformant independent implementation, personally. So that more or less means that for me, PMS will become a priority at around the same time that Paludis 1.0_pre is released. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran, Admittedly, I'm new to this PMS thing so in many cases I'm speaking from a position of ignorance, but I guess I need to jump in somewhere I think that standardization is a good thing and interoperability between paludis, portage, pkgcore and others is something we should strive for. If at all possible, I think that this standardization effort should be multi-lateral in the sense that Gentoo and pkgcore are also active participants in the standardization process. Also, I don't think that the council itself needs to be involved directly, as a standards/spec project can be created and worked on, and the conformance of Portage to this standard can be measured, and if desired Portage developers can tweak portage so that it is more conformant to this standard. This can be done voluntarily by all parties, as they deem it useful. The goal would be to have the ability to measure a package manager's behavior against a known standard, rather than force a certain package manager to behave a certain way. I would expect that the general concern for interoperability within the Gentoo community will encourage package manager developers to work towards resolving any interoperability problems that do exist. I think standardization should focus on real interoperability issues, rather than esoteric technical issues. I think a good way to start would be to create some kind of test/regression suite in the portage tree that can be used to measure the package manager's functionality. Some stuff would be of an obvious pass/fail nature but other things can be couched in more subjective terms - like will unmerge device nodes - yes/no That at least would allow us to measure where we are in terms of interoperability, and identify future areas of improvement. Like I said, I'm just getting familiar with all this but those are my thoughts. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 10:22:14 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Perhaps not all of the council; distinctly recall diego pushing about | it though. Quick look through council logs, robbat2 was asking about | timeline also (jan. meeting specifically). You've gotta ask *why* certain people are so keen on pushing it through... Perhaps if they explained why they needed it in such a hurry we would prioritise it differently. | Several council member have access to it - including me - and | are quite confident about what is already done. | | The question was specifically in regards to timelines; completion so | that ongoing paludis vs pkgcore vs portage crap can be put to rest. *shrug* I don't see PMS as being viable until there's a fully conformant independent implementation, personally. So that more or less means that for me, PMS will become a priority at around the same time that Paludis 1.0_pre is released. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: www-client/mozilla[-bin]
# Raúl Porcel armin76 at gentoo dot org (20 Feb 2007) # Masked for removal 19 Mar 2007, bug 135257, security issues # Replaced by www-client/seamonkey[-bin] www-client/mozilla www-client/mozilla-bin So, amd64 finally stabilized the mono ebuild which doesn't need mozilla, this can be punted. -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 12:19:12 -0700 Daniel Robbins
[EMAIL PROTECTED] wrote:
| I think that standardization is a good thing and interoperability
| between paludis, portage, pkgcore and others is something we should
| strive for. If at all possible, I think that this standardization
| effort should be multi-lateral in the sense that Gentoo and pkgcore
| are also active participants in the standardization process.
Well, Gentoo already is a participant, in that there are a number
of Gentoo developers with access to the document... At this stage, we're
deliberately keeping the numbers down because we want to get it done
rather than spend huge amounts of time arguing with the peanut gallery
(the same approach we took with eselect, the devmanual and Paludis,
rather than the approach taken with portage-ng and Zynot).
| Also, I don't think that the council itself needs to be involved
| directly, as a standards/spec project can be created and worked on,
| and the conformance of Portage to this standard can be measured, and
| if desired Portage developers can tweak portage so that it is more
| conformant to this standard. This can be done voluntarily by all
| parties, as they deem it useful.
The reason the Council is involved is because someone has to give final
approval. This won't be asked for until late on in the process.
| I think standardization should focus on real interoperability issues,
| rather than esoteric technical issues.
The esoteric technical issues are the problem, though. The areas where
there are interoperability problems are the areas where ebuilds are
doing weird things, like relying upon side effects of one
implementation of inherit or trying to manually modify vdb or assuming
that certain variables that contain directory names will not include a
trailing slash. The question is whether the ebuilds are wrong in
expecting to be able to do this, or whether package managers have to
emulate weird quirks in how Portage is currently implemented.
I'll give you a perfect example. Paludis currently includes the
following workaround:
archives = strip_trailing(archives, );
all_archives = strip_trailing(all_archives, );
The reason that this is necessary is because kde-meta.eclass does this:
[[ -n ${A/${TARBALL}/} ]] unpack ${A/${TARBALL}/}
Which means that if a package manager includes trailing spaces in ${A},
the eclass will break. Personally I consider this to be an eclass bug,
but without some standard to back it up there's no concrete answer
either way.
Another example along the same lines (this one's now fixed in the tree,
but it's a good example of weird side effect behaviour): The PHP
eclasses used to set a global scope variable called EXT_DIR based upon
the value of a variable called PHPCONFIG. The PHPCONFIG variable was
set in pkg_setup, and the EXT_DIR variable was used later on. For
Portage as it is currently implemented, this happens to be ok, because
eclasses are re-sourced for every phase. For Paludis this breaks,
because we implement the environment saving that Portage is going to do
at some point to avoid the eclass API problems.
Another example: A certain eclass we all know and love used to use
SLOT=${PVR} and then force uninstalls by overwriting VDB SLOT files
when installing packages. As it happens, Portage doesn't cache those
entries, and because of how it implements cleaning the hack happens to
work. The question is whether ebuilds are allowed to rely upon weird
quirks like that (and, indeed, whether ebuilds should be reading VDB at
all).
Another example: Various ebuilds rely upon the order of items in $A
matching the order in $SRC_URI. This one's arguably useful, but at the
same time it's questionable as to whether it works by fluke.
It's these cases that are the problem, not the generalities. On the one
hand, requiring that package managers implement every Portage quirk
identically is insane, and stops Portage from changing behaviour in the
future. On the other hand, restricting the API to only completely sane
things makes it much harder to code certain ebuilds -- the $A ordering
is one example of this.
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
OK, my initial impression of this is:
1) ebuilds and *especially* eclasses do way too many weird things and
can often depend on idiosyncrasies of portage. The eclass bash scripts
can be quite complex and probably 9 out of 10 (99 out of 100?) times
I'd put the burden of compatibility on the eclass rather than the
package manager, because it's the eclass that's trying to do weird
stuff.
2) to ensure cross-package-manager compatibility, all one would need
to do is document what one can and cannot assume regarding Portage
functionality. I see no harm in having the ebuilds/eclasses assume
less and encourage others to write more robust and compatible ebuild
and eclass functions.
3) I regretfully added eclasses to portage. Although they're useful, I
don't think they ever made sense from an architecture perspective and
are certainly not pretty. Eclasses are nearly ubiquitous now, which is
unfortunate. I can't remember seeing an eclass that I ever liked, even
if the functionality was really useful and everything was
well-written, thought out, documented, etc.
4) Building on 3, I think there are two ways of life in the world of
Portage - either the eclasses control you, or you fight back a bit and
control the growth of eclasses. The eclasses are sort of an
anti-architecture so I think our will should to be imposed on them
rather than the other way around. Otherwise you are in a catch-22
where we are continually adding tons of weird legacy code in the
form of eclasses and this problem of cross-package manager
compatibility will never go away.
Those are my thoughts, anyway...
If you wanted to get me to agree with you by giving me lots of eclass
compatibility issues, then it worked :)
-Daniel
On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 20 Feb 2007 12:19:12 -0700 Daniel Robbins
[EMAIL PROTECTED] wrote:
| I think that standardization is a good thing and interoperability
| between paludis, portage, pkgcore and others is something we should
| strive for. If at all possible, I think that this standardization
| effort should be multi-lateral in the sense that Gentoo and pkgcore
| are also active participants in the standardization process.
Well, Gentoo already is a participant, in that there are a number
of Gentoo developers with access to the document... At this stage, we're
deliberately keeping the numbers down because we want to get it done
rather than spend huge amounts of time arguing with the peanut gallery
(the same approach we took with eselect, the devmanual and Paludis,
rather than the approach taken with portage-ng and Zynot).
| Also, I don't think that the council itself needs to be involved
| directly, as a standards/spec project can be created and worked on,
| and the conformance of Portage to this standard can be measured, and
| if desired Portage developers can tweak portage so that it is more
| conformant to this standard. This can be done voluntarily by all
| parties, as they deem it useful.
The reason the Council is involved is because someone has to give final
approval. This won't be asked for until late on in the process.
| I think standardization should focus on real interoperability issues,
| rather than esoteric technical issues.
The esoteric technical issues are the problem, though. The areas where
there are interoperability problems are the areas where ebuilds are
doing weird things, like relying upon side effects of one
implementation of inherit or trying to manually modify vdb or assuming
that certain variables that contain directory names will not include a
trailing slash. The question is whether the ebuilds are wrong in
expecting to be able to do this, or whether package managers have to
emulate weird quirks in how Portage is currently implemented.
I'll give you a perfect example. Paludis currently includes the
following workaround:
archives = strip_trailing(archives, );
all_archives = strip_trailing(all_archives, );
The reason that this is necessary is because kde-meta.eclass does this:
[[ -n ${A/${TARBALL}/} ]] unpack ${A/${TARBALL}/}
Which means that if a package manager includes trailing spaces in ${A},
the eclass will break. Personally I consider this to be an eclass bug,
but without some standard to back it up there's no concrete answer
either way.
Another example along the same lines (this one's now fixed in the tree,
but it's a good example of weird side effect behaviour): The PHP
eclasses used to set a global scope variable called EXT_DIR based upon
the value of a variable called PHPCONFIG. The PHPCONFIG variable was
set in pkg_setup, and the EXT_DIR variable was used later on. For
Portage as it is currently implemented, this happens to be ok, because
eclasses are re-sourced for every phase. For Paludis this breaks,
because we implement the environment saving that Portage is going to do
at some point to avoid the eclass API problems.
Another example: A certain eclass we all know and love used to use
SLOT=${PVR} and then force
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 14:12:12 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | 1) ebuilds and *especially* eclasses do way too many weird things and | can often depend on idiosyncrasies of portage. The eclass bash scripts | can be quite complex and probably 9 out of 10 (99 out of 100?) times | I'd put the burden of compatibility on the eclass rather than the | package manager, because it's the eclass that's trying to do weird | stuff. Yep. Here's the problem though: How much of the tree is it ok to modify, and how complex are the modifications allowed to be, for the sake of compatibility? The aim with Paludis is to ask for modifications only where it's a hard dried the ebuild / eclass is doing something highly stupid, simply because that's the only way it will be accepted. Even then, some maintainers refuse to make changes to code that works with one particular version of Portage. And until PMS is standardised, there's nothing that can be done to make them do otherwise. | 2) to ensure cross-package-manager compatibility, all one would need | to do is document what one can and cannot assume regarding Portage | functionality. I see no harm in having the ebuilds/eclasses assume | less and encourage others to write more robust and compatible ebuild | and eclass functions. In principle, I agree. In practice, writing robust bash code is a pain in the ass. If it's the case of a couple of lines of hacks in the package manager or a dozen lines of hacks in hundreds of ebuilds, it's simply more practical to impose a weird requirement upon the package manager. | 3) I regretfully added eclasses to portage. Although they're useful, I | don't think they ever made sense from an architecture perspective and | are certainly not pretty. Eclasses are nearly ubiquitous now, which is | unfortunate. I can't remember seeing an eclass that I ever liked, even | if the functionality was really useful and everything was | well-written, thought out, documented, etc. Eh, my objections to eclasses are purely based upon the limitations imposed by Portage (the no API change one). As a general idea they make the tree a lot less complex, and they often move all the package manager dependent hacks into one place... | If you wanted to get me to agree with you by giving me lots of eclass | compatibility issues, then it worked :) Hm. Maybe I should have picked up some of the dodgy ebuild code instead... There's a heck of a lot of that too. It's just that eclass weirdness is easier to find. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 2007-02-20 at 18:29 +, Ciaran McCreesh wrote: | The question was specifically in regards to timelines; completion so | that ongoing paludis vs pkgcore vs portage crap can be put to rest. *shrug* I don't see PMS as being viable until there's a fully conformant independent implementation, personally. So that more or less means that for me, PMS will become a priority at around the same time that Paludis 1.0_pre is released. Are you really saying that you won't be releasing this information until such time as *Paludis* meets it, even though portage/pkgcore may not? Isn't the *point* of this spec to try to bring everyone on the same page? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 16:57:50 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | On Tue, 2007-02-20 at 18:29 +, Ciaran McCreesh wrote: | | The question was specifically in regards to timelines; completion | | so that ongoing paludis vs pkgcore vs portage crap can be put to | | rest. | | *shrug* I don't see PMS as being viable until there's a fully | conformant independent implementation, personally. So that more or | less means that for me, PMS will become a priority at around the | same time that Paludis 1.0_pre is released. | | Are you really saying that you won't be releasing this information | until such time as *Paludis* meets it, even though portage/pkgcore | may not? Isn't the *point* of this spec to try to bring everyone on | the same page? I'm saying that until there is an independent implementation, the specification is worthless and will contain huge numbers of errors. This is standard practice for professional standards, and is the principal difference between, say, Open Document Format and Office Open XML -- the former is a real standard, whereas the latter is a description of how one program operates. Now, if PMS happens to end up being ready before Paludis 1.0, PMS will get released before then. But if Paludis 1.0 ends up being ready before PMS, my and probably others' priorities will switch to getting PMS ready as quickly as sanely possible. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: This is standard practice for professional standards, and is the Now you talk about this, a standard is, in standard practice, the result of a collaborative effort of representing members of the organization(s) that is (are) supposed to adhere to said standard. I believe I don't need then to explain you how far what happens around PMS is from standard practice. You say you want to avoid endless discussions in the interest of getting it finished. Now, if your work is that good, why would there be any discussions about it? If it's not good enough, why wouldn't you let us talk about it and make it better? Also, if it goes in the wrong direction, one that Gentoo devs won't follow, what's the point in finishing it? Denis. -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 23:47:04 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: | On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: | This is standard practice for professional standards, and is the | | Now you talk about this, a standard is, in standard practice, the | result of a collaborative effort of representing members of the | organization(s) that is (are) supposed to adhere to said standard. I | believe I don't need then to explain you how far what happens around | PMS is from standard practice. You know that real standards aren't a free for all, right? They're usually written by a small group, and then commented on by interested parties when they're already well into being written. Which is exactly what we're doing... | You say you want to avoid endless discussions in the interest of | getting it finished. Now, if your work is that good, why would there | be any discussions about it? Because there are a lot of people with opinions out there, and they will all start saying things like well it would be better if things were like $blah, so you should change it to say $blah. Have a look at the amount of noise that comes up any time this kind of discussion takes place on this list... Heck, have a look at the number of people already trying to comment upon how the standard is being written without having seen it... | If it's not good enough, why wouldn't you let us talk about it and | make it better? We will let you (for values of you where your opinion is useful and relevant) discuss it when it is at an appropriate stage. | Also, if it goes in the wrong direction, one that | Gentoo devs won't follow, what's the point in finishing it? It isn't going in the wrong direction. The third parties who have access to it will tell you that. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
[gentoo-dev] removal of winex/winex-cvs ?
Hi, Today I saw that we still have the fake-ebuilds of winex/winex-cvs (just basically telling the user they've been removed). I think they can die? Treecleaers? -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] pgpxaLxHSoUrv.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran, Is there any way that the public can view the PMS spec that you have created so far? I am not totally familiar with how you are going about developing PMS, but based on some of your comments in this thread I'm a little bit concerned. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 23:47:04 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: | On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: | This is standard practice for professional standards, and is the | | Now you talk about this, a standard is, in standard practice, the | result of a collaborative effort of representing members of the | organization(s) that is (are) supposed to adhere to said standard. I | believe I don't need then to explain you how far what happens around | PMS is from standard practice. You know that real standards aren't a free for all, right? They're usually written by a small group, and then commented on by interested parties when they're already well into being written. Which is exactly what we're doing... | You say you want to avoid endless discussions in the interest of | getting it finished. Now, if your work is that good, why would there | be any discussions about it? Because there are a lot of people with opinions out there, and they will all start saying things like well it would be better if things were like $blah, so you should change it to say $blah. Have a look at the amount of noise that comes up any time this kind of discussion takes place on this list... Heck, have a look at the number of people already trying to comment upon how the standard is being written without having seen it... | If it's not good enough, why wouldn't you let us talk about it and | make it better? We will let you (for values of you where your opinion is useful and relevant) discuss it when it is at an appropriate stage. | Also, if it goes in the wrong direction, one that | Gentoo devs won't follow, what's the point in finishing it? It isn't going in the wrong direction. The third parties who have access to it will tell you that. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 17:22:07 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | Is there any way that the public can view the PMS spec that you have | created so far? They can ask spb. If spb is convinced that they have something useful to contribute at this stage, and that they won't do something silly like sticking it where anyone can view it, he'll give them read access. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 17:22:07 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: Is there any way that the public can view the PMS spec that you have created so far? I am not totally familiar with how you are going about developing PMS, but based on some of your comments in this thread I'm a little bit concerned. At this stage, individuals can ask for a copy, or for read access to the repository, if we think that their input is likely to be more productive than distracting. Once it is sufficiently complete, read access will be opened to the public and drafts will likely be sent to -dev for comment. For the same reasons that the repository isn't public, though, such drafts are currently given out on the understanding that they won't be distributed further. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] removal of winex/winex-cvs ?
On Tuesday 20 February 2007, Hanno Böck wrote: Today I saw that we still have the fake-ebuilds of winex/winex-cvs (just basically telling the user they've been removed). I think they can die? done -mike pgpmJFNYVSv0H.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Brian Harring wrote: [snip] In light of that, don't really see any reason for the council to *not* get a status update on it. We get status updates on it. it's pretty much it's not done, we don't want to show you every month. It's one of the things I intend to bring up at the march meeting. [snip] -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 18:58:48 -0800 Mike Doty [EMAIL PROTECTED] wrote: | Brian Harring wrote: | [snip] | In light of that, don't really see any reason for the council to | *not* get a status update on it. | | We get status updates on it. it's pretty much it's not done, we | don't want to show you every month. It's one of the things I intend | to bring up at the march meeting. You're ignoring our offer to show you what's done, eh? Fair enough. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran McCreesh wrote: On Tue, 20 Feb 2007 18:58:48 -0800 Mike Doty [EMAIL PROTECTED] wrote: | Brian Harring wrote: | [snip] | In light of that, don't really see any reason for the council to | *not* get a status update on it. | | We get status updates on it. it's pretty much it's not done, we | don't want to show you every month. It's one of the things I intend | to bring up at the march meeting. You're ignoring our offer to show you what's done, eh? Fair enough. I was never offered this offer. -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Slacker archs
Bryan Østergaard wrote: On Tue, Feb 20, 2007 at 11:46:32AM +0100, Francesco Riosa wrote: Snipped silly inflamatory bit Ciaran McCreesh ha scritto: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. It's even more perceived that there are a couple of satellite people who are working very strongly and sometimes (sadly) successfully to create an un-healty environment for developers and users. Personally I would mention you Caranm, beu and geoman. Please stop the personal attacks. They serve absolutely no purpose other than poisoning the developer community further. Regards, Bryan Østergaard if the shoes fit, wear them -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Stephen Bennett wrote: At this stage, individuals can ask for a copy, or for read access to This stage is usually called early draft, the editor puts every input he deems useful in the first document and then he sends it for discussion once he is happy with it. So, no problems on this practice once we know that we are at the early draft phase of a quite large document. The perception were that the document is quite in a further stage, say pre-release, so people was expecting to see it and comment on it. Now, I think we could wait even a bit more, but there is much interest in seeing it complete so is natural that more people are willing to help speeding up at least the first release. I agree with Ciaran that would be better have at least a working sample implementation while discussing it, I won't call it 1.0pre again because it gives a wrong perception. I'm looking forward to see the spec and the initial implementation ^^ lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 07:10:51PM -0800, Mike Doty wrote: I was never offered this offer. If you read the emails by Ciaran you will see that he already offered the council members access to read the draft. -- Alexander Færøy Bugday Lead Alpha/IA64/MIPS Architecture Teams User Relations, Quality Assurance pgpA1bRB6LYYR.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: You know that real standards aren't a free for all, right? They're usually written by a small group, and then commented on by interested parties when they're already well into being written. Which is exactly what we're doing... You forgot to mention that the small group is either a subset of the interested parties or is commissioned by them. Which doesn't appear to be the case here. Because there are a lot of people with opinions out there, and they will all start saying things like well it would be better if things were like $blah, so you should change it to say $blah. Which means exactly what it means. You would settle for something mediocre? We are here to help you, Ciaran. Have a look at the amount of noise that comes up any time this kind of discussion takes place on this list... Well, it seems that many devs believe there is something wrong in the way PMS is conducted. Their observation isn't based on the result itself, but on the status (or rather non-status) and behavior of some of the project members. Some, even, question the intentions. The noise you hear is the alarm that's ringing. Denis. -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] [RFC] trigger to stop Manifest1 generation (bug #167667)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://bugs.gentoo.org/show_bug.cgi?id=167667
In order so smoothly and transparently drop Manifest1, it seems like
we'll need a toggle built into portage so that it automatically
drops Manifest1 when appropriate. The need for this toggle will be
critical when we make the move to drop Manifest1 from the gentoo-x86
cvs tree.
Please review the attached patch for bug #167667 which triggers the
dropping of Manifest1 via an empty file named
${PORTDIR}/manifest1_obsolete. The file is repo/overlay specific,
so various overlays can keep or drop Manifest1 depending on whether
that file has been added to the overlay.
In order to drop manifest1 from cvs, we will also nned to add
support to repoman so that it handles Manifest1 digest files
correctly. Perhaps it should automatically remove them from cvs?
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.2 (GNU/Linux)
iD8DBQFF23Hm/ejvha5XGaMRAvZfAKDLiQdrEmuBz5OykDvSTfqBxDqUuwCeIcYR
J7MbsD0Ac9jcqm13nv3ujT0=
=H2Vb
-END PGP SIGNATURE-
Index: pym/portage.py
===
--- pym/portage.py (revision 6016)
+++ pym/portage.py (working copy)
@@ -2692,8 +2692,11 @@
writemsg(!!! Invalid SRC_URI for '%s'.\n %
cpv, noiselevel=-1)
del e
return 0
+ mytree = os.path.dirname(os.path.dirname(mysettings[O]))
+ manifest1_compat = not os.path.exists(
+ os.path.join(mytree, manifest1_obsolete))
mf = Manifest(mysettings[O], mysettings[DISTDIR],
- fetchlist_dict=fetchlist_dict)
+ fetchlist_dict=fetchlist_dict,
manifest1_compat=manifest1_compat)
# Don't require all hashes since that can trigger excessive
# fetches when sufficient digests already exist. To ease
transition
# while Manifest 1 is being removed, only require hashes that
will
Index: pym/portage_manifest.py
===
--- pym/portage_manifest.py (revision 6016)
+++ pym/portage_manifest.py (working copy)
@@ -425,7 +425,8 @@
else:
distfilehashes = {}
self.__init__(self.pkgdir, self.distdir,
- fetchlist_dict=self.fetchlist_dict, from_scratch=True)
+ fetchlist_dict=self.fetchlist_dict, from_scratch=True,
+ manifest1_compat=self.compat)
for pkgdir, pkgdir_dirs, pkgdir_files in os.walk(self.pkgdir):
break
for f in pkgdir_files:
