Bug#523323: missing source code

[Simon McVittie]

On Thu, 29 Oct 2009 at 14:17:04 +0100, Bruno Kleinert wrote:
> Am Samstag, den 24.10.2009, 15:28 +0100 schrieb Simon McVittie:
> > 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.
[...]
> > 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.
> I'd prefer this cheating way.

See attached patch. Warning: it's totally untested, you (or I) should add some
printfs to assess whether it actually works.

My suggestion for the checksum blob would be to turn the list of desired
fake-CRCs into an array of integers in Perl syntax, and embed it in a
script that's run at openarena-data build time to produce the actual blob;
that'd make it not too difficult to update for new upstream versions.
Something like (a longer version of):

my @fake_crcs = (
    0x12345678,         # textures/foo.jpg
    0x87654321,         # vm/cgame.qvm (not in Debian, needs non-free compiler)
);

We could even have a script that's *not* run by the build, that takes a blessed
upstream pk3 file as input, scans through it with Archive::Zip, produces
that array of integers, and also produces a stripped version of the pk3 file
that lacks the QVMs. I can probably work on this sometime next week if nobody
gets there first.

As far as I can see, faking the checksums is probably only necessary for
pak0.pk3, but I could be wrong.

In the longer term, yes it'd be good to have upstream not do this, but I can
see that it's desirable to verify that everyone is using the same pk3s, as
a guard against invalid bug reports caused by mismatched versions (I doubt
that the engine copes well with a mismatch), so rather than stripping out
the checksumming, it'd probably be better to ask upstream to compile the
game code alongside the engine build and not ship QVMs at all.

I have a vague recollection that the game-code is not very portable (it
might well rely on the fact that, in practice, everyone always built it
using either lcc for a 32-bit VM, or a real C compiler for i386 Windows,
i386 Linux or PowerPC MacOS). It may need some fixes to be able to
build natively on platforms where int, long and pointer are different sizes,
for instance.

    Simon