Bug 1471066 - build success/failure with identical spec file
Summary: build success/failure with identical spec file
Alias: None
Product: Copr
Classification: Community
Component: backend
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: clime
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2017-07-14 10:38 UTC by Marc Dequènes (Duck)
Modified: 2017-07-20 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-07-20 15:37:33 UTC

Attachments (Terms of Use)

Description Marc Dequènes (Duck) 2017-07-14 10:38:43 UTC
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):

How reproducible:
No idea.

Actual results:
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

Expected results:
The spec file did not change so it should build fine again.

Additional info:
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.

Comment 1 clime 2017-07-14 11:10:19 UTC
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).

Comment 2 clime 2017-07-18 08:51:26 UTC
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.

Comment 3 Marc Dequènes (Duck) 2017-07-18 11:20:07 UTC
Same comment as 1470342, this is outside the specified need.

Comment 4 clime 2017-07-20 09:31:54 UTC
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.

Comment 5 Marc Dequènes (Duck) 2017-07-20 12:04:29 UTC
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).

Comment 6 clime 2017-07-20 14:02:23 UTC
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 ..

Comment 7 Marc Dequènes (Duck) 2017-07-20 15:37:33 UTC
I created 1473361 and 1473364 respectively.

Thanks :-)

Note You need to log in before you can comment on or make changes to this bug.