20:00 <@dberkholz> roll call, please 20:00 <@Cardoe> dberkholz: we might have to moderate this one.... 20:01 < ciaranm> ferringb: you can do that just with assignment too if you impose restrictions upon where the assign occurs... if you need details prod me in another channel 20:01 < dev-zero> dberkholz: here 20:01 < tanderson> <--- here 20:01 <@Cardoe> dberkholz: here 20:01 <@dertobi123> <- here 20:01 <@Betelgeuse> \o/ 20:02 <@dberkholz> leio: here? 20:02 < leio> yes 20:02 <@dberkholz> alright, first topic is the open spot 20:02 <@dberkholz> leio accepted, we need confirmation votes from Cardoe and dev-zero 20:02 < dev-zero> go for it! :) 20:02 <@Cardoe> dberkholz: good by me 20:02 <@dberkholz> excellent 20:03 -!- mode/#gentoo-council [+o leio] by dberkholz 20:03 * lu_zero is here btw.. 20:03 <@dberkholz> leio: welcome to the council! 20:03 <@lu_zero> =) 20:03 <@leio> Thanks :) 20:03 <@lu_zero> thank you for being here ^^ 20:03 < tanderson> dev-zero: now don't you feel special :P 20:04 < dev-zero> tanderson: why? 20:04 < tanderson> dev-zero: no @ 20:04 < tanderson> ;-) 20:04 -!- mode/#gentoo-council [+o dev-zero] by dertobi123 20:04 <@dev-zero> dertobi123: thx :) 20:04 <@dberkholz> i've updated the channel access to reflect halcy0n's resignation and leio's joining 20:05 <@dberkholz> let's move on to the next topic -- progress toward a solution for glep 55 etc. 20:05 <@dberkholz> people see my email? 20:05 <@dberkholz> if not, http://archives.gentoo.org/gentoo-dev/msg_8125876cd6a1e7c3cea3385f02c1ea6f.xml 20:05 <@leio> dev-zero is not in access list 20:06 <@Cardoe> dberkholz: thanks. I need to get with infra about missing mail 20:06 <@dertobi123> "my email" doesn't specify any of this hundreds of mails, but i guess i did read the one you're speaking of 20:06 <@dberkholz> leio: and updated again. =) 20:06 <@dberkholz> dertobi123: thus the link =) 20:06 <@dertobi123> heh 20:06 <@dertobi123> so yeah, seen that mail 20:07 <@leio> yes, have read that mail 20:07 <@dberkholz> antarus: here, by chance? 20:07 <@Betelgeuse> The features are quite easy to implement so I could work with zmedico to implement both glep 55 and lock in and see how performance goes with Portage in practise. 20:08 <@lu_zero> that sounds good 20:08 <@Betelgeuse> If we don't make a decision today I would like us to decided that we will decide in the next meeting unless the sky falls down or something. 20:08 <@dev-zero> agreed 20:08 <@dberkholz> well, considering people were still proposing new solutions in the past 2 hours, that would be pretty hard. 20:09 <@dertobi123> exactly 20:09 <@dberkholz> (to decide today) 20:09 <@Cardoe> everytime I open my e-mail there's a new solution proposed 20:09 <@dberkholz> since i don't think we can decide today, what i suggested instead is concrete action that will move us closer to a decision and make it much easier to decide by having the relevant info all in one place 20:09 < darkside_> i would like to point out that even EAPI-1 is still bricking people systems today. allenJB reports 4 threads in the forums this month about people bringing systems up to date and haveing to reinstall. i know we can't support people forever, but there it is for your consideration 20:10 <@dev-zero> darkside_: jup, G55 would solve that as long as pm's ebuild are being kept on EAPI=0 20:10 <@lu_zero> darkside_ reinstall or update from a stage3 unpacked there? 20:11 <@dberkholz> basically what i'd like to see is something much like http://dev.gentoo.org/~antarus/projects/gleps/glep-0055.html that stops short of actually proposing a single solution, just compares all of them and how well they accomplish what we need. 20:11 <@Betelgeuse> dev-zero: I don't see how G55 is related 20:11 <@Betelgeuse> It just depends on EAPI values 20:11 <@dberkholz> what do the rest of you think about that? 20:11 <@Betelgeuse> not how EAPI is specified 20:11 < tanderson> I don't see how EAPI 1 is related at al really 20:11 < bonsaikitten> dev-zero: actually system, not only pm ... 20:12 <@Cardoe> dberkholz: I like it 20:12 <@dertobi123> dberkholz: i do agree 20:12 <@leio> dberkholz: yes please 20:12 < tanderson> I would like Betelgeuse's suggestion about a mandatory decision deadline to be considered as well 20:12 <@dev-zero> dberkholz: well, why don't you like a proposal for a solution after the comparison? 20:12 <@dev-zero> tanderson: second that 20:12 <@Betelgeuse> We really should setup something for regularly testing upgrade paths but discussion about that is for an another day 20:13 <@dberkholz> dev-zero: because i'd prefer to make my decision based on the data instead of following someone's conclusion 20:13 <@dberkholz> maybe only 1 solution will actually fit the requirements, in which case it's pretty obvious. 20:13 <@dev-zero> ok then, let's do it 20:13 <@Betelgeuse> But the issue here hasn't really been technical merits. 20:13 <@Betelgeuse> But what people like. 20:14 <@lu_zero> Betelgeuse yet numbers could help 20:14 <@Betelgeuse> If we ruled based on technical merits we could just vote 55 in now. 20:14 <@Cardoe> Betelgeuse: that's why we're looking for a decent comparison. I would expect technical merits to be considered in the comparison 20:14 <@dberkholz> not everyone shares that point of view 20:14 < tanderson> lu_zero: not really if the alternate proposals are just bikeshedding( I don't mean that in a bad way) 20:14 <@lu_zero> given much had been said about embedding in ebuild the information would be a detriment to performances 20:14 <@leio> I'd have technical objection to 55, and non-technical objections matter as well. 20:14 <@dberkholz> i've really been enjoying richard freeman's emails 20:15 <@Betelgeuse> leio: If you have technical do share, as I don't remember seeing any. 20:15 <@dev-zero> leio: jup, me neither 20:15 < ciaranm> leio: please provide me a summary of the technical objections to 55, because i seem to have missed them 20:16 <@leio> I discussed stuff pre-meeting here, I'll try to write something up to the list. I just started catching up with these things today, sorry. 20:16 <@dev-zero> dberkholz: ok, so what are we going today then? 20:16 <@dberkholz> i don't think it particularly matters whether objections are "technical" or not 20:16 <@dberkholz> only that enough of us agree that they are important 20:17 <@Betelgeuse> It could go down to the opposition easier if we already have it implemented in Portage when we approve it. 20:17 <@dberkholz> on that note, ferringb also offered to prototype things in pkgcore. 20:17 * ciaranm already has implementations of everything in paludis 20:17 <@lu_zero> as long they could be tried and inspected easily 20:17 <@dberkholz> ciaranm: implementations of every proposal? 20:17 -!- [equilibrium] [n=[equilib@gentoo/contributor/equilibrium] has quit [Remote closed the connection] 20:18 < ciaranm> dberkholz: yup 20:18 <@dberkholz> man, you must have a lot of free time. i'm jealous. 20:18 < ciaranm> naah, just a nice clean codebase 20:18 <@Betelgeuse> ciaranm: even eapi 2 || die? 20:18 <@Betelgeuse> :) 20:18 < ciaranm> Betelgeuse: that one's trivial 20:18 <@Cardoe> Betelgeuse: That's another thing I'd like... a Portage implementation ready at approval time. 20:18 < ciaranm> you can cover every proposal with three implementations 20:18 <@Cardoe> I'm very much a fan of having code provided along with the proposal. 20:18 < ferringb> dberkholz: 20 minutes an implementation or so is all thats really required. it's simple, the slow part is testing each scenario (old manager, new manager, perf, etc) 20:19 < ciaranm> and one of those implementations differs from another only by three lines of bash 20:19 <@dberkholz> in a week from now, i'd like to see an updated version similar to http://dev.gentoo.org/~antarus/projects/gleps/glep-0055.html with the changes i suggested and updates for the latest discussion 20:19 <@dberkholz> that way we have a reasonable chance of actually making a decision by next meeting 20:19 < NeddySeagoon> and some test resuts ? 20:19 <@Betelgeuse> ciaranm: Ok should be easy to create the same results for Paludis then 20:20 < dleverton> Betelgeuse: the benchmarking? 20:20 < ciaranm> test results: 55 is the only one that solves a whole bunch of problems, and anything involving pre-parsing the ebuild gives a 25% to 50% slowdown for -pi world 20:20 <@dberkholz> well, if having test results is a requirement, any option that doesn't have them can't be selected. =P 20:20 < tanderson> dberkholz: handy ;-) 20:21 <@Betelgeuse> ciaranm: Can't you use the cache for lock down as you can just check mtime of the ebuild? 20:21 <@leio> note that performance isn't a metric that can be taken easily. An implementation of a method previous much slower could potentially be made almost as quick or quicker with further optimization work 20:21 < ciaranm> Betelgeuse: how do you mean? 20:21 <@lu_zero> leio the implementations have to be comparable indeed 20:21 <@Betelgeuse> ciaranm: If EAPI can only be set by the ebuild in one place then the cache is valid according to the same rules as now 20:21 < ciaranm> leio: it's a legitimate concern when you have i/o bound processes that've already been carefully optimised for i/o 20:22 <@Betelgeuse> ciaranm: Or did I get somethign wrong? 20:22 <@leio> it is not necessarily a concern that can't be overcome 20:22 < ciaranm> Betelgeuse: that's not actually true for future EAPIs 20:22 <@Betelgeuse> ciaranm: But if we make it so 20:22 < jmbsvicetto> Betelgeuse: one could also think about reviewing the cache - something like has been talked in the -scm ml 20:22 < ciaranm> Betelgeuse: then we need a new cache format, with a second level of EAPI-like-thing... CAPI or whatever 20:22 < ferringb> all proposals at this point require a single authorative "this is my eapi" setting somewhere (whether filename, invocation, or var setting) 20:22 <@leio> or putting the EAPI in Manifest, you touch it anyway 20:22 <@leio> (read it) 20:23 <@leio> (but probably not in all cases needed, so it does inflict some extra I/O in some situations) 20:23 <@Betelgeuse> ciaranm: Why as long as we don't run over the available entries? 20:23 <@Betelgeuse> s/over/out/ 20:23 < ciaranm> Betelgeuse: because the rules used to determine whether a cache entry is valid can change 20:23 < ciaranm> leio: manifest stops people handing out .ebuild files 20:23 < ferringb> ciaranm: and the new mechanism will use keys as needs be for it. that doesn't require flat_hash (even though I prefer flat_hash) 20:24 < zmedico> Betelgeuse: worst case is that you have the parse the head of the ebuild to pull the eapi which is about the same cost as parsing a cache entry 20:24 <@leio> it does not, the EAPI is still in the ebuild. ebuild .. manifest caches it in Manifest 20:24 < ciaranm> zmedico: you mean double the cost 20:24 <@leio> handing out .ebuild's means the receiving end needs to run ebuild manifest on it anyway 20:24 < ciaranm> leio: under current rules you can't get the EAPI until you know the EAPI 20:24 < zmedico> ciaranm: sure but that's only worst case, and not so bad 20:24 < ciaranm> zmedico: no, it's the normal case 20:24 -!- spitfire_ [n=quassel@acom231.neoplus.adsl.tpnet.pl] has joined #gentoo-council 20:25 <@leio> what I'm discussing is an optimization method, it goes along a set of rules for a new method 20:25 -!- strites [n=Nebula@host34-123-dynamic.8-87-r.retail.telecomitalia.it] has joined #gentoo-council 20:25 < zmedico> ciaranm: it's the case when unsupported eapis are in the tree. 20:25 <@Betelgeuse> ciaranm: but you can now if the cache is valid for EAPI 20:25 <@Betelgeuse> ciaranm: not for other entries of course 20:25 < ciaranm> zmedico: that needs a real fix (*cough* 55 *cough*) anyway 20:26 <@lu_zero> a real fix wouldn't involve having also a cache format migration ? 20:26 < ciaranm> Betelgeuse: if you introduce any new global scope functions in a new EAPI, you also have to introduce a new cache format 20:26 < ferringb> no you don't 20:26 < ciaranm> Betelgeuse: unless you go with 55, in which case you don't need to 20:26 -!- Qlawy [n=marcin@gentoo/user/qlawy] has joined #gentoo-council 20:26 < zmedico> ciaranm: the only thing I really dislike about glep 55 is the infinite series of file extensions because it's highly unconventional 20:26 <@Betelgeuse> ciaranm: please xplain why 20:26 <@dberkholz> i would expect that the main tree is primarily composed of ebuilds that stable portage users can parse and use 20:26 < ciaranm> zmedico: no more infinite than having PV in there, which we do already 20:26 < ciaranm> dberkholz: 'primarily' is the problem. it's not 'exclusively'. 20:27 < zmedico> ciaranm: PV isn't currently part of the file extension 20:27 <@dberkholz> so having a slot path for minority users doesn't seem too terrible 20:27 <@leio> I don't think discussion of this during meeting time is a good approach here. I think scheduling an IRC discussion about this could be (e.g, after the meeting) 20:27 <@dberkholz> slow path* 20:27 < tanderson> zmedico: or more important as far as gentoo goes, -rX is quite similar 20:27 < zmedico> ciaranm: I'm talking about moving eapi to the left of the file extension 20:27 < ciaranm> Betelgeuse: new global scope functions can invalidate the cache in ways that current package managers won't detect 20:27 < ferringb> err 20:27 < ciaranm> zmedico: you mean .eapi3.eb? 20:27 < zmedico> ciaranm: right 20:27 < ciaranm> zmedico: and PV is part of the file name, which is effectively the same as part of the file extension 20:28 < ferringb> zmedico: redundant. just do it as the extension if you're going to try that. 20:28 <@Betelgeuse> ciaranm: sure but the cache ist ill valid for EAPI from which you get the cache validation rules 20:28 < ferringb> zmedico: only benefit that gets is being able to still do *.ebuild globbing, which is questionably benefit. 20:28 < zmedico> ciaranm: when I say "file exension" I'm talking about the part to the right of the last period 20:28 < ciaranm> Betelgeuse: nope. if you have an ebuild that's EAPI 1, generate cache for it and then do one of these new style changes, the cache entry can show up as still valid 20:28 < ciaranm> zmedico: how is having a short number in the file extension any different from having a short number in the middle of the filename? 20:29 <@Betelgeuse> ciaranm: The mtime of the ebuild changes and the cache entry is not valid any more 20:29 < ciaranm> Betelgeuse: not if the ebuild isn't what changes 20:29 < jmbsvicetto> ciaranm: last time I read EAPI was defined as being a string - not a number 20:29 <@Betelgeuse> ciaranm: But you must change EAPI 20:29 < ferringb> ciaranm: all proposals require the ebuild to specify the eapi 20:29 <@Betelgeuse> ciaranm: And EAPI can only be set in the ebuild 20:29 <@dev-zero> jmbsvicetto: pms requires eapis used in Gentoo being numbers 20:29 < ferringb> ciaranm: all *non g55* to be clear. 20:29 < ciaranm> jmbsvicetto: it's defined as number for gentoo stuff, and not number for everyone else 20:29 < ciaranm> Betelgeuse: that's not true, though 20:29 <@dev-zero> jmbsvicetto: other projects/overlays need to use strings 20:29 <@Betelgeuse> ciaranm: why not? 20:30 < zmedico> ciaranm: glep 55 proposes an infinite series of file extensions (the part after the righmost period). I think it's too unconventional. I've never seen anybody do that. 20:30 <@leio> ability to do *.ebuild globbing is an important aspect 20:30 < ciaranm> Betelgeuse: you don't know what future EAPIs say, and there're plenty of things they could say that invalidates that 20:30 < tanderson> zmedico: I have 20:30 -!- Qlawy [n=marcin@gentoo/user/qlawy] has left #gentoo-council [] 20:30 <@leio> I can not define a MIME type for ebuilds if *.ebuild doesn't match 20:30 < ciaranm> zmedico: ok, so if we say "after EAPI 99, glep 55 must be reevaluated" you'll be happy? 20:30 <@Betelgeuse> ciaranm: Well isn't GLEP 55 more restrictvive than that? 20:30 <@Betelgeuse> ciaranm: Because it's in the file name so it can't be set anywhere else 20:30 < ciaranm> Betelgeuse: glep 55 removes the problem 20:30 < ferringb> ciaranm: future eapis will still be reliant on the digest/mtime of the ebuild being a component of it however, combined w/ eapi having to be specified in the ebuild that's enough to detect and recheck the eapi 20:30 <@dberkholz> let's give this discussion another 10 minutes, then finish up the meeting and let discussion on glep 55/etc continue afterwards 20:31 <@Cardoe> I happen to agree with leio. That's really my only reservation with GLEP 55 from the start. 20:31 < ferringb> ciaranm: trying to do *all* other form of cache validation on an unsupported eapi is not possible, thus it's a nonissue you're pointing at 20:31 < zmedico> ciaranm: no, even a finite series of file extensions is unconventional 20:31 < ciaranm> you shouldn't be doing *anything* with any ebuild EAPI you don't understand 20:31 <@leio> this is basically my currently only known technical objection, but I'm still working through everything 20:31 < ciaranm> zmedico: you mean like .mp3 and .mp4? 20:31 < ferringb> ciaranm: they cycle significantly slower then eapi one might note 20:32 <@Betelgeuse> ciaranm: How does it remove it? 20:32 < jmbsvicetto> ciaranm: that's a good point - don't try to guess what an unknown EAPI does 20:32 < ciaranm> Betelgeuse: because package managers don't see anything they can't support 20:32 < zmedico> ciaranm: what ferringb said 20:32 <@Betelgeuse> ciaranm: They can see the EAPI with lock down just as well 20:32 < ciaranm> zmedico, ferringb: you can have a cache entry with a set and valid looking current EAPI that ends up being invalid under new EAPI rules 20:33 < ciaranm> Betelgeuse: if you make the lock strict enough, yes. except that still doesn't let you fix MY_PV. 20:33 < ferringb> ciaranm: no one is arguing that. the cache for that specific eapi however will contain the additional chksum info 20:33 < ciaranm> ferringb: sure, but current package managers don't know that 20:33 <@Betelgeuse> ciaranm: What is the fix to that? 20:33 < ferringb> ciaranm: current manageres don't need to know anything further 20:34 < zmedico> ciaranm: I think debian has something called an "version epoc" in the file name which they use to change version rules. we sould do the same for eapi 20:34 < ciaranm> Betelgeuse: the fix is to implement glep 55, and then relax a lot of restrictions that're currently only on PV for historical reasons 20:34 < jmbsvicetto> ciaranm: but how are current package managers going to apply the rules in a new EAPI they don't know? 20:34 < ferringb> ciaranm: the cache entry, if the eapi is something they don't know, they should *not* be fucking around with. it's a nonissue 20:34 < ciaranm> zmedico: that's what 55 is 20:34 <@dev-zero> Betelgeuse: allow foo-1.2.3-1.ebuild for example 20:34 < jmbsvicetto> ciaranm: or are you proposing we can make incompatible changes to an existing EAPI? 20:34 < ciaranm> ferringb: but the cache entry can contain an EAPI that they know, and still be invalid 20:34 < ferringb> ciaranm: the only thing they should be doing at best, is checking mtime/digest of the ebuild against a guranteed value in the cache- the existing mtime field 20:34 < zmedico> ciaranm: right, but the eapi shouldn't go in the extension 20:34 < ciaranm> jmbsvicetto: the issue is that there can be invalid cache entries that look valid to current package managers 20:35 < ferringb> ciaranm: again, ebuilds mtime/digest solves this. this is the first step of cache validation for all years of portage. 20:35 < ciaranm> zmedico: if you want to push for .eapi3.eb instead of .ebuild-3, i'm not going to argue it 20:35 < ciaranm> ferringb: only if the ebuild's mtime changes. you don't know that it will in future. 20:35 <@Betelgeuse> we do 20:35 < zmedico> ciaranm: well, filename or parsed from head of ebuild are both fine with me 20:35 < ferringb> ebuild sets the eapi. 20:35 < ciaranm> Betelgeuse: nnnnnope 20:35 < ferringb> yep 20:36 < ferringb> the other example is git. notice how I kept saying "digest" 20:36 * tanderson cries at summarising this 20:36 <@Betelgeuse> ciaranm: If EAPI is in the first line of the ebuild how come ebuild mtime does not change when EAPI is changed? 20:36 < ferringb> ciaranm: it's addressed; if you think otherwise, give the example now please. 20:36 <@dberkholz> tanderson: on the bright side, perhaps you'll have done much of the work for the comparison we need =) 20:36 < tanderson> dberkholz: I volunteered for glep54, not 55 though 20:36 < ciaranm> Betelgeuse: if you're talking adding in new restrictions that current ebuilds don't follow, then yes, you can fix it 20:37 < ciaranm> ferringb: change where inherit looks. splat. 20:37 < jmbsvicetto> ciaranm: that is one alternative proposal 20:37 <@Betelgeuse> ciaranm: If we arent' changing things why are we talking? 20:37 < ferringb> ciaranm: irrevelant 20:37 < ciaranm> Betelgeuse: we're talking about changing some things without changing others too, which you can't do 20:37 <@Betelgeuse> 20:22 <@Betelgeuse> ciaranm: Can't you use the cache for lock down as you can just check mtime of the ebuild? 20:38 < ferringb> ciaranm: that's getting into global scope explosions, which aren't related to checking if an existant cache entry for an unknown eapi is valid 20:38 <@Betelgeuse> I talked about that from the start. Don't know what you are talkinga bout. 20:38 < ciaranm> Betelgeuse: rephrase that please 20:38 < jmbsvicetto> Betelgeuse / ciaranm: also, what restrictions could be raised if we started using digests? 20:39 < ciaranm> jmbsvicetto: if we ditch the current cache format we can fix the validation issues by using a second sub-EAPI. still stinks when you introduce new ebuilds into the tree though. 20:39 -!- Naib [n=j@fu/hw/naib] has joined #gentoo-council 20:39 < ferringb> ciaranm: we don't need to ditch the cache format 20:40 < ferringb> you've been ducking each point I've made contradicting your validation logic justifying ditching the format 20:40 <@Betelgeuse> I will just see if I hit what ciaramn says when coding it. 20:40 < ferringb> address those before claiming we need a new format 20:40 < ciaranm> the mtime rules on the current format aren't enough if you're allowed to change where inherit looks 20:40 <@dberkholz> let's put this discussion on pause for about 10 minutesf 20:40 <@Betelgeuse> But inherit has no effect on EAPI 20:40 < ciaranm> Betelgeuse: currently it does 20:40 <@Betelgeuse> ciaranm: not with new eapis if we make it so 20:40 <@dberkholz> we need to get through a couple of quick things 20:40 < ciaranm> Betelgeuse: still need to deal with existing cases 20:40 < zmedico> Betelgeuse: we can version the cache like I said here: http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml 20:41 <@dev-zero> dberkholz: like? 20:41 < jmbsvicetto> ciaranm: let's just make it a rule - mandatory EAPI setting in ebuild's 1st line and no overriding 20:41 < ferringb> dev-zero: repositories that aren't pms compliant 20:41 < ciaranm> the problem with zmedico's versioned cache is that it still imposes the icky performance penalty when new EAPIs with new cache rules come along. 55 fixes that. 20:41 < nelchael> jmbsvicetto: non-comment line maybe? 20:41 <@Betelgeuse> ciaranm: I don't see how it makes a difference wrt cache if it's in the file name or the first line for eample 20:41 <@dberkholz> dev-zero: like, do we agree about the writeup on 55? 20:41 < ciaranm> jmbsvicetto: see the email i sent to the list 20:41 < ferringb> ciaranm: every proposal for changing eapi relies on the ebuild specifying the eapi (and being authorative) for all >eapi2 eapis. 20:41 < jmbsvicetto> ciaranm: (if we choose to keep EAPI as a var or make it a call in the 1st line if we move to EAPI as a function) 20:41 < ciaranm> Betelgeuse: we don't normally open the ebuild file at all 20:41 <@Betelgeuse> ciaranm: yes sure 20:42 < ferringb> ciaranm: meaning inherit no longer matters. meaning chksum on the ebuild is enough to deal w/ staleness checks on unknown eapis. 20:42 < jmbsvicetto> nelchael: whatever we can agree on 20:42 < ciaranm> Betelgeuse: the speed of paludis -pi world is determined almost entirely by how many files it has to open 20:42 <@dberkholz> seriously, we need to get through 2 things besides this discussion in the next 15 minutes. so if you guys could hold off for a few, that would really help. 20:42 < zmedico> ciaranm: as said 2 x cache parsing hit isn't bad for worst case 20:42 <@dev-zero> dberkholz: yes 20:42 < ciaranm> zmedico: not worst case. normal case. and it's horrid. 20:43 <@dev-zero> dberkholz: you shouldn't have started with G55 :) 20:43 < ferringb> dev-zero: yep. 20:43 < zmedico> ciaranm: no, general case is that tree only contains supported eapis 20:43 < ferringb> zmedico: stop. 20:43 < tanderson> dev-zero: haha, good point 20:43 < ferringb> resume in 15 20:43 <@dberkholz> i phrased it in a way explicitly designed to avoid this, but it seems that this is impossible. 20:43 <@lu_zero> ciaranm zmedico will implement it and you'll test it and provide data and script to test ourselves 20:43 <@lu_zero> there isn't that much to discuss I guess 20:43 < ciaranm> zmedico: 2x slowdown when the tree contains only supported EAPIs 20:44 < ciaranm> zmedico: that's unacceptable 20:44 <@Betelgeuse> Well let's code and see the results. 20:44 < ciaranm> already did 20:44 < ferringb> post it 20:44 < ferringb> test cases included 20:44 < ferringb> meanwhile the other managers will do the same 20:44 <@Betelgeuse> ciaranm: Ok. I will test with trunk then. 20:44 < ferringb> specifically portage so that we can see how the majority are affected 20:44 <@Betelgeuse> And do the same with Portage. 20:44 < ciaranm> 8s -> 13s for -pi world on the cache valid case 20:44 < zmedico> ciaranm: no, all supported eapis + validatable cache -> no slowdown 20:44 < tanderson> er, +m until 2100? 20:45 < jmbsvicetto> dberkholz: you may want to start talking about the next subject or we won't move forward ;) 20:45 < ciaranm> zmedico: slowdown, because you have to open the .ebuild, which you normally wouldn't have to do 20:45 <@dberkholz> council folks -- do you agree with the writeup of comparisons? if so, who will help on it? 20:45 <@Betelgeuse> dberkholz: If you need silnce for something else use +m 20:45 <@dev-zero> dberkholz: I will 20:45 < zmedico> ciaranm: you don't have to open the ebuild if the cache is validatable 20:45 < ciaranm> zmedico: you don't know that until you open the ebuild 20:45 <@dertobi123> dberkholz: yes, I'd like to see the writeup 20:45 <@dberkholz> 2 minutes to wrap up cleanly without moderation, or +m we go 20:45 <@lu_zero> dberkholz summarize the scope of the comparisons and the voluteers 20:46 <@lu_zero> I got a bit swamped and I no more sure about this 20:46 <@leio> dberkholz: I'd like to see that writeup. I can't help on it as I have to be on devaway for a week 20:46 < zmedico> ciaranm: you don't have to open the ebuild, you just have to validate it's identity 20:46 <@dberkholz> btw, feel free to move your discussion over to #gentoo-dev. 20:46 < ciaranm> dberkholz: heh, funny 20:47 < ahf> haha 20:47 < zmedico> ciaranm: for example, by comparing a digest from the cache with a digest in the manifest. that's good enough for dep calc time 20:47 -!- mode/#gentoo-council [+v tanderson] by ChanServ 20:47 -!- mode/#gentoo-council [+m] by dberkholz 20:47 <@lu_zero> ok 20:47 <@dberkholz> 10 minutes ,then you guys can continue playing 20:48 <@dberkholz> for those of you who haven't replied yet 20:48 <@dberkholz> 20:45 < dberkholz@> council folks -- do you agree with the writeup of comparisons? if so, who will help on it? 20:48 <@dev-zero> 21:45 <@dev-zero> dberkholz: I will keytoast~ 20:48 <@Cardoe> I would like to see the write up 20:48 <@lu_zero> so leio+dev-zero ? 20:48 <@dev-zero> lu_zero: thought that leio is on devaway for the next week 20:49 <@lu_zero> oh, right 20:49 <@dberkholz> Betelgeuse? 20:49 <@leio> yeah, visiting relatives the first half of my vacation, sporadic internet access and "laptop usage allowance" 20:49 <@Betelgeuse> I can work with zmedico to get code in and run benchmakrs. 20:50 <@dberkholz> ok 20:50 <@lu_zero> please post them on -dev 20:50 <@lu_zero> so more people could try firsthand 20:50 <@dberkholz> dev-zero: you're on the writeup, let's see an update by this time next week, using the framework we talked about earlier 20:50 <@dberkholz> dev-zero: sound good? 20:50 <@dev-zero> dberkholz: sure 20:50 <@dberkholz> Betelgeuse: what kind of timeframe? 20:50 <@Betelgeuse> dberkholz: a week should be enough 20:51 <@dberkholz> ok, sounds great. 20:51 <@Betelgeuse> dberkholz: I have exams coming the week after that so won't do it then 20:51 <@dberkholz> those 2 things should help a lot, and we can move forward from there. 20:52 <@dberkholz> now the other topic, 54, i have basically the identical request. just getting all the info in one place for a good comparison. tanderson said he could help lu_zero with that 20:52 <@dberkholz> sound good? 20:52 <@lu_zero> I'll be glad to have his help 20:53 <@dberkholz> lu_zero, tanderson -- can you have something similar to antarus's thing by this time next week? 20:53 <+tanderson> dberkholz: hopefully 20:53 <@lu_zero> it's basically reformat and extend the latest email 20:53 <+tanderson> dberkholz: I have exams until monday but spring break after that 20:53 <@Cardoe> I would say let's shoot for that for next week then 20:53 <@dberkholz> tanderson: if you can't say yes, what timeframe can you say yes to? =) 20:53 <+tanderson> dberkholz: ok, yes :-) 20:53 <@lu_zero> tanderson I hope it won't take much 20:53 <@dberkholz> alright, good. 20:54 <@lu_zero> I'd like to do a poll like we had for glep-55 20:54 <@lu_zero> once we have the summary ready 20:54 <+tanderson> polls are really useless unless we're going for what's the most popular 20:55 <@lu_zero> at least to get a wider feeling of our developers and users 20:55 <@Betelgeuse> well it wasn't really wide thise time 20:55 <@dberkholz> the last point i want to make is what ferringb brought up about pms and gentoo-hosted repos. please read that bit and chip in if you have anything to say. 20:55 <@dev-zero> lu_zero: then make -dev mandatory again 20:55 <+tanderson> dev-zero: a lot of people won't like that 20:55 <+tanderson> dev-zero: if they aren't subscribed they don't care 20:55 <@dberkholz> i can put a poll on my blog, just give me the question and answers, and point people there. 20:56 <@lu_zero> dberkholz ok 20:56 <@dberkholz> i don't think we need to talk about that anymore now 20:56 <@leio> in for example gnome overlay we negate gentoo-x86 package.masks on purpose to make it a lot easier for the users of the overlay. We'd like to continue doing so, and have it working as portage acts like now. 20:56 <@dberkholz> leio: ok, i can't remember whether you said that on the list but could you if you haven't? 20:56 -!- grobian [n=grobian@gentoo/developer/grobian] has joined #gentoo-council 20:56 <+tanderson> I don't think that'll be a good idea especially when we get to proper repository support 20:56 <@dev-zero> leio: well, I get ugly warnings all the time since it's against pms 20:56 <@leio> I will, yes. EvaSDK said something along those lines already 20:57 <@dberkholz> that's everything besides the glep 55 discussion i wanted to cover 20:57 <@leio> most of the overlays work on top of gentoo-x86, and it makes logical sense for that to work like it does right now with portage 20:58 <@lu_zero> dberkholz before I forget for the next council could we get an update about the cvs-> git status? 20:58 <@leio> I'd hate to lose that just because it doesn't conform to some PMS document, that is supposed to document how portage works 20:58 <@lu_zero> leio we should make a difference between overlays and alternate repos 20:58 <@dev-zero> dberkholz: and is there a writeup for Google SoC 2008 ? 20:58 <@leio> sure, just don't make it impossible to do what we do now :) 20:58 <@dberkholz> exactly the same blocker as 2 weeks ago -- see http://archives.gentoo.org/gentoo-scm/msg_df7c98ec7d2e313856bec31769df407f.xml 20:58 <@lu_zero> since those thing overlaps but aren't the same 20:58 <+tanderson> I have to leave soon, I'll get to the summary in a bit 20:58 <@dberkholz> dev-zero: no, but i've been blogging and posting about it like crazy 20:59 <@dberkholz> so can we close up the meeting, unmoderate, and get back to that? 20:59 <@leio> maybe voice ferringb as the requestor for this discussion? 20:59 -!- mode/#gentoo-council [+v ferringb] by dev-zero 20:59 <+ferringb> thank you 21:00 <@leio> so perhaps a concrete proposal on how to support both in a formalized way from someone? 21:00 <+ferringb> essentially, if you want overlay x to be able to override repo x's masks, formalize it then; the current state requires basically collapsing it all down into a single stack which is very unfriendly to implementations designed for multiple stacks 21:00 <+ferringb> further, it goes beyond adjustments of masks- pms specifies profile chunks as files 21:00 <@leio> some file that says a name for a stack or something. Or declaring a parent repository, or.. 21:01 <@lu_zero> ferringb so also that part should be updated as well? 21:01 <+ferringb> portage extended it's user profile support (directory or file) to *all* profiles- now the only spec non-portages can follow is pms, but it blows up in our face on overlays following portages looser standards 21:01 <+ferringb> lu_zero: no, it can't be 21:01 <+ferringb> lu_zero: it would break older portage installations via allowing that in gentoo-x86 21:01 <@dberkholz> i've got other meetings i have to attend for the next couple hours. dev-zero, could you please take care of trying to push this topic to the list, then unmoderating and returning to discussion in the next 5 min or so? 21:02 <@dev-zero> dberkholz: sure 21:02 <+ferringb> the problem here is that we have unversioned changes occuring. version the sucker, if portage has it's own overlay repository format that isn't pms (which *is* the case now), it needs to be marked so paludis/pkgcore aren't getting screwed, or forced to loosen our pms compliance for all repos 21:03 <+ferringb> wordy, but does that make sense? the real issue here is that these repos we have to assume are pms compliant, there is no marking to rely on to tell us otherwise- because portage is dominant and allows more then pms specifies, we're forced to either have things blow up 21:03 <+ferringb> or to disregard pms and follow what portage does. 21:03 <@leio> I'll bring my stuff on the list to get the discussion continued, but I'm not sure I manage before I leave in the morning and be completely without Internet access for a few days. 21:03 <@dev-zero> ferringb, leio: why not bring in the needed stuff in a proposal for the next eapi? 21:04 <+ferringb> dev-zero: profiles aren't versioned by eapi 21:04 <@leio> this isn't really an ebuild thing. How does EAPI apply? 21:04 <+ferringb> no repository metadata is. only ebuilds are versioned by eapi 21:04 <+ferringb> leio: it doesn't apply 21:04 <@dev-zero> ferringb: we have profile EAPIs now 21:05 <+ferringb> dev-zero: not for repository level masks. 21:05 <@lu_zero> then I guess we are set about that to do in this regard 21:05 <@dev-zero> ferringb: yes, we do 21:05 -!- mode/#gentoo-council [+v jmbsvicetto] by leio 21:06 <@dev-zero> but anyway, we're over time already 21:06 <@dev-zero> ferringb, leio: please bring that topic up on -dev again and we'll talk there about it 21:06 <@leio> yeah, I'll try hard to bring up my stuff to the list in a new thread name before I get asleep 21:06 * ferringb sighs, can, but people ignore it 21:06 <+jmbsvicetto> one concern I have for KDE is that we frequently need to mask some versions in Portage, but to unmask them in the kde-testing overlay (where we're conducting the bulk of our work) 21:06 <+ferringb> as does upstream portage. basically leaves the option of loosening to portages spec and disregarding pms 21:06 <@leio> pretty much exactly the same use case in gnome overlay 21:07 <@leio> we could probably do package.unmask entries, but that doesn't really work in a profile iirc 21:07 <@leio> (e.g, not even supported such a list of unmasks) 21:07 <+jmbsvicetto> profile EAPIs would help, but as ferringb stated, that doesn't help with files directly under /profiles 21:07 <+ferringb> leio: package.unmask was one of the additions portage leveled iirc. 21:07 <@dev-zero> well, I'm going to open the channel for discussions again 21:08 -!- mode/#gentoo-council [+tnc] by dev-zero 21:08 <@lu_zero> jmbsvicetto as current workaround won't be possible provide unmask file to add in /etc/portage ? 21:08 <+ferringb> even if you did profile eapis, you'd have to create an eapi w/ the changes portage has forced, then bump every involved profile (repo included) to it where it's used 21:08 <+jmbsvicetto> lu_zero: yes, but that affects the way users work with the overlay 21:08 <+ferringb> which is an upgrade without reason. repository level format marker handles this far cleaner 21:09 <+jmbsvicetto> lu_zero: by putting the file in the overlay profiles dir, users don't need to "think about it" 21:09 <@leio> the whole point of doing the mask negation in the overlay is to avoid users having to put stuff in /etc/portage 21:09 <@leio> we update it for them, they can't forget removing those package.unmask entries from /etc, etc 21:09 <@lu_zero> jmbsvicetto giving a notice and explanations would be understood or you are afraid it would cause an outrage? 21:09 <+jmbsvicetto> lu_zero: I'm sure it would cause an outrage 21:10 -!- mode/#gentoo-council [-m] by dev-zero 21:10 <@lu_zero> leio ln the file in $overlay/scripts won't be the same? 21:10 < ciaranm> leio: having global behaviour changing merely because you add a repo is horrid 21:10 <+jmbsvicetto> lu_zero: users would start complaining why we were making their life harder 21:10 <@lu_zero> jmbsvicetto I see 21:10 < ciaranm> a better solution is to get sets standardised, and not how portage does them now... 21:10 <+ferringb> having users yelling at me unable to use pkgcore because y'all follow portages standards is horrid also 21:10 <@leio> ciaranm: that is your opinion, and most users disagree with it. 21:10 <@leio> (about it being horrid) 21:10 <+jmbsvicetto> ciaranm: I would love to get your feedback about sets 21:10 <+ferringb> encode it in a format 21:10 <@leio> it is the logical approach we are doing 21:10 < ciaranm> leio: most users haven't had access to an easier alternative 21:10 <+ferringb> it solves everyones complaints and gives us a way to deal with this 21:10 <+jmbsvicetto> ciaranm: We should really be trying to define a format that all 3 PMs support 21:11 < ciaranm> leio: you're doing what portage lets you get away with, not what's best 21:11 < ciaranm> jmbsvicetto: indeed 21:11 < ciaranm> jmbsvicetto: the paludis format is rather clean... and documented... 21:11 <@dev-zero> tanderson: I think the meeting can be concidered over