[18:56:56] !proj council [18:56:57] (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh [18:57:04] ^ T-3, get yourself stacked on food and beverage [18:57:06] -*- tamiko here [18:57:18] -*- dilfridge gets the popcorn [18:57:33] mgorny: Just read the final meeting agenda. Preparing coffee. [18:57:52] just in time :) [18:57:55] 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] (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] ulm: around? [19:00:15] -*- ulm here [19:00:28] WilliamH: *ping* [19:01:12] -*- WilliamH here [19:01:26] i guess we can start then [19:01:33] 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] excellent [19:02:19] 2. Status of old GLEPs [1]. [19:02:23] [1]:https://bugs.gentoo.org/634100 [19:02:49] so here's what i know [19:03:01] GLEP 14 has been reviewed by security@, and they're planning to submit an update [19:03:48] bugday i'm kinda lost [19:04:06] alicef: ^ do you know anything? [19:04:06] https://wiki.gentoo.org/index.php?title=Bugday&action=history [19:04:10] we could submit bug 634100 for the next bugday :) [19:04:11] looks like fturco updated the date again (again) [19:04:13] ulm: https://bugs.gentoo.org/634100 "Reevaluate status of old GLEPs"; Gentoo Council, unspecified; CONF; mgorny:council [19:04:48] but i didn't notice anything spectacular [19:04:57] I long suspected the update was done by a script [19:05:21] i suppose there's no harm in keeping it as-is [19:05:48] so that would reduce the list to: [19:05:48] yes, there is some activity, so I'd say leave it as is [19:05:57] a. marking Final: [19:06:02] 59 Acce 2008-10-22 Manifest2 hash policies and security implications [19:06:07] b. marking Moribund: [19:06:12] 7 Fina 2003-07-06 New ombudsman position [19:06:12] 8 Fina 2003-07-02 Adopt-A-Developer [19:06:12] 36 Fina 2004-11-11 Subversion/CVS for Gentoo Hosted Projects [19:06:32] a single vote for all of that? [19:06:35] wfm [19:06:42] wfm [19:06:44] wfm [19:06:56] so please vote for implementing the above a+b [19:07:01] 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] unanimous [19:07:45] anything else you'd like to add or moving on? [19:08:19] thanks for the work reviewing it [19:08:29] +1 [19:08:31] thanks [19:08:38] ++ [19:08:39] ulm also does great work [19:08:51] Marking a bunch of "deferred" GLEPs as "withdrawn" at some point might be a good idea. [19:09:10] tamiko: not sure if GLEP 1 permits that [19:09:11] But not necessary to discuss that now given the fact that we have a long list of stuff to do today :-) [19:09:18] the idea is that 'withdrawal' happens per submitter's request [19:09:23] tamiko: we had discussed that in the team [19:09:41] 'deferred' is more accurate as it clearly indicates nobody's around [19:09:49] exactly [19:09:58] Roger. [19:10:00] ok, let's move on [19:10:02] 3. GLEP 66 -> Final (Gentoo git workflow) [2,3]. [19:10:02] [2]:https://www.gentoo.org/glep/glep-0066.html [19:10:02] [3]:https://archives.gentoo.org/gentoo-dev/message/d9b0e789caf4679b0df3ececc5246fa1 [19:10:27] LGTM [19:10:37] +1 [19:10:45] this has been discussed in detail last time, so i suppose we can go straight for a vote [19:10:58] vote: Mark GLEP 66 Final [19:11:02] -*- K_F yes [19:11:04] -*- slyfox yes [19:11:05] -*- dilfridge yes [19:11:07] 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] ulm: it's only a warning, so doesn't hurt at the moment [19:11:43] and i'll eventually get to it [19:11:48] k [19:11:49] unanimously approved [19:12:05] 4. GLEP 65 -> Final (Post-install QA checks) [4,5]. [19:12:05] [4]:https://dev.gentoo.org/~mgorny/tmp/glep-0065.html [19:12:05] [5]:https://archives.gentoo.org/gentoo-dev/message/6bdf0ed1bf2587931be7e2f10487f213 [19:12:21] this one may require some more discussion as it hasn't been approved at the last submission [19:12:30] if we accept 74 then 65 is fine too [19:12:33] since then we've done some real work on tree signing [19:12:37] mgorny: does that version differ from https://www.gentoo.org/glep/glep-0065.html? [19:12:43] and this one's gotten post-pkg_postinst checks [19:12:50] ulm: ^ [19:13:12] i.e. the thing portage uses right now to detect missing xdg_update* calls [19:14:12] 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] i mean, those checks work perfectly fine by themselves [19:14:41] it's a matter of personal taste I guess [19:15:01] then again I find 74 perfectly fine and will happily vote for it [19:15:48] ulm: any comments before we vote on 65? [19:16:24] sorry, I've read the version in the glep repo only beforehand [19:16:40] I'd say let 65 require 74 and vote on it now [19:16:44] ulm: want a diff or already got one? [19:16:59] mgorny: please, if you have one ready [19:17:22] 65 is about QA checks, I would suggest to not combine/add dependencies on 74/65. [19:17:39] ulm: http://dpaste.com/16VM6AW [19:17:52] tamiko: the logic is that 74 prevents code injection that is running at pm privileges [19:18:49] dilfridge: but 74 is irrelevant e.g. if you're using git checkout [19:18:55] right [19:19:10] it only affects rsync [19:19:13] I agree, its not a dep in terms of the GLEPs [19:19:28] maybe i'll just add a note on top [19:20:15] Anyway, in my opinion both GLEPs are a great step forward. [19:20:21] yes, definitely [19:21:16] ulm: ready? [19:21:45] looks good [19:22:49] 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] unanimously passed [19:23:39] 5. manifest-hashes -> BLAKE2 (+ SHA512) [6,7]. [19:23:39] [6]:https://bugs.gentoo.org/635344 [19:23:39] [7]:https://archives.gentoo.org/gentoo-dev/message/f2321ebb659d15fd8d1f0188c3f80c74 [19:23:59] the current plan is at: https://archives.gentoo.org/gentoo-dev/message/682618f6d1cf4d63b30577cb1e9bd269 [19:24:11] robbat2: [19:24:35] What is the rationale against SHA-3 (KECCAK) and against using SHA512? [19:24:50] if we aim for a single hash, then why not SHA512 which exists in the tree? [19:24:51] (except that BLAKE/BLAKE2 are sexy) [19:24:56] this looks like security@ material [19:25:09] tamiko: Keccak is slow [19:25:18] I'd probably just keep both SHA512 and BLAKE2B [19:25:24] (if we go for two hashes, then the choice of SHA512+BLAKE2 is okay IMHO) [19:25:28] BLAKE2 is apparently as secure as SHA3 and faster than SHA2 [19:25:32] (belt and suspenders, I know) [19:26:24] 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] Well, Dan Bernstein is well respected enough to put a lot of trust into the Blake family. [19:26:39] the Keccak team themselves have recommended BLAKE2B for many cases [19:26:50] however unlikely that is, BLAKE2 should be safe longer [19:27:15] 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] oh my, if that's all we have to offer :) [19:27:49] Personally, I am fine with SHA512 and/or Blake2B. [19:28:22] well, the main point is to kill duplicate SHA256 and old WHIRLPOOL [19:28:27] i think everyone agrees on that [19:28:28] the prior GLEP only kept SHA256 as a transitional hash, but it was never actually disabled after the transition period [19:28:31] 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] mgorny: ack. [19:28:54] tamiko: AES wasn't rushed [19:29:21] while we're changing hashes, we may as well add something new, to avoid unnecessary change in the future [19:29:23] 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] i.e. do that with one diff [19:30:02] What about we agree on transitioning to SHA512 + Blake2B then? [19:30:14] 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] robbat2 insisted we have a full plan on killing SHA512 to reduce number of hashes eventually [19:30:25] so the main reason for blake is speed, not anythign to do with security [19:30:26] mgorny: I would be fine with the proposal if the automatic "T + 36 months" part was omitted [19:30:34] yes, please, just go to SHA512+BLAKE2B [19:30:46] (without any pre-determined changes of that) [19:30:48] ulm: it's not meant to be automatic [19:30:56] it's more like 'we WILL NOT do that before that time' [19:31:08] so >= T+36months [19:31:16] yes, i forgot to say that in the mail [19:31:19] 36months is also a freking long time. [19:31:24] it's about guarantees to our users [19:31:35] 'in next 36 months things will not explode' [19:31:37] All we have to guarantee is 12 months. [19:31:55] I think it's perceived differently. [19:32:22] I like the long-term plan of mgorny's proposal. [19:32:50] i suppose the Council will have to revisit it later before applying the 'T+36' rule anyway [19:32:50] (and the quick phase-out of whirlpool and sha256) [19:33:27] I'm fine with another vote for the removal , and just deferring it to when it makes sense [19:33:38] and voting on the rest of the proposal [19:33:46] That sounds reasonable to me. [19:33:48] K_F: do we want to keep the 'at least 36 months' guarantee in that? [19:33:55] i.e. that the next vote won't remove it earlier? [19:34:17] mgorny: All we have to really worry about there is the next 12 months. [19:34:35] WilliamH: that's why i specifically wanted to make this one longer because it's more core than packages [19:34:39] 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] K_F: ok then [19:34:49] ack. [19:35:01] it can't harm to mention that this is the roadmap, though [19:35:11] ulm: indeed [19:35:37] 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] passed unanimously [19:36:30] hash browns... [19:36:41] 6. GLEP 74 -> Accepted (Full-tree verification using Manifest files) [19:36:41] [8,9]. [19:36:49] [8]:https://dev.gentoo.org/~mgorny/tmp/glep-0074.html [19:36:49] [9]:https://archives.gentoo.org/gentoo-dev/message/86ef412c10540f7bcb17813aba1b484b [19:37:05] one question on the wording [19:37:35] paragraph "Timestamp verification" [19:37:39] mgorny: remove authors from credits :p [19:37:49] "The Manifest file can contain a TIMESTAMP entry..." [19:38:11] ^ does that mean top-level manifest or also sub-manifests? and what would be the meaning in sub-mainifests? [19:38:19] i'll answer that [19:38:24] dilfridge: top-level [19:38:29] both [19:38:37] or rather, by design [19:38:43] technically it can occur anywhere [19:38:51] consider glsa & news under metadata: they could have an externally generated signed Manifest [19:39:00] with it's own timestamp & signature [19:39:06] right [19:39:38] but gemato is going to take the first present for verification purposes [19:39:44] mgorny: under Modern Manifest Tags it says "Optionally used in the top-level Manifest file." though [19:39:46] i.e. the one in top-level [19:39:52] so another failure mode would be "submanifest timestamp is newer than toplevel manifest timestamp" [19:40:20] ulm: tbh i never thought of robbat2's use [19:40:28] 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] 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] signature timestamp doesn't have to be the same as the TIMESTAMP value [19:41:25] but explicit one doesn't hurt anyways.. [19:41:25] 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] it should probably be newer [19:41:50] if the sublevel timestamp is newer then the hash at top-level would fail, I think [19:41:52] and parsing out TIMESTAMP is a lot easier than the signature timestamp [19:42:07] what ulm said [19:42:09] ulm: not if separately signed [19:42:18] then it wouldn't be part of the top-level mainfest [19:42:25] but it has to be [19:42:28] K_F: it always must be [19:42:44] unless it's explicitly IGNORE-d, then it needs explicit PM support and that's outside the spec [19:43:13] the spec only covers how a single Manifest tree works, and that's talking about two disjoint trees [19:43:21] so amendments: sub-Manifest TIMESTAMP must not be newer than a higher-level TIMESTAMP; [19:43:38] "The sub-Manifest can also be signed using OpenPGP armored cleartext [19:43:38] format. However, the signature verification can be omitted if it is [19:43:38] covered by a signed top-level Manifest." [19:44:02] robbat2: what's the purpose of that? if hash is valid, then sub-timestamp is really irrelevant [19:44:04] that implies it doesn't have to be covered by the top level [19:44:30] K_F: unclear wording [19:44:33] K_F: no, it says the signature doesn't need to be verified, it says nothing about not verifying the manifest [19:44:38] we should change that wording [19:44:43] K_F: s/if/as/ [19:44:53] right, robbat2 says it [19:45:03] might be the intention, its not what it says :) [19:45:34] and if it has to be covered, why bother with signatures on the sub-manifests to begin with [19:45:50] as the chain is preserved by signing the top-level [19:45:51] 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] K_F: it's in the rationale [19:45:58] that also removes some ambiguity c.f compression [19:46:09] 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] the idea is that you can use extra signatures if you want backwards compatibility with old tools [19:46:29] (not that portage verifies signatures) [19:46:42] dilfridge: s/it already is covered/it is already covered/g [19:46:52] 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] and it should anyways be limited in size to categories ++ metadata etc [19:47:21] 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] robbat2: what you think of K_F's argument? compression is your child ;-) [19:48:45] glsa-check can anyways verify the top-level manifest [19:49:03] some consumers of glsa-check sync the glsas without the portdir [19:49:41] robbat2: right, then it might make sense indeed [19:49:54] i'm ok with forbidding the compression of top-level Manifest [19:50:02] i was projecting it to be ~50KB in size in the end [19:50:17] before compression [19:50:28] that should be no problem [19:51:01] one of the original related proposals was to use detached GPG signatures to make that safer [19:51:13] but that got dropped because it was going to add many more tiny files [19:51:22] yup, I thought of that and concluded the same [19:52:06] ok, do we want to vote on pre-approval of this glep today, and start testing deployment on infra? [19:53:03] It think this is a good idea. [19:53:06] with the two changes yes [19:53:29] dilfridge: could you reiterate the changes? [19:53:40] 1) "However, the signature verification can be omitted since it is already covered by the signed top-level manifest." [19:53:40] 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] dilfridge: that's an editorial fix [19:54:06] (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] ) [19:54:25] 2) forbid compression of the top level manifest [19:54:39] i'm wondering if we should have explicit file size limit though [19:54:49] (to avoid vulnerabilities in decompressors) [19:55:26] mgorny: min file size limit before compression etc seems like implementation question, not needed in GLEP [19:55:40] yes [19:55:41] so [19:55:58] i'm good with dilfridge's changes [19:56:11] +1 [19:56:12] 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] passed unanimously [19:56:50] \o/ [19:57:00] (and again, i think it's a security@ material to evaluate the design sanity WRT potential threats) [19:57:08] next item is EAPI 7 [19:57:17] can you guys stay longer today or should we defer it? [19:57:34] -*- tamiko has time [19:57:38] (and instead do quick look over bugs + open floor) [19:57:39] -*- WilliamH has time [19:57:45] slyfox: security-audit and/or crypto@ are likely better places [19:57:47] I'm fine for some more time [19:58:12] ok [19:58:18] 7. EAPI 7 feature/spec pre-approval [10,11,12]. [19:58:25] [10]:https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_7_tentative_features [19:58:25] [11]:https://gitweb.gentoo.org/proj/pms.git/log/?h=eapi-7 [19:58:25] [12]:https://dev.gentoo.org/~ulm/pms/7-draft/ [19:58:50] unlike the previous times, we have full listing + the spec ready [19:59:04] and partial untested portage implementation ;-) [19:59:21] list of features is in [10], or also in https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-194000E [20:00:28] 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] one difference, [10] still lists bash-4.3 [20:01:55] (i have to run, thanks all for hashes & meta-manifest; I did sent a previous answer re larrythecow.org) [20:02:07] robbat2: ok, thanks [20:02:09] the most intrusive changes are IMHO: [20:02:16] - first three items listed under https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_7_tentative_features#New_features [20:02:34] - Remove trailing slash from {,E}ROOT and {,E}D [20:03:08] automatic use enforcing has a dependency on GLEP 73 which isn't approved, so can it be pre-approved per se? [20:03:10] let's just go through the list from top to bottom and discuss / vote [20:03:30] (or start with that and continue next time :) [20:04:03] So we are voting on each individual feature? [20:04:03] *ugh* [20:04:03] K_F: the idea is that EAPI7 supersedes that GLEP [20:04:03] but yeah, let's go one-by-one and see if anybody has comments [20:04:12] most of them are fairly unproblematic, so why not [20:04:13] that should keep the discussion focused [20:04:27] Runtime-switchable USE flags [20:04:32] -*- dilfridge is all for that [20:04:45] this one was approved earlier but deferred due to no impl [20:04:59] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=d3d148235b1debf6fe1de1bea7834d83ae88889a [20:05:01] maybe Zac will do it this time, but i suppose it doesn't hurt to keep it in case [20:05:05] Do we have an implementation now? [20:05:08] right, this only affects dependencies and required use so if a feature has automagic etc [20:05:59] WilliamH: nope [20:06:36] K_F: it's meant to be used for things like python package dependencies [20:06:59] alternative to suggested/recommended deps in other distros [20:07:09] 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] ok for the record shall we vote on it? [20:07:59] -*- dilfridge yes [20:08:00] mgorny: right, but a dlopened() dep seems relevant for it [20:08:16] extension features etc [20:08:27] K_F: well, yes, all kinds of stuff that doesn' t affect build time [20:08:45] iow, stuff that per current policy would be in pkg_postinst [20:08:57] exactly [20:09:03] seems good to me [20:09:16] 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] WilliamH: ping [20:10:23] -*- WilliamH yes [20:10:28] ok, next item [20:10:34] Automatic use enforcing (GLEP 73) [20:10:38] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=dd298e8cd9b90cf623336f97f46e7e16feacdec3 [20:10:53] to be clear, that proposal *replaces* glep73, right? [20:10:54] as i said, the idea is to replace the GLEP73 by PMS [20:11:00] ++ [20:11:09] though GLEP73 still explains how to repoman it [20:11:13] I'm not sure if I like the idea of it though, I typically favor explicit over implicit [20:11:29] Ciaran had some snarky comment about it too but he was as enigmatic as ever [20:11:48] 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] to me required use of gnutls ( ssl ) makes a lot of sense in the discussed scenario [20:12:34] i think i've covered all the obvious and less obvious loopholes [20:13:07] and yes, the main idea is with something like ^^ ( ssl_impl_openssl ssl_impl_libressl ) [20:13:25] it improved the readibility a lot while avoiding unnecessary edits for every package [20:14:12] but it's an intrusive change and i'm ready to withdraw it once initial testing finds major issues [20:14:35] (we can test it on EAPI < 7 packages locally) [20:14:51] vote? [20:14:56] 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] so we have 2:2 [20:17:07] not passed [20:17:36] does that mean we kill it already or give it a chance till an implementation is available for testing? [20:18:05] anyway, next item [20:18:07] BDEPEND and SYSROOT [20:18:16] I'd say the latter, but I've voted yes [20:18:19] let me rephrase. Nothing is stopping you from testing it. [20:18:43] I think if it tests out well its chances are improving. [20:18:47] I think it should not be officially part of the eapi without testing. [20:18:57] is it seen as being too complicated, or what is the issue? [20:19:11] impact not yet predictable for me [20:19:57] I'd need to take some real-world situations and manually go through the algorithm [20:20:16] and that I havent done yet [20:21:03] It seems unpredictable as well to me. [20:21:03] -*- K_F says yes for BDEPEND and sysroot [20:21:17] K_F: we aren't there yet [20:21:27] next item was called [20:21:44] but ulm hasn't pasted the link yet ;-) [20:21:56] it's 6 commits [20:21:58] well, links [20:21:58] could you please explain in one sentence what (BDEPEND and) SYSROOT is? [20:22:06] it's a big change [20:22:12] from "EAPI 7 has SYSROOT and ESYSROOT" to "dependencies: Provide a nice summary table for dep APIs" [20:22:22] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=d2562ca6c8808ffc5e310b1745530204018e8cdb [20:22:24] that summary table probably explains it best [20:22:28] dilfridge: cross compile , built host vs build target build-time dependency [20:22:30] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=3a616e967724ff394381f4d7e955dd69ebe06a7b [20:22:38] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=ceb53f99645fdb940d8d4b3936caf52c8b73610f [20:22:45] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=e04651aa1278c4b81f93feef61a5e0289cd88777 [20:22:51] https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-750008.1 [20:22:51] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=9cf6b9aa665ae2057175b934f0e84bb2a4547bd8 [20:22:59] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=1c9dc0345632b61d729c9374a2d26a4661d992b2 [20:23:08] mgorny: happy now? :) [20:23:11] ;-) [20:23:15] so https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-750008.1 table 8.2 [20:23:26] basically we're splitting build-time deps into CBUILD/CHOST [20:23:35] adding SYSROOT for DEPEND [20:23:47] and sanitizing has_version options [20:24:09] biggest impact is that EAPI 7 ebuilds will have to distinguish between DEPEND and BDEPEND [20:24:14] 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] it's mostly related to cross but i suppose SYSROOT has other uses [20:24:22] DEPEND = dependencies on CHOST system [20:24:33] BDEPEND = dependencies on CBUILD system [20:24:56] dilfridge: yes [20:25:06] thank you! an answer I can understand! [20:25:39] any more questions before we vote? [20:26:00] (this one will also probably require some testing but for regular systems it's not changing much) [20:26:22] the relevant policy would be that developers are free to ignore BDEPEND and let people who care about cross fix it [20:26:48] (like they don't have to be 100% prefix safe right now) [20:26:54] "fix it" = distribute things between BDEPEND and DEPEND [20:27:00] yep [20:27:17] dilfridge: possibly add more cross hacks, add SYSROOT somewhere... [20:27:20] That's a lot of fixing. [20:27:26] cross is crazy [20:27:28] Someone setting up some automatic testing for that? [20:27:34] tamiko: better not ;-) [20:27:36] and mostly unmaintained atm [20:27:39] *hrhr* [20:27:46] ok, let's vote for this then [20:27:51] -*- dilfridge yes [20:27:55] -*- mgorny yes [20:27:55] 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] passed [20:28:17] tamiko: heh that's very true. [20:28:19] by the way, credits go to Chewi for handling all this crazy magic [20:28:31] Profile-defined unsetting of variables (ENV_UNSET) [20:28:52] this is meant to fix the lot of mayhem caused by DISPLAY & XDG_* leaking into ebuilds [20:29:04] https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=24fd4576a11b8f97da9664981cb1df3e1f371d00 [20:29:12] 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] ulm: it's probably irrelevant to real-life use of this [20:29:47] OTOH, the code for that exists in package managers already [20:29:50] except maybe for prefx [20:30:13] any discussion? [20:30:32] what's the case with * now? [20:30:43] not supported [20:30:53] only explicit blacklist [20:30:56] ok [20:31:01] well we can start with that [20:31:07] literal variables [20:31:19] the feature came in late, so I guess we can still adjust implementation details before the final vote [20:31:39]