04:58 <bgilbert> dustymabe: another possibility is for the job to mark newly-created PRs as draft, so we skip the Prow runs until we think the PR is interesting enough to merge

07:33 <b100s> hi2all; today I've encountered into https://flatcar-linux.org/ and surprised about more than one descendent of CoreOS. What do you think about this distro? How many descendants of CoreOS in the wild and actual use?

08:23 <travier[m]> b100s: You're in the room for Fedora CoreOS discussions so we're obviously biased. From my perspective, Fedora CoreOS (and Red Hat CoreOS) is about merging the best from CoreOS Container Linux and Fedora / Red Hat Atomic Host. Flatcar is a continuation of the Container Linux project. I'm not familiar enough with the changes they've done to say more.

10:34 <BobSlept> Just want to let you know that i've succesfully setup my first fedora coresos server. I first tested on a RPI4 and after that I just created a very simple ignition file with ssh access. After installation I've then added a second harddrive by hand via systemd. Then tried to setup a podman container and when it worked, i've let podman generate a systemd file. It now survives reboots, pulls container image on start of the service. It's

10:34 <BobSlept> super cool. it's just my home "server". But super fun, and in the end it was easier then i thought it would be. Ofcourse it's an fairly easy setup right now, but it works and can't wait on the first auto update to see if it all survives :D

10:40 <travier[m]> Bob Slept: nice!

12:34 <nemric> BobSlept: nice, now you can cpoy/paste your systemd service content in your butane file, and your config will survive across frash installs ;)

12:35 <nemric> *fresh

13:16 <nemric> Yeah ! since 2 hours now, the "redhat.vscode-yaml" extension for VScode now "support" Butane Config file schema from JSON Schema Store ! You just need to install the extension of course and set file association : "files.associations": {"*.bu": "yaml"} in your workspace settings !

13:25 <travier[m]> https://github.com/coreos/fedora-coreos-streams/pull/517 > I need a quick second LGTM on this one. Thanks!

13:29 <fifofonix> nemric: +1

14:03 <dustymabe> hey crobinso - super dumb question.. what's the difference between qemu-aarch64-static and qemu-aarch64_be-static ? https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/qemu.spec#_2376

14:04 <dustymabe> be == big endian ?

14:04 <crobinso> dustymabe: I think _be is big endian.

14:05 <dustymabe> interesting.. does arm64 support both little and big?

14:07 <crobinso> dustymabe: not from virt perspective at least. qemu-user can do some pretty obscure things though since the usecase is much different

14:08 <dustymabe> yeah. I was just evaluating the new rpm now and notice we pay the cost twice because of the be

14:08 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1088#issuecomment-1150393245

14:09 <dustymabe> thanks for the info crobinso

14:10 <crobinso> dustymabe: ah right. if you want to split the package further to have a aaarch64_be variant that's cool with me too

14:11 <crobinso> s/variant/subrpm/

14:12 <dustymabe> crobinso: +1 - we don't want to ask for too much (i.e. others might think we're being unreasonable) so we might keep it as is, but it's good to know that you're open to it.

14:12 <dustymabe> if we do we'll open a PR

14:12 <dustymabe> LakshmiRavichand: thanks for opening https://github.com/coreos/fedora-coreos-config/pull/1778

14:13 <crobinso> dustymabe: my guess is there's 0 distro users of aarch64_be so in practice it probably won't affect anyone

14:13 <dustymabe> 👍

14:20 <dustymabe> LakshmiRavichand: can you go into each of the issues mentioned in https://github.com/coreos/fedora-coreos-config/pull/1778#issuecomment-1151180541 and add a comment like: "This issue should be fixed in `2022.4-2.fc36`. A PR to fast track this update was merged in https://github.com/coreos/fedora-coreos-config/pull/1778"

14:22 <dustymabe> actually make that `ostree-2022.4-2.fc36`

14:42 <dustymabe> LakshmiRavichand: can you open a new PR to remove the kola-denylist entries for those tests?

14:43 <dustymabe> also might be worth running a local `ext.config.ignition.resource.remote` test against `testing-devel` to see if https://github.com/coreos/fedora-coreos-tracker/issues/1215 is still happening

14:48 <LakshmiRavichand> dustymabe: sure, ll do that

15:56 <dustymabe> jlebon: you good with https://github.com/coreos/fedora-coreos-pipeline/pull/539#pullrequestreview-1001612282 ?

15:57 <dustymabe> LakshmiRavichand: let's add a bit more to the commit message https://github.com/coreos/fedora-coreos-config/pull/1779#issuecomment-1151313563

15:58 <LakshmiRavichand> in my local run, I see 'ext.config.ignition.resource.remote' to be passing which looks good

15:58 <jlebon> dustymabe: i am if you are :) patch itself looks sane

15:59 <dustymabe> LakshmiRavichand: +1

15:59 <dustymabe> can you update the commit message in that PR?

16:02 <LakshmiRavichand> dustymabe: updated them :)

16:17 <dustymabe> LakshmiRavichand: I'm not so worried about the PR description, but more about the git commit message.. i.e. run `git commit --amend` locally and update the message and then force push.

16:19 <dustymabe> I'm free to do a screenshare if that would help

16:30 <dustymabe> gursewak__: can you maybe check sometime today if we can drop this pin: https://github.com/coreos/fedora-coreos-config/blob/rawhide/manifest-lock.overrides.yaml

16:54 <gursewak> dustymabe, will check.

17:14 <dustymabe> jlebon: got time for a quick sync?

17:17 <jlebon> dustymabe: not right now; in around 40 mins?

17:18 <dustymabe> k - i'll go grab lunch then

17:18 <dustymabe> see you then

18:04 <dustymabe> jlebon: I think this is all I need to do to show s390x in the builds browser

18:04 <dustymabe> https://github.com/coreos/fedora-coreos-browser/pull/37

19:18 <dustymabe> gursewak: mind adding a comment to https://github.com/coreos/fedora-coreos-tracker/issues/1200 noting the local version that worked in your test?

19:36 <dustymabe> gursewak: saqib: this should fix it so that AWS/OpenStack tests don't get started for s390x: https://github.com/coreos/fedora-coreos-pipeline/pull/540

19:46 <dustymabe> ravanelli: I updated the notes on https://github.com/coreos/fedora-coreos-streams/issues/515#issuecomment-1151552184

19:46 <dustymabe> can you confirm it makes sense?

19:48 <ravanelli> dustymabe: yeah, it make sense to me

19:48 <dustymabe> +1

20:10 <dustymabe> jlebon: dumb question.. do you know what makes it safe for us to run all of these in parallel? https://github.com/coreos/fedora-coreos-pipeline/blob/fba6d3a2b647bfe575381b0ae59fba07b77e6e56/jobs/build.Jenkinsfile#L421-L433

20:10 <dustymabe> won't each of them be trying to update the meta.json ?

20:12 <jlebon> there's locking

20:12 <jlebon> grep cmdlib.py for 'lock'

20:13 <dustymabe> 🤣

20:13 <dustymabe> it would be going off all the time for me

20:13 <dustymabe> 🚨

20:13 <dustymabe> 🚨

20:13 <jlebon> hehe

20:16 <dustymabe> ok right.. locking is one thing, but there exists the "in memory" representation of meta.json for each of the runs

20:16 <dustymabe> which can/will be out of date

20:16 <dustymabe> I guess it's `merge_meta` which handles that

20:17 <dustymabe> https://github.com/coreos/coreos-assembler/blob/main/src/cosalib/meta.py#L28

20:17 <dustymabe> https://github.com/coreos/coreos-assembler/blob/main/src/cosalib/meta.py#L159

20:18 <jlebon> yeah, exactly

20:18 <dustymabe> ok cool

20:23 <walters> but to answer, as part of gangplank we have this `Lock` stuff which is...not entirely consistently used but I think mostly

20:23 <walters> see specifically `def write_json(path, data, lock_path=None, merge_func=None):`