Bug 1200193

Created attachment 1003200 [details]
Game log with all acceleration turned off.

Interestingly when all video and audio acceleration is turned off I don't get an obvious error message but the game still fails with a window filled with a solid color (grey the first time, blueish the second).

This seems to be system dependent, as I can run it on f21 (but i686).
I see the libpng warnings, so I don't think that is related to the problem.
I'll see about testing it with a live image on x86_64.

I've been in contact with upstream and apparently there have been a lot of video changes from 0.9.18 and 0.9.21 but 0.9.19 & 20 were never packaged for Fedora so I can't narrow down when the breakage took place.

I tried under x86_64 with rawhide and the game seems to work, though I get similar output to you:
[PHYSFS] Init: ok
[PHYSFS] Mounting '/usr/share/hedgewars/Data' to '/': ok
[PHYSFS] Mounting '/home/bruno/.hedgewars/Data' to '/': ok
[PHYSFS] Mounting '/home/bruno/.hedgewars' to '/': ok
[PHYSFS] Setting write dir to '/home/bruno/.hedgewars': ok
Starting Hedgewars 0.9.21-r10765 (31c744824dab)
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
[LAZINESS] ThemeModel::loadThemes()
Object::disconnect: Unexpected null parameter
QCoreApplication::postEvent: Unexpected null receiver

Getting a live f21 image with that version of hedgewars on it will be a bit of a pain. I suspect the issue may not really be with hedgewars.
I tested with an intel and an nVidia card using Nouveau.
You might try the live alpha games spin for f22 and see if you get the problem there.

Yes, both computers are running the Nvidia binary drivers from RPM Fusion as they both run MythTV.

I can try on my wife's f21 laptop with ATI hardware and open source drivers. Upstream indicated that the problem only shows up with the Nvidia drivers but he didn't say if the drivers or hedgewars (or some combination thereof) was actually at fault.

Someone in #fedora noticed this today, checking rpath:

/usr/bin/hwengine: RPATH=$ORIGIN/../lib64/:$ORIGIN/:/usr/lib64/


the /usr/lib64 there means anyone using ati/nvidia drivers will have problems using hedgewars

$ rpm -q hedgewars
hedgewars-0.9.21.1-3.fc20.i686

$ rpmlint hedgewars
hedgewars.i686: E: binary-or-shlib-defines-rpath /usr/bin/hwengine ['$ORIGIN/../lib/', '$ORIGIN/', '/usr/lib/']
hedgewars.i686: E: invalid-soname /usr/lib/libphyslayer.so libphyslayer.so
hedgewars.i686: E: binary-or-shlib-defines-rpath /usr/lib/libphyslayer.so ['$ORIGIN/../lib/', '$ORIGIN/', '/usr/lib/']
hedgewars.i686: E: binary-or-shlib-defines-rpath /usr/bin/hedgewars ['$ORIGIN/../lib/', '$ORIGIN/', '/usr/lib/']
hedgewars.i686: E: script-without-shebang /usr/share/appdata/hedgewars.appdata.xml
hedgewars.i686: W: no-manual-page-for-binary hwengine
hedgewars.i686: W: no-manual-page-for-binary hedgewars
hedgewars.i686: E: invalid-appdata-file /usr/share/appdata/hedgewars.appdata.xml
1 packages and 0 specfiles checked; 6 errors, 2 warnings.

the rpath-related ones are the main bits to worry about here.ge

Are you going to try to fix it in the build system or just brute force it via chrpath?

Thanks for tracking down the problem. I really don't grok rpath. It should get fixed in the builds. I should have noticed the problem, but didn't.
I'll try to work out a fix, but any suggestions from the peanut gallery would be welcome.

Ok, I'm tracking down the issue with the libraries, but the binary one is pretty simple, they're using the wrong install command in cmake:

install(PROGRAMS "${EXECUTABLE_OUTPUT_PATH}/hedgewars${CMAKE_EXECUTABLE_SUFFIX}" DESTINATION ${target_binary_install_dir})

Should use "install(TARGETS...)" instead. Install programs is more for scripts or prebuilt binaries.

Changing to TARGETS breaks the build, so the fix isn't quite that simple.
The error is:
CMake Error at QTfrontend/CMakeLists.txt:231 (install):
  install TARGETS given target
  "/home/bruno/fedora/hedgewars/hedgewars-src-0.9.21/bin/hedgewars" which
  does not exist in this directory.

Yes, it's a bit more than that, you have to specify if its a RUNTIME (bin) or LIBRARY (lib{,64}) as part of it, but that doesn't quite get it. They're intentionally setting the RPATH for some reason. I ASSUME they need it (or think they do) so I'm trying the surgical approach first by trying to set the RPATH to "" for the 3 problem files.

A side note related to the rpmlint output, is that for some reason the app data file gets set as executable during the build install. I need to manually override that.

Created attachment 1011593 [details]
Path for RPATH

Well, for some reason one of them won't play nice but it fixes the other two:
$ rpmlint ./hedgewars-0.9.21.1-3.fc23.x86_64.rpm 
hedgewars.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/hwengine ['$ORIGIN/../lib64/', '$ORIGIN/', '/usr/lib64/']
hedgewars.x86_64: E: invalid-soname /usr/lib64/libphyslayer.so libphyslayer.so
hedgewars.x86_64: E: script-without-shebang /usr/share/appdata/hedgewars.appdata.xml
hedgewars.x86_64: W: no-manual-page-for-binary hwengine
hedgewars.x86_64: W: no-manual-page-for-binary hedgewars
1 packages and 0 specfiles checked; 3 errors, 2 warnings.

But isn't hwengine theone that is most critical to fix?

Probably :) I just ran out of time last night to work on it. I've contacted someone upstream to ask if they really need to be setting rpath at all.

Created attachment 1011850 [details]
New patch which disables setting rpath

I have not tested the resultant package yet, I may have time to do that tonight after $DAYJOB.

$ rpmlint ./hedgewars-0.9.21.1-3.fc23.x86_64.rpm
hedgewars.x86_64: E: invalid-soname /usr/lib64/libphyslayer.so libphyslayer.so
hedgewars.x86_64: E: script-without-shebang /usr/share/appdata/hedgewars.appdata.xml
hedgewars.x86_64: W: no-manual-page-for-binary hwengine
hedgewars.x86_64: W: no-manual-page-for-binary hedgewars
1 packages and 0 specfiles checked; 2 errors, 2 warnings.

I think the $ORIGIN rpaths are less bad (and may or may actually not be needed by the game),

the one you want to omit specifically is:
${CMAKE_INSTALL_PREFIX}/${target_library_install_dir}/

So the minimal patch would look like:

diff -Naur hedgewars-src-0.9.21.orig/cmake_modules/paths.cmake hedgewars-src-0.9.21/cmake_modules/paths.cmake
--- hedgewars-src-0.9.21.orig/cmake_modules/paths.cmake	2014-10-02 10:53:26.000000000 -0500
+++ hedgewars-src-0.9.21/cmake_modules/paths.cmake	2015-04-07 10:54:17.399375270 -0500
@@ -66,5 +66,5 @@
     # - the second is the same directory of the executable (so it runs in bin/)
     # - the third one is the full path of the system dir
     #source http://www.cmake.org/pipermail/cmake/2008-January/019290.html
-    set(CMAKE_INSTALL_RPATH "$ORIGIN/../${target_library_install_dir}/:$ORIGIN/:${CMAKE_INSTALL_PREFIX}/${target_library_install_dir}/")
+    set(CMAKE_INSTALL_RPATH "$ORIGIN/../${target_library_install_dir}/:$ORIGIN/")
 endif(APPLE)

nevermind, $ORIGIN will get us in trouble for the same reasons as hard-coded /usr/lib (I think), comment #17 patch looks good.

Ok, I tested a build for f21 with the proposed patch and can report that I had no issues running the game. Upstream thought it was related to the changes to their GL code but apparently that is not the case.

hedgewars-0.9.21.1-4.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/hedgewars-0.9.21.1-4.fc21

Package hedgewars-0.9.21.1-4.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hedgewars-0.9.21.1-4.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-5858/hedgewars-0.9.21.1-4.fc21
then log in and leave karma (feedback).

hedgewars-0.9.21.1-4.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.