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.
i don't see anything for base-system to do here
Created attachment 329668 [details, diff] a patch for ignoring /etc/os-release in lsb_release
I was also affected by this bug. I attached a patch that fixes the issue.
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`.
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.
Patch is applied in -r1. Thanks for the report.
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)
This was fixed a long time ago (and I'm sorry it wasn't handled properly).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7ef19adb0e10c30924d6d18509f5c840b60dd61c commit 7ef19adb0e10c30924d6d18509f5c840b60dd61c Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-30 07:38:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-30 08:18:41 +0000 sys-apps/lsb-release: add 3.2 Bug: https://bugs.gentoo.org/443116 Closes: https://bugs.gentoo.org/699538 Signed-off-by: Sam James <sam@gentoo.org> 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(+)
