Ok, this is my first package in debian so I'm still getting used to things.
My thinking is that this package depends on external APIs (the hosting websites) and so it is a good candidate for backports. I hope to be able to add new upstream versions there in addition to unstable. I know that version 2 doesn't handle javascript differently, but it does have a different philosophy about modules and who is responsible for them, so I want to think about what is reasonable with that situation. I see that rhino in stable has a -sandbox switch. I know very little about rhino, and I'll have to check to see exactly what promises this mode makes, but it might be sufficient. The documentation is very vague so I'm not confident about this. As for the version of plowshare in stable: it will become increasingly irrelevant as the API implementations gradually break. I would expect that anyone making serious use of it would be after the latest versions anyway rather than relying on the stable version. As such, disabling the javascript support entirely is probably acceptable and is certainly the most definitive fix. I expect it to at least partially break something of order 10 modules, but I'll test out this solution shortly. Carl -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
