Re: reproducibility

2016-01-13 Thread Efraim Flashner
On Wed, 13 Jan 2016 09:13:25 +0100
Federico Beffa  wrote:

> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès  wrote:
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> 
> Just out of curiosity, could you provide a concrete example where the
> order is purposefully specified.
> 
> Thanks,
> Fede
> 

I haven't had time (since reading this) to test if the order matters or not,
but some of the openstack packages say they care about order:
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/test-requirements.txt?h=2.0.0

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


pgp_V1HtrtbD9.pgp
Description: OpenPGP digital signature


Re: reproducibility

2016-01-13 Thread Federico Beffa
On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès  wrote:
>>> Federico Beffa  skribis:
>>>
 I've noticed that a derivation is a function of the order of the
 inputs. As an example, the following two input orders give rise to two
 distinct derivations:

 A)

 (inputs
  `(("texlive" ,texlive)
("texinfo" ,texinfo)
("m4" ,m4)
("libx11" ,libx11))

 B)
 (inputs
  `(("texinfo" ,texinfo)
("texlive" ,texlive)
("m4" ,m4)
("libx11" ,libx11))

 Is this intentional?
>>>
>>> Yes.  There are several places where order matters, most importantly
>>> search paths, and these are computed from the input lists.
>>
>> If order matters, it would probably be more robust to force internally
>> a specific order rather than relying on the (often random) order
>> defined in a package recipe (possibly created by an importer, ...).
>
> Most of the time any order would work, but I can imagine situations
> where the packager could purposefully choose a specific order.  So I’d
> rather not do any automatic sorting, if that’s what you have in mind.

Just out of curiosity, could you provide a concrete example where the
order is purposefully specified.

Thanks,
Fede



Re: reproducibility

2016-01-13 Thread Ludovic Courtès
Federico Beffa  skribis:

> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès  wrote:
>> Federico Beffa  skribis:
>>
>>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès  wrote:
 Federico Beffa  skribis:

> I've noticed that a derivation is a function of the order of the
> inputs. As an example, the following two input orders give rise to two
> distinct derivations:
>
> A)
>
> (inputs
>  `(("texlive" ,texlive)
>("texinfo" ,texinfo)
>("m4" ,m4)
>("libx11" ,libx11))
>
> B)
> (inputs
>  `(("texinfo" ,texinfo)
>("texlive" ,texlive)
>("m4" ,m4)
>("libx11" ,libx11))
>
> Is this intentional?

 Yes.  There are several places where order matters, most importantly
 search paths, and these are computed from the input lists.
>>>
>>> If order matters, it would probably be more robust to force internally
>>> a specific order rather than relying on the (often random) order
>>> defined in a package recipe (possibly created by an importer, ...).
>>
>> Most of the time any order would work, but I can imagine situations
>> where the packager could purposefully choose a specific order.  So I’d
>> rather not do any automatic sorting, if that’s what you have in mind.
>
> Just out of curiosity, could you provide a concrete example where the
> order is purposefully specified.

No specific example, sorry, but it’s plausible IMO.  With enough CPU
power, we could try rebuilding everything with a random order and see
what breaks.

Thanks,
Ludo’.



Re: [PATCHES] Update orfm and package test requirements.

2016-01-13 Thread Ben Woodcroft

Hi,

I've been a little while responding as I intending on releasing a new 
OrfM version before bothering you again. I'd push all this myself but 
wanted to check one last thing so I don't sound too enthusiastic about 
my own software.

+
+(define-public ruby-bio-commandeer
+  (package
+(name "ruby-bio-commandeer")
+(version "0.1.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (rubygems-uri "bio-commandeer" version))
+   (sha256
+(base32
+ "061jxa6km92qfwzl058r2gp8gfcsbyr7m643nw1pxvmjdswaf6ly"
+(build-system ruby-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (replace 'check
+   ;; Run test without calling 'rake' so that jeweler is
+   ;; not required as an input.
+   (lambda _
+ (zero? (system* "rspec" "spec/bio-commandeer_spec.rb")))
+(propagated-inputs
+ `(("ruby-bio-logger" ,ruby-bio-logger)
+   ("ruby-systemu" ,ruby-systemu)))
+(native-inputs
+ `(("bundler" ,bundler)
+   ("ruby-rspec" ,ruby-rspec)))
+(synopsis "Simplified running of shell commands from within Ruby")
+(description
+ "Bio-commandeer is a dead simple opinionated method of running shell
+commands from within Ruby.  The advantage of bio-commandeer over other methods
+of running external commands is that when something goes wrong, the error
+message that is reported gives extra detail to ease debugging.")

I don’t really like the first sentence.  How about

“Bio-comandeer lets you run shell commands from within Ruby.  ...”
That wasn't the best sentence before, fo so. I wonder if the replacement 
is a little bland though. How about (as attached),


+ "Bio-commandeer provides an opinionated method of running shell 
commands

+from within Ruby.  The advantage of bio-commandeer over other methods of
+running external commands is that when something goes wrong, the 
@code{STDOUT}

+and @code{STDERR} are reported, giving extra detail to ease debugging.")

OK? I made scattered other changes too on top of accepting your 
suggestions, but I don't imagine a full re-review is necessary.

Thanks for the review.
ben

>From 5d535f5c465c947140a2917fb9c0aaa31b651102 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Sat, 21 Nov 2015 10:37:34 +1000
Subject: [PATCH 3/3] gnu: orfm: Update to 0.5.3.

* gnu/packages/bioinformatics.scm (orfm): Update to 0.5.3.
[native-inputs]: Add inputs required for tests.
[description]: Add commas.
---
 gnu/packages/bioinformatics.scm | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
index 82506c1..9c2223f 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -2079,7 +2079,7 @@ that a read originated from a particular isoform.")
 (define-public orfm
   (package
 (name "orfm")
-(version "0.4.1")
+(version "0.5.3")
 (source (origin
   (method url-fetch)
   (uri (string-append
@@ -2087,12 +2087,16 @@ that a read originated from a particular isoform.")
 version "/orfm-" version ".tar.gz"))
   (sha256
(base32
-"05fmw145snk646ly076zby0fjav0k7ysbclck5d4s9pmgcfpijc2"
+"0vb6d771gl4mix8bwx919x5ayy9pkj44n7ki336nz3rz2rx4c7gk"
 (build-system gnu-build-system)
 (inputs `(("zlib" ,zlib)))
+(native-inputs
+ `(("ruby-bio-commandeer" ,ruby-bio-commandeer)
+   ("ruby-rspec" ,ruby-rspec)
+   ("ruby" ,ruby)))
 (synopsis "Simple and not slow open reading frame (ORF) caller")
 (description
- "An ORF caller finds stretches of DNA that when translated are not
+ "An ORF caller finds stretches of DNA that, when translated, are not
 interrupted by stop codons.  OrfM finds and prints these ORFs.")
 (home-page "https://github.com/wwood/OrfM;)
 (license license:lgpl3+)))
-- 
2.6.3

>From 4ded5e53c22ada399c976989dbe10cbf376c4e98 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Sat, 21 Nov 2015 10:03:41 +1000
Subject: [PATCH 2/3] gnu: Add ruby-bio-commandeer.

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

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 21f282a..59fe1cd 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -2958,3 +2958,38 @@ there is no danger of full pipes or threading issues hanging your process or
 subprocess.")
 (home-page "https://github.com/ahoward/systemu;)
 (license license:ruby)))
+
+(define-public ruby-bio-commandeer
+  (package
+(name "ruby-bio-commandeer")
+(version "0.1.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (rubygems-uri "bio-commandeer" version))
+   (sha256
+(base32
+ 

Re: [PATCH 3/4] gnu: emacs: Find packages in "~/.guix-profile".

2016-01-13 Thread Ludovic Courtès
Alex Kost  skribis:

> Ludovic Courtès (2016-01-10 23:28 +0300) wrote:

[...]

>> Also, on GuixSD, should we remove the default EMACSLOADPATH as well as
>> /etc/emacs/site-start.el?
>
> If the goal for GuixSD is just to make Emacs packages work, then yes;
> but if the intention is also to make "M-x guix-..." commands work
> out-of-the-box, then we should leave it as it is now.

Oh right; we should leave it as is.

Thanks,
Ludo’.



PulseAudio

2016-01-13 Thread Ludovic Courtès
Leo Famulari  skribis:

> I guess the factors are:
> 1) Does GuixSD have a default audio setup that we should target? If
> GuixSD uses PulseAudio, then I think it would be good for eSpeak to be
> integrated into that sytem.
> 2) Does this package, which launches PulseAudio, work for anyone on a
> foreign distro?

It’s not written anywhere, but I think most of our audio packages target
PulseAudio (that’s what I use on GuixSD.)  I’m in favor of consistently
using it, and it would probably be best to write it down in the manual.

Thoughts?

Ludo’.



Re: [PATCHES] Update orfm and package test requirements.

2016-01-13 Thread Ricardo Wurmus

Ben Woodcroft  writes:

>> “Bio-comandeer lets you run shell commands from within Ruby.  ...”
> That wasn't the best sentence before, fo so. I wonder if the replacement 
> is a little bland though. How about (as attached),
>
> + "Bio-commandeer provides an opinionated method of running shell 
> commands
> +from within Ruby.  The advantage of bio-commandeer over other methods of
> +running external commands is that when something goes wrong, the 
> @code{STDOUT}
> +and @code{STDERR} are reported, giving extra detail to ease debugging.")

This is almost okay, I think.  I would add a couple of words to state
that messages or text *printed* to STDOUT/STDERR (rather than the
streams themselves) are reported.

> From b7d92cbfd47fa9f4807ea72d570d703b78fb59f7 Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft 
> Date: Sat, 21 Nov 2015 10:02:11 +1000
> Subject: [PATCH 1/3] gnu: Add ruby-systemu.

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

[...]

> +(arguments
> + `(#:phases
> +   (modify-phases %standard-phases
> + (add-before 'check 'patch-and-set-version
> +   (lambda _
> + (setenv "VERSION" ,version)
> + #t)

That’s an odd phase name; why “patch”?  Is setting the environment
variable the only way to set the version or would a make-flag work here,
too?  (I haven’t checked if the ruby-build-system respects make-flags.)

The rest looks good to me.  Thanks!

~~ Ricardo



gnunet-gtk (wip, open for others to debug)

2016-01-13 Thread N. Gillmann / Ni*
As mentioned earlier in #guix, here is the most current version of
gnune
t-gtk I am stuck with debugging.
Due to lack of time and documentation I
forgot where it is failing,
but it is just a matter of getting the
arguments to 'make' right iirc.
ricardo wanted to take this over.

Something currently looks like lines are broken, so I attach the .patch itself.


>From 41a4b5b4f7c3cfc4bd2afedc0da9b256eca7b16b Mon Sep 17 00:00:00 2001
From: Ni* Gillmann 
Date: Wed, 13 Jan 2016 18:36:31 +0100
Subject: [PATCH] gnu/packages/gnunet gnunet-gtk added

This is the most recent, almost building commit of gnunet-gtk
Compare to https://notabug.org/anonymiss/libertad-overlay/src/master/net-misc
for a building version (ebuild, on gentoo) and requirements.

This patch tries to build and work with the guix provided version of
gladeui, in its current state it fails and I want other people with
more experience in the guix ecosystem to finish it.
---
 gnu/packages/gnunet.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 11e5aa8..91bbe1f 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2014 Sree Harsha Totakura 
 ;;; Copyright © 2015 Ludovic Courtès 
 ;;; Copyright © 2015 Efraim Flashner 
+;;; Copyright © 2016 Ni* Gillmann 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -286,3 +287,41 @@ GNUnet services, including the @dfn{identity} and 
@dfn{file sharing}
 services.")
   (home-page "http://gnu.org/software/guix;)
   (license license:gpl3+
+
+(define-public gnunet-gtk
+  (package
+(name "gnunet-gtk")
+(version "0.10.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://gnu/gnunet/gnunet-gtk-" version
+   ".tar.gz"))
+   (sha256
+(base32
+ "1p38k1s6a2fmcfc9a7cf1zrdycm9h06kqdyand4s3k500nj6mb4g"
+(build-system gnu-build-system)
+(inputs
+ `(("gnunet" ,gnunet)
+   ("gtk+" ,gtk+-2)
+   ("libextractor" ,libextractor)
+   ("glade3" ,glade3)
+   ("qrencode" ,qrencode)))
+   ;;("libunique" ,libunique)
+(native-inputs
+ `(("pkg-config" ,pkg-config)
+   ("libglade" ,libglade)))
+   (arguments
+`(#:configure-flags '("--without-libunique" "--with-gtk+-2"
+  "--with-gnunet=/usr" "--with-qrencode")
+%standard-phases))
+(synopsis "Graphical front-end tools for GNUnet")
+(description
+ "Gnunet-gtk provides the gnunet-setup tool.  Gnunet-setup can be used to
+configure and test the network settings, choose which applications should be
+run and configure databases.  Other options include system-limitations
+such as disk space consumption, bandwidth, etc.  The resulting configuration
+files are human-readable and can theoretically be created or edited by hand.
+For more information, read https://gnunet.org/svn/gnunet-gtk/README;)
+(license license:gpl3+)
+(home-page "https://gnunet.org/;)))
-- 
2.6.3



-- 
Ni* -- https://www.libertad.pw
Email is public. Talk to me in private:
https://psyced.org:34443/~niasterisk
privacy respecting, secure communication:
BM-2cSj8qEigE3CMaLU3CwPZf7T3LvzvnttsC
(bitmessage)From 41a4b5b4f7c3cfc4bd2afedc0da9b256eca7b16b Mon Sep 17 00:00:00 2001
From: Ni* Gillmann 
Date: Wed, 13 Jan 2016 18:36:31 +0100
Subject: [PATCH] gnu/packages/gnunet gnunet-gtk added

This is the most recent, almost building commit of gnunet-gtk
Compare to https://notabug.org/anonymiss/libertad-overlay/src/master/net-misc
for a building version (ebuild, on gentoo) and requirements.

This patch tries to build and work with the guix provided version of
gladeui, in its current state it fails and I want other people with
more experience in the guix ecosystem to finish it.
---
 gnu/packages/gnunet.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 11e5aa8..91bbe1f 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2014 Sree Harsha Totakura 
 ;;; Copyright © 2015 Ludovic Courtès 
 ;;; Copyright © 2015 Efraim Flashner 
+;;; Copyright © 2016 Ni* Gillmann 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -286,3 +287,41 @@ GNUnet services, including the @dfn{identity} and @dfn{file sharing}
 services.")
   (home-page "http://gnu.org/software/guix;)
   (license license:gpl3+
+
+(define-public gnunet-gtk
+  (package
+(name "gnunet-gtk")
+(version "0.10.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://gnu/gnunet/gnunet-gtk-" version
+   ".tar.gz"))

Re: [PATCH 3/6] emacs: Find packages in system profiles.

2016-01-13 Thread Alex Kost
Ludovic Courtès (2016-01-12 23:28 +0300) wrote:

> Alex Kost  skribis:
>
>> For a usual profile, packages are placed in a profile directory itself,
>> but for a system profile, packages are placed in 'profile'
>> sub-directory.  So we need to do some special cases for system profiles
>> to find packages there as well.
>
> [...]
>
>> +(defun guix-packages-profile (profile  generation system?)
>> +  "Return a directory where packages are installed for the
>> +PROFILE's GENERATION.
>> +
>> +If SYSTEM? is non-nil, then PROFILE is considered to be a system
>> +profile.  Unlike usual profiles, for a system profile, packages
>> +are placed in 'profile' subdirectory."
>> +  (let ((profile (if generation
>> + (guix-generation-file profile generation)
>> +   profile)))
>> +(if system?
>> +(expand-file-name "profile" profile)
>> +  profile)))
>
> It seems you’re calling /run/current-system the system profile, which
> leads to the ‘system?’ Boolean here, but the system profile really is
> /run/current-system/profile.

As we need to work with generations, I use "/var/guix/profiles/system"
instead of a "/run/current-system" link.  But you are right, I called it
“system profile”.

I think using "/var/guix/profiles/system/profile" wouldn't help to
remove ‘system?’ boolean.  For example:

  (guix-packages-profile "/var/guix/profiles/per-user/me/guix-profile" 3)
  => "/var/guix/profiles/per-user/me/guix-profile-3-link"

  (guix-packages-profile "/var/guix/profiles/system/profile" 3)
  => "/var/guix/profiles/system/profile-3-link"

The first one is correct, but the second should be:
  => "/var/guix/profiles/system-3-link/profile"

As you can see we need to distinguish system and usual profiles because
packages are placed in different places for them
("system-NN-link/profile" and "usual-NN-link" without "profile" subdir),
that's why I added ‘system?’ argument.  I don't see how it can be
avoided.

> I had overlooked it, but wouldn’t it be easier if patch #2 did:
>
> +(defvar guix-system-profile
> +  (concat guix-config-state-directory "/profiles/system/profile")
> +  "System profile.")
>
> ?
Not really.

Both "/var/guix/profiles/system" (which I called “system profile”) and
"/var/guix/profiles/system/profile" (which I called “packages profile”)
are needed.  The former — for finding generations, and the latter — for
finding packages.

I actually need "/var/guix/profiles/system" in the first place, so if
‘guix-system-profile’ is not an appropriate name for this variable, it
should be renamed (what name do you suggest?).

And about name confusion: now I see that “profile” should be used only
for a directory (symlink) with packages.  But I always thought that a
directory that has generations can also be named a “profile” (apparently
cannot), especially taking into account ‘profile-generations’ procedure
from (guix profiles) module:

  (profile-generations "/var/guix/profiles/system")

That's why ^^^ I called "/var/guix/profiles/system" a system profile.

-- 
Alex



Re: [PATCH 6/6] emacs: Add interface for system generations.

2016-01-13 Thread Alex Kost
Ludovic Courtès (2016-01-12 23:35 +0300) wrote:

> Alex Kost  skribis:
>
>> * emacs/guix-main.scm (system-generation-boot-parameters)
>> (system-generation-param-alist, system-generation-sexps): New procedures.
>> (entries): Add 'system-generation' entry type.
>> * emacs/guix-messages.el (guix-result-message): Use the same messages
>>   for 'generation' and 'system-generation' entry types.
>> * emacs/guix-ui-system-generation.el: New file.
>> * emacs.am (ELFILES): Add it.
>> * doc/emacs.texi (Emacs Commands): Document new commands.
>> * NEWS: Mention new interface.
>
> [...]
>
>> +Analogously on GuixSD you can also display system generations:
>> +
>> +@table @kbd
>> +@item M-x guix-system-generations
>> +@item M-x guix-last-system-generations
>> +@item M-x guix-system-generations-by-time
>> +@end table
>
> As simple as this.  :-)
>
> And I guess it’s also possible to select generations, delete them, and
> switch to a specific one, as with M-x guix-generations?

Well yes, but only if emacs was started with root privileges.  At first
I was going to remove support for deleting/switching system generations
because of this, but then I left it, as I thought there might exist
users who run emacs from "root" for some reason, and such manipulating
system generations may be useful for them.

> Though maybe it would have to use
> “sudo:localhost:/run/current-system/profile” (via Tramp) to be able to
> modify things.  Maybe it could somehow offer to gain root privileges
> when performing an action?

I don't see how it can be done, since we use a guile REPL to perform
such actions (for example, ‘delete-generations’ procedure from (guix
scripts package) module).  But the REPL is started with the same
privileges as emacs.

-- 
Alex



Re: reproducibility

2016-01-13 Thread Federico Beffa
On Wed, Jan 13, 2016 at 10:15 AM, Efraim Flashner  wrote:
> On Wed, 13 Jan 2016 09:13:25 +0100
> Federico Beffa  wrote:
>
>> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès  wrote:
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>
>> Just out of curiosity, could you provide a concrete example where the
>> order is purposefully specified.
>>
>> Thanks,
>> Fede
>>
>
> I haven't had time (since reading this) to test if the order matters or not,
> but some of the openstack packages say they care about order:
> https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/test-requirements.txt?h=2.0.0

Reading the comment sounds like its because pip installs packages
sequentially. Sounds like a different approach from what we are doing.

Anyway, thanks for the pointer.
Regards,
Fede



Re: [PATCH 1/6] guix system: Export accessors.

2016-01-13 Thread Alex Kost
Ludovic Courtès (2016-01-12 23:25 +0300) wrote:

> Alex Kost  skribis:
>
>> * guix/scripts/system.scm (read-boot-parameters, boot-parameters)
>> (boot-parameters?, boot-parameters-label, boot-parameters-root-device)
>> (boot-parameters-kernel, boot-parameters-kernel-arguments): Export.
>
> LGTM.
>
> Eventually (as a replacement of this patch or as a subsequent patch, as
> you prefer) we should move these to (gnu system) since this is where we
> create the ‘boot-parameters’ sexp.

Great, I would like to make a replacement.  OK for the attached patch?

(I exported  because it is used by (guix scripts system))

>From ac344e3f17741c439aa15a642f1872fd2c7bfd9f Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Fri, 8 Jan 2016 02:48:17 +0300
Subject: [PATCH] Move  to (gnu system).

* guix/scripts/system.scm (, boot-parameters)
  (boot-parameters?, boot-parameters-label, boot-parameters-root-device)
  (boot-parameters-kernel, boot-parameters-kernel-arguments):
  (read-boot-parameters) Move to...
* gnu/system.scm: ... here. Export them.
---
 gnu/system.scm  | 42 ++
 guix/scripts/system.scm | 33 -
 2 files changed, 42 insertions(+), 33 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 4aedb7e..2600224 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -88,6 +88,15 @@
 operating-system-locale-directory
 operating-system-boot-script
 
+
+boot-parameters
+boot-parameters?
+boot-parameters-label
+boot-parameters-root-device
+boot-parameters-kernel
+boot-parameters-kernel-arguments
+read-boot-parameters
+
 local-host-aliases
 %setuid-programs
 %base-packages
@@ -709,4 +718,37 @@ this file is the reconstruction of GRUB menu entries for old configurations."
 #$(operating-system-kernel-arguments os))
(initrd #$initrd)
 
+
+;;;
+;;; Boot parameters
+;;;
+
+(define-record-type* 
+  boot-parameters make-boot-parameters boot-parameters?
+  (labelboot-parameters-label)
+  (root-device  boot-parameters-root-device)
+  (kernel   boot-parameters-kernel)
+  (kernel-arguments boot-parameters-kernel-arguments))
+
+(define (read-boot-parameters port)
+  "Read boot parameters from PORT and return the corresponding
+ object or #f if the format is unrecognized."
+  (match (read port)
+(('boot-parameters ('version 0)
+   ('label label) ('root-device root)
+   ('kernel linux)
+   rest ...)
+ (boot-parameters
+  (label label)
+  (root-device root)
+  (kernel linux)
+  (kernel-arguments
+   (match (assq 'kernel-arguments rest)
+ ((_ args) args)
+ (#f   '())   ;the old format
+(x;unsupported format
+ (warning (_ "unrecognized boot parameters for '~a'~%")
+  system)
+ #f)))
+
 ;;; system.scm ends here
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 1407dc7..a45f07e 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -191,39 +191,6 @@ the ownership of '~a' may be incorrect!~%")
 
 
 ;;;
-;;; Boot parameters
-;;;
-
-(define-record-type* 
-  boot-parameters make-boot-parameters boot-parameters?
-  (labelboot-parameters-label)
-  (root-device  boot-parameters-root-device)
-  (kernel   boot-parameters-kernel)
-  (kernel-arguments boot-parameters-kernel-arguments))
-
-(define (read-boot-parameters port)
-  "Read boot parameters from PORT and return the corresponding
- object or #f if the format is unrecognized."
-  (match (read port)
-(('boot-parameters ('version 0)
-   ('label label) ('root-device root)
-   ('kernel linux)
-   rest ...)
- (boot-parameters
-  (label label)
-  (root-device root)
-  (kernel linux)
-  (kernel-arguments
-   (match (assq 'kernel-arguments rest)
- ((_ args) args)
- (#f   '())   ;the old format
-(x;unsupported format
- (warning (_ "unrecognized boot parameters for '~a'~%")
-  system)
- #f)))
-
-
-;;;
 ;;; Reconfiguration.
 ;;;
 
-- 
2.6.3



Re: reproducibility

2016-01-13 Thread Federico Beffa
On Wed, Jan 13, 2016 at 2:56 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès  wrote:
>>> Federico Beffa  skribis:
>>>
 On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> I've noticed that a derivation is a function of the order of the
>> inputs. As an example, the following two input orders give rise to two
>> distinct derivations:
>>
>> A)
>>
>> (inputs
>>  `(("texlive" ,texlive)
>>("texinfo" ,texinfo)
>>("m4" ,m4)
>>("libx11" ,libx11))
>>
>> B)
>> (inputs
>>  `(("texinfo" ,texinfo)
>>("texlive" ,texlive)
>>("m4" ,m4)
>>("libx11" ,libx11))
>>
>> Is this intentional?
>
> Yes.  There are several places where order matters, most importantly
> search paths, and these are computed from the input lists.

 If order matters, it would probably be more robust to force internally
 a specific order rather than relying on the (often random) order
 defined in a package recipe (possibly created by an importer, ...).
>>>
>>> Most of the time any order would work, but I can imagine situations
>>> where the packager could purposefully choose a specific order.  So I’d
>>> rather not do any automatic sorting, if that’s what you have in mind.
>>
>> Just out of curiosity, could you provide a concrete example where the
>> order is purposefully specified.
>
> No specific example, sorry, but it’s plausible IMO.  With enough CPU
> power, we could try rebuilding everything with a random order and see
> what breaks.

I guess that's not necessary... I was just trying to learn something.

Thanks,
Fede



Re: [PATCH] Build C++ cross-compiler by default.

2016-01-13 Thread Ludovic Courtès
Ricardo Wurmus  skribis:

> the configure flags defined in “cross-gcc-arguments” disabled the C++
> compiler to prevent an error that happens when building libstdc++-v3.
> Since I needed a C++ cross-compiler for ARM I added “c++” to the list of
> enabled languages and added the configure flag
> “--disable-libstdc++-v3”.  This is now the same as what is done in
> “gcc-boot0” in “commencement.scm”.

Cool.

> Will this cause a rebuild of every package on ARM?  Is it okay to push
> this to core-updates?

AFAICS, this causes a rebuild of the cross-compilation infrastructure
only (for Hydra, that’s several times GCC plus a bunch of packages that
we cross-build to make sure the basic functionality is alright.)

So it could even go to ‘master’, but since Hydra is now building all of
‘core-updates’, it’s more energy-efficient to push it to ‘core-updates’
as well.

> From 021febc7f7f35ccffe381af798e0b20d7687c94e Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Mon, 11 Jan 2016 19:43:25 +0100
> Subject: [PATCH] gnu: cross-gcc-arguments: Enable C++, disable building of
>  libstdc++-v3.
>
> * gnu/packages/cross-base.scm (cross-gcc-arguments)[arguments]: Disable
>   building libstdc++-v3 and enable building C++ compiler.

LGTM!

Thanks,
Ludo’.



Re: [PATCH 6/6] emacs: Add interface for system generations.

2016-01-13 Thread Ludovic Courtès
Alex Kost  skribis:

> Ludovic Courtès (2016-01-12 23:35 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> * emacs/guix-main.scm (system-generation-boot-parameters)
>>> (system-generation-param-alist, system-generation-sexps): New procedures.
>>> (entries): Add 'system-generation' entry type.
>>> * emacs/guix-messages.el (guix-result-message): Use the same messages
>>>   for 'generation' and 'system-generation' entry types.
>>> * emacs/guix-ui-system-generation.el: New file.
>>> * emacs.am (ELFILES): Add it.
>>> * doc/emacs.texi (Emacs Commands): Document new commands.
>>> * NEWS: Mention new interface.
>>
>> [...]
>>
>>> +Analogously on GuixSD you can also display system generations:
>>> +
>>> +@table @kbd
>>> +@item M-x guix-system-generations
>>> +@item M-x guix-last-system-generations
>>> +@item M-x guix-system-generations-by-time
>>> +@end table
>>
>> As simple as this.  :-)
>>
>> And I guess it’s also possible to select generations, delete them, and
>> switch to a specific one, as with M-x guix-generations?
>
> Well yes, but only if emacs was started with root privileges.  At first
> I was going to remove support for deleting/switching system generations
> because of this, but then I left it, as I thought there might exist
> users who run emacs from "root" for some reason, and such manipulating
> system generations may be useful for them.

Sounds reasonable.

>> Though maybe it would have to use
>> “sudo:localhost:/run/current-system/profile” (via Tramp) to be able to
>> modify things.  Maybe it could somehow offer to gain root privileges
>> when performing an action?
>
> I don't see how it can be done, since we use a guile REPL to perform
> such actions (for example, ‘delete-generations’ procedure from (guix
> scripts package) module).  But the REPL is started with the same
> privileges as emacs.

Oh right.  We could use elisp code to delete the symlink (that would
allow us to use Tramp), but it’s probably not worth bothering.

Thanks!

Ludo’.



Re: [PATCHES] Update orfm and package test requirements.

2016-01-13 Thread Ben Woodcroft



On 13/01/16 23:50, Ricardo Wurmus wrote:

Ben Woodcroft  writes:



[..]

+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-before 'check 'patch-and-set-version
+   (lambda _
+ (setenv "VERSION" ,version)
+ #t)

That’s an odd phase name; why “patch”?  Is setting the environment
variable the only way to set the version or would a make-flag work here,
too?  (I haven’t checked if the ruby-build-system respects make-flags.)

The rest looks good to me.  Thanks!
Pushed, thanks. The phase name above was a bit crufty so I changed it, 
but had to go with setenv since the ruby-build-system doesn't support 
make-flags (or rake-flags).


Thanks,
ben



[PATCH 0/2] "M-x guix-search-by-name" and "M-x guix-packages-by-name".

2016-01-13 Thread Alex Kost
I almost never use "M-x guix-search-by-name" because I need to know a
real name of a package, and I rarely use "M-x guix-search-by-regexp",
because along with names it also searches in synopses and descriptions
(by default).

But I often use another command that allows me to display packages with
names matching regexp.  For example, I use it when I want to look at
packages with names that contain 'xml' or 'emacs'.  I believe this is
exactly what most people would expect from "M-x guix-search-by-name".

So what about renaming 'guix-search-by-name' into
'guix-packages-by-name' and adding a real 'guix-search-by-name' command
that will search for regexp in package names?

So:

- "M-x guix-packages-by-name guile" will display only guile packages
  (different versions and outputs)

- "M-x guix-search-by-name guile" will display all packages with "guile"
  string in names (like "guile-charting" or "guile-sly").



[PATCH 1/2] emacs: Rename 'guix-search-by-name' to 'guix-packages-by-name'.

2016-01-13 Thread Alex Kost
* emacs/guix-ui-package.el (guix-search-by-name): Rename to...
  (guix-packages-by-name): ... this.  Complete package name.
* doc/emacs.texi (Emacs Commands): Likewise.
---
 doc/emacs.texi   | 2 +-
 emacs/guix-ui-package.el | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/emacs.texi b/doc/emacs.texi
index b2a3d47..7edaedc 100644
--- a/doc/emacs.texi
+++ b/doc/emacs.texi
@@ -155,7 +155,7 @@ Display all installed packages.
 Display obsolete packages (the packages that are installed in a profile
 but cannot be found among available packages).
 
-@item M-x guix-search-by-name
+@item M-x guix-packages-by-name
 Display package(s) with the specified name.
 
 @item M-x guix-search-by-regexp
diff --git a/emacs/guix-ui-package.el b/emacs/guix-ui-package.el
index 7cf1a7d..0696c4b 100644
--- a/emacs/guix-ui-package.el
+++ b/emacs/guix-ui-package.el
@@ -912,15 +912,15 @@ See `guix-package-info-type'."
   "A history of minibuffer prompts.")
 
 ;;;###autoload
-(defun guix-search-by-name (name  profile)
-  "Search for Guix packages by NAME.
+(defun guix-packages-by-name (name  profile)
+  "Display Guix packages with NAME.
 NAME is a string with name specification.  It may optionally contain
 a version number.  Examples: \"guile\", \"guile-2.0.11\".
 
 If PROFILE is nil, use `guix-current-profile'.
 Interactively with prefix, prompt for PROFILE."
   (interactive
-   (list (read-string "Package name: " nil 'guix-package-search-history)
+   (list (guix-read-package-name)
  (guix-ui-read-profile)))
   (guix-package-get-display profile 'name name))
 
-- 
2.6.3




[PATCH 2/2] emacs: Add 'guix-search-by-name'.

2016-01-13 Thread Alex Kost
* emacs/guix-ui-package.el (guix-search-by-name): New command.
* doc/emacs.texi (Emacs Commands): Document it.
---
 doc/emacs.texi   |  5 +
 emacs/guix-ui-package.el | 11 +++
 2 files changed, 16 insertions(+)

diff --git a/doc/emacs.texi b/doc/emacs.texi
index 7edaedc..eb470ab 100644
--- a/doc/emacs.texi
+++ b/doc/emacs.texi
@@ -163,6 +163,11 @@ Search for packages by a specified regexp.  By default 
``name'',
 ``synopsis'' and ``description'' of the packages will be searched.  This
 can be changed by modifying @code{guix-package-search-params} variable.
 
+@item M-x guix-search-by-name
+Search for packages with names matching a specified regexp.  This
+command is the same as @code{guix-search-by-regexp}, except only a
+package ``name'' is searched.
+
 @end table
 
 By default, these commands display each output on a separate line.  If
diff --git a/emacs/guix-ui-package.el b/emacs/guix-ui-package.el
index 0696c4b..2951452 100644
--- a/emacs/guix-ui-package.el
+++ b/emacs/guix-ui-package.el
@@ -939,6 +939,17 @@ Interactively with prefix, prompt for PROFILE."
 (or params guix-package-search-params)))
 
 ;;;###autoload
+(defun guix-search-by-name (regexp  profile)
+  "Search for Guix packages matching REGEXP in a package name.
+If PROFILE is nil, use `guix-current-profile'.
+Interactively with prefix, prompt for PROFILE."
+  (interactive
+   (list (read-string "Package name by regexp: "
+  nil 'guix-package-search-history)
+ (guix-ui-read-profile)))
+  (guix-search-by-regexp regexp '(name) profile))
+
+;;;###autoload
 (defun guix-installed-packages ( profile)
   "Display information about installed Guix packages.
 If PROFILE is nil, use `guix-current-profile'.
-- 
2.6.3




Re: [PATCH 3/6] emacs: Find packages in system profiles.

2016-01-13 Thread Ludovic Courtès
Alex Kost  skribis:

> Ludovic Courtès (2016-01-12 23:28 +0300) wrote:

[...]

>> It seems you’re calling /run/current-system the system profile, which
>> leads to the ‘system?’ Boolean here, but the system profile really is
>> /run/current-system/profile.
>
> As we need to work with generations, I use "/var/guix/profiles/system"
> instead of a "/run/current-system" link.  But you are right, I called it
> “system profile”.
>
> I think using "/var/guix/profiles/system/profile" wouldn't help to
> remove ‘system?’ boolean.  For example:
>
>   (guix-packages-profile "/var/guix/profiles/per-user/me/guix-profile" 3)
>   => "/var/guix/profiles/per-user/me/guix-profile-3-link"
>
>   (guix-packages-profile "/var/guix/profiles/system/profile" 3)
>   => "/var/guix/profiles/system/profile-3-link"
>
> The first one is correct, but the second should be:
>   => "/var/guix/profiles/system-3-link/profile"
>
> As you can see we need to distinguish system and usual profiles because
> packages are placed in different places for them
> ("system-NN-link/profile" and "usual-NN-link" without "profile" subdir),
> that's why I added ‘system?’ argument.  I don't see how it can be
> avoided.

Oh you’re right, got it.

>> I had overlooked it, but wouldn’t it be easier if patch #2 did:
>>
>> +(defvar guix-system-profile
>> +  (concat guix-config-state-directory "/profiles/system/profile")
>> +  "System profile.")
>>
>> ?
> Not really.
>
> Both "/var/guix/profiles/system" (which I called “system profile”) and
> "/var/guix/profiles/system/profile" (which I called “packages profile”)
> are needed.  The former — for finding generations, and the latter — for
> finding packages.
>
> I actually need "/var/guix/profiles/system" in the first place, so if
> ‘guix-system-profile’ is not an appropriate name for this variable, it
> should be renamed (what name do you suggest?).

Indeed, it’s confusing.  I don’t have a better name to suggest, though.

> And about name confusion: now I see that “profile” should be used only
> for a directory (symlink) with packages.  But I always thought that a
> directory that has generations can also be named a “profile” (apparently
> cannot), especially taking into account ‘profile-generations’ procedure
> from (guix profiles) module:
>
>   (profile-generations "/var/guix/profiles/system")
>
> That's why ^^^ I called "/var/guix/profiles/system" a system profile.

Initially, I would have said that as long as FOO/manifest exists, FOO
can be called a profile.  That’s the definition of a “profile” in the
sense of (guix profiles).

Like a profile, /var/guix/profiles/system has generations, but unlike
“real profiles”, it is not created by ‘profile-derivation’.

The solution in this patch looks good, after all!

Thanks for explaining,
Ludo’.



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

2016-01-13 Thread Leo Famulari
On Wed, Jan 13, 2016 at 03:17:28PM +0100, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > * gnu/packages/audio.scm (espeak): New variable.
> 
> If you think eSpeak-ng is not ready yet, or is sufficiently different,
> it’s OK to package eSpeak.

I'm looking into it.

> 
> > +(native-inputs
> > + `(("unzip" ,unzip)))
> > +(inputs
> > +  `(("sonic" ,sonic)
> 
> The “unzip” line is misaligned.

The "unzip" line or the "sonic" line? Most of the patches I see use the
former style.

> 
> > +("pulseaudio" ,pulseaudio)
> > +("portaudio" ,portaudio)))
> 
> Dunno if it’s useful to have both, maybe someone more knowledgeable like
> Ricardo can answer?

I misinterpreted the configure options. It's not useful to have both. If
PulseAudio is an input, then eSpeak will always use PulseAudio unless
configured not to, in which case PulseAudio should not be an input.

PulseAudio stopped working completely on my Debian system a while ago.
I decided to keep using ALSA and never looked back (or is it forward, in
this case? ;)

So, if we are going to target PulseAudio, can a PulseAudio user test
that this package works? This should make the computer speak "hello
world":
$ espeak "hello world"

> 
> > +(synopsis "Software speech synthesizer")
> > +(description "eSpeak is a compact software speech synthesizer for
> > +English and other languages, for Linux and Windows.  eSpeak uses a
>   ^-^
> Remove.

Done.

> 
> In general, we don’t mention proprietary software, and we don’t mention
> other OSes, free or not, portability etc., because that’s not what
> matters from the viewpoint of an OS provider.
> 
> The rest LGTM!

Again, I'll be grateful if a PulseAudio user will test!

> 
> Thanks,
> Ludo’.



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

2016-01-13 Thread Leo Famulari
On Wed, Jan 13, 2016 at 03:10:16PM +0100, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > * gnu/packages/audio.scm (sonic): New variable.
> 
> [...]
> 
> > +#:phases (modify-phases %standard-phases
> > + (delete 'configure
  *>|
> 
> There’s a problem here.  :-)

The indentation of the second line, correct?

> 
> > +(synopsis "Speed up or slow down speech")
> > +(description "Sonic is a simple algorithm for speeding up or slowing 
> > down
> 
> s/is a/implements a/

> 
> > +speech.  However, it's optimized for speed ups of over 2X, unlike previous
> > +algorithms for changing speech rate.  The Sonic library is a very simple 
> > ANSI C
> > +library that is designed to easily be integrated into streaming voice
> > +applications, like TTS back ends.
> 
> I would change the last sentence to:
> 
>   Sonic is a C library designed to be easily integrated into streaming
>   voice applications such as text-to-speech (TTS) back ends.
> 
> > +The primary motivation behind Sonic is to enable the blind and visually 
> > impaired
> > +to improve their productivity with open source speech engines, like espeak.
> ^‑--^
> Replace with “with speech engines such as eSpeak.”
> 
> > +Sonic can also be used by the sighted.  For example, Sonic can improve the
> > +experience of listening to an audio book on an Android phone.")
> 
> I’d remove these two sentences.
> 
> OK with these changes.

Done.

> 
> Thanks,
> Ludo’.



Re: [PATCH] gnu: bind-utils: Build and install “nsupdate”.

2016-01-13 Thread Mathieu Lirzin
Hi,

Ricardo Wurmus  writes:

>>From ba32861728c3534be6796b6b32a9a90954b6 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Wed, 13 Jan 2016 16:06:36 +0100
> Subject: [PATCH] gnu: bind-utils: Build and install "nsupdate".
>
> * gnu/packages/dns.scm (bind-utils)[arguments]: Generalize "build" and
>   "install" phases.
> ---
>  gnu/packages/dns.scm | 105 
> ---
>  1 file changed, 58 insertions(+), 47 deletions(-)
>
> diff --git a/gnu/packages/dns.scm b/gnu/packages/dns.scm
> index 8357dad..0a42722 100644
> --- a/gnu/packages/dns.scm
> +++ b/gnu/packages/dns.scm
[...]
> +  (arguments
> +   `(#:tests? #f ; no test phase implemented
> + #:configure-flags
> + (list (string-append "--with-openssl="
> +  (assoc-ref %build-inputs "openssl"))
> +   (string-append "--with-dlz-mysql="
> +  (assoc-ref %build-inputs "mysql"))
> +   (string-append "--with-pkcs11="
> +  (assoc-ref %build-inputs "p11-kit")))

What about:

   #:configure-flags
   (map (lambda (opt val)
  (string-append opt (assoc-ref %build-inputs val)))
'("--with-openssl=" "--with-dlz-mysql=" "--with-pkcs11=")
'("openssl" "mysql" "p11-kit"))

> + #:modules ((srfi srfi-1)
> +(srfi srfi-26)
> +,@%gnu-build-system-modules)
> + #:phases
> + (modify-phases %standard-phases
> +   (replace 'build
> + (lambda _
> +   (fold (lambda (dir pass)
> +   (and pass (zero? (system* "make" "-C" dir
> + #t
> + (append
> +  (map (cut string-append "lib/" <>)
> +   (list ,@libs))
> +  (map (cut string-append "bin/" <>)
> +   (list ,@bins))
> +   (replace 'install
> + (lambda _
> +   (fold (lambda (dir pass)
> +   (and pass (zero? (system* "make" "-C" dir 
> "install"
> + #t
> + (map (cut string-append "bin/" <>)
> +  (list ,@bins

and this:

   (let ((libs '("dns" "isc" "bind9" "isccfg" "lwres"))
 (bins '("dig" "nsupdate")))
 (modify-phases %standard-phases
   (replace 'build
 (lambda _
   (every (lambda (dir)
(zero? (system* "make" "-C" dir)))
  (append (map (cut string-append "lib/" <>) libs)
  (map (cut string-append "bin/" <>) bins)
   (replace 'install
 (lambda _
   (every (lambda (dir)
(zero? (system* "make" "-C" dir "install")))
  (map (cut string-append "bin/" <>) bins


Otherwise LGTM.

--
Mathieu Lirzin



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

2016-01-13 Thread Ludovic Courtès
Leo Famulari  skribis:

> * gnu/packages/audio.scm (espeak): New variable.

If you think eSpeak-ng is not ready yet, or is sufficiently different,
it’s OK to package eSpeak.

> +(native-inputs
> + `(("unzip" ,unzip)))
> +(inputs
> +  `(("sonic" ,sonic)

The “unzip” line is misaligned.

> +("pulseaudio" ,pulseaudio)
> +("portaudio" ,portaudio)))

Dunno if it’s useful to have both, maybe someone more knowledgeable like
Ricardo can answer?

> +(synopsis "Software speech synthesizer")
> +(description "eSpeak is a compact software speech synthesizer for
> +English and other languages, for Linux and Windows.  eSpeak uses a
  ^-^
Remove.

In general, we don’t mention proprietary software, and we don’t mention
other OSes, free or not, portability etc., because that’s not what
matters from the viewpoint of an OS provider.

The rest LGTM!

Thanks,
Ludo’.



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

2016-01-13 Thread Ludovic Courtès
Leo Famulari  skribis:

> * gnu/packages/audio.scm (sonic): New variable.

[...]

> +#:phases (modify-phases %standard-phases
> + (delete 'configure

There’s a problem here.  :-)

> +(synopsis "Speed up or slow down speech")
> +(description "Sonic is a simple algorithm for speeding up or slowing down

s/is a/implements a/

> +speech.  However, it's optimized for speed ups of over 2X, unlike previous
> +algorithms for changing speech rate.  The Sonic library is a very simple 
> ANSI C
> +library that is designed to easily be integrated into streaming voice
> +applications, like TTS back ends.

I would change the last sentence to:

  Sonic is a C library designed to be easily integrated into streaming
  voice applications such as text-to-speech (TTS) back ends.

> +The primary motivation behind Sonic is to enable the blind and visually 
> impaired
> +to improve their productivity with open source speech engines, like espeak.
^‑--^
Replace with “with speech engines such as eSpeak.”

> +Sonic can also be used by the sighted.  For example, Sonic can improve the
> +experience of listening to an audio book on an Android phone.")

I’d remove these two sentences.

OK with these changes.

Thanks,
Ludo’.



[PATCH] Add audit.

2016-01-13 Thread Ricardo Wurmus
Hi Guix,

the tests for this package cannot easily be fixed by

   #:phases
   (modify-phases %standard-phases
 (add-after 'unpack 'fix-tests
   (lambda _
 (substitute* "auparse/test/auparse_test.ref"
   (("\\(root\\)") "(unknown(0))"))
 #t)))

because for *some* of them “(root)” is returned (while for *most* of
them its “(unknown(0))”).  Ideas on how to fix the tests are very
welcome!

~~ Ricardo

>From c4948bc06b30e4e55810b82cc458cd6a429b6f80 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Wed, 13 Jan 2016 16:00:06 +0100
Subject: [PATCH] gnu: Add audit.

* gnu/packages/admin.scm (audit): New variable.
---
 gnu/packages/admin.scm | 33 +
 1 file changed, 33 insertions(+)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index fbdc26d..87dd497 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer 
 ;;; Copyright © 2015 Alex Sassmannshausen 
 ;;; Copyright © 2015 Eric Dvorsak 
+;;; Copyright © 2016 Ricardo Wurmus 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -34,6 +35,7 @@
   #:use-module (guix build-system trivial)
   #:use-module (gnu packages)
   #:use-module (gnu packages base)
+  #:use-module (gnu packages cyrus-sasl)
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages linux)
@@ -47,6 +49,7 @@
   #:use-module (gnu packages bison)
   #:use-module (gnu packages flex)
   #:use-module (gnu packages glib)
+  #:use-module (gnu packages openldap)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages popt)
   #:use-module (gnu packages texinfo)
@@ -1317,3 +1320,33 @@ able to adapt itself dynamically to the overall system load.  Children
 processes and threads of the specified process may optionally share the same
 limits.")
 (license license:gpl2+)))
+
+(define-public audit
+  (package
+(name "audit")
+(version "2.4.5")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://people.redhat.com/sgrubb/audit/;
+  "audit-" version ".tar.gz"))
+  (sha256
+   (base32
+"1q1q51dvxscbi4kbakmd4bn0xrvwwaiwvaya79925cbrqwzxsg77"
+(build-system gnu-build-system)
+(home-page "http://people.redhat.com/sgrubb/audit/;)
+(arguments
+ `(;; The tests expect records like "uid=0 (root)" but only get "uid=0
+   ;; (unknown(0))" in most cases.
+   #:tests? #f
+   #:configure-flags (list "--with-python=no")))
+(inputs
+ `(("openldap" ,openldap)
+   ("openssl" ,openssl)
+   ("sasl" ,cyrus-sasl)))
+(synopsis "Userspace component to the Linux auditing system")
+(description
+ "auditd is the userspace component to the Linux auditing system.  It's
+responsible for writing audit records to the disk.  Viewing the logs is done
+with the @code{ausearch} or @code{aureport} utilities.  Configuring the audit
+rules is done with the @code{auditctl} utility.")
+(license license:gpl2+)))
-- 
2.1.0



[PATCH] gnu: bind-utils: Build and install “nsupdate”.

2016-01-13 Thread Ricardo Wurmus
Hi Guix,

this patch is not as bad as it looks, even though most of the lines are
changed.  I noticed that “nsupdate” is not build as part of bind-utils
and replaced the manual and repetitive “build” and “install” phases with
something that can be controlled with the let-bound values “bins” and
“libs” holding the names of executables and libraries, respectively.

What do you think?

(“nsupdate” is checked for by the build system of some SELinux
libraries, which are needed for SSSD.)

~~ Ricardo


>From ba32861728c3534be6796b6b32a9a90954b6 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Wed, 13 Jan 2016 16:06:36 +0100
Subject: [PATCH] gnu: bind-utils: Build and install "nsupdate".

* gnu/packages/dns.scm (bind-utils)[arguments]: Generalize "build" and
  "install" phases.
---
 gnu/packages/dns.scm | 105 ---
 1 file changed, 58 insertions(+), 47 deletions(-)

diff --git a/gnu/packages/dns.scm b/gnu/packages/dns.scm
index 8357dad..0a42722 100644
--- a/gnu/packages/dns.scm
+++ b/gnu/packages/dns.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer 
+;;; Copyright © 2016 Ricardo Wurmus 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -61,51 +62,61 @@ and BOOTP/TFTP for network booting of diskless machines.")
 (license (list license:gpl2 license:gpl3
 
 (define-public bind-utils
-  (package
-(name "bind-utils")
-(version "9.10.3-P2")
-(source (origin
-  (method url-fetch)
-  (uri (string-append "http://ftp.isc.org/isc/bind9/; version
-  "/bind-" version ".tar.gz"))
-  (sha256
-   (base32
-"1kbfzml37sx4r2xi4gq48ji8w5kckd1f6gdn6pk6njqdmh8ijv2a"
-(build-system gnu-build-system)
-(inputs
- ;; it would be nice to add GeoIP and gssapi once there is package
- `(("libcap" ,libcap)
-   ("libxml2" ,libxml2)
-   ("mysql" ,mysql)
-   ("openssl" ,openssl)
-   ("perl" ,perl)
-   ("p11-kit" ,p11-kit)))
-(arguments
- `(#:tests? #f ; no test phase implemented
-   #:configure-flags
-   (list (string-append "--with-openssl="
-(assoc-ref %build-inputs "openssl"))
- (string-append "--with-dlz-mysql="
-(assoc-ref %build-inputs "mysql"))
- (string-append "--with-pkcs11="
-(assoc-ref %build-inputs "p11-kit")))
-   #:phases
-   (alist-replace
-'build
-(lambda _
-  (and (zero? (system* "make" "-C" "lib/dns"))
-   (zero? (system* "make" "-C" "lib/isc"))
-   (zero? (system* "make" "-C" "lib/bind9"))
-   (zero? (system* "make" "-C" "lib/isccfg"))
-   (zero? (system* "make" "-C" "lib/lwres"))
-   (zero? (system* "make" "-C" "bin/dig"
-(alist-replace
- 'install
- (lambda _ (zero? (system* "make" "-C" "bin/dig" "install")))
- %standard-phases
-(home-page "https://www.isc.org/downloads/bind/;)
-(synopsis "Tools for querying nameservers")
-(description
- "These tools, included with ISC BIND, are useful for analysis of DNS
+  (let ((libs '("dns" "isc" "bind9" "isccfg" "lwres"))
+(bins '("dig" "nsupdate")))
+(package
+  (name "bind-utils")
+  (version "9.10.3-P2")
+  (source (origin
+(method url-fetch)
+(uri (string-append "http://ftp.isc.org/isc/bind9/; version
+"/bind-" version ".tar.gz"))
+(sha256
+ (base32
+  "1kbfzml37sx4r2xi4gq48ji8w5kckd1f6gdn6pk6njqdmh8ijv2a"
+  (build-system gnu-build-system)
+  (inputs
+   ;; it would be nice to add GeoIP and gssapi once there is package
+   `(("libcap" ,libcap)
+ ("libxml2" ,libxml2)
+ ("mysql" ,mysql)
+ ("openssl" ,openssl)
+ ("perl" ,perl)
+ ("p11-kit" ,p11-kit)))
+  (arguments
+   `(#:tests? #f ; no test phase implemented
+ #:configure-flags
+ (list (string-append "--with-openssl="
+  (assoc-ref %build-inputs "openssl"))
+   (string-append "--with-dlz-mysql="
+  (assoc-ref %build-inputs "mysql"))
+   (string-append "--with-pkcs11="
+  (assoc-ref %build-inputs "p11-kit")))
+ #:modules ((srfi srfi-1)
+(srfi srfi-26)
+,@%gnu-build-system-modules)
+ #:phases
+ (modify-phases %standard-phases
+   (replace 'build
+ (lambda _
+   (fold (lambda (dir pass)
+   (and pass (zero? (system* "make" "-C" dir
+ #t
+ 

Re: Freezing core-updates soon

2016-01-13 Thread Ludovic Courtès
Hydra will start building all of ‘core-updates’ soon.  Hopefully we can
merge in a few days.

Ludo’.