Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-15 Thread Dr Rainer Woitok
Peter,

On Tuesday, 2021-06-15 08:41:40 +0100, you wrote:

> ...
> ># eselect locale set 4
> ># env-update
> > 
> >>>> Regenerating /etc/ld.so.cache...
> 
> After that you need to source /etc/profile, no?

Yes,  if you want to continue working in this shell.   But if I start my
Gentoo update script from my unprivileged userid,  it only depends on my
own environment and on what "/etc/sudoers" allows through.

But your remark  made me curious  about what  was really changed  in the
environment.   So I started a privileged shell  using my own environment
and then executed

   # env | sort > /tmp/env1
   # . /etc/profile
   # env | sort > /tmp/env2
   # diff -du /tmp/env*

The trivial  environment variable changes  were for "LESS",  "LS_COLORS"
(which was added), "MANPATH", "PATH", and "PS1".  However, the non-triv-
ial environment variable change was:

   -LANG=en_GB.UTF-8
   +LANG=en_GB.utf8

which sort of shocked me,  because that effectively again unset the only
variable setting that allowed building of package "/texlive-basic-2021":

> ...
> > So "en_GB.utf8" in "02locale"  but "export LANG=en_GB.UTF-8" in my Shell
> > script doing the Gentoo updates is the only working combination I've yet
> > found.

May this be some sort of bug in "glibc"?

Utterly puzzled ...
  Rainer



Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-15 Thread Peter Humphrey
On Monday, 14 June 2021 17:36:11 BST Dr Rainer Woitok wrote:
> Michael,
> 
> On Sunday, 2021-06-13 18:23:54 +0100, you wrote:
> > ...
> > Yes, this looks odd, but I have not worked out how locale is sourced in
> > 
> > detail.  Have you added:
> >  LANG="en_GB.UTF-8"
> > 
> > in your /etc/env.d/02locale for a system wide setting?
> 
> No, this file still contains
> 
>LANG="en_GB.utf8"
> 
> However, if I change that line to
> 
>LANG="en_GB.UTF-8"
> 
> then I do get a new locale when running
> 
># env-update
> 
>>>> Regenerating /etc/ld.so.cache...
> 
># eselect locale list
>Available targets for the LANG variable:
>  [1]   C
>  [2]   C.utf8
>  [3]   POSIX
>  [4]   en_GB.utf8
>  [5]   en_GB.UTF-8 *
>  [ ]   (free form)
>#
> 
> but afterwards  re-building package "texlive-basic" again fails  until I
> undo this change by executing
> 
># eselect locale set 4
># env-update
> 
>>>> Regenerating /etc/ld.so.cache...

After that you need to source /etc/profile, no?

># eselect locale list
>Available targets for the LANG variable:
>  [1]   C
>  [2]   C.utf8
>  [3]   POSIX
>  [4]   en_GB.utf8 *
>  [ ]   (free form)
># grep -v '^#' /etc/env.d/02locale
>LANG="en_GB.utf8"
>#
> 
> So "en_GB.utf8" in "02locale"  but "export LANG=en_GB.UTF-8" in my Shell
> script doing the Gentoo updates is the only working combination I've yet
> found.  Explanations heartily welcome :-/
> 
> Sincerely,
>   Rainer


-- 
Regards,
Peter.






Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-14 Thread Dr Rainer Woitok
Michael,

On Sunday, 2021-06-13 18:23:54 +0100, you wrote:

> ...
> Yes, this looks odd, but I have not worked out how locale is sourced in 
> detail.  Have you added:
> 
>  LANG="en_GB.UTF-8"
> 
> in your /etc/env.d/02locale for a system wide setting?

No, this file still contains

   LANG="en_GB.utf8"

However, if I change that line to

   LANG="en_GB.UTF-8"

then I do get a new locale when running

   # env-update
   >>> Regenerating /etc/ld.so.cache...
   # eselect locale list
   Available targets for the LANG variable:
 [1]   C
 [2]   C.utf8
 [3]   POSIX
 [4]   en_GB.utf8
 [5]   en_GB.UTF-8 *
 [ ]   (free form)
   #

but afterwards  re-building package "texlive-basic" again fails  until I
undo this change by executing

   # eselect locale set 4
   # env-update
   >>> Regenerating /etc/ld.so.cache...
   # eselect locale list
   Available targets for the LANG variable:
 [1]   C
 [2]   C.utf8
 [3]   POSIX
 [4]   en_GB.utf8 *
 [ ]   (free form)
   # grep -v '^#' /etc/env.d/02locale
   LANG="en_GB.utf8"
   #

So "en_GB.utf8" in "02locale"  but "export LANG=en_GB.UTF-8" in my Shell
script doing the Gentoo updates is the only working combination I've yet
found.  Explanations heartily welcome :-/

Sincerely,
  Rainer



Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-13 Thread Michael
On Sunday, 13 June 2021 18:10:46 BST Dr Rainer Woitok wrote:
> Michael,
> 
> On Sunday, 2021-06-13 16:16:37 +0100, you wrote:
> > ...
> > $ grep -i en_gb /usr/share/i18n/SUPPORTED
> > en_GB.UTF-8 UTF-8
> > en_GB ISO-8859-1
> 
> Same here.

It would/should be the same with mine.  Have you made sure:

en_GB.UTF-8 UTF-8

is in your /etc/locale.gen and have you run locale-gen thereafter?

> > ...
> > $ eselect locale list
> > 
> > Available targets for the LANG variable:
> >   [1]   C
> >   [2]   C.utf8
> >   [3]   POSIX
> > 
> > [snip ... ]
> > 
> >   [7]   en_GB
> >   [8]   en_GB.iso88591
> >   [9]   en_GB.utf8
> >   [10]  en_US
> >   [11]  en_US.iso88591
> >   [12]  en_US.utf8
> >   [13]  en_GB.UTF-8 *
> >   [ ]   (free form)
> 
> Now it's becoming really mysterious, right from the local horse's mouth:
> 
>$ eselect locale list
>Available targets for the LANG variable:
>  [1]   C
>  [2]   C.utf8
>  [3]   POSIX
>  [4]   en_GB.utf8 *
>  [ ]   (free form)
> 
> So allegedly my only  "available target"  for English  is the not (or no
> longer) working "en_GB.utf8".   Being slightly flabbergasted  would be a
> huge understatement ... :-/
> 
> Sincerely,
>   Rainer

Yes, this looks odd, but I have not worked out how locale is sourced in 
detail.  Have you added:

 LANG="en_GB.UTF-8"

in your /etc/env.d/02locale for a system wide setting?

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-13 Thread Dr Rainer Woitok
Michael,

On Sunday, 2021-06-13 16:16:37 +0100, you wrote:

> ...
> $ grep -i en_gb /usr/share/i18n/SUPPORTED
> en_GB.UTF-8 UTF-8
> en_GB ISO-8859-1

Same here.

> ...
> $ eselect locale list
> Available targets for the LANG variable:
>   [1]   C
>   [2]   C.utf8
>   [3]   POSIX
> [snip ... ]
>   [7]   en_GB
>   [8]   en_GB.iso88591
>   [9]   en_GB.utf8
>   [10]  en_US
>   [11]  en_US.iso88591
>   [12]  en_US.utf8
>   [13]  en_GB.UTF-8 *
>   [ ]   (free form)

Now it's becoming really mysterious, right from the local horse's mouth:

   $ eselect locale list
   Available targets for the LANG variable:
 [1]   C
 [2]   C.utf8
 [3]   POSIX
 [4]   en_GB.utf8 *
 [ ]   (free form)

So allegedly my only  "available target"  for English  is the not (or no
longer) working "en_GB.utf8".   Being slightly flabbergasted  would be a
huge understatement ... :-/

Sincerely,
  Rainer



Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-13 Thread Michael
On Sunday, 13 June 2021 15:11:18 BST Dr Rainer Woitok wrote:
> All,
> 
> On Sunday, 2021-06-13 15:39:46 +0200, I myself wrote:
> > ...
> > 
> > > > $ sudo locale
> > > > LANG=en_GB.utf8
> > > > ...
> > 
> > Erm,  is there a difference between  "*.utf8" and "*.UTF-8"?   Does case
> > matter?
> 
> Apparently yes.   At least  for Perl  or anything else  used by Portage.
> Running my package upgrade script again after setting
> 
>$ export LANG=en_GB.UTF-8
> 
> just succeeded.  "As soon as you're doing it right,  it just works". :-)
> But what exactly is the difference?
> 
> Sincerely,
>   Rainer

If you have a look at the comments in /etc/locale.gen it explains where to 
find suitable notation for locale name, charset, and it also provides a 
default list of supported combinations:

/usr/share/i18n/SUPPORTED

In there we find:

$ grep -i en_gb /usr/share/i18n/SUPPORTED
en_GB.UTF-8 UTF-8
en_GB ISO-8859-1

I recall in the past having had a similar problem and as you say, once you set 
it up correctly it just works.  :-)  I don't know what the difference is 
between lower/upper case notation for the charset, but having set it up in 
capitals seems to work here.  Note, I don't have any lower case charset in /
etc/locale.gen.

$ eselect locale list
Available targets for the LANG variable:
  [1]   C
  [2]   C.utf8
  [3]   POSIX
[snip ... ]
  [7]   en_GB
  [8]   en_GB.iso88591
  [9]   en_GB.utf8
  [10]  en_US
  [11]  en_US.iso88591
  [12]  en_US.utf8
  [13]  en_GB.UTF-8 *
  [ ]   (free form)



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-13 Thread Dr Rainer Woitok
All,

On Sunday, 2021-06-13 15:39:46 +0200, I myself wrote:

> ...
> > > $ sudo locale
> > > LANG=en_GB.utf8
> > > ...
> Erm,  is there a difference between  "*.utf8" and "*.UTF-8"?   Does case
> matter?

Apparently yes.   At least  for Perl  or anything else  used by Portage.
Running my package upgrade script again after setting

   $ export LANG=en_GB.UTF-8

just succeeded.  "As soon as you're doing it right,  it just works". :-)
But what exactly is the difference?

Sincerely,
  Rainer



Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-13 Thread Dr Rainer Woitok
Michael,

On Saturday, 2021-06-12 16:29:12 +0100, you wrote:

> ...
> > $ sudo locale
> > LANG=en_GB.utf8
> > ...
> I can't speak for your lua* packages, but as long as you have defined your 
> locale correctly in /etc/locale.gen your system should source what it needs 
> from there.

Erm,  is there a difference between  "*.utf8" and "*.UTF-8"?   Does case
matter?  The web page

   https://wiki.gentoo.org/wiki/UTF-8

provides a mix of both notations, but I get

   $ grep -v '^#' /etc/locale.gen

   en_GB.UTF-8 UTF-8
   $

So do I have to adapt my definition of "LANG"?

> Regarding perl complaining, there was a perl update recently (stable) so 
> running perl-cleaner is recommended and may fix at least your texlive-basic 
> issue.

I installed Perl version 5.32.1 two weeks ago during my last routine up-
grade,  so this might be  a reason as well.   And running "perl-cleaner"
returned this:

   $ perl-cleaner --all --pretend
* Would try to remove the following perl-core packages from world file
*emerge --deselect  perl-core/File-Temp 
* Would try to update installed Perl virtuals
*emerge -u1  virtual/perl-Carp virtual/perl-Compress-Raw-Zlib 
virtual/perl-CPAN-Meta virtual/perl-CPAN-Meta-YAML virtual/perl-Data-Dumper 
virtual/perl-Digest virtual/perl-Digest-MD5 virtual/perl-Digest-SHA 
virtual/perl-Encode virtual/perl-Exporter virtual/perl-ExtUtils-CBuilder 
virtual/perl-ExtUtils-Install virtual/perl-ExtUtils-MakeMaker 
virtual/perl-ExtUtils-Manifest virtual/perl-ExtUtils-ParseXS 
virtual/perl-File-Path virtual/perl-File-Spec virtual/perl-File-Temp 
virtual/perl-Getopt-Long virtual/perl-IO virtual/perl-JSON-PP 
virtual/perl-libnet virtual/perl-MIME-Base64 virtual/perl-Module-Metadata 
virtual/perl-parent virtual/perl-Parse-CPAN-Meta virtual/perl-Perl-OSType 
virtual/perl-Pod-Parser virtual/perl-podlators virtual/perl-Scalar-List-Utils 
virtual/perl-Storable virtual/perl-Sys-Syslog virtual/perl-Test-Harness 
virtual/perl-Test-Simple virtual/perl-Text-ParseWords virtual/perl-Time-Local 
virtual/perl-version virtual/perl-XSLoader 

* Locating packages for an update
* Locating ebuilds linked against libperl
 * No package needs to be reinstalled.
   $

As far as I can see all these virtual packages are installed and updated
to the most recent  stable version.   But nevertheless  I will try that,
too.

By the way, "man perl-cleaner" starts with

   DESCRIPTION
  perl-cleaner -- Find & rebuild packages and Perl header files broken
  due to a perl upgrade

Is this what they call "inspiring confidence"? :-)

Is there a reason why "perl-cleaner"  should be run manually rather than
automatically after emerging  any Perl component?   Should I put it into
my "edepclean" script which I normally run after a successful upgrade?

Sincerely,
  Rainer



Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed

2021-06-12 Thread Michael
On Saturday, 12 June 2021 15:43:18 BST Dr Rainer Woitok wrote:
> Greetings,
> 
> it's been quite a while that I had problems  doing my routine Gentoo up-
> grade.   This time package  "dev-texlive/texlive-basic-2021" balked, and
> in the build log I found this:
> 
>  * Package:dev-texlive/texlive-basic-2021
>  * Repository: gentoo
>  * Maintainer: aball...@gentoo.org t...@gentoo.org
>  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux luajittex
> userland_GNU * FEATURES:   network-sandbox preserve-libs sandbox userpriv
> usersandbox ---8><---
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = "en_GB:en",
>   LC_ALL = (unset),
>   LC_MESSAGES = "C",
>   LC_CTYPE = "C.UTF-8",
>   LC_COLLATE = "C",
>   LANG = "en_GB"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> 
> While the value of environment variable "LANGUAGE"  is clearly mine, the
> other values except  "LC_COLLATE" and "LC_ALL"  are obviously _not mine_
> (in particular "LANG" is missing the ".utf8" part):
> 
> $ sudo env | grep LANGU
> Password:
> LANGUAGE=en_GB:en
> $ sudo locale
> LANG=en_GB.utf8
> LC_CTYPE="en_GB.utf8"
> LC_NUMERIC="en_GB.utf8"
> LC_TIME="en_GB.utf8"
> LC_COLLATE=C
> LC_MONETARY="en_GB.utf8"
> LC_MESSAGES="en_GB.utf8"
> LC_PAPER="en_GB.utf8"
> LC_NAME="en_GB.utf8"
> LC_ADDRESS="en_GB.utf8"
> LC_TELEPHONE="en_GB.utf8"
> LC_MEASUREMENT="en_GB.utf8"
> LC_IDENTIFICATION="en_GB.utf8"
> LC_ALL=
> $
> 
> Using "grep"  to sift through  my build logs  the first occurance of the
> line "perl: warning: Setting locale failed." occured a year ago at 2020-
> 05-18 while upgrading package "media-libs/exiftool-11.93" and since then
> it is present  in quite a few  build logs  without apparently  doing any
> harm.  However, now making "luatex", "luahbtex", and "dviluatex" as part
> of package "dev-texlive/texlive-basic-2021"  all failed with "Unable  to
> read environment locale: exit now." and finally caused the build to die:
> 
>  ---8><---
> fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence
> order): fmtutil:   texmf-dist/fmtutil/format.texlive-basic.cnf
> fmtutil: fmtutil is using the following fmtutil.cnf file for writing
> changes: fmtutil:   texmf-dist/fmtutil/format.texlive-basic.cnf
> fmtutil [INFO]: writing formats under
> /var/tmp/portage/dev-texlive/texlive-basic-2021/work/texmf-var/web2c
> fmtutil [INFO]: --- remaking luatex with luatex
> fmtutil: running `luatex -ini   -jobname=luatex -progname=luatex luatex.ini'
> ... Unable to read environment locale: exit now.
>  ---8><---
> fmtutil [INFO]: --- remaking luahbtex with luahbtex
> fmtutil: running `luahbtex -ini   -jobname=luahbtex -progname=luahbtex
> luatex.ini' ... Unable to read environment locale: exit now.
>  ---8><---
> fmtutil [INFO]: --- remaking dviluatex with luatex
> fmtutil: running `luatex -ini   -jobname=dviluatex -progname=dviluatex
> dviluatex.ini' ... Unable to read environment locale: exit now.
>  ---8><---
> fmtutil [INFO]: failed to build: 3 (luatex/luatex luahbtex/luahbtex
> luatex/dviluatex) fmtutil [INFO]: total formats: 8
> fmtutil [INFO]: exiting with status 3
>  * ERROR: dev-texlive/texlive-basic-2021::gentoo failed (compile phase):
>  *   failed to build format texmf-dist/fmtutil/format.texlive-basic.cnf
>  *
>  * Call stack:
>  * ebuild.sh, line 125:  Called src_compile
>  *   environment, line 510:  Called texlive-module_src_compile
>  *   environment, line 721:  Called die
>  * The specific snippet of code:
>  *   VARTEXFONTS="${T}/fonts"
> TEXMFHOME="${S}/texmf:${S}/texmf-dist:${S}/texmf-var" env -u TEXINPUTS
> $fmt_call --cnffile "${i}" --fmtdir "${S}/texmf-var/web2c" --all || die
> "failed to build format ${i}";
> 
> Is the failure to make "luatex", "luahbtex",  and "dviluatex" due to not
> being able to "read environment locale" a consequence of "perl" claiming
> to have problems with _my_ locale?  If not, what else is going on here?
> 
> Sincerely,
>   Rainer

I can't speak for your lua* packages, but as long as you have defined your 
locale correctly in /etc/locale.gen your system should source what it needs 
from there.

Regarding perl complaining, there was a perl update recently (stable) so 
running perl-cleaner is recommended and may fix at least your texlive-basic 
issue.

signature.asc
Description: This is a digitally signed message part.