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> Chainsaw: we are talking about pkg_required_use() 15:53 <@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