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

Re: OpenArena DFSG-fixing



Hi,

On 03/11/2010 07:07 PM, Bruno Kleinert wrote:
Am Samstag, den 23.01.2010, 18:52 +0100 schrieb Hans de Goede:
Hi,

On 01/22/2010 08:08 AM, Paul Wise wrote:
On Wed, Jan 20, 2010 at 11:33 AM, Simon McVittie<smcv@debian.org>   wrote:

I've attached patches to bugs on openarena and openarena-data to address the
issue of sourceless QVMs (bytecode files) in openarena-data (not only do we
not distribute source, but they need a non-free compiler). However, I don't
feel that I should upload such major changes without review from someone who
knows this codebase better, so I haven't done an NMU or games-team upload
(since working on those bugs I've joined the games team to work on
game-data-packager). Could someone have a look, please?

It'd also be great if someone who is in touch with upstream could talk to them
about this, as it'll probably continue to be a problem in future.

I imagine that would be goneri and or fuddl? Probably best to fix this
upstream first anyway.

In the long term, it'd be good if OpenArena could use a shared ioquake3 source
package (perhaps with multiple differently-patched or differently-configured
builds like linux-2.6, to allow for OpenArena changes?), so we could have
ioquake3 (engine-only support package in /usr/lib/ioquake3), openarena
(wrapper scripts, .desktop etc.) and openarena-data in main, quake3 (wrapper
scripts etc.) in contrib, and quake3-data non-distributable but produced on
users' systems using game-data-packager.

I'd say openarena/quake3 could just contain the data, desktop file,
wrapper script etc, no need for openarena-data or quake3-data.

Ideally, we could then ship World of Padman and/or Urban Terror on a similar
basis (patched or unpatched ioquake3 in contrib or main for the engine,
wrapper scripts in contrib, art and other data in non-free).

I imagine most of these have forked the engine, probably significantly?


No, in Fedora we use a single ioquake3 engine for quake3, openarena, word of
padman (wop) and urban terror.

There all some small patches in there for this, but nothing big, and we set some
options when starting the engine in the wrapper script, see:
http://cvs.fedoraproject.org/viewvc/devel/quake3/

Basically all patches except 2 are for making this possible (and making the
shareware data files work without the binary spitting out various complaints).

The 2 exceptions are:

quake3-1.34-syslibs.patch:
Make the engine use the system libjpeg, I've tried getting this upstream but they
have denied it. You probably want this too, as otherwise the next libjpeg
security hole which pops up will need separate patching in your quake3 packages

quake3-1.36-botlib-strcpy-abuse.patch:
A bugfix for some lets use strcpy when we want memmove issues, which get triggered
by using a new gcc or glibc (dunno which one on Fedora everything is always pretty
new). This patch is already upstream.


While on this subject, you may want to take a look at autodownloader just for fun,
download a livecd (and boot from it), do "yum install urbanterror" and then select
urbanterror in the application menu (under games, duh), or just start the wrapper
script from a terminal. This is our solution to what I guess you are doing
with game-data-packager. Note that this just downloads the files (and extracts them)
to ~/.q3a/<path>/, which means no root rights are needed, if you have
multiple users on the machine who all want these games it is very bandwidth and
diskspace inefficient, but we (I'm) are counting on that being the exception.

Hi Hans,

I had a look at your patches in Fedora and was wondering if you have
something working or if you're working on something to get rid of the
proprietary LCC compiler to build the QVM byte-code files.


No, we don't have any solution for the LCC compiler issue. We work around this
by:
1) Not shipping the LCC compiler (be it in source or binary form)
2) Using the precompiled resources from upstream

Regards,

Hans


Reply to: