RFS: 0ad
Vincent Cheng
Paul Wise
(CCing you since I'm not sure which lists you are on if any, sorry for
any duplicate mail)
Looks like you are taking over the ITPs owned by Bertrand Marc, with
his permission.
Bertrand was maintaining the packaging in the games team's SVN
repository, but you don't seem to have updated the SVN repository with
your changes. In addition your package doesn't have the games team in
the Maintainer field. Do you intend to join the games team or should
we delete Bertrand's packaging from our SVN repository?
If you are interested in joining the games team, please check our wiki
pages, jump on IRC, say hi and we will give you a quick run-down on
our team practices.
The team is having a meeting soon, please check these pages:
http://lists.debian.org/4D8B6722...@debian.org
http://wiki.debian.org/Games/Meetings/2011-04
http://www.doodle.com/q9aguzv2vx9qdrwn
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTi=PLfc9mzu3Xy7n...@mail.gmail.com
Karl Goetz
Vincent Cheng <vincen...@gmail.com> wrote:
> Dear mentors,
Not sure if all the CCs are required, so preserving them.
> I am looking for a sponsor for my package "0ad".
>
> * Package name : 0ad
> Version : 0~r09049~alpha4-1
> Upstream Author : Wildfire Games
> * URL : http://wildfiregames.com/0ad/
> * License : GPL, LGPL, MIT
> Programming Lang: C++
> Description : 3D real-time strategy (RTS) game of ancient
> warfare Section : games
Is there code distributed under the terms of license_dbghelp.txt in
this package? It would appear to be non-dfsg compliant, so may cause
you problems.
thanks,
kk
--
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group
Vincent Cheng
Hi Vincent,
(CCing you since I'm not sure which lists you are on if any, sorry for
any duplicate mail)
Looks like you are taking over the ITPs owned by Bertrand Marc, with
his permission.
Bertrand was maintaining the packaging in the games team's SVN
repository, but you don't seem to have updated the SVN repository with
your changes. In addition your package doesn't have the games team in
the Maintainer field. Do you intend to join the games team or should
we delete Bertrand's packaging from our SVN repository?
If you are interested in joining the games team, please check our wiki
pages, jump on IRC, say hi and we will give you a quick run-down on
our team practices.
The team is having a meeting soon, please check these pages:
http://lists.debian.org/4D8B6722...@debian.org
http://wiki.debian.org/Games/Meetings/2011-04
http://www.doodle.com/q9aguzv2vx9qdrwn
--
bye,
pabs
http://wiki.debian.org/PaulWise
Vincent Cheng
Karl Goetz
Vincent Cheng <vincen...@gmail.com> wrote:
Hi vincent,
I've left all the CCs in; should they all be maintained, or can some be
dropped?
> Dear mentors,
>
> I am looking for a sponsor for my package "0ad".
> Description : 3D real-time strategy (RTS) game of ancient
> warfare Section
Could you double check the following things? Not sure how many of them
are real problems, but would be good to have checked.
(I'm not sure if my check is correct).
./binaries/data/tests/collada/sphere.pmd
- its a data file, and i can't see a free software tool to open this.
./libraries/spidermonkey-tip/src/js.mdp
- its a data file, and i can't see a free software tool to open this.
./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?
./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.
./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.
Appears to be a different licence to stated in d/copyright:
./libraries/spidermonkey-tip/src/dtoa.c
./libraries/spidermonkey-tip/src/jsgcchunk.cpp
./libraries/spidermonkey-tip/src/config/mkdepend/*
./libraries/spidermonkey-tip/src/config/mkdepend/Makefile.in
./libraries/spidermonkey-tip/src/assembler/*
./libraries/spidermonkey-tip/src/yarr/pcre/
./libraries/spidermonkey-tip/ being MPL-1.1 and GPL-2.0 and LGPL-2.1
- the (L)GPL mentioned in the headers is 'or later'
I didn't dig into source/.
Philip Taylor
> On Sat, Apr 2, 2011 at 11:08 PM, Karl Goetz <ka...@kgoetz.id.au> wrote:
>> Not sure if all the CCs are required, so preserving them.
>>
>> Is there code distributed under the terms of license_dbghelp.txt in
>> this package? It would appear to be non-dfsg compliant, so may cause
>> you problems.
>
> license_dbghelp.txt are in source/lib/external_libraries/dbghelp.cpp,
> dbghelp.h, dbghelp_funcs.h, but I'm not sure if they're used during the
> build. Hmmm...I'll try re-building 0ad with those files removed from the
> source tarball and see if the build still works.
> - Vincent
dbghelp is only used for Windows.
I believe the only subdirectories of libraries/ that are needed for
building on Linux are:
* cxxtest
* fcollada
* valgrind
* spidermonkey-tip
* nvtt (unless building with "./update-workspaces.sh
--with-system-nvtt", which requires
http://code.google.com/p/nvidia-texture-tools/ version 2.0.9+ (not
released))
If you're using the -build tarballs from
http://releases.wildfiregames.com/ then all the other stuff under
libraries/ in SVN should have been removed already.
(source/tools/dist/build.sh does the relevant work.)
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimMzrNNv9nTw+2ER...@mail.gmail.com
Philip Taylor
> On Sat, 2 Apr 2011 21:59:59 -0700
> 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.)
> ./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
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.
> ./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).
> ./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
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?
> ./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).
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimpRZoMu6hqihAYw...@mail.gmail.com
David Paleino
> Dear mentors,
>
> I am looking for a sponsor for my package "0ad".
>
> * Package name : 0ad
> [..]
>
> My motivation for maintaining this package is: Even though 0 A.D. is still
> in Alpha, it is still playable (and also very fun if you like RTS games). I
> would like to package and maintain 0 A.D. so that fellow Debian users can
> also enjoy this game as well.
I haven't checked the package, but given I'd like to play it, I tried to build
it, and it FTBFS because of libenet. It seems like it wants libenet0 (1.2.*),
but in Debian we have libenet1a (1.3*).
The parallel jobs make it a bit difficult to find the error, since it's buried
by tons of other successful compilations, but here it is:
g++ -g -O2 -MMD -D "LIB_STATIC_LINK" -D "INSTALLED_BINDIR=/usr/games" -D
"INSTALLED_DATADIR=/usr/share/games/0ad" -D "INSTALLED_LIBDIR=/usr/lib/games/0ad" -D "NDEBUG" -D "CONFIG_FINAL=1" -D "USING_PCH" -I "/usr/X11R6/include/X11" -I "/usr/X11R6/include" -I "/usr/include/X11" -I "../../../source/pch/simulation2" -I "../../../source/" -I "../../../libraries/spidermonkey-tip/include-unix/release" -g -O3 -Wall -Wno-switch -Wno-reorder -Wno-invalid-offsetof -Wextra -Wno-missing-field-initializers -Wunused-parameter -Wredundant-decls -Wnon-virtual-dtor -Wundef -fstack-protector-all -D_FORTIFY_SOURCE=2 -fstrict-aliasing -fpch-preprocess -msse -fno-omit-frame-pointer -march=i686 -fvisibility=hidden -MF obj/simulation2_Release/Simulation2.d -MT obj/simulation2_Release/Simulation2.o -o obj/simulation2_Release/Simulation2.o -c -include obj/simulation2_Release/precompiled.h ../../../source/simulation2/Simulation2.cpp
In file included from ../../../source/network/NetServer.cpp:29:0:
../../../source/lib/external_libraries/enet.h:33:2: error: #error The game
currently requires ENet 1.2.x. You are using a newer version, which has an incompatible API and network protocol. Please switch to an older version.
../../../source/network/NetServer.cpp: In member function 'bool
CNetServerWorker::SetupConnection()':
../../../source/network/NetServer.cpp:118:52: error: too few arguments to
function 'ENetHost* enet_host_create(const ENetAddress*, size_t, size_t,
enet_uint32, enet_uint32)'
/usr/include/enet/enet.h:498:21: note: declared here
make[3]: *** [obj/network_Release/NetServer.o] Error 1
make[2]: *** [network] Error 2
make[2]: *** Waiting for unfinished jobs....
I could suggest either maintain a separate libenet0, or try to port 0ad to the
newer libenet (preferred, I'd say).
Kindly,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Scott Howard
> On Sat, 2 Apr 2011 21:59:59 -0700, Vincent Cheng wrote:
>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "0ad".
>>
>> * Package name : 0ad
>> [..]
> it, and it FTBFS because of libenet. It seems like it wants libenet0 (1.2.*),
> but in Debian we have libenet1a (1.3*).
I started looking at 0AD recently, just wanted to summarize some things I saw.
-libenet was just updated in debian less than a month ago. I don't
think upstream is planning on updating it soon, but someone form
either playdeb or Wildfire will have to do that since playdeb's
package and wildfire's compilation instructions for debian/ubuntu say
to grab libenet-dev to compile.
- As for inclusion in Debian: 0AD has some bundled library issues
(e.g. fcollada). The fcollada issue has been mentioned on this list
[1-2]. Basically fcollada was a library created by a company 10 years
ago with a GPL license. Since then the company stopped maintaining it
and removed it from their website. Many projects grabbed the latest
release and forked it for their own needs. There are at least 4 major
forks out there which are all hacked for individual projects (there
are many other patched versions, but it's hard to keep track). I tried
to merge all of the major changes together in a way that each project
can use, but each fcollada library is pretty much an independent
project now where significant work will be needed to get a single
library that everyone can use. Debian requires one canonical library,
and right now the only practical solution would be to have packages
for each of the major forks (which over the past 10 years have grown
incompatible with each other), but I don't think that is allowed.
Also, Wildfire/0AD needs an fcollada library which is compilable with
MSVC building DLLs for windows (which I am not interested in nor
capable of doing well.)
The last time 0AD was discussed on this list [1], objections were
raised about the inclusion of the fcollada library. If wildfire
produces the most recent and well-maintained fcollada library
available, does that one become the canonical fcollada library (and
should it be packaged as is from wildfire/0AD as the libfcollada in
debian?)
With the amount of work maintaining 0AD may need, you might want to
form a sub-team of debian-games to take care of it.
Cheers,
Scott
[1] http://lists.debian.org/debian-devel-games/2010/09/msg00005.html
[2] sorry can't find the l.d.o link:
http://groups.google.com/group/linux.debian.devel.mentors/browse_thread/thread/198b3d604613b17a
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTiNqThg+Kst...@mail.gmail.com
Russ Allbery
> - As for inclusion in Debian: 0AD has some bundled library issues
> (e.g. fcollada). The fcollada issue has been mentioned on this list
> [1-2]. Basically fcollada was a library created by a company 10 years
> ago with a GPL license. Since then the company stopped maintaining it
> and removed it from their website. Many projects grabbed the latest
> release and forked it for their own needs. There are at least 4 major
> forks out there which are all hacked for individual projects (there are
> many other patched versions, but it's hard to keep track). I tried to
> merge all of the major changes together in a way that each project can
> use, but each fcollada library is pretty much an independent project now
> where significant work will be needed to get a single library that
> everyone can use. Debian requires one canonical library, and right now
> the only practical solution would be to have packages for each of the
> major forks (which over the past 10 years have grown incompatible with
> each other), but I don't think that is allowed.
Debian doesn't *require* a single canonical library. It's just strongly
preferred for security support. In this case, it sounds like what was
originally one library has forked thoroughly enough to be four separate
libraries. It's not an ideal situation, but I don't think this should
block adding the software to Debian.
That said, it would still be nice to fix the embedding of yet another gzip
library.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/874o6er...@windlord.stanford.edu
Karl Goetz
Philip Taylor <exc...@gmail.com> wrote:
> On Sun, Apr 3, 2011 at 11:00 AM, Karl Goetz <ka...@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?
> > ./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.
> 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.
Karl Goetz
Philip Taylor <exc...@gmail.com> wrote:
> On Sun, Apr 3, 2011 at 10:15 AM, Vincent Cheng
> <vincen...@gmail.com> wrote:
> > On Sat, Apr 2, 2011 at 11:08 PM, Karl Goetz <ka...@kgoetz.id.au>
> > wrote:
> >> Not sure if all the CCs are required, so preserving them.
> >>
> >> [...]
> >> Is there code distributed under the terms of license_dbghelp.txt in
> >> this package? It would appear to be non-dfsg compliant, so may
> >> cause you problems.
> >
> > To be honest, I don't know. The files that are licensed under the
> > terms of license_dbghelp.txt are in
> > source/lib/external_libraries/dbghelp.cpp, dbghelp.h,
> > dbghelp_funcs.h, but I'm not sure if they're used during the build.
> > Hmmm...I'll try re-building 0ad with those files removed from the
> > source tarball and see if the build still works.
> > - Vincent
>
> dbghelp is only used for Windows.
I feel you still still be careful of the following:
iii. Distribution Restrictions. You may not
[...]
* modify or distribute the source code of any Distributable Code so
that any part of it becomes subject to an Excluded License. An
Excluded License is one that requires, as a condition of use,
modification or distribution, that
* the code be disclosed or distributed in source code form; or
* others have the right to modify it.
It may cause you issues outside debian too.
Philip Taylor
> Philip Taylor <exc...@gmail.com> wrote:
>> On Sun, Apr 3, 2011 at 11:00 AM, Karl Goetz <ka...@kgoetz.id.au> wrote:
>> > 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).
>
> So it can be modified by the game/related tools?
It can be created and parsed and rendered (but not modified) by the
game engine. It used to be exported by a custom 3ds Max plugin but we
no longer use that (we export to Collada since ~4 years ago). It's not
designed to be a modifiable format, but it's not theoretically
impossible to modify - there's a Python script at
http://trac.wildfiregames.com/ticket/461 to convert .pmd back into
editable Collada format so it can be imported into e.g. Blender,
though that currently only works for static meshes and not
skeletally-animated ones.
>> > ./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.
DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
texgyrepagella-bold.otf are unmodified originals.
ConvertedPagella-Regular.ttf, ConvertedPagella-Bold.ttf are
non-original and derived from texgyrepagella-*. The original
texgyrepagella-* are from
http://www.gust.org.pl/projects/e-foundry/tex-gyre under the license
http://www.gust.org.pl/fonts/licenses/GUST-FONT-LICENSE.txt (LaTeX
Project Public License 1.3c plus a suggestion to rename the fonts when
modifying them).
>> > ./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.
>>
>> [...]
> Any chance you could stop shipping the DAE file? otherwise debian will
> have to repack the tarball.
Changed the tarball generation script in
http://trac.wildfiregames.com/changeset/9160
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimr1BgQNgREqgNSg...@mail.gmail.com
Vincent Cheng
Vincent Cheng
Vincent Cheng
> > ./binaries/data/tools/fontbuilder/fonts/*Are these the original? the comment implies they are not.
> > - 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).
This is probably where the problem in debian/copyright comes from then.
> > ./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
> in a zip). The release-building process finds all the files inNot sure; mentors, is there a best way for this?
> 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?
Any chance you could stop shipping the DAE file? otherwise debian will
> > ./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).
have to repack the tarball.
thanks,
kk
Vincent Cheng
>> > ./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.
>>
> Any chance you could stop shipping the DAE file? otherwise debian willChanged the tarball generation script in
> have to repack the tarball.
http://trac.wildfiregames.com/changeset/9160
Paul Wise
> It can be created and parsed and rendered (but not modified) by the
> game engine. It used to be exported by a custom 3ds Max plugin but we
> no longer use that (we export to Collada since ~4 years ago). It's not
> designed to be a modifiable format, but it's not theoretically
> impossible to modify - there's a Python script at
> http://trac.wildfiregames.com/ticket/461 to convert .pmd back into
> editable Collada format so it can be imported into e.g. Blender,
> though that currently only works for static meshes and not
> skeletally-animated ones.
I would suggest the the pmd files be removed from the source package
and replaced with the _source code_ (the form for modifying) for the
models and that the build scripts should convert them to the form used
by the engine.
> DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
> texgyrepagella-bold.otf are unmodified originals.
Best remove these and package the ones that aren't yet in Debian separately.
> ConvertedPagella-Regular.ttf, ConvertedPagella-Bold.ttf are
> non-original and derived from texgyrepagella-*. The original
> texgyrepagella-* are from
> http://www.gust.org.pl/projects/e-foundry/tex-gyre under the license
> http://www.gust.org.pl/fonts/licenses/GUST-FONT-LICENSE.txt (LaTeX
> Project Public License 1.3c plus a suggestion to rename the fonts when
> modifying them).
What modifications were done for this? Would it be possible to merge
those upstream?
> Changed the tarball generation script in
> http://trac.wildfiregames.com/changeset/9160
Why are you manually creating the tarball, doesn't your build system
have the equivalent of `make distcheck` from automake?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimW637i8GFG...@mail.gmail.com
Paul Wise
> Just for clarification: mentors, if there are files in the source package
> that are unused during a build of that package (in this case, fonts), and
> not installed by the package, do I still need to document them in
> debian/copyright? Or can I just safely ignore them and not have to worry
> about copyright and licensing issues? Or should I simply remove them from
> the source package?
The copyright and license still needs to be documented since we are
distributing them in the source package. If you are already repacking,
just drop them during the repack process.
> Since nobody has mentionned it yet, i'd just like to take a moment and thank
> Philip for taking the time to explain and clear up a lot of potential
> licensing issues, and for being a cooperative upstream. We really appreciate
> your time and effort. :)
Agreed, 0ad folks are one of the better upstreams I've seen around
pkg-games stuff in recent times.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikG2UuU_5HH...@mail.gmail.com
Karl Goetz
Vincent Cheng <vincen...@gmail.com> wrote:
> On Mon, Apr 4, 2011 at 5:43 AM, Karl Goetz <ka...@kgoetz.id.au> wrote:
>
> > On Sun, 3 Apr 2011 12:08:39 +0100
> > Philip Taylor <exc...@gmail.com> wrote:
> >
> > > On Sun, Apr 3, 2011 at 11:00 AM, Karl Goetz <ka...@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?
> > > 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
I don't know; i assumed it being bundled here meant it wasn't included.
> 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).
Please do.
> > > > ./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?
Don't know, hopefully someone else can clarify this. (you will have to
take it into account, i just don't know how detailed you'll have to be)
> > > > ./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.
I'd question the logic of doing that, I suggest having separate source
packages. How big would the two packages be?
> Also, since fcollada tests aren't run automatically, should i simply
> just remove those files from my source tarball (along with dbghelp)?
eagle.dae? definitely remove it. the supporting code? up to you.
> 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.
You have to make sure they are addressed :)
Karl Goetz
Vincent Cheng <vincen...@gmail.com> wrote:
> On Mon, Apr 4, 2011 at 5:39 AM, Karl Goetz <ka...@kgoetz.id.au> wrote:
>
> > On Sun, 3 Apr 2011 11:39:34 +0100
> > Philip Taylor <exc...@gmail.com> wrote:
> >
> > > On Sun, Apr 3, 2011 at 10:15 AM, Vincent Cheng
> > > <vincen...@gmail.com> wrote:
> > > > On Sat, Apr 2, 2011 at 11:08 PM, Karl Goetz <ka...@kgoetz.id.au>
> > > > wrote:
> > > >> Not sure if all the CCs are required, so preserving them.
> > > >>
> > > >> [...]
> > > >> Is there code distributed under the terms of
> > > >> license_dbghelp.txt in this package? It would appear to be
> > > >> non-dfsg compliant, so may cause you problems.
> > > >
> > > dbghelp is only used for Windows.
> >
> > I feel you still still be careful of the following:
> >
> > iii. Distribution Restrictions. You may not
> > [...]
> > * modify or distribute the source code of any Distributable Code
> > so that any part of it becomes subject to an Excluded License. An
> > Excluded License is one that requires, as a condition of use,
> > modification or distribution, that
> > * the code be disclosed or distributed in source code form; or
> > * others have the right to modify it.
> >
> > It may cause you issues outside debian too.
> > thanks,
> > kk
> Since dbghelp isn't needed for 0 A.D. on Linux, would it be
> preferable if I simply strip the files affected by that license out
> of the source package?
I'm not sure; could someone else comment on this?
Philip Taylor
> I didn't come across a FTBFS, but I suppose that was because I built 0 A.D.
> within a pbuilder configured for Testing (which, at the time, had libenet
> 1.2 available). Philip, is upstream planning to port 0ad to a newer version
> of libenet (1.3)?
We're not currently planning to do so.
Porting the code is trivial, but the problem is ENet 1.3 is
protocol-incompatible with 1.2. Cross-platform multiplayer is an
important feature, so we need to use the same ENet series (1.2.* or
1.3.*) for every user on every platform to avoid breakages. (If I
remember correctly, ENet doesn't report the protocol incompatibility
error in a useful way, so we can't even reliably tell the user what's
causing the connection problem.)
About 75% of our Linux users seem to be on Ubuntu. A quarter of those
are using the year-old 10.04 release, and even the not-yet-released
11.04 seems to be stuck with ENet 1.2 packages, so it'll likely be a
couple of years before ENet 1.3 is widely available as a standard
package for nearly all users. I don't want to require all those users
(not to mention users of older versions of other distros) to install
more non-standard packages, since my desire with this whole packaging
thing is to make it easier for users, so I think the least problematic
approach is to require ENet 1.2 everywhere (with newer distros adding
packages for side-by-side installation of 1.2 and 1.3 - several do
that already).
The main alternative I can imagine is to bundle a copy of ENet 1.3
with the game and use that instead of the system library, if the
system library is 1.2. That would let it work automatically and
relatively painlessly for users on older distros, while still using
the system library on newer distros. But bundling isn't nice and I'd
prefer to avoid the added complexity if possible. Unless I'm missing
some better option, adding a new ENet 1.2 package to Debian sounds
best to me.
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimhj42jmbfWzg=FyUykL2mu9+X2xYzD=Bbn-==m...@mail.gmail.com
Philip Taylor
> Since dbghelp isn't needed for 0 A.D. on Linux, would it be preferable if I
> simply strip the files affected by that license out of the source package?
The only file affected is binaries/system/dbghelp.dll, which is in SVN
and in the Windows installer but not in the 0ad-*-alpha-unix-*.tar.*
releases so I don't think there's anything to strip out.
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTi=jpOF4cyv-Kj5i2dEpv...@mail.gmail.com
Philip Taylor
> On Mon, Apr 4, 2011 at 5:43 AM, Karl Goetz <ka...@kgoetz.id.au> wrote:
>> On Sun, 3 Apr 2011 12:08:39 +0100
>> Philip Taylor <exc...@gmail.com> wrote:
>> > 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).
SpiderMonkey doesn't provide any guarantees of API compatibility. (If
they can make Firefox improve by 5% on a benchmark by breaking the API
then they'll do so. The API was designed ~15 years ago so it's not
surprising they have to tweak it to remain competitive). It also
doesn't provide any guarantees of functional compatibility - its
JavaScript language feature support might grow or shrink between
releases. 0 A.D. depends on some relatively advanced SpiderMonkey
features, and functional differences may cause mysterious out-of-sync
errors in multiplayer games if players have different versions, so
compatibility is important here.
The idea behind the SpiderMonkey 1.8.5 release is that *does* provide
compatibility, but only within the 1.8.5 series. They've released
js185-1.0.0.tar.gz and might do a js185-1.0.1.tar.gz with backported
bug fixes or security patches etc. Then at some point in the future
there will probably be a js190-1.0.0.tar.gz based on the latest
upstream code which will be totally incompatible. js190 and js185
should be separate packages, installed side-by-side, so applications
can use whichever stable series they were designed for, instead of
forcing every application to upgrade simultaneously whenever there's a
new major release. (They all ought to upgrade eventually, but it
should be possible to do that gradually.)
So libmozjs-dev won't work since it doesn't provide the necessary
compatibility, but a libmozjs185-dev would probably be okay (once 0
A.D. gets ported to the latest API changes in it).
> 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.
It should be possible to build the two packages completely
independently (and the -data package is architecture-independent so it
can be built less frequently). The tests in the -build release package
optionally run some scripts that are in the -data package, but those
script tests are only useful for development and not needed when
packaging, so you can just ignore their harmless warning message, and
otherwise there should be no build-time dependencies between them.
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinEd+yyrt6yZX9gD...@mail.gmail.com
Philip Taylor
> On Mon, Apr 4, 2011 at 10:55 PM, Philip Taylor <exc...@gmail.com> wrote:
>
>> It can be created and parsed and rendered (but not modified) by the
>> game engine. It used to be exported by a custom 3ds Max plugin but we
>> no longer use that (we export to Collada since ~4 years ago). It's not
>> designed to be a modifiable format, but it's not theoretically
>> impossible to modify - there's a Python script at
>> http://trac.wildfiregames.com/ticket/461 to convert .pmd back into
>> editable Collada format so it can be imported into e.g. Blender,
>> though that currently only works for static meshes and not
>> skeletally-animated ones.
>
> I would suggest the the pmd files be removed from the source package
> and replaced with the _source code_ (the form for modifying) for the
> models and that the build scripts should convert them to the form used
> by the engine.
For new models and animations, that's effectively what we do (the
engine loads the Collada and converts to .pmd at run-time).
For old ones, we don't have the modifiable form (except as 3ds Max
files scattered around various people's disks and FTP sites - the art
process wasn't well organised).
For old static meshes, we could use that Python script to convert them
into modifiable Collada files and replace the .pmd files with those,
and I'd be happy to do that.
For old animated meshes, we'd need to extend that script to convert
them successfully into Collada, which might be significant work (or
might be impossible - I'm not quite sure). It'd be nice to do that,
but it probably won't happen any time soon since there's
higher-priority problems in this area.
For binaries/data/tests/collada/sphere.pmd (the file that was
originally mentioned), its purpose is to test the Collada-to-PMD
conversion code - we can't replace it with a Collada file and then
convert it automatically because that would defeat the point of the
test.
>> DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
>> texgyrepagella-bold.otf are unmodified originals.
>
> Best remove these and package the ones that aren't yet in Debian separately.
We don't use those files at build-time or at run-time (they're only
used at development-time), so there would be no point packaging them
for users. I can exclude those files from the distribution script
since that seems the easiest solution.
>> ConvertedPagella-Regular.ttf, ConvertedPagella-Bold.ttf are
>> non-original and derived from texgyrepagella-*.
>
> What modifications were done for this? Would it be possible to merge
> those upstream?
No modifications except what FontForge does automatically when saving,
which happens to make FreeType render them to bitmaps in a way that
looks prettier. But I can exclude those files so it won't matter here
anyway.
>> Changed the tarball generation script in
>> http://trac.wildfiregames.com/changeset/9160
>
> Why are you manually creating the tarball, doesn't your build system
> have the equivalent of `make distcheck` from automake?
It doesn't. (The build system is certainly far from ideal, but it sort
of works, and I don't have much experience with anything else, so I
haven't cared enough to learn and implement any replacement myself,
and nobody else has tried replacing it either. We'd probably need a
script anyway to generate the Windows installer via Wine and it seems
easy enough to do the tarballs the same way.)
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinwZSPQcJ6fojpKS...@mail.gmail.com
Paul Wise
> For old ones, we don't have the modifiable form (except as 3ds Max
> files scattered around various people's disks and FTP sites - the art
> process wasn't well organised).
Hmm, OK.
> For old static meshes, we could use that Python script to convert them
> into modifiable Collada files and replace the .pmd files with those,
> and I'd be happy to do that.
Great, please do.
> For old animated meshes, we'd need to extend that script to convert
> them successfully into Collada, which might be significant work (or
> might be impossible - I'm not quite sure). It'd be nice to do that,
> but it probably won't happen any time soon since there's
> higher-priority problems in this area.
There seems to be Blender import for 3DS Max files and Collada export
for Blender so it might be possible to go that route, not sure if
those have support for animated meshes though.
> For binaries/data/tests/collada/sphere.pmd (the file that was
> originally mentioned), its purpose is to test the Collada-to-PMD
> conversion code - we can't replace it with a Collada file and then
> convert it automatically because that would defeat the point of the
> test.
Hmm, ok.
>>> DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
>>> texgyrepagella-bold.otf are unmodified originals.
>>
>> Best remove these and package the ones that aren't yet in Debian separately.
>
> We don't use those files at build-time or at run-time (they're only
> used at development-time), so there would be no point packaging them
> for users. I can exclude those files from the distribution script
> since that seems the easiest solution.
It sounds like you're embedding glyphs from the fonts in bitmap
images. I would suggest at minimum that you switch to doing that at
build-time. Preferably you would render text at run-time, since that
enables i18n. For finding font files use fontconfig (preferred) and or
a build-time parameter for finding them.
>>> ConvertedPagella-Regular.ttf, ConvertedPagella-Bold.ttf are
>>> non-original and derived from texgyrepagella-*.
>>
>> What modifications were done for this? Would it be possible to merge
>> those upstream?
>
> No modifications except what FontForge does automatically when saving,
> which happens to make FreeType render them to bitmaps in a way that
> looks prettier. But I can exclude those files so it won't matter here
> anyway.
Here I would suggest doing the conversion at build time until you do
the above font stuff.
>>> Changed the tarball generation script in
>>> http://trac.wildfiregames.com/changeset/9160
>>
>> Why are you manually creating the tarball, doesn't your build system
>> have the equivalent of `make distcheck` from automake?
>
> It doesn't. (The build system is certainly far from ideal, but it sort
> of works, and I don't have much experience with anything else, so I
> haven't cared enough to learn and implement any replacement myself,
> and nobody else has tried replacing it either. We'd probably need a
> script anyway to generate the Windows installer via Wine and it seems
> easy enough to do the tarballs the same way.)
If you are running this stuff on Debian, please note that there is an
nsis package so you do not need to involve wine at all here. Other
Linux distributions probably have nsis packages too, or nsis can
pretty easily be compiled on Linux if you have a GCC/mingw
cross-compiler for win32.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTiktb1C=tbdXj-uRGS6...@mail.gmail.com
Vincent Cheng
Paul Wise
> - package libenet1.2, and replace 0ad's build dependency on libenet-dev with
> this new package
I'd prefer to have only one version of enet in Debian, but I
understand the reasoning here (protocol incompatibility).
> - package libmozjs185, and remove the spidermonkey code that's currently in
> the source tarball (this could be deferred until alpha 5 is released, since
> according to Philip, 0 A.D. hasn't been ported to work with it yet; for now,
> I guess we'll have to leave the spidermonkey code embedded in the source
> tarball)
Why can't you use the versions of SpiderMonkey already in the archive
(1.9.1.18, 2.0)?
> - determine what, if anything, needs to be removed from the source tarball
> (the only thing I've removed so far is
> /libraries/fcollada/src/FCollada/FColladaTest/Samples/Eagle.DAE)
I'd suggest also removing any embedded code copies that aren't used by
the Debian package.
> As for the fonts, since they aren't used during the build or at runtime,
> would it really be necessary to package them separately (is there any point
> in having an unused package in Debian's repositories)? Removing them from
> the source tarball would be a much faster alternative, unless upstream
> decides to set up a build system to convert/render those fonts at build
> time.
I covered this in my earlier mail, was my guess about how they are
used incorrect?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTi=cObjEcbGEjxL_...@mail.gmail.com
Ansgar Burchardt
Vincent Cheng <vincen...@gmail.com> writes:
> - package libenet1.2, and replace 0ad's build dependency on
> libenet-dev with this new package
We just got rid of enet 1.2 in testing a few days ago and I prefer to
have just a single version per release to care about (instead of
doubling the number of possible versions from five to ten).
For Ubuntu users, upstream could include the newer enet in their PPA.
The packages containing the library itself are co-installable, only the
-dev packages for enet 1.2 and 1.3 are not.
I don't know how to best handle other distributions, but doesn't
upstream have to bundle enet anyway for Windows and Mac OS X users?
> - package libmozjs185, and remove the spidermonkey code that's
> currently in the source tarball (this could be deferred until alpha 5
> is released, since according to Philip, 0 A.D. hasn't been ported to
> work with it yet; for now, I guess we'll have to leave the
> spidermonkey code embedded in the source tarball)
I suggest to ask the maintainers' of libmozjs-dev how they think about
this.
Regards,
Ansgar
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Philip Taylor
> On Wed, Apr 6, 2011 at 12:05 AM, Philip Taylor <exc...@gmail.com> wrote:
>>>> DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
>>>> texgyrepagella-bold.otf are unmodified originals.
>>>
>>> Best remove these and package the ones that aren't yet in Debian separately.
>>
>> We don't use those files at build-time or at run-time (they're only
>> used at development-time), so there would be no point packaging them
>> for users. I can exclude those files from the distribution script
>> since that seems the easiest solution.
>
> It sounds like you're embedding glyphs from the fonts in bitmap
> images.
Yes (e.g. http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/fonts/serif-14.png)
> I would suggest at minimum that you switch to doing that at
> build-time. Preferably you would render text at run-time, since that
> enables i18n. For finding font files use fontconfig (preferred) and or
> a build-time parameter for finding them.
My main concern is that that wouldn't provide sufficient consistency -
different versions of Freetype, or the same version with different
configuration (bytecode interpreter, autohinter, etc), might render
the same font quite differently and break the look of the game.
(Getting a font that renders nicely with recolouring and textured
backgrounds and non-native monitor resolutions and with an
outline-stroked variant etc seems tricky - they often look fine in a
desktop application but not in the game). That problem applies equally
to run-time and build-time. Distributing pre-built bitmaps seems to me
the only way to be able to verify and guarantee the rendering quality
across all environments.
I think i18n for languages with small alphabets (Latin, Cyrillic, etc)
is easily handled by sticking more glyphs in the bitmap. I expect
large sets of glyphs (presumably CJK) or complex shaping (presumably
Arabic etc) will need a different implementation, but I'd prefer to
have the game support two text rendering modes simultaneously rather
than compromising the quality of the primary languages, if there isn't
a solution that works equally well for all.
> If you are running this stuff on Debian, please note that there is an
> nsis package so you do not need to involve wine at all here. Other
> Linux distributions probably have nsis packages too
Thanks, I'd forgotten about that. I'm currently on Gentoo so the
package requires a cross-compiler environment, which seems less
trivial to set up than using Wine, but it's probably a better
long-term solution.
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTi=H0DS-Q+u76pVW...@mail.gmail.com
Philip Taylor
> For Ubuntu users, upstream could include the newer enet in their PPA.
> The packages containing the library itself are co-installable, only the
> -dev packages for enet 1.2 and 1.3 are not.
Hmm, I'm not particularly familiar with how the PPAs work, but if
adding enet there requires zero extra effort from users installing the
game then I think that'd be okay.
> I don't know how to best handle other distributions, but doesn't
> upstream have to bundle enet anyway for Windows and Mac OS X users?
On Windows we bundle precompiled binaries (.dll and .lib), so that can
be upgraded easily and is independent of the Linux / OS X approach.
On OS X we don't bundle - we typically use MacPorts which currently
provides ENet 1.2 (http://libenet.darwinports.com/) but I think we
could give them an upgraded portfile and it'd be immediately available
to all users.
For all Fedora/Mandriva/OpenSUSE versions I think we could upgrade the
library at https://build.opensuse.org/package/show?package=libenet&project=games
so it'd work for users who install the game from that service. Arch
and Gentoo already have packages for 1.3 and don't have users on old
distro versions. I think all other distros that have packages for the
game are too minor to worry over - they can sort themselves out as
necessary.
So, I suppose this could work - just need to set up ENet 1.3 packages
for MacPorts and the OpenSUSE Build Service and the Ubuntu PPA, and
recompile on Windows, and update the game code. (Not an entirely
trivial amount of work, unfortunately :-( )
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTik3Wy=F5E=ivX3LGOgt...@mail.gmail.com
Adam Borowski
> On Wed, Apr 6, 2011 at 1:24 AM, Paul Wise <pa...@debian.org> wrote:
> > On Wed, Apr 6, 2011 at 12:05 AM, Philip Taylor <exc...@gmail.com> wrote:
> >>>> DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
> >>>> texgyrepagella-bold.otf are unmodified originals.
> >
> > images.
>
> Yes (e.g. http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/fonts/serif-14.png)
>
> > I would suggest at minimum that you switch to doing that at
> > build-time. Preferably you would render text at run-time, since that
> > enables i18n. For finding font files use fontconfig (preferred) and or
> > a build-time parameter for finding them.
>
> My main concern is that that wouldn't provide sufficient consistency -
> different versions of Freetype, or the same version with different
> configuration (bytecode interpreter, autohinter, etc), might render
> the same font quite differently and break the look of the game.
Why won't you force the settings then? If you are afraid the user's
configuration might be ill-fitting, specify them by hand.
> (Getting a font that renders nicely with recolouring and textured
> backgrounds and non-native monitor resolutions and with an
> outline-stroked variant etc seems tricky - they often look fine in a
> desktop application but not in the game).
Subpixel rendering is nice, but indeed breaks with any sort of scaling.
Monochromatic rendering looks abysmal when scaled, too. You definitely want
greyscale antialiasing. It can't go bad -- other choices might be better in
certain cases, but it's the most universal one.
And guess what, the image you linked to uses greyscale antialiasing.
Is the text usually shown non-scaled? Then you might want hinting. If not,
hinting is totally pointless. Why should FreeType distort the text to match
a certain resolution if it will be immediately scaled? For non-integer
multiplies, it will go wrong.
Thus, you want the following settings:
* (always) FT_LOAD_TARGET_NORMAL, plus
* (if usually scaled) FT_LOAD_NO_SCALE or FT_LOAD_NO_HINTING
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Wise
> My main concern is that that wouldn't provide sufficient consistency -
> different versions of Freetype, or the same version with different
> configuration (bytecode interpreter, autohinter, etc), might render
> the same font quite differently and break the look of the game.
> (Getting a font that renders nicely with recolouring and textured
> backgrounds and non-native monitor resolutions and with an
> outline-stroked variant etc seems tricky - they often look fine in a
> desktop application but not in the game). That problem applies equally
> to run-time and build-time. Distributing pre-built bitmaps seems to me
> the only way to be able to verify and guarantee the rendering quality
> across all environments.
>
> I think i18n for languages with small alphabets (Latin, Cyrillic, etc)
> is easily handled by sticking more glyphs in the bitmap. I expect
> large sets of glyphs (presumably CJK) or complex shaping (presumably
> Arabic etc) will need a different implementation, but I'd prefer to
> have the game support two text rendering modes simultaneously rather
> than compromising the quality of the primary languages, if there isn't
> a solution that works equally well for all.
My experience with warzone2100 and chromium-bsu is that runtime text
rendering works just fine. Only thing you have to watch is the
temptation to add bitmaps, parts of warzone2100 are untranslatable due
to that.
> Thanks, I'd forgotten about that. I'm currently on Gentoo so the
> package requires a cross-compiler environment, which seems less
> trivial to set up than using Wine, but it's probably a better
There is an nsis ebuild in Gentoo, looks like it has good instructions
on how to install the mingw stuff.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTik=jq0ymehHY+RwK...@mail.gmail.com
Vincent Cheng
On Thu, Apr 7, 2011 at 10:58 AM, Vincent Cheng <vincen...@gmail.com> wrote:I'd prefer to have only one version of enet in Debian, but I
> - package libenet1.2, and replace 0ad's build dependency on libenet-dev with
> this new package
understand the reasoning here (protocol incompatibility).
Why can't you use the versions of SpiderMonkey already in the archive
> - package libmozjs185, and remove the spidermonkey code that's currently in
> the source tarball (this could be deferred until alpha 5 is released, since
> according to Philip, 0 A.D. hasn't been ported to work with it yet; for now,
> I guess we'll have to leave the spidermonkey code embedded in the source
> tarball)
(1.9.1.18, 2.0)?
> - determine what, if anything, needs to be removed from the source tarballI'd suggest also removing any embedded code copies that aren't used by
> (the only thing I've removed so far is
> /libraries/fcollada/src/FCollada/FColladaTest/Samples/Eagle.DAE)
the Debian package.
I covered this in my earlier mail, was my guess about how they are
> As for the fonts, since they aren't used during the build or at runtime,
> would it really be necessary to package them separately (is there any point
> in having an unused package in Debian's repositories)? Removing them from
> the source tarball would be a much faster alternative, unless upstream
> decides to set up a build system to convert/render those fonts at build
> time.
used incorrect?
Vincent Cheng
Hi,
We just got rid of enet 1.2 in testing a few days ago and I prefer to
Vincent Cheng <vincen...@gmail.com> writes:
> - package libenet1.2, and replace 0ad's build dependency on
> libenet-dev with this new package
have just a single version per release to care about (instead of
doubling the number of possible versions from five to ten).
For Ubuntu users, upstream could include the newer enet in their PPA.
The packages containing the library itself are co-installable, only the
-dev packages for enet 1.2 and 1.3 are not.
I don't know how to best handle other distributions, but doesn't
upstream have to bundle enet anyway for Windows and Mac OS X users?
> - package libmozjs185, and remove the spidermonkey code that'sI suggest to ask the maintainers' of libmozjs-dev how they think about
> currently in the source tarball (this could be deferred until alpha 5
> is released, since according to Philip, 0 A.D. hasn't been ported to
> work with it yet; for now, I guess we'll have to leave the
> spidermonkey code embedded in the source tarball)
this.
Vincent Cheng
On Thu, Apr 7, 2011 at 9:53 AM, Ansgar Burchardt <ans...@debian.org> wrote:Hmm, I'm not particularly familiar with how the PPAs work, but if
> For Ubuntu users, upstream could include the newer enet in their PPA.
> The packages containing the library itself are co-installable, only the
> -dev packages for enet 1.2 and 1.3 are not.
adding enet there requires zero extra effort from users installing the
game then I think that'd be okay.
> I don't know how to best handle other distributions, but doesn'tOn Windows we bundle precompiled binaries (.dll and .lib), so that can
> upstream have to bundle enet anyway for Windows and Mac OS X users?
be upgraded easily and is independent of the Linux / OS X approach.
On OS X we don't bundle - we typically use MacPorts which currently
provides ENet 1.2 (http://libenet.darwinports.com/) but I think we
could give them an upgraded portfile and it'd be immediately available
to all users.
For all Fedora/Mandriva/OpenSUSE versions I think we could upgrade the
library at https://build.opensuse.org/package/show?package=libenet&project=games
so it'd work for users who install the game from that service. Arch
and Gentoo already have packages for 1.3 and don't have users on old
distro versions. I think all other distros that have packages for the
game are too minor to worry over - they can sort themselves out as
necessary.
So, I suppose this could work - just need to set up ENet 1.3 packages
for MacPorts and the OpenSUSE Build Service and the Ubuntu PPA, and
recompile on Windows, and update the game code. (Not an entirely
trivial amount of work, unfortunately :-( )
Philip Taylor
> On Thu, Apr 07, 2011 at 04:33:47PM +0100, Philip Taylor wrote:
>> On Wed, Apr 6, 2011 at 1:24 AM, Paul Wise <pa...@debian.org> wrote:
>> > Preferably you would render text at run-time, since that
>> > enables i18n. For finding font files use fontconfig (preferred) and or
>> > a build-time parameter for finding them.
>>
>> My main concern is that that wouldn't provide sufficient consistency -
>> different versions of Freetype, or the same version with different
>> configuration (bytecode interpreter, autohinter, etc), might render
>> the same font quite differently and break the look of the game.
>
> Why won't you force the settings then? If you are afraid the user's
> configuration might be ill-fitting, specify them by hand.
The important ones that I'm aware of are compile-time settings
(TT_CONFIG_OPTION_BYTECODE_INTERPRETER/TT_CONFIG_OPTION_UNPATENTED_HINTING)
so we can't override them. It seems the relevant patents only expired
about a year ago, and some distros respected the patents before then -
I have no idea how many users are still running systems in the
unpatented mode, but in the absence of data I assume it's non-zero,
and I'd rather not make changes that add complexity and could make the
game worse for some users unless there's sufficient benefit.
(I expect this may change in the future - once we eventually add i18n
support and non-Latin-alphabet languages there will be some benefit to
loading fonts dynamically (and it'd be simpler to load all fonts that
way), and I could probably collect data on how many of our users have
poor-quality Freetypes if there is no existing data indicating it's a
negligible number, but those are probably unlikely to happen within
the next few months.)
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTiZ63gPz6t9...@mail.gmail.com
Paul Wise
> Similar to why 0 A.D. needs libenet 1.2; Philip explained earlier that 0
> A.D. needs a specific version of Spidermonkey (1.8.5) in order to maintain
> compatibility, since it uses advanced Spidermonkey features and users with
> different versions of Spidermonkey may run into issues in multiplayer games
> (as an
as an ?
> Just wanted some clarification; if upstream chooses not to implement a build
> system where fonts are converted into glyphs/bitmaps during the build, and
> instead stick with pre-rendered glyphs in the source package, it would be ok
> to simply strip out the fonts, and not have to package them separately as
> you suggested in an earlier mail?
No, since the fonts are the source code for those images and we have DFSG #2.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikuYnSMas1OTONL5Sia2qo1k_4_=g...@mail.gmail.com
Adam Borowski
> On Thu, Apr 7, 2011 at 5:35 PM, Adam Borowski <kilo...@angband.pl> wrote:
> > On Thu, Apr 07, 2011 at 04:33:47PM +0100, Philip Taylor wrote:
> >> On Wed, Apr 6, 2011 at 1:24 AM, Paul Wise <pa...@debian.org> wrote:
> >> > Preferably you would render text at run-time, since that
> >> > enables i18n. For finding font files use fontconfig (preferred) and or
> >> > a build-time parameter for finding them.
> >>
> >> My main concern is that that wouldn't provide sufficient consistency -
> >> different versions of Freetype, or the same version with different
> >> configuration (bytecode interpreter, autohinter, etc), might render
> >> the same font quite differently and break the look of the game.
> >
> > Why won't you force the settings then? If you are afraid the user's
> > configuration might be ill-fitting, specify them by hand.
>
> The important ones that I'm aware of are compile-time settings
> (TT_CONFIG_OPTION_BYTECODE_INTERPRETER/TT_CONFIG_OPTION_UNPATENTED_HINTING)
These two are used only if you choose bytecode hinting. Just specify any
other option if you're afraid of inconsistency.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Cheng
On Fri, Apr 8, 2011 at 6:32 PM, Vincent Cheng <vincen...@gmail.com> wrote:as an ?
> Similar to why 0 A.D. needs libenet 1.2; Philip explained earlier that 0
> A.D. needs a specific version of Spidermonkey (1.8.5) in order to maintain
> compatibility, since it uses advanced Spidermonkey features and users with
> different versions of Spidermonkey may run into issues in multiplayer games
> (as an
> Just wanted some clarification; if upstream chooses not to implement a buildNo, since the fonts are the source code for those images and we have DFSG #2.
> system where fonts are converted into glyphs/bitmaps during the build, and
> instead stick with pre-rendered glyphs in the source package, it would be ok
> to simply strip out the fonts, and not have to package them separately as
> you suggested in an earlier mail?
Paul Wise
> Oops, don't know why I broke off mid-sentence like that. My point was that
> porting 0 A.D. to work with newer versions of Spidermonkey seems to be a lot
> of work for very little gain and lots of opportunities for potential
> breakage. Philip addressed this already in an earlier message [1].
> However, the Debian Mozilla team doesn't seem to be very enthusiastic about
> supporting an older version of Spidermonkey in the long run. What would be
> the best course of action now? I don't want to pressure upstream to port 0
> A.D. to a newer Spidermonkey version if they have no desire to do so (and I
> have no clue how to port software), I can't pressure the Debian Mozilla team
> to maintain an older Spidermonkey version for a single piece of software
> (and I'm sure that they have a lot of other work to do), and from the
> replies I've seen so far, it seems that embedding Spidermonkey code in 0
> A.D.'s source is a no-no, or at least strongly discouraged.
Maybe porting to another JavaScript engine (like Google V8) is the
best long-term solution?
> In an earlier message [2], you suggested that various .ttf fonts
> (DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
> texgyrepagella-bold.otf) should be removed from the source package. But on
> the other hand, since the fonts are source code for the glyphs, they
> shouldn't be removed, right? Sorry, but I can't help but feel somewhat
> confused...
That was before I knew how they were being used in this package, keep
them in the source package unless upstream introduces build-time or
run-time text rendering.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTik2Zu60-0MAAq0L=0-bw-a...@mail.gmail.com
Vincent Cheng
On Sun, Apr 10, 2011 at 5:49 PM, Vincent Cheng <vincen...@gmail.com> wrote:Maybe porting to another JavaScript engine (like Google V8) is the
> Oops, don't know why I broke off mid-sentence like that. My point was that
> porting 0 A.D. to work with newer versions of Spidermonkey seems to be a lot
> of work for very little gain and lots of opportunities for potential
> breakage. Philip addressed this already in an earlier message [1].
> However, the Debian Mozilla team doesn't seem to be very enthusiastic about
> supporting an older version of Spidermonkey in the long run. What would be
> the best course of action now? I don't want to pressure upstream to port 0
> A.D. to a newer Spidermonkey version if they have no desire to do so (and I
> have no clue how to port software), I can't pressure the Debian Mozilla team
> to maintain an older Spidermonkey version for a single piece of software
> (and I'm sure that they have a lot of other work to do), and from the
> replies I've seen so far, it seems that embedding Spidermonkey code in 0
> A.D.'s source is a no-no, or at least strongly discouraged.
best long-term solution?
> In an earlier message [2], you suggested that various .ttf fontsThat was before I knew how they were being used in this package, keep
> (DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
> texgyrepagella-bold.otf) should be removed from the source package. But on
> the other hand, since the fonts are source code for the glyphs, they
> shouldn't be removed, right? Sorry, but I can't help but feel somewhat
> confused...
them in the source package unless upstream introduces build-time or
run-time text rendering.
Paul Wise
> Hmmm, I've never thought of porting 0 A.D. to an entirely different JS
> engine as an option. Is V8's API relatively stable compared to Spidermonkey?
V8's ABI looks very unstable, not sure about the API.
I am not particularly knowledgeable in the area of JavaScript engines.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTinLavkQhYSE...@mail.gmail.com
Jon Dowland
> > from the replies I've seen so far, it seems that embedding Spidermonkey
> > code in 0 A.D.'s source is a no-no, or at least strongly discouraged.
>
> Maybe porting to another JavaScript engine (like Google V8) is the best
> long-term solution?
It seems to be asking a lot of upstream. Is there a likelyhood for any other
package to make use of the old spidermonkey version (when it is old, that is)?
I'd expect not, and so I'd think using the bundled version was the sensible
choice.
--
Jon Dowland
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110411092...@deckard.alcopop.org
Mike Hommey
> On Sun, Apr 10, 2011 at 06:04:43PM +0800, Paul Wise wrote:
> > > from the replies I've seen so far, it seems that embedding Spidermonkey
> > > code in 0 A.D.'s source is a no-no, or at least strongly discouraged.
> >
> > Maybe porting to another JavaScript engine (like Google V8) is the best
> > long-term solution?
>
> It seems to be asking a lot of upstream. Is there a likelyhood for any other
> package to make use of the old spidermonkey version (when it is old, that is)?
> I'd expect not, and so I'd think using the bundled version was the sensible
> choice.
There are several packages using spidermonkey, and they are originally
designed for various versions of spidermonkey. If we'd keep these
bundled versions, we'd have 10 copies of different versions of (security
hazardous) spidermonkey in the archive. If we'd package all of them as
separate packages, we'd have 10 spidermonkey packages. The sensible
choice is to either avoid using spidermonkey, or use the latest
available in Debian.
Mike
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Philip Taylor
> On Fri, Apr 08, 2011 at 06:22:23PM +0100, Philip Taylor wrote:
>> On Thu, Apr 7, 2011 at 5:35 PM, Adam Borowski <kilo...@angband.pl> wrote:
>> > On Thu, Apr 07, 2011 at 04:33:47PM +0100, Philip Taylor wrote:
>> >> On Wed, Apr 6, 2011 at 1:24 AM, Paul Wise <pa...@debian.org> wrote:
>> >> > Preferably you would render text at run-time, since that
>> >> > enables i18n. For finding font files use fontconfig (preferred) and or
>> >> > a build-time parameter for finding them.
>> >>
>> >> My main concern is that that wouldn't provide sufficient consistency -
>> >> different versions of Freetype, or the same version with different
>> >> configuration (bytecode interpreter, autohinter, etc), might render
>> >> the same font quite differently and break the look of the game.
>> >
>> > Why won't you force the settings then? If you are afraid the user's
>> > configuration might be ill-fitting, specify them by hand.
>>
>> The important ones that I'm aware of are compile-time settings
>> (TT_CONFIG_OPTION_BYTECODE_INTERPRETER/TT_CONFIG_OPTION_UNPATENTED_HINTING)
>
> These two are used only if you choose bytecode hinting. Just specify any
> other option if you're afraid of inconsistency.
I played with this a bit, and it looks like the bytecode interpreter
is necessary for some of the fonts we use.
http://zaynar.co.uk/0ad-pub/fonts/fonts-default-hint.png - the normal
rendering (using default font options in Cairo, which handles
antialiasing etc automatically).
http://zaynar.co.uk/0ad-pub/fonts/fonts-no-hint.png - FT_LOAD_NO_HINTING.
http://zaynar.co.uk/0ad-pub/fonts/fonts-auto-hint.png -
FT_LOAD_FORCE_AUTOHINT (or a version of Freetype with the patented
code disabled).
The autohinter makes everything much uglier. The main font (Pagella)
doesn't use hinting - with FT_LOAD_NO_HINTING enabled it's actually
the same when using the game's converted .ttf or the original .otf, so
I think I can remove the converted .ttf files entirely and use the
NO_HINTING flag when rendering it. But the DejaVu Sans Mono in the
top-left corner looks like it really needs the original bytecode
hinting, to avoid being ugly or blurry.
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimNJ5XXNAQa...@mail.gmail.com
Philip Taylor
> On Sun, Apr 10, 2011 at 5:49 PM, Vincent Cheng <vincen...@gmail.com> wrote:
>
>> Oops, don't know why I broke off mid-sentence like that. My point was that
>> porting 0 A.D. to work with newer versions of Spidermonkey seems to be a lot
>> of work for very little gain and lots of opportunities for potential
>> breakage. Philip addressed this already in an earlier message [1].
To clarify slightly: I'm happy to port to SpiderMonkey 1.8.5, which is
the newest release (two weeks old). (The version numbers in e.g.
'libmozjs-dev 1.9.1.18' are Gecko version numbers, not SpiderMonkey
version numbers, and don't correspond to any official standalone
SpiderMonkey release, so they're older than 1.8.5). If there are
occasional further standalone releases of SpiderMonkey in the future,
I expect I'll be happy to port to them too.
The main constraint is that any given version of the game will only
support a single SpiderMonkey release (and will use that same release
across all Linux distros and all other platforms). If we use something
like libmozjs-dev 1.9.1.18, there's no guarantee that libmozjs-dev
1.9.1.19 won't break API compatibility or cause multiplayer sync
errors, so I don't want to use a version like that. But if we support
the js185-1.0.0.tar.gz release then a hypothetical bugfixed
js185-1.0.1.tar.gz should work too (that stability being the purpose
of the standalone releases), and we can stick with that until there's
a new standalone release series that we can port to (or until it
becomes apparent there won't be any more standalone releases and then
we can revisit the problem), so it should be less of a maintenance
burden than the alternatives.
> Maybe porting to another JavaScript engine (like Google V8) is the
> best long-term solution?
I believe that will never happen - it'd be a huge amount of work for
very little benefit (and that's assuming V8 does provide a stable API
that they will never break in order to make Chrome 5% faster - I don't
know if that's the case).
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTinocV97fe82cWFYEB-aoAA=fTk...@mail.gmail.com
Vincent Cheng
> I can't pressure the Debian Mozilla team
> to maintain an older Spidermonkey version for a single piece of software
> (and I'm sure that they have a lot of other work to do), and from the
> replies I've seen so far, it seems that embedding Spidermonkey code in 0
> A.D.'s source is a no-no, or at least strongly discouraged.
The whole "embedding code copies" handling isn't entirely black and white.
In cases, where a embedded code copy has no security implications we've
already made sensible compromises, e.g. in the case of kompozer, where the
embedded Gecko copy has no security implications. What is Spidermonkey
used for in the case of 0ad?
Cheers,
Moritz
Philip Taylor
>> to maintain an older Spidermonkey version for a single piece of software
>> (and I'm sure that they have a lot of other work to do), and from the
>> replies I've seen so far, it seems that embedding Spidermonkey code in 0
>> A.D.'s source is a no-no, or at least strongly discouraged.
>
> In cases, where a embedded code copy has no security implications we've
> already made sensible compromises, e.g. in the case of kompozer, where the
> embedded Gecko copy has no security implications. What is Spidermonkey
> used for in the case of 0ad?
I started trying to write some rough notes at
http://trac.wildfiregames.com/wiki/SecurityModel . In summary: we
don't currently use SpiderMonkey to run untrusted scripts (unless the
user manually installs them), but will likely want to start doing that
fairly soon (for convenient automatic downloads of scripted maps for
multiplayer and potentially other things).
(If the goal is to minimise exploitable vulnerabilities, rather than
just to patch bugs for which security advisories have been issued,
then SpiderMonkey is probably the least troublesome part of the game -
there will be far more problems in the game engine (the multiplayer
networking code and (once there's automatic map downloading) the map
loading code and the engine functionality that is exposed to scripts
etc) than in SpiderMonkey itself, due to a lack of careful review or
thorough testing. Security is certainly a goal, and I want to improve
it before adding any automatic content downloading, but the game is
still only released as an alpha version and it's too early to have
much confidence in the implementation yet.)
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTinEW7SQ3Re4...@mail.gmail.com