java-pkg_setup-vm() (called indirectly by e.g. java-pkg-opt-2_pkg_setup()) exports C locale. Some packages optionally build Java bindings and in such cases C locale shouldn't be enforced during building of non-Java parts. Please use 'LC_ALL="C" ${some_command_or_function}' in places when C locale is needed.
Not all usage goes through our eclasses so to remove it from there requires a run through all stable Java packages with ibm-jdk-bin and ecj at least. For the background see bug 170367. I do agree that we should rather fix the broken packages than have a work around like this.
Created attachment 240933 [details] x86 Ok so here's the plan for arch teams: 1. remove the export from line 2463 2. set build vm to ibm-jdk-bin-1.5 and compiler to javac * /etc/java-config-2/build/jdk.conf *=ibm-jdk-bin-1.5 * /etc/java-config-2/build/compilers.conf no COMPILERS declared 3. test the attached list with the et_EE.UTF8 locale * see /etc/locale.gen if you need to generate it * LC_ALL="et_ET.UTF8" emerge 4. Switch the JDK to icedtea6-bin (1.8.0) and compiler to ecj:3.5 5. Repeat compiling everything with et_ET.UTF8 or a uncommon locale of your choosing (!= C)
Created attachment 240935 [details] amd64
Created attachment 240937 [details] ppc
Created attachment 240939 [details] ppc64
Arches see comment #2 for instructions. ppc/ppc64: besides two slots of jdom-jaxen x86 covers all your stuff so your testing can be considered optional. amd64 has a couple packages that x86 doesn't (but I did file stable requests for those so eventually x86 has a superset).
(In reply to comment #2) > > 1. remove the export from line 2463 This is java-utils-2.eclass. Please file individual bugs about failures if you find them and make them block this one. Before filing test with LC_ALL=C to make sure the breakage is truly related to the removal of the export (but do still file it even if it's not).
There are more failures on x86, but I had no time to report them yet.
(In reply to comment #8) > There are more failures on x86, but I had no time to report them yet. I did the x86 list with icedtea6-bin-1.9.6 and ecj:3.5, and bug 354751 is the only failure that is reproducibly hidden by the locale hack. All other failures are unrelated and (by now) archived in bugzilla. What is the next step here?
The locale was an exercise, appears entry to acquire the intended locale is (now) et_EE.UTF-8 UTF-8 also used ja_JP.UTF-8 UTF-8 for the first round. I cannot fathom why this appears to have gone unattended for months. Anyway Here is a test run. First round, since it has been so long, package =kde-base/krossjava-4.6.2 ~amd64 need be added to the list since it wasn't around when this was posted. Also a new version of rhino created a slot conflict with another package. A couple of packages failed with causes unrelated to locale and can be found in java@gentoo. 600 + packages takes a while. Round 2 underway. The absence of the supposed locale invoked failures gives the impression it is either resolved by inhouse development was never prolific.
Created attachment 273037 [details] my emerge --info
After several attempts and getting the settings wrong, it appears I finally have them right & am repeating round 1. The package that really tripped up was ant-nodeps depending on ant-core. Can never be sure of what I had wrong in setup, but chances are it may have been related to relying upon suggested settings from comments 2; et_EE.UTF8 && et_ET.UTF8, which contradict one another && both of which are wrong. The correct is et_EE.UTF-8. To get it right and get no menacing messages of the type sh: warning: setlocale: LC_ALL: cannot change locale (et_ET.UTF-8) correct for /etc/locale.gen is et_ET.UTF-8 UTF-8 and for /etc/env.d/02ocale is LANG="et_EE.UTF-8" LC_ALL="et_EE.UTF-8" gentoo64 ~ # locale yielding LANG=et_EE.UTF-8 LC_CTYPE="et_EE.UTF-8" LC_NUMERIC="et_EE.UTF-8" LC_TIME="et_EE.UTF-8" LC_COLLATE="et_EE.UTF-8" LC_MONETARY="et_EE.UTF-8" LC_MESSAGES="et_EE.UTF-8" LC_PAPER="et_EE.UTF-8" LC_NAME="et_EE.UTF-8" LC_ADDRESS="et_EE.UTF-8" LC_TELEPHONE="et_EE.UTF-8" LC_MEASUREMENT="et_EE.UTF-8" LC_IDENTIFICATION="et_EE.UTF-8" LC_ALL=et_EE.UTF-8 with no menacing warnings or error messages. For now, >>> Emerging (1 of 639) app-editors/gentoo-editor-2 Given ant-core & ant-nodeps are a litmus test, I have already emerged these without issue. So sadly this confirms the other bugs filed are destined for invalid and or worksforme. In fact, ant-nodeps does truly WORKFORME. I can only say, you said to file them with "(but do still file it even if it's not)" so stand by for next
So this run yielded quite different results. Fetch failures excluded, the missed list yielded commons-transaction-build.log, gnu-classpath-0.98-r3-build.log, icu4j-4.4.2-build.log, jdbc-jaybird-build.log, jgoodies-looks-2.3.1-build.log, jjtraveler-0.4.3-r2-build.log, jnlp-bin-build.log, jupidator-0.6.0-build.log, krossjava-4.6.2-build.log, metadata-extractor-build.log, openfire-3.7.0-build.log, piccolo2d-1.2.1-r2-build.log, statsvn-0.5.0-build.log, texlive-basic-2008-r1-build.log, xmlc-2.3.1-build.log, yap-6.2.0-r1-build.log These are the build logs saved under these names. The build errors were unlike those in the first attempt. Those proved to be erroneous, based on that I refrain from filing these 16 package build failures given so many. I shall just settle for, if you would like to acquire them I shall post them in a fashion of your pleasure. "test with LC_ALL=C to make sure the breakage is truly related to the removal of the export" gentoo64 ~ # LC_ALL=C emerge commons-transaction gnu-classpath icu4j jdbc-jaybird jgoodies-looks jjtraveler jnlp-bin jupidator krossjava metadata-extractor openfire piccolo2d statsvn texlive-basic xmlc yap yielded * The following 15 packages have failed to build or install: the exception being dev-java/icu4j-4.4.2. Reverting the line 2463 back in the java eclass and re-emerging, icu4j once again emerged, the others again missed. For the second time, run 2 under way.
finally, run 2 done and a sl better result. gentoo64 ~ # ls run2/*2 run2/freecol-0.8.4-build.log2 run2/metadata-extractor-2.2.2-r2-build.log2 run2/jjtraveler-0.4.3-r2-build.log2 run2/piccolo2d-1.2.1-r2-build.log2 run2/jrdesktop-0.2.0030-build.log2 run2/resin-4.0.13-r1-build.log2 run2/jupidator-0.6.0-build.log2 run2/texlive-basic-2008-r1-build.log2 are the packages that missed, far less.resin is a new one, some others emerged that did not previously. from LC_ALL=C emerge freecol jjtraveler jrdesktop jupidator metadata-extractor piccolo2d resin texlive-basic only freecol emerged. Re-setting line 2463 with the export in the eclass, yielded the same; freecol emerged again, remaining 7 not. As for the last, I shall keep these build logs in case you would like to review them.
IAN DELANEY: Please avoid writing useless comments. If you find a package, which succeeds to build with C locale and fails to build with et_ET.UTF8 locale, then file a new bug and make it block bug #330433.
(In reply to comment #15) > IAN DELANEY: Please avoid writing useless comments. If you find a package, > which succeeds to build with C locale and fails to build with et_ET.UTF8 > locale, then file a new bug and make it block bug #330433. I think the text here sounds unnecessarily harsh. It's not trivial to know what is relevant. Too much is better than nothing so we should not discourage people from submitting info. Ian: if in doubt you can ask on IRC for help on what info to include in the future. 15:13 < idella4> To finalise, amd64 comes up clean of any sign of interference by locale. The package failures resulting either emerged in other configs or are it seems already recorded. I don't wish to answer in the bug in the light of the last reply. I think we are ready to proceed here as soon as bug 368071 is taken care of then.
betelgeuse; sincere thank you for that. That you copied & pasted my text from irc does help make me feel vindicated for my (perhaps) verbose entries. I shall indeed heed you good advice.
@java, are you committing the change? I'm removing x86 from cc, I think our job is done. Please readd if this is not the case.
Export removed. If anything breaks now, it will have to be fixed. Thanks everyone.
