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 attachment 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.
After reading the bug, looks like this is not a emul packages set problem as this is more general
What more are we expected to fix here?
*** Bug 820758 has been marked as a duplicate of this bug. ***
