For reference:
- Job definition: https://pagure.io/fedora-zuul-jobs-config/blob/master/f/zuul.d/jobs.yaml#_69-81
- Project defining the job: https://pagure.io/fedora-project-config/blob/master/f/FZCI.dhall/fedora-zuul-jobs-config/jobs.dhall
- List of available nodes: https://fedora.softwarefactory-project.io/zuul/nodes

It seems rather odd that fixed fedora containers are used, but it is even more odd that this kind of issue is not more prominent. Maybe there is a better approach to this.

From what I see, the srpm is built by fedpkg srpm. If --srpm-mock and --release flag is added, would it use all of the macros from the release packages?

Further reference:
- https://pagure.io/zuul-distro-jobs/blob/master/f/roles/fedpkg-srpm-build/tasks/main.yaml

From what I see, the srpm is built by fedpkg srpm. If --srpm-mock and --release flag is added, would it use all of the macros from the release packages?

Yes, but you would still need up to date mock configs (e.g. to add Fedora 42 when Fedora 41 is branched), which are not available in f38.

Another option is to do https://pagure.io/fedora-ci/general/issue/461 -- that should work from an arbitrarily old system as long as the Koji CLI client there is still capable of communicating with our Koji.

Hmm basically can just skip that srpm build. Looking at the history it was written like that from the very start, not sure why it was like that. It's a bit annoying because it cannot be fully tested with Depends-on, but the change is pretty straightforward, let me propose it.

There shouldn't be an issue with the architecture of the srpm builder and %ifarch on BuildRequires right? There was that issue with fedrq not finding dependencies if when building the srpm it is gated by %ifarch.

Hmm basically can just skip that srpm build. Looking at the history it was written like that from the very start, not sure why it was like that.

The ability to have scratchbuilds reference commits from forks was introduced after Zuul started in Fedora.

It's a bit annoying because it cannot be fully tested with Depends-on

Scratchbuilds never respected Depends-on because scratchbuilds cannot "see" other sctratchbuilds or custom repos.

There shouldn't be an issue with the architecture of the srpm builder...

IMHO Zuul builds with an arch override.

The ability to have scratchbuilds reference commits from forks was introduced after Zuul started in Fedora.

That was introduced within 3 years ago? That's when build-ngrole was created.

It's a bit annoying because it cannot be fully tested with Depends-on

Scratchbuilds never respected Depends-on because scratchbuilds cannot "see" other sctratchbuilds or custom repos.

I mean using the Depends-on for testing the change of dropping the srpm building.

That was introduced within 3 years ago?

~1 year ago https://pagure.io/fedora-infrastructure/issue/9728

I'll propose an update for the jobs definition. Related issue https://pagure.io/fedora-ci/general/issue/483

This is now fixed, f40 is used: https://fedora.softwarefactory-project.io/zuul/build/7af761ac468447e59d54f3224ee1f440/log/job-output.txt#49

Please re-open if needed

Thanks.