path: root/meeting-logs/20101218.txt

15:03 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: Saturday, 18th of December, 1500 UTC - agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_a40b5e49c106a3a98656b2caf8e660a1.xml
15:04 <@jmbsvicetto> ok, let's start this meeting
15:05 <@jmbsvicetto> roll-call:
15:05 <@jmbsvicetto> here
15:05 <@Betelgeuse> here
15:05 <@wired> here
15:05 <@jmbsvicetto> Chainsaw: ^^
15:06 <@Betelgeuse> Americans are still sleeping?
15:06 <@wired> Chainsaw: lol
15:06 <@jmbsvicetto> Anyone wants to poke them?
15:07 <@Betelgeuse> let me see if I can find Mark's number
15:07 <@jmbsvicetto> I'm calling ferringb
15:07 <@Betelgeuse> I'll send Mark a SMS
15:08 <@Chainsaw> Yes, present.
15:08 <@jmbsvicetto> ferringb will be joining in a minute
15:08 -!- ferringb [~ferringb@gentoo/developer/ferringb] has joined #gentoo-council
15:08 -!- mode/#gentoo-council [+o ferringb] by ChanServ
15:08  * ferringb mutters
15:08 <@Chainsaw> Welcome ferringb :)
15:09 <@jmbsvicetto> Betelgeuse: Did you caught halcy0n or want me to do it?
15:09 <@ferringb> thanks whoever called, and pardon- I thought I was getting a call from the romanian team ;)
15:09 <@jmbsvicetto> ferringb: it was me :P
15:09 <@Betelgeuse> jmbsvicetto: I sent an SMS
15:09 <@jmbsvicetto> ok
15:09 <@ferringb> yeah, lost track of time this morning working on some work bits
15:09 <@jmbsvicetto> so, we have 5 out of 7
15:09 <@jmbsvicetto> let's start then
15:09 <@ferringb> no halcy0n?
15:10 <@Chainsaw> ferringb: I'm surprised too, this time was chosen specifically for him.
15:10 <@Betelgeuse> ferringb: I sent him an SMS
15:10 <@Betelgeuse> ferringb: I can try calling if he doesn't show u
15:10  * ferringb notes this time is 5am his time
15:10 <@ferringb> correction, 4am
15:10 <@jmbsvicetto> slacking arches was the first topic. scarabeus asked for it and he won't be around. Anyone wants to address this point or should it be postponned?
15:10 <@ferringb> ugh
15:10 <@ferringb> ignore me.  I'm being very, very special- 10am his time.
15:11 <@Chainsaw> jmbsvicetto: I would rather concentrate on getting relevant hardware distributed among devs.
15:11 <@Chainsaw> jmbsvicetto: As in, instead of trying to punish arch teams that are doing the best they can with very little actual hardware.
15:11 <@Betelgeuse> What's the status of emulation?
15:11 <@ferringb> yeah, I was wondering the same
15:11 <@Betelgeuse> I wonder if we could accept non core parts tested with emulation.
15:11 <@Chainsaw> Betelgeuse: Slow & horrible as always.
15:11 <@jmbsvicetto> qemu?
15:12 <@ferringb> bit racey
15:13 <@ferringb> that said, I actually think the emulation thing should be poked at if folks haven't... very least there are a fair number of tricks that can be done to build either proper cross-compile, or in a mixed emulation mode; end result is faster builds at least
15:13 <@Chainsaw> ferringb: Actually I make it 8am Mark's time.
15:13 <@Chainsaw> ferringb: 7am even. Definitely not 10am. It's 3pm here.
15:13 <@ferringb> Chainsaw: east coast last I knew, so +3 from mine.  doubt he's in mountain time (ain't nothing in that timezone)
15:13 <@Chainsaw> ferringb: Ah yeah. Wrong coast as always :)
15:13 <@ferringb> if he's west coast/PDT (my timezone), it's 7am
15:14  * Chainsaw 's only ever been to California, so "US" == "California" in my limited view
15:14 <@Betelgeuse> The number I have is from 2008
15:14 <@Betelgeuse> i can try calling that
15:14 <@ferringb> more on topic... personally I have no issues w/ emulation where possible for testing at least on a trial basis
15:15 <@wired> ok reached the rest area and the much needed gas station
15:16 <@Chainsaw> ferringb: Sure, armin76 is into that.
15:16 <@wired> most basic things should be safe to test with emulation IMO
15:16 <@Chainsaw> ferringb: Emulation & SSH accounts on dev machines.
15:17 < NeddySeagoon> Chainsaw, what hardware is needed - should there be a funding application to to Foundation ?
15:17 <@jmbsvicetto> If we want to go down that route, then we could suggest existing arch teams with low man power to test it
15:17 <@ferringb> straight to voicemail for Mark, so he's not going to be reachable (phone's likely off)
15:17 <@Chainsaw> NeddySeagoon: Reliable dual G5s could help out PPC64. The machines are on eBay, but the prices are high.
15:18 <@ferringb> define high
15:18 <@ferringb> don't suppose one could clarify the reliable angle also?  Guessing g5's haven't aged well?
15:19 < NeddySeagoon> Chainsaw, thats just something for arch teams and council (if needed) to consider.  No need to spend meeting time on it now
15:19 <@Chainsaw> ~200GBP at least.
15:19 <@Chainsaw> ferringb: Reliable means not the quad 2.5GHz and not the dual 2.7GHz, these are liquid cooled will fail.
15:19 <@jmbsvicetto> let me just point out that if we start looking for hardware for arch teams, even mainstream arches like amd64 are likely to make a request
15:19 <@ferringb> given
15:19 <@ferringb> that said, arch teams *should* have a wish list handy, and we should have it available publically
15:20 < NeddySeagoon> jmbsvicetto, anyone can ask
15:20 <@Chainsaw> You can designate an arch as in need of protection. AMD64/X86 are not.
15:20 <@jmbsvicetto> NeddySeagoon: sure
15:20  * ferringb reiterates that point for x86 included; there is *zero* harm in making known folks could make use of hardware
15:20 <@jmbsvicetto> any council member wants to take the task of talking to arch teams and try to find out what hardware is needed?
15:20 <@Chainsaw> I've just listed what you'd need to kickstart PPC64.
15:21 <@Chainsaw> (PowerStation is not reliable, ask Halcy0n for the gory details)
15:21 < NeddySeagoon> Chainsaw, we also need to know where its needed.  No point in shipping hardware all over the world
15:21 <@jmbsvicetto> if the council wants to get involved on this, than perhaps we should also take the chance to think about automated testing boxes
15:22 <@ferringb> jmbsvicetto: thinking tinderbox?
15:22 <@jmbsvicetto> including it as well
15:22 <@wired> autobox :)
15:22 <@Chainsaw> NeddySeagoon: *nod* You can purchase close to the dev though.
15:22 <@jmbsvicetto> ferringb: the weekly builds are an "automated testing platform" ;)
15:22 < NeddySeagoon> Chainsaw, yep, that would be ideal
15:22 <@jmbsvicetto> ferringb: and I have an interest on that
15:22 <@ferringb> similar, although not much time
15:23 <@wired> jmbsvicetto: barely, considering how often it fails :P
15:23  * ferringb has been dealing w/ crap like that for work for the last year or so though
15:23 <@ferringb> won't own the issue, but I'm willing to help
15:23 <@jmbsvicetto> wired: sorry, that only means it's catching problems in the tree :P
15:23 <@wired> I'd be interested in an autobox system as well
15:23 <@wired> jmbsvicetto: heh
15:23 <@jmbsvicetto> so, let's take this to the ml
15:24 <@jmbsvicetto> la files removal / progress
15:24 <@jmbsvicetto> portage-2.1.9* is marked stable now, but we (me) didn't wrote any doc about the la files, nor was I able to send the news item for review
15:25 <@jmbsvicetto> This one is my fault
15:25 <@jmbsvicetto> at this point I see 2 options:
15:25 <@jmbsvicetto> 1. give a deadline to send a news item for review and get the news out before letting people remove the la files (dbus is still waiting for this)
15:26 <@jmbsvicetto> 2. just drop the "embargo" and deal with it
15:26 <@jmbsvicetto> I'd prefer for 1 and would be grateful if anyone else would be willing to help
15:26 <@jmbsvicetto> -for
15:26 <@Betelgeuse> jmbsvicetto: Wasn't there a suggestion for news item wording already?
15:26 <@jmbsvicetto> yes
15:26 <@Betelgeuse> It shouldn't be that much trouble then to get one out.
15:26 <@jmbsvicetto> It shouldn't, I just didn't had the time
15:27 <@Betelgeuse> jmbsvicetto: Can you send an email at the end of this meeting saying it will be committed in 3 days if nothing comes up?
15:27 <@jmbsvicetto> sure
15:27 <@jmbsvicetto> The old news item? It needs some rewording
15:27 <@jmbsvicetto> iirc
15:28 <@jmbsvicetto> I was going to suggest we give until Monday 2359 UTC for someone to put a proposal for a news item or the "embargo" would be dropped
15:29 <@jmbsvicetto> Betelgeuse: ^^ would that work for you?
15:29 <@wired> well if we have a draft ready, let's fix and publish it
15:29 <@jmbsvicetto> can we have a vote on this issue?
15:29 <@jmbsvicetto> wired: yes, but *who*? I failed on this
15:30 <@Betelgeuse> jmbsvicetto: You're not able to redeem yourself? :)
15:30 <@Betelgeuse> If someone else has more time on their hands that's of course better too.
15:30 <@jmbsvicetto> I'll be very busy the next few days
15:31 <@Betelgeuse> Ok. Any takers? I have exams Monday
15:31 <@jmbsvicetto> ok, let's please vote in the following:
15:31 <@wired> same here, but i could try and take a look at the news item midweek
15:32 <@jmbsvicetto> The council will drop the "embargo" on la file removal if no one submits to the dev ml a news item proposal about this issue before 2359 UTC next Monday.
15:32 <@jmbsvicetto> How do you vote?
15:32 <@jmbsvicetto> I agree
15:32 <@wired> Monday is too soon, make it Wednesday
15:33 <@Betelgeuse> Wednesday is ok. It's not a matter of days at this point.
15:33 <@wired> although I don't like the idea of skipping it altogether just because noones does it
15:34 <@jmbsvicetto> ok, Wednesday then and a disagree vote means the "embargo" will remain until the news item is published
15:34 <@jmbsvicetto> How do you vote?
15:34 <@ferringb> randomly
15:35 <@Chainsaw> News item is a necessity. Disagree. Don't try and push it through before the documentation is ready.
15:35 <@Betelgeuse> agree (I would make sure something gets posted though)
15:35  * ferringb seconds betelgeuese/chainsaw
15:36 <@wired> yeah I'm with Chainsaw, we shouldnt encourage skipping steps :)
15:36 <@ferringb> could attempt to draft diego for proper docs also
15:36 <@jmbsvicetto> ferringb: you need to vote to break the tie
15:36 <@Betelgeuse> voting empty is allowed
15:36 <@ferringb> yeah, 'cept that was a joke
15:37 <@jmbsvicetto> sure, but at this point we don't have a decision
15:37 <@Betelgeuse> ferringb: well you also seconded both options :)
15:37 <@ferringb> Betelgeuse: shhh.
15:37 <@jmbsvicetto> So let's push this back to next meeting again?
15:37 <@ferringb> here's the thing
15:37 <@ferringb> yes, docs are needed.  people don't write docs.  thus this delays further and further.
15:37 <@ferringb> well, not so much needed, as very desirable
15:38 <@ferringb> I'd rather not see this keep getting kicked further and further back
15:38 <@ferringb> agree.  not sure wednesday is the best date, but we need to move it forward
15:38 <@jmbsvicetto> so, 3 agree and 2 disagree
15:38 <@jmbsvicetto> Anyone is welcome to help with this task
15:39  * wired will try to
15:39 <@Chainsaw> The only thing worse than blowing up a users system and telling them why is blowing their system up and leaving *them* to figure out what just happened.
15:39 <@jmbsvicetto> s/anyone/everyone/
15:39 <@jmbsvicetto> Chainsaw: I agree, but we've delayed this enough as is
15:39 <@Chainsaw> It's a good change to delete .la files. But you need to tell users why you're doing it and a quick "if you see X, do Y".
15:39 <@jmbsvicetto> so, arfrever's suggestions to EAPI-4
15:40 <@Chainsaw> It is ludicrous do proceed without that.
15:40 <@Betelgeuse> If we fail to get a single email out it's a clear sign things would be just delayed and delayed
15:40 <@Chainsaw> s/do proceed/to proceed/
15:40 <@jmbsvicetto> ferringb: Do you want to talk about required_use before or after this?
15:40 <@Chainsaw> Betelgeuse: If you can't document it appropriately, you're not ready to proceed.
15:40 <@ferringb> jmbsvicetto: what specifically do you wish to discuss?
15:40 <@Betelgeuse> Chainsaw: The vote was to lift the restrictions only if no action is taken
15:41 <@ferringb> ongoing 3sat/sky-will-fall, or
15:41 <@Betelgeuse> Chainsaw: It will still be there even if the news item is not ready by Wednesday as long as the work is on going
15:41 <@jmbsvicetto> ferringb: the patch submitted by ulm and the effect that ongoing discussion has on it
15:42 <@ferringb> someone *really* should talk to flameeyes about .la doc also- he's been after this a while, and is likely available to help ignoring this weekend
15:42 <@ferringb> ulm's already pushed the patch in
15:42 <@jmbsvicetto> ferringb: He's willing to help and he already agreed to release his posts as CC-SA, but he's not willing to write the doc
15:43 <@ferringb> jmbsvicetto: the ongoing discussion isn't discussion.  it's "the sky will fall".  I'm not having those discussions anymore.
15:43 <@jmbsvicetto> ok
15:43 <@jmbsvicetto> So you don't want the proposed function, correct?
15:43 <@Chainsaw> jmbsvicetto: Hardened has a very enthusiastic young jedi, eh, docs writer going by the nickname of klondike.
15:43 <@Chainsaw> jmbsvicetto: Have a word with him if that's what it takes to move this forward.
15:44 <@ferringb> jmbsvicetto: function is pointless.
15:44 <@ferringb> well, backing down slightly... the function should be added *after* if it proves needed
15:45 <@ferringb> everything I laid out in that bug in terms of binding together the various information already available (particularly local use flag info from metadata.xml) makes me think the function isn't needed
15:45 <@jmbsvicetto> so it should be left out of EAPI-4 and, if needed, be discussed for next EAPI version?
15:45 <@ferringb> exactly
15:45 <@jmbsvicetto> ok
15:45 <@ferringb> hell, a 4.1 would be fine by me
15:45 <@Chainsaw> The only conclusion I can draw on REQUIRED_USE is that it is a punch thrown in Arfrever vs repoman.
15:45 <@Chainsaw> EAPI 4 looks sane, leave this out of it so it can be voted in.
15:45 <@jmbsvicetto> Do we want to vote the patch or will we leave this for a final vote on EAPI-4 ?
15:46 <@ferringb> "punch thrown in arfrever vs repoman" ?
15:46 < Arfrever> Chainsaw: REQUIRED_USE isn't related to me at all.
15:46 <@Chainsaw> ferringb: It's a way for Arfrever to bypass repoman in a crazy python dependency nightmare.
15:46 <@jmbsvicetto> Chainsaw: You're mixing proposals
15:46 <@Chainsaw> ferringb: I don't see any clean way to implement it.
15:46 <@ferringb> crazy python dep issue is orthogonal to required_use
15:46 <@Chainsaw> jmbsvicetto: So be clear about what you're discussing, because REQUIRED_USE is on my agenda.
15:47 <@jmbsvicetto> Chainsaw: my fault, sorry
15:47 <@jmbsvicetto> Chainsaw: I was asking ferringb if he wanted to talk about required_use before or after arfrever's proposals for EAPI-4
15:47 <@Chainsaw> Right. I shall shut up until later then.
15:47 <@wired> Chainsaw: we are talking about pkg_required_use()
15:48 <@ferringb> ok, I'm confused
15:48 <@jmbsvicetto> So, do we want to have a vote or make any comments about ulm's patch or do we leave this until we're ready to have a final vote for EAPI-4?
15:49 <@Betelgeuse> The final vote is tagging a commit so it should at least be easy to get what we will tag
15:50 <@Betelgeuse> guess we could have two branches but I wonder how convenient that is
15:51 <@jmbsvicetto> So everyone knows what were talking about, required_use is bug 347353 and arfrever's proposal is http://archives.gentoo.org/gentoo-dev/msg_bec5db8373fca0271fcadf0cd55724e8.xml
15:51 < willikins> jmbsvicetto: https://bugs.gentoo.org/347353 "[Future EAPI] REQUIRED_USE USE state constraints"; Gentoo Hosted Projects, PMS/EAPI; NEW; ulm@g.o:pms-bugs@g.o
15:52 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has quit [Disconnected by services]
15:52  * ferringb mutters
15:52 <@Betelgeuse> jmbsvicetto: The former wasn't on the agenda so at least I am not really that prepared on it
15:52 <@ferringb> seriously, if that '.' thing comes up once more I'm wedgieing folk
15:52 <@jmbsvicetto> Betelgeuse: sorry, that was also my fault
15:53 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
15:53 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
15:53 <@jmbsvicetto> in that case, let's take care of the bug later
15:53 <@Chainsaw> Well that was most annoying.
15:53 <@Chainsaw>  <wired> Chainsaw: we are talking about pkg_required_use()
15:53 <@Chainsaw>  <Chainsaw> wired: You need that. There's no way the package manager can create a useful error message by itself.
15:53 <@Chainsaw> What'd I miss?
15:53 <@ferringb> jmbsvicetto: basically, everything on that list he's been told no.  repeatedly.
15:53 <@jmbsvicetto> so let's discuss arfrever's request
15:53 < Arfrever> jmbsvicetto: In case of my suggestions, please discuss each of them separately.
15:53 <@ferringb> trying to bypass me pointing out issues (repeatedly) via going to the council (which I'm a part of) seems nonsensical
15:53 <@jmbsvicetto> Chainsaw: http://archives.gentoo.org/gentoo-dev/msg_bec5db8373fca0271fcadf0cd55724e8.xml - link to arfrever's proposal
15:54 <@ferringb> fine, we'll put it on the record this time
15:54 <@wired> Chainsaw: I agree :)
15:54 <@ferringb> anyone mind if I work through the points?
15:54 <@jmbsvicetto> please do
15:54 <@jmbsvicetto> I'm ready to vote on this if anyone else wants to
15:54 <@Betelgeuse> I strong dislike how dots in USE flags is presented as some kind of a mandatory feature.
15:54 <@Betelgeuse> but ferringb feel free
15:54 <@ferringb> yeah, just let me address the points
15:54 <@jmbsvicetto> I vote against . in USE flags for the reasons ferringb has stated before
15:55 < Arfrever> Dots were requested also by Tommy[D].
15:55 <@ferringb> among other things, I'm putting this in the fucking record so it stops coming up
15:55 <@wired> let ferringb analyze everything then we talk
15:55 <@wired> then I can start driving again :)
15:55 <@ferringb> #1; doing so is a minor, stupid gain.  Yes it's aesthetically lovely, the problem is that use flags go *everywhere*.  Consider that python would shortly have a flag 'python2.6', that flag would than be able to show up in multiple places in the profiles with ease
15:56 <@ferringb> this isn't equivalent to usage of slot deps in profiles- you can technically convert a slot dep down to a set of ranged deps to keep the eapi as low as possible in profiles (which you have to do anyways for compatibility)
15:57 < Tommy[D]> Arfrever: while i asked for it, it is not a requirement for me, besides the detail, that i talked with ferringb and he has a point about using such USE flags in the profiles
15:57 <@ferringb> change use flags, everywhere that flag can show up (which is a *lot* of places) winds up getting it's eapi bumped to the version allowing thos versions
15:57 <@ferringb> in other words, pain, potentially at the base nodes of the profiles themselves, for a freaking period.  It ain't worth it.
15:57 <@Chainsaw> Seconded, I don't want it either.
15:58 <@jmbsvicetto> no, from me as well
15:58 <@ferringb> -infinity against it, and a +1 on a permenant ban from it ever reaching my ears again ;)
15:58 < Arfrever> ferringb: What's wrong in using the newest EAPI in non-deprecated profiles?
15:58 <@Betelgeuse> If all languages like php and ruby also moved to using dots then it would be fine
15:58 <@ferringb> Betelgeuse: even then, it wouldn't be.  consider those flags making their way into the default use flag configuration for a profile
15:58 <@ferringb> that's the thing
15:58 <@jmbsvicetto> ferringb: there's also the issue that current tools will break if a . is used on use flags, right?
15:58 <@ferringb> think through base/make.defaults in the profiles- it specifies use flags
15:59 <@Betelgeuse> ferringb: It would be a major coordinated effort any way but yeah.
15:59 <@ferringb> now if you ever want php5.4 or whatever the hell as a default, the base becomes EAPI=4; locking out basically the entire upgrade path
15:59 <@Betelgeuse> ferringb: multiple inheritance would allow creating a EAPI 4 base
15:59 < Tommy[D]> Arfrever: backward compactibility, think about users with older installs, which do a sync, then want to select a new profile as suggested and then wont get anywhere because their portage does not support the profile
16:00 <@ferringb> you'd have to shadow the entire profile tree
16:00 <@ferringb> Betelgeuse: there are ways, I don't deny it, but you must acknowledge they're generally all involving large amounts of pain, and zero lube ;)
16:00 <@Betelgeuse> ferringb: I know. I was basically agreeing with you in different words.
16:00 <@ferringb> pardon ;)
16:00 <@Betelgeuse> ferringb: Basically with added gains it could be worth the trouble later down the road.
16:01 <@ferringb> if it's ever to be done, it should be deployed during a wholescale restructuring of use flags
16:01 <@ferringb> introduction of use groups (proper use groups) for example.
16:01 <@jmbsvicetto> Does anyone else want to vote on this point? we already have 3 no votes
16:01 <@Chainsaw> You'd probably have to switch to a "profile2" directory.
16:01 < Arfrever> *-${EAPI} files would avoid duplication of profiles.
16:01 <@Chainsaw> I don't see another way.
16:01 <@wired> I vote no for now
16:01 <@Chainsaw> wired: Not until the end of time?
16:01 <@ferringb> Arfrever: in favor of duplication of data.  great solution.
16:01 <@wired> lol
16:02 <@Chainsaw> wired: My vote is unlikely to change.
16:02 <@ferringb> anyone really want me to tear at #2?
16:02 <@Betelgeuse> Chainsaw: We can't tie the next council any way :)
16:02 <@wired> I think this can happen when/if we figure out a way to ensure upgrade paths for users
16:02 <@jmbsvicetto> So this point was voted no with 4 votes: ferringb, chainsaw, me and wired 
16:02 <@Betelgeuse> jmbsvicetto: I voted no too
16:02 <@jmbsvicetto> Betelgeuse: ok, I missed it
16:02 <@Betelgeuse> Probably too unclearly
16:02 <@wired> I have something in mind i need to write down someday
16:03 <@ferringb> I suggest adding it to a bug of "these are the things we'd like to do if we ever can break use flags"- it should be tracked
16:03 <@jmbsvicetto> ferringb: talk about point 2 please
16:03 <@ferringb> not much to say.  it's equivalent to pointing a shotgun on your foot
16:04 <@ferringb> it's relying on humans to get things right across multiple eapi versions
16:04 <@jmbsvicetto> to me it's another GLEP55 variation and I already expressed my dislike for that. I vote no
16:04 <@wired> jmbsvicetto: exactly
16:04 <@ferringb> it doesn't address later versions (how does EAPI=5 fit into a profile that has 2, and 4 for a file?), and generally, it's a freaking hack trying to prop up #1
16:05 <@Betelgeuse> bug 349021
16:05 < willikins> Betelgeuse: https://bugs.gentoo.org/349021 "Tracker: Use flag restructuring"; Gentoo Hosted Projects, PMS/EAPI; NEW; betelgeuse@g.o:pms-bugs@g.o
16:05 <@ferringb> Betelgeuse: thanks
16:05 <@jmbsvicetto> Betelgeuse: thanks
16:05 < Arfrever> ferringb: EAPI specified in filename is used only for syntax inside given files.
16:05 <@ferringb> Arfrever: trust me, I understand the profiles and what you're trying to do here
16:06 <@wired> it'll be maintenance nightmare...
16:06 <@ferringb> yep
16:06 <@ferringb> in light of that, what's the gain?
16:06 <@jmbsvicetto> Arfrever: Instead of going down that route, I want us to review the profiles so we can move the trouble files inside real profiles that can have an eapi file
16:06 < Arfrever> wired: What exactly would be maintenance nightmare? My suggestion actually avoids/decreases maintenance nightmare.
16:07 <@ferringb> Arfrever: your suggestion compounds it massively
16:07 <@Betelgeuse> u
16:07 <@Betelgeuse> sorry
16:07 <@wired> again, what we really need here is a way to ensure users have their pm up to date
16:07 <@Betelgeuse> willikins: WE already do
16:07 <@Betelgeuse> wired: ^
16:08 <@jmbsvicetto> wired: there are issues with the package.mask file and the base profile
16:08 <@wired> I've been thinking of a solution that includes switching our rsync repo's name on big updates
16:08 <@jmbsvicetto> wired: is that like Patrick's proposal?
16:08 <@wired> similar
16:08 <@ferringb> not sure if others have been throw equivalent, but when you try doing massive swaps like wired is talking about, with hard cut off's and manual transitions... you bleed users off
16:08 <@ferringb> *through
16:09 <@wired> but more automated
16:09 <@Betelgeuse> When a new EAPI is introduced putting latest EAPI for central packages but without breaking Portage upgrade path makes it quite likely that people are on new versions.
16:09 <@Betelgeuse> Of course this probably doesn't solve profile problems here.
16:09 <@ferringb> wired: what, like having EAPI markers in the profiles, or an EAPI marker in the repository? ;)
16:09 <@jmbsvicetto> Betelgeuse: but that only works for a certain timeframe
16:10 < Arfrever> Both solutions to problem #2 allow to implement solution to problem #1 in profiles.
16:10 <@ferringb> #1 isn't a fucking issue
16:10 <@ferringb> it's a period
16:10 <@jmbsvicetto> Betelgeuse: after 3 or 4 EAPI bumps, you would need to do 3 or 4 jumps to specific snapshots of the tree and then you would need to find the distfiles for the packages and run the merging for the 3 or 4 updates
16:10 <@ferringb> seriously.  use a dash.  backwards compatibility sucks, but we do have to do it
16:10 <@wired> ferringb: cutting off all updates to current rsync except from portage, then when portage gets updated it switched the make.confirm rsync line to the new repo automatically
16:10 <@wired> switches*
16:11 <@ferringb> wired: there are other ways; repository format markers
16:11 <@wired> sure
16:11 <@ferringb> think it was ulm I was last talked w/ about it; it's reasonably clean
16:11 <@jmbsvicetto> anyway, I suggest we take this discussion to the ml as it wasn't in our agenda and at this rate we won't end this meeting
16:11 <@ferringb> eh, let's vote on #2
16:12 <@jmbsvicetto> right
16:12 <@ferringb> if folks have time, I'd like to finish this list off in full
16:12 <@jmbsvicetto> I vote no
16:12 <@wired> ferringb: yeah just working on a basic idea
16:12 <@ferringb> -1, +infinity for never hearing it again
16:12 <@Chainsaw> I vote no, until the end of time.
16:12 <@wired> I vote no
16:12 <@jmbsvicetto> I meant moving to the ml the talk about how to review Gentoo upgrade paths, not arfrever's email
16:12 <@wired> I hate suffixes
16:12 < Arfrever> jmbsvicetto: Please clarify on what is this voting.
16:12 <@jmbsvicetto> Arfrever: we're voting about point 2 of your email
16:13 <@jmbsvicetto> Betelgeuse: how do you vote?
16:13 < Arfrever> jmbsvicetto: Problem #2 has 2 suggested solutions. Is it voting on the first or second solution.
16:13 < Arfrever> s/\.$/?/
16:13 <@jmbsvicetto> Arfrever: sorry, I missed that
16:13 <@ferringb> Arfrever: there is no reason to create those profiles, exempting for if you actually managed to get #1 implemented; it was killed
16:14 <@jmbsvicetto> ferringb / Chainsaw / wired: Do you vote no to both proposals or just to the first?
16:14  * ferringb isn't against profile restructuring if needed for an eapi
16:14 <@ferringb> -infinity no on the first part (.$EAPI), and no on the second since right now, there ain't any reason to do it
16:14 <@Chainsaw> jmbsvicetto: No on both.
16:15 <@wired> no on both
16:15 <@Betelgeuse> No on both.
16:15 <@ferringb> that 4, or 5?
16:15 <@jmbsvicetto> I vote no on the first and push back the 2nd to a larger discussion in the mls
16:15 <@Betelgeuse> But I don't mean that profile restructuring is not allowed.
16:15 <@Betelgeuse> But I don't want to mandate any such thing currently.
16:15 <@ferringb> I doubt anyone is against profile restructuring
16:15 <@jmbsvicetto> 5 no votes for the 1st solution, and 4 no votes and 1 back to the ml for the second solution
16:15 <@ferringb> there just has to be a _reason_ to do it
16:16 <@ferringb> folks feel like finishing the list?  point #3?
16:16 <@Chainsaw> ferringb: Go for it.
16:16 <@jmbsvicetto> yes
16:16 <@ferringb> in reading the text... want my "the sky will fall" explanation, or can you see the QA mess that will unleash w/out it?
16:17  * ferringb is refering in this case to both proposed solutions
16:17 <@jmbsvicetto> ferringb: The "solutions" presented on this case deserve some debate, imho. But not in relation to the proposed problem
16:18 <@Betelgeuse> I can see a problem needing a solution here.
16:18 <@ferringb> to some degree, I agree
16:18 <@Betelgeuse> Ruby should have similar problems with differently stability of VMs
16:18 <@ferringb> I just very strongly think doing what is proposed there is going to lead to maintenance hell
16:18 <@Betelgeuse> like jruby vs. mri
16:19 <@Betelgeuse> maybe 3) unstable use flags?
16:19 <@ferringb> hmm
16:19 <@Betelgeuse> so users with default stable keywords would have to unmask them
16:19 <@jmbsvicetto> ferringb: the "unsatisfiable" idea reminds me of the special repo in paludis for packages that don't exist in the tree. That is something I think we might want to talk about sometime, but I don't see how that has anything to do with python
16:19 <@ferringb> Betelgeuse: how would that work across profiles though?  that's more a repository level thing
16:19 <@Betelgeuse> ferringb: repo global support could be enough
16:19 <@ferringb> jmbsvicetto: unsatisifable in exherbo is a seperate beast, and worthwhile rip off also.
16:19 <@Betelgeuse> ferringb: for at least for these use cases
16:20 <@jmbsvicetto> the separate unstable / stable profile idea is also something that we can talk about, in particular if we get back to the idea of moving KEYWORDS out of ebuilds, but I also don't see how this is tied to python
16:20 < Arfrever> Betelgeuse: Some flags would have to be unstable on some architectures.
16:20 < Arfrever> s/on/only on/
16:20 <@Betelgeuse> Then it could stack like all other stuff?
16:21  * ferringb notes that has the potential to screw repoman run times over pretty hardcore
16:21 <@ferringb> well... that's assuming repoman is doing the same optimizations pcheck does for profile collapsing
16:21 <@ferringb> either way, QA scanning runtime implications
16:21 <@Betelgeuse> In general I think it's too late for EAPI 4
16:21 <@ferringb> agreed
16:22 <@ferringb> the unsatisfiable angling also I very strongly disagree with
16:22 <@wired> agreed, we should discuss this a bit more
16:22 <@ferringb> unstable/stable classification (as a whole) isn't something I'd thought about, but that is a discussion point
16:22 <@jmbsvicetto> Betelgeuse: I know in the past we had KDE packages bumps that added optional support for new features (new deps) that lead to this issue - how to mark the package stable and have the new use flag which pulled an unstable package masked just for stable users
16:23 <@Betelgeuse> jmbsvicetto: So basically the stability attributes for use flags
16:23 <@jmbsvicetto> I do agree it's to late to discuss this for EAPI-4
16:24 <@jmbsvicetto> Betelgeuse: yes
16:24 < Arfrever> Bug #348087 contains example problem. dev-python/numexpr should be stabilized, but its optional dependency (sci-libs/mkl) cannot be stabilized.
16:24 < willikins> Arfrever: https://bugs.gentoo.org/348087 "Stabilize dev-python/pytables-2.2.1"; Gentoo Linux, Applications; RESO, LATE; arfrever@g.o:python@g.o
16:24 <@wired> something like ~use to define unstable use flags maybe?
16:24 <@ferringb> it's not about unstable flags
16:24 <@jmbsvicetto> so, shall we have a vote for 3?
16:24 <@ferringb> it's about optional deps, enhancements
16:25 <@ferringb> wired: imo at least.  if you think about it in that context, stable/unstable lose their meaning and it's more of an annotation
16:25 <@Betelgeuse> On first thought ~use seems a good idea
16:25 <@jmbsvicetto> Betelgeuse: hmm, reading your comment and ferringb's again, it's not about adding "unstable flags" but about optional deps hidden behind use flags that are not yet ready to be marked stable
16:26  * ferringb reiterates; forget stable/unstable
16:26 <@jmbsvicetto> sure
16:26 <@wired> ferringb: then this whole thing could fall under the general use flag redesign umbrella
16:26 <@ferringb> the real issue is that at a dep level, it's strongly refed, *always*.  most of the real issues where it's a pain in the ass (say enabling real support for mplayer- *that* is a good example) are optional deps
16:26 <@Betelgeuse> jmbsvicetto: yes but unstable use flags would cause the optional deps to not be able to be enabled
16:27 <@Betelgeuse> jmbsvicetto: as such solving the problem
16:27 <@ferringb> Betelgeuse: and what does it do to the ability to scan unstable pkgs?
16:27 < Arfrever> Please note that any solution needs to be per-profile, so it cannot require any changes inside ebuilds.
16:27 <@ferringb> see my point about reorientating the discussion?
16:27 <@jmbsvicetto> Betelgeuse: in this case I'd prefer Zac's idea of optional deps
16:27 <@ferringb> Arfrever: the proper place for this is *in* ebuilds themselves
16:27 <@ferringb> profiles shouldn't be involved
16:27 <@ferringb> well, not directly at least
16:28 <@wired> this clearly needs a discussion, and I think it belongs in the ebuild
16:28 <@Betelgeuse> Profile should have as little as possible package specific stuff
16:28 <@Betelgeuse> Package specific stuff belongs to the package directory
16:29 < Arfrever> ferringb: After stabilization of Python 2.7 or 3.2 on given architecture, it should be sufficient to change 1 file in a profile of this architecture instead of changing hundreds ebuilds.
16:29 <@ferringb> Arfrever: eclass
16:29 <@ferringb> nice try though
16:29 <@jmbsvicetto> my vote on point 3 is that something related to the solutions presented should be discussed in the mls, not to be included in EAPI-4, but that the problem raised is another source of concern for the current status of python in Gentoo
16:30 <@ferringb> framing the vote; is this eapi-4 material?
16:30 <@ferringb> my vote is no
16:30 <@Betelgeuse> no
16:30 <@jmbsvicetto> no
16:30 <@wired> I vote no for EAPI 4
16:30 <@wired> would like to talk more about it
16:30 <@Chainsaw> I vote no.
16:30 <@ferringb> wired: ml's make perfect sense
16:30 <@wired> heap
16:30 <@jmbsvicetto> so 5 no votes for the solutions presented in point 3 to be part of EAPI-4
16:30 <@wired> yeap*
16:31 <@ferringb> jmbsvicetto: yeah, exactly that phrasing
16:31 <@ferringb> my personal views for >4, the solution presented would get a -1 still (should be in the ebuild, profiles are a maintenance nightmare)
16:31 <@ferringb> but that vote doesn't need to occur here/now
16:31 <@jmbsvicetto> let's move to the bugs then?
16:32  * ferringb shuts up and lets whoever was chairing this beast run it
16:32  * wired this has to be my most bizarre meeting yet, in my car, on an iPhone, in the middle of nowhere
16:32 <@ferringb> wired: you're cribbing dr. seuss there ;)
16:32 <@jmbsvicetto> How much time do you want / can spend on the meeting? (Should we try to finish the meeting or can we prolong it)
16:33 <@jmbsvicetto> wired: photos or it didn't happen ;)
16:33 <@wired> meh
16:33 <@ferringb> I'd personally like to go get some coffee before continuing, but I've got basically all morning as needed for council
16:33 <@jmbsvicetto> we've gone over slacking arches - bug 234706
16:33 < willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
16:34 <@ferringb> if we're continuing, any complaints if I duck out for ~10 minutes or so?
16:34 <@ferringb> or think we'll be finished in 10 ;)
16:34  * Chainsaw shouts RECESS and steps aside to dodge the stampede
16:34 <@jmbsvicetto> Betelgeuse / Chainsaw / wired: ^^
16:34 <@jmbsvicetto> ok
16:34 <@jmbsvicetto> 10 minute break then
16:34 -!- DrEeevil is now known as bonsaikitten
16:34 <@ferringb> back in 10ish
16:34 <@wired> oh nice
16:34 <@wired> I'll start driving then
16:34 <@ferringb> wired: just enough time for you to get pictures
16:34 <@ferringb> heh
16:34 <@wired> heheh
16:34 <@jmbsvicetto> :)
16:36 <@wired> k got a few photos and screenshots of this client :)
16:38 <@jmbsvicetto> hehe
16:40 < ulm> hm, what have you decided on pkg_required_use()?
16:40 < ulm> it's not clear to me from the log
16:41 <@Chainsaw> ulm: That if REQUIRED_USE were somehow accepted, it is a necessity.
16:41 <@Betelgeuse> Did we decide?
16:42 <@Betelgeuse> I don't even remember voting
16:42 <@Chainsaw> Betelgeuse: I believe that since we voted out REQUIRED_USE, pkg_required_use dies with it.
16:42 <@Betelgeuse> Chainsaw: Isn't REQUIRED_USE already accepted?
16:42 <@Betelgeuse> Then there were complications
16:42 <@Betelgeuse> And now it's an open question how to deal with them.
16:43 <@Betelgeuse> Unless we got a decision today
16:43 < ulm> REQUIRED_USE was accepted in the November meeting
16:43 <@Chainsaw> ulm: Ah.
16:43 < ulm> only open point in the pkg_required_use function
16:43 < ulm> then EAPI 4 can be tagged
16:44 <@Chainsaw> jmbsvicetto: ulm has a point, we need to vote on pkg_required_use. I vote yes.
16:44  * ferringb looks up
16:45 <@ferringb> thought we had
16:45 <@ferringb> I vote no on the function
16:46 <@jmbsvicetto> ulm: we pushed it for next meeting
16:46 < ulm> oh well...
16:46 <@jmbsvicetto> Chainsaw: Betelgeuse reminded I forgot to include it in the agenda for this meeting
16:47 <@Chainsaw> jmbsvicetto: Ah, okay. I must have missed that in the disconnection.
16:47 <@jmbsvicetto> everyone back? can we go over the bugs?
16:47 <@ferringb> ahh right, we didn't vote on that
16:47 <@jmbsvicetto> so
16:47 <@jmbsvicetto> bug 234706 - slacker arches (we've gone over this issue in the meeting)
16:47  * ulm wonders why jmbsvicetto then asked for topics in his announcement
16:47 < willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
16:48 <@jmbsvicetto> ulm: Did you ask for it? If so, I missed your email. I'm sorry
16:48 < ulm> jmbsvicetto: http://archives.gentoo.org/gentoo-project/msg_3463900fd31abf9894c4c07e1a4a9978.xml
16:48 <@Betelgeuse> I think we can vote on it today if people think they have enough info
16:49 <@jmbsvicetto> Betelgeuse / ferringb: As it was I who missed it and we seem to have some time, do you want to talk about required_use?
16:49 <@ferringb> pkg_required_use to be clear
16:49 <@jmbsvicetto> zmedico: ping ?
16:49 <@jmbsvicetto> yes, pkg_required_use
16:49 <@Chainsaw> I am happy to vote pkg_required_use in at this point.
16:49 < zmedico> jmbsvicetto: pong
16:50 <@wired> yes please
16:50 <@Chainsaw> Because I don't see how a package manager could produce a sane error message without it.
16:50 <@jmbsvicetto> zmedico: Do you want to say anything about pkg_required_use?
16:50 <@ferringb> Chainsaw: give me an example asserition
16:50 <@ferringb> *assertion
16:50 < zmedico> jmbsvicetto: this sums up my feelings: https://bugs.gentoo.org/show_bug.cgi?id=347353#c26
16:51 <@jmbsvicetto> zmedico: ferringb proposes that pkg_required_use be left out of EAPI-4 and be considered for a next revision if it is showed a need for it
16:51 <@jmbsvicetto> ferringb: right?
16:51 <@ferringb> basically
16:51 <@ferringb> I'm mostly waiting for examples that disprove my earlier comments about the PM being able to hit 90% of the req itself w/ a bit of work
16:51 < zmedico> as long as we don't have to call pkg_pretend when REQUIRED_USE is unsatisfied, it's fine with me
16:52 <@Betelgeuse> ferringb: How will an ebuild write know he's hitting the 10%?
16:52 <@ferringb> Betelgeuse: by someone giving me an example right here/now so we have something concrete to discuss
16:52 <@jmbsvicetto> ferringb: you don't want the PM to call pkg_pretend because of require_use, do you?
16:52 <@ferringb> pkg_pretend isn't involved in required_use
16:52 <@ferringb> required_use is prior to pkg_pretend
16:52 <@Betelgeuse> jmbsvicetto: one proposal was for pkg_pretend to do a double duty
16:53  * ferringb is -1 on such a proposal
16:53 <@jmbsvicetto> yes, but I just want to clarify that PMS should be clear that it's not acceptable for the PM to call pkg_pretend
16:53 <@ferringb> different stages
16:53 <@jmbsvicetto> ferringb: right, that's what I wanted to confirm
16:53 <@jmbsvicetto> your -1 vote
16:53 <@Betelgeuse> Well PMS shouldn't document all kinds of false behavior.
16:54 <@jmbsvicetto> I'm now ready to vote. Does anyone want to discuss this further?
16:54 <@Betelgeuse> zmedico, ferringb: Would auto detection in PM prove to be complex to implement and as such prone to bugs?
16:54 <@ferringb> ok; and zmedico presumably will back me up on this, but under eapi-4, it's basically 1) do resolution; notify users about flat out broken deps, 2) required_use validation; notify user about conflicts, 3) pkg_pretend invocations as necessary, notify users about those failures, 4) nofetch validations, invoke as needed for fetchs unable to be completely
16:54 <@ferringb> that's the *current* state of REQUIRED_USE/eapi-4
16:55 <@ferringb> folks grok that?
16:55 <@Betelgeuse> ferringb: Can't we have pkg_required_use in eclasses?
16:55 <@Betelgeuse> ferringb: Then it can be upgraded on the fly as needed.
16:55 <@Betelgeuse> ferringb: Then the logic would be same for all PMs
16:55 <@ferringb> stick to the resolution/current state first
16:55 <@Betelgeuse> ferringb: And you would not have to reinvent the wheel
16:55 <@ferringb> folks get that that is how the PM actually does it's thing?  note that 3/4 could be varied in ordering, but that's the rough steps
16:56 < ulm> Betelgeuse: you might have the function in an eclass, but the PM must still call it
16:56 <@Betelgeuse> ulm: yes
16:57 <@jmbsvicetto> Betelgeuse: my reading is that the issue is not where the function is defined, but whether one should open the door for execution of code or stick to metadata resolution
16:57  * ferringb notes execution of code is duplication
16:57 <@ferringb> ok, consider ( mysql sqlite ), right?
16:57 <@ferringb> one or the other
16:58 <@ferringb> err
16:58 <@ferringb> ok, consider || ( mysql sqlite ), right?
16:58 <@ferringb> *cough*
16:58 < zmedico> it's conceivable that you could add a REQUIRED_USE_EXPLANATION variable, and avoid executing code that way
16:58 <@ferringb> the PM, presuming it's not written by monkeys (descendants of monkeys are fine though), knows that that's an OR; so if neither is satisfied, it can tell the user "you must choose one or the other of the following"- then it can pull the local use for that pkg for mysql/sqlite
16:59 <@ferringb> zmedico: ugh.  annotate REQUIRED_USE itself rather than a parallel tree please
16:59 < zmedico> sure
16:59 <@jmbsvicetto> annotations seem to make more sense here
16:59  * ferringb notes you already have them in local use flags
17:00 <@ferringb> the only context missing is annotating the group operator- the 'or', the 'and', the 'exactly one of', which the PM _already_ knows about since it's the one enforcing the constraint
17:00 <@jmbsvicetto> ferringb: not arguing against that
17:00 <@ferringb> so... considering those points, that the data is already there, what's the point of the function?
17:00 <@ferringb> beyond each ebuild/eclass author working around PMs not implementing such a UI design I mentioned?
17:01  * ferringb notes that's his point, through and through; the PM can do this on it's own, doesn't require ebuild/eclass authors writing it
17:01 <@jmbsvicetto> ferringb: I think ciaranm objection was about more complex cases
17:01 <@ferringb> aware
17:01 <@ferringb> again, I wanted examples
17:02 <@ferringb> *real world examples*
17:02 <@jmbsvicetto> ferringb: something like ^ ( mysql sqlite postgres) on package A, ( mysql ) on package B, ( sqlite ) on package C and ( mysql postgres  ) on package D
17:03 <@ferringb> jmbsvicetto: easy counter; explain to me how a pkg level pkg_required_use could explain the conflicts there any better than the manager could?
17:03 <@jmbsvicetto> ferringb: I understand and I don't have any particular world examples that would break your proposal
17:03 <@ferringb> because the *manager* is the one that knows the depgraph, and the use configuration it's choosen
17:03 <@jmbsvicetto> ferringb: btw, I agree with your proposal
17:03 <@ferringb> the ebuild itself doesn't know that info
17:04 <@jmbsvicetto> anyone wants to continue this discussion or are we ready to vote?
17:05 <@jmbsvicetto> Betelgeuse / Chainsaw / wired: ^^
17:05 <@Chainsaw> Ready to vote.
17:05 <@Betelgeuse> Do PMs have the REQUIRED_USE error handlers ready?
17:05 <@Chainsaw> My opinion hasn't changed.
17:05 <@Betelgeuse> zmedico, ferringb: ^
17:05 <@ferringb> Betelgeuse: no, but the infrastructure for REQUIRED_USE is easily extended for this
17:05 <@ferringb> if it's implemented as a CSP, it's available
17:05 <@wired> I'm ready
17:06 <@jmbsvicetto> ok, let's vote then
17:06 <@ferringb> Betelgeuse: that said, zac may've coded something when I wasn't looking ;)
17:06 <@jmbsvicetto> Should EAPI-4 introduce a pkg_required_use flag to be called if the PM isn't able to fulfill required_use constraints?
17:07 <@ferringb> no
17:07 <@Chainsaw> jmbsvicetto: I vote yes.
17:07 <@jmbsvicetto> s/flag/function/
17:07 <@jmbsvicetto> no
17:08 <@jmbsvicetto> wired / Betelgeuse: ^^
17:08 < zmedico> Betelgeuse: this is what portage uses for user feedback: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/portage/dep/__init__.py;hb=master#l1984
17:09 < zmedico> required_use.replace("^^", "only-one-of").replace("||", "any-of")
17:09 <@wired> 1 sec
17:09 <@ferringb> zmedico: yeah, that can be extended a fair bit also
17:09 <@Betelgeuse> zmedico: What is your preference on the question under vote?
17:10 < zmedico> Betelgeuse: it doesn't matter to me. I'm only opposed to calling pkg_pretend when REQUIRED_USE is unsatisfied
17:10 <@ferringb> zmedico: alternative question; is the function needed, or can the PM do it itself?
17:10 <@wired> I vote no, unless proven needed. even then, the internal function should be disabled by a flag in the ebuild when the external function is required
17:11 <@Betelgeuse> A tertiary option is calling it if the function is defined and otherwise falling back on the PM default.
17:11 <@wired> or that
17:11 <@Betelgeuse> This way people can just start writing pkg_required_use when things start falling apart.
17:11 < zmedico> ferringb: I don't know, I think maintainers of ebuilds that would need REQUIRED_USE would be more qualified to speculate
17:11 <@ferringb> well, as is it's 3 nos, 1 yes, 1 undecided
17:11 <@Betelgeuse> Of course this sounds a little bit future proofing.
17:12 <@ferringb> I'm generally opposed to optional's like Betelgeuse is suggesting, but it's a compromise
17:12 <@Betelgeuse> no now and fast 4.1 with pkg_required_use as I described as soon as there's a need in main tree
17:12 <@ferringb> my main concern is that it allowed PM authors to skimp on it, thus forcing it to become the default
17:12 <@ferringb> *allows
17:13 <@ferringb> well, moreso forcing ebuild devs to define it to work around shitty package managers
17:14 <@jmbsvicetto> are everyone votes final? Can I count them?
17:14 <@wired> brb in 2' on a normal keyboard
17:14 <@ferringb> 2 feet?
17:14 <@wired> 2 minutes :P
17:14 <@ferringb> feet's funnier
17:15 <@Betelgeuse> jmbsvicetto: yes
17:15 <@jmbsvicetto> ok, I think this meeting productivity is going down hill, so let's try to wrap this issue and finish the meeting, please?
17:16 <@Betelgeuse> jmbsvicetto: yes
17:16 <@Chainsaw> jmbsvicetto: I vote yes!
17:16  * ferringb votes yes, quickly before wired makes it the 2 feet
17:16 <@ferringb> yes to finishing up that is.  still -1 on pkg_required_use
17:17 <@wired> hehe
17:17 <@jmbsvicetto> So, we have 3 votes no, 1 vote yes and 1 undecided vote on having EAPI-4 introduce a pkg_required_use function to be called by the PMs when they can't fulfill the requird_use constraints
17:17 <@wired> back
17:18 <@wired> -1 on the function from me as well
17:18 <@jmbsvicetto> I suggest we leave the bug for next meeting
17:18 <@wired> for eapi 4[.0] anyway
17:18 <@jmbsvicetto> the remaining bugs*
17:18 <@Betelgeuse> jmbsvicetto: who's undecided?
17:18 <@ferringb> jmbsvicetto: "<@Betelgeuse> no now and fast 4.1 with pkg_required_use as I described as soon as there's a need in main tree"
17:18 <@ferringb> so -4, +1; with myself/betelgeuse advocating a hedged 4.1 if needed (others possibly also)
17:18 <@jmbsvicetto> ok, then the votes weren't final :P
17:19 <@jmbsvicetto> So, 4 votes no and 1 vote yes on ...
17:19 <@Betelgeuse> jmbsvicetto: I said that before you asked if stuff is final
17:19 <@wired> ferringb: me 2 :)
17:19 <@jmbsvicetto> I also advocate 4.1 if needed
17:19 <@Betelgeuse> ulm: Presumably there's text to approve for next meeting then?
17:20 <@Betelgeuse> or just via email
17:20 < ulm> Betelgeuse: you could approve http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=9d2b8ee57bf3be941cfdfe13650952d91b9edfdc now, if you want
17:20 <@jmbsvicetto> so can we leave the remaining bugs for next meeting or do you have any you want to go over now?
17:20 <@Betelgeuse> jmbsvicetto: I need to leave soon so later please
17:21 <@jmbsvicetto> sure
17:21 <@Betelgeuse> I suggest we all take a look at that commit and aim to approve it before end of year :)
17:21 <@ferringb> agreed
17:21 <@Betelgeuse> but let's handle the remaining agenda first
17:21 <@jmbsvicetto> so when should we have our next meeting and who wants to chair it?
17:22 <@wired> what about the 28th?
17:22 <@jmbsvicetto> wired: ? So soon?
17:22 <@jmbsvicetto> If we try to do it on a Tuesday again, what about 11th or 18th of January?
17:22 <@Betelgeuse> We need to have a meeting in January any way
17:22 <@wired> either that or agree on a voting day for eapi-4 via email
17:22 <@wired> then we can do it on january
17:23 <@jmbsvicetto> I say we vote on EAPI-4 by email
17:23 <@wired> the 11th sounds good
17:23 <@Betelgeuse> wired: I'll make sure we get input from everyone in time before the end of year
17:23 <@wired> Betelgeuse: a deadline (say, this friday, or the 27th) would be nice
17:23 <@jmbsvicetto> oh and here's an idea, what about a meeting on February 5th? ;)
17:24 <@jmbsvicetto> (after the next one)
17:24 < NeddySeagoon> heh
17:24 <@wired> ;p
17:24 <@Betelgeuse> jmbsvicetto: let's get the next one nailed first
17:24 <@jmbsvicetto> sure
17:24 <@wired> so, how's the 11th?
17:25 <@jmbsvicetto> +1 from me
17:25 <@wired> (tuesday)
17:25 <@Betelgeuse> ok for me (evening UTC+2)
17:25 <@Betelgeuse> wired: I'll come up with a schedule
17:25 <@jmbsvicetto> what time did we meet last time? 2000 UTC?
17:25 <@Betelgeuse> wired: (for approval)
17:26 <@wired> 2000 UTC yeah, lets stick to that for now
17:26 <@wired> Betelgeuse: great, thanks
17:26 <@Chainsaw> Tuesday the 11th; 2000 UTC works well for me.
17:26 <@Chainsaw> In favour *raises hand*
17:26 <@jmbsvicetto> ferringb: what about you?
17:26  * ferringb can swing 20utc
17:26 <@jmbsvicetto> So, who wants to chair the meeting?
17:27 <@ferringb> we'll have words if someone proposes another 15:00utc though ;)
17:27 <@wired> heh
17:27 <@wired> well
17:27 <@wired> today's meeting had one advantage
17:27 <@wired> noone had to leave
17:27 <@wired> :)
17:28 <@jmbsvicetto> and we had a first-time - a "car" meeting ;)
17:28 <@wired> :P
17:28 <@wired> oh yeah the photos
17:28  * wired scps
17:28 <@jmbsvicetto> no one is willing to volunteer to chair the meeting?
17:28 <@wired> if noone else wants to
17:28 <@wired> (beside's jmbsvicetto who just chaired)
17:28 <@wired> i'll do it
17:29 <@jmbsvicetto> I'd prefer not to do it next time
17:29  * ferringb notes saturday seems to work a bit better actually
17:29 <@Betelgeuse> I can take one too if no-one is voluntary
17:29 <@ferringb> per wired's comments
17:29 <@Betelgeuse> I need to go now.
17:29 <@jmbsvicetto> So, who is going to chair it?
17:30 <@Betelgeuse> wired: want to do it or will I?
17:30  * NeddySeagoon notices everyone looking at jmbsvicetto 
17:30 <@jmbsvicetto> NeddySeagoon: :P
17:30 <@wired> Betelgeuse: i don't mind, you decide :)
17:30 <@Betelgeuse> Ok. I'll let you :)
17:31 <@jmbsvicetto> so, wired will chair next meeting
17:31 <@Betelgeuse> So you can take whatever comes after I'll leave now into account :)
17:31 <@Betelgeuse> Bye and thanks
17:31 <@wired> heh
17:31 <@wired> thanks, c ya
17:31 <@jmbsvicetto> Thanks everyone. Brian thanks for taking all this at 700 AM and Alex for doing it in your car
17:32 <@jmbsvicetto> The floor is now open. Does anyone have anything for the council?
17:32 -!- leio_ [~leio@gentoo/developer/leio] has joined #gentoo-council
17:33  * wired uploading proof.. err pictures :)
17:34 <@ferringb> jmbsvicetto: 7am ain't too bad for me, it's just not always guranteed
17:34 -!- leio [~leio@gentoo/developer/leio] has quit [Ping timeout: 272 seconds]
17:34  * ferringb was up since 5am anyways
17:35 <@jmbsvicetto> ok, the meeting is closed then
17:35 <@jmbsvicetto> if anyone in the community has anything to say, just leave us a message