bug#37865: guix pull: error: You found a bug:

[Bengt Richter]

Hi Kai,

On +2019-10-27 08:54:19 +0100, Kai Mertens wrote:
> On Thu, 24 Oct 2019 13:49:56 -0700
> Bengt Richter <address@hidden> wrote:
> 
> > > 
> > > When invoking guix package -I for example, I encountered an error
> > > like guile: failed to install locale
> > >  
> > 
> > I have encountered the same error. It seems to recur for me after
> > major updates. So there seems to be something lurking to reawaken the
> > real error message source. I collected some symptoms and posted them
> > as bug#37900.
> > 
> 
> Hello Bengt,
> 
> as I see, issue #37900 is closed, but I don't understand the solution,
> unfortunately.
> 
> This issue #37865 is closed as well, so I don't know whether this reply
> reaches you well and is placed correctly.
> 
> I for myself use a different way to get around the warning messages,
> which re-occurred after a while:
> 
>  $ guix package -I
>  guile: warning: failed to install locale
>  warning: failed to install locale: Invalid argument
> 
> I have the impression, that
> 
> cat<<EOF >> ~/.bash_profile
> GUIX_PROFILE="$HOME/.guix-profile"
> source "\$GUIX_PROFILE/etc/profile"
> EOF
> 
> is not enough to provide full information regarding search paths.
> 
> As a complement, I put the output of
> 
>  guix package --search-paths -p "$HOME/.guix-profile"
> 
> into my ‘~/.bashrc’, but append the
> 
>  ${<VAR>:+:}$<VAR>
> 
> pattern to each line in order to keep existing variable content.
> 
> However, it seems as if the output of that command is incomplete as
> well, as it often (not always) misses information regarding
> GUIX_LOCPATH and PATH (~/.config/guix/current).
> 
> I append these definitions as well, just to make sure they are not
> missing. (In a helper script, I use a ‘sort -u’ to avoid redundant
> occurences of lines.)
> 
> cat<<EOF >> ~/.bashrc
> export PATH="$HOME/.config/guix/current/bin\${PATH:+:}\$PATH"
> export 
> GUIX_LOCPATH="$HOME/.guix-profile/lib/locale\${GUIX_LOCPATH:+:}\$GUIX_LOCPATH"
> EOF
> 
> Placing these complementary lines altogether in ~/.bash_profile won't
> help me, I use ~/.bashrc instead.
> 
> Then I perform a logout, login sequence and the error messages
> disappear and everything seems to run smoothly.
> 
> I update my ~/.bashrc after each new package generation.
> 
> As a conclusion, I would like to word three assumptions:
> 
> 1. sourcing GUIX_PROFILE is not enough
> 2. output of ‘guix package --search-paths’ is incomplete
> 3. ~/.bash_profile and ~/.bashrc are not equally weighted in respect to
>    guix environment settings
>

1. I think what produces GUIX_PROFILE is not designed to do what you are doing 
manually,
   nor IMO should it be, as there is (or should be) a proper solution ;-)
2. I don't know if it's incomplete, but I suspect you are saying so because it 
does not
   serve your current approach to solving the problem :)
3. True. Normally ~/.bash_profile is sourced only at login, whereas I think 
~/.bashrc is
   sourced by any new subshell being entered (normally, though AIUI options can 
make a difference). 

To diagnose your situation would you post the ouputs of:

1. strace guix -v |& grep locale

2. which guix|xargs readlink -f|xargs cat -n

3. guix package -I glibc

#1 should show where locale is being looked for and failing to be found

#2 will show that guix on the command line invokes a hash-bang guile script,
   setting some things up and calling the real machinery of guix.

My current version for #2 lists 3 script lines:
     1  #!/gnu/store/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6/bin/guile 
--no-auto-compile
     2  !#
     3  (begin (set! %load-path (cons (string-append 
"/gnu/store/053vb2vkbrv6mjddhkyhb6ddkj85d9ia-guix-module-union" 
"/share/guile/site/" (effective-version)) %load-path)) (set! 
%load-compiled-path (cons (string-append 
"/gnu/store/053vb2vkbrv6mjddhkyhb6ddkj85d9ia-guix-module-union" "/lib/guile/" 
(effective-version) "/site-ccache") %load-compiled-path)) (let ((locpath 
(getenv "GUIX_LOCPATH"))) (setenv "GUIX_LOCPATH" (string-append (if locpath 
(string-append locpath ":") "") 
"/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29/lib/locale")))
 (let ((guix-main (module-ref (resolve-interface (quote (guix ui))) (quote 
guix-main)))) (begin (bindtextdomain "guix" 
"/gnu/store/0m73px55qzbx70v2k346igajrszzz8kb-guix-locale-guix") (bindtextdomain 
"guix-packages" 
"/gnu/store/c01aal3wvwlhi5h81rz14yasf70w04j2-guix-locale-guix-packages")) 
(apply guix-main (command-line))))

Notice the -2.29 version of 
"/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29/lib/locale"
My problem was that I had version 2.28 installed, but not 2.29 -- at least not 
where it could be seen
What version is referenced in your #2 output?

My current output for #3 is
glibc   2.28    out     /gnu/store/c43rbmzv1laxgbnkvf76hx4305n4206a-glibc-2.28
glibc-locales   2.28    out     
/gnu/store/bb9alx1ap57pz0vmx7p1r8qk0lxxfg3x-glibc-locales-2.28
glibc-utf8-locales      2.29    out     
/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29

Before the solution to my problem, that command only showed the 2.28 lines.
The obvious thing to try was to install 2.29, so I chose the smaller 
glibc-utf8-locales.

guix install glibc-utf8-locales

That should have worked, but didn't, and that's what all the confusing stuff in 
bug#37900 came from.
Somehow avahi was mixed into the problem -- but this was solved by some mystery 
(to me) update,
and then after guix pull had pulled that in, guix install glibc-utf8-locales 
worked normally.

It consequently appeared in my #3 output -- and the locale complaints went away 
-- at least after a reboot,
but I'm not sure that was necessary.

So, bottom line, I would suggest posting the outputs to #1,#2, and #3 and 
figuring out what to do.

My bet is you'll revert your workarounds, do a guix pull and maybe guix update 
for good measure,
then guix install glibc-utf8-locales (unless you have an exotic locale, in 
which case you may need
to do guix install glibc-locales) then reboot, and hopefully the locale 
complaints will be gone.

> @all
> What do you think? Could this be regarded as useful information?
> Or does it address my specific use case only?
>
Hard to say for sure, until we see the outputs to #1,#2, and #3 :)

In general, I don't think it's a good idea to tempt people with obstacles
to copy possibly dangerous "solutions" -- especially when it comes to 
permissions,
but also bypassing intended barriers between profiles or other entities.

But it's good to let developers see what desperate hacks people are willing to 
use
to get on with life, so that they can provide user-friendly alternatives, as I 
think
they are all motivated to do. The core developers are amazingly energetic and 
productive,
but they only have so many man^H^H^H :) person-hours to give, so kudos to them!

> best regards
> Kai
> 
> -- 
> Kai Mertens <address@hidden>
> OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
> Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
> What is that? Please check: https://emailselfdefense.fsf.org/en/

HTH and doesn't mislead :)
--
Regards,
Bengt Richter