Re: How to deal with Latin1 filenames?

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> Hello Guix,
>
> I'm trying to package the Norwegian Bokmål Aspell dictionary, which
> contains a 'bokmål.alias' in the source archive. This causes 'readdir'
> to throw a decoding-error.

I'm sorry, the file name is actually ISO-8859-1 encoded. I've updated
the subject. From what I understand Guile should be able to handle
unicode file names just fine.

The easiest fix is probably to make the file name unicode upstream, but
it would be nice to know a workaround. I've tried overriding the
'install-locale' phase to set various iso-8859-1 locales instead of the
default "en_US.utf-8", but getting "invalid argument" on everything.

Are there any Latin1 locales available in the build environment, and
would setting it make any difference?


signature.asc
Description: PGP signature

How to deal with UTF-8 filenames?

[Marius Bakke]

Hello Guix,

I'm trying to package the Norwegian Bokmål Aspell dictionary, which
contains a 'bokmål.alias' in the source archive. This causes 'readdir'
to throw a decoding-error. Here is the backtrace:

phase `unpack' succeeded after 0.1 seconds
starting phase `patch-usr-bin-file'
Backtrace:
In ice-9/boot-9.scm:
 160: 15 [catch #t # ...]
In unknown file:
   ?: 14 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 12 [eval # #]
In ice-9/boot-9.scm:
2404: 11 [save-module-excursion #]
4056: 10 [#]
1727: 9 [%start-stack load-stack #]
1732: 8 [#]
In unknown file:
   ?: 7 [primitive-load 
"/gnu/store/2f1ikq718l8q0lz7y771m503vdwjf2q9-aspell-dict-nb-0.50.1-0-guile-builder"]
In ice-9/eval.scm:
 387: 6 [eval # ()]
In srfi/srfi-1.scm:
 827: 5 [every1 # ...]
In 
/gnu/store/ciqw5z470c8ihl1kfswj1j3ix6hs092d-module-import/guix/build/gnu-build-system.scm:
 627: 4 [# #]
 166: 3 [patch-usr-bin-file #:native-inputs #f ...]
In 
/gnu/store/ciqw5z470c8ihl1kfswj1j3ix6hs092d-module-import/guix/build/utils.scm:
 336: 2 [find-files "." "^configure$" ...]
In ice-9/ftw.scm:
 481: 1 [loop "." "" ...]
In unknown file:
   ?: 0 [readdir #]

ERROR: In procedure readdir:
ERROR: Throw to key `decoding-error' with args `("scm_from_stringn" "input 
locale conversion error" 84 #vu8(98 111 107 109 229 108 46 97 108 105 97 115))'.
builder for 
`/gnu/store/fnhnrmshycf6qgfv6b9xsil3ppvracad-aspell-dict-nb-0.50.1-0.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/419306s2mf3300906ikk39vjy0bqqs64-profile.drv': 1 dependencies 
couldn't be built

This also happens in the 'patch-source-shebangs' phase which is
necessary for the 'configure' script to work.

Any suggestions for how to deal with this?

Patch attached.



signature.asc
Description: PGP signature
>From 6e6dd7144eecf9c04ba47c4a49207f17181259be Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Sun, 4 Dec 2016 19:56:20 +0100
Subject: [PATCH] =?UTF-8?q?gnu:=20Add=20Norwegian=20Bokm=C3=A5l=20Aspell?=
 =?UTF-8?q?=20dictionary.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/packages/aspell.scm (aspell-dict-nb): New variable.
---
 gnu/packages/aspell.scm | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gnu/packages/aspell.scm b/gnu/packages/aspell.scm
index d27e8090b..396e89b2c 100644
--- a/gnu/packages/aspell.scm
+++ b/gnu/packages/aspell.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2016 John Darrington <j...@gnu.org>
 ;;; Copyright © 2016 Efraim Flashner <efr...@flashner.co.il>
 ;;; Copyright © 2016 Christopher Andersson <christop...@8bits.nu>
+;;; Copyright © 2016 Marius Bakke <mba...@fastmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -150,6 +151,14 @@ dictionaries, including personal ones.")
  (base32
   "1gdf7bc1a0kmxsmphdqq8pl01h667mjsj6hihy6kqy14k5qdq69v")))
 
+(define-public aspell-dict-nb
+  (aspell-dictionary "nb" "Norwegian Bokmål"
+ #:version "0.50.1-0"
+ #:prefix "aspell-"
+ #:sha256
+ (base32
+  "12i2bmgdnlkzfinb20j2a0j4a20q91a9j8qpq5vgabbvc65nwx77")))
+
 (define-public aspell-dict-nl
   (aspell-dictionary "nl" "Dutch"
  #:version "0.50-2"
-- 
2.11.0

Re: New Danish PO file for 'guix' (version 0.11.0)

[Marius Bakke]

Translation Project Robot  writes:

> Hello, gentle maintainer.
>
> This is a message from the Translation Project robot.
>
> A revised PO file for textual domain 'guix' has been submitted
> by the Danish team of translators.  The file is available at:
>
> http://translationproject.org/latest/guix/da.po
>
> (We can arrange things so that in the future such files are automatically
> e-mailed to you when they arrive.  Ask at the address below if you want this.)
>
> All other PO files for your package are available in:
>
> http://translationproject.org/latest/guix/
>
> Please consider including all of these in your next release, whether
> official or a pretest.
>
> Whenever you have a new distribution with a new version number ready,
> containing a newer POT file, please send the URL of that distribution
> tarball to the address below.  The tarball may be just a pretest or a
> snapshot, it does not even have to compile.  It is just used by the
> translators when they need some extra translation context.
>
> The following HTML page has been updated:
>
> http://translationproject.org/domain/guix.html
>
> If any question arises, please contact the translation coordinator.
>
> Thank you for all your work,
>
> The Translation Project robot, in the
> name of your translation coordinator.
> 

Tak, applied as 2f1b17b2371f3cd843fcee1068d543437e8d61af!


signature.asc
Description: PGP signature

Re: New Danish PO file for 'guix-packages' (version 0.11.0)

[Marius Bakke]

Translation Project Robot  writes:

> Hello, gentle maintainer.
>
> This is a message from the Translation Project robot.
>
> A revised PO file for textual domain 'guix-packages' has been submitted
> by the Danish team of translators.  The file is available at:
>
> http://translationproject.org/latest/guix-packages/da.po
>
> (We can arrange things so that in the future such files are automatically
> e-mailed to you when they arrive.  Ask at the address below if you want this.)
>
> All other PO files for your package are available in:
>
> http://translationproject.org/latest/guix-packages/
>
> Please consider including all of these in your next release, whether
> official or a pretest.
>
> Whenever you have a new distribution with a new version number ready,
> containing a newer POT file, please send the URL of that distribution
> tarball to the address below.  The tarball may be just a pretest or a
> snapshot, it does not even have to compile.  It is just used by the
> translators when they need some extra translation context.
>
> The following HTML page has been updated:
>
> http://translationproject.org/domain/guix-packages.html
>
> If any question arises, please contact the translation coordinator.
>
> Thank you for all your work,
>
> The Translation Project robot, in the
> name of your translation coordinator.
> 

Applied as 58786f55e52a08f6f7b66c8578ec99c8840e5311, tak!


signature.asc
Description: PGP signature

Re: [PATCH 0/2] i3 window manager update 4.13

[Marius Bakke]

Leo Famulari  writes:

> These patches update i3 to the latest upstream version, 4.13.
>
> The first seems necessary since xcb-util-cursor's pkg-config file
> includes the propagated packages in its 'Requires.private' field. I
> noticed this issue when the i3 build failed because these packages
> weren't available.
>
> i3 itself has switched from a hand-made build system to Autotools.
>
> I haven't actually tested this package, since my GuixSD system is not
> currently using a graphical interface.


>
> Leo Famulari (2):
>   gnu: xcb-util-cursor: Propagate dependences from 'xcb-cursor.pc'.
>   gnu: i3-wm: Update to 4.13.
>
>  gnu/packages/wm.scm   | 37 +
>  gnu/packages/xorg.scm |  5 +++--
>  2 files changed, 32 insertions(+), 10 deletions(-)

Thanks for this! I'm using the new version right now.

The patches LGTM.

On a wholly-unrelated note, I found that
bf7ef1bb848db0977b54ea012789adc68751c68a made the early boot environment
unable to find fsck.ext4 after unlocking a cryptsetup partition (even
though it is present in the initrd).


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add mktorrent.

[Marius Bakke]

Tobias Geerinckx-Rice  writes:

> * gnu/packages/bittorrent.scm (mktorrent): New variable.
> ---
>
> ‘guix lint’ — sorry: @code{guix lint} complained about quotes, so I
> cheated a bit and went with @dfn tags instead. It's a sort of mutual
> equality definition, after all.
>
> Kind regards,
>
> T G-R
>
>  gnu/packages/bittorrent.scm | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)

LGTM, but the SHA1 implementation that's used in absence of OpenSSL is
public-domain.


signature.asc
Description: PGP signature

Re: [PATCH 0/5] Fixes for packages with new python build sytem

[Marius Bakke]

Hartmut Goebel  writes:

> This patches fixes some build issues caused by using the new python build
> system.
>
> Hartmut Goebel (5):
>   gnu: calibre: Do not use python setuptools for building.
>   gnu: python-numpydoc: Correct inputs.
>   gnu: python2-ipython: Fix inputs.
>   gnu: python-numpy: Fix inputs.
>   gnu: dblatex: Update comment.
>
>  gnu/packages/docbook.scm | 10 +++---
>  gnu/packages/ebook.scm   |  3 +++
>  gnu/packages/python.scm  |  9 +
>  3 files changed, 15 insertions(+), 7 deletions(-)

Thanks! These LGTM.



signature.asc
Description: PGP signature

[PATCH] gnu: cairomm: Update to 1.15.1.

[Marius Bakke]

The gnome mirrors appears to have stopped updating this package at
1.12.0. This is the latest version from cairographics.org.

>From ed1c762e210eb9dfe6845d751b79b234edb6183c Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Wed, 30 Nov 2016 19:08:38 +0100
Subject: [PATCH] gnu: cairomm: Update to 1.15.1.

* gnu/packages/gtk.scm (cairomm): Update to 1.15.1.
[source]: Download from cairographics.org.
[home-page]: Use HTTPS.
---
 gnu/packages/gtk.scm | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 8a258b54c..85a0d2318 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -921,15 +921,14 @@ guile-gnome-platform (GNOME developer libraries), and guile-gtksourceview.")
 (define-public cairomm
   (package
 (name "cairomm")
-(version "1.12.0")
+(version "1.15.1")
 (source (origin
   (method url-fetch)
-  (uri (string-append "mirror://gnome/sources/cairomm/"
-  (version-major+minor version) "/"
-  name "-" version ".tar.xz"))
+  (uri (string-append "https://cairographics.org/releases/cairomm-;
+  version ".tar.gz"))
   (sha256
(base32
-"1rmgs6zjj2vaxh9hsa0944m23fdn1psycqh7bi984qd8jj1xljm5"
+"1qkw8lq3iinpcmngny54mwiqavz9ls2mmgrd2swkbn6j3xl5zvhm"
 (build-system gnu-build-system)
 (arguments
  ;; The examples lack -lcairo.
@@ -940,7 +939,7 @@ guile-gnome-platform (GNOME developer libraries), and guile-gtksourceview.")
("freetype" ,freetype)
("fontconfig" ,fontconfig)
("cairo" ,cairo)))
-(home-page "http://cairographics.org/;)
+(home-page "https://cairographics.org/;)
 (synopsis "C++ bindings to the Cairo 2D graphics library")
 (description
  "Cairomm provides a C++ programming interface to the Cairo 2D graphics
-- 
2.11.0

Re: [PATCH] gnu: Add libtermkey

[Marius Bakke]

José Miguel Sánchez García  writes:

> Add libtermkey (I hope it's finally correct!)

Hi José,

Thanks for your contribution! The patch looks mostly good, see comments
inline.

>
> -- 
> José Miguel Sánchez García
> From 8ad5713a25aeb40b9021b30beba7b11d3cf432df Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Jos=C3=A9=20Miguel=20S=C3=A1nchez=20Garc=C3=ADa?=
>  
> Date: Mon, 5 Dec 2016 15:12:56 +0100
> Subject: [PATCH] gnu: Add libtermkey.
>
> ---
>  gnu/packages/libtermkey.scm | 54 
> +
>  1 file changed, 54 insertions(+)
>  create mode 100644 gnu/packages/libtermkey.scm

I think this should go in 'terminals.scm' instead of a new file. We try
to categorize related programs together to keep the file count low.

> diff --git a/gnu/packages/libtermkey.scm b/gnu/packages/libtermkey.scm
> new file mode 100644
> index 000..e3280ca
> --- /dev/null
> +++ b/gnu/packages/libtermkey.scm
> @@ -0,0 +1,54 @@
> +;;; GNU Guix --- Functional package management for GNU
> +;;; Copyright © 2016 José Miguel Sánchez García 
> +;;;
> +;;; This file is part of GNU Guix.
> +;;;
> +;;; GNU Guix is free software; you can redistribute it and/or modify it
> +;;; under the terms of the GNU General Public License as published by
> +;;; the Free Software Foundation; either version 3 of the License, or (at
> +;;; your option) any later version.
> +;;;
> +;;; GNU Guix is distributed in the hope that it will be useful, but
> +;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +;;; GNU General Public License for more details.
> +;;;
> +;;; You should have received a copy of the GNU General Public License
> +;;; along with GNU Guix.  If not, see .
> +
> +(define-module (gnu packages libtermkey)
> +  #:use-module (guix packages)
> +  #:use-module (guix download)
> +  #:use-module (guix build-system gnu)
> +  #:use-module (guix licenses)
> +  #:use-module (gnu packages autotools)
> +  #:use-module (gnu packages ncurses)
> +  #:use-module (gnu packages pkg-config))
> +
> +(define-public libtermkey
> +  (package
> +(name "libtermkey")
> +(version "0.18")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "http://www.leonerd.org.uk/code/;
> +  name "/" name "-" version ".tar.gz"))
> +  (sha256
> +(base32 
> "09ir16kaarv55mnc4jn2sqnjjhzpb1aha51wpd9ayif887g4d5r3"
> +(build-system gnu-build-system)
> +(arguments '(

Please move the "'(" to the next line so that the indentation matches
the start of the expression. Or move #:make-flags one line up and
re-indent the rest of the block, but I think starting the 'arguments' on
a new line looks better.

> +  #:make-flags (list
> +"CC=gcc"
> +(string-append "PREFIX=" (assoc-ref %outputs "out")))
> +  #:phases (modify-phases %standard-phases
> +(delete 'configure))
> +  #:tests? #f))
> +(native-inputs `(("libtool", libtool)
> + ("ncurses", ncurses)
> + ("pkg-config", pkg-config)))

Are any of these inputs used at runtime and not just required for
building? If so, they should be a regular 'input' and not a
'native-input'. ncurses is usually linked as a library and thus needs to
match the target architecture.

See the 'package' reference in the Guix manual for more information:
https://www.gnu.org/software/guix/manual/guix.html#package-Reference

Guix will often automatically detect whether inputs are runtime
dependencies. You can run `guix gc -R $(./pre-inst-env guix build
libtermkey)` to check which inputs are referenced by the built product.

> +(synopsis "Keyboard entry processing libary for terminal-based programs")
   ^ missing 'r' :-) 

> +(description
> +  "Libtermkey handles all the necessary logic to recognise special keys, 
> UTF-8
> +combining, and so on, with a simple interface.")
> +(home-page "http://www.leonerd.org.uk/code/libtermkey;)
> +(license expat)))

The rest LGTM. Can you send an updated patch for 'terminals.scm'
addressing the above points? Thanks!


signature.asc
Description: PGP signature

Re: [PATCH 1/1] gnu: python-matplotlib: Fix documentation reST markup error.

[Marius Bakke]

Danny Milosavljevic  writes:

> * gnu/packages/python.scm (python-matplotlib): Fix documentation reST markup 
> error.
> ---
>  gnu/packages/python.scm | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index 4e1a6b4a8..bc9058ba3 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -3629,6 +3629,11 @@ transcendental functions).")
> (sha256
>  (base32
>   "1dn05cvd0g984lzhh72wa0z93psgwshbbg93fkab6slx5m3l95av"))
> +   (modules '((guix build utils)))
> +   (snippet
> +'(substitute* "doc/users/intro.rst"
> +   ;; Fix reST markup error (see 
> )
> +   (("[[][*][]]") "[#]")))

Please run this substitution in a phase instead. Source snippets change
the source presented to users running `guix build -S` and should be
reserved for critical bug fixes and reproducibility problems, but
otherwise stay as close to upstream as possible.


signature.asc
Description: PGP signature

Re: [PATCH v4 0/3] Prepare for Sphinx update

[Marius Bakke]

Danny Milosavljevic  writes:

> This adds new packages that will be required for an eventual Sphinx update.
>
> Danny Milosavljevic (3):
>   gnu: Add python-snowballstemmer.
>   gnu: Add python-sphinx-cloud-sptheme.
>   gnu: Add python-sphinx-alabaster-theme.
>
>  gnu/packages/python.scm | 74 
> +
>  1 file changed, 74 insertions(+)

Thanks, applied! I changed the description of cloud-sptheme to use
double quotes instead of single quotes to make "guix lint" happy, and
made the snowballstemmer synopsis more generic.

Also removed the delay properties, as AFAIK this is only needed when the
python2 variant requires changes to the expression.

Another low-hanging fruit for the pypi importer is to make it indent
properly ;-)


signature.asc
Description: PGP signature

Re: [PATCH 2/5] gnu: gnu-make: Don't replace 'sh' reference with 'bash'.

[Marius Bakke]

Leo Famulari  writes:

> * gnu/packages/base.scm (gnu-make)[arguments]: Use /bin/sh instead of 
> /bin/bash
> in 'set-default-shell' phase.
> ---
>  gnu/packages/base.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> index 66c5e0cdc..1f25a05aa 100644
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -364,7 +364,7 @@ functionality beyond that which is outlined in the POSIX 
> standard.")
>  (let ((bash (assoc-ref inputs "bash")))
>(substitute* "job.c"
>  (("default_shell =.*$")
> - (format #f "default_shell = \"~a/bin/bash\";\n"
> + (format #f "default_shell = \"~a/bin/sh\";\n"
>   bash)

Could you add a #t at the end of this phase while at it? :-)


signature.asc
Description: PGP signature

Re: [PATCH v3] gnu: Add ghc-markdown-unlit.

[Marius Bakke]

Danny Milosavljevic  writes:

> * gnu/packages/haskell.scm (ghc-markdown-unlit): New variable.
> ---
>  gnu/packages/haskell.scm | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
> index de061a630..5d3c85475 100644
> --- a/gnu/packages/haskell.scm
> +++ b/gnu/packages/haskell.scm
> @@ -8073,4 +8073,31 @@ It features a complete, well-tested parser and pretty 
> printer for all of C99
>  and a large set of GNU extensions.")
>  (license license:bsd-3)))
>  
> +(define-public ghc-markdown-unlit
> +  (package
> +   (name "ghc-markdown-unlit")
> +   (version "0.4.0")
> +   (source (origin
> + (method url-fetch)
> + (uri (string-append 
> "https://hackage.haskell.org/package/markdown-unlit/;
> + "markdown-unlit-" version ".tar.gz"))
> + (sha256
> +   (base32
> + "1kj2bffl7ndd8ygwwa3r1mbpwbxbfhyfgnbla8k8g9i6ffp0qrbw"
> +   (build-system haskell-build-system)
> +   (inputs
> +`(("ghc-base-compat" ,ghc-base-compat)
> +  ("ghc-hspec" ,ghc-hspec)
> +  ("ghc-quickcheck" ,ghc-quickcheck)
> +  ("ghc-silently" ,ghc-silently)
> +  ("ghc-stringbuilder" ,ghc-stringbuilder)
> +  ("ghc-temporary" ,ghc-temporary)))
> +   (native-inputs
> +`(("hspec-discover" ,hspec-discover)))

I noticed this was referenced by the binary and library for some reason,
so I made hspec-discover a regular input. It would be good to figure out
why it's referenced as it doesn't seem like it should be needed.

Pushed with indentation fixes! :-)


signature.asc
Description: PGP signature

Re: [PATCH 0/5] Clean-up of /bin/sh patching

[Marius Bakke]

Leo Famulari  writes:

> This patch series changes all the instances of /bin/sh being patched to
> /bin/bash that I can find.
>
> They are for core-updates.

[...]

> Leo Famulari (5):
>   gnu: m4: Don't replace 'sh' reference with 'bash'.
>   gnu: gnu-make: Don't replace 'sh' reference with 'bash'.
>   gnu: glibc/linux: Don't replace 'sh' reference with 'bash'.
>   gnu: glibc/linux: Use /bin/sh instead of /bin/bash as the default
> shell.
>   gnu: gawk: Don't replace 'sh' reference with 'bash'.

Thanks! I've verified all of these and they LGTM. Good catch on the make
and glibc paths.h substitutions.


signature.asc
Description: PGP signature

Re: [PATCH 1/1] gnu: unrtf: Fix CVE-2016-10091.

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Wed, Jan 04, 2017 at 02:13:25AM -0500, Leo Famulari wrote:
>> On Tue, Jan 03, 2017 at 05:49:29PM +0100, Marius Bakke wrote:
>> > Leo Famulari <l...@famulari.name> writes:
>> > > +diff --git a/debian/patches/series b/debian/patches/series
>> > > +new file mode 100644
>> > > +index 000..7868249
>> > > +--- /dev/null
>> > >  b/debian/patches/series
>> > > +@@ -0,0 +1 @@
>> > > ++0001-Replace-all-instances-of-sprintf-with-snprintf-and-a.patch
>> > 
>> > This part we surely don't need ;-)
>> 
>> Oops!
>
> x2
>
> Of course, the patch I sent on January 1 was completely broken.
>
> The patch it included from Debian was meant to be applied to the Debian
> package tree, not the UnRTF source code.

OK! Thanks for the update, LGTM!

Thanks for keeping up with this. I'm currently travelling, but should
return to normal within a few days/week :-)


signature.asc
Description: PGP signature

[PATCH] gnu: sed: Update to 4.3.

[Marius Bakke]

* gnu/packages/base.scm (sed): Update to 4.3.
[source]: Use xz tarball. Remove upstreamed patch.
[home-page]: Use https.
[native-inputs]: Add perl.
* gnu/packages/patches/sed-hurd-path-max.patch: Delete file.
* gnu/local.mk (dist_patch_DATA): Remove it.
---
 gnu/local.mk |  1 -
 gnu/packages/base.scm| 11 +
 gnu/packages/patches/sed-hurd-path-max.patch | 34 
 3 files changed, 6 insertions(+), 40 deletions(-)
 delete mode 100644 gnu/packages/patches/sed-hurd-path-max.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 860d16d91..e6528e96f 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -841,7 +841,6 @@ dist_patch_DATA =   
\
   %D%/packages/patches/ruby-rack-ignore-failing-test.patch  \
   %D%/packages/patches/ruby-tzinfo-data-ignore-broken-test.patch\
   %D%/packages/patches/ruby-yard-fix-skip-of-markdown-tests.patch \
-  %D%/packages/patches/sed-hurd-path-max.patch \
   %D%/packages/patches/scheme48-tests.patch\
   %D%/packages/patches/scotch-test-threading.patch \
   %D%/packages/patches/sdl-libx11-1.6.patch\
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index cfc1a6591..a1172037b 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -118,15 +118,14 @@ including, for example, recursive directory searching.")
 (define-public sed
   (package
(name "sed")
-   (version "4.2.2")
+   (version "4.3")
(source (origin
 (method url-fetch)
 (uri (string-append "mirror://gnu/sed/sed-" version
-".tar.bz2"))
+".tar.xz"))
 (sha256
  (base32
-  "1myvrmh99jsvk7v3d7crm0gcrq51hmmm1r2kjyyci152in1x2j7h"))
-(patches (search-patches "sed-hurd-path-max.patch"
+  "1anhdgah8h423hlmn9hwzxzr7hjbqjm6hxq3z1p7p7nf8640vhj7"
(build-system gnu-build-system)
(synopsis "Stream editor")
(arguments
@@ -143,6 +142,8 @@ including, for example, recursive directory searching.")
 (("/bin/sh")
  (string-append bash "/bin/bash")))
   #t)))
+   (native-inputs
+`(("perl" ,perl))) ; for help2man
(description
 "Sed is a non-interactive, text stream editor.  It receives a text
 input from a file or from standard input and it then applies a series of text
@@ -150,7 +151,7 @@ editing commands to the stream and prints its output to 
standard output.  It
 is often used for substituting text patterns in a stream.  The GNU
 implementation offers several extensions over the standard utility.")
(license gpl3+)
-   (home-page "http://www.gnu.org/software/sed/;)))
+   (home-page "https://www.gnu.org/software/sed/;)))
 
 (define-public tar
   (package
diff --git a/gnu/packages/patches/sed-hurd-path-max.patch 
b/gnu/packages/patches/sed-hurd-path-max.patch
deleted file mode 100644
index 5226cba4c..0
--- a/gnu/packages/patches/sed-hurd-path-max.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-7bb8d35d0330161a5af5341471d0c183a067e8c2
-Author: Jose E. Marchesi 
-Date:   Sun Oct 6 14:43:38 2013 +0200
-
-Set PATH_MAX to some constant in case it is not defined in system
-headers.
-
-2013-10-06  Jose E. Marchesi  
-
-   * basicdefs.h (PATH_MAX): Defined to some constant in case it is
-   not defined by system headers.
-   * sed/utils.c: Do not include pathmax.h anymore.
-   * bootstrap.conf (gnulib_modules): Do not use the gnulib module
-   pathmax.
-
-diff --git a/basicdefs.h b/basicdefs.h
-index 0d28a97..09f5beb 100644
 a/basicdefs.h
-+++ b/basicdefs.h
-@@ -40,6 +41,13 @@ typedef unsigned long countT;
- #define obstack_chunk_alloc  ck_malloc
- #define obstack_chunk_free   free
- 
-+/* MAX_PATH is not defined in some platforms, most notably GNU/Hurd.
-+   In that case we define it here to some constant.  Note however that
-+   this relies in the fact that sed does reallocation if a buffer
-+   needs to be larger than PATH_MAX.  */
-+#ifndef PATH_MAX
-+# define PATH_MAX 200
-+#endif
- 
- /* handle misdesigned  macros (snarfed from lib/regex.c) */
- /* Jim Meyering writes:
- 
-- 
2.11.0

Re: [PATCH] gnu: curl: Add ca-bundle to config.

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> ng0 <n...@libertad.pw> writes:
>
>> * gnu/packages/curl.scm (curl)[arguments]: Add "--with-ca-bundle" configure 
>> flag.
>> [arguments]: Disable failing test number 324.
>> ---
>>  gnu/packages/curl.scm | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/gnu/packages/curl.scm b/gnu/packages/curl.scm
>> index 7329d870d..3473055b8 100644
>> --- a/gnu/packages/curl.scm
>> +++ b/gnu/packages/curl.scm
>> @@ -4,6 +4,7 @@
>>  ;;; Copyright © 2015 Tomáš Čech <sleep_wal...@suse.cz>
>>  ;;; Copyright © 2015 Ludovic Courtès <l...@gnu.org>
>>  ;;; Copyright © 2016 Leo Famulari <l...@famulari.name>
>> +;;; Copyright © 2017 ng0 <n...@libertad.pw>
>>  ;;;
>>  ;;; This file is part of GNU Guix.
>>  ;;;
>> @@ -65,7 +66,8 @@
>> ("pkg-config" ,pkg-config)
>> ("python" ,python-2)))
>> (arguments
>> -`(#:configure-flags '("--with-gnutls" "--with-gssapi")
>> +`(#:configure-flags '("--with-gnutls" "--with-gssapi"
>> +  
>> "--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt")
>
> This may not work on all distros, and is "impure" since this path is not
> managed by Guix. If we are doing this, it should be referring to
> (string-append (assoc-ref %build-inputs "nss-certs") "/etc/ssl/...").
> That will likely fix the test as well.

I realized shortly after posting why this wasn't done already. Curl has
1403 dependent packages, which would apply for "nss-certs" as well if
that is added as input. Obviously we want to be able to update TLS
certificates quickly without rebuilding ~1/4 of the tree.

Perhaps it could be added as a separate package, or by e.g. renaming the
current curl package to "curl-minimal".


signature.asc
Description: PGP signature

Re: [PATCH] gnu: curl: Add ca-bundle to config.

[Marius Bakke]

ng0  writes:

> * gnu/packages/curl.scm (curl)[arguments]: Add "--with-ca-bundle" configure 
> flag.
> [arguments]: Disable failing test number 324.
> ---
>  gnu/packages/curl.scm | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/curl.scm b/gnu/packages/curl.scm
> index 7329d870d..3473055b8 100644
> --- a/gnu/packages/curl.scm
> +++ b/gnu/packages/curl.scm
> @@ -4,6 +4,7 @@
>  ;;; Copyright © 2015 Tomáš Čech 
>  ;;; Copyright © 2015 Ludovic Courtès 
>  ;;; Copyright © 2016 Leo Famulari 
> +;;; Copyright © 2017 ng0 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -65,7 +66,8 @@
> ("pkg-config" ,pkg-config)
> ("python" ,python-2)))
> (arguments
> -`(#:configure-flags '("--with-gnutls" "--with-gssapi")
> +`(#:configure-flags '("--with-gnutls" "--with-gssapi"
> +  
> "--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt")

This may not work on all distros, and is "impure" since this path is not
managed by Guix. If we are doing this, it should be referring to
(string-append (assoc-ref %build-inputs "nss-certs") "/etc/ssl/...").
That will likely fix the test as well.


signature.asc
Description: PGP signature

Re: GnuTLS and the “trust store”

[Marius Bakke]

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

> Hello!
>
> Marius Bakke <mba...@fastmail.com> skribis:
>
>> Marius Bakke <mba...@fastmail.com> writes:
>>
>>> ng0 <n...@libertad.pw> writes:
>>>
>>>> * gnu/packages/curl.scm (curl)[arguments]: Add "--with-ca-bundle" 
>>>> configure flag.
>
> [...]
>
>> I realized shortly after posting why this wasn't done already. Curl has
>> 1403 dependent packages, which would apply for "nss-certs" as well if
>> that is added as input. Obviously we want to be able to update TLS
>> certificates quickly without rebuilding ~1/4 of the tree.
>
> Indeed.  It’s a situation where we do not want to have a static binding
> between cURL and nss-certs; instead, they should be composed
> dynamically, along the lines of what we already recommend at:
>
>   
> https://www.gnu.org/software/guix/manual/html_node/X_002e509-Certificates.html

Curl respects the variable "CURL_CA_BUNDLE". I think we could add a
"native-search-path" for that, similar to how it's done for "git".

ng0, can you try that?


signature.asc
Description: PGP signature

Re: [PATCH v4 1/1] gnu: python-sphinx: Update to 1.4.8.

[Marius Bakke]

Danny Milosavljevic  writes:

> * gnu/packages/python.scm (python-sphinx)[version]: Update to 1.4.8.

Please also mention changes to inputs, source and other fields in the
commit message.


signature.asc
Description: PGP signature

Re: Ruby 2.4.0 update

[Marius Bakke]

Ben Woodcroft <b.woodcr...@uq.edu.au> writes:

> Hi Marius,
>
> On 26/12/16 23:18, Ben Woodcroft wrote:
>> On 26/12/16 03:09, Marius Bakke wrote:
>>> In good tradition, ruby made a new release today (25/12)[0].
>>>
>>> I tried building some packages with the new version, but ruby-minitest
>>> complains that Rake 12 is too new (even with the latest minitest). There
>>> have been some core changes as well, with Fixnum and Bignum now merged
>>> into a single Integer class.
>> I updated ruby-minitest to the newest version and pushed, but as you 
>> mention the check phase requires rake <12. This actually stems from 
>> hoe though rather than minitest, I've asked the devs about it here:
>> https://github.com/seattlerb/hoe/issues/77
> This issue has now been fixed in hoe, in the just released 3.16.0. I 
> just pushed this to master after building the downstream packages 
> without issue as '8e941f20',.

Cool, thanks!

>>> I suggest that we keep ruby 2.3 as the main "ruby" variable until the
>>> ecosystem catches up. Users will still get the latest version when
>>> using `guix package` or `guix environment`. WDYT?
>> I would agree, but I'd hope that the hoe issue is an isolated one and 
>> that we can make ruby-2.4 the default very soon.
>   What do you think about making 2.4 the default and pushing to staging, 
> if there are no obvious issues?

Sounds good for the next staging cycle :-)


signature.asc
Description: PGP signature

Re: [PATCH] guix: python-build-system: Properly inform caller about test status.

[Marius Bakke]

Danny Milosavljevic  writes:

> * guix/build/python-build-system.scm (check): Properly inform caller about 
> test status.
> ---
>  guix/build/python-build-system.scm | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/guix/build/python-build-system.scm 
> b/guix/build/python-build-system.scm
> index 3f280b0ac..d46739827 100644
> --- a/guix/build/python-build-system.scm
> +++ b/guix/build/python-build-system.scm
> @@ -136,12 +136,13 @@
>;; build/lib in some cases, e.g. if the source is in a sub-directory
>;; (given with `package_dir`). This will by copied to the output, too,
>;; so we need to remove.
> -  (let ((before (find-files "build" "\\.egg-info$" #:directories? #t)))
> -(call-setuppy test-target '() use-setuptools?)
> -(let* ((after (find-files "build" "\\.egg-info$" #:directories? #t))
> -   (inter (lset-difference eqv? after before)))
> -  (for-each delete-file-recursively inter)))
> -#t))
> +  (let* ((before (find-files "build" "\\.egg-info$" #:directories? #t))
> + (status (call-setuppy test-target '() use-setuptools?))
> + (after (find-files "build" "\\.egg-info$" #:directories? #t))
> + (inter (lset-difference eqv? after before)))
> +(for-each delete-file-recursively inter)
> +status)
> +  #t))

This is fixed with e46a043ecd9f9ef46d1d44393362bb7016454544 from the
'python-tests' branch. Speaking of which, there are still some failing
packages in that branch listed at:
https://hydra.gnu.org/eval/109407?compare=master#tabs-now-fail

I'll try to take care of the remaining failures in the next week so we
can merge this branch. Contributions are always welcome however ;-)



signature.asc
Description: PGP signature

Re: [PATCH 1/2] gnu: libtool: Use 'modify-phases'.

[Marius Bakke]

Leo Famulari  writes:

> On Sun, Jan 01, 2017 at 03:24:27PM +, ng0 wrote:
>> * gnu/packages/autotools.scm (libtool): Use 'modify-phases'.
>> [arguments]: Use 'modify-phases'.
>
>> + ("help2man" ,help2man) ;because we modify ltmain.sh
>
> This should go in the other patch, right?
>
> I attached a revised patch series with that change, and another bug fix.
> From 7f0fce3f71be7da461de89fb5f6f47289c6498b6 Mon Sep 17 00:00:00 2001
> From: ng0 
> Date: Sun, 1 Jan 2017 15:24:27 +
> Subject: [PATCH 1/3] gnu: libtool: Use 'modify-phases'.
>
> * gnu/packages/autotools.scm (libtool): Use 'modify-phases'.
> [arguments]: Use 'modify-phases'.
>
> Signed-off-by: Leo Famulari 
> ---
>  gnu/packages/autotools.scm | 30 --
>  1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/gnu/packages/autotools.scm b/gnu/packages/autotools.scm
> index 72492e70e..64a1e68bf 100644
> --- a/gnu/packages/autotools.scm
> +++ b/gnu/packages/autotools.scm
> @@ -5,6 +5,7 @@
>  ;;; Copyright © 2014 Manolis Fragkiskos Ragkousis 
>  ;;; Copyright © 2015 Mark H Weaver 
>  ;;; Copyright © 2016 David Thompson 
> +;;; Copyright © 2017 ng0 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -313,21 +314,22 @@ Makefile, simplifying the entire process for the 
> developer.")
>(or (%current-target-system)
>(%current-system
>  
> -   #:phases (alist-cons-before
> - 'check 'pre-check
> - (lambda* (#:key inputs #:allow-other-keys)
> -   ;; Run the test suite in parallel, if possible.
> -   (setenv "TESTSUITEFLAGS"
> -   (string-append
> -"-j"
> -(number->string (parallel-job-count
> +   #:phases
> +   (modify-phases %standard-phases
> + (add-before 'check 'pre-check
> + (lambda* (#:key inputs #:allow-other-keys)
> +   ;; Run the test suite in parallel, if possible.
> +   (setenv "TESTSUITEFLAGS"
> +   (string-append
> +"-j"
> +(number->string (parallel-job-count
> +
> +   ;; Path references to /bin/sh.
> +   (let ((bash (assoc-ref inputs "bash")))
> + (substitute* "tests/testsuite"
> +   (("/bin/sh")
> +(string-append bash "/bin/bash")

There was a discussion about making "substitute*" return #t if one or
more substitutions were done, is that implemented yet? If not, please
make sure phases end on a truthy value :-)


signature.asc
Description: PGP signature

Re: [PATCH] gnu: sed: Update to 4.3.

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Wed, Jan 04, 2017 at 05:01:34PM +0100, Marius Bakke wrote:
>> * gnu/packages/base.scm (sed): Update to 4.3.
>> [source]: Use xz tarball. Remove upstreamed patch.
>> [home-page]: Use https.
>> [native-inputs]: Add perl.
>> * gnu/packages/patches/sed-hurd-path-max.patch: Delete file.
>> * gnu/local.mk (dist_patch_DATA): Remove it.
>
> Thanks!
>
> We should make sure that the built package doesn't retain a reference to
> Perl.

Thanks for checking (in the other email!) :-)

> It's interesting that `guix refresh -l sed` doesn't show the full impact
> of this change:
>
> $ guix refresh -l sed
> Building the following 4 packages would ensure 4 dependent packages are 
> rebuilt: password-store-1.6.5 hydra-20151030.1ff48da bamm-1.7.3 roary-3.7.0
>
> Also, this part of the package definition is incorrect:
>
> (substitute* '("testsuite/bsd.sh"
>"testsuite/bug-regex9.c")
>   (("/bin/sh")
>(string-append bash "/bin/bash")))
> #t)))
>
> Bash and sh behave differently; the replacement string should refer to
> '/bin/sh'.

Good catch! I fixed this too and pushed to 'core-updates' as
7d7ea947f56e5080c9913f311ede71475045b9d6 .


signature.asc
Description: PGP signature

Re: [PATCH v2] gnu: Add ghc-markdown-unlit.

[Marius Bakke]

Danny Milosavljevic  writes:

> * gnu/packages/haskell.scm (ghc-markdown-unlit): New variable.
> ---
>  gnu/packages/haskell.scm | 29 +
>  1 file changed, 29 insertions(+)
>
> diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
> index de061a630..1f6611d0b 100644
> --- a/gnu/packages/haskell.scm
> +++ b/gnu/packages/haskell.scm
> @@ -8073,4 +8073,33 @@ It features a complete, well-tested parser and pretty 
> printer for all of C99
>  and a large set of GNU extensions.")
>  (license license:bsd-3)))
>  
> +(define-public ghc-markdown-unlit
> +  (package
> +   (name "ghc-markdown-unlit")
> +   (version "0.4.0")
> +   (source (origin
> + (method url-fetch)
> + (uri (string-append
> +"https://hackage.haskell.org/package/markdown-unlit/;
> +"markdown-unlit-" version ".tar.gz"))
> + (sha256
> +   (base32
> + "1kj2bffl7ndd8ygwwa3r1mbpwbxbfhyfgnbla8k8g9i6ffp0qrbw"
> +   (build-system haskell-build-system)
> +   (inputs
> +`(("ghc-base-compat" ,ghc-base-compat)
> +  ("ghc-hspec" ,ghc-hspec)
> +  ("ghc-quickcheck" ,ghc-quickcheck)
> +  ("ghc-silently" ,ghc-silently)
> +  ("ghc-stringbuilder" ,ghc-stringbuilder)
> +  ("ghc-temporary" ,ghc-temporary)))
> +   (native-inputs
> +`(("hspec-discover" ,hspec-discover)))
> +   (home-page "https://github.com/sol/markdown-unlit#readme;)
> +   (synopsis "Literate Haskell support for Markdown")
> +   (description "This package allows you to have a README.md that at the
> +same time is a literate Haskell program.  See also $url{Documentation,
> +https://github.com/sol/markdown-unlit#readme}.;)

I don't think linking the home page in the description is necessary.
What do you think about removing the last sentence? Otherwise LGTM with
a few indentation changes that can be fixed before pushing ;-)

As a side note, do we have volunteers to make the hackage importer
return a "mirror://hackage" uri? IIRC this is needed for pypi too.


signature.asc
Description: PGP signature

Re: python-tests: Sphinx

[Marius Bakke]

Danny Milosavljevic  writes:

> Hi Marius,
>
>> This is fixed with e46a043ecd9f9ef46d1d44393362bb7016454544 from the
>> 'python-tests' branch. Speaking of which, there are still some failing
>> packages in that branch listed at:
>> https://hydra.gnu.org/eval/109407?compare=master#tabs-now-fail
>> 
>> I'll try to take care of the remaining failures in the next week so we
>> can merge this branch. Contributions are always welcome however ;-)
>
> Can we update Sphinx in the python-tests branch please? Then some more things 
> will fail...

Right, I will add them when I get time to work on it in a few days.
Could you make sure they apply, and send an updated patchset with commit
message fixes? TIA!


signature.asc
Description: PGP signature

Re: [PATCH 0/1] MPD: Install systemd service files

[Marius Bakke]

Leo Famulari  writes:

> I noticed that MPD 0.19.21 adds a systemd service file for unprivileged
> users:
>
> http://git.musicpd.org/cgit/master/mpd.git/plain/NEWS?h=v0.19.21
>
> It works for me! 
>
> This patch installs both the privileged and unprivileged service files.
>
> I wonder, is this installation path correct? Should they be at
>
> ~/.guix-profile/etc/systemd[...] (my patch does this)

Yes. Unit names in managed packages should not conflict, so no further
namespacing necessary. This way users can just sync/link units from
/etc/systemd/{user,system} to the respective system
locations.

Btw, Shepherd works in user mode too ;-)

Here is a config that defines a service for "mcron":

$ cat ~/.config/shepherd/init.scm
(define mcron (make 
#:provides '(mcron)
#:start (make-forkexec-constructor
 (list "/run/current-system/profile/bin/mcron"))
#:stop (make-kill-destructor)))
(register-services mcron)

I guess it would be better to re-use the Guix service definition, but
haven't gotten that far yet.


signature.asc
Description: PGP signature

Re: [PATCH 1/2] gnu: libpng: Fix a null pointer dereference [fixes security issue].

[Marius Bakke]

Leo Famulari  writes:

> * gnu/packages/patches/libpng-fix-null-ptr-dereference.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/image.scm (libpng)[replacement]: New field.
> (libpng/fixed): New variable.

That was quick! Both patches LGTM.


signature.asc
Description: PGP signature

Re: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.

[Marius Bakke]

Danny Milosavljevic  writes:

> * gnu/packages/python.scm (python-sphinx)[version]: Update to 1.4.8.
>   [source]: Use pypi-uri.
>   [propagated-inputs]: Add python-imagesize, python-sphinx-alabaster-theme,
>   python-babel, python-snowballstemmer, python-six.
>   [properties]: Add python2-variant.
> (python2-sphinx)[native-inputs]: Add python2-mock.
>   [propagated-inputs]: Add python2-pytz.

LGTM, thanks! As per the prior discussion, it should be applied in the
'python-tests' branch. Since it requires some packages only present in
'master', it will have to wait until the remaining failures are fixed.

Then we can merge master, add this patch and start a new evaluation.


signature.asc
Description: PGP signature

Re: [PATCH 6/6] gnu: Add grub-efi.

[Marius Bakke]

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

> Marius Bakke <mba...@fastmail.com> skribis:
>
>> Ludovic Courtès <l...@gnu.org> writes:
>>
>>> Hello!
>>>
>>> Marius Bakke <mba...@fastmail.com> skribis:
>>>
>>>>>> OK. I'll try to find out why tests don't work with the UEFI variant
>>>>>> first in order to at least write a meaningful comment. Maybe qemu needs
>>>>>> UEFI support or something like that.
>>>>>
>>>>> It might be that we no longer need QEMU 1.3.1 to run the tests (see the
>>>>> top of gnu/packages/grub.scm)?
>>>>
>>>> The problem is missing UEFI firmware for the qemu calls. But we indeed
>>>> no longer need qemu@1.3.1 for the tests, at least on x86_64. I replaced
>>>> it with 'qemu-minimal'. Pushed!
>>>
>>> Great!
>>>
>>> I’m failing at installing GuixSD on a new laptop I have here.
>>> ‘efibootmgr’ exits with code 2 and this message:
>>>
>>>   EFI variables are not supported on this system.
>>>
>>> (which ‘grub-install’ happily ignores.)
>>>
>>> This is because /sys/firmware/efi is missing, which apparently is
>>> because I booted off the GuixSD USB image (“legacy”) and not in EFI
>>> mode.
>>>
>>> What would you suggest?  :-)
>>
>> What I did was a normal BIOS install, backup the grub.cfg, switch laptop
>> to UEFI (only) and boot a Debian live CD. From there "apt-get install
>> grub-efi; grub-install /dev/sda" and afterwards copy grub.cfg in place.
>>
>> You may want to add "insmod efi_gop" and "insmod efi_uga" to grub.cfg,
>> otherwise you won't get a framebuffer until the proper video driver is
>> loaded (which may require unlocking root partition etc).
>
> Wait, all I need is /sys/firmware/efi in the install image.  Is it
> impossible?

Perhaps you can trick Linux into creating it without booting UEFI mode.
Not sure if grub/efibootmgr actually need to read or write there.

>> Not the most user friendly installation instructions! I'm researching
>> methods to make the base install image hybrid BIOS/UEFI.
>
> What would it take?

The scripts I've looked at so far seems to use ISOLINUX as the initial
bootloader and then chainload to grub. Didn't experiment much, haven't
been able to get syslinux packaged yet.

It's *probably* possible do it with grub only, by partitioning the
installation image and create both a "bios_grub" GPT partition and an
EFI system partition and install to both with a different --target.


signature.asc
Description: PGP signature

Re: [PATCH 6/6] gnu: Add grub-efi.

[Marius Bakke]

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

> Hi Marius,
>
> Marius Bakke <mba...@fastmail.com> skribis:
>
>> Ludovic Courtès <l...@gnu.org> writes:
>>
>>>> Relatedly, I think the way to build a 'multi-grub' is to have one
>>>> expression for each supported grub platform, and then consolidate
>>>> out/lib/grub from each.
>>>
>>> So in essence, GRUB itself supports only one platform at a time?
>>
>> AFAICT yes. Gentoo works around this by running the build for each
>> user-specified platform and combining the outputs. Most other distros
>> just carry separate grub-pc and grub-efi packages.
>>
>>>>> Now there are things I didn’t quite get.  Apparently you’re supposed to
>>>>> have a /boot/efi as a vfat partition, and ‘grub-install’ is supposed to
>>>>> detect it and install the EFI stuff, or so I thought (info "(grub)
>>>>> Installing GRUB using grub-install").
>>>>>
>>>>> However, ‘grub-install’ still seems to be installing for “i386-pc”
>>>>> instead of EFI.
>>>>>
>>>>> What am I missing?
>>>>
>>>> IIRC grub-install will detect and install for the running mode (pc, efi,
>>>> etc). So in a classic chicken-and-egg situation, you need to be booted
>>>> with UEFI mode for grub to select the correct installation platform!
>>>
>>> My understanding is that it would install for UEFI if it fines
>>> /boot/efi or if --efi-directory is passed.
>>
>> I'm not so sure, but it's been a while since I played around with this.
>> At least building the 'gnu/system/install.scm' image works fine when
>> passing --efi-directory (see the bottom two patches from
>> https://lists.gnu.org/archive/html/guix-devel/2016-12/txtchTym4QVKr.txt ),
>> and I think it would choose i386-pc even if x86_64-efi was available
>> since the VM boots in BIOS mode.
>>
>> Tangentially, I'm not aware of any way to build a "hybrid" ISO image
>> using only grub. I've started work on packaging syslinux/isolinux which
>> is what Debian uses for their hybrid UEFI/BIOS install image.
>
> OK.
>
> Having checked GRUB’s configure.ac etc., I realize that my suggestion of
> having one ‘grub’ package doing both EFI and “PC” cannot work.  What you
> suggested initially (a separate ‘grub-efi’ package) is the only thing we
> can do (we could perhaps merge the lib/grub directories as you
> suggested, but it’s not even clear that this would work.)
>
> Thus, I think we need to revert 3eee16130d858ae96510ec1c7d38d31290de2699
> and install your initial ‘grub-efi’ patch.  How does that sound?

OK. I'll try to find out why tests don't work with the UEFI variant
first in order to at least write a meaningful comment. Maybe qemu needs
UEFI support or something like that.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: maxima: Update to 5.39.0.

[Marius Bakke]

Kei Kebreau  writes:

>> I've found 'diffoscope' to be useful when troubleshooting
>> reproducibility problems. E.g. by running it on two cancelled builds, or
>> by installing to different output paths with a superficial change to the
>> expression. It will show sections that differs which may aid locating
>> the offending code.
>>
>
> Yes. I see that diffoscope complains about missing 'xxd'. That may be
> useful to package (unless we already have it and I'm just oblivious).

'xxd' is distributed with the 'vim' package. Is the error fatal? Perhaps
we should patch diffoscope with the absolute path to xxd.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: maxima: Update to 5.39.0.

[Marius Bakke]

Kei Kebreau  writes:

> This was supposed to be a simple version bump for Maxima, but it has
> come to my attention that Maxima hasn't built reproducibily for quite a
> while now (since version 5.36.1 according to my tests, possibly
> further). Is there any particular reason why? I can't seem to pinpoint
> the cause.

The patch looks good. Are you sure it was reproducible before?

I've found 'diffoscope' to be useful when troubleshooting
reproducibility problems. E.g. by running it on two cancelled builds, or
by installing to different output paths with a superficial change to the
expression. It will show sections that differs which may aid locating
the offending code.

For C family programs, a "hail mary" grep for __DATE__ or __TIME__ can
be enough. Tobias suggested making those return a fixed value, which I
think could be worthwhile, at least for the build environment.


signature.asc
Description: PGP signature

Re: [PATCH 6/6] gnu: Add grub-efi.

[Marius Bakke]

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

> Hello!
>
> Marius Bakke <mba...@fastmail.com> skribis:
>
>>>> OK. I'll try to find out why tests don't work with the UEFI variant
>>>> first in order to at least write a meaningful comment. Maybe qemu needs
>>>> UEFI support or something like that.
>>>
>>> It might be that we no longer need QEMU 1.3.1 to run the tests (see the
>>> top of gnu/packages/grub.scm)?
>>
>> The problem is missing UEFI firmware for the qemu calls. But we indeed
>> no longer need qemu@1.3.1 for the tests, at least on x86_64. I replaced
>> it with 'qemu-minimal'. Pushed!
>
> Great!
>
> I’m failing at installing GuixSD on a new laptop I have here.
> ‘efibootmgr’ exits with code 2 and this message:
>
>   EFI variables are not supported on this system.
>
> (which ‘grub-install’ happily ignores.)
>
> This is because /sys/firmware/efi is missing, which apparently is
> because I booted off the GuixSD USB image (“legacy”) and not in EFI
> mode.
>
> What would you suggest?  :-)

What I did was a normal BIOS install, backup the grub.cfg, switch laptop
to UEFI (only) and boot a Debian live CD. From there "apt-get install
grub-efi; grub-install /dev/sda" and afterwards copy grub.cfg in place.

You may want to add "insmod efi_gop" and "insmod efi_uga" to grub.cfg,
otherwise you won't get a framebuffer until the proper video driver is
loaded (which may require unlocking root partition etc).

Not the most user friendly installation instructions! I'm researching
methods to make the base install image hybrid BIOS/UEFI.

Once booted, you should apply the following two patches when
reconfiguring the system. I think they are safe for BIOS systems too,
but haven't done extensive testing.



signature.asc
Description: PGP signature
>From fa12cd92a2e4eead22f640d6231813e50b8191bf Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Sun, 6 Nov 2016 17:26:06 +
Subject: [PATCH 1/2] build: Make grub-install command UEFI aware.

* gnu/build/install.scm (install-grub): Extend grub-install command with
'--bootloader-id' and '--efi-directory'.
---
 gnu/build/install.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gnu/build/install.scm b/gnu/build/install.scm
index 5c2b35632..ddd95bbf6 100644
--- a/gnu/build/install.scm
+++ b/gnu/build/install.scm
@@ -54,6 +54,9 @@ GC'd."
   (unless (zero? (system* "grub-install" "--no-floppy"
   "--boot-directory"
   (string-append mount-point "/boot")
+			  "--bootloader-id=GNU"
+			  "--efi-directory"
+  (string-append mount-point "/boot")
   device))
 (error "failed to install GRUB")))
 
-- 
2.11.0

>From dd71d9b334ceccc09cd42484c6deac2079c44c70 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Mon, 7 Nov 2016 12:24:01 +
Subject: [PATCH 2/2] system: Load efi modules in grub.cfg.

* gnu/system/grub.scm (eye-candy): Load 'efi_gop' and 'efi_uga' grub modules.
---
 gnu/system/grub.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/system/grub.scm b/gnu/system/grub.scm
index 4657b06b5..9477b2494 100644
--- a/gnu/system/grub.scm
+++ b/gnu/system/grub.scm
@@ -183,6 +183,8 @@ system string---e.g., \"x86_64-linux\"."
 (if (string-match "^(x86_64|i[3-6]86)-" system)
 "
   # Leave 'gfxmode' to 'auto'.
+  insmod efi_gop
+  insmod efi_uga
   insmod vbe
   insmod vga
   insmod video_bochs
-- 
2.11.0

Re: 01/01: gnu: curl: Update replacement to 7.52.0 [fixes CVE-2016-{9586, 9952, 9953}].

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Wed, Dec 21, 2016 at 02:03:21PM +0000, Marius Bakke wrote:
>> mbakke pushed a commit to branch master
>> in repository guix.
>> 
>> commit 42366b35c3f9f8dc8b059d3369b8196a4b832c18
>> Author: Marius Bakke <mba...@fastmail.com>
>> Date:   Wed Dec 21 14:56:34 2016 +0100
>> 
>> gnu: curl: Update replacement to 7.52.0 [fixes 
>> CVE-2016-{9586,9952,9953}].
>> 
>> * gnu/packages/curl.scm (curl)[replacement]: Update to 7.52.0.
>> (curl-7.51.0): Replace with ...
>> (curl-7.52.0): ... this.
>
> ng0 pointed out this message from the curl maintainers:
>
> "Attention! We will release a patch update within a few days to fix a
> serious security problem found in curl 7.52.0. You may consider holding
> off until then."
>
> https://curl.haxx.se/download.html

Thanks for catching that! I think that message must have appeared after
I downloaded it from there, difficult to miss that notice.

The page was updated about 25 minutes after the commit was pushed:
$ curl -v https://curl.haxx.se/download.html >/dev/null
[...]
< Last-Modified: Wed, 21 Dec 2016 14:28:41 GMT

It was reverted around 16:52 UTC. I hope those who upgraded in between
those five hours reads this list!


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add toxic.

[Marius Bakke]

Kei Kebreau  writes:

> ng0  writes:
>
>> * gnu/packages/messaging.scm (toxic): New variable.
>> ---
>>  gnu/packages/messaging.scm | 47 
>> ++
>>  1 file changed, 47 insertions(+)
>>
>> diff --git a/gnu/packages/messaging.scm b/gnu/packages/messaging.scm
>> index 4290a9f69..24728cc06 100644
>> --- a/gnu/packages/messaging.scm
>> +++ b/gnu/packages/messaging.scm
>> @@ -40,6 +40,7 @@
>>#:use-module (gnu packages autotools)
>>#:use-module (gnu packages avahi)
>>#:use-module (gnu packages check)
>> +  #:use-module (gnu packages curl)
>>#:use-module (gnu packages crypto)
>>#:use-module (gnu packages cyrus-sasl)
>>#:use-module (gnu packages databases)
>> @@ -70,12 +71,14 @@
>>#:use-module (gnu packages linux)
>>#:use-module (gnu packages tls)
>>#:use-module (gnu packages icu4c)
>> +  #:use-module (gnu packages image)
>>#:use-module (gnu packages qt)
>>#:use-module (gnu packages video)
>>#:use-module (gnu packages web)
>>#:use-module (gnu packages xiph)
>>#:use-module (gnu packages audio)
>>#:use-module (gnu packages bison)
>> +  #:use-module (gnu packages textutils)
>>#:use-module (gnu packages fontutils))
>>  
>>  (define-public libotr
>> @@ -767,6 +770,50 @@ guidelines.  It provides an easy to use application 
>> that allows you to
>>  connect with friends and family without anyone else listening in.")
>>  (license license:gpl3+)))
>>  
>> +(define-public toxic
>> +  (package
>> +(name "toxic")
>> +(version "0.7.2")
>> +(source
>> + (origin
>> +   (method url-fetch)
>> +   (uri (string-append "https://github.com/JFreegman/toxic/archive/;
>> +   "v" version ".tar.gz"))
>> +   (sha256
>> +(base32
>> + "0nbcj71ffl85l396bxc5cs8d7abn4b7absaj5asq9bvcfv52m5m2"))
>> +   (file-name (string-append name "-" version ".tar.gz"
>> +(inputs
>> + `(("ncurses" ,ncurses)
>
> I'm not sure what's up here. IIRC, we don't install the ncurses *.pc
> files. If I'm wrong, someone please correct me.

I believe commit 57742b35dc0260ad8779438273e5f3d6e2c0 from
'core-updates' intends to solve this.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add python-hdf4.

[Marius Bakke]

Thomas Danckaert <p...@thomasdanckaert.be> writes:

> From: Marius Bakke <mba...@fastmail.com>
> Subject: Re: [PATCH] gnu: Add python-hdf4.
> Date: Thu, 22 Dec 2016 18:09:07 +0100
>
>> Thomas Danckaert <thomas.dancka...@gmail.com> writes:
>>
>>> Hi Guix,
>>>
>>> this patch adds python-hdf4.  I'm not sure if the line “Python-HDF4
>>> is a fork of pyhdf.” in the description is necessary.  The original
>>> and “official” pyhdf (http://hdfeos.org/software/pyhdf.php) is
>>> somewhat outdated (e.g. doesn't support python3).
>>
>> The "official" pyhdf and this fork was released around the same 
>> time and
>> have the same version number. Confusing! But I'll take your word 
>> that
>> this one is better.
>
> Yes, it seems it mirrors updates in the “official” one, and keeps the 
> same version numbers.

Thanks for clarifying.

>
>> Regarding the patch, I wonder if it should go in (gnu packages 
>> maths),
>> similar to how we put PDF libraries in pdf.scm and XML in xml.scm 
>> etc.
>> But no strong opinion here.
>
> I've wondered the same.  Right now, h5py, which is a similar package 
> for HDF5, is also in python.scm, so I decided to add this package 
> next to it.  As an aside, I find many packages in maths.scm are not 
> really “mathy” (“science” maybe), but anyway :-)

OK! :)

>> The 'check' phase seems to run the build again, and prints at the 
>> end
>> "Ran 0 tests in 0.000s". Looking at the Github ".travis.yml", the CI
>> tool runs the command "nosetests" instead of 'python setup.py test' 
>> like
>> python-build-system does by default. Can you try replacing the 
>> 'check'
>> phase with that command? You'll need 'python-nose' as a 
>> native-input.
>
> I hadn't noticed that. This patch adds nosetests, but that just 
> prints “Ran 0 tests in .005s”, so it seems there are no tests.  Shall 
> we just delete the 'check' phase?

Ha, it seems the one nosetest was added after the 0.9 release. But I
missed another script from the ".travis.yml" which runs through some
example scripts. I added that as well, and kept nose so that it "just
works" when this package is updated.

Applied!


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add wwwoffle.

[Marius Bakke]

Bake Timmons <65pan...@gmail.com> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
> < snip >
>
>> I can do these minor edits for you if you prefer, but would like to
>> confirm name and email for the copyright. Thanks!
>>
>
> Thanks for your review -- I wish I responded earlier!  Attached is a
> revised patch.

Thanks for the update. Applied! Nice work for a first package :-)


signature.asc
Description: PGP signature

Re: 01/01: gnu: curl: Update replacement to 7.52.0 [fixes CVE-2016-{9586, 9952, 9953}].

[Marius Bakke]

ng0 <n...@libertad.pw> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> Leo Famulari <l...@famulari.name> writes:
>>
>>> On Wed, Dec 21, 2016 at 02:03:21PM +, Marius Bakke wrote:
>>>> mbakke pushed a commit to branch master
>>>> in repository guix.
>>>> 
>>>> commit 42366b35c3f9f8dc8b059d3369b8196a4b832c18
>>>> Author: Marius Bakke <mba...@fastmail.com>
>>>> Date:   Wed Dec 21 14:56:34 2016 +0100
>>>> 
>>>> gnu: curl: Update replacement to 7.52.0 [fixes 
>>>> CVE-2016-{9586,9952,9953}].
>>>> 
>>>> * gnu/packages/curl.scm (curl)[replacement]: Update to 7.52.0.
>>>> (curl-7.51.0): Replace with ...
>>>> (curl-7.52.0): ... this.
>>>
>>> ng0 pointed out this message from the curl maintainers:
>>>
>>> "Attention! We will release a patch update within a few days to fix a
>>> serious security problem found in curl 7.52.0. You may consider holding
>>> off until then."
>>>
>>> https://curl.haxx.se/download.html
>>
>> Thanks for catching that! I think that message must have appeared after
>> I downloaded it from there, difficult to miss that notice.
>>
>> The page was updated about 25 minutes after the commit was pushed:
>> $ curl -v https://curl.haxx.se/download.html >/dev/null
>> [...]
>> < Last-Modified: Wed, 21 Dec 2016 14:28:41 GMT
>>
>> It was reverted around 16:52 UTC. I hope those who upgraded in between
>> those five hours reads this list!
>
> Today cURL 7.52.1 has been released, addressing the issue which
> was present only in 7.52.0: https://curl.haxx.se/docs/adv_20161223.html

Thanks for the heads-up, I've pushed the update.

I added the CVE identifier for the 7.52.0 bug in the commit log since we
had it for a short while, and removed the WinCE specific identifiers
(thanks Leo!).


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add httpstat.

[Marius Bakke]

Stefan Reichör  writes:

> From 06958884c4a29f43b9ade58a950b95bf9046d9f4 Mon Sep 17 00:00:00 2001
> From: Stefan Reichoer 
> Date: Fri, 23 Dec 2016 22:06:15 +0100
> Subject: [PATCH] gnu: Add httpstat.
>
> * gnu/packages/networking.scm (httpstat): New variable.
> ---
>  gnu/packages/networking.scm | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)

Thanks for this patch! Since it has a hard dependency on curl to
function, I think we should patch it with curl as input so that the user
don't have to install curl separately. Can you try that?

Typically this involves adding a substitution to the code that invokes
`curl` and replacing it with '(string-append (assoc-ref inputs "curl")
"/bin/curl")'.

TIA!

>
> diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
> index 2a5ff09..3c100c6 100644
> --- a/gnu/packages/networking.scm
> +++ b/gnu/packages/networking.scm
> @@ -2,7 +2,7 @@
>  ;;; Copyright © 2014 Ludovic Courtès 
>  ;;; Copyright © 2015, 2016 Ricardo Wurmus 
>  ;;; Copyright © 2015 Mark H Weaver 
> -;;; Copyright © 2015 Stefan Reichör 
> +;;; Copyright © 2015, 2016 Stefan Reichör 
>  ;;; Copyright © 2016 Raimon Grau 
>  ;;; Copyright © 2016 Tobias Geerinckx-Rice 
>  ;;; Copyright © 2016 John Darrington 
> @@ -34,6 +34,7 @@
>#:use-module (guix download)
>#:use-module (guix build-system glib-or-gtk)
>#:use-module (guix build-system gnu)
> +  #:use-module (guix build-system python)
>#:use-module (gnu packages)
>#:use-module (gnu packages admin)
>#:use-module (gnu packages adns)
> @@ -549,6 +550,24 @@ by firewalls or when you want to monitor the response 
> time of the actual web
>  application stack itself.")
>  (license license:gpl2))); with permission to link with OpenSSL
>  
> +(define-public httpstat
> +  (package
> +(name "httpstat")
> +(version "1.2.1")
> +(source
> +  (origin
> +(method url-fetch)
> +(uri (pypi-uri "httpstat" version))
> +(sha256
> +  (base32
> +"1chw2nk56vaq87aba012a270k9na06hfx1pfbsrc3jfvlc2kb9hb"
> +(build-system python-build-system)
> +(home-page "https://github.com/reorx/httpstat;)
> +(synopsis "visualize curl statistics")
> +(description
> + "httpstat visualizes curl statistics in a way of beauty and clarity.")
> +(license license:expat)))
> +
>  (define-public bwm-ng
>(package
>  (name "bwm-ng")
> -- 
> 2.7.4


signature.asc
Description: PGP signature

Re: [PATCH] gnu: leptonica: Update to 1.73.

[Marius Bakke]

"Taylan Ulrich Bayırlı/Kammer\""  writes:

> I struggled for days with the following bug and ultimately decided to
> disable tests for 1.73 to sidestep it entirely; tests should be
> re-enabled with the next release.
>
> https://github.com/DanBloomberg/leptonica/issues/224

OK! I'm not familiar with this software, are you sure the substitutions
are no longer required? The pkg-config file is fine as there is no
matching substitution in the current version, but I did not investigate
the config.h timestamp trick, or the failing tests.

If they are required for tests to pass on current git, I think they
should be kept so the next person don't have to reinvent them. I would
also keep gnuplot as a native-input, but that can be fixed up before
committing if you confirm that the other phases are no longer needed.

Thank you!

>
> ===File
> /home/taylan/src/guix/0001-gnu-leptonica-Update-to-1.73.patch===
> From 38ca93d5a6b78b9a3d3fafbec36cf3da7b0c371b Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  
> Date: Thu, 15 Dec 2016 09:39:30 +0100
> Subject: [PATCH] gnu: leptonica: Update to 1.73.
>
> * gnu/packages/image.scm (leptonica): Update to 1.73.
> ---
>  gnu/packages/image.scm | 54 
> +-
>  1 file changed, 18 insertions(+), 36 deletions(-)
>
> diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
> index 487635d..126e615 100644
> --- a/gnu/packages/image.scm
> +++ b/gnu/packages/image.scm
> @@ -329,28 +329,18 @@ the W3C's XML-based Scaleable Vector Graphic (SVG) 
> format.")
>  (define-public leptonica
>(package
>  (name "leptonica")
> -(version "1.72")
> +(version "1.73")
>  (source
>   (origin
> (method url-fetch)
> (uri (string-append "http://www.leptonica.com/source/leptonica-;
> version ".tar.gz"))
> (sha256
> -(base32 "0mhzvqs0im04y1cpcc1yma70hgdac1frf33h73m9z3356bfymmbr"))
> -   (modules '((guix build utils)))
> -   ;; zlib and openjpg should be under Libs, not Libs.private.  See:
> -   ;; https://code.google.com/p/tesseract-ocr/issues/detail?id=1436
> -   (snippet
> -'(substitute* "lept.pc.in"
> -   (("^(Libs\\.private: .*)@ZLIB_LIBS@(.*)" all pre post)
> -(string-append pre post))
> -   (("^(Libs\\.private: .*)@JPEG_LIBS@(.*)" all pre post)
> -(string-append pre post))
> -   (("^Libs: .*" all)
> -(string-append all " @ZLIB_LIBS@ @JPEG_LIBS@"))
> +(base32 "1hdgb6lflj5gc3c37rac5nk38vr6qln3im9qjfpphysfcxf37r0r"
>  (build-system gnu-build-system)
> -(native-inputs
> - `(("gnuplot" ,gnuplot)))   ;needed for test suite
> +;; XXX Re-enable this when the test suite is re-enabled.
> +;; (native-inputs
> +;;  `(("gnuplot" ,gnuplot)))   ;needed for test suite
>  (inputs
>   `(("giflib" ,giflib)
> ("libjpeg" ,libjpeg)
> @@ -358,31 +348,23 @@ the W3C's XML-based Scaleable Vector Graphic (SVG) 
> format.")
> ("libtiff" ,libtiff)
> ("libwebp" ,libwebp)))
>  (propagated-inputs
> + ;; Linking a program with leptonica also requires these.
>   `(("openjpeg" ,openjpeg)
> ("zlib" ,zlib)))
>  (arguments
> - '(#:parallel-tests? #f ; XXX: cause fpix1_reg to fail
> -   #:phases
> + '(#:phases
> (modify-phases %standard-phases
> - ;; Prevent make from trying to regenerate config.h.in.
> - (add-after
> -  'unpack 'set-config-h-in-file-time
> -  (lambda _
> -(set-file-time "config/config.h.in" (stat "configure"
> - (add-after
> -  'unpack 'patch-reg-wrapper
> -  (lambda _
> -(substitute* "prog/reg_wrapper.sh"
> -  ((" /bin/sh ")
> -   (string-append " " (which "sh") " "))
> -  (("which gnuplot") (which "gnuplot")
> - (add-before
> -  'check 'disable-failing-tests
> -  ;; XXX: 2 of 9 tests from webpio_reg fails.
> -  (lambda _
> -(substitute* "prog/webpio_reg.c"
> -  ((".*DoWebpTest2.* 90.*") "")
> -  ((".*DoWebpTest2.* 100.*") "")))
> + (add-after 'unpack 'patch-reg-wrapper
> +   (lambda _
> + (substitute* "prog/reg_wrapper.sh"
> +   ((" /bin/sh ")
> +(string-append " " (which "sh") " "))
> +   (("which gnuplot")
> +"true")
> +   ;; All tests of 1.73 fail in Guix's build environment due to the bug:
> +   ;; https://github.com/DanBloomberg/leptonica/issues/224
> +   ;; XXX Enable tests in 1.74 as the bug is fixed upstream.
> +   #:tests? #f))
>  (home-page "http://www.leptonica.com/;)
>  (synopsis "Library and tools for image processing and analysis")
>  (description
> -- 
> 2.10.2
>
> 

Ruby 2.4.0 update

[Marius Bakke]

In good tradition, ruby made a new release today (25/12)[0].

I tried building some packages with the new version, but ruby-minitest
complains that Rake 12 is too new (even with the latest minitest). There
have been some core changes as well, with Fixnum and Bignum now merged
into a single Integer class.

I suggest that we keep ruby 2.3 as the main "ruby" variable until the
ecosystem catches up. Users will still get the latest version when
using `guix package` or `guix environment`. WDYT?

Patch attached. Not sure about the commit message.

0: https://www.ruby-lang.org/en/news/2016/12/25/ruby-2-4-0-released/



signature.asc
Description: PGP signature
>From 6f029cbaedf273febef92e9c4197c55414b818d5 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Sun, 25 Dec 2016 18:07:47 +0100
Subject: [PATCH] gnu: ruby: Update to 2.4.0.

* gnu/packages/ruby.scm (ruby-2.4): New variable.
---
 gnu/packages/ruby.scm | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index c87f8b309..dee98c236 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -100,6 +100,20 @@ a focus on simplicity and productivity.")
 (home-page "https://ruby-lang.org;)
 (license license:ruby)))
 
+(define-public ruby-2.4
+  (package (inherit ruby)
+   (replacement #f)
+   (version "2.4.0")
+   (source
+(origin
+  (method url-fetch)
+  (uri (string-append "https://cache.ruby-lang.org/pub/ruby/;
+  (version-major+minor version)
+  "/ruby-" version ".tar.xz"))
+  (sha256
+   (base32
+"141nnsdk2q83c23p5kl404id8gy1ap261gin48rbjj5sbksgx1rs"))
+
 (define-public ruby-2.2
   (package (inherit ruby)
 (replacement #f)
-- 
2.11.0

Re: [PATCH] gnu: leptonica: Update to 1.73.

[Marius Bakke]

"Taylan Ulrich Bayırlı/Kammer" <taylanbayi...@gmail.com> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> "Taylan Ulrich Bayırlı/Kammer\"" <taylanbayi...@gmail.com> writes:
>>
>>> I struggled for days with the following bug and ultimately decided to
>>> disable tests for 1.73 to sidestep it entirely; tests should be
>>> re-enabled with the next release.
>>>
>>> https://github.com/DanBloomberg/leptonica/issues/224
>>
>> OK! I'm not familiar with this software, are you sure the substitutions
>> are no longer required? The pkg-config file is fine as there is no
>> matching substitution in the current version, but I did not investigate
>> the config.h timestamp trick, or the failing tests.
>>
>> If they are required for tests to pass on current git, I think they
>> should be kept so the next person don't have to reinvent them. I would
>> also keep gnuplot as a native-input, but that can be fixed up before
>> committing if you confirm that the other phases are no longer needed.
>>
>> Thank you!
>
> You know what, Leptonica 1.74.0 has been released yesterday, so here's a
> new patch. :-D
>
> But yes, the source snippet / patch for the .pc file isn't necessary
> anymore for reasons not really clear to me.  (The two libs still need to
> be propagated and Tesseract has to link against them; maybe Tesseract
> special-handles this and other dependents of Leptonica could still
> benefit from a patched .pc file, but so far we don't have any other
> dependents of Leptonica...)
>
> The config.h hack probably wasn't necessary anymore since 1.72; I had
> introduced it with 1.71 where the issue existed and it didn't get
> removed upon the 1.72 update.
>
> And all tests pass, without having to disable parallel tests either.
>
> The 1.74.0 tag on GitHub corresponds to a state in which ./configure
> doesn't exist; the autobuild script needs to be run.
>
> So here's the new patch.

Thanks for the clarification and update, pushed!

I completely forgot to mention the origin and argument changes in the
commit message as we usually do. Hopefully the next update can include
that too ;-)

>
> From f2b7609e5934511b185f73b4927cecf7b404b047 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  <taylanbayi...@gmail.com>
> Date: Thu, 15 Dec 2016 09:39:30 +0100
> Subject: [PATCH] gnu: leptonica: Update to 1.74.0.
>
> * gnu/packages/image.scm (leptonica): Update to 1.74.0.
> ---
>  gnu/packages/image.scm | 60 
> +++---
>  1 file changed, 23 insertions(+), 37 deletions(-)
>
> diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
> index 487635d..1c500b3 100644
> --- a/gnu/packages/image.scm
> +++ b/gnu/packages/image.scm
> @@ -329,28 +329,23 @@ the W3C's XML-based Scaleable Vector Graphic (SVG) 
> format.")
>  (define-public leptonica
>(package
>  (name "leptonica")
> -(version "1.72")
> +(version "1.74.0")
>  (source
>   (origin
> (method url-fetch)
> -   (uri (string-append "http://www.leptonica.com/source/leptonica-;
> -   version ".tar.gz"))
> +   (uri (string-append
> + "https://github.com/DanBloomberg/leptonica/archive/; version
> + ".tar.gz"))
> +   (file-name (string-append "leptonica-" version ".tar.gz"))
> (sha256
> -(base32 "0mhzvqs0im04y1cpcc1yma70hgdac1frf33h73m9z3356bfymmbr"))
> -   (modules '((guix build utils)))
> -   ;; zlib and openjpg should be under Libs, not Libs.private.  See:
> -   ;; https://code.google.com/p/tesseract-ocr/issues/detail?id=1436
> -   (snippet
> -'(substitute* "lept.pc.in"
> -   (("^(Libs\\.private: .*)@ZLIB_LIBS@(.*)" all pre post)
> -(string-append pre post))
> -   (("^(Libs\\.private: .*)@JPEG_LIBS@(.*)" all pre post)
> -(string-append pre post))
> -   (("^Libs: .*" all)
> -(string-append all " @ZLIB_LIBS@ @JPEG_LIBS@"))
> +(base32 "0i2a4vx9gizki0wgmv03xjz8j9d8agkvbag1a8m4kcw4asd4p87g"
>  (build-system gnu-build-system)
>  (native-inputs
> - `(("gnuplot" ,gnuplot)))   ;needed for test suite
> + `(("gnuplot" ,gnuplot) ;needed for test suite
> +   ("autoconf" ,autoconf)
> +   ("automake" ,automake)
> +   ("libtool" ,libtool)
> +   (&q

Re: [PATCH] wireshark: Update to 2.2.3.

[Marius Bakke]

Nicolas Goaziou  writes:

> Hello,
>
> Here is an update for Wireshark.

Applied, thanks!


signature.asc
Description: PGP signature

Re: [PATCH] Update emacs-org to 20161224

[Marius Bakke]

Nicolas Goaziou  writes:

> Hello,
>
> Here is an update for the latest Org release.

Thanks, applied!



signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add httpstat.

[Marius Bakke]

Stefan Reichör  writes:

> Hi Marius!
>
>> Stefan Reichör  writes:
>>
>>> From 06958884c4a29f43b9ade58a950b95bf9046d9f4 Mon Sep 17 00:00:00 2001
>>> From: Stefan Reichoer 
>>> Date: Fri, 23 Dec 2016 22:06:15 +0100
>>> Subject: [PATCH] gnu: Add httpstat.
>>>
>>> * gnu/packages/networking.scm (httpstat): New variable.
>>> ---
>>>  gnu/packages/networking.scm | 21 -
>>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> Thanks for this patch! Since it has a hard dependency on curl to
>> function, I think we should patch it with curl as input so that the user
>> don't have to install curl separately. Can you try that?
>>
>> Typically this involves adding a substitution to the code that invokes
>> `curl` and replacing it with '(string-append (assoc-ref inputs "curl")
>> "/bin/curl")'.
>>
>> TIA!
>>
>
> Good idea - thanks for your feedback!
>
> Here is my attempt to use the guix provided curl package:

Thanks! I altered the description to be a little more informative and
ran the indentation through emacs. Pushed!

>
> From f4ed7438a254e0496518008ca368e1394cce34ce Mon Sep 17 00:00:00 2001
> From: Stefan Reichoer 
> Date: Mon, 26 Dec 2016 21:22:19 +0100
> Subject: [PATCH] gnu: Add httpstat.
>
> * gnu/packages/networking.scm (httpstat): New variable.
> ---
>  gnu/packages/networking.scm | 33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
> index 2a5ff09..174d0b3 100644
> --- a/gnu/packages/networking.scm
> +++ b/gnu/packages/networking.scm
> @@ -2,7 +2,7 @@
>  ;;; Copyright © 2014 Ludovic Courtès 
>  ;;; Copyright © 2015, 2016 Ricardo Wurmus 
>  ;;; Copyright © 2015 Mark H Weaver 
> -;;; Copyright © 2015 Stefan Reichör 
> +;;; Copyright © 2015, 2016 Stefan Reichör 
>  ;;; Copyright © 2016 Raimon Grau 
>  ;;; Copyright © 2016 Tobias Geerinckx-Rice 
>  ;;; Copyright © 2016 John Darrington 
> @@ -34,6 +34,7 @@
>#:use-module (guix download)
>#:use-module (guix build-system glib-or-gtk)
>#:use-module (guix build-system gnu)
> +  #:use-module (guix build-system python)
>#:use-module (gnu packages)
>#:use-module (gnu packages admin)
>#:use-module (gnu packages adns)
> @@ -43,6 +44,7 @@
>#:use-module (gnu packages check)
>#:use-module (gnu packages code)
>#:use-module (gnu packages compression)
> +  #:use-module (gnu packages curl)
>#:use-module (gnu packages databases)
>#:use-module (gnu packages flex)
>#:use-module (gnu packages gettext)
> @@ -549,6 +551,35 @@ by firewalls or when you want to monitor the response 
> time of the actual web
>  application stack itself.")
>  (license license:gpl2))); with permission to link with OpenSSL
>  
> +(define-public httpstat
> +  (package
> +(name "httpstat")
> +(version "1.2.1")
> +(source
> +  (origin
> +(method url-fetch)
> +(uri (pypi-uri "httpstat" version))
> +(sha256
> +  (base32
> +   "1chw2nk56vaq87aba012a270k9na06hfx1pfbsrc3jfvlc2kb9hb"
> +(build-system python-build-system)
> +(inputs `(("curl" ,curl)))
> +(arguments
> + '(#:phases
> +   (modify-phases %standard-phases
> + (add-before 'build 'fix-curl-path
> + (lambda* (#:key inputs #:allow-other-keys)
> +   (substitute* "httpstat.py"
> + (("ENV_CURL_BIN.get\\('curl'\\)")
> +  (string-append "ENV_CURL_BIN.get('"
> + (assoc-ref inputs "curl")
> + "/bin/curl')"
> +(home-page "https://github.com/reorx/httpstat;)
> +(synopsis "Visualize curl statistics")
> +(description
> + "httpstat visualizes curl statistics in a way of beauty and clarity.")
> +(license license:expat)))
> +
>  (define-public bwm-ng
>(package
>  (name "bwm-ng")
> -- 
> 2.7.4


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add python-netcdf4.

[Marius Bakke]

Thomas Danckaert <thomas.dancka...@gmail.com> writes:

> From: Marius Bakke <mba...@fastmail.com>
> Subject: Re: [PATCH] gnu: Add python-netcdf4.
> Date: Sat, 24 Dec 2016 14:59:35 +0100
>
>> Thomas Danckaert <thomas.dancka...@gmail.com> writes:
>>
>>> From b4b54b695e286c19332600c38d5e07fabee409f8 Mon Sep 17 00:00:00 
>>> 2001
>>> From: Thomas Danckaert <thomas.dancka...@gmail.com>
>>> Date: Fri, 23 Dec 2016 15:06:43 +0100
>>> Subject: [PATCH] gnu: Add python-netcdf4.
>>>
>>> * gnu/packages/python.scm (python-netcdf4): New variable.
>>> ---
>>>  gnu/packages/python.scm | 50 
>>> +
>>>  1 file changed, 50 insertions(+)
>>
>> Thanks for this! The patch looks good, but the license seems to be 
>> ISC
>> with parts covered by the expat license according to the COPYING 
>> file.
>> Was there any particular reason you linked to the documentation?
>
> Hi,
>
> yes, you're right.  I linked the documentation because the page 
> included a license statement, but now I see the COPYING file in the 
> repository is more accurate.  So '(license:isc license:expat) it is.

Thanks for confirming, applied!


signature.asc
Description: PGP signature

Re: [PATCH] gnu: leptonica: Update to 1.73.

[Marius Bakke]

"Taylan Ulrich Bayırlı/Kammer" <taylanbayi...@gmail.com> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> "Taylan Ulrich Bayırlı/Kammer" <taylanbayi...@gmail.com> writes:
>>
>>> You know what, Leptonica 1.74.0 has been released yesterday, so here's a
>>> new patch. :-D
>>>
>>> But yes, the source snippet / patch for the .pc file isn't necessary
>>> anymore for reasons not really clear to me.  (The two libs still need to
>>> be propagated and Tesseract has to link against them; maybe Tesseract
>>> special-handles this and other dependents of Leptonica could still
>>> benefit from a patched .pc file, but so far we don't have any other
>>> dependents of Leptonica...)
>>>
>>> The config.h hack probably wasn't necessary anymore since 1.72; I had
>>> introduced it with 1.71 where the issue existed and it didn't get
>>> removed upon the 1.72 update.
>>>
>>> And all tests pass, without having to disable parallel tests either.
>>>
>>> The 1.74.0 tag on GitHub corresponds to a state in which ./configure
>>> doesn't exist; the autobuild script needs to be run.
>>>
>>> So here's the new patch.
>>
>> Thanks for the clarification and update, pushed!
>>
>> I completely forgot to mention the origin and argument changes in the
>> commit message as we usually do. Hopefully the next update can include
>> that too ;-)
>
> Thanks. :-)
>
> FYI I have push access so in the future you can just tell me to push it.

Oh, thanks for letting me know :-)

> I guess I can be more strict with the commit lines.  Usually I assume
> that some changes to the rest of the recipe are implied in a version
> update...

I think it is useful to mention such changes in the commit message, so
that one can clearly see in the git log which commit introduced e.g. a
new phase, or new source URL, instead of having to dig through the full
diffs (or blame) to find it.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add python-hdf4.

[Marius Bakke]

Thomas Danckaert  writes:

> Hi Guix,
>
> this patch adds python-hdf4.  I'm not sure if the line “Python-HDF4 
> is a fork of pyhdf.” in the description is necessary.  The original 
> and “official” pyhdf (http://hdfeos.org/software/pyhdf.php) is 
> somewhat outdated (e.g. doesn't support python3).

The "official" pyhdf and this fork was released around the same time and
have the same version number. Confusing! But I'll take your word that
this one is better. I'd keep the fork comment in the description though,
in case someone is looking for pyhdf. Could you wrap pyhdf in '@url{}'?

Regarding the patch, I wonder if it should go in (gnu packages maths),
similar to how we put PDF libraries in pdf.scm and XML in xml.scm etc.
But no strong opinion here.

'python-numpy' should be a propagated-input since it is imported at
runtime, and not a dynamically linked C library like the other inputs.

The 'check' phase seems to run the build again, and prints at the end
"Ran 0 tests in 0.000s". Looking at the Github ".travis.yml", the CI
tool runs the command "nosetests" instead of 'python setup.py test' like
python-build-system does by default. Can you try replacing the 'check'
phase with that command? You'll need 'python-nose' as a native-input.

It seems you also forgot to add a copyright line. Can you send an
updated patch? Thank you! :-)


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add wwwoffle.

[Marius Bakke]

Bake Timmons <65pan...@gmail.com> writes:

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

Thanks for this! The patch looks good, but does not build on master
because the "libgcrypt" variable cannot be found. It can be imported
from the "gnupg" module.

Some other trivial comments: Home page and source should use HTTPS when
available, and we try to add comments about why tests are disabled.
Could you also add a copyright line for yourself?

I can do these minor edits for you if you prefer, but would like to
confirm name and email for the copyright. Thanks!

>
> diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
> index 184869200..c4e716c2b 100644
> --- a/gnu/packages/web.scm
> +++ b/gnu/packages/web.scm
> @@ -668,6 +668,34 @@ server).  It was primarily designed to be used by one 
> person or a small group
>  of people.")
>  (license l:expat)))
>  
> +(define-public wwwoffle
> +  (package
> +(name "wwwoffle")
> +(version "2.9j")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "http://www.gedanken.org.uk/software/;
> +  "wwwoffle/download/wwwoffle-"
> +  version ".tgz"))
> +  (sha256
> +   (base32
> +"1ihil1xq9dp21hf108khxbw6f3baq0w5c0j3af038y6lkmad4vdi"
> +(build-system gnu-build-system)
> +(arguments
> + `(#:configure-flags '("--with-gnutls")
> +   #:tests? #f))
> +(native-inputs `(("flex" ,flex)))
> +(inputs `(("gnutls" ,gnutls)
> +  ("libcrypt", libgcrypt)))
> +(home-page "http://www.gedanken.org.uk/software/wwwoffle/;)
> +(synopsis "Caching web proxy optimized for intermittent internet links")
> +(description "WWWOFFLE is a proxy web server that is especially good for
> +intermittent internet links.  It can cache HTTP, HTTPS, FTP, and finger
> +protocols, and supports browsing and requesting pages while offline, 
> indexing,
> +modifying pages and incoming and outgoing headers, monitoring pages for
> +changes, and much more.")
> +(license l:gpl2+)))
> +
>  (define-public libyaml
>(package
>  (name "libyaml")
> -- 
> 2.11.0


signature.asc
Description: PGP signature

Re: [PATCH 6/6] gnu: Add grub-efi.

[Marius Bakke]

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

> Marius Bakke <mba...@fastmail.com> skribis:
>
>> Ludovic Courtès <l...@gnu.org> writes:
>>
>>> Hi Marius,
>>>
>>> Marius Bakke <mba...@fastmail.com> skribis:
>>>
>>>> Ludovic Courtès <l...@gnu.org> writes:
>>>>
>>>>>> Relatedly, I think the way to build a 'multi-grub' is to have one
>>>>>> expression for each supported grub platform, and then consolidate
>>>>>> out/lib/grub from each.
>>>>>
>>>>> So in essence, GRUB itself supports only one platform at a time?
>>>>
>>>> AFAICT yes. Gentoo works around this by running the build for each
>>>> user-specified platform and combining the outputs. Most other distros
>>>> just carry separate grub-pc and grub-efi packages.
>>>>
>>>>>>> Now there are things I didn’t quite get.  Apparently you’re supposed to
>>>>>>> have a /boot/efi as a vfat partition, and ‘grub-install’ is supposed to
>>>>>>> detect it and install the EFI stuff, or so I thought (info "(grub)
>>>>>>> Installing GRUB using grub-install").
>>>>>>>
>>>>>>> However, ‘grub-install’ still seems to be installing for “i386-pc”
>>>>>>> instead of EFI.
>>>>>>>
>>>>>>> What am I missing?
>>>>>>
>>>>>> IIRC grub-install will detect and install for the running mode (pc, efi,
>>>>>> etc). So in a classic chicken-and-egg situation, you need to be booted
>>>>>> with UEFI mode for grub to select the correct installation platform!
>>>>>
>>>>> My understanding is that it would install for UEFI if it fines
>>>>> /boot/efi or if --efi-directory is passed.
>>>>
>>>> I'm not so sure, but it's been a while since I played around with this.
>>>> At least building the 'gnu/system/install.scm' image works fine when
>>>> passing --efi-directory (see the bottom two patches from
>>>> https://lists.gnu.org/archive/html/guix-devel/2016-12/txtchTym4QVKr.txt ),
>>>> and I think it would choose i386-pc even if x86_64-efi was available
>>>> since the VM boots in BIOS mode.
>>>>
>>>> Tangentially, I'm not aware of any way to build a "hybrid" ISO image
>>>> using only grub. I've started work on packaging syslinux/isolinux which
>>>> is what Debian uses for their hybrid UEFI/BIOS install image.
>>>
>>> OK.
>>>
>>> Having checked GRUB’s configure.ac etc., I realize that my suggestion of
>>> having one ‘grub’ package doing both EFI and “PC” cannot work.  What you
>>> suggested initially (a separate ‘grub-efi’ package) is the only thing we
>>> can do (we could perhaps merge the lib/grub directories as you
>>> suggested, but it’s not even clear that this would work.)
>>>
>>> Thus, I think we need to revert 3eee16130d858ae96510ec1c7d38d31290de2699
>>> and install your initial ‘grub-efi’ patch.  How does that sound?
>>
>> OK. I'll try to find out why tests don't work with the UEFI variant
>> first in order to at least write a meaningful comment. Maybe qemu needs
>> UEFI support or something like that.
>
> It might be that we no longer need QEMU 1.3.1 to run the tests (see the
> top of gnu/packages/grub.scm)?

The problem is missing UEFI firmware for the qemu calls. But we indeed
no longer need qemu@1.3.1 for the tests, at least on x86_64. I replaced
it with 'qemu-minimal'. Pushed!


signature.asc
Description: PGP signature

Re: [PATCH 0/1] Libxml2 CVE-2016-4658 and CVE-2016-5131

[Marius Bakke]

Leo Famulari  writes:

> This patch fixes CVE-2016-4658 and CVE-2016-5131 in libxml2.
>
> I noticed that Debian applied several more upstream changes to their
> package:
>
> https://anonscm.debian.org/cgit/debian-xml-sgml/libxml2.git/tree/debian/patches
>
> Here is the upstream repository:
>
> https://git.gnome.org/browse/libxml2/log/
>
> Your thoughts?

The patches LGTM. I'm confused by CVE-2016-4658, the only "affected
products" seem to be Apple-based platforms, yet the code itself does
not seem platform-specific. And it looks like a serious vulnerability.

The other patch is less severe, but at least has some references in free
software circles. I'd say push them. Should it be grafted, or can we
wait for the next 'core-updates' evaluation?

I did not look into the other Debian patches.

>
> Leo Famulari (1):
>   gnu: libxml: Fix CVE-2016-{4658,5131}.
>
>  gnu/local.mk |   2 +
>  gnu/packages/patches/libxml2-CVE-2016-4658.patch | 257 
> +++
>  gnu/packages/patches/libxml2-CVE-2016-5131.patch | 218 +++
>  gnu/packages/xml.scm |   2 +
>  4 files changed, 479 insertions(+)
>  create mode 100644 gnu/packages/patches/libxml2-CVE-2016-4658.patch
>  create mode 100644 gnu/packages/patches/libxml2-CVE-2016-5131.patch
>
> -- 
> 2.11.0


signature.asc
Description: PGP signature

Re: [PATCH] gnu: netcdf: Enable HDF4 support.

[Marius Bakke]

Thomas Danckaert  writes:

> Hi Guix,
>
> this patch enables HDF4 support in the netCDF package.
>
> By the way, I noticed some error messages from doxygen during the 
> build:
>
> error: Problems running dot: exit code=127, command='dot', 
> arguments='"/tmp/guix-build-netcdf-4.4.1.1.drv-0/netcdf-4.4.1.1/docs/html/datt_8c__incl.dot"
>  
> -Tpng -o 
> "/tmp/guix-build-netcdf-4.4.1.1.drv-0/netcdf-4.4.1.1/docs/html/datt_8c__incl.png"'
> (these error are already in the present package, for example see 
> http://hydra.gnu.org/build/1686038/log/raw ).
>
> These errors don't cause the build to fail, and are related to 
> html/pdf documentation, which is not installed anyway, as far is I 
> can see.  So perhaps not very critical.
>
> When I build the package myself in a “guix environment netcdf”, I 
> can't reproduce the errors.

The above error indicates that the 'dot' command cannot be found during
the build process. If it works in `guix environment netcdf`, perhaps you
are on a foreign distro and have /usr/bin/dot in your PATH? In any case
it should be fixed in a separate patch, and likely only needed for
documentation.

I've applied this patch, thanks!

> From 893ef9ad6bfb8edbe64d64f3ab5d6a0bd4705a5f Mon Sep 17 00:00:00 2001
> From: Thomas Danckaert 
> Date: Fri, 23 Dec 2016 14:56:00 +0100
> Subject: [PATCH] gnu: netcdf: Enable HDF4 support.
>
> * gnu/packages/maths.scm (netcdf)[inputs]: Add hdf4-alt and libjpeg.
>   [arguments]: Add "--enable-hdf4" configure flag.
> ---
>  gnu/packages/maths.scm | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
> index e15eddc..d045895 100644
> --- a/gnu/packages/maths.scm
> +++ b/gnu/packages/maths.scm
> @@ -726,10 +726,12 @@ HDF5 file is encoded according to the HDF File Format 
> Specification.")
> ("doxygen" ,doxygen)
> ("graphviz" ,graphviz)))
>  (inputs
> - `(("hdf5" ,hdf5)
> -   ("zlib" ,zlib)))
> + `(("hdf4" ,hdf4-alt)
> +   ("hdf5" ,hdf5)
> +   ("zlib" ,zlib)
> +   ("libjpeg" ,libjpeg)))
>  (arguments
> - `(#:configure-flags '("--enable-doxygen" "--enable-dot")
> + `(#:configure-flags '("--enable-doxygen" "--enable-dot" "--enable-hdf4")
> #:parallel-tests? #f))   ;various race conditions
>  (home-page "http://www.unidata.ucar.edu/software/netcdf/;)
>  (synopsis "Library for scientific data")
> -- 
> 2.7.4


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add python-netcdf4.

[Marius Bakke]

Thomas Danckaert  writes:

> From b4b54b695e286c19332600c38d5e07fabee409f8 Mon Sep 17 00:00:00 2001
> From: Thomas Danckaert 
> Date: Fri, 23 Dec 2016 15:06:43 +0100
> Subject: [PATCH] gnu: Add python-netcdf4.
>
> * gnu/packages/python.scm (python-netcdf4): New variable.
> ---
>  gnu/packages/python.scm | 50 
> +
>  1 file changed, 50 insertions(+)

Thanks for this! The patch looks good, but the license seems to be ISC
with parts covered by the expat license according to the COPYING file.
Was there any particular reason you linked to the documentation?

> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index cc53f76..37ad3df 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -800,6 +800,56 @@ concepts.")
>  (define-public python2-h5py
>(package-with-python2 python-h5py))
>  
> +(define-public python-netcdf4
> +  (package
> +(name "python-netcdf4")
> +(version "1.2.6")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (pypi-uri "netCDF4" version))
> +   (sha256
> +(base32
> + "1qcymsfxsdfr4sx0vl7ih5d14z66k6c9sjy4gb6rjaksk5387zvg"
> +(build-system python-build-system)
> +(native-inputs
> + `(("python-cython" ,python-cython)))
> +(propagated-inputs
> + `(("python-numpy" ,python-numpy)))
> +(inputs
> + `(("netcdf" ,netcdf)
> +   ("hdf4" ,hdf4)
> +   ("hdf5" ,hdf5)))
> +(arguments
> + '(#:phases
> +   (modify-phases %standard-phases
> + (replace 'check
> +   (lambda _
> + (setenv "NO_NET" "1") ;; disable opendap tests
> + (with-directory-excursion "test"
> +   (setenv "PYTHONPATH" ;; find and add the library we just built
> +   (string-append
> +(car (find-files "../build" "lib.*"
> + #:directories? #:t
> + #:fail-on-error? #:t))
> +":" (getenv "PYTHONPATH")))
> +   (zero? (system* "python" "run_all.py"
> +(home-page
> + "https://github.com/Unidata/netcdf4-python;)
> +(synopsis "Python/numpy interface to the netCDF library")
> +(description "Netcdf4-python is a Python interface to the netCDF C
> +library.  netCDF version 4 has many features not found in earlier
> +versions of the library and is implemented on top of HDF5.  This module
> +can read and write files in both the new netCDF 4 and the old netCDF 3
> +format, and can create files that are readable by HDF5 clients.  The
> +API is modelled after Scientific.IO.NetCDF, and should be familiar to
> +users of that module.")
> +(license
> + (license:non-copyleft "https://unidata.github.io/netcdf4-python;
> +
> +(define-public python2-netcdf4
> +  (package-with-python2 python-netcdf4))
> +
>  (define-public python-lockfile
>(package
>  (name "python-lockfile")
> -- 
> 2.7.4


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add python-xopen.

[Marius Bakke]

Tobias Geerinckx-Rice <m...@tobias.gr> writes:

> Marius,
>
> On 15/12/16 10:20, Marius Bakke wrote:
>> Why not use 'pypi-uri' here? Otherwise LGTM.
>
> What would that give us?

Good question. Pypi archives are sometimes smaller than the raw sources
or otherwise "prepared", but I guess no inherent benefits.


signature.asc
Description: PGP signature

[PATCH 1/6] gnu: Add leveldb.

[Marius Bakke]

* gnu/packages/databases.scm (leveldb): New variable.
---
 gnu/packages/databases.scm | 37 +
 1 file changed, 37 insertions(+)

diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index e05a337e4..4bbe55bab 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -13,6 +13,7 @@
 ;;; Copyright © 2016 David Craven <da...@craven.ch>
 ;;; Copyright © 2016 Jan Nieuwenhuizen <jann...@gnu.org>
 ;;; Copyright © 2016 Andy Patterson <ajpat...@uwaterloo.ca>
+;;; Copyright © 2017 Marius Bakke <mba...@fastmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -207,6 +208,42 @@ SQL, Key/Value, XML/XQuery or Java Object storage for 
their data model.")
(base32
 "0a1n5hbl7027fbz5lm0vp0zzfp1hmxnz14wx3zl9563h83br5ag0"))
 
+(define-public leveldb
+  (package
+(name "leveldb")
+(version "1.19")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://github.com/google/leveldb;
+  "/archive/v" version ".tar.gz"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"00jjgs9xlwycfkg0xd7n1rj6v9zrx7xc7hann6zalrjyhap18ykx"
+(build-system gnu-build-system)
+(arguments
+ '(#:make-flags (list "CC=gcc")
+   #:phases
+   (modify-phases %standard-phases
+ (delete 'configure)
+ (replace 'install
+   ;; There is no install target, so we do it here.
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(lib (string-append out "/lib"))
+(include (string-append out "/include")))
+   (for-each (lambda (file)
+   (install-file file lib))
+ (find-files "out-shared" "^libleveldb.so.*"))
+   (copy-recursively "include" include)
+   #t))
+(home-page "http://leveldb.org/;)
+(synopsis "Fast key-value storage library")
+(description
+ "LevelDB is a fast key-value storage library that provides an ordered
+mapping from string keys to string values.")
+(license bsd-3)))
+
 (define-public mysql
   (package
 (name "mysql")
-- 
2.11.0

[PATCH 3/6] gnu: Add python-cram.

[Marius Bakke]

* gnu/packages/python.scm (python-cram, python2-cram): New variables.
---
 gnu/packages/python.scm | 64 -
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index ddf276de0..e61d7d1fb 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -26,7 +26,7 @@
 ;;; Copyright © 2016 ng0 <n...@we.make.ritual.n0.is>
 ;;; Copyright © 2016 Dylan Jeffers <sapientech@sapient...@openmailbox.org>
 ;;; Copyright © 2016 David Craven <da...@craven.ch>
-;;; Copyright © 2016 Marius Bakke <mba...@fastmail.com>
+;;; Copyright © 2016, 2017 Marius Bakke <mba...@fastmail.com>
 ;;; Copyright © 2016 Stefan Reichoer <ste...@xsteve.at>
 ;;; Copyright © 2016 Dylan Jeffers <sapientech@sapient...@openmailbox.org>
 ;;; Copyright © 2016 Alex Vong <alexvong1...@gmail.com>
@@ -6057,6 +6057,68 @@ pseudo terminal (pty), and interact with both the 
process and its pty.")
 (define-public python2-ptyprocess
   (package-with-python2 python-ptyprocess))
 
+(define-public python-cram
+  (package
+(name "python-cram")
+(version "0.7")
+(home-page "https://bitheap.org/cram/;)
+(source (origin
+  (method url-fetch)
+  (uri (list (string-append home-page "cram-"
+version ".tar.gz")
+ (pypi-uri "cram" version)))
+  (sha256
+   (base32
+"0bvz6fwdi55rkrz3f50zsy35gvvwhlppki2yml5bj5ffy9d499vx"
+(arguments
+ '(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'patch-source
+   (lambda _
+ (substitute* (find-files "cram" ".*\\.py")
+   ;; Replace default shell path. This is necessary for tests,
+   ;; and convenient for programs using the main "cram" binary
+   ;; in environments lacking /bin/sh (e.g. if this program is
+   ;; used in other builds).
+   (("/bin/sh") (which "sh")))
+ (substitute* (find-files "tests" ".*\\.t")
+   (("md5") "md5sum")
+   (("/bin/bash") (which "bash"))
+   (("/bin/sh") (which "sh")))
+ (substitute* "cram/_test.py"
+   ;; This hack works around a bug triggered by substituting
+   ;; the /bin/sh paths. "tests/usage.t" compares the output of
+   ;; "cram -h", which breaks the output at 80 characters. This
+   ;; causes the line showing the default shell to break into two
+   ;; lines, but the test expects a single line...
+   (("env\\['COLUMNS'\\] = '80'")
+"env['COLUMNS'] = '160'"))
+ #t))
+ (delete 'check)
+ (add-after 'install 'check
+   ;; The test phase uses the built binary and library.
+   ;; It's easier to run it after install since the build
+   ;; directory contains version-specific PATH.
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (add-installed-pythonpath inputs outputs)
+ (setenv "PATH" (string-append (getenv "PATH") ":"
+   (assoc-ref outputs "out") "/bin"))
+ (zero? (system* "make" "test")))
+(build-system python-build-system)
+(native-inputs
+ `(("python-coverage" ,python-coverage)
+   ("which" ,which)))
+(synopsis "Simple testing framework for command line applications")
+(description
+ "Cram is a functional testing framework for command line applications.
+Cram tests look like snippets of interactive shell sessions.  Cram runs each
+command and compares the command output in the test with the command’s actual
+output.")
+(license license:gpl2+)))
+
+(define-public python2-cram
+  (package-with-python2 python-cram))
+
 (define-public python-terminado
   (package
 (name "python-terminado")
-- 
2.11.0

[PATCH 0/6] gnu: Add ceph.

[Marius Bakke]

Hello Guix,

This series adds the Ceph distributed filesystem to Guix.

Ceph is not fully working yet, the executables need to be wrapped with
PYTHONPATH at the very least. But the library seems to work.

Feedback wanted, will send updated Ceph patch when I've tested it.

Note: "crypto++" ended up unused in favor of "nss" since that is what
upstream uses in their release builds.

Marius Bakke (6):
  gnu: Add leveldb.
  gnu: Add crypto++.
  gnu: Add python-cram.
  gnu: Add rocksdb.
  gnu: Add ceph.
  gnu: fio: Enable rbd support.

 gnu/local.mk |   1 +
 gnu/packages/benchmark.scm   |   4 +-
 gnu/packages/crypto.scm  |  90 +++-
 gnu/packages/databases.scm   | 123 ++
 gnu/packages/distributed-filesystems.scm | 172 +++
 gnu/packages/python.scm  |  64 +++-
 6 files changed, 451 insertions(+), 3 deletions(-)
 create mode 100644 gnu/packages/distributed-filesystems.scm

-- 
2.11.0

[PATCH 5/6] gnu: Add ceph.

[Marius Bakke]

* gnu/packages/distributed-filesystems.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
---
 gnu/local.mk |   1 +
 gnu/packages/distributed-filesystems.scm | 172 +++
 2 files changed, 173 insertions(+)
 create mode 100644 gnu/packages/distributed-filesystems.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index 81d774eb6..417e7a0a5 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -102,6 +102,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/dillo.scm   \
   %D%/packages/disk.scm\
   %D%/packages/display-managers.scm\
+  %D%/packages/distributed-filesystems.scm \
   %D%/packages/django.scm  \
   %D%/packages/djvu.scm\
   %D%/packages/dns.scm \
diff --git a/gnu/packages/distributed-filesystems.scm 
b/gnu/packages/distributed-filesystems.scm
new file mode 100644
index 0..f215a847e
--- /dev/null
+++ b/gnu/packages/distributed-filesystems.scm
@@ -0,0 +1,172 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2017 Marius Bakke <mba...@fastmail.com>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages distributed-filesystems)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu)
+  #:use-module (gnu packages bdw-gc)
+  #:use-module (gnu packages boost)
+  #:use-module (gnu packages compression)
+  #:use-module (gnu packages crypto)
+  #:use-module (gnu packages curl)
+  #:use-module (gnu packages databases)
+  #:use-module (gnu packages gnuzilla)
+  #:use-module (gnu packages jemalloc)
+  #:use-module (gnu packages linux)
+  #:use-module (gnu packages openldap)
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages tls)
+  #:use-module (gnu packages web)
+  #:use-module (gnu packages xml))
+
+(define-public ceph
+  (package
+(name "ceph")
+(version "10.2.5")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://download.ceph.com/tarballs/ceph-;
+  version ".tar.gz"))
+  (sha256
+   (base32
+"1x6m69il34x4rjhybk5cpw4yiad4a193l9vgy57vidwfy5ql5pc2"))
+  (modules '((guix build utils)))
+  (snippet
+   '(begin
+  ;; Delete bundled software.
+  (delete-file-recursively "src/test/downloads") ; python-cram
+  (delete-file-recursively "src/rocksdb")
+  ;; TODO: unbundle gtest, civetweb, DPDK, SPDK, xxHash.
+  #t
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+   (list (string-append "--exec_prefix=" (assoc-ref %outputs "out"))
+ (string-append "--libdir=" (assoc-ref %outputs "lib") "/lib")
+ (string-append "--includedir=" (assoc-ref %outputs "lib") 
"/include")
+ "--localstatedir=/var"
+ "--sysconfdir=/etc"
+ "--enable-static=no" ; TODO: separate output
+ "--with-man-pages"
+ (string-append "--with-systemd-unit-dir="
+(assoc-ref %outputs "out") "/etc/systemd/system")
+ "--without-libxfs" ; TODO: enable when xfsprogs is added.
+ ;; Use jemalloc instead of tcmalloc.
+ "--with-jemalloc")
+   #:make-flags
+   ;; Pass sysconfdir here too so that the sample configuration files
+   ;; and directories are installed to the output instead of root level.
+   (list (string-append "sysconfdir=" (assoc-ref %outputs "out") "/etc")
+ (string-append "LDFLAGS=-Wl,-rpath="
+(assoc-ref %outputs "lib") "/lib")
+ ;; The python libraries depend on the ceph libraries,
+

[PATCH 2/6] gnu: Add crypto++.

[Marius Bakke]

* gnu/packages/crypto.scm (crypto++): New variable.
---
 gnu/packages/crypto.scm | 90 -
 1 file changed, 89 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/crypto.scm b/gnu/packages/crypto.scm
index e4a8a4bd5..2bf64f1f6 100644
--- a/gnu/packages/crypto.scm
+++ b/gnu/packages/crypto.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2016 Tobias Geerinckx-Rice <m...@tobias.gr>
 ;;; Copyright © 2016 ng0 <n...@we.make.ritual.n0.is>
 ;;; Copyright © 2016 Eric Bavier <bav...@member.fsf.org>
+;;; Copyright © 2017 Marius Bakke <mba...@fastmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -46,12 +47,99 @@
   #:use-module (gnu packages tcl)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages xml)
+  #:use-module (gnu packages zip)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix git-download)
   #:use-module (guix build-system cmake)
-  #:use-module (guix build-system gnu))
+  #:use-module (guix build-system gnu)
+  #:use-module (guix utils)
+  #:use-module (srfi srfi-26)
+  #:use-module (ice-9 match))
+
+(define-public crypto++
+  (package
+(name "crypto++")
+(version "5.6.5")
+(source (origin
+  (method url-fetch)
+  (uri (let ((numeric-version
+  (match (string-split version #\.)
+((first-digit other-digits ...)
+ (string-append first-digit
+(string-concatenate
+ other-digits))
+ (string-append "https://cryptopp.com/cryptopp;
+numeric-version ".zip")))
+  (sha256
+   (base32
+"0d1cqdz369ivi082k59025wvxzywvkizw7i0pf5h0a1izs3g8pm7"
+(build-system gnu-build-system)
+(arguments
+ `(#:make-flags
+   (list (string-append "PREFIX=" (assoc-ref %outputs "out"))
+ (string-append "BINDIR=" (assoc-ref %outputs "bin") "/bin")
+ (string-append "DATADIR=" (assoc-ref %outputs "doc") "/share")
+ "DISABLE_CXXFLAGS_OPTIMIZATIONS=1"
+ ;; Override "/sbin/ldconfig" with simply "echo" since
+ ;; we don't need ldconfig(8).
+ "LDCONF=echo")
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'enter-source
+   ;; ??? Why are we in the TestData folder.
+   (lambda _ (chdir "..") #t))
+ (add-after 'enter-source 'disable-optimizations
+   (lambda _
+ ;; XXX: The disable optimizations flag above is not recognized in
+ ;; the current version. See 
https://github.com/weidai11/cryptopp/pull/354 .
+ ;; For now, just remove it the dirty way.
+ (substitute* "GNUmakefile"
+   (("-march=native") ""))
+ #t))
+ (delete 'configure)
+ (add-after 'build 'build-shared
+   (lambda _
+ ;; By default, only the static library is built.
+ (zero? (system* "make" "shared"
+ (add-after 'install 'move-static-library
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(lib (string-append out "/lib"))
+(static (assoc-ref outputs "static"))
+(slib (string-append static "/lib")))
+   (mkdir-p slib)
+   (for-each (lambda (file)
+   (install-file file slib)
+   (delete-file file))
+ (find-files lib "\\.l?a$"))
+   #t)))
+ (add-after 'move-static-library 'add-so-version-symlink
+   ;; The library is named MAJOR.MINOR.PATCHLEVEL. Some programs
+   ;; expect a MAJOR.MINOR symlink.
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out"))
+   (major+minor ,(version-major+minor version)))
+   (with-directory-excursion (string-append out "/lib")
+ (symlink (string-append "libcryptopp.so." ,version)
+  (string-append "libcryptopp.so." major+minor))
+ #t)))
+(outputs '("out"  ; 6.4M shared library and headers
+   "bin"  ; 6.3M cryptest.exe
+   "doc"  ; 6.4M documentation and examples
+   "static"))

Re: [PATCH] gnu: Add ghc-flac.

[Marius Bakke]

Danny Milosavljevic  writes:

> * gnu/packages/haskell.scm (ghc-flac): New variable.

Cool!

[...]

> +(native-inputs
> + `(("ghc-hspec" ,ghc-hspec)
> +   ("hspec-discover" ,hspec-discover)))

Are these referenced by the built product? If so, they should be in
[inputs]. You can check references with `guix gc -R`, or try something
like `guix graph -t references ghc-flac | dot -T png | feh -` for a tree
view. Or grep the store paths for a "shotgun" approach :-)

The indentation is off some places, but otherwise this LGTM.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add notmuch-vim.

[Marius Bakke]

ng0 <n...@libertad.pw> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> ng0 <n...@libertad.pw> writes:
>>
>>> * gnu/packages/vim.scm (notmuch-vim): New variable.
>>
>> Thanks for this! I tried installing this plugin, but get an error while
>> loading it according to upstream instructions[0]:
>>
>> Error detected while processing command line:
>> E492: Not an editor command: :NotMuch 
>>
>> Any ideas? The README seems to suggest this depends on the notmuch ruby
>> bindings as well, which is not currently built on Guix. How did you test
>> this?
>
> I really assumed that vim-full provides the ruby bindings and
> that they meant just just, and not just another bindings
> set. Grml... Okay.

I suspect we just need to package 'ruby-notmuch' in a similar vein to
'python-notmuch' and propagate it with the plugin. Possibly also make
sure the 'ruby' executable is referenced by vim/this plugin.

> Do you use vim? I don't do so currently, so I assumed it just works
> when it copied.

I don't use vim often, but when I do, it's to try out plugins from
software I trust ;-) it's more fun when it works, though.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add emacs-aggresive-indent-mode.

[Marius Bakke]

Vasile Dumitrascu  writes:

> * gnu/packages/emacs.scm (emacs-aggresive-indent-mode): New variable.

Thanks!

> ---
>  gnu/packages/emacs.scm | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 547c44033..301552839 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -1066,6 +1066,31 @@ like.  It can be linked with various Emacs mail
> clients (Message and Mail
>  mode, Rmail, Gnus, MH-E, and VM).  BBDB is fully customizable.")
>  (license license:gpl3+)))
>
> +(package

Hmm. This should be enclosed in a 'define-public' block.

> +  (name "emacs-aggresive-indent-mode")
  ^^^

There should be an extra 's' here. Also '-mode' can be dropped.


> +  (version "1.8.3")
> +  (source
> +   (origin
> + (method url-fetch)
> + (uri (string-append "https://elpa.gnu.org/packages/;
> + "aggressive-indent-" version ".el"))
> + (sha256
> +  (base32
> +   "0jnzccl50x0wapprgwxinp99pwwa6j43q6msn4gv437j7swy8wnj"
> +  (build-system emacs-build-system)
> +  (home-page "https://elpa.gnu.org/packages/aggressive-indent.html;)
> +  (synopsis "Minor mode to aggressively keep your code always indented")
> +  (description
> +   "`electric-indent-mode' is enough to keep your code nicely aligned when
> +all you do is type.  However, once you start shifting blocks around,
> +transposing lines, or slurping and barfing sexps, indentation is bound
> +to go wrong.
> +
> +`aggressive-indent-mode' is a minor mode that keeps your code always
> +indented.  It reindents after every change, making it more reliable
> +than `electric-indent-mode'.")

The quotes in the description should be replaced with @code{} blocks.
Running `./pre-inst-env guix lint emacs-aggressive-indent` should warn
about this. I also think that the second paragraph is sufficient.

Can you send an updated patch? Please also add a copyright line for
yourself at the top of the file.

TIA!


> +  (license gpl2+))
> +
>  (define-public emacs-async
>(package
>  (name "emacs-async")
> -- 
> 2.11.0


signature.asc
Description: PGP signature

Re: wrong key used for signing

[Marius Bakke]

Thomas Danckaert  writes:

> I accidentally used the wrong key when signing my commits to 
> core-updates yesterday.  How can I fix this? A number of commits were 
> already made on top of mine, so we'd need to rebase?

If you can send a signed message (using key D77D54FD according to my
books) containing the public key of the key used to sign these commits
(so they can be verified), I think that is proof enough. Assuming you
admit to making them, of course :-)

> These are the offending commits:
>
> b1a8fd2d2 gnu: libreoffice: Update to 5.3.1.2.
> 90ac806d3 gnu: orcus: Update to 0.12.1.
> b85b56dd7 gnu: libetonyek: Update to 0.1.6.
> 22e52dbd0 gnu: Add libstaroffice.
> cb3864392 gnu: ixion: Update to 0.12.2.
> 57144094b gnu: mdds: Upgrade to 1.2.2.
> 741916f11 gnu: Add libzmf.
>
> Thomas


signature.asc
Description: PGP signature

Re: wrong key used for signing

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> Thomas Danckaert <p...@thomasdanckaert.be> writes:
>
>> I accidentally used the wrong key when signing my commits to 
>> core-updates yesterday.  How can I fix this? A number of commits were 
>> already made on top of mine, so we'd need to rebase?
>
> If you can send a signed message (using key D77D54FD according to my
> books) containing the public key of the key used to sign these commits
> (so they can be verified), I think that is proof enough. Assuming you
> admit to making them, of course :-)

To be clear, simply "vouching" for the commits in a signed message is
good enough for me. It would be good to have the signing key for future
reference, but if you don't want to disclose it I'm fine with that.


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Leo Famulari  writes:

> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>> So, here’s a plan:
>> 
>>   • Once Efraim has pushed some of the aarch64 patches, do another
>> evaluation of the “core” package set for that branch, and check for
>> anything wrong.  From there on, forbid full-rebuild changes.
>> 
>>   • Once the “core” subset builds correctly on all the supported
>> platforms (those that Hydra supports), merge ‘master’.  Maybe update
>> a couple of things like GnuTLS while we’re at it.  From there on
>> forbid non-trivial changes.
>> 
>>   • Build all the packages.  (To do that, someone with access to Hydra
>> must change the “subset” argument to “all” in the config of the
>> ‘core-updates’ jobset.)
>> 
>>   • Fix things.
>
> We are at this stage... please help :)

Checking in for duty! o7

Here are the results of the latest evaluation:

https://hydra.gnu.org/eval/109570?full=1=master#tabs-now-fail

I cannot reproduce these failures, please try restarting the jobs:

https://hydra.gnu.org/job/gnu/core-updates/c-graph-2.0.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/express-beta-diversity-1.0.7.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/gdm-3.22.1.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/gengetopt-2.22.6.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/libutf-0.0.0-1.ff4c606.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/mupdf-1.10a.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/ghc-mockery-0.3.2.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/gst-plugins-good-1.10.4.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/python-lit-0.5.0.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/ruby-concurrent-1.0.2.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/wcslib-5.16.i686-linux

With those out of the way, here are most remaining problems on x86_64:

* aegis
* discrover
* clang-3.5.2 (can this be removed?)
* elixir
* gcc-4.7.4 (likewise)
* glog
* a handful of guile libraries
* hugs (abondoned upstream, no users, remove?)
* khmer
* kodi
* ldc
* powertabeditor
* pspp
* scalapack
* stringtie
* swish-e
* vim-full

Once most of these are fixed, I think we're ready to merge!

Kodi is very interesting, most tests take <1s on 'master', but almost
every test take ~30s on 'core-updates' and invariably segfaults. Any
idea what might be going on?

Likewise, one "vim-full" test is failing on 'core-updates' for no good
reason. I would create an upstream issue if I had any idea what might be
causing it :)

Powertabeditor is likely fixed by an update, but I haven't tried it yet.
Any takers?

For the rest.. please share your findings!


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> Here are the results of the latest evaluation:
>
> https://hydra.gnu.org/eval/109570?full=1=master#tabs-now-fail

[...]

> With those out of the way, here are most remaining problems on x86_64:
>
> * aegis
> * discrover
> * clang-3.5.2 (can this be removed?)
> * elixir
> * gcc-4.7.4 (likewise)
> * glog
> * a handful of guile libraries
> * hugs (abondoned upstream, no users, remove?)
> * khmer
> * kodi
> * ldc
> * powertabeditor
> * pspp
> * scalapack
> * stringtie
> * swish-e
> * vim-full

There is at least one other important package failing: "greenisland". I
wonder why it's no longer listed on the Hydra page.

Anyway, halp wanted :-)


signature.asc
Description: PGP signature

Re: [PATCH 0/1] QEMU 2.9.0-rc1

[Marius Bakke]

Leo Famulari  writes:

> This is just a release candidate, but it does boot the GuixSD release
> image.
>
> I'm sharing it so that people can get early access to the bug fixes it
> includes.
>
> Leo Famulari (1):
>   gnu: qemu: Update to 2.9.0-rc1 [security fixes].

I think it would be nice to have this in Guix proper (as a separate
variable), so users don't have to apply this patch and build it
manually. The downside is that it would land in users' profiles unless
they take steps to prevent it, but I'm not sure how much of a problem
that is given how easy it is to roll-back or exclude it. Thoughts?


signature.asc
Description: PGP signature

Re: kodi: LD_LIBRARY_PATH vs. RUNPATH

[Marius Bakke]

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

> Hi Marius,
>
> mba...@fastmail.com (Marius Bakke) skribis:
>
>> commit 4b9a5bd990a4c734828571147f9fec01c7053fcc
>> Author: Marius Bakke <mba...@fastmail.com>
>> Date:   Tue Mar 21 07:02:36 2017 +0100
>>
>> gnu: kodi: Wrap executable so it finds libcurl.
>> 
>> * gnu/packages/kodi.scm (kodi)[arguments]: Add 'wrap' phase.
>
> [...]
>
>> + (add-after 'install 'wrap
>> +   (lambda* (#:key inputs outputs #:allow-other-keys)
>> + (let ((out (assoc-ref outputs "out"))
>> +   (curl (string-append (assoc-ref inputs "curl") "/lib")))
>> +   (wrap-program (string-append out "/bin/kodi")
>> + `("LD_LIBRARY_PATH" suffix (,curl)))
>> +   #t))
>
> I think it would be nicer to add libcurl to the RUNPATH of kodi, by
> adding -Wl,-rpath=/…/curl/lib to the LDFLAGS for the ‘kodi’ executable,
> rather than clobbering LD_LIBRARY_PATH (that’s more “controlled” and
> less intrusive).
>
> Perhaps that’s more complicated to do though (finding the right makefile
> or makefile variable to pass, etc.)
>
> WDYT?

I agree, this was a lazy fix on my part to enable some expected
functionality (scraping, add-ons) because I could not figure out how to
pass LDFLAGS (the environment variable was not enough).

Will work on a proper fix; adding it to the 'kodi-test' executable
should also sort the failing web tests, methinks.


signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> Patch attached. I *think* the two values are for client and server
> respectively, but will study the source and build logs some more to make
> sure we're adjusting the right knobs.
>
> I suggest we try this on 'core-updates' if the patch is correct.

The patch builds fine on x86_64, and I've verified that these are the
correct settings by decreasing the values instead of increasing.

What do you think? Should we check if 25s is high enough on
'core-updates' or push it directly to 'master'?

From 33bbf7bc60b222adc6effc7257440fd8222ef04b Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Tue, 14 Mar 2017 22:54:41 +0100
Subject: [PATCH] gnu: nss: Increase test timeouts.

* gnu/packages/patches/nss-increase-test-timeout.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/gnuzilla.scm (nss)[source]: Use it.
---
 gnu/local.mk   |  1 +
 gnu/packages/gnuzilla.scm  |  3 ++-
 .../patches/nss-increase-test-timeout.patch| 25 ++
 3 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/nss-increase-test-timeout.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index c1b076a5f..7fb22ebb5 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -780,6 +780,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/ninja-tests.patch			\
   %D%/packages/patches/ninja-zero-mtime.patch			\
   %D%/packages/patches/node-9077.patch\
+  %D%/packages/patches/nss-increase-test-timeout.patch		\
   %D%/packages/patches/nss-pkgconfig.patch			\
   %D%/packages/patches/ntfs-3g-CVE-2017-0358.patch		\
   %D%/packages/patches/nvi-assume-preserve-path.patch		\
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index e6e24f665..1d84e7a9a 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -199,7 +199,8 @@ in the Mozilla clients.")
(base32
 "149807rmzb76hnh48rw4m9jw83iw0168njzchz0hmbsgc8mk0i5w"))
   ;; Create nss.pc and nss-config.
-  (patches (search-patches "nss-pkgconfig.patch"
+  (patches (search-patches "nss-pkgconfig.patch"
+   "nss-increase-test-timeout.patch"
 (build-system gnu-build-system)
 (outputs '("out" "bin"))
 (arguments
diff --git a/gnu/packages/patches/nss-increase-test-timeout.patch b/gnu/packages/patches/nss-increase-test-timeout.patch
new file mode 100644
index 0..c6aac6ac0
--- /dev/null
+++ b/gnu/packages/patches/nss-increase-test-timeout.patch
@@ -0,0 +1,25 @@
+We've seen some tests take more than 20s to complete on a busy armhf
+machine. Even a busy x86_64 machine can use more than 5s on some tests.
+
+Increase timeouts to increase chances of a successful build.
+
+--- a/nss/gtests/ssl_gtest/tls_connect.cc	2017-03-14 22:47:30.855813629 +0100
 b/nss/gtests/ssl_gtest/tls_connect.cc	2017-03-14 22:48:49.042335273 +0100
+@@ -245,7 +245,7 @@
+ 
+   ASSERT_TRUE_WAIT((client_->state() != TlsAgent::STATE_CONNECTING) &&
+(server_->state() != TlsAgent::STATE_CONNECTING),
+-   5000);
++   25000);
+ }
+ 
+ void TlsConnectTestBase::EnableExtendedMasterSecret() {
+@@ -387,7 +387,7 @@
+   } else {
+ fail_agent = server_;
+   }
+-  ASSERT_TRUE_WAIT(fail_agent->state() == TlsAgent::STATE_ERROR, 5000);
++  ASSERT_TRUE_WAIT(fail_agent->state() == TlsAgent::STATE_ERROR, 25000);
+ }
+ 
+ void TlsConnectTestBase::ConfigureVersion(uint16_t version) {
-- 
2.12.0



signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Leo Famulari  writes:

> On Tue, Mar 14, 2017 at 05:02:12PM -0400, Mark H Weaver wrote:
>> This is not really sustainable.  A single build attempt takes 7 hours on
>> armhf, and about 40 hours on mips.  When the failure occurs, it causes
>> hundreds of other dependency failures, which must be restarted manually,
>> one at a time, via the web interface.  (We have a way to restart *all*
>> dependency failures, but that results in a huge amount of wasted work
>> for Hydra).
>> 
>> We need test suites to be robust on heavily loaded build machines.
>
> I agree that this situation is not sustainable. If we are committed to
> offering substitutes, we can't have such a critical package not building
> reliably.
>
> But, it seems unsatisfactory to not update NSS / nss-certs without
> working towards a real solution.
>
> Nss-certs provides the CA certificate store in Guix. It does get updated
> along with NSS [0], although not in every NSS release.
>
> I think we should find a way to decouple the certificate store from NSS,
> since we can't build NSS reliably.
>
>> Is there a compelling reason not to revert this update for now?
>
> Since there were no changes to the certificates between 3.29.2 and
> 3.29.3, I think it's fine to revert.

NSS is a crypto library in addition to a certificate store and 3.29.3
resolves a crash when TLS 1.3 is enabled. I don't know how serious this
issue is, but we should try to keep up on both packages.

Nevertheless, I've reverted the commits for now so the old substitutes
should be valid again.

Going forward, I wonder if there could be any unintended side effects by
simply increasing the timeouts in nss/gtests/ssl_gtest/tls_connect.cc
from 5000 ms to something like 2. If a 0-day is discovered in "nss",
we don't want to wait several days to get a successful build.


signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Tue, Mar 14, 2017 at 10:39:48PM +0100, Marius Bakke wrote:
>> Going forward, I wonder if there could be any unintended side effects by
>> simply increasing the timeouts in nss/gtests/ssl_gtest/tls_connect.cc
>> from 5000 ms to something like 2. If a 0-day is discovered in "nss",
>> we don't want to wait several days to get a successful build.
>
> If these failures seem to be timeout issues, I think we should try this.
> We do have other packages that make similar changes.

I'm currently building NSS (on x86_64) with timeouts increased from 5s
to 25s. The recent armhf test failure took 22725ms, and when we
struggled with 3.29.2 it took ~2ms too.

Patch attached. I *think* the two values are for client and server
respectively, but will study the source and build logs some more to make
sure we're adjusting the right knobs.

I suggest we try this on 'core-updates' if the patch is correct.

From c8e0b85953133328e27f0bfcc9a9a0330e36ce5a Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Tue, 14 Mar 2017 22:54:41 +0100
Subject: [PATCH] gnu: nss: Increase test timeouts.

* gnu/packages/patches/nss-increase-test-timeout.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/gnuzilla.scm (nss)[source]: Use it.
---
 gnu/local.mk |  1 +
 gnu/packages/gnuzilla.scm|  3 ++-
 gnu/packages/patches/nss-increase-test-timeout.patch | 20 
 3 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/nss-increase-test-timeout.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index c1b076a5f..7fb22ebb5 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -780,6 +780,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/ninja-tests.patch			\
   %D%/packages/patches/ninja-zero-mtime.patch			\
   %D%/packages/patches/node-9077.patch\
+  %D%/packages/patches/nss-increase-test-timeout.patch		\
   %D%/packages/patches/nss-pkgconfig.patch			\
   %D%/packages/patches/ntfs-3g-CVE-2017-0358.patch		\
   %D%/packages/patches/nvi-assume-preserve-path.patch		\
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index e6e24f665..1d84e7a9a 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -199,7 +199,8 @@ in the Mozilla clients.")
(base32
 "149807rmzb76hnh48rw4m9jw83iw0168njzchz0hmbsgc8mk0i5w"))
   ;; Create nss.pc and nss-config.
-  (patches (search-patches "nss-pkgconfig.patch"
+  (patches (search-patches "nss-pkgconfig.patch"
+   "nss-increase-test-timeout.patch"
 (build-system gnu-build-system)
 (outputs '("out" "bin"))
 (arguments
diff --git a/gnu/packages/patches/nss-increase-test-timeout.patch b/gnu/packages/patches/nss-increase-test-timeout.patch
new file mode 100644
index 0..76d4853ba
--- /dev/null
+++ b/gnu/packages/patches/nss-increase-test-timeout.patch
@@ -0,0 +1,20 @@
+--- a/nss/gtests/ssl_gtest/tls_connect.cc	2017-03-14 22:47:30.855813629 +0100
 b/nss/gtests/ssl_gtest/tls_connect.cc	2017-03-14 22:48:49.042335273 +0100
+@@ -245,7 +245,7 @@
+ 
+   ASSERT_TRUE_WAIT((client_->state() != TlsAgent::STATE_CONNECTING) &&
+(server_->state() != TlsAgent::STATE_CONNECTING),
+-   5000);
++   25000);
+ }
+ 
+ void TlsConnectTestBase::EnableExtendedMasterSecret() {
+@@ -387,7 +387,7 @@
+   } else {
+ fail_agent = server_;
+   }
+-  ASSERT_TRUE_WAIT(fail_agent->state() == TlsAgent::STATE_ERROR, 5000);
++  ASSERT_TRUE_WAIT(fail_agent->state() == TlsAgent::STATE_ERROR, 25000);
+ }
+ 
+ void TlsConnectTestBase::ConfigureVersion(uint16_t version) {
-- 
2.12.0



signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

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

> Marius Bakke <mba...@fastmail.com> skribis:
>
>> Marius Bakke <mba...@fastmail.com> writes:
>>
>>> Patch attached. I *think* the two values are for client and server
>>> respectively, but will study the source and build logs some more to make
>>> sure we're adjusting the right knobs.
>>>
>>> I suggest we try this on 'core-updates' if the patch is correct.
>>
>> The patch builds fine on x86_64, and I've verified that these are the
>> correct settings by decreasing the values instead of increasing.
>>
>> What do you think? Should we check if 25s is high enough on
>> 'core-updates' or push it directly to 'master'?
>
> Good catch.
>
> It might be best to push to ‘core-updates’ to focus our build
> resources.  No strong opinion though.

I pushed it to 'core-updates'.


signature.asc
Description: PGP signature

Re: GuixSD on servers… has someone used Hetzner dedicated servers before?

[Marius Bakke]

ng0  writes:

> Hi,
>
> later this year (once I have mailman functional) I want to add an
> dedicated server from Hetzner (http://hetzner.deto) my network.
>
> With IN-Berlin I have this out-of-console requirement for agetty.
>
> Does someone know what special requirement, if at all, Hetzner has?
> If no one knows it, I'll make a customer inquiry to check it.

I have a dedicated server from Hetzner and don't think they have any
special requirements. They offer VNC and a SSH-able (Debian) rescue
image. If I were to install GuixSD on it*, I would probably install the
binary inside the rescue image and do `guix system init` from there.

*because I haven't been able to package Ganeti for Guix yet**
** mostly due to https://github.com/haskell/cabal/issues/3728


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Ludovic Courtès  writes:

> Hi!
>
> It looks like we’re doing okay now?  There are still a number of
> armhf-linux builds pending, but if everything goes well, I think we
> should merge tomorrow (Sunday).  WDYT?

One "greenisland" test is segfaulting. This package is needed for the
"sddm" display manager, so I don't think we should merge until that is
sorted. I'm looking into it now, but struggling to produce useful
debugging information.

"vim-full" also has a failing test, but is arguably less important.
There are "relink" warnings during the test phase, like this:

Relink 
`/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' 
with 
`/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' 
for IFUNC symbol `longjmp'

...but I'm not sure if it's actually related.


signature.asc
Description: PGP signature

Re: Greenisland & SDDM

[Marius Bakke]

Ludovic Courtès  writes:

> Since, SDDM can be built without Greenisland (and thus without Wayland
> support I suppose), what about doing just that?

I suggested this in [0] and see now that I completely missed Leos reply.

Let's do that. No blockers left from my side, at least.

[0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26200


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> One "greenisland" test is segfaulting. This package is needed for the
> "sddm" display manager, so I don't think we should merge until that is
> sorted. I'm looking into it now, but struggling to produce useful
> debugging information.

Apparently "ctest" will invoke "gdb" for tests if available in PATH. The
stack trace was not very helpful to my untrained eye however..

Given that this software is abandoned upstream, I don't think it's worth
spending a lot of time on maintaining it (our Wayland is newer than the
latest Greenisland release). We'll eventually have to find another
Wayland compositor for SDDM, in the meantime I think it's okay to
disable this test. What do others think?

I've configured my system on 'core-updates' and can confirm that SDDM
works fine (after disabling greenisland tests).

Geronimo? :-)


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Ricardo Wurmus <rek...@elephly.net> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> "vim-full" also has a failing test, but is arguably less important.
>> There are "relink" warnings during the test phase, like this:
>>
>> Relink 
>> `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16'
>>  with 
>> `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' 
>> for IFUNC symbol `longjmp'
>>
>> ...but I'm not sure if it's actually related.
>
> Hmm, I’ve also seen this when running Lilypond!  I thought it was my
> fault.  I don’t know what this means.  Do we need to rebuild libpng?

I don't know either, but this topic was discussed recently at [0] and is
apparently a glibc regression [1].

We should probably open a bug for tracking it, since there is likely
more software affected in Guix.

[0] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00626.html
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21041


signature.asc
Description: PGP signature

Re: 04/05: gnu: xorg-server: Update to 1.19.3.

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Thu, Apr 06, 2017 at 10:04:12AM -0400, Marius Bakke wrote:
>> mbakke pushed a commit to branch staging
>> in repository guix.
>> 
>> commit 7c42cc7738cb28f393b17f9074a264607456c012
>> Author: Marius Bakke <mba...@fastmail.com>
>> Date:   Thu Apr 6 15:42:15 2017 +0200
>> 
>> gnu: xorg-server: Update to 1.19.3.
>> 
>> * gnu/packages/xorg.scm (xorg-server, xorg-server-xwayland): Update to 
>> 1.19.3.
>> [native-inputs]: Remove FONT-UTIL, LIBTOOL, AUTOMAKE and AUTOCONF.
>> [arguments]: Remove 'bootstrap' phase.
>
> This can go straight to master, right?

I don't think so, because of the inputs and arguments change, which
would affect xorg-server-1.19.2 as well (and cause the build to fail).

Commit 3433413b18f02436eb8459d097947257ac6973f7 addresses this, so
future xorg-server updates should indeed be eligible for 'master'.


signature.asc
Description: PGP signature

Re: 02/02: gnu: certbot: Share python-acme's arguments.

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> lfam pushed a commit to branch master
> in repository guix.
>
> commit f26d6e4e9c5efbe060697f54456cfc9144350114
> Author: Leo Famulari <l...@famulari.name>
> Date:   Sat Apr 8 12:45:16 2017 -0400
>
> gnu: certbot: Share python-acme's arguments.
> 
> * gnu/packages/tls.scm (certbot)[arguments]: Use 
> substitute-keyword-arguments to
> inherit from python-acme.
> ---
>  gnu/packages/tls.scm | 39 +++
>  1 file changed, 15 insertions(+), 24 deletions(-)
>
> diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
> index ac5e406..08cc607 100644
> --- a/gnu/packages/tls.scm
> +++ b/gnu/packages/tls.scm
> @@ -478,8 +478,6 @@ security, and applying best practice development 
> processes.")
>  "05cqadwzgfcianw3v0qxwja65dxnzw429f7dk8w0mnh21pib72bl"
>  (build-system python-build-system)
>  
> -;; TODO factorize the 'docs' phase and share arguments between 
> python-acme
> -;; and certbot.
>  (arguments
>   `(#:phases
> (modify-phases %standard-phases
> @@ -541,28 +539,21 @@ security, and applying best practice development 
> processes.")
>  (build-system python-build-system)
>  (arguments
>   `(#:python ,python-2
> -   #:phases
> -   (modify-phases %standard-phases
> - (add-after 'unpack 'patch-dependency
> -   ;; This module is part of the Python standard library, so we don't
> -   ;; need to use an external package.
> -   ;; https://github.com/certbot/certbot/pull/2249
> -   (lambda _
> - (substitute* "setup.py"
> -   (("'argparse',") ""))
> - #t))
> - (add-after 'build 'docs
> -   (lambda* (#:key outputs #:allow-other-keys)
> - (let* ((out (assoc-ref outputs "out"))
> -(man1 (string-append out "/share/man/man1"))
> -(man7 (string-append out "/share/man/man7"))
> -(info (string-append out "/info")))
> -   (and
> - (zero? (system* "make" "-C" "docs" "man" "info"))
> - (install-file "docs/_build/texinfo/Certbot.info" info)
> - (install-file "docs/_build/man/certbot.1" man1)
> - (install-file "docs/_build/man/certbot.7" man7)
> - #t)))
> +   ,@(substitute-keyword-arguments (package-arguments python-acme)
> +   ((#:phases phases)
> +`(modify-phases ,phases
> +  (replace 'docs
> +(lambda* (#:key outputs #:allow-other-keys)
> +  (let* ((out (assoc-ref outputs "out"))
> + (man1 (string-append out "/share/man/man1"))
> + (man7 (string-append out "/share/man/man7"))
> + (info (string-append out "/info")))
> +(and
> +  (zero? (system* "make" "-C" "docs" "man" "info"))
> +  (install-file "docs/_build/texinfo/Certbot.info" info)
> +  (install-file "docs/_build/man/certbot.1" man1)
> +  (install-file "docs/_build/man/certbot.7" man7)
> +  #t)

Not to pick on this patch, since this problem was present before..but:

"install-file" has an unspecified return value, so I don't think it's
safe to use in an "and" block. The attached patch should be more
correct. WDYT?

From e3bd8d6df932986c35a2f8088c491eb6f89ee6d5 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Mon, 10 Apr 2017 00:26:45 +0200
Subject: [PATCH] gnu: certbot, python-acme: Build documentation in separate
 phase.

* gnu/packages/tls.scm (python-acme)[arguments]<:phases>: Add
'build-documentation' phase. Rename 'docs' phase to 'install-documentation'.
(certbot)[arguments]<:phases>: Adjust accordingly.
---
 gnu/packages/tls.scm | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 08cc6075b..7b7de01cb 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -489,15 +489,17 @@ security, and applying best practice development processes.")
  (substitute* "setup.py"
(("'argparse',") ""))
  #t))
- (add-after 'build 'docs
+ (add-after 'build 'build

Re: NSS test failure on armhf

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

>>> It turns out that the bug fix in 3.30.1 is critical: it fixes
>>> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
>>> has since been released, so I'm currently testing it and will push an
>>> update to it soon.  Any issues on armhf will need to be dealt with in
>>> another way.
>>
>> Mark,
>>
>> I checked this. The upstream 3.30 branch[0] contains a fix, but it was
>> not picked to the 3.30.2 release which only contains certificate
>> changes[1].
>>
>> Squashing these two commits into one should fix the problem (the first
>> fix was incomplete[2]):
>>
>> https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
>> https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7
>
> Here is a patch that updates to 3.30.1 and disables the b64 test.
>
> I'm building it on x86_64 now, but think it should be safe to push.
>
> What do you think?
>
> From 7f1a8eda567edb851e0f2cd1f08c6ac07e8a45cd Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mba...@fastmail.com>
> Date: Thu, 20 Apr 2017 21:36:21 +0200
> Subject: [PATCH] gnu: nss: Update to 3.30.1 [fixes CVE-2017-5461].
>
> * gnu/packages/patches/nss-disable-b64_unittest.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/gnuzilla.scm (nss): Update to 3.30.1.
> [source]: Use it.

This built successfully on x86_64. Here's an excerpt from the log:

'B64EncodeDecodeTest: DISABLED_LongFakeDecTest1' SKIPPED
'B64EncodeDecodeTest: DISABLED_LongFakeEncDecTest1' SKIPPED
'B64EncodeDecodeTest: DISABLED_LongFakeEncDecTest2' SKIPPED

Are you currently building a version of this patch on armhf? If not I'd
like to push it.


signature.asc
Description: PGP signature

Re: NSS test failure on armhf

[Marius Bakke]

Mark H Weaver <m...@netris.org> writes:

> Leo Famulari <l...@famulari.name> writes:
>
>> On Mon, Apr 17, 2017 at 11:23:43PM +0200, Marius Bakke wrote:
>>> Hello!
>>> 
>>> Since version 3.30.1, one test consistently fails on armhf. It is the
>>> same as in this bug report, although we don't see the exception:
>>> 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1351459
>>> 
>>> I initially thought this was due to stalls in the build process as we've
>>> seen before and tried increasing the timeouts in a790f2620, but that
>>> should probably be reverted.
>>> 
>>> What should we do? We can either patch out this test, or go back to
>>> 3.30. Here are the release notes for 3.30.1:
>>> 
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30.1_release_notes
>>> 
>>> It fixes a non-public bug in the base64 implementation, but introduced a
>>> test failure on at least two arches.
>>> 
>>> Any preference?
>>
>> Since there were no changes to the set of certificates between 3.30 and
>> 3.30.1 [0], I would revert it for now.
>
> It turns out that the bug fix in 3.30.1 is critical: it fixes
> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
> has since been released, so I'm currently testing it and will push an
> update to it soon.  Any issues on armhf will need to be dealt with in
> another way.

Mark,

I checked this. The upstream 3.30 branch[0] contains a fix, but it was
not picked to the 3.30.2 release which only contains certificate
changes[1].

Squashing these two commits into one should fix the problem (the first
fix was incomplete[2]):

https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7

[0] https://hg.mozilla.org/projects/nss/shortlog/NSS_3_30_BRANCH
[1] 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30.2_release_notes
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1351459#c6


signature.asc
Description: PGP signature

Re: NSS test failure on armhf

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> Mark H Weaver <m...@netris.org> writes:
>
>> Leo Famulari <l...@famulari.name> writes:
>>
>>> On Mon, Apr 17, 2017 at 11:23:43PM +0200, Marius Bakke wrote:
>>>> Hello!
>>>> 
>>>> Since version 3.30.1, one test consistently fails on armhf. It is the
>>>> same as in this bug report, although we don't see the exception:
>>>> 
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1351459
>>>> 
>>>> I initially thought this was due to stalls in the build process as we've
>>>> seen before and tried increasing the timeouts in a790f2620, but that
>>>> should probably be reverted.
>>>> 
>>>> What should we do? We can either patch out this test, or go back to
>>>> 3.30. Here are the release notes for 3.30.1:
>>>> 
>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30.1_release_notes
>>>> 
>>>> It fixes a non-public bug in the base64 implementation, but introduced a
>>>> test failure on at least two arches.
>>>> 
>>>> Any preference?
>>>
>>> Since there were no changes to the set of certificates between 3.30 and
>>> 3.30.1 [0], I would revert it for now.
>>
>> It turns out that the bug fix in 3.30.1 is critical: it fixes
>> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
>> has since been released, so I'm currently testing it and will push an
>> update to it soon.  Any issues on armhf will need to be dealt with in
>> another way.
>
> Mark,
>
> I checked this. The upstream 3.30 branch[0] contains a fix, but it was
> not picked to the 3.30.2 release which only contains certificate
> changes[1].
>
> Squashing these two commits into one should fix the problem (the first
> fix was incomplete[2]):
>
> https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
> https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7

Here is a patch that updates to 3.30.1 and disables the b64 test.

I'm building it on x86_64 now, but think it should be safe to push.

What do you think?

From 7f1a8eda567edb851e0f2cd1f08c6ac07e8a45cd Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Thu, 20 Apr 2017 21:36:21 +0200
Subject: [PATCH] gnu: nss: Update to 3.30.1 and disable failing test [fixes
 CVE-2017-5461].

* gnu/packages/patches/nss-disable-b64_unittest.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/gnuzilla.scm (nss): Update to 3.30.1.
[source]: Use it.
---
 gnu/local.mk   |  1 +
 gnu/packages/gnuzilla.scm  |  5 +--
 .../patches/nss-disable-b64_unittest.patch | 40 ++
 3 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 gnu/packages/patches/nss-disable-b64_unittest.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index f38126251..d17f139a5 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -803,6 +803,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/ngircd-handle-zombies.patch		\
   %D%/packages/patches/ninja-zero-mtime.patch			\
   %D%/packages/patches/node-9077.patch\
+  %D%/packages/patches/nss-disable-b64_unittest.patch		\
   %D%/packages/patches/nss-increase-test-timeout.patch		\
   %D%/packages/patches/nss-pkgconfig.patch			\
   %D%/packages/patches/ntfs-3g-CVE-2017-0358.patch		\
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index 87695329c..21902b427 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -194,7 +194,7 @@ in the Mozilla clients.")
 (define-public nss
   (package
 (name "nss")
-(version "3.30")
+(version "3.30.1")
 (source (origin
   (method url-fetch)
   (uri (let ((version-with-underscores
@@ -205,9 +205,10 @@ in the Mozilla clients.")
   "nss-" version ".tar.gz")))
   (sha256
(base32
-"1agkkwb51si4raw46p44vl3d0l7wzvdjcblpcdjjz6aymq6h1h58"))
+"1djypq081m22iw0wg0q7gnpndam5f8qjhqfd5v9by4c6l6lp78hz"))
   ;; Create nss.pc and nss-config.
   (patches (search-patches "nss-pkgconfig.patch"
+   "nss-disable-b64_unittest.patch"
"nss-increase-test-timeout.patch"
 (build-system gnu-build-system)
 (outputs '("out" "bin"))
diff --git a/gnu/packages/patches/nss-disable-b64_unittest.patch b/gnu/packages/patches/nss-disable-b64_unittest.patch
new file mode 100644
index 0..8d2f1deb7
--- /dev/null
+++ b/gnu/p

Re: NSS test failure on armhf

[Marius Bakke]

Mark H Weaver <m...@netris.org> writes:

> Marius Bakke <mba...@fastmail.com> writes:
>
>> Marius Bakke <mba...@fastmail.com> writes:
>>
>>>>> It turns out that the bug fix in 3.30.1 is critical: it fixes
>>>>> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
>>>>> has since been released, so I'm currently testing it and will push an
>>>>> update to it soon.  Any issues on armhf will need to be dealt with in
>>>>> another way.
>>>>
>>>> Mark,
>>>>
>>>> I checked this. The upstream 3.30 branch[0] contains a fix, but it was
>>>> not picked to the 3.30.2 release which only contains certificate
>>>> changes[1].
>>>>
>>>> Squashing these two commits into one should fix the problem (the first
>>>> fix was incomplete[2]):
>>>>
>>>> https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
>>>> https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7
>
> Good find, thank you!  Since seeing the above post, I prepared my own
> patches to update NSS to 3.30.2 and disable the long b64 tests.
>
> And now I see you've prepared your own patch that only updates to
> 3.30.1.  I'm not sure why we would consider rebuilding everything with
> 3.30.1 when 3.30.2 already exists, even if the only changes are to
> certs.
>
> I'll push this batch of patches soon, including fixes to graphite2 and
> the icecat update, after a bit more testing.

Great, thanks! I could not find any compelling reason to use the 3.30.2
tarball (other than disk space on builders), and found the version
"mismatch" with between 'nss-certs' and 'nss' more distinctive.

However, after diffing 3.30.1 and 3.30.2, it seems certificate changes
also bump the library version:

https://hg.mozilla.org/projects/nss/diff/dc97a4930479/lib/ckfw/builtins/nssckbi.h

So I guess we should keep updating these together to the extent possible.


signature.asc
Description: PGP signature

Re: Staging

[Marius Bakke]

Looks like the queue was cancelled.

https://hydra.gnu.org/eval/109614?compare=master

Should we try to build out the remaining packages? There have been a few
large updates in 'master', might be useful to merge that first. Or just
go the other way around.. ;-)


signature.asc
Description: PGP signature

Re: [PATCH] gnu: add meson

[Marius Bakke]

Corentin Bocquillon  writes:

> * gnu/packages/meson.scm (meson.scm) Add meson package.

Hello! Thanks for this patch. See comments inline.

Could you send the updated patch to "guix-patc...@gnu.org"?

Please also create the patch with `git format-patch` and either send it
as attachment or through `git send-email` so the formatting is
preserved. Thanks in advance!

> ---
>  gnu/packages/meson.scm | 47
> +++ 1 file changed, 47 
> insertions(+)
> create mode 100644 gnu/packages/meson.scm

Maybe this could go in "build-tools.scm" instead of creating a new module.

> +(define-public meson
> +  (package
> +(name "meson")
> +(version "0.39.1")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append
> "https://github.com/mesonbuild/meson/;
> +  "archive/" version ".tar.gz"))
> +  (file-name (string-append name "-" version ".tar.gz"))
> +  (sha256
> +   (base32
> +
> "1jwgd6sl7zl7h16id3405gwk6vlkk86ggwrp0k47njwkxmryq8d4"
> +(build-system python-build-system)
> +(inputs `(("python" ,python)

"python" is an implicit input when using python-build-system, so that
can be omitted.

> +  ("ninja", ninja)))
> +(home-page "https://mesonbuild.com/;)
> +(synopsis "Meson build system")
> +(description
> + "The meson build system is focused on user-friendliness and
> speed.")

Can you expand on this a little? What makes it different, what are the
use cases etc? It would also be good to see a package that uses it, but
I guess that is coming later ;-)

Looks good otherwise, apart from the formatting!


signature.asc
Description: PGP signature

Re: A simple workflow for adding apps guix

[Marius Bakke]

Feng Shu  writes:

> The below is the workflow I used current, any other
> simpler workflow exists?  comments are welcome!

Hello! If you intend to submit these packages, I would recommend working
directly from the main git repository rather than messing with
GUIX_PACKAGE_PATH. Have a look at the "Running Guix before it is
installed" section in the manual:

https://www.gnu.org/software/guix/manual/guix.html#Running-Guix-Before-It-Is-Installed

There is a 'pre-inst-env' script that makes testing local changes easy.
Here is my typical workflow (motley gear optional):

# Start with a clean master branch.
$ git checkout master
$ git pull # sometimes "--rebase" or simply `git reset --hard`..
# Create environment with all Guix dependencies.
$ ge guix # "ge" is an alias for `guix environment`...
# If this is a new machine, prepare the sources for this environment.
$ ./bootstrap
$ ./configure --localstatedir=/var
# Now compile everything. This is typically done after each `pull`.
$ make -j10
# Phew! Now let's start working on our package.
$ git checkout -b package-foo

$ ./pre-inst-env guix build foo # installing works too
# It builds! Let's commit it.
$ git add -p
$ git commit
# D'oh! Something was not right.
$ ./pre-inst-env guix edit foo # I don't actually use this, but..
$ ./pre-inst-env guix build foo
# Great, this looks better.
$ git add -p
$ git commit --amend # or --fixup= for later rebasing..

# Allright, now we can submit it!
$ mkdir outgoing # Not really necessary, but easier to "clean".
$ git format-patch --cover-letter -n origin/master -o outgoing/
$ edit outgoing/-cover-letter.patch
# Cover letter can be omitted, but is a good way to give some background
# info, raise questions, etc. Now, let's send it to open a bug report.
$ git send-email --to guix-patc...@gnu.org outgoing/-cover-letter.patch
# Now we have a bug URL! Let's send the remainder there.
$ rm outgoing/-cover-letter.patch
$ git send-email --to nn...@debbugs.gnu.org outgoing/*.patch

You can also make ~/.config/guix/latest a soft link to your git checkout
and largely avoid the need for `./pre-inst-env`. I don't actually do
that on my main development machine, since I need the `guix` command to
always work, and my work tree is rarely "sane" :P instead, I manage my
entire profile through `./pre-inst-env` and run `guix pull` once per
week or so. I've been meaning to try git-worktree(1) instead.

Hope it helps! Always interesting to see other workflows :)


signature.asc
Description: PGP signature

Re: Staging

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Mon, Apr 17, 2017 at 09:33:12PM +0200, Marius Bakke wrote:
>> @Leo, others: I don't anticipate more staging updates in a while, should
>> we try and get this merged?
>
> Sure, I merged master into staging and started an evaluation of the
> staging branch.

"mesa" failed the same test on both i686 and armhf:

https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.i686-linux
https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.armhf-linux

Oddly, I'm not able to reproduce it when compiling on x86_64:

$ ./pre-inst-env guix build --system=i686-linux mesa
[...]
/gnu/store/kkpq84ki2ipjcn9nhywgm2ww9c5ddlaq-mesa-17.0.4

Can someone with a native machine get the "test-suite.log" of the
failing test?

I pushed a patch that should hopefully fix the "libsndfile" 1.0.28 armhf
failure. We should probably pick it to the graft on 'master' if it
works and staging drags out.


signature.asc
Description: PGP signature

Re: Staging

[Marius Bakke]

The master queue has cleared, so let's get this started again :)


signature.asc
Description: PGP signature

Re: Staging

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> The master queue has cleared, so let's get this started again :)

Uh, never mind, I see there is a pending evaluation for some time.
Hopefully it won't time out (what's up with that, anyway).


signature.asc
Description: PGP signature

Re: [PATCHES] gnu: nss: Update to 3.30.2 [fixes CVE-2017-5461].

[Marius Bakke]

Mark H Weaver <m...@netris.org> writes:

> Hi Marius,
>
> Marius Bakke <mba...@fastmail.com> writes:
>> Mark H Weaver <m...@netris.org> writes:
>>
>>> Unfortunately, even with "nss-increase-test-timeout.patch" and
>>> "nss-disable-long-b64-tests.patch", the build still failed on armhf:
>>>
>>>   https://hydra.gnu.org/build/2010324
>>
>> This looks very similar to the random connect timeouts that prompted the
>> "increase-test-timeouts" patch, except this time it took 50s instead of
>> ~20s:
>
> Thanks very much for looking into it.
>
> 50 seconds to make a local connection?  Bah, that's ridiculous!  I'm
> beginning to wonder if the kernels running on these build slaves have
> buggy schedulers resulting in starvation, or perhaps we're overloading
> them too much.

I've wondered about this too. Even x86_64 exceeded the default 5s
timeout once. Maybe they are swapping to a busy I/O device?

>> I am 99% sure the attached patch will do the job. What do you think?
>
> If it sometimes takes 50 seconds to make a local connection, then I
> suspect it could occasionally take much longer than a minute.
>
> For now, I've asked Hydra to try building it again, as is.
>
> Maybe in 'core-updates' we should consider increasing the timeout to
> something on the order of 5 or 10 minutes.

This time a different test timed out at 34s. For now, I pushed the
change for armhf only with timeout set to 5 minutes. Let's see how that
goes.


signature.asc
Description: PGP signature

Re: [PATCHES] gnu: nss: Update to 3.30.2 [fixes CVE-2017-5461].

[Marius Bakke]

Mark H Weaver <m...@netris.org> writes:

> Mark H Weaver <m...@netris.org> writes:
>
>> These patches update nss to 3.30.2 and disable long b64 tests which fail
>> on some systems including armhf.  I'll push them soon after some light
>> testing.
>
> Unfortunately, even with "nss-increase-test-timeout.patch" and
> "nss-disable-long-b64-tests.patch", the build still failed on armhf:
>
>   https://hydra.gnu.org/build/2010324
>
> It would be good to find a way to fix or work around this issue without
> forcing rebuilds on other platforms.  Also, I feel it's important to
> always run tests on NSS on all platforms.

Here is the relevant excerpt from the log:

[ RUN  ] SkipVariants/TlsSkipTest.SkipCertificateRsa/0
Version: TLS 1.1
server: Changing state from INIT to CONNECTING
client: Changing state from INIT to CONNECTING
Dropping handshake: 11
record old: [531] 
02510302f666481a7e6747c16e682f37345e569db0d06bdb08b5a8894ec8...
record new: [89] 
02510302f666481a7e6747c16e682f37345e569db0d06bdb08b5a8894ec8...
server: Original packet: [536] 
160302021302510302f666481a7e6747c16e682f37345e569db0d06bdb08...
server: Filtered packet: [94] 
160302005902510302f666481a7e6747c16e682f37345e569db0d06bdb08...
Alert: [2] 020a
client: Alert sent: level=2 desc=10
client: Handshake failed with error SSL_ERROR_RX_UNEXPECTED_HELLO_DONE: SSL 
received an unexpected Server Hello Done handshake message.
client: Changing state from CONNECTING to ERROR
tls_connect.cc:238: Failure
Value of: (client_->state() != TlsAgent::STATE_CONNECTING) && (server_->state() 
!= TlsAgent::STATE_CONNECTING)
  Actual: false
Expected: true
tls_connect.cc:374: Failure
Value of: server_->state()
  Actual: CONNECTING
Expected: TlsAgent::STATE_ERROR
Which is: ERROR
[  FAILED  ] SkipVariants/TlsSkipTest.SkipCertificateRsa/0, where GetParam() = 
("TLS", 770) (50449 ms)

This looks very similar to the random connect timeouts that prompted the
"increase-test-timeouts" patch, except this time it took 50s instead of
~20s:

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00412.html

(search for '[  FAILED' in the build logs)

I am 99% sure the attached patch will do the job. What do you think?

From a6876365f2ee9a82452c3f364ee1cd94e44423c2 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mba...@fastmail.com>
Date: Sat, 22 Apr 2017 09:25:36 +0200
Subject: [PATCH] gnu: nss: Further increase test timeouts on armhf.

* gnu/packages/gnuzilla.scm (nss)[arguments]<#:phases>: Add a substitution
when target platform is armhf.
---
 gnu/packages/gnuzilla.scm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index efe63adb4..37c2eb006 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -241,6 +241,16 @@ in the Mozilla clients.")
   `((setenv "USE_64" "1")))
  (_
   '()))
+ ;; The timeout values in "increase-test-timeouts" are still
+ ;; too low, so apply this workaround on armhf for now to avoid
+ ;; rebuilding on all platforms. This should be incorporated in
+ ;; the patch for the next update.
+ ;; https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00472.html
+ ,@(if (string-prefix? "armhf" (or (%current-target-system)
+   (%current-system)))
+   `((substitute* "nss/gtests/ssl_gtest/tls_connect.cc"
+   (("25000\\);") "6);")))
+   '())
  #t))
  (replace 'check
(lambda _
-- 
2.12.2



signature.asc
Description: PGP signature

Re: [PATCH 5/5] gnu: Add obnam.

[Marius Bakke]

Arun Isaac  writes:

> * gnu/packages/backup.scm (obnam): New variable.

Thanks for this (and the dependencies)!

Unfortunately the obnam patch does not apply due to recent changes in
backup.scm, can you rebase it on current 'master' and send an updated
patch?

I've pushed the python packages.

TIA!


signature.asc
Description: PGP signature

Re: 04/05: gnu: Add python-faker.

[Marius Bakke]

Mark H Weaver <m...@netris.org> writes:

> Hi Marius,
>
> mba...@fastmail.com (Marius Bakke) writes:
>
>> mbakke pushed a commit to branch master
>> in repository guix.
>>
>> commit ce7911ddae5d30ba73c8c9552b7d4e71268e5db3
>> Author: Marius Bakke <mba...@fastmail.com>
>> Date:   Fri Feb 24 17:21:07 2017 +0100
>>
>> gnu: Add python-faker.
>> 
>> * gnu/packages/patches/python-fake-factory-fix-build-32bit.patch: Adjust
>> paths. Also rename to ...
>> * gnu/packages/patches/python-faker-fix-build-32bit.patch: ... this.
>
> The 'python-fake-factory' package still exists and refers to the patch
> that you removed in the commit above.  This caused the Hydra evaluation
> to fail, so I was compelled to find a quick remedy.  In commit
> 7b1866d783, I restored "python-fake-factory-fix-build-32bit.patch" as it
> was before the commit above.
>
> Please let me know if you think this is the right fix, or if something
> else is needed.

Oops. That looks like the correct fix, since it makes the package work
if the superseded property is removed. Thanks for taking care of it!


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Fri, Mar 03, 2017 at 01:02:04AM +0100, Marius Bakke wrote:
>> Leo Famulari <l...@famulari.name> writes:
>> > Once these changes are pushed, I'll start a new evaluation:
>> >
>> > http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
>> >
>> > Please, no more rebuild the world changes except to fix breakage in the
>> > core packages.
>> 
>> xorg-server@1.19.2 was *just* released[0] and contains some important
>> bug fixes (notably CVE-2017-2624).
>> 
>> [0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html
>
> It looks like a relatively small set of changes.
>
>> AFAICT it has not been built yet on Hydra since it's not part of the
>> "core" package set. Is it okay to push?
>
> xorg-server is not a core package, so I guess it's fine. I'll do the
> update when pushing the libgd changes from the thread linked above.

Note that 1.19.3 will be released shortly since 1.19.2 had a release bug
that requires running `autoreconf`. See:

https://lists.x.org/archives/xorg-announce/2017-March/002780.html

> I've been reconfiguring my GuixSD system on core-updates, so I've fixed
> and then suffered breakage in a few non-core packages so far :)

Wow, nice :)

> At some arbitrary point we have to stop changing the branch and just
> build it. Newer important updates will have to be grafted.

Agreed. Let's do a full evaluation once Hydra settles down and then
*really* freeze it ;)

>> Unfortunately I have not been able to backport the fix to 1.18.4.
>
> Okay, hopefully we can figure it out or copy from another distro.


signature.asc
Description: PGP signature

Re: core-updates: Python build failures

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Fri, Mar 10, 2017 at 10:46:34PM +0100, Marius Bakke wrote:
>> It looks like Hydra ran out of entropy which caused a bunch of failures.
>> 
>> From the 'python-minimal' build:
>> 
>> if test "no" != "yes"; then \
>> ./Programs/_freeze_importlib \
>> ./Lib/importlib/_bootstrap_external.py Python/importlib_external.h; \
>> fi
>> Fatal Python error: getentropy() failed
>
> Python is not compatible with current versions of glibc on older Linux
> kernels (it builds fine for me on a recent kernel):
>
> Bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1410175
>
> Discussion of a fix:
> https://bugs.python.org/issue29157
>
> I can't work on it today. Everyone else should feel free :)

I tried applying the upstream fix for 3.5:

https://hg.python.org/cpython/rev/337461574c90

However, the monster patch does not apply.

patching file Python/random.c
Hunk #2 succeeded at 39 (offset -1 lines).
Hunk #3 succeeded at 54 (offset -1 lines).
Hunk #4 succeeded at 65 (offset -1 lines).
Hunk #5 FAILED at 77.
Hunk #6 FAILED at 143.
Hunk #7 FAILED at 162.
Hunk #8 FAILED at 203.
Hunk #9 FAILED at 236.
Hunk #10 succeeded at 350 (offset -27 lines).
Hunk #11 succeeded at 374 (offset -27 lines).
Hunk #12 succeeded at 506 (offset -27 lines).
Hunk #13 succeeded at 525 (offset -27 lines).

Will try to dig out the other patches from 3.5 branch that this depends
on tomorrow. I can't reproduce the getentropy() failure either,
apparently it only occurs on kernels < 3.17.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add obnam.

[Marius Bakke]

Arun Isaac  writes:

>> I noticed this program and some of the libraries it uses, requires a
>> package called "CoverageTestRunner" to run unit tests. Currently tests
>> are simply skipped.
>
> I tried packaging the tests too. But, the tests require the root user
> and group to be present. The build environment does not have the root
> user and group. So, the tests fail. Can anything be done about this?

There is one user available in the build environment: "nobody". It could
work to substitute "root" for "nobody" in the code that looks for users.
The "mailutils" package does exactly that for tests. Can you try it?

TIA!


signature.asc
Description: PGP signature

Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Mark H Weaver <m...@netris.org> writes:

> Hi Marius,
>
> mba...@fastmail.com (Marius Bakke) writes:
>> mbakke pushed a commit to branch master
>> in repository guix.
>>
>> commit 4f3dcdd99ba13ab3bdbf1e014afcd076cd95fac7
>> Author: Marius Bakke <mba...@fastmail.com>
>> Date:   Mon Mar 13 16:53:27 2017 +0100
>>
>> gnu: nss, nss-certs: Update to 3.29.3.
>> 
>> * gnu/packages/gnuzilla.scm (nss): Update to 3.29.3.
>
> Hydra has tried to build nss-3.29.3 on x86_64 twice, and the test suite
> failed both times.
>
>   https://hydra.gnu.org/build/1905330
>
> The first time, we got this:
>
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] DamageYDatagram/TlsDamageDHYTest.DamageClientY/8, where 
> GetParam() = ("DTLS", 770, 4, true)
>
> and the second time, this:
>
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] 
> ExtensionPre13Datagram/TlsExtensionTestPre13.AlpnReturnedBadNameLength/0, 
> where GetParam() = ("TLS", 770)
>
> This is the first time I've ever seen NSS fail to build on x86_64.  It's
> quite serious since it means around 230 dependency failures, including
> IceCat, GNOME and Qt/KDE.
>
>   https://hydra.gnu.org/eval/109538#tabs-now-fail
>
> If this problem cannot be fixed very soon, we'll need to revert this
> update.  Did it build successfully on your machine?  If so, which
> architecture did you test it on?

Hi Mark,

I have built this without trouble on two different x86_64 systems. The
release notes[0] lists a single entry[1] which looks innocuous[2], so I
doubt the failure is related to the upgrade.

I can't find the build log of the first run, but note how in the second
failure the test took more than five seconds:

[  FAILED  ] 
ExtensionPre13Datagram/TlsExtensionTestPre13.AlpnReturnedBadNameLength/0, where 
GetParam() = ("TLS", 770) (5543 ms)
(from https://hydra.gnu.org/build/1905330/nixlog/6/raw )

This is reminiscent of the trouble we had getting 3.29.2 to build on
armhf[3]. Something caused the build to stall for a few seconds, which
in turn makes the test fail due to exceeding time treshold.

Can you try restarting the build once more?

0: 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.29.3_release_notes
1: https://bugzilla.mozilla.org/show_bug.cgi?id=1342358
2: https://hg.mozilla.org/projects/nss/rev/4e9aee9c5343
3: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25974#17


signature.asc
Description: PGP signature

Re: core-updates: Python build failures

[Marius Bakke]

Leo Famulari <l...@famulari.name> writes:

> On Sat, Mar 11, 2017 at 08:50:32PM +0100, Marius Bakke wrote:
>> I tried applying the upstream fix for 3.5:
>> 
>> https://hg.python.org/cpython/rev/337461574c90
>> 
>> However, the monster patch does not apply.
>
> [...]
>
>> Will try to dig out the other patches from 3.5 branch that this depends
>> on tomorrow. I can't reproduce the getentropy() failure either,
>> apparently it only occurs on kernels < 3.17.
>
> Maybe we should update Python 3.5 instead, so that the patch applies. Or
> update the kernels on the build farm machines.

Oh, I missed that 3.5.3 is out. After updating, the patch applied.

I've pushed the Python update and the getentropy() fix as
343cee8af and e4d34cd0 respectively.


signature.asc
Description: PGP signature

Re: Updating tzdata freely

[Marius Bakke]

Leo Famulari  writes:

> After creating a special "for tests only" xorg-server package for GTK+'s
> test suite recently, I started thinking about what other packages could
> receive the same treatment.
>
> Tzdata is an important package to keep up to date. Amazingly, some
> governments do announce time zone changes only days or weeks before they
> take effect. Without an up-to-date tzdata, users' clocks will be wrong
> in those locales.
>
> Currently, updating tzdata will cause about 1400 package rebuilds.
> However, if don't use the primary tzdata package in the test suites of
> glib and R, a tzdata update will only cause ~388 rebuilds.
>
> I checked that glib and R do not retain any references to tzdata after
> they are built, so we could create a tzdata package with a "fixed"
> version that will not be updated very often.
>
> So, we could update this package more freely, at the cost of some extra
> complexity in package maintenance.
>
> What do you think?

This sounds good; I was thinking the same after seeing the tzdata update
in core-updates. "libical" still causes a fair amounts of rebuilds, but
it's a lot more manageable than the current 1315 packages :-)


signature.asc
Description: PGP signature