Build on COPR vs locally using mock

I have a package on COPR that I was asked to add builds for epel-9 and 10 (in addition to Fedora builds).
I made the necessary changes to the .spec file to make it build locally using mock for epel-9 and epel-10; however when I uploaded the .srpm to COPR, the epel-9 build failed (with a problem in applying a patch).

What would be the difference in the local build with mock and that done by COPR?

I don’t know it this is relevant but there was no mock config file for epel-9 so I created a link to the centos-stream+epel-9 file (as was done in the normal installation with the epel-10 config).

$ ls -l /etc/mock/epel-9-x86_64.cfg
lrwxrwxrwx 1 root root 31 Jan 22 15:56 /etc/mock/epel-9-x86_64.cfg -> centos-stream+epel-9-x86_64.cfg

Check you are using the same srpm in both cases.
I would be looking at the error and debugging based on what it says.

Yes, its the same SRPM.
The error I see in the log is that a patch fails. This is odd because it succeeds in the other builds (and its the same patch).
If I could see the error locally I might be able to find out whats happening but with only the log on COPR to go on and the arduous process of rebuilding, re-uploading and building on COPR I’m not making much progress.

Can you share a link to the SRPM?

I usually add code to the .spec to help debug this sort of thing.

I wonder if you have used any non-standard options on the patch?

I do see on the COPR settings page …
epel-9-ppc64le Builds are done against RHEL + EPEL.
but epel-10 shows
epel-10-x86_64 Builds are done against CentOS Stream + EPEL

My mock configuration is linkjed to centos-stream+epel-9.
There seems to be no way to use mock for rhel+epel 9

Usually using one of the free alternatives works.
Using rocky is popular. try rocky+epel-9 for example.

But having said that having a patch break is odd.
Does the log point to one specific part of the patch in error?
You could split the patch into smaller patches are try to find a small patch that breaks.

For some odd reason its trying to apply a patch twice!

Patch #0 (linux-gpib-nodevnodes.patch):
+ echo 'Patch #0 (linux-gpib-nodevnodes.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file linux-gpib-user/drivers/Makefile.am
Patch #0 (linux-gpib-nodevnodes.patch):
+ echo 'Patch #0 (linux-gpib-nodevnodes.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file linux-gpib-user/drivers/Makefile.am
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file linux-gpib-user/drivers/Makefile.am.rej
error: Bad exit status from /var/tmp/rpm-tmp.ekbOOp (%prep)

The lines in the .spec file are straight forward (and the patch works on other builds)

Patch0:         %{name}-nodevnodes.patch
...
%patch 0 -p1
%patch 1 -p1
%patch 2 -p1

```nnnn

Good find! I think at this point you need experts to help.
You should get answers on the fedora devel mailing list.
I think subscribe via devel - Fedora mailing-lists

What if you number the patches from 1 not 0?
Wild guess that 0 might be special.