00:56 <marmijo[m]> apiaseck: I reran all of the failed kola-upgrade tests for this week's releases and everything passed.

08:43 <travier[m]> dgilmore: https://discussion.fedoraproject.org/t/looking-at-fedora-coreos-cloud-and-server-editions-countme-stats/80085

11:35 <BazilObolensky[m> Hi all! I'm trying to build coreos on fedora37 but cosa build fails on unshare: failed to execute /usr/bin/bootupctl: No such file or directory. Have anyone stumbled upon similar issue or have ANY assumptions what could be wrong? Thanks in advance

11:36 <BazilObolensky[m> * Hi all! I'm trying to build coreos on fedora37 but cosa build fails on unshare: failed to execute /usr/bin/bootupctl: No such file or directory. Have anyone stumbled upon similar issue or have ANY assumptions what could be wrong? I have bootupctl installed on my system. Thanks in advance

11:54 <jbtrystram[m]> Bazil Obolensky: try the assembler container, everything needed is in there : https://coreos.github.io/coreos-assembler/building-fcos/

13:16 <jbtrystram[m]> I was trying out `coreos-assembler`/`cosa` this morning and tried to build coreOS-sericea franckenstein as an exercise, by simply including this manifest : https://pagure.io/workstation-ostree-config/blob/main/f/sway-desktop-pkgs.yaml

13:16 <jbtrystram[m]> But the build failed with `unable to find plymouth`. I thought that coreOS pulled packages from the fedora repos ? I notice the `fedora-rawhide.repo` have a different content than the one from the pagure/workstation-ostree-config repo

13:26 <travier[m]> jbtrystram: Related: https://github.com/fedora-silverblue/issue-tracker/issues/333

13:46 <marmijo[m]> apiaseck: The release job should be unblocked now. Go ahead and start it when you get to that step and we can monitor it's progress.

14:53 <mizmo> is anyone representing fedora core os going to be at flock next week?

15:03 <travier[m]> Máirín Duffy: Clément, Adam and Ellen will be there

15:07 <mizmo> Thanks 🙂

20:19 <bgilbert> hyperv artifacts are missing from the stream metadata in the -streams PR. investigating

20:32 <bgilbert> they're not in the release metadata. fix in https://github.com/coreos/coreos-assembler/pull/3546

20:32 <bgilbert> dustymabe marmijo[m]: how do you want to proceed here?

20:32 <marmijo[m]> Thanks bgilbert! Looking

20:33 <bgilbert> we could defer to the next release, or run new builds, or try to regenerate the release metadata

20:33 <bgilbert> I no longer recall the semantics for the latter. I think a long time ago we decided that adding things to the release metadata was safe, but I don't know what makes sense with the current pipeline code

20:35 <marmijo[m]> bgilbert: dusty is OOO. I think regenerating it is ideal, but I dont know how to do that. I can poke around and see whats the best option. Have we made any commitments to release that artifact in this cycle?

20:36 <bgilbert> we have not

20:36 <bgilbert> while I'd certainly like to see this ship, I think doing manual surgery on the metadata is riskier than it's worth, esp. with folks OOO

20:37 <marmijo[m]> Ok thanks. I agree that might be the best option at this point.

20:38 <marmijo[m]> I'll wait until that PR merges and try to rerun the rollout workflow. If that doesnt auto regenerate the metadata, then we'll wait until the next cycle

20:42 <bgilbert> the rollout workflow generates stream metadata from release metadata, so that won't help. the release metadata is generated by the pipeline

20:42 <bgilbert> from meta.json

20:42 <bgilbert> by the code fixed in that PR

20:48 <marmijo[m]> bgilbert: Ah, ok. Good to know. In that case, I don't feel comfortable manually editing the release metadata. I say we just wait until the next release.

20:49 <bgilbert> +1

20:49 <bgilbert> thanks for looking!

20:49 <marmijo[m]> Thanks for fixing this!