GNU bug report logs - #41182
Profile hooks ignore system and target

Previous Next

Package: guix;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Sun, 10 May 2020 20:40:01 UTC

Severity: important

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 41182 <at> debbugs.gnu.org, Mathieu Othacehe <m.othacehe <at> gmail.com>
Subject: bug#41182: Profile hooks ignore system and target
Date: Wed, 13 May 2020 11:45:55 +0200
Ludovic Courtès writes:

Hello!

> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> Actually all the profile hooks refer to the native derivation.
>
> I’ve looked at it and this problem is surprisingly tricky to address.

Thank you so much for looking into this!

> I’ve tried to address it in an API-compatible way, which meant setting
> the ‘%current-system’ and ‘%current-target-system’ parameters around the
> hook calls, but that is ugly, hard to get right (dynamic binding and
> monadic code really don’t go together well :-/), and actually raises
> another issue (‘mapm/accumulate-builds’ appears to ignore the initial
> dynamic bindings for these two parameters).  Hacky patch attached to
> illustrate.
>
> So I’m very much tempted to instead require each hook to take ‘system’
> and ‘#:target’ arguments and pass them to ‘gexp->derivation’.  It’ll
> break the API, in case someone out there has custom profile hooks
> (unlikely given that it’s not really documented), but I’d say that’s OK.
>
> Thoughts?

I'm all for breaking the API if that gets us further.  How about doing
that on the wip-hurd-vm branch, complete building the vm-image with
services and when we have found this (and possible next steps) are
useful fixes, commit to core-updates?

It would be useful to get substitutes for such a change, though --
testing this took all night.

Other than that I can offer my observations trying to build a kind of
minimal Hurd system using

    fb120a69a8 services: hurd: Use activation-service, hurd-etc-service.

both

    ./pre-inst-env guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl
    ./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

still want to build a native Hurd (in my case for x86_64).

So, I tried applying what your patch seems to be suggesting:

--8<---------------cut here---------------start------------->8---
diff --git a/guix/store.scm b/guix/store.scm
index 92158bd658..b27ad0fab3 100644
--- a/guix/store.scm
+++ b/guix/store.scm
@@ -1900,8 +1900,8 @@ coalesce them into a single call."
                                    (lambda (obj)
                                      (run-with-store store
                                        (mproc obj)
-                                       ;; #:system (%current-system)
-                                       ;; #:target (%current-target-system)
+                                       #:system (%current-system)
+                                       #:target (%current-target-system)
                                        ))
                                    lst)
             store)))
--8<---------------cut here---------------end--------------->8---

and with that "system build" succeeds (after a while) but "system vm-image" says

    guix system: error: gnu/packages/glib.scm:404:2: gobject-introspection <at> 1.62.0: build system `meson' does not support cross builds

This could be mostly harmless...still building a full (non-tiny/minimal)
qemu or grub maybe?

Greetings
janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




This bug report was last modified 5 years and 9 days ago.

Previous Next


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