Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 443116 - sys-apps/lsb-release with sys-apps/baselayout-2.2 - /etc/os-release breaks lsb-release
Summary: sys-apps/lsb-release with sys-apps/baselayout-2.2 - /etc/os-release breaks ls...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
Keywords: PATCH
Depends on:
Reported: 2012-11-14 15:32 UTC by Daniel Scharrer
Modified: 2022-07-30 08:19 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---

a patch for ignoring /etc/os-release in lsb_release (lsb_release-systemd-fix.patch,704 bytes, patch)
2012-11-16 16:57 UTC, Melker Narikka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Scharrer 2012-11-14 15:32:16 UTC
Since the addition of /etc/os-release to sys-apps/baselayout, lsb_release gives the following output:

$ lsb_release -a
LSB Version:    n/a
Distributor ID: Gentoo
Description:    NAME=Gentoo
Release:        n/a
Codename:       n/a

whereas before it was something like

$ lsb_release -a
LSB Version:    n/a
Distributor ID: Gentoo
Description:    Gentoo Base System release 2.1
Release:        2.1
Codename:       n/a

The 'NAME=' prefix in the description is obviously undesirable for programs that don't know about /etc/os-release themselves yet.

Reproducible: Always

Steps to Reproduce:
1. lsb_release -d
Actual Results:  
Description:    NAME=Gentoo

Expected Results:  
Description:    Gentoo Base System release 2.2

This is caused by /usr/bin/lsb_release running
$ find /etc/ -maxdepth 1 -name \*release -and ! -name lsb-release -and -type f | head -1
While previously the only result of the find was /etc/gentoo-release, not there are both /etc/gentoo-release and /etc/os-release -- and on my system unfortunately /etc/os-release comes first.

Maybe lsb_release can be modified to ignore os-release for that find (like it does with lsb-release) -- or the the description and version field could be added to /etc/lsb-release, but that probably isn't possible in sys-apps/lsb-release.
Comment 1 SpanKY gentoo-dev 2012-11-14 23:28:11 UTC
i don't see anything for base-system to do here
Comment 2 Melker Narikka 2012-11-16 16:57:45 UTC
Created attachment 329668 [details, diff]
a patch for ignoring /etc/os-release in lsb_release
Comment 3 Melker Narikka 2012-11-16 16:58:32 UTC
I was also affected by this bug. I attached a patch that fixes the issue.
Comment 4 James Geboski (jgeboski) 2014-01-15 03:47:01 UTC
I have been experiencing this issue as well.

I first discovered this issue with the usage of `lsb_release` by Mumble. When connecting to a Mumble server, `lsb_release -s -d` is executed to retrieve OS information which is sent to the server. When `lsb_release` fails, it leads to Mumble hanging up for a few seconds upon connecting. This is certainly a Mumble issue as well, but not the root cause.

This issue is dependent on the ordering of the `find` results. On several boxes of mine, `find` will sort the results naturally, however, on other boxes it does it in reverse. This is why some boxes have yet to feel the effects of this issue. Aside from just ignoring 'os-release', for the sake of consistency, `lsb_release' should also sort the results of `find`.
Comment 5 Daniel Scharrer 2014-06-04 23:06:07 UTC
sys-apps/baselayout 2.2 is now the only version in the tree, meaning this affects all users of lsb_release.

Maintainer: Is there any reason not to apply the attached patch or upgrade to a fixed lsb_release version (if there is any).

I'm having trouble finding any upstream bug tracker our source repository for the lsb utilities so I don't know where else to send the patch.

Note that `lsb_release` is of interest outside general LSB support as before /etc/os-release it was the most consistent way to determine the distribution name - and it is still used for that by some applications.
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2014-06-04 23:25:33 UTC
Patch is applied in -r1. Thanks for the report.
Comment 7 Arsen Arsenović gentoo-dev 2018-08-18 16:41:52 UTC
Why has the patch also not moved into arch (as opposed to ~arch) - it's been four years since the patch went into ~arch (and this is such a rare issue that it's only been rediscovered now)
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-30 07:37:59 UTC
This was fixed a long time ago (and I'm sorry it wasn't handled properly).
Comment 9 Larry the Git Cow gentoo-dev 2022-07-30 08:19:44 UTC
The bug has been referenced in the following commit(s):

commit 7ef19adb0e10c30924d6d18509f5c840b60dd61c
Author:     Sam James <>
AuthorDate: 2022-07-30 07:38:28 +0000
Commit:     Sam James <>
CommitDate: 2022-07-30 08:18:41 +0000

    sys-apps/lsb-release: add 3.2
    Signed-off-by: Sam James <>

 sys-apps/lsb-release/Manifest               |  1 +
 sys-apps/lsb-release/lsb-release-3.2.ebuild | 41 +++++++++++++++++++++++++++++
 sys-apps/lsb-release/metadata.xml           |  1 +
 3 files changed, 43 insertions(+)