[PATCH] gnu: xz: Update to 5.2.1

[宋文武]

>From 28016e1de7b60c8d23728b66c2dc90d6cd1e4c3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 12 Sep 2015 14:25:11 +0800
Subject: [PATCH] gnu: xz: Update to 5.2.1.

* gnu/packages/compression.scm (xz): Update to 5.2.1.
---
 gnu/packages/compression.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 287ae25..354f51b 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -225,14 +225,14 @@ decompression.")
 (define-public xz
   (package
(name "xz")
-   (version "5.0.4")
+   (version "5.2.1")
(source (origin
 (method url-fetch)
 (uri (string-append "http://tukaani.org/xz/xz-"; version
 ".tar.gz"))
 (sha256
  (base32
-  "1dl35ca8fdss9z2d6y234gxh24ixq904xksizrjmjr5dimwhax6n"
+  "10a6jxxpm6gbypx5jwhqkq201y1xcvpbb7g1ga6lzrvnh1jbc65r"
(build-system gnu-build-system)
(synopsis "General-purpose data compression")
(description
-- 
2.4.3


This seem trigger the rebuild of everything, should I push it into
the current 'core-updates' or wait for a next cycle?

Re: [PATCH 3/3] gnu: Add python-oslo.config.

[Mathieu Lirzin]

Cyril Roelandt  writes:

> * gnu/packages/openstack.scm (python-oslo.config, python2-oslo.config): New 
> variables.
> ---
>  gnu/packages/openstack.scm | 37 +
>  1 file changed, 37 insertions(+)

LGTM (Like previous reviews for the formatting).

--
Mathieu Lirzin

Re: [PATCH 2/3] gnu: Add python-stevedore.

[Mathieu Lirzin]

Cyril Roelandt  writes:

> * gnu/packages/openstack.scm (python-stevedore, python2-stevedore): New 
> variables.
> ---
>  gnu/packages/openstack.scm | 43 +++
>  1 file changed, 43 insertions(+)

Same as previous review for formatting, otherwise LGTM.

--
Mathieu Lirzin

Re: [PATCH 1/3] gnu: Add python-netaddr.

[Mathieu Lirzin]

This is Mostly about formatting issues here

Cyril Roelandt  writes:

> * gnu/packages/python.scm (python-netaddr, python2-netaddr): New variables.
> ---
>  gnu/packages/python.scm | 28 
>  1 file changed, 28 insertions(+)
>
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index f9ad951..0231bce 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -4739,3 +4739,31 @@ reading and writing MessagePack data.")
>  
>  (define-public python2-msgpack
>(package-with-python2 python-msgpack))
> +
> +(define-public python-netaddr
> +  (package
> +(name "python-netaddr")
> +(version "0.7.18")
> +(source
> +  (origin

(source
 (origin ...))

> +(method url-fetch)
> +(uri (string-append
> +   "https://pypi.python.org/packages/source/n/netaddr/netaddr-";
> +   version
> +   ".tar.gz"))
 
(string-append
 "..." 
 ...)

> +(sha256
> +  (base32
> +"06dxjlbcicq7q3vqy8agq11ra01kvvd47j4mk6dmghjsyzyckxd1"

(base32
 "")

> +(build-system python-build-system)
> +(arguments `(#:tests? #f)) ;; No tests.
  
   ;no tests

> +(inputs
> +  `(("python-setuptools" ,python-setuptools)))
> +(home-page "https://github.com/drkjam/netaddr/";)
> +(synopsis
> +  "Pythonic manipulation of IPv4, IPv6, CIDR, EUI and MAC network 
> addresses")

In order to keep synopsis small and the description longer that
synopsis, maybe you an move "IPv4, IPv6, CIDR, EUI and MAC" into the
description?

> +(description
> +  "A Python library for representing and manipulating network 
> addresses.")
> +(license bsd-3)))
> +
> +(define-public python2-netaddr
> +  (package-with-python2 python-netaddr))

Otherwise LGTM.

--
Mathieu Lirzin

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

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

> I think it’s time to get ready to merge it, so let’s say we’ll get Hydra
> building all of it within a day or two.  Any objections?

I’ve just pushed a patch to skip the Coreutils test that was causing
intermittent failures (see ) and Hydra will
soon start rebuilding the ‘core’ package subset.

Ludo’.

Re: 'origin' indentation rule.

[Ludovic Courtès]

Mathieu Lirzin  skribis:

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

>> Other than that, I think it’s no big deal if some packages don’t follow
>> exactly this rule.  I encourage people to follow this rule, but I prefer
>> a patch that violates it than no patch at all.  I guess it’s about
>> finding the right balance between nitpicking and welcoming.  ;-)
>
> "encourage" means that this is OK that those who use Emacs and/or know
> this rule apply silently this indentation rule when for example updating
> a package definition?

Sure.

>> So apart from the manual, I wouldn’t change anything.
>
> I will send a patch for this, if we agree on that.

We’ve already agreed.  :-)

Ludo’.

Re: 'origin' indentation rule.

[Mathieu Lirzin]

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

> Mathieu Lirzin  skribis:
>
>> I failed to retrieve the post where this rule has been suggested (if
>> there is one), so I don't know the rationale behind it.
>
> I don’t think it was discussed at the time.  It’s just that I like
> ‘package’ and ‘origin’ indented like ‘begin’, I think it’s more pleasant
> to the eye.  :-)

Ok, that makes sense. :)

> It’s a good idea to have the manual conform to the rule.
>
> Other than that, I think it’s no big deal if some packages don’t follow
> exactly this rule.  I encourage people to follow this rule, but I prefer
> a patch that violates it than no patch at all.  I guess it’s about
> finding the right balance between nitpicking and welcoming.  ;-)

"encourage" means that this is OK that those who use Emacs and/or know
this rule apply silently this indentation rule when for example updating
a package definition?

> Importers render code with (ice-9 pretty-print), which is quite
> primitive, so they cannot follow sophisticated rules.

OK, I didn't know about that.

> So apart from the manual, I wouldn’t change anything.

I will send a patch for this, if we agree on that.

--
Mathieu Lirzin

Re: 'origin' indentation rule.

[Mathieu Lirzin]

"Thompson, David"  writes:

> Sounds fine to me.  It's best to be consistent, but this isn't a big deal.

yeah I know...

I tend to have OCD in regards of code formatting.  Sorry about that.  :)

--
Mathieu Lirzin

Re: 'origin' indentation rule.

[Thompson, David]

On Fri, Sep 11, 2015 at 1:08 PM, Ludovic Courtès  wrote:
> Hello!
>
> Mathieu Lirzin  skribis:
>
>> I failed to retrieve the post where this rule has been suggested (if
>> there is one), so I don't know the rationale behind it.
>
> I don’t think it was discussed at the time.  It’s just that I like
> ‘package’ and ‘origin’ indented like ‘begin’, I think it’s more pleasant
> to the eye.  :-)
>
>> My personnal opinion is that for the sake of simplicity and column
>> saving we should remove it. But Whatever the final decision is, I
>> think it's important to be consistent at least in the manual and the
>> importers.
>
> It’s a good idea to have the manual conform to the rule.
>
> Other than that, I think it’s no big deal if some packages don’t follow
> exactly this rule.  I encourage people to follow this rule, but I prefer
> a patch that violates it than no patch at all.  I guess it’s about
> finding the right balance between nitpicking and welcoming.  ;-)
>
> Importers render code with (ice-9 pretty-print), which is quite
> primitive, so they cannot follow sophisticated rules.
>
> So apart from the manual, I wouldn’t change anything.
> What do people think?

Sounds fine to me.  It's best to be consistent, but this isn't a big deal.

- Dave

Re: 'origin' indentation rule.

[Ludovic Courtès]

Hello!

Mathieu Lirzin  skribis:

> I failed to retrieve the post where this rule has been suggested (if
> there is one), so I don't know the rationale behind it.

I don’t think it was discussed at the time.  It’s just that I like
‘package’ and ‘origin’ indented like ‘begin’, I think it’s more pleasant
to the eye.  :-)

> My personnal opinion is that for the sake of simplicity and column
> saving we should remove it. But Whatever the final decision is, I
> think it's important to be consistent at least in the manual and the
> importers.

It’s a good idea to have the manual conform to the rule.

Other than that, I think it’s no big deal if some packages don’t follow
exactly this rule.  I encourage people to follow this rule, but I prefer
a patch that violates it than no patch at all.  I guess it’s about
finding the right balance between nitpicking and welcoming.  ;-)

Importers render code with (ice-9 pretty-print), which is quite
primitive, so they cannot follow sophisticated rules.

So apart from the manual, I wouldn’t change anything.
What do people think?

Ludo’.

Re: R dependencies

[Vicente Vera]

Hello again,

Finally solved this:

Error in grid.Call.graphics(L_text, as.graphicsAnnot(x$label), x$x, x$y,  :
X11 font -adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*, face 2 at size
11 could not be loaded

The problem arose because R wasn't using cairo for font rendering.
Some simple configurations in ~/.Rprofile solved it:

setHook(packageEvent("grDevices", "onLoad"),
function(...) grDevices::X11.options(type = "cairo",
 antialias = "subpixel"))

The code changes the X11 device (used for plotting) type from "XLib"
to "cairo", once it gets called.

(just for the record, i'm not using GuixSD)

2015-09-03 11:55 GMT-03:00 Vicente Vera :
> Hi,
>
> Sure. The error message is this:
>
> X11 font -adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*, face 5 at size
> 15 could not be loaded
>
> No plot is being drawn; only a blank window appears.
>
> The code:
>
> ggplot(data = fig1, aes(x = Var1, y = Freq, fill =
> brewer.pal(length(levels(the_data$VARIABLE1)), "Set3"))) +
> geom_bar(stat = "identity") +
> scale_fill_identity() +
> labs(x = "x", y = "y") +
> geom_text(aes(label = perc), vjust = 2, size = 4, colour =
> "black", fontface = "bold") +
> scale_x_discrete(labels = c("a", "b", "c")) +
> theme(panel.background = element_blank(),
>   line = element_blank(),
>   axis.text.y = element_blank())
>
> On my base system, R 3.2.1 + ggplot2 draws the plot with no problem.
>
> It might be related to a missing font or font alias in the Guix store
> (not familiar enough with it to catch the issue).
>
> Now, I didn't installed ggplot2 through Guix, so that could be a problem.
>
> 2015-09-03 3:29 GMT-03:00 Ricardo Wurmus :
>> Hi Vicente,
>>
>>> Going back to the R dependencies topic, I ran across an issue when
>>> trying to draw a plot (with ggplot2). But first some context:
>>>
>>> - I'm not using GuixSD but a binary installation over Manjaro OpenRC;
>>> several base packages missing on Guix
>>> - I only have other two Guix packages installed: xpdf & abbaye
>>
>> All Guix packages capture the complete graph of dependencies, so you’ll
>> always end up with the dependent packages in ‘/gnu/store’ even if only
>> those packages appear in your profile that have been explicitly
>> installed.
>>
>>> - I installed ggplot2 through install.packages("ggplot2") in R (Guix 
>>> package)
>>
>> Note that ggplot2 has been packaged for Guix:
>>
>> guix package -i r-ggplot2
>>
>>> R complained about some fonts missing, but I think it could be related
>>> to a missing X11 dependency (complete Xorg maybe?). What could it be?
>>
>> What is the exact error message you get?  Is any plot drawn at all?
>> What is the code you use to draw the plot?
>>
>> ~~ Ricardo
>>

tests/tail-2/assert.sh failed on x86_64

[Manolis Ragkousis]

Hello everyone,

While trying to build coreutils on x86_64,  tests/tail-2/assert.sh
sometimes fails. When
I say sometimes, it usually works with the second time.
Even though this happened on a locally rebased core-updates/wip-hurd
branch, I am
sending the log because I saw that this also happened on armhf.

I will also try reproducing it with the master branch on my machine.

Manolis


p0nkvs1j0wamv5rknv492mafhz59f7-coreutils-minimal-8.24.drv.bz2
Description: BZip2 compressed data

Re: [PATCH 12/13] gnu: Add xmonad.

[Eric Bavier]

On Mon, 31 Aug 2015 17:52:36 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Siniša Biđin  skribis:
> 
> > On 2015-08-23 22:47, Eric Bavier wrote:
> >> I had to replace "Exec=/etc/X11/Session/xmonad" with "Exec=xmonad"
> >> in this xmonad.desktop file in order to launch an xmonad session from
> >> Slim.  Does this seem right?
> >
> > Definitely!
> 
> [...]
> 
> >> Does it make sense to fetch this file
> >> from gentoo.org and then modify it? or should we rather just
> >> generate it
> >> ourselves?  What do you/others think?
> >
> > I had followed ratpoison's example (also using gentoo.org), but it does
> > feel dirty. I'm fine with generating it or having it stored in guix's
> > repo,
> > but couldn't find an example of any other package doing the same.
> 
> I think “generating” it (or having it as a string literal) in the source
> is preferable.
> 
> >>> +(propagated-inputs
> >>> + `(("ghc-mtl" ,ghc-mtl)
> >>> +   ("ghc-utf8-string" ,ghc-utf8-string)
> >>> +   ("ghc-extensible-exceptions" ,ghc-extensible-exceptions)
> >>> +   ("ghc-x11" ,ghc-x11)))
> >>
> >> Do these inputs need to be propagated?  I can start up an xmonad
> >> session without propagating these inputs.  Do they need to be available
> >> for xmonad's 'mod-q' (i.e. restarting xmonad/loading a new config)?
> >
> > I think so, yes. For one, since xmonad is an executable and a library,
> > if
> > we don't propagate, "ghc-pkg list" will report it as broken.
> 
> Makes sense to me.
> 
> Could you post an updated patch that addresses these two things?

I've pushed a modified commit that generates the .desktop files for
xmonad, and adds the package instead to gnu/packages/wm.scm.

This Xmonad's mod-q does not work as expected, but that isn't a problem
if you like the default configuration ;).  Anyhow, some more work will
need to be done to support reconfiguration.  I had thought
GHC_PACKAGE_PATH would do what we need, but it doesn't seem to do what
I had thought.  Perhaps creating a custom package database for xmonad
to use would work.

Thanks again for the patch, and sorry for the delay in getting it
pushed!
`~Eric

Re: [PATCH 14/15] scripts: environment: Add --container option.

[Ludovic Courtès]

"Thompson, David"  skribis:

> On Tue, Jul 7, 2015 at 10:35 AM, Ludovic Courtès  wrote:

[...]

> I have a shiny new patch that adds --network, --share, and --expose
> options.

Neat!

> Also, rather than bind-mounting the entire store, I figured out how to
> bind-mount only the union of the closures of the inputs like build
> daemon containers.

How does it perform compared to doing a single bind mount?  It is
noticeably slower or OK?

> And finally, the original patch didn't setup /bin/sh, which is of
> course terrible and broke tons of things so I've fixed that, too.

Right.  :-)

> Now I can do things like build Guix from source inside a container, or
> better replicate the build daemon's environment when debugging with
> failed builds.  I hope that soon everyone will be able to enjoy this.
> :)

Sounds cool!

> From 8e2d0fca75feeaacaf6a401a3c13d614f9c3720b Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Fri, 19 Jun 2015 08:57:44 -0400
> Subject: [PATCH] scripts: environment: Add --container option.
>
> * guix/scripts/system.scm (specification->file-system-mapping): Move from
>   here...
> * guix/ui.scm (specification->file-system-mapping): ... to here.
> * guix/scripts/enviroment.scm (show-help): Show help for new options.
>   (%options): Add --container --network, --expose, and --share options.
>   (launch-environment, launch-environment/container, requisites*,
>   inputs->requisites): New procedures.
>   (guix-environment): Spawn new process in a container when requested.
> * doc/guix.texi (Invoking guix environment): Document it.

[...]

> +The example below spawns a Guile REPL in a container in which the user's
> +home directory is accessible read-only via the @file{/exchange}
> +directory:
> +
> +@example
> +guix environment --container --expose=$HOME=/exchange guile -E guile
> +@end example

\o/

> +  -C, --containerrun command within an isolated container"))

s/within/in/ ?  (You know better than me...)


> +(define (inputs->requisites inputs)
> +  "Convert INPUTS, a list of derivations, into a set of requisite store 
> items i.e.

s/derivations/input tuples/ since it’s a list of (LABEL DRV) or
(LABEL DRV OUTPUT).

> + ;; When in Rome, do as Nix build.cc does: Automagically
> + ;; map common network configuration files.
> + (if network?
> + (filter-map (lambda (file)
> +   (and (file-exists? file)
> +(file-system-mapping
> + (source file)
> + (target file)
> + (writable? #f
> + '("/etc/resolv.conf"
> +   "/etc/nsswitch.conf"
> +   "/etc/services"
> +   "/etc/hosts"))

Could you make this list a global variable for clarity?


[...]

> +(define (specification->file-system-mapping spec writable?)
> +  "Read the SPEC and return the corresponding ."

Now that this is public, could you add an example of what SPEC looks
like in the docstring?

Last, could you add (maybe in a separate patch?)
tests/guix-environment-container.sh mimicking tests/guix-environment.sh?
It only needs to use -E to run a tiny script that checks that we really
get an environment with only the right file system mappings?

Thanks!

Ludo’.

Re: New ‘guix graph’ command

[Ludovic Courtès]

Cyril Roelandt  skribis:

> On 08/27/2015 12:53 AM, Ludovic Courtès wrote:
>> Here’s a long overdue ‘guix graph’ command (documentation below.)
>> Comments welcome!
>
> Would it be hard to do the opposite of what guix graph does ? I'd like
> to be able to find the list of packages which depend on a given package.
> This would be useful when updating a package, to make sure that the
> update does not break anything.

It shouldn’t be too hard, using something akin to the code of ‘guix
refresh --list-dependent’.

Ludo’.

Re: New ‘guix graph’ command

[Leo Famulari]

I think that is what `guix gc --referrers /gnu/store/...package` does.

http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-gc.html

On Thu, Sep 10, 2015, at 20:02, Cyril Roelandt wrote:
> On 08/27/2015 12:53 AM, Ludovic Courtès wrote:
> > Here’s a long overdue ‘guix graph’ command (documentation below.)
> > Comments welcome!
> 
> Would it be hard to do the opposite of what guix graph does ? I'd like
> to be able to find the list of packages which depend on a given package.
> This would be useful when updating a package, to make sure that the
> update does not break anything.
> 
> WDYT?
> 
> 
> Cyril.
>