Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
Ken Moffat wrote: > On Sun, Mar 02, 2014 at 12:49:12AM +, Ken Moffat wrote: >> On Sat, Mar 01, 2014 at 04:05:15PM -0600, Bruce Dubbs wrote: Do you perhaps have any LESSCHARSET or similar variables set ? >>> >>> Yes. >>> >>> LESS=-MX >>> LESSCHARSET=latin1 >>> >> I would try without LESSCHARSET. It ought to be able to determine >> it from the LANG/LC_CTYPE environment variables, or else from >> calling setlocale. >> >>> What about just adding the LC_ALL variable unconditionally? It >>> shouldn't hurt anything. >>> >>> -- Bruce >>> >> Umm, errm. . I'm having issues using a dirty build >> tree after I exported LC_ALL=C to force the breakage. At the >> moment, everything I try breaks, even after 'make clean'. In theory, >> exporting LANG ought to do it, with minimal side-effects. Will play >> around with it some more. >> >> ĸen > On this machine, I need to unset LC_ALL after exporting > LANG=en_US.UTF-8, otherwise it still breaks with LC_ALL=C. > > This is getting messy - the build will be fine (people who use BLFS > can probably cope with any error messages in English), but it risks > leaving their environment in an unexpected state. I guess export > MYLC=$LC_ALL ; export LC_ALL=en_US.UTF-8 ; ./configure ... ; make ; > export LC_ALL=$MYLC ; make install. i.e. just force LC_ALL since it > would otherwise need to be unset. > > If nobody has any cleaner suggestions, I'll give that a whirl > sometime tomorrow (technically, today). Tested. I got it to fail, then: $ which ruby /usr/bin/ruby $ tar -xf gegl-0.2.0.tar.bz2 $ cd gegl-0.2.0 $ patch -Np1 -i ../gegl-0.2.0-ffmpeg2-1.patch $ ./configure --prefix=/usr $ LC_ALL=C make Failure $ LC_ALL=en_US make Worked. I would not hurt to just add LC_ALL=en_US to the instructions. -- Bruce LC_ALL=en_US make -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sun, Mar 02, 2014 at 12:49:12AM +, Ken Moffat wrote: > On Sat, Mar 01, 2014 at 04:05:15PM -0600, Bruce Dubbs wrote: > > > > > > Do you perhaps have any LESSCHARSET or similar variables set ? > > > > Yes. > > > > LESS=-MX > > LESSCHARSET=latin1 > > > I would try without LESSCHARSET. It ought to be able to determine > it from the LANG/LC_CTYPE environment variables, or else from > calling setlocale. > > > What about just adding the LC_ALL variable unconditionally? It > > shouldn't hurt anything. > > > >-- Bruce > > > Umm, errm. . I'm having issues using a dirty build > tree after I exported LC_ALL=C to force the breakage. At the > moment, everything I try breaks, even after 'make clean'. In theory, > exporting LANG ought to do it, with minimal side-effects. Will play > around with it some more. > > ĸen On this machine, I need to unset LC_ALL after exporting LANG=en_US.UTF-8, otherwise it still breaks with LC_ALL=C. This is getting messy - the build will be fine (people who use BLFS can probably cope with any error messages in English), but it risks leaving their environment in an unexpected state. I guess export MYLC=$LC_ALL ; export LC_ALL=en_US.UTF-8 ; ./configure ... ; make ; export LC_ALL=$MYLC ; make install. i.e. just force LC_ALL since it would otherwise need to be unset. If nobody has any cleaner suggestions, I'll give that a whirl sometime tomorrow (technically, today). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 04:05:15PM -0600, Bruce Dubbs wrote: > > > > Do you perhaps have any LESSCHARSET or similar variables set ? > > Yes. > > LESS=-MX > LESSCHARSET=latin1 > I would try without LESSCHARSET. It ought to be able to determine it from the LANG/LC_CTYPE environment variables, or else from calling setlocale. > What about just adding the LC_ALL variable unconditionally? It > shouldn't hurt anything. > >-- Bruce > Umm, errm. . I'm having issues using a dirty build tree after I exported LC_ALL=C to force the breakage. At the moment, everything I try breaks, even after 'make clean'. In theory, exporting LANG ought to do it, with minimal side-effects. Will play around with it some more. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 11:54:17PM +, akhiezer wrote: > > Date: Sat, 1 Mar 2014 21:56:30 + > > From: Ken Moffat > > To: BLFS Development List > > Subject: Re: [blfs-dev] Policy on locale for building ? (ticket #4745) > > > . > . > > > > > > > > Root (at least) here is always still non-utf8 . > > > > > > > The book (at least in most cases) builds as a normal user. You and > > I can choose to build as root if we wish, but we get to keep both > > pieces if it breaks. ;-) > > > > > - sorry, I thought from yr orig remark (not quot above) that you meant, > that everyone should by now have/use utf8 in everyday use (& not just for > b/lfs builds): hence my remark (intending to say) that we avoid utf8 &c > for root/priv in everyday use. > > (And normally only use root in software builds at the required steps). > I did mean that :) Unfortunately, not everyone seems to want to be able to render every language [ and, in a tty, you are limited to at most 512 glyphs so in practice you can only hope to render all languages in a graphical term ]. My apologies. I still have the fanaticism of the convert. Goes back to when I wanted to put correct placenames on my holiday photos. I guess the ruby devs now assume that everyone using a current version of ruby is using unicode, and on linux the only common Unicode Translation Format is UTF-8. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
> Date: Sat, 1 Mar 2014 21:56:30 + > From: Ken Moffat > To: BLFS Development List > Subject: Re: [blfs-dev] Policy on locale for building ? (ticket #4745) > . . > > > > > Root (at least) here is always still non-utf8 . > > > > The book (at least in most cases) builds as a normal user. You and > I can choose to build as root if we wish, but we get to keep both > pieces if it breaks. ;-) > - sorry, I thought from yr orig remark (not quot above) that you meant, that everyone should by now have/use utf8 in everyday use (& not just for b/lfs builds): hence my remark (intending to say) that we avoid utf8 &c for root/priv in everyday use. (And normally only use root in software builds at the required steps). rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
Ken Moffat wrote: > On Sat, Mar 01, 2014 at 03:29:08PM -0600, Bruce Dubbs wrote: >> Ken Moffat wrote: > [ snipped ] >> >> I have a problem with en_US.UTF-8. I generally do not have any LC_ >> variable set and even have >> >> alias ls='LC_ALL=C ls --color=auto' >> >> because I once was running into a problem with ls ignoring case when >> sorting. >> >> If I do 'LC_ALL=en_US.UTF-8 man man', I get things like below. >> >> ... [--no-justifiâ >> <80><90> >> >> without, it gives the expected >> >> ... [--no-justifi- >> >> -- Bruce > Odd. I prefer to see case-insensitive sorting, but I haven't > noticed that sort of problem recently in 'man'. At the moment, both > of the --no-justification matches in that manpage look fine with > LC_ALL and LANG both set to en_GB.UTF-8. I have seen that sort of > problem occasionally in the past, I think it was on some av > package(s) - I don't think I've looked at 'man man' in years. > > Do you perhaps have any LESSCHARSET or similar variables set ? Yes. LESS=-MX LESSCHARSET=latin1 With LC_ALL=en_US.UTF-8 LESSCHARSET= man man, I still get ... [--no-justifiâ but without the <80><90>. With LC_ALL=en_GB.UTF-8, all is as it should be. > Going back to gegl, do you think a note along the lines of "If you > have installed ruby, and are building in a non-UTF-8 locale such as > 'C', you will need to use a UTF-8 environment for compiling this > package, for example by passing LC_ALL=en_US.UTF-8 to configure." > would hurt ? What about just adding the LC_ALL variable unconditionally? It shouldn't hurt anything. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 09:49:33PM +, akhiezer wrote: > > Date: Sat, 1 Mar 2014 20:18:34 + > > From: Ken Moffat > > To: blfs-dev@linuxfromscratch.org > > Subject: [blfs-dev] Policy on locale for building ? (ticket #4745) > > > . > . > > > > If I configure gegl in my normal UTF-8 locale, there is no problem > > even with ruby already installed. But if I pass LC_ALL=C to > > configure, I get the reported problem during 'make' : > > > > ../tools/create-reference.rb:331:in `block (2 levels) in ': > > invalid byte sequence in US-ASCII (ArgumentError) > . > . > > > > > Hmmm. Does it _really_ require utf8 or similar to build? Seems like a poor > idea to _require_ it. > Seems to - the workaround in the ticket is to add Encoding.default_external = Encoding::UTF_8 Encoding.default_internal = Encoding::UTF_8 to one of the .rb files. Of course, if you don't install ruby before gegl, the problem doesn't arise. Taking a quick look at fedora, http://pkgs.fedoraproject.org/cgit/gegl.git/plain/gegl.spec they have: # Needed by Ruby 1.9.3. export LANG=en_US.utf8 note the lowercase, presumably both .utf8 and .UTF-8 will work in this case. > > Root (at least) here is always still non-utf8 . > The book (at least in most cases) builds as a normal user. You and I can choose to build as root if we wish, but we get to keep both pieces if it breaks. ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
On Sat, Mar 01, 2014 at 03:29:08PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: [ snipped ] > > I have a problem with en_US.UTF-8. I generally do not have any LC_ > variable set and even have > > alias ls='LC_ALL=C ls --color=auto' > > because I once was running into a problem with ls ignoring case when > sorting. > > If I do 'LC_ALL=en_US.UTF-8 man man', I get things like below. > > ... [--no-justifiâ > <80><90> > > without, it gives the expected > > ... [--no-justifi- > >-- Bruce Odd. I prefer to see case-insensitive sorting, but I haven't noticed that sort of problem recently in 'man'. At the moment, both of the --no-justification matches in that manpage look fine with LC_ALL and LANG both set to en_GB.UTF-8. I have seen that sort of problem occasionally in the past, I think it was on some av package(s) - I don't think I've looked at 'man man' in years. Do you perhaps have any LESSCHARSET or similar variables set ? Going back to gegl, do you think a note along the lines of "If you have installed ruby, and are building in a non-UTF-8 locale such as 'C', you will need to use a UTF-8 environment for compiling this package, for example by passing LC_ALL=en_US.UTF-8 to configure." would hurt ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
> Date: Sat, 1 Mar 2014 20:18:34 + > From: Ken Moffat > To: blfs-dev@linuxfromscratch.org > Subject: [blfs-dev] Policy on locale for building ? (ticket #4745) > . . > > If I configure gegl in my normal UTF-8 locale, there is no problem > even with ruby already installed. But if I pass LC_ALL=C to > configure, I get the reported problem during 'make' : > > ../tools/create-reference.rb:331:in `block (2 levels) in ': > invalid byte sequence in US-ASCII (ArgumentError) . . > Hmmm. Does it _really_ require utf8 or similar to build? Seems like a poor idea to _require_ it. > What I don't recall is whether we ever recommend building packages > in BLFS using the C or POSIX locales ? My belief is that everyone > ought to be using UTF-8 locales by now, but from support posts over > the years I guess that some of our users are behind the curve in > this, and see no reason to change from legacy encodings (or perhaps > they have too much data to make that feasible). > Root (at least) here is always still non-utf8 . > . . > rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Policy on locale for building ? (ticket #4745)
Ken Moffat wrote: > Looking at #4745, there is a workaround for a problem building gegl > when ruby has already been installed. Dunno why the originator > hasn't actually put this in the wiki (I assume an ID for creating a > ticket provides those privilege?), but there is an easier solution: > > If I configure gegl in my normal UTF-8 locale, there is no problem > even with ruby already installed. But if I pass LC_ALL=C to > configure, I get the reported problem during 'make' : > > ../tools/create-reference.rb:331:in `block (2 levels) in ': > invalid byte sequence in US-ASCII (ArgumentError) > from ../tools/create-reference.rb:325:in `foreach' > from ../tools/create-reference.rb:325:in `block in ' > from ../tools/create-reference.rb:318:in `times' > from ../tools/create-reference.rb:318:in `' > Makefile:881: recipe for target 'api.html' failed > make[3]: *** [api.html] Error 1 > > What I don't recall is whether we ever recommend building packages > in BLFS using the C or POSIX locales ? My belief is that everyone > ought to be using UTF-8 locales by now, but from support posts over > the years I guess that some of our users are behind the curve in > this, and see no reason to change from legacy encodings (or perhaps > they have too much data to make that feasible). > > For this package, is it worth adding a note that it should be built > from a UTF-8 environment, e.g. by passing LC_ALL=en_US.UTF-8 ? > > I note that in LFS we recommend a number of locales, not all UTF-8, > for optimum test coverage (en_US.UTF-8 is one of these), followed by > "In addition, install the locale for your own country, language and > character set." so that if people decide to omit tests there is no > guarantee about which locales will exist. I have a problem with en_US.UTF-8. I generally do not have any LC_ variable set and even have alias ls='LC_ALL=C ls --color=auto' because I once was running into a problem with ls ignoring case when sorting. If I do 'LC_ALL=en_US.UTF-8 man man', I get things like below. ... [--no-justifiâ <80><90> without, it gives the expected ... [--no-justifi- -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Policy on locale for building ? (ticket #4745)
Looking at #4745, there is a workaround for a problem building gegl when ruby has already been installed. Dunno why the originator hasn't actually put this in the wiki (I assume an ID for creating a ticket provides those privilege?), but there is an easier solution: If I configure gegl in my normal UTF-8 locale, there is no problem even with ruby already installed. But if I pass LC_ALL=C to configure, I get the reported problem during 'make' : ../tools/create-reference.rb:331:in `block (2 levels) in ': invalid byte sequence in US-ASCII (ArgumentError) from ../tools/create-reference.rb:325:in `foreach' from ../tools/create-reference.rb:325:in `block in ' from ../tools/create-reference.rb:318:in `times' from ../tools/create-reference.rb:318:in `' Makefile:881: recipe for target 'api.html' failed make[3]: *** [api.html] Error 1 What I don't recall is whether we ever recommend building packages in BLFS using the C or POSIX locales ? My belief is that everyone ought to be using UTF-8 locales by now, but from support posts over the years I guess that some of our users are behind the curve in this, and see no reason to change from legacy encodings (or perhaps they have too much data to make that feasible). For this package, is it worth adding a note that it should be built from a UTF-8 environment, e.g. by passing LC_ALL=en_US.UTF-8 ? I note that in LFS we recommend a number of locales, not all UTF-8, for optimum test coverage (en_US.UTF-8 is one of these), followed by "In addition, install the locale for your own country, language and character set." so that if people decide to omit tests there is no guarantee about which locales will exist. Dunno what would be best here. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
