diff options
| -rw-r--r-- | meeting-logs/20171008.txt | 408 | ||||
| -rw-r--r-- | meeting-logs/20171008.txt.asc | 19 |
2 files changed, 427 insertions, 0 deletions
diff --git a/meeting-logs/20171008.txt b/meeting-logs/20171008.txt new file mode 100644 index 0000000..1c662b5 --- /dev/null +++ b/meeting-logs/20171008.txt @@ -0,0 +1,408 @@ +[20:05:34] <dilfridge> !proj council +[20:05:34] <willikins> (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh +[20:05:37] <dilfridge> roll call! +[20:05:41] -*- K_F here +[20:05:42] -*- mgorny here +[20:05:44] -*- dilfridge here +[20:05:46] -*- WilliamH here +[20:06:20] -*- slyfox here +[20:06:55] <K_F> let me send SMS to ulm +[20:07:05] <mgorny> he was around 15 minutes ago +[20:07:12] <WilliamH> tamiko: ping? +[20:08:07] <dilfridge> :/ I have only a german mobile number of tamiko, but he likely won't use that when he's in the us +[20:08:33] -*- ulm here +[20:08:35] <ulm> sorry +[20:08:45] <K_F> :) +[20:08:57] <ulm> K_F: thanks +[20:08:59] <dilfridge> ok let's wait one more minute for tamiko +[20:09:02] <dilfridge> then start +[20:09:12] <mgorny> !time tamiko +[20:09:12] <willikins> mgorny: America - Chicago - Sun Oct 08 13:09 CDT +[20:09:42] <dilfridge> he told me something about being super-busy, but that's all I know +[20:10:22] <K_F> proxy is always an option in that case +[20:10:23] * dilfridge has changed topic for #gentoo-council to: "Next meeting: 2017-10-08 18:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171008T18 | https://wiki.gentoo.org/wiki/Project:Council | https://dev.gentoo.org/~dilfridge/decisions.html | Agenda: https://archives.gentoo.org/gentoo-project/message/9e0202b2929921b62fa0bddcd4ca20dd" +[20:10:28] <dilfridge> ok +[20:10:31] <dilfridge> let's start +[20:10:36] <dilfridge> agenda is in the link +[20:10:42] <dilfridge> first topic, +[20:10:52] <dilfridge> 2. Briefly revisit the status of HPPA [1] +[20:11:07] <dilfridge> so who knows? +[20:11:10] <mgorny> i have heard only positive comments +[20:11:14] <slyfox> hppa is slowly going through stable backlog +[20:11:31] <slyfox> (security issues first, quite a few are left still) +[20:12:08] <slyfox> and (not too relevant) we've got one new hppa user on #gentoo-hppa :) +[20:12:24] <slyfox> <end of status> +[20:12:24] <dilfridge> heh +[20:12:37] <dilfridge> let's recruit! +[20:13:03] <dilfridge> anyway... to me that sounds like there's nothing to do at the moment? +[20:13:04] <mgorny> well, i've asked security team and ChrisADR said they think hppa is doing fine (if i recall correctly) +[20:13:14] <dilfridge> (for us) +[20:13:17] <mgorny> yes +[20:13:35] <WilliamH> sounds fine to me. +[20:13:53] <K_F> blueknight mentioned he was going to be around for today's meeting, just pinged him +[20:14:29] <dilfridge> ok as long as there are no other comments... +[20:14:50] <dilfridge> let's go to the next topic! \o/ +[20:14:53] <slyfox> \o/ +[20:15:01] <dilfridge> 3. The big GLEP reform -- [2] for importing new GLEPs, [3] for GLEP 1/2 updates +[20:15:23] <dilfridge> ulm: mgorny: that's your baby +[20:15:34] <ulm> mgorny's mainly +[20:15:46] <mgorny> well, i think we've done all that could be done to prepare it and it's waiting for the official stamp now +[20:16:09] <dilfridge> I've read the changes to GLEP 1/2 and I think it's good +[20:16:20] -*- WilliamH is fine with the changes +[20:16:37] <mgorny> software and infra is practically ready for deployment +[20:17:15] <dilfridge> imho it makes no sense to split this up in any way, so essentially we should only vote on the whole package +[20:17:28] <mgorny> i agree +[20:17:32] <ulm> wfm +[20:17:51] <mgorny> the split was mostly to account for the silent modifications done by glep editors +[20:17:54] <ulm> mgorny: any reply from the GLEP editor? +[20:18:08] <mgorny> nope, weren't able to get a word out of him +[20:18:32] <dilfridge> haven't heard from chris for a while +[20:18:34] <mgorny> (though i admit i didn't remember to try very hard) +[20:18:55] <ulm> mgorny: maybe add original-author to the commit message where appropriate +[20:19:13] <mgorny> wfm +[20:19:46] <dilfridge> ok does anyone else want to say something about this topic? +[20:19:47] -*- kent\n points out you can forge committer and author attributes of commits of that makes more sense +[20:20:01] <mgorny> https://bugs.gentoo.org/628098#c2 +[20:20:09] <mgorny> that's the only comment from him i know of +[20:20:14] <ulm> kent\n: not sure, it's not the same +[20:20:25] <ulm> one if mediawiki syntax, the other is rst +[20:20:27] <ulm> *is +[20:20:45] <mgorny> he didn't sound very happy but i'm not sure if it was because of the change, or merely because he didn't want to do the work +[20:21:01] <slyfox> is there 2-sentence Tl;DR: on what is the current GLEP state (CVS+wiki? what is the authoritative source) and what will change? (repos added, removed?) +[20:21:05] <K_F> mgorny: I read the comment as the latter +[20:21:34] <mgorny> slyfox: current state is wiki is authoritative +[20:21:36] <ulm> slyfox: wiki is authoritative according to GLEP 1 +[20:21:50] <mgorny> we've changing this to a git repo that's ~ conversion of wiki +[20:21:57] <mgorny> except for a few reverts of wiki changes +[20:22:11] <slyfox> aha. sounds good +[20:22:12] <mgorny> (like replacing 'devrel' for 'ComRel' in some old GLEP) +[20:22:55] <mgorny> from user's perspective, gleps will be part of www.gentoo.org site +[20:23:18] <mgorny> from dev's perspective, he will write them in rst (like old times) and push to git repo afterwards +[20:23:58] <slyfox> *nod* +[20:24:19] <K_F> in any case, the way I see it mgorny and ulm has done a good job with this one, I don't have any further comments +[20:24:34] <dilfridge> so are we ready for a vote? +[20:24:34] <dilfridge> we would vote on two things together, +[20:24:34] <dilfridge> a) confirm the conversion, see https://bugs.gentoo.org/show_bug.cgi?id=630882#c3 +[20:24:34] <dilfridge> b) confirm the changes to GLEP 1/2, https://bugs.gentoo.org/show_bug.cgi?id=631338 +[20:24:49] <mgorny> lemme paste a link to the repo +[20:25:32] <mgorny> https://github.com/gentoo/glep-draft/tree/gleps-new-format +[20:25:37] <mgorny> this is the final version we're voting on +[20:25:46] -*- b-man apologizes for missing the initial request for HPPA related items. I will await the open floor. +[20:25:55] <K_F> we should have a non-github link for archive purposes +[20:25:59] <mgorny> i.e. all converted to rst, with glep1/2 updated and headings updated +[20:26:06] <K_F> are there changes from the patchset at https://archives.gentoo.org/gentoo-project/message/cb1473c75ad329d48b6c21025f9ac2b6 ? +[20:26:08] <mgorny> i will push it to git.g.o afterwards +[20:26:15] -*- WilliamH agrees with k_f wrt non-github +[20:26:33] <mgorny> K_F: i think not +[20:26:40] <mgorny> ulm: are you aware of any? +[20:26:51] <mgorny> K_F: ofc besides reformatting headers +[20:27:10] <K_F> headers aren't important , so thats fine +[20:27:13] <mgorny> (to conform to new version of GLEP1) +[20:27:16] <ulm> mgorny: some minor cosmetical changes maybe +[20:27:20] <K_F> oh, those headers.. +[20:27:30] <ulm> like changing tabs to spaces in the header +[20:28:32] <K_F> I generally prefer tabs over spaces, but this is the PEP conformity changes? +[20:28:39] <dilfridge> we can document here in the log where you will push it, then we have a permanent non-github link +[20:28:44] <dilfridge> mgorny: ^ +[20:29:07] <mgorny> https://gitweb.gentoo.org/data/glep.git/ +[20:29:10] <mgorny> this is the target repository +[20:29:13] -*- WilliamH tends to prefer tabs also +[20:29:15] <mgorny> (it currently matches old cvs) +[20:29:30] <dilfridge> oh come on, please no tabs-vs-spaces discussion now! +[20:29:37] <slyfox> +1 +[20:29:38] <mgorny> K_F: spaces are kinda implied by rst +[20:29:56] <mgorny> i've mostly used them because that's what old gleps did +[20:30:17] <K_F> thats a good argument in its own merits, fine by me +[20:30:36] <WilliamH> I find spaces harder to work with, it is harder to align things. +[20:30:42] <ulm> the old (cvs) glep 2 answers the spaces vs tabs question already, and we haven't changed anything there +[20:31:14] <Soap__> tbh, hppa has improved +[20:31:25] <Soap__> and this is me as a minor-arch-hater saying this +[20:31:33] <K_F> Soap__: its not in scope for the current discussion +[20:31:46] <K_F> please keep comments to open floor +[20:32:06] <mgorny> anything else or can we vote now? +[20:32:12] <K_F> I'm fine with vote +[20:32:26] <dilfridge> let's vote +[20:32:29] -*- slyfox votes yes +[20:32:35] -*- mgorny yes +[20:32:37] -*- dilfridge yes +[20:32:38] -*- WilliamH yes +[20:32:41] -*- K_F yes +[20:32:47] -*- ulm yes +[20:32:57] <dilfridge> and tamiko is absent +[20:33:00] <dilfridge> so unanimous +[20:33:13] <dilfridge> next topic! +[20:33:23] <dilfridge> 4. The Git pre-GLEP [4] +[20:33:36] <WilliamH> It looks reasonable to me. +[20:34:34] <mgorny> i think we can discuss it now and then do a quick confirmation vote by bug when it gets converted to rst and pushed +[20:35:30] <mgorny> it might be subject to later changes as infra evolves and so on but i think it's quite accurate on how to do things with git +[20:35:55] <mgorny> and if we have a proper glep in place, we can finally get to preparing one consistent documentation +[20:36:27] <dilfridge> mgorny: one small comment, +[20:36:44] <dilfridge> specifying bug numbers in the summary line should be done in one of the formats triggering willikins +[20:36:54] <dilfridge> so, "bug xxxxx" or "bug #xxxxx" +[20:37:03] <dilfridge> not just "#xxxxxx" +[20:37:15] <mgorny> oh, i didn't think of that, good idea +[20:38:05] <mgorny> K_F: you seemed to have most concerns +[20:38:17] <dilfridge> brb food delivery .) +[20:38:29] <K_F> mgorny: I found the discussions useful, I'm fine with the current state after getting some clarification +[20:39:07] <mgorny> ok, anyone else having comments? +[20:39:16] <K_F> one comment, which is more on tooling than the glep +[20:39:28] <K_F> we should add some convenience tags to repoman , e.g to add bug information +[20:39:56] <K_F> so we don't have to write out the URLs by hand on each commit +[20:40:20] <mgorny> K_F: it's there for half a year already, or so ;-) +[20:40:22] <mgorny> --bug and --closes +[20:40:33] <K_F> good to know :) +[20:40:37] <mgorny> (though i think dol-sen hasn't made a release of repoman yet) +[20:40:59] <K_F> well, it should be in stable by the time we effectuate the glep +[20:41:27] <slyfox> why? +[20:41:36] <mgorny> K_F: well, before it is marked Final, i suppose (if it's supposed to become final) +[20:41:40] <K_F> convenience for enforcement +[20:41:42] <mgorny> normally implementation goes after approval +[20:41:55] <K_F> I said effectuation, not approval +[20:42:07] <mgorny> that's ok then +[20:42:19] <mgorny> dilfridge: just updated for 'bug #nnnnnn' +[20:42:24] <dilfridge> ++ +[20:42:33] <mgorny> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git +[20:42:36] <mgorny> url for archival purposes +[20:43:02] <dilfridge> ok then, as far as I understand it, we don't really need a vote on this today yet? +[20:43:15] <dilfridge> it sounds though as if everyone is happy with it +[20:43:18] <mgorny> just wanted to ask if you want to vote on it, or defer to when it's ready +[20:43:30] <mgorny> ready = glep editors do the needful +[20:43:33] <dilfridge> well I would not mind voting +[20:43:55] <K_F> lets just vote on it , doesn't seem to be any major disagreements anyways, the rest is editorial +[20:44:04] <slyfox> yup +[20:44:37] <ulm> well, I guess we'll vote on an rst version :) +[20:44:52] <dilfridge> ok so: the draft GLEP at https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git is approved pending editorial changes and conversion to rst ?! +[20:45:05] -*- slyfox votes yes +[20:45:07] -*- mgorny yes +[20:45:13] -*- K_F yes +[20:45:15] -*- dilfridge yes +[20:45:17] -*- WilliamH yes +[20:45:20] -*- ulm yes +[20:45:27] <dilfridge> again unanimous +[20:45:39] <dilfridge> next topic +[20:45:45] <dilfridge> 5. Banning empty dependency groups like "|| ( )" or "foo? ( )" in PMS +[20:46:05] <dilfridge> I failed to add a link, let me check +[20:46:33] <dilfridge> https://archives.gentoo.org/gentoo-project/message/9b76a175e12ef89dab2489a941d7af20 +[20:46:50] <mgorny> strictly speaking, we're talking about explicit empty groups (vs empty groups due to use-conditional elimination) +[20:47:15] <ulm> yes, this is about syntax only +[20:47:15] <K_F> this is where I'm lost, PMS should define a behavior that is consistent between a reduction and explicit definition +[20:47:36] -*- WilliamH isn't sure this is a big deal +[20:48:06] <ulm> K_F: we need a rule for reduction, but that doesn't prevent us from banning explicitly empty groups +[20:48:10] <K_F> and although I agree that, in particular, an empty || () is a bad idea, if being reduced by package masks etc (which can also go for the foo? () case, although here we seem to have foo? (bar? ( ) ) possibilities +[20:48:25] <K_F> I don't like to have different rules for explicit definition and reduction in PMS +[20:48:36] <dilfridge> what is the use-case for writing that out explicitly? if it has no use case we can as well ban it. +[20:48:54] <mgorny> those are kinda different problems +[20:49:16] <mgorny> explicit || ( ) has no valid use case, and since it is defined to be true (which is also bad), it might go unnoticed +[20:49:29] <mgorny> it could e.g. happen if eclass goes sideways and does not generate dep string +[20:49:44] <mgorny> (and i think we had things like that, e.g. when package no longer supported any valid ruby version0 +[20:50:07] <mgorny> use reduction otoh can technically happen if a package has purely use conditionals +[20:50:19] <mgorny> not that i like that case but i don't feel like we should forbid it either +[20:50:35] <ulm> at least not retroactively +[20:50:45] <dilfridge> does portage already error out today when an eclass creates such a string? +[20:50:50] <mgorny> finally, 2 of 3 package managers behave differently +[20:50:54] <ulm> dilfridge: yes +[20:50:57] <mgorny> dilfridge: yes, portage and pkgcore both reject explicit +[20:50:57] <K_F> its the retroactive aspect that has me worried, in particular if other package managers has handling for it +[20:51:02] <ulm> since 2011, in fact +[20:51:13] <mgorny> if we vote against this, we are supposed to 'fix' portage +[20:51:13] <dilfridge> ok then I'm all for the change +[20:51:22] <mgorny> which means portage will no longer catch those problems +[20:51:37] <mgorny> and i think that's main argument for the change +[20:52:18] <dilfridge> ok more questions or need for discussion? +[20:52:28] <ulm> also when looking at the end result, banning it retroactively makes for a much easier spec than adding another bunch of EAPI tables +[20:52:31] <K_F> mgorny: what would portage do for || ( foo bar ) if both foo and bar is not visible to user, due to ~arch or mask today? +[20:53:17] <mgorny> i haven't checked but it will probably reject it as unsatisfiable dep +[20:53:18] <K_F> (the example might be easier with a >= for [foo,bar]) +[20:53:21] -*- kent\n would probably also think a QA warning for an || ( ) group with only 1 item might be worthwhile +[20:53:36] <mgorny> kent\n: 1 item might be a valid result of eclass generation +[20:53:44] <mgorny> K_F: i'll test it very fast now +[20:53:50] <K_F> thanks +[20:54:21] <slyfox> ghc used to use SRC_URI="binary? ( amd64? ( binary1 ) x86? ( binary2 ) ... )" with occasionally empty list of arches/binaries for very fresh versions +[20:54:53] <kent\n> it might be, but its still something that probably should be looked into when it happens. Not a "fatal fix this" but an "uh...." grade ( similar to how items in a || ( ) that don't exist are fine as long as one of the items in || ( ) that do exist is fine ) +[20:54:53] <slyfox> portage failure requires 1-line change to not generate 'binary? ( )' +[20:55:34] <mgorny> K_F: scratch 'very fast', portage just started doing binpkg updates ;-) +[20:56:28] <ulm> that's the kind of research better to be done before a meeting +[20:56:43] <dilfridge> well +[20:56:47] <mgorny> well, i'm pretty sure it will behave like a regular masked dep +[20:56:55] <dilfridge> "|| ( foo bar ) if both foo and bar is not visible to user" is not covered by the change anyway +[20:56:56] <ulm> or the kind of questions better to be asked beforehand +[20:57:05] <ulm> dilfridge: right +[20:57:16] <dilfridge> since it is a || specification with two arguments in the brackets +[20:57:19] <mgorny> use reduction applies only based on state of EFFECTIVE_USE +[20:57:24] <mgorny> er, just USE* +[20:57:30] <K_F> dilfridge: the question is more, if we're going to fix anything, lets make sure it is a proper fix +[20:57:32] <dilfridge> independent of whether they are visible to the user or not +[20:58:17] <dilfridge> well, the proposed change to the specification adapts the specs to the current behaviour of package managers +[20:58:24] <K_F> and iirc || ( ) is still defined as true in PMS? +[20:58:38] <ulm> K_F: that will stay +[20:58:39] <mgorny> yes, it is, and i don't think we can really change this retroactively +[20:58:40] <dilfridge> we can always fix things in a later EAPI, if we think they are wrong as they are +[20:59:02] <ulm> or rather, that will stay for EAPIs 0 to 6 +[20:59:07] <mgorny> K_F: wrt your question, portage tries to autounmask the first package +[20:59:16] <ulm> :) +[20:59:21] <mgorny> and if i disable autounmask, it complains that the first package is masked +[20:59:46] <mgorny> so yes, it boils down to either +[20:59:57] <mgorny> A. we change PMS to ban || ( ) like 2 out of 3 PMs do +[21:00:17] <mgorny> or B. we change PMs to match PMS and allow || ( ), effectively opening field for issues +[21:00:34] <mgorny> (which will practically require us to ban it anyway via policy to avoid inconsistent behavior, at least) +[21:01:03] <WilliamH> If those are the two choices the first on is the easiest. +[21:01:04] <K_F> I fundamentally agree with the changes, but I'm not sure if we're going far enough +[21:01:36] <K_F> we should note that the next EAPI should have defined to false instead of true as a comment at least +[21:01:57] <mgorny> can do +[21:02:02] <ulm> we cannot go further for a retroactive change +[21:02:28] <mgorny> i suppose we can live with one extra EAPI table for this +[21:02:40] <ulm> yeah +[21:02:51] <ulm> but please not 4 of them +[21:03:37] <K_F> how about adding a note that PMS team comes up with a proposal for the next EAPI to define a behavior that seems correct in terms of resolver and our uses +[21:03:43] <mgorny> dilfridge: vote on the change + comment for EAPI 7? ;-) +[21:03:46] <dilfridge> yes +[21:04:05] <dilfridge> so, the vote is: +[21:04:21] <dilfridge> 1) PMS changes as detailed in https://archives.gentoo.org/gentoo-pms/message/a612bdc64f7aa3e556b129a67493da1b +[21:04:32] <dilfridge> 2) note that PMS team comes up with a proposal for the next EAPI to define a behavior that seems correct in terms of resolver and our uses +[21:04:43] -*- dilfridge yes +[21:04:50] -*- K_F yes +[21:05:14] -*- slyfox abstains +[21:05:19] -*- ulm yes +[21:05:21] -*- mgorny yes +[21:05:41] -*- WilliamH yes +[21:06:11] <dilfridge> ok that's 5 yes, 1 abstention, 1 absent, motion passed +[21:06:42] <dilfridge> I don't think we have any additional open bugs, so we can skip point "6. Further open bugs" +[21:06:57] <dilfridge> this gets us to +[21:07:02] <dilfridge> "7. Open Floor" +[21:07:05] <dilfridge> anyone? +[21:07:08] <slyfox> \o/ +[21:07:08] <mgorny> b-man, Soap__ +[21:07:37] <mgorny> on a different topic, i think we'll vote on EAPI 7 next month +[21:07:38] <b-man> I have seen a few bugs processed by HPPA, but there are still quite a few that are open with only hppa pending. +[21:07:54] <Soap__> mgorny: but SYSROOT! +[21:08:00] <mgorny> Soap__: it has SYSROOT +[21:08:03] <Soap__> oh ok +[21:08:09] <mgorny> and BROOT ;-D +[21:08:20] <Soap__> wuts that +[21:08:33] <mgorny> but i suppose the dirs might change, chewi is (will be) testing this +[21:08:34] <slyfox> b-man: we'll try to go through them in a reasonale time +[21:08:49] <mgorny> b-man: do you think there's any action necessary? +[21:09:08] <Soap__> mgorny: what about version specifiers? +[21:09:08] <b-man> slyfox: That would be great. Again, I see forward movement, but still many bugs pending only hppa stabilization. +[21:09:11] <b-man> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=VERIFIED&email1=security%40gentoo.org&email2=hppa%40gentoo.org&emailassigned_to1=1&emailcc2=1&emailtype1=equals&emailtype2=substring&list_id=3691046&order=changeddate%20DESC%2Cassigned_to%2Cbug_status%2Cpriority%2Cbug_id&query_format=advanced&resolution=--- +[21:09:12] <Soap__> too alpha atm? +[21:09:49] <b-man> slyfox: many of those are a couple months old :( +[21:09:52] <mgorny> Soap__: could you be more specific? you mean version syntax changes? +[21:09:57] <Soap__> yes those +[21:10:25] <mgorny> they haven't seen much interest +[21:11:06] <mgorny> so i really have no clue what to push forward there +[21:11:20] <K_F> lets not change it without a good reason, at least +[21:11:49] <K_F> just increases hurdle of migrating EAPIs and maintaining packages in general +[21:12:03] <mgorny> Soap__: but feel free to revive the topic and try to gather something reasonable +[21:12:13] <mgorny> you have 4 weeks ;-) +[21:12:27] <mgorny> (or 5?) +[21:12:31] <Soap__> mgorny: nah, I care more about SYSROOT and slash stuff +[21:12:39] <mgorny> those are both in +[21:12:50] <mgorny> (also ESYSROOT) +[21:12:57] <Soap__> while the current version specifiers suck, I dont have the creativity to define better ones +[21:13:13] <mgorny> all the patches are on gentoo-pms ml, waiting for review +[21:14:00] <mgorny> b-man, slyfox: so can you sort things out wrt hppa vs sec? +[21:14:13] <dilfridge> there's also the wiki page with the "executive summary", right? +[21:14:24] <mgorny> yes +[21:14:45] <mgorny> though some bugs have a lot of discussion, so it's easier to look at the final text ;-) +[21:15:15] <mgorny> https://dev.gentoo.org/~mgorny/eapi-7/pms.html#x1-194000E +[21:15:21] <dilfridge> how is portage development going? +[21:15:40] <mgorny> most of the small items i have prepared already +[21:15:47] <mgorny> Zac is workign on GLEP 73 +[21:15:58] <mgorny> Chewi has prepared BDEPEND & co AFAIK +[21:16:29] <dilfridge> cool +[21:16:37] -*- dilfridge prepares to add another line to the plot +[21:16:40] <mgorny> ||= and IUSE_RUNTIME are unclear +[21:16:43] <Soap__> BDEPEND :D +[21:17:00] <mgorny> because they both rely on Zac +[21:17:06] <mgorny> but i've prepared the wording in case they're done +[21:17:24] <mgorny> i mean, rely on Zac having enough time to implement them +[21:17:26] <slyfox> nix calls those 'native-inputs' (vs. 'inputs') +[21:17:51] <mgorny> we're using B as for CBUILD +[21:17:57] <dilfridge> fancy +[21:17:58] <mgorny> to avoid ambiguity +[21:18:27] <dilfridge> so... any other topics? +[21:18:36] <K_F> there were some concern about releng and catalyst, do we need to look into the state of those projects? +[21:18:51] <mgorny> also GLEP editors (when K_F's finished) +[21:19:04] <K_F> seems similar enough of a topic +[21:19:23] <dilfridge> releng is mostly jmbsvicetto, I think +[21:19:40] <mgorny> and i think he's active to talk if there's any concern +[21:19:41] <dilfridge> catalyst, no idea +[21:20:17] <mgorny> as for glep, i'll try to contact creffett and see if he needs/wants help +[21:20:22] <K_F> should we send an email to the projects asking about the status and encouraging them to send recruit mail if they need more manpower? +[21:20:50] <dilfridge> well, it should not hurt, in theory +[21:21:00] <K_F> including what kind of skills they seek +[21:21:20] <mgorny> does anyone want to join glep editors with the new workflow? ulm? +[21:21:45] <ulm> can do (but not me alone) +[21:22:05] -*- dilfridge already has too many projects +[21:22:06] <mgorny> i suppose we both should join at least for some time to help with technicalities or such +[21:22:12] <veremitz> there's a push to incorporate uefi into catalyst somehow +[21:22:26] <dilfridge> huh? +[21:22:37] <veremitz> and hopefully using catalyst 3 not 2 any more .. but there are a few issues I believe .. jmbsvicetto knows. +[21:22:46] <veremitz> dol-sen is hoping to get back to catalyst Soon™ +[21:23:27] <veremitz> uefi+support +[21:23:51] <K_F> we really need to get some more traction on OpenPGP signing of the gentoo repository / metamanifest as well, sadly development there has stopped for a while +[21:23:58] <dilfridge> K_F++ +[21:24:00] <dilfridge> pretty please +[21:24:02] <mgorny> i think Robin's GLEPs are good for that +[21:24:10] <mgorny> so it's just a matter of doing the needful +[21:24:37] <dilfridge> verification in portage? +[21:24:56] <K_F> it has been through two GSoCs already, I'm currently working on reducing the scope of things, e.g. gkeys-gen is likely going to be removed altogether +[21:25:05] <K_F> the verification code is mostly written +[21:25:10] <dilfridge> good +[21:25:17] <mgorny> hmm +[21:25:26] <mgorny> does anyone remember where we were about changing manifest hashes? +[21:25:40] <dilfridge> in a pointles debate? +[21:25:49] <mgorny> i think it stopped waiting for some portage changes which should be in stable already +[21:26:02] <dilfridge> right, there's one hash hardcoded into portage +[21:26:07] <dilfridge> and that had to be changed +[21:26:10] <ulm> IIRC portage was requiring SHA256 +[21:26:10] <mgorny> Date: Thu Jun 15 09:27:47 2017 +[21:26:10] <mgorny> const: Change the MANIFEST2_REQUIRED_HASH to SHA512 +[21:26:16] <ulm> right +[21:26:46] <Soap__> pls no SHA512 +[21:26:52] <dilfridge> too late +[21:26:54] <Soap__> I prefer my broken hash functions +[21:27:01] <Soap__> MD5 4eva +[21:27:13] <mgorny> so repoman 2.3.3, portage 2.3.7 has it +[21:27:15] <mgorny> have* +[21:27:20] <Soap__> pls also add the soviet one +[21:27:22] <K_F> the hashes aren't really too relevant as long as we don't have OpenPGP signatures +[21:27:42] <Soap__> ahahaha +[21:27:44] <mgorny> portage is stable +[21:27:45] <K_F> and sha256 is not broken in a practical sense +[21:27:52] <mgorny> repoman stable except fringe arches +[21:27:54] <dilfridge> well the signatures also only sign the sha1 git hash +[21:28:18] <dilfridge> but anyway +[21:28:27] <dilfridge> any progress is appreciated +[21:28:34] <K_F> dilfridge: in the backend, yes, the metamanifest is signed using other MDs +[21:28:47] <dilfridge> so now that we can get away from SHA256 +[21:29:00] <dilfridge> what was the last about a new manifest hash combination? +[21:29:13] <mgorny> hmm, will be hard to grep +[21:29:19] <dilfridge> manifest-hashes = SHA256 SHA512 WHIRLPOOL +[21:29:23] <dilfridge> ^ is what we have now +[21:29:55] <K_F> removal of sha256 makes sense from a cryptographical sense, as sha512 covers it +[21:30:13] -*- dilfridge suggests dropping SHA256 and WHIRLPOOL and adding some SHA3 variant and something else +[21:30:26] <ulm> I don't see a need for adding new hashes at this point +[21:30:30] <K_F> but I'm wondering about the portage migration path, we likely want the portage version not requiring it be stable for 12 months before actual removal +[21:30:43] <K_F> ulm++ +[21:31:04] <mgorny> https://archives.gentoo.org/gentoo-dev/message/3c041c1d1160c95c802df1574b0fbefe +[21:31:05] <dilfridge> at least let's replace WHIRLPOOL with SHA3 +[21:31:06] <mgorny> that was the original thread +[21:31:22] <mgorny> manifest-hashes = SHA512 SHA3-512 WHIRLPOOL +[21:31:25] <ulm> dilfridge: especially dropping the existing ones will be a pain for fetch restricted packages +[21:31:28] <mgorny> that was my original proposal, i suppose +[21:31:44] <mgorny> ulm: i think we've dealt with all lacking SHA512 +[21:31:51] <K_F> I'd be fore removing WHIRLPOOL if adding SHA3-512 +[21:32:00] <K_F> s/fore/for/ +[21:32:32] <mgorny> anyway, i suppose this belongs on the agenda for the next month +[21:32:35] <dilfridge> yep +[21:32:45] <dilfridge> anything else? +[21:33:04] <dilfridge> seems not +[21:33:11] <K_F> I've requested a stand for FOSDEM 2018 +[21:33:17] <dilfridge> right :) +[21:33:37] <K_F> we'll know if we get it in november +[21:34:48] -*- dilfridge is reminded of the bottle Chimay Grande Reserve in the cupboard +[21:35:27] <dilfridge> so keep it in your calendar - 3 & 4 February 2018 +[21:35:43] <dilfridge> with that we can probably close the session for today. +[21:35:45] <dilfridge> cheers! diff --git a/meeting-logs/20171008.txt.asc b/meeting-logs/20171008.txt.asc new file mode 100644 index 0000000..bf3659d --- /dev/null +++ b/meeting-logs/20171008.txt.asc @@ -0,0 +1,19 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2 + +iQKTBAABCgB9FiEEwo/LD3vtE3qssC2JpEzzc+fumeQFAlndJxdfFIAAAAAALgAo +aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMy +OEZDQjBGN0JFRDEzN0FBQ0IwMkQ4OUE0NENGMzczRTdFRTk5RTQACgkQpEzzc+fu +meRuiQ/+MIX4kQpoWfYxGTIYV8Rqs2H0T2zXuLsjaslAkhozB1TPZ62fo98UHH86 +tKzIcl1LkGL7P0aXHR/+neWwei04JQam3bOK19D+ZVB7pN8MOuDvR8RoQbPPJw4T +QIYlb9ppJYgvC+z6tJc2ZtTuQsMNttr3uKVC1zDaE/L6uDP/AE1Maru03wJK2eB3 +8AH3I2Jx/v2cW1Vxp4HxFtEb4IHwRZzA6EKpCKH3kmzf7J4mH6OmhY0PkWHXtuWW +OVAR5a8JblftD0t1pDgvbbMwoUaldu3LSkj2NfJTkIlkKb+KstcIZXdCT7bvStjn +j1iSuXm0BU4RUBBGXPabwQXgIK5zOMgVIv3zfLCKFlCkQyb4SHMjovPypHYJarG5 +rvvdPRnhFsKS3ZoAFAfW64Tvbz6+qiRvxWSagxQs973oxEMnh7i7a2GEtmaFCV1X +YSqi9yhuybfxO6NswmPnAeqBw1d90mDn19a53tCCZ1PHDLRpWlPA6woEtwArKqMt +CplON8eER9iGXQ4tW97SQC89Jo2RgjVwV2F6B+gyb9DKpHUI/3iF1JTppKCMy0TQ +NE54IO3fqTpcAjsMY9d7Kib64BNIAmdXh4yeaD1BURHSh84gi0pYoWPySiQrKn3W +CMqddzdIKKNRo0xU+zJ9x/tr2YQDB36pe3beVNLtAel6xsKcxFw= +=et6g +-----END PGP SIGNATURE----- |