[PATCH] Add ibus-libpinyin.

[Ricardo Wurmus]

>From 984245dcc1359c4de3ff3a26c0d1d6427a88b6fa Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Wed, 9 Sep 2015 07:27:18 +0200
Subject: [PATCH 1/2] gnu: Add libpinyin.

* gnu/packages/ibus.scm (libpinyin): New variable.
---
 gnu/packages/ibus.scm | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/gnu/packages/ibus.scm b/gnu/packages/ibus.scm
index b2d3fa5..6b8d262 100644
--- a/gnu/packages/ibus.scm
+++ b/gnu/packages/ibus.scm
@@ -24,6 +24,8 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system glib-or-gtk)
   #:use-module (gnu packages)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages base)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages gtk)
@@ -98,3 +100,51 @@ input method user interface.  It comes with multilingual input support.  It
 may also simplify input method development.")
(home-page "http://ibus.googlecode.com/;)
(license lgpl2.1+)))
+
+(define-public libpinyin
+  (package
+(name "libpinyin")
+(version "1.2.0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"https://github.com/libpinyin/libpinyin/archive/;
+version ".tar.gz"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"04didxd39vlry6nqy7xqynwc68ndajnhw334wahfmp7zjbbscs7p"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-before 'configure 'autogen
+  (lambda _ (zero? (system* "autoreconf" "-vif"
+ (add-after 'unpack 'unpack-model
+  (lambda* (#:key inputs #:allow-other-keys)
+(zero? (system* "tar" "-xvf"
+(assoc-ref inputs "model")
+"-C" "data")))
+(inputs
+ `(("glib" ,glib)
+   ("bdb" ,bdb)
+   ("model"
+,(origin
+   (method url-fetch)
+   (uri (string-append "http://downloads.sourceforge.net/libpinyin/;
+   "models/model10.text.tar.gz"))
+   (sha256
+(base32
+ "0g489wqcfklxphhxpkh8i4qf9y8scmnmdbfrzdbrgf3rignbwyiw"))
+(native-inputs
+ `(("pkg-config" ,pkg-config)
+   ("tar" ,tar)
+   ("autoconf" ,autoconf)
+   ("automake" ,automake)
+   ("libtool" ,libtool)))
+(synopsis "Library to handle Chinese Pinyin")
+(description
+ "The libpinyin C++ library provides algorithms needed for sentence-based
+Chinese pinyin input methods.")
+(home-page "https://github.com/libpinyin/libpinyin;)
+(license gpl2+)))
-- 
2.5.0

>From d474729c8f8951e2c7e45cc7dba1b1542ab0e5a8 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Wed, 9 Sep 2015 07:28:23 +0200
Subject: [PATCH 2/2] gnu: Add ibus-libpinyin.

* gnu/packages/ibus.scm (ibus-libpinyin): New variable.
---
 gnu/packages/ibus.scm | 55 +++
 1 file changed, 55 insertions(+)

diff --git a/gnu/packages/ibus.scm b/gnu/packages/ibus.scm
index 6b8d262..7eb9e60 100644
--- a/gnu/packages/ibus.scm
+++ b/gnu/packages/ibus.scm
@@ -26,6 +26,8 @@
   #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages base)
+  #:use-module (gnu packages databases)
+  #:use-module (gnu packages freedesktop)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages gtk)
@@ -101,6 +103,59 @@ may also simplify input method development.")
(home-page "http://ibus.googlecode.com/;)
(license lgpl2.1+)))
 
+(define-public ibus-libpinyin
+  (package
+   (name "ibus-libpinyin")
+   (version "1.7.2")
+   (source (origin
+ (method url-fetch)
+ (uri (string-append "https://github.com/libpinyin/;
+ "ibus-libpinyin/archive/" version ".tar.gz"))
+ (file-name (string-append name "-" version ".tar.gz"))
+ (sha256
+  (base32
+   "080ixx5lih9lr78b061y67dqmiyc7ij87jl1sa26hhs1dr28ihka"
+   (build-system glib-or-gtk-build-system)
+   (arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-before 'configure 'autogen
+  (lambda _ (and (zero? (system* "intltoolize"))
+ (zero? (system* "autoreconf" "-vif")
+ (add-after 'wrap-program 'wrap-with-additional-paths
+  (lambda* (#:key inputs outputs #:allow-other-keys)
+;; Make sure 'ibus-setup-libpinyin' runs with the correct
+;; PYTHONPATH and GI_TYPELIB_PATH.
+(let ((out (assoc-ref outputs "out")))
+  (wrap-program (string-append out "/libexec/ibus-setup-libpinyin")
+`("PYTHONPATH" ":" prefix
+  (,(getenv 

Re: [PATCH 0/1] Add lz4 (C implementation)

[Leo Famulari]

So, it is confirmed that parallel testing is not supposed to work:
https://groups.google.com/forum/#!topic/lz4c/Egwtrrbb66M
"If you are talking about doing multiple `make test` in parallel,
then indeed, some tests involved writing, reading, and removing test
files from local directory,
so should multiple such operations happen randomly in parallel, there is
a high probability that it will not end well."

On Wed, Sep 9, 2015, at 17:26, Taylan Ulrich Bayırlı/Kammer wrote:
> Guix contains a lot of software with build and test phases that take a
> very long time.  When I was working on Qt it would take 5 GB of disk
> space and 6 hours to build every time.  Though that was a pathological
> case and this program is tiny in comparison, I'd still say ~30 minutes
> is harmless.  It's annoying, but that's the price of disciplined work.

In that case, I say we leave the tests in.

Re: [PATCH] build: Fix potential type error when generating human-friendly byte count strings.

[Mark H Weaver]

Steve Sprang  writes:

> This is a follow up tweak to my previous "progress bar" patch. With a
> really slow throughput it's possible to get fractional sub-KiB byte
> counts, so I added some additional number massaging.

Sounds good!  Looks good to me except for a few minor nits on this
auxiliary procedure:

> +(define (number->integer n)
> +  "Given an arbitrary number N, round it and return the exact result."
> +  (inexact->exact (round n)))

How about calling it "nearest-exact-integer"?  Also, it makes sense only
for real numbers, not arbitrary numbers, and the variable name N is
conventionally used to denote natural numbers, and X for real numbers.

So, how about naming the argument 'x', and using something closer to the
following docstring:

  "Given a real number X, return the nearest exact integer, with ties
going to the nearest exact even integer."

Otherwise, looks good to me.  Can you send an updated patch?

  Mark

Re: [PATCH] build: Fix potential type error when generating human-friendly byte count strings.

[Steve Sprang]

Sure thing. Here you go.

-Steve

On Wed, Sep 9, 2015 at 7:42 PM, Mark H Weaver  wrote:

> Steve Sprang  writes:
>
> > This is a follow up tweak to my previous "progress bar" patch. With a
> > really slow throughput it's possible to get fractional sub-KiB byte
> > counts, so I added some additional number massaging.
>
> Sounds good!  Looks good to me except for a few minor nits on this
> auxiliary procedure:
>
> > +(define (number->integer n)
> > +  "Given an arbitrary number N, round it and return the exact result."
> > +  (inexact->exact (round n)))
>
> How about calling it "nearest-exact-integer"?  Also, it makes sense only
> for real numbers, not arbitrary numbers, and the variable name N is
> conventionally used to denote natural numbers, and X for real numbers.
>
> So, how about naming the argument 'x', and using something closer to the
> following docstring:
>
>   "Given a real number X, return the nearest exact integer, with ties
> going to the nearest exact even integer."
>
> Otherwise, looks good to me.  Can you send an updated patch?
>
>   Mark
>
From 922d9ae8b6f2c13638b49fcc8b79f8d464f01244 Mon Sep 17 00:00:00 2001
From: Steve Sprang 
Date: Wed, 9 Sep 2015 13:59:52 -0700
Subject: [PATCH] build: Fix potential type error when generating
 human-friendly byte count strings.

* guix/build/download.scm (nearest-exact-integer): New function.
  (seconds->string): Use new rounding function.
  (byte-count->string):  Use new rounding function.
---
 guix/build/download.scm | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index 6e85174..31d60fb 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -49,6 +49,11 @@
   ;; Size of the HTTP receive buffer.
   65536)
 
+(define (nearest-exact-integer x)
+  "Given a real number X, return the nearest exact integer, with ties going to
+the nearest exact even integer."
+  (inexact->exact (round x)))
+
 (define (duration->seconds duration)
   "Return the number of seconds represented by DURATION, a 'time-duration'
 object, as an inexact number."
@@ -60,7 +65,7 @@ object, as an inexact number."
 format."
   (if (not (number? duration))
   "00:00:00"
-  (let* ((total-seconds (inexact->exact (round duration)))
+  (let* ((total-seconds (nearest-exact-integer duration))
  (extra-seconds (modulo total-seconds 3600))
  (hours (quotient total-seconds 3600))
  (mins  (quotient extra-seconds 60))
@@ -75,8 +80,8 @@ way."
 (GiB (expt 1024. 3))
 (TiB (expt 1024. 4)))
 (cond
- ((< size KiB) (format #f "~dB" (inexact->exact size)))
- ((< size MiB) (format #f "~dKiB" (inexact->exact (round (/ size KiB)
+ ((< size KiB) (format #f "~dB" (nearest-exact-integer size)))
+ ((< size MiB) (format #f "~dKiB"   (nearest-exact-integer (/ size KiB
  ((< size GiB) (format #f "~,1fMiB" (/ size MiB)))
  ((< size TiB) (format #f "~,2fGiB" (/ size GiB)))
  (else (format #f "~,3fTiB" (/ size TiB))
-- 
2.5.0

Dealing with common collisions in profiles

[Ludovic Courtès]

Hello!

You’ve probably noticed that as soon as there’s a non-negligible number
of packages in a profile, there are collisions.  It’s really harmless,
but seriously annoying.  Here’s a collection of those I get:

  share/glib-2.0/schemas/gschemas.compiled
  share/icons/hicolor/icon-theme.cache
  lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
  lib/perl5/5.16.1/x86_64-linux/perllocal.pod

Federico, I know ‘glib-or-gtk-build-system’ builds the first 3 items on
purpose, but what do you think can be done about them?  At worst we
could always change (guix build profiles) to not report collisions for
those.

The .pod files are used by ‘perldoc’ IIUC.  What can be done about them?

Thanks,
Ludo’.

[PATCH 1/1] gnu: Add lz4.

[Leo Famulari]

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

diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 287ae25..e96518c 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer 
 ;;; Copyright © 2015 Eric Bavier 
 ;;; Copyright © 2015 Ricardo Wurmus 
+;;; Copyright © 2015 Leo Famulari 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -30,6 +31,7 @@
   #:use-module (guix build-system perl)
   #:use-module (gnu packages base)
   #:use-module (gnu packages perl)
+  #:use-module (gnu packages valgrind)
   #:use-module ((srfi srfi-1) #:select (last)))
 
 (define-public zlib
@@ -513,3 +515,34 @@ compression library.")
 (description "IO-Compress provides a Perl interface to allow reading and
 writing of compressed data created with the zlib and bzip2 libraries.")
 (license (package-license perl
+
+(define-public lz4
+  (package
+(name "lz4")
+(version "r131")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/Cyan4973/lz4/archive/;
+version ".tar.gz"))
+   (sha256
+(base32 "1vfg305zvj50hwscad24wan9jar6nqj14gdk2hqyr7bb9mhh0kcx"
+(build-system gnu-build-system)
+(native-inputs `(("valgrind" ,valgrind)))
+(arguments
+ `(#:test-target "test"
+   #:parallel-tests? #f ; tests fail if run in parallel
+   #:make-flags (list "CC=gcc"
+  (string-append "PREFIX=" (assoc-ref %outputs "out")))
+   #:phases (modify-phases %standard-phases
+  (delete 'configure
+(home-page "https://github.com/Cyan4973/lz4;)
+(synopsis "Compression algorithm focused on speed")
+(description "LZ4 is a lossless compression algorithm, providing
+compression speed at 400 MB/s per core (0.16 Bytes/cycle).  It also features an
+extremely fast decoder, with speed in multiple GB/s per core (0.71 
Bytes/cycle).
+A high compression derivative, called LZ4_HC, is also provided.  It trades CPU
+time for compression ratio.")
+;; The libraries (lz4, lz4hc, and xxhash are BSD licenced. The command
+;; line interface programs (lz4, fullbench, fuzzer, datagen) are GPL2+.
+(license (list license:bsd-2 license:gpl2+
-- 
2.4.3

[PATCH 0/1] Add lz4 (C implementation)

[Leo Famulari]

This patch adds the C reference implementation of the lz4 compression
algorithm.

I'm looking for advice regarding the tests. The tests take >30 minutes on my on
my quad-core i5 with 8 gigabytes of RAM and they require Valgrind as a
native-input. This seems excessive to me but if users install binary
substitutes, they won't run the tests or need to install Valgrind, right? And 
if distributions won't test software, then who will?

It might be possible to cherry-pick which tests are used. `make test` is a
recursive call to a Makefile in the programs/ subdirectory of the tarball. That
Makefile builds the lists of test to run. For this reason, setting
'test-target' in the package definition won't work because it works on the 
top-level Makefile. If someone knows how to specify the test-targets on the 
second Makefile, we could ask upstream for advice on what tests to exclude.

Also, I have sent a message to the lz4 author asking if tests are expected to
fail when run in parallel. I expect the answer is yes, but I'd like to be sure.

Leo Famulari (1):
  gnu: Add lz4.

 gnu/packages/compression.scm | 33 +
 1 file changed, 33 insertions(+)

-- 
2.4.3

[PATCH] build: Fix potential type error when generating human-friendly byte count strings.

[Steve Sprang]

This is a follow up tweak to my previous "progress bar" patch. With a
really slow throughput it's possible to get fractional sub-KiB byte counts,
so I added some additional number massaging.

-Steve
From daccd58e5fbe366ebcd33092f70ca45bc79285e0 Mon Sep 17 00:00:00 2001
From: Steve Sprang 
Date: Wed, 9 Sep 2015 13:59:52 -0700
Subject: [PATCH] build: Fix potential type error when generating
 human-friendly byte count strings.

* guix/build/download.scm (number->integer): New function.
  (seconds->string): Use new rounding function.
  (byte-count->string):  Use new rounding function.
---
 guix/build/download.scm | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index 6e85174..a0b8d92 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -49,6 +49,10 @@
   ;; Size of the HTTP receive buffer.
   65536)
 
+(define (number->integer n)
+  "Given an arbitrary number N, round it and return the exact result."
+  (inexact->exact (round n)))
+
 (define (duration->seconds duration)
   "Return the number of seconds represented by DURATION, a 'time-duration'
 object, as an inexact number."
@@ -60,7 +64,7 @@ object, as an inexact number."
 format."
   (if (not (number? duration))
   "00:00:00"
-  (let* ((total-seconds (inexact->exact (round duration)))
+  (let* ((total-seconds (number->integer duration))
  (extra-seconds (modulo total-seconds 3600))
  (hours (quotient total-seconds 3600))
  (mins  (quotient extra-seconds 60))
@@ -75,8 +79,8 @@ way."
 (GiB (expt 1024. 3))
 (TiB (expt 1024. 4)))
 (cond
- ((< size KiB) (format #f "~dB" (inexact->exact size)))
- ((< size MiB) (format #f "~dKiB" (inexact->exact (round (/ size KiB)
+ ((< size KiB) (format #f "~dB" (number->integer size)))
+ ((< size MiB) (format #f "~dKiB"   (number->integer (/ size KiB
  ((< size GiB) (format #f "~,1fMiB" (/ size MiB)))
  ((< size TiB) (format #f "~,2fGiB" (/ size GiB)))
  (else (format #f "~,3fTiB" (/ size TiB))
-- 
2.5.0

Re: [PATCH] Add ibus-libpinyin.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> From 984245dcc1359c4de3ff3a26c0d1d6427a88b6fa Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Wed, 9 Sep 2015 07:27:18 +0200
> Subject: [PATCH 1/2] gnu: Add libpinyin.
>
> * gnu/packages/ibus.scm (libpinyin): New variable.

[...]

> +,(origin
> +   (method url-fetch)
> +   (uri (string-append "http://downloads.sourceforge.net/libpinyin/;
> +   "models/model10.text.tar.gz"))

Should be mirror://sourceforge/ if possible.

> +(native-inputs
> + `(("pkg-config" ,pkg-config)
> +   ("tar" ,tar)

‘tar’ can be omitted, it’s an implicit input.

Otherwise OK.

> From d474729c8f8951e2c7e45cc7dba1b1542ab0e5a8 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Wed, 9 Sep 2015 07:28:23 +0200
> Subject: [PATCH 2/2] gnu: Add ibus-libpinyin.
>
> * gnu/packages/ibus.scm (ibus-libpinyin): New variable.

LGTM.

It’s a pity that no ‘make dist’ tarball is published; that would make
everbody’s lives easier.

Thanks,
Ludo’.

Re: (Geiser or guile bug) Guix-daemon output is missing

[Ludovic Courtès]

Alex Kost  skribis:

> As a workaround for this issue it was proposed¹ to transform
> ‘current-build-output-port’ into a procedure (I have checked that it
> solves the problem).  What do you think about it?  Perhaps to make sure
> that the port will be always the same define it like this:
>
> (define current-build-output-port (memoize current-error-port))
>
> Is it acceptable?

No, ‘current-build-output-port’ should remain a SRFI-39 parameter so
that callers can easily rebind it.

However, perhaps the guix.el code could do:

  (current-build-output-port (current-error-port))

at startup; would that be doable?

Thanks,
Ludo’.

Re: Outdated package "r-scales"

[Cyril Roelandt]

On 09/09/2015 09:50 PM, Vicente Vera wrote:
> Hello,
> Right now installing r-ggplot2 fails because dependency r-scales can't
> be found on CRAN mirrors:
> 
> ERROR: download failed
> "http://cran.../src/contrib/scales_0.2.5.tar.gz; 404 "Not Found"
> 

Are old versions always removed from the CRAN mirrors?

Could you send a patch to update r-scales?

Thanks,
Cyril.

Re: [PATCH 5/6] guix: Move package-transitive-propagated-labels* and package-propagated-input-refs to (guix packages).

[Ludovic Courtès]

Eric Bavier  skribis:

> I find myself needing this functionality while exploring configuration
> support in xmonad, so I am (finally) revisiting this patch.

Nice!

> For Perl, my idea is to wrap each module somehow, so that perl gets the
> appropriate 'use lib "/gnu/store/..."' when it loads each module.
> Preferably the solution would also work with store deduplication.
> I've not yet confirmed this is even feasible, so anyone with more perl
> knowledge should chime in.
>
> Our haskell modules install files into a "package.conf.d" subdirectory,
> and these files actually keep references to all haskell modules that
> were configured in the environment when it was built.  I'm baffled why
> GHC does not make use of this information for dependency resolution when
> it loads libraries.  Perhaps we could hack our GHC to do so.

This sounds like retrofitting some RUNPATH-like functionality in
languages.  This would be ideal, and we should use whatever already
exists if that does the job (which seems to be the case for Perl?).

Otherwise we should really push upstream to implement that
functionality.

> From c7932475b95f22f891169b7f315366e2602fb4f5 Mon Sep 17 00:00:00 2001
> From: Eric Bavier 
> Date: Tue, 21 Jul 2015 20:45:54 -0500
> Subject: [PATCH 5/6] guix: packages: Add transitive-input-references.
>
> * guix/packages.scm (transitive-input-references): New procedure.
> * gnu/packages/version-control.scm (package-transitive-propagated-labels*)
>   (package-propagated-input-refs): Delete.
>   (git)[arguments]: Adjust to transitive-input-references.

It addresses previous comments and looks reasonable to me.

OK for ‘master’!

Thank you,
Ludo’.

Outdated package "r-scales"

[Vicente Vera]

Hello,
Right now installing r-ggplot2 fails because dependency r-scales can't
be found on CRAN mirrors:

ERROR: download failed
"http://cran.../src/contrib/scales_0.2.5.tar.gz; 404 "Not Found"

Current version of r-scales is "0.3.0".

'guix download' output:

starting download of `/tmp/guix-file.DyKVF9' from
`http://cran.rstudio.com/src/contrib/scales_0.3.0.tar.gz'...
 scales_0.3.0.tar.gz  56KiB  124KiB/s 00:00:00 [] 100.0%
/gnu/store/gjk0cdfyi83gygcka0ai1cvmqvcv10ab-scales_0.3.0.tar.gz
1kkgpqzb0a6lnpblhcprr4qzyfk5lhicdv4639xs5cq16n7bkqgl

Re: Outdated package "r-scales"

[Vicente Vera]

Messed up. It should say:

Current version of R package scales is 0.3.0. In Guix, version of
package r-scales is 0.2.5.

The output of 'guix download' shows the hash of the new "0.3.0"
version of scales.

2015-09-09 16:50 GMT-03:00 Vicente Vera :
> Hello,
> Right now installing r-ggplot2 fails because dependency r-scales can't
> be found on CRAN mirrors:
>
> ERROR: download failed
> "http://cran.../src/contrib/scales_0.2.5.tar.gz; 404 "Not Found"
>
> Current version of r-scales is "0.3.0".
>
> 'guix download' output:
>
> starting download of `/tmp/guix-file.DyKVF9' from
> `http://cran.rstudio.com/src/contrib/scales_0.3.0.tar.gz'...
>  scales_0.3.0.tar.gz  56KiB  124KiB/s 00:00:00 [] 
> 100.0%
> /gnu/store/gjk0cdfyi83gygcka0ai1cvmqvcv10ab-scales_0.3.0.tar.gz
> 1kkgpqzb0a6lnpblhcprr4qzyfk5lhicdv4639xs5cq16n7bkqgl

Re: (Geiser or guile bug) Guix-daemon output is missing

[Alex Kost]

Ludovic Courtès (2015-09-09 23:11 +0300) wrote:

> Alex Kost  skribis:
>
>> As a workaround for this issue it was proposed¹ to transform
>> ‘current-build-output-port’ into a procedure (I have checked that it
>> solves the problem).  What do you think about it?  Perhaps to make sure
>> that the port will be always the same define it like this:
>>
>> (define current-build-output-port (memoize current-error-port))
>>
>> Is it acceptable?
>
> No, ‘current-build-output-port’ should remain a SRFI-39 parameter so
> that callers can easily rebind it.
>
> However, perhaps the guix.el code could do:
>
>   (current-build-output-port (current-error-port))
>
> at startup; would that be doable?

(IMO it would be so ugly, that I should say: "no")

Do you mean at startup of Guix REPL?  If you remember the point is to
add an emacs command to build the package in the current Geiser REPL
(not Guix REPL).  So to prevent this disappearing of the build output,
(current-build-output-port (current-error-port)) should be evaluated in
the *Geiser REPL*.  We can make a workaround just for ‘build-package’
procedure by putting this port assigning in it, but the only way to make
a global solution is to get rid of the top-level setting of
‘current-build-output-port’, for example by:

(define current-build-output-port (make-parameter #f))

and bind it to current-error-port in ‘process-stderr’, but I suppose
this is also undesired, right?

-- 
Alex

Re: Outdated package "r-scales"

[Vicente Vera]

Patch attached.

2015-09-09 17:19 GMT-03:00 Cyril Roelandt :
> On 09/09/2015 09:50 PM, Vicente Vera wrote:
>> Hello,
>> Right now installing r-ggplot2 fails because dependency r-scales can't
>> be found on CRAN mirrors:
>>
>> ERROR: download failed
>> "http://cran.../src/contrib/scales_0.2.5.tar.gz; 404 "Not Found"
>>
>
> Are old versions always removed from the CRAN mirrors?
>
> Could you send a patch to update r-scales?
>
> Thanks,
> Cyril.
>
From f70dc3b10fc9274ca3b6d95f966928e7ed71432d Mon Sep 17 00:00:00 2001
From: Vicente Vera Parra 
Date: Wed, 9 Sep 2015 18:07:09 -0300
Subject: [PATCH] gnu: r-scales: Update to 0.3.0.

* gnu/packages/statistics.scm (r-scales): Update to 0.3.0.
---
 gnu/packages/statistics.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 29cd34a..2e89fa9 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -445,14 +445,14 @@ using just two functions: melt and dcast (or acast).")
 (define-public r-scales
   (package
 (name "r-scales")
-(version "0.2.5")
+(version "0.3.0")
 (source
  (origin
(method url-fetch)
(uri (string-append "mirror://cran/src/contrib/scales_"
version ".tar.gz"))
(sha256
-(base32 "12xrmn1vh64dl46bq7n7pa427aicb2ifjrby9in3m32nyvir0kac"
+(base32 "1kkgpqzb0a6lnpblhcprr4qzyfk5lhicdv4639xs5cq16n7bkqgl"
 (build-system r-build-system)
 (propagated-inputs
  `(("r-dichromat" ,r-dichromat)
-- 
2.5.1

Re: [PATCH 0/1] Add lz4 (C implementation)

[Taylan Ulrich Bayırlı/Kammer]

Leo Famulari  writes:

> This patch adds the C reference implementation of the lz4 compression
> algorithm.
>
> I'm looking for advice regarding the tests. The tests take >30 minutes
> on my on my quad-core i5 with 8 gigabytes of RAM and they require
> Valgrind as a native-input. This seems excessive to me but if users
> install binary substitutes, they won't run the tests or need to
> install Valgrind, right? And if distributions won't test software,
> then who will?

Indeed users won't have to go through that unless they build from
source, and Valgrind won't become a run-time dependency so long as the
produced package does not contain any references to any files from the
Valgrind package.

Guix contains a lot of software with build and test phases that take a
very long time.  When I was working on Qt it would take 5 GB of disk
space and 6 hours to build every time.  Though that was a pathological
case and this program is tiny in comparison, I'd still say ~30 minutes
is harmless.  It's annoying, but that's the price of disciplined work.

Taylan