Please release 2.1.10 to OBS

[dcermak]

The package https://build.opensuse.org/package/show/devel:kubic:libcontainers:unstable/conmon is still at 2.1.9 which contains a critical regression (#475). As the regression has been fixed in 2.1.10, could you please release a new version to OBS so that we can pick it up for github actions?

[mheon]

Unfortunately most of the team is on end-of-year vacation this week and next week. I don't know if anyone working this week has the ability to trigger OBS builds.

[dcermak]

According to https://build.opensuse.org/package/users/devel:kubic:libcontainers:unstable/conmon @lsm5 @vrothberg and @sysrich have access.

[joelpurra]

The conmon version on OBS was bumped to v2.1.10 on 2023-12-24.

OBS revision diff (login required):

https://build.opensuse.org/package/rdiff/devel:kubic:libcontainers:unstable/conmon?linkrev=base&rev=18

[dcermak]

Joel Purra ***@***.***> writes:

The `conmon` version on OBS was bumped to v2.1.10 on 2023-12-24. OBS revision diff (login required): https://build.opensuse.org/package/rdiff/devel:kubic:libcontainers:unstable/conmon?linkrev=base&rev=18

Thank you! Would it be possible to automate the releasing to OBS? I know that timing before the end of year holidays was really unfortunate, but it resulted in the officially suggested repository for Ubuntu shipping broken binaries for three weeks. And due to OBS only retaining the latest build, we also couldn't switch to the previous version.

[lsm5]

Would it be possible to automate the releasing to OBS?

These days I'm unable to dedicate time to OBS. So, if people in the community are willing to volunteer, we can probably make something happen. If OBS has some magic to have that automation be enabled upstream itself (kinda like https://packit.dev) , that might make life easier for everyone.

but it resulted in the officially suggested repository for Ubuntu shipping broken binaries for three weeks.

by "official", do you mean the conmon / crio docs mentioned this one? @haircommander we should pitch kubic/unstable only as a last resort, or maybe remove it altogether / discourage from prod use from the official docs if we can't actively maintain it.

[haircommander]

yeah cri-o has largely moved to an automated release process, but we package conmon as a bundle with cri-o in that. I don't know what the team's bandwidth for packaging separately for podman is but I suspect we may not have it

[dcermak]

If OBS has some magic to have that automation be enabled upstream itself (kinda like https://packit.dev) , that might make life easier for everyone.

I am working on adding OBS support to packit, but haven't managed to get it implemented yet. OBS can by itself pull files directly from git and build them, but it cannot run any pre-processing steps like packit can. So if the build recipes are somewhere in a git repo, then OBS could build them.

but it resulted in the officially suggested repository for Ubuntu shipping broken binaries for three weeks.

I was wrong about this part. I thought that the podman docs mentioned the OBS repository, but they have been revamped and now the repo is no longer in there.

It would be nice if it this repo could be used though, as the current latest Ubuntu version in Github actions is 22.04 and that ships a rather ancient podman 3.4.4.

[lsm5]

I am working on adding OBS support to packit, but haven't managed to get it implemented yet. OBS can by itself pull files directly from git and build them, but it cannot run any pre-processing steps like packit can. So if the build recipes are somewhere in a git repo, then OBS could build them.

If we have any volunteers committing to active maintenance of the deb build scripts, we could potentially look at hosting them usptream and get used for building on the kubic repos. I'll need the rest of the podman team to signoff on that though. The current podman team doesn't have the bandwidth to own it, so I wanna tread with caution on that, otherwise we'll end up with yet another hard-to-maintain deb packaging attempt.

I would love to build deb packages using the fedora spec files hosted upstream (rpm/podman.spec), but including the deb specific logic would cause us trouble with Fedora upstream. I can check if Fedora is willing to grant us an exception.

It would be nice if it this repo could be used though, as the current latest Ubuntu version in Github actions is 22.04 and that ships a rather ancient podman 3.4.4.

The repo still exists. It's just been removed from the official podman docs. I had checked sometime ago with the GHA people if they'd want to use the kubic unstable repos, but they were happy to continue with the official Ubuntu repo.