| 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 | ||
| 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/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 | |
| 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 |