[v4.5 backport][CI:BUILD] Packit: add jobs for downstream Fedora package builds

[lsm5]

Get rid of podman.spec.rpkg in favour of
rpm/podman.spec which gets synced with fedora dist-git on every upstream release. The version in the new spec file is set to 0 by default and gets updated by packit automatically on every packit task.

For local manual rpm builds using the spec, the helper script in the rpm/ subdir will update the Version field with the latest version found in the upstream repo.

Packit will automatically create a PR on fedora dist-git on every new upstream release. A sample PR will look like:
https://src.fedoraproject.org/rpms/container-selinux/pull-request/10#

A dry run for this can be triggered using:
$ packit propose-downstream --local-content

To run this command locally, you would need to have your packit user-configuration-file set.
Ref: https://packit.dev/docs/configuration/#user-configuration-file

along with a fedora api key created at:
https://src.fedoraproject.org/settings#nav-api-tab with sufficient ACLs.

Also includes a revised package Makefile target which will build rpms using rpm/podman.spec. Fixes: #18421.

[NO NEW TESTS NEEDED]

(cherry picked from commit 6003dca)

Does this PR introduce a user-facing change?

None

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lsm5]

@cevich you cool with disabling cirrus task for podman-next on maint branches ? (RE: second commit on this PR)

[lsm5]

actually, i don't see any reason to have cirrus task for podman-next on any branch. Correct me if i'm wrong.

[cevich]

you cool with disabling cirrus task for podman-next on maint branches

Yep...though I question why other stuff is being updated on a maintenance branch when (my understanding is) this only applies to the latest/greatest main?

actually, i don't see any reason to have cirrus task for podman-next on any branch. Correct me if i'm wrong.

You would know better than I. My (limited) understanding is the build (test and otherwise) are all handled by the Packit service, including for PRs, yes? If so, then, yep, feel free to nuke it everywhere.

[cevich]

Also, I see Packit runs on this PR for F37/F38 but this release branch's CI is setup for F36/37. That seems like a recipe for future headaches. Can packit be blocked from running on other branches besides main? or is there a reason for it to run?

[lsm5]

Yep...though I question why other stuff is being updated on a maintenance branch when (my understanding is) this only applies to the latest/greatest main?

This is for the downstream Fedora tasks that will get triggered after an upstream release is published. The tasks need to be on the branch from which the release is cut. If you look at the trigger: commit task that was present already here, that is for a separate copr rhcontainerbot/qm and not our regular copr rhcontainerbot/pomdan-next. The qm copr is for people who wanna do testing with https://github.com/containers/qm and a relatively new and stable podman on CentOS 9 environments.

You would know better than I. My (limited) understanding is the build (test and otherwise) are all handled by the Packit service, including for PRs, yes? If so, then, yep, feel free to nuke it everywhere.

Yes, none of the rpm build tasks need to be done via cirrus. Thanks!

Also, I see Packit runs on this PR for F37/F38 but this release branch's CI is setup for F36/37. That seems like a recipe for future headaches. Can packit be blocked from running on other branches besides main? or is there a reason for it to run?

Packit CI is independent of Cirrus and directly uses the actively supported official Fedora branches. So what we specify in Cirrus doesn't matter to packit. The reason I asked about the cirrus task for podman-next was that it was failing on an earlier run on this PR, hence the additional commit to disable it.

[cevich]

Packit CI is independent of Cirrus and directly uses the actively supported official Fedora branches.

Yep I get that, what I was wondering about is the potential for drift. Imagine a CVE comes out and needs a patch made on this branch a year from now. Cirrus-CI will validate the fix against F36/37 then packet will try and build for F38/39. That build could fail if there's any incompatibility with any dependency.

Is this concern real? Maybe is it possible to lock packit for this branch to only building F36/37 & Stream-8/9?

[lsm5]

Packit CI is independent of Cirrus and directly uses the actively supported official Fedora branches.

Yep I get that, what I was wondering about is the potential for drift. Imagine a CVE comes out and needs a patch made on this branch a year from now. Cirrus-CI will validate the fix against F36/37 then packet will try and build for F38/39. That build could fail if there's any incompatibility with any dependency.

Is this concern real? Maybe is it possible to lock packit for this branch to only building F36/37 & Stream-8/9?

Hmm, looks like I mixed up terminology earlier. This branch would be a release branch and not a maint branch. The -rhel branches would be maint branch. The packit config so far is only intended for Copr and Fedora tasks. If we need build checks on -rhel branches, I can update the packit config on those branches to only run build checks on centos stream 8 and 9 envs. We only need pre-commit CI build checks done via packit on the maint branches.

So, the CVE concern would be real for -rhel, but not for the release branch. Does that answer your q?

[lsm5]

Another thing to note about Copr infrastructure, copr follows Fedora's EOL policy. So, once fedora 36 goes EOL, the build env for f36 will vanish from copr. But anyway, any fedora release shouldn't be a concern for more than a year, CVE wise. Once v4.6 branch is created, we can stop caring about v4.5 branch for Fedora.

[cevich]

Yeah, it's the -rhel case I was thinking about. I like your idea of limiting those to Cent, that would decouple it from the fast-moving Fedora.

Conceptually this SGTM (I haven't looked at any of the actual file changes).

[lsm5]

Yeah, it's the -rhel case I was thinking about. I like your idea of limiting those to Cent, that would decouple it from the fast-moving Fedora.

Great, thanks. Let me know if I should go ahead on any existing -rhel branches.

Conceptually this SGTM (I haven't looked at any of the actual file changes).

No worries. I subjected @edsantiago to that pain on the main branch already :D

[cevich]

A few minor bash-concerns for consideration.

[edsantiago]

LGTM pending @cevich's concerns

[lsm5]

@edsantiago @cevich addressed all concerns in a new commit here and I also have a PR with those changes at #18687 for the main branch . I uncommented a few lines in .packit.yaml after checking with the packit people, so there's some additional diff.

[edsantiago]

/lgtm
/hold

[mheon]

LGTM
/hold cancel