Hi Leo and George,
I've taken a stab at improving the "Substitutes" section. Please let me
know if you have any concerns by replying to the patch email submission:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29271
I think the existence of this email thread proves that the question of
"Are sub
On Sat, Nov 11, 2017 at 10:36:26PM -0500, myglc2 wrote:
> Yes, but ... the average bear using GuixSD, having internalized Guix'
> assurances that substitutes are reliably the same as what they could
> build-from-source locally, naturally assumes that substitutes will be
> used.
>
> Unfortunately t
On 11/11/2017 at 20:29 Leo Famulari writes:
> On Sat, Nov 11, 2017 at 10:29:30AM -0500, myglc2 wrote:
>> On 11/10/2017 at 15:30 Chris Marusich writes:
>> > Thank you for the clarification. This is what I did not understand. I
>> > read the manual and got the impression that when --fallback has n
On Sat, Nov 11, 2017 at 10:29:30AM -0500, myglc2 wrote:
> On 11/10/2017 at 15:30 Chris Marusich writes:
> > Thank you for the clarification. This is what I did not understand. I
> > read the manual and got the impression that when --fallback has not been
> > given, if a given substitute cannot be
On Sat, Nov 11, 2017 at 11:23:00PM +0100, Marco van Hulten wrote:
> > This is terrible, but you can work around it by passing a large value to
> > the --max-silent-time "common build option": [...]
>
> Hmm, but the time-out is now after 1 hour of silence, and the whole
> process takes over 10 hour
Leo-
Op 10 nov 11:35 schreef Leo Famulari:
> On Fri, Nov 10, 2017 at 08:26:12AM +0100, Marco van Hulten wrote:
> > kodi@watson ~$ time guix pull --cores=1
>
> [...]
>
> > compiling... 75.4% of 647 filesbuilding of
> > `/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' timed
On 11/11/2017 at 09:05 Chris Marusich writes:
> myglc2 writes:
>
>> On 11/10/2017 at 15:30 Chris Marusich writes:
>>
>>> Hi Leo,
>>>
>>> Leo Famulari writes:
>>>
Substition is considered to fail when Guix is expecting a substitute but
the server returns 404, 504, or some other unexpect
myglc2 writes:
> On 11/10/2017 at 15:30 Chris Marusich writes:
>
>> Hi Leo,
>>
>> Leo Famulari writes:
>>
>>> Substition is considered to fail when Guix is expecting a substitute but
>>> the server returns 404, 504, or some other unexpected problem occurs. It
>>> is not considered to fail if the
On 11/10/2017 at 15:30 Chris Marusich writes:
> Hi Leo,
>
> Leo Famulari writes:
>
>> Substition is considered to fail when Guix is expecting a substitute but
>> the server returns 404, 504, or some other unexpected problem occurs. It
>> is not considered to fail if the server initially reports t
Hi Leo,
Leo Famulari writes:
> Substition is considered to fail when Guix is expecting a substitute but
> the server returns 404, 504, or some other unexpected problem occurs. It
> is not considered to fail if the server initially reports that no
> substitute is available.
Thank you for the cla
On Fri, Nov 10 2017, Chris Marusich wrote:
> Anecdotally, I swear I've seen guix build some things from source even
> when I did not specify --fallback. Has anybody else seen that occur?
Yeah, I've definitely seen that. My assumption was that this is what's
meant to happen when substitutes aren'
On Fri, Nov 10, 2017 at 08:26:12AM +0100, Marco van Hulten wrote:
> kodi@watson ~$ time guix pull --cores=1
[...]
> compiling... 75.4% of 647 filesbuilding of
> `/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' timed out after
> 3600 seconds of silence
[...]
> real 609m30.245s
> Thomas Sigurdsen writes:
>
> >> Secondly, I noted that with, e.g., 'guix package -i kodi' software gets
> >> compiled. I understood that GNU Guix is capable of both binary and
> >> source packages. Which should I typically expect? Can I choose?
Guix is a build-from-source system that can tr
Op 09 nov 21:53 schreef Mathieu Othacehe:
> My bad, this has been fixed by Efraim in
> d8f075c3a3daba93ff4420bbe0b1833712aaa0e9.
>
> You may want to guix pull again !
This work again — thanks for the quick response.
However, now I get the freeze again at around 75 %:
```
kodi@watson ~$ time gui
Thomas Sigurdsen writes:
>> Firstly, it often says that I need to use '--fallback'. Is that
>> because the binary is not available?
>>
>
> '--fallback' means that guix will fall back to compiling from source if
> it can't download binaries (also called substitutes). By default guix
> tries to do
> ERROR: In procedure %resolve-variable:
> ERROR: Unbound variable: %intel-compatible-systems
My bad, this has been fixed by Efraim in
d8f075c3a3daba93ff4420bbe0b1833712aaa0e9.
You may want to guix pull again !
Sorry,
Mathieu
Hello,
Op 09 nov 20:27 schreef Marco van Hulten:
> Right now I'm updating packages, and things are looking up.
Well... concerning the root user. As the manual states that one needs
to do a `guix pull' for any user for whom you want to upgrade the
packages, I did that here, but it failed:
```
ko
Ludo'-
Op 09 nov 14:19 schreef Ludovic Courtès:
> How many CPUs and how much RAM does this machine have? Does it help in
> any way to run “guix pull --cores=2”, thereby limiting CPU usage to two
> cores?
I have two processors, so I tried to run it on one, and it worked:
```
root@watson ~# time
Hi,
Marco van Hulten skribis:
> The following derivations will be built:
>/gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv
>/gnu/store/6gxf5snkl5him1iqg6aqmpyn5ggijhx5-module-import-compiled.drv
>/gnu/store/fxnbl74nxjzzm44f1j25glsb3gav4k6b-module-import.drv
> substitute: u
Ludo'-
Minor additional info below.
Op 08 nov 02:37 schreef Marco van Hulten:
> Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.
I tried with this suggestion, and actually got less information with
this (no "failed to expand heap
Ludovic-
This is the second time I tried a `guix pull':
```
root@watson ~# time guix pull
Starting download of /tmp/guix-file.x2AvJM
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
….tar.gz 2.3MiB/s 00:06 | 13.8MiB transferred
unpackin
Ludovic-
Op 07 nov 10:20 schreef Ludovic Courtès:
> Marco van Hulten skribis:
>
> > root@watson ~# guix pull
> >
> > Starting download of /tmp/guix-file.F5p3in
> > From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
> > ….tar.gz 2.3MiB/s 0
Hi Marco,
Marco van Hulten skribis:
> root@watson ~# guix pull
>
> Starting download of /tmp/guix-file.F5p3in
> From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
> ….tar.gz 2.3MiB/s 00:06 | 13.8MiB
> transferred
> unpacking '/gnu/store/
Hello,
Thank you Carl and Thomas for the clear explanation.
Still one issue remains.
Op 06 nov 20:43 schreef Carlo Zancanaro:
> > 'guix pull' ends with a compilation error:
> >
> >> guix pull: error: build failed: build of
> >> `/gnu/store/*-guix-latest.drv' failed
>
> This isn't enough to
Hello!
On Mon, Nov 06 2017, Marco van Hulten wrote:
> I installed GuixSD 0.13.0 with success!
Excellent! That's great to hear!
> 'guix pull' ends with a compilation error:
>
>> guix pull: error: build failed: build of
>> `/gnu/store/*-guix-latest.drv' failed
This isn't enough to tell me what's
Hello, sadly I can't help with the guix pull error, don't know a lot
about it unfortunately. I do have some comments on the other questions.
On Mon, 06 Nov 2017 09:16:56 +0100
Marco van Hulten wrote:
> After this I should execute this command.
>
> > $ guix system reconfigure
> > guix system: er
Hello,
I installed GuixSD 0.13.0 with success! But I still have a couple
of issues and questions concerning updating the system and installing
packages. I followed the [installation guide][1].
[1]:
https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html
'guix
27 matches
Mail list logo
