Example scratch build of openbios on current rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=18419192 error: Missing build-id in /builddir/build/BUILDROOT/openbios-20170213-1.git0cd97cc.fc27.noarch/usr/share/qemu/openbios-ppc RPM build errors: error: Missing build-id in /builddir/build/BUILDROOT/openbios-20170213-1.git0cd97cc.fc27.noarch/usr/share/qemu/openbios-sparc32 error: Missing build-id in /builddir/build/BUILDROOT/openbios-20170213-1.git0cd97cc.fc27.noarch/usr/share/qemu/openbios-sparc64 error: Generating build-id links failed Missing build-id in /builddir/build/BUILDROOT/openbios-20170213-1.git0cd97cc.fc27.noarch/usr/share/qemu/openbios-ppc Missing build-id in /builddir/build/BUILDROOT/openbios-20170213-1.git0cd97cc.fc27.noarch/usr/share/qemu/openbios-sparc32 Missing build-id in /builddir/build/BUILDROOT/openbios-20170213-1.git0cd97cc.fc27.noarch/usr/share/qemu/openbios-sparc64 Generating build-id links failed I don't know if this is RPM related really, but I saw another bug go by mentioning build-id changes, so maybe this is related? Dunno, could use some guidance. Not sure if it matters but this package and SLOF are built with cross-gcc, build is kinda non-standard in that way, and debuginfo isn't generated for previous builds. rpm-4.13.0.1-9.fc27
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