guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#43494] [PATCH 2/4] services: guix: Add guix-build-coordinator-servi


From: Christopher Baines
Subject: [bug#43494] [PATCH 2/4] services: guix: Add guix-build-coordinator-service-type.
Date: Sat, 26 Sep 2020 09:43:31 +0100
User-agent: mu4e 1.4.13; emacs 26.3

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

> Hi!
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>>> +  (program-file
>>>> +   "start-guix-build-coordinator"
>>>> +   (with-extensions (cons guix-build-coordinator-package
>>>> +                          ;; This is a poorly constructed Guile load path,
>>>> +                          ;; since it contains things that aren't Guile
>>>> +                          ;; libraries, but it means that the Guile 
>>>> libraries
>>>> +                          ;; needed for the Guix Build Coordinator don't 
>>>> need
>>>> +                          ;; to be individually specified here.
>>>> +                          (map second (package-inputs
>>>> +                                       guix-build-coordinator-package)))
>>>
>>> Perhaps there should eventually be a ‘guix-build-coordinator’ command in
>>> the package itself?
>>
>> There actually is, one thing I've had in mind for a while now though is
>> to use a scheme script constructed by the Guix service to run the
>> coordinator.
>>
>> For guix.cbaines.net, I'm using the script, but with the hooks passed in
>> on the command line, the command is rather long, and it means that
>> backtraces don't work well with the hooks.
>
> You mean because the hooks are interpreted, and so all you see in the
> backtrace is a bunch of ‘eval’ calls?

Yeah, I haven't done much testing of this, but that's my assumption.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]