!user siosm

**Usage:** !user <subcommand> [...] ● hello [username] - Return brief information about a Fedora user. ● info [username] - Return brief information about a Fedora user. ● localtime <username> - Returns the current time of the user.

!user info siosù

!user info siosm

!hi

!hi gursewak

Sorry, could not get info from FASJSON (code 401)

!hi

!hi

!hi

Sorry, could not get info from FASJSON (code 401)

hum, looks like zodbot is not doing well

!hello c4rt0

!hello jlebon

Sorry, could not get info from FASJSON (code 401)

mee to zodbot meee tooo

Sorry, could not get info from FASJSON (code 401)

I asked #admin:fedoraproject.org to look at it

https://pagure.io/fedora-infrastructure/issue/11733

TL;DR we have been laying the groundwork for some time to be able to build CoreOS disk images using the OSBuild tooling rather than the custom code inside COSA.

The underlying enablement is pretty close to working and passing all of our tests.

My current proposal is to switch over our `rawhide` stream to using OSBuild as the tool used to build disk images. Then switch over `next-devel` (and thus `next`) for some period of time.

WDYT?

that sounds reasonable to me. i'm happy about the test added that checks partition tables to make sure they're identical.

Great work team!

Great work everybody!

Great work everybody! Especially Renata, Luke, Dusty and Joseph working on making this happen.

Do we know what a reasonable amount of time to wait would be for then switching over `testing` ?

should we just let it flow in with the F40 rebase? or do it earlier?

!hello jbtrystram

Sorry, could not get info from FASJSON (code 401)

The rebase would be a good target but as always it's a trade off between every change at the same time vs small changes progressively

i think it could be before f40, but at least e.g. two months?

the nice thing with this is that it should only affect new installs, so upgrade risk is quite low

Branch Fedora Linux 40 from Rawhide Tue 2024-02-06

F40 branching is happening soon

I'd say we should switch the branched release to it

that's being moved out a week

I'd say we should switch the branched stream to it

Jonathan Lebon: true regarding only new installs

travier: yeah definitely anything "upstream" of `next` can be switched over

the thing is we don't have a large pool of people on next. it might be worth sending on an email asking to test things once we switch it over

Jonathan Lebon: right. That's why I was considering letting it flow in with the rebase to F40. I think a lot of people start looking at `next` more when it gets rebased to F40

so maybe we could say we switch over `testing` "not before" the rebase to F40 (beta time)

dustymabe: right, yeah. we'd make it part of our f40 communications.

This one is kind wordy:

!proposed We will roll out disk image building using OSBuild to our `rawhide` mechanical stream first (this is a non-user facing stream). Then we will roll out OSBuild to the `next` stream and let it soak there for some time. We may choose to switch over `testing` before the rebase to F40, but we won't do it until F40 has at least reached `next` at F40 beta time.

emojis on their own lines please (for the log history)

+1

+1

+1

+1

+1

+1

+1 (to help with voting - but this is way over my head!)

+1

+1

travier: if you look at the logs from meetings you won't see emoji reactions to individual messages

+1

+1

+1

it'll be good to have it in next before f40 test day

we have this issue and another `fwupd` issue that we really need someone to look into. It's kind of embarassing IMO that we rolled it out and it seems to be missing basic functionality

too bad, the emoji voting format was so nice

Yeah, unfortunately I did not do enough testing. Not sure how to test in QEMU/virtual hardware.

Yeah, unfortunately I did not do enough testing for the fwupd integration. Not sure how to test in QEMU/virtual hardware.

I'm just wondering if we can get someone to look into it more and maybe work with richard hughes? or we could disable it?

We could consider disabling it for now until we've fixed those issues

i'm happy to be heavily directed by someone on this providing it is not too time consuming. i have machines on vsphere/aws that are running next.

re. https://github.com/coreos/fedora-coreos-tracker/issues/1650 I still think if some platforms should be disabled, that should be done upstream or in Fedora.

ahh sorry, have to go to another meeting now!

Jonathan Lebon: I agree

though TBH I'm not sure "platform detection" is really good on any platform other than FCOS (since we have the platform ID)

travier: could you work with fifofonix on this? or any other mentor able to?

ok I'll move on to the next topic

We have some new items to consider

I think we usually try to do advanced testing in our repos on the newer golang versions.. Anything for us to do here on that front?

looks like 1.22 was only built in rawhide a few days ago: https://koji.fedoraproject.org/koji/packageinfo?packageID=16224

and it's not actually in the rawhide repos yet

I guess it's an rc1 so 1.22 isn't out yet?

`Go 1.22 is expected to be released in February 2024`

spresti: do you know how we have handled stuff like this in the past? are there upstream CI knobs for testing on different versions of golang?

I guess there is this line: https://github.com/coreos/repo-templates/blob/b7fb8e151edaccc5250d5604bf4e082ed21bebef/config.yaml#L7

see what happens when you don't answer questions!!!

i'll move on to the next one

hmm interesting..

> Enabling ACD will cause an additional delay when bringing up interfaces, because NetworkManager needs first to probe the address. The delay is between 1.5 and 3 seconds, because RFC 5227 requires that the probe interval is randomized. The delay will affect both static and DHCP connections.

I think we need to critically consider this change

since boot time can be really important especially in cloud scenarios

thoughts?

Lol sorry I stepped away for bio break

Yeah I will take a look, I am not familure with what was done in the past.

spresti: no worries, now you've been cursed with an action item

agree ^^?

we don't really ship any python packages IIUC so I think we're good here

Should be fine for us

should not impact us

we don't really ship the wifi stack, but I know it is common for people to layer it in

ok, it will impact users of FCOS with wifi overlayed but for me this lands into the category of "Fedora makes a change for the better" and we don't have a strong reason to refuse it

based on https://fedoraproject.org/wiki/Changes/StableSSIDMACAddress#Upgrade/compatibility_impact, i think it's maybe worth mentioning in the f40 email

but otherwise, not much for us to do

yeah. we should probably start an issue that collates all the things we need to communicate at switchover time (like we did last time)

You're on an action giving spree :)

travier: watch out, you're next!

Going to leave discretely...🚪

ok I think we are out of time :(

We'll pick up the rest next week

I don't see anything else in the change list that needs immediate action

:)

anyone with anything for open floor? travier not sure if you saw the ask earlier but if fifofonix is willing to dig into the fwupd issue we might want to take advantage of it and give him some guidance

fifofonix: yes, I should be able to help you

fifofonix: yes, I should be able to help you get started

travier: i'll DM you.

🎉

any other topics ? sorry we are over

nothing from my side!