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
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
|
<blueness> time to start [19:54]
<blueness> agenda at
https://archives.gentoo.org/gentoo-dev-announce/message/106bd518b11a2e9700e7d77606cb7c23
[19:55]
<blueness> dilfridge: dilfridge|mobile jlec K_F rich0 ulm WilliamH
<blueness> wierd my computer says 4 minutes to the hour but my computers says
4 minutes after! [19:56]
<floppym> Sounds like you need to configure NTP on some of your computers.
[19:57]
* WilliamH is here, my clock is at 18:57 utc
<blueness> floppym: i do have ntp
<jlec> Same here
<blueness> there’s one central ntp server
<blueness> i think my one computer is off and everything is syncing off of it
<blueness> well it doesn’t hurt to wake people up a bit early [19:58]
<WilliamH> blueness: heh
<dilfridge> here [20:00]
<K_F> here
<jlec> Here
* jlec here
* WilliamH here [20:01]
<blueness> rich0:
<floppym> I'm proxying for ulm.
<blueness> ulm: is probably not going to show up
<blueness> oh okay floppym
<blueness> the agenda is here
https://archives.gentoo.org/gentoo-dev-announce/message/106bd518b11a2e9700e7d77606cb7c23
<blueness> so the first item is to look at the updates to glep 42 on news
items [20:02]
<blueness>
https://archives.gentoo.org/gentoo-dev/message/b9460b9c8d578c3498c217c17b75afd4
<blueness> ulm also has a prepared update to the glep page at
https://wiki.gentoo.org/wiki/User:Ulm/GLEP:42 [20:03]
<blueness> take a sec to look it over and then let’s discuss
<K_F> Hvae read through it and the changes seems to be in line with what we
have previously discussed, including some more definition on backwards
vs forwards compatible tool vs file format.. [20:04]
<jlec> I cannot spot anything wrong [20:05]
<jlec> Lgtm
<blueness> you can search for format 2.0 in the proposed wiki page which
nicely specifies the new featurs
<floppym> I do find it strange that we still cater to 80 column terminals, but
50 is certainly better than 44.
<blueness> i agree i can’t see anything wrong
<WilliamH> The changes look reasonable to me. [20:06]
<K_F> floppym: I rarely use more than 80 cols personally
<dilfridge> lgtm
<jlec> Please no 80 char discussion
<blueness> floppym: for git on gitweb 72+ chars is a problem
<floppym> Ah.
<blueness> so there are still places where the are problems
<floppym> I was just making a comment; no real objection here.
<blueness> lol jlec okay
* dilfridge bites the ears off a chocolate bunny
<blueness> heh [20:07]
<blueness> are we ready for a vote then?
<jlec> Yes
<blueness> okay “Accept proposed changes to GLEP 42”?
* blueness yes
* WilliamH yes
* dilfridge yes
<floppym> I vote yes, to accept the changes.
* K_F yes
* jlec yes [20:08]
<blueness> unanimous with one missing rich0
<blueness> wow that was easy
<blueness> okay next item
<blueness> 3. Historical behaviour vs PMS (see above)
<dilfridge> ok one remark from me [20:09]
<K_F> as a point of order I suggest we don't have any decisions /votes today,
but a discussion
<jlec> ulm: thanks for your work on glep 42
<dilfridge> I suggest that in any case improving PMS should be also considered
as option.
<dilfridge> (Not just adapting code to current PMS.)
<K_F> dilfridge: certainly, improving PMS might very well be an outcome of
mismatches [20:10]
<dilfridge> yeah, this is not clear from the text that I submitted.
<WilliamH> Which mismatches are we specifically talking about?
<dilfridge> All of them. :)
<K_F> the important thing is that the specs and reality matches, which one is
out of sync will have to be discussed case by case
<blueness> dilfridge regarding point 3?
<dilfridge> well... [20:11]
<dilfridge> when we're talking about time frames,
<WilliamH> If we are talking about the multislot uselfag issue, kill it hard
;-)
<dilfridge> and deadlines,
<dilfridge> I would rather have a shorter deadline (say 6 months) with the
proviso that anything planned to go into next EAPI is exempt
[20:12]
<WilliamH> The slot variable should be a static string not dependent on a use
flag.
<dilfridge> WilliamH: totally agree with you in that point
<blueness> can i suggest something, i think those points are too harsh, i’d
like to track the mismatches between specs and package managers,
but then deal with each mismatch on an ad hoc basis, because we can
change PMS too
<blueness> we don’t want to throw out the baby with the bath wather
<blueness> water
<K_F> WilliamH: yeah, that one is likely the easiest to decide on
<K_F> blueness: exactly [20:13]
<floppym> I'm really not sure how a deadline could be applied generally.
<K_F> would need to be a case by case basis
<dilfridge> ok so let me try to re-write the three points
<floppym> It really depends on the nature of the mismatch and the people
involved.
<blueness> if we find a mismatch, we may want to include the undocumented
behavior in PMS rather than vice versa
<blueness> so it has to be ad hoc
<dilfridge> 1) All non-PMS-conformant behaviour should be considered a bug,
and package / eclass / package manager / PMS maintainers should
work together and to achieve consistent behaviour. [20:14]
<jlec> If there is take me to solution then things are easy in case there's
none we will have a problem
<jlec> *technical
<dilfridge> s/and to/and strive to/
<K_F> dilfridge: should it be specified .. bug (either in specs or
implementation) [20:15]
<K_F> to avoid ambiguity?
<dilfridge> well, I left it open deliberately
<mgorny> i don't think we can put a generic rule for this
<mgorny> discouraging use of non-PMS compliant behavior if people don't even
try to get it into PMS would be good though [20:16]
<K_F> mgorny: well that is just a general point, and in principle it is
sound.. just that we need to go through case by case basis to see
whether PMS needs updating or the behavior does..
<mgorny> i'd say for each behavior, there are three possibilities:
<dilfridge> 2) We encourage the creation of trackers to identify and collect
non-PMS-conformant behaviour and propose fixes.
<mgorny> a. bad behavior, we deprecate and kill it; b. good behavior, we get
it into future EAPI and encourage updating ebuilds, c. intended
behavior, we get it into all EAPIs [20:17]
<dilfridge> yep
<blueness> mgorny: there is yet a fourth, an ambiguity in PMS specs which
happens enough and also leads to discussion
<jlec> But that sounds like b [20:18]
<K_F> well, either a or b depending on situation :)
<jlec> I was optimistic [20:19]
<blueness> i’m not sure they’re mutually exclusive, but we get different
behaviours between paludis, portage, pkgcore and PMS specs
<jlec> That's a different thing. Ebuilds and eclasses should only depend on
pms [20:20]
<blueness> because each will read PMS differently, we had that with
=cat/pkg-2.* vs =cat/pkg-2*
<WilliamH> agreed
<jlec> That's what this is all about
<blueness> are we talking just ebuids/eclasses here?
<K_F> blueness: if there are other known issues I suggest we include them in
scope [20:21]
<jlec> What else?
<K_F> blueness: but the specific ones that have already been brought up are
ebuilds/eclass related
<blueness> if we’re just talking multislot that’s pretty much gone
<WilliamH> Aren't we just talking about compliance with pms?
<xiaomiao> WilliamH: or PMS matching reality [20:22]
<dilfridge> 3) The council recognizes that historically there has been a lack
of cooperation; there is however no current reason why that should
continue. If in any specific issue no progress at all is reached
within 6 months, finding the best technical solution is delegated
to QA.
<K_F> dilfridge: finding the solution is delegated meaning they propose a
solution for council vote or implement it directly? [20:23]
<dilfridge> well, pms changes need to be approved by council
<dilfridge> ebuild changes need to be approved by maintainer
<dilfridge> qa can overrule maintainer but likely not council [20:24]
<mgorny> yes, strictly speaking qa can override maintainer per the current
rules
<mgorny> and the maintainer can appeal to the council if he disagrees
<blueness> dilfridge let me understand the politics here, are we just trying
to make a policy cover future situations like multislot?
[20:25]
<dilfridge> blueness: we're trying to get rid of a historical stalemate
<K_F> blueness: and/or investigate whether other mismatches exists
<WilliamH> As a member of qa I would mask the multislot use flag right now if
I felt comfortable doing it ;-)
<K_F> and indeed, setting a presedence for how to deal with it going forwards
if one is detected (it is bound to in some way) [20:26]
<WilliamH> Masking the use flag is in the scope of qa as the rules are right
now.
<floppym> WilliamH: Masking the use flag would not be helpful if use is fatal
in global scope.
<dilfridge> blueness: basically, half of gentoo treating PMS as "the spec" and
some of gentoo treating PMS as "that funny stuff imposed on us by
ciaranm"
<dilfridge> so, to break out of this we need to 1) make sure reality and PMS
agree, 2) make sure that it really is the definitive spec
[20:27]
<mgorny> once you're done with the generic problem, we should probably decide
how to proceed with multislot
<dilfridge> mgorny: I already have a headache. [20:28]
<K_F> my suggestion is no decision on single issue today
<dilfridge> just mask it(tm)
<blueness> dilfridge: thanks i misunderstood where this was coming from. i
don’t mind the specs lagging behind the package managers and
ebuilds/eclasses, so let’s just say that bugs have to be opened
where the specs don’t match either and these have to be dealt with
in a timely fashion else it escalates to QA first and then the
council
<K_F> each individual issue should be presented on a case-by case basis and
discussed with pros and cons on ML before a vote
<WilliamH> K_F: that sounds reasonable. I do think we should open a tracker
too though for the issues. [20:29]
<K_F> WilliamH: yeah, and/or tracker
<floppym> I like the idea of a documented escalation process for these kind of
issues; though I thouht we already had that.
<WilliamH> floppym: I think we basically do. [20:30]
<blueness> floppym: we have that
<blueness> its like anything else
<blueness> we’re not voting today, are we? [20:31]
<WilliamH> I don't think we are
<K_F> blueness: we can vote on procedure
<K_F> but I recommend not voting on a single issue
<dilfridge> no single issues
<blueness> ah okay, dilfridge can we consolidate your 3 points into one
statement, I can suggest something if you like [20:32]
<dilfridge> one moment
<blueness> dilfridge: take your time, i’ll wait for you
<WilliamH> wrt multislot, I have a better idea. [20:34]
<dilfridge> well, here's the combined text with only one small change
(s/finding/proposing/):
<K_F> WilliamH: if we set up a discussion for it we can take it in tracker /
ML perhaps?
<dilfridge> All non-PMS-conformant behaviour should be considered a bug, and
package / eclass / package manager / PMS maintainers
<dilfridge> should work together and to achieve consistent behaviour. We
encourage the creation of trackers to identify and
<dilfridge> collect non-PMS-conformant behaviour and propose fixes. The
council recognizes that historically there has been a
<dilfridge> lack of cooperation; there is however no current reason why that
should continue. If in any specific issue no progress
<dilfridge> at all is reached within 6 months, proposing the best technical
solution is delegated to QA.
<mgorny> WilliamH: please talk about multislot separately [20:35]
<WilliamH> mgorny: ok
<K_F> dilfridge: s/and to/in order to/ perhaps?
<blueness> dilfridge: that sounds fine, how do we promulgate that? email
gentoo-dev@g.o ?
<dilfridge> K_F: where?
<WilliamH> blueness: just send it to -dev and maybe -project? [20:36]
<blueness> WilliamH: 1 sec, let’s get this language out of the way?
<K_F> dilfridge: "should work together and to achieve consistent behaviour."
<WilliamH> blueness: sure
<WilliamH> K_F: s/and to/to/
<K_F> that also works..
<blueness> how do people feel about this? are we ready for a vote module the
minor lanuage chagnes? [20:37]
<dilfridge> wait
<dilfridge> new version:
<blueness> k
<dilfridge> ll non-PMS-conformant behaviour should be considered a bug, and
package / eclass / package manager / PMS [20:38]
<dilfridge> maintainers should work together and strive to achieve consistent
behaviour. We encourage the creation of
<dilfridge> trackers to identify and collect non-PMS-conformant behaviour and
to propose fixes. The council recognizes
<dilfridge> that historically there has been a lack of cooperation; there is
however no current reason why that should
<dilfridge> continue. If in any specific issue no progress at all is reached
within 6 months, proposing the best
<dilfridge> technical solution is delegated to QA.
<jlec> 6 month means busy summer. I are we sure the time frame is good?
<dilfridge> (insert "A" at start)
<floppym> So the guts of this is the 6 month deadline. The rest is just
reaffirmation of pretty obvious stuff.
<K_F> jlec: 6 months should be sufficient even with summer involved
<K_F> jlec: that is also just a deadlock limit, if there is progress it
doesn't hit
<jlec> Mmh, okay [20:39]
<blueness> if people are acting in good faith, we can consider relaxing 6
months for thorny issues
<jlec> Lgtm
<K_F> I'm fine with that statement
<blueness> i’m okay with the 6 month limit [20:40]
<blueness> are we ready for a vote, any other comments?
<K_F> I'm ready for vote [20:41]
* jlec yes
<blueness> okay “The council moves to adopt the above policy”?
* blueness yes
* dilfridge yes
* WilliamH yes [20:42]
* K_F yes
* jlec yss
<floppym> I abstain.
<blueness> passes, 5 yeses, 1 abstain, 1 missing
<blueness> rich0: are you around?
<blueness> okay do we want to discussion multislot now?
<WilliamH> Here's my thought. [20:43]
<K_F> that is just one of the other single issues, so it should be discussed
in tracker bug for it and/or ML
<WilliamH> Let me open bugs on the issue assigned to maintainers and cc
qa/council.
<blueness> go ahead, its slightl off agenda, but we have some time and we’ll
have to discuss it sooner or later
<WilliamH> I'll ask the maintainers to remove the use flag.
<WilliamH> and add that if they do not qa / council has authorized its removal
in 30 days. [20:44]
<K_F> that would require a vote
<mgorny> errr
<mgorny> but we already have a decision wrt multislot
<mgorny> and the discussion
<dilfridge> afaik long ago already there was a qa decision about multislot
<K_F> open the bug as part of tracker for the overall discussion [20:45]
<WilliamH> hang on folks let me pull up something
<dilfridge> just noone pushed it through so far
<mgorny> last month council decided today's deadline for maintainers applying
it
<blueness> mgorny: i haven’t looked but didn’t vapier remove multislot from
toolchain.eclass?
<dilfridge> right :D
<mgorny> blueness: nah
<mgorny> but he proposed a patch
<blueness> never mind, just looked, its still there
<blueness> ah that’s what it was [20:46]
<mgorny> so i wanted to suggest we just apply it or talk to him about applying
it
<K_F> blueness: binutils was changed
<mgorny> blueness: you seemed to be against it
<WilliamH> K_F: what they are doing violates this:
https://devmanual.gentoo.org/general-concepts/portage-cache/index.html
<mgorny> or did i understand your comment wrong?
<blueness> mgorny: not exactly gainst it, i was thinking a different approache
<blueness> he’s going to just turn multislot on always, i wanted it off always
<K_F> WilliamH: I'm aware.. there are still good ways and bad ways of
enforcing it [20:47]
<blueness> but i can live with his solution
<K_F> WilliamH: and it has been around for so long, another few weeks isn't
going to kill anyone, at least do it in a civil manner
* mgorny actually uses multislot, so on always sounds better to me
<WilliamH> I don't have a problem with it being on or off for everyone, just
make a decision either way ;-)
<floppym> It's really up to toolchain how they want to slot it.
<blueness> mgorny: like i said, i can live with it on always
<mgorny> blueness: can you handle this as toolchain member? [20:48]
<blueness> mgorny: i could but i alway defer to vapier
<WilliamH> The issue is that SLOT= can't be dynamic.
<blueness> let’s see if he’s just not going to do it, and if he isn’t then
i’ll step in like i did with glibc
<floppym> WilliamH: I think we are all on the same page on the technical side.
<WilliamH> All I'm asking for is for them to make up their mind ;-) [20:49]
<jlec> Guys, we don't need to discuss this. It needs to go and we know it.
<dilfridge> ++
<mgorny> blueness: could you then talk to him? i think he just needs a
reminder/push/whatever
<WilliamH> either they do it in a reasonable amount of time or qa does it then
they fix it without the use flag. :-) [20:50]
* WilliamH agrees with mgorny
<blueness> mgorny: i can
<floppym> What's left on the agenda?
<blueness> okay guys, i think enough discussion on multislot, i’ll email
vapier and say, let’s get it done!
<blueness> okay guys, i think we’re done here last item [20:51]
<blueness> Bugs with council involvement
https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3101194&query_format=advanced
* ulm is here
<ulm> floppym: just go on, I'm reading the backlog
<blueness> ulm: welcome! [20:52]
<jlec> Don't kick him out
<jlec> He really did a good job
<K_F> I don't understand why council is involved in #575534
<blueness> okay 575534 is wierd [20:53]
<blueness> lol!
<blueness> K_F: jinx
<blueness> okay let me take care of that one right now
<K_F> missing logs in two bugs, who chaired? [20:54]
<blueness> i’m going to ask that a3li and mgorny work it out between
themselves before escaating
<floppym> For what its worth, I hate it when I get a degraded experience on
mobile too.
<floppym> It's very annoying.
<floppym> (speaking generally, not just about our wiki) [20:55]
* mgorny has done enough random gentoo project and certainly isn't going to
patch this nonsense
<K_F> dilfridge: seems both are yours :)
<dilfridge> :/ meh
<mgorny> and a3li is pretty much 'mgorny does not like it, so i'm going to
ignore this'
*** viaCrucis (~scott@91.33.233.220.static.exetel.com.au) has joined channel
#gentoo-council
* WilliamH isn't sure why that was assigned to council
<K_F> WilliamH: it shouldn't have been [20:56]
<WilliamH> There's not a lot we can do there.
<blueness> mgorny: QA can mask the package if its bad enough!
<floppym> Is that a bad joke?
<jlec> Mask the wiki? [20:57]
* floppym masks bluness' sens of humor
<blueness> floppym: yes it is
<mgorny> well, the council is the entity which decides that wiki is the
official doc channel
<WilliamH> mgorny: yes, but we didn't mandate anything about which wiki
software to use etc. [20:58]
<K_F> or triaging of bugs within infra
<blueness> what about bug #574952 mgorny what would you like us to do with
that since games + QA have been at it for a while
<willikins> blueness: https://bugs.gentoo.org/574952 "Games team intentionally
ignoring messages and bugs in order to stall QA and Council";
Community Relations, Developer Relations; CONF; mgorny:comrel
<K_F> this is a regular bug report like any other
<mgorny> yes, www stuff is pretty much a3li deciding whatever he wants by
himself and with no respect to other developers
<blueness> similarly bug #574080 [20:59]
<willikins> blueness: https://bugs.gentoo.org/574080 "games.eclass: Path
customization needs to be removed wrt 20151213 Council meeting";
Gentoo Linux, Eclasses and Profiles; CONF; mgorny:games
<mgorny> blueness: that's comrel problem, i'd say
<blueness> yeah
<mgorny> council CC-ed because it was involved and may want to track events
<mgorny> and/or be inquired
<floppym> mgorny: I think we can't really force a3li to implement something,
but if you find someone else who can do the work we can stop him
from blocking it if necessary. [21:00]
<a3li> wtf?!
<a3li> I said I accept your issue
<blueness> the a3li might escalate there, but let’s see
<blueness> i agree with trakcing the games stuff since its a big issue
<blueness> floppym: i was going to suggest something like that
<blueness> someone to supply a patch
<a3li> also, what's with the borderline slanderous comments mgorny is allowed
to make her?!°
<blueness> a3li: i don’t like those comments either but can you and mgorny
just stick to the technical issues wrt to that pkg [21:01]
<a3li> that's very hard when I get shit shoveled at me at any occasion, you
know
<blueness> a3li: i understand. so just take a break from it and don’t think
you’re isolated here. [21:02]
<a3li> I'm not. I think someone else isolates himself with inane commentary
atm. [21:03]
<K_F> in any case, I don't see any more for council to do with open bugs so
propose we close today's meeting [21:05]
<blueness> mgorny: still not sure how to proceed with the games stuff there
are 3 bugs there with council involvement
<K_F> a3li: and yeah, I didn't like those comments either..
<blueness> K_F: open floor i have one quick announcement
<mgorny> well, the eclass is deprecated, i thnk
<mgorny> games team doesn't bother replying on the topic
<blueness> okay well continue with the stalement? [21:06]
<jlec> Then have QA set a deadline and remove it with all usages [21:07]
<dilfridge> I guess all the deadlines are over anyway and it just needs
someone to do the actual work.
<blueness> yeah
<ulm> right, maybe best if qa takes care of the technical issues [21:08]
<mgorny> well, i wouldn't feel good rewritting packages maintained by games
team for this
<blueness> mgorny: i’m going to bounce this back to QA to decide what do to
<mgorny> esp. that they didn't really approve any of it
<blueness> ulm: +1
<ulm> and avoid filing bugs with "games team intentionally ignoring ..." in
the summary
<ulm> that's not going to lead anywhere
<blueness> ulm: +1 again, they’re just not listening
* WilliamH agrees
<K_F> blueness: I wouldn't outright listen to such statements either, tend to
get the deaf ear.. [21:09]
<K_F> so yeah, keep the bug reports factual and neutral in nature
<WilliamH> agreed [21:10]
<K_F> in particular if involving council...
<mgorny> you could complain if they didn't admit it
<blueness> mgorny: maybe QA can create an overlay and move all the deprecated
stuff there and then put the onus on games to move it back into the
tree in a compliant fashion … i know, its work!
<blueness> mgorny: ^^^ as K_F said, please try to avoid the ad hominems
<blueness> QA needs to be a policy force and at least appear neutral
<blueness> okay let’s move on, i don’t want to get mired in this [21:11]
<blueness> final point i’ll comment on bug #568068 our decision today
<willikins> blueness: https://bugs.gentoo.org/568068 "GLEP 42: Define support
for EAPI 5 dependency atoms in news items"; Doc Other, GLEP
Changes; IN_P; floppym:glep
<blueness> anything else before opne floor
<blueness> okay open floor [21:12]
<blueness> i have one annoucnement
<blueness> last council meeting we spoke about hasufell’s pkgs and work
<WilliamH> There already is a graveyard overlay I think; I don't know who
maintains it.
<WilliamH> sorry go ahead blueness
<blueness> i’ve started a libressl project and we have dilfridge soap and zn2x
(forget his nick!) on board [21:13]
<K_F> I expect that to be zx2c4
<dilfridge> r2d2
<blueness> K_F: ty!
<floppym> Any long-term goal for that project? Are you aiming to replace
openssl, or just provide a perpetual alternative? [21:14]
<blueness> anyhow, we’ll have a plan for moving forward and we’ll at least
inform the council
<blueness> floppym: the basic goal is two provide two system wide alternatives
<blueness> either you have an all libressl system or all openssl
<blueness> openssl will not be replaced in any way, just a permanent
alternative [21:15]
<floppym> Ok. That's the safer route for sure; I was kind of hoping for a more
entertaining conflict. :P
<blueness> two steps 1) getting it into the tree 2) provide support to
maintainers who have packages that depend on openssl so we offset
any extra work regarding abi mismatches
<blueness> floppym: lol no!
<blueness> floppym: i think openssl has actually benefited from libressl just
being an alternative [21:16]
<blueness> anyhow, we’ll meet and report back
<K_F> blueness: sounds good
<floppym> Competition tends to spur innovation, yes.
<blueness> nothing else for now, just FYI
<blueness> floppym: that’s the idea!
<blueness> okay if theres nothign more we’re done! [21:17]
<K_F> thanks for chairing
<blueness> np
<blueness> oh crap … ulm are you there? did you log this? can anyone send
me the logs?
<ulm> floppym: thanks for proxying
<blueness> anyhow meeting over [21:18]
|