e
>extremely costly bootstrap process through which its building blocks (in
>particular recent Kotlin versions) can be built.
>
>The work on this is mainly done by Julien Lepiller in channel
>guix-android :
>https://framagit.org/tyreunom/guix-android/-/blob/master/android/pac
At least for Frama-C, the issue is environment variables. It requires OCAMLPATH
to work correctly. So this works:
guix shell frama-c ocaml -- frama-c
Even though the compiler is not needed.
It's another example of why we should propagate search paths, although we could
also redefine the same
Ah, you sent this while I was writing to the other bug. Would it be possible to
convert the recipe to use the dune-build-system instead? It sounds like it
would be more future-proof, and it's also prefered by opam people.
Le 9 mars 2024 22:03:15 GMT+01:00, Vivien Kraus a
écrit :
>*
Hi Guix!
There seems to be a time bomb in icedtea@2 and openjdk@9. while
building it:
Error: time is more than 10 years from present: 138852720
java.lang.RuntimeException: time is more than 10 years from present:
138852720 at
It seems to be working on bordeaux:
https://data.qa.guix.gnu.org/gnu/store/yirvdai4a50mv6fqbw44nw9s38agxrzj-java-geronimo-xbean-bundleutils-4.5.drv
Looking at the build log, it's related to a failure of java-testng, which had
sometimes randomly failed in the past. It's hard to diagnose:
It's interesting to see that only the generate po files are compiled to
non-reproducible mo files. All other translations seem fine, right? Could it be
related to the way these po files are created? It might introduce a timestamp
at that point, but I can't check right now.
Le 17 octobre 2023
Le Sat, 26 Aug 2023 10:25:53 +0900,
elaexuotee--- via Bug reports for GNU Guix a écrit :
> The new pretty progress bars are quite nice. One issue I am
> ecountering, however, is demonstrated in the snippet below:
>
> オブジェクトにインデックスを付けています 71%
>
Le Fri, 25 Aug 2023 20:24:28 +0200,
Denis 'GNUtoo' Carikli a écrit :
> ./pre-inst-env guix deploy -L
> rockpro64/ rockpro64/rockpro64.scm
If you're doing this on a non aarch64 system, you'll need to add
--system=aarch64-linux.
Le 21 août 2023 14:09:14 GMT+02:00, Maxime Devos a
écrit :
>Consider, e.g.,
>
>(format #t (G_ "~0@*~a should be set to ~1@*~a instead of ~2@*~a~%") "CC"
>"(cc-for-target)" "gcc")
>->
>CC should be set to (cc-for-target) instead of gcc
>
>By using positional arguments like this, translators can
Untested yet, but looks fine, thanks
Le 13 juin 2023 07:08:11 GMT+02:00, pukkamustard a
écrit :
>
>Hi Benjamin,
>
>Thanks for the report.
>
>"Benjamin" writes:
>
>> Here is a minimal example to reproduce the bug :
>>
>> ---
>> (use-modules
>> (gnu packages ocaml)
>> (guix build-system
I'll probably tag a release this week-end.
Le 24 mai 2023 16:55:56 GMT+02:00, "Ludovic Courtès" a écrit :
>Hello,
>
>Julien Lepiller skribis:
>
>> Thanks, I was able to test it simply by doing something like
>> (wait-for-link "veth0") and from another
Thanks, I was able to test it simply by doing something like
(wait-for-link "veth0") and from another terminal, "ip l add veth0 type
veth peer veth1" (it doesn't have to be veth, it's the first one I
thought of that I didn't have to reach the manual for).
Pushed to guile-netlink's master :)
Le
I don't remember why we did that. The constraints for that file are:
- it's not required to install it
- it must be built before the manuals are generated (it's used for translations)
- it should be built, since otherwise it takes a long time to run
- it has no dependencies
- it's not actually
How weird, I don't see it spelled like that in the repository (latest master).
I don't see any recent change in the file either.
Maybe there's an issue with your local checkout.
Guix has a checkout of the repository in one of the directories of
~/.cache/guix/checkouts. You should be able to
Gettext already checks issues with format strings, and for the manual, I always
try to build it, so I can catch most issues. Unfortunately, we don't have good
tools to check texinfo markup in our strings, so this kind of error can stell
slip in, I hadn't realized.
I'll try to contact the
OK, fixed on master and on weblate. Hope it works now!
Had to change @esempio to @example (it's Texinfo markup that's not supposed to
be cranslated) and even found a typo'd @sempio.
Also, if you want to help with translations andqproof-reading, you're very
welcome to edit on
Le Mon, 06 Mar 2023 23:46:57 +0100,
Ludovic Courtès a écrit :
> Hi Luigi,
>
> Luigi Salamone skribis:
>
> > I'm unable to use guix commands like "guix system search KEYWORD".
> > No problem if I run the commend with LANG=LC_ALL.
>
> [...]
>
> > ice-9/boot-9.scm:1685:16: In procedure
Le Sat, 28 Jan 2023 20:28:59 +0100,
Csepp a écrit :
> Julien Lepiller writes:
>
> > Le Thu, 13 Oct 2022 18:16:18 +0200,
> > Csepp a écrit :
> >
> >> Julien Lepiller writes:
> >>
> >> > Maybe this could be fixed in the dune-build-s
Le Thu, 13 Oct 2022 18:16:18 +0200,
Csepp a écrit :
> Julien Lepiller writes:
>
> > Maybe this could be fixed in the dune-build-system?
> >
> Actually, good call. I'll look into it, unless you want to take a
> stab at it.
With the test-target argument removed, do you consider this fixed?
Le Tue, 24 Jan 2023 03:23:44 +0100,
Csepp a écrit :
> Truncated stack trace:
>
> ```
> ...
> In guix/import/opam.scm:
> 287:2 3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
> In unknown file:
>2 (filter #
> …) In guix/import/opam.scm:
>290:13 1 (_
Ah this is dangerous. You updated the msgid but not the msgstr. This means the
translation will keep using the old format string. Could you also update the
msgstr when a translation exists?
You can also drop all the files with no translation for the affected msgids
from your patch, though this
Changing the po files in guix repo will work at first, it'll be negated next
time I push changes from weblate. We could change the po files to ensure
continuity, but we have to also apply the change to the repo behind weblate. I
can take care of it after the patch is pushed.
Le 22 janvier 2023
realising.
>By the time I took to email, I was up around the chandeliers. Do excuse.
>
>Loz.
>
>On Mon, Jan 16, 2023 at 7:39 PM Julien Lepiller wrote:
>
>> Le Mon, 16 Jan 2023 13:08:37 +0100,
>> Laurence Taylor a écrit :
>>
>> > > ice-9/eval.scm:293:34
Le Mon, 16 Jan 2023 13:08:37 +0100,
Laurence Taylor a écrit :
> > ice-9/eval.scm:293:34: no code for module (sExplorer Excluderfi
> > srfi-35)
This looks weird, what is "Explorer Excluder"? It's definitely not in
gnu.scm.
Le Sun, 15 Jan 2023 12:54:45 +0100,
Josselin Poiret a écrit :
> Hi Julien,
>
> Julien Lepiller writes:
>
> > So, apart from the output filename which obviously changes, it seems
> > that the differences are:
> >
> > - order of dependencies,
> > -
Hi Guix!
I found out today that guix pull does not compute the same derivation
on two machines, with the same architecture (x86_64), using the same
initial Guix revision (4473be9) and pulling to the same commit
(c77978d).
guix-packages-base.drv seems to be the first derivation to differ. I
get:
Hi Derwin,
The report looks like a network failure, so maybe try again?
Le 10 décembre 2022 09:30:33 GMT+01:00, Derwin McGeary
a écrit :
>Hi!
>
>The output of guix pull suggested sending the output here, so here I am.
>
>Context: running guix as user with a foreign distro (Ubuntu 22.10),
Oh no, do we have a Texi injection vulnerability in Guix? :)
What I understand is that an error occurs when trying to show a hint to the
user (display-hint in the backtrace). This calls texi->plain-text which
transforms texinfo markup to text for displaying on a terminal. With your user
name,
Current system generation identifies the one that would boot by default.
Basically, booted ≠ current. Maybe guix system could show that information.
Le 22 novembre 2022 18:06:19 GMT+01:00, Felix Lechner via Bug reports for GNU
Guix a écrit :
>Hi,
>
>On my equipment the command 'guix system
Hi,
This is not a bug. The gcc package exists, but is hidden from CLI on purpose
because you shouldn't install it and use it directly. You should use
gcc-toolchain instead.
Le 15 novembre 2022 00:53:32 GMT+01:00, bbb ee a écrit :
>in version c81457a5883ea43950eb2ecdcbb58a5b144bcd11 of guix,
Saluton!
The pot generation process for translations at weblate is separate from
the one for Guix. The pot in Guix is outdated and not updated
automatically.
It seems that the rules for generating the pot changed in Guix, but I
don't use them for generating the pot files in the translation repo.
continue. GNU Guile 3.0.7
Copyright (C) 1995-2021 Free Software Foundation, Inc.
That sounds weird, I would expect our guile to be more recent than that. The
manual suggests using "sudo guix system" instead of "sudo -E guix system",
maybe that's the issue?
Le 26 octobre 2022 00:43:03
Hi, replying to a few emails at once.
The ant-build-system uses zip -0 to produce an uncompressed archive. By
default, jar produces a compressed one, so there's a repack phase for that:
http://git.savannah.nongnu.org/cgit/guix.git/tree/guix/build/ant-build-system.scm#n226
Embedding the
You're right, java package don't retain references to there input, that's why
we propagate required dependencies (mh… sometimes). I don't know how they could
reference dependencies directly.
Le 17 octobre 2022 23:04:47 GMT+02:00, Maxim Cournoyer
a écrit :
>Hello,
>
>I'm not a Java expert, but
One thing I suspect is that weblate takes quite a lot of time to pull changes
from the intermediate repository, so if you provide a translation while the
repo is being synced, I think they might be reset when the file is finally
loaded by weblate.
Not sure if this could explain this many
(beautify-description #f _)
Seems to be the cause. Yet, there is a description. Maybe parsing ends a bit
too soon?
Le 13 octobre 2022 18:07:08 GMT+02:00, Csepp a écrit :
>The error might not be the same for others, I have a slightly patched
>opam->guix-package function.
>
>guix import opam
Maybe this could be fixed in the dune-build-system?
Le 13 octobre 2022 17:03:43 GMT+02:00, Csepp a écrit :
>So I'm working on building MirageOS unikernels with Guix, which means
>using the OPAM importer *a lot*, which unearths some very Fun TM bugs.
>Here is the first one:
>
>guix import opam
Hi Guix!
I was trying to use a perl software that uses gtk3. Its main window
does not show up and it seems to get stuck. I tried to come up with a
reproducer. In guix shell perl perl-gtk3:
```
#!/usr/bin/env perl
use strict;
use warnings;
use diagnostics;
use feature ':5.14';
use Gtk3 '-init';
I installed Guix on a new drive, so I tried the installer from the latest
image. After reviewing the system config, the installer goes to a black screen
where guix output is shown. Although I can see messages about substitutes being
updated, and how much will be downloaded, all download lines
You can push this fix directly to the repo, but please also fix it on weblate
or it'll break again next time I update translations.
Le 7 octobre 2022 08:34:51 GMT+02:00, Ricardo Wurmus a
écrit :
>
>Ricardo Wurmus writes:
>
>> The error in guix.de.texi is an infinite loop. The location it
It's probably because other importers are structured that way. I'd be in favor
of changing that and using the condition system.
Le 27 septembre 2022 13:33:56 GMT+02:00, Csepp a écrit :
>The specific error is this:
>Wrong number of values returned to continuation (expected 2)
>It is caused by
Le Thu, 22 Sep 2022 10:19:16 +0200,
Rostislav Svoboda a écrit :
> It seems like this issue has been resolved by the
> 79897a37012a9bfbcb460cfe0aaaf32aab79dbe5 if so then please close this
> issue.
>
> Thanks
>
>
>
Ah indeed, a similar patch was sent independently and pushed before
this. I
I don't think checking for file-exists before mkdir-p makes much sense. Doesn't
mkdir-p make the same checks already?
I thought find-files required two arguments? Also the first argument could be
simplified to input-folder
Otherwise LGTM, but I can't push myself currently. Thanks!
Le 12
Le 7 septembre 2022 19:07:10 GMT+02:00, zimoun a
écrit :
>Hi,
>
>Well, the field reads,
>
>+(license (package-home-page qtbase
>
>so why is the compiler accepting that? Is a warning raised?
>
No warning because the compiler has no way to know you don't want to do that.
license is a
Quoting my own email I think this is the relevant bit. I don't think it's an
issue in haunt, but something with qt:
srfi/srfi-1.scm:241:2: In procedure map:
In procedure map: Wrong type argument: "https://www.qt.io/;
building pages in '/tmp/gnu.org/software/guix'...
Le 5 septembre 2022 14:04:10
2022 10:35:43 GMT+02:00, zimoun a
écrit :
>Hi Julien
>
>On dim., 04 sept. 2022 at 17:18, Julien Lepiller wrote:
>
>> I tried to update the po files for the website today, but I was unable
>> to test. Trying to build the website from a clean checkout (without
>>
iles. After removing the generation
and "guix gc", these files no longer exist, and I'm in trouble :)
So, guix home and guix gc are working as intended, but the change to no
longer adding a "." at the beginning of file names (which makes total
sense) tripped me up.
Le Sun, 4
Hi Guix!
Today I ran "guix home delete-generations" to remove my old home
generations. It removed generations 0 and 17. I'm on generation 18.
Then I ran "guix gc" and after I noticed I couldn't run a program from
my window manager (its menu is managed from guix home), I tried to look
at what was
Hi Guix!
I tried to update the po files for the website today, but I was unable
to test. Trying to build the website from a clean checkout (without
updating translations) gives this error. I think it's related to the
code that generate the list of packages:
Backtrace:
In ice-9/eval.scm:
I don't know how to fix it, but here is what I think is the issue:
in guix/scripts/system/reconfigure.scm:
#:autoload (guix describe) (current-channels)
...
(define* (check-forward-update ...
(current-channels ...))
(define new (current-channels)) ; this is supposed to be the
I must have misunderstood, I thought you wanted to pass it during the build of
glibc.
Le 21 juillet 2022 17:49:36 GMT+02:00, "(" a écrit :
>On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes. But
>> it's not 'just use
We're trying to avoid hard-coding bash-static in glibc, instead letting the
build-system fill the value in dependents. So that can't be it, right?
Le 21 juillet 2022 17:11:56 GMT+02:00, "(" a écrit :
>
>And considering the definition of system(3) in glibc:
>
>@ sysdeps/posix/system.c (took me
If anything, you also need to chainload to boot on haiku, which is free
software. So no reason not to implement it.
Le 16 juillet 2022 11:59:29 GMT+02:00, Josselin Poiret a
écrit :
>Hello both of you,
>
>Julien Lepiller writes:
>> Of course this is only a workaround I'm propo
Hi Peter,
This is indeed not nice. Guix does not provide a useful package that would
reinstall boot configuratipn because boot configuration is managed together
with the rest of the system configuration.
You need to update your /etc/config.scm to declare more entries, and
reconfigure. Here
I've heard that theory before. From observation on my late armhf server (two
cores):
- it takes just below 2GB to build one of the derivations
- It doesn't swap a single byte
- whether with two or a single core, it takes roughly the same amount of memory
- substitution is nice, it doesn't
Hi Ronak,
Guix does not control the infrastructure behind the GNU project. You need to
contact the GNU sysadmins, though I don't know how :)
Le 12 juillet 2022 02:45:38 GMT+02:00, Ronak B a écrit :
>Hi, I noticed today when I typed "man cat" and clicked on the "http://;
>link in the man page
It's not a bug, because you don't have icedtea in your profile, but
icedtea:jdk. Guix is picky with outputs. Try "guix remove icedtea:jdk" :)
On July 3, 2022 7:25:46 PM GMT+02:00, bbb ee wrote:
>Hi,
>
>I have icedtea installed in my current profil, but `guix package remove`
>doesn't find it.
Hi Guix!
I figured out this morning that my guix pull profile ("current") was more than
1GB. Looking at the closure, I found a few oddities.
There's gcc in there, which is the second most important contributor after
guix-*-modules (150 MB). It's referenced by gcc-toolchain, itself only
On June 16, 2022 7:28:45 AM GMT+02:00, vi...@riseup.net wrote:
>hey all.
>
>vidak here.
>
>i cannot get `guix pull` to work for me.
>
>i am having issues getting the package-cache.drv to build.
>
>i was homeless, and unable to update my workstation for about... a
>month?
>
>here are some related
Since then, this has been fixed:
guix import opam coq-of-ocaml
...
(description
"This package lacks a description. Run \"info '(guix) Synopses and
Descriptions'\" for more information.")
...
So, closing :)
Le Sat, 04 Jun 2022 17:00:15 +0200,
"Dr. Arne Babenhauserheide" a écrit :
> Julien Lepiller writes:
> > What I did instead is, since jdom wants to set more features than
> > supported in the driver, to add dummy support for all these
> > additional features by
y not fix
the issue.
What I did instead is, since jdom wants to set more features than
supported in the driver, to add dummy support for all these additional
features by just not throwing the exception. It's not very satisfying,
but it works and we don't keep a vulnerable jdom around. With the
att
Le Fri, 20 May 2022 13:36:54 +0200,
raingloom a écrit :
> Sorry, can't debug this further right now.
>
> ```
> $(guix build frama-c)/bin/frama-c
> [kernel] User Error: [findlib] package 'ocamlgraph' not found
> (required by `frama-c.kernel') [kernel] User Error: Deferred error
> message was
you. I made a couple of "guix package
>-- roll-back" because I thought It could be one of the last packages I
>wanted. But If It was the server is good to know.
>Thank you!
>
>El mié., 4 may. 2022 7:25, Julien Lepiller escribió:
>
>> Hi Pedro,
>>
>> I be
Thanks for getting back to us. Closing then. Enjoy your new guix :)
On May 5, 2022 11:54:15 PM GMT+02:00, Nathan Wilcox
wrote:
>It completed successfully.
>
>On Tue, May 3, 2022 at 10:27 PM Julien Lepiller wrote:
>
>> Hi Nathan,
>>
>> I believe this was caused
t;Wilson
>
>On Wed, 4 May 2022, 07:30 Julien Lepiller, wrote:
>
>> Hi Wilson,
>>
>> I believe this was caused by a network issue (). We lost our
>> main server for a few hours when you tried running guix pull.
>>
>> Could you try again and report success/fa
Hi Wilson,
I believe this was caused by a network issue (). We lost our main
server for a few hours when you tried running guix pull.
Could you try again and report success/failure?
Thanks for reporting the issue! It's much appreciated :)
On May 3, 2022 8:56:51 PM GMT+02:00, surface wrote:
Hi Nathan,
I believe this was caused by a network issue (). We lost our main
server for a few hours when you tried running guix pull.
Could you try again and report success/failure?
Thanks for reporting the issue! It's much appreciated :)
On May 3, 2022 9:44:19 PM GMT+02:00, Nathan Wilcox via
Hi Pedro,
I believe this was caused by a network issue (). We lost our main
server for a few hours when you tried running guix pull.
Could you try again and report success/failure?
Thanks for reporting the issue! It's much appreciated :)
On May 3, 2022 11:18:16 PM GMT+02:00, Pedro Herrero
On March 23, 2022 4:46:53 PM GMT+01:00, zimoun wrote:
>Hi Luis,
>
>On Wed, 23 Mar 2022 at 16:13, Luis Felipe
>wrote:
>
>> So, if Julien and Arne, for example, don't experience the issue anymore, I'm
>> happy to close the issue.
>
>Let wait 15 days and if no answer, let assume it is not an
guix shell ocaml ocaml-findlib frama-c
Should work :)
Ocaml is needed to define OCAMLPATH, ocaml-findlib is what frama-c is missing.
Should we wrap the binary?
On February 21, 2022 10:13:07 PM GMT+01:00, raingloom
wrote:
>I was just idly messing around so I'm not super motivated to dig
Openjdk has two outputs: out and jdk. The default output contains only
what's necessary to *run* a Java application, while the jdk output
contains that *in addition* to what's needed to build Java applications
(javac, ...). I'm not knowledgeable enough to know if javadoc or doclet
need to be in
Le Sun, 30 Jan 2022 18:53:29 +0100,
Ludovic Courtès a écrit :
> Hi Julien,
>
> Julien Lepiller skribis:
>
> > It was not supported in guile-netlink, so I added support for
> > #:peer and other new arguments in addr-add and addr-del. There's no
> > release yet
It was not supported in guile-netlink, so I added support for #:peer and other
new arguments in addr-add and addr-del. There's no release yet, but I'd be glad
if you could check it works as expected (--with-latest=guile-netlink should
work).
Le 25 décembre 2021 08:03:16 GMT-05:00, Jonathan
From the backtrace I can't tell you more than this. The installer tried to run
"mkfs.btrfs -f /dev/napper/crypt" but the command ended with status 1 (error).
Unfortunately guix didn't capture the error. Next time you try, could you run
the failid command (you'll find the exact one at the
The problem seems to be solved now. Thanks for reminding me of my old bugs :).
Closing.
Le 24 novembre 2021 18:32:20 GMT-05:00, zimoun a
écrit :
>Hi Julien,
>
>On Mon, 15 Jan 2018 at 14:52, julien lepiller wrote:
>
>> claws-mail has a plugin system to add functionnality. Fo
Hi,
First, today when running guix import opam iter, I get a synopsis, and
#f as the description because the field is missing.
I also pushed a small patch to master, as
24aa7b3c21309b63cc6e8e18d6417d2cddccf6c6, that ensures that, when the
field exists but contains unknown data, we also return #f
I just pushed fixes to master, so now everything listed in "guix
refresh -l ocaml@4.07" builds without issues. Closing :)
Le 19 novembre 2021 10:41:21 GMT-05:00, Julien Lepiller a
écrit :
>Closing since the links now seem to be working.
Closing since the links now seem to be working.
I don't have this issue anymore, so closing. Thanks!
Closing since the website manual is now up to date :)
I haven't been able to reproduce it in a long time, so closing.
Since then, we have openjdk 10, and much more recent versions. I don't remember
what fixed the issue, but I haven't seen it since then, so closing :)
Closing since it now builds again (even got a substitute from bordeaux :D)
I plan to get rid of ocaml4.07* at some point. For that, I'll need to import a
bunch of packages (ocaml-core and friends, at least). Will see if I have enough
time for that.
Le 15 novembre 2021 07:59:53 GMT-05:00, zimoun a
écrit :
>Hi,
>
>These OCaml packages fail to build because some issue
Hi, I think you fixed openjdk16 instead of openjdk17, this makes the
patch a bit confusing to read.
Le Sun, 14 Nov 2021 21:59:44 +0100,
"Dr. Arne Babenhauserheide" a écrit :
> Julien Lepiller writes:
>
> > Le Mon, 08 Nov 2021 21:32:16 +0100,
> > "Dr
Le Mon, 08 Nov 2021 21:32:16 +0100,
"Dr. Arne Babenhauserheide" a écrit :
> Hi,
>
> the attached patch adds openjdk@17
>
> Take care with updating packages depending on this, because the
> changes to the module system can cause runtime failures.
>
Hi!
sorry for the delay. I tried your
Le Wed, 27 Oct 2021 20:49:02 +0200,
"Dr. Arne Babenhauserheide" a écrit :
> "Dr. Arne Babenhauserheide" writes:
>
> > The attached patch updates openjdk11 to the latest version. The
> > update includes some important bugfixes for compile errors of
> > classfiles.
>
> > +(version
Le Mon, 25 Oct 2021 21:15:23 +,
Raimundo Martins via Bug reports for GNU Guix a
écrit :
> Hey!
>
> Turns out that, since I use the runit init system, GUIX_LOCPATH
> wasn't being set anytime before guix-daemon started, since
> /etc/profile.d/guix.sh was not sourced. As a fix I set that
Le Wed, 27 Oct 2021 21:18:35 +0200,
Mikołaj Wielgus a écrit :
> In 2020 KiCad moved its official website to kicad.org [1].
>
> Recently, a former member has betrayed the project and sold the
> kicad-pcb.org domain name to an unknown third party. The new owner has
> subsequently set up a fake
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
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
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?
>
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 mast
Le Wed, 20 Oct 2021 04:04:19 +0200,
Julien Lepiller a écrit :
> I think this is the same as #35519?
>
>
>
Sorry, I meant #51259
rt LC_ALL=$LANG && ./bootstrap && ./configure
> --localstatedir=/var && make ---
>
>
> Kind regards,
>
> Raphaël
>
>
>
Since it seems this is due to the lack of the LC_ALL variable in the
pure environment, how about the attached patch?
>From
I think this is the same as #35519?
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 ??
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
1 - 100 of 372 matches
Mail list logo
