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