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!