Bug#559240: Packaging ioQuake3 instead of the OpenArena engine

2010-07-18 Thread Bruno Kleinert
Hi,

I'm currently experimenting with a patched ioQuake3 engine for OpenArena
instead of using the patched (and very likely outdated) ioQuake3 engine
that comes with OpenArena.

The version of ioQuake3 I'm using is 1.36, which is the latest release.
From the sources I stripped the non-DFSG compliant LCC to get rid of the
policy violation and the binary-without-source issue. The game logic
shipped with ioQuake3 and compiled as shared objects works fine for
OpenArena as far as I tested it the whole day yesterday ;)

I also applied some patches from fedora to address the outstanding
internal code copy issues (jpeg, speex, etc.)

The problem I have not taken care of is incompatibity to sv_pure 1
servers. But maybe we can fix that later on.

As I'm at the BSP Munich ATM, I'll try to prepare an ioquake3 upload for
experimental.

Cheers - Fuddl


signature.asc
Description: This is a digitally signed message part


Bug#559240: Packaging ioQuake3 instead of the OpenArena engine

2010-07-18 Thread Simon McVittie
On Sun, 18 Jul 2010 at 11:45:30 +0200, Bruno Kleinert wrote:
 The version of ioQuake3 I'm using is 1.36, which is the latest release.
 From the sources I stripped the non-DFSG compliant LCC to get rid of the
 policy violation and the binary-without-source issue.

(Please leave q3asm in and only strip out lcc; q3asm seems to have been
written and GPL'd by ID, and we might want it at some point.)

 The game logic
 shipped with ioQuake3 and compiled as shared objects works fine for
 OpenArena as far as I tested it the whole day yesterday ;)

OA = 0.8.5 game logic has an active upstream
(http://code.google.com/p/oax/source/browse/), and they're making
independent changes, so I think they'll diverge from vanilla Quake 3 over
time.

The OA *engine*, on the other hand, seems to have one developer applying a few
patches to ioquake3. Ideally, we'd build a single ioquake3 binary and use it
for OA, non-free quake3, Urban Terror, etc.; we might have to apply some
patches to turn things that are normally compile-time options into runtime
options (mainly BASEGAME).

I think the arrangement I'd aim for, using Urban Terror as an example of a
total conversion we might want to package, is:

* src:ioquake3 builds ioquake3, ioquake3-server
  - engine from ioquake3 + patches for system libraries and openarena
friendliness
  - upstream is ioquake3

* src:openarena builds openarena, openarena-server, possibly openarena-common
  - game logic from openarena releases
  - openarena Depends: ioquake3, openarena-common, openarena-data
  - openarena-server Depends: openarena-server, openarena-common, -data
  - upstream is openarena, i.e. tagged releases of oax on Google Code

* src:quake3 (contrib) builds quake3 (contrib), quake3-server (contrib)
  - quake3 Depends: ioquake3, quake3-data
  - quake3-server Depends: ioquake3-server, quake3-data
  - they might as well use the vanilla ID QVMs, since the data is non-free
and non-distributable anyway

* src:urban-terror (contrib) has the same structure as quake3

* quake3-data comes from game-data-packager

* urban-terror-data comes from game-data-packager

 The problem I have not taken care of is incompatibity to sv_pure 1
 servers. But maybe we can fix that later on.

I think that's a showstopper for pushing this to unstable: sv_pure 1 is the
default, and if nothing else it makes a good sanity check.

S



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org