16:00 <@dev-zero> ok, let's start the roll-call 16:00 * dertobi123 his here and grabs another beer 16:00 * lu_zero is present 16:00 * Naib joins Sput. 16:00 <@dertobi123> is* 16:00 < Naib> I has beer Sput 16:00 * lu_zero takes some water 16:01 < zmedico> dev-zero: yeah 16:01 <@dev-zero> zmedico: cool :) 16:01 * ulm is here 16:01 <@leio> here 16:01 <@dertobi123> so, we're waiting for Cardoe and Betelgeuse, right? 16:02 <@dev-zero> yes 16:02 <@dev-zero> Cardoe: ping? 16:02 <@dev-zero> Betelgeuse: ping? 16:02 <@Cardoe> pong 16:02 <@dertobi123> heya Cardoe 16:03 <@dev-zero> just updated the agenda again to match the one I posted 16:03 <@dev-zero> Betelgeuse: please call in asap 16:03 <@dev-zero> let's get started 16:03 -!- Ron_157 [n=Matt@DSL01.212.114.237.250.ip-pool.NEFkom.net] has joined #gentoo-council 16:03 <@dev-zero> Donnie decided to resign 16:04 <@Cardoe> dertobi123: hey 16:04 <@Betelgeuse> dev-zero: \o/ 16:04 <@dev-zero> the next person on the list are: ssuominen and ulm 16:04 <@dev-zero> Betelgeuse: heya :) 16:04 <@dev-zero> ssuominen decided to leave the spot to ulm 16:05 <@dev-zero> so, unanonymous vote please 16:05 <@Cardoe> ulm: are you present? 16:05 <@dertobi123> he is 16:05 < ulm> Cardoe: yep 16:05 <@lu_zero> ulm =) 16:05 <@Cardoe> yes for ulm 16:05 <@dev-zero> yes for ulm 16:05 <@dertobi123> welcome ulm ;) 16:05 <@lu_zero> ulm welcome =) 16:06 < ulm> thanks :) 16:06 <@leio> yes for ulm 16:06 <@Betelgeuse> yes 16:06 -!- mode/#gentoo-council [+o ulm] by dev-zero 16:06 <@dev-zero> good, that was quick :) 16:07 <@dev-zero> can we move to the next topic? 16:07 <@dertobi123> yes 16:07 <@dev-zero> zmedico: what's the progress on eapi-3 implementation in portage? 16:08 <+tanderson> I'm here 16:08 < zmedico> dev-zero: almost nothing so far. only stuff is what you've given me patches for. however, I hope to make time to get it all done pretty soon. 16:08 <+tanderson> dev-zero: yeah, I've been logging the whole thing 16:09 -!- aknm [n=aknm@5acabe73.bb.sky.com] has joined #gentoo-council 16:09 -!- spatz [n=spatz@unaffiliated/spatz] has joined #gentoo-council 16:09 <@dev-zero> zmedico: ok, thanks 16:10 <@dev-zero> I guess there's nothing more we could do besides start coding to speed up the process, is there? 16:10 <@Betelgeuse> zmedico: Jugding from past experience that's anything from days to a year :) 16:10 <@Betelgeuse> dev-zero: Writing code is recommended for everyone. 16:10 < zmedico> Betelgeuse: yeah, but I don't expect the eapi3 stuff to be much work. just need to make time for it 16:11 <@dev-zero> Betelgeuse: maybe we should point out that many features are not that hard to implement, just need a bit of bash and/or python knowledge 16:11 <@lu_zero> basically patches welcome? 16:11 <@Betelgeuse> dev-zero: Indeed. 16:11 <@leio> lets rewrite portage in C, then I can help *g 16:11 <@Betelgeuse> dev-zero: The barrier of entry for some of them shouldn't be that high and maybe it would encourage further contributions. 16:11 -!- xake [n=xake@liten.csbnet.se] has joined #gentoo-council 16:11 <@lu_zero> leio ok =P 16:11 <+tanderson> I could take a look at making some patch for the bash things 16:11 <+tanderson> *patches 16:11 < Calchan> zmedico, how about asking your recruit to help you ? 16:12 -!- marens [n=marens@unaffiliated/marens] has joined #gentoo-council 16:12 < zmedico> Calchan: good idea, will do 16:12 <+tanderson> zmedico: I never did get around to rewriting ebuild.sh to be more eapi-friendly,did I :/ 16:13 < zmedico> well, it works fine as is 16:13 <+tanderson> zmedico: yeah, but it's a tad messy 16:13 -!- spaceinvader [n=desktop@unaffiliated/spaceinvader] has joined #gentoo-council 16:13 < zmedico> yeah, could use some cleanup 16:14 <@lu_zero> zmedico you may try to point some tasks you'd like to see patches in your blog 16:14 <@Betelgeuse> dev-zero: Next topic time? 16:14 <@dev-zero> Betelgeuse: I think so 16:14 <@dev-zero> zmedico: jup, that would be great :) 16:14 < zmedico> lu_zero: good idea, will do 16:14 <@dev-zero> zmedico: thanks for reporting :) 16:14 <@dev-zero> ok, next topic 16:15 < zmedico> you're welcome 16:15 <@dev-zero> removing old eclasses 16:16 <@dev-zero> as Betelgeuse pointed out it would only be a problem for packages where the vdb entry has been generated with a very old portage version 16:16 <@dev-zero> or when using a portage version older than 2.1.4 16:16 <@dev-zero> is that correct? 16:16 <@leio> do I get it right that if user has packages using eclasses that have been removed, all he has to do is upgrade portage before upgrading or removing other stuff to get the environment.bz2 used that has been saved for lots more than since a year? 16:16 <@ulm> zmedico: when exactly was Portage 2.1.4 stabilised? 16:16 <@dev-zero> leio: I did understand it that way as well, yes 16:17 * dertobi123 too 16:18 <@dev-zero> it seems something around a year ago 16:18 < peper> and how horribly <2.1.4 fails at uninstallation? i.e. is it just a case of upgrading and trying again or something is screwed up in the process? 16:18 < zmedico> ulm: around march, 2008 16:20 <@dertobi123> it was mid-february last year according to the changelog 16:20 <@leio> I think it would be fine to remove eclasses once we map out which ones are used by portage and its deps and limit any compatibility breaking impact there 16:20 <@ulm> dertobi123: 2008-02-18 according to bug 210031 16:20 < Willikins> ulm: https://bugs.gentoo.org/210031 "sys-apps/portage-2.1.4.4 stable request"; Portage Development, Conceptual/Abstract Ideas; RESO, FIXE; zmedico@g.o:dev-portage@g.o 16:20 <@Cardoe> The packages that don't know what repo they were generated with are generated with which Portage? 16:20 -!- lavajoe [n=joe@mail.boulder.swri.edu] has joined #gentoo-council 16:20 <@Cardoe> the ones that say "[?=>0]" 16:21 <@dertobi123> ulm: yep, that was the one i found, too 16:21 <@Cardoe> cause if that's 2.1.4, then I still have packages that were recently upgraded with that version 16:21 <@dev-zero> zmedico: ^^ ? 16:21 -!- marens [n=marens@unaffiliated/marens] has left #gentoo-council [] 16:22 <@Betelgeuse> Yeah many people never run emerge -e world 16:23 <@Betelgeuse> I don't really see what's the big benefit of being able to rm a couple files? 16:23 <@dertobi123> i don't, too 16:23 <@dertobi123> mark them as deprecated and we're done 16:24 < zmedico> Cardoe: repo labels in /var/db/pkg are in >=portage-2.1.5 iirc 16:24 <@dev-zero> maybe make anything not needed for uninstall unusable? (by using die in src_install/src_compile/etc) 16:24 <@Cardoe> zmedico: and what file is that stored in? 16:24 <+tanderson> dertobi123: you could even put a die in pkg_setup or something 16:24 <@Betelgeuse> dev-zero: That's been the practise 16:24 <@dev-zero> Betelgeuse: ah, ok 16:24 <@Betelgeuse> dev-zero: see debug.eclass 16:25 < zmedico> Cardoe: /var/db/pkg/*/*/repository 16:25 <@dertobi123> tanderson: exactly ... 16:26 <@dev-zero> well, we already drop enough bugs on our users, I don't like risking even more 16:26 <@dertobi123> agreed 16:26 <@Cardoe> so we can see what directories are missing /var/db/pkg/*/*/repository 16:26 <@dev-zero> Cardoe: but that isn't related to environment.bz2, is it? 16:27 <@Cardoe> and that'll give you a guess at seeing that that some packages are made with an old portage 16:27 <@Cardoe> dev-zero: I thought we were talking about when eclasses were included in environment.bz2 16:27 <@leio> by my understanding that's a lot before 2.1.4 16:28 <@dev-zero> Cardoe: yes, but repository is included with portage >=2.1.5 and environment.bz2 got generated by even older portage but not used 16:28 <@dev-zero> ok, can we come to a conclusion here? 16:28 <@dertobi123> guess we can quickly vote on that 16:28 <@Cardoe> dev-zero: right so my check tells you what vdb's were created with 2.1.4 and older 16:28 <@dev-zero> leio, lu_zero, ulm, Cardoe: what's your opinion on this? 16:28 <@leio> repeating from before: I think it would be fine to remove eclasses once we map out which ones are used by portage and its deps and limit any compatibility breaking impact there 16:29 <@ulm> if it's only a little more that a year ago, then IMO it's too risky to allow removing 16:29 <@lu_zero> as a general rule I'd keep 6 month of deprecation, make sure an upgrade path is available as leio said 16:29 <@ulm> after all, the benefit is very small 16:29 <@lu_zero> and do the cleanup if is deemed useful 16:29 <@Cardoe> I'm with ulm on this one 16:30 <@dev-zero> that leaves us with "wait a bit longer to remove eclasses"? 16:30 <@leio> does that have to be mean about all eclasses? 16:31 <@dev-zero> well, graph theory is non-trivial, so I don't consider myself smart enough to ensure that a given eclass doesn't show up in a dep-tree when updating portage 16:31 <@leio> there's a difference between eclasses that portage and its deps depend on and eclasses that only a limited set of packages used, and all those revisions of such packages were removed two years ago 16:31 <@dertobi123> leio: eclasses which were introduced after portage-2.1.4 went stable might be an exception (though the number of those eclasses isn't that large, i guess) 16:32 <@ulm> dertobi123: that makes sense 16:32 <@leio> maybe the community can bring example of which eclasses they'd like to remove 16:33 <@dev-zero> kde has been mentioned 16:33 <@Betelgeuse> GLEP 55 allows us to use a new eclass approach etc 16:33 <@Betelgeuse> so the old ones can just be left to rot 16:33 <@dertobi123> unused eclasses are marked as deprecated and it's functionality except uninstall-related stuff removed, and that for a minimum of 2 years before final removal 16:34 <@dertobi123> what about that? (and the exception i stated above) 16:34 <@ulm> dertobi123: +1 16:34 <@dev-zero> dertobi123: sounds good 16:34 <@lu_zero> dertobi123 fine 16:34 <@dertobi123> so we have 4 yes on that :) 16:34 <@dertobi123> any "no"s? 16:35 <@Betelgeuse> I don't really see a need for a time limit like that 16:35 <@leio> I take it as something that can be relaxed once more time has passed 16:35 <@dev-zero> where do we write that down? 16:35 <@Betelgeuse> I would just leave the empty ones there 16:35 <@dertobi123> dev-zero: meeting agenda, dev-manual, anywhere else? 16:35 <@dev-zero> dev-manual mainly I think 16:36 <@Betelgeuse> Otherwise if we keep the flat namespace someone might accidentally resurrect an eclass with different behavior 16:36 <@dev-zero> tanderson: can you do the update perhaps? 16:36 <@Cardoe> dev-zero: dev-manual for sure 16:36 <@Cardoe> dev-zero: I'd file a ticket for that 16:37 <@Cardoe> alright let's get moving on the agenda items 16:37 <@Cardoe> got about 20 min left 16:37 <@dertobi123> yeah 16:38 <@dev-zero> good 16:38 <@leio> instead of keeping empty ones, there could be a cvs or git hook to disallow resurrection 16:39 <+tanderson> dev-zero: for eapi 3? 16:39 <@leio> however initially I thought the intention of keeping empty ones around idea was to keep the inherit calls from old package revisions being uninstalled to not error out on missing eclasses 16:39 <+tanderson> dev-zero: or deprecating unused eclasses? 16:39 -!- codejunky [i=jan@nerdig.org] has joined #gentoo-council 16:39 <@dev-zero> tanderson: deprecating unused eclasses 16:39 <+tanderson> right. 16:40 <+tanderson> can do. Probably after my summary is finished though :) 16:40 -!- codejunky [i=jan@nerdig.org] has left #gentoo-council [] 16:40 <+tanderson> leio dislikes waiting :p 16:40 <@dev-zero> tanderson: otherwise please open a bug for it 16:40 <+tanderson> ok 16:40 <@dev-zero> leio: can we discuss it on-list or later on? 16:40 <@leio> sure. 16:40 <@dev-zero> ok 16:40 <@leio> (I'll be gone till Monday after meeting though, fyi) 16:41 <@dev-zero> let's move on: Handling EAPI versioning in a forwards-compatible way 16:41 <+tanderson> If I don't get it done this weekend I'll file a bug. Usually I just poke halcy0n with patches 16:41 <@dev-zero> ok, Ferris proposed a good way to maybe shed some light on that issue 16:42 <@dev-zero> are we all clear what the problems are GLEP55 tries to solve? 16:42 <@leio> Not completely. 16:42 <@lu_zero> dev-zero some are still disputing them 16:42 -!- windzor [i=windzor@goatse.baconsvin.dk] has quit [SendQ exceeded] 16:43 <+tanderson> mmm 16:43 <+tanderson> what specifically is not understood about the purpose? 16:43 <@leio> some things it tries to solve seem like things that are not a problem that needs solving 16:43 <@ulm> dev-zero: the glep in its current wording doesn't make clear what the problem is 16:44 < ciaranm> what's unclear about the four bullet points describing the problems? 16:44 <+tanderson> leio: -scm? 16:44 <@lu_zero> tanderson from what I see from a cursory read the items listed as "problems" aren't believed to be problems at all 16:44 < NeddySeagoon> GLEP 55 could use some editorial work. There is more useful info in emails than in the glep 16:44 <@leio> -scm does not need an extension change. 16:44 <@dertobi123> ulm: right 16:44 < ciaranm> please point out which of the four bullet points listing the problem needs clarifying 16:44 <@leio> this discussion will go downhill from this point. 16:44 <@dertobi123> as usual 16:44 * dertobi123 sighs 16:45 <+tanderson> leio: we do not want per-package eclasses at all? I do certainly 16:45 < ciaranm> if someone could say which of the bullet points they think isn't clear enough, i'm sure the glep could be updated to address that 16:45 < bonsaikitten> ciaranm: they do not list the problem but a potential solution 16:45 <@leio> tanderson: good for you. There are other ways to achieve that. 16:45 <@Betelgeuse> Who wants to us VAR+="addition" in global scope? 16:45 <@Betelgeuse> s/us/use/ 16:45 -!- alip [i=alip@unaffiliated/alip] has joined #gentoo-council 16:46 < ciaranm> bonsaikitten: the four bullet points under the Problem title, please 16:46 <@dev-zero> bonsaikitten: no, they don't. Please read "current behaviour" in the glep 16:46 < bonsaikitten> which version are we talking about btw? 16:46 <@Betelgeuse> http://www.gentoo.org/proj/en/glep/glep-0055.html 16:47 < bonsaikitten> Betelgeuse: that's not the current version 16:47 <@lu_zero> ciaranm I'd say 16:47 <@lu_zero> all. 16:47 <@lu_zero> either by their vague definition 16:47 <@lu_zero> or their circularity 16:47 < ciaranm> lu_zero: ok, let's start with "Change the behaviour of inherit in any way (for example, to extend or change eclass functionality)". what's the problem with that one? 16:47 <@lu_zero> ciaranm case 1: vague definition 16:47 < NeddySeagoon> lets not waste the meetings time - lets just fix the glep 16:47 < ciaranm> lu_zero: what specifically is vague, that you don't understand? 16:48 <@Betelgeuse> NeddySeagoon: Do you have a patch in mind? 16:48 < ciaranm> NeddySeagoon: that's what we're doing. we're finally getting someone to say specifically what they think needs fixing. 16:48 <@Betelgeuse> NeddySeagoon: Feel free to submit one. 16:48 < ciaranm> NeddySeagoon: if lu_zero could explain exactly what he thinks is wrong with the four bullet points, we can fix them 16:48 <@dev-zero> jup, that's the point of it 16:48 <@lu_zero> ciaranm "in any way" doesn't explain which way 16:49 <@lu_zero> and could be merged with the point 2 16:49 <@Cardoe> This is a constant struggle. 16:49 < NeddySeagoon> Betelgeuse, as I suggested on on -ml it needs a rewrite to include much of the missing information, that is available in the emails 16:49 <@lu_zero> and there "sane" isn't defined 16:49 <@Cardoe> People are confused about some wording 16:49 < fmccor> bonsaikitten, It's dated 17 May 2009. You have something more recent? 16:49 <@Cardoe> and they just want clarification 16:49 < ciaranm> lu_zero: so if we add in links to the pms "future eapi request" bugs that give examples of ways that people want inherit to be changed, you'd be happy with that? 16:49 <@Cardoe> there's no need to be defensive and get in a fight 16:49 < bonsaikitten> fmccor: it shows ver. 1.4, cvs has a 1.5 16:49 <@Cardoe> explain it to the person 16:49 <@Cardoe> if more then 1 person is confused. 16:49 < ciaranm> Cardoe: i'm trying to establish exactly what people don't understand or want changed 16:50 < ssuominen> ulm: to old msg, good :) 16:50 <@lu_zero> ciaranm if that manages to get less people going berserk when you proposed that in ml probably. 16:50 <@Betelgeuse> Let's go this way. Who thinks being able to use VAR+="addition" in global scope is useless? 16:50 < ciaranm> lu_zero: ok, second bullet point. "Add new global scope functions in any sane way.". what is your problem with that statement? 16:50 < NeddySeagoon> ciaranm, references to other docs are only useful if the reference docs will not change 16:50 <@ulm> Betelgeuse: nobody needs this 16:50 <@leio> "Easily fetchable EAPI inside the ebuild" sounds like a good way to start with solving the thing that is the agenda topic - "Handling EAPI versioning in a forwards-compatible way" 16:50 < bonsaikitten> Betelgeuse: nicely loaded question 16:50 < peper> bonsaikitten: it's the current version. probably some cvs/web-sync screw-up 16:50 <@leio> because it merely makes it a rule something that already is a QA policy 16:51 <@lu_zero> ciaranm define "Sane" 16:51 < ciaranm> lu_zero: would it help if we add in links to bugs where people are requesting new global scope functions? 16:51 < bonsaikitten> peper: oh fun ... so which version is authorative? 16:51 <@Betelgeuse> ulm: why? 16:51 <@lu_zero> inherit is a global scope function or not btw? 16:51 < peper> bonsaikitten: it's the same version 16:51 < ciaranm> lu_zero: inherit's an existing global scope funtion, not a new one 16:51 < drantin> it's outside a stage, so it's global 16:51 <@ulm> Betelgeuse: because you can do it in a different way? 16:51 <@lu_zero> ciaranm inherit2 would be 16:51 < ciaranm> lu_zero: and inherit has its own special problems unrelated to adding new functions 16:52 <@lu_zero> or inherit with optional parameters 16:52 <@lu_zero> anyway it's digressing 16:52 <@dev-zero> NeddySeagoon: would it be sufficient to add examples for stuff where "in any way" is written? 16:52 <@Betelgeuse> ulm: We should write longer code on purpose when we could get away with new syntax? I don't see any benefit to sticking with old bash syntax. 16:52 < ciaranm> lu_zero: bullet point 4. what don't you understand about "use newer bash features."? 16:52 < ciaranm> lu_zero: would you like a list of newer bash features that we could use? 16:52 <@lu_zero> ciaranm I think it would help a lot 16:53 < ciaranm> lu_zero: ok, easily done. and bullet point three: "Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely.". what's wrong with that? 16:53 <@ulm> Betelgeuse: it's no so much longer, probably on the few percent level 16:53 <@lu_zero> it's circular. 16:53 < ciaranm> lu_zero: how is it circular? 16:53 < NeddySeagoon> dev-zero, that will help. I understand the reason for the glep and support it aims. 16:53 <@lu_zero> glep54 isn't accepted 16:53 < ciaranm> lu_zero: glep 54 is merely an example 16:53 <@dev-zero> NeddySeagoon: good, will happen then 16:54 < ciaranm> lu_zero: it also lists other examples of things we might want to do 16:54 < bonsaikitten> ciaranm: we might want to keep the status quo 16:54 <@ulm> ciaranm: who is "we"? 16:54 <@Betelgeuse> ulm: Well bash syntax evolves constantly and there's other things too. But as said a couple lines up there will be a list. 16:54 <@dev-zero> lu_zero: even your .live extension depends on it 16:54 < ciaranm> ulm: people who submit feature requests for future eapis 16:54 < NeddySeagoon> dev-zero, I can volunteer some editorial time, if that helps. 16:54 <@lu_zero> dev-zero I know 16:54 < ciaranm> lu_zero: would you like us to remove the specific examples from the third bullet point whilst we're adding them in to the other three? 16:55 <@lu_zero> ciaranm as I said 3 are vague, one is circular 16:55 < ciaranm> lu_zero: please explain the circular thing 16:55 < ciaranm> lu_zero: glep 54 is merely one example of a thing we'd like to do 16:55 < Sput> isn't the real problem g55 should be solving "how to figure out EAPI prior to sourcing", and shouldn't the discussion center around how to achieve that best? 16:55 <@dev-zero> lu_zero: ... and your glep is another example 16:55 <@Betelgeuse> I guess he means that go hand in hand but I don't see how it makes GLEP 55 worse. 16:56 <@lu_zero> dev-zero none of them are accepted 16:56 < ciaranm> lu_zero: if that bullet point instead said "Extend versioning rules in an EAPI, for example to allow version formats like 1-rc1, 1-alpha etc. to match upstream more closely", would you be happy? 16:56 < NeddySeagoon> ciaranm, do you already have glep 54 and 55 implemented in paludis ? 16:56 < ciaranm> lu_zero: they can't be accepted until glep 55 is 16:56 <@dev-zero> NeddySeagoon: yes 16:56 < ciaranm> NeddySeagoon: 54, yes. 55, more or less, although not for the specific suffixes we're asking for (it's used by exheres and kdebuild) 16:56 <@lu_zero> so you don't need glep 55 if people agree live ebuild or scm version rules are useful 16:57 -!- alip [i=alip@unaffiliated/alip] has left #gentoo-council [] 16:57 <@Betelgeuse> how do you do -scm without 55? 16:57 < ciaranm> lu_zero: you need glep 55 if you want any of the bullet points, or if you want -rc support or so on 16:57 <@Betelgeuse> And no user visible breakage. 16:57 < lack> Betelgeuse: Easy -> Wait a year 16:57 <@Betelgeuse> or year wait 16:57 < NeddySeagoon> ciaranm, maybe that explains why glep55 needs to be read from the bottom up. You are too close to the problem and perceived solution to document it well 16:57 <@leio> there is no need to wait for a year 16:58 <@leio> to introduce -scm or -live 16:58 <@dev-zero> leio: can you explain that please? 16:58 <@Betelgeuse> dev-zero: I propose having a vote on if the council thinks the problems as worthy. 16:58 < ciaranm> NeddySeagoon: stop thinking of the abstract and title as part of the main body 16:58 < peper> NeddySeagoon: just fyi, I wrote the glep :) as can be easily seen by english quality probably :) 16:58 <@dev-zero> Betelgeuse: and then update them according to what we discussed today? 16:58 < ciaranm> lu_zero: so if we update those four bullet points the ways we discussed, you'll be happy? 16:59 <@Betelgeuse> dev-zero: I only see clarifications coming out of this. 16:59 < NeddySeagoon> ciaranm I'm not. The body is very thin too 16:59 -!- xake [n=xake@liten.csbnet.se] has quit [Client Quit] 16:59 < ciaranm> NeddySeagoon: please point out specific areas where you'd like it fattened up 16:59 <@lu_zero> ciaranm I see people complaining about that so I hope that will make the thing more acceptable to that point 16:59 <@lu_zero> then there is the rest 16:59 <@leio> dev-zero: you simply have portage warn about an unrecognized atom for people with old portage. One line warning per package seen that has a -scm revision, nagging them even further to finally upgrade their package manager for doing, duh, package management. Nothing catastrophic to my knowledge. 16:59 <@Betelgeuse> dev-zero: And if you understand the problem domain you don't need any concrete wording for voting 16:59 < ciaranm> leio: did you see the mess last time that happened? 17:00 <@leio> No. 17:00 <@lu_zero> I don't see benchmarks yet I have most of the alternate proposals ruled as resource heavy 17:00 <@dev-zero> Betelgeuse: ok, agreed for the voting 17:00 <@dev-zero> ok, people 17:00 < NeddySeagoon> ciaranm, I would like objective, quantitive measurements of the main potential solutions included in the GLEP. Some have been posted to the -ml, so they are probebly available 17:00 <+tanderson> This is a vote on the 'problem' not the solution, right? 17:00 < Calchan> what the glep really needs is summarizing what was said on the list, and I know that ciaranm is going to say that very little to none of it is valuable but many will disagree with that 17:00 <@ulm> leio: do you remember if there were any serious problems when multiple _pre, _rc, etc. were allowed? 17:00 <@dertobi123> NeddySeagoon, Calchan: agreed 17:01 <@lu_zero> and possibly reproducible by third party easily 17:01 <@dev-zero> tanderson: yes 17:01 <@leio> ulm: I don't remember, but that's a reason why I don't see it reasonable to change versioning rules to track upstream better. 17:01 <+tanderson> Calchan: I could clarify some points of the problem part. I just need concrete emails on which parts are confusing and why they are confusing 17:01 < NeddySeagoon> lu_zero, auditable anyway 17:01 <@dev-zero> ok, can we please get votes for whether the problems mentioned in the glep are worth to get solved? 17:01 <@ulm> leio: I also see no need for things like "-rc" instead of "_rc" 17:01 <@Betelgeuse> I vote yes. 17:02 < Calchan> tanderson, that's the hard part, digging the interesting stuff from all these useless flamewars 17:02 <@dertobi123> in general, yes 17:02 <@dev-zero> I vote yes. 17:02 <@lu_zero> I asked them to be clarified so count me as a yes with reserve 17:02 <+tanderson> Calchan: indeed. I'm actually considering asking for _private_ emails so I don't have all the back-and-forth 17:02 <@dev-zero> good, that makes 4 17:03 <@lu_zero> dev-zero that makes me a no if they aren't clarified 17:03 <@dev-zero> so, glep authors: please update the glep as discussed here 17:03 <@dev-zero> lu_zero: yes, I understand that 17:03 * ulm doesn't see a basis to vote about the glep in its current wording 17:03 <@Betelgeuse> ulm: We are not voting about the GLEP at all 17:03 <@dev-zero> ulm: it's not about the glep, only about the problems mentioned 17:03 <@leio> I agree there are things to solve for bullet points 1, 2 and 4, but do not agree with glep55 being the best way to do that. 17:03 <@dertobi123> ulm: we're not voting about the glep, but the problems described 17:03 <@dertobi123> i'd like to vote the next meeting on whether to approve on of the mentioned solutions 17:03 <@dertobi123> and only to vote. 17:03 <@dev-zero> leio: ok, that's the only thing we wanted to know :) 17:04 <@dertobi123> otherwise this will become a neverending story ... 17:04 <@dev-zero> dertobi123: but this discussion was probably one of the most productive ones we had about it 17:04 <@leio> I am heavily against voting on stuff that is not clear only to "get it under the carpet" 17:04 < Calchan> I'd like everybody to note that there seemed to have been an informal consensus on the third solution in the list of three that peper proposed in http://archives.gentoo.org/gentoo-dev/msg_959451961983a52129e3f41cd87eac0e.xml 17:04 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council 17:05 <@dertobi123> leio: there are again 14 days to get those things sorted 17:05 < NeddySeagoon> ciaranm, if the council pick an in ebuild solution, how much work do you have to redo ? 17:05 <@ulm> Calchan: that would be "Easily fetchable EAPI inside the ebuild"? 17:05 < ciaranm> NeddySeagoon: we can implement anything we want in paludis. it's not portage, you know :P 17:06 <@dertobi123> ulm: plus extention change, "easily fetchable eapi inside the ebuild" wasn't mentioned in peper's mail 17:06 < NeddySeagoon> dev-zero, thats good design, break the problem into small pieces and address each piece. Recursively as needed 17:06 < Calchan> ulm, yes with for example a .eb extension and eapi in she-bang 17:06 <@dertobi123> and that's another thing i dislike 17:06 <@dertobi123> extension* even 17:06 <@dev-zero> ok, I think that topic is over for today 17:06 < NeddySeagoon> ciaranm, I was thinking wasted effort 17:06 < peper> dertobi123: hmm? 17:06 < ciaranm> NeddySeagoon: eh, exherbo's using it anyway 17:06 <@dev-zero> reserve solutions to the problems for the next 14 days and the next meeting, please :) 17:07 < peper> dertobi123: it wasn't cause I hate it. you are free to like it :) 17:07 < NeddySeagoon> ciaranm, I think you went with eapi in filename ? 17:07 <@Betelgeuse> coding and changin wording is nothing compared to what people seem to be using for mailing on lists 17:07 <@dev-zero> is someone on the run or can we peek into the next topic? 17:07 <@dertobi123> peper: if the glep mentiones 4 solutions i'd expect to put all of them up for discussion on the ml and not to hide a solution you personally dislike. 17:07 < ciaranm> NeddySeagoon: oh, you mean, you want someone to code in-ebuild-eapi support? can do that, if the council decides it doesn't want to take the best solution 17:07 < peper> dertobi123: err, the list was labeled: "Just FYI, my order of preference of solutions is:" 17:07 * dertobi123 needs to go to bed somewhat soonish 17:08 < fmccor> dertobi123, It's in GLEP55 (alternative 3 or idea 4, depending on where you start counting) 17:08 < peper> i listed 2. and 3. just to show I can live with them 17:08 <@dertobi123> fmccor: sure 17:08 < NeddySeagoon> ciaranm, the objective evidence for 'best solution' is still missing 17:08 <@dev-zero> ok, the next topic: 17:08 <@Betelgeuse> dev-zero: I need to finish a task for tomorrow. 17:08 <@Betelgeuse> dev-zero: I will glance every once in a while 17:08 <@dev-zero> Betelgeuse: fine by me 17:09 <@Cardoe> dev-zero: we're over time.. have we decided to extend? 17:09 <@dev-zero> ok, next topic (just to get an idea). 17:09 < ciaranm> NeddySeagoon: objectively, you have to either not change version format rules ever, or force the package manager to open() every ebuild rather than no ebuilds before it can find the best version of something 17:09 < peper> NeddySeagoon: re: your editorial time, I would appreciate it and welcome patches 17:09 <@dev-zero> Cardoe: I asked, see above 17:09 <@dertobi123> we did agree on a one-hour meeting and i don't think the next topic is that important to extend the meeting 17:09 <@leio> ciaranm: incorrect, but this is not the place to discuss right now indeed. 17:09 < NeddySeagoon> peper, I can't start until Wednesday ... but ok 17:09 * antarus chuckles 17:09 <@dev-zero> dertobi123: then please say just "no" the next time I ask :) 17:10 <@dev-zero> ok then, meeting is over