Re: [PATCH maintenance] hydra: services: Reload nginx when certbot updates certificates.

[Carlo Zancanaro]

On Mon, Jun 17 2024, Ludovic Courtès wrote:
> Right.  However, issues.guix.gnu.org is actually hosted on bayfront,

I'm not so sure about this. To make the change that I sent I grepped for
issues.guix.gnu.org and it showed up in hydra/nginx/berlin.scm in a
variable called %berlin-servers, which is used in %nginx-configuration
in that same file. This is included into hydra/berlin.scm and used in
the nginx configuration for berlin.guix.gnu.org.

>From that, I assumed that issues.guix.gnu.org was hosted on berlin. If
I'm wrong about that then I'm very confused!

Carlo

[PATCH maintenance] hydra: services: Reload nginx when certbot updates certificates.

[Carlo Zancanaro]

* hydra/modules/sysadmin/services.scm (%certbot-deploy-hook): New
variable.
(%certbot-job): Pass %certbot-deploy-hook to certbot invocation.
---

I think this patch should resolve the certificate issue more
permanently. I haven't tested it at all, but I mostly just stole it
from Guix's certbot service. I know it works there, so I'm just
assuming it will work here, too.

 hydra/modules/sysadmin/services.scm | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/hydra/modules/sysadmin/services.scm 
b/hydra/modules/sysadmin/services.scm
index 128b0c1..3d996f5 100644
--- a/hydra/modules/sysadmin/services.scm
+++ b/hydra/modules/sysadmin/services.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2023 Andreas Enge 
 ;;; Copyright © 2023 Lars-Dominik Braun 
 ;;; Copyright © 2024 Arun Isaac 
+;;; Copyright © 2024 Carlo Zancanaro 
 ;;;
 ;;; This program is free software: you can redistribute it and/or modify
 ;;; it under the terms of the GNU General Public License as published by
@@ -616,11 +617,19 @@ to a selected directory.")
   `(("nginx" ,(file-append nginx "/share/nginx/conf")
 
 
+(define %certbot-deploy-hook
+  ;; Reload nginx after a new certificate is deployed.
+  (with-imported-modules '((gnu services herd))
+#~(begin
+(use-modules (gnu services herd))
+(with-shepherd-action 'nginx ('reload) result result
+
+
 (define %certbot-job
   ;; Attempt to renew the Let's Encrypt certificate twice a week.
   #~(job "30 0 * * 2,5"
  (string-append #$certbot "/bin/certbot renew \
---webroot --webroot-path /var/www")))
+--webroot --webroot-path /var/www --deploy-hook " #$certbot-deploy-hook)))
 
 
 

base-commit: 489fc437c7b3aa0af41a40d6090eb4c51ced0028
-- 
2.41.0

Re: Call for contribution to the Guix infrastructure

[Carlo Zancanaro]

Hi Ludo,

On Fri, May 24 2024, Ludovic Courtès wrote:
>   • Day-to-day system administration
>
> We’re also looking for people who’d be willing to have SSH access to
> some of the infrastructure to help with day-to-day maintenance:
> restarting a build, restarting the occasional service that has gone
> wild (that can happen :-)), reconfiguring/upgrading a machine,
> rebooting, etc.

I think I could help with this. I can't guarantee that I'll always be
available, but I'm able and willing to help where I can.

> This day-to-day activity requires you to be available some of the
> time (during office hours or not, during the week-end or not),
> whenever is convenient for you, so you can react to issues reported
> on IRC, on the mailing list, or elsewhere, and synchronize with
> other sysadmins.

My timezone has generally made it hard for me to be actively involved in
real-time conversations about Guix (I'm in Australia), so hopefully that
wouldn't be too much of an impediment here. It might even be an asset,
if you don't already have people available in this timezone.

> Prerequisite: Being a “known” member of the community, familiarity
> with Guix System administration, with some of the services/web sites
> being run, and with the infrastructure handbook:
> 
> .

I'm not sure if I count as a "known" member of the community, but I have
been around the periphery for a while. My earliest commit that made it
into Guix is from 2016, and I made it to the Guix day in 2018. I have
been running my own personal infrastructure primarily on Guix since at
least 2018.

Carlo

Re: bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Carlo Zancanaro]

Apologies for the line breaks my earlier email. I'm not entirely sure
what happened, but hopefully they'll come through properly this time.

On Fri, Apr 12 2024, Felix Lechner wrote:
> To my surprise OpenSSL, which I saw in proced, generated a lot of
> certificates in /etc/certs.  I am talking about pages and pages of
> asterisk, plusses, and dots for a system with twenty or so certificates.
> Is it possible that they were generated as a result of the patch?

I expect the first reconfiguration after this change to create one self
signed certificate in /etc/certs for each 
object in your certbot configuration. These self-signed certificates
will then be replaced by symlinks to the certificates that cerbot
generates after your next renewal (i.e. when the deploy hook runs).

We could avoid generating unnecessary self-signed certificates by first
checking if we already have certificates from certbot, and creating the
symlink straight away if we can.

About the "pages and pages" of output: it might be sensible to change
the size of the self keys used in the self signed certificates. The
current code uses the rsa-key-size from the , or
4096 if that is unset (the default). This is probably overkill given we
don't actually need, or want, to use the initial certificates.

We could instead use the smallest key size that openssl supports (512?).

I'm not sure when I'll have time to make those changes, but they should
be pretty straightforward if someone else has time before I do.

> It would be unfavorable to create such certificates when they are not
> needed.  It reduces valuable server entropy.

If you don't want the initial self signed certificate you can tell Guix
not to generate it by setting start-self-signed? to #f on the
 object.

Carlo

Re: bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Carlo Zancanaro]

Hi Felix,

On Fri, Apr 12 2024, Felix Lechner wrote: 
To my surprise OpenSSL, which I saw in proced, generated a lot 
of certificates in /etc/certs.  I am talking about pages and 
pages of asterisk, plusses, and dots for a system with twenty or 
so certificates.  Is it possible that they were generated as a 
result of the patch?


I expect the first reconfiguration after this change to create one 
self signed certificate in /etc/certs for each 
 object in your certbot configuration. 
These self-signed certificates will then be replaced by symlinks 
to the certificates that cerbot generates after your next renewal 
(i.e. when the deploy hook runs).   We could avoid generating 
unnecessary self-signed certificates by first checking if we 
already have certificates from certbot, and creating the symlink 
straight away if we can.   About the "pages and pages" of output: 
it might be sensible to change the size of the self keys used in 
the self signed certificates. The current code uses the 
rsa-key-size from the , or 4096 if that is 
unset (the default). This is probably overkill given we don't 
actually need, or want, to use the initial certificates.   We 
could instead use the smallest key size that openssl supports 
(512?).   I'm not sure when I'll have time to make those changes, 
but they should be pretty straightforward if someone else has time 
before I do.


It would be unfavorable to create such certificates when they 
are not needed.  It reduces valuable server entropy.


If you don't want the initial self signed certificate you can tell 
Guix not to generate it by setting start-self-signed? to #f on the 
 object.


Carlo

Re: Contribute or create a channel?

[Carlo Zancanaro]

On Tue, Mar 12 2024, Attila Lendvai wrote:
> channels are a step towards this, but they are not enough in their
> current form to successfully accommodate for such a setup. an obvious
> thing that is missing is a way to formally express inter-channel
> dependencies, including some form of versioning.

Do we not have this? The manual documents a mechanism for channel
dependencies in "(guix) Declaring Channel Dependencies".

I haven't used it, but it looks like the dependencies are declared as
channels, which can have the usual branch/commit specifications to tie
them to specific versions.

What are we missing?

Carlo

Re: Proposal to turn off AOT in clojure-build-system

[Carlo Zancanaro]

As someone who has worked as a professional Clojure programmer, I would
like to add my voice in support of this:

On Mon, Feb 19 2024, Ryan Sundberg wrote:
> ... In my experience using AOT is the exception rather than the rule;
> it is a nice optimization when practical for release engineering, but
> typically the juice is not worth the squeeze.

That is: the norm in the Clojure community is *not* using AOT, so there
isn't any specific statement against it. It's just assumed that you
won't use AOT unless you have a reason to do so.

Reading the clojure.org page about compilation[1] with this in mind, we
see four possible (although admittedly not exhaustive) reasons to
provide AOT compilation:
 - to deliver your application without source
 - to speed up application startup
 - to generated named classes
 - to create an application that does not need runtime bytecode
   generation and custom classloaders

I'm not convinced any of these apply across the board in Guix.
Potentially for some libraries and applications it does, and so should
be applied in those specific cases.

The next statement on the page, after those reasons to use AOT is: "The
Clojure compilation model preserves as much as possible the dynamic
nature of Clojure, in spite of the code-reloading limitations of Java."
Or, to read it another way: AOT compiled Clojure is not as dynamic as
on-the-fly compiled Clojure. This isn't a bug in Clojure, this is how it
is designed to function.

It could be argued that it is a bug in the individual libraries to not
work with AOT, but I think it's inappropriate for Guix to attempt to
impose "AOT is the right way to do things" on Clojure libraries. That is
not the norm in that community.

As a personal datapoint: I spent three and a half years working on
mission-critical Clojure libraries and applications, and I have never
used AOT compilation in production.

Carlo

[1]: https://clojure.org/reference/compilation

Re: Intermediate abstraction of system service configuration

[Carlo Zancanaro]

On Tue, Feb 06 2024, Dale Mellor wrote:
>Agree that it would have repercussions throughout the package
> ecosystem.  I would have thought that it would make things easier.  You
> could argue that you don't benefit from the Guile syntax checker, but
> at the end of the day you don't find out you've made a mistake until
> you try to run `guix system reconfigure` anyway.

It might make things "easier" in one sense, but loosening the
constraints on one thing often makes some other part harder. In
particular, because of service extensions you can't rely on the whole
configuration being written in the same place, so we would need some
sort of merging logic for free-form configurations.

This merging logic would have to be service specific, but would
presumably need to perform its own shape checking (for good error
messages, if nothing else). Presumably this would require some sort of
type definitions, similar to what our current configuration system
requires (maybe with less boilerplate).

I'm sure it's possible to write a system that uses these things, and
there has been some idea of doing this in the past for nginx
specifically[1], but I'm not yet convinced it would actually be easier
across the board. Having used Nix (which has more free-form
configuration), I'm not sure that it's better than what Guix has.

I'm happy to be convinced, though, if you'd like to put together an
implementation. Maybe you could start with a single service (nginx) and
see how it comes together. I'm not a committer, so convincing me doesn't
get things into Guix, but presumably if you can convince me you can
convince a committer as well.

Carlo

[1]: https://issues.guix.gnu.org/37388

Re: ice-9 match penalty depending on pattern?

[Carlo Zancanaro]

> ./guix/docker.scm:261:  (((head ...) (tail ...) id)

This one is not like the others. However, looking at the context I think
the pattern could just be (head tail id).

> Why not?  Do I miss something in the implementation of ’match’?

The only reason I can think of would be if these matches are sometimes
provided improper lists, which need to fail these match conditions. That
seems unlikely to me, but it should be clear from looking at the other
match clauses in each case.

Carlo

Re: Experience using the Nix service as a novice user

[Carlo Zancanaro]

Hi Christian!

On Sun, Feb 04 2024, Christian Miller wrote:
> I wanted to try out the Nix service and followed the manual.  I had
> some trouble while doing so.  The following are the steps I took, the
> errors I encountered, and how I resolved them.  As well as feedback to
> the experience.

Thank you for this feedback!

I recently installed the Nix service myself, and ran into these rough
edges, but I didn't think to write them down or fix things. Thank you
for the clear and detailed prompt to do so.

I've just sent a patch to guix-patches with some updates to the manual
which attempts to add the pieces that you found were missing. Could you
have a look at that and make sure you're happy with what I've written?

> At this point, I started encountering problems.  The command
> "nix-channel --update" returns:
>
> unpacking channels...
> error: opening pseudoterminal master: No such device
> error: program
> '/gnu/store/mh2nc81cvw321q0lx4y38g4n7b86q88y-nix-2.16.1/bin/nix-env'
> failed with exit code 1
>
> This was easy to fix because I had found this solution[1]
>
> sudo herd restart nix-daemon

I didn't mention this in the manual, because this seems more like a bug
that should be fixed. I've also had the same issue, so I'll try to
investigate the next time it happens to see if I can fix it.

> I initially attempted this within a VM ($(guix system vm nix.scm) -m
> 4096 -smp 2) that had 4 GiB of memory and 2 cores.  The process was
> terminated. Is it normal for Nix to require such a large amount of
> resources to install a package?

I wouldn't expect it to need that much, unless it was needing to build
things from source. Usually Nix's substitute coverage is pretty good, so
I wouldn't expect you to need to build much from source.

Carlo

Re: Intermediate abstraction of system service configuration

[Carlo Zancanaro]

Hi Dale!

On Tue, Feb 06 2024, Dale Mellor wrote:
>There is no middle ground.

The nginx{,-upstream,-server}-configuration records have fields for
{extra,raw}-content, which do allow arbitrary configuration lines to be
added to their config. I think this is a sensible escape hatch to have
to provide this middle ground.

Andrew Tropin has done something interesting on the idea of more
free-form configuration for nginx specifically[1], but I don't think
that idea has found its way out of rde and into Guix yet.

>   I think that Guix taking the view of a configuration
> file as a nested set of string-named blocks containing
> lists of string-named, string-valued pairs would be an
> intermediate level of abstraction more suited to the
> Guix system configuration view of the world.

This sounds quite similar to the way that Nix represents their internal
configuration. Their model of configuring services is to have "Attribute
Sets" (i.e. key/value mappings) which specify the configuration of
services. Nix doesn't have service extension in the same way as Guix
does, however, so interactions between different services look very
different. We'd have to think carefully about how the Guix model of
service extension would work with such an intermediate representation.

Carlo

[1]: https://fosstodon.org/@abcdw/110180191828598277

Re: Introducing Guix "Features"!

[Carlo Zancanaro]

On Thu, Feb 01 2024, Felix Lechner via "Development of GNU Guix and the GNU 
System distribution." wrote:
> On Thu, Nov 30 2023, Attila Lendvai wrote:
>> the use of 'service' to describe two rather different abstractions: a
>> component of an OS vs. a deamon process run by shepherd.
>
> Indeed, the use of 'service' in much of Guix appears to be a grand
> misnomer. It probably occurred because the meaning expanded over time.

We can actually point to a specific moment when the meaning was
expanded. It was done in Guix 0.9.0:
https://guix.gnu.org/en/blog/2015/gnu-guix-090-released/

Here is a blog post introducing services back in 2015, which has a
heading "Services Beyond Daemons" which discusses the change to broaden
the term to encompass what Guix now calls a service:
https://guix.gnu.org/en/blog/2015/service-composition-in-guixsd/

There is also a talk that Ludovic gave at FOSDEM 2017 where he discusses
the ideas of Guix services (I can't remember the content of this, but it
seemed like it might be relevant):
https://archive.fosdem.org/2017/schedule/event/composingsystemservicesinguixsd/

This doesn't seem like accidental concept creep. This was an intentional
decision to use the word "service" to mean something specific.

I say this to note that any argument to change the term should first
understand why this decision was made (see: Chesterton's Fence).

Carlo

Re: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Carlo Zancanaro]

Hi Felix,

On Tue, Jan 30 2024, Felix Lechner wrote:

On Tue, Jan 30 2024, Carlo Zancanaro wrote:

certbot can't produce certificates without a functional nginx


Yes, it can. The option is called --standalone. [1]


You are correct, of course. If I had been more precise I would 
have said "with our current configuration, certbot can't produce 
certificates without a functional nginx".


Maybe another way to bootstrap the certificates would be to hold 
off on starting Nginx or Apache until all certificates are 
obtained?


This could work, but I see a few downsides.

As Clément has already mentioned, this would make nginx dependent 
on certbot. This causes problems for servers disconnected from the 
general internet, but it also shifts complexity into the nginx 
service without much benefit over the patch series I'm proposing. 
We'd need to add more configuration on the nginx side to control 
whether to delay startup based on whether we actually want 
certificates. This would delay the startup of the whole nginx 
process, even if some server configurations don't require new 
certificates.


For renewal, we would also have two options: (1) use --standalone, 
and require a period of downtime for our web server; or (2) use 
--webroot, and maintain two code paths for the two cases. I think 
it's a bad idea for Guix to make a decision that requires downtime 
of user systems if there's an alternative, so I don't like (1). 
Maintaining two "similar but different" code paths for (2) doesn't 
seem like a clear advantage over the patch series I'm proposing.



Anyway, that's what I do manually.


I use the DNS challenge type, with hooks which automatically 
create/remove DNS records. This solves all the problems I'm 
bringing up (i.e. doesn't require nginx, doesn't involve downtime, 
has a single code path), but I don't think Guix can assume that 
all users have the ability to do this. My aim with this patch 
series is to make the default certbot configuration work for the 
common case of a simple web server, without manual intervention.


Carlo

[PATCH v2 1/4] services: certbot: Symlink certificates to /etc/certs.

[Carlo Zancanaro]

* gnu/services/certbot.scm (certbot-deploy-hook): New procedure.
(certbot-command): Pass new deploy hook to certbot.
* doc/guix.texi: Replace "letsencrypt/live" with "certs" throughout.

Change-Id: I2ba5e4903d1e293e566b732a84b07d5a134b697d
---
 doc/guix.texi| 26 +-
 gnu/services/certbot.scm | 36 ++--
 2 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index bb0af26d93..b134d45a16 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -43,7 +43,7 @@
 Copyright @copyright{} 2017, 2018, 2019 Clément Lassieur@*
 Copyright @copyright{} 2017, 2018, 2020, 2021, 2022 Mathieu Othacehe@*
 Copyright @copyright{} 2017 Federico Beffa@*
-Copyright @copyright{} 2017, 2018 Carlo Zancanaro@*
+Copyright @copyright{} 2017, 2018, 2024 Carlo Zancanaro@*
 Copyright @copyright{} 2017 Thomas Danckaert@*
 Copyright @copyright{} 2017 humanitiesNerd@*
 Copyright @copyright{} 2017, 2021 Christine Lemmer-Webber@*
@@ -28135,7 +28135,7 @@ Messaging Services
 them.  See @url{https://prosody.im/doc/letsencrypt}.
 
 @example
-prosodyctl --root cert import /etc/letsencrypt/live
+prosodyctl --root cert import /etc/certs
 @end example
 
 The available configuration parameters follow.  Each parameter
@@ -28846,8 +28846,8 @@ Telephony Services
   (welcome-text
 "Welcome to this Mumble server running on Guix!")
   (cert-required? #t) ;disallow text password logins
-  (ssl-cert "/etc/letsencrypt/live/mumble.example.com/fullchain.pem")
-  (ssl-key "/etc/letsencrypt/live/mumble.example.com/privkey.pem")))
+  (ssl-cert "/etc/certs/mumble.example.com/fullchain.pem")
+  (ssl-key "/etc/certs/mumble.example.com/privkey.pem")))
 @end lisp
 
 After reconfiguring your system, you can manually set the mumble-server
@@ -28965,12 +28965,12 @@ Telephony Services
 File name of the SSL/TLS certificate used for encrypted connections.
 
 @lisp
-(ssl-cert "/etc/letsencrypt/live/example.com/fullchain.pem")
+(ssl-cert "/etc/certs/example.com/fullchain.pem")
 @end lisp
 @item @code{ssl-key} (default: @code{#f})
 Filepath to the ssl private key used for encrypted connections.
 @lisp
-(ssl-key "/etc/letsencrypt/live/example.com/privkey.pem")
+(ssl-key "/etc/certs/example.com/privkey.pem")
 @end lisp
 
 @item @code{ssl-dh-params} (default: @code{#f})
@@ -32685,7 +32685,7 @@ Certificate Services
 Command to be run in a shell once for each successfully issued
 certificate.  For this command, the shell variable
 @code{$RENEWED_LINEAGE} will point to the config live subdirectory (for
-example, @samp{"/etc/letsencrypt/live/example.com"}) containing the new
+example, @samp{"/etc/certs/example.com"}) containing the new
 certificates and keys; the shell variable @code{$RENEWED_DOMAINS} will
 contain a space-delimited list of renewed certificate domains (for
 example, @samp{"example.com www.example.com"}.
@@ -32694,8 +32694,8 @@ Certificate Services
 @end deftp
 
 For each @code{certificate-configuration}, the certificate is saved to
-@code{/etc/letsencrypt/live/@var{name}/fullchain.pem} and the key is
-saved to @code{/etc/letsencrypt/live/@var{name}/privkey.pem}.
+@code{/etc/certs/@var{name}/fullchain.pem} and the key is
+saved to @code{/etc/certs/@var{name}/privkey.pem}.
 @node DNS Services
 @subsection DNS Services
 @cindex DNS (domain name system)
@@ -37381,9 +37381,9 @@ Version Control Services
  (listen '("443 ssl"))
  (server-name "git.my-host.org")
  (ssl-certificate
-  "/etc/letsencrypt/live/git.my-host.org/fullchain.pem")
+  "/etc/certs/git.my-host.org/fullchain.pem")
  (ssl-certificate-key
-  "/etc/letsencrypt/live/git.my-host.org/privkey.pem")
+  "/etc/certs/git.my-host.org/privkey.pem")
  (locations
   (list
(git-http-nginx-location-configuration
@@ -38508,9 +38508,9 @@ Version Control Services
(nginx-server-block
  (nginx-server-configuration
(ssl-certificate
- "/etc/letsencrypt/live/myweb.site/fullchain.pem")
+ "/etc/certs/myweb.site/fullchain.pem")
(ssl-certificate-key
- "/etc/letsencrypt/live/myweb.site/privkey.pem")
+ "/etc/certs/myweb.site/privkey.pem")
(listen '("443 ssl http2" "[::]:443 ssl http2"))
(locations
  (list
diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 0c45471659..3926d0551a 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -6,6 +6,7 @@
 ;;; C

[PATCH v2 4/4] services: certbot: Add one-shot service to renew certificates.

[Carlo Zancanaro]

* gnu/services/certbot.scm (certbot-renewal-one-shot): New procedure.
(certbot-service-type)[extensions]: Add it to shepherd-root extension.
(certbot-command): Make connection errors return a different exit code.
(certbot-activation): Remove message with certificate renewal instructions.

Change-Id: I614ac6214a753dba0396e2385a75926c8355caa1
---
 gnu/services/certbot.scm | 77 +---
 1 file changed, 65 insertions(+), 12 deletions(-)

diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 490b9e8d6d..d6354c86d3 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -183,15 +183,37 @@ (define certbot-command
(program-file
 "certbot-command"
 #~(begin
-(use-modules (ice-9 match))
-(let ((code 0))
+(use-modules (ice-9 match)
+ (ice-9 textual-ports))
+
+(define (file-contains? file string)
+  (string-contains (call-with-input-file file
+ get-string-all)
+   string))
+
+(define (connection-error?)
+  (file-contains? "/var/log/letsencrypt/letsencrypt.log"
+  "Failed to establish a new connection"))
+
+(let ((script-code 0))
   (for-each
(match-lambda
  ((name . command)
   (begin
 (format #t "Acquiring or renewing certificate: ~a~%" name)
-(set! code (or (apply system* command) code)
-   '#$commands) code)))
+(unless (zero? (status:exit-val (apply system* command)))
+  ;; Certbot errors are always exit code 1, but we'd like
+  ;; to separate connection errors from other error types.
+  (if (connection-error?)
+  ;; If we have a connection error, then bail early
+  ;; with exit code 2. We don't expect this to
+  ;; resolve within the timespan of this script.
+  (exit 2)
+  ;; If we have any other type of error, then continue
+  ;; but exit with a failing status code in the end.
+  (set! script-code 1))
+   '#$commands)
+  (exit script-code
 
 (define (certbot-renewal-jobs config)
   (list
@@ -200,6 +222,40 @@ (define (certbot-renewal-jobs config)
#~(job '(next-minute-from (next-hour '(0 12)) (list (random 60)))
   #$(certbot-command config
 
+(define (certbot-renewal-one-shot config)
+  (list
+   ;; Renew certificates when the system first starts. This is a one-shot
+   ;; service, because the mcron configuration will take care of running this
+   ;; periodically. This is most useful the very first time the system starts,
+   ;; to overwrite our self-signed certificates as soon as possible without
+   ;; user intervention.
+   (shepherd-service
+(provision '(renew-certbot-certificates))
+(requirement '(nginx))
+(one-shot? #t)
+(start #~(lambda _
+   ;; This needs the network, but there's no reliable way to know
+   ;; if the network is up other than trying. If we fail due to a
+   ;; connection error we retry a number of times in the hope that
+   ;; the network comes up soon.
+   (let loop ((attempt 0))
+ (let ((code (status:exit-val
+  (system* #$(certbot-command config)
+   (cond
+((and (= code 2)  ; Exit code 2 means connection error
+  (< attempt 12)) ; 12 * 10 seconds = 2 minutes
+ (sleep 10)
+ (loop (1+ attempt)))
+((zero? code)
+ ;; Success!
+ #t)
+(else
+ ;; Failure.
+ #f))
+(auto-start? #t)
+(documentation "Call certbot to renew certificates.")
+(actions (list (shepherd-configuration-action (certbot-command 
config)))
+
 (define (generate-certificate-gexp certbot-cert-directory rsa-key-size)
   (match-lambda
 (($  name (primary-domain other-domains ...)
@@ -243,9 +299,7 @@ (define (generate-certificate-gexp certbot-cert-directory 
rsa-key-size)
 
 (define (certbot-activation config)
   (let* ((certbot-directory "/var/lib/certbot")
- (certbot-cert-directory "/etc/letsencrypt/live")
- (script (in-vicinity certbot-directory "renew-certificates"))
- (message (format #f (G_ "~a may need to be run~%") script)))
+ (certbot-cert-directory "/etc/letsencrypt/live"))
 (match config
   (($  package webroot certificates email
   server rsa-key-size default-location)
@@ -261,10 

[PATCH v2 2/4] services: certbot: Create self-signed certificates before certbot runs.

[Carlo Zancanaro]

* gnu/services/certbot.scm (): Add
start-self-signed? field.
(generate-certificate-gexp): New procedure.
(certbot-activation): Generate self-signed certificates when
start-self-signed? is #t.
* doc/guix.texi (Certificate services): Document start-self-signed?.

Change-Id: Icfd85ae0c3e29324acbcde6ba283546cf0e27a1d
---
 doc/guix.texi|  6 
 gnu/services/certbot.scm | 62 ++--
 2 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index b134d45a16..58a65fe0b7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -32690,6 +32690,12 @@ Certificate Services
 contain a space-delimited list of renewed certificate domains (for
 example, @samp{"example.com www.example.com"}.
 
+@item @code{start-self-signed?} (default: @code{#t})
+Whether to generate an initial self-signed certificate during system
+activation.  This option is particularly useful to allow @code{nginx} to
+start before @code{certbot} has run, because @code{certbot} relies on
+@code{nginx} running to perform HTTP challenges.
+
 @end table
 @end deftp
 
diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 3926d0551a..10b99f5630 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -35,6 +35,7 @@ (define-module (gnu services certbot)
   #:use-module (guix records)
   #:use-module (guix gexp)
   #:use-module (srfi srfi-1)
+  #:use-module (ice-9 format)
   #:use-module (ice-9 match)
   #:export (certbot-service-type
 certbot-configuration
@@ -64,7 +65,9 @@ (define-record-type* 
   (cleanup-hookcertificate-cleanup-hook
(default #f))
   (deploy-hook certificate-configuration-deploy-hook
-   (default #f)))
+   (default #f))
+  (start-self-signed?  certificate-configuration-start-self-signed?
+   (default #t)))
 
 (define-record-type* 
   certbot-configuration make-certbot-configuration
@@ -91,7 +94,10 @@ (define-record-type* 
 (define (certbot-deploy-hook name deploy-hook-script)
   "Returns a gexp which creates symlinks for privkey.pem and fullchain.pem
 from /etc/certs/NAME to /etc/letsenctypt/live/NAME.  If DEPLOY-HOOK-SCRIPT is
-not #f then it is run after the symlinks have been created."
+not #f then it is run after the symlinks have been created.  This wrapping is
+necessary for certificates with start-self-signed? set to #t, as it will
+overwrite the initial self-signed certificates upon the first successful
+deploy."
   (program-file
(string-append name "-deploy-hook")
(with-imported-modules '((guix build utils))
@@ -108,7 +114,8 @@ (define (certbot-deploy-hook name deploy-hook-script)
  "/etc/letsencrypt/live/" name "/fullchain.pem")
   #$(string-append "/etc/certs/" name "/fullchain.pem.new"))
 
- ;; Rename over the top of the old ones, if there are any.
+ ;; Rename over the top of the old ones, just in case they were the
+ ;; original self-signed certificates.
  (rename-file #$(string-append "/etc/certs/" name "/privkey.pem.new")
   #$(string-append "/etc/certs/" name "/privkey.pem"))
  (rename-file #$(string-append "/etc/certs/" name "/fullchain.pem.new")
@@ -184,6 +191,47 @@ (define (certbot-renewal-jobs config)
#~(job '(next-minute-from (next-hour '(0 12)) (list (random 60)))
   #$(certbot-command config
 
+(define (generate-certificate-gexp certbot-cert-directory rsa-key-size)
+  (match-lambda
+(($  name (primary-domain other-domains ...)
+challenge
+csr authentication-hook
+cleanup-hook deploy-hook)
+ (let (;; Arbitrary default subject, with just the
+   ;; right domain filled in. These values don't
+   ;; have any real significance.
+   (subject (string-append
+ "/C=US/ST=Oregon/L=Portland/O=Company Name/OU=Org/CN="
+ primary-domain))
+   (alt-names (if (null? other-domains)
+  #f
+  (format #f "subjectAltName=~{DNS:~a~^,~}"
+  other-domains)))
+   (directory (string-append "/etc/certs/" (or name primary-domain
+   #~(when (not (file-exists? #$directory))
+   ;; We generate self-signed certificates in /etc/certs/{domain},
+   ;; because certbot is very sensitive to its directory
+   ;; structure. It refuses to write over the top of existing files,
+   ;; so we need to use a directory outside of its control.
+   ;;
+   ;; These certificates are overwritten by the certbot deploy hook
+   ;; the first time it successfully obtains a letsencrypt-signed
+   ;; certificate.
+   (mkdir-p #$directory)
+   (chmod #$directory #o755)
+   (in

[PATCH v2 0/4] Make certbot play more nicely with nginx

[Carlo Zancanaro]

Hi Guix,

This patch series is a few changes to make certbot default to doing
"the right thing" in the common case of wanting certificates for an
nginx web server.

The initial change (in v1 of these patches) was to solve the certbot
bootstrapping problem. Nginx won't start without valid certificates,
but certbot can't produce certificates without a functional
nginx. This is solved by generating self-signed certificates to start
with, and then replacing them once certbot has run. Doing this
requires storing certificates in a different location (because certbot
is very particular). I've chosen /etc/certs/.

The other two changes (new to v2 of this series) make things a bit
easier to use: a one-shot shepherd service to renew certificates when
the machine starts up, and a default deploy-hook to reload the nginx
configuration (which picks up the new certificates). I think these
changes make certbot "do the right thing", at the expense of being
slightly more magical.

On IRC podiki suggested I should copy guix-devel and Brice (the
original bug reporter), so I've done that, too.

Carlo Zancanaro (4):
  services: certbot: Symlink certificates to /etc/certs.
  services: certbot: Create self-signed certificates before certbot
runs.
  services: certbot: Add a default deploy hook to reload nginx.
  services: certbot: Add one-shot service to renew certificates.

 doc/guix.texi|  38 ++---
 gnu/services/certbot.scm | 178 ---
 2 files changed, 188 insertions(+), 28 deletions(-)


base-commit: 144c95032e517bb8ce466b930fe91506bcc92b2b
-- 
2.41.0

[PATCH v2 3/4] services: certbot: Add a default deploy hook to reload nginx.

[Carlo Zancanaro]

* gnu/services/certbot.scm (%default-deploy-hook): New variable.
()[deploy-hook]: Use it as default deploy hook.
* doc/guix.texi (Certificate services): Document new default deploy hook.

Change-Id: Ibb10481170a6fda7df72492072b939dd6a6ad176
---
 doc/guix.texi|  6 +-
 gnu/services/certbot.scm | 13 +++--
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 58a65fe0b7..0f372a460f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -32681,7 +32681,7 @@ Certificate Services
 additionally @code{$CERTBOT_AUTH_OUTPUT} will contain the standard output
 of the @code{auth-hook} script.
 
-@item @code{deploy-hook} (default: @code{#f})
+@item @code{deploy-hook} (default: @code{%default-deploy-hook})
 Command to be run in a shell once for each successfully issued
 certificate.  For this command, the shell variable
 @code{$RENEWED_LINEAGE} will point to the config live subdirectory (for
@@ -32690,6 +32690,10 @@ Certificate Services
 contain a space-delimited list of renewed certificate domains (for
 example, @samp{"example.com www.example.com"}.
 
+The default deploy hook calls the @code{reload} action of the
+@code{nginx} Shepherd service, to reload the newly generated
+certificates.
+
 @item @code{start-self-signed?} (default: @code{#t})
 Whether to generate an initial self-signed certificate during system
 activation.  This option is particularly useful to allow @code{nginx} to
diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 10b99f5630..490b9e8d6d 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -37,7 +37,8 @@ (define-module (gnu services certbot)
   #:use-module (srfi srfi-1)
   #:use-module (ice-9 format)
   #:use-module (ice-9 match)
-  #:export (certbot-service-type
+  #:export (%default-deploy-hook
+certbot-service-type
 certbot-configuration
 certbot-configuration?
 certificate-configuration))
@@ -49,6 +50,14 @@ (define-module (gnu services certbot)
 ;;; Code:
 
 
+(define %default-deploy-hook
+  (program-file
+   "reload-nginx.scm"
+   (with-imported-modules '((gnu services herd))
+ #~(begin
+ (use-modules (gnu services herd))
+ (with-shepherd-action 'nginx ('reload) result result)
+
 (define-record-type* 
   certificate-configuration make-certificate-configuration
   certificate-configuration?
@@ -65,7 +74,7 @@ (define-record-type* 
   (cleanup-hookcertificate-cleanup-hook
(default #f))
   (deploy-hook certificate-configuration-deploy-hook
-   (default #f))
+   (default %default-deploy-hook))
   (start-self-signed?  certificate-configuration-start-self-signed?
(default #t)))
 
-- 
2.41.0

Re: Guix CLI, thoughts and suggestions

[Carlo Zancanaro]

Hi Ian,

On Sat, Jan 20 2024, Ian Eure wrote:
> I agree that this would make sense, but my understanding is that `guix
> package' doesn’t work like that -- it only performs the final
> operation in the list.  IMO, it should either do *everything* the
> commands specify, or print an error and take no action.

It can accumulate multiple commands. As an example, if you create a
profile with a single package in it:

  $ guix package -i hello
  The following package will be installed:
 hello 2.12.1
  ... more output...

then you can remove that package and install another package in a single
transaction:

  $ guix package -r hello -i coreutils
  The following package will be removed:
 hello 2.12.1

  The following package will be installed:
 coreutils 9.1
  ... more output...

The inconsistency here is that some commands can be combined
(specifically adding and removing), whereas others cannot (probably
everything else).

> I agree, I don’t think the situation can be improved without finding a
> solution to preserve BC.  But, I didn’t think it was worth making
> detailed plans for any of this before gauging whether the problem was
> one broadly considered to be worth solving.

I think it would be great to have a consistent CLI, so I would love it
if we were able to solve this problem.

Carlo

Re: Guix deploy --keep-going equivalent for machine connection failures

[Carlo Zancanaro]

On Mon, Jan 15 2024, Richard Sent wrote:
> At present this can be worked around by commenting out entries on the
> list, but this requires
> a) Already knowing what machine is offline
> b) Remembering to uncomment it later when the machine goes back online
> c) Generally feels "ugly" in a way that most Guix commands don't.
> d) Makes version control a pain

This is generally what I've done, but I see this as a manual form of
something that could easily be added the machines.scm file itself.

For instance, you could define a helper function and use it to filter
the list of machines, like so:

  (define (reachable-host? machine)
(let ((configuration (machine-configuration machine)))
  (cond
   ((machine-ssh-configuration? configuration)
(zero? (system* "ssh" (machine-ssh-configuration-host-name 
configuration)
"--" "true")))
   (else
#f

  (filter
   reachable-host?
   (list
(machine ...)
(machine ...)))

Using this sort of approach can implement whatever strategy you want, as
long as you can determine the machines which you want to deploy to
up-front (i.e. this can't implement a strategy that handles failure
partway through deployment).

Carlo

Re: Guix CLI, thoughts and suggestions

[Carlo Zancanaro]

Hi Ian,

Much of what you've written is fair, and I'm sure that Guix's commands
could be better organised. I'm not really involved in Guix development,
but I think there are two "inconsistencies" that you've mentioned which
can be explained.

On Mon, Jan 15 2024, Ian Eure wrote:
> Some examples of where I think Guix could do better.  This is an
> illustrative list, not an exhaustive one.
>
> Inconsistent organization
> =
>
> Most package-related commands are under `guix package', but many are
> sibling commands.  Examples are `guix size', `guix lint', `guix hash',
> etc.

I think the real inconsistency here is that `guix package' is poorly
named. This command really operates on profiles, and performs operations
(install, remove, list, etc.) on those profiles. Packages are given as
arguments to this command.

The other commands operate on, and show the properties of, packages.
Similarly with `guix build'.

> Inconsistency between verbs and options
> ===

> ... For example, installing a package is `guix package -i foo' rather
> than `guix package install foo', removing is `guix package -r foo'
> rather than `guix package remove foo', and listing installed packages
> is `guix package -I' rather than `guix package installed' (or
> similar).

The specific example of `guix package' might be explained by considering
it as a single transaction to update the profile. The command `guix
package' really says "perform a transaction on the profile", and the
options are the commands in the transaction. Since there can be multiple
commands, and the command names look like package names, they are
provided as options.

This doesn't fully explain the behaviour. In particular the example you
give:

> This means that users can express commands which *seem* like they
> should work, but do not.  For example `guix package -i emacs -r
> emacs-pgtk -I' represents a command to 1) install emacs 2) remove
> emacs-pgtk 3) list installed packages (which would verify the previous
> two operations occurred). ...

seems reasonable to have working within the view of `guix package' as a
transactional operation.

It's also worth noting that there are convenience shortcuts in `guix
install' and `guix remove'.

> It seems like a lot of work to change, and backwards compatibility
> also is an issue.

I see backwards compatibility as the main issue here. There was a lot of
discussion preceding the inclusion of `guix shell', because of the
prospect of breaking existing tutorials/documentation floating around on
the internet. This is an even bigger concern for a more drastic
reorganisation of the CLI.

Carlo

Re: Unable to define shebang for guix shell file

[Carlo Zancanaro]

Hey Jacob,

On Tue, Nov 09 2021, Jacob Hrbek wrote:
For now I use “#!/usr/bin/env -S guix shell --”, which works 
well enough for me.  How does that sound? -- l...@gnu.org


Not a solution as (AFIAK) POSIX only accepts one argument.


That's the point of the -S. It passes the entire rest of the line 
as a single argument to /usr/bin/env, which reads it as a single 
-S argument which /usr/bin/env then interprets as a command with 
arguments.


Something like how this doesn't work:

 $ /usr/bin/env 'echo hello'
 /usr/bin/env: ‘echo hello’: No such file or directory
 /usr/bin/env: use -[v]S to pass options in shebang lines

But this does:

 $ /usr/bin/env '-S echo hello'
 hello

It looks like this was added to coreutils in 2018 in version 8.30. 
I wasn't aware of this feature until seeing Ludo's email, but it 
seems like a neat solution to the problem.


Carlo

Re: Accuracy of importers?

[Carlo Zancanaro]

Hi Nicolas/Ludo,

On Fri, Oct 29 2021, Nicolas Goaziou wrote:
Among those, which importers provide source that differs from 
what you’d get from upstream’s checkout or release tarballs? 
My guess:


   elpa (gives hosted tarballs that can differ from upstream 
   repo)


Indeed.


For MELPA specifically there is code to grab the upstream Git 
repository details, but it doesn't seem to work when the module is 
compiled. See https://issues.guix.gnu.org/49006 for some details.


Carlo

Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Carlo Zancanaro]

On Wed, Sep 01 2021, Liliana Marie Prikler wrote:
TL;DR: I'm generally in favor of branching emacs support 
packages off, even if origins are to be inherited.


This is my preference, and there is precedent for this in Guix 
already. I know of emacs-protobuf-mode and emacs-erlang which are 
separate packages, but which reference the source of an existing 
package (with (package-source protobuf) and (package-source 
erlang), respectively).


I like how easy it is to discover Emacs packages by looking for 
the emacs- prefix. Mu and notmuch already violate that prefix 
expectation, moving their elisp into a separate output would be 
further hiding the Emacs modes.


Carlo

Re: A new wip-emacs branch

[Carlo Zancanaro]

Hi Leo!

On Thu, Apr 08 2021, Leo Prikler wrote:
guix-emacs should still be loaded by site-start.el, which also 
initially loads your autoloads.


Now that I've had more of a chance to play with it, you're right 
about this. I'm not sure what I did earlier, but it loaded 
properly just now.


What changes for "Guix in Emacs modifying Emacs", is that you'll 
probably have to reload the subdirs.el file before autoloading 
the packages.


Ah, okay. I just played around with this, and it seems like the 
sequence I now need is:


 $ guix install emacs-magit # shell command
 ...
 $ load subdirs # emacs command
 t
 $ guix-emacs-autoload-packages # emacs command
 (... list of autoload files ...)

It also sees like I'm able to require the packages in Emacs after 
the "load subdirs" step, as well, so in practice it's still only 
two commands to make new Emacs packages loadable, it's just that 
the second command has changed. 👍


Obviously, there are exceptions to this, that we can argue on a 
case by case basis, but to summarize, I don't think hardcoding 
paths throughout Emacs is a good idea.


I think there are two different cases which are more clear-cut, 
with a significant middle ground that's fuzzy, and using PATH just 
ignores this distinction entirely. There are program uses that are 
an implementation detail (e.g. the fact that dired uses ls), and 
there are programs that a user is directly interacting with (e.g. 
anything that I run in a shell). My thinking is that ideally the 
former should use hard-coded paths, and the latter should come 
from PATH.


The tricky ones are things like geiser, or magit, where the Emacs 
package is a wrapper around a program's functionality. These feel 
like it's reasonable to go either way, but they are also the types 
of packages that provide ways to easily change which program they 
run (i.e. geiser-guile-binary and magit-git-executable for these 
specific examples), so they could default to a hard-coded store 
path because a user can easily change them if they want to use a 
different version.


Although, as you mentioned in a previous email, TRAMP may make 
even those "clear-cut" cases a bit trickier. I'll admit I haven't 
considered TRAMP much in my thinking.


As a more general comment, I feel like Guix's wrappers are often 
treated as "cheaper" than they are. It makes me sad that using 
awesome as a window manager means that I have to have 
LD_LIBRARY_PATH= GI_TYPELIB_PATH= before calls to external 
programs to stop things from crashing (and working out that I 
needed that was a pain in itself). I'll admit that this case with 
Emacs and PATH seems less dangerous than the awesome wrapper, but 
I'm wary of the unexpected problems that it might cause.


Carlo

Re: A new wip-emacs branch

[Carlo Zancanaro]

Hi Leo!

Thanks so much for working to improve Emacs packaging in Guix! I 
have a question and a comment about your approach on the wip-emacs 
branch.


On Tue, Apr 06 2021, Leo Prikler wrote:
Emacs now gets its core lisp path from the wrapper rather than 
the search path and there's a new profile hook adding all 
top-level subdirectories to a subdirs.el, that gets loaded at 
startup.


This sounds great in terms of Emacs starting in an already 
established profile, but one key use case for me is to be able to 
install new packages without restarting Emacs. Usually I can do 
this in eshell by running


 $ guix install emacs-magit # shell command
 ...
 $ guix-emacs-autoload-packages # emacs command
 ...

I just tried this in a fresh profile with a Guix built from 
wip-emacs, but it didn't seem to work. It's possible that I've 
done something wrong (I'm doing it with time-machine, which adds 
its own complexities), but are you expecting this to work? It 
looks like guix-emacs wasn't loaded, and it wasn't on the load 
path, but I haven't had a chance to investigate further than that.


Extending PATH in the same wrapper as EMACSLOADPATH seems to be 
a fairly cheap option, however.


I'm not supportive of this, because extending PATH would also 
change the binaries that are available through Emacs' shells, 
which I use a lot. This would mean that either (a) the Emacs 
packages can shadow what I've explicitly installed in my profile, 
potentially leading to me running unexpected versions of programs, 
or (b) installing something else in my profile might break 
something in Emacs because the version has changed. This isn't 
likely to be a major problem for coreutils and gzip, assuming 
they're stable enough, but it is a problem in general. In my view 
either patching the Emacs libraries (to avoid the conflict) or 
propagating inputs (to expose the potential conflict while 
building the profile) are better options.


Thanks again!

Carlo

Re: Help with packaging: Dendrite (Matrix), Gitea, Caddy

[Carlo Zancanaro]

Hi Timothy,

On Thu, Jan 14 2021, Timothy wrote:
For the past ~month I've been trying to package Dendrite (a 
second generation reference Matrix server implementation, set to 
succeed Synapse when feature parity is reached), Gitea, and 
Caddy.


I took a look at dendrite, and it looks like it needs some 
dependencies. In the build output I saw a bunch of:


src/github.com/matrix-org/dendrite/internal/consumers.go:21:2: 
cannot find package "github.com/Shopify/sarama" in any of:
	/gnu/store/cb9kqjg7m6xk1wz7ap8as792fd5kcmd2-go-1.14.10/src/github.com/Shopify/sarama 
	(from $GOROOT)
	/tmp/guix-build-dendrite-0.3.1.drv-0/src/github.com/Shopify/sarama 
	(from $GOPATH)
src/github.com/matrix-org/dendrite/appservice/appservice.go:23:2: 
cannot find package "github.com/gorilla/mux" in any of:
	/gnu/store/cb9kqjg7m6xk1wz7ap8as792fd5kcmd2-go-1.14.10/src/github.com/gorilla/mux 
	(from $GOROOT)
	/tmp/guix-build-dendrite-0.3.1.drv-0/src/github.com/gorilla/mux 
	(from $GOPATH)

...

From what I can see of the other Go packages in Guix, each of the 
dependencies needs to be added to the propagated-inputs of the 
dendrite package to make it build.


I don't think we have all of these dependencies packaged in Guix 
at the moment, so you will have to write some package definitions 
for these dependencies before you can package dendrite. I'm not 
up-to-date on the state of Go in Guix, but I think there are some 
patches for a Go importer floating around on the mailing list, if 
you wanted to try automatically importing package definitions.


I hope that helps,

Carlo

Re: ZFS on Guix

[Carlo Zancanaro]

Apologies for the short reply, but that permission issue can be solved in the 
short term by changing the permissions on /dev/kvm (I set it to 777 to force it 
when necessary, because I don't know what the right permissions are).

The proper solution is probably to add your user to a kvm group on your 
distribution, which should give you the appropriate access.

Re: ZFS on Guix

[Carlo Zancanaro]

Hi raid5atemyhomework,

On Wed, Jan 06 2021, raid5atemyhomework wrote:
I have this patch below for creating a new 
`kernel-loadable-module-service-type`, which can be extended by 
another service to add kernel-loadable modules provided by 
packages, hope for a review.


I tried out building a VM using this patch and it seemed to work 
properly. I was able to add a kernel module by extending 
kernel-loadable-module-service-type, and then load it in the 
running VM with modprobe.


I only have superficial comments about the patch itself. Hopefully 
someone else will provide a better review than I can.


From 984602faba1e18b9eb64e62970147aab653d997f Mon Sep 17 
00:00:00 2001

From: raid5atemyhomework 
Date: Tue, 5 Jan 2021 22:27:56 +0800
Subject: [PATCH] gnu: Add 'kernel-loadable-module-service-type' 
for services

 to extend with kernel-loadable modules.


This will need a proper commit message before being committed. 
Guix generally follows the GNU Change Log style[1]. You can see 
examples of what commit messages look like by looking at other 
commits in the repository.



+;; Only used by the KERNEL-LOADABLE-MODULE-SERVICE-TYPE.


I would remove this comment. This is a description of the current 
state, rather than a restriction on how it should be used. As a 
description, it might get out of date (if we use 
 values elsewhere), and it doesn't 
add much value (because it can be easily verified, and the record 
type isn't exported). If you indent this to be normative, the 
comment should explain why this type should not be used elsewhere.



+  (return `(("kernel" ,kernel)
+,@(if hurd `(("hurd" ,hurd)) '()))
+(define (kernel-builder-configuration-add-modules config 
modules)
+  "Constructs a kernel builder configuration that has its 
modules extended."


Put empty lines between definitions here ...

+ "Register packages containing kernel-loadable 
modules and adds them

+to the system.")))
+(define (kernel-loadable-module-service kernel hurd modules)
+  "Constructs the service that sets up kernel loadable 
modules."


... and here.

It would also be worth adding a test to 
gnu/tests/linux-modules.scm to test loading modules through this 
service.


Other than that, it looks good to me and it seems to work in my 
limited testing. 👍 Good job!


Carlo

[1]: https://www.gnu.org/prep/standards/html_node/Change-Logs.html

Re: A new paradigm for modifying operating system declarations

[Carlo Zancanaro]

Hi raid5atemyhomework,

On Tue, Jan 05 2021, raid5atemyhomework wrote:
What `install-zfs` does is that it installs the same 
kernel-specific package in three different points:


* `kernel-loadable-modules`, because ZFS needs to get into the 
kernel somehow.
* `packages`, because the kernel module is useless if you don't 
have the userland tools to interact with the kernel module.
* `services`, because ZFS is well-documented outside of Guix as 
automatically mounting its filesystems at bootup, but that 
actually requires a bit of magic in the `init` system, 
specifically you need to actually **load** the module, then 
execute `zpool import -a -l` to have it scan for all filesystems 
and mount those that need automounting.


Thus, an `install-zfs`, that is a *single* form that inserts the 
correct bits in the correct ***three*** places, makes the 
experience of adding ZFS to your `operating-system` easier 
because there's less scope for error in actually adding the 
package.  You just add a single `install-zfs`, not add three 
things (plus an extra `(define my-zfs (make-zfs-package 
linux-libre-5.4))` before your form).


In principle, I think this should all be handled by a service. 
Services have a number of extension points where they can impact 
the operating system being declared, by extending other services. 
For example, adding a package into the global profile is done by 
extending profile-service-type (which you can find in 
gnu/services.scm). Adding a shepherd service to manage a process 
is done by extending shepherd-root-service-type (in 
gnu/services/shepherd.scm).


This is how many services work. As an example, sddm-service-type 
extends services to: (a) start a process on the running system, 
(b) put files in /etc, (c) install some pam services, (d) add an 
account on the system, and (e) install packages in the global 
profile.


As far as I can tell, the only thing missing for a 
zfs-service-type to do what you want is that services can't 
currently add new kernel modules (although they can load them via 
kernel-module-loader-service-type). I may have missed a mechanism 
for this, though. If we added the ability to do this, then it 
should be possible to add zfs support by adding a single (service 
zfs-service-type) to your services list.


The approach of using services in this way has some advantages 
which are outlined in a blog post from 2015[1]. For me the most 
compelling advantage is that an zfs-service-type is more 
restricted in what it can do, and must be more explicit. An 
install-zfs procedure has free-reign over the entire 
operating-system definition that it gets passed, which makes it 
harder to reason about the composition of such procedures.


Carlo

[1]: https://guix.gnu.org/blog/2015/service-composition-in-guixsd/

Re: Release: Docker Image? DockerHub? skopeo?

[Carlo Zancanaro]

Hey Danny,

On Wed, Nov 18 2020, Danny Milosavljevic wrote:
Hmm, maybe I'm misunderstanding what Docker compose does 
entirely.


Reading the docs it seems to just manage multiple isolated 
Docker images and deploy new ones?


Yep, that's all it does. It lets you link together ports and 
volumes, and expose ports to the host machine, but it doesn't do 
anything particularly magical. I think it only does things that 
you could have done by starting images with the right docker 
invocations.


What then is used to do the equivalent of a guix profile with 
multiple packages in a Docker image?


I don't think there is a way to compose multiple docker images 
into a single image.


Carlo

Re: Why does %build-inputs contain the transitive closure of inputs?!

[Carlo Zancanaro]

Hi Jakub,

On Sat, Aug 08 2020, Jakub Kądziołka wrote:
Why? I would expect only libgit2 to be present, and not all of 
its dependencies. ...


If you take a look at the definition for libgit2 in 
gnu/packages/version-control.scm you'll see that this isn't all 
the dependencies for libgit2, it's only the propagated-inputs. For 
instance, libssh2 and http-parser are both inputs for libgit2, but 
they don't appear in your list because they're not propagated.


... It seems to me that this has only downsides - the entire 
transitive closure needs to be present during build, even when 
the actually used dependencies don't reference it, and the names 
of inputs used by packages are now public API, and changing them 
can break the build of any transitively dependent package.


The way propagated inputs work is that they're installed alongside 
the package, so in some sense they are part of the public API of 
the package. They should be used with care, but as far as I can 
tell everything is working properly here.


Carlo

Re: Vanilla Firefox recipe?

[Carlo Zancanaro]

Hey Chris,

On Wed, May 27 2020, Christopher Lemmer Webber wrote:
> However, I wonder if, with a matter of just two patches, this could be
> resolved:
>
>  - Patch out the automatic download of Cisco's h.264 plugin.
>  - Add a warning banner *above* the extensions page, or simply switch it
>to the same one that Icecat already uses.
>
> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
> It strikes me that with those two changes, the criteria would be met.

We would need to watch out for Mozilla's requirements to use the "Firefox" 
trademark[1]. Of particular note is the section titled "Modified Versions 
Require Prior Written Permission":

  The open source nature of Firefox and other Mozilla software allows you to 
freely download and modify the source code. However, if you make any changes to 
Firefox or other Mozilla software, you may not redistribute that product using 
any Mozilla trademark without Mozilla’s prior written consent and, typically, a 
distribution agreement with Mozilla. For example, you may not distribute a 
modified form of Firefox and continue to call it Firefox.

  Changes requiring Mozilla’s prior written permission include (but are not 
limited to):
   - Changing the default home page or adding bookmarks,
   - Adding, modifying, or deleting source files,
   - Adding, modifying, or deleting content from installer files,
   - File location changes,
   - Adding extensions, add-ons or plugins, or
   - Installing themes other than those available in the most recent stable 
version of Firefox available at Mozilla.org.

  If you wish to distribute a modified version of Firefox or other Mozilla 
software with Mozilla trademarks please contact us with your request at 
trademark-permissi...@mozilla.com.

Carlo

[1]: https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/

Re: “Guix Profiles in Practice”

[Carlo Zancanaro]

Hey Pierre,

On Mon, Nov 04 2019, Pierre Neidhardt wrote:

As I understand it, the current discussion is about "pinning"
profiles.
Should any dependency get garbage collected, an environment will 
need
Internet access to refetch the missing parts; I think this is 
what we
are trying to avoid, regardless of how fast `guix environment` 
is.


What about `guix environment --pin` instead of `guix develop`?


Have you used `guix environment --root`?

In my git checkout of the Guix repository I once ran `guix 
environment guix --root=.environment`, and now whenever I want to 
hack on Guix I start a shell and `source 
.environment/etc/profile`. The .environment symlink is treated as 
a GC root by Guix, and because I'm not actually invoking Guix 
there's never a risk that it will attempt to fetch anything from 
the internet.


Upgrading the environment is quite easy, and must be done 
manually: I delete the existing symlink and run `guix environment 
guix --root=.environment` again. If I'm feeling paranoid I'll run 
`guix environment guix` once first to make sure it succeeds, 
before deleting the old symlink and adding the 
`--root=.environment` to the end.


Carlo

Re: awesome window manager configuration

[Carlo Zancanaro]

Hi Joshua!

On Fri, Jan 04 2019, Joshua Branson wrote:
I recently started using the awesome window manager, and I'm 
curious if I can help edit the manual a bit.  The current manual 
does not mention that to configure the awesome window manager, 
one must copy the configuration from 
/gnu/store/xmmqxby6bm...-awesome-4.2/etc/xdg/awesome/rc.lua to 
"~/.config/awesome/".


My question is for now, can I add that information to the 
manual?


It would be great if you could add that to the manual! The usual 
advice for awesome is to copy it from /etc/xdg/awesome/rc.lua, so 
it's worth documenting that it's different on Guix. It might be 
worth saying to copy it from the relevant profile, rather than the 
specific store directory. The profile would usually be either 
~/.guix-profile/etc/xdg/awesome/rc.lua (if it's installed as a 
user package), or 
/run/current-system/profile/etc/xdg/awesome/rc.lua (if it's 
installed as a system package).


My second question is what is the long term plan for integrating 
window managers with guixSD?  Should be turn all window manager 
packages into services? ...


I don't think we need to do this. As long as they work (and are 
picked up by DMs) when installed as a package, I think that's 
sufficient. I actually don't even have Awesome installed as a 
system package - I install it as a user package and configure my 
DE (xfce, which is installed as a system package) to start Awesome 
from my user profile.


Carlo

Re: System configuration on non-native Guix (SuSE/Debian)

[Carlo Zancanaro]

On Sun, Aug 19 2018, Pjotr Prins wrote:
One thing I have always wanted to do is use Guix' system 
configuration capabilities on top of Debian. But, so far, I have 
no idea how to go about that.


I would also be interested in this. I have thought about it a 
little bit, but I haven't made any concrete steps towards making 
it happen.


Can someone help? We can make a blog out of it. Say I want to 
configure Nginx as a system tool using Guix. What would be the 
steps to take? A simple example would help a lot!


For something like nginx it might be possible to reuse the code in 
(gnu services web) which generates a config file for nginx. This 
would be a very simplistic way of doing things, though, and 
wouldn't really solve the problem generally.


It would be cool if we could instantiate a given service graph on 
the currently running system, although working out how to do this 
without interfering with the host distribution sounds tricky. 
GuixSD assumes that it's in control of the entire system, so the 
easiest way to do this might well be start up an isolated GuixSD 
system in a container/vm. If we wanted to run on the host 
distribution we'd at least have to come up with a different set of 
base services, because %base-services would almost certainly 
conflict with the host distribution.


And a separate question: can the shepherd run next to systemd? I 
would think so. I have no real love for systemd, but it is 
rather hard to avoid on recent distros.


You could start an instance of the Shepherd as a systemd service. 
I use the Shepherd to manage my user sessions, but I use systemd 
to start it when it's available. If you start it under systemd 
then you can't shutdown/restart using the Shepherd, but everything 
else should work properly.


Carlo


signature.asc
Description: PGP signature

Re: Improving Shepherd

[Carlo Zancanaro]

Hey Ludo,

On Fri, Feb 09 2018, Ludovic Courtès wrote:
In particular, with higher levels of concurrency I want to move 
the

mutable state out of  objects.


The only piece of mutable state is the ‘running’ value.  We can 
make

that an “atomic box”, and users won’t even notice.


That's not quite true, unfortunately. I count four pieces of 
mutable state in the  object: `running`, `enabled?`, 
`waiting-for-termination?` and `last-respawns`. They should be 
stored elsewhere so that Shepherd can manage that state however it 
wants. We don't want to expose that to a user, where they could 
break Shepherd's assumptions about when/how it's modified (because 
user configuration can do anything it wants - including starting a 
long-running thread to mutate it later).


We shouldn't have to break much. My thought is just to remove 
those mutable fields from the  object (maybe leaving 
`enabled?`, but changing its meaning slightly to just be whether 
the service is enabled at the start). In practice it shouldn't 
break any real-world configuration, I hope.


Carlo


signature.asc
Description: PGP signature

Re: Improving Shepherd

[Carlo Zancanaro]

Hey Danny,

On Mon, Feb 05 2018, Danny Milosavljevic wrote:

I assume that means "starts a user's shepherd when they log in".


Either that, or run the services itself. In either case, what you 
have sent is very helpful!


User namespaces just present a different set of names to your 
process

(via VFS) so it looks like a chroot basically.
It does nothing for processes except fake their ids and limit 
your

overview of them.

You probably want process groups (see setsid(2)) or maybe 
containers.


Okay. I've been trying to read about containers/cgroups/namespaces 
and I think my mind has just blurred them all into the same thing. 
I'll read up about process groups. Thanks!


Carlo


signature.asc
Description: PGP signature

Re: Improving Shepherd

[Carlo Zancanaro]

Hey Ludo,

On Mon, Feb 05 2018, Ludovic Courtès wrote:
User services - Alex has already sent a patch to the list to 
allow
generating user services from the Guix side. The idea is to 
generate a
Shepherd config file, allowing a user to invoke shepherd 
manually to
start their services. A further extension to this would be to 
have
something like systemd's "user sessions", where the pid 1 
Shepherd

automatically starts a user's services when they log in.


After replying to Alex’ message, I realized that we could just 
as well
have a separate “guix service” or similar tool to take care of 
this?


This needs more thought (and perhaps taking a look at systemd 
user
sessions, which I’m not familiar with), but I think Alex’ 
approach is a

good starting point.


We were thinking it might work like this:
- services->package constructs a package which places a file in 
the profile containing the necessary references
- pid 1 shepherd listens to elogind login/logout events, and 
starts the services when necessary


Admittedly this isn't the nicest way for it to work, but it might 
be a good starting point.


There were some discussions on the list a while ago about how to 
have `guix environment` automatically start services, too, so I 
wonder what overlap there could be there. Although maybe 
environment services (in containers) have more in common with 
system services than user services.



Child process control - this is my personal frustration, where
Shepherd loses track of processes that fork away (e.g. "emacs
--daemon"). I barely know anything about Linux process 
management, but
from my reading this can be solved through Linux namespaces (if 
user
namespaces are available). Could someone who knows more about 
this let
me know if that's a productive direction for me to investigate? 
Or

tell me a better way to go about it?


Currently shepherd monitors SIGCHLD, and it’s not supposed to 
miss
those; in some cases it might handle them later than you’d 
expect, which
means that in the meantime you see a zombie process, but 
otherwise it

seems to work.

ISTR you reported an issue when using ‘shepherd --daemonize’, 
right?

Perhaps the issue is limited to that mode?


I no longer use the daemonize function. My user shepherd runs "in 
the foreground" (it's started when my X session starts), so it's 
not that. Jelle fixed the problem I was having by delaying the 
SIGCHLD handler registration until it's needed. It is still buggy 
if a process is started before the daemonize command is given to 
root service, though.


If you try running "emacs --daemon" with 
"make-forkexec-constructor" (and #:pid-file, and put something in 
your emacs config to make it write out the pid) you should be able 
to reproduce what I am seeing. If you kill emacs (or if it 
crashes) then shepherd continues to report that it is started and 
running. When I look at htop's output I can also see that my emacs 
process is not a child of my shepherd process.


I would like to add a --daemon/--daemonize command line argument 
to shepherd instead of the current "send the root service a 
daemonize message". I think the use cases of turning it into a 
daemon later are limited, and it just gives you an additional way 
of shooting yourself in the foot.


Concurrency/parallelism - I think Jelle was planning to work on 
this,
but I might be wrong about that. Maybe I volunteered? We're 
keen to
see Shepherd starting services in parallel, where possible. 
This will
require some changes to the way we start/stop services (because 
at the
moment we just send a "start" signal to a single service to 
start it,
which makes it hard to be parallel), and will require us to 
actually
build some sort of real dependency resolution. Longer-term our 
goal
should be to bring fibers into Shepherd, but Efraim mentioned 
that
fibers doesn't compile on ARM at the moment, so we'll have to 
get that

working first at least.


I’d really like to see that happen.  I’ve become more familiar 
with
Fibers, and I think it’ll be perfect for the Shepherd (and we’ll 
fix the

ARM build issue, no doubt.)


I'm not going to put much time/effort into this until we have 
fibers building on ARM. I think these changes are likely to break 
shepherd's config API, too. In particular, with higher levels of 
concurrency I want to move the mutable state out of  
objects.


It seems that signalfd(2) is Linux-only though, which is a 
bummer.  The
solution might be to get over it and have it implemented on 
GNU/Hurd…

(I saw this discussion:
; 
I

suspect it’s within reach.)


Failing that, could we have our signal handlers just convert the 
signal to a message in our event loop? I have a very rudimentary 
understanding of signal handling, but I assume we could have our 
main event loop just reading things off of two channels: one of 
signal events, one of fd events.


This would mean that Shepherd could decide the best way to 
s

Re: Improving Shepherd

[Carlo Zancanaro]

A few people came to join me on Friday to think about Shepherd. 
Thanks Alex, Efraim, and Jelle.


We talked about a few different things that we'd like to achieve 
with Shepherd. The most significant and achievable things were, I 
think: user services, child process control, and 
concurrency/parallelism.


User services - Alex has already sent a patch to the list to allow 
generating user services from the Guix side. The idea is to 
generate a Shepherd config file, allowing a user to invoke 
shepherd manually to start their services. A further extension to 
this would be to have something like systemd's "user sessions", 
where the pid 1 Shepherd automatically starts a user's services 
when they log in.


Child process control - this is my personal frustration, where 
Shepherd loses track of processes that fork away (e.g. "emacs 
--daemon"). I barely know anything about Linux process management, 
but from my reading this can be solved through Linux namespaces 
(if user namespaces are available). Could someone who knows more 
about this let me know if that's a productive direction for me to 
investigate? Or tell me a better way to go about it?


Concurrency/parallelism - I think Jelle was planning to work on 
this, but I might be wrong about that. Maybe I volunteered? We're 
keen to see Shepherd starting services in parallel, where 
possible. This will require some changes to the way we start/stop 
services (because at the moment we just send a "start" signal to a 
single service to start it, which makes it hard to be parallel), 
and will require us to actually build some sort of real dependency 
resolution. Longer-term our goal should be to bring fibers into 
Shepherd, but Efraim mentioned that fibers doesn't compile on ARM 
at the moment, so we'll have to get that working first at least.


I mentioned an idea to the guys on Friday about how Shepherd 
should treat enabled/disabled services. I've thought about it some 
more, and I think it might work. The general idea is that Shepherd 
would always try to run an enabled service, and it would leave a 
disabled service as-is (unless it's needed to start another 
service). So it would kind of work like this:

- if stopped and enabled: try to start service
- if started and enabled: monitor, and restart service if it 
fails
- if retrying too often: disable this service, and all which 
depend on it

- else: only start if another enabled service depends on this one

This would mean that Shepherd could decide the best way to 
start/stop services, including doing so in parallel if possible.


So, there are our ideas! Any thoughts, or words of wisdom? 
Feedback is welcome.


Carlo

On Mon, Jan 29 2018, Carlo Zancanaro wrote:
I'm keen to do some work on shepherd. Partially this is driven 
by

me using it to manage my user session and having it not always
work right, and partially this is driven by me grepping the code
for "FIXME" (which was slightly overwhelming). If anyone is keen
to chat about it on Friday, please find me! I have some ideas
about things I'd like to do, but I don't really have any idea 
what

I'm doing. Any help/advice/encouragement you can give me will be
appreciated!

Carlo


signature.asc
Description: PGP signature

Re: Dinner in Brussels?

[Carlo Zancanaro]

On Tue, Jan 30 2018, Ludovic Courtès wrote:
To those going to the Guix workshop in Brussels this Friday: 
who’s in

for dinner (+ drink) on Friday evening?


I'm in, assuming my wife is welcome as well.

Carlo


signature.asc
Description: PGP signature

Improving Shepherd

[Carlo Zancanaro]

I'm keen to do some work on shepherd. Partially this is driven by 
me using it to manage my user session and having it not always 
work right, and partially this is driven by me grepping the code 
for "FIXME" (which was slightly overwhelming). If anyone is keen 
to chat about it on Friday, please find me! I have some ideas 
about things I'd like to do, but I don't really have any idea what 
I'm doing. Any help/advice/encouragement you can give me will be 
appreciated!


Carlo


signature.asc
Description: PGP signature

Re: [RFC] A simple draft for channels

[Carlo Zancanaro]

On Tue, Jan 23 2018, Pjotr Prins wrote:

How is it a security issue?


If I can authorise any substitute server key that I want, then I 
can authorise my own server's key. I can then create a malicious 
substitute that doesn't correspond to the build recipe in Guix. I 
could inject whatever code I want into this substitute, and have 
it placed in the store as the output for the derivation. When 
another user attempts to install the same package into their 
profile they will then use my malicious substitute (even though 
they never authorised my server's key).


Carlo


signature.asc
Description: PGP signature

Re: FOSDEM 2018 and announcing a GNU Guix/Guile day!

[Carlo Zancanaro]

On Tue, Dec 05 2017, Manolis Ragkousis wrote:
If you are going to attend please add your name to the wiki, or 
just

respond to this email, so we can order enough lunches! Of course
everyone is welcome to come whether they register or not!


Apparently I can't create an account in order to edit the wiki, 
but I am planning to attend!


Carlo


signature.asc
Description: PGP signature

Re: Building from a local source code checkout

[Carlo Zancanaro]

On 20 December 2017 9:19:00 pm AEDT, Konrad Hinsen  
wrote:
> > guix build python-activepapers 
>--with-source=~/Development/python-activepaper
>guix build: error: lstat: No such file or directory: 
>"~/Development/python-activepapers"

I found earlier today that the tilde wasn't expanded in guix package 
--manifest. Maybe it's the same for --with-source. Try putting your home 
directory in as an absolute path.

Re: File permissions on git fetched packages.

[Carlo Zancanaro]

On Sun, Sep 17 2017, Ludovic Courtès wrote:
> I think you just have to “chmod -R +w” those files.
>
> I was looking for examples of packages that use ‘git-fetch’ and that do
> that, but I couldn’t easily find one.  I suppose that’s what they do
> when they have to, though.

One example is kakoune. It has a fix-test-permissions phase which does
exactly that.

Carlo


signature.asc
Description: PGP signature

Re: Combining Guix, direnv and Emacs for environment customisation

[Carlo Zancanaro]

On Tue, Aug 29 2017, David wrote:
> There is a feature missing in 'guix environment': saving the resulting
> profile for easy access later.  I often want to build an environment
> once and not update it for awhile, but with the current state of 'guix
> environment' it's not possible. This leads me to pulling my hair out
> when I do an upgrade of Guix and have to rebuild all of my development
> environments. What was supposed to be a quick hack turns into a Guix
> maintenance session.

I also got frustrated by this when trying to keep my own checkout of
guix. Then I found out you can do this:

  guix environment guix --root=environment

This puts a link to the environment under `environment` in the local
directory. Then you can run `source environment/etc/profile; make` to
rebuild guix. This also protects the environment from garbage
collection, which was the actual problem I was trying to solve.

Carlo


signature.asc
Description: PGP signature

Re: Upgrading packages with substitutes only (bug #26608)

[Carlo Zancanaro]

On Sun, Jun 18 2017, Timothy Sample wrote:
> While the user experience would suffer a bit, it’s no real hardship to
> type
>
> $ guix package \
> --do-not-upgrade $(guix package --only-substitutes -u) \
> -u
>
> This is definitely possible.

Just checking: is the proposal that --only-substitutes /always/ prints a
list of packages without substitutes? My understanding was that it would
only print the list if there were packages without substitutes (thus
making the above potentially incorrect/wasteful if everything has a
substitute, because you shouldn't unconditionally re-run `guix
package`). I don't know if we should conflate "upgrade my profile" with
"print a list of packages without substitutes". Those aren't the same
requests.

I'm more in favour of it continuing and building the new profile, but
printing a list of packages which didn't have substitutes. If the user
wants to roll-back the upgrade then they can easily do so, but they
asked for it to be upgraded and we can still do that.

Carlo


signature.asc
Description: PGP signature

Re: Services can now have a default value

[Carlo Zancanaro]

On Sat, May 13 2017, Carlo Zancanaro wrote:
> I've attached two patches, one of which is the definition of
> define-service-type, and the other which is me changing the
> exim-service-type definition to use it.

It turns out these patches don't work at all. I wrote the code for them
around a month ago and naively assumed they'd still work. They are quite
broken, so maybe just ignore them. I'm playing around with it again now,
so we'll see what I can come up with.

Carlo


signature.asc
Description: PGP signature

Re: Services can now have a default value

[Carlo Zancanaro]

On Fri, Apr 21 2017, Carlo Zancanaro wrote:
> I'll have a go at it later today and see what I can come up with. (I'm
> not very familiar with guile/scheme libraries, but I have played around
> a fair bit with macros.)

Well, it's been a lot longer than "later today", but better late than
never, I guess!

I've attached two patches, one of which is the definition of
define-service-type, and the other which is me changing the
exim-service-type definition to use it.

I made a decision to not try to generate a define-configuration form,
and instead just generate an "old-style" define-record-type for the
configuration. That's mostly just because I don't know how to write
something that works with define-configuration and it felt more
complicated to me. If someone else wants to do that (or help me to
understand it) I'd be supportive.

I'm not really promoting this as something that should be merged at the
moment, but I'm mostly just offering it as food for thought.

Carlo

From da085158b30ae983cdaaf172ba2fb97b40d3207d Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Sat, 13 May 2017 20:20:27 +1000
Subject: [PATCH 1/2] services: Add `define-service-type`.

* gnu/services.scm (id, define-service-type): New macros.
---
 gnu/services.scm | 33 +
 1 file changed, 33 insertions(+)

diff --git a/gnu/services.scm b/gnu/services.scm
index 5c314748d..837e75568 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -50,6 +50,8 @@
 service-type-extend
 service-type-default-value
 
+define-service-type
+
 service
 service?
 service-kind
@@ -154,6 +156,37 @@
 
 (set-record-type-printer!  write-service-type)
 
+(define-syntax-rule (id ctx parts ...)
+  "Assemble PARTS into a raw (unhygienic)  identifier."
+  (datum->syntax ctx (symbol-append (if (symbol? parts)
+parts
+(syntax->datum parts)) ...)))
+
+(define-syntax define-service-type
+  (lambda (stx)
+(syntax-case stx (extensions configuration)
+  ((define-service-type service-name
+ (extensions exts ...)
+ (configuration (fields tail ...) ...))
+   (with-syntax (((field-accessors ...)
+  (map (lambda (field)
+ (id #'stx #'service-name '-configuration- field))
+   #'(fields ...
+ #`(begin
+ (define #,(id #'stx #'service-name '-service-type)
+   (service-type
+(name 'service-name)
+(extensions exts ...)))
+ (define-record-type* #,(id #'stx '< #'service-name '-configuration>)
+   #,(id #'stx #'service-name '-configuration)
+   #,(id #'stx 'make- #'service-name '-configuration)
+   #,(id #'stx #'service-name '-configuration?)
+   (fields field-accessors tail ...) ...)
+ (define-syntax-rule (#,(id #'stx #'service-name '-service) config (... ...))
+   (service
+#,(id #'stx #'service-name '-service-type)
+(#,(id #'stx #'service-name '-configuration) config (... ...))
+
 ;; Services of a given type.
 (define-record-type 
   (make-service type value)
-- 
2.12.2

From 69c471d4ebe6a24fe11e6488f93616a7afb4467a Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Sat, 13 May 2017 20:27:15 +1000
Subject: [PATCH 2/2] services: Change exim-service-type to use
 define-service-type.

* gnu/services/mail.scm: Refactor code to use define-service-type.
---
 gnu/services/mail.scm | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/gnu/services/mail.scm b/gnu/services/mail.scm
index 6305f06f8..ebc7e3d9e 100644
--- a/gnu/services/mail.scm
+++ b/gnu/services/mail.scm
@@ -1693,14 +1693,6 @@ accept from local for any relay
 ;;; Exim.
 ;;;
 
-(define-record-type*  exim-configuration
-  make-exim-configuration
-  exim-configuration?
-  (package   exim-configuration-package ;
- (default exim))
-  (config-file   exim-configuration-config-file ;file-like
- (default #f)))
-
 (define %exim-accounts
   (list (user-group
  (name "exim")
@@ -1752,15 +1744,16 @@ exim_group = exim
(zero? (system* #$(file-append package "/bin/exim")
"-bV" "-C" #$(exim-computed-config-file package config-file
 
-(define exim-profile
-  (compose list exim-configuration-package))
-
-(define exim-service-type
-  (service-type
-   (name 'exim)
-   (extensions
-(list (service-extension shepherd-root-service-type 

Re: Defining user services in Guix.

[Carlo Zancanaro]

On Sat, Apr 22 2017, Danny Milosavljevic wrote:
> Unfortunately, it still doesn't respawn redshift if it dies - it seems
> to require a pid file for that (#:start (make-forkexec-constructor ...
> #:pid-file "xxx.pid") and you have to specify #:respawn? #t. The
> invoked program then has to create "xxx.pid"). I think it would be a
> nice addition to have it monitor the process that
> make-forkexec-constructor invoked - without any pid file. Maybe it's
> even a bug...

I currently use shepherd to manage my local user daemons, and I have run
into this. There's an easy workaround, but there's definitely a bug
lurking here.

The problem is this:

> ;; Send shepherd into the background
> (action 'shepherd 'daemonize)

If you tell shepherd to turn itself into a daemon then it no longer
processes the SIGCHLD that it expects when the child dies.

I've also found that shepherd doesn't properly watch a process that uses
#:pid-file. I start my emacs with --daemon using shepherd and have it
create a pid file, but if emacs dies shepherd doesn't restart it for me.

Other than this, everything else about using shepherd to manage my user
services has worked great. I've been meaning to spend some time looking
into it, but I don't really know where to start in terms of debugging
and fixing this.

Carlo


signature.asc
Description: PGP signature

Re: Services can now have a default value

[Carlo Zancanaro]

On Fri, Apr 21 2017, Ludovic Courtès wrote:
> A ‘define-service-type’ macro or similar could generate either code the
> current framework (with  and  and
> ) or for SRFI-99-style records if we later to go that
> route.
>
> So I think we should start by designing this macro.
>
> How does that sound?

Great! I think that it's sensible to not break things for now, and we
should be able to design the macro to do that.

I'll have a go at it later today and see what I can come up with. (I'm
not very familiar with guile/scheme libraries, but I have played around
a fair bit with macros.)

> Well I don’t know, perhaps in some cases it might make sense to
> automatically instantiate things depended on.  The advantage is that as
> a user of the service (exim for instance) you don’t have to be aware of
> the services it expects (improves separation of concern).
>
> So you could blissfully write just:
>
>   (cons (service mediagoblin-service-type)
> %base-services)
>
> and behind the scenes it would add an nginx instance, an mcron instance
> with a couple of jobs, a rottlog instance, and so on.
>
> WDYT?

My main concern would be making sure that all of our services have safe
defaults that can be extended. It may lead to surprising outcomes if we
have services spun up which do more than you expect. As an example, if
someone requests exim to start as a dependency, we should make sure it
doesn't turn you into an open relay by default.

Carlo


signature.asc
Description: PGP signature

Re: Services can now have a default value

[Carlo Zancanaro]

Hey Ludo,

On Thu, Apr 20 2017, Ludovic Courtès wrote:
> There must be some sort of a mapping between service types and
> configuration types, indeed, but I’m not sure how to achieve it.
>
> One solution would be to have all the  records
> inherit (in the OO sense) from , or something along these
> lines.

This was my first thought. I couldn't see how to do OO-style inheritance
with the SRFI-9 API, though. I'm not very experienced with Guile (or
scheme generally), so I might do some more reading about that.

One nice thing about this approach is that now a "service type" is a
scheme record-type, and a "service" is a particular instance of that
record-type, which feels slightly simpler/cleaner to me.

> Or we could make  “struct vtables” and then make
>  instances of those vtables (info "(guile) Vtables").
> I’d rather avoid using those interfaces, though (currently the only
> record API we use is SRFI-9.)

I don't know what this means. I had a quick scan of the documentation,
but I'll have to read it in more detail later.

> Or we could have a ‘define-service’ macro that defines both the
>  and the , and defines a ‘foo-service’
> macro equivalent to (service foo-service-type (foo-configuration …)).
>
>   (define-service-type openssh-service-type
> openssh-service
> (extensions …)
> (configuration
>   (port openssh-service-port (default 22))
>   (use-pam? openssh-service-use-pam? (default #t
>
> and then:
>
>(operating-system
>  ;; …
>  (services (cons (openssh-service (port )) %base-services)))

I also thought about this, but I was concerned about things like
dovecot-service, where there are two configuration objects. I wouldn't
want to force us to duplicate code, and create two different service
types, if we wanted services like that in future.

Although, maybe we would actually rather enforce a "one configuration
type per service type" rule, for the sake of modifying services? It's
hard to modify a service if you can't be sure of what the type of the
configuration will be.

Do you have a preference for what approach to use? If we use a macro to
generate things then we retain the same flexibility as the current
approach which removing a bunch of boilerplate, but I'm not sure I have
the best view of the trade-offs involved.

> I’m not sure what you mean.  Is it something like what ‘simple-service’
> does?

I meant something more like what I did with exim-service-type, where I
extend a service just to ensure its presence, then I had to document
you have to have a mail-aliases-service-type in order to use exim. With
a default configuration the mail-aliases-service-type could be
automatically instantiated if it doesn't exist.

I don't think that's a good idea, though.

Carlo


signature.asc
Description: PGP signature

Re: Services can now have a default value

[Carlo Zancanaro]

Hey Ludo,

On Wed, Apr 19 2017, Ludovic Courtès wrote:
> It used to be that we would write ‘-service’ procedures.  Then when (gnu
> services) was added, each of these procedures would boil down to:
>
>   (define (foo-service #:key (foo foo) (number 42))
> (service foo-service-type
>  (foo-configuration (foo foo) (number number

Indeed, when I look at the postgresql-service procedure, it's doing
exactly this. The mysql-service one doesn't even take keyword arguments,
it just takes a mysql-configuration record and passes it straight
through.

> There are two issues here:
>
>   1. The default values here are redundant with those we also specify in
>  .
>
>   2. The ‘-service’ procedures are a bit opaque.  For things like
>  ‘modify-services’, we want to expose the fact that we have service
>  objects with an associated  value, rather than
>  hide it inside a procedure.
>
> For these reasons, I’ve been progressively suggesting that we avoid
> ‘-service’ procedures altogether, and deprecate the existing ones.
> There are still many of them though, as you write; we should remove
> them (patches welcome! easy task for a GuixSD newcomer! :-)).

Could we create a mapping from configuration -> service-type? Or somehow
embed the service-type inside the configuration record? (I prefer the
former.) That way we could specify our service list as a list of
configurations without having to doubly-specify the services.

So then instead of

  (service foo-service-type
   (foo-configuration (foo #f)
  (number 42)))

we could have:

  (foo-configuration (foo #f)
 (number 42))

and have the foo-service-type implicitly looked up when instantiating
the services.

I chose to put the mapping as configuration -> service-type (rather than
the other way around) because I'm aware of the dovecot-service-type
which has two configuration record types: dovecot-configuration and
opaque-dovecot-configuration. This would still restrict things more than
they currently are (where a configuration record type can be shared
between multiple services). I don't know whether that's a problem or
not. We could also leave the option of using the (service ...) form
while inferring it when necessary.

If we had a mapping like this then both of your issues would be solved,
I think: the default values would only have to exist in one place (the
configuration record type), and the configuration records would remain
as the interface for configuration.

> The default value thing in this thread is about making the ‘service’
> form less verbose and closer to what we had with ‘-service’
> procedures.

Yeah, okay. I guess I just saw the change and felt like it doesn't
actually change much. Having a default value saves you a bit of typing,
but only in the case where you don't want to change any configuration
for the service.

The other thing that it would buy you (which is more significant) is the
ability to create services that are required for service extensions, but
which aren't listed in the operating-system's services. I assume we
don't want to do that, though, because that could be
dangerous/surprising.

> Does that clarify things?

Yes, thanks! Are there discussions somewhere that I can read about how
this came together? I don't think I've been on the list long enough to
have seen it myself (or if I have, I can't find them).

Carlo


signature.asc
Description: PGP signature

Re: Services can now have a default value

[Carlo Zancanaro]

I have a question related to this, but about a broader issue.

On Sat, Apr 15 2017, Ludovic Courtès wrote:
>   (service openssh-service-type)

Is this supposed to be the preferred way to add a service to your
operating system? Or, put another way, as a service writer: should I
consider a *-service-type to be sufficient to complete the work of
creating a service?

Looking at various services that we have defined at the moment
(according to what is documented), most services have a procedure (ie.
*-service), and maybe also a *-service-type. For example, in "Database
Services" we have postgresql-service and mysql-service, with no
corresponding *-service-type. But then we have redis-service-type
without a *-service to go with it.

I wonder if we would be better off creating *-service procedures for
each *-service-type and documenting them as the canonical way to create
services. That way we could handle things like default arguments through
the usual scheme mechanisms, rather than our own special case.

Carlo


signature.asc
Description: PGP signature

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Carlo Zancanaro]

On Mon, Feb 27 2017, Roel Janssen wrote
> Unfortunately, I don't seem to be able to apply your patch. [ ... ]

Hmm. That's strange. I generated a new patch which hopefully will work.
I tried applying it to master on my machine and it seemed to work fine.

I'm not sure what to do with this in light of Ricardo's comments, but
I'm hopeful that it can be pushed. (The advantage not having the ability
to push is that I don't have to make any real decisions. Hooray!)

Carlo

From 8d499d361cb89c29902ef21c46b3899c2f6799f7 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Sun, 26 Feb 2017 11:34:44 +1100
Subject: [PATCH] gnu: icedtea-6: Modify certificate import to not fail for
 icedtea-8.

* gnu/packages/java.scm (icedtea-6)[arguments]: Fix install-keystore phase to
  not fail the build when attempting to import unsupported certificate
  types (which occur with icedtea-8, which inherits from icedtea-6). Also
  ensure that the keystore is able to be written to before copying it.
---
 gnu/packages/java.scm | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index e7479e1b0..1abdf607f 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -1,7 +1,8 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015, 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 Leo Famulari 
-;;; Copyright © 2016 Roel Janssen 
+;;; Copyright © 2016, 2017 Roel Janssen 
+;;; Copyright © 2017 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -706,7 +707,7 @@ build process and its dependencies, whereas Make uses Makefile format.")
"-file" temp)))
  (display "yes\n" port)
  (when (not (zero? (status:exit-val (close-pipe port
-   (error "failed to import" cert)))
+   (format #t "failed to import ~a\n" cert)))
(delete-file temp)))
 
;; This is necessary because the certificate directory contains
@@ -719,6 +720,15 @@ build process and its dependencies, whereas Make uses Makefile format.")
"/lib/security"))
(mkdir-p (string-append (assoc-ref outputs "jdk")
"/jre/lib/security"))
+
+   ;; The cacerts files we are going to overwrite are chmod'ed as
+   ;; read-only (444) in icedtea-8 (which derives from this
+   ;; package).  We have to change this so we can overwrite them.
+   (chmod (string-append (assoc-ref outputs "out")
+ "/lib/security/" keystore) #o644)
+   (chmod (string-append (assoc-ref outputs "jdk")
+ "/jre/lib/security/" keystore) #o644)
+
(install-file keystore
  (string-append (assoc-ref outputs "out")
 "/lib/security"))
@@ -1023,9 +1033,6 @@ build process and its dependencies, whereas Make uses Makefile format.")
 (find-files "openjdk.src/jdk/src/solaris/native"
 "\\.c|\\.h"))
#t)))
- ;; FIXME: This phase is needed but fails with this version of
- ;; IcedTea.
- (delete 'install-keystore)
  (replace 'install
(lambda* (#:key outputs #:allow-other-keys)
  (let ((doc (string-append (assoc-ref outputs "doc")
-- 
2.11.1



signature.asc
Description: PGP signature

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Carlo Zancanaro]

On Mon, Feb 27 2017, Ricardo Wurmus wrote
> Carlo Zancanaro  writes:
>> But then I wondered, could we just change the generate-keystore phase of
>> the icedtea-6 package to log a failed certificate import without failing
>> the build? Then we could move the permissions change there, too, which
>> would give us a smaller patch that should accomplish a similar result
>> (attached).
>
> Hmm, I have a slight preference to have the build fail in those cases,
> because that prompts us to fix the underlying problem.  Roel’s fix seems
> more direct, even though it results in more lines of code.

Sure, but then we get a situation like we currently have: the build
fails, so the keystore generation is disabled (rather than fixed) and we
have a Java package that is heavily crippled (especially for development
purposes).

If it failing actually lead to people fixing the issue then I would be
fine with that, but the issue I have is that it doesn't get fixed, it
gets disabled. I'd much rather have it work for most use cases, rather
than failing on the slightest hiccup.

My issue isn't that Roel's fix is more lines of code, it's that it is
more brittle, it hard codes package information, and it results in
unnecessary duplication of code.

>> @@ -719,6 +719,15 @@ build process and its dependencies, whereas Make uses 
>> Makefile format.")
>> "/lib/security"))
>> (mkdir-p (string-append (assoc-ref outputs "jdk")
>> "/jre/lib/security"))
>> +
>> +   ;; The cacerts files we are going to overwrite are chmod'ed 
>> as
>> +   ;; read-only (444) in icedtea-8 (which derives from this
>> +   ;; package).  We have to change this so we can overwrite 
>> them.
>> +   (chmod (string-append (assoc-ref outputs "out")
>> + "/lib/security/" keystore) #o644)
>> +   (chmod (string-append (assoc-ref outputs "jdk")
>> + "/jre/lib/security/" keystore) #o644)
>> +
>
> I don’t understand this.

What don't you understand about it? If the comment is unclear then I am
happy to clarify it further.

> It also seems inelegant to make a change in “icedtea-6” for the sake
> of “icedtea-8”. Could this be done in “icedtea-8” instead?

I agree that it's inelegant, but the alternative is to duplicate the
entire phase and make the changes in icedtea-8. Given we are using
inheritance for code re-use here, I don't think it's too bad to do
something that's always valid to fix a problem in a specific case.

> Also note that icedtea-6 will eventually be removed (as it will no
> longer receive upstream updates) and the other icedtea* packages should
> no longer use inheritance to make that possible.

The 'install-keystore phase will have to be moved to icedtea-7, then,
where the same code will be required. The phase will have to move at
some point anyway, so I don't think this is particularly significant
that it's currently in icedtea-6.

Carlo


signature.asc
Description: PGP signature

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Carlo Zancanaro]

On Sun, Feb 26 2017, Roel Janssen wrote
> Great idea.  This is also a more durable solution for when certificates
> change in nss-certs.

Yeah, that was my thinking. I had tried to do it earlier, but hadn't
noticed the incorrect permissions later on in the build (which had
caused my attempts to fail).

> I think we should add ourselves to the copyright notice.
> Other than that, I think this patch is good to be pushed.

I've added both of us to the copyright notice (I hope that isn't too
presumptuous). Patch is attached.

Thanks!

Carlo

From 1fb1116475506495f8f026c9b53cf955dec29742 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Sun, 26 Feb 2017 11:34:44 +1100
Subject: [PATCH] gnu: icedtea-6: Modify certificate import to not fail for
 icedtea-8.

* gnu/packages/java.scm (icedtea-6)[arguments]: Fix install-keystore phase to
  not fail the build when attempting to import unsupported certificate
  types (which occur with icedtea-8, which inherits from icedtea-6). Also
  ensure that the keystore is able to be written to before copying it.
---
 gnu/packages/java.scm | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index e7479e1b0..1abdf607f 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -1,7 +1,8 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015, 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 Leo Famulari 
-;;; Copyright © 2016 Roel Janssen 
+;;; Copyright © 2016, 2017 Roel Janssen 
+;;; Copyright © 2017 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -706,7 +707,7 @@ build process and its dependencies, whereas Make uses Makefile format.")
"-file" temp)))
  (display "yes\n" port)
  (when (not (zero? (status:exit-val (close-pipe port
-   (error "failed to import" cert)))
+   (format #t "failed to import ~a\n" cert)))
(delete-file temp)))
 
;; This is necessary because the certificate directory contains
@@ -719,6 +720,15 @@ build process and its dependencies, whereas Make uses Makefile format.")
"/lib/security"))
(mkdir-p (string-append (assoc-ref outputs "jdk")
"/jre/lib/security"))
+
+   ;; The cacerts files we are going to overwrite are chmod'ed as
+   ;; read-only (444) in icedtea-8 (which derives from this
+   ;; package).  We have to change this so we can overwrite them.
+   (chmod (string-append (assoc-ref outputs "out")
+ "/lib/security/" keystore) #o644)
+   (chmod (string-append (assoc-ref outputs "jdk")
+ "/jre/lib/security/" keystore) #o644)
+
(install-file keystore
  (string-append (assoc-ref outputs "out")
 "/lib/security"))
@@ -1023,9 +1033,6 @@ build process and its dependencies, whereas Make uses Makefile format.")
 (find-files "openjdk.src/jdk/src/solaris/native"
 "\\.c|\\.h"))
#t)))
- ;; FIXME: This phase is needed but fails with this version of
- ;; IcedTea.
- (delete 'install-keystore)
  (replace 'install
(lambda* (#:key outputs #:allow-other-keys)
  (let ((doc (string-append (assoc-ref outputs "doc")
-- 
2.11.1



signature.asc
Description: PGP signature

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Carlo Zancanaro]

On Fri, Feb 10 2017, Roel Janssen wrote
> [ ... ]

I was getting frustrated at not having certificates with java 8 (it's
surprisingly annoying to have to use one environment with java 7 to
download dependencies with maven, then a different environment with java
8 to actually run your program), so I downloaded and tried out your
patch. It seems to work!

But then I wondered, could we just change the generate-keystore phase of
the icedtea-6 package to log a failed certificate import without failing
the build? Then we could move the permissions change there, too, which
would give us a smaller patch that should accomplish a similar result
(attached).

From b1ed0d53a72f95fdc42fa3741ae16726782ad414 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Sun, 26 Feb 2017 11:34:44 +1100
Subject: [PATCH] gnu: icedtea-6: Modify certificate import to not fail for
 icedtea-8.

* gnu/packages/java.scm (icedtea-6)[arguments]: Fix install-keystore phase to
  not fail the build when attempting to import unsupported certificate
  types (which occur with icedtea-8, which inherits from icedtea-6). Also
  ensure that the keystore is able to be written to before copying it.
---
 gnu/packages/java.scm | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index e7479e1b0..c7f9b9aad 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -706,7 +706,7 @@ build process and its dependencies, whereas Make uses Makefile format.")
"-file" temp)))
  (display "yes\n" port)
  (when (not (zero? (status:exit-val (close-pipe port
-   (error "failed to import" cert)))
+   (format #t "failed to import ~a\n" cert)))
(delete-file temp)))
 
;; This is necessary because the certificate directory contains
@@ -719,6 +719,15 @@ build process and its dependencies, whereas Make uses Makefile format.")
"/lib/security"))
(mkdir-p (string-append (assoc-ref outputs "jdk")
"/jre/lib/security"))
+
+   ;; The cacerts files we are going to overwrite are chmod'ed as
+   ;; read-only (444) in icedtea-8 (which derives from this
+   ;; package).  We have to change this so we can overwrite them.
+   (chmod (string-append (assoc-ref outputs "out")
+ "/lib/security/" keystore) #o644)
+   (chmod (string-append (assoc-ref outputs "jdk")
+ "/jre/lib/security/" keystore) #o644)
+
(install-file keystore
  (string-append (assoc-ref outputs "out")
 "/lib/security"))
@@ -1023,9 +1032,6 @@ build process and its dependencies, whereas Make uses Makefile format.")
 (find-files "openjdk.src/jdk/src/solaris/native"
 "\\.c|\\.h"))
#t)))
- ;; FIXME: This phase is needed but fails with this version of
- ;; IcedTea.
- (delete 'install-keystore)
  (replace 'install
(lambda* (#:key outputs #:allow-other-keys)
  (let ((doc (string-append (assoc-ref outputs "doc")
-- 
2.11.1



signature.asc
Description: PGP signature

Re: [PATCH 1/5] gnu: Add emacs-ht.

[Carlo Zancanaro]

On Fri, Jan 27 2017, Ludovic Courtès wrote
> What needs to be done?  We cannot guess the upstream URL just from the
> MELPA one, can we?

No, we can't just get it from the URL, but MELPA's recipes should give
us enough information to be able to build them. (After all, they give
MELPA enough information to be able to build them.)

https://github.com/melpa/melpa/tree/master/recipes

I think this is where they're actually processed:

https://github.com/melpa/melpa/blob/8babd80660a50183d81a9269e83c9e473c450ffb/package-build/package-build.el

Carlo


signature.asc
Description: PGP signature

[PATCH] tests: Adjust pypi test to recent importer change.

[Carlo Zancanaro]

In the patch I sent recently which updated the pypi importer, I forgot
to update the corresponding tests.

Here's a fix for the tests.

Carlo

From e709e9a1cb321ff2581cc10232bae9e37048cea0 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Fri, 27 Jan 2017 14:40:49 +1100
Subject: [PATCH] tests: Adjust pypi test to recent importer change.

This is a followup to 2f977d92d3ae517788d3dee98f63680ca149aa1a.

* tests/pypi.scm ("pypi->guix-package"): Don't expect 'python-setuptools' in
'propagated-inputs'.
("pypi->guix-package, wheels"): Likewise.
---
 tests/pypi.scm | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tests/pypi.scm b/tests/pypi.scm
index f26e7fea1..447c23ee9 100644
--- a/tests/pypi.scm
+++ b/tests/pypi.scm
@@ -130,8 +130,7 @@ baz > 13.37")
  ('propagated-inputs
   ('quasiquote
(("python-bar" ('unquote 'python-bar))
-("python-baz" ('unquote 'python-baz))
-("python-setuptools" ('unquote 'python-setuptools)
+("python-baz" ('unquote 'python-baz)
  ('home-page "http://example.com";)
  ('synopsis "summary")
  ('description "summary")
@@ -194,8 +193,7 @@ baz > 13.37")
('propagated-inputs
 ('quasiquote
  (("python-bar" ('unquote 'python-bar))
-  ("python-baz" ('unquote 'python-baz))
-  ("python-setuptools" ('unquote 'python-setuptools)
+  ("python-baz" ('unquote 'python-baz)
('home-page "http://example.com";)
('synopsis "summary")
('description "summary")
-- 
2.11.0



signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add kakoune

[Carlo Zancanaro]

On Thu, Jan 26 2017, Marius Bakke wrote
> Would you like to fix it? Good catch, sorry for making the mistake on
> your behalf!

No worries!

I've attached a patch to move it to a snippet. I wasn't sure how to word
the commit message (this is the first time I've updated a package), so I
hope it's okay. If not, feel free to change it.

Thanks for the comments regarding patches/snippets/phases. I think I'll
just need to hang around a bit longer and see how things are done to get
a feel for it myself.

Carlo

From b66c5ce74f15994f7976d405171771c185a646ff Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Fri, 27 Jan 2017 10:48:12 +1100
Subject: [PATCH] gnu: kakoune: Move substitution phase to snippet.

* gnu/packages/text-editors.scm (kakoune): Move substitution phase to snippet.
---
 gnu/packages/text-editors.scm | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/text-editors.scm b/gnu/packages/text-editors.scm
index cb4855860..465c088a8 100644
--- a/gnu/packages/text-editors.scm
+++ b/gnu/packages/text-editors.scm
@@ -98,7 +98,13 @@ based command language.")
(commit commit)))
  (sha256
   (base32
-   "19qs99l8r9p1vi5pxxx9an22fvi7xx40qw3jh2cnh2mbacawvdyb"
+   "19qs99l8r9p1vi5pxxx9an22fvi7xx40qw3jh2cnh2mbacawvdyb"))
+ (modules '((guix build utils)))
+ (snippet
+  ;; Kakoune uses 'gzip' to compress its manpages. Make sure
+  ;; timestamps are not preserved for reproducibility.
+  '(substitute* "src/Makefile"
+(("gzip -f") "gzip -f --no-name")
   (build-system gnu-build-system)
   (arguments
`(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out"))
@@ -117,10 +123,6 @@ based command language.")
  (("if \\(m_shell.empty\\(\\)\\)" line)
   (string-append "m_shell = \"" (which "sh")
  "\";\n" line)))
-   ;; Kakoune uses 'gzip' to compress its manpages. Make sure
-   ;; timestamps are not preserved for reproducibility.
-   (substitute* "src/Makefile"
- (("gzip -f") "gzip -f --no-name"))
#t))
(delete 'configure)
;; kakoune requires us to be in the src/ directory to build
-- 
2.11.0



signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add kakoune

[Carlo Zancanaro]

On Thu, Jan 26 2017, Marius Bakke wrote
> I replaced the patch file with a substitution phase instead ... .

Is this the preferred way to patch reproducibility issues? I don't
really have a sense of it, but the other packages I have seen have used
either a patch or a snippet to make a build reproducible.

I don't really have a sense of when I should use a patch, a snippet, or
a phase. Can you give me a sense of when I should prefer one over the
others?

Carlo


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add kakoune

[Carlo Zancanaro]

On Thu, Jan 26 2017, Ludovic Courtès wrote
> It’s simpler to add --no-name (which suppresses timestamps and file
> names from the gzip output) to all the gzip invocation in this Makefile.
>
> Could you do that?

Done! Patch attached. I've also updated it to the most recent commit
again. I figure it's worth committing it as up-to-date as possible.

Carlo

From 6ca08153fb987d49c535120a7b451e1935d6627e Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Fri, 30 Dec 2016 02:15:59 +1100
Subject: [PATCH] gnu: Add kakoune

* gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
* gnu/packages/text-editors.scm (kakoune): New variable.
---
 gnu/local.mk   |  1 +
 .../kakoune-leave-manpages-uncompressed.patch  | 28 
 gnu/packages/text-editors.scm  | 78 +-
 3 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 59fc1a82c..e22c8e471 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -643,6 +643,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/isl-0.11.1-aarch64-support.patch	\
   %D%/packages/patches/jbig2dec-ignore-testtest.patch		\
   %D%/packages/patches/jq-CVE-2015-8863.patch			\
+  %D%/packages/patches/kakoune-leave-manpages-uncompressed.patch		\
   %D%/packages/patches/kdbusaddons-kinit-file-name.patch	\
   %D%/packages/patches/khmer-use-libraries.patch\
   %D%/packages/patches/kmod-module-directory.patch		\
diff --git a/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch
new file mode 100644
index 0..943647d0c
--- /dev/null
+++ b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch
@@ -0,0 +1,28 @@
+Kakoune uses gzip to compress its manpages, but this saves the original time
+stamp into the file. If we add --no-name to the uses of gzip then we get a
+reproducible build.
+
+--- a/src/Makefile
 b/src/Makefile
+@@ -71,19 +71,19 @@
+ 	$(CXX) $(CPPFLAGS) $(CXXFLAGS) -MD -MP -MF $(addprefix ., $(<:.cc=$(suffix).d)) -c -o $@ $<
+ 
+ # Generate the man page
+ ../doc/kak.1.gz: ../doc/kak.1.txt
+ 	a2x --no-xmllint -f manpage $<
+-	gzip -f $(basename $<)
++	gzip -f --no-name $(basename $<)
+ 
+ # Generate the editor's documentation pages
+ # Since `a2x` won't generate man pages if some sections are missing (which we don't need),
+ # we generate the pages, patch them and then compress them
+ ../doc/manpages/%.gz: ../doc/manpages/%.asciidoc
+ 	a2x --no-xmllint -f manpage $<
+ 	sed -i -r -e "s,^\.TH .+,.TH KAKOUNE 1 \"\" \"\" \"$(basename $(notdir $<))\"," \
+ 	-e "/^\.SH \"NAME\"/{N;d;}" $(@:.gz=.1)
+-	gzip -f $(@:.gz=.1)
++	gzip -f --no-name $(@:.gz=.1)
+ 	mv -f $(@:.gz=.1.gz) $@
+ 
+ check: test
+ test:
diff --git a/gnu/packages/text-editors.scm b/gnu/packages/text-editors.scm
index 4e2324dbe..110234a49 100644
--- a/gnu/packages/text-editors.scm
+++ b/gnu/packages/text-editors.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016 José Miguel Sánchez García 
+;;; Copyright © 2016 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -19,13 +20,20 @@
 (define-module (gnu packages text-editors)
   #: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 licenses) #:prefix license:)
   #:use-module (gnu packages)
   #:use-module (gnu packages lua)
   #:use-module (gnu packages ncurses)
-  #:use-module (gnu packages terminals))
+  #:use-module (gnu packages terminals)
+  #:use-module (gnu packages gcc)
+  #:use-module (gnu packages bash)
+  #:use-module (gnu packages documentation)
+  #:use-module (gnu packages boost)
+  #:use-module (gnu packages ruby)
+  #:use-module (gnu packages xml))
 
 (define-public vis
   (package
@@ -75,3 +83,71 @@ based command language.")
 (license (list license:isc   ; Main distribution.
license:public-domain ; map.[ch]
license:expat ; lexers and libutf.[ch]
+
+(define-public kakoune
+  (let ((commit "125c8b7e80995732e0d8c87b82040025748f1b4f")
+(revision "1"))
+(package
+  (name "kakoune")
+  (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+  (source
+   (origin
+ (file-name (string-append "kakoune-" version "-checkout"))
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/mawww/kakoune.git";)
+   (commit commit)))
+  

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

[Carlo Zancanaro]

On Mon, Jan 02 2017, Carlo Zancanaro wrote
> ... patch used to be here ...

Now that the patches for its dependencies have been pushed, can anyone
review this patch for Electrum?


signature.asc
Description: PGP signature

[PATCH] import: pypi: Don't add setuptools to propagated-inputs.

[Carlo Zancanaro]

The pypi importer currently adds python-setuptools to the propagated
inputs. According to the manual we don't need to do this any more, so
here's a patch that updates the importer to match.

From d819fce415614d269fbb28f035963e6e0d6efbee Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Sat, 21 Jan 2017 16:15:21 +1100
Subject: [PATCH] import: pypi: Don't add setuptools to propagated-inputs.

* guix/import/pypi.scm (compute-inputs): Don't add setuptools to the imported
  package's propagated-inputs.
---
 guix/import/pypi.scm | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/guix/import/pypi.scm b/guix/import/pypi.scm
index 7cce0fc59..ed0d4297a 100644
--- a/guix/import/pypi.scm
+++ b/guix/import/pypi.scm
@@ -227,10 +227,8 @@ name/variable pairs describing the required inputs of this package."
   (sort
 (map (lambda (input)
(list input (list 'unquote (string->symbol input
- (append '("python-setuptools")
- ;; Argparse has been part of Python since 2.7.
- (remove (cut string=? "python-argparse" <>)
- (guess-requirements source-url wheel-url tarball
+ (remove (cut string=? "python-argparse" <>)
+ (guess-requirements source-url wheel-url tarball)))
 (lambda args
   (match args
 (((a _ ...) (b _ ...))
-- 
2.11.0



signature.asc
Description: PGP signature

[PATCH 3/4] gnu: Add python2-slowaes

[Carlo Zancanaro]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 0ee1b6ef8..ad62c25e8 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12516,3 +12516,24 @@ console.")
 
 (define-public python2-qrcode
   (package-with-python2 python-qrcode))
+
+;; SlowAES isn't compatible with Python 3.
+(define-public python2-slowaes
+  (package
+(name "python-slowaes")
+(version "0.1a1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "slowaes" version))
+   (sha256
+(base32
+ "02dzajm83a7lqgxf6r3hgj64wfmcxz8gs4nvgxpvj5n19kjqlrc3"
+(build-system python-build-system)
+(arguments `(#:python ,python-2))
+(home-page "http://code.google.com/p/slowaes/";)
+(synopsis "Implementation of AES in Python")
+(description "This package contains an implementation of AES in Python.
+This implementation is slow (hence the project name) but still useful when
+faster ones are not available.")
+(license license:asl2.0)))
-- 
2.11.0

[PATCH 2/4] gnu: Add python-qrcode.

[Carlo Zancanaro]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 21347b25e..0ee1b6ef8 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12491,3 +12491,28 @@ a file-like object from which an arbitrarly-sized key 
can be read.")
 (define-public python2-pbkdf2
   (package-with-python2 python-pbkdf2))
 
+(define-public python-qrcode
+  (package
+(name "python-qrcode")
+(version "5.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "qrcode" version))
+   (sha256
+(base32
+ "0kljfrfq0c2rmxf8am57333ia41kd0snbm2rnqbdy816hgpcq5a1"
+(build-system python-build-system)
+(home-page "https://github.com/lincolnloop/python-qrcode";)
+(synopsis "QR Code image generator")
+(description "This package provides a pure Python QR Code generator
+module.  It uses the Python Imaging Library (PIL) to allow for the generation
+of QR Codes.
+
+In addition this package provides a command line tool to generate QR codes and
+either write these QR codes to a file or do the output as ascii art at the
+console.")
+(license license:bsd-3)))
+
+(define-public python2-qrcode
+  (package-with-python2 python-qrcode))
-- 
2.11.0

[PATCH 1/4] gnu: Add python-pbkdf2.

[Carlo Zancanaro]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 6a5b0c4f1..21347b25e 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -34,6 +34,7 @@
 ;;; Copyright © 2016 Julien Lepiller 
 ;;; Copyright © 2016, 2017 Tobias Geerinckx-Rice 
 ;;; Copyright © 2016 Thomas Danckaert 
+;;; Copyright © 2017 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -12462,3 +12463,31 @@ Features:
 @item Compiles templates into optimized, yet readable, Python code.
 @end enumerate")
 (license (license:x11-style "file://LICENSE"
+
+(define-public python-pbkdf2
+  (package
+(name "python-pbkdf2")
+(version "1.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "pbkdf2" version))
+   (sha256
+(base32
+ "0yb99rl2mbsaamj571s1mf6vgniqh23v98k4632150hjkwv9fqxc"
+(build-system python-build-system)
+(home-page "http://www.dlitz.net/software/python-pbkdf2/";)
+(synopsis "Password-based key derivation")
+(description "This module implements the password-based key derivation
+function, PBKDF2, specified in RSA PKCS#5 v2.0.
+
+PKCS#5 v2.0 Password-Based Key Derivation is a key derivation function which
+is part of the RSA Public Key Cryptography Standards series.  The provided
+implementation takes a password or a passphrase and a salt value (and
+optionally a iteration count, a digest module, and a MAC module) and provides
+a file-like object from which an arbitrarly-sized key can be read.")
+(license license:expat)))
+
+(define-public python2-pbkdf2
+  (package-with-python2 python-pbkdf2))
+
-- 
2.11.0

Re: [PATCH] gnu: Add kakoune

[Carlo Zancanaro]

Let's give this another try, then. I think I've taken into account all
your feedback, and I've updated to a more recent kakoune commit.

From a15396f186d5a88f7fbe1af21add9bbd40ddc59b Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Fri, 30 Dec 2016 02:15:59 +1100
Subject: [PATCH] gnu: Add kakoune

* gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
* gnu/packages/text-editors.scm (kakoune): New variable.
---
 gnu/local.mk   |  1 +
 .../kakoune-leave-manpages-uncompressed.patch  | 69 +++
 gnu/packages/text-editors.scm  | 78 +-
 3 files changed, 147 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 2da8b82db..ce7a905d2 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -645,6 +645,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/isl-0.11.1-aarch64-support.patch	\
   %D%/packages/patches/jbig2dec-ignore-testtest.patch		\
   %D%/packages/patches/jq-CVE-2015-8863.patch			\
+  %D%/packages/patches/kakoune-leave-manpages-uncompressed.patch		\
   %D%/packages/patches/kdbusaddons-kinit-file-name.patch	\
   %D%/packages/patches/khal-disable-failing-tests.patch		\
   %D%/packages/patches/khmer-use-libraries.patch\
diff --git a/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch
new file mode 100644
index 0..eb1acb34d
--- /dev/null
+++ b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch
@@ -0,0 +1,69 @@
+Kakoune compresses its manpages, which makes the build non-reproducible (as it
+leaves timestamps in files). If we don't do that here, and instead do it in
+the guix phases `compress-manpages` then the build is reproducible.
+
+--- a/src/Makefile
 b/src/Makefile
+@@ -22,7 +22,7 @@
+ objects := $(addprefix ., $(sources:.cc=$(suffix).o))
+ deps := $(addprefix ., $(sources:.cc=$(suffix).d))
+ docs := $(wildcard ../doc/manpages/*.asciidoc)
+-mandocs := $(docs:.asciidoc=.gz)
++mandocs := $(docs:.asciidoc=.1)
+ 
+ PREFIX ?= /usr/local
+ DESTDIR ?= # root dir
+@@ -76,19 +76,17 @@
+ 	$(CXX) $(CPPFLAGS) $(CXXFLAGS) -MD -MP -MF $(addprefix ., $(<:.cc=$(suffix).d)) -c -o $@ $<
+ 
+ # Generate the man page
+-../doc/kak.1.gz: ../doc/kak.1.txt
++../doc/kak.1: ../doc/kak.1.txt
+ 	a2x --no-xmllint -f manpage $<
+-	gzip -f $(basename $<)
+ 
+ # Generate the editor's documentation pages
+ # Since `a2x` won't generate man pages if some sections are missing (which we don't need),
+-# we generate the pages, patch them and then compress them
+-../doc/manpages/%.gz: ../doc/manpages/%.asciidoc
++# we generate the pages and patch them
++../doc/manpages/%.1: ../doc/manpages/%.asciidoc
+ 	a2x --no-xmllint -f manpage $<
+ 	sed -i -r -e "s,^\.TH .+,.TH KAKOUNE 1 \"\" \"\" \"$(basename $(notdir $<))\"," \
+-	-e "/^\.SH \"NAME\"/{N;d;}" $(@:.gz=.1)
+-	gzip -f $(@:.gz=.1)
+-	mv -f $(@:.gz=.1.gz) $@
++	-e "/^\.SH \"NAME\"/{N;d;}" $@
++
+ 
+ check: test
+ test:
+@@ -97,7 +95,7 @@
+ TAGS: tags
+ tags:
+ 	ctags -R
+-man: ../doc/kak.1.gz
++man: ../doc/kak.1
+ doc: $(mandocs)
+ 
+ clean:
+@@ -124,8 +122,8 @@
+ 	[ -e $(sharedir)/autoload ]	|| ln -s rc	$(sharedir)/autoload
+ 	install	-m 0644	../colors/*	$(sharedir)/colors
+ 	install	-m 0644	../README.asciidoc $(docdir)
+-	install	-m 0644	../doc/manpages/*.gz $(docdir)/manpages
+-	install	-m 0644	../doc/kak.1.gz	$(mandir)
++	install	-m 0644	../doc/manpages/*.1 $(docdir)/manpages
++	install	-m 0644	../doc/kak.1	$(mandir)
+ 
+ install-strip: install
+ 	strip -s $(bindir)/kak
+@@ -134,7 +132,7 @@
+ 	rm -rf $(bindir)/kak \
+ 		$(sharedir)	\
+ 		$(docdir) \
+-		$(mandir)/kak.1.gz
++		$(mandir)/kak.1
+ 
+ .PHONY: check TAGS clean distclean installdirs install install-strip uninstall
+ .PHONY: tags test man doc
diff --git a/gnu/packages/text-editors.scm b/gnu/packages/text-editors.scm
index 4e2324dbe..8b7e95975 100644
--- a/gnu/packages/text-editors.scm
+++ b/gnu/packages/text-editors.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016 José Miguel Sánchez García 
+;;; Copyright © 2016 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -19,13 +20,20 @@
 (define-module (gnu packages text-editors)
   #: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 licenses) #:prefix license:)
   #:use-module (gnu packages)
   #:use-module (gnu packages lua)
   #:use-module (gnu packages ncurses)
-  #:use-module (gnu packages terminals))
+  #:use-module (gnu packages terminals)
+  #:use-module (gnu package

[PATCH 4/4] gnu: Add electrum.

[Carlo Zancanaro]

* gnu/packages/finance.scm (electrum): New variable.
---
 gnu/packages/finance.scm | 51 
 1 file changed, 51 insertions(+)

diff --git a/gnu/packages/finance.scm b/gnu/packages/finance.scm
index 792482782..ee90c38eb 100644
--- a/gnu/packages/finance.scm
+++ b/gnu/packages/finance.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2016 Efraim Flashner 
 ;;; Copyright © 2016 Alex Griffin 
 ;;; Copyright © 2016 Hartmut Goebel 
+;;; Copyright © 2017 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -26,6 +27,7 @@
  #:use-module (guix build utils)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system cmake)
+ #:use-module (guix build-system python)
  #:use-module (gnu packages base)
  #:use-module (gnu packages boost)
  #:use-module (gnu packages databases)
@@ -240,3 +242,52 @@ allow to do that off the ERiC library (which is 
proprietary however).
 It's not clear at the moment whether one day it will be possible to
 do so.")
 (license license:agpl3+)))
+
+(define-public electrum
+  (package
+(name "electrum")
+(version "2.7.12")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://download.electrum.org/";
+   version "/Electrum-"
+   version ".tar.gz"))
+   (sha256
+(base32
+ "0vxdfl208if7mdsnva1jg37bnay2dsz3ww157aqwcv1j6512fi1n"))
+   (modules '((guix build utils)))
+   (snippet
+'(begin
+   ;; Delete the bundled dependencies.
+   (delete-file-recursively "packages")
+   #t
+(build-system python-build-system)
+(inputs
+ `(("python-slowaes" ,python2-slowaes)
+   ("python-sip" ,python2-sip)
+   ("python-pyqt" ,python2-pyqt-4)
+   ("python-ecdsa" ,python2-ecdsa)
+   ("python-pbkdf2" ,python2-pbkdf2)
+   ("python-requests" ,python2-requests)
+   ("python-qrcode" ,python2-qrcode)
+   ("python-protobuf" ,python2-protobuf)
+   ("python-dnspython" ,python2-dnspython)
+   ("python-jsonrpclib" ,python2-jsonrpclib)))
+(arguments
+ `(#:python ,python-2
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'build 'patch-home
+   (lambda* (#:key outputs #:allow-other-keys)
+ (substitute* "setup.py"
+   (("~/.local/share")
+(string-append (assoc-ref outputs "out") "/local/share"
+(home-page "https://electrum.org/";)
+(synopsis "Bitcoin wallet")
+(description
+ "Electrum is a lightweight Bitcoin client, based on a client-server
+protocol.  It supports Simple Payment Verification (SPV) and deterministic key
+generation from a seed.  Your secret keys are encrypted and are never sent to
+other machines/servers.  Electrum does not download the Bitcoin blockchain.")
+(license license:expat)))
-- 
2.11.0

[PATCH 2/4] gnu: Add python-qrcode.

[Carlo Zancanaro]

* gnu/packages/python.scm (python-qrcode, python2-qrcode): 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 2841830f0..9afb2f0b1 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12293,3 +12293,27 @@ function, PBKDF2, specified in RSA PKCS#5 v2.0.")
 
 (define-public python2-pbkdf2
   (package-with-python2 python-pbkdf2))
+
+(define-public python-qrcode
+  (package
+(name "python-qrcode")
+(version "5.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "qrcode" version))
+   (sha256
+(base32
+ "0kljfrfq0c2rmxf8am57333ia41kd0snbm2rnqbdy816hgpcq5a1"
+(build-system python-build-system)
+(propagated-inputs
+ `(("python-setuptools" ,python-setuptools)))
+(home-page
+ "https://github.com/lincolnloop/python-qrcode";)
+(synopsis "QR Code image generator")
+(description "This module uses image libraries, Python Imaging
+Library (PIL) by default, to generate QR Codes.")
+(license license:bsd-3)))
+
+(define-public python2-qrcode
+  (package-with-python2 python-qrcode))
-- 
2.11.0

[PATCH 3/4] gnu: Add python2-slowaes

[Carlo Zancanaro]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 9afb2f0b1..eb238fc1e 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12317,3 +12317,25 @@ Library (PIL) by default, to generate QR Codes.")
 
 (define-public python2-qrcode
   (package-with-python2 python-qrcode))
+
+;; SlowAES isn't compatible with Python 3.
+(define-public python2-slowaes
+  (package
+(name "python-slowaes")
+(version "0.1a1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "slowaes" version))
+   (sha256
+(base32
+ "02dzajm83a7lqgxf6r3hgj64wfmcxz8gs4nvgxpvj5n19kjqlrc3"
+(build-system python-build-system)
+(arguments `(#:python ,python-2))
+(propagated-inputs
+ `(("python-setuptools" ,python-setuptools)))
+(home-page "http://code.google.com/p/slowaes/";)
+(synopsis "Implementation of AES in Python")
+(description "This module implements the AES encryption algorithm in
+python.")
+(license license:asl2.0)))
-- 
2.11.0

[PATCH 1/4] gnu: Add python-pbkdf2.

[Carlo Zancanaro]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index fce62175b..2841830f0 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -34,6 +34,7 @@
 ;;; Copyright © 2016 Julien Lepiller 
 ;;; Copyright © 2016, 2017 Tobias Geerinckx-Rice 
 ;;; Copyright © 2016 Thomas Danckaert 
+;;; Copyright © 2017 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -12268,3 +12269,27 @@ possible on all supported Python versions.")
 
 (define-public python2-xopen
   (package-with-python2 python-xopen))
+
+(define-public python-pbkdf2
+  (package
+(name "python-pbkdf2")
+(version "1.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "pbkdf2" version))
+   (sha256
+(base32
+ "0yb99rl2mbsaamj571s1mf6vgniqh23v98k4632150hjkwv9fqxc"
+(build-system python-build-system)
+(propagated-inputs
+ `(("python-setuptools" ,python-setuptools)))
+(home-page
+ "http://www.dlitz.net/software/python-pbkdf2/";)
+(synopsis "PKCS#5 v2.0 PBKDF2 Module")
+(description "This module implements the password-based key derivation
+function, PBKDF2, specified in RSA PKCS#5 v2.0.")
+(license license:expat)))
+
+(define-public python2-pbkdf2
+  (package-with-python2 python-pbkdf2))
-- 
2.11.0

[PATCH 0/4] Add electrum

[Carlo Zancanaro]

These patches are to add Electrum, a Bitcoin client. The three python
libraries are the only dependencies that weren't already packaged. They're
mostly just from the pypi importer and they seem correct to me.

Carlo Zancanaro (4):
  gnu: Add python-pbkdf2.
  gnu: Add python-qrcode.
  gnu: Add python2-slowaes
  gnu: Add electrum.

 gnu/packages/finance.scm | 50 ++
 gnu/packages/python.scm  | 71 
 2 files changed, 121 insertions(+)

-- 
2.11.0

Re: [PATCH] gnu: Add kakoune

[Carlo Zancanaro]

On Fri, Dec 30 2016, Leo Famulari wrote
>> diff --git a/gnu/packages/patches/kakoune-fix-bash-path.patch 
>> b/gnu/packages/patches/kakoune-fix-bash-path.patch
>> diff --git a/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch 
>> b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch
>
> Patches require some commentary explaining what problem they are solving
> and, if the approach they take is unclear, how they do it. If they are
> copied from somewhere else, they need attribution.
>
> In this case, we need to explain why upstream's approach of finding a
> POSIX shell doesn't work.

Perhaps you can give me a hint on this. I've patched it myself because
the original code uses confstr with _CS_PATH, but within the build
environment (and presumably outside of it, too) it gives back
"/bin:/usr/bin". Within the build environment this is invalid (as
neither directory exists), so the tests all fail. There is a bug[1]
about this already, but it was closed without fixing the issue (due to
some complexity/ambiguity in doing so, and no immediate need to fix it).

I can try to come up with a better way to patch this, but I don't know
if I should actually use the PATH environment variable. The patch that
changed this code to use _CS_PATH instead of PATH was made fifteen days
ago and was apparently to "use a POSIX guaranteed way of getting the
shell path"[2].

I could package the commit from just before the patch instead (which
would make this problem go away for now), or we can try to come up with
a real solution to the problem.

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23112.
[2]: 
https://github.com/mawww/kakoune/commit/9a879262a272bd4c6458fcfa07a9289ee41d7220

>> +   (add-before 'configure 'patch-bash-path
>> + (lambda* (#:key inputs #:allow-other-keys)
>> +   (substitute* "src/shell_manager.cc"
>> + (("__BASH_PATH__")
>> +  (assoc-ref inputs "bash")
>
> I wonder if we can do this change all in the same place. It's sort of
> complicated to use a patch and a substitution.
>
> Also, using a patch to get half-way there will cause the source code
> given by `guix build --source` to be unbuildable, right? So, I think we
> should find another way to fix whatever is wrong with the shell-finding
> logic. Perhaps it will require cooperation with the upstream
> maintainers, I don't know.

I hadn't thought about the effect this would have on `guix build
--source`. That's a fairly big problem.

Everything else that I haven't responded to is fine. I'll fix them up
and send a new patch once I have some direction on the _CS_PATH issue.

Carlo


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add kakoune

[Carlo Zancanaro]

It turns out emacs decided to destroy my whitespace!

I'll attach it this time.

From 57b2f9e6af20606e302fc4040515d7a92bde73fc Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Fri, 30 Dec 2016 02:15:59 +1100
Subject: [PATCH] gnu: Add kakoune
To: guix-devel@gnu.org

* gnu/packages/patches/kakoune-fix-bash-path.patch: New file.
* gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patches.
* gnu/packages/text-editors.scm (kakoune): New variable.
---
 gnu/local.mk   |  2 +
 gnu/packages/patches/kakoune-fix-bash-path.patch   | 34 ++
 .../kakoune-leave-manpages-uncompressed.patch  | 65 +++
 gnu/packages/text-editors.scm  | 73 +-
 4 files changed, 173 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/kakoune-fix-bash-path.patch
 create mode 100644 gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 106adb235..5517be2de 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -640,6 +640,8 @@ dist_patch_DATA =		\
   %D%/packages/patches/isl-0.11.1-aarch64-support.patch	\
   %D%/packages/patches/jbig2dec-ignore-testtest.patch		\
   %D%/packages/patches/jq-CVE-2015-8863.patch			\
+  %D%/packages/patches/kakoune-fix-bash-path.patch		\
+  %D%/packages/patches/kakoune-leave-manpages-uncompressed.patch		\
   %D%/packages/patches/kdbusaddons-kinit-file-name.patch	\
   %D%/packages/patches/khmer-use-libraries.patch\
   %D%/packages/patches/kmod-module-directory.patch		\
diff --git a/gnu/packages/patches/kakoune-fix-bash-path.patch b/gnu/packages/patches/kakoune-fix-bash-path.patch
new file mode 100644
index 0..35b076d57
--- /dev/null
+++ b/gnu/packages/patches/kakoune-fix-bash-path.patch
@@ -0,0 +1,34 @@
+--- a/src/shell_manager.cc
 b/src/shell_manager.cc
+@@ -22,30 +22,7 @@
+ 
+ ShellManager::ShellManager()
+ {
+-// Get a guaranteed to be POSIX shell binary
+-{
+-auto size = confstr(_CS_PATH, 0, 0);
+-String path; path.resize(size-1, 0);
+-confstr(_CS_PATH, path.data(), size);
+-for (auto dir : StringView{path} | split(':'))
+-{
+-String candidate = format("{}/sh", dir);
+-struct stat st;
+-if (stat(candidate.c_str(), &st))
+-continue;
+-
+-bool executable = (st.st_mode & S_IXUSR)
+-| (st.st_mode & S_IXGRP)
+-| (st.st_mode & S_IXOTH);
+-if (S_ISREG(st.st_mode) and executable)
+-{
+-m_shell = std::move(candidate);
+-break;
+-}
+-}
+-if (m_shell.empty())
+-throw runtime_error{format("unable to find a posix shell in {}", path)};
+-}
++m_shell = "__BASH_PATH__/bin/sh";
+ 
+ // Add Kakoune binary location to the path to guarantee that %sh{ ... }
+ // have access to the kak command regardless of if the user installed it
diff --git a/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch
new file mode 100644
index 0..f7118c309
--- /dev/null
+++ b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch
@@ -0,0 +1,65 @@
+--- a/src/Makefile
 b/src/Makefile
+@@ -22,7 +22,7 @@
+ objects := $(addprefix ., $(sources:.cc=$(suffix).o))
+ deps := $(addprefix ., $(sources:.cc=$(suffix).d))
+ docs := $(wildcard ../doc/manpages/*.asciidoc)
+-mandocs := $(docs:.asciidoc=.gz)
++mandocs := $(docs:.asciidoc=.1)
+ 
+ PREFIX ?= /usr/local
+ DESTDIR ?= # root dir
+@@ -76,19 +76,17 @@
+ 	$(CXX) $(CPPFLAGS) $(CXXFLAGS) -MD -MP -MF $(addprefix ., $(<:.cc=$(suffix).d)) -c -o $@ $<
+ 
+ # Generate the man page
+-../doc/kak.1.gz: ../doc/kak.1.txt
++../doc/kak.1: ../doc/kak.1.txt
+ 	a2x --no-xmllint -f manpage $<
+-	gzip -f $(basename $<)
+ 
+ # Generate the editor's documentation pages
+ # Since `a2x` won't generate man pages if some sections are missing (which we don't need),
+-# we generate the pages, patch them and then compress them
+-../doc/manpages/%.gz: ../doc/manpages/%.asciidoc
++# we generate the pages and patch them
++../doc/manpages/%.1: ../doc/manpages/%.asciidoc
+ 	a2x --no-xmllint -f manpage $<
+ 	sed -i -r -e "s,^\.TH .+,.TH KAKOUNE 1 \"\" \"\" \"$(basename $(notdir $<))\"," \
+-	-e "/^\.SH \"NAME\"/{N;d;}" $(@:.gz=.1)
+-	gzip -f $(@:.gz=.1)
+-	mv -f $(@:.gz=.1.gz) $@
++	-e "/^\.SH \"NAME\"/{N;d;}" $@
++
+ 
+ check: test
+ test:
+@@ -97,7 +95,7 @@
+ TAGS: tags
+ tags:
+ 	ctags -R
+-man: ../doc/kak.1.gz
++man: ../doc/kak.1
+ doc: $(mandocs)
+ 
+ clean:
+@@ -124,8 +122,8 @@
+ 	[ -e $(sharedir)/autoload ]	|| ln -s rc	$(sharedir)/au

[PATCH] gnu: Add kakoune

[Carlo Zancanaro]

stall	-m 0644 
../doc/kak.1	$(mandir) +  + install-strip: install + 
strip -s $(bindir)/kak +@@ -134,7 +132,7 @@ + 	rm -rf 
$(bindir)/kak \ + 		$(sharedir)	\ + 
$(docdir) \ +-		$(mandir)/kak.1.gz ++ 
$(mandir)/kak.1 +  + .PHONY: check TAGS clean distclean 
installdirs install install-strip uninstall + .PHONY: tags test 
man doc diff --git a/gnu/packages/text-editors.scm 
b/gnu/packages/text-editors.scm index 4e2324dbe..c3981948e 100644 
--- a/gnu/packages/text-editors.scm +++ 
b/gnu/packages/text-editors.scm @@ -1,5 +1,6 @@ 
;;; GNU Guix --- Functional package management for GNU ;;; 
Copyright © 2016 José Miguel Sánchez García 
 
+;;; Copyright © 2016 Carlo Zancanaro  
;;; ;;; This file is part of GNU Guix.  ;;; 
@@ -19,13 +20,20 @@ 
(define-module (gnu packages text-editors) 
  #: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 licenses) #:prefix license:) #:use-module 
  (gnu packages) #:use-module (gnu packages lua) #:use-module 
  (gnu packages ncurses) 
-  #:use-module (gnu packages terminals)) +  #:use-module (gnu 
packages terminals) +  #:use-module (gnu packages gcc) + 
#:use-module (gnu packages bash) +  #:use-module (gnu packages 
documentation) +  #:use-module (gnu packages boost) + 
#:use-module (gnu packages ruby) +  #:use-module (gnu packages 
xml)) 
 
(define-public vis 
  (package 
@@ -75,3 +83,66 @@ based command language.") 
(license (list license:isc   ; Main distribution. 
   license:public-domain ; map.[ch] 
   license:expat ; lexers and 
   libutf.[ch] 
+ +(define-public kakoune +  (let ((commit 
"4f986776423f5cd5fd80a16735f873ae23c10da2")) +(package + 
(name "kakoune") +  (version (string-append "0.0.1-" 
(string-take commit 7))) +  (source +   (origin + 
(file-name (string-append "kakoune-" version)) + (method 
git-fetch) + (uri (git-reference +   (url 
"https://github.com/mawww/kakoune.git";) +   (commit 
commit))) + (sha256 +  (base32 + 
"1nwkz18f73xcygayj42ijd70afzvwpasnqj84x4pdxgf4s349ipy")) + 
(patches +  (search-patches + 
"kakoune-fix-bash-path.patch" + 
"kakoune-leave-manpages-uncompressed.patch" + 
(build-system gnu-build-system) +  (arguments + 
`(#:phases + (modify-phases %standard-phases + 
(add-before 'configure 'patch-bash-path + (lambda* 
(#:key inputs #:allow-other-keys) +   (substitute* 
"src/shell_manager.cc" + (("__BASH_PATH__") + 
(assoc-ref inputs "bash") +   ;; Kakoune doesn't have 
a configure script, but it still +   ;; requires us to do 
some setup/configuration.  +   (replace 'configure + 
(lambda* (#:key outputs #:allow-other-keys) +   ;; 
Make has to be run in the src/ directory, so let's + 
;; move there now.  +   (chdir "src") + 
;; Boost is compiled with the older ABI, so we can't use + 
;; the new ABI if we want to link againt it.  + 
(setenv "CPPFLAGS" "-D_GLIBCXX_USE_CXX11_ABI=0") + 
(setenv "PREFIX" (assoc-ref outputs "out" + 
(add-before 'check 'fix-test-permissions + (lambda* _ 
+   ;; The tests fail if they can't write over files 
in the +   ;; test directory, so make sure we can 
write everywhere +   ;; we might possibly need to.  + 
(system* "chmod" "-R" "u+w" "../test")) +  (native-inputs 
`(("gcc" ,gcc-5) +   ("libxslt" ,libxslt) + 
("asciidoc" ,asciidoc) +   ("ruby" ,ruby))) + 
(inputs `(("gcc:lib" ,gcc-5 "lib") +("bash" ,bash) 
+("ncurses" ,ncurses) +("boost" 
,boost))) +  (synopsis "Vim-inspired code editor") + 
(description +   "Kakoune is a code editor heavily inspired by 
Vim, as such most of its +commands are similar to Vi's ones, and 
it shares Vi's \"keystrokes as a text +editing language\" model. 
Kakoune has a strong focus on interactivity, most +commands 
provide immediate and incremental results, while still being 
+competitive (as in keystroke count) with Vim.")  + 
(home-page "http://kakoune.org/";) +  (license 
license:unlicense --  2.11.0 



signature.asc
Description: PGP signature

Re: GuixSD + StumpWM

[Carlo Zancanaro]

On Wed, Dec 28 2016, Daniel Pimentel wrote 
I'm trying use StumpWM in my config.scm but there's code for 
module:


guix system: error: failed to load '/etc/config.scm': 
ice-9/boot-9.scm:2870:6: In procedure resolve-interface: 
ice-9/boot-9.scm:2870:6: no code for module (gnu packages 
sbcl-stumpwm)


My config.scm: (use-modules (gnu) (gnu system nss)) 
(use-service-modules desktop) (use-package-modules wm 
sbcl-stumpwm certs)


It looks like the sbcl-stumpwm package is in (gnu packages lisp). If you
replace `sbcl-stumpwm` with `lisp` here it should be able to find it
(ie. `(use-package-modules wm lisp certs)`).


signature.asc
Description: PGP signature

Re: [PATCH] Elpa importer improvements

[Carlo Zancanaro]

On Tue, Dec 27 2016, Alex Kost wrote

[...]

-  (proc (http-fetch/cached (string->uri url +  (catch #t + 
(lambda () +  (proc (http-fetch/cached (string->uri url 
+(lambda (key . args) +  (if error-thunk + 
(error-thunk) +  (apply throw key args)


So here you fixed a regression introduced by commit 218622a73¹, 
thanks!  I think it's better to call 'leave' on the last line as 
it was done originally.


Ah, so that's what it meant by "leave"! I misunderstood. I had 
interpreted it as "leave the error alone", so thought re-throwing 
was consistent with that. I've attached an updated patch to use 
the original "leave" line.


From 35da0d4977f217be6aefb24ab062b646d17de671 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Wed, 14 Dec 2016 12:31:12 +1100
Subject: [PATCH 1/2] import: elpa: Fix call-with-downloaded-file

* guix/import/elpa.scm (call-with-downloaded-file): Make function behaviour
match documentation string.
---
 guix/import/elpa.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/import/elpa.scm b/guix/import/elpa.scm
index 320a09e8c..ec232cd8a 100644
--- a/guix/import/elpa.scm
+++ b/guix/import/elpa.scm
@@ -89,7 +89,13 @@ NAMES (strings)."
   "Fetch URL, store the content in a temporary file and call PROC with that
 file.  Returns the value returned by PROC.  On error call ERROR-THUNK and
 return its value or leave if it's false."
-  (proc (http-fetch/cached (string->uri url
+  (catch #t
+(lambda ()
+  (proc (http-fetch/cached (string->uri url
+(lambda (key . args)
+  (if error-thunk
+  (error-thunk)
+  (leave (_ "~A: download failed~%") url)
 
 (define (is-elpa-package? name elpa-pkg-spec)
   "Return true if the string NAME corresponds to the name of the package
-- 
2.11.0



signature.asc
Description: PGP signature

Re: [PATCH] Elpa importer improvements

[Carlo Zancanaro]

On Wed, Dec 14 2016, Carlo Zancanaro wrote 
I was trying to import some elpa packages recently and found 
some  issues, so here are some patches to fix them.


1. call-with-downloaded-file had behaviour different to how it 
was  documented to behave. This was primarily a problem when 
trying to  import packages with no description (eg. 
color-theme-solarized on  melpa).


2. Package dependencies need to be propagated so that emacs can 
find them.


Has anyone looked at this? This is relatively minor, but now that the
0.12.0 release is done I thought a ping might be appropriate.


signature.asc
Description: PGP signature

[PATCH] Elpa importer improvements

[Carlo Zancanaro]

I was trying to import some elpa packages recently and found some 
issues, so here are some patches to fix them.


1. call-with-downloaded-file had behaviour different to how it was 
documented to behave. This was primarily a problem when trying to 
import packages with no description (eg. color-theme-solarized on 
melpa).


2. Package dependencies need to be propagated so that emacs can 
find them.


From 0e561aee91b5d389d72906d059ddf486a322f20a Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Wed, 14 Dec 2016 12:31:12 +1100
Subject: [PATCH 1/2] import: elpa: Fix call-with-downloaded-file

* guix/import/elpa.scm (call-with-downloaded-file): Make function behaviour
match documentation string.
---
 guix/import/elpa.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/import/elpa.scm b/guix/import/elpa.scm
index 320a09e8c..5f8b7a9e5 100644
--- a/guix/import/elpa.scm
+++ b/guix/import/elpa.scm
@@ -89,7 +89,13 @@ NAMES (strings)."
   "Fetch URL, store the content in a temporary file and call PROC with that
 file.  Returns the value returned by PROC.  On error call ERROR-THUNK and
 return its value or leave if it's false."
-  (proc (http-fetch/cached (string->uri url
+  (catch #t
+(lambda ()
+  (proc (http-fetch/cached (string->uri url
+(lambda (key . args)
+  (if error-thunk
+  (error-thunk)
+  (apply throw key args)
 
 (define (is-elpa-package? name elpa-pkg-spec)
   "Return true if the string NAME corresponds to the name of the package
-- 
2.11.0

From 88f23b9c369841837a83225b52e19f4c029906ab Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Wed, 14 Dec 2016 12:34:15 +1100
Subject: [PATCH 2/2] import: elpa: Import dependencies as propagated-inputs

* guix/import/elpa.scm (elpa-package->sexp): Import dependencies as
propagated-inputs.
---
 guix/import/elpa.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/import/elpa.scm b/guix/import/elpa.scm
index 5f8b7a9e5..897ce6a69 100644
--- a/guix/import/elpa.scm
+++ b/guix/import/elpa.scm
@@ -228,7 +228,7 @@ type ''."
 (bytevector->nix-base32-string (file-sha256 tarball))
 "failed to download package")
(build-system emacs-build-system)
-   ,@(maybe-inputs 'inputs dependencies)
+   ,@(maybe-inputs 'propagated-inputs dependencies)
(home-page ,(elpa-package-home-page pkg))
(synopsis ,(elpa-package-synopsis pkg))
(description ,(elpa-package-description pkg))
-- 
2.11.0



signature.asc
Description: PGP signature

Re: Unable to configure a system with 'cuirass-service'

[Carlo Zancanaro]

On Thu, Dec 01 2016, ng0 wrote 
I tried that before (though I did just think it was wrong) and 
now I get the same message as yesterday:


...

In gnu/services/cuirass.scm: 
  81: 1 [cuirass-shepherd-service #] 
In unknown file: 
   ?: 0 [string=? "" ((# # # # ...))]


ERROR: In procedure string=?: ERROR: In procedure string=: Wrong 
type argument in position 2 (expecting string): (((#:name . 
"guix") (#:url . "git://git.savannah.gnu.org/guix.git") 
(#:load-path . ".") (#:file . 
"/.../cuirass/tests/gnu-system.scm") (#:proc . hydra-jobs) 
(#:arguments (subset . "hello")) (#:branch . "master")))


It looks like cuirass is expecting the specifications to be a 
string, not a list. I don't know anything about cuirass, so I 
can't help you to configure the cuirass-service.


Looking at the source, specifications has a comment ";string
(file-name)". It looks like the "specifications" field of the
configuration is just equivalent to the --specifications argument to the
cuirass command, if that helps at all.


signature.asc
Description: PGP signature

Re: Unable to configure a system with 'cuirass-service'

[Carlo Zancanaro]

On Thu, Dec 01 2016, ng0 wrote

https://ptpb.pw/gQOZ.scm with this change it fails differently:


This is wrong again, but for a different reason. The 
`%desktop-services` must be the last argument to the `cons*` call.


You want it to look like this (assuming my formatting comes out at 
least a little bit okay):


 (services (cons* (gnome-desktop-service)
  (tor-service)
  (console-keymap-service "de")
   (lsh-service)
   (let ((spec-guix `((#:name . "guix")
  (#:url . 
"git://git.savannah.gnu.org/guix.git")
  (#:load-path . ".")
  ;; Adapt to a valid absolute file name.
  (#:file . 
"/.../cuirass/tests/gnu-system.scm")
  (#:proc . hydra-jobs)
  (#:arguments (subset . "hello"))
  (#:branch . "master"

 (cuirass-service #:config (cuirass-configuration
(specifications (list 
spec-guix)
   %desktop-services))


signature.asc
Description: PGP signature

Re: Unable to configure a system with 'cuirass-service'

[Carlo Zancanaro]

On Wed, Nov 30 2016, ng0 wrote

Is there anything obvious I have to change?


Your `let` body contains both the `(cuirass-service ...)` form as 
well as the `%desktop-services` form. A `let` form will take the 
value of the last form in its body, so the `(cuirass-service ...)` 
value is being thrown away.


Try removing one of the closing parentheses after `%desktop-services`
and add it after the `(cuirass-service ...)` form. (This has the effect
of moving `%desktop-services` out of the `let` body.)


signature.asc
Description: PGP signature

Re: Shepherd does not recycle zombie processes

[Carlo Zancanaro]

On Wed, Nov 09 2016, Ludovic Courtès wrote
Could you run shepherd in “strace -f” and see where the SIGCHLD 
signals go?


I don't really know how to read strace's output (and there's a lot 
of it), but sometimes it gives a line like this:


--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, 
si_pid=10496, si_status=SIGTERM, si_utime=142, si_stime=22} 
---


and sometimes it gives a line like this:

   [pid 10465] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, 
   si_pid=10556, si_status=SIGTERM, si_utime=84, si_stime=16} ---


If it has the [pid x] prefix then the signal is handled 
properly and the child process is reaped. If there's no prefix 
then a zombie process is left behind. (The pid in the prefix is 
the pid of the forked daemon process.)


Using my example init.scm file I have found that if I run `herd 
restart sleep` repeatedly and quickly (< 1 second) then it will 
consistently reap the processes. If I delay for more than about a 
second between runs then it will fail to reap the old process. 
(With strace attached this time is extended to a few seconds.)


Carlo


signature.asc
Description: PGP signature

Re: Shepherd does not recycle zombie processes

[Carlo Zancanaro]

Hey Ludo!

On Mon, Nov 07 2016, Ludovic Courtès wrote
Could it be that you invoke the ‘daemonize’ action after 
respawnable processes have been started?  The manual has this 
caveat (info "(shepherd) The root and unknown services"):


  ‘daemonize’ 
   Fork and go into the background.  This should be called 
   before respawnable services are started, as otherwise we 
   would not get the ‘SIGCHLD’ signals when they terminate.


Yeah, I saw that note in the documentation. I used to have

   (action 'shepherd 'daemonize)

as the first line in ~/.config/shepherd/init.scm. Is there some 
other way that I was supposed to do that?


With that line in place, Shepherd will leave behind a process 
every time I stop/start a service.


I have attached an example init.scm that does this for me. If I 
start: 


   shepherd -c init.scm

and then run:

   herd stop sleep
   herd start sleep
   herd stop sleep
   herd start sleep
   herd stop sleep

then I will have three zombie sleep processes underneath my 
Shepherd process. (If the service were respawnable then it also 
would fail to restart the service.)


I assume this behaviour is wrong, but if I'm doing something wrong 
then please let me know what it is.


Carlo



init.scm
Description: Binary data


signature.asc
Description: PGP signature

Re: Shepherd does not recycle zombie processes

[Carlo Zancanaro]

I've had problems with Shepherd and its daemonize action. If I run
daemonize (as the first thing when Shepherd starts) then it fails to handle
signals from child processes.

I've only been running without the daemonize call for a day or so, but it
seems to properly handle the child processes now.

On 06/11/2016 9:52 am, "Dale Mellor"  wrote:

I'm running shepherd stand-alone in a Debian system.  But I am seeing
zombie processes which have been kicked off by shepherd, and they do not
get re-spawned.

Any suggestions?

Re: [PATCH] gnu: Add awesome.

[Carlo Zancanaro]

On 16 June 2016 at 22:38, Ludovic Courtès  wrote:

> Primarily, I built it with --rounds=2 as per
> <
> https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>
> ...
>

I tried to build with --rounds=2, but always after I had built normally
(because I cared first about whether it compiled, then later about whether
it was deterministic). The --rounds=2 build never seemed to do anything. Is
there something I have to do to make that work? (I tried adding the --check
flag too, but it also seemed to not do anything, either with or without
--rounds.)

[PATCH] gnu: Add awesome.

[Carlo Zancanaro]

* gnu/packages/wm.scm (awesome): New variable.
---
 gnu/packages/wm.scm | 79 +
 1 file changed, 79 insertions(+)

diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index 5f32fc4..7ee517c 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016 Danny Milosavljevic 
 ;;; Copyright © 2016 Efraim Flashner 
 ;;; Copyright © 2016 Al McElrath 
+;;; Copyright © 2016 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -28,6 +29,7 @@
   #:use-module (guix packages)
   #:use-module (gnu packages)
   #:use-module (gnu packages linux)
+  #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system haskell)
   #:use-module (gnu packages haskell)
@@ -49,6 +51,11 @@
   #:use-module (gnu packages maths)
   #:use-module (gnu packages web)
   #:use-module (gnu packages fontutils)
+  #:use-module (gnu packages freedesktop)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gperf)
+  #:use-module (gnu packages imagemagick)
+  #:use-module (gnu packages lua)
   #:use-module (guix download)
   #:use-module (guix git-download))
 
@@ -370,3 +377,75 @@ and easy to handle yet full of features to make an easy 
and fast desktop
 experience.")
 (home-page "http://fluxbox.org/";)
 (license license:expat)))
+
+(define-public awesome
+  (package
+(name "awesome")
+(version "3.4.15")
+(source
+ (origin (method url-fetch)
+ (uri (string-append 
"https://awesome.naquadah.org/download/awesome-";
+ version ".tar.xz"))
+ (sha256
+  (base32
+   "1m910lr7wkw2dgzmirfvz7dasfswhhccdf65l21iiciv24c3w1bb"
+(build-system cmake-build-system)
+(native-inputs `(("asciidoc" ,asciidoc)
+ ("docbook-xsl" ,docbook-xsl)
+ ("doxygen" ,doxygen)
+ ("gperf" ,gperf)
+ ("imagemagick" ,imagemagick)
+ ("libxml2" ,libxml2) ; for XML_CATALOG_FILES
+ ("pkg-config" ,pkg-config)
+ ("xmlto" ,xmlto)))
+(inputs `(("cairo" ,cairo)
+  ("dbus" ,dbus)
+  ("gdk-pixbuf" ,gdk-pixbuf)
+  ("glib" ,glib)
+  ("imlib2" ,imlib2)
+  ("libev" ,libev)
+  ("libxcb" ,libxcb)
+  ("libxcursor" ,libxcursor)
+  ("libxdg-basedir" ,libxdg-basedir)
+  ("lua" ,lua-5.1)
+  ("pango" ,pango)
+  ("startup-notification" ,startup-notification)
+  ("xcb-util" ,xcb-util)
+  ("xcb-util-cursor" ,xcb-util-cursor)
+  ("xcb-util-image" ,xcb-util-image)
+  ("xcb-util-keysyms" ,xcb-util-keysyms)
+  ("xcb-util-renderutil" ,xcb-util-renderutil)
+  ("xcb-util-wm" ,xcb-util-wm)))
+(arguments `(#:phases (modify-phases %standard-phases
+(add-before 'build 'xmlto-skip-validation
+  (lambda _
+;; we can't download the necessary schema, so
+;; so skip validation and assume they're valid
+(substitute* 
"../build/CMakeFiles/man.dir/build.make"
+  (("/xmlto") (string-append "/xmlto 
--skip-validation")))
+#t))
+(replace 'check
+  (lambda _
+;; there aren't any tests, so just make sure 
the
+;; binary gets built and can be run 
successfully
+(zero? (system* "../build/awesome" "-v")))
+(synopsis "Highly configurable, next generation framework window manager
+for X")
+(description
+ "awesome is a window manager for X.  It manages windows in different
+layouts, like floating or tiled.  Any layout can be applied dynamically,
+optimizing the environment for the application in use and the task currently
+being performed.
+
+In a tiled layout, windows are managed in a master and stacking area.  The
+master area contains the windows which currently need the most attention,
+whereas the stacking area contains all other windows.  In a floating layout
+windows can be resized and moved freely.  Dialog windows are always managed as
+floating, regardless of the layout currently applied.  The spiral and dwindle
+layouts are special cases of the tiled layout where the stacking area is
+arranged in a spiral for the former or as a rectangular fractal for the later.
+
+Windows are grouped by tags in awesome.  Each window can be tagged with one or
+more tags.  Selecting certain tags displays all windows with these tags.")
+(license license:gpl2+)
+(home-page "https://awesome.naquadah.org/";)))
-- 
2.7.3

Re: [PATCH] gnu: Add awesome.

[Carlo Zancanaro]

On 14 June 2016 at 01:46, Leo Famulari  wrote:

> I think that imagemagick is only required while building, so it can be a
> 'native-input'.
>
> You can check what packages the built output refers to: $ guix gc
> --references $(./pre-inst-env guix build awesome)
>
> Imagemagick is not in the list.
>

Thanks for this! I had assumed that the "guix lint" would tell me about
something like that, given the check "inputs-should-be-native".

Is it possible for those references to be "wrong"? For there to be
something which is required at runtime, but doesn't show up in a "guix gc
--references" check?


> I noticed that several of the files have the "or later" text. If they
> are all like that, we could use gpl2+. Did you check if there are any
> files with licenses besides GPL2+?
>

The lua files (in lib/) don't have a license heading beyond a copyright
year/author in the luadoc tags. Everything which has a license heading
seems to be gpl2+ (I had missed the "or later" text, but I've updated it
now).

Re: [PATCH] gnu: Add awesome.

[Carlo Zancanaro]

Hi!

On 13 June 2016 at 17:53, Danny Milosavljevic 
wrote:

> I think it would be better if it went into wm.scm .
>

Ah, okay! I looked at ratpoison.scm, because it was the first window
manager that I thought of to look up. It was in its own file, so I followed
that example. I agree awesome fits better into wm.scm.

> +(arguments `(#:phases (modify-phases %standard-phases
> > +(replace 'check
> > +  (lambda* _
> > +(zero? (system* "../build/awesome"
> "-v")))
>
> What's up with the tests? Why disable them like this?
>

There actually aren't any tests, so if I leave the "check" phase to do the
default "make test", it fails. This way it at least checks that the awesome
binary was compiled and can be run. I'll put a comment in explaining that.

Re: [PATCH] gnu: Add awesome.

[Carlo Zancanaro]

Hi!

On 13 June 2016 at 18:05, ng0  wrote:

> Is 3.4.15 the latest? I use 3.5.9 here, and this was what I targeted
> with my work in progress.
>

No, 3.4.15 isn't the latest. 3.5.9 is the latest stable, but I couldn't get
it to compile (at the very least lua-lgi is missing, I don't know if other
things are too). I figured it was better to have something rather than
nothing. I don't need more than 3.4.15, but not having awesome at all
stopped me from using GuixSD for a while.


> it requires also lua-lgi, at least with 3.5.9 version. I can give you the
> wip
> of that if it only got in with 3.5.x and you need it.
>

Apparently lua-lgi only became a dependency for the 3.5.x releases. If you
have a working package definition for it then I'm willing to try to get it
working with awesome. (I don't know anything about packaging lua libraries,
so I gave up on lua-lgi when it didn't work immediately.)


> Building the documentation also requires doxygen and graphviz in case you
> want
> to add a second output for them - I never made it that far and can't tell
> if the
> docs are very big.
>

I'll give this a go.

Re: [PATCH] gnu: Add awesome.

[Carlo Zancanaro]

After looking a bit more at patches where new files are added, I now
realise this is incomplete. I'll send through a new patch in a few minutes.

On 13 June 2016 at 10:12, Carlo Zancanaro  wrote:

> * gnu/packages/awesome.scm (awesome): New variable.
> ---
>  gnu/packages/awesome.scm | 93
> 
>  1 file changed, 93 insertions(+)
>  create mode 100644 gnu/packages/awesome.scm
>
> diff --git a/gnu/packages/awesome.scm b/gnu/packages/awesome.scm
> new file mode 100644
> index 000..6aa1f93
> --- /dev/null
> +++ b/gnu/packages/awesome.scm
> @@ -0,0 +1,93 @@
> +;;; GNU Guix --- Functional package management for GNU
> +;;; Copyright © 2016 Carlo Zancanaro 
> +;;;
> +;;; 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 <http://www.gnu.org/licenses/>.
> +
> +(define-module (gnu packages awesome)
> +  #:use-module ((guix licenses) #:prefix license:)
> +  #:use-module (guix packages)
> +  #:use-module (guix download)
> +  #:use-module (guix build-system cmake)
> +  #:use-module (guix build-system glib-or-gtk)
> +  #:use-module (gnu packages freedesktop)
> +  #:use-module (gnu packages glib)
> +  #:use-module (gnu packages gperf)
> +  #:use-module (gnu packages gtk)
> +  #:use-module (gnu packages image)
> +  #:use-module (gnu packages imagemagick)
> +  #:use-module (gnu packages libevent)
> +  #:use-module (gnu packages lua)
> +  #:use-module (gnu packages pkg-config)
> +  #:use-module (gnu packages xdisorg)
> +  #:use-module (gnu packages xorg))
> +
> +(define-public awesome
> +  (package
> +(name "awesome")
> +(version "3.4.15")
> +(source
> + (origin (method url-fetch)
> + (uri (string-append "
> https://awesome.naquadah.org/download/awesome-";
> + version ".tar.xz"))
> + (sha256
> +  (base32
> +   "1m910lr7wkw2dgzmirfvz7dasfswhhccdf65l21iiciv24c3w1bb"
> +(build-system cmake-build-system)
> +(native-inputs `(("pkg-config" ,pkg-config)))
> +(inputs `(("cairo" ,cairo)
> +  ("dbus" ,dbus)
> +  ("gdk-pixbuf" ,gdk-pixbuf)
> +  ("glib" ,glib)
> +  ("gperf" ,gperf)
> +  ("imlib2" ,imlib2)
> +  ("libev" ,libev)
> +  ("libxcb" ,libxcb)
> +  ("libxcursor" ,libxcursor)
> +  ("libxdg-basedir" ,libxdg-basedir)
> +  ("lua" ,lua-5.1)
> +  ("pango" ,pango)
> +  ("startup-notification" ,startup-notification)
> +  ("xcb-util" ,xcb-util)
> +  ("xcb-util-cursor" ,xcb-util-cursor)
> +  ("xcb-util-image" ,xcb-util-image)
> +  ("xcb-util-keysyms" ,xcb-util-keysyms)
> +  ("xcb-util-renderutil" ,xcb-util-renderutil)
> +  ("xcb-util-wm" ,xcb-util-wm)
> +  ("imagemagick" ,imagemagick)))
> +(arguments `(#:phases (modify-phases %standard-phases
> +(replace 'check
> +  (lambda* _
> +(zero? (system* "../build/awesome"
> "-v")))
> +(synopsis "Highly configurable, next generation framework window
> manager
> +for X")
> +(description
> + "awesome is a window manager for X.  It manages windows in different
> +layouts, like floating or tiled.  Any layout can be applied dynamically,
> +optimizing the environment for the application in use and the task
> currently
> +being performed.
> +
> +In a tiled layout, windows are managed in a master and stacking area.  The
> +master area contains the windows which currently need the most attention,
> +whereas the stacking area contains all other windows.  In a floating
> layout
> +windows can be resized and moved freely.  Dialog windows are always
> managed as
> +floating, regardless of the layout currently applied.  The spiral and
> dwindle
> +layouts are special cases of the tiled layout where the stacking area is
> +arranged in a spiral for the former or as a rectangular fractal for the
> later.
> +
> +Windows are grouped by tags in awesome.  Each window can be tagged with
> one or
> +more tags.  Selecting certain tags displays all windows with these tags.")
> +(license license:gpl2)
> +(home-page "https://awesome.naquadah.org/";)))
> --
> 2.7.3
>
>

[PATCH] gnu: Add awesome.

[Carlo Zancanaro]

* gnu/packages/awesome.scm (awesome): New variable.
---
 gnu/packages/awesome.scm | 93 
 1 file changed, 93 insertions(+)
 create mode 100644 gnu/packages/awesome.scm

diff --git a/gnu/packages/awesome.scm b/gnu/packages/awesome.scm
new file mode 100644
index 000..6aa1f93
--- /dev/null
+++ b/gnu/packages/awesome.scm
@@ -0,0 +1,93 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Carlo Zancanaro 
+;;;
+;;; 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 <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages awesome)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system cmake)
+  #:use-module (guix build-system glib-or-gtk)
+  #:use-module (gnu packages freedesktop)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gperf)
+  #:use-module (gnu packages gtk)
+  #:use-module (gnu packages image)
+  #:use-module (gnu packages imagemagick)
+  #:use-module (gnu packages libevent)
+  #:use-module (gnu packages lua)
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages xdisorg)
+  #:use-module (gnu packages xorg))
+
+(define-public awesome
+  (package
+(name "awesome")
+(version "3.4.15")
+(source
+ (origin (method url-fetch)
+ (uri (string-append 
"https://awesome.naquadah.org/download/awesome-";
+ version ".tar.xz"))
+ (sha256
+  (base32
+   "1m910lr7wkw2dgzmirfvz7dasfswhhccdf65l21iiciv24c3w1bb"
+(build-system cmake-build-system)
+(native-inputs `(("pkg-config" ,pkg-config)))
+(inputs `(("cairo" ,cairo)
+  ("dbus" ,dbus)
+  ("gdk-pixbuf" ,gdk-pixbuf)
+  ("glib" ,glib)
+  ("gperf" ,gperf)
+  ("imlib2" ,imlib2)
+  ("libev" ,libev)
+  ("libxcb" ,libxcb)
+  ("libxcursor" ,libxcursor)
+  ("libxdg-basedir" ,libxdg-basedir)
+  ("lua" ,lua-5.1)
+  ("pango" ,pango)
+  ("startup-notification" ,startup-notification)
+  ("xcb-util" ,xcb-util)
+  ("xcb-util-cursor" ,xcb-util-cursor)
+  ("xcb-util-image" ,xcb-util-image)
+  ("xcb-util-keysyms" ,xcb-util-keysyms)
+  ("xcb-util-renderutil" ,xcb-util-renderutil)
+  ("xcb-util-wm" ,xcb-util-wm)
+  ("imagemagick" ,imagemagick)))
+(arguments `(#:phases (modify-phases %standard-phases
+(replace 'check
+  (lambda* _
+(zero? (system* "../build/awesome" "-v")))
+(synopsis "Highly configurable, next generation framework window manager
+for X")
+(description
+ "awesome is a window manager for X.  It manages windows in different
+layouts, like floating or tiled.  Any layout can be applied dynamically,
+optimizing the environment for the application in use and the task currently
+being performed.
+
+In a tiled layout, windows are managed in a master and stacking area.  The
+master area contains the windows which currently need the most attention,
+whereas the stacking area contains all other windows.  In a floating layout
+windows can be resized and moved freely.  Dialog windows are always managed as
+floating, regardless of the layout currently applied.  The spiral and dwindle
+layouts are special cases of the tiled layout where the stacking area is
+arranged in a spiral for the former or as a rectangular fractal for the later.
+
+Windows are grouped by tags in awesome.  Each window can be tagged with one or
+more tags.  Selecting certain tags displays all windows with these tags.")
+(license license:gpl2)
+(home-page "https://awesome.naquadah.org/";)))
-- 
2.7.3

[PATCH] gnu: Add awesome.

[Carlo Zancanaro]

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

diff --git a/gnu/local.mk b/gnu/local.mk
index 73aef0a..0d6e1c4 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -49,6 +49,7 @@ GNU_SYSTEM_MODULES =  \
   %D%/packages/autotools.scm   \
   %D%/packages/avahi.scm   \
   %D%/packages/avr.scm \
+  %D%/packages/awesome.scm \
   %D%/packages/backup.scm  \
   %D%/packages/base.scm\
   %D%/packages/bash.scm\
diff --git a/gnu/packages/awesome.scm b/gnu/packages/awesome.scm
new file mode 100644
index 000..6aa1f93
--- /dev/null
+++ b/gnu/packages/awesome.scm
@@ -0,0 +1,93 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Carlo Zancanaro 
+;;;
+;;; 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 <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages awesome)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system cmake)
+  #:use-module (guix build-system glib-or-gtk)
+  #:use-module (gnu packages freedesktop)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gperf)
+  #:use-module (gnu packages gtk)
+  #:use-module (gnu packages image)
+  #:use-module (gnu packages imagemagick)
+  #:use-module (gnu packages libevent)
+  #:use-module (gnu packages lua)
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages xdisorg)
+  #:use-module (gnu packages xorg))
+
+(define-public awesome
+  (package
+(name "awesome")
+(version "3.4.15")
+(source
+ (origin (method url-fetch)
+ (uri (string-append 
"https://awesome.naquadah.org/download/awesome-";
+ version ".tar.xz"))
+ (sha256
+  (base32
+   "1m910lr7wkw2dgzmirfvz7dasfswhhccdf65l21iiciv24c3w1bb"
+(build-system cmake-build-system)
+(native-inputs `(("pkg-config" ,pkg-config)))
+(inputs `(("cairo" ,cairo)
+  ("dbus" ,dbus)
+  ("gdk-pixbuf" ,gdk-pixbuf)
+  ("glib" ,glib)
+  ("gperf" ,gperf)
+  ("imlib2" ,imlib2)
+  ("libev" ,libev)
+  ("libxcb" ,libxcb)
+  ("libxcursor" ,libxcursor)
+  ("libxdg-basedir" ,libxdg-basedir)
+  ("lua" ,lua-5.1)
+  ("pango" ,pango)
+  ("startup-notification" ,startup-notification)
+  ("xcb-util" ,xcb-util)
+  ("xcb-util-cursor" ,xcb-util-cursor)
+  ("xcb-util-image" ,xcb-util-image)
+  ("xcb-util-keysyms" ,xcb-util-keysyms)
+  ("xcb-util-renderutil" ,xcb-util-renderutil)
+  ("xcb-util-wm" ,xcb-util-wm)
+  ("imagemagick" ,imagemagick)))
+(arguments `(#:phases (modify-phases %standard-phases
+(replace 'check
+  (lambda* _
+(zero? (system* "../build/awesome" "-v")))
+(synopsis "Highly configurable, next generation framework window manager
+for X")
+(description
+ "awesome is a window manager for X.  It manages windows in different
+layouts, like floating or tiled.  Any layout can be applied dynamically,
+optimizing the environment for the application in use and the task currently
+being performed.
+
+In a tiled layout, windows are managed in a master and stacking area.  The
+master area contains the windows which currently need the most attention,
+whereas the stacking area contains all other windows.  In a floating layout
+windows can be resized and moved freely.  Dialog windows are always managed as
+floating, regardless of the la