18:00 <@Betelgeuse> rollcall
18:00 <@dertobi123> <- here
18:00 <@leio> here
18:00 <+tanderson> <--- here
18:00 <@lu_zero> here
18:00 <@Betelgeuse> weaver, solar
18:00 <@Betelgeuse> ulm:
18:00 < weaver> here
18:00 <@ulm> here
18:01 <@Betelgeuse> !seen solar
18:01 < Willikins> Betelgeuse: solar was last seen 44 seconds ago, saying "araujo: not really. But the EAPI mess they created in system is to be frowned upon."
18:01 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has joined #gentoo-council
18:01 <@Betelgeuse> He should be around soon then.
18:02 < likewhoa> Betelgeuse: he's currently active in #gentoo-ten, letting him know now.
18:02 <+tanderson> he's active in #-dev too
18:03 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-council
18:03 <@solar> damn I hate UTC. I figured it was not for another hr
18:04 <@lu_zero> ^^;
18:04 <@leio> date -u :)
18:04 < weaver> everyone needs to just switch to utc
18:04 <@Betelgeuse> Ok let's start with item 1.
18:05 <@Betelgeuse> I propose it's the duty of the meeting chair to post any follow up and the secretary should remind him if it's not done when summaring is being approved.
18:05 <@Betelgeuse> Then we don't have to wonder whose job things are.
18:06 <@leio> That sounds reasonable when we are rotating chairs
18:06 <@Betelgeuse> yes
18:07 <@Betelgeuse> When someone accepts chair for a meeting they should be prepared to follow up too in the future.
18:07 <@lu_zero> ok
18:07 <@ulm> fine
18:08 < weaver> sounds good
18:08 <@dertobi123> i disagree - imho those who want things to be discussed should be the ones getting the discussion going on
18:08  * solar seconds dertobi123 
18:08 <@leio> that sounds reasonable too...
18:08 <@dertobi123> i.e. of Calchan wants to discuss some glep39 stuff, i expect him to show up on the meeting and also to get discussion going
18:08 <@dertobi123> s/of/if
18:09 <@leio> then again, we should be proactive as a team and follow up on these things collectively and get them concluded
18:10 < weaver> dertobi123: i think the point was if the council makes an actionable item, someone needs to be responsible for acting on it
18:11 <@Betelgeuse> dertobi123: I have no problem with someone else taking responsilibity but the chair should do it if they don't.
18:11 <@Betelgeuse> Otherwise nothing happens.
18:11 <@ulm> dertobi123: if you take the "PMS/EAPI committee" example of last meeting, who should have acted on it, in your opinion?
18:11 <@dertobi123> weaver: and the ones being responsible are those who want to see things happen - not necessarily the council itself which decided further discussion on that matter is necessary
18:11 <@dertobi123> ulm: hrm, you?
18:12 < weaver> the flexible solution i think is for every item on the agenda that the council decides to act on, to designate the person responsible
18:12 < weaver> don't you guys do that already? :P
18:12 <@lu_zero> better if there is one or more volunteers
18:12 <+tanderson> I think if an actionable item is delayed, put one person in charge of that item
18:12 <+tanderson> It's been done in the past and should work fine
18:12 <@ulm> dertobi123: I disagree, because I had made two propositions
18:13 <@ulm> dertobi123: the ones who voted for "something different" should have followed up with something concrete here
18:13 <@solar> fine. dump it all and go back to eapi=0
18:13 <@dertobi123> ulm: but then you want a decision, so it's your interest to get the discussion started
18:13 <@dertobi123> solar: agreed.
18:14 <@Betelgeuse> solar: let's stay on the topic at hand
18:14 <@solar> that is my follow up.
18:14 <@lu_zero> ulm so far the "kill pms for good" seemed to be the best solution =)
18:15 <+tanderson> assigning someone for each item(and noting it in the summary) seems fine...
18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
18:15 -!- antarus|home [n=antarus@gentoo/developer/antarus] has joined #gentoo-council
18:15 <@lu_zero> seems good
18:16 <@ulm> also ok
18:18 <@dertobi123> if there are no volunteers that specific topic is dead
18:18 <@dertobi123> no one interested in getting things discussed, no important topic
18:19 <@Betelgeuse> dertobi123: And what about purely administrative topics like slacker handling?
18:20 <@dertobi123> Betelgeuse: what needs to be followed or discussed on such topics?
18:21 <@Betelgeuse> dertobi123: Last time people did not vote on my slacker handling during the meeting so follow up was needed, not the best example
18:21 <@Betelgeuse> Any way please vote so we can move to the next topic.
18:21 <@leio> Vote on what?
18:22 <@Betelgeuse> leio: 18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
18:22 <@dertobi123> Betelgeuse: at the end of our last meeting it was clear you won't get a slacker mark, nothing to follow up (besides a summary being wrong in that aspect)
18:22 <@solar> I have no input either way. Do whatever you guys feel is right
18:22 <@leio> and additionally note in the summary as agreed
18:23 <@lu_zero> seems balanced
18:23 <@leio> (I suggest action points like, ACTION: description (volunteer), and noting down on top who was the chair)
18:24 <@Betelgeuse> weaver: around?
18:24 < weaver> yes
18:24 <@Betelgeuse> weaver: your opinion?
18:25 <@ulm> leio: that's a detail, do you think we must vote on it?
18:25 <@leio> no
18:25 < weaver> I vote on:  <Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
18:25 <@leio> I'll just bend tanderson arm to do it like that :)
18:25 <+tanderson> bahaha, usually works too =)
18:26 <@ulm> I vote yes, too
18:26 <@leio> I votes yes, to be clear
18:26 <@dertobi123> no, obviously
18:26 < weaver> ok, let's move on then
18:26 <@Betelgeuse> So yes: Betelgeuse, ulm, leio, weaver neutral: solar no: dertobi123
18:27 <@Betelgeuse> Topic 2
18:27 <@Betelgeuse> zmedico: Are you here?
18:27 <@dertobi123> uhrm, what abou lu_zero?
18:27 <@Betelgeuse> damn counted like it was seven but failed
18:28 <@solar> moot. Majority rule?
18:28 <@leio> we have four yes already though, but I didn't see a clear vote from weaver
18:28 < weaver> yes
18:28 < weaver> ^ vote
18:28 <@Betelgeuse> Please be more active than every 5 minutes
18:28 <@lu_zero> I already voted long ago...
18:28 <@lu_zero> anyway yes
18:29 < weaver> ok, zmedico is not here to give us an EAPI 3 report?
18:29 <@Betelgeuse> My guess is that no progress has been done.
18:30 <@Betelgeuse> But it's just a guess.
18:30 <@leio> When I inquired on #gentoo-dev a few days ago, he said that he wants to get a 2.1.7 release out before working on EAPI 3
18:30 <@Betelgeuse> I don't remember reading any bug spam related to EAPI 3
18:30 < antarus|home> the 2.1.7 release was this past weekend
18:30 <@dertobi123> well, 2.1.7 is out ;)
18:30 <@leio> I didn't ask if EAPI 3 work will follow immediate after that or not ;p
18:30 <@ulm> If bug 273620 is accurate, then there are still several things missing
18:30 < Willikins> ulm: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 3 implementation"; Portage Development, Core; NEW; s.mingramm@gmx.de:dev-portage@g.o
18:31 <@Betelgeuse> ulm: and they are the actually time taking parts
18:31 -!- reavertm_ [n=reavertm@83.27.157.92] has joined #gentoo-council
18:31 <@ulm> Betelgeuse: yes, looks like :(
18:32 -!- Tommy[D] [i=bnc@gentoo/developer/tommy] has joined #gentoo-council
18:32 <@Betelgeuse> Maybe we could offer a bounty for EAPI 3.
18:33 <@Betelgeuse> But that's to discuss with trustees.
18:33 <@lu_zero> I'd let another month pass and then think about it seriously
18:33 <@leio> We could get an update very soon from Zac outside meeting time and post it in an e-mail for everyone to read
18:34 <@dertobi123> we *should*
18:34 <@Betelgeuse> So who volunteers to ask him?
18:35 < antarus|home> why not just send him an email?
18:35 <@Betelgeuse> antarus|home: email can be used to ask?
18:35 <@ulm> well, if noone else volunteers... I can ask him
18:36 <@Betelgeuse> ok
18:36 <@Betelgeuse> I don't see anything further we can do for point 2 so let's move to case 3.
18:37 <@Betelgeuse> Let's discuss 5 minutes and vote.
18:37 <@Betelgeuse> I think if we open the list then we will have others requesting the same.
18:37 <@solar> I'll vote right now that it should be left up to the respective PM's on how they want to deal with it.
18:37 <@Betelgeuse> When energy could be better spend getting EAPI 3 out and work on EAPI 4 to be faster.
18:37 <@leio> We can demand an implementation to exist
18:37 <@solar> as mtimes can not be counted on in the first place (think compressed file systems)
18:38 <@ulm> solar: that's exactly what we shouldn't do because it will result in breakage
18:38 <@lu_zero> I second that
18:38 <@lu_zero> ulm exactly how?
18:38 <@ulm> there's good reason why portage preserves them
18:39 <@ulm> lu_zero: see http://bugs.gentoo.org/263387 as one example, but there are several others
18:39 <@solar> sure there is. But it can't be counted on. But can't be enforced properly ever
18:40 <@leio> I don't see why a PM should mangle what the build systems make install does
18:40 < weaver> I don't have an opinion as I'm not informed of upsides and downsides of mtime modification
18:41 <@ulm> leio: right, it should try to preserve as much as possible when merging D to ROOT
18:42 <@solar> there are valid reasons. But why are we going outside of the ebuild syntax and into behaviors that are best left up to the programmers coding the respective PM's ?
18:42 <@solar> seems an overstep of the council
18:42 <@ulm> solar: because the ebuild cannot do anything if the PM decides to mangle mtimes
18:42 <@leio> We seem to be involved because paludis PM disagrees with portage and pkgcore PM
18:43 < weaver> the PM spec is not just for syntax of the ebuilds
18:43 <@Betelgeuse> Vote: Reopen EAPI 3 for mtimes?
18:43 <@Betelgeuse> I vote no.
18:43 <@solar> then perhaps they can duke it out?
18:43 <@ulm> solar: see <http://bugs.gentoo.org/83877#c36> for horrible "solutions" on the ebuild level ;)
18:43 <@leio> and because it is asserted it's an EAPI feature
18:44 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 110 (Connection timed out)]
18:44 <@leio> I vote yes
18:44 <@ulm> I vote yes, obviously
18:44 < weaver> hmm
18:44 < weaver> I understand that calchan would vote yes
18:44 <@ulm> weaver: calchan requested the feature for portage, btw ;)
18:44 < weaver> so, I vote yes
18:44 <@dertobi123> i vote yes, too
18:45 <@lu_zero> yes also for me
18:46 <@ulm> solar?
18:46 <@Betelgeuse> yes: leio ulm  weaver dertobi123  lu_zero no: Betelgeuse ?: solar
18:47 <@Betelgeuse> Then we need the wording.
18:47 <@solar> ulm: I'm not sure right now. Majority rule.
18:48 <@Betelgeuse> ulm: So do you have a short pros and cons to give about the options?
18:49 <@ulm> Betelgeuse: Obviously A is the simplest and gives all control to the ebuild
18:50 <@ulm> B will optionally allow the PM to update "old" time stamps
18:50 < weaver> i'm sorry, where are the A/B/... described?
18:50 <@ulm> and C will make that updating mandatory, but please note that C is not "zero cost" for Portage
18:51 <@ulm> weaver: http://bugs.gentoo.org/264130#c26
18:51 < weaver> ok thanks
18:51 < weaver> what's the definition of an "old" mtime?
18:52 <@leio> what do you mean under optionally in option B? PM can freely choose to do that or not, or the ebuild instructs it with some variable?
18:52 <@ulm> weaver: time before the build process of the package started
18:52 <@ulm> leio: PM can freely choose
18:53 -!- lxnay|two [n=lxnay@host-78-14-152-87.cust-adsl.tiscali.it] has joined #gentoo-council
18:53 <@ulm> leio: i.e. most likely Portage and Pkgcore would just preserve mtimes
18:53 <@ulm> Paludis would update "old" ones
18:53 < weaver> would that break stuff?
18:53 -!- few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-council
18:54 <@ulm> weaver: hopefully not, but i've checked for lisp, python, and ghdl only
18:54 <@Betelgeuse> zmedico prefers A
18:54 <@ulm> right
18:54 < weaver> then let's go with A
18:55 < antarus|home> ulm: the intention is to prevent rebuilds with build systems based on mtime?
18:55 <@ulm> antarus|home: the intent is more directed at runtime
18:55 <@Betelgeuse> Please vote on a A|B|C and let's see if we get a majority (if not ready please note):
18:55 <@ulm> antarus|home: e.g., .py vs .pyc or .lisp vs .fasl
18:55 <@leio> A
18:55 -!- Zorry [n=zorry@fu/coder/zorry] has joined #gentoo-council
18:56 <@lu_zero> A
18:56 < weaver> A
18:56 <@dertobi123> A
18:56 <@ulm> B
18:57 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
18:57 <@ulm> (but I can live with A too)
18:57 <@Betelgeuse> I am neutral between A and B.
18:57 <@dertobi123> (i can live with b, too - but prefer A)
18:58 <@leio> I understand B is the same as A in case of portage and pkgcore
18:58 <@ulm> leio: right
18:58 <@Betelgeuse> leio: yes
18:59 <@Betelgeuse> A: leio, lu_zero, weaver, dertobi123 B: ulm A|B: Betelgeuse ?: solar
18:59 < weaver> is there a specific option that ciaran/paludis is objecting against?
18:59 <@ulm> weaver: he (they?) prefer C
19:00 <@ulm> and paludis complies to none of the options presently
19:00 < weaver> ok
19:00 <@ulm> s/to/with/
19:00 < weaver> I understand we have a majority on A, so let's move on then?
19:01 <@Betelgeuse> The hour allotted is up. Anyone need to go or can we have some time for open floor?
19:01  * leio has time
19:02  * weaver has time
19:02  * lu_zero has time
19:02  * ulm has time
19:02 <@Betelgeuse> Tommy[D] wanted us to talk about the multilib stuff.
19:02 <@Betelgeuse> I havent' had much time to look into it.
19:02 <@Betelgeuse> In the thread zmedico was saying it needs EAPI changes.
19:02  * dertobi123 has some minutes
19:02 <@Betelgeuse> So most likely EAPI 4 and as such would take time.
19:02 <@leio> me neither, I hope to dig into that, have had various thoughts about that on my own, would be nice to see what they have done there
19:03 -!- dabbott|work [n=david@gentoo/developer/comprookie2000] has quit ["Heading home"]
19:03 <@lu_zero> I used myself the multilib overlay and is quite interesting (and useful)
19:03 < Tommy[D]> Betelgeuse: did you also read my reply to him?
19:04 <@Betelgeuse> Tommy[D]: it wasn't immediately evident from that
19:05 < Tommy[D]> Betelgeuse: so optional, additional features would require EAPI, but not the basic functions
19:05 <@ulm> Tommy[D]: would that require to change ebuilds lateron?
19:05 <@ulm> i.e. when the "optional, additional features" have been implemented
19:06 -!- antarus|home [n=antarus@gentoo/developer/antarus] has left #gentoo-council []
19:06 < Tommy[D]> ulm: i use multilib-portage with main tree, if the ebuilds and build system respects the env, no changes are needed
19:07 < weaver> i have no opinion on this
19:07 < Tommy[D]> the only place, where you either need to depend a specific portage version (with multilib support) or an EAPI, which requires PM with multilib support, is the *DEPEND on libs/packages with additional 32bit libs
19:07 < weaver> and i'm not aware if Calchan does
19:08 <@Betelgeuse> For me I would like zmedico to first fogus on EAPI 3 before this stuff
19:08 <@Betelgeuse> Of course he does what he wants with his time.
19:08 < weaver> yes I believe eapi 3 needs to be pushed out ASAP
19:09 < weaver> it's been delayed and it has a bunch of useful features
19:09 < Tommy[D]> i did implent the current version of multilib-portage, based on previous work done by other people and i would continue working on it, so the main work would be a code review by zmedico
19:09 <@Betelgeuse> Tommy[D]: Sure but it's a major feature to Portage
19:10 <@Betelgeuse> Tommy[D]: Testing etc would slow down EAPI 3 to stable
19:10 <@Betelgeuse> Tommy[D]: If it stays in trunk, then fine.
19:10 < Tommy[D]> the main issue is that zmedico once got a council warning because of some changed or additional feature, thats why i request the discussion and later decision here
19:11 < Tommy[D]> Betelgeuse: i would not mind, if it stays in 2.2_rc* for now, while EAPI-3 could go into 2.1.*
19:11 <@Betelgeuse> Tommy[D]: Yes he did change EAPI 0 behavior without our blessing.
19:11 <@Betelgeuse> Tommy[D]: Before I can vote on this it needs to be clear to me whether this does that.
19:12 <@Betelgeuse> Tommy[D]: I think PMS currently says phases can run only once.
19:12 <@Betelgeuse> I don't know what that is based upon.
19:12 < Tommy[D]> it violates current PMS in at least 1 point: execute every phase at max once
19:12 < weaver> this sounds like something we should intentionally delay until after EAPI 3 is out
19:12 <@lu_zero> I think that could be relaxed
19:13 <@lu_zero> still it could be done in parallel and make push it as the main part of eapi 4
19:13 < Tommy[D]> my implementation would require something like "preserve none-default env vars in filesystem between phase switches"
19:13 <@Betelgeuse> We can do an EAPI 4 that is fast for zmedico to implement.
19:13 <@Betelgeuse> for needs in this
19:14 <@Betelgeuse> and other fast stuff
19:14 < weaver> as long as the people involved are sure it won't delay EAPI 3
19:14  * leio has no opinion about this until some research
19:15 <@solar> Till our devs learn how to use the existing EAPI's properly I have no desire to introduce another eapi
19:15 <@Betelgeuse> solar: devs beside direct Portage deps should always use the latest
19:15 < weaver> solar: how are they used improperly?
19:15 < Tommy[D]> multilib-portage itself can be added without any additional EAPI
19:15 <@solar> weaver: system. There is no clean upgrade path.
19:15 < NeddySeagoon> Betelgeuse solar is that a reason to depreciate and remove old EAPIs ?
19:16 <@Betelgeuse> NeddySeagoon: the stay in vdb
19:16 <@leio> portage oralready requires EAPI-2 :9
19:16 <@Betelgeuse> NeddySeagoon: We can make repoman require latest EAPI for new ebuilds
19:16 <@Betelgeuse> NeddySeagoon: But only after discussion
19:16 <@solar> that is sick
19:17 < weaver> sick as in good or bad
19:17 <@solar> bad and in evil and a dumb idea
19:17 <@Betelgeuse> solar: there's fatal and warning repoman levels, this would fall in the latter
19:17 < weaver> i don't see why not, as long as revisions are allowed in older eapis
19:17 < Tommy[D]> Can multilib-portage inclusion be added to agenda of next meeting? And i would like to see comments, requests and discussion about it until then
19:17 < NeddySeagoon> Betelgeuse, that would be good.  PMs have to be capable of removing old stuff ... but we should encourage the use of the current/latest EAPI
19:17 <@solar> Betelgeuse: there is no clean upgrade path in that
19:18 <@Betelgeuse> solar: You only need an upgrade path for direct Portage deps
19:18 <@solar> I'm in favor of reverting lots of system packages back to EAPI=0
19:18 <@Betelgeuse> solar: So you can get to new Portage
19:18 < weaver> solar could you elaborate on what the problem is, I'm not familiar with it
19:18 <@solar> weaver: take a box from 2008 and try to upgrade it. You can't
19:18 < weaver> what happens?
19:18 <@Betelgeuse> python
19:18 < weaver> oh
19:19 < Tommy[D]> weaver: old portage, which doesnt know EAPI-2 cannot upgrade because newer portage requires newer python, but all pyhton packages have EAPI-2
19:19 <@Betelgeuse> python people decided for all to break upgrade path without warning.
19:19 <@solar> gotta give it to bonsaikitten for one time. He had the right idea on how to allow a mix. You always keep one ebuild at EAPI=0
19:19 < weaver> oh. can't we roll a transitional verison of portage that would deal with this issue specifically?
19:19 <@Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back.
19:20 <@Betelgeuse> weaver: We don't need to.
19:20 <@solar> this means you need a python-2.6 and eselect* at 0
19:20 <@Betelgeuse> Just need python people to do their job.
19:20 < weaver> i guess...
19:20 <@Betelgeuse> They can't make decisions like that for everyone.
19:21 <@Betelgeuse> solar: Could you take responsibility on working with them trying to get EAPI 0 back there?
19:21 <@ulm> solar: hm? eselect is still at EAPI 0
19:21 <@Betelgeuse> If it doesn't work out, we can put it on the agenda nexttime.
19:21 <@ulm> solar: with good reason
19:22 <@Betelgeuse> Who wants to chair next time?
19:22 <@solar> Betelgeuse: I'm not sure I'm nice enough to work with them (I have much anger about this topic).
19:22 <@leio> and take care of the agenda
19:23 <@ulm> solar: sounds like you're the right person for it then :p
19:23 <@solar> leio: I would second this for the next round then. 07:19PM <Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back.
19:24 <@solar> ulm: I do much better work when I'm happy. Gentoo 10 was a hit
19:24 < weaver> should I volunteer Calchan to do this? :]
19:24 <@Betelgeuse> weaver: probably not
19:25  * ulm can take it
19:25 <@leio> lets say I can look with solar into the upgrade path business
19:26 <@Betelgeuse> ulm: chair or upgrade path?
19:26 <@ulm> Betelgeuse: chair
19:26 <@Betelgeuse> ok ulm chair and leio EAPI 0
19:26 <@solar> leio: that would work. TeamWork++
19:26 <@Betelgeuse> I call this meeting done. Thanks everyone.
19:26 < weaver> thank you
19:26 <@solar> thanks Betelgeuse
19:26 <@ulm> question of understanding: followups are for the _previous_ chair, right?
19:27 <@Betelgeuse> ulm: I would follow up from today.
19:27 <@ulm> Betelgeuse: k
19:27 <@Betelgeuse> I will make sure leio does.
19:27 <@Betelgeuse> And you ask zmedico.
19:28 <@lu_zero> please let's try to use more the council alias
19:28 <@Betelgeuse> private is bad
19:29 <@lu_zero> we have also the council ml
19:29 <@Betelgeuse> better
19:29 <@lu_zero> still both of them are quicker and easier to follow than -dev
19:29 <@Betelgeuse> following -dev comes with the job
19:30 -!- reavertm_ is now known as reavertm
19:30 <@solar> the alias is proper for some things.
19:30 <@solar> Not going to send a personal reminder to the entire list just to make sure ppl don't get the slacker mark.
19:30 <@Betelgeuse> sure alias is fine for that
19:30 <@Betelgeuse> but not discussing technical stuff etc
19:31 <@solar> nod
19:31 <@Betelgeuse> I am off to write a short essay that's due today.
19:31 <@solar> well unless you don't want input from some ppl.
19:31 <@solar> anyway cya.
19:31  * dertobi123 nods
19:32  * lu_zero runs away as well
19:32 <@lu_zero> nite ^^
19:33 < weaver> have fun people