bug#31294: Failed building dependencies for guix.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> It confirms that the bad code creates a  structure with the empty
>> list as its ‘modules’ field instead of '((guix build utils)).
>>
>> That’s clearly a Guile bug.
>
> This miscompilation issue involves “syntax parameters” (because
> ‘with-imported-modules’ uses a syntax parameter), and it very likely has
> to do with the thread-safety issue I describe here:
> .

I just got this on my Fedora workstation in the office, where I use Guix
from a git checkout.  I worked around this by moving “guix/profiles.go”
out of the way.

(Some people seem to be getting this with just “guix pull” now.)

--
Ricardo

bug#33968: errors in shepherd service constructors are not logged and lead to misleading status

[Florian Dold]

Hi Guix,

when defining a service type that extends shepherd-root-service-type and
the 'start' function of the shepherd-service definition contains an
error, the error is silently ignored.  No log output is generated at all.

For example (full system definition is attached):

(define (errtest-shepherd-service c)
  (list
(shepherd-service
  (provision '(errtest))
  (documentation "Errtest")
  (requirement '(file-systems))
  (modules `((shepherd support) (ice-9 match) ,@%default-modules))
  (start #~(lambda args
 (local-output "errtest start")
 this-is-an-unbound-variable
 (local-output "errtest end")
 #t)


The log message "errtest start" appears in /var/log/messages, as
expected.  The next line contains an error, and aborts execution of the
start function.

The error only becomes apparent when manually doing a "herd restart
errtest", which shows an error message (but without any error location
or stack trace).  But the error (regarding the unbound variable) is not
logged, and there is no indication in the log that the service couldn't
be started in any log.

Furthermore the "herd status" of a service that encountered an error in
the start function is very misleading:

root@errtest ~# herd status errtest
Status of errtest:
  It is stopped.
  It is enabled.
  Provides (errtest).
  Requires (file-systems).
  Conflicts with ().
  Will be respawned.


It shows "Will be respawned", which is wrong.

I'd be happy to work on a patch, but it seems like there is some design
discussion necessary, in particular how the "Will be respawned" should
be handled.  Services have a "respawn?" flag, but of course respawning
can only work if the start function executed successfully (and only the
service process itself failed) in the first place.

I generally feel like the state machine for services needs some work.
In particular, it would be useful to distinguish between "failed" and
"completed" services instead of conflating both states into "stopped".
Or maybe have some more general mechanism for storing state about the
service, instead of just the slot that usually contains the PID?

- Florian
(use-modules (gnu))
(use-service-modules networking ssh shepherd)

(define (errtest-shepherd-service c)
  (list
(shepherd-service
  (provision '(errtest))
  (documentation "Errtest")
  (requirement '(file-systems))
  (modules `((shepherd support) (ice-9 match) ,@%default-modules))
  (start #~(lambda args
		 (local-output "errtest start")
		 this-is-an-unbound-variable
		 (local-output "errtest end")
		 #t)

(define errtest-service-type
  (service-type
   (name 'errtest)
   (extensions
(list (service-extension shepherd-root-service-type errtest-shepherd-service)))
   (default-value #t)))

(operating-system
  (host-name "errtest")
  (timezone "Europe/Berlin")
  (locale "en_US.utf8")
  (kernel-arguments (list "console=ttyS0" "console=tty0"))
  (bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sdX")))
  (file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))

  (services (cons* (service errtest-service-type)
   %base-services)))

bug#33932: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1.

[swedebugia]

On 2019-01-03 20:19, Christopher Baines wrote:


swedebugia  writes:


On 2019-01-02 22:50, swedebugia wrote:

On 2018-12-31 13:33, Ricardo Wurmus wrote:


Hi swedebugia,


We should upgrade.


Could you please send a patch?



Here it is :)


I haven't looked too closely at the patch, but I think the newer version
of Artanis have bundled guile-redis (or something like that), so it
would be good to look at unbundling it, similar to how guile-json is
handled.



Thanks for the review. :)

Correct. Redis is bundled an I did not unbundle it. Even guile-csv is 
bundled, but we have not packaged it yet.


I will try unbundling and send a new patch.

--
Cheers Swedebugia

bug#33962: guix pull fails on latest master

[Leo Famulari]

On Fri, Jan 04, 2019 at 01:24:22AM +1100, Brendan Tildesley wrote:
> 95bf2fb637ba4abb27efe94e0b671c1e93204e4f , which adds wl-clipboard fails
> to build because it references meson-build-system without importing the
> required module. I'm guessing adding  #:use-module (guix build-system
> meson)   ; would fix it.
> 
> I'm curious to know how this error was made.

My guess is that the code contribution was tested with the
meson-build-system module imported correctly. However, the actual commit
or patch was created without the module import line.

When reviewing patches just by reading them, it's easy to miss mistakes
like this one.

This should be fixed in commit 4382cef28cb6de4b2b505788b759b0fe4f8ea603

Thanks for the reports!


signature.asc
Description: PGP signature

bug#33932: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1. (was: Re: bug#33932: Artanis fails to build - 0.3.1 is out)

[Christopher Baines]

swedebugia  writes:

> On 2019-01-02 22:50, swedebugia wrote:
>> On 2018-12-31 13:33, Ricardo Wurmus wrote:
>>>
>>> Hi swedebugia,
>>>
 We should upgrade.
>>>
>>> Could you please send a patch?
>>>
>>
>> Here it is :)

I haven't looked too closely at the patch, but I think the newer version
of Artanis have bundled guile-redis (or something like that), so it
would be good to look at unbundling it, similar to how guile-json is
handled.


signature.asc
Description: PGP signature

bug#33953: reconfigure not working tl; dr : EFI not mounted to /boot/efi

[Joshua Branson]

Timothy Sample  writes:

> Hi Joshua,
>
> Joshua Branson  writes:
>
>
> I agree with you that the manual could be more clear.  In the
> installation section, it mentions needing an EFI partition that is
> mounted, but it never spells out that this needs to be included in the
> operating system configuration.  I am not sure how exactly to fix it
> though.  If you were willing propose something, that would be very
> helpful!

Perhaps for now, I'll just throw in this patch that modifies an
guix/system/examples desktop file.  The "full blown" desktop has a UEFI
boot, but it does not show the (file-system (type "vfat") ...) example.
This patch should fix that.

The "light weight window manager" in the manual does have a
(file-system (type "vfat") ...).

>From 0d35f5c6a73dc97959779f727c25e81de9192680 Mon Sep 17 00:00:00 2001
From: Joshua Branson 
Date: Thu, 3 Jan 2019 05:47:23 -0500
Subject: [PATCH] I modified the UEFI desktop example to include the
 (file-system (type "vfat") ...)

---
 gnu/system/examples/desktop.tmpl | 4 
 1 file changed, 4 insertions(+)

diff --git a/gnu/system/examples/desktop.tmpl b/gnu/system/examples/desktop.tmpl
index 1b8d46afa..9c36a2692 100644
--- a/gnu/system/examples/desktop.tmpl
+++ b/gnu/system/examples/desktop.tmpl
@@ -30,6 +30,10 @@
 (mount-point "/")
 (type "ext4")
 (dependencies mapped-devices))
+(file-system
+ (device (uuid "1234-ABCD" 'fat))
+ (mount-point "/boot/efi")
+ (type "vfat"))
   %base-file-systems))
 
   (users (cons (user-account
-- 
2.20.1



--
Joshua Branson
Sent from Emacs and Gnus

bug#33964: guix pull ERROR

[Matthias Lehr]

user@gnu ~$ guix pull
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'... Building from this
channel: guix  https://git.savannah.gnu.org/git/guix.git   95bf2fb
Computing Guix derivation for 'x86_64-linux'...  Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 _)
   222:29 18 (map1 _)
   222:29 17 (map1 _)
   222:29 16 (map1 _)
   222:29 15 (map1 _)
   222:29 14 (map1 _)
   222:17 13 (map1 (((gnu packages xdisorg)) ((gnu packages xorg)) …))
  2800:17 12 (resolve-interface (gnu packages xdisorg) #:select _ # _ …)
In ice-9/threads.scm:
390:8 11 (_ _)
In ice-9/boot-9.scm:
  2726:13 10 (_)
In ice-9/threads.scm:
390:8  9 (_ _)
In ice-9/boot-9.scm:
  2994:20  8 (_)
   2312:4  7 (save-module-excursion _)
  3014:26  6 (_)
In unknown file:
   5 (primitive-load-path "gnu/packages/xdisorg" #)
In ice-9/eval.scm:
619:8  4 (_ #f)
   626:19  3 (_ #)
   293:34  2 (_ #(#(#(# …) …) …))
   223:20  1 (proc #(#(#(# …) …) …))
In unknown file:
   0 (%resolve-variable (7 . meson-build-system) #)

ERROR: In procedure %resolve-variable:
error: meson-build-system: unbound variable
-guix pull: error: You found a bug: the program
'/gnu/store/rd74a504sfkl1ql3719b44fmmvbbjsxz-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"95bf2fb637ba4abb27efe94e0b671c1e93204e4f"; system: "x86_64-linux";
host version: "79f6fc0d9950eb96ffeea4150b1822e759efa0b7"; pull-version:
1). Please report it by email to .

user@gnu ~$ 

-- 
Sent from GNU

bug#33932: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1.

[swedebugia]

On 2019-01-03 12:39, Ricardo Wurmus wrote:


Hi swedebugia,


 From a7f0c26705aad362acc35e632bed2dcc9e32d004 Mon Sep 17 00:00:00 2001
From: swedebugia 
Date: Wed, 2 Jan 2019 23:47:07 +0100
Subject: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1.

* gnu/packages/guile.scm (artanis): Move from here...
* gnu/packages/web.scm (artanis): To here and Update to 0.3.1.


Thanks.

Unfortunately, this patch contains a lot of unrelated changes, as you
can see here:


  gnu/packages/guile.scm | 360 +++--
  gnu/packages/web.scm   |  95 +++
  2 files changed, 368 insertions(+), 87 deletions(-)


Please also split the upgrade from moving the package definition to
another file.


Done, see attached.

Is this acceptable? Or should I have made a new branch from master 
before moving?


--
Cheers Swedebugia
>From 2d7b2109cd42f12192e9e2bf601d539dd4896986 Mon Sep 17 00:00:00 2001
From: swedebugia 
Date: Thu, 3 Jan 2019 17:04:09 +0100
Subject: [PATCH 1/2] gnu: artanis: Update to 0.3.1.

* gnu/packages/guile.scm (artanis): Update it. Added TODO about unbundling
  guile-csv.
---
 gnu/packages/guile.scm | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 07b568ee7..29e488175 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -528,7 +528,7 @@ program can be installed in one go.")
 ;;;
 
 (define-public artanis
-  (let ((release "0.2.1")
+  (let ((release "0.3.1")
 	(revision 3))
 (package
   (name "artanis")
@@ -543,13 +543,14 @@ program can be installed in one go.")
 (file-name (string-append name "-" version ".tar.gz"))
 (sha256
  (base32
-  "041ajcg2pz918kd9iqcj4inpzddc3impvz3r2nhlpbv8zrz011hn"))
+  "0hqr5m3mb558bdhkc2sadmd9cbrhp3y525wx7cwirgy6i0zmay68"))
 (modules '((guix build utils)))
 (snippet
  '(begin
 (delete-file-recursively "artanis/third-party/json.scm")
 (delete-file-recursively "artanis/third-party/json")
 (substitute* '("artanis/artanis.scm"
+   "artanis/lpc.scm"
"artanis/oht.scm")
   (("(#:use-module \\()artanis third-party (json\\))" _
 use-module json)
@@ -565,6 +566,7 @@ program can be installed in one go.")
""))
 #t
   (build-system gnu-build-system)
+  ;; TODO replace bundled csv with guile-csv
   ;; TODO: Add guile-dbi and guile-dbd optional dependencies.
   (inputs `(("guile" ,guile-2.2)
 ("guile-json" ,guile-json)))
@@ -601,7 +603,13 @@ program can be installed in one go.")
  (wrap-program (string-append bin "/art")
`("GUILE_LOAD_PATH" ":" prefix (,scm))
`("GUILE_LOAD_COMPILED_PATH" ":" prefix (,go)))
- #t))
+ #t)))
+   (delete 'strip
+  ;; native-search-paths are needed but left out because we propagate it
+  ;; from the installation of guile.
+  ;; On foreign distributions you have to set this manually no matter if
+  ;; you installed guile with guix or not. On GuixSD it should be set
+  ;; correctly automatically (Guile is always installed there)
   (synopsis "Web application framework written in Guile")
   (description "GNU Artanis is a web application framework written in Guile
 Scheme.  A web application framework (WAF) is a software framework that is
-- 
2.19.2

>From 5652a3f8197150b7b0a435bc65d99e18719f2a3d Mon Sep 17 00:00:00 2001
From: swedebugia 
Date: Thu, 3 Jan 2019 17:12:49 +0100
Subject: [PATCH 2/2] gnu: artanis: Move to web.scm

* gnu/packages/guile.scm (artanis): Move from here...
* gnu/packages/web.scm (artanis): ...to here
---
 gnu/packages/guile.scm | 95 --
 gnu/packages/web.scm   | 95 ++
 2 files changed, 95 insertions(+), 95 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 29e488175..4762191dd 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -527,101 +527,6 @@ program can be installed in one go.")
 ;;; Extensions.
 ;;;
 
-(define-public artanis
-  (let ((release "0.3.1")
-	(revision 3))
-(package
-  (name "artanis")
-  (version (if (zero? revision)
-   release
-   (string-append release "-"
-  (number->string revision
-  (source (origin
-(method url-fetch)
-(uri (string-append "mirror://gnu/artanis/artanis-"
-release ".tar.gz"))
-(file-name (string-append name "-" version ".tar.gz"))
-(sha256
- 

bug#33962: guix pull fails on latest master

[Rutger Helling]

Sorry, that was sloppiness on my part. I built the package on my own
Guix that already had staging merged where apparently the
meson-build-system was already added to the modules.

I was about to revert but I just noticed it's already been fixed. I'll
double check if it builds on a clean master next time.

On Fri, 4 Jan 2019 01:24:22 +1100
Brendan Tildesley  wrote:

> 95bf2fb637ba4abb27efe94e0b671c1e93204e4f , which adds wl-clipboard
> fails to build because it references meson-build-system without
> importing the required module. I'm guessing adding  #:use-module
> (guix build-system meson)   ; would fix it.
> 
> I'm curious to know how this error was made.
> 



pgpZH5No26IUe.pgp
Description: OpenPGP digital signature

bug#33962: Acknowledgement (guix pull fails on latest master)

[Brendan Tildesley]

Efraim fixed it:

bug#33961: guix pull error

[Bradley Haggerty]

Updating channel 'guix' from Git repository at '
https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   95bf2fb
Computing Guix derivation for 'x86_64-linux'...  Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 _)
   222:29 18 (map1 _)
   222:29 17 (map1 _)
   222:29 16 (map1 _)
   222:29 15 (map1 _)
   222:29 14 (map1 _)
   222:17 13 (map1 (((gnu packages xdisorg)) ((gnu packages xorg)) …))
  2800:17 12 (resolve-interface (gnu packages xdisorg) #:select _ # _ …)
In ice-9/threads.scm:
390:8 11 (_ _)
In ice-9/boot-9.scm:
  2726:13 10 (_)
In ice-9/threads.scm:
390:8  9 (_ _)
In ice-9/boot-9.scm:
  2994:20  8 (_)
   2312:4  7 (save-module-excursion _)
  3014:26  6 (_)
In unknown file:
   5 (primitive-load-path "gnu/packages/xdisorg" #)
In ice-9/eval.scm:
619:8  4 (_ #f)
   626:19  3 (_ #)
   293:34  2 (_ #(#(#(# …) …) …))
   223:20  1 (proc #(#(#(# …) …) …))
In unknown file:
   0 (%resolve-variable (7 . meson-build-system) #)

ERROR: In procedure %resolve-variable:
error: meson-build-system: unbound variable
guix pull: error: You found a bug: the program
'/gnu/store/rd74a504sfkl1ql3719b44fmmvbbjsxz-compute-guix-derivation'

failed to compute the derivation for Guix (version:
"95bf2fb637ba4abb27efe94e0b671c1e93204e4f"; system:
"x86_64-linux";

host version: "0.16.0-8.7ba2b27"; pull-version: 1).

bug#33962: guix pull fails on latest master

[Brendan Tildesley]

95bf2fb637ba4abb27efe94e0b671c1e93204e4f , which adds wl-clipboard fails
to build because it references meson-build-system without importing the
required module. I'm guessing adding  #:use-module (guix build-system
meson)   ; would fix it.

I'm curious to know how this error was made.

bug#33932: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1. (was: Re: bug#33932: Artanis fails to build - 0.3.1 is out)

[Ricardo Wurmus]

Hi swedebugia,

> From a7f0c26705aad362acc35e632bed2dcc9e32d004 Mon Sep 17 00:00:00 2001
> From: swedebugia 
> Date: Wed, 2 Jan 2019 23:47:07 +0100
> Subject: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1.
>
> * gnu/packages/guile.scm (artanis): Move from here...
> * gnu/packages/web.scm (artanis): To here and Update to 0.3.1.

Thanks.

Unfortunately, this patch contains a lot of unrelated changes, as you
can see here:

>  gnu/packages/guile.scm | 360 +++--
>  gnu/packages/web.scm   |  95 +++
>  2 files changed, 368 insertions(+), 87 deletions(-)

Please also split the upgrade from moving the package definition to
another file.

--
Ricardo