path: root/meeting-logs/20171008.txt

[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!