Re: RFC: gnash (FSF Free Flash Player)
On Tue, 2006-04-18 at 13:02 +0200, Miriam Ruiz wrote: > Gnash is not ready for uploading to SID yet, I'm considering putting > it into experimental. Please do! Thanks for taking on this package. > The last packages I've made are available at > http://baby.yi.org/packages/gnash/ Some comments: * debian/control: extra space on the first line of the third para of the long description * debian/control: shockwave is different to flash, please see these links. http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_13971 http://webmonkey.wired.com/webmonkey/99/27/index3a.html?tw=multimedia http://www.google.com/search?q=shockwave+vs+flash * debian/control: gnash is not binNMUable due to libgnash-dev strictly depending on libgnash0 (= ${Source-Version}). * debian/control: xlibmesa-gl-dev, libglu1-xorg-dev, are transition packages * debian/control: about mozilla-dev, generally, xulrunner is being moved to these days, is that something that is possible for the plugin? I'd love to be able to try this in galeon/epiphany. * debian/rules: you forget to run this in the clean target: make -C debian/h2m clean * debian/rules: might want to use a more standard patch system than something homegrown. I'd suggest quilt or dpatch. The patch target doesn't seem to be used or do anything. * debian/rules: contains some extraneous comments and blank lines * debian/rules: does the upstream automake stuff really not create correct directories? * debian/rules: the ln -s calls can be replaced with a dh_link call and a debian/.links file * debian/rules: uncomment or remove the commented out dh_* calls * debian/rules: dh_installman can use debian/.manpages * debian/rules: would be good to run the test suite (if it is automated). you should also check in the test suite for files that are non-free or .swf files that have no source code. some suspect files: green.jpg lynch.jpg offspring.jpg elvis.swf. not sure about vnc2swf.swf, I suppose that vnc2swf embeds copyrighted parts of itself into swf files it creates? * debian/*.install: no need to do usr/bin/*, usr/bin works too * debian/copyright: you miss out copyright years. you miss out copyright info for several copyright holders. * debian/copyright: the documentation is under the GFDL (no invariants/fc/bc - free according to the latest GR), but you miss that info. * debian/copyright: please use grep and mc to go through this code with a fine tooth comb for copyright info. be also good to know if there are any patents on flash. * debian/docs: would be good to install AUTHORS and maybe libamf/README (as README.amf) too * since the player can be run standalone, it would be good to add a menu file and uncomment dh_installmenu in the debian/rules. A .desktop file would be good too. * Might want to modify the upstream README with sed or something during the build process to remove the section about building it. * might want to add a debian/watch file once they make a release * Interesting that upstream provides their own packaging packaging/debian/. I see that they provide a separate konqueror plugin package, any reason to differ there? * The package FTBFS today in pbuilder (with modular X). you might want to use dpkg-genbuilddeps/dpkg-depcheck and pbuilder to investigate: i486-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.0.3/crtbeginS.o .libs/plugin.o -Wl,--rpath -Wl,/tmp/buildd/gnash-0.0.20060418/plugin/mozilla-sdk/.libs -Wl,--rpath -Wl,/tmp/buildd/gnash-0.0.20060418/backend/.libs -Wl,--rpath -Wl,/tmp/buildd/gnash-0.0.20060418/server/.libs -Wl,--rpath -Wl,/tmp/buildd/gnash-0.0.20060418/libgeometry/.libs -Wl,--rpath -Wl,/tmp/buildd/gnash-0.0.20060418/libbase/.libs -L/usr/lib -L/usr/lib/gnash -lXi /usr/lib/libSDL.so -lGL -lGLU /usr/lib/libcairo.so /usr/lib/libxml2.so -lz /usr/lib/libjpeg.so -lpng /usr/lib/libogg.so mozilla-sdk/.libs/libmozsdk.so ../backend/.libs/libgnashbackend.so ../server/.libs/libgnashasobjs.so ../server/.libs/libgnashserver.so ../libgeometry/.libs/libgnashgeo.so ../libbase/.libs/libgnashbase.so /usr/lib/libSDL_mixer.so -lrt -lX11 -lXmu -L/usr/lib/gcc/i486-linux-gnu/4.0.3 -L/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib -L/usr/lib/gcc/i486-linux-gnu/4.0.3/../../.. -L/lib/../lib -L/usr/lib/../lib -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i486-linux-gnu/4.0.3/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crtn.o -Wl,-soname -Wl,libgnashplugin.so -o .libs/libgnashplugin.so /usr/bin/ld: cannot find -lXi collect2: ld returned 1 exit status make[4]: *** [libgnashplugin.la] Error 1 ma
Re: RFC: gnash (FSF Free Flash Player)
On Wed, 2006-04-19 at 02:31 +0800, Paul Wise wrote: > Some comments: > * debian/copyright: I forgot to point out this mail: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: RFC: gnash (FSF Free Flash Player)
--- Paul Wise <[EMAIL PROTECTED]> escribió: > Some comments: Thanks a lot for your comments on the package, they have been really useful!! > * debian/control: gnash is not binNMUable due to libgnash-dev > strictly depending on libgnash0 (= ${Source-Version}). What should I do in this case? just depend on libgnash0 without the version? wasn't they going to solve this problem in some way? > * debian/control: about mozilla-dev, generally, xulrunner is being > moved to these days, is that something that is possible for the > plugin? I'd love to be able to try this in galeon/epiphany. I haven't ever had a look at xulrunner but it seems to be interesting. The plugin should be compatible with any browser that supports mozilla plugins I guess. Is there a standard way to handle that? > * debian/rules: might want to use a more standard patch system > than something homegrown. I'd suggest quilt or dpatch. The patch > target doesn't seem to be used or do anything. I'm using that just because as I'm depending on CVS version it's much easier to be using patches, but I plan to remove that when a release version appears, so I don't wanna complicate it much. I've fixed a lot of things, I guess the packages are almost finished for now. I just have to know what to do with a lintian warning: W: klash: binary-or-shlib-defines-rpath ./usr/lib/kde3/libklashpart.so /usr/lib:/usr/share/qt3/lib N: N: The binary or shared library defines the `RPATH'. Usually this is a N: bad thing. Most likely you will find a Makefile with a line like: N: gcc test.o -o test -Wl,--rpath N: or N: gcc test.o -o test -R/usr/local/lib N: Please contact debian-devel@lists.debian.org if you have questions N: about this. N: ./usr/lib/kde3/libklashpart.so is a plugin for konqueror, an it seems to depend on the libraries at /usr/share/qt3/lib. As this is the first konqueror plugin I package, I don't know if it's something usual or not. Does somebody out there have a hint? Greetings and lots of thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: gnash (FSF Free Flash Player)
On Fri, 2006-04-21 at 00:49 +0200, Miriam Ruiz wrote: > > * debian/control: gnash is not binNMUable due to libgnash-dev > > strictly depending on libgnash0 (= ${Source-Version}). > > What should I do in this case? just depend on libgnash0 without the version? > wasn't they going to solve this problem in some way? I'm not sure exactly, but there was a thread recently about this. I think making the relation >= would do it. Otherwise, you can use dpkg-parsechangelog and sed to create a new variable, which you pass to dh_gencontrol using -V (and use that in the control file). > > * debian/control: about mozilla-dev, generally, xulrunner is being > > moved to these days, is that something that is possible for the > > plugin? I'd love to be able to try this in galeon/epiphany. > > I haven't ever had a look at xulrunner but it seems to be interesting. The > plugin should be compatible with any browser that supports mozilla plugins I > guess. Is there a standard way to handle that? Not really sure, I'd suggest asking the xulrunner/firefox/galeon/etc maintainers. There may be an l.d.o or l.alioth.d.o list for that. > W: klash: binary-or-shlib-defines-rpath ./usr/lib/kde3/libklashpart.so > /usr/lib:/usr/share/qt3/lib > ./usr/lib/kde3/libklashpart.so is a plugin for konqueror, an it seems to > depend on the libraries at /usr/share/qt3/lib. As this is the first konqueror > plugin I package, I don't know if it's something usual or not. Does somebody > out there have a hint? On my unstable system, /usr/share/qt3/lib only contains symlinks to files in /usr/lib, so presumably you can turn off the rpath with no ill effects. I don't know if this is the correct thing to do, I'd suggest asking on the debian qt/kde list about it. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: RFC: gnash (FSF Free Flash Player)
On Fri, Apr 21, 2006 at 12:49:35AM +0200, Miriam Ruiz <[EMAIL PROTECTED]> wrote: > > * debian/control: about mozilla-dev, generally, xulrunner is being > > moved to these days, is that something that is possible for the > > plugin? I'd love to be able to try this in galeon/epiphany. > > I haven't ever had a look at xulrunner but it seems to be interesting. The > plugin should be compatible with any browser that supports mozilla plugins I > guess. Is there a standard way to handle that? If you want the plugin built with xulrunner with any browser (including the current firefox and mozilla), you'll have to not link against the xulrunner libraries. The symbols will be already loaded by the browser anyway, so there won't be a symbol resolution problem. But if you link, there will be two version of the same symbols in memory and big problems. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]