Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1602096 - debuginfo package creation fails due to compressed DWARF information on rawhide (f29)
Summary: debuginfo package creation fails due to compressed DWARF information on rawhi...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1601220 (view as bug list)
Depends On:
Blocks: F29FTBFS 1604024 1604112 1604134 1604195 1604526
TreeView+ depends on / blocked
 
Reported: 2018-07-17 19:44 UTC by Lokesh Mandvekar
Modified: 2019-01-02 08:40 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-16 01:11:04 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Lokesh Mandvekar 2018-07-17 19:44:09 UTC 
Description of problem:
This is probably a golang version issue, but anyway, filing it under buildah first.

Enabling debuginfo packages on f29 gives this: 

Provides: buildah = 1.3-1.dev.gita9895bd.fc29 buildah(x86-64) = 1.3-1.dev.gita9895bd.fc29
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: libassuan.so.0()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libdevmapper.so.1.02()(64bit) libdevmapper.so.1.02(Base)(64bit) libdevmapper.so.1.02(DM_1_02_97)(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgpg-error.so.0()(64bit) libgpgme.so.11()(64bit) libgpgme.so.11(GPGME_1.0)(64bit) libgpgme.so.11(GPGME_1.1)(64bit) libostree-1.so.1()(64bit) libostree-1.so.1(LIBOSTREE_2016.3)(64bit) libostree-1.so.1(LIBOSTREE_2016.8)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libseccomp.so.2()(64bit) libselinux.so.1()(64bit) rtld(GNU_HASH)
Processing files: buildah-debugsource-1.3-1.dev.gita9895bd.fc29.x86_64
RPM build errors:
error: Empty %files file /builddir/build/BUILD/buildah-a9895bd41d742117f3480a620a466a363e3d3165/debugsourcefiles.list
    Empty %files file /builddir/build/BUILD/buildah-a9895bd41d742117f3480a620a466a363e3d3165/debugsourcefiles.list
Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py", line 89, in trace
    result = func(*args, **kw)
  File "/usr/lib/python3.6/site-packages/mockbuild/util.py", line 582, in do
    raise exception.Error("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
mockbuild.exception.Error: Command failed. See logs for output.
 # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/buildah.spec



Additional info:

This works just fine on f28 for the same dist-git source. I notice golang is 1.10.3 on f28, but 1.11.0.beta1 on f29, so maybe that's what causes this issue?
Comment 1 Lokesh Mandvekar 2018-07-17 23:41:26 UTC 
This happens with cri-o as well, so quite likely a golang issue. Moving to golang..
Comment 2 Jakub Čajka 2018-07-18 12:08:54 UTC 
Yes, this started with Go1.11 as it is now compressing DWARF debug information by default. Unfortunately the breakage lies in the rpm/debuginfo as it seems to not be able to parse the compressed sections. 

I have turned off the default DWARF compression for time being in Golang(golang-1.11-0.beta1.2 is building right now), until the rpm/debuginfo can be fixed. This should unblock any package that fails in the upmentioned fashion. 

Reassigning.
Comment 3 Mark Wielaard 2018-07-19 09:41:44 UTC 
There are at least two packaging tools, rmp debugedit and dwz, which don't deal with DWARF compressed ELF sections. The easiest workaround for that would be to explicitly decompress any that find-debuginfo.sh encounters.

That could be done by doing something (untested) like the following:

diff --git a/scripts/find-debuginfo.sh b/scripts/find-debuginfo.sh
index 90a4494..7b01bc0 100755
--- a/scripts/find-debuginfo.sh
+++ b/scripts/find-debuginfo.sh
@@ -357,6 +357,9 @@ do_file()
   get_debugfn "$f"
   [ -f "${debugfn}" ] && return
 
+  echo "explicitly decompress any DWARF compressed ELF sections in $f"
+  eu-elfcompress -q -p -t none "$f"
+
   echo "extracting debug info from $f"
   # See also cpio SOURCEFILE copy. Directories must match up.
   debug_base_name="$RPM_BUILD_DIR"
Comment 4 Elliott Sales de Andrade 2018-07-19 22:03:15 UTC 
*** Bug 1601220 has been marked as a duplicate of this bug. ***
Comment 5 Kaushal 2018-07-20 13:50:20 UTC 
glusterd2 was hit with the same issue (bz#1604134). I can confirm that the workaround works [1].

[1]: https://koji.fedoraproject.org/koji/taskinfo?taskID=28469808
Comment 6 Igor Raits 2018-07-25 06:53:01 UTC 
Should be fixed with latest elfutils + rpm.
Comment 7 Carl George 2018-11-15 22:54:50 UTC 
I'm seeing this same behavior while working on a new package.

https://paste.fedoraproject.org/paste/uAHrJcZKzxKanCJ9FCgxlw

My mock chroot is seeing these versions:

rpm-4.14.2.1-2.fc30.x86_64
elfutils-0.174-5.fc30.x86_64
golang-1.11.2-1.fc30.x86_64
Comment 8 Carl George 2018-11-15 23:02:25 UTC 
I get the same result on F27, F28, and F29.  Here is the spec file and SRPM I'm working with.

https://carlwgeorge.fedorapeople.org/golang-github-rainycape-memcache.spec
https://carlwgeorge.fedorapeople.org/golang-github-rainycape-memcache-0-0.1.20181114git1031fa0.fc30.src.rpm
Comment 9 Robert-André Mauchin 🐧 2018-11-15 23:34:06 UTC 
 If you don't build any binary, remove:

%build
%gobuildroot


 Otherwise with a %build section, the packaging process tries to find debuginfo data.
Comment 10 Carl George 2018-11-16 01:11:04 UTC 
*facepalm*

That fixed it, thanks Robert.  Sorry for the noise everyone.
Comment 11 Mark Wielaard 2018-11-16 07:38:22 UTC 
No worries. The error message isn't very helpful. Hopefully someone seeing the error message finds this bug report and sees the actual fix.
Note You need to log in before you can comment on or make changes to this bug.