Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 256259 - www-plugins/nspluginwrapper should allow native wrapping
Summary: www-plugins/nspluginwrapper should allow native wrapping
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement with 1 vote (vote)
Assignee: Patrick McLean
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-25 00:49 UTC by Kevin Bowling
Modified: 2018-03-24 16:14 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
nspluginwrapper-1.2.2-r2 patch (npw.diff,1.66 KB, patch)
2009-10-07 15:12 UTC, Nguyen Thai Ngoc Duy
Details | Diff
nspluginwrapper-1.2.2-r1 patch (npw-2.patch,1.90 KB, patch)
2009-10-08 05:01 UTC, Nguyen Thai Ngoc Duy
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Bowling 2009-01-25 00:49:26 UTC
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
Comment 1 Kevin Bowling 2009-01-25 01:05:53 UTC
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?
Comment 2 Patrick McLean gentoo-dev 2009-08-21 14:53:45 UTC
If you provide a patch that works, I would be happy to include it.
Comment 3 Nguyen Thai Ngoc Duy 2009-10-07 15:12:01 UTC
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)
Comment 4 Nguyen Thai Ngoc Duy 2009-10-08 05:01:28 UTC
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.
Comment 5 Pacho Ramos gentoo-dev 2009-11-04 21:52:01 UTC
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 :-/
Comment 6 Pacho Ramos gentoo-dev 2009-11-07 21:24:20 UTC
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
Comment 7 Pacho Ramos gentoo-dev 2009-11-28 15:18:51 UTC
(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?


Comment 8 Nguyen Thai Ngoc Duy 2009-11-29 08:52:37 UTC
> -       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.
Comment 9 Patrick McLean gentoo-dev 2011-05-26 17:58:18 UTC
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.
Comment 10 Pacho Ramos gentoo-dev 2011-05-26 19:35:19 UTC
I think this is still needed for browsers like epiphany :/
Comment 11 Pacho Ramos gentoo-dev 2011-05-31 11:15:58 UTC
(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
Comment 12 Pacho Ramos gentoo-dev 2012-04-18 08:47:57 UTC
Would also help on cases like mixing gtk2 plugins on gtk3 based browsers (recently talked about this problem with Samuli on IRC)
Comment 13 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2018-03-24 16:14:36 UTC
The package had been removed long ago.