Hi Ian, Ian Eure <i...@retrospec.tv> writes:
> Ran into this issue last week. If you: > > - Configure some offload build machines in your operating-system > configuration. > - Reconfigure your system. > - Remove all offload build machines. > - Reconfigure your system again. > > ...then various guix operations will still try to connect to offload > machines, even if you reboot the affected client. > > This is caused by a bug in the `guix-activation' procedure: > > ;; ... and /etc/guix/machines.scm. > #$(if (null? (guix-configuration-build-machines config)) > #~#f > (guix-machines-files-installation > #~(list #$@(guix-configuration-build-machines > config)))) > > If there are no build machines defined in the configuration, no > operation is performed (#f is returned), which leaves the previous > generation’s /etc/guix/machines.scm in place. > > The same issue appears to affect channels: > > ;; ... and /etc/guix/channels.scm... > #$(and channels (install-channels-file channels)) Interesting! > I’d be happy to take a stab at fixing this, but I’m not certain what > direction to go, or how much to refactor to get there. Should the > channels/machines files be removed (ignoring errors if they don’t > exist)? Should empty files be installed? Should that happen inline > in `guix-activation', or in another procedure? Should the filenames be > extracted to %variables to avoid duplicating between the two places > they’ll be used? > > If someone would like to provide answered, I would contribute a patch. I guess the simplest would be to attempt to remove the files when there are no offload machines or channels, in this already existing activation procedure. Extracting the file names to %variables sounds preferable yes, if there's a logical place to store them that is easily shared. A patch would be dandy! -- Thanks, Maxim
