unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: David Lecompte via <help-guix@gnu.org>
To: Matthew Brooks <matthewfbrooks@mailbox.org>,
	"help-guix@gnu.org" <help-guix@gnu.org>
Subject: Re: Avoiding rebuilds (e.g. of mariadb, the entire Rust chain, etc.)?
Date: Mon, 27 Dec 2021 09:23:56 +0000	[thread overview]
Message-ID: <dbb56f28f6fb3a01365b686ffe384b28db1afd12.camel@metani.info> (raw)
In-Reply-To: <20211226234130.5ad3d9f2@mailbox.org>


[-- Attachment #1.1: Type: text/plain, Size: 1897 bytes --]

Le dimanche 26 décembre 2021 à 23:41 -0600, Matthew Brooks a écrit :
> Is there any way to avoid rebuilding stuff like mariadb, the entire
> Rust chain, etc. unless one of those packages *actually* changes? It
> seems like every few days every single package needs to rebuild for
> some reason, including many packages that spend unbelievably long
> times running tests that will never actually be of use to me, so I'm
> usually only able to update every couple of weeks since so much
> constantly needs to be rebuilt and everything takes so long.
> 

I don't have a solution, just similar experience but with a different
setup.

I use Guix on Trisquel on my X200, I have substitues enabled, my
installed packages are glibc-locales, fontconfig, font-adobe-source-
han-sans, gajim, gajim-omemo, gajim-openpgp, nheko, syncthing,
darktable,  and ungoogled-chromium.

Often, "guix pull" and "guix package update" take between 1h and 2h.
This is not due to the download time. Apparently, even with substitues,
some CPU-heavy work is needed.

> It seems to have gotten worse over time as well, as more and more
> base packages pull in extremely computation-hungry dependency chains.
> At this very moment, for example, I'm waiting for Rust & co. to
> compile simply to delete old system generations from the bootloader.
> 

I started "guix package -u" about 40h ago, it has been on ungoogled-
chromium-96.0.4664.110-1.drv for more than 30h now and it is not
finished.

For a long time, both cores of the CPU have been at 100% load. Now, it
is much lower and I see a lot of disk activity but still working.
During the whole time, I have almost not used the computer at all.

I will have to travel in two hours and I need to switch my laptop off
first. If the update is not finished, I will stop the process. I guess
I will remove ungoogled chromium as well.


[-- Attachment #1.2: publickey - david.lecompte@metani.info - 292b3e27.asc --]
[-- Type: application/pgp-keys, Size: 3212 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 855 bytes --]

  reply	other threads:[~2021-12-27  9:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27  5:41 Avoiding rebuilds (e.g. of mariadb, the entire Rust chain, etc.)? Matthew Brooks
2021-12-27  9:23 ` David Lecompte via [this message]
2021-12-29  9:12   ` zimoun
2022-01-02 17:36     ` David Lecompte
2022-01-03 16:42       ` zimoun
2021-12-28  0:13 ` Leo Famulari
2021-12-29  9:26 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dbb56f28f6fb3a01365b686ffe384b28db1afd12.camel@metani.info \
    --to=help-guix@gnu.org \
    --cc=david.lecompte@metani.info \
    --cc=matthewfbrooks@mailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).