Description of problem: 1. I downloaded a src.rpm from koji, added some patches to customize it, and rebuilt it using rpmbuild. It installed just fine. But, when I ran dnf update , it gave a whole list of packages that couldn't be updated because there was a /usr/lib/.build-id conflict with the locally built package. When I reinstalled the package from the Fedora repositories, the update succeeded. 2. I downloaded a src.rpm from koji, changed the name to one not in the Fedora repositories, and added some patches to customize it. I rebuilt it using rpmbuild. But, when I try to install it using dnf install, dnf refuses and cites conflicts in /usr/lib/.build-id. Version-Release number of selected component (if applicable): Name : rpm Version : 4.13.0.1 Release : 23.fc27 Architecture: x86_64 How reproducible: Every time Steps to Reproduce: 1. Build a src.rpm from koji on the local system 2. Try to install with dnf 3. Actual results: file /usr/lib/.build-id from install of package [blah] conflicts with file from package [long list of packages] Expected results: successful install Additional info: This works without problem on F25, and I think it worked on F27 until about a month ago.
Which package are you rebuilding?
The new nethack-3.6.0 package. It's been stable for years, and a long time ago, I added some tweaks to make it more fun for me to play. The process has worked fine for many versions of Fedora, with just a rebuild of the package. I just ported those to the new version, and expected it to continue working. In F25 it did, and it also did initially in rawhide. But, a recent dnf update produced the build-id errors, until I reinstalled the repository package.
Also, which packages are conflicting? There have been a few bugs in how the build-id directories are added to packages and as a consequence, rawhide has packages built with differently buggy rpm versions and chances are the locally built package is correct and the ones conflicting are in need of rebuild.
Hi stan, Some questions to better understand what is going on: - I assume you did the rpmbuild on an (up to date) rawhide system? - Could you post the exact nethack.spec file you used locally? - How exactly did you invoke rmpbuild, which command line arguments? - What was the exact dnf update or install command you tried? - It would be helpful to get the precise output you got. Specifically what was "[blah]" and "[long list of packages]"? Thanks, Mark
@3 It is a long list of packages, and I didn't capture it at the time because things have been going so well in rawhide that I stopped redirecting output to files. I'll fire it up at some point, and get the list. It won't be the list for updating with my modified nethack 3.6 installed because I can't install it. It will be the list of files that complain of build-id collision because I try to install my modified nethack 3.6. @4 - I assume you did the rpmbuild on an (up to date) rawhide system? Yes - Could you post the exact nethack.spec file you used locally? It's just the package spec file with patches added. I'll attach it. - How exactly did you invoke rmpbuild, which command line arguments? rpmbuild -bb hetnack.spec > build_output 2> error_output from within the rpmbuild/SPECS directory. - What was the exact dnf update or install command you tried? dnf update - It would be helpful to get the precise output you got. Specifically what was "[blah]" and "[long list of packages]"? As I mentioned to Panu, I'll have to regenerate this, but it was a long list that I didn't capture. It was similar to the output from when the same issue was occurring in rawhide a few months ago. blah was nethack, and long list of packages was everything that complained of build-id collision. It was more than a full screen, so dozens of packages.
Created attachment 1285474 [details] modified nethack 3.6.0 spec file Just the src.rpm package spec file with patches added.
Created attachment 1285498 [details] Errors that dnf gives when trying to install locally built package These are all the build-id conflicts that dnf detects when trying to install my modified nethack package.
I was re-reading your questions, and realized you wanted the exact update command for the nethack reinstall command. dnf -C reinstall nethack-3.6.0-36.fc27.x86_64.rpm from within the rpmbuild/RPMS/x86_64 directory. Which is the same command I ran to get the above attached output.
Thanks. That is a lot of conflicts indeed. But all for the same directory it seems. What is the output of: rpm -c -qp --qf "[%{filenames} %{filemodes:perms}\n]" nethack-3.6.0-36.fc27.x86_64 | grep build-id
Here's the output. # rpm -c -qp --qf "[%{filenames} %{filemodes:perms}\n]" nethack-3.6.0-36.fc27.x86_64.rpm | grep build-id /usr/lib/.build-id drwx------ /usr/lib/.build-id/70 drwx------ /usr/lib/.build-id/70/f61c6b990e1a9ec537c5799656d48274b32a2f lrwxrwxrwx /usr/lib/.build-id/c7 drwx------ /usr/lib/.build-id/c7/6a86490e7443ec4d37c574a907f6449dc4535b lrwxrwxrwx This is for the standard package, which gets the same errors as my modified package. I was just in the process of seeing if using the unmodified src.rpm package would have the errors when I read your reply. If necessary, I can rerun with the modified package, but I don't think the modifications have anything to do with this after the unmodified package also generated the build-id errors.
Thanks, that is the issue: /usr/lib/.build-id drwx------ It should be (like in all the other packages): /usr/lib/.build-id drwxr-xr-x Now to figure out how that happened...
Problem is that I cannot replicate locally using fedpkg mockbuild. All permissions come out as expected (/usr/lib/.build-id drwxr-xr-x).
I can reproduce after 'umask 0077' on the building shell. And that makes sense - the build-id stuff takes permissions as they come from the fs, which is dependent on local umask and all. To fix, set the permissions explicitly in the %attr(...)'s that are already attached to the build-ids instead of just passing '-' (which means "whatever is on disk"). Or set %defattr() for both files and directories.
Posted a patch upstream: http://lists.rpm.org/pipermail/rpm-maint/2017-June/005716.html
Thank you for the fast resolution.
(In reply to stan from comment #15) > Thank you for the fast resolution. Note that it isn't in fedora rpmbuild yet. I have been told that the patch as proposed is a bit ugly (it duplicates the file list parsing). So we'll discuss it first upstream to see if we can get something that makes everybody happy. But hopefully soon after it will hit fedora.
I usually run a locally compiled kernel from rawhide on my stable Fedora version. The latest 4.12 kernel requires a later rpm than F25 has. I downloaded the src.rpm and built the rawhide version of rpm, and it built just fine. If I install it on F25 in order to compile a kernel, I think I will see the build-id issue on F25, until the fix you proposed is implemented. Is that true?
(In reply to stan from comment #17) > I usually run a locally compiled kernel from rawhide on my stable Fedora > version. The latest 4.12 kernel requires a later rpm than F25 has. I > downloaded the src.rpm and built the rawhide version of rpm, and it built > just fine. If I install it on F25 in order to compile a kernel, I think I > will see the build-id issue on F25, until the fix you proposed is > implemented. Is that true? Although the fix still hasn't been discussed upstream this issue is somewhat specific to nethack/umask settings. It really should not impact normal builds. As long as your umask is not non-standard it should work fine. Also the kernel is special and generates build-ids slightly differently working around this issue.
Thank you.
Fix should be in rpm-4.13.0.1-29
The updated rpm packages weren't in the rawhide repositories, so I used the 4.13.0.1-30 versions of the packages from koji. I can confirm that the updated packages work fine, the errors are gone, and the transactions succeed. Thanks for your help.