00:29 <bgilbert> +1

00:30 <bgilbert> baude: I'm thinking a useful API would be "give me all the keys", and maybe "save these keys to a pool file" if we're going to support that part

00:30 <bgilbert> and then Ignition can handle the key lookup and reassembly

05:39 <adamw> so, it seems rpm-ostree commands on rawhide are failing with error: Error binding to address (GUnixSocketAddress): No such file or directory

05:39 <adamw> anyone looking into that already?

05:39 <adamw> jlebon: dustymabe Colin Walters ^

05:48 <nirik> always an adventure.

05:51 <adamw> yup.

05:53 <bgilbert> filed as https://bugzilla.redhat.com/show_bug.cgi?id=2169622, for the record. (thanks!)

05:58 <adamw> yeah, thanks for the link.

07:16 <adamw> openqa's silverblue image build test is also failing due to "No previous commit for fedora/38/x86_64/silverblue", not sure what's going on there, maybe it'll clear up tomorrow...

12:06 <travier[m]> https://github.com/coreos/rpm-ostree/issues/4306 > impacts rawhide FCOS as well

14:37 <apollo13> if I inspect a container image it has the gitlab access token in the labels: "org.opencontainers.image.source": "https://gitlab-ci-token:XXXX@gitlab.instance.mine",

14:37 <apollo13> is this wanted behavior? :D

14:37 <dustymabe> apollo13: probably not

14:38 <apollo13> open a bugreport against cosa-assembler?

14:41 <dustymabe> apollo13: yeah, since it's cosa injecting the token into the built container image. I'm not sure what the fix would be but we can at least document the issue

14:41 <apollo13> I'll see if I can fix it

14:42 <apollo13> though I am not sure what writes the file in question and where from this is read :D

14:44 <apollo13> btw automatic-version-prefix: "${releasever}.<date:%Y%m%d>.dev" sets ".dev" etc in the image version. How are prod releases ment to be named? and is there a way to override this from outside the treefile or so?

14:44 <dustymabe> apollo13: when cosa does a build it tries to capture information about its inputs so if we go inspect later to try to determine how an image was built we can easily browse the code and we know what commits to start at

14:45 <apollo13> dustymabe: yeah I understand that, I just didn't find the file in question where this info is read from (seems to be coreos-assembler-config-git.json)

14:48 <apollo13> but lemme dig deeper

14:48 <apollo13> ah prepare_git_artifacts it is

14:49 <dustymabe> apollo13: yep

14:52 <apollo13> mhm sanitizing this is not as easy as it looks like

14:52 <dustymabe> yeah. would be easier if there was a way to do auth outside of the URL (env var or something)

15:09 <apollo13> let's see if gitlab handles "git remote set-url origin ${CI_REPOSITORY_URL}" to reset that url, then I should be fine :)

15:54 <apollo13[m]> Ok that does work. A bit ugly but okay

15:57 <dustymabe> apollo13[m]: yay

16:00 <apollo13[m]> So my biggest question currently is how to handle the .dev versioning from the auto version prefix. How to come up with a proper scheme for "ref" naming and then I am good to go I guess (a few ci cleanups maybe). Also if I build variants with --variant should I include the default manifest.yaml?

16:27 <guesswhat[m]> podman 4.4.1 in testing-devel still broken

16:27 <dustymabe> guesswhat[m]: did you see my messages yesterday?

16:28 <guesswhat[m]> dustymabe: guess no :(

16:29 <guesswhat[m]> can do some testing, we are using it quite extensively

16:29 <dustymabe> https://libera.irclog.whitequark.org/fedora-coreos/2023-02-13#33821005

16:30 <dustymabe> guesswhat[m]: the sooner you report the issue the sooner we can try to get the podman team involved

16:31 <apollo13[m]> So, any recommendations on how to use refs and container-imgref (naming wise) and how to utilize docker tags so stuff maps nicely?

16:35 <guesswhat[m]> dustymabe: got it. thanks. will report issue today

16:36 <apollo13[m]> I guess I could just put the ref into the image name and always use the latest tag?

16:58 <guesswhat[m]> dustymabe: https://github.com/coreos/fedora-coreos-tracker/issues/1417

19:35 <dustymabe> aaradhak[m]: marmijo[m]: gursewak: mind a review on https://github.com/coreos/fedora-coreos-pipeline/pull/811 (related to https://github.com/coreos/coreos-assembler/pull/3349)

19:42 <aaradhak[m]> sure, I will take a look at it in a while.

19:42 <aaradhak[m]> s/take/review/, s/a look at//

22:26 <baude> bgilbert, mind peeking at https://github.com/coreos/ignition/pull/1555 and seeing if it is more to your liking ?