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
Hello, 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
Hello, 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.