[PATCH] gnu: icecat: Update to 31.1.1

[Mark H Weaver]

This is technically a pre-release, but given that our current Icecat has
at least one security hole (and probably others), and fails to build on
i686, I'm inclined to push it to master immediately.

I suppose I should also mention that I've only tested it on i686.

What do you think?

  Mark


>From d74f4c12f005bbfbd419772f861d7693eb1b7c28 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 8 Oct 2014 23:37:37 -0400
Subject: [PATCH] gnu: icecat: Update to 31.1.1.

* gnu/packages/gnuzilla.scm (icecat): Update to 31.1.1.  Add 'pango',
  'freetype', 'libxft' and 'pulseaudio' as inputs.  Set
  'out-of-source?' to #t.  Remove 'sanitise' phase.  Adapt customized
  'configure' phase to handle 'out-of-source?' build.  Add
  '--with-l10n-base' argument to configure.
---
 gnu/packages/gnuzilla.scm | 61 +++
 1 file changed, 35 insertions(+), 26 deletions(-)

diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index 11515d4..1ae1f29 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -30,9 +30,11 @@
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages compression)
+  #:use-module (gnu packages fontutils)
   #:use-module (gnu packages libevent)
   #:use-module (gnu packages image)
   #:use-module (gnu packages libffi)
+  #:use-module (gnu packages pulseaudio)
   #:use-module (gnu packages python)
   #:use-module (gnu packages xorg)
   #:use-module (gnu packages gl)
@@ -42,16 +44,15 @@
 (define-public icecat
   (package
 (name "icecat")
-(version "24.0")
+(version "31.1.1")
 (source
  (origin
   (method url-fetch)
-  (uri (string-append "mirror://gnu/gnuzilla/"
-  (substring version 0 (string-index version #\.))
-  "/icecat-" version ".tar.gz"))
+  (uri (string-append "http://gnuzilla.gnu.org/releases/";
+  version "/" name "-" version ".tar.xz"))
   (sha256
(base32
-"1vxzjwmhad6yxx4sk9zvapjgv5salcv10id061q0991ii3dycy9a"
+"033p5b6akjbg33prqg57mhp5zx3svryqzbjb3k58ql6939bfmad8"
 (build-system gnu-build-system)
 (inputs
  `(("alsa-lib" ,alsa-lib)
@@ -62,9 +63,13 @@
("gstreamer" ,gstreamer-0.10)
("gst-plugins-base" ,gst-plugins-base-0.10)
("gtk+" ,gtk+-2)
+   ("pango" ,pango)
+   ("freetype" ,freetype)
+   ("libxft" ,libxft)
("libevent" ,libevent)
("libxt" ,libxt)
("libffi" ,libffi)
+   ("pulseaudio" ,pulseaudio)
("mesa" ,mesa)
("unzip" ,unzip)
("yasm" ,yasm)
@@ -76,7 +81,8 @@
("python2-pysqlite" ,python2-pysqlite)
("pkg-config" ,pkg-config)))
 (arguments
- `(#:tests? #f ; no check target
+ `(#:tests? #f  ; no check target
+   #:out-of-source? #t  ; must be built outside of the source directory
 
#:configure-flags '(;; Building with debugging symbols takes ~5GiB, so
;; disable it.
@@ -112,26 +118,29 @@
"--enable-system-ffi")
 
#:phases
- (alist-cons-before
-  'patch-source-shebangs 'sanitise
-  (lambda _
-;; delete dangling symlinks
-(delete-file "browser/base/content/.#aboutDialog.xul")
-(delete-file "browser/base/content/abouthome/.#aboutHome.xhtml")
-(delete-file "browser/branding/unofficial/content/.#aboutHome.xhtml")
-(delete-file "toolkit/crashreporter/google-breakpad/autotools/compile"))
- (alist-replace
-  'configure
-  ;; configure does not work followed by both "SHELL=..." and
-  ;; "CONFIG_SHELL=..."; set environment variables instead
-  (lambda* (#:key outputs configure-flags #:allow-other-keys)
-(let ((out (assoc-ref outputs "out")))
-  (setenv "SHELL" (which "bash"))
-  (setenv "CONFIG_SHELL" (which "bash"))
-  (zero? (apply system* "./configure"
-(string-append "--prefix=" out)
-configure-flags
-  %standard-phases
+   (alist-replace
+'configure
+;; configure does not work followed by both "SHELL=..." and
+;; "CONFIG_SHELL=..."; set environment variables instead
+(lambda* (#:key outputs

Re: [PATCH] gnu: icecat: Update to 31.1.1

[Mark H Weaver]

Mark H Weaver  writes:
> This is technically a pre-release, but given that our current Icecat has
> at least one security hole (and probably others), and fails to build on
> i686, I'm inclined to push it to master immediately.

After some more testing, I went ahead and pushed this.

 Mark

Setting environment variables in .bashrc vs .bash_profile

[Mark H Weaver]

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

> I just noticed that ‘guix environment foo’, without -E, doesn’t work for
> me because my .bashrc & co. reset PATH, CPATH, etc.
>
> Conversely, ‘guix environment foo -E /bin/sh’ works, because when
> invoked as ‘sh’, Bash does not read .bashrc.
>
> I’m not sure if it’s something wrong with my Bash initialization files
> or something that might affect others.  WDYT?

FWIW, I've always put my environment variable settings in .bash_profile
instead of .bashrc for this reason.  I want to be able to set up an
alternate environment and launch interactive subshells without resetting
everything.

I vaguely remember noticing that the standalone Guix system set things
up in such a way that my environment was reset in every interactive
shell.  If so, I would be in favor of changing that.

On the other hand, I end up with
/gnu/store/10fr8jbnrb3gzyc0967m7ar64ch9ggk8-windowmaker-0.95.6/bin in
front of my PATH within my entire X session, because of our windowmaker
wrapper.

Thoughts?
   Mark

Re: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a.

[Mark H Weaver]

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

> Eric Bavier  skribis:
>
>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001
>> From: Eric Bavier 
>> Date: Fri, 10 Oct 2014 13:07:55 -0500
>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a.
>>
>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a.
>
> OK.

This triggered over 450 rebuilds.  I wonder if it should have been done
in core-updates instead.

  Mark

Re: Rebuilds and branches

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Eric Bavier  skribis:
>>>
>>>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001
>>>> From: Eric Bavier 
>>>> Date: Fri, 10 Oct 2014 13:07:55 -0500
>>>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a.
>>>>
>>>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a.
>>>
>>> OK.
>>
>> This triggered over 450 rebuilds.  I wonder if it should have been done
>> in core-updates instead.
>
> Arf, probably yes, in a ‘libjpeg-update’ branch, rather.

Well, suppose we update two different core packages in close succession,
e.g. make 4.1 and bash 4.3.30.  I don't want two independent rebuilds,
one with make 4.1 and bash 4.3.27 and another with make 4.0 and bash
4.3.30.  Each of those would turn out to be useless.

> What about having a policy for that?  Like, above some threshold of the
> number of rebuilds reported by ‘guix refresh -l’ (200 packages?), set up
> a separate branch and Hydra job set.

The severity of the bug being fixed may also be a relevant factor in the
decision.

> In an ideal world a patch queue manager would automatically take care of
> that.

I'm not sure the decision can be made fully automatically, but it would
certainly be nice to have some tools to make the job easier.

   Mark

Re: [PATCH 3/4] gnu: Add xfig.

[Mark H Weaver]

Hi Eric,

Eric Bavier  writes:

> From fca4924a98e06ec0d2877b14f074515a2a970605 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Fri, 10 Oct 2014 13:10:42 -0500
> Subject: [PATCH 3/4] gnu: Add xfig.

Hydra reports that xfig only builds successfully on x86_64.  It fails on
i686 and mips64el.  Can you investigate?

http://hydra.gnu.org/job/gnu/master/xfig-3.2.5c.i686-linux
http://hydra.gnu.org/job/gnu/master/xfig-3.2.5c.mips64el-linux

  Mark

Re: GNU Hackers Meeting talk on-line

[Mark H Weaver]

John Darrington  writes:

> On Sat, Oct 11, 2014 at 11:47:41AM +0200, Ludovic Court??s wrote:
>  The video of my talk at the 2014 GHM is now online:
>  
>http://www.gnu.org/software/guix/#talks
>  
>  (Sound is not very good.)
>  
> This seems to be a recurring problem with GHM videos.  Making good quality
> audio/video recordings requires equipment and skill.
>
>
> Since we traditionally, don't have any "proceedings", the videos are the only
> recoding of the meetings.  Does anyone have any suggestions how we could 
> ensure 
> that we get consistently good recordings?

Maybe I'll come next year, and if so, I can help with the recordings.
I'm experienced at making audio recordings for radio broadcast, as a
long-time member of WMBR, MIT's all-volunteer radio station.

  Mark

Re: bug#18524: Guix unable to download from github due to TLS fatal alert

[Mark H Weaver]

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

> I had managed to bork ‘set-session-server-name!’ in GnuTLS (which
> addresses this bug), so this is fixed in commit 5186158 and upstream:
> .
>
> Sorry about that!

No worries, thanks for taking care of this!

 Mark

Re: [PATCH 3/4] gnu: Add xfig.

[Mark H Weaver]

Eric Bavier  writes:
> Btw, I did push a change to xfig and transfig that should let them build
> for i686 (which I tested locally now) and mips (which I don't have the
> means to check locally).

This fixed the issue, and xfig now builds on all three of our platforms.

Thanks!
  Mark

Re: Grafts

[Mark H Weaver]

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

> I pushed ‘wip-grafts’, a branch that implements “grafts.”
>
> Normally security updates deep in the DAG, such as an update of Bash or
> libc, cause a rebuild of everything, which can some time, as we’ve seen
> lately.
>
> The idea of grafts is to graft the fixed package on any packages users
> may want to install.  So, suppose there’s a libc fix; when installing
> IceCat, you’ll just be starting from the (pre-built) IceCat, and an
> additional derivation will patch the files in it to replace references
> to the old libc with references to the fixed libc (in practice this only
> works if the file name of the old and fixed libc have the same length.)

Thanks for working on this!  I think it will be quite important.

> ‘wip-grafts’ adds a ‘graft’ field to package records.  In the example
> above, we’d just add a ‘graft’ field to glibc, pointing to the fixed
> glibc, and the graft would just be automagically applied.  The branch
> has an example of that with Bash:
>
> --- a/gnu/packages/bash.scm
> +++ b/gnu/packages/bash.scm
> @@ -185,7 +185,13 @@ allows command-line editing, unlimited command history, 
> shell functions and
>  aliases, and job control while still allowing most sh scripts to be run
>  without modification.")
>   (license gpl3+)
> - (home-page "http://www.gnu.org/software/bash/";
> + (home-page "http://www.gnu.org/software/bash/";)
> + (graft bash-fixed
> +
> +(define bash-fixed;FIXME: Use something real.
> +  (package (inherit bash)
> +(version "4.3.42")
> +(graft #f)))

If you want a real example, upstream bash is at 4.3.30, whereas we only
have 4.3.27.

Thanks!
  Mark

Re: [PATCH] gnu: Add ntp

[Mark H Weaver]

John Darrington  writes:

> +(define-public ntp
> +  (package
> +   (name "ntp")
> +   (version "4.2.6p5")
> +   (source (origin
> + (method url-fetch)
> + (uri (string-append 
> "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-";
> +(string-take version 3) "/ntp-" 

Instead of 'string-take', please import (srfi srfi-1) and then do this:

  (string-join (take (string-split version #\.) 2)
   ".")

We use this pattern in a number of other places -- search for
"string-join" in gnu/packages/*.scm to find them.  I suppose we should
add a procedure specifically for this, but it can wait, and it should be
in a separate commit anyway.

> +version ".tar.gz"))
> + (sha256
> +  (base32
> +   "077r69a41hasl8zf5c44km7cqgfhrkaj6a4jnr75j7nkz5qq7ayn"
> +   (native-inputs `(("which" ,which)))
> +   (build-system gnu-build-system)
> +   (synopsis "Real time clock synchonization system")
> +   (description "NTP is a system designed to synchronize the clocks of
> +computers over a network.")
> +   (license (x11-style 
> + "http://www.eecis.udel.edu/~mills/ntp/html/copyright.html";
> + "A non-copyleft free licence from the University of Delaware"))
> +   (home-page "http://www.ntp.org";)))

Okay to commit with the change above.

Thanks!
  Mark

Re: [PATCH] gnu: Add ntp

[Mark H Weaver]

Ian Denhardt  writes:

> Quoting Mark H Weaver (2014-10-18 12:24:56)
>>   (string-join (take (string-split version #\.) 2)
>>".")
>
> 
>
>> I suppose we should add a procedure specifically for this, but
>> it can wait, and it should be in a separate commit anyway.
>
> I'm going to grab this and try to have a patch submitted today or
> tomorrow.

Sounds good!

> Does guix/utils.scm seem like a sensible place to put this?

Yes, it fits in well with 'version-compare' and 'version>?'.

Thanks,
  Mark

Re: [PATCH 1/1] Factor out a common pattern into a procedure.

[Mark H Weaver]

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

> John Darrington  skribis:
>
>> How about something like (string-take-fields "1.22.3.04.5" 3) which would 
>> return "1.22.3"
>
> Agreed.  What ‘version-prefix’, with the optional argument defaulting
> to 2?

I also like 'version-prefix', although I'd favor making it a required
argument.  The improved code clarity is well worth two extra characters.
I don't feel strongly though.

>> Possibly an optional argument specifying the separator might be useful too.
>
> I think that’d be overkill.

Agreed.

 Mark

Re: [PATCH 1/1] Factor out a common pattern into a procedure.

[Mark H Weaver]

Ian Denhardt  writes:

> diff --git a/guix/utils.scm b/guix/utils.scm
> index 6392914..a179f6b 100644
> --- a/guix/utils.scm
> +++ b/guix/utils.scm
> @@ -2,6 +2,7 @@
>  ;;; Copyright © 2012, 2013, 2014 Ludovic Courtès 
>  ;;; Copyright © 2013 Mark H Weaver 
>  ;;; Copyright © 2014 Eric Bavier 
> +;;; Copyright © 2014 Ian Denhardt 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -64,6 +65,7 @@
>  %current-system
>  %current-target-system
>  version-compare
> +version-take-api
>  version>?
>  guile-version>?
>  package-name->name+version
> @@ -518,6 +520,11 @@ or '= when they denote equal versions."
>((negative? result) '<)
>(else '=))
>  
> +(define (version-take-api version-string)
> +  "Return \".\", where major and minor are the major and
> +minor version numbers from version-string."
> +  (string-join (take (string-split version-string #\.) 2) "."))
> +
>  (define (version>? a b)
>"Return #t when A denotes a newer version than B."
>(eq? '> (version-compare a b)))

Let's keep 'version-compare' and 'version>?' adjacent, in both the
export list and the implementation, since they are much more closely
related to each other than to this new procedure.

And as discussed in another message, let's rename the procedure and
replace the hard-coded 2 with an argument.

 Thanks,
   Mark

Re: [PATCH 3/5] guix: lint: Check for proper end-of-sentence space.

[Mark H Weaver]

Eric Bavier  writes:

> From 88d05ece4bf30bbed6de51f076cde0301c493123 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Wed, 22 Oct 2014 13:47:01 -0500
> Subject: [PATCH 3/5] guix: lint: Check for proper end-of-sentence space.
>
> * guix/scripts/lint.scm (start-with-capital-letter?): Handle empty
>   strings.
>   (check-description-style): New check for end-of-sentence space.
> * tests/lint.scm: Test it.
> ---
>  guix/scripts/lint.scm |   42 ++
>  tests/lint.scm|9 +
>  2 files changed, 43 insertions(+), 8 deletions(-)
>
> diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
> index 84d9fe9..e8cc853 100644
> --- a/guix/scripts/lint.scm
> +++ b/guix/scripts/lint.scm
> @@ -25,6 +25,8 @@
>#:use-module (guix utils)
>#:use-module (gnu packages)
>#:use-module (ice-9 match)
> +  #:use-module (ice-9 regex)
> +  #:use-module (ice-9 format)
>#:use-module (srfi srfi-1)
>#:use-module (srfi srfi-9)
>#:use-module (srfi srfi-11)
> @@ -75,17 +77,41 @@
>(exit 0))
>  
>  (define (start-with-capital-letter? s)
> -  (char-set-contains? char-set:upper-case (string-ref s 0)))
> +  (and (not (string-null? s))
> +   (char-set-contains? char-set:upper-case (string-ref s 0
>  
>  (define (check-description-style package)
>;; Emit a warning if stylistic issues are found in the description of 
> PACKAGE.
> - (let ((description (package-description package)))
> -   (when (and (string? description)
> -  (not (string-null? description))
> -  (not (start-with-capital-letter? description)))
> - (emit-warning package
> -   "description should start with an upper-case letter"
> -   'description
> +  (define (check-starts-with-upper-case description)
> +(unless (start-with-capital-letter? description)
> +  (emit-warning package
> +"description should start with an upper-case letter"
> +'description)))
> +
> +  (define (check-end-of-sentence-space description)
> +"Check that an end-of-sentence period is followed by two spaces."
> +(let ((infractions (filter-map
> +(lambda (m)
> +  (and (not
> +;; Filter out matches of common abbrevs.
> +(find (lambda (s)
> +(string-suffix? s (match:prefix m)))
> +  '("i.e" "e.g" "a.k.a" "resp")))
> +   (match:start m)))
> +(list-matches "\\. [A-Z]" description
> + (when (not (null? infractions))

(unless (null? infractions)).  Also, this should be indented one more
column.

> +   (emit-warning package
> + (format #f "sentences in description should be followed 
> ~
> +by two spaces; possible infraction~p at ~{~a~^, ~}"
> + (length infractions)
> + infractions)
> + 'description
> +
> +  (let ((description (package-description package)))
> +(when (string? description)
> +  (begin
> +(check-starts-with-upper-case description)
> +(check-end-of-sentence-space description)

'begin' is not needed here.  'when' and 'unless' include an implicit
'begin'.

>  
>  (define (check-inputs-should-be-native package)
>;; Emit a warning if some inputs of PACKAGE are likely to belong to its
> diff --git a/tests/lint.scm b/tests/lint.scm
> index 62a9df9..2c2a179 100644
> --- a/tests/lint.scm
> +++ b/tests/lint.scm
> @@ -53,6 +53,15 @@
>(check-description-style pkg
>  "description should start with an upper-case letter")))
>  
> +(test-assert "description: two spaces after end of sentence"
> +  (->bool
> +   (string-contains (call-with-warnings
> +  (lambda ()
> +(let ((pkg (dummy-package "x"
> + (description "Bad. Quite bad."
> +  (check-description-style pkg
> +"sentences in description should be followed by two 
> spaces")))
> +

It would be good to add some tests for the "common abbrevs" logic above.

Otherwise looks good to me, thanks!

  Mark

Updates for GNU Make, bash, gettext, openssl, coming soon!

[Mark H Weaver]

FYI, Hydra is currently building a new 'core-updates' branch with GNU
Make 4.1, bash 4.3.30, gettext 0.19.3, openssl 1.0.1j, and a few other
things.  As soon as Hydra has caught up on Intel platforms (probably in
a day or two), I'll merge these updates to master.

 Mark

Re: Update sqlite

[Mark H Weaver]

Andreas Enge  writes:
> needing sqlite, I wondered if I could not quickly update it to the latest
> version. It appears that sqlite-large-page-size-fix.patch does not apply
> any more. Mark, as you added it, could you maybe check if it is still needed?

Can you check whether the changes made in the patch are now present in
the new version?  We definitely need something like it, or else Guix
itself will stop working properly on my MIPS machines, including our
MIPS build slave for Hydra.

I got the patch from upstream, but they didn't want to apply it to their
stable branch.  I'm not sure whether the latest release is part of that
same branch or not.  For that matter, I never checked to see if they
applied it to their repo.

Thanks,
  Mark

Re: [PATCH] gnu: Add older ruby 1.8.7

[Mark H Weaver]

Pjotr Prins  writes:

> * gnu/packages/ruby.scm: Added older Ruby 1.8.7
> ---
>  gnu/packages/ruby.scm |   27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
> index ac751f5..0b10b87 100644
> --- a/gnu/packages/ruby.scm
> +++ b/gnu/packages/ruby.scm
> @@ -89,6 +89,33 @@ a focus on simplicity and productivity.")
>  (home-page "https://ruby-lang.org";)
>  (license license:ruby)))
>  
> +(define-public ruby-1.8
> +  (package (inherit ruby)
> +(name "ruby")
> +(version "1.8.7")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "ftp://ftp.ruby-lang.org/pub/ruby/1.8/";
> +   name "-" version "-p374.tar.bz2"))

What's that "-p374" in the file name?  If it's a patch level, then I
think it should be part of the version string.

 Mark

Re: [PATCH] gnu: Add older ruby 1.8.7

[Mark H Weaver]

Mark H Weaver wrote:
> What's that "-p374" in the file name?  If it's a patch level, then I
> think it should be part of the version string.

Pjotr Prins  wrote:
> Good point. How do we use patch levels anyway?

I'm sorry, I don't understand your question.  What does it mean to "use"
a patch level?

  Mark

Re: Updates for GNU Make, bash, gettext, openssl, coming soon!

[Mark H Weaver]

Mark H Weaver  writes:
> FYI, Hydra is currently building a new 'core-updates' branch with GNU
> Make 4.1, bash 4.3.30, gettext 0.19.3, openssl 1.0.1j, and a few other
> things.  As soon as Hydra has caught up on Intel platforms (probably in
> a day or two), I'll merge these updates to master.

I applied the updates to master.

 Mark

Suggestion: disable offloading for texlive builds on hydra?

[Mark H Weaver]

When texlive is built on hydra, the build slave that built it is tied up
for 12 hours or more waiting for the build outputs (over 3 gigabytes!)
to be transferred back to hydra.

By design, only one transfer can happen at a time from a given build
slave, so during those 12 hours, the build slave's CPU is left idle, and
typically another 3 built-but-not-yet-transferred packages must wait
until the texlive transfer finishes.

I suggest that we arrange for hydra.gnu.org to build texlive locally for
x86_64 and i686, to avoid this problem.

What do you think?

  Mark

Re: Suggestion: disable offloading for texlive builds on hydra?

[Mark H Weaver]

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

> John Darrington  skribis:
>
>> On Sun, Oct 26, 2014 at 03:36:03AM -0400, Mark H Weaver wrote:
>>  When texlive is built on hydra, the build slave that built it is tied up
>>  for 12 hours or more waiting for the build outputs (over 3 gigabytes!)
>>  to be transferred back to hydra.
>>  
>>  By design, only one transfer can happen at a time from a given build
>>  slave, so during those 12 hours, the build slave's CPU is left idle, and
>>  typically another 3 built-but-not-yet-transferred packages must wait
>>  until the texlive transfer finishes.
>>
>> Why is it designed like that?  It seems like a poor design to me.
>
> The rationale was that, in general, you just slow everything down by
> sending several things at once.

I have my doubts that it would slow things down very much, if at all.
The number of parallel transfers would still be limited to a small
number, typically 4 per build slave.  The expense associated with
running multiple processes on a CPU is mainly due to cache effects, but
I wouldn't expect that to be an issue with network connections,
especially when those connections are between the same two hosts.  The
practice of using multiple connections is well established in web
browsers and imap clients, as long as the number is not too large.

We're losing a huge amount of available CPU capacity in our build farm
(probably over 30 machine-hours per texinfo rebuild) in exchange for a
dubious increase in network efficiency.

The more I think about it, the more I agree with John that we've chosen
the wrong tradeoff here.  I think we should remove those mutexes.

> diff --git a/gnu/packages/texlive.scm b/gnu/packages/texlive.scm
> index e562b02..bc0ece7 100644
> --- a/gnu/packages/texlive.scm
> +++ b/gnu/packages/texlive.scm
> @@ -88,7 +88,7 @@
>("pkg-config" ,pkg-config)
>("python" ,python-2) ; incompatible with Python 3 (print syntax)
>("tcsh" ,tcsh)))
> -   (outputs '("out" "data"))
> +   (outputs '("out" "data" "doc"))
> (arguments
>  `(#:out-of-source? #t
>#:configure-flags
>
>
> Data point: there’s 1.6 GiB in texmf-dist/doc (which the patch above
> splits out), and 1.4 GiB in texmf-dist/fonts.

I'd definitely be in favor of splitting out the docs.

> Another option Andreas and I discussed a while back would be to use a
> fixed-output derivation for the data, since it’s really what it is.
> That’s a bit hacky though: we’d have to install it, compute the hash of
> the installed files, and then use that as the derivation’s output hash.

Hmm.  It is indeed a hack, but maybe worth considering.  When I think
about Guix users downloading over 3 GiB from our humble hydra quite
often just to have TeX, it makes me worry about our bandwidth
requirements.

Thanks,
  Mark

Re: [PATCH] gnu: Add older ruby 1.8.7

[Mark H Weaver]

Pjotr Prins  writes:
> We have package-name and package-version. Why not package-patch-level?
> I don't think it should be part of version.

I agree with Ludovic.  The patch-level is conceptually part of the
version.

We have a fair bit of program logic, APIs, and user interface elements
that assume that there's only one 'version' field.  All of those would
need to be changed to support an additional 'patch-level' field.  Doing
all of that work would require a compelling argument.  I don't see one.

  Mark

Re: [PATCH] list-packages: Display package usage count.

[Mark H Weaver]

Eric Bavier  writes:

> Ludovic Courtès writes:
>
>> Eric Bavier  skribis:
>>
>>> +  (define (users package)
>>> +(let ((n (length (package-transitive-dependents
>>> +  (find-packages-by-name* (package-name package)
>>> +  (package-version 
>>> package))
>>
>> Why not just (package-transitive-dependents package)?
>
> Because that would not accurately count the "true" number of dependents.

Agreed, but what you wrote doesn't fully address the problem either.

If we modify 'gnu-make', that's also going to affect 'gnu-make-boot0' in
commencement.scm.  Since that one has a different name ("make-boot0"),
your logic won't catch it.

Similarly, if you modify 'gcc-4.7', that's also going to affect
'gcc-4.8' (different version) which affects 'gcc-boot0' (with a
different name and version).

So, it seems to me that we need a way to find all packages that
'inherit' from the package we're changing, transitively.  I'm not sure
off-hand if that information is preserved, but if not, we should
probably arrange to preserve it somehow.

  Mark

Re: [PATCH] gnu: Add ruby 1.8.7

[Mark H Weaver]

Pjotr Prins  writes:
> * gnu/packages/ruby.scm: Added older Ruby 1.8.7

According to our conventions, this should be:

* gnu/packages/ruby.scm (ruby-1.8): New variable.

> ---
>  gnu/packages/ruby.scm |   27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
> index ac751f5..31cbe54 100644
> --- a/gnu/packages/ruby.scm
> +++ b/gnu/packages/ruby.scm
> @@ -89,6 +89,33 @@ a focus on simplicity and productivity.")
>  (home-page "https://ruby-lang.org";)
>  (license license:ruby)))
>  
> +(define-public ruby-1.8
> +  (package (inherit ruby)
> +(name "ruby")

Is there a reason to repeat the 'name' field here?
It should be inherited.

> +(version "1.8.7-p374")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "ftp://ftp.ruby-lang.org/pub/ruby/1.8/";
> +   name "-" version ".tar.bz2"))

In the ruby-2.1.3 package description, we used the http URI starting
with "http://cache.ruby-lang.org/pub/ruby/";.  It's probably better to
use that one, since 'http' has some advantages and our http client is
more robust.

> + (sha256
> +  (base32
> +   "1qq7khilwkayrhwmzlxk83scrmiqfi7lgsn4c63znyvz2c1lgqxl"
> +(arguments
> + `(#:test-target "test"
> +   #:parallel-tests? #f
> +   #:phases
> +(alist-cons-before
> + 'configure 'replace-bin-sh
> + (lambda _
> +   (substitute* '("Makefile.in"
> +  "ext/pty/pty.c"
> +  "io.c"
> +  "lib/mkmf.rb"
> +  "process.c")
> + (("/bin/sh") (which "sh"
> + %standard-phases)

It looks like the 'native-search-paths' field needs to be overridden,
since the existing one has "2.1.3" in it.

 Thanks!
   Mark

Re: [PATCH] gnu: Add ruby 1.8.7

[Mark H Weaver]

Pjotr Prins  writes:

> On Sun, Oct 26, 2014 at 07:33:51PM -0400, Mark H Weaver wrote:
>> Pjotr Prins  writes:
>> > * gnu/packages/ruby.scm: Added older Ruby 1.8.7
>> 
>> According to our conventions, this should be:
>> 
>> * gnu/packages/ruby.scm (ruby-1.8): New variable.
>
> Is a new package a variable? 

'ruby-1.8' is a Scheme variable that's bound to a package object.

I admit that I'm not fond of this convention -- I'd prefer "New package"
-- but it's what we've been doing, anyway.

> We used the same message with ruby2.  Where can I find these
> conventions, btw?

In broad strokes, we use the GNU changelog conventions:

  http://www.gnu.org/prep/standards/html_node/Change-Logs.html

but with some minor formatting differences.  However, the best thing is
to look in the commit history for examples close to what you're doing.

There is brief mention of this in the "Submitting Patches" section of
the HACKING file in the source tree.

>> It looks like the 'native-search-paths' field needs to be overridden,
>> since the existing one has "2.1.3" in it.
>
> I don't think it is used by 1.8.7. Does that matter?

Yes, otherwise users who install ruby 1.8.7 will be advised to set
GEM_PATH to $HOME/.guix-profile/lib/ruby/gems/2.1.3.

If setting GEM_PATH is not appropriate when using ruby 1.8.7, then you
should override it here to be the empty list, like so:

  (native-search-paths '())

 Thanks,
   Mark

Re: [PATCH] gnu: Add ruby 1.8.7

[Mark H Weaver]

Pjotr Prins  writes:

> On Sun, Oct 26, 2014 at 09:43:22PM -0400, Mark H Weaver wrote:
>> In broad strokes, we use the GNU changelog conventions:
>> 
>>   http://www.gnu.org/prep/standards/html_node/Change-Logs.html
>> 
>> but with some minor formatting differences.  However, the best thing is
>> to look in the commit history for examples close to what you're doing.
>> 
>> There is brief mention of this in the "Submitting Patches" section of
>> the HACKING file in the source tree.
>
> I read those earlier. I used a commit message we used before. I think
> that if you are serious about convention you should point to a real
> list of allowed standard messages.

The commit log is full of examples, but I agree that it would be good to
have more documentation on this.  There's a lot to do, and we're a small
team.

> Now it looks arbitrary and makes the submitter look stupid.

I agree that the conventions are arbitrary, and could probably use
improvement, but I also think there's some value in keeping things
consistent.  I don't think it makes you look stupid.  I'm sorry if I
came off that way.

>> >> It looks like the 'native-search-paths' field needs to be overridden,
>> >> since the existing one has "2.1.3" in it.
>> >
>> > I don't think it is used by 1.8.7. Does that matter?
>> 
>> Yes, otherwise users who install ruby 1.8.7 will be advised to set
>> GEM_PATH to $HOME/.guix-profile/lib/ruby/gems/2.1.3.
>
> Ah, that is what it is for. Actually the build did not give me that
> message.

The message is supposed to be shown when you install the package using
"guix package -i", but I see that it wasn't working.  The reason is that
"lib/ruby/gems/2.1.3" doesn't actually exist in the built ruby package.
Instead, there's "lib/ruby/gems/2.1.0".  I guess that should be fixed in
a separate commit.

If the search-path-specification contains a directory that exists and is
not already in your GEM_PATH, you should see the message when you
install ruby, or when you run "guix package --search-paths".

> I DO get a load of messages such as
>
>   
> strip:/gnu/store/icz59y35qqmm4jcrnkqx7d73xlzsq0lq-ruby-1.8.7-p374/lib/ruby/1.8/rexml/attlistdecl.rb:
>   File format not recognized
>
> is there a way to prevent files with a .rb extension or ruby shebang
> to be stripped?

In theory the default 'strip' phase could be replaced by one that's more
selective, but please don't do that.

The problem happens in almost every package, so the improvements should
be made in the default 'strip' phase.  The relevant procedure is 'strip'
in guix/build/gnu-build-system.scm, but beware that changing that file
(or just about anything else in that directory) will trigger a full
rebuild of all packages.  It would be nice to do at some point, but it's
quite far down on our TODO list.

 Regards,
   Mark

Re: Some documentation

[Mark H Weaver]

Hi Pjotr,

Pjotr Prins  writes:

> I am documenting my GNU Guix journey here:
>
>   https://github.com/pjotrp/guix-notes

This is a great start, thanks for writing this up! :)

I have a few comments.  In your HACKING file, you mentioned this as an
alternative to "guix package -i ruby":

  guix package -i $(guix build ruby)

Passing a raw directory name to "guix package -i", while occasionally
useful, is inferior in many ways.  I've forgotten the detailed effects,
but the main problem is that Guix doesn't really know what package it
is, it just blindly merges that directory into your profile, so things
like upgrades, propagated inputs, and search-path advisories aren't
handled correctly.

Also, in your RUBY file, you wrote:

> The libraries that come with Ruby are also symlinked via
> ~/.guix-profile/lib/ruby/2.1.0/. The numbering does not matter too
> much since it points to an immutable (read-only) directory in
>
> ~/.guix-profile/lib -> 
> /gnu/store/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/lib
>
> (FIXME: the symlink should be at lib/ruby level)

When a profile is built, the symlinks are always placed as close to the
root as possible.  In the case above, your ruby package must have been
the only thing in your profile that had a top-level 'lib' directory.  If
you later install another package that contains 'lib', you'll find that
the newly-built profile will create 'lib' as a directory and move the
symlinks further down.

  Mark

Re: [PATCH] gnu: Add ruby 1.8.7 package

[Mark H Weaver]

Pjotr Prins  writes:
> * gnu/packages/ruby.scm: (ruby-1.8): New variable.

I pushed this with some minor changes to the commit log, and with the
unneeded (guix hash) import removed.  I also followed it up with another
commit making some improvements to the original ruby package.

Thanks!
  Mark

Re: Problems with downloading from https

[Mark H Weaver]

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

> Alex Kost  skribis:
>
>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>
>>> Alex Kost  skribis:
>>>
 Yes, I installed gnutls, but it didn't work because I didn't set the
 right guile paths: “guix package --search-paths” recommends
 "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site/2.0"
 but "gnutls.scm" is actually placed in
 "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site"
 so ‘(use-modules (gnutls))’ failed for me.
>>>
>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>> configure flag so that modules go to site/2.0.  Could you do that?

Alex committed this change, and it broke all https downloads in Guix,
leading to hydra build failures.  For example, see:

  http://hydra.gnu.org/build/132928/nixlog/1/raw

The reason is that guix/download.scm contains this code:

--8<---cut here---start->8---
  ;; Add GnuTLS to the inputs and to the load path.
  #~(eval-when (load expand eval)
  (set! %load-path
(cons (string-append #$(gnutls-package)
 "/share/guile/site")
  %load-path)))
  #~#t)
--8<---cut here---end--->8---

For now, I think we should revert this commit and discuss it further
before proceeding.

>> Yes, but I'm a little concerned.  Should it really be so?  What about
>> guile-1.8; isn't it supposed to use gnutls module as well?
>
> 1.8 has long been deprecated, so let’s not worry about it.

I think Alex was right to be concerned.  We'll have the same problem
when Guile 2.2 comes around, and then again for 2.4.  I'm reluctant to
hardcode "2.0" into the code above.  Think about what it implies for
GnuTLS in the future.  Will they be expected to install their modules
into site/2.0, site/2.2, site/2.4, etc?  Do we really want to advocate
this practice to projects that install Guile modules?

   Mark

Re: Imlib2 license

[Mark H Weaver]

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

> Alex Kost  skribis:
>
>> OK for the attached patch?
>>
>>
>> From b7564a7f68fe2d2d74d0d1bc768eb19dbab09a36 Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Sun, 26 Oct 2014 15:27:56 +0300
>> Subject: [PATCH] licenses: Add 'imlib2'.
>>
>> * guix/licenses.scm (imlib2): New variable.
>> * gnu/packages/image.scm (imlib2): Use it.
>
> OK!

FYI, this patch broke the package 'feh' and caused fatal evaluation
errors on hydra, because gnu/packages/feh.scm used the package 'imlib2'
from (gnu packages image) and also imported (guix licenses) without a
prefix.  'imlib2', used as an input to 'feh', ended up being a license
object.  I fixed it in commit 4e2f98c5394c515a5849be3aad6d06e8ad89807b.

  Mark

Re: ‘strip’ phase

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>>> I DO get a load of messages such as
>>>
>>>   
>>> strip:/gnu/store/icz59y35qqmm4jcrnkqx7d73xlzsq0lq-ruby-1.8.7-p374/lib/ruby/1.8/rexml/attlistdecl.rb:
>>>   File format not recognized
>>>
>>> is there a way to prevent files with a .rb extension or ruby shebang
>>> to be stripped?
>>
>> In theory the default 'strip' phase could be replaced by one that's more
>> selective, but please don't do that.
>>
>> The problem happens in almost every package, so the improvements should
>> be made in the default 'strip' phase.  The relevant procedure is 'strip'
>> in guix/build/gnu-build-system.scm, but beware that changing that file
>> (or just about anything else in that directory) will trigger a full
>> rebuild of all packages.  It would be nice to do at some point, but it's
>> quite far down on our TODO list.
>
> I think the ‘strip’ phase is fine this way: sure, it ends up invoking
> ‘strip’ on files that are not ELF files, but it’s harmless.  So we get
> these extra warnings in the build log, but they are really harmless.

Large numbers of spurious warnings are not harmless, because they make
it unlikely that anyone will notice the warnings worth our attention.
They condition us to ignore all warnings, because it's too much work to
look through them all.

> Conversely, attempts to be more selective may miss actual ELF files.

True, but this is more harmless than the spurious warnings, IMO.  It
merely means that we failed to save some disk space.

IMO, the best solution is to check for the presence of ELF headers
ourselves.  We already have ELF code in Guile master.

What do you think?

  Mark

Re: ‘strip’ phase

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> IMO, the best solution is to check for the presence of ELF headers
>> ourselves.  We already have ELF code in Guile master.
>
> Yes, that sounds good.  Instead of relying on Guile’s ELF code, perhaps
> it would be enough to check for the presence of the ELF magic bytes?

Agreed.  The test need not be perfect, because the worst that can happen
is an _occasional_ warning from 'strip', which really will be harmless :)

Thanks,
  Mark

Re: Problems with downloading from https

[Mark H Weaver]

Alex Kost  writes:

> Mark H Weaver (2014-10-27 12:06 +0300) wrote:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Alex Kost  skribis:
>>>
>>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>>
>>>>> Alex Kost  skribis:
>>>>>
>>>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>>>> right guile paths: “guix package --search-paths” recommends
>>>>>> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site/2.0"
>>>>>> but "gnutls.scm" is actually placed in
>>>>>> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site"
>>>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>>>
>>>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>>>> configure flag so that modules go to site/2.0.  Could you do that?
>>
>> Alex committed this change, and it broke all https downloads in Guix,
>> leading to hydra build failures.  For example, see:
>>
>>   http://hydra.gnu.org/build/132928/nixlog/1/raw
>
> [...]
>
> OMG!  I'm sorry about that.  And thanks for fixing imlib2 license issue.
>
> I'm feeling guilty and I think I shouldn't touch anything outside
> "emacs" directory.  Sorry again.

No, not at all!  We all very much appreciate your contributions, Alex,
and you only did what Ludovic asked you to do.  Anyway, it's not as
though a few missing builds on Hydra is the end of the world.  That
happens quite regularly anyway, so please don't worry about it.

  Mark

Re: Problems with downloading from https

[Mark H Weaver]

Alex Kost  writes:

> Why not just allow gnutls and other packages to install guile modules in
> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
> suggested at
> ?

In my opinion, this is the right fix.  There is plenty of Guile code
that works on both Guile 1.8 and Guile 2.0, so there's no need to put
Scheme modules in versioned directories.  We provide 'cond-expand' when
it's really needed, after all.

Guile 2 puts both "site/2.0" and "site" in its load path by default,
which signals to developers that they can choose either location.

Furthermore, if changing the installation directory of the GnuTLS
modules broke Guix, there's a non-trivial possibility that we might
break something else.

Please, let's leave the GnuTLS modules where they are, and add "site" to
the search-path-specification, as Alex suggests.

What do you think?

  Mark

Re: [PATCH] emacs: Add 'pretty-sha-path'.

[Mark H Weaver]

Hi Alex,

Alex Kost  writes:

> +(defcustom pretty-sha-path-regexp
> +  (rx "/"
> +  (or "nix" "gnu")
> +  "/store/"
> +  (group (= 32 alnum)))

I'm not sure if it's worth it, but you could make this regexp more
restrictive.  Nix hashes can only contain the following 32 characters:

  "0123456789abcdfghijklmnpqrsvwxyz"

i.e. digits and lowercase ASCII letters excluding (e o u t).  See
'base32Chars' in nix/libutil/hash.cc.

  Mark

Re: Acl

[Mark H Weaver]

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

> ndreas Enge  skribis:
>
>> Adding optional inputs to kdelibs, I notice that acl is not recognised.
>> The reason is that the header files are not installed. Would that be easy
>> to modify? Maybe by changing the line
>>   (zero? (system* "make" "install" "install-lib")))
>
> Commit 16755848 added ‘install-lib’ (before that libacl.so was not
> installed), but yeah, installing headers would have been cool too.  ;-)

Indeed.  I would apologize for overlooking this, but doc/INSTALL
specifically recommends "make install install-lib", and "install-dev"
appears to be completely undocumented :-/

  Mark

Re: Handling ‘file’ CVE

[Mark H Weaver]

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

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> What about this other option: make another public package, ‘file-5.20’,
>> next to ‘file’, such that when a user explicitly installs ‘file’, they
>> get the new one?
>
> I ended up taking that route, in commit 310081e.

FWIW, I think it would be better for 'file' to be bound to the fixed
package, and to add a 'file/fixed' that points to the old buggy one.
Then 'file/fixed' could be used in some selected places.

'file' is used as a plain input (as opposed to native-input) in several
places that make me a bit nervous, e.g. the 'transmission' bittorrent
client (is 'file' being used at runtime on downloaded files?), and also
'aegis', 'quilt', and 'cmake'.

Finally, 'file' is a propagated-input for 'intltool', which means that
if anyone installs 'intltool' in their profile, they will have the buggy
'file' in their PATH.

Regards,
  Mark

Re: Gluglug X60 Guix howto

[Mark H Weaver]

白熊  writes:

> On 2014年11月23日 20:22:24 GMT+03:00, Alex Sassmannshausen 
>  wrote:
>>Hello,
>>
>>I received a request for instructions on how to get Guix running as
>>standalone on the Gluglug X60 — my work is ongoing (I haven't
>>reconfigured the Grub BIOS, nor have I got wireless working yet), but
>>a first draft may help other owners.
>
> I hope you can get the wireless working! Especially during Guix install...

I run standalone Guix on my Gluglug X60 with wireless.  All you have to
do is create a wpa_supplicant.conf file containing stanzas like this:

--8<---cut here---start->8---
network={
ssid="my network name"
key_mgmt=WPA-PSK
psk="my network password"
}
--8<---cut here---end--->8---

and then run:

  wpa_supplicant -i wlp2s0 -c /path/to/wpa_supplicant.conf -B
  dhclient wlp2s0

If you have problems connecting to wireless, you can replace the "-B"
with "-d" in the wpa_supplicant command, which will run it in the
foreground with debugging output enabled.

 Regards,
   Mark

Re: [PATCH] gnu: Add Glulxe.

[Mark H Weaver]

Eric Bavier  writes:

> This is a bit terse, IMHO.  Perhaps something like:
>
> (let* ((out (assoc-ref outputs "out"))
>(inc (string-append out "/include")))
>   (begin
> (mkdir-p inc)
> (for-each
>   (lambda (f) (copy-file f (string-append inc "/" f)))
>   '("glk.h" "glkstart.h" "gi_blorb.h" "gi_dispa.h" "Make.glkterm"))
> (mkdir-p lib)
> (copy-file "libglkterm.a" (string-append out "/lib/libglkterm.a"

It's not important, but FYI the 'begin' above is not needed.  The 'let*'
includes an implicit 'begin'.

  Mark

Re: Packaging Coq

[Mark H Weaver]

Andreas Enge  writes:

> On Thu, Dec 04, 2014 at 05:02:27AM +0400, Nikita Karetnikov wrote:
>>   (alist-replace 'build
>>  (lambda _
>>(system* "make" "world"))
>
> Instead of this, you could use
>   #:make-flags '("world")

IMO, this is a misuse of #:make-flags.  'world' is not a make flag, it
is a make *target*.  The make flags are also passed to 'make' during the
default 'check' and 'install' phases.

  Mark

Re: use zsh as login shell

[Mark H Weaver]

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

> 宋文武  skribis:
>
>> +  (mlet %store-monad ((bash-profile (text-file "bash_profile" "\
>> +# honor ~/.bashrc if the shell is interactive
>> +[[ $- == *i* ]] && source ~/.bashrc
>
> I don’t think the test is needed, because ~/.bash_profile is only read
> by interactive Bash.

Indeed.  However, it would be good to check if ~/.bashrc exists.
Section 6.2 of the Bash manual suggests this:

  if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

>> +# load system-wide environment varibales
>> +source /etc/environment
>> +
>> +# common varibales for user profile
>> +export PATH=$HOME/.guix-profile/bin:$HOME/.guix-profile/sbin:$PATH
>> +export INFOPATH=$HOME/.guix-profile/share/info:$INFOPATH\n"))
>> +  (bashrc (text-file "bashrc" "\
>> +PS1='\\u@\\h \\w\\$ '
>
> I think PS1 should go to /etc/profile.  WDYT?

I agree with 宋文武 that the PS1 setting belongs in the default
~/.bashrc skeleton.  I would prefer to keep settings like this, that are
purely a matter of personal taste, out of system-wide files.  Also,
/etc/profile is read by other shells, and I don't know that the syntax
above is portable.

Regards,
  Mark

Re: Packaging Coq

[Mark H Weaver]

Nikita Karetnikov  writes:
> Does anyone know how to proceed?

It would help if you told us something about the problem you ran into,
preferably with relevant excerpts of the failed build output.

I'm also interested in Coq, and attempted to package it about 6 weeks
ago.  I started by trying to update to ocaml 4.02.x, but there were many
test suite failures that looked non-trivial to debug.  I stalled there.

If I were to proceed without the ocaml update, I would start by
packaging "camlp5", which is listed as a build dependency in the Coq
build documentation (INSTALL in the top-level source directory).

It looks like we don't yet have camlp5, and that you didn't attempt to
package it.  Maybe that's the problem?

 Regards,
   Mark

Re: Packaging Coq

[Mark H Weaver]

Andreas Enge  writes:

> On Thu, Dec 04, 2014 at 06:56:25PM -0500, Mark H Weaver wrote:
>> Andreas Enge  writes:
>> > Instead of this, you could use
>> >   #:make-flags '("world")
>> IMO, this is a misuse of #:make-flags.  'world' is not a make flag, it
>> is a make *target*.  The make flags are also passed to 'make' during the
>> default 'check' and 'install' phases.
>
> In that case, maybe we should add a variable 'build-target' to our build
> system.

Sounds reasonable to me, although it should be 'build-targets' since
there is often more than one.  Ditto for 'install-targets' and
'check-targets' (or 'test-targets') if we don't already have them.

On the other hand, I'm not sure that these are needed often enough to
justify these new variables.  What do others think?

 Mark

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Federico Beffa  writes:

> On Tue, Dec 9, 2014 at 8:30 PM, Federico Beffa  wrote:
>> I've then updated pix-buf to the latest and it builds fine, but have 2
>> out of 74 test failures.
>
> gdk-pixbuf 2.31.2 (latest) fails 2 tests, but 2.31.1 passes all of them.

This is a bug in 2.31.2, where they forgot to include a test image in
the tarball.  See:

  https://mail.gnome.org/archives/commits-list/2014-December/msg01800.html

 Mark

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Federico Beffa  writes:
> What do you prefer? Revert to gobject-introspection 1.38.0, or got
> down the version dependency hell?

I've started working on this.  It turns out we have to go down quite a
rabbit hole.  Among other things, 'eudev' must be updated, and we will
lose 'udev' entirely.  I'll see how deep the rabbit hole goes and report
back.

  Mark

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Mark H Weaver  writes:

> Federico Beffa  writes:
>> What do you prefer? Revert to gobject-introspection 1.38.0, or got
>> down the version dependency hell?
>
> I've started working on this.  It turns out we have to go down quite a
> rabbit hole.  Among other things, 'eudev' must be updated [...]

It turns out that even the most recent release of 'eudev' (2.1.1) fails
to work with gobject-introspection 1.42.0.  I looked in their git repo,
and didn't see any commits addressing this issue.

I think we should revert the gobject-introspection update for now.

What do you think?

  Mark

Re: hydra python2-numpy-1.9.1 failure

[Mark H Weaver]

Federico Beffa  writes:

> I've noticed that on hydra python2-numpy-1.9.1 for x86_64-linux (and
> other architectures) fails to pass the test procedure (really the
> module local version without documentation called
> python2-numpy-bootstrap-1.9.1):
>
> http://hydra.gnu.org/build/172563
>
> So, I've built it locally to investigate and on my machine it builds
> without errors. The hash in the store is the same as on hydra
>
> /gnu/store/wyzv0xw9fi0hks5x1kagy2nl2sykbr7l-python2-numpy-bootstrap-1.9.1
>
> so the inputs should be the same.
>
> I'm at commit 57c3f71632692d1e2e12e5d2db5c2cc4c6e075c9 (of today). The
> only part which is not up to date on my system is the daemon which is
> still from the 0.7 release (back then I've setup an init script to
> start it automatically at boot).
>
> Any hint at what could be going wrong on hydra?

It's not uncommon for some tests to fail occasionally in certain
packages.  Reasons I've seen include: timeouts set too short, race
conditions, randomized tests that fail for some values, and dependencies
on the kernel version and/or configuration.  We've had to debug these
problems on a case-by-case basis.  Sometimes we've disabled the
unreliable tests, or even disabled the entire test suite.

   Mark

[PATCH] gnu: pcre: Update to 8.36 and enable JIT support

[Mark H Weaver]

>From 5796cf1178fbcf41ef1c3d6406adb992d7e71dd0 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 10 Dec 2014 15:56:00 -0500
Subject: [PATCH] gnu: pcre: Update to 8.36 and enable JIT support.

* gnu/packages/pcre.scm (pcre): Update to 8.36.  Enable JIT support.
---
 gnu/packages/pcre.scm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/pcre.scm b/gnu/packages/pcre.scm
index 54a3e22..e6c9ab8 100644
--- a/gnu/packages/pcre.scm
+++ b/gnu/packages/pcre.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013 Andreas Enge 
+;;; Copyright © 2014 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -27,20 +28,21 @@
 (define-public pcre
   (package
(name "pcre")
-   (version "8.32")
+   (version "8.36")
(source (origin
 (method url-fetch)
 (uri (string-append "mirror://sourceforge/pcre/pcre/"
 version "/pcre-" version ".tar.bz2"))
 (sha256
  (base32
-  "0m8gvrf1q0iwll4csirvvj98xygw4cy7r14i5l53ivsqs2dzn4x9"
+  "1fs5p1z67m9f4xnyil3s4lhgyld78f7m4d1yawpyhh0cvrbk90zg"
(build-system gnu-build-system)
(inputs `(("bzip2" ,bzip2)
  ("readline" ,readline)
  ("zlib" ,zlib)))
(arguments
 `(#:configure-flags '("--enable-utf"
+  "--enable-jit"
   "--enable-pcregrep-libz"
   "--enable-pcregrep-libbz2"
   "--enable-pcretest-libreadline")))
-- 
2.1.2

[PATCH] gnu: Add nginx

[Mark H Weaver]

>From 359d1b0a7dcb7320ff28bbabe792e0d8e6d399ad Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 10 Dec 2014 17:39:48 -0500
Subject: [PATCH] gnu: Add nginx.

* gnu/packages/web.scm (nginx): New variable.
---
 gnu/packages/web.scm | 60 
 1 file changed, 60 insertions(+)

diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 0731d0b..c64f874 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2013 Andreas Enge 
 ;;; Copyright © 2013 Aljosha Papsch 
 ;;; Copyright © 2014 Ludovic Courtès 
+;;; Copyright © 2014 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -19,6 +20,7 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages web)
+  #:use-module (ice-9 match)
   #:use-module ((guix licenses) #:prefix l:)
   #:use-module (guix packages)
   #:use-module (guix download)
@@ -26,6 +28,7 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system perl)
   #:use-module (guix build-system cmake)
+  #:use-module (gnu packages linux)
   #:use-module (gnu packages apr)
   #:use-module (gnu packages asciidoc)
   #:use-module (gnu packages docbook)
@@ -77,6 +80,63 @@ and its related documentation.")
 (license l:asl2.0)
 (home-page "https://httpd.apache.org/";)))
 
+(define-public nginx
+  (package
+(name "nginx")
+(version "1.6.2")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://nginx.org/download/nginx-";
+  version ".tar.gz"))
+  (sha256
+   (base32
+"060s77qxhkn02fjkcndsr0xppj2bppjzkj0gn84svrykb4lqqq5m"
+(build-system gnu-build-system)
+(inputs `(("pcre" ,pcre)
+  ("openssl" ,openssl)
+  ("zlib" ,zlib)))
+(arguments
+ `(#:tests? #f  ; no test target
+   #:phases
+   (alist-cons-before
+'configure 'patch-/bin/sh
+(lambda _
+  (substitute* "auto/feature"
+(("/bin/sh") (which "bash"
+(alist-replace
+ 'configure
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let ((flags
+  (list (string-append "--prefix=" (assoc-ref outputs "out"))
+"--with-http_ssl_module"
+"--with-pcre-jit"
+;; Even when not cross-building, we pass the
+;; --crossbuild option to avoid customizing for the
+;; kernel version on the build machine.
+,(let ((system "Linux") ; uname -s
+   ;; uname -r
+   (release (package-version linux-libre-headers))
+   ;; uname -m
+   (machine (match (or (%current-target-system)
+   (%current-system))
+  ("x86_64-linux"   "x86_64")
+  ("i686-linux" "i686")
+  ("mips64el-linux" "mips64"
+   (string-append "--crossbuild="
+  system ":" release ":" machine)
+ (setenv "CC" "gcc")
+ (format #t "environment variable `CC' set to `gcc'~%")
+ (format #t "configure flags: ~s~%" flags)
+ (zero? (apply system* "./configure" flags
+ %standard-phases
+(home-page "http://nginx.org";)
+(synopsis "HTTP and reverse proxy server")
+(description
+ "Nginx (\"engine X\") is a high-performance web and reverse proxy server
+created by Igor Sysoev.  It can be used both as a standalone web server
+and as a proxy to reduce the load on back-end HTTP or mail servers.")
+(license (list l:bsd-2 l:bsd-3 l:bsd-4 l:expat
+
 (define-public json-c
   (package
 (name "json-c")
-- 
2.1.2

Re: hydra python2-numpy-1.9.1 failure

[Mark H Weaver]

Federico Beffa  writes:

> On Wed, Dec 10, 2014 at 7:33 PM, Mark H Weaver  wrote:
>> It's not uncommon for some tests to fail occasionally in certain
>> packages.  Reasons I've seen include: timeouts set too short, race
>> conditions, randomized tests that fail for some values, and dependencies
>> on the kernel version and/or configuration.  We've had to debug these
>> problems on a case-by-case basis.  Sometimes we've disabled the
>> unreliable tests, or even disabled the entire test suite.
>
> Thanks for the input! It looks like on hydra the failure is
> reproducible. I would therefore tend to discard randomized tests. Do
> you happen to know the timeout for tests? The test fails after
> 17seconds which is not very long.

Any such timeout would be built in to the test suite of that package.
IIRC, the only relevant timeout that guix-daemon imposes is this: if the
build is silent (no output) for 1 hour, the build is aborted.

> Now that you mention race conditions, I remember having a hard time
> with parallel builds in ATLAS; and numpy makes use of it. I may try
> adding '#:parallel-tests? #f'.

It's worth a try.  We currently need that in over 20 packages.

  Mark

Re: [PATCH] gnu: Add nginx

[Mark H Weaver]

Mark H Weaver  writes:
> From 359d1b0a7dcb7320ff28bbabe792e0d8e6d399ad Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Wed, 10 Dec 2014 17:39:48 -0500
> Subject: [PATCH] gnu: Add nginx.

Based on my experiences attempting to deploy this server in practice,
the compile-time configuration needs more work.  I'll post an updated
version later.

  Mark

Re: [PATCH] gnu: pcre: Update to 8.36 and enable JIT support

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> From 5796cf1178fbcf41ef1c3d6406adb992d7e71dd0 Mon Sep 17 00:00:00 2001
>> From: Mark H Weaver 
>> Date: Wed, 10 Dec 2014 15:56:00 -0500
>> Subject: [PATCH] gnu: pcre: Update to 8.36 and enable JIT support.
>>
>> * gnu/packages/pcre.scm (pcre): Update to 8.36.  Enable JIT support.
>
> OK!
>
> Is JIT supported everywhere, or is it automatically turned off on
> platforms that don’t support it?

According to the docs, passing "--enable-jit" will cause the compilation
to fail on platforms not supported by their JIT, so we might have to
make that flag conditional in the future.  However, the build and test
suite passed on MIPS, and they support ARM as well, so I think it'll be
fine for the foreseeable future.

  Mark

Re: [PATCH 11/15] gnu: Add xfce4-settings.

[Mark H Weaver]

宋文武  writes:

> * gnu/packages/xfce.scm (xfce4-settings): New variable.
> ---
>  gnu/packages/xfce.scm | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
> index 5f15594..c601852 100644
> --- a/gnu/packages/xfce.scm
> +++ b/gnu/packages/xfce.scm
> @@ -310,3 +310,33 @@ your system in categories, so you can quickly find and 
> launch them.")
>   "Session manager for Xfce, it will restores your session on startup and
>  allows you to shutdown the computer from Xfce.")
>  (license gpl2+)))
> +
> +(define-public xfce4-sesttings

The variable name above has a typo:
  'xfce4-sesttings' ->
  'xfce4-settings'.

> +  (package
> +(name "xfce4-settings")
> +(version "4.10.0")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "http://archive.xfce.org/xfce/4.10/src/";
> +  name "-" version ".tar.bz2"))

Instead of putting "4.10" directly in the string above, how about this:

(uri (string-append "http://archive.xfce.org/xfce/";
(version-major+minor version)
"/src/" name "-" version ".tar.bz2"))

This way, when the package is updated to a new version, there will be
one less thing to change.  The same change could be made to many of your
other xfce packages.

'version-major+minor' is in the (guix utils) module, so you'll need to
add that to the import list.

Thanks for working on this!

  Mark

Re: [PATCH] gnu: Add nginx

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> From 359d1b0a7dcb7320ff28bbabe792e0d8e6d399ad Mon Sep 17 00:00:00 2001
>> From: Mark H Weaver 
>> Date: Wed, 10 Dec 2014 17:39:48 -0500
>> Subject: [PATCH] gnu: Add nginx.
>>
>> * gnu/packages/web.scm (nginx): New variable.
>
> LGTM, but we’ll wait for the next iteration if you want.
>
>> +(license (list l:bsd-2 l:bsd-3 l:bsd-4 l:expat
>
> Can you add a comment saying if it’s an ‘or’ or something else?

Good point.  Here's an updated patch.

  Mark

>From 92e58c3b80d5c22969de9f242d42528f27191146 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 10 Dec 2014 17:39:48 -0500
Subject: [PATCH] gnu: Add nginx.

* gnu/packages/web.scm (nginx): New variable.
---
 gnu/packages/web.scm | 66 
 1 file changed, 66 insertions(+)

diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 0731d0b..2bccd57 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2013 Andreas Enge 
 ;;; Copyright © 2013 Aljosha Papsch 
 ;;; Copyright © 2014 Ludovic Courtès 
+;;; Copyright © 2014 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -19,6 +20,7 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages web)
+  #:use-module (ice-9 match)
   #:use-module ((guix licenses) #:prefix l:)
   #:use-module (guix packages)
   #:use-module (guix download)
@@ -26,6 +28,7 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system perl)
   #:use-module (guix build-system cmake)
+  #:use-module (gnu packages linux)
   #:use-module (gnu packages apr)
   #:use-module (gnu packages asciidoc)
   #:use-module (gnu packages docbook)
@@ -77,6 +80,69 @@ and its related documentation.")
 (license l:asl2.0)
 (home-page "https://httpd.apache.org/";)))
 
+(define-public nginx
+  (package
+(name "nginx")
+(version "1.6.2")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://nginx.org/download/nginx-";
+  version ".tar.gz"))
+  (sha256
+   (base32
+"060s77qxhkn02fjkcndsr0xppj2bppjzkj0gn84svrykb4lqqq5m"
+(build-system gnu-build-system)
+(inputs `(("pcre" ,pcre)
+  ("openssl" ,openssl)
+  ("zlib" ,zlib)))
+(arguments
+ `(#:tests? #f  ; no test target
+   #:phases
+   (alist-cons-before
+'configure 'patch-/bin/sh
+(lambda _
+  (substitute* "auto/feature"
+(("/bin/sh") (which "bash"
+(alist-replace
+ 'configure
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let ((flags
+  (list (string-append "--prefix=" (assoc-ref outputs "out"))
+"--with-http_ssl_module"
+"--with-pcre-jit"
+"--with-ipv6"
+"--with-debug"
+;; Even when not cross-building, we pass the
+;; --crossbuild option to avoid customizing for the
+;; kernel version on the build machine.
+,(let ((system "Linux"); uname -s
+   (release "2.6.32")  ; uname -r
+   ;; uname -m
+   (machine (match (or (%current-target-system)
+   (%current-system))
+  ("x86_64-linux"   "x86_64")
+  ("i686-linux" "i686")
+  ("mips64el-linux" "mips64"
+   (string-append "--crossbuild="
+  system ":" release ":" machine)
+ (setenv "CC" "gcc")
+ (format #t "environment variable `CC' set to `gcc'~%")
+ (format #t "configure flags: ~s~%" flags)
+ (zero? (apply system* "./configure" flags
+ %standard-phases
+(home-page "http://nginx.org";)
+(synopsis "HTTP and reverse proxy server")
+(description
+ "Nginx (\"engine X\") is a high-performance web and reverse proxy server
+created by Igor Sysoev.  It can be used both as a standalone web server
+and as a proxy to reduce the load on back-end HTTP or mail servers.")
+;; Almost all of nginx is distributed under the bsd-2 license.
+;; The exceptions are:
+;;   * The 'nginx-http-push' module is covered by the expat license.
+;;   * The 'nginx-development-kit' module is mostly covered by bsd-3,
+;; except for two source files which are bsd-4 licensed.
+(license (list l:bsd-2 l:expat l:bsd-3 l:bsd-4
+
 (define-public json-c
   (package
 (name "json-c")
-- 
2.1.2

Re: [PATCH v3] gnu: Add bullet.

[Mark H Weaver]

Tomas Cech  writes:

> At Thu, 11 Dec 2014 22:09:22 -0500,
> David Thompson wrote:
>> 
>> Tomáš Čech  writes:

[...]

>> > +(define-public bullet
>> > +  (package
>> > +(name "bullet")
>> > +(version "2.82")
>> > +(source (origin
>> > +  (method url-fetch)
>> > +  (uri (string-append 
>> > "https://bullet.googlecode.com/files/bullet-";
>> > +  version "-r2704.tgz"))
>> 
>> I remember there being some discussion about dashes in version numbers,
>> and I can't remember the outcome.  If there's no issue, I think that the
>> "-r2704" should be part of the version number string.
>
> I'm pretty sure that this version is generally refered as '2.82' only, even 
> on their own pages:
> http://bulletphysics.org/wordpress/?p=393.
>
> Gentoo has 2.82:
> http://packages.gentoo.org/package/sci-physics/bullet
>
>
> Debian is referring to that as 2.82-r2704:
> https://packages.debian.org/source/sid/misc/bullet

I agree with David, and Debian.  The fact that they include "-r2704" in
their tarball name suggests that they might release a newer version
called "2.82-r2705", and I want Guix to be able to answer the question
"which version is newer?".  If 2.82-r2705 fixes a problem, I want to be
able to see if the version I have installed still has that problem.
Does that make sense?

Regards,
  Mark

Re: [PATCH 03/15] gnu: Add xfconf.

[Mark H Weaver]

宋文武  writes:
> * gnu/packages/xfce.scm (xfconf): New variable.

This failed to build on i686-linux.  For details and build log, see:

  http://hydra.gnu.org/build/173095

Could you look into it?

 Mark

Re: [PATCH] gnu: Add samtools

[Mark H Weaver]

Ricardo Wurmus  writes:
> From c4cae6d77e00491cfd78fe03da8ab617bc1732f2 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Thu, 11 Dec 2014 15:48:22 +0100
> Subject: [PATCH] gnu: Add samtools

This built successfully on x86_64, but on i686 its test suite shows 87
failures ("SAM files differ").  See:

  http://hydra.gnu.org/build/173180
  http://hydra.gnu.org/build/173180/log/raw

Would you be willing to investigate?  On your existing guix system, you
could start with:

  guix build --system=i686-linux --keep-failed

It fails similarly on mips64el, but that will be hard for you to debug
and probably not so important.

 Mark

Re: [PATCH] gnu: Add bedtools

[Mark H Weaver]

Ricardo Wurmus  writes:

> From c8d71da303ff6b82a30db542d382cab57a00699e Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Thu, 11 Dec 2014 17:37:16 +0100
> Subject: [PATCH] gnu: Add bedtools

Ludovic mostly covered this, but I have two additional suggestions:

> + (alist-replace
> +  'install (lambda* (#:key outputs #:allow-other-keys)

Please align the lambda* under 'install.

> + (let* ((out (assoc-ref outputs "out"))
> +(bin (string-append out "/bin"))
> +(tools
> + '("bamToFastq" "mapBed" "shuffleBed" 
> "bed12ToBed6" "bedToBam"
> +   "multiIntersectBed" "complementBed" 
> "randomBed" "tagBam" "sortBed"
> +   "annotateBed" "clusterBed" 
> "fastaFromBed" "coverageBed" "bedpeToBam"
> +   "pairToPair" "subtractBed" "nucBed" 
> "expandCols" "bedToIgv" "slopBed"
> +   "closestBed" "windowMaker" "linksBed" 
> "getOverlap" "mergeBed" "windowBed"
> +   "flankBed" "pairToBed" "intersectBed" 
> "bamToBed" "multiBamCov"
> +   "unionBedGraphs" "genomeCoverageBed" 
> "groupBy" "maskFastaFromBed"
> +   "bedtools")))
> +   (mkdir-p bin)
> +   (map (lambda (tool)

It would be more appropriate to use 'for-each' here instead of 'map'.

> +  (copy-file (string-append "bin/" tool)
> + (string-append bin "/" 
> tool)))
> +tools)))
> +  %standard-phases)
[...]

Thanks!
  Mark

Re: [PATCH] gnu: Add samtools

[Mark H Weaver]

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

> Ricardo Wurmus  skribis:
>
>> Can we disable the test suite for certain architectures?  Or would they
>> have to be disabled completely?
>
> Yes, just pass something like in ‘arguments’:
>
>   #:tests? (not (string=? (or (%current-system) (%current-target-system))
>   "i686-linux"))

Since it fails the same way on mips64el, I suggest this instead:

   #:tests? (string=? (or (%current-system) (%current-target-system))
  "x86_64-linux")

> Also please add a comment above linking to the upstream bug report.

 Thanks!
   Mark

Re: [PATCH] gnu: Add samtools

[Mark H Weaver]

Mark H Weaver  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Ricardo Wurmus  skribis:
>>
>>> Can we disable the test suite for certain architectures?  Or would they
>>> have to be disabled completely?
>>
>> Yes, just pass something like in ‘arguments’:
>>
>>   #:tests? (not (string=? (or (%current-system) (%current-target-system))
>>   "i686-linux"))
>
> Since it fails the same way on mips64el, I suggest this instead:
>
>#:tests? (string=? (or (%current-system) (%current-target-system))
>   "x86_64-linux")

Oops, we forgot to mention that there should be a comma before that
first open paren, like this:

#:tests? ,(string=? (or (%current-system) (%current-target-system))
"x86_64-linux")

>> Also please add a comment above linking to the upstream bug report.
>
>  Thanks!
>Mark

Re: hydra python2-numpy-1.9.1 failure

[Mark H Weaver]

Federico Beffa  writes:

> On Thu, Dec 11, 2014 at 2:20 PM, Ludovic Courtès  wrote:
>> Check if that flag has an effect at all.  For instance,
>> Automake-generated makefiles have supported parallel test suites for
>> not-too-long (a couple of years maybe) and even there it’s optional.
>> Hand-written build systems often run tests sequentially.
>
> I think you are right that the flag does not have any effect here.
>
> I've now identified the failing test. From the comment in the test
> procedure it appears that it has to do with memory
>
> https://github.com/numpy/numpy/issues/4442

Thanks for looking into it!

> Could I know the specs of the hydra (virtual?) machine running the
> code? I may reduce the size of the test matrix, or skip the test
> altogether.

The builds don't happen on hydra.gnu.org itself, they happen on its
build slaves, of which there are several.  Anyway, the question is not
relevant, because we want users to be able to build packages on their
own machines.  We'll just have to use our own judgment about what the
minimum requirements should be to build this package.

Thanks!
  Mark

[PATCH 1/2] gnu: xfce4-panel: Support panel plugins from other packages

[Mark H Weaver]

Hi Guix,

Currently, xfce4-panel looks for plugins only in its own /gnu/store
directory, so it is not possible to add extra panel plugins or even to
use the trash plugin that comes with thunar (xfce's file manager).

In the past, xfce4-panel had a way to configure paths for per-user
plugin directories, but later this was changed to use only compile-time
constant paths, for reasons described here:

  https://bugzilla.xfce.org/show_bug.cgi?id=5455

Nix's current solution is simply to change the compile-time constant
paths to /run/current-system/sw/..., which I found unsatisfying.

  http://lists.science.uu.nl/pipermail/nix-dev/2012-October/009956.html

The following patch modifies xfce4-panel to search for panel plugins in
directories specified by the XDG_DATA_DIRS and X_XFCE4_LIB_DIRS
environment variables.  That latter name is my own invention, and I've
waffled a bit on what to call it and how much of the pathname prefixes
it should contain.

Here's how I configure these variables in my ~/.bash_profile:

--8<---cut here---start->8---
export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
export 
XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
export 
X_XFCE4_LIB_DIRS=$HOME/.guix-profile/lib/xfce4:/run/current-system/profile/lib/xfce4
--8<---cut here---end--->8---

Anyway, here's the patch.  It's what I needed to make the second patch
work (packaging xfce4-battery-plugin), which was my original goal here.
I'll post that patch in another message.

Comments and suggestions welcome.

  Mark


>From ffc34f08feb9175c140e7ee7d9dcfef07b0cb751 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Sat, 13 Dec 2014 20:50:00 -0500
Subject: [PATCH 1/2] gnu: xfce4-panel: Support panel plugins from other
 packages.

* gnu/packages/patches/xfce4-panel-plugins.patch: New file.
* gnu-system.am (dist_patch_DATA): Add it.
* gnu/packages/xfce.scm (xfce4-panel): Add the patch, and a
  native search path specification for X_XFCE4_LIB_DIRS.
---
 gnu-system.am  |   1 +
 gnu/packages/patches/xfce4-panel-plugins.patch | 115 +
 gnu/packages/xfce.scm  |  12 ++-
 3 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/xfce4-panel-plugins.patch

diff --git a/gnu-system.am b/gnu-system.am
index e828c01..08b1ecd 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -451,6 +451,7 @@ dist_patch_DATA =		\
   gnu/packages/patches/wmctrl-64-fix.patch			\
   gnu/packages/patches/xf86-input-synaptics-glibc-2.20.patch	\
   gnu/packages/patches/xf86-video-openchrome-includes.patch	\
+  gnu/packages/patches/xfce4-panel-plugins.patch		\
   gnu/packages/patches/xmodmap-asprintf.patch
 
 bootstrapdir = $(guilemoduledir)/gnu/packages/bootstrap
diff --git a/gnu/packages/patches/xfce4-panel-plugins.patch b/gnu/packages/patches/xfce4-panel-plugins.patch
new file mode 100644
index 000..df5a0a9
--- /dev/null
+++ b/gnu/packages/patches/xfce4-panel-plugins.patch
@@ -0,0 +1,115 @@
+Search for xfce4 panel plugins in the directories specified
+in XDG_DATA_DIRS and X_XFCE4_LIB_DIRS.  For discussion of the
+relevant issues, see:
+
+  https://bugzilla.xfce.org/show_bug.cgi?id=5455
+
+Patch by Mark H Weaver 
+
+--- xfce4-panel-4.10.0/panel/panel-module.c.orig	2012-04-28 16:31:35.0 -0400
 xfce4-panel-4.10.0/panel/panel-module.c	2014-12-14 01:31:55.728107386 -0500
+@@ -35,8 +35,14 @@
+ #include 
+ #include 
+ 
+-#define PANEL_PLUGINS_LIB_DIR (LIBDIR G_DIR_SEPARATOR_S "panel" G_DIR_SEPARATOR_S "plugins")
+-#define PANEL_PLUGINS_LIB_DIR_OLD (LIBDIR G_DIR_SEPARATOR_S "panel-plugins")
++#define PANEL_PLUGINS_LIB_DIR_TAIL (G_DIR_SEPARATOR_S "panel" G_DIR_SEPARATOR_S "plugins")
++#define PANEL_PLUGINS_LIB_DIR_TAIL_OLD (G_DIR_SEPARATOR_S "panel-plugins")
++
++static const gchar *plugins_lib_dir_tails[] =
++{
++  PANEL_PLUGINS_LIB_DIR_TAIL,
++  PANEL_PLUGINS_LIB_DIR_TAIL_OLD
++};
+ 
+ 
+ typedef enum _PanelModuleRunMode PanelModuleRunMode;
+@@ -335,21 +341,39 @@
+   /* show a messsage if the old module path key still exists */
+   g_message ("Plugin %s: The \"X-XFCE-Module-Path\" key is "
+  "ignored in \"%s\", the panel will look for the "
+- "module in %s. See bug #5455 why this decision was made",
+- name, filename, PANEL_PLUGINS_LIB_DIR);
++ "module in DIR%s for each DIR in $X_XFCE4_LIB_DIRS "
++ "(%s by default).  See bug #5455 for discussion.",
++ name, filename, PANEL_PLUGINS_LIB_DIR_TAIL, LIBDIR);
+ }
+ #endif
+ 
+-  path = g_module_build_path (PANEL_PLUGINS_LIB_DIR, module_name)

[PATCH 2/2] gnu: Add xfce4-battery-plugin

[Mark H Weaver]

>From 21388251c029d4193e3e87747c26b2e603c180e1 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Sat, 13 Dec 2014 20:53:59 -0500
Subject: [PATCH 2/2] gnu: Add xfce4-battery-plugin.

* gnu/packages/xfce.scm (xfce4-battery-plugin): New variable.
---
 gnu/packages/xfce.scm | 29 +
 1 file changed, 29 insertions(+)

diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
index b23ac79..0ab3c42 100644
--- a/gnu/packages/xfce.scm
+++ b/gnu/packages/xfce.scm
@@ -279,6 +279,35 @@ applications menu, workspace switcher and more.")
 ;; Libraries are under LGPLv2.1+, and programs under GPLv2+.
 (license (list gpl2+ lgpl2.1+
 
+(define-public xfce4-battery-plugin
+  (package
+(name "xfce4-battery-plugin")
+(version "1.0.5")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://archive.xfce.org/src/panel-plugins/";
+  name "/" (version-major+minor version) "/"
+  name "-" version ".tar.bz2"))
+  (sha256
+   (base32
+"04gbplcj8z4vg5xbks8cc2jjf62mmf9sdymg90scjwmb82pv2ngn"
+(build-system gnu-build-system)
+(native-inputs `(("pkg-config" ,pkg-config)
+ ("intltool" ,intltool)))
+(inputs `(("glib" ,glib)
+  ("gtk+" ,gtk+-2)
+  ("libxfce4util" ,libxfce4util)
+  ("libxfce4ui" ,libxfce4ui)
+  ("xfce4-panel" ,xfce4-panel)))
+(home-page
+ "http://goodies.xfce.org/projects/panel-plugins/xfce4-battery-plugin";)
+(synopsis "Battery monitor panel plugin for Xfce4")
+(description
+ "A battery monitor panel plugin for Xfce4, compatible with APM and ACPI.")
+;; The main plugin code is covered by gpl2+, but the files containing code
+;; to read the battery state via ACPI or APM are covered by lgpl2.0+.
+(license (list gpl2+ lgpl2.0+
+
 (define-public xfce4-appfinder
   (package
 (name "xfce4-appfinder")
-- 
2.1.2

Re: [PATCH 1/2] gnu: Add vte.

[Mark H Weaver]

宋文武  writes:

> David Thompson  writes:
>> Maybe call this one 'vte-gtk2'?  'vte-0' isn't very descriptive.
> Basically, I intend to use the version of pc file,
> for example, I have libwnck-1, which has libwnck-1.0.pc.
>
> Yes, this does make sense, but 'vte-gtk2' is look like another package,
> how about 'vte/gtk+-2'?

Package names cannot match the regexp "-[0-9]", because when
'package-name->name+version' in (guix utils) finds such a match, it
interprets the part after the "-" as a version number.  So if you run
"guix package -i vte/gtk+-2", it will look for version "2" of a package
named "vte/gtk+".

 Mark

Re: [PATCH 1/2] gnu: Add vte.

[Mark H Weaver]

宋文武  writes:

> Mark H Weaver  writes:
>
>> 宋文武  writes:
>>
>>> David Thompson  writes:
>>>> Maybe call this one 'vte-gtk2'?  'vte-0' isn't very descriptive.
>>> Basically, I intend to use the version of pc file,
>>> for example, I have libwnck-1, which has libwnck-1.0.pc.
>>>
>>> Yes, this does make sense, but 'vte-gtk2' is look like another package,
>>> how about 'vte/gtk+-2'?
>>
>> Package names cannot match the regexp "-[0-9]", because when
>> 'package-name->name+version' in (guix utils) finds such a match, it
>> interprets the part after the "-" as a version number.  So if you run
>> "guix package -i vte/gtk+-2", it will look for version "2" of a package
>> named "vte/gtk+".
> Ah, I think you mean the 'name' field of package?
>
> I'm talk about the variable name, for which we have gtk+-2, gtkmm-2 etc.

You're right, my mistake.  Nevermind :)

 Mark

Re: gobject-introspection typelibs and shared libraries

[Mark H Weaver]

Federico Beffa  writes:

> On Wed, Dec 10, 2014 at 1:56 PM, Ludovic Courtès  wrote:
 Yes, let’s create a branch with all the update work the two of you have
 done, and revert the upgrade in master.
>
> I've created a branch named wip-gobject-introspection with the patch
> and version 1.42.0.  I've also pushed version updates for pango and
> gdk-pixbuf compatible with the former.
>
> Would be nice to have hydra build that, so that we can see what's failing.

I went down this road, and found that a great many things fail.  I don't
remember finding a single package that uses gobject-introspection that
worked without updating.

I got stuck on eudev.  The newest version doesn't work, and I didn't see
anything in their git repo to fix it either.

Before moving forward on this, can you find a way to build eudev with
gobject-introspection-1.42.0?

Also, I'm currently working on upgrading almost every package in
xorg.scm, as well as glib and dbus.  I'll push it as a branch in the
next day or two.  It probably makes the most sense to build your branch
on top of mine.

Thanks for working on this!

Regards,
  Mark

Re: [PATCH 3/4] gnu: Add cairocffi.

[Mark H Weaver]

Federico Beffa  writes:

> From e853d10b595ece0003d838cbfffa65e29a6c2e68 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Wed, 10 Dec 2014 21:05:59 +0100
> Subject: [PATCH 3/4] gnu: Add cairocffi.
>
> * gnu/packages/gtk.scm (python-cairocffi, python2-cairocffi): New variables.

[...]

> +(define-public python2-cairocffi
> +  (package-with-python2 python-cairocffi))
> +

This commit breaks the Guix build for me.

Due to complications arising from circular module dependencies, we can't
use 'package-with-python2' from gtk.scm.  For now, I suggest moving it
to python.scm, where all other uses of 'package-with-python2' are
currently located.

If you'd like to understand the reasons, read on (optional).

The reason is that gtk.scm and python.scm are part of the same strongly
connected component (SCC) in the graph of "use-module" dependencies.  In
other words, there exists a cycle containing both of them (in this case
they use each other directly).  This prevents Guile from loading the
modules in "bottom-up" order, and there's no guarantee which one will be
loaded first.

In this case, if gtk.scm is loaded first, it works, but if python.scm is
loaded first, you're out of luck.

If python.scm is loaded first, it starts by loading the modules it uses,
including gtk.scm.  Then gtk.scm loads the modules it uses including
python.scm.  This would lead to infinite recursion, but Guile breaks the
cycle by ignoring the attempt load python.scm when it's currently being
loaded.  gtk.scm then continues to load, and gets to your definition of
'python2-cairocffi', which tries to call 'package-with-python2' before
python.scm has been fully loaded (in fact it's hardly loaded at all).

In Guix package modules this is usually not a problem, because most of
the inter-module variable references are in "thunked" fields such as
'inputs', and thunked fields are not evaluated until later.  However,
the definition of 'python2-cairocffi' needs to call
'package-with-python2' at module-load time, and python.scm may not be
loaded yet at that point.

So 'python2-cairocffi' must either be moved out of the SCC containing
python.scm, or moved into python.scm at a point late enough in the file
such that everything needed by 'package-with-python2' has already been
loaded.

We currently have two non-trivial SCCs in our "use-module" graph of
package modules.  One is ((gnu packages bison) (gnu packages flex)),
and the other one is rather large:

((gnu packages boost)
 (gnu packages python)
 (gnu packages image)
 (gnu packages fontutils)
 (gnu packages ghostscript)
 (gnu packages tcl)
 (gnu packages xorg)
 (gnu packages gettext)
 (gnu packages xml)
 (gnu packages gnupg)
 (gnu packages curl)
 (gnu packages gnutls)
 (gnu packages guile)
 (gnu packages gtk)
 (gnu packages glib)
 (gnu packages base)
 (gnu packages acl)
 (gnu packages attr)
 (gnu packages linux)
 (gnu packages databases)
 (gnu packages emacs)
 (gnu packages lesstif)
 (gnu packages version-control)
 (gnu packages cook)
 (gnu packages groff)
 (gnu packages netpbm)
 (gnu packages nano)
 (gnu packages admin)
 (gnu packages swig)
 (gnu packages imagemagick)
 (gnu packages algebra)
 (gnu packages mpi)
 (gnu packages valgrind)
 (gnu packages gdb)
 (gnu packages dejagnu)
 (gnu packages graphviz)
 (gnu packages gd)
 (gnu packages w3m)
 (gnu packages wget)
 (gnu packages web)
 (gnu packages asciidoc)
 (gnu packages docbook)
 (gnu packages inkscape)
 (gnu packages maths)
 (gnu packages cmake)
 (gnu packages backup)
 (gnu packages rsync)
 (gnu packages ssh)
 (gnu packages fltk)
 (gnu packages gl)
 (gnu packages xdisorg)
 (gnu packages lisp)
 (gnu packages texlive)
 (gnu packages pdf)
 (gnu packages tcsh)
 (gnu packages zip)
 (gnu packages gnome)
 (gnu packages gstreamer)
 (gnu packages pulseaudio)
 (gnu packages avahi)
 (gnu packages libcanberra)
 (gnu packages xiph)
 (gnu packages doxygen)
 (gnu packages iso-codes)
 (gnu packages mp3)
 (gnu packages cdrom)
 (gnu packages man)
 (gnu packages lynx)
 (gnu packages rrdtool)
 (gnu packages gsasl)
 (gnu packages shishi)
 (gnu packages openldap))

 Mark

Re: [PATCH 3/4] gnu: Add cairocffi.

[Mark H Weaver]

Federico Beffa  writes:

> On Thu, Dec 18, 2014 at 8:53 PM, Mark H Weaver  wrote:
>> Federico Beffa  writes:
>>
>>> From e853d10b595ece0003d838cbfffa65e29a6c2e68 Mon Sep 17 00:00:00 2001
>>> From: Federico Beffa 
>>> Date: Wed, 10 Dec 2014 21:05:59 +0100
>>> Subject: [PATCH 3/4] gnu: Add cairocffi.
>>>
>>> * gnu/packages/gtk.scm (python-cairocffi, python2-cairocffi): New variables.
>>
>> [...]
>>
>>> +(define-public python2-cairocffi
>>> +  (package-with-python2 python-cairocffi))
>>> +
>>
>> This commit breaks the Guix build for me.
>>
>> Due to complications arising from circular module dependencies, we can't
>> use 'package-with-python2' from gtk.scm.  For now, I suggest moving it
>> to python.scm, where all other uses of 'package-with-python2' are
>> currently located.
>
> I just moved cairocffi to the python module and committed.  Sorry about that!

Thanks, and no worries!  I don't think any of us could have anticipated
this problem.

> I worked on it and with packages depending on it for several days
> without problems. How is it that the import is not deterministic?

It depends on which module in that large SCC is loaded first into a
given Guile session.

It should be deterministic for any given Guile session, e.g. for any
given *.scm file that is being compiled by 'guild compile', or for any
given set of commands typed into a freshly loaded Guile.

I saw the problem when compiling inkscape.scm.  Other files might have
failed as well, but 'make' stopped when inkscape.scm failed.  I guess
you didn't recompile any of the files that exhibited the problem since
adding 'python2-cairocffi', which is reasonable :)

I hope to eventually add some mechanism to detect and/or avoid these
problems in the future.  In the meantime, we'll just have to accept that
this problem will occasionally bite us.  I don't think it's reasonable
to expect people to do a "make clean-go && make" every time they add a
package.  IMO, that cure would be worse than the disease.

 Regards,
   Mark

New xorg-updates branch pushed

[Mark H Weaver]

Hello Guix!

I've pushed a new branch 'xorg-updates' which updates almost every
package in xorg.scm, as well as mesa, dbus, glib, pixman, cairo,
poppler, inkscape, and a few others.

My original purpose was to apply security fixes mentioned here:

  http://www.x.org/wiki/Development/Security/Advisory-2014-12-09/

but I decided it was a better use of my time to upgrade xorg-server to
the latest pre-release (which contains the fixes) than to try to
backport them to our old xorg-server.  This required updating the *proto
packages, which in turn forced a rebuild of the X libraries and
everything built on them, so I decided I might as well update most of
xorg.scm while I was at it.

I've been running with these patches on my own system for the last day
or so, and it's working very well so far.  The X server now uses
xf86-input-evdev, which among other things enables hotplugging of input
devices.  xf86-video-modesetting also now works.  I was also able to
resurrect xf86-video-geode, thanks to a new upstream release.

Two drivers no longer compile: xf86-video-ast and xf86-video-newport.
They both try to include xaa.h, which has apparently been removed from
the server, although I confess I didn't look too deeply into it.

Most of the commits are fairly straightforward, but I wanted to call
attention to a few points:

* Wherever possible, I changed the source URIs to
  mirror://xorg/individual/.  For most of the package updates this was
  required, and then for consistency, in the final commit I changed all
  of the URIs for the packages I didn't update.  I made it the last
  commit so it will be easy to remove if there are objections :)

* Many video drivers needed patches.  Most of the patches are for two
  recurrent problems:

   * mibstore.h has been removed in the X server, and 10 of the video
 drivers haven't yet been updated.  Fixing this requires patches
 like this:

 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/xf86-video-nv-remove-mibstore.patch?h=xorg-updates

   * There's an incompatibility between glibc-2.20 and the os.h header
 in the xorg-server package.  Until they fix this properly, a
 simple workaround is to include  before including
 the headers for the internal X driver API, as done here:

 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/xf86-video-intel-glibc-2.20.patch?h=xorg-updates

   * Related to the problem above, some video drivers checked for the
 exa.h header in their configure scripts, and the test compilation
 fails for the same reason as above.  My workaround was to hack the
 configure script to include  in the test program,
 using patches like this:

 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/xf86-video-mach64-glibc-2.20.patch?h=xorg-updates

I've asked Hydra to build this new branch, and when it's done building
(or close to it) I plan to merge it into master.

In the meantime, if anyone feels inspired to review these 116 commits,
your comments and suggestions are welcome.  Testing would also be very
helpful, as I was only able to test on my Libreboot X60 laptop with
intel graphics.

   Mark

[PATCH] Optimize package-transitive-supported-systems

[Mark H Weaver]

When hydra evaluates a jobset, 'package-transitive-supported-systems' is
called for every package+system combination.  Each of these calls
traverses the tree of inputs, but without eliminating duplicate
transitive-inputs.  In other words, the amount of time spent is
proportional not to the number of transitive-inputs, but the number of
_paths_ to all transitive-inputs.

This patch memoizes 'package-transitive-supported-systems', so that the
total time to apply it to all packages is O(N).

 Mark


>From 90541f6c7e2a9e2f8a7b412532b4b5a56a10e481 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Sun, 21 Dec 2014 16:21:02 -0500
Subject: [PATCH] Optimize package-transitive-supported-systems.

* guix/packages.scm (first-value): Remove.
  (define-memoized/v): New macro.
  (package-transitive-supported-systems): Rewrite.
---
 guix/packages.scm | 61 +++
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/guix/packages.scm b/guix/packages.scm
index 07f6d0c..2a9a55e 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014 Ludovic Courtès 
+;;; Copyright © 2014 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -543,40 +544,38 @@ for the host system (\"native inputs\"), and not target inputs."
 recursively."
   (transitive-inputs (package-propagated-inputs package)))
 
-(define-syntax-rule (first-value exp)
-  "Truncate all but the first value returned by EXP."
-  (call-with-values (lambda () exp)
-(lambda (result . _)
-  result)))
+(define-syntax define-memoized/v
+  (lambda (form)
+"Define a memoized single-valued unary procedure with docstring.
+The procedure argument is compared to cached keys using `eqv?'."
+(syntax-case form ()
+  ((_ (proc arg) docstring body body* ...)
+   (string? (syntax->datum #'docstring))
+   #'(define proc
+   (let ((cache (make-hash-table)))
+ (define (proc arg)
+   docstring
+   (match (hashv-get-handle cache arg)
+ ((_ . value)
+  value)
+ (_
+  (let ((result (let () body body* ...)))
+(hashv-set! cache arg result)
+result
+ proc))
 
-(define (package-transitive-supported-systems package)
+(define-memoized/v (package-transitive-supported-systems package)
   "Return the intersection of the systems supported by PACKAGE and those
 supported by its dependencies."
-  (first-value
-   (let loop ((package package)
-  (systems (package-supported-systems package))
-  (visited vlist-null))
- (match (vhash-assq package visited)
-   ((_ . result)
-(values (lset-intersection string=? systems result)
-visited))
-   (#f
-(call-with-values
-(lambda ()
-  (fold2 (lambda (input systems visited)
-   (match input
- ((label (? package? package) . _)
-  (loop package systems visited))
- (_
-  (values systems visited
- (lset-intersection string=?
-systems
-(package-supported-systems package))
- visited
- (package-direct-inputs package)))
-  (lambda (systems visited)
-(values systems
-(vhash-consq package systems visited)
+  (fold (lambda (input systems)
+  (match input
+((label (? package? p) . _)
+ (lset-intersection
+  string=? systems (package-transitive-supported-systems p)))
+(_
+ systems)))
+(package-supported-systems package)
+(package-direct-inputs package)))
 
 (define (bag-transitive-inputs bag)
   "Same as 'package-transitive-inputs', but applied to a bag."
-- 
2.1.2

Re: [PATCH 4/4] gnu: matplotlib: Add gtk3 backends.

[Mark H Weaver]

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

> Federico Beffa  skribis:
>
>> The build does finish as I've tested it on my machine before
>> committing the package. However, for some reason, guix needs very long
>> to generate the derivation. On my machine (quad-core Xeon E5520)
>> python2-matplotlib takes ca. 31 mins to start building.
>> Python2-scipy, which includes python2-matplotlib, takes ca. 80 mins.!
>
> Eric Bavier  skribis:
>
>> I wonder if this could this be a result of package-with-python2's
>> behavior of recursively creating new package objects for each input in a
>> package.  As Ludovic suggested, this could easily create very large DAGs
>> that then need to be processed.
>>
>> This behavior of package-with-python2 was giving me a nightmare when
>> trying to code some improvements to `guix refresh -l`, since there would
>> easily become tens or hundreds of logically identical python package
>> objects floating through the package dependency DAG.
>
> Ouch, thanks for putting me on the right track.  Basically
> ‘package-with-explicit-python’ was recursing way too much, leading to
> hundreds of unique package objects, and thus defeating memoization of
> ‘package-derivation’.
>
> Commit 78a2745 fixes that.  ‘guix build python2-matplotlib -n
> --no-substitutes’ takes ~5 seconds on my laptop (which is still too much
> IMO, but that’s another story.)  I’ve thus reinstated numpy, scipy, etc.

This seems to have fixed Hydra as well.  Previously, it was timing out
(after 3 hours) while trying to evaluate jobsets.  Hydra is now building
the xorg-updates branch.

 Thanks!
   Mark

Re: Is help wanted?Needed?

[Mark H Weaver]

Omar Radwan  writes:

> Ok, I'll check that out. 
>
> About packaging, is there a specific build script that I have to use,
> like the SlackBuild? Or is there another way. I've never packaged
> software for any distro before, but I have compiled for personal use.
> Is there like a manual or something that can help me?

In addition to the manual, these tutorial slides might be helpful:

  https://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf

I'd also encourage you to visit our IRC channel, #guix on
irc.freenode.net.

  Mark

Re: New xorg-updates branch pushed

[Mark H Weaver]

Mark H Weaver  writes:
> I've pushed a new branch 'xorg-updates' which updates almost every
> package in xorg.scm, as well as mesa, dbus, glib, pixman, cairo,
> poppler, inkscape, and a few others.

Hydra has finished building it, and I've fixed the remaining problems,
so I've merged this into master.

 Mark

Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Hello Guix,

I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
which seems likely to finish natively building bootstrap tarballs soon.
It is based on the 'core-updates' branch.

I chose system name "armhf-linux", GNU triplet "arm-linux-gnueabihf",
and the following GCC configure flags:

   --with-arch=armv7-a
   --with-float=hard
   --with-mode=thumb
   --with-fpu=vfpv3-d16

I believe this coincides with what Debian does for their 'armhf' port.

This branch is *not* ready for use.  For one thing, the current
bootstrap tarballs are cross-compiled, and we should wait for the
natively-compiled ones.

The branch is for review.  Comments and suggestions solicited!

  Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Hi John,

John Darrington  writes:
> It would seem then, that the only difference between the wip-arm and
> the wip-armhf branches is the value of the --with-fpu flag.

That is not even close to the truth, as anyone who actually looks at the
branches (or tries to build them) can easily see.  John, I appreciate
your preliminary work on 'wip-arm', and I credited you in the final
patch on 'wip-armhf', but you didn't get very far.

> I'm not an ARM expert, so I don't know how important that setting is.

I assuming that the Debian armhf developers are far more knowledgeable
than either of us, so I followed their lead.  There is some discussion
here:

  https://wiki.debian.org/ArmHardFloatPort
  https://wiki.debian.org/ArmHardFloatPort/VfpComparison

> But I do know that there are many different fpus - if we are going to
> have a new branch for every combination of flags then there are going
> to be rather a lot of branches.

First of all, the branch is temporary.  Like mips64el before it, this
branch will be merged into 'core-updates' and 'master' when it's ready.

I don't think we need a 'system' for every combination of flags.  We
should just find a small number of "sweet spots" in the tradeoff between
minimum requirements vs performance.  IMO, for 32-bit ARM, two systems
should be enough: armhf, and maybe another one (armel?) that works on
lower-end processors.

Other opinions?

 Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Mark H Weaver  writes:

> I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
> which seems likely to finish natively building bootstrap tarballs soon.
> It is based on the 'core-updates' branch.

I believe that my cross-compiled bootstrap tarballs are bad and have to
be rebuilt.  Despite passing both --target=arm-linux-gnueabihf and
--with-float=hard to GCC's configure, I believe that GCC was using the
soft-float ABI for ARM by default.  This is especially bad given that
our dynamic linker has a name that indicates the hard-float ABI.

For now, I've pushed another commit to the 'wip-armhf' branch that will
hopefully make it *cross-build* armhf bootstrap tarballs properly, but
it is not yet suitable for building on an arm box because it refers to
the existing (bad) bootstrap tarballs.

I'll post an update when this issue is resolved.

  Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Mark H Weaver  writes:

> Mark H Weaver  writes:
>
>> I've pushed a new branch 'wip-armhf' (not to be confused with 'wip-arm')
>> which seems likely to finish natively building bootstrap tarballs soon.
>> It is based on the 'core-updates' branch.
>
> I believe that my cross-compiled bootstrap tarballs are bad and have to
> be rebuilt.  Despite passing both --target=arm-linux-gnueabihf and
> --with-float=hard to GCC's configure, I believe that GCC was using the
> soft-float ABI for ARM by default.

False alarm.  Looking at the source code of gcc/config/arm/linux-eabi.h
and seeing a patch in Debian made me think that we needed a patch in
order to make this work, but testing indicates that the hard-float ABI
is being used by GCC by default without any patches.

So, nevermind :)

  Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

Hi John,

John Darrington  writes:

> On Wed, Dec 31, 2014 at 02:23:30PM -0500, Mark H Weaver wrote:
>  
>  John Darrington  writes:
>  > It would seem then, that the only difference between the wip-arm and
>  > the wip-armhf branches is the value of the --with-fpu flag.
>  
>  That is not even close to the truth, as anyone who actually looks at the
>  branches (or tries to build them) can easily see.  John, I appreciate
>  your preliminary work on 'wip-arm', and I credited you in the final
>  patch on 'wip-armhf', but you didn't get very far.
>
> No I didn't.   I didn't think it worth even creating a branch, but civodul 
> asked me to.
> So I was surprised and disappointed that nobody wanted to help take it 
> further.

Initially, I hoped to build upon your branch instead of starting a new
one.  However, when I took a close look, I found that there was not a
single hunk of your initial commit (0386b83a2) that I could use:

* You called the system 'armel-linux', but I preferred to save that name
  for a possible soft-float system analogous to Debian's 'armel' port.

* You used the triplet 'armel-linux-gnueabihf'.  I tried that, but found
  that a great many copies of 'config.sub' in the wild fail to recognize
  'armel' as the machine name when there is also a company name in the
  triplet.  After a few experiments with other triplets, I settled on
  'arm-linux-gnueabihf', which is what Debian uses.

* You chose higher FPU requirements than Debian, and tuned compiles for
  cortex-a9.  I'm open to discussing these choices, but without careful
  research I'd be more inclined to follow Debian's lead.

* You added "CFLAGS=-Wno-cast-qual" and "--disable-werror" for ARM in
  'gcc-configure-flags-for-triplet', which I thought was a bad idea and
  didn't belong there.

* You patched gcc/config/arm/linux-eabi.h unnecessarily.

Given that every piece of your foundation needed modification, it didn't
seem to make sense to build on it.

> You said your branch also wasn't ready, that's why I haven't tried to
> build it.  From your description, I wasn't clear what your branch
> achieves that my attempt doesn't.

'wip-armhf' is well on its way to building native bootstrap tarballs on
my Novena board.  Given the many problems in the early bootstrap that I
had to fix along the way, it is clear that 'wip-arm' in it's current
state wouldn't get very far.

   Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

John Darrington  writes:

> On Wed, Dec 31, 2014 at 06:40:23PM -0500, Mark H Weaver wrote:
>  
>  * You added "CFLAGS=-Wno-cast-qual" and "--disable-werror" for ARM in
>'gcc-configure-flags-for-triplet', which I thought was a bad idea and
>didn't belong there.
>
> Have you tried actually building GCC ?

Yes, I've built several GCCs including gcc-final.  I've also
successfully built the 'hello' package.

> I found that without those, it failed to build.

Perhaps the problem you ran into was fixed in GCC 4.8.4.

>  * You patched gcc/config/arm/linux-eabi.h unnecessarily.
>
> Without that patch, GCC actually builds soft-float code, even though
> you may have passed the --with-float=hard flag.  What bits of that
> patch do you think are not necessary?

All of it seems to be unnecessary, by experiment.  I've used the
resulting GCC to compile the following test program:

--8<---cut here---start->8---
#include 

double foo (double a, double b)
{
  return sinh(a * b);
}
--8<---cut here---end--->8---

Compiled with "/gnu/store/.../bin/gcc -O2 -S foo.c", here's the
resulting foo.s:

--8<---cut here---start->8---
.syntax unified
.arch armv7-a
.eabi_attribute 27, 3
.eabi_attribute 28, 1
.fpu vfpv3-d16
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.thumb
.file   "foo.c"
.text
.align  2
.global foo
.thumb
.thumb_func
.type   foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
fmuld   d0, d0, d1
b   sinh
.size   foo, .-foo
.ident  "GCC: (GNU) 4.8.4"
.section.note.GNU-stack,"",%progbits
--8<---cut here---end--->8---

'foo' accepts the double arguments via registers and passes a double to
sinh via registers.  I also checked a variant that simply returned a*b,
and it was clearly returning the result via register as well.

I think it's quite clear that this is using the hard-float ABI, no?

  Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

John Darrington  writes:

> On Thu, Jan 01, 2015 at 02:11:19AM -0500, Mark H Weaver wrote:
>  John Darrington  writes:
>  
>  >  * You patched gcc/config/arm/linux-eabi.h unnecessarily.
>  >
>  > Without that patch, GCC actually builds soft-float code, even though
>  > you may have passed the --with-float=hard flag.  What bits of that
>  > patch do you think are not necessary?
>  
>  All of it seems to be unnecessary, by experiment.  I've used the
>  resulting GCC to compile the following test program:
>  
>  'foo' accepts the double arguments via registers and passes a double to
>  sinh via registers.  I also checked a variant that simply returned a*b,
>  and it was clearly returning the result via register as well.
>  
>  I think it's quite clear that this is using the hard-float ABI, no?
>
> My results showed that simple binaries like that compiled (and ran)
> ok.  The problems arose when linking with bigger projects.  I don't
> recall the details.  Have you tried building libc?

Yes, of course.  I looked further into this, and discovered that the
reason it all works is that the main 'gcc' driver arranges to pass
"-mfloat-abi=hard" (and several others) to 'cc1' and 'as'.

  Mark

Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

I was able to natively build bootstrap tarballs on the Novena.  However,
the compiler in these new bootstrap tarballs is broken.  The problem is
that the new compiler driver (gcc) passes -lgcc_s when linking, but
libgcc_s.so does not exist in the gcc bootstrap tarball.

It seems that libgcc_s.so does not exist in any of our bootstrap
tarballs, so I guess that's intentional.  However, for some reason this
new bootstrap gcc is trying to link to it.

I've done a careful comparison of the output of "gcc -v bare-test.c"
between the old (cross-compiled) and new (native-compiled) bootstrap
tarballs.  bare-test.c contains only an empty main() function.  These
tests are run outside of the guix-daemon but using only the environment
variables set in the 'make-boot0' build.  Here are the non-trivial
differences:

* The GNU triplet is different.  The old (working) cross-compiled ones
  use "arm-linux-gnueabihf", but the new (broken) ones use
  "armv7l-unknown-linux-gnueabihf", the result of 'config.guess'.

* The LIBRARY_PATHs printed by "gcc -v" before running 'collect2' are
  different.  The old (working) cross-compiled one includes
  ":/lib/:/usr/lib/" at the end, whereas the new (broken) one includes
  only directories from /gnu/store.

* There are several differences in the call to 'collect2':

   * The old (working) cross-compiled one passes "-dynamic-linker
 /lib/ld-linux-armhf.so.3" early in the command line, whereas the
 new (broken) one passes "-dynamic-linker
 
/gnu/store/-glibc-2.20/lib/ld-linux-armhf.so.3".

 However, both of them pass a second -dynamic-linker argument that
 points to /gnu/store/*-glibc-bootstrap-0//lib/ld-linux-armhf.so.3
 which seems to be correct.

   * The new (broken) one passes the following extra flags to 'collect2':
 "-L/gnu/store/-glibc-2.20/lib
 -rpath=/gnu/store/-glibc-2.20/lib
 -rpath=/gnu/store/-gcc-static-4.8.4/lib64
 -rpath=/gnu/store/-gcc-static-4.8.4/lib
 -lgcc_s"

Obviously, that last -lgcc_s is what's causing problems here.
Any idea what's causing this, or how to fix it?

  Mark

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

Mark H Weaver  writes:

> I was able to natively build bootstrap tarballs on the Novena.  However,
> the compiler in these new bootstrap tarballs is broken.  The problem is
> that the new compiler driver (gcc) passes -lgcc_s when linking, but
> libgcc_s.so does not exist in the gcc bootstrap tarball.

[...]

>* The new (broken) one passes the following extra flags to 'collect2':
>  "-L/gnu/store/-glibc-2.20/lib
>  -rpath=/gnu/store/-glibc-2.20/lib
>  -rpath=/gnu/store/-gcc-static-4.8.4/lib64
>  -rpath=/gnu/store/-gcc-static-4.8.4/lib
>  -lgcc_s"

These new flags directly correspond to the modification we make to
GNU_USER_TARGET_LIB_SPEC in the pre-configure phase of our gcc-4.7
package in gcc.scm (and inherited by our other gcc packages):

--8<---cut here---start->8---
;; Tell where to find libstdc++, libc, and `?crt*.o', except
;; `crt{begin,end}.o', which come with GCC.
(substitute* (find-files "gcc/config"
 "^gnu-user.*\\.h$")
  (("#define GNU_USER_TARGET_LIB_SPEC (.*)$" _ suffix)
   ;; Help libgcc_s.so be found (see also below.)  Always use
   ;; '-lgcc_s' so that libgcc_s.so is always found by those
   ;; programs that use 'pthread_cancel' (glibc dlopens
   ;; libgcc_s.so when pthread_cancel support is needed, but
   ;; having it in the application's RUNPATH isn't enough; see
   ;; 
<http://sourceware.org/ml/libc-help/2013-11/msg00023.html>.)
   (format #f "#define GNU_USER_TARGET_LIB_SPEC \
\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 
-rpath=~a/lib -lgcc_s}} \" ~a"
   libc libc libdir libdir suffix))
--8<---cut here---end--->8---

It turns out that the "-lgcc_s" above was added just a few days after
we generated our last set of bootstrap tarballs, in commit a7bf595ff.

I guess that ever since that commit, any natively-built bootstrap
tarballs we generated for any platform would have created a broken
compiler, and that this is the first time we've tried since then.

Any suggestions on how best to fix this?  My first crude idea is to
simply remove the "-lgcc_s" from %gcc-static.  Thoughts?

  Mark

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

Mark H Weaver  writes:

> I was able to natively build bootstrap tarballs on the Novena.  However,
> the compiler in these new bootstrap tarballs is broken.  The problem is
> that the new compiler driver (gcc) passes -lgcc_s when linking, but
> libgcc_s.so does not exist in the gcc bootstrap tarball.

[...]

> It turns out that the "-lgcc_s" above was added just a few days after
> we generated our last set of bootstrap tarballs, in commit a7bf595ff.
>
> I guess that ever since that commit, any natively-built bootstrap
> tarballs we generated for any platform would have created a broken
> compiler, and that this is the first time we've tried since then.
>
> Any suggestions on how best to fix this?  My first crude idea is to
> simply remove the "-lgcc_s" from %gcc-static.

For now, this is the approach I took, in commit 5336e4c74.

  Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> I don't think we need a 'system' for every combination of flags.  We
>> should just find a small number of "sweet spots" in the tradeoff between
>> minimum requirements vs performance.  IMO, for 32-bit ARM, two systems
>> should be enough: armhf, and maybe another one (armel?) that works on
>> lower-end processors.
>
> It’s not even clear that “hf” needs to be part of the system name.

I think it needs to be part of the system name, because on ARM these are
two incompatible ABIs.  Among other things, the hard-float ABI passes
floating point arguments in registers.

> In theory, the bootstrap tarballs could be soft-float, which means they
> would run everywhere, and from there users could choose what
> --with-float and --with-fpu flags to use.

A single GCC can generate code for both ABIs, but each ABI uses its own
dynamic linker.  If we did as you suggest, we'd need two separate
bootstrap glibc's, and improve the dynamic-linker-name patching code in
our gcc package to rewrite the two dynamic linker names separately, etc.

 Thanks,
   Mark

wip-armhf branch ready for wider testing

[Mark H Weaver]

Hello Guix!

I'm pleased to announce that the 'wip-armhf' branch is now ready for
wider testing.  So far, I've successfully used this branch to:

(1) cross-compile armhf-linux bootstrap tarballs on my Libreboot X60,

(2) natively compile armhf bootstrap tarballs on my Novena, based on the
cross-compiled bootstrap tarballs from (1), and

(3) build the 'hello' package based on the natively-compiled bootstrap
tarballs from (2).

Most likely we'll find more build problems higher up in the stack, and
help with that would be most appreciated!

   Happy hacking,
   Mark

xorg-server successfully built on mips64el

[Mark H Weaver]

FYI, the recent mesa and xorg-server updates have resulted in 31 new
successful builds on mips64el:

  http://hydra.gnu.org/eval/102200#tabs-now-succeed

Our current xorg-server still won't work on a Loongson2F-based machines,
which require some small but horrible patches that make it work _only_
on those machines.  (As I vaguely recall, the relevant patch hardcodes
the address of the framebuffer directly into the server.)

Anyway, if anyone still cares about those machines, it probably wouldn't
be hard to make a separate 'xorg-server-yeeloong' package that works
with them.  I vaguely remember thinking that a more proper fix would
involve changes to the kernel as well, to allow xorg-server to ask the
kernel where to find the framebuffer, as is done on other machines.

I confess that I have largely lost interest in the Lemote machines,
since Lemote's newer laptops require non-free blobs and I've lost
confidence that they will produce another machine that respects our
freedom anytime soon.  Meanwhile we have the Libreboot X60 (and soon
X200), the Novena, and other promising hardware in the pipeline.

Thoughts?
   Mark

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> Mark H Weaver  writes:
>>
>>> Any suggestions on how best to fix this?  My first crude idea is to
>>> simply remove the "-lgcc_s" from %gcc-static.
>>
>> For now, this is the approach I took, in commit 5336e4c74.
>
> Sounds good.
>
> I was tempting to do something like this:
>
> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
> index a7156bf..dd33a26 100644
> --- a/gnu/packages/gcc.scm
> +++ b/gnu/packages/gcc.scm
> @@ -213,7 +213,7 @@ where the OS part is overloaded to denote a specific 
> ABI---into GCC
> ;; below, make sure to update the relevant code in
> ;; %gcc-static package as needed.
> (format #f "#define GNU_USER_TARGET_LIB_SPEC \
> -\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 
> -rpath=~a/lib -lgcc_s}} \" ~a"
> +\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 
> -rpath=~a/lib %{pthread: -lgcc_s}}} \" ~a"
> libc libc libdir libdir suffix))
>(("#define GNU_USER_TARGET_STARTFILE_SPEC.*$" line)
> (format #f "#define STANDARD_STARTFILE_PREFIX_1 \"~a/lib\"
>
> I believe this is enough to address what the comment mentions (glibc
> dlopening libgcc_s for pthread functions), but this will need testing.
>
> WDYT?

I confess I don't know enough about the relevant details to know whether
this would work reliably -- e.g. will -pthread always be passed to gcc
at link time whenever this problem would arise? -- but it certainly
looks like a cleaner solution in principle.

I'm glad to defer to your judgement on how best to fix this :)

   Thanks!
 Mark

Re: Preliminary 'wip-armhf' branch pushed

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> I chose system name "armhf-linux", GNU triplet "arm-linux-gnueabihf",
>> and the following GCC configure flags:
>>
>>--with-arch=armv7-a
>>--with-float=hard
>>--with-mode=thumb
>>--with-fpu=vfpv3-d16
>
> Does it mean that GCC generates Thumb code by default?

Yes.  I confess that I'm not sufficiently knowledgeable about ARM to
understand the tradeoffs here, and have simply followed Debian's lead.
There is some rationale here:

  https://wiki.debian.org/ArmHardFloatPort

There, it says:

  Thumb-2/ThumbEE: Thumb-2 provides code size improvements and unlike
  thumb(1) there is no interworking overhead except in a few corner
  cases. Also Thumb-2 is sufficiently complete that there is no need to
  fall back to ARM ISA for some operations (unlike thumb1). Thus
  defaulting to Thumb-2 on v7 or later makes sense.

I haven't yet verified that our GCC is generating Thumb-2 instructions
(as opposed to Thumb-1).  Debian's GCC apparently does, but they apply a
rather large patch from Linaro.  This should be checked at some point.

Anyway, here are some more links that might be worth looking at if we
run into build problems:

  https://wiki.ubuntu.com/ARM/Thumb2
  https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

Regards,
  Mark

Pass --build= to native builds by default?

[Mark H Weaver]

It turns out that on ARM systems, the result of 'config.guess' depends
on the result of 'uname -m'.  In other words, details of the kernel (and
perhaps processor?) on the build machine will determine the triplet of
our builds, which in turn may affect what set of instructions is used.

Therefore, I think that on ARM systems (and perhaps _all_ systems), we
should consider passing --build= to configure by default.

What do you think?

Mark

Re: Pass --build= to native builds by default?

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> It turns out that on ARM systems, the result of 'config.guess' depends
>> on the result of 'uname -m'.  In other words, details of the kernel (and
>> perhaps processor?) on the build machine will determine the triplet of
>> our builds, which in turn may affect what set of instructions is used.
>
> Do you know how the ‘uname -m’ output is used in config.guess?  What
> does it return on ARM?

The output of 'uname -m' becomes the first (cpu) component of the GNU
triplet.  uname(1) gets its information from the kernel via the uname(2)
system call.  The field returned by 'uname -m' is described as "Hardware
identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.

Here's the relevant section of config.guess from gcc-4.8.4:

--8<---cut here---start->8---
arm*:Linux:*:*)
eval $set_cc_for_build
if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ARM_EABI__
then
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
else
if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ARM_PCS_VFP
then
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
else
echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
fi
fi
exit ;;
--8<---cut here---end--->8---

 Mark

Re: Pass --build= to native builds by default?

[Mark H Weaver]

Mark H Weaver  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver  skribis:
>>
>>> It turns out that on ARM systems, the result of 'config.guess' depends
>>> on the result of 'uname -m'.  In other words, details of the kernel (and
>>> perhaps processor?) on the build machine will determine the triplet of
>>> our builds, which in turn may affect what set of instructions is used.
>>
>> Do you know how the ‘uname -m’ output is used in config.guess?  What
>> does it return on ARM?
>
> The output of 'uname -m' becomes the first (cpu) component of the GNU
> triplet.  uname(1) gets its information from the kernel via the uname(2)
> system call.  The field returned by 'uname -m' is described as "Hardware
> identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.
>
> Here's the relevant section of config.guess from gcc-4.8.4:
>
> arm*:Linux:*:*)
>   eval $set_cc_for_build
>   if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
>   | grep -q __ARM_EABI__
>   then
>   echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
>   else
>   if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
>   | grep -q __ARM_PCS_VFP
>   then
>   echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
>   else
>   echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
>   fi
>   fi
>   exit ;;

I forgot to answer your second question.  On my Novena, 'uname -m'
returns "armv7l".  The problem is this: I suspect that if the build
machine has an armv8 processor, it will return something different like
"armv8l".

  Mark

patchelf apparently needs extensive changes to work on ARM

[Mark H Weaver]

Upstream 'patchelf' doesn't work on ARM.
Here's the upstream bug report:

  https://github.com/NixOS/patchelf/issues/8

I had to apply a rather large patch from a fork
of 'patchelf' to get it working:

  
https://github.com/sriemer/patchelf/commit/0a96239cea6b97b9a0fff80da576e58ca2dfb2a2

For now, I've applied this patch on the 'wip-armhf' branch in commit
8de9362f3.  If anyone has a better suggestion, I'm all ears.

 Mark

Re: Pass --build= to native builds by default?

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> Mark H Weaver  writes:
>>
>>> l...@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Mark H Weaver  skribis:
>>>>
>>>>> It turns out that on ARM systems, the result of 'config.guess' depends
>>>>> on the result of 'uname -m'.  In other words, details of the kernel (and
>>>>> perhaps processor?) on the build machine will determine the triplet of
>>>>> our builds, which in turn may affect what set of instructions is used.
>>>>
>>>> Do you know how the ‘uname -m’ output is used in config.guess?  What
>>>> does it return on ARM?
>>>
>>> The output of 'uname -m' becomes the first (cpu) component of the GNU
>>> triplet.  uname(1) gets its information from the kernel via the uname(2)
>>> system call.  The field returned by 'uname -m' is described as "Hardware
>>> identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.

[...]

>> I forgot to answer your second question.  On my Novena, 'uname -m'
>> returns "armv7l".  The problem is this: I suspect that if the build
>> machine has an armv8 processor, it will return something different like
>> "armv8l".
>
> But how do the armv7 and armv8 ISAs differ?  If it’s more like
> additional SIMD extensions, then indeed it would make sense to use the
> same name for both; but if there’s more than that, perhaps using
> different triplets is the right thing?

Using different triplets depending on the architecture revision of the
CPU in the build machine?  I thought we were aiming for deterministic
builds.

I may not have explained the issue clearly.  Please let me try again.

I don't see why it matters how the ISAs differ.  The important point is
that a build process may intentionally produce different build outputs
when the triplet is armv8l-* vs armv7l-*.

Even if we didn't care about deterministic builds, there's a more
serious problem.  Packages built for armv8l are free to use armv8 ISA
extensions that do not work at all on an armv7l processor.

As things stand now, we must ensure that none of our build machines
implement ISA extensions beyond the baseline requirements we've chosen
for armhf-linux.

  Mark

[PATCHES] gnu: bootstrap: Fix egrep and fgrep in bootstrap binaries

[Mark H Weaver]

The first of these two patches adds support for optional "snippets" to
'package-from-tarball', which is used to unpack the bootstrap tarballs.

The second patch uses this new feature to patch the shebangs in 'egrep'
and 'fgrep' immediately after unpacking the static-binaries bootstrap
tarball.

Obviously, this is for core-updates, the first 2 out of 6 remaining
patches needed for ARM.  It is a prerequisite for ARM support, because
'fgrep' is typically needed for ARM specific tests in configure scripts.

What do you think?

  Mark


>From 00e491bc64f6aa1fcebd19d1aa7370d1708d9d3a Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 31 Dec 2014 03:38:26 -0500
Subject: [PATCH 1/2] gnu: bootstrap: Add support for snippets to
 'package-from-tarball'.

* gnu/packages/bootstrap.scm (package-from-tarball): Add new keyword
  argument #:snippet.
---
 gnu/packages/bootstrap.scm | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 5a19783..05444dd 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014 Ludovic Courtès 
+;;; Copyright © 2014, 2015 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -87,10 +88,13 @@
  (patch patch))
 (origin-patches source))
 
-(define (package-from-tarball name source program-to-test description)
+(define* (package-from-tarball name source program-to-test description
+   #:key snippet)
   "Return a package that correspond to the extraction of SOURCE.
 PROGRAM-TO-TEST is a program to run after extraction of SOURCE, to
-check whether everything is alright."
+check whether everything is alright.  If SNIPPET is provided, it is
+evaluated after extracting SOURCE.  SNIPPET should return true if
+successful, or false to signal an error."
   (package
 (name name)
 (version "0")
@@ -112,6 +116,7 @@ check whether everything is alright."
(with-directory-excursion out
  (and (zero? (system* tar "xvf"
   (string-append builddir "/binaries.tar")))
+  ,@(if snippet (list snippet) '())
   (zero? (system* (string-append "bin/" ,program-to-test)
   "--version"
 (inputs
-- 
2.1.2

>From 34412a7202cabafd25daaa045f70aa567e867d3b Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 31 Dec 2014 03:41:50 -0500
Subject: [PATCH 2/2] gnu: bootstrap: Fix egrep and fgrep after unpacking
 bootstrap binaries.

* gnu/packages/bootstrap.scm (%bootstrap-coreutils&co): Add #:snippet argument
  to 'package-from-tarball' that calls 'patch-shebang' on egrep and fgrep
  after unpacking.  Test 'fgrep' instead of 'true'.
---
 gnu/packages/bootstrap.scm | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 05444dd..f1110d9 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -264,8 +264,15 @@ $out/bin/guile --version~%"
   ("mips64el-linux"
(base32
 "072y4wyfsj1bs80r6vbybbafy8ya4vfy7qj25dklwk97m6g71753"))
-"true"; the program to test
-"Bootstrap binaries of Coreutils, Awk, etc."))
+"fgrep"; the program to test
+"Bootstrap binaries of Coreutils, Awk, etc."
+#:snippet
+'(let ((path (list (string-append (getcwd) "/bin"
+   (chmod "bin" #o755)
+   (patch-shebang "bin/egrep" path)
+   (patch-shebang "bin/fgrep" path)
+   (chmod "bin" #o555)
+   #t)))
 
 (define %bootstrap-binutils
   (package-from-tarball "binutils-bootstrap"
-- 
2.1.2

Re: Problem with natively-built armhf bootstrap compiler

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>>> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
>>> index a7156bf..dd33a26 100644
>>> --- a/gnu/packages/gcc.scm
>>> +++ b/gnu/packages/gcc.scm
>>> @@ -213,7 +213,7 @@ where the OS part is overloaded to denote a specific 
>>> ABI---into GCC
>>> ;; below, make sure to update the relevant code in
>>> ;; %gcc-static package as needed.
>>> (format #f "#define GNU_USER_TARGET_LIB_SPEC \
>>> -\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 
>>> -rpath=~a/lib -lgcc_s}} \" ~a"
>>> +\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 
>>> -rpath=~a/lib %{pthread: -lgcc_s}}} \" ~a"
>>> libc libc libdir libdir suffix))
>>>(("#define GNU_USER_TARGET_STARTFILE_SPEC.*$" line)
>>> (format #f "#define STANDARD_STARTFILE_PREFIX_1 
>>> \"~a/lib\"
>>>
>>> I believe this is enough to address what the comment mentions (glibc
>>> dlopening libgcc_s for pthread functions), but this will need testing.
>
> I see you applied this patch.  However, after grepping through libc, I
> found there are other cases where libgcc_s is dlopened, including to
> walk the stack, which has nothing to do with pthread.
>
> So I think the status quo is safer.
>
> WDYT?

Okay, sounds good to me.  I also discovered that tcl doesn't pass
-pthread on GNU/Linux by default, but only -lpthread.

I've reverted the patch above and will soon post another patch which
implements my original workaround and worked well in practice.

 Thanks,
   Mark

[PATCH] gnu: gmp: Apply fixes for armhf

[Mark H Weaver]

This is another patch needed for ARM.  It depends on an earlier patch
which moves 'nix-system->gnu-triplet' to (guix utils) and exports it
(part of "'gcc-configure-flags-for-triplet' for native compilers too").

 Mark

>From 1e63fb1f2d7fa22bb9a009c055499e3c039a0bca Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 31 Dec 2014 04:17:45 -0500
Subject: [PATCH] gnu: gmp: Apply fixes for armhf.

* gnu/packages/patches/gmp-arm-asm-nothumb.patch: New file.
* gnu-system.am (dist_patch_DATA): Add it.
* gnu/packages/multiprecision.scm (gmp): Add patch.  Include --build triplet
  in configure args when building natively.
* gnu/packages/commencement.scm (gcc-final): Use bootstrap guile to
  build gmp-source.
---
 gnu-system.am  |  1 +
 gnu/packages/commencement.scm  |  2 +-
 gnu/packages/multiprecision.scm| 15 +--
 gnu/packages/patches/gmp-arm-asm-nothumb.patch | 21 +
 4 files changed, 36 insertions(+), 3 deletions(-)
 create mode 100644 gnu/packages/patches/gmp-arm-asm-nothumb.patch

diff --git a/gnu-system.am b/gnu-system.am
index 5dd3a49..ca468b3 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -372,6 +372,7 @@ dist_patch_DATA =		\
   gnu/packages/patches/glibc-bootstrap-system.patch		\
   gnu/packages/patches/glibc-ldd-x86_64.patch			\
   gnu/packages/patches/glibc-mips-dangling-vfork-ref.patch	\
+  gnu/packages/patches/gmp-arm-asm-nothumb.patch		\
   gnu/packages/patches/gnunet-fix-scheduler.patch		\
   gnu/packages/patches/gnunet-fix-tests.patch		\
   gnu/packages/patches/gobject-introspection-cc.patch		\
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index e6d03b1..8fa90fe 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -531,7 +531,7 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a \"$@\"~%"
 (native-inputs `(("texinfo" ,texinfo-boot0)
  ,@(package-native-inputs gcc-boot0)))
 
-(inputs `(("gmp-source" ,(package-source gmp))
+(inputs `(("gmp-source" ,(bootstrap-origin (package-source gmp)))
   ("mpfr-source" ,(package-source mpfr))
   ("mpc-source" ,(package-source mpc))
   ("binutils" ,binutils-final)
diff --git a/gnu/packages/multiprecision.scm b/gnu/packages/multiprecision.scm
index 377d922..ddbfc79 100644
--- a/gnu/packages/multiprecision.scm
+++ b/gnu/packages/multiprecision.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013 Ludovic Courtès 
+;;; Copyright © 2014 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -22,6 +23,7 @@
   #:use-module (gnu packages m4)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix utils)
   #:use-module (guix build-system gnu))
 
 (define-public gmp
@@ -35,7 +37,8 @@
 version ".tar.xz"))
 (sha256
  (base32
-  "0r5pp27cy7ch3dg5v0rsny8bib1zfvrza6027g2mp5f6v8pd6mli"
+  "0r5pp27cy7ch3dg5v0rsny8bib1zfvrza6027g2mp5f6v8pd6mli"))
+(patches (list (search-patch "gmp-arm-asm-nothumb.patch")
(build-system gnu-build-system)
(native-inputs `(("m4" ,m4)))
(outputs '("out" "debug"))
@@ -43,7 +46,15 @@
 '(;; Build a "fat binary", with routines for several
   ;; sub-architectures.
   "--enable-fat"
-  "--enable-cxx")))
+  "--enable-cxx"
+
+  ;; FIXME: gmp-6.0.0a's config.guess fails on
+  ;; multi-core armhf systems.
+  ,@(if (%current-target-system)
+'()
+(let ((triplet
+   (nix-system->gnu-triplet (%current-system
+  (list (string-append "--build=" triplet)))
(synopsis "Multiple-precision arithmetic library")
(description
 "GMP is a library for arbitrary precision arithmetic, operating on
diff --git a/gnu/packages/patches/gmp-arm-asm-nothumb.patch b/gnu/packages/patches/gmp-arm-asm-nothumb.patch
new file mode 100644
index 000..666cf58
--- /dev/null
+++ b/gnu/packages/patches/gmp-arm-asm-nothumb.patch
@@ -0,0 +1,21 @@
+
+# HG changeset patch
+# User Torbjorn Granlund 
+# Date 1396602422 -7200
+# Node ID 676e2d0f0e4dd301a7066079d2c9326c25c34a40
+# Parent  0194a75b56b21a9196626430af86c5bd9110c42d
+Conditionalise ARM asm on !__thumb__.
+
+diff -r 0194a75b56b2 -r 676e2d0f0e4d mpn/generic/div_qr_1n_pi1.c
+--- a/mpn/generic/div_qr_1n_pi1.c	Thu Apr 03 23:58:51 2014 +0200
 b/mpn/generic/div_qr_1n_pi1.c	Fri Apr 04 11:07:02 

[PATCHES] Use 'gcc-configure-flags-for-triplet' for native compilers too

[Mark H Weaver]

Hello Guix,

These two patches change the 'gcc' packages so that the result of
'gcc-configure-flags-for-triplet' is passed to GCC's configure in all
cases.  Previously, they were only used when building cross compilers.
On ARM, these extra flags are always needed to specify the hard-float
ABI and the default code generation options.

These are for core-updates, obviously.  Comments and suggestions
welcome!

 Mark


>From ed1644c06ce49658ba7399928512eaaaefcdffb3 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 31 Dec 2014 03:47:40 -0500
Subject: [PATCH 1/2] Move 'nix-system->gnu-triplet' to (guix utils) and export it.

* gnu/packages/commencement.scm (nix-system->gnu-triplet): Move to...
* guix/utils.scm (nix-system->gnu-triplet): ... here.  Fix docstring typo.
---
 gnu/packages/commencement.scm | 13 -
 guix/utils.scm| 14 ++
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 20831de..e6d03b1 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -122,19 +122,6 @@
 ("file" ,file-boot0)
 ,@%bootstrap-inputs))
 
-(define* (nix-system->gnu-triplet
-  #:optional (system (%current-system)) (vendor "unknown"))
-  "Return an a guess of the GNU triplet corresponding to Nix system
-identifier SYSTEM."
-  (let* ((dash (string-index system #\-))
- (arch (substring system 0 dash))
- (os   (substring system (+ 1 dash
-(string-append arch
-   "-" vendor "-"
-   (if (string=? os "linux")
-   "linux-gnu"
-   os
-
 (define* (boot-triplet #:optional (system (%current-system)))
   ;; Return the triplet used to create the cross toolchain needed in the
   ;; first bootstrapping stage.
diff --git a/guix/utils.scm b/guix/utils.scm
index d0d2e8a..7ac586b 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -61,6 +61,7 @@
 location-column
 source-properties->location
 
+nix-system->gnu-triplet
 gnu-triplet->nix-system
 %current-system
 %current-target-system
@@ -476,6 +477,19 @@ previous value of the keyword argument."
  (()
   (reverse before)))
 
+(define* (nix-system->gnu-triplet
+  #:optional (system (%current-system)) (vendor "unknown"))
+  "Return a guess of the GNU triplet corresponding to Nix system
+identifier SYSTEM."
+  (let* ((dash (string-index system #\-))
+ (arch (substring system 0 dash))
+ (os   (substring system (+ 1 dash
+(string-append arch
+   "-" vendor "-"
+   (if (string=? os "linux")
+   "linux-gnu"
+   os
+
 (define (gnu-triplet->nix-system triplet)
   "Return the Nix system type corresponding to TRIPLET, a GNU triplet as
 returned by `config.guess'."
-- 
2.1.2

>From 8ca1e958b2efe26ba7b7b90afe321b81248e6636 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Wed, 7 Jan 2015 15:00:44 +
Subject: [PATCH 2/2] gnu: gcc: Use 'gcc-configure-flags-for-triplet' for
 native compilers too.

* gnu/packages/gcc.scm (gcc-configure-flags-for-triplet): Do not export it.
  (gcc-4.7): Pass the result of 'gcc-configure-flags-for-triplet' to configure
  for all builds, including native ones.
---
 gnu/packages/cross-base.scm |  1 -
 gnu/packages/gcc.scm| 12 ++--
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 0f32c9f..a9ae5ee 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -88,7 +88,6 @@ may be either a libc package or #f.)"
 (substitute-keyword-arguments (package-arguments gcc-4.8)
   ((#:configure-flags flags)
`(append (list ,(string-append "--target=" target)
-  ,@(gcc-configure-flags-for-triplet target)
   ,@(if libc
 '()
 `( ;; Disable features not needed at this stage.
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 02de128..e21f958 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -35,7 +35,7 @@
   ;; Base URL for GCC's infrastructure.
   "ftp://gcc.gnu.org/pub/gcc/infrastructure/";)
 
-(define-public (gcc-configure-flags-for-triplet target)
+(define (gcc-configure-flags-for-triplet target)
   "Return a list of additional GCC `configure' flags for TARGET, a GNU triplet.
 
 The purpose of this procedure is to translate extended GNU triplets---e.g.,
@@ -101,11 +101,11 @@ where the OS part is overloaded to de

[PATCH] gnu: gcc-static: Remove -lgcc_s from GNU_USER_TARGET_LIB_SPEC

[Mark H Weaver]

Here's my proposed patch to fix our generated bootstrap gcc to not try
to link with the nonexistent -lgcc_s.  I used this to create the current
set of 'armhf-linux' bootstrap tarballs and to bootstrap my initial
system (including 'emacs').

What do you think?

  Mark

>From 108a59f3b2ec5d3551c54d5f713a7ed34171acb3 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Thu, 1 Jan 2015 22:53:55 -0500
Subject: [PATCH] gnu: gcc-static: Remove -lgcc_s from GNU_USER_TARGET_LIB_SPEC.

* gnu/packages/make-bootstrap.scm (%gcc-static): Add 'remove-lgcc_s
  phase.
* gnu/packages/gcc.scm (gcc-4.7): Add comment.
---
 gnu/packages/gcc.scm|  5 +
 gnu/packages/make-bootstrap.scm | 14 +-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a510af4..02de128 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -207,6 +207,11 @@ where the OS part is overloaded to denote a specific ABI---into GCC
;; libgcc_s.so when pthread_cancel support is needed, but
;; having it in the application's RUNPATH isn't enough; see
;; <http://sourceware.org/ml/libc-help/2013-11/msg00023.html>.)
+   ;;
+   ;; NOTE: The '-lgcc_s' added below needs to be removed in a
+   ;; later phase of %gcc-static.  If you change the string
+   ;; below, make sure to update the relevant code in
+   ;; %gcc-static package as needed.
(format #f "#define GNU_USER_TARGET_LIB_SPEC \
 \"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64 -rpath=~a/lib -lgcc_s}} \" ~a"
libc libc libdir libdir suffix))
diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index f6ef2e3..88fad0e 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -430,7 +430,19 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
"--disable-libquadmath"
"--disable-decimal-float")
   (remove (cut string-match "--(.*plugin|enable-languages)" <>)
-  ,flags))
+  ,flags)))
+((#:phases phases)
+ `(alist-cons-after
+   'pre-configure 'remove-lgcc_s
+   (lambda _
+ ;; Remove the '-lgcc_s' added to GNU_USER_TARGET_LIB_SPEC in
+ ;; the 'pre-configure phase of our main gcc package, because
+ ;; that shared library is not present in this static gcc.  See
+ ;; <https://lists.gnu.org/archive/html/guix-devel/2015-01/msg8.html>.
+ (substitute* (find-files "gcc/config"
+  "^gnu-user.*\\.h$")
+   ((" -lgcc_s}}") "}}")))
+   ,phases)
  (native-inputs
   (if (%current-target-system)
   `(;; When doing a Canadian cross, we need GMP/MPFR/MPC both
-- 
2.1.2

[PATCH] gnu: patchelf: On ARM, apply experimental patch to get it working

[Mark H Weaver]

The upstream 'patchelf' doesn't work on ARM, and apparently the problems
are non-trivial to fix.  See:

  https://github.com/NixOS/patchelf/issues/8

This commit applies the only patch I was able to find to get it (mostly)
working.

Unfortunately, I found that this modified 'patchelf' corrupted one of
the libraries in icu4c.  For now, I've worked around this problem by
avoiding the use of 'patchelf' in icu4c.  Ideally, I'd like to reduce
the number of uses of 'patchelf' in our tree, preferably down to zero.

In the meantime, this patch will allow us to make progress on ARM, so
I'd like to apply it to core-updates.  The patch is only applied when
building for ARM targets.

What do you think?

  Mark


>From 0822111f984611bb0f585dcdfd9db214277053c4 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 6 Jan 2015 21:41:55 +
Subject: [PATCH] gnu: patchelf: On ARM, apply experimental patch to get it
 working.

* gnu/packages/patches/patchelf-rework-for-arm.patch: New file.
* gnu-system.am: Add it.
* gnu/packages/elf.scm: Apply patch when the target is ARM.
---
 gnu-system.am  |   1 +
 gnu/packages/elf.scm   |  21 +
 gnu/packages/patches/patchelf-rework-for-arm.patch | 473 +
 3 files changed, 495 insertions(+)
 create mode 100644 gnu/packages/patches/patchelf-rework-for-arm.patch

diff --git a/gnu-system.am b/gnu-system.am
index ca468b3..51d55c7 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -428,6 +428,7 @@ dist_patch_DATA =		\
   gnu/packages/patches/orpheus-cast-errors-and-includes.patch	\
   gnu/packages/patches/ots-no-include-missing-file.patch	\
   gnu/packages/patches/patchelf-page-size.patch			\
+  gnu/packages/patches/patchelf-rework-for-arm.patch		\
   gnu/packages/patches/patchutils-xfail-gendiff-tests.patch	\
   gnu/packages/patches/perl-no-sys-dirs.patch			\
   gnu/packages/patches/perl-tk-x11-discover.patch		\
diff --git a/gnu/packages/elf.scm b/gnu/packages/elf.scm
index 7fc689c..46c59c3 100644
--- a/gnu/packages/elf.scm
+++ b/gnu/packages/elf.scm
@@ -100,6 +100,27 @@ addr2line, and more.")
"1rqpg84wrd3fa16wa9vqdvasnc05yz49w207cz1l0wrl4k8q97y9"))
  (patches (list (search-patch "patchelf-page-size.patch")
 (build-system gnu-build-system)
+
+;; XXX: The upstream 'patchelf' doesn't support ARM.  The only available
+;;  patch makes significant changes to the algorithm, possibly
+;;  introducing bugs.  So, we apply the patch only on ARM systems.
+(inputs
+ (if (string-prefix? "arm" (or (%current-target-system) (%current-system)))
+ `(("patch/rework-for-arm" ,(search-patch
+ "patchelf-rework-for-arm.patch")))
+ '()))
+(arguments
+ (if (string-prefix? "arm" (or (%current-target-system) (%current-system)))
+ `(#:phases (alist-cons-after
+ 'unpack 'patch/rework-for-arm
+ (lambda* (#:key inputs #:allow-other-keys)
+   (let ((patch-file
+  (assoc-ref inputs "patch/rework-for-arm")))
+ (zero? (system* "patch" "--force" "-p1"
+ "--input" patch-file
+ %standard-phases))
+ '()))
+
 (home-page "http://nixos.org/patchelf.html";)
 (synopsis "Modify the dynamic linker and RPATH of ELF executables")
 (description
diff --git a/gnu/packages/patches/patchelf-rework-for-arm.patch b/gnu/packages/patches/patchelf-rework-for-arm.patch
new file mode 100644
index 000..6f4eb8f
--- /dev/null
+++ b/gnu/packages/patches/patchelf-rework-for-arm.patch
@@ -0,0 +1,473 @@
+Rework the growing algorithm in patchelf to support ARM systems.
+See <https://github.com/NixOS/patchelf/issues/8>.
+This patch copied from:
+<https://github.com/sriemer/patchelf/commit/0a96239cea6b97b9a0fff80da576e58ca2dfb2a2>
+
+From 0a96239cea6b97b9a0fff80da576e58ca2dfb2a2 Mon Sep 17 00:00:00 2001
+From: Sebastian Parschauer 
+Date: Sat, 28 Jun 2014 01:24:57 +0200
+Subject: [PATCH] Rework the growing algorithm
+
+On ARM systems there is no space in virtual memory for another LOAD
+area in front of the code LOAD area. So insert data to its end
+instead. At this location there should be enough space in virtual
+memory due to alignment. We can extend it until the end of the
+alignment but the file shift may be greater as it must be aligned
+to the page size. Do the same for the data LOAD area.
+---
+ src/patchelf.cc | 357 ++--
+ 1 file changed, 142 insertions(+), 215 deletions(-)
+
+diff --git a/src/patchelf.cc b/src/patchelf.cc
+index dcbfd