Re: Review process

[Pjotr Prins]

On Fri, Jul 22, 2016 at 06:02:48PM +0200, Ludovic Courtès wrote:
> > I think I have covered that both in my writeup and in my response to
> > Ben. I think this work should be accepted as is.
> 
> I find this unfair.  You are not a newcomer, as proved by the fact that
> you’ve already identified weaknesses in the work you submit.

Exactly. 

> Thus, that you post it anyway can be understood as “I know this and that
> should be done, but I’d rather let you do it on my behalf, kthxbye”.
> 
> Or perhaps you’re suggesting that reviews are unnecessary, or that the
> points we insist on make little sense?

If have explained things why they are as they are with the Elixir
package. I have done my utmost to get the package to this stage. There
is some work pending fixing tests with upstream. All that is in the
open and happening.

> Well, I can tell you that as a user, I very much prefer that people who
> add packages to the distro have taken their time to make it lean and
> clean.  This QA work that you dislike is a service that we developers do
> to users; it’s not something we do for the sake of elitism.
> 
> I hope this can clear misunderstandings!

Thanks Ludo. As it stands I am no longer submitting packages to ML. I
did my utmost to make the package lean and clean. This package is not
going in.

But, I suggest you listen. I know at least 4 people here who say they
have trouble submitting to Guix. Good people.

You know I love Guix and I am a great admirer of all of you and I
certainly appreciate the energy you put into developing Guix and
reviews. I won't go away, but I am making clear why I am quitting
working in this way. Mind, I saw this coming. I actually quit
submitting packages half a year ago and instead worked through others.
I was interested to see if I would survive this one last attempt. In
the end my opinion on the state of the package conflicts with yours -
even though I am the expert on Elixir here and the conflict is not
about knowledge of Guix itself. Please read this last sentence again.

I'll have a think on how to proceed from here. I want to work with
those 4 people. And I want to attract more people from conda, brew
etc. I am convinced we need to change our ways. This state of affairs
does not sit well with me. To call it elitist was a provocation, but I
actually think there is some truth to it. The world is divided in
people who can do the dance, and those who can't (for whatever
reason). We need to find a way where the lesser people (like me) can
contribute.

Now, THAT would make it a brilliant project.

Pj.

[PATCH] gnu: libepoxy: Update to 1.3.1.

[ng0]

VLC build graph in core-update fails at libepoxy (see
core-updates thread), this updates libepoxy and hopefully fixes
the problem with vlc.


>From 3974440fdcd69b8e6f968492c2f031daeba61193 Mon Sep 17 00:00:00 2001
From: ng0 
Date: Sat, 23 Jul 2016 00:33:28 +
Subject: [PATCH] gnu: libepoxy: Update to 1.3.1.

* gnu/packages/gl.scm (libepoxy): Update to 1.3.1.
---
 gnu/packages/gl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index f36d15a..a4bffe4 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -443,7 +443,7 @@ OpenGL graphics API.")
 (define-public libepoxy
   (package
 (name "libepoxy")
-(version "1.2")
+(version "1.3.1")
 (source (origin
   (method url-fetch)
   (uri (string-append
@@ -453,7 +453,7 @@ OpenGL graphics API.")
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32
-"1xp8g6b7xlbym2rj4vkbl6xpb7ijq7glpv656mc7k9b01x22ihs2"
+"1d1brhwfmlzgnphmdwlvn5wbcrxsdyzf1qfcf8nb89xqzznxs037"
 (arguments
  `(#:phases
(alist-cons-after
-- 
2.9.1


-- 
♥Ⓐ  ng0 – http://we.make.ritual.n0.is
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org

[PATCH] gnu: Add trash-cli.

[Alex Griffin]

This patch adds trash-cli, a simple command line utility for interacting
with the FreeDesktop.org Trash used by GNOME, KDE, XFCE, etc.
-- 
Alex Griffin
From 1aaeb3dc699d58d7ef18791b8c385e341e4acc15 Mon Sep 17 00:00:00 2001
From: Alex Griffin 
Date: Fri, 22 Jul 2016 19:20:53 -0500
Subject: [PATCH] gnu: Add trash-cli.

* gnu/packages/shellutils.scm (trash-cli): New variable.
---
 gnu/packages/shellutils.scm | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/shellutils.scm b/gnu/packages/shellutils.scm
index 8108b04..27f45ba 100644
--- a/gnu/packages/shellutils.scm
+++ b/gnu/packages/shellutils.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016 Matthew Jordan 
+;;; Copyright © 2016 Alex Griffin 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -17,11 +18,14 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (gnu packages shellutils)
+  #:use-module (gnu packages base)
+  #:use-module (gnu packages python)
   #:use-module (guix licenses)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix utils)
-  #:use-module (guix build-system gnu))
+  #:use-module (guix build-system gnu)
+  #:use-module (guix build-system python))
 
 (define-public envstore
   (package
@@ -48,3 +52,39 @@
 between various shells or commands.")
 (license
  (non-copyleft "http://www.wtfpl.net/txt/copying/;
+
+(define-public trash-cli
+  (package
+(name "trash-cli")
+(version "0.12.9.14")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "trash-cli" version))
+   (sha256
+(base32
+ "1p4v2qx0sy47d9c9axszq04wns63s4b7rrhmsavg948sklqdaf54"
+(build-system python-build-system)
+(arguments
+ `(#:python ,python-2
+   #:tests? #f ; no tests
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'build 'patch-path-constants
+   (lambda* (#:key inputs #:allow-other-keys)
+ (let ((libc (assoc-ref inputs "libc"))
+   (coreutils (assoc-ref inputs "coreutils")))
+   (substitute* "trashcli/list_mount_points.py"
+ (("\"/lib/libc.so.6\".*")
+  (string-append "\"" libc "/lib/libc.so.6\"\n"))
+ (("\"df\"")
+  (string-append "\"" coreutils "/bin/df\"")
+(inputs `(("coreutils" ,coreutils)))
+(home-page "https://github.com/andreafrancia/trash-cli;)
+(synopsis "Trash can management tool")
+(description
+ "trash-cli is a command line utility for interacting with the
+FreeDesktop.org trash can used by GNOME, KDE, XFCE, and other common desktop
+environments.  It can move files to the trash, and remove or list files that
+are already there.")
+(license gpl2+)))
-- 
2.9.1

Re: core-updates, next release, and all that

[ng0]

While building vlc libepoxy is in the graph, and this fails on
its own, adding one problem to get vlc to testbuild on
core-updates. I've seen someone fix something similar this this
week but I don't know how.
libepoxy is also outdated, newest release is
https://github.com/anholt/libepoxy/archive/v1.3.1.tar.gz
so I'll try with updating first.

Found valid signature for
/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2
From
https://mirror.hydra.gnu.org/nar/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2
Downloading 6m6p3m…-libepoxy-1.2 (2.7MiB installed)...
 libepoxy-1.2
 342KiB/s 00:01 | 373KiB transferred
 @ substituter-failed
 /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 0 hash
 mismatch in downloaded path
 `/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2':
 expected
 27b06d547ac45ab865e5cd27ccbf3654eba156d4563c0a0868466fdd2e383e8a,
 got
 72fd010c7341668648ffe7e0c9839c2ba2dfe18f998b86cc7e4e0fd218bf5c06
 @ substituter-started
 /gnu/store/zijrd8769sgfxqhq92b9219dhpl76va5-ftgl-2.1.3-rc5
 
/gnu/store/vw26xsn24jmrijn939fjjk50m5i4hfq3-guix-0.10.0-0.e901/libexec/guix/substitute
 killing process 23614
 guix build: error: build failed: some substitutes for the
 outputs of derivation
 `/gnu/store/vwhxvdfwwm7phx9ysd6nr115bwlki56z-qtbase-5.6.1-1.drv'
 failed (usually happens due to networking issues); try
 `--fallback' to build derivation from source
 ng0@shadowwalker ~/src/guix/guix-curl$ ./pre-inst-env guix build
 libepoxy
 The following file will be downloaded:
/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2
@ substituter-started
/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2

/gnu/store/vw26xsn24jmrijn939fjjk50m5i4hfq3-guix-0.10.0-0.e901/libexec/guix/substitute

Found valid signature for
/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2
From
https://mirror.hydra.gnu.org/nar/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2
Downloading 6m6p3m…-libepoxy-1.2 (2.7MiB installed)...
 libepoxy-1.2
 1.2MiB/s 00:00 | 373KiB transferred
 @ substituter-failed
 /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 0 hash
 mismatch in downloaded path
 `/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2':
 expected
 27b06d547ac45ab865e5cd27ccbf3654eba156d4563c0a0868466fdd2e383e8a,
 got
 72fd010c7341668648ffe7e0c9839c2ba2dfe18f998b86cc7e4e0fd218bf5c06
 guix build: error: build failed: some substitutes for the
 outputs of derivation
 `/gnu/store/x2x0ydbc66rm3a3r3n1n6qdhcfw1ixlv-libepoxy-1.2.drv'
 failed (usually happens due to networking issues); try
 `--fallback' to build derivation from source
 
-- 
♥Ⓐ  ng0 – http://we.make.ritual.n0.is
NFor non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org

[PATCH] Add trio (dependency of ghostscript)

[Ricardo Wurmus]

Hi Guix,

I noticed that GNU Ghostscript (and the unpackaged AGPL Ghostscript)
bundles a few dependencies.  One of them is trio.

Here’s a working build of this library that has been sitting in my “wip”
branch for more than a year.

~~ Ricardo

>From 15ee46e1db30696c0f1dade014d619a8383dfa96 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Thu, 3 Sep 2015 13:28:25 +0200
Subject: [PATCH] gnu: Add trio.

* gnu/packages/code.scm (trio): New variable.
---
 gnu/packages/code.scm | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/code.scm b/gnu/packages/code.scm
index c3efd15..cce6945 100644
--- a/gnu/packages/code.scm
+++ b/gnu/packages/code.scm
@@ -229,6 +229,29 @@ files, but compared to grep is much faster and respects files like .gitignore,
 .hgignore, etc.")
 (license license:asl2.0)))
 
+(define-public trio
+  (package
+(name "trio")
+(version "1.16")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "mirror://sourceforge/ctrio/trio/trio-"
+  version ".tar.gz"))
+  (sha256
+   (base32
+"02pwd5m5vq7hbrffgm2na1dfc249z50yyr5jv73vdw15bd7ygl44"
+(build-system gnu-build-system)
+(home-page "http://daniel.haxx.se/projects/trio/;)
+(synopsis "Portable and extendable printf and string functions")
+(description
+ "Trio is a set of @code{printf} and string functions designed be used by
+applications with a focus on portability or with the need for additional
+features that are not supported by the standard @code{stdio} implementation.")
+;; This license is very similar to the ISC license, but the wording is
+;; slightly different.
+(license (license:non-copyleft
+  "http://sourceforge.net/p/ctrio/git/ci/master/tree/README;
+
 (define-public withershins
   (package
 (name "withershins")
-- 
2.8.4

Re: core-updates, next release, and all that

[Andreas Enge]

On Fri, Jul 22, 2016 at 07:00:43PM -0400, Leo Famulari wrote:
> Done. I also wrote a description of the conflicts I resolved in the
> commit message. I think this is useful, since I've had difficulty
> learning this information about other merges in the past.

Thank you! I just launched a new evaluation.

Andreas

Re: [PATCH] download: Add official SourceForge mirror.

[Leo Famulari]

On Fri, Jul 22, 2016 at 01:08:31PM -0500, Alex Griffin wrote:
> This patch mirrors a similar change in nixpkgs [1][2].
> 
> The official method for downloading from SourceForge is to use
> downloads.sourceforge.net, which redirects to various other mirrors. It
> can be unreliable, but also faster because it can find a nearby mirror
> and load-balance. If it fails Guix will still fall back to known good
> mirrors.

I think it's a good idea. It wouldn't have helped with the latest
problem, where the project-specific parts of the URL changed. But, if
our users can automatically use closer mirrors, that seems best.

Any objections?

Re: Gs

[Ricardo Wurmus]

Andreas Enge  writes:

> Hello,
>
> the following commit
> commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> Author: Ludovic Courtès 
> Date:   Mon May 9 15:54:34 2016 +0200
>
> gnu: ghostscript: Do not build the statically-linked 'gs' binary.
> 
> * gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
> 'build-so' and 'install-so' phases.  Replace 'build' and 'install'
> phases.
>
> removes "gs" from the ghostscript package. However, this is the usual program
> that people expect. For instance, unison uses it for building its
> documentation. Is there a dynamically linked binary which replaces gs?
> If yes, should we add a symbolic link?

This also broke our “lilypond” package on core-updates.

~~ Ricardo

Re: core-updates, next release, and all that

[Leo Famulari]

On Sat, Jul 23, 2016 at 12:06:49AM +0200, Andreas Enge wrote:
> Hello Leo,
> 
> some of the failures are due to missing sourceforge tarballs. I think
> we should merge master into core-updates and start a new evaluation.

Done. I also wrote a description of the conflicts I resolved in the
commit message. I think this is useful, since I've had difficulty
learning this information about other merges in the past.

Re: core-updates, next release, and all that

[Leo Famulari]

On Fri, Jul 22, 2016 at 10:46:16PM +, ng0 wrote:
> I still have the gnupg updates sitting here. Sorry that it took a
> bit longer, I had to figure out problems and solutions with
> another system and project.
> 
> >gnupg-2.1.14 requires libgcrypt >= 1.7.0 [0] and libgpg-error >= 1.24.
> >Those are both core packages.
> 
> Now that we are nearing completion of core, should I just wait or
> base them on -next?

The gnupg updates will require rebuilding almost everything. Right now,
we are trying to finish building a few final things. I think we should
put the gnupg updates on -next.

Re: core-updates, next release, and all that

[ng0]

Andreas Enge  writes:

> Hello Leo,
>
> some of the failures are due to missing sourceforge tarballs. I think
> we should merge master into core-updates and start a new evaluation.
>
> Andreas
>
>

I still have the gnupg updates sitting here. Sorry that it took a
bit longer, I had to figure out problems and solutions with
another system and project.

>gnupg-2.1.14 requires libgcrypt >= 1.7.0 [0] and libgpg-error >= 1.24.
>Those are both core packages.

Now that we are nearing completion of core, should I just wait or
base them on -next?
--
♥Ⓐ  ng0 – http://we.make.ritual.n0.is
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org

Re: core-updates, next release, and all that

[Leo Famulari]

On Sat, Jul 23, 2016 at 12:06:49AM +0200, Andreas Enge wrote:
> some of the failures are due to missing sourceforge tarballs. I think
> we should merge master into core-updates and start a new evaluation.

Okay, I will try the merge now.

Re: [PATCH] gnu: Add libsmpeg.

[Vincent Legoll]

> I see 2 solutions

The other solution could be to patch the setup.py script, if you
want to do that I'll tell you what to change

-- 
Vincent Legoll

Re: [PATCH] gnu: Add libsmpeg.

[Vincent Legoll]

> reply = raw_input('\n' + message + ' [Y/n]:')
> EOFError: EOF when reading a line

That setup.py is handcrafted, and is interactive. It asks a
question to the user and waits for a keypress in return.

And it looks like it is getting EOF instead of a keypress.

I see 2 solutions, either you find a way to answer its question,
I think I remember having seen some package that does this,
but cannot find it now. :-/

I think it was done with (display "Y" port) and port should be
the stdin of setup.py

You'll have to hunt that scm example.

hope that helps

-- 
Vincent Legoll

Re: core-updates, next release, and all that

[Andreas Enge]

Hello Leo,

some of the failures are due to missing sourceforge tarballs. I think
we should merge master into core-updates and start a new evaluation.

Andreas

Gs

[Andreas Enge]

Hello,

the following commit
commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
Author: Ludovic Courtès 
Date:   Mon May 9 15:54:34 2016 +0200

gnu: ghostscript: Do not build the statically-linked 'gs' binary.

* gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
'build-so' and 'install-so' phases.  Replace 'build' and 'install'
phases.

removes "gs" from the ghostscript package. However, this is the usual program
that people expect. For instance, unison uses it for building its
documentation. Is there a dynamically linked binary which replaces gs?
If yes, should we add a symbolic link?

If not, I would suggest to revert this commit.

Ceterum censeo that we should not optimise for size by sacrificing
functionality and ease of handling (cf. separate outputs).

Andreas

Re: core-updates, next release, and all that

[Leo Famulari]

On Fri, Jul 22, 2016 at 10:59:38PM +0200, Ludovic Courtès wrote:
>   polkit https://hydra.gnu.org/build/1287623

If I'm reading the Hydra web page correctly, this is a consequence of
the failure of mozjs-17 and a cached failure of the Shepherd.

Re: core-updates, next release, and all that

[Leo Famulari]

On Fri, Jul 22, 2016 at 10:59:38PM +0200, Ludovic Courtès wrote:
>   lpsolve https://hydra.gnu.org/build/1248528

>From the failing build log:

In unknown file:
   ?: 0 [copy-file "lpsolve55/bin/ux64/liblpsolve55.a" ...]

ERROR: In procedure copy-file:
ERROR: In procedure copy-file: No such file or directory

It's strange, because lpsolve is the same package on master and
core-updates, and I can build it from master. Did (copy-file) change?
Could there be some issue with the underlying operating system?

Or am I misreading the backtrace?

Re: core-updates, next release, and all that

[Leo Famulari]

On Fri, Jul 22, 2016 at 10:59:38PM +0200, Ludovic Courtès wrote:
> Critical things:
> 
>   mozjs https://hydra.gnu.org/build/1291842

Disabling parallel-builds worked for mozjs-24, which failed the same
way, so I pushed a similar change for mozjs-17.

Re: [PATCH 2/5] import: pypi: Remove setuptools from the inputs.

[Leo Famulari]

On Fri, Jul 22, 2016 at 11:24:52PM +0200, Ludovic Courtès wrote:
> Cyril Roelandt  skribis:
> 
> > * guix/import/pypi.scm (compute-inputs): remove python-setuptools from the
> > inputs.
> > * tests/pypi.scm ("pypi->guix-package", "pypi->guix-package, wheels"): 
> > Update
> > accordingly.
> 
> IIRC python-setuptools is needed for Python 2.x only, right?  I keep
> forgetting what the deal is.

In my experience, it is more often required for Python 2.x, but
sometimes it is required by Python 3.x packages, and sometimes not for
Python 2.x packages.

I'd be happy to get a more systematic explanation, or to be shown wrong.
A simple rule would be great :)

Re: [PATCH 5/5] import: pypi: Add more tests.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * tests/pypi.scm ("pypi->guix-package, no requirements", "pypi->guix-package,
> no test requirements", "pypi->guix-package, no runtime requirements"): New
> tests.

Perfect.  :-)

Thank you!

Ludo'.

Re: [PATCH 4/5] import: pypi: Compute test requirements when reading requirements files.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/import/pypi.scm (guess-requirement-from-source): Read
> test-requirements.txt as well as requirements.txt.
> * tests/pypi.scm ("pypi->guix-package"): Update accordingly.

[...]

>(let* ((req-file (string-append dirname "/requirements.txt"))
> - (exit-code (system* "tar" "xf" tarball req-file)))
> + (test-req-file (string-append dirname 
> "/test-requirements.txt"))
> + (exit-code (system* "tar" "xf" tarball req-file))
> + (test-exit-code (system* "tar" "xf" tarball test-req-file)))
>  ;; TODO: support more formats.
> -(if (zero? exit-code)
> +(if (or (zero? exit-code)
> +(zero? test-exit-code))

This seems to suggest that this could be factorized somehow.  Maybe
unpack once and read the two files at once?

Ludo’.

Re: [PATCH 3/5] import: pypi: Compute test requirements when using wheels.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/import/pypi.scm (read-wheel-metadata): Read test requirements from the
> metadata included in the wheel.
> * guix/import/pypi.scm (guess-requirement-from-source): Return an empty list
> for test requirements.
> * guix/import/pypi.scm (compute-inputs): Return both the runtime requirements
> and the test requirements.
> * guix/import.pypi.scm (make-pypi-sexp): Compute native inputs.
> * tests/pypi.scm ("pypi->guix-package, wheels"): Update accordingly.

[...]

>(requirements (if run_requires
>  (hash-ref (list-ref run_requires 
> 0)
> "requires")
> -'(
> - (map (lambda (r)
> -(python->package-name (clean-requirement r)))
> -  requirements)
> +'()))
> +  (test-requirements (if test_requires
> + (hash-ref (list-ref 
> test_requires 0)
> +"requires")
> + '(

Maybe for a subsequent patch: these two occurrences could be written as

  (match test_requires
((head _ ...)
 (hash-ref head "requires"))
(_
 '()))

LGTM, thanks!

Ludo’.

Re: [PATCH 2/5] import: pypi: Remove setuptools from the inputs.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/import/pypi.scm (compute-inputs): remove python-setuptools from the
> inputs.
> * tests/pypi.scm ("pypi->guix-package", "pypi->guix-package, wheels"): Update
> accordingly.

IIRC python-setuptools is needed for Python 2.x only, right?  I keep
forgetting what the deal is.

Ludo’.

Re: [PATCH 0/5] Improve the pypi updater.

[Ludovic Courtès]

Hello!

Cyril Roelandt  skribis:

> A couple of minor improvements, and a huge one: we should now be able to
> automatically compute the test requirements of our Python packages!

Neat!  So the test dependencies go to ‘inputs’ instead of
‘propagated-inputs’, right?  That can definitely save time and avoid
errors.

Is there an example package that illustrates this?

> * guix/import/pypi.scm (maybe-inputs): Pass INPUT-TYPE as a parameter.
> * guix/import/pypi.scm (make-pypi-sexp): Use this parameter.

Nitpick: no need to repeat the file name.

> * tests/pypi.scm ("pypi->guix-package", "pypi->guix-package, wheels"): Update
> accordingly.

LGTM!

Thanks,
Ludo’.

Re: none

[Leo Famulari]

On Fri, Jul 22, 2016 at 10:50:14PM +1000, Jookia wrote:
> On top of that, the maintainers can't even use the mailing list properly:
> Patches are lost, discussion doesn't happen, things are lost and it's hard for
> new users to join in. Who exactly benefits from this workflow compared to
> something web-based? Sure, maybe you could argue that the maintainers are best
> served with it, or that you personally are attuned to that. Fine, but let's 
> not
> pretend the mailing list isn't gruelling.

I've heard a handful of people express frustration with a mail-based
workflow. Here's what's easy for me:

1) I set up my mail provider / server to put all mail from
guix-devel@gnu.org into a Guix mailbox. This doesn't require advanced
knowledge. Even the most "user-friendly" solutions like GMail have this
feature.

2) When a message is "done", I put it in an Archive mailbox or delete
it. A message is done when it no longer requires attention. For example,
when I've replied and am waiting for the other person to reply, or when
a patch has been merged.

> It's a complicated setup in return for being able to track what's happening in
> the project. If I were to ask, 'how many patches are pending review' right now
> you'd have absolutely no idea.

I can look at my Guix mailbox to see all outstanding patches.

By the way, if someone asks the submitter to look into something or make
a change, the patch is no longer outstanding until they reply. The ball
is now in their court. I archive their message if I have nothing else to
add [0]. We all manage *our own submissions*. Nobody else is responsible
for that. Otherwise, we can't expect that the submitter will maintain
their code once it has been merged.

[0] Sometimes I don't archive messages, because I know that I will pick
up the work if the submitter drops it.

Re: [PATCH] gnu: Add libsmpeg.

[Kei Kebreau]

Vincent Legoll  writes:

>> Pygame's config.py is not finding smpeg-config. This will be fun! Anyone
>> with skill in Python is welcome to offer me assistance!
>
> Maybe I can help, could you elaborate on how to reproduce ?

Sure. Apply the libsmpeg patch and the attached Pygame patch to a copy
of the Guix repo and attempt to build python-pygame. The error is
contained in the build log. I'll copy it below:

starting phase `build'
running "python setup.py" with command "build" and parameters ()


WARNING, No "Setup" File Exists, Running "config.py"
Using UNIX configuration...

/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/sh: smpeg-config: c
ommand not found  

Hunting dependencies...
WARNING: "smpeg-config" failed!
SDL : found 1.2.15
FONT: not found
IMAGE   : not found
MIXER   : not found
SMPEG   : not found
PNG : not found
JPEG: not found
SCRAP   : found
PORTMIDI: not found
PORTTIME: not found


Warning, some of the pygame dependencies were not found. Pygame can still
compile and install, but games that depend on those missing dependencies
will not run. Would you like to continue the configuration? [Y/n]:Traceback (mo
st recent call last): 
  File "setup.py", line 132, in 
config.main()
  File "/tmp/guix-build-python-pygame-1.9.1.drv-0/pygame-1.9.1release/config.py
", line 137, in main  
deps = CFG.main()
  File "/tmp/guix-build-python-pygame-1.9.1.drv-0/pygame-1.9.1release/config_un
ix.py", line 180, in main 
will not run. Would you like to continue the configuration?"""):
  File "/tmp/guix-build-python-pygame-1.9.1.drv-0/pygame-1.9.1release/config_un
ix.py", line 24, in confirm   
reply = raw_input('\n' + message + ' [Y/n]:')
EOFError: EOF when reading a line
phase `build' failed after 0.8 seconds
builder for `/gnu/store/fgrm7ph1z050mldbzwg4s872373lqj1j-python-pygame-1.9.1.dr
v' failed with exit code 1
guix package: error: build failed: build of `/gnu/store/fgrm7ph1z050mldbzwg4s87
2373lqj1j-python-pygame-1.9.1.drv' failed 

From f15ce6a6050543ad6da623dd5758c114ec95fd60 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Fri, 22 Jul 2016 17:06:11 -0400
Subject: [PATCH] gnu: Add python-pygame.

* gnu/packages/game-development.scm (python-pygame): Add python-pygame.
---
 gnu/packages/game-development.scm | 44 ++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/game-development.scm 
b/gnu/packages/game-development.scm
index 7067a71..e3ecc79 100644
--- a/gnu/packages/game-development.scm
+++ b/gnu/packages/game-development.scm
@@ -31,6 +31,7 @@
   #:use-module (guix git-download)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system python)
   #:use-module (gnu packages)
   #:use-module (gnu packages curl)
   #:use-module (gnu packages databases)
@@ -41,6 +42,7 @@
   #:use-module (gnu packages gnunet)
   #:use-module (gnu packages guile)
   #:use-module (gnu packages multiprecision)
+  #:use-module (gnu packages music)
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages qt)
   #:use-module (gnu packages compression)
@@ -60,7 +62,8 @@
   #:use-module (gnu packages xiph)
   #:use-module (gnu packages lua)
   #:use-module (gnu packages mp3)
-  #:use-module (gnu packages xml))
+  #:use-module (gnu packages xml)
+  #:use-module (gnu packages video))
 
 (define-public bullet
   (package
@@ -512,3 +515,42 @@ It offers the following features:
 OpenGL programs with character rendering services via an application 
programming
 interface (API).")
 (license (list license:expat license:lgpl2.1+
+
+
+(define-public python-pygame
+  (package
+(name "python-pygame")
+(version "1.9.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://www.pygame.org/ftp/pygame-;
+  version "release.tar.gz"))
+  (sha256
+   (base32
+"0cyl0ww4fjlf289pjxa53q4klyn55ajvkgymw0qrdgp4593raq52"
+(build-system python-build-system)
+(inputs `(("libpng" ,libpng)
+  ("libjpeg" ,libjpeg)
+  ("libsmpeg" ,libsmpeg)
+  ("portmidi" ,portmidi)
+  ("sdl" ,sdl)
+  ("sdl-ttf" ,sdl-ttf)
+  ("sdl-image" ,sdl-image)
+  ("sdl-mixer" ,sdl-mixer)))
+(home-page "http://www.pygame.org;)
+(synopsis "Set of Python modules designed for writing games using SDL")
+(description
+ "Pygame is a cross-platform library designed to make it easy to write
+multimedia software, such as 

core-updates, next release, and all that

[Ludovic Courtès]

Hello Guix!

Time passes and we still have that ‘core-updates’ branch waiting to be
healed and merged.  It seems to be doing mostly OK:

  https://hydra.gnu.org/jobset/gnu/core-updates

with ~90 packages failing compared to master:

  https://hydra.gnu.org/eval/109012?compare=master

Critical things:

  mozjs https://hydra.gnu.org/build/1291842
  icecat https://hydra.gnu.org/build/1307245
  polkit https://hydra.gnu.org/build/1287623
  lpsolve https://hydra.gnu.org/build/1248528
  …

Leaf packages:

  lilypond https://hydra.gnu.org/build/1304657
  unison https://hydra.gnu.org/build/1305618
  node https://hydra.gnu.org/build/1306274
  vlc https://hydra.gnu.org/build/1304871
  …

턞 Join us now, 텞 fix the packages, you’ll be happy, hacker!  :-)

I think we should release 0.10.1 soon after that given all the
improvements and packages we’ve accumulated.  What do people think?

Ludo’.

Re: Customising linux-libre

[David Craven]

> PS: any chance you could easily switch to plain text for this list?
> It would make reading & replying just a bit more pleasant :-)

Sry, it's probably when I reply from my phone... I can't see anything
wrong [0] dough...

[0] http://lists.gnu.org/archive/html/guix-devel/2016-07/msg00969.html

Re: Customising linux-libre

[Tobias Geerinckx-Rice]

David,

On 2016-07-22 22:00, David Craven wrote:

I'm sure if you improve the linux-libre package to make it simpler
to customize we can annoy ludo until he merges it... =P


That's the plan! I just don't want to do the work only to hear (or
realise myself) ‘yeah, it should be like that, but x, so no’.

Kind regards,

T G-R

PS: any chance you could easily switch to plain text for this list?
It would make reading & replying just a bit more pleasant :-)

Re: [PATCH] gnu: wesnoth: Update to 1.12.6.

[Leo Famulari]

On Fri, Jul 22, 2016 at 01:11:21PM -0500, Alex Griffin wrote:
> * gnu/packages/games.scm (wesnoth): Update to 1.12.6.

Thanks, applied with 26ad4adb5!

Re: Customising linux-libre

[Tobias Geerinckx-Rice]

Vincent,

Thanks for the quick reply!

On 2016-07-22 21:58, Vincent Legoll wrote:

Does anyone know a reason why all the .config stuff couldn't be
moved to a separate 'configure-phase, before I waste my time? ;-)


There's a thread in help-guix that may be relevant:

https://lists.gnu.org/archive/html/help-guix/2016-07/msg00096.html


Yes, in the sense that Ludo's example from that thread was what
got me started. I hadn't expected it to be so easy.

What I actually meant was: why is everything up to ‘make oldconfig’
part of the build phase, and not a separate 'configure phase?

Kind regards,

T G-R

--
Sent from a web browser. Excuse my brevity.

Re: Customising linux-libre (was: [PATCH 4/4] environment: Add '--debug' flag.)

[Vincent Legoll]

On Fri, Jul 22, 2016 at 10:00 PM, David Craven  wrote:
> I'm sure if you improve the linux-libre package to make it simpler to
> customize we can annoy ludo until he merges it... =P

Maybe something like what I proposed here:
https://lists.gnu.org/archive/html/help-guix/2016-07/msg00122.html
would do what people want...

-- 
Vincent Legoll

Re: Customising linux-libre (was: [PATCH 4/4] environment: Add '--debug' flag.)

[David Craven]

I'm sure if you improve the linux-libre package to make it simpler to
customize we can annoy ludo until he merges it... =P
On Jul 22, 2016 9:58 PM, "Vincent Legoll"  wrote:

> > That's wonderfully trivial. It encouraged me to finally try porting
> > my old patched Linux kernel + custom configuration to the new GuixSD
> > installation. Now to find out why it silently fails after ‘make’...
> >
> > Hmm, seems like I'll be copying over the entire linux-libre
> > 'build-phase to poke at it a bit.
> >
> > Does anyone know a reason why all the .config stuff couldn't be
> > moved to a separate 'configure-phase, before I waste my time? ;-)
>
> There's a thread in help-guix that may be relevant:
>
> https://lists.gnu.org/archive/html/help-guix/2016-07/msg00096.html
>
> --
> Vincent Legoll
>

Re: Customising linux-libre (was: [PATCH 4/4] environment: Add '--debug' flag.)

[Vincent Legoll]

> That's wonderfully trivial. It encouraged me to finally try porting
> my old patched Linux kernel + custom configuration to the new GuixSD
> installation. Now to find out why it silently fails after ‘make’...
>
> Hmm, seems like I'll be copying over the entire linux-libre
> 'build-phase to poke at it a bit.
>
> Does anyone know a reason why all the .config stuff couldn't be
> moved to a separate 'configure-phase, before I waste my time? ;-)

There's a thread in help-guix that may be relevant:

https://lists.gnu.org/archive/html/help-guix/2016-07/msg00096.html

-- 
Vincent Legoll

Re: [PATCH] gnu: Add libsmpeg.

[Vincent Legoll]

> Pygame's config.py is not finding smpeg-config. This will be fun! Anyone
> with skill in Python is welcome to offer me assistance!

Maybe I can help, could you elaborate on how to reproduce ?

-- 
Vincent Legoll

Customising linux-libre (was: [PATCH 4/4] environment: Add '--debug' flag.)

[Tobias Geerinckx-Rice]

Danny,

Thank you!

On 2016-07-19 22:11, Danny Milosavljevic wrote:

~$ echo $GUIX_PACKAGE_PATH
/home/dannym/.local/guix
~/.local/guix/gnu/packages$ ls
patches/  pythonb.scm  pythonc.scm  rust.scm

The files look just like the ones in the guix git repo.


That's wonderfully trivial. It encouraged me to finally try porting
my old patched Linux kernel + custom configuration to the new GuixSD
installation. Now to find out why it silently fails after ‘make’...

Hmm, seems like I'll be copying over the entire linux-libre
'build-phase to poke at it a bit.

Does anyone know a reason why all the .config stuff couldn't be
moved to a separate 'configure-phase, before I waste my time? ;-)

Kind regards,

T G-R

Re: [PATCH] gnu: Add libsmpeg.

[Kei Kebreau]

Kei Kebreau  writes:

> This is a preliminary patch for pygame. I don't really have a test case
> for it outside of (hopefully) a successful build of pygame. We'll see
> how it goes.

Pygame's config.py is not finding smpeg-config. This will be fun! Anyone
with skill in Python is welcome to offer me assistance!

-- 
Kei (GPG Key: 4096R/E6A5EE3C19467A0D)


signature.asc
Description: PGP signature

Re: [PATCH 3/3] gnu: icedtea-6: Generate keystore.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> From: Ricardo Wurmus 
>>
>> * gnu/packages/java.scm (icedtea-6)[arguments]: Add phase
>> "install-keystore".
>> [native-inputs]: Add nss-certs and openssl.
>
> [...]
>
>> + (add-after 'install 'install-keystore
>> +   (lambda* (#:key inputs outputs #:allow-other-keys)
>
> Could you add a comment to explain what’s going on here?
>
> Too bad IceTea’s build system doesn’t take care of that.
>
>> + (let* ((keystore  "cacerts")
>> +(certs-dir (string-append (assoc-ref inputs "nss-certs")
>> +  "/etc/ssl/certs"))
>> +(keytool   (string-append (assoc-ref outputs "jdk")
>> +  "/bin/keytool"))
>> +(openssl   (which "openssl"))
>> +(recent(date->time-utc (string->date "2016-1-1"
>> + "~Y-~m-~d"
>> +   (define (valid? cert)
>> + (let* ((port (open-pipe* OPEN_READ openssl
>> +  "x509" "-enddate" "-in" cert 
>> "-noout"))
>> +(str  (read-line port))
>> +(end  (begin (close-pipe port)
>> + ;; TODO: use match?
>> + (cadr (string-split str #\=)
>
> Why not use ‘match’, indeed.  :-)  No big deal though.
>
>> +   (time>? (date->time-utc
>> +(string->date end "~b ~d ~H:~M:~S ~Y")) 
>> recent)))
>> +
>> +   (define (import-cert cert)
>> + (format #t "Importing certificate ~a\n" (basename cert))
>> + (let* ((port (open-pipe* OPEN_WRITE keytool
>> +  "-import"
>> +  "-alias" (basename cert)
>> +  "-keystore" keystore
>> +  "-storepass" "changeit"
>> +  "-file" cert)))
>> +   (display "yes\n" port)
>> +   (when (not (eqv? 0 (status:exit-val (close-pipe port
>
> Maybe (zero? (status:exit-val …)).
>
>> + (format (current-error-port)
>> + "Failed to import certificate.\n"
>
> Rather (error "failed to import" cert) so the process stops here.
>
>> +   ;; This is necessary because the certificate directory 
>> contains
>> +   ;; files with non-ASCII characters in their names.
>> +   (setlocale LC_ALL "en_US.utf8")
>> +   (setenv "LC_ALL" "en_US.utf8")
>> +
>> +   (for-each import-cert
>> + (filter valid? (find-files certs-dir "\\.pem$")))
>
> Why do we need to filter out invalid certificates?
>
> The problem I see is that the result of ‘valid?’, and thus the output of
> the build process, depends on the build time, which isn’t great.
>
> I would prefer to unconditionally install all the certificates if that
> doesn’t cause any problems.  WDYT?

I removed the validation (because I expect certs to be validated at
runtime).  I also added a comment explaining why this is needed and made
the suggested changes.

(I pushed from my workstation without signing key, because I forgot that
I normally push from my laptop.  Sorry, won’t happen again!  Key
replacement is on my list, and then I’ll get myself a subkey for the
office workstation.)

Thanks for the review!

~~ Ricardo

Re: gnu/system/u-boot.scm

[Danny Milosavljevic]

Hi,

On Fri, 22 Jul 2016 02:59:34 -0700
Chris Marusich  wrote:

> I'm not familiar with u-boot, but based on recent emails, it sounds like it's 
> important for getting GuixSD to run on ARM.

Yeah, because many ARM platforms don't have a BIOS (or any similar 
replacement), the bootloader has to do things you wouldn't believe. U-Boot has 
support for that.

There would be support for Grub as an U-Boot payload (in a fork), but I figured 
it's not really necessary [for now?] and complicates things too much - see how 
similar the U-Boot config body is to the Grub config body...

> I wonder if it would be possible to create a bootloader abstraction of
> some kind so that the installation mechanism can work with either u-boot
> or grub, without caring about which one it uses?  It would be nice if
> the installation mechanism were generic enough so that the same
> mechanism could be used to install either bootloader.

That would be nice. I'm not sure whether different bootloaders are similar in 
their installation mechanism, though. 

ARM platforms have... weird ways of booting - so getting all ARM boards to boot 
in the first place is difficult. Supporting those and Grub should be easy 
afterwards.

> > (define-record-type* 
> >   u-boot-configuration make-u-boot-configuration
> >   u-boot-configuration?
> >   (board   u-boot-configuration-board)   ; string ; not 
> > optional!
> >   (u-boot  u-boot-configuration-u-boot   ; package
> >(default (@ (gnu packages u-boot) (make-u-boot-package 
> > board
> >   (device  u-boot-configuration-device); string
> >   (menu-entriesu-boot-configuration-menu-entries   ; list
> >(default '()))
> >   (default-entry   u-boot-configuration-default-entry  ; integer
> >(default 0))
> >   (timeout u-boot-configuration-timeout; integer
> >(default 5)))  
> 
> This looks a little different from the grub-configuration record type
> (defined in guix/gnu/system/grub.scm).  

It should be very similar.

I added "board" and removed the theme stuff since it's unsupported. I don't 
think leaving the theme stuff in there would hurt either - it would just be 
ignored.

>How do you intend to integrate it with the existing bootloader installation 
>mechanism?

I have no idea yet. Have to read up on what's there first :)

[PATCH] gnu: wesnoth: Update to 1.12.6.

[Alex Griffin]

This patch just updates wesnoth to the latest version.
-- 
Alex Griffin
From 6c85b6054737f6d96d31eb8862c84bd429a16f3c Mon Sep 17 00:00:00 2001
From: Alex Griffin 
Date: Fri, 22 Jul 2016 13:09:01 -0500
Subject: [PATCH] gnu: wesnoth: Update to 1.12.6.

* gnu/packages/games.scm (wesnoth): Update to 1.12.6.
---
 gnu/packages/games.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 068b7d4..672d640 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -1023,7 +1023,7 @@ falling, themeable graphics and sounds, and replays.")
 (define-public wesnoth
   (package
 (name "wesnoth")
-(version "1.12.5")
+(version "1.12.6")
 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://sourceforge/wesnoth/wesnoth-"
@@ -1032,7 +1032,7 @@ falling, themeable graphics and sounds, and replays.")
   name "-" version ".tar.bz2"))
   (sha256
(base32
-"07d8ms9ayswg2g530p0zwmz3d77zv68l6nmc718iq9sbv90av6jr"
+"0kifp6g1dsr16m6ngjq2hx19h851fqg326ps3krnhpyix963h3x5"
 (build-system cmake-build-system)
 (arguments
  '(#:tests? #f ; no check target
-- 
2.9.1

[PATCH] download: Add official SourceForge mirror.

[Alex Griffin]

This patch mirrors a similar change in nixpkgs [1][2].

The official method for downloading from SourceForge is to use
downloads.sourceforge.net, which redirects to various other mirrors. It
can be unreliable, but also faster because it can find a nearby mirror
and load-balance. If it fails Guix will still fall back to known good
mirrors.

[1]: https://github.com/NixOS/nixpkgs/issues/16900
[2]: https://github.com/NixOS/nixpkgs/pull/16976
-- 
Alex Griffin
From 387f1116e6d6c8aa99e19a0ade3605300d59b0f9 Mon Sep 17 00:00:00 2001
From: Alex Griffin 
Date: Fri, 22 Jul 2016 12:55:47 -0500
Subject: [PATCH] download: Add official SourceForge mirror.

The official method for downloading from SourceForge is to use
downloads.sourceforge.net, which redirects to various other mirrors. It
can be unreliable, but also faster because it can find a nearby mirror
and load-balance. If it fails Guix will still fall back to known good
mirrors.

* guix/download.scm (mirrors)[sourceforge]: Add official SourceForge mirror.
---
 guix/download.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/guix/download.scm b/guix/download.scm
index 8f38a4f..aa403af 100644
--- a/guix/download.scm
+++ b/guix/download.scm
@@ -99,6 +99,7 @@
"http://www.centervenus.com/mirrors/nongnu/;
"http://download.savannah.gnu.org/releases-noredirect/;)
   (sourceforge ; https://sourceforge.net/p/forge/documentation/Mirrors/
+   "http://downloads.sourceforge.net/project/;
"http://ufpr.dl.sourceforge.net/project/;
"http://heanet.dl.sourceforge.net/project/;
"http://freefr.dl.sourceforge.net/project/;
-- 
2.9.1

Re: [PATCH 2/4] gnu: Rename 'glib' label to 'glib:bin' where appropriate.

[David Craven]

So I resubmitted the check-native-inputs patch and dropped the other
three based on the discussions.

[PATCH] lint: 'inputs-should-be-native' checks for intltool, itstool and glib:bin.

[David Craven]

* guix/scripts/lint.scm (check-inputs-should-be-native): Warn when intltool,
itstool or glib:bin isn't a native-input.
* tests/lint.scm (inputs: glib:bin is probably a native input): Add test.
---
 guix/scripts/lint.scm | 20 +---
 tests/lint.scm| 10 ++
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
index d5e9197..586ae88 100644
--- a/guix/scripts/lint.scm
+++ b/guix/scripts/lint.scm
@@ -203,14 +203,20 @@ by two spaces; possible infraction~p at ~{~a~^, ~}")
 (define (check-inputs-should-be-native package)
   ;; Emit a warning if some inputs of PACKAGE are likely to belong to its
   ;; native inputs.
-  (let ((inputs (package-inputs package)))
+  (let ((inputs (package-inputs package))
+(native-inputs '("pkg-config" "glib:bin" "intltool" "itstool")))
 (match inputs
-  (((labels packages . _) ...)
-   (when (member "pkg-config"
- (map package-name (filter package? packages)))
-(emit-warning package
-  (_ "pkg-config should probably be a native input")
-  'inputs))
+  (((labels packages . outputs) ...)
+(for-each (lambda (package output)
+  (when (package? package)
+(let ((input (string-append
+(package-name package)
+(if (> (length output) 0)
+  (string-append ":" (car output)) ""
+  (when (member input native-inputs)
+(emit-warning package
+  (string-append input " should probably be a native 
input"))
+packages outputs)
 
 (define (package-name-regexp package)
   "Return a regexp that matches PACKAGE's name as a word at the beginning of a
diff --git a/tests/lint.scm b/tests/lint.scm
index ce751c4..136a5a6 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -31,6 +31,7 @@
   #:use-module (guix scripts lint)
   #:use-module (guix ui)
   #:use-module (gnu packages)
+  #:use-module (gnu packages glib)
   #:use-module (gnu packages pkg-config)
   #:use-module (web server)
   #:use-module (web server http)
@@ -321,6 +322,15 @@ string) on HTTP requests."
  (check-inputs-should-be-native pkg)))
  "pkg-config should probably be a native input")))
 
+(test-assert "inputs: glib:bin is probably a native input"
+  (->bool
+(string-contains
+  (with-warnings
+(let ((pkg (dummy-package "x"
+ (inputs `(("glib" ,glib "bin"))
+  (check-inputs-should-be-native pkg)))
+  "glib:bin should probably be a native input")))
+
 (test-assert "patches: file names"
   (->bool
(string-contains
-- 
2.9.0

Re: [PATCH] gnu: maths: Fix expected hash of gnuplot tarball.

[Tomáš Čech]

Just ignore it, it seemed to me that Efraim forgot to send the patch
as we discussed on IRC but in fact my imap server was
dead and I haven't noticed that. Sorry :)

S_W

On Fri, Jul 22, 2016 at 06:57:43PM +0200, Tomáš Čech wrote:

* gnu/packages/maths.scm(gnuplot): Fix hash of downloaded tarball.

Upstream silently changed tarballs without changing version.

Diff of the tarball change:
diff -Naur gnuplot-5.0.4-old/docs/gnuplot.pdf gnuplot-5.0.4-new/docs/gnuplot.pdf
--- gnuplot-5.0.4-old/docs/gnuplot.pdf  2016-07-20 05:25:57.0 +0200
+++ gnuplot-5.0.4-new/docs/gnuplot.pdf  2016-07-21 17:47:10.0 +0200
@@ -11445,8 +11445,8 @@
endobj
6539 0 obj <<
/Author(gnuplot)/Title(gnuplot documentation)/Subject(see 
www.gnuplot.info)/Creator(LaTeX with hyperref 
package)/Producer(pdfTeX-1.40.14)/Keywords()
-/CreationDate (D:20160719202555-07'00')
-/ModDate (D:20160719202555-07'00')
+/CreationDate (D:20160721084708-07'00')
+/ModDate (D:20160721084708-07'00')
/Trapped /False
/PTEX.Fullbanner (This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 
2013/Mageia) kpathsea version 6.1.1)
>> endobj
@@ -11470,7 +11470,7 @@
/W [1 3 1]
/Root 6538 0 R
/Info 6539 0 R
-/ID [<7A30FAEBBA4B7F11C1CD6990B04692C4> <7A30FAEBBA4B7F11C1CD6990B04692C4>]
+/ID [<6898D2AAE33E85175B346EB9F8A7546B> <6898D2AAE33E85175B346EB9F8A7546B>]
/Length 16171
/Filter /FlateDecode
>>
diff -Naur gnuplot-5.0.4-old/ChangeLog gnuplot-5.0.4-new/ChangeLog
--- gnuplot-5.0.4-old/ChangeLog 2016-07-20 05:22:29.0 +0200
+++ gnuplot-5.0.4-new/ChangeLog 2016-07-21 17:45:11.0 +0200
@@ -1,3 +1,10 @@
+2016-07-21  Ethan A Merritt  
+
+   * src/term_api.h:  Define TERM_POLYGON_PIXELS.
+   * src/graphics.c (plot_image_or_update_axes):  If this flag is set,
+   implement "plot ... with image pixels" using term->filled_polygon()
+   rather than term->fillbox().
+
2016-07-19  Jun Takimoto 

* term/aquaterm.trm:  The AQUA_boxfill() routine scales very badly
diff -Naur gnuplot-5.0.4-old/src/graphics.c gnuplot-5.0.4-new/src/graphics.c
--- gnuplot-5.0.4-old/src/graphics.c2016-07-06 06:43:36.0 +0200
+++ gnuplot-5.0.4-new/src/graphics.c2016-07-21 17:43:44.0 +0200
@@ -4835,7 +4835,8 @@
corners[0].style = FS_TRANSPARENT_SOLID + 
(alpha<<4);
}

-   if (rectangular_image && term->fillbox) {
+   if (rectangular_image && term->fillbox
+   &&  !(term->flags & TERM_POLYGON_PIXELS)) {
/* Some terminals (canvas) can do filled rectangles 
*/
/* more efficiently than filled polygons. */
(*term->fillbox)( corners[0].style,
diff -Naur gnuplot-5.0.4-old/src/term_api.h gnuplot-5.0.4-new/src/term_api.h
--- gnuplot-5.0.4-old/src/term_api.h2016-01-19 00:51:59.0 +0100
+++ gnuplot-5.0.4-new/src/term_api.h2016-07-21 17:39:07.0 +0200
@@ -261,6 +261,7 @@
#define TERM_IS_LATEX(1<<13)  /* text uses TeX markup*/
#define TERM_EXTENDED_COLOR  (1<<14)  /* uses EXTENDED_COLOR_SPECS   */
#define TERM_NULL_SET_COLOR  (1<<15)  /* no support for RGB color*/
+#define TERM_POLYGON_PIXELS  (1<<16) /* filledpolygon rather than fillbox 
*/

/* The terminal interface structure --- heart of the terminal layer.
 *
diff -Naur gnuplot-5.0.4-old/src/version.c gnuplot-5.0.4-new/src/version.c
--- gnuplot-5.0.4-old/src/version.c 2016-07-20 05:23:21.0 +0200
+++ gnuplot-5.0.4-new/src/version.c 2016-07-21 17:50:12.0 +0200
@@ -44,7 +44,7 @@
#ifdef DEVELOPMENT_VERSION
#include "timestamp.h"
#else
-const char gnuplot_date[] = "2016-07-19 ";
+const char gnuplot_date[] = "2016-07-21 ";
#endif
const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2016";
---
gnu/packages/maths.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 9f780a0..86326f7 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -390,7 +390,7 @@ singular value problems.")
  version "/gnuplot-" version ".tar.gz"))
  (sha256
   (base32
-"08vpmhl85l48xcccx8jrkamalih2d6z9ppqpsppwii9y2l1p3297"
+"07n3w12dkcxjnhsvsliaqnkhajhi818v6q8mkpmpbplbf92vh70m"
(build-system gnu-build-system)
(inputs `(("readline" ,readline)
  ("cairo" ,cairo)
--
2.9.2




signature.asc
Description: Digital signature

curl releases and download - package location to add

[ng0]

Hello,

I'm one of the developers who maintain GNU Guix, the package
manager and its GNU System (GuixSD).

Through our package manager curl is available as sourcecode and
as binary substitute on all supported systems and architectures
which Guix supports at the moment:
https://hydra.gnu.org/job/gnu/master/curl-7.47.0.x86_64-linux
https://hydra.gnu.org/job/gnu/master/curl-7.47.0.i686-linux
https://hydra.gnu.org/job/gnu/master/curl-7.47.0.armhf-linux
https://hydra.gnu.org/job/gnu/master/curl-7.47.0.mips64el-linux

https://www.gnu.org/software/guix/packages/#curl is a link to the
static generated package list pointing to the curl entry.
At the same link (currently 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/curl.scm#n41)
you can find the current code for the package.

If you need more information about size, type, package name, or
any other specific details I left out we are happy to provide you
with input.

thanks,
-- 
♥Ⓐ  ng0 – http://we.make.ritual.n0.is
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org

[PATCH] gnu: maths: Fix expected hash of gnuplot tarball.

[Tomáš Čech]

* gnu/packages/maths.scm(gnuplot): Fix hash of downloaded tarball.

Upstream silently changed tarballs without changing version.

Diff of the tarball change:
diff -Naur gnuplot-5.0.4-old/docs/gnuplot.pdf gnuplot-5.0.4-new/docs/gnuplot.pdf
--- gnuplot-5.0.4-old/docs/gnuplot.pdf  2016-07-20 05:25:57.0 +0200
+++ gnuplot-5.0.4-new/docs/gnuplot.pdf  2016-07-21 17:47:10.0 +0200
@@ -11445,8 +11445,8 @@
 endobj
 6539 0 obj <<
 /Author(gnuplot)/Title(gnuplot documentation)/Subject(see 
www.gnuplot.info)/Creator(LaTeX with hyperref 
package)/Producer(pdfTeX-1.40.14)/Keywords()
-/CreationDate (D:20160719202555-07'00')
-/ModDate (D:20160719202555-07'00')
+/CreationDate (D:20160721084708-07'00')
+/ModDate (D:20160721084708-07'00')
 /Trapped /False
 /PTEX.Fullbanner (This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 
2013/Mageia) kpathsea version 6.1.1)
 >> endobj
@@ -11470,7 +11470,7 @@
 /W [1 3 1]
 /Root 6538 0 R
 /Info 6539 0 R
-/ID [<7A30FAEBBA4B7F11C1CD6990B04692C4> <7A30FAEBBA4B7F11C1CD6990B04692C4>]
+/ID [<6898D2AAE33E85175B346EB9F8A7546B> <6898D2AAE33E85175B346EB9F8A7546B>]
 /Length 16171
 /Filter /FlateDecode
 >>
diff -Naur gnuplot-5.0.4-old/ChangeLog gnuplot-5.0.4-new/ChangeLog
--- gnuplot-5.0.4-old/ChangeLog 2016-07-20 05:22:29.0 +0200
+++ gnuplot-5.0.4-new/ChangeLog 2016-07-21 17:45:11.0 +0200
@@ -1,3 +1,10 @@
+2016-07-21  Ethan A Merritt  
+
+   * src/term_api.h:  Define TERM_POLYGON_PIXELS.
+   * src/graphics.c (plot_image_or_update_axes):  If this flag is set,
+   implement "plot ... with image pixels" using term->filled_polygon()
+   rather than term->fillbox().
+
 2016-07-19  Jun Takimoto 

* term/aquaterm.trm:  The AQUA_boxfill() routine scales very badly
diff -Naur gnuplot-5.0.4-old/src/graphics.c gnuplot-5.0.4-new/src/graphics.c
--- gnuplot-5.0.4-old/src/graphics.c2016-07-06 06:43:36.0 +0200
+++ gnuplot-5.0.4-new/src/graphics.c2016-07-21 17:43:44.0 +0200
@@ -4835,7 +4835,8 @@
corners[0].style = FS_TRANSPARENT_SOLID + 
(alpha<<4);
}

-   if (rectangular_image && term->fillbox) {
+   if (rectangular_image && term->fillbox
+   &&  !(term->flags & TERM_POLYGON_PIXELS)) {
/* Some terminals (canvas) can do filled rectangles 
*/
/* more efficiently than filled polygons. */
(*term->fillbox)( corners[0].style,
diff -Naur gnuplot-5.0.4-old/src/term_api.h gnuplot-5.0.4-new/src/term_api.h
--- gnuplot-5.0.4-old/src/term_api.h2016-01-19 00:51:59.0 +0100
+++ gnuplot-5.0.4-new/src/term_api.h2016-07-21 17:39:07.0 +0200
@@ -261,6 +261,7 @@
 #define TERM_IS_LATEX(1<<13)   /* text uses TeX markup*/
 #define TERM_EXTENDED_COLOR  (1<<14)   /* uses EXTENDED_COLOR_SPECS   */
 #define TERM_NULL_SET_COLOR  (1<<15)   /* no support for RGB color*/
+#define TERM_POLYGON_PIXELS  (1<<16)   /* filledpolygon rather than fillbox */

 /* The terminal interface structure --- heart of the terminal layer.
  *
diff -Naur gnuplot-5.0.4-old/src/version.c gnuplot-5.0.4-new/src/version.c
--- gnuplot-5.0.4-old/src/version.c 2016-07-20 05:23:21.0 +0200
+++ gnuplot-5.0.4-new/src/version.c 2016-07-21 17:50:12.0 +0200
@@ -44,7 +44,7 @@
 #ifdef DEVELOPMENT_VERSION
 #include "timestamp.h"
 #else
-const char gnuplot_date[] = "2016-07-19 ";
+const char gnuplot_date[] = "2016-07-21 ";
 #endif
 const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2016";
---
 gnu/packages/maths.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 9f780a0..86326f7 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -390,7 +390,7 @@ singular value problems.")
   version "/gnuplot-" version ".tar.gz"))
   (sha256
(base32
-"08vpmhl85l48xcccx8jrkamalih2d6z9ppqpsppwii9y2l1p3297"
+"07n3w12dkcxjnhsvsliaqnkhajhi818v6q8mkpmpbplbf92vh70m"
 (build-system gnu-build-system)
 (inputs `(("readline" ,readline)
   ("cairo" ,cairo)
-- 
2.9.2

Re: none

[myglc2]

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

> Hi Roel,
>
> Roel Janssen  skribis:
>
[...]
>
>> One thing that really helped me in reducing the time to contribute
>> changes to the upstream distribution, is to have a good workflow.  I
>> ended up doing the following:
>> 1. Make the changes.
>> 2. Commit the changes.
>> 3 git format-patch -1 --no-attach
>> 4. git reset --hard 
>> 5. Submit the patch to the mailing list
>> 6. Wait for response and probably go back to 1.
>>
>> I made all of my changes on a GNU Guix git checkout.  So, not writing
>> package definitions on a separate repository.
>
> Do you think it would help to add this as a section in the manual?

This is a great idea!

Re: none

[Ludovic Courtès]

Hi Roel,

Roel Janssen  skribis:

> For the last twenty weeks or so I have started contributing packages to
> GNU Guix mainly because Pjotr gave me the opportunity to do so.  For me,
> upstreaming was part of the deal, and I'd say it has taken me at least
> two times the time it took me to write a proper package definition to
> get it in the upstream distribution.
>
> You've seen the mistakes I made, and the little syntactic things that
> kept going wrong over time.  Near the end of my internship, however, I
> saw a positive change: Reviewers actually make little changes, instead
> of leaving it up to the submitter to ``fix the indendation''.  This
> change makes the burden of reviewing smaller as well as the burden to
> submit a package.  Great!

Thanks for your feedback.

> One thing that really helped me in reducing the time to contribute
> changes to the upstream distribution, is to have a good workflow.  I
> ended up doing the following:
> 1. Make the changes.
> 2. Commit the changes.
> 3 git format-patch -1 --no-attach
> 4. git reset --hard 
> 5. Submit the patch to the mailing list
> 6. Wait for response and probably go back to 1.
>
> I made all of my changes on a GNU Guix git checkout.  So, not writing
> package definitions on a separate repository.

Do you think it would help to add this as a section in the manual?

>> But seriously, we should find other ways to encourage people. I wonder
>> how many packages are out there that never find their way into guix or
>> much too late. I wonder how much duplicate work is going on because of
>> our dance requirement. If it this hard *with* my experience in
>> packaging, how hard do you think it is for people *without*
>> experience. I know Dennis, for example, is sitting on a heap of opencl
>> packages which are incredibly useful to many people.
>>
>> I believe we have to change our ways.
>
> The problem is real.  I have taken contributing back to upstream _very_
> serious, and I haven't been able to get everything back into GNU Guix
> either.
>
> Packages I work(ed) on that haven't made it upstream (yet) due to
> ``imperfect'' patches:
> * MongoDB:Bundled source code;
> * GParted:The help function does not work without external
>   documentation database tool;

(I think it’s OK if GParted’s documentation isn’t available; that’s
probably the case for some other GNOME apps.)

> * FreeBayes:  At first, licensing issues, now just a plain ugly patch to
>   deal with the unbundling of its dependencies in the
>   Makefiles of this project;
> * VCFLib: Same situation as FreeBayes.  To be honest, this package
>   would've not ended up as a separate package if I didn't
>   have to split up FreeBayes.  I consider this a positive
>   effect of the review process.

Recursive bundling?  Woow.  :-)

Bundling is definitely a difficulty.  I still think there are good
reasons to unbundle software, but there are also a few exceptions in the
packages we provide.

It might be that VCFLib or the things in bundles have practically no
other user, in which case bundling makes absolutely no difference.

So I’m guessing these might be acceptable as-is.

> Maybe we could create an online course to do packaging with GNU Guix and
> make it rewarding with a grading system and giving achievement points..
> That might make the incentive to make the upstreaming step of packaging
> more fun and more like a learning process rather than a recurrent PITA.
> (This is something I could spend time at..)

Sure.  Concrete suggestions like this often help more than rants!  :-)

Thank you,
Ludo’.

Re: [PATCH] gnu: wxwidgets-2: Update to upstream's re-release of 2.8.12.

[Leo Famulari]

On Fri, Jul 22, 2016 at 03:59:48PM +0200, Jelle Licht wrote:
> * gnu/packages/wxwidgets.scm (wxwidgets-2): Add a guix revision number
>   to the version scheme of wxwidgets-2 to force an update.
> -   (uri (string-append "mirror://sourceforge/wxwindows/" version
> -   "/wxWidgets-" version ".tar.bz2"))
> -   (sha256
> -(base32 "1gjs9vfga60mk4j4ngiwsk9h6c7j22pw26m3asxr1jwvqbr8kkqk"

> + (uri (string-append "mirror://sourceforge/wxwindows/" 
> upstream-version
> + "/wxWidgets-" upstream-version ".tar.bz2"))
> + (sha256
> +  (base32 "01zp0h2rp031xn6nd8c4sr175fa4nzhwh08mhi8khs0ps39c22iv"

Without noticing, I changed the wxwidgets-2.8 URL from the following while
"fixing" changed SourceForge URLs recently:

mirror://sourceforge/wxwindows/wxGTK-" version ".tar.gz

Notice that the tarball name changed from 'wxGTK' to 'wxWidgets'.

So, upstream did not change the package in place. We started fetching
something else accidentally.

Which URL is correct?

Re: [PATCH] gnu: fish: Update to 2.3.1.

[Tobias Geerinckx-Rice]

Dave,

On 2016-07-22 14:47, Thompson, David wrote:

LGTM.


Thanks!


Do you have commit access?


Not at the moment, but some guy named Ludo' did just ask me for my
GPG key...

Kind regards,

T G-R

--
Sent from a web browser. Excuse my brevity.

Review process

[Ludovic Courtès]

Howdy,

Pjotr Prins  skribis:

> On Thu, Jul 21, 2016 at 02:51:38PM +0200, Ludovic Courtès wrote:
>> In
>> ,
>> you already identified exactly what we were going to say.  :-)
>> 
>> Namely, why are patches applied in a build phase rather than in
>> ‘origin’, why is such and such test disabled (one sentence is usually
>> enough), what happens if we set ‘HOME’ like Ben suggests, etc.
>> 
>> What should we do?  :-)
>
> I think I have covered that both in my writeup and in my response to
> Ben. I think this work should be accepted as is.

I find this unfair.  You are not a newcomer, as proved by the fact that
you’ve already identified weaknesses in the work you submit.

Thus, that you post it anyway can be understood as “I know this and that
should be done, but I’d rather let you do it on my behalf, kthxbye”.

Or perhaps you’re suggesting that reviews are unnecessary, or that the
points we insist on make little sense?

Well, I can tell you that as a user, I very much prefer that people who
add packages to the distro have taken their time to make it lean and
clean.  This QA work that you dislike is a service that we developers do
to users; it’s not something we do for the sake of elitism.

I hope this can clear misunderstandings!

Thanks for your feedback,
Ludo’.

Re: [PATCH] gnu: Add mono.

[Leo Famulari]

On Fri, Jul 15, 2016 at 09:32:43PM +0200, Jan Nieuwenhuizen wrote:
> Subject: [PATCH] gnu: Add mono.
> 
> * gnu/packages/mono.scm: New file.
> * gnu/packages/local.mk (GNU_SYSTEM_MODULES): Add it.

Thank you!

I assume this mono is working for you? I'm wondering if the problems
requiring skipped tests hide a larger problem or if it's benign.

Do you know if mono is supposed to work on all of our architectures? Or,
should we disable it on some of them?

> +  (snippet

Did you try doing these substitutions in a build phase? The origin
snippet affects what you get from `guix build --source mono`, so we tend
to reserve it for removing non-free components, so that we don't
distribute things that we don't have a right to distribute.

> +  ;; tests fail, trying to access $HOME
> +  (substitute* "mcs/class/Makefile"
> +(("^include ../build/rules.make" all)
> + (string-append
> +  all
> +  "\nrun-test-recursive:\n\t@echo skipping tests\n")))

After moving this into a build phase, there could be a prior phase
'set-env' that just sets $HOME to '/tmp'. Can you check if that works?

> +(build-system gnu-build-system)
> +(native-inputs
> + `(("gettext" ,gnu-gettext)
> +   ("glib" ,glib)

I notice many uses of glib:bin rather than the full glib output. But,
to be honest, I don't understand the distinction ;)

> + ;; these 3 tests fail
> + `(#:make-flags
> +   `(,(string-append "PLATFORM_DISABLED_TESTS="
> + " appdomain-unload.exe"
> + " delegate2.exe"
> + " finally_guard.exe"
> + " remoting4.exe"))

4 tests?

> +   #:parallel-tests? #f))

Parallel testing is not supported? Let's add a comment.

> +(home-page "http://mono-project.org/;)

s/org/com/

Re: More SourceForge package problems

[Leo Famulari]

On Fri, Jul 22, 2016 at 11:04:42AM -0400, Leo Famulari wrote:
> There are still some packages that can't download source code at all:
> 
> utfcpp
> slim (found on tarballs.nixos.org)
> lxtask
> lxappearance
> lxrandr
> libfm
> lxterminal
> menu-cache
> pcmanfm
> libmng
> gtkglext
> freeglut (tarballs.nixos.org)
> ftgl (tarballs.nixos.org)
> terminus-font (tarballs.nixos.org)
> libmodplug (tarballs.nixos.org)

These all had URLs like 'http://sourceforge.net/project/foo'. We
recently added the 'project/' part to our mirrors, so they ended up with
duplicate 'project/project/'.

Fixed in 0f971a0475.

Re: Seeking guidance regarding system roll-back and switch-generation

[Ludovic Courtès]

Hi!

Chris Marusich  skribis:

> Thank you very much for taking the time to respond!  Now I have a better
> idea of how to proceed.

Sorry for the delay!  That’s what you get for asking difficult
questions.  ;-)

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Chris Marusich  skribis:
>>
>>> I've noticed that the GuixSD mechanism is different from the NixOS
>>> mechanism.  In particular, NixOS uses an "install-grub" script (which is
>>> specific to each system generation) to install grub, but GuixSD does
>>> not.  Is this difference intentional?
>>
>> Looking at
>> ,
>> part of it seems to be concerned with the generation of grub.cfg, which
>> is what (gnu system grub) does.
>>
>> It also does a couple more things, such as providing proper EFI support,
>> and avoiding reinstalling GRUB when possible (whereas ‘guix system
>> reconfigure’ currently reruns ‘grub-install’ each time, even when it’s
>> not strictly needed.)
>>
>> So I don’t think it’s very different, after all.  Or am I missing
>> something?
>
> Yes, they both install grub, but the mechanism seems different.  NixOS
> generates a script for each system generation, which installs exactly
> the right grub for that generation.  Unless I'm mistaken, GuixSD does
> not do that.  Instead, the existing GuixSD mechanism seems to require an
> operating system configuration file.  GuixSD uses that to determine the
> correct grub, which it then installs.

Sure, but it seems to be equivalent in the end.

>> Switching to a generations primarily means: (1) running the target’s
>> activation script, (2) updating Shepherd services, and (3) updating
>> grub.cfg.
>
> In addition to (3), don't we also need to install the grub software
> itself?

In general yes (there are cases where this is not needed, but let’s
ignore them.)

>> Of these (1) and (3) are currently easy to do on GuixSD.  (Right? :-))
>
> For both (1) and (3), the current GuixSD mechanism appears to require an
> operating system configuration file.

The output of ‘guix system build’ contains the ‘parameters’ file, which
is enough to generate grub.cfg (see ‘previous-grub-entries’ in (guix
scripts system)).

However, the activation script is indeed missing.  We can add it to the
output of ‘guix system build’ by extending ‘system-service-type’:

diff --git a/gnu/services.scm b/gnu/services.scm
index 5479bfa..fc3e17e 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -352,11 +352,18 @@ ACTIVATION-SCRIPT-TYPE."
 
 (define (second-argument a b) b)
 
+(define (gexps->activation-system-entry gexps)
+  "Return a directory entry to add to the result of the 'system' derivation."
+  (mlet %store-monad ((script (activation-script gexps)))
+(return `(("activate" ,script)
+
 (define activation-service-type
   (service-type (name 'activate)
 (extensions
  (list (service-extension boot-service-type
-  gexps->activation-gexp)))
+  gexps->activation-gexp)
+   (service-extension system-service-type
+  gexps->activation-system-entry)))
 (compose append)
 (extend second-argument)))
 

This way we have direct access to each generation’s activation script
and we should be fine with (3).

WDYT?

> Yes, I think that makes sense.  I need to learn more about GuixSD's
> activation mechanism, but it makes sense that a procedural definition
> (e.g., like in NixOS's switch-to-configuration script) is equivalent to
> a declarative definition.  I think a declarative definition of services
> would be fine.  Concretely speaking, is there a specific format that is
> convenient to use for such a "declarative definition of services"?

I would suggest an sexp as discussed at:

  https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00173.html

> What about the grub installation?

The ‘parameters’ file should be enough, as you wrote.

HTH!

Ludo’.

More SourceForge package problems

[Leo Famulari]

These packages have been "updated in place". That is, our URLs do fetch
something with the given version string, but the hash is wrong.

wxwidgets-2.8
gnuplot
pardre

We have to audit the differences before updating these packages with new
hashes.

There are still some packages that can't download source code at all:

utfcpp
slim (found on tarballs.nixos.org)
lxtask
lxappearance
lxrandr
libfm
lxterminal
menu-cache
pcmanfm
libmng
gtkglext
freeglut (tarballs.nixos.org)
ftgl (tarballs.nixos.org)
terminus-font (tarballs.nixos.org)
libmodplug (tarballs.nixos.org)

[PATCH] gnu: Add libsmpeg.

[Kei Kebreau]

This is a preliminary patch for pygame. I don't really have a test case
for it outside of (hopefully) a successful build of pygame. We'll see
how it goes.

From fa92b4e1fd08b19ad2427121b57a5a61ea798aca Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Fri, 22 Jul 2016 10:20:10 -0400
Subject: [PATCH] gnu: Add libsmpeg.

* gnu/packages/video.scm (libsmpeg): New variable.
---
 gnu/packages/video.scm | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
index d36400c..943ff26 100644
--- a/gnu/packages/video.scm
+++ b/gnu/packages/video.scm
@@ -8,6 +8,7 @@
 ;;; Copyright © 2015 Ricardo Wurmus 
 ;;; Copyright © 2015 Alex Vong 
 ;;; Copyright © 2016 Alex Griffin 
+;;; Copyright © 2016 Kei Kebreau 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -33,6 +34,7 @@
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix git-download)
+  #:use-module (guix svn-download)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system glib-or-gtk)
@@ -1525,3 +1527,39 @@ implementation.")
 your graphical desktop and encodes it as a video.  This is a useful tool for
 making @dfn{screencasts}.")
 (license license:gpl2+)))
+
+(define-public libsmpeg
+  (package
+(name "libsmpeg")
+(version "0.4.5")
+(source (origin
+  (method svn-fetch)
+  (uri (svn-reference
+(url "svn://svn.icculus.org/smpeg/trunk/")
+(revision 412)))
+  (sha256
+   (base32
+"1irf2d8f150j8cx8lbb0pz1rijap536crsz0mw871xrh6wd2fd96"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases (modify-phases %standard-phases
+  (add-after 'unpack 'autogen.sh
+(lambda _
+  (zero? (system* "sh" "autogen.sh")))
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("automake" ,automake)))
+(inputs
+ `(("sdl" ,sdl2)))
+(home-page "http://icculus.org/smpeg/;)
+(synopsis "SDL MPEG decoding library")
+(description
+ "SMPEG (SDL MPEG Player Library) is a free MPEG1 video player library
+with sound support.  Video playback is based on the ubiquitous Berkeley MPEG
+player, mpeg_play v2.2.  Audio is played through a slightly modified mpegsound
+library, part of splay v0.8.2.  SMPEG supports MPEG audio (MP3), MPEG-1 video,
+and MPEG system streams.")
+(license (list license:expat
+   license:lgpl2.1
+   license:lgpl2.1+
+   license:gpl2
-- 
2.9.1

-- 
Kei (GPG Key: 4096R/E6A5EE3C19467A0D)


signature.asc
Description: PGP signature

Re: none

[Vincent Legoll]

On Fri, Jul 22, 2016 at 4:07 PM, Leo Famulari  wrote:
>> You've seen the mistakes I made, and the little syntactic things that
>> kept going wrong over time.  Near the end of my internship, however, I
>> saw a positive change: Reviewers actually make little changes, instead
>> of leaving it up to the submitter to ``fix the indendation''.  This
>> change makes the burden of reviewing smaller as well as the burden to
>> submit a package.  Great!
>
> That's good. I think there is some value in asking submitters to correct
> even small issues, so that they have a chance to learn. But, the faster
> method is for the reviewer to make the correction themselves, and then
> explain the difference. If there are many minor changes, the reviewer
> can attach a diff to their reply.

That's a matter of taste, I prefer being told that my contribution is not good
enough and then fix it myself, but that's because I'm not doing a lot...

If the maintainer wants to do additional changes, I also prefer he does it in
a separate patch/commit, as that would enable me to git pull --ff instead of
merge...

my .02€

-- 
Vincent Legoll

Re: Installing incompatible major versions of packages alongside each other

[Leo Famulari]

On Fri, Jul 22, 2016 at 03:02:10PM +0200, Ludovic Courtès wrote:
> > For example right now I can't install icedtea-7: "guix package: error: 
> > icedtea: package not found for version 7"
> 
> There’s no version 7, but there are other versions available:
> 
> --8<---cut here---start->8---
> $ guix package -A icedtea
> icedtea   1.13.11 out,jdk,doc gnu/packages/java.scm:196:2
> icedtea   2.6.6   out,jdk,doc gnu/packages/java.scm:598:4
> icedtea   3.0.1   out,jdk,doc gnu/packages/java.scm:768:4
> --8<---cut here---end--->8---

To clarify a little more, icedtea@1 corresponds to Java 6, icedtea@2 to
Java 7, and icedtea@3 to Java 8.

Re: [PATCH] gnu: Add elixir.

[Leo Famulari]

On Fri, Jul 22, 2016 at 02:55:55PM +0200, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > On Thu, Jul 21, 2016 at 09:43:57PM +1000, Ben Woodcroft wrote:
> >> On 21/07/16 11:42, Pjotr Prins wrote:
> >> > Sorry for the new thread. But this time the patch is readable from all
> >> > mailers (supporting UTF8). Please comment.
> >> 
> >> Maybe to fix the $HOME issues by including a phase to set environment
> >> variables during testing as in e.g. blast+ ? i.e.
> >> 
> >> (setenv "HOME" "/tmp")
> >
> > The test passes when run with this variable set, as attached.
> 
> Not attached.  :-)

I'd forget my head if it wasn't already attached ;)
>From 3f9ce99471d94422d3e74e2d67815e924b06974d Mon Sep 17 00:00:00 2001
From: Pjotr Prins 
Date: Thu, 21 Jul 2016 03:39:03 +0200
Subject: [PATCH] gnu: Add elixir.

* gnu/packages/elixir.scm,
gnu/packages/patches/elixir-disable-failing-tests.patch,
gnu/packages/patches/elixir-disable-mix-tests.patch: New files.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add package module.
(dist_patch_DATA): Add patches.

Signed-off-by: Leo Famulari 
---
 gnu/local.mk   |   5 +-
 gnu/packages/elixir.scm|  91 
 .../patches/elixir-disable-failing-tests.patch |  90 
 .../patches/elixir-disable-mix-tests.patch | 152 +
 4 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/elixir.scm
 create mode 100644 gnu/packages/patches/elixir-disable-failing-tests.patch
 create mode 100644 gnu/packages/patches/elixir-disable-mix-tests.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 31a4d58..8637a04 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -104,6 +104,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/ebook.scm			\
   %D%/packages/ed.scm\
   %D%/packages/elf.scm\
+  %D%/packages/elixir.scm			\
   %D%/packages/emacs.scm			\
   %D%/packages/enchant.scm			\
   %D%/packages/engineering.scm			\
@@ -478,8 +479,10 @@ dist_patch_DATA =		\
   %D%/packages/patches/doxygen-test.patch			\
   %D%/packages/patches/duplicity-piped-password.patch		\
   %D%/packages/patches/duplicity-test_selection-tmp.patch	\
-  %D%/packages/patches/elfutils-tests-ptrace.patch		\
   %D%/packages/patches/einstein-build.patch			\
+  %D%/packages/patches/elfutils-tests-ptrace.patch		\
+  %D%/packages/patches/elixir-disable-failing-tests.patch	\
+  %D%/packages/patches/elixir-disable-mix-tests.patch		\
   %D%/packages/patches/emacs-exec-path.patch			\
   %D%/packages/patches/emacs-fix-scheme-indent-function.patch	\
   %D%/packages/patches/emacs-scheme-complete-scheme-r5rs-info.patch	\
diff --git a/gnu/packages/elixir.scm b/gnu/packages/elixir.scm
new file mode 100644
index 000..873d0c2
--- /dev/null
+++ b/gnu/packages/elixir.scm
@@ -0,0 +1,91 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Leo Famulari 
+;;; Copyright © 2016 Pjotr Prins 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages elixir)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix download)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages base)  ; for patch
+  #:use-module (gnu packages erlang)
+  #:use-module (gnu packages version-control))
+
+(define-public elixir
+  (package
+   (name "elixir")
+   (version "1.3.2")
+   (source (origin
+(method url-fetch)
+(uri (string-append
+  "https://github.com/elixir-lang/elixir/archive/v;
+  version ".tar.gz"))
+(file-name (string-append name "-" version ".tar.gz"))
+(sha256
+ (base32
+  "0jsc6kl7f74yszcypdv3w3vhyc9qfqav8nwc41in082m0vpfy95y"
+   (build-system gnu-build-system)
+   (native-inputs
+`(("patch" ,patch)
+  ("patch/elixir-disable-failing-tests"
+   ,(search-patch "elixir-disable-failing-tests.patch"))
+  ("patch/elixir-disable-mix-tests"
+   ,(search-patch "elixir-disable-mix-tests.patch"
+   (inputs
+`(("erlang" ,erlang)
+  ("git" ,git)))
+   (arguments
+`(#:phases (modify-phases %standard-phases
+

Re: [PATCH] gnu: wxwidgets-2: Update to upstream's re-release of 2.8.12.

[Vincent Legoll]

On Fri, Jul 22, 2016 at 4:01 PM, Jelle Licht  wrote:
> packages on SourceForge that have been changed in place.

They have a past history of doing "interesting" things to binary
packages they host... I hope that's not a new batch of those...

-- 
Vincent Legoll

Re: [PATCH 1/4] lint: Add packages with suffix ':bin' to 'inputs-should-be-native'.

[Vincent Legoll]

> That’ll happen, someday, but even then, I’m not sure we’ll remove
> labels; at least we won’t remove them overnight, for sure.  ;-)

That may be a good fit for a guix lint warning, maybe first as a
--pedantic mode, then after the first rush of newbies-editing-the-world,
it can be turned into --Werror...

-- 
Vincent Legoll

Re: none

[Leo Famulari]

> You've seen the mistakes I made, and the little syntactic things that
> kept going wrong over time.  Near the end of my internship, however, I
> saw a positive change: Reviewers actually make little changes, instead
> of leaving it up to the submitter to ``fix the indendation''.  This
> change makes the burden of reviewing smaller as well as the burden to
> submit a package.  Great!

That's good. I think there is some value in asking submitters to correct
even small issues, so that they have a chance to learn. But, the faster
method is for the reviewer to make the correction themselves, and then
explain the difference. If there are many minor changes, the reviewer
can attach a diff to their reply.

Re: [PATCH] gnu: wxwidgets-2: Update to upstream's re-release of 2.8.12.

[Jelle Licht]

Hello guix,

Shamelessly stole most of this from Efraim, as wxwidgets had the same
problem.

Lets hope that it's just a couple of packages on SourceForge that have been
changed in place.


Jelle

2016-07-22 15:59 GMT+02:00 Jelle Licht :

> * gnu/packages/wxwidgets.scm (wxwidgets-2): Add a guix revision number
>   to the version scheme of wxwidgets-2 to force an update.
> ---
>  gnu/packages/wxwidgets.scm | 54
> +-
>  1 file changed, 29 insertions(+), 25 deletions(-)
>
> diff --git a/gnu/packages/wxwidgets.scm b/gnu/packages/wxwidgets.scm
> index c9eb178..f4866e1 100644
> --- a/gnu/packages/wxwidgets.scm
> +++ b/gnu/packages/wxwidgets.scm
> @@ -81,29 +81,33 @@ a graphical user interface.  It has language bindings
> for Python, Perl, Ruby
>  and many other languages.")
>  (license (list l:lgpl2.0+ (l:fsf-free "file://doc/license.txt")
>
> +;; wxwidgets version 2.8.12 was updated in-place, resulting in a hash
> +;; mismatch. This can be removed at the next version update.
>  (define-public wxwidgets-2
> -  (package
> -(inherit wxwidgets)
> -(version "2.8.12")
> -(source
> - (origin
> -   (method url-fetch)
> -   (uri (string-append "mirror://sourceforge/wxwindows/" version
> -   "/wxWidgets-" version ".tar.bz2"))
> -   (sha256
> -(base32 "1gjs9vfga60mk4j4ngiwsk9h6c7j22pw26m3asxr1jwvqbr8kkqk"
> -(inputs
> - `(("gtk" ,gtk+-2)
> -   ("libjpeg" ,libjpeg)
> -   ("libtiff" ,libtiff)
> -   ("libmspack" ,libmspack)
> -   ("sdl" ,sdl)
> -   ("unixodbc" ,unixodbc)))
> -(arguments
> - `(#:configure-flags
> -   '("--enable-unicode" "--with-regex=sys" "--with-sdl")
> -   #:make-flags
> -   (list (string-append "LDFLAGS=-Wl,-rpath="
> -(assoc-ref %outputs "out") "/lib"))
> -   ;; No 'check' target.
> -   #:tests? #f
> +  (let ((upstream-version "2.8.12")
> +(guix-revision "1"))
> +(package
> +  (inherit wxwidgets)
> +  (version (string-append upstream-version "-" guix-revision))
> +  (source
> +   (origin
> + (method url-fetch)
> + (uri (string-append "mirror://sourceforge/wxwindows/"
> upstream-version
> + "/wxWidgets-" upstream-version ".tar.bz2"))
> + (sha256
> +  (base32
> "01zp0h2rp031xn6nd8c4sr175fa4nzhwh08mhi8khs0ps39c22iv"
> +  (inputs
> +   `(("gtk" ,gtk+-2)
> + ("libjpeg" ,libjpeg)
> + ("libtiff" ,libtiff)
> + ("libmspack" ,libmspack)
> + ("sdl" ,sdl)
> + ("unixodbc" ,unixodbc)))
> +  (arguments
> +   `(#:configure-flags
> + '("--enable-unicode" "--with-regex=sys" "--with-sdl")
> + #:make-flags
> + (list (string-append "LDFLAGS=-Wl,-rpath="
> +  (assoc-ref %outputs "out") "/lib"))
> + ;; No 'check' target.
> + #:tests? #f)
> --
> 2.9.1
>
>

[PATCH] gnu: wxwidgets-2: Update to upstream's re-release of 2.8.12.

[Jelle Licht]

* gnu/packages/wxwidgets.scm (wxwidgets-2): Add a guix revision number
  to the version scheme of wxwidgets-2 to force an update.
---
 gnu/packages/wxwidgets.scm | 54 +-
 1 file changed, 29 insertions(+), 25 deletions(-)

diff --git a/gnu/packages/wxwidgets.scm b/gnu/packages/wxwidgets.scm
index c9eb178..f4866e1 100644
--- a/gnu/packages/wxwidgets.scm
+++ b/gnu/packages/wxwidgets.scm
@@ -81,29 +81,33 @@ a graphical user interface.  It has language bindings for 
Python, Perl, Ruby
 and many other languages.")
 (license (list l:lgpl2.0+ (l:fsf-free "file://doc/license.txt")
 
+;; wxwidgets version 2.8.12 was updated in-place, resulting in a hash
+;; mismatch. This can be removed at the next version update.
 (define-public wxwidgets-2
-  (package
-(inherit wxwidgets)
-(version "2.8.12")
-(source
- (origin
-   (method url-fetch)
-   (uri (string-append "mirror://sourceforge/wxwindows/" version
-   "/wxWidgets-" version ".tar.bz2"))
-   (sha256
-(base32 "1gjs9vfga60mk4j4ngiwsk9h6c7j22pw26m3asxr1jwvqbr8kkqk"
-(inputs
- `(("gtk" ,gtk+-2)
-   ("libjpeg" ,libjpeg)
-   ("libtiff" ,libtiff)
-   ("libmspack" ,libmspack)
-   ("sdl" ,sdl)
-   ("unixodbc" ,unixodbc)))
-(arguments
- `(#:configure-flags
-   '("--enable-unicode" "--with-regex=sys" "--with-sdl")
-   #:make-flags
-   (list (string-append "LDFLAGS=-Wl,-rpath="
-(assoc-ref %outputs "out") "/lib"))
-   ;; No 'check' target.
-   #:tests? #f
+  (let ((upstream-version "2.8.12")
+(guix-revision "1"))
+(package
+  (inherit wxwidgets)
+  (version (string-append upstream-version "-" guix-revision))
+  (source
+   (origin
+ (method url-fetch)
+ (uri (string-append "mirror://sourceforge/wxwindows/" upstream-version
+ "/wxWidgets-" upstream-version ".tar.bz2"))
+ (sha256
+  (base32 "01zp0h2rp031xn6nd8c4sr175fa4nzhwh08mhi8khs0ps39c22iv"
+  (inputs
+   `(("gtk" ,gtk+-2)
+ ("libjpeg" ,libjpeg)
+ ("libtiff" ,libtiff)
+ ("libmspack" ,libmspack)
+ ("sdl" ,sdl)
+ ("unixodbc" ,unixodbc)))
+  (arguments
+   `(#:configure-flags
+ '("--enable-unicode" "--with-regex=sys" "--with-sdl")
+ #:make-flags
+ (list (string-append "LDFLAGS=-Wl,-rpath="
+  (assoc-ref %outputs "out") "/lib"))
+ ;; No 'check' target.
+ #:tests? #f)
-- 
2.9.1

Re: [PATCH 1/4] lint: Add packages with suffix ':bin' to 'inputs-should-be-native'.

[Ludovic Courtès]

Tobias Geerinckx-Rice  skribis:

> On 2016-07-21 18:06, l...@gnu.org wrote:
   (inputs `(("somethingsilly" ,glib "bin")))
>>
>> This "somethingsilly" is just a label that allows you to refer to an
>> input on the build side, in idioms like:
>>
>>   (assoc-ref inputs "somethingsilly")
>>   => "/gnu/store/…-glib-42.0-bin"
>
> I remember writing something like
>
>   (inputs `(("libuuid" ,util-linux)))
>
> once, to indicate that libuuid really is all we need and that one
> could swap out util-linux for another — extremely hypothetical —
> libuuid provider.
>
> Was this, in hindsight, somethingsilly? :-)

I think it’s fine, but a comment would work well too.

> If so, is there still a reason to keep all this duplication around?

Build systems haven’t migrated yet to gexps.  There’s a branch to do
that, ‘wip-build-systems-gexp’, but there’s a performance regression
compared to what we have, which is why I have not merged it.

That’ll happen, someday, but even then, I’m not sure we’ll remove
labels; at least we won’t remove them overnight, for sure.  ;-)

>> This predates g-expressions, which solve this problem more elegantly.
>
> Interesting! I always assumed[1] gexps were one of the foundations for
> Guix since day 0.

In an ideal world it would have been this way.  :-)

Ludo’.

Re: [PATCH 3/3] doc: Note on inclusive language for documentation.

[Ludovic Courtès]

I pushed something along these lines as
3c2d03a2b91a085b94c66e7810f358988538d1e4.

Thanks,
Ludo’.

Re: [PATCH] Add gnu/packages/u-boot.scm with all the boards that u-boot supports right now

[Ludovic Courtès]

Danny Milosavljevic  skribis:

>> This note should go to the top of the .patch file, along with one or two
>> sentences explaining what it does and why we need it.
>
> OK, will do that.

Great.

>> In that case, I’d suggest writing a procedure like:
>> 
>>   (define (make-u-boot-package board)
>> (package
>>   (inherit u-boot)
>>   (name (string-append "u-boot-" (string-downcase board)))
>>   (arguments
>> ;; … pass the right configure flags etc.
>> )))
>> 
>> Then it’s probably enough to export ‘u-boot’ and ‘make-u-boot’—having a
>> zillion variables doesn’t seem very helpful.  People can explicitly call
>> ‘make-u-boot’ with the right board name
>
> Yeah, sounds much nicer. 
>
> How do I test this? How can I call it?

For test purposes, you could define a package variant and try to build
it:

  (define-public u-boot-FOOBAR
(make-u-boot "FOOBAR"))

and:

  guix build u-boot-foobar

HTH!

Ludo’.

Re: [PATCH v2] gnu: Add lrzip.

[Ludovic Courtès]

Hi Tobias,

Tobias Geerinckx-Rice  skribis:

> On 2016-07-21 22:24, Tobias Geerinckx-Rice wrote:
>> +(native-inputs
>> + `(,@(if (string-prefix? "i686" (or (%current-target-system)
>> +(%current-system)))
>> + `(("nasm" ,nasm))
>> + '())
>
> Hmm. Not sure where this falls on the ‘let the code speak for itself’
> to ‘should have added a comment’ scale.
>
> Guess I'll wait for another review + patch or a very friendly committer.

I have another idea: could you create a Savannah account and tell me
your user name?  :-)

Thanks,
Ludo’.

Re: [PATCH v2] gnu: Add ptpython, ptpython-2.

[Ludovic Courtès]

Danny Milosavljevic  skribis:

> * gnu/packages/python.scm (ptpython, ptpython-2): New variables.

[...]

> +  (name "ptpython-2"

I changed this to “ptpython2” as discussed and applied with minor
indentation changes.

Thank you!

Ludo’.

Re: [PATCH 2/4] gnu: Rename 'glib' label to 'glib:bin' where appropriate.

[David Craven]

The reason I renamed them was to be able to check for :bin in the
label. I already dropped this patch from my fork, since we decided to
take a different approach.

I'll update the other patch, still working on it... (Need to read up
on how pattern matching works in scheme etc.)

Re: Installing incompatible major versions of packages alongside each other

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

>> In the former command-line package specification syntax, which is still
>> supported but deprecated, “ptpython-2” was taken to mean “version 2 of
>> package ‘ptpython’”.  Because of this, you cannot refer to this
>> “ptpython-2” package from the command-line (except with -e).
>> 
>> The solution is to call it differently, like “ptpython2”.
>
> Hmm, it doesn't seem as if Guix Python itself uses that policy. Python 2.7 is 
> called "python-2.7" (note: dash)

The *variable* is called ‘python-2.7’, but the *name* field (which is
what matters here) has value "python".

> Which mechanism does Guix use? Which should it use?

Packages for Python 3.x are called “python-XYZ”, and packages for 2.x
are called “python2-XYZ”:

  https://www.gnu.org/software/guix/manual/html_node/Python-Modules.html

> For example right now I can't install icedtea-7: "guix package: error: 
> icedtea: package not found for version 7"

There’s no version 7, but there are other versions available:

--8<---cut here---start->8---
$ guix package -A icedtea
icedtea 1.13.11 out,jdk,doc gnu/packages/java.scm:196:2
icedtea 2.6.6   out,jdk,doc gnu/packages/java.scm:598:4
icedtea 3.0.1   out,jdk,doc gnu/packages/java.scm:768:4
--8<---cut here---end--->8---

Hope this clarifies things!

Ludo’.

Re: [PATCH 2/4] gnu: Rename 'glib' label to 'glib:bin' where appropriate.

[Ludovic Courtès]

David Craven  skribis:

>  (native-inputs
>   `(("intltool" ,intltool)
> -   ("glib" ,glib "bin")
> +   ("glib:bin" ,glib "bin")
> ("pkg-config" ,pkg-config)))

This patch triggers a lot of rebuild.  While I agree that consistency is
good, and that we should rather use the “glib:bin” going forward, I’d
rather avoid the extra rebuild now.

Thoughts?

Thanks,
Ludo’.

Re: [PATCH] gnu: cross-libc: Cross build the correct libc for GNU/Hurd systems.

[Ludovic Courtès]

Hi Manolis,

Manolis Ragkousis  skribis:

> This is the updated patch. I have tested it as suggested and it works.

Great!

(In the future, could you quote the relevant parts of the message you’re
replying to?  Otherwise I have to search a little bit to find the
context, which increases delay, frustration, and all that.  ;-))

> From e599bc5b7208be48d4fff0868fb3b53a964dae11 Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis 
> Date: Wed, 8 Jun 2016 17:15:00 +0300
> Subject: [PATCH] gnu: cross-libc: Cross build the correct libc for GNU/Hurd
>  systems.
>
> * gnu/packages/cross-base.scm (cross-kernel-headers): Add new variable.
>   Add xgnumach-headers, xmig, xhurd-headers, xglibc/hurd-headers,
>   xhurd-minimal, xhurd-core-headers.
>   (cross-libc): Add cross-libc-for-target.
>   [arguments]: Set "CROSS_LIBRARY_PATH".
>   [propagated-inputs]: Use "cross-kernel-headers" to determine the correct 
> headers.
>   [native-inputs]: Use "cross-mig" when target is GNU/Hurd.

Still LGTM, thank you!

Ludo’.

Re: [PATCH] gnu: Add elixir.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Thu, Jul 21, 2016 at 09:43:57PM +1000, Ben Woodcroft wrote:
>> On 21/07/16 11:42, Pjotr Prins wrote:
>> > Sorry for the new thread. But this time the patch is readable from all
>> > mailers (supporting UTF8). Please comment.
>> 
>> Maybe to fix the $HOME issues by including a phase to set environment
>> variables during testing as in e.g. blast+ ? i.e.
>> 
>> (setenv "HOME" "/tmp")
>
> The test passes when run with this variable set, as attached.

Not attached.  :-)

Ludo’.

Re: none

[Jookia]

On Fri, Jul 22, 2016 at 02:23:42PM +0200, Ricardo Wurmus wrote:
> Pjotr Prins  writes:
> 
> > On Fri, Jul 22, 2016 at 06:48:47AM +0200, Tobias Geerinckx-Rice wrote:
> >> In the spirit of (friendly) provocation, I'd nitpick on the term
> >> ‘purist views’ and suggest the word ‘standards’ instead. ;-)
> >
> > Alright. I concede ;)
> >
> >> But seriously: the code reviews? Most Free software projects don't
> >> do nearly enough. Also, most Free software projects su^W should.
> >
> > The number of contributors is not going up as fast as it should. I
> > have been quite exasparated with every package I submitted. Does that
> > mean I should stop packaging? Note that I actually like packaging, but
> > I feel mentally blocked to submit to the ML... Should we really leave
> > it to those that are more inclined to do the dance?

> I appreciate you sharing your experiences.

I've also quit Guix development because of these experiences, so forgive me for
my harsh words. See help-guix for my experiences. In general, I'm a bit sick of
this so I'm going to reiterate some of my concerns.

> What makes things easier for me personally is to not worry about
> urgency.  Nothing I do is really urgent.  If I need to provide a package
> for someone at the institute I don’t wait for acceptance in Guix
> upstream; I just push it to our own “guix-bimsb” repo, which is used via
> GUIX_PACKAGE_PATH.  Eventually, changes are polished and get accepted
> upstream; at that point I remove them from the external repo.  There is
> no hurry and I can choose to take my time addressing issues mentioned in
> reviews.  (One of my patches for “pam_limits” went through several major
> revisions over a duration of half a year or so.  I’m a sloth.)

Guuix uses a mailing list for development, like most GNU projects. Maybe this
works for those, but Guix is trying to be hip and cool and fresh compared to
most GNU projects which are stable and generally a pain to contribute to.

On top of that, the maintainers can't even use the mailing list properly:
Patches are lost, discussion doesn't happen, things are lost and it's hard for
new users to join in. Who exactly benefits from this workflow compared to
something web-based? Sure, maybe you could argue that the maintainers are best
served with it, or that you personally are attuned to that. Fine, but let's not
pretend the mailing list isn't gruelling.

> I really don’t think we make it hard for people to contribute.  Projects
> using Github or similar platforms have a more complicated workflow
> (because you must work not only with your local clone but also your
> online fork, and you need to force push to make revisions to a pull
> request, etc).  Prior to Guix I had very little experience with a
> mail-based workflow, but I’ve come to really appreciate and prefer it
> over the alternatives.

It's a complicated setup in return for being able to track what's happening in
the project. If I were to ask, 'how many patches are pending review' right now
you'd have absolutely no idea.

> Aren’t you already doing this with your separate package set on Github?
> In my opinion there is no need for an official project like that.  We
> want most changes to be made to Guix directly.  Changes there are much
> more likely to benefit the majority of users.

This is the reason why I really dislike the current attitude of the community.
You're building an operating system which by definition is meant to serve a ton
of different needs, building it slowly and not urgently at all, but then arguing
changes should be kept centralized for the benefit of all users and staging
features should be pushed to whateve personal repositories we have.

> Hmm, an alternative is what you’ve suggested before: have reviewers
> accept more patches earlier.  Since we won’t budge on our standards this
> means that subpar patches take up more work, more time.  As it stands
> right now, we don’t have enough time / enough reviewers.  (I disagree
> with the claim that the number of contributors doesn’t grow quickly
> enough; we do have a problem with the number of reviewers.)

This isn't a software project, it's an operating system. At least until there's
a Guix and GuixSD repo split. Implying the issue that patches not being accepted
is due to subpar patches or high standards sounds good, but isn't true. A lot of
the issues are design-related and require discussion that can't be known in
advance by conributors since Guix is dictated by the maintainers' preferences.
To my knowledge there's no detailed list of what to do in absolutely every
situation involved in the complexity of packaging something, especially with how
new the project is.

> It should not be overlooked that some contributors started out with
> patch submissions that needed a lot of revisions who now provide us with
> extremely reliable contributions.  This relieves pressure from reviewers
> who can spend more time on other contributions.
> 
> For 

Re: [PATCH] gnu: fish: Update to 2.3.1.

[Thompson, David]

On Fri, Jul 22, 2016 at 3:01 AM, Tobias Geerinckx-Rice  wrote:
> * gnu/packages/fish.scm (fish): Update to 2.3.1.
> [home-page, source]: Use 'https' in the URL.

LGTM. Do you have commit access?

- Dave

Re: gnuplot update

[Efraim Flashner]

Ignore the previous patch, here's the real one to update it.


-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 2f2d8925c57da87a3e6c6fa697e58e0fe5a2b14f Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Fri, 22 Jul 2016 15:27:16 +0300
Subject: [PATCH] gnu: gnuplot: Update to upstream's re-release of 5.0.4.

* gnu/packages/maths.scm (gnuplot): Add a guix revision number to the
version scheme of gnuplot to force an update.
---
 gnu/packages/maths.scm | 55 +++---
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index ef84986..ad7d0e2 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -380,35 +380,40 @@ singular value problems.")
 "See LICENSE in the distribution."
 
 (define-public gnuplot
-  (package
-(name "gnuplot")
-(version "5.0.4")
-(source
- (origin
-  (method url-fetch)
-  (uri (string-append "mirror://sourceforge/gnuplot/gnuplot/"
-  version "/gnuplot-" version ".tar.gz"))
-  (sha256
-   (base32
-"08vpmhl85l48xcccx8jrkamalih2d6z9ppqpsppwii9y2l1p3297"
-(build-system gnu-build-system)
-(inputs `(("readline" ,readline)
-  ("cairo" ,cairo)
-  ("pango" ,pango)
-  ("gd" ,gd)))
-(native-inputs `(("pkg-config" ,pkg-config)
- ("texlive" ,texlive-minimal)))
-(home-page "http://www.gnuplot.info;)
-(synopsis "Command-line driven graphing utility")
-(description "Gnuplot is a portable command-line driven graphing
+  ;; Gnuplot version 5.0.4 was updated in-place, resulting in a hash mismatch.
+  ;; This can be removed at the next version update.
+  (let ((upstream-version "5.0.4")
+(guix-revision "1"))
+(package
+  (name "gnuplot")
+  (version (string-append upstream-version "-" guix-revision))
+  (source
+   (origin
+(method url-fetch)
+(uri (string-append "mirror://sourceforge/gnuplot/gnuplot/"
+upstream-version "/gnuplot-"
+upstream-version ".tar.gz"))
+(sha256
+ (base32
+  "07n3w12dkcxjnhsvsliaqnkhajhi818v6q8mkpmpbplbf92vh70m"
+  (build-system gnu-build-system)
+  (inputs `(("readline" ,readline)
+("cairo" ,cairo)
+("pango" ,pango)
+("gd" ,gd)))
+  (native-inputs `(("pkg-config" ,pkg-config)
+   ("texlive" ,texlive-minimal)))
+  (home-page "http://www.gnuplot.info;)
+  (synopsis "Command-line driven graphing utility")
+  (description "Gnuplot is a portable command-line driven graphing
 utility.  It was originally created to allow scientists and students to
 visualize mathematical functions and data interactively, but has grown to
 support many non-interactive uses such as web scripting.  It is also used as a
 plotting engine by third-party applications like Octave.")
-;;  X11 Style with the additional restriction that derived works may only 
be
-;;  distributed as patches to the original.
-(license (license:fsf-free
-  
"http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright;
+  ;;  X11 Style with the additional restriction that derived works may 
only be
+  ;;  distributed as patches to the original.
+  (license (license:fsf-free
+
"http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright;)
 
 (define-public hdf5
   (package
-- 
2.9.1



signature.asc
Description: PGP signature

gnuplot update

[Efraim Flashner]

Hydra discovered that gnuplot's release tarball didn't match, and it
turns out that there was an in-place update to the release tarball. The
diff of the two tarballs is attached.

Attached is a patch to update to the new 5.0.4 release.


Old tarball:
https://flashner.co.il/~efraim/gnuplot-5.0.4-old.tar.gz
08vpmhl85l48xcccx8jrkamalih2d6z9ppqpsppwii9y2l1p3297

New tarball: (also at Sourceforge)
https://flashner.co.il/~efraim/gnuplot-5.0.4-new.tar.gz
07n3w12dkcxjnhsvsliaqnkhajhi818v6q8mkpmpbplbf92vh70m


-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
diff -Naur gnuplot-5.0.4-new/docs/gnuplot.pdf gnuplot-5.0.4-old/docs/gnuplot.pdf
--- gnuplot-5.0.4-new/docs/gnuplot.pdf  2016-07-21 17:47:10.0 +0200
+++ gnuplot-5.0.4-old/docs/gnuplot.pdf  2016-07-20 05:25:57.0 +0200
@@ -11445,8 +11445,8 @@
 endobj
 6539 0 obj <<
 /Author(gnuplot)/Title(gnuplot documentation)/Subject(see 
www.gnuplot.info)/Creator(LaTeX with hyperref 
package)/Producer(pdfTeX-1.40.14)/Keywords()
-/CreationDate (D:20160721084708-07'00')
-/ModDate (D:20160721084708-07'00')
+/CreationDate (D:20160719202555-07'00')
+/ModDate (D:20160719202555-07'00')
 /Trapped /False
 /PTEX.Fullbanner (This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 
2013/Mageia) kpathsea version 6.1.1)
 >> endobj
@@ -11470,7 +11470,7 @@
 /W [1 3 1]
 /Root 6538 0 R
 /Info 6539 0 R
-/ID [<6898D2AAE33E85175B346EB9F8A7546B> <6898D2AAE33E85175B346EB9F8A7546B>]
+/ID [<7A30FAEBBA4B7F11C1CD6990B04692C4> <7A30FAEBBA4B7F11C1CD6990B04692C4>]
 /Length 16171 
 /Filter /FlateDecode
 >>
diff -Naur gnuplot-5.0.4-new/ChangeLog gnuplot-5.0.4-old/ChangeLog
--- gnuplot-5.0.4-new/ChangeLog 2016-07-21 17:45:11.0 +0200
+++ gnuplot-5.0.4-old/ChangeLog 2016-07-20 05:22:29.0 +0200
@@ -1,10 +1,3 @@
-2016-07-21  Ethan A Merritt  
-
-   * src/term_api.h:  Define TERM_POLYGON_PIXELS.
-   * src/graphics.c (plot_image_or_update_axes):  If this flag is set,
-   implement "plot ... with image pixels" using term->filled_polygon()
-   rather than term->fillbox().
-
 2016-07-19  Jun Takimoto 
 
* term/aquaterm.trm:  The AQUA_boxfill() routine scales very badly 
diff -Naur gnuplot-5.0.4-new/src/graphics.c gnuplot-5.0.4-old/src/graphics.c
--- gnuplot-5.0.4-new/src/graphics.c2016-07-21 17:43:44.0 +0200
+++ gnuplot-5.0.4-old/src/graphics.c2016-07-06 06:43:36.0 +0200
@@ -4835,8 +4835,7 @@
corners[0].style = FS_TRANSPARENT_SOLID + 
(alpha<<4);
}
 
-   if (rectangular_image && term->fillbox
-   &&  !(term->flags & TERM_POLYGON_PIXELS)) {
+   if (rectangular_image && term->fillbox) {
/* Some terminals (canvas) can do filled rectangles 
*/
/* more efficiently than filled polygons. */
(*term->fillbox)( corners[0].style,
diff -Naur gnuplot-5.0.4-new/src/term_api.h gnuplot-5.0.4-old/src/term_api.h
--- gnuplot-5.0.4-new/src/term_api.h2016-07-21 17:39:07.0 +0200
+++ gnuplot-5.0.4-old/src/term_api.h2016-01-19 00:51:59.0 +0100
@@ -261,7 +261,6 @@
 #define TERM_IS_LATEX(1<<13)   /* text uses TeX markup*/
 #define TERM_EXTENDED_COLOR  (1<<14)   /* uses EXTENDED_COLOR_SPECS   */
 #define TERM_NULL_SET_COLOR  (1<<15)   /* no support for RGB color*/
-#define TERM_POLYGON_PIXELS  (1<<16)   /* filledpolygon rather than fillbox */
 
 /* The terminal interface structure --- heart of the terminal layer.
  *
diff -Naur gnuplot-5.0.4-new/src/version.c gnuplot-5.0.4-old/src/version.c
--- gnuplot-5.0.4-new/src/version.c 2016-07-21 17:50:12.0 +0200
+++ gnuplot-5.0.4-old/src/version.c 2016-07-20 05:23:21.0 +0200
@@ -44,7 +44,7 @@
 #ifdef DEVELOPMENT_VERSION
 #include "timestamp.h"
 #else
-const char gnuplot_date[] = "2016-07-21 ";
+const char gnuplot_date[] = "2016-07-19 ";
 #endif
 const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2016";
 

From 898e50701f6e9624243ff457ab2aa250128f4cff Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Fri, 22 Jul 2016 15:27:16 +0300
Subject: [PATCH] gnu: gnuplot: Update to upstream's re-release of 5.0.4.

* gnu/packages/maths.scm (gnuplot): Add a guix revision number to the
version scheme of gnuplot to force an update.
---
 gnu/packages/maths.scm | 53 +++---
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index ef84986..00814ca 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -381,34 +381,39 @@ singular value problems.")
 
 (define-public gnuplot
   (package
-(name 

Re: none

[Ricardo Wurmus]

Pjotr Prins  writes:

> On Fri, Jul 22, 2016 at 06:48:47AM +0200, Tobias Geerinckx-Rice wrote:
>> In the spirit of (friendly) provocation, I'd nitpick on the term
>> ‘purist views’ and suggest the word ‘standards’ instead. ;-)
>
> Alright. I concede ;)
>
>> But seriously: the code reviews? Most Free software projects don't
>> do nearly enough. Also, most Free software projects su^W should.
>
> The number of contributors is not going up as fast as it should. I
> have been quite exasparated with every package I submitted. Does that
> mean I should stop packaging? Note that I actually like packaging, but
> I feel mentally blocked to submit to the ML... Should we really leave
> it to those that are more inclined to do the dance?

I appreciate you sharing your experiences.

I may be wrong but to me this comes down to familiarity with Git or
with having a convenient workflow.  I work on many packages and core
changes at the same time in different branches and not having to think
about Git makes this a lot easier.  Rarely ever do I feel that a
suggested change is inconvenient because I can just add a new tmp
commit, interactively rebase to reorder and squash commits, and produce
a new patches.  All of that in separate branches so that I can continue
work on other things without any impact.

What makes things easier for me personally is to not worry about
urgency.  Nothing I do is really urgent.  If I need to provide a package
for someone at the institute I don’t wait for acceptance in Guix
upstream; I just push it to our own “guix-bimsb” repo, which is used via
GUIX_PACKAGE_PATH.  Eventually, changes are polished and get accepted
upstream; at that point I remove them from the external repo.  There is
no hurry and I can choose to take my time addressing issues mentioned in
reviews.  (One of my patches for “pam_limits” went through several major
revisions over a duration of half a year or so.  I’m a sloth.)

I really don’t think we make it hard for people to contribute.  Projects
using Github or similar platforms have a more complicated workflow
(because you must work not only with your local clone but also your
online fork, and you need to force push to make revisions to a pull
request, etc).  Prior to Guix I had very little experience with a
mail-based workflow, but I’ve come to really appreciate and prefer it
over the alternatives.

>> As long as it's not a fork in any way: yes please!
>
> We should consider a separate project that is aligned with trunk. I
> don't want to divert, but to add to both.

Aren’t you already doing this with your separate package set on Github?
In my opinion there is no need for an official project like that.  We
want most changes to be made to Guix directly.  Changes there are much
more likely to benefit the majority of users.

> I am not looking forward to having a separate project, but I don't see
> much of an alternative. There will be a fear that actualy
> contributions to GNU Guix can go down - there is that risk - but my
> aim is to get more acceptance and contributors and eventually we all
> gain. I am not worried about QA. Work can be self correcting - we
> see that a lot.

Hmm, an alternative is what you’ve suggested before: have reviewers
accept more patches earlier.  Since we won’t budge on our standards this
means that subpar patches take up more work, more time.  As it stands
right now, we don’t have enough time / enough reviewers.  (I disagree
with the claim that the number of contributors doesn’t grow quickly
enough; we do have a problem with the number of reviewers.)

It should not be overlooked that some contributors started out with
patch submissions that needed a lot of revisions who now provide us with
extremely reliable contributions.  This relieves pressure from reviewers
who can spend more time on other contributions.

For sustainable growth I think it is necessary that we “train”
contributors by means of reviews.

~~ Ricardo

Re: [PATCH 2/2] gnu: racket: Add more inputs.

[宋文武]

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

> 宋文武  skribis:
>
>> * gnu/packages/schem.scm (racket)[inputs]: Add glu, gmp, libpng, libx11,
>  ^^
> Typo. 
>
>> mesa, mpfr, openssl and unixodbc.  Replace libjpeg-8 with libjpeg and
>> gtk+-2 with gtk+.
>
> LGTM!
Thanks for the review, pushed!

Re: none

[Pjotr Prins]

On Fri, Jul 22, 2016 at 06:48:47AM +0200, Tobias Geerinckx-Rice wrote:
> In the spirit of (friendly) provocation, I'd nitpick on the term
> ‘purist views’ and suggest the word ‘standards’ instead. ;-)

Alright. I concede ;)

> But seriously: the code reviews? Most Free software projects don't
> do nearly enough. Also, most Free software projects su^W should.

The number of contributors is not going up as fast as it should. I
have been quite exasparated with every package I submitted. Does that
mean I should stop packaging? Note that I actually like packaging, but
I feel mentally blocked to submit to the ML... Should we really leave
it to those that are more inclined to do the dance?

> >license, github etc.
> 
> I've not seen any licence purism (yet) either. Anything Free, goes.
> No?

Yes, but there are also non-free packages in our repo. They do not
have to go in GNU Guix. I am a great fan of the FSF and GNU. I think
GNU Guix is pure genius. I always choose free over non-free. But we
also have to be pragmatic.

> I'm curious why GitHub's in that list. Sure, the upstream Guix
> repository isn't going to move there any time soon. There's no
> compelling reason to do so, and not relying on someone else's
> good-will is always a good idea. Not relying on someone else's
> proprietary secret SaaS is simply common sense. But I haven't
> seen any purist elitism towards GitHub users. I'm one.

People don't like github because it is non-free.

> >I understand the need for purism, and applaud the idea, but we are
> >throwing up too many barriers.
> >
> >Because GNU Guix is an extreme, ...
> 
> Wow. I don't see that. At all.

Everything FSF and/or GNU is pretty extreme ;). It is a good thing. I
buy into it when I can. Barriers are there. Everyone is different, we
have to cater for that.

> As long as it's not a fork in any way: yes please!

We should consider a separate project that is aligned with trunk. I
don't want to divert, but to add to both.

Yellow-band Guix? With a Judoka embracing the Guix logo ;). 'A Guix
package project without an opinion' would be my choice of a slogan.
Judo instead of dancing.

I am not looking forward to having a separate project, but I don't see
much of an alternative. There will be a fear that actualy
contributions to GNU Guix can go down - there is that risk - but my
aim is to get more acceptance and contributors and eventually we all
gain. I am not worried about QA. Work can be self correcting - we
see that a lot.

I had a mug that said 'Stop me before I volunteer again'. This is one
of those moments... But I may just do it.

Pj.

Re: [PATCH] Add python-protobuf and python2-protobuf

[d4n1]

thanks :)



Daniel Pimentel (aka d4n1)On Leo Famulari , Jul 22, 2016 3:23 AM wrote:On Thu, Jul 14, 2016 at 12:23:35PM -0300, Daniel Pimentel wrote:
> Guix,
> 
> Patches to add python-protobuf to Python3 and Python2.

Thanks!

I moved the packages to (gnu packages protobuf). Also, I updated them to
the latest upstream version (3.0.0b4) and removed a couple unused
inputs.

I committed the change in 8d63dddac.

Re: Seeking guidance regarding system roll-back and switch-generation

[Chris Marusich]

Chris Marusich  writes:

> Specifically, to complete the first milestone (flip symlinks and
> regenerate grub.cfg), I need to determine the paths to certain things
> like the kernel and the initrd for an arbitrary system generation.  So,
> I'm not sure if I should simply parse that information from the file
> system, or if I should try to use the store to obtain that information.
> What are your thoughts?

I did not realize that we already store information like this in a
declarative form in the "parameters" file (e.g.,
/var/guix/profiles/system/parameters).  Now that I know that such a
thing exists, I will look into it to see how I can use it.

-- 
Chris


signature.asc
Description: PGP signature

Re: gnu/system/u-boot.scm

[Chris Marusich]

Danny Milosavljevic  writes:

> Hi,
>
> below is my (untested!) attempt at an u-boot-configuration for use like this
>
>   (bootloader (u-boot-configuration (device "/dev/sda")))

Neat!  Kudos to you for getting the ball rolling.  I'm not familiar with
u-boot, but based on recent emails, it sounds like it's important for
getting GuixSD to run on ARM.

> Now how do I make u-boot-configuration available in my /etc/config.scm
> ? :)

A mechanism exists for installing the bootloader and its configuration
files.  You can see it in guix/gnu/build/install.scm (where we actually
execute the install-grub [1] program) and guix/guix/scripts/system.scm.
It seems the code currently assumes that grub is the bootloader.  To
actually install u-boot, you'll probably need to add support for u-boot
somewhere in there.

[1] 
https://www.gnu.org/software/grub/manual/html_node/Installing-GRUB-using-grub_002dinstall.html#Installing-GRUB-using-grub_002dinstall

I wonder if it would be possible to create a bootloader abstraction of
some kind so that the installation mechanism can work with either u-boot
or grub, without caring about which one it uses?  It would be nice if
the installation mechanism were generic enough so that the same
mechanism could be used to install either bootloader.

> (define-record-type* 
>   u-boot-configuration make-u-boot-configuration
>   u-boot-configuration?
>   (board   u-boot-configuration-board)   ; string ; not 
> optional!
>   (u-boot  u-boot-configuration-u-boot   ; package
>(default (@ (gnu packages u-boot) (make-u-boot-package 
> board
>   (device  u-boot-configuration-device); string
>   (menu-entriesu-boot-configuration-menu-entries   ; list
>(default '()))
>   (default-entry   u-boot-configuration-default-entry  ; integer
>(default 0))
>   (timeout u-boot-configuration-timeout; integer
>(default 5)))

This looks a little different from the grub-configuration record type
(defined in guix/gnu/system/grub.scm).  How do you intend to integrate
it with the existing bootloader installation mechanism?

-- 
Chris


signature.asc
Description: PGP signature

Installing incompatible major versions of packages alongside each other

[Danny Milosavljevic]

Hi Ludo,

> In the former command-line package specification syntax, which is still
> supported but deprecated, “ptpython-2” was taken to mean “version 2 of
> package ‘ptpython’”.  Because of this, you cannot refer to this
> “ptpython-2” package from the command-line (except with -e).
> 
> The solution is to call it differently, like “ptpython2”.

Hmm, it doesn't seem as if Guix Python itself uses that policy. Python 2.7 is 
called "python-2.7" (note: dash)

I'm used to semantic version numbers.

Usually, the major version is increased because something major is incompatible.

For example Python 3 changed "print" from prefix operator to function. So 
almost no program that uses Python 2 "print" will work in Python 3. (they also 
changed the default string representation and lots of other things)

Therefore, it makes sense (and is common) to install and use both Python 2 and 
Python 3.

For pypython, too, you'd have it be able to use a Python 2 and a Python 3 
interpreter.

I think this is a general rule. However, some packages and/or developers use 
non-standard version numbers. Therefore it would be good to be able to override 
this rule as a packager.

Therefore, Gentoo packages have something called a "SLOT". It's an extra number 
in the package spec which specifies which slot of the base package you want to 
fill in the installation.

For example if you install

  dev-lang/python-3.4.3

it will install it in slot 3 [the 3 is in the package file which you can't see 
here; it says SLOT=3 in there] (and replace the thing in slot 3 if necessary)

and if you install

  dev-lang/python-2.7.3

it will install it in slot 2 [it says so in the package spec file] (and replace 
the thing in slot 2 if necessary).

If you uninstall

  dev-lang/python

it will remove both.

If you uninstall

  dev-lang/python-3.4.3

it will just remove this one.

For a completely different take, Debian just adds this kind of slot number to 
the package basename - as you suggest I do.

There, it would just be "python2.6" for Python 2.6 and "python3" for Python 3.

Which mechanism does Guix use? Which should it use?

The guix.texi manual seems to advocate using names like "python-2" - which I 
seem to have the most problems in practise with. For example right now I can't 
install icedtea-7: "guix package: error: icedtea: package not found for version 
7"

[PATCH 1/3] gnu: Add xdpyprobe.

[Alex Kost]

* gnu/packages/xdisorg.scm (xdpyprobe): New variable.
---
 gnu/packages/xdisorg.scm | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 54545a8..485bbc4 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -13,6 +13,7 @@
 ;;; Copyright © 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 Efraim Flashner 
 ;;; Copyright © 2016 Leo Famulari 
+;;; Copyright © 2016 Alex Kost 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -913,6 +914,28 @@ demos.  It also acts as a nice screen locker.")
"http://metadata.ftp-master.debian.org/changelogs/;
"/main/x/xscreensaver/xscreensaver_5.34-2_copyright")
 
+(define-public xdpyprobe
+  (package
+(name "xdpyprobe")
+(version "0.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://github.com/alezost/; name
+  "/releases/download/v" version
+  "/" name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"1h09wd2qcg08rj5hcakvdh9q01hkrj8vxly94ax3ch2x06lm0zq8"
+(build-system gnu-build-system)
+(inputs
+ `(("libx11" ,libx11)))
+(home-page "https://github.com/alezost/xdpyprobe;)
+(synopsis "Probe X server for connectivity")
+(description
+ "Xdpyprobe is a tiny C program whose only purpose is to probe a
+connectivity of the X server running on a particular @code{DISPLAY}.")
+(license license:gpl3+)))
+
 (define-public rofi
   (package
 (name "rofi")
-- 
2.8.3

[PATCH 2/3] gnu: Add guile-xosd.

[Alex Kost]

* gnu/packages/guile.scm (guile-xosd): New variable.
---
 gnu/packages/guile.scm | 32 
 1 file changed, 32 insertions(+)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 2d8ca0c..9b85016 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 Erik Edrosa 
 ;;; Copyright © 2016 Eraim Flashner 
+;;; Copyright © 2016 Alex Kost 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -50,6 +51,8 @@
   #:use-module (gnu packages sdl)
   #:use-module (gnu packages maths)
   #:use-module (gnu packages image)
+  #:use-module (gnu packages xdisorg)
+  #:use-module (gnu packages xorg)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix git-download)
@@ -1122,4 +1125,33 @@ It currently supports MySQL, Postgres and SQLite3.")
 SQL databases.  This package implements the interface for SQLite.")
 (license gpl2+)))
 
+(define-public guile-xosd
+  (package
+(name "guile-xosd")
+(version "0.2")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://github.com/alezost/; name
+  "/releases/download/v" version
+  "/" name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"1j0b07kycccfslp5n6q0hz7adwc7k41fpzds2dvrly67gavjqljv"
+(build-system gnu-build-system)
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("guile" ,guile-2.0)
+   ("libx11" ,libx11)
+   ("libxext" ,libxext)
+   ("libxinerama" ,libxinerama)
+   ("xosd" ,xosd)))
+(home-page "https://github.com/alezost/guile-xosd;)
+(synopsis "XOSD bindings for Guile")
+(description
+ "Guile-XOSD provides Guile bindings for @code{libxosd},
+@uref{http://sourceforge.net/projects/libxosd/, the X On Screen Display
+library}.")
+(license gpl3+)))
+
 ;;; guile.scm ends here
-- 
2.8.3

[PATCH 0/3] 3 packages for my programs

[Alex Kost]

Hello, I use these programs all the time, so I think maybe they could be
useful for someone else.  Is it reasonable to add these packages to
Guix?

[PATCH 1/3] gnu: Add xdpyprobe.
[PATCH 2/3] gnu: Add guile-xosd.
[PATCH 3/3] gnu: Add guile-daemon.

Re: none

[Roel Janssen]

Pjotr Prins writes:

> On Thu, Jul 21, 2016 at 02:51:38PM +0200, Ludovic Courtès wrote:
>> In
>> ,
>> you already identified exactly what we were going to say.  :-)
>> 
>> Namely, why are patches applied in a build phase rather than in
>> ‘origin’, why is such and such test disabled (one sentence is usually
>> enough), what happens if we set ‘HOME’ like Ben suggests, etc.
>> 
>> What should we do?  :-)
>
> I think I have covered that both in my writeup and in my response to
> Ben. I think this work should be accepted as is.
>
> I think this is probably the last package I am contributing to main line.
> Never liked dancing that much ;)

For the last twenty weeks or so I have started contributing packages to
GNU Guix mainly because Pjotr gave me the opportunity to do so.  For me,
upstreaming was part of the deal, and I'd say it has taken me at least
two times the time it took me to write a proper package definition to
get it in the upstream distribution.

You've seen the mistakes I made, and the little syntactic things that
kept going wrong over time.  Near the end of my internship, however, I
saw a positive change: Reviewers actually make little changes, instead
of leaving it up to the submitter to ``fix the indendation''.  This
change makes the burden of reviewing smaller as well as the burden to
submit a package.  Great!

One thing that really helped me in reducing the time to contribute
changes to the upstream distribution, is to have a good workflow.  I
ended up doing the following:
1. Make the changes.
2. Commit the changes.
3 git format-patch -1 --no-attach
4. git reset --hard 
5. Submit the patch to the mailing list
6. Wait for response and probably go back to 1.

I made all of my changes on a GNU Guix git checkout.  So, not writing
package definitions on a separate repository.

> But seriously, we should find other ways to encourage people. I wonder
> how many packages are out there that never find their way into guix or
> much too late. I wonder how much duplicate work is going on because of
> our dance requirement. If it this hard *with* my experience in
> packaging, how hard do you think it is for people *without*
> experience. I know Dennis, for example, is sitting on a heap of opencl
> packages which are incredibly useful to many people.
>
> I believe we have to change our ways.

The problem is real.  I have taken contributing back to upstream _very_
serious, and I haven't been able to get everything back into GNU Guix
either.

Packages I work(ed) on that haven't made it upstream (yet) due to
``imperfect'' patches:
* MongoDB:Bundled source code;
* GParted:The help function does not work without external
  documentation database tool;
* FreeBayes:  At first, licensing issues, now just a plain ugly patch to
  deal with the unbundling of its dependencies in the
  Makefiles of this project;
* VCFLib: Same situation as FreeBayes.  To be honest, this package
  would've not ended up as a separate package if I didn't
  have to split up FreeBayes.  I consider this a positive
  effect of the review process.

Lastly, I would like to say that I think the package reviews have always
been positive and fair.  We are trying to maintain a high-quality
distribution, and this is a natural effect of trying to do so.

Maybe we could create an online course to do packaging with GNU Guix and
make it rewarding with a grading system and giving achievement points..
That might make the incentive to make the upstreaming step of packaging
more fun and more like a learning process rather than a recurrent PITA.
(This is something I could spend time at..)

Kind regards,
Roel Janssen

[PATCH] gnu: fish: Update to 2.3.1.

[Tobias Geerinckx-Rice]

* gnu/packages/fish.scm (fish): Update to 2.3.1.
[home-page, source]: Use 'https' in the URL.
---
 gnu/packages/fish.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/fish.scm b/gnu/packages/fish.scm
index 7abaaf0..a8b88e7 100644
--- a/gnu/packages/fish.scm
+++ b/gnu/packages/fish.scm
@@ -29,14 +29,14 @@
 (define-public fish
   (package
 (name "fish")
-(version "2.3.0")
+(version "2.3.1")
 (source (origin
   (method url-fetch)
-  (uri (string-append "http://fishshell.com/files/;
+  (uri (string-append "https://fishshell.com/files/;
   version "/fish-" version ".tar.gz"))
   (sha256
(base32
-"1ralmp7lavdl0plc09ppm232aqsn0crxx6m3hgaa06ibam3sqawi"))
+"0r46p64lg6da3v6chsa4gisvl04kd3rpy60yih8r870kbp9wm2ij"))
   (modules '((guix build utils)))
   ;; Don't try to install /etc/fish/config.fish.
   (snippet
@@ -61,5 +61,5 @@ has extensive and discoverable help.  A special help command 
gives access to
 all the fish documentation in your web browser.  Other features include smart
 terminal handling based on terminfo, an easy to search history, and syntax
 highlighting.")
-(home-page "http://fishshell.com/;)
+(home-page "https://fishshell.com/;)
 (license gpl2)))
-- 
2.9.0

Re: [PATCH 2/3] profiles: Add fonts-dir-file hook.

[Alex Kost]

Ludovic Courtès (2016-07-05 17:31 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2016-07-02 17:34 +0300) wrote:
>>
>>> Alex Kost  skribis:
>>>
 * guix/profiles.scm (fonts-dir-file): New procedure.
 (%default-profile-hooks): Add it.
>>>
>>> [...]
>>>
>>> A potential problem with this hook is that it pulls mkfontscale and
>>> mkfontdir regardless of whether they are needed; I can’t really think of
>>> a way to avoid it though.
>>
>> Yes, I also don't like it.  We have the same problem with
>> 'info-file-dir' hook: it always pulls texinfo and gzip, but not all
>> profiles include info manuals.
>
> Yes, but I thought it was OK to make these mandatory dependencies.
>
> The closure of mkfontscale + mkfontdir is small; it’s slightly annoying
> for someone building from source because you have to build a few X11
> libraries, but it’s not that much either (‘guix graph’ shows just a few
> boxes.)
>
> So this hook is probably fine, after all.
>
> What do people think?

Since there were no objections in 2 weeks, I think it's OK to commit
this 'fonts-dir-file' hook, right?

-- 
Alex

Re: [PATCH] Add python-protobuf and python2-protobuf

[Leo Famulari]

On Thu, Jul 14, 2016 at 12:23:35PM -0300, Daniel Pimentel wrote:
> Guix,
> 
> Patches to add python-protobuf to Python3 and Python2.

Thanks!

I moved the packages to (gnu packages protobuf). Also, I updated them to
the latest upstream version (3.0.0b4) and removed a couple unused
inputs.

I committed the change in 8d63dddac.