Debian Patches

Status for openarena/0.8.8+dfsg-6

Patch Description Author Forwarded Bugs Origin Last update
Fix-for-crashing-the-server-by-making-a-callvote-to-.patch Fix for crashing the server by making a callvote to kick a player which does not exist

A fix for Debian Bug #681812. Doing "callvote kick PLAYERNAME" for a
playername that did not exist resultet in undefined behavior.

Depending on architecture this resultet in a crash or something else.
Poul Sander <sago007@gmail.com> no debian upstream 2012-09-13
Treat-GNU-kFreeBSD-and-GNU-Hurd-as-equivalent-to-GNU-Linu.patch Treat GNU/kFreeBSD and GNU/Hurd as equivalent to GNU/Linux
The GNU family of operating systems use the GNU libc and runtime linker,
which is the layer that this engine interacts with directly. The specific
kernel used is below the level that this engine is dealing with.

This is a combination of ioquake3 commits
https://github.com/ioquake/ioq3/commit/fd4cf3b7839ec36789627c27758478cca8f69ffe,
https://github.com/ioquake/ioq3/commit/58a8f5ef8bca62ea6bc4a4e0cfff65b5d28d36a0,
https://github.com/ioquake/ioq3/commit/d2f8b9f4bb3fda901ffd6f18074d035469832338,
https://github.com/ioquake/ioq3/commit/54aa7f25832cfa7a8ac7891a702758ccd88d1ba8
(partial) and
https://github.com/ioquake/ioq3/commit/540e4225cceacaf843a9d4741bfbb11ba19fdd7a,
variously written by Cyril Brulebois, Thilo Schulz, devhc and Svante Signell.
Simon McVittie <smcv@debian.org> yes debian 2017-06-24
Makefile-confine-LIB-to-the-one-platform-that-needs-it-na.patch Makefile: confine $(LIB) to the one platform that needs it, namely irix64

It isn't mentioned anywhere else, and deleting it from the Linux code
path means we don't need to maintain an exhaustive list of 64-bit
architectures.

(cherry picked from ioquake3 commit 071965b3f0647385f3c32a49c1df5e125550969c)
Simon McVittie <smcv@debian.org> yes 2017-06-24
build-canonicalize-all-ARM-variants-to-arm-matching-q_pla.patch build: canonicalize all ARM variants to "arm", matching q_platform.h
The ARCH in the Makefile must match the ARCH_STRING in q_platform.h;
otherwise, ioquake3 will install (for instance) uiARCH.so but look for
uiARCH_STRING.so, which isn't going to go well (particularly for
the modular renderer).

Like i386, but unlike most (all?) other Linux platforms, uname -m on
32-bit ARM machines can have various results starting with "arm",
depending on the specific CPU version (e.g. Raspberry Pi is armv6l,
RPi2 is armv7l). Again similar to the x86 family,
it's appropriate for them to share an architecture suffix;
q_platform.h has traditionally used "arm" so let's use that.

64-bit ARM makes a clean break from this, much like 64-bit x86 does:
uname -m produces a string not starting with arm (specifically
"aarch64"), and gcc predefines __aarch64__ instead of __arm__.
As a result, it is unaffected by this change.

(cherry picked from ioquake3 commit c91fab3900345d047f085d1e467521bba1ebd28f)
Simon McVittie <smcv@debian.org> yes 2017-06-24
debian/Use-a-cpp-macro-for-the-game-code-version-so-package.patch Use a cpp macro for the game-code version so packages can override it

Also draw it at a variable location, so it's right-aligned.
Simon McVittie <smcv@debian.org> not-needed vendor, Debian 2012-02-26
build-define-ARCH_STRING-in-Makefile-on-Linux-and-other-G.patch build: define ARCH_STRING in Makefile on Linux and other GNU platforms

GNU platforms (Linux, kFreeBSD, Hurd) have endian.h to determine
endianness, so all architectures except x86_64 are in fact treated
identically, except that their ARCH_STRING is different. For the engine,
the ARCH_STRING must always be identical to the ARCH from the Makefile,
otherwise the engine will not find its cgame, game and ui plugins
under their expected names and startup will fail. If we pass it in
from the Makefile, then an identical value is guaranteed, and we can
get rid of an increasingly long list of defined(__some_cpu__) tests.

The game-code does not actually use ARCH_STRING, but I've kept it
in order to be consistent with the ioquake3 engine.

On non-Linux platforms we only support a few architectures anyway,
so keeping the list up to date is less of a burden; *BSD porters
could probably use the same technique to get support for lots of
architectures with little effort, but I have not done that here,
because I cannot test it.

Windows must continue to support preprocessor-based architecture tests
in any case, so that the MSVC solutions (which do not use the Makefile)
can continue to work. However, Windows only runs on a few CPU families,
so this shouldn't be a significant burden in practice.

When cross-compiling, the tools are compiled for the build architecture
(COMPILE_PLATFORM, COMPILE_ARCH) rather than the host architecture
(PLATFORM, ARCH), so define ARCH_STRING to COMPILE_ARCH on a GNU
COMPILE_PLATFORM.

(cherry-picked from ioquake3 commit 2a71948f21fe588dbce9b29409283e9c912ef8e7)
Simon McVittie <smcv@debian.org> yes 2017-06-24
Pick-up-date-from-SOURCE_DATE_EPOCH-for-reproducible-buil.patch Pick up date from SOURCE_DATE_EPOCH, for reproducible builds
The goal of reproducible builds is that a rebuild of the same source
code with the same compiler, libraries, etc. should result in the same
binaries. SOURCE_DATE_EPOCH provides a standard way for build systems
to fill in the date of the latest source change, typically from a git
commit or from metadata like the debian/changelog in Debian packages.
Simon McVittie <smcv@debian.org> yes 2015-04-02
build-Link-game-cgame-ui-modules-to-LIBS.patch build: Link game, cgame, ui modules to $(LIBS)
All three modules call mathematical functions like atan2(). On glibc
systems, when compiled to native code with an ordinary C compiler
(as opposed to bytecode from q3lcc), they get the definition of those
functions from libm.

Until now, they were not explicitly linked to libm, and instead relied
on the fact that libm is linked into the main executable. However,
doing it this way defeats glibc's symbol-versioning mechanisms, and
can fail in some situations, in particular binaries built with
-ffast-math on a pre-2.31 version of glibc (where atan2() resolves to
__atan2_finite()), and used without recompilation on a post-2.31 version
of glibc (where __atan2_finite() has become a deprecated hidden symbol
that is only available as a versioned symbol).

When building shared libraries and loadable modules, it's most robust
to link them explicitly to their dependencies, as is done here.
$(LIBS) also includes -ldl, which is unnecessary but harmless.
Simon McVittie <smcv@debian.org> yes debian 2020-07-24
Fix-typo-of-empty-in-ai_main.c.patch Fix typo of empty in ai_main.c Zack Middleton <zturtleman@gmail.com> no ioquake3, commit:274fa898b1cbadd444a2641c93c0f7daadba9af6 2016-06-27
Fix-a-typo-for-already.patch Fix a typo for 'already' Simon McVittie <smcv@debian.org> yes 2020-12-22
Disable-Altivec-instructions-on-PowerPC-unless-requested.patch Disable Altivec instructions on PowerPC unless requested
Baseline PowerPC CPUs are not guaranteed to have Altivec instructions
available, even if they are 64-bit.

Unlike SSE and similar extensions on x86, there does not seem to be
a way to enable conditional, targeted use of Altivec based on runtime
detection (which is what ioquake3 wants to do) without also giving the
compiler permission to use Altivec in code generation; so to not crash
on the affected CPUs, we'll have to turn it off altogether.

At one point Altivec was an important optimization, because the
most commonly available PowerPC CPUs (in Apple G4/G5 hardware)
had the Altivec instructions, and they were a significant benefit
there. However, Apple haven't sold PowerPC devices for over 10 years,
some more recently-manufactured PowerPC CPUs like the (64-bit) Freescale
e5500 omit Altivec, and CPUs in general are a lot faster now than they
were when the idTech3 engine was first released, hopefully making the
optimization unnecessary.

This commit uses -mno-altivec to force Altivec instructions not to be
emitted, unless Altivec is requested via "make USE_ALTIVEC=1". The Apple
fork of gcc doesn't document the corresponding -fno-altivec option, so
we'll have to assume that omitting -faltivec is enough (but non-Altivec
PowerPC Macs haven't been sold for a long time anyway).

Similar to https://github.com/ioquake/ioq3/pull/337 in ioquake3.
Simon McVittie <smcv@debian.org> no debian 2017-10-04
debian/Request-confirmation-if-a-user-enables-auto-download.patch Request confirmation if a user enables auto-downloading
The Q3 UI toolkit isn't great at large amounts of text, so just point
to a deb.li link into the Debian wiki.
Simon McVittie <smcv@debian.org> no debian vendor, Debian 2012-09-14
debian/Add-OPENARENA_081_COMPATIBLE-define-for-network-comp.patch Add OPENARENA_081_COMPATIBLE define for network compat with 0.8.1
0.8.1 was approximately compatible with Quake III Arena, whereas 0.8.5
is more like Team Arena. Unfortunately, these are not the same.

Not forwarded: upstream expect everyone to use the precompiled bytecode they
supply, which was built from unmodified 0.8.5 and 0.8.1 source code. We're not
doing that in Debian for DFSG reasons, and I'd rather not add a second complete
copy of the source.
Simon McVittie <smcv@debian.org> not-needed debian upstream vendor, Debian 2012-02-26
debian/Add-a-version-marker-to-each-game-cgame-ui-module.patch Add a version marker to each game/cgame/ui module
This ensures that they aren't identical even if built from the same
code, so that their build-IDs differ, so that their detached debug
symbols don't collide.
Simon McVittie <smcv@debian.org> not-needed 2020-02-18

All known versions for source package 'openarena'

Links