bug#22883: Trustable "guix pull"

On Sun, 5 Jun 2016 00:27, l...@gnu.org said: > cannot or shouldn’t try to guess what’s “best”, IMO. So in this case, > we keep the default names, ‘gpg2’ and ‘gpgv2’. > > Do you think we should rename those files? Given that Guix is a new distro you should really try to get rid of 1.4 and only u

bug#23697: guix system reconfigure hangs, shows repl in messages

Hi, Not sure this qualifies as a bug, sending per request. As a preparation to move from Debian to GuixSD, I have been dual booting between Debian and GuixSD. Using Debian as my main system with this layout /dev/sda3 "debian" / /dev/sda1 /guix /dev/sda4 /home I di

bug#22883: Authenticating a Git checkout

Ludovic Courtès writes: >>> Second, even if it did, it would be a shallow check: as Mike notes in >>> with the ‘signchk’ >>> script, you actually have to traverse the whole commit history and >>> authenticate them one by one. But that’s OK, it run

bug#23666: guix download fails for large files

Thanks for your suggestions, Leo and Ludovic! I still see this as a bug; should I report it upstream to Nix? On Wed, Jun 01, 2016 at 02:39:54PM +0200, Ludovic Courtès wrote: > This is implemented using the ‘add-to-store’ RPC, which, after all these > years, is still implemented like this (nix/libs

bug#22883: Authenticating a Git checkout

On Sun, Jun 05, 2016 at 03:39:04PM -0500, Christopher Allan Webber wrote: > One theoretical optimization: if I verify the DAG, could I store > somewhere that I've verified from commit cabba6e and upward already, so > the next time I verify it only has to verify the new commits? AIUI `git verify-co

bug#22883: Authenticating a Git checkout

On Sun, Jun 05, 2016 at 15:39:04 -0500, Christopher Allan Webber wrote: > One theoretical optimization: if I verify the DAG, could I store > somewhere that I've verified from commit cabba6e and upward already, so > the next time I verify it only has to verify the new commits? tbh, I haven't given