Re: [PATCH] gnu: Add libjxr.

[Kei Kebreau]

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

> Leo Famulari  skribis:
>
>> On Sat, Oct 22, 2016 at 04:33:18AM -0400, Kei Kebreau wrote:
>
> [...]
>
>>> >> diff --git a/gnu/packages/patches/libjxr-use-cmake.patch
>>> >> b/gnu/packages/patches/libjxr-use-cmake.patch
>>> >> new file mode 100644
>>> >> index 000..cb5919e
>>> >> --- /dev/null
>>> >> +++ b/gnu/packages/patches/libjxr-use-cmake.patch
>>> >> @@ -0,0 +1,143 @@
>>> >> +Description: Prefer a cmake based build system
>>> >> +Author: Mathieu Malaterre 
>>> >> +Forwarded: https://jxrlib.codeplex.com/discussions/440294
>>> >
>>> > Why doesn't upstream's build system work?
>>> 
>>> Upstream's build system simply doesn't have configuration or
>>> installation targets in the provided Makefile. Using the cmake patch
>>> makes the definition cleaner at the cost of relying on outside work
>>> [1]. If this is not acceptable, I can see about writing manual
>>> replacement phases to the best of my ability.
>>> 
>>> [1]: https://jxrlib.codeplex.com/discussions/440294
>>
>> Hm, not an ideal situation.
>>
>> If Debian is using this patch, we should link to it's source on Debian's
>> site instead of this message board. I don't know enough about CMake to
>> judge the patch but I'd be more comfortable if Debian was using it.
>>
>> What do others think?
>
> Regarding the choice between writing our own installation phase in
> Scheme and using this CMake thing instead, I think we should choose the
> most concise approach (in terms of lines of code).
>
> If the winner here is the CMake patch, then indeed, we should take the
> patch from Debian rather than from a message board (and include
> provenance information in the patch, as you wrote.)
>
> That said, I suspect an ‘install’ phase in Scheme would be more concise
> than this new CMakeLists.txt (134 lines).
>
> Kei: WDYT?
>

I have been working on writing our own installation phase, and it looks
like it will be more concise. However, the patches need to be in DOS
format to apply. The patch doesn't seem to carry these line returns,
which leads me to believe that a standard git configuration won't accept
them. Is there way around this?

> Thanks!
>
> Ludo’.


signature.asc
Description: PGP signature

Re: [PATCH] Add libdispatch

[Ricardo Wurmus]

ng0  writes:

> libdispatch:
> I think that the compiler can only find libblocks-runtime on a bsd system and 
> that the port can not run tests.
> This is my theory, I must put it to practice, the new nvidia-texture-tools(?) 
> required libdispatch which is why I packaged this.
> This was before the current version got released, I assume it's still 
> required.
>
> [PATCH 1/4] gnu: Add libkque.
> [PATCH 2/4] gnu: Add libpthread_workqueue.
> [PATCH 3/4] gnu: Add libblocks-runtime.
> [PATCH 4/4] gnu: Add libdispatch.

I don’t know what this means.  If this isn’t actually working on a GNU
system I’d like to suggest to wait until you can confirm that it does.
If you need “nvidia-texture-tools” and that requires libdispatch then
please test that it does in fact work.

If you have no need for libdispatch and it seems that it’s not working
I’d rather not have it in Guix.

~~ Ricardo

Re: [PATCH 4/4] gnu: r-nmf: Use bigmemory.

[Ricardo Wurmus]

Roel Janssen  writes:

> * gnu/packages/statistics.scm (r-nmf): Use bigmemory.

* gnu/packages/statistics.scm (r-nmf)[propagated-inputs]: Add
r-bigmemory and r-synchronicity.

> ---
>  gnu/packages/statistics.scm | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
> index 478e1a5..35f65e5 100644
> --- a/gnu/packages/statistics.scm
> +++ b/gnu/packages/statistics.scm
> @@ -2868,6 +2868,8 @@ memory-mapped files.")
>  (build-system r-build-system)
>  (propagated-inputs
>   `(("r-cluster" ,r-cluster)
> +   ("r-bigmemory" ,r-bigmemory)
> +   ("r-synchronicity" ,r-synchronicity)
> ("r-colorspace" ,r-colorspace)
> ("r-digest" ,r-digest)
> ("r-doparallel" ,r-doparallel)

Okay!

~~ Ricardo

Re: [PATCH 3/4] gnu: Add r-bigmemory.

[Ricardo Wurmus]

Roel Janssen  writes:

> * gnu/packages/statistics.scm (r-bigmemory): New variable.
> ---
>  gnu/packages/statistics.scm | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
> index a50e792..478e1a5 100644
> --- a/gnu/packages/statistics.scm
> +++ b/gnu/packages/statistics.scm
> @@ -2829,6 +2829,30 @@ message passing.")
>  bigmemory and synchronicity packages.")
>  (license (list license:lgpl3 license:asl2.0
>  
> +(define-public r-bigmemory
> +  (package
> +(name "r-bigmemory")
> +(version "4.5.19")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (cran-uri "bigmemory" version))
> +   (sha256
> +(base32
> + "191gbzca557kpk7mdsg716vfyqpr7j5din6qb8hin4g1nkzzwmg6"
> +(build-system r-build-system)
> +(propagated-inputs
> + `(("r-bh" ,r-bh)
> +   ("r-rcpp" ,r-rcpp)
> +   ("r-bigmemory-sri" ,r-bigmemory-sri)
> +   ("r-r-utils" ,r-r-utils)))
> +(home-page "http://www.bigmemory.org";)
> +(synopsis "Manage large matrices with shared memory or memory-mapped 
> files")
> +(description "This package provides methods to Create, store,
> access, and

“Create” –> “create”

> +manipulate large matrices.  Matrices are allocated to shared memory and may 
> use
> +memory-mapped files.")
> +(license (list license:lgpl3 license:asl2.0
> +

Same question as before: what does this list mean?  And: are you sure
it’s LGPLv3 only?

~~ Ricardo

Re: [PATCH 2/4] gnu: Add r-bigmemory-sri.

[Ricardo Wurmus]

Roel Janssen  writes:

> * gnu/packages/statistics.scm (r-bigmemory-sri): New variable.
> ---
>  gnu/packages/statistics.scm | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
> index 9e2d4a9..a50e792 100644
> --- a/gnu/packages/statistics.scm
> +++ b/gnu/packages/statistics.scm
> @@ -2810,6 +2810,25 @@ via mutexes and may eventually support interprocess 
> communication and
>  message passing.")
>  (license (list license:lgpl2.1 license:asl2.0
>  
> +(define-public r-bigmemory-sri
> +  (package
> +(name "r-bigmemory-sri")
> +(version "0.1.3")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (cran-uri "bigmemory.sri" version))

I think this should have a property to record the upstream name to help
the updater.

> +   (sha256
> +(base32
> + "0mg14ilwdkd64q2ri9jdwnk7mp55dqim7xfifrs65sdsv1934h2m"
> +(build-system r-build-system)
> +(home-page
> + "http://cran.r-project.org/web/packages/bigmemory.sri";)

Please pull them onto one line.

> +(synopsis "A shared resource interface for the bigmemory
> package")

Don’t start with “A”.

> +(description "This package provides a shared resource interface for the
> +bigmemory and synchronicity packages.")
> +(license (list license:lgpl3 license:asl2.0

What does this list mean?
Also: is this LGPL3+ or LGPL3 only?

~~ Ricardo

Re: [PATCH 1/4] gnu: Add r-synchronicity.

[Ricardo Wurmus]

Roel Janssen  writes:

> * gnu/packages/statistics.scm (r-synchronicity): New variable.
> ---
>  gnu/packages/statistics.scm | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
> index b15f9cf..9e2d4a9 100644
> --- a/gnu/packages/statistics.scm
> +++ b/gnu/packages/statistics.scm
> @@ -2787,6 +2787,29 @@ Fourier transform, fuzzy clustering, support vector 
> machines, shortest path
>  computation, bagged clustering, naive Bayes classifier, and more.")
>  (license license:gpl2+)))
>  
> +(define-public r-synchronicity
> +  (package
> +(name "r-synchronicity")
> +(version "1.1.9.1")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (cran-uri "synchronicity" version))
> +   (sha256
> +(base32
> + "0d9skpwmsnkn4xb3f2kgyyv8bhdi0r9p1kj3cvi0s92fjjnpi00c"
> +(build-system r-build-system)
> +(propagated-inputs
> + `(("r-bh" ,r-bh)
> +   ("r-bigmemory-sri" ,r-bigmemory-sri)
> +   ("r-rcpp" ,r-rcpp)))
> +(home-page "http://www.bigmemory.org";)
> +(synopsis "Boost mutex functionality in R")
> +(description "This package provides support for synchronization
> +via mutexes and may eventually support interprocess communication and
> +message passing.")
> +(license (list license:lgpl2.1 license:asl2.0
> +
>  (define-public r-nmf
>(package
>  (name "r-nmf")

The order of patches is wrong.  Since this depends on “r-bigmemory-sri”
it ought to be committed after it.

Other than that it’s fine.  Thanks!

~~ Ricardo

Re: [PATCH 3/5] gnu: Add ghc-data-access-transformers.

[Ricardo Wurmus]

Federico Beffa  writes:

> On Fri, Oct 28, 2016 at 3:44 PM, Ludovic Courtès  wrote:
>> Federico Beffa  skribis:
>>> +(synopsis "Use Accessor to access state in transformers State monad")
>>
>> I can’t parse “transformers State monad”, but maybe it’s just me, or is
>> it missing a word, like “transformers of the State monad”, “State monad
>> transformers”?
>
> The way I understand it is: "transformers State monad" stands for the
> transformer monad called StateT, itself a monad.  But I'll let you or
> a native English speaker decide about the grammatical correctness of
> the synopsis provided by the author :-)

“transformers” is a package providing monad transformers.  But even
after looking at the code I can’t quite make sense of the synopsis :)

It provides functions that take accessors and return State and
Read-Write-State monad transformers.

~~ Ricardo

Re: Building packages with python-3.4

[Ricardo Wurmus]

Leo Famulari  writes:

> On Mon, Oct 24, 2016 at 10:58:38PM +0200, Ludovic Courtès wrote:
>> Leo Famulari  skribis:
>> 
>> > On core-updates, we updated python to 3.5.2, but we kept 3.4.5 in case
>> > we needed it.
>> >
>> > I recently tried building python-cryptography with 3.4.5, like this:
>> >
>> > (arguments
>> >  `(#:python ,python-3.4))
>> >
>> > But, it fails like this:
>> >
>> > patch-shebang: ./setup.py: warning: no binary for interpreter `python' 
>> > found in $PATH
>> 
>> I think you need to write:
>> 
>>   (arguments
>>`(#:python ,(wrap-python3 python-3.4)))
>> 
>> That will provide ‘python’ and other commands without the ‘3’ prefix.
>
> Thanks!
>
> I tried this to fix the build failure of Blender on core-updates, and it
> did work. But in the end I instead updated Blender to the latest
> version, which supports Python 3.5.

Heh, I was waiting for the Python upgrade to upgrade Blender but didn’t
manage to do it without my laptop freezing.  Thanks for taking care of
this!

~~ Ricardo

Re: [PATCH] gnu: vim: Update to 8.0.0047.

[Marius Bakke]

Ricardo Wurmus  writes:

>>> Guix can handle downloading patches, so there’s really no need for
>>> switching in my opinion.  “gnu/packages/bash.scm” could be used as a
>>> reference for how to deal with a large number of patches.
>>
>> vim-7.4 ended at 2367 patches[0]. 8.0 is currently at 51 (four since
>> yesterday!), whereas bash has 42, so they are not really comparable. I
>> think vim would rarely be updated, if it required downloading and
>> creating potentially hundreds of patch references at once.
>>
>> They are also not signed, though we could rely on the MD5SUMS file.
>>
>> With this information, do you still think a custom patch importer is
>> better? I don't really mind either way, but someone needs to make it :)
>
> No, you convinced me :)  Thanks for your patience!

Thanks for questioning my oft-rushed conclusions! :)
I updated vim in a9afb956b3232ccfb7deaf3feed02b60a12d65bf.


signature.asc
Description: PGP signature

[PATCH v3 1/1] gnu: Add plantuml.

[Theodoros Foradis]

* gnu/packages/uml.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
---
 gnu/local.mk |  1 +
 gnu/packages/uml.scm | 87 
 2 files changed, 88 insertions(+)
 create mode 100644 gnu/packages/uml.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index 0d400e9..595a5bd 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -357,6 +357,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/tmux.scm\
   %D%/packages/tor.scm \
   %D%/packages/tv.scm  \
+  %D%/packages/uml.scm \
   %D%/packages/unrtf.scm   \
   %D%/packages/upnp.scm\
   %D%/packages/uucp.scm\
diff --git a/gnu/packages/uml.scm b/gnu/packages/uml.scm
new file mode 100644
index 000..ae1af41
--- /dev/null
+++ b/gnu/packages/uml.scm
@@ -0,0 +1,87 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Theodoros Foradis 
+;;;
+;;; 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 uml)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix utils)
+  #:use-module (guix build-system ant)
+  #:use-module (gnu packages bash)
+  #:use-module (gnu packages graphviz)
+  #:use-module (gnu packages java))
+
+(define-public plantuml
+  (package
+(name "plantuml")
+(version "8048")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"mirror://sourceforge/plantuml/plantuml-"
+version ".tar.gz"))
+  (sha256
+   (base32
+"1vipxd6p7isb1k1qqh4hrpfcj27hx1nll2yp0rfwpvps1w2d936i"
+(build-system ant-build-system)
+(arguments
+ `(#:tests? #f ; no tests
+   #:build-target "dist"
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'build 'delete-extra-from-cp
+   (lambda _
+ (substitute* "build.xml"
+   (("1.6") "1.7")
+   (("") "-->"))
+ #t))
+ (add-before 'install 'gen-install
+   (lambda* (#:key outputs #:allow-other-keys)
+ (mkdir-p "build/jar")
+ (system* "mv" "plantuml.jar" "build/jar")
+ ((@@ (guix build ant-build-system) default-build.xml)
+  "plantuml.jar"
+  (string-append (assoc-ref outputs "out")
+ "/share/java"))
+ #t))
+ (add-after 'install 'make-wrapper
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(wrapper (string-append out "/bin/plantuml")))
+   (mkdir-p (string-append out "/bin"))
+   (with-output-to-file wrapper
+ (lambda _
+   (display
+(string-append
+ "#!/bin/sh\n\n"
+ (assoc-ref inputs "jre") "/bin/java -jar "
+ out "/share/java/plantuml.jar \"$@\"\n"
+   (chmod wrapper #o555))
+ #t)
+(inputs
+ `(("graphviz" ,graphviz)
+   ("jre" ,icedtea)))
+(home-page "http://plantuml.com/";)
+(synopsis "Draw UML diagrams from simple textual description")
+(description
+ "Plantuml is a tool to generate sequence, usecase, class, activity,
+component, state, deployment and object UML diagrams, using a simple and
+human readable text description.  Contains @code{salt}, a tool that can design
+simple graphical interfaces.")
+(license license:gpl3+)))
-- 
2.10.1

Re: [PATCH v2 1/1] gnu: Add plantuml.

[Theodoros Foradis]

>> +(home-page "http://plantuml.com/";)
>> +(synopsis "Draw UML diagrams from simple textual description")
>> +(description
>> + "Plantuml is a tool to generate sequence, usecase, class,
>> activity,
>
> Is “usecase” a word or should it be “use case”?
>

It is a word. I reply with the changes you suggested, with no change in the 
build procedure.

Theodoros Foradis (1):
  gnu: Add plantuml.

 gnu/local.mk |  1 +
 gnu/packages/uml.scm | 87 
+++
 2 files changed, 88 insertions(+)

Re: [PATCH 2/2] gnu: Add emacs-org-trello.

[Roel Janssen]

Ricardo Wurmus writes:

> Roel Janssen  writes:
>
>> So, the only proper way to do it, is to manually add a test phase in
>> each package definition.  But then we still have to add a lot of
>> dependencies that are only needed to run the tests, and even then the
>> tests don't say much..  In the case of this package, the test functions
>> can't run because they use functions that aren't loaded yet, which
>> results in failures of the tests (while the package works just fine).
>>
>> Could I therefore, please, go ahead and push the patch without the
>> additional inputs for running tests?
>
> Yes, please do!  I was just curious.  Sorry for delaying this!
>
> ~~ Ricardo

Pushed in 36e5d1038 and ed8bc028f.

Thanks!

[PATCH v3 3/3] gnu: Add openocd.

[Theodoros Foradis]

* gnu/packages/embedded.scm (openocd): New variable.
* gnu/packages/patches/openocd-nrf52.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add the patch.
---
 gnu/local.mk |   1 +
 gnu/packages/embedded.scm|  64 +++
 gnu/packages/patches/openocd-nrf52.patch | 843 +++
 3 files changed, 908 insertions(+)
 create mode 100644 gnu/packages/patches/openocd-nrf52.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index ff2d976..286d3af 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -741,6 +741,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/openjpeg-CVE-2016-5157.patch\
   %D%/packages/patches/openjpeg-CVE-2016-7163.patch\
   %D%/packages/patches/openjpeg-use-after-free-fix.patch   \
+  %D%/packages/patches/openocd-nrf52.patch \
   %D%/packages/patches/openssh-memory-exhaustion.patch \
   %D%/packages/patches/openssl-runpath.patch   \
   %D%/packages/patches/openssl-1.1.0-c-rehash-in.patch \
diff --git a/gnu/packages/embedded.scm b/gnu/packages/embedded.scm
index 0b4f9ab..f3aec81 100644
--- a/gnu/packages/embedded.scm
+++ b/gnu/packages/embedded.scm
@@ -28,11 +28,15 @@
   #:use-module (guix build-system trivial)
   #:use-module (guix build utils)
   #:use-module (gnu packages)
+  #:use-module (gnu packages autotools)
   #:use-module (gnu packages cross-base)
   #:use-module (gnu packages flex)
   #:use-module (gnu packages gcc)
   #:use-module (gnu packages gdb)
+  #:use-module (gnu packages libftdi)
+  #:use-module (gnu packages libusb)
   #:use-module (gnu packages perl)
+  #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages texinfo))
 
 ;; We must not use the released GCC sources here, because the cross-compiler
@@ -236,3 +240,63 @@ languages are C and C++.")
"--enable-languages=c,c++"
"--disable-nls")
  ,@(package-arguments gdb)
+
+;; We build openocd from git, because the JTAG library libjaylink
+;; is not included in tarball releases.
+(define-public openocd
+  (let* ((commit "674141e8a7a6413cb803d90c2a20150260015f81")
+ (revision "1"))
+(package
+  (name "openocd")
+  (version (string-append "0.9.0-" revision "."
+  (string-take commit 7)))
+  (source (origin
+(method git-fetch)
+(uri (git-reference
+  (url (string-append "git://git.code.sf.net/p/" name 
"/code.git"))
+  (commit commit)
+  (recursive? #t)))
+(sha256
+ (base32 
"0p8rcqhkx3f29j08w33fkp8xnzj4xxa41lzdfq5wd1i4x8s07s0p"))
+(file-name (string-append name "-" version "-checkout"))
+(patches
+ (search-patches "openocd-nrf52.patch"
+  (build-system gnu-build-system)
+  (arguments
+   '(#:configure-flags
+ (append (list "--disable-werror")
+ (map (lambda (programmer)
+(string-append "--enable-" programmer))
+  '("amtjtagaccel" "armjtagew" "buspirate" "ftdi"
+"gw16012" "jlink" "oocd_trace" "opendous" "osbdm"
+"parport" "aice" "cmsis-dap" "dummy" "jtag_vpi" 
"remote-bitbang"
+"rlink" "stlink" "ti-icdi" "ulink" "usbprog" "vsllink"
+"usb-blaster-2" "usb_blaster" "presto" "openjtag")))
+ #:phases
+ (modify-phases %standard-phases
+   (add-before 'configure 'autoreconf
+ (lambda _
+   (zero? (system* "autoreconf" "-vfi"
+   (add-after 'autoreconf 'patch-configure
+ (lambda _
+   (substitute* "configure"
+ (("srcdir/src/jtag/drivers/libjaylink/configure.gnu") ""))
+   #t)
+  (inputs
+   `(("hidapi" ,hidapi)
+ ("libftdi" ,libftdi)
+ ("libusb" ,libusb)
+ ("libusb-compat" ,libusb-compat)))
+  (native-inputs
+   `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("libtool" ,libtool)
+ ("pkg-config" ,pkg-config)))
+  (home-page "http://openocd.org";)
+  (synopsis "On-Chip Debugger")
+  (description
+   "OpenOCD provides on-chip programming and debugging support with a
+layered architecture of JTAG interface and TAP support.")
+  (license (list license:gpl2   ; openocd and git2cl submodule
+ license:gpl2+  ; libjaylink submodule
+ license:bsd-2) ; jimctl submodule
diff --git a/gnu/packages/patches/openocd-nrf52.patch 
b/gnu/packages/patches/openocd-nrf52.patch
new file mode 100644
index 000..792575d
--- /dev/null
+++ b/gnu/packages/patches/openocd-nrf52.patch
@@ -0,0 +1,843 @@
+This patch adds support for nRF52 series devices.  It is patchset 

[PATCH v3 2/3] gnu: Add hidapi.

[Theodoros Foradis]

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

diff --git a/gnu/packages/libusb.scm b/gnu/packages/libusb.scm
index 0071f4f..fe1bed1 100644
--- a/gnu/packages/libusb.scm
+++ b/gnu/packages/libusb.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2015 Andy Wingo 
 ;;; Copyright © 2015, 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 Efraim Flashner 
+;;; Copyright © 2016 Theodoros Foradis 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -29,6 +30,7 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system glib-or-gtk)
   #:use-module (guix build-system python)
+  #:use-module (gnu packages autotools)
   #:use-module (gnu packages gnupg)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages linux)
@@ -201,3 +203,39 @@ proposed for standardization.")
   (MTP), which allows media files to be transferred to and from many portable
 devices.")
 (license bsd-3)))
+
+(define-public hidapi
+  (package
+(name "hidapi")
+(version "0.8.0-rc1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append 
"https://github.com/signal11/hidapi/archive/hidapi-";
+  version ".tar.gz"))
+  (sha256
+   (base32
+"0qdgyj9rgb7n0nk3ghfswrhzzknxqn4ibn3wj8g4r828pw07451w"
+(build-system gnu-build-system)
+(arguments
+ '(#:phases
+   (modify-phases %standard-phases
+ (add-before 'configure 'bootstrap
+   (lambda _
+ (zero? (system* "autoreconf" "-vfi")))
+(inputs
+ `(("libusb" ,libusb)
+   ("udev" ,eudev)))
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("automake" ,automake)
+   ("libtool" ,libtool)
+   ("pkg-config" ,pkg-config)))
+(home-page "http://www.signal11.us/oss/hidapi/";)
+(synopsis "HID API library")
+(description
+ "HIDAPI is a library which allows an application to interface with USB 
and Bluetooth
+HID-Class devices.")
+;; HIDAPI can be used under one of three licenses.
+(license (list gpl3
+   bsd-3
+   non-copyleft "file://LICENSE-orig.txt"
-- 
2.10.1

Re: [PATCH v2 3/3] gnu: Add openocd.

[Theodoros Foradis]

Ricardo Wurmus writes:

> Theodoros Foradis  writes:
>
>> +;; We build openocd from git, because the JTAG library libjaylink
>> +;; is not included in tarball releases.
>
> Is there a separate release of libjaylink?  Does the git version bundle
> libjaylink?  I’d prefer packaging proper releases of libjaylink and
> openocd, if that’s the case.
>

The git version does not bundle libjaylink. It is included in a
submodule. Should it be make clear in that initial comment?

>> +(define-public openocd
>> +  (let* ((commit "674141e8a7a6413cb803d90c2a20150260015f81")
>> + (revision "1"))
>> +(package
>> +  (name "openocd")
>> +  (version (string-append "0.9.0-" revision "."
>> +  (string-take commit 7)))
>> +  (source (origin
>> +(method git-fetch)
>> +(uri (git-reference
>> +  (url (string-append "git://git.code.sf.net/p/" name 
>> "/code.git"))
>> +  (commit commit)
>> +  (recursive? #t)))
>> +(sha256
>> + (base32 
>> "0p8rcqhkx3f29j08w33fkp8xnzj4xxa41lzdfq5wd1i4x8s07s0p"))
>> +(file-name (string-append name "-" version 
>> "-checkout.tar.xz"))
>> +(patches
>> + (search-patches "openocd-nrf52.patch"
>> +  (build-system gnu-build-system)
>> +  (arguments
>> +   '(#:configure-flags
>> + (append (list "--disable-werror")
>> + (map (lambda (programmer)
>> +(string-append "--enable-" programmer))
>> +  '("amtjtagaccel" "armjtagew" "buspirate" "ftdi"
>> +"gw16012" "jlink" "oocd_trace" "opendous" "osbdm"
>> +"parport" "aice" "cmsis-dap" "dummy" "jtag_vpi" 
>> "remote-bitbang"
>> +"rlink" "stlink" "ti-icdi" "ulink" "usbprog" 
>> "vsllink"
>> +"usb-blaster-2" "usb_blaster" "presto" "openjtag")))
>> + #:phases
>> + (modify-phases %standard-phases
>> +   (add-before 'configure 'autoreconf
>> + (lambda _
>> +   (zero? (system* "autoreconf" "-vfi"
>> +   (add-after 'autoreconf 'patch-configure
>> + (lambda _
>> +   (substitute* "configure"
>> + (("SHELL = /bin/sh") (string-append "SHELL = "
>> (which "sh"
>
> Is this really necessary?  Or can we just pass “SHELL” as a configure
> flag to override?
>

This is in fact not necessary, and removed.

>> +   (substitute* "configure"
>> + (("srcdir/src/jtag/drivers/libjaylink/configure.gnu")
>> +  (string-append "echo -e '#!" (which "sh") "\nexec 
>> \"`dirname \"'\\$'0\"`
>> +/configure\" --enable-subproject-build \"'\\$'@\"' > \"
>> +$srcdir/src/jtag/drivers/libjaylink/configure.gnu\"")))
>
> This isn’t clear to me.  What happens here?  Why is the additional
> configure flag needed?  Could you add a comment as to the intent of this
> substitution?
>

This substitution was changed, to substitute with an empty string. The
actual intention of the substitution was to replace /bin/sh in the generated
configure.gnu, which proved to be unneeded, so it's just removed, and
the file will be run with the correct /bin/sh.

>> +   #t)
>> +  (inputs
>> +   `(("hidapi" ,hidapi)
>> + ("libftdi" ,libftdi)
>> + ("libusb" ,libusb)
>> + ("libusb-compat" ,libusb-compat)))
>
> Both libusb AND libusb-compat?
>

Yes, it won't build without both.

>> +  (native-inputs
>> +   `(("autoconf" ,autoconf)
>> + ("automake" ,automake)
>> + ("libtool" ,libtool)
>> + ("pkg-config" ,pkg-config)))
>> +  (home-page "http://openocd.org";)
>> +  (synopsis "Open On-Chip Debugger")
>
> s/Open//
>
> I know that that’s what OpenOCD stands for, but everything is free
> software (or “open source”) in Guix anyway, so we usually don’t mention
> “free” or “open”.
>

Understood. I removed it.

>> +  (description
>> +   "OpenOCD provides on-chip programming and debugging support with a
>> +layered architecture of JTAG interface and TAP support.")
>> +  (license (list license:gpl2   ;; openocd and git2cl submodule
>> + license:gpl2+  ;; libjaylink submodule
>> + license:bsd-2) ;; jimctl submodule
>
> Please use a single “;” for margin comments like this.
>

Done.

>> diff --git a/gnu/packages/patches/openocd-nrf52.patch 
>> b/gnu/packages/patches/openocd-nrf52.patch
>> new file mode 100644
>> index 000..d136735
>> --- /dev/null
>> +++ b/gnu/packages/patches/openocd-nrf52.patch
>> @@ -0,0 +1,843 @@
>> +This patch adds support for nRF52 series devices. It is patchset 7 from
>> +http://openocd.zylin.com/#/c/3511/ , which has been tested, but not
>> +merged yet in master.
>
> Nitpick: please use two spaces between sentences and surround the

[PATCH v3 1/3] gnu: Add gdb-arm-none-eabi.

[Theodoros Foradis]

* gnu/packages/embedded.scm (gdb-arm-none-eabi): New variable.
---
 gnu/packages/embedded.scm | 13 +
 1 file changed, 13 insertions(+)

diff --git a/gnu/packages/embedded.scm b/gnu/packages/embedded.scm
index a7af69f..0b4f9ab 100644
--- a/gnu/packages/embedded.scm
+++ b/gnu/packages/embedded.scm
@@ -31,6 +31,7 @@
   #:use-module (gnu packages cross-base)
   #:use-module (gnu packages flex)
   #:use-module (gnu packages gcc)
+  #:use-module (gnu packages gdb)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages texinfo))
 
@@ -223,3 +224,15 @@ languages are C and C++.")
 (define-public arm-none-eabi-nano-toolchain-6
   (arm-none-eabi-toolchain gcc-arm-none-eabi-6
newlib-nano-arm-none-eabi))
+
+(define-public gdb-arm-none-eabi
+  (package
+(inherit gdb)
+(name "gdb-arm-none-eabi")
+(arguments
+ `(#:configure-flags '("--target=arm-none-eabi"
+   "--enable-multilib"
+   "--enable-interwork"
+   "--enable-languages=c,c++"
+   "--disable-nls")
+ ,@(package-arguments gdb)
-- 
2.10.1

Re: Workflow management with GNU Guix

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen  skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> So I guess that’s an argument in favor of the approach you chose.
>>
>> Can't a derivation write its output to some other place than the store?
>> Maybe by running it "by hand"?
>
> Yes, if you run it “by hand”, then you can tweak things as you see fit.
>
>>> Fundamentally, a derivation just describes a command, its arguments, its
>>> dependencies, its outputs, and its environment variables.
>>>
>>> So you’re right: you can very much run a derivation “by hand” instead of
>>> letting the daemon do it on your behalf.  The only difference is that
>>> you won’t have write access to the store.
>>
>> And that's fine, because we don't want to write the output to the store :).
>>
>> So, the workflow language should create a derivation, but then
>> guix-daemon should not execute the derivation, but instead, the workflow
>> execution engine can do it so it can avoid writing the output to the
>> store.. right?
>
> Right.  In addition to the snippet I gave, you’d need to set the
> environment variables that are specified in the derivation.
>
> For each output of the derivation, one environment variable is defined
> that points to its /gnu/store/… file name.  So for instance, you’d also
> need to do:
>
>   (setenv "out" "/home/roel/something")
>
> if you want to “redirect” the “out” output to a place that’s not its
> normal place in the store.
>
> With user namespaces, you could simply bind mount /home/roel/something
> to /gnu/store/… in the process that runs the derivation builder, instead
> using of the ‘setenv’ hack above.

Ideally, we would do the equivalent of @code{guix environment
--container --ad-hoc --pure }  and execute the programs inside
the environment.  Unfortunately, that requires super user privileges as
well (for good reasons!).

It would be great to build this in though.. just for those who want to
do things properly and have the luxury of doing so...

I'll try to implement this in the upcoming week(s) so we have something
to try out.

Kind regards,
Roel Janssen

Re: [PATCH] gnu: vim: Update to 8.0.0047.

[Ricardo Wurmus]

Marius Bakke  writes:

> Ricardo Wurmus  writes:
>
>> Marius Bakke  writes:
>>
>>> The official vim mirrors only carries major versions and individual
>>> patches, no up-to-date releases. This patch changes the source uri to
>>> the tagged github releases instead of downloading all 40+ (so far)
>>> patches individually.
>>>
>>> I'm not very happy about changing to a third-party source, but IMO it
>>> beats keeping track of the frequent patches. WDYT?
>>
>> I’m also not happy about using a third-party mirror for vim.  Can we be
>> sure that this is updated consistently and in time?  (Is this done
>> automatically?)
>
> When I sent this, the 0047 release was about an hour old and the
> corresponding patch was not yet available on ftp.vim.org. So it seems
> to be the other way around. The "vim" organization on Github is endorsed
> on vim.org and maintained by Bram Molenaar himself.

Ah, cool.  This makes all the difference, IMO.

>> Guix can handle downloading patches, so there’s really no need for
>> switching in my opinion.  “gnu/packages/bash.scm” could be used as a
>> reference for how to deal with a large number of patches.
>
> vim-7.4 ended at 2367 patches[0]. 8.0 is currently at 51 (four since
> yesterday!), whereas bash has 42, so they are not really comparable. I
> think vim would rarely be updated, if it required downloading and
> creating potentially hundreds of patch references at once.
>
> They are also not signed, though we could rely on the MD5SUMS file.
>
> With this information, do you still think a custom patch importer is
> better? I don't really mind either way, but someone needs to make it :)

No, you convinced me :)  Thanks for your patience!

~~ Ricardo

Re: [PATCH 5/5] gnu: Add ghc-gnuplot.

[Federico Beffa]

On Fri, Oct 28, 2016 at 3:45 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
> [...]
>
>> +(propagated-inputs `(("gnuplot" ,gnuplot)))
>
> Instead of propagating it, could we instead replace “gnuplot” with
> “/gnu/store/…/bin/gnuplot” in the relevant source file?

Good idea and easy to implement. I'll do it.

Thanks,
Fede

Re: [PATCH] gnu: vim: Update to 8.0.0047.

[Marius Bakke]

Ricardo Wurmus  writes:

> Marius Bakke  writes:
>
>> The official vim mirrors only carries major versions and individual
>> patches, no up-to-date releases. This patch changes the source uri to
>> the tagged github releases instead of downloading all 40+ (so far)
>> patches individually.
>>
>> I'm not very happy about changing to a third-party source, but IMO it
>> beats keeping track of the frequent patches. WDYT?
>
> I’m also not happy about using a third-party mirror for vim.  Can we be
> sure that this is updated consistently and in time?  (Is this done
> automatically?)

When I sent this, the 0047 release was about an hour old and the
corresponding patch was not yet available on ftp.vim.org. So it seems
to be the other way around. The "vim" organization on Github is endorsed
on vim.org and maintained by Bram Molenaar himself.

> Guix can handle downloading patches, so there’s really no need for
> switching in my opinion.  “gnu/packages/bash.scm” could be used as a
> reference for how to deal with a large number of patches.

vim-7.4 ended at 2367 patches[0]. 8.0 is currently at 51 (four since
yesterday!), whereas bash has 42, so they are not really comparable. I
think vim would rarely be updated, if it required downloading and
creating potentially hundreds of patch references at once.

They are also not signed, though we could rely on the MD5SUMS file.

With this information, do you still think a custom patch importer is
better? I don't really mind either way, but someone needs to make it :)

0: http://ftp.vim.org/pub/vim/patches/7.4/


signature.asc
Description: PGP signature

Re: Building packages with python-3.4

[Leo Famulari]

On Mon, Oct 24, 2016 at 10:58:38PM +0200, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > On core-updates, we updated python to 3.5.2, but we kept 3.4.5 in case
> > we needed it.
> >
> > I recently tried building python-cryptography with 3.4.5, like this:
> >
> > (arguments
> >  `(#:python ,python-3.4))
> >
> > But, it fails like this:
> >
> > patch-shebang: ./setup.py: warning: no binary for interpreter `python' 
> > found in $PATH
> 
> I think you need to write:
> 
>   (arguments
>`(#:python ,(wrap-python3 python-3.4)))
> 
> That will provide ‘python’ and other commands without the ‘3’ prefix.

Thanks!

I tried this to fix the build failure of Blender on core-updates, and it
did work. But in the end I instead updated Blender to the latest
version, which supports Python 3.5.

Re: [PATCH 2/2] gnu: Add emacs-org-trello.

[Ricardo Wurmus]

Roel Janssen  writes:

> So, the only proper way to do it, is to manually add a test phase in
> each package definition.  But then we still have to add a lot of
> dependencies that are only needed to run the tests, and even then the
> tests don't say much..  In the case of this package, the test functions
> can't run because they use functions that aren't loaded yet, which
> results in failures of the tests (while the package works just fine).
>
> Could I therefore, please, go ahead and push the patch without the
> additional inputs for running tests?

Yes, please do!  I was just curious.  Sorry for delaying this!

~~ Ricardo

Re: [PATCH] gnu: Add radeontop.

[Tobias Geerinckx-Rice]

Ludo',

On 28/10/16 15:49, Ludovic Courtès wrote:
> We can add ‘supported-systems’ later if/when we have evidence that it
> doesn’t build on other arches.

OK!

> You could move ‘home-page’ above ‘source’ and reference it here.

Done. Nice to know that's not considered over-factorisation; I quite
like it.

>> +(license license:gpl3)))
> It’s indeed v3-only, bah.

Yup :-/

Because you never know what those freedom-smoking hippies at the FSF
will come up with in future.

Thanks!

T G-R



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] gnu: Add emacs-org-trello.

[Federico Beffa]

On Fri, Oct 28, 2016 at 11:30 AM, Alex Kost  wrote:
> Ricardo Wurmus (2016-10-27 20:48 +0200) wrote:
>
>> Alex Kost  writes:
>>
 @Alex: could you please confirm this?  Should these inputs be mentioned
 at all?  If so, is it sufficient to add them to native-inputs?
>>>
>>> As for me, I don't see a reason to add these additional inputs,
>>> emacs-build-system will not run tests anyway.
>>
>> Thank you for clarifying.
>>
>> Is there a reason why we don’t run the tests?  We do this by default for
>> all other packages.
>
> How can it be done?  There is no common way for emacs packages to
> perform tests: only some packages have Makefile (with "check" phase),
> and it would be a really good luck if "make check" as is succeeded for
> them.  Usually such projects use Cask to run tests or even some custom
> scripts.  They may use just "ert" or "ert-running" package (or maybe
> something else).
>
> After all, I think that adding a 'check' phase to emacs-build-system is
> not worth an effort: there would be too much manual interventions in
> package recipes to make tests work for different emacs packages.

You said it all!

Fede

Re: [PATCH 3/5] gnu: Add ghc-data-access-transformers.

[Federico Beffa]

On Fri, Oct 28, 2016 at 3:44 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>> +(synopsis "Use Accessor to access state in transformers State monad")
>
> I can’t parse “transformers State monad”, but maybe it’s just me, or is
> it missing a word, like “transformers of the State monad”, “State monad
> transformers”?

The way I understand it is: "transformers State monad" stands for the
transformer monad called StateT, itself a monad.  But I'll let you or
a native English speaker decide about the grammatical correctness of
the synopsis provided by the author :-)

Thanks,
Fede

Re: Workflow management with GNU Guix

[Ludovic Courtès]

Roel Janssen  skribis:

> Ludovic Courtès writes:

[...]

>> So I guess that’s an argument in favor of the approach you chose.
>
> Can't a derivation write its output to some other place than the store?
> Maybe by running it "by hand"?

Yes, if you run it “by hand”, then you can tweak things as you see fit.

>> Fundamentally, a derivation just describes a command, its arguments, its
>> dependencies, its outputs, and its environment variables.
>>
>> So you’re right: you can very much run a derivation “by hand” instead of
>> letting the daemon do it on your behalf.  The only difference is that
>> you won’t have write access to the store.
>
> And that's fine, because we don't want to write the output to the store :).
>
> So, the workflow language should create a derivation, but then
> guix-daemon should not execute the derivation, but instead, the workflow
> execution engine can do it so it can avoid writing the output to the
> store.. right?

Right.  In addition to the snippet I gave, you’d need to set the
environment variables that are specified in the derivation.

For each output of the derivation, one environment variable is defined
that points to its /gnu/store/… file name.  So for instance, you’d also
need to do:

  (setenv "out" "/home/roel/something")

if you want to “redirect” the “out” output to a place that’s not its
normal place in the store.

With user namespaces, you could simply bind mount /home/roel/something
to /gnu/store/… in the process that runs the derivation builder, instead
using of the ‘setenv’ hack above.

Ludo’.

Re: [PATCH v2 2/3] gnu: Add hidapi.

[Theodoros Foradis]

Ricardo Wurmus writes:

> Theodoros Foradis  writes:
>
>> * gnu/packages/hidapi.scm: New file.
>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
>> ---
>>  gnu/local.mk|  1 +
>>  gnu/packages/hidapi.scm | 63 
>> +
>>  2 files changed, 64 insertions(+)
>>  create mode 100644 gnu/packages/hidapi.scm
>>
>> diff --git a/gnu/local.mk b/gnu/local.mk
>> index ff2d976..9019b98 100644
>> --- a/gnu/local.mk
>> +++ b/gnu/local.mk
>> @@ -178,6 +178,7 @@ GNU_SYSTEM_MODULES = \
>>%D%/packages/gxmessage.scm\
>>%D%/packages/haskell.scm  \
>>%D%/packages/hexedit.scm  \
>> +  %D%/packages/hidapi.scm   \
>>%D%/packages/hugs.scm \
>>%D%/packages/hurd.scm \
>>%D%/packages/ibus.scm \
>> diff --git a/gnu/packages/hidapi.scm b/gnu/packages/hidapi.scm
>> new file mode 100644
>> index 000..88e5eba
>> --- /dev/null
>> +++ b/gnu/packages/hidapi.scm
>> @@ -0,0 +1,63 @@
>> +;;; GNU Guix --- Functional package management for GNU
>> +;;; Copyright © 2016 Theodoros Foradis 
>> +;;;
>> +;;; 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 hidapi)
>> +  #:use-module (guix packages)
>> +  #:use-module (guix download)
>> +  #:use-module ((guix licenses) #:prefix license:)
>> +  #:use-module (guix build-system gnu)
>> +  #:use-module (gnu packages)
>> +  #:use-module (gnu packages autotools)
>> +  #:use-module (gnu packages libusb)
>> +  #:use-module (gnu packages linux)
>> +  #:use-module (gnu packages pkg-config))
>> +
>> +(define-public hidapi
>> +  (package
>> +(name "hidapi")
>> +(version "0.8.0-rc1")
>> +(source (origin
>> +  (method url-fetch)
>> +  (uri (string-append 
>> "https://github.com/signal11/hidapi/archive/hidapi-";
>> +  version ".tar.gz"))
>> +  (sha256
>> +   (base32
>> +"0qdgyj9rgb7n0nk3ghfswrhzzknxqn4ibn3wj8g4r828pw07451w"
>> +(build-system gnu-build-system)
>> +(arguments
>> + '(#:phases
>> +   (modify-phases %standard-phases
>> + (add-before 'configure 'bootstrap
>> +   (lambda _
>> + (zero? (system* "autoreconf" "-vfi")))
>> +(inputs
>> + `(("libusb" ,libusb)
>> +   ("udev" ,eudev)))
>> +(native-inputs
>> + `(("autoconf" ,autoconf)
>> +   ("automake" ,automake)
>> +   ("libtool" ,libtool)
>> +   ("pkg-config" ,pkg-config)))
>> +(home-page "http://www.signal11.us/oss/hidapi/";)
>> +(synopsis "HID API library")
>> +(description
>> + "HIDAPI is a library which allows an application to interface with USB 
>> and Bluetooth
>> +  HID-Class devices.")
>
> There should be no indentation for the continuing line starting with
> “HID-Class”.
>

Ok.

> I wonder, should this rather go to “libusb.scm”?  Having a separate
> module just for this one package seems a little excessive :)
>
I wondered this as well, I can move is to libusb, if it's more
appropriate.

>> +(license (list license:gpl3 ;HIDAPI can be used under one of
>> three licenses.
>
> I’d move the comment above the “license” field because it doesn’t apply
> to the GPL in particular.

Ok.

>
>> +   license:bsd-3
>> +   license:non-copyleft ;LICENSE-orig.txt - permissive 
>> license
>
> “non-copyleft” takes at least one argument.  In this case this would be
>
> (license:non-copyleft "file://LICENCE-orig.txt")
>
> There’s no need to mention that it’s a “permissive” (or “push-over”)
> license, because that’s what non-copyleft already states.
>
> ~~ Ricardo

Thanks, I'll fix that as well.

-- 
Theodoros Foradis

[PATCH] Add libdispatch

[ng0]

libdispatch:
I think that the compiler can only find libblocks-runtime on a bsd system and 
that the port can not run tests.
This is my theory, I must put it to practice, the new nvidia-texture-tools(?) 
required libdispatch which is why I packaged this.
This was before the current version got released, I assume it's still required.

[PATCH 1/4] gnu: Add libkque.
[PATCH 2/4] gnu: Add libpthread_workqueue.
[PATCH 3/4] gnu: Add libblocks-runtime.
[PATCH 4/4] gnu: Add libdispatch.

[PATCH 1/4] gnu: Add libkqueue.

[ng0]

* gnu/local.mk: Include gnu/packages/libdispatch.scm .
* gnu/packages/libdispatch.scm: Add new file.
* gnu/packages/libdispatch.scm (libkqueue): New variable.
---
 gnu/local.mk |  1 +
 gnu/packages/libdispatch.scm | 64 
 2 files changed, 65 insertions(+)
 create mode 100644 gnu/packages/libdispatch.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index f306180..d1bb937 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -206,6 +206,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/libbsd.scm  \
   %D%/packages/libcanberra.scm \
   %D%/packages/libdaemon.scm   \
+  %D%/packages/libdispatch.scm  \
   %D%/packages/libedit.scm \
   %D%/packages/libevent.scm\
   %D%/packages/libffcall.scm   \
diff --git a/gnu/packages/libdispatch.scm b/gnu/packages/libdispatch.scm
new file mode 100644
index 000..77c80c0
--- /dev/null
+++ b/gnu/packages/libdispatch.scm
@@ -0,0 +1,64 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 ng0 
+;;;
+;;; 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 libdispatch)
+  #:use-module (gnu packages)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages perl)
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages ruby))
+
+(define-public libkqueue
+  (package
+(name "libkqueue")
+(version "2.1.0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append 
"https://github.com/mheily/libkqueue/archive/v";
+  version ".tar.gz"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"07xdns9kaw6v5jbz2d7d9zw1lkz1zdj1wmbyxla0wqyhzywizybf"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'autogen
+   (lambda _
+ (zero? (system* "autoreconf" "-fi")))
+(native-inputs
+ `(("pkg-config" ,pkg-config)
+   ("ruby" ,ruby)
+   ("perl" ,perl)
+   ("autoconf" ,(autoconf-wrapper))
+   ("automake" ,automake)
+   ("libtool" ,libtool)))
+(home-page "https://github.com/mheily/libkqueue";)
+(description
+ "Userspace implementation of the kqueue(2) kernel event
+notification mechanism found in FreeBSD.
+libkqueue acts as a translator between the kevent structure and the
+native kernel facilities.")
+(synopsis "kqueue(2) compatibility library")
+;; event.h is bsd-2
+(license (list license:expat license:bsd-2
-- 
2.10.1

[PATCH 4/4] gnu: Add libdispatch.

[ng0]

* gnu/packages/libdispatch.scm (libdispatch): New variable.
---
 gnu/packages/libdispatch.scm | 44 
 1 file changed, 44 insertions(+)

diff --git a/gnu/packages/libdispatch.scm b/gnu/packages/libdispatch.scm
index 3902a82..1e58296 100644
--- a/gnu/packages/libdispatch.scm
+++ b/gnu/packages/libdispatch.scm
@@ -21,11 +21,14 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system cmake)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages llvm)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages python)
   #:use-module (gnu packages ruby))
 
 (define-public libkqueue
@@ -127,3 +130,44 @@ languages developed by Apple to support the Grand Central 
Dispatch
 concurrency engine.")
 (synopsis "Blocks Runtime")
 (license (list license:ncsa license:expat
+
+;; This commit includes a commit which drops click.
+(define-public libdispatch
+  (let ((commit "bd1808980b04830cbbd79c959b8bc554085e38a1")
+(revision "1"))
+(package
+  (name "libdispatch")
+  (version (string-append "0.1.3.1" "-" revision "." (string-take commit 
7)))
+  (source (origin
+(method git-fetch)
+(uri (git-reference
+  (url "https://github.com/nickhutchinson/libdispatch";)
+  (commit commit)))
+(file-name (string-append name "-" version "-checkout"))
+(sha256
+ (base32
+  "00a6xkzrd7svk7pbi59w0rq7wxszp888lg00kzaim2ikagw67ihi"
+  (native-inputs
+   `(("python-2" ,python-2)))
+  (inputs
+   `(("libpthread_workqueue" ,libpthread_workqueue)
+ ("libkqueue" ,libkqueue)
+ ("libblocks-runtime" ,libblocks-runtime)))
+  (build-system cmake-build-system)
+  (arguments
+   ;;`(#:tests? #f))
+   `(#:configure-flags (list "-DDISPATCH_ENABLE_TEST_SUITE=1")))
+ ;; #:phases
+ ;; (modify-phases %standard-phases
+ ;;   (add-after 'unpack 'autogen
+ ;; (lambda _
+  (home-page "http://nickhutchinson.me/libdispatch/";)
+  (synopsis "GNU-linux port of Apple's concurrency library")
+  (description
+   "libdispatch, aka Grand Central Dispatch (GCD) is Apple's
+high-performance event-handling library.  It provides asynchronous
+task queues, monitoring of file descriptor read and write-ability,
+asynchronous I/O (for sockets and regular files), readers-writer locks,
+parallel for-loops, sane signal handling, periodic timers, semaphores
+and more.")
+  (license license:asl2.0
-- 
2.10.1

[PATCH 3/4] gnu: Add libblocks-runtime.

[ng0]

* gnu/packages/libdispatch.scm (libblocks-runtime): New variable.
---
 gnu/packages/libdispatch.scm | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/gnu/packages/libdispatch.scm b/gnu/packages/libdispatch.scm
index 37d9195..3902a82 100644
--- a/gnu/packages/libdispatch.scm
+++ b/gnu/packages/libdispatch.scm
@@ -23,6 +23,7 @@
   #:use-module (guix download)
   #:use-module (guix build-system gnu)
   #:use-module (gnu packages autotools)
+  #:use-module (gnu packages llvm)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages ruby))
@@ -93,3 +94,36 @@ native kernel facilities.")
  "libpthread_workqueue is a POSIX threads workqueue library.")
 (synopsis "Portable implementation of the pthread_workqueue API")
 (license license:bsd-2)))
+
+(define-public libblocks-runtime
+  (package
+(name "libblocks-runtime")
+(version "0.4.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"https://github.com/mheily/blocks-runtime/releases/";
+"download/v" version "/" "libblocksruntime-" version 
".tar.gz"))
+  (sha256
+   (base32
+"1g1a25g1qfy3w21dy0kaxnj6ylbjskmsif68fw7xkavcgn6y21vq"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'autogen
+   (lambda _
+ (zero? (system* "autoreconf" "--install" "--verbose")))
+(native-inputs
+ `(("autoconf" ,(autoconf-wrapper))
+   ("automake" ,automake)
+   ("clang" ,clang)
+   ("libtool" ,libtool)
+   ("pkg-config" ,pkg-config)))
+(home-page "https://github.com/mheily/blocks-runtime/";)
+(description
+ "Blocks are a proposed extension to the C, Objective C, and C++
+languages developed by Apple to support the Grand Central Dispatch
+concurrency engine.")
+(synopsis "Blocks Runtime")
+(license (list license:ncsa license:expat
-- 
2.10.1

[PATCH 2/4] gnu: Add libpthread_workqueue.

[ng0]

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

diff --git a/gnu/packages/libdispatch.scm b/gnu/packages/libdispatch.scm
index 77c80c0..37d9195 100644
--- a/gnu/packages/libdispatch.scm
+++ b/gnu/packages/libdispatch.scm
@@ -62,3 +62,34 @@ native kernel facilities.")
 (synopsis "kqueue(2) compatibility library")
 ;; event.h is bsd-2
 (license (list license:expat license:bsd-2
+
+(define-public libpthread_workqueue
+  (package
+(name "libpthread_workqueue")
+(version "0.9.2")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"https://github.com/mheily/libpwq/archive/v";
+version ".tar.gz"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"0gi8l6jy5d7w3fff684qfjdj16snbc8vkf27y68w91xl5jy16xri"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'autogen
+   (lambda _
+ (zero? (system* "autoreconf" "--install" "--verbose")))
+(native-inputs
+ `(("pkg-config" ,pkg-config)
+   ("autoconf" ,(autoconf-wrapper))
+   ("automake" ,automake)
+   ("libtool" ,libtool)))
+(home-page "https://github.com/mheily/libpwq";)
+(description
+ "libpthread_workqueue is a POSIX threads workqueue library.")
+(synopsis "Portable implementation of the pthread_workqueue API")
+(license license:bsd-2)))
-- 
2.10.1

Re: [PATCH] gnu: Add qtwebkit.

[Roel Janssen]

Thomas Danckaert writes:

> Hi,
>
> this patch adds QtWebKit 5.7 as a separate package (hopefully this will 
> reduce security concerns: only packages which really need QtWebKit will 
> include it).
>
> QtWebKit is not officially supported anymore as of Qt 5.6, so this is a 
> “community release” (not exactly sure what that entails, or if this includes 
> any updates at all since the Qt 5.5 version).  I suppose many projects are 
> switching to Qt WebEngine, and there are some efforts to create an updated 
> version of QtWebKit (https://github.com/annulen/webkit), but in the mean 
> time, this package might help build packages which still rely on the old 
> QtWebKit.
>
> By default, the qmake build system for qtwebkit insists on installing into 
> the same prefix as qtbase, and it seems no command line parameters will 
> change that. The solution I came up with, was to substitute all the necessary 
> paths in the generated Makefiles. This makes the patch a bit lengthy.
>
> I've also attached a minimal example.
>
> Thomas
> QT += widgets
> QT += webkit
> QT += webkitwidgets
> SOURCES = example.cpp
>   
> #include 
> #include 
>
> int main(int argc, char** argv) {
> QApplication app(argc, argv);
> QWebView view;
> view.show();
> view.setUrl(QUrl("https://www.gnu.org/software/guix";));
> return app.exec();
> }

Thanks a lot for this patch.  I can confirm it builds fine, yet I have
to test it on some Qt packages that need QtWebkit (Texmaker).

Kind regards,
Roel Janssen

Re: Workflow management with GNU Guix

[Roel Janssen]

Ludovic Courtès writes:

> Hi!
>
> Roel Janssen  skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> IIUC, (guix workflows) from the tarball you sent executes workflows in
>>> the current environment, as opposed to creating a derivation that would
>>> actually perform the workflow.  What motivated this approach?
>>
>> The short answer:
>> Lack of time to implement it properly ;).
>>
>> The slightly longer answer:
>> I want to avoid storing results in the store, because we could be
>> analyzing files of 100GB or more that we do not want to copy into the
>> store, neither do we want to store the results of the run in the store.
>
> Good point!
>
>> I now realize we could only put the derivation in the store, and not the
>> build output itself..
>
> A derivation has to get its inputs from the store, and to write its
> output to the store.  There’s no other option.
>
> So I guess that’s an argument in favor of the approach you chose.

Can't a derivation write its output to some other place than the store?
Maybe by running it "by hand"?

>>> Workflows could compiled to derivations, which in turn could be “built”,
>>> and their build result would be the workflow’s output file.
>>>
>>> I guess in practice it only works if users of the cluster can build
>>> derivations on the cluster and have them scheduled on compute nodes.
>>>
>>> Thoughts?
>>
>> For building derivations, I think we need super user privileges, right?
>
> Well guix-daemon needs to run as root, unless --disable-chroot is used.

Yeah ok..  But as long as the guix-daemon doesn't build any derivation it
doesn't need super user privileges ;).

>> Why can't the scripts "just" output the environment variables required as
>> @code{guix package --search-paths} provides, and then run the commands
>> with the newly set environment?
>
> Fundamentally, a derivation just describes a command, its arguments, its
> dependencies, its outputs, and its environment variables.
>
> So you’re right: you can very much run a derivation “by hand” instead of
> letting the daemon do it on your behalf.  The only difference is that
> you won’t have write access to the store.

And that's fine, because we don't want to write the output to the store :).

So, the workflow language should create a derivation, but then
guix-daemon should not execute the derivation, but instead, the workflow
execution engine can do it so it can avoid writing the output to the
store.. right?

Kind regards,
Roel Janssen

Re: [PATCH] gnu: Add qwt.

[Marius Bakke]

> * gnu/packages/qt.scm (qwt): New variable.

I pushed this as fc381a3.

`guix lint` reports that qttools "should probably be a native-input",
but it is referenced, so that is wrong.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add radeontop.

[Ludovic Courtès]

Hi!

Tobias Geerinckx-Rice  skribis:

> * gnu/packages/linux.scm (radeontop): New variable.

[...]

> I'm too ignorant of anything beyond x86 to know if supported-systems is
> needed or even makes sense here.

I’m guessing the program is not very useful on non-x86 machines… but it
may build fine anyway.

We can add ‘supported-systems’ later if/when we have evidence that it
doesn’t build on other arches.

> +(define-public radeontop
> +  (package
> +(name "radeontop")
> +(version "0.9")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append 
> "https://github.com/clbr/radeontop/archive/v";

You could move ‘home-page’ above ‘source’ and reference it here.

Otherwise LGTM, thanks!

> +(license license:gpl3)))

It’s indeed v3-only, bah.

Ludo’.

Re: [PATCH 5/5] gnu: Add ghc-gnuplot.

[Ludovic Courtès]

Federico Beffa  skribis:

> From f06b0a9eea5ddf055cfcf7f80fe8ac6eb62972b3 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 24 Oct 2016 17:49:35 +0200
> Subject: [PATCH 5/5] gnu: Add ghc-gnuplot.
>
> * gnu/packages/haskell.scm (ghc-gnuplot): New variable.

[...]

> +(propagated-inputs `(("gnuplot" ,gnuplot)))

Instead of propagating it, could we instead replace “gnuplot” with
“/gnu/store/…/bin/gnuplot” in the relevant source file?

Thanks,
Ludo’.

Re: [PATCH 4/5] gnu: Add ghc-utility-ht.

[Ludovic Courtès]

Federico Beffa  skribis:

> From c18d8ed86ee3793e7591ae7e040351da2ae94bcc Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 24 Oct 2016 17:43:17 +0200
> Subject: [PATCH 4/5] gnu: Add ghc-utility-ht.
>
> * gnu/packages/haskell.scm (ghc-utility-ht): New variable.

LGTM!

Re: [PATCH 3/5] gnu: Add ghc-data-access-transformers.

[Ludovic Courtès]

Federico Beffa  skribis:

> From 675fbdda80b453dc6e1b8aa4635d4adefd7c18df Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 24 Oct 2016 17:35:27 +0200
> Subject: [PATCH 3/5] gnu: Add ghc-data-access-transformers.
>
> * gnu/packages/haskell.scm (ghc-data-access-transformers): New variable.

[...]

> +(synopsis "Use Accessor to access state in transformers State monad")

I can’t parse “transformers State monad”, but maybe it’s just me, or is
it missing a word, like “transformers of the State monad”, “State monad
transformers”?

Otherwise LGTM, thanks!

Ludo’.

Re: Providing an alternative to setuid in GuixSD

[Ludovic Courtès]

Hi!

sba...@catern.com skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>> Well, the kernel Linux will forever support setuid binaries
>
> That can be selectively turned off per-mount, simply specify the nosuid
> option. And so eventually we can get to a point where setuid is a Linux
> build configuration option, which distros can turn off.

Right.

>> and thus, most likely, chroot(2) will forever be restricted to root.
>
> This too can be a configuration option. And it's entirely possible for
> distros to turn it on after setuid is turned off.
>
> These decisions about setuid and chroot are distribution decisions;
> distributions can and should make decisions and innovate independent of
> the Linux kernel's default configuration. (That's part of how the whole
> GNU/Linux ecosystem works)
>
> On another point, even if chroot is forever privileged, new syscalls can
> be developed which duplicate the functionality of chroot with more
> flexibility and less baggage. But they will certainly face the same
> issue as chroot if they wish to be made unprivileged. Mount namespaces,
> for example, (with a bit of tweaking of the API to make it actually
> useful unprivileged) could be made unprivileged without relying on user
> namespaces, but face the same problems as chroot. So by removing setuid
> we are laying the groundwork for innovation not just by allowing
> unprivileged chroot.

Yes, I agree with this.

I think we must just be clear that GuixSD will be the only one to
benefit from a solution along the lines you wrote, at least for the
foreseeable future.

It seems to me that your proposal could be summarized as (1) replacing
sudo with a sudo-that-uses-IPCs (fine), and (2) replacing other setuid
programs by a wrapper that does “sudo program”.

Item #2 is already possible, but it doesn’t look “better” to me that
setuid programs from a security or configuration viewpoint.

Note that GuixSD is different from other distros regarding setuid
binaries: they exist only in /run/setuid-programs, which is recreated at
boot time (unless of course root messes up with the system).

>>> I think also the ability to build a setuid-free system could make GuixSD
>>> a useful platform for innovation in the use of filesystem namespaces. (I
>>> myself certainly have plans in this area.)
>>
>> Our ‘linux-libre’ package has support for user namespaces and other
>> namespaces built in already (this is the default kernel config I think),
>> so one can already play with namespaces on GuixSD and on other distros
>> that enable it.  :-)
>
> I mean new kernel features - I'm skeptical that user namespaces provide
> an intuitive or easy to use API, and I have some ideas on what would be
> better. But the features I want to develop rely on getting rid of
> setuid, so I'm starting there. :)

What features do you have in mind?

Namespaces look like an improvement to me.  If you want something less
hacky, there’s always the Hurd.  ;-)

>>> The largest targets for elimination are sudo and su. Luckily there is
>>> already a ready alternative for those commands: ssh. We can augment lsh
>>
>> SSH is a complex protocol and its implementations are complex too.  I
>> would find it unreasonable to replace ‘su’ and ‘sudo’ with something
>> this complex, that goes through the TCP/IP stack, etc.
>
> Yes, that is true. The sole virtue of ssh here is that it already exists
> and is used for this purpose.
>
> What if we adapted s6-sudod, or wrote something from scratch? Or perhaps
> patched sudo to work in some way over IPC? I think a generic solution is
> useful. Maybe something should be written specifically for GuixSD,
> configured with Guile? Or maybe something which makes use of the putative
> standard, PolicyKit, which is configured with Javascript?

Polkit has its own sudo-like program, ‘pkexec’, that works by talking to
the polkit daemon over D-Bus.

Ludo’.

Re: [PATCH 2/5] gnu: Add ghc-data-accessor.

[Ludovic Courtès]

Federico Beffa  skribis:

> From 6885ee012c18ae14c31e23ab07b0f5421b630c4a Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 24 Oct 2016 17:30:50 +0200
> Subject: [PATCH 2/5] gnu: Add ghc-data-accessor.
>
> * gnu/packages/haskell.scm (ghc-data-accessor): New variable.

LGTM!

> +   (uri (string-append
> + 
> "https://hackage.haskell.org/package/data-accessor/data-accessor-";

Maybe we should consider adding a mirror://hackage in (guix download).

Ludo’.

Re: [PATCH 1/5] gnu: geiser-next: Re-introduce it.

[Ludovic Courtès]

Federico Beffa  skribis:

> Unfortunately it was forgot to include support files for Chibi and
> Chez in the 0.9 Geiser release tar archive.  For this reason I'm
> proposing to reintroduce 'chez-next'.
>
> Regards,
> Fede
>
> From 4cb3a1774754ffec91e00b681ffb4acff3e77b4e Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 24 Oct 2016 09:56:35 +0200
> Subject: [PATCH 1/5] gnu: geiser-next: Re-introduce it.
>
> * gnu/packages/emacs.scm (geiser-next): Re-introduce it.

OK!

Ludo’.

Re: [PATCH] gnu: Add libjxr.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sat, Oct 22, 2016 at 04:33:18AM -0400, Kei Kebreau wrote:

[...]

>> >> diff --git a/gnu/packages/patches/libjxr-use-cmake.patch
>> >> b/gnu/packages/patches/libjxr-use-cmake.patch
>> >> new file mode 100644
>> >> index 000..cb5919e
>> >> --- /dev/null
>> >> +++ b/gnu/packages/patches/libjxr-use-cmake.patch
>> >> @@ -0,0 +1,143 @@
>> >> +Description: Prefer a cmake based build system
>> >> +Author: Mathieu Malaterre 
>> >> +Forwarded: https://jxrlib.codeplex.com/discussions/440294
>> >
>> > Why doesn't upstream's build system work?
>> 
>> Upstream's build system simply doesn't have configuration or
>> installation targets in the provided Makefile. Using the cmake patch
>> makes the definition cleaner at the cost of relying on outside work
>> [1]. If this is not acceptable, I can see about writing manual
>> replacement phases to the best of my ability.
>> 
>> [1]: https://jxrlib.codeplex.com/discussions/440294
>
> Hm, not an ideal situation.
>
> If Debian is using this patch, we should link to it's source on Debian's
> site instead of this message board. I don't know enough about CMake to
> judge the patch but I'd be more comfortable if Debian was using it.
>
> What do others think?

Regarding the choice between writing our own installation phase in
Scheme and using this CMake thing instead, I think we should choose the
most concise approach (in terms of lines of code).

If the winner here is the CMake patch, then indeed, we should take the
patch from Debian rather than from a message board (and include
provenance information in the patch, as you wrote.)

That said, I suspect an ‘install’ phase in Scheme would be more concise
than this new CMakeLists.txt (134 lines).

Kei: WDYT?

Thanks!

Ludo’.

Re: Workflow management with GNU Guix

[Ludovic Courtès]

Hi!

Roel Janssen  skribis:

> Ludovic Courtès writes:

[...]

>> IIUC, (guix workflows) from the tarball you sent executes workflows in
>> the current environment, as opposed to creating a derivation that would
>> actually perform the workflow.  What motivated this approach?
>
> The short answer:
> Lack of time to implement it properly ;).
>
> The slightly longer answer:
> I want to avoid storing results in the store, because we could be
> analyzing files of 100GB or more that we do not want to copy into the
> store, neither do we want to store the results of the run in the store.

Good point!

> I now realize we could only put the derivation in the store, and not the
> build output itself..

A derivation has to get its inputs from the store, and to write its
output to the store.  There’s no other option.

So I guess that’s an argument in favor of the approach you chose.

>> Workflows could compiled to derivations, which in turn could be “built”,
>> and their build result would be the workflow’s output file.
>>
>> I guess in practice it only works if users of the cluster can build
>> derivations on the cluster and have them scheduled on compute nodes.
>>
>> Thoughts?
>
> For building derivations, I think we need super user privileges, right?

Well guix-daemon needs to run as root, unless --disable-chroot is used.

> Why can't the scripts "just" output the environment variables required as
> @code{guix package --search-paths} provides, and then run the commands
> with the newly set environment?

Fundamentally, a derivation just describes a command, its arguments, its
dependencies, its outputs, and its environment variables.

So you’re right: you can very much run a derivation “by hand” instead of
letting the daemon do it on your behalf.  The only difference is that
you won’t have write access to the store.

Here’s an example:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,use(gnu packages base)
scheme@(guile-user)> (define s (open-connection))
scheme@(guile-user)> (package-derivation s coreutils)
$4 = # 
/gnu/store/81pkzgzjwbnxfd5izgmgam8hfmjn20v8-coreutils-8.25-debug 
/gnu/store/apx87qb8g3f6x0gbx555qpnfm1wkdv4v-coreutils-8.25 5baea00>
scheme@(guile-user)> (derivation-builder $4)
$5 = "/gnu/store/ik15p8lrbk6jfa3fs3x34m78lj2c0ix1-guile-2.0.11/bin/guile"
scheme@(guile-user)> (derivation-builder-arguments $4)
$6 = ("--no-auto-compile" "-L" 
"/gnu/store/mn706n39l8z37w8wdqcm9v8pg6zcn33v-module-import" 
"/gnu/store/1a559p1yki9x1g676r8z0p3cf1f3pq7l-coreutils-8.25-guile-builder")
scheme@(guile-user)> (apply system* $5 $6)
[ Well, chdir to /tmp or something before trying it at home… ]
--8<---cut here---end--->8---

Ludo’.

Re: [PATCH] refresh: Suggest changes to inputs when updating.

[Ludovic Courtès]

Hello!

Thanks for tackling this, it’s more and more needed!

Ricardo Wurmus  skribis:

> * guix/scripts/refresh.scm (updater->importer-info): New procedure.
> (mock): New syntax rule.
> (update-package): Run matching importer to suggest changes to inputs.

Tests and a bit of documentation would be welcome for the final
revision.

> +(define (updater->importer-info updater-name)
> +  "Return a list containing an update procedure, a package name converter,
> +and, optionally, an archive symbol for the given UPDATER-NAME.  Return #F for
> +an unknown updater."
> +  (case updater-name
> +((gnu)
> + (list gnu->guix-package
> +   package-name))
> +((elpa)
> + (list elpa->guix-package
> +   package-name))
> +((cran)
> + (list cran->guix-package
> +   (@@ (guix import cran) package->upstream-name)))
> +((bioconductor)
> + (list cran->guix-package
> +   (@@ (guix import cran) package->upstream-name)
> +   'bioconductor))
> +((hackage)
> + (list hackage->guix-package
> +   (@@ (guix import gem) guix-package->hackage-name)))
> +((pypi)
> + (list pypi->guix-package
> +   guix-package->pypi-name))
> +((gem)
> + (list gem->guix-package
> +   (@@ (guix import gem) guix-package->gem-name)))
> +(else #f)))

This is not OK because it breaks the  abstraction.

> +;; FIXME: copied from (guix tests)
> +(define-syntax-rule (mock (module proc replacement) body ...)
> +  "Within BODY, replace the definition of PROC from MODULE with the 
> definition
> +given by REPLACEMENT."
> +  (let* ((m (resolve-module 'module))
> + (original (module-ref m 'proc)))
> +(dynamic-wind
> +  (lambda () (module-set! m 'proc replacement))
> +  (lambda () body ...)
> +  (lambda () (module-set! m 'proc original)

This is OK for tests but not for Real Code.  :-)

>  (define* (update-package store package updaters
>   #:key (key-download 'interactive))
>"Update the source file that defines PACKAGE with the new version.
> @@ -246,7 +287,62 @@ values: 'interactive' (default), 'always', and 'never'."
>  (package-version package) version)
>  (let ((hash (call-with-input-file tarball
>port-sha256)))
> -  (update-package-source package version hash)))
> +  (update-package-source package version hash))
> +
> +;; Run importer to compare inputs and suggest changes.
> +(let* ((updater (find (lambda (updater)
> +((upstream-updater-predicate updater) 
> package))
> +  updaters))
> +   (updater-name (upstream-updater-name updater)))
> +  (match (updater->importer-info updater-name)
> +(#f #t) ; do nothing if there's no matching importer
> +((importer convert-name . archive)
> + ;; Replace "download-to-store" to avoid downloading the
> + ;; tarball again.
> + (match (mock ((guix download) download-to-store
> +   (lambda _ tarball))
> + (apply importer (convert-name package) archive))
> +   ((and expr ('package fields ...))
> +;; FIXME: Is there a nicer way to match names in the
> +;; package expression?  Could we compare actual packages
> +;; instead of only their labels?
> +(let* ((imported-inputs
> +(append
> + (match expr
> +   ((path *** ('inputs
> +   ('quasiquote ((label ('unquote 
> sym)) ... label)
> +   (_ '()))

What if we first changed importers to return a  instead of an
sexp?

That way we could (1) factorize the ‘package->sexp’ machinery in (guix
upstream), and (2) simplify this specific use case.

A downside is that syntactic sugar, like when the importer returns an
sexp representing a call to ‘pypi-uri’, would be lost.  Hmm.

Anyway, I think the functionality (determining the set of inputs that
needs to be changed) should go to (guix upstream).  The user messages
(“consider removing these inputs”, etc.) should go to (guix refresh).

Concretely, ‘package-update-path’ could be changed to return not just an
 but also dependency information.  That could be
achieved by adding native/propagated/regular inputs to
, or maybe preferably by creating a new
 record to carry that information.

WDYT?

That said, I can imagine that this patch has already been extremely
helpful for mass updates…

Thank you!

Ludo’.

Re: [PATCH 2/2] gnu: Add emacs-org-trello.

[Roel Janssen]

Alex Kost writes:

> Ricardo Wurmus (2016-10-27 20:48 +0200) wrote:
>
>> Alex Kost  writes:
>>
 @Alex: could you please confirm this?  Should these inputs be mentioned
 at all?  If so, is it sufficient to add them to native-inputs?
>>>
>>> As for me, I don't see a reason to add these additional inputs,
>>> emacs-build-system will not run tests anyway.
>>
>> Thank you for clarifying.
>>
>> Is there a reason why we don’t run the tests?  We do this by default for
>> all other packages.
>
> How can it be done?  There is no common way for emacs packages to
> perform tests: only some packages have Makefile (with "check" phase),
> and it would be a really good luck if "make check" as is succeeded for
> them.  Usually such projects use Cask to run tests or even some custom
> scripts.  They may use just "ert" or "ert-running" package (or maybe
> something else).
>
> After all, I think that adding a 'check' phase to emacs-build-system is
> not worth an effort: there would be too much manual interventions in
> package recipes to make tests work for different emacs packages.
>
> But I better let Federico speak about «why we don’t run the tests» as he
> wrote emacs-build-system :-)

So, the only proper way to do it, is to manually add a test phase in
each package definition.  But then we still have to add a lot of
dependencies that are only needed to run the tests, and even then the
tests don't say much..  In the case of this package, the test functions
can't run because they use functions that aren't loaded yet, which
results in failures of the tests (while the package works just fine).

Could I therefore, please, go ahead and push the patch without the
additional inputs for running tests?

Kind regards,
Roel Janssen

Re: [PATCH 2/3] gnu: pam_unix.so Add use_first_pass option.

[Ludovic Courtès]

John Darrington  skribis:

> On Thu, Oct 27, 2016 at 02:51:02PM +0200, Ludovic Court??s wrote:
>  >
>  > On its own it does nothing.  It makes more sense in context with the 
> other patch I sent.
>  > With this option in place, one can extend the unix-pam-service with 
> another pam service
>  > (such as krb5-pam), and if the krb5 authentication fails (for example 
> because I am not
>  > at work) then the password I gave will be presented to the regular 
> pam_unix login. 
>  > I won't be prompted for it again.
>  
>  In that case, instead of hardcoding ???use_first_pass??? here, would it 
> be
>  possible for the pam-krb5 service to extend ???pam-root-service-type??? 
> with
>  a procedure that automatically adds ???use_first_pass??? where needed?
>  
>
> I will look into it.  But almost any other pam module will want to do
> the same

Yes, and what I suggest will allow you to do that.

> - at least
> any other which uses passphrase based authentication.  So I thought why put 
> the onus on 
> every other module to do this?

It’s not entirely clear that ‘use_first_pass’ is generally desirable,
Kerberos aside.  So I think it makes more sense to add it as part of the
Kerberos service, with an explanation of why it’s important in this
context.

Ludo’.

Re: [PATCH 1/1] gnu: Add ccid.

[Ludovic Courtès]

Marius Bakke  skribis:

> * gnu/packages/security-token.scm (ccid): New variable.

LGTM; the driver issue that Mike and you are discussing doesn’t seem to
be a blocker.

Ludo’.

[PATCH 4/4] gnu: r-nmf: Use bigmemory.

[Roel Janssen]

* gnu/packages/statistics.scm (r-nmf): Use bigmemory.
---
 gnu/packages/statistics.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 478e1a5..35f65e5 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -2868,6 +2868,8 @@ memory-mapped files.")
 (build-system r-build-system)
 (propagated-inputs
  `(("r-cluster" ,r-cluster)
+   ("r-bigmemory" ,r-bigmemory)
+   ("r-synchronicity" ,r-synchronicity)
("r-colorspace" ,r-colorspace)
("r-digest" ,r-digest)
("r-doparallel" ,r-doparallel)
-- 
2.10.1

[PATCH 3/4] gnu: Add r-bigmemory.

[Roel Janssen]

* gnu/packages/statistics.scm (r-bigmemory): New variable.
---
 gnu/packages/statistics.scm | 24 
 1 file changed, 24 insertions(+)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index a50e792..478e1a5 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -2829,6 +2829,30 @@ message passing.")
 bigmemory and synchronicity packages.")
 (license (list license:lgpl3 license:asl2.0
 
+(define-public r-bigmemory
+  (package
+(name "r-bigmemory")
+(version "4.5.19")
+(source
+ (origin
+   (method url-fetch)
+   (uri (cran-uri "bigmemory" version))
+   (sha256
+(base32
+ "191gbzca557kpk7mdsg716vfyqpr7j5din6qb8hin4g1nkzzwmg6"
+(build-system r-build-system)
+(propagated-inputs
+ `(("r-bh" ,r-bh)
+   ("r-rcpp" ,r-rcpp)
+   ("r-bigmemory-sri" ,r-bigmemory-sri)
+   ("r-r-utils" ,r-r-utils)))
+(home-page "http://www.bigmemory.org";)
+(synopsis "Manage large matrices with shared memory or memory-mapped 
files")
+(description "This package provides methods to Create, store, access, and
+manipulate large matrices.  Matrices are allocated to shared memory and may use
+memory-mapped files.")
+(license (list license:lgpl3 license:asl2.0
+
 (define-public r-nmf
   (package
 (name "r-nmf")
-- 
2.10.1

[PATCH 2/4] gnu: Add r-bigmemory-sri.

[Roel Janssen]

* gnu/packages/statistics.scm (r-bigmemory-sri): New variable.
---
 gnu/packages/statistics.scm | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 9e2d4a9..a50e792 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -2810,6 +2810,25 @@ via mutexes and may eventually support interprocess 
communication and
 message passing.")
 (license (list license:lgpl2.1 license:asl2.0
 
+(define-public r-bigmemory-sri
+  (package
+(name "r-bigmemory-sri")
+(version "0.1.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (cran-uri "bigmemory.sri" version))
+   (sha256
+(base32
+ "0mg14ilwdkd64q2ri9jdwnk7mp55dqim7xfifrs65sdsv1934h2m"
+(build-system r-build-system)
+(home-page
+ "http://cran.r-project.org/web/packages/bigmemory.sri";)
+(synopsis "A shared resource interface for the bigmemory package")
+(description "This package provides a shared resource interface for the
+bigmemory and synchronicity packages.")
+(license (list license:lgpl3 license:asl2.0
+
 (define-public r-nmf
   (package
 (name "r-nmf")
-- 
2.10.1

[PATCH 0/4] Let r-nmf use bigmemory for large files.

[Roel Janssen]

Dear Guix,

When the NMF R package finds another package upon installation (called
bigmemory), it can use memory maps for reading large files.  This patch
series adds the necessary packages to add bigmemory, and let r-nmf use
it.

Kind regards,
Roel Janssen

[PATCH 1/4] gnu: Add r-synchronicity.

[Roel Janssen]

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

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index b15f9cf..9e2d4a9 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -2787,6 +2787,29 @@ Fourier transform, fuzzy clustering, support vector 
machines, shortest path
 computation, bagged clustering, naive Bayes classifier, and more.")
 (license license:gpl2+)))
 
+(define-public r-synchronicity
+  (package
+(name "r-synchronicity")
+(version "1.1.9.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (cran-uri "synchronicity" version))
+   (sha256
+(base32
+ "0d9skpwmsnkn4xb3f2kgyyv8bhdi0r9p1kj3cvi0s92fjjnpi00c"
+(build-system r-build-system)
+(propagated-inputs
+ `(("r-bh" ,r-bh)
+   ("r-bigmemory-sri" ,r-bigmemory-sri)
+   ("r-rcpp" ,r-rcpp)))
+(home-page "http://www.bigmemory.org";)
+(synopsis "Boost mutex functionality in R")
+(description "This package provides support for synchronization
+via mutexes and may eventually support interprocess communication and
+message passing.")
+(license (list license:lgpl2.1 license:asl2.0
+
 (define-public r-nmf
   (package
 (name "r-nmf")
-- 
2.10.1

Re: Web site news to move to Haunt

[Andy Wingo]

On Fri 28 Oct 2016 01:33, l...@gnu.org (Ludovic Courtès) writes:

>> The goal is to manage news using Haunt, and to have a page to display
>> them on the web site, something nicer and more flexible than this:
>>
>>   https://savannah.gnu.org/news/?group=guix
>>
>> And I already enjoy Haunt!  :-)
>
> I’m done!

Nice!

> I think we should do the same for Guile real soon.

Yeah!  First thing would be to get Assaf to export the news items I
guess.

Super stuff!

A

Re: 01/01: gnu: python-urllib3: Update to 1.18.1.

[Marius Bakke]

Leo Famulari  writes:

> On Thu, Oct 27, 2016 at 01:05:19PM +, Marius Bakke wrote:
>> mbakke pushed a commit to branch master
>> in repository guix.
>> 
>> commit 6178274d19ed3e637b5365b64a28f298574df81f
>> Author: Marius Bakke 
>> Date:   Thu Oct 27 14:03:07 2016 +0100
>> 
>> gnu: python-urllib3: Update to 1.18.1.
>> 
>> * gnu/packages/python.scm (python-urllib3): Update to 1.18.1.
>> [home-page]: Use https URL.
>
> Thanks for this!

NP! I saw it on the oss-security tracker. Our version was too old to be
affected by the CVE, but decided to update it anyway.


signature.asc
Description: PGP signature

Re: [PATCH 1/1] gnu: Add ccid.

[Marius Bakke]

Mike Gerwitz  writes:

> On Thu, Oct 27, 2016 at 10:46:11 +0100, Marius Bakke wrote:
>> + `(#:configure-flags (list (string-append "--enable-usbdropdir=" %output
>> +  "/pcsc/drivers"))
>
> When I run pcscd under Guix, I get:
>
>    hotplug_libudev.c:122:HPReadBundleValues()
>   Cannot open PC/SC drivers directory: /var/lib/pcsc/drivers
>   0041 hotplug_libudev.c:123:HPReadBundleValues()
>   Disabling USB support for pcscd.
>
> I believe that is what `--enable-usbdropdir' is referencing in
> ccid.  pcsc-lite has the same configuration option, but it's currently
> hardcoded to /var/lib/pcsc/drivers; could you update it to match ccid's
> and see if that works?

Packages are not allowed to write to /var, so to run pcscd on Guix you
will have to symlink ~/.guix-profile/pcsc/drivers to
/var/lib/pcsc/drivers manually, until we have a system service for
pcscd. Can you try that?

> Debian has the dependencies structured such that pcscd has ccid as an
> input.

This would work, but ccid is one of potentially many drivers for pcscd,
so I'm reluctant to "hard code" it. It would not be possible to use
other drivers if usbdropdir is set to the ccid output.

Thanks for checking!


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add libdispatch.

[ng0]

Leo Famulari  writes:

> On Fri, Sep 16, 2016 at 10:50:09AM +, ng0 wrote:
>> Subject: [PATCH 1/4] gnu: Add libkqueue.
>> 
>> * gnu/local.mk: Include gnu/packages/libdispatch.scm .
>> * gnu/packages/libdispatch.scm: Add new file.
>> * gnu/packages/libdispatch.scm (libkqueue): New variable.
>
> LGTM
>
>> Subject: [PATCH 2/4] gnu: Add libpthread_workqueue.
>> 
>> * gnu/packages/libdispatch.scm (libpthread_workqueue): New variable.
>
>> +(version "0.9.1")
>
> 0.9.2 is available upstream:
> https://github.com/mheily/libpwq/releases
>
> Can you try using that?

Ok

>> Subject: [PATCH 3/4] gnu: Add libblocks-runtime.
>> 
>> * gnu/packages/libdispatch.scm (libblocks-runtime): New variable.
>
>> + (add-after 'unpack 'autogen
>> +   (lambda _
>> + (zero? (system* "autoreconf" "--install" "--symlink" 
>> "--verbose")))
>
> Why use --symlink?

I have no idea why I did this. I'll remove it in the new version
of the patches.

>> Subject: [PATCH 4/4] gnu: Add libdispatch.
>> 
>> * gnu/packages/libdispatch.scm (libdispatch): New variable.
>
>> +(arguments
>> + `(#:tests? #f))
>
> The tests can be run with `ctest` [0].
>
> The test suite can be built by setting "-DDISPATCH_ENABLE_TEST_SUITE=1"
> in #:configure-flags. However, when I tried that, the build log included
> "No compiler support for Blocks; test suite will not be built.", and the
> tests were indeed not built.
>
> Does that mean that libblocks-runtime is not working?

An ebuild for this package contains this:

src_install() {
 multilib_foreach_abi ustr_install install-multilib-linux
 #TODO this is redundant and stupid, why does libdispatch need this file
 cp "${S}/BlocksRuntime/Block_private.h" "${ED}/usr/include" || die
#dodoc ChangeLog README README-DEVELOPERS AUTHORS NEWS TODO
}

( source: 
https://data.gpo.zugaina.org/netcrave/dev-libs/libblocksruntime/libblocksruntime-.ebuild
 )

Maybe Blocks_private.h is expected in that location but not
copied by upstream. I will take a look once the test suite runs.
This is libblocksruntime, not libdispatch but I think I packaged
that as dependency for libdispatch.

> Also, the libdispatch tarball bundles Click [0] at 'thirdparty/click'. We
> should remove that and use our Click package.

Ok

> [0]
> https://github.com/nickhutchinson/libdispatch#testing-with-ctest
>
> [1]
> http://click.pocoo.org/5/
>

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: [PATCH v2 1/1] gnu: Add plantuml.

[Theodoros Foradis]

Hello Ricardo,

> Hi Theodoros,
>
> thanks for the patch!
>
>> +(define-public plantuml
>> +  (package
>> +(name "plantuml")
>> +(version "8048")
>> +(source (origin
>> +  (method url-fetch)
>> +  (uri (string-append
>> +"mirror://sourceforge/plantuml/plantuml-"
>> +version ".tar.gz"))
>> +  (sha256
>> +   (base32
>> +"1vipxd6p7isb1k1qqh4hrpfcj27hx1nll2yp0rfwpvps1w2d936i"
>> +(build-system ant-build-system)
>> +(arguments
>> + `(#:tests? #f ; no tests
>> +   #:build-target "dist"
>> +   #:phases
>> +   (modify-phases %standard-phases
>> + (add-before 'build 'delete-extra-from-cp
>> + (lambda _
>> +   (substitute* "build.xml"
>> + (("1.6") "1.7")
>> + (("> + (("j2v8_macosx_x86_64-3.1.7.jar\" />") "-->"))
>> +   #t))
>> + (add-before 'install 'gen-install
>> +  (lambda* (#:key outputs #:allow-other-keys)
>> +(mkdir-p "build/jar")
>> +(system* "mv" "plantuml.jar" "build/jar")
>> +((@@ (guix build ant-build-system) default-build.xml)
>> + "plantuml.jar"
>> + (string-append (assoc-ref outputs "out")
>> +"/share/java"
>
> I don’t understand this.  Do you only use “default-build.xml” to add an
> install target?  In the previous phase you use the included “build.xml”.
> I find this a little odd and think it would be clearer to just install
> the files manually instead of using “default-build.xml” here.

The build.xml that our ant-build-system generates, does not generate a
correct manifest attribute with the Main-Class, so the produced jar file
cannot be run. Instead of generating the required text manually, I use
the default build.xml for the build phase.

The default build.xml does not include an install phase, so I generate
it after compilation, with our ant-build-system.

Feedback is welcome, if there is a better way to do this, before I
reformat the patch.

>
>> + (add-after 'install 'make-wrapper
>> +(lambda* (#:key inputs outputs #:allow-other-keys)
>
> Please check the indentation for all phases.  That’s too far to the
> right.
>

I will fix that. This is the default indentation emacs does with this,
so I forgot to fix it manually.

>> +  (let* ((out (assoc-ref outputs "out"))
>> + (wrapper (string-append out "/bin/plantuml")))
>> +(mkdir-p (string-append out "/bin"))
>> +(with-output-to-file wrapper
>> +  (lambda _
>> +(display
>> + (string-append
>> +  "#!" (assoc-ref inputs "bash")
>> "/bin/sh\n\n"
>

Works for me, so I'll change it.

> You might not need bash here.  Would just “#!/bin/sh” work?
>
>> +  (assoc-ref inputs "jre") "/bin/java -jar "
>> +  out "/share/java/plantuml.jar \"$@\"\n"
>> +(chmod wrapper #o555)))
>
> Please note that all phases should end with #t or #f. 
>

Will fix.

>> +(inputs
>> + `(("graphviz" ,graphviz)
>> +   ("bash" ,bash)
>> +   ("jre" ,icedtea "out")))
>
> “out” is the default so you can just leave it off.
>
>> +(home-page "http://plantuml.com/";)
>> +(synopsis "Draw UML diagrams from simple textual description")
>> +(description
>> + "Plantuml is a tool to generate sequence, usecase, class,
>> activity,
>
> Is “usecase” a word or should it be “use case”?
>
>> +component, state, deployment and object UML diagrams, using a simple and
>> +human readable text description.  Contains salt, a tool that can
>> design simple
>
> Please use “@code{salt}”.
>

Ok.

>> +graphical interfaces.")
>> +(license license:gpl3+)))
>
> Could you please send an updated patch?
>
> ~~ Ricardo

Sure, I will send an updated patch later.

Regards,
-- 
Theodoros Foradis

Re: guix emacs mode

[ng0]

Alex Kost  writes:

> ng0 (2016-10-28 08:30 +) wrote:
>
>> ng0  writes:
>>
>>> Efraim Flashner  writes:
>>>
 [ Unknown signature status ]
 On Sat, Oct 22, 2016 at 09:31:33PM +, ng0 wrote:
> Occasionally I use vim on systems to work on guix and other projects. As
> far as I see it, there is nothing similar to .dir-locals.el (the per
> directory local variables in emacs) for vim.
> 
> We should include modelines for every file to reflect what .dir-locals.el
> does when you use emacs. It's probably an unpopular opinion, but I think
> we should do this to be more open to people who do not use emacs.
> Support for vim and emacs covers most editors which are there to
> support.
> 

 IMO there's too many files to go adding to the bottom of all the files.
 Something I've been thinking about is learning enough vimscript to write
 a guix.vim file that'll take care of formatting.
>>>
>>> I agree, this could be more useful. The best approach would be to move
>>> this to a separate project, so that other systems can create packages
>>> for this to install it.
>>
>> Different issue, but somehow related: Could we move the emacs
>> specific settings into an emacs mode if emacs modes can detect
>> some common structure or however we specify that the current file
>> which is edited is guix and not guile/scm alone?
>
> Sorry, I don't understand the question.  What does «move the emacs
> specific settings into an emacs mode» mean?

I don't understand much, well to be honest: nothing, on how modes
in emacs work. I meant that we maybe could move whatever the
.dir-locals.el sets into some external modules/files/set if
possible at all. It probably works for gentoo .ebuild because
they have a different file extension than bash, but at their core
it is bash (if I don't mix it up right now). The sentence below
looks like this will not work at all for guix.

> Also there is no difference between some guix ".scm" file and a usual
> guile ".scm" file.

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

[PATCH 07/10] Factor out procedure: install-grub-config

[cmmarusich]

From: Chris Marusich 

* gnu/build/install (install-grub, install-grub-config): Extract code from
  'install-grub' into a new procedure 'install-grub-config'.  Also, define
  'install-grub' using define, not define*, since it makes no use of the extra
  features that define* provides.
---
 gnu/build/install.scm | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/gnu/build/install.scm b/gnu/build/install.scm
index 7431a09..3d1594e 100644
--- a/gnu/build/install.scm
+++ b/gnu/build/install.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016 Ludovic Courtès 
+;;; Copyright © 2016 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -22,6 +23,7 @@
   #:use-module (srfi srfi-26)
   #:use-module (ice-9 match)
   #:export (install-grub
+install-grub-config
 populate-root-file-system
 reset-timestamps
 register-closure
@@ -36,13 +38,24 @@
 ;;;
 ;;; Code:
 
-(define* (install-grub grub.cfg device mount-point)
+(define (install-grub grub.cfg device mount-point)
   "Install GRUB with GRUB.CFG on DEVICE, which is assumed to be mounted on
 MOUNT-POINT.
 
 Note that the caller must make sure that GRUB.CFG is registered as a GC root
 so that the fonts, background images, etc. referred to by GRUB.CFG are not
 GC'd."
+  (install-grub-config grub.cfg mount-point)
+  (unless (zero? (system* "grub-install" "--no-floppy"
+  "--boot-directory"
+  (string-append mount-point "/boot")
+  device))
+(error "failed to install GRUB")))
+
+(define (install-grub-config grub.cfg mount-point)
+  "Atomically copy GRUB.CFG into boot/grub/grub.cfg on the MOUNT-POINT.  Note
+that the caller must make sure that GRUB.CFG is registered as a GC root so
+that the fonts, background images, etc. referred to by GRUB.CFG are not GC'd."
   (let* ((target (string-append mount-point "/boot/grub/grub.cfg"))
  (pivot  (string-append target ".new")))
 (mkdir-p (dirname target))
@@ -50,13 +63,7 @@ GC'd."
 ;; Copy GRUB.CFG instead of just symlinking it, because symlinks won't
 ;; work when /boot is on a separate partition.  Do that atomically.
 (copy-file grub.cfg pivot)
-(rename-file pivot target)
-
-(unless (zero? (system* "grub-install" "--no-floppy"
-"--boot-directory"
-(string-append mount-point "/boot")
-device))
-  (error "failed to install GRUB"
+(rename-file pivot target)))
 
 (define (evaluate-populate-directive directive target)
   "Evaluate DIRECTIVE, an sexp describing a file or directory to create under
-- 
2.9.2

[PATCH 03/10] Refactor grub.cfg generation logic

[cmmarusich]

From: Chris Marusich 

This enables the implementation of 'guix system switch-generation' and 'guix
system roll-back'.  Those new commands will only be able to determine the
store device and mount point for a given system generation by reading them
from that generation's boot parameters file, which does not contain a
 object.  This change makes it possible for those commands
regenerate grub.cfg using that information.

* gnu/system.scm (operating-system-grub.cfg): Instead of passing store-fs
  directly as a parameter to grub-configuration-file, pass in its mount point
  and (basically) its device.

* gnu/system/grub.scm (strip-mount-point, eye-candy, grub-root-search,
  grub-configuration-file, previous-grub-entries): Refactor these procedures
  to take a mount point and/or (basically) a device as parameters instead of a
  full-fledged  object.
---
 gnu/system.scm  | 10 -
 gnu/system/grub.scm | 98 ++---
 guix/scripts/system.scm |  3 +-
 3 files changed, 63 insertions(+), 48 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index f9f63a0..0d8c25a 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -728,6 +728,10 @@ listed in OS.  The C library expects to find it under
   ((system  (operating-system-derivation os))
(root-fs ->  (operating-system-root-file-system os))
(store-fs -> (operating-system-store-file-system os))
+   (grub-root-search-device -> (case (file-system-title store-fs)
+ ((uuid) (file-system-device store-fs))
+ ((label) (file-system-device 
store-fs))
+ (else #f)))
(label ->(kernel->grub-label (operating-system-kernel os)))
(kernel ->   (operating-system-kernel-file os))
(initrd  (operating-system-initrd-file os))
@@ -736,7 +740,7 @@ listed in OS.  The C library expects to find it under
(file-system-device root-fs)))
(entries ->  (list (menu-entry
(label label)
-   (device #f) ;; stub value, not used yet
+   (device grub-root-search-device)
(linux kernel)
(linux-arguments
 (cons* (string-append "--root=" root-device)
@@ -746,7 +750,9 @@ listed in OS.  The C library expects to find it under
(operating-system-kernel-arguments os)))
(initrd initrd)
 (grub-configuration-file (operating-system-bootloader os)
- store-fs entries
+ (file-system-mount-point store-fs)
+ grub-root-search-device
+ entries
  #:old-entries old-entries)))
 
 (define (operating-system-parameters-file os)
diff --git a/gnu/system/grub.scm b/gnu/system/grub.scm
index 859f33a..d45fdca 100644
--- a/gnu/system/grub.scm
+++ b/gnu/system/grub.scm
@@ -62,16 +62,15 @@
 ;;;
 ;;; Code:
 
-(define (strip-mount-point fs file)
-  "Strip the mount point of FS from FILE, which is a gexp or other lowerable
+(define (strip-mount-point mount-point file)
+  "Strip MOUNT-POINT from FILE, which is a gexp or other lowerable
 object denoting a file name."
-  (let ((mount-point (file-system-mount-point fs)))
-(if (string=? mount-point "/")
-   file
-   #~(let ((file #$file))
-(if (string-prefix? #$mount-point file)
-(substring #$file #$(string-length mount-point))
-file)
+  (if (string=? mount-point "/")
+  file
+  #~(let ((file #$file))
+  (if (string-prefix? #$mount-point file)
+  (substring #$file #$(string-length mount-point))
+  file
 
 (define-record-type* 
   grub-image make-grub-image
@@ -164,12 +163,15 @@ WIDTH/HEIGHT, or #f if none was found."
 (with-monad %store-monad
   (return #f)
 
-(define (eye-candy config root-fs system port)
-  "Return in %STORE-MONAD a gexp that writes to PORT (a port-valued gexp) the
-'grub.cfg' part concerned with graphics mode, background images, colors, and
-all that.  ROOT-FS is a file-system object denoting the root file system where
-the store is.  SYSTEM must be the target system string---e.g.,
-\"x86_64-linux\"."
+(define (eye-candy config store-fs-mount-point store-device system port)
+  "Return a gexp that writes to PORT (a port-valued gexp) the 'grub.cfg' part
+concerned with graphics mode, background images, colors, and all that.
+STORE-FS-MOUNT-POINT is the mount point of the file system containing the
+store.  STORE-DEVICE is a file system UUID, a file system label, or #f.  The
+value of STORE-DEVICE determines the GRUB search command that will be used to
+find and set the GRUB root; for details, please refer to the
+'grub-root-searc

[PATCH 02/10] Add 'device' field to

[cmmarusich]

From: Chris Marusich 

* gnu/system/grub.scm (): add field 'device'.

* gnu/system.scm (grub-configuration-file): use a dummy value for 'device'.

* guix/scripts/system.scm (previous-grub-entries): use a dummy value for
  'device'.

In a future commit, we will restructure the grub.cfg generation logic to use
this information, to enable the implementation of 'guix system
switch-generation' and 'guix system roll-back'.
---
 gnu/system.scm  | 1 +
 gnu/system/grub.scm | 4 +++-
 guix/scripts/system.scm | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index ff84b63..f9f63a0 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -736,6 +736,7 @@ listed in OS.  The C library expects to find it under
(file-system-device root-fs)))
(entries ->  (list (menu-entry
(label label)
+   (device #f) ;; stub value, not used yet
(linux kernel)
(linux-arguments
 (cons* (string-append "--root=" root-device)
diff --git a/gnu/system/grub.scm b/gnu/system/grub.scm
index 249b415..859f33a 100644
--- a/gnu/system/grub.scm
+++ b/gnu/system/grub.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016 Ludovic Courtès 
+;;; Copyright © 2016 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -121,6 +122,7 @@ object denoting a file name."
   menu-entry make-menu-entry
   menu-entry?
   (label   menu-entry-label)
+  (device  menu-entry-device)  ; file system uuid, label, or #f
   (linux   menu-entry-linux)
   (linux-arguments menu-entry-linux-arguments
(default '()))  ; list of string-valued gexps
@@ -262,7 +264,7 @@ corresponding to old generations of the system."
 
   (define entry->gexp
 (match-lambda
- (($  label linux arguments initrd)
+ (($  label device linux arguments initrd)
   ;; Use the right file names for LINUX and STORE-FS in case STORE-FS is
   ;; not the "/" file system.
   (let ((linux  (strip-mount-point store-fs linux))
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 0519ab8..8f0b8cd 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015, 2016 Ludovic Courtès 
 ;;; Copyright © 2016 Alex Kost 
+;;; Copyright © 2016 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -384,6 +385,7 @@ it atomically, and then run OS's activation script."
 (label (string-append label " (#"
   (number->string number) ", "
   (seconds->string time) ")"))
+(device #f) ; stub value, not used yet
 (linux kernel)
 (linux-arguments
  (cons* (string-append "--root=" root-device)
-- 
2.9.2

[PATCH 06/10] grub-entries: take a list of numbers on input

[cmmarusich]

From: Chris Marusich 

* guix/scripts/system.scm (grub-entries): Add an optional parameter which
  allows the caller to limit the grub entries that get returned.
---
 guix/scripts/system.scm | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index a4f5c7b..2c80c2e 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -366,8 +366,10 @@ it atomically, and then run OS's activation script."
 (date->string (time-utc->date time)
   "~Y-~m-~d ~H:~M")))
 
-(define* (grub-entries #:optional (profile %system-profile))
-  "Return a list of 'menu-entry' for the generations of PROFILE."
+(define* (grub-entries #:optional (profile %system-profile)
+  (numbers (generation-numbers profile)))
+  "Return a list of 'menu-entry' for the generations of PROFILE specified by
+NUMBERS, which is a list of generation numbers."
   (define (system->grub-entry system number time)
 (unless-file-not-found
  (let* ((file (string-append system "/parameters"))
@@ -395,8 +397,7 @@ it atomically, and then run OS's activation script."
 kernel-arguments))
 (initrd initrd)
 
-  (let* ((numbers (generation-numbers profile))
- (systems (map (cut generation-file-name profile <>)
+  (let* ((systems (map (cut generation-file-name profile <>)
numbers))
  (times   (map (lambda (system)
  (unless-file-not-found
-- 
2.9.2

[PATCH 09/10] Rename grub-entries to profile-grub-entries

[cmmarusich]

From: Chris Marusich 

* guix/scripts/system.scm (grub-entries): Rename this procedure to
  'profile-grub-entries'.  Update all callers.
---
 guix/scripts/system.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 086b431..2ee145a 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -366,7 +366,7 @@ it atomically, and then run OS's activation script."
 (date->string (time-utc->date time)
   "~Y-~m-~d ~H:~M")))
 
-(define* (grub-entries #:optional (profile %system-profile)
+(define* (profile-grub-entries #:optional (profile %system-profile)
   (numbers (generation-numbers profile)))
   "Return a list of 'menu-entry' for the generations of PROFILE specified by
 NUMBERS, which is a list of generation numbers."
@@ -441,9 +441,9 @@ generation as its default entry."
  ;; from the actual past values for this generation's entry.
  (grub-config (grub-configuration (device root-device)))
  ;; Make the specified system generation the default entry.
- (entries (grub-entries %system-profile (list number)))
+ (entries (profile-grub-entries %system-profile (list number)))
  (old-generations (delv number (generation-numbers %system-profile)))
- (old-entries (grub-entries %system-profile old-generations))
+ (old-entries (profile-grub-entries %system-profile old-generations))
  (grub.cfg (run-with-store store
  (grub-configuration-file grub-config
   store-mount-point
@@ -625,7 +625,7 @@ building anything."
   (operating-system-grub.cfg os
  (if (eq? 'init action)
  '()
- (grub-entries)
+ (profile-grub-entries)
 
;; For 'init' and 'reconfigure', always build GRUB.CFG, even if
;; --no-grub is passed, because GRUB.CFG because we then use it as a GC
-- 
2.9.2

[PATCH 01/10] * gnu/system.scm (): Add 'store-device' and 'store-fs-mount-point'.

[cmmarusich]

From: Chris Marusich 

In a future commit, we will restructure the grub.cfg generation logic to use
this information, to enable the implementation of 'guix system
switch-generation' and 'guix system roll-back'.
---
 gnu/system.scm | 58 +-
 1 file changed, 49 insertions(+), 9 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 38ae8f1..ff84b63 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2013, 2014, 2015, 2016 Ludovic Courtès 
 ;;; Copyright © 2015 Mark H Weaver 
 ;;; Copyright © 2015, 2016 Alex Kost 
+;;; Copyright © 2016 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -99,6 +100,8 @@
 boot-parameters?
 boot-parameters-label
 boot-parameters-root-device
+boot-parameters-store-device
+boot-parameters-store-fs-mount-point
 boot-parameters-kernel
 boot-parameters-kernel-arguments
 boot-parameters-initrd
@@ -750,17 +753,25 @@ listed in OS.  The C library expects to find it under
 this file is the reconstruction of GRUB menu entries for old configurations."
   (mlet %store-monad ((initrd   (operating-system-initrd-file os))
   (root ->  (operating-system-root-file-system os))
+  (store -> (operating-system-store-file-system os))
   (label -> (kernel->grub-label
  (operating-system-kernel os
-(gexp->file "parameters"
-#~(boot-parameters (version 0)
-   (label #$label)
-   (root-device #$(file-system-device root))
-   (kernel #$(operating-system-kernel-file os))
-   (kernel-arguments
-#$(operating-system-kernel-arguments os))
-   (initrd #$initrd))
-#:set-load-path? #f)))
+(gexp->file
+ "parameters"
+ #~(boot-parameters (version 1)
+(label #$label)
+(root-device #$(file-system-device root))
+(store-device
+ #$(case (file-system-title store)
+ ((uuid) (file-system-device store))
+ ((label) (file-system-device store))
+ (else #f)))
+(store-fs-mount-point #$(file-system-mount-point 
store))
+(kernel #$(operating-system-kernel-file os))
+(kernel-arguments
+ #$(operating-system-kernel-arguments os))
+(initrd #$initrd))
+ #:set-load-path? #f)))
 
 
 ;;;
@@ -770,7 +781,16 @@ this file is the reconstruction of GRUB menu entries for 
old configurations."
 (define-record-type* 
   boot-parameters make-boot-parameters boot-parameters?
   (labelboot-parameters-label)
+  ;; Because we will use the 'store-device' to create the GRUB search command,
+  ;; the 'store-device' has slightly different semantics than 'root-device'.
+  ;; The 'store-device' can be a file system uuid, a file system label, or #f,
+  ;; but it cannot be a device path such as "/dev/sda3", since GRUB would not
+  ;; understand that.  The 'root-device', on the other hand, corresponds
+  ;; exactly to the device field of the  object representing the
+  ;; OS's root file system, so it might be a device path like "/dev/sda3".
   (root-device  boot-parameters-root-device)
+  (store-device boot-parameters-store-device)
+  (store-fs-mount-point boot-parameters-store-fs-mount-point)
   (kernel   boot-parameters-kernel)
   (kernel-arguments boot-parameters-kernel-arguments)
   (initrd   boot-parameters-initrd))
@@ -786,6 +806,10 @@ this file is the reconstruction of GRUB menu entries for 
old configurations."
  (boot-parameters
   (label label)
   (root-device root)
+  ;; For backwards compatibility, we assume the store device and the
+  ;; root device are the same.
+  (store-device root)
+  (store-fs-mount-point "/")
 
   ;; In the past, we would store the directory name of the kernel instead
   ;; of the absolute file name of its image.  Detect that and correct it.
@@ -805,6 +829,22 @@ this file is the reconstruction of GRUB menu entries for 
old configurations."
   (string-append directory file))
  (('initrd (? string? file))
   file)
+(('boot-parameters ('version 1)
+   ('label label)
+   ('root-device root)
+   ('store-device store)
+   ('store-fs-mount-point store-fs-mount-point)
+   ('kernel linux)
+   ('kernel-arguments arguments)
+   ('initrd initrd))
+ (boot-paramet

[PATCH 08/10] Implement switch-generation and roll-back

[cmmarusich]

From: Chris Marusich 

* guix/scripts/system.scm (roll-back-system, switch-to-system-generation,
  reinstall-grub): New procedures.

* guix/scripts/system.scm (show-help, process-command, guix-system): Add
  references to the new actions.
---
 guix/scripts/system.scm | 97 ++---
 1 file changed, 91 insertions(+), 6 deletions(-)

diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 2c80c2e..086b431 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -407,6 +407,67 @@ NUMBERS, which is a list of generation numbers."
 
 
 ;;;
+;;; Roll-back.
+;;;
+(define (roll-back-system store)
+  "Roll back the system profile to its previous generation."
+  (switch-to-system-generation store "-1"))
+
+;;;
+;;; Switch generations.
+;;;
+(define (switch-to-system-generation store spec)
+  "Switch the system profile to the generation specified by SPEC, and
+re-install grub with a grub configuration file that uses the specified system
+generation as its default entry."
+  (let ((number (relative-generation-spec->number %system-profile spec)))
+(if number
+(begin
+  (reinstall-grub store number)
+  (switch-to-generation* %system-profile number))
+(leave (_ "cannot switch to system generation '~a'~%") spec
+
+(define (reinstall-grub store number)
+  "Re-install grub for existing system profile generation NUMBER."
+  (let* ((generation (generation-file-name %system-profile number))
+ (file (string-append generation "/parameters"))
+ (params (unless-file-not-found
+  (call-with-input-file file read-boot-parameters)))
+ (root-device (boot-parameters-root-device params))
+ (store-mount-point (boot-parameters-store-fs-mount-point params))
+ (grub-root-search-device (boot-parameters-store-device params))
+ ;; We don't currently keep track of past menu entries' details.  The
+ ;; default values will allow the system to boot, even if they differ
+ ;; from the actual past values for this generation's entry.
+ (grub-config (grub-configuration (device root-device)))
+ ;; Make the specified system generation the default entry.
+ (entries (grub-entries %system-profile (list number)))
+ (old-generations (delv number (generation-numbers %system-profile)))
+ (old-entries (grub-entries %system-profile old-generations))
+ (grub.cfg (run-with-store store
+ (grub-configuration-file grub-config
+  store-mount-point
+  grub-root-search-device
+  entries
+  #:old-entries old-entries
+(show-what-to-build store (list grub.cfg))
+(build-derivations store (list grub.cfg))
+;; This is basically the same as install-grub*, but for now we avoid
+;; re-installing the GRUB boot loader itself onto a device, mainly because
+;; we don't in general have access to the same version of the GRUB package
+;; which was used when installing this other system generation.
+(let* ((grub.cfg-path (derivation->output-path grub.cfg))
+   (gc-root (string-append %gc-roots-directory "/grub.cfg"))
+   (temp-gc-root (string-append gc-root ".new")))
+  (switch-symlinks temp-gc-root grub.cfg-path)
+  (unless (false-if-exception (install-grub-config grub.cfg-path "/"))
+(delete-file temp-gc-root)
+(leave (_ "failed to re-install GRUB configuration file: '~a'~%")
+   grub.cfg-path))
+  (rename-file temp-gc-root gc-root
+
+
+;;;
 ;;; Graphs.
 ;;;
 
@@ -641,14 +702,19 @@ building anything."
 ;;;
 
 (define (show-help)
-  (display (_ "Usage: guix system [OPTION] ACTION [FILE]
-Build the operating system declared in FILE according to ACTION.\n"))
+  (display (_ "Usage: guix system [OPTION ...] ACTION [ARG ...] [FILE]
+Build the operating system declared in FILE according to ACTION.
+Some ACTIONS support additional ARGS.\n"))
   (newline)
   (display (_ "The valid values for ACTION are:\n"))
   (newline)
   (display (_ "\
reconfigure  switch to a new operating system configuration\n"))
   (display (_ "\
+   roll-backswitch to the previous operating system configuration\n"))
+  (display (_ "\
+   switch-generation switch to an existing operating system configuration\n"))
+  (display (_ "\
list-generations list the system generations\n"))
   (display (_ "\
buildbuild the operating system without installing anything\n"))
@@ -809,15 +875,33 @@ resulting from command-line parsing."
   "Process COMMAND, one of the 'guix system' sub-commands.  ARGS is its
 argument list and OPTS is the option alist."
   (case command
+;; The following commands do not need to use the store, and they do not 
need
+;; an operating system configurat

[PATCH 04/10] Extract procedure: relative-generation-spec->number

[cmmarusich]

From: Chris Marusich 

* guix/scripts/package.scm (switch-generation-action): Extract code from
  here...

* guix/profiles.scm (relative-generation-spec->number): into this new
  procedure here.
---
 guix/profiles.scm| 17 +
 guix/scripts/package.scm |  8 ++--
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index e7319a8..6d707b1 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2015 Mark H Weaver 
 ;;; Copyright © 2015 Sou Bunnbu 
 ;;; Copyright © 2016 Ricardo Wurmus 
+;;; Copyright © 2016 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -97,6 +98,7 @@
 generation-number
 generation-numbers
 profile-generations
+relative-generation-spec->number
 relative-generation
 previous-generation-number
 generation-time
@@ -1039,6 +1041,21 @@ former profiles were found."
 '()
 generations)))
 
+(define (relative-generation-spec->number profile spec)
+  "Return PROFILE's generation specified by SPEC, which is a string.  The SPEC
+may be a N, -N, or +N, where N is a number.  If the spec is N, then the number
+returned is N.  If it is -N, then the number returned is the profile's current
+generation number minus N.  If it is +N, then the number returned is the
+profile's current generation number plus N.  Return #f if there is no such
+generation."
+  (let ((number (string->number spec)))
+(and number
+ (case (string-ref spec 0)
+   ((#\+ #\-)
+(relative-generation profile number))
+   (else number)
+
+
 (define* (relative-generation profile shift #:optional
   (current (generation-number profile)))
   "Return PROFILE's generation shifted from the CURRENT generation by SHIFT.
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 70ed0a7..96a22f6 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2014, 2016 Alex Kost 
 ;;; Copyright © 2016 Roel Janssen 
 ;;; Copyright © 2016 Benz Schenk 
+;;; Copyright © 2016 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -782,12 +783,7 @@ processed, #f otherwise."
#:key dry-run?)
   "Switch PROFILE to the generation specified by SPEC."
   (unless dry-run?
-(let* ((number (string->number spec))
-   (number (and number
-(case (string-ref spec 0)
-  ((#\+ #\-)
-   (relative-generation profile number))
-  (else number)
+(let ((number (relative-generation-spec->number profile spec)))
   (if number
   (switch-to-generation* profile number)
   (leave (_ "cannot switch to generation '~a'~%") spec)
-- 
2.9.2

[PATCH 10/10] Mention new 'guix system' features in the manual

[cmmarusich]

From: Chris Marusich 

* doc/guix.texi (GRUB Configuration, Invoking guix system): Mention the new
   field 'device', update the custom  example, and
  mention the new actions 'guix system roll-back' and 'guix system
  switch-generation' in the manual.

* gnu/system/grub.scm (strip-mount-point): Add a TODO comment.

* guix/scripts/system.scm (show-help): Point users to the manual for details.
---
 doc/guix.texi   | 90 +++--
 gnu/system/grub.scm |  4 +++
 guix/scripts/system.scm |  2 +-
 3 files changed, 85 insertions(+), 11 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1293b8b..26fb930 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -11064,35 +11064,66 @@ along these lines:
 @example
 (menu-entry
   (label "The Other Distro")
-  (linux "/boot/old/vmlinux-2.6.32")
+  (device #f)
+  (linux "(hd0,msdos2)/boot/old/vmlinux-2.6.32")
   (linux-arguments '("root=/dev/sda2"))
-  (initrd "/boot/old/initrd"))
+  (initrd "(hd0,msdos2)/boot/old/initrd"))
 @end example
 
 Details below.
 
 @deftp {Data Type} menu-entry
-The type of an entry in the GRUB boot menu.
+The type of an entry in the GRUB boot menu.  Below, the phrase
+``string-valued G-Expression'' means a string or any object which can be
+inserted (via @code{ungexp}) as a string in a G-Expression
+(@pxref{G-Expressions}).
 
 @table @asis
 
 @item @code{label}
-The label to show in the menu---e.g., @code{"GNU"}.
+The label to show in the menu---e.g., @code{"GNU"}.  This is a string-valued 
G-Expression.
 
 @item @code{linux}
-The Linux kernel image to boot, for example:
+The Linux kernel image to boot.  This is a string-valued G-Expression.
+For example:
 
 @example
 (file-append linux-libre "/bzImage")
 @end example
 
+It is also possible to specify a device explicitly in the file path
+using GRUB's device naming convention (@pxref{Naming convention,,, grub,
+GNU GRUB manual}), for example:
+
+@example
+"(hd0,msdos1)/bzImage"
+@end example
+
+If the device is specified explicitly as above, then the @code{device}
+field is ignored entirely.
+
+@item @code{device}
+The device to use as GRUB's root for this menu entry (@pxref{root,,,
+grub, GNU GRUB manual}).  This may be a file system label (a string), a
+file system UUID (@pxref{File Systems}), or @code{#f}, in which case
+GRUB will automatically find the device containing the file specified by
+the @code{linux} field via a file-based search (@pxref{search,,, grub,
+GNU GRUB manual}).
+
+@c For details, see (guix gnu system).
+Currently, the @code{device} field is not suitable for use in custom
+menu entries.  Therefore, if you need to specify a custom menu entry,
+for now it is best to just pass a dummy value to it (such as @code{#f})
+and specify the device explicitly using GRUB's device naming convention,
+as in the example above.
+
 @item @code{linux-arguments} (default: @code{()})
 The list of extra Linux kernel command-line arguments---e.g.,
-@code{("console=ttyS0")}.
+@code{("console=ttyS0")}.  This is a list of string-valued
+G-Expressions.
 
 @item @code{initrd}
-A G-Expression or string denoting the file name of the initial RAM disk
-to use (@pxref{G-Expressions}).
+The initial RAM disk file to use.  This is a string-valued G-Expression.
 
 @end table
 @end deftp
@@ -11126,8 +11157,9 @@ supported:
 @table @code
 @item reconfigure
 Build the operating system described in @var{file}, activate it, and
-switch to it@footnote{This action is usable only on systems already
-running GuixSD.}.
+switch to it@footnote{This action and the related actions
+@code{switch-generation} and @code{roll-back}) are usable only on
+systems already running GuixSD.}.
 
 This effects all the configuration specified in @var{file}: user
 accounts, system services, global package list, setuid programs, etc.
@@ -11149,6 +11181,44 @@ guix pull}).  Failing to do that you would see an 
older version of Guix
 once @command{reconfigure} has completed.
 @end quotation
 
+@item switch-generation
+Switch to an existing system generation.  This action rearranges the
+existing GRUB menu entries.  It makes the menu entry for the target
+system generation the default, and it moves the entries for the other
+system generations to a submenu.  The next time the system boots, it
+will use the specified system generation.
+
+The target generation can be specified explicitly by its generation
+number.  For example, the following invocation would switch to system
+generation 7:
+
+@example
+guix system switch-generation 7
+@end example
+
+The target generation can also be specified relative to the current
+generation with the form @code{+N} or @code{-N}, where @code{+3} means
+``3 generations ahead of the current generation,'' and @code{-1} means
+``1 generation prior to the current generation.''
+
+Currently, the effect of invoking this action is only to rearrange the
+GRUB menu entries.  Therefore, to actually start using the target system
+generation, you must reboot afte

[PATCH 05/10] Rename previous-grub-entries to grub-entries

[cmmarusich]

From: Chris Marusich 

* guix/scripts/system.scm (previous-grub-entries): rename this procedure to
  grub-entries.  Update all callers.

This procedure actually returns an entry for every generation of the profile,
so its name is confusing if it suggests that it only returns "previous"
entries.
---
 guix/scripts/system.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 4edaa0f..a4f5c7b 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -366,7 +366,7 @@ it atomically, and then run OS's activation script."
 (date->string (time-utc->date time)
   "~Y-~m-~d ~H:~M")))
 
-(define* (previous-grub-entries #:optional (profile %system-profile))
+(define* (grub-entries #:optional (profile %system-profile))
   "Return a list of 'menu-entry' for the generations of PROFILE."
   (define (system->grub-entry system number time)
 (unless-file-not-found
@@ -563,7 +563,7 @@ building anything."
   (operating-system-grub.cfg os
  (if (eq? 'init action)
  '()
- 
(previous-grub-entries)
+ (grub-entries)
 
;; For 'init' and 'reconfigure', always build GRUB.CFG, even if
;; --no-grub is passed, because GRUB.CFG because we then use it as a GC
-- 
2.9.2

Add system roll-back and switch-generation commands

[cmmarusich]

Hi,

This patch series adds 'guix system roll-back' and 'guix system
switch-generation' commands.  It should apply cleanly to the current master
branch.

I've tested the patches manually on a VM with a single disk, and a VM with
multiple disks (with the store on a separate disk).  Two of the "check-system"
tests fail (nss-mdns and encrypted-root-os), but those are failing on the
current master branch for me anyway, and I can't recall ever seeing them pass,
so I have no reason to suspect that my changes are causing the failures.

I look forward to your feedback.

Thank you,
Chris

Re: [PATCH 4/4] gnu: Add psyced.

[ng0]

Efraim Flashner  writes:

> On Tue, Oct 04, 2016 at 08:34:29AM +, ng0 wrote:
>> * gnu/packages/psyc.scm (psyced): New variable.
>> ---
>>  gnu/packages/psyc.scm | 103 
>> ++
>>  1 file changed, 103 insertions(+)
>> 
>> diff --git a/gnu/packages/psyc.scm b/gnu/packages/psyc.scm
>> index 2a2ddc1..e929866 100644
>> --- a/gnu/packages/psyc.scm
>> +++ b/gnu/packages/psyc.scm
>> @@ -223,3 +223,106 @@ multi user virtual environments on the internet.  This 
>> technology is used for
>>  MUDs and also the psyced implementation of the Protocol for SYnchronous 
>> Conferencing (PSYC).  psycLPC is a fork of LDMud with some new features and
>>  many bug fixes.")
>>  (license license:gpl2
>> +
>> +;; XXX: We need a service for this which makes it functional, including
>> +;; copying initial data around.
>> +(define-public psyced
>> +  (let* ((commit "18e72b74ccc4edef58751475d15138fb1300a3b1")
>> + (revision "1"))
>> +(package
>> +  (name "psyced")
>> +  (version (string-append "20160830-" revision "." (string-take commit 
>> 7)))
>> +  (source (origin
>> +(method git-fetch)
>> +(uri (git-reference
>> +  (url "git://git.psyced.org/psyced")
>> +  (commit commit)))
>> +(file-name (string-append name "-" version "-checkout"))
>> +(sha256
>> + (base32
>> +  "1h2cbb14lvnxyqf9g35h78d796hyhafg3h73jv69z6j2cvhka9r2"
>> +  (build-system gnu-build-system)
>> +  (inputs
>> +   `(("perl" ,perl)))
>> +  ;; psyced needs psyclpc at runtime, specifically you will also not
>> +  ;; be able to use psyced witout psyclpc.
>> +  (native-inputs
>> +   `(("pkg-config" ,pkg-config)))
>> +  (propagated-inputs
>> +   `(("psyclpc" ,psyclpc)))
>> +  (arguments
>> +   `(#:tests? #f ; No tests
>> + #:phases
>> + (modify-phases %standard-phases
>> +   (delete 'configure) ; No configure
>> +   (delete 'build) ; no make build needed
>> +   ;; Much of what install.sh used to do is now handled by psyconf. 
>> Upstream
>> +   ;; reference is the Gentoo ebuild in the 
>> youbroketheinternet-overlay
>> +   ;; (https://gnunet.org/git/) where equal ways of installing 
>> psyced are applied
>> +   (replace 'install
>> + (lambda* (#:key outputs #:allow-other-keys)
>> +   (let* ((out (assoc-ref outputs "out"))
>> +  (bin (string-append out "/bin")) ;symlink it?
>> +  (doc (string-append out "/share/doc"))
>> +  ;; sandbox in /opt/psyced/world:
>> +  (opt (string-append out "/opt/psyced"))
>> +  (var (string-append out "/var/psyced"))
>> +  (vard (string-append var "/data"))
>> +  (vardpe (string-append vard "/person"))
>> +  (vardpl (string-append vard "/place"))
>> +  (varcon (string-append var "/config"))
>> +  (etcpsy (string-append out "/etc/psyc")) ;symlink to /
>> +  (varlp (string-append out "/var/log/psyced")) 
>> ;symlink to /
>> +  (varlpp (string-append varlp "/place"))) ;symlink to /
>> + (mkdir-p bin)
>> + (mkdir-p doc)
>> + (mkdir-p opt)
>> + (mkdir-p var)
>> + (mkdir-p vard)
>> + (mkdir-p vardpe)
>> + (mkdir-p vardpl)
>> + (mkdir-p varcon)
>> + (mkdir-p etcpsy)
>> + (mkdir-p varlp)
>> + (mkdir-p varlpp)
>> +
>
> I don't see any files being installed into %out/var/*, is psyced
> supposed to be able to write to these directories at runtime?

My idea was to create a directory structure as a first try to get
psyced to work. It requires some symlinks at runtime. I have some
notes, but those are mostly copy and paste from chatlogs between
lynX and myself. No files are installed into var but later
folders are symlinked into it. Because it must be /var and not
%out/var I will populate this at first-use of service.
This is, like I mentioned before, not a finished package.

>> + (copy-recursively "bin" bin)
>> +
>> + (install-file "config/psyced.ini" etcpsy)
>> +
>> + (install-file "AGENDA.txt" doc)
>> + (install-file "CHANGESTODO" doc)
>> + (install-file "COPYLEFT.txt" doc)
>> + (install-file "LICENSE.txt" doc)
>> +
>> + (copy-recursively "pike" opt)
>> + (copy-recursively "place" opt)
>> + (copy-recursively "run" opt)
>> + (copy-recursively "tor" opt)
>> + (copy-recursively "config" opt)
>> + (copy-recursively "

Re: guix emacs mode

[Alex Kost]

ng0 (2016-10-28 08:30 +) wrote:

> ng0  writes:
>
>> Efraim Flashner  writes:
>>
>>> [ Unknown signature status ]
>>> On Sat, Oct 22, 2016 at 09:31:33PM +, ng0 wrote:
 Occasionally I use vim on systems to work on guix and other projects. As
 far as I see it, there is nothing similar to .dir-locals.el (the per
 directory local variables in emacs) for vim.
 
 We should include modelines for every file to reflect what .dir-locals.el
 does when you use emacs. It's probably an unpopular opinion, but I think
 we should do this to be more open to people who do not use emacs.
 Support for vim and emacs covers most editors which are there to
 support.
 
>>>
>>> IMO there's too many files to go adding to the bottom of all the files.
>>> Something I've been thinking about is learning enough vimscript to write
>>> a guix.vim file that'll take care of formatting.
>>
>> I agree, this could be more useful. The best approach would be to move
>> this to a separate project, so that other systems can create packages
>> for this to install it.
>
> Different issue, but somehow related: Could we move the emacs
> specific settings into an emacs mode if emacs modes can detect
> some common structure or however we specify that the current file
> which is edited is guix and not guile/scm alone?

Sorry, I don't understand the question.  What does «move the emacs
specific settings into an emacs mode» mean?

Also there is no difference between some guix ".scm" file and a usual
guile ".scm" file.

-- 
Alex

Re: [PATCH 2/2] gnu: Add emacs-org-trello.

[Alex Kost]

Ricardo Wurmus (2016-10-27 20:48 +0200) wrote:

> Alex Kost  writes:
>
>>> @Alex: could you please confirm this?  Should these inputs be mentioned
>>> at all?  If so, is it sufficient to add them to native-inputs?
>>
>> As for me, I don't see a reason to add these additional inputs,
>> emacs-build-system will not run tests anyway.
>
> Thank you for clarifying.
>
> Is there a reason why we don’t run the tests?  We do this by default for
> all other packages.

How can it be done?  There is no common way for emacs packages to
perform tests: only some packages have Makefile (with "check" phase),
and it would be a really good luck if "make check" as is succeeded for
them.  Usually such projects use Cask to run tests or even some custom
scripts.  They may use just "ert" or "ert-running" package (or maybe
something else).

After all, I think that adding a 'check' phase to emacs-build-system is
not worth an effort: there would be too much manual interventions in
package recipes to make tests work for different emacs packages.

But I better let Federico speak about «why we don’t run the tests» as he
wrote emacs-build-system :-)

-- 
Alex

[PATCH] gnu: Add qtwebkit.

[Thomas Danckaert]

Hi,

this patch adds QtWebKit 5.7 as a separate package (hopefully this will reduce 
security concerns: only packages which really need QtWebKit will include it).

QtWebKit is not officially supported anymore as of Qt 5.6, so this is a 
“community release” (not exactly sure what that entails, or if this includes 
any updates at all since the Qt 5.5 version).  I suppose many projects are 
switching to Qt WebEngine, and there are some efforts to create an updated 
version of QtWebKit (https://github.com/annulen/webkit), but in the mean time, 
this package might help build packages which still rely on the old QtWebKit.

By default, the qmake build system for qtwebkit insists on installing into the 
same prefix as qtbase, and it seems no command line parameters will change 
that. The solution I came up with, was to substitute all the necessary paths in 
the generated Makefiles. This makes the patch a bit lengthy.

I've also attached a minimal example.

Thomas
From ef2830cfc9342a88ce473f6a9bc55fee68991b74 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert 
Date: Wed, 26 Oct 2016 11:11:01 +0200
Subject: [PATCH] gnu: Add qtwebkit.

* gnu/packages/qt.scm (qtwebkit): New variable.
---
 gnu/packages/qt.scm | 113 
 1 file changed, 113 insertions(+)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index a1e5fde..8e710ab 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2015 Ludovic Courtès 
 ;;; Copyright © 2015, 2016 Efraim Flashner 
 ;;; Copyright © 2016 ng0 
+;;; Copyright © 2016 Thomas Danckaert 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1112,3 +1113,115 @@ contain over 620 classes.")
   "QtKeychain is a Qt library to store passwords and other secret data
 securely.  It will not store any data unencrypted unless explicitly requested.")
 (license license:bsd-3)))
+
+(define-public qtwebkit
+  (package
+(name "qtwebkit")
+(version "5.7.0")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append "http://download.qt.io/community_releases/";
+(version-major+minor version)
+"/" version "/qtwebkit-opensource-src-" version
+".tar.xz"))
+(sha256
+ (base32
+  "1prlpl3zslzpr1iv7m3irvxjxn3v8nlxh21v9k2kaq4fpwy2b8y7"
+(build-system gnu-build-system)
+(native-inputs
+ `(("perl" ,perl)
+   ("python" ,python-2.7)
+   ("ruby" ,ruby)
+   ("bison" ,bison)
+   ("flex" ,flex)
+   ("gperf" ,gperf)
+   ("pkg-config" ,pkg-config)))
+(inputs
+ `(("icu" ,icu4c)
+   ("libjpeg" ,libjpeg)
+   ("libpng" ,libpng)
+   ("libwebp" ,libwebp)
+   ("sqlite" ,sqlite)
+   ("fontconfig" ,fontconfig)
+   ("libxrender", libxrender)
+   ("qtbase" ,qtbase)
+   ("qtdeclarative" ,qtdeclarative)
+   ("qtmultimedia" ,qtmultimedia)
+   ("libxml2" ,libxml2)
+   ("libxslt" ,libxslt)
+   ("libx11" ,libx11)
+   ("libxcomposite" ,libxcomposite)))
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (replace 'configure
+  (lambda* (#:key outputs #:allow-other-keys)
+(let ((out (assoc-ref outputs "out")))
+  (setenv "QMAKEPATH"
+  (string-append (getcwd) "/Tools/qmake:"
+ (getenv "QMAKEPATH")))
+  (system* "qmake"
+ ;; prevent webkit from trying to install into the qtbase store directory,
+ ;; and replace references to the build directory in linker options:
+ (add-before 'build 'patch-installpaths
+ (lambda* (#:key outputs inputs #:allow-other-keys)
+   (let* ((out (assoc-ref outputs "out"))
+  (qtbase (assoc-ref inputs "qtbase"))
+  (builddir (getcwd))
+  (linkbuild (string-append "-L" builddir))
+  (linkout (string-append "-L" out))
+  (makefiles
+   (map-in-order
+(lambda (i)
+  (let* ((in (car i))
+ (mf (string-append (dirname in) "/"
+(cdr i
+;; by default, these Makefiles are
+;; generated during install, but we need
+;; to generate them now
+(system* "qmake" in "-o" mf)
+mf))
+'(("Source/api.pri" . "Makefile.api")
+  ("Source/widgetsapi.pri"
+   . "Makefile.widgetsapi"

Re: Guix gathering in Berlin, Dec. 12th?

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> @Ludo: at what time would you like this to start and for how long do we
> want the room?

I haven’t booked my plane tickets yet, so I don’t know exactly, and it
also depends on what everyone else wants.  :-)  I think we’d have no
shortage of things to talk about, though.

Would it be possible to tentatively book the room for the whole day,
like 9AM to 6PM, and adjust later as we see fit?

Thanks,
Ludo’.

guix emacs mode (was: Re: vim modelines for guix repository)

[ng0]

ng0  writes:

> Efraim Flashner  writes:
>
>> [ Unknown signature status ]
>> On Sat, Oct 22, 2016 at 09:31:33PM +, ng0 wrote:
>>> Occasionally I use vim on systems to work on guix and other projects. As
>>> far as I see it, there is nothing similar to .dir-locals.el (the per
>>> directory local variables in emacs) for vim.
>>> 
>>> We should include modelines for every file to reflect what .dir-locals.el
>>> does when you use emacs. It's probably an unpopular opinion, but I think
>>> we should do this to be more open to people who do not use emacs.
>>> Support for vim and emacs covers most editors which are there to
>>> support.
>>> 
>>
>> IMO there's too many files to go adding to the bottom of all the files.
>> Something I've been thinking about is learning enough vimscript to write
>> a guix.vim file that'll take care of formatting.
>
> I agree, this could be more useful. The best approach would be to move
> this to a separate project, so that other systems can create packages
> for this to install it.

Different issue, but somehow related: Could we move the emacs
specific settings into an emacs mode if emacs modes can detect
some common structure or however we specify that the current file
which is edited is guix and not guile/scm alone?

>> -- 
>> Efraim Flashner  אפרים פלשנר
>> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>
>

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: [PATCH] gnu: vim: Update to 8.0.0047.

[ng0]

Ricardo Wurmus  writes:

> Marius Bakke  writes:
>
>> The official vim mirrors only carries major versions and individual
>> patches, no up-to-date releases. This patch changes the source uri to
>> the tagged github releases instead of downloading all 40+ (so far)
>> patches individually.
>>
>> I'm not very happy about changing to a third-party source, but IMO it
>> beats keeping track of the frequent patches. WDYT?
>
> I’m also not happy about using a third-party mirror for vim.  Can we be
> sure that this is updated consistently and in time?  (Is this done
> automatically?)
>
> Guix can handle downloading patches, so there’s really no need for
> switching in my opinion.  “gnu/packages/bash.scm” could be used as a
> reference for how to deal with a large number of patches.
>
> ~~ Ricardo

Last time I looked at the method used in bash.scm it was not
obvious how the method should be used, and from my impression in
irc it wasn't obvious to others when they tried to update bash or
what it was.

If vim gets an equal method, can we please document how the
patches are downloaded (in other words: how you execute the
download of scripts to store) in the module(s) or somewhere else?

In addition to my first message: I think we should not rely too
much on github.com, when it goes down again we have no fallback
solution.
-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: Web site news to move to Haunt

[ng0]

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

> Hello Guix!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> The goal is to manage news using Haunt, and to have a page to display
>> them on the web site, something nicer and more flexible than this:
>>
>>   https://savannah.gnu.org/news/?group=guix
>>
>> And I already enjoy Haunt!  :-)
>
> I’m done!

Great work, thanks!

> Please visit the news pages and report anything wrong!  Also, please
> test the feed.xml file; currently IceCat reports that it “does not
> appear to have any style information associated with it”, and thus
> doesn’t display it nicely.  Maybe Haunt omits to emit (ah ha!) the
> doctype thingie?

For me the feed.xml works (without librejs) with latest icecat.

> Because Savannah’s feeds only include the 20 newest entries¹, Assaf
> Gordon, who works on Savannah, kindly exported the raw Guix news
> database for me (54 entries).
>
> The database contains the input markup, not the XML that appears in the
> feed.  Of course the markup is nothing like Markdown, CommonMark, etc.
>
> So I considered writing a parser in Scheme, but that turned out to be
> trickier than I thought, so I turned back to running Savane’s own parser
> (PHP!).  Since I don’t have PHP on Guix, I ran it on another machine
> where it’s installed: PHP as a service.  And since I couldn’t run all of
> Savane, I just hacked together ‘markup.php’ (attached).  High-quality
> work.
>
> And then I reused the atom-parsing code that used to be in our (www)
> module to get the damn entries and emit them as SXML for Haunt (file
> attached).  Phewww.
>
> I think we should do the same for Guile real soon.
>
> Anyway, big thanks to Assaf!
>
> Ludo’.
>
> ¹ 
> https://lists.gnu.org/archive/html/savannah-hackers-public/2016-10/msg00017.html
>
>
>

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: Guix gathering in Berlin, Dec. 12th?

[ng0]

Ricardo Wurmus  writes:

> ng0  writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hello Guix!
>>>
>>> A couple of us will be in Berlin in December for the reproducible build
>>> summit, so I was wondering if there’d be interest in having a Guix
>>> gathering in Berlin on Dec. 12th.  It would be an opportunity to meet in
>>> person and discuss hot topics, use cases, future directions, and so on.
>>>
>>> If you think you’d be able to join, please let us know, either privately
>>> or on this list!
>>>
>>> Ludo’.
>>
>> I hope I'll be able to make it, I'm also interested in the
>> reproducible-builds meeting. I know next month if I'm able to
>> attend.
>>
>> Do you have any specific location in mind, like cbase, onionspace
>> or whatever one can get for the better half of day?
>
> I was thinking of either the IN-Berlin rooms or the e-Lok (where we have
> our FSFE gatherings).  e-Lok is close to Ostkreuz station.
>
> I’ve only been to cbase once after the FSFE summit and people smoke
> there.  I prefer indoor air to be without smoke.

I've been there after a conference and it was irritating. All
similar places I've been to have a no-smoke policy and people go
outside. If the rooms you suggested are no-smoke it would be
great.

> @Ludo: at what time would you like this to start and for how long do we
> want the room?
>
> ~~ Ricardo
>
>

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org