[2025-10-12T19:00:07Z] <@arthurzam> meeting time
[2025-10-12T19:00:07Z] <@arthurzam> !proj council
[2025-10-12T19:00:10Z] <willikins> (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm
[2025-10-12T19:00:12Z] <@arthurzam> agenda at https://public-inbox.gentoo.org/gentoo-project/2a940545-2211-4f2c-9225-ca0072384c7b@gentoo.org/
[2025-10-12T19:00:12Z] <@arthurzam> 1. roll call
[2025-10-12T19:00:15Z] -*- arthurzam here
[2025-10-12T19:00:16Z] -*- mgorny here
[2025-10-12T19:00:17Z] -*- sam_ here
[2025-10-12T19:00:18Z] -*- dilfridge here
[2025-10-12T19:00:19Z] -*- soap_ here
[2025-10-12T19:00:42Z] <+ztrawhcse> actually scratch that, gotta run and bring my father something to eat at work that doesn't have chiyuv sukkah...
[2025-10-12T19:00:52Z] <+ztrawhcse> back soon
[2025-10-12T19:01:23Z] <@arthurzam> ulm: robbat2: ?
[2025-10-12T19:01:24Z] -*- robbat2 present
[2025-10-12T19:02:56Z] <@arthurzam> let's wait for 2 more minutes until 22:04
[2025-10-12T19:03:04Z] <@arthurzam> can someone call him? he doesn't have signal
[2025-10-12T19:04:04Z] <@arthurzam> ok, timeout
[2025-10-12T19:04:08Z] <@arthurzam> :(
[2025-10-12T19:04:25Z] <@arthurzam> So our next item is:
[2025-10-12T19:04:26Z] <@arthurzam> 2. Migration to codeberg [1,2]
[2025-10-12T19:04:26Z] <@arthurzam> [0] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20251012T19
[2025-10-12T19:04:26Z] <@arthurzam> [1] https://public-inbox.gentoo.org/gentoo-project/87ecrifgyk.fsf@gentoo.org/
[2025-10-12T19:04:31Z] <@arthurzam> sam_: can you please lead the item now?
[2025-10-12T19:04:42Z] <@sam_> sure, I can stall until Eli is here :p
[2025-10-12T19:05:05Z] <@arthurzam> I wanted to share the link
[2025-10-12T19:05:06Z] <@arthurzam> https://codeberg.org/Codeberg-e.V./requests/issues/868
[2025-10-12T19:05:09Z] <@sam_> so, to summarise, we've had a response from codeberg's board (or equivalent), saying essentially not to worry about sizes as long as it's all good faith and so on
[2025-10-12T19:05:25Z] <@sam_> and that they don't predict any problems, and that we'll figure them out if we do hit any
[2025-10-12T19:05:58Z] <@sam_> they were a bit taken aback by the formality we had, I think, but I think we were right to be this way, because I had some users approach and express concern about going to codeberg if we were going to overwhelm them
[2025-10-12T19:06:29Z] <@sam_> the question now is what is next
[2025-10-12T19:06:38Z] <@sam_> laumann has worked on some of the scripting I think for handling PRs
[2025-10-12T19:06:48Z] <@arthurzam> I want to ask a harder question: currently in the community of potential proxy devs, is codeberg considered more used than github?
[2025-10-12T19:06:53Z] <@sam_> do we update the wiki and ask proxy-maint@ to start sendin gpeople over there? or what do we do?
[2025-10-12T19:07:07Z] <@sam_> arthurzam: it's impossible to say really, surely it's a smaller pool
[2025-10-12T19:07:14Z] <@mgorny> i think the main question is what are gentoo devs expected to do
[2025-10-12T19:07:21Z] <@sam_> i will say i suspect many people contributing via gh rn do not have codeberg accounts
[2025-10-12T19:07:23Z] <@mgorny> i.e. are we expected now to accept contributions on both channels?
[2025-10-12T19:07:25Z] <@sam_> right
[2025-10-12T19:07:30Z] <@dilfridge> the proxies and contributors will follow
[2025-10-12T19:07:45Z] <@mgorny> or are we looking for something like early testing period, then we expect everyone to switch over
[2025-10-12T19:08:01Z] <@sam_> dilfridge: yes, I believe that -- I don't mind taking drive-bys on ::gentoo every so often, but we'll tell people that the "main process" is codeberg, and you might get lucky and someone merges it via gh
[2025-10-12T19:08:02Z] <@mgorny> we certainly don't want users to switch if they're going to be ignored afterwards
[2025-10-12T19:08:09Z] <@arthurzam> Well, I think early testing area is a must, in case we do notice big hiccups
[2025-10-12T19:08:34Z] <@arthurzam> And we need proxy-maint project to really handle both for that period, upping the load on them
[2025-10-12T19:08:37Z] <@dilfridge> early testing but eventially "switch of main contribution pipeline"
[2025-10-12T19:10:21Z] <@mgorny> does anyone have any clue how the general community "feeling" about this is? i feel like most devs didn't really reply in any way
[2025-10-12T19:10:30Z] <+ztrawhcse> I'd like to eventually encourage people to think of GitHub as an abandoned legacy automated mirror that if you're absolutely lucky someone will actually notice
[2025-10-12T19:10:43Z] <eluks> I can only speak for myself, but I'm happy about moving away from GitHub and can't imagine contributors being upset about the change.
[2025-10-12T19:11:05Z] <@sam_> my impression is people tend to prefer codeberg and like the idea of it but don't hate gh enough to not contribute to gentoo
[2025-10-12T19:11:10Z] <@arthurzam> I'm also unsure on it. I use github a lot, and adding another place, will make it harder for some time
[2025-10-12T19:11:28Z] <@dilfridge> my impression at the cauldron was that codeberg is seen as a valid alternative for things
[2025-10-12T19:11:29Z] <+ztrawhcse> if things pan out we should update the GitHub assignment bot to warn people "oh yeah we don't really use GitHub anymore, just a heads up in case you get disappointed"
[2025-10-12T19:11:32Z] <@arthurzam> So I can't feel the state of devs
[2025-10-12T19:11:53Z] <@mgorny> i think we should focus on people who handle the PRs most
[2025-10-12T19:12:04Z] <@mgorny> so we have as good coverage as possible
[2025-10-12T19:12:11Z] <@arthurzam> I'm concerned on us jumping the wagon, and later discovering we lost contributors en-masse
[2025-10-12T19:12:15Z] <@mgorny> and ofc there's the matter of setting up all the scripting
[2025-10-12T19:12:19Z] <@robbat2> i'll offer an alternate perspective: of the open source I do, I've never had to contribute to anything that was on Codeberg, so I didn't make an account there until I had to
[2025-10-12T19:12:35Z] <@robbat2> kernel stuff is mailing lists, Linux Foundation ecosystem is GitHub
[2025-10-12T19:12:57Z] <@robbat2> so we're really comparing much smaller groups of users
[2025-10-12T19:13:58Z] <@mgorny> well, there's "sign in via github", so not much of a deal
[2025-10-12T19:14:12Z] <@sam_> i think people are used to handling various gitlab instances now too
[2025-10-12T19:14:21Z] <@sam_> i'm really not too worried about it
[2025-10-12T19:14:29Z] <@arthurzam> sam_: which I hate. Why isn't there "import settings" across gitlab instances
[2025-10-12T19:14:32Z] <@sam_> i'm happy to prioritise codeberg for reviews and tell people that
[2025-10-12T19:14:37Z] <+ztrawhcse> yes, I'm very used to having to navigate tons of one-project gitlabs
[2025-10-12T19:14:43Z] <@sam_> this is pretty similar to what is going on in the gnu toolchain side
[2025-10-12T19:14:45Z] <+ztrawhcse> it has not really cramped my style at all
[2025-10-12T19:14:51Z] <@sam_> a lot of the discussion has revolved around "what will the main reviewers do"
[2025-10-12T19:15:09Z] <@sam_> and the main reviewers have said "i'm happy to move over, but i worry about being unfair on others" (because they hadn't committed to moving)
[2025-10-12T19:15:28Z] <@sam_> i think we just have to try it, really
[2025-10-12T19:15:46Z] <@soap_> finally all those developers that won't review PRs on GitHub because it violates the social contract will gladly do it on Codeberg now!
[2025-10-12T19:15:52Z] <@mgorny> what about pull request CI? adjusting existing scripting?
[2025-10-12T19:15:56Z] <@sam_> soap_: I was trying to find a way to phrase that ;)
[2025-10-12T19:16:08Z] <@arthurzam> soap_: lol, I think they will find another reason
[2025-10-12T19:16:23Z] <@soap_> arthurzam: that was the implication :P
[2025-10-12T19:16:29Z] <@mgorny> it shouldn't be hard, i think
[2025-10-12T19:16:36Z] <@sam_> mgorny: laumann started on some of it, I'm not sure how far he got
[2025-10-12T19:16:46Z] <@mgorny> the main question is whether we should run a separate server for it, or split the current cronjob
[2025-10-12T19:16:54Z] <@mgorny> e.g. do 1 github, 1 codeberg or alike
[2025-10-12T19:17:04Z] <@mgorny> but i guess these are details to work out
[2025-10-12T19:17:24Z] <@sam_> the main thing in getting "early testing" done is to figure out the CI side
[2025-10-12T19:17:30Z] <@sam_> otherwise nobody is going to do it, or they'll do gh as well
[2025-10-12T19:17:33Z] <@sam_> and then it's pointless
[2025-10-12T19:17:33Z] <@arthurzam> mgorny: what if we used self-hosted agent server, and then use codeberg pipeline to trigger pkgcheck?
[2025-10-12T19:17:50Z] <@mgorny> arthurzam: are you going to set that up?
[2025-10-12T19:18:03Z] <@mgorny> also remember, we don't want random files in the repository if possible
[2025-10-12T19:18:12Z] <@mgorny> especially if the files will literally just trigger a separate script on our side anyway
[2025-10-12T19:18:25Z] <@arthurzam> I could look at it, but only in at least one month (I expect call to service in the comming days)
[2025-10-12T19:19:35Z] <@mgorny> i think literally replacing github API calls with codeberg API calls will be easier
[2025-10-12T19:19:43Z] <@arthurzam> So at least do we all agree we should define "trial start" requirements, and until they are ready, it is too early to even vote on starting the trial?
[2025-10-12T19:19:58Z] <@mgorny> especially if they expose PRs (or whatever they call it) via remotes
[2025-10-12T19:20:01Z] <@arthurzam> (which include CI, ...) - and make them ready?
[2025-10-12T19:20:14Z] <@sam_> I don't think we need to vote on it (we can if someone wants to), the important thing is there's no objections
[2025-10-12T19:20:28Z] <@sam_> we just need to get on with some infra wiring (and finding volunteers for that)
[2025-10-12T19:20:32Z] <@mgorny> yeah, i think we're all good with starting to prepare and seeing how it works
[2025-10-12T19:20:34Z] <@sam_> yep
[2025-10-12T19:20:43Z] <@mgorny> i'd say 1) infra, 2) volunteer reviewers, 3) users
[2025-10-12T19:20:43Z] <@arthurzam> Well, from my side I'm just very unsure on all of this, but not on the level to be against it
[2025-10-12T19:21:01Z] <@sam_> what are you actually unsure about?
[2025-10-12T19:21:12Z] <@arthurzam> I remember gitlab.g.o and it's failure
[2025-10-12T19:21:22Z] <@sam_> we never promoted that nor really intended it to work
[2025-10-12T19:21:26Z] <@sam_> it was one infra member's pet project
[2025-10-12T19:21:40Z] <@sam_> i was never keen on it because gitlab is a huge application and it's opencore
[2025-10-12T19:21:48Z] <+ztrawhcse> I think that gitlab.g.o doesn't really have anyone who can explain why it exists or anyone should want to use it
[2025-10-12T19:21:49Z] <@mgorny> the problem with gitlab.g.o is that it's barely maintained, and it's gitlab
[2025-10-12T19:21:55Z] <@sam_> yep and yep
[2025-10-12T19:21:55Z] <+ztrawhcse> how do you even create an account there?
[2025-10-12T19:22:02Z] <@mgorny> gitlab is really the worst possible experience
[2025-10-12T19:22:05Z] <@arthurzam> ztrawhcse: you use your gentoo sso
[2025-10-12T19:22:07Z] <@sam_> plus it got overrun with spam, not running our own instance helps a lot with that
[2025-10-12T19:22:11Z] <@arthurzam> ok, i see
[2025-10-12T19:22:15Z] <@mgorny> they compete with atlassian on making things really bad
[2025-10-12T19:22:18Z] <@dilfridge> well, gitlab might have worked *if* we had adapted it forcefully and made that show
[2025-10-12T19:22:22Z] <+ztrawhcse> okay, how does anyone that isn't a Developer create an account there
[2025-10-12T19:22:26Z] <@sam_> arthurzam: exactly. we never even had a safe way for users to sign up, because when we let anyone sign up, we got spam
[2025-10-12T19:22:27Z] <@arthurzam> mgorny: you clearly didn't use bitbucket
[2025-10-12T19:22:33Z] <+ztrawhcse> the entire point of this whole endeavor is for contributors to contribute
[2025-10-12T19:22:42Z] <@mgorny> arthurzam: i did use it in the early days
[2025-10-12T19:23:08Z] <@arthurzam> But if the main point is contributors to contribute, isn't github better *for now*?
[2025-10-12T19:23:24Z] <@sam_> it's always a trade-off
[2025-10-12T19:23:40Z] <@arthurzam> I do agree on preparing server infra & CI, for contigency plan when github isn't better
[2025-10-12T19:23:43Z] <@sam_> github is becoming slower and clunkier, more people are boycotting it, and there's all the AI features they're adding
[2025-10-12T19:23:50Z] <+ztrawhcse> the point is not what's better *now*
[2025-10-12T19:23:52Z] <@sam_> plus the social contract stuff we can finally resolve
[2025-10-12T19:24:01Z] <@sam_> we can finally properly say "yes, you should just send patches via codeberg"
[2025-10-12T19:24:02Z] <+ztrawhcse> gitlab.g.o never had a route to making it functional at all
[2025-10-12T19:24:05Z] <@sam_> not "eh maybe github depending on the devs maybe"
[2025-10-12T19:24:09Z] <@dilfridge> github has entered the enshittification stage
[2025-10-12T19:24:16Z] <+ztrawhcse> it was literally not functional because nobody could sign up
[2025-10-12T19:24:33Z] <@arthurzam> ztrawhcse: yeah, I close the gitlab argument
[2025-10-12T19:24:55Z] <@sam_> so, I see codeberg as strictly better, because we don't have to have it in some weird quasi-unofficial state
[2025-10-12T19:25:18Z] <@arthurzam> (I do like the github free CI usage, to make them pay for abusing open source)
[2025-10-12T19:25:23Z] <@arthurzam> (not relevant to ::gentoo)
[2025-10-12T19:25:50Z] <@mgorny> maybe we'd also get all the contributions concentrated again
[2025-10-12T19:25:56Z] <@mgorny> without people ocassionally resorting to git patches
[2025-10-12T19:26:03Z] <@sam_> that's what i'm sort of going for here
[2025-10-12T19:26:12Z] <@sam_> we can say "just send it on codeberg" without any guilt
[2025-10-12T19:26:13Z] <+ztrawhcse> right, I agree and that's why I'm unlikely to strongly advocate for e.g. Meson to move off of GitHub -- we are too dependent on CI
[2025-10-12T19:26:20Z] <@arthurzam> ok, I guess I agree with you
[2025-10-12T19:26:41Z] <@arthurzam> But for now, we enforce the future migration for ::gentoo, with other repos deciding for themselves
[2025-10-12T19:26:48Z] <@sam_> it's an experiment of sorts, we can't see the future, i think it's worth a go
[2025-10-12T19:27:40Z] <@arthurzam> But I do want to request from the devs, to at least migrate many of our github/projg2 repos to gitweb.g.o, so we aren't 100% dependent on github
[2025-10-12T19:27:56Z] <@mgorny> i've already moved the most important projects
[2025-10-12T19:28:02Z] <@sam_> i'm very glad about that
[2025-10-12T19:28:03Z] <@mgorny> then forgot about moving more
[2025-10-12T19:28:38Z] <@arthurzam> OK, I think we can close this item - we need to work on infra + CI
[2025-10-12T19:28:41Z] <@sam_> ok, what's left to talk about on th-
[2025-10-12T19:28:51Z] <@arthurzam> 3. Open bugs with Council participation [3]
[2025-10-12T19:28:51Z] <@arthurzam> https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation
[2025-10-12T19:28:55Z] <@arthurzam> bug 963069
[2025-10-12T19:28:56Z] <willikins> arthurzam: https://bugs.gentoo.org/963069 "OpenPGP v5 (LibrePGP) and OpenPGP v6 (RFC 9580) formats are incompatible, GLEP63 should mention and handle this"; Documentation, GLEP Changes; UNCO; d:glep
[2025-10-12T19:28:59Z] <@arthurzam> mgorny: do I understand correctly we want to postpone it to at least the next meeting?
[2025-10-12T19:29:05Z] <@sam_> this is a complete mess
[2025-10-12T19:29:15Z] <@dilfridge> it's a whole mess hall
[2025-10-12T19:29:16Z] <@sam_> both ztrawhcse and mgorny have wanted a command to actually repro some incompatibility
[2025-10-12T19:29:19Z] <@mgorny> well, i wanted to discuss it shortly, in case you have some ideas
[2025-10-12T19:29:40Z] <@mgorny> my thinking is to just update the GLEP to say RFC 4880 + curve 25519
[2025-10-12T19:29:44Z] <@dilfridge> yes
[2025-10-12T19:29:51Z] <@sam_> yeah, it's the obvious and best solution for now
[2025-10-12T19:30:00Z] <@mgorny> we can think what to do next, well, later
[2025-10-12T19:30:11Z] <@mgorny> we need to do the packaging side first
[2025-10-12T19:30:16Z] <@arthurzam> mgorny: ok, so I think it can be done as patch to GLEP + vote of council in bug for fast apply
[2025-10-12T19:30:17Z] <@dilfridge> how about we find a minimum extension, and then test how/if we can use all three impls exchangibly with  the resulting keys / sigs
[2025-10-12T19:30:33Z] <+ztrawhcse> having a command to repro the incompatibility would be great for multiple reasons... including adding a glep63-check routine to test your key for compatibility
[2025-10-12T19:30:37Z] <@mgorny> did you see the relevant bugs? for freepg and app-alternatives?
[2025-10-12T19:30:51Z] <+ztrawhcse> I can't even figure out a way to machine-parseably dump the preferences
[2025-10-12T19:30:58Z] <@sam_> (I tried to find a way too and failed so far)
[2025-10-12T19:31:00Z] <@dilfridge> not yet, can look later
[2025-10-12T19:31:27Z] <@robbat2> lmk after this meeting about the preferences dump; i have some suggestions/tooling
[2025-10-12T19:31:41Z] <@mgorny> basically, given how messy gpg is by design and that freepg pretty much patches it, i'm not convinced we can cleanly support both simultaneously
[2025-10-12T19:31:47Z] <@mgorny> more likely having one block the other
[2025-10-12T19:32:00Z] <@dilfridge> well
[2025-10-12T19:32:03Z] <@sam_> that's ok with me if we have to, just they must be separate packages
[2025-10-12T19:32:09Z] <@mgorny> otherwise we're probably going to see problems like gpg starting its agent, and then freepg using it instead of its own
[2025-10-12T19:32:11Z] <@sam_> we've been burned by the single package thing so many times
[2025-10-12T19:32:24Z] <@sam_> soap wanted the openssh hpn etc stuff gone for so long
[2025-10-12T19:32:27Z] <@arthurzam> or maybe a "smart" wrapper selecting the tool at the correct moment (and breaking thw world)
[2025-10-12T19:32:29Z] <@dilfridge> if a freepg created key can be easily modified to be good... the incompatibility is not so extreme
[2025-10-12T19:32:40Z] <@mgorny> yeah, i don't want the bumps to be relying on each other
[2025-10-12T19:32:58Z] <@mgorny> dilfridge: freepg creates rfc4880 by default, i think
[2025-10-12T19:33:15Z] <@dilfridge> or gnupg
[2025-10-12T19:33:17Z] <@mgorny> which is kinda what i dislike -- they deliberately changed UX from gpg, so it's not really a drop-in replacement
[2025-10-12T19:33:17Z] <@dilfridge> whatever
[2025-10-12T19:33:38Z] <+ztrawhcse> they changed UX meaning the command line syntax?
[2025-10-12T19:33:48Z] <@mgorny> yes, the default behavior
[2025-10-12T19:33:53Z] <@dilfridge> this whole thing makes me want to shout at people :|
[2025-10-12T19:34:50Z] <@mgorny> otoh it should make switching between two (as in replacing and restarting) safer
[2025-10-12T19:35:08Z] <@mgorny> as freepg should be able to handle whatever gpg spews, and it should spew stuff compatible with gpg and others
[2025-10-12T19:36:18Z] <@mgorny> well, if nobody has any comments, i think we're good
[2025-10-12T19:36:24Z] <@arthurzam> ok, thank you
[2025-10-12T19:36:28Z] <@arthurzam> bug 961811
[2025-10-12T19:36:29Z] <willikins> arthurzam: https://bugs.gentoo.org/961811 "Consider procuring Token2 PIN+ security keys for developers"; Gentoo Council, unspecified; CONF; tamiko:council
[2025-10-12T19:36:33Z] <@arthurzam> We decided during the last 2 weeks which council members will be included in the test, and sent our details to robbat2. Now we need to finalize the test plan and order it?
[2025-10-12T19:36:36Z] <@mgorny> sam_: i think you had someone working on freepg, right?
[2025-10-12T19:36:37Z] <@robbat2> https://wiki.gentoo.org/wiki/Project:Council/Token2_Eval#Evaluators
[2025-10-12T19:36:53Z] <@robbat2> i asked for those to be clearer about which model, and the test plan
[2025-10-12T19:37:03Z] <@sam_> mgorny: yeah, or hopefully at least
[2025-10-12T19:37:07Z] <@robbat2> also I said we needed a tester in the USA [not Canada]
[2025-10-12T19:37:08Z] <@arthurzam> ok
[2025-10-12T19:37:14Z] <@sam_> I can ask about it again (or do it myself if needed)
[2025-10-12T19:37:26Z] <@arthurzam> robbat2: does tamiko's answers after previous meeting not answer all our questions?
[2025-10-12T19:38:20Z] <@robbat2> he answered about performance
[2025-10-12T19:38:31Z] <@robbat2> but that wasn't really a: "what are the actual requirements, and does Token2 meet them"
[2025-10-12T19:38:40Z] <@arthurzam> arthurzam: ulm: mgorny: sam_: let's fill our details of the device after the meeting, so in ~1h he has all details on the order itself
[2025-10-12T19:39:01Z] <@arthurzam> robbat2: he answered about the code of shipping, tarrifs, etc?
[2025-10-12T19:39:02Z] <@mgorny> robbat2: i think tamiko tested USA orders, didn't he?
[2025-10-12T19:39:32Z] <@arthurzam> What extra info where the destination matters do we miss?
[2025-10-12T19:39:39Z] <@arthurzam> Does the NSA approve it?
[2025-10-12T19:40:02Z] <@robbat2> i want to know how much of a hassle the US tariff stuff will be to shipping
[2025-10-12T19:40:13Z] <@arthurzam> He explained it
[2025-10-12T19:40:36Z] <+tamiko> mgorny, robbat2: yes, I did.
[2025-10-12T19:41:02Z] <@robbat2> "send me a link for online payment." -> we need to improve that
[2025-10-12T19:41:16Z] <@robbat2> i don't want to have to go do that for every dev ordering in the USA
[2025-10-12T19:41:25Z] <@robbat2> or worse, reimbursing them for each order
[2025-10-12T19:41:44Z] <+tamiko> robbat2: The idea what be to order on big shipment to the US and then redistribute via USPS.
[2025-10-12T19:41:53Z] <+tamiko> *would
[2025-10-12T19:42:51Z] <@mgorny> robbat2: what does "Status" in that table mean?
[2025-10-12T19:43:07Z] <@robbat2> for when I start ordering them; to record that ordered/shipped/recieved/testing/passed/failed
[2025-10-12T19:44:02Z] <@mgorny> okay
[2025-10-12T19:44:06Z] <@robbat2> who is going to be that person who will reship in the USA?
[2025-10-12T19:44:36Z] <@dilfridge> trustee in the us?
[2025-10-12T19:44:50Z] <@mgorny> someone trusted xP
[2025-10-12T19:45:01Z] <@dilfridge> we dont have any council member in the us
[2025-10-12T19:45:03Z] <@robbat2> and how do we make their life easier, esp with ordering different models
[2025-10-12T19:45:37Z] <@mgorny> will we actually need different models in the end?
[2025-10-12T19:45:56Z] <@arthurzam> Maybe the dual-a-c covers all?
[2025-10-12T19:45:58Z] <@mgorny> i think we may just go for A+C as the most universal choice
[2025-10-12T19:46:04Z] <@robbat2> depends - some discussion wanted it to be flush with their laptop/system
[2025-10-12T19:47:05Z] <+tamiko> The "flush" token2 versions do prodrude by about 4mm. They are not entirely flush.
[2025-10-12T19:47:06Z] <@robbat2> ~30 devs in the USA right now as a quick skim of the developer list
[2025-10-12T19:48:09Z] <@mgorny> i think we can defer the exact delivery details until after we decide to actually go with them
[2025-10-12T19:49:43Z] <@robbat2> a common order SKU makes sense from a fufillment perspective to me
[2025-10-12T19:49:47Z] <@robbat2> if we can get everybody to agree on it
[2025-10-12T19:49:53Z] <@mgorny> i suppose different models will be marked sufficiently to distinguish them
[2025-10-12T19:49:58Z] <@arthurzam> wait, let me google what you just wrote
[2025-10-12T19:50:00Z] <@mgorny> though i suppose the dev will have a lot of repacking to do
[2025-10-12T19:50:31Z] <@mgorny> we will probably compensate the reshipping dev for the packaging material
[2025-10-12T19:51:05Z] <@robbat2> take 30 padded envolopes, stuff 2 keys per; shipping label (ideally prepaid as much as possible), drop into mail system
[2025-10-12T19:51:32Z] <@robbat2> i don't know about USPS; but at least Canada Post, I can generate prepaid shipping labels from home and just put mail into pickup boxes
[2025-10-12T19:51:36Z] <@sam_> does this need to be done synchronously in the meeting?
[2025-10-12T19:51:55Z] <@arthurzam> robbat2: but do you agree this plan isn't required for intial early testing now?
[2025-10-12T19:52:06Z] <@arthurzam> We do need to plan it, but it can happen in parralel
[2025-10-12T19:52:21Z] <@robbat2> SKU discussion - what model(s) are we using for testing vs final?
[2025-10-12T19:53:14Z] <@arthurzam> Do we want to test type-A if dual-A-C exists?
[2025-10-12T19:53:34Z] <@arthurzam> I see some gain in type-C (small into laptop), which needs to be decided if applicable
[2025-10-12T19:56:28Z] <+tamiko> The mini type-c and mini type-a are small enough to just keep them plugged in. For the larger ones, the type-a, type-c and dual-a-c have about the same dimension.
[2025-10-12T19:56:40Z] <@arthurzam> ok, I think we can continue this planning after meeting
[2025-10-12T19:56:55Z] <@arthurzam> tamiko: thank you for participating!
[2025-10-12T19:56:55Z] <@robbat2> i would like to order these today, so please hash it out
[2025-10-12T19:57:14Z] <@sam_> thanks
[2025-10-12T19:57:21Z] <@robbat2> exactly which model, 20EUR vs 25EUR isn't a cost issue
[2025-10-12T19:57:27Z] <@arthurzam> sam_: mgorny: arthurzam: let's got with dual-a-c for us?
[2025-10-12T19:57:42Z] <@sam_> for the record, i'm fine with whatever model as long as it's usb-c
[2025-10-12T19:57:44Z] <@sam_> sure
[2025-10-12T19:57:46Z] <@arthurzam> ulm: wrote type-c-mini - I guess we let him test it for us?
[2025-10-12T19:57:47Z] <@robbat2> and *which* dual-a-c; e.g. https://www.token2.com/shop/product/token2-t2f2-dual-pin-octo-fido2-1-security-key-nonbranded
[2025-10-12T19:57:51Z] <@robbat2> vs https://www.token2.com/shop/product/pin-dual-release3-fido2-1-key-with-openpgp-and-otp-and-dual-usb-ports
[2025-10-12T19:57:56Z] <@mgorny> wfm
[2025-10-12T19:58:00Z] <+tamiko> robbat2: I suggest to evaluate: (a) https://www.token2.com/shop/product/pin-dual-release3-fido2-1-key-with-openpgp-and-otp-and-dual-usb-ports, (b) https://www.token2.com/shop/product/pin-mini-c-release3-1-fido2-u2f-and-totp-security-key-with-pin-complexity, (c) https://www.token2.com/shop/product/pin-minia-fido2-security-key-usb-a-release3-2
[2025-10-12T19:58:05Z] <@arthurzam> robbat2: it is only the branding, does anyone cares?
[2025-10-12T19:58:14Z] <@robbat2> those two have different features lists
[2025-10-12T19:58:35Z] <+tamiko> robbat2: Make sure it is release 3.1 or release 3.2.
[2025-10-12T19:58:41Z] <@arthurzam> tamiko: your's dual-a-c is out-of-stock
[2025-10-12T19:59:02Z] <@robbat2> tamiko: both of the items are listed are release 3.2 as well
[2025-10-12T19:59:15Z] <@arthurzam> I guess we must go with https://www.token2.com/shop/product/token2-t2f2-dual-pin-octo-fido2-1-security-key-nonbranded for stocked ones
[2025-10-12T19:59:18Z] <@mgorny> i think we should take 3.2, for the sake of it being newer
[2025-10-12T19:59:39Z] <@mgorny> i.e. longer "lifetime" or howdyacallit
[23:00:08] <@arthurzam> ok, I expect ulm to connect in the coming hours, and I hope he will decide on the final model
[23:00:18] <@arthurzam> next item
[23:00:24] <@arthurzam> bug 961301 - tracker
[23:00:25] <willikins> arthurzam: https://bugs.gentoo.org/961301 "[Tracker] Requests for metadata/AUTHORS"; Gentoo Council, unspecified; CONF; ulm:council
[23:00:28] <@arthurzam> bug 730200
[23:00:29] <willikins> arthurzam: https://bugs.gentoo.org/730200 "metadata/AUTHORS: inclusion of myself and prior employers that may own copyright"; Gentoo Council, unspecified; CONF; robbat2:council
[23:00:32] <@arthurzam> we just apply for robbat2?
[23:02:46] <@arthurzam> ok, no against that, so robbat2, when you can, apply the addition (since we ACKed it last council meeting)
[23:02:52] <@arthurzam> And finally, bug 936211
[23:02:52] <@arthurzam> Any updates or questions?
[23:02:53] <willikins> arthurzam: https://bugs.gentoo.org/936211 "[Tracker] Gentoo Foundation dissolution"; Gentoo Foundation, Proposals; CONF; ulm:trustees
[23:03:12] <@robbat2> no news on the foundation side; busy the last month
[23:03:23] <@arthurzam> ok, thank you
[23:03:31] <@arthurzam> no more bugs
[23:03:33] <@arthurzam> 4. Open floor
[23:03:52] <@arthurzam> meeting logs + summary for 2025-09 will be sent soon, had a hard month
[23:05:05] <@arthurzam> anything else?
[23:05:43] <@arthurzam> 2 more minutes
[23:07:43] <@arthurzam> meeting closed