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
snip
./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]
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/package.links file
* debian/rules: uncomment or remove the commented out dh_* calls
* debian/rules: dh_installman can use debian/package.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]
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
