Re: [PATCH] gnu: Add gnome.

[Thompson, David]

On Fri, Feb 12, 2016 at 11:33 PM, 宋文武  wrote:
> * gnu/packages/gnome.scm (gnome): New variable.
> ---
>  gnu/packages/gnome.scm | 41 +
>  1 file changed, 41 insertions(+)

This is awesome!  I'm reconfiguring my system now to see how it all works. :)

- Dave

[PATCH] gnu: guile-next: Set correct native search paths.

[Thompson, David]

I've started building my own projects with Guile 2.1.2 and I noticed
that the search paths needed adjustment in order to find modules.

- Dave
From 7b26acb50b60a68b1c64ff38a663212e03b0bb7d Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sat, 13 Feb 2016 00:08:22 -0500
Subject: [PATCH] gnu: guile-next: Set correct native search paths.

* gnu/packages/guile.scm (guile-next): Use the "2.2" directory for the
  load paths.
---
 gnu/packages/guile.scm | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index e6e7228..11d9da1 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -210,7 +210,15 @@ without requiring the source code to be rewritten.")
   ;; times (almost 3 hours on a 4-core Intel i5).
   (snippet '(for-each delete-file
   (find-files "prebuilt" "\\.go$")
-(synopsis "Snapshot of what will become version 2.2 of GNU Guile")))
+(synopsis "Snapshot of what will become version 2.2 of GNU Guile")
+(native-search-paths
+ (list (search-path-specification
+(variable "GUILE_LOAD_PATH")
+(files '("share/guile/site/2.2")))
+   (search-path-specification
+(variable "GUILE_LOAD_COMPILED_PATH")
+(files '("lib/guile/2.0/ccache"
+ "share/guile/site/2.2")))
 
 (define-public guile-for-guile-emacs
   (package (inherit guile-next)
-- 
2.5.0

Re: gnu: Add python-wtforms.

[Thompson, David]

This looks good, Chris!  I can tell by looking at the diff that it's
based on the wip-mediagoblin.  If it cleanly applies on master then I
say "push"!

- Dave

Re: [PATCH] Add and use sqlite-legacy-for-python

[Thompson, David]

On Fri, Feb 12, 2016 at 7:13 PM, Christopher Allan Webber
 wrote:
> Ludovic Courtès writes:
>
>> Pjotr Prins  skribis:
>>
>>> Patch b24765139c8940541b23f84592d3580d53f71d71
>>>
>>>  (define-public sqlite
>>>(package
>>> (name "sqlite")
>>> -   (version "3.8.11.1")
>>> +   (version "3.10.0")
>>> (source (origin
>>>
>>> is the cause of python(2|3)-sqlalchemy breaking. I confirmed that by
>>> regressing to the original sqlite package. Since the python binding is
>>> part of the interpreter, I suspect there may be more python modules
>>> vulnerable. I updated python-sqlalchemy to latest and that makes no
>>> difference. Its tests fail on sqlite 3.10.0 and pass on 3.8.11.1.
>>>
>>> What do we do? Revert on this sqlite patch for the new guix release?
>>> Or add a second sqlite package and have that as a python dependency?
>>
>> I would do the latter, assuming that soon a new python-sqlalchemy
>> release would solve the problem.  WDYT?
>>
>> This is probably OK since python-sqlalchemy is a leaf, and so we’re
>> unlikely to end up mixing two different SQLite versions.
>>
>> Ludo’.
>
> Will sqlalchemy really remain a leaf node?  I hope not, since I'm
> working on packaging MediaGoblin now :)

Yeah, sqlalchemy being a leaf node is accidental.  It's a library that
will be depended on by MediaGoblin and maybe other software.

> Regardless, I agree that the second approach seems to be the right one.
> I've built a modified package, sqlite-legacy-for-python, and put it to
> use.  I built it and confirmed it builds fine and that the tests pass,
> and with it, the tests pass in python-sqlalchemy too.

I'm concerned about this.  What exactly is being used here, a client
library?  If so, it means that we may have an issue when a python
application uses a library that wants to dynamically link against both
the normal sqlite library and this older version.  Maybe this is still
fine, but proceed with caution.

- Dave

Re: Problem with pkgconfig source https redirect

[Thompson, David]

On Wed, Feb 10, 2016 at 2:43 AM, Efraim Flashner  wrote:
> On Tue, 09 Feb 2016 20:56:59 -0600
> Christopher W Carpenter  wrote:
>
>> Talked about this on IRC davexunit, but there appears to be a circular 
>> dependency
>> issue with gnutls and pkg-config now that pkg-config needs to be
>> downloaded via https.
>>
> [snip]
>>
>> davexunit on #guix mentioned that this may need to be solved using a
>> minimal build of gnutls that doesn't require pkg-config for https
>> downloads but i'm a bit out of my depth here so I'm just reporting :).
>>
>> I am happy to do some grunt work once the project decides what direction
>> to go.
>>
>> Thanks,
>> Christopher Carpenter
>>
>
> Another option is to try to build gnutls without pkg-config and as part of
> the configure phase manually tell it where to find the dependencies. IIRC we
> do that with some of the less complicated lower level packages.

The bigger problem to be aware of is this:  No package in the gnutls
dependency graph may have its source code downloaded over HTTPS.  Even
if we hack around this for pkg-config, I'm sure it will bite us again
when another upstream starts enforcing HTTPS.

So, what can we do here?

- Dave

Re: GSoC ideas

[Thompson, David]

On Mon, Feb 8, 2016 at 12:24 PM, Christopher Allan Webber
 wrote:
> What I'm talking about is Guix *as a package
> manager* to be able to be available on foreigh distros so I can
> encourage friends to do:
>
>   apt-get install guix
>
> ... and then do user-space hacking with Guix, and use "guix environment"
> for hacking on my projects...  I think we'd increase our userbase
> dramatically by getting Guix as a user-space pacakge manager into
> various distros.

Such packages would be convenient for users of these distros, but
getting them into Debian and Fedora proper is unlikely because Guix
does not conform to the FHS.

- Dave

Re: [PATCH] gnu: Add gtk-engines and murrine.

[Thompson, David]

Hi Fabian,

These look good!  Could you split them up into 2 patches so that only
1 package is added in each patch?  Thanks!

- Dave

Re: [PATCHES] Add awscli and 7 pre-requisite Python libraries.

[Thompson, David]

On Mon, Feb 1, 2016 at 5:28 PM, Ludovic Courtès  wrote:
> Dave Thompson  skribis:
>
>> Here's a patch set I've been sitting on for awhile for the AWS CLI.  Do
>> note that the AWS APIs are not exclusive to Amazon.  Free software such
>> as Eucalyptus [0] and OpenStack also implement these APIs for
>> compatibility reasons, and both the boto library and awscli itself can
>> be used to manipulate them.
>
> I think it’s OK to include AWS clients.  After all, AWS is essentially a
> “hosting service”, it’s not SaaSS or anything directly conflicting with
> our goals and the GNU FSDG.

Thanks for the clarification!  Much appreciated.

>> If this proves too controversial, I'd still like to apply the first 6
>> uncontroversial patches. ;)
>
> Nothing to add to what Efraim already said.  Except that, now that Tox
> gets in, you’ll have to add Guix-Tox.  ;-)

:)

Efraim, I incorporated most of your suggestions, but the Tox test
suite remains disabled with a "FIXME" above it because it requires a
more recent version of pytest than we have, but upgrading the existing
pytest package causes breakage.  That's a task for another day!

Pushed everything, sans the redundant python-wheel patch.  Thanks!

- Dave

Fixing package-with-python2 (was: Package transformations)

[Thompson, David]

On Mon, Feb 1, 2016 at 8:06 AM, Efraim Flashner  wrote:

> I looked over the commit but not deeply enough yet, would it be possible to
> use some of the logic in this to fix the package-with-python2 issue?

Here's a potential solution for 'package-with-python2': module
introspection.  AIUI, the issue is that some Python 2 packages need
extra manual tweaking, but 'package-with-python2' creates package
variants without these tweaks. Our algorithm could look up
'python2-foo' in (gnu packages python) and use that package object, if
it exists.  This would stop the recursive transformation for that
branch of the dependency graph and allow us to tweak Python 2 variants
as needed without fear.

Also, somewhat unrelated, package-with-python2 could add setuptools as
an input to these packages so we can remove all the unnecessary usage
of it in Python 3 packages.

Thoughts?

- Dave

Re: Fixing package-with-python2 (was: Package transformations)

[Thompson, David]

On Mon, Feb 1, 2016 at 11:35 AM, Efraim Flashner  wrote:

> Not all of our python packages are in python.scm. Currently in
> guix/build-system/python.scm we have:
>
> (define package-with-python2
>   ;; Note: delay call to 'default-python2' until after the 'arguments' field
>   ;; of packages is accessed to avoid a circular dependency when evaluating
>   ;; the top-level of (gnu packages python).
>   (package-with-explicit-python (delay (default-python2))
> "python-" "python2-"))
>
> Excuse the code, but I think we're looking for something like:
>
> (define package-with-python2
>   (if (exists? python2-foo)
> (python2-foo)
> (package-with-explicit-python (delay (default-python2))
>   "python-" "python2-"))

I believe you just said the same thing I said.  We're on the same page.

- Dave

Re: [PATCHES] Add Aseprite and Allegro 4

[Thompson, David]

On Fri, Jan 29, 2016 at 5:20 PM, Eric Bavier  wrote:
> On 2016-01-29 16:01, David Thompson wrote:
>>
>> I found out about a really neat little pixel art editing tool called
>> Aseprite, so I packaged it!
>
>
> All LGTM.

Pushed, thanks!

- Dave

Re: [PATCH 04/13] utils: Use '@' for separating package names and version numbers.

[Thompson, David]

On Sun, Jan 24, 2016 at 3:19 PM, Mathieu Lirzin  wrote:
>
> Fixes .
>
> * guix/build/utils.scm (package-name->name+version): Use '@' for
> separating package names and version numbers instead of '-'.  This
> provides the ability to use numbers in package names.
> * guix/packages.scm (package-full-name): Add an optional SEPARATOR
> argument defaulting to "@".
> * doc/guix.texi (Invoking guix package, Invoking guix import): Adapt to
> the new syntax.
> * guix/ui.scm (package-specification->name+version+output): Likewise.
> * guix/scripts/import/hackage.scm (show-help): Likewise.
> * gnu/packages.scm (check-package-freshness, specification->package)
> (specification->package+output): Likewise.
> * emacs/guix-base.scm (guix-package-name-specification): Likewise.
> * emacs/guix-main.scm (full-name->name+version)
> (name+version->full-name): Likewise.
> * tests/guix-build.sh: Likewise.
> * tests/guix-lint.sh: Likewise.
> * tests/guix-package.sh: Likewise.
> * tests/packages.scm: Likewise.
> * tests/ui.scm: Likewise.
> * tests/utils.scm: Likewise.
> * tests/graph.scm ("bag-emerged DAG"): Use 'package-full-name' optional
> SEPARATOR argument.
> * gnu/packages/commencement.scm (gcc-boot0): Likewise.
> * NEWS: Mention new syntax.
> ---
>  NEWS| 13 +
>  doc/guix.texi   | 12 ++--
>  emacs/guix-base.el  |  2 +-
>  emacs/guix-main.scm |  4 ++--
>  gnu/packages.scm| 10 +-
>  gnu/packages/commencement.scm   |  2 +-
>  guix/build/utils.scm| 25 +++--
>  guix/packages.scm   |  9 ++---
>  guix/scripts/import/hackage.scm |  2 +-
>  guix/ui.scm |  4 ++--
>  tests/graph.scm |  2 +-
>  tests/guix-build.sh |  4 ++--
>  tests/guix-lint.sh  |  2 +-
>  tests/guix-package.sh   |  4 ++--
>  tests/ui.scm|  6 +++---
>  tests/utils.scm |  4 ++--
>  16 files changed, 55 insertions(+), 50 deletions(-)

Does the fact that so many files needed to be edited indicate the need
for a single specification string constructor?  If this had already
been the case, then this patch would have only needed to change 1 or 2
procedures.

That's not to say that this isn't great work!  I just think that we
could ease the maintenance burden with some refactoring.

- Dave

Re: Add "guix update" command

[Thompson, David]

Hi Fabian,

This isn't the first time I've seen such a proposal, and while I
appreciate the viewpoint, I don't think this would be a good decision
for Guix and I'm fairly sure that the other developers agree.  See
below for further explanation.

On Sat, Jan 23, 2016 at 1:11 PM, Fabian Harfert  wrote:
> Hello,
>
> on IRC I already mentioned that, but there wasn't much resonance: I
> think for the purposes of non-developers the behavior of the "guix
> pull" command is too complicated.
>
> Normal users don't need a development version of the package manager,
> when they just want to get the newest package definitions to update
> their installed software. So it would be much easier and faster if
> there was a separate repository just containing the most recent package
> definitions.

In Guix, we purposely do not distinguish between a user and a
developer because we believe there is no distinction.  We think the
perceived line between user and developer should be blurred.  Everyone
should be enabled to hack on Guix, and introducing things that
differentiate developers from "regular users" is counter-productive to
our goal.

> I propose to add a new command line option - e.g. "guix update" -
> fetching these latest package definitions and not doing anything else.
> They could be contained by a package whose definition is downloaded,
> for example "guix-packages".
>
> To avoid compatibility issues when there's a new release of Guix itself
> this package must be versioned equal to the Guix version numbers. I'm
> thinking of the following:
>
>   The user is running Guix 1.2.1 and has installed the package
>   guix-packages-1.2.1-4 containing the package definitions. Now he runs
>   "guix update" and fetches guix-packages-1.2.1-5 with the new package
>   definitions including the new Guix release 1.2.2. He now updates Guix
>   to this version which has the new guix-packages-1.2.2-0 as an input.
>   When he runs "guix update" again, guix-packages-1.2.2-1 is installed,
>   which contains package definitions that make use of some new features.

This additional complexity is one of the reasons why packages are not
maintained separately from everything else.  We know exactly what the
outcome of such a scheme would look like because this is what Nix
does.  Nix, the package manager, exists separately from nixpkgs, which
contains all the package recipes.  This was deliberately avoided when
the Guix project was started to avoid compatibility issues.

By maintaining the packages separately from Guix itself, we must turn
internal APIs into external APIs and become very concerned with
backwards compatibility.  We follow an approach similar to Linux.  In
Linux, kernel modules are maintained in the same source tree as the
kernel itself.  The reason for this is it allows the kernel developers
to introduce changes to internal APIs and update *all* of the modules
affected, together.  This greatly simplifies maintenance and the
ability to improve the software without introducing compatibility
issues.  Being able to break internal APIs when needed is something we
simply could not afford to give up, at least not at this stage in
Guix's development.

Another reason is simply practical.  Having patch sets that span
multiple repositories is cumbersome.  I know this all too well because
I work at a company that has a lot of repository proliferation.  It's
not uncommon for a new feature to span 3 Git repos, and keep
everything in order is a pain.

> This would just be for the time between the Guix releases. I think we
> don't need support for older versions of Guix except from keeping the
> last guix-packages package, but we could also do some security
> or minor updates to the older package definitions which would provide
> users the possibility to use GuixSD as a stable distribution like
> Debian.

A stable version of Guix would be nothing more (or less) than a branch
in Git that received only critical security updates.

> Another advantage of the separation between Guix itself and the package
> definitions is that it's easy to provide an own or foreign
> guix-packages package which would promote the decentralization of Guix.

This point is moot because it's already easy to include other package
recipes via the GUIX_PACKAGE_PATH environment variable.  See:
https://gnu.org/software/guix/manual/html_node/Package-Modules.html#Package-Modules

> Initially I thought of doing the same for service definitions except
> from the basic ones. But I think that version compatibility problems
> would occur more often because service definitions are at a lower level
> than the package definitions. In addition the notorious normal users
> won't change so much of their service definitions.

Services are at a higher level, actually.  Services often use package
objects in the g-expressions that define the service configuration.
This is a good example of why Guix is a unified whole, and separating
packages from the rest would only leads to 

Re: Composing service definitions (and maybe fmt)

[Thompson, David]

On Wed, Jan 20, 2016 at 5:13 PM, Ludovic Courtès  wrote:

> To me, the question is more about choosing between writing configuration
> file bindings and exposing upstream’s configuration file syntax, as was
> discussed when Andy posted the Dovecot service.  (To which I don’t have
> a better answer than: let’s see on a case-by-case basis.)

How about this:

Procedures that return services should accept file-like objects when
configuration files are needed.  When it makes sense (like with
elogind, dovecot, etc.), we can provide special procedures that take a
Scheme data structure and "compile" that to a file-like object in the
service's native configuration language.  This way, we allow ourselves
to have the high-level Scheme configuration APIs we like while also
allowing the use of "raw" configuration files in situations where it
is unavoidable or the path of least resistance.

- Dave

Re: [PATCHES] Add v4l-utils in order to add support for webcams to OBS

[Thompson, David]

On Wed, Jan 20, 2016 at 5:08 AM, Andreas Enge <andr...@enge.fr> wrote:
> Tiny typo in a comment:
>
> On Tue, Jan 19, 2016 at 10:17:47PM -0500, Thompson, David wrote:
>> +;; libv4l2 is LGPL2.1+, while utilties are GPL2 only.
> "util_i_ties"

Thanks.  Fixed and pushed.

- Dave

[PATCHES] Add v4l-utils in order to add support for webcams to OBS

[Thompson, David]

These patches scratch a particularly timely itch.  I want to use
OpenBroadcaster to record my talk tomorrow, but recording video from a
webcam requires libv4l.

(Sorry that these are likely not inline attachments.  I'm dealing with
a less-than-ideal email setup right now.)

Thanks in advance for review!

- Dave
From b1ccba1616dc77950b8495714a47d5e3f9b9eda1 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Tue, 19 Jan 2016 22:11:16 -0500
Subject: [PATCH 1/2] gnu: Add v4l-utils.

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

diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
index 9e41835..c135770 100644
--- a/gnu/packages/video.scm
+++ b/gnu/packages/video.scm
@@ -1265,6 +1265,39 @@ functionality of the system is provided via an assortment of ready to use
 tools, XML authoring components, and an extensible plug-in based API.")
 (license license:lgpl2.1+)))
 
+(define-public v4l-utils
+  (package
+(name "v4l-utils")
+(version "1.8.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://linuxtv.org/downloads/v4l-utils;
+  "/v4l-utils-" version ".tar.bz2"))
+  (sha256
+   (base32
+"0cqv8drw0z0kfmz4f50a8kzbrz6vbj6j6q78030hgshr7yq1jqig"
+(build-system gnu-build-system)
+(arguments
+ '(#:configure-flags
+   (list (string-append "--with-udevdir="
+(assoc-ref %outputs "out")
+"/lib/udev"
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("alsa-lib" ,alsa-lib)
+   ("glu" ,glu)
+   ("libjpeg" ,libjpeg)
+   ("libx11" ,libx11)
+   ("qt" ,qt)
+   ("eudev" ,eudev)))
+(synopsis "Realtime video capture utilities for Linux")
+(description "The v4l-utils provide a series of libraries and utilities to
+be used for realtime video capture via Linux-specific APIs.")
+(home-page "https://linuxtv.org/wiki/index.php/V4l-utils;)
+;; libv4l2 is LGPL2.1+, while utilties are GPL2 only.
+(license (list license:lgpl2.1+ license:gpl2
+
 (define-public obs
   (package
 (name "obs")
-- 
2.5.0

From 00ad398215837b64daf577024511330c1f73ce6a Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Tue, 19 Jan 2016 22:11:35 -0500
Subject: [PATCH 2/2] gnu: obs: Add support for webcams.

* gnu/packages/video.scm (obs)[inputs]: Add v4l-utils.
---
 gnu/packages/video.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
index c135770..4939194 100644
--- a/gnu/packages/video.scm
+++ b/gnu/packages/video.scm
@@ -1326,6 +1326,7 @@ be used for realtime video capture via Linux-specific APIs.")
("mesa" ,mesa)
("pulseaudio" ,pulseaudio)
("qt" ,qt)
+   ("v4l-utils" ,v4l-utils)
("zlib" ,zlib)))
 (synopsis "Live streaming software")
 (description "Open Broadcaster Software provides a graphical interface for
-- 
2.5.0

[PATCHES] Add docker-compose and missing prerequisites.

[Thompson, David]

Hello Guix hackers,

As much as I dislike it, the company I work for has started to use
Docker.  Docker Compose is a special Python program that talks to the
Docker daemon to run many containers at once using configuration from
a "declarative" YAML file (my kingdom for an sexp), and I didn't want
to use pip to install it.  So, here's 8 patches that add it and the
stuff that was missing for it.

I hear someone has a working Go package that hasn't been submitted
yet, so maybe we'll have Docker itself available someday.  That will
be interesting. :)

TIA for review.

- Dave
From 29aa112adc961c806a56e03c9031c1385ad29f37 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:24:30 -0500
Subject: [PATCH 1/8] gnu: Add version 2.7 variant of python-requests.

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 4ab1eed..5f6ac79 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -2182,6 +2182,18 @@ compatible install in a way that is very close to the on-disk format.")
 than Python’s urllib2 library.")
 (license asl2.0)))
 
+;; Some software requires an older version of Requests, notably Docker
+;; Compose.
+(define-public python-requests-2.7
+  (package (inherit python-requests)
+(version "2.7.0")
+(source (origin
+ (method url-fetch)
+ (uri (pypi-uri "requests" version))
+ (sha256
+  (base32
+   "0gdr9dxm24amxpbyqpbh3lbwxc2i42hnqv50sigx568qssv3v2ir"))
+
 (define-public python2-requests
   (package-with-python2 python-requests))
 
-- 
2.6.3

From 41af50a9a40a7668e1069cf3a94c58c73dc50452 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:26:07 -0500
Subject: [PATCH 2/8] gnu: Add python-vcversioner.

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 5f6ac79..91629e8 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -2197,6 +2197,30 @@ than Python’s urllib2 library.")
 (define-public python2-requests
   (package-with-python2 python-requests))
 
+(define-public python-vcversioner
+  (package
+(name "python-vcversioner")
+(version "2.14.0.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "vcversioner" version))
+   (sha256
+(base32
+ "11ivq1bm7v0yb4nsfbv9m7g7lyjn112gbvpjnjz8nv1fx633dm5c"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(synopsis "Python library for version number discovery")
+(description "Vcversioner is a Python library that inspects tagging
+information in a variety of version control systems in order to discover
+version numbers.")
+(home-page "https://github.com/habnabit/vcversioner;)
+(license isc)))
+
+(define-public python2-vcversioner
+  (package-with-python2 python-vcversioner))
+
 (define-public python-jsonschema
   (package
 (name "python-jsonschema")
-- 
2.6.3

From 4609db7c4569b047f8357133dafacf3a3a418032 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:26:47 -0500
Subject: [PATCH 3/8] gnu: Update python-jsonschema to 2.5.1.

* gnu/packages/python.scm (python-jsonschema): Update to 2.5.1.
---
 gnu/packages/python.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 91629e8..e1009cc 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -2224,7 +2224,7 @@ version numbers.")
 (define-public python-jsonschema
   (package
 (name "python-jsonschema")
-(version "2.4.0")
+(version "2.5.1")
 (source (origin
  (method url-fetch)
  (uri
@@ -2233,10 +2233,11 @@ version numbers.")
version ".tar.gz"))
  (sha256
   (base32
-   "1yik3031ziygvq66rj3mzfqdgxj29sg1bkfc46wsgi7lnbqs560j"
+   "0hddbqjm4jq63y8jf44nswina1crjs16l9snb6m3vvgyg31klrrn"
 (build-system python-build-system)
 (inputs
- `(("python-setuptools" ,python-setuptools)))
+ `(("python-setuptools" ,python-setuptools)
+   ("python-vcversioner" ,python-vcversioner)))
 (home-page "http://github.com/Julian/jsonschema;)
 (synopsis "Implementation of JSON Schema for Python")
 (description
-- 
2.6.3

From 43b8e05406a62d0b201df9aac7c6bcc9ea74a92f Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 11 Jan 2016 13:27:31 -0500
Subject: [PATCH 4/8] gnu: Add python-texttable.

* gnu/packages/python.scm 

Re: Guix as a Guile package manager

[Thompson, David]

On Sat, Jan 9, 2016 at 5:35 AM, Fabio Pesari  wrote:
> Package managers have been immensely successful in increasing the
> popularity of programming languages - think about Perl's CPAN or Ruby's
> Gem. But Guile doesn't a package manager, and that in my opinion slows
> down its adoption.

Many of us in the Guile community, including myself, are not very
interested in language-specific package managers because they are
problematic:

- They put burden on the user to make sure the right toolchain is
  available to build/install things (GCC and co.)

- They cannot describe the full dependency graph for things that
  aren't completely written in that language or use a foreign-function
  interface (for example, a Guile library that talks to a C library
  via the dynamic FFI, or one that uses the Guile C API)

- They encourage new users to conflate the build system with the
  package manager, leading to software that cannot be built without a
  network connection and a specific package manager.  Java software is
  notorious for this, as are Ruby and Python to a lesser degree.

That said, I see the desire to have a tool for easily sharing pure
Guile modules.

> The Guix repos distribute a lot of useful Guile libraries (like
> guile-json or guile-opengl) which can't be found on most distro
> repositories and it already provides Guile APIs and package management
> capabilities...my question is, can Guix be forked into a full-blown
> Guile package manager like gem from Ruby?

You can install Guix right now and use it to help you develop with
Guile, or any other language.  I use it for all of my Guile projects
and it works great.

> I know that an argument could be made that Guix can already be used in
> this way, but there are many Scheme coders who don't need a system-wide
> package manager and would rather use a program that can manage Guile
> packages under a user root like ~/.guile and allow them to easily
> distribute their packages (something like Python's virtualenvs would
> also be useful).

This is what the Guildhall[0] is for, but it needs some love.  I
really do not encourage the use of language-specific package managers
for the above-mentioned problems, but if you *really* want that,
contributing to the Guildhall seems to be the best thing to do.
People ask about it somewhat frequently, but so far no one has seemed
willing to roll up their sleeves and make it work for them.

> Perhaps some of the Guix code can be moved to a library, so that both
> the Guix and the Guile package manager binaries can reuse the same code.
> Moving Guix' core to a library would also facilitate its inclusion in
> things like PackageKit, as well as make it easier to create front-ends.

This would be a bad idea, because it creates a divide between the Guix
core and the rest of Guix, which would force us to make currently
internal APIs into external, public APIs and worry about backwards
compatibility and other issues.  Our development of Guix models that
of Linux.  In Linux, the kernel is maintained in conjuction with the
kernel modules, in the same source tree.  In Guix, the core modules
are maintained in conjunction with the user interfaces and package
recipes, in the same source tree.  Thus, if we change the packaging
API, or something else, we can update the relevant code in the source
tree and be done with it.  We don't have to worry about breaking
compatibility with an older version of libguix or something.  This was
a deliberate decision made to deal with problems that the Nix
community have when their version of Nix doesn't work with their
version of nixpkgs.

On the topic of PackageKit, it's been discussed in the past, but
PackageKit is incompatible with functional package managers because it
does not support important features like unprivileged package
management. [1]

> I'm not a package management expert so I'm not sure this idea is
> feasible but I would really like Guile to become more
> popular, and this I think would be a step in the right direction.

I don't think Guix is a good fit here, because there's simply no way
around the fact that Guix packages *must* contain the full dependency
graph for build-time and runtime dependencies.  There's no way that
you could use, say, the Guile or GCC from your host system because
doing so invalidates the entire purpose and design of Guix.  Thus, a
Debian user that tried to use a Guile-specific package manager based
on Guix would be surprised when it starts compiling its own glibc,
GCC, Guile, etc.  So, I don't see anything worth extracting from Guix
to use to build a Guile-specific package manager.

I encourage you to hack on Guildhall to make it more usable for your
needs.

Happy hacking,

- Dave

[0] https://github.com/ijp/guildhall
[1] https://lists.gnu.org/archive/html/bug-guix/2014-03/msg00018.html

Re: Ruby security updates

[Thompson, David]

On Fri, Jan 8, 2016 at 6:48 PM, Mark H Weaver  wrote:
> Some of our ruby versions may need security updates.
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1248935
>
> Can someone who cares about ruby please investigate?

This particular issue is definitely fixed in Ruby 2.2.4 or later,
which we upgraded very recently in response to this.

Now, I suspect Pjotr will find issue with this, but I think we really
should drop the Ruby 1.8.7 package because it is end-of-life and will
*not* receive bug fixes or security updates.

Thoughts?

- Dave

Re: [PATCH] Help Ruby packages be reproducible

[Thompson, David]

On Wed, Jan 6, 2016 at 6:46 AM, Ricardo Wurmus
 wrote:
>
> Ben Woodcroft  writes:
>
>> On 02/01/16 01:10, Ludovic Courtès wrote:
> [...]
>>> So I guess you (Ricardo?) can push it now.
> [...]
>> Thanks for pushing the patch.
>
> I did this just now.  Sorry for the delay.  Pushed as 7266848.  Thanks,
> Ben, for helping to make Ruby packages reproducible!

Just catching up on this conversation now.  Thanks, Ben!

- Dave

Re: Freezing core-updates soon

[Thompson, David]

On Sun, Jan 3, 2016 at 9:35 AM, Ludovic Courtès  wrote:
> Hi!
>
> I would like to declare ‘core-updates’ frozen in 1 or 2 days so we can
> have Hydra build it all and merge it afterwards.
>
> Thoughts?
>
> If there’s a big update you’d like to make (Python anyone?), now is
> the time!

I don't have the time to do it, but if anyone would like to bump Ruby
to 2.3.0 and keep the 2.2.4 version hanging around in another variable
like the other old versions, that would be cool. :)

Thanks,

- Dave

Re: web browser freedom issue

[Thompson, David]

On Sat, Dec 26, 2015 at 8:07 AM, Dika Setya Prayogi
 wrote:
> I saw the default GuixSD web browser the ''web'' in xfce include an
> non privacy oriented search engine. is that a restriction of freedom ?

GuixSD has no default web browser, because OS configs are completely
up to users to create.  Are you talking about GNU IceCat?  I don't see
a software freedom issue here, but it would be best to to send this
feedback directly to the GNU IceCat developers so that they can use
their knowledge of the domain to make an informed decision about this.

Thanks,

- Dave

Re: [PATCH 1/1] gnu: letsencrypt and acme: Update to 0.1.1.

[Thompson, David]

On Mon, Dec 21, 2015 at 2:17 PM, Leo Famulari  wrote:
> These packages should be updated together.
>
> * gnu/packages/tls.scm (letsencrypt): Update to 0.1.1.
> [source]: Use pypi-uri.
> * gnu/packages/tls.scm (acme): Update to 0.1.1.
> [source]: Use pypi-uri.
> ---
>  gnu/packages/tls.scm | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
> index e539686..5789534 100644
> --- a/gnu/packages/tls.scm
> +++ b/gnu/packages/tls.scm
> @@ -351,14 +351,13 @@ security, and applying best practice development 
> processes.")
>  (define-public acme
>(package
>  (name "acme")
> -(version "0.1.0")
> +(version "0.1.1")
>  (source (origin
>(method url-fetch)
> -  (uri (string-append 
> "https://pypi.python.org/packages/source/a/acme/acme-;
> -  version ".tar.gz"))
> +  (uri (pypi-uri "acme" version))
>(sha256
>  (base32
> -  "0fj0m04zzdxx23vazl00ilqyl3jxqq9c9p4x61pfz1zps7nbzsy3"
> + "1yv0gy8akaqp5p2wjpfj8r5i0da04a9qdmlh06rczdkrmk6q680w"
>  (build-system python-build-system)
>  (arguments
>   `(#:python ,python-2))
> @@ -384,14 +383,13 @@ security, and applying best practice development 
> processes.")
>  (define-public letsencrypt
>(package
>  (name "letsencrypt")
> -(version "0.1.0")
> +(version "0.1.1")
>  (source (origin
>(method url-fetch)
> -  (uri (string-append 
> "https://pypi.python.org/packages/source/l/;
> -  "letsencrypt/letsencrypt-" version 
> ".tar.gz"))
> +  (uri (pypi-uri "letsencrypt" version))
>(sha256
> (base32
> -"1zb96xz32k6ai41h5m1l22qi47y71dq69dcmbz7vfm6jfrhjgxl1"
> +"1kia3wk66lxyi2fghp9sd7cqgr5qiwdfayz153hi4wpa3q1q8rwf"
>  (build-system python-build-system)
>  (arguments
>   `(#:python ,python-2))
> --
> 2.6.2
>
>

LGTM, thanks!

Re: Create help-g...@gnu.org?

[Thompson, David]

On Mon, Dec 21, 2015 at 8:45 AM, Ludovic Courtès  wrote:
> Hello!
>
> Should we create a help-g...@gnu.org mailing list specifically to answer
> user questions?
>
> Until recently, the community was very small and users were also active
> developers, but we’re reaching the point where that may no longer be
> true (hey!).  People could ask for help on guix-devel@gnu.org, but some
> might be reluctant to doing that when they see that most messages relate
> to patch reviews and more or less intricate development topics.
>
> Thoughts?

Sounds good to me.

- Dave

Re: GNOME on GuixSD

[Thompson, David]

On Sun, Dec 20, 2015 at 7:50 AM, 宋文武  wrote:
> With commit a4df575, we can get a minimal gnome-shell on GuixSD.
>
> Make sure you have elogind and upower-daemon services running,
> and add the following packages:
>
>   adwaita-icon-theme, gnome-session, gnome-shell,
>   gnome-control-center, gnome-settings-daemon, dbus
>
> to the packages field (to use with the silm login manager) or
> user profile (then add 'exec gnome-session' to ~/.xsession).
>
> Please give suggestions :-)

I tried it and... it works! Awesome!

Now, we need the Gnome Tweak Tool so we can change "advanced" things
like the font size which is waaay too big by default.

Thanks for all the effort!  It's like I'm using a "normal" distro again!

 - Dave

Re: substitutes mirror of 0.9.0 packages

[Thompson, David]

On Fri, Dec 18, 2015 at 4:25 AM, Florian Paul Schmidt
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Hi,
>
> this service might go away anytime. But I setup a substitute server
> that is reachable at
>
> http://fps.io:
>
> The public key is:
>
> (public-key
>  (ecc
>   (curve Ed25519)
>   (q #AFF68C4E099401E85BE2D7375C1DB5E8A29F1DB83299038122AF5C0984099CF8#)
>   )
>  )
>
> It should have most of 0.9.0 packages and some random ones from other
> revisions.
>
> If it goes down, drop me an email, maybe I will be able to fix it,
> maybe not.

Thanks for sharing!

- Dave

Re: [PATCH] gnu: Add obs.

[Thompson, David]

On Thu, Dec 17, 2015 at 2:33 PM, Eric Bavier  wrote:
> On 2015-12-17 19:58, David Thompson wrote:
>>
>> * gnu/packages/video.scm (obs): New variable.
>
>
> LGTM.

Pushed, thanks!

Re: [PATCHES] Add sdl2-image, sdl2-mixer, and sdl2-ttf

[Thompson, David]

On Thu, Dec 17, 2015 at 5:18 PM, Ricardo Wurmus <rek...@elephly.net> wrote:
>
> Thompson, David <dthomps...@worcester.edu> writes:
>
>> From f0109ade56e024bf4ac0b6e1ac9ce3d0592964d1 Mon Sep 17 00:00:00 2001
>> From: David Thompson <dthomp...@vistahigherlearning.com>
>> Date: Tue, 15 Dec 2015 13:30:11 -0500
>> Subject: [PATCH 1/3] gnu: Add sdl2-image.
>
>> * gnu/packages/sdl.scm (propagated-inputs-with-sdl2): New procedure.
>>   (sdl2-image): New variable.
>
> Not sure, but I think the (new) rules are to not indent the parentheses
> on the second line.

Fixed.

>> +(define (propagated-inputs-with-sdl2 package)
>> +  (map (match-lambda
>> + (("sdl" _)
>> +  `("sdl2" ,sdl2))
>> + (other other))
>> +   (package-propagated-inputs package)))
>
> Is it really necessary to map over all inputs?  Aren’t you just
> replacing a single input with another?  Maybe a more generic procedure
> to replace a named input would be better?  (It probably doesn’t really
> matter much.)

It's not necessary to map once you've reached the element you need to
replace, but the inputs list is small so I didn't care to write the
more optimized version.

>> +(define-public sdl2-image
>> +  (package (inherit sdl-image)
>> +(name "sdl2-image")
>> +(version "2.0.0")
>> +(source (origin
>> +  (method url-fetch)
>> +  (uri
>> +   (string-append 
>> "http://www.libsdl.org/projects/SDL_image/release/SDL2_image-;
>> +  version ".tar.gz"))
>> +  (sha256
>> +   (base32
>> +"0d3jlhkmr0j5a2dd5h6y29jfcsj7mkl16wghm6n3nqqp7g3ib65j"
>> +(propagated-inputs
>> + (propagated-inputs-with-sdl2 sdl-image
>> +
>
> Looks good.
>
>> From 9c3d05c07c941e8031c583abb8acfe91fed11d12 Mon Sep 17 00:00:00 2001
>> From: David Thompson <dthomp...@vistahigherlearning.com>
>> Date: Tue, 15 Dec 2015 13:30:56 -0500
>> Subject: [PATCH 2/3] gnu: Add sdl2-mixer.
>
>> * gnu/packages/sdl.scm (sdl2-mixer): New variable.
>
> [...]
>
>> +(define-public sdl2-mixer
>> +  (package
>> +(inherit sdl-mixer)
>
> This is inconsistent with the previous expression.  Should ‘(inherit
> ...)’ be on the same line as ‘(package’ or not?

Yes.  Fixed.

>> +(name "sdl2-mixer")
>> +(version "2.0.0")
>> +(source (origin
>> +  (method url-fetch)
>> +  (uri
>> +   (string-append 
>> "http://www.libsdl.org/projects/SDL_mixer/release/SDL2_mixer-;
>> +  version ".tar.gz"))
>> +  (sha256
>> +   (base32
>> +"0nvjdxjchrajrn0jag877hdx9zb788hsd315zzg1lyck2wb0xkm8"
>> +(propagated-inputs
>> + (propagated-inputs-with-sdl2 sdl-mixer
>> +
>
> OK!
>
>> From b0473e355c8661d77e575580e08852efa0060f36 Mon Sep 17 00:00:00 2001
>> From: David Thompson <dthomp...@vistahigherlearning.com>
>> Date: Tue, 15 Dec 2015 13:31:32 -0500
>> Subject: [PATCH 3/3] gnu: Add sdl2-ttf.
>
>> * gnu/packages/sdl.scm (sdl2-ttf): New variable.
>
> [...]
>
>> +(define-public sdl2-ttf
>> +  (package
>> +(inherit sdl-ttf)
>
> Same as above.

Fixed.

>> +(name "sdl2-ttf")
>> +(version "2.0.12")
>> +(source (origin
>> + (method url-fetch)
>> + (uri
>> +  (string-append 
>> "http://www.libsdl.org/projects/SDL_ttf/release/SDL2_ttf-;
>> + version ".tar.gz"))
>> + (sha256
>> +  (base32
>> +   "0vkg6lyj278mdpd52map3rfi65fbq16w67ahmmfcl77a8da60a47"
>> +(propagated-inputs
>> + (propagated-inputs-with-sdl2 sdl-ttf
>> +
>
> Otherwise okay.
> Thank you!

Thanks for the feedback.  Fixed and pushed.

- Dave

Re: [PATCH 6/6] gnu: Add gnome-shell.

[Thompson, David]

On Wed, Dec 16, 2015 at 9:36 PM, 宋文武  wrote:
> * gnu/packages/gnome.scm (gnome-shell): New variable.

Woohoo!

- Dave

[PATCHES] Add sdl2-image, sdl2-mixer, and sdl2-ttf

[Thompson, David]

Packaged some more SDL2 stuff as I frantically try to prepare Sly for
the Lisp Game Jam in January.

- Dave
From f0109ade56e024bf4ac0b6e1ac9ce3d0592964d1 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Tue, 15 Dec 2015 13:30:11 -0500
Subject: [PATCH 1/3] gnu: Add sdl2-image.

* gnu/packages/sdl.scm (propagated-inputs-with-sdl2): New procedure.
  (sdl2-image): New variable.
---
 gnu/packages/sdl.scm | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/sdl.scm b/gnu/packages/sdl.scm
index 1b64be0..28213ef 100644
--- a/gnu/packages/sdl.scm
+++ b/gnu/packages/sdl.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013 David Thompson 
+;;; Copyright © 2013, 2015 David Thompson 
 ;;; Copyright © 2014 Mark H Weaver 
 ;;; Copyright © 2015 Sou Bunnbu 
 ;;; Copyright © 2015 Alex Kost 
@@ -20,6 +20,7 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (gnu packages sdl)
+  #:use-module (ice-9 match)
   #:use-module (gnu packages)
   #:use-module ((guix licenses) #:hide (freetype))
   #:use-module (guix packages)
@@ -299,6 +300,28 @@ directory.")
 (home-page (package-home-page sdl))
 (license (package-license sdl
 
+(define (propagated-inputs-with-sdl2 package)
+  (map (match-lambda
+ (("sdl" _)
+  `("sdl2" ,sdl2))
+ (other other))
+   (package-propagated-inputs package)))
+
+(define-public sdl2-image
+  (package (inherit sdl-image)
+(name "sdl2-image")
+(version "2.0.0")
+(source (origin
+  (method url-fetch)
+  (uri
+   (string-append "http://www.libsdl.org/projects/SDL_image/release/SDL2_image-;
+  version ".tar.gz"))
+  (sha256
+   (base32
+"0d3jlhkmr0j5a2dd5h6y29jfcsj7mkl16wghm6n3nqqp7g3ib65j"
+(propagated-inputs
+ (propagated-inputs-with-sdl2 sdl-image
+
 (define-public guile-sdl
   (package
 (name "guile-sdl")
-- 
2.5.0

From 9c3d05c07c941e8031c583abb8acfe91fed11d12 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Tue, 15 Dec 2015 13:30:56 -0500
Subject: [PATCH 2/3] gnu: Add sdl2-mixer.

* gnu/packages/sdl.scm (sdl2-mixer): New variable.
---
 gnu/packages/sdl.scm | 16 
 1 file changed, 16 insertions(+)

diff --git a/gnu/packages/sdl.scm b/gnu/packages/sdl.scm
index 28213ef..9857509 100644
--- a/gnu/packages/sdl.scm
+++ b/gnu/packages/sdl.scm
@@ -322,6 +322,22 @@ directory.")
 (propagated-inputs
  (propagated-inputs-with-sdl2 sdl-image
 
+(define-public sdl2-mixer
+  (package
+(inherit sdl-mixer)
+(name "sdl2-mixer")
+(version "2.0.0")
+(source (origin
+  (method url-fetch)
+  (uri
+   (string-append "http://www.libsdl.org/projects/SDL_mixer/release/SDL2_mixer-;
+  version ".tar.gz"))
+  (sha256
+   (base32
+"0nvjdxjchrajrn0jag877hdx9zb788hsd315zzg1lyck2wb0xkm8"
+(propagated-inputs
+ (propagated-inputs-with-sdl2 sdl-mixer
+
 (define-public guile-sdl
   (package
 (name "guile-sdl")
-- 
2.5.0

From b0473e355c8661d77e575580e08852efa0060f36 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Tue, 15 Dec 2015 13:31:32 -0500
Subject: [PATCH 3/3] gnu: Add sdl2-ttf.

* gnu/packages/sdl.scm (sdl2-ttf): New variable.
---
 gnu/packages/sdl.scm | 16 
 1 file changed, 16 insertions(+)

diff --git a/gnu/packages/sdl.scm b/gnu/packages/sdl.scm
index 9857509..d524abf 100644
--- a/gnu/packages/sdl.scm
+++ b/gnu/packages/sdl.scm
@@ -338,6 +338,22 @@ directory.")
 (propagated-inputs
  (propagated-inputs-with-sdl2 sdl-mixer
 
+(define-public sdl2-ttf
+  (package
+(inherit sdl-ttf)
+(name "sdl2-ttf")
+(version "2.0.12")
+(source (origin
+ (method url-fetch)
+ (uri
+  (string-append "http://www.libsdl.org/projects/SDL_ttf/release/SDL2_ttf-;
+ version ".tar.gz"))
+ (sha256
+  (base32
+   "0vkg6lyj278mdpd52map3rfi65fbq16w67ahmmfcl77a8da60a47"
+(propagated-inputs
+ (propagated-inputs-with-sdl2 sdl-ttf
+
 (define-public guile-sdl
   (package
 (name "guile-sdl")
-- 
2.5.0

Re: ‘local-file’ resolves relative to source file

[Thompson, David]

On Mon, Dec 14, 2015 at 1:59 PM, Ludovic Courtès  wrote:
> Hi!
>
> Commit 9d3994f changes ‘local-file’ to resolve relative file names
> relative to the form where ‘local-file’ appears.
>
> This means that you can use it in your OS config, and files will be
> looked up relative for your OS config file (instead of relative to
> $PWD), which is usually what one expects.
>
> Feedback welcome!

That's bitten me a few times and my attempt to fix it with
'source-filename' failed.  Thank you!

- Dave

Re: Short writeup on deterministic system configuration with GNU Guix

[Thompson, David]

On Fri, Dec 11, 2015 at 4:15 AM, Pjotr Prins  wrote:
> A short writeup on how Guix handles sudo:
>
>   https://github.com/pjotrp/guix-notes/blob/master/SYSCONFIG.org
>
> Comments?

Good stuff, Pjotr!  I'm going to share this.

- Dave

Re: [DMD] [PATCH] service: Change gid before uid when dropping privileges.

[Thompson, David]

On Sun, Dec 6, 2015 at 4:56 PM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Fri, Dec 4, 2015 at 3:00 AM, Ricardo Wurmus
>> <ricardo.wur...@mdc-berlin.de> wrote:
>>>
>>> David Thompson <dthomps...@worcester.edu> writes:
>>>
>>>> Found this little order of operations issue when trying to button up the
>>>> Transmission service.
>>>
>>> Looks fine to me.
>>
>> Thanks.  Now I need someone with commit access to dmd to apply it. :)
>
> Good point, should be fixed now!  (With the admin bit, even.  ;-))

Thank you, Ludo.

> Please take a look at the comments I made earlier.

Noted.  You just beat me to addressing them. :)

- Dave

Re: [DMD] [PATCH] service: Change gid before uid when dropping privileges.

[Thompson, David]

On Mon, Dec 7, 2015 at 8:22 AM, Thompson, David
<dthomps...@worcester.edu> wrote:
> On Sun, Dec 6, 2015 at 4:56 PM, Ludovic Courtès <l...@gnu.org> wrote:
>> "Thompson, David" <dthomps...@worcester.edu> skribis:
>>
>>> On Fri, Dec 4, 2015 at 3:00 AM, Ricardo Wurmus
>>> <ricardo.wur...@mdc-berlin.de> wrote:
>>>>
>>>> David Thompson <dthomps...@worcester.edu> writes:
>>>>
>>>>> Found this little order of operations issue when trying to button up the
>>>>> Transmission service.
>>>>
>>>> Looks fine to me.
>>>
>>> Thanks.  Now I need someone with commit access to dmd to apply it. :)
>>
>> Good point, should be fixed now!  (With the admin bit, even.  ;-))
>
> Thank you, Ludo.
>
>> Please take a look at the comments I made earlier.
>
> Noted.  You just beat me to addressing them. :)

Oh, nevermind.  I thought that you fixed my commit for me, but you
just gave me commit access.  ;)

Thanks!

- Dave

Re: [PATCH 00/23] WIP: Add the Let's Encrypt client

[Thompson, David]

I pushed all of the patches yesterday, and today I actually used
letsencrypt to generate certificates for my self-hosted web services.
I used 'letsencrypt certonly --webroot' so that I did not have any
server downtime while I generated the certs.  Works like a charm!

Thanks for all of the hard work, Leo!

- Dave

Re: [PATCH 00/23] WIP: Add the Let's Encrypt client

[Thompson, David]

Hi Leo,

On Tue, Nov 24, 2015 at 4:02 PM, Leo Famulari  wrote:
> These WIP patches provide the most recent developer preview of the Let's
> Encrypt [1] client and its dependencies.
>
> I am grateful to Dave Thompson for getting this patchset started. He
> packaged most of the python-3 Zope dependencies and cut the Gordian knot
> of circular dependency between zope.security and zope.component.
>
> The Let's Encrypt client will communicate with the Let's Encrypt servers
> and, if you are in their private beta progam, obtain valid SSL/TLS
> certificates that you can install on your server. If you are not in
> their private beta program, you can still test it and obtain certs
> issued by "happy hacker fake CA".
>
> On 2015-12-03, Let's Encrypt will open their beta program to the public
> [2].
>
> These patches probably need some work. The patch for
> python-configargparse is WIP due to a bug filed upstream. I have also
> committed the lets-encrypt patch as WIP as a warning.

I have cleaned up all of the commits in a local branch of mine that
I'm looking to push to master soon.

> I am specifically requesting review on the following subjects:
>
> 1) Are all the inputs categorized properly? That is, are they properly
> named as inputs, native-inputs, and propagated-inputs?

Pretty good overall.  I just cleaned up a few errors.  Currently
dealing with python-dialog so that we don't need to wrap the
letsencrypt binary.

> 2) Lint complains about the patch applied to the source of
> python-configobj because it doesn't include the name of
> python2-configobj. The patch applies to both language versions of
> python-configobj so I'm not sure how to handle this.

Don't worry about it.  The linter ought to be changed to account for
this python/python2 convention.

> 3) Please test the webserver integration. The client is supposed to be
> able to automatically configure Apache and Nginx with some plugins. I
> did not try this; I just let the client put the certs in
> /etc/letsencrypt (this is the default) and manually configured my
> webserver [3]

The package as it stands currently is not build with Apache support.
I'll look into adding the correct inputs for it.

> 4) I've included python-3 and python-2 versions of dependencies that
> support both versions, but I have packaged lets-encrypt itself as
> python-2. Many dependencies require extra inputs for python-2. You will
> see that I did not create separate packages for the python-2 versions,
> so the python-3 versions have some unecessary inputs. If requested, I
> can separate the python-2 packages out... or you can help with this. :)

Things overall look okay.  I've tweaked a couple of them.

Thanks for all the hard work!  We're almost there!

- Dave

Re: [DMD] [PATCH] service: Change gid before uid when dropping privileges.

[Thompson, David]

On Fri, Dec 4, 2015 at 3:00 AM, Ricardo Wurmus
 wrote:
>
> David Thompson  writes:
>
>> Found this little order of operations issue when trying to button up the
>> Transmission service.
>
> Looks fine to me.

Thanks.  Now I need someone with commit access to dmd to apply it. :)

- Dave

Re: proposal: add "packagers" field (list of strings (names)) to package definition

[Thompson, David]

On Wed, Dec 2, 2015 at 8:43 AM, Andy Wingo  wrote:
> On Tue 01 Dec 2015 08:12, Florian Paul Schmidt  writes:
>
>> ...and encourage its use. The intended semantics is to list people
>> that have contributed to the packaging effort. The motivation behind
>> this proposal is that in many free software projects attribution can
>> be a major source of motivation to get people involved. Having the
>> packagers be first class citizens in the package definitions (as
>> opposed to the information being only implicitly available through
>> e.g. "git blame") would allow things like "guix package" or the
>> package list on the website to display the contributor's names.
>
> Since you ask for opinions, -1 from me :)
>
> Currently Guix packages are more-or-less collectively owned.
> Introducing this field implies to me an introduction of ownership of
> packages.  Ownership has a number of negative effects: it can inhibit
> casual fixes and it can introduce unnecessary conflicts.
>
> The kind of ego-based positive feedback that having a maintainer field
> would introduce is negative IMO.  It is good if people feel attached to
> Guix-the-project and GuixSD-the-software-distribution, and to a degree
> they get that by copyright, git blame, and NEWS.  Feeling attached to a
> particular package is not as useful for the project or the distribution.

+1

- Dave

Re: [PATCHES] Add Kodi

[Thompson, David]

On Wed, Nov 25, 2015 at 8:38 AM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> This one was a real hairball, but here is a patch set that adds the Kodi
>> media center!  I hope that I've explained all the craziness relatively
>> well in the comments.
>
> Wow, quite an achievement!
>
>> From d708d0c36e202bbad7255c3b8a55ca0afdd18cb3 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Tue, 24 Nov 2015 13:35:44 -0500
>> Subject: [PATCH 1/3] gnu: Add tinyxml.
>>
>> * gnu/packages/xml.scm (tinyxml): New variable.
>> * gnu/packages/patches/tinyxml-use-stl.patch: New file.
>> * gnu-system.am (dist_patch_DATA): Add it.
>
> [...]
>
>> +From a53b6ee4519a7657164610ac14a82c57b1273bf6 Mon Sep 17 00:00:00 2001
>> +From: David Thompson 
>> +Date: Mon, 23 Nov 2015 06:54:36 -0500
>> +Subject: [PATCH] Use STL.
>
> Maybe just say why this is needed.

Sure.  I added an explanation.  Kodi, and presumably others, assume
that TinyXML was built with STL support on.

>> +   ;; Generate and install pkg-config file.
>> +   (mkdir-p pkgconfig)
>> +   (call-with-output-file (string-append pkgconfig 
>> "/tinyxml.pc")
>
> It’s OK to do that, but only if there are users that expect it (usually
> because a major distro has been doing it for some time.)  Maybe just add
> a something like “because Kodi expects it”, or “similar to what Debian
> does”.

Added a note along those lines.

>> From feb1a97e9d3c0e28ee265861bb34c90aa3e06265 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Mon, 16 Nov 2015 22:31:26 -0500
>> Subject: [PATCH 3/3] gnu: Add kodi.
>
> + commit log and copyright header.
>
>> + '(#:configure-flags '("--with-ffmpeg=shared") ; don't use bundled 
>> ffmpeg
>
> Would it be possible to delete the bundled ffmpeg in a snippet?

Sure, I removed it.  I also added a TODO to delete more bundled things
that are safe to delete in the future.

>> + (let ((cwd (getcwd)))
>> +   (dynamic-wind
>> + (const #t)
>> + (lambda ()
>> +   (chdir "tools/depends/native/JsonSchemaBuilder/src")
>> +   (zero? (system* "sh" "autogen.sh")))
>> + (lambda ()
>> +   (chdir cwd))
>
> Use ‘with-directory-excursion’ instead.

I should have known that this was already implemented.  :)

>> +(native-inputs
>> + `(("autoconf" ,autoconf)
>> +   ("automake" ,automake)
>> +   ("cmake" ,cmake)
>> +   ("doxygen" ,doxygen)
>> +   ("gawk" ,gawk)
>> +   ("gettext" ,gnu-gettext)
>
> We could remove autoconf/automake/libtool/gettext if they used ‘make
> dist’, but I guess they don’t.  Bah.
>
> We should start a “make dist” campaign; makedist.org appears to be
> available…  ;-)

I'm on board.  I spent 99% of packaging time trying to get the
bootstrapping process to work.  I don't think any of the devs realize
that they conflate bootstrapping with configuration, or maybe they
know and don't see a problem.

>> +   ("icedtea7" ,icedtea7)
>
> Is it a build-only dependency (it’s in ‘native-inputs’)?  Can it be
> avoided?

Yes, it is a build-only dependency.  Unfortunately, it is mandatory to
build some part of the application.  I added a comment for clarity.

Pushed with the suggested changes.  Thanks!

- Dave

Re: [PATCHES] Add Kodi

[Thompson, David]

In my haste I realize that I've forgotten the appropriate copyright
header comment in kodi.scm.  I have fixed it locally.

- Dave

Re: [PATCH] Add ruby-net-ssh (and 12 other gems)

[Thompson, David]

On Fri, Nov 20, 2015 at 6:23 AM, Ricardo Wurmus
 wrote:
> Hi Guix,
>
> I’ve finally packaged yet another top runtime dependency of buildr[1]
> (which I hope we can use to build maven): ruby-net-ssh.
>
> It depends on a number of gems, including the popular ruby-mocha and
> ruby-redcarpet.

Awesome!  All of these look good except for the ruby-blankslate patch,
whose 'check phase always passes because you return #t after running
the test suite.  OK to push with this phase fixed.

Great stuff!

- Dave

Re: updating list of substitutes

[Thompson, David]

On Wed, Nov 18, 2015 at 11:15 AM, Pjotr Prins  wrote:
> Hi Ludo,
>
> Hydra needs to get kicked ;). Download substitutes is slow. Too slow.
>
> How much would it cost to get some decent hardware for the substitute
> server? Maybe we can do a dedicated round of funding on this list and
> go round with a cap at FOSDEM? I am happy to put in $100 if it solves
> the issue. Is there no one here who can provide a decent server?

If someone can source the hardware and figure out colocation details,
I will happily throw in some money towards this cause as well.

- Dave

Re: avr-gcc

[Thompson, David]

On Wed, Nov 18, 2015 at 6:03 AM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Tue, Nov 17, 2015 at 4:32 PM, Ludovic Courtès <l...@gnu.org> wrote:
>
> [...]
>
>>> In GCC we modify the spec file so that the right -L/libc/dir/name is
>>> passed to ld; see (gnu packages gcc), ‘GNU_USER_TARGET_LIB_SPEC’.
>>>
>>> However, ‘gcc-cross-sans-libc-avr’ is a bare-bones compiler, so it
>>> doesn’t get the -L flag in question since there’s no libc to link to.
>>>
>>> To get a full-blow compiler that uses avr-libc, you could start from
>>> this:
>>>
>>>
>>>
>>> … and then address any glibc assumptions you encounter.
>>
>> I tried to do this, but I don't really know what I'm doing.  The first
>> problem I encountered was that I needed to add a case to the
>> 'glibc-dynamic-linker' procedure in (gnu packages bootstrap).  I
>> didn't know what ld was needed, if any, so I added this case:
>>
>> ((string=? system "avr-avrlibc") "no-ld.so")
>
> It may be that avr-libc has no dynamic linker, because it targets
> MMU-less systems, no?
>
>> Then, the issue was that avr-libc doesn't have a propagated input with
>> the label "linux-headers", as required by 'cross-gcc' in (gnu packages
>> cross-base).  So, as a hack I tried something like this:
>>
>> (if (string=? "avr-libc" (package-name libc))
>>`()
>>`(("xlinux-headers" ;the target headers
>>   ,@(assoc-ref (package-propagated-inputs libc)
>>"linux-headers"
>>
>> Now I was able to get the build process to start, but it failed when
>> trying to compile binutils:
>>
>> checking target system type... Invalid configuration
>> `avr-linux-avrlibc': system `avrlibc' not recognized
>>
>> I'm totally lost.  Any thoughts on where to go next?
>
> Hmm, maybe my suggestion was just misguided, because the AVR environment
> seems to be very different from the typical GNU/Linux environment.
>
> For instance it’s not clear to me how as a user you’re supposed to tell
> the compiler which libc.a file to choose among all those provided by
> avr-libc.
>
> Back to the Microscheme question, you could set ‘CROSS_LIBRARY_PATH’
> manually to point to one of the avr/lib/xxx directories, where our
> cross-gcc will find libc.a, libm.a, and crt*.o, but I don’t know if it’s
> how it’s intended to work.
>
>> BTW, I believe this native search path is needed in order for the AVR
>> header files to be found:
>>
>> (search-path-specification
>>  (variable "C_INCLUDE_PATH")
>>  (files '("avr/include")))
>
> ‘C_INCLUDE_PATH’ is the C-only equivalent of ‘CPATH’.  Our
> cross-compiler honors ‘CROSS_CPATH’ instead of ‘CPATH’ so as to
> distinguish between host and build headers (see
> gcc-cross-environment-variables.patch.)

Ah, okay.  CROSS_CPATH works.

> Also it’s not clear to me why avr-libc installs things in avr/include
> instead of include/.

Not sure either, but it poses no problem.

> So in short, it looks like everything you need is already there, but the
> pieces need to be wired together.  :-)

Not quite.  The avr-gcc build only provides a single version of
libgcc.a, whereas Debian's avr-gcc provides a separate libgcc.a for
each supported AVR family (avr2, avr3, avr35, etc.)  Mark thought it
might be the fault of the --disable-multilib configure flag, so I
removed it but it didn't solve anything.  I'm not sure what to do now.
I have no idea what flag or patch could be signalling to the gcc build
system that it shouldn't try to compile libraries for all of the
various AVR models.

Does anyone have any ideas?

Thanks,

- Dave

Re: avr-gcc

[Thompson, David]

On Tue, Nov 17, 2015 at 4:32 PM, Ludovic Courtès  wrote:
> Ricardo Wurmus  skribis:
>
>> Microscheme 0.9.2, (C) Ryan Suchocki
 Treeshaker: After 4 rounds: 87 globals purged! 22 bytes will be reserved.
 18 lines compiled OK
 Assembling...
>> avr-ld: cannot find crtm328p.o: No such file or directory
>> avr-ld: cannot find -lm
>> avr-ld: cannot find -lc
>
> In GCC we modify the spec file so that the right -L/libc/dir/name is
> passed to ld; see (gnu packages gcc), ‘GNU_USER_TARGET_LIB_SPEC’.
>
> However, ‘gcc-cross-sans-libc-avr’ is a bare-bones compiler, so it
> doesn’t get the -L flag in question since there’s no libc to link to.
>
> To get a full-blow compiler that uses avr-libc, you could start from
> this:
>
>
>
> … and then address any glibc assumptions you encounter.

I tried to do this, but I don't really know what I'm doing.  The first
problem I encountered was that I needed to add a case to the
'glibc-dynamic-linker' procedure in (gnu packages bootstrap).  I
didn't know what ld was needed, if any, so I added this case:

((string=? system "avr-avrlibc") "no-ld.so")

Then, the issue was that avr-libc doesn't have a propagated input with
the label "linux-headers", as required by 'cross-gcc' in (gnu packages
cross-base).  So, as a hack I tried something like this:

(if (string=? "avr-libc" (package-name libc))
   `()
   `(("xlinux-headers" ;the target headers
  ,@(assoc-ref (package-propagated-inputs libc)
   "linux-headers"

Now I was able to get the build process to start, but it failed when
trying to compile binutils:

checking target system type... Invalid configuration
`avr-linux-avrlibc': system `avrlibc' not recognized

I'm totally lost.  Any thoughts on where to go next?

BTW, I believe this native search path is needed in order for the AVR
header files to be found:

(search-path-specification
 (variable "C_INCLUDE_PATH")
 (files '("avr/include")))

Hopefully I'll be able to play with my Atmel microcontrollers again
real soon. :)

- Dave

Re: [PATCH 5/5] gnu: Add gnome-shell.

[Thompson, David]

On Tue, Nov 10, 2015 at 8:10 AM, 宋文武  wrote:
> WIP, gdm and gnome-shell won't start.
>
> I haven't look much about gdm.
>
> gnome-shell still missing some runtime depends (as typelib) like
> network-manager, etc.
>
> I post those patches to ML to track the process, let's package GNOME :-)

Wow!!!  Awesome progress!

- Dave

Re: [PATCH] gnu: Add ruby-eventmachine.

[Thompson, David]

On Thu, Nov 5, 2015 at 4:20 PM, Ricardo Wurmus  wrote:
> Looks good to me.  Thank you for packaging this!
>
> Out of curiosity: do all/most tests assume an Internet connection?  If
> not could you just patch away those tests that do?

I decided to just disable the tests entirely and report the issue
upstream: https://github.com/eventmachine/eventmachine/issues/656

Thanks for the review.

- Dave

Re: [PATCH] website: Add support for Haunt.

[Thompson, David]

On Sat, Nov 7, 2015 at 6:04 AM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Fri, Nov 6, 2015 at 3:47 PM, Ludovic Courtès <l...@gnu.org> wrote:
>
> [...]
>
>>>> WARNING: Haunt builds the site afresh at each 'haunt build' run, which
>>>> means that it deletes everything in the build directory first.  Will
>>>> that be an issue here?
>>>
>>> That should be fine.
>>
>> OK.  I was worried that maybe some "stateful" stuff like the manual
>> html pages would get clobbered or something.
>
> Ah yes, that would be a problem.  It thought you were only talking about
> the files that Haunt generates.
>
> Currently, there’s a bunch of files that are only in CVS, such as the
> PDFs of talks and the manual.  This is not ideal, but I’m not sure how
> to address that.

I can add a 'precious-directories' field to  or something to
protect "stateful" stuff.

- Dave

Re: IMPORTANT: Security Updates

[Thompson, David]

On Sat, Nov 7, 2015 at 8:43 AM, Mark H Weaver  wrote:
> I just pushed updates to 'nss', 'nspr', and 'icecat' fixing critical
> remote code execution security vulnerabilities in all three.
>
> This also affects 'epiphany', 'libreoffice', 'conkeror', anything based
> on Qt, and other things.  Substitutes are available for all of the
> updated packages on x86_64 and i686, except for libreoffice which is
> still being built.
>
> I strongly recommend that you update your software as soon as possible.

Thank you, Mark.

- Dave

Re: [PATCH] website: Add support for Haunt.

[Thompson, David]

On Thu, Nov 5, 2015 at 6:50 PM, Mathieu Lirzin <m...@gnu.org> wrote:
> Hi,
>
> "Thompson, David" <dthomps...@worcester.edu> writes:
>
>> On Thu, Nov 5, 2015 at 4:25 PM, Ludovic Courtès <l...@gnu.org> wrote:
> [...]
>>> Does the generated HTML change as a result of using Haunt?
>>
>> Not as far as I can tell by looking at the patch.
>>
>> I'm not 100% sure if Haunt really buys us anything in the case of this
>> site.  Mathieu, do you see any current or potential future advantages
>> to using Haunt having done this work?  I'm really happy to see more
>> Haunt users, but I also don't want to encourage its use where it
>> doesn't make sense. :)
>
> For now it provides us a reliable and simple command line interface for
> building the website.  My hope for the future is that GuixSD website
> will have a smaller code base that will use convenient generic
> procedures provided by Haunt.  Of course it will depend on what would
> make sense to be implemented in Haunt.  the first example I have in mind
> is the the RSS/Atom feed importer implemented by Ludo in “www.scm” (used
> by new Guile's website too) which IIUC could be implemented as a Haunt
> reader.  This would provide somekind of RSS/Atom functional
> composability. ;)
>
> WDYT?

Makes sense.  Let's see how it goes. :)

> Continue the good work!

I'll try.

- Dave

Re: [PATCH] website: Add support for Haunt.

[Thompson, David]

On Fri, Nov 6, 2015 at 3:47 PM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Thu, Nov 5, 2015 at 4:25 PM, Ludovic Courtès <l...@gnu.org> wrote:
>>> Mathieu Lirzin <m...@gnu.org> skribis:
>>>
>>>> +Building the website depends on the static site generator:
>>>> +
>>>> +  - [[http://haunt.dthompson.us/][Haunt]]
>>>> +
>>>> +To build the site, run ‘haunt build -c guixsd.scm’ to compile all of
>>>> +the HTML pages.  To view the results, run ‘haunt serve -c guixsd.scm’
>>>> +and visit <http://localhost:8080> in a web browser.
>>>
>>> This looks nice.
>>>
>>> Is there a way to specify the output directory for the generated HTML?
>>>
>>> Currently I do:
>>>
>>>   (export-web-site "/path/to/cvs/checkout")
>>>
>>> so the HTML ends up directly in the right place.
>>
>> Yes, you can tweak haunt.scm a bit:
>>
>> (site ... #:build-directory "/path/to/cvs/checkout")
>
> And from the command line?  I don’t want to hard-code /home/ludo in the
> code.  :-)

I guess I need to add an option to 'haunt build' for that.

>> WARNING: Haunt builds the site afresh at each 'haunt build' run, which
>> means that it deletes everything in the build directory first.  Will
>> that be an issue here?
>
> That should be fine.

OK.  I was worried that maybe some "stateful" stuff like the manual
html pages would get clobbered or something.

- Dave

Re: [PATCH] website: Add support for Haunt.

[Thompson, David]

On Thu, Nov 5, 2015 at 4:25 PM, Ludovic Courtès  wrote:
> Mathieu Lirzin  skribis:
>
>> +Building the website depends on the static site generator:
>> +
>> +  - [[http://haunt.dthompson.us/][Haunt]]
>> +
>> +To build the site, run ‘haunt build -c guixsd.scm’ to compile all of
>> +the HTML pages.  To view the results, run ‘haunt serve -c guixsd.scm’
>> +and visit  in a web browser.
>
> This looks nice.
>
> Is there a way to specify the output directory for the generated HTML?
>
> Currently I do:
>
>   (export-web-site "/path/to/cvs/checkout")
>
> so the HTML ends up directly in the right place.

Yes, you can tweak haunt.scm a bit:

(site ... #:build-directory "/path/to/cvs/checkout")

WARNING: Haunt builds the site afresh at each 'haunt build' run, which
means that it deletes everything in the build directory first.  Will
that be an issue here?

> Does the generated HTML change as a result of using Haunt?

Not as far as I can tell by looking at the patch.

I'm not 100% sure if Haunt really buys us anything in the case of this
site.  Mathieu, do you see any current or potential future advantages
to using Haunt having done this work?  I'm really happy to see more
Haunt users, but I also don't want to encourage its use where it
doesn't make sense. :)

Thanks,

- Dave

[PATCH] gnu: Add ruby-eventmachine.

[Thompson, David]

From 8338597b81f100cb3fdda00dfadb9c1a3c95ca1b Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Thu, 5 Nov 2015 08:43:44 -0500
Subject: [PATCH] gnu: Add ruby-eventmachine.

* gnu/packages/ruby.scm (ruby-eventmachine): New variable.
---
 gnu/packages/ruby.scm | 25 +
 1 file changed, 25 insertions(+)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 137b75a..3193aea 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -1649,3 +1649,28 @@ that can be exported to a number of formats very easily, and also supports
 extending for custom Ruby constructs such as custom class level definitions.")
 (home-page "http://yardoc.org;)
 (license license:expat)))
+
+(define-public ruby-eventmachine
+  (package
+(name "ruby-eventmachine")
+(version "1.0.8")
+(source
+ (origin
+   (method url-fetch)
+   (uri (rubygems-uri "eventmachine" version))
+   (sha256
+(base32
+ "1frvpk3p73xc64qkn0ymll3flvn4xcycq5yx8a43zd3gyzc1ifjp"
+(build-system ruby-build-system)
+(arguments
+ '(#:tests? #f)) ; test suite tries to connect to google.com
+(native-inputs
+ `(("ruby-rake-compiler" ,ruby-rake-compiler)))
+(synopsis "Single-threaded network event framework for Ruby")
+(description
+ "EventMachine implements a single-threaded engine for arbitrary network
+communications.  EventMachine wraps all interactions with sockets, allowing
+programs to concentrate on the implementation of network protocols.  It can be
+used to create both network servers and clients.")
+(home-page "http://rubyeventmachine.com;)
+(license (list license:ruby license:gpl3 ; GPLv3 only AFAICT
-- 
2.5.0

Re: [PATCH] tests: Skip 'guix environment --container' tests in some cases.

[Thompson, David]

On Wed, Nov 4, 2015 at 4:05 AM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> Took a stab at fixing the guix-environment-container.sh tests when the
>> necessary features aren't available.  GuixSD systems don't have
>> /proc/sys/kernel/unprivileged_userns_clone so I couldn't verify that
>> code path works as intended.  All I can say is that the tests still pass
>> on my machine as they did before.
>>
>> WDYT?  Did I make it in time for the release?
>
> Sounds good in principle, but you forgot to attach the patch.  :-)

Ugh.  Then I also forgot to reply-all and sent the patch to you only.
Double ugh.  Sorry about this.

- Dave
From a2b6e503c53ed6f4e20474e78f17fac208f4627e Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Tue, 3 Nov 2015 22:05:26 -0500
Subject: [PATCH] tests: Skip 'guix environment --container' tests in some
 cases.

The tests in tests/guix-environment-container.sh cannot be performed
unless the system supports user namespaces.

* tests/guix-environment-container.sh: Skip if feature tests fail.
---
 tests/guix-environment-container.sh | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/tests/guix-environment-container.sh b/tests/guix-environment-container.sh
index 141fd16..9e75ac5 100644
--- a/tests/guix-environment-container.sh
+++ b/tests/guix-environment-container.sh
@@ -22,6 +22,25 @@
 
 set -e
 
+# Perform some feature tests to determine if the tests are applicable.
+if test -f /proc/self/ns/user -a \
+-f /proc/self/setgroups
+then
+if test -f /proc/sys/kernel/unprivileged_userns_clone
+then
+if test $(cat /proc/sys/kernel/unprivileged_userns_clone) = "1"
+then
+true
+else
+exit 77
+fi
+else
+true
+fi
+else
+exit 77
+fi
+
 guix environment --version
 
 tmpdir="t-guix-environment-$$"
-- 
2.5.0

Re: [PATCH 2/2] gnu: Add esmtp.

[Thompson, David]

On Tue, Nov 3, 2015 at 9:54 AM, Andy Wingo  wrote:
> * gnu/packages/mail.scm (esmtp): New public variable.
> ---
>  gnu/packages/mail.scm | 40 
>  1 file changed, 40 insertions(+)
>
> diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
> index 9a70341..dfc8ec9 100644
> --- a/gnu/packages/mail.scm
> +++ b/gnu/packages/mail.scm
> @@ -30,6 +30,7 @@
>#:use-module (gnu packages base)
>#:use-module (gnu packages backup)
>#:use-module (gnu packages bash)
> +  #:use-module (gnu packages bison)
>#:use-module (gnu packages curl)
>#:use-module (gnu packages cyrus-sasl)
>#:use-module (gnu packages databases)
> @@ -44,6 +45,7 @@
>#:use-module (gnu packages gsasl)
>#:use-module (gnu packages gtk)
>#:use-module (gnu packages guile)
> +  #:use-module (gnu packages flex)
>#:use-module (gnu packages libcanberra)
>#:use-module (gnu packages libidn)
>#:use-module (gnu packages linux)
> @@ -70,6 +72,7 @@
>(expat . license:expat)))
>#:use-module (guix packages)
>#:use-module (guix download)
> +  #:use-module (guix git-download)
>#:use-module (guix utils)
>#:use-module (guix build-system gnu)
>#:use-module (guix build-system perl)
> @@ -955,4 +958,41 @@ be able to post electronic mail where mail functionality 
> may not be that
>  program's primary purpose.")
>  (license (list lgpl2.1+ gpl2+
>
> +(define-public esmtp
> +  (package
> +(name "esmtp")
> +(version "1.2")
> +(source
> + (origin
> +   (method git-fetch)
> +   (uri (git-reference
> + (url "https://github.com/andywingo/esmtp.git;)
> + (commit "01bf9fc")))
> +   (sha256
> +(base32
> + "1ay282rrl92h0m0m8z5zzjnwiiagi7c78aq2qvhia5mw7prwfyw2"))
> +   (file-name (string-append name "-" version "-checkout"
> +(arguments
> + `(#:phases (modify-phases %standard-phases
> +  (add-before
> +   'configure 'autoconf
> +   (lambda _ (zero? (system* "autoreconf" "-vfi")))
> +(build-system gnu-build-system)
> +(native-inputs
> + `(("bison" ,bison)
> +   ("flex" ,flex)
> +   ("libesmtp" ,libesmtp)

Should this be a regular input instead?

> +   ("autoconf" ,autoconf)
> +   ("automake" ,automake)
> +   ("libtool" ,libtool)))
> +(home-page "http://www.stafford.uklinux.net/libesmtp/;)

Wrong home page?

> +(synopsis "Relay-only mail transfer agent (MTA)")
> +(description "Esmtp is a simple relay-only mail transfer agent built 
> using
> +libESMTP.  It sends e-mail via a remote SMTP server using credentials from 
> the
> +user's @file{$HOME/.esmtprc} configuration file; see the @command{esmtprc} 
> man
> +page for more on configuration.  This package also provides minimal
> +compatibility shims for the @command{sendmail}, @command{mailq}, and
> +@command{newaliases} commands.")
> +(license gpl2+)))
> +
>  ;;; mail.scm ends here
> --
> 2.5.0
>
>

LGTM sans those minor nits.

- Dave

Re: "guix container exec --help" errors

[Thompson, David]

On Mon, Nov 2, 2015 at 8:28 AM, Alex Kost  wrote:
> Hello, currently "guix container exec -h" (or -V) gives:
>
>   guix container: error: no pid specified
>
> I think this happens because:
>
> (partition-args '("-h")) => ()
> ("-h")
>
> So 'parse-command-line' is called on an empty list.

Thanks for the report!  Fixed in d431b23.

- Dave

Re: [PATCH] website: Add support for Haunt.

[Thompson, David]

On Tue, Nov 3, 2015 at 4:26 PM, Mathieu Lirzin  wrote:
> Hello Guix,
>
> Thanks to Alex Vong's impulse, I have implemented a first step in the
> use of Dave Thompson's site generator Haunt (http://haunt.dthompson.us/)
> for the GuixSD website.

Wow, cool!  I'm surprised at how little code is needed to make the
basics work.  I'll have to try this patch out sometime and see what we
can do to improve it.  I'm sure we'll find a thing or two that Haunt
can do better in the process.

- Dave

Re: [PATCH] scripts: environment: Allow lists of packages in expressions.

[Thompson, David]

On Sat, Oct 31, 2015 at 6:25 AM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> From c9c282cea04ec5a3ee7bd17e6ad8846600220feb Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Fri, 30 Oct 2015 21:02:51 -0400
>> Subject: [PATCH] scripts: environment: Allow lists of packages in 
>> expressions.
>>
>> * guix/scripts/environment.scm (options/resolve-packages): Match against
>>   lists of packages when evaluating expressions.
>> * tests/guix-environment.sh: Add test.
>> * doc/guix.texi ("invoking guix environment"): Add docs.
>
> OK!

Pushed. Thanks!

- Dave

Re: [PATCH 14/15] scripts: environment: Add --container option.

[Thompson, David]

Hello, sorry for the delay.

On Tue, Oct 27, 2015 at 6:13 AM, Ludovic Courtès  wrote:
> Hello!
>
> One thing I noticed is that ‘guix environment --container’ behaves
> sub-optimally when ‘SHELL’ is set or set to the empty string:
>
> --8<---cut here---start->8---
> $ guix environment alta --pure --container
>
> [...]
>
> In execvp of /home/ludo/.guix-profile/bin/bash: No such file or directory
> $ SHELL= guix environment alta --pure --container
> In execvp of : No such file or directory
> --8<---cut here---end--->8---
>
> One has to explicitly ‘unset SHELL’ to sidestep the problem.  This may
> be confusing to newcomers.

Yes, I know about this, but I'm not sure of a good solution.

> What about automatically mapping $SHELL in the container when it is set?

The issue is that the default command to evaluate is $SHELL or
"/bin/sh."  You can be almost certain that $SHELL is not going to be
available in the container.  What to do?  Check if the command is
'equal?' to (list (getenv "SHELL")) and make it '("/bin/sh") instead?

> Also, ‘SHELL’ is overridden in the environment:
>
> --8<---cut here---start->8---
> $ echo $SHELL
> /home/ludo/.guix-profile/bin/bash
> $ guix environment alta --container --expose=$SHELL
> bash-4.3# echo $SHELL
> /bin/sh
> # ls -l /proc/2/exe
> lrwxrwxrwx 1 0 0 0 Oct 27 10:11 /proc/2/exe -> 
> /home/ludo/.guix-profile/bin/bash
> bash-4.3# ls -l /home/ludo/.guix-profile/bin/bash
> -r-xr-xr-x 2 65534 65534 917320 Jan  1  1970 /home/ludo/.guix-profile/bin/bash
> --8<---cut here---end--->8---
>
> I’m not sure if ‘SHELL’ should be added to ‘%precious-variables’.

I don't think so, because of the issue mentioned above.  I'm thinking
that the default shell should remain the Bash we mount at /bin/sh.

Open to, and looking for, ideas to improve things.  Let me know what
you think of all this.

- Dave

Re: [PATCH] Add ruby-rb-inotify, ruby-listen, ruby-permutation.

[Thompson, David]

All of these LGTM.  If we encounter gems like inotify that use
Jeweler, then we should consider adding an argument to
ruby-build-system that allows one to toggle gemspec generation.

- Dave

Re: [PATCH 13/15] scripts: system: Add 'container' action.

[Thompson, David]

On Tue, Oct 27, 2015 at 1:41 PM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> From 5dde31ef51502726a2915cc4faba81f4fadb851c Mon Sep 17 00:00:00 2001
>> From: David Thompson <da...@gnu.org>
>> Date: Mon, 8 Jun 2015 09:04:38 -0400
>> Subject: [PATCH] scripts: system: Add 'container' action.
>>
>> * guix/scripts/system.scm (show-help): Display 'container' action.
>>   (system-derivation-for-action, guix-system): Add 'container' case.
>>   (perform-action): Skip GRUB config generation when building a container.
>> * doc/guix.texi (Invoking guix system): Document it.
>
> [...]
>
>> +  ;; A range of 65536 uid/gids is used to cover 16 bits worth of
>> +  ;; users and groups, which is sufficient for most cases.
>
> Should be enough for everyone.  ;-)

Hehe.  I need to do more research on this.  User/group mapping is
still pretty confusing to me.

>>(display (_ "\
>> +  container build a Linux container that shares the host's 
>> store\n"))
>
> I’d remove “Linux” here (after all, we use libc’s interface, which
> hopefully will be implemented for the Hurd eventually.)

Fixed and pushed.  Thanks!

- Dave

Re: [PATCH] scripts: environment: Allow mixing regular and ad-hoc packages.

[Thompson, David]

On Mon, Oct 26, 2015 at 10:37 AM, Ludovic Courtès  wrote:

> Could you add a test in guix-environment.sh based on the output of
> --search-paths, similar to what is already done with ‘gnu-make-boot0’?

Good idea.  I wasn't sure how I could test this before.  Done!

> Other than that it LGTM!

How about this new patch?

Thanks!

- Dave
From ce7ebcc7d40bd6ec4beaad620597dfc121ca5bbe Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sun, 25 Oct 2015 22:33:33 -0400
Subject: [PATCH] scripts: environment: Allow mixing regular and ad-hoc
 packages.

This patch changes the --ad-hoc flag to be positional.  That is, the
packages that appear before --ad-hoc are interpreted as packages whose
inputs should be in the environment; the packages that appear after are
interpreted as packages to be directly added to the environment.

* guix/scripts/environment.scm (tag-package-arg, compact): New
  procedures.
  (%options): Tweak the handlers for --load and --expression options.
  (options/resolve-packages): Preserve package mode tag.
  (parse-args): Tweak argument handler to use package tagging procedure.
  (guix-environment): Apply ad-hoc behavior on a per package basis.
* tests/guix-environment.sh: Add test.
* doc/guix.texi ("invoking guix environment"): Document new behavior of
  --ad-hoc.
---
 doc/guix.texi| 20 +++
 guix/scripts/environment.scm | 85 ++--
 tests/guix-environment.sh| 14 
 3 files changed, 85 insertions(+), 34 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 9878b93..cb66f1f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4698,6 +4698,20 @@ NumPy:
 guix environment --ad-hoc python2-numpy python-2.7 -- python
 @end example
 
+Furthermore, one might want the dependencies of a package and also some
+additional packages that are not build-time or runtime dependencies, but
+are useful when developing nonetheless.  Because of this, the
+@code{--ad-hoc} flag is positional.  Packages appearing before
+@code{--ad-hoc} are interpreted as packages whose dependencies will be
+added to the environment.  Packages appearing after are interpreted as
+packages that will be added to the environment directly.  For example,
+the following command creates a Guix development environment that
+additionally includes Git and strace:
+
+@example
+guix environment guix --ad-hoc git strace
+@end example
+
 Sometimes it is desirable to isolate the environment as much as
 possible, for maximal purity and reproducibility.  In particular, when
 using Guix on a host distro that is not GuixSD, it is desirable to
@@ -4758,6 +4772,12 @@ Note that this example implicitly asks for the default output of
 specific output---e.g., @code{glib:bin} asks for the @code{bin} output
 of @code{glib} (@pxref{Packages with Multiple Outputs}).
 
+This option may be composed with the default behavior of @command{guix
+environment}.  Packages appearing before @code{--ad-hoc} are interpreted
+as packages whose dependencies will be added to the environment, the
+default behavior.  Packages appearing after are interpreted as packages
+that will be added to the environment directly.
+
 @item --pure
 Unset existing environment variables when building the new environment.
 This has the effect of creating an environment in which search paths
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 1d21a76..1888385 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -166,6 +166,16 @@ COMMAND or an interactive shell in that environment.\n"))
 (max-silent-time . 3600)
 (verbosity . 0)))
 
+(define (tag-package-arg opts arg)
+  "Return a two-element list with the form (TAG ARG) that tags ARG with either
+'ad-hoc' in OPTS has the 'ad-hoc?' key set to #t, or 'inputs' otherwise."
+  ;; Normally, the transitive inputs to a package are added to an environment,
+  ;; but the ad-hoc? flag changes the meaning of a package argument such that
+  ;; the package itself is added to the environment instead.
+  (if (assoc-ref opts 'ad-hoc?)
+  `(ad-hoc-package ,arg)
+  `(package ,arg)))
+
 (define %options
   ;; Specification of the command-line options.
   (cons* (option '(#\h "help") #f #f
@@ -186,10 +196,14 @@ COMMAND or an interactive shell in that environment.\n"))
(alist-cons 'search-paths #t result)))
  (option '(#\l "load") #t #f
  (lambda (opt name arg result)
-   (alist-cons 'load arg result)))
+   (alist-cons 'load
+   (tag-package-arg result arg)
+   result)))
  (option '(#\e "expression") #t #f
  (lambda (opt name arg result)
-   (alist-cons 'expression arg result)))
+   (alist-cons 'expression
+   (tag-package-arg result arg)
+   

Re: Environment containers

[Thompson, David]

On Wed, Oct 28, 2015 at 3:09 PM, Efraim Flashner  wrote:

> efraim@debian-netbook:~$ ls -la /gnu/store/*sh
> -r-xr-xr-x 27 root root 1425560 Jan  1  1970 
> /gnu/store/gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash
> -r--r--r--  2 root root1153 Jan  1  1970 
> /gnu/store/jd51fxgzf2bj3v9naliq44vgcib06ay9-build-bootstrap-guile.sh
> -r-xr-xr-x 27 root root 1351732 Jan  1  1970 
> /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash
> -r--r--r--  2 root root1153 Jan  1  1970 
> /gnu/store/x06d80rn9lxbh3305pkizf4k2dswsbn1-build-bootstrap-guile.sh
> -r-xr-xr-x  2 root guix-builder 765 Jan  1  1970 
> /gnu/store/zrnjijsg19f52ficwlk4n5cccf6smhya-run-vm.sh
>
> 765 bytes is the smallest VM I've ever seen :)

Do note that this is just a *script* to boot a virtual machine, which
is completely different from the scripts that boot GuixSD containers.
What you're not seeing in that directory listing is the disk image
that was generated for qemu to boot.  Guix environment containers do
not generate scripts like this.

- Dave

Re: Some newbie questions

[Thompson, David]

On Thu, Oct 29, 2015 at 6:08 AM, Jan Synáček  wrote:
> Hello,
>
> I've been playing with guix a bit and I must say I really like it. I don't
> understand a few things though.
>
> 1) How do I tell if a package I have installed had been built locally or
> downloaded as a substitute?

You don't.  You can think of substitution is an optimization
technique, the results are indistinguishable except for that it likely
took less time to get the substitute.  It's possible to query the
substitute server to see if it has the store item that you have, but
that doesn't mean that your copy was retrieved from there necessarily.
Other than that, the Guix tools will tell you at build/download time
whether or not it is building from source or downloading a pre-built
binary.  What use-case do you have in mind?

> 2) There are a lot of packages with executable binaries in the bin/
> subfolder in /gnu/store. However, if I didn't explicitly install the
> package, I don't have it in my profile and can't easily reach the binary
> without first looking it up in the store. Do I have to always "install" a
> package to be able to use run it easily?

Not always, but usually that is what you'd do.  This is how we achieve
isolation of environments.  Different users, or the same user in
different circumstances, will want different sets of programs and
libraries available to them.

That said, if you just want to do a one-off run of something, you can
use 'guix environment' instead, which will not install anything to
your user profile, like so:

guix environment --ad-hoc wget -- wget http://gnu.org/s/guix

> Please, excuse my not-so-clear questions, I still don't fully understand how
> things really work in guix.

No problem at all.  Welcome!

- Dave

Re: Substitutes from multiple server

[Thompson, David]

On Wed, Oct 28, 2015 at 7:14 AM, Ludovic Courtès  wrote:
> It’s now possible to really use multiple substitute servers, as in:
>
>   guix build foo --substitute-urls='http://example.org http://hydra.gnu.org'
>
> Here Guix first looks for substitutes at example.org, and then falls
> back to gnu.org for those that were not found.
>
> The basics were in place but commit 55b2fc1 adds the missing bits.

Awesome!  One step closer to 'guix publish' being a generally useful
tool.  I'd like to run my own substitute server to provide some custom
binaries while fetching everything else from hydra.gnu.org.

> Unfortunately, due to , the daemon’s
> --substitute-urls is overridden by clients, so you really have to pass
> --substitute-urls to various ‘guix’ commands.
>
> Unfortunately², because URLs are whitespace-separated, one cannot put
> the option in the ‘GUIX_BUILD_OPTIONS’ environment variable, because
> that one is simply split up using ‘string-tokenize’.

It will be a great day when these limitations are removed.

Thanks!

- Dave

Re: [PATCH] scripts: build: Add --file option.

[Thompson, David]

On Wed, Oct 28, 2015 at 5:26 AM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> From d3dd1b2d05f17702f7fa6095132db00e2146e702 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Mon, 26 Oct 2015 18:09:28 -0400
>> Subject: [PATCH] scripts: build: Add --file option.
>>
>> * guix/scripts/build.scm (show-help): Add help text for --file option.
>>   (%options): Add --file option.
>>   (options/resolve-packages): Handle 'file' options.
>> * tests/guix-build.sh: Add tests.
>> * doc/guix.texi ("invoking guix build"): Add doc.

Fixed typo and pushed.  Thanks Alex and Ludo!

- Dave

Re: Environment containers

[Thompson, David]

On Wed, Oct 28, 2015 at 11:14 AM, Alex Vong  wrote:
> On 28/10/2015, Ludovic Courtès  wrote:
>> Alex Vong  skribis:
>>
>>> On 27/10/2015, Ludovic Courtès  wrote:
>>
>> [...]
>>
 Do you still experience the test failures mentioned in that report?  If
 not, could you email 21...@debbugs.gnu.org, specifying which commit
 works for you?

>>> Yes, there are 4 tests still failing with the latest master branch
>>> without unprivileged container.
>>
>> Which tests?  Does tests/container.scm pass?
>>
> It doesn't pass if I run as unprivileged user. It passes if I run as
> root. I will be mailing the test logs on another mail.

This is because Debian doesn't let unprivileged users create user
namespaces without explicitly overriding some configuration.

- Dave

Re: Environment containers

[Thompson, David]

On Wed, Oct 28, 2015 at 11:56 AM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Wed, Oct 28, 2015 at 11:14 AM, Alex Vong <alexvong1...@gmail.com> wrote:
>>> On 28/10/2015, Ludovic Courtès <l...@gnu.org> wrote:
>>>> Alex Vong <alexvong1...@gmail.com> skribis:
>>>>
>>>>> On 27/10/2015, Ludovic Courtès <l...@gnu.org> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> Do you still experience the test failures mentioned in that report?  If
>>>>>> not, could you email 21...@debbugs.gnu.org, specifying which commit
>>>>>> works for you?
>>>>>>
>>>>> Yes, there are 4 tests still failing with the latest master branch
>>>>> without unprivileged container.
>>>>
>>>> Which tests?  Does tests/container.scm pass?
>>>>
>>> It doesn't pass if I run as unprivileged user. It passes if I run as
>>> root. I will be mailing the test logs on another mail.
>>
>> This is because Debian doesn't let unprivileged users create user
>> namespaces without explicitly overriding some configuration.
>
> How could we determine whether this restriction is in place?  That would
> allow us to skip the test on these systems.

I think it is /proc/sys/kernel/unprivileged_userns_clone, but I don't
know what the contents are exactly.  0 when off, 1 when on?  Can
someone on Debian confirm?

If we can get the test suite passing, I'd like to extract these user
namespace presence tests to a procedure that 'guix environment' can
use to give the user an informative error message in these cases.

- Dave

Re: [PATCH] system: container: Update to new service API.

[Thompson, David]

On Tue, Oct 27, 2015 at 9:22 AM, Ludovic Courtès  wrote:
> Sorry, I meant to preserve #:container? behavior but I forgot this bit.
>
> I believe the attached patch provides an Even Greater Way to address the
> problem, namely by making the modprobe/firmware thing an optional
> service.
>
> Could you try and report back?  I tried it in a VM and there’s no
> regression.

It works great, thanks!  If you make a commit from this, I will reduce
this patch to simply fixing gnu/system/linux-container.scm.

> Besides, we’ll have to make sure ‘guix system extension-graph’ honors
> --container.

Hmm, yes, good point. I haven't looked at that code at all since it is so new.

- Dave

Re: [PATCH 15/15] scripts: Add 'container' subcommand.

[Thompson, David]

Dusting this patch off.  Here's a fresh patch!

- Dave
From f5312c2445d774c9355c947d3c748d064740246e Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Wed, 1 Jul 2015 20:32:07 -0400
Subject: [PATCH] scripts: Add 'container' subcommand.

* guix/scripts/container.scm: New file.
* guix/scripts/container/exec.scm: New file.
* po/guix/POTFILES.in: Add them.
* Makefile.am (MODULES): Add them.
* doc/guix.texi (Invoking guix container): New section.
---
 Makefile.am |  2 +
 doc/guix.texi   | 54 ++
 guix/scripts/container.scm  | 63 ++
 guix/scripts/container/exec.scm | 86 +
 po/guix/POTFILES.in |  2 +
 5 files changed, 207 insertions(+)
 create mode 100644 guix/scripts/container.scm
 create mode 100644 guix/scripts/container/exec.scm

diff --git a/Makefile.am b/Makefile.am
index 4f90b1d..1582af3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -128,6 +128,8 @@ MODULES =	\
   guix/scripts/edit.scm\
   guix/scripts/size.scm\
   guix/scripts/graph.scm			\
+  guix/scripts/container.scm			\
+  guix/scripts/container/exec.scm		\
   guix.scm	\
   $(GNU_SYSTEM_MODULES)
 
diff --git a/doc/guix.texi b/doc/guix.texi
index 3491cfb..271b24b 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -144,6 +144,7 @@ Utilities
 * Invoking guix environment::   Setting up development environments.
 * Invoking guix publish::   Sharing substitutes.
 * Invoking guix challenge:: Challenging substitute servers.
+* Invoking guix container:: Process isolation.
 
 GNU Distribution
 
@@ -3582,6 +3583,7 @@ programming interface of Guix in a convenient way.
 * Invoking guix environment::   Setting up development environments.
 * Invoking guix publish::   Sharing substitutes.
 * Invoking guix challenge:: Challenging substitute servers.
+* Invoking guix container:: Process isolation.
 @end menu
 
 @node Invoking guix build
@@ -4985,6 +4987,58 @@ URLs to compare to.
 @end table
 
 
+@node Invoking guix container
+@section Invoking @command{guix container}
+@cindex container
+
+Note: This tool is experimental.  The interface is subject to radical
+change in the future.
+
+The purpose of @command{guix container} is to manipulate processes
+running within an isolated environment, commonly known as a
+``container,'' typically created by the @command{guix environment}
+(@pxref{Invoking guix environment}) and @command{guix system container}
+(@pxref{Invoking guix system}) commands.
+
+The general syntax is:
+
+@example
+guix container @var{action} @var{options}@dots{}
+@end example
+
+@var{action} specifies the operation to perform with a container, and
+@var{options} specifies the context-specific arguments for the action.
+
+The following actions are available:
+
+@table @code
+@item exec
+Execute a command within the context of a running container.
+
+The syntax is:
+
+@example
+guix container exec @var{pid} @var{program} @var{arguments}@dots{}
+@end example
+
+@var{pid} specifies the process ID of the running container.
+@var{program} specifies an executable file name within the container's
+root file system.  @var{arguments} are the additional options that will
+be passed to @var{program}.
+
+The following command launches an interactive login shell inside a
+GuixSD container, started by @command{guix system container}, and whose
+process ID is 9001:
+
+@example
+guix container exec 9001 /run/current-system/profile/bin/bash --login
+@end example
+
+Note that the @var{pid} cannot be the parent process of a container.  It
+must be the container's PID 1 or one of its child processes.
+
+@end table
+
 @c *
 @node GNU Distribution
 @chapter GNU Distribution
diff --git a/guix/scripts/container.scm b/guix/scripts/container.scm
new file mode 100644
index 000..cd9f345
--- /dev/null
+++ b/guix/scripts/container.scm
@@ -0,0 +1,63 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 David Thompson 
+;;;
+;;; 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 (guix scripts container)
+  #:use-module (ice-9 match)
+  #:use-module (guix ui)
+  #:export (guix-container))
+
+(define (show-help)
+  (display (_ 

Re: [PATCH 13/15] scripts: system: Add 'container' action.

[Thompson, David]

So, It's been awhile. I cleaned up the docs as per your suggestions.
Attaching the updated patch just so someone can give it another look
before I push it.  My "system: container: Update to new service API."
patch must be pushed first, though.

Thanks!

- Dave
From 5dde31ef51502726a2915cc4faba81f4fadb851c Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 8 Jun 2015 09:04:38 -0400
Subject: [PATCH] scripts: system: Add 'container' action.

* guix/scripts/system.scm (show-help): Display 'container' action.
  (system-derivation-for-action, guix-system): Add 'container' case.
  (perform-action): Skip GRUB config generation when building a container.
* doc/guix.texi (Invoking guix system): Document it.
---
 doc/guix.texi  | 21 +
 gnu/system/linux-container.scm |  7 ++-
 guix/scripts/system.scm| 19 +--
 3 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 20bf284..3491cfb 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -7183,6 +7183,27 @@ using the following command:
 # dd if=$(guix system disk-image my-os.scm) of=/dev/sdc
 @end example
 
+@item container
+Return a script to run the operating system declared in @var{file}
+within a container.  Containers are a set of lightweight isolation
+mechanisms provided by the kernel Linux-libre.  Containers are
+substantially less resource-demanding than full virtual machines since
+the kernel, shared objects, and other resources can be shared with the
+host system; this also means they provide thinner isolation.
+
+Currently, the script must be run as root in order to support more than
+a single user and group.  The container shares its store with the host
+system.
+
+As with the @code{vm} action (@pxref{guix system vm}), additional file
+systems to be shared between the host and container can be specified
+using the @option{--share} and @option{--expose} options:
+
+@example
+guix system container my-config.scm \
+   --expose=$HOME --share=$HOME/tmp=/exchange
+@end example
+
 @end table
 
 @var{options} can contain any of the common build options provided by
diff --git a/gnu/system/linux-container.scm b/gnu/system/linux-container.scm
index abe816f..c2eb773 100644
--- a/gnu/system/linux-container.scm
+++ b/gnu/system/linux-container.scm
@@ -108,7 +108,12 @@ that will be shared with the host system."
 (setenv "TMPDIR" "/tmp")
 (setenv "GUIX_NEW_SYSTEM" #$os-drv)
 (for-each mkdir-p '("/run" "/bin" "/etc" "/home" "/var"))
-(primitive-load (string-append #$os-drv "/boot"))
+(primitive-load (string-append #$os-drv "/boot")))
+  ;; A range of 65536 uid/gids is used to cover 16 bits worth of
+  ;; users and groups, which is sufficient for most cases.
+  ;;
+  ;; See: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--private-users=
+  #:host-uids 65536)))
 
   (gexp->script "run-container" script
 #:modules '((ice-9 match)
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index d847c75..4bf9ac9 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -34,6 +34,7 @@
   #:use-module (gnu build install)
   #:use-module (gnu system)
   #:use-module (gnu system file-systems)
+  #:use-module (gnu system linux-container)
   #:use-module (gnu system vm)
   #:use-module (gnu system grub)
   #:use-module (gnu services)
@@ -406,6 +407,8 @@ PATTERN, a string.  When PATTERN is #f, display all the system generations."
   (case action
 ((build init reconfigure)
  (operating-system-derivation os))
+((container)
+ (container-script os #:mappings mappings))
 ((vm-image)
  (system-qemu-image os #:disk-image-size image-size))
 ((vm)
@@ -438,10 +441,12 @@ building anything."
 #:full-boot? full-boot?
 #:mappings mappings))
(grub  (package->derivation grub))
-   (grub.cfg  (operating-system-grub.cfg os
- (if (eq? 'init action)
- '()
- (previous-grub-entries
+   (grub.cfg  (if (eq? 'container action)
+  (return #f)
+  (operating-system-grub.cfg os
+ (if (eq? 'init action)
+ '()
+ (previous-grub-entries)
(drvs   -> (if (and grub? (memq action '(init reconfigure)))
   (list sys grub grub.cfg)
   (list sys)))
@@ -524,6 +529,8 @@ Build the operating system declared in FILE according to ACTION.\n"))
   (display (_ "\
build

Re: Environment containers

[Thompson, David]

On Mon, Oct 26, 2015 at 10:37 AM, Taylan Ulrich Bayırlı/Kammer
 wrote:

> Also, for Debian 8 users and maybe others, this might help:
>
> sudo sysctl -w kernel.unprivileged_userns_clone=1

Yes, user namespaces are a must-have for this to work.  I will prepare
patches that mention this in the manual and add a test to 'guix
environment' that can detect if user namespaces are unavailable and
display a more helpful error message.

Thanks for bring the UX issues to my attention!

- Dave

Re: Environment containers

[Thompson, David]

On Mon, Oct 26, 2015 at 12:23 PM, Christopher Allan Webber
 wrote:
> David, you are kicking ass on this.  *Thank you* so much for working so
> hard to get this in... I know it was a challenging task, but I think
> this helps pave the way for even greater things!

Thanks for your kind words, Chris!  Much appreciated.

- Dave

Environment containers

[Thompson, David]

Hello Guix hackers,

I am pleased to announce that the patch for adding Linux container
support to 'guix environment' has just landed in master!

Why is this cool, you ask?  Well, it enables one to truly isolate
development environments from the rest of the system, much more so
than --pure does.  The --pure option only clears the environment
variables, but --container goes further and "unshares" kernel
resources (such as the user, mount, and pid namespaces) and creates a
chroot environment that has no file system access to what might be
considered "impurities."  The only file systems from the host that
make it into the container by default are the current working
directory and the store paths for all of the needed software.  This is
especially useful when running Guix on top of another host distro,
where sometimes things from the host sneak into your build environment
because a tool decided to inspect the contents of /usr or something.

You can use it like this:

guix environment --container guix

The above command will create an isolated container with everything
you need to build Guix from source.

There's more fun to be had, too.  Sometimes it's nice to make ad-hoc
sandboxes just to play around in.  The below command will run a
sandboxed Guile REPL:

guix environment --container --ad-hoc guile -- guile

By default, containers have no network access.  To share the host
network, use the --network flag.

This is just the beginning!  There's lots more to do.  It would be
nice to be able to create a network bridge so that the container can
have network access without sharing the host devices, a la Docker and
friends.  It would also be great to incorporate cgroups to arbitrarily
restrict container resources.

Coming soon is 'guix system container', which creates full-blown
GuixSD containers.

Since I mentioned Docker, I'd like to point some significant
advantages that Guix containers have over other implementations:

1) The container tools I'm working on are completely declarative.  No
imperative Dockerfiles!  This means that you don't have to worry about
order of operations, something that you have to think about constantly
when using Docker, especially when trying to maximize the use of the
image cache.

2) There are no disk images.  Disk images are opaque blobs that are
often not reproducible, whereas the items in the Guix store tell you
the full story of how the software came to be.  Thus, Guix containers
do not worry at all about the complications involved with layering
disk images in an overlayfs-style setup.  They are simply not needed.

3) Software and other files shared amongst many containers are
deduplicated system-wide.  This is a big deal from my perspective.
With Docker, container images *must* share as many base image layers
as possible to take advantage of deduplication, and there's
limitations to how smart overlay file systems can be to do
deduplication in memory (citation missing because I can't find the
article that explained the issues.)  Some people say that Docker is a
higher-level form of static linking, but instead of static linking the
executables, you "statically link" an entire, albeit more minimal,
operating system for each application that you run.  I'm inclined to
agree, and I'm happy to say that Guix doesn't have this problem.  A
store item present in N containers exists in exactly one place: in the
host store.  We take great advantage of bind mounts to share
everything without duplication.  Once again the fundamental building
block of every Guix tool, the immutable store, proves to be an
invaluable asset in overcoming the problems of our imperative
predecessors and contemporaries.

I hope this excites some of you.  Containers are all the rage right
now, and they have some seriously good properties if you can look past
the Docker hype.  I'd love to get some more hands to help make Guix
containers more featureful and robust in order to compete with the
mainstream tools.

Until next time, happy hacking!

- Dave

Re: [PATCH 14/15] scripts: environment: Add --container option.

[Thompson, David]

On Sun, Oct 25, 2015 at 5:38 PM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> From a61c65357174263790a55e8785fc625209e11324 Mon Sep 17 00:00:00 2001
>> From: David Thompson <da...@gnu.org>
>> Date: Fri, 19 Jun 2015 08:57:44 -0400
>> Subject: [PATCH] scripts: environment: Add --container option.
>>
>> * guix/scripts/system.scm (specification->file-system-mapping): Move from
>>   here...
>> * guix/ui.scm (specification->file-system-mapping): ... to here.
>> * guix/scripts/enviroment.scm (show-help): Show help for new options.
>>   (%options): Add --container --network, --expose, and --share options.
>>   (%network-configuration-files): New variable.
>>   (launch-environment, launch-environment/container, requisites*,
>>   inputs->requisites): New procedures.
>>   (guix-environment): Spawn new process in a container when requested.
>> * doc/guix.texi (Invoking guix environment): Document it.
>> * tests/guix-environment-container.sh: New file.
>> * Makefile.am (SH_TESTS): Add it.
>
> [...]
>
>> --- a/tests/guix-environment.sh
>> +++ b/tests/guix-environment.sh
>> @@ -55,6 +55,15 @@ else
>>  test $? = 42
>>  fi
>>
>> +# Make sure the exit value is preserved for containers, too.
>> +if guix environment --container --ad-hoc --bootstrap guile-bootstrap \
>> +-- guile -c '(exit 42)'
>> +then
>> +false
>> +else
>> +test $? = 42
>> +fi
>
> I think this bit is a leftover from a previous attempt that can now be
> removed (guix-environment-container.sh contains the same test.)

Thanks for catching this.  I could've sworn I had deduplicated that!

> OK to push with this change!  Exciting stuff, thank you!

Thanks for all of your help.  Pushed!  Woo!!!

- Dave

Re: [PATCH 14/15] scripts: environment: Add --container option.

[Thompson, David]

On Sat, Oct 17, 2015 at 6:05 AM, Ludovic Courtès  wrote:
> l...@gnu.org (Ludovic Courtès) skribis:
>
> As discussed on IRC, this turned out to be due to the fact that the Bash
> in Guile’s shebang was zero-sized.
>
> This happened because the ‘mount-file-system’ procedure would truncate
> that file, because the test store happens to be in $HOME, which was
> already bind-mounted.
>
> Commit 78981bb fixes it.

Thank you!

I've added some tests and tweaked a couple of other things.  Updated
patch attached.  WDYT?

- Dave
From a61c65357174263790a55e8785fc625209e11324 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Fri, 19 Jun 2015 08:57:44 -0400
Subject: [PATCH] scripts: environment: Add --container option.

* guix/scripts/system.scm (specification->file-system-mapping): Move from
  here...
* guix/ui.scm (specification->file-system-mapping): ... to here.
* guix/scripts/enviroment.scm (show-help): Show help for new options.
  (%options): Add --container --network, --expose, and --share options.
  (%network-configuration-files): New variable.
  (launch-environment, launch-environment/container, requisites*,
  inputs->requisites): New procedures.
  (guix-environment): Spawn new process in a container when requested.
* doc/guix.texi (Invoking guix environment): Document it.
* tests/guix-environment-container.sh: New file.
* Makefile.am (SH_TESTS): Add it.
---
 Makefile.am |   1 +
 doc/guix.texi   |  56 
 guix/scripts/environment.scm| 277 ++--
 guix/scripts/system.scm |  13 --
 guix/ui.scm |  19 +++
 tests/guix-environment-container.sh |  75 ++
 tests/guix-environment.sh   |   9 ++
 7 files changed, 395 insertions(+), 55 deletions(-)
 create mode 100644 tests/guix-environment-container.sh

diff --git a/Makefile.am b/Makefile.am
index 1427203..4f90b1d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -253,6 +253,7 @@ SH_TESTS =	\
   tests/guix-archive.sh\
   tests/guix-authenticate.sh			\
   tests/guix-environment.sh			\
+  tests/guix-environment-container.sh		\
   tests/guix-graph.sh\
   tests/guix-lint.sh
 
diff --git a/doc/guix.texi b/doc/guix.texi
index 99c10d8..7715b72 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4681,6 +4681,18 @@ NumPy:
 guix environment --ad-hoc python2-numpy python-2.7 -- python
 @end example
 
+Sometimes it is desirable to isolate the environment as much as
+possible, for maximal purity and reproducibility.  In particular, when
+using Guix on a host distro that is not GuixSD, it is desirable to
+prevent access to @file{/usr/bin} and other system-wide resources from
+the development environment.  For example, the following command spawns
+a Guile REPL in a ``container'' where only the store and the current
+working directory are mounted:
+
+@example
+guix environment --ad-hoc --container guile -- guile
+@end example
+
 The available options are summarized below.
 
 @table @code
@@ -4741,6 +4753,49 @@ environment.
 @item --system=@var{system}
 @itemx -s @var{system}
 Attempt to build for @var{system}---e.g., @code{i686-linux}.
+
+@item --container
+@itemx -C
+@cindex container
+Run @var{command} within an isolated container.  The current working
+directory outside the container is mapped to @file{/env} inside the
+container.  Additionally, the spawned process runs as the current user
+outside the container, but has root privileges in the context of the
+container.
+
+@item --network
+@itemx -N
+For containers, share the network namespace with the host system.
+Containers created without this flag only have access to the loopback
+device.
+
+@item --expose=@var{source}[=@var{target}]
+For containers, expose the file system @var{source} from the host system
+as the read-only file system @var{target} within the container.  If
+@var{target} is not specified, @var{source} is used as the target mount
+point in the container.
+
+The example below spawns a Guile REPL in a container in which the user's
+home directory is accessible read-only via the @file{/exchange}
+directory:
+
+@example
+guix environment --container --expose=$HOME=/exchange guile -- guile
+@end example
+
+@item --share
+For containers, share the file system @var{source} from the host system
+as the writable file system @var{target} within the container.  If
+@var{target} is not specified, @var{source} is used as the target mount
+point in the container.
+
+The example below spawns a Guile REPL in a container in which the user's
+home directory is accessible for both reading and writing via the
+@file{/exchange} directory:
+
+@example
+guix environment --container --share=$HOME=/exchange guile -- guile
+@end example
 @end table
 
 It also supports all of the common build options that @command{guix
@@ -7064,6 +7119,7 @@ This command also installs GRUB on the device specified in
 @item vm
 @cindex virtual machine
 @cindex VM
+@anchor{guix 

Re: Giving up on RubyGems

[Thompson, David]

Hi Pjotr,

This cheered me up!

On Wed, Oct 21, 2015 at 5:46 AM, Pjotr Prins  wrote:
> Hi Dave,
>
> You know I am not so much interested in fixing upstream concepts which
> appear to be mixed up (indeed). I think you are heroic for trying to
> discuss this with the Rubygem system authors. Kudos for trying.

Thanks!

> Still: GNU Guix Rubygem support is a major achievement.
>
> Fact is that:
>
> 1. We have successfully packaged rubygems for guix in a simple and
>elegant way. I use them daily.
>
> 2. Enough tests are in there to make sure things work - in fact I was
>mighty surprised that Nokogiri works on ARM+MIPS, despite the fact
>that we haven't gotten the Nokogiri test system to work - and that
>it works was tested by virtue of my bio-blastxmlparser gem which
>*has* working tests.
>
> 3. Rubygems does not dictate how people package their gems. In fact,
>if need be, we can also repackage into rubygems and deploy those.
>We may even influence the upstream authors.

All good points.  You're right.  I shouldn't think that we've
accomplished nothing, because we have done a lot.

> I agree the Rubygem situation is not ideal and the maybe Rubygems
> people are misguided in their architectural choices. But I think they
> will probably converge towards our ideas in time. When a choice, such
> as no tests, or using git fuzzily, starts to bite, they will want to
> revert on that. I also love your argumentation that they should
> provide the source code next to the 'binary' distribution. Totally
> valid and in line with most licenses in use, including the Ruby
> license. Maybe the FSF should threaten a case.

Perhaps I could find a gem that is GPL licensed whose archive doesn't
include the corresponding source code, but it seems like finding a
needle in a haystack.  It probably doesn't exist.

> With Linux distributions and languages you can just see people
> reinventing the wheel (npm, pip, docker, firefox anyone?). It is
> amazing how much energy goes into all the combined packaging systems
> when they could simply be using Guix ;)
>
> Still, it is a form of evolution. Each his own (imperfect) niche.
>
> For us, I think we have to be purely pragmatic. I love the current
> Ruby build system in Guix and will use it for those gems that allow
> inclusion. It has to be source (anyway) to build against the Guix
> ruby-build-system.
>
> And when it fails we find some other way. It is simply software, i.e.,
> we can always fix it.

Yes, agreed.  We will evaluate on a case-by-case basis whether or not
the gem archive on rubygems.org meets our standards.  I will write a
patch sometime to add the 'gitify' phase back to the Ruby build system
as an optional phase for cases where we need to build from a tarball
or git checkout.

> So, yes, I think it is wise to give up on the rubygem authors for now.
>
> But please don't stop loving - the people who use - Ruby :)

I won't.  Thanks for cheering me up, Pjotr. :)

- Dave

[PATCH] build: Do not clobber existing files when bind mounting.

[Thompson, David]

This really bit me while trying to wrap up the tests for 'guix
environment --container'.  Thanks to Ludovic for tracking this down!

- Dave
From 482a31152260f48d1e96ffe74a2b1a9898d5f09c Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Fri, 16 Oct 2015 14:00:00 -0400
Subject: [PATCH] build: Do not clobber existing files when bind mounting.

* gnu/build/file-systems.scm (mount-file-system): Do not touch
  'mount-point' if it already exists.
---
 gnu/build/file-systems.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 377bec2..df6d3da 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -347,7 +347,8 @@ run a file system check."
;; Create the mount point.  Most of the time this is a directory, but
;; in the case of a bind mount, a regular file may be needed.
(if (and (= MS_BIND (logand flags MS_BIND))
-(regular-file? source))
+(regular-file? source)
+(not (file-exists? mount-point)))
(begin
  (mkdir-p (dirname mount-point))
  (call-with-output-file mount-point (const #t)))
-- 
2.5.0

Re: Plan for 0.9.0

[Thompson, David]

On Thu, Oct 15, 2015 at 8:28 AM, Mathieu Lirzin  wrote:
> Eric Bavier  writes:
>
>> On Wed, 14 Oct 2015 23:44:39 +0200
>> l...@gnu.org (Ludovic Courtès) wrote:
>>
>>> Mathieu Lirzin  skribis:
>>>
>>> > l...@gnu.org (Ludovic Courtès) writes:
>>> >
>>> >> Dunno, I admit I’m not as enthusiastic as the other people here.  :-)
>>> >>
>>> >> What would ‘guix gc’ (without any option) do?
>>> >
>>> > Show --help and exit(0)?  ;)
>>>
>>> Sure we could do that, but I’m not convinced it’s an improvement.  WDYT?
>>
>> FWIW, I'm not convinced either.
>
> I think the enthusiasm for changing ‘guix gc’ was induced by somekind of
> shared experience of typing it loosely and ending up having to download
> a lot of substitutes again.  So maybe we can keep ‘guix gc’ as it is but
> make it interactive by listing what is going to be deleted and ask for
> confirmation with a [Y/n] prompt.  This solution will also require
> somekind of a ‘--force’ option for scripting purposes.
>
> Does it sound better?

In general, I do not like interactive CLIs.  I'm fine with 'guix gc'
working as-is.  The re-downloading lots of substitutes issue is not an
issue about the CLI, but rather about not making store items that you
want to hang around GC roots.

- Dave

Re: Plan for 0.9.0

[Thompson, David]

On Thu, Oct 15, 2015 at 8:51 AM, Mathieu Lirzin <m...@openmailbox.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> writes:
>
>> On Thu, Oct 15, 2015 at 8:28 AM, Mathieu Lirzin <m...@openmailbox.org> wrote:
> [...]
>>> I think the enthusiasm for changing ‘guix gc’ was induced by somekind of
>>> shared experience of typing it loosely and ending up having to download
>>> a lot of substitutes again.  So maybe we can keep ‘guix gc’ as it is but
>>> make it interactive by listing what is going to be deleted and ask for
>>> confirmation with a [Y/n] prompt.  This solution will also require
>>> somekind of a ‘--force’ option for scripting purposes.
>>>
>>> Does it sound better?
>>
>> In general, I do not like interactive CLIs.  I'm fine with 'guix gc'
>> working as-is.  The re-downloading lots of substitutes issue is not an
>> issue about the CLI, but rather about not making store items that you
>> want to hang around GC roots.
>
> You mean a problem between the keyboard and the chair, or a problem with
> the GC being too greedy?

The GC is not too greedy.  It's doing exactly what it should.  The
issue is that we need more tools to let people protect things from the
GC that they want protected.  One example that is that 'guix
environment' will eventually generate profiles that are registered as
GC roots, which will protect development environments from the GC.

- Dave

Re: [PATCH] gnu: abbaye: Use 'sdl-union'.

[Thompson, David]

On Tue, Oct 13, 2015 at 6:34 AM, Alex Kost  wrote:
> Ludovic Courtès (2015-10-12 19:35 +0300) wrote:
>
>> Alex Kost  skribis:
>>
> [...]
>>> Actually, I think it will be more clear to use 'sdl-union' here, because
>>> the workaround is more concise, WDYT?
>>
>> Indeed.
>
> What about using 'sdl-union' in ‘abbaye’ as well?
>
> I have switched ‘abbaye’ to 'modify-phases' syntax, but since it is
> trivial I didn't send the patch for it (I hope it's OK).

LGTM.  Thanks!

- Dave

Re: [PATCH 02/12] guix: Add a "pypi-uri" helper method.

[Thompson, David]

On Tue, Oct 13, 2015 at 3:47 AM, Ricardo Wurmus
 wrote:
>
> Cyril Roelandt  writes:
>
>> * guix/download.scm (mirrors): New "pypi" mirror.
>> * guix/build-system/python.scm (pypi-uri): New method.
>
> It’s a good idea to provide “pypi-uri”!  But why is a mirror entry
> required when “pypi.python.org” is the only source for packages?

Yeah, get rid of the mirror thing and this patch looks good to me.

- Dave

Re: Outdated config.scm in development repo

[Thompson, David]

On Tue, Oct 13, 2015 at 2:08 PM, Taylan Ulrich Bayırlı/Kammer
 wrote:
> From what I can tell this situation I landed in doesn't involve any bugs
> and won't happen to a normal user, but for the sake of documenting it
> for developers, here goes:
>
> I have $XDG_CONFIG_HOME/guix/latest point to a git repository so I can
> update it swiftly.
>
> In the repo, a ./guix/config.scm is generated from ./guix/config.scm.in
> sometimes, I guess on ./configure; I haven't tried to figure out exactly
> when but certainly not every time I run 'make'.
>
> That config.scm will contain absolute paths to gzip, bzip2, and some
> other things.  If you used a Guix environment to build, those will be
> /gnu/store/... paths.
>
> When you update things and garbage-collect, those store items might get
> removed, since $XDG_CONFIG_HOME/guix/latest/guix/config.scm is not a GC
> root (rightly so, as far as I understand).  And thus, guix commands will
> start failing, saying they can't find /gnu/store/.../bin/bzip2 or
> whatever.
>
> That sums up the problem description.
>
> Fixing it might be tricky if you need to use 'guix environment' to run
> ./configure or whatever to fix the config.scm, since you possibly first
> need to fix the issue to be able to use 'guix environment' (it will work
> only if no calls are made to the missing /gnu/store/... executables).
>
> Manually fixing the config.scm is easy, fortunately.  Just change the
> absolute /gnu/store/... paths which point at non-existing store items to
> point to existing store items.

Some day 'guix environment' will allow one to create a profile and
register it as a GC root and avoid this issue.

- Dave

Re: [PATCH] build: container: Fix call-with-clean-exit.

[Thompson, David]

On Fri, Oct 9, 2015 at 5:59 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> From dc72ee831d6c6b93cf404a7fd1abc4b8fb27b7f2 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Fri, 9 Oct 2015 12:33:40 -0400
>> Subject: [PATCH] build: container: Fix call-with-clean-exit.
>>
>> Before, call-with-clean-exit would *always* return an exit code of 1.
>>
>> * gnu/build/linux-container.scm (call-with-clean-exit): Exit with status
>>   code of 0 if thunk does not throw an exception.
>> * tests/containers.scm: Add test.
>
> LGTM, thanks.

Pushed, thanks.

- Dave

Re: [PATCH 2/2] gnu: Add manaplus.

[Thompson, David]

On Fri, Oct 9, 2015 at 8:40 AM, Ludovic Courtès  wrote:
> Alex Kost  skribis:
>
>> I don't know if there is a better workaround for the SDL headers, but
>> this problem is rather common: there is a workaround in 'abbaye' and a
>> special patch for 'pingus'.
>>
>> The problem is: the source code has lines like this:
>>
>>   #include 
>>
>> but the headers of all SDL packages are placed in “include/SDL/”
>> subdirectories.  And an upstream often doesn't use "pkg-config" for
>> every SDL package to define CFLAGS and assumes that all SDL headers are
>> placed in one directory.  So we have to invent workarounds for such
>> packages.
>>
>> I just mention this problem here, perhaps someone will come up with a
>> general solution.
>
> Can’t ‘sdl-union’ be used here?  I think it was created specifically to
> solve this problem.  (Currently it’s private to (gnu packages sdl) but
> you can export it.)

Do you have any concerns about this package being picked up by UIs now
that it will be public?  Might confuse a user or two, dunno.

- Dave

Re: Using 'system*' instead of 'system' in 'guix environment'

[Thompson, David]

On Fri, Oct 9, 2015 at 8:23 AM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> From 4be0c2bfd2e2e9a03d860cfb2ff92aa66cbfaa70 Mon Sep 17 00:00:00 2001
>> From: David Thompson <dthomps...@worcester.edu>
>> Date: Thu, 8 Oct 2015 21:23:09 -0400
>> Subject: [PATCH] scripts: environment: Use system* instead of system.
>>
>> This allows for direct program invokation without needing a shell to act
>> as a command interpreter.
>>
>> * guix/scripts/environment.scm (%default-shell): New variable.
>>   (show-help): Adjust description.  Remove '--exec' reference.
>>   (%default-options): Use '%default-shell'.
>>   (%options): Adjust '--exec' to run command via the default shell.
>>   (parse-args): New procedure.
>>   (guix-environment): Use 'parse-args'.  Use 'system*' instead of
>>   'system'.
>> * guix/utils.scm (split): New procedure.
>> * tests/guix-environment.sh: Adjust tests to use '--' instead of
>>   '--exec'.
>> * tests/utils.scm: Add tests for 'split'.
>> * doc/guix.texi ("Invoking guix environment"): Use new syntax.  Remove
>>   '--exec' documentation.
>
> Looks good to me.  Could you just add ‘split’ in a separate commit?
>
>>   (option '(#\E "exec") #t #f
>
> Add a “deprecated” comment.
>
>>  # Make sure the exit value is preserved.
>> -if guix environment --ad-hoc guile-bootstrap --pure -E 'guile -c "(exit 
>> 42)"'
>> +if guix environment --ad-hoc guile-bootstrap --pure -- guile -c '(exit 42)'
>
> Could you keep the example with -E, in addition to the new one, with a
> comment noting that this is the deprecated syntax?  We’ll remove it when
> we finally remove -E.
>
> OK with these changes, thank you!

Thanks, fixed and pushed 2 commits.

- Dave

Re: Using 'system*' instead of 'system' in 'guix environment'

[Thompson, David]

On Thu, Oct 8, 2015 at 3:53 AM, Ludovic Courtès  wrote:
> Hi!
>
> David Thompson  skribis:
>
>> In an effort to finish up a patch to add a --container flag to 'guix
>> environment', I've encountered a serious problem.  The --exec flag
>> allows the user to pass an arbitrary command to be run using 'system'.
>> Unlike 'system*', 'system' spawns a command interpreter first and passes
>> the command string in.  This is very problematic when using a container,
>> because there's a very good chance that the command interpreter of the
>> running Guile process is not mounted inside the container.
>
> Oooh, good catch!
>
> How about using something like:
>
>   (system* (or (the-container-shell) (getenv "SHELL") "/bin/sh")
>"-c" the-string)

Yes, that could work.  I've tried that but I don't love it.  More
about that below.

>> If the above explanation is confusing, the 'sudo' program provides a
>> good example of the UI I'm after:
>>
>> sudo guile -c '(do-root-things)'
>
> Or similarly: “ssh HOST some command and arguments”.
>
>> But for now we're stuck with this:
>>
>> guix environment --ad-hoc guile -E "guile -c '(do-root-things)'"
>>
>> Now, we can't actually do exactly what 'sudo' does because 'guix
>> environment' already recognizes operands as package names, not program
>> arguments.  Perhaps we can use '--' to separate the package list from
>> the command to run:
>>
>> guix environment --ad-hoc guile -- guile -c '(do-root-things)'
>>
>> Does that look okay?  Any other ideas?
>
> I really like the UI that you propose; using -- to separate the
> arguments sounds good.
>
> I think it’s orthogonal to the question of whether to use ‘system’ or
> not though.
>
> Currently one can do things like:
>
>   guix environment foo -E 'cd /bar ; frob'
>
> and I think we should keep this capability, which means running the
> command via /bin/sh -c (which is what ‘system’ does, but we can use
> ‘system*’ the way I wrote above to achieve that.)
>
> So I think the new UI should essentially ‘string-join’ everything that
> comes after --, and pass that to the procedure that invokes sh -c.

I disagree, and here's why.  Going back to the sudo/ssh example, it's
not possible to do 'cd /bar; frob' naively because this...

sudo cd /bar; frob

...is two commands.  And this doesn't work either because it's not a
valid string for exec:

sudo 'cd /bar; frob'

However, we can just do the 'sh -c' trick!

sudo sh -c 'cd /bar; frob'

This is essentially what you propose having built-in, but I think it
would be best to leave it out.  That way we can simply use 'system*'
and users that want to execute an inline Bash script can do so using
the method they most likely already know about from tools like sudo
and ssh.

guix environment --ad-hoc guile -- guile -c '(frob)'

guix environment --ad-hoc guile -- sh -c "cd bar/; guile -c '(frob)'"

This has the additional advantage that the first process created
inside containers will be PID 1, not 2.

Does this counter-proposal sound OK?

- Dave

Re: Using 'system*' instead of 'system' in 'guix environment'

[Thompson, David]

On Thu, Oct 8, 2015 at 10:59 AM, Ludovic Courtès  wrote:

> I guess we must still support -E for compatibility.  Probably it should
> do an implicit ‘sh -c’?

This introduces implementation issues.  What if a user provides both a
-E command *and* a command after '--'?  What's the sane thing to do?

I also don't feel strongly that we need to keep flags around for
compatibility this early in the game, given that we are alpha software
and such.

Thoughts?

- Dave

Re: Using 'system*' instead of 'system' in 'guix environment'

[Thompson, David]

On Thu, Oct 8, 2015 at 12:05 PM, Taylan Ulrich Bayırlı/Kammer
<taylanbayi...@gmail.com> wrote:
> "Thompson, David" <dthomps...@worcester.edu> writes:
>
>> On Thu, Oct 8, 2015 at 10:59 AM, Ludovic Courtès <l...@gnu.org> wrote:
>>
>>> I guess we must still support -E for compatibility.  Probably it should
>>> do an implicit ‘sh -c’?
>>
>> This introduces implementation issues.  What if a user provides both a
>> -E command *and* a command after '--'?  What's the sane thing to do?
>>
>> I also don't feel strongly that we need to keep flags around for
>> compatibility this early in the game, given that we are alpha software
>> and such.
>>
>> Thoughts?
>
> I thought it would be nice to keep also for convenience...
>
> -E 'foo' is somewhat nicer than -- sh -c 'foo'.

But this is not a very common case (citing my own personal experience
and sudo, ssh, and other programs that use this pattern), and now we
have to deal with precedence rules in the argument parser.  If we have
to keep -E, then I would rather not implement the '--' stuff.

- Dave

Re: Using 'system*' instead of 'system' in 'guix environment'

[Thompson, David]

On Thu, Oct 8, 2015 at 12:53 PM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Thu, Oct 8, 2015 at 10:59 AM, Ludovic Courtès <l...@gnu.org> wrote:
>>
>>> I guess we must still support -E for compatibility.  Probably it should
>>> do an implicit ‘sh -c’?
>>
>> This introduces implementation issues.  What if a user provides both a
>> -E command *and* a command after '--'?  What's the sane thing to do?
>
> I’d consider this a bug in the user’s mind ;-) and would do whatever is
> easiest.

Okay.  Will do.

>> I also don't feel strongly that we need to keep flags around for
>> compatibility this early in the game, given that we are alpha software
>> and such.
>
> I think it’s neither black nor white.
>
> For instance, I use it at work for continuous integration.  I can
> definitely migrate the scripts to the new syntax, but it’s best if it
> doesn’t break overnight.

I didn't know that you were one the users in question. ;)

> So we could remove -E from ‘--help’ and from the manual, but still keep
> it around for a while.

That sounds good.

- Dave

Re: Using 'system*' instead of 'system' in 'guix environment'

[Thompson, David]

On Thu, Oct 8, 2015 at 12:53 PM, Ludovic Courtès <l...@gnu.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Thu, Oct 8, 2015 at 10:59 AM, Ludovic Courtès <l...@gnu.org> wrote:
>>
>>> I guess we must still support -E for compatibility.  Probably it should
>>> do an implicit ‘sh -c’?
>>
>> This introduces implementation issues.  What if a user provides both a
>> -E command *and* a command after '--'?  What's the sane thing to do?
>
> I’d consider this a bug in the user’s mind ;-) and would do whatever is
> easiest.
>
>> I also don't feel strongly that we need to keep flags around for
>> compatibility this early in the game, given that we are alpha software
>> and such.
>
> I think it’s neither black nor white.
>
> For instance, I use it at work for continuous integration.  I can
> definitely migrate the scripts to the new syntax, but it’s best if it
> doesn’t break overnight.
>
> So we could remove -E from ‘--help’ and from the manual, but still keep
> it around for a while.

Here is the patch that does this.

Thanks,

- Dave
From 4be0c2bfd2e2e9a03d860cfb2ff92aa66cbfaa70 Mon Sep 17 00:00:00 2001
From: David Thompson <dthomps...@worcester.edu>
Date: Thu, 8 Oct 2015 21:23:09 -0400
Subject: [PATCH] scripts: environment: Use system* instead of system.

This allows for direct program invokation without needing a shell to act
as a command interpreter.

* guix/scripts/environment.scm (%default-shell): New variable.
  (show-help): Adjust description.  Remove '--exec' reference.
  (%default-options): Use '%default-shell'.
  (%options): Adjust '--exec' to run command via the default shell.
  (parse-args): New procedure.
  (guix-environment): Use 'parse-args'.  Use 'system*' instead of
  'system'.
* guix/utils.scm (split): New procedure.
* tests/guix-environment.sh: Adjust tests to use '--' instead of
  '--exec'.
* tests/utils.scm: Add tests for 'split'.
* doc/guix.texi ("Invoking guix environment"): Use new syntax.  Remove
  '--exec' documentation.
---
 doc/guix.texi| 16 ++--
 guix/scripts/environment.scm | 38 ++
 guix/utils.scm   | 18 ++
 tests/guix-environment.sh|  4 ++--
 tests/utils.scm  | 14 ++
 5 files changed, 66 insertions(+), 24 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 6da7281..39b76c7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4538,11 +4538,12 @@ and Emacs are available:
 guix environment guile emacs
 @end example
 
-Sometimes an interactive shell session is not desired.  The
-@code{--exec} option can be used to specify the command to run instead.
+Sometimes an interactive shell session is not desired.  An arbitrary
+command may be invoked by placing the @code{--} token to separate the
+command from the rest of the arguments:
 
 @example
-guix environment guile --exec=make
+guix environment guile -- make -j4
 @end example
 
 In other situations, it is more convenient to specify the list of
@@ -4551,7 +4552,7 @@ runs @command{python} from an environment containing Python@tie{}2.7 and
 NumPy:
 
 @example
-guix environment --ad-hoc python2-numpy python-2.7 -E python
+guix environment --ad-hoc python2-numpy python-2.7 -- python
 @end example
 
 The available options are summarized below.
@@ -4582,11 +4583,6 @@ As an example, @var{file} might contain a definition like this
 @verbatiminclude environment-gdb.scm
 @end example
 
-
-@item --exec=@var{command}
-@item -E @var{command}
-Execute @var{command} in the new environment.
-
 @item --ad-hoc
 Include all specified packages in the resulting environment, as if an
 @i{ad hoc} package were defined with them as inputs.  This option is
@@ -4596,7 +4592,7 @@ package expression to contain the desired inputs.
 For instance, the command:
 
 @example
-guix environment --ad-hoc guile guile-sdl -E guile
+guix environment --ad-hoc guile guile-sdl -- guile
 @end example
 
 runs @command{guile} in an environment where Guile and Guile-SDL are
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 7aa52e8..d35ab18 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -57,6 +57,9 @@ OUTPUT) tuples."
 (define %precious-variables
   '("HOME" "USER" "LOGNAME" "DISPLAY" "TERM" "TZ" "PAGER"))
 
+(define %default-shell
+  (or (getenv "SHELL") "/bin/sh"))
+
 (define (purify-environment)
   "Unset almost all environment variables.  A small number of variables such
 as 'HOME' and 'USER' are left untouched."
@@ -103,9 +106,9 @@ existing environment variables with additional search paths."
 ,@(package-transitive-propagated-inputs package)))
 
 (define (show-help)
-  (display (_ "Usage: gui

Re: [PATCH] 11 little Ruby gems.

[Thompson, David]

On Tue, Oct 6, 2015 at 10:55 AM, Ben Woodcroft  wrote:
>
> Stupidly not being aware of this thread I believe I've got ruby-yard
> packaged without disabling tests just now, by packaging rspec-2 (and
> skipping the 2 remaining failing tests that write to /homeless-shelter). I
> think that issue on github might be incorrect (there's no rspec 2.14.3 on
> rubygems only 2.14.1 which seems to work for me). It actually means 4 new
> rspec-2 packages in total, there's no dependency issues beyond rspec I don't
> think. Would you like me to send patches? My suspicion is that there might
> be other packages that rely on rspec-2 out there, but that's just a hunch
> more than anything.

Since you've already got it packaged, then I think we should do that.
The migration from Rspec 2 -> 3 is nontrivial so I won't be surprised
if we run into other gems that use Rspec 2.  Regarding the
/homeless-shelter thing, you should be able to make those tests pass
by creating some directory in the source tree and set HOME to it.

In short, yes, your patches are very welcome.  Thanks!

- Dave

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

[Thompson, David]

On Mon, Oct 5, 2015 at 5:08 PM, Alex Kost <alez...@gmail.com> wrote:
> Thompson, David (2015-10-05 19:19 +0300) wrote:
>
>> On Sun, Oct 4, 2015 at 3:15 PM, Alex Kost <alez...@gmail.com> wrote:
>>> Is there a suitable module for this library?
>>
>> It's intended for video games, so how about (gnu packages game-development)?
>
> I thought that game-development is intended only for the tools that are
> useful for developing games, not the ones that are needed at the game
> run-time, and that's why (gnu packages games) doesn't include
> game-development module.  But if it's OK to use (gnu packages
> game-development) in (gnu packages games), I will move physfs there.

Yes, that's fine I think.  I never such a distinction in my mind about
this, but maybe someone else does.

- Dave

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

[Thompson, David]

On Sun, Oct 4, 2015 at 3:15 PM, Alex Kost  wrote:
> Is there a suitable module for this library?

It's intended for video games, so how about (gnu packages game-development)?

- Dave

Re: [PATCH] gnu: Add file-roller.

[Thompson, David]

On Sun, Sep 20, 2015 at 12:54 PM, Ludovic Courtès  wrote:
> David Thompson  skribis:
>
>> +(description "File Roller is an archive manager for the GNOME desktop
>> +environment.")
>
> In addition to Ricardo’s comment, could you expound on this a little
> bit?  I’m not completely sure what it means to manage archives.  :-)

I moved the propagated inputs to inputs, changed the description to this:

File Roller is an archive manager for the GNOME desktop
environment that allows users to view, unpack, and create
compressed archives such as gzip tarballs.

And pushed.  Thanks!

- Dave

Re: guix on savannah

[Thompson, David]

On Mon, Sep 28, 2015 at 9:53 PM, Dika Setya Prayogi
 wrote:
> is guixsd are combined in guix project in savannah ? because there is
> no guixsd project in savannah but guix only is available.

Yes, everything is in the Guix project.

- Dave

Re: Service refactoring

[Thompson, David]

On Mon, Sep 21, 2015 at 12:00 PM, Ludovic Courtès  wrote:
> Andy Wingo  skribis:
>
>> On Sun 20 Sep 2015 15:42, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> I’m quite happy with the result, but comments are welcome!  I’ll convert
>>> some more services to see how it goes.
>>
>> Neat!  Sounds great.  One question: there are some services like colord
>> or geoclue that don't need to be managed by DMD, but are just declared
>> as services so that their users are created, there /var/foo directories
>> are created, etc.  The can be started by D-Bus as needed.  Does the new
>> design support services of this kind?
>
> Yes it does.
>
> ‘colord’ will “extend” the D-Bus service by giving it its package object
> (thus its .service files), it will extend the activation service by
> providing it #~(mkdir "/var/foo"), and it will extend the account
> service by passing it its user accounts/groups.

I'm picturing an enhanced 'nginx-service' that is able to accept site
configuration files from other services (say, a MediaGoblin service)
and it sounds like a great feature.  Now, is the following scenario
possible?: 'mediagoblin-service' can extend both 'apache-service' and
'nginx-service', and when the system configuration is realized, the
web service the user has chosen is extended.

This is really great stuff.  :)

- Dave

Re: [PATCH] gnu: Add file-roller.

[Thompson, David]

On Sun, Sep 20, 2015 at 11:34 AM, Ricardo Wurmus  wrote:
> Looks good to me!
>
> I have one question about the propagated inputs, though: why are they
> needed?  Is it obvious (and I just fail to see it), or could you explain
> this in a comment?

I noticed that the inputs were propagated in another package, so I monkey typed.

- Dave

Re: [PATCH] Fix OpenAL backends.

[Thompson, David]

On Sun, Sep 20, 2015 at 7:15 AM, Ricardo Wurmus  wrote:
> Hi Guix,
>
> as I tested my new “mars” package I noticed that there was no sound.
> Investigating a little showed that the problem is in our “openal”
> package, which loads backend libraries by name only, not by path.
>
> The attached patch fixes this by patching in the full paths for
> libasound and libpulse, so now I have sound in “mars” :)

Awesome!  This fixed sound in Minetest, too.  Thanks!

- Dave

Re: [PATCH] Add MARS shooter.

[Thompson, David]

On Sat, Sep 19, 2015 at 4:06 PM, Ricardo Wurmus <rek...@elephly.net> wrote:
>
> Thompson, David <dthomps...@worcester.edu> writes:
>
>>> “Content-Type: .gz” is what trips up “guix download”.  What follows
>>> “Content-Type:” should be a mime type and I suppose “.gz” is not a valid
>>> mime type.  Would it make sense for the HTTP client to be a little more
>>> tolerant about this?
>>
>> No, upstream needs to fix their invalid Content-Type header.  We've
>> had this problem a few times, most recently with rubygems.org, and in
>> all cases we've gotten upstream to fix it.  Strict header parsing can
>> seem like an issue at times, but it's really a very good feature that
>> the rest of the world seems to ignore. [0]
>
> I wonder what a correct Content-Type header would look like in this
> case.  I would like to submit a helpful report containing what I got and
> what it should have been.

In this case, application/x-gzip or application/octet-stream would be
appropriate.  Less specifically, the media type needs to match the
syntax as defined by the W3C spec. [0]

> However, this is independent from the patch itself where I’m using a git
> reference.

Ah yes, you are right. :)

- Dave

[0] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7

Re: [PATCH 1/2] gnu: Add ruby-docile.

[Thompson, David]

On Wed, Sep 16, 2015 at 12:06 AM, Pjotr Prins  wrote:
> * gnu/packages/ruby.scm (ruby-docile): New variable.
> ---
>  gnu/packages/ruby.scm | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
> index 7dc46b6..539b00b 100644
> --- a/gnu/packages/ruby.scm
> +++ b/gnu/packages/ruby.scm
> @@ -1125,6 +1125,28 @@ into a single method call.")
>  (home-page "http://rack.github.io/;)
>  (license license:expat)))
>
> +(define-public ruby-docile
> +  (package
> +(name "ruby-docile")
> +(version "1.1.5")
> +(source
> +  (origin
> +(method url-fetch)
> +(uri (rubygems-uri "docile" version))
> +(sha256
> +  (base32
> +"0m8j31whq7bm5ljgmsrlfkiqvacrw6iz9wq10r3gwrv5785y8gjx"
> +(build-system ruby-build-system)
> +(arguments
> + '(#:tests? #f)) ; needs github-markup, among others
> +(synopsis "Docile turns any Ruby object into a DSL")
> +(description "Turn any Ruby object into a DSL.  Especially useful
> +with the Builder pattern.  Docile is a small, self-contained Ruby
> +library, that let's you map a DSL (domain specific language) to your
> +Ruby objects in a snap.")

A lot of times, the upstream description of software reads like an
advertisement or doesn't well define their terms, so we need to come
up with an appropriate description ourselves.  I changed the synopsis
and description as follows:

(synopsis "Ruby EDSL helper library")
(description "Docile is a Ruby library that provides an interface for
creating embedded domain specific languages (EDSLs) that manipulate existing
Ruby classes.")


> +(home-page "https://ms-ati.github.io/docile/;)
> +(license license:expat)))
> +
>  (define-public ruby-gherkin3
>(package
>  (name "ruby-gherkin3")
> @@ -1147,3 +1169,4 @@ It is intended to replace Gherkin 2 and be used by all 
> Cucumber
>  implementations to parse '.feature' files.")
>  (home-page "https://github.com/cucumber/gherkin3;)
>  (license license:expat)))
> +

I removed this extraneous whitespace change.

> --
> 2.4.3
>
>

Pushed.  Thanks.

- Dave