Description of problem: After installing 64 bit version of Sauerbraten, program failed to start with error: "could not load texture packages/textures/notex" and "could not find core textures". Problem is caused by user, during startup, being placed into /usr/lib64/sauerbraten, while data files have been installed (using no-arch data rpm) into /usr/lib/sauerbraten. Solved problem using two step method: 1) Created symbolic link: ln -s /usr/lib64/sauerbraten/bin_unix/ /usr/lib/sauerbraten/bin_unix 2) Modified startup script "/usr/bin/sauerbraten" line 5 From: ln -s /usr/lib64/sauerbraten/* $CUBE_DI To: ln -s /usr/lib/sauerbraten/* $CUBE_DI Version-Release number of selected component (if applicable): sauerbraten-data-2010_07_28-4.mga2.nonfree sauerbraten-2010_07_28-4.mga2.nonfree How reproducible: Every time Steps to Reproduce: 1. urpmi sauerbraten (on Mageia 2 64 bit install) 2. $ sauerbraten 3. observe failed startup
CC: (none) => kevin
Assignee: bugsquad => juan.baptisteSeverity: critical => major
Even after issuing the workaround by Kevin, still get the same response: $ sauerbraten init: sdl init: net init: game init: video: mode init: video: misc init: gl Renderer: Mesa DRI Intel(R) Sandybridge Mobile (Tungsten Graphics, Inc) Driver: 2.1 Mesa 8.0.2 WARNING: Disabling shaders for extra performance. (use "/shaders 1" to enable shaders if desired) Rendering using the OpenGL fixed-function path. could not load texture packages/textures/notexture.png could not find core textures
CC: (none) => isis2000
The problem is that the data package is marked as noarch but is being installed in /usr/{_libexecdir}/sauerbraten, which installs on /usr/lib and the launch script looks for the data files on /usr/lib64. The quick fix is to remove the BuildArch: noarch from the data package so it installs on /usr/lib64/sauerbraten, but the correct fix would be to make the data package install in a no arch dir like %{_gamesdatadir} (/usr/share/games) and make the launch script look for it there. It also should be a separate package so when updating it, the user doesn't have to re-download the ~300MB or more from the data files. I'm going to fix the package this way on cauldron, but I'm not sure if it's worth for the fix on Mga 2 as removing the noarch build tag also fixes the issue and the package move I plan will need much more testing than the quick fix. What does QA thinks ?
Status: NEW => ASSIGNED
Ok I'm going to do the quick fix for the mga 2 version and do the proper fix for cauldron.
Ok, I have added an updated version in nonfree/updates_testing, please install it and see if it works for you.
Removing noarch is not a proper fix, it will waste space on the mirrors (noarch packages are shared between all architectures). Better intall the date in %{_gamesdatadir}/%{name} and make the game look for this dir (or make a symlink, but then you have to handle upgrade properly)
CC: (none) => mageia
(In reply to comment #5) > Removing noarch is not a proper fix, it will waste space on the mirrors (noarch > packages are shared between all architectures). > Better intall the date in %{_gamesdatadir}/%{name} and make the game look for > this dir (or make a symlink, but then you have to handle upgrade properly) Yes, that's what I said on comment #2 and it is what I will do on cauldron, but it will need more testing on mga 2, that's why I asked for opinions before and as no one said anything I proceeded with the safest fix for mga 2.
So, is this update ready to be tested? It wasn't assigned to QA.
CC: (none) => stormi
With sauerbraten-2010_07_28-4.1.mga2.nonfree.x86_64.rpm and sauerbraten-data-2010_07_28-4.1.mga2.nonfree.x86_64.rpm I get: [samuel.verschelde@tech009 Documents]$ sauerbraten init: sdl init: net init: game init: video: mode init: video: misc init: gl Renderer: GeForce 310/PCIe/SSE2 (NVIDIA Corporation) Driver: 2.1.2 NVIDIA 295.49 Rendering using the OpenGL assembly/GLSL shader path. could not load texture packages/textures/notexture.png could not find core textures
In fact, after erasing ~/.cube, then it works. So although the fix works for new users, it won't for those who tested already. Is there a way to solve this too?
In addition to previous comment, sauerbraten loses my screen configuration (windowed, with a smaller resolution) each time I restart it, although it keeps key bindings and player name. Is that a known issue?
When you remove ~/.cube you will loose all your configuration, but it should remain through game launches after you configure the game again (while you don't remove that file again).
(In reply to comment #11) > When you remove ~/.cube you will loose all your configuration, but it should > remain through game launches after you configure the game again (while you > don't remove that file again). of course. My comment was without removing ~/.cube. Graphical configuration isn't kept, and the same for my colleague's computers.
I just did some tests with this version on core/updates_testing and for me is working ok, including the scenarios described by Samuel: 1. launch sauerbraten without an existing config in .cube. It launches ok. 2. launch sauerbraten with an existing config in .cube, this config has a different resolution than the default one. The game also launches ok. Also screen resolution is saved among restarts, even better, the game autodetected and automatically changed the resolution upon first launch, I didn't have to do anything to adjust it.
Forgot to mention, on cauldron sauerbraten was updated to the latest version 2013.01.07 collect edition, and this issue doesn't occur.
We have the latest 2013.02.03 version, closing this.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED