Red Hat Bugzilla – Bug 1471066
build success/failure with identical spec file
Last modified: 2017-07-20 11:37:33 EDT
Description of problem:
Building of postsrsd package worked in build 573099. I added documentation inside the repository and it triggered a new build (579388 ) with failed.
Package build page is https://copr.fedorainfracloud.org/coprs/duck/osas-infra-team-rpm-repo/package/postsrsd/
Version-Release number of selected component (if applicable):
Build failed. Corresponding log is https://copr-be.cloud.fedoraproject.org/results/duck/osas-infra-team-rpm-repo/epel-7-x86_64/00579388-postsrsd/builder-live.log
The spec file did not change so it should build fine again.
Originally I created a project for postsrsd. The build worked well on a CentOS 7.3 VM, but failed on Copr. As I wanted to have a single repo for multiple related packages I reorganized in another Copr project, and with the webhook it triggered another build which… succeeded! The spec file was the same so it felt strange but I was happy to get it built. Now I'm facing the same problem again and filing a bug report.
Thanks for this.
It worked for 573099 by accident because we used spectool at that time to download external sources and these sources were replacing the original Source0 generated on dist-git.
The problem is that some (lots of) users put URL into Source0 but still want to build from the content of their SCM repositories. Hence, we stopped replacing Source0 by the downloaded content (content is actually not even downloaded if we have a source file of the same name already at hand) and it works like before spectool introduction.
In your use-case, Source0 should be downloaded and used for the build, however, because you only put spec and patches into a repo. This is a new use-case, actually, that we need to and will take into account.
ETA is one week (probably it will land sooner).
Addresed by https://pagure.io/copr/copr/c/b20621370858ce53f8348ba92850a233ad1dd2dd?branch=master.
You should be able to do this now but you will need to switch the build method to Tito. That's because repo subdirectory (like python-urllib3 or postsrsd) needs to be specified additionally and the MockSCM form does not enable this option. You don't need to specify name of a spec file with "Tito" method. It will be auto-located. Let me know if it works or not, please.
Same comment as 1470342, this is outside the specified need.
Fixed by https://pagure.io/copr/copr/c/11ac8e638480d75d69a19d051affa51110b9e8db?branch=master. You don't need to switch the "methods" now. Just additionally specify the respective subdirectory you want to build. Also note that the spec path is now optional and relative to the specified subdirectory. Please reopen or file a new issue if there is another problem.
New COPR version has been released.
Sorry to bother again.
First, the build works well even with the spec file not specified, so the feature is here.
Nevertheless, If I edit the package settings to make them permanent (and usable with the webhooks), this field is not saved.
Also I had to activate network during build (see https://copr-be.cloud.fedoraproject.org/results/duck/osas-infra-team-rpm-repo/epel-7-x86_64/00581806-postsrsd/builder-live.log). I can activate this permanently and I'll have my packages built, but I think from a security point of view this is not a bright idea. My packages do not need network during the build phase, so I think the SRPM preparation should be decorrelated. At the very least it should at least be documented because this is a change from previous behavior (where the source could be downloaded without this option).
Could you, please, create two new issues for the following?
> Nevertheless, If I edit the package settings to make them permanent (and usable with the webhooks), this field is not saved.
> Also I had to activate network during build ..
I created 1473361 and 1473364 respectively.