[PATCH] Improve shell script headers and pre-inst-env handling

[Mark H Weaver]

Hello all,

I've attached two patches.  The first arranges to make sure that
'pre-inst-env' will be rebuilt when 'pre-inst-env.in' is modified.

The second patch is the main subject of this email.  It reworks the
shell script headers at the top of 'guix-package' and the other scripts
to avoid modifying environment variables (which could propagate to
unrelated subprocesses that use libguile), and to avoid prepending
installed directories to the guile load paths in the case where
'pre-inst-env' is being used.

My approach here might be controversial, given that the resulting code
is a bit longer, so if you don't like it, no worries :)

However, I do find it nice to write more scheme and less shell code, and
as a bonus the scheme code at the top is properly handled by emacs and
paredit as if it were in the main body of the file.

What do you think?

  Mark

Re: [PATCH] Improve shell script headers and pre-inst-env handling

[Mark H Weaver]

I wrote:

> I've attached two patches.  The first arranges to make sure that
> 'pre-inst-env' will be rebuilt when 'pre-inst-env.in' is modified.
>
> The second patch is the main subject of this email.  It reworks the
> shell script headers at the top of 'guix-package' and the other scripts
> to avoid modifying environment variables (which could propagate to
> unrelated subprocesses that use libguile), and to avoid prepending
> installed directories to the guile load paths in the case where
> 'pre-inst-env' is being used.
>
> My approach here might be controversial, given that the resulting code
> is a bit longer, so if you don't like it, no worries :)
>
> However, I do find it nice to write more scheme and less shell code, and
> as a bonus the scheme code at the top is properly handled by emacs and
> paredit as if it were in the main body of the file.
>
> What do you think?

And here are the actual patches (oops :)

  Mark


>From 172011c586a96cd15e6401cf813fd6d6ea59b355 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Mon, 11 Feb 2013 19:23:20 -0500
Subject: [PATCH 1/2] Add noinst_SCRIPTS = pre-inst-env to Makefile.am.

* Makefile.am: Add noinst_SCRIPTS = pre-inst-env.
---
 Makefile.am |3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index b90f7e0..9ec7f55 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -24,6 +24,9 @@ bin_SCRIPTS =	\
   guix-package	\
   guix-gc
 
+noinst_SCRIPTS =\
+  pre-inst-env
+
 MODULES =	\
   guix/base32.scm\
   guix/utils.scm\
-- 
1.7.10.4

>From 4df3f71782256c7a90f9a7445f093a545fcaa1b1 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Mon, 11 Feb 2013 19:13:32 -0500
Subject: [PATCH 2/2] Improve shell script headers and pre-inst-env handling.

* pre-inst-env.in: Define $GUIX_UNINSTALLED.

* guix-build.in, guix-download.in, guix-gc.in, guix-import.in,
  guix-package.in: Rewrite shell script headers to adjust '%load-path' and
  '%load-compiled-path' within Guile itself instead of setting environment
  variables.  Inhibit this behavior if $GUIX_UNINSTALLED is set to a non-empty
  string.
---
 guix-build.in|   22 --
 guix-download.in |   22 --
 guix-gc.in   |   24 +---
 guix-import.in   |   22 --
 guix-package.in  |   24 +---
 pre-inst-env.in  |7 ++-
 6 files changed, 88 insertions(+), 33 deletions(-)

diff --git a/guix-build.in b/guix-build.in
index f8c7115..6b79962 100644
--- a/guix-build.in
+++ b/guix-build.in
@@ -1,15 +1,25 @@
 #!/bin/sh
 # aside from this initial boilerplate, this is actually -*- scheme -*- code
 
+script=guix-build
+
 prefix="@prefix@"
 datarootdir="@datarootdir@"
+moduledir="@guilemoduledir@"
 
-GUILE_LOAD_COMPILED_PATH="@guilemoduledir@:$GUILE_LOAD_COMPILED_PATH"
-export GUILE_LOAD_COMPILED_PATH
-
-main='(module-ref (resolve-interface '\''(guix-build)) '\'guix-build')'
-exec ${GUILE-@GUILE@} -L "@guilemoduledir@" -l "$0"\
- -c "(apply $main (cdr (command-line)))" "$@"
+start="
+(let ()
+  (define (main interp guix-uninstalled-str module-dir script-file . args)
+(let* ((guix-uninstalled? (not (string-null? guix-uninstalled-str)))
+   (path-to-prepend (if guix-uninstalled? '() (list module-dir
+  (set! %load-path  (append path-to-prepend %load-path))
+  (set! %load-compiled-path (append path-to-prepend %load-compiled-path))
+  (load script-file)
+  (let (($script (module-ref (resolve-interface '($script)) '$script)))
+(apply $script args
+  (apply main (command-line)))
+"
+exec "${GUILE-@GUILE@}" -c "$start" "$GUIX_UNINSTALLED" "$moduledir" "$0" "$@"
 !#
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013 Ludovic Courtès 
diff --git a/guix-download.in b/guix-download.in
index ea62b09..f6f226e 100644
--- a/guix-download.in
+++ b/guix-download.in
@@ -1,15 +1,25 @@
 #!/bin/sh
 # aside from this initial boilerplate, this is actually -*- scheme -*- code
 
+script=guix-download
+
 prefix="@prefix@"
 datarootdir="@datarootdir@"
+moduledir="@guilemoduledir@"
 
-GUILE_LOAD_COMPILED_PATH="@guilemoduledir@:$GUILE_LOAD_COMPILED_PATH"
-export GUILE_LOAD_COMPILED_PATH
-
-main='(module-ref (resolve-interface '\''(guix-download)) '\'guix-download')'
-exec ${GUILE-@GUILE@} -L "@guilemoduledir@" -l "$0"\
- -c "(apply $main (cdr (command-line)))" "$@"
+start="
+(let ()
+  (define (main interp guix-uninstalled-str m

Re: [PATCH] Improve shell script headers and pre-inst-env handling

[Mark H Weaver]

Here's an improved version of the second patch.  There's no functional
difference, but the code is easier to read IMO.

 Mark


>From b1ea7f6ab01fb5c1ae1638315dad3fc8903682dc Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Mon, 11 Feb 2013 19:13:32 -0500
Subject: [PATCH 2/2] Improve shell script headers and pre-inst-env handling.

* pre-inst-env.in: Define $GUIX_UNINSTALLED.

* guix-build.in, guix-download.in, guix-gc.in, guix-import.in,
  guix-package.in: Rewrite shell script headers to augment '%load-path' and
  '%load-compiled-path' within Guile itself instead of setting environment
  variables.  Inhibit this behavior if $GUIX_UNINSTALLED is set.
---
 guix-build.in|   22 --
 guix-download.in |   22 --
 guix-gc.in   |   22 --
 guix-import.in   |   22 --
 guix-package.in  |   22 --
 pre-inst-env.in  |7 ++-
 6 files changed, 86 insertions(+), 31 deletions(-)

diff --git a/guix-build.in b/guix-build.in
index f8c7115..29241c7 100644
--- a/guix-build.in
+++ b/guix-build.in
@@ -1,15 +1,25 @@
 #!/bin/sh
 # aside from this initial boilerplate, this is actually -*- scheme -*- code
 
+script=guix-build
+
 prefix="@prefix@"
 datarootdir="@datarootdir@"
 
-GUILE_LOAD_COMPILED_PATH="@guilemoduledir@:$GUILE_LOAD_COMPILED_PATH"
-export GUILE_LOAD_COMPILED_PATH
-
-main='(module-ref (resolve-interface '\''(guix-build)) '\'guix-build')'
-exec ${GUILE-@GUILE@} -L "@guilemoduledir@" -l "$0"\
- -c "(apply $main (cdr (command-line)))" "$@"
+startup="
+(let ()
+  (define-syntax-rule (push! elt v) (set! v (cons elt v)))
+  (define (main interpreter module-dir script-file . args)
+(unless (getenv \"GUIX_UNINSTALLED\")
+  (push! module-dir %load-path)
+  (push! module-dir %load-compiled-path))
+(load script-file)
+(let ((proc (module-ref (resolve-interface '($script))
+'$script)))
+  (apply proc args)))
+  (apply main (command-line)))
+"
+exec "${GUILE-@GUILE@}" -c "$startup" "@guilemoduledir@" "$0" "$@"
 !#
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013 Ludovic Courtès 
diff --git a/guix-download.in b/guix-download.in
index ea62b09..ccffbde 100644
--- a/guix-download.in
+++ b/guix-download.in
@@ -1,15 +1,25 @@
 #!/bin/sh
 # aside from this initial boilerplate, this is actually -*- scheme -*- code
 
+script=guix-download
+
 prefix="@prefix@"
 datarootdir="@datarootdir@"
 
-GUILE_LOAD_COMPILED_PATH="@guilemoduledir@:$GUILE_LOAD_COMPILED_PATH"
-export GUILE_LOAD_COMPILED_PATH
-
-main='(module-ref (resolve-interface '\''(guix-download)) '\'guix-download')'
-exec ${GUILE-@GUILE@} -L "@guilemoduledir@" -l "$0"\
- -c "(apply $main (cdr (command-line)))" "$@"
+startup="
+(let ()
+  (define-syntax-rule (push! elt v) (set! v (cons elt v)))
+  (define (main interpreter module-dir script-file . args)
+(unless (getenv \"GUIX_UNINSTALLED\")
+  (push! module-dir %load-path)
+  (push! module-dir %load-compiled-path))
+(load script-file)
+(let ((proc (module-ref (resolve-interface '($script))
+'$script)))
+  (apply proc args)))
+  (apply main (command-line)))
+"
+exec "${GUILE-@GUILE@}" -c "$startup" "@guilemoduledir@" "$0" "$@"
 !#
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013 Ludovic Courtès 
diff --git a/guix-gc.in b/guix-gc.in
index 1a4a541..84f18dd 100644
--- a/guix-gc.in
+++ b/guix-gc.in
@@ -1,15 +1,25 @@
 #!/bin/sh
 # aside from this initial boilerplate, this is actually -*- scheme -*- code
 
+script=guix-gc
+
 prefix="@prefix@"
 datarootdir="@datarootdir@"
 
-GUILE_LOAD_COMPILED_PATH="@guilemoduledir@:$GUILE_LOAD_COMPILED_PATH"
-export GUILE_LOAD_COMPILED_PATH
-
-main='(module-ref (resolve-interface '\''(guix-gc)) '\'guix-gc')'
-exec ${GUILE-@GUILE@} -L "@guilemoduledir@" -l "$0"\
- -c "(apply $main (cdr (command-line)))" "$@"
+startup="
+(let ()
+  (define-syntax-rule (push! elt v) (set! v (cons elt v)))
+  (define (main interpreter module-dir script-file . args)
+(unless (getenv \"GUIX_UNINSTALLED\")
+  (push! module-dir %load-path)
+  (push! module-dir %load-compiled-path))
+(load script-file)
+(let ((proc (module-ref (resolve-interface '($script))
+'$script)))
+  (apply proc args)))
+  (apply main (command-li

[PATCH] Implement guix-package --upgrade

[Mark H Weaver]

Hello all,

Here's an implementation of the -u/--upgrade option for guix-package.

The one thing I'm not happy about is that it complains about ambiguous
package specifications when asked to upgrade packages such as guile,
though it seems to me that there's no way to avoid that.

Comments and suggestions solicited.

  Mark


>From 3436dd9460e1b7b85584a96df3bb57b022629651 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 12 Feb 2013 01:24:21 -0500
Subject: [PATCH] Implement guix-package --upgrade.

* guix-package.in (%options): Add -u/--upgrade option.
  (process-actions): Implement upgrade option.
---
 guix-package.in |   39 ---
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/guix-package.in b/guix-package.in
index 32d9afd..ec91581 100644
--- a/guix-package.in
+++ b/guix-package.in
@@ -356,6 +356,9 @@ Install, remove, or upgrade PACKAGES in a single transaction.\n"))
 (option '(#\r "remove") #t #f
 (lambda (opt name arg result)
   (alist-cons 'remove arg result)))
+(option '(#\u "upgrade") #t #f
+(lambda (opt name arg result)
+  (alist-cons 'upgrade arg result)))
 (option '("roll-back") #f #f
 (lambda (opt name arg result)
   (alist-cons 'roll-back? #t result)))
@@ -520,13 +523,30 @@ Install, remove, or upgrade PACKAGES in a single transaction.\n"))
 (begin
   (roll-back profile)
   (process-actions (alist-delete 'roll-back? opts)))
-(let* ((install  (filter-map (match-lambda
-  (('install . (? store-path?))
-   #f)
-  (('install . package)
-   (find-package package))
-  (_ #f))
- opts))
+(let* ((installed (manifest-packages (profile-manifest profile)))
+   (upgrade-regexps (filter-map (match-lambda
+ (('upgrade . regexp)
+  (make-regexp regexp))
+ (_ #f))
+opts))
+   (upgrade  (if (null? upgrade-regexps)
+ '()
+ (filter-map (match-lambda
+  ((name _ _ _ _)
+   (and (any (cut regexp-exec <> name)
+ upgrade-regexps)
+(find-package name)))
+  (_ #f))
+ installed)))
+   (install  (append
+  upgrade
+  (filter-map (match-lambda
+   (('install . (? store-path?))
+#f)
+   (('install . package)
+(find-package package))
+   (_ #f))
+  opts)))
(drv  (filter-map (match-lambda
   ((name version sub-drv
  (? package? package)
@@ -563,10 +583,7 @@ Install, remove, or upgrade PACKAGES in a single transaction.\n"))
  (match package
((name _ ...)
 (alist-delete name result
-   (fold alist-delete
- (manifest-packages
-  (profile-manifest profile))
- remove)
+   (fold alist-delete installed remove)
install*
 
   (when (equal? profile %current-profile)
-- 
1.7.10.4

Re: [PATCH] Implement guix-package --upgrade

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>> +   (upgrade  (if (null? upgrade-regexps)
>> + '()
>> + (filter-map (match-lambda
>> +  ((name _ _ _ _)
>> +   (and (any (cut regexp-exec <> 
>> name)
>> + upgrade-regexps)
>> +(find-package name)))
>> +  (_ #f))
>> + installed)))
>
> It’s actually slightly more complex: you need to select those packages
> that are installed and for which either a newer version is available
> (per ‘version-string>?’, see gnu-maintenance.scm; should be moved to
> utils.scm), or the version is identical and the output path differs (for
> instance because one of its dependencies has changed.)

Okay.  I was relying on the fact that attempts to install a derivation
that's already installed will ultimately be ignored, and my (admittedly
simple) tests seem to suggest that it works properly, but perhaps this
approach will be too inefficient when the profile contains a large
number of packages.

I'll do as you suggest and post an updated patch soon.

> There are tests in guix-package.sh, but this one is going to be
> difficult to test without building the world.

Would you be willing to write the tests?  I think that my knowledge of
Guix is still too weak to do this job properly.  (For that matter, it
was probably foolish of me to try to implement --upgrade at this early
stage in my explorations :)

> I think guix-package needs a -e switch (as for guix-build), which would
> allow us to write dummy packages for test purposes.

Makes sense.

   Thanks!
 Mark

Re: [PATCH] Improve shell script headers and pre-inst-env handling

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:
> Honestly, I wouldn’t worry about the propagation of $GUILE_LOAD_PATH &
> co. to subprocesses, because we know there’s none anyway.

That policy will lead to future where libguile-using programs break in
random ways when they happen to be subprocesses of each other.

Shouldn't we be setting a better example than that?

If we assume that Guile will never be widely used, and encourage usage
patterns that will cause things to break if it ever becomes more
successful, then we are pretty much guaranteeing a bleak future for
Guile.

Isn't correctness more important than brevity?

What do you think?

Mark

Re: [PATCH] Implement guix-package --upgrade

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> Okay.  I was relying on the fact that attempts to install a derivation
>> that's already installed will ultimately be ignored, and my (admittedly
>> simple) tests seem to suggest that it works properly, but perhaps this
>> approach will be too inefficient when the profile contains a large
>> number of packages.
>
> More importantly, you don’t want upgrade to downgrade.

Ah, good point! :)

> For instance, if guile-1.8.8 turns out to be before guile-2.0.7 in the
> package list, users who’ve installed the latter shouldn’t suddenly
> downgrade to the former.

Would "guix-package -i guile" ever choose guile-1.8.8 over guile-2.0.7
if the latter was available?  Does it not automatically choose the
newest available version?  If not, should it?

> I’ll take care of the tests and -e.

Great, thanks!

I've attached a new implementation of --upgrade along the lines you
suggested.  Still remaining to be done: if there are multiple packages
with the same (newest) version number, choose intelligently between
them.

The first patch moves 'version-string>?' to (guix utils) and renames it
to 'version>?'.  It also adds 'version-compare'.  I needed these for the
improved upgrade implementation.

Comments and suggestions solicited.

 Mark


>From bd192057c770ca3653828498591dbe4683b51545 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 12 Feb 2013 12:02:15 -0500
Subject: [PATCH 1/2] Add version-compare and version>? to utils.scm.

* guix/utils.scm (version-compare, version>?): New exported procedures,
  based on version-string>?, which was formerly in gnu-maintenance.scm.

* guix/gnu-maintenance.scm (version-string>?): Removed procedure.
  (latest-release): Use 'version>?' instead of 'version-string>?'.
---
 guix/gnu-maintenance.scm |   12 ++--
 guix/utils.scm   |   20 
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/guix/gnu-maintenance.scm b/guix/gnu-maintenance.scm
index c934694..6475c38 100644
--- a/guix/gnu-maintenance.scm
+++ b/guix/gnu-maintenance.scm
@@ -28,6 +28,7 @@
   #:use-module (srfi srfi-26)
   #:use-module (system foreign)
   #:use-module (guix ftp-client)
+  #:use-module (guix utils)
   #:export (official-gnu-packages
 releases
 latest-release
@@ -156,21 +157,12 @@ pairs.  Example: (\"mit-scheme-9.0.1\" . \"/gnu/mit-scheme/stable.pkg/9.0.1\").
files)
result)))
 
-(define version-string>?
-  (let ((strverscmp
- (let ((sym (or (dynamic-func "strverscmp" (dynamic-link))
-(error "could not find `strverscmp' (from GNU libc)"
-   (pointer->procedure int sym (list '* '*)
-(lambda (a b)
-  "Return #t when B denotes a newer version than A."
-  (> (strverscmp (string->pointer a) (string->pointer b)) 0
-
 (define (latest-release project)
   "Return (\"FOO-X.Y\" . \"/bar/foo\") or #f."
   (let ((releases (releases project)))
 (and (not (null? releases))
  (fold (lambda (release latest)
- (if (version-string>? (car release) (car latest))
+ (if (version>? (car release) (car latest))
  release
  latest))
'("" . "")
diff --git a/guix/utils.scm b/guix/utils.scm
index 7ab835e..d7c37e3 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -57,6 +57,8 @@
 
 gnu-triplet->nix-system
 %current-system
+version-compare
+version>?
 package-name->name+version))
 
 
@@ -422,6 +424,24 @@ returned by `config.guess'."
   ;; By default, this is equal to (gnu-triplet->nix-system %host-type).
   (make-parameter %system))
 
+(define version-compare
+  (let ((strverscmp
+ (let ((sym (or (dynamic-func "strverscmp" (dynamic-link))
+(error "could not find `strverscmp' (from GNU libc)"
+   (pointer->procedure int sym (list '* '*)
+(lambda (a b)
+  "Return '> when A denotes a newer version than B,
+'< when A denotes a older version than B,
+or '= when they denote equal versions."
+  (let ((result (strverscmp (string->pointer a) (string->pointer b
+(cond ((positive? result) '>)
+  ((negative? result) '<)
+  (else '=))
+
+(define (version>? a b)
+  "Return #t when A denotes a newer version than B."
+  (eq? '> (version-compare a b)))
+
 (define (package-name->name+version name)
   "Given

Re: [PATCH] Implement guix-package --upgrade

[Mark H Weaver]

I wrote:
> Would "guix-package -i guile" ever choose guile-1.8.8 over guile-2.0.7
> if the latter was available?  Does it not automatically choose the
> newest available version?

Having now looked at the code, I see that it does not.

My latest upgrade implemention assumed that it did, so I'll have to fix
that.  Please hold off on reviewing the current patch.  Another is now
in the works.

> If not, should it?

For now, I'm going to assume that "guix-package -i guile" indeed
*should* choose from among the newest available versions, so I'm going
to work on fixing that.

Please let me know if you disagree.

 Mark

Re: [PATCH] Improve shell script headers and pre-inst-env handling

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>> Honestly, I wouldn’t worry about the propagation of $GUILE_LOAD_PATH &
>>> co. to subprocesses, because we know there’s none anyway.
>>
>> That policy will lead to future where libguile-using programs break in
>> random ways when they happen to be subprocesses of each other.
>
> I agree in general with your feeling.
>
> However, in that case, we know that these command-line tools are just
> wrappers around our Scheme APIs, and that they won’t ever launch any
> program (programs are a thing of the past; procedures are the future).
> So it just seemed safe to me to do that in this particular case.
>
> What do you think?

Ah, okay, I didn't realize that.  When you said "we know there's none
anyway", I thought you meant "no subprocesses that use Guile", but I
guess you meant "no subprocesses at all".

I guess guix-daemon is the only one with subprocesses, and by the time
that's written in Guile hopefully Guile will have a command-line option
to augment %load-compiled-path.

In that case, I withdraw my proposal.  I'll make a new patch.

> (BTW, rather than $GUIX_UNINSTALLED, it just occurred to me that
> $GUIX_LOAD_PATH would do just as well while being more generic and
> easier to implement/use.)

Sounds good.

Mark

[PATCH] Inhibit duplicates in fold-packages

[Mark H Weaver]

Here's a patch to inhibit the same package (in the sense of eq?) from
being traversed more than once by fold-packages.  One example where this
helps is the guile-2.0 package in (gnu packages guile), which is
exported in two different variables: guile-2.0 and guile-2.0/fixed.

Note that even after applying this patch, there are still cases where
"guix-package -A ." produces the same output twice, but that's a
different problem.  In the remaining cases, there are actually two
distinct package objects being printed the same way because the
'location' field is inherited from one package to another.  For example
this happens with the 'gcc-boot0' and 'gcc-4.7' packages in (gnu
packages base).

What do you think?

Mark


>From 1d30931a28af4ed6aa747a05bc3540e335ce1b32 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 12 Feb 2013 20:29:30 -0500
Subject: [PATCH] Inhibit duplicates in fold-packages.

* gnu/packages.scm (fold2): New procedure.
  (fold-packages): Rework to suppress duplicates.
---
 gnu/packages.scm |   36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/gnu/packages.scm b/gnu/packages.scm
index 6a5496e..d783e4c 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -21,6 +21,7 @@
   #:use-module (guix utils)
   #:use-module (ice-9 ftw)
   #:use-module (ice-9 vlist)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-39)
@@ -108,20 +109,33 @@
   (false-if-exception (resolve-interface name
   (package-files)))
 
+(define (fold2 f seed1 seed2 lst)
+  (if (null? lst)
+  (values seed1 seed2)
+  (call-with-values
+  (lambda () (f (car lst) seed1 seed2))
+(lambda (seed1 seed2)
+  (fold2 f seed1 seed2 (cdr lst))
+
 (define (fold-packages proc init)
   "Call (PROC PACKAGE RESULT) for each available package, using INIT as
 the initial value of RESULT."
-  (fold (lambda (module result)
-  (fold (lambda (var result)
-  (if (package? var)
-  (proc var result)
-  result))
-result
-(module-map (lambda (sym var)
-  (false-if-exception (variable-ref var)))
-module)))
-init
-(package-modules)))
+  (identity   ; discard second return value
+   (fold2 (lambda (module result seen)
+(fold2 (lambda (var result seen)
+ (if (and (package? var)
+  (not (vhash-assq var seen)))
+ (values (proc var result)
+ (vhash-consq var #t seen))
+ (values result seen)))
+   result
+   seen
+   (module-map (lambda (sym var)
+ (false-if-exception (variable-ref var)))
+   module)))
+  init
+  vlist-null
+  (package-modules
 
 (define* (find-packages-by-name name #:optional version)
   "Return the list of packages with the given NAME.  If VERSION is not #f,
-- 
1.7.10.4

Re: w3m: 'license'; error: redefinition of 'struct file_handle'

[Mark H Weaver]

Nikita Karetnikov  writes:
> w3m raises the following error:
>
> istream.h:23:8: error: redefinition of 'struct file_handle'

The issue here is that glibc started using "struct file_handle", which
conflicts with w3m's prior use of the same name.  You shouldn't need a
patch for this.  Just replace "struct file_handle" with "struct
io_file_handle" everywhere in the w3m source code.  That will have no
effect on the operation of the program whatsoever.

 Mark

Re: w3m: 'license'; error: redefinition of 'struct file_handle'

[Mark H Weaver]

Nikita Karetnikov  writes:

> Also, I'm not sure what license should be used.  Should we create a new
> one?
>
> This page [2] states that w3m is under MIT, which is an ambiguous name
> of the Expat License [3].

That's incorrect.  While it is true that the Expat license is sometimes
ambiguously referred to as the MIT license, it does not follow that
everything called the MIT license is actually the Expat license.  Many
different licenses are ambiguously referred to as the MIT license.

In general, you cannot trust a project's web page or any README in a
source distribution.  The only truly reliable method is to look at the
copyright notices in every source file, but that's far too much work;
we'd never get anywhere if we did that.

The best practical resource I know of for this job are the Debian
copyright files, which are in /usr/share/doc//copyright on
a Debian system.  They are also available by going to their web site:

  http://packages.debian.org/sid/

and then clicking on the "Copyright File" link in the right column.
Debian is more consistently thorough in their research on copyright
notices than anyone else I know of.  The main caveat is that these files
describe Debian's modified versions of the package, not upstream.  Most
notably, Debian may have removed code with objectionable licenses, and
thus those objectionable licenses may not appear in their copyright
files.  A useful marker for this case is when you see "dfsg" in the
binary package name (which most often means that GFDL-covered
documentation was removed).

Anyway, in the case of w3m, there are quite a variety of licenses used:

  
http://packages.debian.org/changelogs/pool/main/w/w3m/w3m_0.5.3-8/w3m.copyright

I don't know how Ludovic wants to handle complex cases like this, so
I'll let him chime in here.

Thanks for your tireless efforts, Nikita!

 Mark

Re: [PATCH] Improve shell script headers and pre-inst-env handling

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>> Honestly, I wouldn’t worry about the propagation of $GUILE_LOAD_PATH &
>>> co. to subprocesses, because we know there’s none anyway.
>>
>> That policy will lead to future where libguile-using programs break in
>> random ways when they happen to be subprocesses of each other.
>
> I agree in general with your feeling.
>
> However, in that case, we know that these command-line tools are just
> wrappers around our Scheme APIs, and that they won’t ever launch any
> program (programs are a thing of the past; procedures are the future).
> So it just seemed safe to me to do that in this particular case.
>
> What do you think?

So I've been working on a patch to fix the ./pre-inst-env problem using
portable shell code instead of Guile code, as you suggested, and this is
the kind of code I'm coming up with:

--8<---cut here---start->8---
#!/bin/sh
# aside from this initial boilerplate, this is actually -*- scheme -*- code

prefix="@prefix@"
datarootdir="@datarootdir@"

main='(module-ref (resolve-interface '\''(guix-package)) '\'guix-package')'

if test "x$GUIX_UNINSTALLED" = x; then
  GUILE_LOAD_COMPILED_PATH="@guilemoduledir@:$GUILE_LOAD_COMPILED_PATH"
  export GUILE_LOAD_COMPILED_PATH
  exec ${GUILE-@GUILE@} -L "@guilemoduledir@" -l "$0"\
   -c "(apply $main (cdr (command-line)))" "$@"
else
  exec ${GUILE-@GUILE@} -l "$0"\
   -c "(apply $main (cdr (command-line)))" "$@"
fi
!#
--8<---cut here---end--->8---

or perhaps you'd prefer something more like this:

--8<---cut here---start->8---
#!/bin/sh
# aside from this initial boilerplate, this is actually -*- scheme -*- code

prefix="@prefix@"
datarootdir="@datarootdir@"

if test "x$GUIX_UNINSTALLED" = x; then
  GUILE_LOAD_COMPILED_PATH="@guilemoduledir@:$GUILE_LOAD_COMPILED_PATH"
  export GUILE_LOAD_COMPILED_PATH
  load_path_args="-L @guilemoduledir@"
else
  load_path_args=""
fi

main='(module-ref (resolve-interface '\''(guix-package)) '\'guix-package')'
exec ${GUILE-@GUILE@} $load_path_args -l "$0"\
 -c "(apply $main (cdr (command-line)))" "$@"
!#
--8<---cut here---end--->8---

but the more I look at this ugly, buggy code; and the more I fret
about the inherent bugs having to do with poor handling of shell
meta-characters and colons in file names; and the more I read of the
"Portable Shell Programming" chapter of the autoconf manual, the less
I understand why you feel so strongly about using this awful language
instead of the Guile code I wrote.  To save a few lines?

Please take a look at my proposed code one more time with fresh eyes:

--8<---cut here---start->8---
#!/bin/sh
# aside from this initial boilerplate, this is actually -*- scheme -*- code

script=guix-build

prefix="@prefix@"
datarootdir="@datarootdir@"

startup="
(let ()
  (define-syntax-rule (push! elt v) (set! v (cons elt v)))
  (define (main interpreter module-dir script-file . args)
(unless (getenv \"GUIX_UNINSTALLED\")
  (push! module-dir %load-path)
  (push! module-dir %load-compiled-path))
(load script-file)
(let ((proc (module-ref (resolve-interface '($script))
'$script)))
  (apply proc args)))
  (apply main (command-line)))
"
exec "${GUILE-@GUILE@}" -c "$startup" "@guilemoduledir@" "$0" "$@"
--8<---cut here---end--->8---

Allow me to list the advantages:

* Schemers will have a much easier time understanding precisely what
  this code does, without having to grok the finer details of shell
  programming and Guile's command-line handling.

* It sets a good example for how to write a Guile program that will be
  robust in the case where subprocesses might also use Guile.

* The boilerplate code is identical in all scripts except on line 4
  (script=guix-build).

* It is completely robust in its handling of unusual characters, with
  the sole exception of "${GUILE-@GUILE@}" which could fail if @GUILE@
  contains meta-characters.  I could fix that too with a few more lines
  of code.  (And yes, I know that autoconf is already unable to handle
  filenames with meta-characters, but that's no excuse to create similar
  bugs in our own code if we ca

[PATCH] Build newest versions unless specified, and upgrades.

[Mark H Weaver]

Hello all,

Here's a preliminary patch that does two things:

* Changes 'guix-build' and 'guix-package --install' so that only the
  newest packages will be considered (unless a version number is
  specified).

* Implements 'guix-package --upgrade'.

Although I'm not aware of any functional problems with this code, I'm
not entirely pleased with its organization.  Nonetheless, I wanted to
make it available for early testing and comments.

I welcome suggestions on how to improve this code.

  Mark


>From 16cf486524502c1caebbd8831a8f6802640aeace Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 12 Feb 2013 01:24:21 -0500
Subject: [PATCH] Build newest versions unless specified, and implement
 upgrades.

* gnu/packages.scm (find-newest-available-packages):
  New exported procedure.

* guix-build.in (newest-available-packages, find-best-packages-by-name):
  New procedures.
  (find-package): Use find-best-packages-by-name, to guarantee that
  if a version number is not specified, only the newest versions will
  be considered.

* guix-package.in (%options): Add --upgrade/-u option.
  (newest-available-packages, find-best-packages-by-name, upgradeable?):
  New procedures.
  (find-package): Use find-best-packages-by-name, to guarantee that
  if a version number is not specified, only the newest versions will
  be considered.
  (process-actions): Implement upgrade option.
---
 gnu/packages.scm |   24 +-
 guix-build.in|   16 ++--
 guix-package.in  |   71 --
 3 files changed, 95 insertions(+), 16 deletions(-)

diff --git a/gnu/packages.scm b/gnu/packages.scm
index 792fe44..04ca840 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -20,6 +20,8 @@
   #:use-module (guix packages)
   #:use-module (guix utils)
   #:use-module (ice-9 ftw)
+  #:use-module (ice-9 vlist)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-39)
@@ -28,7 +30,8 @@
 %patch-directory
 %bootstrap-binaries-path
 fold-packages
-find-packages-by-name))
+find-packages-by-name
+find-newest-available-packages))
 
 ;;; Commentary:
 ;;;
@@ -137,3 +140,22 @@ then only return packages whose version is equal to VERSION."
(cons package result)
result))
  '()))
+
+(define (find-newest-available-packages)
+  "Return a vhash with elements of the form
+  (name newest-version newest-package ...)
+where the preferred package is listed first."
+
+  ;; FIXME: Currently, the preferred package is whichever one
+  ;; was found last by 'fold-packages'.  Find a better solution.
+  (fold-packages (lambda (p r)
+   (let ((name(package-name p))
+ (version (package-version p)))
+ (match (vhash-assoc name r)
+   ((_ newest-so-far . pkgs)
+(case (version-compare version newest-so-far)
+  ((>) (vhash-cons name `(,version ,p) r))
+  ((=) (vhash-cons name `(,version ,p ,@pkgs) r))
+  ((<) r)))
+   (#f (vhash-cons name `(,version ,p) r)
+ vlist-null))
diff --git a/guix-build.in b/guix-build.in
index 29241c7..3bfddeb 100644
--- a/guix-build.in
+++ b/guix-build.in
@@ -47,6 +47,7 @@ exec "${GUILE-@GUILE@}" -c "$startup" "@guilemoduledir@" "$0" "$@"
   #:use-module (guix utils)
   #:use-module (ice-9 format)
   #:use-module (ice-9 match)
+  #:use-module (ice-9 vlist)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-11)
   #:use-module (srfi srfi-26)
@@ -206,13 +207,24 @@ Build the given PACKAGE-OR-DERIVATION and return their output paths.\n"))
  root (strerror (system-error-errno args)))
  (exit 1)
 
+  (define newest-available-packages
+(memoize find-newest-available-packages))
+
+  (define (find-best-packages-by-name name version)
+(if version
+(find-packages-by-name name version)
+(match (vhash-assoc name (newest-available-packages))
+  ((_ version pkgs ...) pkgs)
+  (#f '()
+
   (define (find-package request)
 ;; Return a package matching REQUEST.  REQUEST may be a package
 ;; name, or a package name followed by a hyphen and a version
-;; number.
+;; number.  If the version number is not present, return the
+;; preferred newest version.
 (let-values (((name version)
   (package-name->name+version request)))
-  (match (find-packages-by-name name version)
+  (match (find-best-packages-by-name name version)
 ((p)  ; one match
  p)
 ((p x ...)   

Re: [PATCH] Inhibit duplicates in fold-packages

[Mark H Weaver]

I wrote:
> Here's a patch to inhibit the same package (in the sense of eq?) from
> being traversed more than once by fold-packages.  One example where this
> helps is the guile-2.0 package in (gnu packages guile), which is
> exported in two different variables: guile-2.0 and guile-2.0/fixed.
>
> Note that even after applying this patch, there are still cases where
> "guix-package -A ." produces the same output twice, but that's a
> different problem.  [...]

Sorry, the patch I posted did not apply cleanly, because it was layered
on top of a preliminary version of my upgrade patch.  Here's a fixed
version.

 Mark


>From fcb78e4af6d4f7304582fa2ad44eb99236b6ae23 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 12 Feb 2013 20:29:30 -0500
Subject: [PATCH] Inhibit duplicates in fold-packages.

* gnu/packages.scm (fold2): New procedure.
  (fold-packages): Rework to suppress duplicates.
---
 gnu/packages.scm |   36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/gnu/packages.scm b/gnu/packages.scm
index 792fe44..ee661d7 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -20,6 +20,7 @@
   #:use-module (guix packages)
   #:use-module (guix utils)
   #:use-module (ice-9 ftw)
+  #:use-module (ice-9 vlist)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-39)
@@ -106,20 +107,33 @@
   (false-if-exception (resolve-interface name
   (package-files)))
 
+(define (fold2 f seed1 seed2 lst)
+  (if (null? lst)
+  (values seed1 seed2)
+  (call-with-values
+  (lambda () (f (car lst) seed1 seed2))
+(lambda (seed1 seed2)
+  (fold2 f seed1 seed2 (cdr lst))
+
 (define (fold-packages proc init)
   "Call (PROC PACKAGE RESULT) for each available package, using INIT as
 the initial value of RESULT."
-  (fold (lambda (module result)
-  (fold (lambda (var result)
-  (if (package? var)
-  (proc var result)
-  result))
-result
-(module-map (lambda (sym var)
-  (false-if-exception (variable-ref var)))
-module)))
-init
-(package-modules)))
+  (identity   ; discard second return value
+   (fold2 (lambda (module result seen)
+(fold2 (lambda (var result seen)
+ (if (and (package? var)
+  (not (vhash-assq var seen)))
+ (values (proc var result)
+ (vhash-consq var #t seen))
+ (values result seen)))
+   result
+   seen
+   (module-map (lambda (sym var)
+ (false-if-exception (variable-ref var)))
+   module)))
+  init
+  vlist-null
+  (package-modules
 
 (define* (find-packages-by-name name #:optional version)
   "Return the list of packages with the given NAME.  If VERSION is not #f,
-- 
1.7.10.4

Re: [PATCH] Build newest versions unless specified, and upgrades.

[Mark H Weaver]

I wrote:
> Here's a preliminary patch that does two things:
>
> * Changes 'guix-build' and 'guix-package --install' so that only the
>   newest packages will be considered (unless a version number is
>   specified).
>
> * Implements 'guix-package --upgrade'.
>
> Although I'm not aware of any functional problems with this code, I'm
> not entirely pleased with its organization.  Nonetheless, I wanted to
> make it available for early testing and comments.
>
> I welcome suggestions on how to improve this code.

Sorry, that patch had a problem in guix-build.  Here's a fixed version.

 Mark

>From c3820d291cdc40cc58abebf8ca10332e51ebead1 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 12 Feb 2013 01:24:21 -0500
Subject: [PATCH] Build newest versions unless specified, and implement
 upgrades.

* gnu/packages.scm (find-newest-available-packages):
  New exported procedure.

* guix-build.in (newest-available-packages, find-best-packages-by-name):
  New procedures.
  (find-package): Use find-best-packages-by-name, to guarantee that
  if a version number is not specified, only the newest versions will
  be considered.

* guix-package.in (%options): Add --upgrade/-u option.
  (newest-available-packages, find-best-packages-by-name, upgradeable?):
  New procedures.
  (find-package): Use find-best-packages-by-name, to guarantee that
  if a version number is not specified, only the newest versions will
  be considered.
  (process-actions): Implement upgrade option.
---
 gnu/packages.scm |   24 +-
 guix-build.in|   19 ---
 guix-package.in  |   71 --
 3 files changed, 97 insertions(+), 17 deletions(-)

diff --git a/gnu/packages.scm b/gnu/packages.scm
index 792fe44..04ca840 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -20,6 +20,8 @@
   #:use-module (guix packages)
   #:use-module (guix utils)
   #:use-module (ice-9 ftw)
+  #:use-module (ice-9 vlist)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-39)
@@ -28,7 +30,8 @@
 %patch-directory
 %bootstrap-binaries-path
 fold-packages
-find-packages-by-name))
+find-packages-by-name
+find-newest-available-packages))
 
 ;;; Commentary:
 ;;;
@@ -137,3 +140,22 @@ then only return packages whose version is equal to VERSION."
(cons package result)
result))
  '()))
+
+(define (find-newest-available-packages)
+  "Return a vhash with elements of the form
+  (name newest-version newest-package ...)
+where the preferred package is listed first."
+
+  ;; FIXME: Currently, the preferred package is whichever one
+  ;; was found last by 'fold-packages'.  Find a better solution.
+  (fold-packages (lambda (p r)
+   (let ((name(package-name p))
+ (version (package-version p)))
+ (match (vhash-assoc name r)
+   ((_ newest-so-far . pkgs)
+(case (version-compare version newest-so-far)
+  ((>) (vhash-cons name `(,version ,p) r))
+  ((=) (vhash-cons name `(,version ,p ,@pkgs) r))
+  ((<) r)))
+   (#f (vhash-cons name `(,version ,p) r)
+ vlist-null))
diff --git a/guix-build.in b/guix-build.in
index 29241c7..607a4bd 100644
--- a/guix-build.in
+++ b/guix-build.in
@@ -47,12 +47,14 @@ exec "${GUILE-@GUILE@}" -c "$startup" "@guilemoduledir@" "$0" "$@"
   #:use-module (guix utils)
   #:use-module (ice-9 format)
   #:use-module (ice-9 match)
+  #:use-module (ice-9 vlist)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-11)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-37)
-  #:autoload   (gnu packages) (find-packages-by-name)
+  #:autoload   (gnu packages) (find-packages-by-name
+   find-newest-available-packages)
   #:export (guix-build))
 
 (define %store
@@ -206,13 +208,24 @@ Build the given PACKAGE-OR-DERIVATION and return their output paths.\n"))
  root (strerror (system-error-errno args)))
  (exit 1)
 
+  (define newest-available-packages
+(memoize find-newest-available-packages))
+
+  (define (find-best-packages-by-name name version)
+(if version
+(find-packages-by-name name version)
+(match (vhash-assoc name (newest-available-packages))
+  ((_ version pkgs ...) pkgs)
+  (#f '()
+
   (define (find-package request)
 ;; Return a package matching REQUEST.  REQUEST may be a package
 ;; name, or a package name followed by a hyphen and a version

Guile reader package names are problematic

[Mark H Weaver]

Hi Ludovic,

In commit d9d466ddff2091f4b1f94599335b5947a17def2c, you added the
following packages:

  guile-reader-for-guile-1.8.8
  guile-reader-for-guile-2.0.7

The "1.8.8" and "2.0.7" are actually part of the package names (both of
these packages are at version 0.6).

Unfortunately, this means that these packages cannot be referenced using
the guix command-line tools, because 'package-name->name+version'
assumes that "1.8.8" or "2.0.7" is the version number, and that the
package name is "guile-reader-for-guile".  It then fails to find any
package of that name.

How do you suppose this should be fixed?

  Mark

Re: w3m: 'license'; error: redefinition of 'struct file_handle'

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Andreas Enge  skribis:
>
>> Additionally, the file matrix.c looks non-free to me:
>> "3.  No charge is made for this software or works derived from it.  
>>   This clause shall not be construed as constraining other software
>>   distributed on the same medium as this software, nor is a
>>   distribution fee considered a charge."
>>
>> So maybe it needs to be patched out, if possible? How come debian contains 
>> the file?
>
> It’s not in http://libreplanet.org/wiki/Software_blacklist so I guess
> it’s a question for the gnu-linux-libre mailing list.  Any volunteer?

I'll ask RMS and report back.  The only reason I'm not certain it's
non-free is because of the words "nor is a distribution fee considered a
charge."

   Thanks,
 Mark

Re: [PATCH] Build newest versions unless specified, and upgrades.

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:
> Other than that, please push!

Okay, I incorporated your suggestions and pushed it.

Thanks,
  Mark

Re: [PATCH] Improve shell script headers and pre-inst-env handling

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:
> Note that I think we’ll most likely have a single ‘guix’ script in the
> near future, so that ‘guix-pull’ can actually update everything: Guix,
> commands, and distro.

Okay, I have another proposal.  I've written a proposed 'guix' script
that's pure Guile code.  The idea is that "guix FOO ARGS ..." augments
the load paths as needed, loads the module (guix scripts guix-FOO) and
then applies the procedure 'guix-FOO' to (ARGS ...)

It also supports "guix-FOO ARGS ..." simply by making 'guix-FOO' a
symlink to 'guix'.

Then we can move all the scripts into guix/scripts/, and remove the
boilerplate shell code from the top of all them.  They become pure guile
modules.  No more shell at all.

What do you think?

Mark

#!@GUILE@ -s
-*- scheme -*-
!#
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2013 Mark H Weaver 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(use-modules (ice-9 regex))

(let ()
  (define-syntax-rule (push! elt v) (set! v (cons elt v)))

  (define config-lookup
(let ((config '(("prefix" . "@prefix@")
("datarootdir". "@datarootdir@")
("guilemoduledir" . "@guilemoduledir@")))
  (var-ref-regexp (make-regexp "\\$\\{([a-z]+)\\}")))
  (define (expand-var-ref match)
(lookup (match:substring match 1)))
  (define (expand str)
(regexp-substitute/global #f var-ref-regexp str
  'pre expand-var-ref 'post))
  (define (lookup name)
(expand (assoc-ref config name)))
  lookup))

  (define (maybe-augment-load-paths!)
(unless (getenv "GUIX_UNINSTALLED")
  (let ((module-dir (config-lookup "guilemoduledir")))
(push! module-dir %load-path)
(push! module-dir %load-compiled-path

  (define (run-script name args)
(let* ((symbol (string->symbol name))
   (module (resolve-interface `(guix scripts ,symbol)))
   (script (module-ref module symbol)))
  (apply script args)))

  (define (main arg0 . args)
(setlocale LC_ALL "")  ; XXX Is there a reason not to do this?
(maybe-augment-load-paths!)
(let ((cmd (basename arg0)))
  (cond ((string-prefix? "guix-" cmd)
 (run-script cmd args))
((not (null? args))
 (run-script (string-append "guix-" (car args))
 (cdr args)))
(else
 ;; TODO: Dynamically generate a summary of available commands.
 (format (current-error-port)
 "Usage: guix  []~%")
 (exit 1)

  (apply main (command-line)))

Re: Guile reader package names are problematic

[Mark H Weaver]

Andreas Enge  writes:
> How about naming them "guile-reader" with a version number of
> 0.6-1.8.8 and 0.6-2.0.7, or the other way round 1.8.8-0.6 and
> 2.0.7-0.6?

We can't do this, because it would break the version-number comparison
logic.  One option would be to change the dash to something else.
Maybe tilde?

  guile-reader-for-guile~1.8.8
  guile-reader-for-guile~2.0.7

Even if we decide to remove 'guile-reader-for-guile-1.8.8', there will
surely be other cases like this, so it would be useful to decide on a
policy.

 Mark

Re: [PATCH] Replace individual scripts with master 'guix' script

[Mark H Weaver]

Hi Ludovic,

Thanks for the quick feedback.  I've attached a new patch that
incorporates almost all of your suggestions, and also includes a basic
find/replace in the manual (though more work is needed there).

>   • Remove the ‘guix-’ prefix from module names, so
> guix/scripts/build.scm instead of guix/scripts/guix-build.scm;
>
>   • No need to add .gitignore to change logs;
>
>   • Make sure to update po/POTFILES.in;

Done.

>   • Arrange commits such that everything always works; thus, update
> tests to use the new command names in the same commit that changes
> those commands.

Indeed.  The reason I initially kept the test updates separated is
because I wasn't sure if we wanted to continue supporting the old style
"guix-package" and friends.  However, we agreed on IRC to abandon the
old style, so that's what this patch now does.

>   (install-locale)
>   (textdomain "guix")
>   (setvbuf (current-output-port) _IOLBF)
>   (setvbuf (current-error-port) _IOLBF)

Done.

> We also need to support --version and --help here, using SRFI-37 as is
> the current scripts.

I now support --version and --help, but I didn't see how to use SRFI-37
in the main driver, because it doesn't know the full set of options to
accept.

> + (format (current-error-port)
> + "Usage: guix  []~%")
>
> Messages must be i18n’d, and use standard GNU notation:
>
>   Usage: guix COMMAND ARGS...

Done.

Here's the new patch, compressed this time.  Please let me know what you
think.  I think this might be about ready to push.

 Mark



0001-Replace-individual-scripts-with-master-guix-script.patch.gz
Description: [PATCH] Replace individual scripts with master 'guix' script

Re: w3m: 'license'; error: redefinition of 'struct file_handle'

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Andreas Enge  skribis:
>
>> Additionally, the file matrix.c looks non-free to me:
>> "3.  No charge is made for this software or works derived from it.  
>>   This clause shall not be construed as constraining other software
>>   distributed on the same medium as this software, nor is a
>>   distribution fee considered a charge."
>>
>> So maybe it needs to be patched out, if possible? How come debian contains 
>> the file?
>
> It’s not in http://libreplanet.org/wiki/Software_blacklist so I guess
> it’s a question for the gnu-linux-libre mailing list.  Any volunteer?

I asked RMS, and he thinks that this clause is okay because it says a
"distribution fee" is okay and does not limit the amount.  Thus, what it
prohibits is a fee for the right to use the program, which is okay.

He was actually slightly more concerned about whether it allowed
distribution of modified versions:

  Everyone is granted permission to copy, modify and redistribute

Overall, he said that with its most natural intepretation, it is a free
software license, but that it is not clear.  He asked me to attempt to
contact the library authors for clarification, but in the meantime I
think we can consider this license acceptable.

Apologies for paraphrasing RMS rather than quoting him directly, but I
forgot to ask whether it was okay to publish what he wrote in private
email.

 Mark

Re: w3m: 'license'; error: redefinition of 'struct file_handle'

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> I asked RMS, and he thinks that this clause is okay because it says a
>> "distribution fee" is okay and does not limit the amount.  Thus, what it
>> prohibits is a fee for the right to use the program, which is okay.
>
> Great, thanks for investigating.
>
>> Apologies for paraphrasing RMS rather than quoting him directly, but I
>> forgot to ask whether it was okay to publish what he wrote in private
>> email.
>
> In the future I think it’s better if we work with the gnu-linux-libre
> list, where there are knowledgeable people lurking (from gNewSense,
> Trisquel, etc.), as it would allow us to share efforts with them (and
> vice versa ;-)).

I did not intend to preempt that suggestion, but rather to augment it.
I wanted to know RMS's opinion, but I want to hear the opinions of other
knowledgeable people as well.  Any volunteers to raise this question on
the gnu-linux-libre list?

Still, until we hear otherwise, I think we can tentatively assume that
the license is okay, and proceed with the w3m packaging.

  Mark

Re: Boot-to-Guile!

[Mark H Weaver]

Wow.  This is very exciting work, Ludovic.
You make our lives brighter :)

  Mark

IMPORTANT: guix-package -> guix package

[Mark H Weaver]

Hello all,

In git, the five scripts 'guix-package', 'guix-gc', 'guix-build',
'guix-download' and 'guix-import' have been replaced with the single
script 'guix'.  The new usage replaces 'guix-package' with 'guix
package', and more generally 'guix-COMMAND' with 'guix COMMAND'.

After pulling, please delete the old scripts from your build directory
to avoid running them by mistake.  Please delete them from ${prefix}/bin
after "make install" as well.

Thanks,
  Mark

Re: Guile reader package names are problematic

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> Andreas Enge  writes:
>>> How about naming them "guile-reader" with a version number of
>>> 0.6-1.8.8 and 0.6-2.0.7, or the other way round 1.8.8-0.6 and
>>> 2.0.7-0.6?
>>
>> We can't do this, because it would break the version-number comparison
>> logic.  One option would be to change the dash to something else.
>> Maybe tilde?
>>
>>   guile-reader-for-guile~1.8.8
>>   guile-reader-for-guile~2.0.7
>
> Good idea.

Unfortunately, tilde seems to be forbidden in package names.

  mhw@tines:~/guix$ ./pre-inst-env guix package -i guile-reader-for-guile~2.0.7
  error: build failed: invalid character `~' in name 
`guile-reader-for-guile~2.0.7-0.6-guile-builder'

How about using underscore instead?  That seems to be allowed.

   guile-reader-for-guile_1.8.8
   guile-reader-for-guile_2.0.7

   Mark

Re: Bug: missing interface for module (gnutls)

[Mark H Weaver]

Nikita Karetnikov  writes:
> This commit is buggy.

I don't see how this could have anything to do with my commit.  (gnutls)
needs to be in Guile's load path when (guix build download) is compiled,
and in your case it apparently isn't.  That must be a problem with your
specific configuration.  I think the reason it came up now is because my
commit changed configure.ac, which forced a more complete rebuild than
usual.

My commit changes the code that sets the guile load path from within the
'guix' script.  However, (gnutls) is not part of guix and therefore it
is not guix's responsibility to ensure that it is in the guile load
path.  Furthermore, this didn't happen when you ran the 'guix' script,
but rather while compiling (guix build download) using guild.  The code
I changed has nothing to do with that.

 Mark

Problem with texinfo 5.0 package

[Mark H Weaver]

Hi Ludovic,

Regarding commit a24b75d8e1753da629ecf945f4022eee4c340aed:

The built texinfo 5.0 packages contain a few uses of 'perl' that are not
pointing to a specific version in /nix/store:

./bin/pod2texi:1:#!/nix/store/777jas1fcgc38hmvq6lq1sa9k67f10kl-coreutils-8.20/bin/env
 perl
./bin/texi2dvi:1437:  perl -pe 's<\\documentclass(?:\[.*\])?{.*}>
./bin/texi2dvi:1544:  perl -pi -e 's/[ \t]+$//g' "$out_base"*;;
./bin/texi2any:1:#!/nix/store/777jas1fcgc38hmvq6lq1sa9k67f10kl-coreutils-8.20/bin/env
 perl 

Regards,
  Mark

Re: Problem with texinfo 5.0 package

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> The built texinfo 5.0 packages contain a few uses of 'perl' that are not
>> pointing to a specific version in /nix/store:
>
> Yes, I know, but since in ‘core-updates’ we’ll change ‘patch-shebang’ to
> handle /usr/bin/env specially, that’ll work well there.

Okay.  In the meantime, 'mailutils' fails to build because of this
problem:

--8<---cut here---start->8---
  CCLD   libmu_scm.la
  GENmailutils.scm
  GENguile-procedures.txt
/nix/store/777jas1fcgc38hmvq6lq1sa9k67f10kl-coreutils-8.20/bin/env: perl: No 
such file or directory
WARNING: `makeinfo' is missing on your system.  You should only need it if
 you modified a `.texi' or `.texinfo' file, or any other file
 indirectly affecting the aspect of the manual.  The spurious
 call might also be the consequence of using a buggy `make' (AIX,
 DU, IRIX).  You might want to install the `Texinfo' package or
 the `GNU make' package.  Grab either from any GNU archive site.
make[3]: *** [guile-procedures.txt] Error 1
make[3]: Leaving directory 
`/tmp/nix-build-mailutils-2.2.drv-0/mailutils-2.2/libmu_scm'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/tmp/nix-build-mailutils-2.2.drv-0/mailutils-2.2/libmu_scm'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/nix-build-mailutils-2.2.drv-0/mailutils-2.2'
make: *** [all] Error 2
phase `build' failed after 88 seconds
builder for `/nix/store/39031b9d3w6j9iwhsnxjfd0lhga1z61g-mailutils-2.2.drv' 
failed with exit code 1
error: build failed: build of 
`/nix/store/39031b9d3w6j9iwhsnxjfd0lhga1z61g-mailutils-2.2.drv' failed
--8<---cut here---end--->8---

I don't care that much, but that's how the problem came to my attention.

Regards,
  Mark

Re: Problem with texinfo 5.0 package

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> carl hansen  skribis:
>
>> FYI When I recently upgraded to texinfo-5, I had to make a soft link
>> ln -s  texi2any  makeinfo
>> The link was supposed to be made in the package, but it wasn't. It
>> might be relevant to you.
>
> I just installed (from Guix) it and it did create the symlink.

It created the symlink for me as well.

 Mark

Re: Problem with texinfo 5.0 package

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> The built texinfo 5.0 packages contain a few uses of 'perl' that are not
>> pointing to a specific version in /nix/store:
>
> Yes, I know, but since in ‘core-updates’ we’ll change ‘patch-shebang’ to
> handle /usr/bin/env specially, that’ll work well there.

Unless I'm mistaken, that will fix only 2 out of 4 of the occurrences:

./bin/pod2texi:1:#!/nix/store/777jas1fcgc38hmvq6lq1sa9k67f10kl-coreutils-8.20/bin/env
 perl
./bin/texi2dvi:1437:  perl -pe 's<\\documentclass(?:\[.*\])?{.*}>
./bin/texi2dvi:1544:  perl -pi -e 's/[ \t]+$//g' "$out_base"*;;
./bin/texi2any:1:#!/nix/store/777jas1fcgc38hmvq6lq1sa9k67f10kl-coreutils-8.20/bin/env
 perl 

Mark

Re: #!/usr/bin/env perl

[Mark H Weaver]

Hi Andreas,

Andreas Enge  writes:
> (has-env (string-suffix? "/env" interp))

I think we might want to make this test more restrictive.  I'm looking
at a package (guile-figl) that includes an 'env' script in its build
directory, analogous to 'pre-inst-env' in Guix.  This makes me worry
that the test above will have false positives.

In practice, the path used is (almost?) always "/usr/bin/env".
I suspect it would be safer to check for that exact string.

What do you think?

Mark

Re: Toward 0.2

[Mark H Weaver]

Nikita Karetnikov  writes:

> I'm attaching a patch.
>
> It's a separate file; if I add these lines
>
>#:use-module (guix packages)
>#:use-module (guix store)
>
> to 'guix/build/utils.scm', they will raise the following error on
> 'make'.

Based on the backtrace below, it looks like you tried to add those to
guix/utils.scm, not guix/build/utils.scm.  It failed because it resulted
in a circular dependency between modules.

  (guix utils) -> (guix packages) -> (guix derivations) -> (guix utils)

Circular dependencies are not always fatal in Guile, but they can be
when one of the modules depends on a *macro* from another module in the
cycle.  In this case, (guix derivations) uses the 'memoize' macro from
(guix utils).

[Adds to Guile TODO list: better error messages in cases like this]

> Also, 'bin-location' and 'chmod' are not safe.  It can be solved with
> 'file-exists?'

I don't know what the issue is here (and don't have time now to figure
it out), but the idea that 'file-exists?' can make anything safe is
setting off warning bells in my head, because it sounds like a
TOCTTOU[1] race condition: someone else may change the filesystem
between your 'file-exists?' check and whatever you do that depends on
that check for safety.

 Regards,
   Mark

[1] http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use

Bad hash for hop-2.4.0.tar.gz

[Mark H Weaver]

On my system, attempts to build hop result in the following error:

output path `/nix/store/l4jyrfyx8nr3sy6j20s8znk2aa2hpw84-hop-2.4.0.tar.gz' 
should have sha256 hash `04fhy5jp9lq12fmdqfjzj1w32f7nxc80fagbj7pfci7xh86nm2c5', 
instead has `1v2r4ga58kk1sx0frn8qa8ccmjpic9csqzpk499wc95y9c4b1wy3'

I tried downloading 
manually with wget, and got the same file that guix had downloaded.

  Mark

Download progress interleaved with compile output

[Mark H Weaver]

I recently installed a large number of packages in a single "guix
package -i" command, and in the resulting transcript I see download
progress reports interleaved with compile output, e.g.:

--8<---cut here---start->8---
gcc -DHAVE_CONFIG_H -I. -I../include  -I ../src -I ../include -I ../tools  
-Wall -W   -I/nix/store/zs7rsahwk9hmfypgazw1fkk2kg6rymvp-libogg-1.3.0/include   
-g -O2 -MT katalyzer-kutil.o -MD -MP -MF .deps/katalyzer-kutil.Tpo -c -o 
katalyzer-kutil.o `test -f 'kutil.c' || echo './'`kutil.c
http://mirror.yongbok.net/.../guile-ncurses-1.3.tar.gz   18.0% of 712.2 KiBmv 
-f .deps/katalyzer-kutil.Tpo .deps/katalyzer-kutil.Po
gcc -DHAVE_CONFIG_H -I. -I../include  -I ../src -I ../include -I ../tools  
-Wall -W   -I/nix/store/zs7rsahwk9hmfypgazw1fkk2kg6rymvp-libogg-1.3.0/include   
-g -O2 -MT katalyzer-kstream.o -MD -MP -MF .deps/katalyzer-kstream.Tpo -c -o 
katalyzer-kstream.o `test -f 'kstream.c' || echo './'`kstream.c
mv -f .deps/katalyzer-kstream.Tpo .deps/katalyzer-kstream.Po
--8<---cut here---end--->8---

Is this intentional?

  Mark

[PATCH] gnu: gprolog: Update to 1.4.3 and download from GNU mirrors

[Mark H Weaver]

I was unable to build gprolog, because it was no longer available at the
specified URL <http://www.gprolog.org/gprolog-1.4.2.tar.gz>.  Apparently
only the newest version is available there.  Older versions are moved to
a different URL <http://gprolog.univ-paris1.fr/old_versions/>, which
does *not* have the latest version.

Since gprolog.org does not seem to provide stable URLs for their newest
tarballs, I suggest that we use the GNU mirrors instead.  The attached
patch does this, and also upgrades gprolog to 1.4.3.

What do you think?

  Mark


>From 60b284848f722f3faa3e1a5e876b712e8b09960c Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Sun, 21 Apr 2013 02:54:56 -0400
Subject: [PATCH] gnu: gprolog: Update to 1.4.3 and download from GNU mirrors

* gnu/packages/gprolog.scm (gprolog): Update to 1.4.3.
  Download from GNU mirrors.
---
 gnu/packages/gprolog.scm |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/gprolog.scm b/gnu/packages/gprolog.scm
index c362a7b..7f7cbe0 100644
--- a/gnu/packages/gprolog.scm
+++ b/gnu/packages/gprolog.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013 Nikita Karetnikov 
+;;; Copyright © 2013 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -25,15 +26,15 @@
 (define-public gprolog
   (package
 (name "gprolog")
-(version "1.4.2")
+(version "1.4.3")
 (source
  (origin
   (method url-fetch)
-  (uri (string-append "http://www.gprolog.org/gprolog-";
-  version ".tar.gz"))
+  (uri (string-append "mirror://gnu/gprolog/gprolog-" version
+  ".tar.gz"))
   (sha256
(base32
-"0y25c2gwz41i6g28qyfjklrmanzgk0c8cr4jn2s7s8qgd9dnm1fm"
+"16yl6q9ydx9d8lphg9xkk53l1m0fq0kpvrhry8njsxhhncazm4j2"
 (build-system gnu-build-system)
 (arguments
  `(#:phases (alist-cons-before
-- 
1.7.10.4

Updates to be done

[Mark H Weaver]

Which of these can be done on master, and which should be done only on
core-updates?

gnu/packages/groff.scm:32:3: note: using groff-1.22.1 but groff-1.22.2 is 
available upstream
gnu/packages/cdrom.scm:89:3: note: using xorriso-1.2.4 but xorriso-1.2.8 is 
available upstream
gnu/packages/wdiff.scm:28:3: note: using wdiff-1.1.2 but wdiff-1.2.1 is 
available upstream
gnu/packages/smalltalk.scm:27:3: note: using smalltalk-3.2.4 but 
smalltalk-3.2.5 is available upstream
gnu/packages/nano.scm:29:3: note: using nano-2.2.6 but nano-2.3.2 is available 
upstream
gnu/packages/gnupg.scm:35:3: note: using libgpg-error-1.10 but 
libgpg-error-1.11 is available upstream
gnu/packages/gnupg.scm:82:3: note: using libassuan-2.0.3 but libassuan-2.1.0 is 
available upstream
gnu/packages/help2man.scm:27:3: note: using help2man-1.40.8 but help2man-1.41.2 
is available upstream
gnu/packages/base.scm:931:34: note: using guile-2.0.7 but guile-2.0.9 is 
available upstream

Also, is there a reason not to update guile to 2.0.9 in core-updates?

   Mark

Re: Bad hash for hop-2.4.0.tar.gz

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> On my system, attempts to build hop result in the following error:
>>
>> output path
>> /nix/store/l4jyrfyx8nr3sy6j20s8znk2aa2hpw84-hop-2.4.0.tar.gz' should
>> have sha256 hash
>> 04fhy5jp9lq12fmdqfjzj1w32f7nxc80fagbj7pfci7xh86nm2c5', instead has
>> 1v2r4ga58kk1sx0frn8qa8ccmjpic9csqzpk499wc95y9c4b1wy3'
>>
>> I tried downloading <ftp://ftp-sop.inria.fr/indes/fp/Hop/hop-2.4.0.tar.gz>
>> manually with wget, and got the same file that guix had downloaded.
>
> Apparently Manuel sometimes modifies tarballs in-place.  Would you like
> to report it?  I can also try to discuss it with him.

Okay, I sent the following message.

 Mark


--8<---cut here---start->8---
From: Mark H Weaver 
To: h...@lists-sophia.inria.fr
Subject: hop-2.4.0.tar.gz has apparently been modified
Date: Wed, 24 Apr 2013 00:51:44 -0400

It appears that hop-2.4.0.tar.gz has been modified since it was first
made available.  This makes me concerned about a possible security
breach.

Alternatively, perhaps it was intentionally modified in place.  If so,
I'd like to discourage you from continuing this practice.  It thwarts
attempts to authenticate downloads and detect trojan horses.  It teaches
people not to worry if the tarball they downloaded is not the same as
the one their friend downloaded with the same name.

Several existing projects that automatically download and compile
software, such as source-based GNU/Linux distributions and the BSD ports
collections, include cryptographic hashes of the downloaded files in
their metadata.  This is an important security practice, but it fails
when you change your tarballs in place.  In fact, this is how I learned
that hop-2.4.0.tar.gz had changed.

For these reasons, I'd strongly encourage you to never change a tarball
once it has been made publicly available.  Always increment the version
number.  Integers are cheap and plentiful, are they not?

 Regards,
   Mark
--8<---cut here---end--->8---

Assertion failure while building libtool

[Mark H Weaver]

I did a clean rebuild of guix from git master (make clean; ./bootstrap;
make), and then attempted to upgrade all packages.  After several
successful builds, the daemon printed this:

guix-daemon: nix/libstore/local-store.cc:526: void 
nix::canonicalisePathMetaData_(const Path&, uid_t, nix::InodesSeen&): Assertion 
`!st.st_mode)) & 017) == (004))' failed.

Here are the last several lines of output from the console where I ran
the upgrade:

--8<---cut here---start->8---
test -z 
"/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2/share/man/man1" || 
/nix/store/2p8di9qlp6l5z7bq5qgnpx99vl8rim2a-coreutils-8.21/bin/mkdir -p 
"/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2/share/man/man1"
 /nix/store/2p8di9qlp6l5z7bq5qgnpx99vl8rim2a-coreutils-8.21/bin/install -c -m 
644 ./doc/libtool.1 ./doc/libtoolize.1 
'/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2/share/man/man1'
make[3]: Leaving directory `/tmp/nix-build-libtool-2.4.2.drv-0/libtool-2.4.2'
make[2]: Leaving directory `/tmp/nix-build-libtool-2.4.2.drv-0/libtool-2.4.2'
make[1]: Leaving directory `/tmp/nix-build-libtool-2.4.2.drv-0/libtool-2.4.2'
phase `install' succeeded after 1 seconds
starting phase `patch-shebangs'
phase `patch-shebangs' succeeded after 0 seconds
starting phase `strip'
stripping binaries in 
"/nix/store/g1wl3hkiykindg7xjl05r57vim6jsyki-libtool-2.4.2-bin/bin" with flags 
("--strip-debug")
strip:/nix/store/g1wl3hkiykindg7xjl05r57vim6jsyki-libtool-2.4.2-bin/bin/libtool:
 File format not recognized
strip:/nix/store/g1wl3hkiykindg7xjl05r57vim6jsyki-libtool-2.4.2-bin/bin/libtoolize:
 File format not recognized
stripping binaries in 
"/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2/lib" with flags 
("--strip-debug")
strip:/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2/lib/libltdl.la: 
File format not recognized
phase `strip' succeeded after 0 seconds
Backtrace:
In ice-9/boot-9.scm:
 157: 13 [catch #t # ...]
In unknown file:
   ?: 12 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 10 [eval # #]
In ice-9/boot-9.scm:
2320: 9 [save-module-excursion #]
3966: 8 [#]
In unknown file:
   ?: 7 [load-compiled/vm 
"/home/mhw/.cache/guile/ccache/2.0-LE-8-2.0/home/mhw/guix/scripts/guix.go"]
In guix/ui.scm:
 462: 6 [run-guix-command package "--upgrade"]
In ice-9/boot-9.scm:
 157: 5 [catch srfi-34 # ...]
In guix/scripts/package.scm:
 929: 4 [#]
 824: 3 [process-actions (# # # #)]
In guix/store.scm:
 474: 2 [build-derivations # #]
 325: 1 [process-stderr #]
In guix/serialization.scm:
  49: 0 [read-int #]

guix/serialization.scm:49:4: In procedure read-int:
guix/serialization.scm:49:4: In procedure bv-u32-ref: Wrong type argument in 
position 1 (expecting bytevector): #
--8<---cut here---end--->8---

This is current git master (v0.2-82-gb2e3dd9) running on Debian Wheezy
with Guile 2.0.9.  I ran the daemon with the command:

 ./pre-inst-env guix-daemon --no-substitutes --build-users-group=guix-builder

The upgrade command was: ./pre-inst-env guix package --upgrade

Any idea what went wrong here?

  Mark

Re: Assertion failure while building libtool

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> I did a clean rebuild of guix from git master (make clean; ./bootstrap;
>> make), and then attempted to upgrade all packages.  After several
>> successful builds, the daemon printed this:
>>
>> guix-daemon: nix/libstore/local-store.cc:526: void
>> nix::canonicalisePathMetaData_(const Path&, uid_t,
>> nix::InodesSeen&): Assertion `!st.st_mode)) & 017) ==
>> (004))' failed.
>
> Yes, this is a daemon bug pending a fix:
> <https://github.com/NixOS/nix/issues/122>.
>
> In the meantime, you can hopefully work around it by deleting the
> already-present output–i.e., by running either:
>
>   guix gc --delete /nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2

This command fails because there are still references:

--8<---cut here---start->8---
mhw@tines:~/guix$ ./pre-inst-env guix gc --delete 
/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2
finding garbage collector roots...
removing stale temporary roots file `/usr/local/var/nix/temproots/18019'
guix gc: error: build failed: cannot delete path 
`/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2' since it is still 
alive
mhw@tines:~/guix$ ./pre-inst-env guix gc --references 
/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2
/nix/store/gk8dpqzml7n6ah0nxi59hrpwjaqqml64-gcc-4.7.3
/nix/store/wbsypglflcy7fi08h4finffjy9mqzh12-libtool-2.4.2
/nix/store/ybdv89csf4sn7wbmgj9kfjjk1b0mhrlb-glibc-2.17
/nix/store/zch43a56qdchdw0xm3lwpr8ydg8ksx25-bash-4.2
--8<---cut here---end--->8---

> or
>
>   guix gc --delete 
> /nix/store/g1wl3hkiykindg7xjl05r57vim6jsyki-libtool-2.4.2-bin

This command succeeds, but does not solve the problem for me.

Any other suggestions?

 Thanks,
   Mark

[PATCH] gnu: subversion: Download from apache archive site

[Mark H Weaver]

Attempts to build subversion fail because the version currently in Guix
(1.7.8) is no longer on the apache mirror network.  It turns out that
the apache mirrors keep only a couple of recent versions.  This patch
changes the download location to archive.apache.org, which keeps old
versions around.

What do you think?

  Mark


>From 06d670d362c140e46781bc2348fb85d822986d19 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Fri, 7 Jun 2013 21:42:33 -0400
Subject: [PATCH] gnu: subversion: Download from apache archive site.

* gnu/packages/subversion.scm (subversion): Download from archive.apache.org,
  where versions are kept for a longer period of time.  Previously, we
  downloaded from the mirrors, which keep only the most recent versions.
---
 gnu/packages/subversion.scm |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/subversion.scm b/gnu/packages/subversion.scm
index 009b341..28ddc42 100644
--- a/gnu/packages/subversion.scm
+++ b/gnu/packages/subversion.scm
@@ -34,7 +34,7 @@
 (version "1.7.8")
 (source (origin
  (method url-fetch)
- (uri (string-append "mirror://apache/subversion/subversion-"
+ (uri (string-append "https://archive.apache.org/dist/subversion/subversion-";
  version ".tar.bz2"))
  (sha256
   (base32
-- 
1.7.10.4

Re: Assertion failure while building libtool

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:
> Could you rebuild the daemon with that patch, relaunch the libtool
> build, and check if it fixes the problem?

Works for me!  Thanks :)

Mark

bug#15182: module-init-tools-3.16 no longer available from kernel.org

[Mark H Weaver]

FYI, module-init-tools fails to build from source, because
module-init-tools-3.16 is no longer present on the kernel.org mirror
network.  This seems rather strange, given that 3.16 was released over
two years ago, and all the earlier versions are present.

  Mark

bug#15187: module-init-tools-3.16-man no longer available from distfiles.gentoo.org

[Mark H Weaver]

The 'module-init-tools' recipe tries to download
module-init-tools-3.16-man.tar.bz2 from distfiles.gentoo.org, but it's
no longer there.

  Mark

bug#15182: module-init-tools-3.16 no longer available from kernel.org

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> This seems rather strange, given that 3.16 was released over
>> two years ago, and all the earlier versions are present.
>
> Indeed.  I haven’t found anything mentioning the removal of that
> version, but it’d be great to know more about that...

It appears that 'module-init-tools' is now a dead package, and its
successor is 'kmod', or so says a gentoo dev here:

https://forums.gentoo.org/viewtopic-t-929906-start-0.html

 Mark

bug#15194: hop FTBFS

[Mark H Weaver]

Using guix from git 5d9cd70721aa8256f333f76c76cecc6593b6b293, hop fails
to build from source.  Here's the tail of the make transcript:

--8<---cut here---start->8---
bigloo -O2 -fsharing -Wall -wslots -L 
/tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/lib -srfi enable-threads -srfi 
enable-avahi -cc gcc -copt "-O3  
-I/nix/store/l4389c6kqs5x339ai7rah7ywaxm97hcs-bigloo-4.0b/lib/bigloo/4.0b" 
-srfi hop-dynamic  -copt -fPIC -L /tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/lib 
-unsafe -safee -c xml.scm -o o/xml.o

File "xml.scm", line 859, character 33481:
# (let ((js-attr (xml-attribute-encode (xml-tilde->statement obj
#^
*** ERROR:xml-tilde->attribute
Unbound variable -- xml-attribute-encode

File "xml.scm", line 646, character 24544:
#   (let ((a (xml-attribute-encode attr)))
#^
*** ERROR:xml-write-attribute1293
Unbound variable -- xml-attribute-encode

File "xml.scm", line 650, character 24709:
# (display (xml-attribute-encode attr) p)))
#  ^
*** ERROR:xml-write-attribute1293
Unbound variable -- xml-attribute-encode
3 errors occured, ending ...
make[1]: *** [o/xml.o] Error 255
make[1]: Leaving directory `/tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/runtime'
make: *** [lib] Error 2
--8<---cut here---end--->8---

bug#15194: hop FTBFS

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> It turns out Hop & Bigloo have to be upgraded in lockstep.  I believe
> a new Hop version is around the corner, so I’m tempted to just wait
> for that.
>
> WDYT?

I think we should find a solution that doesn't lead to the 'hop' build
being broken every time 'bigloo' is upgraded before 'hop'.

An obvious solution would be to keep two versions of 'bigloo': the
latest release, and the release that corresponds to the latest release
of 'hop'.  Hopefully these would be the same most of the time.

What do you think?

  Mark

bug#15194: hop FTBFS

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> It turns out Hop & Bigloo have to be upgraded in lockstep.  I believe
>>> a new Hop version is around the corner, so I’m tempted to just wait
>>> for that.
>>>
>>> WDYT?
>>
>> I think we should find a solution that doesn't lead to the 'hop' build
>> being broken every time 'bigloo' is upgraded before 'hop'.
>>
>> An obvious solution would be to keep two versions of 'bigloo': the
>> latest release, and the release that corresponds to the latest release
>> of 'hop'.  Hopefully these would be the same most of the time.
>
> Yes, that sounds like a plan.  And hopefully the “old” Bigloo would just
> differ by its ‘version’ and ‘source’ fields, which is easily handled.
>
> Would you like to propose a patch?

I don't actually use 'bigloo' or 'hop' myself, and right now I have my
hands full with a lot of pending work for Guile, so I'd prefer to let
someone else take care of this.  I only know about this problem because
I've been building as many Guix packages as possible, for testing
purposes.

 Regards,
   Mark

bug#15286: Add the current directory as GUILE_LOAD_PATH by default

[Mark H Weaver]

Arne Babenhauserheide  writes:

> Am Samstag, 14. September 2013, 14:13:17 schrieb Ludovic Courtès:
>> > I now learned, that with guile I can use 
>> >
>> > guile -L .
>> >
>> > which actually does what I need.
>> >
>> > Providing this in guix would be consistent with guile and it would make it 
>> > really easy to select overlays.
>> 
>> If this is a ‘-L’ option, then I’d say no.  After all, Guix is just
>> another Guile library, and as such it must not fiddle with the search
>> path.
>
> Isn’t guix a standalone program?

It's both a library and a standalone program.

If you're using one or more overlays, isn't it easier to set
GUILE_LOAD_PATH in your dot files?  I wouldn't want to have to
specify one or more -L arguments every time I use guix.

 Mark

bug#15392: xorg-server FTBFS

[Mark H Weaver]

Hello all,

xorg-server fails to build from source.  See below for the tail of the
build log.  This is with aae4ead8142d4fd7c674a1e6e302f40469f878c6.

Regards,
  Mark


--8<---cut here---start->8---
PASS: input
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of 
xkeyboard-config.

Fatal server error:
Failed to activate core devices.

Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.

FAIL: xtest
PASS: misc
PASS: fixes
PASS: xfree86

1 of 9 tests failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory 
`/tmp/nix-build-xorg-server-1.12.2.drv-0/xorg-server-1.12.2/test'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
`/tmp/nix-build-xorg-server-1.12.2.drv-0/xorg-server-1.12.2/test'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/tmp/nix-build-xorg-server-1.12.2.drv-0/xorg-server-1.12.2/test'
make: *** [check-recursive] Error 1
phase `check' failed after 2 seconds
builder for 
`/nix/store/kgpvhgf4rin7syv7cxid78vmlckqqyfg-xorg-server-1.12.2.drv' failed 
with exit code 1
@ build-failed 
/nix/store/kgpvhgf4rin7syv7cxid78vmlckqqyfg-xorg-server-1.12.2.drv - 1 builder 
for `/nix/store/kgpvhgf4rin7syv7cxid78vmlckqqyfg-xorg-server-1.12.2.drv' failed 
with exit code 1
guix package: error: build failed: build of 
`/nix/store/kgpvhgf4rin7syv7cxid78vmlckqqyfg-xorg-server-1.12.2.drv' failed
--8<---cut here---end--->8---

bug#15392: xorg-server FTBFS

[Mark H Weaver]

Mark H Weaver  writes:

> xorg-server fails to build from source.  See below for the tail of the
> build log.  This is with aae4ead8142d4fd7c674a1e6e302f40469f878c6.

Sorry, the build log tail I posted was actually from a slightly modified
xorg.scm, where I uncommented the build inputs for 'xkbutils' and
'xkeyboard-config' in the 'xorg-server' recipe.  Here's a corrected
version of the build log, using a pristine copy of
aae4ead8142d4fd7c674a1e6e302f40469f878c6.  The only differences are in
the nix hashes.

  Mark


--8<---cut here---start->8---
PASS: input
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of 
xkeyboard-config.

Fatal server error:
Failed to activate core devices.

Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.

FAIL: xtest
PASS: misc
PASS: fixes
PASS: xfree86

1 of 9 tests failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory 
`/tmp/nix-build-xorg-server-1.12.2.drv-0/xorg-server-1.12.2/test'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
`/tmp/nix-build-xorg-server-1.12.2.drv-0/xorg-server-1.12.2/test'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/tmp/nix-build-xorg-server-1.12.2.drv-0/xorg-server-1.12.2/test'
make: *** [check-recursive] Error 1
phase `check' failed after 3 seconds
builder for 
`/nix/store/pjla94lqhahnrb0z2h05sb1zh8dlb9wp-xorg-server-1.12.2.drv' failed 
with exit code 1
@ build-failed 
/nix/store/pjla94lqhahnrb0z2h05sb1zh8dlb9wp-xorg-server-1.12.2.drv - 1 builder 
for `/nix/store/pjla94lqhahnrb0z2h05sb1zh8dlb9wp-xorg-server-1.12.2.drv' failed 
with exit code 1
guix package: error: build failed: build of 
`/nix/store/pjla94lqhahnrb0z2h05sb1zh8dlb9wp-xorg-server-1.12.2.drv' failed
--8<---cut here---end--->8---

bug#15615: Pulseaudio build fails

[Mark H Weaver]

David Thompson  writes:

> On 10/16/2013 09:15 AM, Ludovic Courtès wrote:
>> I think you hit the /dev/shm issue described in a footnote (info "(guix)
>> Setting Up the Daemon").
>>
>> (Of course, re-open this bug if this is not the case.)
>
> That is indeed the case. /dev/shm is a symlink to /run/shm.

[...]

> Have other Debian users worked around this issue?

I successfully built pulseaudio in Guix within Debian Wheezy x86_64, but
/dev/shm is not a symlink on that box.  I'm not sure why it's different
from yours, maybe because I installed systemd?

  Mark

bug#15733: Guile fails to download from poorly-behaved downloads.mysql.com

[Mark H Weaver]

Guile 2.0.9 is unable to download:

  http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.54.tar.gz

apparently because the HTTP server resets the TCP connection at the end,
instead of closing normally.  Here's what I see:

--8<---cut here---start->8---
http://downloads.mysql.com/.../mysql-5.1.54.tar.gz   99.9% of 23117.4 
KiBERROR: In procedure fport_fill_input: Connection reset by peer
--8<---cut here---end--->8---

wget is able to download the file successfully.

Mark

bug#16791: w3m fails to do any SSL certificate checking

[Mark H Weaver]

In Guix, neither w3m nor emacs-w3m warn me when I visit an https URL
that uses a server certificate that is both self-signed and expired.
To make matters worse, if I ask for page information (with the '=' key),
it tells me that the certificate is valid.

On Debian, both w3m and emacs-w3m inform me when an SSL certificate is
invalid in some way, e.g. if it's expired or not signed by a certificate
authority in my trust store.

  Mark

bug#17122: More problems with --no-substitutes

[Mark H Weaver]

This just happened to me on core-updates, on my YeeLoong:

--8<---cut here---start->8---
mhw:~/guix-core-updates$ ./pre-inst-env guix build -S expect lua zip pth bazaar 
ocaml
substitute-binary: Backtrace:
substitute-binary: In ice-9/boot-9.scm:
substitute-binary:  157: 0 [catch #t # ...]
substitute-binary: 
substitute-binary: ice-9/boot-9.scm:157:17: In procedure catch:
substitute-binary: ice-9/boot-9.scm:157:17: In procedure system-async-mark: 
thread has already exited
  C-c C-c
--8<---cut here---end--->8---

No doubt, the "system-async-mark: thread has already exited" is a
problem, but that's not what bothers me.

What disturbs me the most is that 'substitute-binary' is being called at
all.  I'm 100% certain that I passed '--no-substitutes' to guix-daemon.
I use a script to start guix-daemon with the options I prefer, to avoid
mistakes.  I also just checked with 'ps', and indeed '--no-substitutes'
is there on the command line.

It's very important to me to trust that guix-daemon will not accept
binaries from the internet, even if there's a man-in-the-middle that
pretends to be hydra.gnu.org with mips64el binaries for me.

I'm surprised and concerned that we seem to be having so much trouble
making '--no-substitutes' work reliably.  How hard can it be?

Until we get this straightened out, what's the most reliable way for me
to hack the code to ensure that substitutes cannot work, ever?

 Mark

bug#17122: More problems with --no-substitutes

[Mark H Weaver]

I should have pasted the output of the 'ps' command I did immediately
after this error.  Here it is:

--8<---cut here---start->8---
mhw:~/guix-core-updates$ ./pre-inst-env guix build -S expect lua zip pth bazaar 
ocaml
substitute-binary: Backtrace:
substitute-binary: In ice-9/boot-9.scm:
substitute-binary:  157: 0 [catch #t # ...]
substitute-binary: 
substitute-binary: ice-9/boot-9.scm:157:17: In procedure catch:
substitute-binary: ice-9/boot-9.scm:157:17: In procedure system-async-mark: 
thread has already exited
  C-c C-c
mhw:~/guix-core-updates$ ps auxww | grep guix-daemon
mhw   1275  3.0  0.2   5248  2688 pts/0S+   11:40   0:00 grep 
guix-daemon
root 13020  0.0  0.2   7552  2496 tty6 S+   Mar22   0:00 guix-daemon 
--no-substitutes --build-users-group=guix-builder
root 14429  0.1  0.9  15808 10304 ?Ss   Mar26   1:05 guix-daemon 
14425--build-users-group=guix-builder
--8<---cut here---end--->8---

Notice that there's another 'guix-daemon' process here (pid 14429) which
I didn't start, and which has "--build-users-group=guix-builder" but is
missing "--no-substitutes".

Could it be that there's some code in 'guix-daemon' that launches
another 'guix-daemon' subprocess, and which takes care to propagate some
of the options but not all of them?

  Mark

bug#17150: Stale bootstrap/*/guile-2.0.9.tar.xz files are not detected

[Mark H Weaver]

I just realized that my x86_64 and Loongson 3A systems have spent an
enormous amount of time building the new guix master branch based on
outdated bootstrap/*/guile-2.0.9.tar.xz.

The issue is that if you simply "git pull" from a build directory with
older versions of bootstrap/*/guile-2.0.9.tar.xz, although the various
places where the hashes are stored are updated, those new hashes are
never checked against the existing files.  Therefore, you can proceed to
build an entire system based on an outdated bootstrap guile, and with
hashes that don't match what's on hydra and what other people are
building.

It would be good if the hashes were checked even if they are already
present in the build directory.

 Mark

bug#17150: Stale bootstrap/*/guile-2.0.9.tar.xz files are not detected

[Mark H Weaver]

I wrote:
> I just realized that my x86_64 and Loongson 3A systems have spent an
> enormous amount of time building the new guix master branch based on
> outdated bootstrap/*/guile-2.0.9.tar.xz.

Upon further investigation, I see that only MIPS was affected by this
problem in the recent merge of core-updates.  The reason is that the
bootstrap guile for MIPS was updated without changing its version
number, whereas the Intel ones were 2.0.7 before the update.

 Mark

bug#17150: Stale bootstrap/*/guile-2.0.9.tar.xz files are not detected

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> I just realized that my x86_64 and Loongson 3A systems have spent an
>> enormous amount of time building the new guix master branch based on
>> outdated bootstrap/*/guile-2.0.9.tar.xz.
>>
>> The issue is that if you simply "git pull" from a build directory with
>> older versions of bootstrap/*/guile-2.0.9.tar.xz, although the various
>> places where the hashes are stored are updated, those new hashes are
>> never checked against the existing files.  Therefore, you can proceed to
>> build an entire system based on an outdated bootstrap guile, and with
>> hashes that don't match what's on hydra and what other people are
>> building.
>
> Right, ‘guix pull’ doesn’t survive updates of the bootstrap Guile
> tarballs, because it doesn’t try to download it (see ‘build-guix’ in
> guix/build/pull.scm.)  That’s rare in practice, but still a serious
> limitation as you note.  :-/

Hmm, yes, I suppose that "guix pull" is more relevant for typical users,
but actually that's not what I was talking about above.  I was talking
about "git pull" followed by "make".

> There are other things to do in ‘guix pull’, such as authentication, and
> improved bandwidth usage.  For the latter an option would be to resort
> to git, and perhaps for the former too.

Yes, it seems to me that git is a good tool for this job.

  Mark

bug#17122: More problems with --no-substitutes

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> What disturbs me the most is that 'substitute-binary' is being called at
>> all.  I'm 100% certain that I passed '--no-substitutes' to guix-daemon.
>> I use a script to start guix-daemon with the options I prefer, to avoid
>> mistakes.  I also just checked with 'ps', and indeed '--no-substitutes'
>> is there on the command line.
>
> Can you check with current master?  (See in particular commits 968e84a
> and c9e2b0b.)  Does tests/guix-daemon.sh pass?

Yes, it does.

I also hacked 'guix-substitute-binary' to unconditionally raise an error
as soon as it is called (a local patch I intend to keep indefinitely).

Before your recent commits, 'guix-substitute-binary' was always being
called by 'guix build' (unless --no-substitutes was passed to it), but
that seems to be fixed now.  Thanks.

>> I'm surprised and concerned that we seem to be having so much trouble
>> making '--no-substitutes' work reliably.  How hard can it be?
>
> The issue is that guix-daemon.cc glues into Nix’s code, and Nix changed
> the way it handles substituter settings in the last update.

Ah, okay.  I wish this wasn't so fragile, but the new test case you
added helps, as does my hack to raise an error if the substituter is
called, which will immediately alert me to any similar problems in the
future.

> Specifically, in Nix commit dcaea042, the Settings::update method is
> made to re-read $NIX_SUBSTITUTERS:
> <https://github.com/NixOS/nix/commit/dcaea042fc895667bf6f529471ff9f449629774c>;
> then in Guix commit 89faa5c I adjusted guix-daemon.cc accordingly, but
> inadvertently removed the ‘if’ branch that clears the substituter list.
>
> Commit c9e2b0b augments tests/guix-daemon.sh to test guix-daemon
> --no-substitutes.

Thanks very much!  I'm closing this bug now.

 Mark

bug#17198: Octave fails to build

[Mark H Weaver]

In recent master, GNU Octave fails to build on my x86_64 system.
Here's the tail of the log.

 Mark

--8<---cut here---start->8---
libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/crti.o 
/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtbeginS.o
  -Wl,--whole-archive array/.libs/libarray.a cruft/.libs/libcruft.a 
cruft/ranlib/.libs/libranlib.a numeric/.libs/libnumeric.a 
operators/.libs/liboperators.a system/.libs/libsystem.a util/.libs/libutil.a 
../libgnu/.libs/libgnu.a -Wl,--no-whole-archive  -Wl,-rpath 
-Wl,/gnu/store/w5csmfiqjvk94lhiv5qr9gmpn6157l2q-curl-7.35.0/lib -Wl,-rpath 
-Wl,/gnu/store/vm5ihgqdzf0dxcpc76gfwzsd5zxm1bgz-pcre-8.32/lib -Wl,-rpath 
-Wl,/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib -Wl,-rpath 
-Wl,/gnu/store/w5csmfiqjvk94lhiv5qr9gmpn6157l2q-curl-7.35.0/lib -Wl,-rpath 
-Wl,/gnu/store/vm5ihgqdzf0dxcpc76gfwzsd5zxm1bgz-pcre-8.32/lib -Wl,-rpath 
-Wl,/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib 
/gnu/store/w5csmfiqjvk94lhiv5qr9gmpn6157l2q-curl-7.35.0/lib/libcurl.so -llapack 
-lblas -lreadline -lncurses 
-L/gnu/store/vm5ihgqdzf0dxcpc76gfwzsd5zxm1bgz-pcre-8.32/lib 
/gnu/store/vm5ihgqdzf0dxcpc76gfwzsd5zxm1bgz-pcre-8.32/lib/libpcre.so -ldl 
-L/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib 
-L/gnu/store/24zqczrfsvz4y70byvlbiqsc7f8y2f17-perl-5.16.1/lib 
-L/gnu/store/mrgh23r6a5mdfvp2fspv7c1g0r46igfg-ghostscript-9.06.0/lib 
-L/gnu/store/k42ljxy7g8av6jv99bjdh4wcv1ddqpg8-lapack-3.5.0/lib 
-L/gnu/store/hyw9k8jvr9xcggiw72fc6lsq8a9yxcl8-readline-6.3/lib 
-L/gnu/store/zysrgzapv5vzjqrbcz2y3ksi9w651876-ncurses-5.9/lib 
-L/gnu/store/wqnqhp01lpvdhx4a8l1kgcb8bsnz121r-glpk-4.54/lib 
-L/gnu/store/w5csmfiqjvk94lhiv5qr9gmpn6157l2q-curl-7.35.0/lib 
-L/gnu/store/lr1ki5pkxnw25rnd0z17hjl2l2ngysfb-fltk-1.3.2/lib 
-L/gnu/store/v5wr09jhn17ami1k844r6y6n3sy6y0kr-fontconfig-2.10.93/lib 
-L/gnu/store/nw5y8klybqh3wn0xc66b1dfjafs5hybv-freetype-2.4.11/lib 
-L/gnu/store/fjgps76im3kra76qkkyk7abkf15ijrwm-hdf5-1.8.12-lib/lib 
-L/gnu/store/jxyc3cccbkblisknipyafnhycna77mi6-libxft-2.3.1/lib 
-L/gnu/store/9d7kl81a32psj0kp5r0pa33i0r4904j6-libxrender-0.9.7/lib 
-L/gnu/store/0wpcnb6afgssr6dxls04qr3bw049yy24-renderproto-0.11.1/lib 
-L/gnu/store/0x7fb6bwy2krz4mp0bkbbjpmhbs86y12-mesa-8.0.5/lib 
-L/gnu/store/h261a1i9afcvk06rrrsgxr908yhxrzzy-libxxf86vm-1.1.2/lib 
-L/gnu/store/n2f4hyqxrqgl3xzg7pzqllaxgl2vha7p-libxdamage-1.1.3/lib 
-L/gnu/store/3ys5k1i9ylzfl7vqkbygzc5w4p6hhlaq-libx11-1.5.0/lib 
-L/gnu/store/s426x6j1206s8fa6bvziqncpbslq7rfi-libdrm-2.4.33/lib 
-L/gnu/store/42gl7v2zymq1k2digq4ps3v8hfjgniig-glproto-1.4.15/lib 
-L/gnu/store/qszq7kppz86wnk9gbsk76nmh4rlnx13f-libxcb-1.8.1/lib 
-L/gnu/store/0pmpr03aqpa3isv5h46yhfghjlm39bl7-kbproto-1.0.6/lib 
-L/gnu/store/ilk79p1n43wh1f6216i5ml2f3c8pdbhq-libxdmcp-1.1.1/lib 
-L/gnu/store/drfa0rj88xkl3a5mdsg0shvs7l1iw1w0-libxau-1.0.7/lib 
-L/gnu/store/5d91m00mn4wv95x9liz1fb2w98zx99b3-libpthread-stubs-0.3/lib 
-L/gnu/store/8vc1przq2pgya04q5a8phqlnd11vxdsa-xproto-7.0.23/lib 
-L/gnu/store/kzn30f7sg54hlz3blaimc1962fhpm7fs-util-macros-1.17/lib 
-L/gnu/store/5fp4day13nixpw1qaksdw89h3pr8drss-damageproto-1.2.1/lib 
-L/gnu/store/k8r39q9as7lcfx1dhy33n3mkgsgdcprp-xf86vidmodeproto-2.3.1/lib 
-L/gnu/store/ywklhh8g1adi4v43dij99yda4d5wffdf-libxext-1.3.1/lib 
-L/gnu/store/9vzbp3qjz81sgnvg74j8cpzc6n0lmq03-xextproto-7.2.1/lib 
-L/gnu/store/8f15savrvf13z1z9hi5cb5l6akdx4gzr-zlib-1.2.7/lib 
-L/gnu/store/vkgwsi1vi2k91y22clf42z2qxydyxfbb-bzip2-1.0.6/lib 
-L/gnu/store/394ijzg3g53i77q9400j22w1wamcjkxs-xz-5.0.4/lib 
-L/gnu/store/sw5gnvc1q14pyiw5d7xc47xcy942gsf5-gawk-4.1.0/lib 
-L/gnu/store/plw2fk911b33n75ylmrqkfwkhwg75ydv-binutils-2.24/lib 
-L/gnu/store/6z7k9ms4sf367c3phl7djhb740ly3dqi-gcc-4.8.2/lib 
-L/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib 
-L/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
 
-L/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../..
 /gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib/libgfortran.so 
/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib/libquadmath.so 
/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib/libstdc++.so -lm 
-lpthread -lc -lgcc_s 
/gnu/store/p0sjqi40vd47z57g0i7mvhx9hrng9c2g-gfortran-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtendS.o
 /gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/crtn.o  -O2 
-pthread   -pthread -Wl,-soname -Wl,liboctave.so.2 -o .libs/liboctave.so.2.0.0
ld: 
/gnu/store/k42ljxy7g8av6jv99bjdh4wcv1ddqpg8-lapack-3.5.0/lib/liblapack.a(sgbtrf.f.o):
 relocation R_X86_64_32 against `.rodata' can not be used when making a shared 
object; recompile with -fPIC
/gnu/store/k42ljxy7g8av6jv99bjdh4wcv1ddqpg8-lapack-3.5.0/lib/liblapack.a: error 
adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefil

bug#17200: Mailutils test failures

[Mark H Weaver]

With current master, mailutils fails its test suite on my x86_64
machine.  The failures are in imap4d/testsuite/imap4d/fetch.exp:

--8<---cut here---start->8---
Running 
/tmp/nix-build-mailutils-2.2.drv-1/mailutils-2.2/imap4d/testsuite/imap4d/fetch.exp
 ...
FAIL: FETCH 3 BODY[1.MIME]
FAIL: FETCH 4 BODY[2.2.1]
FAIL: FETCH 4 BODY[2.2.1.TEXT]
FAIL: FETCH 4 BODY[2.2.TEXT]
FAIL: FETCH 5 BODY[2.TEXT]
--8<---cut here---end--->8---

  Mark

bug#17201: xf86-input-evdev fails to build

[Mark H Weaver]

With current master, xf86-input-evdev 2.7.0 fails to build on my x86_64
machine.  During ./configure it reports:

--8<---cut here---start->8---
checking for UDEV... no
configure: error: Package requirements (libudev) were not met:

No package 'libudev' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables UDEV_CFLAGS
and UDEV_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
phase `configure' failed after 7 seconds
--8<---cut here---end--->8---

  Mark

bug#17202: Imagemagick lacks stable source URLs

[Mark H Weaver]

The imagemagick build was broken because 6.8.8-8 is no longer available.
I've upgraded it to 6.8.8-10, but it will continue to break every time
they add a new version.

One option worth considering is to download the source from their
subversion repository.

 Mark

bug#17212: tests/utils.scm failures on Debian Wheezy i686 with Guile 2.0.5

[Mark H Weaver]

I see two 'fcntl-lock' related failures with current master on an i686
Debian Wheezy system with Debian's Guile 2.0.5 package.  See below for
the relevant excerpts from utils.log.

 Mark

--8<---cut here---start->8---
Test begin:
  test-name: "fcntl-flock wait"
  source-file: "tests/utils.scm"
  source-line: 177
  source-form: (test-equal "fcntl-flock wait" 42 (let ((file (open-file 
temp-file "w0"))) (fcntl-flock file (quote write-lock)) (match (primitive-fork) 
(0 (dynamic-wind (const #t) (lambda () (let ((file (open-file temp-file "r"))) 
(fcntl-flock file (quote read-lock)) (primitive-exit (read file))) 
(primitive-exit 1)) (lambda () (primitive-exit 2 (pid (display "hello, 
world!" file) (force-output file) (sleep 1) (seek file 0 SEEK_SET) 
(truncate-file file 0) (write 42 file) (force-output file) (fcntl-flock file 
(quote unlock)) (match (waitpid pid) ((_ . status) (let ((result 
(status:exit-val status))) (close-port file) result)))
Test end:
  result-kind: fail
  actual-value: 2
  expected-value: 42
--8<---cut here---end--->8---

--8<---cut here---start->8---
Test begin:
  test-name: "fcntl-flock non-blocking"
  source-file: "tests/utils.scm"
  source-line: 216
  source-form: (test-equal "fcntl-flock non-blocking" EAGAIN (match (pipe) 
((input . output) (match (primitive-fork) (0 (dynamic-wind (const #t) (lambda 
() (close-port output) (read-char input) (let ((file (open-file temp-file 
"w"))) (catch (quote flock-error) (lambda () (fcntl-flock file (quote 
write-lock) #:wait? #f)) (lambda (key errno) (primitive-exit errno 
(primitive-exit -1)) (lambda () (primitive-exit -2 (pid (close-port input) 
(let ((file (open-file temp-file "w"))) (fcntl-flock file (quote write-lock)) 
(write (quote green-light) output) (force-output output) (match (waitpid pid) 
((_ . status) (let ((result (status:exit-val status))) (fcntl-flock file (quote 
unlock)) (close-port file) result)
t) (lambda () (close-port output) (read-char input) (let ((file (open-file 
temp-file "w"))) (catch (quote flock-error) (lambda () (fcntl-flock file (quote 
write-lock) #:wait? #f)) (lambda (key errno) (primitive-exit errno 
(primitive-exit -1)) (lambda () (primitive-exit -2 (pid (close-port input) 
(let ((file (open-file temp-file "w"))) (fcntl-flock file (quote write-lock)) 
(write (quote green-light) output) (force-output output) (match (waitpid pid) 
((_ . status) (let ((result (status:exit-val status))) (fcntl-flock file (quote 
unlock)) (close-port file) result)
Test end:
  result-kind: fail
  actual-value: 0
  expected-value: 11
--8<---cut here---end--->8---

bug#17198: Octave fails to build

[Mark H Weaver]

Mark H Weaver  writes:
> In recent master, GNU Octave fails to build on my x86_64 system.

This was fixed in 57e544e8f7f0c907bb1ea3b4432a9a3d3da57365.
I'm closing this bug.

 Mark

bug#18003: texlive-2014 fails to build on MIPS

[Mark H Weaver]

texlive-2014 contains a copy of luajit which fails its test suite on
MIPS, thus causing the entire build to fail on guix.  Here's the tail of
the build log:

--8<---cut here---start->8---
Making check in luajit
make[2]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
Making check in .
make[3]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
make  jittest luajittry \
  luajit.test luajiterr.test
make[4]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
gcc -DHAVE_CONFIG_H -I. -I../../../texlive-20140525-source/libs/luajit  
-Iinclude  -Wall -g -O2 -MT jittest-jittest.o -MD -MP -MF 
.deps/jittest-jittest.Tpo -c -o jittest-jittest.o `test -f 'jittest.c' || echo 
'../../../texlive-20140525-source/libs/luajit/'`jittest.c
mv -f .deps/jittest-jittest.Tpo .deps/jittest-jittest.Po
gcc -Wall -g -O2   -o jittest jittest-jittest.o libluajit.a -ldl -lm 
gcc -DHAVE_CONFIG_H -I. -I../../../texlive-20140525-source/libs/luajit  
-Iinclude  -Wall -g -O2 -MT LuaJIT-2.0.3/src/luajittry-luajit.o -MD -MP -MF 
LuaJIT-2.0.3/src/.deps/luajittry-luajit.Tpo -c -o 
LuaJIT-2.0.3/src/luajittry-luajit.o `test -f 'LuaJIT-2.0.3/src/luajit.c' || 
echo '../../../texlive-20140525-source/libs/luajit/'`LuaJIT-2.0.3/src/luajit.c
mv -f LuaJIT-2.0.3/src/.deps/luajittry-luajit.Tpo 
LuaJIT-2.0.3/src/.deps/luajittry-luajit.Po
gcc -Wall -g -O2   -o luajittry LuaJIT-2.0.3/src/luajittry-luajit.o libluajit.a 
-ldl -lm 
make[4]: Nothing to be done for 
'../../../texlive-20140525-source/libs/luajit/luajit.test'.
make[4]: Nothing to be done for 
'../../../texlive-20140525-source/libs/luajit/luajiterr.test'.
make[4]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
make  check-TESTS
make[4]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
make[5]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
PASS: luajit.test
FAIL: luajiterr.test
make[6]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
make  all-recursive
make[7]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
Making all in .
make[8]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
make[8]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
Making all in native
make[8]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit/native'
make  all-am
make[9]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit/native'
make[9]: Leaving directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit/native'
make[8]: Leaving directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit/native'
Making all in include
make[8]: Entering directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit/include'
make[8]: Leaving directory 
'/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit/include'
make[7]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
make[6]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'

Testsuite summary for luajit for TeX Live 2.0.3

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to te...@tug.org

Makefile:1166: recipe for target 'test-suite.log' failed
make[5]: *** [test-suite.log] Error 1
make[5]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
Makefile:1272: recipe for target 'check-TESTS' failed
make[4]: *** [check-TESTS] Error 2
make[4]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
Makefile:1499: recipe for target 'check-am' failed
make[3]: *** [check-am] Error 2
make[3]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
Makefile:1052: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs/luajit'
Makefile:456: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/tmp/nix-build-texlive-2014.drv-1/build/libs'
Makefile:545: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1
phase `check' failed after 35 seconds
--8<---cut here---end--->8---

Here's the contents of luajiterr.log on Loongson 2F:

--8<---cut here---start->8---
../../../texlive-20140525-source/libs/luajit/luajiterr.test: line 6:  9268 
Illegal instruction ./luajittry -e "error('test')" 2> jiterr.tmp
1,4d0
< ./luajittry: (command line):1: test
< stack traceback:
< 

bug#18003: texlive-2014 fails to build on MIPS

[Mark H Weaver]

I found that Guix's own 'luajit' package builds successfully on MIPS,
presumably because it does not run the test suite.  The 'luajit' package
in Guix includes "#:tests? #f" in the arguments, with the comment
"luajit is distributed without tests".

  Mark

bug#18053: guix system init: incorrect permissions for /gnu/store

[Mark H Weaver]

Hi,

During my testing on a ThinkPad X60 (i686), I have found that 'guix
system init' creates /gnu/store with mode 0750, which does not allow
members of guixbuild to write to it.  The mode should be 1775.

Thanks!
  Mark

bug#18068: LINUX_MODULE_DIRECTORY needs trailing slash

[Mark H Weaver]

'module-init-tools' (with our patch) assumes that LINUX_MODULE_DIRECTORY
ends with a trailing slash.  However, 'udev-service' sets
LINUX_MODULE_DIRECTORY to "/run/booted-system/kernel/lib/modules".

One option would be to add a trailing slash:

--8<---cut here---start->8---
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -488,7 +488,7 @@ passed to @command{guix-daemon}."
 
 ;; Allow udev to find the modules.
 (setenv "LINUX_MODULE_DIRECTORY"
-"/run/booted-system/kernel/lib/modules")
+"/run/booted-system/kernel/lib/modules/")
 
 (let ((pid (primitive-fork)))
   (case pid
--8<---cut here---end--->8---

Another option would be to change module-init-tools-moduledir.patch to
cope with the lack of a trailing slash.

Thoughts?

Thanks,
  Mark

bug#18081: openpty fails on standalone guix

[Mark H Weaver]

openpty fails for unprivileged users on standalone guix.  For example,
running 'script' or 'screen' fails, and running M-x shell within emacs
results in a bash without job control, because emacs uses pipes to
communicate with the subprocess instead of pseudo-ttys, apparently
because it was unable to use openpty.

I've found that I can fix the problem by unmounting /dev/pts and then
remounting with the same options that LFS uses for its /etc/fstab:
"gid=1004,mode=620".  That gid corresponds to the 'tty' group.

  Mark

bug#18082: 'guix system reconfigure' fails to install grub from standalone guix

[Mark H Weaver]

I built guix from git master from within a standalone guix install.  I
then tried to run 'pre-inst-env guix system reconfigure' using the same
OS configuration, and it failed to install grub.

The error message said "failed to install GRUB on device '/dev/sda'",
which indicates that 'install-grub' raised an exception.

 Mark

bug#18082: 'guix system reconfigure' fails to install grub from standalone guix

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:
> In guix/scripts/system.scm, could you remove ‘false-if-exception’ around
> ‘install-grub’, and report the backtrace?

Here it is:

--8<---cut here---start->8---
root@jojen# ~mhw/guix/pre-inst-env guix system reconfigure ~mhw/os-install.scm 
The following derivation will be built:
   /gnu/store/ynkp0ijahvg4x1q6bfdw34d28hhqmgb4-grub.cfg.drv
killing process 1117
/gnu/store/ay6f47hv2gy4hny4ycnbyn0jnyd60n4v-system
/gnu/store/2yrylvn5c9apgfpppc5kfb24fi7mrnpl-grub-2.00
/gnu/store/6qwr8shknwlb1f1l0a7j6n3h8sg36bv7-grub.cfg
activating system...
populating /etc from /gnu/store/p4gvgs07g7gmsygjb3767r5k32v3l1y5-etc...
setting up setuid programs in '/run/setuid-programs'...
making '/gnu/store/ay6f47hv2gy4hny4ycnbyn0jnyd60n4v-system' the current 
system...
Backtrace:
In ice-9/boot-9.scm:
 157: 15 [catch #t # ...]
In unknown file:
   ?: 14 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 12 [eval # #]
In ice-9/boot-9.scm:
2401: 11 [save-module-excursion #]
4050: 10 [#]
1724: 9 [%start-stack load-stack ...]
1729: 8 [#]
In unknown file:
   ?: 7 [primitive-load "/home/mhw/guix/scripts/guix"]
In guix/ui.scm:
 656: 6 [run-guix-command system "reconfigure" "/home/mhw/os-install.scm"]
In ice-9/boot-9.scm:
 157: 5 [catch srfi-34 # ...]
 157: 4 [catch system-error ...]
In guix/monads.scm:
 430: 3 [run-with-store # ...]
In guix/scripts/system.scm:
 301: 2 [# #]
In guix/build/install.scm:
  47: 1 [install-grub # "/dev/sda" "/"]
In unknown file:
   ?: 0 [copy-file # "//boot/grub/grub.cfg.new"]

ERROR: In procedure copy-file:
ERROR: Wrong type (expecting string): # 
/gnu/store/6qwr8shknwlb1f1l0a7j6n3h8sg36bv7-grub.cfg b7ecf78>
root@jojen# 
--8<---cut here---end--->8---

and here's my os-install.scm:

--8<---cut here---start->8---
(use-modules (gnu)
 (gnu packages emacs)
 (gnu packages admin)
 (gnu packages linux)
 (gnu services base)
 (gnu services networking)
 (guix monads)
 (srfi srfi-26))

(operating-system
  (host-name "jojen")
  (timezone "US/Eastern")
  (bootloader (grub-configuration
(device "/dev/sda")))
  (file-systems (list (file-system
(device "librintel-guix")
(mount-point "/")
(type "ext4"
  (users (list (user-account
(name "mhw")
(group "mhw")
(password "")
(uid 1000)
(home-directory "/home/mhw"
  (groups (cons (user-group
 (name "mhw")
 (id 1000))
%base-groups))
  (packages (cons* emacs
   wpa-supplicant
   wireless-tools
   module-init-tools
   isc-dhcp
   %base-packages))
  (services
   (let ((motd (text-file "motd" "
This is the GNU operating system, welcome!\n\n")))
 (list (console-font-service "tty1")
   (console-font-service "tty2")
   (console-font-service "tty3")
   (console-font-service "tty4")
   (console-font-service "tty5")
   (console-font-service "tty6")

   (mingetty-service "tty1" #:motd motd)
   (mingetty-service "tty2" #:motd motd)
   (mingetty-service "tty3" #:motd motd)
   (mingetty-service "tty4" #:motd motd)
   (mingetty-service "tty5" #:motd motd)
   (mingetty-service "tty6" #:motd motd)
   (static-networking-service "lo" "127.0.0.1"
  #:provision '(loopback))
   (syslog-service)
   (guix-service #:authorize-hydra-key? #t)
   (nscd-service)
   (udev-service)
--8<---cut here---end--->8---

   Thanks!
 Mark

bug#18068: LINUX_MODULE_DIRECTORY needs trailing slash

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:
> I think it would be best to fix the module-init-tools patch.
> Could you look into it?

Okay.

> (Note that (1) udev uses kmod, not module-init-tools, and (2) it’s
> possible to use ‘kmod load’ instead of ‘insmod’.)

Hmm, yes, I would like to transition to kmod from module-init-tools, but
'kmod load' doesn't work for me, at least not within the standalone guix
system.  'kmod help' doesn't list 'load' as one of the commands either.

The only way I was able to get 'kmod' to work was to create a symlink
named 'modprobe' that points to it, and then running that.

I think we should consider creating those symlinks in our 'kmod'
package.  What do you think?

Thanks!
  Mark

bug#18082: 'guix system reconfigure' fails to install grub from standalone guix

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> In guix/build/install.scm:
>>   47: 1 [install-grub # "/dev/sda" "/"]
>> In unknown file:
>>?: 0 [copy-file # "//boot/grub/grub.cfg.new"]
>>
>> ERROR: In procedure copy-file:
>> ERROR: Wrong type (expecting string): #> /gnu/store/ynkp0ijahvg4x1q6bfdw34d28hhqmgb4-grub.cfg.drv => 
>> /gnu/store/6qwr8shknwlb1f1l0a7j6n3h8sg36bv7-grub.cfg b7ecf78>
>
> Oops, should be much better with this:
>
> diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
> index 57f4221..5737807 100644
> --- a/guix/scripts/system.scm
> +++ b/guix/scripts/system.scm
> @@ -299,7 +299,8 @@ actions."
>   (mlet %store-monad ((% (switch-to-system os)))
> (when grub?
>   (unless (false-if-exception
> -  (install-grub grub.cfg device "/"))
> +  (install-grub (derivation->output-path grub.cfg)
> +device "/"))
> (leave (_ "failed to install GRUB on device '~a'~%")
>device)))
> (return #t)))
>
> Can you confirm?

That helped, and now it successfully updates the grub.cfg file, but now
there's another problem.  When it tries to execvp 'grub-install', it
can't find it because PATH is set to:

  "/gnu/store/l5815c2iars8scdy82grfjjmxv9ahgv2-shadow-4.1.5.1/sbin"

Here's a transcript of the attempt, with (pk 'path (getenv "PATH"))
inserted just before the (system* "grub-install" ...) call in
guix/build/install.scm:

--8<---cut here---start->8---
root@jojen# echo $PATH
/run/setuid-programs:/run/current-system/profile/sbin:/root/.guix-profile/bin:/run/current-system/profile/bin
root@jojen# ~mhw/guix/pre-inst-env guix system reconfigure ~mhw/os-install.scm
The following derivation will be built:
   /gnu/store/1rj11nb1sv3jx2aalnqa7xl09nw6vfnr-grub.cfg.drv
killing process 1587
/gnu/store/qfacd34rj6v8b9mi21qx9mj3lkq3c2pg-system
/gnu/store/2yrylvn5c9apgfpppc5kfb24fi7mrnpl-grub-2.00
/gnu/store/ymxq6025wb6h3vp0glryykarz8r7hqhs-grub.cfg
activating system...
populating /etc from /gnu/store/89dn636ibbc2dy8wqaz30ck3dcli44jk-etc...
setting up setuid programs in '/run/setuid-programs'...
making '/gnu/store/qfacd34rj6v8b9mi21qx9mj3lkq3c2pg-system' the current 
system...

;;; (path "/gnu/store/l5815c2iars8scdy82grfjjmxv9ahgv2-shadow-4.1.5.1/sbin")
In execvp of grub-install: No such file or directory
Backtrace:
In ice-9/boot-9.scm:
 157: 14 [catch #t # ...]
In unknown file:
   ?: 13 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 12 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 11 [eval # #]
In ice-9/boot-9.scm:
2401: 10 [save-module-excursion #]
4050: 9 [#]
1724: 8 [%start-stack load-stack ...]
1729: 7 [#]
In unknown file:
   ?: 6 [primitive-load "/home/mhw/guix/scripts/guix"]
In guix/ui.scm:
 656: 5 [run-guix-command system "reconfigure" "/home/mhw/os-install.scm"]
In ice-9/boot-9.scm:
 157: 4 [catch srfi-34 # ...]
 157: 3 [catch system-error ...]
In guix/monads.scm:
 430: 2 [run-with-store # ...]
In guix/scripts/system.scm:
 301: 1 [# #]
In unknown file:
   ?: 0 [scm-error misc-error #f "~A" ("failed to install GRUB") #f]

ERROR: In procedure scm-error:
ERROR: failed to install GRUB
root@jojen# 
--8<---cut here---end--->8---

 Thanks,
   Mark

bug#18068: LINUX_MODULE_DIRECTORY needs trailing slash

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:
> Commits 906f704 and 4a8b4c2 address both issues.  Thanks!

Alas, this seems to have broken the linux-libre builds on all platforms.

   Thanks!
 Mark

bug#18082: 'guix system reconfigure' fails to install grub from standalone guix

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> populating /etc from /gnu/store/89dn636ibbc2dy8wqaz30ck3dcli44jk-etc...
>> setting up setuid programs in '/run/setuid-programs'...
>> making '/gnu/store/qfacd34rj6v8b9mi21qx9mj3lkq3c2pg-system' the current 
>> system...
>>
>> ;;; (path "/gnu/store/l5815c2iars8scdy82grfjjmxv9ahgv2-shadow-4.1.5.1/sbin")
>> In execvp of grub-install: No such file or directory
>
> OK, commit 720ee24 should bring us one step closer.  Could you check?

'guix system reconfigure' now works.
I'm closing this bug.

   Thanks! :)
 Mark

bug#18101: gccgo fails to build (all platforms)

[Mark H Weaver]

At the very end of the builds for gccgo, there is an error:

  cycle detected in the references of `/gnu/store/*-gccgo-4.8.3-lib'

and that causes the build to fail.

I wonder if this is fallout from when the gcc packages had their libs
split into a different output.  Maybe the "lib" and "out" outputs of
gccgo reference each other, and perhaps this is a problem?

 Mark

bug#18115: offload fails to register GC root

[Mark H Weaver]

See the aborted build here: http://hydra.gnu.org/build/80150

Here's the Nix error output:

--8<---cut here---start->8---
these derivations will be built:
  /gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv
process 11125 acquired build slot '/nix/var/guix/offload/chapters.gnu.org/0'
process 11125 acquired build slot '/nix/var/guix/offload/hydra.gnunet.org/0'
load on machine 'hydra.gnunet.org' is 0.05 (normalized: 0.0125)
load on machine 'chapters.gnu.org' is 0.01 (normalized: 0.005)
load on machine 'hydra.gnunet.org' is 0.05 (normalized: 0.0125)
@ build-started 
/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv - x86_64-linux 
/nix/var/log/guix/drvs/jb//3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv
Backtrace:
In ice-9/boot-9.scm:
 157: 7 [catch #t # ...]
In unknown file:
   ?: 6 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 5 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 4 [eval # #]
In unknown file:
   ?: 3 [call-with-input-string "(begin (use-modules (guix config)) (let 
((root-directory (string-append %state-directory \"/gcroots/tmp\"))) 
(false-if-exception (mkdir root-directory)) (symlink 
\"/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv\" 
(string-append root-directory \"/\" 
\"offload-20121227-hydra.gnu.org-11125\"" ...]
In ice-9/command-line.scm:
 180: 2 [# #]
In unknown file:
   ?: 1 [eval (begin (use-modules #) (let # # #)) #]
   ?: 0 [symlink 
"/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv" ...]

ERROR: In procedure symlink:
ERROR: In procedure symlink: File exists
guix offload: error: failed to register GC root for 
'/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv' on 
'#< name: "hydra.gnunet.org" port: 22 system: "x86_64-linux" 
user: "hydra" private-key: "/home/hydra/.lsh/identity" parallel-builds: 4 
speed: 1.7 features: ()>' (status: 256)
builder for `/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv' 
failed with exit code 1
@ hook-failed /gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv 
- 256 builder for 
`/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv' failed with 
exit code 1
error: build of 
`/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv' failed
--8<---cut here---end--->8---

bug#18003: texlive-2014 fails to build on MIPS

[Mark H Weaver]

I've worked around the problem by disabling tests on MIPS, commit
2f4640e320a8834f618c7be5a7e8dba62da91190.  Closing this bug.

 Mark

bug#18101: gccgo fails to build (all platforms)

[Mark H Weaver]

Mark H Weaver  writes:

> At the very end of the builds for gccgo, there is an error:
>
>   cycle detected in the references of `/gnu/store/*-gccgo-4.8.3-lib'
>
> and that causes the build to fail.
>
> I wonder if this is fallout from when the gcc packages had their libs
> split into a different output.  Maybe the "lib" and "out" outputs of
> gccgo reference each other, and perhaps this is a problem?

I fixed this by suppressing the separate "lib" output in gccgo, commit
c4df90a594672042ae106730ab5ce07fe85cf46f.  Closing this bug.

  Mark

bug#18243: make clean removes gnu/system/os-config.tmpl

[Mark H Weaver]

Subject says it all...

 Mark

bug#18247: Cyclic dependencies in (gnu package *) modules

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> m...@netris.org skribis:
>
>> I'm currently unable to compile guix from git, with error messages that
>> suggest cyclic dependencies between the modules.
>
> Indeed.  That is fixed by reverting c5d8376.  Can you confirm?

Yes, that solves the problem for me.

>> I just computed the strongly connected components of the (gnu package
>> *) modules.  The non-trivial ones are listed below.
>>
>> There are three cycles of size 2:
>>
>> ((gnu packages emacs)  (gnu packages version-control))
>> ((gnu packages flex)   (gnu packages bison))
>> ((gnu packages python) (gnu packages zip))
>>
>> And one large strongly-connected component containing 51 modules:
>
> Ouch.
>
> Well, that is not really a problem per se.  The real problem is when
> top-level bindings refer to each other, of course.

To be more precise, the relevant question is: which bindings from other
modules are needed when a module is _loaded_.  In other words, we need
to worry about cycles in a graph, but a different graph than the one my
script computed.

I think the graph we need to consider is one that contains one vertex
per module, and an directed edge from module A to B if and only if
loading module A requires looking up a binding from module B.

Does that sound right to you?

Unfortunately, it seems to me that the most common kinds of cross-module
references between (gnu packages *) modules are references in 'inputs'
or 'native-inputs' fields, and those need to be looked up at module load
time, right?

> But anyway, I agree we need tooling or something to help deal with this
> kind of issues.  Perhaps something like the script you posted, but that
> would look at the set of bindings referenced from the top-level of a
> module?  Or can we do better?
>
> If Guile supported phases, such circular references would not be a
> problem since it would not have to evaluate all of the imported modules
> at expansion phase, just the ‘define-module’ clause.

I'd very much like to add phases to Guile's macro expander at some
point, but it would have to be done between major releases.  It would
likely break a lot of existing code.

Thanks,
  Mark

bug#18247: Cyclic dependencies in (gnu package *) modules

[Mark H Weaver]

Eric Bavier  writes:

> Ludovic Courtès writes:
>
>> As a stop-gap measure, I’ve worked around the problem in commit d759cf6,
>> which removes the dependency from texinfo to gettext.
>>
>> (Éric: I see one test failure in texi2html, which is a priori unrelated
>> to the change.  Could you check what’s going on?)
>
> The problem is that texi2html does actually require gettext.  Its
> makefile wants to install mo files that are not present in the
> distribution (so msgfmt is required).  Configuring with --disable-nls
> causes the resulting script to fail at runtime.
>
> Perhaps moving texi2html into its own module would solve the circular
> dependency?

That would be one way to avoid the circular dependency, yes.

  Mark

bug#18221: Source of mit-scheme

[Mark H Weaver]

Andreas Enge  writes:

> Hello,
>
> mit-scheme fails to build on mips64el-linux, because specific source is not
> downloaded for this system. Furthermore, I wonder if in the corresponding
> lines
>   (match (%current-system)
> ("x86_64-linux" "x86-64")
> ("i686-linux" "i386")
> (_ "c"))
> one need not also check for the target system in the usual manner.
> Here the "c" should be the empty string, I think, and the preceding "-"
> should be included into "x86-64" and "i386".

I'm not sure I understand what you're suggesting.

The problem here is that the "c" belongs in a different place in the
filename than where the "i386" or "x86-64" goes.  The filenames are:

  mit-scheme-9.2-i386.tar.gz
  mit-scheme-9.2-x86-64.tar.gz
  mit-scheme-c-9.2.tar.gz

So I guess we need something like this (untested):

  (uri (string-append "mirror://gnu/mit-scheme/stable.pkg/"
  version "/mit-scheme-"
  (match (%current-system)
("x86_64-linux"
 (string-append version "-x86-64"))
("i686-linux"
 (string-append version "-i386"))
(_
 (string-append "c-" version)))
  ".tar.gz"))

Thanks,
  Mark

bug#18542: gnome-vfs intermittent test failures

[Mark H Weaver]

gnome-vfs is intermittently failing its 'test-async-cancel' test.  See:

  http://hydra.gnu.org/job/gnu/master/gnome-vfs-2.24.4.i686-linux
  http://hydra.gnu.org/job/gnu/master/gnome-vfs-2.24.4.x86_64-linux

  Mark

bug#18553: Hydra: failures to create GC root /home/hydra/offload-*

[Mark H Weaver]

I've seen several failed builds on Hydra where the build log ends with
something like this:

--8<---cut here---start->8---
phase `strip' succeeded after 0 seconds
@ build-succeeded 
/gnu/store/b20viwrr0h5y2mqdpx9bpi21snb4fv5c-xkeyboard-config-2.6.drv -
/gnu/store/sp60mrd8hashvh0v8l17gn2mz87a34kl-xkeyboard-config-2.6
guix build: error: failed to create GC root 
`/home/hydra/offload-20121227-hydra.gnu.org-18304': File exists
--8<---cut here---end--->8---

Simply restarting the jobs typically result in successful builds.

 Mark

bug#18221: Source of mit-scheme

[Mark H Weaver]

Andreas Enge  writes:

> On Sun, Aug 17, 2014 at 05:06:07PM +0200, Ludovic Courtès wrote:
>> Yes, I think that’s what’s needed, so OK to commit.
>
> Done with commit 68dddca.

That commit adds a top-level procedure 'source-directory' that is
specific to mit-scheme.  If it's kept at the top-level, it should
probably be renamed to something like 'mit-scheme-source-directory'.

Also, it would be good to line up the two calls to 'string-prefix?'.

Thanks!
  Mark

bug#18581: icecat fails to build on i686

[Mark H Weaver]

The icecat build on i686 broke with the last core-updates merge.
See:

  http://hydra.gnu.org/build/96557/log/tail-reload
  http://hydra.gnu.org/job/gnu/master/icecat-24.0.i686-linux

Some of the notable updates in that merge include:

  glibc-2.20
  gnutls-3.2.16
  libunistring-0.9.4
  libgc-7.4.2
  libffi-3.1

Here's a more complete list:

  http://hydra.gnu.org/eval/100725#tabs-new

 Mark

bug#18581: icecat fails to build on i686

[Mark H Weaver]

retitle 18581 IceCat fails to build on i686 and needs security updates
severity 18581 serious
thanks

Mark H Weaver  writes:
> The icecat build on i686 broke with the last core-updates merge.
> See:
>
>   http://hydra.gnu.org/build/96557/log/tail-reload
>   http://hydra.gnu.org/job/gnu/master/icecat-24.0.i686-linux

More importantly, the version of IceCat we are using is almost a year
old, with no security updates applied during that time.

We should update to IceCat 31, which is currently available only from
Trisquel, here:

  
http://devel.trisquel.info/icecat/belenos/pool/main/i/icecat/icecat_31.0+gnu3.tar.gz

We also need security updates applied, notably the recent NSS signature
verification flaw: (CVE-2014-1568)

  http://seclists.org/oss-sec/2014/q3/736
  https://www.mozilla.org/security/announce/2014/mfsa2014-73.html

There may be other security patches as well.  I suggest looking on
mozilla.org for patches to version 31.

  Mark

bug#18581: IceCat fails to build on i686 and needs security updates

[Mark H Weaver]

Andreas Enge  writes:

> On Tue, Sep 30, 2014 at 01:37:08PM -0400, Mark H Weaver wrote:
>> More importantly, the version of IceCat we are using is almost a year
>> old, with no security updates applied during that time.
>> 
>> We should update to IceCat 31, which is currently available only from
>> Trisquel, here:
>
> This is a problem with the gnuzilla maintenance, which is possibly solved:
>https://lists.gnu.org/archive/html/bug-gnuzilla/2014-09/msg8.html
> Although the lack of news since September 11 is not encouraging.

Jason Self spoke to the new IceCat maintainer (Rubén Rodríguez, also the
Trisquel BDFL), and reports that the current plan is to base IceCat on
the Firefox v31 Extended Support Release (ESR), to get security updates
from Mozilla, and also to get the patches from TorBrowser.  Rubén says
that he's almost done modifying his scripts for the FF31 ESR, at which
point we should be in good shape.

I also asked on #parabola to find out how they deal with this issue.
Apparently their IceCat is also old and unpatched, but they have scripts
to modify Debian's Iceweasel to comply with the FSDG here:

  https://projects.parabola.nu/abslibre.git/tree/libre/iceweasel

We might consider adding this to Guix as well.

 Thanks,
   Mark

bug#18639: libdaemon home-page and source URL no longer valid

[Mark H Weaver]

http://0pointer.de/lennart/projects/libdaemon/ no longer exists, and
I've been unable to easily find out what happened to it, or where it
now lives (if at all).

  Mark

bug#18640: [wishlist] fontconfig's cache is not refreshed automatically

[Mark H Weaver]

When a user runs emacs (or any other program that uses fontconfig), a
cache is created in ~/.cache/fontconfig.  This cache is not updated
automatically after installing new fonts, and must be manually cleared
out.

I guess this might be related to our use of Jan 1, 1970 as the
timestamps for all files in /gnu/store (which includes user profiles).

We should either modify fontconfig to detect a stale cache using a
method that works on Guix, or else notify the user that they must clear
the cache after installing ttf fonts.

  Mark

bug#18639: libdaemon home-page and source URL no longer valid

[Mark H Weaver]

Mark H Weaver  writes:

> http://0pointer.de/lennart/projects/libdaemon/ no longer exists, and
> I've been unable to easily find out what happened to it, or where it
> now lives (if at all).

In the meantime, here are two places where it can be downloaded from:

http://pkgs.fedoraproject.org/repo/pkgs/libdaemon/libdaemon-0.14.tar.gz/509dc27107c21bcd9fbf2f95f5669563/libdaemon-0.14.tar.gz
http://ftp.de.debian.org/debian/pool/main/libd/libdaemon/libdaemon_0.14.orig.tar.gz

Both of these match the hash in our libdaemon recipe.  The first one has
the advantage of having the filename we expect.

  Mark

bug#18673: Intermittent test failures in guile-ssh-0.6.0

[Mark H Weaver]

There are intermittent test failures in guile-ssh, see:

  http://hydra.gnu.org/job/gnu/master/guile-ssh-0.6.0.i686-linux
  http://hydra.gnu.org/job/gnu/master/guile-ssh-0.6.0.x86_64-linux

All of the failures are the same: "FAIL: client-server.scm"

 Mark

bug#18695: Qt fails to build from source

[Mark H Weaver]

Somewhere between 74c7af9 and 7239828, all of the Qt builds broke.
See:

   http://hydra.gnu.org/eval/100809#tabs-now-fail

   Mark

bug#18698: Our WindowMaker wrapper pollutes PATH in the entire X session

[Mark H Weaver]

We install a wrapper script around WindowMaker that prepends
/gnu/store/XXX-windowmaker-XXX/bin to $PATH.  This setting is propagated
to all subprocesses in the entire X session, which is suboptimal.  It
would be nice to find another solution, preferably by using absolute
pathnames when launching subprocesses run by WindowMaker.

  Mark

bug#18695: Qt fails to build from source

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> Somewhere between 74c7af9 and 7239828, all of the Qt builds broke.
>> See:
>>
>>http://hydra.gnu.org/eval/100809#tabs-now-fail

[...]

> I think this is due to a thinko I overlooked during the review; I’m
> testing this patch and will commit if it solves the problem:
>
> diff --git a/gnu/packages/icu4c.scm b/gnu/packages/icu4c.scm
> index 7eb3874..e7d5247 100644
> --- a/gnu/packages/icu4c.scm
> +++ b/gnu/packages/icu4c.scm
> @@ -68,10 +68,10 @@
>  (lambda* (#:key outputs #:allow-other-keys)
>(let* ((out (assoc-ref outputs "out"))
>   (lib (string-append out "/lib")))
> -;; Add LIB to the RUNPATH of all the binaries.
> +;; Add LIB to the RUNPATH of all the libraries and binaries.
>  (with-directory-excursion out
>(for-each (cut augment-rpath <> lib)
> -(append
> +(append (find-files "lib" ".*")
>  (find-files "bin" ".*")
>  (find-files "sbin" ".*"))
>  %standard-phases)

Yes, this fixed it.  I'm closing this bug now.

Thanks!
  Mark

bug#18700: GNU Lightning fails to build on all platforms

[Mark H Weaver]

GNU Lightning fails to build on all platforms.  See:

  http://hydra.gnu.org/job/gnu/master/lightning-2.0.5.x86_64-linux
  http://hydra.gnu.org/job/gnu/master/lightning-2.0.5.i686-linux
  http://hydra.gnu.org/job/gnu/master/lightning-2.0.5.mips64el-linux

  Mark