all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Bone Baboon <bone.baboon@disroot.org>
Cc: 48024@debbugs.gnu.org
Subject: bug#48024: glib-2.62.6 build fails i686
Date: Thu, 06 May 2021 04:46:10 -0400	[thread overview]
Message-ID: <877dkcmeqa.fsf@netris.org> (raw)
In-Reply-To: <87y2cti1gp.fsf@disroot.org>

Hi,

Bone Baboon <bone.baboon@disroot.org> writes:

> Thank you for sharing this.  Also thank you for the warning about
> 'significant caveats and "rough edges"'.

The "rough edges" could surely be smoothed out with some effort.  I
haven't been motivated to work on it, partly because until recently,
I've felt quite alone in my preference for using Guix in this way.
However, you are now the second person to express interest in this in
the last couple of months.

> As a new user of Guix I think I will initially try to use the official
> Guix repository.

That's probably best for now, at least until you have a compelling
reason to do otherwise.

> However the message from Tobias Geerinckx-Rice in
> https://issues.guix.gnu.org/48213 gives me the idea that your flexible
> approach could be very useful if I find myself in a situation where I
> have an issue that will not be addressed by an upstream project and
> that has too much of a maintenance burden for Guix maintainers to take
> on.

Yes, it enables one to exercise an extraordinary amount of individual
control over one's system, while still benefitting from the work of the
larger Guix community.  Several of the commits on my private branch are
reversions of upstream changes in Guix that I disagreed with.

One more important note: regardless of whether you run Guix from a git
checkout or use the official 'master' branch, if you build everything
locally, then it's important to pass "--gc-keep-derivations=yes" and
"--gc-keep-outputs=yes" to the Guix daemon.

Those flags change the way the Guix garbage collector operates, such
that more store items are retained.  I've forgotten the precise details,
but roughly, these flags cause not only the run-time requirements of the
currently-installed software to be retained, but also the *build*
requirements of that software.  Without these flags, "guix gc" will
delete far too much, and you'll likely end up having to rebuild a great
many packages that are needed at build time only.

I have something close to this in the 'services' field of my OS config:

--8<---------------cut here---------------start------------->8---
  (modify-services %desktop-services
    (guix-service-type config =>
                       (guix-configuration
                         (inherit config)
                         (use-substitutes? #f)
                         (authorize-key?   #f)
                         (authorized-keys '())
                         (substitute-urls '())
                         (extra-options '("--gc-keep-derivations=yes"
                                          "--gc-keep-outputs=yes")))))
--8<---------------cut here---------------end--------------->8---

    Regards,
      Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.




  reply	other threads:[~2021-05-06  8:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-26  3:35 bug#48024: glib-2.62.6 build fails i686 Bone Baboon via Bug reports for GNU Guix
2021-04-26 15:26 ` raingloom
2021-04-27 19:25   ` Bone Baboon via Bug reports for GNU Guix
2021-04-28  3:23     ` Mark H Weaver
2021-05-03 22:00       ` Bone Baboon via Bug reports for GNU Guix
2021-05-04  0:38         ` Leo Famulari
2021-05-04  3:01         ` Mark H Weaver
2021-05-04  6:18           ` Efraim Flashner
2021-05-04 20:01             ` Mark H Weaver
2021-05-04 20:08               ` Mark H Weaver
2021-05-04 22:52               ` Bone Baboon via Bug reports for GNU Guix
2021-05-05  8:38               ` Efraim Flashner
2021-05-05 21:15                 ` Bone Baboon via Bug reports for GNU Guix
2021-05-06  0:20                   ` Mark H Weaver
2021-05-06  0:35                     ` Bone Baboon via Bug reports for GNU Guix
2021-05-06  6:45                   ` Efraim Flashner
2021-05-06  9:06                     ` Bengt Richter
2021-05-06 17:44                     ` Bone Baboon via Bug reports for GNU Guix
2021-05-07 17:46                       ` Mark H Weaver
2021-05-08 13:26                         ` Bengt Richter
2022-03-18  2:26                     ` Maxim Cournoyer
2021-05-04  3:56         ` Mark H Weaver
2021-05-05 16:34           ` Bone Baboon via Bug reports for GNU Guix
2021-05-06  8:46             ` Mark H Weaver [this message]
2021-05-06 19:36               ` Bone Baboon via Bug reports for GNU Guix

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

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

  git send-email \
    --in-reply-to=877dkcmeqa.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=48024@debbugs.gnu.org \
    --cc=bone.baboon@disroot.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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.