Re: [gentoo-dev] Good-bye
Seemant Kulleen wrote: > Dear Gentoo Devs and Users, > The time has finally come for me to resign from Gentoo. I've been Seemant, Thanks a lot for everything you've done for Gentoo. It's been really amazing to have you around and you'll be missed. Take care my friend and do stick around on IRC. PS : Aam chahiye kya? :) Note : The above line means "Do you want a Mango?" in Hindi. If any of you *ever* meet Seemant, don't forget to ask him this :D May the force be with you! -- Shyam Mani | <[EMAIL PROTECTED]> docs-team | http://gdp.gentoo.org devrel | http://devrel.gentoo.org infra | http://infrastructure.gentoo.org GPG Key| 0xFDD0E345 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Dec 25, 2007 2:38 AM, Roy Marples <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
> > On Dec 24, 2007 7:53 AM, Roy Marples <[EMAIL PROTECTED]> wrote:
> > > So to obtain EAPI from .ebuild you would always do
> > > EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
> >
> > Doesn't work with current ebuilds, nor future ebuilds. No points!
>
> Works fine as long as the functions the ebuild has in global scope
> exist. Which would assuming that the ebuild was sourced in a portage
> environment.
Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
1 environment, or what? What happens when EAPI 2 changes the behaviour
of inherit? What happens when EAPI 2 introduces a new global scope
function that sources a new kind of eclass that current package
managers don't support?
--
Ciaran McCreesh
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
> On Dec 24, 2007 7:53 AM, Roy Marples <[EMAIL PROTECTED]> wrote:
> > So to obtain EAPI from .ebuild you would always do
> > EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
>
> Doesn't work with current ebuilds, nor future ebuilds. No points!
Works fine as long as the functions the ebuild has in global scope
exist. Which would assuming that the ebuild was sourced in a portage
environment.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Dec 24, 2007 7:53 AM, Roy Marples <[EMAIL PROTECTED]> wrote:
> So to obtain EAPI from .ebuild you would always do
> EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
Doesn't work with current ebuilds, nor future ebuilds. No points!
--
Ciaran McCreesh
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)
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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)
On Mon, Dec 24, 2007 at 11:00:44PM +, Roy Marples wrote: > On Mon, 2007-12-24 at 21:39 +, 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 : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpR7JD896GL3.pgp Description: PGP signature
[gentoo-dev] Roy's retirement (Was: PMS location)
Roy Marples <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 24 Dec 2007 23:00:44 +: > On Mon, 2007-12-24 at 21:39 +, 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. I guess I was a bit ambiguous as I had mentioned your project in passing, but that remark as quoted was intended to apply to the Gentoo PMS repo, not your RC project (which I know has seen progress as I've been following the blog). Sorry for the confusion. > 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. ... So the remark, while intended for the Gentoo PMS repo, would seem to apply to the Gentoo repo for your project as well... Not to be hard on infra here, just reality, which must be dealt with. > 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. >From all the discussion I've seen, you /are/ trusted. The arrangement they are working on for you is the first of its kind (probably one reason it's taking the time it is), and I don't think something they'd have considered for just anyone. (If you note, the PMS repo thing, which they are treating similar, is documentation, not code, certainly not code that has been and will continue to be at the core of very close to every Gentoo box out there.) > [1] http://bugs.gentoo.org/show_bug.cgi?id=199318 I expect that's showing in the "lack of haste" in closing the retirement bug as well. You are still trusted and your code will continue to be at the center of Gentoo for the foreseeable future, so regardless of dev access or not you could still screw Gentoo over if that was your intent, and given that, well, there are just more pressing matters to attend to. That said, while flattered, I'd be bugged about it too if it were me. I know I'm sermonizing the choir here but crackers love stale but still active accounts, and it remains your name on the line, so yeah, there's reason for concern. -- 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
Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)
On Mon, 2007-12-24 at 21:39 +, 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 -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: PMS location (Was: Re: EAPI placement)
Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 24 Dec 2007 08:38:19 +: > 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 -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [Last Rites] sys-apps/mii-diag
# Raúl Porcel (24 Dec 2007) # Mask for removal on 24 Feb 2008 for treecleaners # Bug 195228, merged with net-tools sys-apps/mii-diag -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Confirm unsubscribe from [EMAIL PROTECTED]
Confirm unsubscribe from [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Just picked this particular email to reply with my thoughts on this
thread.
On Mon, 2007-12-24 at 10:52 +, Steve Long wrote:
> But they come under the scope of this discussion, since this is about the
> long-term future of *every* EAPI. So let's discuss them
Impossible. History has proven again and again that you cannot predict
every aspect of the future. But then I'm sure you know this ;)
File name suffixes historically describe the content structure of a
file.
.png means the content is a picture and it's structure is Portable
Network Graphic.
.ebuild means the content is instructions on how to install something
and it's structure is bash.
So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
Now say you wanted to move ebuilds into xml you would do
EAPI=`xmlcmd_to_extract_node_value /root/eapi /path/to/ebuild.xml"
In closing, EAPI describes features available, not content nor
structure.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 24 Dec 2007 11:19:18 + Steve Long <[EMAIL PROTECTED]> wrote: > > Which is fine. But then, the majority of devs shouldn't expect to be > > able to provide opinions when it comes to the more technical > > aspects. > > > Yes, but they can smell a nasty hack when they see one; starting with > the fact that the API is no longer as clean. Clearly not... > >> On a somewhat related note : I noticed that among the massive > >> thread, you have brought up several times the issue of cache > >> generation, saying that it was a complicated process. > >> > >> Maybe this process needs to be reworked before the whole EAPI issue > >> can be resolved? > > > > That's partly what the GLEP is doing. Making it any simpler, > > unfortunately, would involve either a huuge performance hit > > (we're talking two orders of magnitude here) or removing metadata > > from the ebuilds entirely -- neither of which are viable solutions. > > > Oh, I thought this wasn't about performance? Nor indeed about cache > generation. The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. In particular, making a typical emerge -pv world take of the order of 0.1s per c/p-v's metadata that's needed (as a very rough idea, we're talking a thousand upwards of these on a typical system) isn't even remotely feasible. And no, the GLEP doesn't directly address cache generation. But equally, it can't ignore it simply because without some form of static metadata cache package managers can't be implemented in a way acceptable to end users. You see, there's this thing called the "big picture"... -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])
On Mon, 24 Dec 2007 10:52:53 + Steve Long <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Mon, 24 Dec 2007 06:03:12 + > > Steve Long <[EMAIL PROTECTED]> wrote: > >> * Set the EAPI inside the ebuild in a way that makes it easy to > >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is > >> no backward compatibility issue. > > > > It's both a backwards and a forwards compatibility issue. > > > Yeah, so forwards into the future where it's impossible to maintain > this format (er..) there'll be another type of ebuild for your > purported long-term solution. Hopefully that'll be EAPI 2, and hopefully we're talking months rather than years. > > And eclasses are an entirely separate issue. They need to > > be dealt with differently, ideally starting with EAPI 2. > > > But they come under the scope of this discussion, since this is about > the long-term future of *every* EAPI. So let's discuss them. Ok. What technically sound ideas that have been implemented in a real package manager and tried out on a large, real tree maintained by multiple developers do you have about improving eclasses with respect to EAPI handling? I'm curious, because the only solutions we have for working with the current system are going to suck in the long term (but equally, they do work with EAPI 0/1, which means they're fine for short term), and I've yet to hear of a solution that is implementable (both theoretically and practically), usable from a tree perspective and scalable across EAPIs. To start you off, here's a list of ideas that suck: * Per-EAPI eclasses, or a master eclass that uses sub-eclasses for whichever EAPI is in use. This is the best general current solution, but it gets messy very quickly with new EAPIs. * Eclasses enforcing EAPI restrictions either by global scope or pkg_setup die. The former's illegal, breaks the metadata cache as it's done currently, and is way too easy for developers to screw up. The latter is way too easy for developers to screw up, results in users seeing the mess and doesn't allow package managers to work around it. * Variant: eclasses forcibly setting EAPI to OOPS-SOMEONE-SCREWED-UP if they don't support the eclass used. This one's actually ok from a package manager perspective, but lousy from a developer testing thing perspective. * Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor across EAPIs removing features, nor EAPIs changing eclasses. * Some kind of list of supported EAPIs in an eclass. Still has to deal with EAPI 0 and 1, and doesn't work well across multiple eclasses. * Banning eclasses from using anything that isn't supported in every EAPI. Makes new features rather useless, and removing things rather difficult... * Crazy hackery involving making 'inherit' look somewhere else in future EAPIs. At best you'd end up having stub eclasses (again with no particularly nice way of saying 'oops') to deal with EAPIs 0 and 1. * Introduce some new global scope eclass-like function that, combined with supported EAPI sets, does have a proper way of signalling 'not supported' (and throw in per cat/pkg eclasses because you can). Unfortunately, you can't do this without breaking current EAPI 0 / 1 package managers, unless you also switch file extensions or some equivalent op. All but the last of these are nowhere near good enough. The last one may or may not be OK as a starting point, but everyone I've spoken to who's worked with a real multiple EAPI repo agrees that it's a long way off being a good enough idea that it's worth considering having serious discussion about it. So go ahead and start discussing eclasses, if you want. But first I suggest getting lots and lots of experience and making damned sure you understand how everything works... -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 14:29:25 +0100 >> The majority of devs don't want to know how portage or paludis work >> internally, that's not what interests most of us. > > Which is fine. But then, the majority of devs shouldn't expect to be > able to provide opinions when it comes to the more technical aspects. > Yes, but they can smell a nasty hack when they see one; starting with the fact that the API is no longer as clean. >> On a somewhat related note : I noticed that among the massive thread, >> you have brought up several times the issue of cache generation, >> saying that it was a complicated process. >> >> Maybe this process needs to be reworked before the whole EAPI issue >> can be resolved? > > That's partly what the GLEP is doing. Making it any simpler, > unfortunately, would involve either a huuge performance hit (we're > talking two orders of magnitude here) or removing metadata from the > ebuilds entirely -- neither of which are viable solutions. > Oh, I thought this wasn't about performance? Nor indeed about cache generation. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh wrote: > On Mon, 24 Dec 2007 06:03:12 + > Steve Long <[EMAIL PROTECTED]> wrote: >> * Set the EAPI inside the ebuild in a way that makes it easy to >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is no >> backward compatibility issue. > > It's both a backwards and a forwards compatibility issue. > Yeah, so forwards into the future where it's impossible to maintain this format (er..) there'll be another type of ebuild for your purported long-term solution. >> * Have a new ebuild/eclass extension ".eapi-$EAPI" >> This is for ebuilds for other package managers; it is envisaged by >> some that this will become the new ebuild format since it enables >> quick access to the EAPI without accessing the file contents. > And eclasses are an entirely separate issue. They need to be dealt with > differently, ideally starting with EAPI 2. > But they come under the scope of this discussion, since this is about the long-term future of *every* EAPI. So let's discuss them. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] PMS location (Was: Re: EAPI placement)
On Mon, 24 Dec 2007 08:27:39 + (UTC) Duncan <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Steve Long <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 23 Dec 2007 21:01:15 +: > I don't accept that I took it to that level, but I apologise > unreservedly for responding to it. Thanks. Now to leave it behind. -- 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: EAPI placement
Steve Long <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 24 Dec 2007 05:51:34 +: >> 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.) 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. (Apparently, there aren't any official Gentoo devs working on PMS ATM. =8^( Did I mention political issues in addition to technical ones?) Thus, one can get detailed but unofficial specs from the informal non- Gentoo repo, or a general summary as in the new-version portage announcement mentioning EAPI-1 support, now, or look at the code of the various PMs. =8^( >> 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. Well... according to the portage devs (as posted on the portage devel list) newer portage now stores the complete build environment, including the state of all inherited eclasses at the time of the original merge, and uses them at unmerge if at all possible. If the merge was from an older version before this info was stored, or if the package database is corrupted and thus is otherwise missing the complete eclass info, portage can and does still pull from the live tree. Thus, in theory, a year or so after the first version with that functionality working goes/went stable (I don't track stable status as I'm on ~arch, so I've no idea if it's stable yet or not, or for that matter which version first qualified), it should then be possible to start removing old/stale eclasses, keeping in mind that even after they are removed, if someone /really/ needs them, they can still fetch them out of the source control system attic. So in any case, it should be possible <2 years from now; just not yet. -- 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
