afaik, everything qemu-user provides, the single qemu package provides now. so can we just punt it ?
I haven't tried it recently, but last I checked the "static" build provided by the default package was not able to truly run all by itself. There was a lot of custom patching going on to make it work correctly. i.e. it has to be able to run alone when chrooting into a mounted ARM image for instance. Perhaps this has been fixed in more recent (2.0+) versions.
if something isn't working in the main qemu ebuild, then file a bug
I've confirmed that I can successfully chroot into an environment for another architecture using the latest qemu-2.0. The inability to do that was the only thing keeping qemu-user around that I am aware of. +1 for punting.
mask added: http://sources.gentoo.org/profiles/package.mask?r1=1.15626&r2=1.15627
There is a one unpleasant thing, that you should consider to punt qemu-user ebuild. https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html You can't use qemu-static-$(cpu) in chroot without such wrapper. I can't understand why, but upstream don't want to accept this patch. We have now qemu-initd service in qemu-user ebuild, which expects this wrapper: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/qemu-user/files/qemu-binfmt.initd?revision=1.2 So for qemu-user I've used this patch https://507990.bugs.gentoo.org/attachment.cgi?id=375194 But in qemu we have qemu-initd service like in upstream http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/qemu/files/qemu-binfmt.initd-r1?revision=1.3 Can we have a new use "binfmt-wrapper", which will add this wrapper and qemu-binfmt-wrapper service?
(In reply to Andrew Aladjev from comment #5) file feature enhancement requests for qemu in new bugs please (one per bug)
(In reply to SpanKY from comment #6) > (In reply to Andrew Aladjev from comment #5) > > file feature enhancement requests for qemu in new bugs please (one per bug) Is it really a feature enhancement when you're punting a package without replicating it's actual use?
(In reply to SpanKY from comment #6) > (In reply to Andrew Aladjev from comment #5) > > file feature enhancement requests for qemu in new bugs please (one per bug) Sorry if that last comment came across as rude/combative - I didn't mean it like that - what I mean is, the p.mask message makes it sound like qemu with static-user useflag is a 1:1 replacement, and presently, it isn't, and as of right now, it completely breaks my workflow.
(In reply to Steev Klimaszewski from comment #8) -ENOINFO. file a new bug.
Please do this Mike. I tried in the past but was unsuccessful with the broken CVE ridden ebuild added back. If it doesn't support something, file a bug. As far as the init script for the setting up the static binaries, I added that a year ago while fixing bugs in the qemu-user version so please try it before you guys complain.
i've deleted it from the tree now i'll reiterate that we are interested in people filing new bugs detailing exactly what functionality qemu-user provided that app-emulation/qemu did not. afawk, it should support everything people were using qemu-user for.
