[gentoo-commits] gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20090226-summary.txt 20090226.txt

[Thomas Anderson (gentoofan23)]

gentoofan23    09/03/02 18:36:16

  Added:                20090226-summary.txt 20090226.txt
  Log:
  Add Council log and summary for meeting on February 26 2009

Revision  Changes    Path
1.1                  xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt?rev=1.1&content-type=text/plain

Index: 20090226-summary.txt
===================================================================
Roll Call:
===========
Betelgeuse: here
Cardoe: here
dberkholz: here
dertobi123: here
dev-zero: here
leio: here
lu_zero: here
tanderson(secretary): here

Topics:
===========

Open Council Spot:
    - Should leio fill the empty council spot?
        Since Mark(halcy0n) resigned from the council there is an empty spot.
        Since Mart Raudsepp(leio) is ranked next from the last election, he is
        eligible to fill the spot.

        Conclusion:
            Mart Raudsepp is unanimously approved for the council.

Technical Issues:
    - GLEP 55
        There had been quite a bit of discussion on this topic recently.
        Within hours of the council meeting new proposals were being proposed
        and discussion was ongoing. 

        Conclusion:
            No decision as of yet. Ciaran Mccreesh(ciaranm) and Zac
            Medico(zmedico) volunteered to benchmark the various proposals on
            the package managers they maintain(paludis and portage
            respectively. Petteri(Betelgeuse) will assist with the portage
	    benchmarks. Tiziano(dev-zero) and Alec Warner(antarus) will write
            up a comparison of the various proposals and their various
            advantages and disadvantages within a week.

    - GLEP 54
        There had been some discussion on gentoo-dev since last meeting,
        though no consensus or agreement had been reached(surprise!)

        Conclusion:
            Thomas Anderson(tanderson) and Luca Barbato(lu_zero) will write up
            a comparison of the advantages and disadvantages of the two
            proposals(-scm and _live). This will be completed within a week.

    - Overlay Masking in Repositories.
        Brian Harring(ferringb) asked for discussion for when overlays
        attempted to unmask packages provided by the master 
        repository(gentoo-x86). Because this is only available in portage
        (it is contrary to PMS), Brian thought it should not be allowed.
        
        Numerous suggestions were made to the effect that if a standardized
        set format was agreed upon for repositories and package.unmask was
        allowed to contain sets, then this problem would be fixed.

        Conclusion:
            No decision, as only discussion was requested. Mart Raudsepp(leio)
	    will follow up on this with discussion on gentoo-dev



1.1                  xml/htdocs/proj/en/council/meeting-logs/20090226.txt

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090226.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090226.txt?rev=1.1&content-type=text/plain

Index: 20090226.txt
===================================================================
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@××××××××××××××××××××××××××.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@××××××××××××××××××××××××××××××××××××××××××××××.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