[PATCH] emacs: Use space to separate package name and version in heading.

[Alex Kost]

This patch is for displaying "name version" instead of "name@version" in
the heading of *Guix Package Info* buffer.

>From d3cd02351042f8139aeff0302bcb921c8b520716 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Mon, 21 Mar 2016 10:58:29 +0300
Subject: [PATCH] emacs: Use space to separate package name and version in
 heading.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Reported by Ludovic Courtès .

* emacs/guix-ui-package.el (guix-package-name): Check 'spec' property.
(guix-package-info-insert-heading): Use "name version" for button label,
write name specification to 'spec' property.
---
 emacs/guix-ui-package.el | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/emacs/guix-ui-package.el b/emacs/guix-ui-package.el
index 9d81c61..df5f8d1 100644
--- a/emacs/guix-ui-package.el
+++ b/emacs/guix-ui-package.el
@@ -357,7 +357,8 @@ formatted with this string, an action button is inserted.")
 (guix-buffer-get-display-entries-current
  'info guix-package-info-type
  (list (guix-ui-current-profile)
-   'name (button-label btn))
+   'name (or (button-get btn 'spec)
+ (button-label btn)))
  'add)))
 
 (define-button-type 'guix-package-heading
@@ -374,10 +375,12 @@ formatted with this string, an action button is inserted.")
 (message "Yes, this is the source URL. What did you expect?")))
 
 (defun guix-package-info-insert-heading (entry)
-  "Insert package ENTRY heading (name specification) at point."
+  "Insert package ENTRY heading (name and version) at point."
   (guix-insert-button
-   (guix-package-entry->name-specification entry)
-   'guix-package-heading))
+   (concat (guix-entry-value entry 'name) " "
+   (guix-entry-value entry 'version))
+   'guix-package-heading
+   'spec (guix-package-entry->name-specification entry)))
 
 (defun guix-package-info-insert-systems (systems entry)
   "Insert supported package SYSTEMS at point."
-- 
2.6.3

[PATCH] emacs: Fix converting scheme into elisp expression.

[Alex Kost]

There is a bug in "scheme → elisp" conversion in the emacs interface.
It can be seen with the following recipe:

1. M-x guix-licenses

2. Move to "FreeBSD" license and press "i" to describe it.

3. In the *Guix License Info* buffer you can see:

  https://www.gnu.org/licenses/license-listnilreeBSD

while it should be:

  https://www.gnu.org/licenses/license-list#FreeBSD

As you can see, "#F" is replaced with "nil".  The problem is: we receive
a string with scheme expression from geiser, and it should be converted
into elisp expression.  I don't see how to do it other than just to
replace scheme specific things (#t, #f, #) with elisp
analogs in this raw string.

The attached patch improves this conversion process, but it is still
ugly.  Are there better ideas how to perform this conversion?

>From f127fc2ac741334340b650736b98ed15879a3be1 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 24 Jan 2016 11:16:44 +0300
Subject: [PATCH] emacs: Fix converting scheme into elisp expression.

* emacs/guix-geiser.el (guix-geiser-eval-read): Replace #f/#t with nil/t
  only when they follow "(" or " ".
---
 emacs/guix-geiser.el | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/emacs/guix-geiser.el b/emacs/guix-geiser.el
index 0e6cc03..833f5bb 100644
--- a/emacs/guix-geiser.el
+++ b/emacs/guix-geiser.el
@@ -46,11 +46,23 @@ Return a list of strings with result values of evaluation."
 (defun guix-geiser-eval-read (str &optional repl)
   "Evaluate STR with guile expression using Geiser REPL.
 Return elisp expression of the first result value of evaluation."
-  ;; Parsing scheme code with elisp `read' is probably not the best idea.
-  (read (replace-regexp-in-string
- "#f\\|#" "nil"
- (replace-regexp-in-string
-  "#t" "t" (car (guix-geiser-eval str repl))
+  ;; The goal is to convert a string with scheme expression into elisp
+  ;; expression.
+  (let ((result (car (guix-geiser-eval str repl
+(cond
+ ((or (string= result "#f")
+  (string= result "#"))
+  nil)
+ ((string= result "#t")
+  t)
+ (t
+  (read (replace-regexp-in-string
+ "[ (]\\(#f\\)" "nil"
+ (replace-regexp-in-string
+  "[ (]\\(#t\\)" "t"
+  result
+  nil nil 1)
+ nil nil 1))
 
 (defun guix-repl-send (cmd &optional save-history)
   "Send CMD input string to the current REPL buffer.
-- 
2.6.3

Re: [PATCH 4/6] gnu: python-llfuse: Update to 1.0, keep 0.41 variant.

[Alex Kost]

Leo Famulari (2016-03-21 05:49 +0300) wrote:

> On Tue, Mar 15, 2016 at 05:25:58PM +0100, Ludovic Courtès wrote:
[...]
>> Furthermore ‘@’ (at sign) has a special meaning in Guile (info "(guile)
>> Using Guile Modules"), so even though it’s currently valid within an
>> identifier, I’d suggest avoiding it.
>
> Thanks for the explanation everybody!
>
> I've made all the requested changes. Any more comments on this patch
> series?

I don't have more comments :-)

-- 
Alex

Re: [PATCH] Update .mailmap.

[Alex Kost]

Nils Gillmann (2016-03-20 15:17 +0300) wrote:

> It's okay for me.
>
> I think .mailmap is only for mail, so my old contribution name
> will only be fixed once someone applies the gnunet.scm patch and
> others where it might still occur.

You will fix your name in gnunet.scm some day¹, right?  If you are not
going to modify gnunet.scm, we can fix it right now.

.mailmap is not for mail.  It is used by "git shortlog" (see "man
git-shortlog"), and as I wrote, we use this output to generate AUTHORS
file in a release tarball, so keeping this output clean is important.

¹ http://lists.gnu.org/archive/html/guix-devel/2016-02/msg00506.html

-- 
Alex

Re: [GSoC] Draft of my proposition

[Ludovic Courtès]

Hello!

 skribis:

> The admission for Google's Summer of Code have started and I want to spend 
> the summer working on Guix. I have a proposition I hope you will find 
> interesting! I have joined the draft to this e-mail.

Thanks for your proposal!

Preliminary question: could you resend it as plain text or Org-mode to
simply the life of people on this list?

Thanks in advance,  :-)
Ludo’.

Re: [PATCH] emacs: Use space to separate package name and version in heading.

[Ludovic Courtès]

Alex Kost  skribis:

> From d3cd02351042f8139aeff0302bcb921c8b520716 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Mon, 21 Mar 2016 10:58:29 +0300
> Subject: [PATCH] emacs: Use space to separate package name and version in
>  heading.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Reported by Ludovic Courtès .
>
> * emacs/guix-ui-package.el (guix-package-name): Check 'spec' property.
> (guix-package-info-insert-heading): Use "name version" for button label,
> write name specification to 'spec' property.

Sure, go ahead!

Thank you,
Ludo'.

Re: [PATCH] emacs: Fix converting scheme into elisp expression.

[Ludovic Courtès]

Alex Kost  skribis:

> As you can see, "#F" is replaced with "nil".  The problem is: we receive
> a string with scheme expression from geiser, and it should be converted
> into elisp expression.  I don't see how to do it other than just to
> replace scheme specific things (#t, #f, #) with elisp
> analogs in this raw string.
>
> The attached patch improves this conversion process, but it is still
> ugly.  Are there better ideas how to perform this conversion?

The ideal solution would be to have a full-blown Scheme reader in elisp
(trivial in Guile-Emacs…).  Otherwise I’m not sure what can be done.

> From f127fc2ac741334340b650736b98ed15879a3be1 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sun, 24 Jan 2016 11:16:44 +0300
> Subject: [PATCH] emacs: Fix converting scheme into elisp expression.
>
> * emacs/guix-geiser.el (guix-geiser-eval-read): Replace #f/#t with nil/t
>   only when they follow "(" or " ".

Looks good, thanks!

Ludo’.

Re: [PATCH 0/1] Enabling header caching in mutt

[Efraim Flashner]

On Sun, Mar 20, 2016 at 10:47:04PM -0400, Leo Famulari wrote:
> This patch builds mutt with support for header caching so that large
> mailboxes can be opened quickly.
> 
> Without the header cache, each message's headers are processed before
> the mailbox can be used. For large mailboxes (>1 messages), this can
> take minutes.
> 
> To use the header cache, users must enable it in their configuration.
> 
> It's following up on this:
> http://lists.gnu.org/archive/html/help-guix/2016-03/msg00055.html
> 
> I checked, and bdb and gdbm are already both in mutt's build-time
> dependency graph (openldap refers to bdb and python refers to gdbm).
> 
> I've chosen gdbm for it's small size and because it's a GNU project. If
> anyone says they prefer another database, then let's talk!
> 

I've just tried this out on my machine. At first I didn't see any
change, but then I added `set header_cache = ~/.cache/mutt/` to my
.muttrc and I was blown away by the difference.

-- 
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] Add the clBLAS (OpenCL accelerated BLAS library) to GNU Guix

[Ricardo Wurmus]

Hi Dennis,

> This patch adds the clBLAS package to GNU Guix.

thank you for your patches!

Here a couple of comments:

* We usually require one patch per package.  Your patch adds three
  packages.

* The module is named “(gn packages clBLAS)”.  Packages should go to
  “(gnu packages ...)”.  Also, all module names are to be lowercase,
  i.e. “clblas” rather than “clBLAS”.  That said, it may be better to
  not create a new module but add the packages to existing modules such
  as “maths.scm”.

* Please keep the length of lines below 80 characters.

* Please run “guix lint” on your new packages for helpful hints.


> +(define-public clBLAS

Variable names should be lowercase.

> +  (package
> +(name "clBLAS")
> +(version "v2.10")

The “v” should not be part of the version number.

> +(source (origin
> + (method url-fetch)
> + (uri (string-append 
> "https://github.com/clMathLibraries/clBLAS/archive/";
> + version ".tar.gz"))

Since the tarball does not contain the name of the package, please add a
“(file-name ...)” expression.  You can grep the “gnu/packages/”
directory for examples on how to use it.

> + (sha256
> +  (base32
> +   "0adlb02lqzrklfybhnv4n0p37mvkvdi3vqiwa05x2mv05ywnr93j"
> +(build-system cmake-build-system)
> +(arguments `(#:tests? #f

Why are tests disabled?  If there are no tests we usually just add a
comment saying so.

> + #:configure-flags '("../clBLAS-2.10/src"
> "-DBUILD_SHARED_LIBS=ON" "-DCMAKE_BUILD_TYPE=Release"
> "-DBUILD_TEST=OFF")))

“CMAKE_BUILD_TYPE=Release” does not need to be set.  Why are the other
arguments needed?  In particular, why do you pass “../clBLAS-2.10/src”?

> +(native-inputs `(("autoconf" ,autoconf)

This should be on a new line.

> +("automake" ,automake)

Why do you need autoconf and automake when this package uses cmake?

> +("cmake" ,cmake)
> +("gfortran" ,gfortran)
> +("libtool" ,libtool)
> +("pkg-config" ,pkg-config)))
> +(inputs `(("curl" ,curl)

This should be on a new line.

> +   ("dbus" ,dbus)
> +   ("boost" ,boost)
> +   ("enca" ,enca)
> +   ("eudev" ,eudev)
> +   ("fftw-openmpi" ,fftw-openmpi)
> +   ("glew" ,glew)   
> +   ("libcap" ,libcap)
> +   ("libjpeg" ,libjpeg)
> +   ("libltdl" ,libltdl)
> +   ("libtiff" ,libtiff)
> +   ("mesa-utils" ,mesa-utils)
> +   ("openmpi" ,openmpi)
> +   ("ocl-icd" ,ocl-icd)
> +   ("opencl-headers" ,opencl-headers)
> +   ("randrproto" ,randrproto)
> +   ("libxrandr" ,libxrandr)
> +   ("xineramaproto" ,xineramaproto)
> +   ("libxinerama" ,libxinerama)
> +   ("libxcursor" ,libxcursor)
> +   ("python" ,python-2)))   
> +(home-page "http://www.glfw.org/";)
> +(synopsis "glfw is an Open Source, multi-platform library for creating 
> windows with OpenGL contexts and receiving input and events.")

We usually don’t say “Open Source” (or “free”) because all software in
Guix is Free Software.  A synopsis should not be a full sentence.  It
should be short enough not to require line breaks.

> +(description "glfw is an Open Source, multi-platform library for 
> creating windows with OpenGL contexts and receiving input and events.")

Please break lines.  In Emacs you can format the paragraph with M-q.

> +(license (list license:gpl2

No list needed when it’s just one license.  Are you sure it’s GPLv2 only?

> +(define-public ocl-icd
> +  (package
> +   (name "ocl-icd")
> +   (version "2.2.9")
> +   (source (origin
> + (method url-fetch)
> + (uri (string-append 
> "https://forge.imag.fr/frs/download.php/716/ocl-icd-";
> + version ".tar.gz"))
> + (file-name (string-append name "-" version ".tar.gz"))

This is not required here because the tarball already contains package
name and version.

> + (sha256
> +  (base32
> +   "1rgaixwnxmrq2aq4kcdvs0yx7i6krakarya9vqs7qwsv5hzc32hc"
> +(inputs `(("zip" ,zip)

It looks nicer to have the zip pair on the next line.
The list of inputs is usually placed below the build-system and
arguments fields.

> + ("autoconf" ,autoconf)
> + ("automake" ,automake)

These are probably native inputs only.

> + ("ruby" ,ruby)
> + ("libtool" ,libtool)
> + ("opencl-headers" ,opencl-headers)
> + ("libgcrypt" ,libgcrypt)))  
> 
> +(build-system gnu-build-system)
> + (arguments

The indentation here looks wrong.

> + '(#:phases (modify-phases %standard-phases
> +(add-after 'unpack `bootstrap
> +  (lambda _
> +(zero? (system* "autoreconf" "-vfi")))

Is bootstrapping really required?  Is there a release that doesn’t
require it?

Re: [PATCH] Add the clFFT (OpenCL accelerated FFT library) package to GNU Guix

[Ricardo Wurmus]

Dennis Mungai  writes:

> This patch adds the clFFT library to GNU Guix.

Thanks!

My comments about your patches for clBLAS largely also apply to this
patch.  Additional comments follow.


> From 6ebec56462308cb83290d4fa4b47be07a5480674 Mon Sep 17 00:00:00 2001
> From: Dennis Mungai 
> Date: Sun, 20 Mar 2016 04:50:31 +0300
> Subject: [PATCH] Ported the clFFT package to GNU Guix

> ---
>  clFFT.scm | 158 
> ++
>  1 file changed, 158 insertions(+)
>  create mode 100644 clFFT.scm

For commit summaries and messages we use a variant of the ChangeLog
format.  Assuming only the addition of a “clfft” package to “maths.scm”
the commit message would look like this:

gnu: Add clFFT.

* gnu/packages/maths.scm (clfft): New variable.

> +(define-public clFFT
> +  (package
> +(name "clFFT")
> +(version "v2.10.1")
> +(source (origin
> + (method url-fetch)
> + (uri (string-append 
> "https://github.com/clMathLibraries/clFFT/archive/";
> + version ".tar.gz"))
> + (sha256
> +  (base32
> +   "19hrk1lf06kch8x9dpbdj0waycn2mldrmj2y4vzi7zn2gdfw6g73"
> +(build-system cmake-build-system)
> +(arguments `(#:configure-flags '("../clFFT-2.10.1/src" 
> "-DBUILD_SHARED_LIBS=ON" "-DCMAKE_BUILD_TYPE=Release") #:tests? #f))
> +(native-inputs `(("autoconf" ,autoconf)
> +("automake" ,automake)
> +("cmake" ,cmake)
> +("libtool" ,libtool)
> +("pkg-config" ,pkg-config)))
> +(inputs `(("curl" ,curl)
> +   ("dbus" ,dbus)
> +   ("enca" ,enca)
> +   ("eudev" ,eudev)
> +   ("fftw-openmpi" ,fftw-openmpi)
> +   ("glew" ,glew)
> +   ("libcap" ,libcap)
> +   ("libjpeg" ,libjpeg)
> +   ("libltdl" ,libltdl)
> +   ("libtiff" ,libtiff)
> +   ("mesa-utils" ,mesa-utils)
> +   ("openmpi" ,openmpi)
> +   ("ocl-icd" ,ocl-icd)
> +   ("opencl-headers" ,opencl-headers)
> +   ("randrproto" ,randrproto)
> +   ("libxrandr" ,libxrandr)
> +   ("xineramaproto" ,xineramaproto)
> +   ("libxinerama" ,libxinerama)
> +   ("libxcursor" ,libxcursor)
> +   ("python" ,python-2)))   
> +(home-page "http://www.glfw.org/";)
> +(synopsis "glfw is an Open Source, multi-platform library for creating 
> windows with OpenGL contexts and receiving input and events.")
> +(description "glfw is an Open Source, multi-platform library for 
> creating windows with OpenGL contexts and receiving input and events.")

This whole package expression looks a lot like the one for clBLAS.  Even
the synopsis and the description are the same.  Surely, that’s a
mistake.

> +(define-public ocl-icd
> +(define-public opencl-headers

Haven’t you added these two with your previous patch already?

~~ Ricardo

Re: [PATCH] Add fyba to GNU Guix

[Ricardo Wurmus]

Hi Dennis,

> This patch adds Fyba, a library required by GDAL to process Norwegian
> statistical datums, to GNU Guix.

Thanks for your patch!

> From the package description:
>
> FYBA is the source code release of the FYBA library, distributed by
> the National Mapping Authority of Norway (Kartverket) to read and
> write files in the National geodata standard format SOSI.

This is a much better description than the one you chose to use for the
package below.


> From 5212e686078f73211182a4fe52d81529faccefba Mon Sep 17 00:00:00 2001
> From: Dennis Mungai 
> Date: Sun, 20 Mar 2016 04:48:27 +0300
> Subject: [PATCH] Ported the fyba package to GNU Guix

Please see my comments on commit messages earlier.

> +(define-module (gn packages fyba)

Is it really necessary to create a new module?  Could this package be
added to an existing module instead?  Also, our modules are called “gnu
packages ...” not “gn packages ...”.

> +(define-public fyba
> +  (package
> +   (name "fyba")
> +   (version "4.1.1")
> +   (source (origin
> + (method url-fetch)
> + (uri (string-append 
> "https://github.com/kartverket/fyba/archive/";
> + version ".tar.gz"))
> + (file-name (string-append name "-" version ".tar.gz"))
> + (sha256
> +  (base32
> +   "0ya1agi78d386skq353dk400fl11q6whfqmv31qrkn4g5vamixlr"

OK.  Have you checked that there is no other release tarball?

> +(inputs `(("zip" ,zip)
> + ("autoconf" ,autoconf)
> + ("automake" ,automake)
> + ("libtool" ,libtool)
> + ("libgcrypt" ,libgcrypt)))  
> 

Most packages place the “inputs” field after “arguments”.  I think its
better to do the same.

Most of these, however, look like they should be “native-inputs”.

Are the autotools really required?  Or is there a bootstrapped release
tarball somewhere that we could use instead?

> +(build-system gnu-build-system)
> + (arguments
> + '(#:phases (modify-phases %standard-phases
> +(add-after 'unpack `bootstrap
> +  (lambda _
> +(zero? (system* "autoreconf" "-vfi")))
> +(home-page "http://labs.kartverket.no/sos/";)
> +(synopsis "source code release of the FYBA library")

This is not a helpful synopsis.  It should tell me succintly what this
library does, not that this is a release.

> +(description "OpenFYBA is the source code release of the FYBA library.")

Is it OpenFYBA or just FYBA?  What is the FYBA library?  Your
explanation in the email is a lot better than this.

> +(license (list gpl2

No “list” required when you only have one license.  Is this really just
“GPLv2 only” or “GPLv2 or later”?

Could you please resend this patch after addressing these comments and
running “guix lint fyba”?

Thanks again!

~~ Ricardo

Re: [PATCH] Add glfw to GNU Guix

[Ricardo Wurmus]

Hi Dennis,

> The patch attached adds glfw to the list of packages in GNU Guix.
>
> This definitely goes under gl.scm

Your patch doesn’t add it to “gl.scm”.  Could you please resend a patch
that adds “glfw” to the “gl” module instead of creating a new module?

Thanks!

~~ Ricardo

Re: [PATCH] Add ocl-icd to GNU Guix

[Ricardo Wurmus]

Hi Dennis,

> The attached patch adds ocl-icd (An OpenCL ICD Loader) to GNU Guix.

Thanks!

I’m confused about this, because I just reviewed two other patches from
you that also contained definitions for “ocl-icd” and “opencl-headers”.
Which of these is the latest version?

It would be helpful if you created one patch per package only.

~~ Ricardo

Re: [PATCH] Add ocl-icd to GNU Guix

[Dennis Mungai]

Hello Ricardo,

Thanks for your valuable input.

I'll address the issues raised and re-submit the patches to the stated standard.

Regards,

Dennis.

On 21 March 2016 at 13:56, Ricardo Wurmus  wrote:
>
> Hi Dennis,
>
>> The attached patch adds ocl-icd (An OpenCL ICD Loader) to GNU Guix.
>
> Thanks!
>
> I’m confused about this, because I just reviewed two other patches from
> you that also contained definitions for “ocl-icd” and “opencl-headers”.
> Which of these is the latest version?
>
> It would be helpful if you created one patch per package only.
>
> ~~ Ricardo

[GSoC] Porting GuixSD to GNU Hurd draft

[Manolis Ragkousis]

Hello everyone,

Although I have uploaded and shared my draft to the GSoC website, I am
also resending it to the lists as per Ludovic's instruction.

I am sharing it as a txt + pdf.

Here is also the link that I shared to the GSoC website as per Google's
instructions.
https://docs.google.com/document/d/1NEEz_PHM2YZTm8okd2BgPRSc4c89I1fGnwbyeeEUrhw/edit?usp=sharing

This is the time to share your ideas/corrections :-)

Manolis
Porting GuixSD to GNU/Hurd

Manolis Ragkousis
manolis...@gmail.com

March 17, 2016


1. Summary

In this project, we would like to port the Guix Software Distribution to GNU 
Hurd.  By the end of the project, 
Guix will be able to handle and use the available Hurd mechanisms, have the 
required tools to produce a working, 
bootable, system vm/image with GNU Shepherd as the init daemon and offer the 
same functionality as you would 
expect from booting into a GNU/Linux GuixSD system. 


2. The Project

The project consists of four main stages

1. Modify Guix so it will be able to create and mount the file-system needed to 
boot into a system with Hurd at its core. 
2. Modify Guix so it can produce a working image, while isolating any cases of 
Linux assumptions.
3. Successfully boot into one such system using GNU Shepherd with pid 1.
4. Modify the new Guix system to take advantage of Hurd specific mechanisms.


Currently the tools Guix uses to interact with the filesystem exist inside the 
(guix build syscalls) module. 
This module provides bindings to libc's syscall wrappers, which are only 
available on a GNU/Linux system. 
In order to offer the same functionality on a GNU/Hurd system we must first 
write Guile bindings for the 
relevant Hurd functions, like 'file_set_translator' in hurd/fs.defs for 
example. This module will be called 
(guix build hurd). This allows us to re-implement the functionality of the 
'settrans' command, as described 
here[1], in Scheme and use that in place of 'mount()', where applicable.

Additionally, we need to make sure that all modules in (guix build *) and (gnu 
build *) can offer the same 
functionalities on a GNU/Hurd system.  For example (gnu build vm) relies on 
QEMU's '-kernel' command-line 
option, which is Linux-specific.  On the other hand, in the case of modules 
like (gnu build linux-boot) or 
(gnu build linux-initrd), which by design are Linux-specific, we will need to 
provide a separate module with 
equivalent functionality. (gnu system *) modules will require changes as well, 
in order to be able to use 
modifications that will happen in the (guix build *) and (gnu build *) modules. 

At this point we will be able to generate a working vm image and boot into it.  
Guix will be able to use the 
Hurd servers (i.e. /hurd/init) to start the init manager and the system itself. 
 We will also have to account 
for the fact that servers in /hurd will be symlinks to /gnu/store/*, and modify 
Guix and/or the Hurd libraries 
accordingly to achieve functionality.  Regarding the init daemon, please note 
that a precedent already exists 
for starting GuixSD/Hurd with GNU Shepherd as pid 1 (David Michael [2015][2]).

Finally, once GuixSD is successfully ported, we can cater to the last stage of 
taking advantage of Hurd specific 
mechanisms. 
This includes but is not limited to:
1)Replacing (gnu build linux-container) with (gnu build subhurd) when on a 
GNU/Hurd system. Subhurds can offer 
isolation similar to Linux containers as described here[3].
2)Modify the guix-daemon to run without root privileges by utilizing the Hurd 
architecture. The daemon needs root 
privileges in order to setup chrooted environments for the builds.  In the Hurd 
this can be done by setting up a 
translator as described here[4]. 
3)Guix uses symlink trees for user profiles. Instead we can use stowfs[5]. 
Stowfs creates a traditional Unix directory 
structure from all the files in the individual package directories.

 
3. Estimated Project Timeline

Before March 31
Finish merging the wip-hurd branch to upstream.
Write a (guix build hurd) module which will contain Guile bindings to the RPC 
stubs like hurd/fs.defs or hurd/exec.defs .

April 1 - April 15
Package missing dependencies (Hurd libs).
Re-implement 'settrans' in scheme.

April 16 - May 1
At this point we will have the tools needed to build a Hurd based file-system. 
(Milestone 1)
Start working on getting (guix build *) and (gnu build *) modules to work on 
Hurd.
Make sure '%base-packages' in (gnu system) module work as expected on Hurd.

May 2 - May 22
Create (gnu build hurd-boot) and (gnu build hurd-initrd).
Start working on describing the GNU/Hurd system in (gnu system).

May 23 - 12 June
Modify (gnu system *) modules as needed.
All the modules (guix build *) and (gnu build *) will be working as expected by 
now.
Try building a GuixSD image. (Milestone 2)

13 June - 23 June
Solve any problems with booting into the system and running GNU Shepherd.

24 June - 9 July
Have a fully working GNU/Hurd system. (Milestone 3)

[GSoC] Bourne-shell compiler front-end for Guile

[Efraim Flashner]

I'm a student still this year and Guix is the only project I'm considering.

If there's anything I can do/change to make it more clear or thorough I'd
love to have some feedback.

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

Efraim Flashner
efr...@flashner.co.il

Who am I?

My name is Efraim, I’m currently living in Jerusalem, Israel. I’m a 3rd 
year Computer Science student at the Jerusalem College of Technology (Israel 
has the college/university split). One of my classes was on functional 
programming, where we covered prolog and lisp. I found the idea of functional 
programming interesting, and at the time even tried writing small programs 
using them.

I switched full-time to Linux in 2010, trying out Ubuntu and then switching to 
Debian, and currently I’m waiting on a blob-free wireless mini-pcie/usb 
before switching my laptop over to GuixSD. I haven’t had a lot of opportunity 
in Israel to meet up with Free Software or Linux people, and I’ve worked hard 
to make up for that by reading lots of online tutorials and experimenting on my 
machines. I first discovered Guix around June of last year and got involved 
shortly after.

The Plan:

As it currently stands, looking in gnu/packages/bootstrap/$ARCH/, in addition 
to guile there’s bash, mkdir, tar and xz. From the manual we have the 
bootstrapping methodology 
(https://www.gnu.org/software/guix/manual/html_node/Bootstrapping.html) which 
also uses gcc, binutils, coreutils, libc, etc. We also have 
guix/build/bournish.scm to act as a rescue-shell of sorts and in use in the 
initrd.

By extending/building upon bournish we can lessen the number of bootstrap 
binaries that we need to bootstrap a working system AND we get a more powerful 
shell to use when something™ happens during boot and we’re dropped down to 
a rescue shell.

Currently the idea on the GSoC idea wiki is to extend bournish so that it can 
cover everything needed by a configure script. This would of course allow us to 
decrease the number of binaries we need to get started. Looking at the list of 
bootstrap binaries, I’m most interested in including enough functionality to 
remove our dependance on bash which to me seems like a good security idea, as 
surely we wouldn’t want to have a vulnerability found for our bootstrap 
version of bash.

The Plan, Part 2:

From now until the start of GSoC I’d work on bettering my knowledge of guile 
and more closely analyzing the bootstrap process. I’ve had a look at 
Wikipedia’s entry on Unix shells and I’ll be grabbing the source of a few 
of them, including ash, scsh and busybox, for inspiration.

For the coding I plan on implementing the different features that we’d need 
for replacing a number of the bootstrap binaries. As a stretch-goal I’d like 
to see if it is possible to switch to using it as my user shell in place of 
bash. Part of this would of course come with deciding on how to use it to 
replace bootstrap binaries; whether to have additional binary outputs for the 
different binaries being replaced or to have one monolithic binary.


GSoC_proposal_Efraim_Flashner.pdf
Description: Adobe PDF document


pgpC2lPZ2bTba.pgp
Description: OpenPGP digital signature

Re: [PATCH] Update .mailmap.

[Nils Gillmann]

Alex Kost  writes:

> Nils Gillmann (2016-03-20 15:17 +0300) wrote:
>
>> It's okay for me.
>>
>> I think .mailmap is only for mail, so my old contribution name
>> will only be fixed once someone applies the gnunet.scm patch and
>> others where it might still occur.
>
> You will fix your name in gnunet.scm some day¹, right?  If you are not
> going to modify gnunet.scm, we can fix it right now.

Yes, see also the pending to be retested or whatever by someone
with commit access patch for the gnunet.scm, thread here:
http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00464.html

> .mailmap is not for mail.  It is used by "git shortlog" (see "man
> git-shortlog"), and as I wrote, we use this output to generate AUTHORS
> file in a release tarball, so keeping this output clean is
> important.

I understood that, my reply was a bit too short to transport that
I did so.

>
> ¹ http://lists.gnu.org/archive/html/guix-devel/2016-02/msg00506.html


-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

[PATCH] Fix gfortran (?)

[Ricardo Wurmus]

Hi Guix,

with this patch applied I can build randomjungle without having to add
the “lib” output of gfortran to the package inputs.

This is related to the changes I pushed in commit 82f145e to fix
bug#19733, which seems to have broken the build of randomjungle and
slepc, among others.

Is this acceptable?  Should we do this for all gfortran variants then?

~~ Ricardo

>From f3d97b7f1f2b597f7f74b2f59212f241a87fa602 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Mon, 21 Mar 2016 14:09:45 +0100
Subject: [PATCH] gnu: gfortran: Disable separate "lib" output.

* gnu/packages/gcc.scm (gfortran): Disable separate "lib" output.
---
 gnu/packages/gcc.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 1df5150..341c30c 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -474,7 +474,8 @@ as the 'native-search-paths' field."
 
 (define-public gfortran
   (custom-gcc gcc "gfortran" '("fortran")
-  %generic-search-paths))
+  %generic-search-paths
+  #:separate-lib-output? #f))
 
 (define-public gfortran-5
   (custom-gcc gcc-5 "gfortran" '("fortran")
-- 
2.1.0

Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

First follow up idea:

Ideal case would be:
 - integration with Guix in the future (the emacs interface and
   other potential future interfaces)
 - integration into Guix website
 - patches can be marked:
   - state (done/open)
   - priority
 - patches can be assigned to more than 1 person
 - webinterface

As we are not at the ideal case and need a software until we get
there, most projects seem to either use mailman, bugzilla,
something equal to prmon.freebsd.org (ports monitor), simple pull
requests on a mirror on a bigger source control system.


what are your thoughts?
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

Re: [REQ/DISCUSSION] patch managing system

[Ricardo Wurmus]

Nils Gillmann  writes:

> First follow up idea:
>
> Ideal case would be:
>  - integration with Guix in the future (the emacs interface and
>other potential future interfaces)
>  - integration into Guix website
>  - patches can be marked:
>- state (done/open)
>- priority
>  - patches can be assigned to more than 1 person
>  - webinterface
>
> As we are not at the ideal case and need a software until we get
> there, most projects seem to either use mailman, bugzilla,
> something equal to prmon.freebsd.org (ports monitor), simple pull
> requests on a mirror on a bigger source control system.

I have a very strong aversion to bugzilla and other complicated tracking
systems.  All of the above points are covered by debbugs, which we
already use for bug tracking.

debbugs has an Emacs interface as well as a read-only web interface.

I must admit that I’m not using debbugs regularly for our bug tracker
because I’m not working on bugs very often.  If we really wanted to
track progress on patches we could be using debbugs, but I don’t
actually think it would improve the situation much.

Right now I’m capturing guix-devel emails that I want to look at later
with Org capture, or I simply leave them in an unread state.  The
problem, in my opinion, is not so much keeping track of patches, but
taking the time to review and engage in discussions.  I cannot review as
much as I would like to and for follow up discussions I often miss time
(in front of the computer, and in a reasonably awake state).

I don’t think it’s a software problem, but a people problem.  To deal
with more patches we need more people reviewing patches.  We already
have “guix lint” to point out common problems.  We probably should add a
little helper script for all non-Emacsers that runs Emacs over the
expression to check the indentation.  But other than that I’d just say:
resend a patch if you haven’t received any response within five days or
so.

~~ Ricardo

Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

Ricardo Wurmus  writes:

> Nils Gillmann  writes:
>
>> First follow up idea:
>>
>> Ideal case would be:
>>  - integration with Guix in the future (the emacs interface and
>>other potential future interfaces)
>>  - integration into Guix website
>>  - patches can be marked:
>>- state (done/open)
>>- priority
>>  - patches can be assigned to more than 1 person
>>  - webinterface
>>
>> As we are not at the ideal case and need a software until we get
>> there, most projects seem to either use mailman, bugzilla,
>> something equal to prmon.freebsd.org (ports monitor), simple pull
>> requests on a mirror on a bigger source control system.
>
> I have a very strong aversion to bugzilla and other complicated tracking
> systems.  All of the above points are covered by debbugs, which we
> already use for bug tracking.

That's right, rain1 pointed this out to me in irc some moments ago.

> debbugs has an Emacs interface as well as a read-only web interface.
>
> I must admit that I’m not using debbugs regularly for our bug tracker
> because I’m not working on bugs very often.  If we really wanted to
> track progress on patches we could be using debbugs, but I don’t
> actually think it would improve the situation much.
>
> Right now I’m capturing guix-devel emails that I want to look at later
> with Org capture, or I simply leave them in an unread state.  The
> problem, in my opinion, is not so much keeping track of patches, but
> taking the time to review and engage in discussions.  I cannot review as
> much as I would like to and for follow up discussions I often miss time
> (in front of the computer, and in a reasonably awake state).

Would it make sense to have a patches-only list or at least a
separation between [general not-patch-related disussions,
questions, pre-bug report questions] and [patches and their
discussions]?
This would not fix the people and times situation
but eventually prevent situations in the future where we only
have -devel for discussions, questions, patches, pre-bug
questions, and with a growing number of participants more
reviewers might come, but also more questions and other non-patch
related input on the list, making it /maybe/ difficult to
follow.
I think it's better to think ahead and solve problems
before they become problems, but maybe this is too soon.

(sidenote:
I envision something for much later which I will discuss in
another project and see if it fits into what we (in that project)
focus on, maybe in a couple of years it could be useful.)

> I don’t think it’s a software problem, but a people problem.  To deal
> with more patches we need more people reviewing patches.  We already
> have “guix lint” to point out common problems.  We probably should add a
> little helper script for all non-Emacsers that runs Emacs over the
> expression to check the indentation.  But other than that I’d just say:
>
> resend a patch if you haven’t received any response within five days or
> so.

>From my perspective, resending does not really help either. It
fills up the mailinglist with duplicates and unless I mention
which of these threads can be considered closed, any version
could be seen as the patch and it only works around the problem
you mentioned and I see - too little people to review and apply
patches.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

Re: [PATCH 1/2] gnu: Add freealut.

[Ricardo Wurmus]

Hi David,

thank you for the patch!

> * gnu/packages/audio.scm (freealut): New variable.
> ---

[...]

>  
> +(define-public freealut
> +  (package
> +(name "freealut")
> +(version "1.1.0")
> +(source (origin
> +  (method git-fetch)
> +  (uri (git-reference
> +;; The official repository is defunct. This is the most
> +;; popular mirror.
> +(url (string-append "https://github.com/vancegroup/"; 
> name))
> +(commit version)))

I see that Arch and Fedora both use the tarball from here:


http://pkgs.fedoraproject.org/repo/pkgs/freealut/freealut-1.1.0.tar.gz/e089b28a0267faabdb6c079ee173664a/freealut-1.1.0.tar.gz

The advantage of that tarball is that it doesn’t require bootstrapping,
so you can do without the additional “autogen” phase and without the
three native inputs.

> +(home-page "http://www.openal.org/";)

Does Freealut itself have a home page?  It doesn’t seem right to me to
declare the website of OpenAL as the home page, when the package is
really just one implemenatation of the standard published on the OpenAL
website.

> +(synopsis "OpenAL Utility Tool")

Is it a library or a tool (or both)?  What does it do?

> +(description "Freealut is a free implementation of OpenAL's ALUT
> +standard.")

Could you try to extend the description a little?  I don’t know what
this really means.

~~ Ricardo

Re: [PATCH] Add ustr.

[Ricardo Wurmus]

Leo Famulari  writes:

> On Thu, Mar 17, 2016 at 01:13:33PM +0100, Ricardo Wurmus wrote:
>> * gnu/packages/textutils.scm (ustr): New variable.
>
> [...]
>
>> +  (uri (string-append "http://www.and.org/ustr/"; version
>> +  "/ustr-" version ".tar.bz2"))

[...]

> It looks like this directory only contains the current version of the
> code, but I can't find an archive of old releases. How about mentioning
> this in a comment, and (maybe) asking and.org to provide an archive?

Actually, there are older versions as well.  Version 1.0.2, for example,
is at

http://www.and.org/ustr/1.0.2/ustr-1.0.2.tar.bz2

>> +(build-system gnu-build-system)
>> +(arguments
>> + `(#:make-flags
>> +   (list "CC=gcc"
>> + "HIDE="
>
> I read the Makefile's comment about this. ;)

I guess we don’t qualify as “all sane people” :)

>> + "LDCONFIG=echo"
>
> Can you explain this one in a comment?

Will do.

>> + (string-append "prefix=" (assoc-ref %outputs "out"))
>> + "all-shared")
>
> [...]
>
>> +;; Quoted from the home page: "The License for the code is MIT, new-BSD,
>> +;; LGPL, etc. ... if you need another license to help compatibility, 
>> just
>> +;; ask for it.  It's basically public domain, without all the legal
>> +;; problems for everyone that trying to make something public domain
>> +;; entails."
>> +(license license:public-domain)))
>
> Sounds good to me. Hopefully there are no objections from the legal
> experts!

Thanks for taking the time to review!  I’ll push this after adding the
comment.

~~ Ricardo

[PATCH] Update Artanis.

[Ricardo Wurmus]

This patch updates GNU Artanis to the latest version.  I also needed to
set DESTDIR because the build system installs some files to
“$DESTDIR/etc/”.

~~ Ricardo

>From dd6f844687c44ff95a8f59ab047891e88e2f35b7 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Mon, 21 Mar 2016 15:56:00 +0100
Subject: [PATCH] gnu: artanis: Update to 0.1.2.

* gnu/packages/guile.scm (artanis): Update to 0.1.2.
[arguments]: Set DESTDIR.
---
 gnu/packages/guile.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 882a62d..fe043cb 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -275,14 +275,14 @@ without requiring the source code to be rewritten.")
 (define-public artanis
   (package
 (name "artanis")
-(version "0.1.0")
+(version "0.1.2")
 (source (origin
   (method url-fetch)
   (uri (string-append "ftp://alpha.gnu.org/gnu/artanis/artanis-";
   version ".tar.gz"))
   (sha256
(base32
-"1mc2zy6n9wnn4hzi3zp3jd6b5rlr0lv7fvh800xf4fyrxg0zia4g"
+"19m3ak12cqk8js9d2mdg11kh4fjsq8frfpd10qw75h0zpr5cywpp"
 (build-system gnu-build-system)
 ;; TODO: Add guile-dbi and guile-dbd optional dependencies.
 (inputs `(("guile" ,guile-2.0)))
@@ -296,7 +296,8 @@ without requiring the source code to be rewritten.")
   (dir (string-append out "/share/guile/site/2.0")))
  ;; Don't use (%site-dir) for site paths.
  (list (string-append "MOD_PATH=" dir)
-   (string-append "MOD_COMPILED_PATH=" dir)))
+   (string-append "MOD_COMPILED_PATH=" dir)
+   (string-append "DESTDIR=" out)))
#:test-target "test"
#:phases
(modify-phases %standard-phases
-- 
2.1.0

Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

Nils Gillmann  writes:

> Ricardo Wurmus  writes:
>
>> Nils Gillmann  writes:
>>
>>> First follow up idea:
>>>
>>> Ideal case would be:
>>>  - integration with Guix in the future (the emacs interface and
>>>other potential future interfaces)
>>>  - integration into Guix website
>>>  - patches can be marked:
>>>- state (done/open)
>>>- priority
>>>  - patches can be assigned to more than 1 person
>>>  - webinterface
>>>
>>> As we are not at the ideal case and need a software until we get
>>> there, most projects seem to either use mailman, bugzilla,
>>> something equal to prmon.freebsd.org (ports monitor), simple pull
>>> requests on a mirror on a bigger source control system.
>>
>> I have a very strong aversion to bugzilla and other complicated tracking
>> systems.  All of the above points are covered by debbugs, which we
>> already use for bug tracking.
>
> That's right, rain1 pointed this out to me in irc some moments ago.
>
>> debbugs has an Emacs interface as well as a read-only web interface.
>>
>> I must admit that I’m not using debbugs regularly for our bug tracker
>> because I’m not working on bugs very often.  If we really wanted to
>> track progress on patches we could be using debbugs, but I don’t
>> actually think it would improve the situation much.
>>
>> Right now I’m capturing guix-devel emails that I want to look at later
>> with Org capture, or I simply leave them in an unread state.  The
>> problem, in my opinion, is not so much keeping track of patches, but
>> taking the time to review and engage in discussions.  I cannot review as
>> much as I would like to and for follow up discussions I often miss time
>> (in front of the computer, and in a reasonably awake state).
>
> Would it make sense to have a patches-only list or at least a
> separation between [general not-patch-related disussions,
> questions, pre-bug report questions] and [patches and their
> discussions]?
> This would not fix the people and times situation
> but eventually prevent situations in the future where we only
> have -devel for discussions, questions, patches, pre-bug
> questions, and with a growing number of participants more
> reviewers might come, but also more questions and other non-patch
> related input on the list, making it /maybe/ difficult to
> follow.
> I think it's better to think ahead and solve problems
> before they become problems, but maybe this is too soon.

Appended: maybe not, just went through emacs-devel and it seems
to be working out with discussion and patches.
Only -help at our side, there are some threads in -devel which
would be more suited for -help.

> (sidenote:
> I envision something for much later which I will discuss in
> another project and see if it fits into what we (in that project)
> focus on, maybe in a couple of years it could be useful.)
>
>> I don’t think it’s a software problem, but a people problem.  To deal
>> with more patches we need more people reviewing patches.  We already
>> have “guix lint” to point out common problems.  We probably should add a
>> little helper script for all non-Emacsers that runs Emacs over the
>> expression to check the indentation.  But other than that I’d just say:
>>
>> resend a patch if you haven’t received any response within five days or
>> so.
>
> From my perspective, resending does not really help either. It
> fills up the mailinglist with duplicates and unless I mention
> which of these threads can be considered closed, any version
> could be seen as the patch and it only works around the problem
> you mentioned and I see - too little people to review and apply
> patches.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

Re: [PATCH] Add ustr.

[Leo Famulari]

On Mon, Mar 21, 2016 at 03:50:44PM +0100, Ricardo Wurmus wrote:
> 
> Leo Famulari  writes:
> 
> > On Thu, Mar 17, 2016 at 01:13:33PM +0100, Ricardo Wurmus wrote:
> >> * gnu/packages/textutils.scm (ustr): New variable.
> >
> > [...]
> >
> >> +  (uri (string-append "http://www.and.org/ustr/"; version
> >> +  "/ustr-" version ".tar.bz2"))
> 
> [...]
> 
> > It looks like this directory only contains the current version of the
> > code, but I can't find an archive of old releases. How about mentioning
> > this in a comment, and (maybe) asking and.org to provide an archive?
> 
> Actually, there are older versions as well.  Version 1.0.2, for example,
> is at
> 
> http://www.and.org/ustr/1.0.2/ustr-1.0.2.tar.bz2

Ah, I see now!

> 
> >> +(build-system gnu-build-system)
> >> +(arguments
> >> + `(#:make-flags
> >> +   (list "CC=gcc"
> >> + "HIDE="
> >
> > I read the Makefile's comment about this. ;)
> 
> I guess we don’t qualify as “all sane people” :)
> 
> >> + "LDCONFIG=echo"
> >
> > Can you explain this one in a comment?
> 
> Will do.
> 
> >> + (string-append "prefix=" (assoc-ref %outputs "out"))
> >> + "all-shared")
> >
> > [...]
> >
> >> +;; Quoted from the home page: "The License for the code is MIT, 
> >> new-BSD,
> >> +;; LGPL, etc. ... if you need another license to help compatibility, 
> >> just
> >> +;; ask for it.  It's basically public domain, without all the legal
> >> +;; problems for everyone that trying to make something public domain
> >> +;; entails."
> >> +(license license:public-domain)))
> >
> > Sounds good to me. Hopefully there are no objections from the legal
> > experts!
> 
> Thanks for taking the time to review!  I’ll push this after adding the
> comment.

Okay!

> 
> ~~ Ricardo

Re: [PATCH] gnu: Add erlang.

[Leo Famulari]

On Wed, Mar 16, 2016 at 10:00:21PM -0700, Steve Sprang wrote:
> I don't have anything else packaged. I've only dabbled with Erlang myself.
> You can start a REPL with:
> 
> % erl

Okay, I was able to build this on x86_64 and cross-build to i686. Would
anyone like the test the build on armhf or mips64el?

I was able to run a "Hello world" program [0]:

---
$ ./pre-inst-env guix environment --pure --ad-hoc erlang -- erl -noshell -eval 
'io:fwrite("Hello, world!\n"), init:stop().'
Hello, world!
---

The configure script was not finding OpenSSL, so I've modified the
package locally to provide the path.

I did something similar for `rm`. Also, I had to provide the path to
`sed` in 'erl/bin', which is just a small shell script.

I've attached my changes. What do you think?

The Nix package [1] might show the way for future improvements to this
package.

For example, the documentation (man pages) is distributed separately, so
I've attached a patch that adds them in their own package. But, they are
only 6 megabytes (erlang itself is 100 megabytes), so they should
probably be folded into the the erlang package.

[0]
http://erlangcentral.org/wiki/index.php/Hello_World

[1]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/erlang/R18.nix

> 
> -Steve
> On Mar 16, 2016 9:21 PM, "Leo Famulari"  wrote:
> 
> > On Wed, Mar 16, 2016 at 05:18:57PM -0700, Steve Sprang wrote:
> > > Oops, I didn't follow up on this. I made the suggested changes to the
> > > patch. I also bumped the version to 18.3, which has subsequently
> > > become available.
> >
> > This is awesome!
> >
> > Do you have any erlang programs packaged that we can try it out with? Or
> > is there some "hello world" thing I can try for this package?
> >
>From cafc65901667dab9a3773f637eba65a43346da1a Mon Sep 17 00:00:00 2001
Message-Id: 
From: Steve Sprang 
Date: Sat, 6 Feb 2016 12:40:53 -0800
Subject: [PATCH 1/2] gnu: Add erlang.

* gnu/packages/erlang.scm: New file.
* gnu-system.am (GNU_SYSTEM_MODULES): Add it.

Signed-off-by: Leo Famulari 
---
 gnu-system.am   |   1 +
 gnu/packages/erlang.scm | 127 
 2 files changed, 128 insertions(+)
 create mode 100644 gnu/packages/erlang.scm

diff --git a/gnu-system.am b/gnu-system.am
index f13a55d..4cc44df 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -102,6 +102,7 @@ GNU_SYSTEM_MODULES =\
   gnu/packages/enchant.scm			\
   gnu/packages/engineering.scm			\
   gnu/packages/enlightenment.scm		\
+  gnu/packages/erlang.scm			\
   gnu/packages/fcitx.scm			\
   gnu/packages/feh.scm  \
   gnu/packages/figlet.scm			\
diff --git a/gnu/packages/erlang.scm b/gnu/packages/erlang.scm
new file mode 100644
index 000..4f9d6e4
--- /dev/null
+++ b/gnu/packages/erlang.scm
@@ -0,0 +1,127 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Steve Sprang 
+;;;
+;;; 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 erlang)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu)
+  #:use-module (gnu packages ncurses)
+  #:use-module (gnu packages perl)
+  #:use-module (gnu packages tls))
+
+(define-public erlang
+  (package
+(name "erlang")
+(version "18.3")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://erlang.org/download/otp_src_";
+version
+".tar.gz"))
+  (sha256
+   (base32
+"1hy9slq9gjvwdb504dmvp6rax90isnky6chqkyq5v4ybl4lq3azx"
+(build-system gnu-build-system)
+(native-inputs
+ `(("perl" ,perl)))
+(inputs
+ `(("ncurses" ,ncurses)
+   ("openssl" ,openssl)))
+(arguments
+ `(#:configure-flags
+   (list (string-append "--with-ssl=" (assoc-ref %build-inputs "openssl")))
+   #:phases
+   (modify-phases %standard-phases
+	 (add-after 'patch-source-shebangs 'patch-source-env
+	   (lambda _
+	 (let ((escripts
+		(append
+		 (find-files "." "\\.escript")
+		 (find-files "lib/stdlib/test/escript_SUITE_data/")
+		 '("erts/lib_src/utils/make_atomics_api"
+		   "erts/preloaded/src/add_abstract_code"
+		   "lib/diameter/b

Re: [REQ/DISCUSSION] patch managing system

[Mathieu Lirzin]

Hi,

Nils Gillmann  writes:

> As you maybe already noticed, and I hope this is not just a
> temporary impression I have after ~4 months or so, guix-devel is
> getting an increasing amount of messages per day and per month.

Same feeling here.

> In my opinion this makes it hard to keep track of patches and
> maybe also makes the workflow of people with commit access
> harder and we need a patch managing solution.
[...]
> Ideal case would be:
>  - integration with Guix in the future (the emacs interface and
>other potential future interfaces)
>  - integration into Guix website
>  - patches can be marked:
>- state (done/open)
>- priority
>  - patches can be assigned to more than 1 person
>  - webinterface
[...]
> what are your thoughts?

I think keeping track of patches is a valid concern.  However I think
you are not focusing on the actual problem by speaking of adding other
interfaces.  IMO the crucial point to make life of reviewer easier,
would be to automate the repetitive tasks and to have a way to not
forget old unpushed patches.  I think providing interfaces that are not
email based is orthogonal to this.

To automate the repetitive tasks, Cyril Roelandt had started sometimes
ago to work on a bot that was continuously applying and building
incoming patches on top of master and report (by email) if things were
building correctly.  I think that is a good idea that could be extended
by providing a way to send commands to the bot like what is done for
Debbugs.

Cyril: Do you think the bot option is feasible?

-- 
Mathieu Lirzin

Re: libcap: bzip2: Compressed file ends unexpectedly on http://mirror.guixsd.org

[Leo Famulari]

On Sat, Mar 19, 2016 at 10:22:39PM +0100, Ludovic Courtès wrote:
> Pjotr Prins  skribis:
> 
> > Downloading 9rvydp...-libcap-2.24 (125KiB installed)...
> >  http://mirror.guixsd.org/nar/9rvydpss0n9hva68jrmbg5qcjvyf3yc2-libcap-2.24 
> > 0B/s 00:00 | 0B transferred
> > bzip2: Compressed file ends unexpectedly;
> 
> Indeed, this file had zero length.
> 
> I’ve manually removed it from the nginx cache, but clearly it’d be
> problematic it empty/incomplete files ended up being cached.
> 
> If you stumble upon other such things, please let me know and give me
> the URL to we can check what’s going on.

Can you take a look at python-2.7.10?

Specifically, /gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10

This is from "ifur" on #guix:
http://paste.lisp.org/display/311051

> 
> Thank you!
> 
> Ludo’.

Re: [REQ/DISCUSSION] patch managing system

[Mathieu Lirzin]

Mathieu Lirzin  writes:

> Cyril: Do you think the bot option is feasible?

[GSoC] Integrating npm packages into the Guix ecosystem

[Jelle Licht]

Hello Guix,

Seeing as this time next year I'll be finishing up my studies, this was a
now-or-never moment for me. I would love to spend this summer hacking on
both guix, and reading up on npm.


Attached you will find the .org and corresponding pdf export of my draft
proposal for GSoC 2016!

If anyone has some feedback, I'd love to hear it.

~Jelle


proposal_jlicht.org
Description: Binary data


proposal_jlicht.pdf
Description: Adobe PDF document

Re: [PATCH] Update Artanis.

[Mathieu Lirzin]

Ricardo Wurmus  writes:

> This patch updates GNU Artanis to the latest version.  I also needed to
> set DESTDIR because the build system installs some files to
> “$DESTDIR/etc/”.
>
> ~~ Ricardo
>
>>From dd6f844687c44ff95a8f59ab047891e88e2f35b7 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Mon, 21 Mar 2016 15:56:00 +0100
> Subject: [PATCH] gnu: artanis: Update to 0.1.2.
>
> * gnu/packages/guile.scm (artanis): Update to 0.1.2.
> [arguments]: Set DESTDIR.
> ---

LGTM!

-- 
Mathieu Lirzin

Re: [PATCH] Update and fix Chicken Scheme.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> From e2fc4f5bfac95e51ba0494ffccd6354680a73385 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Sun, 20 Mar 2016 17:10:12 +0100
> Subject: [PATCH 1/4] gnu: chicken: Update to 4.10.0.
>
> * gnu/packages/scheme.scm (chicken): Update to 4.10.0.

OK!

> From 98fe76c36134f78346b18f62b09cc1ba42d11dde Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Sun, 20 Mar 2016 17:10:41 +0100
> Subject: [PATCH 2/4] gnu: chicken: Use "modify-phases" syntax.
>
> * gnu/packages/scheme.scm (chicken)[arguments]: Use "modify-phases"
>   syntax.

OK.

> From 345d60f91763c5edf696c7e9c27675655423b8e3 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Sun, 20 Mar 2016 23:01:11 +0100
> Subject: [PATCH 3/4] gnu: chicken: Disable port tests.
>
> * gnu/packages/scheme.scm (chicken)[arguments]: Do not run port tests.

OK.  I think that’s reasonable.  It’s an improvement anyway, and we can
always discuss it with upstream eventually.

> From fd4730fc5cf431d42d9ae670544eb7d6408d78e3 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Sun, 20 Mar 2016 23:03:24 +0100
> Subject: [PATCH 4/4] gnu: chicken: Build with GCC 4.8.
>
> * gnu/packages/scheme.scm (chicken)[native-inputs]: Add GCC 4.8.

OK.

Thank you!

Ludo’.

Re: small cursor gnome

[Ludovic Courtès]

ren...@openmailbox.org skribis:

> in the GNOME environment my cursor is small, and did a link as follows
> to fix it:
>
> mkdir -p ~/.icons/default
> cd ~/.icons/default
> ln -s 
> /gnu/store/zr4vacpl0rlgx6m2hivr2fm2vxhgdppc-adwaita-icon-theme-3.18.0/share/icons/Adwaita/cursors
> cursors
>
> My question is, is it necessary to create a patch-icon-theme package
> for this detail adwaita?.

This on GuixSD, right?  Isn’t it enough to install adwaita-icon-theme in
your profile or in the system profile?

Thanks,
Ludo’.

Re: [REQ/DISCUSSION] patch managing system

[Ludovic Courtès]

Hi!

The best patch-tracking candidate I’ve seen so far is “patches”, written
by/for the QEMU people (the ‘patches’ package in Guix.)

  https://www.gnu.org/software/guix/packages/#patches

I think it has everything most of us want, including an Emacs interface.

The main “difficulty” is setting it up on a machine where it can serve
those patches.json files over HTTP based on the mailing list archive
(which could be synced from ) and Git
repo.  There’s a README in the the source tree that explains the
details:

  https://github.com/aliguori/patches/blob/master/README-server.md

Would someone like to set it up somewhere and share a recipe?  I’d be
happy to beta-test it as soon as it’s available!  :-)

Ludo’.

Re: [PATCH 1/1] gnu: mutt: Enable header caching.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/packages/mail.scm (mutt)[inputs]: Add gdbm.
> [arguments]: Pass --enable-hcache to #:configure-flags.

I don’t use Mutt but this LGTM!

>  (inputs
>   `(("cyrus-sasl" ,cyrus-sasl)
> +   ("gdbm" ,gdbm)

Maybe add “for header caching” as a margin comment.

Thanks,
Ludo’.

Re: libcap: bzip2: Compressed file ends unexpectedly on http://mirror.guixsd.org

[Ricardo Wurmus]

Leo Famulari  writes:

> On Sat, Mar 19, 2016 at 10:22:39PM +0100, Ludovic Courtès wrote:
>> Pjotr Prins  skribis:
>> 
>> > Downloading 9rvydp...-libcap-2.24 (125KiB installed)...
>> >  http://mirror.guixsd.org/nar/9rvydpss0n9hva68jrmbg5qcjvyf3yc2-libcap-2.24 
>> > 0B/s 00:00 | 0B transferred
>> > bzip2: Compressed file ends unexpectedly;
>> 
>> Indeed, this file had zero length.
>> 
>> I’ve manually removed it from the nginx cache, but clearly it’d be
>> problematic it empty/incomplete files ended up being cached.
>> 
>> If you stumble upon other such things, please let me know and give me
>> the URL to we can check what’s going on.
>
> Can you take a look at python-2.7.10?
>
> Specifically, /gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10
>
> This is from "ifur" on #guix:
> http://paste.lisp.org/display/311051

Boost at

  http://hydra.gnu.org/nar/wkj46vmxw2zl4amia2iav2wsn7c7pb9j-boost-1.60.0

probably also needs fixing.

~~ Ricardo

Hash mismatch for Python 2.7.10 (x86_64-linux)

[Ludovic Courtès]

Leo Famulari  skribis:

> Can you take a look at python-2.7.10?
>
> Specifically, /gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10
>
> This is from "ifur" on #guix:
> http://paste.lisp.org/display/311051

This is an “interesting” case.  There’s indeed a hash mismatch between
that narinfo and the nar (hydra.gnu.org and mirror.guixsd.org provide
the exact same narinfo and nar though):

--8<---cut here---start->8---
$ wget -q -O - https://hydra.gnu.org/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv.narinfo 
|grep Hash
NarHash: sha256:1ifhxz7ng64ckrsfp0cy6rcybwrdf2mgq7p9w73ynbwy1w2frhp5
$ wget -q -O - 
https://hydra.gnu.org/nar/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10 | 
bunzip2 | guix hash /dev/stdin
1rb34mfv32zj6ir9nkrmw2mrc00n2gf9p2chihh1qpl9fmsxhhif
$ guix hash -r /gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10
1ifhxz7ng64ckrsfp0cy6rcybwrdf2mgq7p9w73ynbwy1w2frhp5
--8<---cut here---end--->8---

To spot the differences, I did:

--8<---cut here---start->8---
$ wget -O - 
https://mirror.guixsd.org/nar/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10 | 
bunzip2 | guix archive -x /tmp/python
$ diff -ur --no-dereference /tmp/python 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10
Binary files /tmp/python/lib/python2.7/_abcoll.pyc and 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/_abcoll.pyc
 differ
Binary files /tmp/python/lib/python2.7/abc.pyc and 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/abc.pyc 
differ
Binary files /tmp/python/lib/python2.7/codecs.pyc and 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/codecs.pyc
 differ
Binary files /tmp/python/lib/python2.7/copy_reg.pyc and 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/copy_reg.pyc
 differ
Binary files /tmp/python/lib/python2.7/encodings/aliases.pyc and 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/encodings/aliases.pyc
 differ
Binary files /tmp/python/lib/python2.7/encodings/__init__.pyc and 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/encodings/__init__.pyc
 differ
Binary files /tmp/python/lib/python2.7/encodings/utf_8.pyc and 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/encodings/utf_8.pyc
 differ
[...]
$ diffoscope --html t.html /tmp/python/lib/python2.7 
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10/lib/python2.7/
--8<---cut here---end--->8---

Diffoscope shows several hundred of bytes of differences in several .pyc
files (so it’s not just 32-byte timestamps as discussed in
, IIRC.)

That the differences are so important is fishy.  Could you check what
you have on your machine?  Is anyone able to make an independent build
of this thing?


For non-deterministic packages, something that could in theory happen
(although it seems unlikely) is this:

  1. nginx caches the narinfo of a first build with hash X;

  2. nobody downloads the corresponding nar, and the result is
 eventually GC’d from hydra;

  3. Hydra rebuilds the thing, obtains hash Y; the nar with hash Y is
 downloaded and cached by nginx, but, no luck, it doesn’t match the
 hash in the narinfo that was cached in step #1.

That could happen, but it seems pretty far-fetched, especially for a
package like Python.


On my machine I looked for the corresponding “derivers”:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> (define s (open-connection))
scheme@(guile-user)> (valid-derivers s 
"/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10")
$4 = ("/gnu/store/a5s3mkl387wwkklj3ss5hw34ib9rb2p6-python-2.7.10.drv" 
"/gnu/store/pvsdsjn15rj1ciwr37vl2vqprvl57szg-python-2.7.10.drv")
--8<---cut here---end--->8---

And then run:

--8<---cut here---start->8---
$ guix build "/gnu/store/pvsdsjn15rj1ciwr37vl2vqprvl57szg-python-2.7.10.drv" 
--check  
--8<---cut here---end--->8---

However that’s not very helpful since it unsurprisingly fails with a
“may not be deterministic” error.

Ludo’.

Removing compilers that cannot be bootstrapped

[Thompson, David]

Haskell, OCaml, Chicken, and other compilers that we package have a
serious issue that many of us are aware of: they cannot be built from
source!  They rely upon pre-built binaries of the same compiler.  I
understand that it's very inconvenient to not have these compilers
available to us, and all of the software that is written in their
respective languages, but I feel like all of our work is undermined by
making exceptions for them.  I would like to remove compilers that
don't have a bunch of dependent packages yet such as Chicken until
upstream fixes the issue.  But we have tons of Haskell packages and a
handful of OCaml packages and it would be heartbreaking to some to
remove all of that hard work.

What can we possibly do to avoid being yet another distro that relies
on a bunch of blobs (leaving the *true* bootstrap binaries out of it
for now)?

- Dave

Re: small cursor gnome

[rennes]

On 2016-03-21 10:37, l...@gnu.org wrote:

ren...@openmailbox.org skribis:


in the GNOME environment my cursor is small, and did a link as follows
to fix it:

mkdir -p ~/.icons/default
cd ~/.icons/default
ln -s
/gnu/store/zr4vacpl0rlgx6m2hivr2fm2vxhgdppc-adwaita-icon-theme-3.18.0/share/icons/Adwaita/cursors
cursors

My question is, is it necessary to create a patch-icon-theme package
for this detail adwaita?.


This on GuixSD, right?  Isn’t it enough to install adwaita-icon-theme 
in

your profile or in the system profile?

Thanks,
Ludo’.


yes in GuixSD, this is not enough. I'll check the documentation for more 
information.

Re: Removing compilers that cannot be bootstrapped

[Taylan Ulrich Bayırlı/Kammer]

"Thompson, David"  writes:

> Haskell, OCaml, Chicken, and other compilers that we package have a
> serious issue that many of us are aware of: they cannot be built from
> source!  They rely upon pre-built binaries of the same compiler.  I
> understand that it's very inconvenient to not have these compilers
> available to us, and all of the software that is written in their
> respective languages, but I feel like all of our work is undermined by
> making exceptions for them.  I would like to remove compilers that
> don't have a bunch of dependent packages yet such as Chicken until
> upstream fixes the issue.  But we have tons of Haskell packages and a
> handful of OCaml packages and it would be heartbreaking to some to
> remove all of that hard work.
>
> What can we possibly do to avoid being yet another distro that relies
> on a bunch of blobs (leaving the *true* bootstrap binaries out of it
> for now)?

A while back Mark raised the idea of hosting one pre-compiled bootstrap
version of each such compiler, and use that to compile further versions.

This way the number of blobs is one per such compiler, instead of one
for every new version of each such compiler.

It seemed like a good medium-term solution to me.  I'm not sure how it
would be implemented.

I think the original proposal had it that we keep an internal bootstrap
version of the package, which works by downloading a blob, and this is
used to compile the true, public package.  However, we would need to
update the bootstrap version whenever it becomes too old to compile the
newest version.  So new untrusted blobs enter the picture every once in
a while.  Maybe frequently, if some of these compilers don't care much
about supporting the ability to be compiled with somewhat older versions
of themselves.

A solution to that in turn might be to keep a growing list of
intermediate versions of the compiler in addition to the bootstrap and
newest versions.  The first version in this list can be compiled via the
bootstrap version, each nth version in the list can be compiled with the
n-1th version, and the last version in the list is used to compile the
current, newest version.

(define %foo-compiler-bootstrap
  (package ... (source some-blob) ...))

(define %foo-compiler-intermediate-versions-list
  '("1.1" "1.7" "2.2" ...))

(define %foo-compiler-intermediate-versions
  (magic %foo-compiler-bootstrap
 %foo-compiler-intermediate-versions-list))

(define foo-compiler
  (package
...
(native-inputs
  `(("foo-compiler" ,(last %foo-compiler-intermediate-versions))
...))
...))

So when someone instructs guix to rebuild the world from scratch, it
downloads the bootstrap blob, then builds 1.1 with it, then builds 1.7
with that, then 2.2 with that, and so on, and ultimately the current
version.

This way it's truly one blob for each such compiler in guix.  And one
day, that blob can be replaced with a verified-safe one.

I just came up with this and haven't thought much about it.  Just
throwing it out there.

> - Dave

Taylan

Re: Removing compilers that cannot be bootstrapped

[Taylan Ulrich Bayırlı/Kammer]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> "Thompson, David"  writes:
>
>> Haskell, OCaml, Chicken, and other compilers that we package have a
>> serious issue that many of us are aware of: they cannot be built from
>> source!  They rely upon pre-built binaries of the same compiler.  I
>> understand that it's very inconvenient to not have these compilers
>> available to us, and all of the software that is written in their
>> respective languages, but I feel like all of our work is undermined by
>> making exceptions for them.  I would like to remove compilers that
>> don't have a bunch of dependent packages yet such as Chicken until
>> upstream fixes the issue.  But we have tons of Haskell packages and a
>> handful of OCaml packages and it would be heartbreaking to some to
>> remove all of that hard work.
>>
>> What can we possibly do to avoid being yet another distro that relies
>> on a bunch of blobs (leaving the *true* bootstrap binaries out of it
>> for now)?
>
> A while back Mark raised the idea of hosting one pre-compiled bootstrap
> version of each such compiler, and use that to compile further versions.

I now found Mark's mail in the archive:

https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html

Taylan

Re: Removing compilers that cannot be bootstrapped

[Andreas Enge]

On Mon, Mar 21, 2016 at 08:15:34PM +0100, Taylan Ulrich Bayırlı/Kammer wrote:
> So when someone instructs guix to rebuild the world from scratch, it
> downloads the bootstrap blob, then builds 1.1 with it, then builds 1.7
> with that, then 2.2 with that, and so on, and ultimately the current
> version.

This is an interesting idea, but maybe not enough, assuming that the build
process requires additional inputs to build besides the bootstrap blob.
If we need additional libraries A to Z to build the compiler, then it may
be that 1.7 and 2.2 require different versions of these libraries. And of
course, each library may depend recursively on another set of libraries.
Ultimately, this might force us to keep a whole tree (well, DAG) of frozen
inputs for versions 1.7 and 2.2 to compile the current one. This might
quickly become completely unmanageable. (An example is the latest trial
of updating libreoffice, which was actually impossible given that libreoffice
itself and some of its inputs all depended on a certain library, but in
different versions).

Andreas

Re: [PATCH 1/2] gnu: Add freealut.

[David Hashe]

Hi Ricardo,

Thanks for taking the time to review this!

On Mon, Mar 21, 2016 at 9:36 AM, Ricardo Wurmus <
ricardo.wur...@mdc-berlin.de> wrote:

>
> Hi David,
>
> thank you for the patch!
>
> > * gnu/packages/audio.scm (freealut): New variable.
> > ---
>
> [...]
>
> >
> > +(define-public freealut
> > +  (package
> > +(name "freealut")
> > +(version "1.1.0")
> > +(source (origin
> > +  (method git-fetch)
> > +  (uri (git-reference
> > +;; The official repository is defunct. This is the
> most
> > +;; popular mirror.
> > +(url (string-append "https://github.com/vancegroup/";
> name))
> > +(commit version)))
>
> I see that Arch and Fedora both use the tarball from here:
>
>
> http://pkgs.fedoraproject.org/repo/pkgs/freealut/freealut-1.1.0.tar.gz/e089b28a0267faabdb6c079ee173664a/freealut-1.1.0.tar.gz
>
> The advantage of that tarball is that it doesn’t require bootstrapping,
> so you can do without the additional “autogen” phase and without the
> three native inputs.
>

Done. By the way, where exactly do you find what tarball Arch and Fedora
use for a given package? I couldn't seem to find that information on a
cursory glance.


>
> > +(home-page "http://www.openal.org/";)
>
> Does Freealut itself have a home page?  It doesn’t seem right to me to
> declare the website of OpenAL as the home page, when the package is
> really just one implemenatation of the standard published on the OpenAL
> website.
>
>
I agree, but it doesn't seem to have a separate home page. Debian simply
lists the home page as "http://www.openal.org/";, for instance. I could set
the field to #f, but guix lint complains about that and it looks like only
the bootstrap-binaries actually do that. For now, I've added a comment
clarifying the situation.

Let me know if you think that another option would be better.


> > +(synopsis "OpenAL Utility Tool")
>
> Is it a library or a tool (or both)?  What does it do?
>

It is a library, similar to GLUT from OpenGL. I've expanded the synopsis
to "Implementation of the OpenAL Utility Toolkit (ALUT)", which I patterned
off of the freeglut synopsis.


>
> > +(description "Freealut is a free implementation of OpenAL's ALUT
> > +standard.")
>
> Could you try to extend the description a little?  I don’t know what
> this really means.
>

I've expanded the synopsis.


>
> ~~ Ricardo
>

Thanks!
David Hashe
From 196fcc5fb1071da976aec1785fd95ada8fdf7418 Mon Sep 17 00:00:00 2001
From: David Hashe 
Date: Sat, 19 Mar 2016 00:56:55 -0500
Subject: [PATCH] gnu: Add freealut.

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

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index ca438f8..5225c64 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2015 Andreas Enge 
 ;;; Copyright © 2015 Alex Kost 
 ;;; Copyright © 2015, 2016 Mark H Weaver 
+;;; Copyright © 2016 David Hashe 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1504,6 +1505,36 @@ buffers, and audio capture.")
 (home-page "http://kcat.strangesoft.net/openal.html";)
 (license license:lgpl2.0+)))
 
+(define-public freealut
+  (package
+(name "freealut")
+(version "1.1.0")
+(source (origin
+  (method url-fetch)
+  (uri
+   (let ((name-version-tar
+  (string-append name "-" version ".tar.gz")))
+ (string-append
+  "http://pkgs.fedoraproject.org/repo/pkgs/"; name "/"
+  name-version-tar "/"
+  "e089b28a0267faabdb6c079ee173664a/"
+  name-version-tar)))
+  (sha256
+   (base32
+"0kzlil6112x2429nw6mycmif8y6bxr2cwjcvp18vh6s7g63ymlb0"
+(build-system gnu-build-system)
+(inputs
+ `(("openal" ,openal)))
+;; This is the home page for the specification, but there is no
+;; project-specific homepage.
+(home-page "https://www.openal.org/";)
+(synopsis "Implementation of the OpenAL Utility Toolkit (ALUT)")
+(description "Freealut is a free implementation of OpenAL's ALUT standard.
+ALUT is the OpenAL equivalent to GLUT fom OpenGL and has an intentionally
+similar API.  It is intended to allow developers to quickly learn OpenAL while
+abstracting away details such as loading sound samples from disk.")
+(license license:lgpl2.0+)))
+
 (define-public patchage
   (package
 (name "patchage")
-- 
1.9.1

Re: [PATCH 1/1] gnu: mutt: Enable header caching.

[Leo Famulari]

On Mon, Mar 21, 2016 at 05:44:37PM +0100, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > * gnu/packages/mail.scm (mutt)[inputs]: Add gdbm.
> > [arguments]: Pass --enable-hcache to #:configure-flags.
> 
> I don’t use Mutt but this LGTM!
> 
> >  (inputs
> >   `(("cyrus-sasl" ,cyrus-sasl)
> > +   ("gdbm" ,gdbm)
> 
> Maybe add “for header caching” as a margin comment.

Done in b0bb01369!

> 
> Thanks,
> Ludo’.

Re: [PATCH 1/2] gnu: Add freealut.

[Ricardo Wurmus]

David Hashe  writes:

>> I see that Arch and Fedora both use the tarball from here:
>>
>>
>> http://pkgs.fedoraproject.org/repo/pkgs/freealut/freealut-1.1.0.tar.gz/e089b28a0267faabdb6c079ee173664a/freealut-1.1.0.tar.gz
>>
>> The advantage of that tarball is that it doesn’t require bootstrapping,
>> so you can do without the additional “autogen” phase and without the
>> three native inputs.
>>
>
> Done. By the way, where exactly do you find what tarball Arch and Fedora
> use for a given package? I couldn't seem to find that information on a
> cursory glance.

I looked at the PKGBUILD of the Arch package.

>> Does Freealut itself have a home page?  It doesn’t seem right to me to
>> declare the website of OpenAL as the home page, when the package is
>> really just one implemenatation of the standard published on the OpenAL
>> website.
>>
>>
> I agree, but it doesn't seem to have a separate home page. Debian simply
> lists the home page as "http://www.openal.org/";, for instance. I could set
> the field to #f, but guix lint complains about that and it looks like only
> the bootstrap-binaries actually do that. For now, I've added a comment
> clarifying the situation.

That’s good, thanks.

The patch looks pretty good to me now, except maybe for this

+  (uri
+   (let ((name-version-tar
+  (string-append name "-" version ".tar.gz")))
+ (string-append
+  "http://pkgs.fedoraproject.org/repo/pkgs/"; name "/"
+  name-version-tar "/"
+  "e089b28a0267faabdb6c079ee173664a/"
+  name-version-tar)))

I find the let binding a bit too ... much :)  But if nobody else has a
problem with this, I wouldn’t complain.

Thanks!

~~ Ricardo

Re: [PATCH 5/6] gnu: Add borg.

[Leo Famulari]

On Tue, Mar 15, 2016 at 05:18:45AM -0400, Leo Famulari wrote:
> On Tue, Mar 15, 2016 at 12:11:15PM +0300, Alex Kost wrote:
> > Leo Famulari (2016-03-15 02:34 +0300) wrote:
> > > +   (modify-phases %standard-phases
> > > + (add-before 'build 'set-openssl-prefix
> > > +   (lambda* (#:key inputs #:allow-other-keys)
> > > + (setenv "BORG_OPENSSL_PREFIX" (assoc-ref inputs "openssl"))
> > > + #t))
> > > + (add-before 'build 'set-lz4-prefix
> > > +   (lambda* (#:key inputs #:allow-other-keys)
> > > + (setenv "BORG_LZ4_PREFIX" (assoc-ref inputs "lz4"))
> > > + #t))
> > 
> > Would it be better to make a single 'set-env' phase instead?  Or better
> > yet, are these '..._PREFIX' variables used for make command?  If so,
> > they should be specified in #:make-flags argument.
> 
> Thank you, that makes the recipe shorter and clearer.

I didn't test the change before replying ;)

There is no #:make-flags for the python-build-system, so I have used a
single set-env phase instead.

Re: [PATCH 1/2] gnu: Add freealut.

[David Hashe]

On Mon, Mar 21, 2016 at 4:24 PM, Ricardo Wurmus <
ricardo.wur...@mdc-berlin.de> wrote:

>
> David Hashe  writes:
>
> >> I see that Arch and Fedora both use the tarball from here:
> >>
> >>
> >>
> http://pkgs.fedoraproject.org/repo/pkgs/freealut/freealut-1.1.0.tar.gz/e089b28a0267faabdb6c079ee173664a/freealut-1.1.0.tar.gz
> >>
> >> The advantage of that tarball is that it doesn’t require bootstrapping,
> >> so you can do without the additional “autogen” phase and without the
> >> three native inputs.
> >>
> >
> > Done. By the way, where exactly do you find what tarball Arch and Fedora
> > use for a given package? I couldn't seem to find that information on a
> > cursory glance.
>
> I looked at the PKGBUILD of the Arch package.
>
> >> Does Freealut itself have a home page?  It doesn’t seem right to me to
> >> declare the website of OpenAL as the home page, when the package is
> >> really just one implemenatation of the standard published on the OpenAL
> >> website.
> >>
> >>
> > I agree, but it doesn't seem to have a separate home page. Debian simply
> > lists the home page as "http://www.openal.org/";, for instance. I could
> set
> > the field to #f, but guix lint complains about that and it looks like
> only
> > the bootstrap-binaries actually do that. For now, I've added a comment
> > clarifying the situation.
>
> That’s good, thanks.
>
> The patch looks pretty good to me now, except maybe for this
>
> +  (uri
> +   (let ((name-version-tar
> +  (string-append name "-" version ".tar.gz")))
> + (string-append
> +  "http://pkgs.fedoraproject.org/repo/pkgs/"; name "/"
> +  name-version-tar "/"
> +  "e089b28a0267faabdb6c079ee173664a/"
> +  name-version-tar)))
>
> I find the let binding a bit too ... much :)  But if nobody else has a
> problem with this, I wouldn’t complain.
>

Yeah... I wasn't sure if it made things better or worse. I've gone ahead
and removed it, since it might be a bit more readable that way.


>
> Thanks!
>
> ~~ Ricardo
>

- David
From 38bdec70d4cb3cdc3e810eea7c3c475a289e3cd4 Mon Sep 17 00:00:00 2001
From: David Hashe 
Date: Sat, 19 Mar 2016 00:56:55 -0500
Subject: [PATCH] gnu: Add freealut.

* gnu/packages/audio.scm (freealut): New variable.
---
 gnu/packages/audio.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index ca438f8..cbaad11 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2015 Andreas Enge 
 ;;; Copyright © 2015 Alex Kost 
 ;;; Copyright © 2015, 2016 Mark H Weaver 
+;;; Copyright © 2016 David Hashe 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1504,6 +1505,33 @@ buffers, and audio capture.")
 (home-page "http://kcat.strangesoft.net/openal.html";)
 (license license:lgpl2.0+)))
 
+(define-public freealut
+  (package
+(name "freealut")
+(version "1.1.0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://pkgs.fedoraproject.org/repo/pkgs/"; name "/"
+name "-" version ".tar.gz/"
+"e089b28a0267faabdb6c079ee173664a/"
+name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"0kzlil6112x2429nw6mycmif8y6bxr2cwjcvp18vh6s7g63ymlb0"
+(build-system gnu-build-system)
+(inputs
+ `(("openal" ,openal)))
+;; This is the home page for the specification, but there is no
+;; project-specific homepage.
+(home-page "https://www.openal.org/";)
+(synopsis "Implementation of the OpenAL Utility Toolkit (ALUT)")
+(description "Freealut is a free implementation of OpenAL's ALUT standard.
+ALUT is the OpenAL equivalent to GLUT fom OpenGL and has an intentionally
+similar API.  It is intended to allow developers to quickly learn OpenAL while
+abstracting away details such as loading sound samples from disk.")
+(license license:lgpl2.0+)))
+
 (define-public patchage
   (package
 (name "patchage")
-- 
1.9.1

[PATCH v2] Add hplip

[Danny Milosavljevic]

This is a patch that adds hplip. Note that hplip builds and installs but we 
don't do any of the merging of different packages' ppds etc yet [the majority 
of the merging will be in "services" and not in "packages", though].

diff --git a/gnu/packages/cups.scm b/gnu/packages/cups.scm
index ff3d152..ca637c1 100644
--- a/gnu/packages/cups.scm
+++ b/gnu/packages/cups.scm
@@ -26,6 +26,10 @@
   #:use-module (gnu packages)
   #:use-module (gnu packages avahi)
   #:use-module (gnu packages compression)
+  #:use-module (gnu packages libusb)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages scanner)
   #:use-module (gnu packages image)
   #:use-module (gnu packages fonts) ;font-dejavu
   #:use-module (gnu packages fontutils)
@@ -297,3 +301,59 @@ device-specific programs to convert and print many types 
of files.")
("gnutls" ,gnutls)
("cups-filters" ,cups-filters)
("zlib"  ,zlib)
+
+(define-public hplip
+  (package
+(name "hplip")
+(version "3.16.2")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "mirror://sourceforge/hplip/"
+  "/hplip-" version ".tar.gz"))
+  (sha256
+   (base32
+"1nflgrbyl0fz35djnkn7qsfr5g4sh8lixqna9jvs52wasjllbj7j"
+(build-system gnu-build-system)
+(home-page "http://hplipopensource.com/";)
+(synopsis "HP Printer Drivers")
+(description "HP Printer Drivers and PPDs. You can use the PPDs with CUPS 
as well.")
+(license (list license:gpl2 license:bsd-3)) ; FIXME and which MIT
+; FIXME remove Binary plugin-ins, hp-plugin
+; FIXME PPDs use "hpcups" in cupsFilter. In which directory?
+; TODO install apparmor profile files
+(arguments `(#:configure-flags `("--disable-network-build"
+ ,(string-append "--prefix=" (assoc-ref 
%outputs "out"))
+ ,(string-append "--sysconfdir=" 
(assoc-ref %outputs "out") "/etc")
+ "--disable-fax-build" ; until mime.types 
merging works; FIXME re-enable
+ ,(string-append "--with-cupsfilterdir=" 
(assoc-ref %outputs "out") "/lib/cups/filter") ; TODO merge
+ ,(string-append "--with-cupsbackenddir=" 
(assoc-ref %outputs "out") "/lib/cups/backend") ; TODO merge
+ ,(string-append "--with-icondir=" 
(assoc-ref %outputs "out") "/share/applications") ; TODO merge
+ ,(string-append "--with-systraydir=" 
(assoc-ref %outputs "out") "/etc/xdg")) ; TODO merge
+ ; #:make-flags (list (string-append "DESTDIR=" (assoc-ref 
%outputs "out")))
+ #:phases (alist-cons-after
+   'fix-libusb 'autoreconf
+   (lambda _
+ (setenv "AUTOMAKE" "automake --foreign")
+ (zero? (system* "autoreconf" "-fi")))
+   (alist-cons-after 'unpack 'fix-libusb
+(lambda* (#:key inputs outputs #:allow-other-keys)
+ (substitute* "Makefile.am" 
(("/usr/include/libusb-1.0") (string-append (assoc-ref inputs "libusb") 
"/include/libusb-1.0"))
+(("hplip_statedir[ 
]*=[ ]*/var/lib/hp") (string-append "hplip_statedir = " (assoc-ref outputs 
"out") "/var/lib/hp")) ; only for the installer.
+(("hplip_confdir[ ]*=[ 
]*/etc/hp") (string-append "hplip_confdir = " (assoc-ref outputs "out") 
"/etc/hp")) ; only for installing the default config
+(("halpredir[ ]*=[ 
]*/usr/share/hal/fdi/preprobe/10osvendor") (string-append "halpredir = " 
(assoc-ref outputs "out") "/share/hal/fdi/preprobe/10osvendor")) ; I don't 
think we use hal, so who cares?
+(("rulesdir[ ]*=[ 
]*/etc/udev/rules.d") (string-append "rulesdir = " (assoc-ref outputs "out") 
"/lib/udev/rules.d")) ; will be merged by base service
+
(("rulessystemdir=/usr/lib/systemd/system") (string-append "rulessystemdir = " 
(assoc-ref outputs "out") "/lib/systemd/system")) ; dummy
+(("/etc/sane.d") 
(string-append (assoc-ref outputs "out") "/etc/sane.d"
+%standard-phases
+(inputs `(("libjpeg" ,libjpeg)
+  ("cups-minimal" ,cups-minimal)
+  ("libusb" ,libusb)
+  ("python" ,python) ; FIXME propagated-inputs ??
+  ("sane-backends" ,sane-backends)
+  ("dbus" ,dbus)))
+(native-inputs `(("pkg-config" ,pkg-config)
+ ("automake" ,automake

Re: [GSoC] Draft of my proposition

[vincent]

21. Mar 2016 05:35 by l...@gnu.org:


> Hello!
>
> <> vinc...@cloutier.co> > skribis:
>
>> The admission for Google's Summer of Code have started and I want to spend
>> the summer working on Guix. I have a proposition I hope you will find
>> interesting! I have joined the draft to this e-mail.
> Preliminary question: could you resend it as plain text or Org-mode to
> simply the life of people on this list?
>
>

Of course! I added a plain text version to this email.





Vincent Cloutier

Guix – Adding peer-to-peer sharing
Vincent Cloutier
vinc...@cloutier.co

Abstract

Large performance gains and servers savings could be made by fetching data from 
peers instead of a central set of servers. Since Guix users know in advance the 
hash of the data they want, downloading from peers has no security implications 
(and privacy can be done trough proxies).  

What I want to build

I have a fascination for peer-to-peer tech and I am constantly looking for the 
innovative new tech in this area (Bitcoin, Ethereum, etc). Less than a year ago 
I discovered IPFS, a project that takes the best ideas from BitTorrent and Git 
to create a simple and elegant protocol. 

IPFS allows one to find who has a piece of content and is ready to share it, 
when knowing only the content’s hash. Content is added in a reproducible manner 
and deduplication can be added via Merkle trees. IPFS is also content-agnostic, 
one could serve Guix’s programs without even running Guix. It would also be 
possible to share text or video documentation using IPFS. 

This could allow the community to chip in to Guix success more easily. 
Publishing the content of one’s store for anyone to download will be possible. 
Looking at GNU/Linux distributions’ torrents, everyone seeds to help the 
community. It is very likely people will want to do the same for Guix. 

This adds no restriction on how a chain of trusts of key contributor to the 
project can be built. When a way of building consensus on a package’s hash 
(maybe via an Ethereum smart contract) will be build, everything will be in 
place for a serverless and fully auditable OS. 

What I will do before the summer

There is currently a free implementation of the IPFS protocol written in go and 
another one in Javascript underway. I will package them for Guix and add them 
to the repository. This will be a great way to familiarize myself with the 
codebase. 

Lisp looks interesting having done some Haskell. I will make sure I am 
comfortable with it.

What I will do during the first half of the summer

I will add the option to fetch content via IPFS instead of via HTTP. Guix will 
spawn an IPFS daemon and run it in a container. I will build it in a way that 
it will not be a hard dependency, as it is preferable in some cases to use a 
client-server architecture, and the code I will write will handle without 
problems the absence of an IPFS client. I will also make sure this can run with 
any of IPFS free implementation.

What I will do during the second half of the summer 

I will made the publish command also spawn an IPFS daemon and publish 
everything available in the store. I will also be there if the Hydra build farm 
runs into any problem with this new code. There will be a option to turn it off 
at any time, and statitstics will be made available, ex: how much bandwidth has 
been used, what are the most requested packages, etc. 

I will look into making the data storage efficient by making the IPFS daemon 
not copy everything in its own data store. 

Stretch goals

If everything goes better than expected and everything works beautifully before 
the end of the summer, I have the following stretch goals in mind: 

A GPL’ed IPFS implementation in Lisp
Packaging more free software for Guix

Who I am 

My name is Vincent Cloutier and I am a french speaking developper in Québec. I 
am currently in cégep (https://en.wikipedia.org/wiki/CEGEP). 

I started programming when I was very young. My father started showing me some 
python when I was 8, and I have not stopped programming since. I worked in 
python for a few years - I was fascinated by infinite loops until I was 9 - 
then I switched to Perl for a while (where I tried to make chatbots), and then 
to PHP that I continue to use to this day. I also do haskell competitions for 
fun here 
(https://www.codingame.com/profile/8ee4bb16e866d398775fa5bc545e426e2789121), 
though I am not good at it yet.

I already contribute to free software. I made ipfs.pics with a friend. It is a 
picture sharing website that uses the P2P IPFS technology. I did a junior job 
on Owncloud two years ago (https://github.com/owncloud/core/pull/11029) to see 
what a big open source project looked like. I used Sagemath cloud on my 
chromebook for school and made two pull requests 
(https://github.com/sagemathinc/smc/pull/52 and 
https://github.com/sagemathinc/smc/pull/53) to improve the UI on small screens.

A couple of years ago I realized that every tool I had learn and eve

Re: [GSoC] Bourne-shell compiler front-end for Guile

[Ludovic Courtès]

Hi Efraim,

Thanks for your proposal!

This project can be pretty fun, I think, and quite rewarding if it
indeed allows us to get rid of a bunch of bootstrap binaries.

As I see it, the project covers mostly two areas:

  1. Lexing & parsing.  This compiler front-end will need a real parser
 for the Bourne shell syntax, notably semicolon-separated command
 sequences, pipes, brace-delimited blocks, functions, variables, and
 ‘test’ and ‘[’.

 The available tools could be SILex + (system base lalr) (the latter
 is part of Guile, the former is maintained separately; a copy can
 be found in Guile-RPC for instance.)

  2. Run-time support: redirections, pipes, background execution, C-c
 (SIGINT) and C-z (SIGTSTP), globbing, and so on.

 Guile provides just the basic here, and a little more with (ice-9
 popen).  Scsh and its Guile port(s) provide a lot of that, so it
 might be a good idea to see what can be stolen from these.

It may be that some of your CS classes cover some of this ground (a
fairly common programming project here at university is to implement a
small shell precisely because it covers several areas.)

How does that sound?

Perhaps one way to get started would be by looking at the available
tools for #1, and experimenting with hacks for #2, possibly borrowing
code from Scsh.

Thoughts?

Thanks,
Ludo’.

PS: Would be nice to have a second mentor on this, either officially or
unofficially (if you don’t want to have a to be known to Google…).
Any takers?  :-)

Re: [PATCH 5/6] gnu: Add borg.

[Leo Famulari]

On Mon, Mar 21, 2016 at 05:31:15PM -0400, Leo Famulari wrote:
> On Tue, Mar 15, 2016 at 05:18:45AM -0400, Leo Famulari wrote:
> > On Tue, Mar 15, 2016 at 12:11:15PM +0300, Alex Kost wrote:
> > > Leo Famulari (2016-03-15 02:34 +0300) wrote:
> > > > +   (modify-phases %standard-phases
> > > > + (add-before 'build 'set-openssl-prefix
> > > > +   (lambda* (#:key inputs #:allow-other-keys)
> > > > + (setenv "BORG_OPENSSL_PREFIX" (assoc-ref inputs 
> > > > "openssl"))
> > > > + #t))
> > > > + (add-before 'build 'set-lz4-prefix
> > > > +   (lambda* (#:key inputs #:allow-other-keys)
> > > > + (setenv "BORG_LZ4_PREFIX" (assoc-ref inputs "lz4"))
> > > > + #t))
> > > 
> > > Would it be better to make a single 'set-env' phase instead?  Or better
> > > yet, are these '..._PREFIX' variables used for make command?  If so,
> > > they should be specified in #:make-flags argument.
> > 
> > Thank you, that makes the recipe shorter and clearer.
> 
> I didn't test the change before replying ;)
> 
> There is no #:make-flags for the python-build-system, so I have used a
> single set-env phase instead.

I asked upstream about some warnings during the docs generation, and
they pointed out that I needed to add a command line. I've attached a
revised patch.

Can I get some feedback on it?
>From f5e9039a6d161d8b834b33a660e865d043627684 Mon Sep 17 00:00:00 2001
Message-Id: 
In-Reply-To: <90ce1642eb4e527227b4c2bce25dcf25b484e22f.1458599643.git@famulari.name>
References: <90ce1642eb4e527227b4c2bce25dcf25b484e22f.1458599643.git@famulari.name>
From: Leo Famulari 
Date: Mon, 14 Mar 2016 19:34:25 -0400
Subject: [PATCH 5/6] gnu: Add borg.

* gnu/packages/backup.scm (borg): New variable.
---
 gnu/packages/backup.scm | 54 -
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index 4a69b7a..d5c304b 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015 Eric Bavier 
 ;;; Copyright © 2014 Ian Denhardt 
-;;; Copyright © 2015 Leo Famulari 
+;;; Copyright © 2015, 2016 Leo Famulari 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -406,3 +406,55 @@ compression, and more.  The library itself implements storage techniques such
 as content-addressable storage, content hash keys, Merkle trees, similarity
 detection, and lossless compression.")
 (license license:gpl3+)))
+
+(define-public borg
+  (package
+(name "borg")
+(version "1.0.0")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "borgbackup" version))
+  (sha256
+   (base32
+"0wa6cvqs3rni5nwrgagigchcly8a53rxk56z0zn8iaii2cqrw2sh"
+(build-system python-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'set-env
+   (lambda* (#:key inputs #:allow-other-keys)
+ (let ((openssl (assoc-ref inputs "openssl"))
+   (lz4 (assoc-ref inputs "lz4")))
+   (setenv "BORG_OPENSSL_PREFIX" openssl)
+   (setenv "BORG_LZ4_PREFIX" lz4)
+   (setenv "PYTHON_EGG_CACHE" "/tmp")
+ #t)))
+ (add-after 'install 'docs
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(man (string-append out "/share/man/man1")))
+   (and
+ (zero? (system* "python3" "setup.py" "build_ext" "--inplace"))
+ (zero? (system* "make" "-C" "docs" "man"))
+ (install-file "docs/_build/man/borg.1" man)))
+ #t)
+(native-inputs
+ `(("python-setuptools-scm" ,python-setuptools-scm)
+   ;; For generating the documentation.
+   ("python-sphinx" ,python-sphinx)
+   ("python-sphinx-rtd-theme" ,python-sphinx-rtd-theme)))
+(inputs
+ `(("acl" ,acl)
+   ("lz4" ,lz4)
+   ("openssl" ,openssl)
+   ("python-llfuse" ,python-llfuse)
+   ("python-msgpack" ,python-msgpack)))
+(synopsis "Deduplicated, encrypted, authenticated and compressed backups")
+(description "Borg is a deduplicating backup program.  Optionally, it
+supports compression and authenticated encryption.  The main goal of Borg is to
+provide an efficient and secure way to backup data.  The data deduplication
+technique used makes Borg suitable for daily backups since only changes are
+stored.  The authenticated encryption technique makes it suitable for backups
+to not fully trusted targets.  Borg is a fork of Attic.")
+(home-page "https://borgbackup.github.io/borgbackup/";)
+(license license:bsd-3)))
-- 
2.7.3

Re: Removing compilers that cannot be bootstrapped

[Ludovic Courtès]

"Thompson, David"  skribis:

> Haskell, OCaml, Chicken, and other compilers that we package have a
> serious issue that many of us are aware of: they cannot be built from
> source!

(And GCC, but let’s put it aside for now.)

> They rely upon pre-built binaries of the same compiler.  I understand
> that it's very inconvenient to not have these compilers available to
> us, and all of the software that is written in their respective
> languages, but I feel like all of our work is undermined by making
> exceptions for them.  I would like to remove compilers that don't have
> a bunch of dependent packages yet such as Chicken until upstream fixes
> the issue.  But we have tons of Haskell packages and a handful of
> OCaml packages and it would be heartbreaking to some to remove all of
> that hard work.

I definitely sympathize with your concerns, and also in the case of
whole-distro bootstrapping.

However, removing things seems really harsh, and also sidestepping the
problem (not to mention that once we’d done that, we couldn’t ignore
GCC’s bootstrapping.)

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> A while back Mark raised the idea of hosting one pre-compiled bootstrap
> version of each such compiler, and use that to compile further versions.
>
> This way the number of blobs is one per such compiler, instead of one
> for every new version of each such compiler.
>
> It seemed like a good medium-term solution to me.  I'm not sure how it
> would be implemented.

I like the idea.

Often, in their implementation history, compilers are boostrapped from
something else initially, and only later to they become self-hosted and
unbootstrappable.

So in theory, it’d be possible to find, say, an old-enough GHC that only
requires a C compiler (?), and use that to build the next version and so
on, until we reach the latest version.  I suspect the same applies to
many compilers.

This is technically possible.  The main difficulty is to find what exact
chain of compiler versions will work, and then to make sure that the
super-old compilers can build.  The risk, as Andreas suggests, is that
maintaining those old versions will require dragging a whole graph of
old dependencies, recursively.

But really, we won’t know until we’ve actually tried ;-), and it’ll
be different for each compiler.

I would suggest that people pick a compiler they’re more or less
familiar with, and give it a try.  MIT/GNU Scheme might be a good start,
since we should be able to talk with the folks behind it and reach
mutual understanding.  ;-)

For GCC, an idea discussed at
 would
be to build GCC 4.7 (the last version written in plain C) with something
more auditable like TinyCC, and then use this g++ 4.7 to build whatever
GCC version we want.  Again, sounds like it should work, but we need to
actually try.

Thoughts?

BTW, the “good news” is that more and more compilers build upon LLVM,
and for those there’s no bootstrapping problem if we take the C++
compiler for granted.

Ludo’.

Re: [PATCH 5/6] gnu: Add borg.

[Leo Famulari]

On Mon, Mar 21, 2016 at 06:35:19PM -0400, Leo Famulari wrote:
> I asked upstream about some warnings during the docs generation, and
> they pointed out that I needed to add a command line. I've attached a
> revised patch.
> 
> Can I get some feedback on it?

Based on feedback on #guix, I've revised it again. Attached...
>From 5e43672e45e6b9bbe7c0ed0d954a44285e55b173 Mon Sep 17 00:00:00 2001
Message-Id: <5e43672e45e6b9bbe7c0ed0d954a44285e55b173.1458600724.git@famulari.name>
In-Reply-To: <90ce1642eb4e527227b4c2bce25dcf25b484e22f.1458600724.git@famulari.name>
References: <90ce1642eb4e527227b4c2bce25dcf25b484e22f.1458600724.git@famulari.name>
From: Leo Famulari 
Date: Mon, 14 Mar 2016 19:34:25 -0400
Subject: [PATCH 5/6] gnu: Add borg.

* gnu/packages/backup.scm (borg): New variable.
---
 gnu/packages/backup.scm | 55 -
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index 4a69b7a..0993c76 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015 Eric Bavier 
 ;;; Copyright © 2014 Ian Denhardt 
-;;; Copyright © 2015 Leo Famulari 
+;;; Copyright © 2015, 2016 Leo Famulari 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -406,3 +406,56 @@ compression, and more.  The library itself implements storage techniques such
 as content-addressable storage, content hash keys, Merkle trees, similarity
 detection, and lossless compression.")
 (license license:gpl3+)))
+
+(define-public borg
+  (package
+(name "borg")
+(version "1.0.0")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "borgbackup" version))
+  (sha256
+   (base32
+"0wa6cvqs3rni5nwrgagigchcly8a53rxk56z0zn8iaii2cqrw2sh"
+(build-system python-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'set-env
+   (lambda* (#:key inputs #:allow-other-keys)
+ (let ((openssl (assoc-ref inputs "openssl"))
+   (lz4 (assoc-ref inputs "lz4")))
+   (setenv "BORG_OPENSSL_PREFIX" openssl)
+   (setenv "BORG_LZ4_PREFIX" lz4)
+   (setenv "PYTHON_EGG_CACHE" "/tmp")
+ #t)))
+ (add-after 'install 'docs
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(man (string-append out "/share/man/man1")))
+   (and
+ (zero? (system* "python3" "setup.py" "build_ext" "--inplace"))
+ (zero? (system* "make" "-C" "docs" "man"))
+ (begin
+   (install-file "docs/_build/man/borg.1" man)
+   #t
+(native-inputs
+ `(("python-setuptools-scm" ,python-setuptools-scm)
+   ;; For generating the documentation.
+   ("python-sphinx" ,python-sphinx)
+   ("python-sphinx-rtd-theme" ,python-sphinx-rtd-theme)))
+(inputs
+ `(("acl" ,acl)
+   ("lz4" ,lz4)
+   ("openssl" ,openssl)
+   ("python-llfuse" ,python-llfuse)
+   ("python-msgpack" ,python-msgpack)))
+(synopsis "Deduplicated, encrypted, authenticated and compressed backups")
+(description "Borg is a deduplicating backup program.  Optionally, it
+supports compression and authenticated encryption.  The main goal of Borg is to
+provide an efficient and secure way to backup data.  The data deduplication
+technique used makes Borg suitable for daily backups since only changes are
+stored.  The authenticated encryption technique makes it suitable for backups
+to not fully trusted targets.  Borg is a fork of Attic.")
+(home-page "https://borgbackup.github.io/borgbackup/";)
+(license license:bsd-3)))
-- 
2.7.3

security-updates merged

[Ludovic Courtès]

Hello!

I’ve just merged ‘security-updates’ into ‘master’.  There are no new
security fixes in there, only the integration of fixes that used to be
available via grafting.

Ludo’.

Re: [GSoC] Porting GuixSD to GNU Hurd draft

[Samuel Thibault]

Hello,

Manolis Ragkousis, on Mon 21 Mar 2016 14:09:36 +0200, wrote:
> Although I have uploaded and shared my draft to the GSoC website, I am
> also resending it to the lists as per Ludovic's instruction.

Looks very promising :)

Samuel

Re: Removing compilers that cannot be bootstrapped

[rain1]

On 2016-03-21 17:54, Thompson, David wrote:

Haskell, OCaml, Chicken, and other compilers that we package have a
serious issue that many of us are aware of: they cannot be built from
source!  They rely upon pre-built binaries of the same compiler.  I
understand that it's very inconvenient to not have these compilers
available to us, and all of the software that is written in their
respective languages, but I feel like all of our work is undermined by
making exceptions for them.  I would like to remove compilers that
don't have a bunch of dependent packages yet such as Chicken until
upstream fixes the issue.  But we have tons of Haskell packages and a
handful of OCaml packages and it would be heartbreaking to some to
remove all of that hard work.

What can we possibly do to avoid being yet another distro that relies
on a bunch of blobs (leaving the *true* bootstrap binaries out of it
for now)?

- Dave


I would like to propose one idea to manage this: What about adding a 
field to the system configuration for a list of 'trusted-binaries'?


guix requires gcc binaries (and some other things) to bootstrap off so 
these things are all implicitly trusted binaries. My suggestion is to 
make that list explicit and allow people to add things like the ocaml 
compiler to it.


Trying to install the ocaml compiler could give an error about an 
untrusted binary unless the user has added that to their system 
configuration.