Gentoo Linux does not use /etc/os-release and lsb_release returns: LSB Version: n/a.
Looks like an os-release file to me, maybe it's just on new installs, not sure not a Gentoo user.
Still, most major distro's use os-release, those that don't are considering/implementing it. Steam's target distro uses os-release it doesn't make sense to call a script that people may not have when the info is sat there in a file.
@Meyithi It looks like Gentoo is using /etc/gentoo-release for itself, and the subversion repository you pointed to is the baselayout-1 repo which has been retired in favor of baselayout-2 and openrc. That being said, Steam appears to find /etc/gentoo-release.
For what it is worth:
Debian (6.0/Squeeze) does not have either /etc/os-release, /etc/debian-release, or lsb_release.
Fedora (16/Verne) has an lsb_release and an /etc/fedora-release, but no /etc/os-release.
One suggestion would be that during a HW survey would be to attempt to install lsb_release, that'd probably require updating the client dependency requirements, then dropping them again afterwards
(iirc, Debian Squeeze requires the lsb-release installed to get it's functionality, Fedora has it in redhat-lsb-core, Fedora 17 has /etc/os-release from fedora-release. no doubt each system has it's own special package name for this stuff which kinda nullifies the whole idea of a single one stop shop for distro info but I digress in oldman rage)
It seems that this is the cause of the distro that's showing up in the current (published early March) Hardware & Software Survey results as "Linux 64 bit".
(that doesn't really add much to the discussion, but a comment is the only way I can get updates on this issue without watching the entire repo >_< )
Well, you could look for distro-specific files like I've been doing in my system info script, since not every distro is bound to have systemd and /etc/os-release. Here's an ugly excerpt:
lsb_release >/dev/null 2>/dev/null
if [ $? = 0 ]
then
lsb_release -ds | sed 's/^\"//g;s/\"$//g'
# a bunch of fallbacks if no lsb_release is available
# first trying /etc/os-release which is provided by systemd
elif [ -f /etc/os-release ]
then
source /etc/os-release
if [ -n "${PRETTY_NAME}" ]
then
printf "${PRETTY_NAME}\n"
else
printf "${NAME}"
[[ -n "${VERSION}" ]] && printf " ${VERSION}"
printf "\n"
fi
# now looking at distro-specific files
elif [ -f /etc/arch-release ]
then
printf "Arch Linux\n"
elif [ -f /etc/gentoo-release ]
then
cat /etc/gentoo-release
elif [ -f /etc/fedora-release ]
then
cat /etc/fedora-release
elif [ -f /etc/redhat-release ]
then
cat /etc/redhat-release
elif [ -f /etc/debian_version ]
then
printf "Debian GNU/Linux " ; cat /etc/debian_version
else
printf "Unknown\n"
fi
We don't use the lsb_release script. Thanks for the suggestions though!
If steam doesn't print out useful information at startup for your distribution, feel free to submit a new issue with a patch for steam.sh to add functionality for your distribution.
The hardware survey correctly detects a number of distributions on the data side but hasn't been wired up with the appropriate output.
I didn't realise that the System Information tool used what was gathered from steam.sh, but that's good to know. Thanks :D
(it's also good to hear that the survey data has extra depth that can be explored)
Edit: It's just been pointed out to me that lsb_release and lsb-release are different creatures. Never mind ^_^
I think you've probably correctly identified the 'real' problem there, Cheese. afaik & iirc /etc/lsb-release is deprecated for which lsb_release output. A patch for lines 131-132 to use lsb_release in preference might fix up a fair amount for newer boxen (of course, it may add some new dependencies...) Also also afaik iirc what line 132 appears to do would be remarkably similar to 'lsb_release -sd' which gives here "Fedora release 17 (Beefy Miracle)". Of course, ymmv depending on which lsb_release you have, and I'm not overly inclined right now to go digging in it's historical codebase so I'll leave that to you, Cheese :)
Rightio, so if you're a little crazy like me and feel the need to punk the Steam Hardware Survey on machines that have lsb_release, you could echo "DISTRIB_RELEASE=\"Plan 9 on Z80\"" > /etc/lsb-release
Here's a quick diff that'll stop such silly behaviour appearing in the HW Survey results:
--- steam_orig.sh 2013-03-07 05:47:55.462263097 +1100
+++ steam.sh 2013-03-07 06:20:01.750367885 +1100
@@ -128,7 +128,9 @@
function detect_distro()
{
- if [ -f /etc/lsb-release ]; then
+ if [ -f /usr/bin/lsb_release ]; then
+ (/usr/bin/lsb_release -si)
+ elif [ -f /etc/lsb-release ]; then
(. /etc/lsb-release; echo $DISTRIB_ID | tr '[A-Z]' '[a-z]')
elif [ -f /etc/os-release ]; then
(. /etc/os-release; echo $ID | tr '[A-Z]' '[a-z]')
@@ -140,7 +142,9 @@
function detect_release()
{
- if [ -f /etc/lsb-release ]; then
+ if [ -f /usr/bin/lsb_release ]; then
+ (/usr/bin/lsb_release -sr)
+ elif [ -f /etc/lsb-release ]; then
(. /etc/lsb-release; echo $DISTRIB_RELEASE)
elif [ -f /etc/os-release ]; then
(. /etc/os-release; echo $VERSION_ID)
With this in place here,
Running Steam on Plan 9 on Z80 64-bit
becomes
Running Steam on Fedora 17 64-bit
I'd be interested how this works out for others who have lsb_release and things like /etc/os-release, etc.
It wouldn't be much hard harder to replace /usr/bin/lsb_release with something that returns "NetBSD 2k on Gameboy Color"...
or even to just change steam.sh
Oh, totally. My punking example was more to explicitly test and describe the code that, I believe, more correctly addresses the issue that Slouken commented upon and Cheese raised. I should probably file the diff as a new ticket, though...
The primary method to detect the distribution name and release really should be /etc/os-release. While introduced (and afaik required) by SystemD, it's it's own independent spec. For example Gentoo with baselayout 2.2 will have it, even without SystemD (breaking lsb_release in the process, which isn't even installed by default):
$ qfile -v /etc/os-release
sys-apps/baselayout-2.2 (/etc/os-release)
Afaik, /etc/lsb-release was never meant to be read directly, only via the lsb_release script (and hardcoding paths for that seems wrong).
I know this is an old, closed ticket, but for what it's worth, I have noticed on some Debian systems when upgrading the OS, /etc/os-release does not get updated.
For example Debian 7.0 upgraded to 7.1 still reads as:
$ cat os-release
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"
ID=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="http://bugs.debian.org/"
lsb_release -a read correctly
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.1 (wheezy)
Release: 7.1
Codename: wheezy
Not every distro have the command lsb_release installed by default.
Almost all modern distros use /etc/os-release (Debian, Ubuntu, openSUSE, Fedora, Arch, ...).
Please use that instead.
Nothing extracted yet.
The client should parse /etc/os-release instead of depending on the lsb_release script.
I know only Ubuntu is supported (which coincidentally has an /etc/os-release file) but a lot of distro's which have /etc/os-release will not have lsb_release installed as default (such as Arch Linux) so there is no way of knowing the host distro.