path: root/meeting-logs/20090514.txt

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=<value> 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-<eapi>  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: <dev-zero> 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> <ciaranm> 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