Re: [gentoo-dev] Re: [gentoo-dev-announce] Submit project ideas NOW for Google Summer of Code 2012

2012-03-07 Thread Richard Yao
I am not a developer yet, but I would like to suggest some idea possibilities: Minix port of Gentoo Illumos port of Gentoo LLVM/Clang System Compiler Support ICC System Compiler Support (probably easier than LLVM/Clang) Port of Gentoo/FreeBSD to amd64 (or other architectures) Gentoo/FreeBSD KVM po

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Ulrich Mueller
> On Wed, 7 Mar 2012, Alec Warner wrote: >> *** Proposal 1: "Parse the EAPI assignment statement" *** >> [...] > I don't like this idea because the sane way should be easy and > straightforward. Mixing a constant declaration with bash assignment > just confuses users who think the assignment

[gentoo-dev] Re: [gentoo-dev-announce] Submit project ideas NOW for Google Summer of Code 2012

2012-03-07 Thread Robin H. Johnson
On Wed, Mar 07, 2012 at 11:38:47PM -0600, Donnie Berkholz wrote: > . If you > have project ideas, this is the place to put them. It's critical to also > include potential mentors and prerequisite skills so students know which > ideas

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Alec Warner
On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller wrote: > Hi all, > > The way how we currently specify the EAPI in ebuilds has some > problems. For example, there is no sane way to allow usage of features > of a new bash version in a new EAPI. So we are currently stuck with > bash 3.2. Also changes

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Jeroen Roovers
On Wed, 07 Mar 2012 17:36:05 -0500 Alexandre Rostovtsev wrote: > FYI, any Russian speaker is *guaranteed* to read the name ".eb" as a > very common obscenity. In Dutch it means the low tide, and as a verb, it means "becoming low" or "decreasing" as in the tide or some other fluid. In English it

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Ulrich Mueller
> On Wed, 07 Mar 2012, Michael Orlitzky wrote: > Someone suggested using a standard shebang the last time this came > up, and if I remember correctly it was one of the least-disagreeable > solutions proposed. We could of course define our own custom format, > but I think something like, >

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Alexandre Rostovtsev
On Wed, 2012-03-07 at 21:41 +0100, Ulrich Mueller wrote: > .ebuild -> .eb FYI, any Russian speaker is *guaranteed* to read the name ".eb" as a very common obscenity.

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Michael Orlitzky
On 03/07/2012 03:41 PM, Ulrich Mueller wrote: *** Proposal 2: "EAPI in header comment" *** A different approach would be to specify the EAPI in a specially formatted comment in the ebuild's header. No syntax has been suggested yet, but I believe that the following would work as a specification:

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread David Leverton
On 7 March 2012 21:07, Alexis Ballier wrote: > As i understand it, $PM will need to try the regexp tingy on any ebuild > anyway, guess the EAPI then source the ebuild with the right sourcer > to get the real EAPI and compare it. Not exactly... the idea with proposal 2) is that the header comment

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Alexis Ballier
On Wed, 7 Mar 2012 21:41:02 +0100 Ulrich Mueller wrote: > Hi all, > > The way how we currently specify the EAPI in ebuilds has some > problems. For example, there is no sane way to allow usage of features > of a new bash version in a new EAPI. So we are currently stuck with > bash 3.2. Also chan

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Ciaran McCreesh
On Wed, 7 Mar 2012 21:41:02 +0100 Ulrich Mueller wrote: > (I really hope for a constructive discussion here. So, if you want > to comment that all of the above proposals suck and GLEP 55 is much > superior, then please open a new thread for it.) I think if you want a constructive discussion, then

[gentoo-dev] RFD: EAPI specification in ebuilds

2012-03-07 Thread Ulrich Mueller
Hi all, The way how we currently specify the EAPI in ebuilds has some problems. For example, there is no sane way to allow usage of features of a new bash version in a new EAPI. So we are currently stuck with bash 3.2. Also changes of global scope behaviour, like addition of new global scope funct

Re: [gentoo-dev] Ruby keywording

2012-03-07 Thread Hans de Graaff
On Wed, 2012-03-07 at 08:00 +0100, "Paweł Hajdan, Jr." wrote: > It's trivial to set up x86 chroot on amd64 box, so I can't imagine > what's preventing people from creating such chroot, doing the testing > and keywording themselves. In my personal case what is preventing me is sheer and utter disi

Re: [gentoo-dev] Ruby keywording

2012-03-07 Thread Hans de Graaff
On Tue, 2012-03-06 at 23:17 +0100, Thomas Kahle wrote: > Ruby is an interpreted language, I don't see any > point in having every arch team do the testing for every small package. > Could the ruby team add ~x86 themselves after testing on ~amd64, or are > there compelling reasons to not do this?

Re: [gentoo-dev] Ruby keywording

2012-03-07 Thread Alexis Ballier
On Wed, 7 Mar 2012 15:54:49 +0100 Thomas Kahle wrote: > On 09:25 Wed 07 Mar 2012, Alexis Ballier wrote: > > On Wed, 07 Mar 2012 08:00:16 +0100 > > ""Paweł Hajdan, Jr."" wrote: > > > > Also the inter-bug dependencies are often not resolved > > > > correctly, that is the to be keyworded package de

Re: [gentoo-dev] Ruby keywording

2012-03-07 Thread Thomas Kahle
On 09:25 Wed 07 Mar 2012, Alexis Ballier wrote: > On Wed, 07 Mar 2012 08:00:16 +0100 > ""Paweł Hajdan, Jr."" wrote: > > > Also the inter-bug dependencies are often not resolved correctly, > > > that is the to be keyworded package depends on non-keyworded stuff > > > not listed in the bug. > > > >

Re: [gentoo-dev] Ruby keywording

2012-03-07 Thread Alexis Ballier
On Wed, 07 Mar 2012 08:00:16 +0100 ""Paweł Hajdan, Jr."" wrote: > > Also the inter-bug dependencies are often not resolved correctly, > > that is the to be keyworded package depends on non-keyworded stuff > > not listed in the bug. > > And this is even worse. Please check things with repoman befo