From davidben at mit.edu Sat Mar 5 19:49:54 2011 From: davidben at mit.edu (David A Benjamin) Date: Sat, 5 Mar 2011 14:49:54 -0500 (EST) Subject: Project still maintained? Message-ID: 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. :-) From stransky at redhat.com Wed Mar 9 12:09:12 2011 From: stransky at redhat.com (Martin Stransky) Date: Wed, 09 Mar 2011 13:09:12 +0100 Subject: Project still maintained? In-Reply-To: References: Message-ID: <4D776DE8.10402@redhat.com> Hi, AFAIK the project is abandoned. We (in Fedora) keep some patches to make the wrapper in some sane shape, but there are many missing bugs to fix or reimplement from scratch. I saw your repo at GitHub and I think it's a great idea to have a repository for it and maintain all patches here. ma. On 03/05/2011 08:49 PM, David A Benjamin 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 > From evan at chromium.org Wed Mar 9 18:10:31 2011 From: evan at chromium.org (Evan Martin) Date: Wed, 9 Mar 2011 10:10:31 -0800 Subject: Project still maintained? In-Reply-To: References: Message-ID: It might be worth trying to track down the original developer explicitly. Otherwise, I fully endorse you merging the patches and fixing bugs. On Sat, Mar 5, 2011 at 11:49 AM, David A Benjamin 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 > From davidben at mit.edu Sun Mar 13 20:48:53 2011 From: davidben at mit.edu (David A Benjamin) Date: Sun, 13 Mar 2011 16:48:53 -0400 (EDT) Subject: Project still maintained? In-Reply-To: References: Message-ID: 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 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 >> > From davidben at mit.edu Sat Mar 26 06:31:15 2011 From: davidben at mit.edu (David A Benjamin) Date: Sat, 26 Mar 2011 02:31:15 -0400 (EDT) Subject: Project still maintained? In-Reply-To: References: Message-ID: 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 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 > From davidben at mit.edu Thu Mar 31 23:42:38 2011 From: davidben at mit.edu (David A Benjamin) Date: Thu, 31 Mar 2011 19:42:38 -0400 (EDT) Subject: Nspluginwrapper Update Status Message-ID: Hi all, (WARNING: Long email. The more interesting stuff is at the end.) So, as I mentioned in the other thread, I'm interested in cleaning up this project and resolving the various patches distros have. Here's a status update, and some thoughts on what to do from here. Also if anyone wants to help me test or hack on this, go for it (let me know so I'll avoid rebasing the repo). I'm hoping to get input on from whoever's still on the list. The git repository is hosted here: https://github.com/davidben/nspluginwrapper I've updated the NPAPI headers and thunked up to 0.24 (Flash advertises NPAPI 0.23). I've got a branch for 0.25 which I can't test yet, so I'll do the rest later. npplayer I've left largely untouched as I'm not really interested in it and can't get it to work in the first place. :-) Passing --plugin and no other arguments causes a memory error (without my changes), and other attempts display nothing. I haven't spent much time on it though. Other than that, I've mostly been cleaning the build. It should now build fine with --as-needed and pkg-config is used for finding X11 and Xt. I've also made the configure script die on invalid option; Debian, Fedora, and Ubuntu actually call the configure script slightly wrong, and this kind of thing should be visible. The lsb-build headers are sadly still there. I'd like to kill then eventually, and did some refactoring to that end, but I'm not very happy with existing patches. They pull the host arch's LIBS and CFLAGS, and assume compatible headers and blind -L/usr/lib32 will work. I'd rather perhaps set a target arch PKG_CONFIG_PATH or so. May also be worth switching build system someday. (Maybe scons? I think it can handle building for multiple architectures at once by creating several Environment objects. Or maybe we can write a generator for ninja. :-D) The build fixes cover most of the existing distribution patches I've come across (Debian, Fedora, Gentoo, OpenSUSE, Ubuntu). I've merged the others that look fine to me, but some are more questionable, and I'd like some feedback on. First is a fairly boring batch from Fedora that decreases the RPC timeout from 30 seconds to 10. The git commit says "Changed RPM [sic] timeout to 10 second, should prevent long browser hangs." Martin, you're on this list right? What was the original reason for this change? Both numbers are absurdly long for UI. Was this in case the plugin process exited or hung? If exited, the wrapper instead detect a crashed viewer better. If hung, it's not really hanging any more than would normally. I'd like to not focus on trying to improve the plugin and only recommend nspluginwrapper when your plugin is the wrong architecture. Both Chromium and Firefox already push plugins out of process, presumably already with hang/timeout logic, so this is just an extra source of bugs (and generally makes good on promises there). The last patches are Debian, Fedora, and Ubuntu's changes to wrapper management. I've made (rambly) notes on what I can understand of the logic here: (If I'm wrong on any of this, feel free to correct me.) http://web.mit.edu/davidben/Public/nspluginwrapper-directory-patches.txt As a summary, the original logic seems to mostly work, but it's not the most robust. Fedora's patch amounts to letting the caller pick the resulting location of the wrapped browser. And then there's some other tool in C that calls it? Debian and Ubuntu try to implement some kind of symlinking logic and other things by patching them in. I'm not enthusiastic about merging any of the three as they may mesh badly with the existing flimsy logic. (What happens if you try to update all your plugins but passing a different --dir?) Looking at Fedora's situation however, what if instead npw-config.c gets hacked to pieces and we add some npconfig binary with commands like npconfig is_plugin PLUGIN, npconfig is_wrapper WRAPPER, npconfig install_wrapper PLUGIN WRAPPER, etc. Then Fedora's plugin-config tool can be written in shell (or Python or whatever), and likewise Debian and Ubuntu can write their own things. Upstream can probably provide one compatible with the original for distros that didn't change it and maybe improve it later. I'd love to stop this madness where every distro does paths differently, but I don't think nspluginwrapper can fix this. And in the meantime, people have not yet agreed on a coherant way to discover and install multiarch plugins. So, what are folks' thoughts about that? And if this is reasonable, should it be done now, or would it be better to save this for 1.6.0? It probably wouldn't be an insane amount of work, but it does also mean more friction for packagers to build the new ones. And possibly more sources for incompatibilities. I think this issue is the last on my list, other than further buildsystem cleanup (--with-lib32 is completely unused, and --with-lib64's remaining usage could maybe be replaced with LIBDIR or something). I was also going to see what other nspluginwrapper bugs in Chromium's tracker I can fix. And then I guess I can maybe make some final attempt to contact the original author and eventually get a 1.4.0 out for all to enjoy. David