On Mon, Oct 19, 2020 at 07:43:27PM +0200, Miguel Ángel Arruga Vivas wrote:
> Hello,
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> > Thanks for taking a look.
> 
> No problem at all, I was thinking about something along these lines too,
> but then I saw your patch. :-)

Your patch was what got me to actually send mine to guix-patches :)

> > For the utf8 vs UTF-8 there are a couple of comments in the code:
> > The above phase does not install locales with names using
> > the "normalized codeset."  Thus, create symlinks like:
> > en_US.utf8 -> en_US.UTF-8
> >
> > and also:
> > For backward compatibility with Guix
> > <= 0.8.3, add "xx_YY.UTF-8".
> 
> Yes, what I mean is that the comments along the code may need to be
> clarified, but adding a "nobody knows" doesn't add much information.

That is a good point. I'll change it to something actually useful,
mentioning that there's a convention but that people often get it wrong.

> The actual source[1] says that the correct value is utf8, following
> the rules for the 'normalized codeset' naming, that I copy here:
> 
>   1. Remove all characters besides numbers and letters.
>   2. Fold letters to lowercase.
>   3. If the same only contains digits prepend the string ‘"iso"’.
> 
> We should stick to that naming regarding libc locales (note to self),
> even though we keep the links for compatibility.  That includes the
> other locale at en_us-glibc-locales.

I agree it should be renamed to en-us. I have some bikeshedding to think
about for en-us-glibc-locales vs glibc-locales-en-us. And I'll also test
out one for glibc-locales-guile-tests.

> >> What do you think about replacing make-glibc-utf8-locales with a call of
> >> the new function (using that code) ensuring that the generated
> >> derivation stays the same for that case (i.e. it's optimized for the
> >> UTF-8 case)?
> >
> > This is what I originally wanted to do, but there's a glibc-locales
> > buried in the bootstrap path so it's not so easy to just swap it out.
> 
> I guess you mean glibc-utf8-locales, if not I'm missing where that
> reference could come from.  That's why I insist on leaving exactly the
> same derivation.

I meant in commencement.scm. There's a glibc-utf8-locales-final near the
definition for %boot5-inputs.

> > I can make the change in core-updates. I'll play around with it and
> > see if I can come out with the same derivation using a different
> > function, but I'm not expecting it to turn out identical.
> 
> The colour of my lisp-rate belt isn't even close to some you can see
> around here but I could bring you some help if you want, because I think
> it's easier to do it without any change in current packages than it
> might sound.  Not the definitions in scheme, of course, I mean the
> derivations the daemon actually sees.
> 
> Said this, I've seen that [single-]locale-directory does mostly the
> same, and there is a build-locale function in gnu/build/locale.scm... so
> I'm starting to see as a better idea to clean up glibc-utf8-locales up
> in core-updates using the latter, as it would lead to cleaner code for
> the builder.
> 
> Could you check that and tell if you consider feasible what I propose?

I hadn't seen gnu/build/locales.scm. I'll have to see what we can do
about using it. We normally don't allow cross-over from the build side
to the packages side.

> Happy hacking!
> Miguel
> 
> [1] info "(libc)Using gettextized software"

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted