Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage This is the solution that solves most problems. Going with something else is just a way of doing it wrong for the sake of it. - ferdy pgpfhEMRKGC35.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Thu, Oct 16, 2008 at 10:01:40PM +0100, Steve Long wrote: Ciaran McCreesh wrote: On Wed, 15 Oct 2008 20:28:43 +0100 Steve Long [EMAIL PROTECTED] wrote: Fernando J. Pereda wrote: A big gain in the context of ebuilds and source packages. Well done. Yes, almost as important as not sourcing any ebuilds, so let's all stick an EAPI extension on the end of the filename. If you really think that EAPI as an extension has anything to do with performance You mentioned performance a few times in that lovely thread when it got shot down, I believe in the context of metadata generation: Performance hit (when discussing an alternative) [1] The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. [2] It's several more directory reads. This is a measurable performance hit [3] Are you now saying performance doesn't matter? No, performance is just a side effect it has never been part of the motivation of the GLEP. You are the only fighting over stupid pico optimizations. - ferdy pgpa4DJ4UDaap.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote: Here you go (this is on an old machine, so you'll get much quicker times if you try this at home): A big gain in the context of ebuilds and source packages. Well done. - ferdy pgprSLpWrpb0H.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Wed, Oct 15, 2008 at 08:51:32PM +0100, Ranjit Singh wrote: This is a purely stylistic issue, same as the braces with variable expansions. See my other posts. Your other posts only show that this is, indeed, a personal stylistic issue. And a pointless one, too. - ferdy pgpY8zl8tdvKz.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote: David Leverton wrote: 2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers? Well, it's not much different from the existing file extension logic that's already built into the unpack function. I think what really matters is whether or not the majority of people see it as a useful extension. I'm wondering why would one fetch a tarball instead of using git.eclass which is much better for both upstream and users (in terms of bandwidth and resources usage). - ferdy pgp4InFxofziD.pgp Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 18:03, Luca Barbato wrote: trunk = .live nope it would resolve as foo_pre1 - meaningless. So your proposal is unable to handle that case, right? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 18:23, Luca Barbato wrote: Fernando J. Pereda wrote: nope it would resolve as foo_pre1 - meaningless. So your proposal is unable to handle that case, right? You are forced to put a version, that's all. Which doesn't always make sense so we are back to 9 versions. I don't consider this an improvement over the current situation. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? (btw they are single packages, emerge =python- works as should) So what was your proposal all about? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 22:18, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? mainline glibc usually requires you to fix it or the rest of the world... What? (btw they are single packages, emerge =python- works as should) So what was your proposal all about? Doing something more. How is using versions 'doing something more'? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 13 Jun 2008, at 10:43, Luca Barbato wrote:
* What's the filename for live ebuild for SVN trunk/? What about
foo-${version inside trunk}.live?
And when trunk is unversioned?
Upstream has an issue, still you know which is the version they aim.
Wrong. Your GLEP has an issue because it isn't able to cover a real-
world case. See the pu branch in Git.
- ferdy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On 13 Jun 2008, at 11:01, Patrick Lauer wrote: Ciaran McCreesh wrote: On Fri, 13 Jun 2008 09:30:54 +0530 Arun Raghavan [EMAIL PROTECTED] wrote: And why do you have to be plain insulting about it? Nobody can magically spot every single bug in any piece of code presented to them. In fact it's why the given enough eyes ... adage is one of the bases of open source development. Which is why any responsible person ensures good test coverage. Just to pour some oil on the flames - Then don't do it. You are doing a very bad marketing for the pkgcore guys with your whinnings. Y'all are aware that paludis can't parse a valid make.conf and does ignore package.keywords at times, yes? Test case is: FEATURES=strict # test and stricter fail in make.conf ... if you had the tests you claim others lack that would have been fixed a long time ago. Yes, we are aware of that bug in a feature we consider highly experimental. You are amusing... - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On 13 Jun 2008, at 11:16, Patrick Lauer wrote: Then don't do it. You are doing a very bad marketing for the pkgcore guys with your whinnings. I'm not a pkgcore guy. If anything I'm a portage supporter. That I accidentally host pkgcore.org doesn't mean I'm one of them. Were you able to read English you'd have noted that I implicitly excluded you from the pkgcore guys in that sentence. Yes, we are aware of that bug in a feature we consider highly experimental. Hmm, I'd have guessed config files are moderately relevant. And why don't y'all fix a bug like that? First you insult others for not doing tests, then you show a lack of tests and are proud of it. Augh. Use of Portage configuration files will lead to sub-optimal performance and loss of functionality. Full support for Portage configuration formats is not guaranteed; issues should be reported via trac. That's the pretty nice warning. Full support is not guaranteed. We do take sane patches, however. Stop flaming, please. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On 13 Jun 2008, at 12:18, Nirbheek Chauhan wrote: We're writing a spec that's somewhat like Portage, but where it breaks Paludis, we prefer to get Portage to change it's behaviour instead. Don't crib about this however. We could just have easily have created a whole new spec which broke Portage completely. Care to give an example instead of FUDing? Paludis is written to match PMS, not the other way around. And when PMS changes, Paludis is changed to reflect such changes. Don't be childish. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]
On 12 Jun 2008, at 04:16, Brian Harring wrote: Why the exherbo/paludis/PMS folk decided to go this route to report, I'm not quite sure aside from assuming they're just griefers. s-exherbo/paludis/PMS-pkgcore-g and: http://fpereda.wordpress.com/2008/05/03/on-cooperating-and-paludis-vulnerability/ Except this one wasn't a lie. I wish there were more cooperation between all of us. But looks like it is impossible with some of your people. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
On 11 Jun 2008, at 13:11, Brian Harring wrote: On Wed, Jun 11, 2008 at 03:06:17AM +, Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Reiterating the early request, I'd like the council to please discuss the current status of PMS, if the running of it satisfys the councils requirements of a *neutral* standard, if the proposed spec actually meets said standards, and if said spec is actually going to be approved sometimes this side of '09. Effectively, we've watched it essentially progress into a standard that effectively only the paludis folk are adherent to (if in doubt, ask portage folk, my sending this mail is indicative of the pkgcore standpoint)- it's about time the council comment upon it in light of the general view. Did you send patches for those parts you don't agree with? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On 10 Jun 2008, at 12:30, Rémi Cardona wrote: Ciaran McCreesh a écrit : picard_facepalm.jpg I don't think any of us are completely thrilled by either proposals, but the EAPI-in-a-separate-file does have the potential for more flexibility, ie package-wide EAPI. And it does keep filenames simple enough. And it is not backwards compatible. - ferdy-- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
On 10 Jun 2008, at 13:13, Luca Barbato wrote: but I dislike empty theories or hardly searched corner cases that could be avoided with half of the effort necessary to get there. Yoy mean like adopting GLEP55, right? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On 10 Jun 2008, at 15:33, Joe Peterson wrote: Luca Barbato wrote: Check if exists a line EAPI=*$, if does and the rest of the string matches an understood eapi, go on sourcing, otherwise ignore/mask it... And placing it out-of-band (like # EAPI=...) avoids any sourcing errors, makes parsing faster, etc. No, it doesn't make parsing faster. Had you bothered to profile any package manager you'd know that. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On 10 Jun 2008, at 15:46, Joe Peterson wrote: Also, I'm not sure reading XML is a problem at all - python has good libs for this already. Reading XML files is easy, but it makes certain codepaths much much slower. Not a good 'feature'. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On 10 Jun 2008, at 15:48, Luca Barbato wrote: Fernando J. Pereda wrote: No, it doesn't make parsing faster. Had you bothered to profile any package manager you'd know that. Do you have any number to share? What number are you interested in? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On 10 Jun 2008, at 16:14, Ciaran McCreesh wrote: On Tue, 10 Jun 2008 19:38:52 +0530 Arun Raghavan [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: [...] - it doubles the number of file reads necessary during resolution. The first read will cause the file to be cached for subsequent reads anyway, so the performance hit boils down to an additional read() call (which will probably be buffered by your file I/O library anyway, so it's unlikely to even result in a context switch). And even without, it is well worth the lack of fugliness in the ebuild name. No, it results in a new open() on a file that's elsewhere on disk, which results in two new seeks. You get about fifty seeks per second. Plus path resolution, which isn't exactly free - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 10 Jun 2008, at 19:06, Patrick Lauer wrote: On Tuesday 10 June 2008 16:54:49 Richard Brown wrote: On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED] wrote: At this point, we should really only discuss features that all 3 package managers have implemented. I'm not sure that's a good idea, only two have implemented EAPI 1 so far. Yes, but noone cares about Paludis. Ah, Paludis does support EAPI-1 just fine. Thank you. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 10 Jun 2008, at 18:39, Doug Goldstein wrote: Nirbheek Chauhan wrote: On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer [EMAIL PROTECTED] wrote: So EAPI 2 is not everything shiny, but a small iterative improvement to EAPI 1. Suggest features then and let's discuss! For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a tracker for EAPI feature requests. I personally like https://bugs.gentoo.org/197859 the most -- split out src_configure from src_compile which will allow sane resuming of compiles :) At this point, we should really only discuss features that all 3 package managers have implemented. I'm not sure this intersection isn't empty :/ We might, however, only discuss features that all 3 package managers can implement easily. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 9 Jun 2008, at 10:50, Luca Barbato wrote: Ciaran McCreesh wrote: I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? You got some right here. Feel free to address them. So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. - use EBNF when describing a syntax. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. lu And how specifically is this going to help? You are missing the 'provide details' part. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 9 Jun 2008, at 14:18, Luca Barbato wrote: The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Your opinion. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. Pointless nit. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 8 Jun 2008, at 11:12, Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html Hi, I already argued in favour of both GLEP54 and GLEP55 in a council meeting. I'm eager to know what real problems people have with those. Until now, we've only seen stupid complains such as: 'changing extension breaks my shitty scripts', 'it looks weird', 'I don't understand what you are talking about, yet I want to comment', 'but scm means something else for me'... Other than that, I'm looking forward to both GLEPs being accepted whether I make it to the council or not. With respect to future EAPIs, from the top of my head, I'd like Gentoo to have: * USE dependencies. * Suggested dependencies. * Blockers information to the package manager. * Proper SCM integration with the package manager. - ferdy-- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations for council
On 8 Jun 2008, at 14:34, Alex Howells wrote: 2008/6/7 Fernando J. Pereda [EMAIL PROTECTED]: Except you'd rather veto the ones you don't like. Hehe... It must suck being you, wanting to veto people and not being able to do it :) I trust the masses to do the sensible thing and not vote for people who'd be bad for the project. Hopefully that means we get the Council from last year, with one or two new faces? Hopefully everyone would be 'new' and only a couple of people (if not less) repeat. This council hasn't really done anything right. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations for council
On 7 Jun 2008, at 21:21, Alex Howells wrote: 2008/6/7 Santiago M. Mola [EMAIL PROTECTED]: ferdy, thanks for the nomination. astinus, thanks for your support and inspiration, which almost convinced me for running for Council. Any time :) In which case I guess maybe Jeroen Roovers (rej / jer) wants that spot on the ticket? ;) I'd like to nominate him too. Looks like we'll have plenty of choice this time around, which can only be a good thing. Except you'd rather veto the ones you don't like. Hehe... It must suck being you, wanting to veto people and not being able to do it :) - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
On 5 Jun 2008, at 18:09, Ali Polatel wrote: Łukasz Damentko yazmış: Hi guys, Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). I want to nominate: Fernando J. Pereda -- ferdy I kindly accept my nomination. Thanks. - ferdy-- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations for council
On 3 Jun 2008, at 07:52, Ferris McCormick wrote: I think nominations are open. I'd like to nominate: Ingmar ColdWind - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Wed, Jan 09, 2008 at 09:25:11AM -0500, Caleb Tennis wrote: Why taking it against arch teams? How is that different from certain maintainer not taking care of a bug that holds stabilization of certain package by some time measured in months ? I'll tell you my answer: 'no difference at all'. You are right, there's not much difference. However, I brought up the topic because I felt like this particular situation was a bit of a problem that needed to be addressed. Yours is also one that can/should potentially be addressed, and I advise you to recommend the council discuss it as well. Well, while discussing what you brought up, they should _also_ consider what I said as part of the same (so-called) problem. My goal wasn't to point fingers or to call anyone lazy. My goal was to address that if development in this certain area has stagnated, how can those of us who it affects continue to move forward? This is simply an area that is gray and needs to be discussed. There are many other gray areas that need to be discussed too. I understand we all have real lives and are volunteers. But if there are areas that we are responsible for and we aren't able to meet the needs/demands of the other developers in those areas, it's only fair to let them continue moving forward. I never even mentioned any specific arch in my original request, nor did I call any developer out. So please, nobody needs to take this personally. I didn't take it personally myself, honestly, I couldn't care less. Wonder why there is almost no non-mainstream arch team people contributing to this thread? - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpOiXoZzRjqH.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote: Ciaran McCreesh wrote: On Sat, 22 Dec 2007 16:09:27 +0800 Zhang Le [EMAIL PROTECTED] wrote: IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion which is supposed to be open to everyone who cares about it. It's open to anyone who cares about it and is knowledgeable enough to provide informed commentary. Anything else is just noise. At least not to tell others to be quiet. It is a discussion after all. We can let them become knowledgeable, at least we should try. Heh... unfortunately this is gentoo and this behaviour is tolerated. Try to go with this same thing to the lkml[*1*]. Ask them to teach you C so you can contribute with your opinion to every single patch and design decision that is made. Then tell them they should teach you stuff about OS design because you _are_entitled_ an opinion, then [then, sane people see how this approach gets silly] - ferdy 1 - And if you do so, please share Message-IDs, it'll make a great laugh. -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpJPPltHYsaK.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Sat, Dec 22, 2007 at 07:09:30AM +, Ciaran McCreesh wrote:
On Sat, 22 Dec 2007 03:41:02 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Piotr Jaroszyński kirjoitti:
This GLEP proposes usage of EAPI-suffixed file extensions for
ebuilds (for example, foo-1.2.3.ebuild-1).
It seems many people don't like the idea of having it in the filename
but how about having subdirectories for different eapis. This should
even be faster for the package manager as it can just ignore the
directories it can't understand instead of having to parse the file
names.
example:
${PORTDIR}/category/pkg/eapiX/
In terms of what it does and doesn't allow, this one's equivalent. But
it has some new disadvantages:
* It's several more directory reads. This is a measurable performance
hit on something that's already i/o bound.
Among other things, because readdirs cannot be neither readahead nor
'advised'. Which is STUPIDLY slow. So adding yet another directory to
the hierarchy is quite silly.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgp2k93LGjnu1.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, Dec 20, 2007 at 12:07:35AM +, Steve Long wrote: Since only declaring it the once /seems/ ok with you, what on Earth is so hard about extracting it? I'm sure ruby has sufficient text processing capability if the C++ is a bit much for you; I remember there was that long-term bug in paludis not being able to deal with whitespace in config files, so clearly something's up with your text-processing. Hope that's finally fixed now. Hahahahahahaha you just made my day. As usual, your input is close to worthless. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpeNyi907khR.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, Dec 20, 2007 at 02:12:24PM +0100, Bo Ørsted Andresen wrote: On Thursday 20 December 2007 13:48:31 Steve Long wrote: (optimising early here seems silly tbh, given that paludis now requires ruby.) Eh? Now what're you on about? http://bugs.gentoo.org/show_bug.cgi?id=198864 So here you're showing that you don't know what a USE flag is? It is good he made it crystal clear though. Nobody has to 'guess' now. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpgzm13Sp0xr.pgp Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote: Piotr Jaroszyński wrote: Mixing EAPIs can't work. Why? Because EAPIs can define colliding features. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp90C5dzn9AZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, Dec 19, 2007 at 11:03:54AM -0500, Jim Ramsay wrote: Fernando J. Pereda [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote: Piotr Jaroszyński wrote: Mixing EAPIs can't work. Why? Because EAPIs can define colliding features. The sense I've gotten from this discussion so far is that if you want features from two EAPIs you know *can* be combined without collisions, you should define a third EAPI that is a superset of the other 2. *nod* But that is different from arbitrary mixing them, which is what originated this subthread. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpVgdhCxzpDI.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, Dec 18, 2007 at 06:57:33AM -0700, Joe Peterson wrote: Ulrich Mueller wrote: It seems to me that this will inconvenience the users, in order to solve a technical problem of the package manager. Absolutely, +1. This does indeed sound like a technical issue; how would requiring a dev to manually mirror the EAPI in the filename extension provide any benefit over caching it behind the scenes (using the Manifest file or similar mechanism)? You are yet to show what kind of inconvenience to the users this proposal will cause. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpM82WsW5kEr.pgp Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, Dec 18, 2007 at 05:05:13PM +, Steve Long wrote:
Thomas de Grenier de Latour wrote:
On 2007/12/18, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 17:10:46 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
I probably missed some of the stuff leading up to this GLEP, but
what is the problem with having the EAPI in the file and
determining it by looking at the file contents?
Motivation, second bullet point:
| Possibility to extend the behaviour of inherit and add new global
| scope functions (as a result of not sourcing ebuilds with
| unsupported EAPI).
Why can't it be in the file but readable without sourcing? For instance,
it could be mandatory that EAPI=X, if present, must be the first
non-blank and non-comment line of the ebuild (and it would then be
checked after sourcing, if the ebuild is sourced, to bug on cases where
it's redefined or unset afterwards).
There's _no_ need to source, nor constrain like that, for a simple one-line
variable, eg:
$ sed -nr '/^[[:space:]]*DESCRIPTION=([^]*).*/ { s//\1/p;q; }' \
app-portage/autounmask/autounmask-0.21.ebuild
autounmask - Unmasking packages the easy way
eapi=$(sed -nr '/^[[:space:]]*EAPI=([^]*).*/ { s//\1/p;q; }' foo.ebuild)
[[ $eapi ]] checkAPI $eapi
..would do it in bash (empty if unset in ebuild) assuming the conventional
EAPI=xx format is used. Other languages can call system() easily enough.
This is just *brillant*. Lets see how useful your solution is:
--- 8 ---
# EAPI has to be set differently based upon tests on PV
if [[ -z ${PV/?.?/} ]] ; then
EAPI=bar-1
elif [[ -z ${PV/?.?.?/} ]] ; then
EAPI=0
else
EAPI=1
fi
--- 8 ---
So please, no hacks.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgpuCiBgvg9Lx.pgp
Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, Dec 18, 2007 at 06:37:11PM +0100, Ulrich Mueller wrote: On Tue, 18 Dec 2007, Fernando J Pereda wrote: It seems to me that this will inconvenience the users, in order to solve a technical problem of the package manager. Absolutely, +1. This does indeed sound like a technical issue; how would requiring a dev to manually mirror the EAPI in the filename extension provide any benefit over caching it behind the scenes (using the Manifest file or similar mechanism)? You are yet to show what kind of inconvenience to the users this proposal will cause. One example was mentioned in this thread before: You cannot use find -name '*.ebuild' anymore. Yeah, and you cannot use 'give-me-my-ebuilds' to list them all... people will have to improve their tools to work with EAPI-suffixed ebuilds. And as we have now learned that EAPI strings are not limited to digits (see ciaranm's message) and may even contain blanks (see grobian's message), we would have ebuilds with very strange filenames. What's the problem with this? - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpt4m8GAdyXU.pgp Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, Dec 18, 2007 at 07:45:44PM +, Duncan wrote: Fernando J. Pereda [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007 18:56:32 +0100: And as we have now learned that EAPI strings are not limited to digits (see ciaranm's message) and may even contain blanks (see grobian's message), we would have ebuilds with very strange filenames. What's the problem with this? 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1' (note the space) anyone? I know what filenames with spaces mean, thank you very much. How about when we have a dozen or so EAPIs active, several of which apply to a specific ebuild? 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty 3 8 4' (and that example uses no odd chars beyond the EAPI component space separator)? This is talking about something not covered by this GLEP so what is your point? - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpJ3tGZSnUfw.pgp Description: PGP signature
Re: [gentoo-dev] diff /usr/portage
On Thu, Dec 13, 2007 at 02:07:07PM +0100, smurfd wrote: Hi! i have not really done any research This is a very good moment to do so. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpTTgBfM3Ta4.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: eselect_zenity: alpha eselect GUI
On Mon, Nov 12, 2007 at 09:13:32AM +, Steve Long wrote: And why do you feel the need to comment when you don't know what the eselect die implementation is or how the changes to it introduced in Paludis make it better? As stated, I was sharing knowledge and pointing out improvements and possible solutions. You should try it some time (nice to see that you can actually discuss, as above, but it's a shame it still takes 2 or 3 mails before you will. Good luck with that.) And then you were shown your improvements are not. Why you had to jump to the personal side, it is unknown to me, though. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpvD1hATiv2t.pgp Description: PGP signature
Re: [gentoo-dev] Phase invariancy and exclusivity requirements
On Mon, Nov 12, 2007 at 01:26:46PM +0100, Marijn Schouten (hkBst) wrote: Ciaran McCreesh wrote: On Fri, 9 Nov 2007 22:40:08 + Ciaran McCreesh [EMAIL PROTECTED] wrote: Is the following set sufficient? Is the following set the least restrictive correct solution? ... to explain the implications of these... Say we have packages a, b and c, and none of them have any dependencies. One valid solution to the build ordering is as follows: * Install a * Install b * Install c One of many solutions that is *not* valid is: * Start doing a, b and c in parallel. Install them as they become ready, doing only one merge at once. Another that is not valid is: * Start doing a, b and c in parallel, but don't merge them. * Merge a. * Merge b. * Merge c. One that is valid is: * Build binary packages for a, b and c in parallel. * Merge a's binary. * Merge b's binary. * Merge c's binary. What exactly is the difference between this valid situation and the previous invalid one? The state of the environment when pkg_setup is run. In the first situation you can't trust it (it is racy and unpredictable among other things). In the second one, you can. That's the first thing that I can think of, there might be others. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp0MO47jsszv.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild
On Sat, Nov 10, 2007 at 04:08:25PM +0100, Denis Dupeyron wrote: On Nov 10, 2007 2:58 PM, Daniel Pielmeier [EMAIL PROTECTED] wrote: Gentoo is a worldwide project, so i guess many of the contributors are not native speakers. See the gentoo-devs all over the world [1] as an example. Okay english is the common language here, but is it that difficult to articulate in a way that everybody can understand and not to use words which could easily be misunderstood. Lucky you are that your native language is one of the world's most widely spoken languages. Imagine to express yourself in a language you are not familiar with! I hope everybody can understand this, as i am not a _native speaker_ too! [1] http://www.gentoo.org/proj/en/devrel/roll-call/devmap.xml? Please do not argue with him. He does this kind of baiting once in a while in search of some action. My previous message was only a seasonal reminder of the fact that we know that he knows what his problem is, although he is naive enough to think we are naive enough to play with him. So saying that a nasty hack is a nasty hack is not allowed these days? - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp4ztBufvy8Y.pgp Description: PGP signature
Re: [gentoo-dev] RFC: sh versionator.eclass
On Mon, Oct 01, 2007 at 11:30:16PM +0100, Roy Marples wrote: On Monday 01 October 2007 22:59:40 Roy Marples wrote: This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. It should be noted that that first draft was developed on bash only. Attached is a patch that fixes quoting on all shells and shift errors on ash/dash/busybox variants. Also attached is the patched versionater.eclass again. Thanks I sure as hell am not going to proof read all that (mainly because I think not using bash features in an environment where bash is required is silly, instead of being an improvement) but I find interesting that you ripped Ciaran's copyright while leaving the Prod ciaranm if you find something it can't handle comment. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpxTtGi7nili.pgp Description: PGP signature
Re: [gentoo-dev] 2.4 profiles are on their way out!
On Mon, Aug 27, 2007 at 11:57:48AM -0700, Chris Gianelloni wrote: As many of you may know, the Gentoo Kernel team has stopped supporting our last 2.4 kernel sources in the tree, gentoo-sources-2.4. Since we no longer have an officially supported 2.4 kernel on alpha/sparc/x86, I have deprecated the 2.4 profiles for those architectures. The 2.4 kernel has had a good run with Gentoo. It is a shame to see it go, but we're finding more and more applications are requiring hal/udev or other 2.6-only requirements, making for a hard time for teams like Gnome. The profiles are slated to be removed on or after November 1st. There is no upgrade path as we will no longer have 2.4 profiles, but it should be a fairly smooth transition to any 2.6 profile. It's a shame that you've done that BEFORE asking the relevant arch teams. Thats a REAL BIG SHAME. Consider your changes on the alpha profiles reverted as soon as I get to my machine. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpWH5jgHzsRx.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 11:40:26AM +0200, cilly wrote: In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets updated the older ebuild gets removed in the same turn. In my opinion, it is better to keep the older ebuild around for a while since if there are some bugs in the newer ebuild, users are able to downgrade easily. My suggestion is to set up a guidline similar like it exists for marking the ebuilds as stable (4 weeks). Probably, a time period for removing ebuilds would be nice to have, I think 2 weeks would be reasonable if there aren't any known bugs of the newer ebuild. Of course, if the newer ebuild has bugs, which do not exist in the older ebuild the older ebuild should still be kept to let the user be able to choose, which version they want. What do you think? I think that setting arbitrary guidelines that try to rule every situation is just *plain* wrong. Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) As usual, deep known of the package you are removing and common sense is way better than guidelines 'to rule them all'. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgppo3ZKWtso0.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 11:59:28AM +0200, Luca Barbato wrote: lu - that prefers less rules and more people aware. Couldn't agree more. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpliNQUioYQL.pgp Description: PGP signature
Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked
On Tue, Jun 12, 2007 at 12:07:11PM +0200, cilly wrote: Hi all, I think it is worth to discuss about `Do not modify ebuilds which are already in the tree... even if masked.` Sometimes ebuilds which are already in the portage tree are modified without changing the version-number, i.e. ebuild-r1 is in the portage tree and the ebuild-r1 gets changed, i.e. useflag or other issues without changing the version number to ebuild-r2. This causes confusion i.e. in bug-reports. My opinion is not to change any ebuild which is in the portage tree, even if the ebuild is masked. I think the better way is to add an ebuild with an updated version number, even if the ebuild is still masked. I also recommend to manage hard-masked packages the same way, it prevents confusion in bug-reports. What do you think? I think this is also a bad idea. I seem to recall that this is documented somewhere in the Developer Handbook... - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpNIXUsJJac3.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 12:14:37PM +0200, cilly wrote: On Jun 12, 2007, at 12:01 PM, Fernando J. Pereda wrote: I think that setting arbitrary guidelines that try to rule every situation is just *plain* wrong. Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) As usual, deep known of the package you are removing and common sense is way better than guidelines 'to rule them all'. I see myself very often upgrading and encountering a bug which requires me to downgrade. But a downgrade isn't easily possible since the last stable ebuild has already been replaced by the newer and buggy one. The bug must not be in the ebuild itself, sometimes a version-upgrade (upstream) brings new features and new bugs. Sometimes it is nearly impossible for a package maintainer to get an overview of possible bugs, may be upstream bugs, or typos. Well, if maintainers can't properly follow upstream development they should probably seek help in their maintenance job. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpIOT3TR5mfk.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 06:36:31AM -0400, Richard Freeman wrote: Fernando J. Pereda wrote: Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) Can you clarify this? What scenarios do you run into where it isn't good for stable users to have access to more than one version of the software? Known to be buggy versions. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpXkRY28H2IT.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 12:53:16PM +0200, cilly wrote: On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote: Known to be buggy versions. Of course, there are bugs in every version. Sometimes a user must be able to choose which bug is more problematic, i.e. the bug in the newer ebuild which makes the package unusable for them or the older bug which has a security issue the users are aware of but not present, i.e. prevented by firewall. A timeline of two weeks would allow the user to easily downgrade and if necessary put the ebuild in overlay. If the user thinks he knows better than me which version he wants to use, there is the code. I'll still keep in Gentoo's tree whatever *I* feel it is best for every gentoo user. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpN2eS7eF6so.pgp Description: PGP signature
Re: [gentoo-dev] Intentions to remove mail-client/muttng from the tree
On Sat, May 26, 2007 at 02:51:39PM +0200, Lars Weiler wrote: * Fabian Groffen [EMAIL PROTECTED] [07/05/26 10:52 +0200]: Please speak up now if there are major reasons to keep muttng in the tree, despite being unmaintained and out of date. I'm okay with removing muttng from the tree. Some weeks ago I tested the old mutt again, but unfortunately not all patches work the same like in muttng. Especially the sidebar-patch which made my life easier. Just FYI the sidebar-patch is going to be taken out of the Gentoo's mutt-patchset. It is going to get a USE flag for itself and it is going to be either sidebar or rest of the patches. This is because of bug #174080. Upstream claims 'it is a configuration problem' and I claim that the sidebar patch is braindamaged and so it is going the way of the dodo. Since people seem to use it anyway, you'll be able to use it with USE=sidebar in the next mutt's release. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpLM06XNH1eN.pgp Description: PGP signature
Re: [gentoo-dev] Re: [news-item] Paludis 0.24
On Sun, May 06, 2007 at 01:10:48AM +0200, Jakub Moc wrote: Christian Hartmann napsal(a): The paludis news item has been approved by me, cause I rock, and commited to the proper location. Council? +1 This should be put on hold until there's some consent and guidelines on how this is supposed to be used. The current 100+ emails threads clearly suggests it's not the case ATM. The interesting number is 23... only 23 different people commented on the whole thread, and some of them even agree with the news item. So the situation is not that bad, lets rephrase that as: There is still some people that don't like it. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpHNh2nUjSs2.pgp Description: PGP signature
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
On Tue, Apr 24, 2007 at 03:16:38PM -0400, Doug Goldstein wrote: Danny van Dyk wrote: Hi all, [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th, 2007] A subset of council members decided today that multiple version suffixes are illegal in the tree pending further notice. This decission can be appealed at the next Council meeting. If there is sufficient public demand, an earlier meeting can be held. This decission has been made to prevent sufficient precedence for unilateral changes to the tree structure. So far the following package versions are considered illegal: media-viode/mplayer-1.0_rc2_pre20070321-r4 media-video/transcode-1.0.3_rc2_p20070310-r1 An illegal version specification of media-sound/alsa-driver has already been removed from the tree. I would like to ask the affected package maintainers to move these versions to sane version specifications as soon as possible. Thanks in advance for this. Danny So apparently as little as 1 council member can make a decision and it be binding unless appealed to the entire council at the next meeting. Danny, This wouldn't have to be because you have a vested interest in paludis and paludis does not support this syntax and there happens to be no reasonable way to support that? Incidentally paludis *does* support it. -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpiD6XCA1LY4.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, Apr 20, 2007 at 08:22:42AM -0400, Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong -mike I don't see a reason to keep it... so lets kill it. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpMM3rYE1Bit.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Resignation
On Thu, Apr 19, 2007 at 11:36:09AM +0100, Steve Long wrote: It's not just me that thinks there haven't been any major b0rkages for nearly a year. Could it be that maybe, just maybe, the development process has actually worked /better/ since you were forcibly retired? Can you *please* stop writing such nonsense here? - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpBJOIPchhLd.pgp Description: PGP signature
Re: [gentoo-dev] Some council topics for March meeting
On Sat, Mar 03, 2007 at 08:46:35PM -0700, Daniel Robbins wrote: [snip] Would you be kind enough to stop hijacking the thread ? You are responsible for this last flame... just quit it please. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpSAwjNUZqqe.pgp Description: PGP signature
Re: [gentoo-dev] Little respect towards Daniel please
On Sun, Mar 04, 2007 at 01:17:03PM -0700, Daniel Robbins wrote: Yep, I agree. Thanks everyone for being tolerant of my confusion and disruption while I look for a way to remove Ciaran from gentoo-dev. Stop it. You don't like him, fine. I personally don't like you, no problem. And many people hate me, good too. Please go back to your hacking and improve Gentoo. You just can't 'remove Ciaran from gentoo-dev', live with it, or leave Gentoo if you don't like the way we do things now. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpAkszCnFlph.pgp Description: PGP signature
Re: [gentoo-dev] A Gentle Reminder
On Sun, Feb 11, 2007 at 05:40:27PM +, Ciaran McCreesh wrote: On Sun, 11 Feb 2007 18:30:43 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | - I'm *not* demanding anything from *arch teams*, the bugs are for | *maintainers* of those packages. I've already told you couple of | times, why are you making these misleading statements yet again? And yet, somehow developers are interpreting your bugs as requests to remove packages straight away. Why do you think this is? Maybe it's because you assign the bugs to maintainers rather than the arch teams and make lots of noise about it, regardless of whether arch keywording still has to be done... In case someone thinks this is just ciaranm inventing stuff, this has happened not too far ago. Some mozilla package got p.masked while some ebuilds still depended on it. It is definitely _not_ Jakub to blame (imho) but I'm pretty sure said deveveloper *thought* he had checked rdeps before. Result: some people (users here) got screwed because of misunderstanding. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpoTSmuR6fyG.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, Feb 06, 2007 at 06:17:16PM +, Roy Marples wrote: Hi List Hi Roy, [snip] So, to free baselayout of forcing bash down our throats I/we am/are looking at re-writing our network setup, including configuration. Who's got any bright ideas for a new config then? Lets brain storm! It is a good format and easy to write and parse in C, why change it ? Just tell people to stop treating config files like bash scripts and everything will be fine. Or am I missing something? - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpVCA2ayOize.pgp Description: PGP signature
Re: [gentoo-dev] Only you can prevent broken portage trees
On Tue, Oct 31, 2006 at 06:18:26PM +0100, Jakub Moc wrote: Sure I did... Could you tell me why should we accumulate broken and vulnerable junk in the tree for years? (Outdated ebuild A depends on junky outdated ebuild B which depends on crappy, unsupported ebuilds C, D and E which... ) Thats not the maintainer's problem but the Arch Team's problem so they are the ones that decide what to do. Either keyword it in a reasonable time or you'll lose the keyword, damn simple... Can't do it in X months? Sorry, too bad for your arch, the package is gone and users will rant (or they won't, and then you don't need the keywords in the first place). No. Arch Teams manage their keywords the way _they_ want not the way YOU or others that don't work on arch teams want. It is actually *that* simple. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpMx13985eWE.pgp Description: PGP signature
Re: [gentoo-dev] Only you can prevent broken portage trees
On Tue, Oct 31, 2006 at 05:05:21PM +, Stephen Bennett wrote: On Tue, 31 Oct 2006 17:57:06 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Of course it does... Lots of people can't remove outdated broken cruft because $ebuild still depends on something since $arch has been slacking for months. Lots of people are forced to maintain outdated junk in this way, it's not like it's just sitting there doing nothing. Did you even read my mail? We're not asking people to maintain old stuff, just to leave it there as is until a newer one can be tested and keyworded. No he didn't, and he probably won't. I've tried to explain this at least once in #gentoo-qa and he didn't seem to *want+ to understand it. Maybe we aren't being clear enough... - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpAzaT7s7Kvr.pgp Description: PGP signature
Re: [gentoo-dev] Only you can prevent broken portage trees
On Tue, Oct 31, 2006 at 06:50:58PM +0100, Jakub Moc wrote: Ah. That's apparently much more important than not breaking users by providing them w/ non-vulnerable, decently uptodate stuff that's not ridden by tons of bugs. Yup. :P Why do you keep trying to tell arch maintainers how to do their job ? Do I tell you how to do yours ? Users of security-supported archs are not affected so what's your point again ? Assuming you have a valid one, of course, so please don't come back with that maintainters don't want to maintain old/broken stuff kind of argument. I'm both an arch-maintainer and ebuild-maintainer and don't see a problem here... so from your _vast_ experience as both an ebuild-maintainer and arch-maintainer, what's the problem? - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpnAnd6PQL1B.pgp Description: PGP signature
Re: [gentoo-dev] Only you can prevent broken portage trees
On Tue, Oct 31, 2006 at 07:12:58PM +0100, Jakub Moc wrote: Oh well, this apparently doesn't go anywhere, slacking is just wonderful, maintainers should just STFU and obey the almighty slacking arches, security is the least of a concern and no priority, not answering a on bug for half a year makes lots of sense and all is fine and dandy. More cruft in the tree for t3h win. Yeah, we are so slackers that we are able to maintain a whole tree of keywords with less than 10 persons and less than 10 machines (alpha example). You probably want a shell account on a mips/alpha/... machine so you can start helping, right? - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpDeqfGu4dZh.pgp Description: PGP signature
Re: [gentoo-dev] Only you can prevent broken portage trees
On Tue, Oct 31, 2006 at 03:23:00PM -0500, Seemant Kulleen wrote: Third, the best proposal I've seen here is for developers to get shell accounts on alternate architectures. There's quite a few of them floating around, and I'm pretty sure the arch teams will help you get a shell on one of the boxes somewhere. Some of the arches even have shell boxes for that purpose sitting at OSU or something. This would work for at least the console applications (the visual stuff will be a little trickier). Just to add a little thing here: Arch teams have been using vnc through ssh to test visual stuff like gnome, kde, xfce and their respective mothers, for years. So testing visual stuff remotely *is* possible. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpZgswJbGLmJ.pgp Description: PGP signature
Re: [gentoo-dev] New git.eclass (Take #2)
On Thu, Sep 07, 2006 at 08:32:50PM +0200, Fernando J. Pereda wrote: Hi guys, We are planning to add git.eclass as presented in bug #132383 (as attachment 96300). I also attach it here in case someone wants to comment parts of it. git.eclass is now in the tree - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgplSVpvKPfQQ.pgp Description: PGP signature
[gentoo-dev] New git.eclass (Take #2)
Hi guys,
We are planning to add git.eclass as presented in bug #132383 (as
attachment 96300). I also attach it here in case someone wants to
comment parts of it.
Please raise your concerns if you have any.
- ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvs/overlay/eclass/git.eclass,v 1.7 2006/09/07 18:01:14 ferdy
Exp $
## --- #
# subversion.eclass author: Akinori Hattori [EMAIL PROTECTED]
# modified for git by Donnie Berkholz [EMAIL PROTECTED]
# improved by Fernando J. Pereda [EMAIL PROTECTED]
#
# The git eclass is written to fetch the software sources from
# git repositories like the subversion eclass.
#
#
# Description:
# If you use this eclass, the ${S} is ${WORKDIR}/${P}.
# It is necessary to define the EGIT_REPO_URI variable at least.
#
## --- #
inherit eutils
EGIT=git.eclass
EXPORT_FUNCTIONS src_unpack
HOMEPAGE=http://git.or.cz/;
DESCRIPTION=Based on the ${ECLASS} eclass
## -- add git in DEPEND
#
DEPEND==dev-util/git-1.4.0
## -- EGIT_STORE_DIR: git sources store directory
#
EGIT_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/git-src
## -- EGIT_FETCH_CMD: git clone command
#
EGIT_FETCH_CMD=git clone --bare
## -- EGIT_UPDATE_CMD: git fetch command
#
EGIT_UPDATE_CMD=git fetch -f -u
## -- EGIT_DIFFSTAT_CMD: Command to get diffstat output
#
EGIT_DIFFSTAT_CMD=git diff --stat
## -- EGIT_OPTIONS:
#
# the options passed to clone and fetch
#
: ${EGIT_OPTIONS:=}
## -- EGIT_REPO_URI: repository uri
#
# e.g. http://foo, git://bar
#
# supported protocols:
# http://
# https://
# git://
# git+ssh://
# rsync://
# ssh://
#
: ${EGIT_REPO_URI:=}
## -- EGIT_PROJECT: project name of your ebuild
#
# git eclass will check out the git repository like:
#
# ${EGIT_STORE_DIR}/${EGIT_PROJECT}/${EGIT_REPO_URI##*/}
#
# so if you define EGIT_REPO_URI as http://git.collab.net/repo/git or
# http://git.collab.net/repo/git. and PN is subversion-git.
# it will check out like:
#
# ${EGIT_STORE_DIR}/subversion
#
# default: ${PN/-git}.
#
: ${EGIT_PROJECT:=${PN/-git}}
## -- EGIT_BOOTSTRAP:
#
# bootstrap script or command like autogen.sh or etc..
#
: ${EGIT_BOOTSTRAP:=}
## -- EGIT_PATCHES:
#
# git eclass can apply pathces in git_bootstrap().
# you can use regexp in this valiable like *.diff or *.patch or etc.
# NOTE: this patches will apply before eval EGIT_BOOTSTRAP.
#
# the process of applying the patch is:
# 1. just epatch it, if the patch exists in the path.
# 2. scan it under FILESDIR and epatch it, if the patch exists in FILESDIR.
# 3. die.
#
: ${EGIT_PATCHES:=}
## -- EGIT_BRANCH:
#
# git eclass can fetch any branch in git_fetch().
# Defaults to 'master'
#
: ${EGIT_BRANCH:=master}
## -- EGIT_TREE:
#
# git eclass can checkout any tree.
# Defaults to EGIT_BRANCH.
#
: ${EGIT_TREE:=${EGIT_BRANCH}}
## - EGIT_REPACK:
#
# git eclass will repack objects to save disk space. However this can take a
# long time with VERY big repositories. If this is your case set:
# EGIT_REPACK=false
#
: ${EGIT_REPACK:=false}
## - EGIT_PRUNE:
#
# git eclass can prune the local clone. This is useful if upstream rewinds and
# rebases branches too often. If you don't want this to happen, set:
# EGIT_PRUNE=false
#
: ${EGIT_PRUNE:=false}
## -- git_fetch() - #
git_fetch() {
local EGIT_CLONE_DIR
# EGIT_REPO_URI is empty.
[[ -z ${EGIT_REPO_URI} ]] die ${EGIT}: EGIT_REPO_URI is empty.
# check for the protocol.
case ${EGIT_REPO_URI%%:*} in
git*|http|https|rsync|ssh)
;;
*)
die ${EGIT}: fetch from ${EGIT_REPO_URI%:*} is not
yet implemented.
;;
esac
if [[ ! -d ${EGIT_STORE_DIR} ]] ; then
debug-print ${FUNCNAME}: initial clone. creating git directory
addwrite /
mkdir -p ${EGIT_STORE_DIR} \
|| die ${EGIT}: can't mkdir ${EGIT_STORE_DIR}.
chmod -f o+rw ${EGIT_STORE_DIR} \
|| die ${EGIT}: can't chmod ${EGIT_STORE_DIR}.
export SANDBOX_WRITE=${SANDBOX_WRITE%%:/}
fi
cd -P ${EGIT_STORE_DIR} || die ${EGIT}: can't chdir to
${EGIT_STORE_DIR}
EGIT_STORE_DIR=${PWD}
# every time
addwrite ${EGIT_STORE_DIR}
[[ -z ${EGIT_REPO_URI##*/} ]] EGIT_REPO_URI=${EGIT_REPO_URI%/}
EGIT_CLONE_DIR=${EGIT_PROJECT}
debug-print ${FUNCNAME}: EGIT_OPTIONS = \${EGIT_OPTIONS}\
export GIT_DIR=${EGIT_CLONE_DIR}
if [[ ! -d ${EGIT_CLONE_DIR} ]] ; then
# first
Re: [gentoo-dev] New git.eclass
On Fri, May 19, 2006 at 11:58:32PM -0700, Donnie Berkholz wrote: Fernando J. Pereda wrote: I'd like people who use Git eclass to test it and see if any of the 'features' I introduced break things for them. I just incorporated much of this into my version (minus some whitespace changes) and pushed it up. Seems to work fine on my stuff, although the additional time taken by the repack and prune is mildly annoying, particularly considering the point of git is to be fast at the cost of disk space rather than vice versa. =) We could make EGIT_PRUNE and EGIT_REPACK to default to 'false' then. Is there a way users could set these variables and choose if they want to prune/repack or not ? Cheers - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpRgOj7gSmhC.pgp Description: PGP signature
Re: [gentoo-dev] New git.eclass
On Thu, May 18, 2006 at 06:30:47PM -0700, Donnie Berkholz wrote:
[snip]
Hi,
I think I improved the eclass a bit by making it more efficient both
disk and network wise among other things:
- Branchs are supported so different versions of the ebuild can use
different versions of the code without duplicating objects.
- Once you cloned the first time, following installations only fetch
updates for the branch you are going to use.
- It clones a 'bare' repository, i.e. without a working copy, thus
saving disk space.
- Uses 'git tar-tree' instead of 'rsync' to checkout a particular
commitish (EGIT_TREE).
- It is able to repack and prune the repository to save disk space and
improve performance. Ebuilds can override this behavior by setting
EGIT_{PRUNE,REPACK} to false.
I also bash'ified the eclass, I don't know if this is a good thing but
makes things easier to read (at least for me). Everything should work
perfectly on bash2 systems.
I'd like people who use Git eclass to test it and see if any of the
'features' I introduced break things for them.
Also, git-sources *should* use this eclass once it is in the tree since
people using it will save _lots_ of bandwidth and disk space.
Latest version is in my public overlay[1].
- ferdy
[1] http://dev.gentoo.org/~ferdy/overlay/eclass/git.eclass
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgpkLlwXiUe3v.pgp
Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Tue, May 16, 2006 at 04:15:49PM +0100, Stephen Bennett wrote: Comments? I'd like to see a paludis profile under default-linux/alpha. I belive it is much better to have a top-level hierarchy for paludis profiles anyway but people seem to blindly disagree with that. Oh, and BTW, keep up the good work with paludis. -ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpuETI11d9bR.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Sat, Apr 29, 2006 at 03:02:46PM +0300, Dan Armak wrote: On Friday 28 April 2006 23:42, Ryan Phillips wrote: svn + Atomic Commits + Merging/tagging/brancing is a simple copy operation http://svnbook.red-bean.com/en/1.1/ch04.html + lots of benefits http://svnbook.red-bean.com/nightly/en/svn.intro.features.html there is more I'm sure people can come up with - 2x Drive space - No changeset/merge tracking If we have a lot of active branches and a lot of merging between them, changeset tracking could be a major plus. I've never used git but I've heard that it, and other distributed development-style SCMs, have changeset/merge tracking features that are really helpful. Could someone who's used them comment on this? Yes, Git tracks merges unless the merge is trivial (aka fast-forward). When you merge branch 'a' into branch 'b' and 'b' is a strict subset of 'a' we call that a fast-forward, since there is no merge anywhere: o---o---o b \ x---x---x a If you merge 'a' into 'b' (git checkout b ; git pull . a) the result is: o---o---o---x---x---x a = b However in the following case, a proper merge is required: o---o---o---#---# b \ x---x---x a 'b' is not a strict subset of 'a' because the commits marked with # do not exist in 'a', so the thing ends up being: o---o---o---#---#---@ b \ / x---x---x a The commit marked with @ is a special comit called a 'merge'. I hope that clarifies the merge tracking part. However I don't know what do you mean with 'changeset tracking'. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpeQGlULeJE4.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Sat, Apr 29, 2006 at 03:54:17PM +0300, Dan Armak wrote: On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote: The commit marked with @ is a special comit called a 'merge'. I hope that clarifies the merge tracking part. You just described what merging is. Svn can do that too with svn merge. But, if I merge changesets from branch A to B selectively, skipping some along the way, can I later ask git to: - list the changesets remaining in A that I haven't merged to B yet? Yes, unless you used cherry-pick. You have to do *real* merges to be able to do that. - list the branches, from a given list, which have/haven't merged a given changeset? It depends on how you merged the changesets, if you did it sanely, yes, should be easy. If you used cherry-pick here and there I don't think so. I didn't mean that 'changeset tracking' is different from 'merge tracking'. Ok. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp5JAHZLyaXe.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 01:42:40PM -0700, Ryan Phillips wrote: cogito - Not practical * the lots of little files doesn't scale well with the size of the portage tree Sure, that's why they invented git repack. * In addition, git only allows checkins from the project parent. A deal breaker in my opinion That's not true at all. Not in any sane Git version. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpuShtf3rkjZ.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan: I think you are talking about very old versions of Git: On Fri, Apr 28, 2006 at 02:20:43PM -0700, Ryan Phillips wrote: What I meant is, if you have a change within one directory pending a commit, and you have a commit pending in a current directory, both files will be picked up for the commit. I think that is bad. That means you can't have pending changes not ready for commit and commit something. Of course you can have pending commits. You can even have uncommited changes in your index since git-commit uses a temporary index when doing this kind of checkins. yes. git-commit will allow the commit, it will walk the directories backwards, but it will find all the pending changes and want to commit them. It will if you don't use git-commit correctly :) I don't think that is beneficial. I'm open to comments though. 'git commit' semantics are a bit different from 'cvs commit' and 'svn commit' semantics. That's probably the reason you faced that problem :) Cheers, ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpZfPqD2Ec9B.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 02:06:36PM -0700, Ryan Phillips wrote: Second issue with git, is that with lots of tiny little files things don't work so well. I tried converting our portage tree into a git tree, and it ran for around 2 days until I finally killed it. If we didn't want to preserve history, then maybe it would work out. But with the problem I outlined above I still don't see it as a contender. There are lots of times when one would want to do a commit in one directory. Ryan, What tool did you use for that? AFAIK parsecvs[1] has converted some very big and broken CVS repositories successfully. - ferdy [1] git://git.freedesktop.org/~keithp/parsecvs -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpEnrmtBVaXl.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 02:56:26PM -0700, Ryan Phillips wrote: I sorta like git in certain aspects. If git would work better than CVS or anything other SCM I'm for it. Right now, _anything_ would be better than CVS. I don't really know if Git is suitable for our workflow though... I was just trying to clarify those issues you pointed out about Git. I locally manage a couple of overlays with it, but nothing compared to the portage tree. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpBDy9Dpn3Ta.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Fri, Mar 31, 2006 at 09:16:17AM +0100, Stuart Herbert wrote: Hi Aron, On 3/30/06, Aron Griffis [EMAIL PROTECTED] wrote: I think we might be best to try three revision control systems to start: darcs, git and subversion. Three seems like a lot, but each has its reason, and we can anticipate darcs being used primarily by the haskell team rather than for overlays in general. Many thanks for the summary. I'll find some time to look at how we can support darcs and git, and I'll post some news when I have some :) Feel free to contact me if you need help with Git. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpTYXwfbk50K.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, Mar 25, 2006 at 07:57:43PM -0500, Aron Griffis wrote: Fernando J. Pereda wrote: [Sat Mar 25 2006, 06:18:52PM EST] Well, I find it easier to understand than many other DVCSs out there... In fact I don't think it is difficult to use in any way. Maybe pre-1.1 versions had some syntax weirdnesses, but the 1.2 series are really easy to use and understand... That is good to hear. It's possible that my comments were misplaced, and it would be worth my while to reinvestigate git. Personally I use mercurial daily (xen) and I've been very happy with it. I'm under the impression that mercurial is easier to use than git, mostly because of git's philosophy of providing the low-level infrastructure and expecting other projects to build user-friendly interfaces. While that split sounds good in theory, it seems to result in one interface that's powerful+complex, and other interfaces that are weak+easy. Again, that's an impression, not recent personal experience. Definately that was the case some months ago. Now Git provides a 'porcelain' (user oriented) interface, and using the 'plumbing' (core) tools directly is highly discouraged. Also Cogito has improved a lot since then. *shrug* All possible with the other DVCSs, generally easier to use, and harder to screw up your repo. How would you screw your repo using normal Git commands ? I shouldn't have made that statement since I haven't done it personally, only heard of it happening to other people, and not recently. Again, might be the case with ancient versions, I screwed some of my repos :) But definately not with post-1.0 versions. Basically, I think you tried/heard about, ancient versions of Git and Cogito, and yeah... the very first versions were a PITA sometimes. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpPqe472FfxF.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sun, Mar 26, 2006 at 06:39:15AM +0200, Luca Barbato wrote: git : c+bash (and optional perl/python for some merge scripts) Just for clarifying things: A strict server doesn't need perl or python (not even bash) though bash is highly recommended. A client NEEDS python because the 'recursive' (default and best) merge strategy is written in python. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpjs799au2ks.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, Mar 25, 2006 at 06:00:49PM -0500, Aron Griffis wrote: Ryan Phillips wrote: [Sat Mar 25 2006, 01:47:51AM EST] It sounds to me like the overlays would benefit of using git/cogito. The Linux Kernel uses this DVCS to full affect. Pulling changes from other repositories, and even receiving email patches pushed from people not having their own official repository (or repository http or ssh accessible). Any git checkout is a branch, so its easy to stay up to date with the mainline tree and still work on personal branches. Most of the other DVCSs are easier to use than git, and just as powerful or more. IMHO git is used for Linux mostly because Linus wrote it, rather than it being the best tool for the job. Well, I find it easier to understand than many other DVCSs out there... In fact I don't think it is difficult to use in any way. Maybe pre-1.1 versions had some syntax weirdnesses, but the 1.2 series are really easy to use and understand... I think git/cogito might be the solution. It works for a highly distributed kernel development, which would be similar to the way the overlays would work. Gentoo User A would checkout the kde overlay, make some changes, cg-commit them to their own overlay, and submit the patches upstream via an email requesting a pull, or emailing them patches directly with a git-mkmail command. *shrug* All possible with the other DVCSs, generally easier to use, and harder to screw up your repo. How would you screw your repo using normal Git commands ? Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpCufL8qSvGg.pgp Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, Mar 25, 2006 at 06:12:07PM -0500, Aron Griffis wrote: I should backpedal on that statement a bit... While I think it's true historically, git is doing a great job for kernel development, and it can't be criticized lightly. Nonetheless, similar power is available in other DVCSs that are easier to use and less likely to cause headaches. Now my other mail doesn't make a lot of sense :) -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpgtULTTyX0l.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 06:59:49PM +0100, Patrick Lauer wrote: If you show a wrong code snippet please explain _why_ it is wrong in the same email. Ehm you mean it is not obvious that calling emerge inside an eclass is utterly wrong ? -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpCBNysRgMmy.pgp Description: PGP signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Mon, Dec 19, 2005 at 10:17:56PM +0100, Patrick Lauer wrote: | http://www.keltia.net/EuroBSDCon/slides.pdf has some performance data on | mercurial for FreeBSD, roughly the same size as the Gentoo cvs | repositories. It's not the size of the repo what matters... it is the workflow. I don't know how they work... but I definately don't think ours suits in a distributed SCM as Ciaran pointed out. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp4IZvukZIby.pgp Description: PGP signature
Re: [gentoo-dev] The deal with epkgmove
On Sat, Dec 10, 2005 at 05:29:09PM +, Ciaran McCreesh wrote: | On Sat, 10 Dec 2005 16:56:55 +0100 Luca Barbato [EMAIL PROTECTED] | wrote: | | I'd suggest having a look at git or mercurial, they are tested on a | | quite big workload and they seems good enough for the task. | | Workload isn't the issue. It's number of files. And not only the number of files... the workflow here doesn't fit in a distributed enviroment. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp79Jjh6Ig20.pgp Description: PGP signature
Re: [gentoo-dev] Interactive emerge
On Sun, Oct 02, 2005 at 07:02:02PM +0100, Ciaran McCreesh wrote: | | Also when FEATURES=test ? In such case the mod_php and php packages | | are broken. They ask you to save, reject or send the result of the | | tests if I'm not mistaken | | Yup. There're quite a few broken test packages in the tree. Another | common problem is calling wget from inside test. Mostly this comes from | src_test being a fairly recent feature... When some of the ebuilds in | question were written it didn't exist. Ok, thanks for the clarification. -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp5MrmL4AoAH.pgp Description: PGP signature
Re: [gentoo-dev] The tree is now utf-8 clean
On Sat, Sep 17, 2005 at 02:42:09AM +0100, Ciaran McCreesh wrote: | Something strange I noticed... Some people are using funny quotes and | non breaking spaces in ebuilds. Some people are using weird characters | as substitution delimiters for sed. Don't! It will break on many | systems. I'm going to go and purge all of those, UTF-8 or not, whenever | my brain recovers. I hope ~ is not considered a weird character... if it is, tell me and I'll fix all my ebuilds. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpPPyvqGYvqI.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 06:38:36AM -0500, Brian Harring wrote: You're masking occurs within the profile itself, not globally. Global masking usually is for introduction of new ebuilds that need testing and shouldn't be hit by normal arch testers (portage early release candidates for example); if you're blocking valgrind on arm (fex), you *should* be blocking it in profiles/default-linux/arm, not profiles/package.mask ;) If it's profile specified files, relax, not targeted :). Strictly after getting the global data out of there, and into a directory reflecting that data's actual role within the repository, and makes sense in a more flexible, non single $PORTDIR+$PORTDIR_OVERlAY environment. Aside from that, see my other email re: the seperate levels of filtering :) ~harring That clarified it for me :) Thanks Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgphtFffPFpHO.pgp Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things
On Sat, Aug 20, 2005 at 07:00:02PM -0400, Nathan L. Adams wrote: WONTFIX refers to the bug, not the attached ebuild. And it won't be 'fixed' unless the ebuild is improved, so WONTFIX is fine. Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgpuB2Cq7h8LV.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
On Thu, Aug 18, 2005 at 11:05:43PM +0200, Grobian wrote: Maurice van der Pot wrote: On Thu, Aug 18, 2005 at 09:28:47PM +0100, Ciaran McCreesh wrote: Bah! No I'm not, because Sven pointed out that it collides with the bugzilla resolution. So I'm going with CHECKED instead. Whoah! Isn't REVIEWED the perfect keyword? or APPROVED? I think APPROVED doesn't reflect the idea; since nobody 'approved' the ebuild. A developer just checked it looks good and 'seems to work'. REVIEWED or CHECKED make more sense imho. Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgp7ybycy98a9.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
On Tue, Jun 28, 2005 at 10:39:52AM +0200, [EMAIL PROTECTED] wrote: You want to become official. We are official. It's not just the way things should be. Well... you want to become staff. In that regard, you do not get to take care of your own things anymore. We will still recruit new mods/admins and take care of them. We will still moderate and administering the board and the software. We will still vote on new policies and guidelines. I fail to see what you mean by saying that. Nope; if you become staff then devrel/recruiters will be involved. You are no exception to the rule. Every developer and staff has taken the quiz [...] Sorry, but thats not correct (at least to my knowledge). - Back in the good ol' days most of the developers knew each other and knew who was doing what. Taking a quiz became mandatory back in 2003 iirc. Devs who were already aboard did not need to take the quiz. Those people were already gentoo staff, you aren't right now, so it's not the same situation. Again, I fail to see why the forum staff deserves an exception to the rules that every other person that is either staff for Gentoo or a developer for Gentoo has to follow. Well.. that's right. Rules should be followed.* If it would be up to me everybody of us would take that quiz and we could stop this discussion. But it's not up to me. - It's not that simple. People managing the forums should take the responsability to make them take the quiz and become official. Nobody said that being 'the boss' was going to be easy. Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgppN4IrONmZ9.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
On Tue, Jun 28, 2005 at 11:53:17AM +0200, Ioannis Aslanidis wrote: Nope; if you become staff then devrel/recruiters will be involved. You are no exception to the rule. Incorrect. As devrel already stated, this won't change ever. We will be always the ones to do this. I still don't see *WHY* you should be different from us. If you want to manage your recruits then they can't be gentoo staff. Arch teams have developed a new 'figure', the arch tester. Not official gentoo staff but somehow involved with us; arch teams manage their own arch tester recruitment process. If that's the situation you want then they won't become gentoo staff. And some of us were already doing stuff for Gentoo much before the quizes became mandatory, so it would be fair that all of us that were mods/admins before that date would be treated *that* way. Still, you weren't gentoo staff. Helping out since then doesn't make you any different from the recruitment point of view (IMHO). Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgpDAwXVB0z2V.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
On Tue, Jun 28, 2005 at 12:19:34PM +0200, Ioannis Aslanidis wrote: I still don't see *WHY* you should be different from us. If you want to manage your recruits then they can't be gentoo staff. One reason could be that we are _not_ going to be called developers but staff. Can anybody explain me the difference between them ? Arch teams have developed a new 'figure', the arch tester. Not official gentoo staff but somehow involved with us; arch teams manage their own arch tester recruitment process. If that's the situation you want then they won't become gentoo staff. Didn't I say that was already agreed with devrel? Do I have to quit saying that I think that's wrong? No thanks. You are the only group that will make new devs apart from devrel. I still don't see why you should deserve a different treatment. If you want to join us, PLEASE PLEASE PLEASE follow our rules. They are there to be followed if you didn't notice. Still, you weren't gentoo staff. Helping out since then doesn't make you any different from the recruitment point of view (IMHO). Then the problem is we should have been done in that moment, so this is one more reason in favor of taking old mods to staff with no quiz stright away. I hope you have stronger arguments... Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgpI8FFCKSpqh.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
On Tue, Jun 28, 2005 at 01:01:57PM +0200, Ioannis Aslanidis wrote: On 6/28/05, Jon Portnoy [EMAIL PROTECTED] wrote: Developers have CVS access; take the ebuild quiz and you're a developer, take the staff quiz (the eight-question quiz some mods apparently don't like for whatever bizarre reason...) and you're staff Does that mean that we could take the ebuild quiz too (if we wanted to)? Why would you want to ? Everybody can take the ebuild quiz, if they have something to do in the tree of course. Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgp0b1ahZee9W.pgp Description: PGP signature
Re: [gentoo-dev] Brainless keywording (this time: dev-dotnet)
On Tue, Jun 28, 2005 at 06:34:11PM -0300, Gustavo Zacarias wrote: When will this end? DON'T KEYWORD STUFF YOU DON'T TEST ON ARCHES, SPECIALLY STUFF THAT WON'T WORK UNTIL PORTING IS DONE. I mean, c'mon, it's easy enough... just go to that little Mono page (http://www.mono-project.com/Main_Page) and check the arch status... it's not hard... just a simple link. (FYI SPARC is Solaris/SPARC supported, not Linux/SPARC, just another small click to read that). Yeah, it may eventually be ported or whatever - i don't care, it's not ported yet. Stick to procedures and common sense. Of course this also applies to the Alpha keyword. Keywording policy is CLEAR and SIMPLE to read, understand AND follow. Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgp3Ezl3MW06B.pgp Description: PGP signature
Re: [gentoo-dev] Bad metadata.xml encoding
On Wed, May 11, 2005 at 01:13:11PM +0200, Lars Weiler wrote: * Georgi Georgiev [EMAIL PROTECTED] [05/05/11 09:36 +0900]: Starts to smell of a cvs problem... Two ideas to handle a check of metadata.xml: 1) repoman should run xmllint 2) the cvs-server can do it during commit (like it already does with other xml-documents) Though I like (1) (probably (2) is redundant here) this will neither solve nor prevent what happened to that metadata files since they are XML valid and GLEP31 valid. (i.e. the file is UTF-8) Cheers, Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgpWCE3mGbKHp.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo could become certified for IBM Server Hardware
On Wed, May 04, 2005 at 06:15:28AM -0400, Michael Cummings wrote: Let me just diplomatically: cool :) Agreed ! :P -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgpczvO4zSiu7.pgp Description: PGP signature
