It appears that the nspluginwrapper ebuild is not sufficient to install native wrapping capability. Doing native wrapping is beneficial because plugins will not crash the browser, and we can begin to think of additional security jails for plugins. kev-ws-amd64 ~ # nspluginwrapper --verbose --native --install /opt/netscape/plugins/libflashplayer.so *** NSPlugin Viewer *** ERROR: /opt/netscape/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64 nspluginwrapper: no appropriate viewer found for /opt/netscape/plugins/libflashplayer.so Reproducible: Always
The configure script lists '--enable-biarch', while the ebuild uses '--with-biarch'. This change alone does not fix the problem though. Likely, things will need to now be intelligently installed into lib32 and lib64?
If you provide a patch that works, I would be happy to include it.
Created attachment 206333 [details, diff] nspluginwrapper-1.2.2-r2 patch Here is something that works for me (tested with swfdec-mozilla, sadly adobe flash failed)
Created attachment 206402 [details, diff] nspluginwrapper-1.2.2-r1 patch It was the problem with my machine. nspluginwrapper works for me on another machine. Someone needs to test it against amd64 as I have none. Sorry I don't have -r2 here to patch against.
I have just tried the patch but seems that plugin is not properly detected, as I get the following from about:plugins under firefox: NPAPI Plugins Wrapper 1.2.2 Nombre del fichero: npwrapper.so nspluginwrapper is a cross-platform NPAPI plugin viewer, in particular for linux/i386 plugins. This software is available under the terms of the GNU General Public License. Tipo MIME Descripción Sufijos Habilitado unknown/mime-type Do not open none Sí Shockwave Flash Nombre del fichero: libflashplayer.so Shockwave Flash 10.0 r32 Tipo MIME Descripción Sufijos Habilitado application/x-shockwave-flash Shockwave Flash swf Sí application/futuresplash FutureSplash Player spl Sí Then, seems that native libflashplayer.so is still being used over nspluginwrapper one :-/
The problem is caused by "Remove wrappers if equivalent 64-bit plugins exist" section under "autoinstall()": --- nspluginwrapper-1.2.2-r2.ebuild~ 2009-11-04 22:46:28.000000000 +0100 +++ nspluginwrapper-1.2.2-r2.ebuild 2009-11-07 22:19:53.000000000 +0100 @@ -32,14 +32,14 @@ # Remove wrappers if equivalent 64-bit plugins exist # TODO: May be better to patch nspluginwrapper so it doesn't create # duplicate wrappers in the first place... - local DIR64="${ROOT}/usr/$(get_libdir)/nsbrowser/plugins/" - for f in "${DIR64}"/npwrapper.*.so; do - local PLUGIN=${f##*/npwrapper.} - if [[ -f ${DIR64}/${PLUGIN} ]]; then - einfo " Removing duplicate wrapper for native 64-bit ${PLUGIN}" - ${PN} -r "${f}" - fi - done It seems to be not needed and, after dropping it, nspluginwrapper is used even for 64 bits plugins, allowing to get a more stable browser when flash plugin crashes
(In reply to comment #4) > Created an attachment (id=206402) [details] > nspluginwrapper-1.2.2-r1 patch > > It was the problem with my machine. nspluginwrapper works for me on another > machine. Someone needs to test it against amd64 as I have none. Sorry I don't > have -r2 here to patch against. > Hi! Could you please explain me some lines from your patch? Thanks a lot - inst_plugin "/usr/$(get_libdir)/${PN}/x86_64/linux/npwrapper.so" - dosym "/usr/$(get_libdir)/${PN}/x86_64/linux/npconfig" "/usr/bin/${PN}" + local ARCH=i386 + use amd64 && ARCH=x86_64 + inst_plugin "/usr/$(get_libdir)/${PN}/${ARCH}/linux/npwrapper.so" + dosym "/usr/$(get_libdir)/${PN}/${ARCH}/linux/npconfig" "/usr/bin/${PN}" Why do you set "local ARCH=i386" ? pkg_postinst() { - autoinstall - elog "Any 32bit plugins you currently have installed have now been" - elog "configured to work in a 64bit browser. Any plugins you install in" - elog "the future will first need to be setup with:" - elog " \"nspluginwrapper -i <path-to-32bit-plugin>\"" - elog "before they will function in a 64bit browser" - elog + if use amd64; then + autoinstall + elog "Any 32bit plugins you currently have installed have now been" + elog "configured to work in a 64bit browser. Any plugins you install in" + elog "the future will first need to be setup with:" + elog " \"nspluginwrapper -i <path-to-32bit-plugin>\"" + elog "before they will function in a 64bit browser" + fi } Are you sure this will work also on x86? I mean, will plugins be wrapped also under x86?
> - inst_plugin "/usr/$(get_libdir)/${PN}/x86_64/linux/npwrapper.so" > - dosym "/usr/$(get_libdir)/${PN}/x86_64/linux/npconfig" "/usr/bin/${PN}" > + local ARCH=i386 > + use amd64 && ARCH=x86_64 > + inst_plugin "/usr/$(get_libdir)/${PN}/${ARCH}/linux/npwrapper.so" > + dosym "/usr/$(get_libdir)/${PN}/${ARCH}/linux/npconfig" > "/usr/bin/${PN}" > > Why do you set "local ARCH=i386" ? Or you could do it like "if use amd64; then ARCH=x86_64; else ARCH=x86;fi". I take it nspluginwrapper only works on x86/x86_64 architectures? > > pkg_postinst() { > - autoinstall > - elog "Any 32bit plugins you currently have installed have now been" > - elog "configured to work in a 64bit browser. Any plugins you install > in" > - elog "the future will first need to be setup with:" > - elog " \"nspluginwrapper -i <path-to-32bit-plugin>\"" > - elog "before they will function in a 64bit browser" > - elog > + if use amd64; then > + autoinstall > + elog "Any 32bit plugins you currently have installed have now > been" > + elog "configured to work in a 64bit browser. Any plugins you > install in" > + elog "the future will first need to be setup with:" > + elog " \"nspluginwrapper -i <path-to-32bit-plugin>\"" > + elog "before they will function in a 64bit browser" > + fi > } > > Are you sure this will work also on x86? I mean, will plugins be wrapped also > under x86? Not sure at all. That's why I left it out.
This is no longer necessary for either Firefox or Chromium as Firefox does this internally now, and Chromium runs each tab as a separate process, thus making it much more difficult for a plugin to crash the browser.
I think this is still needed for browsers like epiphany :/
(In reply to comment #10) > I think this is still needed for browsers like epiphany :/ Yes, epiphany tends to crash a lot due flash crashing on multiple sites :S
Would also help on cases like mixing gtk2 plugins on gtk3 based browsers (recently talked about this problem with Samuli on IRC)
The package had been removed long ago.
