Re: [PATCH] gnu: Add libgnomekbd.

[Ludovic Courtès]

ng0  skribis:

> From 177706fe15b53a9b8ea3c053b878e6f0ed1fa8b9 Mon Sep 17 00:00:00 2001
> From: ng0 
> Date: Sun, 31 Jul 2016 10:45:35 +
> Subject: [PATCH] gnu: Add libgnomekbd.
>
> * gnu/packages/gnome.scm (libgnomekbd): New variable.

[...]

> +(inputs
> + `(("gtk+" ,gtk+)
> +   ("libxklavier" ,libxklavier)))

I moved these to ‘propagated-inputs’ since they’re already mentioned in
the .pc file, and pushed.

Thanks!

Ludo’.

Re: [PATCH 3/3] gnu: Add s6-linux-utils.

[Ludovic Courtès]

Eric Le Bihan  skribis:

> * gnu/packages/skarnet.scm (s6-linux-utils): New variable.

[...]

> +(description
> + "s6-linux-utils is a set of minimalistic Linux-specific system
> +utilities.")))

Expounded a bit and pushed, thanks!

Ludo’.

Re: [PATCH 2/3] gnu: Add s6-portable-utils.

[Ludovic Courtès]

Eric Le Bihan  skribis:

> * gnu/packages/skarnet.scm (s6-portable-utils): New variable.

[...]

> +(synopsis "Set of tiny general Unix utilities")

Removed “Set of”…

> +(description
> + "s6-portable-utils is a set of tiny general Unix utilities, often
> +performing well-known tasks such as cut and grep, but optimized for

… and added @command here.

Applied, thanks!

Ludo’.

Re: [PATCH 1/3] gnu: Add s6-rc.

[Ludovic Courtès]

Eric Le Bihan  skribis:

> * gnu/packages/skarnet.scm (s6-rc): New variable.

Applied, thanks!

Re: [PATCH] add go@1.6

[Ludovic Courtès]

Hello!

Matthew Jordan  skribis:

> From fbe9e4074cd27449d2337f62c7004993d087f6ba Mon Sep 17 00:00:00 2001
> From: Matthew Jordan 
> Date: Thu, 26 May 2016 09:16:48 -0400
> Subject: [PATCH] gnu: Add go@1.6.
>
> * gnu/packages/golang.scm (go-1.6): New variable.
>
> Co-author: Efraim Flashner 
> Co-author: Andy Wingo 

Awesome!  I made small changes:

> +(arguments
> + `(#:modules ((ice-9 match)
> +  (guix build gnu-build-system)
> +  (guix build utils))
> +   #:tests? #f ; Tests are run by all.bash script
> +   #:phases
> +   (modify-phases %standard-phases
> + (delete 'configure)
> + (add-after 'patch-generated-file-shebangs 'chdir
> +   (lambda _ (chdir "src")))

… using ‘substitute-keyword-arguments’ here to try to factorize build
phases with go@1.4, though in practice there are subtle differences
preventing the ‘prebuild’ and ‘install’ phases from being factorized.
Would be nice to improve it eventually, somehow.
> +(inputs
> + `(,@(package-inputs go-1.4)))

This is equivalent to:

  (inputs (package-inputs go-1.4))

which is equivalent to putting nothing, since we already ‘inherit’ from
go-1.4.

> +(propagated-inputs
> + `(,@(package-propagated-inputs go-1.4)

Ditto.

Committed, thank you!

Ludo’.

Re: [PATCH] gnu: Add awesome.

[Leo Famulari]

On Sun, Jul 31, 2016 at 09:45:29PM +, ng0 wrote:
> Leo Famulari  writes:
> 
> > On Fri, Jun 17, 2016 at 09:31:59AM +1000, Carlo Zancanaro wrote:
> >> On 16 June 2016 at 22:38, Ludovic Courtès  wrote:
> >> 
> >> > Primarily, I built it with --rounds=2 as per
> >> > <
> >> > https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>
> >> > ...
> >> >
> >> 
> >> I tried to build with --rounds=2, but always after I had built normally
> >> (because I cared first about whether it compiled, then later about whether
> >> it was deterministic). The --rounds=2 build never seemed to do anything. Is
> >> there something I have to do to make that work? (I tried adding the --check
> >> flag too, but it also seemed to not do anything, either with or without
> >> --rounds.)
> >
> > Once you have built the package and it is in /gnu/store, you need to use
> > --check.

Reading back, I realize that we didn't talk about grafting. --check
might not appear to have any effect if the package is grafted; in that
case, you'd need to add --no-grafts.

Re: [PATCH ?] gnu: Add dash.

[Leo Famulari]

On Sun, Jul 31, 2016 at 11:18:14PM +0200, Tobias Geerinckx-Rice wrote:
> Indeed; thanks for adding that. dash is horrible for interactive use,
> but fast at running shell[1] scripts. If anyone thinks that might be
> relevant in the description, let me know.

Nope, no suggestion from me :) I just wanted to provide some context.

> [1]:  It's also a trivial way to catch 98% of bash-specific code.

Yup, it's how I like to test /bin/sh scripts.

Re: [PATCH] gnu: Add awesome.

[ng0]

Leo Famulari  writes:

> On Fri, Jun 17, 2016 at 09:31:59AM +1000, Carlo Zancanaro wrote:
>> On 16 June 2016 at 22:38, Ludovic Courtès  wrote:
>> 
>> > Primarily, I built it with --rounds=2 as per
>> > <
>> > https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>
>> > ...
>> >
>> 
>> I tried to build with --rounds=2, but always after I had built normally
>> (because I cared first about whether it compiled, then later about whether
>> it was deterministic). The --rounds=2 build never seemed to do anything. Is
>> there something I have to do to make that work? (I tried adding the --check
>> flag too, but it also seemed to not do anything, either with or without
>> --rounds.)
>
> Once you have built the package and it is in /gnu/store, you need to use
> --check.
>
> In that case, I'm not sure how it interacts with --rounds.
>
> It would be good to get a reproducer if there's a bug here.
>

What is the exact problem here? these are my builts:

ng0@shadowwalker ~$ guix build --rounds=2 awesome
substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/3g3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv
   The following files will be downloaded:
  /gnu/store/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15
 /gnu/store/kqkznj38c8z6jppl620q8fvz7ij9j6dp-libev-4.20
/gnu/store/zvggrli42q119zpqjd8ydxygvfj840bp-libxdg-basedir-1.2.0
@ substituter-started
/gnu/store/kqkznj38c8z6jppl620q8fvz7ij9j6dp-libev-4.20

/gnu/store/04q37mcyxybzbc46j9c6pa3g8553sbgz-guix-0.10.0-0.97c8/libexec/guix/substitute

Found valid signature for
/gnu/store/kqkznj38c8z6jppl620q8fvz7ij9j6dp-libev-4.20
From
https://mirror.hydra.gnu.org/nar/kqkznj38c8z6jppl620q8fvz7ij9j6dp-libev-4.20
Downloading kqkznj…-libev-4.20 (279KiB installed)...
 libev-4.20
 931KiB/s 00:00 | 144KiB transferred
 @ substituter-succeeded
 /gnu/store/kqkznj38c8z6jppl620q8fvz7ij9j6dp-libev-4.20
 @ substituter-started
 /gnu/store/zvggrli42q119zpqjd8ydxygvfj840bp-libxdg-basedir-1.2.0
 
/gnu/store/04q37mcyxybzbc46j9c6pa3g8553sbgz-guix-0.10.0-0.97c8/libexec/guix/substitute

Found valid signature for
/gnu/store/zvggrli42q119zpqjd8ydxygvfj840bp-libxdg-basedir-1.2.0
From
https://mirror.hydra.gnu.org/nar/zvggrli42q119zpqjd8ydxygvfj840bp-libxdg-basedir-1.2.0
Downloading zvggrl…-libxdg-basedir-1.2.0 (42KiB installed)...
 libxdg-basedir-1.2.0
 4.1MiB/s 00:00 | 13KiB transferred
 @ substituter-succeeded
 /gnu/store/zvggrli42q119zpqjd8ydxygvfj840bp-libxdg-basedir-1.2.0
 @ substituter-started
 /gnu/store/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15
 
/gnu/store/04q37mcyxybzbc46j9c6pa3g8553sbgz-guix-0.10.0-0.97c8/libexec/guix/substitute

Found valid signature for
/gnu/store/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15
From
https://mirror.hydra.gnu.org/nar/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15
Downloading dplmx2…-awesome-3.4.15 (1.4MiB installed)...
 awesome-3.4.15
 264KiB/s 00:03 | 818KiB transferred
 @ substituter-succeeded
 /gnu/store/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15
 @ build-started
 /gnu/store/3g3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv -
 x86_64-linux
 /var/log/guix/drvs/3g//3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv.bz2
 grafting '/gnu/store/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15'
 -> '/gnu/store/hvnlf55aj3rkgkllp567k7jr8q04fyqb-awesome-3.4.15'...
 @ build-started
 /gnu/store/3g3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv -
 x86_64-linux
 /var/log/guix/drvs/3g//3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv.bz2
 grafting '/gnu/store/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15'
 -> '/gnu/store/hvnlf55aj3rkgkllp567k7jr8q04fyqb-awesome-3.4.15'...
 @ build-succeeded
 /gnu/store/3g3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv -
 /gnu/store/hvnlf55aj3rkgkllp567k7jr8q04fyqb-awesome-3.4.15
 ng0@shadowwalker ~$ guix build --check --rounds=2 awesome
 @ build-started
 /gnu/store/3g3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv -
 x86_64-linux
 /var/log/guix/drvs/3g//3l3i3j6d1zn9m0xjz8dgxnfphchjgp-awesome-3.4.15.drv.bz2
 grafting '/gnu/store/dplmx20hzggiin25pqrkx9z9irz9l7cn-awesome-3.4.15'
 -> '/gnu/store/hvnlf55aj3rkgkllp567k7jr8q04fyqb-awesome-3.4.15'...
 /gnu/store/hvnlf55aj3rkgkllp567k7jr8q04fyqb-awesome-3.4.15
 

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [PATCH] gnu: dmidecode: Update to 3.0.

[Kei Kebreau]

ng0  writes:

> Kei Kebreau  writes:
>
>> ng0  writes:
>>
>>> Hi,
>>>
>>> Kei Kebreau  writes:
>>>
 A package for those who like to roam around the lower levels of their
 machines. As soon as this package is verified to build successfully and
 reproducibly on another user's machine, I can push it to the repos.
>
> snip
>
>> Wow! I must have misspelled dmidecode when I searched for it! Silly me. :-P
>>
>> I've attached a new patch. I don't know whether updating a version
>> number necessitates a copyright assignment, so I omitted it.
>
> Thanks. No problem. I can not review it (or at least not right now), but
> version bumps get copyright assignments too.
> I think I could review it on tuesday or tomorrow night. Could you send
> it as .patch in addition to inlined? I have not figured out how to
> extract inlined patches in notmuch yet.
>

Sure thing:

From 06770d6275aacdb0c5763bcc8aff4d27fe6ae2f5 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sun, 31 Jul 2016 17:15:25 -0400
Subject: [PATCH] gnu: dmidecode: Update to 3.0.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/packages/admin.scm (dmidecode): Update to 3.0.
[arguments]: Use ’modify-phases’ instead of ‘alist-delete’.
---
 gnu/packages/admin.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 195959e..a80ee9d 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -981,18 +981,18 @@ network, which causes enabled computers to power on.")
 (define-public dmidecode
   (package
 (name "dmidecode")
-(version "2.12")
+(version "3.0")
 (source (origin
   (method url-fetch)
   (uri (string-append
 "mirror://savannah/dmidecode/dmidecode-"
-version ".tar.bz2"))
+version ".tar.xz"))
   (sha256
(base32
-"122hgaw8mpqdfra159lfl6pyk3837giqx6vq42j64fjnbl2z6gwi"
+"0iby0xfk5x3cdr0x0gxj5888jjyjhafvaq0l79civ73jjfqmphvy"
 (build-system gnu-build-system)
 (arguments
- '(#:phases (alist-delete 'configure %standard-phases)
+ '(#:phases (modify-phases %standard-phases (delete 'configure))
#:tests? #f; no 'check' target
#:make-flags (list (string-append "prefix="
  (assoc-ref %outputs "out")
-- 
2.9.2

From 06770d6275aacdb0c5763bcc8aff4d27fe6ae2f5 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sun, 31 Jul 2016 17:15:25 -0400
Subject: [PATCH] gnu: dmidecode: Update to 3.0.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/packages/admin.scm (dmidecode): Update to 3.0.
[arguments]: Use ’modify-phases’ instead of ‘alist-delete’.
---
 gnu/packages/admin.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 195959e..a80ee9d 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -981,18 +981,18 @@ network, which causes enabled computers to power on.")
 (define-public dmidecode
   (package
 (name "dmidecode")
-(version "2.12")
+(version "3.0")
 (source (origin
   (method url-fetch)
   (uri (string-append
 "mirror://savannah/dmidecode/dmidecode-"
-version ".tar.bz2"))
+version ".tar.xz"))
   (sha256
(base32
-"122hgaw8mpqdfra159lfl6pyk3837giqx6vq42j64fjnbl2z6gwi"
+"0iby0xfk5x3cdr0x0gxj5888jjyjhafvaq0l79civ73jjfqmphvy"
 (build-system gnu-build-system)
 (arguments
- '(#:phases (alist-delete 'configure %standard-phases)
+ '(#:phases (modify-phases %standard-phases (delete 'configure))
#:tests? #f; no 'check' target
#:make-flags (list (string-append "prefix="
  (assoc-ref %outputs "out")
-- 
2.9.2



signature.asc
Description: PGP signature

Re: [PATCH ?] gnu: Add dash.

[Tobias Geerinckx-Rice]

Hullo all,

On Fri, Jul 29, 2016 at 02:44:27PM +, ng0 wrote:
> Ludovic Courtès  writes:
>> I’d tend to remove “significantly” , but otherwise LGTM, thanks!
> I second this. Significantly faster is subjectiv as long as we do not
> provide some side by side benchmark results etc.

Let's not give Phoronix any ideas.

While I am convinced that ‘significantly faster’ is an objective fact, I
agree that such claims smell so subjective that they don't belong in
Guix. I just copied that bit from upstream, to be honest. Dropped.

On 29/07/2016 17:51, Leo Famulari wrote:
> I'm not suggesting that we run the benchmarks or put 'significantly'
> back in the description, but I would like to include some context.
> 
> This is the shell that Debian uses as the default non-interactive
> "system" shell. They replaced Bash with dash in that context in order to
> reduce the time spent on shell initialization for things like the boot
> sequence.

Indeed; thanks for adding that. dash is horrible for interactive use,
but fast at running shell[1] scripts. If anyone thinks that might be
relevant in the description, let me know.

Otherwise, I'll push it soon with the suggested changes.

Kind regards,

T G-R

[1]:  It's also a trivial way to catch 98% of bash-specific code.

Re: [PATCH] gnu: openttd: Update to 1.6.1.

[Andreas Enge]

On Sun, Jul 31, 2016 at 08:41:01PM +0200, Albin wrote:
> Here is an update to the latest version of OpenTTD. I've also added the
> following sentence to the package description:

Pushed as eb3bd6762a2972773489551b0e247d0f5549a819 to master, with a slightly
shortened commit message: There is no need to repeat file or variable names.

Thanks!

Andreas

Re: [PATCH] gnu: dmidecode: Update to 3.0. (was: Re: [PATCH] gnu: Add dmidecode.)

[ng0]

Kei Kebreau  writes:

> ng0  writes:
>
>> Hi,
>>
>> Kei Kebreau  writes:
>>
>>> A package for those who like to roam around the lower levels of their
>>> machines. As soon as this package is verified to build successfully and
>>> reproducibly on another user's machine, I can push it to the repos.

snip

> Wow! I must have misspelled dmidecode when I searched for it! Silly me. :-P
>
> I've attached a new patch. I don't know whether updating a version
> number necessitates a copyright assignment, so I omitted it.

Thanks. No problem. I can not review it (or at least not right now), but
version bumps get copyright assignments too.
I think I could review it on tuesday or tomorrow night. Could you send
it as .patch in addition to inlined? I have not figured out how to
extract inlined patches in notmuch yet.

> From 0ddaeaeefbcc39143f3538448a37de974e38d0b5 Mon Sep 17 00:00:00 2001
> From: Kei Kebreau 
> Date: Sun, 31 Jul 2016 15:55:08 -0400
> Subject: [PATCH] gnu: dmidecode: Update to 3.0.
>
> * gnu/packages/admin.scm (dmidecode): Update to 3.0.
> ---
>  gnu/packages/admin.scm | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
> index 195959e..a80ee9d 100644
> --- a/gnu/packages/admin.scm
> +++ b/gnu/packages/admin.scm
> @@ -981,18 +981,18 @@ network, which causes enabled computers to power on.")
>  (define-public dmidecode
>(package
>  (name "dmidecode")
> -(version "2.12")
> +(version "3.0")
>  (source (origin
>(method url-fetch)
>(uri (string-append
>  "mirror://savannah/dmidecode/dmidecode-"
> -version ".tar.bz2"))
> +version ".tar.xz"))
>(sha256
> (base32
> -"122hgaw8mpqdfra159lfl6pyk3837giqx6vq42j64fjnbl2z6gwi"
> +"0iby0xfk5x3cdr0x0gxj5888jjyjhafvaq0l79civ73jjfqmphvy"
>  (build-system gnu-build-system)
>  (arguments
> - '(#:phases (alist-delete 'configure %standard-phases)
> + '(#:phases (modify-phases %standard-phases (delete 'configure))
> #:tests? #f; no 'check' target
> #:make-flags (list (string-append "prefix="
>   (assoc-ref %outputs "out")
> -- 
> 2.9.2
>

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [PATCH] gnu: dmidecode: Update to 3.0.

[Ludovic Courtès]

Hi,

Kei Kebreau  skribis:

> I've attached a new patch. I don't know whether updating a version
> number necessitates a copyright assignment, so I omitted it.

You mean a copyright line (no copyright assignment here :-)).  I’d argue
it doesn’t require one.

> From 0ddaeaeefbcc39143f3538448a37de974e38d0b5 Mon Sep 17 00:00:00 2001
> From: Kei Kebreau 
> Date: Sun, 31 Jul 2016 15:55:08 -0400
> Subject: [PATCH] gnu: dmidecode: Update to 3.0.
>
> * gnu/packages/admin.scm (dmidecode): Update to 3.0.

Please add:

  [argument]: Use ’modify-phases’ instead of ‘alist-delete’.

Otherwise LGTM, thank you!

Ludo’.

Re: 'guix environment' as a build tool.

[Ludovic Courtès]

Hi!

"Thompson, David"  skribis:

> On Sun, Jul 31, 2016 at 9:55 AM, Ludovic Courtès  wrote:
>> Conversely, useful metadata is missing: for instance, I’d like to add
>> something that would allow me to specify the equivalent of ‘--network
>> --expose=$HOME/.gdbinit’ in development environments I use.
>>
>> Perhaps the solution is to introduce a new way to declare development
>> environments?  It would be similar to ‘package’, but without ‘synopsis’,
>> ‘description’, and a couple other things; it could have additional
>> fields to describe container setups and such likes; it would compile
>> down to a bag, just like packages.
>>
>> What do you think?
>
> Hmm, that sounds like a good idea.  Maybe I'll try to write a
> prototype sometime.  The downside of this method is that one could no
> longer use the same expression as input to 'guix build -f' or 'guix
> package -f'.

Good point.  That would be a drawback of the approach, but probably we
can support both styles.

Thanks,
Ludo’.

Re: [PATCH] gnu: dmidecode: Update to 3.0. (was: Re: [PATCH] gnu: Add dmidecode.)

[Kei Kebreau]

ng0  writes:

> Hi,
>
> Kei Kebreau  writes:
>
>> A package for those who like to roam around the lower levels of their
>> machines. As soon as this package is verified to build successfully and
>> reproducibly on another user's machine, I can push it to the repos.
>>
>> From 37c3cc1021671d93dca2c34c4d3b392173b84ef1 Mon Sep 17 00:00:00 2001
>> From: Kei Kebreau 
>> Date: Sun, 31 Jul 2016 13:59:59 -0400
>> Subject: [PATCH] gnu: Add dmidecode.
>>
>> * gnu/packages/linux.scm (dmidecode): New variable.
>> ---
>
> I don't understand.. is an upgrade not enough?
>
> ng0@shadowwalker ~$ guix package -s dmidecode
> name: dmidecode
> version: 2.12
> outputs: out
> systems: x86_64-linux i686-linux armhf-linux mips64el-linux
> dependencies:
> location: gnu/packages/admin.scm:982:2
> homepage: http://www.nongnu.org/dmidecode/
> license: GPL 2+
> synopsis: Read hardware information from the BIOS
> description: Dmidecode reports information about your system's hardware
> as
> + described in your system BIOS according to the SMBIOS/DMI standard.
> This
> + typically includes system manufacturer, model name, serial number,
> BIOS
> + version, asset tag as well as a lot of other details of varying level
> of
> + interest and reliability depending on the manufacturer.  This will
> often
> + include usage status for the CPU sockets, expansion slots (e.g.  AGP,
> PCI,
> + ISA) and memory module slots, and the list of I/O ports (e.g.  serial,
> + parallel, USB).

Wow! I must have misspelled dmidecode when I searched for it! Silly me. :-P

I've attached a new patch. I don't know whether updating a version
number necessitates a copyright assignment, so I omitted it.

From 0ddaeaeefbcc39143f3538448a37de974e38d0b5 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sun, 31 Jul 2016 15:55:08 -0400
Subject: [PATCH] gnu: dmidecode: Update to 3.0.

* gnu/packages/admin.scm (dmidecode): Update to 3.0.
---
 gnu/packages/admin.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 195959e..a80ee9d 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -981,18 +981,18 @@ network, which causes enabled computers to power on.")
 (define-public dmidecode
   (package
 (name "dmidecode")
-(version "2.12")
+(version "3.0")
 (source (origin
   (method url-fetch)
   (uri (string-append
 "mirror://savannah/dmidecode/dmidecode-"
-version ".tar.bz2"))
+version ".tar.xz"))
   (sha256
(base32
-"122hgaw8mpqdfra159lfl6pyk3837giqx6vq42j64fjnbl2z6gwi"
+"0iby0xfk5x3cdr0x0gxj5888jjyjhafvaq0l79civ73jjfqmphvy"
 (build-system gnu-build-system)
 (arguments
- '(#:phases (alist-delete 'configure %standard-phases)
+ '(#:phases (modify-phases %standard-phases (delete 'configure))
#:tests? #f; no 'check' target
#:make-flags (list (string-append "prefix="
  (assoc-ref %outputs "out")
-- 
2.9.2



signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add dmidecode.

[ng0]

Hi,

Kei Kebreau  writes:

> A package for those who like to roam around the lower levels of their
> machines. As soon as this package is verified to build successfully and
> reproducibly on another user's machine, I can push it to the repos.
>
> From 37c3cc1021671d93dca2c34c4d3b392173b84ef1 Mon Sep 17 00:00:00 2001
> From: Kei Kebreau 
> Date: Sun, 31 Jul 2016 13:59:59 -0400
> Subject: [PATCH] gnu: Add dmidecode.
>
> * gnu/packages/linux.scm (dmidecode): New variable.
> ---

I don't understand.. is an upgrade not enough?

ng0@shadowwalker ~$ guix package -s dmidecode
name: dmidecode
version: 2.12
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies:
location: gnu/packages/admin.scm:982:2
homepage: http://www.nongnu.org/dmidecode/
license: GPL 2+
synopsis: Read hardware information from the BIOS
description: Dmidecode reports information about your system's hardware
as
+ described in your system BIOS according to the SMBIOS/DMI standard.
This
+ typically includes system manufacturer, model name, serial number,
BIOS
+ version, asset tag as well as a lot of other details of varying level
of
+ interest and reliability depending on the manufacturer.  This will
often
+ include usage status for the CPU sockets, expansion slots (e.g.  AGP,
PCI,
+ ISA) and memory module slots, and the list of I/O ports (e.g.  serial,
+ parallel, USB).




-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

[PATCH] gnu: openttd: Update to 1.6.1.

[Albin]

Hi!

Here is an update to the latest version of OpenTTD. I've also added the
following sentence to the package description:

"This package only includes the game engine.  When you start it you will
be prompted to download a graphics set."

All the best,

Albin
From ee8cc850a3f60b1a7d94545b2dc333c8dd113579 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Albin=20S=C3=B6derqvist?= 
Date: Sun, 31 Jul 2016 20:29:20 +0200
Subject: [PATCH] gnu: openttd: Update to 1.6.1.

* gnu/packages/games.scm (openttd): Update to 1.6.1.
* gnu/packages/games.scm (openttd): Improve package description.
---
 gnu/packages/games.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 919b018..9245742 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -1872,14 +1872,14 @@ and a game metadata scraper.")
 (define openttd-engine
   (package
 (name "openttd-engine")
-(version "1.6.0")
+(version "1.6.1")
 (source
  (origin (method url-fetch)
  (uri (string-append "http://binaries.openttd.org/releases/;
  version "/openttd-" version "-source.tar.xz"))
  (sha256
   (base32
-   "1cjf9gz7d0sn7893wv9d00q724sxv3d81bgb0c5f5ppz2ssyc4jc"))
+   "1ak32fj5xkk2fvmm3g8i7wzmk4bh2ijsp8fzvvw5wj6365p9j24v"))
  (modules '((guix build utils)))
  (snippet
   ;; The DOS port contains proprietary software.
@@ -1919,7 +1919,8 @@ and a game metadata scraper.")
 passengers by land, water and air.  It is a re-implementation of Transport
 Tycoon Deluxe with many enhancements including multiplayer mode,
 internationalization support, conditional orders and the ability to clone,
-autoreplace and autoupdate vehicles.")
+autoreplace and autoupdate vehicles.  This package only includes the game engine.  When you start
+it you will be prompted to download a graphics set.")
 (home-page "http://openttd.org/;)
 ;; This package is GPLv2, except for a few files located in
 ;; "src/3rdparty/" which are under the 3-clause BSD, LGPLv2.1+ and Zlib
-- 
2.6.3



signature.asc
Description: OpenPGP digital signature

[PATCH] gnu: Add dmidecode.

[Kei Kebreau]

A package for those who like to roam around the lower levels of their
machines. As soon as this package is verified to build successfully and
reproducibly on another user's machine, I can push it to the repos.

From 37c3cc1021671d93dca2c34c4d3b392173b84ef1 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sun, 31 Jul 2016 13:59:59 -0400
Subject: [PATCH] gnu: Add dmidecode.

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

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index fad5a63..dc9e649 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -14,6 +14,7 @@
 ;;; Copyright © 2016 Nicolas Goaziou 
 ;;; Copyright © 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 David Craven 
+;;; Copyright © 2016 Kei Kebreau 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -2822,3 +2823,37 @@ as used on certified hardware security devices.")
(license:non-copyleft "file://nist/packtest.c")
license:public-domain; nist/dfft.c
license:gpl3+; everything else
+
+(define-public dmidecode
+  (package
+(name "dmidecode")
+(version "3.0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://download.savannah.gnu.org/releases/;
+  name "/" name "-" version ".tar.xz"))
+  (sha256
+   (base32
+"0iby0xfk5x3cdr0x0gxj5888jjyjhafvaq0l79civ73jjfqmphvy"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f ; no check target
+   #:phases (modify-phases %standard-phases
+  (delete 'configure) ; no configure script
+  (add-before 'install 'patch-prefix-directory
+(lambda* (#:key inputs outputs #:allow-other-keys)
+  (let ((out (assoc-ref outputs "out")))
+(substitute* "Makefile"
+  (("prefix  = /usr/local")
+   (string-append "prefix  = " %output)
+(home-page "http://www.nongnu.org/dmidecode/;)
+(synopsis "SMBIOS/DMI table decoder")
+(description
+ "Dmidecode reports information about your system's hardware as described 
in
+your system BIOS according to the SMBIOS/DMI standard.  This information
+typically includes system manufacturer, model name, serial number, BIOS 
version,
+asset tag as well as a lot of other details of varying level of interest and
+reliability depending on the manufacturer.  This will often include usage
+status for the CPU sockets, expansion slots (e.g. AGP, PCI, ISA) and memory
+module slots, and the list of I/O ports (e.g. serial, parallel, USB).")
+(license license:gpl2+)))
-- 
2.9.2



signature.asc
Description: PGP signature

Re: [WIP v0.1 0/8] KDE framework 5, tier 1

[David Craven]

> Unfortunatly I have not time ATM for working on this. Feel free to pick
> up and complete it. (I'd be happy if you'd take over :-)

Thanks for the info =)

Re: Ecl

[Andreas Enge]

On Sun, Jul 31, 2016 at 01:25:10PM -0400, Andy Patterson wrote:
> This patch should address the issue. It's for core-updates. I've tested
> it locally.

Just pushed, thanks a lot!

Andreas

Re: [PATCH 8/8] services: Add spice vdagent service.

[David Craven]

> If spice-vdagend produces a PID file, make sure to use #:pid-file here
> (there are several examples in the tree), which often provides more
> reliable startup notification.

spice-vdagentd doesn't create a pid file itself. [0] [1]

I haven't updated the documentation yet because I'm running into
issues building guix, haven't figured out why yet.

guix environment guix && make

Complains about not finding sqlite3. The pc file is and the libraries
are in the profile, so it might just be guix and nixos getting at it
again. I haven't had time to investigate this further yet.

[0] https://github.com/SPICE/linux-vd_agent/blob/master/data/spice-vdagentd#L43
[1] 
https://github.com/SPICE/linux-vd_agent/blob/master/data/spice-vdagentd.service#L13

Re: [PATCH] gnu: r: Update to 3.3.1.

[myglc2]

Roel Janssen  writes:

>> On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote:
>>> I can assure you that if our users do guix pull and invisibly get a new
>>> R release, their analyses will from time to time break. So we may want a
>>> simple way for them to back down to a previous release. So.. I am
>>> thinking it would make sense to keep previous versions of R in the
>>> recipe. What do others think?

> I think what you're looking for in your hospital research lab is what
> Pjotr describes as a certain check-out of the Guix source tree.

But it is not simple to use. It is to technical an approach to appeal to
the medical researchers I have worked with.

> From a scientific viewpoint you cannot say that the results of your data
> analysis "will work with R version 3.3.0 or higher", but instead you can
> only say "we achieved these results b using R version 3.3.0, with
> extension X at version Y" (assuming these versions can be uniquely
> identified to their source code).

Actually R 'sessionInfo()' collects this at run time.

> The cool thing is, is that you can construct the software environment
> from any particular time, as long as the source tarballs are
> available.
>
> In addition to the `per-user' profiles, you could use `per-pipeline' and
> `per-group' profiles for users to "pin" a specific software environment
> for doing the data analysis.  Users can then set the environment
> variables in their shell to use that shared profile:
>   export PATH=/path/to/profiles/per-pipeline/ngs/guix-profile/bin:$PATH
>   export 
> R_LIBS_SITE=/path/to/profiles/per-pipeline/ngs/guix-profile/site-library
>
> Or by simply following the recommendations by GNU Guix:
>   guix package --search-paths 
> --profile=/path/to/profiles/per-profiles/ngs/guix-profile
>
> I think upgrading is inevitable, so pinpointing to a specific set of
> build recipes (tied to a commit ID) is a good way of maintaining a
> stable software environment.

Guix has marvelous raw tools to do anything. The question is how to make
it simple enough for someone that is basically an R user to take
advantage of them.  The challenge in guix R packaging is to consider R
patterns of use and determine how guix packate R to support them in a
way that is accessible to typical R users.

> Do you think we can keep the latest versions in the upstream repository,
> provided that you have a way of reverting or staying to the "old"
> versions by either copying the 3.3.0 recipe to a local repository, or
> pinpoint to an older Git commit?

Guix in general should have a scheme to decide which "golden oldies"
stay in the repository ;-)

In the meantime, after thinking about it some more I withdraw the
suggestion of multiple R version recipes (please see separate post).

But maybe you should test the existing guix R package recipes against
the new R version, if you have not already done so, before you update
the R recipe ;-)

Re: [PATCH] gnu: r: Update to 3.3.1.

[Roel Janssen]

myglc2 writes:

> Pjotr Prins  writes:
>
>> On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote:
>>> The workaround used by sysops where I work (hospital research lab) is to
>>> give notice of R upgrades and to make previous releases available for
>>> reference by ongoing projects. IMO, we should consider how the guix R
>>> recipe(s) might support a pattern of use like this.
>>> 
>>> I can assure you that if our users do guix pull and invisibly get a new
>>> R release, their analyses will from time to time break. So we may want a
>>> simple way for them to back down to a previous release. So.. I am
>>> thinking it would make sense to keep previous versions of R in the
>>> recipe. What do others think?
>
>> Note, meanwhile, that a new R install does not remove the old packages
>> automatically. One way to work older versions is by using guix
>> profiles effectively. We introduced Unix modules with Guix, so a
>> module would point to a well tested and working profile. Just make
>> sure it does not get GC'd at some point.
>
> This functionality could be adequate in some situations if it can be
> made simple to use. Some questions to answer...
>
> What do you mean by "Unix modules"?

I think Pjotr means environment variables.

> How does one "make sure it does not get GC'd"?

Keep it in a profile linked to the store.  (So once you've installed
a version in a profile, Guix will not GC it as long as you haven't
removed the profile, or the programs in the profiles and its
accompanying generations).

> What happens when a user wants something else (e.g., not R) updated?

He can just to `guix package --upgrade='.

>> Another way to work it is by using a checked out Guix source tree.
>
> This is not simple and is beyond the capability of the medical
> researchers I have met.

I agree.  However, when upgrading packages, they can be careful not to
upgrade a package.  You can do that by `guix package --upgrade
--do-not-upgrade=r'.

This may seem too difficult as well, but let's consider the alternative:
Not upgrading packages upstream.  That's what we can already do
downstream (simply don't run `guix pull').  I like having the latest
versions available in GNU Guix, and when I need an older version, I can
find it in the version control system.

Kind regards,
Roel Janssen

Re: Ecl

[Andy Patterson]

On Sun, 31 Jul 2016 12:00:25 +0200
Andreas Enge  wrote:

> Yet another package which fails on all architectures:
>http://hydra.gnu.org:3000/build/1313690
> If someone is interested in it, please have a look.

This patch should address the issue. It's for core-updates. I've tested
it locally.

Andy>From 3306dfad4dbb2288a6a689596e3a14abac5a093b Mon Sep 17 00:00:00 2001
From: Andy Patterson 
Date: Sun, 31 Jul 2016 13:21:07 -0400
Subject: [PATCH] gnu: ecl: Use "kernel-headers" instead of "linux-headers" to
 designate input.

* gnu/packages/lisp.scm (ecl)[arguments]: Use "kernel-headers" as the
identifier for an input.

This is a follow-up to commit 55de892b435657f82a25c6499174d09b4a680f15.
---
 gnu/packages/lisp.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 5c0df4e..1772780 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -148,7 +148,7 @@ interface to the Tk widget system.")
  `("CPATH" suffix
,(map (lambda (lib)
(input-path lib "/include"))
- `("linux-headers" ,@libraries)))
+ `("kernel-headers" ,@libraries)))
  `("LIBRARY_PATH" suffix ,library-directories)
  `("LD_LIBRARY_PATH" suffix ,library-directories)
  (add-after 'wrap 'check (assoc-ref %standard-phases 'check)
-- 
2.9.2

Re: [PATCH] gnu: r: Update to 3.3.1.

[myglc2]

Pjotr Prins  writes:

> On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote:
>> The workaround used by sysops where I work (hospital research lab) is to
>> give notice of R upgrades and to make previous releases available for
>> reference by ongoing projects. IMO, we should consider how the guix R
>> recipe(s) might support a pattern of use like this.
>> 
>> I can assure you that if our users do guix pull and invisibly get a new
>> R release, their analyses will from time to time break. So we may want a
>> simple way for them to back down to a previous release. So.. I am
>> thinking it would make sense to keep previous versions of R in the
>> recipe. What do others think?

> Note, meanwhile, that a new R install does not remove the old packages
> automatically. One way to work older versions is by using guix
> profiles effectively. We introduced Unix modules with Guix, so a
> module would point to a well tested and working profile. Just make
> sure it does not get GC'd at some point.

This functionality could be adequate in some situations if it can be
made simple to use. Some questions to answer...

What do you mean by "Unix modules"?

How does one "make sure it does not get GC'd"?

What happens when a user wants something else (e.g., not R) updated?

> Another way to work it is by using a checked out Guix source tree.

This is not simple and is beyond the capability of the medical
researchers I have met.

> In the near future I hope we get a version of guix pull which can
> essentially achieve the same (i.e. a checked out version of the tree).
>
>   guix pull HASH-tag

This comes the closet to being a "simple way for them to back down to a
previous release". It has merit independent of R.

Re: [PATCH] gnu: r: Update to 3.3.1.

[myglc2]

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

> myglc2  skribis:
>
>> I can assure you that if our users do guix pull and invisibly get a new
>> R release,
>
> They need to to ‘guix pull’ *and* ‘guix package -u’.
>
>> their analyses will from time to time break. So we may want a simple
>> way for them to back down to a previous release. So.. I am thinking it
>> would make sense to keep previous versions of R in the recipe. What do
>> others think?
>
> I don’t use R myself; keeping a couple of R versions would be fine,
> though R packages would always be built only against the latest R.

I had forgotten that you are also building many packages. Given that, an
update to the R guix recipe may break some packages. So all the packages
should probably be tested as part of an R recipe update. Do/did we do
that?

As regards keeping a couple of R versions, if we don't keep the
associated packages it will have limited usefulness, so I withdraw
the suggestion.

Re: Python-pathlib

[Hartmut Goebel]

Am 31.07.2016 um 11:28 schrieb Andreas Enge:
> So should we drop python-pathlib and keep only python2-pathlib?

+1

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/artikel-zu-debops-im-ix-magazin
Kolumne:
http://www.cissp-gefluester.de/2011-08-horrorszenario-bring-your-own-device

Re: [WIP v0.1 0/8] KDE framework 5, tier 1

[Hartmut Goebel]

Am 31.07.2016 um 18:33 schrieb Hartmut Goebel:
> Please note there are more branches (kf5-tier-2, kde-tier-3, kde-tier-4,
> kf5-porting-aids) where I prepared packages for the other tiers.

I should have added: I used the branches so I could plain stupidity add
all packages first, amending and editing each package until it's fine.
Then rebase the next tier's branch and continue in the same way.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/artikel-zu-debops-im-ix-magazin
Kolumne:
http://www.cissp-gefluester.de/2011-08-horrorszenario-bring-your-own-device

Re: [WIP v0.1 0/8] KDE framework 5, tier 1

[Hartmut Goebel]

Am 30.07.2016 um 11:14 schrieb Andreas Enge:
> I would suggest to order the packages in kde-frameworks.scm according to the
> different "tiers", and to add a comment when a new tier is started, similarly
> to the comments in xorg.scm. There is already one package there that was

That's exactly what I already prepared in the other branches.


-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/artikel-zu-debops-im-ix-magazin
Kolumne:
http://www.cissp-gefluester.de/2011-08-horrorszenario-bring-your-own-device

Re: ‘guix publish’ as a content-addressed file server

[Ludovic Courtès]

Hello,

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

> Until now, if hydra.gnu.org had a source file in its store (the result
> of an ‘origin’), you could get it via substitutes.  However, with
> substitutes disabled, hydra.gnu.org was of no help, even though it did
> have the source file.
>
> Commit ff6638d112d794c9c433731643711932452fd2ff helps address that: it
> augments ‘guix publish’ such that it can be used as a content-addressed
> mirror for source files¹.
>
> If you run ‘guix publish -p ’ on your machine, and if
> hello-2.10.tar.gz is in the store, then this URL:
>
>   
> http://localhost:/file/hello-2.10.tar.gz/sha256/0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
>
> … gives you hello-2.10.tar.gz.

guix-maintenance commit 7f59985566b384e31da7e6f1a36744e9edfba54f adds
nginx proxying for those /file URLs (‘guix publish’ is now running on
hydra.gnu.org, though we only use it for those /file URLs;
mirror.hydra.gnu.org proxies and caches those requests):

--8<---cut here---start->8---
$ wget -q -O - 
https://mirror.hydra.gnu.org/file/hello-2.10.tar.gz/sha256/0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
 | guix hash /dev/stdin
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
--8<---cut here---end--->8---

Guix commit 40f788b9f6184436d9cc36a4dd8e7d101cd2f0ba adds
mirror.hydra.gnu.org as a content-addressable mirror.

Ludo’.

Re: [WIP v0.1 0/8] KDE framework 5, tier 1

[Hartmut Goebel]

Am 30.07.2016 um 00:37 schrieb David Craven:
> Are you still working on these patches?

Unfortunatly I have not time ATM for working on this. Feel free to pick
up and complete it. (I'd be happy if you'd take over :-)

Please note there are more branches (kf5-tier-2, kde-tier-3, kde-tier-4,
kf5-porting-aids) where I prepared packages for the other tiers.

For kapidocs the requirements where not clear. I asked the current
maintainer about the requirements and he answered: "the only
dependencies are python-yaml, jinja2 and doxygen. I updated the readme
file with required/optional dependencies"

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH} Add RAID devices.

[Andreas Enge]

On Sun, Jul 31, 2016 at 12:12:02PM -0400, myglc2 wrote:
> Thanks, I tried that. the 'guix system reconfigure' succeeds and starts
> the raid array (please see system35.scm & system35.log, attached).
> 
> But the reboot hangs at:
> 
> [...] clocksource: Switched to clocksource tsc

No idea. The only difference I saw with my setup is that you have the
#:mapped-devices clause in the initrd; I am just using this:

  ;; Add a kernel module for RAID-10.
  (initrd (lambda (file-systems . rest)
(apply base-initrd file-systems
   #:extra-modules '("raid10")
   rest)))

Andreas

Re: Isnan

[Andreas Enge]

On Sun, Jul 31, 2016 at 04:53:49PM +0200, Andreas Enge wrote:
> And rapicorn:
>http://hydra.gnu.org:3000/build/1345676/nixlog/1/tail-reload

Fixed in commit 42bf34298eec19b37e276e49074113f29c494aed.

Andreas

Re: [PATCH} Add RAID devices.

[myglc2]

Andreas Enge  writes:

> On Sat, Jul 30, 2016 at 07:05:25PM -0400, myglc2 wrote:
>> > I might write a more detailed blog post about this; there is a little
>> > subtlety with the non-automatic determination of dependencies between
>> > devices, so one needs to make sure that the partitions to be assembled
>> > are present before the mdadm command is executed.
>> I rebooted and the array is not assembled ;-(
>
> Strange! But I will also tell you the subtlety ;-)  Here is a trick to use
> (thanks to Ludovic):
> (define md0
>   (mapped-device
> (source (list "/dev/sda2" "/dev/sdb2"))
>   (target "/dev/md0")
>   (type raid-device-mapping)))
> (operating-system
> ...
>   (mapped-devices (list md0))
>   (file-systems (cons (file-system
> (title 'device)
> (device "/dev/md0")
> (dependencies (list md0))
> (mount-point "/")
> (type "ext4"))
>   %base-file-systems))
>
> The "dependencies" field makes sure that the file system is only mounted
> after the array is assembled; I am not sure that this is your problem,
> but you might want to give it a try.
>
> In the long run, this should be reprogrammed: Devices and file systems
> should wait until all their "inputs" are present, or at least wait for
> a reasonable time.

Thanks, I tried that. the 'guix system reconfigure' succeeds and starts
the raid array (please see system35.scm & system35.log, attached).

But the reboot hangs at:

[...] clocksource: Switched to clocksource tsc



system35.log
Description: Binary data


system35.scm
Description: Binary data

Re: Isnan

[Andreas Enge]

On Sun, Jul 31, 2016 at 04:42:35PM +0200, Andreas Enge wrote:
> It finished successfully. The next package with the same problem is synfig,

And rapicorn:
   http://hydra.gnu.org:3000/build/1345676/nixlog/1/tail-reload

Andreas

Re: Isnan

[Andreas Enge]

On Sun, Jul 31, 2016 at 01:06:07PM +0200, Andreas Enge wrote:
> I am just looking at the reports on hydra. Dealii compiles in master, but not
> in core-updates. (I am trying to update to 8.4.1; so far, the build process
> goes beyond where it fails in the current version.)

It finished successfully. The next package with the same problem is synfig,
or probably rather etl that it depends on:
   http://hydra.gnu.org:3000/build/1345394

time.cpp: In member function ‘bool synfig::Time::is_valid() const’:
time.cpp:322:10: error: ‘::isnan’ has not been declared
  return !::isnan(value_);
  ^
time.cpp:322:10: note: suggested alternative:
In file included from 
/gnu/store/q5x10dkfsacby2i7yn6d18sdjbfvs5hj-etl-0.04.19/include/ETL/_misc.h:29:0,
 from 
/gnu/store/q5x10dkfsacby2i7yn6d18sdjbfvs5hj-etl-0.04.19/include/ETL/misc:32,
 from time.cpp:37:
/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/include/c++/cmath:632:5: 
note:   ‘std::isnan’
 isnan(_Tp __x)
 ^

Andreas

Re: 'guix environment' as a build tool.

[Thompson, David]

On Sun, Jul 31, 2016 at 9:55 AM, Ludovic Courtès  wrote:
> Hello!
>
> "Thompson, David"  skribis:
>
>> On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin  wrote:
>>> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
 What about providing a ‘guix.scm’ file that people could pass to ‘guix
 environment -l’ (instead of typing the long command above), and to ‘guix
 package -f’ (info "(guix) Invoking guix package")?
>>>
>>> 'guix environment -l' uses a package definition.  To me this abstraction
>>> doesn't fit well in a development context:
>>
>> It *does* fit well.  This use-case is why I wrote 'guix environment'
>> in the first place.
>
> [...]
>
>>> if the user wants to enter this environment Later it will have to invoke
>>> './guix-env'.
>>
>> This just makes things more inconvenient and limits potential utility.
>
> That sounds harsh.

I'm sorry.

> I don’t have a better answer for Mathieu other than ‘guix environment
> -l’, and I think it does the job well.
>
> But I also think that Mathieu’s concerns must not be dismissed.  For
> instance, it’s true that some of the metadata in ‘package’ forms looks
> irrelevant for the purposes of setting up a build environment—no big
> deal, but still it doesn’t “feel” completely right.

My intention was to define it just like a regular package so that
users can do whatever they want with it: build it, install it, or make
a development environment using it.

> Conversely, useful metadata is missing: for instance, I’d like to add
> something that would allow me to specify the equivalent of ‘--network
> --expose=$HOME/.gdbinit’ in development environments I use.
>
> Perhaps the solution is to introduce a new way to declare development
> environments?  It would be similar to ‘package’, but without ‘synopsis’,
> ‘description’, and a couple other things; it could have additional
> fields to describe container setups and such likes; it would compile
> down to a bag, just like packages.
>
> What do you think?

Hmm, that sounds like a good idea.  Maybe I'll try to write a
prototype sometime.  The downside of this method is that one could no
longer use the same expression as input to 'guix build -f' or 'guix
package -f'.

- Dave

Re: 'guix environment' as a build tool.

[Ludovic Courtès]

Hello!

"Thompson, David"  skribis:

> On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin  wrote:
>> l...@gnu.org (Ludovic Courtès) writes:

[...]

>>> What about providing a ‘guix.scm’ file that people could pass to ‘guix
>>> environment -l’ (instead of typing the long command above), and to ‘guix
>>> package -f’ (info "(guix) Invoking guix package")?
>>
>> 'guix environment -l' uses a package definition.  To me this abstraction
>> doesn't fit well in a development context:
>
> It *does* fit well.  This use-case is why I wrote 'guix environment'
> in the first place.

[...]

>> if the user wants to enter this environment Later it will have to invoke
>> './guix-env'.
>
> This just makes things more inconvenient and limits potential utility.

That sounds harsh.

I don’t have a better answer for Mathieu other than ‘guix environment
-l’, and I think it does the job well.

But I also think that Mathieu’s concerns must not be dismissed.  For
instance, it’s true that some of the metadata in ‘package’ forms looks
irrelevant for the purposes of setting up a build environment—no big
deal, but still it doesn’t “feel” completely right.

Conversely, useful metadata is missing: for instance, I’d like to add
something that would allow me to specify the equivalent of ‘--network
--expose=$HOME/.gdbinit’ in development environments I use.

Perhaps the solution is to introduce a new way to declare development
environments?  It would be similar to ‘package’, but without ‘synopsis’,
‘description’, and a couple other things; it could have additional
fields to describe container setups and such likes; it would compile
down to a bag, just like packages.

What do you think?

Thanks,
Ludo’.

[patch] python-numpy, python-matplotlib and openblas update, python-cycler added

[Federico Beffa]

Pjotr Prins  writes:

> Attached bumping of python-numpy, openblas and python-matplotlib. New
> package python-cycler.
>
[...]
> - matplotlib and ipython now have a circular dependency - so I removed
>   one and had to disable document generation for matplotlib

We value documentation and welcome efforts to provide/keep it.  An often
working workaround for circular dependencies is to use bootstrap
packages.  One example is the circular dependency between python-numpy
and python-matplotlib.  The former need the latter to build its
documentation, so we have an (unexported) python-numpy-bootstrap to work
around that.

Regards,
Fede

Re: [PATCH] gnunet-svn, gnunet-gtk-svn

[ng0]

ng0  writes:

> This is functional, but it suffers the same bug as the gnunet-0.10.1
> package. I will write a gnunet-service for guix which will fix all
> versions.
> The expected behavior for installing gnunet is: create gnunet user with
> gnunet group, create gnunet-dns group, build, install, configure through
> gnunet-setup -c /path/to/gnunet.conf or setup without graphical tools,
> add regular user to gnunet group, run gnunet stuff with regular user.
>
> You will experience the same stability with this svn as with 0.10.1 but
> it will have the same broken behavior until I have fixed it.
>
> +  (arguments
> +   '(#:configure-flags
> + (list (string-append "--with-nssdir=" %output "/lib"))
> + #:parallel-tests? #f ; parallel building is not functional
> + #:tests? #f ; FAIL: test_testbed_logger_api

Comment in the previous patch I received:

> > Okay, is it easy to disable just the failing test? Also, can you
 > > include a link to the upstream bug report in this comment?

This was another failing test, someone before me reported it and
therefore I have no bugreport to point to. I consider it superfluous
work to fix 0.10.1 (the (define-public gnunet)) now that work towards
0.10.2 release happens. Tests might or might not change, so the svn
version is more logical to fix and report bugs on.

The failing more current test will be reported as soon as I have time
for it.


-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [GSoC] Continuous integration tool à la Hydra.

[Mathieu Lirzin]

Hi,

Florian Paul Schmidt  writes:

> On 07/29/2016 09:26 PM, Mathieu Lirzin wrote:
>>> To get pkg-config, see .
>>> See `config.log' for more details
>> 
>> I have tested successfully with the following command on a foreign
>> system:
>> 
>>   guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite 
>> guile-sqlite3
>> 
>> Tell me if it works for you.
>
> Yes, that makes configure run fine. Thanks

Cool. :)

> This is what I get when I run it:
>
> fps@guix ~/cuirass [env]$ ./pre-inst-env cuirass
> --specifications=tests/hello-singleton.scm --database=test.db
> Cloning into 'guix'...
> remote: Counting objects: 101761, done.
> remote: Compressing objects: 100% (28866/28866), done.
> remote: Total 101761 (delta 74214), reused 99101 (delta 72173)
> Receiving objects: 100% (101761/101761), 35.86 MiB | 6.27 MiB/s, done.
> Resolving deltas: 100% (74214/74214), done.
> Checking connectivity... done.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> + exec autoreconf -vfi
> ./bootstrap: line 5: exec: autoreconf: not found
> In execvp of ./configure: No such file or directory
> In execvp of make: No such file or directory
> ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/derivations.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/derivations.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/store.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/store.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/utils.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/utils.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/combinators.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/combinators.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/build/utils.scm
>
> [ more here ]
>
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/unrtf.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/unrtf.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/uucp.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/uucp.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/vtk.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/vtk.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/wdiff.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/wdiff.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/wine.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/wine.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/xfce.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/xfce.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/xnee.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/xnee.go
> ;;; note: source file
> /home/fps/.cache/cuirass/guix/./gnu/packages/yubico.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/yubico.go
> ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/zsh.scm
> ;;;   newer than compiled
> /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/zsh.go
> evaluate 'hello-2.10.x86_64-linux': 32.563 seconds
> building /gnu/store/cw502hifb3q32h2x0gl1afgzmbx9295y-hello-2.10.drv...
> /gnu/store/zby49aqfbd9w9br4l52mvb3y6f9vfv22-hello-2.10
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> ^C
> fps@guix ~/cuirass [env]$
>
> And then:
>
> fps@guix ~/cuirass [env]$  ./pre-inst-env cuirass --database=test.db
> HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
> HEAD is now at 2fa66f4 gnu: mutt: 

Re: [patch] python-numpy, python-matplotlib and openblas update, python-cycler added

[Andreas Enge]

Hello,

On Sun, Jul 31, 2016 at 01:40:11PM +0200, Pjotr Prins wrote:
> PS I thought using texlive-minimal was a good idea. Ignore those if
> you think it is not supposed to be. It may be the reason the PDFs
> disappeared.

well, if the documentation does not build, then it might be a better idea
to even drop texlive altogether... Fixes to texlive-minimal (that is,
indications on what we delete from texlive-texmf while we should not)
are welcome.

Andreas

[patch] python-numpy, python-matplotlib and openblas update, python-cycler added

[Pjotr Prins]

Hi Ricardo,

I ran into the eigen issue of numpy+openblas.

See https://github.com/xianyi/OpenBLAS/issues/703

The good news is that openblas now appears to have fixed eigen
support. It was broken on numpy and the upgrades fixed the segfaults.

Attached bumping of python-numpy, openblas and python-matplotlib. New
package python-cycler.

- numpy now needs setuptools
- matplotlib requires new packagen python-cycler
- matplotlib sources are now on github
- matplotlib and ipython now have a circular dependency - so I removed
  one and had to disable document generation for matplotlib

We may have success getting R to work agains OpenBLAS.

Pj.

PS I thought using texlive-minimal was a good idea. Ignore those if
you think it is not supposed to be. It may be the reason the PDFs
disappeared.

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index b5518b0..063a6bf 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -3016,7 +3016,7 @@ writing C extensions for Python as easy as Python itself.")
 (define python-numpy-bootstrap
   (package
 (name "python-numpy-bootstrap")
-(version "1.10.4")
+(version "1.11.1")
 (source
  (origin
(method url-fetch)
@@ -3024,11 +3024,12 @@ writing C extensions for Python as easy as Python itself.")
"/numpy-" version ".tar.gz"))
(sha256
 (base32
- "1bjjhvncraka5s6i4lg644jrxij6bvycxy7an20gcz3a0m11iygp"
+ "1kbpsnqfabpbczh3ly2d4jrwq2d1gqlshlpk5dm8bk3r77284h6w"
 (build-system python-build-system)
 (inputs
  `(("python-nose" ,python-nose)
("openblas" ,openblas)
+   ("python-setuptools" ,python-setuptools)
("lapack" ,lapack)))
 (native-inputs
  `(("gfortran" ,gfortran)))
@@ -3130,7 +3131,7 @@ association studies (GWAS) on extremely large data sets.")
,@(package-inputs python-numpy-bootstrap)))
 (native-inputs
  `(("pkg-config" ,pkg-config)
-   ("texlive" ,texlive)
+   ("texlive-minimal" ,texlive-minimal)
("texinfo" ,texinfo)
("perl" ,perl)
,@(package-native-inputs python-numpy-bootstrap)))
@@ -3159,10 +3160,10 @@ association studies (GWAS) on extremely large data sets.")
 ;; (mkdir-p info)
 ;; (copy-file "build/texinfo/numpy.info"
 ;;(string-append info "/numpy.info"))
-(for-each (lambda (file)
-(copy-file (string-append "build/latex" file)
-   (string-append doc file)))
-  '("/numpy-ref.pdf" "/numpy-user.pdf"))
+; (for-each (lambda (file)
+; (copy-file (string-append "build/latex" file)
+;(string-append doc file)))
+;   '("/numpy-ref.pdf" "/numpy-user.pdf"))
 (with-directory-excursion "build/html"
   (for-each (lambda (file)
   (let* ((dir (dirname file))
@@ -3298,24 +3299,50 @@ transcendental functions).")
  ,@(alist-delete "python-numpy"
  (package-propagated-inputs numexpr)))
 
+(define-public python-cycler
+  (package
+(name "python-cycler")
+(version "0.10.0")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append
+   "https://pypi.python.org/packages/c2/4b/137dea450d6e1e3d474e1d873cd1d4f7d3beed7e0dc973b06e8e10d32488/cycler-;
+   version
+   ".tar.gz"))
+(sha256
+  (base32
+"1n69n23fak1gjxlrbhqisi2b9pv3ckrfj98llx3p53953082syyd"
+(build-system python-build-system)
+(inputs
+  `(("python-setuptools" ,python-setuptools)
+("python-six" ,python-six)))
+(home-page "http://github.com/matplotlib/cycler;)
+(synopsis "Composable style cycles")
+(description "Composable style cycles")
+(license bsd-3)))
+
 (define-public python-matplotlib
   (package
 (name "python-matplotlib")
-(version "1.4.3")
+(version "1.5.2")
 (source
  (origin
(method url-fetch)
-   (uri (string-append "mirror://sourceforge/matplotlib/matplotlib"
-   "/matplotlib-" version
-   "/matplotlib-" version ".tar.gz"))
+   (uri (string-append
+  "https://github.com/matplotlib/matplotlib/archive/v;
+ version ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
(sha256
-(base32
- "1dn05cvd0g984lzhh72wa0z93psgwshbbg93fkab6slx5m3l95av"))
-   (patches (search-patches "matplotlib-setupext-tk.patch"
+(base32 
+ "1bnr81p13l2z5kk0isngjhw458ia8jd5mg3f3qz45457rpfcad63"))
+   ; (patches (search-patches "matplotlib-setupext-tk.patch"))
+   ))
 (build-system python-build-system)
 

Re: [PATCH v5 01/17] gnu: Add perl-db-file.

[Danny Milosavljevic]

On Thu, 28 Jul 2016 23:38:17 +0200
Danny Milosavljevic  wrote:

> gnu: Add perl-db-file.
> 
> * gnu/packages/databases.scm (perl-db-file): New variable.
> ---
>  gnu/packages/databases.scm | 32 
>  1 file changed, 32 insertions(+)

This part has already been pushed (by Andreas Enge). The other parts of the 
patch series are still pending.

Re: Call for screencasts!

[Ludovic Courtès]

Hello!

With help from Mark, the video is now on-line:

  https://www.gnu.org/software/guix/

Of course there’s room for improvement, so if anyone would like to
prettify the video, add more demos, or anything, this is welcome!

Ludo’.

Re: PATCH [0/22]: Add roary.

[Ludovic Courtès]

Hello,

Ben Woodcroft  skribis:

> This patchset adds roary, a pipeline which at times is used for tracking
> outbreaks of pathogenic bacteria in e.g. foodstuffs or hospitals, by comparing
> whole genome sequences.

I looked briefly at this series and I guess you can take into account
Leo’s comments and the push.

> perl-log-log4perl was already discussed previously and I am happy to
> defer to that patch.  I only include mine here so the packages build.
> https://lists.gnu.org/archive/html/guix-devel/2016-07/msg00624.html

Alex, have you pushed it yet?

Thank you Ben for this heroic packaging effort!  :-)

Ludo’.

Re: Shepherd fails on core-updates

[Ludovic Courtès]

Andreas Enge  skribis:

> Something embarrassing:
> shepherd does not build on arm in core-updates:
>http://hydra.gnu.org:3000/build/1246005

This is a non-deterministic test failure:

  http://bugs.gnu.org/23811

Ludo’.

Re: 'guix environment' as a build tool.

[Ludovic Courtès]

Hello,

Mathieu Lirzin  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mathieu Lirzin  skribis:
>>
>>> I have tested successfully with the following command on a foreign
>>> system:
>>>
>>>   guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite 
>>> guile-sqlite3
>>>
>>> Tell me if it works for you.
>>>
 How about including a guix package definition then we can easily build
 it assuming "we" know how to do out-of-guix-tree package building :)
>>>
>>> It would indeed be nice to provide an easy way for Guix users to install
>>> Cuirass.  IMHO package definitions meant as a development build tool is
>>> confusing and should be avoided.  Nonetheless, I think it is useful to
>>> document the previous 'guix environment ...' command in the README.
>>
>> What about providing a ‘guix.scm’ file that people could pass to ‘guix
>> environment -l’ (instead of typing the long command above), and to ‘guix
>> package -f’ (info "(guix) Invoking guix package")?
>
> 'guix environment -l' uses a package definition.  To me this abstraction
> doesn't fit well in a development context:
>
>  - the origin hash doesn't make sense.

Not a problem with ‘local-file’, as David wrote.

>  - packages already included in Guix have redundant description and synopsis.

Yeah, though for such packages, a guix.scm is typically less useful
since most of the time ‘guix environment PACKAGE’ is enough.

>  - package definitions rely on Guix internals.

I sympathize both with this and with what David wrote here.

I can sympathize with the idea that conceptually a package definition is
not quite the same thing as a development environment definition, in
practice ‘guix environment -l’ remains much better than the long command
line above.  :-)

> An idea that I like better and is less invasive, would be to complement
> bootstrap scripts with:
>
>   ./bootstrap --with-guix
>
> This command would:
>
> - generate a guix-env script that wraps 'guix environment ...' if it
>   doesn't exist.
> - Invoke ./guix-env
> - Invoke autoreconf -vfi
>
> if the user wants to enter this environment Later it will have to invoke
> './guix-env'.

I’m not convinced by generated scripts.

Now, we’re at a stage where everyone is welcome to explore their own
way.  Some may prefer a ‘guix.scm’ file, while others would prefer a
script that runs ‘guix environment --ad-hoc’.  With more experience,
maybe we can come up with a solution that better caters to everyone’s
needs.

Thanks,
Ludo’.

Re: Isnan

[Andreas Enge]

On Sun, Jul 31, 2016 at 12:44:27PM +0200, Danny Milosavljevic wrote:
> > Apparently the "std::" is missing in front of "isnan"; should this not be 
> > implicit?
> No. Many people in the C++ community frowns upon even doing "using namespace 
> std" at all, never mind implicitly.
> http://stackoverflow.com/questions/1265039/using-std-namespace
> If you include math.h , isnan is called ::isnan .
> If you include cmath , isnan is called std::isnan .

Thanks for the info!

> Also, std::isnan was added with C++11, so it's a new feature. Are you 
> compiling with a C++11 compiler? What are the compiler flags used?

I am just looking at the reports on hydra. Dealii compiles in master, but not
in core-updates. (I am trying to update to 8.4.1; so far, the build process
goes beyond where it fails in the current version.)

Andreas

Re: Code formatting

[Ludovic Courtès]

Danny Milosavljevic  skribis:

>> Bonus to whoever posts indentation rules for their favorite editor!  :-)
>
> Is there a standalone program that reformats Scheme code to what we want it 
> to be? 

There’s Emacs, which can be invoked for batch processing.  I’m not sure
what the right incantation is.

Though to me, it sounds more productive to have $EDITOR do the right
thing.

Ludo’.

Re: WIP: neomutt. segfaulting outside of gdb, functional inside.

[Danny Milosavljevic]

On Fri, 29 Jul 2016 14:56:37 +
ng0  wrote:

> Tomáš Čech  writes:
> 
> > On Fri, Jun 24, 2016 at 04:04:43PM +, ng0 wrote:  
> >>In gnu/packages/mail.scm I created this package.
> >>It builds succesfully, but when I run it, it segfaults.
> >>Running it in gdb however makes it succeed and not
> >>segfault. How do I debug such a software?  
> >
> > Let it generate coredump and open that in GDB.
> >
> > S_W  
> 
> Thanks, I'll look into how to do this and see if I can get further
> results with this.

$ ulimit -c unlimited
$ neomutt # in the same shell!
$ gdb `which neomutt` core*

[PATCH] gnu: Add libgnomekbd.

[ng0]

The author(?) in 2012 wrote:
"Libgnomekbd is a dead man walking – the only useful thing is the
keyboard drawing widget, that should be incorporated into
gnome-control-center in 3.8."

This library has been tested in my GNOME system by clicking the tastatur
layout in the right corner, open drop down menu, click "Show Keyboard
Layout". Previously: "can't find libgnomekbd" (or smth like that), now
it displays keyboard layout drawings.

>From 177706fe15b53a9b8ea3c053b878e6f0ed1fa8b9 Mon Sep 17 00:00:00 2001
From: ng0 
Date: Sun, 31 Jul 2016 10:45:35 +
Subject: [PATCH] gnu: Add libgnomekbd.

* gnu/packages/gnome.scm (libgnomekbd): New variable.
---
 gnu/packages/gnome.scm | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index b2f4695..9497101 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -20,6 +20,7 @@
 ;;; Copyright © 2016 Roel Janssen 
 ;;; Copyright © 2016 Leo Famulari 
 ;;; Copyright © 2016 Alex Griffin 
+;;; Copyright © 2016 ng0 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -5388,3 +5389,33 @@ compiled.")
 GLib/GObject code.")
 (home-page "https://wiki.gnome.org/Projects/GFBGraph;)
 (license license:lgpl2.1+)))
+
+(define-public libgnomekbd
+  (package
+(name "libgnomekbd")
+(version "3.6.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "mirror://gnome/sources/" name "/"
+ (version-major+minor version)  "/"
+ name "-" version ".tar.xz"))
+ (sha256
+  (base32
+   "02bahnl3vaqyqyr99r9kwka84sxj8qdrz7x0bf97192dysqaa7n4"
+(build-system gnu-build-system)
+(inputs
+ `(("gtk+" ,gtk+)
+   ("libxklavier" ,libxklavier)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)
+   ("glib" ,glib "bin")
+   ("intltool" ,intltool)))
+(propagated-inputs
+ ;; Referred to in .h files and .pc.
+ `(("glib" ,glib)))
+(home-page "https://www.gnome.org;)
+(synopsis "Gnome keyboard configuration library")
+(description
+ "Gnome keyboard configuration library.  Its most visible feature is to
+display keyboard layouts.")
+(license license:lgpl2.0+)))
-- 
2.9.2

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: Isnan

[Danny Milosavljevic]

> Apparently the "std::" is missing in front of "isnan"; should this not be 
> implicit?

No. Many people in the C++ community frowns upon even doing "using namespace 
std" at all, never mind implicitly.

http://stackoverflow.com/questions/1265039/using-std-namespace

If you include math.h , isnan is called ::isnan .
If you include cmath , isnan is called std::isnan .

Also, std::isnan was added with C++11, so it's a new feature. Are you compiling 
with a C++11 compiler? What are the compiler flags used?

Re: Code formatting

[Andreas Enge]

On Sun, Jul 31, 2016 at 12:34:12PM +0200, Danny Milosavljevic wrote:
> Is there a standalone program that reformats Scheme code to what we want it 
> to be? 
> It would be best if such a program just automatically normalized all the 
> files for us. There's no reason this needs to stay a degree of freedom where 
> every single person has to manually make sure it's the same regardless.

That would be great, especially to run it once over all our source files.
I tend to program by copy-paste, which also pastes random indentation errors
from random packages.

Andreas

Isnan

[Andreas Enge]

Hello,

has anyone followed what the deal is with isnan in core-updates? A number
of C++ packages does not build any more. For instance, dealii:
solver_control.cc:96:24: error: ‘isnan’ was not declared in this scope
   isnan(check_value) ||
^
[ 30%] Building CXX object 
source/lac/CMakeFiles/obj_lac.debug.dir/solver_control.cc.o
cd /tmp/guix-build-dealii-8.2.1.drv-0/build/source/lac && 
/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/bin/c++   -DDEBUG 
-I/tmp/guix-build-dealii-8.2.1.drv-0/build/source/lac 
-I/tmp/guix-build-dealii-8.2.1.drv-0/build/include 
-I/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/include 
-I/gnu/store/pzk986yikywnql4x393pbhzbiz7vl72n-bzip2-1.0.6/include 
-I/gnu/store/f51hs67f3g1r15fy9xq4bi7m3z991p0j-tbb-4.3.2/include 
-I/gnu/store/5992iq1v7arqa14ym3di58n4la0893nv-zlib-1.2.8/include 
-I/gnu/store/5qp29kq39b23w0sb1306fhsrq0zfm6sl-suitesparse-4.4.3/include 
-I/gnu/store/693zbcqs6jv8zg7k1x8x8k3sm7fimqs0-boost-1.60.0/include 
-I/gnu/store/8vqdr67rfbxk12bl3gajshkiffn8l9ld-muparser-2.2.5-2/include  
-pedantic -fpic -Wall -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare 
-Wswitch -Wno-unused-local-typedefs -Wno-long-long -Wno-deprecated 
-Wno-deprecated-declarations -fopenmp-simd -std=c++11 -Og -ggdb 
-Wa,--compress-debug-sections -o 
CMakeFiles/obj_lac.debug.dir/solver_control.cc.o -c 
/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/source/lac/solver_control.cc
/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/source/lac/solver_control.cc: 
In member function ‘virtual dealii::SolverControl::State 
dealii::SolverControl::check(unsigned int, double)’:
/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/source/lac/solver_control.cc:96:24:
 error: ‘isnan’ was not declared in this scope
   isnan(check_value) ||
^
/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/source/lac/solver_control.cc:96:24:
 note: suggested alternative:
In file included from 
/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/include/c++/complex:44:0,
 from 
/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/include/deal.II/base/numbers.h:22,
 from 
/tmp/guix-build-dealii-8.2.1.drv-0/build/include/deal.II/base/config.h:579,
 from 
/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/include/deal.II/base/logstream.h:19,
 from 
/tmp/guix-build-dealii-8.2.1.drv-0/dealii-8.2.1/source/lac/solver_control.cc:16:
/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/include/c++/cmath:632:5: 
note:   ‘std::isnan’
 isnan(_Tp __x)

Apparently the "std::" is missing in front of "isnan"; should this not be 
implicit?

Andreas

Re: Code formatting

[Danny Milosavljevic]

> Bonus to whoever posts indentation rules for their favorite editor!  :-)

Is there a standalone program that reformats Scheme code to what we want it to 
be? 

It would be best if such a program just automatically normalized all the files 
for us. There's no reason this needs to stay a degree of freedom where every 
single person has to manually make sure it's the same regardless.

Ecl

[Andreas Enge]

Yet another package which fails on all architectures:
   http://hydra.gnu.org:3000/build/1313690
If someone is interested in it, please have a look.

Andreas

IR source disappeared

[Andreas Enge]

Hello,

the web site for IR disappeared and with it the source code:
   http://hydra.gnu.org:3000/build/1325922

While looking at the Debian package, I also noticed that their package
is called "...dfsg...", which usually indicates a freedom problem with
part of the source code. From what I understand, they do the following:
   https://sources.debian.net/src/ir.lv2/1.3.2~dfsg0-2/debian/repack.local/
rm lv2_ui.h \
 instance-access.h

Could someone interested in the package have a look, please?

It is a leaf package, so we might also remove it.

Thanks,

Andreas

Re: [PATCH] gnu: r: Update to 3.3.1.

[Roel Janssen]

> On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote:
>> The workaround used by sysops where I work (hospital research lab) is to
>> give notice of R upgrades and to make previous releases available for
>> reference by ongoing projects. IMO, we should consider how the guix R
>> recipe(s) might support a pattern of use like this.
>> 
>> I can assure you that if our users do guix pull and invisibly get a new
>> R release, their analyses will from time to time break. So we may want a
>> simple way for them to back down to a previous release. So.. I am
>> thinking it would make sense to keep previous versions of R in the
>> recipe. What do others think?
>
> Hi George,
>
> If bioconductor tests pass on a new R build they *should* work. Guix
> is not the same mess that Debian and Fedora are.
>
> Note, meanwhile, that a new R install does not remove the old packages
> automatically. One way to work older versions is by using guix
> profiles effectively. We introduced Unix modules with Guix, so a
> module would point to a well tested and working profile. Just make
> sure it does not get GC'd at some point.
>
> Another way to work it is by using a checked out Guix source tree.
> That is what we do for Genenetwork deployment. Guix 'pull' simply
> represents a version of the source tree - with its combination of
> packages. You can force a combination of package versions by keeping
> track of your own tree. See 
>
>   https://github.com/genenetwork/genenetwork2/blob/master/doc/README.org
>
> In the near future I hope we get a version of guix pull which can
> essentially achieve the same (i.e. a checked out version of the tree).
>
>   guix pull HASH-tag

Hi George,

I think what you're looking for in your hospital research lab is what
Pjotr describes as a certain check-out of the Guix source tree.

>From a scientific viewpoint you cannot say that the results of your data
analysis "will work with R version 3.3.0 or higher", but instead you can
only say "we achieved these results b using R version 3.3.0, with
extension X at version Y" (assuming these versions can be uniquely
identified to their source code).  This is what you can do with GNU
Guix.

You could explain how to reproduce your results by writing:  "When using
the recipes from GNU Guix at Git commit , we can construct a
software environment including R with version Y, with which we can
obtain the results we obtained."

So, using any newer Git commit ID is not guaranteed to work (but is
likely to work..).  The cool thing is, is that you can construct the
software environment from any particular time, as long as the source
tarballs are available.

In addition to the `per-user' profiles, you could use `per-pipeline' and
`per-group' profiles for users to "pin" a specific software environment
for doing the data analysis.  Users can then set the environment
variables in their shell to use that shared profile:
  export PATH=/path/to/profiles/per-pipeline/ngs/guix-profile/bin:$PATH
  export 
R_LIBS_SITE=/path/to/profiles/per-pipeline/ngs/guix-profile/site-library

Or by simply following the recommendations by GNU Guix:
  guix package --search-paths 
--profile=/path/to/profiles/per-profiles/ngs/guix-profile

I think upgrading is inevitable, so pinpointing to a specific set of
build recipes (tied to a commit ID) is a good way of maintaining a
stable software environment.

Do you think we can keep the latest versions in the upstream repository,
provided that you have a way of reverting or staying to the "old"
versions by either copying the 3.3.0 recipe to a local repository, or
pinpoint to an older Git commit?

Kind regards,
Roel Janssen

Python-pathlib

[Andreas Enge]

Hello,

python-pathlib is one of the other packages that fails on core-updates.
I am reading on its home page:
   https://pypi.python.org/pypi/pathlib/ :
"Requirements

Python 3.2 or later is recommended, but pathlib is also usable with Python 2.7 
and 2.6.
Install

In Python 3.4, pathlib is now part of the standard library. For Python 3.3 and 
earlier, easy_install pathlib or pip install pathlib should do the trick."

So should we drop python-pathlib and keep only python2-pathlib?

Andreas

Re: Shepherd fails on core-updates

[Andreas Enge]

On Sun, Jul 31, 2016 at 10:03:32AM +0200, Andreas Enge wrote:
> shepherd does not build on arm in core-updates:
>http://hydra.gnu.org:3000/build/1246005

Well, in an effort to provide the logs of the failing tests, I compiled
on my novena, and the tests do pass! I will restart it once again.

The same happens for python2-alembic - it builds without problem on my
x86_64.

Andreas

Re: [PATCH] gnu: r: Update to 3.3.1.

[Andreas Enge]

Hello,

On Sat, Jul 30, 2016 at 04:36:22PM +0200, Roel Janssen wrote:
> Is it OK to upgrade?

maybe wait until after the core-updates merge?

Andreas

Re: [PATCH} Add RAID devices.

[Andreas Enge]

On Sat, Jul 30, 2016 at 07:05:25PM -0400, myglc2 wrote:
> > I might write a more detailed blog post about this; there is a little
> > subtlety with the non-automatic determination of dependencies between
> > devices, so one needs to make sure that the partitions to be assembled
> > are present before the mdadm command is executed.
> I rebooted and the array is not assembled ;-(

Strange! But I will also tell you the subtlety ;-)  Here is a trick to use
(thanks to Ludovic):
(define md0
  (mapped-device
(source (list "/dev/sda2" "/dev/sdb2"))
  (target "/dev/md0")
  (type raid-device-mapping)))
(operating-system
...
  (mapped-devices (list md0))
  (file-systems (cons (file-system
(title 'device)
(device "/dev/md0")
(dependencies (list md0))
(mount-point "/")
(type "ext4"))
  %base-file-systems))

The "dependencies" field makes sure that the file system is only mounted
after the array is assembled; I am not sure that this is your problem,
but you might want to give it a try.

In the long run, this should be reprogrammed: Devices and file systems
should wait until all their "inputs" are present, or at least wait for
a reasonable time.


Andreas

Shepherd fails on core-updates

[Andreas Enge]

Something embarrassing:
shepherd does not build on arm in core-updates:
   http://hydra.gnu.org:3000/build/1246005

Andreas

Re: Glibc-locales failure in core-updates

[Andreas Enge]

On Sun, Jul 31, 2016 at 10:56:50AM +0800, 宋文武 wrote:
> > glibc-locales fails on all architectures in core-updates. The error message
> > looks as if it would not be too difficult to fix for someone who knows
> > the package...
> Fixed, thanks for noticing!

Great, thanks a lot!

Andreas

Re: [GSoC] Continuous integration tool à la Hydra.

[Florian Paul Schmidt]

Hi!

On 07/29/2016 09:26 PM, Mathieu Lirzin wrote:
>> To get pkg-config, see .
>> See `config.log' for more details
> 
> I have tested successfully with the following command on a foreign
> system:
> 
>   guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite 
> guile-sqlite3
> 
> Tell me if it works for you.

Yes, that makes configure run fine. Thanks

This is what I get when I run it:

fps@guix ~/cuirass [env]$ ./pre-inst-env cuirass
--specifications=tests/hello-singleton.scm --database=test.db
Cloning into 'guix'...
remote: Counting objects: 101761, done.
remote: Compressing objects: 100% (28866/28866), done.
remote: Total 101761 (delta 74214), reused 99101 (delta 72173)
Receiving objects: 100% (101761/101761), 35.86 MiB | 6.27 MiB/s, done.
Resolving deltas: 100% (74214/74214), done.
Checking connectivity... done.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
+ exec autoreconf -vfi
./bootstrap: line 5: exec: autoreconf: not found
In execvp of ./configure: No such file or directory
In execvp of make: No such file or directory
;;; note: source file /home/fps/.cache/cuirass/guix/./guix/derivations.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/derivations.go
;;; note: source file /home/fps/.cache/cuirass/guix/./guix/store.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/store.go
;;; note: source file /home/fps/.cache/cuirass/guix/./guix/utils.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/utils.go
;;; note: source file /home/fps/.cache/cuirass/guix/./guix/combinators.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/combinators.go
;;; note: source file /home/fps/.cache/cuirass/guix/./guix/build/utils.scm

[ more here ]

;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/unrtf.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/unrtf.go
;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/uucp.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/uucp.go
;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/vtk.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/vtk.go
;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/wdiff.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/wdiff.go
;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/wine.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/wine.go
;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/xfce.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/xfce.go
;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/xnee.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/xnee.go
;;; note: source file
/home/fps/.cache/cuirass/guix/./gnu/packages/yubico.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/yubico.go
;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/zsh.scm
;;;   newer than compiled
/gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/zsh.go
evaluate 'hello-2.10.x86_64-linux': 32.563 seconds
building /gnu/store/cw502hifb3q32h2x0gl1afgzmbx9295y-hello-2.10.drv...
/gnu/store/zby49aqfbd9w9br4l52mvb3y6f9vfv22-hello-2.10
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
^C
fps@guix ~/cuirass [env]$

And then:

fps@guix ~/cuirass [env]$  ./pre-inst-env cuirass --database=test.db
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2.
[]

Is that the expected output/behaviour?

Regards,
Flo


-- 
https://fps.io



signature.asc
Description: OpenPGP digital signature