Mailing List Archive

On Mon, 24 Dec 2007 08:27:39 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> The problem right now is that while you are correct, that's the
> official list, due to technical/political issues, the Gentoo-official
> PMS repo doesn't (or didn't as of the last council meeting, according
> to the log) have any EAPI-1 info at all, as it's currently outdated,
> with the work all going into the off-Gentoo repo.

No no. The 'Gentoo-official' repo doesn't have any EAPI-1 info at all
because whoever's supposed to have set up the 'Gentoo-official' repo
hasn't bothered to tell any of the people doing the committing a) where
the repo is or how to commit to it, b) what the technical reasons for
moving away from the current repo are or c) who all has root on the box
upon which the repo is hosted. Even if any of the PMS contributors
*wanted* to commit to an official Gentoo repository, they couldn't
because neither the Council nor whoever did the setting up have
bothered to tell them about it.

> (Apparently, there aren't any official Gentoo devs working on PMS
> ATM. =8^( Did I mention political issues in addition to technical
> ones?)

So far as I'm aware, spb is still technically an official Gentoo
developer.

--
Ciaran McCreesh

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071224083819.003f0d26@blueyonder.co.uk, excerpted below, on Mon, 24 Dec
2007 08:38:19 +0000:

> Even if any of the PMS contributors *wanted* to commit to an official
> Gentoo repository, they couldn't because neither the Council nor
> whoever did the setting up have bothered to tell them about it.

That would appear to be part of the technical issues side. As I
understood the last council log discussion, the eventual idea is to
handle it similar to what's being done with Roy's RC or whatever it ends
up being called (formerly baselayout, proposed OpenRC shot down due to
preexisting trademark rights belonging to someone else), but infra hasn't
gotten the full thing setup yet, proper permissions and secure access and
all that. Apparently, at present, pretty much the only one with access
is the one who actually did the port, and he's hasn't done much with it
since.

Thanks for correcting the "no Gentoo people working on it" thing tho. I
couldn't understand quite /no/, tho it might be only one, SPB.

FWIW, I intended to post this link earlier but forgot to include it (tho
I did mention it was in the last council meeting log so those interested
knew what to look for, at least). The PMS discussion was last, the only
thing in Open Floor, which started at logged time 21:51 on line 311:

http://www.gentoo.org/proj/en/council/meeting-logs/20071213.txt

--
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

--
gentoo-dev@gentoo.org mailing list

On Mon, 2007-12-24 at 21:39 +0000, Duncan wrote:
> Apparently, at present, pretty much the only one with access
> is the one who actually did the port, and he's hasn't done much with it
> since.

I beg to differ - I've down an awful lot with the code.
It now installs and works cleanly on a vanilla FreeBSD.
man pages have been written for every userland tool and library function
it provides.
Init scripts now support a "template" system, based on Free/Net BSDs RC.
Lots of Gentoo reported bugs have been fixed.

Infact, the last of the planned changes have now been comitted to my
local repo and I'll be itching to make a release soon into the New Year.

Granted I'm waiting on Gentoo Infra to host it (the git repo) because
that is what we agreed. However I'm probably going to end up going with
someone else, or hosting myself, because it's now coming up to 2 months
and nothings ready yet. Heck, my retirement bug [1] is still pending and
I currently have full access to all my accounts on various boxes. So
either I'm a very trustable guy that you really don't want to retire
(tough, I have) or some people are slacking.

[1] http://bugs.gentoo.org/show_bug.cgi?id=199318

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

On Mon, Dec 24, 2007 at 11:00:44PM +0000, Roy Marples wrote:
> On Mon, 2007-12-24 at 21:39 +0000, Duncan wrote:
> > Apparently, at present, pretty much the only one with access
> > is the one who actually did the port, and he's hasn't done much with it
> > since.
>
> I beg to differ - I've down an awful lot with the code.
> It now installs and works cleanly on a vanilla FreeBSD.
> man pages have been written for every userland tool and library function
> it provides.
> Init scripts now support a "template" system, based on Free/Net BSDs RC.
> Lots of Gentoo reported bugs have been fixed.
>
> Infact, the last of the planned changes have now been comitted to my
> local repo and I'll be itching to make a release soon into the New Year.
>
> Granted I'm waiting on Gentoo Infra to host it (the git repo) because
> that is what we agreed. However I'm probably going to end up going with
> someone else, or hosting myself, because it's now coming up to 2 months
> and nothings ready yet. Heck, my retirement bug [1] is still pending and
> I currently have full access to all my accounts on various boxes. So
> either I'm a very trustable guy that you really don't want to retire
> (tough, I have) or some people are slacking.
> [1] http://bugs.gentoo.org/show_bug.cgi?id=199318
We're getting there.

Infra moves a bit slowly at times, because it's not all we do.
On the retirement side, I was holding off doing them, to get a larger
batch, that had their 1 month of notice today, if you search for bugs
with 'infra-retire' in the whiteboard right now, you'll find them until
I've got them completed.

The CVS stuff should have been locked out already, not sure how you
tested that.

The Git stuff is coming very shortly (probably as a Christmas gift from
infra tmrw), I've spent the last week or so on it. (I think the upstream
gitosis author is going to kill me, but meh, it had to be done to make
it work for Gentoo).

--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

On Mon, 2007-12-24 at 19:52 -0800, Robin H. Johnson wrote:
> The CVS stuff should have been locked out already, not sure how you
> tested that.

I didn't.
I assumed that as I had access to d.g.o, I had CVS access too.
My bad.

> The Git stuff is coming very shortly (probably as a Christmas gift from
> infra tmrw), I've spent the last week or so on it. (I think the upstream
> gitosis author is going to kill me, but meh, it had to be done to make
> it work for Gentoo).

Great!

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

Doug Klima schrieb:
> <Cardoe> zmedico: what if I have EAPI=2 above the inherit but an eclass
> has EAPI=1

if an eclass sets EAPI, then the ebuild shouldn't... make it two
eclasses if needed or plain bump them if really really needed.

Greetz
Jokey

Carsten Lohrke wrote:
> On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
>> * Eclasses may not set EAPI.
>>
>> * Eclasses may not assume a particular EAPI.
>
> I disagree here. It would be annoying and possibly even hindering in
> future not being able to use higher EAPI features in eclasses. Point is
> the eclass has to check, if the author of an ebuild sets another EAPI and
> throw an error, in this case.
>
Agreed. There's no problem from the bash side of this, only the PM specific
code.

> The most basic issue, which we didn't even discuss yet, afaik, is how to
> make every developer aware which feature belongs to which EAPI. I freely
> admit, I do not know that. Is there a list somewhere?
>
Well the official one is the internal Gentoo PMS repo. The Council haven't
changed the policy so far this term on what is the "authoritative" PMS.
(Nor of course have they accepted any of the drafts officially.)

> EAPI issues may lead to a lot of confusion and eclass bloat, especially
> since we still can't remove stale eclasses afaik.
>
Another maintenance headache, agreed.

Is it possible to remove an eclass if it can be shown that there are no apps
in the tree using it, say for over 2 years? That would give Gentoo
equivalence with longer-term "support" from other distros, while allowing
some breathing space wrt installed ebuilds. It'd be easy enough to automate
a hook to move deleted eclasses to local overlay as well.

> On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote:
>> Nobody said that eclasses can't use new features.
>
> Using new features in ebuilds or eclasses relates. EAPI A using ebuild
> with EAPI B using eclass (but not defining any EAPI) is your hard nut.
> Shouldn't happen, but will. And bugs in eclasses unfortunately don't have
> a minor impact.
>
>> Just that they
>> cannot _set_ EAPI or assume they are working with any EAPI.
>
> And I say they can - under the condition that you have a defined subset of
> ebuilds belonging to that eclass.

And it's a major loss of flexibility in addition to the maintenance problems
you highlight. A dynamic EAPI declaration in an ebuild is foolish, but
testing the EAPI value in an eclass and taking alternative action, or
indeed allowing dynamic setting in that context (which would require
additional metadata-- in this case i think the overhead is worth it, given
that eclasses are much less numerous than ebuilds, and it's actually
*adding* to what we can do already) makes a lot more sense.

<zlin> the kde4 eclasses in the kde4-experimental overlay set eapi=1.
<zmedico> it's fine to do that, it's just too early to do that on lots
of eclasses in the main tree, because EAPI=1 is too new

So there's no technical reason not to to, apart from some concern about
signalling die()?

<Cardoe> I think putting EAPI above inherit is bad
<Cardoe> because you're relying on the ebuild author to audit all the
eclass code to know which EAPI version is required

Ouch. Well at least EAPI anything is still experimental atm. Thank heavens
for peer review :D


--
gentoo-dev@gentoo.org mailing list