Red Hat Bugzilla – Bug 1461875
Build Continuously Fails to Import SRPM
Last modified: 2017-07-07 00:20:27 EDT
Created attachment 1288080 [details]
Description of problem:
Version-Release number of selected component (if applicable):
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
Build fails to import SRPM into Git.
SRPM should be imported normally, and the build should commence.
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.
*not being named
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.
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.
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.
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.
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 :)
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?
> 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.
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.
Awesome thanks for fixing. I just noticed it started to build today, and I was just about to adjust my RPM :)
> 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.