Hi all, (Hopefully this is the right place to report this stuff.) Just letting you know that there's a new nspluginwrapper upstream release. I've taken over maintenance from the original maintainer with his blessing. https://www.redhat.com/archives/nspluginwrapper-devel-list/2011-April/msg00003.html There now exists 1.3.2 which fixes many many bugs and resolves most of the piles of patches distributions had been maintaining on top of the last release. https://www.redhat.com/archives/nspluginwrapper-devel-list/2011-April/msg00006.html I haven't had the time to set up a website or anything fancy yet, but there is a release tarball and git repo. Just re-using the original mailing list. Reproducible: Always
As you are upstream, have you take a look on Gentoo patches to try to upstream them? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-plugins/nspluginwrapper/files/
Gentoo's was among the set of patches I looked through. I believe I processed all of them, but you may want to verify it as I don't necessarily know the context behind each patch; I ended up having to rework several since I reorganized the Makefile a bit. I also have not killed the bundled lsb-build hack, which I believe one of your patches did, so if you still need that you'll need to keep that patch. (It's not clear to me how to do that properly. I probably want to have options for two sets of pkg-config paths. All the patches to the effect I've seen thus far assume that 32-bit GTK cflags/ldflags and 64-bit ones are the same, which is not actually true. glib installs one header file, glibconfig.h, with platform-specific #defines. Not that I'm terribly happy about the bundled lsb-build either.)
=www-plugins/nspluginwrapper-1.4.0 is now in the tree. It appears that the only patch from 1.3.0 that did not make it upstream is nspluginwrapper-1.3.0-gdk-native-windows.patch I also added a new patch that fixes parallel make on "make install".
(In reply to comment #3) > =www-plugins/nspluginwrapper-1.4.0 is now in the tree. It appears that the only > patch from 1.3.0 that did not make it upstream is > nspluginwrapper-1.3.0-gdk-native-windows.patch An equivalent patch from Ubuntu made it upstream. I ended up taking that one because it only applied to libflashplayer, which seemed better. Though the place Ubuntu picked to apply the change (somewhere in the Makefile) was very poor; I've since moved it to npw-viewer.sh in master. (Really, this is the browser's job to fix anyway; an nspluginwrapper-less Flash has the same problem. I believe Firefox and Chrome both set the variable these days, but I'm happy to keep it in nspluginwrapper too for now.) > I also added a new patch that fixes parallel make on "make install". Cool. I will take a look at it. By the way, I just skimmed your ebuild. One thing I noticed: you have a line that says inst_plugin "/usr/$(get_libdir)/${PN}/x86_64/linux/npwrapper.so" This installs npwrapper.so as a Mozilla plug-in, correct? You actually do not want to that. npwrapper.so is the template plug-in used to create wrappers. Unfortunately, it looks like a real plug-in since all the config tool does is write a path somewhere. You don't want to be loading it. There are checks to prevent it from doing anything in the NPAPI entry points, but one of them was broken. That combined with a change in 1.4.0 made npwrapper.so crash WebKitGtk-based browsers; they probe plug-ins differently (and less efficiently) from everyone else. I've since fixed the crash in master[1], but I do not believe it affects most distributions, so I didn't think it worth making a new release just for it; npwrapper.so isn't installed where any browser will look for it, and I believe this packaging bug is not common. You'll want to remove that line. Sometime I'll see about corrupting the ELF header or something on npwrapper.so so no one will even try to load it. [1] https://github.com/davidben/nspluginwrapper/commit/e87d49bdd6d3f66aba9fa22c7a05b90b3817b460
Ok, I committed a -r1 ebuild that doesn't install npwrapper.so as a plugin.
