Hi,
On Thu, 21 Oct 2021 at 20:57, jgart via Bug reports for GNU Guix
wrote:
> https://git.sr.ht/~jgart/dotfiles/tree/master/item/bin/executable_guix-prepare-tree
--8<---cut here---start->8---
guix environment guix --container -- ./bootstrap \
&& gui
On Fri, 22 Oct 2021 00:38:02 + help-debb...@gnu.org (GNU bug Tracking
System) wrote:
Thanks for fixing that! I'll just run this script I've been using again:
https://git.sr.ht/~jgart/dotfiles/tree/master/item/bin/executable_guix-prepare-tree
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 tex
On Wed, 20 Oct 2021 11:52:54 -0400
Julien Lepiller wrote:
> 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 remov
Denis 'GNUtoo' Carikli 写道：
- rm doc/contributing.*.texi
This isn't enough, you need to rm doc/guix*.*.texi as well:
./doc/guix-cookbook.zh_Hans.texi:2892: @node `'
previously defined
Kind regards,
T G-R
signature.asc
Description: PGP signature
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
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 g
On 10/20/21 2:11 PM, Julien Lepiller wrote:
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.
Le Wed, 20 Oct 2021 12:40:17 +0200,
Raphaël Mélotte a écrit :
> Hello,
>
> On 10/20/21 4:06 AM, Julien Lepiller wrote:
>
> >
> > Since it seems this is due to the lack of the LC_ALL variable in the
> > pure environment, how about the attached patch?
>
> With the attached patch on top of mas
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"
Hello,
On 10/20/21 4:06 AM, Julien Lepiller wrote:
Since it seems this is due to the lack of the LC_ALL variable in the
pure environment, how about the attached patch?
With the attached patch on top of master (c650160abb), the build fails with
messages similar to this one:
./doc/guix.de.te
Le Tue, 19 Oct 2021 12:29:47 +0200,
Raphaël Mélotte a écrit :
> On 10/19/21 11:59 AM, Simon Streit wrote:
> > Extending my previous message:
> >
> > I first thought that it had to do with commit
> > 15c91189cb61c579f4289047c79530cefe75215f, but it turns out that
> > commit 0623138ffa5b066afc2554
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
On 10/19/21 11:59 AM, Simon Streit wrote:
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 d1b375402f5680b1e5a77dd1fb77e1e9
Simon Streit writes:
> Leo Famulari writes:
>
>> I noticed today that I can't build Guix from a fresh Git checkout in the
>> usual manner. Something goes wrong while building the Korean language
>> info manual. I tested it several times and on two different computers,
>> both x86_64.
>
> Can conf
Hello,
Leo Famulari writes:
> I noticed today that I can't build Guix from a fresh Git checkout in the
> usual manner. Something goes wrong while building the Korean language
> info manual. I tested it several times and on two different computers,
> both x86_64.
Can confirm that I can't build
On Mon, Oct 18, 2021 at 07:23:40AM -0400, Julien Lepiller wrote:
> Hi Leo,
>
> Looks like something is wrong with your setup… are you running in "guix
> environment guix"? What's your $LANG?
Yes, it's in a "pure" environment.
Normally LANG=en_US.UTF-8, but in the pure environment, LANG is unset
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 ??
Leo Famulari 写道：
./doc/guix.ko.texi:431: here is the previous definition as @node
./doc/guix.ko.texi:2065: @node `??' previously defined
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 Syst
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 a
écrit :
>I noticed today that I can't build Guix from a fresh Git checkout in the
>usual manner. Something goes wrong whil
I noticed today that I can't build Guix from a fresh Git checkout in the
usual manner. Something goes wrong while building the Korean language
info manual. I tested it several times and on two different computers,
both x86_64.
--
$ guix describe
Generation 23 Oct 18 2021 00:23:51(current
21 matches
Mail list logo
