the upstream package strips the binaries at install time but the ebuild is correctly patching the makefiles to prevent that but at the same time is restricting the strip with : RESTRICT="strip" if the restriction to restrict is lifted the following is obtained : * QA Notice: Pre-stripped files found: * /var/tmp/portage/app-emulation/qemu-softmmu-0.9.0-r1/image/usr/share/qemu/openbios-sparc32 which is a pre-stripped binary from upstream which contains a sparc binary that is used as firmware for the emulation of a sparc virtual machine and hence is irrelevant for the QA notice anyway. the end result is that there is no way to support FEATURES="splitdebug" and the binaries are left unstripped when this would have been better solved by either (in order of preference) 1) adding a QA_STRIP for that file which overrides the QA strip check for the sparc firmware (will need QA_STRIP or equivalent to be added to portage) 2) asking upstream from an unstripped binary for that firmware and then letting portage strip it at install time (most likely will need also changes for the make install so that upstream can strip its own firmware at install time too, and will need some really convincing argument on why an unstripped firmware is really needed) 3) remove the restrict and live with the bogus QA notice Reproducible: Always Steps to Reproduce: 1. emerge -Dv qemu-softmmu 2. file /usr/bin/qemu 3. Actual Results: /usr/bin/qemu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped Expected Results: /usr/bin/qemu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped if there is some bug entry or feature request for adding a QA_SPLIT or equivalent and that is the considered solution then this bug could be dependent on that one.
I guess you already provided it in you new ebuild (that I'm about to commit to portage)
(In reply to comment #1) > I guess you already provided it in you new ebuild (that I'm about to commit to > portage) no, otherwise I would have provided the fix on this ticket and the subject will say that qemu-0.9.1 is not affected. qemu-0.9.1 comes with an stripped binary for the openbios-sparc32 firmware so option 2 will need to wait for another release if that will be the path taken to fix this issue. will develop a fix to portage for option 1 instead though and file a feature request for it, as that is IMHO the best option and if there is not one already filed (couldn't find one) and the portage developers agree to integrate it so that it could be used to fix this bug (and others affected for the same issue)
(In reply to comment #2) > will develop a fix to portage for option 1 instead though and file a feature > request for it, as that is IMHO the best option and if there is not one already > filed (couldn't find one) and the portage developers agree to integrate it so > that it could be used to fix this bug (and others affected for the same issue) there is already a feature implemented that could be used for this as detailed here : http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/prepstrip?r1=7381&r2=8915 the changes required will be to replace the current RESTRICT="nostrip" by RESTRICT="bincheks" but are of course dependent on the stabilization of portage 2.1.4 (currently in ~amd64 at least through 2.1.4_rc14)
Based on the report, it appears this has been fixed over the years. Sorry for the lack of updates from Gentoo devs. I'll just close this one as fixed since its fixed in the newer qemu packages since qemu-softmmu is gone.
