[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: 0ad





On Mon, Apr 4, 2011 at 5:43 AM, Karl Goetz <karl@kgoetz.id.au> wrote:
On Sun, 3 Apr 2011 12:08:39 +0100
Philip Taylor <excors@gmail.com> wrote:

> On Sun, Apr 3, 2011 at 11:00 AM, Karl Goetz <karl@kgoetz.id.au> wrote:
> > On Sat, 2 Apr 2011 21:59:59 -0700
> > I've left all the CCs in; should they all be maintained, or can
> > some be dropped?
> >
> > [...]
> > ./binaries/data/tests/collada/sphere.pmd
> >  - its a data file, and i can't see a free software tool to open
> > this.
>
> It's the game's custom format for mesh data
> (http://trac.wildfiregames.com/wiki/PMD_File_Format).
>
> (Old models only exist in .pmd format. New models exist in editable
> Collada (.dae) format in SVN, and the game automatically converts and
> caches as .pmd for more efficient loading. That particular
> tests/collada/sphere.pmd file is just used for tests of the cache
> loading code - the other .pmd files are inside public.zip.)

So it can be modified by the game/related tools?

> > ./libraries/spidermonkey-tip/src/js.mdp
> >  - its a data file, and i can't see a free software tool to open
> > this.
>
> It'd be best for the game to not bundle a copy of SpiderMonkey (so
> this becomes somebody else's problem). I think that should be possible

This would be best.

> now, since https://bugzilla.mozilla.org/show_bug.cgi?id=628723 gives a
> relatively stable modern version - just need to do a bit of work to
> port the game to the latest version of the API. I can probably get
> that done for the next alpha release of the game.

Vincent, how do you feel about ITPing that too?

Isn't spidermonkey already available in Debian? If possible, I would rather avoid filing an ITP; rather, I'd prefer including libmozjs-dev as a build dependency for 0 A.D (and work with the Debian Mozilla crew if any changes have to be made to libmozjs in order for 0 A.D. to get along with it).
 
> > ./binaries/data/tools/fontbuilder/fonts/*
> >  - this doesn't appear in d/copyright; because they're not installed
> > from here?
> >  - i note that there is a comment in there to this effect "The
> > Converted... fonts were produced by opening the originals in
> > FontForge 20090923, changing the names, and exporting as
> > TrueType.". problem for debian?
>
> Those files aren't used in the build or installation at all, they're
> just used by an offline tool that converts them to PNGs (so it was
> convenient to keep the original font files in SVN and they're not
> explicitly excluded from the release tarballs).

Are these the original? the comment implies they are not.

> > ./binaries/data/mods/public/public.zip
> >  - is this meant to be sitting around as a zip, or extracted by
> > something at unpack? Could this be related to the lack of files in
> > binaries/data/mods/ ? The copyright file says there is an art/ and
> > an audio/ dir in there.
>
> It's meant to be installed as a zip (kind of like Quake's PK3 files).
> The game's LICENSE.txt file refers to paths in SVN (where they're not

This is probably where the problem in debian/copyright comes from then.

0 A.D. runs fine with public.zip installed as a zip, so I'm assuming that there's no need to unzip it prior to packaging and installing it. Do I have to account for all the contents of the zip in debian/copyright, and if so, how would I go about doing that?
 
> in a zip). The release-building process finds all the files in
> binaries/data/mods/public/, does some format conversions (PNG -> DDS
> etc), then saves everything into public.zip. Any suggestions on how to
> state the copyright status more clearly?

Not sure; mentors, is there a best way for this?

> > ./libraries/fcollada/src/FCollada/FColladaTest/Samples/Copyright.txt
> > ./libraries/fcollada/src/FCollada/FColladaTest/Samples/Eagle.DAE
> >  - according to the Copyright file, Eagle.DAE is non-free.
>
> It'd be best for the game to not bundle a copy of FCollada. See
> http://trac.wildfiregames.com/ticket/562 - I don't know how long it's
> likely to be before that's integrated and working, though.
>
> In the meantime, it's safe to delete those files from a release (since
> the FCollada tests don't get run automatically; they're only useful
> when people are developing FCollada itself).

Any chance you could stop shipping the DAE file? otherwise debian will
have to repack the tarball.
thanks,
kk



Actually, I have to repack the tarball anyways in order to have 0ad and 0ad-data build from the same source package, although they're offered as 2 separate source packages upstream.

Also, since fcollada tests aren't run automatically, should i simply just remove those files from my source tarball (along with dbghelp)? I don't want to have to modify the source tarball too much, but it is simply much easier than trying to make sure that every potential copyright/licensing issue is adressed.

- Vincent

Reply to: