Hello, Lars-Dominik Braun <l...@leibniz-psychology.org> skribis:
>> This is a limitation in ‘build-aux/build-self.scm’: […] > I don’t understand what’s going on there unfortunately. Is there a high-level > explanation somewhere in the manual? > >> We could work around it by letting the ‘GUIX_DAEMON_SOCKET’ environment >> variable through, along these lines: > Nope, that does not seem to be enough. After pulling on master doing the same > on a node (with a patched guix) yields: > > ---snip--- > ice-9/eval.scm:293:34: Throw to key `srfi-34' with args `(#<condition > &store-connection-error [file: "ssh://master.<domain>" errno: 95] > 7f0f325f77b0>)'. > ---snap--- > > Any ideas? Sounds like this ssh URI is not valid on the nodes, is that right? >> + (when (and (not (file-port? port) daemon-socket)) > (when (and (not (file-port? port)) daemon-socket) > I assume: ↑ > >> […] and won’t work with old Guix revisions anyway. > That means `guix time-machine` could not go back beyond a commit that fixes > the > issue, correct? Not a concern for me. Correct. >> However, for your use case, you could perhaps simply pull on one machine >> and use ‘guix copy’ to send Guix elsewhere? > The store is the same on all machines, since /gnu/store, /var/guix and /home > are all shared via NFS. As far as I understand the manual `guix copy` would be > useful for store to store transfers on different machines only. Right. So perhaps I don’t quite understand the use case. What about simply pulling from one of these machines, if everything is shared over NFS? HTH, Ludo’.