Bug 508098 – app-emulation/qemu-user: mask & punt

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description SpanKY 2014-04-19 14:52:34 UTC]

afaik, everything qemu-user provides, the single qemu package provides now.  so can we just punt it ?

[Comment 1 Reuben Martin 2014-04-19 18:55:30 UTC]

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.

[Comment 2 SpanKY 2014-04-20 02:06:09 UTC]

if something isn't working in the main qemu ebuild, then file a bug

[Comment 3 Reuben Martin 2014-04-23 03:35:36 UTC]

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.

[Comment 4 SpanKY 2014-04-28 18:52:32 UTC]

mask added:
http://sources.gentoo.org/profiles/package.mask?r1=1.15626&r2=1.15627

[Comment 5 Andrew Aladjev 2014-04-29 15:58:37 UTC]

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?

[Comment 6 SpanKY 2014-04-29 17:44:43 UTC]

(In reply to Andrew Aladjev from comment #5)

file feature enhancement requests for qemu in new bugs please (one per bug)

[Comment 7 Steev Klimaszewski (RETIRED) 2014-05-17 06:41:31 UTC]

(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?

[Comment 8 Steev Klimaszewski (RETIRED) 2014-05-17 07:16:45 UTC]

(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.

[Comment 9 SpanKY 2014-05-18 15:09:58 UTC]

(In reply to Steev Klimaszewski from comment #8)

-ENOINFO.  file a new bug.

[Comment 10 Doug Goldstein (RETIRED) 2014-05-18 21:19:23 UTC]

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.

[Comment 11 SpanKY 2014-05-30 04:42:42 UTC]

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.