Bugzilla Bug 192286

When installing nspluginwrapper, the install doesn't check if the kernel is
compiled with the CONFIG_IA32_EMULATION enabled.

When you run the command nspluginwrapper -i [plugin_to_install] you will have
an error message:
npviewer.bin: cannot execute binary file

Reproducible: Always

Steps to Reproduce:
1. Build a kernel with IA32 emulation support (grep IA32_EMULATION
/usr/src/linux/.config. (output must be: "# CONFIG_IA32_EMULATION is not set" )
2. Install the kernel and boot from it.
3. Install nspluginwrapper (emerge nspluginwrapper)
4. Install netscape-flash
5. Run nspluginwrapper -i [location of libflash.so]

Actual Results:  
The result will be that bash will say:
"npviewer.bin: cannot execute binary file"

And no plugin is installed via the wrapper.

Expected Results:  
The installation process of nspluginwrapper must be aborted, because the kernel
doesn't support IA32 emulation. So the user must be given a hint that the IA32
Emulation must get enabled.

Used kernel: 2.6.22.5 (from kernel.org)

nspluginwrapper version: 0.9.91.5
netscape-flash version.: 9.0.48.0-r1
mozilla-firefox version: 2.0.0.6

You'll have a _lot_ more trouble without IA32 that nspluginwrapper on multilib
profiles; on no-multilib ones it's package.masked.

http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#kernel

While I do agree that anyone not following the FAQ is asking for trouble, I
think the ebuilds themselves should be giving information about this.  It could
be done via the multilib eclass or some other similar method.  Basically, we'd
want the following:

- is this a multilib profile?
- does this profile require special kernel parameters?
- are those parameters enabled?
- if not, throw a WARNING

Of course, this would end up leaving a good bit of work to anyone who maintains
a binary ebuild that has amd64 KEYWORDS, but I think I maintain a majority of
them, if not most of them, and I'm willing to put in the work.  Users should be
informed when they need to do something for an ebuild to work and we can never
assume that they've read any of our wonderful documentation.

I'm reassigning this to amd64, since I know they have a kernel option for
32-bit support.  Do other arches have the same thing and also multilib?  If so,
we'd likely want to add them to CC also.

(In reply to comment #2)
> While I do agree that anyone not following the FAQ is asking for trouble, I
> think the ebuilds themselves should be giving information about this. It could
> be done via the multilib eclass or some other similar method. 

Uh, which ebuilds? You can't even install basic multilib AMD64 system without
having IA32 emulation enabled, things like gcc or sandbox won't compile... Are
you seriously suggesting to make all ebuilds that use multilib eclass depend on
configured kernel sources to check for this? Oh wow, that will really rock. o_O

I kind of agree with jakub... That said, maybe in the multilib profile bashrc
we should check for IA32 mode or something, not having it is really not a good
idea (unless you use the no-multilib profile)... 

I know you might not believe this, but I'm not an idiot.  I never once
mentioned requiring kernel sources.  Go back and look at comment #2 please
before making any more comments here.  Also, you very well can setup a Gentoo
box without CONFIG_IA32_EMULATION, it's called a stage3.  Now, if you have
actual factual technical information to provide, feel free.  There's no need
for sarcastic comments which provide nothing to the issue at hand.

Thanks

Created an attachment (id=130780) [details]
Code snippet example for checking multilib options

OK.  This is a general idea on how this can be done.  It might not be 100%
correct, but it gets the idea across.

Since I am using only a WARNING, there's no reason to *DEPEND on any kernel
sources, nor do we fail on missing kernel sources.  This still allows for
compiling (where necessary) on alternate machines and only runs the checks when
necessary.  Of course, other arches could be added, if necessary.

(In reply to comment #7)
Yeah, you can install from stage 3 - and on any gcc upgrade you've get
non-compilable gcc without IA32 emulation.

Back to this 'issue': Producing spurious warnings because of
missing/uncofigured kernel sources is a _lot_ worse than users occasionally
hitting a 'problem' because they didn't follow the docs. Also you can even have
IA32 emulation enabled in currently unpacked/configured kernel, but that
doesn't say anything at all about the running kernel. As these packages we are
talking about here don't require kernel sources to compile at all, similar
checks are essentially bogus.

On another note, linux-info eclass already depends on virtual/linux-sources, so
where exactly do you want to stick the above attached code snippet? Can't be
any eclass/ebuild, and not really sure how will using inherit fly in
profile.bashrc.

If this is such a horrible issue, why don't you ask kernel folks to make that
option hard-enabled on amd64 multilib? Yeah, they won't do it because it
doesn't make sense. Nor does a similar check for PEBKAC cases make sense
elsewhere, kinda sounds like the "don't put your dog into your microwave"
warnings.

If you want a real check, compile a stub of 32bit code and try to run it, that
won't produce any spurious warnings anywhere - but will still be a complete
over -engineering.

So, how many ebuilds do we have that depend on compiling 32bit code on a x86_64
platform?  I want to say very few, so we should avoid using a check in the
profile.bashrc on every package and instead patch the ebuild and/or configure
script.  I'm of the opinion that this is something autoconf should be catching,
but I can see an argument for doing the check inside the ebuild too.  Before
considering any approach, we should figure out how many packages depend on the
functionality proposed.

On a unrelated note, the tone on this bug seems to be very negative, lets try
to keep it more professional.

(In reply to comment #8)
> (In reply to comment #7)
> Yeah, you can install from stage 3 - and on any gcc upgrade you've get
> non-compilable gcc without IA32 emulation.

...and?  What does that have to do with *this* bug report?

> Back to this 'issue': Producing spurious warnings because of
> missing/uncofigured kernel sources is a _lot_ worse than users occasionally
> hitting a 'problem' because they didn't follow the docs. Also you can even

That is totally your opinion, which I and the original bug poster do not share.
 As such, I asked the affected architecture team(s) what they thought of my
idea for a solution and will be proceeding based on their valued input.

> On another note, linux-info eclass already depends on virtual/linux-sources, so
> where exactly do you want to stick the above attached code snippet? Can't be
> any eclass/ebuild, and not really sure how will using inherit fly in
> profile.bashrc.

*yawn*

Did you ever think that it could be put *in* linux-info?  It really doesn't
matter very much where it ends up, so long as it doesn't affect the dependency
tree in the lower stages, which is my playground/responsibility and something
I'm not exactly apt to go around breaking.

> If this is such a horrible issue, why don't you ask kernel folks to make that
> option hard-enabled on amd64 multilib? Yeah, they won't do it because it
> doesn't make sense. Nor does a similar check for PEBKAC cases make sense
> elsewhere, kinda sounds like the "don't put your dog into your microwave"
> warnings.

Why does an issue have to be "horrible" to be fixed?  How about I go and change
the severity to "trivial" instead. Will that stop this incessant non-technical
badgering?  Oh wait, it already is marked trivial.  Go figure.

> If you want a real check, compile a stub of 32bit code and try to run it, that
> won't produce any spurious warnings anywhere - but will still be a complete
> over -engineering.

That would actually be fine, if we were talking about compiling 32-bit code. 
We aren't.

This bug report has to do with *running* 32-bit code on a multilib x86_64
system.  I am looking into how many packages this entails, but I know that I
maintain at least 50 or so such packages myself.  The issue of compiling 32-bit
code came up during the course of the bug report, but really is less of an
issue, in this case, since someone can quite easily do a stage3 install, then
go and install some binary package without compiling a single thing.

(In reply to comment #10)
> That would actually be fine, if we were talking about compiling 32-bit code. 
> We aren't.
> 
> This bug report has to do with *running* 32-bit code on a multilib x86_64
> system. 

No, this is bug is about the fact that amd64 multilib profiles do NOT work
without IA32 emulation enabled in kernel. By do not work, I seriously mean do
NOT work. Being unable to compile toolchain is not something you could call a
working profile no matter how many time you mumble something about your stage3
installs. 

So, lets forget some flash crap and focus on the real issue, and lets not use
nonsensical kernel checks that fail to check anything relevant.

wolf31o2@inertia /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64 $ grep jakub
*
wolf31o2@inertia /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64 $ grep
wolf31o2 *
index.xml:<dev role="Developer" description="games">wolf31o2</dev>

When you join the AMD64 team, let me know and I'll consider your input on this.
 Until then, I'm waiting to hear from the people I've actually asked since
their opinion on this actually matters to me and is going to be the basis of my
work on this issue.  Feel free to discuss your ideas with the AMD64 team and
get them to agree with you.  I'm not interested in the opinion of someone who
will not be supporting whatever changes are made, if any.  As such, I'll be
waiting for the respective team to come to a decision.

So I am thinking of adding a "check_ia32" (or whatever, name doesn't matter)
function to multilib.eclass, since that seems like the most likely location for
it.  I'm willing to put in the work to add the check to any ebuilds which needs
it.  Does anyone from amd64 have any objections?

(In reply to comment #13)
> So I am thinking of adding a "check_ia32" (or whatever, name doesn't matter)
> function to multilib.eclass, since that seems like the most likely location for
> it.  I'm willing to put in the work to add the check to any ebuilds which needs
> it.  Does anyone from amd64 have any objections?
> 

This seems reasonable.  Please call it check_ia32_emulation so there is no
confusion as to what it does.

or "check_emulation_ia32" ...

any update on this? I just hit this problem with some other 32bit apps on
amd64. Let me know if there is any tedious work that needs to be done. I'll
gladly do it on a weekend. 

I was going to get back onto this over the next few days.  I've been terribly
swamped with work and the release and am just now starting to get a little free
time.

Why are we (devrel) CC on this?  We got added last November for no reason that
I can see.  Anyone object if I take us off?

11:45 < ColdWind> feel free to unCC devrel from #192286, there wasn't ever a
                  reason to CC you, and now there's even less since neither
                  wolf or jakub are around


Done.

Ehh... I'm still around and this is still on my TODO.  I'll put up a patch here
for the support once I get it done, then file bugs for the individual packages
that require it.