16:01 <@Betelgeuse> so are we starting
16:01 <@dberkholz> yep
16:01 <@leio> where does that assumption come from
16:01 <@dertobi123> heya
16:01 <@lu_zero> apparently
16:01 <@leio> ok, nevermind for now
16:01 <@dberkholz> i was typing and was interrupted by a salad dish =P
16:01 <@dev-zero> leio: what assumption?
16:01 <+tanderson> mmmm, yummy
16:01 <@dberkholz> council folks, speak up please
16:01 < ciaranm> leio: if the assumption doesn't hold, you're into "stuff that doesn't work with existing EAPIs anyway" territory, and slot operator deps don't affect it
16:01 <@leio> that >=foo/bar-2:= means 2, 3 or 4, but not 1
16:01 <@dev-zero> dberkholz: another desert for me please
16:02 <@dberkholz> tanderson: can you list anyone on council who hasn't spoken since 2000
16:02 -!- psychoschlumpf [i=lars@unaffiliated/psychoschlumpf] has joined #gentoo-council
16:02 <@dev-zero> leio: read what ciaran said completely :)
16:02 < ciaranm> leio: if it doesn't, you can't use existing deps correctly anyway
16:02 <@leio> There are two parts in there
16:02 <@leio> >=foo/bar-2
16:02 <@leio> and :=
16:02 <@leio> Some foo/bar-2.0.1 might be SLOT=1
16:02 <@dev-zero> leio, ciaranm: I guess we should do that discussion later
16:03 <@leio> exactly, nevermind for now
16:03 < ciaranm> leio: ...in which case you're in "doesn't work with existing deps anyway, so unrelated to the proposal" territory
16:03 <+tanderson> dberkholz: Cardoe
16:03 <+tanderson> I knew I was missing someone...
16:04 <@leio> Cardoe had asked dang to proxy on #gentoo-desktop the other day
16:04 <+tanderson> well, dang isn't here either...
16:04 <@dberkholz> neither of them are on freenode
16:04 <@lu_zero> hmm
16:04 <+tanderson> dang it :P
16:04 <@dberkholz> if anyone's got im handy, please ping
16:05 <@dev-zero> is there a way we can store that info on a voluntary basis in the ldap?
16:05 <@dberkholz> we already do
16:05 <@dev-zero> ah, ok
16:05 <@dberkholz> gentooIM or so
16:05 <@dev-zero> then I have to go updating my info there :)
16:05 <@dberkholz> so let's get rolling
16:06 <@dberkholz> EAPI=3. i'd like to see people mention any specific features they've got questions for or want to reject entirely
16:06 <@dberkholz> i think only dev-zero and i have done this on the list
16:06 <@leio> the SLOT operator stuff is hazy for me. A nice concrete user facing documentation blurb would be appreciated
16:06 < ciaranm> dberkholz: Betelgeuse did too 15m or so ago
16:07 <@dberkholz> ah, thanks. been eating dinner and all that.
16:07  * solar requests that you start at the top of the draft vs the middle of it
16:08  * dev-zero agrees with solar
16:08 <@lu_zero> there is a quick link with the up to date list?
16:08 <@dev-zero> see topic
16:08 <+tanderson> solar: yep, nice for summaries as well
16:08 <@dberkholz> ok, sure.
16:08 <@leio> what, we are going to go through all of them again in a meeting?
16:09 <+tanderson> dleverton had PMS copies available as well, since my computer is still struggling to compile texlive
16:09 <@dev-zero> we can group them by priority
16:09 <@dberkholz> i've got an idea
16:09 <@Betelgeuse> The only thing I see useful to do here is to assign people to take care of getting them implemented
16:09 <@Betelgeuse> I can take a couple
16:09 <@dev-zero> I already started :)
16:10 <@dberkholz> does anyone who hasn't posted on the list have questions or problems with specific features that they want to say here?
16:10 <@lu_zero> ...
16:10 < solar> yes
16:10 < solar> but towards the end
16:10 < hwoarang> not right now :)
16:11 <@dev-zero> ok, pkg_pretend and the USe dep modifiers have already been accepted
16:11 <@leio> yes, but details on list after meeting would be best, sorry for not doing it before-hand.
16:11 <@dev-zero> slot operator support as implemented in kdebuild ... leio has a question there
16:12 <@dertobi123> well, probably yeah ... but i wasn't able to do so on-list before the meetingt
16:12 <@dertobi123> meeting*
16:12 <@dberkholz> hmm
16:12 <@dev-zero> leio: your question is about certain use cases, right?
16:12 <@dberkholz> can we collect a specific list of features that people have questions/problems with now, and not actually discuss the questions?
16:12 <@leio> yes, and actual examples and user documentation
16:12 <@dberkholz> that way we at least know what's blocking
16:13 <@dev-zero> dberkholz: ok, let's first do that and then discuss the concrete questions right afterwards
16:13 <@lu_zero> or that there are enough features worth an eapi bump
16:13 <@dev-zero> lu_zero: do you doubt that?
16:13 < ciaranm> user documentation for slot operator deps is easy. just tell people that if they build+run dep on something that has multiple slots, they should append either :* or :=.
16:13 <@leio> regarding dohard deprecation I'm reserved about. It should be handled when possible and the portage bug needs to be fixed anyhow (actual packages are getting lots of copies of the same file because hard links are lost, irrelevant to dohard)
16:13 <+tanderson> I could do devmanual patches easily for docs
16:14 <@dberkholz> whoever has a feature they have a question/problem with, just say to me (dberkholz: $feature) what the feature is, so tanderson can collect a list of what feature and who
16:14 <@lu_zero> dev-zero after discussion we can either wait or go on with what is already accepted
16:14 <@dev-zero> tanderson: that'd be great because I don't want to touch that thing
16:14 <@dev-zero> leio: I don't think there's a good way to handle it properly
16:14 <+tanderson> dberkholz: it's easier to prefix that with tanderson since then I'll just look for highlights :)
16:15 <@dberkholz> either way. already one false positive
16:15 <@dberkholz> you've got 5 minutes =P
16:15 <+tanderson> *cricket* :P
16:15 < hwoarang> dberkholz: doinclude seems useless to me
16:15 <@leio> Are we talking about open questions about a feature, or rejections too? ;p
16:16 <@dev-zero> leio: both
16:16 <@leio> like I'm clear on some of them but definitely rejecting
16:16 <@lu_zero> which ones?
16:16 <@dev-zero> dberkholz: mind posting yours too?
16:16 <@leio> tanderson: slot operator support (open questions, might be against depending on the answer to those)
16:17 <@leio> tanderson: default src_install (there are already open questions still there per dev-zero's summary - same thing)
16:17 <@Betelgeuse> I wonder if the slot operator stuff would better be postponed to go in with labels.
16:17 <@Betelgeuse> ciaranm: Does that make sense^?
16:17 < ciaranm> Betelgeuse: labels solve a different problem
16:17 <@lu_zero> tanderson I'm against disable-dependency-tracking in econf by default
16:17 <@dberkholz> tanderson: default src_install; doinclude; dosed
16:18 < ciaranm> Betelgeuse: you *could* co-opt it into labels, but it's messy, because labels work on groups, and operators work on individual things
16:18 <@dberkholz> tanderson: unpack should fail on unknown types
16:18 <@dberkholz> i think that's it off dev-zero's list
16:19 < ciaranm> lu_zero: what's wrong with disable-dependency-tracking? not heard any objections to that before
16:19 <@leio> tanderson: docompress (I need to review what prepalldocs does and compare it closer to the proposed thing, so not open question, just needing more time to be sure)
16:19 <@lu_zero> ciaranm there are configure script rejecting it
16:19 <@dberkholz> remember, we're not discussing yet... hold off till we're done
16:19 <+tanderson> leio: not sure what to classify that one as then
16:19 <@lu_zero> (sadly)
16:19 < ciaranm> lu_zero: which ones, and why?
16:19 <@lu_zero> hand made ones
16:19 <@leio> tanderson: ignore I guess unless I bring up on ml
16:19 <@Betelgeuse> lu_zero: Well just have a way to disable the behaviour
16:20 <@dev-zero> tanderson: docompress ... I still think it's useless
16:20 <+tanderson> leio: ok
16:20 <@dev-zero> tanderson: doexample must have -r if at all
16:20 <@lu_zero> Betelgeuse ok
16:20 <@dertobi123> tanderson: default src_install; doexample
16:21 < dleverton_> Are hand-made configuration scripts going to accept the arguments that econf already passes?
16:21 <@lu_zero> dleverton_ yes
16:21 <@leio> tanderson: regarding "Limit values in $USE to the ones in $IUSE" I need to just educate the developers about what LINGUAS is and isn't better.
16:21 <@dberkholz> not all of them. i've got examples
16:21 < ciaranm> lu_zero: there're hand-made configure scripts that take everything econf passes but not disable-dependency-tracking? examples please
16:21 <@lu_zero> ffmpeg ?
16:21 <@lu_zero> mplayer ?
16:23 < ciaranm> they take weird stuff we already pass like --host and --localstatedir, but barf on --disable-dependency-tracking?
16:23 <@dberkholz> anyone still got things to list to me / tanderson ?
16:23 <@lu_zero> anyway if econf is tailed to work with autotool generated configure
16:23 <@leio> tanderson: Deprecate "|| ( foo? ( . ) . )" in depend  -- should not need an EAPI rule to ban it completely to avoid mis-use, and I see no reason to start banning various specific DEPEND constructs and be required to parse for all the EAPI rejected stuff and so on, while there might be 1-10% valid use cases
16:23 <@lu_zero> and is stated
16:23 <@lu_zero> I'm fine with adding them
16:23 < ciaranm> econf already passes autotools-specific weirdness
16:23 <@leio> tanderson: dohard - should remain and bugs fixed instead imho
16:23 < ciaranm> leio: banning it across EAPIs is a clean way of getting rid of it. and there are no valid use cases.
16:24 < ciaranm> dohard is probably unfixable
16:24 <@dev-zero> ciaranm: it is
16:24 <+tanderson> leio: as far as I'm aware there have been no correct usecases for || ( foo? ( . ) . )
16:24 <@leio> tanderson: doinclude - mostly unnecessary . Might be interesting for the potential +x removing bit, but build systems should install them properly really
16:25 <@leio> tanderson: .xz support - never heard of what it is and it doesn't appear to be a mature packing format yet. Does it mean portage will have to rdepend on the unpacking tool of it?
16:25 <@dev-zero> leio: no, it doesn't mean that
16:25 <@leio> tanderson: --disable-dependency-tracking and --enable-fast-install -- would be nice, but some scripts don't take them and fail
16:25 < ciaranm> leio: deps for .xz things are like deps for .rar, which unpack already does
16:26 <@dev-zero> btw, it has been requested that .xpi gets added to the new extensions unpack supports
16:26 <@leio> package needs to DEPEND on the unpacker? Fine.
16:26 <@lu_zero> and xpi is stable and widespread
16:26 < ciaranm> what unpacks xpi, and how horrid is its interface?
16:26 <@leio> tanderson: utility commands should die -- documented open questions
16:26 < psychoschlumpf> isnt --enable-fast-install enabled per default for autoconf configure scripts
16:26 <@lu_zero> ciaranm zip
16:26 <@dberkholz> can anyone speak up now if they haven't yet said they have issues with EAPI=3 features?
16:27 < ciaranm> xpi's easy enough then, so i have no opinion on it
16:27 <@leio> tanderson: "provide ebuilds a way to differentiate between updates and removals" -- seems to duplicate REPLACING_VERSIONS
16:27 <@dberkholz> tanderson: you have a list of features now?
16:27 < ciaranm> leio: uh, that *is* REPLACING_VERSIONS
16:27 <@dev-zero> jup, my bad, sorry
16:27 <@lu_zero> then it's a dupe
16:27 <@leio> sorry, I'm going by dev-zero list
16:27 <@dev-zero> leio: no problem, my fault
16:27 <@dberkholz> the description needs changing, i guess
16:28 <@dev-zero> I'll do that after the discussion to not even confuse people even further ;-)
16:28 <@leio> lots of the stuff at the end seems to have unclear things
16:29 <@dev-zero> leio: which ones=
16:29 <@lu_zero> leio you mean "Non-fast Features"
16:29 <@dev-zero> ?
16:29 < ciaranm> leio: go by the pms draft for clear specifics
16:29 < solar> If you are at the end. Then Non-fast Features -> src_test() listed is a no go.
16:29 <@leio> nah, I think just one or two of the stuff before non-fast features had mentioned open questions too.
16:30 <@leio> as for non-fast features
16:30 <@dev-zero> solar: that's why it's non-fast, not considered for eapi-3 unless someone explicitly asks for it
16:30 <@dev-zero> (should have chosen a better title though)
16:30 <@leio> most of them have no description in dev-zero summary
16:30  * ciaranm asked for it, on the grounds that src_test is useless without it
16:30 <@leio> regarding
16:30 <@leio> src_test run unless RESTRICTed or explicitly disabled by the user
16:30 <@leio> completely against it, in any form
16:30 <@lu_zero> ciaranm src_test should be triggered by repoman
16:30 <@Betelgeuse> ciaranm: well I do have arch teams using src_test to catch stuff so it's not useless
16:31 < solar> well as stated. The core problem there is if $CBUILD != $CHOST
16:31 <@dberkholz> ok, let's skip non-fast things in the interest of getting this in the tree by the end of april
16:31 <@Betelgeuse> ciaranm: probably could be more useful of course
16:31 < ciaranm> lu_zero: yes, because that works *brilliantly* for detecting failures on user systems.
16:31 < ciaranm> solar: ebuilds don't support cross compiling, so it's not an issue
16:31 <@dberkholz> sarcasm not necessary...
16:31 <@lu_zero> ciaranm user system having src_test enable is a failure by itself
16:31 <@lu_zero> since the time and resources needed by certain testsuites
16:31 < ciaranm> lu_zero: no, it's a basic sanity feature. for those certain test suites you can override it.
16:31 <@Betelgeuse> If we were to enable to now, my bet would be that most users would just disable it.
16:31 <@dev-zero> lu_zero: that's a different issue
16:31 <@leio> ok, now what?
16:32 <@lu_zero> ciaranm do you really use src_test on your systems?
16:32 <@Betelgeuse> Then they won't enable it when it's actually good to enable.
16:32 < ciaranm> lu_zero: yup
16:32 <+tanderson> lu_zero: I use it on my system, works fine
16:32 < ciaranm> lu_zero: as does everyone else running paludis
16:32 < dleverton_> lu_zero: in the same way that having cmake installed or using live ebuilds is a failure?
16:32 <@leio> lets not discuss src_test further please. It is not feasible to enable it by default this year
16:32 <@lu_zero> ciaranm and you do not have failures?
16:32 < ciaranm> lu_zero: i do. EAPI 3 would fix this.
16:32 <@lu_zero> dleverton_ ciaranm said there are so...
16:32 <@dev-zero> hehe, touché :)
16:33 <@lu_zero> ciaranm I don't see why
16:33 <@dberkholz> tanderson: i'm still waiting for you to tell us that you have a list of features with people who have questions etc
16:33 < ciaranm> lu_zero: if it were on for EAPI 3, any src_test failure that made it to the user would be a genuine failure. right now, half of test failures are just caused by lazy developers.
16:33 < dleverton_> lu_zero: ciaranm said there are what so what?
16:33 <@lu_zero> make test is used by upstream
16:33 < solar> ok well the real world includes things like cross compiles. So in the case of $CBUILD != $CHOST src_test() can and should not be run.
16:33 <@lu_zero> dleverton_ not just me apparently
16:33 <+tanderson> dberkholz: I can't write that up while the meeting's going on...too many people and too many proposals
16:33 < dleverton_> lu_zero: I can't understand a word you're saying now.
16:33 <@dev-zero> tanderson: how much off-time you need?
16:34 <+tanderson> dev-zero: ~5-10 minutes maybe
16:34 <@dberkholz> tanderson: now you understand the challenge when i was trying to be secretary too =)
16:34 < ciaranm> solar: so users who do cross-compiling can turn it off, along with all the other things they need to do to get cross-compiling to sort of work
16:34 <+tanderson> dberkholz: heh, indeed
16:34 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
16:34 <+tanderson> dberkholz: for now I can give you a list of things that need discussing so it can be done one at a time though
16:34 < solar> ciaranm: no reason to break stuff that works now for people
16:34 <@leio> ciaranm: for cross-compiling to work they just cross-compile, there's nothing else to do beside fix bugs...
16:35 <@dberkholz> tanderson: ok. all in one line, please, so it doesn't get broken up. then i'll start at the beginning
16:35 < solar> if people want and have the spare cpu and are the type to fix stuff. They can enable what they want.
16:35 < ciaranm> solar: it's an easy change for people who've already made large changes for cross-compiling to make one more small change
16:35 < solar> vs us being broken by default
16:35 < ciaranm> leio: ebuilds don't support it, though, except by fluke
16:35 <@leio> FEATURES=test on by default is completely unfeasible
16:35 < dleverton_> If it would really make people happy, portage could easily disable tests automatically in that case.  PMS already doesn't cover cross compiling, so no need to mention it there.
16:35 <@leio> and as far as I'm concerned not a thing for an EAPI point
16:36 <@dertobi123> leio: fully-agreed
16:36 < ciaranm> leio: explain why please, avoiding any issue that has previously been shown to be false
16:36 < solar> our users are not an excuse for upstreams often buggy test suites. but that is a diff story.
16:36 <@dev-zero> ok, can we stop src_test discussion _now_ ?
16:36 <@leio> if a package manager wants to give users pleasures of uninteresting subtle failures due to bugs in the tests themselves, and increase the compile time from minutes to days for some stuff, that's their business
16:37 < ciaranm> leio: sorry, already debunked as being utter nonsense. please at least read the discussion we had.
16:37 <@leio> it's not an EAPI feature what a package manager or profiles considers a default FEATURES
16:37 < ciaranm> leio: also already debunked
16:37 < solar> I read it and in no way did you debunk it. you dismissed it
16:37 <@leio> I'm done with src_test for today.
16:37 <@Betelgeuse> stop
16:37 <@Betelgeuse> I don't see this going anywhere useful atm
16:38 <@dev-zero> me neither
16:38 <+tanderson> slot operator support(leio questions), default src_install(leio, open questions), disable-dependency-tracking(lu_zero), unpack fail on unknown types(dberkholz), doinclude( dberkholz ), doesed( dberkholz ), docompress(dev-zero+leio), doexample(dev-zero), limit values in $use to $iuse(leio), deprecate || ( foo? ( . ) . )(leio), dohard(leio), doinclude(leio), fast-install(leio)
16:38 <@Betelgeuse> There's nothing new here.
16:38 <@dertobi123> Betelgeuse: exactly
16:38 < ciaranm> it's not going to go anywhere useful until people read the frickin' discussion
16:38 <@dberkholz> aha, there we go
16:38 < solar> so drop it from the draft plz then
16:38 <@dev-zero> solar: will do
16:38 < ciaranm> solar: it's not in the draft
16:38 < solar> thanks. have a nice day *
16:38 <@dertobi123> tanderson: hrm, you missed my comment? ;)
16:38 <@dberkholz> the first thing on the list is slot ops. leio, you said you'll post to the list about that?
16:38 < solar> ciaranm: see the end of it. It was.
16:38 <@Betelgeuse> solar: read pms
16:38 < ciaranm> solar: no, it's in dev-zero's summary. it's not in the draft.
16:38 <+tanderson> dertobi123: I skimmed over, probably missed a few people's objections
16:39 < solar> Betelgeuse: PMS is the final spec. We are talking about a draft here at listed in the topic
16:39 <@leio> dberkholz: I guess. It would be nice to have explanations from an ebuild developer point of view for things like that point
16:39 <@dev-zero> list seems small enough to be discussed here, no?
16:39 < ciaranm> solar: uh. no. we're talking about a pms draft branch.
16:39 < solar> if you are putting things into before they are approved, then something is really wrong
16:39 < solar> ok
16:39 <@dertobi123> tanderson: anyways, my topics are listed
16:39 <@Betelgeuse> solar: The topic should have been made to point to PMS draft branch
16:40 <+tanderson> dertobi123: yeah, when we get to those you can just chip in that you also have questions
16:41 <@dev-zero> leio: from an ebuild developer pov: DEPEND="dev-lang/python" in a python package spans up to 4 slots
16:42 <@dev-zero> leio: DEPEND="dev-lang/python:=" will tell the pm that a package built using a specific python version needs that specific python version as long as that package is installed
16:42 <@leio> dev-zero: I think my point is to have such an explanation available to anyone evaluating the features. Your summary page or mailing list or whatever that goes beyond council members :)
16:42 < ciaranm> leio: *all* the changes will need user-facing documentation
16:42 <@dev-zero> yes, but creating them before actually having stuff implemented is a lot of work
16:43 <@leio> yeah, I don't mean all. Just things that are not well understood otherwise. Like this one.
16:43 <@dberkholz> leio: anythong you want to bring up now on default src_install?
16:43 <@leio> Ah! I think I found the right place in PMS. the hyperlinks on the bottom to up are going to weird places
16:44 <@dev-zero> leio: and the result? :)
16:44 <@leio> as for default src_install, I understand it covers what docs should be installed by default
16:44 -!- kickar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council
16:44 < ciaranm> the default src_install has "TODO: what goes here?"
16:45 <@leio> I think that this should be done by the maintainer always
16:45 <@dev-zero> leio: so, no default src_install?
16:45 <@dberkholz> yeah, there are many cases when the default GNU files are totally useless
16:45 < ciaranm> because some people think ebuilds shouldn't use DOCS="blah", despite writing lots of code themselves that does exactly that...
16:45 <@leio> this is in regards to the docs part of it
16:45 <@dev-zero> dberkholz: but for those a src_install is already written
16:45 <@leio> dodoc seems to already ignore files listed that are empty
16:46 <@leio> but in some cases NEWS says
16:46 <@leio> "See ChangeLog" and nothing else, crap like that doesn't need to get installed
16:46 <@leio> DOCS sounds good. Many eclasses do it.
16:46 <@dev-zero> dberkholz: and don't understand the argumentationn, sorry
16:46 < ciaranm> leio: in some cases, you override it. it's only a default.
16:47  * dertobi123 likes to see a useful default DOCS
16:47 <@leio> but I want the default src_install to handle the actual installation
16:47 <@leio> not decide for me what docs get installed
16:47 < ciaranm> then if the default's not good enough, don't use it
16:47 < ciaranm> the idea of defaults is to cover a lot of cases, not all cases
16:47 <@dertobi123> have a sane default, if you want to decide what docs get installed set DOCS
16:48 <@dev-zero> yes, you can still override it if you see that the docs installed by default are crap
16:48 <@leio> yeah, just please with a way that doesn't mean I can't call default in src_install for stuff like getting make install run by the default
16:49 <@leio> DOCS=""
16:49 <@leio> src_install() {
16:49 < ciaranm> leio: that'd need DOCS then, which some people object to
16:49 <@leio>   some_extra_stuff
16:49 <@leio>   default
16:49 <@leio> }
16:49 <@leio> sounds good
16:49 <@leio> right, so there's more discussion to do on list :(
16:49 < ciaranm> unfortunately the objection to DOCS is purely ideological
16:49 <@dev-zero> no, I don't think so
16:49 -!- spitf1r3 is now known as spitfire_
16:49 < ciaranm> which means voting on it and seeing which ideology is in the majority...
16:50 <@dev-zero> dberkholz: I remember you being the one objection DOCS, right?
16:50 <@dberkholz> yes
16:51 <@dberkholz> if you want docs defaults, i'd prefer a function argument instead
16:51 <@dev-zero> example?
16:52 <@dberkholz> i haven't thought about the interface
16:52 <@dberkholz> but you're all familiar with the concept of arguments to functions
16:52 <+tanderson> why not just vote on it?
16:53 <@dev-zero> yes, who objects a default src_install which calls "emake DESTDIR=${D} install ... ; dodoc ${DOCS}" ?
16:53 <@dev-zero> and from those who don't: who objects DOCS having a sane default like README NEWS etc. if not specified otherwise?
16:53 < solar> will it die if they don't exist?
16:54 <@dberkholz> i object to the whole philosophy of moving important parts of all ebuild functions (not global metadata) into variables
16:54 <@Betelgeuse> I want the contrary
16:54 <@Betelgeuse> In Java ebuilds having as much in variables has showed to be much better
16:54 <@dberkholz> i don't think it's useful enough with the changes in new EAPIs
16:54 < solar> and will the ebuild be forced to set DOCS="" ?
16:54 <@dberkholz> although when i wrote eclasses years ago, it was nice
16:54 < ulm> solar: some eclasses die if files from DOCS don't exist. so a general default may be problematic
16:55 < ciaranm> solar: the DOCS-based proposals i've seen only die if you explicitly set docs and stuff doesn't exist
16:55 < solar> seems sane
16:55 < ciaranm> solar: they silently ignore any defaults that don't exist
16:55 <@dev-zero> that seems useful
16:55 <@dev-zero> vote?
16:55 <@dberkholz> making people know all these variables associated with ebuild functions adds a whole new dimension to what they have to learn
16:56 <+tanderson> so people learn a bit more...big deal.
16:56 <+tanderson> Learning ebuilds isn't terribly difficult
16:56 < solar> tanderson: it will become harder over time as each eapi will have it's own rules.
16:56 < hwoarang> imho it's better to learn a couple of new ebuild than writting functions
16:56 <@dev-zero> nothing more than they have to learn when writing an ebuild using one of 13 or 14 eclasses which already recognise DOCS
16:56 <@dertobi123> and DOCS shouldn't be that hard to "learn" *cough*
16:56 < hwoarang> *s/ebuilds/variables
16:57 <@lu_zero> since is already in use
16:57 < ciaranm> solar: you only have to learn the EAPIs for things you're writing. which should just mean new EAPIs. older stuff you just look up.
16:57 <@lu_zero> have it standardized would be good
16:57 <@dev-zero> solar: there's usually only one eapi to learn, the most recent one
16:57 < solar> no
16:58 <@dberkholz> editing an ebuild that's e.g. part of kde or X or whatever is a whole different story from having *all* ebuilds doing something
16:58 <@dev-zero> dberkholz: not all, only those being EAPI=3 and from those only the ones with no src_install
16:58 < ciaranm> this isn't going to get decided by anything except a vote
16:58 <@dberkholz> you can learn levels of complexity in steps instead of needing it all at once for a basic ebuild
16:58 <@lu_zero> I'd just think if it would make us spare time or not
16:58 < ciaranm> both sides already know the arguments each way
16:58 <+tanderson> hint: if a substantial amount of eclasses do something, there might be a point to it
16:59 <@dev-zero> tanderson: my point
16:59 <@dev-zero> and I would like to see a vote
16:59 <@Betelgeuse> DOCS++
16:59 <@dev-zero> DOCS++
17:00 <@dberkholz> ----------------------
17:00 <@dertobi123> DOCS++
17:00 <@dberkholz> sorry, bad wifi.
17:00 <@lu_zero> too many - ^^
17:00 <+tanderson> unfortunately, we could have a tie vote...
17:00 <+tanderson> lu_zero: is that a DOCS-- for you?
17:00 <@leio> sorry, I got pre-occupied
17:00 <+tanderson> ok
17:01 <@lu_zero> tanderson I'm not so fond of having too many automagic vars
17:01 <@lu_zero> so I can agree on the idea of dberkholz
17:02 <@lu_zero> in itself shouldn't change much since common docs aren't that common (sadly)
17:02 <@Betelgeuse> lu_zero: woot?
17:02 <@Betelgeuse> lu_zero: I see it in almost every ebuild I write
17:03 <@lu_zero> Betelgeuse and you touch which kind of ebuilds?
17:03 <@dev-zero> lu_zero: and you can still set it manually
17:03 <@Betelgeuse> lu_zero: Java and autotools
17:03 <@dberkholz> we need to wrap it up
17:03 < ciaranm> need to finish the vote!
17:03 <+tanderson> is that a positive vote for DOCS? 3 ++, 2 --
17:03 <@dberkholz> looks like we're waiting on another vote from leio, and we'll catch cardoe later
17:04 <@dberkholz> if necessary
17:04 <@dberkholz> then we'll close up
17:04 <@leio> sorry, was on phone with landlord, gimme a minute please
17:05 <@lu_zero> Betelgeuse do they have a common intersection that is bigger than 2?
17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -l dodoc | wc -l
17:05 <@Betelgeuse> 12457
17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -vl dodoc | wc -l
17:05 <@Betelgeuse> 26204
17:05 <@Betelgeuse> and then there's the DOCS using stuff etc
17:05 <@dberkholz> leio: from 20:53 on will catch you up on this, if you aren't yet
17:06 <@leio> yeah, got markerline, reading
17:06 <@lu_zero> Betelgeuse so you are positive that would make us spare time
17:06 < solar> it sounds like you don't have to vote right now as cardoe is not here anyway
17:06 <@Betelgeuse> solar: if leio votes yes we have a majority any way
17:06 < ciaranm> doesn't really matter if leio votes in favour
17:06 <@dberkholz> you could do a grep for exactly how dodoc is called
17:06 <@dberkholz> indeed
17:07 <@leio> DOCS++
17:07 <@Betelgeuse> lu_zero: We used to have lots of stuff in functions in Java ebuidls. I migrated to using variables and it has been a lot better.
17:07 <@Betelgeuse> lu_zero: At least for me personally
17:07 <+tanderson> fine, DOCS is in
17:07 <@dberkholz> k, that's it for tonight
17:07 < solar> guys done?
17:07 <@dev-zero> yes
17:07 <@Betelgeuse> I will note that zac told me that GLEP 55 support is in Portage.
17:07 <@Betelgeuse> So I can finally do the numbers.
17:07 <@lu_zero> its 10.12 for me
17:08 <@dberkholz> meeting's over, tanderson please be sure to post the nice list of features with people blocking them