Re: [PATCH] gnu: Add smartmontools.

[Taylan Ulrich Bayırlı/Kammer]

Mark H Weaver  writes:

> One more unrelated suggestion, while I'm at it: in the synopsis and
> description, I think it would be better to write "S.M.A.R.T." rather
> than "SMART".  What do you think?

Done.  Thanks for the review. :-)

using guix in virtualbox

[westlake]

Hi, I've noticed that people have been using virtualbox with guix, but 
over here with 0.8.1 (64-linux), i'm noticing a bootup issue upon 
post-install


The setup is informative enough from the guix install page, on top of 
which I create two empty .vdi disks, and can use qemu-nbd to transfer 
the raw image of the usb-install.


It's actually pretty easy to set this up, and it took under 20 minutes. 
However after rebooting and then "unplugging" the installer drive from 
Virtualbox. The grub boot menu shows up, it appears the init starts but 
soon there is a freezing issue.


Not sure what to do from this point, I understand more details would be 
needed to see why this is happening so I added an attachment.


thanks

Re: [PATCH] gnu: Add openntpd.

[Ludovic Courtès]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> From d9e0a4d07ee7e82582589b1e1cd3be218dd6b08f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  
> Date: Mon, 9 Feb 2015 21:39:41 +0100
> Subject: [PATCH] gnu: Add openntpd.
>
> * gnu/packages/ntp.scm (openntpd): New variable.

[...]

> +(define-public openntpd
> +  (package
> +(name "openntpd")
> +(version "5.7p3")
> +(source (origin
> +  (method url-fetch)
> +  ;; XXX Use mirror://openbsd
> +  (uri (string-append
> +"http://ftp.openbsd.org/pub/OpenBSD/OpenNTPD/openntpd-";
> +version ".tar.gz"))
> +  (sha256
> +   (base32
> +"0filjmb3b8rc39bvhm8q2azzj10ljfgq41qih71pxv919j57qhag"
> +(build-system gnu-build-system)
> +(home-page "http://www.openntpd.org/";)
> +(synopsis "NTP client and server by the OpenBSD Project")
> +(description "OpenNTPD is the OpenBSD Project's implementation of a 
> client
> +and server for the Network Time Protocol.")

Could you write a bit about what sets it apart?  Notably that it’s
minimalist compared to ntpd.

> +(license l:isc)))

The web site says it’s “under a BSD license”.  Could you double-check
which license that is?

TIA,
Ludo’.

Re: [PATCH]: gnu: Add STAR.

[Ricardo Wurmus]

Ludovic Courtès writes:
>> +(license license:gpl3)))
>
> GPLv3-only?

Actually, searching the source tree shows me that LICENSE includes the
"or (at your option) any later version" phrase; but the included copy of
htslib that is built as part of the STAR aligner is MIT licensed.

I'll update the license field to

  ;; STAR is licensed under GPLv3 or later; htslib is MIT-licensed.
  (license (list license:gpl3+ license:expat))

Is this appropriate?

~~ Ricardo

Re: [PATCH]: gnu: Add HISAT.

[Ricardo Wurmus]

Ludovic Courtès writes:

> If it’s possible to avoid the whole list using ‘find-files’ or
> ‘scandir’, that would be nicer IMO.  If it’s not, that’s fine.


>
>> +(license license:gpl3)))
>
> GPLv3-only?
>
> Thanks!
>
> Ludo’.

Re: [PATCH] gnu: Add openntpd.

[Taylan Ulrich Bayırlı/Kammer]

Updated patch:

>From 4ee696247b320144c16656fd525b20a3a4cf31d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
 
Date: Mon, 9 Feb 2015 21:39:41 +0100
Subject: [PATCH] gnu: Add openntpd.

* gnu/packages/ntp.scm (openntpd): New variable.
---
 gnu/packages/ntp.scm | 24 
 1 file changed, 24 insertions(+)

diff --git a/gnu/packages/ntp.scm b/gnu/packages/ntp.scm
index 24ce2f5..0525882 100644
--- a/gnu/packages/ntp.scm
+++ b/gnu/packages/ntp.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014 John Darrington 
 ;;; Copyright © 2014, 2015 Mark H Weaver 
+;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -61,3 +62,26 @@ computers over a network.")
  "http://www.eecis.udel.edu/~mills/ntp/html/copyright.html";
  "A non-copyleft free licence from the University of Delaware"))
(home-page "http://www.ntp.org";)))
+
+(define-public openntpd
+  (package
+(name "openntpd")
+(version "5.7p3")
+(source (origin
+  (method url-fetch)
+  ;; XXX Use mirror://openbsd
+  (uri (string-append
+"http://ftp.openbsd.org/pub/OpenBSD/OpenNTPD/openntpd-";
+version ".tar.gz"))
+  (sha256
+   (base32
+"0filjmb3b8rc39bvhm8q2azzj10ljfgq41qih71pxv919j57qhag"
+(build-system gnu-build-system)
+(home-page "http://www.openntpd.org/";)
+(synopsis "NTP client and server by the OpenBSD Project")
+(description "OpenNTPD is the OpenBSD Project's implementation of a client
+and server for the Network Time Protocol.  Its design goals include being
+secure, easy to configure, and accurate enough for most purposes, so it's more
+minimalist than ntpd.")
+;; A few of the source files are under bsd-3.
+(license (list l:isc l:bsd-3
-- 
2.2.1

Re: [PATCH]: gnu: Add HISAT.

[Ricardo Wurmus]

Ludovic Courtès writes:

> If it’s possible to avoid the whole list using ‘find-files’ or
> ‘scandir’, that would be nicer IMO.  If it’s not, that’s fine.

In the attached patch I used `find-files' instead.  The expression is a
bit long, but I think it's still clear enough to be preferable to the
long list.

>> +(license license:gpl3)))
>
> GPLv3-only?

You were right: it's GPLv3+.  My apologies.

>From 5696a8227d98d60d38f0ff19b40a21ccb13e53f1 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Mon, 9 Feb 2015 12:13:26 +0100
Subject: [PATCH] gnu: Add HISAT.

* gnu/packages/bioinformatics.scm (hisat): New variable.
---
 gnu/packages/bioinformatics.scm | 66 -
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
index c0d1438..9219bc2 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -29,8 +29,9 @@
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
-  #:use-module (gnu packages python))
+  #:use-module (gnu packages python)
   #:use-module (gnu packages tbb)
+  #:use-module (gnu packages zip))
 
 (define-public bedtools
   (package
@@ -181,6 +182,69 @@ supports next-generation sequencing data in fasta/q and csfasta/q format from
 Illumina, Roche 454, and the SOLiD platform.")
 (license license:gpl3)))
 
+(define-public hisat
+  (package
+(name "hisat")
+(version "0.1.4")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://ccb.jhu.edu/software/hisat/downloads/hisat-";
+version "-beta-source.zip"))
+  (sha256
+   (base32
+"1k381ydranqxp09yf2y7w1d0chz5d59vb6jchi89hbb0prq19lk5"
+(build-system gnu-build-system)
+(arguments
+ '(#:tests? #f ;no check target
+   #:make-flags '("allall")
+   #:phases
+   (alist-replace
+'unpack
+(lambda* (#:key source #:allow-other-keys)
+  (and (zero? (system* "unzip" source))
+   (chdir "hisat-0.1.4-beta")))
+(alist-cons-after
+ 'unpack 'patch-sources
+ (lambda _
+   ;; XXX Cannot use snippet because zip files are not supported
+   (substitute* "Makefile"
+ (("^CC = .*$") "CC = gcc")
+ (("^CPP = .*$") "CPP = g++")
+ ;; replace BUILD_HOST and BUILD_TIME for deterministic build
+ (("-DBUILD_HOST=.*") "-DBUILD_HOST=\"\\\"guix\\\"\"")
+ (("-DBUILD_TIME=.*") "-DBUILD_TIME=\"\\\"0\\\"\""))
+   (substitute* '("hisat-build" "hisat-inspect")
+ (("/usr/bin/env") (which "env"
+ (alist-replace
+  'install
+  (lambda* (#:key outputs #:allow-other-keys)
+(let ((bin (string-append (assoc-ref outputs "out") "/bin/")))
+  (mkdir-p bin)
+  (for-each
+   (lambda (file)
+ (copy-file file (string-append bin file)))
+   (find-files
+"."
+"hisat(-(build|align|inspect)(-(s|l)(-debug)*)*)*$"
+  (alist-delete 'configure %standard-phases))
+(native-inputs
+ `(("unzip" ,unzip)))
+(inputs
+ `(("perl" ,perl)
+   ("python" ,python)
+   ("zlib" ,zlib)))
+(home-page "http://ccb.jhu.edu/software/hisat/index.shtml";)
+(synopsis "Hierarchical indexing for spliced alignment of transcripts")
+(description
+ "HISAT is a fast and sensitive spliced alignment program for mapping
+RNA-seq reads.  In addition to one global FM index that represents a whole
+genome, HISAT uses a large set of small FM indexes that collectively cover the
+whole genome.  These small indexes (called local indexes) combined with
+several alignment strategies enable effective alignment of RNA-seq reads, in
+particular, reads spanning multiple exons.")
+(license license:gpl3+)))
+
 (define-public samtools
   (package
 (name "samtools")
-- 
2.1.0

Re: [ART] Logo proposal

[Daniel Pimentel]

On 2015-02-09 19:35, l...@gnu.org wrote:

Luis Felipe López Acevedo  skribis:


I made some logos for Guix and GuixSD:

* http://sirgazil.bitbucket.org/static/temp/img/guix/Guix.png
* http://sirgazil.bitbucket.org/static/temp/img/guix/GuixSD.png

I understand if you prefer using the current Guix logo and no logo for
GuixSD, though. I just wanted to share anyways.


I’m very impressed by both, I like them!

It raises the two questions you mention.  I sympathize both with what
you wrote before and your current hesitation wrt. brxanding.

I need to think more (and read more what others think) but yeah, why 
not

a GuixSD logo.

Thank you!

Ludo’.

Thank you Guix team (users, developers and others) for great work :)
--
Daniel Pimentel (d4n1)

texlive failure

[Federico Beffa]

Hi,

I have trouble downloading the 3.3GB 'texlive-data' package and
therefore I'm trying to build it locally. The 'build' and 'check'
phases succeed. However, after the 'compress-documentation' phase a
guile process stays at 100% for 1 hour, after which the process times
out and is killed.

This is the 'tail' of the output:

[...]
starting phase `compress-documentation'
compressing documentation in
'/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/man'
with "gzip" and flags ("--best" "--no-name")
compressing documentation in
'/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/info'
with "gzip" and flags ("--best" "--no-name")
phase `compress-documentation' succeeded after 0 seconds

After this there is no more output.

The content of the documentation directories is less than 1MB and I
can see that all man and info pages are compressed long before the
process times out. This is reproducible as I tried 3 times.

Any idea?

Regards,
Fede

Re: [ART] Logo proposal

[Adam Pribyl]

On Sun, 8 Feb 2015, Luis Felipe López Acevedo wrote:


Hi,

I made some logos for Guix and GuixSD:

* http://sirgazil.bitbucket.org/static/temp/img/guix/Guix.png
* http://sirgazil.bitbucket.org/static/temp/img/guix/GuixSD.png

I understand if you prefer using the current Guix logo and no logo for
GuixSD, though. I just wanted to share anyways.



Very nice. Just I am not sure why to change the existing Guix logo.
IMHO Guix and GSD need a symbols/icon - it is good for orientation.

And here is and asciiart version :)

(_  _)
  \/
GuixSD


--
Luis Felipe López Acevedo



Adam Pribyl

Re: [PATCH]: gnu: Add STAR.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès writes:
>>> +(license license:gpl3)))
>>
>> GPLv3-only?
>
> Actually, searching the source tree shows me that LICENSE includes the
> "or (at your option) any later version" phrase; but the included copy of
> htslib that is built as part of the STAR aligner is MIT licensed.
>
> I'll update the license field to
>
>   ;; STAR is licensed under GPLv3 or later; htslib is MIT-licensed.
>   (license (list license:gpl3+ license:expat))
>
> Is this appropriate?

Since the combined work is GPLv3+ anyway, I would keep the comment but
set the ‘license’ field to GPL3+.

Thanks,
Ludo’.

Re: [PATCH] gnu: Add openntpd.

[Ludovic Courtès]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> From 4ee696247b320144c16656fd525b20a3a4cf31d3 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  
> Date: Mon, 9 Feb 2015 21:39:41 +0100
> Subject: [PATCH] gnu: Add openntpd.
>
> * gnu/packages/ntp.scm (openntpd): New variable.

Please push, thank you!

Ludo’.

Re: [PATCH]: gnu: Add HISAT.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> From 5696a8227d98d60d38f0ff19b40a21ccb13e53f1 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Mon, 9 Feb 2015 12:13:26 +0100
> Subject: [PATCH] gnu: Add HISAT.
>
> * gnu/packages/bioinformatics.scm (hisat): New variable.

LGTM, thanks!

Ludo’.

Re: using guix in virtualbox

[Adam Pribyl]

On Tue, 10 Feb 2015, westlake wrote:

Hi, I've noticed that people have been using virtualbox with guix, but over 
here with 0.8.1 (64-linux), i'm noticing a bootup issue upon post-install


The setup is informative enough from the guix install page, on top of which I 
create two empty .vdi disks, and can use qemu-nbd to transfer the raw image 
of the usb-install.


It's actually pretty easy to set this up, and it took under 20 minutes. 
However after rebooting and then "unplugging" the installer drive from 
Virtualbox. The grub boot menu shows up, it appears the init starts but soon 
there is a freezing issue.


Not sure what to do from this point, I understand more details would be 
needed to see why this is happening so I added an attachment.


thanks



This is how I did it with 0.8

convertfromraw gnu-usb-install-version-linux-i686 gnu.vdi --format vdi

Attach it as a new SATA storage to new VB machine, enable PAE in 
System/Processor tab, otherwise it may crash. Add another disk image to 
install to and after a boot continue with install.


Adam Pribyl

Re: texlive failure

[Ludovic Courtès]

Federico Beffa  skribis:

> I have trouble downloading the 3.3GB 'texlive-data' package and
> therefore I'm trying to build it locally. The 'build' and 'check'
> phases succeed. However, after the 'compress-documentation' phase a
> guile process stays at 100% for 1 hour, after which the process times
> out and is killed.

I think what happens is what Mark described in
.

For now the workaround is to use --max-silent-time=1 or similar.

HTH,
Ludo’.

Re: texlive failure

[Federico Beffa]

On Tue, Feb 10, 2015 at 1:26 PM, Federico Beffa  wrote:
> This is the 'tail' of the output:
>
> [...]
> starting phase `compress-documentation'
> compressing documentation in
> '/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/man'
> with "gzip" and flags ("--best" "--no-name")
> compressing documentation in
> '/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/info'
> with "gzip" and flags ("--best" "--no-name")
> phase `compress-documentation' succeeded after 0 seconds
>
> After this there is no more output.

While I was writing the previous email I was trying again to build
texlive and that guile process was already running since ca. 45 mins.
But, this time the process finished and the further output is

grafting '/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014' ->
'/gnu/store/lpxmwqsv0rq6qsx7yc7wqjfzjk1v9pck-texlive-2014'...
grafting '/gnu/store/331b3772kzqpgp9mbw73cb9ixfy2fjn7-texlive-2014-data'
-> '/gnu/store/1fvf9jhlc5gb3kcminmv4yds9dkhyx01-texlive-2014-data'...
install-info: warning: no info dir entry in
`/gnu/store/z2z6924n1da54i956hj00awwksy2axkp-automake-1.14.1/share/info/automake-history.info'
[...]

So, I guess grafting takes a very long time. For this package it is
not substantially faster than building the package itself. :-(

Regards,
Fede

Re: texlive failure

[Federico Beffa]

On Tue, Feb 10, 2015 at 1:55 PM, Ludovic Courtès  wrote:
> I think what happens is what Mark described in
> .
>
> For now the workaround is to use --max-silent-time=1 or similar.

Crossed emails...

Yes, that's correct.

Thanks,
Fede

Re: bug#19805: Numpy failures

[Federico Beffa]

On Tue, Feb 10, 2015 at 12:07 AM, Ludovic Courtès  wrote:
>> At some point we should fix the support for '#:substitutable?' on hydra
>
> That probably means that #:substitutable? should be propagated–i.e.,
> that anything depending on ATLAS should not be substituted.

I guess so. Is there a way to specify this in a package or does it
require changes to the guix code?

Regards,
Fede

Re: texlive failure

[Andreas Enge]

On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote:
> So, I guess grafting takes a very long time. For this package it is
> not substantially faster than building the package itself. :-(

The speciality of texlive is that it is relatively easy to build - some CPU time
for the binaries. Then the data is essentially only unpacked and some of the
binaries are run on them, but the latter takes only minutes. So I would always
recommend to (re-)build the package locally.

Andreas

Re: texlive failure

[Mark H Weaver]

Andreas Enge  writes:

> On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote:
>> So, I guess grafting takes a very long time. For this package it is
>> not substantially faster than building the package itself. :-(
>
> The speciality of texlive is that it is relatively easy to build - some CPU 
> time
> for the binaries. Then the data is essentially only unpacked and some of the
> binaries are run on them, but the latter takes only minutes. So I would always
> recommend to (re-)build the package locally.

I wonder if we should consider setting #:substitutable? #f for texlive.
However, we would have to be careful not to propagate this setting, as
was recently proposed in the "Numpy failures" thread.

  Mark

Re: texlive failure

[Daniel Pimentel]

On 2015-02-10 10:34, Andreas Enge wrote:

On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote:

So, I guess grafting takes a very long time. For this package it is
not substantially faster than building the package itself. :-(


The speciality of texlive is that it is relatively easy to build - some 
CPU time
for the binaries. Then the data is essentially only unpacked and some 
of the
binaries are run on them, but the latter takes only minutes. So I would 
always

recommend to (re-)build the package locally.

Andreas

I can install texlive after "guix pull", it work.

Thanks,
--
Daniel Pimentel (d4n1)

Re: bug#19805: Numpy failures

[Mark H Weaver]

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

> Federico Beffa  skribis:
>
>> At some point we should fix the support for '#:substitutable?' on hydra
>
> That probably means that #:substitutable? should be propagated–i.e.,
> that anything depending on ATLAS should not be substituted.

As I just wrote in the "texlive failure" thread, setting
#:substitutable? #f might make sense for texlive.  However, in that case
we certainly would not want to propagate that setting.

So, instead of propagating it, how about simply arranging to not send
such packages to the build slaves, instead forcing them to build it
locally on their own?

I suppose this would cause the texlive build log to be prepended to some
other build log, which is not so good, but that could also be dealt with
in various ways, e.g. by changing the "send dependency to slave" logic
for non-substitutable packages to build the package on that particular
slave.

What do you think?

  Mark

Re: texlive failure

[Andreas Enge]

On Tue, Feb 10, 2015 at 10:50:05AM -0300, Daniel Pimentel wrote:
> I can install texlive after "guix pull", it work.

You mean, you managed to pull all the data from hydra?
Or did you compile locally?

Andreas

Re: texlive failure

[Andreas Enge]

On Tue, Feb 10, 2015 at 08:46:42AM -0500, Mark H Weaver wrote:
> I wonder if we should consider setting #:substitutable? #f for texlive.
> However, we would have to be careful not to propagate this setting, as
> was recently proposed in the "Numpy failures" thread.

I have been working on a split of texlive into two private packages,
the binaries and the data (which unfortunately depends on the binaries),
and a public one that joins the two. We could then also have a
texlive-small with a smaller data portion.

With Ludovic we have been discussing numerous solutions over the last
week, but when implementing them, something always went wrong...
I think we now have a solution that works with wrapping all binaries,
and once some changes are made in core-updates to enable this for
symbolic links, it should be easy to implement. But before it works,
I am not giving guarantees any more...

Then a possible solution would be to substitute the binary package
(which requires CPU time), but not the data package (which requires almost
none).

Andreas

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

[Manolis Ragkousis]

Ludo is this okay to push?

Wrapped lines to 80 chars.
From aaa968bbe01a57ceadf8d0c46c44e0d75d2f90cd Mon Sep 17 00:00:00 2001
From: Marek Benc 
Date: Thu, 5 Feb 2015 17:01:14 +0100
Subject: [PATCH] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)
 systems.

* gnu/packages/cross-base.scm (cross-gcc-arguments): Make 'set-cross-path aware of the Hurd.
---
 gnu/packages/cross-base.scm | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index f881096..8929f7f 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -151,21 +151,36 @@ GCC that does not target a libc; otherwise, target that libc."
  `(alist-cons-before
'configure 'set-cross-path
(lambda* (#:key inputs #:allow-other-keys)
- ;; Add the cross Linux headers to CROSS_CPATH, and remove
+ ;; Add the cross kernel headers to CROSS_CPATH, and remove
  ;; them from CPATH.
  (let ((libc  (assoc-ref inputs "libc"))
(linux (assoc-ref inputs
- "libc/cross-linux-headers")))
+ "libc/cross-linux-headers"))
+   (mach  (assoc-ref inputs
+ "libc/cross-gnumach-headers"))
+   (hurd  (assoc-ref inputs
+ "libc/cross-hurd-headers"))
+   (hurd-minimal (assoc-ref inputs
+ "libc/cross-hurd-minimal")))
(define (cross? x)
  ;; Return #t if X is a cross-libc or cross Linux.
  (or (string-prefix? libc x)
- (string-prefix? linux x)))
+ (if linux(string-prefix? linux x) #f)
+ (if hurd (string-prefix? hurd  x) #f)
+ (if mach (string-prefix? mach  x) #f)
+ (if hurd-minimal (string-prefix? hurd-minimal x) #f)))
 
(setenv "CROSS_CPATH"
-   (string-append libc "/include:"
-  linux "/include"))
+   (string-append libc "/include"
+(if linux
+(string-append ":" linux "/include") "")
+(if hurd
+(string-append ":" hurd  "/include"
+   ":" mach  "/include") "")))
(setenv "CROSS_LIBRARY_PATH"
-   (string-append libc "/lib"))
+   (string-append libc "/lib"
+(if hurd-minimal
+(string-append ":" hurd-minimal "/lib") "")))
 
(let ((cpath   (search-path-as-string->list
(getenv "CPATH")))
-- 
2.3.0

Re: texlive failure

[Ludovic Courtès]

Federico Beffa  skribis:

> So, I guess grafting takes a very long time. For this package it is
> not substantially faster than building the package itself. :-(

Grafting takes time proportional to the input size.  It’s OK for
packages of up to several MiB (the vast majority of packages), but here
we’re talking about 3 GiB.

Grafting is intentionally not substitutable, on the grounds that it’s
quite fast for most packages, and certainly faster than re-downloading
stuff.

TeX Live is obviously an exception.  I’m not sure how to address it.  We
must make grafting faster but even then, it’ll probably never be less
than 10mn for something this big.

Thoughts?

Ludo’.

Re: bug#19805: Numpy failures

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Federico Beffa  skribis:
>>
>>> At some point we should fix the support for '#:substitutable?' on hydra
>>
>> That probably means that #:substitutable? should be propagated–i.e.,
>> that anything depending on ATLAS should not be substituted.
>
> As I just wrote in the "texlive failure" thread, setting
> #:substitutable? #f might make sense for texlive.  However, in that case
> we certainly would not want to propagate that setting.
>
> So, instead of propagating it, how about simply arranging to not send
> such packages to the build slaves, instead forcing them to build it
> locally on their own?

I think there are two properties of interest: “substitutability”, and
“offloadability”.

What do we want for ATLAS, for NumPy, and for TeX Live?

However, note that we can’t currently distinguish between these two
properties: .

Thanks,
Ludo’.

Re: [ART] Logo proposal

[Luis Felipe López Acevedo]

El lun, 09-02-2015 a las 23:35 +0100, Ludovic Courtès escribió:
> Luis Felipe López Acevedo  skribis:
> 
> > I made some logos for Guix and GuixSD:
> >
> > * http://sirgazil.bitbucket.org/static/temp/img/guix/Guix.png
> > * http://sirgazil.bitbucket.org/static/temp/img/guix/GuixSD.png
> >
> > I understand if you prefer using the current Guix logo and no logo for
> > GuixSD, though. I just wanted to share anyways.
> 
> I’m very impressed by both, I like them!
> 
> It raises the two questions you mention.  I sympathize both with what
> you wrote before and your current hesitation wrt. branding.
> 

What worries me about staying close to the GNU branding is that it could
create the confusion RMS wants to avoid (people thinking that GuixSD is
*the* GNU OS and GNU's head its logo). He even suggested having a logo
for Guix and GuixSD [1][2]. So I think it would be better to play it
safe and avoid any conflict within the GNU Project. We can still
emphasise the close relationship between GuixSD and the GNU Project, and
hence the proposal of a wildebeest head as the logo for GuixSD too.

> I need to think more (and read more what others think) but yeah, why not
> a GuixSD logo.

No problem. Take your time.

Thank you everyone for your feedback, and d4n1 for the alternative logo.


[1]
http://lists.gnu.org/archive/html/gnu-system-discuss/2015-01/msg00078.html
[2]
http://lists.gnu.org/archive/html/gnu-system-discuss/2015-01/msg00079.html

-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

Re: A secure multimedia workstation

[Dirk Scheuring]

Andreas Enge wrote:

> ... Definitely you could start helping the Guix project (and your own
project) by packaging software that you are interested in and that we do
not provide yet. Some guile/scheme knowledge is helpful, but not
strictly required, see
https://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf Some
experience in installing software by hand is needed, though.  The irc
channel is usually a good place to ask for advice.

This is interesting. You seem to make packaging much easier than I
thought it would be. I wonder why that is.

I know next to nothing about Guix yet, but I know some things about
audio production software, and the problems you can experience while
running it. For example, Ricardo Wurmus (1) recently added Ardour (2), a
popular Digital Audio Workstation. Ardour depends on JACK Audio
Connection Kit (3), as do many applications in the Linux Audio
ecosystem. Multimedia distros like Ubuntu Studio and KXStudio include
JACK, plus a kernel version compiled with the -lowlatency flag, to
prevent dropouts/xruns when you're doing multichannel audio recording in
Ardour, which might also have other samplers, synthesizers and drum
machines feeding into it for playback, through JACK. So you want a
kernel that prioritizes audio throughput above all else.

I wouldn't know whether such a kernel was available for Guix currently,
and if it wasn't, I wouldn't know how to compile one, and make it
available. I would have to learn these things first, before I could
start packaging something like Ardour. At least, so I thought.

Moreover, there are production workflows which depend on Ardour being
connected to other programs (5) which in turn depend on JACK. So I
thought that I would have to track down all those interdependencies
between programs, and include knowledge about them, libraries, etc. in
the package receipt. I have to learn how to do that before I can
seriously contribute, don't I?

Also, not all audio applications support JACK. PulseAudio tends to fight
with JACK, both trying to grab the audio hardware, but several other
popular apps use PulseAudio, rather than JACK, as their audio
server. The solution here is to configure PulseAudio to pipe its output
into JACK, and as I'm trying to find out how to do that (6), I stumble
across the remark

"I performed the following changes to the files in /etc/pulse"

when I realize that there is no /etc/pulse in Guix! Rather, the
configuration files are represented - as is everything else - by their
contribution to the hash values in /nix/store. Or that's how I currently
understand it.

So it seems like I have to learn how to map the relevant parts of the
LSB to /nix/store, and I will also have to find out which parts are
relevant for any program I have to include in my package, and I have to
learn how to express this information in my receipt, so that the build
process can use it successfully. And the deeper I crawl into this rabbit
hole, the longer my list of known unknowns grows, while unknown unknowns
remain unknown. I figured it might take me a while to work through all
this, given that I have other jobs, and a family.

Or am I overcomplicating things here? Thanks for any advice,

Dirk

(1) http://lists.gnu.org/archive/html/guix-devel/2015-01/msg00477.html
(2) http://en.wikipedia.org/wiki/Ardour_%28software%29
(3) https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit
(4) 
https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit#Low_latency_scheduling
(5) http://kxstudio.sourceforge.net/Applications:Cadence
(6) 
http://askubuntu.com/questions/100862/running-jackd-on-startup-replacing-pulseaudio

Re: A secure multimedia workstation

[Ricardo Wurmus]

Dirk Scheuring writes:

> This is interesting. You seem to make packaging much easier than I
> thought it would be. I wonder why that is.

It really *is* rather simple.  I come from a background of packaging
RPMs by writing spec files and I find packaging for Guix much less
painful (to the point where it actually becomes fun).

> running it. For example, Ricardo Wurmus (1) recently added Ardour (2), a
> popular Digital Audio Workstation. Ardour depends on JACK Audio
> Connection Kit (3), as do many applications in the Linux Audio
> ecosystem. Multimedia distros like Ubuntu Studio and KXStudio include
> JACK, plus a kernel version compiled with the -lowlatency flag, to
> prevent dropouts/xruns when you're doing multichannel audio recording in
> Ardour, which might also have other samplers, synthesizers and drum
> machines feeding into it for playback, through JACK. So you want a
> kernel that prioritizes audio throughput above all else.
>
> I wouldn't know whether such a kernel was available for Guix currently,
> and if it wasn't, I wouldn't know how to compile one, and make it
> available. I would have to learn these things first, before I could
> start packaging something like Ardour. At least, so I thought.

A realtime kernel is not currently available, but there have been
discussions about simplifying the specification of custom kernel
packages by providing a wrapper function that takes a kernel
configuration file.

Ardour works without a realtime kernel (and I have been using it in the
past with stock kernels for many years).  You can prevent xruns by
increasing JACK buffers.  This increases latency, but for recording
where you don't need to listen to effects processing in realtime
(i.e. if you use direct monitoring on your equipment) this is not an
issue.  Dependent on your workflow your requirements may differ.  Still,
the Ardour package itself does not need a realtime kernel as an explicit
input, so from a packager's perspective this is a non-issue.

> Moreover, there are production workflows which depend on Ardour being
> connected to other programs (5) which in turn depend on JACK. So I
> thought that I would have to track down all those interdependencies
> between programs, and include knowledge about them, libraries, etc. in
> the package receipt. I have to learn how to do that before I can
> seriously contribute, don't I?

When I packaged Ardour I looked at the immediate dependencies.  If they
were not yet available (like JACK or LV2) I packaged those first.  Once
all build dependencies were satisfied I could build Ardour successfully.

Now, there are production workflows that require certain LV2 plugins,
for example.  But Ardour itself does not depend on them.  Ardour, using
LV2, looks up plugins in the LV2_PATH, a variable listing directories in
which LV2 plugin bundles are to be found.  At runtime you can modify
this variable and make available to Ardour whatever plugin you have
installed, long after Ardour was built.

So you don't have to learn about these interdependencies because they
don't really matter much to packaging.  In some cases programmes are not
as flexible as Ardour/LV2 and they look at hard-coded paths (e.g. CUPS
with its filters).  Only in these cases a little more effort is required.

> Also, not all audio applications support JACK. PulseAudio tends to fight
> with JACK, both trying to grab the audio hardware, but several other
> popular apps use PulseAudio, rather than JACK, as their audio
> server. The solution here is to configure PulseAudio to pipe its output
> into JACK, and as I'm trying to find out how to do that (6), I stumble
> across the remark
>
> "I performed the following changes to the files in /etc/pulse"
>
> when I realize that there is no /etc/pulse in Guix! Rather, the
> configuration files are represented - as is everything else - by their
> contribution to the hash values in /nix/store. Or that's how I currently
> understand it.

Guix (the package manager) and the Guix System Distribution (the GNU
system based on Guix and other GNU software, or GNU GSD for short) are
different things.  While Guix only stores stuff in /gnu/store/, the
system distribution may have "global" configuration files like any other
system.  I have not yet played with Pulseaudio on GNU GSD, but I'm
confident that Pulseaudio does not insist on /etc/pulse for its
configuration.  AFAIR, Pulseaudio also supports per-user configuration.

> So it seems like I have to learn how to map the relevant parts of the
> LSB to /nix/store, and I will also have to find out which parts are
> relevant for any program I have to include in my package, and I have to
> learn how to express this information in my receipt, so that the build
> process can use it successfully. And the deeper I crawl into this rabbit
> hole, the longer my list of known unknowns grows, while unknown unknowns
> remain unknown. I figured it might take me a while to work through all
> this, given that I have other jobs, and a fa

Re: A secure multimedia workstation

[Ludovic Courtès]

Dirk Scheuring  skribis:

> "I performed the following changes to the files in /etc/pulse"
>
> when I realize that there is no /etc/pulse in Guix! Rather, the
> configuration files are represented - as is everything else - by their
> contribution to the hash values in /nix/store. Or that's how I currently
> understand it.

Right.  The “Defining Services” shows how to create service definitions
that potentially populate the store with the relevant configuration
files.

So it’s a different approach from what you may be used to: users do not
/modify/ config files; instead, they formally declare the /system state/
that they want, and /instantiate/ that configuration.

Thanks,
Ludo’.

Re: using guix in virtualbox

[Ludovic Courtès]

westlake  skribis:

> The setup is informative enough from the guix install page, on top of
> which I create two empty .vdi disks, and can use qemu-nbd to transfer
> the raw image of the usb-install.
>
> It's actually pretty easy to set this up, and it took under 20
> minutes. However after rebooting and then "unplugging" the installer
> drive from Virtualbox. The grub boot menu shows up, it appears the
> init starts but soon there is a freezing issue.

It seems to be failing very early, but I’m not sure where.

It may be that the initrd is lacking a driver for the virtual disk drive
that you are using.  Do you know what drivers are needed for these?

Assuming the virtio drivers are needed, you might need to amend the OS
configuration along the following lines, and to redo the installation
with that configuration:

  (operating-system
;; ...
(initrd (lambda (file-systems . rest)
  ;; Ask for an initrd that contains the virtio drivers.
  (apply base-initrd file-systems
 #:virtio? #t
 rest)))
;; rest of the config...
)

Thanks,
Ludo’.

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

[Ludovic Courtès]

Manolis Ragkousis  skribis:

> From aaa968bbe01a57ceadf8d0c46c44e0d75d2f90cd Mon Sep 17 00:00:00 2001
> From: Marek Benc 
> Date: Thu, 5 Feb 2015 17:01:14 +0100
> Subject: [PATCH] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)
>  systems.
>
> * gnu/packages/cross-base.scm (cross-gcc-arguments): Make 'set-cross-path 
> aware of the Hurd.

Please wrap line.

> (setenv "CROSS_CPATH"
> -   (string-append libc "/include:"
> -  linux "/include"))
> +   (string-append libc "/include"
> +(if linux
> +(string-append ":" linux "/include") "")
> +(if hurd
> +(string-append ":" hurd  "/include"
> +   ":" mach  "/include") 
> "")))

Please align ‘else’ branch with ‘then’ branch:

  (if hurd
  consequent
  alternate)

> (setenv "CROSS_LIBRARY_PATH"
> -   (string-append libc "/lib"))
> +   (string-append libc "/lib"
> +(if hurd-minimal
> +(string-append ":" hurd-minimal "/lib") 
> "")))

Ditto.

As I suggested to Manolis, could you make sure that this doesn’t break
the existing GNU/Linux cross-toolchains?

Namely, could you run:

  guix build -e '(@ (gnu packages cross-base) xgcc-armhf)'

If that passes, OK to push to wip-hurd.

Thank you!

Ludo’.

Re: [PATCH 4/4] gnu: gcc: Also substitute the dynamic linker name for GNU, (ie. Hurd) systems.

[Ludovic Courtès]

Marek Benc  skribis:

> On 02/08/2015 12:22 AM, Ludovic Courtès wrote:
>
>>
>> Would this slightly more concise approach work:
>>
>>
>>
>> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
>> index 6143f5b..5cb7f8b 100644
>> --- a/gnu/packages/gcc.scm
>> +++ b/gnu/packages/gcc.scm
>> @@ -202,10 +202,11 @@ where the OS part is overloaded to denote a specific 
>> ABI---into GCC
>>
>>   ;; Fix the dynamic linker's file name.
>>   (substitute* (find-files "gcc/config"
>> - "^linux(64|-elf|-eabi)?\\.h$")
>> -  (("#define GLIBC_DYNAMIC_LINKER([^ ]*).*$" _ suffix)
>> -   (format #f "#define GLIBC_DYNAMIC_LINKER~a \"~a\"~%"
>> -   suffix
>> + 
>> "^(gnu|linux)(64|-elf|-eabi)?\\.h$")
>> +  (("#define (GLIBC|GNU_USER)_DYNAMIC_LINKER([^ ]*).*$" _
>> +kind suffix)
>> +   (format #f "#define ~a_DYNAMIC_LINKER~a \"~a\"~%"
>> +   kind suffix
>>  (string-append libc ,(glibc-dynamic-linker)
>>
>>   ;; Tell where to find libstdc++, libc, and `?crt*.o', 
>> except
>>
>>
>
>
> Most probably yes, but the previous part of the code (which joins the
> lines defining a dynamic linker) will also need to be modified to take
> GNU_USER_DYNAMIC_LINKER into account, as the code also substitutes
> some entries in the linux.h files, which are usually multiline (most
> of the time, a CHOOSE_DYNAMIC_LINKER macro)...

Hmm OK, maybe that’s a good reason to keep it the way you did, then.

OK to push your initial patch to wip-hurd, with commit log lines wrapped
to 80 chars.

Thank you!

Ludo’.

core-updates merged!

[Federico Beffa]

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

>   • The ‘glibc’ package no longer has a “locale” output, making it
> faster to build, and much smaller (the “locale” output was always
> pulled, and it took 110 MiB.)

I notice that this breaks some packages like guile-ncurses and the
(all?) packages using python-sphinx to generate documentation like
matplotlib, numpy, scipy.

Guile-ncurses was fixed by adding a new phase to generate the
"en_US.UTF-8" locale during the generation of the package, but wouldn't
it be better to keep the "en_US.UTF-8" locale? That appears to be the
default used by most packages.

Regards,
Fede

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

[Marek Benc]

On 02/10/2015 05:25 PM, Ludovic Courtès wrote:



As I suggested to Manolis, could you make sure that this doesn’t break
the existing GNU/Linux cross-toolchains?

Namely, could you run:

   guix build -e '(@ (gnu packages cross-base) xgcc-armhf)'



I've tested most of my patches with:

$ guix build coreutils --target=i686-pc-linux-gnu; # 32bit x86 GNU/Linux

since I can very easily test whether those binaries work (my virtual 
machine is an x86_64), and it all worked so far, but I'll check the 
armhf xgcc as well.




Ludo’.



--
Marek.

Improving the usability of 'guix environment'

[David Thompson]

As I use 'guix environment', I realize that I often do not want to
create an environment from the inputs of a package, but rather that I
want to create an environment from the package itself.  I didn't think
it was an issue when I did the initial development, but in practice it
has proven to be inconvenient.

For example, a development environment for guix-web requires autoconf,
automake, guile-2.0, guile-json, and libgcrypt.  To create such an
environment, I currently use a dummy package:

;; env.scm

(package
  (name "guix-web")
  (version "0.1")
  (source ".")
  (build-system gnu-build-system)
  (native-inputs
   `(("autoconf" ,autoconf)
 ("automake" ,automake)))
  (inputs
   `(("guile" ,guile-2.0)
 ("guile-json" ,guile-json)
 ("libgcrypt" ,libgcrypt)))
  (synopsis "Web frontend for GNU Guix")
  (description "Guix-web is a web interface to the GNU Guix package
manager written in GNU Guile Scheme and JavaScript.")
  (home-page "https://gitorious.org/guix-web/guix-web";)
  (license agpl3+))

;; shell

guix environment -l env.scm

But all of that boilerplate is unnecessary since it's not possible to
actually build the package successfully without a proper hash of the
source AFAICT.  Really, I would rather just use a simple list of
packages:

(list autoconf automake guile-2.0 guile-json libgcrypt)

And other times it would be nice to create an ad-hoc environment from
the shell for quickly experimenting with something and not polluting a
profile:

guix environment guile guile-sdl # let's tinker with SDL in Guile

I propose adding a new flag that indicates whether we want the packages
themselves or their inputs in the environment.  If we assume that the
default behavior is to include the packages themselves, a --inputs flag
could indicate to use the package(s) inputs instead:

guix environment --inputs emacs

Thoughts?

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

[Ludovic Courtès]

Marek Benc  skribis:

> On 02/10/2015 05:25 PM, Ludovic Courtès wrote:
>
>>
>> As I suggested to Manolis, could you make sure that this doesn’t break
>> the existing GNU/Linux cross-toolchains?
>>
>> Namely, could you run:
>>
>>guix build -e '(@ (gnu packages cross-base) xgcc-armhf)'
>>
>
> I've tested most of my patches with:
>
> $ guix build coreutils --target=i686-pc-linux-gnu; # 32bit x86 GNU/Linux
>
> since I can very easily test whether those binaries work (my virtual
> machine is an x86_64), and it all worked so far, but I'll check the
> armhf xgcc as well.

OK, very well.  So you can go ahead, thanks!

Ludo’.

Lack of locales in build environment

[Ludovic Courtès]

Federico Beffa  skribis:

> Guile-ncurses was fixed by adding a new phase to generate the
> "en_US.UTF-8" locale during the generation of the package, but wouldn't
> it be better to keep the "en_US.UTF-8" locale? That appears to be the
> default used by most packages.

That’s an open question.  The vast majority of packages is happy with
just the C locale, and some need something more.

So far the approach has been to fix these one by one (that’s 4 packages
so far) but if it happens to be frequent enough or cumbersome, we can
change that in the next core-updates to have en_US.UTF-8 available by
default.

WDYT?

Thanks,
Ludo’.

Re: Improving the usability of 'guix environment'

[Ludovic Courtès]

David Thompson  skribis:

> But all of that boilerplate is unnecessary since it's not possible to
> actually build the package successfully without a proper hash of the
> source AFAICT.  Really, I would rather just use a simple list of
> packages:
>
> (list autoconf automake guile-2.0 guile-json libgcrypt)

What about adding a case for the handling of ‘-l’ such that, if the file
evaluates to a list of packages, it does what you suggest?

> And other times it would be nice to create an ad-hoc environment from
> the shell for quickly experimenting with something and not polluting a
> profile:
>
> guix environment guile guile-sdl # let's tinker with SDL in Guile

Right.

> I propose adding a new flag that indicates whether we want the packages
> themselves or their inputs in the environment.  If we assume that the
> default behavior is to include the packages themselves, a --inputs flag
> could indicate to use the package(s) inputs instead:
>
> guix environment --inputs emacs

That makes sense.

In terms of UI, what about rather something keeping an interface close
to that of ‘guix package’:

  guix environment -i guile guile-sdl
  # semantically equivalent to ‘guix package -i guile guile-sdl’

Now that I think of it, we could even move -E to ‘guix package’ itself:
that would make it easy to create a scratch environment based on an
existing profile.

WDYT?

Ludo’.

Re: Lack of locales in build environment

[Federico Beffa]

On Tue, Feb 10, 2015 at 6:13 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> Guile-ncurses was fixed by adding a new phase to generate the
>> "en_US.UTF-8" locale during the generation of the package, but wouldn't
>> it be better to keep the "en_US.UTF-8" locale? That appears to be the
>> default used by most packages.
>
> That’s an open question.  The vast majority of packages is happy with
> just the C locale, and some need something more.
>
> So far the approach has been to fix these one by one (that’s 4 packages
> so far) but if it happens to be frequent enough or cumbersome, we can
> change that in the next core-updates to have en_US.UTF-8 available by
> default.

The "scipy ecosystem" documentation makes use of sphinx to build the
documentation and requires an UTF-8 locale. I do not know if this is
specific to scipy and friends of if it is a characteristic of sphinx
(that's why I speculated that there may be more python packages in
need for that).

>From my point of view it would be good to include en_US.UTF-8 by
default for two reasons: (i) we already are at 7 (4+3) packages
requiring an UTF-8 locale and, I guess, that this number is doomed to
increase in the following years. (ii) This is another small step in
making maintenance easier by providing an environment setting that
sometimes helps.

Regards,
Fede

Re: Improving the usability of 'guix environment'

[David Thompson]

Ludovic Courtès  writes:

> David Thompson  skribis:
>
>> But all of that boilerplate is unnecessary since it's not possible to
>> actually build the package successfully without a proper hash of the
>> source AFAICT.  Really, I would rather just use a simple list of
>> packages:
>>
>> (list autoconf automake guile-2.0 guile-json libgcrypt)
>
> What about adding a case for the handling of ‘-l’ such that, if the file
> evaluates to a list of packages, it does what you suggest?

I'm hesitant to do that, because I would also like for a list of
packages to be usable for building the environment as it's done
currently.  Only allowing a single package in a file is a limitation
right now.

>> I propose adding a new flag that indicates whether we want the packages
>> themselves or their inputs in the environment.  If we assume that the
>> default behavior is to include the packages themselves, a --inputs flag
>> could indicate to use the package(s) inputs instead:
>>
>> guix environment --inputs emacs
>
> That makes sense.
>
> In terms of UI, what about rather something keeping an interface close
> to that of ‘guix package’:
>
>   guix environment -i guile guile-sdl
>   # semantically equivalent to ‘guix package -i guile guile-sdl’

So without the -i switch, it would behave as it does now?  Okay, but I
guess I would prefer to optimize for the common case, which in my case
would be having -i on by default.

> Now that I think of it, we could even move -E to ‘guix package’ itself:
> that would make it easy to create a scratch environment based on an
> existing profile.

I'm a bit confused about that.  Are you suggesting we merge 'guix
environment' into 'guix package'?

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Lack of locales in build environment

[John Darrington]

On Tue, Feb 10, 2015 at 06:36:58PM +0100, Federico Beffa wrote:
 On Tue, Feb 10, 2015 at 6:13 PM, Ludovic Courtès  wrote:
 > Federico Beffa  skribis:
 >
 >> Guile-ncurses was fixed by adding a new phase to generate the
 >> "en_US.UTF-8" locale during the generation of the package, but wouldn't
 >> it be better to keep the "en_US.UTF-8" locale? That appears to be the
 >> default used by most packages.
 >
 > That’s an open question.  The vast majority of packages is happy with
 > just the C locale, and some need something more.
 >
 > So far the approach has been to fix these one by one (that’s 4 packages
 > so far) but if it happens to be frequent enough or cumbersome, we can
 > change that in the next core-updates to have en_US.UTF-8 available by
 > default.
 
 
(i) we already are at 7 (4+3) packages requiring an UTF-8 locale 

Then that is a bug which should be filed against those pacakges.

 (ii) This is another small step in
 making maintenance easier by providing an environment setting that
 sometimes helps.

It sounds like a slippery slope.  If we shovel in everything into the defaults, 
that might possibly help somebody do something, someday we'll end up with a very
bloated system.

The C locale is the canonical locale. UTF-8 is not the only characater encoding 
in
the world.  English is not the only language in the world, and US English is not
the only dialect of English.

J'
 

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Locales not working

[Andreas Enge]

Hello,

after the latest upgrade of my profile, the locales do not seem to work
any more. All the fancy utf8 in your messages is broken in mutt, and
the locale command returns:
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Do I need to set anything special? Install a separate package?

In the meantime, hooray for "--roll-back"! Äöüß!

Andreas

Re: Improving the usability of 'guix environment'

[Andreas Enge]

On Tue, Feb 10, 2015 at 11:45:02AM -0500, David Thompson wrote:
> guix environment guile guile-sdl # let's tinker with SDL in Guile

Is this not already covered by doing a "guix package -i ...", tinkering,
and a roll-back? There is one more line to type for the roll-back.
The functionality with installing inputs is much more useful as it saves
a lot of typing, and looking up which inputs are needed.

Andreas

Re: Locales not working

[Andreas Enge]

Ah, it turns out that I wrote my message before reading the ongoing discussion
on locales. What a coincidence! So we were at least two being bitten by this
bug (yes, yes) at the same time! I do not think it is reasonable to break
systems for saving 100MB.

The code of glibc states
;; Installing a locale archive with all the locales is to
;; expensive (~100 MiB), so we rely on users to install the
;; locales they really want.
But how do I do that? I wondered if there was an additional "locale" output
of glibc, but there is not.

$ guix package -A locale
does not return anything useful.

There is a section 6.2.6 in the manual, but it only speaks about GSD,
not about Guix inside other systems.

So there needs to be a simple way to install locales to be used by Guix
packages, and it needs to be documented. Or the patch could be reverted.

Andreas

Re: Improving the usability of 'guix environment'

[David Thompson]

Andreas Enge  writes:

> On Tue, Feb 10, 2015 at 11:45:02AM -0500, David Thompson wrote:
>> guix environment guile guile-sdl # let's tinker with SDL in Guile
>
> Is this not already covered by doing a "guix package -i ...", tinkering,
> and a roll-back? There is one more line to type for the roll-back.
> The functionality with installing inputs is much more useful as it saves
> a lot of typing, and looking up which inputs are needed.

That works, but it creates more of a mess than it ought to and isn't as
automated.  I do not want to add a new generation to my profile (that
then must be explicitly GC'd later), and I want all of the environment
variables automatically setup for me somewhat like the build daemon
does.  Furthermore, 'guix environment' can create a pure environment,
where, in this example, only guile and guile-sdl things would be present
in the search paths.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: A secure multimedia workstation

[Andreas Enge]

On Tue, Feb 10, 2015 at 04:21:27PM +0100, Dirk Scheuring wrote:
> This is interesting. You seem to make packaging much easier than I
> thought it would be. I wonder why that is.

Most packages are easy, because they just require a few declarations.
One should start from easy ones, learn and move on to more complex ones.

> Moreover, there are production workflows which depend on Ardour being
> connected to other programs (5) which in turn depend on JACK. So I
> thought that I would have to track down all those interdependencies
> between programs, and include knowledge about them, libraries, etc. in
> the package receipt. I have to learn how to do that before I can
> seriously contribute, don't I?

I am not sure what you mean exactly. As Ricardo said, sometimes it is
only necessary to recursively track down the dependencies ("inputs")
of a package and then package first the ones with no inputs themselves.
And then the ones which have only inputs that you have already packaged.
And so on.

> Or am I overcomplicating things here? Thanks for any advice,

Maybe. I would suggest to start working with the Guix package manager
on top of your current system, check whether the packages we already have
satisfy your needs and start packaging the others, or file bug reports
and patches for packages that do not work as expected. It requires practice,
but not necessarily to understand everything from the start!

Andreas

Re: core-updates merged!

[Andreas Enge]

On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote:
> Guile-ncurses was fixed by adding a new phase to generate the
> "en_US.UTF-8" locale during the generation of the package

This is interesting information! If I understand things correctly, I think
a solution would be to have tons of locale-XX packages, where XX stands for
the country code, the contents of which are created by calls to localedef.
And maybe a package locales-all for people who have space and do not wish
to choose. And a search path definition in glibc to set LOCPATH.

What do you think?

Andreas

Re: core-updates merged!

[John Darrington]

On Tue, Feb 10, 2015 at 07:46:48PM +0100, Andreas Enge wrote:
 On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote:
 > Guile-ncurses was fixed by adding a new phase to generate the
 > "en_US.UTF-8" locale during the generation of the package
 
 This is interesting information! If I understand things correctly, I think
 a solution would be to have tons of locale-XX packages, where XX stands for
 the country code, the contents of which are created by calls to localedef.
 And maybe a package locales-all for people who have space and do not wish
 to choose. And a search path definition in glibc to set LOCPATH.
 
 What do you think?
 
To me, it sounds like a good idea.I have never liked the debian way where 
the
locales are compiled at install time.

J'


 

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: core-updates merged!

[Federico Beffa]

On Tue, Feb 10, 2015 at 7:46 PM, Andreas Enge  wrote:
> On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote:
>> Guile-ncurses was fixed by adding a new phase to generate the
>> "en_US.UTF-8" locale during the generation of the package
>
> This is interesting information! If I understand things correctly, I think
> a solution would be to have tons of locale-XX packages, where XX stands for
> the country code, the contents of which are created by calls to localedef.
> And maybe a package locales-all for people who have space and do not wish
> to choose. And a search path definition in glibc to set LOCPATH.
>
> What do you think?

I like this idea as well.

Regards,
Fede

Re: Lack of locales in build environment

[Federico Beffa]

John Darrington  writes:
> (i) we already are at 7 (4+3) packages requiring an UTF-8 locale
>
> Then that is a bug which should be filed against those pacakges.

I just discovered the problem with the "scipy ecosystem" packages
today and intended to fix them. But, before submitting changes, I wanted
to check with the ML.

If we decide to keep the status quo, then I will fix the
packages. Otherwise, if we introduce a default UTF-8 locale or implement
Andreas's suggestion, I will file a bug to avoid forgetting.

>
>  (ii) This is another small step in
>  making maintenance easier by providing an environment setting that
>  sometimes helps.
>
> It sounds like a slippery slope.  If we shovel in everything into the 
> defaults,
> that might possibly help somebody do something, someday we'll end up with a 
> very
> bloated system.

The C locale is really an ancient relict. I think adding a more
modern default locale to the build environment doesn't really bloat the
system.

>
> The C locale is the canonical locale. UTF-8 is not the only characater 
> encoding in
> the world.  English is not the only language in the world, and US English is 
> not
> the only dialect of English.

I'm not a native english speaker and I understand the problem very
well. In spite of this I do not know of any package providing
documentation in other languages than english. That's the reason for
suggesting a default locale of en_US.UTF-8 for the build systems.


Regards,
Fede

CA certificates

[Andreas Enge]

The attached patch series
1) adds a (private) python script to extract single certificates in .pem 
   format from a big textfile in mozilla source format;
2) adds the package nss-certs, which contains the certificates thus extracted
   in OUT/etc/ssl/certs, preprocessed with c_rehash for use with openssl;
3) adds "etc/ssl/certs" as a native-search-path for SSL_CERT_DIR to openssl.

So if you do a
   guix package -i openssl nss-certs youtube-dl
and add SSL_CERT_DIR as stipulated by the text output after the installation,
things work out of the box.

The search path definition means that we could have alternative root
certificate packages (potentially one per certification authority) and that
the user could install the ones he trusts.

The patches currently are in a branch wip-certs. Suggestions are welcome.

Andreas

Re: Lack of locales in build environment

[Ludovic Courtès]

John Darrington  skribis:

> The C locale is the canonical locale. UTF-8 is not the only characater 
> encoding in
> the world.  English is not the only language in the world, and US English is 
> not
> the only dialect of English.

You’re right, of course.  For the packages discussed, what matters above
all is to provide their build environment with a UTF-8 locale, and en_US
seems like the least disruptive one from a technical viewpoint.  But of
course, that does not have any impact on what locales people may want to
use in their own environment.

Ludo’.

Re: Lack of locales in build environment

[Ludovic Courtès]

Federico Beffa  skribis:

> From my point of view it would be good to include en_US.UTF-8 by
> default for two reasons: (i) we already are at 7 (4+3) packages
> requiring an UTF-8 locale and, I guess, that this number is doomed to
> increase in the following years. (ii) This is another small step in
> making maintenance easier by providing an environment setting that
> sometimes helps.

Right.

How about this: we make a package with a bunch of locales, and in
core-updates we add a specification for $LOCPATH to glibc.

For those packages, we would just add that locales package to their
inputs and be done with it.

WDYT?

Ludo’.

Re: Improving the usability of 'guix environment'

[Ludovic Courtès]

David Thompson  skribis:

> Ludovic Courtès  writes:
>
>> David Thompson  skribis:
>>
>>> But all of that boilerplate is unnecessary since it's not possible to
>>> actually build the package successfully without a proper hash of the
>>> source AFAICT.  Really, I would rather just use a simple list of
>>> packages:
>>>
>>> (list autoconf automake guile-2.0 guile-json libgcrypt)
>>
>> What about adding a case for the handling of ‘-l’ such that, if the file
>> evaluates to a list of packages, it does what you suggest?
>
> I'm hesitant to do that, because I would also like for a list of
> packages to be usable for building the environment as it's done
> currently.  Only allowing a single package in a file is a limitation
> right now.

Yeah.

>>> I propose adding a new flag that indicates whether we want the packages
>>> themselves or their inputs in the environment.  If we assume that the
>>> default behavior is to include the packages themselves, a --inputs flag
>>> could indicate to use the package(s) inputs instead:
>>>
>>> guix environment --inputs emacs
>>
>> That makes sense.
>>
>> In terms of UI, what about rather something keeping an interface close
>> to that of ‘guix package’:
>>
>>   guix environment -i guile guile-sdl
>>   # semantically equivalent to ‘guix package -i guile guile-sdl’
>
> So without the -i switch, it would behave as it does now?  Okay, but I
> guess I would prefer to optimize for the common case, which in my case
> would be having -i on by default.
>
>> Now that I think of it, we could even move -E to ‘guix package’ itself:
>> that would make it easy to create a scratch environment based on an
>> existing profile.
>
> I'm a bit confused about that.  Are you suggesting we merge 'guix
> environment' into 'guix package'?

A possibility might be to:

  • keep ‘guix environment’ as is; after all, ‘guix environment emacs’
really reads as “the environment for [the development of] Emacs”;

  • add a -E option to ‘guix package’ (like the -E of ‘guix
environment’).

Example:

  # start a shell where guile and guile-sdl are available in addition to
  # what’s in ~/.guix-profile
  $ guix package -i guile guile-sdl -E $SHELL

  # start a shell where only guile and guile-sdl are available
  $ guix package -i guile guile-sdl --scratch -E $SHELL

  # start a shell in an environment which is my profile minus emacs
  # plus vim and with an upgraded zile
  $ guix package -r emacs -i vim -u zile --pure -E $SHELL

Hmm.

I’ve not completely convinced myself.

Maybe keeping it in ‘guix environment’ is wiser.  I’m not quite sure
that changing the default behavior is desirable though.

Thoughts?

Ludo’.

Re: [PATCH 0/4]: Add various audio libraries

[Ricardo Wurmus]

Ludovic Courtès writes:
>> From 3bb3b7346f44f8e4849efc7a5fc8b465a974d625 Mon Sep 17 00:00:00 2001
>> From: rekado 
>> Date: Thu, 29 Jan 2015 10:12:00 +0100
>> Subject: [PATCH 4/4] gnu: Add LV2.
>>
>> * gnu/packages/audio.scm (lv2): New variable.
>
> [...]
>
>> +(synopsis "LV2 audio plugin standard")
>> +(description
>> + "LV2 is an open standard for audio plugins and host applications.  At 
>> its
>> +core, LV2 is a simple stable interface, accompanied by extensions which add
>> +functionality to support the needs of increasingly powerful audio 
>> software.")
>
> It’s not clear to me what this all means; I guess LV2 is not a
> “standard” as in RFC or ISO, because it’s software.  That said, I don’t
> have any suggestions, so I’ll leave it up to your creativity.  :-)

I changed it from "standard" to "specification" because it's neither a
"standard" in RFC or ISO sense, nor is it software.  It's ttl files that
outline feature.  These specifications can be turned into code or
workable data; they serve as an interface declaration, so I think
"specification" is really the most appropriate term here.

Attached is the new patch.

~~ Ricardo

>From 02ae9dbb1c344187d0b9e5328533a8aed16d081a Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Thu, 5 Feb 2015 22:40:06 +0100
Subject: [PATCH] gnu: Add LV2.

* gnu/packages/audio.scm (lv2): New variable.
---
 gnu/packages/audio.scm | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index 9227367..f83c5d2 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -158,3 +158,33 @@ synchronous execution of all clients, and low latency operation.")
  "liblo is a lightweight library that provides an easy to use
 implementation of the Open Sound Control (OSC) protocol.")
 (license license:lgpl2.1+)))
+
+(define-public lv2
+  (package
+(name "lv2")
+(version "1.10.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://lv2plug.in/spec/lv2-";
+ version
+ ".tar.bz2"))
+ (sha256
+  (base32
+   "1md41x9snrp4mcfyli7lyfpvcfa78nfy6xkdy84kppnl8m5qw378"
+(build-system waf-build-system)
+(arguments
+ `(#:tests? #f  ; no check target
+   #:configure-flags '("--lv2-system")))
+(inputs
+ ;; Leaving off cairo and gtk+-2.0 which are needed for example plugins
+ `(("libsndfile" ,libsndfile)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(home-page "http://lv2plug.in/";)
+(synopsis "LV2 audio plugin specification")
+(description
+ "LV2 is an open specification for audio plugins and host applications.
+At its core, LV2 is a simple stable interface, accompanied by extensions which
+add functionality to support the needs of increasingly powerful audio
+software.")
+(license license:isc)))
-- 
2.1.0

Re: [PATCH 0/5]: Add even more LV2 libraries

[Ricardo Wurmus]

Ludovic Courtès writes:
>> - serd
>> - sord
>> - sratom
>
> I think these should go to rdf.scm, no?

I moved serd and sord to rdf.scm, but left sratom in audio.scm because
it is very specific to LV2 atoms.

>> - lilv
>> - suil
>
> Its ‘description’ is bit long, IMO.

The description has been shortened.  Attached are updated patches for
these five packages.

~~ Ricardo

>From a17b861614f20d98e240c975d58d00470c912830 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 10 Feb 2015 10:07:57 +0100
Subject: [PATCH 1/5] gnu: Add serd.

* gnu/packages/rdf.scm (serd): New variable.
---
 gnu/packages/rdf.scm | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/rdf.scm b/gnu/packages/rdf.scm
index ff74b2f..dde883b 100644
--- a/gnu/packages/rdf.scm
+++ b/gnu/packages/rdf.scm
@@ -19,12 +19,13 @@
 
 (define-module (gnu packages rdf)
   #:use-module ((guix licenses)
-#:select (bsd-style gpl2 lgpl2.0+ lgpl2.1 lgpl2.1+))
+#:select (bsd-style isc gpl2 lgpl2.0+ lgpl2.1 lgpl2.1+))
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system python)
+  #:use-module (guix build-system waf)
   #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages databases)
@@ -228,6 +229,31 @@ Turtle/N3 and read them in SPARQL XML, RDF/XML and Turtle/N3.")
 and triple stores.")
 (license lgpl2.1+))) ; or any choice of gpl2+ or asl2.0
 
+(define-public serd
+  (package
+(name "serd")
+(version "0.20.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://download.drobilla.net/serd-";
+ version
+ ".tar.bz2"))
+ (sha256
+  (base32
+   "1gxbzqsm212wmn8qkdd3lbl6wbv7fwmaf9qh2nxa4yxjbr7mylb4"
+(build-system waf-build-system)
+(arguments `(#:tests? #f)) ; no check target
+(home-page "http://drobilla.net/software/serd/";)
+(synopsis "Library for RDF syntax supporting Turtle and NTriples")
+(description
+ "Serd is a lightweight C library for RDF syntax which supports reading
+and writing Turtle and NTriples.  Serd is not intended to be a swiss-army
+knife of RDF syntax, but rather is suited to resource limited or performance
+critical applications (e.g. converting many gigabytes of NTriples to Turtle),
+or situations where a simple reader/writer with minimal dependencies is
+ideal (e.g. in LV2 implementations or embedded applications).")
+(license isc)))
+
 (define-public soprano
   (package
 (name "soprano")
-- 
2.1.0

>From 92c58fd1ba47e84066100379248b4a4682414eef Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 10 Feb 2015 10:09:39 +0100
Subject: [PATCH 2/5] gnu: Add sord.

* gnu/packages/rdf.scm (sord): New variable.
---
 gnu/packages/rdf.scm | 24 
 1 file changed, 24 insertions(+)

diff --git a/gnu/packages/rdf.scm b/gnu/packages/rdf.scm
index dde883b..588a4b7 100644
--- a/gnu/packages/rdf.scm
+++ b/gnu/packages/rdf.scm
@@ -254,6 +254,30 @@ or situations where a simple reader/writer with minimal dependencies is
 ideal (e.g. in LV2 implementations or embedded applications).")
 (license isc)))
 
+(define-public sord
+  (package
+(name "sord")
+(version "0.12.2")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://download.drobilla.net/sord-";
+ version
+ ".tar.bz2"))
+ (sha256
+  (base32
+   "0rq7vafdv4vsxi6xk9zf5shr59w3kppdhqbj78185rz5gp9kh1dx"
+(build-system waf-build-system)
+(arguments `(#:tests? #f)) ; no check target
+(inputs
+ `(("serd" ,serd)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(home-page "http://drobilla.net/software/sord/";)
+(synopsis "C library for storing RDF data in memory")
+(description
+ "Sord is a lightweight C library for storing RDF data in memory.")
+(license isc)))
+
 (define-public soprano
   (package
 (name "soprano")
-- 
2.1.0

>From f82f0d9c9ad4205b2ed5dae4dc157f204ffbd941 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 10 Feb 2015 10:21:30 +0100
Subject: [PATCH 3/5] gnu: Add sratom.

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

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index f83c5d2..1105ec2 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -31,6 +31,7 @@
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages pulseaudio)  ;libsndfile, libsamplerate
   #:use-module (gnu packages python)
+  #:use-module (gnu packages rdf)
   #:use-module (gnu packages readline)
   #:use