path: root/meeting-logs/20240811.txt

[18:59:58] <@soap> https://marc.info/?l=gentoo-project&m=172336871401229&w=2
[19:00:16] <@arthurzam> dilfridge: soap: https://public-inbox.gentoo.org/gentoo-project/d2779e497df653744135f11f9ad5e4dd4d0f977c.camel@gentoo.org/T/#u
[19:00:46] <@dilfridge> looks exciting
[19:00:53] <@soap> ok, roll call
[19:00:57] <@robbat2> present
[19:01:01] -*- dilfridge present
[19:01:03] -*- mgorny here
[19:01:04] -*- arthurzam here
[19:01:06] -*- soap here
[19:01:07] -*- Arsen here (proxy for ulm)
[19:01:09] -*- sam_ here
[19:01:25] <@soap> ok, full council
[19:01:32] <@dilfridge> full house
[19:01:59] <@soap> 1.1 I've decided against discussing the foundation, since we'll have an AGM soon and there aren't any news on that front
[19:02:16] <@soap> 2. Open bugs with Council participation
[19:03:02] <@soap> bug 936517 should be done, I'll close it after the meeting
[19:03:03] <willikins> soap: https://bugs.gentoo.org/936517 "Social Contract update"; Gentoo Foundation, Licenses; IN_P; ulm:trustees
[19:03:09] <@dilfridge> \o/
[19:03:30] <@soap> bug 936914 should be fine too
[19:03:31] <willikins> soap: https://bugs.gentoo.org/936914 "arm64: Short-term replacement for jiji.arm.dev.gentoo.org"; Gentoo Foundation, Proposals; CONF; robbat2:trustees
[19:03:42] <@robbat2> i have some questions there
[19:03:53] <@robbat2> did we hear back from WorksOnArm, or any other big users?
[19:04:06] <@dilfridge> I didnt hear anything
[19:04:16] <@sam_> just to say: I haven't heard back from my WOA replies, I have a feeling they didn't quite realise our needs couldn't be met by cloud, but I don't know if we will hear back
[19:04:33] <@sam_> I can try reach out to 2 people I know at arm who have been very appreciative of our help with gcc
[19:04:38] <@sam_> I have not heard from other users
[19:04:46] <@robbat2> neither Gigabyte nor SuperMicro are selling anything newer than 18 months old publicly
[19:04:54] <@dilfridge> no response from the glibc people
[19:05:17] <@sam_> I was waiting on asking the arm people I knew of until we gave the glibc people a chance, in case they're all on the same team
[19:05:18] <@robbat2> lots of hype about new products coming, but nowhere to get them, or even access
[19:05:30] <@dilfridge> robbat2: the only thing that is sold publicly is the nvidia grace superchip, and that is beyond our needs and means
[19:05:35] <@soap> the story of ARM...
[19:05:40] <@sam_> yep
[19:05:50] <@sam_> so if people think I should, I can reach out to the 2 arm folk
[19:05:53] <@sam_> I don't konw if it'll go anywhere
[19:05:57] <@sam_> or I can ask in person in a month
[19:06:07] <@robbat2> you can order a Grace, but seems nobody is actually shipping it
[19:06:14] <@dilfridge> (based on 2x neoverse v2, typical server from 50k€ upwards)
[19:06:24] <@soap> we have a Grace at work, but they're finicky
[19:06:36] <@ajak> wrt contingencies: i have my arm server that i'd be happy to give to gentoo, but need somewhere to put it
[19:06:41] <@sam_> we also don't need the gpu part at all for our purposes
[19:06:46] <@ajak> soap: and loud!
[19:06:56] <@ajak> (which may or may not be a genuine concern)
[19:07:00] <@dilfridge> sam_: grace is without gpu, grace hopper is with (fun)
[19:07:09] <@sam_> ah
[19:07:13] <@robbat2> i've asked OSL about the state of our racks; there isn't enough power right now; maybe if something got cleared out
[19:07:17] <@robbat2> but that's a next month discussion now
[19:07:21] -*- ajak nods
[19:07:26] <@mgorny> btw no chance worksonarm would give us the hw if they're decommissioning it anyway?
[19:07:30] <@dilfridge> sounds reasonable
[19:07:30] <@sam_> ok, so quickly: should I email the 2 people now, or just ask in person next month?
[19:07:31] <@robbat2> ajak: where physically is your node located?
[19:07:38] <ajak> bay area
[19:08:02] <@sam_> mgorny: they've not replied to my other emails yet so..
[19:08:06] <@robbat2> mgorny: I did suggest WOA should be asked that question
[19:08:09] <@arthurzam> sam_: what are the risks of contacting them?
[19:08:27] <@sam_> arthurzam: just that maybe it'd be more successful if I ask IRL, dunno, but I get on with them well anyway
[19:08:34] <@sam_> maybe slight awkwardness if they say no? :D
[19:08:54] <+Arsen> I doubt there are any really.. but minimizing "bother" is nice
[19:09:02] <@arthurzam> ok, I see
[19:09:17] <@sam_> maybe some small increased chance of success if arsen and I are both there with the begging bowl
[19:09:18] <@sam_> no idea
[19:09:22] <+Arsen> (assuming these are the same ARM people I'm thinking of; sam?)
[19:09:25] <@sam_> yes
[19:09:28] <+Arsen> figures
[19:09:47] <@sam_> ok I'll play it by ear, I'll definitely ask, not sure when
[19:09:56] <@sam_> I'll ask in person if I haven't by then
[19:10:26] <@robbat2> thanks
[19:10:39] <@dilfridge> for the moment susuwatari (the new hetzner machine) is fully functional (thanks robbat2 and whoever else helped)
[19:11:01] <@arthurzam> dilfridge: can I start the tattoo on it?
[19:11:11] <@dilfridge> as far as I'm concerned, sure
[19:11:21] <@robbat2> i thought tattoo was already running :-)
[19:11:24] <@dilfridge> catalyst jobs and binhost builders are already running
[19:13:57] <@robbat2> anything else to discuss on the arm64 box topic?
[19:14:05] <@sam_> nothing from me
[19:14:09] <@dilfridge> nope
[19:14:13] <@arthurzam> none
[19:14:23] <@soap> ok, lets proceed
[19:14:28] <@soap> bug 801499
[19:14:28] <willikins> soap: https://bugs.gentoo.org/801499 "Approach Nitrokey for Nitrokey 3 upgrade"; Gentoo Foundation, Proposals; CONF; sam:trustees
[19:14:37] <@dilfridge> nope
[19:15:04] <@robbat2> what is our overall plan here? (one sec, writing a longer message)
[19:15:08] <+Arsen> AFAIK yubikey was proposed as an alternative - ulm said that he does not oppose, so maybe that's a direction to inquire
[19:15:09] <@soap> so yes, NK3s seem to be a real problem
[19:15:11] <@sam_> I think that bug needs an update (ulm had mentioned we'd "voted against")
[19:15:22] <@sam_> I'll let soap summarise but I have serious concerns
[19:15:41] <@soap> the final nail in the coffin is that it turns out the secret enclave is actually proprietary?
[19:15:54] <@dilfridge> yes
[19:15:54] <@soap> never mind the terrible UX and cheap built quality
[19:15:59] <@robbat2> somebody was going to ask yubikey, for sponsorship/price quotes; if that works, go with that; otherwise go to NO keys?
[19:16:06] <@soap> yes
[19:16:15] <@soap> I was going to ask, but RL
[19:16:25] <@soap> I'm on PTO next week, so have time to contact them
[19:16:40] <@robbat2> so we're accepting we have to take proprietary to get the functionality; and which point it's a price / UX / quality discussion
[19:17:02] <@soap> "proprietary", why has noone engaged with sam's argument yet
[19:17:33] <@sam_> the RYU part applies heavily here; you don't _want_ to be able to update security key hardware, and nor can you if the security key is any good
[19:17:45] <@sam_> not only that, it's unclear to me that yubikey is even non-compliant with RYU
[19:17:51] <@sam_> it's marketing nonsense
[19:17:58] <@robbat2> can you expand RYU for the logs please?
[19:18:00] <@soap> if there's a serious vuln, yubico has demonstrated that they will replace all affected hardware
[19:18:15] <@soap> (ROCA)
[19:18:17] <@sam_> RYU = Free Software Foundation (FSF)'s "Respect Your Freedom" certification
[19:18:25] <@sam_> it has rules regarding firmware which can, and cannot, be updated
[19:18:35] <@dilfridge> [then you can extract your key using the serious vuln and upload it to the new hardware :o)]
[19:18:41] <+Arsen> heh
[19:19:07] <@sam_> all that to say, I just don't agree with the characterisation of proprietary vs not, as it's misleading
[19:19:28] <@sam_> i don't consider this any sort of violation, breach, or disrespect of the social contract
[19:19:29] <@dilfridge> it's kinda silly anyway, since I'm fairly sure our ganeti machines dont run coreboot
[19:19:33] <@sam_> that too
[19:19:34] <+Arsen> IMO there's value in the open-ness but it's academic if the product is significantly worse
[19:19:35] <@soap> especially with that secret enclave BS
[19:19:56] <@sam_> if the products are ~equal but one is more open, I'd definitely prefer the more open one
[19:20:07] <@sam_> or even if it's just a small trade-off
[19:20:16] <@sam_> for the logs, wrt secret enclave: https://docs.nitrokey.com/nitrokey3/features
[19:20:29] <@sam_> the FIDO2, Password Safe, and Admin Apps are _not_ in the secure element because of this
[19:20:56] <@sam_> if nitrokey come out with a NK4 or similar where they fix the various problems, I'm all for it
[19:21:09] <@robbat2> that's going to be at least 2 years ago
[19:21:10] <@robbat2> *away
[19:21:14] <@soap> si
[19:21:24] <@sam_> aye, I jus mean I don't take us using yubikey now (if we do) as a permanent agreement or anything
[19:21:30] <@dilfridge> the announcement, the hardware more like 6 years
[19:21:31] <@robbat2> in which period, we have yubikey || NK2
[19:21:33] <@sam_> i'll happily support nitrokey if they come out with something good
[19:21:47] <@soap> dilfridge: with a cheesy python-only package for managing it
[19:22:26] <@mgorny> they should rewrite it in rust
[19:22:27] -*- mgorny hides
[19:22:30] <+Arsen> they did
[19:22:33] <@soap> mgorny: they did
[19:22:34] <@soap> haha
[19:22:34] <@robbat2> ok, let's continue with asking Yubico; in parallel, are any other SPI projects also doing similar work we can join?
[19:22:38] <@dilfridge>  /o\
[19:22:39] <+Arsen> https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-rust-common-criteria-eal-6
[19:22:45] <@sam_> good question ...
[19:22:54] <@sam_> so, I know that Alpine DOES NOT use security keys AFAIK
[19:23:04] <@soap> what a surprise
[19:23:44] <@robbat2> Arch does
[19:23:48] <@robbat2> https://www.nitrokey.com/news/2021/nitrokey-equips-arch-linux-developers-usb-keys
[19:23:53] <@soap> doesnt debian too?
[19:24:05] <@sam_> I don't know many people at Arch to ask about this
[19:24:13] <@sam_> I know one person who I could maybe ask
[19:24:15] <+Arsen> maybe eli does?
[19:24:21] <@dilfridge> let's ask eli :D
[19:24:30] <@robbat2> let's ask on the SPI discussion lists
[19:24:34] <@sam_> good idea
[19:24:38] <+Arsen> yes that seems easier
[19:24:42] <@sam_> ztrawhcse: ^ fyi
[19:25:04] <@robbat2> so action items here? soap was going to contact yubico; and ?? will ask on spi lists
[19:25:06] <@soap> robbat2: can you ask?
[19:25:13] <@robbat2> yes, I can take the spi lists
[19:25:26] <@dilfridge> robbat2 is gonna be our action figure
[19:26:36] <@soap> ok, last bug
[19:26:49] <@soap> bug 925014
[19:26:49] <willikins> soap: https://bugs.gentoo.org/925014 "PR services lacking developer redundancy"; Community Relations, User Relations; CONF; ajak:pr
[19:27:02] <@soap> not sure what's left here to do?
[19:27:17] <@arthurzam> A shared account was just created for matstodon
[19:27:27] <@dilfridge> this is like arch status, we should probably just make it into a regular agenda item
[19:27:36] <+Arsen> lol
[19:27:37] <@soap> or that, yes
[19:27:42] <+ztrawhcse> sam_: I never got one via that program. I do remember from the discussion period that it was decided to seek Nitrokey sponsorship, not yubikey sponsorship, because nitrokey was "open source, open hardware"
[19:27:48] <@sam_> bug 937585
[19:27:49] <willikins> sam_: https://bugs.gentoo.org/937585 "New alias to enable maintaining mastodon with more than one developer"; Gentoo Infrastructure, Other; RESO, FIXE; jstein:infra-bugs
[19:28:06] <@soap> ztrawhcse: open hardware, except the most important part :D
[19:28:20] <@robbat2> ztrawhcse: the nitrokey2 are still available in the program
[19:28:23] <@sam_> wrt PR: I think nothing for us to do really, the bug being done is good
[19:28:24] <+ztrawhcse> well, funny how these things turn out in the end is all I can say
[19:28:36] <@soap> ok great
[19:28:46] <@soap> let's move to the final point
[19:28:54] <@soap> 3. Open floor
[19:29:10] <@arthurzam> So some news:
[19:29:23] <@arthurzam> (1) as of some hours ago, alpha is now not exp arch!
[19:29:29] <@sam_> finally!
[19:29:34] <@dilfridge> \o/
[19:29:38] <+Arsen> grats!
[19:29:38] <@sam_> that's great news, exp is really a death spiral
[19:29:38] <@dilfridge> great
[19:29:52] <@arthurzam> (2) I've yanked the weird ppc64-32bit useland profiles, soon will start cleanup of ppc64 profiles
[19:29:53] <@soap> arthurzam: lets do the same with mips!
[19:29:53] <@dilfridge> next step mips :)
[19:29:55] -*- soap ducks
[19:30:00] <+Arsen> lol
[19:30:02] <@soap> dilfridge: jinx!
[19:30:16] <@soap> tbh, I think arthur has a point, and we should split up mips
[19:30:18] <@arthurzam> (3) ia64 is deprecated, until 2024-09-07 when we will remove it
[19:30:31] <@sam_> these mono keywords are appalling
[19:30:36] <@sam_> bitness, endianness
[19:30:37] <@dilfridge> soap: split it up into what? mips and mips64 ?
[19:30:53] <@dilfridge> mips mipsel mips64 mips64el
[19:31:09] <@sam_> no 'el' please, we're not debian
[19:31:14] <@sam_> 'le' and 'be'
[19:31:22] <@dilfridge> that is, unfortunately, the CHOST
[19:31:27] <@soap> dilfridge: yes
[19:32:01] <@soap> we can probably keep the ABIs nested in there, but otherwise, mipsbe vs mips64le are totally different beasts
[19:32:01] <@arthurzam> dilfridge: could you create a blog item for removal of ia64?
[19:32:07] <@dilfridge> yes
[19:32:10] <+Arsen> sam_: mipsNNl and mipsNNb avoid that also ;P
[19:32:11] <@dilfridge> no problem
[19:32:35] <@arthurzam> dilfridge: and also for alpha not exp - I think it would make funny case for Gentoo that we support that thingy
[19:33:13] <@arthurzam> Thats all the news from me for now
[19:33:14] <@robbat2> what's the state of guppy.ia64? as of 2022/04 it was racked&powered still at OSL
[19:33:19] <@dilfridge> lets split that up and post it in different months
[19:33:35] <@dilfridge> robbat2: hangs
[19:33:37] <@sam_> robbat2: it's unstable (kernel) so i have to keep rebooting it, as far as I'm concerned, let's take a backup and uplug it
[19:33:40] <@arthurzam> dilfridge: Aug for alpha, Sep for ia64
[19:33:40] <@sam_> *un
[19:33:46] <@soap> robbat2: didnt you see we need to make space/power at OSL?
[19:33:52] <@arthurzam> lol
[19:33:57] <@soap> say*
[19:33:57] <@robbat2> exactly why I'm asking ;-)
[19:34:05] <@arthurzam> I suspect ia64 is quite power hungry
[19:34:17] <@dilfridge> arthurzam: other way around, because ia64 is an action item while alpha is non-urgent good news
[19:34:28] <@arthurzam> dilfridge: ok
[19:35:11] <@dilfridge> about splitting arches
[19:35:30] <@dilfridge> we should come up with a plan and go with a relatively simple case first
[19:35:45] <@soap> dilfridge: I'd say do it along BE/LE then
[19:35:49] <@dilfridge> like riscv, where riscv32 so far barely exists
[19:35:56] <@sam_> I'll just note that in the past, we've done ACCEPT_KEYWORDS="k ~k" in profiles, maybe we can do basically the same thing
[19:36:17] <@dilfridge> once we have the problems sorted out and a valid procedure, we can do more
[19:36:28] <@dilfridge> sam_: yes that might work
[19:36:40] <@sam_> (not saying it's purely as simple as that, just noting it's an option)
[19:36:43] <@arthurzam> Also remember the userbase for the arches we want to split is quite small and knowladgable, so they can survive if we "break the seemless transition"
[19:36:44] <@dilfridge> I'll start a wiki page based on my -dev mail, then we can collect ideas
[19:36:47] <@sam_> thanks
[19:37:44] <@soap> ok, that should be it then for today?
[19:37:51] <+Arsen> seems so
[19:37:51] <@arthurzam> I think so?
[19:37:54] <@sam_> nothing more from me
[19:38:00] -*- ulm here :)
[19:38:08] <@dilfridge> nothing else that explodes when split?
[19:38:10] <@robbat2> nothing from me
[19:38:15] <+Arsen> ah, welcome back :-)
[19:38:18] -*- soap closes the meeting
[19:38:22] <@sam_> thank you!
[19:38:24] <+Arsen> just in time
[19:38:25] <+Arsen> thank you!
[19:38:27] <@soap> thanks everyone
[19:38:28] <@ulm> Arsen: thanks for proxying
[19:38:30] <+Arsen> np
[19:38:34] <@dilfridge> \o/ thanks :)
[19:38:42] <@arthurzam> Thank you all
[19:39:28] <@mgorny> thx