On Wednesday, July 1, 2020 4:03:08 PM CEST PGNet Dev wrote:
>> Does COPR need an earlier preload of 'git' for
forgemeta SCM use by builds?
>
> Copr rebuilds srpm first, from copr dist-git - in limited buildchroot.
as does mock, right?
as I'm getting used to the Fedora build ecosystem, my current workflow is ...
rmpbuild locally
if rmpbuild ok, mock build
if mock build ok, COPR build
a mock build and COPR build _should_ be identical(-ish) ?
By saying those statements, you keep more things unspecified than
specified. The situation isn't that easy:
1. Copr imports (or rather "caches") sources into it's internal dist-git:
a) By uploading only spec file (your case), you rely on the fact that
copr is able to - using provided spec file - download all the needed
tarballs. This is tricky part, and can take any amount of time. But
we do this only once for all the selected target chroots.
b) By uploading src.rpm, copr just goes and imports the data to dist-git.
This may take some time, depending on the connectivity. But it is more
reliable than a) as you are 100% sure what you upload, and then build
from.
2. Copr builder builds a source RPM in mock chroot from dist-git. The
chroot is decided based on the target chroot you build for (so if you
requested rawhide x86_64, the src.rpm is build in rawhide x86_64 as
well first). This should be an easy task since all the tarballs and
specfiles are already cached and available on a very close location to
the builder (in copr dist-git).
3. Using src.rpm from step 2, copr builds the RPMs in target chroot.
So if you build locally using `rpmbuild`, we know nothing about your build
environment, about the tarballs you have pre-downloaded, time of your
build, etc. Mock then helps you to prepare the environment, but
from pre-generated src.rpm! So if this succeeds, and you have correctly
set local environment, you have correct src.rpm to build from.
And so if you delivered exactly that src.rpm to copr, it _should_ succeed
as well as it succeeds in mock locally. But if you upload just the spec
file, you need to rely on the fact the 1.a) step does the same thing you
did locally.
in any case, here's a current fail,
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/f...
again, that same spec builds without error _here_, as a mock build.
now to figure out the differences ...
... and this failure probably means that _when_ you uploaded just the spec
file and copr downloaded all the sources for you automatically, _some
variant_ of sources were downloaded and imported (and cached) to dist-git.
I bit later, using the same spec file and tarballs (from cache) from
dist-git, copr builds source RPM in mock (see the log, --buildsrpm). But
the very same spec file probably newly references _different_ sources than
those cached variants, because it tries to download something (once more,
it shouldn't now, all the sources should be already fetched from caches).
The question is why this is happening; why your specfile references
different sources in slightly different time (or in different
environment).
Perhaps you could (I'm not 100% sure) unblock your builds by enabling
network connection for your RPM builds (check the project web-UI settings
page). But that is a very bad thing to do, considering that the source
rpm should be already correctly imported and nothing should be re-downloaded.
You need to debug what is going on here, this is behind the support edge
for copr maintainers. I'd suggest you to compare the source RPMs you and
copr works with. Compare the local sources, spec files, etc. Try to
build from uploaded source.rpm. We can lend you some copr builder
temporarily if you need it for debugging (so you can try the `copr-rpmbuild`
commands manually).
Pavel