20:01 <@dberkholz> ok, let's get started 20:01 <@Cardoe> Betelgeuse: yes? 20:01 <@Betelgeuse> Cardoe: just to find out that you are here 20:01 -!- ferdy [n=ferdy@exherbo/developer/ferdy] has joined #gentoo-council 20:01 <@Cardoe> Betelgeuse: I've been here talking for the last hour 20:01 <@dberkholz> Betelgeuse, Cardoe, dberkholz, dertobi123, leio-dl are here 20:01 <@Betelgeuse> dev-zero: 20:01 <@dberkholz> lu_zero, dev-zero -- pong please 20:02 <@dev-zero> dberkholz: pong 20:02 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has joined #gentoo-council 20:02 <@dberkholz> lu_zero: check in again when you're back 20:02 < fmccor> lu_zero was here 9 minutes ago 20:02 <@dberkholz> let's start 20:03 <@dberkholz> anyone mind if we talk briefly about the path to EAPI=3, even though it wasn't on the draft agenda? 20:03 <@Betelgeuse> There won't be a shortage of ideas the main deciding thing is zac. 20:03 <@Betelgeuse> Unless someone gets down to coding. 20:04 <@dberkholz> zmedico: around? 20:04 <@Betelgeuse> As can be seen with GLEP 55 if we rely on zac we really can't make much plans. 20:04 <@dev-zero> Betelgeuse: for at least one issue on the task there's already a patch for portage 20:04 < ciaranm> half the things on the list are five minute bash jobs 20:04 <@dev-zero> second, some issues are pretty much isolated and don't need much portage knowledge 20:05 <@Cardoe> We don't necessarily have to rely on Zac. Most of the items are really basic and can be coded by someone with 30 min time. 20:05 <@Betelgeuse> good 20:05 < ciaranm> the one that's slightly non-trivial is [use(+)] deps (assuming we like that syntax), and afaik that's considered the driving force behind EAPI 3 20:05 <@dev-zero> yes 20:05 <+tanderson> hi, I'm here now 20:05 <@Betelgeuse> Well repoman support would help a lot too. 20:05 <@dev-zero> and the multislot dep issue 20:05 <@Cardoe> ciaranm: was that for handling the missing case? 20:05 < ciaranm> Cardoe: yeah 20:06 <@dberkholz> which line is that on the spreadsheet? 20:06 <@dberkholz> use(+) 20:06 <@dev-zero> 6 20:06 <@Cardoe> ciaranm: can you give a quick description of the syntax. The spreadsheet kinda is weak on it and I'd also like to have a description of the syntax for the logs. 20:06 <@Betelgeuse> dev-zero: please post a link so it gets logged 20:06 <@leio-dl> [use(+)] has the same portage stock message issue as other USE deps, but that's a topic for ml and possibly separate thing 20:06 <@Cardoe> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ is the spreadsheet and #6 is what we're talking about 20:07 < ciaranm> Cardoe: the syntax exheres-0 uses is foo/bar[flag(+)] and foo/bar[flag(-)] 20:07 <@dev-zero> here are the eapi-3 feature proposals: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ 20:07 <+tanderson> I need to catch up :\ 20:07 < ciaranm> where (+) means "pretend it's on if foo/bar doesn't have flag in IUSE" 20:07 <@Cardoe> dev-zero: they're missing a bunch that ciaranm suggested and I'd like to see merged in. 20:07 <@Cardoe> ciaranm: thanks 20:07 <@dev-zero> Cardoe: hmm, which ones? 20:08 <@Betelgeuse> I don't really see it solving the remove use flags problem unless we always start to use these atoms. 20:08 <@dev-zero> Betelgeuse: that's true 20:08 < ciaranm> Betelgeuse: until someone removes the use flag in a newer version, though, you don't know what your dep will want 20:08 <@Betelgeuse> You should always check reverse stuff any way. 20:08 < ciaranm> if you're currently foo/bar[baz], and new bar has no baz, you don't know in advance whether it's because baz is always on or has been removed or what 20:09 <@Betelgeuse> ciaranm: I know but I was referring to the spreadsheet. 20:09 <@Cardoe> I think it's a good syntax as any unless there are any technical objections. 20:09 < ciaranm> so if you do foo/bar[baz] until you know, the repoman can flag it down for you once a new foo/bar comes along 20:09 <@leio-dl> we just need tools to show automatically what depends on an IUSE in any way to deal with it 20:09 * ciaranm really can't type tonight 20:10 <@Betelgeuse> dev-zero: One thing to add is doexamples 20:10 <@Cardoe> ok lemme speed this up. 20:10 <@leio-dl> but repoman will only tell it if you run it inside the package that has foo/bar[baz] in depends, not when you are running it inside foo/bar after removing baz from IUSE 20:10 <@dev-zero> Betelgeuse: good point 20:10 < ciaranm> leio-dl: yup. fortunately, people do global tree scans regularly to catch that sort of thing. 20:10 <@dberkholz> there's some point where we have so many do* actions that it's harder to remember them all than to do an insinto.. 20:10 <@leio-dl> always after the fact. Lets move on 20:11 < ciaranm> leio-dl: there's no nice easy solution to dealing with reverse deps, and use deps don't really alter that 20:11 <@Cardoe> Do we want [use(+)] deps to go into the EAPI-3 draft? dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero? 20:11 <@Cardoe> I say yes. 20:11 <@leio-dl> yes 20:11 <@dertobi123> yep 20:11 <@dev-zero> yes 20:11 <@dberkholz> fine w/ me 20:11 <@Betelgeuse> dberkholz: well in the long term we should more helper stuff to the tree 20:11 <@Cardoe> dertobi123: sorry for missing you off 20:11 <@dertobi123> Cardoe: :P 20:11 <@Betelgeuse> Cardoe: sure 20:11 <@Cardoe> dertobi123: too many d's 20:12 <@dertobi123> heh 20:12 <@Cardoe> Ok. Next item on the draft. 20:12 <@Cardoe> pkg_pretend() 20:12 <@dberkholz> we'll have to vote for higher council nick diversity next time. 20:12 <+tanderson> bwahaha 20:12 <@dberkholz> i am totally for pkg_pretend 20:12 <@Cardoe> I would like to see pkg_pretend() useful for displaying USE conflicts 20:13 <@Cardoe> http://bugs.gentoo.org/show_bug.cgi?id=75936 20:13 <@dberkholz> there are so many ways it's useful 20:13 <@Cardoe> To allow the developer to put a description behind it. 20:13 <@dev-zero> yes, me too, but we should still try to find a more pm-based solution for USE conflicts 20:13 <@Cardoe> because the current way Portage displays it sucks 20:13 <@dberkholz> telling people we're gonna break their system before a merge instead of after 20:13 <@Cardoe> and users are confused 20:13 <@dberkholz> gentoo sysadmins have complained to me about that so many times 20:13 <@Cardoe> pkg_pretend in draft EAPI-3.... dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero, dertobi123? 20:13 <@dev-zero> yes 20:13 <@Cardoe> yes 20:14 <@dberkholz> 20:12 < dberkholz@> i am totally for pkg_pretend 20:14 <@Betelgeuse> Cardoe: Do we need to go through one by one? 20:14 <@dertobi123> yes 20:14 <@leio-dl> abstain (haven't read and thoguht about it enough) 20:14 <@Betelgeuse> Is there anything people disagree on? 20:14 <@Cardoe> Betelgeuse: I'm looking for us to nail down a "draft" list. 20:14 <@Cardoe> That we can hand over to the PM maintainers to implement 20:14 <@Cardoe> They come back to us once we've got some code and we'll formally resolve the differences and finalize EAPI-3 20:15 <@Betelgeuse> Cardoe: What good does that do if we are tied to Portage implementing things? 20:15 < ciaranm> can always take things out if it turns out portage can't do them quickly 20:15 <@dberkholz> how about we come up with a list of things on that spreadsheet that any of us disagrees with instead 20:15 <@Cardoe> Fine 20:15 <@Betelgeuse> I would propose as to set a time and then see what Portage has then. 20:15 <@dberkholz> it'll take a while to go through 20-something positively 20:15 <@Betelgeuse> And use that for EAPI 3. 20:15 <@dev-zero> I already cancelled some features out (those with prio=99) 20:16 <@Cardoe> dev-zero: please add a reference to bug #75936 to item #1 20:16 < Willikins> Cardoe: https://bugs.gentoo.org/75936 "method for handling conflicting USE flags at --pretend time required"; Portage Development, Core - Ebuild Support; NEW; ciaran.mccreesh@googlemail.com:pms-bugs@g.o 20:16 <@Betelgeuse> I say a month is fine. 20:16 <@dev-zero> Cardoe: I'm sorry, but that's not the same thing 20:17 <@Betelgeuse> Any comments? 20:18 <@dberkholz> so basically request a specific list of features in portage, then take whatever's done in a month and call it 3? 20:18 <@dertobi123> putting those marked with priority 1 to 3 on a draft and look in month what we have implemented in portage would work for me 20:18 <@dertobi123> in a month* 20:18 <@Betelgeuse> dberkholz: it can implement more too 20:19 <@dberkholz> sorry, didn't understand that 20:20 <@Betelgeuse> dberkholz: I don't think we need to restrict ourselves to the items on that list of there is more implemented (if this is likely is of course another matter) 20:20 <@dberkholz> all i'm saying is that we actually provide a list of stuff that we want, instead of having this list of random features that a million people have proposed, which we may or may not end up approving 20:21 <@Cardoe> Betelgeuse: we're not restricting outselves 20:21 <@Cardoe> We're providing a list of stuff we'd like to see 20:21 <@dberkholz> so we pre-approve features before they're implemented 20:21 <@dev-zero> that's true, but it would be good if we limit ourselves to certain points and see that those get really implemented 20:21 <@Betelgeuse> dev-zero: The easiest way is to divide the features between council members or others to code 20:21 -!- keytoast1r [n=tobias@alpha.libexec.de] has quit [Client Quit] 20:21 <@leio-dl> I don't like pre-approving, if expressed that way 20:22 <@dev-zero> Betelgeuse: ok, fine by me 20:22 -!- theinlein [n=tobias@gentoo/developer/keytoaster] has joined #gentoo-council 20:22 <@dberkholz> leio-dl: what's your problem with it? 20:22 <@Cardoe> We're sifting through the list of proposed features on all the mailing lists 20:22 <@Cardoe> rejecting certain ones out right 20:22 <@Cardoe> and prioritizing some based on the needs and requests 20:22 <@Cardoe> and giving that list to people to code 20:22 <@Cardoe> then we'll check back with what's coded in a month 20:22 <@Cardoe> and go from there 20:22 <@leio-dl> my problem is that for example we haven't actually been able to test this feature, and before actual approving we could and something turns out. That's an example 20:22 -!- theinlein is now known as keytoaster 20:23 <@dberkholz> pre-approving doesn't mean pre-requiring 20:23 <@dberkholz> it means if things work out well, it's in. it could still fail at the implementation step 20:23 <@leio-dl> pre-approving worded like that sounds like we can't end up rejecting it 20:23 <@leio-dl> if it turns out to be a bad idea by then, regardless of the implementation 20:23 <@Cardoe> if it turns out to be a bad implementation or works out to be poorly thought out after further discussions we drop it 20:23 < ciaranm> leio-dl: all of these features are easy to turn on or off in the package manager 20:23 <@dev-zero> that's why you usually have developers at the requirement meeting 20:24 <@Cardoe> It's a wish list 20:24 <@Cardoe> dev-zero: unfortunately we can't force the developers of PMs to be on here 20:24 <@leio-dl> wish list, sure. Just avoid the term pre-approved and I'll be happy 20:24 <@dev-zero> Cardoe: no, it's a requirement list 20:24 <@dev-zero> Cardoe: we have at least one developer of a package manager here 20:25 <@Cardoe> dev-zero: indeed we do and we appreciate it. 20:25 <@Cardoe> dev-zero: but alas the others did not come. 20:25 <@dev-zero> Cardoe: and the prio=1 features have been implemented in one package manager, so a proof-of-concept is done 20:25 <@leio-dl> ciaranm: No, they are not. If the ebuild says an EAPI, it has to support it fully not have something turned off 20:25 <@Cardoe> leio-dl: he meant as part of development and testing 20:25 < ciaranm> leio-dl: no, i mean, we can implement features in the package manager, but not have them supported for any EAPI 20:26 <@leio-dl> sure, you can implement what you want :) 20:26 <@Cardoe> Honestly folks. This is a rather pointless debate. 20:26 <@Cardoe> We've got a list with priorities 20:26 <@dev-zero> yes 20:26 <@Cardoe> It's done 20:26 <@Cardoe> Move on 20:26 <@Cardoe> dberkholz: what's the next agenda item? 20:27 <@dberkholz> it was overlay masking, but we've already got an action there 20:27 < ciaranm> leio-dl: have a look at http://git.pioto.org/gitweb/paludis.git?a=tree;f=paludis/repositories/e/eapis;h=18e91e4a6e08e6160f400;hb=master to see what i mean. there's no harm in experimentally or provisionally implementing something in a package manager and then just not using it if it turns out it sucks 20:27 <@dberkholz> leio-dl just needs to follow up on list, which he's gonna do by saturday 20:27 <@Cardoe> dberkholz: sounds good. 20:27 <@Cardoe> dberkholz: next item? 20:27 <@dberkholz> then we've got the live ebuild stuff 20:28 <@dberkholz> the existing writeup really doesn't address the things i was hoping it would, along the lines that antarus did for 55 20:28 <@Cardoe> frankly the more we look at the live stuff. the more I feel its lacking 20:28 <@dberkholz> i'm wondering whether i need to get involved with that 20:29 <+tanderson> uh, I was supposed to write a comparison, no? 20:29 <@Cardoe> tanderson: yep 20:29 <+tanderson> at least that what everybody agreed on for the summary 20:29 <@Cardoe> The only thing I'd like to see from GLEP 54 is a defined way of storing the revision information used by the build 20:29 <+tanderson> so How did what I do not address what was wanted? 20:30 <+tanderson> Cardoe: Yeah, I hope to work on that soon. Thankfully, classes have eased up a bit 20:30 < ciaranm> Cardoe: storing revision information is largely an unrelated issue. getting that whole thing right is best addressed as stages two and three of a staggered plan 20:30 <+tanderson> yeah, All we have to agree on is that it's possible and a good plan to do it with GLEP 54, or not.. 20:31 <+tanderson> er, s/we/you obviously :P 20:31 <@Cardoe> ciaranm: ok fine. 20:31 <@Cardoe> ciaranm: then I'd like a documented way for the user to specify a specific revision 20:31 <@Cardoe> right now we've got ESVN_REVISION and EGIT_REVISION 20:31 < ciaranm> Cardoe: that's stage two, or possibly stage three if it's split in four 20:32 -!- kICkar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council 20:32 <@dberkholz> they're not really compared at all ... there's a document that has descriptions for both of them, and a problem or 2 picked out with each. there's no tie-in to the actual requirements of what this needs to do. 20:32 < ciaranm> Cardoe: solving the entire live sources problem is a lot of work, and there're a lot of very non-obvious pitfalls. trying to do it all at once means it'll never get anywhere. 20:32 <@dberkholz> it's clear to me that my mental picture doesn't match with what i actually requested 20:32 <@Cardoe> ciaranm: fair enough 20:33 <@Cardoe> ciaranm: so we're just going to say this addresses the -9999 ebuild 20:33 <@Cardoe> Is Portage using PROPERTIES=live? 20:33 < ciaranm> Cardoe: right. the glep *just* addresses the ordering problem, and nothing else. 20:34 < ciaranm> PROPERTIES=live isn't necessarily bad. it's just not related to what the glep's trying to solve. 20:34 <@Cardoe> ciaranm: well, we could say that if you make a -scm.. you have to put PROPERTIES=live 20:35 <@Cardoe> in there 20:35 < ciaranm> really... PROPERTIES=live is just a lousy way of sort of attempting some of part two or three... 20:35 <@Cardoe> ciaranm: my idea here is let's get GLEP 54 into EAPI=3 and not make people wait until EAPI=4 to really work with it 20:35 < dleverton> Is there any case when it would be sensible to have -scm without PROPERTIES=live, or vice versa? 20:35 < ciaranm> dleverton: the PCI IDs list, arguably 20:36 <@Cardoe> ok fine 20:36 <@Cardoe> we'll come back to it 20:36 <+tanderson> ciaranm: is that checking out a static revision? 20:36 <@dev-zero> Cardoe: the original motivation behind EAPI=3 was to have it fast 20:36 <@Cardoe> dev-zero: as is my motivation right now. 20:36 <@dev-zero> Cardoe: things like G55, G54 and a couple of more issues which can take month are not suited 20:36 < ciaranm> 54's a lot easier with 55, which puts it into "not fast" territory unfortunately 20:36 <@Cardoe> Does any council member have a technical issue to GLEP 54? 20:37 <@lu_zero> Cardoe the glep should be specified better 20:37 <@lu_zero> but I said that already 20:37 <@leio-dl> I need more time to be sure personally 20:37 <@dev-zero> Cardoe: and I want a reference implementation 20:37 <+tanderson> lu_zero: well, considering it's only addressing part 1, I'm not so sure.. 20:37 <@Cardoe> dev-zero: so do I 20:37 < ciaranm> kdebuild-1's a reference implementation for both 54 and 55 20:38 <@lu_zero> tanderson it's addressing the last part of something bigger 20:38 <@lu_zero> you usually do not start from the roof 20:38 < ciaranm> -scm is the first part, not the last part, because it's easy and doesn't need the other parts to be useful 20:38 <+tanderson> lu_zero: well, I think the first part is getting correct ordering 20:38 <@lu_zero> ciaranm it's uses are debatable at best 20:38 <@dev-zero> lu_zero: I agree with tanderson 20:39 < ciaranm> lu_zero: tell that to the people using -9999, -20099999 and so on 20:39 <@lu_zero> ciaranm 9999 it's a value like others 20:39 < ciaranm> lu_zero: which is the problem 20:39 <@dev-zero> ok, I don't see that we get to an end here, do you? 20:39 <@dertobi123> not really ... 20:39 <@lu_zero> you can enforce ordering otherwise 20:40 < ciaranm> i honestly don't see an end until there's a vote, because lu_zero isn't ever going to agree to -scm 20:40 <@lu_zero> like preventing people using pkg-1234545677 20:40 <@lu_zero> that said my only concern is getting more people agree on it, so if somebody adds more meat to glep 54 I won't be against it 20:41 <+tanderson> lu_zero: what kind of meat? 20:41 <@dev-zero> and I still fail to see what needs to be added 20:41 <@lu_zero> dev-zero if I propose you to allow utf8 for names and latin numbers for version 20:42 <@lu_zero> you'd consider me crazy 20:42 < ciaranm> latin numbers for versions is doable 20:42 <@dberkholz> back in 5, gotta take care of something. 20:42 <@lu_zero> ciaranm anything is doable 20:42 <@lu_zero> even utf8 numbers 20:43 < ciaranm> lu_zero: actually no. i could list several proposals regarding versioning that are technically unimplementable. 20:43 <@lu_zero> that alone should make you wonder if is worth it 20:43 <@lu_zero> if there is an use 20:43 < ciaranm> the use for -scm is replacing -9999 etc 20:43 <@lu_zero> the use of utf8 names is to allow crazy names in programs 20:44 <@lu_zero> that doesn't make it more agreable 20:44 < ciaranm> lu_zero: how many programs can you think of that use utf-8 names? 20:44 <@lu_zero> ciaranm I hope none 20:44 < ciaranm> lu_zero: compare that with the number of packages for which people are shipping -scm ebuilds 20:44 <@dev-zero> lu_zero: I think you're getting far away from the real problem 20:44 <@lu_zero> ciaranm I hope none as well 20:44 <@lu_zero> since means that either upstream or the packager is insane 20:45 < ciaranm> lu_zero: there're lots of packages using -9999 or equivalent. most are masked, fortunately, but people find them useful. 20:45 <@lu_zero> ciaranm they are masked since they are unstable by definition 20:45 <@lu_zero> and they are scarce 20:45 < ciaranm> lu_zero: yes. and? they're still there, so we should support them well. 20:45 < ciaranm> lu_zero: look at how many scm-related eclasses there are in the main tree. are you saying they should be removed? 20:45 <@lu_zero> we should support them within the limit of usefulness/effort ratio 20:46 <@lu_zero> ciaranm they can be used even w/out requesting for fluid revisions 20:46 < ciaranm> the only effort for -scm is discussing things with you... it's easy to implement 20:46 <@lu_zero> see mythtv and their ustream 20:46 <@lu_zero> upstram 20:46 <@lu_zero> sigh I cannot spell 20:47 <@Cardoe> lu_zero: I'm the MythTV guy.. 20:47 <@lu_zero> as a -9999 user I'll be glad to have something simpler 20:47 <@Cardoe> Based on what GLEP 54 proponents are trying to say is 20:47 <@Cardoe> let's that be the next step 20:47 <@Cardoe> let us just get the basics down 20:47 <@lu_zero> Cardoe IIRC you had to use constant revision sometimes 20:48 <@Cardoe> yep 20:48 <@Cardoe> But this GLEP won't address all uses of svn/git/cvs/bzr etc 20:48 <@Cardoe> just the -9999 usage 20:48 <@Cardoe> which I don't use 20:48 <@lu_zero> right 20:48 <@Cardoe> I'll have to write a new GLEP 20:49 <@dev-zero> ok, result of this discussion? 20:49 <@dberkholz> back 20:50 <@dev-zero> dberkholz: right in time 20:50 <@Cardoe> lu_zero: I say you and I work on another GLEP on top of this 20:50 <@lu_zero> Cardoe agreed 20:50 <@Cardoe> which brings up a point.. why aren't the EAPIs a GLEP? 20:50 <@Betelgeuse> Cardoe: we tagged PMS last time 20:51 < ciaranm> Cardoe: because we're lazy, and a PMS branch is easier 20:51 <@Cardoe> Fair enough 20:51 <@Cardoe> I like lazy 20:51 <@lu_zero> thehe 20:51 <@Cardoe> next item? 20:51 <@lu_zero> everybody feels 20:51 < ciaranm> otherwise we'd have to rst them for GLEPs as full proposals, and then work that into PMS as diffs 20:51 < solar> remove keywords from ebuilds. 20:51 < solar> ciaranm: can your pkg mgr handle that? 20:51 < solar> ie. profiles/package.keywords 20:52 <@dberkholz> ...? 20:52 < ciaranm> solar: we don't use keywords from profiles at all currently. we could, easily enough, but it won't work for gentoo until gentoo-x86 is a tenth of its current size and using git instead of cvs 20:52 < solar> it wont work? 20:52 < ciaranm> it doesn't scale to what arch teams do 20:53 < solar> it works today in everything else. I just want to make sure i don't cause any segvs 20:53 -!- togge [n=togge@gentoo/contributor/togge] has quit [Remote closed the connection] 20:53 < ciaranm> this was investigated three or four years ago... iirc agriffis an / or g2boojum 20:54 < ciaranm> basically... the cvs tree is so big and slow, you'd never be able to commit anything because of conflicts if everyone's editing a single file all the time 20:54 < solar> ciaranm: well the scaling thing does not really hold true anymore. 20:54 < solar> and conflict is not any more of a problem than say ppl editing other package. 20:54 <+tanderson> ciaranm: wouldn't you get merges rather than conflicts? 20:54 < ciaranm> solar: honestly, i suggest you bring it up after gentoo's using git and lots of smaller independent repositories 20:55 -!- togge [n=togge@212.247.117.70] has joined #gentoo-council 20:55 <@Betelgeuse> Is this really something we need to discuss atm? 20:55 < ciaranm> tanderson: if you're lucky 20:55 < solar> files. Anyway. I plan to go down this route with a bunch of other ppl. So 20:55 <@dberkholz> i've gotta head out in the next 5-10 min, so i'd like to get through the next topic as much as possible 20:55 <@Betelgeuse> dberkholz: fine by me 20:55 <@dev-zero> me too 20:56 <@lu_zero> ok 20:56 <@dberkholz> basically wrt glep 55, we really need the information from people that we requested at the last meeting and expected to hear back about a week ago 20:56 <@dberkholz> so what's the deal? 20:56 <@Betelgeuse> I can't benchmark something that's not there. 20:56 <@Betelgeuse> Zac promised me two weeks ago to do it 20:56 <@Betelgeuse> But never did it. 20:56 <@dberkholz> alright 20:56 <@Betelgeuse> So it seems I must implement it myself. 20:56 <@lu_zero> did he tell something about it? 20:57 <@Betelgeuse> lu_zero: See his mail on gentoo-council 20:57 <@lu_zero> just that? 20:58 <@dberkholz> Betelgeuse: ok, can you check back in with zac about that timeframe and drop a post to -council? 20:58 <@Betelgeuse> lu_zero: yeah haven't heard anything yet since that 20:58 <@dberkholz> it is still "this week" after all 20:58 <@lu_zero> right 20:59 <@Betelgeuse> My opinion is to approve 55 and put a GSoC project by an experienced dev to redesign the tree format that always uses .ebuild 20:59 <@dberkholz> ciaranm: i was hoping to see some benchmarks from you. could you post them? 20:59 <@Betelgeuse> Can actually nail down PMS and solve other long standing issues. 20:59 <@lu_zero> I have to ask him something about multislot as well 20:59 <@lu_zero> Betelgeuse would be interesting 21:00 <@Betelgeuse> If this doesn't happen before we have a need for global scope changes we can fall back on 55. 21:00 <@Betelgeuse> In the mean time. 21:00 < ciaranm> dberkholz: just under 50% slowdown in metadata access times in the 'valid cache' case 21:00 <@lu_zero> ciaranm something we could try ourselves? 21:00 <@dberkholz> ciaranm: i'd really love to see the numbers on times for each case 21:01 < ciaranm> dberkholz: for invalid cache cases you can't measure it since bash is a thousand times slower than using the cache 21:02 < ciaranm> lu_zero: why? planning to benchmark it on an ssd just to screw with the results? :P 21:02 <@lu_zero> ciaranm planning to read the patch and see how works 21:02 <@dberkholz> ciaranm: hot cache, cold cache? what are the numbers in seconds? 21:03 <@lu_zero> the more people trying the more shared is the decision upon it 21:03 < ciaranm> dberkholz: hot vs cold doesn't make much difference to the ratio either, since with hot cache you're doubling the syscall overhead 21:04 < ciaranm> dberkholz: numbers in seconds are "very small" to "double very small". it's when you multiply that by 10k it gets to be the problem. 21:04 <@lu_zero> using a default set like xorg + kde + gnome would be a good benchmark 21:04 <@dberkholz> in which situations will people be multiplying it by 10k? 21:05 < ciaranm> dberkholz: you do 10k metadata lookups to do a pretend-install world 21:05 <@lu_zero> even if the minimal set would be a portage or a system set 21:06 <@dberkholz> we've gotta wrap this up 21:06 <@dberkholz> next step is trying to get a portage implem & benchmarked 21:07 <@dberkholz> let's get that and go from there 21:07 <@dev-zero> but to make it clear: benchmark is not the main issue, it may just be another issue 21:08 <@dev-zero> s/benchmark/performance 21:08 <@lu_zero> dev-zero which is the other issue in your opinion? 21:08 <@leio-dl> I think I was supposed to bring my technical objection to G55 to list? 21:09 <@lu_zero> my main concern is least surprise/ease of use, then performance 21:09 < dleverton> The other issue is whether the prosposed solution is insane or not. 21:09 < ciaranm> the whole "having to open the ebuild" thing isn't even an issue if you stick with the EAPI= assignment restrictions i posted, since if you're ok to assume those restrictions you don't need to open the ebuild to check cache validity 21:09 <@dberkholz> i really need to go now 21:09 <@dev-zero> lu_zero: restrictions the various solutions imply 21:09 <@leio-dl> I'm not even sure what's being talked about here 21:10 <@dberkholz> should we close the meeting or is there another council member who wants to wrap up? 21:10 <@dev-zero> let's close the meeting