Locales with lexical sorting that differs from english will choke on the ebuild function "check_targets()" in qemu ebuilds with aarch64 in the target lists. Reproducible: Always Steps to Reproduce: LC_ALL=nb_NO.UTF-8 emerge -v qemu Actual Results: >>> Emerging (1 of 1) app-emulation/qemu-2.4.0.1-r1::gentoo * qemu-2.4.0.1.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking qemu-2.4.0.1.tar.bz2 to /var/tmp/portage/app-emulation/qemu-2.4.0.1-r1/work >>> Source unpacked in /var/tmp/portage/app-emulation/qemu-2.4.0.1-r1/work >>> Preparing source in /var/tmp/portage/app-emulation/qemu-2.4.0.1-r1/work/qemu-2.4.0.1 ... * The ebuild needs to be kept in sync. * IUSE_SOFTMMU_TARGETS: cris i386 lm32 m68k microblaze microblazeel mips mips64 mips64el mipsel moxie or32 ppc ppc64 ppcemb s390x sh4 sh4eb sparc sparc64 tricore unicore32 x86_64 xtensa xtensaeb aarch64 alpha arm * configure : alpha arm cris i386 lm32 m68k microblaze microblazeel mips mips64 mips64el mipsel moxie or32 ppc ppc64 ppcemb s390x sh4 sh4eb sparc sparc64 tricore unicore32 x86_64 xtensa xtensaeb aarch64 * ERROR: app-emulation/qemu-2.4.0.1-r1::gentoo failed (prepare phase): * sync IUSE_SOFTMMU_TARGETS to the list of targets * * Call stack: * ebuild.sh, line 90: Called src_prepare * environment, line 12474: Called check_targets 'IUSE_SOFTMMU_TARGETS' 'softmmu' * environment, line 8506: Called die * The specific snippet of code: * die "sync ${var} to the list of targets"; * * If you need support, post the output of `emerge --info '=app-emulation/qemu-2.4.0.1-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=app-emulation/qemu-2.4.0.1-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/app-emulation/qemu-2.4.0.1-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-emulation/qemu-2.4.0.1-r1/temp/environment'. * Working directory: '/var/tmp/portage/app-emulation/qemu-2.4.0.1-r1/work/qemu-2.4.0.1/default-configs' * S: '/var/tmp/portage/app-emulation/qemu-2.4.0.1-r1/work/qemu-2.4.0.1' Expected Results: That it merges. Nordic locales sorts "aa" after "z", because "aa" is an international/ascii-friendly way to write the letter "å". So if you make a function that compares two lists that are sorted alphabetically, you should force LC_ALL to be C to be sure it does not screw up in non-english locales.
i specifically wrote the sort code so that the locale it's run under should not matter. i don't have a hardcoded list which is then compared against a locale sorted list ... both lists get run through `sort -u` which means the result should be the same. sort is doing something weird here ... it's not stable when it sees aarch64. $ printf '%s\n' aarch64 abc zed | LC_ALL=nb_NO.UTF-8 sort -u aarch64 abc zed $ printf '%s\n' abc aarch64 zed | LC_ALL=nb_NO.UTF-8 sort -u abc zed aarch64 i'll have to check with upstream to see if this behavior is correct.
Why should it be stable? I mean, in nordic locales it is correct that aa comes after z when sorting alphabetically (it's even like this in Windows). I couldn't find anything in the documentation to sort that tells that sorting alphabetically should be stable across locales...
man sort states: *** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
Sorry for spamming the bug report, I didn't catch what you were complaining about after reading it over again several times. Yes, I see what you mean now, it's kind of buggy that one list triggers aarch first and the another list triggers aarch last. That looks like a legitimate bug. Should have read better, sorry.
looks like we're hitting a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18589 which should be fixed in glibc-2.23. i'll force LC_COLLATE=C in the mean time.
workaround here: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b9f374926a1889542d89cbff46e2b83d5afc99dd
