Bug#523323: missing source code

[Simon McVittie]

On Sat, 01 Aug 2009 at 14:20:40 +0100, Simon McVittie wrote:
> If you believe that suitable source code for OpenArena game data is not
> provided, that would be a bug in openarena-data (a separate source package).

Unfortunately, it appears that this is correct:

* openarena-data contains .pk3 files (zip files)
* of those, pak0.pk3 contains .qvm files (the "cgame", "game" and "ui"
  modules), which are bytecode for a VM built in to the Quake 3 engine
* the .qvm files are compiled from C in http://www.openarena.ws/svn/source/
  using a non-free compiler (lcc)

Using gcc (main)
================

It should also possible to compile the cgame, game and ui modules as
native code, by copying them into the openarena source package and defining
BUILD_GAME_SO. I don't know how portable these modules are (the current
packaging dodges that issue by having them as platform-independent bytecode,
that was (presumably) compiled on i386), so this may cause build failures on
64-bit or big-endian architectures.

This would mean that openarena-data could be made suitable for main by
removing the sourceless QVM files - but see below for compatibility.

Using lcc (contrib)
===================

openarena-data could be made suitable for contrib by working out what the
corresponding source code is, providing it in the source package, and requiring
that an external q3lcc be used to build it; however, see "Compatibility"
below. This would also demote openarena (the binaries) to contrib.

(If doing this, it would be convenient if the required version of lcc was
uploaded to non-free.)

Compatibility
=============

Confusing things further, the Quake 3 network protocol checks for
compatibility by applying a simple checksum to the PK3 files. The checksum
is based on the CRC32s of the unzipped *contents* of the PK3 file, so just
unzipping and re-compressing the PK3 file shouldn't be a problem, but
recompiling the VMs would be, as far as I can tell - unless Debian has the
same "blessed" QVM files that are in upstream's svn, Debian openarena will be
incompatible.

Since we're building Openarena from source anyway, we control the source
code that computes the checksum, so it should be possible to have our
Openarena cheat, and claim to other platforms' Openarena builds that its QVMs
match the "blessed" upstream ones, even if they actually don't exist.

The best way to do this would probably be to include some sort of datafile
containing the desired fake checksums in openarena-data, and patch
openarena to look for them.

The checksums in question are:

* normal checksum: a checksum over the CRC32s of the zip file members
* pure-server checksum: a checksum over the "checksum feed" (an integer
  representing the ordered sequence of PK3s the server is using?) followed
  by the CRC32s of the zip file members

so the fake checksum data would have to be a list of CRC32s of zipfile members
to pretend to have. The checksumming expects them to be 4-byte little-endian,
so the file could just consist of the raw bytes of the CRCs, in LE order. I
have some untested code for this if you're interested in this approach.

Regards,
    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 793 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20091024/de697972/attachment.pgp>