[gentoo-dev] Re: New developer : Richard Freeman (rich0)
Denis Dupeyron schrieb: I would like to thank Markus Ullmann (jokey) for taking over the mentoring of Richard after his original mentor left us. So please everybody, give a warm welcome to Richard. Denis. Now that you did your first commmits, welcome to the crowd of evil tree breakers^Wcommitters :) Greetz -Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])
On Fri, 28 Dec 2007 05:21:06 + Steve Long [EMAIL PROTECTED] wrote: Whatever. EAPI=2 works fine with current software. Could you tell me why you're so hot on export'ing EAPI? I thought it was only relevant, environment-wise, to the ebuild and subshells. What is the use case for exporting it externally? I'm going to ignore you until you post a lengthy explanation of why what you just said was utter bollocks. You clearly don't have a clue what you're talking about just now, and by continuing to post nonsense like the above to the discussion you're wasting everyone's time. Honestly, that was the single most wrong thing anyone's said in this entire discussion. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 28 Dec 2007 13:25:13 +0100 Santiago M. Mola [EMAIL PROTECTED] wrote: On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). Possibly. Currently there's simply no way of doing it, nor of using non-EAPI-0 features anywhere in profiles (you can't, for example, use slot deps in package.mask). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 27 Dec 2007 23:26:27 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Marius Mauch wrote: Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? The restricted definition is certainly OK, but I'm not convinced that the restriction is necessary. There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 28, 2007 1:28 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 28 Dec 2007 13:25:13 +0100 Santiago M. Mola [EMAIL PROTECTED] wrote: On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). Possibly. Currently there's simply no way of doing it, nor of using non-EAPI-0 features anywhere in profiles (you can't, for example, use slot deps in package.mask). It'd be nice to agree a new profile format before accepting version format changes. In the case of slot deps, it'd be desirable to use them in package.mask, just desirable. But with version format changes we're introducing ebuilds which can't be handled in package.mask, that's a great loss of functionality. GLEPs 54 and 55 could wait until we have figured out how to apply them properly and without loss of current functionality. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
[gentoo-dev] apache-2.0* and apr{,-util}-0* removal
As previously announced apache-2.0 support ends as of 31-12-2007 and will be
masked (together with apr{,-util}-0*) end of january.
A tracker bug exists at https://bugs.gentoo.org/203578
Greets,
Bene
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Some new global USE-flags
On Fri, 2007-12-28 at 05:53 +, Steve Long wrote: Chris Gianelloni wrote: branding: Enable Gentoo specific branding [questionable, as used for splashes/shortcuts/artwork] Well, my personal opinion here is that we should enable this by default on *at least* the desktop profiles, as providing sensible defaults and branding isn't outside the scope of the project. We still stay as close to upstream as possible with this stuff and only use it for branding or optional Gentoo-specific minor config changes. Also, it can still be disabled for people who want everything as upstream intended. I have no objection to it being flagged on by default in desktop profiles, but Gentoo-specific minor config changes concerns me, since I take it as given that installing for a specific distro implies config changes to work with that distro, and not having those because I have turned branding off sounds bad for me as a user and seems a confusion of purpose. (It could lead to more optional config changes bundled in future which wouldn't be apparent without knowledge of the ebuild.) Well, by this I meant something like bug #170059 which would mean changing the default home page (minor config change) to something Gentoo-specific. Not all config changes are for required functionality. Sorry, I had assumed that people on this list would be technical and able to realize this without it being explicitly spelled-out. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] Bug Day Saturday January 5th, 2008
All, It's that time of the month again, time for another Bug Day on Saturday 5th January. Yep, that's the first bug day of 2008. Join us in #gentoo-bugs on irc.freenode.net to help squash some bugs and meet up with fellow users and developers. Read all about it http://bugday.gentoo.org/ Regards, Roy Bamford (NeddySeagoon) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 28 Dec 2007 12:28:10 +: On Fri, 28 Dec 2007 13:25:13 +0100 Santiago M. Mola [EMAIL PROTECTED] wrote: On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). Possibly. Currently there's simply no way of doing it, nor of using non-EAPI-0 features anywhere in profiles (you can't, for example, use slot deps in package.mask). Requesting clarification of a point, here: I understand the ban on non-EAPI-0 features in in-tree profiles, since users could be using old PMs, but it's fine using them in /etc/portage/*, provided one has upgraded to an appropriately compatible PM, correct? I ask because based on the kde overlay documentation, I have a lot of entries like this in /etc/portage/package.keywords: # kde4 overlay kde-base kde-base/kdelibs:kde-svn** -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 27 Dec 2007 18:11:33 +: On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. OK, I still think putting it in the file name is less prone to error, but what about this, call it blue if you will? 1) Strictly define and restrict EAPI to a specific form in a specific file location (say EAPI=value, unquoted, as the first line of the file). 2) Quickly define say EAPI=1_ext, that further defines say SUB_EAPI, or EBPI, or EAPI-B, which is allowed to be a function or whatever, with the only further restrictions on it being those that would apply to EAPI- suffix file names. That should give us the nailed down qualities of putting it in the file name, while providing the flexibility therein as well. There may be a bit of delay while we wait for non-EAPI aware PMs to drop out, but by the sounds of things, it's not going to be much more than fighting this thru and getting it approved is likely to be (a couple months, anyway), and as it's a different EAPI, EAPI aware PMs should ignore it if they don't understand it. PMs can then do a pre-parse, looking at the first line in specified format just as they'd otherwise look at the filename. With that information in hand, if the EAPI is 1_ext and they understand that, they'll immediately know to check SUB_EAPI or whatever, which is as flexible as bash parsing is. If at some point in the future we want to go to XML based formats or whatever, we cross that bridge when we come to it and /then/ we do the filename thing, if it's still thought to be necessary. Meanwhile, other (master) EAPIs may yet be defined, if their practical use is restricted enough to fit within the strict first line EAPI=whatever rule above, and those could include further refinements on the SUB_EAPI theme if they become necessary, WITHOUT a multiplication if ebuild-xxx extensions. The big drawback I see here is the the forced delay until EAPI aware PMs can be assumed, but as I said, it seems that's going to be the case with the current proposal anyway, simply because of the amount of resistance to it and the delay in approval that's likely to mean, even if it /is/ ultimately approved. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
