19:00, so let's start the meeting [21:00] agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/4014 roll call here here here here here dberkholz? [21:01] anyone has donnie's number? [21:02] lets start he sent it to the list or alias sent him a text... [21:03] dilfridge, were you going to compile a list? :) yes, soon... anyway, let's start first topic: dynamic dependencies in portage http://thread.gmane.org/gmane.linux.gentoo.project/3943 wheeee [21:04] any opinions? two things from me... So, I believe the portage team indicated that they plan to remove dynamic deps the way they are now, but to come up with another solution to the rebuild problem. As long as the latter accompanies the former when it goes mainstream, I don't have a problem with it. [21:05] 1) some eclasses add dependencies which need to be changed every now and then... e.g. minimal perl version in perl-module.eclass, or minimal qt version for kde ebuilds I'd say this is up to the portage team. they had added the feature, so they can change or remove it as well noone's come up with a real solution for this yet, except for a true mass rebuild There is a solution that mgorny came up with, a new @changed-deps set that would rebuild everything. [21:06] with new dependencies yes... wanna rebuild all perl-related ebuilds in your system? :) WilliamH: IIUC this has the same problem as dynamic dependencies if the ebuild is gone, the package won't be rebuilt [21:07] i haven't seen a solution that satisfies my so i'm not sure what we are resolving here. i'd say ask the portage team to come up with something. so it would bite users who haven't upgraded for a long time 2) that said, I dont intend to fully block this move by the portage team, but before it's actually disabled fully, we need a working, reliable alternative and a good idea for the needed workflow and tree policies. ulm, the ebuild is still in vardb as a pkgcore guy, I've never been pro-dynamic deps due a number of issues most of which have been raised in the various threads dilfridge: ++ blueness: the one with the old dependencies [21:08] ah yes imo, we should really spec out a vdb format That is my concern. I'm fine with one step back and two steps forward, but we can't do the latter without plans to do the former. Err, the other way around :) radhermit, take a look at https://wiki.gentoo.org/wiki/GLEP:64 Sure, to some extent the portage team should take the lead on this, but this affects the whole tree and how it is maintained. so, should we ask the portage team to outline their solution, before they remove the current feature? [21:09] this does not so much affect the maintainer of a single package, blueness: ah gotcha but much more the people maintaining virtuals and eclasses... There is no consensus in Portage team to remove dynamic dependencies. Arfrever: I thought there was. [21:10] Sorry can you type louder, I didn't hear you... anyway, I also agree that the support shouldn't just be yanked out of portage since it's been the default for a long time and devs have become implicitly used to its mostly hidden workings [21:11] exactly. I think a long-term plan would alleviate a lot of concerns. It isn't enough to say dynamic deps are broken. We need to talk about what the better solution actually is. I'm sure it will be supported then. Arfrever: the portage team meeting summary posted on 2014-07-25 says that dynamic dependencies will be turned off right now the bigger surprise is that sometimes dynamic deps dont work... that's the most official statement we have so we should go from there [21:12] anyone wants to come up with a motion? [21:13] I'm thinking that if they are turned off by default that will be ok as long as we can turn them on until a fix is developed. We won't know what is broken by them being turned off until they are turned off... [21:15] ulm: This "meeting" was even not announced before it (mailing lists were down). I have received e-mail about announcement of meeting after meeting. Probably very small number of members of team participated in meeting. Arfrever: you should be able to check that by the meeting log if it is posted. [21:16] How about this: "The council asks the portage team to outline their long-term plan regarding removal or replacement of dynamic dependencies, before they actually remove this feature." ulm: that plus: yes "Especially tree policies and the handling of eclasses and virtuals need to be clarified." [21:17] (Anyway I am one of Portage team members, who would vote for keeping dynamic dependencies.) good wfm "The council asks the portage team to first outline their long-term plan regarding removal or replacement of dynamic dependencies, before they remove this feature. Especially tree policies and the handling of eclasses and virtuals need to be clarified." dilfridge, "especially" -> "In particular" (very minor change but sounds better) Please vote * dilfridge yes yes yes yes [21:18] ok, with blueness's change of wording yes yes yes sure unanimous, for the council members present anything else for this topic? just the remark [21:19] that this is much more critical for slow arches as e.g. arm or ppc where the rebuilds are more time-consuming. do you want this in the summary? * dilfridge pulls up the obligatory remark about a "beowulf cluster of those"... [21:20] nah, log is enough :) next topic: additional features for EAPI 6 http://thread.gmane.org/gmane.linux.gentoo.project/4002 mgorny asks us to reopen the list of features [21:21] ulm: (It was never closed anyway...) were they closed? I didn't think so yet k I suggest we discuss features individually [21:22] + 1. passing additional configure options, namely --docdir and --htmldir I would be in favour of this imo, should be fine * dilfridge abstains looks pretty safe should be ok [21:23] and mgorny has done a tree-wide scan IIUC so let's just vote * ulm yes yes * dilfridge abstain yes * rich0 yes * WilliamH yes passes with 5 yes 1 abstention 1 absent [21:24] 2. additional default suffixes for dohtml IMHO changing the default is pointless What are the requested suffixes? [21:25] it's just a default, and there are options -a and -A to change the list of suffixes .xml .xhtml .ico .svg bug 423245 ulm: https://bugs.gentoo.org/423245 "[Future EAPI] dohtml: Extend default list of extensions"; Gentoo Hosted Projects, PMS/EAPI; UNCO; arfrever.fta:pms-bugs I have some ideas about moving the dohtml function from the PM to an eclass [21:26] this is minor, imo. its harmless to change the default but there's no strong reason to do so. blueness: well, devs have to learn the difference between EAPIs then [21:27] right. let's keep it as it is. ulm, yeah i guess and you'd have to check the set of installed files for every EAPI bump from 5 to 6 more discussion? seems not, so let's vote [21:28] * ulm no * dilfridge no no no * WilliamH abstains no rejected, 5 no 1 abstention 1 absent 3. build-time switching variant of || () [21:29] bug 489458 ulm: https://bugs.gentoo.org/489458 "[Future EAPI] Replace || with something less ambiguous"; Gentoo Hosted Projects, PMS/EAPI; CONF; ciaran.mccreesh:pms-bugs I would be very much in favour of this feature if there was proof of concept ready I think mgorny's proposal seemed reasonable enough. well, right now we're only saying what things people should work on... this is not the final decision on EAPI features (since that needs the implementation) [21:30] ulm: well, that seems to be the point of pre-voting on EAPIs rich0, you mean comment #14? blueness: yes we could provisionally approve it, with the condition that it will only be included in EAPI 6 if an implementation is ready comment 14 is the one to go for, yes We'll have to re-vote on the final PMS once there is a reference implemenation. [21:31] ulm: isn't that true for everything right now? dilfridge: yes PMS policy is that we don't put stuff in until implemented in portage This is basically to help devs avoid wasting time on stuff only to have it yanked back out I think it makes sense to do it this way. dilfridge: mgorny has implemented everything else in his branch of portage already People can still work on stuff we vote no on, or not work on stuff we vote yes on. It just gives them a sense of where we stand. [21:32] right... but that wasn't the case at the time of the first votes :P o.k. * radhermit will need to look at pkgcore code a bit, but it seems ok-ish rich0, i agree that this resolves one ambiguity, but to be honest, i can't fully get my head around all the possibilities here, and i'm not sure mgorny's solution really nails everything so please vote on provisional approvement, with the condition that it will only be included if an implementation is ready * ulm yes * dilfridge yes [21:33] yes yes yes WilliamH? blueness: agree that when you get into nesting the actual use gets murky. However, I think that the rules are straightforward enough. I guess if you get ||= embedded in || you have to decide if the ||= propagates through. * WilliamH yes [21:34] rich0: these things are what makes the implementation difficult ;) it will probably need some more forceful or better defined boundaries though, I'm assuming that'll happen if it gets into PMS passes unanimously (1 absent) we're perfectly in time :) [21:35] next: open bugs bug 424647 ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken URLs for e.g. gentoo-dev-announce and others"; Gentoo Infrastructure, Other; CONF; darkside:infra-bugs I think infra has bigger problems atm... [21:36] yeah no progress there agree, but how is this a council issue anyway? and no action by council we basically look at this every month and say, yes, it is a problem heh yeah [21:37] Either somebody volunteers to fix it, or maybe we beg the trustees to pay somebody to fix it for us we could remove council from cc let's do that and forget about the problem I don't think we're adding any value which problem? [21:38] :) dilfridge, the broken archives dilfridge: that we have no archives email archives ... :) pretty sure he was joking any objections against removing us from cc? no objections. [21:39] We should use discourse. :) ulm, i agree, remove us next, bug 477030 https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council I became impatient and wrote a summary :) [21:40] http://www.gentoo.org/proj/en/council/meeting-logs/20130611-summary.txt asking for approval here ulm, were you at the meeting? you should also have received the draft by e-mail blueness: yes okay then, do it [21:41] looks fine, imo I don't see any objections [21:42] I say go ahead so I'll add the link to the council page well i have not basis to disagree since i wasn't there finally, bug 503382 https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council but donnie is not here :( [21:43] so again no progress, I fear hm, there's another bug actually [21:44] bug 520074 ulm: https://bugs.gentoo.org/520074 "GLEP 39 rump council privilege escalation in secret meeting"; Doc Other, GLEP Changes; UNCO; wking:glep rich0: you've participated in the discussion there, so do you want to comment? [21:45] I think it is much ado about nothing. :) yeah, that's my impression too * WilliamH agrees from a theoretical pov he might have a point [21:46] Certainly our rules aren't airtight, but we only lead because everybody recognizes that we lead. actually, i had a secret meeting yesterday and voted to disband the council, so this is now mute but I doubt that it has any practical relevance moot yes... it's very much about codifying common sense, which is something you can spend all eternity on If we say something that 99% of devs disagree with, they'll just ignore us. shoudl we have a quorum for other reasons? Well, we already disband the council anytime half of us don't show up. [21:47] So, that seems to be overkill already. :) Right. yeah I don't care for the slacker rule at all, but that is a separate matter. any action? remove council from cc? yeah rich0: I would not mind adding that the council with <=50% attendance can't decide anything, but if that requires an eternal discussion on how to add something, I dont care. I don't object either, but then you get into the whole argument about who is allowed to edit GLEP 39 [21:48] exactly. dilfridge: it was handled that way when it occured * radhermit doesn't care that much, seems people have replied enough on the bug only once, in 2008 yes. I don't have an issue with just fixing it, but maybe the same folks who like the slacker rule might object. :) ok, I'll remove us from cc [21:49] next, open floor and we're still in time :) [21:50] meh right. [21:47:28] <_AxS_> done! official commendation to _AxS_ for revbumping all dev-perl to EAPI=5 :) woot! great :) * WilliamH agrees, that is good news that was a lot of work [21:51] That obosoletes perl-cleaner right? so am i to understand this correctly that we won't need perl-cleaner anymore not yet obsoletes * let's finish EAPI 6 so the perl team won't be put out of work :p WilliamH: there are some ebuilds left (not many), more complex apps that also install perl modules [21:52] dilfridge, what will perl-cleaner be needed for? i see once these are gone too, we'll ban EAPI<5 in perl-module.eclass then it's obsolete. what about perl virtuals? well, the new ones are also marked EAPI=5 [21:53] but there's no hurry there no eclass, nothing to rebuild i see (and the EAPI makes no difference) anything else for open floor? [21:54] seems not to be the case [21:55] next meeting will be on 2014-09-09 so I'll send the call for agenda items today [21:56] *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: Tuesday, 9 Sep 2014 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council"