summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'meeting-logs')
-rw-r--r--meeting-logs/20240512.txt44
-rw-r--r--meeting-logs/20240512.txt.asc19
-rw-r--r--meeting-logs/20240609.txt350
-rw-r--r--meeting-logs/20240609.txt.asc19
-rw-r--r--meeting-logs/20241013.txt247
-rw-r--r--meeting-logs/20241013.txt.asc19
-rw-r--r--meeting-logs/20241110.txt86
-rw-r--r--meeting-logs/20241110.txt.asc19
-rw-r--r--meeting-logs/20241208.txt313
-rw-r--r--meeting-logs/20241208.txt.asc19
-rw-r--r--meeting-logs/20250112.txt175
-rw-r--r--meeting-logs/20250112.txt.asc19
12 files changed, 1329 insertions, 0 deletions
diff --git a/meeting-logs/20240512.txt b/meeting-logs/20240512.txt
new file mode 100644
index 0000000..6d87d08
--- /dev/null
+++ b/meeting-logs/20240512.txt
@@ -0,0 +1,44 @@
+[00:00:00] - {Tageswechsel: Sonntag, 12. Mai 2024}
+[21:00:31] <dilfridge> !proj council
+[21:00:32] <willikins> (council@gentoo.org) ajak, dilfridge, mattst88, mgorny, sam, soap, ulm
+[21:00:35] <dilfridge> meeting time
+[21:00:41] <dilfridge> 1) roll call
+[21:00:45] -*- dilfridge here
+[21:00:46] -*- ulm here
+[21:00:53] -*- mgorny ook
+[21:01:04] -*- sam_ here
+[21:01:21] -*- mattst88 here
+[21:02:01] <mgorny> ajak said he won't be around
+[21:02:02] <dilfridge> ajak cant make it, that means we're missing only Herr Seife
+[21:02:20] -*- soap here
+[21:02:25] <dilfridge> excellent :)
+[21:02:47] <dilfridge> which
+[21:02:52] <dilfridge> immediately brings us to
+[21:02:55] <dilfridge> 2) open bugs
+[21:03:04] <dilfridge> bug 801499
+[21:03:05] <willikins> dilfridge: https://bugs.gentoo.org/801499 "Approach Nitrokey for Nitrokey 3 upgrade"; Gentoo Foundation, Proposals; CONF; sam:trustees
+[21:03:25] <dilfridge> robbat2: any news here?
+[21:03:50] <dilfridge> (he'd probably have added it to the bug though if there were...)
+[21:04:08] <mattst88> I saw some emails between robbat2 and Jan (CEO? of nitrokey)
+[21:04:14] <mattst88> so I think things are progressing
+[21:04:19] <dilfridge> ok good
+[21:04:33] <dilfridge> no time like the present to wait a bit longer
+[21:04:35] <ulm> we may get some samples first
+[21:04:41] <dilfridge> bug 925014
+[21:04:42] <willikins> dilfridge: https://bugs.gentoo.org/925014 "PR services lacking developer redundancy"; Community Relations, User Relations; CONF; ajak:pr
+[21:04:58] <dilfridge> anything we can, should, want to do?
+[21:05:50] <mgorny> apparently some people offered to accept new volunteers
+[21:06:05] <mgorny> but i haven't seen anything about storing credentials happen
+[21:06:42] <dilfridge> ok then that's the next thing to annoy people about
+[21:06:54] <dilfridge> right
+[21:07:00] <dilfridge> which brings us to
+[21:07:03] <dilfridge> 3) open floor
+[21:07:04] <dilfridge> anyone?
+[21:07:33] <sam_> nothing from me; i have summaries to do which i will handle soon
+[21:08:09] <dilfridge> well
+[21:08:15] <dilfridge> then we're done for today!
+[21:08:18] -*- dilfridge bangs the gavel
+[21:08:22] <sam_> thank you!
+[21:08:24] <mgorny> thanks, everyone
+[21:08:29] <dilfridge> 8min 20sec, that might be a new record
+[21:08:50] <dilfridge> thanks from me too
diff --git a/meeting-logs/20240512.txt.asc b/meeting-logs/20240512.txt.asc
new file mode 100644
index 0000000..fa39924
--- /dev/null
+++ b/meeting-logs/20240512.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmeVRS9fFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE
+MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V
+QSovUg/9FDGnP3CbNHdO2whZ2yhbjJQxE2yYzWH4hr2mJkLOxko/UVNbM9Rmw6Sb
+g/B8N91KpnKNFyLZ0nu/OCdJcK33JNlnF2178dfL6CiFq2h4lVe2CQjM+YsoUtdH
+LU0leaNhuEePQndbjp3a8UxkDPlmOCPul30f4zmwxm6xWq1xhPQpOw90XOWkDUQ9
+uRaeArRGtimIWRWT9FyGYaQuuykmlSN4bySJsqJMgt24zGsYSdaJ1BvFDfDAVaGg
+sBCQ9yVZjywkgb5SgqEg+EbbPzCnijziWCmsTzLmY4pdf6ftVJu7dzVtVsqY6dz4
+nxkcGZZeqIfm5QA0F2iYfjsGoS0PSCSnd7MT35/N4lrNj5aPt0IROaG5jgcMUsI4
+S5oHVXRR4vIKBNv+vbSw31efqA327y3LIfoiMvyeALm6CTaBGvXQpTnT6VtMY6HI
+Z3b5V4K6IMMqmqpS9zXgZoncuNBbacMKQUHNOuJ1rF9Ix1Zj9/FeG/6bGp1Dhn1t
+rS+Qqf/gR2blHxMdC0bcsWKDOyn+GPc+N7b7EIVA+NL50mh7f+s+YrpVNRaRLRNh
+UcNz2OQSib5SE0npgaPo5MrTO7BVDFVZ1NflmjTvJe0Q4Kj74WbaBwZcIJeFLq8F
+mBtA6MK4qoBNDfSPskOfdzY/O9gjohUyvYNNAVfRrb/1+CmgY6M=
+=l/4Q
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20240609.txt b/meeting-logs/20240609.txt
new file mode 100644
index 0000000..8edc225
--- /dev/null
+++ b/meeting-logs/20240609.txt
@@ -0,0 +1,350 @@
+[00:00:00] - {Tageswechsel: Sonntag, 9. Juni 2024}
+[21:00:35] <dilfridge> !proj council
+[21:00:36] <willikins> (council@gentoo.org) ajak, dilfridge, mattst88, mgorny, sam, soap, ulm
+[21:00:40] <dilfridge> meeting now! :)
+[21:00:56] -*- ajak here
+[21:00:57] <dilfridge> let's start with the roll call
+[21:00:59] -*- dilfridge here
+[21:01:04] -*- sam_ here
+[21:01:14] -*- mgorny here
+[21:01:18] -*- ulm here
+[21:01:18] -*- soap here
+[21:01:49] -*- ajak guesses sandwich wasn't made in <4 minutes
+[21:01:56] <dilfridge> let's hope it's a good sandwich
+[21:01:59] -*- mattst88 here
+[21:02:05] <ajak> :)
+[21:02:05] <dilfridge> excellent
+[21:02:14] <dilfridge> 2.
+[21:02:26] <dilfridge> Proposed item: Enable GitHub sponsorship using SPI Fiscal Host
+[21:02:32] <dilfridge> https://marc.info/?l=gentoo-project&m=171676255409548&w=2
+[21:02:46] <dilfridge> robbat2: want to say something?
+[21:03:27] <ulm> can we do this ourselves, or do we have to ask SPI to enable it for us?
+[21:03:40] <mattst88> AFAIU this is just enabling github sponsors for Gentoo, which will direct money to SPI for us, right?
+[21:03:53] <ajak> i think it's fine; even if robin did it unilaterally i wouldn't have whined
+[21:03:59] <dilfridge> so I tried to read up on this, and it seems to be connected to github accounts ... cause you usually sponsor a person
+[21:04:05] <soap> yeah, I'm fine with it too
+[21:04:15] <mattst88> yeah, makes sense to me
+[21:04:18] <dilfridge> accordingly I'm not really sure how it's going to work for us, but I have no general objections
+[21:04:18] <ajak> mattst88: that's my understanding yeah
+[21:04:39] <dilfridge> yup, works for me
+[21:05:05] <dilfridge> so we should probably vote about something
+[21:05:13] <ulm> yes please :)
+[21:05:19] -*- ulm yes
+[21:05:26] <dilfridge> Proposed item: Enable GitHub sponsorship using SPI Fiscal Host
+[21:05:28] -*- dilfridge yes
+[21:05:30] -*- sam_ yes
+[21:05:31] -*- ajak yes
+[21:05:32] -*- ulm yes
+[21:05:38] -*- soap yes
+[21:05:38] -*- mattst88 yes
+[21:05:46] <dilfridge> that makes 7 yes, unanimous
+[21:05:50] <dilfridge> next
+[21:05:52] <dilfridge> 3.
+[21:05:54] <dilfridge> arch status
+[21:06:00] <arthurzam> wait, mgorny vote?
+[21:06:12] -*- mgorny yes
+[21:06:26] <dilfridge> ah
+[21:06:27] <dilfridge> ok
+[21:06:29] <dilfridge> still 7 yes
+[21:06:39] <dilfridge> shouldnt count ulm double :P
+[21:06:46] <dilfridge> https://gentoo.akhuettel.de/bugs/arches.php
+[21:06:49] <arthurzam> So about arch status, I want to talk about ia64 & hppa
+[21:06:51] <dilfridge> sorry for the white margin
+[21:07:13] <arthurzam> ia64 is close to death (kernel and glibc dropped)
+[21:07:42] <arthurzam> hppa is in sad state because issues with devbox, and once again, do we really want stable hppa at all?
+[21:08:24] <sam_> my position on it is the same as usual really, i still believe stable for some arches is useful because otherwise you can't really keep them up to date at all, and we'd end up with problems with no devbox anyway if we can't rekeyword things (albeit less, yes)
+[21:08:46] <ulm> dilfridge: didn't you have plots for number of keywords too?
+[21:08:52] <mattst88> I mentioned this yesterday in another channel, but I think we should drop the 32-bit userland sparc profiles
+[21:08:55] <dilfridge> ulm: still broken
+[21:09:01] <ulm> I see
+[21:09:07] <arthurzam> I agree with mattst88
+[21:09:17] <sam_> yeah 32-bit ul sparc should go as the kernel support is going and afaik the hw (matt explained this to me ages ago) basically doesn't exist in terms of anything anyone would use
+[21:09:23] <sam_> it's always people running 32-bit-on-64-bit hw
+[21:09:31] <arthurzam> SHould we also drop s390, not x variant?
+[21:09:39] <sam_> dilfridge has been working towards that
+[21:09:50] <sam_> i'll let him explain
+[21:10:07] <dilfridge> well, we can do that at any time, but right now also keeping s390 (without x) doesnt cost us anything
+[21:10:11] <dilfridge> (in a chroot)
+[21:10:23] <sam_> ah I forgot we could do that :)
+[21:10:46] <sam_> I actually do think we should remove it because IBM didn't seem to even realise anyone supported it
+[21:10:50] <sam_> but I agree it costs very little too
+[21:11:28] <dilfridge> we should definitely drop s390 boot media because they are pointless
+[21:11:45] <dilfridge> (kernel is s390x only for ages already)
+[21:11:48] <sam_> i suppose killing s390 will speed up CI a tiny bit or something
+[21:11:56] <sam_> plus it's also rustless, unlike s390x
+[21:12:14] <arthurzam> It would make the profiles mess with keywords simpler
+[21:12:26] <dilfridge> there#s of course also ppc32 and the elephant in the room, x86
+[21:12:30] <mgorny> btw do we expect rust to come to more arches soon?
+[21:12:45] <arthurzam> mgorny: not long ago I've added mips
+[21:12:58] <mgorny> ...which mips? xD
+[21:13:09] <sam_> rustc_codegen_gcc (rustc + libgccjit) got more integrated into the Rust repo recently so I think there is progress there
+[21:13:16] <dilfridge> BE or LE? and which ABI?
+[21:13:17] <sam_> gccrust is slower moving because it's a full frontend reimplementation
+[21:13:31] <soap> I love how "mips" is the most overloaded keyword in gentoo
+[21:13:32] <mattst88> yeah, I think just dropping stuff that provides no value is the right thing to do, even if it doesn't appear to cost much
+[21:13:45] <sam_> matoro also worked on making building rustc via cross work so it's easier to do dist tarballs now (bootstrap tarballs we do for sparc&mips)
+[21:13:54] <arthurzam> mgorny: dilfridge: I don't know, see here: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/rust-bin/rust-bin-1.78.0.ebuild#n20
+[21:13:56] <sam_> so I think the rust coverage is going to get better
+[21:13:59] <dilfridge> building stages is fairly easy, keeping up with boot media is harder
+[21:14:09] <sam_> soap: yes
+[21:14:18] <sam_> soap: this is part of why killing s390 is good (as arthur pointed out), i'd forgot about this
+[21:14:21] <dilfridge> arthurzam: that is fairly good coverage
+[21:14:24] <sam_> soap: if we added s390 (no x) today, we wouldn't overload the kw
+[21:14:40] <dilfridge> hrhr... how about riscv32`?
+[21:14:49] <sam_> that one should probably really be split too
+[21:15:00] <sam_> ultimately bitness is such a huge characteristic
+[21:15:02] <dilfridge> no objection but someone needs to do the work
+[21:15:14] <dilfridge> (and yes I suggested that at the start)
+[21:15:31] <arthurzam> sam_: so what about ia64 & hppa?
+[21:15:31] <arthurzam> (before we jump to ppc & x86)
+[21:15:38] <dilfridge> ok
+[21:15:40] <dilfridge> so
+[21:15:42] <dilfridge> chair statement
+[21:15:53] <dilfridge> we can't really decide anything without discussion on the lists
+[21:15:54] <dilfridge> but
+[21:15:57] <sam_> hppa is what I said above, I'd like to leave it alone for now and maybe setup my home machine doing AT until we can get the devbox repaired (we got given bad ram by a supplier)
+[21:16:05] <dilfridge> we can come up with things to propose there and decide next time
+[21:16:05] <sam_> i have personal affection for it though
+[21:16:14] <mgorny> is there anything to actually decide council-wise?
+[21:16:21] <mgorny> i think dropping some old profiles is within arch team scope
+[21:16:36] <dilfridge> !proj ia64
+[21:16:36] <willikins> dilfridge: (ia64@gentoo.org) ago, hattya, vapier
+[21:16:39] <sam_> LOL
+[21:16:50] <arthurzam> lol
+[21:16:52] <dilfridge> !proj hppa
+[21:16:52] <willikins> dilfridge: (hppa@gentoo.org) arthurzam, jsmolic, sam, vapier
+[21:16:54] <ajak> ... that might be that
+[21:17:13] <mgorny> ah, sorry, ia64, right
+[21:17:33] <arthurzam> council: Yeah here is the decision, so what about making x86 and ppc ~arch only? I don't see a good future for them as stable arch
+[21:17:39] <sam_> hppa is kind of my guilty pleasure and my favourite alt-arch even if it's not rational so unless it's hugely problematic i'd like it to not go
+[21:17:42] <sam_> meh
+[21:17:51] <sam_> this is again the question of what a stable arch is for
+[21:18:00] <sam_> the x86 and ppc hw is usually crap and slow
+[21:18:04] <sam_> there *are* still x86 users out there
+[21:18:11] <sam_> I know this because I broke Perl last month for them
+[21:18:18] <ulm> what's the status of m68k?
+[21:18:18] <sam_> more people noticed than I thought!
+[21:18:28] <dilfridge> also glibc broke for them and barely anyone noticed
+[21:18:45] <sam_> to be fair, that's explicitly the no-SSE2 ones which is less so, but yeah
+[21:18:50] <mgorny> is woodpecker still x86?
+[21:18:57] <mattst88> yes, woodpecker is still x86
+[21:19:08] <sam_> re x86, a lot of problems are either fp related or time_t
+[21:19:10] <arthurzam> But it runs on the new amd64 infra server
+[21:19:20] <ajak> i think only because it was migrated from some old x86 host
+[21:19:20] <sam_> the fp problems should be solved by mgorny's mfpmath=sse thing we implemented
+[21:19:28] <sam_> time_t is a global 32-bit arch thing we need to fix
+[21:19:33] <mgorny> did we finally get it into stages?
+[21:19:44] <sam_> good question
+[21:19:45] <dilfridge> yes, that also affects arm, mips, m68k, ...
+[21:19:52] <dilfridge> not yet I think
+[21:19:57] <sam_> ulm: m68k is ok but it needs a big transition (alignment change)
+[21:21:06] <dilfridge> ok, so, imho, we should downgrade ppc(32) to ~arch, but keep x86 stable for now (more users)
+[21:21:25] <dilfridge> ~arch only things are usually not so much of a problem
+[21:21:25] <ulm> sam_: that was kernel? or glibc?
+[21:21:32] <sam_> i'd still prefer the stable base for ppc32 be reduced instead but i know it's easy for me to say that and it requires work to determine what we do there
+[21:22:03] <dilfridge> well
+[21:22:16] <dilfridge> on the whole things are working right now (except for guppy :P)
+[21:22:21] <mattst88> what is the value of a stable base for ppc32?
+[21:22:27] <sam_> i already said it above a few times
+[21:22:47] <sam_> we also do have a fair influx of people into #gentoo-powerpc installing on 32-bit macs still
+[21:23:12] <mattst88> sorry, I must have missed it
+[21:23:25] <sam_> it's ok i just didn't want to repeat it again for no reason
+[21:23:28] <mattst88> the systems are slow, so keeping up with ~arch is hard?
+[21:23:30] <sam_> the issue is like, what is a stable arch for
+[21:23:42] <sam_> it's nice to be able to keep a machine up to date, and this hw is usually slow
+[21:23:57] <sam_> and also, if something is chronically broken, it's easier for it to get bricked (but i appreciate this is a more niche point)
+[21:24:01] <sam_> *critically
+[21:24:03] <arthurzam> sam_: we have the binpkg host for the base stable
+[21:24:12] <dilfridge> I can confirm that slow hardware + continuous rebuidls are a pain
+[21:24:19] <mattst88> IMO stable is for saving users time by preventing them from running into bugs that we can prevent from reaching them by the stabilization process
+[21:24:21] <sam_> like even gcc ends up killing these builders
+[21:24:58] <sam_> I have to avoid keywording gcc as much as I'd like to sometimes because I hear dilf in my ear about building gcc for a million mips ABIs because it's ~arch
+[21:25:04] <mattst88> when it's just a for-fun architecture, I don't think this is a particularly compelling reason for stabilization
+[21:25:07] <sam_> but I get your point too
+[21:25:11] <sam_> it's a good one
+[21:25:25] <sam_> oh, there's one other thing but it's related to yours
+[21:25:32] <dilfridge> sam_: is much better now, new machine
+[21:25:41] <sam_> with stabilisation, we run tests regularly for packages and at least it's fairly easy to tell when they broke
+[21:25:54] <sam_> when you stop doing that, it becomes really hard to know if they're broken because nobody is running them as a matter of course
+[21:26:07] <sam_> that's not a reason to keep stable kws forever, it's just a point i've made in the past
+[21:26:15] <mattst88> yeah
+[21:26:27] <sam_> i find your point quite compelling and hard to reconcile with how i feel about it :(
+[21:26:32] <mattst88> at the same time, I'm reminded of how long gdb was broken on sparc with no one noticing until I actually tried to use it
+[21:26:41] <dilfridge> so we have a couple of things we can do
+[21:26:46] <dilfridge> 1) reduce stable set
+[21:26:55] <dilfridge> 2) drop stable set entirely
+[21:27:22] <dilfridge> 3) in some cases, remove specific profiles (32bit s390,sparc)
+[21:27:41] <sam_> (the nuclear option for 1) if we're finding candidates hard is to just go back to roots like mattst88 did before for hppa (and other arches I think too?) and just re-stable stuff where it makes sense, too. that might even be worth it for ppc because it has loads of legacy kws. maybe even x86 as well)
+[21:27:56] <sam_> there's stuff out there with ~amd64 ppc x86 (!!!!)
+[21:28:09] <mattst88> yeah, that's a bad sign
+[21:28:42] <soap> any package with ppc but not ppc64 is likely just being dragged along
+[21:28:44] <ulm> sam_: these keywords must be at least 15 years old
+[21:28:50] <mattst88> alright, I don't think we need to decide anything here. let's move on?
+[21:29:04] <dilfridge> here's yet another thing, I would really love to have consistent deptrees everywhere (see mips)
+[21:29:21] <dilfridge> consistent as enforced by ci
+[21:29:32] <dilfridge> but yes
+[21:29:56] <dilfridge> my suggestion would be, we can talk informally over the next weeks, and maybe push some ideas on the lists
+[21:30:09] <dilfridge> for possible decisions in later meetings
+[21:30:15] <dilfridge> anyway
+[21:30:35] <dilfridge> 4. open bugs with council participation
+[21:31:05] <dilfridge> bug 925014
+[21:31:06] <willikins> dilfridge: https://bugs.gentoo.org/925014 "PR services lacking developer redundancy"; Community Relations, User Relations; CONF; ajak:pr
+[21:31:08] <dilfridge> any news?
+[21:31:44] <dilfridge> seems like not, further discussion would be redundant
+[21:31:57] <dilfridge> bug 801499
+[21:31:57] <willikins> dilfridge: https://bugs.gentoo.org/801499 "Approach Nitrokey for Nitrokey 3 upgrade"; Gentoo Foundation, Proposals; CONF; sam:trustees
+[21:32:28] <dilfridge> ulm, soap, and me got nitrokeys 3 to test them out
+[21:32:45] <ajak> i don't think i knew that people got them for testing before robin's comment but maybe you guys could comment on them?
+[21:32:45] <soap> yeah and they're not great :/
+[21:33:02] <ajak> how so?
+[21:33:07] <dilfridge> I havent really touched it yet myself, it looks like the flimsiest usb stick ever
+[21:33:24] <sam_> the previous generation (not these, no idea) were so unreliable
+[21:33:26] <ulm> the gnupg part is ok IMHO, but mechanical quality is as it was for Nitrokey 2
+[21:33:30] <sam_> i really think we should just do yubikey
+[21:33:36] <sam_> they're reliable, actually work
+[21:33:41] <soap> sam_: social contract blabla
+[21:33:49] <sam_> this is such a weak argument
+[21:33:51] <ulm> sam_: the previous generation was just an adapter for a ZeitControl card
+[21:34:01] <soap> personally, I would vote to overrule the social contract
+[21:34:03] <sam_> ah, so it's their own HW now?
+[21:34:03] <ulm> that issue should be fixed
+[21:34:16] <sam_> ajak and my's keys died after not very long
+[21:34:19] <dilfridge> and it does the fancy curve
+[21:34:38] <soap> there's no GUI app for FIDO2/admin yet, it's all a bunch of python scriptlets
+[21:34:46] <ajak> yeah mine's dead after a little while of not using it after switching to my yubi full time
+[21:34:56] <soap> the TOTP app isnt available yet
+[21:34:57] <arthurzam> My nitrokey 2 also dies like a month ago. I was copying from printed base64 page the backup for some hours
+[21:35:03] <sam_> i'm skeptical but i am open to trying them again, though soap is who I'd defer to on this
+[21:35:06] <sam_> arthurzam: :(
+[21:35:11] <ulm> I think yubikey is out of the question because it's proprietary
+[21:35:15] <soap> the USB-C connector is just padded out for the USB-A connector
+[21:35:16] <sam_> i don't believe that, sorry
+[21:35:19] <sam_> it's just nonsense
+[21:35:22] <sam_> are we doing that for infra servers?
+[21:35:27] <sam_> it doesn't scale at all
+[21:35:45] <sam_> do all infra servers need to run coreboot?
+[21:35:57] <sam_> i believe in the social contract, i don't believe it even applies here if the "social contract"-compatible option is terrible
+[21:36:06] <ajak> or our sponsors? :p
+[21:36:18] <sam_> we should try to comply with it even when we don't have to, but in this case, i think it's genuinely to our detriment
+[21:36:29] <sam_> ajak: right
+[21:36:49] <ajak> i don't think it's sustainable to prefer the obviously worse hardware especially when it's (supposed to be) such a vital part of our security posture
+[21:37:09] <ajak> the sheer incidence of hardware failures even among this small group is horrific
+[21:37:16] <sam_> (also, aren't yubikeys FSF RYF compliant anyway because you can't flash the firmware? :D)
+[21:37:32] <soap> hahahah
+[21:37:33] <ulm> ajak: hardware failure? that was for Nitrokey 2
+[21:37:37] <soap> thats actually a good point
+[21:37:57] <sam_> I just don't know what nitrokey have done to deserve our business again after such a terrible experience
+[21:38:01] <sam_> keep in mind the order form kept breaking, too
+[21:38:19] <dilfridge> the ordering experience was somewhat painful, yess
+[21:38:23] <ajak> yeah i'm not sure we have any obligation to trust that the nitrokey 3 is better
+[21:38:25] <sam_> I am open to trying them one more time but I want this discussion to be remembered when we revisit it on the next cycle if so
+[21:38:36] <sam_> (that it was a "last chance")
+[21:39:00] <sam_> dilfridge: I actually don't think I ever even got my nitrokey from them
+[21:39:04] <ajak> any reason we couldn't do both? offer nitrokeys and yubikeys?
+[21:39:06] <sam_> dilfridge: a developer donated some spare ones to me lol
+[21:39:08] <dilfridge> yubikey 5 now also does ED25519
+[21:39:17] <ajak> that's important too, yeah
+[21:39:18] <ulm> if you want I'll crack my sample open and post some photos :)
+[21:39:33] <dilfridge> un-cracked is sufficient
+[21:39:57] <ulm> comparison Nitrokey 2 vs 3 I mean
+[21:40:21] <sam_> I also do wish that we'd discussed this *before* approaching nitrokey again
+[21:40:29] <sam_> I was taken by surprise when robbat2 contacted them
+[21:40:32] <ajak> i don't think the comparison between the two is particularly useful
+[21:40:38] <ajak> yeah me too
+[21:40:50] <dilfridge> well, yes, that was a tad surprising
+[21:40:51] <ulm> no harm done I think? we don't have any obligation
+[21:41:05] <sam_> well, it's just a bit unprofessional if we were going to then vote against it or something
+[21:41:11] <sam_> it would've been worth speaking about it
+[21:41:28] <dilfridge> well, if you can't say no, there is no point in getting samples
+[21:41:34] <sam_> yeah good point
+[21:41:43] <ulm> dilfridge: +1
+[21:41:49] <arthurzam> You also wrote about it bad stuff in the bug
+[21:41:54] <arthurzam> So not a surprise
+[21:42:02] <sam_> honestly it was so long ago that I forgot what I wrote ;)
+[21:42:06] <ulm> USB-C form factor is simewhat unfortunate
+[21:42:14] <ulm> *somewhat
+[21:42:17] <soap> because USB-C was an afterthought
+[21:42:37] <ulm> yeah, looks like
+[21:43:04] <dilfridge> in the time they took to develop it, whole usb generations passed by
+[21:43:15] <sam_> anyway I won't stand in the way, to be clear
+[21:43:16] <ajak> i'm not sure we have any consensus here, do we?
+[21:43:19] <sam_> not sure if we should vote on it or what
+[21:43:36] <dilfridge> well, who else
+[21:43:47] <ulm> we could do an informal vote at least
+[21:44:00] <dilfridge> ok
+[21:44:04] <ulm> to get a picture of opinions
+[21:44:27] <arthurzam> I think it is a 3 way vote (only A, only B, both)
+[21:44:28] <sam_> also to be clear, am grateful to robbat2 for doing the work, I just meant I felt mixed about it because of my poor experiences with them and wanted to lobby for adopting yubikey, but if there's no obligation (as proven by e.g. samples), it's fine to me
+[21:44:41] <dilfridge> motion: approach nitrokey for a renewal of keys for developers with nitrokey 3: yes, no, abstain
+[21:44:51] <ulm> I'd vote against Yubikey
+[21:44:59] -*- soap no
+[21:45:03] -*- sam_ no
+[21:45:06] -*- dilfridge abstain
+[21:45:09] -*- ulm abstain
+[21:45:22] -*- mgorny abstain
+[21:45:28] -*- ajak no (but wouldn't mind seeing both foundation-provided yubis + nitrokeys)
+[21:45:41] <sam_> ulm: you didn't respond to my arguments above though regarding yubikey? I just don't see how it violates the social contract? And supposing it did, if they're unreliable, how is that okay?
+[21:45:57] <sam_> ulm: there's no real third game in town for these
+[21:45:59] <ajak> maybe that can be a research project for next meeting (/council)
+[21:46:01] <dilfridge> mattst88: ^
+[21:46:13] <ulm> sam_: IMHO the choice between open and closed hardware is clear
+[21:46:15] <sam_> there's the google tokens but they're limited
+[21:46:31] <ajak> must be a very good sandwich :D
+[21:46:31] <soap> ulm: that still hasnt engaged with sam's argument
+[21:47:10] <dilfridge> ok that's 3 no, 3 abstain, 1 missing
+[21:47:16] <ulm> soap: that one cannot flash the firmware?
+[21:47:17] <sam_> I'm all for open hardware and software, but the hardware doesn't work, and I don't see how it even violates the social contract
+[21:47:21] <soap> si
+[21:47:25] <dilfridge> we should probably attach another motion
+[21:47:25] <sam_> as I said, it's arguably even RYF compliant
+[21:47:43] <dilfridge> motion: approach yubikey and try to establish a similar deal, yes no abstain
+[21:47:47] <sam_> but hell, what does the freedom matter for a yubikey or nitrokey given you can't flash either?
+[21:47:48] -*- sam_ yes
+[21:47:51] -*- ulm no
+[21:47:51] -*- ajak yes
+[21:47:53] -*- soap yes
+[21:48:01] -*- dilfridge abstain
+[21:48:08] -*- mgorny yes
+[21:48:21] <dilfridge> mattst88: ?
+[21:48:48] -*- ajak doesn't think a "similar deal" should be a prereq to establish a similar gentoo<->developer deal though
+[21:49:16] <dilfridge> anyway, that's 4 yes, 1 no, 1 abstain, 1 missing, motion in all its vagueness carried
+[21:49:27] <ajak> ie they might just say "just buy like everyone else" and that should be fine, foundation or whatever can still buy and send to devs
+[21:49:44] <sam_> yeah, fair point
+[21:49:45] <dilfridge> sure
+[21:49:51] <dilfridge> but everyone likes sponsors :P
+[21:49:54] <sam_> :)
+[21:49:57] <sam_> tbh I think we should do more there
+[21:50:01] <sam_> you don't ask, you don't get...
+[21:50:12] <dilfridge> ok
+[21:50:19] <dilfridge> let's leave it with that for the moment
+[21:50:25] <sam_> i know this was a long 'un but i feel like this was overall quite useful
+[21:50:29] <dilfridge> 5.
+[21:50:32] <dilfridge> open floor
+[21:50:35] -*- mattst88 yes
+[21:50:40] <mattst88> (sorry)
+[21:50:42] <sam_> just to say I've got my new laptop and will be doing my summaries shortly
+[21:50:43] <dilfridge> (for what?)
+[21:51:03] <mattst88> yes for approaching yubikey
+[21:51:07] <dilfridge> oh yeah right summaries
+[21:51:15] -*- dilfridge summons a summary
+[21:51:22] <arthurzam> Can I request council members reply to election nominations?
+[21:51:54] <dilfridge> I'm sorry, but as an AI language model I cannot ... wait
+[21:52:01] <arthurzam> And I would like to also thank all council members for the good year of counseling - this council did a lot
+[21:52:45] <dilfridge> thanks arthur
+[21:53:03] <dilfridge> time to get into the mood for next year :D
+[21:53:20] <ulm> I'm a little disappointed about progress of the transition to SPI
+[21:53:33] <ulm> maybe the next council should take the initiative there
+[21:54:02] -*- mattst88 recalls the first meeting of this council where he suggested we take the initiative
+[21:54:03] <dilfridge> ulm: without intending to overestimate my influence there, once we got as far as we are now, I was very glad to have a bit of time for other stuff again
+[21:54:04] <ajak> we made more progress this year than in previous years :)
+[21:54:07] <ulm> e.g. transfer of copyrights and trademarks is still pending
+[21:54:17] <dilfridge> ulm: so, I did not mind that it slowed down
+[21:54:40] <ulm> dilfridge: yeah, but keeping some momentum would be good :)
+[21:54:59] <dilfridge> time to go back into first gear, push the pedal to the metal and see the gravel fly
+[21:56:05] <dilfridge> right
+[21:56:09] <dilfridge> anything else?
+[21:56:57] <dilfridge> apparently not. then <bang> meeting closed. we meet again for the sentencing... oh wait, different story...
+[21:57:09] <ajak> thanks for chairing!
+[21:57:27] <sam_> thanks!
+[21:57:33] <dilfridge> thanks all
+[21:57:35] <mgorny> thanks and gn
diff --git a/meeting-logs/20240609.txt.asc b/meeting-logs/20240609.txt.asc
new file mode 100644
index 0000000..e348d0b
--- /dev/null
+++ b/meeting-logs/20240609.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmeVRLdfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE
+MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V
+QSqLTA//SYtlHmWPwer2o0qSPlGQO40OzKr5H4WQu5D04CnWpD8XiGblX1DO+vHT
+78v+AGwN8XTQxtG69XTwu7JsG2C4ndTUfOsaQN3PZ0Nv7p5M70dcJpx9QsVZLnQK
+AKg3wYqPuSkdfedejRk4F4Z+p8BG4nziVMCwu0oSlfuJUjCTI6qAURkxNjL/y8zZ
+bx49XV3NfaSe0BOZM8wvnT9WiUiSx+kKOBNHpuhaqTinQ0KAdbp4Ncj8sie2Anzt
+bWaMmKbhIMO2bXElvkgi/l/RhUhDCtrdnR2TEBfs8sIbUX/yRpz6dMS/zCEEU+VS
+LASYjZ/ETVee9G8pzcwCjkMWLNnBxSlUOwkPZxaB7WiVc+5kJQbzsrLqZR55Ai5F
+Ki629mmQ+zbdGY9p97mu/FmMhcRsieGBreiZq1/I+rcg6LhRXRV6T0XX/RfeJ7Ek
+FJa/6lcEri8+zIrRvFJ4lKF1MyG7Gr9XKriuQNXXgf20PjvcsIfBwcev/JvCbsYN
++g0s8Yzu/92aV0pmZWWUBktdbgfQzQhRrQ/ZNmF2kbM3SAD+m6yAwGjDX4VLVfV2
+sBwHcszBQyDGVHE+f/Cb/hkfZp6rZrMdsyC7lnxl8D/jKB6ZwutJP/7tVpHVo8ID
+X1XRB84dOWzR0QnXC25L1ckJL0859tLhtLpeB+8h/KnirwrVi9k=
+=K1CI
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20241013.txt b/meeting-logs/20241013.txt
new file mode 100644
index 0000000..6011ebc
--- /dev/null
+++ b/meeting-logs/20241013.txt
@@ -0,0 +1,247 @@
+[00:00:00] - {Tageswechsel: Sonntag, 13. Oktober 2024}
+[21:00:40] <dilfridge> meeting time
+[21:00:42] <dilfridge> !proj council
+[21:00:43] <willikins> (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm
+[21:00:51] <dilfridge> 1) roll call
+[21:00:53] -*- ulm here
+[21:00:55] -*- arthurzam here
+[21:00:55] -*- sam_ here
+[21:00:58] -*- dilfridge here
+[21:01:00] -*- soap here
+[21:01:07] -*- mgorny here
+[21:01:07] <robbat2> present
+[21:01:16] <dilfridge> excellent, all here
+[21:01:24] <dilfridge> 2) apology
+[21:01:36] <dilfridge> sorry, I completely forgot about sending out the mails
+[21:01:42] <dilfridge> even though arthurzam tried to remind me
+[21:02:02] <dilfridge> I think there wasn't much other business that couldve come up though
+[21:02:08] <dilfridge> so damage is limited
+[21:02:37] <dilfridge> mgorny sent one reply to the thread so this is our one nonstandard agenda item
+[21:02:41] <arthurzam> it happens, let's just try to not repeat next time :)
+[21:02:49] <dilfridge> 3) time64
+[21:03:13] <dilfridge> mgorny already summarized the situation, there's not much I can add
+[21:03:23] <dilfridge> we tried to work with debian, they werent interested
+[21:03:31] <dilfridge> now we only get angry wookie noises
+[21:03:36] <soap> mgorny: final question, utmp?
+[21:03:48] <soap> utmp is the one thing people overlook with time64
+[21:03:59] <mgorny> errr, i'm not the person to answer that
+[21:04:11] <robbat2> i have another question re the proposal to change chost value
+[21:04:11] <mgorny> i'm only doing ground work here
+[21:04:36] <sam_> soap: the problem is, the suse guy is sort of leading the charge to just replace it with logind
+[21:04:44] <sam_> we haven't got an alternative plan there right now
+[21:04:52] <soap> and he's right tbh
+[21:05:09] <soap> but ofc the usual crowd will come with non-suggestions
+[21:05:25] <mgorny> lemme rephrase: i'm tackling the transition part, not the design of time64 systems per se
+[21:05:30] <sam_> "just make it unsigned" (which is not a terrible idea but if we're going to do that, let's just make it a proper 64-bit type anyway, it doesn't have to be time_t)
+[21:05:40] <dilfridge> that's happened anyway
+[21:05:47] <sam_> i need to reboot, my rendering is broken for a moment
+[21:05:48] <dilfridge> I think the code is already in glibc
+[21:05:49] <sam_> please hold
+[21:05:55] -*- dilfridge holds
+[21:06:21] <robbat2> maybe good that I explain my CHOST question while he's rebooting
+[21:06:22] <soap> mgorny: the transition needs to account for utmp, since it's still broken, is what I'm saying
+[21:06:53] <dilfridge> explain
+[21:07:17] <mgorny> also, any ideas?
+[21:07:24] <soap> you want to fix the Y2038 problem, but utmp is still broken
+[21:07:33] <soap> I agree with the suse guy, dump utmp
+[21:07:40] <soap> it's broken by design
+[21:07:57] <mgorny> if you want to have a new utmp format, i suppose we could go for changing path too but that's upstream work, not mine
+[21:08:22] <mgorny> i'm all for declaring it unsupported
+[21:08:22] <soap> the reason they havent changed utmp is because people want to use their 20 year old wtmp DBs
+[21:08:27] <soap> since that is so valuable
+[21:08:44] <mgorny> tho i think we should start by declaring it unsupported on new systems xD
+[21:09:09] <robbat2> i've been around long enough that I experienced the x86 CHOST change of i[45]86-pc-linux-gnu -> i686-pc-linux-gnu; and I recall finding lots of apps that did bad hardcoding or other weird assumptions; 1. how much pain do we expect in Gentoo to identify these source-built packages; 2. how will running pre-built binaries behavior in this? [e.g. I used the Zoom binary client today to offer tech
+[21:09:15] <soap> fine with me, wait for the usual crowd of people to complain
+[21:09:15] <robbat2> support to a relative]
+[21:09:52] <ulm> robbat2: there's no x86 zoom client?
+[21:10:06] <mgorny> robbat2: my random choice of packages found issues with two: ncurses and clang
+[21:10:27] <mgorny> there might be more, we need more testing obvsly
+[21:10:33] <dilfridge> first of all this affects only i[456]86 (x86), NOT amd64 (x86_64)
+[21:10:38] <mgorny> for clang, i've got upstreamable patch that's basically waiting for gentoo to confirm
+[21:10:52] <mgorny> for ncurses, they're doing really stupid stuff
+[21:11:16] <dilfridge> basically bad stuff happens if you write your own automake
+[21:11:27] <robbat2> ulm: there is a 32-bit zoom client specifically
+[21:11:47] <ulm> robbat2: there used to be, but no longer
+[21:11:50] <mgorny> in the end, some of the stuff already had to become more flexible for *-gnueabi and *-gnueabihf
+[21:11:57] <soap> ncurses has a terrible upstream
+[21:12:09] <robbat2> thanks; so I probably have to get that relative a newer laptop that isn't 32-bit
+[21:12:36] <mgorny> also, i don't think prebuilt binaries care about CHOST much, unless you're asking the wider question of time64 transition
+[21:12:41] --> sam__ (~sam@82.8.138.118) hat #gentoo-council betreten
+[21:12:51] <sam__> hello, i can't get back to a desktop, here via irssi temporarily
+[21:12:55] <sam__> i'll debug it post-meeting
+[21:12:58] <dilfridge> ack
+[21:12:59] <sam__> can someone tell me what robin's question was?
+[21:13:03] <robbat2> some prebuilt binaries really did care about the chost
+[21:13:04] <-> sam__ heißt jetzt Guest3800
+[21:13:06] <robbat2> sam__: will repeat
+[21:13:13] <robbat2> i've been around long enough that I experienced the x86 CHOST change of i[45]86-pc-linux-gnu -> i686-pc-linux-gnu; and I recall finding lots of apps that did bad hardcoding or other weird assumptions; 1. how much pain do we expect in Gentoo to identify these source-built packages; 2. how will running pre-built binaries behavior in this? [e.g. I used the Zoom binary client today to offer tech
+[21:13:19] <robbat2> support to a relative]
+[21:13:48] <arthurzam> sam_: https://bpa.st/CBUA
+[21:13:59] <mgorny> robbat2: but why do they even know CHOST?
+[21:14:10] <mgorny> i mean, it's a build-time property
+[21:14:13] <Arsen> and how? do they run gcc -dumpmachine or something?
+[21:14:22] <Guest3800> for 2., I'm not worried about it at all, because they'll be busted in >=2038, they'll also be busted with large inodes often (i.e. we're not worried about keeping legacy apps working, but mgorny's plan does mean we will keep 32-bit libc around AFAIK for easy testing and so on)
+[21:14:27] <-> Guest3800 heißt jetzt sam_crashed
+[21:14:42] <sam_crashed> like, the whole thing here is "yes, we have to break ABI, so we accept prebuilt stuff won't work"
+[21:14:56] <sam_crashed> it's only for 32-bit systems which have a timebomb anyway
+[21:15:01] <sam_crashed> for 1., it's a harder problem
+[21:15:08] <sam_crashed> we already had ncurses' configure script break because it handrolls the logic
+[21:15:09] <dilfridge> as long as some application only uses libc and no other libraries, it will still work
+[21:15:30] <dilfridge> otherwise expect tons of breakage
+[21:15:31] <robbat2> mgorny: it was a long time ago that I recall this from; sorry I don't recall the details of how
+[21:15:53] <mgorny> dilfridge: work until 2038, then everything will fall apart
+[21:16:00] <dilfridge> exactly
+[21:16:04] <mgorny> unless you faketime hard
+[21:16:16] <ulm> also, we'd still keep some time32 profiles I suppose?
+[21:16:22] <mgorny> also faketime is broken on modern glibc, there still haven't been a reply to my bug
+[21:16:29] <robbat2> should we even do this work, or just declare end of x86 support entirely in 2028 or something/
+[21:16:39] <sam_crashed> yes, we should, because it affects e.g. arm as well
+[21:16:42] <dilfridge> ulm: yes, keep a minimal set
+[21:16:47] <sam_crashed> also because we already did the hard bit in a sense
+[21:16:54] <sam_crashed> (the planning for the transition is the worst of it)
+[21:16:57] <dilfridge> it affects all 32bit arches except riscv32
+[21:17:13] <sam_crashed> i also think we're sort of the last bastion for these things
+[21:17:19] <dilfridge> this
+[21:17:24] <sam_crashed> if we won't do it, nobody will, and it's kind of sad to let it all rot for something where it's actually completely doable
+[21:17:38] <sam_crashed> is it hard, yes, but it's not intractable
+[21:17:56] <sam_crashed> (but it's a fair question)
+[21:18:06] <sam_crashed> we also have people hitting it **now**
+[21:18:12] <sam_crashed> so to not do it would essentially mean we're going to drop 32-bit support far sooner
+[21:18:24] <sam_crashed> we have python testsuites failing all the time on this because people are e.g. trying to test THEIR y2038 compat (lol)
+[21:18:37] <sam_crashed> but there's sometimes more insidious less trivial cases
+[21:19:01] <sam_crashed> the ino_t thing actually bites pretty hard as well, because of how various filesystems handle inode recycling
+[21:19:08] <sam_crashed> dilfridge has hit this a lot in releng i think
+[21:19:17] <dilfridge> yes
+[21:19:30] <dilfridge> actually because of this we (everyone) carry a nonstandard glibc patchset
+[21:19:31] <robbat2> thanks; so we have to do something much sooner :-(
+[21:20:32] <dilfridge> ideally we get things migrated soon and keep a few profiles / stage builds for people who need full binary compatibility
+[21:21:11] <sam_crashed> for x86 in particular we care about that, for others we probably won't (but open to discussion ofc)
+[21:21:17] <dilfridge> yes
+[21:21:29] <dilfridge> but once we have handled x86, the rest is boring busywork
+[21:21:32] <sam_crashed> yeah
+[21:22:00] <dilfridge> and for all the arm gadgets / embedded stuff it's probably useful too
+[21:22:13] <dilfridge> dito mips if it exists
+[21:22:32] <robbat2> mgorny: what actions do you think the council should take regarding this?
+[21:23:00] <mgorny> no real actions today, i'm mostly looking whether we're on the same page wrt *t64 suffix
+[21:23:10] <mgorny> so i could merge patches into clang without having to change them later
+[21:23:16] <sam_crashed> (as it involves making representations/claims/etc to 3r dparties)
+[21:23:21] <dilfridge> I came up with it, so as far as I'm concerned, go with it
+[21:23:25] <mgorny> once we have more packages fixed, further testing will be easier
+[21:24:38] <dilfridge> any other opinions / statements / questions / wishes?
+[21:24:42] <robbat2> thanks to whomever produced the nice summary table on the wiki page; I think the best option from that is "New profiles, new chost"
+[21:24:45] <dilfridge> (related to this topic)
+[21:24:53] <ulm> so the plan for the triplet is to append t64 to the third field for time64, and keep the existing triplet for time32?
+[21:25:01] <dilfridge> yes
+[21:25:06] <ulm> k
+[21:25:13] <sam_crashed> yes, quite proud of the wiki page
+[21:25:35] <dilfridge> (more precisely, on global scale, "keep existing triplet for time32 in gentoo, and anything elsewhere blargh debian)
+[21:25:42] <mgorny> ulm: fourth field, i think
+[21:25:48] <mgorny> third is "linux"
+[21:26:06] <dilfridge> i686-pc-linux-gnut64
+[21:26:15] <ulm> why is it called triplet then :)
+[21:26:19] <mgorny> don't ask me
+[21:26:22] <dilfridge> tuple
+[21:26:32] <dilfridge> triplet is without the vendor field
+[21:26:32] <mgorny> also *-gnueabit64 and *-gnueabihft64
+[21:26:38] <mgorny> for nice pronunciation
+[21:26:43] <dilfridge> i686-linux-gnut64
+[21:26:54] <sam_crashed> can't be worse than riscv
+[21:26:57] <sam_crashed> are we all happy then?
+[21:26:58] <dilfridge> ^ this is normalized by config.sub to i686-pc-linux-gnut64
+[21:27:17] <sam_crashed> not to rush everyone but i'm sort of nervous of retreading everything given we've sort of been through it a _lot_ internally in toolchain and so on
+[21:27:25] <sam_crashed> and i don't want to veer into some option we already discounted
+[21:27:39] <dilfridge> yes, it's nice this finally converged somehow
+[21:27:51] <dilfridge> so - last chance to object
+[21:27:52] <dilfridge> 10
+[21:27:54] <dilfridge> 9
+[21:27:55] <dilfridge> 8
+[21:27:57] <dilfridge> 7
+[21:27:59] <dilfridge> 6
+[21:28:00] <dilfridge> 5
+[21:28:02] <dilfridge> 4
+[21:28:03] <dilfridge> 3
+[21:28:04] <robbat2> ship it
+[21:28:05] <mgorny> i suppose you're also fine with the plan not to change libdir, break ABI compat, and use libt32 for transition?
+[21:28:26] <mgorny> tho ofc it needs more testing
+[21:28:34] <sam_crashed> I would like us to, if possible, have a way to keep legacy binaries around for testing (even if we don't use it in the final scheme), but I'm not married to it, and we can talk about that separately
+[21:28:43] <dilfridge> mgorny: I'm personally ambivalent, but since you've worked out the plan and it seems to work I'm willing to go with it
+[21:28:47] <sam_crashed> yeah
+[21:28:50] <robbat2> plz no libt32; the equivilent was mip's n32/n64 era, and it was painful
+[21:29:10] <mgorny> robbat2: it's only temporary, and not used by sources
+[21:29:12] <dilfridge> the libt32 is only for the duration of the rebuild
+[21:29:20] <mgorny> you haven't looked at time64-prep, did you?
+[21:29:24] <sam_crashed> tbh actually I sort of withdraw my "I would like to" above, as we can already cross for that
+[21:29:43] <dilfridge> sam_crashed: also we can use a t32 stage
+[21:29:44] <mgorny> sam_crashed: yeah, i'm afraid i can't see a good way to preserve full binary compat
+[21:29:55] <mgorny> the best we can do is switch prebuilt stuff to bundle 32-bit libs
+[21:29:59] <soap> you'd need to pull another LFS
+[21:30:08] <dilfridge> no no no, not more horror
+[21:30:12] <soap> zactly
+[21:30:20] <sam_crashed> ok nvm
+[21:30:27] <dilfridge> so ship it
+[21:30:45] <sam_crashed> yes
+[21:30:46] <mgorny> i mean, any attempt at multilib is blocked on ld.so being unable to distinguish binaries
+[21:30:53] <sam_crashed> yeah, sorry, I forgot that
+[21:30:58] <dilfridge> yes and fixing that is an insane amount of fiddling
+[21:31:04] <dilfridge> which noone will be happy about
+[21:31:10] <sam_crashed> yes
+[21:31:11] <mgorny> it's kinda doable by injecting RUNPATH and so on but meh
+[21:31:18] <sam_crashed> ignore me, I sort of forgot about the complexity with our discussion and what we tried
+[21:31:20] <dilfridge> ok with that our short agenda is essentially over, so we come to
+[21:31:20] <robbat2> time64-prep does have the same problem as the n32/n64 era - dynamically loaded libraries
+[21:31:21] <sam_crashed> not worth it
+[21:31:24] <dilfridge> 4) open floor
+[21:31:26] <dilfridge> anyone?
+[21:31:29] <arthurzam> yes
+[21:31:33] <robbat2> yes to open floor
+[21:31:37] <arthurzam> https://wiki.gentoo.org/wiki/Project:Council/Meeting_logs
+[21:31:48] <arthurzam> dilfridge: missing 05 and 06 month
+[21:31:58] <mgorny> robbat2: it's as good as it can get us, for the limited risk of time32/time64 mixing
+[21:32:07] <dilfridge> ok
+[21:32:09] <dilfridge> on it
+[21:32:32] <arthurzam> (I remember you said you have time for that in October, so here I remind :)
+[21:32:35] <dilfridge> heh
+[21:32:37] <ulm> september missing too
+[21:33:15] <ulm> soap: ^^
+[21:33:26] <mgorny> (i'll merge the clang changes tomorrow, in case they break something)
+[21:33:32] <sam_crashed> iirc soap did it all
+[21:33:32] <soap> should be up?
+[21:33:36] <sam_crashed> maybe need to update wiki
+[21:33:39] <mgorny> and ideally there'll be in next 20.x snapshot
+[21:33:40] <sam_crashed> but i remember the emails
+[21:33:43] <soap> oh yes
+[21:33:46] <soap> didnt update the wiki
+[21:33:55] <sam_crashed> mgorny: i'll ack them once i fix kwin post-meeting as well
+[21:34:09] <ulm> yeah, it's in the repo but not linked from the page
+[21:35:36] <arthurzam> ok, done from me for open floor
+[21:35:39] <arthurzam> robbat2?
+[21:36:04] <robbat2> i want to report that i've had zero progress from SPI's treasurer in getting the updated paypal links created by them
+[21:36:21] <dilfridge> ugh
+[21:36:37] <robbat2> specifically; this would be paypal links to go on Gentoo's donate page, that ensure the donation is correctly credited to us in SPI's accounting
+[21:36:45] <dilfridge> want me to pop up at the next board meeting too?
+[21:36:55] <robbat2> i gave them a set of detailed instructions, and offered to do a 1:1 zoom session to show
+[21:36:56] <sam_crashed> what's the current situation?
+[21:37:01] <sam_crashed> like they go to SPI unmarked?
+[21:37:13] <sam_crashed> or we have to manually xfer from our paypal?
+[21:37:18] <robbat2> our donate page still goes to our own account OR you can click through a few levels into their donation system
+[21:37:40] <sam_crashed> ok so it could be worse but not good either
+[21:37:47] <robbat2> the goal is that you should be able to donate directly from our page: https://www.gentoo.org/donate/
+[21:37:54] <robbat2> fill that out, get paypal checkout, done
+[21:38:22] <sam_crashed> dilfridge: i think this might be a good idea
+[21:38:28] <sam_crashed> from watching the channel it looks like their ticket system loses stuff sometimes
+[21:38:33] <sam_crashed> robbat2: thx
+[21:38:44] <sam_crashed> (also arthurzam thx for logs earlier, forgive me being scatty, not easy with just text)
+[21:39:16] <arthurzam> sam_: it's ok
+[21:39:53] <robbat2> i'm going to raise this at their next monthly meeting as well
+[21:39:56] <sam_crashed> thanks
+[21:40:16] <robbat2> (it's tommorow)
+[21:40:28] <robbat2> but I didn't want it to be a surprise to anybody here
+[21:40:37] <dilfridge> robbat2: what time?
+[21:40:46] <robbat2> 2024/10/14 20:00 UTC
+[21:40:52] <dilfridge> ok
+[21:41:13] <ulm> thanks, I'll try to be there too
+[21:42:00] <robbat2> that's all for me
+[21:42:20] <dilfridge> anyone else?
+[21:43:13] <dilfridge> seems not
+[21:43:15] <dilfridge> then
+[21:43:23] -*- dilfridge bangs the gavel, meeting closed
diff --git a/meeting-logs/20241013.txt.asc b/meeting-logs/20241013.txt.asc
new file mode 100644
index 0000000..670f384
--- /dev/null
+++ b/meeting-logs/20241013.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmeVQ/dfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE
+MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V
+QSonQA/+Ke090uwfoMQO0P7nkFaydJWpIfeAe0qIwme8uMva/CGlCYezjKSadPXY
+x3H5PyuDPB2U67PXyHNFiNNf2tZ3A1AXo75A2RPc6ImmGfnluTvwpyc/qxJxoy1k
+42zJ0N+RQAE4whLpF22LNC2OZrsydWI/Mb2w63iISB3KccHkbl7QYE+qYCraVyF/
+vq91YABnHUH5C3ECVwoMAP8awtyNg8IImYNq/EAK/gHddxkOM+X5Ko0/LwZnp8mL
+Ae9QEumfYsVqBk4v4Cj8CuiRgvyRR3BcIw4BZEc7i8oe2XaOAIW3iFAGchclj+Tv
+7G9CaRHEQ0vwKO0ryFUM1gI0Jt3P4M/1UyeVbe4JK/0oYpo287rLjWjOSyk+oZBq
+CEHNyi/pbRYliLdCPuM7iZWS/+ydHEujlNr/xOx5xLMhGUuR5gYpkyx9YicPYHOz
+wdd+H+BoIcOzPigGI21aAXUc7bdXP25JHUOe9Gwo2KF5igtMTcFzfcu6t4PbRXNV
+EbuvCeMF7ILtib4AbVLpBYAZofaAGtBPFWli1kR0rd+DafsQOhx6kqrr+G+h0aFP
+5QTb2FaGc7+Bn8hbXpugZR9nSRmdTbETly+UfxbYYaAandnX9tkbXQXjoUCknRCB
+Kz3r8JmFBtcmFD0dwJdlb3oEy88+wovFzYou5C5rwWuNnexa+HQ=
+=ATE4
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20241110.txt b/meeting-logs/20241110.txt
new file mode 100644
index 0000000..84089ee
--- /dev/null
+++ b/meeting-logs/20241110.txt
@@ -0,0 +1,86 @@
+[00:00:00] - {Tageswechsel: Sonntag, 10. November 2024}
+[20:00:31] <robbat2> oi; meeting time
+[20:00:36] <dilfridge> yup
+[20:00:41] <dilfridge> meeting time
+[20:00:44] <dilfridge> !proj council
+[20:00:45] <willikins> (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm
+[20:00:46] <robbat2> roll call!
+[20:00:47] <dilfridge> roll call
+[20:00:51] <robbat2> present
+[20:00:53] -*- sam_ her
+[20:00:55] <sam_> e
+[20:00:55] <dilfridge> present
+[20:01:02] -*- mgorny here
+[20:01:08] -*- soap_ here
+[20:01:16] <ulm> +1
+[20:01:54] <dilfridge> arthurzam: ping
+[20:02:24] <dilfridge> let's wait until 20:05 and then proceed
+[20:02:45] <dilfridge> (CET :)
+[20:03:48] <dilfridge> does anyone have a number to text arthurzam?
+[20:04:11] -*- ulm just wanted to ask this
+[20:05:08] <dilfridge> anyway let's continue (maybe we can swap numbers in private later, for future meetings)
+[20:05:13] <dilfridge> so
+[20:05:24] <dilfridge> the agenda is somewhat boring, no topics have been submitted
+[20:05:53] <dilfridge> which means the first item is already, open bugs with council participation
+[20:06:17] <dilfridge> I see four bugs
+[20:06:22] <dilfridge> bug 924014
+[20:06:22] <willikins> dilfridge: https://bugs.gentoo.org/924014 "sys-auth/pam_ssh: stabilize on arm64"; Gentoo Linux, Stabilization; RESO, FIXE; pkubaj:maintainer-needed
+[20:06:28] <dilfridge> err
+[20:06:31] <dilfridge> no, typo
+[20:06:35] <dilfridge> bug 925014
+[20:06:36] <willikins> dilfridge: https://bugs.gentoo.org/925014 "PR services lacking developer redundancy"; Community Relations, User Relations; CONF; ajak:pr
+[20:07:02] <dilfridge> This is probably at the moment not an issue anymore.
+[20:07:22] <dilfridge> Does anyone want to take care of X, or should we shut it down?
+[20:07:49] <dilfridge> I have the password, but honestly dont feel much inclined to work with it anymore.
+[20:08:14] <robbat2> keep it for critical announcements only?
+[20:08:18] <dilfridge> OK
+[20:08:27] <robbat2> ensure foundation trustees have it in the shared passwords?
+[20:08:48] <dilfridge> do we have shared passwords? :O
+[20:09:06] <robbat2> yes, infra uses pass, foundation have it in the repo in gpg files
+[20:09:23] -*- dilfridge is somewhat concerned about the onboarding now
+[20:09:50] <ulm> this reminds be that I wanted to file a bug about our web page footer, which curretly has twitter and facebook, both with their old logo, and no mastodon
+[20:09:51] <dilfridge> but anyway we can handle that outside the meeting
+[20:09:59] <ulm> *currently
+[20:10:01] <dilfridge> yes
+[20:10:07] <dilfridge> and if we change it we should add LinkedIn
+[20:10:37] <ulm> but no need to discuss it now, of course
+[20:10:43] <dilfridge> ok
+[20:10:54] <dilfridge> bug 801499
+[20:10:55] <willikins> dilfridge: https://bugs.gentoo.org/801499 "Approach Nitrokey for Nitrokey 3 upgrade"; Gentoo Foundation, Proposals; CONF; sam:trustees
+[20:11:02] <dilfridge> close it?
+[20:11:39] <dilfridge> apparently there are no objections to that, so I'm gonna just do it
+[20:11:43] <ulm> yep
+[20:11:55] <ulm> and open a new bug for yubikey if necessary
+[20:12:04] <robbat2> arthurzam was supposed to be asking yubikey; but we have not seen an update on that
+[20:12:16] <dilfridge> bug 936914
+[20:12:16] <willikins> dilfridge: https://bugs.gentoo.org/936914 "arm64: Short-term replacement for jiji.arm.dev.gentoo.org"; Gentoo Foundation, Proposals; CONF; robbat2:trustees
+[20:12:27] <dilfridge> we can probably close that too
+[20:13:05] <dilfridge> the short-term replacement was susuwatari.arm... but since we have dola.arm.... now robbat2 already handed it back I think
+[20:13:17] <robbat2> yes
+[20:14:18] <dilfridge> closed
+[20:14:29] <dilfridge> bug 936211
+[20:14:30] <willikins> dilfridge: https://bugs.gentoo.org/936211 "[Tracker] Gentoo Foundation dissolution"; Gentoo Foundation, Proposals; CONF; ulm:trustees
+[20:14:44] <dilfridge> robbat2: any news about the paypal stuff?
+[20:15:09] <-- npc (~yTQsBfexO@user/spareproject) hat das Netzwerk verlassen (Read error: Connection reset by peer)
+[20:15:24] --> op (~nqnqAkscl@user/spareproject) hat #gentoo-council betreten
+[20:15:36] <robbat2> SPI said they would do it, but no progress :-9
+[20:15:44] <robbat2> *supposed to be :-(
+[20:16:16] <dilfridge> ok, let's poke them more with blunt instruments
+[20:16:43] <dilfridge> that's it from the bugs side
+[20:16:52] <dilfridge> so, next agenda item
+[20:16:54] <dilfridge> OPEN FLOOR
+[20:16:56] <dilfridge> anyone
+[20:18:00] <dilfridge> waiting another minute
+[20:18:08] <robbat2> *crickets chirp*
+[20:18:54] <dilfridge> nothing
+[20:19:05] <dilfridge> so that means, we're all done, meeting closed
+[20:19:07] <dilfridge> <bang>
+[20:19:17] <sam_> thank you!
+[20:19:18] <dilfridge> thanks everyone
+[20:19:18] <soap_> thanks!
+[20:19:23] <mgorny> thx
+[20:19:28] <dilfridge> sub-20min is a good time
+[20:19:34] <ulm> thanks for chairing
+[20:20:54] * ulm has changed topic for #gentoo-council to: "256th meeting: 2024-12-08 19:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20241208T19 | https://wiki.gentoo.org/wiki/Project:Council | https://dev.gentoo.org/~dilfridge/decisions.pdf"
+[20:21:28] <ulm> jubilee next month, 256th meeting :)
+[20:22:14] * ulm has changed topic for #gentoo-council to: "0b100000000th meeting: 2024-12-08 19:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20241208T19 | https://wiki.gentoo.org/wiki/Project:Council | https://dev.gentoo.org/~dilfridge/decisions.pdf"
diff --git a/meeting-logs/20241110.txt.asc b/meeting-logs/20241110.txt.asc
new file mode 100644
index 0000000..ed2c3c6
--- /dev/null
+++ b/meeting-logs/20241110.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmeVQ3BfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE
+MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V
+QSr7URAAkcY6F/pCE+MADt+FXfwgTGFagSz/HpF/ZtwcXwHf4f6msIrOAGVxdOfM
+ElfPQffj9M822/Tql6tvIme6WXqLDAIpHeC8eJwlzi1cX7u/shGx7Um0OFkIpdDM
+IXAqmGmBRhKiHpvcTCKcLs9P64NrqLCITXKxT9bKp5lZPIBvP5YX4inURKYOnnL8
++Oe5XEvBLjOaiZ7YjIDKGa15ukXlCMxLdro8yMjuOYHNBU6+5KWZLds10l9PPwaa
+g8ZVpxsL1knVt+hozfvb4+IqFyEJ/CB4n2zFprKPq0yuEQ8kX+PzJQeDHrThdUz/
+hW/XY5tzHg+32Gx6qXXvTyyUAyWH3cjFO7GjPLoIoqRy1bh6x7BYVgDOocANjyUC
+Ikh/60JKPoaNoYuMpe6kqpLQhndfwAPXCRlj+HG4ENqQfimCtc6qf7mOv7CGlqG4
+376/NBJggqzcFm3lz2a0//oa9jT7QztBwGVx378MUK7xUnHcyqZdfg4WrDVaXx1e
+W1IAA/Roc0Bm3d47j9WAzWdyizb07rKt31a4+6L3qD5wmFF+oK9lEGBOtjAP06LB
+8TzrrThbpQwIQlmxx5dmuacpI0lBVQ63mYJlAM2mjcK07Uatp0gzHqkSRCjjTzNU
+jVapk/MSEiQmJ9qahwtnjqOjK5WnrMRnVLNRncuSircTifBLAUQ=
+=V17+
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20241208.txt b/meeting-logs/20241208.txt
new file mode 100644
index 0000000..2550e2b
--- /dev/null
+++ b/meeting-logs/20241208.txt
@@ -0,0 +1,313 @@
+[00:00:00] - {Tageswechsel: Sonntag, 8. Dezember 2024}
+[20:00:01] <sam_> !proj council
+[20:00:01] <willikins> sam_: (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm
+[20:00:05] <sam_> meeting time!
+[20:00:06] <sam_> agenda: https://public-inbox.gentoo.org/gentoo-project/87seqyvj02.fsf@gentoo.org/
+[20:00:12] <sam_> 1. roll call
+[20:00:15] -*- arthurzam here
+[20:00:16] <robbat2> present
+[20:00:16] -*- sam_ here
+[20:00:17] -*- mgorny here
+[20:00:20] -*- soap here
+[20:00:31] -*- dilfridge here
+[20:00:35] -*- ulm here
+[20:00:40] <sam_> \o/
+[20:00:55] <sam_> 2. (Further) pre-approval of EAPI 9 features [1][2]
+[20:00:57] <sam_> [1] https://public-inbox.gentoo.org/gentoo-project/ua5djagbz@gentoo.org/
+[20:00:58] <sam_> [2] https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_9_tentative_features
+[20:01:06] <sam_> ulm: over to you
+[20:01:31] <ulm> it's three changes
+[20:01:52] <ulm> the first is not to mangle symlink targets
+[20:02:14] <mgorny> bug 934514
+[20:02:15] <willikins> mgorny: https://bugs.gentoo.org/934514 "[Future EAPI] Drop rewriting of absolute symbolic links (section 13.4)"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms
+[20:02:16] <ulm> Portage currently drops any ${D} from them when merging, which is broken
+[20:02:30] <ulm> right, the bug has all the rationale :)
+[20:03:09] <mgorny> i think we recommended using relative symlinks anyway
+[20:03:13] <arthurzam> ulm: Do we know the impact of this? Is this common issue, or very rare?
+[20:03:16] <mgorny> esp. with dosym -r
+[20:03:19] <sam_> to me, it's obviously fine, and if anything, rewriting would need to be handled differently anyway (not just for symlinks, and ideally just as a QA warning on any references to the image dir)
+[20:03:23] <sam_> i think it's surprising we did it at all
+[20:03:25] <sam_> but yeah
+[20:03:43] <ulm> arthurzam: I haven't seen any warnings about it, and portage should emit them now
+[20:03:52] <arthurzam> ulm: good enough for me :)
+[20:03:53] <ulm> so I'd say rewriting is rare
+[20:04:08] <ulm> and it's broken for binpkgs
+[20:04:09] <mgorny> and since EAPI 9 is clean slate...
+[20:04:10] <arthurzam> Will need to somehow understand where and if pkgcore does it
+[20:04:11] <robbat2> is tinderbox checking for them?
+[20:04:39] <ulm> I don't know, but I'll ask toralf to add it
+[20:04:42] <arthurzam> mgorny: of course, I just wanted to know if this is a big speed-bump for EAPI=9 migration, or just a rare annoyance
+[20:04:56] <arthurzam> Got answered :)
+[20:06:13] <arthurzam> Should we vote for that?
+[20:06:14] <robbat2> seems likely very rare
+[20:06:16] <ulm> so, should we approve every item separately, or all in one go?
+[20:06:36] <sam_> I think individually
+[20:06:39] <robbat2> seperately is likely less decisive
+[20:06:52] <robbat2> *divisive
+[20:07:36] <ulm> the precise spec is here: https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-9&id=a331bd4241cecfe6b124408f345979f126d519e7
+[20:08:20] <sam_> ok
+[20:08:32] <sam_> 2a: Pre-approve the EAPI 9 feature "No longer rewrite absolute symlinks (bug #934514)"
+[20:08:32] <willikins> sam_: https://bugs.gentoo.org/934514 "[Future EAPI] Drop rewriting of absolute symbolic links (section 13.4)"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms
+[20:08:35] -*- sam_ yes
+[20:08:39] -*- arthurzam yes
+[20:08:40] -*- mgorny yes
+[20:08:46] -*- dilfridge yes
+[20:08:58] -*- soap yes
+[20:09:03] -*- ulm yes
+[20:09:25] <robbat2> yes
+[20:09:30] <sam_> excellent
+[20:09:33] <sam_> motion passes
+[20:09:47] <sam_> 2b: New pipestatus command (bug #566342#c37) (not voting yet)
+[20:09:47] <willikins> sam_: https://bugs.gentoo.org/566342#c37 "[Future EAPI] Ban or rename assert"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms
+[20:09:55] <sam_> and then:
+[20:09:59] <sam_> 2c: * Ban assert (only if we accept pipestatus, bug #566342) (not voting yet)
+[20:09:59] <willikins> sam_: https://bugs.gentoo.org/566342 "[Future EAPI] Ban or rename assert"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms
+[20:10:03] <ulm> bug 566342
+[20:10:03] <willikins> ulm: https://bugs.gentoo.org/566342 "[Future EAPI] Ban or rename assert"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms
+[20:10:05] <sam_> this has prompted quite a lot of discussion
+[20:10:17] <ulm> and exact spec is here: https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-9&id=286f95a9661bff8086450fe06d4fee3a45053a8c
+[20:10:47] <sam_> we have a proposed eclass, eapi9-pipestatus.eclass, to preview and battletest the feature: https://public-inbox.gentoo.org/gentoo-dev/u4j3wrf90@urania.mail-host-address-is-not-set/T/#u
+[20:10:54] <ulm> not everybody is happy, but I think it's the best compromise as it is
+[20:11:13] <arthurzam> ulm: let's say we want to add a new flag to this command - can we do it in EAPI=9 or would we need to wait for =10?
+[20:11:14] <ulm> (sorry about the bad message-id :)
+[20:11:26] <mgorny> i think it's good enough to pre-approve as-is
+[20:11:30] <sam_> hehe
+[20:11:45] <mgorny> we can always revisit after the initial testing
+[20:11:48] <ulm> arthurzam: we can still change it as long as EAPI 9 isn't finally approved
+[20:12:01] <mgorny> adding commands shouldn't break existing consumes
+[20:12:05] <sam_> personally I'm inclined to say yes on 2b, no on 2c for now (depending on how the eclass adoption and real-life testing goes)
+[20:12:23] <sam_> then we revisit 2c (and the rest if needed, of course) depending on that feedback
+[20:12:31] <sam_> adding as mgorny says is easy, removing not so much :)
+[20:12:35] <arthurzam> ulm: ok, I see. For now it seems like aggreeable base, but I suspect some more features will be wanted, so let's be flexible for additions until SPEC is done
+[20:12:59] <ulm> I'd strongly prefer having 2c in 9
+[20:13:03] <robbat2> IMO: yes on pipestatus; introduce new assert-like helper; mark "assert" deprecated for EAPI9 and ban in EAPI10
+[20:13:04] <ulm> let's not repeat the mistake from epatch/eapply
+[20:13:10] <dilfridge> let's just vote
+[20:13:24] <ulm> why not ban immediately?
+[20:13:43] <arthurzam> Umm, is there a usage of "assert" we might want?
+[20:13:46] <sam_> yes, I suppose tat's fine as long we can undo it
+[20:13:48] <mgorny> even the simplest form of pipestatus defeats the purpose of assert
+[20:13:50] <sam_> *that's
+[20:13:55] <sam_> 2b: Pre-approve the EAPI 9 feature "New pipestatus command (bug #566342#c37)"
+[20:13:55] <willikins> sam_: https://bugs.gentoo.org/566342#c37 "[Future EAPI] Ban or rename assert"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms
+[20:13:57] -*- sam_ yes
+[20:13:59] <ulm> there's really no need for a transition time there
+[20:14:02] -*- mgorny yes
+[20:14:10] -*- robbat2 yes to pipestatus
+[20:14:25] -*- arthurzam yes (pipestatus)
+[20:14:27] -*- ulm yes
+[20:14:30] -*- soap yes
+[20:14:34] <sam_> the motion is entirely about pipestatus, you need not specify :)
+[20:14:41] -*- dilfridge yes
+[20:14:51] <arthurzam> sam_: (the bugno says otherwise)
+[20:14:57] <sam_> the motion is what matters
+[20:15:23] <sam_> ok
+[20:15:53] <sam_> 2c. Pre-approve the EAPI 9 feature "Ban assert (bug #566342)"
+[20:15:54] <willikins> sam_: https://bugs.gentoo.org/566342 "[Future EAPI] Ban or rename assert"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms
+[20:16:18] -*- dilfridge yes
+[20:16:19] -*- sam_ yes (of course we can revisit based on how eclass adoption goes; assert adoption is already pretty poor as discussed in the bug)
+[20:16:24] <mgorny> assert is literally 'pipestatus || die'
+[20:16:26] -*- mgorny yes
+[20:16:28] -*- ulm yes
+[20:16:47] -*- robbat2 yes to rename or deprecate; no to ban
+[20:16:51] -*- soap yes
+[20:16:58] <sam_> robbat2: the motion is "ban", so your vote is no
+[20:17:10] -*- arthurzam yes
+[20:17:29] <sam_> ok, all done
+[20:17:41] <sam_> ulm: do you have anything else to say on it, or shall I move on?
+[20:17:52] <ulm> thank you!
+[20:17:56] <arthurzam> sam_: don't you need to summarise the vote count?
+[20:18:04] <arthurzam> (here in logs?)
+[20:18:13] <sam_> please let me chair if I'm chairing, it's already going to be in the summary we all review, but..
+[20:18:21] <sam_> yes, it passed unanimously
+[20:18:29] <ulm> 2c didn't?
+[20:18:39] <sam_> 2b didn't but it doesn't matter, I'll summarise that in the.. summary
+[20:18:51] <sam_> that's what we always do and vote counts aren't always clear in the log anyway
+[20:19:11] <sam_> i'd ask that you generally let the chair do their role and if we want to discuss what the chair should do, we should do that separately
+[20:19:27] <arthurzam> ok, after meeting
+[20:19:31] <arthurzam> sorry
+[20:19:31] <sam_> thanks
+[20:19:35] <ulm> sam_: ok, do your count later :) all motions passed
+[20:20:10] <sam_> 3. Social media links on website footer [3] (whether or not we remain on X is a separate topic, #4, so please don't consider that for now)
+[20:20:12] <sam_> [3] https://public-inbox.gentoo.org/gentoo-project/uzflj8yd3@gentoo.org/
+[20:20:31] <sam_> we currently link to twitter (x) and facebook
+[20:20:53] <sam_> the question is if we should keep linking to twitter/x (supposing we stay on it for the purposes of #3, please), facebook, or add/remove other sites
+[20:20:53] <ulm> xtsmpfkat :)
+[20:21:21] <arthurzam> I've concerned a little on the topic of technical, the icons. I'll want to see it solved, because I've some issues doing it
+[20:21:41] <arthurzam> When I tried to use "Font Awesome 5" it failed
+[20:21:42] <robbat2> arthurzam: to be clear, the icons or other technical concerns?
+[20:21:44] <dilfridge> that's yet another separate issue
+[20:22:02] <ulm> arthurzam: I think we can use "FA 5 Brands" together with FA 4
+[20:22:02] <dilfridge> please keep on track
+[20:22:05] <sam_> I suggest we keep twitter/x, but we add mastodon too, and we keep facebook (any other sites to add?)
+[20:22:10] <dilfridge> linkedin
+[20:22:20] <ulm> but let's discuss the technical details later
+[20:22:47] <sam_> linkedin feels really quite niche for something like us but i don't use it
+[20:22:50] <robbat2> the PR team should have good practices [e.g. no SPOF, planned posts, reviews] for any service we decide to list here; is that the case for all of the sites?
+[20:22:51] <dilfridge> the overall response on linkedin is quite positive
+[20:22:52] <arthurzam> I think facebook, mastodon, linkedin. Do we want reddit?
+[20:22:54] <sam_> is anyone ever looking for e.g. debian's linkedin?
+[20:22:58] <sam_> oh, really?
+[20:23:21] <robbat2> linkedin I agree with dilfridge, because I think we need the representation to "business"
+[20:23:21] <sam_> arthurzam: yeah, reddit might be a good shout
+[20:23:46] <robbat2> a few years ago I wouldn't have agreed, but linkedin is used a lot more as a social blog post now
+[20:24:05] <dilfridge> business-oriented social network with hiring/job ad functionality
+[20:24:21] <dilfridge> heck, even our research programs now want to be on linkedin because publicity
+[20:24:33] <mgorny> do we want to vote on them separately?
+[20:24:53] <sam_> it's more of a consensus issue IMO and not worth it (really not something to vote on at all I think)
+[20:25:10] <ulm> I'd be in favour of Mastodon + Facebook, no Twitter, indifferent about Linkedin
+[20:25:13] <arthurzam> We want them to be maintained socials! Do all our lists match this criteria?
+[20:25:19] <dilfridge> FB, mastodon, LinkedIn, X (if maintained)
+[20:25:25] <sam_> dilfridge has said a few times that nobody really wants to run FB
+[20:25:28] <sam_> i htink
+[20:25:34] <dilfridge> well, I do it now again
+[20:25:51] <dilfridge> that plus linkedin
+[20:26:06] <sam_> then dilfridge's list is fine with me, I'd like to see reddit on there _but_ the subreddit often has dubious advice on it
+[20:26:06] <robbat2> is comment moderation the problem on these?
+[20:26:10] <mgorny> i think we should add mastodon
+[20:26:19] <mgorny> as for the others, i don't care / consider them negative
+[20:26:22] <robbat2> re the "nobody really wants to run FB"
+[20:26:33] <dilfridge> no, I havent seen a single one yet I'd have to moderate
+[20:26:57] <dilfridge> what I dont want to run anymore is X / the network formerly known as twitter
+[20:27:11] <arthurzam> (this is next topic)
+[20:27:14] <dilfridge> but maffblaster and mpagano were both interested in doing it
+[20:27:16] <mgorny> in the end, i don't really see what we gain exactly by linking to these networks
+[20:27:18] <sam_> that's fine, we have a volunteer for that, but that's the next topic
+[20:27:27] <sam_> mgorny: mostly letting people follow us and find out news
+[20:27:37] <dilfridge> that
+[20:27:44] <sam_> especially for event time
+[20:27:50] <sam_> ok
+[20:27:53] <mgorny> which reminds me
+[20:28:00] <mgorny> we really should have a visible RSS/ATOM feed
+[20:28:04] <sam_> FB, mastodon, LinkedIn, X (if maintained) (and let's leave reddit for now given its quality is a bit mixed IMO)
+[20:28:09] <sam_> anyone object to that?
+[20:28:15] -*- dilfridge fine with that
+[20:28:19] <mgorny> sam_: add RSS/ATOM xP
+[20:28:23] <ulm> let's drop X please
+[20:28:24] <mgorny> it's good a cool icon too
+[20:28:27] -*- arthurzam is fine (hopes no vote on the order of them)
+[20:28:33] <dilfridge> ulm: next thing
+[20:28:33] <robbat2> https://www.gentoo.org/feeds/news.xml has been there the entire time
+[20:28:49] <arthurzam> robbat2: maybe we just need to add icon + link to it
+[20:29:06] <sam_> right
+[20:29:12] <sam_> i think this is settled and the remaining stuff is tangential
+[20:29:19] <sam_> 4. Handling of Twitter / X account [4]
+[20:29:22] <sam_> [4] https://public-inbox.gentoo.org/gentoo-project/13936474.dW097sEU6C@noumea/
+[20:29:35] <sam_> my position on this is really that if someone we trust is happy to run the account, it's no bother to me
+[20:29:45] <sam_> mpagano has kindly volunteered
+[20:29:52] <sam_> dilfridge mentioned maffblaster may be willing too
+[20:30:03] <robbat2> no SPOF; clear password handling policies for future turnover; then happy to let it continue running
+[20:30:06] <dilfridge> my personal position is that we should leave X for good, same as many others
+[20:30:08] <sam_> nobody is making individual devs use it
+[20:30:27] <arthurzam> dilfridge: umm, why? How is that different from facebook or matsodon?
+[20:30:45] <sam_> dilfridge: personally i'd rather us stay out of any sort of political judgement on it, and it's up to whether someone wants to run it or not. anything else is going to involve offending someone or making a (silly) "gentoo judgement"
+[20:30:57] <sam_> making an official declaration of leaving looks embarrassing
+[20:31:01] <sam_> (and dramatic)
+[20:31:13] <robbat2> my concern is: say we *stop* using it; mark the account as frozen; then we risk X saying "inactive accounts can be shut down"
+[20:31:26] <robbat2> and the handle ends up in somebody else's control
+[20:31:29] <sam_> yes that's a good point, kind of like freenode did at one point during that debacle
+[20:31:38] <ulm> robbat2: they can shut down any account, active or not?
+[20:31:48] <robbat2> X *have* done that to inactive accounts in the past
+[20:31:53] <dilfridge> shrug, yes... just be aware that the point of moderation is more critical there...
+[20:31:58] <dilfridge> anyway I dont care so much
+[20:32:27] <robbat2> for all of these, if we do not have staffing to moderate responses, we should turn off commenting/responses
+[20:32:42] <robbat2> and use them as broadcast mediums primarily
+[20:33:05] <mgorny> wasn't the point rather to remove the account altogether?
+[20:33:15] <dilfridge> that would have been my suggestion
+[20:33:22] <dilfridge> (not parking it)
+[20:33:24] <ulm> freezing is also fine
+[20:33:38] <arthurzam> But we have volunteers for it? Why freeze/delete it?
+[20:33:41] <sam_> exactly
+[20:33:44] <robbat2> remove/freeze both end up with somebody else potentially in control of the name
+[20:33:52] <robbat2> which is what I want to avoid
+[20:34:05] <mgorny> that can happen without us doing anything either
+[20:34:05] <sam_> for me, given what arthurzam said, it's not a matter for us
+[20:34:12] <mgorny> it's enough i say publicly how much i hate nazis
+[20:34:33] <arthurzam> mgorny: but they are everywhere? Not in only specific social?
+[20:34:33] <ulm> oh my. Godwin's law?
+[20:34:33] -*- mgorny wait for whole Gentoo to be banned now
+[20:34:39] <sam_> oh dear
+[20:34:41] <robbat2> convert them to broadcast mediums, wire up automation to news posts, done
+[20:34:59] <dilfridge> arthurzam: X is nowadays the bad end
+[20:35:18] <robbat2> nope, that's TruthSocial or whatever they renamed to
+[20:35:27] <sam_> mpagano: not sure if you're around but feel free to speak if you are
+[20:35:31] <dilfridge> that's not relevant outside of Ameristan
+[20:35:32] <arthurzam> but by staying there, Gentoo can be the light in the darkness
+[20:35:46] <mpagano> Happy to maintain twitter, but Robbat2's idea is pretty good
+[20:35:47] <arthurzam> Also, here it is just a normal social network
+[20:35:49] <mpagano> I mean X
+[20:36:10] <mpagano> The idea is to reach people to further our goals in Gentoo
+[20:36:13] <sam_> yes
+[20:36:21] <sam_> wherever they might be, and keep them posted on developments
+[20:36:22] <mpagano> and with 900MM users, that's good visibility
+[20:36:46] <mgorny> arthurzam: or be another organization that brings more users and therefore profit to nazis
+[20:36:50] <mpagano> Agism aside, I don't like FB, but we should eb on there also
+[20:36:53] <mgorny> i wouldn't have started using twitter in the first place if not for gentoo
+[20:37:09] <mgorny> the blade has two sides
+[20:37:20] <sam_> ok, clearly do need to vote on it
+[20:37:35] <sam_> motion: remain on X (given we have 1, possibly 2, volunteers)
+[20:37:36] -*- sam_ yes
+[20:37:53] -*- arthurzam yes
+[20:37:57] -*- mgorny no
+[20:38:00] -*- dilfridge abstain
+[20:38:04] -*- soap yes
+[20:38:27] -*- robbat2 yes
+[20:38:30] -*- ulm no
+[20:38:33] <sam_> hh
+[20:38:43] <sam_> 4 yes, 2 no, 1 abstention
+[20:38:46] <sam_> motion passes
+[20:38:58] <sam_>
+[20:38:59] <sam_> 5. Open bugs with Council participation [5]
+[20:39:01] <sam_> [5] https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation
+[20:39:10] <sam_> [5] https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation
+[20:39:12] <sam_> oops
+[20:39:14] <sam_> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=7321875&query_format=advanced
+[20:39:20] <sam_> * bug 925014 (heh)
+[20:39:20] <willikins> sam_: https://bugs.gentoo.org/925014 "PR services lacking developer redundancy"; Community Relations, User Relations; CONF; ajak:pr
+[20:39:21] <dilfridge> mpagano: would be great if you could forward frontpage posts if/when they happen, thank you!!!
+[20:39:35] <sam_> I think we agreed to drop ourselves from that and it's sort of hard to do anything there
+[20:39:59] <arthurzam> sam_: just to make sure, did X/twitter creds also pass into the secrets vault?
+[20:40:18] <robbat2> as the council, should we set better policies on how to handle these? my comment earlier that non-SPOF moderation team or broadcast-only mode
+[20:41:08] <dilfridge> robbat2: mostly it's probably enough if people talk to each other
+[20:41:30] <dilfridge> (realistically, I've done all frontpage posts of the last >3 years I think)
+[20:42:04] <dilfridge> something like hootsuite would be great, but costs and social contract ...
+[20:43:39] <dilfridge> https://en.wikipedia.org/wiki/List_of_social_platforms_with_at_least_100_million_active_users
+[20:44:12] <sam_> arthurzam: i don't think so
+[20:44:25] <ulm> dilfridge: skype? :)
+[20:44:28] <arthurzam> sam_: so maybe add it as requirement xD
+[20:44:32] <dilfridge> I have these, so easy
+[20:44:38] <arthurzam> dilfridge: ah, thanks
+[20:45:11] <sam_> ok
+[20:45:26] <robbat2> so remove council from this bug then?
+[20:45:30] <sam_> yeah
+[20:45:40] <sam_> * bug 936211
+[20:45:41] <willikins> sam_: https://bugs.gentoo.org/936211 "[Tracker] Gentoo Foundation dissolution"; Gentoo Foundation, Proposals; CONF; ulm:trustees
+[20:45:47] <sam_> not sure if there's any news here
+[20:45:55] <sam_> I saw robin I think had progress with the paypal bits?
+[20:47:10] <robbat2> i really should have split every item in bug 936233 to seperate tasks
+[20:47:33] <robbat2> DONE - Move one-time donations to SPI accounts
+[20:47:48] <robbat2> DONE - Move (new) recurring donations to SPI accounts
+[20:48:11] <robbat2> existing recurring donations are not moved; we need to reach out to the donors
+[20:48:17] <robbat2> which I was planning to do this month
+[20:48:32] <robbat2> with the carrot that they get tax credits via SPI starting in January
+[20:48:41] <ulm> the bug could still be split
+[20:48:45] <dilfridge> \o/
+[20:49:06] <robbat2> also reminds me I think the CPA owes us a confirming they filed the taxes
+[20:50:13] <sam_> ok
+[20:50:17] <sam_> all alright otherwise for now?
+[20:50:33] <sam_> 6. Open floor
+[20:51:07] <arthurzam> https://wiki.gentoo.org/wiki/Project:Council/Meeting_logs is quite empty :(
+[20:51:21] <dilfridge> sorry my fault, gets better soon
+[20:51:58] <soap> I have done mine :D
+[20:52:04] <ulm> May and June missing too, who was chairing these?
+[20:52:13] <arthurzam> I think dilfridge
+[20:52:22] <dilfridge> think so
+[20:52:41] <dilfridge> holidays are coming
+[20:54:07] <sam_> ok
+[20:54:09] -*- sam_ bangs gavel
+[20:54:11] <sam_> thank you all
+[20:54:21] * ulm has changed topic for #gentoo-council to: "257th meeting: 2025-01-12 19:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250112T19 | https://wiki.gentoo.org/wiki/Project:Council | https://dev.gentoo.org/~dilfridge/decisions.pdf"
+[20:54:22] <arthurzam> sam_: thank you for chairing
+[20:54:22] <arthurzam> Thank you everyone
+[20:54:23] <dilfridge> thanks sam_
+[20:54:28] <ulm> thanks
diff --git a/meeting-logs/20241208.txt.asc b/meeting-logs/20241208.txt.asc
new file mode 100644
index 0000000..b625be3
--- /dev/null
+++ b/meeting-logs/20241208.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmeVQr9fFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE
+MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V
+QSp9LQ/8CHLXTAAXuT+xpNJcLb29dV1ra/nxKoKNFvSWIjkH46HGwslzRiOVQjKq
+XXzW1dqqN0qtr4OBbyIOvGgXxUFF7x2aBK7dpsmSLf1Y9OKu4MKGUE3/Z4t6BaGj
+RxzgRrO2aHEvgpUQXSDt0NT2ROZl815r2pi3B44fNNpevWa2yR1QBF1qAvoKBhvw
+zyO2WhhKuudpDTqTXByHY7GIxUFskSPvgRrW+3mAjSlxSxYSImPhBuJKkVz9d6AE
+/oiuUSfnvPCY+VIBVr8VallXju7JKIKWoyJ90X+Ej0BMTZBaXKGFR8yP6L8h8Gx6
+UKGrRvFd+dEmxdYA6395GHyB56mNLOASXUO2A5Fy31MScDnJhNuD6oPWhrG80cu/
+Yn0MRPRyqrmz8EhM2jLsdDq2AkpLZnThs4o14AWk5d0Hg8uK6j4+TsXDyhwzmH7p
+0ljGoI9Vm5BINDeKC6xk68/htgwP+y44ECeAuUUEQ1nNIvJ9V6SNwaEYNNzahTYU
+cYU82ybdmkmweo2Hsvf8LmmDhIYxQoRNleDOTEOcji+7sbQczwEANv8IKYgW8A04
+zYuTRXwiMRltVe4Uz9K6pxdKqZFe5e7ocfMFDeARGeH5VkpSNiS5fPqBYMxo23Wo
+7zgs5SNn9zcZbwU2l/hB0NGYNYKc8lXV0UJo57d5j9QeXG1DtDs=
+=d0i7
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20250112.txt b/meeting-logs/20250112.txt
new file mode 100644
index 0000000..ff71050
--- /dev/null
+++ b/meeting-logs/20250112.txt
@@ -0,0 +1,175 @@
+[00:00:00] - {Tageswechsel: Sonntag, 12. Januar 2025}
+[20:00:05] <sam_> !proj council
+[20:00:05] <willikins> sam_: (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm
+[20:00:08] <sam_> Agenda: https://public-inbox.gentoo.org/gentoo-project/87a5bvzx8m.fsf@gentoo.org/T/#u
+[20:00:12] <sam_> 1. Roll call
+[20:00:13] -*- sam_ here
+[20:00:16] -*- soap here
+[20:00:17] -*- mgorny here
+[20:00:18] -*- ulm here
+[20:01:17] -*- dilfridge here
+[20:01:39] <sam_> arthurzam: robbat2:
+[20:03:18] <sam_> will wait until 5 past
+[20:03:54] <robbat2> present
+[20:04:00] <robbat2> sorry, kid IRQs
+[20:05:03] <sam_> ok
+[20:05:16] <sam_> 2. (Further) pre-approval of EAPI 9 features [0]
+[20:05:19] <sam_> 2a. * Do not export PMS variables (bug #721088) [1]
+[20:05:19] <willikins> sam_: https://bugs.gentoo.org/721088 "[Future EAPI] Do not export PMS variables"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms
+[20:05:22] <sam_> [0] https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_9_tentative_features
+[20:05:24] <sam_> [1] https://public-inbox.gentoo.org/gentoo-project/87036fbf-6bd4-4577-bbd2-a11c9bc1dc1e@gentoo.org/
+[20:05:31] <sam_> ulm: flow: ^
+[20:05:37] <ulm> text of the spec is here: https://public-inbox.gentoo.org/gentoo-pms/20250110184912.16006-1-ulm@gentoo.org/T/#u
+[20:06:13] <ulm> the idea is not to export most of the PM-defined variables
+[20:06:35] <ulm> the the rationale that A has become very large in some cases
+[20:06:39] <ulm> *with the
+[20:06:57] <dilfridge> we went from A to AAAAA
+[20:07:02] <mgorny> the idea itself is sound, the rationale not really
+[20:07:03] <ulm> and other vars like P may influence upstream build systems
+[20:07:12] <mgorny> that's what i wanted to say
+[20:07:24] <sam_> yeah, I personally find the "other-vars cause issues" argument then "consistency" on top more persuasive
+[20:07:34] <ulm> so we'd not export any of them except TMPDIR and HOME
+[20:07:36] <soap> I've had to deal with $P breaking makefiles
+[20:07:52] <sam_> P has broken gcc several times in the last few years even
+[20:07:52] <dilfridge> just to clarify, within ebuilds and eclasses directly nothing changes?
+[20:08:01] <mgorny> this will also cover USE_EXPAND vars like ARCH?
+[20:08:07] <sam_> it's also usually not obvious at all when it is happening
+[20:08:07] <ulm> nope
+[20:08:14] <sam_> even worse for novices writing ebuilds
+[20:08:19] <sam_> so I see this as a nice footgun removal too
+[20:08:22] <ulm> what's defined in profiles will still be exported
+[20:08:33] <sam_> (reducing "uh, works manually, fails in ebuild")
+[20:08:47] <mgorny> well, let's extend it to USE_EXPAND vars then explicitly, but that could be done separately
+[20:08:51] <sam_> the only reason not to do this is tools *we've* written relying on these variables, like eselect calls
+[20:08:52] <mgorny> ARCH definitely breaks stuff
+[20:09:05] <sam_> ulm had an idea of having pkgcheck look for the eselect case
+[20:09:17] <sam_> (mainly for ROOT)
+[20:09:33] <ulm> the eselect cases are trivial to catch
+[20:09:45] <robbat2> to double-check - if a tool does need a non-exported variable, all the ebuild author has to do is an extra "export VARNAME" in the ebuild?
+[20:10:22] <ulm> "export VARNAME" or "local -Ix VARNAME" (assuming we switch to bash-5.2)
+[20:10:49] <ulm> local has the advantage that it's ... local :)
+[20:11:03] <arthurzam> I'm here. Power outage
+[20:11:27] <mgorny> ulm: wait, bash now allows you to actually make things exported locally now?
+[20:11:43] <sam_> punt that to the next topic please ;)
+[20:11:47] <sam_> naughty ulm!
+[20:11:56] <ulm> mgorny: yes
+[20:12:34] <ulm> mgorny: but don't use -I in EAPI 8 :)
+[20:12:44] <robbat2> i'm slightly worried about finding subtle breakage; e.g. where we were implicitly exporting CFLAGS before; and it built correctly, and then stops
+[20:12:59] <sam_> CFLAGS isn't going to change
+[20:13:02] <ulm> CFLAGS isn't affected
+[20:13:07] <sam_> it's about PMS-defined variables we were always leaking to the environment
+[20:13:07] <arthurzam> Do we have an idea for a env var that might be wanted to be manually exported in many places?
+[20:13:48] <sam_> ROOT is the only one I can think of at the moment, also HOME and TMPDIR but those have exceptions in this
+[20:13:52] <robbat2> maybe the doc would be improved with a clear list there: "list of PMS-defined variables that will/will-not be exported"
+[20:14:17] <ulm> robbat2: it's the ones in this table: https://projects.gentoo.org/pms/8/pms.html#x1-109001r1
+[20:14:19] <dilfridge> the list looks pretty harmless to me
+[20:14:35] <ulm> except TMPDIR and HOME
+[20:14:38] <arthurzam> Umm, SYSROOT maybe?
+[20:14:40] <sam_> yeah, it's maybe clearer in the Portage patch Flow has written (https://github.com/gentoo/portage/pull/1407)
+[20:14:41] <robbat2> would you accept adding an adding a exported column?
+[20:15:07] <ulm> robbat2: no :)
+[20:15:26] <arthurzam> OK, went over Flow's patch, list looks ok for me :)
+[20:15:27] <sam_> arthurzam: we might have to export EPREFIX in some rare cases, and maybe (E)SYSROOT for the benefit of some crossdev hacks we have
+[20:15:28] <ulm> the table is already too wide as it is
+[20:15:34] <sam_> but I'm not worried about it
+[20:15:43] <arthurzam> sam_: ack :)
+[20:16:04] <ulm> I see it as a good thing if these exports must be explicit
+[20:16:20] <sam_> yes - I think it's going to reduce hard-to-debug breakage, and then makes environment smaller as a bonus
+[20:16:34] <sam_> shall we proceed to vote?
+[20:16:53] <arthurzam> sounds good
+[20:17:05] <sam_> Motion: pre-approve "Do not export PMS variables" for EAPI 9
+[20:17:06] <robbat2> no further questions from me
+[20:17:07] -*- sam_ yes
+[20:17:11] -*- arthurzam yes
+[20:17:13] -*- mgorny yes
+[20:17:13] -*- dilfridge yes
+[20:17:23] -*- robbat2 aye
+[20:17:31] <soap> .me yes
+[20:17:33] -*- soap yes
+[20:17:34] -*- ulm yes
+[20:17:50] <sam_> motion passes (7 yes, 0 no, 0 abstentions)
+[20:17:58] <ulm> good :)
+[20:18:16] <sam_> 2b. Update Bash version to 5.2 (bug #946193) [2]
+[20:18:17] <willikins> sam_: https://bugs.gentoo.org/946193 "[Future EAPI] Update Bash version to 5.2"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms
+[20:18:20] <sam_> [2] https://public-inbox.gentoo.org/gentoo-project/ua5byebc7@gentoo.org/
+[20:18:58] <arthurzam> If we approve this, and bash 5.3 is considered stable in future, and EAPI=9 isn't yet out, would we be able to update from 5.2 baseline to 5.3?
+[20:19:05] <ulm> sure
+[20:19:30] <arthurzam> Is there potential cons against the upgrade then?
+[20:19:33] <sam_> for me we'd need a strong reason not to approve this, because Chet has been very clear that he doesn't care for BASH_COMPAT at all
+[20:19:37] <ulm> it's mainly that we don't fall to far behind
+[20:19:43] <sam_> and we've had various issues with it not actually working
+[20:19:52] <sam_> so there isn't really a choice
+[20:20:07] <ulm> I've listed some incompatibilities in bug 946193
+[20:20:07] <willikins> https://bugs.gentoo.org/946193 "[Future EAPI] Update Bash version to 5.2"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms
+[20:20:14] <ulm> not sure if that's all
+[20:20:26] <sam_> Kerin had tried reporting various issues w/ 5.2 with BASH_COMPAT as 5.1 and they all got WONTFIX'd
+[20:20:39] <ulm> the main issue is that devs will start using 5.2 features anyway
+[20:20:47] <sam_> yeah, that too
+[20:20:52] <robbat2> re bash 5.3: if upstream released a stable 5.3.0 today, that's 6? months until we can rely on it for stable ebuilds assuming EAPI=9 requires bash5.3?
+[20:21:24] <ulm> yeah, we've been very conservative about it in the past
+[20:21:40] <sam_> we've been very conservative with *that* part, and then not conservative enough with the rest
+[20:21:54] <sam_> (PM support vs use in tree)
+[20:22:00] <arthurzam> ulm: is there a reason to be conservative, and use 6 month and not the standard 30 days?
+[20:22:14] <ulm> portage would depend on bash-5.3, I guess
+[20:22:35] <ulm> so in principle it's usable as soon as 5.3 is stable
+[20:22:41] <arthurzam> (maybe out of scope current motion, so maybe better postpone discussion on changing bash wait period to open floor)
+[20:22:55] <sam_> yeah
+[20:23:02] <ulm> 5.2 should be safe by now
+[20:23:08] <arthurzam> agree
+[20:23:20] <sam_> ok
+[20:23:27] <sam_> Motion: Pre-approve "Update Bash version to 5.2" for EAPI 9
+[20:23:30] -*- sam_ yes
+[20:23:30] -*- arthurzam yes
+[20:23:34] -*- robbat2 aye
+[20:23:43] -*- mgorny yes
+[20:23:44] -*- dilfridge aiaiaia... yes
+[20:23:47] -*- soap yes
+[20:23:48] -*- ulm yes
+[20:24:24] <sam_> motion passes (7 yes, 0 no, 0 abstentions)
+[20:24:39] <sam_> 3. Open bugs with Council participation [3]
+[20:24:42] <sam_> [3] https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation
+[20:24:50] <sam_> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=7352092&query_format=advanced
+[20:24:55] <sam_>
+[20:24:57] <sam_> bug 946351
+[20:24:57] <willikins> sam_: https://bugs.gentoo.org/946351 "Remove Open Collective organization"; Gentoo Council, unspecified; CONF; mgorny:council
+[20:25:12] <sam_> ulm did some digging into this before because there's several different "Open Collective" bodies
+[20:25:23] <sam_> I think there's an account we made a while ago that we need to deactivate
+[20:25:50] <sam_> I don't think anyone disagrees with us doing that, do they?
+[20:26:14] <arthurzam> sounds logical. Do we know who holds account's creds?
+[20:26:26] <robbat2> it's a role-based system
+[20:26:30] <robbat2> not a single account for the org
+[20:26:31] <ulm> we have an account with open collective inc. which is the platform
+[20:27:28] <ulm> whereas open collective foundation (OCF) was the fiscal host and is shutting down (or already has)
+[20:27:48] <ulm> plus there's open source collective :/
+[20:27:56] <ulm> (OSC)
+[20:28:30] <ulm> I'm all for removing us
+[20:28:47] <robbat2> the org had only submitted an application to OCF; and that application was rejected
+[20:28:57] <robbat2> from the admin panel right now, there is delete or archive
+[20:29:07] <robbat2> given that we had no data in here at all
+[20:29:29] <robbat2> i'm on the delete side, as long as the name isn't open for squatting in future, and only we can get it back
+[20:29:35] <ulm> yes, make a clean slate
+[20:29:45] <arthurzam> Yeah, delete I think is good
+[20:29:48] <robbat2> if squatting or never getting it back is a concern; then i'd vote archive
+[20:30:09] <sam_> I don't think we need to vote on this
+[20:30:13] <sam_> ok, let's move on
+[20:30:24] <sam_> bug 936211
+[20:30:25] <willikins> sam_: https://bugs.gentoo.org/936211 "[Tracker] Gentoo Foundation dissolution"; Gentoo Foundation, Proposals; CONF; ulm:trustees
+[20:30:27] <sam_> any news on this?
+[20:30:58] <robbat2> new donations (recurring & one-time) are going to SPI now
+[20:31:10] <robbat2> i'm waiting for their monthly financials due next week
+[20:31:19] <robbat2> to see if we have enough income to start switching over expenses
+[20:32:14] <sam_> ok, thanks
+[20:32:32] <sam_> 4. Open floor
+[20:32:34] <sam_> anything?
+[20:33:19] <robbat2> do we want to discuss bash5.3 more?
+[20:33:26] <ulm> let's cross that bridge when we reach it
+[20:33:42] <ulm> then we'll have more facts on it
+[20:33:45] <sam_> yeah, who knows when it will even come
+[20:33:50] <sam_> or how bad the breakage within will be
+[20:34:51] <sam_> i'm going to bang the gavel, i think
+[20:34:54] <sam_> thank you all!
+[20:34:57] -*- sam_ bangs gavel
+[20:35:01] <dilfridge> thanks!
+[20:35:04] <arthurzam> thank you
+[20:35:12] <mgorny> thanks
+[20:35:13] <soap> thank you!
diff --git a/meeting-logs/20250112.txt.asc b/meeting-logs/20250112.txt.asc
new file mode 100644
index 0000000..0aad609
--- /dev/null
+++ b/meeting-logs/20250112.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKSBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmeVQgZfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE
+MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V
+QSqRcg/4jaW1xfqrm6DoZ1rkytcoJdeYBqytFNML1Y/GqO6uP2wLSido3alkD59/
+ECesmYrCPRnM04RbtDnz9PraQFzKzqAZFI5wEMxYH0qezU49V9nasxreJR0pJU0m
+XndcC2F0oLcyG/wB8rTu5SdJMY2C5JhU9xp7ijW2S2FPCdxv5tfJfPdIaPgBDG1O
+FVcLWTo8zdOcEt7tVCfc1XcxoyDCMnlXQVWAt6LXS9HNlM0r9kIzbdXtl6fksTYR
+1uRZtIqAN2icTIem+hQ64emoEEdpUlS329e2MSrtwEirDQ7auEml5j0/Cc4B95Ih
+7iPwaBfgem9OPU2i3EN0ld1sUx9ZoKpx00WKbfixKNqLHTJZoNiR10R3K1BRyG09
+bxQA/qesxPGyeTbUQ5Egw8MrR1HvivZTLdY3Ld7JUHSv5E5EAisR4qNTFQ7ciuWW
+V17hjPBOnsxpbFC/qxY/9g6hq5VIPUsroWh2l4xv4MiAfVLAesCAUHh7zZjIsIAX
+1mq7SWjxW/XLq90oVMvPegNTXuhWQyOqWBpeb9vdephOpSAPYSvZz/41zKvSdtIM
+1hNneGuHtnk9MDSm0aHWRUYKqXT2AYJb+IBr6bRZ/uLwg3XFirmZLglEsbZeKhIP
+NfVnBbw7/ffwO8ZQx6P2LIQ2L5GnIh+UjRhN12HCw3WbANJmJQ==
+=qe7v
+-----END PGP SIGNATURE-----