Re: [PATCH]:Resend: Add LLVM, clang and clang-runtime-3.8 to GNU Guix

[Dennis Mungai]

Hello fellows,

I have made a few changes that should ensure a successful build of
both clang and clang-runtime-3.8, by disabling test units from llvm
3.8 as they generated invalid targets for clang.

Test and confirm that the patch fixes the issues highlighted above.

Thanks and regards,

Dennis.


On 28 May 2016 at 18:30, Ludovic Courtès  wrote:
> Hi!
>
> Another question: is there any use for all these versions, or should we
> instead just bump llvm/clang/clang-runtime to 3.8?
>
> LLVM 3.6 currently has only five users:
>
> --8<---cut here---start->8---
> $ GUIX_PACKAGE_PATH= guix refresh -l llvm@3.6
> Building the following 2 packages would ensure 5 dependent packages are 
> rebuilt: rdmd-v2.070.0-1.da0a2e0 c-reduce-2.3.0
> --8<---cut here---end--->8---
>
> Thanks,
> Ludo’.
From 38643acf50749212a4455d15a1729002d6dfa04a Mon Sep 17 00:00:00 2001
From: brainiarc7 
Date: Tue, 31 May 2016 01:32:05 +0300
Subject: [PATCH] Add LLVM 3.8 to GNU Guix

---
 gnu/packages/llvm.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
index 3bf019f..e995ff2 100644
--- a/gnu/packages/llvm.scm
+++ b/gnu/packages/llvm.scm
@@ -2,6 +2,9 @@
 ;;; Copyright © 2014 Eric Bavier 
 ;;; Copyright © 2015 Mark H Weaver 
 ;;; Copyright © 2015 Ludovic Courtès 
+;;; Copyright © 2016 Dennis Mungai 
+;;; Copyright © 2016 Pjotr Prins 
+;;; Copyright © 2016 Roel Janssen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,6 +24,8 @@
 (define-module (gnu packages llvm)
   #:use-module (guix packages)
   #:use-module (guix licenses)
+  #:use-module (gnu packages compression)
+  #:use-module (gnu packages libffi)
   #:use-module (guix download)
   #:use-module (guix utils)
   #:use-module (guix build-system gnu)
@@ -201,3 +206,37 @@ code analysis tools.")
 (define-public clang-3.5
   (clang-from-llvm llvm-3.5 clang-runtime-3.5
"12yv3jwdjcbkrx7zjm8wh4jrvb59v8fdw4mnmz3zc1jb00p9k07w"))
+   
+(define-public llvm-3.8
+  (package (inherit llvm)
+(version "3.8.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "http://llvm.org/releases/;
+   version "/llvm-" version ".src.tar.xz"))
+   (sha256
+(base32
+ "0ikfq0gxac8xpvxj23l4hk8f12ydx48fljgrz1gl9xp0ks704nsm"
+(native-inputs
+ `(("python" ,python-wrapper)
+   ("perl" ,perl)
+   ("libffi" ,libffi)
+   ("zlib" ,zlib)))
+(arguments
+ `(#:configure-flags '("-DCMAKE_SKIP_BUILD_RPATH=FALSE"
+   "-DLLVM_INCLUDE_TESTS=OFF" ;; clang target units cannot be built (invalid test targets inherited from llvm result in build failure)
+   "-DLLVM_BUILD_TESTS=OFF"
+   "-DCMAKE_BUILD_TYPE=Release"
+   "-DCMAKE_BUILD_WITH_INSTALL_RPATH=FALSE"
+   "-DLLVM_ENABLE_PIC=ON"
+   "-DLLVM_ENABLE_WERROR=OFF")
+
+(define-public clang-runtime-3.8
+  (clang-runtime-from-llvm
+   llvm-3.8
+   "1c2nkp9563873ffz22qmhc0wakgj428pch8rmhym8agjamz3ily8"))
+
+(define-public clang-3.8
+  (clang-from-llvm llvm-3.8 clang-runtime-3.8
+   "1ybcac8hlr9vl3wg8s4v6cp0c0qgqnwprsv85lihbkq3vqv94504"))
-- 
2.7.4

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

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> For those willing to see more, a Git repository is available here:
>
>   https://notabug.org/mthl/cuirass

BTW, I can confirm that it “builds stuff” here when I let it go.

An improvement would be to redirect or filter
(current-build-output-port).  For instance, we could let only the “@”
lines go through (build started, build failed, etc.)

Ludo’.

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

[Ludovic Courtès]

Hello!

Mathieu Lirzin  skribis:

> Since it would be cumbersome to speak about something without giving it
> a name, I have decided to call this software “Cuirass”.

Interesting.  :-)

> While being intended as a general purpose continuous integration tool,
> the first iteration of Cuirass is focusing only on building Guix
> packages.  The logic of the program is simple since 'cuirass' sits in a
> loop:
>
>  - Fetching new changes from Guix master branch
>  - Compiling Guix code
>  - Evaluating packages derivations
>  - Building those derivations
>
> The Guix repository is kept in a directory set by 'CUIRASS_CACHEDIR'
> environment variable to avoid cloning it every time.  Even if the
> algorithm is trivial, the implementation has required some thought in
> order to allow using guile code fetched from the Guix git repository.
> Hopefully the solution was already in 'hydra-eval-guile-jobs' script
> from Hydra, so I have used the same technique.

So far, so good!

I think eventually ‘compile’ should disappear.  It should be up to the
project’s ‘evaluate.scm’ file (for Guix, it’s
‘build-aux/hydra/gnu-system.scm’) to compute whatever needs to be
computed to produce a list of derivations to build.

> Currently the build phase is failing with the following error:
>
> Starting download of 
> /gnu/store/y17blrd1x80nqik4ss4djbm92a5i5ivl-zsh-5.1.1.tar.gz
> From http://www.zsh.org/pub/zsh-5.1.1.tar.gz...
> ERROR: In procedure connect*: Network is unreachable
>
> Starting download of 
> /gnu/store/y17blrd1x80nqik4ss4djbm92a5i5ivl-zsh-5.1.1.tar.gz
> From http://www.zsh.org/pub/old/zsh-5.1.1.tar.gz...
> ERROR: In procedure connect*: Network is unreachable

Probably just a transient error on zsh.org.  The 1st URL is 404, and the
second one works for me.  I don’t think this has anything to do with
https.

Anyway, it’s good to see that the basics are in place!  :-)

Thanks for the update,
Ludo’.

Re: [PATCH 4/4] emacs: Add "Build Log" button to Package Info.

[Ludovic Courtès]

Alex Kost  skribis:

> * emacs/guix-main.scm (package-build-log-file): New procedure.
> * emacs/guix-ui-package.el (guix-package-build-log-file)
> (guix-package-find-build-log)
> (guix-package-info-insert-build-log-button): New procedures.
> (guix-package-info-button-functions): Add
> 'guix-package-info-insert-build-log-button'.

OK!

I think having this extra info and extra buttons is nice.  I wonder
though if in the future we should have a way to hide non-essential info
and buttons, so that someone who just wants to search and install/remove
software isn’t overwhelmed.

What are your thoughts?

Thank you!

Ludo’.

Re: [PATCH 3/4] emacs: Add "Build" button to Package Info.

[Ludovic Courtès]

Alex Kost  skribis:

> * emacs/guix-main.scm: Use (guix scripts) module for 'build-package'
>   procedure.
> * emacs/guix-base.el (guix-build-package): New procedure.
> * emacs/guix-ui-package.el (guix-package-info-insert-build-button): New
>   procedure.
  ^^
Extra indent.

> (guix-package-info-button-functions): New variable.
> (guix-package-info-insert-misc): Insert buttons using it.

OK!

Re: [PATCH 2/4] emacs: Extend 'guix-mapinsert'.

[Ludovic Courtès]

Alex Kost  skribis:

> * emacs/guix-utils.el (guix-mapinsert): Add 'indent' and 'column'
>   keyword arguments.

I’m intimidated by ‘dolist’, but it LGTM.  :-)

Ludo’.

Re: [PATCH 1/4] emacs: Show built output directories in Package Info.

[Ludovic Courtès]

Alex Kost  skribis:

> * emacs/guix-main.scm (package-store-path): New procedure.
> * emacs/guix-base.el (guix-package-store-path): New procedure.
> * emacs/guix-ui-package.el (guix-package-info-auto-find-package): New
> variable.
> (guix-package-info-show-store-path, guix-package-info-insert-misc): New
> procedures.
> (guix-package-info-format, guix-output-info-format): Add
> 'guix-package-info-insert-misc'.

LGTM.

Ludo’.

Re: [PATCH 1/1] services: urandom-seed: Set umask to 077 while shutting down.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/services/base.scm (urandom-seed-shepherd-service): Call 'umask'.
> ---
>  gnu/services/base.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gnu/services/base.scm b/gnu/services/base.scm
> index a45f219..8ed40a4 100644
> --- a/gnu/services/base.scm
> +++ b/gnu/services/base.scm
> @@ -461,6 +461,7 @@ stopped before 'kill' is called."
>   (call-with-input-file "/dev/urandom"
> (lambda (urandom)
>   (get-bytevector-n! urandom buf 0 512)
> + (umask #o077)
>   (call-with-output-file #$%random-seed-file

I think it’s safer to restore the umask afterwards, like:

  (let ((previous-umask (umask #o077)))
…
(umask previous-umask))

Otherwise LGTM, thanks!

Ludo’.

[PATCH] Add msgpack

[Lukas Gradl]

Hello Guix,

Attached is a patch for the c/c++ version of msgpack.  This is a
dependency of the Ring.

Thank you!

>From 25eef52146bc84e83d90e429a0a2a5ca607280bc Mon Sep 17 00:00:00 2001
From: Lukas Gradl 
Date: Mon, 30 May 2016 15:46:29 -0500
Subject: [PATCH] gnu: serialization: Add msgpack.

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

diff --git a/gnu/packages/serialization.scm b/gnu/packages/serialization.scm
index 8dfd21d..524754b 100644
--- a/gnu/packages/serialization.scm
+++ b/gnu/packages/serialization.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015 Ricardo Wurmus 
+;;; Copyright © 2016 Lukas Gradl 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,7 +22,11 @@
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system cmake)
+  #:use-module (guix build-system gnu)
   #:use-module (gnu packages)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages check)
+  #:use-module (gnu packages compression)
   #:use-module (gnu packages documentation))
 
 (define-public cereal
@@ -72,3 +77,29 @@
 arbitrary data types and reversibly turns them into different representations,
 such as compact binary encodings, XML, or JSON.")
 (license license:bsd-3)))
+
+
+(define-public msgpack
+  (package
+(name "msgpack")
+(version "1.4.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri
+(string-append
+ "https://github.com/msgpack/msgpack-c/releases/download/;
+ "cpp-1.4.1/msgpack-" version ".tar.gz"))
+   (sha256
+(base32
+ "0bpjfh9vz0n2k93mph3x15clmigkgs223xfn8h12ymrh5gsi5ica"
+(build-system gnu-build-system)
+(native-inputs
+ `(("googletest" ,googletest)))
+(inputs
+ `(("zlib" ,zlib)))
+(home-page "http://www.msgpack.org;)
+(synopsis "Binary serialization library")
+(description "Msgpack is a library for C/C++ that implements binary
+serialization.")
+(license license:boost1.0)))
-- 
2.7.4

[PATCH] Add googletest

[Lukas Gradl]

Hello Guix,

This patch adds googletest, a native-input for the c/c++ version of
msgpack (coming soon).

There is no "install" target.  At the moment the patch copies the build
results to out/lib and the include directory of the source tree to
out/include.  I am not sure if this is enough or if something else needs
to be installed.  Opinions are welcome!

Thank you!

>From 0560038dd1c529cca46e31c6afbb5cd16808db43 Mon Sep 17 00:00:00 2001
From: Lukas Gradl 
Date: Mon, 30 May 2016 15:35:10 -0500
Subject: [PATCH] gnu: check: Add googletest.

* gnu/packages/check.scm (googletest): New variable.
---
 gnu/packages/check.scm | 41 +
 1 file changed, 41 insertions(+)

diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm
index 9eef7a9..f6b586a 100644
--- a/gnu/packages/check.scm
+++ b/gnu/packages/check.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2015 Andreas Enge 
 ;;; Copyright © 2016 Efraim Flashner 
 ;;; Copyright © 2016 Roel Janssen 
+;;; Copyright © 2016 Lukas Gradl 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -24,6 +25,7 @@
 (define-module (gnu packages check)
   #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
+  #:use-module (gnu packages python)
   #:use-module (guix licenses)
   #:use-module (guix packages)
   #:use-module (guix download)
@@ -193,3 +195,42 @@ in the code.  Cppcheck primarily detects the types of bugs that the compilers
 normally do not detect.  The goal is to detect only real errors in the code
 (i.e. have zero false positives).")
 (license gpl3+)))
+
+(define-public googletest
+  (package
+(name "googletest")
+(version "1.7.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri
+(string-append
+ "https://github.com/google/googletest/archive/release-;
+ version ".tar.gz"))
+   (sha256
+(base32
+ "1k0nf1l9cb3prdmsvaajl5i31bx86c1mw0d5jgzykz7rzm36afpp"
+(build-system cmake-build-system)
+(native-inputs
+ `(("python-2" ,python-2)))
+(arguments
+ `(#:tests? #f
+   ;#:configure-flags '("-Dgtest_build_tests=ON")
+   #:phases (modify-phases %standard-phases
+  (replace 'install
+(lambda _
+  (let ((out (assoc-ref %outputs "out")))
+(and
+ (mkdir-p (string-append out "/lib"))
+ (mkdir-p (string-append out "/include"))
+ (zero? (system* "cp" "libgtest.a" "libgtest_main.a"
+ (string-append out "/lib")))
+ (system* "ls")
+ (zero? (system* "ls" "..")
+(home-page "https://github.com/google/googletest/;)
+(synopsis "Test discovery and XUnit test framework")
+(description "Google Test features an XUnit test framework, automated test
+discovery, death tests, assertions, parameterized tests and XML test report
+generation.")
+(license bsd-3)))
+   
-- 
2.7.4

guix ignores --no-substitutes

[Federico Beffa]

Hi,

I find that Guix still contacts home even when passed the
'--no-substitutes' flag:

$ ./pre-inst-env guix build --no-substitutes chez-sockets
substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... substitute: updating list of
substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://hydra.gnu.org'... 100.0%
@ build-started ...

It would be desirable to avoid all calls home with that flag.

Regards,
Fede

[no subject]

[Tomáš Čech]

OK, I got too excited with sending patch, I'm just glad I get in touch once
again. And besides, that GPG signing of commits is new to me.

S_W

[PATCH] gnu: Add py3status.

[Tomáš Čech]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index dc54bff..d139dbc 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -8788,3 +8788,25 @@ the renaming, moving and extracting of attributes, 
functions, modules, fields
 and parameters in Python 2 source code.  These refactorings can also be applied
 to occurences in strings and comments.")
 (license gpl2)))
+
+(define-public python-py3status
+  (package
+(name "python-py3status")
+(version "2.9")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "py3status" version))
+   (sha256
+(base32
+ "09y7h8rjay5kzwk5akq7f5f9wqnvjkxhivck04hdc8ny1nw3vqzp"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(home-page "https://github.com/ultrabug/py3status;)
+(synopsis "Extensible i3status wrapper written in python")
+(description "py3status is i3status wrapper which extends i3status
+functionality in modular way, allowing you to extend your panel with
+your own code, responding to click events and update clock every
+second.")
+(license bsd-3)))
-- 
2.8.3

Re: [PATCH] Add libiax

[Lukas Gradl]

Leo Famulari  writes:

> On Sat, May 28, 2016 at 06:08:57PM -0500, Lukas Gradl wrote:
>> +  #:use-module (gnu packages autotools)  
>^
> Also, there is some extra whitespace at the end of the line above.
>

Oops!  Good catch!

>> + (uri
>> +  (string-append
>> +   "https://gitlab.savoirfairelinux.com/sflphone/libiax2/;
>> +   "repository/archive.tar.gz?ref="
>> +   commit))
>
> Can you use (file-name ...) to make the file-name like
> libiax-version.tar.gz?
>

I updated this in the attached patch.

Thank you for your review!


>From 581f899fe2ff3db7151b5d488dc00c77ca9602bd Mon Sep 17 00:00:00 2001
From: Lukas Gradl 
Date: Mon, 30 May 2016 14:40:51 -0500
Subject: [PATCH] gnu: telephony: Add libiax.

* gnu/packages/telephony.scm (libiax): New variable.
---
 gnu/packages/telephony.scm | 36 
 1 file changed, 36 insertions(+)

diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index 50a83fb..0f43e79 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2015 Andreas Enge 
 ;;; Copyright © 2015 David Hashe 
 ;;; Copyright © 2015 Efraim Flashner 
+;;; Copyright © 2016 Lukas Gradl 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,6 +22,7 @@
 
 (define-module (gnu packages telephony)
   #:use-module (gnu packages)
+  #:use-module (gnu packages autotools)
   #:use-module (gnu packages gnupg)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages pkg-config)
@@ -211,3 +213,37 @@ Real-time Transport Protocol (SRTP), the Universal Security Transform (UST),
 and a supporting cryptographic kernel.")
 (home-page "https://github.com/cisco/libsrtp;)
 (license bsd-3)))
+
+(define-public libiax
+  (let ((commit "0e5980f1d78ce462e2d1ed6bc39ff35c8341f201"))
+;; This is the commit used by the Ring Project.
+(package
+  (name "libiax")
+  (version (string-append "0.0.0-1." (string-take commit 7)))
+  (source
+   (origin
+ (method url-fetch)
+ (uri
+  (string-append
+   "https://gitlab.savoirfairelinux.com/sflphone/libiax2/;
+   "repository/archive.tar.gz?ref="
+   commit))
+ (file-name (string-append name "-" version ".tar.gz"))
+ (sha256
+  (base32
+   "0cj5293bixp3k5x3hjwyd0iq7z8w5p7yavxvvkqk5817hjq386y2"
+  (build-system gnu-build-system)
+  (native-inputs
+   `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("libtool" ,libtool)))
+  (arguments
+   `(#:phases (modify-phases %standard-phases
+(add-before 'configure 'autoconf
+  (lambda _
+(zero? (system* "autoreconf" "-vfi")))
+  (home-page "https://gitlab.savoirfairelinux.com/sflphone/libiax2;)
+  (synopsis "Inter-Asterisk-Protocol library")
+  (description "LibIAX implements the Inter-Asterisk-Protocol for relaying
+Voice-over-IP (VoIP) communications.")
+  (license lgpl2.0
-- 
2.7.4

Re: [PATCH] Add libiax

[Lukas Gradl]

Thank you for your review!

Leo Famulari  writes:

> On Sat, May 28, 2016 at 06:08:57PM -0500, Lukas Gradl wrote:
>> 
>> Hi Guix,
>> 
>> Attached is a patch for LibIAX, a library that is used by the Ring
>> (formerly SFLphone).
>
> Cool!
>
>> Upstream seems to use no version numbers.  I used the git commit ID that
>> is also refered to in the version that is bundeled with Ring.  This is
>> also the latest commit to libiax.
>
> Since there are no upstream versions, I think the version string should
> use 0.0.0 to refer to the upstream version, then the Guix package
> revision number, and then the 7 characters of the commit.
>
> So, it would end up like this: 0.0.0-1.cabba9e
>
> See here:
> https://www.gnu.org/software/guix/manual/html_node/Version-Numbers.html#Version-Numbers

OK, Thank you for pointing this out!  I missed that in the manual.
I updated the patch accordingly and will send it soon.

>
>> +(package
>> +  (name "libiax")
>> +  (version (string-append "2-" (string-take commit 7)))
>
> By the way, what does the "2-" refer to?

Upstream seems to refer to the software as "iax" "libiax" and "libiax2"
interchangeably.  The "2" was the closest thing I could find to a version
number.

Thank you!

Re: [PATCH] Add zimg.

[Ricardo Wurmus]

Efraim Flashner  writes:

> On Sun, May 29, 2016 at 08:34:15PM +0200, Ricardo Wurmus wrote:
>> 
>> Efraim Flashner  writes:
>> 
>> > here's a patch to add zimg, a new dependency for vapoursynth in versions
>> > 29 and above.
>> 
>> Thanks, this looks good to me.  Too bad the release tarball is not
>> bootstrapped.
>> 
>> I found that the tests contain third-party libs under Expat license
>> (e.g. “musl”).  Not sure if this needs to be declared.
>> 
>> ~~ Ricardo
>> 
>
> I've thought about it, and no one else has chimed in. Its in the test
> folder and doesn't affect the rest of the code so I've made a note of it
> next to the license field but haven't included it as one of the licenses
> for the program.

I think that’s reasonable.  Thanks!

~~ Ricardo

[PATCH] gnu: Add py3status.

[Tomáš Čech]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index dc54bff..42a0e8a 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -8788,3 +8788,27 @@ the renaming, moving and extracting of attributes, 
functions, modules, fields
 and parameters in Python 2 source code.  These refactorings can also be applied
 to occurences in strings and comments.")
 (license gpl2)))
+
+(define-public python-py3status
+  (package
+(name "python-py3status")
+(version "2.9")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+
"https://pypi.python.org/packages/60/cd/79b6d249befe0a136a29e2d634a4ac78730bc240bec247fc3bfa355f644b/py3status-;
+version ".tar.gz"))
+   (sha256
+   (base32
+""
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(home-page "https://github.com/ultrabug/py3status;)
+(synopsis "Extensible i3status wrapper written in python")
+(description "py3status is i3status wrapper which extends i3status
+functionality in modular way, allowing you to extend your panel with
+your own code, responding to click events and update clock every
+second.")
+(license bsd-3)))
-- 
2.8.3

Re: [PATCH] Add zimg.

[Efraim Flashner]

On Sun, May 29, 2016 at 08:34:15PM +0200, Ricardo Wurmus wrote:
> 
> Efraim Flashner  writes:
> 
> > here's a patch to add zimg, a new dependency for vapoursynth in versions
> > 29 and above.
> 
> Thanks, this looks good to me.  Too bad the release tarball is not
> bootstrapped.
> 
> I found that the tests contain third-party libs under Expat license
> (e.g. “musl”).  Not sure if this needs to be declared.
> 
> ~~ Ricardo
> 

I've thought about it, and no one else has chimed in. Its in the test
folder and doesn't affect the rest of the code so I've made a note of it
next to the license field but haven't included it as one of the licenses
for the program.

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


signature.asc
Description: PGP signature

Re: [PATCH 2/5] gnu: Add avr-gcc.

[Thompson, David]

On Thu, Apr 14, 2016 at 1:25 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> * gnu/packages/avr.scm (avr-gcc): New variable.
>
> [...]
>
>> +  `(modify-phases ,phases
>> + ;; Without a working multilib build, the resulting GCC lacks
>> + ;; support for nearly every AVR chip.
>> + (add-after 'unpack 'fix-genmultilib
>> +   (lambda _
>> + (substitute* "gcc/genmultilib"
>> +   (("#!/bin/sh") (string-append "#!" (which "sh"
>
> Just: (patch-shebang "gcc/genmultilib").
>
> I think the reason this file is not automatically patched during the
> ‘patch-shebangs’ phase is because it does not have the executable bit.
> Would be worth mentioning in a comment IMO.
>
> What’s unclear, though, is why the invalid shebang is a problem at all
> given that this file is not executable anyway.  Thoughts?

It turns out that gcc/genmultilib is a script that generates many
scripts, and thus has many instances of #!/bin/sh in it.  So,
patch-shebang was inadequate for the job and I've stuck with the
original solution.

>> + ((#:configure-flags flags)
>> +  '(list "--target=avr"
>> + "--enable-languages=c,c++"
>> + "--disable-nls"
>> + "--disable-libssp"
>> + "--with-dwarf2"
>
> I think we should minimize target-specific changes and justify them in a
> comment when they’re unavoidable.
>
> Here, I think we can safely remove --target and --disable-nls.
> --disable-libssp and --enable-languages are already in
> ‘cross-gcc-arguments’, so that leaves us with just --with-dwarf2, IIUC.
>
> Why is it needed?

I've removed all of these.

>> +  (native-search-paths
>> +   (list (search-path-specification
>> +  (variable "CROSS_CPATH")
>> +  (files '("avr/include")))
>> + (search-path-specification
>> +  (variable "CROSS_LIBRARY_PATH")
>> +  (files '("avr/lib"
>
> That these go in ‘native-search-paths’ feels wrong.
>
> But I think it’s because we’re trying to build avr-libc like a “normal”
> package with a cross-toolchain as its input.
>
> Instead, the “intended use” is that libc is treated specially as in
> ‘cross-libc’ in cross-base.scm.  Probably we need to:
>
>   1. Remove #:configure-flags and ‘native-inputs’ from the ‘avr-libc’
>  package.
>
>   2. Add (supported-systems '()) or similar to the ‘avr-libc’ package.
>
>   3. Use something similar to ‘cross-libc’ but that uses avr-libc
>  instead of glibc in cross-base.scm, thus setting CROSS_CPATH and
>  CROSS_LIBRARY_PATH appropriately.

As explained in the thread about the avr-toolchain, this is a special
scenario because the only use for avr-gcc is to cross-compile and you
cannot actually port any part of Guix to the AVR architecture.  Maybe
there's still something to revisit later, but having a working AVR
toolchain is a big win for now.

Pushed with the other issues addressed.  Thanks!

- Dave

Re: [PATCH 1/5] gnu: Add avr-binutils.

[Thompson, David]

On Tue, Apr 19, 2016 at 10:55 AM, Ludovic Courtès  wrote:
> Manolis Ragkousis  skribis:
>
>> And I would really prefer if we had a way to explicitly install
>> avr-binutils.  This way it will be more clear to someone only wanting to
>> install this specific package.
>>
>> We could keep something like this
>>
>> (define-public avr-binutils
>>   (package
>> (inherit (cross-binutils "avr"))
>> (name "avr-binutils")))
>
> I see.  In that case, that’s a fine thing to do!
>
> Maybe (define-public avr-binutils (cross-binutils "avr")) is enough
> though?  Or is its name too wordy?

The name was too wordy, IMO, and it is nice to have consistency with
all the avr toolchain components prefixed with "avr-", so I've pushed
a patch that simply gives (cross-binutils "avr") a new name.

Thanks!

- Dave

Re: [PATCH 3/5] gnu: avr-libc: Fix build.

[Thompson, David]

On Fri, Apr 15, 2016 at 5:12 PM, Ludovic Courtès  wrote:
> "Thompson, David"  skribis:
>
>> On Thu, Apr 14, 2016 at 1:26 PM, Ludovic Courtès  wrote:
>>> David Thompson  skribis:
>>>
 * gnu/packages/avr.scm (avr-libc): Update to 2.0.0.
 [native-inputs]: Use new avr-gcc and avr-binutils.
 [arguments]: Add phase to unset C_INCLUDE_PATH.
>>>
>>> Please make the update a separate patch, which you can push right away.
>>> ;-)
>>
>> I don't see why I should push that separately given that avr-libc has
>> been broken for a long time.
>>
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23115
>>
>> I can just not update it here at all and get everything fixed first.
>
> OK, I had overlooked that.  Your call!

I decided to push the build fix and the version bump as two separate commits.

Thanks!

- Dave

Re: [PATCH 4/5] gnu: Add avr-toolchain.

[Thompson, David]

Reviving this old thread.

On Thu, Apr 14, 2016 at 1:33 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> * gnu/packages/avr.scm (avr-toolchain): New variable.
>
> I’m guessing that the goal is to allow users to install it in a profile
> and build stuff interactively from there, right?
>
> However, profiles currently contain only native packages; patch #2 moves
> ’search-paths’ to ‘native-search-paths’, which in part is a way to work
> around this limitation.
>
> I think a better solution would be to allow users to build profiles that
> contain non-native packages.  That way, we could do things like:
>
>   guix environment --target=avr foo
>
> Thoughts?
>
> Until this is possible, we could apply this patch with the added
> search-paths/native-search-paths hack (assuming said hack has been
> removed from patch #2.)
>
> Does it makes sense?

We discussed this on IRC quite awhile back, and the conclusion was
that this didn't make sense because compiling for AVR isn't like
compiling for an architecture like x86 or MIPS because you cannot
actually run any "normal" software on an AVR.  They are very
special-purpose, 8-bit processors with a limited amount of resources
and can not run GNU/Linux.  Thus, the only way that one would want to
use avr-gcc is to have it compiled for their workstation's
architecture so that they can cross-compile AVR firmware.

I think the native-search-paths make sense for this use-case.  With
this toolchain I've once again been able to build the firmware for my
arcade stick.

Without further ado, I will push this.

- Dave

[GSoC] Porting GuixSD to GNU/Hurd Update 1

[Manolis Ragkousis]

Hello everyone,

One week passed since the beginning of the coding phase of GSoC, so I
think it's time to give you an update on my progress.

In the previous weeks I tried to get me prepared as much as possible and
get a better idea of what needs to be done.  I concentrated on getting
familiar with the parts of Guix and Hurd that are more relevant to this
project and I found out some interesting things.

We already knew that the guix-daemon was not working properly on the
Hurd.  I looked more into it and I found that if you do a build with
Guix and it fails, and then you retry again, the next one will create a
new build directory in /tmp/ as it should, but it will still use the
first one.  What this means is that the status of the previous build
leaks into the new one and there is no isolation.  With this in mind
build isolation in the daemon is currently my first priority.

I also found out that guix publish may sometimes crash if a client asks
for a big substitute.  I will investigate this one as soon as possible.

Now on the coding part, in Guix I updated the gnumach/mig/hurd packages
to the latest version and worked on getting wip-hurd in a state which
can eventually merge to master.  A part of wip-hurd is already on master
and after this core-updates cycle is merged to master, we will be able
to get the rest of wip-hurd merged as well. Package glibc/hurd will also
be updated then as well.

On debian/hurd I am using Guix every day and in my github wip-hurd I
have some patches which I need to clean up and apply to the Guix repo.
These patches are for various packages of various importance.

And on the Hurd side, I created a new library called libhurdutil and
moved the settrans implementation there.  For implementation info please
read this email[1]. I am currently improving that library after
Guillem's and Justus' input. (Thank you :-))  On the Guix side I will
just write a wrapper to use this call and we will be able to control
translators really easily.  This way the non existing mount() is not a
problem anymore :-).

I think that's enough for now.  If you have any questions/suggestions
please feel free to tell me. :-)

Thank you,
Manolis

[1]https://lists.gnu.org/archive/html/bug-hurd/2016-05/msg00041.html

Solving the ‘package-name->name+version’ name conflict. (was: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.)

[Mathieu Lirzin]

Hi,

I am a bit late.

David Thompson  writes:

> * guix/build/emacs-build-system.scm (gnu:unpack)
> (store-file->elisp-source-file, unpack): New procedures.
> (%standard-phases): Use the new unpack procedure.
> ---
>  guix/build/emacs-build-system.scm | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/guix/build/emacs-build-system.scm 
> b/guix/build/emacs-build-system.scm
> index f0a9a6e..4fd36d1 100644
> --- a/guix/build/emacs-build-system.scm
> +++ b/guix/build/emacs-build-system.scm
> @@ -21,6 +21,7 @@
>#:use-module (guix build utils)
>#:use-module (guix build emacs-utils)
>#:use-module (srfi srfi-1)
> +  #:use-module (srfi srfi-11)
>#:use-module (srfi srfi-26)
>#:use-module (ice-9 rdelim)
>#:use-module (ice-9 regex)
> @@ -39,6 +40,27 @@
>  ;; archive signature.
>  (define %install-suffix "/share/emacs/site-lisp/guix.d")
>  
> +(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
> +
> +(define (store-file->elisp-source-file file)
> +  "Convert file, a store file name for an Emacs Lisp source file, into a file
> +name that has been stripped of the hash and version number."
> +  (let-values (((name version)
> +(package-name->name+version
^^^

This is the old ‘package-name->name+version’ from (guix build utils)
which has been replaced when possible by a new one in (guix utils) using
'@' as a delimiter.  While I think it was OK to use it to fix previously
written code, I don't want Guix to build upon the old one.

Time has come to resolve this ugly and confusing name conflict.  The
problem is that I don't fully understand the rationale behind this
temporary solution, so I can't help much.

Ludo: Since you are the mind behind it, I think you are in the best
position to figure this out or at least explain to us “mere mortals”
what is possible and what is not.  :)

-- 
Mathieu Lirzin

Re: [PATCH] Add GeoGebra

[Alex Vong]

Hi,


I have skimmed through the patch, the website of geogebra, and I have
noticed some problems.


+   ;; Move ".jar" files and license into "share/geogebra/".
It seems the jar files are copied into the installation directory.
This is no good because guix requires compiling everything from source
(except the bootstrap binaries). There is an ant-build-system in guix
(https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00207.html),
you may find it useful.


+;; Source code uses GPLv3+.  Other parts (e.g., translations) use
+;; a Non-Commercial clause.
This is hairy. I have looked at the website.

At the top of the website, it said
"You are free to copy, distribute and transmit GeoGebra for
non-commercial purposes (please see details below)."

But at the end of the website, it said
"Please note that GeoGebra as a complete software program would
probably not be considered "free" software according to the definition
of that term which is used \
by the Free Software Foundation. This is because the restrictions on
commercial use that apply to the GeoGebra installers, web services and
language files add-ons m\
ight be seen to be a restriction on the software as a whole (thus
making it "non-free"), even though the GeoGebra source code is made
available under the GNU General Public License without restriction.
You can rest assured that our license terms fully respect \
all existing licenses from third parties (including the GNU General
Public License and all Creative Commons variants) and have been
checked by an experienced \
law firm."

I guess this means the source is free-sw, but not the binaries and
translation, so we would have add a build phase to delete those
non-free parts. How do the other think about the license?


Thanks,
Alex


On 30/05/2016, Nicolas Goaziou  wrote:
> Hello,
>
> The following patch adds GeoGebra. Please consider adding it to the
> repository.
>
> Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Thompson, David]

On Mon, May 30, 2016 at 6:14 AM, Alex Kost  wrote:
> Ludovic Courtès (2016-05-30 00:50 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2016-05-28 18:36 +0300) wrote:
>>>
 David Thompson  skribis:

> * guix/build/emacs-build-system.scm (gnu:unpack)
> (store-file->elisp-source-file, unpack): New procedures.
> (%standard-phases): Use the new unpack procedure.

 Good idea, LGTM!

 Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
 commit, and remove ‘uncompressed-file-fetch’?
>>>
>>> I object!
>>
>> Damn it, sorry, I thought this would be uncontroversial.
>>
>>> I mean this should be discussed at least.  I would really prefer to
>>> keep (and document) 'uncompressed-file-fetch' and not to update
>>> emacs-build-system for this case.  It is possible, that once we'll
>>> need to handle non-compressed files for another build system.  So it
>>> should also be adjusted in the same way.  But if we keep
>>> 'uncompressed-file-fetch', it will be a general decision as it can be
>>> used for any build system.
>>
>> In my view, ‘uncompressed-file-fetch’ and the ‘emacs-build-system’
>> change that Dave proposes are equally good hacks, but the latter has the
>> advantage that people won’t have to think about it: they can just use
>> ‘url-fetch’ and ‘emacs-build-system’ as usual and things will just work.
>>
>> Of course, perhaps we should consider handling flat files closer to the
>> core, but so far the only use case we have, AFAIK, is .el files.  Thus,
>> it doesn’t seem that bad to add a special case in ‘emacs-build-system’.
>> Pragmatic approach I suppose.  ;-)
>>
>> WDYT?
>
> , OK, I wanted to write verbosely why I prefer
> uncompressed-file-fetch, and why we should still use it, etc.;
>
> but I've just noticed an unpleasant downside with
> ‘uncompressed-file-fetch’: for example, if you build the recently added
> "emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
> impossible to do (require 'queue).  With David's solution, it will be a
> proper "queue.el" file.
>
> So I agree now.  David's patch is definitely a better solution :-)

Hehe.  Thanks for the discussion.  Pushed!

- Dave

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Thompson, David]

On Sat, May 28, 2016 at 11:37 AM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> * gnu/packages/emacs.scm (emacs-better-defaults): New variable.
>
> [...]
>
>> +   (uri (string-append 
>> "http://stable.melpa.org/packages/better-defaults-;
>> +   version ".el"))
>
> IIRC, MELPA URLs are not stable over time (modified in place) and for
> this reason we usually fetch things from Git instead.
>
> Could you do that here?

Fixed and pushed.  Thanks Ludo and Alex!

- Dave

feedback as solicited by Guix manual (Section 7.1.5)

[Ethan Stefan Day]

Hello,

I just got finished setting up GuixSD on one of these
, to
use as a fun/hacking box.  I hit a bump with partitioning the drive, but
managed to figure it out.  The Guix manual refers to the Parted manual
for an overview of partitioning, but the Parted manual no longer
provides that and instead references some other manual without providing
a link.  It was rather comical:

"Error, no bios_grub partition.  Grub not installed."
"Oh, well I made the root drive bootable.  Lets just reboot and see what
happens."
...
"BEEP BEEP BEEP BEEP BEEP BEEP BEEP BEEP..."

I am running Gnome, and aside from video tearing and Icecat not
appearing in the activities view, things seem to be working fine.  I'll
be looking for ways to contribute once I have a better understanding of
the system.  Thanks for putting this together, and a particular thanks
to whoever packaged GHC (I have read that bootstrapping it can be tricky).

-Ethan Day

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Catonano]

2016-05-30 13:55 GMT+02:00 Catonano :

> 2016-05-30 12:14 GMT+02:00 Alex Kost :
>
>>
>> , OK, I wanted to write verbosely why I prefer
>> uncompressed-file-fetch, and why we should still use it, etc.;
>>
>> but I've just noticed an unpleasant downside with
>> ‘uncompressed-file-fetch’: for example, if you build the recently added
>> "emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
>> impossible to do (require 'queue).  With David's solution, it will be a
>> proper "queue.el" file.
>>
>> So I agree now.  David's patch is definitely a better solution :-)
>>
>>
> Ah ! This is probably why I couldn't manage emacs-cider to require
> emacs-spinner and emacs-queue. They both are packaged with
> uncompressed-file-fetch.
>
> In fact queue and spinner work if I installl them on their own.
>
> After I attempt with cider, they not only are not requirable but they are
> also not autoloaded anymore.
>
> So now I'll try stick with more tested download methods and see if cider
> works with those.
>
>

queue is available only as an uncompresse file

So I'll wait for this patch to be merged and then I'll try with the new
emacs-build-system

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Catonano]

2016-05-30 12:14 GMT+02:00 Alex Kost :

>
> , OK, I wanted to write verbosely why I prefer
> uncompressed-file-fetch, and why we should still use it, etc.;
>
> but I've just noticed an unpleasant downside with
> ‘uncompressed-file-fetch’: for example, if you build the recently added
> "emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
> impossible to do (require 'queue).  With David's solution, it will be a
> proper "queue.el" file.
>
> So I agree now.  David's patch is definitely a better solution :-)
>
>
Ah ! This is probably why I couldn't manage emacs-cider to require
emacs-spinner and emacs-queue. They both are packaged with
uncompressed-file-fetch.

In fact queue and spinner work if I installl them on their own.

After I attempt with cider, they not only are not requirable but they are
also not autoloaded anymore.

So now I'll try stick with more tested download methods and see if cider
works with those.

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Alex Kost]

Ludovic Courtès (2016-05-30 00:50 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2016-05-28 18:36 +0300) wrote:
>>
>>> David Thompson  skribis:
>>>
 * guix/build/emacs-build-system.scm (gnu:unpack)
 (store-file->elisp-source-file, unpack): New procedures.
 (%standard-phases): Use the new unpack procedure.
>>>
>>> Good idea, LGTM!
>>>
>>> Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
>>> commit, and remove ‘uncompressed-file-fetch’?
>>
>> I object!
>
> Damn it, sorry, I thought this would be uncontroversial.
>
>> I mean this should be discussed at least.  I would really prefer to
>> keep (and document) 'uncompressed-file-fetch' and not to update
>> emacs-build-system for this case.  It is possible, that once we'll
>> need to handle non-compressed files for another build system.  So it
>> should also be adjusted in the same way.  But if we keep
>> 'uncompressed-file-fetch', it will be a general decision as it can be
>> used for any build system.
>
> In my view, ‘uncompressed-file-fetch’ and the ‘emacs-build-system’
> change that Dave proposes are equally good hacks, but the latter has the
> advantage that people won’t have to think about it: they can just use
> ‘url-fetch’ and ‘emacs-build-system’ as usual and things will just work.
>
> Of course, perhaps we should consider handling flat files closer to the
> core, but so far the only use case we have, AFAIK, is .el files.  Thus,
> it doesn’t seem that bad to add a special case in ‘emacs-build-system’.
> Pragmatic approach I suppose.  ;-)
>
> WDYT?

, OK, I wanted to write verbosely why I prefer
uncompressed-file-fetch, and why we should still use it, etc.;

but I've just noticed an unpleasant downside with
‘uncompressed-file-fetch’: for example, if you build the recently added
"emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
impossible to do (require 'queue).  With David's solution, it will be a
proper "queue.el" file.

So I agree now.  David's patch is definitely a better solution :-)

-- 
Alex

Re: [PATCH 2/4] emacs-pkg-info

[Alex Kost]

Catonano (2016-05-29 18:53 +0300) wrote:

> From 6b4542d9f52b8f91375d07bd41bcc196a1c0515a Mon Sep 17 00:00:00 2001
> From: humanitiesNerd 
> Date: Sun, 29 May 2016 10:23:00 +0200
> Subject: gnu: Add emacs-pkg-info.
>
> * gnu/packages/emacs.scm (emacs-pkg-info).

Almost, but not quite ;-)  should be:

* gnu/packages/emacs.scm (emacs-pkg-info): New variable.

> ---
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 90f55ea..92ad434 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -1727,3 +1727,25 @@ first-in first-out (FIFO) stack, i.e. elements can be 
> added to the front or
>  back of the queue, and can be removed from the front. (This type of data
>  structure is sometimes called an \"output-restricted deque\")")
>  (license license:gpl3+)))
> +
> +(define-public emacs-pkg-info
> +  (package
> +(name "emacs-pkg-info")
> +(version "0.6")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + "https://github.com/lunaryorn/pkg-info.el/archive/;
> + version ".tar.gz"))
> +   (file-name (string-append name "-" version ".tar.gz"))
> +   (sha256
> +(base32
> +  "1gy1jks5mmm02gg1c8gcyr4f8a9s5ggzhk56gv33b9mzjqzi5rd5"
> +(build-system emacs-build-system)
> +(propagated-inputs `(("emacs-epl" ,emacs-epl)))
> +(home-page "https://github.com/lunaryorn/pkg-info.el;)
> +(synopsis "Information about packages")

I wrote: "Information about Emacs packages".

> +(description
> + "This library extracts information from installed packages.")

and: "This library extracts information from installed Emacs packages."

I made similar modifications (to mention "Emacs") in
synopses/descriptions for other packages, and committed all your
patches, thanks!

-- 
Alex

Re: [PATCH 1/4] emacs-queue

[Alex Kost]

Catonano (2016-05-29 18:53 +0300) wrote:

> From 89849ff33cd67243d691748f77f13474676d5361 Mon Sep 17 00:00:00 2001
> From: humanitiesNerd 
> Date: Fri, 27 May 2016 10:01:59 +0200
> Subject: gnu: Add emacs-queue.
>
> *  gnu/packages/emacs.scm (emacs-queue): New variable.
> ---
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 5d6db5a..90f55ea 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -1706,3 +1706,24 @@ It is recommended to use @code{clojure-mode} with 
> paredit or smartparens.")
>  The purpose of this library is to wrap all the quirks and hassle of
>  @code{package.el} into a sane API.")
>  (license license:gpl3+)))
> +
> +(define-public emacs-queue
> +  (package
> +(name "emacs-queue")
> +(version "0.1.1")
> +(source
> + (origin
> +   (method uncompressed-file-fetch)
> +   (uri (string-append "http://elpa.gnu.org/packages/queue-; version 
> ".el"))
> +   (sha256
> + (base32
> +  "0jw24fxqnf9qcaf2nh09cnds1kqfk7hal35dw83x1ari95say391"
> +(build-system emacs-build-system)
> +(home-page "http://www.dr-qubit.org/emacs.php;)

This page tells it moved to

so I changed it.


> +(synopsis "Queue data structure")

I made it: "Queue data structure for Emacs"

> +(description
> + "These queues can be used both as a first-in last-out (FILO) and as a

I added here:

  This Emacs library provides queue data structure.  These queues ...

> +first-in first-out (FIFO) stack, i.e. elements can be added to the front or
> +back of the queue, and can be removed from the front. (This type of data
> +structure is sometimes called an \"output-restricted deque\")")
> +(license license:gpl3+)))

Applied, thanks!

-- 
Alex

Re: [PATCH 7/7] guix import: Print list of expressions.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * guix/scripts/import.scm (guix-import): Print list of expressions.

Depending on your answer to #6, maybe we’d bring more of the recursive
functionality to this file.  :-)

Anyway, this is a step in the right direction, thanks for working on it!

Ludo’.

Re: [PATCH 6/7] import cran: Add "recursive" option.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * guix/scripts/import/cran.scm: (%options): Add "recursive" option.
> (guix-import-cran): Handle "recursive" option.
> ---
>  guix/scripts/import/cran.scm | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/guix/scripts/import/cran.scm b/guix/scripts/import/cran.scm
> index ace1123..4cae9da 100644
> --- a/guix/scripts/import/cran.scm
> +++ b/guix/scripts/import/cran.scm
> @@ -63,6 +63,9 @@ Import and convert the CRAN package for PACKAGE-NAME.\n"))
>   (lambda (opt name arg result)
> (alist-cons 'repo (string->symbol arg)
> (alist-delete 'repo result
> + (option '(#\r "recursive") #f #f
> + (lambda (opt name arg result)
> +   (alist-cons 'recursive #t result)))
>   %standard-import-options))
>  
>
> @@ -88,12 +91,23 @@ Import and convert the CRAN package for PACKAGE-NAME.\n"))
> (reverse opts
>  (match args
>((package-name)
> -   (let ((sexp (cran->guix-package package-name
> -   (or (assoc-ref opts 'repo) 'cran
> - (unless sexp
> -   (leave (_ "failed to download description for package '~a'~%")
> -  package-name))
> - sexp))
> +   (if (assoc-ref opts 'recursive)
> +   ;; Recursive import
> +   (map (match-lambda
> +  ((and (label . (('package ('name name) . rest)))
> +(label . (pkg)))
> +   `(define-public ,(string->symbol name)
> +  ,pkg))

Perhaps it could check with ‘find-packages-by-name’ whether NAME already
exists?

> +  (_ #f))
> +(recursive-import package-name
> +  (or (assoc-ref opts 'repo) 'cran)))
> +   ;; Single import
> +   (let ((sexp (cran->guix-package package-name
> +   (or (assoc-ref opts 'repo) 
> 'cran
> + (unless sexp
> +   (leave (_ "failed to download description for package '~a'~%")
> +  package-name))
> + sexp)))

Do you think this could be moved to (guix scripts import)?  We would
have to change other importers to return an empty list/stream of
dependencies for now.

Thanks,
Ludo’.

Re: [PATCH 3/7] import cran: description->package: Also return package dependencies.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * guix/import/cran.scm (description->package): Return package
>   dependencies in addition to generated package expression.

What would you think of making it return a SRFI-41 stream of packages
instead?  Or maybe two values: the package asked for, and the stream
containing its dependencies.  That would hide the package lookup
machinery.

Ludo’.

Re: [PATCH 4/7] import cran: Ignore default R packages.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * guix/import/cran.scm (default-r-packages): New variable.
> (description->package): Drop default R packages from list of inputs.

OK!

Ludo'.

Re: [PATCH 1/7] import cran: Remove more invalid characters from package names.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * guix/import/cran.scm (guix-name): Replace period and underscore with
>   dash; always prepend package names with "r-".

[...]

> +(string-append "r-" (string-downcase
> + (regexp-substitute/global #f "(_|\\.)" name
> +   'pre "-" 'post

I have a preference fro ‘string-map’, which I find more readable than
‘regexp-substitute/global’ in simple cases.  Thoughts?

Otherwise LGTM!

Thanks,
Ludo’.

Re: [PATCH 2/7] import cran: Move guix-name to top-level.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * guix/import/cran.scm (guix-name): Move to top-level.

[...]

> +(define (guix-name name)
> +  "Return a Guix package name for a given R package name."
> +  (string-append "r-" (string-downcase
> +   (regexp-substitute/global #f "(_|\\.)" name
> + 'pre "-" 'post

Same comment as before, but otherwise OK!

Ludo’.

Re: Can we package NetHack?

[Ludovic Courtès]

"Thompson, David"  skribis:

> On Sun, May 29, 2016 at 6:54 PM, Kei Kebreau  wrote:
>> On Mon, 30 May 2016 00:13:00 +0200
>> l...@gnu.org (Ludovic Courtès) wrote:
>>
>>> Kei Kebreau  skribis:
>>>
>>> > NetHack tries to modify its state files in the store and none of its
>>> > easily patchable directory variables allow anything different.
>>> > NetHack also doesn't allow a ~/.nethack directory to be created in
>>> > the user's directory upon running. Does anyone have any ideas or
>>> > other packages that do this sort of thing?
>>>
>>> I suppose the state files are essentially score files?  Don’t other
>>> games store things in /var/lib/something?  What do other distros do?
>>> :-)
>>>
>>> Ludo’.
>>
>> Yes, the state files are high score lists, locks for the world files
>> and such. The problem is that other distros give NetHack a directory to
>> write those files to that would be equivalent to writing to our store.
>> The only one I have seen that avoids this is NixOS. However, NixOS
>> creates a ".nethack" directory within the user's folder (among other
>> things) to work around this.
>>
>> I thought that this would be a problem for Guix, because installing and
>> removing NetHack cleanly would necessitate directly writing to and
>> erasing files within the user's directory. So I decided to mail the
>> list to see if anyone could find a solution. :-)
>
> This isn't a problem.  Stateful files in home directories or elsewhere
> are not managed by Guix.  A .nethack directory sounds like a fine
> solution to me.

Yes, I agree.

Note that this problem is not limited to Nixpkgs and Guix.  So perhaps
there’s also inspiration to be taken from Debian et al.

Ludo’.