Arch Linux User Repository

@Infiltrator If you mean, that the mouse cursor is stuck in certain areas: I already reported the issue to the SDL2-compat developers some month ago (https://github.com/libsdl-org/sdl2-compat/issues/399). It should be fixed in v2.32.58

Hi Infiltrator. conflicts in the PKGBUILD is only there to make the package manager aware of conflicts between similar packages because of files that are the same in both packages. The sdl2/sdl2-compat is sadly not really solveable (ignoring statically compiling) as pacman lacks an alternative system like other package managers. And as sdl2-compat provides sdl2 it will always be chosen as a dep unless the old sdl2 from the AUR will be installed beforehand (or one does have a custom repo listed earlier than [extra]). That is also the reason why constricting this dep to a version won't really work as one group will always be left out :D
I would simply add a pinned comment which describes the situation: Either people install sdl2 before building/installing/running or wait for the respective release of sdl2-compat.

Ah, good work getting that fixed, @Machion!

@TriaInError, I would still like to know from a packaging perspective whether what I asked is possible in general, and whether it should be applied in this specific case until the fixed version of sdl2-compat is released. (And maybe also a minimum version requirement for sdl2-compat, then?)

@Infiltrator If you mean, that the mouse cursor is stuck in certain areas: I already reported the issue to the SDL2-compat developers some month ago (https://github.com/libsdl-org/sdl2-compat/issues/399). It should be fixed in v2.32.58

Hey, TrialnError, it looks like there is an issue with sdl2-compat and the cursor bounds. Is it possible to add "sdl2-compat" to conflicts to link against real SDL2 instead of sdl2-compat?

Yeah, I agree that the COPYING file makes things confusing. My TINLA/IANAL understanding is that the copyright notice of the actual source takes precedence, especially since the COPYING file does not strictly state "only 2 and not later". If anybody knows more about this, I would be happy to hear it.

Thank you for having me on board. As I said in the other package, I am a noob at packaging; but at the very least, I can update version numbers. :D

Thank you for the insight. Very much appreciated.
Interesting to hear about your fork. Something new to check out.

Thank you for the patch for enabled strictness. Will use that instead of deactivating that option.

You bring up a good point about CXXFLAGS; I should have included ${CXXFLAGS}. I take it that you will fix it up?

Slightly different, but yes, I adjusted that.

Regarding the license: I based my conclusion from a quick glance at the top of the COPYING file. And there it only mentions the GPL2 in general and not explicitly any flavour. So I'm currently at a loss. But as the or later isn't removed from the license text it is safe to assume GPL-2.0-or-later? Especially since it also appears that way in the source files. So thank you again for the heads up. I will change the SPDX identifier.

I would be happy to be a co-maintainer for this package, yeah, if that makes it easier for you.

Great to read :) It does help a lot as I only check on upstream from time to time. Visible through missing the latest release (not for the first time). And additionally I wouldn't have known about an issue between clients compiled with different GCC versions.
Therefore: Welcome aboard :)

I notice as well that you set the licence to GPL-2.0-only. I am 99% sure that the licence is actually GPL2+. And if I am mistaken, then I need to go and fix up a few things myself.

I base my conclusion on this snippet of the copyright notice at the top of the source files:

 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 2 of the License, or
 * (at your option) any later version.

Thank you very much for the heads up about the markdown.

I don't know whether involved is the right word. Upstream is… not easy for me to work with, let's say. I am actually maintaining my own fork; but I am still trying to get as many bug fixes into 7kaa as I can. (A bunch of them are sitting in PRs waiting to be looked at.)

I would be happy to be a co-maintainer for this package, yeah, if that makes it easier for you.

You bring up a good point about CXXFLAGS; I should have included ${CXXFLAGS}. I take it that you will fix it up?

Yes, the patch for the build error above is:

Date: Sun, 3 Aug 2025 16:40:34 +1000
Subject: [PATCH] Fix format not a string literal and no format arguments error
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Compilation with strictness turned on (for the Debian build) was giving
these errors:

    ONEWSENG.cpp: In member function ‘void News::firm_constructed()’:
    ONEWSENG.cpp:1759:17: error: format not a string literal and no format arguments [-Werror=format-security]
     1759 |         snprintf(str, MAX_STR_LEN+1, _(firm_constructed_msg[short_para1-1]));
          |         ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ONEWSENG.cpp: In member function ‘void News::weapon_ship_built()’:
    ONEWSENG.cpp:1834:25: error: format not a string literal and no format arguments [-Werror=format-security]
     1834 |                 snprintf(str, MAX_STR_LEN+1, weapon_ship_built_msg[short_para1-UNIT_CATAPULT]);
          |                 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fix this by using strncpy instead of snprintf with no format arguments.
---
 src/ONEWSENG.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/ONEWSENG.cpp b/src/ONEWSENG.cpp
index cf3d6cd2..155319e1 100644
--- a/src/ONEWSENG.cpp
+++ b/src/ONEWSENG.cpp
@@ -1756,7 +1756,7 @@ void News::firm_constructed()
    //
    //----------------------------------------------//

-   snprintf(str, MAX_STR_LEN+1, _(firm_constructed_msg[short_para1-1]));
+   strncpy(str, _(firm_constructed_msg[short_para1-1]), MAX_STR_LEN+1);
 }
 //------- End of function News::firm_constructed -----//

@@ -1831,7 +1831,7 @@ void News::weapon_ship_built()
    else
    {
        // ships don't have tech levels, and harbors aren't always near towns
-       snprintf(str, MAX_STR_LEN+1, _(weapon_ship_built_msg[short_para1-UNIT_CATAPULT]));
+       strncpy(str, _(weapon_ship_built_msg[short_para1-UNIT_CATAPULT]), MAX_STR_LEN+1);
    }
 }
 //------- End of function News::weapon_ship_built -----//
-- 
2.47.2

I will add the flag, but in a different way. In the proposed way it will overwrite the distro default CXXFLAGS.
And while compiling the new version it runs into this:

ONEWSENG.cpp: In member function ‘void News::firm_constructed()’:
ONEWSENG.cpp:1763:17: error: format not a string literal and no format arguments [-Werror=format-security]
 1763 |         snprintf(str, MAX_STR_LEN+1, _(firm_constructed_msg[short_para1-1]));
      |         ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ONEWSENG.cpp: In member function ‘void News::weapon_ship_built()’:
ONEWSENG.cpp:1838:25: error: format not a string literal and no format arguments [-Werror=format-security]
 1838 |                 snprintf(str, MAX_STR_LEN+1, _(weapon_ship_built_msg[short_para1-UNIT_CATAPULT]));
      |                 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Is there a patch around for that?

Thank you for the heads up.
In general the markdown syntax for multiline unformatted stuff (packs of triple backticks) should work.
It seems you are involved with upstream? At least the same dropped in the release news. Are you maybe interested in being a co-maintainer for this package?