Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 795885 - sys-libs/glibc-2.33-r1: locale-gen error on prefix system (locale-gen 2.10)
Summary: sys-libs/glibc-2.33-r1: locale-gen error on prefix system (locale-gen 2.10)
Status: RESOLVED DUPLICATE of bug 779790
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-14 03:38 UTC by Marien Zwart
Modified: 2021-08-06 21:55 UTC (History)
1 user (show)

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


Attachments
emerge --info (emerge-info.txt,6.53 KB, text/plain)
2021-06-14 03:38 UTC, Marien Zwart
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marien Zwart 2021-06-14 03:38:18 UTC
Created attachment 715926 [details]
emerge --info

When installing sys-libs/glibc-2.33-r1 on a prefix install in /home/marienz/gentoo, locale-gen isn't getting its paths right:

>>> Original instance of package unmerged safely.
/home/marienz/gentoo/usr/sbin/locale-gen: line 166: /home/marienz/gentoousr/bin/localedef: No such file or directory
 * Unable to parse the output of your localedef utility.
 * File a bug about this issue and include the output of 'localedef --help'.
locale-gen --jobs 22 --config /home/marienz/gentoo//etc/locale.gen --destdir /home/marienz/gentoo/
 * Using locale.gen from /home/marienz/gentooetc/
 * Building locales in DESTDIR '/home/marienz/gentoo/'
 * Generating 2 locales (this might take a while) with 22 jobs
 *  (2/2) Generating C.UTF-8 ...                                                                                  [ ok ]
 *  (1/2) Generating en_US.UTF-8 ...                                                                              [ ok ]
 * Generation complete
 * Adding locales to archive ...                                                                                  [ ok ]

/home/marienz/gentoousr/bin/localedef does indeed not exist, but /home/marienz/gentoo/usr/bin/localedef works fine.

It looks like this happens because when EROOT is unset, locale-gen sets it with a trailing "/" (which it relies on for DESTDIR and CONFIG further on):

: ${EROOT:="${EPREFIX}/"}

But it's called from an EAPI 7 ebuild, which exports EROOT without a trailing "/". Running "EROOT=/home/marienz/gentoo locale-gen --list --config ~/gentoo/etc/locale.gen" reproduces the problem, but "locale-gen --list --config ~/gentoo/etc/locale.gen" (with EROOT unset) works correctly.

It looks like this is cosmetic, because of a second bug. The failing locale-gen run is the one to check if there are any locales configured, which it does by checking for any output to stdout:

        if [[ -z $(locale-gen --list --config "${locale_list}") ]] ; then
                [[ -z ${inplace} ]] && ewarn "Generating all locales; edit /etc/locale.gen to save time/space"
                locale_list="${root}/usr/share/i18n/SUPPORTED"
        fi

But on a prefix system, locale-gen prints a status message to stdout:

% EROOT=/home/marienz/gentoo locale-gen --list --config ~/gentoo/etc/locale.gen 2>/dev/null
 * Using locale.gen from /home/marienz/gentooetc/

That message is conditional on ${EROOT} != "/", so you won't see it on a "normal" system. But on a prefix system, the ebuild will always assume we have locales configured. The second invocation of locale-gen passes --destdir in addition to --config, which works around the EROOT issue entirely (the "Using locale.gen from /home/marienz/gentooetc/" is cosmetic: it's actually using locale.gen passed in as --config, which uses the correct path).

The status message should probably be behind "[ ${QUIET} -eq 0 ]] && [[ -z ${JUST_LIST} ]]" checks, like most of the rest of the einfo calls are (and report ${CONFIG} after setting that, not ${EROOT}etc/).
Comment 1 Andreas K. Hüttel archtester gentoo-dev 2021-08-06 21:55:54 UTC

*** This bug has been marked as a duplicate of bug 779790 ***