On 7/1/20 8:10 AM, Pavel Raiskup wrote:
By saying those statements, you keep more things unspecified than specified. The situation isn't that easy:
(snip)
this is a _very_ useful explanation.
i had not yet wrapped my head around these details from the docs I'd managed to find/read.
thx!
now to figure out the differences ...
...
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).
It already is.
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.
Hm.
I'm used to a system (OBS) where I push the _spec_ file online, specify the source pulls (@OBS, with _service files; similar (?) to forgemeta), and specify the build env / repos used.
As long as the online build env matched my local env, the result's been the same.
I need to revisit/rethink this. It seems that SRPMS are the preferred 'input' ...
Your comments above, again, will be helpful.
You need to debug what is going on here, this is behind the support edge for copr maintainers.
My _goal_ is to get local, mock & COPR builds generating the _same_ results. Ideally, using the available forgemeta constructs.
I'm guessing that consistent build results is not an uncommon goals.
But, sure. I get that resources are limited.
I'd suggest you to compare the source RPMs you and copr works with. Compare the local sources, spec files, etc.
Well THAT much i've been doing :-)
Try to build from uploaded source.rpm.
yep, as above.
We can lend you some copr builder temporarily if you need it for debugging (so you can try the `copr-rpmbuild` commands manually).
lol. still a Fedora-land noob, here. I have no idea what 'lend you some copr builder' means or entails! yet ...
thx agn!