2022-08-14 19:00:01 @gyakovlev !proj council 2022-08-14 19:00:03 willikins (council@gentoo.org) ajak, dilfridge, gyakovlev, mattst88, mgorny, sam, ulm 2022-08-14 19:00:12 @gyakovlev and jsmolic as proxy 2022-08-14 19:00:15 @gyakovlev meeting time! 2022-08-14 19:00:25 * ajak here 2022-08-14 19:00:28 * mattst88 here 2022-08-14 19:00:32 * jsmolic here 2022-08-14 19:00:39 * gyakovlev here 2022-08-14 19:01:02 * ulm here 2022-08-14 19:01:19 * mgorny here 2022-08-14 19:01:46 * gyakovlev pokes sam with a stick 2022-08-14 19:02:08 @ajak he told me he might be a minute 2022-08-14 19:02:12 @ajak struggling with heat 2022-08-14 19:03:13 @gyakovlev I almos rushed my cat to vet today - she's been breathing really fast with open mouth and tried to sneak into the fridge. 2022-08-14 19:03:21 * sam_ here 2022-08-14 19:03:26 @gyakovlev 30c inside... 2022-08-14 19:03:36 @gyakovlev ok everyone is here 2022-08-14 19:03:43 @gyakovlev agenda for today: 2022-08-14 19:03:43 @gyakovlev https://archives.gentoo.org/gentoo-project/message/77286085094c5f747b6fff164717e000 2022-08-14 19:04:04 @gyakovlev 1. Roll call just happened, everyone is here, jsmolic is proxy for dilfridge 2022-08-14 19:04:16 @gyakovlev 2. Change the status of GLEP 13 to moribund (ulm) [1] 2022-08-14 19:04:57 @ulm rationale is in bug 853166 2022-08-14 19:04:57 willikins https://bugs.gentoo.org/853166 "GLEP 13 is obsolete"; Documentation, GLEP Changes; CONF; ulm:glep 2022-08-14 19:05:13 @gyakovlev GuideXML is long gone afaik 2022-08-14 19:05:15 @ajak makes sense to me 2022-08-14 19:05:22 @sam_ i'm surprised we didn't do that long ago 2022-08-14 19:05:23 @ulm also there's no Gentoo Documentation Project any more 2022-08-14 19:05:38 @mattst88 let's vote and move on? 2022-08-14 19:05:38 @ajak yeah, 6 years of de facto uselessness is a long time :) 2022-08-14 19:05:45 +jsmolic Yep, makes sense to remove outdated files 2022-08-14 19:06:05 @gyakovlev ok let's vote, motion: Change the status of GLEP 13 to moribund 2022-08-14 19:06:07 * gyakovlev yes 2022-08-14 19:06:10 * ajak yes 2022-08-14 19:06:12 * mgorny yes 2022-08-14 19:06:12 * sam_ yes 2022-08-14 19:06:16 * mattst88 yes 2022-08-14 19:06:17 * jsmolic yes 2022-08-14 19:06:18 * ulm yes 2022-08-14 19:06:22 @ulm thanks 2022-08-14 19:06:40 @gyakovlev motion passes with all y votes 2022-08-14 19:06:53 @gyakovlev next item (also ulm) 2022-08-14 19:06:53 @gyakovlev Approval of GLEP 83 2022-08-14 19:07:09 @gyakovlev https://archives.gentoo.org/gentoo-project/message/f7d00cf127ff8ca96aeaaf2ee209010c 2022-08-14 19:07:25 @gyakovlev it's the eapi deprecation one 2022-08-14 19:07:51 @ulm text of the draft: https://www.gentoo.org/glep/glep-0083.html 2022-08-14 19:08:18 @ulm this tries to standardise the criteria we've been using 2022-08-14 19:08:30 @sam_ to me, there's nothing controversial about it at all, just codification, which is a great thing indeed 2022-08-14 19:08:57 @sam_ it's a nice step in moving away from unwritten rules and such 2022-08-14 19:08:58 @ulm gives pretty similar times for EAPIs 4 and 5, for the ones before it's somewhat off 2022-08-14 19:09:08 @mgorny and i don't think there were any negative replies to the final version 2022-08-14 19:09:21 @sam_ yep 2022-08-14 19:09:34 @gyakovlev ok lets vote? 2022-08-14 19:09:37 @ulm I'd suggest to label it as "active" immediately 2022-08-14 19:09:42 --> jstein (~jstein@gentoo/developer/jstein) has joined #gentoo-council 2022-08-14 19:09:42 -- Mode #gentoo-council [+v jstein] by ChanServ 2022-08-14 19:09:55 @gyakovlev motion: approve grep 83 and label it active immediately 2022-08-14 19:09:56 @ulm because there's no implementation that we must wait for 2022-08-14 19:09:59 * mgorny yes 2022-08-14 19:10:03 * gyakovlev yes 2022-08-14 19:10:05 @sam_ yeah, i don't see the point in burdening us with another vote later 2022-08-14 19:10:06 * ajak yes 2022-08-14 19:10:06 * sam_ yes 2022-08-14 19:10:08 * jsmolic yes 2022-08-14 19:10:15 * mattst88 yes 2022-08-14 19:10:16 * ulm yes 2022-08-14 19:10:27 @mattst88 (how will we know when an EAPI becomes deprecated?) 2022-08-14 19:10:46 @mattst88 since it's 24-months after ... -- do we need some kind of calendar or reminder? 2022-08-14 19:11:08 @ulm yeah, I'll see if I can come up with some tooling that will remind us :) 2022-08-14 19:11:13 @mattst88 sounds good 2022-08-14 19:11:18 @gyakovlev sgtm too 2022-08-14 19:11:35 @gyakovlev ok motion passed with all y votes 2022-08-14 19:11:42 @gyakovlev moving to next item: 2022-08-14 19:11:42 @gyakovlev Multilib implementation finalization 2022-08-14 19:11:59 @gyakovlev not sure if soap is here or needed 2022-08-14 19:12:04 @gyakovlev rationale is here: 2022-08-14 19:12:04 @gyakovlev https://archives.gentoo.org/gentoo-project/message/f49bee8e7ff58f8d28cba5d659b55b88 2022-08-14 19:12:24 @sam_ he's travelling at the moment 2022-08-14 19:12:39 @gyakovlev ah yeah, remember he mentioned the flight 2022-08-14 19:13:09 @mattst88 I look at this as codifying what is already the case, and has been for a long time 2022-08-14 19:13:31 @sam_ mattst88 can probably speak best about his experience with some of the bugs being filed for multilib-portage 2022-08-14 19:13:31 @ulm IMHO item 2 there is micro-management. we should leave it to the portage project 2022-08-14 19:13:41 @gyakovlev ok, so do we need a discussion on it? 2022-08-14 19:13:42 @gyakovlev seems like sensible thing to do, should have been done long ago. 2022-08-14 19:13:42 @gyakovlev to me it's more like just setting in stone current situation. 2022-08-14 19:13:44 +jsmolic yeah, especially points 2 and 3 2022-08-14 19:13:49 @sam_ (as GNOME in particular gets badly affected because of the introspection stuff) 2022-08-14 19:14:21 @mattst88 yeah, I've seen a number of bugs filed by the author of portage-multilib where he hides the fact that the reported issue is only reproducible with portage-multilib 2022-08-14 19:14:38 @mattst88 and it's just a waste of people's time to try to help in this case 2022-08-14 19:15:01 @ulm it's still actively maintained though? at least I see some commits from this year 2022-08-14 19:15:03 +ionen I've gotten one for nvidia-drivers before and it wasn't fun to try that thing, currently it ignores abi_x86_* USE entirely so any ebuild checking those is broken by default 2022-08-14 19:15:08 @sam_ anyway, I think it's a good idea, and the status quo leads to confusion from both developers and users (I've seen users add the multilib overlay thinking it was necessary). there is no "debate" over a solution for multilib anymore and we've standardised on the approach in the eclass. 2022-08-14 19:15:34 @sam_ the bugs reported tend to be lacking in detail, there's no much documentation for multilib-portage, and in reality, it's not supported 2022-08-14 19:15:37 @mgorny i don't mind people working on their custom solutions but i really dislike the fact that they are deliberately causing confusion 2022-08-14 19:15:42 @gyakovlev ulm: maintained or not, it has exactly 1 user. 2022-08-14 19:15:48 @mattst88 ulm: dunno, I think the point is really that even if it's getting commits, it's just by one person who has been doing it by himself for 10 years 2022-08-14 19:15:50 @gyakovlev nobody is going to test or validate it 2022-08-14 19:16:00 @sam_ fwiw I actually tried it out a few months ago and I had to scavenge for distfiles as a bunch of the SRC_URIs in the overlay were gone 2022-08-14 19:16:06 @sam_ i really doubt anyone is using it apart from tommy 2022-08-14 19:16:12 +jsmolic it seems to be a one-man project really, yes 2022-08-14 19:16:48 @sam_ does anyone have any concerns here? 2022-08-14 19:17:06 @gyakovlev ok let's do itemized vote: 2022-08-14 19:17:06 @gyakovlev 1. Declare the current multilib solution (multilib-minimal.eclass, 2022-08-14 19:17:07 @gyakovlev [${MULTILIB_USEDEP}] usedeps) the final _de facto_ and _de jure_ 2022-08-14 19:17:07 @gyakovlev approach Gentoo has chosen to take with respect to the multilib problem. 2022-08-14 19:17:14 @mattst88 (I'm happy to strip out #2 and let the portage project handle potentially removing the branch from portage.git) 2022-08-14 19:17:38 @gyakovlev yeah ^ i thought the same. 2022-08-14 19:17:47 * ajak yes, though i think 1 probably naturally leads to 2 2022-08-14 19:18:04 @sam_ yeah, i don't really see the point in stripping it, 2 is just about making it explicit that it's okay to do so, but w/e 2022-08-14 19:18:30 @ulm not sure if removing branches is good practice. retiring yes, but keep the history? 2022-08-14 19:18:43 @mattst88 yeah, true -- it's just asking for council's blessing. sam is right 2022-08-14 19:19:17 @gyakovlev ok let's do the following vote 2022-08-14 19:19:17 @gyakovlev Motion: Declare current multilib solution (multilib-minimal.eclass) final, maintainers are free to close alternative implementation bugs as INVALID, WONTFIX etc. 2022-08-14 19:19:17 +jsmolic I think point 2 seems okay, to get the approval, and Portage team can choose how to handle it in way they think is best 2022-08-14 19:19:28 * gyakovlev yes 2022-08-14 19:19:33 * mgorny yes 2022-08-14 19:19:40 @ajak ulm: i think the issue is that it's really independent from portage (ie, never going to be merged) and as such doesn't belong in portage.git 2022-08-14 19:19:41 * ajak yes 2022-08-14 19:19:42 * ulm yes 2022-08-14 19:19:44 @mattst88 ulm: I think the real objective is to make it crystal clear that the multulib branch is not an official project, and removing it from the official portage.git sends that message 2022-08-14 19:19:53 * jsmolic yes 2022-08-14 19:19:53 * mattst88 yes 2022-08-14 19:20:08 @ajak so, surely the parties that care about it can continue it elsewhere than portage.git 2022-08-14 19:20:20 @ulm ajak: mattst88: ok, I hadn't looked at it from that perspective 2022-08-14 19:20:23 +jsmolic yes, having the branch in portage.git might look confusing 2022-08-14 19:20:24 @ajak there's just no need for it to be under the portage project's resources 2022-08-14 19:20:27 @gyakovlev sam_ ? vote? 2022-08-14 19:20:30 * sam_ yes 2022-08-14 19:20:53 @gyakovlev ok motion passes. 2022-08-14 19:20:53 @gyakovlev we just ask portage team handle the branch handling 2022-08-14 19:21:25 @gyakovlev moving on 2022-08-14 19:21:29 @gyakovlev 5. Approve draft of GLEP 78 (Sheng Yu, mgorny) 2022-08-14 19:21:36 @gyakovlev it's the binpkg format glep 2022-08-14 19:21:51 @gyakovlev https://gitweb.gentoo.org/data/glep.git/tree/glep-0078.rst 2022-08-14 19:22:14 @mgorny Sheng Yu has been doing great work there, and i basically don't have anything to add 2022-08-14 19:22:21 @mgorny he has figured out stuff that didn't even occur to me 2022-08-14 19:22:51 @sam_ portage-3.0.31+ implements this and we've had no real bugs either 2022-08-14 19:22:59 @mattst88 awesome, I'm really excited to see this 2022-08-14 19:23:00 @gyakovlev Zac is aware of this too right? 2022-08-14 19:23:21 @sam_ https://github.com/gentoo/portage/blob/master/NEWS#L157 2022-08-14 19:23:24 +ionen been using it for some time myself too, good stuff 2022-08-14 19:23:57 @sam_ gyakovlev: yeah, the PR was open for a very long time, and he'd commented on it quite a bit 2022-08-14 19:24:12 @sam_ but I've been handling recent releases as he's busy right now 2022-08-14 19:24:28 @gyakovlev ok let's vote I guess. 2022-08-14 19:24:28 @gyakovlev motion: Approve draft of GLEP 78 2022-08-14 19:24:38 * mattst88 yes 2022-08-14 19:24:39 * ajak yes 2022-08-14 19:24:39 * sam_ yes 2022-08-14 19:24:40 * jsmolic yes 2022-08-14 19:24:42 * gyakovlev yes 2022-08-14 19:24:46 * mgorny yes 2022-08-14 19:24:50 * ulm yes 2022-08-14 19:25:04 @gyakovlev passed with all y votes, thanks! 2022-08-14 19:25:40 @gyakovlev next item is a bit poorly worded, but let's start a discussion and re-phrase if required 2022-08-14 19:25:41 @gyakovlev 6. Request a status update along with complete information about the 2022-08-14 19:25:41 @gyakovlev current options from the Foundation regarding umbrella options. 2022-08-14 19:25:41 @gyakovlev Make a decision on which of these options to follow. (mgorny) [6] 2022-08-14 19:26:01 @sam_ NeddySeagoon made a comment on the ML about this: https://archives.gentoo.org/gentoo-project/message/a6f135659f592c05b85e55eaac4d31d6 2022-08-14 19:26:08 @sam_ I don't think any of us were planning on an actual decision based on the options today though 2022-08-14 19:26:19 @sam_ it's more that we should make a decision based on the info when we get it 2022-08-14 19:26:22 @gyakovlev yeah it was clear to me it's just an action starter, not finalizer 2022-08-14 19:26:26 * sam_ nods 2022-08-14 19:26:28 @ajak yeah, just trying to see where the ball has rolled so far 2022-08-14 19:26:39 @mgorny yes, it's just about asking foundation for the options officially 2022-08-14 19:27:15 @mattst88 I don't even know what happened with the foundation election 2022-08-14 19:27:25 @mattst88 i.e., who are the current trustees 2022-08-14 19:27:43 @ajak current trustees appoint new ones at agm, i think? 2022-08-14 19:27:43 @sam_ very healthy situation for sure 2022-08-14 19:28:00 @sam_ suffice to say I'm very happy with us moving forward on requesting this info 2022-08-14 19:28:05 @mgorny trustees stay the same until the AGM 2022-08-14 19:28:08 @mattst88 but yes, let's please get the info we want and try to put this thing to bed 2022-08-14 19:28:29 @ajak according to neddy in -trustees, deadline for agm is 2022-09-23 2022-08-14 19:28:38 @gyakovlev I'm stuggling to re-phrase it into actionable item. help? 2022-08-14 19:29:02 @sam_ change last sentence to "Once that information is received, council should make a..." 2022-08-14 19:29:28 @gyakovlev let's just drop last part and make it an action item later? 2022-08-14 19:29:31 @sam_ sure 2022-08-14 19:29:34 @mattst88 "Council requests a status update from the Foundation regarding umbrella organizations." 2022-08-14 19:29:38 @sam_ even better :) 2022-08-14 19:30:41 @gyakovlev so we are voting for us to ask? =) 2022-08-14 19:30:50 @mattst88 sure, let's just vote 2022-08-14 19:30:54 @gyakovlev motion: Council to request a status update from the Foundation regarding umbrella organizations 2022-08-14 19:30:56 @mattst88 seems quickest 2022-08-14 19:31:01 * mattst88 yes 2022-08-14 19:31:02 * gyakovlev yes 2022-08-14 19:31:03 * jsmolic yes 2022-08-14 19:31:08 * ajak yes 2022-08-14 19:31:14 * mgorny yes 2022-08-14 19:31:30 * ulm yes 2022-08-14 19:31:40 * sam_ yes 2022-08-14 19:31:43 @mgorny hmm, though perhaps we should make it clear that we're requesting complete details 2022-08-14 19:31:47 @sam_ i think they know 2022-08-14 19:31:51 @gyakovlev passed. 2022-08-14 19:31:51 @sam_ if we don't get it, we can shout 2022-08-14 19:31:51 @gyakovlev who's going to take the ball? =) 2022-08-14 19:31:52 @mgorny not just something like "nothing new" 2022-08-14 19:32:11 @gyakovlev passed with all y votes (for log) 2022-08-14 19:33:02 @mattst88 I've gotta run now (moving house, and the wife is waiting for my help to move furniture) 2022-08-14 19:33:06 @gyakovlev I saw antarus's comments earlier, so believe foundation is aware indeed. 2022-08-14 19:33:06 @gyakovlev but I guess we need papertrail email inquiry 2022-08-14 19:34:18 @gyakovlev ok let's move to next item 2022-08-14 19:34:18 @gyakovlev bugs with council invovement 2022-08-14 19:34:23 @gyakovlev !bug 835152 2022-08-14 19:34:24 willikins gyakovlev: https://bugs.gentoo.org/835152 "Mirror pkgcore/* repos from github"; Gentoo Infrastructure, Git; CONF; sam:infra-bugs 2022-08-14 19:35:05 @sam_ arthurzam: what should we do there? 2022-08-14 19:35:08 @gyakovlev sam_ arthurzam any news here? 2022-08-14 19:35:18 @gyakovlev this is just mirror to infra right? 2022-08-14 19:35:20 @sam_ yeah 2022-08-14 19:35:24 +arthurzam Done on gitlab.g.o 2022-08-14 19:35:31 @sam_ ok i think that's good enough for now 2022-08-14 19:36:14 @gyakovlev ok thanks, progress happening, good enough 2022-08-14 19:36:16 +arthurzam Maybe I will move it to gitweb from gitlab and then push to github & gitlab - didn't decide yet, but I think bug can be closed or removed from council? 2022-08-14 19:36:29 @gyakovlev yeah I'll uncc council 2022-08-14 19:36:35 @gyakovlev unless someone objects 2022-08-14 19:36:40 @gyakovlev next bug: 2022-08-14 19:36:40 @gyakovlev !bug 176186 2022-08-14 19:36:41 willikins gyakovlev: https://bugs.gentoo.org/176186 "Gentoo projects file hosting"; Gentoo Infrastructure, Other; IN_P; dsd:infra-bugs 2022-08-14 19:36:43 @sam_ fine with me 2022-08-14 19:37:17 @sam_ we're waiting for infra on that one but it's such a big issue that i feel like we should stay on it 2022-08-14 19:37:24 @sam_ it's a long-standing complaint 2022-08-14 19:37:35 @gyakovlev I'm not logged into bugzilla on this machine and main machine is still down... will uncc later then. 2022-08-14 19:37:45 @sam_ robin is away moving at the moment so nothing has happened there 2022-08-14 19:38:01 @gyakovlev ok let's keep monitoring. 2022-08-14 19:38:23 @gyakovlev that's all for bugs 2022-08-14 19:38:32 @gyakovlev __Open floor__ 2022-08-14 19:38:53 @sam_ nothing from me 2022-08-14 19:39:16 @sam_ I want to pursue some eclassy analogue to the GLEP 83 stuff we approved earlier but I have nothing to show right now 2022-08-14 19:40:26 @gyakovlev I guess nothing else will come up today. let's call it a day then. 2022-08-14 19:40:44 * gyakovlev bangs the gong 2022-08-14 19:40:45 @gyakovlev meeting closed