Description of problem: I just installed SuperTux2 on my Lenovo desktop PC and clicked to start the executable from Start -> Games -> Arcade and nothing happened. I downloaded the latest source code from https://github.com/SuperTux/supertux/ and it's the same version, but to build it locally we need to add libraqm to the spec file and rebuild the package again. Version-Release number of selected component (if applicable): 0.5.1 How reproducible: All the time. Steps to Reproduce: 1. Use a Lenovo H515 desktop PC. 2. Login to MATE. 3. Install SuperTux2. 4. Open Start -> Games -> Arcade and click on SuperTux2. 5. Voila! Nothing happens.
CC: (none) => hamnisdude
[kristoffer@localhost supertux (master)]$ ./configure -- Boost version: 1.60.0 -- Found the following Boost libraries: -- filesystem -- system -- date_time -- locale -- Found OggVorbis: /usr/lib64/libvorbisfile.so;/usr/lib64/libvorbis.so;/usr/lib64/libogg.so -- Size of void* is 8 -- Checking for module 'raqm' -- No package 'raqm' found -- Could NOT find RAQM (missing: RAQM_INCLUDE_DIRS RAQM_LIBRARIES) CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: RAQM_LIBRARIES linked by target "supertux2_lib" in directory /home/kristoffer/Desktop/supertux -- Configuring incomplete, errors occurred!
(In reply to Kristoffer Grundström from comment #0) > Description of problem: I just installed SuperTux2 on my Lenovo desktop PC Running on LENOVO H215/Tilapia CRB, BIOS D2KT21AUS 03/12/2010 Logged into Xfce DE using lightdm as DM. > and clicked to start the executable from Start -> Games -> Arcade and > nothing happened. 2. Login to MATE. I need the output from cat /etc/sysconfig/desktop systemctl status display-manager.service | grep -E "PID|bin/" to configure my system to look like yours.
CC: (none) => bittwister2
cat /etc/sysconfig/desktop DISPLAYMANAGER=gdm systemctl status display-manager.service | grep -E "PID|bin/" Main PID: 1806 (gdm) └─1806 /usr/sbin/gdm -nodaemon
When you have these kinds of problems, you need to run the app in a terminal to see if there are any clues as to why it fails to start. In the gdm/mate setup it runs in the terminal and does not run from the menu. To find the terminal command you need to find the app_here.desktop file and get the run command from the Exec= directive. Example: $ locate supertux | grep \.desktop /usr/share/applications/supertux2.desktop $ grep Exec /usr/share/applications/supertux2.desktop Exec=supertux2 Now you know to run supertux2 Since DM is gdm, I tried gtk-launch supertux2.desktop in the terminal and it came up. It is entirely possible that it works in the terminal on my setup because I have a highly customized PATH and whatnot settings and have loaded a whole bunch of other games, DEs, DMs, and other packages.
Assignee: bugsquad => pkg-bugsCC: (none) => marja11
@ Kristoffer The summary of this report gives the impression it's about our supertux package, but then you only mention supertux2.... I'm confused!!
Keywords: (none) => NEEDINFOCC: (none) => rverschelde
(In reply to Marja Van Waes from comment #5) > @ Kristoffer > > The summary of this report gives the impression it's about our supertux > package, but then you only mention supertux2.... I'm confused!! Kristoffer, you did the same report for openarena, and we concluded that you changed you path so that /usr/games were removed from it. This is not the default for a new Mageia user, and is why the shortcut fails : it launches the binary without the full path. It is intended in mageia that all games are in /usr/games and not /usr/bin.
CC: (none) => lists.jjorge
(In reply to Marja Van Waes from comment #5) > @ Kristoffer > > The summary of this report gives the impression it's about our supertux > package, but then you only mention supertux2.... I'm confused!! # rpm --query --list supertux-0.5.1-8.mga7 | grep /usr/games/supertux2 /usr/games/supertux2
(In reply to José Jorge from comment #6) > (In reply to Marja Van Waes from comment #5) > Kristoffer, you did the same report for openarena, and we concluded that you > changed you path so that /usr/games were removed from it. This is not the > default for a new Mageia user, and is why the shortcut fails : it launches > the binary without the full path. > > It is intended in mageia that all games are in /usr/games and not /usr/bin. Hmmm, if desktop file launches in my terminal, but did not launch from the menu would not that suggest that whatever sets the path in the DE is at fault. I know in the past DE like kde had a /etc/ config file which sets PATH. quick google search suggests a /etc/gdm/gdm.conf contains the PATH= but there is no /etc/gdm/gdm.conf in the cauldron install.
(In reply to Marja Van Waes from comment #5) > @ Kristoffer > > The summary of this report gives the impression it's about our supertux > package, but then you only mention supertux2.... I'm confused!! Sorry, my bad! supertux. I remember seeing supertux2_lib in the error output so my brain automatically assumed that I'm trying to build supertux2.
(In reply to José Jorge from comment #6) > (In reply to Marja Van Waes from comment #5) > > @ Kristoffer > > > > The summary of this report gives the impression it's about our supertux > > package, but then you only mention supertux2.... I'm confused!! > > Kristoffer, you did the same report for openarena, and we concluded that you > changed you path so that /usr/games were removed from it. This is not the > default for a new Mageia user, and is why the shortcut fails : it launches > the binary without the full path. > > It is intended in mageia that all games are in /usr/games and not /usr/bin. But I didn't change it manually. /usr/games didn't show up by default in my system $PATH. echo $PATH �/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib64/qt4/bin:/usr/lib64/qt5/bin
Version: Cauldron => 6
Had to change it to Mageia 6 instead of Cauldron.
However, it still does not work to start it from terminal. [kristoffer@localhost ~]$ locate supertux | grep \.desktop /usr/share/applications/supertux2.desktop [kristoffer@localhost ~]$ grep Exec /usr/share/applications/supertux2.desktop Exec=supertux2 [kristoffer@localhost ~]$ supertux2 bash: supertux2: command not found [kristoffer@localhost ~]$ gtk-launch supertux2.desktop gtk-launch: no such program supertux2.desktop
Well, on my setup (mga6/cauldron) $ grep Exec /usr/share/applications/supertux2.desktop Exec=supertux2 $ type supertux2 supertux2 is /usr/games/supertux2 $ /usr/games/supertux2 will launch supertux2 The type command is kinda like the which command, but can be a bit more informative. Both commands use the PATH variable to look for programs. In this case if $PATH does not contain /usr/games, neither command will return location of supertux2. Run echo $PATH to check your path. mga6 path would look something like /usr/local/bin:/usr/bin:/usr/local/games:/usr/games:/usr/lib64/qt4/bin:/usr/lib64/qt5/bin
(In reply to Kristoffer Grundström from comment #10) > (In reply to José Jorge from comment #6) > > > > It is intended in mageia that all games are in /usr/games and not /usr/bin. > > But I didn't change it manually. Heheh, but you could have manually cause it to change. > /usr/games didn't show up by default in my system $PATH. > > echo $PATH > �/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib64/qt4/ > bin:/usr/lib64/qt5/bin Usual progression of setup is /etc/profile /etc/bashrc $HOME/.bash_profile $HOME/.bashrc I can recommend that you create a test account, say junk, log out of your user account and into junk. Click up a terminal and run echo $PATH to verify it matches your user account's PATH.
(In reply to Bit Twister from comment #14) > (In reply to Kristoffer Grundström from comment #10) > > (In reply to José Jorge from comment #6) > > > > > > > It is intended in mageia that all games are in /usr/games and not /usr/bin. > > > > But I didn't change it manually. > > Heheh, but you could have manually cause it to change. > > > > /usr/games didn't show up by default in my system $PATH. > > > > echo $PATH > > �/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib64/qt4/ > > bin:/usr/lib64/qt5/bin > > Usual progression of setup is > /etc/profile > /etc/bashrc > $HOME/.bash_profile > $HOME/.bashrc > > I can recommend that you create a test account, say junk, log out of your > user account and into junk. Click up a terminal and run echo $PATH to verify > it matches your user account's PATH. I upgraded to Cauldron (YES I know that it's meant to be unstable and that things do crash and behave oddly, but I like to see if the problem is fixed in Mageia 7 so I can maybe close this report) and then did as you told me to. I created a new user called junk and logged into MATE. I opened the terminal window and wrote echo $PATH and still I have the same result as in my regular user account. [junk@localhost ~]$ echo $PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib64/qt5/bin:/usr/lib64/qt4/bin What's next?
(In reply to Kristoffer Grundström from comment #15) > I upgraded to Cauldron (YES I know that it's meant to be unstable and that > things do crash and behave oddly, but I like to see if the problem is fixed > in Mageia 7 so I can maybe close this report) and then did as you told me to. How unfortunate. If you do not have a mga6 gdm/mate install where you can create the junk account and run the test then I suggest you have to change this bug report Version back to cauldron. > I created a new user called junk and logged into MATE. > > I opened the terminal window and wrote echo $PATH and still I have the same > result as in my regular user account. > > [junk@localhost ~]$ echo $PATH > /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib64/qt5/ > bin:/usr/lib64/qt4/bin > > What's next? All the tests in this bug shows two problems. First problem to be fixed is getting the PATH environment variable fixed to have /usr/local/games. The second problem is that the game does not run from the DE gui/task menu even if it works from a terminal with /usr/local/games in $PATH; see Comment #8 If problem is in mga6, then I suggest that should drive the decision as to which Version this bug should have.
(In reply to Bit Twister from comment #13) > $ type supertux2 > supertux2 is /usr/games/supertux2 > That does not work for me in Cauldron. I even deleted the 2 in supertux, but that didn't work either. > $ /usr/games/supertux2 > will launch supertux2 Yes, that launched Supertux2.
(In reply to Kristoffer Grundström from comment #15) > [junk@localhost ~]$ echo $PATH > /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib64/qt5/ > bin:/usr/lib64/qt4/bin > > What's next? Looking at the /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin suggests /etc/profile thinks you are root or some system account. In you user account, click up a terminal and show us the results from grep $USER /etc/profile grep junk /etc/profile > I upgraded to Cauldron Upgrade may have not have upgraded the code causing your problem. Clean install would have been better. I keep separate partitions, one is cauldron, the other is the "Production" release. I would also like to know what iso was used to install gdm/mate. clasic, gnome live, netinstal,..... and the results from ls -1 /usr/share/xsessions/*
(In reply to Bit Twister from comment #18) > > In you user account, click up a terminal and show us the results from > grep $USER /etc/profile > grep junk /etc/profile That resulted in 2 blank rows. [junk@localhost ~]$ grep $USER /etc/profile [junk@localhost ~]$ grep junk /etc/profile [junk@localhost ~]$ > I would also like to know what iso was used to install gdm/mate. > clasic, gnome live, netinstal,..... Net-install iso. > and the results from > ls -1 /usr/share/xsessions/* The result is: [junk@localhost ~]$ ls -1 /usr/share/xsessions/* /usr/share/xsessions/cinnamon2d.desktop /usr/share/xsessions/cinnamon.desktop /usr/share/xsessions/gnome.desktop /usr/share/xsessions/gnome-xorg.desktop /usr/share/xsessions/icewm.desktop /usr/share/xsessions/icewm-session.desktop /usr/share/xsessions/mate.desktop
(In reply to Kristoffer Grundström from comment #19) > (In reply to Bit Twister from comment #18) > > > > In you user account, click up a terminal and show us the results from > > grep $USER /etc/profile > > grep junk /etc/profile > > That resulted in 2 blank rows. OH, sorry. That should have been grep $USER /etc/passwd grep junk /etc/passwd
Mate with gdm. x86_64 $ path /usr/local/bin /usr/local/sbin /usr/bin /usr/sbin /bin /sbin /usr/lib64/qt4/bin /usr/lib64/qt5/bin /home/lcl/bin /sbin ? [lcl@difda ~]$ grep $USER /etc/passwd lcl:x:1000:1000:Len Lawrence:/home/lcl:/bin/bash [lcl@difda ~]$ grep junk /etc/passwd "games" appears twice in $PATH with sddm. Don't recall which iso was used for installation but it was most probably the latest release net-install.
CC: (none) => tarazed25
(In reply to Len Lawrence from comment #21) > [lcl@difda ~]$ grep $USER /etc/passwd > lcl:x:1000:1000:Len Lawrence:/home/lcl:/bin/bash 1000 rules out UID is the problem. > [lcl@difda ~]$ grep junk /etc/passwd Guessing you are not in the Cauldron install because you gave results for junk in Comment #15 If you were to read /etc/profile, it adds /usr/local/games to path if user logging in has a UID greater than 999. > "games" appears twice in $PATH with sddm. > Don't recall which iso was used for installation but it was most probably > the latest release net-install. I did want to see the results of PATH in the junk account terminal. Reason being, I would be able to assume a known ~junk/.bash_profile and ~junk/.bashrc contents. You might want to verify PATH is not set/changed in your lcl files. grep PATH= ~/.bash_profile grep PATH= ~/.bashrc grep PATH= ~/.profile If nothing found, that rules out those files are causing the problem. Ignore .profile not found message if grep can not find it. If junk's terminal PATH has games, and panel menu launch still fails, it is a system problem and you have a valid bug.
Sorry - did not understand about junk - came late to the party. As user junk it was not possible to login to Mate. Ended up in GNOME. The PATH variable contained no "games".
uid for junk was 1001. As lcl: $ rpm -qa | grep supertux supertux-0.5.1-1.mga6 supertux-data-0.5.1-1.mga6 $ supertux2 bash: supertux2: command not found $ cat /etc/sysconfig/desktop DISPLAYMANAGER=GNOME Exec=supertux2 in /usr/share/applications/supertux2.desktop. $ /usr/games/supertux2 That starts up the game OK. Maybe we need a link from /usr/bin.
So, back to sddm. Neither junk nor lcl have problems with games because /usr/games is on their paths. And, junk can login to Mate. More than one problem with gdm.
(In reply to Len Lawrence from comment #23) > Sorry - did not understand about junk - came late to the party. I am sorry, I did not look to see who was talking. Thought you were Kristoffer > As user junk it was not possible to login to Mate. Ended up in GNOME. The > PATH variable contained no "games". That shows up a new problem. Mate worked with DM=gdm (In reply to Len Lawrence from comment #24) > uid for junk was 1001. > > As lcl: > $ rpm -qa | grep supertux > supertux-0.5.1-1.mga6 > supertux-data-0.5.1-1.mga6 Ok, now we know you are on Release 6 > $ supertux2 > bash: supertux2: command not found > $ cat /etc/sysconfig/desktop > DISPLAYMANAGER=GNOME > > Exec=supertux2 in /usr/share/applications/supertux2.desktop. > > $ /usr/games/supertux2 > That starts up the game OK. > > Maybe we need a link from /usr/bin. No, just need PATH to have the games location. Supposedly, /etc/profile sets the PATH to have games if user ID > 999. For some reason we now see different DMs are not setting PATH via /etc/profile or something is overwriting it. The fact that PATH has the sbin/ stuff still seems to point to UID being less than 1000 at the time /etc/profile is executed, if executed at all. You could put echo "/usr/bin/id " > /var/local/profile.tmp echo "/usr/bin/id --real" >> /var/local/profile.tmp after the HISTSIZE=1000 line After login, click up a terminal and cat /var/local/profile.tmp Do remember to back out those changes. I am at the end of my knowledge base as to what to look at next.
(In reply to Bit Twister from comment #26) > > You could put > echo "/usr/bin/id " > /var/local/profile.tmp > echo "/usr/bin/id --real" >> /var/local/profile.tmp > after the HISTSIZE=1000 line Oops, wrong location. New an improved: echo "id: $(/usr/bin/id) " > /var/tmp/profile.tmp echo "id real: $(/usr/bin/id --real -u)" >> /var/tmp/profile.tmp echo "$PATH" >> /var/tmp/profile.tmp Terminal path is correct for DM=gdm DE-Mate $ cat /var/tmp/profile.tmp id: uid=1005(mate) gid=1005(mate) groups=1005(mate) id real: 1005 /usr/local/bin:/usr/bin:/usr/local/games:/usr/games
MGA6-32 on IBM Thinkpad R50e MATE LightDM $ echo $PATH /usr/local/bin:/usr/bin:/usr/local/games:/usr/games:/usr/lib/qt4/bin:/usr/lib/qt5/bin:/home/tester6/.local/bin:/home/tester6/bin This is my updates testing machine, so has hedgewars and minetest installed as games. Will test supertux a bit later.
CC: (none) => herman.viaene
Installed supertux and I can launch it and move the penguin. At CLI I get: $ supertux2 Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started AL lib: (WW) ALCjackBackendFactory_init: jack_client_open() failed, 0x11 AL lib: (WW) alc_initconfig: Failed to initialize backend "jack" [SQUIRREL] [DEBUG] Underground state initialized [WARNING] /home/iurt/rpmbuild/BUILD/SuperTux-v0.5.1-Source/src/supertux/sector.cpp:265 [levels/misc/menu.stl] Tried spawning Tux in solid matter. Compensating.
Got the new update, but it still doesn't start from cli. Command not found.
(In reply to Kristoffer Grundström from comment #30) > Got the new update, but it still doesn't start from cli. > > Command not found. Add the code in comment #27, log out/in and cat /var/tmp/profile.tmp
Created attachment 10415 [details] Result of commands from comment #27
Is this issue still valid in Mageia 7 or Cauldron?
Component: New RPM package request => RPM PackagesAssignee: pkg-bugs => rverschelde
Summary: SuperTux does not open on a LENOVO desktop PC => PATH lacks /usr/games on a LENOVO desktop PCSource RPM: supertux => (none)Assignee: rverschelde => pkg-bugs
That's not related to supertux, but Kristoffer had a bogus PATH which lacks `/usr/games` and `/usr/local/games`, which are defined on Mageia. I don't know why but that means that /etc/profile (package setup) was not run by the OS on profile creation, which is the one responsible for adding those two entries to the default PATH. One possibility could be if Mageia was using the same user profile as a different distro, where PATH had been overridden already in e.g. `~/.bash_profile`. In any case, if the problem is still reproducible, more detailed steps to reproduce would be necessary. It's highly unlikely to be related to the hardware/maker, but to the installation process instead.
Source RPM: (none) => setup
(In reply to Marja Van Waes from comment #33) > Is this issue still valid in Mageia 7 or Cauldron? I just used the netinstall iso to install Mageia 7 and I now get no menu entry at all after installing supertux supertux-data and /usr/games is still missing in $PATH
[kristoffer@localhost ~]$ echo "id: $(/usr/bin/id) " > /var/tmp/profile.tmp [kristoffer@localhost ~]$ echo "id real: $(/usr/bin/id --real -u)" >> /var/tmp/profile.tmp [kristoffer@localhost ~]$ echo "$PATH" >> /var/tmp/profile.tmp [kristoffer@localhost ~]$ cat /var/tmp/profile.tmp id: uid=1000(kristoffer) gid=1000(kristoffer) grupper=1000(kristoffer) id real: 1000 /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib64/qt5/bin
Created attachment 11316 [details] Loading supertuxkart2 Here's the result of loading the supertuxkart binary manually in /usr/games/
(In reply to Kristoffer Grundström from comment #37) > Created attachment 11316 [details] > Loading supertuxkart2 > > Here's the result of loading the supertuxkart binary manually in /usr/games/ That works. How strange!
(In reply to Rémi Verschelde from comment #34) > That's not related to supertux, but Kristoffer had a bogus PATH which lacks > `/usr/games` and `/usr/local/games`, which are defined on Mageia. > > I don't know why but that means that /etc/profile (package setup) was not > run by the OS on profile creation, which is the one responsible for adding > those two entries to the default PATH. > > One possibility could be if Mageia was using the same user profile as a > different distro, where PATH had been overridden already in e.g. > `~/.bash_profile`. > > In any case, if the problem is still reproducible, more detailed steps to > reproduce would be necessary. It's highly unlikely to be related to the > hardware/maker, but to the installation process instead. Thanks, Rémi. Kristoffer, do you still have this issue in a *super*clean* install of Mageia 7.1 or 8-cauldron, *without* re-using the existing /home directory and without linking anything in the new home to formerly used data? No need to wipe your current /home, just don't use it for this install ;-) If so, if you installed one of the Lives, then please attach journal.txt that is the result of running in that installed system, as root: journalctl -ab1 > journal.txt (Compress with xz if it's too large to attach) ((Note that on mga, you can compress it further by using "xz -9 --text")) If it was a classical install, then please attach /root/drakx/report.bug.xz from that installed system.
This message is a reminder that Mageia 6 is end of life. Mageia stopped maintaining and issuing updates for Mageia 6. At that time this bug will be closed as OLD (EOL). Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 6's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we cannot be able to fix it before Mageia 6 was end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
Resolution: (none) => OLDStatus: NEW => RESOLVEDCC: (none) => ouaurelien