Re: [PATCH 3/4] gnu: emacs: Find packages in "~/.guix-profile".

[Alex Kost]

Ludovic Courtès (2016-01-10 23:28 +0300) wrote:

> Alex Kost  skribis:
>
>> From: Federico Beffa 
>>
>> * gnu/packages/emacs.scm (emacs)[inputs]: Add 'guix-src' input.
>>   [arguments]: Add 'install-site-start' phase.
>
> [...]
>
>> + (add-after 'install 'install-site-start
>
> Could you add a comment like:
>
>   ;; Copy guix-emacs.el from Guix and add it to site-start.el.  This
>   ;; way, Emacs packages provided by Guix and installed in
>   ;; ~/.guix-profile/share/emacs/site-lisp/guix.d/PACKAGE-VERSION are
>   ;; automatically found.
>
> Otherwise LGTM.

Done for this and for your notes on other patches, thanks!

> Also, on GuixSD, should we remove the default EMACSLOADPATH as well as
> /etc/emacs/site-start.el?

If the goal for GuixSD is just to make Emacs packages work, then yes;
but if the intention is also to make "M-x guix-..." commands work
out-of-the-box, then we should leave it as it is now.

-- 
Alex

Re: [PATCH 0/4] Make Emacs find packages in "~/.guix-profile".

[Alex Kost]

Ludovic Courtès (2016-01-10 23:21 +0300) wrote:

> Alex Kost  skribis:
>
>> So this is a full patchset to "teach" Emacs how to find emacs packages
>> installed with Guix.  See conversation at
>> .
>>
>> [PATCH 1/4] emacs: Make "guix-emacs.el" independent.
>> [PATCH 2/4] emacs: Move loading packages to "guix-emacs.el".
>> [PATCH 3/4] gnu: emacs: Find packages in "~/.guix-profile".
>> [PATCH 4/4] doc: Describe how Emacs packages are found.
>>
>> There is an important nuance: the 3rd patch MUST NOT be committed along
>> with the first 2 patches, because it will make our Emacs package use an
>> old source of 'guix' which does not contain the required changes.  So I
>> think we should:
>>
>> 1. Push the patches 1 and 2.
>>
>> 2. Wait for the next update of the 'guix-devel' snapshot (last time it
>>was updated in November¹, so it will probably happen soon).
>>
>> 3. And finally push the patches 3 and 4.
>
> OK.  Note that we can update ‘guix-devel’ whenever we want.  So if you
> take care of pushing things, feel free to do it yourself!

Great, but I see that you updated guix-devel snapshot several days ago.
Would it be OK to update it again so soon?  If yes, then I will gladly
push this patchset and update guix-devel as appropriate.

-- 
Alex

Version numbers for VCS snapshots

[Ludovic Courtès]

Ricardo Wurmus  skribis:

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

Let do that!

> So far we have been picking the latest release version (or “0.0.0” if
> there hasn’t been any release) followed by “.” and either a date or a
> guix-internal revision number, then again a “.” followed by part of the
> commit hash.
>
> I’m afraid that we might accidentally introduce conflicts with future
> release versions, e.g. when the latest release only uses two digits
> (e.g. “0.1”) and we add a revision or a date (e.g. “0.1.1” or
> “0.1.20160112”) and the next release and the next official release
> switches to three digits (e.g. “0.1.1”).
>
> Would it make sense to separate our version identifier from the actual
> release version with a different character than “.”?  Or should this be
> discussed elsewhere as it hasn’t anything to do with how we specify
> versions on the command line?

Probably.  Debian, for instance, uses “2.0.11-9” where “9” denotes the
9th package revision of upstream version “2.0.11”.  We could probably
use that convention.

In a previous discussion on this topic, I suggested that we should have
such a revision number instead of just “x.y.COMMIT”.  The extra
monotonically-increasing revision number is needed to allow upgrades to
work as expected.

So, a Git snapshot’s version number could be:

  2.0.11-3.deadbeef
^^^
||`— upstream commit ID
||
|`—— 3rd Guix package revision
|
  latest upstream version

The next snapshot would be:

  2.0.11-4.cafeefac

WDYT?

Ludo’.

Re: qemu instructions for manual

[Ludovic Courtès]

Leo Famulari  skribis:

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

In practice -enable-kvm is highly recommended too.  I think anything
less than 5 to 8(?) years old supports virtualization extensions.

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

In theory we should be able to cross-compile complete GuixSD images to
other architectures, but that’s never been tried and there are probably
lots of build issues on the way, so let’s say that this has to match the
hardware platform or a sibling thereof (e.g., i686 code can be built on
x86_64.)

> # Unprivileged user mode networking. Guest can access host but not vice versa.
> # If you don't choose a network stack, the boot process will fail.
> -net user \
>
> # You must create a network interface of a given model. You can get a list of
> # available NIC types by running `qemu-system-$arch -net nic,model=help`. If
> # you don't create a NIC, the boot process will fail.
> -net nic,model=virtio \
>
> # RAM available to the guest OS. Defaults to 128 megabytes, which is not 
> enough
> # for the Guix daemon. More is better.
> -m 256 \
>
> OPTIONAL: If your system is x86 with hardware virtualization extensions,
> enabling the kernel virtual machine will make things go much faster.
> -enable-kvm \
>
> # Path to the virtual machine image
> ./qemu-image

Sounds good!

Note that our QEMU package installs two Info manuals.  They are sparse,
but helpful.

In the Guix manual, and interesting thing would be an “Installating
GuixSD in a VM” section.  This is a bit more involved than the above,
because you need a target disk image separate from the installation
image, but the above is a good start.

Thanks,
Ludo’.

Re: reproducibility

[Ludovic Courtès]

Federico Beffa  skribis:

> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès  wrote:
>> Federico Beffa  skribis:
>>
>>> I've noticed that a derivation is a function of the order of the
>>> inputs. As an example, the following two input orders give rise to two
>>> distinct derivations:
>>>
>>> A)
>>>
>>> (inputs
>>>  `(("texlive" ,texlive)
>>>("texinfo" ,texinfo)
>>>("m4" ,m4)
>>>("libx11" ,libx11))
>>>
>>> B)
>>> (inputs
>>>  `(("texinfo" ,texinfo)
>>>("texlive" ,texlive)
>>>("m4" ,m4)
>>>("libx11" ,libx11))
>>>
>>> Is this intentional?
>>
>> Yes.  There are several places where order matters, most importantly
>> search paths, and these are computed from the input lists.
>
> If order matters, it would probably be more robust to force internally
> a specific order rather than relying on the (often random) order
> defined in a package recipe (possibly created by an importer, ...).

Most of the time any order would work, but I can imagine situations
where the packager could purposefully choose a specific order.  So I’d
rather not do any automatic sorting, if that’s what you have in mind.

Thanks,
Ludo’.

Re: 03/05: gnu: icedtea6, icedtea7: Rename package to "icedtea".

[Ricardo Wurmus]

Mark H Weaver  writes:

>> commit 5452588c1a662bdcee240342a9df87efa4b1c017
>> Author: Ricardo Wurmus 
>> Date:   Wed Dec 30 14:31:16 2015 +0100
>>
>> gnu: icedtea6, icedtea7: Rename package to "icedtea".
>> 
>> * gnu/packages/java.scm (icedtea6): Change package name to "icedtea".
>> (icedtea7): Inherit package name.
>
> This broke the builds for icedtea-1.13.9, see:
>
>   http://hydra.gnu.org/eval/108721#tabs-new
>   http://hydra.gnu.org/build/908975/log/tail-reload
>
> The relevant excerpt is:
>
> --8<---cut here---start->8---
> In unknown file:
>?: 0 [chdir "icedtea-1.13.9"]
>
> ERROR: In procedure chdir:
> ERROR: In procedure chdir: No such file or directory
> builder for `/gnu/store/dl93r8kpd9g7g3iamwz2n05nxlwjsfsn-icedtea-1.13.9.drv' 
> failed with exit code 1
> --8<---cut here---end--->8---
>
> I guess the problem is that the custom unpack phase does this:
>
>(chdir (string-append ,name "-" ,version))
>
> and this patch changes the value of 'name'.

Indeed!  It’s fixed in 9f40b1171bab8bc4be8a0a1f78453ac7e7310fdb.  My
apologies!

~~ Ricardo

Re: reproducibility

[Federico Beffa]

On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> I've noticed that a derivation is a function of the order of the
>> inputs. As an example, the following two input orders give rise to two
>> distinct derivations:
>>
>> A)
>>
>> (inputs
>>  `(("texlive" ,texlive)
>>("texinfo" ,texinfo)
>>("m4" ,m4)
>>("libx11" ,libx11))
>>
>> B)
>> (inputs
>>  `(("texinfo" ,texinfo)
>>("texlive" ,texlive)
>>("m4" ,m4)
>>("libx11" ,libx11))
>>
>> Is this intentional?
>
> Yes.  There are several places where order matters, most importantly
> search paths, and these are computed from the input lists.

If order matters, it would probably be more robust to force internally
a specific order rather than relying on the (often random) order
defined in a package recipe (possibly created by an importer, ...).

Fede

Re: [PATCH 3/6] emacs: Find packages in system profiles.

[Ludovic Courtès]

Alex Kost  skribis:

> For a usual profile, packages are placed in a profile directory itself,
> but for a system profile, packages are placed in 'profile'
> sub-directory.  So we need to do some special cases for system profiles
> to find packages there as well.
>
> * emacs/guix-base.el (guix-packages-profile): New procedure.
>   (guix-manifest-file): Use it.  Add optional 'system?' argument.
> * emacs/guix-ui-generation.el (guix-system-generation?)
>   (guix-generation-current-packages-profile):  New procedures.
>   (guix-generation-packages, guix-generation-insert-packages)
>   (guix-generation-packages-buffer): Add optional 'system?' argument.
>   (guix-profile-generation-manifest-file)
>   (guix-profile-generation-packages-buffer): Adjust accordingly.
> * emacs/guix-main.scm (generation-package-specifications+paths): Rename to...
>   (profile->specifications+paths): ... this.  Use a single 'profile' argument.

[...]

> +(defun guix-packages-profile (profile  generation system?)
> +  "Return a directory where packages are installed for the
> +PROFILE's GENERATION.
> +
> +If SYSTEM? is non-nil, then PROFILE is considered to be a system
> +profile.  Unlike usual profiles, for a system profile, packages
> +are placed in 'profile' subdirectory."
> +  (let ((profile (if generation
> + (guix-generation-file profile generation)
> +   profile)))
> +(if system?
> +(expand-file-name "profile" profile)
> +  profile)))

It seems you’re calling /run/current-system the system profile, which
leads to the ‘system?’ Boolean here, but the system profile really is
/run/current-system/profile.

I had overlooked it, but wouldn’t it be easier if patch #2 did:

+(defvar guix-system-profile
+  (concat guix-config-state-directory "/profiles/system/profile")
+  "System profile.")

?

Ludo’.

Re: [PATCH 6/6] emacs: Add interface for system generations.

[Ludovic Courtès]

Alex Kost  skribis:

> * emacs/guix-main.scm (system-generation-boot-parameters)
> (system-generation-param-alist, system-generation-sexps): New procedures.
> (entries): Add 'system-generation' entry type.
> * emacs/guix-messages.el (guix-result-message): Use the same messages
>   for 'generation' and 'system-generation' entry types.
> * emacs/guix-ui-system-generation.el: New file.
> * emacs.am (ELFILES): Add it.
> * doc/emacs.texi (Emacs Commands): Document new commands.
> * NEWS: Mention new interface.

[...]

> +Analogously on GuixSD you can also display system generations:
> +
> +@table @kbd
> +@item M-x guix-system-generations
> +@item M-x guix-last-system-generations
> +@item M-x guix-system-generations-by-time
> +@end table

As simple as this.  :-)

And I guess it’s also possible to select generations, delete them, and
switch to a specific one, as with M-x guix-generations?

Though maybe it would have to use
“sudo:localhost:/run/current-system/profile” (via Tramp) to be able to
modify things.  Maybe it could somehow offer to gain root privileges
when performing an action?

Ludo’.

Re: [PATCH 3/3] gnu: Add go-1.5.

[Ricardo Wurmus]

Efraim Flashner  writes:

> * gnu/packages/golang.scm (go-1.5): New variable.

[...]

> +(arguments
> + (substitute-keyword-arguments (package-arguments go-1.4)
> +   ((#:phases phases)
> +`(modify-phases ,phases
> + (replace 'build
> +  (let* ((bash   (assoc-ref %build-inputs "bash"))
> + (go14   (assoc-ref %build-inputs "go-1.4"))
> + (output (assoc-ref %outputs "out")))
> +(setenv "CC" "gcc")
> +(setenv "GOPATH" (string-append (getcwd) "/go"))
> +(setenv "GOROOT_BOOTSTRAP" go14)
> +(setenv "GOROOT_FINAL" output)
> +(lambda _
> +  (zero?
> +(system* (string-append bash "/bin/bash") 
> "make.bash")

This looks weird.  Shouldn’t the “let” and the “setenv” be inside the
“lambda”?  (BTW: this is a perfect usecase for “M-x
paredit-convolute-sexp”, after placing point before “(zero?”.)

I think you could do this instead:

   `(modify-phases ,phases
  (replace 'build
(lambda* (#:key inputs outputs #:allow-other-keys)
  (let ((go14   (assoc-ref inputs "go-1.4"))
(output (assoc-ref outputs "out")))
(setenv "CC" "gcc")
(setenv "GOPATH" (string-append (getcwd) "/go"))
(setenv "GOROOT_BOOTSTRAP" go14)
(setenv "GOROOT_FINAL" output)
(zero? (system* "bash" "make.bash"))

~~ Ricardo

Re: [PATCH 4/6] emacs: Replace 'generation-diff' search with 'profile-diff'.

[Ludovic Courtès]

Alex Kost  skribis:

> * emacs/guix-main.scm (generation-package-specifications): Rename to...
>   (profile-package-specifications): ... this.  Take a single 'profile'
>   argument.
>   (generation-difference): Rename to...
>   (profile-difference): ... this.  Take profiles as arguments.
>   (package/output-sexps): Adjust accordingly.
> * emacs/guix-ui-generation.el (guix-generation-list-profiles-to-compare):
>   New procedure.
>   (guix-generation-list-show-added-packages)
>   (guix-generation-list-show-removed-packages): Use it.
> * emacs/guix-messages.el (guix-messages): Replace 'generation-diff' with
>   'profile-diff'.
>   (guix-message-outputs-by-diff): Adjust accordingly.

LGTM.

Re: [PATCH 0/6] emacs: Add "M-x guix-system-generations".

[Ludovic Courtès]

Alex Kost  skribis:

> This patchset adds commands for displaying system generations — an
> emacs analog of 'guix system list-generations' shell command.  The
> interface is the same as for "M-x guix-generations", i.e. you can look
> at installed "system" packages (by pressing RET on a generation), or
> compare 2 generations by pressing "=".

Awesome!

> Patches:
>
> [PATCH 1/6] guix system: Export  accessors.
>
>   I just exported this stuff, but perhaps it would be better to move it
>   from (guix scripts system) to another module.
>
> [PATCH 2/6] emacs: profiles: Add 'guix-system-profile'.
>
> [PATCH 3/6] emacs: Find packages in system profiles.
> [PATCH 4/6] emacs: Replace 'generation-diff' search with 'profile-diff'.
> [PATCH 5/6] emacs: Remove 'generation' search type.
>
>   These 3 patches are for some internal changes, related to the fact
>   that system packages are installed in "system-NN-link/profile", while
>   user packages are installed in "guix-profile-NN-link".
>
> [PATCH 6/6] emacs: Add interface for system generations.
>
>   Is it OK to update 'NEWS' file in this patch?

Sure.

Ludo’.

Re: [PATCH 1/6] guix system: Export accessors.

[Ludovic Courtès]

Alex Kost  skribis:

> * guix/scripts/system.scm (read-boot-parameters, boot-parameters)
> (boot-parameters?, boot-parameters-label, boot-parameters-root-device)
> (boot-parameters-kernel, boot-parameters-kernel-arguments): Export.

LGTM.

Eventually (as a replacement of this patch or as a subsequent patch, as
you prefer) we should move these to (gnu system) since this is where we
create the ‘boot-parameters’ sexp.

Thanks,
Ludo’.

Re: [PATCH 2/6] emacs: profiles: Add 'guix-system-profile'.

[Ludovic Courtès]

Alex Kost  skribis:

> * emacs/guix-profiles.el (guix-system-profile): New variable.

OK!

Re: [PATCH 5/6] emacs: Remove 'generation' search type.

[Ludovic Courtès]

Alex Kost  skribis:

> Use 'installed' search type instead.
>
> * emacs/guix-main.scm (%patterns-makers): Remove 'generation'.
>   (package/output-sexps): Adjust accordingly.
> * emacs/guix-ui-generation.el (guix-generation-info-insert-number):
>   Replace 'generation' search with 'installed'.
>   (guix-generation-list-show-packages): Likewise.
> * emacs/guix-messages.el (guix-messages): Remove 'generation'.

I guess it’s OK.  ;-)

Ludo’.

Re: [PATCH 0/2] Add eSpeak

[Andreas Enge]

On Tue, Jan 12, 2016 at 12:58:12AM -0500, Leo Famulari wrote:
> So, in the future we should probably
> package espeak-ng as well, for the sake of users that need speech
> synthesis. It will conflict with espeak since the output binaries have
> the same names.

>From what you write, would it not be better to directly package espeak-ng
and to drop espeak?

Andreas

[PATCH 1/5] gnu: Add python-args.

[宋文武]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 4ab1eed..0886809 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -6620,3 +6620,25 @@ the standard library.")
 
 (define-public python2-contextlib2
   (package-with-python2 python-contextlib2))
+
+(define-public python-args
+  (package
+(name "python-args")
+(version "0.1.0")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "args" version))
+  (sha256
+   (base32
+"057qzi46h5dmxdqknsbrssn78lmqjlnm624iqdhrnpk26zcbi1d7"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(home-page "https://github.com/kennethreitz/args;)
+(synopsis "CLI argument interface")
+(description
+ "This module provides the CLI argument interface for clint.")
+(license bsd-3)))
+
+(define-public python2-args
+  (package-with-python2 python-args))
-- 
2.5.0

Re: [PATCH 0/2] Add eSpeak

[Leo Famulari]

On Tue, Jan 12, 2016 at 02:30:06PM -0500, Leo Famulari wrote:
> On Tue, Jan 12, 2016 at 04:48:18PM +0100, Andreas Enge wrote:
> > On Tue, Jan 12, 2016 at 12:58:12AM -0500, Leo Famulari wrote:
> > > So, in the future we should probably
> > > package espeak-ng as well, for the sake of users that need speech
> > > synthesis. It will conflict with espeak since the output binaries have
> > > the same names.
> > 
> > From what you write, would it not be better to directly package espeak-ng
> > and to drop espeak?
> 
> Eventually we should do that, but for now I think we should provide the
> espeak that users are familiar with. I am not sure how much the
> interface has changed in espeak-ng, if at all. I'm going to try it out
> soon.

There's a WIP patch for espeak-ng available here if anyone wants to take
a crack at making it work:
https://github.com/lfam/guix/commits/contrib-espeak

I think the error it fails on is corrected on the git master branch.
I'll try it soon.

> 
> > 
> > Andreas
> > 
> 

[PATCH 3/5] gnu: Add python-astor.

[宋文武]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index e54f521..95e9a09 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -,3 +,26 @@ commandline applications.")
 
 (define-public python2-clint
   (package-with-python2 python-clint))
+
+(define-public python-astor
+  (package
+(name "python-astor")
+(version "0.5")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "astor" version))
+  (sha256
+   (base32
+"1fdafq5hkis1fxqlmhw0sn44zp2ar46nxhbc22cvwg7hsd8z5gsa"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(home-page "https://github.com/berkerpeksag/astor;)
+(synopsis "Read and write Python ASTs")
+(description
+ "Astor is designed to allow easy manipulation of Python source via the
+Abstract Syntax Tree.")
+(license bsd-3)))
+
+(define-public python2-astor
+  (package-with-python2 python-astor))
-- 
2.5.0

[PATCH 2/5] gnu: Add python-clint.

[宋文武]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 0886809..e54f521 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -6642,3 +6642,27 @@ the standard library.")
 
 (define-public python2-args
   (package-with-python2 python-args))
+
+(define-public python-clint
+  (package
+(name "python-clint")
+(version "0.5.1")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "clint" version))
+  (sha256
+   (base32
+"1an5lkkqk1zha47198p42ji3m94xmzx1a03dn7866m87n4r4q8h5"
+(build-system python-build-system)
+(inputs
+ `(("python-args" ,python-args)
+   ("python-setuptools" ,python-setuptools)))
+(home-page "https://github.com/kennethreitz/clint;)
+(synopsis "Command line interface tools")
+(description
+ "Clint is a Python module filled with a set of tools for developing
+commandline applications.")
+(license isc)))
+
+(define-public python2-clint
+  (package-with-python2 python-clint))
-- 
2.5.0

[PATCH 5/5] gnu: Add python-hy.

[宋文武]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index d4cc8d3..139c02e 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -6715,3 +6715,31 @@ with a new public API, and RPython support.")
 
 (define-public python2-rply
   (package-with-python2 python-rply))
+
+(define-public python-hy
+  (package
+(name "python-hy")
+(version "0.11.1")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "hy" version))
+  (sha256
+   (base32
+"1msqv747iz12r73mz4qvsmlwkddwjvrahlrk7ysrcz07h7dsscxs"
+(build-system python-build-system)
+(inputs
+ `(("python-astor" ,python-astor)
+   ("python-clint" ,python-clint)
+   ("python-rply" ,python-rply)
+   ("python-setuptools" ,python-setuptools)))
+(home-page "http://hylang.org/;)
+(synopsis "Lisp frontend to Python")
+(description
+ "Hy is a dialect of Lisp that's embedded in Python.
+
+Since Hy transforms its Lisp code into the Python Abstract Syntax Tree, you
+have the whole world of Python at your fingertips, in Lisp form.")
+(license license:expat)))
+
+(define-public python2-hy
+  (package-with-python2 python-hy))
-- 
2.5.0

[PATCH 4/5] gnu: Add python-rply.

[宋文武]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 95e9a09..d4cc8d3 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -6689,3 +6689,29 @@ Abstract Syntax Tree.")
 
 (define-public python2-astor
   (package-with-python2 python-astor))
+
+(define-public python-rply
+  (package
+(name "python-rply")
+(version "0.7.4")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "rply" version))
+  (sha256
+   (base32
+"12rp1d9ba7nvd5rhaxi6xzx1rm67r1k1ylsrkzhpwnphqpb06cvj"
+(build-system python-build-system)
+(inputs
+ `(("python-appdirs" ,python-appdirs)
+   ("python-setuptools" ,python-setuptools)))
+(home-page "")
+(synopsis
+ "Pure Python based parser that also works with RPython")
+(description
+ "This package provides a pure Python based parser generator, that also
+works with RPython.  It is a more-or-less direct port of David Bazzley's PLY,
+with a new public API, and RPython support.")
+(license bsd-3)))
+
+(define-public python2-rply
+  (package-with-python2 python-rply))
-- 
2.5.0

[PATCH 3/3] gnu: Add go-1.5.

[Efraim Flashner]

* gnu/packages/golang.scm (go-1.5): New variable.
---
 gnu/packages/golang.scm | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index cb1cbc1..6f281cf 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -91,4 +91,34 @@ garbage collection, various safety features and CSP-style 
concurrent programming
 features added.")
 (license license:bsd-3)))
 
-(define-public go go-1.4)
+(define-public go-1.5
+  (package (inherit go-1.4)
+(version "1.5.2")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append "https://storage.googleapis.com/golang/go;
+version ".src.tar.gz"))
+(sha256
+ (base32
+  "0x3sk32ym93hnc0yk6bnra226f92qvixia6kwcf68q84q0jddpgk"
+(arguments
+ (substitute-keyword-arguments (package-arguments go-1.4)
+   ((#:phases phases)
+`(modify-phases ,phases
+ (replace 'build
+  (let* ((bash   (assoc-ref %build-inputs "bash"))
+ (go14   (assoc-ref %build-inputs "go-1.4"))
+ (output (assoc-ref %outputs "out")))
+(setenv "CC" "gcc")
+(setenv "GOPATH" (string-append (getcwd) "/go"))
+(setenv "GOROOT_BOOTSTRAP" go14)
+(setenv "GOROOT_FINAL" output)
+(lambda _
+  (zero?
+(system* (string-append bash "/bin/bash") "make.bash")
+(native-inputs
+ `(("go-1.4" ,go-1.4)
+   ("perl" ,perl)
+
+(define-public go go-1.5)
-- 
2.7.0.rc3

[PATCH 1/3] gnu: gccgo: Update to 4.9.

[Efraim Flashner]

* gnu/packages/gcc.scm (gccgo): Update to 4.9.
---
 gnu/packages/gcc.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 2848e43..e336967 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -440,8 +440,8 @@ using compilers other than GCC."
 (define-public gfortran-5
   (custom-gcc gcc-5 "gfortran" '("fortran")))
 
-(define-public gccgo-4.8
-  (custom-gcc gcc-4.8 "gccgo" '("go")
+(define-public gccgo-4.9
+  (custom-gcc gcc-4.9 "gccgo" '("go")
   ;; Suppress the separate "lib" output, because otherwise the
   ;; "lib" and "out" outputs would refer to each other, creating
   ;; a cyclic dependency.  
-- 
2.7.0.rc3

[PATCH 0/3] WIP: Go-lang

[Efraim Flashner]

It seems there's a lot of interest around getting Go packaged in Guix, so I
figured I should post my work so far to the mailinglist. Currently go-1.4
does not have cgo enabled, the go binary keeps on trying to link against
libgcc_s.so.1 (from gcc:lib) and can't find it in the RUNPATH. Also, the
tests are disabled. Nix has a whole slew of changes to the test suite to
remove tests that call out to the internet and to change tests that
call /bin/{hostname,pwd} and others.

Go-1.4 is built using gccgo-4.9, and go-1.5 uses go-1.4 to build, so I'm
pretty confident that go-1.4 works, and since go-1.5 inherits from go-1.4
it should be working too.

I wanted to write the go-build-system before submitting, but everything I
know about go I learned while packaging it, so it doesn't seem fair to have
everyone wait while I prepare a build system that could be missing crucial
features. I still intend to work on the build system; I'm probably just
psyching myself out about it :).

Efraim Flashner (3):
  gnu: gccgo: Update to 4.9.
  gnu: Add go-1.4.
  gnu: Add go-1.5.

 gnu-system.am   |   1 +
 gnu/packages/gcc.scm|   4 +-
 gnu/packages/golang.scm | 124 
 3 files changed, 127 insertions(+), 2 deletions(-)
 create mode 100644 gnu/packages/golang.scm

--
2.7.0.rc3

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

[Ludovic Courtès]

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

> Andreas Enge  skribis:
>
>> On Wed, Jan 06, 2016 at 11:18:19PM +0100, Ludovic Courtès wrote:
>>> It has 140 dependent packages, including LibreOffice, so kinda
>>> borderline for master.  It’s probably safer on a separate branch that
>>> Hydra will build.  Mark?
>>
>> Finally hydra picked up the branch. Unfortunately, the new boost fails
>> to build on mips:
>>http://hydra.gnu.org/build/914532
>>
>> I find it difficult to see what is the problem in the build log
>> (C++, eh?)...
>
> The error is:
>
> gcc.compile.c++ 
> bin.v2/libs/context/build/gcc-4.9.3/release/threading-multi/unsupported.o
> libs/context/src/unsupported.cpp:7:2: error: #error "platform not supported"
>  #error "platform not supported"
>   ^

I cannot really decipher libs/context/build/Jamfile.v2, but I can see
that the only mentions of MIPS in there relate to the o32 ABI, whereas
we target n32.

Another thing that’s fishy in the build log is that, at the beginning of
the build phase, we see:

--8<---cut here---start->8---
Component configuration:

- atomic   : building
- chrono   : building
- container: building
- context  : not building
- coroutine: not building
--8<---cut here---end--->8---

Yet it attempts to build ‘context’.

> The options I can think of are:
>
>   1. Mark mips64el-linux as unsupported (134 packages depend on Boost,
>  notably LibreOffice, Abiword, and Ardour).
>
>   2. Build Boost without multi-threading support on MIPS, assuming it’s
>  only this feature that’s unsupported.
>
>   3. Hope that Debian has a patch to fix this and apply it.
>
> Thoughts?

I think we could try another option, which is to configure with

  --without-libraries=context

like openSuSE does in some cases:

   
https://build.opensuse.org/package/view_file/devel:libraries:c_c++/boost/boost.spec

Could someone try that?

If that fails, or if nobody can test it, let’s just do #1.

Ludo’.