Re: [PATCH] Add fxtract.

[Ben Woodcroft]

On 12/01/16 07:00, Ludovic Courtès wrote:

Ben Woodcroft  skribis:


 From acd310d27c457139d3f2fcd2cfc1127167bf2c48 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Thu, 7 Jan 2016 07:44:58 +1000
Subject: [PATCH] gnu: Add fxtract.

* gnu/packages/bioinformatics.scm (fxtract): New variable.

[...]


+   `(("ctskennerton-util"
+  ,(origin
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/ctSkennerton/util.git;)
+   (commit util-commit)))

This is GPLv2-only.  Could you mention it in a comment?


+ (file-name (string-append
+ "ctstennerton-util-" util-commit "-checkout"))

I would make it:

   (string-append "ctstennerton-util-" (string-take util-commit 7)
  "-checkout")


+  (home-page "https://github.com/ctSkennerton/fxtract;)
+  (synopsis "Extract sequences from FASTA and FASTQ files")
+  (description
+   "Fxtract extracts sequences from a protein or nucleotide fastx (FASTA
+or FASTQ) file given a subsequence.  It uses a simple substring search for
+basic tasks but can change to using POSIX regular expressions, PCRE, hash
+lookups or multi-pattern searching as required.  By default fxtract looks in
+the sequence of each record but can also be told to look in the header,
+comment or quality sections.")
+  (license license:gpl3+

According to the ‘LICENSE’ file, this should be ‘license:expat’.

Otherwise LGTM.


Pushed with these changes. Thanks for picking up the mistakes.

ben

Re: [PATCH] gnu: boost: Update to 1.60.0

[Ludovic Courtès]

Andreas Enge  skribis:

> On Wed, Jan 06, 2016 at 11:18:19PM +0100, Ludovic Courtès wrote:
>> It has 140 dependent packages, including LibreOffice, so kinda
>> borderline for master.  It’s probably safer on a separate branch that
>> Hydra will build.  Mark?
>
> Finally hydra picked up the branch. Unfortunately, the new boost fails
> to build on mips:
>http://hydra.gnu.org/build/914532
>
> I find it difficult to see what is the problem in the build log
> (C++, eh?)...

The error is:

--8<---cut here---start->8---
gcc.compile.c++ 
bin.v2/libs/context/build/gcc-4.9.3/release/threading-multi/unsupported.o
libs/context/src/unsupported.cpp:7:2: error: #error "platform not supported"
 #error "platform not supported"
  ^
--8<---cut here---end--->8---

The options I can think of are:

  1. Mark mips64el-linux as unsupported (134 packages depend on Boost,
 notably LibreOffice, Abiword, and Ardour).

  2. Build Boost without multi-threading support on MIPS, assuming it’s
 only this feature that’s unsupported.

  3. Hope that Debian has a patch to fix this and apply it.

Thoughts?

Ludo’.

Re: Texlive work

[Ludovic Courtès]

Andreas Enge  skribis:

>(modify-phases %standard-phases
>  (add-after 'install 'postint
>(lambda* (#:key inputs outputs #:allow-other-keys #:rest args)

Certified as valid indentation!

> (modify-phases
>   (map (cut assq <> %standard-phases)
>'(set-paths unpack patch-source-shebangs))
>   (add-after 'patch-source-shebangs 'texmf-config
> (lambda* (#:key inputs outputs #:allow-other-keys)

This one would be more:

  (modify-phases (map (cut foo bar)
  '(set-paths and all that))
(add-after 'patch-source-shebangs 'texmf-config
  (lambda* (#:key inputs outputs #:allow-other-keys)
;; …
)))

Ludo’.

Re: [PATCH] gnu: boost: Update to 1.60.0

[Andreas Enge]

On Mon, Jan 11, 2016 at 10:17:32AM +0100, Ludovic Courtès wrote:
>   3. Hope that Debian has a patch to fix this and apply it.

Debian is still at 1.58, so this is not an option right now.

Andreas

Re: [PATCH 5/6] gnu: mit-scheme: Generate and install documentation.

[Federico Beffa]

On Mon, Jan 11, 2016 at 12:14 AM, Mathieu Lirzin  wrote:
> Hi,
>
> Federico Beffa  writes:
>
>> HTML is not better than Info. Here we only need to keep it for
>> 'emacs-mit-scheme-doc' to work. This is functionality for mit-scheme
>> whereby Emacs looks up the documentation for the identifier at point.
>>
>> For PDFs, it depends on the type and quality of the manual. If it is
>> short and/or poor, then nobody will spend hours reading it. But if the
>> manual is good and long, then there is a chance that people will spend
>> a lot of time reading it and it would be nice to have a good quality
>> environment to read it (again, I'm talking about font graphics
>> rendering).
>>
>> This is analogous to making public buildings suitable for people with
>> wheel-chairs, ... may people don't care, until they are affected :-(
>
> Sorry I don't understand your analogy.  IIUC the discussion is about
> what should be installed with the default output.  Putting the PDF
> version of the manual in the 'doc' output will not prevent anyone to use
> it.  Did I miss something?

Well, the discussion is about this sentence:

   I just realized that its documentation is in Texinfo format.  What about
   simply installing the Info format like we do for other GNU packages, and
   not the PDF/PS/DVI version?

I can't find: why don't we put the PDF/PS/DVI in a different output.
If I misunderstood then my bad. But being less cryptic and more
explicit would prevent that.

Regards,
Fede

Re: [PATCH 0/2] Add eSpeak

[Leo Famulari]

On Tue, Jan 12, 2016 at 12:26:37AM -0500, Leo Famulari wrote:
> These patches provide the eSpeak software speech synthesizer [0].

I realized that the espeak upstream has gone inactive [0] and the users have
forked the project as espeak-ng: https://github.com/espeak-ng/espeak-ng/

The impression I get from the espeak ML is that the fork is merging a
lot of third-party patches that improve support for different languages,
as well as cleaning up the C codebase. So, in the future we should probably
package espeak-ng as well, for the sake of users that need speech
synthesis. It will conflict with espeak since the output binaries have
the same names.

There is also the espeakedit program that allows phoneme-editing. That
should be packaged, too.

[0] Read the last few months of their ML:
http://sourceforge.net/p/espeak/mailman/espeak-general/

> 
> I need advice on what audio system to configure it to use.
> 
> This patch configures it to use PulseAudio if it is available, and to
> use PortAudio otherwise. Of course, since I have included PulseAudio as
> an input, PulseAudio is always available and it starts a PulseAudio
> server if one is not running [1].
> 
> The other option is to use only PortAudio (tested and works for me).
> 
> 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?
> 
> Can GuixSD users with audio please test it out? As well as users on
> foreign distros? You can do so like this:
> `espeak 'hello world'`
> 
> [0]
> http://espeak.sourceforge.net/
> 
> [1] This is actually not the expected behaviour and I am going to file a
> bug. The Makefile reads "'runtime' uses pulseaudio if it is running,
> else uses portaudio". Instead, it starts PulseAudio on demand.
> 
> Leo Famulari (2):
>   gnu: Add sonic.
>   gnu: Add espeak.
> 
>  gnu/packages/audio.scm | 86 
> ++
>  1 file changed, 86 insertions(+)
> 
> -- 
> 2.6.4
> 
> 

Re: New CLI syntax for package version

[Ricardo Wurmus]

Ludovic Courtès  writes:

> In , we came to the conclusion that we need a
> new syntax to denote a specific package version on the command line.
>
> The current syntax is described in the manual (info "(guix) Invoking
> guix package").  Basically, ‘guile-1.8’ refers to version 1.8.x of
> Guile; however, this syntax has proved to be ambiguous for packages
> whose name contains digits.

Should we also take some time to reconsider how we name unreleased
versions like arbitrary git commits?

So far we have been picking the latest release version (or “0.0.0” if
there hasn’t been any release) followed by “.” and either a date or a
guix-internal revision number, then again a “.” followed by part of the
commit hash.

I’m afraid that we might accidentally introduce conflicts with future
release versions, e.g. when the latest release only uses two digits
(e.g. “0.1”) and we add a revision or a date (e.g. “0.1.1” or
“0.1.20160112”) and the next release and the next official release
switches to three digits (e.g. “0.1.1”).

Would it make sense to separate our version identifier from the actual
release version with a different character than “.”?  Or should this be
discussed elsewhere as it hasn’t anything to do with how we specify
versions on the command line?

~~ Ricardo

Re: [PATCH 5/6] gnu: mit-scheme: Generate and install documentation.

[Federico Beffa]

On Mon, Jan 11, 2016 at 8:06 PM, Leo Famulari  wrote:
>> It seems you don't get that my point is not about personal preferences
>> or feelings. It's about physical impairments (and there are plenty of
>> shades of grays between good sight and completely blind, where big,
>> good quality fonts matter).
>
> Agreed, I know two people with very severe visual impairments who find
> it more effective to magnify text to what seems an extreme degree than
> to use a Braille reader.

Thanks for sharing your experience supporting my claim!

Regards,
Fede

[PATCH 2/2] gnu: Add espeak.

[Leo Famulari]

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

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index 111a82d..2f679b7 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -2057,3 +2057,55 @@ 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.")
 (home-page "https://github.com/waywardgeek/sonic;)
 (license license:asl2.0)))
+
+(define-public espeak
+  (package
+(name "espeak")
+(version "1.48.04")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "mirror://sourceforge/project/espeak/espeak"
+ "/espeak-" (version-major+minor version)
+ "/espeak-" version "-source.zip"))
+ (sha256
+  (base32
+   "0n86gwh9pw0jqqpdz7mxggllfr8k0r7pc67ayy7w5z6z79kig6mz"
+(build-system gnu-build-system)
+(arguments
+  `(#:tests? #f ; no test suite
+#:make-flags (let ((out (assoc-ref %outputs "out")))
+   (list "--directory=src"
+ ;; 'runtime' uses PulseAudio if it is running, 
else
+ ;; it uses PortAudio.
+ "AUDIO=runtime"
+ ;; Add the 'lib' dir to the RUNPATH of the
+ ;; binaries.
+ (string-append "LDFLAGS=-Wl,-rpath=" out "/lib")
+ (string-append "DATADIR=" out 
"/share/espeak-data")
+ (string-append "PREFIX=" out)))
+#:phases (modify-phases %standard-phases
+   (add-after 'unpack 'patch-makefile
+ (lambda _
+   (substitute* "src/Makefile"
+ (("LN_SF = /bin/ln -sf") "LN_SF = ln -sf"
+;; The program supports portaudio versions 18 and 19. We
+;; package 19, so we select it here.
+   (add-after 'unpack 'pick-portaudio-version
+ (lambda _
+   (copy-file "src/portaudio19.h" "src/portaudio.h")))
+   (delete 'configure
+(native-inputs
+ `(("unzip" ,unzip)))
+(inputs
+  `(("sonic" ,sonic)
+("pulseaudio" ,pulseaudio)
+("portaudio" ,portaudio)))
+(synopsis "Software speech synthesizer")
+(description "eSpeak is a compact software speech synthesizer for
+English and other languages, for Linux and Windows.  eSpeak uses a
+formant synthesis method.  This allows many languages to be provided in
+a small size.  The speech is clear, and can be used at high speeds, but
+is not as natural or smooth as larger synthesizers which are based on
+human speech recordings.")
+(home-page "http://espeak.sourceforge.net/;)
+(license license:gpl3+)))
-- 
2.6.4

[PATCH 1/2] gnu: Add sonic.

[Leo Famulari]

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

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index ebae5d5..111a82d 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -2023,3 +2023,37 @@ that contains WAVE data, compressed or not---provided 
there exists a format
 module to handle that particular file type.")
 (home-page "http://etree.org/shnutils/shntool/;)
 (license license:gpl3+)))
+
+(define-public sonic
+  (package
+(name "sonic")
+(version "0.2.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append 
"https://github.com/waywardgeek/sonic/archive/;
+ "release-"
+ version ".tar.gz"))
+ (file-name (string-append name "-" version ".tar.gz"))
+ (sha256
+  (base32
+   "11a0q9wkgbb9ymf52v7dvybfhj8hprgr67zs1xcng143fvjpr0n7"
+(build-system gnu-build-system)
+(arguments
+  `(#:tests? #f ; no test suite
+#:make-flags
+ (list (string-append "DESTDIR=" (assoc-ref %outputs "out")))
+#:phases (modify-phases %standard-phases
+ (delete 'configure
+(synopsis "Speed up or slow down speech")
+(description "Sonic is a simple algorithm for speeding up or slowing down
+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.
+
+The primary motivation behind Sonic is to enable the blind and visually 
impaired
+to improve their productivity with open source speech engines, like 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.")
+(home-page "https://github.com/waywardgeek/sonic;)
+(license license:asl2.0)))
-- 
2.6.4

Re: [PATCH] build: Speed up .go compilation.

[Ludovic Courtès]

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

> Well, my observation while testing guix pull was that before, one would
> get several Guile processes each taking up about 100 MB memory if I
> remember correctly.  (As many processes as one has cores.)  So for dual-
> or quad-core devices we're not making things (much) worse, but maybe
> some single-core devices with little memory will now have problems.

Right, but now the amount of memory consumed is proportional to the
number of modules compiled, whereas it was constant before.

> If it becomes urgent, we could partition the files to be compiled into
> subsets and use a few Guile processes to compile them.  Could actually
> speed things up on multi-core devices, and would still be much faster
> than one-process-per-file on single-core.

Yes.

Ludo’.

Re: [PATCH] build: Speed up .go compilation.

[Ludovic Courtès]

Mathieu Lirzin  skribis:

  # Unset 'GUILE_LOAD_COMPILED_PATH' altogether while compiling.  
 Otherwise, if
  # $GUILE_LOAD_COMPILED_PATH contains $(moduledir), we may find .go files 
 in
  # there that are newer than the local .scm files (for instance because the
 @@ -358,14 +346,16 @@ GUILD_COMPILE_FLAGS =
 \
  #
  # XXX: Use the C locale for when Guile lacks
  # 
 .
>>>^^^
>>>
 -.scm.go:
 -  $(AM_V_GUILEC)$(MKDIR_P) `dirname "$@"` ;   \
 +%.go: make-go ; @:
 +make-go: $(MODULES) guix/config.scm guix/tests.scm
 +  @echo "Compiling Scheme modules..." ;   \
unset GUILE_LOAD_COMPILED_PATH ;\
LC_ALL=C\
>>> ^^^
>>>
>>> This is present because (scripts compile) from "old" Guile doesn't do it
>>> automatically.  What about copying the code from the link above in
>>> compile-all.scm and removing this from Makefile.am ?
>>
>> I should be using the whole (catch ...) expression, right?  Done, thanks
>> for the heads up.
>
> Yes I suppose.  Maybe Ludo can confirm?

It’s unnecessary to even call ‘setlocale’ in compile-all.scm because we
don’t rely on anything locale-specific.  So there’s no problem.

The LC_ALL=C line can also be removed from Makefile.am.

Ludo’.

Re: [PATCH] Add fxtract.

[Ludovic Courtès]

Ben Woodcroft  skribis:

> From acd310d27c457139d3f2fcd2cfc1127167bf2c48 Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft 
> Date: Thu, 7 Jan 2016 07:44:58 +1000
> Subject: [PATCH] gnu: Add fxtract.
>
> * gnu/packages/bioinformatics.scm (fxtract): New variable.

[...]

> +   `(("ctskennerton-util"
> +  ,(origin
> + (method git-fetch)
> + (uri (git-reference
> +   (url "https://github.com/ctSkennerton/util.git;)
> +   (commit util-commit)))

This is GPLv2-only.  Could you mention it in a comment?

> + (file-name (string-append
> + "ctstennerton-util-" util-commit "-checkout"))

I would make it:

  (string-append "ctstennerton-util-" (string-take util-commit 7)
 "-checkout")

> +  (home-page "https://github.com/ctSkennerton/fxtract;)
> +  (synopsis "Extract sequences from FASTA and FASTQ files")
> +  (description
> +   "Fxtract extracts sequences from a protein or nucleotide fastx (FASTA
> +or FASTQ) file given a subsequence.  It uses a simple substring search for
> +basic tasks but can change to using POSIX regular expressions, PCRE, hash
> +lookups or multi-pattern searching as required.  By default fxtract looks in
> +the sequence of each record but can also be told to look in the header,
> +comment or quality sections.")
> +  (license license:gpl3+

According to the ‘LICENSE’ file, this should be ‘license:expat’.

Otherwise LGTM.

Thanks,
Ludo’.

Re: [PATCH 5/6] gnu: mit-scheme: Generate and install documentation.

[Ludovic Courtès]

Federico Beffa  skribis:

> On Mon, Jan 11, 2016 at 10:09 AM, Ludovic Courtès  wrote:
>> Federico Beffa  skribis:
>>
>>> For PDFs, it depends on the type and quality of the manual. If it is
>>> short and/or poor, then nobody will spend hours reading it. But if the
>>> manual is good and long, then there is a chance that people will spend
>>> a lot of time reading it and it would be nice to have a good quality
>>> environment to read it (again, I'm talking about font graphics
>>> rendering).
>>
>> I agree that rendering is much better in PDF.
>>
>>> This is analogous to making public buildings suitable for people with
>>> wheel-chairs, ... may people don't care, until they are affected :-(
>>
>> I disagree with the analogy.  On a computer, I find it simply less
>> convenient to browse PDFs than to browse Info, and that outweighs the
>> better rendering quality.  (As it turns out, Info is also much more
>> usable for people using a Braille reader.)

[...]

> It seems you don't get that my point is not about personal preferences
> or feelings. It's about physical impairments (and there are plenty of
> shades of grays between good sight and completely blind, where big,
> good quality fonts matter).

My point about Braille reader is very clearly about physical
impairment.  I think I do get your point.

Ludo’.

Re: New CLI syntax for package version

[Ludovic Courtès]

shak...@openmailbox.org skribis:

> The problem I see with 3. is that the mailing list archives will detect the
> package names (with versions, ie the whole strings like ‘guile@1.8’) as email
> addresses, and hide them, by replacing them with ‘address@hidden’.  As an
> example, here’s the mail I replied to:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00343.html

True…  Gmane does something slightly less silly:

  http://article.gmane.org/gmane.comp.gnu.guix.devel/15058

Ludo’.

Re: [PATCH] Update Ruby to 2.3.0

[Ben Woodcroft]

On 11/01/16 07:14, Ludovic Courtès wrote:

Ben Woodcroft  skribis:


 From 2f26295b5a163cfc5d37332a501dcba5c40fb956 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Mon, 4 Jan 2016 09:38:42 +1000
Subject: [PATCH 5/5] gnu: ruby: Update to 2.3.0.

* gnu/packages/ruby.scm (ruby): Update to 2.3.0.
[arguments]: Remove bundled libffi.  Use parallel tests.
(ruby-2.2): New variable.

[...]


+ ;; Remove bundled libffi
+ (delete-file-recursively
+  (string-append "ext/fiddle/libffi-3.2.1"))

I should have mentioned it before, but could you move the removal to a
‘snippet’ in the origin?

All pushed to core-updates with a snippet and minor formatting changes.

 From 015a0e17be804dd7f68f21cde8a878ff353a4a97 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Fri, 8 Jan 2016 17:29:39 +1000
Subject: [PATCH 3/5] ruby: Abstract out path to GEM_HOME.

Previously paths to the GEM_HOME of certain Ruby packages were
hard-coded, so packages failed to build when Ruby was updated to 2.3.0.

* guix/build/ruby-build-system.scm (gem-home): New procedure.
* gnu/packages/ruby.scm (ruby-metaclass, ruby-instantiator,
ruby-introspection, ruby-mocha, ruby-minitest-tu-shim): Use it.

LGTM.

However, ultimately, we should pass the Ruby version as a keyword
parameter on the build side or have a build-side procedure akin to
‘get-python-version’ in python-build-system.scm (I’d prefer the former.)

That way, phases could query the version number of the Ruby that’s
actually used instead of using the version number of whatever variant
the global ‘ruby’ variable refers to.  This would allow users to simply
change the “ruby” input of a package and have it automatically work with
the new package.

Does that make sense?

This can always be done after the ‘core-updates’ merge, no rush.
OK then. I reckon we should provide a procedure to get to the lib/ 
directory as well, based on the upstream name property too. Then we can 
use it for the require test too.


Thanks,
ben

Re: New CLI syntax for package version

[shakmar]

Hi!

[…]

>>>1. slash, 
>>>
>>>   guile:1.8/doc
>>>   xterm-256-color:320
>>>   emacs:24.5/out
>>>
>>>2. underscore, 9#28>
>>>
>>>   emacs_24.5:out
>>>
>>>3. at, 
>>>
>>>   guile@1.8
>>>   guile@1.8:doc
>>>
>>> What do people think?
>> My order of preference (highest preference first) is: 3., 1., 2.
>
> Me too.
> ben

The problem I see with 3. is that the mailing list archives will detect the
package names (with versions, ie the whole strings like ‘guile@1.8’) as email
addresses, and hide them, by replacing them with ‘address@hidden’.  As an
example, here’s the mail I replied to:

https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00343.html

If it wasn’t for this problem, my order of preference would be 3-1-2 too.

Thanks for the effort, by the way. :)

[PATCH] bristol: Try to fix build on ARM + MIPS.

[Ricardo Wurmus]

>From 5290edcfa5f7ae8f6363df63b7f0738a7d0de5ac Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Mon, 11 Jan 2016 19:38:11 +0100
Subject: [PATCH] gnu: bristol: Remove SSE flags on platforms other than x86_64
 and i686.

* gnu/packages/music.scm (bristol)[arguments]: Add phase
"remove-sse-flags" to remove unsupported optimizations on platforms
other than x86_64 and i686.
---
 gnu/packages/music.scm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index fd1751e..7f1232e 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -659,6 +659,16 @@ Laurens Hammond and Don Leslie.")
(base32
 "1fi2m4gmvxdi260821y09lxsimq82yv4k5bbgk3kyc3x1nyhn7vx"
 (build-system gnu-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'remove-sse-flags
+   (lambda* (#:key system #:allow-other-keys)
+ (when (not (or (string-prefix? "x86_64" system)
+(string-prefix? "i686" system)))
+   (substitute* "bristol/Makefile.in"
+ (("-msse -mfpmath=sse") "")))
+ #t)
 (inputs
  `(("alsa-lib" ,alsa-lib)
("jack" ,jack-1)
-- 
2.5.0

[PATCHES] Add docker-compose and missing prerequisites.

[Thompson, David]

Hello Guix hackers,

As much as I dislike it, the company I work for has started to use
Docker.  Docker Compose is a special Python program that talks to the
Docker daemon to run many containers at once using configuration from
a "declarative" YAML file (my kingdom for an sexp), and I didn't want
to use pip to install it.  So, here's 8 patches that add it and the
stuff that was missing for it.

I hear someone has a working Go package that hasn't been submitted
yet, so maybe we'll have Docker itself available someday.  That will
be interesting. :)

TIA for review.

- Dave
From 29aa112adc961c806a56e03c9031c1385ad29f37 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:24:30 -0500
Subject: [PATCH 1/8] gnu: Add version 2.7 variant of python-requests.

* gnu/packages/python.scm (python-requests-2.7): New variable.
---
 gnu/packages/python.scm | 12 
 1 file changed, 12 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 4ab1eed..5f6ac79 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -2182,6 +2182,18 @@ compatible install in a way that is very close to the on-disk format.")
 than Python’s urllib2 library.")
 (license asl2.0)))
 
+;; Some software requires an older version of Requests, notably Docker
+;; Compose.
+(define-public python-requests-2.7
+  (package (inherit python-requests)
+(version "2.7.0")
+(source (origin
+ (method url-fetch)
+ (uri (pypi-uri "requests" version))
+ (sha256
+  (base32
+   "0gdr9dxm24amxpbyqpbh3lbwxc2i42hnqv50sigx568qssv3v2ir"))
+
 (define-public python2-requests
   (package-with-python2 python-requests))
 
-- 
2.6.3

From 41af50a9a40a7668e1069cf3a94c58c73dc50452 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:26:07 -0500
Subject: [PATCH 2/8] gnu: Add python-vcversioner.

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 5f6ac79..91629e8 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -2197,6 +2197,30 @@ than Python’s urllib2 library.")
 (define-public python2-requests
   (package-with-python2 python-requests))
 
+(define-public python-vcversioner
+  (package
+(name "python-vcversioner")
+(version "2.14.0.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "vcversioner" version))
+   (sha256
+(base32
+ "11ivq1bm7v0yb4nsfbv9m7g7lyjn112gbvpjnjz8nv1fx633dm5c"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(synopsis "Python library for version number discovery")
+(description "Vcversioner is a Python library that inspects tagging
+information in a variety of version control systems in order to discover
+version numbers.")
+(home-page "https://github.com/habnabit/vcversioner;)
+(license isc)))
+
+(define-public python2-vcversioner
+  (package-with-python2 python-vcversioner))
+
 (define-public python-jsonschema
   (package
 (name "python-jsonschema")
-- 
2.6.3

From 4609db7c4569b047f8357133dafacf3a3a418032 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:26:47 -0500
Subject: [PATCH 3/8] gnu: Update python-jsonschema to 2.5.1.

* gnu/packages/python.scm (python-jsonschema): Update to 2.5.1.
---
 gnu/packages/python.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 91629e8..e1009cc 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -2224,7 +2224,7 @@ version numbers.")
 (define-public python-jsonschema
   (package
 (name "python-jsonschema")
-(version "2.4.0")
+(version "2.5.1")
 (source (origin
  (method url-fetch)
  (uri
@@ -2233,10 +2233,11 @@ version numbers.")
version ".tar.gz"))
  (sha256
   (base32
-   "1yik3031ziygvq66rj3mzfqdgxj29sg1bkfc46wsgi7lnbqs560j"
+   "0hddbqjm4jq63y8jf44nswina1crjs16l9snb6m3vvgyg31klrrn"
 (build-system python-build-system)
 (inputs
- `(("python-setuptools" ,python-setuptools)))
+ `(("python-setuptools" ,python-setuptools)
+   ("python-vcversioner" ,python-vcversioner)))
 (home-page "http://github.com/Julian/jsonschema;)
 (synopsis "Implementation of JSON Schema for Python")
 (description
-- 
2.6.3

From 43b8e05406a62d0b201df9aac7c6bcc9ea74a92f Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:27:31 -0500
Subject: [PATCH 4/8] gnu: Add python-texttable.

* gnu/packages/python.scm 

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

[Ricardo Wurmus]

Hi Guix,

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”.

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

~~ Ricardo

>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.
---
 gnu/packages/cross-base.scm | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index d64cdd1..f947e7a 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -105,11 +105,12 @@ may be either a libc package or #f.)"
"--disable-libcilkrts")
  `( ;; Disable features not needed at this stage.
"--disable-shared" "--enable-static"
+   "--enable-languages=c,c++"
 
-   ;; Disable C++ because libstdc++'s configure
-   ;; script otherwise fails with "Link tests are not
-   ;; allowed after GCC_NO_EXECUTABLES."
-   "--enable-languages=c"
+   ;; libstdc++ cannot be built at this stage
+   ;; ("Link tests are not allowed after
+   ;; GCC_NO_EXECUTABLES.").
+   "--disable-libstdc++-v3"
 
"--disable-threads" ;libgcc, would need libc
"--disable-libatomic"
-- 
2.5.0

Re: [PATCH 5/6] gnu: mit-scheme: Generate and install documentation.

[Leo Famulari]

On Mon, Jan 11, 2016 at 12:58:41PM +0100, Federico Beffa wrote:
> On Mon, Jan 11, 2016 at 10:09 AM, Ludovic Courtès  wrote:
> > Federico Beffa  skribis:
> >
> >> For PDFs, it depends on the type and quality of the manual. If it is
> >> short and/or poor, then nobody will spend hours reading it. But if the
> >> manual is good and long, then there is a chance that people will spend
> >> a lot of time reading it and it would be nice to have a good quality
> >> environment to read it (again, I'm talking about font graphics
> >> rendering).
> >
> > I agree that rendering is much better in PDF.
> >
> >> This is analogous to making public buildings suitable for people with
> >> wheel-chairs, ... may people don't care, until they are affected :-(
> >
> > I disagree with the analogy.  On a computer, I find it simply less
> > convenient to browse PDFs than to browse Info, and that outweighs the
> > better rendering quality.  (As it turns out, Info is also much more
> > usable for people using a Braille reader.)
> >
> > When I want to read a complete manual, I prefer the paper version,
> > though.
> 
> It seems you don't get that my point is not about personal preferences
> or feelings. It's about physical impairments (and there are plenty of
> shades of grays between good sight and completely blind, where big,
> good quality fonts matter).

Agreed, I know two people with very severe visual impairments who find
it more effective to magnify text to what seems an extreme degree than
to use a Braille reader.

> 
> I will install PDFs in a separate output.
> 
> Regards,
> Fede
> 

qemu instructions for manual

[Leo Famulari]

Hi everyone,

I recently started using GuixSD in a virtual machine in advance of
getting some dedicated hardware.

This process is not well-documented, at least for somebody who is new to
QEMU. I don't think our manual should explain how to use QEMU, but I do
think it should provide the necessary information to get from `guix
system vm-image` to a working GuixSD virtual machine.

I'm looking for feedback on my understanding of QEMU so that my
contribution to the manual is accurate

This is a 'run-vm.sh' script produced by `guix system vm` for a simple
system declaration:

#!/gnu/store/ibpm6n6706yimzr3967krkxi2ibxq5yh-bash-4.3.39/bin/sh
exec 
/gnu/store/jm6wvkhq87kwr2grlravx6ix3w63p996-qemu-2.4.0.1/bin/qemu-system-x86_64 
\
-kernel /gnu/store/lcs3ncjam9xxkczy34rdn7mxn0y912g9-linux-libre-4.3.3/bzImage \
-initrd /gnu/store/1n5q21mc49pkb33ynf6nzrmx11vgp28r-system/initrd \
-append "--system=/gnu/store/1n5q21mc49pkb33ynf6nzrmx11vgp28r-system 
--load=/gnu/store/1n5q21mc49pkb33ynf6nzrmx11vgp28r-system/boot --root=/dev/vda1 
" \
-enable-kvm \
-no-reboot \
-net nic,model=virtio \
-virtfs local,path="/gnu/store",security_model=none,mount_tag="TAG_gnu_store" \
-net user \
-serial stdio \
-vga std \
-drive 
file=/gnu/store/2azafsay573829m1hynp27kwvmssdp1f-qemu-image,if=virtio,cache=writeback,werror=report,readonly
 \
-m 256 \
"$@"

This appears to be the minimum QEMU invocation that works:
$ qemu-system-x86_64 \
-net user \
-net nic,model=virtio \
-m 256 \
./qemu-image

Is there anything else that can be adapted from the run-vm.sh script?

After playing around with `guix system vm-image`, this appears to be the
minimum list of commands that will successfully boot GuixSD:
$ guix system vm-image --image-size=1G ~/guix/doc/os-config-bare-bones.texi 
$ cp /gnu/store/...-qemu-image ./qemu-image && guix gc -d 
/gnu/store/...-qemu-image
$ chmod 600 ./qemu-image
$ qemu-system-x86_64 \
-net user \
-net nic,model=virtio \
-m 256 \
./qemu-image

Annotated version:
# System type to emulate. Does this have to match the host hardware? Can
# "foreign" arch machine images be built with Guix?
$ qemu-system-x86_64 \

# Unprivileged user mode networking. Guest can access host but not vice versa.
# If you don't choose a network stack, the boot process will fail.
-net user \

# You must create a network interface of a given model. You can get a list of
# available NIC types by running `qemu-system-$arch -net nic,model=help`. If
# you don't create a NIC, the boot process will fail.
-net nic,model=virtio \

# RAM available to the guest OS. Defaults to 128 megabytes, which is not enough
# for the Guix daemon. More is better.
-m 256 \

OPTIONAL: If your system is x86 with hardware virtualization extensions,
enabling the kernel virtual machine will make things go much faster.
-enable-kvm \

# Path to the virtual machine image
./qemu-image

Any feedback?