poor information when updating using “guix time-machine”

  • Open
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Simon Tournier
Owner
unassigned
Submitted by
Simon Tournier
Severity
normal
S
S
Simon Tournier wrote on 6 Sep 2023 18:57
poor information when updating using “guix time -machine”
(address . bug-guix@gnu.org)
87pm2vme7x.fsf@gmail.com
Hi,

Tangential of bug#65787 [1], the annoyance is the order of the updates.
It leads to poor messages. Let exemplify at the extreme case.

Toggle snippet (18 lines)
$ guix describe
Generation 28 sept. 06 2023 14:54:50 (current)
guix 6113e05
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 6113e0529d61df7425f64e30a6bf77f7cfdfe5a5

$ rm -fr ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq

$ 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'... \

The reason is because the logic:

(when (procedure? validate-channels)
(validate-channels channels))
(run-with-store store
(mlet* %store-monad ((instances
-> (latest-channel-instances store channels
#:authenticate?
authenticate?))

where ’validate-channels’ (validate-guix-channel) reads,

(checkout commit relation (update-cached-checkout
(channel-url guix-channel)
#:ref reference
#:starting-commit
%oldest-possible-commit)))

and ’latest-channel-instances’ which is the ones that displays,

(format (current-error-port)
(G_ "Updating channel '~a' from Git repository at '~a'...~%")
(channel-name channel)
(channel-url channel))


this ’latest-channel-instances’ reads under the hood,

((checkout commit relation)
(update-cached-checkout (channel-url channel)
#:ref (channel-reference channel)
#:starting-commit starting-commit)))


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.

WDYT?

Cheers,
simon


L
L
Ludovic Courtès wrote on 28 Oct 2023 16:16
Re: bug#65788: poor information when updating using “guix time-machine”
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
875y2q96hz.fsf@gnu.org
Hi,

(Cc: Maxim.)

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

Toggle quote (9 lines)
> $ 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?

Toggle quote (6 lines)
> 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:


Ludo’.

PS: We should define rules for “Reviewed-by” tags because I don’t think
I LGTM’d commit 79ec651a286c71a3d4c72be33a1f80e76a560031 (?).
M
M
Maxim Cournoyer wrote on 31 Oct 2023 15:55
(name . Ludovic Courtès)(address . ludo@gnu.org)
87bkcesux1.fsf@gmail.com
Hi,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

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

It was a friendly credit added based on substantial comments I received
and acted upon from your review,

I don't mind if we codify to add these only when the reviewer added
their 'LGTM' approval stamp; there's an ongoing change adding some
guidelines for reviews in bug#66436, we should add this bit in.

--
Thanks,
Maxim
S
S
Simon Tournier wrote on 19 Dec 2023 15:36
(name . Ludovic Courtès)(address . ludo@gnu.org)
87h6ke45to.fsf@gmail.com
Hi Ludo,

On Sat, 28 Oct 2023 at 16:16, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (12 lines)
>> 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’.

[...]

Toggle quote (4 lines)
> Here’s my proposal to do that:
>
> https://issues.guix.gnu.org/66793

This improvement does not address this issue with
%oldest-possible-commit, right?

In addition, we also need to consider ’inferior-for-channels’ which
calls ’cached-channel-instance’ – currently with the default (const #t)
for #:validate-channels.

For an instance of bug with inferiors, please look at:

Dependence on an old version of a package.
Philippe Veber <philippe.veber@gmail.com>
Sun, 10 Dec 2023 09:18:50 +0100
id:CAOOOohRJu0QH+czx3qAwNxCY0X9JBd4NdUd9vjBvt-kDFCHkmA@mail.gmail.com


Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 65788@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 65788
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch