GNU bug report logs - #60879
`guix pull` profile reproducibility issues

Previous Next

To reply to this bug, email your comments to 60879 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars-Dominik Braun <ldb <at> leibniz-psychology.org>
To: bug-guix <at> gnu.org
Subject: `guix pull` profile reproducibility issues
Date: Tue, 17 Jan 2023 14:24:51 +0100

Hi,

here at ZPID we “cache” Guix pull profiles (via `guix pull -p`) in project
directories, which can be shared between users. I’ve been trying to
ensure that a given Guix pull profile corresponds to a given channels.scm
file, i.e. it has not been tampered with, because calls to the Guix binary
currently run outside of the project sandbox (`guix shell -C`). Doing
so I discovered two reproducibility issues:

1) `guix pull` and `guix time-machine` currently do not produce the same
   Guix profile, even with exactly the same channels.scm
   file. Unfortunately time-machine does not print the profile path
   anywhere, but this can be reproduced implicitly by looking at the
   output of cached-channel-instance, which the time-machine uses. Looking
   at `guix describe` vs `guix time-machine -C channels.scm -- describe`
   reveals a reversed channel order. Thus channel order matters when
   using a channels.scm, when it really should not.
2) `guix pull` seems to depend on the host `guix` and produces
   different profile paths depending on which `guix` command
   was used to pull. In the following example `guix` is at commit
   f094c3831f382b7299a2aaa04d85f4b27320e9ec and we’re pulling commit
   5fd9d3ba82faddf8393027655d4a10a1562dac47 through the attached
   channels.scm. These commits were selected carefully, because the
   problem is more likely for older commits pulled from newer commits.

   $ guix pull -C channels.scm -p guix-level1
   $ ./guix-level1/bin/guix pull -C channels.scm -p guix-level2
   $ readlink -f guix-level1
   /gnu/store/3fr7rlx9hm29a5c0mh0lnxpqg8prfvw7-profile
   $ readlink -f guix-level2
   /gnu/store/4gyv6m8v47f6wpmrq86iy6wgvivm2sh8-profile
   $ diffoscope guix-level1 guix-level2
   […]
   │ │   --- guix-level1/etc/profile
   │ ├── +++ guix-level2/etc/profile
   │ │ @@ -4,8 +4,8 @@
   │ │  #
   │ │  #  GUIX_PROFILE=/path/to/profile ; \
   │ │  #  source /path/to/profile/etc/profile
   │ │  #
   │ │  # When GUIX_PROFILE is undefined, the various environment variables refer
   │ │  # to this specific profile generation.
   │ │
   │ │ +export PATH="${GUIX_PROFILE:-/gnu/store/4gyv6m8v47f6wpmrq86iy6wgvivm2sh8-profile}/bin${PATH:+:}$PATH"
   │ │ -export PATH="${GUIX_PROFILE:-/gnu/store/3fr7rlx9hm29a5c0mh0lnxpqg8prfvw7-profile}/bin${PATH:+:}$PATH"
  
   The only visible difference is the adjusted PATH, which means there
   actually is no difference. Pulling again from level2 results in the
   same profile as level2, so clearly something is leaking from our
   original `guix` into level1. The .drv files for both reveal that
   fonts-dir.drv is different, because mkfontdir and mkfontscale
   differ. These are part of the profile generation code, which apparently
   comes from the host Guix, when the newly built Guix should be used.

Cheers,
Lars

-- 
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate

www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.