11:36 <travier[m]> https://discussion.fedoraproject.org/t/adding-team-to-almost-all-of-the-tags-in-project-discussion/42707/36

11:38 <travier[m]> FYI: https://bugzilla.redhat.com/show_bug.cgi?id=2177633

13:50 <dustymabe> hartan[m]: any chance you saw this section of the documentation? https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-raspberry-pi4/#_edk2_firmware_gpio_via_devicetree

14:15 <dustymabe> travier[m]: for whatever reason the most recent testing-devel ppc64le build succeeded so maybe we aren't affected by #2177633

15:05 <fifofonix> if i rebase a node to next-devel rn will i get the ssh host key change? eager to validate that signed ssh host keys aren't impacted somehow.

15:13 <jlebon> fifofonix: not yet. we're planning to cut the release tomorrow. would be great to have you test it!

15:15 <fifofonix> always testing next aggressively but looking to pre-release-next in this case ... are you saying next-devel will be usable for this purpose tomorrow or an actual cut of next?

15:17 <dustymabe> jlebon: but he said `next-devel`

15:17 <dustymabe> in which case the answer would be yes

15:18 <dustymabe> we typically don't encourage users to do that (pick up development streams), but he *can* try it

15:22 <dustymabe> fifofonix: do you know how to rebase to `next-devel` ?

15:23 <fifofonix> i was going to google it...

15:24 <jlebon> ahhh yup. we don't often get that request, so misread it :)

15:24 <dustymabe> :)

15:25 <dustymabe> actually `next-devel` isn't what you want (because it's already leading what we're going to release tomorrow)

15:25 <dustymabe> but you can just rebase to the development (unpromoted) version of `next`

15:25 <dustymabe> try this `sudo rpm-ostree rebase fedora-compose:fedora/x86_64/coreos/next`

15:40 <dustymabe> back

17:59 <walters> Our upgrade testing is mainly one test, right? We don't e.g. have an automated test run anywhere that verifies a system with say luks set up can upgrade?

18:15 <fifofonix> ^^ thanks dustymabe

18:22 <dustymabe> walters: that is correct IIUC (jlebon might know more)

18:22 <dustymabe> fifofonix: hope it went well!

18:24 <fifofonix> dustymabe: got distracted but i still have a few hours left to tackle it...

18:38 <fifofonix> dustymabe: ok that trial upgrade worked fine for me without disruption to certified ssh + signed hostkeys.

18:47 <dustymabe> fifofonix: good to know! thanks

18:57 <jlebon> nice!

19:00 <dustymabe> travier[m]: tomorrow do you mind a new review on https://github.com/coreos/fedora-coreos-config/pull/1994 ?

19:06 <dustymabe> gursewak: how's the kubevirt work going? let me know if you want to sync

19:08 <travier[m]> dustymabe: re-reviewed

19:21 <gursewak> dustymabe, we can sync up if you are available.

19:36 <dustymabe> gursewak: give me 10

21:10 <adamw> hmm, ostree building on rawhide seems to have broken in the last few hours

21:10 <adamw> https://openqa.fedoraproject.org/tests/1820861#step/_ostree_build/43

21:10 <adamw> that's the test that builds a silverblue ostree, it's failing with "error: Directory not empty (os error 39)"

21:10 <adamw> first update it failed on was a gstreamer plugin update but i'd sorta suspect that's not the cause

21:11 <adamw> not sure if those /proc errors are a problem. don't recall seeing those before.

21:24 <adamw> that's happening...somewhere between install_packages' call to `composeutil_legacy_prep_dev_and_run` and `println!("Updating {}", path);` in `compose_postprocess_mutate_os_release` (because that's the next thing that gets logged in the last successful run of the test)