20:01 -!- dev-zero changed the topic of #gentoo-council to: Meeting started || Meeting agenda here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090514.txt 20:01 <@dev-zero> roll-call please? 20:01 <@leio> here 20:01 <@lu_zero> here 20:02 < ulm> here (proxying dertobi123) 20:02 < ssuominen> here (proxying dberkholz) 20:03 <@dev-zero> Cardoe: ping? 20:03 <@dev-zero> tanderson: ping? 20:03 <@dev-zero> zmedico: ping? 20:04 <@dev-zero> well, then let's start with the first topic and hope the others get here as soon as possible 20:04 <@dev-zero> zmedico promised an updated on the progress of the implementation 20:05 <@dev-zero> anyone knows something about it? 20:05 -!- darkside_ [n=darkside@gentoo/developer/darkside] has joined #gentoo-council 20:06 <@Betelgeuse> I can take a look at svn log to see if there's anything 20:06 <@dev-zero> Betelgeuse: yes, please :) 20:08 <@Betelgeuse> I don't immediately see anything 20:09 <@dev-zero> good, ok, state didn't change then, two smaller features are implemented then 20:09 <@dev-zero> Betelgeuse: thanks 20:09 <@Betelgeuse> Add dummy dosed and dohard functions for EAPI 3, so that a trace can be 20:09 <@Betelgeuse> something but not much 20:09 <@dev-zero> and 'dodoc -r' 20:09 <@dev-zero> which was also one of the easiest features 20:10 <@dev-zero> I'd say let's move to the next task if nobody objects 20:10 <@dev-zero> EAPI 3: PMS approval 20:10 <@dev-zero> the idea is to approve the wording of the EAPI 3 part of the PMS formally 20:11 <@lu_zero> I'd like to have a clean diff 20:11 <@Betelgeuse> What's the need before Portage is even half way there? 20:11 < ssuominen> Did EAPI 3 contain a suitable replacement for "prepalldocs" and "ecompress" which are both used in tree now, and for a reasons that can't be worken out 20:11 <@lu_zero> ciaranm there is a tag to use or I should dig the log? 20:11 <@dev-zero> ssuominen: yes, docompress 20:11 < ciaranm> lu_zero: just diff the heads on the official version and the eapi 3 branch 20:11 <@leio> I don't feel comfortable with giving things an official stamp when there is no implementation in the official package manager. However I do want to signal that the feature list is final when while doing the official implementation nothing appears to need changes, and I believe I did that with my vote about EAPI-3 last time 20:12 <@lu_zero> ciaranm ok 20:12 < ciaranm> leio: we want approval on the wording now, not the feature list 20:12 <@leio> I see no reason to need such an approval now 20:12 <@dev-zero> Betelgeuse: well, the most complicated features to implement are probably the slot-operators and the use-specifiers 20:13 < ciaranm> lu_zero: you could've asked me two weeks ago when the item was first sent out... 20:13 < ssuominen> dev-zero: but say one does, mansuffix="$(ecompress --suffix)" and then dosym /usr/share/man/man1/foo.1${mansuffix} usr/share/man/man1/bar.1${mansuffix} 20:13 < ssuominen> dev-zero: how would docompress work on such case? 20:13 <@dev-zero> Betelgeuse: the rest is basically bash stuff which could be done by everyone 20:13 < ciaranm> ssuominen: ecompress isn't in any EAPI 20:14 < ulm> ssuominen: docompress has no substitute for that 20:14 < ssuominen> i'm fine with the eapi3 as is, but this is the part that's been buggering me.. 20:14 <@leio> ulm: can you comment on that approval need as a PMS representative of gentoo? 20:14 < ssuominen> no way to symlink manpages in src_inst.. 20:14 < ciaranm> in any case, the wording's not changed for two weeks, and you've had two weeks asking to send any questions... 20:14 < ciaranm> ssuominen: uh, yes there is 20:15 < ciaranm> ssuominen: pms is quite clear about that 20:15 < ulm> leio: seems to me that the eapi 3 features were already approved at last meeting? 20:15 < dleverton> ssuominen: IIRC the portage compression handles symlinks transparently already, so if you symlink to foo.1, it'll rewrite it to foo.1.bz2 or whatever. 20:15 <@leio> ulm: what kind of approval is ciaranm wanting here that is necessary? 20:16 <@dev-zero> lu_zero: about the diff, you can use the app-doc/pms ebuild with USE=eapi3-draft which colors the differences 20:16 <@lu_zero> dev-zero thank you 20:16 < ssuominen> dleverton: oh.. lemme try that, but this would only work in src_, not in pkg_postinst? there's the legacy update-alternatives.eclass 20:16 < ulm> leio: from my point of view we could postpone that until after an implementation is ready 20:17 < ssuominen> dleverton: e.g. xloadimage is using the symlinking in postinst, that's after the install func has processed the compression 20:17 < dleverton> ssuominen: yeah, only src_install as far as I know. Is that eclass still used? 20:17 < ciaranm> ulm: thanks for consulting with the rest of the pms team about that back when we first asked for approval 20:17 < ssuominen> dleverton: see xli or xloadimage's ~ ebuilds for example 20:17 < dleverton> Hmm 20:18 < dleverton> You could probably check the contents of ${D} in pkg_preinst 20:18 <@leio> no reason has been provided why an approval of the final text is necessary 20:18 < ssuominen> dleverton: i'm not saying i want to keep it around, i'm entirely fine with the concensus "if ecompress is no longer allowed, we need to kill update-alternatives.eclass" 20:18 <@leio> so actually having portage implementations first makes sense 20:18 < ciaranm> leio: so we can go ahead and implement it without having to worry that the wording will be changed 20:18 < ulm> ciaranm: imho the text is good for approval, but why the haste? 20:19 < ciaranm> ulm: because without approval, we can't get implementations ready 20:19 <@leio> ciaranm: who is worrying about that? 20:19 -!- igli [n=igli@fu/coder/igli] has joined #gentoo-council 20:19 <@dev-zero> ulm: we have to approve it at some point 20:19 < ciaranm> leio: everyone who wants to implement it without having to worry that someone will come along and change, say, the src_install wording 20:20 <@leio> the features are already approved 20:20 < ciaranm> the features, not the details 20:20 <@lu_zero> ciaranm I'd rather have incremental drafts of both 20:20 < ciaranm> what we have is approval of the features, in general. what we need now is approval of the wording of the details, subject to the usual "we fix it if it goes wrong" 20:21 <@dev-zero> ciaranm: thanks :) 20:21 < ciaranm> the council has said "there will be a default src_install". it has not approved what that is, so anyone writing implementations or test cases is wasting their time. 20:21 < ssuominen> docompress should have "exclude" flags as dohtml has.. 20:21 <@leio> I wasn't aware that we didn't consider all the details while voting last time 20:21 < ssuominen> (it might already have?) 20:21 < ulm> ssuominen: what do you mean by exclude flags 20:21 <@dev-zero> leio: we discussed the stuff which people didn't agree up on 20:21 -!- yngwin [n=yngwin@gentoo/developer/yngwin] has joined #gentoo-council 20:21 < ulm> ssuominen: there's docompress -x 20:22 < ciaranm> ssuominen: thanks for doing your homework and reading the pms draft and raising your questions before the meeting 20:22 <@dev-zero> leio: so I think we were clear about the features 20:22 <@dev-zero> leio: and we surely don't have the time to nitpick about every single detail, that's the reason why stuff got posted on the ml 20:22 < ssuominen> ulm: lets's say econf --docdir=/usr/share/doc/${PF} installs the docs into the directory, but one of them is a .pdf file used directly runtime from the program, or a manual.txt that's invoked from the application 20:22 <@leio> ssuominen seems to mean file exclusion as opposed to directory exclusion 20:23 < ciaranm> ssuominen: what part of the things that are in pms to handle that case are no good for you? 20:23 < ulm> ssuominen: then you can call docompress -x .../manual.txt 20:24 < igli> what's wrong with: emake install prefix=/usr sysconfdir=/etc docdir=/usr/share/doc mandir=/usr/share/man # or the equiv (specced by someone who knows autotools a bit better than I do obviously;) 20:24 < ssuominen> ciaranm, ulm: awesome. missed that part, i've had only few hours to get myself familiar with it. sorry. 20:24 < ssuominen> that works for me. 20:25 -!- tomaw [i=tom@freenode/staff/tomaw] has quit ["Quit"] 20:25 <@dev-zero> ok, are there any objections to the wording of certain parts? 20:25 <@leio> src_install was quite much nitpicked and details hammered down. Even dodoc already doing an empty file check and src_install doing it too was brought up (and concluded the extra doesn't hurt in case dodoc changes in some way or something). Anyway, I have already voted on the features in detail, so you can just take my last vote if wanting it like that again 20:25 -!- tomaw [i=tom@freenode/staff/tomaw] has joined #gentoo-council 20:26 <@leio> so, no objections, unless something has been changed in the wordings of the features that were voted in, as I did not know to review all the text in detail of the latest branch version 20:26 <@dev-zero> leio: on the ml, yes 20:27 <@leio> src_install was discussed in the meeting, I'm quite sure, but whatever :) 20:27 < ciaranm> i didn't ever get a definitive answer to a whole bunch of wording questions, so i arbitrarily picked things. i assume that anyone who has a problem with any of those choices would have raised their queries in the past two weeks. 20:27 < igli> assumptions: mother of all fsck-ups. 20:28 <@dev-zero> good 20:28 < ciaranm> so really, approving a merge of the eapi 3 branch to the gentoo-hosted master shouldn't be a big deal, should it? 20:28 <@Betelgeuse> ciaranm: If that's what you need approval I have no problem with that 20:29 <@lu_zero> same here 20:29 <@leio> I must have missed some e-mails then, and my -dev folder is with an unusually small unread count 20:29 <@Betelgeuse> ciaranm: The council approved tagging should imho wait until Portage gets up to speed 20:29 < ulm> ok with me too 20:29 <@dev-zero> so, do we need to vote or can we say that all people here agree that the wording of eapi-3 as it has been presented is ok? 20:29 <@leio> I approve merging to master without tagging 20:29 * lu_zero seconds leio 20:29 <@Betelgeuse> There's four so it passes 20:29 < ciaranm> tagging's the sign for "stick stuff in the tree using it", which we probably shouldn't do just yet... 20:29 < ciaranm> ok, merged. ta. 20:30 * ulm seconds it too 20:30 <@dev-zero> fine 20:30 <@dev-zero> next topic then 20:30 <@dev-zero> GLEP 54 20:30 < solar> again? 20:30 <@dev-zero> jup 20:30 < solar> kill it. Nobody wants it 20:31 <@dev-zero> solar: are you proxying someone? 20:31 <@Betelgeuse> solar: please contribute something useful or shut up 20:31 < solar> I'm a dev. I think I have a right to speak 20:31 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has quit [Read error: 110 (Connection timed out)] 20:31 <@Betelgeuse> Indeed. We don't have to listen though. 20:31 <@lu_zero> solar I think somebody could disagree with you 20:31 < igli> it's much better done as a prefix 20:31 < ssuominen> If live ebuilds would be marken with something special, like suffix or a PROPERTIES="" in the ebuilds it would be easier to package manager to identify them 20:32 < igli> or indeed a property yeah 20:32 <@Betelgeuse> Wasn't PROPERTIES="live" already approved? 20:32 < ciaranm> PROPERTIES=live is unrelated to version ordering 20:32 <@Betelgeuse> ciaranm: sure just said to ssuominen 20:32 < igli> is -scm a binary indicator or not? 20:32 < igli> leaving aside repo 20:33 < ciaranm> -scm's an ordering thing 20:33 <@dev-zero> lu_zero: you once said you'd update your counter glep, is there anything new there? 20:33 < igli> i know its implications, but in data terms it's a binary value 20:33 <@lu_zero> dev-zero in the devspace there is the updated one 20:33 <@dev-zero> lu_zero: what has been changed since last time we discussed it? 20:34 <@leio> was there really nothing in GLEP54 to updated after all the discussions? If the discussions explain things in more detail, those things ought to get into the GLEP text as well 20:34 < igli> LIVE="foo" # (or SOME_LONG_VAR_THAT_MEANS_LIVE) if you want more flexibility 20:34 < ssuominen> As for GLEP 54's part "Motivation", if there is/will be PROPERTIES for them it pretty much covers the motivation already 20:34 < ssuominen> Can't just see any other benefits 20:35 < ciaranm> the other benefit is ordering 20:35 <@lu_zero> dev-zero I think it is more or less the same 20:35 <@dev-zero> lu_zero: ok, thanks 20:35 < igli> which the pkg-mangler knows about when considering the ordering in resolution, one would hope. 20:35 <@lu_zero> the glep54 didn't see any update since the inception I guess 20:35 <@dev-zero> lu_zero: that's correct 20:35 <@Betelgeuse> ssuominen: You can more easily make scm version for branches etc 20:36 <@lu_zero> Betelgeuse not branches 20:36 <@lu_zero> one kind of version branches 20:36 < ciaranm> topic branches aren't versions and shouldn't be treated as such 20:36 < ulm> lu_zero: your counterproposal is the one in http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst ? 20:36 <@lu_zero> ciaranm target branches are version branches... 20:36 <@lu_zero> ulm yup 20:36 < igli> if it has to be in filename, that can be done with prefix as well. but I remain unconvinced it needs to be exposed in the filename 20:36 < ciaranm> lu_zero: scm works for target branches 20:37 <@leio> I'd hope to see a complete proposal that actually solves more things. The ordering works fine even with 9999, so right now all that -scm is is pretty much giving a name to that ugly 9999 construct and not solving anything else 20:37 < ciaranm> lu_zero's counterproposal is unimplementable, in any case. -scm has a reference implementation in paludis. 20:37 <@lu_zero> ciaranm unimplementable as in you cannot make it? 20:37 <@dev-zero> lu_zero, ciaranm: stop that right now 20:37 < ciaranm> lu_zero: no, unimplementable as in it's impossible to implement 20:37 < igli> oh it's in paludis, it has to go in. I forgot. 20:37 < bonsaikitten> igli: silence! 20:38 * igli stfu 20:38 <@dev-zero> lu_zero: does it still stand that your proposal could be implemented on top of G54? (since it's described as an expansion) 20:38 < igli> what if it's cleaner implemented another way tho? 20:39 <@lu_zero> dev-zero it diverged enough 20:39 < scarabeus> i like lu_zeros glep more, and it would be greatly utilized by mesa/drm for example (take look on live ebuilds in overlay how i allow the branching now) 20:39 < ssuominen> Betelgeuse: You mean grabbing the branch from the version into ebuild, instead of defining the branch in a variable inside the ebuild? 20:39 <@dev-zero> I guess we have to vote about G54 to get it off the table, is that correct? 20:39 <@lu_zero> it aims to solve glep54 pointed issue and some more that cropped up 20:40 <@Betelgeuse> ssuominen: I mean if you want both 2.2 official release and then a live ebuild for 2.2 branch 20:40 < ciaranm> with lu_zero's glep you can't set use flags just for live packages using package.use without breaking emerge -N. how can people like that? 20:40 <@leio> I like many of the things lu_zero's glep would allow to do, and would like to see that explored more 20:41 <@Betelgeuse> I don't want 54 in without 55 so I would rather do that first. 20:41 < ssuominen> Betelgeuse: 2.2 < 2.2-scm 20:41 <@Betelgeuse> ssuominen: yes 20:42 < igli> I'm sure portage team can fix emerge, if the need arises. but that proposal still does it as yaf suffix when that space is already quite crowded with patch data. 20:42 < ssuominen> Betelgeuse: 2.2 < 2.2.9999.. but I don't mind, if we change to more pretty and constant -scm. 20:42 < igli> better to shove it in same place as debian put their epochs imo. 20:42 < ssuominen> So I'm for the glep. 20:42 <@dev-zero> lu_zero: do you think you could provide a reference implementation of your proposal? 20:43 <@lu_zero> dev-zero no 20:43 <@lu_zero> first I wanted to see if there were enough interest 20:43 <@dev-zero> lu_zero: there is surely interest, otherwise G54 would have voted in a long time ago 20:43 <@Betelgeuse> dev-zero: We have never really voted in it 20:43 <@Betelgeuse> dev-zero: Just post poned it 20:43 <@lu_zero> dev-zero see solar reply before 20:44 <@Betelgeuse> At least as far as I remember 20:44 <@dev-zero> Betelgeuse: that's true, but we postponed it since we thought other solutions would show up, better explanations given, etc. 20:44 <@lu_zero> and it got postponed since the glep wasn't detailed enough 20:44 <@Betelgeuse> dev-zero: No. Mainly because it's controversial so it's easier to push later based on those arguments. 20:45 < ciaranm> last time it got postponed was because lu_zero said he had an alternative 20:45 <@dev-zero> Betelgeuse: also true 20:45 <@dev-zero> well, then I think we should put it to a vote to get it off the table at last 20:45 <@lu_zero> and seems people like the possibility to have both _plive and _prelive ... 20:45 <@Betelgeuse> I propose the following. This is stuff that belongs to PMS. If GLEP 55 is approved, this can be put to list for EAPI 4. 20:45 <@leio> I do not see any relevance to EAPI's here 20:46 <@dev-zero> Betelgeuse: the relevance to EAPIs may be true 20:46 < ssuominen> What about _r as in revision to reuse it in the ebuild 20:46 <@dev-zero> Betelgeuse: but not the one to G55 20:46 <@Betelgeuse> dev-zero: You can't do 54 without breakage unless you do 55 too 20:46 <@dev-zero> Betelgeuse: if G55 gets accepted the people can start using it faster 20:46 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Read error: 110 (Connection timed out)] 20:46 < ssuominen> _r should be > _p 20:46 <@dev-zero> Betelgeuse: otherwise they have to wait at least 6 months 20:46 <@leio> Betelgeuse: you can 20:46 <@Betelgeuse> I hate the wait way when we have a better way these days. 20:47 <@leio> why would it have to wait 6 months? 20:47 <@dev-zero> Betelgeuse: that's true and can be prevented 20:47 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 104 (Connection reset by peer)] 20:47 -!- reavertm [n=reavertm@ary193.neoplus.adsl.tpnet.pl] has joined #gentoo-council 20:47 <@dev-zero> leio: because of portage moaning about unknown version tags 20:47 <@Betelgeuse> Can we just vote on the following: Approve GLEP 54 on the condition that 55 is approved and move it to PMS instead for next EAPI instead of being a separate GLEP. 20:47 <@leio> because it has a reason to moan 20:47 <@Betelgeuse> I want to see this stuff being centralised. 20:48 <@Betelgeuse> I obviosly vote yes. 20:48 <@leio> the user hasn't bothered to upgrade portage despite strong suggestions in the form of messages after syncing AND the moaning about invalid version tags 20:48 < ciaranm> there's already wording for scm stuff in pms if you enable the kdebuild bits, if anyone's worried about whether it'll fit in that way 20:48 < ciaranm> so what Betelgeuse makes sense from a pms perspective 20:48 < bonsaikitten> le sigh! 20:49 <@dev-zero> Betelgeuse: and what happens if G55 is not approved? 20:49 <@leio> the warnings I see as a good thing. Developers also will notice it and not regenerate manifests with a portage that doesn't know this versioning 20:49 <@Betelgeuse> Please vote so we can see where you stand. 20:49 < solar> vote of no confidence? 20:49 <@Betelgeuse> solar: not on the agenda 20:49 <+tanderson> wait, I thought the meeting was at 5:00 EST? 20:49 <@Betelgeuse> tanderson: 20UTC like always 20:50 <@dev-zero> I vote yes, in case G55 is accepted do it like Betelgeuse said, in case G55 is not accepted keep it as GLEP and implement it 20:50 <@Betelgeuse> dev-zero: A new vote on what do to instead. 20:50 <+tanderson> Betelgeuse: oops, sorry 20:50 <@lu_zero> I'd like to know how many would like to have the live templates implemented 20:50 <@leio> I do not see how we can vote on it like that, it seems weird 20:50 <@leio> lu_zero: I would like to see an implementation and further investigation of this 20:51 <@Betelgeuse> leio: If my proposal is approved then we can just move on. If not then we need to talk what else. 20:51 < ulm> i vote yes (as specifically instructed by dertobi123, not my personal opinion though) 20:51 <@dev-zero> I vote yes 20:51 <@lu_zero> I vote no 20:51 <@leio> ok, so what are we voting here? 20:51 <@Betelgeuse> 20:47 <@Betelgeuse> Can we just vote on the following: Approve GLEP 54 on the condition that 55 is approved and move it to PMS instead for next EAPI instead of being a separate GLEP. 20:52 < solar> thanks lu_zero 20:52 <@Betelgeuse> ssuominen: your vote please 20:52 <@leio> I vote no. It is a) not fleshed out, no updates at all after discussions, I can not vote with an approval on this; b) it is not an EAPI or PMS thing 20:53 < ciaranm> of course it's an EAPI / PMS thing 20:53 <@Betelgeuse> indeed 20:53 < igli> it's just a pig, is all. 20:53 < ssuominen> sec 20:53 <@leio> sorry, I meant just EAPI. 20:53 <@Betelgeuse> leio: the versioning rules are EAPI 0 20:53 <@Betelgeuse> leio: This is an extension to those 20:53 < ssuominen> vote is yes 20:54 <@Betelgeuse> Ok vote passed. 20:54 <@leio> So we are going to modify EAPI 0? 20:54 <@Betelgeuse> leio: no 20:54 <@Betelgeuse> leio: My proposal puts it to next EAPI and it passed 20:54 < ssuominen> yes, with the condition Betelgeuse said 20:54 <@leio> how can that work, versioning rules are across the board. Would all revisions of a package have to be upgraded to that new EAPI first? 20:54 < ulm> Betelgeuse: how can version ordering be part of an eapi? 20:55 < ciaranm> ulm: quite easily 20:55 <@lu_zero> leio the vote was about having 54 approved if 55 passes 20:55 < ulm> but you may compare ebuild with different eapis 20:55 < igli> just like it can be non-bash (yay) 20:55 <@Betelgeuse> ulm: You don't want PMs to handle it the same way 20:55 <@Betelgeuse> ? 20:55 < ciaranm> you define version comparisons in terms of a super-version-format of which every other eapi is a subset 20:55 -!- darkside_ [n=darkside@gentoo/developer/darkside] has left #gentoo-council [] 20:56 < igli> even the eapi's you don't know about which can't cope with EAPI='foo' 20:56 <@Betelgeuse> igli: If you don't know about EAPI 4 you don't see scm ebuilds at all 20:56 < igli> scheme? 20:56 < igli> I love scheme 20:56 < igli> i think you mean VCS 20:56 < ciaranm> sorry, gentoo standardised on 'scm' by order of seemant about five years ago 20:57 < ssuominen> can we move on? 20:57 <@dev-zero> jup 20:57 <@Betelgeuse> I have exams tomorrow morning so I would rather stop at this one hour mark because I need study. 20:57 < ulm> igli: the scheme team has already announced that there will be a dev-scheme/scm-scm if glep 54 is approved :p 20:57 < igli> sure; diktat from on-high seems order of the day. 20:57 -!- igli [n=igli@fu/coder/igli] has left #gentoo-council ["Have a good one ;-)"] 20:57 < solar> yeah enough fucking up for one day 20:57 <@dev-zero> Betelgeuse: do you think we could stretch it for the next item? 20:57 <@Betelgeuse> I expect a lengthy discussion coming unless we just vote. 20:57 <@dev-zero> Betelgeuse: then let's do just that 20:58 < bonsaikitten> what the ... why are we discussing eapi4 and later when eapi3 isn't even out 20:58 <@dev-zero> because the discussion could be going on forever 20:58 <@dev-zero> bonsaikitten: please, you can flame away in 5-10 minutes 20:58 <@dev-zero> ok, next topic and the last one for today: GLEP 55 20:58 <@Betelgeuse> For GLEP 55 I propose: Approve it and I will start a project to redesign the tree where it will be moved back inside .ebuild 20:58 <@Betelgeuse> There's plenty of stuff we want to solve with a redesign 20:59 < ulm> dev-zero: tobias wanted to see the benchmarks (promised long time ago) for glep 55 20:59 <@Betelgeuse> can't promise anyhting delivered any time soon 20:59 <@dev-zero> ulm: I know, he told me, I don't think there are any (at least not published) 20:59 <@leio> There is no need for GLEP55 20:59 <@Betelgeuse> But in the time it takes for the extensions to blow out of proportion we should have something 20:59 <@leio> It doesn't solve anything 20:59 < ciaranm> glep 55 is needed to get the recently approved glep 54 usable in EAPI 4 timeframes 20:59 <@Betelgeuse> leio: Then we will never have the need to use a new extension 20:59 <@lu_zero> ciaranm glep 54 isn't approved 20:59 <@lu_zero> it has been linked to glep 55 20:59 < NeddySeagoon> Betelgeuse, so why approve G55 then - just fix stuff properly ? 21:00 < ulm> ciaranm: glep 54 was only conditionally approved 21:00 <@leio> Betelgeuse: we don't have that need now either. 21:00 < jmbsvicetto> ciaranm: That argument doesn't hold - GLEP54 was approved *pending* GLEP55 being approved 21:00 <@Betelgeuse> NeddySeagoon: http://rafb.net/p/09PDiO25.html 21:00 < jmbsvicetto> ciaranm: So you can't say GLEP55 need to be approved because GLEP54 was approved 21:00 <@Betelgeuse> NeddySeagoon: It just seemed easier to just rethink 21:00 <@Betelgeuse> NeddySeagoon: Easier to avoid breakage 21:00 < bonsaikitten> sigh. why don't you stop for a minute and decide where you want to go before starting to run ... 21:01 < NeddySeagoon> Betelgeuse, that does not answer my question ... how is that related to G55 ? 21:01 <@leio> Instead of GLEP55 we simply need to say EAPI= comes as the first non-comment within a certain set of lines. Done. G55 serves no purpose 21:01 <@Betelgeuse> NeddySeagoon: Some people don't want to see us having ten different EAPI file extensions in use 21:01 <@Betelgeuse> NeddySeagoon: My proposal would mean we would not use GLEP 55 for more than a couple 21:01 <@leio> and when the next step plan is to have *.ebuild again, what's the point of changing that then 21:01 <@Betelgeuse> NeddySeagoon: if any 21:01 < jmbsvicetto> Betelgeuse: I don't see how most (any?) of those is related to GLEP55 21:01 <@Betelgeuse> jmbsvicetto: Please ready what I said 21:01 < NeddySeagoon> Betelgeuse, Yep. me too - its bad system design. So kill G55 21:02 <@Betelgeuse> s/ready/read/ 21:02 <@dev-zero> ok, council members, please state your votes 21:02 < NeddySeagoon> Betelgeuse, there is nothing so permanent as a temprory fix 21:02 <@dev-zero> otherwise it will never end, sorry 21:02 < jmbsvicetto> Betelgeuse: So you want it for a "transition" phase? 21:02 <@Betelgeuse> I vote yes (with the final extension format to be decided later) 21:02 <@leio> We are not in a hurry 21:02 <@dev-zero> I vote yes 21:03 <@Betelgeuse> .eb vs .ebuild- I think 21:03 < ssuominen> Don't see any harm in it, so I vote yes as well. 21:03 <@leio> why are we bringing this up again within one meeting timeframe and try to get votes out of council members who need to review it more. Have you all even been able to read the last e-mail about it, especially bonsaikitten ones? 21:03 <@Betelgeuse> GLEP 55 will never be utilised without a new EAPI any way 21:03 <@Betelgeuse> which we need to vote on 21:03 < NeddySeagoon> Betelgeuse no hurry for G55 at all then 21:04 <@Betelgeuse> leio: Finally voting it even if controversial will allow people to put their energy to something more useful 21:04 <@Betelgeuse> Which is a good reason for voting in itself 21:04 <@lu_zero> I vote no 21:04 < ulm> i vote no 21:04 <@leio> Betelgeuse: and we end up with something bad voted in because people were uninformed. Sounds very useful 21:04 < NeddySeagoon> Betelgeuse, This vote looks like UK MPs voting their expenses 21:04 <@Betelgeuse> leio: Some of us don't htink it's bad. 21:04 < ciaranm> don't worry, there's nothing informative in bonsaikitten's recent email 21:05 < bonsaikitten> ciaranm: I don't think you're qualified to say that 21:05 < bonsaikitten> you didn't even understand it ... 21:05 < ahf> bonsaikitten: go rant somewhere else 21:05 < solar> he is a dev. He is allowed to voice his concerns here 21:05 < NeddySeagoon> bonsaikitten, hes qualified, just not impartial as he has a vested interest 21:05 <@leio> The first two e-mails of bonsaikitten were very informative 21:05 < jmbsvicetto> Can we please leave the "pleasentries" for somewhere else? Thanks 21:06 < ciaranm> leio: no, they were very wrong 21:06 < yngwin> so far i counted 2 yes and 2 no votes 21:06 < jmbsvicetto> yngwin: 3 yes and 2 no 21:06 <@Betelgeuse> yngwin: 3 times yes 21:06 <@Betelgeuse> Nothing from leio I think 21:06 < scarabeus> 3 yes 2 noes by mine counting 21:06 < yngwin> ok 21:06 <@Betelgeuse> leio: So what do you vote? 21:07 <@leio> I do not see voting being the correct action here, for the record 21:07 <@leio> I vote no 21:07 <@dev-zero> and Cardoe wrote in his mail that he's against it 21:07 <+tanderson> nice, a tie 21:07 <+tanderson> oh, not a tie 21:07 <@Betelgeuse> Will have to wait until next time then. 21:07 < solar> nope 21:08 < NeddySeagoon> its voted down 21:08 < ulm> Betelgeuse: 3 yes 4 no? 21:08 < ssuominen> Please clarify which we are really voting for, for me it seems very vague.. 21:08 < ciaranm> Cardoe hasn't voted 21:08 < ssuominen> or me 21:08 < jmbsvicetto> Betelgeuse: iirc, the rules are that any vote without a majority is a no vote 21:08 <+tanderson> ssuominen: GLEP 55 I think 21:08 < ulm> ciaranm: and Cardoe wrote in his mail that he's against it 21:08 <@leio> the e-mail was private 21:08 < ciaranm> ulm: that's not a vote 21:08 <@Betelgeuse> I don't see us counting private mails like that. 21:08 <@dev-zero> no 21:08 < ulm> ciaranm: you're right i guess 21:09 <@dev-zero> so we'll see it next time again 21:09 < jmbsvicetto> ulm: it doesn't matter. What counts are the votes here - a miniumum of 4 votes is required for a motion to pass 21:09 <@Betelgeuse> "Council decisions are by majority vote of those who show up (or their proxies)." 21:09 <@leio> lets say we know cardoe's opinion of it, but it's not a vote 21:09 < NeddySeagoon> Its still an overall no, as there was no majority 21:09 <@Betelgeuse> There's no majority either way. 21:09 <@dev-zero> leio: exactly 21:09 <@Betelgeuse> So there's no decision either. 21:09 < ssuominen> I vote no for GLEP 55 as it is put now. 21:09 < solar> that is some BS. You call for a vote. Don't like the results. And then declare there is no decision? 21:09 <@Betelgeuse> ssuominen: s/vote/change your vote/? 21:09 < ssuominen> As for the other ideas -part it leaves too many options open to give a vote on it. 21:10 < solar> you are serious? really? 21:10 <@Betelgeuse> solar: it was a tie 21:10 <@Betelgeuse> solar: Where does it say a tie means no decision? 21:10 < yngwin> so it is rejected 21:10 <@Betelgeuse> Now it's rejected as ssuominen changed votes. 21:10 < ssuominen> I voted yes for 54 if 55 gets approved, and no for 55 since it's not specific enough, specially the parts suggesting se different subdirectories for different EAPIs, i.e. cat/pkg/eapiX/ 21:10 < ssuominen> It needs to be more clear 21:10 < ciaranm> ssuominen: uh, 55 isn't proposing that 21:11 <@Betelgeuse> ssuominen: That's just a bad alternative 21:11 <+tanderson> ssuominen: 55 is saying that that's not a good idea 21:11 < NeddySeagoon> So when does the vote end ? 21:11 <@lu_zero> are we going to have petitioning about glep55 till next morning? 21:11 <+tanderson> NeddySeagoon: when I say that I'm Cardoe's proxy? (I'm not) :P 21:12 < ssuominen> well the other ideas is confusing, but if that's not really going in [in] anyway, then yes 21:12 < ssuominen> "other ideas" in the glep 21:12 <@Betelgeuse> ssuominen: Yes that's just to list other ideas proposed and why they are bad 21:12 <@lu_zero> ssuominen what donnie said in the email? 21:12 <@Betelgeuse> lu_zero: To use his judgement 21:12 < NeddySeagoon> ssuominen, how can you vote in favour of somethiing you clearly don't understand 21:13 <@dev-zero> NeddySeagoon: and how can he vote against? 21:13 < ssuominen> NeddySeagoon: I do understand, The GLEP imho is not clear enough. 21:13 <@Betelgeuse> Any way we need to vote again next time as there was no decision this time. 21:13 <@Betelgeuse> Next item 21:13 < bonsaikitten> LOL 21:13 < ssuominen> NeddySeagoon: The GLEP expects you to have read a mile long thread. 21:13 < NeddySeagoon> ssuominen, IF you understood it, you would not be changing your vote 21:13 <@lu_zero> ssuominen the problem is that glep shouldn't require that 21:14 <@lu_zero> (one of the problems) 21:14 <@dev-zero> Betelgeuse: since there was a tie at the beginning and now it changed to something else I'd say we retake the vote 21:14 <@leio> therefore the GLEP needs to be edited to make it so that a mile long thread doesn't need to be read before it can be considered to be approved 21:14 <@dev-zero> Betelgeuse: do you think we can continue or should we stop here? 21:14 <@lu_zero> and that was requested the first time it was proposed. 21:14 < ssuominen> a glep should be a full spec. of the proposed change, not some random quoting tablet. 21:14 <@Betelgeuse> dev-zero: I consider vote 3-3 and in GLEP 39 terms it means there's no decision either way 21:14 < ssuominen> tech. doc 21:15 <@dev-zero> Betelgeuse: good, also my point 21:15 <@lu_zero> ssuominen that's what I requested many times. 21:15 <@Betelgeuse> dev-zero: So I would put to agenda next time with hopefully 7 here 21:15 <@Betelgeuse> There's time to flame in between 21:15 <@dev-zero> Betelgeuse: good, will do that 21:15 <@dev-zero> ok, topic is closed 21:15 <@lu_zero> could we quickly stamp static libs? 21:15 < reavertm> according to GLEP1, this voted glep status could be changed to "Deferred" as no progress has been made on that glep (if not "Rejected") - I mean, if there's no resolution after so long time, maybe it should be reedited, as some people already raised points, that it's not well specified. 21:16 <@dev-zero> reavertm: topic closed, please post on ml, sorry 21:16 <@Betelgeuse> reavertm: There's no resolution because this was the first time the council actually voted on it 21:16 < ssuominen> i'd say normal default should be static libs disabled, but add USE="static-libs" to those ebuilds where they are needed 21:17 <@dev-zero> ssuominen: no ebuild "needs" to disable static libs 21:17 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)] 21:17 <@leio> or unconditionally enable where they are needed, such as those mythical system things that are told to break things if their .a gets filtered out with INSTALL_MASK 21:17 < jmbsvicetto> Betelgeuse / dev-zero: I disagree with your reading of GLEP39. The "Council decisions are by majority vote of those who show up (or their proxies)" in my reading means any motion that doesn't have a majority is by definition turned down 21:17 < ssuominen> dev-zero: only wrt installing performance, many ebuilds in tree does this already 21:17 <@leio> We explicitly disable static libraries with no USE flag option in most GNOME packages for good maintainer decided reasons 21:18 <@Betelgeuse> jmbsvicetto: Well turned down or not, we can always put it to vote next time if we want to 21:18 < fmccor|home> jmbsvicetto, No, that says "no decision" 21:18 < fmccor|home> jmbsvicetto, Because a vote to turn down is a decision, too. 21:18 <@leio> However we are about to add IUSE=static-libs to a few where users reasonably might have a potential use for static libraries, this iis basically C++ and glib (for prefix=/ usages) 21:19 < fmccor|home> jmbsvicetto, So you would need a majority "no" 21:19 < yngwin> there is a majority no 21:19 <@leio> I have never understood where this "ebuild must always install static libraries when available" "rule" comes from. Have seen it nowhere written down or explained 21:19 < ciaranm> leio: it comes from solar 21:19 <@lu_zero> solar really? 21:19 < ssuominen> leio: Me either, not needed for running, longer building time 21:20 < ssuominen> Should be "Only install shared libs, unless there is a real reason to add USE="static-libs" to control it." 21:20 <@leio> e.g, if you enable static libs in gtk+ and use them, you are just crazy and don't know what you are doing 21:21 < jmbsvicetto> leio: Qt/KDE would also be fun 21:21 <@dev-zero> so, should we put it like that "install shared libs only per default unless there is a reason and let users request USE=static-libs to control it" ? 21:21 <@dev-zero> ... if needed 21:22 < ssuominen> dev-zero: exactly 21:22 <@lu_zero> sounds ok 21:22 <@leio> yup. Could use some wording touch-up though 21:22 < ciaranm> you're wanting every ebuild to start doing econf --disable-static? 21:22 < ssuominen> ciaranm: yes, unless $(use_enable static-libs static) is requested. 21:23 <@leio> I see the supposed policy of always having to install static libraries as the problem 21:23 < ssuominen> or plain needed. 21:23 < ciaranm> my point was more "every ebuild", for some value of "every", tends to smell like a "shove it in the next EAPI" thing rather than forcing everyone to write their own src_configure 21:23 <@leio> I think maintainers can decide on that fully well themselves 21:23 < ulm> dev-zero: "install shared libs ..."? s/shared/static/? 21:23 <@leio> if they decide to keep it, I can live with that and work as a user and developer in convincing with technical arguments 21:23 < ciaranm> make EAPI 4 do src_configure() { if hasq "static-libs" $IUSE ; then econf $(use_enable static-libs static ) ; else econf ; fi } 21:24 <@Betelgeuse> I would see it cleaner to allow dropping statis libs now and wait for EAPI 4 having --disable-static by default 21:24 <@dev-zero> ulm: no :) bad wording: "install only shared libs per default" 21:24 < ssuominen> leio: Indeed, no doubt about that. I bet both Gnome and Xfce4 can all do --disable-static and we'll hear no complaints. 21:24 < ulm> dev-zero: o.k. ;) 21:24 <@leio> we've only had reasonable technical complaints 21:24 <@leio> a) C++ bindings, users fear that libstdc++ will break ABI again, so they want that part statically linked 21:24 < reavertm> why not just make it some eclass feature? why involve eapi here? 21:25 <@leio> b) glib, because some things in prefix=/ (as opposed to /usr) might want to use it 21:25 < ciaranm> reavertm: because otherwise no-one can use the default src_configure 21:25 < ciaranm> reavertm: also because otherwise there's no obvious way which ebuilds have been updated 21:25 < ciaranm> ...to tell which... 21:25 < jmbsvicetto> About removing the static libs, does the prefix project have any objections to it? 21:26 <@Betelgeuse> So let's vote on: It's now possible to drop static libs (with possible USE static-libs) and make it the default in EAPI 4. 21:26 <@Betelgeuse> ^yes 21:26 <@dev-zero> Betelgeuse: thanks :) 21:26 <@dev-zero> yes 21:26 <@leio> not like that 21:26 < ulm> yes 21:26 <@leio> lets vote on jsut dropping the requirement to ship static libraries or some such 21:26 <@leio> and we vote on EAPI-4 stuff when we are actually dealing with EAPI-4 21:26 < ciaranm> eh, eapi 3's merged. i can keep track of eapi 4 now. 21:26 < ssuominen> i second that.. why pull the eapi4 into this? 21:27 <@dev-zero> leio: uhm, that's what Betelgeuse proposed 21:27 <@leio> he proposed to vote on making it the default in EAPI 4 21:27 <@leio> it's not the time to vote on EAPI-4 items 21:27 < ssuominen> Why does it need to be EAPI=4 bound? 21:27 <@Betelgeuse> Well if I wasn't clear let's say put it as an item for EAPI 4. 21:27 <@Betelgeuse> ssuominen: I don't really fancy mandating every putting --disable-static 21:28 <@Betelgeuse> If people want to then sure 21:28 < reavertm> btw, why add autotools specific configuration to eapi? there are other buildsystems as well, hence I see no valid reason to make exception for it 21:28 <@leio> someone will make sure to propose it for EAPI-4. If no-one does, they don't find that useful 21:28 < ciaranm> reavertm: uhm... it's already in there. 21:28 <@Betelgeuse> reavertm: There's lots of autotootls specific stuff in default ./configure args 21:28 < ciaranm> reavertm: econf and src_configure are already both highly autoconf-centric 21:28 <@lu_zero> and that was stated again while discussing eapi3 21:28 <+tanderson> emake also assumes DESTDIR=$D for eapi 3 21:29 <@lu_zero> DESTDIR is more standard ^^ 21:29 <@dev-zero> can we have your votes please? 21:29 <@leio> ok, so what are we voting on? 21:30 < ssuominen> if this gets passed, can we start using it right now in tree? 21:30 <@leio> I see it's appropriate to vote on either dropping the requirement to ship static libraries (if such exists) 21:30 <@leio> s/either// 21:30 <@Betelgeuse> Developers can drop static libs if they want to but it won't be the default now. 21:30 < ssuominen> or do we have to wait for eapi4 for some magical reason 21:30 < reavertm> if so, I guess it's wrong approach - PM should be buildsystem independent - that's what eclasses are for imho 21:30 <@Betelgeuse> ssuominen: you can do it now if you want to 21:30 <@leio> Betelgeuse: with that wording I'm prepared to vote, and the vote is obviously yes :) 21:30 <@Betelgeuse> reavertm: No. The defaults should cater to most cases. 21:30 <+tanderson> reavertm: So econf should be in an eclass? That's silly 21:30 < ulm> reavertm: the default is reasonable since it covers the vast majority of cases 21:30 < ciaranm> reavertm: that idea was dropped years ago 21:31 <@dev-zero> ok, I vote yes 21:31 <@Betelgeuse> I vote yes 21:31 < ssuominen> I vote yes (but it should become the default to disable the static libs) 21:31 < ulm> I vote yes 21:31 -!- Zorry [n=zorry@fu/coder/zorry] has quit [Read error: 104 (Connection reset by peer)] 21:32 <@leio> we have a majority 21:32 <@dev-zero> good 21:32 -!- Zorry [n=zorry@ip1-67.bon.riksnet.se] has joined #gentoo-council 21:32 * lu_zero votes yes as well 21:32 <@dev-zero> ok, developers are allowed to drop static libs if the they want to but it won't be the default now 21:33 < ssuominen> dev-zero: right, it can be decided/voted later on will it become the default or not 21:33 <@leio> I suggest we suggest the development community to standardize on an USE=static-libs when they want to make installation of static libraries to be optional when they see a reason that someone might want them, and then it is eventually made a global USE flag per usual ways of having more than some 8 packages using it and proposing it on gentoo-dev as usual 21:33 <@dev-zero> leio: sounds reasonable 21:33 < jmbsvicetto> leio: 5 is the "magic" number 21:34 <@dev-zero> ok, I'd say we put the rest of the topics on the agenda for the next meeting 21:34 < ssuominen> so next topic removing old eclasses? 21:34 <@dev-zero> yes, in two weeks 21:34 < jmbsvicetto> leio: Should USE="static-libs" be a choice by the dev or should we mandate it for any ebuild that starts disabling them? 21:35 <@dev-zero> ssuominen: sorry, but the suggested timeframe for such meetings is 1 hour and some of us have either job, studies or bed calling 21:35 <@leio> jmbsvicetto: no, I meant it only for cases where it is reasonable to provide such an option. Not mandatory 21:35 < ssuominen> dev-zero: right 21:35 < jmbsvicetto> leio: If it is an option, users might start complaining about not being able to build packages with static-libs 21:36 <@dev-zero> ok, has somebody to say something which should get in the log, statemement etc? 21:36 < jmbsvicetto> leio: I was trying to clear what you said. I think some people (in particular users) might start "demanding" it becomes mandatory 21:36 < jmbsvicetto> Yes 21:36 < ssuominen> jmbsvicetto: for pkgs e.g. gst-engines-something just always --disable, i can see only few core libraries really needing the flag 21:36 < dleverton> Presumably EXTRA_ECONF could still override it (although a USE flag is still nice in cases where it's most likely to be useful) 21:36 <@dev-zero> jmbsvicetto: ok, what is it? :) 21:36 <@leio> jmbsvicetto: hmm... I guess it might be useful to define when it would make sense to have it. I personally see it making sense for some C++ things and in lower-level things that are of interest to the embedded community 21:36 <+tanderson> Why not just use EXTRA_ECONF in the places is useful(livecds I've heard) 21:36 < jmbsvicetto> The election team decided to hold the council elections from June 1st to 14th for nominations and 16th to 30th for voting. The results will likely be announced on July 2nd 21:37 < solar> leio: it comes from solar <-- not me. Perhaps somebody else. 21:37 <@leio> solar: vapier 21:37 < ssuominen> EXTRA_ECONF is not an option, there's other build systems as well... 21:37 < jmbsvicetto> leio: I'm not a fan of static-libs, but I antecipate users will complain about not having a choice 21:37 <@dev-zero> jmbsvicetto: ok, thank you already for organizing the elections 21:37 <@leio> solar: I think. At least he's the only one that has been saying there is such a rule, and the only actual written down statement as such is a short e-mail from him stating such a rule exists 21:37 <@dev-zero> tanderson: ^^ please put that in the summary 21:38 <+tanderson> the elections stuff? I miss nothing :P 21:38 <@dev-zero> someone else? 21:38 <@Betelgeuse> Well usually devs cater to users that want a choice. 21:38 <@Betelgeuse> IF it makes sense. 21:38 <@leio> solar: and Halcy0n saying there is such a thing because vapier said so :) 21:38 <@dev-zero> tanderson: yes, just add it as a separate point please 21:38 <+tanderson> yup 21:38 <@dev-zero> ok, then the meeting is over