|Summary:||sys-apps/lsb-release with sys-apps/baselayout-2.2 - /etc/os-release breaks lsb-release|
|Product:||Gentoo Linux||Reporter:||Daniel Scharrer <daniel>|
|Component:||Current packages||Assignee:||Gentoo's Team for Core System packages <base-system>|
|Severity:||normal||CC:||adaptee, alexanderyt, meklu|
|Package list:||Runtime testing required:||---|
|Attachments:||a patch for ignoring /etc/os-release in lsb_release|
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 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) 2014-06-04 23:25:33 UTC
Patch is applied in -r1. Thanks for the report.
Comment 7 Arsen Arsenovic 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)