Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 236770 - custom locale.gen lost while catalyst stage3 -> stage4
Summary: custom locale.gen lost while catalyst stage3 -> stage4
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 225309 245910 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-09-05 03:53 UTC by Peter Stuge
Modified: 2010-06-06 05:22 UTC (History)
3 users (show)

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


Attachments
output from strace -s 256 -o out -fF of running catalyst (strace.bz2,725.39 KB, application/octet-stream)
2008-09-07 19:11 UTC, Peter Stuge
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Stuge 2008-09-05 03:53:27 UTC
When building a stage4 system using catalyst, the glibc ebuild insists on always generating every possible locale.

Reproducible: Always

Steps to Reproduce:
1. Create suitable stage4.spec
2. Replace empty ./etc/locale.gen in stage3 tarball with one that has two locales "en_US ISO-8859-1" and "en_US.UTF-8 UTF-8"
3. catalyst -f stage4.spec

Actual Results:  
>>> Emerging (36 of 66) sys-libs/glibc-2.6.1 to /
 * >>> SetUID: [chmod go-r] /usr/lib/misc/glibc/pt_chown ... [ ok ]
sed: can't read /etc/locale.gen: No such file or directory
 * Generating all locales; edit /etc/locale.gen to save time/space
 * Generating locale-archive: forcing # of jobs to 1
 * Generating 381 locales (this might take a while) with 1 jobs


Expected Results:  
 * Generating 2 locales (this might take a while) with 1 jobs


Before I created this bug there was some discussion on the gentoo-catalyst mailing list:
http://archives.gentoo.org/gentoo-catalyst/msg_78552805cfb15121598ed765b593a1d4.xml


The following excerpts from the glibc ebuild seem to at least be part of the problem. 2.8 also looks the same way.

--8<-- glibc-2.6.1.ebuild
pkg_preinst() {
..
        # Shouldnt need to keep this updated
        [[ -e ${ROOT}/etc/locale.gen ]] && rm -f "${D}"/etc/locale.gen
..
}

pkg_postinst() {
..
        if ! is_crosscompile && [[ ${ROOT} == "/" ]] ; then
..
                # if the host locales.gen contains no entries, we'll
                # install everything
                local locale_list="${ROOT}etc/locale.gen" 
                if [[ -z $(locale-gen --list --config "${locale_list}") ]] ; then
                        ewarn "Generating all locales; edit /etc/locale.gen to save time/space"
..
}
-->8--
Comment 1 SpanKY gentoo-dev 2008-09-07 06:45:09 UTC
i dont know why you think those lines are a problem, but i'm pretty sure you're reading them wrong.  you didnt post the output from portage merging the package, but i'm guessing portage removed locale.gen for you.  notice how locale-gen says that /etc/locale.gen doesnt exist.  nowhere in the glibc ebuild does it modify any file in $ROOT/etc/.
Comment 2 Philipp Riegger 2008-09-07 08:40:46 UTC
So in order to have catalyst work nicely with locale.gen, there seems to be some word needed.

What about providing the default locale.gen in sys-libs/glibc/files? Then the user can overwrite it.

Or what about installing locale.gen in an extra ebuild, which can be "overwritten" by an ebuild in an overlay?

Or there is some general new way needed for providing profile/configuration files for ebuilds to catalyst.
Comment 3 Peter Stuge 2008-09-07 19:11:29 UTC
Created attachment 164844 [details]
output from strace -s 256 -o out -fF of running catalyst

> i dont know why you think those lines are a problem, but i'm pretty sure
> you're reading them wrong.

I'm not ruling that out at all. :)

> you didnt post the output from portage merging the package,

I did, in "Actual Results", note that at this point catalyst is using a binary package for glibc because it has been built before.
(This could in itself be another bug, maybe glibc should save locales in the tbz2?)

> but i'm guessing portage removed locale.gen for you.

It does.

> nowhere in the glibc ebuild does it modify any file in $ROOT/etc/.

Yet it is still during glibc emerge that /etc/locale.gen is removed from the stage4 root.

Please see if you can grok the attached strace from catalyst. I paused catalyst to attach strace when it had just printed the ebuild name. The unlink() is on line 40202.
Comment 4 SpanKY gentoo-dev 2008-09-21 07:21:42 UTC
those are all hacks.  just delete the locale.gen line in pkg_preinst().
Comment 5 Andrew Gaffney (RETIRED) gentoo-dev 2008-10-08 02:05:03 UTC
Whatever is going on here, it's not catalyst's fault
Comment 6 SpanKY gentoo-dev 2008-11-07 07:37:07 UTC
*** Bug 245910 has been marked as a duplicate of this bug. ***
Comment 7 SpanKY gentoo-dev 2008-12-07 22:13:00 UTC
*** Bug 225309 has been marked as a duplicate of this bug. ***
Comment 8 SpanKY gentoo-dev 2008-12-08 01:01:51 UTC
fixed in glibc-2.8_p20080602-r1 and glibc-2.9
Comment 9 Peter Stuge 2009-06-02 14:25:34 UTC
I'm sorry to report that the symptom persists with glibc-2.8_p20080602-r1. Have not tried 2.9, but I believe the fix was the same there.

Now the problem seems to be that /etc/locale.gen is being overwritten by the glibc ebuild itself, before locale generation in pkg_postinstall.

After catalyst has unpacked the (specially prepared) stage3 tarball, /etc/locale.gen is my file.

During glibc-2.8_p20080602-r1 postinstall, all locales are still generated. Looking at /etc/locale.gen it is now the default file, which lists no locales, which leads to all locales being generated.

grep 'locale\.gen' /var/tmp/catalyst/tmp/default/stage4-amd64-my.200905/var/db/pkg/sys-libs/glibc-2.8_p20080602-r1/CONTENTS 
obj /etc/locale.gen 9bfbcfea3e186c70fe5501512d367de2 1243901769

I'm sure it's actually a distinct problem from the one that has been fixed, but the description for this bug still applies. How to proceed? Reopen or new bug?
Comment 10 Peter Stuge 2009-06-22 17:26:02 UTC
Sorry, but am just now watching every single locale being generated.

My previous comment https://bugs.gentoo.org/show_bug.cgi?id=236770#c9 attempts to identify the problem.

I appreciate your input!
Comment 11 SpanKY gentoo-dev 2009-07-05 20:00:20 UTC
it needs to be doubly emerged.  the first emerge after the fix will still clobber the file, but the second will not.
Comment 12 Peter Stuge 2010-06-06 05:22:11 UTC
I'm just now building a fresh stage4 based on stage3-i686-20100601 (glibc-2.10.1-r1) plus my own locale.gen, and this problem persist.

As part of emerge --quiet --usepkg --buildpkg --newuse -u system catalyst emerges glibc-2.11.1, and in that process my own locale.gen is overwritten with the default one (which has all locales commented out) and thus I still end up with all locales being generated.

What can I provide to help fix this? And should I create a new bug or reopen this one? (See https://bugs.gentoo.org/show_bug.cgi?id=236770#c9)