Project still maintained?

Sat Mar 26 06:31:15 UTC 2011

As a status update, I've added a quick fix to the compile problem (just 
define the missing stubs) though I'm not terribly happy about that. I 
still haven't gone through the rest of the patches yet, but I've started 
doing some hacking of my own.

I've updated the NPAPI headers and have been slowly adding thunks for the 
the new functions. In particular, plugins that use 
NPN_PluginThreadAsyncCall can now run, and NPNVprivateModeBool no longer 
returns a bogus value. (This work is on branch npapi-upgrade.) It also now 
implements all of the NPClass hooks, so NPClass::construct and 
NPClass::enumerate now work. It's not clear Flash uses any of these but 
NPNVprivateModeBool though. :-)

David

On Sun, 13 Mar 2011, David A Benjamin wrote:

> On Wed, 9 Mar 2011, Evan Martin wrote:
>> It might be worth trying to track down the original developer explicitly.
>> Otherwise, I fully endorse you merging the patches and fixing bugs.
>
> Yeah, I sent an email to the address listed in the README (gb.public at free.fr) 
> a week before sending the one to this list, actually. I haven't heard back. I 
> can try looking for other ways of reaching him.
>
>
> I've updated the master branch on my git repository to include all the 
> tarballs I've found so far. (Pulled from a combination of Debian, Fedora, 
> Ubuntu, and Wayback machine archives.) I've also started going through some 
> of the more obvious patches in random order, but I'm by no means finished. 
> (So far my queue contains patches from Debian, Fedora, Gentoo, OpenSUSE, and 
> Ubuntu.) If nothing else, I've yet to even fix the problem that the tarball 
> doesn't build in the first place. :-)
>
> I'm not totally sure what the best way to deal with that is. There's some 
> stub lsb-build thing in here which doesn't link because it doesn't include 
> the entry points needed for -fstack-protector or so in libgcc (?). Seems 
> people have been either patching it out or putting in the missing stubs, and 
> the Changelog suggests the latter has been done a lot anyway. I'm tempted to 
> punt it altogether or at least update to an unforked newer lsb-build. The 
> former is probably saner; it seems wrong to keep it without also using their 
> compiler config and whatnot. But the Changelog says it was added back in 2006 
> "so that to help non-multiarch capable x86-64 distributions to build the 
> 32-bit viewer". Dunno how much that still applies today.
>
> https://github.com/davidben/nspluginwrapper/commits/master
>
>
> David
>
>
>> On Sat, Mar 5, 2011 at 11:49 AM, David A Benjamin <davidben at mit.edu> wrote:
>>> Hi all,
>>> 
>>> So, is this project still being actively maintained? I was working on a
>>> crash that resulted from a race condition in nspluginwrapper[1]. I've
>>> written a patch[2] for it, but I can't find an upstream to send it to
>>> anymore? The website listed doesn't exist anymore (and I came across this
>>> list on accident googling). As far as I can tell, distros are just
>>> maintaining piles of patches on top of the most recent release. (I ended 
>>> up
>>> just filing bugs with a couple distros for my patch, but I'd rather not go
>>> hunt down all of them.)
>>> 
>>> In working on the fix, I think I've become mildly familiar with the code,
>>> and have worked on a simple NPAPI plugin of my own[3]. So, if this project
>>> is actually abandoned, I'm thinking of perhaps adopting it. I was thinking
>>> of starting out by looking at every distro's patchset, try to reconcile
>>> them, and put out a new release with the ones that seem reasonable. And I
>>> guess things can go from there. I wouldn't expect development to be hugely
>>> active and, if nothing else, consolidating all the conflicting distro
>>> patches would be a huge improvement from the current state of affairs.
>>> 
>>> So, if anyone's still on this list: Is this project really abandoned / 
>>> would
>>> a new upstream be helpful? Also, does anyone have a copy of the original
>>> repository this was kept in. Otherwise, hunting for tarballs should give a
>>> little history; I've found 0.9.91.5, 1.2.2, and 1.3.0.
>>> 
>>> Oh, I should probably disclaim: my interest in this project actually 
>>> working
>>> is that I need it to to run a 32-bit Flash on 64-bit Chrome. When Adobe 
>>> puts
>>> out a stable 64-bit Flash or Chromium implements the 64-bit/32-bit
>>> out-of-process translation itself[4], I won't use it anymore. But I guess
>>> the former condition applies to most using it, and the baton can be passed
>>> to someone else.
>>> 
>>> 
>>> David Benjamin
>>> 
>>> 
>>> [1] http://crbug.com/53940
>>> 
>>> [2] https://github.com/davidben/nspluginwrapper/commits/master
>>> 
>>> [3] https://github.com/davidben/embedded-emacs
>>> 
>>> [4] All this logic should be in the browser anyway; Chromium and Firefox
>>> have some limited freedom to make NPP calls asynchronous/reorderable.
>>> nspluginwrapper cannot by design as it speaks NPAPI on both ends. In
>>> particular, my fix for the NPP_Destroy race actually discards NPSavedData 
>>> in
>>> some cases because the NPP_Destroy must return earlier. Chromium 
>>> apparently
>>> doesn't implement NPSavedData at all, but that's not the point. :-)
>>> 
>>> _______________________________________________
>>> Nspluginwrapper-devel-list mailing list
>>> Nspluginwrapper-devel-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list
>>> 
>> 
>
> _______________________________________________
> Nspluginwrapper-devel-list mailing list
> Nspluginwrapper-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list
>