Description of problem: wcslib package has conflict with (at least) libevdev, netpbm and perl-Unicode-Normalize Version-Release number of selected component (if applicable): 5.16-1.fc27 How reproducible: always Steps to Reproduce: 1. Take Fedora Rawhide, i686 achitecture 2. Haveone of the other packages installed 3. See the conflict Actual results: file /usr/lib/.build-id conflicts between attempted installs of wcslib-5.16-1.fc27.i686 and libevdev-1.5.7-1.fc27.i686 file /usr/lib/.build-id/1b conflicts between attempted installs of wcslib-5.16-1.fc27.i686 and libv4l-1.12.5-1.fc27.i686 file /usr/lib/.build-id conflicts between attempted installs of netpbm-10.78.00-1.fc27.i686 and wcslib-5.16-1.fc27.i686 file /usr/lib/.build-id/1b conflicts between attempted installs of perl-Unicode-Normalize-1.25-367.fc27.i686 and wcslib-5.16-1.fc27.i686 Expected results: no conflicts Additional info: This is a known problem happening sometimes, I will do a rebuild which will hopefully solve it. This is not a bug with the spec itself but a general one with rpm.
Rebuilt, wcslib-5.16-2.fc27
Rebuilt once more without success, fails on i686 and armv7hl. Reassigning to rpm as other packages reported similar issues https://bugzilla.redhat.com/show_bug.cgi?id=1432372 https://bugzilla.redhat.com/show_bug.cgi?id=1449732
Latest affected build https://koji.fedoraproject.org/koji/buildinfo?buildID=899928
Thanks for the report. This is unfortunate. It is the state of the directories that is different between the packages. And it seems in this case you cannot get rid of it by rebuilding just your own package. We'll have to see which package has different permissions or attributes. Probably one of them was build some time ago with a buggy rpmbuild and needs to be rebuild now.
It seems it is wcslib itself: rpm -qp --qf "[%{filenames} %{filemodes:perms}\n]" wcslib-5.16-3.fc27.i686.rpm | grep build-id/usr/lib/.build-id drwxr-sr-x /usr/lib/.build-id/08 drwxr-sr-x /usr/lib/.build-id/08/5a5a40ac79bda6e920f3d4e8f23cc1e9ec4143 lrwxrwxrwx Note that it has the sticky bit set. I don't know how that happened.
Thank you for investigating :) So the next point/question: Why are only the 32 Bit architectures armv7hl and i686 affected, not the 64 Bit ones? That astropy build [1] for example shows that. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=19798547
You are right. It only seems to be the 32bit arches? e.g. x86_64 is fine: rpm -qp --qf "[%{filenames} %{filemodes:perms}\n]" wcslib-5.16-3.fc27.x86_64.rpm | grep build-id /usr/lib/.build-id drwxr-xr-x /usr/lib/.build-id/38 drwxr-xr-x /usr/lib/.build-id/38/1e747086d438dff9f272ed892a5cec69b73ffd lrwxrwxrwx hmmm
Still looking where this is coming from. What is odd is that it isn't just the .build-id directories. Looking at the wcslib-debuginfo-5.16-3.fc27.i686.rpm package all directories under /usr/lib/debug have the group sticky bit set, but none of the directories under /usr/src/debug /usr/lib/debug drwxr-sr-x /usr/lib/debug/.dwz drwxr-sr-x /usr/lib/debug/.dwz/wcslib-5.16-3.fc27.i386 -rw-r--r-- /usr/lib/debug/usr drwxr-sr-x /usr/lib/debug/usr/bin drwxr-sr-x but /usr/src/debug/wcslib-5.16-3.fc27.i386 drwxr-xr-x /usr/src/debug/wcslib-5.16-3.fc27.i386/C drwxr-xr-x
I can replicate this with a local fedpkg mockbuild --root fedora-rawhide-i386 but still don't know how this is happening.
Panu Matilainen figured out why it doesn't happen on 64bit systems. On 32bit systems the package flips the the group sticky bit on /usr/lib which then propagates to /usr/lib/debug, /usr/lib/.build-id. On 64bit systems it does flip the group bit on /usr/lib64 but rpmbuild itself doesn't install anything under that directory. So it really depends on the setting of %_libdir. I believe we also have a patch to fix this. Setting %attr (or %attrdef) explicitly for anything installed by rpmbuild itself. Testing now, will post upstream.
[I see Mark beat me to commenting, but I'll post this anyway since wcslib is doing strange things] (In reply to Christian Dersch from comment #6) > Thank you for investigating :) So the next point/question: Why are only the > 32 Bit architectures armv7hl and i686 affected, not the 64 Bit ones? That > astropy build [1] for example shows that. In i386 chroot: <mock-chroot> sh-4.4# ls -l builddir/build/BUILDROOT/wcslib-5.16-4.fc27.i386/usr/ total 20 drwxrwsr-x. 2 mockbuild mockbuild 4096 Jun 9 14:05 bin drwxr-xr-x. 3 mockbuild mockbuild 4096 Jun 9 14:05 include drwxrwsr-x. 5 mockbuild mockbuild 4096 Jun 9 14:06 lib drwxr-xr-x. 5 mockbuild mockbuild 4096 Jun 9 14:06 share drwxr-xr-x. 3 mockbuild mockbuild 4096 Jun 9 14:05 src In x86_64 chroot: <mock-chroot> sh-4.4# ls -l builddir/build/BUILDROOT/wcslib-5.16-4.fc27.x86_64/usr/ total 24 drwxrwsr-x. 2 mockbuild mockbuild 4096 Jun 9 14:13 bin drwxr-xr-x. 3 mockbuild mockbuild 4096 Jun 9 14:13 include drwxr-xr-x. 4 mockbuild mockbuild 4096 Jun 9 14:13 lib drwxrwsr-x. 3 mockbuild mockbuild 4096 Jun 9 14:13 lib64 drwxr-xr-x. 5 mockbuild mockbuild 4096 Jun 9 14:13 share drwxr-xr-x. 3 mockbuild mockbuild 4096 Jun 9 14:13 src So the issue originates from upstream makefile using bizarre permissions when installing stuff, and build-id etc inherits those sticky bits from the parent dire ctories. That 64bit happens to avoid it is that %_libdir (which wcslib makefile creates) is different from the debugdir base. You can easily reproduce it on x86_64 too by passing --define "%_libdir /usr/lib" to rpmbuild. This only has gone uncaught this long because wcslib doesn't try to own those directories, otherwise it'd conflict with filesystem package. Note in the above how include directory doesn't have the sticky bit? That's the wcslib-perms.patch fixing the permission crazyness for includedir, the same should be done for all the -m 2775 install's in GNUmakefile. I'd also suggest asking upstream to drop the sticky bits from install, its a ... peculiar (to put it nicely) thing to do when there's no need for it - that I can see. Nevertheless, the build-id directories must not be affected by stuff like this no matter what, so a fix to rpm is needed too (and in the works as noted by Mark)
Posted a patch upstream: http://lists.rpm.org/pipermail/rpm-maint/2017-June/005716.html
Lots of discussion later it has finally landed upstream and in rpm-4.13.0.1-29