GNU bug report logs - #65788
poor information when updating using “guix time-machine”

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: 65788 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: bug#65788: poor information when updating using “guix time-machine”
Date: Sat, 28 Oct 2023 16:16:56 +0200

Hi,

(Cc: Maxim.)

Simon Tournier <zimon.toutoune <at> gmail.com> skribis:

> $ guix time-machine -q --commit=6113e05 -- describe
> receiving objects   2% ▕█▋
>     …some time flies…
> indexing objects  21% ▕███████████████████████                                                                                       ▏
>     …some time flies…
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
>    …instant…
> Computing Guix derivation for 'x86_64-linux'... \

To be clear, the problem you see is that “Updating channel” is printed
too late, after “receiving objects” etc., right?

> Why not move this ’validate-guix-channel’ to internals.  Somehow, it is
> in guix/scripts/ because it captures ’ref’.  However, this capture is
> redundant and is normally managed by ’channel-list’.  Therefore, I would
> be tempted to have this validation for the reachable commit close to the
> “Updating” message.

Yes, that’s a good idea.

As I started looking into it, I realized we could reuse the existing
#:validate-pull mechanism of ‘latest-channel-instances’ for the purposes
of this commit check in ‘time-machine’.

The main advantage is that this would address a performance issue with
the implementation of ‘validate-guix-channel’ in commit
79ec651a286c71a3d4c72be33a1f80e76a560031, namely the fact that it opens
and traverses the repository one extra time for this check.  (The
#:validate-pull mechanism is integrated with ‘latest-channel-instances’
precisely to avoid this cost.)

Here’s my proposal to do that:

  https://issues.guix.gnu.org/66793

Ludo’.

PS: We should define rules for “Reviewed-by” tags because I don’t think
    I LGTM’d commit 79ec651a286c71a3d4c72be33a1f80e76a560031 (?).

Previous Next

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