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--
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/.
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.
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.
those are all hacks. just delete the locale.gen line in pkg_preinst().
Whatever is going on here, it's not catalyst's fault
*** Bug 245910 has been marked as a duplicate of this bug. ***
*** Bug 225309 has been marked as a duplicate of this bug. ***
fixed in glibc-2.8_p20080602-r1 and glibc-2.9
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?
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!
it needs to be doubly emerged. the first emerge after the fix will still clobber the file, but the second will not.
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)