[PATCH] gnu: Add metabat.

[Ben Woodcroft]

Thanks for fixing the samtools headers Ricardo, needed that for this.
>From 3f253f059edee5ee2fdb116e310ab210646acf40 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Sat, 11 Jul 2015 16:49:30 +1000
Subject: [PATCH] gnu: Add metabat.

* gnu/packages/bioinformatics.scm (metabat): New variable.
---
 gnu/packages/bioinformatics.scm | 72 +
 1 file changed, 72 insertions(+)

diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
index a28832d..a349d39 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -1394,6 +1394,78 @@ resolution of binding sites through combining the information of both
 sequencing tag position and orientation.")
 (license license:bsd-3)))
 
+(define-public metabat
+  (package
+(name "metabat")
+(version "0.26.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"https://bitbucket.org/berkeleylab/metabat/get/";
+version ".tar.bz2"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"0vgrhbaxg4dkxyax2kbigak7w0arhqvw0szwp6gd9wmyilc44kfa"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f ; tests run as part of build phase
+   #:phases
+   (modify-phases %standard-phases
+ (replace 'configure
+  (lambda* _
+(substitute* "SConstruct" ; Do not distribute README
+  (("env.Install.idir_prefix, 'README.md'.") ""))
+#t))
+ (replace 'build
+  (lambda* (#:key inputs outputs #:allow-other-keys)
+(substitute* "SConstruct"
+  (("/include/bam/bam.h")
+   "/include/samtools/bam.h"))
+(substitute* "src/BamUtils.h"
+  (("#include .bam/bam.h.")
+   "#include \"samtools/bam.h\""))
+(substitute* "src/BamUtils.h"
+  (("#include .bam/sam.h.")
+   "#include \"samtools/sam.h\""))
+(substitute* "src/KseqReader.h"
+  (("#include \"bam/kseq.h\"")
+   "#include \"samtools/kseq.h\""))
+(mkdir (assoc-ref outputs "out"))
+(zero? (system* "scons"
+(string-append
+ "PREFIX="
+ (assoc-ref outputs "out"))
+(string-append
+ "HTSLIB_DIR="
+ (assoc-ref inputs "htslib"))
+(string-append
+ "SAMTOOLS_DIR="
+ (assoc-ref inputs "samtools"))
+(string-append
+ "BOOST_ROOT="
+ (assoc-ref inputs "boost"))
+"install"
+ (delete 'install
+(inputs
+ `(("zlib" ,zlib)
+   ("perl" ,perl)
+   ("samtools" ,samtools)
+   ("htslib" ,htslib)))
+(native-inputs
+ `(("boost" ,boost)
+   ("scons" ,scons)))
+(home-page "https://bitbucket.org/berkeleylab/metabat";)
+(synopsis "Reconstruction of single genomes from complex microbial communities")
+(description
+ "Grouping large genomic fragments assembled from shotgun metagenomic
+sequences to deconvolute complex microbial communities, or metagenome binning,
+enables the study of individual organisms and their interactions.  MetaBAT is
+an automated metagenome binning software, which integrates empirical
+probabilistic distances of genome abundance and tetranucleotide frequency.")
+   (license (license:non-copyleft "file://license.txt"
+  "See LICENSE in the distribution."
+
 (define-public miso
   (package
 (name "miso")
-- 
2.4.3

Re: [PATCH] gnu: add the rc shell package

[Mark H Weaver]

Jeff Mickey  writes:
> I've never contributed a patch to guix, so please let me know if I'm
> missing any prerequisites for contribution.

To add to the feedback provided by Ricardo: your new file rc.scm should
contain the same large header as the other files, with your copyright
notice.

Thanks,
  Mark

Re: [PATCH] gnu: add the rc shell package

[Ricardo Wurmus]

> The tests are written in an m4 file which generates a configure script
> that generates c main()'s that are compiled and run as tests against
> rc.. there was a /bin/pwd in there that failed the test and I didn't
> think a simple sed would be able to remove that part of the test.

You can use

(substitute* "the-file.c"
  (("/bin/pwd") (which "pwd")))

to replace the “/bin/pwd” with the “pwd” in the store.

To run the tests by some other means than “make check” you can simply
replace the ‘check’ phase.

~~ Ricardo

RE: Using a shared Guix store (was RE: [Bio-packaging] testing out guix)

[Cook, Malcolm]

Ludovic, and Ricardo,

> Yes, one way to help would be by trying a simple setup using Guix as it
> currently exists, coupled with socat:
> 
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20381
> 
> If you could test this and provide feedback about the other options discussed
> there, that would be great (please email
> 20...@debbugs.gnu.org.)

Excellent.  That definitely looks testable by me, once I'm done with my basic 
site deployment.  I've been moving rather slowly but might be ready to contrast 
such approach with simply calling guix on guix-master over ssh.  I'll plan on 
it.  Maybe a week or two out.

Reading the thread, it sounds like Ricardo has today already had good success 
with socat.  Yay!

In that thread, you suggested "What about installing Guix in /gnu/bin (say) and 
sharing it over NFS?".  Is there a way to `./bootstrap ./configure ` this?  
Something like -- exec_prefix=/gnu --localstatedir=/gnu/var?  

Also, you discussed need for setting NIX_STATE_DIR.  This should not be needed 
if guix was already installed with configuration of --localstatedir=/guix/var   
(with /guix being nfs mounted), right?

Ricardo also wrote "For ‘guix package’ to work, /gnu/var/guix/profiles/per-user 
must be shared read-write (over NFS) with correct UID mapping." - I really 
don't understand this and tried to elicit feedback in 
http://lists.nongnu.org/archive/html/guix-devel/2015-07/msg00216.html -   Can 
anyone give me clarification on this.  I though the guix daemon is going to 
manage these profiles.

Honestly, much of my understanding of the above comes from reading the manual, 
archived IRC chats and mail threads, FOSDEM vids, and blog posts - which has 
been great.  But,  I've yet to succeed in my own site deploy, which will give 
me testbed to stretch my own understanding.  Today, I had the following 
failure

Ricardo, et. al.,  would you mind sharing some details on your network sharing 
configuration as regards users/groups and privileges, for I seem to have 
painted myself into a corner with the following
  
/gnu  is an NFS mount, owned by network user 'guix', group-owned by  
guix-builder with mod of 1775 
 
guix is being built from git configured with -- exec_prefix=/gnu 
--localstatedir=/gnu/var 

`make check`  results are


Testsuite summary for GNU Guix 0.8.3

# TOTAL: 42
# PASS:  32
# SKIP:  0
# XFAIL: 0
# FAIL:  10
# XPASS: 0
# ERROR: 0

With details below   I can submit all this to bug-g...@gnu.org, but I 
suspect (1) there is something fundamentally wrong with the way I am setting 
things up (2) your are reading this anyway ;)

Can you see any gotchas I haven't got yet?  Can you see the error in my ways 
and suggest a way through?

FWIW, I try to `make install` anyway, and, I pause I cannot complete a make 
install without "changing hats".  I find that it works to do the following

sudo make install-data # as root on localhost
sudo -u guix make install-exec ## since root on localhost is 
squashed on the NFS mount point, 

But I don't know if this is complete or not (the Makefile is complex!).

Anyway, "changing hats" feels very wrong, and I can feel more trouble coming 
when I want to run the daemon

Thanks so much everyone, and, keep on guixing,

~Malcolm


PS - in case it helps - below are test results and tarred logs are at 
http://research.stowers.org/mec/guixtests.tar

 I have not yet taught myself how to read them with understanding - (have a 
great weekend!)

PASS: tests/base32.scm
PASS: tests/base64.scm
FAIL: tests/cpio.scm
PASS: tests/hash.scm
PASS: tests/pk-crypto.scm
PASS: tests/pki.scm
PASS: tests/sets.scm
PASS: tests/substitute.scm
FAIL: tests/builders.scm
FAIL: tests/derivations.scm
PASS: tests/ui.scm
PASS: tests/records.scm
PASS: tests/utils.scm
PASS: tests/build-utils.scm
FAIL: tests/packages.scm
PASS: tests/snix.scm
PASS: tests/hackage.scm
PASS: tests/elpa.scm
FAIL: tests/store.scm
PASS: tests/monads.scm
PASS: tests/gexp.scm
FAIL: tests/nar.scm
FAIL: tests/union.scm
PASS: tests/profiles.scm
FAIL: tests/syscalls.scm
PASS: tests/gremlin.scm
PASS: tests/lint.scm
PASS: tests/publish.scm
PASS: tests/size.scm
PASS: tests/guix-build.sh
PASS: tests/guix-download.sh
PASS: tests/guix-hash.sh
PASS: tests/guix-package.sh
FAIL: tests/guix-package-net.sh
PASS: tests/guix-system.sh
PASS: tests/guix-archive.sh
PASS: tests/guix-authenticate.sh
FAIL: tests/guix-environment.sh
PASS: tests/guix-lint.sh
PASS: tests/guix-register.sh
PASS: tests/guix-gc.sh
PASS: tests/guix-daemon.sh



> So no ETA, but once we have feedback from you, Ricardo, and other
> interested parties, it will be easier to make a choice and implement it.
> :-)
> 
> Thanks,
> Ludo’.

Re: [PATCH] gnu: add the rc shell package

[Jeff Mickey]

* Ricardo Wurmus  [2015-07-10 06:59]:
> Please add a comment to explain why the tests are disabled (no “check”
> target or failing tests?).

The tests are written in an m4 file which generates a configure script
that generates c main()'s that are compiled and run as tests against
rc.. there was a /bin/pwd in there that failed the test and I didn't
think a simple sed would be able to remove that part of the test.

I will include an explanation in my followup.

> The alignment and length of the lines makes it hard to read.  How
> about this instead:
[...]

Yea - I think emacs must not be loading the right scheme settings from
.dir-locals.el for some reason, any pointers to a "blessed config" or
style guide would be awesome.

Thanks for the review - the comments were very helpful and I'll be
updating the package shortly!

  //  codemac

[PATCH 3/3] gnu: Add python-pelican

[Christopher Allan Webber]

At last, Pelican itself!

Static site publishing managed by Guix, here we come!

>From 220db75dbf4700a8c9b342cf68dacce74d864d8a Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber 
Date: Fri, 10 Jul 2015 16:28:01 -0500
Subject: [PATCH 3/3] gnu: Add python-pelican

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 6d0f811..4953e27 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -2134,6 +2134,57 @@ interested parties to subscribe to events, or \"signals\".")
 (define-public python2-blinker
   (package-with-python2 python-blinker))
 
+(define-public python-pelican
+  (package
+(name "python-pelican")
+(version "3.6.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/source/p/pelican/pelican-";
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "0lbkk902mqxpp452pp76n6qcjv6f99lq2zl204xmqyzcan9zr3ps"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)
+   ("python-feedgenerator" ,python-feedgenerator)
+   ("python-jinja2" ,python-jinja2)
+   ("python-pygments" ,python-pygments)
+   ("python-docutils" ,python-docutils)
+   ("python-pytz" ,python-pytz)
+   ("python-blinker" ,python-blinker)
+   ("python-unidecode" ,python-unidecode)
+   ("python-six" ,python-six)
+   ("python-dateutil-2" ,python-dateutil-2)))
+(home-page "http://getpelican.com/";)
+(arguments
+ `(;; Requires a lot more packages to do unit tests :P
+   #:tests? #f
+   #:phases (modify-phases %standard-phases
+  (add-before
+   'install 'adjust-requires
+   ;; Since feedgenerator is installed from git,
+   ;; it doesn't conform to the version requirements.
+   ;;
+   ;; We *do have* "feedgenerator >= 1.6", but strip off the
+   ;; version requirement so setuptools doesn't get confused.
+   (lambda _
+ (substitute* "setup.py"
+   (("['\"]feedgenerator.*?['\"]")
+"'feedgenerator'")))
+(synopsis
+ "Python-based static site publishing system")
+(description
+ "A tool to generate a static blog from reStructuredText, Markdown input files,
+and more.  Pelican uses Jinja2 for templating and is very extensible.")
+;; No indication that this is "or later" in the source,
+;; must assume AGPLv3 only
+(license agpl3)))
+
 (define-public python-scikit-learn
   (package
 (name "python-scikit-learn")
-- 
2.1.4

[PATCH 2/3] gnu: Add python-blinker

[Christopher Allan Webber]

Here's the second patch towards Pelican support.  This one's the
python-blinker library!  Easy!  No extra dependencies!

>From 0ef695078864edb838827b9b4eac918f4c090391 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber 
Date: Fri, 10 Jul 2015 16:12:47 -0500
Subject: [PATCH 2/3] gnu: Add python-blinker

* gnu/packages/python.scm (python-blinker python2-blinker): New variables.
---
 gnu/packages/python.scm | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 7d77da0..6d0f811 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -28,7 +28,7 @@
 (define-module (gnu packages python)
   #:use-module ((guix licenses)
 #:select (asl2.0 bsd-4 bsd-3 bsd-2 non-copyleft cc0 x11 x11-style
-  gpl2 gpl2+ gpl3+ lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+
+  gpl2 gpl2+ gpl3+ lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+ agpl3
   psfl public-domain x11-style))
   #:use-module ((guix licenses) #:select (expat zlib) #:prefix license:)
   #:use-module (gnu packages)
@@ -2105,6 +2105,35 @@ sources.")
 (define-public python2-feedgenerator
   (package-with-python2 python-feedgenerator))
 
+(define-public python-blinker
+  (package
+(name "python-blinker")
+(version "1.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/source/b/blinker/blinker-";
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "0bvfxkmjx6bpa302pv7v2vw5rwr3dlzjzfdp3bj628i6144024b8"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(arguments '(#:tests? #f))
+(home-page "http://pythonhosted.org/blinker/";)
+(synopsis
+ "Fast, simple object-to-object and broadcast signaling")
+(description
+ "Blinker provides a fast dispatching system that allows any number of
+interested parties to subscribe to events, or \"signals\".")
+(license license:expat)))
+
+(define-public python2-blinker
+  (package-with-python2 python-blinker))
+
 (define-public python-scikit-learn
   (package
 (name "python-scikit-learn")
-- 
2.1.4

[PATCH 1/3] gnu: Add python-feedgenerator

[Christopher Allan Webber]

Hello!  I'm packaging pelican, so here's the first of the couple of
required dependencies to install it.

(Unfortunately we have to install from git because the LICENSE file was
just added at my request.  Otherwise I'd use a tarball!)

>From 32fe80103c1cef93f1608d5c09e4edf7cd005a5e Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber 
Date: Fri, 10 Jul 2015 15:49:07 -0500
Subject: [PATCH 1/3] gnu: Add python-feedgenerator

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 5dcaba0..7d77da0 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -8,6 +8,7 @@
 ;;; Copyright © 2015 Omar Radwan 
 ;;; Copyright © 2015 Pierre-Antoine Rault 
 ;;; Copyright © 2015 Ricardo Wurmus 
+;;; Copyright © 2015 Christopher Allan Webber 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -2066,6 +2067,44 @@ sources.")
 (define-public python2-sphinx-rtd-theme
   (package-with-python2 python-sphinx-rtd-theme))
 
+(define-public python-feedgenerator
+  (package
+(name "python-feedgenerator")
+(version "20150710.97185b7")
+(source
+ ;; Using the git checkout for now because license file not added till
+ ;; https://github.com/dmdm/feedgenerator-py3k/commit/97185b7566c240c4bf5ed80db7d6c271204dab39
+ (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://github.com/dmdm/feedgenerator-py3k.git";)
+ (commit "97185b7566c240c4bf5ed80db7d6c271204dab39")))
+   (sha256
+(base32
+ "0dbd6apij5j1923ib905x0srgcyls4wlabqlwp4dzkwmksvnrr2a"
+(arguments
+ ;; incompatible with Python 3 (exception syntax)
+ `(;; With standard flags, the install phase attempts to create a zip'd
+   ;; egg file, and fails with an error: 'ZIP does not support timestamps
+   ;; before 1980'
+   #:configure-flags '("--single-version-externally-managed"
+   "--record=feedgenerator.txt")))
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)
+   ("python-pytz" ,python-pytz)
+   ("python-six" ,python-six)))
+(home-page
+ "https://github.com/dmdm/feedgenerator-py3k.git";)
+(synopsis
+ "Standalone version of django.utils.feedgenerator, compatible with Py3k")
+(description
+ "Feedgenerator-py3k is a standalone version of Django's feedgenerator.")
+(license bsd-3)))
+
+(define-public python2-feedgenerator
+  (package-with-python2 python-feedgenerator))
+
 (define-public python-scikit-learn
   (package
 (name "python-scikit-learn")
-- 
2.1.4

Re: 01/01: gnu: boost: Update to 1.58.0.

[Mark H Weaver]

Andreas Enge  writes:

> I will push this to a wip-boost branch, and try to build a dependent package
> locally. I wonder if I should base wip-boost on openssl-update; but with
> only 69 dependent packages (if the count is true), it probably does not
> matter.

I see that you pushed this branch and asked Hydra to build it.  First, I
don't think that we should be building a new branch against a version of
openssl with a known security flaw.  It will only have to be immediately
rebuilt again.

I would also prefer to prioritize getting this openssl security fix
deployed, if you don't mind.  Toward that end, I'm going to delete the
jobset on Hydra for now.  If you disagree, can we talk about it?

  Mark

Re: How to handle required plugins and dbus services for GNOME Programs?

[Ludovic Courtès]

Mark H Weaver  skribis:

> So, at this point my inclination is to do the following:
>
> * Add 'dconf' to the propagated-inputs of 'totem', since totem needs
>   dconf services to be available on the user session D-Bus.
>
> * Add a wrapper for 'totem' that add prefixes to both
>   GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH to ensure reliable access
>   to a baseline set of plugins needed for proper functioning of 'totem'.
>   This includes grilo-plugins, gst-plugins-base, and gst-plugins-good.
>   IMO, this hard-coded set of plugins should exclude patent-encumbered
>   codecs, so no gst-libav or gst-plugins-ugly.
>
> Please see the attached 'totem' package.  To simplify things, the values
> of the GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH environment variables
> are taken directly from the build environment (using 'getenv') and
> propagated unchanged into the created wrapper.
>
> What do you think?

Sounds good.  Thanks for moving forward!

Ludo’.

Re: [PATCH] gnu: make-bootstrap: Produce the correct %glibc-bootstrap-tarball for Hurd systems.

[Ludovic Courtès]

Manolis Ragkousis  skribis:

> On 7 July 2015 at 17:58, Ludovic Courtès  wrote:
>> Could you make sure that ‘guix build glibc-stripped-tarball’ still works
>> as expected?  (I assume you already tested with --target=i586-pc-gnu.)
>
> All OK with the changes, but 'guix build glibc-stripped-tarball' does
> not work anymore because
> I have turned (%glibc-bootstrap-tarball) into a procedure.

I had overlooked that.

> Unless I do that, it will not evaluate correctly. How can I export it
> correctly now?

Uh.  But you can run ‘guix build bootstrap-tarballs’, can’t you?

Ludo’.

Re: [PATCH] gnu: bootstrap: Create a wrapper for guile to set the system load path

[Ludovic Courtès]

Mark H Weaver  skribis:

> We currently use gnu/packages/patches/guile-relocatable.patch to set the
> system load path in the bootstrap guile.  However, that patch depends on
> /proc/self/exe which is not present on the Hurd.  Therefore, I came up
> with another approach in the attached patch.  After unpacking the
> bootstrap guile, we use it to create its own wrapper that sets the
> GUILE_SYSTEM_PATH and GUILE_SYSTEM_COMPILED_PATH environment variables.

That sounds nice!

> My only concern is that these variables will be present in the
> environment in any subprograms launched by the bootstrap guile, and so
> if the bootstrap guile ever tries to run a different version of guile,
> those variable settings may cause trouble.

Good point.  I think that happens when ‘guile-final’ gets built, but you
mentioned that it built perfectly, right?  But in that case it’s OK
because meta/uninstalled-env overrides GUILE_SYSTEM_* anyway.

> From 885997fec1f0a175279edbf56b86050731892148 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Wed, 8 Jul 2015 12:31:32 -0400
> Subject: [PATCH] gnu: bootstrap: Create a wrapper for guile to set the system
>  load path.
>
> * gnu/packages/bootstrap.scm (raw-build): After unpacking, use the bootstrap
>   guile to create its own wrapper that sets the guile system load path.

[...]

> + (make-guile-wrapper
> +  '(begin

Could you add a comment above mentioning that this replaces the previous
non-portable option based on /proc/self/exe?

OK for core-updates.

Thanks for helping out with this!

Ludo’.

Re: [PATCH 3/6] gnu: Add perl-date-manip.

[Ludovic Courtès]

Andreas Enge  skribis:

> On Thu, Jul 09, 2015 at 07:38:06PM -0500, ericbav...@openmailbox.org wrote:
>> +(arguments
>> + ;; Tests would require tzdata for timezone information, but tzdata is 
>> in
>> + ;; (gnu packages base) which would create a circular dependency.  TODO:
>> + ;; Maybe put this package elsewhere so we can turn on tests.
>> + '(#:tests? #f))
>
> Would it be enough to selectively import only tzdata here?

On the contrary: Circular dependencies among modules are OK as long as
#:select isn’t used (see .)

Ludo’.

Re: 01/01: gnu: boost: Update to 1.58.0.

[Mark H Weaver]

Andreas Enge  writes:

> On Fri, Jul 10, 2015 at 12:52:24PM -0400, Mark H Weaver wrote:
>> I'm not 100% sure what's happening either, but more packages are
>> becoming broken over time.  I think it has to do with the fact that
>> 'git' is one of the broken packages, and other packages that fetch their
>> source code using 'git' are becoming broken whenever Guix decides it's
>> time to try re-downloading the source, e.g.:
>
> Okay, that is an interesting explanation!
>
>> I've reverted the patch.  After we have a solution to this problem, we
>> can build it in a separate branch.  I think we should have done this
>> anyway, since updating Boost entails a lot of rebuilds, and has a
>> history of being problematic on non-Intel platforms.
>
> With only 69 dependent packages, it did not look like a big risk!

It's definitely more than that.  As I recall, Hydra had to do on the
order of 600 rebuilds after your boost update.  This is a case where
"guix refresh -l" is way off.

> It just built with the patch on my mips machine:
>Performing configuration checks
>
> - 32-bit   : yes
> - arm  : no
> - mips1: no
> - power: no
> - sparc: no
> - x86  : no
> - combined : no
> I still find it suspicious that it is not recognised as "mips1"; it may
> have to do with the different ABIs, since when I build it on debian,
> it says "mips1 : yes".

Yes, it might have to do with that.  Debian uses the O32 ABI.

> I will push this to a wip-boost branch, and try to build a dependent package
> locally. I wonder if I should base wip-boost on openssl-update; but with
> only 69 dependent packages (if the count is true), it probably does not
> matter.

Can we do this on core-updates instead?  I'm currently working on a
core-updates branch.  I will push it soon, after I've done some basic
testing on it.

Hydra is already overloaded trying to rebuild the openssl-update jobset,
and now it will have more to do since I reverted boost on master and
rebased openssl-update on that.  I want to get openssl-update built
ASAP.

What do you think?

  Mark

Re: 01/01: gnu: boost: Update to 1.58.0.

[Andreas Enge]

On Fri, Jul 10, 2015 at 12:52:24PM -0400, Mark H Weaver wrote:
> I'm not 100% sure what's happening either, but more packages are
> becoming broken over time.  I think it has to do with the fact that
> 'git' is one of the broken packages, and other packages that fetch their
> source code using 'git' are becoming broken whenever Guix decides it's
> time to try re-downloading the source, e.g.:

Okay, that is an interesting explanation!

> I've reverted the patch.  After we have a solution to this problem, we
> can build it in a separate branch.  I think we should have done this
> anyway, since updating Boost entails a lot of rebuilds, and has a
> history of being problematic on non-Intel platforms.

With only 69 dependent packages, it did not look like a big risk!
It just built with the patch on my mips machine:
   Performing configuration checks

- 32-bit   : yes
- arm  : no
- mips1: no
- power: no
- sparc: no
- x86  : no
- combined : no
I still find it suspicious that it is not recognised as "mips1"; it may
have to do with the different ABIs, since when I build it on debian,
it says "mips1 : yes".

I will push this to a wip-boost branch, and try to build a dependent package
locally. I wonder if I should base wip-boost on openssl-update; but with
only 69 dependent packages (if the count is true), it probably does not
matter.

Andreas



> 
> Does that make sense?
> 
>   Mark

Re: [PATCH 14/15] scripts: environment: Add --container option.

[Ludovic Courtès]

"Thompson, David"  skribis:

> On Tue, Jul 7, 2015 at 10:35 AM, Ludovic Courtès  wrote:

>> Since this works without root privileges, what about adding a test in
>> tests/guix-environment.sh?
>>
>> Basically something similar to one of the existing tests, but
>> additionally checking from within the container that ‘id -u’ returns 0,
>> that ‘$$’ is 2, and that files outside of $PWD are not in the container.
>
> For some reason that I haven't figured out, the existing tests do not
> pass on my machine when I run:
>
> make check TESTS=tests/guix-environment.sh
>
> I'm finding it difficult to debug our tests because the test runner
> eats backtraces and other useful info.

Could you post tests/guix-environment.log?  Normally it contains both
stdout and stderr, as well as all the shell lines that were executed.

>> Which reminds me: In a separate commit, it Would Be Nice to document our
>> minimal kernel requirements for the container functionality.  Could you
>> look into that?
>
> AFAIK the recommended minimal kernel version that folks should be
> using for this stuff is 3.13, and the kernel needs to be configured
> with that DEVPTS_MULTIPLE_INSTANCES flag.  Where would you put this
> information?

The DEVPTS_MULTIPLE_INSTANCES thing should probably go in “Setting Up
the Daemon.”

The rest could maybe go to a “Container Support” section under
“Installation” that would be referenced from “Requirements” (where
optional dependencies are listed)?  Any better idea?

Thanks,
Ludo’.

Re: [PATCH 11/15] gnu: system: Add Linux container module.

[Ludovic Courtès]

"Thompson, David"  skribis:

> From 7c41e765a91f6a4c50b692f6230d6e0e3e3b7099 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Mon, 8 Jun 2015 08:59:00 -0400
> Subject: [PATCH] gnu: system: Add Linux container module.
>
> * gnu/system/linux-container.scm: New file.
> * gnu-system.am (GNU_SYSTEM_MODULES): Add it.
> * gnu/system.scm: Export 'operating-system-etc-directory',
>   'operating-system-boot-script', 'operating-system-locale-directory', and
>   'file-union'.
>   (operating-system-boot-script): Add #:container? keyword argument.
>   (operating-system-activation-script): Add #:container?  keyword argument.
>   Don't call 'activate-firmware' or 'activate-ptrace-attach' when activating a
>   container.

LGTM!

Ludo'.

Re: Presence of GuixSD as "a Linux"

[Ludovic Courtès]

Adam Pribyl  skribis:

> On Fri, 10 Jul 2015, Taylan Ulrich Bayırlı/Kammer wrote:

[...]

>> Such a case we had recently: Guitarix web page.  Despite having
>> "GNU/Linux" in the project name, they were unwilling to change mentions
>> of "a Linux" and "Linux flavours" on their page to GNU/Linux, without
>> really giving a reason...  Anyone interested might want to check their
>> mailing list archives; I don't know if perhaps my communication skills
>> were too bad.
>
> Do not bother people with that - let them use what they want. To
> understand this, people have to have some level of insight and
> will. They may grow to that or not.

+1.  Let’s respectfully let them do what they deem appropriate.

Ludo’.

Re: Call for testing : guix-tox, a version of tox that uses "guix environment".

[Ludovic Courtès]

Amirouche Boubekki  skribis:

> On 2015-07-10 03:38, Christopher Allan Webber wrote:

[...]

>>> I intend to propose a 20 minute talk about
>>> guix-tox at the next PyConFR.
>
> Nice!

\o/

>> This is great!  I've also been very interested in "guix environment" as
>> a universal virtualenv.  Replacing tox is an excellent example/usage!
>
> I wondering whether it is possible to use the same recipe for `guix
> environment` and `guix container`. The idea behind that is that one
> can use environment for dev and container for deployment.

The patch series that David posted adds a --container option to ‘guix
environment’, so you get isolated containers for free.

Keep up the good work, Cyril! :-)

Ludo’.

Re: OpenStack and GuixOps

[Ludovic Courtès]

Great, thanks for looking into this!

Ludo’.

Re: 01/01: gnu: boost: Update to 1.58.0.

[Mark H Weaver]

Andreas Enge  writes:

> On Thu, Jul 09, 2015 at 06:00:39PM -0400, Mark H Weaver wrote:
>> Boost turns out to be an important package.  The fallout from this is
>> 412 newly failed builds on mips64el:
>>   http://hydra.gnu.org/eval/105333#tabs-now-fail
>
> I do not quite understand this number, it should be 65 according to the
> first link. But anyway, it is an important package.

I'm not 100% sure what's happening either, but more packages are
becoming broken over time.  I think it has to do with the fact that
'git' is one of the broken packages, and other packages that fetch their
source code using 'git' are becoming broken whenever Guix decides it's
time to try re-downloading the source, e.g.:

  http://hydra.gnu.org/eval/105357#tabs-now-fail
  
http://hydra.gnu.org/eval/105355?filter=.mips64el-linux&compare=105351#tabs-now-fail

Anyway, thanks for investigating this, but it seems that we still don't
understand what's going on, and meanwhile our MIPS port is extremely
broken.

I've reverted the patch.  After we have a solution to this problem, we
can build it in a separate branch.  I think we should have done this
anyway, since updating Boost entails a lot of rebuilds, and has a
history of being problematic on non-Intel platforms.

Does that make sense?

  Mark

Re: Guix "ops"

[Christopher Allan Webber]

David Thompson writes:

> Hello again Carlos,
>
> Carlos Sosa  writes:
>
>>   I like the idea of 'guix deploy', and maybe something to propagates
>>   given configuration files, like 'guix config prepare' and later 'guix
>>   config apply'.
>>
>> Now, how can I contribute? work the guix command?
>>
>> Let me know if you have a specific repository or place to find any work
>> done on this.
>
> I have just pushed a new branch called "wip-deploy" to the official guix
> repository.  Since this branch is prefixed with "wip-", expect it to be
> rebased frequently.  There's not much code here yet, but a very simple
> prototype has been implemented that supports the creation of local QEMU
> VMs.
>
> To take it for a spin, add something like this to a file, let's call it
> "deployment.scm":

I've confirmed that the above works and works great.  I wanted to play
with it with current master, so I rebased the current branch on top of
it.  It's a mere single patch at the moment, so here's the patch with
appropriate conflicts resolved, in case anyone wants to play with it
with master (or in case David wants someone else to handle the conflict
resolving work for them ;))

>From 25047d057c2adc30901b3052bf5017a6763741a1 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 13 Apr 2015 19:14:31 -0400
Subject: [PATCH] scripts: Add deploy.

* gnu/machines.scm: New file.
* gnu-system.am (GNU_SYSTEM_MODULES): Add it.
* guix/scripts/deploy.scm: New file.
* Makefile.am (MODULES): Add it.
* gnu.scm: Export (gnu machines) symbols.
* gnu/system/vm.scm (virtualized-operating-system): Export it.
---
 Makefile.am |   1 +
 gnu-system.am   |   4 +-
 gnu.scm |   1 +
 gnu/machines.scm| 125 +++
 gnu/system/vm.scm   |   2 +
 guix/scripts/deploy.scm | 153 
 6 files changed, 285 insertions(+), 1 deletion(-)
 create mode 100644 gnu/machines.scm
 create mode 100644 guix/scripts/deploy.scm

diff --git a/Makefile.am b/Makefile.am
index 7059a8f..9458b2c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -121,6 +121,7 @@ MODULES =	\
   guix/scripts/publish.scm			\
   guix/scripts/edit.scm\
   guix/scripts/size.scm\
+  guix/scripts/deploy.scm			\
   guix.scm	\
   $(GNU_SYSTEM_MODULES)
 
diff --git a/gnu-system.am b/gnu-system.am
index d6369b5..d2d6f79 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -359,7 +359,9 @@ GNU_SYSTEM_MODULES =\
   gnu/build/linux-container.scm			\
   gnu/build/linux-initrd.scm			\
   gnu/build/linux-modules.scm			\
-  gnu/build/vm.scm
+  gnu/build/vm.scm\
+		\
+  gnu/machines.scm
 
 
 patchdir = $(guilemoduledir)/gnu/packages/patches
diff --git a/gnu.scm b/gnu.scm
index e3147b3..5cd1dea 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -42,6 +42,7 @@
 (gnu services base)
 (gnu packages)
 (gnu packages base)
+(gnu machines)
 (guix gexp))) ; so gexps can be used
 
 (for-each (let ((i (module-public-interface (current-module
diff --git a/gnu/machines.scm b/gnu/machines.scm
new file mode 100644
index 000..2276732
--- /dev/null
+++ b/gnu/machines.scm
@@ -0,0 +1,125 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 David Thompson 
+;;;
+;;; 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 machines)
+  #:use-module (guix records)
+  #:use-module (gnu system)
+  #:use-module (gnu system vm)
+  #:use-module (ice-9 match)
+  #:use-module (srfi srfi-1)
+  #:export (deployment
+make-deployment
+deployment?
+deployment-name
+deployment-machines
+
+machine
+make-machine
+machine?
+machine-name
+machine-system
+machine-platform
+
+platform
+make-platform
+platform-name
+platform-description
+platform-provision
+platform-install
+platform-reconfigure
+platform-boot
+platform-reboot
+platform-halt
+platform-destroy
+
+machine-os-for-platform
+provision-machine
+boot-machine
+
+local-vm))
+
+(define-record-type*  deployment
+  make-deploy

Re: Presence of GuixSD as "a Linux"

[Adam Pribyl]

On Fri, 10 Jul 2015, Taylan Ulrich Bayırlı/Kammer wrote:


Some pages and documentation of some projects insist on using
terminology such as "a Linux", "Linux distributions", "Linux flavours"
etc. when referring to GNU/Linux systems.

Would the publicity benefits of appearing on such pages outweigh the
harm done by GuixSD appearing as "a Linux"?


IMHO GuixSD is more a platform to build OS. Now it is build with Linux, 
but I noticed Hurd attempts too or it may "parasite" on another OS. I do 
not feel it as a GNU/Linux distribution.



Such a case we had recently: Guitarix web page.  Despite having
"GNU/Linux" in the project name, they were unwilling to change mentions
of "a Linux" and "Linux flavours" on their page to GNU/Linux, without
really giving a reason...  Anyone interested might want to check their
mailing list archives; I don't know if perhaps my communication skills
were too bad.


Do not bother people with that - let them use what they want. To 
understand this, people have to have some level of insight and will. They 
may grow to that or not.



Taylan


Adam Pribyl

Presence of GuixSD as "a Linux"

[Taylan Ulrich Bayırlı/Kammer]

Some pages and documentation of some projects insist on using
terminology such as "a Linux", "Linux distributions", "Linux flavours"
etc. when referring to GNU/Linux systems.

Would the publicity benefits of appearing on such pages outweigh the
harm done by GuixSD appearing as "a Linux"?


Such a case we had recently: Guitarix web page.  Despite having
"GNU/Linux" in the project name, they were unwilling to change mentions
of "a Linux" and "Linux flavours" on their page to GNU/Linux, without
really giving a reason...  Anyone interested might want to check their
mailing list archives; I don't know if perhaps my communication skills
were too bad.

Taylan

Re: [PATCH] gnu: add the rc shell package

[Ricardo Wurmus]

Hi Jeff,

thanks for the contribution!  Below are some comments about your patch,
mostly relating to formatting.

> From 5deadfb23d8235101220310d0c47626c1d4c219f Mon Sep 17 00:00:00 2001
> From: Jeff Mickey 
> Date: Thu, 9 Jul 2015 17:39:42 -0700
> Subject: [PATCH] gnu: add the rc shell package
>
> * gnu/packages/rc.scm (rc): Add the rc package definition
>
> This patch adds the rc shell package to guix. It is byron's rc, not plan9 rc -
> and on other distributions 'rc' refers to byron's rc and 'plan9port' or some
> other meta package install the plan9 set of tools which includes rc.
>
> It has a zlib license.

We usually don’t add comments like that to the commit message (instead
they go into the cover email to the mailing list).  Also, when creating
a new file we don’t name the variable that is added, but declare this
file to be new.

I wonder if for this shell we could have a common module called
“shells.scm” where we could merge in “zsh.scm” and possibly other
shells.  Anyway, here would be a commit message that is more in line
with the others:

~~~8<
gnu: Add the rc shell.

* gnu/packages/rc.scm: New file.
~~~8<

> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "https://github.com/rakitzis/rc/tarball/";
> +  
> "c884da53a7c885d46ace2b92de78946855b18e92"))
> +  (sha256
> +   (base32 
> "05hlnqcxaw08m1xypk733hajwaap5pr354ndmrm86k0flisjk0fw"

I see that there are no release tarballs.  When we take an arbitrary
commit we usually add a comment.  Also, we normally use the ‘git-fetch’
method instead of ‘url-fetch’.

> +(build-system gnu-build-system)
> +(arguments `(#:configure-flags
> +  '("--with-edit=gnu")
> +  #:phases
> +  (modify-phases %standard-phases
> +(add-before 'configure 'autoreconf (lambda _
> + (zero? (system* 
> "autoreconf" "-vfi")
> +  #:tests? #f))

Please add a comment to explain why the tests are disabled (no “check”
target or failing tests?).  The alignment and length of the lines makes
it hard to read.  How about this instead:

(arguments
 `(#:tests? #f ;no "check" target
   #:configure-flags '("--with-edit=gnu")
   #:phases
   (modify-phases %standard-phases
 (add-before
  'configure 'autoreconf
  (lambda _ (zero? (system* "autoreconf" "-vfi")))

> +(inputs `(("readline" ,readline)
> +   ("perl" ,perl)))

This is oddly aligned.

> +(native-inputs `(("autoconf" ,autoconf)
> +  ("automake" ,automake)
> +  ("libtool" ,libtool)
> +  ("pkg-config" ,pkg-config)))

Same here.

> +(synopsis "An alternative implementation of the plan 9 rc shell.")
> +(description
> + "This is a reimplementation for Unix, by Byron Rakitzis, of
> +the Plan 9 shell. It has a small feature set similar to a traditional Bourne
> +shell, but with a much cleaner and simpler syntax.")

Please use two spaces after a period.

I’m not sure if the description is okay; “much cleaner and simpler
syntax” sounds a little too partial to me.

Note that you can use “guix lint” to check your package definition for
the most common problems.

~~ Ricardo

Re: [PATCH] Add Gridmap + psutils.

[Ricardo Wurmus]

Eric Bavier  writes:

> On 2015-07-10 07:59, Ricardo Wurmus wrote:
>> * gnu/packages/python.scm (python-psutil, python2-psutil): New 
>> variables.
> [...]
>> +(native-inputs
>> +  `(("python-setuptools" ,python-setuptools)))
>
> Nitpick: I believe the '`' should align with the 'n'.

Oh, yes.  I forgot to hit TAB.

[PATCH] gnu: add the rc shell package

[Jeff Mickey]

Hi guix-devel!

I've never contributed a patch to guix, so please let me know if I'm
missing any prerequisites for contribution.

This adds the rc shell to guix.

  //  jeff mickey

>From 5deadfb23d8235101220310d0c47626c1d4c219f Mon Sep 17 00:00:00 2001
From: Jeff Mickey 
Date: Thu, 9 Jul 2015 17:39:42 -0700
Subject: [PATCH] gnu: add the rc shell package

* gnu/packages/rc.scm (rc): Add the rc package definition

This patch adds the rc shell package to guix. It is byron's rc, not plan9 rc -
and on other distributions 'rc' refers to byron's rc and 'plan9port' or some
other meta package install the plan9 set of tools which includes rc.

It has a zlib license.
---
 gnu/packages/rc.scm | 44 
 1 file changed, 44 insertions(+)
 create mode 100644 gnu/packages/rc.scm

diff --git a/gnu/packages/rc.scm b/gnu/packages/rc.scm
new file mode 100644
index 000..6fc001c
--- /dev/null
+++ b/gnu/packages/rc.scm
@@ -0,0 +1,44 @@
+(define-module (gnu packages rc)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages perl)
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages readline)
+  #:use-module (guix build gnu-build-system)
+  #:use-module (guix build utils)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix download)
+  #:use-module (guix licenses)
+  #:use-module (guix packages))
+
+
+(define-public rc
+  (package
+(name "rc")
+(version "1.7.4")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://github.com/rakitzis/rc/tarball/";
+  "c884da53a7c885d46ace2b92de78946855b18e92"))
+  (sha256
+   (base32 "05hlnqcxaw08m1xypk733hajwaap5pr354ndmrm86k0flisjk0fw"
+(build-system gnu-build-system)
+(arguments `(#:configure-flags
+		 '("--with-edit=gnu")
+		 #:phases
+		 (modify-phases %standard-phases
+		   (add-before 'configure 'autoreconf (lambda _
+			(zero? (system* "autoreconf" "-vfi")
+		 #:tests? #f))
+(inputs `(("readline" ,readline)
+	  ("perl" ,perl)))
+(native-inputs `(("autoconf" ,autoconf)
+		 ("automake" ,automake)
+		 ("libtool" ,libtool)
+		 ("pkg-config" ,pkg-config)))
+(synopsis "An alternative implementation of the plan 9 rc shell.")
+(description
+ "This is a reimplementation for Unix, by Byron Rakitzis, of
+the Plan 9 shell. It has a small feature set similar to a traditional Bourne
+shell, but with a much cleaner and simpler syntax.")
+(home-page "http://github.com/rakitzis/rc";)
+(license zlib)))
-- 
2.4.5

Re: [PATCH] Add Gridmap + psutils.

[Eric Bavier]

On 2015-07-10 07:59, Ricardo Wurmus wrote:
* gnu/packages/python.scm (python-psutil, python2-psutil): New 
variables.

[...]

+(native-inputs
+  `(("python-setuptools" ,python-setuptools)))


Nitpick: I believe the '`' should align with the 'n'.

--
`~Eric

[PATCH] Add Gridmap + psutils.

[Ricardo Wurmus]

>From 0f415a0c5a18083c5ead7cf0c84c201234a806e0 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Fri, 10 Jul 2015 14:57:05 +0200
Subject: [PATCH 1/2] gnu: Add python-psutil.

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 5cad200..a1e8843 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -249,6 +249,36 @@ data types.")
  "\n\nThis wrapper package provides symbolic links to the python binaries
   without version suffix."
 
+(define-public python-psutil
+  (package
+(name "python-psutil")
+(version "3.0.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/source/p/psutil/psutil-";
+ version ".tar.gz"))
+   (sha256
+(base32
+ "00c8h1mzqysih99z8pnbmdv117d2naldf11yjy50dhykxsf3n89z"
+(build-system python-build-system)
+(native-inputs
+  `(("python-setuptools" ,python-setuptools)))
+(home-page "https://pypi.python.org/pypi/psutil/";)
+(synopsis "Library for retrieving information on running processes")
+(description
+ "psutil (Python system and process utilities) is a library for retrieving
+information on running processes and system utilization (CPU, memory, disks,
+network) in Python.  It is useful mainly for system monitoring, profiling and
+limiting process resources and management of running processes.  It implements
+many functionalities offered by command line tools such as: ps, top, lsof,
+netstat, ifconfig, who, df, kill, free, nice, ionice, iostat, iotop, uptime,
+pidof, tty, taskset, pmap.")
+(license bsd-3)))
+
+(define-public python2-psutil
+  (package-with-python2 python-psutil))
 
 (define-public python-pytz
   (package
-- 
2.1.0

>From 772798dcaba2097d17ad969b0acdad3f10a047e3 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Fri, 10 Jul 2015 14:58:09 +0200
Subject: [PATCH 2/2] gnu: Add python-gridmap.

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index a1e8843..dea7f8f 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -3234,6 +3234,38 @@ Python language binding specification.")
 (define-public python2-drmaa
   (package-with-python2 python-drmaa))
 
+(define-public python-gridmap
+  (package
+(name "python-gridmap")
+(version "0.13.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://github.com/pygridtools/gridmap/archive/v";
+ version ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
+   (sha256
+(base32 "1gzjg2k6f14i1msm2b0ax8d9ds1hvk6qd5nlaivg8m4cxqp4cp1x"
+(build-system python-build-system)
+(inputs
+ `(("python-psutil" ,python-psutil)
+   ("python-drmaa" ,python-drmaa)
+   ("python-pyzmq" ,python-pyzmq)))
+(native-inputs
+ `(;("python-nose" ,python-nose)
+   ("python-setuptools" ,python-setuptools)))
+(home-page "https://github.com/pygridtools/gridmap";)
+(synopsis "Create jobs on a cluster directly from Python")
+(description
+  "Gridmap is a Python package to allow you to easily create jobs on the
+cluster directly from Python.  You can directly map Python functions onto the
+cluster without needing to write any wrapper code yourself.")
+(license gpl3+)))
+
+(define-public python2-gridmap
+  (package-with-python2 python-gridmap))
+
 (define-public python-ipython
   (package
 (name "python-ipython")
-- 
2.1.0

Re: [PATCH] gnu: Update pumpa to 0.9.1.

[Thompson, David]

On Fri, Jul 10, 2015 at 4:31 AM, Claes Wallin (韋嘉誠)
 wrote:
> On Jul 9, 2015 7:49 PM, "Mathieu Lirzin"  wrote:
>>
>> PS: There is no need to use "git send-mail ..." here.  Just attach the
>> file generated by "git format-patch origin/master" to your answer.
>
> The advantage I see with git send-mail is that the patch is readable inline
> when reading the list archive and list mail, and in the case of a multi-step
> patch it neatly groups patches together ... when you do it right.

You don't need git send-email for this, just tell your mail client to
inline the patch attachments.

- Dave

Re: [PATCH 5/5] gnu: Add emacs-mmm-mode

[Ludovic Courtès]

Alex Kost  skribis:

> So my guess is: MELPA periodically updates all the tarballs, not just
> the packages with the new version tags.  I think it means we should
> refuse from using melpa(-stable) tarballs and use the upstream releases
> instead.  In this particular case it will be
> .

Agreed.

Ludo’.

Re: [PATCH 2/2] gnu: Add dunst.

[Ludovic Courtès]

Alex Kost  skribis:

> From 8d8928b84b565eb47c36c1e6b2ff2b3c963076d2 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Wed, 8 Jul 2015 21:03:49 +0300
> Subject: [PATCH 2/2] gnu: Add dunst.
>
> * gnu/packages/dunst.scm: New file.
> * gnu-system.am (GNU_SYSTEM_MODULES): Add it.

LGTM.

>From the description, I gather it is started automatically and thus
doesn’t need a GuixSD service definition, right?

Thanks,
Ludo’.

Re: Using a shared Guix store (was RE: [Bio-packaging] testing out guix)

[Ludovic Courtès]

"Cook, Malcolm"  skribis:

>> Another one, which I think Ricardo has been investigating lately, would be to
>> have users manage their profiles via the Web user interface,
>> guix-web: .  (The video
>> > 01__GNU_Guix__The_Emacs_of_Distros.webm>
>> has a demo starting at around 23mn.)
>
> Hmm, it is not clear to me how this would play out in a multi-user 
> environment.  Having a web server that could alter per-user profiles sounds 
> like a recipe for more confusion, rather than a solution.
>
> In any case, in my opinion, it would be a mistake to have depend on another 
> tool (such as guix-web, or something similar) to implement functionality that 
> could not be gained at using command-line  guix.  Don't you agree?

I’m just mentioning it as an additional option, for those who like it.

>> >> Ultimately, the correct fix is to allow remote guix clients to
>> >> communicate with a central guix daemon.  The daemon does not even
>> >> need to be aware of remote connections if guix clients can
>> >> transparently connect via SSH and send RPCs to the socket.  This is not 
>> >> yet
>> implemented.
>> >
>> > Sounds great.  On the roadmap?
>> 
>> Definitely.  There are details to be sorted out (SSH vs. plain old socket), 
>> but
>> we should discuss it and “get it done.”
>
> Are there any signposts on this road-map emerging?  Is there any way I can 
> help, such as review proposals for how the CLI would work, I'd be happy to 
> chip in.  Not ready to start slinging guile though.  Maybe later (the old 
> lisper in me revels at the thought).

Yes, one way to help would be by trying a simple setup using Guix as it
currently exists, coupled with socat:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20381

If you could test this and provide feedback about the other options
discussed there, that would be great (please email
20...@debbugs.gnu.org.)

So no ETA, but once we have feedback from you, Ricardo, and other
interested parties, it will be easier to make a choice and implement it.
:-)

Thanks,
Ludo’.

Re: [PATCH] gnu: Update pumpa to 0.9.1.

[韋嘉誠]

On Jul 9, 2015 7:49 PM, "Mathieu Lirzin"  wrote:
>
> One last thing before pushing. :)
>
> Following the
> http://lists.gnu.org/archive/html/guix-devel/2015-07/msg00235.html
> discussion, I want to know if the usage of the email address
>  instead of
>  in your patch was intentionnal?

Do you mean the opposite? I use gnu@ on the list, but I would like my
patches (and AUTHORS) to use @greatsino. I think that's what I did?

> PS: There is no need to use "git send-mail ..." here.  Just attach the
> file generated by "git format-patch origin/master" to your answer.

The advantage I see with git send-mail is that the patch is readable inline
when reading the list archive and list mail, and in the case of a
multi-step patch it neatly groups patches together ... when you do it right.

Re: [PATCH 3/6] gnu: Add perl-date-manip.

[Andreas Enge]

On Thu, Jul 09, 2015 at 07:38:06PM -0500, ericbav...@openmailbox.org wrote:
> +(arguments
> + ;; Tests would require tzdata for timezone information, but tzdata is in
> + ;; (gnu packages base) which would create a circular dependency.  TODO:
> + ;; Maybe put this package elsewhere so we can turn on tests.
> + '(#:tests? #f))

Would it be enough to selectively import only tzdata here?

> +(description "")

Empty description.

Andreas

Re: [PATCH 2/6] gnu: Add perl-html-tableextract.

[Andreas Enge]

Looks good.

Andreas

Re: [PATCH 1/6] gnu: Add perl-html-element-extended.

[Andreas Enge]

On Thu, Jul 09, 2015 at 07:38:04PM -0500, ericbav...@openmailbox.org wrote:
> +(description
> + "Perl extension for manipulating a table composed of HTML::Element style
> +components.")

I would use a full sentence as in your other patch: "... is a Perl 
extension...".
Otherwise it looks good.

Andreas

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Federico Beffa]

On Fri, Jul 10, 2015 at 8:47 AM, Alex Kost  wrote:
> Federico Beffa (2015-07-09 23:41 +0300) wrote:
>
>> On Thu, Jul 9, 2015 at 10:51 AM, Alex Kost  wrote:
>>> Federico Beffa (2015-07-08 23:22 +0300) wrote:
>>>
 On Tue, Jul 7, 2015 at 6:58 PM, Alex Kost  wrote:
> A side note: I think generally it would be preferable to use an upstream
> release in the package recipe rather than to use a melpa(-stable) URL,
> i.e.:
>
>   http://foo-upstream.org/foo-0.1.tar.gz  instead of
>   http://stable.melpa.org/packages/foo-0.1.tar

 I believe that such information is not available from ELPA archives.
 Therefore the ELPA importer has no way to do this. But, obviously,
 manual modification is possible. (By the way, the tar files are
 similar but not identical.)
>>>
>>> Surely, I didn't mean that it's a task for the elpa importer.  I'm
>>> totally for the manual modification to use an upstream release, not the
>>> melpa(-stable) one.
>>>
>>> By "the tar files are similar" do you mean that MELPA usually leaves
>>> only elisp files in the tarballs?  I think since it's a common practice
>>> to put elisp files in the root directory of the repo, we should add a
>>> phase to the emacs build system to remove non-elisp files (like
>>> .gitignore or README) from the final
>>> /gnu/store/…-foo-0.1/share/emacs/site-lisp/guix.d/foo-0.1/ directory.
>>
>> One difference that I noticed in the tar files is that tar coming from
>> elpa archives always include the .info file, while the upstream ones
>> do not always do so. I've not investigated further differences.
>
> I think that the upstream never include (at least they shouldn't)
> ".info" files.  So perhaps it would be good to add a phase for building
> info manual if there are ".texi" files and no ".info".
>
>> While often the READMEs are not very usefull, sometimes they are.
>
> But do people look at ~/.guix-profile/share/emacs/site-lisp/guix.d/foo
> directory to find README and other useful non-elisp files?

My guess is that people using the Emacs packaging system (and by
extension Emacs users) do, because that's very similar to the Emacs'
native packaging strategy.

>
>> Therefore I do not like the idea of removing them, nor anything else
>> provided by the package. It's upstream who should decide what's
>> relevant. With the use of 'guix.d' there will be no name clashes. Did
>> you happen to see the following thread?
>>
>> https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00392.html
>
> Yes, I read it, but when you say «provided by the package» and «It's
> upstream who should decide», you are talking about the packages imported
> from (m)elpa, not the upstream itself.  Since melpa is unusable (due to
> a hash problem), we'll have to use the direct upstream releases, which
> are not stripped from ".gitignore" and other unrelated files.  So all
> these files will move into "…/.guix.d/package" dir.
>
> As an example, try the following variant of "emacs-mmm-mode" package:
>
>
>
> As you can see, there are many odd files in the
> "…/share/emacs/site-lisp/guix.d/mmm-mode-0.5.4" directory.
>
> So I suggest to add a phase for deleting non-".el[c]" files from the
> ".guix.d/package" directory.
>
> And just in case: I have nothing against GNU ELPA repository (especially
> taking into account that it is the only "home" for some packages).  I'm
> against melpa and melpa-stable, because:
>
> - Why should we rely on a third-party server that do something with the
>   upstream files to produce a final tarball?

Well, that's just a necessary step to make Emacs 'package.el' work properly.

>
> - MELPA(-stable) is not usable anyway, because the tarballs of the same
>   version are updated all the time, so the hash is being permanently
>   changed.
>
> However, if a package from ELPA has a real upstream release that can be
> used with "gnu-build-system" (e.g., emms, auctex, mmm-mode), I think we
> should prefer it instead of importing it from ELPA.

Nowadays many Emacs packages recommend to use Emacs' packaging system
as the preferred method of installation. See e.g.
https://github.com/purcell/mmm-mode

However, the hash problem with packages from melpa appears to be a show stopper.

Fede

Re: [PATCH] Add Emacs PDF tools

[Ricardo Wurmus]

Alex Kost  writes:

> Since now we have 'emacs-byte-compile-directory', the elisp files may
> also be compiled.  I modified your patch to:
>
> - move patching the variables (including 'pdf-tools-handle-upgrades')
>   into a separate phase;
> - compile the elisp files;
> - generate autoloads.

Thank you!

> So if there is no way to "build" elisp files using the top-level
> Makefile, and then to "build" epdfinfo using "autogen.sh" and friends
> from the "server" subdir, I think the attached patch will do.  WDYT?

The top-level Makefile uses ‘cask’ to bytecompile and test the package
tarball.  The ‘$(PACKAGE_NAME).tar’ target contains the only line that
copies the elisp files to the target directory, but it’s amidst lines
required for building the tarball.  I don’t think there’s a good way to
reuse the top-level Makefile.

~~ Ricardo

Re: [PATCH] Add preseq.

[Ricardo Wurmus]

Mark H Weaver  writes:

> No.  It's deterministic, and 'modify-phases' is in (guix build utils) so
> it can't be changed without triggering a full rebuild.  The edits are
> done in the order shown, as if it was imperative code.  For example:

Thank you for confirming the behaviour.

>> When I built it locally back then “use-samtools-headers” must have
>> ended up after “enter-dir”.)
>
> I don't see how that could have happened.  Maybe you made some changes
> after your last test?  Anyway, if 'use-samtools-headers' must come after
> 'enter-dir' then it's surely better to make that explicit.

In that case it must have been that I made a change (reordering the
phases) and forgot to build preseq afterward.  My apologies for the
noise!

~~ Ricardo