code/game/g_cmds.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 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.

Makefile | 4 2 + 2 - 0 !
code/qcommon/q_platform.h | 9 8 + 1 - 0 !
2 files changed, 10 insertions(+), 3 deletions(-)

 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.

Bug-Debian: https://bugs.debian.org/413617
Bug-Debian: https://bugs.debian.org/679330

Makefile | 16 1 + 15 - 0 !
1 file changed, 1 insertion(+), 15 deletions(-)

 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)

Makefile | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 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)

Makefile | 6 5 + 1 - 0 !
code/qcommon/q_platform.h | 30 2 + 28 - 0 !
2 files changed, 7 insertions(+), 29 deletions(-)

 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

Makefile | 5 5 + 0 - 0 !
code/game/g_main.c | 4 2 + 2 - 0 !
code/qcommon/q_shared.h | 4 4 + 0 - 0 !
3 files changed, 11 insertions(+), 2 deletions(-)

 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.

Makefile | 12 6 + 6 - 0 !
1 file changed, 6 insertions(+), 6 deletions(-)

 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.

Bug-Debian: https://bugs.debian.org/966150
Bug-Debian: https://bugs.debian.org/966173

code/game/ai_main.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix typo of empty in ai_main.c

code/game/g_combat.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix a typo for 'already'

Makefile | 27 23 + 4 - 0 !
code/qcommon/q_platform.h | 2 1 + 1 - 0 !
2 files changed, 24 insertions(+), 5 deletions(-)

 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.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701630

Makefile | 2 1 + 1 - 0 !
code/q3_ui/ui_menu.c | 2 1 + 1 - 0 !
code/qcommon/q_shared.h | 4 2 + 2 - 0 !
3 files changed, 4 insertions(+), 4 deletions(-)

 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.

code/q3_ui/ui_firstconnect.c | 17 15 + 2 - 0 !
code/q3_ui/ui_local.h | 1 1 + 0 - 0 !
code/q3_ui/ui_preferences.c | 40 39 + 1 - 0 !
3 files changed, 55 insertions(+), 3 deletions(-)

 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.

Makefile | 4 4 + 0 - 0 !
code/cgame/cg_draw.c | 6 3 + 3 - 0 !
code/game/ai_dmq3.c | 2 2 + 0 - 0 !
code/game/bg_misc.c | 15 12 + 3 - 0 !
code/game/bg_pmove.c | 2 2 + 0 - 0 !
code/game/bg_public.h | 11 10 + 1 - 0 !
code/game/g_active.c | 11 10 + 1 - 0 !
code/game/g_combat.c | 4 4 + 0 - 0 !
code/game/g_items.c | 9 8 + 1 - 0 !
9 files changed, 55 insertions(+), 9 deletions(-)

 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.

code/qcommon/q_shared.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 add a version marker to each game/cgame/ui module

This ensures that they aren't identical even if built from the same