Agenda is here: http://archives.gentoo.org/gentoo-project/msg_ac95bed78694852cd09f20a07437b805.xml [21:01] Roll call hi here Present. fwiw, i've always got logs if nobody else does. hi [21:02] *** nimiux (~nimiux@gentoo/developer/nimiux) has joined channel #gentoo-council Betelgeuse, jmbsvicetto? Do we have phone numbers for the gentlemen in question? [21:03] yes [21:04] I'll call them Thank you. seems I don't have the right number of betelgeuse [21:06] "number is incomplete" hmm, i might have it. lemme check. it could've been on my stolen phone [21:07] and only mailbox for jmbsvicetto the phone numbers should be available in the council@ alias from June just texted Betelgeuse [21:08] dberkholz: hello dberkholz: thanks for the reminder we're still short by one jorge I have a bunch of numbers for him The coverage at his hospital is supposed to be spotty, so a text is probably best. [21:09] *** AdmiralNemo (~dustin.ha@vpn.softekinc.com) has joined channel #gentoo-council I got through to one number but a woman responded in Portuguese [21:11] lol we've got a long agenda today, so I suggest that we start [21:12] it's been 12' can we start? Betelgeuse: is that the 4153 one? EAPI specification in ebuilds grobian: xxx xxx 250 indeed we do. if i'd noticed the times on that agenda, i would've said something. grobian: 4153 did not connect [21:13] ulm: agreed I texted that number discussion on -dev and the wiki page are linked from the agenda *** thrice` (thrice@unaffiliated/thrice/x-000000001) has joined channel #gentoo-council [21:14] ulm: my reponse/input: http://dev.gentoo.org/~grobian/altEAPImechs.txt so, of methods A-F, i'd be ok with A, B, or E. [21:15] A or F for me F A C [21:16] I'd much prefer B, but A would be o.k. too As long as we do not attempt D, which has been voted out in the past... And with the understanding that F is the preferred option... [21:17] i suppose F too, but i'd rather see some forward motion even if the chosen solution has some cons. Most of the others look good. <_AxS_> for clarification -- F is do nothing and ensure that portage depends on an appropriate bash for EAPI=0 ? *** thrice` (thrice@unaffiliated/thrice/x-000000001) has left channel #gentoo-council: #gentoo-council right, F is to do nothing F is basically say this problem isn't important because we haven't needed it for the past 5 years. … or we silently broke PMS' restriction of bash version because we didn't care enough [21:18] Chainsaw: any preferences? ulm: F please! Betelgeuse? [21:19] ulm: D A B C E [21:20] lol F as in fail Anyone know what the status of xattrs is? If it's in any way feasible. [21:21] yeah, won't work everywhere ha. that's an idea i was talking about years ago. we'd hate to stop supporting gentoo on aix though. =P *** johu (~johu@gentoo/developer/johu) has quit: Quit: No Ping reply in 180 seconds. so, there seems to be preference for options A and F *** johu (~johu@gentoo/developer/johu) has joined channel #gentoo-council [21:22] B also seemed fairly popular any reason people dislike C? dberkholz: it could come in an external file for people without xattr support grobian: it's summarised on the wiki page already so they pay a small performance penalty ulm: yeah, but see my link metadata influences Portage's "ugly die behaviour": users won't see it [21:23] Betelgeuse: yep, that had occurred to me. it is a fun idea, isn't it? so, how should we proceed? I could live with A. B assign meaning to comments without a shebang. [21:24] And that seems very, very wrong to me. I could work out a more detailed proposal for option A for the next meeting But, if I could have F, that would be even better. it seems everyone understand the proposals so I think we are safe to vote? the only concensus at the moment is F? seems like most of us have more than one items of preference [21:25] A is slightly preferred I prefer to put the portage team in the loop for their input on some candidates for the best match (performance, ease of implementation) A seems to be the only one everybody is OK with say those that would get a council majority vote so basically A [21:26] assuming i got this right: http://pastebin.com/35HS216n grobian: I believe zmedico prefers A dberkholz: That's helpful, thanks. A looks like a winner then. <_AxS_> ulm: by vote (ranking in order), A is the winner with 22, followed by F with 16. [21:27] betelgeuse also was ok with F _AxS_: yes, I've put it into a Condorcet/Schulze calculator too ;) So let's move forward. Proposal A, yes/no? <_AxS_> ulm: ah. (i didn't know there was a name for that, i just wrote it out) A, then F, then B * Chainsaw votes yes [21:28] Chainsaw: that's A against F? ulm: We can only do yes/no votes last I checked. o.k., let's vote yes/no on A yes from me * Chainsaw votes yes (again) [21:29] A: yes Chainsaw: Well we just need to reach a majority in some fashion yes Betelgeuse: your vote? So are we voting on the exact specifics now or just the approach? are we just re-doing everything we just did? Betelgeuse: Option A. Yes/no? [21:30] i would've sworn we just finished saying all the ones we'd be fine with, and now we seem to be doing it again one at a time dberkholz: Yes, it is most tedious. Betelgeuse: exact specifics will follow, but as outlined on the wiki page as of today <_AxS_> i think this vote is for official concensus on A _AxS_: Yes. * grobian nods ok, i'm yes on A/B/F, and ping me in 20 minutes when the rest of you are ready =P Chainsaw: neutral [21:31] Betelgeuse: There is no abstaining from a yes or no vote. I count 5 yes and one abstention ulm: Not unanimous but sufficient? ok, so we're on schedule now grobian: Yes, that agenda is bang on. [21:32] that's sufficient I guess yes it is so I hope we'll have the exact specifics (PMS patch) ready for the next meeting Chainsaw: I guess depending on how you look at it could be counted as no. Chainsaw: But I don't think you must say anything. [21:33] ulm: make it an action point grobian: k next topic New udev and separate /usr partition Chainsaw: Do you want to comment on this? Indeed. In my opinion, a separate /usr partition has been a supported configuration for a very long time and should remain so. You will have seen a statement by Jaco Kroon, who admins an order of magnitude more Gentoo servers than me. [21:34] We are both in the same predicament, in that we have LVM2 systems with /usr separate, as per the official guide. I do not feel that the new udev should be allowed to have stable keywords unless it is capable of handling a separate /usr in a graceful fashion. Chainsaw: So to clarify a universal initramfs is not enough? [21:35] For the avoidance of doubt, I do not contest the unmasking, nor the ~amd64 keyword on it. <_AxS_> ... point of order on the agenda, regarding the conclusion about what would occur if /usr will remain supported .... udev can go stable if a means of supporting /usr-on-separate partition (via initramfs or other) is a possibility, no? Chainsaw: separate /usr, as in separate /usr without an initramfs? Betelgeuse: No. That is additional work for a clearly broken package. here's the thing who's going to either "port" udev as necessary, or maintain an old version forever? [21:36] we can't proclaim things like this from on high without a route forward I will keep an old version going until the end of time. if udev is moving that way, we can't stay 'old' forever what happens when kernel 3.6 no longer supports it? Then dev(tmp)fs will win. or static /dev as in the old times ;) [21:37] As a point of interest, does anyone know exactly what changed in udev to stop /usr from working? given that udev is going to be merged to systemd, this discussion may render moot i was just about to mention that. dleverton_: IIUC it depends on programs in /usr now [21:38] Unconditionally? I never thought I'd speak out in favour of openrc... But I will use openrc over systemd any day. <_AxS_> ...there's a fair bit of talk on this issue, and from more than just gentoo. If gentoo took the stance of definitely not sticking with upstream (and probably forking udev), i think that there would be support for this. dleverton_: /usr/bin/udevadm And to confirm, if that means "Chainsaw maintains udev in Gentoo" and "point at Chainsaw if you disagree", I can live with that. [21:39] OK Chainsaw: that makes a change, and probably you can find people that support you grobian: I have jkroon on my team. We can handle Asterisk. [21:40] grobian: I am sure we can handle udev too. Chainsaw++ [21:41] what do udev maintainers think about this? Chainsaw: I mean, it's hard to say something must remain supported if there is no people doing that, so if you back it, I'm happy to support you grobian: I will do what it takes, on company time. [21:42] grobian: Expect an Asterisk-style patchset on top of what upstream does to tame it into reasonable behaviour. Yes, separate /usr should remain supported so, should we have a vote on it in this meeting? [21:43] ^^^ my vote ulm: I think we should. or postpone it? postpone it for what? ulm: Because if we postpone it, there is time for udev to be stabled under "it's been 30 days!" conditions. <_AxS_> the discussion we just have about udev is somewhat aside from the issue. It would be pertinent, i think to vote on continuing to support separate /usr or not o.k., then please vote yes/no yeah we should at least delay udev going stable could either flesh out building the "separate /usr" team, or vote now assuming it will happen As long as there is no automated help for people to automatically get initramfs I vote yes [21:44] Separate /usr is a supported configuration. I vote yes. umm i vote no, because diverting from upstream is not an ideal option for me [21:45] i'm fine with supporting that in the sense that older udevs could be maintained forever but i'm not ok with never stabling new versions That isn't the question though dberkholz. this is not about stabling packages The question is whether separate /usr is a supported configuration. The question is: "Decide on whether a separate /usr is still a supported configuration." If it is, then stabling udev and "the hell with you LVM2 weirdos" is no longer an option. [21:46] as in the agenda and my vote is conditional on this not blocking stabilization of new udev as long as the other configuration is somehow supported dberkholz: Whilst you can't have it both ways... you could make a profile [21:47] dberkholz: My plan is to patch reasonable behaviour back into udev, and going with the upstream releases as long as it is feasible. sure i can. maintain old udev-XXX forever, put an elog in new udev that says "if you want separate /usr without initramfs, block old udev or whatever err, install old udev, mask new do it's masked/unmasked there dberkholz: That is the python 3 disaster all over again. *NO* well, i want new crap, and i don't want to wait around for custom gentoo ports all day. that is why we do vanilla. fork udev into a different package name then [21:48] dberkholz: Then put it back under package.mask and go nuts. yeah, use a virtual we already have a device-manager virtual problem solved :) dev-manager anyway, including another yes from me, I count 4 yes and 1 no [21:49] so this seems to be able to be solved, apart from the question whether or not separate /usr is supported which is a majority <_AxS_> there are ways to provide support for /usr with a newer udev; again, the stabilization of udev (in the long term) should not really be an issue with this vote, should it? _AxS_: It does not block newer udev from being stabled in the long term. _AxS_: It just blocks stabling with a some armwaving about initramfs generators over in the corner there. [21:50] (Which is going to happen. Sorry for my lack of trust in people, but it will) <_AxS_> *nod*. right. ok, well ulm closed voting so i'll go back to my corner. _AxS_: we should make sure that there's reasonable documentation about setting up an initramfs though <_AxS_> ulm: oh yes -- i was figuring the solution on how to support separate /usr with new udev would be tabled at the mext meeting (if necessary) ok, next? [21:51] dberkholz: should I count you as an abstention for the last vote? _AxS_: I would recommend raising the implementation details for next meeting, yes. ulm: nah, i'm for it. [21:52] the implementation details are my concern, but that's not the vote. o.k., that's 5 yes 1 no then has anyone further comments on this topic? dberkholz: My immediate concern is the prevention of stabling by stealth, which is now done. We can agree further work offline. [21:53] As in, outside of this meeting. Let's move on. next topic herds.xml and mail aliases answer: no [21:54] no I think that has been more or less answered on the ml already if this is even a question, that means it should be automated. no from me, too No. no (It's a laudable goal, but it will not work this way.) [21:55] so obviously no majority, at least not for the way it has been proposed [21:56] I guess we can move on Open bugs with council involvement bug 383467 [21:57] ulm: https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto jmbsvicetto isn't present, so I guess we won't get an answer on this one answer is probably: ETOOBUSY :) anyone has comments about this bug? seems not to be the case [21:58] bug 408073 ulm: https://bugs.gentoo.org/408073 "Make the user choose a locale"; Documentation, Installation Handbook; CONF; betelgeuse:docs-team sounds like we need to heckle cam. ulm, wanna ping on the bug? [21:59] can do Okay, so when we will we meet again? Betelgeuse: can we please have the logs + summary from the last meeting? It's been a month and it does not look good [22:00] well, we finally did something interesting this time, so it's worth posting the logs more speedily =) Chainsaw: May 8th? may 8 is more or less fine for me, with the caveat that my next baby's due date is may 7. [22:01] hwoarang: yeah I will do it when this meeting wraps up. May 8 works well for me, yes please. thanks a lot hwoarang: sorry about it and thanks for reminding me ulm: May 8th ok who's chair for next month? jmbsvicetto: I don't mind doing it for him [22:02] k I suspect he'll be busy still grobian: you probably want to get in touch with him grobian: let him comment by e-mail in case he wont make it, lets be prepared yup I'll be just his stand in send him an email and such tahnks [22:03] so, open floor The mics are on guys & gals. Share your thoughts. deafening silence [22:04] <_AxS_> ... not much to say, all the big stuff was covered already [22:05] then let's close the meeting thanks to all of you, it was very efficient this time *big hammer* *BANG* Very civilised as well. thanks for chairing ulm [22:06] Even got the results I wanted. Thank you all. thx *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: May 8th, 19:00 UTC | Meeting chairs: http://www.gentoo.org/proj/en/council/#doc_chap5 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/" [22:07]