It is attached, the log&summary has already been put on the project page.
-- --------- Thomas Anderson Gentoo Developer ///////// Areas of responsibility: AMD64, Secretary to the Gentoo Council ---------
Roll Call:
===========
Betelgeuse: here
Cardoe: here
dberkholz: here
dertobi123: here
dev-zero: here
leio: here
lu_zero: absent(?, waiting for feedback), 37 minutes late
tanderson(secretary): here
Topics:
===========
EAPI-3 Proposals:
Note: The following two proposals were discussed before it was realized
that there was not sufficient time to discuss all of them. At that point a
call for objections to any of the proposals found at [1] was asked for,
and none were made. A full list of proposals for EAPI 3 follow.
- New phase: pkg_pretend
This phase is most useful for displaying conflicting USE flags at
dependency resolution time(pretend), though it has various other uses
so that errors about installing the package can be displayed before
installation of packages begin.
Conclusion:
Approved for the draft.
- [flag(+/-)] USE dependencies
This may be needed when one wishes to depend on a package with a
certain USE flag but if the USE flag is not present in that package
assume it is on or off(+ and - respectively).
Conclusion:
Approved for the draft.
- Multislot Dependency Specifications
This allows ebuils to tell the package manager that runtime
dependencies are not swappable(:1 installed at runtime can't be
removed even though :2 'satisfies' the dependency).
- PROPERTIES mandatory in cache
Some information provided by this variable is useful at --pretend
time(interactive packages).
- DEFINED_PHASES mandatory in cache
Same reasons as for PROPERTIES, but is also useful for determining
the phases a package provides with just the cache.
- Provide a default src_install prototype.
Get rid of the need for the src_install functions with just `emake
install` in them. Some discussion is needed to clear up issues with a
DOCS variable for extra documentation and a list of docs to
automatically get installed.
- Provide a `docompress` function.
This function serves as a replacement for prepalldocs. `docompress`
can optionally compress files in /usr/share/doc according to a set of
inclusion and exclusion lists.
- Provide a '-r' option to `dodoc`
Providing a way to put `dodoc` in recursive mode is widely accepted.
- Make `doins` preserve symlinks
This obsoletes the `cp -R` constructs frequently seen and is easy to
implement.
- Limit values in $USE to those in $IUSE.
Certain USE_EXPAND flags may be in USE even if they aren't
specifically set in IUSE. Eliminate this.
Next Action:
The Council agreed to have portage implement as many of these as
possible in a month and then make that EAPI 3.
Technical Agenda Items:
- GLEP 54
Thomas(tanderson) sent out a comparison of GLEP 54 and the liveebuild
proposals.
Among those discussing GLEP 54 there was a general consensus that
there was nothing wrong with it as a first step to get correct
ordering. Luca(lu_zero) commented that all he was concerned about was
that there was not enough 'meat' to the GLEP.
Next Action:
Doug(Cardoe) and Luca(lu_zero) intend to write a
GLEP to handle the second part of the problem(making the revision
available to ebuilds/package manager/users.
- GLEP 55
Petteri, Zac, and Ciaran were supposed to benchmark the various
proposals and report back. Zac did not write the code for portage so
Petteri had nothing to report on this issue. Ciaran commented that
the solutions other than GLEP 55 had a 50% slowdown in the valid cache
situation compared to GLEP55, but did not post the raw numbers or the
patches used.
Next Action:
Zac needs to benchmark the proposals in portage.
Open Floor:
===========
- Migration of KEYWORDS from ebuilds to profiles:
Ned Ludd(solar) brought this up, but it came up in the middle of agenda
items so was not talked about much. Some points were made that such a scheme
would require a git conversion, but nothing was agreed upon.
References:
[1]: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
15:01 <@dberkholz> ok, let's get started 15:01 <@Cardoe> Betelgeuse: yes? 15:01 <@Betelgeuse> Cardoe: just to find out that you are here 15:01 -!- ferdy [n=fe...@exherbo/developer/ferdy] has joined #gentoo-council 15:01 <@Cardoe> Betelgeuse: I've been here talking for the last hour 15:01 <@dberkholz> Betelgeuse, Cardoe, dberkholz, dertobi123, leio-dl are here 15:01 <@Betelgeuse> dev-zero: 15:01 <@dberkholz> lu_zero, dev-zero -- pong please 15:02 <@dev-zero> dberkholz: pong 15:02 -!- arkanoid [n=arkan...@exherbo/developer/arkanoid] has joined #gentoo-council 15:02 <@dberkholz> lu_zero: check in again when you're back 15:02 < fmccor> lu_zero was here 9 minutes ago 15:02 <@dberkholz> let's start 15:03 <@dberkholz> anyone mind if we talk briefly about the path to EAPI=3, even though it wasn't on the draft agenda? 15:03 <@Betelgeuse> There won't be a shortage of ideas the main deciding thing is zac. 15:03 <@Betelgeuse> Unless someone gets down to coding. 15:04 <@dberkholz> zmedico: around? 15:04 <@Betelgeuse> As can be seen with GLEP 55 if we rely on zac we really can't make much plans. 15:04 <@dev-zero> Betelgeuse: for at least one issue on the task there's already a patch for portage 15:04 < ciaranm> half the things on the list are five minute bash jobs 15:04 <@dev-zero> second, some issues are pretty much isolated and don't need much portage knowledge 15: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. 15:05 <@Betelgeuse> good 15: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 15:05 <@dev-zero> yes 15:05 <+tanderson> hi, I'm here now 15:05 <@Betelgeuse> Well repoman support would help a lot too. 15:05 <@dev-zero> and the multislot dep issue 15:05 <@Cardoe> ciaranm: was that for handling the missing case? 15:05 < ciaranm> Cardoe: yeah 15:06 <@dberkholz> which line is that on the spreadsheet? 15:06 <@dberkholz> use(+) 15:06 <@dev-zero> 6 15: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. 15:06 <@Betelgeuse> dev-zero: please post a link so it gets logged 15: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 15:06 <@Cardoe> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ is the spreadsheet and #6 is what we're talking about 15:07 < ciaranm> Cardoe: the syntax exheres-0 uses is foo/bar[flag(+)] and foo/bar[flag(-)] 15:07 <@dev-zero> here are the eapi-3 feature proposals: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ 15:07 <+tanderson> I need to catch up :\ 15:07 < ciaranm> where (+) means "pretend it's on if foo/bar doesn't have flag in IUSE" 15:07 <@Cardoe> dev-zero: they're missing a bunch that ciaranm suggested and I'd like to see merged in. 15:07 <@Cardoe> ciaranm: thanks 15:07 <@dev-zero> Cardoe: hmm, which ones? 15:08 <@Betelgeuse> I don't really see it solving the remove use flags problem unless we always start to use these atoms. 15:08 <@dev-zero> Betelgeuse: that's true 15:08 < ciaranm> Betelgeuse: until someone removes the use flag in a newer version, though, you don't know what your dep will want 15:08 <@Betelgeuse> You should always check reverse stuff any way. 15: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 15:09 <@Betelgeuse> ciaranm: I know but I was referring to the spreadsheet. 15:09 <@Cardoe> I think it's a good syntax as any unless there are any technical objections. 15: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 15:09 <@leio-dl> we just need tools to show automatically what depends on an IUSE in any way to deal with it 15:09 * ciaranm really can't type tonight 15:10 <@Betelgeuse> dev-zero: One thing to add is doexamples 15:10 <@Cardoe> ok lemme speed this up. 15: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 15:10 <@dev-zero> Betelgeuse: good point 15:10 < ciaranm> leio-dl: yup. fortunately, people do global tree scans regularly to catch that sort of thing. 15: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.. 15:10 <@leio-dl> always after the fact. Lets move on 15:11 < ciaranm> leio-dl: there's no nice easy solution to dealing with reverse deps, and use deps don't really alter that 15:11 <@Cardoe> Do we want [use(+)] deps to go into the EAPI-3 draft? dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero? 15:11 <@Cardoe> I say yes. 15:11 <@leio-dl> yes 15:11 <@dertobi123> yep 15:11 <@dev-zero> yes 15:11 <@dberkholz> fine w/ me 15:11 <@Betelgeuse> dberkholz: well in the long term we should more helper stuff to the tree 15:11 <@Cardoe> dertobi123: sorry for missing you off 15:11 <@dertobi123> Cardoe: :P 15:11 <@Betelgeuse> Cardoe: sure 15:11 <@Cardoe> dertobi123: too many d's 15:12 <@dertobi123> heh 15:12 <@Cardoe> Ok. Next item on the draft. 15:12 <@Cardoe> pkg_pretend() 15:12 <@dberkholz> we'll have to vote for higher council nick diversity next time. 15:12 <+tanderson> bwahaha 15:12 <@dberkholz> i am totally for pkg_pretend 15:12 <@Cardoe> I would like to see pkg_pretend() useful for displaying USE conflicts 15:13 <@Cardoe> http://bugs.gentoo.org/show_bug.cgi?id=75936 15:13 <@dberkholz> there are so many ways it's useful 15:13 <@Cardoe> To allow the developer to put a description behind it. 15:13 <@dev-zero> yes, me too, but we should still try to find a more pm-based solution for USE conflicts 15:13 <@Cardoe> because the current way Portage displays it sucks 15:13 <@dberkholz> telling people we're gonna break their system before a merge instead of after 15:13 <@Cardoe> and users are confused 15:13 <@dberkholz> gentoo sysadmins have complained to me about that so many times 15:13 <@Cardoe> pkg_pretend in draft EAPI-3.... dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero, dertobi123? 15:13 <@dev-zero> yes 15:13 <@Cardoe> yes 15:14 <@dberkholz> 20:12 < dberkholz@> i am totally for pkg_pretend 15:14 <@Betelgeuse> Cardoe: Do we need to go through one by one? 15:14 <@dertobi123> yes 15:14 <@leio-dl> abstain (haven't read and thoguht about it enough) 15:14 <@Betelgeuse> Is there anything people disagree on? 15:14 <@Cardoe> Betelgeuse: I'm looking for us to nail down a "draft" list. 15:14 <@Cardoe> That we can hand over to the PM maintainers to implement 15:14 <@Cardoe> They come back to us once we've got some code and we'll formally resolve the differences and finalize EAPI-3 15:15 <@Betelgeuse> Cardoe: What good does that do if we are tied to Portage implementing things? 15:15 < ciaranm> can always take things out if it turns out portage can't do them quickly 15:15 <@dberkholz> how about we come up with a list of things on that spreadsheet that any of us disagrees with instead 15:15 <@Cardoe> Fine 15:15 <@Betelgeuse> I would propose as to set a time and then see what Portage has then. 15:15 <@dberkholz> it'll take a while to go through 20-something positively 15:15 <@Betelgeuse> And use that for EAPI 3. 15:15 <@dev-zero> I already cancelled some features out (those with prio=99) 15:16 <@Cardoe> dev-zero: please add a reference to bug #75936 to item #1 15: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.mccre...@googlemail.com:pms-b...@g.o 15:16 <@Betelgeuse> I say a month is fine. 15:16 <@dev-zero> Cardoe: I'm sorry, but that's not the same thing 15:17 <@Betelgeuse> Any comments? 15:18 <@dberkholz> so basically request a specific list of features in portage, then take whatever's done in a month and call it 3? 15: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 15:18 <@dertobi123> in a month* 15:18 <@Betelgeuse> dberkholz: it can implement more too 15:19 <@dberkholz> sorry, didn't understand that 15: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) 15: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 15:21 <@Cardoe> Betelgeuse: we're not restricting outselves 15:21 <@Cardoe> We're providing a list of stuff we'd like to see 15:21 <@dberkholz> so we pre-approve features before they're implemented 15: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 15:21 <@Betelgeuse> dev-zero: The easiest way is to divide the features between council members or others to code 15:21 -!- keytoast1r [n=tob...@alpha.libexec.de] has quit [Client Quit] 15:21 <@leio-dl> I don't like pre-approving, if expressed that way 15:22 <@dev-zero> Betelgeuse: ok, fine by me 15:22 -!- theinlein [n=tob...@gentoo/developer/keytoaster] has joined #gentoo-council 15:22 <@dberkholz> leio-dl: what's your problem with it? 15:22 <@Cardoe> We're sifting through the list of proposed features on all the mailing lists 15:22 <@Cardoe> rejecting certain ones out right 15:22 <@Cardoe> and prioritizing some based on the needs and requests 15:22 <@Cardoe> and giving that list to people to code 15:22 <@Cardoe> then we'll check back with what's coded in a month 15:22 <@Cardoe> and go from there 15: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 15:22 -!- theinlein is now known as keytoaster 15:23 <@dberkholz> pre-approving doesn't mean pre-requiring 15:23 <@dberkholz> it means if things work out well, it's in. it could still fail at the implementation step 15:23 <@leio-dl> pre-approving worded like that sounds like we can't end up rejecting it 15:23 <@leio-dl> if it turns out to be a bad idea by then, regardless of the implementation 15: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 15:23 < ciaranm> leio-dl: all of these features are easy to turn on or off in the package manager 15:23 <@dev-zero> that's why you usually have developers at the requirement meeting 15:24 <@Cardoe> It's a wish list 15:24 <@Cardoe> dev-zero: unfortunately we can't force the developers of PMs to be on here 15:24 <@leio-dl> wish list, sure. Just avoid the term pre-approved and I'll be happy 15:24 <@dev-zero> Cardoe: no, it's a requirement list 15:24 <@dev-zero> Cardoe: we have at least one developer of a package manager here 15:25 <@Cardoe> dev-zero: indeed we do and we appreciate it. 15:25 <@Cardoe> dev-zero: but alas the others did not come. 15:25 <@dev-zero> Cardoe: and the prio=1 features have been implemented in one package manager, so a proof-of-concept is done 15: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 15:25 <@Cardoe> leio-dl: he meant as part of development and testing 15:25 < ciaranm> leio-dl: no, i mean, we can implement features in the package manager, but not have them supported for any EAPI 15:26 <@leio-dl> sure, you can implement what you want :) 15:26 <@Cardoe> Honestly folks. This is a rather pointless debate. 15:26 <@Cardoe> We've got a list with priorities 15:26 <@dev-zero> yes 15:26 <@Cardoe> It's done 15:26 <@Cardoe> Move on 15:26 <@Cardoe> dberkholz: what's the next agenda item? 15:27 <@dberkholz> it was overlay masking, but we've already got an action there 15: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 15:27 <@dberkholz> leio-dl just needs to follow up on list, which he's gonna do by saturday 15:27 <@Cardoe> dberkholz: sounds good. 15:27 <@Cardoe> dberkholz: next item? 15:27 <@dberkholz> then we've got the live ebuild stuff 15:28 <@dberkholz> the existing writeup really doesn't address the things i was hoping it would, along the lines that antarus did for 55 15:28 <@Cardoe> frankly the more we look at the live stuff. the more I feel its lacking 15:28 <@dberkholz> i'm wondering whether i need to get involved with that 15:29 <+tanderson> uh, I was supposed to write a comparison, no? 15:29 <@Cardoe> tanderson: yep 15:29 <+tanderson> at least that what everybody agreed on for the summary 15: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 15:29 <+tanderson> so How did what I do not address what was wanted? 15:30 <+tanderson> Cardoe: Yeah, I hope to work on that soon. Thankfully, classes have eased up a bit 15: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 15: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.. 15:31 <+tanderson> er, s/we/you obviously :P 15:31 <@Cardoe> ciaranm: ok fine. 15:31 <@Cardoe> ciaranm: then I'd like a documented way for the user to specify a specific revision 15:31 <@Cardoe> right now we've got ESVN_REVISION and EGIT_REVISION 15:31 < ciaranm> Cardoe: that's stage two, or possibly stage three if it's split in four 15:32 -!- kICkar [n=didko...@unaffiliated/kickar] has joined #gentoo-council 15: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. 15: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. 15:32 <@dberkholz> it's clear to me that my mental picture doesn't match with what i actually requested 15:32 <@Cardoe> ciaranm: fair enough 15:33 <@Cardoe> ciaranm: so we're just going to say this addresses the -9999 ebuild 15:33 <@Cardoe> Is Portage using PROPERTIES=live? 15:33 < ciaranm> Cardoe: right. the glep *just* addresses the ordering problem, and nothing else. 15:34 < ciaranm> PROPERTIES=live isn't necessarily bad. it's just not related to what the glep's trying to solve. 15:34 <@Cardoe> ciaranm: well, we could say that if you make a -scm.. you have to put PROPERTIES=live 15:35 <@Cardoe> in there 15:35 < ciaranm> really... PROPERTIES=live is just a lousy way of sort of attempting some of part two or three... 15: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 15:35 < dleverton> Is there any case when it would be sensible to have -scm without PROPERTIES=live, or vice versa? 15:35 < ciaranm> dleverton: the PCI IDs list, arguably 15:36 <@Cardoe> ok fine 15:36 <@Cardoe> we'll come back to it 15:36 <+tanderson> ciaranm: is that checking out a static revision? 15:36 <@dev-zero> Cardoe: the original motivation behind EAPI=3 was to have it fast 15:36 <@Cardoe> dev-zero: as is my motivation right now. 15:36 <@dev-zero> Cardoe: things like G55, G54 and a couple of more issues which can take month are not suited 15:36 < ciaranm> 54's a lot easier with 55, which puts it into "not fast" territory unfortunately 15:36 <@Cardoe> Does any council member have a technical issue to GLEP 54? 15:37 <@lu_zero> Cardoe the glep should be specified better 15:37 <@lu_zero> but I said that already 15:37 <@leio-dl> I need more time to be sure personally 15:37 <@dev-zero> Cardoe: and I want a reference implementation 15:37 <+tanderson> lu_zero: well, considering it's only addressing part 1, I'm not so sure.. 15:37 <@Cardoe> dev-zero: so do I 15:37 < ciaranm> kdebuild-1's a reference implementation for both 54 and 55 15:38 <@lu_zero> tanderson it's addressing the last part of something bigger 15:38 <@lu_zero> you usually do not start from the roof 15: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 15:38 <+tanderson> lu_zero: well, I think the first part is getting correct ordering 15:38 <@lu_zero> ciaranm it's uses are debatable at best 15:38 <@dev-zero> lu_zero: I agree with tanderson 15:39 < ciaranm> lu_zero: tell that to the people using -9999, -20099999 and so on 15:39 <@lu_zero> ciaranm 9999 it's a value like others 15:39 < ciaranm> lu_zero: which is the problem 15:39 <@dev-zero> ok, I don't see that we get to an end here, do you? 15:39 <@dertobi123> not really ... 15:39 <@lu_zero> you can enforce ordering otherwise 15: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 15:40 <@lu_zero> like preventing people using pkg-1234545677 15: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 15:41 <+tanderson> lu_zero: what kind of meat? 15:41 <@dev-zero> and I still fail to see what needs to be added 15:41 <@lu_zero> dev-zero if I propose you to allow utf8 for names and latin numbers for version 15:42 <@lu_zero> you'd consider me crazy 15:42 < ciaranm> latin numbers for versions is doable 15:42 <@dberkholz> back in 5, gotta take care of something. 15:42 <@lu_zero> ciaranm anything is doable 15:42 <@lu_zero> even utf8 numbers 15:43 < ciaranm> lu_zero: actually no. i could list several proposals regarding versioning that are technically unimplementable. 15:43 <@lu_zero> that alone should make you wonder if is worth it 15:43 <@lu_zero> if there is an use 15:43 < ciaranm> the use for -scm is replacing -9999 etc 15:43 <@lu_zero> the use of utf8 names is to allow crazy names in programs 15:44 <@lu_zero> that doesn't make it more agreable 15:44 < ciaranm> lu_zero: how many programs can you think of that use utf-8 names? 15:44 <@lu_zero> ciaranm I hope none 15:44 < ciaranm> lu_zero: compare that with the number of packages for which people are shipping -scm ebuilds 15:44 <@dev-zero> lu_zero: I think you're getting far away from the real problem 15:44 <@lu_zero> ciaranm I hope none as well 15:44 <@lu_zero> since means that either upstream or the packager is insane 15:45 < ciaranm> lu_zero: there're lots of packages using -9999 or equivalent. most are masked, fortunately, but people find them useful. 15:45 <@lu_zero> ciaranm they are masked since they are unstable by definition 15:45 <@lu_zero> and they are scarce 15:45 < ciaranm> lu_zero: yes. and? they're still there, so we should support them well. 15:45 < ciaranm> lu_zero: look at how many scm-related eclasses there are in the main tree. are you saying they should be removed? 15:45 <@lu_zero> we should support them within the limit of usefulness/effort ratio 15:46 <@lu_zero> ciaranm they can be used even w/out requesting for fluid revisions 15:46 < ciaranm> the only effort for -scm is discussing things with you... it's easy to implement 15:46 <@lu_zero> see mythtv and their ustream 15:46 <@lu_zero> upstram 15:46 <@lu_zero> sigh I cannot spell 15:47 <@Cardoe> lu_zero: I'm the MythTV guy.. 15:47 <@lu_zero> as a -9999 user I'll be glad to have something simpler 15:47 <@Cardoe> Based on what GLEP 54 proponents are trying to say is 15:47 <@Cardoe> let's that be the next step 15:47 <@Cardoe> let us just get the basics down 15:47 <@lu_zero> Cardoe IIRC you had to use constant revision sometimes 15:48 <@Cardoe> yep 15:48 <@Cardoe> But this GLEP won't address all uses of svn/git/cvs/bzr etc 15:48 <@Cardoe> just the -9999 usage 15:48 <@Cardoe> which I don't use 15:48 <@lu_zero> right 15:48 <@Cardoe> I'll have to write a new GLEP 15:49 <@dev-zero> ok, result of this discussion? 15:49 <@dberkholz> back 15:50 <@dev-zero> dberkholz: right in time 15:50 <@Cardoe> lu_zero: I say you and I work on another GLEP on top of this 15:50 <@lu_zero> Cardoe agreed 15:50 <@Cardoe> which brings up a point.. why aren't the EAPIs a GLEP? 15:50 <@Betelgeuse> Cardoe: we tagged PMS last time 15:51 < ciaranm> Cardoe: because we're lazy, and a PMS branch is easier 15:51 <@Cardoe> Fair enough 15:51 <@Cardoe> I like lazy 15:51 <@lu_zero> thehe 15:51 <@Cardoe> next item? 15:51 <@lu_zero> everybody feels 15:51 < ciaranm> otherwise we'd have to rst them for GLEPs as full proposals, and then work that into PMS as diffs 15:51 < solar> remove keywords from ebuilds. 15:51 < solar> ciaranm: can your pkg mgr handle that? 15:51 < solar> ie. profiles/package.keywords 15:52 <@dberkholz> ...? 15: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 15:52 < solar> it wont work? 15:52 < ciaranm> it doesn't scale to what arch teams do 15:53 < solar> it works today in everything else. I just want to make sure i don't cause any segvs 15:53 -!- togge [n=to...@gentoo/contributor/togge] has quit [Remote closed the connection] 15:53 < ciaranm> this was investigated three or four years ago... iirc agriffis an / or g2boojum 15: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 15:54 < solar> ciaranm: well the scaling thing does not really hold true anymore. 15:54 < solar> and conflict is not any more of a problem than say ppl editing other package. 15:54 <+tanderson> ciaranm: wouldn't you get merges rather than conflicts? 15:54 < ciaranm> solar: honestly, i suggest you bring it up after gentoo's using git and lots of smaller independent repositories 15:55 -!- togge [n=to...@212.247.117.70] has joined #gentoo-council 15:55 <@Betelgeuse> Is this really something we need to discuss atm? 15:55 < ciaranm> tanderson: if you're lucky 15:55 < solar> files. Anyway. I plan to go down this route with a bunch of other ppl. So 15: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 15:55 <@Betelgeuse> dberkholz: fine by me 15:55 <@dev-zero> me too 15:56 <@lu_zero> ok 15: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 15:56 <@dberkholz> so what's the deal? 15:56 <@Betelgeuse> I can't benchmark something that's not there. 15:56 <@Betelgeuse> Zac promised me two weeks ago to do it 15:56 <@Betelgeuse> But never did it. 15:56 <@dberkholz> alright 15:56 <@Betelgeuse> So it seems I must implement it myself. 15:56 <@lu_zero> did he tell something about it? 15:57 <@Betelgeuse> lu_zero: See his mail on gentoo-council 15:57 <@lu_zero> just that? 15:58 <@dberkholz> Betelgeuse: ok, can you check back in with zac about that timeframe and drop a post to -council? 15:58 <@Betelgeuse> lu_zero: yeah haven't heard anything yet since that 15:58 <@dberkholz> it is still "this week" after all 15:58 <@lu_zero> right 15: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 15:59 <@dberkholz> ciaranm: i was hoping to see some benchmarks from you. could you post them? 15:59 <@Betelgeuse> Can actually nail down PMS and solve other long standing issues. 15:59 <@lu_zero> I have to ask him something about multislot as well 15:59 <@lu_zero> Betelgeuse would be interesting 16:00 <@Betelgeuse> If this doesn't happen before we have a need for global scope changes we can fall back on 55. 16:00 <@Betelgeuse> In the mean time. 16:00 < ciaranm> dberkholz: just under 50% slowdown in metadata access times in the 'valid cache' case 16:00 <@lu_zero> ciaranm something we could try ourselves? 16:00 <@dberkholz> ciaranm: i'd really love to see the numbers on times for each case 16:01 < ciaranm> dberkholz: for invalid cache cases you can't measure it since bash is a thousand times slower than using the cache 16:02 < ciaranm> lu_zero: why? planning to benchmark it on an ssd just to screw with the results? :P 16:02 <@lu_zero> ciaranm planning to read the patch and see how works 16:02 <@dberkholz> ciaranm: hot cache, cold cache? what are the numbers in seconds? 16:03 <@lu_zero> the more people trying the more shared is the decision upon it 16: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 16: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. 16:04 <@lu_zero> using a default set like xorg + kde + gnome would be a good benchmark 16:04 <@dberkholz> in which situations will people be multiplying it by 10k? 16:05 < ciaranm> dberkholz: you do 10k metadata lookups to do a pretend-install world 16:05 <@lu_zero> even if the minimal set would be a portage or a system set 16:06 <@dberkholz> we've gotta wrap this up 16:06 <@dberkholz> next step is trying to get a portage implem & benchmarked 16:07 <@dberkholz> let's get that and go from there 16:07 <@dev-zero> but to make it clear: benchmark is not the main issue, it may just be another issue 16:08 <@dev-zero> s/benchmark/performance 16:08 <@lu_zero> dev-zero which is the other issue in your opinion? 16:08 <@leio-dl> I think I was supposed to bring my technical objection to G55 to list? 16:09 <@lu_zero> my main concern is least surprise/ease of use, then performance 16:09 < dleverton> The other issue is whether the prosposed solution is insane or not. 16: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 16:09 <@dberkholz> i really need to go now 16:09 <@dev-zero> lu_zero: restrictions the various solutions imply 16:09 <@leio-dl> I'm not even sure what's being talked about here 16:10 <@dberkholz> should we close the meeting or is there another council member who wants to wrap up? 16:10 <@dev-zero> let's close the meeting
pgpKC0HkruFZ5.pgp
Description: PGP signature
