zyli

I checked if it is possible to compile 0ad-0.27.0-rc2 on Live Debian Bookworm 12.9. Short answer: you can't, because 'rustc' is too old. If someone wants to play 0ad-0.27.0-rc2, they have to upgrade Bookworm -> Trixie. Details. After installing dependencies (without 'subversion', but with 'llvm') and issuing the command './build-source-libs.sh' I found out that: 0:02.40 checking rustc version... 1.63.0 0:02.42 checking cargo version... 1.65.0 0:02.45 ERROR: Rust compiler 1.63.0 is too old. 0:02.45 To compile Rust language sources please install at least 0:02.45 version 1.66.0 of the 'rustc' toolchain (or, if using nightly, 0:02.45 at least one version newer than 1.66.0) and make sure it is 0:02.45 first in your path. 0:02.45 You can verify this by typing 'rustc --version'. 0:02.45 If you have the 'rustup' tool installed you can upgrade 0:02.45 to the latest release by typing 'rustup update'. The 0:02.45 installer is available from https://rustup.rs/ *** Fix above errors and then restart with "./mach build" ERROR: SpiderMonkey build failed The system has: $ apt policy rustc rustc: Installed: 1.63.0+dfsg1-2 Candidate: 1.63.0+dfsg1-2 There is no newer version in backports. If anyone wants to know how to compile 0ad, the README.md file contained in the 0ad-0.27.0-rc2-unix-build.tar.gz archive directs them to: https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions In my opinion, in the 'Linux Debian Ubuntu' subitem (https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions#debian-ubuntu) you should; 1. Remove: Debian 12 (bookworm) Enter: Debian 13 (trixie) 2. In the 'sudo apt install' code Remove: 'subversion' 3. In the 'sudo apt install' code Add: 'llvm' Best regards.

I checked if the 0ad-0.27.0-rc2 build works correctly on Live Debian Trixie. $ cat /run/live/medium/.disk/info Auto-generated Debian GNU/Linux Live testing xfce 2025-01-20T02:15:25Z It compiled correctly, but two comments. 1. The 'llvm' package is not specified in the dependencies. It is not on Live Trixie - you have to install it (# apt install llvm). Otherwise we will see: 0:03.83 ERROR: Cannot find llvm-objdump *** Fix above errors and then restart with "./mach build" ERROR: SpiderMonkey build failed 2. In my opinion, the 'subversion' package is unnecessary for RC compilation. It is useful for svn compilation. Best regards. PS. If I find time – I will try compiling on Live Debian 12.9 – but the 'rustc' version there is probably too low. The computer has an NVidia card, but Trixie uses the 'nouveau' driver and because of that, strange shadows appear in the game. Of course, there will be no problems on the NVidia proprietary driver. PS. No. 2 After switching graphics to Vulkan and restarting the game, the strange shadows disappeared. The game is playable - of course it is slower than on the Nvidia company drivers.

I am attaching replay files from the directory '~/.local/share/0ad/replays/0.27.0/2025-01-18_0001' 2025-01-18_0001.zip

Debian Trixie, 0.0.27 svn 173100c5c3. Elephantine map, very large. Everything seems fine to me, but in 'mainlog.html' I found: "WARNING: PlayerID 2 | Petra: Raid 14 has an inaccessible target foundation|structures/gaul/dock indices 10 1". Regards. mainlog.html_svn_RC1_173100c5c3_Debian_Trixie_nvidia.zip

https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions#dependencies Dependencies Python 3 (required for cxxtest and non-system SpiderMonkey)

Yesterday, Debian Experimental made Python 3.13 the default version. https://tracker.debian.org/pkg/python3-defaults Since Python 3.12 was a problem when compiling 0ad, I decided to check how 0ad handles version 3.13. Debian Trixie with Python 3.13 installed from the Experimental branch as default. $ python3 --version Python 3.13.1 Compilation (svn update, cd libraries/, ./build-source-libs.sh and so on) went fine. The game starts without problems. I updated ver. 109 (L"main, dba968") to ver. 117 (L"release-a27, b08cf") Christmas greetings.

Thank you for your answer. Here's what I did: 1. I installed Debian Trixie on a USB flash drive (USB 3.0) just like on a hard drive (with its own UEFI partition and additionally with grub-pc so that it can be run on older computers without UEFI). Now I have: rustc ver. 1.83.0, python 3.12.6, libopenal* ver. 1.24.1. 2. I copied my previous directory from 0ad nightly 'svn_2024/0ad/trunk/' to the above-mentioned Debian Trixie drive. I made sure that the directories I placed in had exactly the same names. Once I unnecessarily changed the name 'svn_2024' to something else and 0ad wouldn't build - the absolute path was remembered somewhere. 3. I issued the commands: cd trunk/ svn update cd libraries/ nproc # I got: 20 ./build-source-libs.sh -j20 cd ../build/workspaces/ ./update-workspaces.sh -j20 cd gcc make clean make -j20 4. Now check: cd ../../../binaries/system/ ./test # I got: Running cxxtest tests (416 tests)...OK! ./pyrogenesis # It works fine! cat ~/svn_2024_october/0ad/trunk/build/build_version/build_version.txt L"main, 5f1f8" (yesterday, today 17 Dec: L"main, dba968") 5. Of course, there were some surprises. I struggled with, among others: with the problem: It helped to install the package: llvm. 6. I think that on the page: https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions in the "Dependencies - Debian, Ubuntu" section for Debian 13 Trixie in the sentence starting with: "sudo apt install" it would be good to add the following packages: python-is-python3 rustfmt llvm Adding the 'ccache' package wouldn't hurt either. 7. When I executed './clean-source-libs.sh' it gave me a warning: './clean-source-libs.sh: 13: git: not found'. But I think that for 'svn update' the 'git' package is not needed. 8. After starting './pyrogenesis' it displays: [W][01203.830396] pw.conf | [ conf.c: 1214 try_load_conf()] can't load config client.conf: No such file or directory [E][01203.830423] pw.conf | [ conf.c: 1243 pw_conf_load_conf_for_context()] can't load config client.conf: No such file or directory But it probably has no visible effect. 9. You can't download the 0ad-spirv mod using Settings – Mod selection, which was once needed for Vulkan to work. So I copied the '0ad-spirv-0.27.22-b8sl.zip' file I had, enabled it in the settings and everything works. 0ad + Vulkan on the 'nouveau' driver (sic!). The game is playable, but Debian files and game files on a pendrive instead of a hard drive do their thing. I noticed that when there is no '0ad-spirv' mod, after exiting the game a warning window appears - I'm attaching the 'crash' file. That would be it - maybe someone will find it useful. Best regards. crashlog_2024-12-17_no_spirv-mod.txt

Debian 12.8 Bookworm Today (2024-12-16) I tried to compile 0ad with nightly-build (commands: 'svn update' etc.) I got the message: In the '0ad/trunk/libraries/' directory I had to give executable permissions to *.sh files, because the update downloaded newer files without these permissions: chmod +x build-source-libs.sh source/cxxtest-4.4/build.sh source/fcollada/build.sh source/nvtt/build.sh source/premake-core/build.sh source/spidermonkey/build.sh source/spirv-reflect/build.sh But that's a minor thing. Being in the 'libraries/' directory I issued the command './build-source-libs.sh' During "Building SpiderMonkey..." I received the information: And then: Finally: In stable Debian 12.8 there is: rustc --version rustc 1.63.0 Can't the requirements be lowered to version 1.63, which would allow building a 0ad nightly build in Debian Bookworm? I know that Debian has been waiting for quite a long time to update rustc. Debian Testing already has the current version 1.83, but the new Debian Stable is still a long way off (half a year?). The previous 0ad build, i.e. 99, made by me, worked fine. Regards.

https://tracker.debian.org/pkg/0ad [2024-11-28] Accepted 0ad 0.0.26-8 (source) into unstable (Vincent Cheng) Changelog: 0ad (0.0.26-8) unstable; urgency=medium [ Antoine Le Gonidec ] * Honour DEB_BUILD_OPTIONS when setting the maximum number of jobs. (Closes: #1000235) * Avoid a crash on launch with openal 1.24.0 (Closes: #1087990) [ Vincent Cheng ] * Fix FTBFS when attempting to build twice in a row. (Closes: #1043705) * Update Standards version to 4.7.0, no changes needed. -- Vincent Cheng <vcheng@debian.org> Thu, 28 Nov 2024 14:26:39 -0800

@bigsmit19 You're not the only one with this problem. In my opinion, it follows that there are two types of players: 1. Let's call them 'builders' - they plan, build, develop the economy and at the same time develop the army, 2. Let's call them 'rowdy' - at the beginning they focus on producing soldiers and at all costs send them immediately to the opponent. The first one has no chance against the second one (and this is how Petra plays) - unless there is some obstacle, e.g. the sea. That's why I suggest you try your hand at naval maps (random). For example, the Migration map, a very large map, four players (human + 3 computer players). There are four islands (each for one player) and a continent. In order for the computer player to attack you, he must first develop the economy - just like you, because he must build warships. Even if he attacks you later, you will defeat him, because you will already be at a certain level of development. I suggest playing as Carthaginians and sending a crew to the continent as soon as possible in a merchant ship to set up a base somewhere in the interior, because the resources on the island will soon run out. It is best if you play on the outermost island - you land in the corner of the map, build a port and a trade route, etc. Once you get the hang of it, you will win every time on the most difficult level. A more interesting (but also more difficult) map is Elephantine (very large, four players). Because on the central island (Elephantine) you can take over a wonder defended by Gaia warriors. As soon as you start building your own wonder, send heavy cavalry (approx. 80) to the central island to take over the Gaia wonder. When you have two wonders, no one will threaten you. First, you have to defend yourself against one opponent from the same coast or form an alliance with him (neutrality). And taking a third wonder from an opponent is a real joy. Good luck.

So where did 'neofetch' get this data: "Kernel: 6.5.0-5-amd64"? The current kernel in Trixie is: 6.11.5 https://packages.debian.org/trixie/linux-image-amd64 In my opinion, in the file '/etc/apt/sources.list': 1. The last two lines ('proposed-updates' and 'bookworm-backports') are unnecessary. 2. Instead of 'ftp.it.debian.org/debian' I would use: 'http://deb.debian.org/debian/'. 3. Instead of 'ftp.it.debian.org/debian/ trixie-security' I would use: 'deb http://security.debian.org/debian-security/ trixie-security' Best regards.

Sorry, but... Debian Trixie with kernel 6.5.0-5 was in December 2023. https://snapshot.debian.org/package/linux-signed-amd64/6.5.13%2B1/#linux-image-6.5.0-5-amd64_6.5.13-1 Are other packages that old too? Best regards

Nothing disappears without a reason. At that time '0ad' did not compile with python 3.12. https://wildfiregames.com/forum/topic/100249-alpha-26-doesnt-start-ubuntu-2204/?do=findComment&comment=585068 Therefore, the solution was to take '0ad' from 'mantic'. But time passes and now there is no 'mantic' repository, because 'plucky' was released. '0ad' is already present in 'plucky'. https://packages.ubuntu.com/plucky/0ad Compare the required dependencies, in particular: 'libboost-filesystem1.83.0' and 'libicu74'. In 'noble' they are probably appropriate. Then download the '0ad' package ( http://cz.archive.ubuntu.com/ubuntu/pool/universe/0/0ad/0ad_0.0.26-6ubuntu1_amd64.deb ) and install manually (dpkg -i file.deb). Installing with flatpak is not recommended: https://wildfiregames.com/forum/topic/100249-alpha-26-doesnt-start-ubuntu-2204/?do=findComment&comment=585183 Best regards.

And so it happened ... 0ad 0.0.26 returns to Debian Testing – Trixie. https://tracker.debian.org/pkg/0ad If it is already in Debian, it will be in Debian-based systems soon.

It's good that it went smoothly for you and you're happy Regarding this inscription: "Potentially unsafe". It's strange that this Ubuntu is oversensitive to packages from its own repository one branch lower ('mantic' vs. 'noble'). And somehow Ubuntu doesn't care about "Potentially unsafe" in the case of snap packages that it promotes so widely. But never mind. "Potentially unsafe" most often applies to older kernels, older web browsers, etc. when newer versions have been released. However, in this case it does not apply to the 0ad package, which would be compiled on 'noble' from the same source (0.0.26) as on 'mantic'. And why wasn't 0ad compiled on 'noble' (and also on Debian Trixie, Mint 22)? Answer: Because now in Debian Trixie ('noble' etc) the default python version is 3.12, which for some strange reason prevents compilation of 0ad (only 0ad, because 0ad-data compiles correctly). It's only about compilation, because python is not needed to run 0ad. It goes without saying that on 'mantic' python was in a lower version. And that's why the 0ad package will not be in Debian Trixie (noble etc.), until this problem is solved. News: I think auspicious winds are beginning to blow: https://wildfiregames.com/forum/topic/124266-0adpython312-%E2%80%93-a-positive-signal/ And that would be it. Regards. Postscript Given that "Potentially unsafe" label, for peace of mind you can always handle "serious matters" on another ("Potentially safe") computer.