Bug 1433129
Summary: | 'Missing build-id' building openbios, SLOF | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Cole Robinson <crobinso> |
Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | ignatenko, kardos.lubos, mjw, mjw, packaging-team-maint, vmukhame |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | rpm-4.13.0.1-11.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-03-17 10:43:16 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Cole Robinson
2017-03-16 21:43:12 UTC
O that is interesting. Thanks. That is indeed rpm related. I assume we didn't check build-ids in noarch packages before. We probably shouldn't. I'll fix that. The reason you get that error is because rpm sees what it presumes are architecture specific ELF files without a build-id note that would identify them as belonging to a specific build. I assume you are expecting these architecture specific ELF files in the noarch package and that they aren't normally ran directly on the installed system but are regarded as data files? An alternative fix would be to %undefine _missing_build_ids_terminate_build But I think rpm should just trust that any ELF files in a noarch package are just data and not actual executables. Please rebuild against rpm-4.13.0.1-11.fc27 in rawhide koji which contains the following fix submitted to upstream: http://lists.rpm.org/pipermail/rpm-maint/2017-March/005258.html Thanks for the quick turnaround. Yes the ELF binaries are essentially just 'data' from the perspective of the host, since they are only run inside an emulated VM environment Looks like this is manifesting in qemu package as well, which distributes some prebuilt roms, but not in a noarch package. This is with rpm-4.13.0.1-12.fc27 https://koji.fedoraproject.org/koji/taskinfo?taskID=18475401 build.log: https://kojipkgs.fedoraproject.org//work/tasks/5401/18475401/build.log error: Missing build-id in /builddir/build/BUILDROOT/qemu-2.9.0-0.1.rc0.fc27.x86_64/usr/share/qemu/palcode-clipper error: Generating build-id links failed RPM build errors: Missing build-id in /builddir/build/BUILDROOT/qemu-2.9.0-0.1.rc0.fc27.x86_64/usr/share/qemu/palcode-clipper Generating build-id links failed Thanks for noticing and reporting. I see this is in a binary arch package. But the palcode-clipper ELF file is not executable. The old shell script code explicitly excluded any non-executable code from build-id checks (it used find with -perm -0100 -or -perm -0010 -or -perm -0001). Which makes sense. I can do the same for the new code. Let me double check and test some things. (In reply to Mark Wielaard from comment #5) > Thanks for noticing and reporting. I see this is in a binary arch package. > But the palcode-clipper ELF file is not executable. > > The old shell script code explicitly excluded any non-executable code from > build-id checks (it used find with -perm -0100 -or -perm -0010 -or -perm > -0001). Which makes sense. > > I can do the same for the new code. Let me double check and test some things. Since this bug has already been closed and this has a slightly different root cause I am handling this in a separate bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1433837 |