[04:00:40] <@arthurzam> I think dillfridge forgot
[04:01:22] <@robbat2> dionysos: ping ;-)
[04:01:55] <@robbat2> roll call: arthurzam, dionysos/dilfridge, mgorny, robbat2, soap, sam_, ulm
[04:01:59] -*- robbat2 present
[04:02:02] -*- ulm here
[04:02:05] -*- sam_ here
[04:02:06] -*- arthurzam here
[04:02:07] -*- soap here
[04:02:11] -*- mgorny here
[04:03:10] <@ulm> do we have an agenda?
[04:03:19] <@arthurzam> wasn't sent to ML
[04:03:26] <@arthurzam> but we can collect most of it manually I think
[04:03:44] <@sam_> i've pinged him on signal but i'm not sure what timezone he is in right now 
[04:03:46] <@sam_> traveling a lot
[04:03:51] <@sam_> so i won't call
[04:04:11] <@sam_> afaik the only notable thing in this meeting is arch review
[04:04:17] <@arthurzam> wait
[04:04:23] <@arthurzam> I want https://public-inbox.gentoo.org/gentoo-dev/20260509093355.562591-1-arthurzam@gentoo.org/
[04:04:35] <@sam_> ah yeah
[04:04:42] <@iznogoud> Here
[04:04:48] <@arthurzam> \o/
[04:04:51] <-> iznogoud heißt jetzt dilfridge
[04:04:52] <@ulm> also EAPI 9 update, bug 977170
[04:04:52] <willikins> ulm: https://bugs.gentoo.org/977170 "EAPI 9 change to not export PMS variables widely breaks cross-compiling"; Gentoo Hosted Projects, PMS/EAPI; IN_P; chewi:pms
[04:05:28] <@dilfridge> Sorry was just on the way train station-> home
[04:05:39] <@arthurzam> dilfridge: do you want some minutes to collect yourself?
[04:06:13] <@dilfridge> If someone else could take over chair would be great
[04:06:59] <@robbat2> additional agenda item, calling for the foundation's recordation date
[04:06:59] <@arthurzam> I can take it
[04:07:24] <@arthurzam> So, umm
[04:07:24] <@arthurzam> meeting time :)
[04:07:30] <@arthurzam> 1. Roll call
[04:07:35] -*- arthurzam here
[04:07:52] <@robbat2> already did the rollcall ;-)
[04:08:06] <@arthurzam> let's do it again
[04:08:11] -*- robbat2 present
[04:08:12] -*- ulm here
[04:08:15] -*- sam_ here
[04:08:22] -*- dilfridge here
[04:08:22] -*- soap here
[04:08:48] <@arthurzam> mgorny is also here
[04:08:48] <@arthurzam> so all 7 are here
[04:09:02] <@arthurzam> 2. EAPI 9 update, bug 977170
[04:09:02] <willikins> arthurzam: https://bugs.gentoo.org/977170 "EAPI 9 change to not export PMS variables widely breaks cross-compiling"; Gentoo Hosted Projects, PMS/EAPI; IN_P; chewi:pms
[04:09:03] <@mgorny> yep, sorry
[04:09:04] -*- mgorny here
[04:09:09] <@arthurzam> ulm: can you take it?
[04:10:10] <@ulm> the problem is that *SYSROOT and BROOT are needed as exported vars for crossdev to work
[04:10:24] <@ulm> and EAPI 9 broke this
[04:10:52] <@ulm> so the idea would be to just export these 3 vars again: https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-9&id=66ae4b02f33418228dee683e85fa61cf8de9983f
[04:10:57] <@arthurzam> is portage ready with a fix?
[04:11:10] <@ulm> second ...
[04:11:17] <@ulm> https://github.com/gentoo/portage/pull/1589
[04:11:30] <@ulm> trivial change
[04:12:05] <@arthurzam> I don't think EAPI=9 was shipped to other package manager where this will have issues, so I think we can indeed amend EAPI=9 with that
[04:12:20] <@arthurzam> should I move to vote?
[04:12:49] <@ulm> yes please. motion would be to amend EAPI with the last three commits from https://gitweb.gentoo.org/proj/pms.git/log/?h=eapi-9
[04:13:06] <@arthurzam> motion: approve the amend to EAPI=9 with changes listed in bug 977170
[04:13:07] <willikins> arthurzam: https://bugs.gentoo.org/977170 "EAPI 9 change to not export PMS variables widely breaks cross-compiling"; Gentoo Hosted Projects, PMS/EAPI; IN_P; chewi:pms
[04:13:09] -*- arthurzam yes
[04:13:32] -*- soap yes
[04:13:49] -*- sam_ yes
[04:13:52] -*- dilfridge yes
[04:13:53] -*- mgorny yes (though only as a quick bugfix -- we should look into not relying on implicit stuff like that long-term)
[04:14:16] -*- robbat2 yes
[04:14:26] -*- ulm yes
[04:14:46] <@arthurzam> all 7 are yes, motion passed.
[04:14:46] <@arthurzam> mgorny's concern is valid and we should indeed attempt to improve our way
[04:14:47] <@robbat2> of that list, off the top of my head, I know gcc itself uses SYSROOT
[04:15:16] <@mgorny> yes, SYSROOT is a standard variable
[04:15:20] <@mgorny> ESYSROOT and BROOT are not
[04:15:33] <@arthurzam> let's do it post meeting
[04:15:37] <@arthurzam> next item
[04:15:39] <@arthurzam> 3. approve modification to GLEP 68, bug 974436
[04:15:39] <@arthurzam> https://public-inbox.gentoo.org/gentoo-dev/20260509093355.562591-1-arthurzam@gentoo.org/
[04:15:40] <willikins> https://bugs.gentoo.org/974436 "GLEP 68: add <straight-to-stable/> to package's metadata.xml"; Documentation, GLEP Changes; CONF; arthurzam:glep
[04:16:18] <@arthurzam> So about this one, there were ideas to use better flag for allarches flag, but this one is readlly "most don't define, special cases define it", so I think the current version is better
[04:16:22] <@sam_> I like the idea: it codifies something we often tell each other informally and also helps new contributors who are sometimes confused by this (discord is probably a good example)
[04:16:34] <@sam_> and I find the tag fine
[04:16:35] <@robbat2> last time we had a discussion about making it have an option to explicitly say "no" to straight-to-stable
[04:16:52] <@arthurzam> robbat2: I think no is really the default and very most case
[04:17:00] <@arthurzam> only special cases are "yes"
[04:17:21] <@arthurzam> I agree with you to use yes/no/undefined for allarches, but not here
[04:17:25] <@sam_> we can always do comments for things like that
[04:17:34] <@robbat2> rely on comments means having to parse
[04:17:36] <@sam_> <!-- This is not straight-to-stable because ... -->
[04:17:43] <@sam_> it's not the kind of thing you are likely to want to parse
[04:17:49] <@robbat2> <straight-to-stable flag="no" />
[04:18:09] <@ulm> please no attribute, let's keep it simple
[04:18:09] <@sam_> the absence of the flag means no. if people want to explain *why*, a comment works
[04:18:11] <@arthurzam> But why would someone do it?
[04:18:18] <@mgorny> are you going to add it to all packages that aren't eligible? (i.e. practically all of them?)
[04:18:48] <@ulm> also "flag" is a bad name for a attribute
[04:18:50] <@sam_> the only reason to do it is to explain why, and in that case, the parsing is no good with =no />, and you want a comment anyway
[04:18:54] <@robbat2> being able to understand, at a tree-wide scale: "what packages did we consider straight-to-stable-on?"
[04:19:06] <@arthurzam> robbat2: it should be the smallest set possible
[04:19:17] <@sam_> i'm not really worried about that, plus it should be a subset probably of <stabilize-allarches/>
[04:19:20] <@arthurzam> you don't really want to use it, unless *-bin package
[04:19:25] <@sam_> or that
[04:20:01] <@mgorny> either way, you're either introducing something that will be all over the place, or that will practically never be used
[04:20:04] <@mgorny> so the "no" thing is just noise
[04:20:17] <@soap> random package also doesnt have USE=foo, hence you consider it not to be a thing for random package
[04:20:59] <@arthurzam> And this whole straight-to-stable is just a recommendation to developer, he can always override during bump (explain in commit idealy)
[04:20:59] <@robbat2> having it a tri-value attribute lets that default decision also move to the tooling
[04:21:15] <@soap> robbat2: please let's not overthink this
[04:21:27] <@dilfridge> More list discussion?
[04:21:28] <@arthurzam> tooling wise, I guess the only affect "if yes, don't do `ekeyword ~all`"
[04:22:00] <@arthurzam> I want to push to vote, but as a chair and author I don't want to be too pushy
[04:22:59] <@mgorny> wasn't the consensus on the ml that nobody wants extra "no" option except for one preson?
[04:23:01] <@mgorny> person*
[04:23:11] <@soap> exactly
[04:23:22] <@arthurzam> ok, let's vote
[04:23:35] <@arthurzam> motion: approve the GLEP 68 update, as in bug 974436
[04:23:36] <willikins> https://bugs.gentoo.org/974436 "GLEP 68: add <straight-to-stable/> to package's metadata.xml"; Documentation, GLEP Changes; CONF; arthurzam:glep
[04:23:40] -*- arthurzam yes
[04:23:46] -*- mgorny yes
[04:23:49] -*- soap yes
[04:24:02] -*- sam_ yes
[04:24:03] -*- robbat2 nay; I think not making it a 3-way option is a design mistake
[04:24:18] -*- dilfridge no
[04:24:27] -*- ulm yes
[04:24:43] <@arthurzam> 5 yes, 2 no
[04:24:48] <@arthurzam> does it make it pass?
[04:24:56] <@robbat2> yes, it passes
[04:25:10] <@arthurzam> ok, next item
[04:25:25] <@arthurzam> 4. arch review (https://wiki.gentoo.org/wiki/Project:Council#Arch-status_Reviews)
[04:25:57] <@arthurzam> loong is an issue from reports of devs
[04:26:06] <@arthurzam> hppa & sparc - I didn't follow
[04:26:45] <@mgorny> not perfect, not horrible
[04:27:01] <@sam_> hppa/sparc are mostly fine because nobody considers them "desktop worthy", while loong has many major things kw'd so the lagging is more substantial
[04:27:10] <@sam_> e.g. for kde stuff it's been a real pain
[04:27:16] <@robbat2> do we have metrics/graphs showing the stable turnaround times still?
[04:27:27] <@sam_> all 3 arches here are ~arch only fwiw
[04:27:30] <@sam_> the issue is rekwing
[04:27:32] <@mgorny> exactly, it feels like loong started keywording everything at some point, then disappeared
[04:27:37] <@robbat2> both breadth & depth of queue
[04:27:46] <@arthurzam> robbat2: no, but in average our response time for main arches got worse compared to previous half year (2025H2)
[04:27:59] <@arthurzam> https://dev.gentoo.org/~arthurzam/at_bugs_report.html shows current state
[04:28:33] <@arthurzam> There is also https://gentoo.akhuettel.de/bugs/arches.php
[04:29:54] <@arthurzam> Do we want to start mass desktop dekeyword on loong?
[04:30:00] <@dilfridge> Only real difficulty are m68k amd hppa
[04:30:26] <@soap> I feel like xenon keywording loong might have been a bit too ambitious
[04:30:39] <@ulm> maybe allow maintainers to drop loong when there's no response to a rekeyword request after N days?
[04:30:42] <@sam_> I also believe him when he says there are really users of it in china, but we don't see them
[04:30:47] <@sam_> we get bug reports sometimes but they're not sending patches
[04:30:56] <@arthurzam> and we never got loong devbox
[04:31:07] <@sam_> to be fair, we actually had an offer from loongson for that
[04:31:13] <@sam_> we just had/have no idea where it goes
[04:31:22] <@sam_> because of import complications
[04:31:48] <@mgorny> ulm: i don't think there's any rule forbidding that
[04:32:28] <@dionysos> let's talk to him and maybe he can find a fresh recruit
[04:32:47] <@arthurzam> or a datacenter or something to host the devbox and give ssh access
[04:33:13] <@arthurzam> I think china has datacenters? Or maybe longson can host it
[04:33:33] <@dionysos> arthurzam: the problem is that loongson is under us restrictions
[04:33:36] <@robbat2> given world politics, yes, hosted in China, with remote access
[04:33:47] <@dionysos> so either we do it like debian and host it in switzerland (I think)
[04:34:00] <@dionysos> or we ask them if they can host it there
[04:34:17] <@arthurzam> I don't think we care to where to ssh?
[04:34:26] <@mgorny> how powerful is that hw anyway?
[04:34:26] <@dionysos> not really, no
[04:34:29] <@arthurzam> (maybe just use a different ssh key, just in case)
[04:34:48] <@arthurzam> mgorny: I think somewhere between mips and riscv
[04:34:55] <@dionysos> mgorny: ok-ish, I think... at least better than riscv 
[04:35:04] <@robbat2> the big loongson are 256core now
[04:35:23] <@dionysos> it's definitely under development
[04:36:42] <@arthurzam> ok, sounds like we have some ideas, let's contact xenon
[04:36:52] <@arthurzam> anything more about arches?
[04:37:04] <-> Sie heißen jetzt dilfridge|laptop
[04:37:24] <@dilfridge|laptop> I went through the stage3 builds during the last days
[04:37:58] <@dilfridge|laptop> because the python-3.14 update broke our build procedure
[04:38:29] <@dilfridge|laptop> (basically the builders all need to go py3.13 -> py3.13+p3.14 -> py3.14 now)
[04:38:45] <@dilfridge|laptop> in the course of that
[04:38:49] <@dilfridge|laptop> current state:
[04:38:51] <@mgorny> dilfridge|laptop: don't we just need to do that once, though?
[04:39:20] <@dilfridge|laptop> yes, only once, but since I'm setting it per-builder, I need to make sure that all stages on that builder actually update
[04:39:21] <@mgorny> and just for the record, it's not python's fault, but portage's
[04:40:00] <@dilfridge|laptop> so, stage status (not saying anything about iso etc now):
[04:40:31] <@dilfridge|laptop> alpha, amd64, arm, arm64: all good
[04:40:42] <@dilfridge|laptop> hppa: broken, looking into it
[04:41:02] <@robbat2> osl never got our hppa boxes working again after the move
[04:41:05] <@dilfridge|laptop> loong, mips: (not finished yet but likely) all good
[04:41:07] <@robbat2> how important are they to fixing it?
[04:41:33] <@dilfridge|laptop> not really that much, qemu is faster and for emergencies there's matoro's machine
[04:42:05] <@dilfridge|laptop> m68k: broken, unclear why
[04:42:19] <@dilfridge|laptop> possibly perl miscompiled
[04:42:28] <@arthurzam> ppc{,64} - what there?
[04:42:44] <@dilfridge|laptop> ppc, ppc64: all good
[04:43:09] <@dilfridge|laptop> riscv: 50/50, the more common stuff is good, but e.g. all musl is broken
[04:43:56] <@robbat2> i think that just leaves s390?
[04:43:58] <@dilfridge|laptop> s390: 64bit all good, 32bit broken (but fixable, file/seccomp) - but the 32bit support is dropped in the next glibc release
[04:44:02] <@dilfridge|laptop> sparc: all good
[04:44:11] <@dilfridge|laptop> x86 all good
[04:45:06] <@dilfridge|laptop> that's my summary right now
[04:45:25] <@robbat2> dilfridge|laptop: any actions or specific requests you have of people?
[04:45:56] <@dilfridge|laptop> for packages where assembler is involved, e.g. leancrypto, please test on more than one level within an arch
[04:46:18] <@dilfridge|laptop> like, leancrypto[asm] needs armv7 at least, and for riscv hf support
[04:46:31] <@dilfridge|laptop> nothing else
[04:46:40] <@dilfridge|laptop> but we may want to drop 32bit s390 soon
[04:46:53] <@dilfridge|laptop> and hppa / m68k need volunteers
[04:47:41] <@arthurzam> dilfridge: want to send to ML deprecation before removal of 
[04:47:47] <@arthurzam> s390 32 bits?
[04:48:11] <@dilfridge|laptop> well, it's not urgent yet imho
[04:48:11] <@arthurzam> I don't think anyone uses it at all, so maybe even 1 month is fine
[04:48:18] <@dilfridge|laptop> but yes
[04:48:37] <@dilfridge|laptop> I mean, nothing keeps us from sticking to glibc-2.43 there for a while
[04:48:54] <@dilfridge|laptop> it's a pure legacy environment
[04:49:04] <@dilfridge|laptop> like x86, for old applications
[04:51:08] <@arthurzam> I think dilfridge's arch status summarises well the arch status. I'll let you decide if to post to ML deprecation
[04:51:24] <@arthurzam> next item
[04:51:31] <@arthurzam> 5. robbat2's item: calling for the foundation's recordation date
[04:51:46] <@arthurzam> no idea here, robbat2 you lead
[04:51:53] <@robbat2> historically the foundation trustees called for it; but with the overlap to council members
[04:52:01] <@ulm> what date did we have last year?
[04:52:01] <@robbat2> this makes sense to me to announce it here
[04:52:34] <+NeddySeagoon> end of May
[04:52:56] <@robbat2> we're running behind; so I think sending today for June 21st as the recording date
[04:53:49] <@robbat2> nominations can run June 21-July 1st; followed by the normal 2 weeks of voting
[04:53:50] <+NeddySeagoon> The election is in progress with the member list as it was before nominations opened.
[04:54:48] <@robbat2> i think we have to double-check the new mexico laws then; as we have to specifically announce the recordation date
[04:54:56] <@robbat2> and we didn't do that :-(
[04:55:14] <@arthurzam> wait, foundation is based on Mexico?
[04:55:22] <@robbat2> the state of New Mexico
[04:56:30] <@robbat2> if we are required to specifically announce it; sometime in the next few days at the latest
[04:56:34] <@ulm> (new mexico) laws, not new (mexico laws) :)
[04:56:45] <-- crabbedhaloablut (~crabbedha@user/crabbedhaloablut) hat das Netzwerk verlassen (Quit: bye)
[04:57:16] --> crabbedhaloablut (~crabbedha@user/crabbedhaloablut) hat #gentoo-council betreten
[04:57:32] <@robbat2> related to the council & trustee side: I want to note that I am *NOT* going to stand for Council this year, between work + infra + council + trustees was too much; dropping Council to get the foundation finally shut
[04:57:47] <@robbat2> next topic
[04:58:21] <@robbat2> (brb as well)
[04:58:41] <@arthurzam> was the next topic meaning he writes something, or expects me to continue?
[04:58:51] <+NeddySeagoon> Does the record date need to apply to this election?
[04:59:25] <@sam_> why wouldn't it?
[04:59:47] <@sam_> but i don't understand, isn't this the same every year? 
[05:00:02] <@sam_> arthurzam: think he expects you to continue
[05:00:38] <@arthurzam> next item should be foundaton dissolution, but I think he just wrote about it
[05:00:40] <+NeddySeagoon> The election is in progress.  It's dackdated from the AGM which does not have a set date every year, so no.
[05:00:49] <@sam_> what do you mean no, though
[05:00:56] <@sam_> robin says it is usually done
[05:00:58] <@sam_> is it not usually done?
[05:01:10] <@sam_> were you not aware of this process (you were a trustee)? or what?
[05:01:12] <+NeddySeagoon> The AGM is a moveable feast, so is the record date.
[05:01:20] <@sam_> ok, but then elections have to shift with it, right?
[05:01:30] <@sam_> or is robin wrong? or what am I missing?
[05:01:34] <@robbat2> correct they are all movable within certain limitations
[05:01:44] <@robbat2> by next topic I meant whatever was next on the agenda
[05:01:56] <@robbat2> (back)
[05:02:23] <+NeddySeagoon> It sets the member list ... which is the peopole entilileted to vote is foundation affairs.
[05:02:31] <@arthurzam> ok, might as well
[05:02:31] <@arthurzam> 6. open floor
[05:02:49] <@arthurzam> please write even single character if you have an item, so we know to wait for you
[05:05:30] <@arthurzam> seems quite
[05:06:08] <@arthurzam> I think we can close the meeting
[05:06:08] <@arthurzam> Thank you all for being in council for the last year
[05:06:08] <@arthurzam> And special thanks to sam for fighting mail spam - he is the hero of all gentoo devs
[05:06:19] <@mgorny> thanks
[05:06:40] <@ulm> thanks for chairing!
[05:07:52] <@sam_> thanks!
[05:07:55] <@sam_> (and thank you)
[05:09:29] * ulm has changed topic for #gentoo-council to: "275th meeting: TBA | https://www.timeanddate.com/worldclock/fixedtime.html?iso=202607ddThh | https://wiki.gentoo.org/wiki/Project:Council | https://dev.gentoo.org/~dilfridge/decisions.pdf"
[05:10:05] <@dilfridge|laptop> thanks all and arthurzam thanks for taking over the chair on short notice!