summaryrefslogtreecommitdiff
blob: 1f579606f4e28f9afa87d8dfa2491dc952ec9301 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
[15:04:39] <rich0> roll call :)
[15:04:48] -*- dilfridge here
[15:04:56] -*- WilliamH here
[15:05:00] <rich0> blueness, dberkholz, scarabeus, ulm?
[15:06:14] <blueness> rich0, png
[15:06:21] <blueness> sorry almost forgot!
[15:06:25] <rich0> np :)
[15:06:32] <rich0> 3rd time might be the charm for finishing our term!
[15:06:38] <blueness> yep
[15:06:48] <rich0> Ok, let's get started and hopefully dberkholz, scarabeus, and ulm will catch up.
[15:06:55] <rich0> GLEP 64
[15:06:56] <blueness> yep
[15:06:59] <rich0> Err, GLEP 62.
[15:07:43] <rich0> Thoughs?
[15:07:46] <rich0> Thoughts?
[15:08:00] <rich0> https://wiki.gentoo.org/wiki/GLEP:62
[15:08:00] -*- WilliamH is looking for the glep
[15:08:19] <blueness> reading
[15:08:37] <rich0> mgorny: ping, FYI - your GLEP is under discussion...
[15:09:21] <rich0> I like the fact that it avoids polluting @world 
[15:09:46] <dilfridge> 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] <rich0> Well, it obviously isn't an actual implementation - more of a design.
[15:10:28] <dilfridge> yeah, sure,
[15:10:34] <rich0> I'd probably have this section updated once an actual implementation is done.
[15:10:44] <dilfridge> but I think this is more something that should come out of writing the code
[15:10:47] <dilfridge> exactly
[15:10:48] <blueness> dilfridge, yeah i don't see that as bad, its an outline of what IUSE_RUNTIME entails
[15:11:21] <rich0> So, we can approve the GLEP, except that the reference implementation can be updated once actually implemented.  :)
[15:11:24] <WilliamH> 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] <blueness> 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] <blueness> err ... not exactly
[15:11:54] <blueness> but some flag which pulls in perl
[15:11:56] <rich0> 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] <dilfridge> ulm had something to say about this
[15:12:57] <dilfridge> 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] <WilliamH> blueness: as an example, logrotate could be a use flag aas long as it were in IUSE_RUNTIME.
[15:13:28] <blueness> this is the point -> enabling or disabling any of the flags must not involve rebuilding the package,
[15:13:32] <dilfridge> exactly
[15:13:48] <blueness> okay i get it now, i'm okay with it
[15:13:56] <rich0> 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] <blueness> right
[15:14:17] <rich0> 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] <rich0> Any issues with the actual proposal?
[15:14:54] <blueness> not really, i also don't see the 'reference implementation' as a problem
[15:14:56] <rich0> 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] <dilfridge> 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] <WilliamH> Yes this is more of a roadmap.
[15:16:31] <dilfridge> 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] <rich0> Do we just want to approve it for EAPI6?
[15:16:53] <blueness> sure if we approve the gleb
[15:16:56] <blueness> glep
[15:17:03] <rich0> dilfridge: makes sense - I'd probably leave that up to the PMS/portage teams or the next council
[15:17:13] <blueness> 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] <rich0> 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] <rich0> That's the whole point of PMS.
[15:17:59] <dilfridge> not retroactively
[15:18:38] <rich0> 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] <rich0> So, the dependency would work fine, it would just trigger a rebuild when it changes.
[15:18:51] <dilfridge> 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] <rich0> So, in that sense it could potentially go into EAPI6 even if portage isn't ready.
[15:19:14] <dilfridge> (assuming that IUSE_RUNTIME is widely accepted)
[15:19:40] <dilfridge> hmm
[15:19:44] <rich0> If it gets rid of einfo spam, more power to it!  :)
[15:20:31] <rich0> 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] <dilfridge> we can add it to the list of planned EAPI6 features, yes
[15:20:55] <rich0> EAPI6 itself gets its real approval when PMS is submitted to the next council.
[15:21:26] <rich0> 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] <WilliamH> We should probably find out from the portage guys a rough idea of whether it will hold up EAPI 6?
[15:21:38] <rich0> That is why this isn't a final approval.
[15:22:25] <rich0> 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] <rich0> Granted, I guess they could still do that.  :)
[15:23:00] <blueness> WilliamH, who are the portage guys these days?
[15:23:00] <blueness> ie who's the lead?
[15:23:09] <dilfridge> blueness: dol-sen
[15:24:03] <rich0> 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] <blueness> rich0, let's add it, they can always amend later
[15:24:17] <rich0> blueness: ++
[15:24:23] <blueness> <mid-air!>
[15:24:29] <rich0> Really we're just saying htat it is "approvable"
[15:25:11] <dilfridge> sounds good
[15:25:16] -*- dilfridge approves
[15:25:22] <blueness> call the vote!
[15:25:33] <rich0> 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] <rich0> 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] <rich0> ok, passes 4-0 with 3 absent.
[15:26:27] <rich0> That brings us to bugs.
[15:26:33] <dilfridge> yawn
[15:27:24] <rich0> dberkholz: write your summaries!
[15:27:54] <rich0> blueness: I think the last one is yours?
[15:28:02] <blueness> which bug?
[15:28:12] <WilliamH> I need to ask a quick question about the rules of the glep though.
[15:28:13] <rich0> bug 477030
[15:28:14] <willikins> rich0: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
[15:28:26] <rich0> WilliamH: sure, we're just about at AOB anyway
[15:28:38] <blueness> rich0, all my summaries are posted afaik
[15:28:40] <blueness> let me look
[15:28:53] <rich0> you're right
[15:29:02] <WilliamH>  I guess my logrotate example is wrong, because of rule 3.
[15:29:09] <rich0> Unless you were responsible before you joined the council
[15:29:17] <rich0> 2013-06-11
[15:29:20] <rich0> It was the last council
[15:29:31] <rich0> I just was looking at your bug comment
[15:29:31] <dilfridge> betelgeuse
[15:29:50] <rich0> Ok, just say it three times and hopefully it will happen.
[15:29:56] <blueness> rich0, oh that was me being a newbie ;)
[15:29:57] <dilfridge> :D
[15:30:00] <WilliamH> I was thinking we could use this to reinstate use flags for things like logrotate, xinetd, etc.
[15:30:06] <dilfridge> brb
[15:30:29] <rich0> WilliamH: what is the problem with that?
[15:30:43] <rich0> Which rule 3?  flags listed in IUSE_RUNTIME must not be referenced in phase functions, DEPEND, LICENSE or SRC_URI,
[15:30:43] <rich0> ?
[15:30:53] <WilliamH> rich0: right.
[15:31:02] <rich0> why would logrotate be part of those phases?
[15:31:09] <rich0> It would be an RDEPEND.
[15:31:21] <WilliamH> if use logrotate; then
[15:31:29] <WilliamH> # install logrotate config files
[15:31:29] <rich0> You install the logrotate script unconditionally, and then pull in logrotate conditionally as an RDEPEND.
[15:31:30] <WilliamH> fi
[15:32:01] <rich0> This would only manage dependencies, not what actually gets installed.
[15:32:05] <rich0> That is the key to IUSE_RUNTIME.
[15:32:11] <WilliamH> rich0: logrotate isn't an rdepend, the package doesn't need it to run.
[15:32:28] <rich0> You don't use IUSE_RUNTIME with things the package NEEDS to run.
[15:32:39] <rich0> It is for things that optionally improve the package.
[15:32:48] <WilliamH> rich0: right, so you can't put logrotate in rdepend.
[15:32:49] <rich0> I need to dig up some examples.
[15:33:05] <rich0> WilliamH: why not?  It is a suggested dependency, basically.
[15:33:13] <floppym> I think it would be a bad idea to add IUSE_RUNTIME="logrotate systemd openrc ..." to every packages.
[15:33:29] <rich0> Myabe logrotate isn't a great example.
[15:33:34] -*- WilliamH agrees with floppym
[15:33:51] <rich0> 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] <floppym> net-misc/netctl is a good example.
[15:34:53] <rich0> Good one
[15:35:49] <rich0> systemd has some
[15:35:56] <rich0> sys-apps/systemd-ui: for GTK+ systemadm UI and gnome-ask-password-agent
[15:36:05] <rich0> dracut has a laundry list
[15:36:07] <dilfridge> logrotate is a bad example, since in that case the idea originally was to control installation of a small file
[15:36:27] <dilfridge> (which is not possible if you dont reinstall on switching useflag)
[15:36:32] <rich0> in this case it wouldn't be about controlling the file installation, but about pulling in logrotate itself.
[15:36:36] <dilfridge> yep
[15:36:50] <rich0> dracut is actually a pretty good example
[15:37:14] <rich0> http://pastebin.com/4cfwVqSb
[15:37:27] <WilliamH> 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] <rich0> Anything else on this?  I'm not hearing that we want to actually revisit the vote...
[15:38:54] <rich0> I'd definitely like to get to open floor this week!  :)
[15:39:22] <blueness> i'm good, this was more of a clarification for me
[15:39:42] <rich0> Sure, and the bonus of this is that it gives everybody more stuff to fight over in six months!
[15:39:42] <WilliamH> heh we can move on.
[15:39:57] <rich0> Thus ensuring we or our replacements still have a job to do...
[15:40:05] <rich0> Ok, open floor then.
[15:40:09] <rich0> And any other business.
[15:41:01] -*- rich0 enjoys the crickets...
[15:41:19] <dilfridge> let me just state that I think this was a productive year :)
[15:41:36] <blueness> i think so too
[15:41:44] <blueness> now i have to sit down and write my glep
[15:41:48] -*- WilliamH agrees
[15:41:54] <rich0> Yes, I was pretty happy with how things went.  
[15:42:49] <rich0> Ok, then I guess we'll wrap up.  It has been great serving with all of you!
[15:42:59] <WilliamH> Same here. :-)
[15:43:10] <blueness> Handshakes all around!
[15:43:16] <rich0> 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] <dilfridge> Yep, thank you all! same from me!
[15:43:59] <blueness> well some of us are running again so maybe we'll see one another again
[15:44:08] <blueness> <mid-air!>
[15:44:14] <rich0> 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] <blueness> WilliamH, i was going to ask jmbsvicetto that very question
[15:44:21] <blueness> the business that anyone can nominate did not turn out so bad
[15:44:31] <blueness> the fact that you *have* to accept stopped the madness
[15:44:49] <dilfridge> https://www.gentoo.org/proj/en/elections/council/2014/council-201406-nominees.xml
[15:45:05] <rich0> 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] <rich0> Lots of incumbents this year - we're gluttens for punishment!
[15:46:30] <rich0> err, gluttons
[15:46:46] <rich0> Good thing I'm not running on a platform of being an ispell replacement
[15:48:01] <rich0> Ok, well, we're officially dismissed.  I'll post the logs/summary.