Bug 1461875 - Build Continuously Fails to Import SRPM
Build Continuously Fails to Import SRPM
Product: Copr
Classification: Community
Component: backend (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: clime
Depends On:
  Show dependency treegraph
Reported: 2017-06-15 09:45 EDT by Ben Nied
Modified: 2017-07-07 00:20 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-06-29 10:09:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Build log (4.88 KB, text/plain)
2017-06-15 09:45 EDT, Ben Nied
no flags Details

  None (edit)
Description Ben Nied 2017-06-15 09:45:30 EDT
Created attachment 1288080 [details]
Build log

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Import source RPM (example: https://yum.spaceduck.org/kernel-lt-aufs/7/SRPMS/kernel-lt-aufs-4.9.32-1.el7.centos.src.rpm)
2. Try to build

Actual results:
Build fails to import SRPM into Git.

Expected results:
SRPM should be imported normally, and the build should commence.

Additional info:

Log attached
Comment 1 clime 2017-06-15 12:42:49 EDT

the log, you provided, shows that the import went fine. The problem happened on builder and it is caused by the spec file being named after the package. It is called kernel-lt-aufs-4.9.spec, whereas builder expects it to be called kernel-lt-aufs.spec. Would it be possible to change this on your side? If not, we may figure something out.
Comment 2 clime 2017-06-15 12:46:55 EDT
*not being named
Comment 3 Ben Nied 2017-06-15 13:45:06 EDT

There would be some reconfiguration required in my build script to support this, but it's terribly difficult.

Out of curiosity, is this a new change? The packages were building fine a week ago.
Comment 4 clime 2017-06-16 03:26:21 EDT
Yes, this is probably new change. I think it would be a good change as the package would then follow Fedora Packaging Guidelines for naming specs.
Comment 5 Leif Madsen 2017-06-16 14:49:22 EDT
Looks like I'm running into the same issue. Is this change really necessary? If so, maybe it would be better to provide some information that the build is failing because of this, since it isn't obvious when looking through the logs that the reason this started to fail was due to a backend change requiring the spec file to match the package name.

My OVS master build is now broken, and the naming of the spec file is done in the upstream project, not controlled by my build script.
Comment 6 Pavel Raiskup 2017-06-16 15:58:55 EDT
Leif, can you send the logs please?  The mockchain.log in Ben's case was
pretty readable claiming what spec file is missing.

How it worked before in copr?  What copr should do if there were two spec
files in the dist-git directory?  IOW - to me it is really unexpected that
copr ever built against wrongly named spec file (my opinion) -- that just
gives a false feeling that the package was 100% valid.
Comment 7 Leif Madsen 2017-06-16 16:07:21 EDT
I mean, it is somewhat clear that the file is missing (it says so), but when things have been building as-is for well over a year, it's an unexpected change :)
Comment 8 Pavel Raiskup 2017-06-29 00:38:42 EDT
OTOH, copr is also used as "CI" for Fedora in many cases (or some people
build packages in copr before they go through formal package review).  I
doubt you would be able to build such package in Koji...  So you basically
didn't know that your package was broken until now.

So I agree with #1 and #, this actually was good change IMO on copr side
and my feeling is that fixing this bug would be actually regression..

Also, consider that you have two spec files within on dist-git repository, which
one should be taken into account?  Should we build multiple packages?
Comment 9 Pavel Raiskup 2017-06-29 01:13:01 EDT
> I doubt you would be able to build such package in Koji..

Ah sorry, Koji really builds such src.rpm;  there's no point in making copr
behave differently -- so I'm changing my mind.

> Also, consider that you have two spec files within on dist-git
> repository, which one should be taken into account?  Should we build
> multiple packages?

We still should cover this case, though.
Comment 10 clime 2017-06-29 10:09:18 EDT
I alleviated the restriction for .spec naming. Any file ending with .spec in the source directory is being built against now. I don't want to enforce rules that matter only for official Fedora packaging and this was, hence, a regression.

New copr-rpmbuild will be now loaded into newly spawned OpenStack builders.
Comment 11 Leif Madsen 2017-07-05 10:34:20 EDT
Awesome thanks for fixing. I just noticed it started to build today, and I was just about to adjust my RPM :)
Comment 12 Pavel Raiskup 2017-07-07 00:20:27 EDT
> I was just about to adjust my RPM :)

And that's not a bad idea anyways, at least if you plan to maintain a package
which conforms to guidelines.

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