14:51 <miabbott[m]> jdoss your first mistake was using my example 😛

14:58 <guesswhat> hey, when we can expect https://github.com/containers/podman/releases/tag/v4.3.0 in devel/next branch? thanks

15:13 <miabbott[m]> guesswhat: https://github.com/coreos/fedora-coreos-tracker/issues/1327

15:14 <dustymabe> guesswhat: test them out and give feedback in bodhi.. links: https://github.com/coreos/fedora-coreos-tracker/issues/1327#issuecomment-1290526298

15:20 <guesswhat> dustymabe i am not familiar much with rpm-ostree, but is doable to install it from that advisory?

15:24 <travier[m]> guesswhat: https://release-monitoring.org/project/10952/

15:24 <travier[m]> whoops, wrong link

15:24 <travier[m]> https://github.com/coreos/rpm-ostree/issues/4054

15:24 <travier[m]> guesswhat: ^ correct link

15:26 <dustymabe> `rpm-ostree override replace <bodhi url>`

15:29 <guesswhat> rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2022-658b2dbea2 fails to nothing provides containers-common-extra >= 4:1-62 needed by podman-4:4.3.0-2.fc36.x86_64

15:29 <guesswhat> guess it does not handle dependecies

15:32 <dustymabe> There are some corner cases in which it doesn't work. In this case `containers-common-extra` is a new required subpackage (wasn't required before) so that's why you're bumping up into that problem.

15:33 <dustymabe> try rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2022-658b2dbea2 --install https://kojipkgs.fedoraproject.org//packages/containers-common/1/62.fc36/noarch/containers-common-extra-1-62.fc36.noarch.rpm

15:50 <jlebon> dustymabe: are you working on rebasing `rhcos` or should i?

15:56 <dustymabe> jlebon: I will, but was wanting to maybe get https://github.com/coreos/fedora-coreos-pipeline/pull/718 in first

15:56 <dustymabe> i can always add it in the branch without that merging

15:59 <jlebon> :lgtm:

15:59 <jlebon> when rebasing, make sure to drop the commit that disables legacy-oscontainer

16:00 <jlebon> thanks!

16:13 <dustymabe> jlebon: pushed up the rebase

16:13 <dustymabe> i'm mostly squashing any config.yaml changes down into just the first commit

16:14 <jlebon> nice. yeah that SGTM

16:30 <dustymabe> aaradhak davdunc dustymabe gursewak jaimelm jbrooks jcajka jdoss jlebon jmarrero lorbus miabbott nasirhm ravanelli saqali skunkerk walters

16:30 <dustymabe> FCOS community meeting in #fedora-meeting-1

16:30 <dustymabe> If you don't want to be pinged remove your name from this file: https://github.com/coreos/fedora-coreos-tracker/blob/main/meeting-people.txt

17:41 <guesswhat> dustymabe: thanks, its working

18:52 <jdoss> is there a setting for rpm-ostreed to keep N number of container deployment layers so we can roll things back

19:00 <dustymabe> jdoss: https://github.com/coreos/rpm-ostree/issues/577

19:00 <jdoss> Thanks @dustymabe !

19:03 <dustymabe> TL;DR you can pin specific deployments, but you can't configure it to keep N number of deployments around

19:04 <dustymabe> also, on FCOS by default our `/boot/` partition isn't very large so you might bump into space issues if you start pinning a bunch

19:16 <jdoss> OK cool. I am just looking for a way to do updates and be able to roll back. Is there an official way to issue a rollback after an update if my units fail or do I need to make some on-failure units and set things up that way?

19:16 <jdoss> @miabbott[m] your example is great! :)

20:02 <dustymabe> jdoss: usually just `rpm-ostree rollback` and after reboot you are back to your pre-update state

20:02 <jdoss> yeah, I am thinking of how I would tie that to an application healthcheck without stuff going sideways.

20:04 <dustymabe> this is kind of what greenboot is supposed to solve

20:04 <dustymabe> more in https://github.com/coreos/fedora-coreos-tracker/issues/47

20:05 <dustymabe> jdoss: ping lorbus when is around on the topic - there might be some updates there

20:25 <bgilbert> it looks like GitHub re-enabled the Projects tab in all of our repos

20:25 <bgilbert> presumably because they've redone the Projects system

20:25 <bgilbert> I'll go around and turn it off again :-(

20:35 <bgilbert> it re-enabled them on all my personal repos too

20:36 <bgilbert> what a user-hostile move

20:38 <dustymabe> assuming it was intentional, yeah