From: Diego Nicola Barbato <dnbarbato@posteo.de>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 31085@debbugs.gnu.org
Subject: bug#31085: Unexpected behaviour when running `guix build lilypond'
Date: Fri, 20 Apr 2018 23:20:01 +0200 [thread overview]
Message-ID: <87tvs5tw1q.fsf@GlaDOS.home> (raw)
In-Reply-To: <87muxzi4v4.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 19 Apr 2018 17:38:07 +0200")
Hello
ludo@gnu.org (Ludovic Courtès) writes:
> Hello,
>
> Diego Nicola Barbato <dnbarbato@posteo.de> skribis:
>
>> I have experienced some unexpected behaviour when running `guix build
>> lilypond':
>> After verifying that there was a substitute available with `guix weather
>> -m m.scm' (Where m.scm evaluates to a manifest containing only lilypond)
>> I ran `guix build lilypond --dry-run' which claimed that a substitute
>> would be downloaded. I then ran `guix build lilypond' which proceeded
>> to build lilypond from source (instead of downloading the substitute).
>>
>> Upon explaining this on IRC it was suggested that I try running `guix
>> build --no-grafts lilypond' (which actually downloaded the substitute)
>> then deleting the locally built lilypond with `guix gc --delete
>> /gnu/store/...' and finally running `guix build lilypond' again (which,
>> this time, grafted the substituted lilypond instead of building it from
>> source again). While this fixed the issue I was told that this
>> behaviour was indeed unexpected.
>
> We’d have to see if this is still reproducible, but I have a plausible
> explanation.
I can consistently reproduce this in a VM with the following steps:
First I run:
$ qemu-system-x86_64 -enable-kvm -snapshot -m 4G $(guix system vm-image bare-bones.scm --image-size=8G)
(Where bare-bones.scm is the bare-bones.tmpl after replacing /dev/sdX
with /dev/sda.)
Then after logging in as root:
# guix pull --commit=872bda5de52a8f0514230ebc4e9680aab74f509a
# guix build --dry-run lilypond
Which returns:
52.1 MB would be downloaded:
/gnu/store/0amx7bcbs518lkqwfh2azmqrp2yqib0g-lilypond-2.19.80
/gnu/store/7b5ykfl6jbrdl8j7xp630fga4as3234z-ghostscript-9.22
/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14
/gnu/store/k2ak44m0miind785x22mmpbcwi0mq7hq-freetype-2.8.1
/gnu/store/mkhfqx7m7pniyic0kh0lnafmajymn4dr-guile-1.8.8
/gnu/store/pwbx5fhjrq9crr1c0d2x08ch0l6vr3cv-pango-1.40.14
/gnu/store/qm8ri32n0rkh749v3jb3x8s8ksjl7yd3-fontconfig-2.12.6
/gnu/store/sm37m59gq3smxxz8gs4jikn50qg0g7xh-glib-2.54.2
Then:
# guix build lilypond
Which, after downloading the dependencies, starts to build lilypond from
source.
> Substitute info is cached locally. guix-daemon caches it under
> /var/guix/substitute/cache, but ‘guix weather’ caches it under
> ~/.cache/guix/substitute (that’s because it needs fine-grain control
> over substitute info and thus cannot simply use the
> ‘substitutable-path-info’ daemon RPC.) Each cached entry has a
> time-to-live (TTL).
>
> What could have happened is that /var/guix/substitute/ had a
> not-expired-yet entry saying that there’s no substitute for LilyPond
> (which is why ‘guix build’ ended up building from source), whereas ‘guix
> weather’ was run at a point when there was a substitute.
The unexpected behaviour was that `guix build lilypond' started to build
lilypond from source after `guix build --dry-run lilypond' had claimed
that nothing would be built and that it would download a substitute. I
assume that `guix build --dry-run' is not affected by the substitute
info used by `guix weather'. I only ran `guix weather' in order to
double check that there were indeed substitutes available (Sorry for the
red herring).
Greetings
Diego
next prev parent reply other threads:[~2018-04-20 21:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-06 20:22 bug#31085: Unexpected behaviour when running `guix build lilypond' Diego Nicola Barbato
2018-04-19 15:38 ` Ludovic Courtès
2018-04-20 21:20 ` Diego Nicola Barbato [this message]
2018-04-23 13:26 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tvs5tw1q.fsf@GlaDOS.home \
--to=dnbarbato@posteo.de \
--cc=31085@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).