path: root/meeting-logs/20171112.txt

[18:56:56] <mgorny> !proj council
[18:56:57] <willikins> (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh
[18:57:04] <mgorny> ^ T-3, get yourself stacked on food and beverage
[18:57:06] -*- tamiko here
[18:57:18] -*- dilfridge gets the popcorn
[18:57:33] <tamiko> mgorny: Just read the final meeting agenda. Preparing coffee.
[18:57:52] <slyfox> just in time :)
[18:57:55] <mgorny> i've interrupted my chromium build since it's likely to OOM chromium ;-)
[18:59:02] -*- robbat2 wheels the foundation soft-serve & coffee machine into the room, for a short-term loan ;-)
[18:59:24] <robbat2> (i'm here for GLEP74, at mgorny's request)
[18:59:43] -*- K_F is here
[18:59:59] -*- tamiko hands over and extension cord to robbat2 
[19:00:04] <mgorny> ulm: around?
[19:00:15] -*- ulm here
[19:00:28] <tamiko> WilliamH: *ping*
[19:01:12] -*- WilliamH here
[19:01:26] <mgorny> i guess we can start then
[19:01:33] <mgorny> 1. Roll call.
[19:01:42] -*- slyfox is here
[19:01:43] -*- WilliamH here
[19:01:46] -*- mgorny here
[19:01:46] -*- dilfridge here
[19:01:48] -*- tamiko here
[19:01:52] -*- K_F here
[19:02:06] -*- ulm here
[19:02:13] <mgorny> excellent
[19:02:19] <mgorny> 2. Status of old GLEPs [1].
[19:02:23] <mgorny> [1]:https://bugs.gentoo.org/634100
[19:02:49] <mgorny> so here's what i know
[19:03:01] <mgorny> GLEP 14 has been reviewed by security@, and they're planning to submit an update
[19:03:48] <mgorny> bugday i'm kinda lost
[19:04:06] <dilfridge> alicef: ^ do you know anything?
[19:04:06] <mgorny> https://wiki.gentoo.org/index.php?title=Bugday&action=history
[19:04:10] <ulm> we could submit bug 634100 for the next bugday :)
[19:04:11] <mgorny> looks like fturco updated the date again (again)
[19:04:13] <willikins> ulm: https://bugs.gentoo.org/634100 "Reevaluate status of old GLEPs"; Gentoo Council, unspecified; CONF; mgorny:council
[19:04:48] <mgorny> but i didn't notice anything spectacular
[19:04:57] <dilfridge> I long suspected the update was done by a script
[19:05:21] <mgorny> i suppose there's no harm in keeping it as-is
[19:05:48] <mgorny> so that would reduce the list to:
[19:05:48] <ulm> yes, there is some activity, so I'd say leave it as is
[19:05:57] <mgorny> a. marking Final:
[19:06:02] <mgorny> 59 Acce 2008-10-22 Manifest2 hash policies and security implications
[19:06:07] <mgorny> b. marking Moribund:
[19:06:12] <mgorny>    7 Fina 2003-07-06 New ombudsman position
[19:06:12] <mgorny>    8 Fina 2003-07-02 Adopt-A-Developer
[19:06:12] <mgorny>   36 Fina 2004-11-11 Subversion/CVS for Gentoo Hosted Projects
[19:06:32] <mgorny> a single vote for all of that?
[19:06:35] <dilfridge> wfm
[19:06:42] <tamiko> wfm
[19:06:44] <K_F> wfm
[19:06:56] <mgorny> so please vote for implementing the above a+b
[19:07:01] <WilliamH> wfm
[19:07:04] -*- K_F yes
[19:07:05] -*- dilfridge yes
[19:07:11] -*- mgorny yes
[19:07:12] -*- ulm yes
[19:07:18] -*- slyfox yes
[19:07:20] -*- tamiko yes
[19:07:22] -*- WilliamH yes
[19:07:33] <mgorny> unanimous
[19:07:45] <mgorny> anything else you'd like to add or moving on?
[19:08:19] <K_F> thanks for the work reviewing it
[19:08:29] <tamiko> +1
[19:08:31] <mgorny> thanks
[19:08:38] <dilfridge> ++
[19:08:39] <mgorny> ulm also does great work
[19:08:51] <tamiko> Marking a bunch of "deferred" GLEPs as "withdrawn" at some point might be a good idea.
[19:09:10] <mgorny> tamiko: not sure if GLEP 1 permits that
[19:09:11] <tamiko> But not necessary to discuss that now given the fact that we have a long list of stuff to do today :-)
[19:09:18] <mgorny> the idea is that 'withdrawal' happens per submitter's request
[19:09:23] <ulm> tamiko: we had discussed that in the team
[19:09:41] <mgorny> 'deferred' is more accurate as it clearly indicates nobody's around
[19:09:49] <ulm> exactly
[19:09:58] <tamiko> Roger.
[19:10:00] <mgorny> ok, let's move on
[19:10:02] <mgorny> 3. GLEP 66 -> Final (Gentoo git workflow) [2,3].
[19:10:02] <mgorny> [2]:https://www.gentoo.org/glep/glep-0066.html
[19:10:02] <mgorny> [3]:https://archives.gentoo.org/gentoo-dev/message/d9b0e789caf4679b0df3ececc5246fa1
[19:10:27] <slyfox> LGTM
[19:10:37] <dilfridge> +1
[19:10:45] <mgorny> this has been discussed in detail last time, so i suppose we can go straight for a vote
[19:10:58] <mgorny> vote: Mark GLEP 66 Final
[19:11:02] -*- K_F yes
[19:11:04] -*- slyfox yes
[19:11:05] -*- dilfridge yes
[19:11:07] <ulm> some of the commit tags don't work properly, though
[19:11:07] -*- mgorny yes
[19:11:24] -*- ulm yes
[19:11:25] -*- tamiko yes
[19:11:32] -*- WilliamH yes
[19:11:33] <mgorny> ulm: it's only a warning, so doesn't hurt at the moment
[19:11:43] <mgorny> and i'll eventually get to it
[19:11:48] <ulm> k
[19:11:49] <mgorny> unanimously approved
[19:12:05] <mgorny> 4. GLEP 65 -> Final (Post-install QA checks) [4,5].
[19:12:05] <mgorny> [4]:https://dev.gentoo.org/~mgorny/tmp/glep-0065.html
[19:12:05] <mgorny> [5]:https://archives.gentoo.org/gentoo-dev/message/6bdf0ed1bf2587931be7e2f10487f213
[19:12:21] <mgorny> this one may require some more discussion as it hasn't been approved at the last submission
[19:12:30] <dilfridge> if we accept 74 then 65 is fine too
[19:12:33] <mgorny> since then we've done some real work on tree signing
[19:12:37] <ulm> mgorny: does that version differ from https://www.gentoo.org/glep/glep-0065.html?
[19:12:43] <mgorny> and this one's gotten post-pkg_postinst checks
[19:12:50] <mgorny> ulm: ^
[19:13:12] <mgorny> i.e. the thing portage uses right now to detect missing xdg_update*  calls
[19:14:12] <mgorny> dilfridge: do we want to mark '74' as required by this one? i was thinking about it but that seems kinda tangential
[19:14:25] <mgorny> i mean, those checks work perfectly fine by themselves
[19:14:41] <dilfridge> it's a matter of personal taste I guess
[19:15:01] <dilfridge> then again I find 74 perfectly fine and will happily vote for it
[19:15:48] <mgorny> ulm: any comments before we vote on 65?
[19:16:24] <ulm> sorry, I've read the version in the glep repo only beforehand
[19:16:40] <dilfridge> I'd say let 65 require 74 and vote on it now
[19:16:44] <mgorny> ulm: want a diff or already got one?
[19:16:59] <ulm> mgorny: please, if you have one ready
[19:17:22] <tamiko> 65 is about QA checks, I would suggest to not combine/add dependencies on 74/65.
[19:17:39] <mgorny> ulm: http://dpaste.com/16VM6AW
[19:17:52] <dilfridge> tamiko: the logic is that 74 prevents code injection that is running at pm privileges
[19:18:49] <mgorny> dilfridge: but 74 is irrelevant e.g. if you're using git checkout
[19:18:55] <dilfridge> right
[19:19:10] <dilfridge> it only affects rsync
[19:19:13] <K_F> I agree, its not a dep in terms of the GLEPs
[19:19:28] <mgorny> maybe i'll just add a note on top
[19:20:15] <tamiko> Anyway, in my opinion both GLEPs are a great step forward.
[19:20:21] <dilfridge> yes, definitely
[19:21:16] <mgorny> ulm: ready?
[19:21:45] <ulm> looks good
[19:22:49] <mgorny> vote: GLEP 65 -> Accepted, pending Final when we have tree-signing
[19:22:57] -*- slyfox yes
[19:22:58] -*- tamiko yes
[19:23:01] -*- mgorny yes
[19:23:04] -*- K_F yes
[19:23:08] -*- ulm yes
[19:23:12] -*- dilfridge yes
[19:23:15] -*- WilliamH yes
[19:23:22] <mgorny> unanimously passed
[19:23:39] <mgorny> 5. manifest-hashes -> BLAKE2 (+ SHA512) [6,7].
[19:23:39] <mgorny> [6]:https://bugs.gentoo.org/635344
[19:23:39] <mgorny> [7]:https://archives.gentoo.org/gentoo-dev/message/f2321ebb659d15fd8d1f0188c3f80c74
[19:23:59] <mgorny> the current plan is at: https://archives.gentoo.org/gentoo-dev/message/682618f6d1cf4d63b30577cb1e9bd269
[19:24:11] <mgorny> robbat2: 
[19:24:35] <tamiko> What is the rationale against SHA-3 (KECCAK) and against using SHA512?
[19:24:50] <ulm> if we aim for a single hash, then why not SHA512 which exists in the tree?
[19:24:51] <tamiko> (except that BLAKE/BLAKE2 are sexy)
[19:24:56] <slyfox> this looks like security@ material
[19:25:09] <mgorny> tamiko: Keccak is slow
[19:25:18] <dilfridge> I'd probably just keep both SHA512 and BLAKE2B
[19:25:24] <ulm> (if we go for two hashes, then the choice of SHA512+BLAKE2 is okay IMHO)
[19:25:28] <mgorny> BLAKE2 is apparently as secure as SHA3 and faster than SHA2
[19:25:32] <dilfridge> (belt and suspenders, I know)
[19:26:24] <mgorny> ulm: i think the main argument is that SHA2 is the 'lowest' safe hash right now which makes it the next target for being broken
[19:26:24] <tamiko> Well, Dan Bernstein is well respected enough to put a lot of trust into the Blake family.
[19:26:39] <robbat2> the Keccak team themselves have recommended BLAKE2B for many cases
[19:26:50] <mgorny> however unlikely that is, BLAKE2 should be safe longer
[19:27:15] <mgorny> plus i'm pretty sure many of our users would like to see something new in Gentoo, even if it's just about hashes
[19:27:48] -*- dilfridge now thinks of hash browns and is hungry...
[19:27:49] <ulm> oh my, if that's all we have to offer :)
[19:27:49] <tamiko> Personally, I am fine with SHA512 and/or Blake2B.
[19:28:22] <mgorny> well, the main point is to kill duplicate SHA256 and old WHIRLPOOL
[19:28:27] <mgorny> i think everyone agrees on that
[19:28:28] <robbat2> the prior GLEP only kept SHA256 as a transitional hash, but it was never actually disabled after the transition period
[19:28:31] <tamiko> It is intersting how the crypto community rushed for SHA-3 standardization (similarly to AES) and sometime halfway through SHA-2 turned out to be much more robust than expected.
[19:28:50] <tamiko> mgorny: ack.
[19:28:54] <K_F> tamiko: AES wasn't rushed
[19:29:21] <mgorny> while we're changing hashes, we may as well add something new, to avoid unnecessary change in the future
[19:29:23] <K_F> neither was SHA-3, really.. although the whole starting to make adjustment after the competition was a bit fishy (which they reverted)
[19:29:26] <mgorny> i.e. do that with one diff
[19:30:02] <tamiko> What about we agree on transitioning to SHA512 + Blake2B then?
[19:30:14] <K_F> but I don't believe there is a particular reason to be concerned with SHA2, having digest algorithms based on other constructs is a good thing up the sleeve
[19:30:23] <mgorny> robbat2 insisted we have a full plan on killing SHA512 to reduce number of hashes eventually
[19:30:25] <K_F> so the main reason for blake is speed, not anythign to do with security
[19:30:26] <ulm> mgorny: I would be fine with the proposal if the automatic "T + 36 months" part was omitted
[19:30:34] <dilfridge> yes, please, just go to SHA512+BLAKE2B
[19:30:46] <dilfridge> (without any pre-determined changes of that)
[19:30:48] <mgorny> ulm: it's not meant to be automatic
[19:30:56] <mgorny> it's more like 'we WILL NOT do that before that time'
[19:31:08] <robbat2> so >= T+36months
[19:31:16] <mgorny> yes, i forgot to say that in the mail
[19:31:19] <tamiko> 36months is also a freking long time.
[19:31:24] <mgorny> it's about guarantees to our users
[19:31:35] <mgorny> 'in next 36 months things will not explode'
[19:31:37] <WilliamH> All we have to guarantee is 12 months.
[19:31:55] <dilfridge> I think it's perceived differently.
[19:32:22] <tamiko> I like the long-term plan of mgorny's proposal.
[19:32:50] <mgorny> i suppose the Council will have to revisit it later before applying the 'T+36' rule anyway
[19:32:50] <tamiko> (and the quick phase-out of whirlpool and sha256)
[19:33:27] <K_F> I'm fine with another vote for the removal , and just deferring it to when it makes sense
[19:33:38] <K_F> and voting on the rest of the proposal
[19:33:46] <WilliamH> That sounds reasonable to me.
[19:33:48] <mgorny> K_F: do we want to keep the 'at least 36 months' guarantee in that?
[19:33:55] <mgorny> i.e. that the next vote won't remove it earlier?
[19:34:17] <WilliamH> mgorny: All we have to really worry about there is the next 12 months.
[19:34:35] <mgorny> WilliamH: that's why i specifically wanted to make this one longer because it's more core than packages
[19:34:39] <K_F> mgorny: 36 months isn't necessarily set in stone either, so I'd just keep it out, it is anyways part of the dicussion in this meeting and we can mention it in summary
[19:34:49] <mgorny> K_F: ok then
[19:34:49] <tamiko> ack.
[19:35:01] <ulm> it can't harm to mention that this is the roadmap, though
[19:35:11] <K_F> ulm: indeed
[19:35:37] <mgorny> vote: change manifest-hashes -> BLAKE2B SHA512 according to https://archives.gentoo.org/gentoo-dev/message/682618f6d1cf4d63b30577cb1e9bd269 with the exception that the Council will vote later on removing SHA512
[19:35:46] -*- K_F yes
[19:35:52] -*- dilfridge yes
[19:35:56] -*- mgorny yes
[19:36:01] -*- tamiko yes
[19:36:06] -*- ulm yes
[19:36:12] -*- WilliamH yes
[19:36:17] -*- slyfox yes
[19:36:25] <mgorny> passed unanimously
[19:36:30] <dilfridge> hash browns...
[19:36:41] <mgorny> 6. GLEP 74 -> Accepted (Full-tree verification using Manifest files)
[19:36:41] <mgorny> [8,9].
[19:36:49] <mgorny> [8]:https://dev.gentoo.org/~mgorny/tmp/glep-0074.html
[19:36:49] <mgorny> [9]:https://archives.gentoo.org/gentoo-dev/message/86ef412c10540f7bcb17813aba1b484b
[19:37:05] <dilfridge> one question on the wording
[19:37:35] <dilfridge> paragraph "Timestamp verification"
[19:37:39] <ulm> mgorny: remove authors from credits :p
[19:37:49] <dilfridge> "The Manifest file can contain a TIMESTAMP entry..."
[19:38:11] <dilfridge> ^ does that mean top-level manifest or also sub-manifests? and what would be the meaning in sub-mainifests?
[19:38:19] <robbat2> i'll answer that
[19:38:24] <mgorny> dilfridge: top-level
[19:38:29] <robbat2> both
[19:38:37] <mgorny> or rather, by design
[19:38:43] <mgorny> technically it can occur anywhere
[19:38:51] <robbat2> consider glsa & news under metadata: they could have an externally generated signed Manifest
[19:39:00] <robbat2> with it's own timestamp & signature
[19:39:06] <dilfridge> right
[19:39:38] <mgorny> but gemato is going to take the first present for verification purposes
[19:39:44] <ulm> mgorny: under Modern Manifest Tags it says "Optionally used in the top-level Manifest file." though
[19:39:46] <mgorny> i.e. the one in top-level
[19:39:52] <dilfridge> so another failure mode would be "submanifest timestamp is newer than toplevel manifest timestamp"
[19:40:20] <mgorny> ulm: tbh i never thought of robbat2's use
[19:40:28] <K_F> if timestamp exists it would likely need to be verified on all levels, e.g if glsa are separately signed (and as such not in top level manifest), you could otherwise stop glsa-check through downgrade attack
[19:40:59] <K_F> you already have the timestamp from the signature though, so I'm wondering if it wouldn't make sense just to use that
[19:41:20] <robbat2> signature timestamp doesn't have to be the same as the TIMESTAMP value
[19:41:25] <K_F> but explicit one doesn't hurt anyways..
[19:41:25] <dilfridge> but it doesnt make sense to verify them at all levels ( app-text/a2ps got its last update a few years ago, but ... )
[19:41:25] <robbat2> it should probably be newer
[19:41:50] <ulm> if the sublevel timestamp is newer then the hash at top-level would fail, I think
[19:41:52] <robbat2> and parsing out TIMESTAMP is a lot easier than the signature timestamp
[19:42:07] <mgorny> what ulm said
[19:42:09] <K_F> ulm: not if separately signed
[19:42:18] <K_F> then it wouldn't be part of the top-level mainfest
[19:42:25] <dilfridge> but it has to be
[19:42:28] <mgorny> K_F: it always must be
[19:42:44] <mgorny> unless it's explicitly IGNORE-d, then it needs explicit PM support and that's outside the spec
[19:43:13] <mgorny> the spec only covers how a single Manifest tree works, and that's talking about two disjoint trees
[19:43:21] <robbat2> so amendments: sub-Manifest TIMESTAMP must not be newer than a higher-level TIMESTAMP;
[19:43:38] <K_F> "The sub-Manifest can also be signed using OpenPGP armored cleartext
[19:43:38] <K_F> format. However, the signature verification can be omitted if it is
[19:43:38] <K_F> covered by a signed top-level Manifest."
[19:44:02] <mgorny> robbat2: what's the purpose of that? if hash is valid, then sub-timestamp is really irrelevant
[19:44:04] <K_F> that implies it doesn't have to be covered by the top level
[19:44:30] <mgorny> K_F: unclear wording
[19:44:33] <robbat2> K_F: no, it says the signature doesn't need to be verified, it says nothing about not verifying the manifest
[19:44:38] <dilfridge> we should change that wording
[19:44:43] <mgorny> K_F: s/if/as/
[19:44:53] <dilfridge> right, robbat2 says it
[19:45:03] <K_F> might be the intention, its not what it says :)
[19:45:34] <K_F> and if it has to be covered, why bother with signatures on the sub-manifests to begin with
[19:45:50] <K_F> as the chain is preserved by signing the top-level
[19:45:51] <mgorny> K_F: but the other option is prohibited by other parts of the spec, so that's really a typo-level fix
[19:45:55] <mgorny> K_F: it's in the rationale
[19:45:58] <K_F> that also removes some ambiguity c.f compression
[19:46:09] <dilfridge> replace the sentence with "However, the signature verification can be omitted since it already is covered by the signed top-level manifest."
[19:46:23] <mgorny> the idea is that you can use extra signatures if you want backwards compatibility with old tools
[19:46:29] <mgorny> (not that portage verifies signatures)
[19:46:42] <tamiko> dilfridge: s/it already is covered/it is already covered/g
[19:46:52] <K_F> on that note, I'm wondering if we shouldn't avoid compressing top-level manifest file, as that allows direct verification without possibility of zip bombs etc
[19:47:06] <K_F> and it should anyways be limited in size to categories ++ metadata etc
[19:47:21] <robbat2> FYI, the use cases I had in mind 1. some of the downstream gentoo repos already copy in our glsa & news; 2. glsa-check can verify glsa dir Manifests :-)
[19:48:35] <mgorny> robbat2: what you think of K_F's argument? compression is your child ;-)
[19:48:45] <K_F> glsa-check can anyways verify the top-level manifest
[19:49:03] <robbat2> some consumers of glsa-check sync the glsas without the portdir
[19:49:41] <K_F> robbat2: right, then it might make sense indeed
[19:49:54] <robbat2> i'm ok with forbidding the compression of top-level Manifest
[19:50:02] <robbat2> i was projecting it to be ~50KB in size in the end
[19:50:17] <robbat2> before compression
[19:50:28] <dilfridge> that should be no problem
[19:51:01] <robbat2> one of the original related proposals was to use detached GPG signatures to make that safer
[19:51:13] <robbat2> but that got dropped because it was going to add many more tiny files
[19:51:22] <K_F> yup, I thought of that and concluded the same
[19:52:06] <mgorny> ok, do we want to vote on pre-approval of this glep today, and start testing deployment on infra?
[19:53:03] <tamiko> It think this is a good idea.
[19:53:06] <dilfridge> with the two changes yes
[19:53:29] <mgorny> dilfridge: could you reiterate the changes?
[19:53:40] <dilfridge> 1) "However, the signature verification can be omitted since it is already covered by the signed top-level manifest."
[19:53:40] <tamiko> Futher, it might also be a good idea to do some "security review" (by a single author/some people) that just report their finding via e-mail. IRC isn't exactly the right medium for that.
[19:54:03] <mgorny> dilfridge: that's an editorial fix
[19:54:06] <dilfridge> (as replacement for the sentence "However, the signature verification can be omitted if it is covered by a signed top-level Manifest."
[19:54:13] <dilfridge> )
[19:54:25] <dilfridge> 2) forbid compression of the top level manifest
[19:54:39] <mgorny> i'm wondering if we should have explicit file size limit though
[19:54:49] <dilfridge> (to avoid vulnerabilities in decompressors)
[19:55:26] <K_F> mgorny: min file size limit before compression etc seems like implementation question, not needed in GLEP
[19:55:40] <mgorny> yes
[19:55:41] <mgorny> so
[19:55:58] <robbat2> i'm good with dilfridge's changes
[19:56:11] <ulm> +1
[19:56:12] <mgorny> vote: pre-approve GLEP 74 given the editorial fixes discussed + disallowing top-level Manifest compression, and give green light for infra testing
[19:56:22] -*- tamiko yes
[19:56:22] -*- K_F yes
[19:56:26] -*- ulm yes
[19:56:27] -*- mgorny yes
[19:56:31] -*- slyfox yes
[19:56:32] -*- WilliamH yes
[19:56:32] -*- dilfridge yes
[19:56:38] <mgorny> passed unanimously
[19:56:50] <dilfridge> \o/
[19:57:00] <slyfox> (and again, i think it's a security@ material to evaluate the design sanity WRT potential threats)
[19:57:08] <mgorny> next item is EAPI 7
[19:57:17] <mgorny> can you guys stay longer today or should we defer it?
[19:57:34] -*- tamiko has time
[19:57:38] <mgorny> (and instead do quick look over bugs + open floor)
[19:57:39] -*- WilliamH has time
[19:57:45] <K_F> slyfox: security-audit and/or crypto@ are likely better places
[19:57:47] <dilfridge> I'm fine for some more time
[19:58:12] <mgorny> ok
[19:58:18] <mgorny> 7. EAPI 7 feature/spec pre-approval [10,11,12].
[19:58:25] <mgorny> [10]:https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_7_tentative_features
[19:58:25] <mgorny> [11]:https://gitweb.gentoo.org/proj/pms.git/log/?h=eapi-7
[19:58:25] <mgorny> [12]:https://dev.gentoo.org/~ulm/pms/7-draft/
[19:58:50] <mgorny> unlike the previous times, we have full listing + the spec ready
[19:59:04] <mgorny> and partial untested portage implementation ;-)
[19:59:21] <ulm> list of features is in [10], or also in https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-194000E
[20:00:28] <mgorny> Zac seems positive about implementing the list but it's going to still take time, and we may eventually want to drop something
[20:00:35] <ulm> one difference, [10] still lists bash-4.3
[20:01:55] <robbat2> (i have to run, thanks all for hashes & meta-manifest; I did sent a previous answer re larrythecow.org)
[20:02:07] <mgorny> robbat2: ok, thanks
[20:02:09] <ulm> the most intrusive changes are IMHO:
[20:02:16] <ulm> - first three items listed under https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_7_tentative_features#New_features
[20:02:34] <ulm> - Remove trailing slash from {,E}ROOT and {,E}D
[20:03:08] <K_F> automatic use enforcing has a dependency on GLEP 73 which isn't approved, so can it be pre-approved per se?
[20:03:10] <dilfridge> let's just go through the list from top to bottom and discuss / vote
[20:03:30] <dilfridge> (or start with that and continue next time :)
[20:04:03] <WilliamH> So we are voting on each individual feature?
[20:04:03] <tamiko> *ugh*
[20:04:03] <mgorny> K_F: the idea is that EAPI7 supersedes that GLEP
[20:04:03] <mgorny> but yeah, let's go one-by-one and see if anybody has comments
[20:04:12] <dilfridge> most of them are fairly unproblematic, so why not
[20:04:13] <mgorny> that should keep the discussion focused
[20:04:27] <mgorny> Runtime-switchable USE flags
[20:04:32] -*- dilfridge is all for that
[20:04:45] <mgorny> this one was approved earlier but deferred due to no impl
[20:04:59] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=d3d148235b1debf6fe1de1bea7834d83ae88889a
[20:05:01] <mgorny> maybe Zac will do it this time, but i suppose it doesn't hurt to keep it in case
[20:05:05] <WilliamH> Do we have an implementation now?
[20:05:08] <K_F> right, this only affects dependencies and required use so if a feature has automagic etc
[20:05:59] <mgorny> WilliamH: nope
[20:06:36] <mgorny> K_F: it's meant to be used for things like python package dependencies
[20:06:59] <mgorny> alternative to suggested/recommended deps in other distros
[20:07:09] <ulm> it will be dropped from eapi 7 if there's no implementation, so we don't have to worry about it at this point
[20:07:57] <dilfridge> ok for the record shall we vote on it?
[20:07:59] -*- dilfridge yes
[20:08:00] <K_F> mgorny: right, but a dlopened() dep seems relevant for it
[20:08:16] <K_F> extension features etc
[20:08:27] <mgorny> K_F: well, yes, all kinds of stuff that doesn' t affect build time
[20:08:45] <mgorny> iow, stuff that per current policy would be in pkg_postinst
[20:08:57] <dilfridge> exactly
[20:09:03] <K_F> seems good to me
[20:09:16] <mgorny> ok, let's do a quick vote for completeness
[20:09:23] -*- K_F yes
[20:09:24] -*- mgorny yes
[20:09:26] -*- dilfridge yes
[20:09:33] -*- tamiko yes
[20:09:41] -*- slyfox yes
[20:09:46] -*- ulm yes
[20:10:13] <mgorny> WilliamH: ping
[20:10:23] -*- WilliamH yes
[20:10:28] <mgorny> ok, next item
[20:10:34] <mgorny> Automatic use enforcing (GLEP 73)
[20:10:38] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=dd298e8cd9b90cf623336f97f46e7e16feacdec3
[20:10:53] <dilfridge> to be clear, that proposal *replaces* glep73, right?
[20:10:54] <mgorny> as i said, the idea is to replace the GLEP73 by PMS
[20:11:00] <dilfridge> ++
[20:11:09] <mgorny> though GLEP73 still explains how to repoman it
[20:11:13] <K_F> I'm not sure if I like the idea of it though, I typically favor explicit over implicit
[20:11:29] <mgorny> Ciaran had some snarky comment about it too but he was as enigmatic as ever
[20:11:48] <mgorny> Zac has made some progress implementing it but we'll know for sure when it's done and we can test it
[20:12:28] <K_F> to me required use of gnutls ( ssl ) makes a lot of sense in the discussed scenario
[20:12:34] <mgorny> i think i've covered all the obvious and less obvious loopholes
[20:13:07] <mgorny> and yes, the main idea is with something like ^^ ( ssl_impl_openssl ssl_impl_libressl )
[20:13:25] <mgorny> it improved the readibility a lot while avoiding unnecessary edits for every package
[20:14:12] <mgorny> but it's an intrusive change and i'm ready to withdraw it once initial testing finds major issues
[20:14:35] <mgorny> (we can test it on EAPI < 7 packages locally)
[20:14:51] <dilfridge> vote?
[20:14:56] <mgorny> vote
[20:15:13] -*- K_F no
[20:15:18] -*- dilfridge abstains
[20:15:19] -*- slyfox abstains
[20:15:30] -*- tamiko abstains
[20:16:05] -*- mgorny yes, provided that it's given enough testing and doesn't prove problematic
[20:16:32] -*- WilliamH no
[20:16:45] -*- ulm yes
[20:16:52] <mgorny> so we have 2:2
[20:17:07] <ulm> not passed
[20:17:36] <mgorny> does that mean we kill it already or give it a chance till an implementation is available for testing?
[20:18:05] <mgorny> anyway, next item
[20:18:07] <mgorny> BDEPEND and SYSROOT
[20:18:16] <ulm> I'd say the latter, but I've voted yes
[20:18:19] <WilliamH> let me rephrase. Nothing is stopping you from testing it.
[20:18:43] <dilfridge> I think if it tests out well its chances are improving.
[20:18:47] <WilliamH> I think it should not be officially part of the eapi without testing.
[20:18:57] <ulm> is it seen as being too complicated, or what is the issue?
[20:19:11] <dilfridge> impact not yet predictable for me
[20:19:57] <dilfridge> I'd need to take some real-world situations and manually go through the algorithm
[20:20:16] <dilfridge> and that I havent done yet
[20:21:03] <WilliamH> It seems unpredictable as well to me.
[20:21:03] -*- K_F says yes for BDEPEND and sysroot
[20:21:17] <mgorny> K_F: we aren't there yet
[20:21:27] <K_F> next item was called
[20:21:44] <mgorny> but ulm hasn't pasted the link yet ;-)
[20:21:56] <ulm> it's 6 commits
[20:21:58] <mgorny> well, links
[20:21:58] <dilfridge> could you please explain in one sentence what (BDEPEND and) SYSROOT is?
[20:22:06] <mgorny> it's a big change
[20:22:12] <ulm> from "EAPI 7 has SYSROOT and ESYSROOT" to "dependencies: Provide a nice summary table for dep APIs"
[20:22:22] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=d2562ca6c8808ffc5e310b1745530204018e8cdb
[20:22:24] <mgorny> that summary table probably explains it best
[20:22:28] <K_F> dilfridge: cross compile , built host vs build target build-time dependency
[20:22:30] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=3a616e967724ff394381f4d7e955dd69ebe06a7b
[20:22:38] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=ceb53f99645fdb940d8d4b3936caf52c8b73610f
[20:22:45] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=e04651aa1278c4b81f93feef61a5e0289cd88777
[20:22:51] <mgorny> https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-750008.1
[20:22:51] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=9cf6b9aa665ae2057175b934f0e84bb2a4547bd8
[20:22:59] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=1c9dc0345632b61d729c9374a2d26a4661d992b2
[20:23:08] <ulm> mgorny: happy now? :)
[20:23:11] <mgorny> ;-)
[20:23:15] <mgorny> so https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-750008.1 table 8.2
[20:23:26] <mgorny> basically we're splitting build-time deps into CBUILD/CHOST
[20:23:35] <mgorny> adding SYSROOT for DEPEND
[20:23:47] <mgorny> and sanitizing has_version options
[20:24:09] <ulm> biggest impact is that EAPI 7 ebuilds will have to distinguish between DEPEND and BDEPEND
[20:24:14] <dilfridge> ok so if I cross-compile for architecture X, then a) SYSROOT points to the root directory of X, b) DEPEND dependencies are in binary format X, c) BDEPEND dependencies are in the binary format of the builder?
[20:24:19] <mgorny> it's mostly related to cross but i suppose SYSROOT has other uses
[20:24:22] <ulm> DEPEND = dependencies on CHOST system
[20:24:33] <ulm> BDEPEND = dependencies on CBUILD system
[20:24:56] <mgorny> dilfridge: yes
[20:25:06] <dilfridge> thank you! an answer I can understand!
[20:25:39] <mgorny> any more questions before we vote?
[20:26:00] <mgorny> (this one will also probably require some testing but for regular systems it's not changing much)
[20:26:22] <mgorny> the relevant policy would be that developers are free to ignore BDEPEND and let people who care about cross fix it
[20:26:48] <mgorny> (like they don't have to be 100% prefix safe right now)
[20:26:54] <dilfridge> "fix it" = distribute things between BDEPEND and DEPEND
[20:27:00] <ulm> yep
[20:27:17] <mgorny> dilfridge: possibly add more cross hacks, add SYSROOT somewhere...
[20:27:20] <tamiko> That's a lot of fixing.
[20:27:26] <mgorny> cross is crazy
[20:27:28] <tamiko> Someone setting up some automatic testing for that?
[20:27:34] <mgorny> tamiko: better not ;-)
[20:27:36] <dilfridge> and mostly unmaintained atm
[20:27:39] <tamiko> *hrhr*
[20:27:46] <mgorny> ok, let's vote for this then
[20:27:51] -*- dilfridge yes
[20:27:55] -*- mgorny yes
[20:27:55] <tamiko> unmaintained is a very mild expression of our current state of prefix/cross support.
[20:27:56] -*- slyfox yes
[20:27:57] -*- K_F yes
[20:28:00] -*- tamiko yes
[20:28:00] -*- ulm yes
[20:28:04] -*- WilliamH yes
[20:28:07] <mgorny> passed
[20:28:17] <WilliamH> tamiko: heh that's very true.
[20:28:19] <mgorny> by the way, credits go to Chewi for handling all this crazy magic
[20:28:31] <mgorny> Profile-defined unsetting of variables (ENV_UNSET)
[20:28:52] <mgorny> this is meant to fix the lot of mayhem caused by DISPLAY & XDG_* leaking into ebuilds
[20:29:04] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=24fd4576a11b8f97da9664981cb1df3e1f371d00
[20:29:12] <mgorny> without having every second ebuild inherit xdg.eclass to fix it
[20:29:25] -*- ulm wonders if stacking between profiles is over-engineered
[20:29:46] <mgorny> ulm: it's probably irrelevant to real-life use of this
[20:29:47] <ulm> OTOH, the code for that exists in package managers already
[20:29:50] <mgorny> except maybe for prefx
[20:30:13] <mgorny> any discussion?
[20:30:32] <dilfridge> what's the case with * now?
[20:30:43] <mgorny> not supported
[20:30:53] <mgorny> only explicit blacklist
[20:30:56] <dilfridge> ok
[20:31:01] <dilfridge> well we can start with that
[20:31:07] <mgorny> literal variables
[20:31:19] <ulm> the feature came in late, so I guess we can still adjust implementation details before the final vote
[20:31:39] <mgorny> the problem is, '*' is kinda dangerous
[20:31:41] -*- dilfridge feels literate, err, literal (or was it litoral) today
[20:31:57] <mgorny> people become lazy, do 'XDG_*' and suddenly eclass control variable disappears
[20:32:05] <dilfridge> yeah, good point
[20:32:15] <dilfridge> explicit is better
[20:32:34] <mgorny> ok, let's vote
[20:32:38] -*- dilfridge yes
[20:32:38] -*- mgorny yes
[20:32:45] -*- ulm yes
[20:32:50] -*- K_F yes
[20:32:58] -*- WilliamH yes
[20:33:00] -*- tamiko yes
[20:33:24] <mgorny> slyfox: 
[20:33:25] -*- slyfox yes
[20:33:28] <mgorny> ok
[20:33:31] <mgorny> Sandbox control (sandbox{off,save,restore})
[20:33:32] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=288935f1321343dae4d83f6c857b426c85930acf
[20:33:37] <mgorny> those actually have changed a bit
[20:34:04] <mgorny> so we have a set of functions to remove previously added sandbox paths
[20:34:28] <mgorny> as easiest to implement portably between different sandbox implementations
[20:34:36] <dilfridge> I like that better than the original
[20:34:43] <mgorny> and we've removed sandboxoff since that shouldn't be ever used
[20:34:48] <K_F> What are we trying to do with this feature? imho sandbox should be controlled outside ebuild mostly (although we do allow addwrite etc)
[20:34:54] <dilfridge> (found it strange that an ebuild should have the power to switch off the sandbox)
[20:35:20] <mgorny> K_F: we basically add stuff complementary to addwrite
[20:35:24] <ulm> K_F: e.g. VCS eclasses do an addwrite / at some point
[20:35:47] -*- dilfridge headdesk
[20:35:52] <ulm> currently they have to mess with sandbox internals to restore the previous state
[20:36:16] <mgorny> VCS eclasses are kinda mess anyway
[20:36:26] <mgorny> but we don't have a good replacement right now
[20:36:41] <mgorny> maybe we should have an explicit replacement for DISTDIR in the future to avoid all this polka
[20:37:05] <mgorny> but that's straying off the topic
[20:37:33] <mgorny> vote: rm* commands for removing paths off sandbox lists
[20:37:51] -*- slyfox yes
[20:37:54] -*- ulm abstains
[20:38:02] -*- dilfridge yes
[20:38:07] -*- K_F yes
[20:38:11] -*- tamiko yes
[20:38:13] -*- mgorny abstains
[20:38:36] -*- WilliamH  abstains
[20:38:43] <mgorny> 4:0, passed
[20:38:54] <mgorny> New eqawarn command
[20:38:58] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=05fbb636c70db0df46dbb8d86a31c19caa3ae0a8
[20:39:00] <mgorny> i suppose this has been waiting ages
[20:39:13] <ulm> let's just vote
[20:39:16] <mgorny> ulm: you have a different order?
[20:39:18] -*- ulm yes
[20:39:29] -*- dilfridge yes
[20:39:29] <ulm> hm, wrong link?
[20:39:46] -*- dilfridge yes for eqawarn
[20:39:47] <mgorny> ulm: no, sorry, looked at wrong string ;-)
[20:39:49] -*- K_F yes
[20:39:51] -*- mgorny yes
[20:40:03] -*- WilliamH yes for eqawarn
[20:40:08] -*- slyfox yes
[20:40:32] <mgorny> tamiko: 
[20:40:55] -*- tamiko yes
[20:41:04] <mgorny> Controllable stripping and dostrip
[20:41:06] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=5c624f05acdfbc6e1339a175b0c4749965859618
[20:41:32] <mgorny> any discussion needed here?
[20:41:50] <tamiko> Don't think so. These are all reasonable changes.
[20:41:55] <mgorny> i think it fits docompress pretty neat
[20:42:00] <mgorny> so let's vote
[20:42:05] -*- ulm yes
[20:42:10] -*- K_F yes
[20:42:13] -*- mgorny yes
[20:42:16] -*- dilfridge yes
[20:42:17] -*- slyfox yes
[20:42:29] -*- WilliamH yes
[20:42:39] -*- tamiko yes
[20:42:41] <mgorny> Functions for version comparison and version component expansion
[20:42:44] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=555e50c4416c1a77938a9f36343a9bd86fe68752
[20:42:51] <mgorny> already in tree as eapi7-ver.eclass
[20:43:08] <tamiko> (Finally!)
[20:43:15] <WilliamH> mgorny: so this is meant to replace versionator?
[20:43:16] <mgorny> much faster than versionator.eclass
[20:43:22] <mgorny> WilliamH: yes
[20:43:26] <ulm> mgorny: implementation will most likely be in bash, right?
[20:43:32] <ulm> i.e. no IPC
[20:43:46] <mgorny> ulm: i think so, that's proved too fast to play with IPC :-)
[20:43:59] -*- ulm yes
[20:44:01] -*- K_F yes
[20:44:04] -*- mgorny yes
[20:44:04] -*- WilliamH yes
[20:44:04] -*- tamiko yes
[20:44:05] -*- dilfridge yes
[20:44:06] -*- slyfox yes
[20:44:16] <mgorny> Group 2: Enhancements of existing features
[20:44:20] <mgorny> Directory support for profiles/package.mask
[20:44:31] <mgorny> (Not intended for gentoo-x86 tree, only to be used in overlays)
[20:44:33] <ulm> can we vote on the first two together?
[20:44:36] <K_F> should we do a vote whether we need a one-by one on the rest?
[20:44:52] <mgorny> K_F: those two should be separate
[20:44:57] <mgorny> ulm: yes
[20:45:01] <mgorny> so the above + Directory support for profile files
[20:45:09] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=9b410aad2d7a40e060eac053a66c99f72bb72a8c
[20:45:13] <mgorny> i personally don't like it, but i see why some people want it
[20:45:17] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=9dd030848d570ad8303128c030c7a773eb493416
[20:45:40] <K_F> isn't that only consistent with how we do things otherwise?
[20:45:51] <tamiko> Jup.
[20:45:52] <K_F> and can allow for cleaner package masks etc, easier removal etc
[20:46:00] <tamiko> Jup.
[20:46:14] <WilliamH> We allow files or directories in /etc/portage/*, so why not in profiles?
[20:46:27] <ulm> one of them already was approved for EAPI 6, but got dropped at last minute because of inconsistencies
[20:46:39] <ulm> that should be all settled now
[20:46:44] <mgorny> well, let's vote
[20:46:47] <K_F> of course it can't be used before profile is bumping EAPI so will be down the road
[20:46:49] <mgorny> (for both)
[20:46:53] -*- slyfox yes
[20:46:55] -*- WilliamH yes
[20:46:56] -*- dilfridge yes
[20:46:56] -*- ulm yes
[20:47:00] -*- mgorny abstains
[20:47:05] -*- K_F yes
[20:47:17] -*- tamiko yes
[20:47:40] <mgorny> Variant of || ( ) with defined runtime behaviour
[20:47:47] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=68805ec803fc4d5262bb926f2136092659b984f9
[20:47:55] <mgorny> this is ||= ( A B ... ) that binds to one of the options
[20:48:03] <ulm> that's the equivalent of slot operator =
[20:48:18] <mgorny> no implementation at the moment, and i have some doubts whether it's possible
[20:48:21] <mgorny> but it's eventually needed
[20:48:50] <mgorny> i.e. for things like ||= ( openssl:= libressl:= )
[20:48:55] <dilfridge> so essentially this means "if you replace A with B, you need to rebuild"
[20:49:00] <ulm> right
[20:49:08] <mgorny> dilfridge: yes
[20:49:17] <mgorny> except when you replace B with A, then the package just keeps using B ;-)
[20:49:31] <dilfridge> wot?
[20:49:40] <mgorny> (assuming they don't block one another)
[20:49:43] -*- WilliamH agrees with dilfridge 
[20:49:55] <dilfridge> and it makes the construct "  ||= ( openssl:0= libressl:0= ) " possible
[20:50:05] <mgorny> yes
[20:50:10] <WilliamH> If I replace a with b, we need a rebuild, but replacing b with a also needs a rebuild?
[20:50:23] <mgorny> WilliamH: only if they block one another
[20:50:26] <WilliamH> or replacing a with b doesn't need a rebuild
[20:50:34] <dilfridge> if package uses B, and A is installed *additionally*, then package keeps using B
[20:50:40] <mgorny> you can't replace A with B unless you uninstall A
[20:51:00] <mgorny> because the left-most item takes precedence
[20:51:19] <mgorny> (replace as in make the package use, you can still install it but it won't be used)
[20:51:34] <dilfridge> you'd need something else that hard-requires B
[20:51:44] <WilliamH> Hmm, ok.
[20:52:07] <mgorny> so let's vote
[20:52:28] -*- dilfridge yes
[20:52:31] -*- tamiko yes
[20:52:43] -*- slyfox abstains
[20:52:52] -*- ulm yes
[20:52:57] -*- K_F yes
[20:53:00] -*- mgorny abstains
[20:53:34] -*- WilliamH abstains
[20:53:40] <mgorny> ok, let's take the next two together 
[20:53:45] <mgorny> Implement nonfatal as both a function and an external command
[20:53:47] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=56249e4d62f7be20d4ebfce02a24a748f702ad71
[20:53:49] <mgorny> Allow die in subshell/subcommand
[20:53:57] -*- K_F yes
[20:54:05] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=7e4140d4ca0ce50de9b1479e24cab0363c246cd5
[20:54:07] -*- ulm yes
[20:54:09] -*- slyfox yes
[20:54:11] -*- tamiko yes
[20:54:14] -*- mgorny yes
[20:54:28] -*- dilfridge yes
[20:54:45] <mgorny> WilliamH: 
[20:55:27] -*- WilliamH yes
[20:55:30] <mgorny> ok
[20:55:33] <mgorny> Group 3: Other changes
[20:55:37] <mgorny> i think we can vote on all of them
[20:55:46] <mgorny> except bash-4.3 which was withdrawn, i think
[20:55:57] <K_F> why was it withdrawn?
[20:56:03] <ulm> it's too early to vote on the bash version
[20:56:14] <mgorny> K_F: because it has no new features and the proposal only came a few days ago
[20:56:21] <mgorny> i mean, no really useful new features
[20:56:30] <ulm> if we are going to update it, we'll likely go for 4.4
[20:56:42] <mgorny> i'm going to paste the items now
[20:56:47] <K_F> I'd say we likely want to use a recent bash version when doing a new EAPI
[20:56:48] <dilfridge> this is the first time I hear of domo (in this context)
[20:56:58] <K_F> but 4.4 might be an argument in itself
[20:57:10] <K_F> voting for 4.3 doesn't exclude bumping to 4.4 for final though
[20:57:34] <ulm> mgorny: I request that we vote on trailing slash removal separately
[20:57:39] <mgorny> ok
[20:57:40] <K_F> but for same reason I'm open to excluding it from vote now
[20:58:14] <mgorny> let's take it for completeness then
[20:58:17] <mgorny> vote: Bash 4.3
[20:58:19] -*- mgorny no
[20:58:28] -*- dilfridge abstains
[20:58:28] -*- ulm abstains
[20:58:32] -*- slyfox abstains
[20:58:58] -*- K_F yes
[20:59:05] -*- tamiko abstains
[20:59:17] <WilliamH> Paste a link?
[20:59:32] <ulm> commit is not pushed yet
[20:59:34] <mgorny> WilliamH: there's no PMS patch for it yet
[20:59:35] <K_F> WilliamH: its just minimal required bash version
[20:59:45] <mgorny> https://bugs.gentoo.org/636652#c2
[20:59:46] -*- WilliamH abstains
[20:59:51] <mgorny> that's feature list
[20:59:54] <WilliamH> hold on let me read
[21:00:27] <mgorny> ok, don't worry
[21:00:30] <mgorny> Empty || ( ) and ?? ( ) groups no longer count as being matched
[21:00:36] <mgorny> this one was requested by Council last time, so we can skip it
[21:00:47] <ulm> bash 4.3 patch: https://paste.pound-python.org/show/JLANuGV1qQbhndySWaxh/
[21:00:51] <WilliamH> ok, question. how long has 4.3 been stable?
[21:01:28] <mgorny> i suppose that's hard to find right now 
[21:01:59] <WilliamH> one sec.
[21:02:08] <mgorny> WilliamH: at least one year, i think
[21:02:26] <mgorny> in Dec 2016 the newest rev was stabilized on alpha
[21:02:49] <WilliamH> Sio again the vote is to require 4.3?
[21:03:06] <mgorny> yes
[21:03:15] <mgorny> for EAPI 7 ebuilds
[21:03:48] <WilliamH> I'm curious what the concern is about doing that (there are a lot of abstentions)?
[21:04:11] <mgorny> WilliamH: it doesn't make a real difference, so why change it? also some are arguing going straight for 4.4 is better
[21:04:42] <K_F> and I say we can still vote for 4.4 before fil␡nal anyways
[21:04:47] <K_F> so nice to have fresher version available when we first do EAPI bump
[21:05:16] <ulm> implementation is trivial, so we can decide last minute
[21:05:20] <mgorny> WilliamH: can we move on?
[21:05:22] -*- WilliamH abstains then
[21:05:26] <mgorny> ok
[21:05:27] <mgorny> Remove trailing slash from {,E}ROOT and {,E}D
[21:05:44] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=c26e4fe8bee772124f48ba0baf6a8a20c0e5c853
[21:05:47] <mgorny> this has gotten a lot of support, and many eclasses and ebuilds are ready for it
[21:06:13] <mgorny> the main idea is to avoid having to do 'weird' "${D}"usr/bin/foo
[21:06:27] <mgorny> ulm: did you want to discuss anything about it?
[21:06:31] <K_F> well, double dashes are handled on OS level anyways, so does it really matter?
[21:06:57] <mgorny> K_F: posix special-cases // for windows nt
[21:07:03] <mgorny> i mean at root directory level
[21:07:18] <mgorny> e.g. "${EROOT}"/foo
[21:07:21] <K_F> I'm all for ${D}/ as I find it easier to write myself, but I'm wondering it it really matters
[21:07:42] <K_F> mgorny: i.e implied CIFS/SMB2 for root
[21:07:54] <K_F> (well SMB at all ..)
[21:08:11] <ulm> https://devmanual.gentoo.org/ebuild-writing/variables/index.html already recommends using ${D%/}/ and so on
[21:08:16] <mgorny> let's vote
[21:08:17] <ulm> section "Trailing Slashes in Variables"
[21:08:28] -*- K_F yes
[21:08:32] -*- mgorny yes
[21:08:33] -*- ulm yes
[21:08:33] -*- dilfridge yes
[21:09:04] <mgorny> tamiko, slyfox, WilliamH
[21:09:17] <slyfox> Will code like "ROOT=/ has_version 'dev-vcs/git[curl]'" become invalid?
[21:09:23] -*- tamiko yes
[21:09:25] <mgorny> slyfox: it's always been invalid
[21:09:44] <mgorny> (you're suppose to use --host-root)
[21:10:13] <WilliamH> Would this mean that $_{D%/} would become ${D}/
[21:10:17] <mgorny> (but it's irrelevant to the change at hand, i suppose it will still work
[21:10:20] <WilliamH> s/_//
[21:10:25] <ulm> WilliamH: yes
[21:10:27] <mgorny> WilliamH: yes
[21:10:30] -*- WilliamH yes
[21:11:03] <mgorny> slyfox: 
[21:11:26] <mgorny> let's finish this and vote on the rest combined
[21:11:48] -*- K_F yes
[21:11:58] -*- slyfox abstains
[21:12:04] <mgorny> ok, so
[21:12:28] <ulm> can you post the list, for later reference?
[21:12:30] <mgorny> Require GNU patch 2.7
[21:12:30] <mgorny> Require einfo and other output functions not to pollute stdout
[21:12:30] <mgorny> Make domo install to /usr instead of DESTTREE
[21:12:30] <mgorny> and everything in 'Removals and bans'
[21:12:34] <dilfridge> I am not sure about the impact of "Ban package.provided in profiles"
[21:12:58] <mgorny> Ban package.provided in profiles
[21:12:58] <mgorny> Ban PORTDIR and ECLASSDIR variables
[21:12:58] <mgorny> Ban DESTTREE and INSDESTTREE variables
[21:12:58] <mgorny> Ban dohtml function
[21:12:58] <mgorny> Ban dolib and libopts commands
[21:13:00] <dilfridge> are you sure nobody in the weird corners (like bsd) still needs that?
[21:13:19] <mgorny> dilfridge: portage support for old-style virtuals is gone for ages now ;-)
[21:13:26] <tamiko> dilfridge: Well, profiles should be able to create a meaningful @system set and package.provided doesn't really make much sense when it comes to bootstrapping.
[21:13:29] <mgorny> (or at least i think so)
[21:13:38] <ulm> dilfridge: we have confirmed with prefix that it's not needed there
[21:13:42] <dilfridge> ok
[21:13:44] <dilfridge> wfm
[21:13:54] <mgorny> so let's vote on the all items listed above
[21:13:58] <ulm> and last time I checked,  they were the only useres
[21:14:02] <ulm> *users
[21:14:03] -*- dilfridge yes
[21:14:06] -*- slyfox yes
[21:14:07] -*- mgorny yes
[21:14:09] -*- tamiko yes
[21:14:15] -*- ulm yes
[21:14:20] -*- WilliamH yes
[21:14:39] -*- K_F already voted yes above, but for consistency..
[21:14:43] <mgorny> ok, so
[21:14:46] <mgorny> 8. Open bugs with Council involvement
[21:14:55] <mgorny> bug #587226
[21:14:57] <willikins> mgorny: https://bugs.gentoo.org/587226 "[PATCH] PMS: Clarify/specify when and how to store the slot/sub-slot part for equals slot operator"; Gentoo Hosted Projects, PMS/EAPI; CONF; aballier:pms
[21:15:51] <mgorny> it seems that aballier is requested council to override PMS/QA interpretation to ban := in ||
[21:16:20] <ulm> I think that doesn't fly
[21:16:22] <mgorny> we've already approved ||= as proper fix in EAPI 7
[21:16:22] <dilfridge> well, we have ||= for this now, right?
[21:16:26] <dilfridge> so this is obsolete
[21:16:34] <K_F> agreed
[21:16:38] <mgorny> dilfridge: assuming ||= will actually be implemented
[21:16:58] <mgorny> in any case, := inside || is half-working in portage
[21:16:58] -*- dilfridge watches some migrant pigs fly past
[21:17:21] <ulm> if ||= cannot be implemented then aballier's feature can't be implemented either?
[21:17:50] <mgorny> well, given he's requesting retroactive change based on half-working portage behavior...
[21:18:10] <mgorny> or rather, he's requesting a wording change that he could exploit to rely on portage behavior
[21:18:18] <ulm> I'd say we should go for the much cleaner ||= solution
[21:18:26] <tamiko> Agreed.
[21:18:31] <mgorny> so let's vote
[21:18:35] -*- mgorny no
[21:18:41] -*- slyfox abstains
[21:18:44] -*- dilfridge no
[21:18:46] <tamiko> mgorny: Please state a wording we vote on
[21:19:08] <mgorny> hmm
[21:19:10] <K_F> I take it we vote on approving the patch, in which case; no
[21:19:20] <mgorny> vote: approve the patch posted on bug #587226
[21:19:21] <willikins> mgorny: https://bugs.gentoo.org/587226 "[PATCH] PMS: Clarify/specify when and how to store the slot/sub-slot part for equals slot operator"; Gentoo Hosted Projects, PMS/EAPI; CONF; aballier:pms
[21:19:29] -*- tamiko no
[21:19:32] <ulm> the council notes := in || doesn't work
[21:19:41] -*- slyfox abstains
[21:19:51] -*- ulm no
[21:20:03] <mgorny> 0:5, does not pass
[21:20:18] <mgorny> bug 634406
[21:20:18] -*- WilliamH abstains for completeness
[21:20:20] <willikins> mgorny: https://bugs.gentoo.org/634406 "larrythecow.org potentially(?) profiting off of Gentoo mascot's name."; Gentoo Foundation, Proposals; CONF; R030t1:trustees
[21:20:30] <K_F> not council territory
[21:20:38] <dilfridge> not our stuff, un-cc
[21:20:39] <ulm> mgorny: I count 0:4 on the last vote
[21:20:49] <tamiko> Jup. What about we vote on:
[21:20:50] <ulm> and 3 abstentions
[21:20:52] <mgorny> WilliamH: sorry, counted wrong
[21:21:04] <mgorny> ulm: yes, exactly
[21:21:24] <mgorny> so vote: un-CC on bug #634406
[21:21:24] <willikins> mgorny: https://bugs.gentoo.org/634406 "larrythecow.org potentially(?) profiting off of Gentoo mascot's name."; Gentoo Foundation, Proposals; CONF; R030t1:trustees
[21:21:32] -*- K_F yes
[21:21:33] -*- tamiko yes
[21:21:35] -*- mgorny yes
[21:21:39] -*- WilliamH yes
[21:21:39] -*- ulm yes
[21:21:41] -*- dilfridge yes
[21:21:44] -*- slyfox yes
[21:21:52] <mgorny> bug #629554
[21:21:54] <willikins> mgorny: https://bugs.gentoo.org/629554 "HPPA arch stabilization problem"; Gentoo Linux, Current packages; IN_P; blueknight:qa
[21:22:11] <mgorny> i think things have improved and we don't have to do anything here
[21:22:26] <slyfox> progress happens :)
[21:22:33] <K_F> lets defer it, see if it keeps up
[21:22:50] <mgorny> i'd say we should close it already
[21:23:03] <mgorny> worst case, it can be reopened if someone feels another action is necessary
[21:23:03] <tamiko> Let's vote on closing and not taking any further action.
[21:23:03] <ulm> what's comment 11 about?
[21:23:16] <slyfox> it's the comment that should be comment1
[21:23:18] <tamiko> dilfridge: ^^^
[21:23:33] <mgorny> ulm: your guess is as good as mine
[21:23:55] <dilfridge> that was my e-mail on -core
[21:23:55] <ulm> slyfox: don't confuse me further, please :)
[21:24:16] <mgorny> i don't think it's really relevant to the topic at hand
[21:24:26] <dilfridge> according to second-hand information, jer was rather perplexed to be trolled by a council member
[21:24:28] <mgorny> so let's vote for closing bug #629554 as fixed
[21:24:28] <willikins> mgorny: https://bugs.gentoo.org/629554 "HPPA arch stabilization problem"; Gentoo Linux, Current packages; IN_P; blueknight:qa
[21:24:42] -*- slyfox yes
[21:24:46] <K_F> its relevant to the extent of why jer stopped working on hppa
[21:24:46] -*- mgorny yes
[21:24:48] -*- dilfridge yes
[21:24:54] -*- K_F no
[21:25:00] -*- ulm abstains
[21:25:06] -*- tamiko yes
[21:25:35] <dilfridge> I tried to talk to jer, which ended up with him telling me that (from memory) I had behaved like a total asshole, which stopped his motivation to work on hppa stabilizations.
[21:25:41] <dilfridge> Pot meet kettle.
[21:26:13] <dilfridge> I dont remember the details anymore, but the logs are somewhere (it was on #gentoo-HPPA).
[21:26:16] <mgorny> WilliamH: 
[21:26:27] <K_F> the email referenced was sent to core 22nd may
[21:26:28] <mgorny> (voting on closing hppa bug)
[21:27:18] -*- WilliamH abstains
[21:27:50] <mgorny> 4:1, 2 abstained
[21:28:01] <mgorny> so we've reached open floor
[21:28:07] <tamiko> \o/
[21:28:11] <ulm> unbelievable :)
[21:28:15] <dilfridge> yes, indeed
[21:28:19] <tamiko> Let the chairman note the time.
[21:28:24] <dilfridge> 150min later ;)
[21:28:25] -*- slyfox won't endure 2.5 hours next time
[21:28:40] <mgorny> now imagine writing the summary for this ;-D
[21:29:13] <dilfridge> not so problematic, it was fairly structured :D
[21:29:15] <mgorny> anyway, thank you all for coming today
[21:29:24] <mgorny> i think we've reached a record on votes
[21:29:25] <dwfreed> is there a rationale somewhere for banning dolib and only dolib of the set? (there's also dolib.a and dolib.so)
[21:29:42] <mgorny> dwfreed: dolib is redundant to dolib.a
[21:29:43] <ulm> dwfreed: exactly :)
[21:30:02] <mgorny> except it's confusing
[21:30:13] <dwfreed> dolib is the only one noted to respect libopts :P
[21:30:14] <ulm> also there's newlib.a and newlib.so but there never was a plain newlib
[21:30:28] -*- WilliamH wondered about that, what is the use case for dolib instead of dolib.so or dolib.a?
[21:30:47] <mgorny> WilliamH: you can do libopts to make it behave non-standard
[21:30:54] <mgorny> except you can also use doins for non-standard stuff ;-)
[21:31:16] <dwfreed> except doins doesn't figure out LIBDIR_${ABI} for you
[21:31:19] <ulm> WilliamH: the conclusion was that there is none, use the .so or .a variant for the right permissions
[21:32:21] <mgorny> anything else on the open floor?
[21:32:24] <dwfreed> so then you have to insinto /usr/$(get_libdir)
[21:32:47] <ulm> no, use dolib.{so,a}
[21:34:10] <tamiko> Ah, these "Closes:" annotations in commits are really neat!
[21:34:23] <dilfridge> Yeah.
[21:34:30] -*- dilfridge loves to close all sorts of stuff.
[21:35:09] <mgorny> I suppose it's time to bang the gavel
[21:35:15] <dilfridge> \o/
[21:35:24] <K_F> mgorny: thanks for chairing, and good luck on the summary
[21:35:30] <mgorny> Thanks everyone
[21:35:33] <dilfridge> thanks & thanks everyone else :)