[15:04:39] roll call :) [15:04:48] -*- dilfridge here [15:04:56] -*- WilliamH here [15:05:00] blueness, dberkholz, scarabeus, ulm? [15:06:14] rich0, png [15:06:21] sorry almost forgot! [15:06:25] np :) [15:06:32] 3rd time might be the charm for finishing our term! [15:06:38] yep [15:06:48] Ok, let's get started and hopefully dberkholz, scarabeus, and ulm will catch up. [15:06:55] GLEP 64 [15:06:56] yep [15:06:59] Err, GLEP 62. [15:07:43] Thoughs? [15:07:46] Thoughts? [15:08:00] https://wiki.gentoo.org/wiki/GLEP:62 [15:08:00] -*- WilliamH is looking for the glep [15:08:19] reading [15:08:37] mgorny: ping, FYI - your GLEP is under discussion... [15:09:21] I like the fact that it avoids polluting @world [15:09:46] I like the whole idea, I just think the detail description of the algorithm is not really making sense under "Reference implementation" [15:10:15] Well, it obviously isn't an actual implementation - more of a design. [15:10:28] yeah, sure, [15:10:34] I'd probably have this section updated once an actual implementation is done. [15:10:44] but I think this is more something that should come out of writing the code [15:10:47] exactly [15:10:48] dilfridge, yeah i don't see that as bad, its an outline of what IUSE_RUNTIME entails [15:11:21] So, we can approve the GLEP, except that the reference implementation can be updated once actually implemented. :) [15:11:24] I'm sure this was discussed and I missed it, why is this a glep instead of a feature for a new eapi? [15:11:26] rich0, i guess the point is if a package installs a perl script, you and you add IUSE_RUNTIME=dev-lang/perl then perl is NOT pulled in? [15:11:32] err ... not exactly [15:11:54] but some flag which pulls in perl [15:11:56] WilliamH: it wasn't discussed. Probably was just propsoed this way since GLEPs used to be the way these things were done. [15:12:21] ulm had something to say about this [15:12:57] as far as I can remember, his argument originally was "it's 100% backward compatible and could even in theory be added independent of eapi" [15:13:04] blueness: as an example, logrotate could be a use flag aas long as it were in IUSE_RUNTIME. [15:13:28] this is the point -> enabling or disabling any of the flags must not involve rebuilding the package, [15:13:32] exactly [15:13:48] okay i get it now, i'm okay with it [15:13:56] exactly - perl wouldn't be pulled in unless you enabled the perl USE flag. If you enabled it later then perl would be pulled in, but the package wouldn't rebuild. [15:14:14] right [15:14:17] If you disabled it later then perl isn't pulled in, though it won't go away if something else pulls it in, obviously [15:14:30] Any issues with the actual proposal? [15:14:54] not really, i also don't see the 'reference implementation' as a problem [15:14:56] There is the GLEP vs EAPI6 bit - probably does make more sense as part of the EAPI, though I'm not opposed to having the GLEP as well. [15:15:30] the "Reference implementation" section is not a problem, I just would not see it as "close to final", more as a roadmap [15:15:47] Yes this is more of a roadmap. [15:16:31] one suggestion would be, if an implementation in portage is ready in time, consider it for EAPI=6, otherwise postpone for later (this should not hold up the EAPI) [15:16:33] Do we just want to approve it for EAPI6? [15:16:53] sure if we approve the gleb [15:16:56] glep [15:17:03] dilfridge: makes sense - I'd probably leave that up to the PMS/portage teams or the next council [15:17:13] unless you think it will hold up eapi=6 and we don't want that [15:17:26] -*- WilliamH isn't in favor of retroactively applying it to older eapis either. [15:17:42] No, I'd just make it work for new EAPIs unless all the PMs chime in that it isn't an issue. [15:17:53] That's the whole point of PMS. [15:17:59] not retroactively [15:18:38] Granted, the proposal is basically designed to handle that - older PMs would ignore the IUSE_RUNTIME and just treat it as a use flag. [15:18:46] So, the dependency would work fine, it would just trigger a rebuild when it changes. [15:18:51] well, it's not an issue in terms of definition or functionality, just in matters of convenience (if a pm does not respect IUSE_RUNTIME people end up with an insane number of rebuilds) [15:19:14] So, in that sense it could potentially go into EAPI6 even if portage isn't ready. [15:19:14] (assuming that IUSE_RUNTIME is widely accepted) [15:19:40] hmm [15:19:44] If it gets rid of einfo spam, more power to it! :) [15:20:31] Ok, do we just want to include it in EAPI6 then? We can save appropving the GLEP until the rest of EAPI6 is ready to be approved? [15:20:50] we can add it to the list of planned EAPI6 features, yes [15:20:55] EAPI6 itself gets its real approval when PMS is submitted to the next council. [15:21:26] I think any of the items we included in EAPI6 are at the discretion of the PMS team if for whatever reason the PMs can't implement all of them. [15:21:34] We should probably find out from the portage guys a rough idea of whether it will hold up EAPI 6? [15:21:38] That is why this isn't a final approval. [15:22:25] WilliamH: I don't see this as a hard commitment to anything. This is just a process to get rid of EAPI6 items that we don't want so that people don't implement them only to have the next council reject them. [15:23:00] Granted, I guess they could still do that. :) [15:23:00] WilliamH, who are the portage guys these days? [15:23:00] ie who's the lead? [15:23:09] blueness: dol-sen [15:24:03] My personal recommendation would be to include, and then let the portage guys reject it later. Anything not implemented would be dropped from the final EAPI6. [15:24:10] rich0, let's add it, they can always amend later [15:24:17] blueness: ++ [15:24:23]

[15:24:29] Really we're just saying htat it is "approvable" [15:25:11] sounds good [15:25:16] -*- dilfridge approves [15:25:22] call the vote! [15:25:33] Ok, so how about "The council accepts IUSE_RUNTIME for implementation in EAPI6 as outlined in GLEP 62. The actual GLEP will be approved when EAPI6 is approved as part of PMS." [15:25:37] vote! [15:25:43] -*- rich0 yes [15:25:47] -*- blueness yes [15:25:53] -*- dilfridge yes for glep 62 [15:25:58] -*- WilliamH yes [15:26:11] ok, passes 4-0 with 3 absent. [15:26:27] That brings us to bugs. [15:26:33] yawn [15:27:24] dberkholz: write your summaries! [15:27:54] blueness: I think the last one is yours? [15:28:02] which bug? [15:28:12] I need to ask a quick question about the rules of the glep though. [15:28:13] bug 477030 [15:28:14] rich0: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council [15:28:26] WilliamH: sure, we're just about at AOB anyway [15:28:38] rich0, all my summaries are posted afaik [15:28:40] let me look [15:28:53] you're right [15:29:02] I guess my logrotate example is wrong, because of rule 3. [15:29:09] Unless you were responsible before you joined the council [15:29:17] 2013-06-11 [15:29:20] It was the last council [15:29:31] I just was looking at your bug comment [15:29:31] betelgeuse [15:29:50] Ok, just say it three times and hopefully it will happen. [15:29:56] rich0, oh that was me being a newbie ;) [15:29:57] :D [15:30:00] I was thinking we could use this to reinstate use flags for things like logrotate, xinetd, etc. [15:30:06] brb [15:30:29] WilliamH: what is the problem with that? [15:30:43] Which rule 3? flags listed in IUSE_RUNTIME must not be referenced in phase functions, DEPEND, LICENSE or SRC_URI, [15:30:43] ? [15:30:53] rich0: right. [15:31:02] why would logrotate be part of those phases? [15:31:09] It would be an RDEPEND. [15:31:21] if use logrotate; then [15:31:29] # install logrotate config files [15:31:29] You install the logrotate script unconditionally, and then pull in logrotate conditionally as an RDEPEND. [15:31:30] fi [15:32:01] This would only manage dependencies, not what actually gets installed. [15:32:05] That is the key to IUSE_RUNTIME. [15:32:11] rich0: logrotate isn't an rdepend, the package doesn't need it to run. [15:32:28] You don't use IUSE_RUNTIME with things the package NEEDS to run. [15:32:39] It is for things that optionally improve the package. [15:32:48] rich0: right, so you can't put logrotate in rdepend. [15:32:49] I need to dig up some examples. [15:33:05] WilliamH: why not? It is a suggested dependency, basically. [15:33:13] I think it would be a bad idea to add IUSE_RUNTIME="logrotate systemd openrc ..." to every packages. [15:33:29] Myabe logrotate isn't a great example. [15:33:34] -*- WilliamH agrees with floppym [15:33:51] I forget what the last package I installed was that had about 10 lines of einfo about useful stuff I could optionally install. [15:34:07] net-misc/netctl is a good example. [15:34:53] Good one [15:35:49] systemd has some [15:35:56] sys-apps/systemd-ui: for GTK+ systemadm UI and gnome-ask-password-agent [15:36:05] dracut has a laundry list [15:36:07] logrotate is a bad example, since in that case the idea originally was to control installation of a small file [15:36:27] (which is not possible if you dont reinstall on switching useflag) [15:36:32] in this case it wouldn't be about controlling the file installation, but about pulling in logrotate itself. [15:36:36] yep [15:36:50] dracut is actually a pretty good example [15:37:14] http://pastebin.com/4cfwVqSb [15:37:27] In that case, I would not suggest logrotate as a use flag still. [15:38:10] -*- WilliamH still doesn't like that we force users to use install_mask if they want to get rid of small files like that. [15:38:42] Anything else on this? I'm not hearing that we want to actually revisit the vote... [15:38:54] I'd definitely like to get to open floor this week! :) [15:39:22] i'm good, this was more of a clarification for me [15:39:42] Sure, and the bonus of this is that it gives everybody more stuff to fight over in six months! [15:39:42] heh we can move on. [15:39:57] Thus ensuring we or our replacements still have a job to do... [15:40:05] Ok, open floor then. [15:40:09] And any other business. [15:41:01] -*- rich0 enjoys the crickets... [15:41:19] let me just state that I think this was a productive year :) [15:41:36] i think so too [15:41:44] now i have to sit down and write my glep [15:41:48] -*- WilliamH agrees [15:41:54] Yes, I was pretty happy with how things went. [15:42:49] Ok, then I guess we'll wrap up. It has been great serving with all of you! [15:42:59] Same here. :-) [15:43:10] Handshakes all around! [15:43:16] Who knows, maybe a few of us will get to repeat the adventure. The lists are much quieter than they were last election. [15:43:18] Yep, thank you all! same from me! [15:43:59] well some of us are running again so maybe we'll see one another again [15:44:08]

[15:44:14] Ok, then we're officially done barring any emergencies, and anybody who can find me after the meeting is welcome to a free drink. :) [15:44:15] -*- WilliamH is curious how many have accepted their nomminations so far... [15:44:16] WilliamH, i was going to ask jmbsvicetto that very question [15:44:21] the business that anyone can nominate did not turn out so bad [15:44:31] the fact that you *have* to accept stopped the madness [15:44:49] https://www.gentoo.org/proj/en/elections/council/2014/council-201406-nominees.xml [15:45:05] blueness: yup - I raised the question just so that we didn't get any birthers after somebody gets elected and it is pointed out that no dev nominated them. :) [15:46:25] Lots of incumbents this year - we're gluttens for punishment! [15:46:30] err, gluttons [15:46:46] Good thing I'm not running on a platform of being an ispell replacement [15:48:01] Ok, well, we're officially dismissed. I'll post the logs/summary.