GNU bug report logs - #53208
[PATCH]: gnu: rust-analyzer: Update to 2020-01-10.

Previous Next

Full log

View this message in rfc822 format

From: Leo Famulari <leo <at> famulari.name>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 53208 <at> debbugs.gnu.org
Subject: [bug#53208] [PATCH 38/39] gnu: rust-analyzer: Update to 2022-01-10.
Date: Sun, 23 Jan 2022 13:53:56 -0500

On Sun, Jan 23, 2022 at 09:35:10AM +0100, Nicolas Goaziou wrote:
> As you may guess, I know this part (which IMO could be refreshed as the
> capacity of the build farm and the number of Guix packages evolved since
> 2016) of the manual.

I agree about refreshing the guidelines, although I'm waiting until
after the 1.4.0 release to start a discussion about it. Think about
ideas for improving the workflow!

> What I do not know, however, is how to predict the number of rebuilds
> when it comes to Rust packages. Do you have an idea?

It's tough, indeed.

Maybe something like `./pre-inst-env guix build --no-grafts gnome
--dry-run` can reliably give a good answer.

GNOME does depend on Rust packages, in at least two ways: via librsvg
and via rav1e.

------
$ guix graph --path gnome rav1e
gnome <at> 41.0    
tracker-miners <at> 3.1.2
ffmpeg <at> 4.4.1
rav1e <at> 0.5.1
$ guix graph --path gnome librsvg
gnome <at> 41.0    
gnome-control-center <at> 41.2
librsvg <at> 2.50.7
------

And anyways, it's good practice to make sure that GNOME builds after
changing big parts of the dependency graph.

If it's too computationally expensive for you to perform builds like
that, let us know maybe we can provide a solution via ci.guix.gnu.org

Previous Next

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