[21:00:15] <@mgorny> !proj council
[21:00:15] <willikins> (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm
[21:00:27] <@robbat2> present
[21:00:28] <@mgorny> Agenda: https://public-inbox.gentoo.org/gentoo-project/0f53166bb35da2ccf1d4c90feae699075877fe78.camel@gentoo.org/T/#u
[21:00:34] <@mgorny> 1. Roll call.
[21:00:37] -*- arthurzam here
[21:00:38] -*- soap here
[21:00:49] -*- ulm here
[21:00:52] -*- mgorny here
[21:01:23] <@mgorny> dilfridge, sam_:
[21:03:43] -*- sam_ here
[21:04:17] <sam__> i seem to be havin some strange input lag
[21:04:24] <sam__> did you get my "here"?
[21:04:27] <@mgorny> can anyone try to ping dilfridge?
[21:04:29] <@mgorny> sam__: yes
[21:04:30] <@arthurzam> yes
[21:04:34] <sam__> thanks!
[21:04:37] <-> sam__ is now known as Guest3861
[21:05:13] -*- dilfridge here
[21:05:13] <@ulm> he definitely has problems there :/
[21:05:14] <-> Guest3861 is now known as sam__
[21:05:27] <@mgorny> okay, so everyone's present
[21:05:40] <@mgorny> 2. EAPI=9 changes [2]
[21:05:45] <@mgorny> [2] https://public-inbox.gentoo.org/gentoo-project/ur014wz9u@gentoo.org/
[21:05:51] <@mgorny> ulm: would you like to take the lead?
[21:06:16] <@ulm> I guess we start with domo?
[21:06:28] <@mgorny> sure
[21:06:33] <@ulm> bug 951502
[21:06:33] <willikins> ulm: https://bugs.gentoo.org/951502 "[Future EAPI] remove domo"; Gentoo Hosted Projects, PMS/EAPI; CONF; arthurzam:pms
[21:06:50] <@mgorny> i don't think i've ever used it
[21:07:01] <@arthurzam> Anyone want's to add something on this domo, or just vote it?
[21:07:10] <@mgorny> do we have a "recommended replacement"?
[21:07:17] <@ulm> in summary, it is little used (6 packages), has confusing semantics, and it's not possible to install in another gettext domain than PN
[21:07:25] <@ulm> insinto + newins
[21:07:42] <@ulm> or an eclass, if someone feels like writing one
[21:08:25] <@ulm> so my suggestion is to drop the command in EAPI 9
[21:08:33] <@robbat2> do we know why it was originally a helper instead of an eclass way back?
[21:08:35] <@ulm> s/drop/ban/
[21:09:10] <@ulm> IIRC it was present in portage in 2000 or 2001 already
[21:09:26] <@ulm> so we have no history and no rationale why it's there
[21:09:51] <@robbat2> yeah ban it then
[21:09:55] <@robbat2> esp since it's so rare
[21:09:59] -*- sam_ here
[21:10:19] <@arthurzam> So let's vote on domo?
[21:10:30] <@ulm> any other opinions? if not, let's vote?
[21:10:52] <@robbat2> app-i18n/mozc/mozc-2.28.5029.102-r1.ebuild has a nice example of using insinto+newins instead
[21:11:11] <@mgorny> ok
[21:11:17] <@mgorny> vote: ban domo in EAPI 9
[21:11:22] <@sam_> this one is pretty important because it's actually a complete misnomer
[21:11:26] -*- dilfridge yes
[21:11:29] -*- arthurzam yes
[21:11:30] <@sam_> Eli explained on the bug that it can't work often
[21:11:30] -*- ulm yes
[21:11:31] -*- mgorny yes
[21:11:32] -*- robbat2 aye
[21:11:38] <@sam_> use a proper build system (seriously)
[21:11:42] <@sam_> this isn't a simple task
[21:11:44] <@sam_> just use doins if you really must
[21:11:54] <@arthurzam> sam_: we are voting on it :)
[21:12:02] -*- soap yes
[21:12:02] <@ulm> sam_: newins, but otherwise yes
[21:12:24] <@sam__> arthurzam: I have some weird input lag, I thought it was gone, remember?
[21:12:42] <@dilfridge> sam__ is piped through GCHQ first...
[21:12:47] <@sam__> :)
[21:12:56] <@sam_> let's vote
[21:12:58] <@mgorny> sam__: vote: ban domo in EAPI 9
[21:13:00] -*- sam__ yes 
[21:13:12] <@mgorny> okay, 7 yes, passed
[21:13:20] -*- soap yes
[21:13:21] -*- sam_ yes
[21:13:30] <@mgorny> ulm: i guess edo/edov next
[21:13:37] <@sam_> arthurzam: input lag, remember
[21:13:39] <@mgorny> do we want to cover edov or skip it?
[21:13:39] <@ulm> bug 744880
[21:13:40] <willikins> ulm: https://bugs.gentoo.org/744880 "[Future EAPI] provide an exherbo edo-like helper"; Gentoo Hosted Projects, PMS/EAPI; CONF; soap:pms
[21:13:58] <@sam__> there's some active discussion on edov, so maybe we wait a little bit?
[21:14:00] <@ulm> mgorny: not sure, let's discuss edo first
[21:14:19] <@arthurzam> I think edo is a very good candidate to enter EAPI=9 already. It has increasing usage in tree
[21:14:33] <@mgorny> i think there is general agreement to have edo, just not necessarily how to implement it
[21:14:36] <@arthurzam> And while we can ignore the impl of edo, it's syntax is already well defined and used
[21:14:45] <@ulm> then again, it would help to know if there were both commands in EAPI 9 or only one
[21:14:50] <@mgorny> though i don't think specific output is in a matter of PMS
[21:14:53] <@ulm> for the implementation, that is
[21:15:12] <@arthurzam> I hope we can add edov to EAPI=9, so we let's prepare for it
[21:15:42] <@ulm> the gist is that it outputs an informational message to stderr, then executes the command, and die -n if it fails
[21:16:08] <@ulm> the exact format of the output need not be (and should not be) part of the spec
[21:16:17] <@arthurzam> I agree
[21:16:18] <@robbat2> what do we get out of having it in portage, since it's already in an eclass
[21:16:26] <@arthurzam> no need to inherit eclass
[21:16:32] <@ulm> +!
[21:16:36] <@ulm> +1
[21:16:36] <@sam__> it's such a simple utility that having it ::gentoo specific feels stupid
[21:17:11] <@arthurzam> it is really such a nice QoL addition
[21:17:37] <@ulm> not sure if I see a similar need for edov, because edob has little adoption in comparison
[21:17:40] <@mgorny> i think it falls under the category of "popular and general enough"
[21:18:00] <@mgorny> (talking of edo, not edov)
[21:18:56] <@ulm> details of the implementation must still be figured out, but I don't see this as a blocker for voting on it today
[21:19:42] <@robbat2> i'm going to say pragmatically the API should be limited to critical things - QoL things shouldn't be limited by the API specification
[21:20:14] <@ulm> certainly the exact format of an informational message isn't critical?
[21:20:16] <@arthurzam> I think edo is so much trivial, so much improves usage and clean ebuilds, and brings good principals of writing
[21:20:25] <@arthurzam> I think exact format isn't intersting
[21:20:27] <@mgorny> the way i see it, "edo" is trivial and we don't expect the spec to change
[21:20:36] <@arthurzam> Maybe some PM will use JSON output...
[21:20:41] <@sam__> robbat2: is your point that it shouldn't be in the spec, or that its details are irrelevant?
[21:20:50] <@mgorny> like, it's literally "run $@ || die", and output it somehow
[21:21:03] <@robbat2> that it shouldn't be in the spec at all
[21:21:18] <@sam__> IMO another reason it should be in the spec is: it's EXTREMELY easy for newbies to run a command and ASSUME we trap on failure
[21:21:21] <@sam__> other PMs do this
[21:21:27] <@sam__> ztrawhcse and I have talked about that a few times
[21:21:35] <@robbat2> and they can "inherit edo"
[21:21:43] <@sam__> having edo in the spec and well-documented makes clear that our *spec* does not guarantee such a trap
[21:21:47] <@sam__> no, because eclasses are repo specific
[21:21:47] <@arthurzam> But this feels like an adoption gate
[21:21:55] <@sam__> this is a basic thing to do with error handling in our spec
[21:22:24] <@ulm> sam_: strictly speaking, we don't need edov for all that
[21:22:32] <@sam__> ulm: that's true
[21:22:34] <@ulm> edo is enough
[21:22:40] <@sam__> ulm: but i'm making an argument in favour of having edo, not excluding anything else ;)
[21:22:48] <@mgorny> let's vote for edo and edov separately?
[21:22:54] <@arthurzam> yeah
[21:22:56] <@sam__> sure
[21:22:57] <@ulm> yes, please
[21:23:21] <+ztrawhcse> the critical point is having some feedback to the user what is being run (especially when there are multiple things a package "might" do). it's an incredibly common problem to fail at this, and pushing every single ebuild writer to inherit edo is gonna cause a lot of confusion. we need this info especially in build.log for successful builds that did the wrong thing and we don't know 
[21:23:22] <+ztrawhcse> *why*
[21:23:31] <@mgorny> vote: edo in EAPI 9
[21:23:35] -*- arthurzam yes
[21:23:40] -*- ulm yes
[21:23:41] -*- dilfridge yes
[21:23:48] -*- sam__ yes
[21:23:49] -*- mgorny yes
[21:24:16] -*- robbat2 aye - but all QoL-only changes should be strongly debated; API being as small as possible is good
[21:24:20] -*- soap yes
[21:24:33] <@mgorny> 7 yes, passed
[21:24:39] <@mgorny> vote: edov in EAPI 9
[21:24:45] -*- ulm no
[21:24:48] -*- mgorny no
[21:24:56] -*- dilfridge abstain
[21:25:09] -*- sam__ no 
[21:25:14] -*- soap no
[21:25:27] -*- robbat2 nay
[21:25:38] <@arthurzam> I'm still not sure for current idea, so
[21:25:38] -*- arthurzam no
[21:25:52] <@mgorny> 6 no, 1 abstain, rejected
[21:26:10] <@mgorny> which brings us to:
[21:26:15] <@mgorny> er, wait
[21:26:17] <@ulm> ok, so that will stay (as "edob") in its eclass, with some additional embellishments thanks to Flow
[21:26:47] <@mgorny> is there anything left for EAPI 9?
[21:26:47] <@ulm> (and I mean this in a positive sense)
[21:27:01] <@ulm> the implementation? :)
[21:27:18] <@mgorny> no, i mean for today's meeting
[21:27:18] <@sam__> mgorny: yes, I'd like bug 955833 (which I'd been meaning to propose for some time)
[21:27:19] <willikins> sam__: https://bugs.gentoo.org/955833 "Introduce package.use.stable, use.stable for profiles"; Gentoo Hosted Projects, PMS/EAPI; CONF; sam:pms
[21:27:21] <@sam__> oh
[21:27:22] <@ulm> but yeah, I fell like we should wrap it up soonish
[21:27:24] <@sam__> yeah, notihng else for today I think
[21:27:25] <@sam__> *nothing
[21:27:33] <@arthurzam> A question about EAPI=9, are eclass revisions ready indeed? I didn't see explanations or something usefull on how it works
[21:27:47] <@sam__> we agreed already we're not going to do it
[21:27:55] <@sam__> it's a mess to implement and the model is to ocomplex
[21:27:57] <@arthurzam> oh, ok, so wiki confused me
[21:28:20] <@mgorny> okay, so moving on
[21:28:26] <@mgorny> 3. Open bugs with Council participation [3]
[21:28:28] <@ulm> the idea is nice, but looks like implementation would be non-trivial
[21:28:35] <@sam__> yeah, idea was fine
[21:28:45] <@mgorny> bug 948684
[21:28:46] <willikins> mgorny: https://bugs.gentoo.org/948684 "Missing summary for 20240609 council meeting"; Gentoo Council, unspecified; CONF; ulm:dilfridge
[21:28:50] <@mgorny> and bug 948686
[21:28:51] <willikins> mgorny: https://bugs.gentoo.org/948686 "Missing summary for 20241110 council meeting"; Gentoo Council, unspecified; CONF; ulm:dilfridge
[21:29:00] <@dilfridge> willdo
[21:29:16] <@mgorny> then bug 936211         
[21:29:17] <willikins> mgorny: https://bugs.gentoo.org/936211 "[Tracker] Gentoo Foundation dissolution"; Gentoo Foundation, Proposals; CONF; ulm:trustees
[21:29:19] <@arthurzam> dilfridge: do you need help with that? I clearly see you are swamped for a long time
[21:29:30] <@robbat2> (waiting for dilfridge's answer)
[21:29:42] <@dilfridge> i can do it myself
[21:29:50] <@robbat2> ok - re foundation
[21:29:59] <@robbat2> SPI did get new reports posted
[21:30:01] <@robbat2> https://www.spi-inc.org/treasurer/reports/202502/#index7h4
[21:30:06] <@robbat2> https://www.spi-inc.org/treasurer/reports/202503/#index7h4
[21:30:11] <@robbat2> ^^ month-on-month changes
[21:30:25] <@robbat2> 2025/04 not posted yet, but their target is 15 days after month-end
[21:30:40] <@mgorny> so things are improving?
[21:30:49] <@dilfridge> looks like it
[21:31:05] <@arthurzam> I think they fixed it like 4 hours before #spi meeting
[21:31:23] <@robbat2> yes - assuming the 2025/04 funds show the same pattern; I think we can start to switch over at least smaller bills
[21:31:28] <@robbat2> not all of them yet
[21:31:59] <@robbat2> ~$750USD/mo is the run rate
[21:32:07] <@robbat2> some currency flucuation
[21:32:37] <@robbat2> I had hoped to wrap it in this tax year
[21:32:43] <@robbat2> but that's not going to happen
[21:32:55] <@robbat2> i did also re-ask SPI about switching trademarks, other contracts
[21:33:00] <@robbat2> and they at least have it on their tracker now
[21:33:07] <@ulm> good :)
[21:33:13] <@robbat2> but their progress is not exactly fast
[21:33:45] <@robbat2> unless I hear otherwise, on June 1st, i'm going to do the combined renewal for both trademarks
[21:33:53] <@robbat2> (saves some money to renew them at the same time)
[21:34:11] <@robbat2> i will put out a fresh ask for recent photos of the Gentoo logo in tradeshows etc
[21:34:20] <@robbat2> that's all from me
[21:34:41] <@sam__> we have a bunch from fosdem this year we can use as well
[21:34:48] <@robbat2> great; please email me links etc
[21:35:24] <@mgorny> okay, so that brings us to
[21:35:26] <@robbat2> I think we might have also been at SCALE at the start of the year
[21:35:32] <@mgorny> 4. Open Floor
[21:35:47] <@mgorny> does anyone want to raise anything?
[21:36:23] <@arthurzam> The situation with OUSOUL was somewhat concerning
[21:36:41] <@arthurzam> As robbat2 said in #-infra, we might need to consider some actions...
[21:36:54] <@sam__> antarus proposed back in 2020 or 2021 or so that we donate something monthly
[21:36:58] <@sam__> I think we should definitely be doing that
[21:37:01] <@robbat2> specifically, we should look at diversification of the physical hosting
[21:37:05] <@sam__> we rely so heavily on OSUOSL, probably more than many projects
[21:37:37] <@robbat2> the remote hands being able to poke the alt-arch hardware are incredibly valuable to us
[21:38:38] <@dilfridge> I wonder if some computer history museum or similar might be interested in a collaboration
[21:40:33] <@robbat2> dilfridge: living computer history musuem was having financial troubles as well
[21:40:50] <@robbat2> https://www.reddit.com/r/Seattle/comments/1doa3fd/living_computer_museum_closed_for_good/
[21:41:02] <@mgorny> what's our arch status, btw?
[21:41:25] <@arthurzam> hppa and sparc is sad
[21:41:25] <@robbat2> sparc+hppa offline due to UPS issue at OSL
[21:41:46] <@sam__> muta is dead (hardware problem, and also off because of the UPS issue)
[21:41:47] <@arthurzam> x86,x64,{arm,ppc}{,64} holding mostly well
[21:41:51] <@sam__> hake is mysteriously absent, we don't know why
[21:41:53] <@mgorny> what's up with alpha? my bugs are not progressing xP
[21:42:01] <@arthurzam> it is matoro pinged
[21:42:10] <@sam__> matoro had some circumstances change so has had less time, I think
[21:42:11] <@arthurzam> did we see him lately?
[21:42:20] <@sam__> i've seen him, just not often
[21:42:53] <@arthurzam> Should we setup qemu-user container for that like mips?
[21:43:12] <@sam__> yes
[21:43:21] <@sam__> rth is working on qemu heavily and he was/is one of the alpha maintainers
[21:43:25] <@sam__> i'm sure the alpha support in qemu-user is decent enough
[21:43:33] <@dilfridge|mobile> It is
[21:43:41] <@arthurzam> ok, action item
[21:44:50] <@robbat2> the arm64 box @ OSL - I kept it online because it's very low power
[21:45:02] <@dilfridge|mobile> FTR dola  / arm64 is slow for qemu, a x8664 machine is way better
[21:45:16] <@arthurzam> I think to take some more cores/RAM for devbox.amd64
[21:45:52] <@robbat2> dola right now = loadavg 30/25/41, 125W
[21:46:03] <@robbat2> whereas the sparc box used 1kW idle
[21:47:06] <@robbat2> on the actionable discussion
[21:47:36] <@robbat2> we can remain revenue neutral and donate $250-$400/mo to OSL
[21:48:02] <@sam__> I think we ought to do that
[21:48:23] <@robbat2> that would mean that we are not saving for future hardware replacements
[21:48:25] <@arthurzam> I'll ask a question in #-private because of my ignorance
[21:49:05] <@robbat2> our half-rack of owned hardware in Manitu's DE facility probably needs to be replaced early 2026
[21:49:46] <@robbat2> it's 11.5 years old right now
[21:50:32] <@robbat2> arthurzam: is that a right now question you're writing, or for post-meeting?
[21:50:39] <@arthurzam> robbat2: post
[21:51:02] <@arthurzam> robbat2: you need to join #-private
[21:51:13] <@robbat2> action-item: move discussion to lists for ongoing donation to osl
[21:51:19] <@arthurzam> Sorry, sent in wrong #-private, lol
[21:51:37] <@sam__> robbat2: yes
[21:51:49] <@arthurzam> yes
[21:52:31] <@mgorny> okay, anything else for today?
[21:54:01] <@robbat2> nothing from me
[21:54:17] -*- mgorny bangs the gavel