Re: [PATCH] Update IcedTea.

[Andreas Enge]

Hi Ricardo,

do you have an answer to the question below?

On Wed, Jul 22, 2015 at 07:33:56PM +0200, Andreas Enge wrote:
> > I would also like to suggest changing the names ‘icedtea6’ and
> > ‘icedtea7’ to just ‘icedtea’.  They cannot be installed into the same
> > profile anyway and users will most likely want the latest version by
> > default.
> 
> These version numbers are anyway a bit confusing...
> 
> Is there a reason to keep icedtea6 around at all? If not, you might drop it
> and rename icedtea7 as icedtea.

Andreas

Re: [PATCH] Update IcedTea.

[Andreas Enge]

On Mon, Sep 07, 2015 at 11:27:26AM +0200, Ricardo Wurmus wrote:
> The only reason why I added icedtea7 and kept icedtea6 was that I
> previously did not know that icedtea7 could be bootstrapped with GCJ.
> In the first attempt to get icedtea7 to compile I used icedtea6 to build
> it.  Now that this is no longer required, I think there is no good
> reason not to rename “icedtea7” to “icedtea” and drop icedtea6.

Great!

> It should be noted, though, that “icedtea7” inherits from “icedtea6” and
> dropping “icedtea6” would either require a rewrite of the package
> definition for “icedtea7” or force us to retain the “icedtea6”
> definition (making it private).

Rewriting the icedtea(7) definition sounds like the proper solution to me.

Thanks!

Andreas

Re: [PATCH] Update IcedTea.

[Ricardo Wurmus]

Andreas Enge  writes:

> On Wed, Jul 22, 2015 at 07:33:56PM +0200, Andreas Enge wrote:
>> > I would also like to suggest changing the names ‘icedtea6’ and
>> > ‘icedtea7’ to just ‘icedtea’.  They cannot be installed into the same
>> > profile anyway and users will most likely want the latest version by
>> > default.
>> 
>> These version numbers are anyway a bit confusing...
>> 
>> Is there a reason to keep icedtea6 around at all? If not, you might drop it
>> and rename icedtea7 as icedtea.

The only reason why I added icedtea7 and kept icedtea6 was that I
previously did not know that icedtea7 could be bootstrapped with GCJ.
In the first attempt to get icedtea7 to compile I used icedtea6 to build
it.  Now that this is no longer required, I think there is no good
reason not to rename “icedtea7” to “icedtea” and drop icedtea6.

It should be noted, though, that “icedtea7” inherits from “icedtea6” and
dropping “icedtea6” would either require a rewrite of the package
definition for “icedtea7” or force us to retain the “icedtea6”
definition (making it private).

~~ Ricardo

Re: [PATCH] Add gMTP.

[Andreas Enge]

This looks good and very useful, thanks!

Andreas

Re: [PATCH] Add MAFFT.

[Ricardo Wurmus]

Andreas Enge  writes:

>> +protein sequences.  For instance, it offers L-INS-i (accurate; for alignment
>> +of 
> Is this an artefact of the mailer?

In the original patch I see this instead:

> + "MAFFT offers a range of multiple alignment methods for nucleotide and
> +protein sequences.  For instance, it offers L-INS-i (accurate; for alignment
> +of <∼200 sequences) and FFT-NS-2 (fast; for alignment of <∼30,000
> +sequences).")

It’s not a problem with the patch.

~~ Ricardo

Re: [PATCH] gnu: pbr: Update to 1.6.0

[Andreas Enge]

This looks harmless to push, if you checked that the dependent
python-oslotest still builds.

Andreas

Re: [PATCH] Add MAFFT.

[Andreas Enge]

On Tue, Aug 25, 2015 at 10:58:42PM +0200, Ludovic Courtès wrote:
> It seems this message was left unanswered.  Andreas?

I had a cursory look at the patch, here are some comments:

On Thu, Jul 23, 2015 at 10:43:31PM +1000, Ben Woodcroft wrote:
> +   #:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs 
> "out"))
> +  (string-append "BINDIR=" (string-append
> +(assoc-ref %outputs 
> "out")
> +"/bin")))

Would it make sense to include this into a 
  (let ((out (assoc-ref %outputs out))) ...)
?

> + (add-after 'enter-dir 'patch-makefile
> +(lambda _
> +  (substitute* "Makefile"
> +(("^SCRIPTS = mafft mafft-homologs.rb")
> + "SCRIPTS = mafft")
> +(((string-append "^PROGS = dvtditr dndfast7 dndblast"
> + " sextet5 mafft-distance"))
> + "PROGS = dvtditr dndfast7 dndblast sextet5")

This "string-append" to concatenate two literal strings is difficult to read;
I would suggest to move the "(lambda" more to the left so that everything
fits into one line.

> +(synopsis
> + "Multiple sequence alignment program for unix-like operating systems")

Maybe drop "for unix-like operating systems"; instead, you could add
"for nucleotide and protein sequences" from the description.

> +protein sequences.  For instance, it offers L-INS-i (accurate; for alignment
> +of 

Re: [PATCH] Add gMTP.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> From 83997a0d8783395d0307498d3b7c32b0de9fb404 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Sun, 6 Sep 2015 23:07:10 +0200
> Subject: [PATCH] gnu: Add gMTP.
>
> * gnu/packages/libusb.scm (gmtp): New variable.

[...]

> +(description "gMTP is a simple graphical MTP client.  [...]

How about:

  “gMTP is a simple graphical client for the Media Transfer Protocol
  (MTP), which allows media files to be transferred to and from
  many portable devices.”  [...]

Otherwise LGTM.

Thanks,
Ludo’.

Re: [PATCH 1/2] gnu: glibc/linux: Rename "linux-headers" input to "kernel-headers".

[Manolis Ragkousis]

Updated all the files referring to linux-headers in gnu/packages. The
part of the patch referring to
glibc/hurd was kept out, as there is no glibc/hurd in master.

Is it okay to push it to core-updates?
From b5d724cae502e8bf664b71045f4053e6d35a98df Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis 
Date: Mon, 7 Sep 2015 14:01:51 +0300
Subject: [PATCH] gnu: packages: Change label from "linux-headers" to
 "kernel-headers".

* gnu/packages/base.scm (glibc)[propagated-inputs, arguments]: Change to "kernel-headers".
* gnu/packages/commencement.scm (glibc-final-with-bootstrap-bash)[propagated-inputs]: Same
* gnu/packages/cross-base.scm (cross-gcc)[native-inputs]: Same.
  (cross-libc)[propagated-inputs, arguments]: Same.
* gnu/packages/make-bootstrap.scm (%glibc-stripped)[inputs, arguments]: Same.
---
 gnu/packages/base.scm   | 4 ++--
 gnu/packages/commencement.scm   | 2 +-
 gnu/packages/cross-base.scm | 6 +++---
 gnu/packages/make-bootstrap.scm | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index f35f619..79f9b60 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -459,7 +459,7 @@ store.")
 
;; Glibc's  refers to , for instance, so glibc
;; users should automatically pull Linux headers as well.
-   (propagated-inputs `(("linux-headers" ,linux-libre-headers)))
+   (propagated-inputs `(("kernel-headers" ,linux-libre-headers)))
 
(outputs '("out" "debug"))
 
@@ -495,7 +495,7 @@ store.")
 (string-append "libc_cv_localedir=/run/current-system/locale")
 
 (string-append "--with-headers="
-   (assoc-ref %build-inputs "linux-headers")
+   (assoc-ref %build-inputs "kernel-headers")
"/include")
 
 ;; This is the default for most architectures as of GNU libc 2.21,
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 74c3f30..d336318 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -334,7 +334,7 @@
"export CPATH\n"
all "\n"
,phases)
- (propagated-inputs `(("linux-headers" ,(linux-libre-headers-boot0
+ (propagated-inputs `(("kernel-headers" ,(linux-libre-headers-boot0
  (native-inputs
   `(("texinfo" ,texinfo-boot0)
 ("perl" ,perl-boot0)))
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index d64cdd1..fc3cea1 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -247,7 +247,7 @@ GCC that does not target a libc; otherwise, target that libc."
(alist-delete "libc" %final-inputs
(if libc
`(("libc" ,libc)
- ("xlinux-headers";the target headers
+ ("xkernel-headers";the target headers
   ,@(assoc-ref (package-propagated-inputs libc)
"linux-headers"))
  ,@inputs)
@@ -313,7 +313,7 @@ XBINUTILS and the cross tool chain."
 `(alist-cons-before
   'configure 'set-cross-linux-headers-path
   (lambda* (#:key inputs #:allow-other-keys)
-(let ((linux (assoc-ref inputs "linux-headers")))
+(let ((linux (assoc-ref inputs "kernel-headers")))
   (setenv "CROSS_CPATH"
   (string-append linux "/include"))
   #t))
@@ -321,7 +321,7 @@ XBINUTILS and the cross tool chain."
 
 ;; Shadow the native "linux-headers" because glibc's recipe expects the
 ;; "linux-headers" input to point to the right thing.
-(propagated-inputs `(("linux-headers" ,xlinux-headers)))
+(propagated-inputs `(("kernel-headers" ,xlinux-headers)))
 
 ;; FIXME: 'static-bash' should really be an input, not a native input, but
 ;; to do that will require building an intermediate cross libc.
diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index 1b70d54..6b1b4ef 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -346,7 +346,7 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
   (libdir (string-append out "/lib"))
   (incdir (string-append out "/include"))
   (libc   (assoc-ref %build-inputs "libc"))
-  (linux  (assoc-ref %build-inputs "linux-headers")))
+  (linux  (assoc-ref %build-inputs "kernel-headers")))
  (mkdir-p libdir)
  (for-each (lambda (file)
  (let ((target (string-append libdir "/"
@@ -381,7 +381,7 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
 (parameterize ((%current-target-system #f))
   (cross-libc 

Re: Ilmbase and openexr header files

[Ludovic Courtès]

Andreas Enge  skribis:

> the openexr package has ilmbase as a propagated input, since the openexr
> header files include ilmbase header files. However, there is a problem with
> subdirectories, since both packages put the include files into
> .../include/OpenEXR.
>
> Then, for instance,
>
> /gnu/store/bnp4nsy7v4lzw562k4v7w34jdg8vkc3s-openexr-2.2.0/include/OpenEXR/ImfInt64.h
> contains a line
>#include "ImathInt64.h"
> This is the file
>
> /gnu/store/6ih7f5cq1amgh134f75xw2sxk39p9gi7-ilmbase-2.2.0/include/OpenEXR/ImathInt64.h
> which of course is not found

This shouldn’t be a problem because:

--8<---cut here---start->8---
$ pkg-config OpenEXR --cflags
-pthread 
-I/gnu/store/bnp4nsy7v4lzw562k4v7w34jdg8vkc3s-openexr-2.2.0/include/OpenEXR 
-I/gnu/store/6ih7f5cq1amgh134f75xw2sxk39p9gi7-ilmbase-2.2.0/include/OpenEXR 
--8<---cut here---end--->8---

> There was an error when adding openexr support to vigra, which I repaired
> with a kludge, and it is happening again in the package hugin that I am
> preparing. So I wonder what would be the proper fix.

My guess is that Vigra doesn’t use pkg-config, and thus doesn’t get the
right -I flags.

Is that a correct guess?  :-)

Thanks,
Ludo’.

Re: [PATCH] gnu: Add ruby-rack.

[Ludovic Courtès]

David Thompson  skribis:

> From a740a5ca98c02bd0e9c792677dfc8ff8464c8365 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Fri, 4 Sep 2015 16:47:52 -0400
> Subject: [PATCH] gnu: Add ruby-rack.
>
> * gnu/packages/ruby.scm (ruby-rack): New variable.

[...]

> + (add-before 'check 'fix-tests
> +   (lambda _
> + ;; A few of the tests use the length of a file on disk for
> + ;; Content-Length and Content-Range headers.  However, this file
> + ;; has a shebang in it which an earlier phase patches, growing
> + ;; the file size from 193 to 239 bytes.
> + (substitute* '("test/spec_file.rb")
> +   (("193") "239")

I think this phase should use the actual length of the shebang, in case
the store is not at /gnu/store, with something like:

  (- (string-length (which "ruby")) (string-length "/usr/bin/ruby"))

Could you look into it?

TIA,
Ludo’.

Re: [PATCH] build: container: Use the same clone flags as fork(3).

[Ludovic Courtès]

David Thompson  skribis:

> This patch resolves an issue I was having when working with containers
> at the REPL, which means it probably presented undetected issues
> elsewhere.

Calling ‘primitive-fork’ at the REPL is not very useful anyway since you
end up with two Guiles trying to read from the same tty.

> From 61ebbe55f7f6d4d4eb42db957d6fc7b4eaf282a6 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Sat, 5 Sep 2015 14:10:08 -0400
> Subject: [PATCH] build: container: Use the same clone flags as fork(3).
>
> The intent is to make 'clone' behave a lot more like 'primitive-fork', which
> calls clone(2) with SIGCHLD, CLONE_CHILD_CLEARTID, and CLONE_CHILD_SETTID
> flags.  Notably, running 'clone' at the REPL without these flags would break
> the REPL beyond repair.
>
> * guix/build/syscalls.scm (CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID): New
>   variables.
> * gnu/build/linux-container.scm (namespaces->bit-mask): Add
>   CLONE_CHILD_CLEARTID and CLONE_CHILD_SETTID to bit mask.

Looking at clone(2) and libc, I’m guessing that without these flags, the
child would have a wrong idea of its thread ID, which in turn may cause
all sorts of problems, right?

LGTM.

Thanks,
Ludo’.

Re: Texinfo in descriptions?

[Alex Kost]

Ludovic Courtès (2015-09-07 00:31 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-09-06 16:51 +0300) wrote:
>>
>>> Alex: We should maybe disable the paragraph filling code in guix.el so
>>> that it doesn’t mess up with formatting?
>>
>> I don't mind (if you remember I didn't actually like such filling¹, and
>> I've never used it).  So we can change the default value of
>> ‘guix-package-info-fill-heading’ variable.
>
> Yes, though ideally the elisp code would provide Scheme code the current
> value of ‘fill-column’ so that text is filled using the right width.
> WDYT?

Do you mean that ‘package-description-string’ should take an optional
'fill-column' argument, so that it can be called from the elisp side?

If so, I'm afraid currently there is no way to have such fine tuning for
the received package parameters.  The package (or generation) data is
received all at once using ‘guix-get-entries’, for example:

(guix-get-entries guix-current-profile 'package 'name '("r"))
(guix-get-entries guix-current-profile 'generation 'last '(3))

As you can see there is no place to specify fill-column there.  But I
have noted this thing, perhaps it will become possible one day.

-- 
Alex

Re: Ilmbase and openexr header files

[Ludovic Courtès]

Andreas Enge  skribis:

> On Mon, Sep 07, 2015 at 02:03:17PM +0200, Ludovic Courtès wrote:
>> This shouldn’t be a problem because:
>> --8<---cut here---start->8---
>> $ pkg-config OpenEXR --cflags
>> -pthread 
>> -I/gnu/store/bnp4nsy7v4lzw562k4v7w34jdg8vkc3s-openexr-2.2.0/include/OpenEXR 
>> -I/gnu/store/6ih7f5cq1amgh134f75xw2sxk39p9gi7-ilmbase-2.2.0/include/OpenEXR 
>> --8<---cut here---end--->8---
>> My guess is that Vigra doesn’t use pkg-config, and thus doesn’t get the
>> right -I flags.
>> Is that a correct guess?  :-)
>
> Indeed it is, thanks for looking into this!
>
> The same problem occurs with hugin, which I am currently packaging; it uses
> pkg-config, but there are error messages
>-- WARNING: you are using the obsolete 'PKGCONFIG' macro, use FindPkgConfig
> So it is possible that pkg-config is used incorrectly there.

This is a warning emitted by a CMake function, I think.

Could you check in ‘CMakeOutput.log’ or whatever it’s called what
‘pkg-config’ it invoked and what its result was?

Thanks,
Ludo’.

Re: Texinfo in descriptions?

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-09-07 00:31 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2015-09-06 16:51 +0300) wrote:
>>>
 Alex: We should maybe disable the paragraph filling code in guix.el so
 that it doesn’t mess up with formatting?
>>>
>>> I don't mind (if you remember I didn't actually like such filling¹, and
>>> I've never used it).  So we can change the default value of
>>> ‘guix-package-info-fill-heading’ variable.
>>
>> Yes, though ideally the elisp code would provide Scheme code the current
>> value of ‘fill-column’ so that text is filled using the right width.
>> WDYT?
>
> Do you mean that ‘package-description-string’ should take an optional
> 'fill-column' argument, so that it can be called from the elisp side?

Yes.

> If so, I'm afraid currently there is no way to have such fine tuning for
> the received package parameters.  The package (or generation) data is
> received all at once using ‘guix-get-entries’, for example:
>
> (guix-get-entries guix-current-profile 'package 'name '("r"))
> (guix-get-entries guix-current-profile 'generation 'last '(3))
>
> As you can see there is no place to specify fill-column there.  But I
> have noted this thing, perhaps it will become possible one day.

Oh I see.  Thanks for checking anyway.

Ludo’.

Re: [PATCH] gnu: Add ruby-byebug.

[Ludovic Courtès]

David Thompson  skribis:

> From a0a69a802b1d26bf91a663c0d5a0afde510ce5f0 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Fri, 4 Sep 2015 15:09:30 -0400
> Subject: [PATCH] gnu: Add ruby-byebug.
>
> * gnu/packages/ruby.scm (ruby-byebug): New variable.

LGTM, thanks.

Ludo'.

Re: Ilmbase and openexr header files

[Andreas Enge]

On Mon, Sep 07, 2015 at 02:03:17PM +0200, Ludovic Courtès wrote:
> This shouldn’t be a problem because:
> --8<---cut here---start->8---
> $ pkg-config OpenEXR --cflags
> -pthread 
> -I/gnu/store/bnp4nsy7v4lzw562k4v7w34jdg8vkc3s-openexr-2.2.0/include/OpenEXR 
> -I/gnu/store/6ih7f5cq1amgh134f75xw2sxk39p9gi7-ilmbase-2.2.0/include/OpenEXR 
> --8<---cut here---end--->8---
> My guess is that Vigra doesn’t use pkg-config, and thus doesn’t get the
> right -I flags.
> Is that a correct guess?  :-)

Indeed it is, thanks for looking into this!

The same problem occurs with hugin, which I am currently packaging; it uses
pkg-config, but there are error messages
   -- WARNING: you are using the obsolete 'PKGCONFIG' macro, use FindPkgConfig
So it is possible that pkg-config is used incorrectly there. In any case,
I feel less bad now about using the same work-around...

Andreas

Re: [PATCHES] Add ruby-pg and adjust Ruby build system

[Thompson, David]

On Sun, Sep 6, 2015 at 5:34 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> From 8f29026d37a66d8bcbddc6f32a6354d93d40f50d Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Sat, 29 Aug 2015 21:55:12 -0400
>> Subject: [PATCH 1/2] build: ruby: Avoid long build directory names.
>>
>> Having the hash of the source gem in the source directory file name proved to
>> be problematic when running the test suite for the 'pg' gem that creates
>> UNIX-domain sockets in the source directory and exceeded the 108 character
>> limit on GNU/Linux systems.
>>
>> * guix/build/ruby-build-system.scm (unpack): Rename unpacked gem directory to
>>   "gem".
>
> Heh, LGTM.
>
>> From efced81a77bc4a5a72a430987ab8168196358d47 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Sat, 29 Aug 2015 22:03:51 -0400
>> Subject: [PATCH 2/2] gnu: Add ruby-pg.
>>
>> * gnu/packages/ruby.scm (ruby-pg): New variable.
>
> OK.

Pushed, thanks!

- Dave

Re: [PATCH] build: container: Setup /dev/console.

[Thompson, David]

On Mon, Sep 7, 2015 at 12:03 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> From dc797eb8e306655b10bd466d64ef5deaf428259f Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Sat, 1 Aug 2015 13:54:40 -0400
>> Subject: [PATCH] build: container: Setup /dev/console.
>>
>> * gnu/build/linux-container.scm (mount-file-systems): Bind mount the
>>   controlling terminal as /dev/console.
>
> [...]
>
>> +  ;; Setup the container's /dev/console by bind mounting the psuedo-terminal
>  ^^^
> Typo.

Thanks.  I have a bad tendency to transpose those characters.

> Otherwise LGTM, thanks!

Fixed and pushed.

- Dave

Re: [PATCH] build: container: Use the same clone flags as fork(3).

[Thompson, David]

On Mon, Sep 7, 2015 at 12:13 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> This patch resolves an issue I was having when working with containers
>> at the REPL, which means it probably presented undetected issues
>> elsewhere.
>
> Calling ‘primitive-fork’ at the REPL is not very useful anyway since you
> end up with two Guiles trying to read from the same tty.

Yes, this is true, but it made it glaringly obvious that something was wrong.

(match (primitive-fork) (0 (primitive-exit 0)) (pid pid))  ; OK
since it exits immediately

(match (clone (logior CLONE_NEWUSER SIGCHLD)) (0 (primitive-exit
0)) (pid pid)) ; Broken REPL!

>> From 61ebbe55f7f6d4d4eb42db957d6fc7b4eaf282a6 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Sat, 5 Sep 2015 14:10:08 -0400
>> Subject: [PATCH] build: container: Use the same clone flags as fork(3).
>>
>> The intent is to make 'clone' behave a lot more like 'primitive-fork', which
>> calls clone(2) with SIGCHLD, CLONE_CHILD_CLEARTID, and CLONE_CHILD_SETTID
>> flags.  Notably, running 'clone' at the REPL without these flags would break
>> the REPL beyond repair.
>>
>> * guix/build/syscalls.scm (CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID): New
>>   variables.
>> * gnu/build/linux-container.scm (namespaces->bit-mask): Add
>>   CLONE_CHILD_CLEARTID and CLONE_CHILD_SETTID to bit mask.
>
> Looking at clone(2) and libc, I’m guessing that without these flags, the
> child would have a wrong idea of its thread ID, which in turn may cause
> all sorts of problems, right?

Yes, that seems to be the case.  I was always a little suspicious
about not using the same clone flags as fork, and I finally ran into a
case where it made a difference.

> LGTM.

Pushed, thanks!

- Dave

Re: [PATCH] gnu: Add ruby-rack.

[Thompson, David]

On Mon, Sep 7, 2015 at 12:02 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> From a740a5ca98c02bd0e9c792677dfc8ff8464c8365 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Fri, 4 Sep 2015 16:47:52 -0400
>> Subject: [PATCH] gnu: Add ruby-rack.
>>
>> * gnu/packages/ruby.scm (ruby-rack): New variable.
>
> [...]
>
>> + (add-before 'check 'fix-tests
>> +   (lambda _
>> + ;; A few of the tests use the length of a file on disk for
>> + ;; Content-Length and Content-Range headers.  However, this 
>> file
>> + ;; has a shebang in it which an earlier phase patches, growing
>> + ;; the file size from 193 to 239 bytes.
>> + (substitute* '("test/spec_file.rb")
>> +   (("193") "239")
>
> I think this phase should use the actual length of the shebang, in case
> the store is not at /gnu/store, with something like:
>
>   (- (string-length (which "ruby")) (string-length "/usr/bin/ruby"))
>
> Could you look into it?

Good point.  It was easy to implement, too:

(let ((size-diff (- (string-length (which "ruby"))
(string-length "/usr/bin/env ruby"
  (substitute* '("test/spec_file.rb")
(("193")
 (number->string (+ 193 size-diff)))
(("bytes(.)22-33" all delimiter)
 (string-append "bytes"
delimiter
(number->string (+ 22 size-diff))
"-"
(number->string (+ 33 size-diff))

Pushed, thanks!

- Dave

Re: [PATCH] gnu: pbr: Update to 1.6.0

[Cyril Roelandt]

On 09/07/2015 11:07 AM, Andreas Enge wrote:
> This looks harmless to push

Btw, is it OK to directly push such changes? I feel like they usually
pollute the mailing list more than anything else :/


Cyril.

Re: [PATCH] gnu: pbr: Update to 1.6.0

[Cyril Roelandt]

On 09/07/2015 11:07 AM, Andreas Enge wrote:
> This looks harmless to push, if you checked that the dependent
> python-oslotest still builds.
> 

Pushed in ea8e40d031c3295805dc9357098c2c13aa516e1a .


Cyril.

[PATCH 2/3] gnu: Add python-stevedore.

[Cyril Roelandt]

* gnu/packages/openstack.scm (python-stevedore, python2-stevedore): New 
variables.
---
 gnu/packages/openstack.scm | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/gnu/packages/openstack.scm b/gnu/packages/openstack.scm
index 1641476..e5ba867 100644
--- a/gnu/packages/openstack.scm
+++ b/gnu/packages/openstack.scm
@@ -139,6 +139,49 @@ and sensible default behaviors into your setuptools run.")
 (define-public python2-pbr
   (package-with-python2 python-pbr))
 
+(define-public python-stevedore
+  (package
+(name "python-stevedore")
+(version "1.7.0")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append
+   "https://pypi.python.org/packages/source/s/stevedore/stevedore-;
+   version
+   ".tar.gz"))
+(sha256
+  (base32
+"149pjc0c3z6khjisn4yil3f94qjnzwafz093wc8rrzbw828qdkv8"
+(build-system python-build-system)
+(propagated-inputs
+  `(("python-six" ,python-six)))
+(inputs
+  `(("python-pbr" ,python-pbr)
+("python-setuptools" ,python-setuptools)
+;; Tests
+("python-docutils" ,python-docutils)
+("python-mock" ,python-mock)
+("python-oslotest" ,python-oslotest)
+("python-sphinx" ,python-sphinx)))
+(home-page
+  "https://github.com/dreamhost/stevedore;)
+(synopsis
+  "Manage dynamic plugins for Python applications")
+(description
+  "Python makes loading code dynamically easy, allowing you to configure
+and extend your application by discovering and loading extensions (“plugins”)
+at runtime.  Many applications implement their own library for doing this,
+using __import__ or importlib.  stevedore avoids creating yet another extension
+mechanism by building on top of setuptools entry points.  The code for managing
+entry points tends to be repetitive, though, so stevedore provides manager
+classes for implementing common patterns for using dynamically loaded
+extensions.")
+(license asl2.0)))
+
+(define-public python2-stevedore
+  (package-with-python2 python-stevedore))
+
 ;; Packages from the Oslo library
 (define-public python-oslo.i18n
   (package
-- 
2.1.4

[PATCH 3/3] gnu: Add python-oslo.config.

[Cyril Roelandt]

* gnu/packages/openstack.scm (python-oslo.config, python2-oslo.config): New 
variables.
---
 gnu/packages/openstack.scm | 37 +
 1 file changed, 37 insertions(+)

diff --git a/gnu/packages/openstack.scm b/gnu/packages/openstack.scm
index e5ba867..dc30207 100644
--- a/gnu/packages/openstack.scm
+++ b/gnu/packages/openstack.scm
@@ -183,6 +183,43 @@ extensions.")
   (package-with-python2 python-stevedore))
 
 ;; Packages from the Oslo library
+(define-public python-oslo.config
+  (package
+(name "python-oslo.config")
+(version "2.4.0")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append
+   
"https://pypi.python.org/packages/source/o/oslo.config/oslo.config-;
+   version
+   ".tar.gz"))
+(sha256
+  (base32
+"13r778jfb0fhna37c2pd1f2xipnsbd7zli7qhn96acrzymrwj5k1"
+(build-system python-build-system)
+(propagated-inputs
+  `(("python-netaddr" ,python-netaddr)
+("python-six" ,python-six)
+("python-stevedore" ,python-stevedore)))
+(inputs
+  `(("python-pbr" ,python-pbr)
+("python-setuptools" ,python-setuptools)
+;; Tests
+("python-oslo.i18n" ,python-oslo.i18n)
+("python-mock" ,python-mock)
+("python-oslotest" ,python-oslotest)
+("python-testscenarios" ,python-testscenarios)))
+(home-page "https://launchpad.net/oslo;)
+(synopsis "Oslo Configuration API")
+(description
+  "The Oslo configuration API supports parsing command line arguments and
+.ini style configuration files.")
+(license asl2.0)))
+
+(define-public python2-oslo.config
+  (package-with-python2 python-oslo.config))
+
 (define-public python-oslo.i18n
   (package
 (name "python-oslo.i18n")
-- 
2.1.4

[PATCH] build: ruby: Add support for tarball and directory sources.

[David Thompson]

>From 612a4a692375f241934de03d24064dbef1c7294c Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 7 Sep 2015 22:58:05 -0400
Subject: [PATCH] build: ruby: Add support for tarball and directory sources.

Previously, the Ruby build system only knew how to work with gem archives,
which made it difficult to build unreleased gems from a Git repository or
released gems in tarball form.

* gnu/build/ruby-build-system.scm (gnu:unpack, gem-archive?): New procedures.
  (unpack): Use GNU build system unpack phase for non-gem sources.
  (build): Rebuild the gemspec iff the source is a gem archive.
---
 guix/build/ruby-build-system.scm | 86 ++--
 1 file changed, 48 insertions(+), 38 deletions(-)

diff --git a/guix/build/ruby-build-system.scm b/guix/build/ruby-build-system.scm
index 4184ccc..2685da1 100644
--- a/guix/build/ruby-build-system.scm
+++ b/guix/build/ruby-build-system.scm
@@ -41,53 +41,63 @@ directory."
 ((file-name . _) file-name)
 (() (error "No files matching pattern: " pattern
 
+(define gnu:unpack (assq-ref gnu:%standard-phases 'unpack))
+
+(define (gem-archive? file-name)
+  (string-match "^.*\\.gem$" file-name))
+
 (define* (unpack #:key source #:allow-other-keys)
   "Unpack the gem SOURCE and enter the resulting directory."
-  (and (zero? (system* "gem" "unpack" source))
-   ;; The unpacked gem directory is named the same as the archive, sans
-   ;; the ".gem" extension.  It is renamed to simply "gem" in an effort to
-   ;; keep file names shorter to avoid UNIX-domain socket file names and
-   ;; shebangs that exceed the system's fixed maximum length when running
-   ;; test suites.
-   (let ((dir (match:substring (string-match "^(.*)\\.gem$"
- (basename source))
-   1)))
- (rename-file dir "gem")
- (chdir "gem")
- #t)))
+  (if (gem-archive? source)
+  (and (zero? (system* "gem" "unpack" source))
+   ;; The unpacked gem directory is named the same as the archive,
+   ;; sans the ".gem" extension.  It is renamed to simply "gem" in an
+   ;; effort to keep file names shorter to avoid UNIX-domain socket
+   ;; file names and shebangs that exceed the system's fixed maximum
+   ;; length when running test suites.
+   (let ((dir (match:substring (string-match "^(.*)\\.gem$"
+ (basename source))
+   1)))
+ (rename-file dir "gem")
+ (chdir "gem")
+ #t))
+  ;; Use GNU unpack strategy for things that aren't gem archives.
+  (gnu:unpack #:source source)))
 
 (define* (build #:key source #:allow-other-keys)
   "Build a new gem using the gemspec from the SOURCE gem."
+  (define (first-gemspec)
+(first-matching-file "\\.gemspec$"))
 
   ;; Remove the original gemspec, if present, and replace it with a new one.
   ;; This avoids issues with upstream gemspecs requiring tools such as git to
   ;; generate the files list.
-  (let ((gemspec (or (false-if-exception
-  (first-matching-file "\\.gemspec$"))
- ;; Make new gemspec if one wasn't shipped.
- ".gemspec")))
-
-(when (file-exists? gemspec) (delete-file gemspec))
-
-;; Extract gemspec from source gem.
-(let ((pipe (open-pipe* OPEN_READ "gem" "spec" "--ruby" source)))
-  (dynamic-wind
-(const #t)
-(lambda ()
-  (call-with-output-file gemspec
-(lambda (out)
-  ;; 'gem spec' writes to stdout, but 'gem build' only reads
-  ;; gemspecs from a file, so we redirect the output to a file.
-  (while (not (eof-object? (peek-char pipe)))
-(write-char (read-char pipe) out
-  #t)
-(lambda ()
-  (close-pipe pipe
-
-;; Build a new gem from the current working directory.  This also allows any
-;; dynamic patching done in previous phases to be present in the installed
-;; gem.
-(zero? (system* "gem" "build" gemspec
+  (when (gem-archive? source)
+(let ((gemspec (or (false-if-exception (first-gemspec))
+   ;; Make new gemspec if one wasn't shipped.
+   ".gemspec")))
+
+  (when (file-exists? gemspec) (delete-file gemspec))
+
+  ;; Extract gemspec from source gem.
+  (let ((pipe (open-pipe* OPEN_READ "gem" "spec" "--ruby" source)))
+(dynamic-wind
+  (const #t)
+  (lambda ()
+(call-with-output-file gemspec
+  (lambda (out)
+;; 'gem spec' writes to stdout, but 'gem build' only reads
+;; gemspecs from a file, so we redirect the output to a file.
+(while (not (eof-object? (peek-char pipe)))
+  (write-char (read-char pipe) 

Re: [PATCH 0/2] Add oslo.i18n

[Cyril Roelandt]

On 09/02/2015 01:04 AM, Cyril Roelandt wrote:
> These patches add oslo.i18n, a library that is part of Oslo.
> 
> Cyril Roelandt (2):
>   gnu: python-testtools: fix propagated inputs.
>   gnu: Add oslo.i18n.
> 


Pushed both patches in 05de40c5d342232fae86e7839baec1ebffeac022 and
8531b326f166403298f238817db728c2d8df6bb9 .

Cyril.

[PATCH 1/3] gnu: Add python-netaddr.

[Cyril Roelandt]

* gnu/packages/python.scm (python-netaddr, python2-netaddr): New variables.
---
 gnu/packages/python.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index f9ad951..0231bce 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -4739,3 +4739,31 @@ reading and writing MessagePack data.")
 
 (define-public python2-msgpack
   (package-with-python2 python-msgpack))
+
+(define-public python-netaddr
+  (package
+(name "python-netaddr")
+(version "0.7.18")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append
+   "https://pypi.python.org/packages/source/n/netaddr/netaddr-;
+   version
+   ".tar.gz"))
+(sha256
+  (base32
+"06dxjlbcicq7q3vqy8agq11ra01kvvd47j4mk6dmghjsyzyckxd1"
+(build-system python-build-system)
+(arguments `(#:tests? #f)) ;; No tests.
+(inputs
+  `(("python-setuptools" ,python-setuptools)))
+(home-page "https://github.com/drkjam/netaddr/;)
+(synopsis
+  "Pythonic manipulation of IPv4, IPv6, CIDR, EUI and MAC network 
addresses")
+(description
+  "A Python library for representing and manipulating network addresses.")
+(license bsd-3)))
+
+(define-public python2-netaddr
+  (package-with-python2 python-netaddr))
-- 
2.1.4

[PATCH 0/3] Add oslo.config.

[Cyril Roelandt]

These three patches add oslo.config.

Cyril Roelandt (3):
  gnu: Add python-netaddr.
  gnu: Add python-stevedore.
  gnu: Add python-oslo.config.

 gnu/packages/openstack.scm | 80 ++
 gnu/packages/python.scm| 28 
 2 files changed, 108 insertions(+)

-- 
2.1.4

Re: (Geiser or guile bug) Guix-daemon output is missing

[Alex Kost]

Ludovic Courtès (2015-09-07 00:28 +0300) wrote:

> Alex Kost  skribis:
>
>> Now the bug itself:
>>
>> 1. Start Geiser (M-x run-guile)
>>
>> 2. Make a scheme buffer and evaluate (use-modules (guix scripts build))
>>there using "C-x C-e" or "C-M-x" (or any other "geiser-eval-…"
>>command).  This is important: do not ,use module in the REPL;
>>evaluate ‘use-modules’ clause in a scheme buffer!
>>
>> 3. Go to the REPL and run the following there:
>>
>>(catch 'quit (lambda () (guix-build "test-package")) (const #t)).
>>
>> You get only "The following derivation will be built: …" but there is no
>> build output from guix-daemon.
>
> Ha ha!  Try this before:
>
>   (current-build-output-port (current-error-port))
>
> The trick here is that ‘current-build-output-port’ is initialized to
> (current-error-port), but that initialization happens at the top-level,
> apparently before Geiser has rebound ‘current-error-port’, hence the
> silence.
>
> HTH!

Thanks for answering!  This helped to make a simple recipe, so I
reported it: .

-- 
Alex