14:05 <@WilliamH> Ok, let's get started. 14:05 <@WilliamH> The agenda is here: https://archives.gentoo.org/gentoo-project/message/2be6e27c946a5348e27d6e6ec338de04 14:05 <@WilliamH> rol call: 14:05 * WilliamH here 14:05 * slyfox here 14:05 * mattst88 here 14:05 * gyakovlev here 14:05 * dilfridge here 14:05 * Whissi here 14:05 * ulm here 14:06 <@WilliamH> Cool, we're all here. :-) 14:06 <@WilliamH> 2. EAPI 8 approval. 14:06 <@ulm> https://archives.gentoo.org/gentoo-project/message/26ec04fc812d1810b52424b1fe1809c2 14:06 <@WilliamH> Do we have anything to discuss on this? 14:07 <@ulm> should we have just one vote, or vote on changed features first? 14:07 <@WilliamH> It seems not, so let's vote: The council approves EAPI 8. 14:07 <@dilfridge> mgorny had some sort of status board, right? 14:07 <@mattst88> yes, on the Wiki 14:07 <@WilliamH> ah ok. let's wait for mgorny for a minute. 14:07 <@ulm> https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_8_tentative_features 14:07 <@gyakovlev> https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_8_tentative_features 14:07 <@dilfridge> mostly asking because that list still includes non-implemented features? 14:07 <@ulm> yes, it does 14:08 <@dilfridge> ok that's just "Variant of || ( ) with defined runtime behaviour" 14:08 <@ulm> "Variant of || ( ) with defined runtime behaviour" and "RESTRICT value for network-restricted tests" have been dropped 14:08 <@ulm> "Empty working directory in pkg_* phases" and "Ban useq, hasq, and hasv functions" added 14:09 <@dilfridge> ok 14:09 <@dilfridge> good, we have this in the log now 14:09 <@ulm> :) 14:09 <@WilliamH> So do we need to vote on each feature or do we just do one vote for the EAPI? 14:09 <@slyfox> i'm ok for all set 14:09 <@dilfridge> one vote should be fine 14:10 <@gyakovlev> WilliamH: let's do a full vote, if there are disagreements we can go in detail 14:10 <@gyakovlev> by saying full I mean one-for-all 14:10 <@dilfridge> not all-for-one? :D 14:11 <@WilliamH> sounds good to me. 14:11 <+sam_> I was worried for a minute.. 14:11 <@WilliamH> let's vote: The council approves EAPI 8. 14:11 * slyfox yes 14:11 * gyakovlev yes 14:11 * dilfridge yes 14:11 <@ulm> with features as listed in https://archives.gentoo.org/gentoo-project/message/26ec04fc812d1810b52424b1fe1809c2 14:11 * mattst88 yes 14:11 * WilliamH yes 14:12 * ulm yes 14:12 <@mattst88> Whissi: you still here? 14:12 <@WilliamH> the motion passes. 14:12 <@Whissi> I am here. Just checking mail 14:12 <@WilliamH> moving on: 14:12 <@WilliamH> 3. glep 82. 14:12 <+mgorny> i'm around now 14:12 <@WilliamH> bug 793164 14:12 < willikins> WilliamH: https://bugs.gentoo.org/793164 "GLEP 82: Repository configuration file (layout.conf)"; Documentation, New GLEP submissions; CONF; mgorny:glep 14:12 * Whissi is confused because it said restrict network-restricted was dropped but it is in the mail? 14:13 <@Whissi> s/it/ulm/ 14:13 <@ulm> Whissi: it has been implemented as optional token in PROPERTIES 14:13 <+sam_> retrospectively 14:13 <@gyakovlev> WilliamH: we did not get Whissi's voice yet. 14:13 <@ulm> so it doesn't need to be EAPI dependent 14:13 * Whissi yes 14:13 <@WilliamH> gyakovlev: ok, 14:13 <@gyakovlev> now we did it. 14:13 <@ulm> unanimous then 14:13 <@WilliamH> Now we did, so unanimous. 14:13 <@ulm> thank you folks :) 14:14 <@WilliamH> now moving on. 14:14 <+sam_> does it count if the vote was closed? :) 14:14 <@WilliamH> 3. glep 82 (bug 793164)... 14:14 < willikins> WilliamH: https://bugs.gentoo.org/793164 "GLEP 82: Repository configuration file (layout.conf)"; Documentation, New GLEP submissions; CONF; mgorny:glep 14:14 <@gyakovlev> sam_: tsss, that's a bikeshed for a month or two. 14:15 <@dilfridge> sam_: that topic is deferred to the next council 14:16 <@WilliamH> Do we have anything to discuss on glep 82 ? 14:16 <@mattst88> I'm happy with GLEP82. It's just codifying what we've been doing for the last 10 years 14:16 <@dilfridge> ++ 14:16 <@WilliamH> Ok, let's vote: The council approves glep 82. 14:16 * slyfox yes 14:16 * WilliamH yes 14:16 * dilfridge yes 14:16 * Whissi yes 14:16 * gyakovlev yes 14:16 * mattst88 yes 14:17 <@WilliamH> We're missing a vote. 14:17 <@slyfox> ulm: ^ 14:17 <+sam_> he's too busy pushing dates to git ;) 14:17 * ulm yes 14:17 <+sam_> [20:15:56] <+gentoovcs> ulm → proj/pms:eapi-8 (/) Cheat sheet: EAPI 8 approval date 14:17 <@gyakovlev> I had a suggestion for it but can propose it later as an addition after discussion with glep author. 14:18 <@WilliamH> unanimous again. :-) 14:18 <@WilliamH> 4. mark glep 72 final: bug 617612 14:18 < willikins> WilliamH: https://bugs.gentoo.org/617612 "GLEP 72: Architecture stability status file"; Documentation, New GLEP submissions; IN_P; dilfridge:glep 14:19 <@dilfridge> not much left to do here 14:19 <@WilliamH> dilfridge: ok. 14:19 <@gyakovlev> dilfridge: just say yes of it and that's it? afaik it's been working in the wild for long time by now. 14:19 <@mattst88> We're just voting to make it "Final", right? 14:19 <@dilfridge> exactly 14:19 <@dilfridge> it's already in use 14:20 <@WilliamH> Let's vote. the council approves marking glep 72 final. 14:20 <@ulm> yep, jsut about status update 14:20 * slyfox yes 14:20 <@ulm> *just 14:20 * dilfridge yes 14:20 * gyakovlev yes 14:20 * mattst88 yes 14:20 * ulm yes 14:20 * WilliamH yes 14:20 * Whissi yes 14:20 <@WilliamH> unanymous. 14:20 <@WilliamH> grr typo 14:21 <@dilfridge> that was the anonymoose typing 14:21 <@WilliamH> ... moving on. 14:21 <@slyfox> +1 14:21 <@WilliamH> open bugs with council participation. 14:22 <@WilliamH> bug 779451 14:22 < willikins> WilliamH: https://bugs.gentoo.org/779451 "Request to add Gentoo developer business card to Gentoo Artwork"; Gentoo Foundation, Artwork approval; UNCO; alicef:artwork 14:22 <@WilliamH> We are still on that bug. 14:23 <@dilfridge> hmm I think we already decided to close that? 14:24 <+sam_> what is the council actually doing there? 14:24 <@WilliamH> We didn't say to close it, just that we can't do anything one way or another. I will look and put the update on it we came up with last meeting if it isn't there. 14:24 <@dilfridge> not sure 14:24 <@dilfridge> ok why not just un-cc us? 14:24 <@dilfridge> I mean... 14:25 <@mattst88> yes, agreed. let's just un-cc council@ 14:25 <@WilliamH> Ok I can do that. 14:25 <@slyfox> thanks 14:25 <@WilliamH> bug 751010 14:25 < willikins> WilliamH: https://bugs.gentoo.org/751010 "Missing summaries for 20210314 council meetings"; Gentoo Council, unspecified; CONF; ulm:council 14:25 <@WilliamH> I'm up to date with mine. 14:26 <@gyakovlev> 2021-03-14 is still missing, dilfridge 14:26 <@gyakovlev> rest are uploaded. 14:26 <@dilfridge> ah 14:26 <@dilfridge> ok sorry, I thought I was done 14:26 <@dilfridge> the rest is all complete by now 14:26 <@gyakovlev> log is there, just not summary 14:26 <@dilfridge> yes 14:26 <@WilliamH> dilfridge: cool, close this after your latest one is in. 14:26 <@gyakovlev> just 1 small one and we can pass a clean state to next council =) 14:27 <@WilliamH> bug 784710 14:27 < willikins> WilliamH: https://bugs.gentoo.org/784710 "Remove SHA512 hash from Manifests"; Gentoo Council, unspecified; CONF; mgorny:council 14:27 <@Whissi> We also had this one 14:28 <+sam_> an interesting part is how much it'd reduce manifests by 14:28 <@gyakovlev> sam_: especially for go packages 14:28 <@gyakovlev> which can be 2000 lines long 14:28 <@mattst88> I'd prefer some sort of macro-level performance data (if that's what we're claiming is improved) or the manifest size changes for the whole repo, etc 14:28 <+sam_> gyakovlev: exactly 14:28 <+sam_> but as a non-voting person, it might be nice to see some numbers on the bug before a final decision is made 14:29 <+sam_> (however it is obvious it'll be > ~50%) 14:29 <@mattst88> I think the argument that we should have multiple hashes in case one is broken is specious 14:29 <@gyakovlev> sys-cluster/minikube: $ wc -l Manifest 14:29 <@gyakovlev> 2410 Manifest 14:29 <@mattst88> holy... 14:30 <+sam_> gyakovlev: could you quickly use cut to get the size with 1st and 2nd hash and compare? 14:30 <@gyakovlev> mattst88: it takes good 15 minutes to download, 30 seconds to build 14:30 <+sam_> no worries if not 14:30 <@WilliamH> gyakovlev: the line count isn't going to change, but the character count would. 14:30 <@slyfox> the whole ::gentoo is 187MB. I would say it's not a lot. 14:30 <@gyakovlev> WilliamH: yeah by a lot 14:30 <@dilfridge> huettel@pinacolada ~/Gentoo/gentoo/dev-texlive/texlive-latexextra $ wc -l Manifest 14:30 <@dilfridge> 6880 Manifest 14:31 <@Whissi> mattst88: Exactly. Given that some distfiles are also not publicly available (fetch restriction), in case we need to switch hash because of an emergency, we would put some files at risk for no reason. 14:31 <+sam_> I think you're disagreeing with matt, no? 14:31 <+mgorny> $ find -name Manifest -exec cat {} + | wc -l 14:31 <+mgorny> 106451 14:31 <@mattst88> I think so as well; specious == superficially plausible, but actually wrong according to google 14:31 <@Whissi> And robbat2 had the argument to have one hash used by upstream sometimes so you can compare manually, too. 14:32 <@gyakovlev> $ du -hs Manifest* 14:32 <@gyakovlev> 501K Manifest 14:32 <@gyakovlev> 281K Manifest.blakeonly 14:32 <@gyakovlev> $ du -hs --apparent-size Manifest* 14:32 <@gyakovlev> 809K Manifest 14:32 <@gyakovlev> 489K Manifest.blakeonly 14:32 <+sam_> Whissi: I think robbat2 was saying that it's less important nowadays because upstreams are not using uniform hashes 14:32 <@Whissi> No. 14:32 <@Whissi> That was not was he was saying. 14:32 <@Whissi> *what 14:32 <@ulm> we don't use upstream hashes 14:32 <+sam_> oh, I see, yes 14:32 <+mgorny> removing SHA512 means removing 136 bytes from every line 14:32 <@ulm> that's a separate issue 14:33 <@Whissi> But anyway, this was not the main argument. 14:33 <+sam_> ulm: it's not, because robbat2's argument (I agree with Whissi's interpretation now) was that it's useful to have the same hash algorithm as a lot of upstreams, but this is really a convenience thing. 14:33 <+mgorny> so if my math is correct, 13.8 MiB 14:33 <+mgorny> (of apparent size) 14:34 <@gyakovlev> mgorny: it's not much but it's honest work =) 14:34 <@WilliamH> So what is the most common upstream hash? 14:34 <@Whissi> SHA512 14:34 <+sam_> my view is that it's a convenience thing and it doesn't really matter 14:34 <+sam_> all it takes is a few upstreams to not use the same hash and you have to adapt tooling anyway 14:34 <+mgorny> Whissi: [citation needed] 14:34 <@gyakovlev> Whissi: do you have statistic for that? 14:34 <+sam_> it's not a reason to bloat Manifests and I'm not sure if it is definitely SHA512.. 14:35 <@ulm> sam_: it's a different question, and we don't have any mechanism in place to records what hash is used by upstreams 14:35 <@ulm> *record 14:35 <+sam_> ulm: indeed, just a convenience thing, it's not really an argument per se 14:35 <@Whissi> gyakovlev: No statistics... but look for GNU projects. If you will find .md5 files, you will also find .sha256 and .sha512 files. 14:35 <@WilliamH> The more I think about it, I'm not really sure it matters either. 14:35 <@gyakovlev> Whissi: I agree it's more common than blake2b in upstreams, but not the most common among all. 14:35 <@mattst88> I don't know either; X.Org release announcements contain SHA256 and SHA512. GNOME uses SHA256 14:35 <+sam_> I think we'd do best to leave out this population count stuff.. 14:35 <+mgorny> Whissi: i dare guess sha1 is more common 14:36 <@ulm> if Manifest size was an armument we'd use md5 :p 14:36 <@ulm> *argument 14:36 <@Whissi> mgorny: Right. But we don't provide SHA1. 14:36 <+sam_> ulm: MD5 and SHA1! 14:36 <@Whissi> I only looked at what we have. 14:36 <+sam_> Right, let's rewind for a moment 14:36 <+sam_> this is about whether we want to have 2 hashes in the manifest 14:36 <+sam_> it's not about choosing a new one 14:36 <+sam_> popularity is mostly irrelevant in terms of upstream usage 14:36 <+sam_> (we have no evidence right now in terms of that) 14:37 <@WilliamH> Do we know if one is more vulnerable than the other to being compromised? 14:37 <@gyakovlev> we should be more like paludis and not have manifests at all! 14:37 <@slyfox> that's a question for security@ 14:37 * gyakovlev hides 14:37 <@mattst88> We're not cryptographers, so no 14:37 <+sam_> what mattst88 said 14:37 <+sam_> if either were weak, we'd know and it'd be public 14:37 <@Whissi> These are competing algorithms at least. Not the same family, which is good. 14:38 <@Whissi> So if one will fail, the other will hopefully not be affected. 14:38 <+sam_> this is really like saying all developers should have PGP keys of two different types 14:38 <+sam_> RSA and EC 14:38 <+sam_> it's voodoo 14:38 <+sam_> it's true, but it's not really meaningful 14:38 <+sam_> ultimately, if one of these got broken, everyone (inc. us) would be in a lot of trouble 14:38 <@Whissi> There is an important difference: Developer could at any point create a new key. But re-hashing all distfiles in an emergency is impossible. 14:39 <@mattst88> I really don't care if we have multiple hashes. 13.8M seems like a lot, but it's probably < 10% of the whole tree. I'm happy to stop debating and just keep the status quo for now 14:39 <+sam_> that's definitely true, although I suspect we'd have other problems in such a case 14:39 <@dilfridge> let's keep the status quo and close the bug. 14:39 <@Whissi> +1 14:39 <+sam_> I don't think there's a strong case for doing anything 14:39 <+mgorny> Whissi: how probable it is that one hash will be broken in such a horrible way to make it easy to create a meaningful distfile with the same size and matching format? 14:39 <@WilliamH> Personally I don't care either way. ;-) 14:40 <@dilfridge> exactly, it's not that important 14:40 <@ulm> if there was a strong case, we'd have switched to binary or base64 long time ago 14:40 <+mgorny> i don't find it important either but i'd rather not reject it based on Whissi's pseudoarguments 14:40 <@Whissi> mgorny: I dunno. I wouldn't expect a breakage but I'd like to stay prepared. I mean, what do we gain from dropping a second hash? What's the benefit? Just 15mb? 14:41 <@Whissi> In this case it isn't worth it. 14:41 <@ulm> it's 15 MB 14:41 <+mgorny> the benefit is that a package manager doesn't have to implement two hashes 14:41 <@ulm> and I think users can disable hashes in their config 14:41 <@Whissi> In case Python would drop SHA512 support and we would need to pull in an additional lib which bad depgraph just for everyone... that's a different story for example. 14:41 <@ulm> so there's not really a speedup 14:41 <@Whissi> But I don't see something like that. 14:42 <@mattst88> mgorny: python has all of these built-in, right? import hashlib? 14:42 <+sam_> ... does anyone else do 1/2/N hashes? 14:42 <+mgorny> mattst88: think of paludis! 14:42 <@mattst88> lol 14:42 <+sam_> I know Fedora just does one (SHA512) 14:42 <@mattst88> FWIW: python3 -c 'import hashlib; print(hashlib.algorithms_available)' 14:43 <@mattst88> (has blake2b and sha512) 14:43 <@Whissi> And isn't SHA512 the one with better hardware acceleration? *duck* 14:43 <+sam_> Not on my Celeron! 14:43 <@Whissi> In mean in general :p 14:43 * dilfridge joins the Ah Forget It Tendency 14:44 <+sam_> I think so too 14:44 <+mgorny> Whissi: haven't seen anyone reporting blake to be slower 14:45 <+sam_> I'm torn here because I don't really care about arguing on this, but I also feel like we're keeping it even when nobody else is just to feel warm 14:46 <+sam_> does *anyone* feel strongly? :) 14:46 <@Whissi> For keeping, yes. 14:46 <@mattst88> I don't feel strongly one way or another 14:46 <@WilliamH> Not me really. 14:47 <@WilliamH> I don't think there's a strong argument either way. 14:47 <@mattst88> I think this is a pretty good example of bikeshedding, tbh 14:47 <@WilliamH> mattst88: heh 14:47 <@slyfox> i don't care. adding new hashes is natural if we need to transit. having a steady state policy would be nice, but i'd like security@ to declare what is it. 14:47 <@Whissi> Remember that verify-sig discussion? I think mgorny also asked me how likely it is, that a malicious GPG key... I would have said "very likely"... few weeks later we learned about bug 767814 =) 14:47 < willikins> Whissi: https://bugs.gentoo.org/767814 " approved EAPI=8 7-0 in less than 2 minutes. debated something no one really cares about for 15 14:48 <@Whissi> s/very likely/very unlikely/ 14:48 <+sam_> to be fair, a cryptographic break isn't the same thing as an implementation issue 14:48 <+sam_> but yeah, I get it 14:49 <@Whissi> Let's move on 14:49 <@WilliamH> Ok, let's not close the bug and move on. 14:49 <@Whissi> Not closing? 14:49 <@Whissi> You want to continue next month? 14:49 <@WilliamH> one sec. 14:49 <+sam_> please no.. 14:49 <@gyakovlev> yeah gotta leave something unpainted for next council. 14:49 <@slyfox> let's not discuss it next time 14:49 <@WilliamH> lol 14:49 <@WilliamH> one sec 14:50 <@WilliamH> bug 774489 14:50 < willikins> WilliamH: https://bugs.gentoo.org/774489 "GLEP 67: add proxied-maint="" attribute"; Documentation, GLEP Changes; CONF; mgorny:glep 14:50 <@WilliamH> That should be closed. 14:50 <@Whissi> yes 14:51 <@WilliamH> bug 736760 14:51 < willikins> WilliamH: https://bugs.gentoo.org/736760 "Application to Software Freedom Conservancy"; Gentoo Foundation, Proposals; CONF; mgorny:trustees 14:51 <@WilliamH> Why are we still on this bug? 14:51 <+sam_> I think it's just an FYI thing 14:51 <@WilliamH> ok. 14:51 <@WilliamH> no updates then. 14:52 <@WilliamH> moving on. 14:52 <@WilliamH> open floor: 14:52 * WilliamH listens 14:52 <+mgorny> well, yesterday i came up with this idea that it would be nice to somehow summarize the Council term 14:52 <+mgorny> (but it was too late to put it on agenda) 14:53 <+mgorny> still, maybe someone wants to say something 14:53 <@mattst88> Can we ask GSoC admins to form a Gentoo project, make a wiki page, create a mail alias, etc? 14:53 <+sam_> (I have two points to make, but I'll do so in a minute ^^) 14:53 <+sam_> (new topic) 14:53 <@Whissi> There's a mail alias. *duck* 14:53 <@mattst88> It would be nice to know who is involved in GSoC from year to year 14:53 <@slyfox> Creating a project sounds nice. Do they have informal leader? 14:53 <@mattst88> Whissi: ?? 14:53 <@Whissi> Wiki lists gentoo-soc@lists.gentoo.org 14:54 <@mattst88> that's not an alias 14:54 <+sam_> that looks public 14:54 <+sam_> (I had to check) 14:54 <@gyakovlev> that does not look like an alias 14:54 <@Whissi> Ah sorry, you asked about alias. 14:54 <@gyakovlev> damn lag 14:54 <@Whissi> Sorry! 14:54 <+sam_> honestly I didn't realise that existed 14:54 <+sam_> i'm not sure it should exist 14:54 <+sam_> it seems like it'd be much more useful to have us all aware of what's happening 14:55 <+sam_> we could offer help if a student is struggling in e.g. their progress report, and so on 14:55 <@mattst88> so, anyone against asking them to form a real project? 14:55 <@slyfox> nope 14:55 <@gyakovlev> not at all 14:55 <@WilliamH> no 14:55 <@gyakovlev> full on in favor 14:55 <@Whissi> I don't see how a formal project with lead election would work but... 14:55 <@mattst88> great 14:55 <@Whissi> Not sure if a porject must have a lead 14:56 <@WilliamH> Well, I wouldn't necessarily worry about a lead election. 14:56 <@mattst88> Whissi: the same way any regular project would? in fact, since GSoC is a yearly thing, there's a pretty opportune time to select a leader 14:56 <@mattst88> but yeah, I don't really care about that. I just want to be able to know who's involved and contact them 14:56 <@Whissi> mattst88: I would be surprised seeing anyone making a 1y commitment in time =) 14:56 <@Whissi> But sure, go on 14:57 <@gyakovlev> Whissi: why do you always disagree on something? 14:57 <@mattst88> I'd imagine they'd just select a leader immediately before the GSoC process starts for the year? 14:57 <@WilliamH> moving on, next topic: 14:57 <@mattst88> that seems like a pretty obvious thing to do, doesn't it? 14:57 <@Whissi> gyakovlev: If you see having an opinion as disagreement, *shrug* 14:58 <@mattst88> so can I say "Council asks GSoC admins to form a project"? 14:58 <@Whissi> yes 14:58 <@WilliamH> fwm 14:58 <@mattst88> Whissi: it's that you just bring up trivial problems that don't really block anything, and then we spend a lot of time trying to figure out if you're actually against something or not 14:59 <@Whissi> Because people often do quick solutions without thinking to the end and I don't like that. 14:59 <@gyakovlev> Whissi: but having different opinion is disagreement =) 15:00 <+sam_> It might help if, when playing devil's advocate, we say so 15:00 <+sam_> "I agree/disagree with X, but can we just talk about Y for a minute?" 15:00 <+sam_> that way, we're a bit clearer on where people are coming from 15:00 <@Whissi> A different opinion would be "I am against..." - I just said that I don't see how a project would fit at all and shared why but as said, I am not blocking. 15:01 <+sam_> (maybe people interpret some things as agree/disagreement, if you're just trying to explore a topic, so making it clearer could help) 15:01 <@slyfox> i assume there is someone in contact with google each year 15:01 <@slyfox> that would be a natural point of contact to list (leader or not) 15:01 <@WilliamH> slyfox++ 15:01 <+sam_> not sure if that's one or many people 15:01 <@gyakovlev> well, 6 people see value, 1 don 15:01 <+sam_> but agreed 15:01 <@gyakovlev> t 15:01 <@gyakovlev> idk... 15:02 <+sam_> (I mean: natural choice is definitely that person(s) speaking to Google) 15:02 <@gyakovlev> there should be official entry point to avoid something, you know =) 15:02 <+sam_> okay okay 15:02 <+sam_> all happy with asking GSoC to officially form a project? 15:02 <@dilfridge> let's ask the other way around, what reason is there *not* to have a normal project? 15:02 * dilfridge yes 15:02 <@WilliamH> brb stepping away for a second 15:03 * slyfox yes 15:03 * mattst88 yes 15:03 * ulm yes 15:03 <+sam_> let's wait for whissi and WilliamH but I think they both already expressed a view 15:04 <@dilfridge> more than one? 15:04 <+sam_> (and gyakovlev) 15:04 * Whissi yes 15:04 * gyakovlev yes 15:04 <@mattst88> sam_: did you have something else you wanted to bring up? 15:04 <+sam_> hi, yes! 15:04 <@mattst88> I'd say go ahead 15:04 <+sam_> it's a two-parter about EAPIs 15:05 <+sam_> 1. Would council be willing to declare EAPI 6 deprecated after 27th June? (That's when it's been 3 years). 15:05 <+sam_> 2. I'd like to include an unofficial request re EAPI 8: we should try clean up eclasses and take the opportunity before adding new EAPI support. i.e. we should encourage people to put the EAPI 8 support patches to the ML, even if it's e.g. cmake.eclass (which is sometimes seen as kde@'s purview), in order to ensure we maximise such opportunities to cleanup indirect inherits and so on. 15:05 <@WilliamH> I don't have a strong opinion, but a project would be helpful. 15:05 <+sam_> ---- 15:06 <@ulm> sam_: let's wait for eapi 8 to go live, before deprecating 6 15:06 <+amadio> Hi, I think the mail alias is soc-mentors@gentoo.org 15:06 <+sam_> ulm: completely fine with me, I just wanted to raise it 15:06 <@gyakovlev> sam_: also, maybe it's more QA territory, I'd like for eclasses to add future guards against new EAPIs. ALL eclasses, no matter what they do. 15:06 <@slyfox> deprecating EAPI=6 sounds like a good agenda item for next council meeting. I'd also suggest posting to -dev@ ML 15:06 <@ulm> otherwise we may end up with 6 -> 7 -> 8 updates when it could be 6 -> 8 directly 15:07 <@mattst88> amadio: I thought that might be the case as well, but it's not clear and the name suggests that it might not include the administrators 15:07 <@dilfridge> let's deprecate 6 when 8 becomes acceptable for stable? 15:07 <@mattst88> amadio: I guess we'll figure it out when we ask them :) 15:07 <@gyakovlev> sam_: I've seen to many eclasses without future eapi guard break silently and unexpectedly. this should not be the norm. 15:07 <@ulm> dilfridge: something like that, yes 15:07 <+sam_> gyakovlev: 100% agreed, let's take it to QA first and go from there 15:07 <+sam_> dilfridge, ulm, slyfox: that sounds fine with me, thanks for comments guys 15:08 <@dilfridge> also, we still have EAPI=5 around and it will take a bit to remove it 15:08 <@dilfridge> about 1500 ebuilds 15:08 <+sam_> yeah, give me a few weeks.. ;) 15:08 <@ulm> yes, time to ban 5 15:08 <@dilfridge> ^^ 15:08 <@gyakovlev> sam_: can you put my item as part of your item 2 maybe? 15:08 <+amadio> I think forming a project is a good idea. I've just co-mentored a project in the past, so I'm in the mailing lists. 15:08 <+sam_> gyakovlev: ok, one sec 15:08 <@gyakovlev> amadio: thanks for real feedback 15:08 <@dilfridge> ++ 15:08 <@gyakovlev> from an actual participant 15:08 <+sam_> (please hold...) 15:09 <@dilfridge> (elevator music) 15:09 <+sam_> 2. I'd like to include an unofficial request re EAPI 8. We should try clean up eclasses before adding EAPI 8 support to them. This includes adding future EAPI guards on changes, but also clean up indirect inherits and so on. We encourage people to put the EAPI 8 support patches to the ML, even if it's e.g. cmake.eclass (which is sometimes seen as kde@'s purview), in order to ensure we maximise such opportunities. 15:10 <+sam_> would council be willing to endorse that statement? 15:10 <@mattst88> I'm fine with that 15:10 <@dilfridge> sounds ok to me 15:10 <+sam_> (note: EAPI guards are important because it means we don't have to audit them in a hurry to make sure we're not breaking something retrospectively, and forces us to do a check and modernise them at the point of a new EAPI, which is a nice periodic refresh.) 15:11 <@slyfox> do we still have nontrivial eclasses without guards? 15:11 <@gyakovlev> yes, i'd even go as far as not having an EAPI=9 guard on adding EAPI=8 support a bug. 15:11 <@gyakovlev> slyfox: there were cases, yes 15:11 <+sam_> I have been working to include these, but we still have some 15:11 <@gyakovlev> idk as of right now, but worth checking 15:12 <@slyfox> maybe pkgcheck should test for eclass sourcability with EAPI=nonexistent :) 15:12 <@mattst88> not a bad idea 15:12 <@gyakovlev> I know a couple of java ones that still confuse BDEPEND and RDEPEND and break on that ground, because nobody guarded EAPI=7 15:12 <+sam_> that's a cute idea actually 15:12 <+sam_> thanks slyfox 15:12 <@dilfridge> yes, good idea 15:12 <+sam_> slyfox: if you don't, I will file a bug for this with pkgcheck 15:12 <@WilliamH> We could actually clean up some of the guards too. 15:13 <@slyfox> please do file a bug 15:13 <@gyakovlev> slyfox: even EAPI=9 should be illegal imo 15:13 <+sam_> ofc 15:13 <@slyfox> gyakovlev: not for long perhaps :) 15:13 <+sam_> WilliamH: agreed, full cleanup time (without bikeshedding, just doing as much as we can) 15:13 <@WilliamH> I've seen eclasses with two different guards... one for "too old" eapis and one for "unknown eapis" or similar... 15:13 <@gyakovlev> WilliamH: it should be the norm 15:13 * sam_ nods 15:14 <@WilliamH> I've always thought it should just have valid eapis the eclass supports and die for all others. 15:14 <+sam_> yeah, that's what I'd like to enforce going forward 15:14 <@gyakovlev> but helpful message is nice though 15:14 <+sam_> or at least 'kindly request' ;) 15:14 <@gyakovlev> saying if it's too old or unknown 15:14 <@WilliamH> gyakovlev: sure, but not two messages. 15:14 <+sam_> honestly, I dare say that's something for QA policy 15:15 <+sam_> not saying I agree/disagree, but it's a nit :) 15:15 <@WilliamH> Basically I've seen things like (pseudo code).... 15:15 <@ulm> it's normally clear, so IMHO no need for two messages 15:15 <+sam_> let's not worry about the exact details of phrasing of dies 15:15 <@WilliamH> if eapi is valid... 15:15 <@WilliamH> no message 15:15 <@WilliamH> if it is an old eapi 15:15 <@WilliamH> one message 15:15 <@WilliamH> else 15:15 <@WilliamH> another message saying it is unsupported 15:15 <@WilliamH> So you just need one message. 15:16 <@mattst88> okay guys. I'm bored :) 15:16 <+sam_> I think on balance I'd prefer one but it's orthogonal here 15:16 <@WilliamH> ulm++ 15:16 <+sam_> let's move on 15:16 <+sam_> is everyone happy endorsing, or no? 15:16 <@WilliamH> any more topics? 15:16 <@slyfox> sure 15:16 * gyakovlev yes 15:16 * mattst88 yes 15:16 <@ulm> fine with me 15:16 <@WilliamH> fwm 15:16 <@dilfridge> wfm 15:17 <@gyakovlev> Whissi: ? you still here? 15:17 * Whissi yes 15:17 <@WilliamH> any more topics? 15:17 <+sam_> all good, back to you WilliamH 15:17 <+sam_> thanks guys 15:17 * WilliamH listens for a minute. 15:18 * WilliamH bangs the gavel 15:18 <@WilliamH> meeting closed