Cannot build Guix from source (error messages about the translations)

Hi Leo,

Looks like something is wrong with your setup… are you running in "guix environment guix"? What's your $LANG?

Le 18 octobre 2021 00:01:28 GMT-04:00, Leo Famulari <leo@famulari.name> a écrit :

Leo Famulari ???

This seems to hint at a locale error, and indeed it was: when I

check out a fresh guix.git and build it in a recent ‘guix

environment guix’ on Guix System, I get the same error as you.

When I repeat the exact same steps but first set

$ export LC_ALL=en_IE.utf8

in the environment, the build goes swimmingly.

I only ran each test once so it could be a coincidence, but I

doubt it.

As for the actual error…

At the risk of being naive: could it simply be that the missing

locale turns the Korean UTF-8 into a literal ‘??????’, which of

course matches another mangled @node string of the same length?

Kind regards,

T G-R

I managed to reproduce the issue on fedora, in a broken pure environmert. In a pure environment, fedora gives error messages about software that doesn't exist, and asks if I want to install them. If I ^C at that point, I enter the environment, but some things are missing.

There are litteral ?? in manuals that don't use ascii, and this is especially visible in the korean manual. Po4a works fine in my experimentation, but it looks like the po parser or regular expression matching is broken at the POXREF phase, and everything is copied as literal ??.

Maybe setting LANG to a UTF-8 locale in the poxref rule would help? It didn't hix the issue in my case, but I think that's because I'm missing even more variables.

Le 18 octobre 2021 07:54:08 GMT-04:00, Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> a écrit :

On Mon, Oct 18, 2021 at 07:23:40AM -0400, Julien Lepiller wrote:

Yes, it's in a "pure" environment.

Normally LANG=en_US.UTF-8, but in the pure environment, LANG is unset.

In both cases, LC_ALL is unset.

Hello,

Leo Famulari <leo@famulari.name> writes:

Can confirm that I can't build on a fresh Guix or on another machine.

I just had a look into the file guix.ko.texi. Unfortunately the file

itself is indeed full of question marks:

Chances are something wrong?

Kind regards,

Simon

Simon Streit <simon@netpanic.org> writes:

Extending my previous message:

I first thought that it had to do with commit

15c91189cb61c579f4289047c79530cefe75215f, but it turns out that commit

0623138ffa5b066afc25547ffdeb97753cb0ee9a creates these errors.

Commit d1b375402f5680b1e5a77dd1fb77e1e9d94625d1 is okay.

Kind regards

Simon

On 10/19/21 11:59 AM, Simon Streit wrote:

Building on Debian 10, I was about to report the same.

From a git bisect I got:

"0623138ffa5b066afc25547ffdeb97753cb0ee9a is the first bad commit".

I can confirm that in the meantime, compiling with $LC_ALL set manually (to the

value of $LANG outside the environment) also worked for me:

---

guix environment guix --pure --ad-hoc help2man git strace bash -- sh -c "export

LC_ALL=$LANG && ./bootstrap && ./configure --localstatedir=/var && make

---

Kind regards,

Raphaël

I had the same problem with my checkout of the “master” branch

after I ran “guix pull --branch=core-updates-frozen”.

I worked around this by running

rm doc/contributing.*.texi

and then ./bootstrap, ./configure …, make. This made PO4A

regenerate these files correctly.

--

Ricardo

Le Tue, 19 Oct 2021 12:29:47 +0200,

Raphaël Mélotte <raphael.melotte@mind.be> a écrit :

Since it seems this is due to the lack of the LC_ALL variable in the

pure environment, how about the attached patch?

merge 51294 51259

Hello,

On 10/20/21 4:06 AM, Julien Lepiller wrote:

With the attached patch on top of master (c650160abb), the build fails with

messages similar to this one:

./doc/guix.de.texi:158: @ref reference to nonexistent node `Translating Guix'

I attached the build logs.

I used the following to build, to make sure to start from a clean tree:

---

git clean -ffdx && guix environment guix --pure --ad-hoc help2man git strace --

sh -c './bootstrap && ./configure --localstatedir=/var && make' | tee build.log

---

Kind regards,

Raphaël

Arg, I don't get why you get that one… I'll see what I can find. In the meantime, you can build the rest of guix locally with "make make-go", which doesn't depend on the manuals, although you won't be able to push with the prepush hook.

Le 20 octobre 2021 06:40:17 GMT-04:00, "Raphaël Mélotte" <raphael.melotte@mind.be> a écrit :

Le Wed, 20 Oct 2021 12:40:17 +0200,

Raphaël Mélotte <raphael.melotte@mind.be> a écrit :

So, it looks like my change prevented the xref command from running

altogether, which explains the error. Moving the variable definition

seems to help; I was able to build from a clean checkout in a pure

environment with the attached revised patch.

On 10/20/21 2:11 PM, Julien Lepiller wrote:

Indeed! With this change it compiles successfully on my side as well.

Thanks,

Raphaël

Hi,

I'm on i686, and I've tried all the approaches mentioned:

- export LC_ALL=en_US.utf8

- rm doc/contributing.*.texi

- the patch in doc/local.mk

on top of the following commit:

19d3cfec72 gnu: python-arrow: Move python-pytz to native-inputs.

I tried building Guix with both:

- guix environment guix -C guix

- guix environment --pure guix

And for building I use

export LC_ALL=en_US.utf8

rm -f doc/contributing.*.texi && \

./bootstrap && \

./configure --localstatedir=/var && \

make clean && \

make -j2

And that gives the following compilation error (with guix environment

guix -C guix):

I'll then try 'make make-go' instead in order to be able to test

patches before sending them.

Denis.

You might be running with modified files, or the container is doing something unexpected. Can you try again from a clean checkout, or after cleaning with "git clean -fdx"? This should put the repo back to the last commit, and remove any additional files, as if you just pulled it.

Le 20 octobre 2021 11:44:38 GMT-04:00, Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> a écrit :

Denis 'GNUtoo' Carikli ???

This isn't enough, you need to rm doc/guix*.*.texi as well:

Kind regards,

T G-R

On Wed, 20 Oct 2021 11:52:54 -0400

Julien Lepiller <julien@lepiller.eu> wrote:

I tried many things (including git clean -dfx) and at the end I don't

know exactly what made it compile but it works now and I suspect that

it's either removing GUIX_PACKAGE_PATH or using guix pull && guix

package -u that fixed it for me.

Denis.

I pushed my patch to master as

c5881ff1f3ea321401b0f040c4e795bcd452ef5d, so tentatively closing this

bug.

Note that, if you encountered the issue, this patch is not enough: you

already have .texi files that contain lots of "??". You'll need to

start from a clean checkout, or at least clean the texi files with

something like:

git pull # to get the patch

rm doc/*.texi # remove texi files

git checkout doc # reinstate those that are commited

./bootstrap # recreate dummy files for the Makefile to be happy

make # should now be working

Sorry for the inconvenience!