After emerging UT2004 (3339) via the Gentoo ebuild I found that the KDE menu entry did not contain the right command. The command used ut2004 failed obviously because the right path could not be found. After changing the command line to /opt/ut2004/ut2004 the KDE menu entry worked OK. Reproducible: Always Steps to Reproduce: 1. 2. 3. bash-2.05b# emerge info Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r8 i686) ================================================================= System uname: 2.6.9-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://GentooMirror/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://GentooMirror/gentoo-portage" USE="X X509 acpi acpi4linux alsa apache2 apm arts artswrappersuid avi berkdb bitmap-fonts cdr cgi chroot cjk crypt css cups curl dga directfb divx4linux doc dvd dvdr encode exif f77 fam fbcon font-server foomaticdb foreign-package foreign-sysvinit fortran freetype fs ftp gcj gdbm gif gphoto2 gpm gtk2imagemagick imap imlib innodb java javascript joystick jpeg jpeg2k kde kdexdeltas kerberos krb4 lcd libg++ libwww mad md5sum memlimit mikmod mime mmx mmx2 motif mozcalendar mozilla mozsvg mozxmlterm mpeg msn nas ncurses nls no-old-linux noreiserfs nptl nvidia oav odbc offensive oggvorbis opengl openssh oss pam pcap pdf pdflib perl png pnp ppds python qt quicktime readline rtc samba scanner sdl silc skey slp snmp speedo spell sse sse2 ssl svg svga tcpd tiff transcode truetype truetype-fonts trusted type1 type1-fonts unicode usb wifi wmf wxwindows x86 xml2 xmms xprint xscreensaver xv xvid zlib"
You need to add yourself to the games group and log in again. the ut2400 wrapper is installed in /usr/games/bin which will then be in your path.
I may be missing your point or otherwise doing something wrong. I have a very simple setup, only user "root". To be sure, I added root to the games group, but /usr/games/bin still isn't in my path, see attachment.
Created attachment 45198 [details] Console output from within KDE
The file /usr/games/bin/ut2004 does exist and executes correctly, it's just the path that is missing.
Have you logged out and back in? Group changes do not take affect on currently-logged in consoles. Also, you should *never* run as root.
Yes I've redone the login and it doesn't help. I probably can tell you why: bash-2.05b# echo $PATH /usr/kde/3.3/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/sbin:/usr/kde/3.3/bin bash-2.05b# I don't quite understand your second remark. It's up to me to choose how to protect my system isn't it? If the ebuild cannot be installed as root, tell me. Finally, can we please leave this bug open until it's clear where one of us wrong? This constant "invalid" setting gets on my nerves...
what you see if a feature, not a bug root users shouldnt be playing games, thus we dont add /usr/games/bin/ to the default PATH for the root user if you wish to play games as root, add /usr/games/bin to your PATH in your config files also, there's no reason to be rude, the bug is closed because the behavior you're seeing is correct and what you think you want is INVALID for default settings
You are wrong. This bug is INVALID. You are not using the system as it was intended. The path for games is added to PATH, not to ROOTPATH. This bug is 100% INVALID simply because you are not working with the syste as it was intended. If you wish to use the system outside of our intention, there is nothing stopping you from doing so, but do not expect us to provide you support. Good day.
I may have to apologize. I did not want to be rude, and reading back I can only remember feeling a bit irritated because I felt I wasn't taken seriously. But, not being a native English speaker my wording apparently came out wrong. After all I created another user which I made a member of the games group and indeed for that user the PATH variable does contain the /usr/games/bin path. So it appears everything is as you said. I only ask: how could I know? However, if you feel uncomfortable with my remarks, there's no need to answer.
Well, during the installation, the Handbook[1] told you to create a user account. There are reasons for this besides security. The games team, using proper Linux behavior, sets up everything for non-root accounts. We take security very seriously. As I stated before, we build the system with the assumption that you will be following the Handbook and have no way to support when you do not. If you do not follow our instructions, then you simply cannot expect everything to work. There are no hard feelings, you just have to realize that we see hundreds and thousands of bugs. I can't even tell you how many times we have had this "problem" come up, so when we mark a bug as INVALID, it is because the bug is, in fact, invalid. [1]http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=11