Created attachment 1314931 [details] test unit as source package Seems when %exclude is used in %files excluded files are added second time to debuginfo package list but I'm not sure is that only issue. Full test unit is in attachment as src.rpm Result of the build (after begin %install): $ rpmbuild --rebuild test-exclude-1.0-1.src.rpm [..] Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.FaFuKP + umask 022 + cd /home/tkloczko/rpmbuild/BUILD + '[' /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64 '!=' / ']' + rm -rf /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64 ++ dirname /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64 + mkdir -p /home/tkloczko/rpmbuild/BUILDROOT + mkdir /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64 + cd test-exclude-1.0 + mkdir -p /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64/usr/bin + install hellow world /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64/usr/bin + /usr/lib/rpm/find-debuginfo.sh -j4 --strict-build-id -m -i --build-id-seed 1.0-1 --unique-debug-suffix -1.0-1.x86_64 --unique-debug-src-base test-exclude-1.0-1.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /home/tkloczko/rpmbuild/BUILD/test-exclude-1.0 extracting debug info from /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64/usr/bin/world extracting debug info from /home/tkloczko/rpmbuild/BUILDROOT/test-exclude-1.0-1.x86_64/usr/bin/hellow /usr/lib/rpm/sepdebugcrcfix: Updated 2 CRC32s, 0 CRC32s did match. + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 + /usr/lib/rpm/brp-python-hardlink Processing files: test-exclude-1.0-1.x86_64 warning: File listed twice: /usr/lib/.build-id/fd/5df5a9de19cca0698c2b360391e2aabc285e7e Provides: test-exclude = 1.0-1 test-exclude(x86-64) = 1.0-1 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) rtld(GNU_HASH) Processing files: test-exclude-exclude-1.0-1.x86_64 Provides: test-exclude-exclude = 1.0-1 test-exclude-exclude(x86-64) = 1.0-1 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) rtld(GNU_HASH) Processing files: test-exclude-debugsource-1.0-1.x86_64 error: Empty %files file /home/tkloczko/rpmbuild/BUILD/test-exclude-1.0/debugsourcefiles.list RPM build errors: File listed twice: /usr/lib/.build-id/fd/5df5a9de19cca0698c2b360391e2aabc285e7e Empty %files file /home/tkloczko/rpmbuild/BUILD/test-exclude-1.0/debugsourcefiles.list
Easily verified, thanks for the nice reproducer. Our resident debuginfo guru is on vacation but will look into it, this is more likely than not breaking real-world packages.
AFAICS it's not related to %exclude at all but a dupe of bug 1479198, which is probably why it seemed to ring some bell: If I change the reproducer %prep + %build to this: --- %prep %setup -T -c -n %{name}-%{version} cp %{SOURCE0} %{SOURCE1} . %build %{__cc} %{optflags} -o hellow hellow.c %{__cc} %{optflags} -o world world.c --- ...the problem goes away. The problem is %{SOURCE<n>} files exist in %{SOURCEDIR} which is outside the directory set up in %setup, and this doesn't work anymore. BUT unlike bug 1479198, it does seem kinda legitimate for a package to do %{__cc} %{optflags} -o hellow %{SOURCE0} %{__cc} %{optflags} -o world %{SOURCE1}
Yes, the problem is that when we create debugsource packages we are somewhat aggressive making sure there are actually sources available (we refuse to create an empty debugsource package). This also didn't work with older rpm. Sources outside the buildsubdir aren't found. But with older rpm we just created a debuginfo package with .debug files, but nothing under /usr/debug/src. We should at the minimum improve the error message.
(In reply to Mark Wielaard from comment #3) > We should at the minimum improve the error message. See also this thread: http://lists.rpm.org/pipermail/rpm-maint/2017-August/thread.html#6230 That solution might not be what we want, but it is the place in the code where we can detect the issue and generate a better diagnostic.
(In reply to Panu Matilainen from comment #2) > AFAICS it's not related to %exclude at all but a dupe of bug 1479198, which > is probably why it seemed to ring some bell: > > If I change the reproducer %prep + %build to this: [..] Seems you are right but it is only part of the problem. After change spec I've build packages and this is what comes to generated packages: [tkloczko@domek x86_64]$ rpm -qlv test-exclude-1.0-1.x86_64.rpm; echo; rpm -qlv test-exclude-exclude-1.0-1.x86_64.rpm -rwxr-xr-x 1 root root 7056 Aug 19 09:56 /usr/bin/hellow drwxr-xr-x 2 root root 0 Aug 19 09:56 /usr/lib/.build-id drwxr-xr-x 2 root root 0 Aug 19 09:56 /usr/lib/.build-id/61 lrwxrwxrwx 1 root root 25 Aug 19 09:56 /usr/lib/.build-id/61/152c1618e1e1787d2bbaabbcfb6a34b6aad889 -> ../../../../usr/bin/world drwxr-xr-x 2 root root 0 Aug 19 09:56 /usr/lib/.build-id/d1 lrwxrwxrwx 1 root root 26 Aug 19 09:56 /usr/lib/.build-id/d1/714366455841893b00b68aec9eba1bc735a21f -> ../../../../usr/bin/hellow -rwxr-xr-x 1 root root 7056 Aug 19 09:56 /usr/bin/world drwxr-xr-x 2 root root 0 Aug 19 09:56 /usr/lib/.build-id lrwxrwxrwx 1 root root 25 Aug 19 09:56 /usr/lib/.build-id/61/152c1618e1e1787d2bbaabbcfb6a34b6aad889 -> ../../../../usr/bin/world So as you see %exclude does not affect list of symlinks generated by build-id. In test-exclude-debuginfo package are debuginfo of both binaries. And when I've been building package in output I had an warning: + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 + /usr/lib/rpm/brp-python-hardlink Processing files: test-exclude-1.0-1.x86_64 warning: File listed twice: /usr/lib/.build-id/61/152c1618e1e1787d2bbaabbcfb6a34b6aad889 I don't know why but in my working copy of evolution.spec when I've been trying to use way shorter %files list than t is now with %exclude in main package and those excluded lines in other subpackages I had build fail which exactly the same error messages "File listed twice" like in attached test package. Because I was unable find what I've done incorrectly in evolution I wrote shorter attached test package because I've been suspecting that it is not only something wrong with only my evolution.spec. As this test-exclude has been producing exactly the same result as in evolution I've concluded that my evolution.spec is OK. I need to double check what I've done in my evolution.spec but definitely this spec is not affected by use %SOURCE<num> macros so still something other may be behind a corner :/ Nevertheless seems still it is some issue with build-id related to %exclude :)
You seem to be right that the build-id symlink list generation doesn't properly handle excluded ELF files. That should be fixed of course (I'll look at it when I am back from vacation in ~1.5 weeks). But at worst that should generate a build-id file listing twice. Which would generate that warning. But that shouldn't be a fatal error. Do you have a pointer to the spec file and build.log for the build that fails for you?
Yesterday I found typo in my working copy of evolution.spec and after fixing it it produces only the same warnings as it is possible to observe in test-exclude package. The same as in test-exclude it produces now binary packages despite warnings about duplicated entries. My evolution.spec is even more complicated because it combines %exclude with %bconds. Nevertheless seems I was a bit lucky because I've wrote two a bit wrong spec files and despite this still accidentally I found some rpm bug :) Despite above still what I found was probably easy to ignore by many people like those warning messages on assembly final packages. My evolution.spec is still not finished (is without comments describing all changes I made). With the same approach masking many files in one package + %exclude and list excluded files in other subpackages in case of evolution is possible to reduce dramatically %files content (simpler/shorter -> usually better). If you want I can attach this spec file when I'll back home.
FWIW, %exclude not affecting debuginfo generation is not a new issue, see bug 878863.
(In reply to Panu Matilainen from comment #8) > FWIW, %exclude not affecting debuginfo generation is not a new issue, see > bug 878863. Yes, I've noticed this but it still affects normal packages. Seems script adding symlinks is not doing what debuginfo package is doing. BTW. IMO whole mechanism with build-id in symlinks could be dropped because information which package contains debuginfo is allredy present in rpm and dnf databases. This how this can be obtained: root@domek x86_64]# eu-readelf -n /bin/bash Note section [ 2] '.note.ABI-tag' of 32 bytes at offset 0x254: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 3.2.0 Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x274: Owner Data size Type GNU 20 GNU_BUILD_ID Build ID: c5e4f7e29843d259706c333f7b31eed823af7130 So here we have c5e4f7e29843d259706c333f7b31eed823af7130 build-id and as long as access to debuginfo repos is active using dnf is possible to do: [root@domek x86_64]# dnf repoquery --whatprovides 'debuginfo(build-id) = c5e4f7e29843d259706c333f7b31eed823af7130' Last metadata expiration check: 0:08:46 ago on Mon 21 Aug 2017 13:57:48 BST. bash-debuginfo-0:4.4.12-9.fc27.x86_64 All this can be done without look ups into /usr/lib/.build-id/ directories. In other words content of the /usr/lib/.build-id/ already duplicates what is is in dnf repo.
Any progress on this issue?
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Bug still is reproducible on rawhide.
(In reply to Tomasz Kłoczko from comment #12) > Bug still is reproducible on rawhide. I am not sure I understand what this bug is precisely. How is it different from bug #878863 and bug #1479198
In ticket is attached test unit. Just try it. Result: [tkloczko@domek x86_64]$ rpm -qplv test-exclude-1.0-1.x86_64.rpm -rwxr-xr-x 1 root root 7624 Feb 24 16:44 /usr/bin/hellow drwxr-xr-x 2 root root 0 Feb 24 16:44 /usr/lib/.build-id drwxr-xr-x 2 root root 0 Feb 24 16:44 /usr/lib/.build-id/3d lrwxrwxrwx 1 root root 25 Feb 24 16:44 /usr/lib/.build-id/3d/2bcd8c56be1b40633c74edee3377709a2037e1 -> ../../../../usr/bin/world drwxr-xr-x 2 root root 0 Feb 24 16:44 /usr/lib/.build-id/f2 lrwxrwxrwx 1 root root 26 Feb 24 16:44 /usr/lib/.build-id/f2/33ae8d9fefe6f7fbbbd722cdbc076585c67c55 -> ../../../../usr/bin/hellow As you see build-id links are for both binaries. and only /usr/bin/hellow is included. This bug is not about debugifo or debugsource packages content but about normal packages content. Those two tickets may be related but effects reported are different.
Debug links getting packaged for %excluded files really is a dupe of bug 878863. That the links now live in the main package makes it more visible doesn't mean it's a different issue.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
*** This bug has been marked as a duplicate of bug 878863 ***