Re: ESC/P-R package

[Diego Nicola Barbato]

Hello Guix,

I have sent the following patch to the guix-patches mailing list
(29...@debbugs.gnu.org):

>From 5d6449cc3cfc4154fff24abcdd54c05b44b9e471 Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato 
Date: Wed, 1 Nov 2017 02:48:14 +0100
Subject: gnu: Add Epson escpr printer driver.

* gnu/packages/cups.scm (escpr): New variable.
---
 gnu/packages/cups.scm | 32 
 1 file changed, 32 insertions(+)

diff --git a/gnu/packages/cups.scm b/gnu/packages/cups.scm
index 491668e52..54a93fe49 100644
--- a/gnu/packages/cups.scm
+++ b/gnu/packages/cups.scm
@@ -599,3 +599,35 @@ printer/driver specific, but spooler-independent PPD file.")
 protocols, which cover printers made by Konica, HP (LaserJet), Oki, Samsung,
 and more.  See @file{README} for details.")
 (license license:gpl2+)))
+
+(define-public escpr
+  (package
+(name "escpr")
+(version "1.6.17")
+;; This currently works.  But it will break as soon as a newer
+;; version is available since the URLs for older versions are not
+;; preserved.  An alternative source will be added as soon as
+;; available.
+(source (origin
+  (method url-fetch)
+  ;; The uri has to be chopped up in order to satisfy guix lint.
+  (uri (string-append "https://download3.ebz.epson.net/dsc/f/03/00/06/66/09/";
+  "4ac2bf69bb1ddf4a9ad525596615cbb40fe4dad5/"
+  "epson-inkjet-printer-escpr-1.6.17-1lsb3.2.tar.gz"))
+  (sha256
+   (base32
+"0m6v1wdavw4r25jfywqchsx0v9ss1l5fr8vq9d0d8cmjnz8mqblv"
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+   `(,(string-append "--prefix="
+ (assoc-ref %outputs "out"))
+ ,(string-append "--with-cupsfilterdir="
+ (assoc-ref %outputs "out") "/lib/cups/filter")
+ ,(string-append "--with-cupsppddir="
+ (assoc-ref %outputs "out") "/share/ppd"
+(inputs `(("cups" ,cups-minimal)))
+(synopsis "ESC/P-R printer driver")
+(description "ESC/P-R driver and PPDs supporting a multitude of Epson printers.")
+(home-page "http://download.ebz.epson.net/dsc/search/01/search";)
+(license license:gpl2+)))
-- 
2.14.3


It appears to build reproducibly (at least on my system).  And I have
checked it with `guix lint'.  It passes all tests except `guix lint -c
source' which does not report an error but strangely crashes with the
following output:

~$ guix lint -c source escpr
Backtrace:scpr@1.6.17 [source]...
  13 (primitive-load "/gnu/store/19wpps1nmlg4j1530knl7kdhvgc…")
In guix/ui.scm:
  1384:12 12 (run-guix-command _ . _)
In srfi/srfi-1.scm:
640:9 11 (for-each # …)
In guix/scripts/lint.scm:
   1062:4 10 (run-checkers # …)
In srfi/srfi-1.scm:
640:9  9 (for-each # …)
In guix/scripts/lint.scm:
673:4  8 (check-source #)
In guix/monads.scm:
553:0  7 (_ _)
In guix/scripts/lint.scm:
   109:38  6 (_ ())
543:7  5 (validate-uri _ # …)
96:17  4 (emit-warning # …)
In ice-9/boot-9.scm:
837:9  3 (catch system # …)
In guix/packages.scm:
   355:11  2 (_)
In ice-9/ports.scm:
   439:11  1 (call-with-input-file #f # …)
In unknown file:
   0 (open-file #f "r" #:encoding #f #:guess-encoding #f)

ERROR: In procedure open-file:
ERROR: Wrong type (expecting string): #f

I have not yet found an alternative source.  But the current one works
(except for the `guix lint' error).  I will try to send a patch as soon
as the URI changes or the source is made available on this Debian
repository:
http://http.debian.net/debian/pool/main/e/epson-inkjet-printer-escpr/

Greetings

Diego

Re: Creating Docker containers in Scheme

[Ludovic Courtès]

Hi,

Roel Janssen  skribis:

> I'd like to create a Docker container from Scheme.  Looking at
> guix/scripts/pack.scm, I believe something like this should be possible:
>
>   (docker-image "my-container"
> (profile-derivation
>   (packages->manifest (list hello coreutils

Move precisely:

  (mlet %store-monad ((profile (profile-derivation …)))
(docker-image "my-container" profile))

> Is this something we could add to the the public interface of a module?

Sure.  For now the easiest solution would be to export ‘docker-image’
from (guix scripts pack).

Longer-term, we could rename (guix docker) to (guix build docker) and
move ‘docker-image’ to a new (guix docker) module, but perhaps we’d also
need a (guix pack) modules containing tools that are shared between the
docker and tarball backends of ‘guix pack’.

WDYT?

Ludo’.

Re: More native-search-paths for gtk and

[Ludovic Courtès]

Hello,

Hartmut Goebel  skribis:

> while checking the Nix patches for qtbase, I discovered that they have a
> patch to extend XDG_DATA_DIRS and GIO_EXTRA_MODULES.
>
> They basically do this:
>
>   XDG_DATA_DIRS=$XDG_DATA_DIRS:{gtk3}/share/gsettings-schemas/${gtk3.name}
>
>   GIO_EXTRA_MODULES=$GIO_EXTRA_MODULES:${dconf.lib}/lib/gio/modules
>
> What do you think about adding native-search-path entries for these
> directories?

We have those in the glib package.  Or did you mean adding them to
‘qtbase’?  We’d need to apply the same patch as Nixpkgs so that these
variables are honored by Qt, right?

Ludo’.

Re: Let’s meet before FOSDEM!

[Ludovic Courtès]

Pjotr Prins  skribis:

> With regard to talks we should limit the total time for that - say 2-3
> hours total. And have the rest of the day free flowing discussion and
> hacking. Talks are useful, but I think the real impact will be to be
> together and sit down and inspire each other and flesh out next year's
> projects and priorities.

Agreed!

Ludo'.

Re: Packaging Jitsi SIP Communicator

[Ludovic Courtès]

Hi Ben,

Ben Sturmfels  skribis:

> starting phase `reset-gzip-timestamps'
> find-files: /gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10: No such 
> file or directory
> phase `reset-gzip-timestamps' succeeded after 0.0 seconds
> starting phase `compress-documentation'
> phase `compress-documentation' succeeded after 0.0 seconds
> builder for `/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv' 
> failed to produce output path 
> `/gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10'
> @ build-failed /gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv - 1 
> builder for `/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv' 
> failed to produce output path 
> `/gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10'

It means that /gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10 was
not created at all.

HTH!

Ludo’.

Re: Packaging Jitsi SIP Communicator

[Thomas Danckaert]

From: Ben Sturmfels 
Subject: Packaging Jitsi SIP Communicator
Date: Wed, 08 Nov 2017 15:01:32 +1100



Date: Wed, 08 Nov 2017 15:01:32 +1100
Message: 2
X-Mew: <3.3 body> Good PGP sign "Christopher Baines 
" [unknown] UNDEFINED


Hi Folks,

I'm having some trouble packaging Jitsi (a VoIP client written in 
Java).
The attached patch adds the package "jitsi", which completes the 
"build"
phase, but fails as below. Ignoring for now that Jitsi is bundling 
a whole lot

of dependencies, can someone help me understand what’s going on:

[...]

find-files: /gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10: 
No such file or directory


[...]

builder for 
`/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv' failed 
to produce output path 
`/gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10'
@ build-failed 
/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv - 1 
builder for 
`/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv' failed 
to produce output path `


Hi,

These messages indicate that the build procedure did not create the 
output directory, i.e. nothing was installed.  So you should have a 
look at the build procedure, and make sure there is an install phase 
that creates and populates the output directory (available as 
(assoc-ref %outputs "out")) with the items that were built.


Thomas

Re: Creating Docker containers in Scheme

[Roel Janssen]

Ludovic Courtès writes:

> Hi,
>
> Roel Janssen  skribis:
>
>> I'd like to create a Docker container from Scheme.  Looking at
>> guix/scripts/pack.scm, I believe something like this should be possible:
>>
>>   (docker-image "my-container"
>> (profile-derivation
>>   (packages->manifest (list hello coreutils
>
> Move precisely:
>
>   (mlet %store-monad ((profile (profile-derivation …)))
> (docker-image "my-container" profile))
>

Oh, of course! :)

Unfortunately, I cannot seem to get it to work.
Here's what I do (mind the GWL process- stuff):

--8<---cut here---start->8---
(define* (process->docker-derivation proc #:key (guile (default-guile)))
  "Return a Docker container that can run the PROCEDURE described in PROC, with
PROCEDURE's imported modules in its search path."
  (let ((name (process-full-name proc))
(exp (process-procedure proc))
(out (process-output-path proc))
(packages (process-package-inputs proc)))
(let ((out-str (if out (format #f "(setenv \"out\" ~s)" out) "")))
  (mlet %store-monad ((set-load-path
   (load-path-expression (gexp-modules exp)))
  (container (docker-image
  (string-append (process-full-name proc)
  "-docker")
  (profile-derivation
   (packages->manifest packages)
(gexp->derivation
 name
 (gexp
  (call-with-output-file (ungexp output)
(lambda (port)
  (format port "# Docker image: ~a~%" (ungexp container)
 #:graft? #f)
--8<---cut here---end--->8---

And the error I get is:
  wrong-type-arg: string-prefix?

Is there anything obviously wrong here?

>> Is this something we could add to the the public interface of a module?
>
> Sure.  For now the easiest solution would be to export ‘docker-image’
> from (guix scripts pack).
>
> Longer-term, we could rename (guix docker) to (guix build docker) and
> move ‘docker-image’ to a new (guix docker) module, but perhaps we’d also
> need a (guix pack) modules containing tools that are shared between the
> docker and tarball backends of ‘guix pack’.
>
> WDYT?

It'd be nice to keep the (guix scripts ...) small, and only do
command-line handling.  So I think a (guix build docker), and a (guix
pack) module would be good.

>
> Ludo’.

Thanks for your time!

Kind regards,
Roel Janssen

Re: Packaging Jitsi SIP Communicator

[julien lepiller]

Le 2017-11-08 05:01, Ben Sturmfels a écrit :

Hi Folks,

I'm having some trouble packaging Jitsi (a VoIP client written in 
Java).
The attached patch adds the package "jitsi", which completes the 
"build"
phase, but fails as below. Ignoring for now that Jitsi is bundling a 
whole lot

of dependencies, can someone help me understand what’s going on:

phase `build' succeeded after 45.3 seconds
starting phase `check'
test suite not run
phase `check' succeeded after 0.0 seconds
starting phase `strip-jar-timestamps'
find-files: /gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10: No
such file or directory
phase `strip-jar-timestamps' succeeded after 0.0 seconds
starting phase `patch-shebangs'
phase `patch-shebangs' succeeded after 0.0 seconds
starting phase `strip'
phase `strip' succeeded after 0.0 seconds
starting phase `validate-runpath'
phase `validate-runpath' succeeded after 0.0 seconds
starting phase `validate-documentation-location'
phase `validate-documentation-location' succeeded after 0.0 seconds
starting phase `delete-info-dir-file'
phase `delete-info-dir-file' succeeded after 0.0 seconds
starting phase `patch-dot-desktop-files'
phase `patch-dot-desktop-files' succeeded after 0.0 seconds
starting phase `reset-gzip-timestamps'
find-files: /gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10: No
such file or directory
phase `reset-gzip-timestamps' succeeded after 0.0 seconds
starting phase `compress-documentation'
phase `compress-documentation' succeeded after 0.0 seconds
builder for
`/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv' failed to
produce output path
`/gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10'
@ build-failed
/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv - 1 builder
for `/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv'
failed to produce output path
`/gnu/store/kz7kwgm25xk83fc69immm80dazv9gb6x-jitsi-2.10'
note: keeping build directory `/tmp/guix-build-jitsi-2.10.drv-0'
guix build: error: build failed: build of
`/gnu/store/hxpb6xvx324d9i9kxc7ywfwwaz3zgs4z-jitsi-2.10.drv' failed


Regards,
Ben


Well of course if you "(delete 'install)", you won't install anything :p

You should rather modify that phase to install manually (using 
install-file)

the compiled jar, or find the correct target in build.xml.

Also, this package bundles a lot of pre-compiled jars. You should remove
them (for-each delete-files (find-files "." ".*.jar")) and add them as
inputs (we already have all of them, except felix.jar, but I think I
have a package for that: I will send it this evening).

Then you will be able to make a wrapper script. You can get inspiration
from the java-antlr packages.

Finally, there is probably an issue with your #:main-class: a class
usually starts with an upper-case letter. According to your comment,
it should be net.java.sip.communicator.launcher.SIPCommunicator.



--
Ben Sturmfels

Sturm - Software Engineering
www.sturm.com.au
(03) 9024 2467

Re: Let’s meet before FOSDEM!

[Efraim Flashner]

On Tue, Nov 07, 2017 at 02:39:53PM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> Since we didn’t get a devroom this time in spite of the efforts of
> Manolis and Pjotr, what about holding a Guix meeting let’s say on Friday
> before FOSDEM (Feb. 2nd, in Brussels)?
> 
> We could meet for the whole day, in a place that remains to be defined,
> to discuss about all things Guix{,SD}.  The event could be a mixture of
> short talks on specific topics, discussions on technical and less
> technical topics (multiple bootloader support & GuixSD on ARM, making
> ‘guix pull’ great again, Cuirass, reaching out to more
> users/contributors, Guix & HPC, improving our infrastructure and
> organization, etc.), and possibly hacking sessions.
> 
> Who would be willing to join?  (You can reply privately if you prefer.)
> 
> Based on the show of hands, we’ll arrange for a venue of the appropriate
> size.
> 
> Thanks!
> 
> Ludo’.

I should be able to make it again this year. Assuming I'm taking the
same flight as last time I'll be in Brussels by about 5am. I'm not
suggesting that we start that early, but depending on what everyone else
is doing we could aim to have the talks/presentations when we have the
most number of people and then have time before and after for hacking.


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


signature.asc
Description: PGP signature

Re: Performance regression on NFS with new manifest version

[Roel Janssen]

Ludovic Courtès writes:

> Hello,
>
> Roel Janssen  skribis:
>
>> I couldn't install *all* R packages, but I used it on our shared R
>> profile:
>>
>> $ guixr package --list-installed -p /gnu/profiles/per-language/r
>> ncurses  6.0 out 
>> /gnu/store/djvxj8r1xwvrm89xqjrd44wwaxc02i74-ncurses-6.0
>> coreutils8.27out 
>> /gnu/store/ps92fz5p6l3mz9ddi388p1891r2q3fva-coreutils-8.27
>> grep 3.0 out /gnu/store/bxnxmg6vamnlp95skrgdqw7s86ag1f51-grep-3.0
>> sed  4.4 out /gnu/store/673v5pxadfdj1zkmpm90s6j89367w4af-sed-4.4
>> r-sparql 1.16out 
>> /gnu/store/5qhr4va0af65a0jrpj6nc7xdnw9s4345-r-sparql-1.16
>
> Unfortunately most of these packages are not in Guix proper AFAICS.
> Could you come up with a simple way for me to reproduce the issue on
> Guix master?

Just install a lot of R packages in a profile, including R itself would
be sufficient to reproduce it.


>
>> $ strace -c guixr package --search-paths -p /gnu/profiles/per-language/r 
>>   
>> export PATH="/gnu/profiles/per-language/r/bin"
>> export R_LIBS_SITE="/gnu/profiles/per-language/r/site-library/"
>> export TERMINFO_DIRS="/gnu/profiles/per-language/r/share/terminfo"
>> % time seconds  usecs/call callserrors syscall
>> -- --- --- - - 
>>  98.310.139510   1162612 6 wait4
>>   0.770.001087  3630 9 open
>>   0.430.000615  2129 8 stat
>
> I think you’re tracing ‘guixr’, which forks and just waits for ‘guix’
> and other commands, no?

Indeed, here's a new strace, without using 'guixr', but instead using
'guix' with 'guix-daemon' listening on a TCP port:

$ time strace -c guix package --search-paths -p /gnu/profiles/per-language/r

  
export PATH="/gnu/profiles/per-language/r/bin"
export R_LIBS_SITE="/gnu/profiles/per-language/r/site-library/"
export TERMINFO_DIRS="/gnu/profiles/per-language/r/share/terminfo"
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 30.150.010014  30   334   162 open
 24.380.008100   5  1518  1285 stat
 23.290.007738  9086   read
 11.210.003723  12   31474 futex
  2.990.000994   5   220   mmap
  2.490.000826   5   175   mprotect
  1.230.000407   2   175   close
  0.720.000238   466   fstat
  ...
-- --- --- - - 
100.000.033219  3335  1535 total

real1m12.196s
user1m10.090s
sys 0m0.377s

So, I don't think the real issue is on display here, because strace only
thinks the command took 0.033219 seconds, but it actually too 78.196
seconds.

What worries me is that almost all stat calls are erroneous, and
I think the number of calls to "open" is a bit high for this command.

So I stripped my Bash environment (unset LD_LIBRARY_PATH, only put the
path to 'guix' in PATH), and ran the strace again:

$ /usr/bin/strace -c guix package --search-paths -p 
/gnu/profiles/per-language/r

   
export PATH="/gnu/profiles/per-language/r/bin"
export R_LIBS_SITE="/gnu/profiles/per-language/r/site-library/"
export TERMINFO_DIRS="/gnu/profiles/per-language/r/share/terminfo"
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 35.750.011242   7  1510  1279 stat
 34.080.010718  35   305   135 open
  8.450.002659   8   33683 futex
  5.240.001649  2083   read
  3.940.001238   6   220   mmap
  2.990.000941   5   175   mprotect
  1.850.000582 582 1   readlink
  1.430.000450   764 2 lstat
  1.410.000445   3   170   close
  1.020.000320   564   fstat
  ...
-- --- --- - - 
100.000.031449  3283  1509 total

Even though the number of calls to "stat" and "open" are slightly lower
now, it's still a lot.

>
> TIA!
>
> Ludo’.

Re: [PATCH] Clean all .go in clean-go

[Vincent Legoll]

Hello,

> Alternatively... how about adding a new make target that also removes
> the stray .go files?

what about:

make mrproper-go

Sorry, couldn't resist...

-- 
Vincent Legoll

Re: Reporting module errors

[Hartmut Goebel]

Am 07.11.2017 um 23:47 schrieb Ludovic Courtès:
>   /tmp/config.scm:6:0: module (gnu packages foobar) could not be found

Since one of the aims of guix is to empower users, this is more cryptic.
One needs to know that ":6:0" means "line 6". Thus such a terse message
raises the bar.

I agree with George: Even if I so not understand the language the hint
is written in (English!), the hint is still, l useful since it contains
commands i can try. If you ever picked log-entries and commands from a
Russian, Chinese, Japaneses, etc web-site, you know what I mean.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

[PATCH 1/6] ui: Introduce (guix i18n).

[Ludovic Courtès]

* guix/ui.scm (G_, N_, _P, %gettext-domain, %package-text-domain): Move
to...
* guix/i18n.scm: ... here.  New file.
---
 Makefile.am   |  1 +
 guix/i18n.scm | 51 +++
 guix/ui.scm   | 27 +++
 3 files changed, 55 insertions(+), 24 deletions(-)
 create mode 100644 guix/i18n.scm

diff --git a/Makefile.am b/Makefile.am
index 41fb9ba38..7ad95cec7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -103,6 +103,7 @@ MODULES =   \
   guix/store.scm   \
   guix/cvs-download.scm\
   guix/svn-download.scm\
+  guix/i18n.scm\
   guix/ui.scm  \
   guix/build/ant-build-system.scm  \
   guix/build/download.scm  \
diff --git a/guix/i18n.scm b/guix/i18n.scm
new file mode 100644
index 0..f81e6b38e
--- /dev/null
+++ b/guix/i18n.scm
@@ -0,0 +1,51 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 

+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (guix i18n)
+  #:use-module (srfi srfi-26)
+  #:export (G_
+N_
+P_
+%gettext-domain
+%package-text-domain))
+
+;;; Commentary:
+;;;
+;;; Internationalization support.
+;;;
+;;; Code:
+
+(define %gettext-domain
+  ;; Text domain for strings used in the tools.
+  "guix")
+
+(define %package-text-domain
+  ;; Text domain for package synopses and descriptions.
+  "guix-packages")
+
+(define G_ (cut gettext <> %gettext-domain))
+(define N_ (cut ngettext <> <> <> %gettext-domain))
+
+(define (P_ msgid)
+  "Return the translation of the package description or synopsis MSGID."
+  ;; Descriptions/synopses might occasionally be empty strings, even if that
+  ;; is something we try to avoid.  Since (gettext "") can return a non-empty
+  ;; string, explicitly check for that case.
+  (if (string-null? msgid)
+  msgid
+  (gettext msgid %package-text-domain)))
diff --git a/guix/ui.scm b/guix/ui.scm
index 3c8734a7d..40371e471 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -26,6 +26,7 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (guix ui)
+  #:use-module (guix i18n)
   #:use-module (guix gexp)
   #:use-module (guix utils)
   #:use-module (guix store)
@@ -55,10 +56,8 @@
   #:use-module (texinfo)
   #:use-module (texinfo plain-text)
   #:use-module (texinfo string-utils)
-  #:export (G_
-N_
-P_
-report-error
+  #:re-export (G_ N_ P_)  ;backward compatibility
+  #:export (report-error
 leave
 make-user-module
 load*
@@ -111,26 +110,6 @@
 ;;;
 ;;; Code:
 
-(define %gettext-domain
-  ;; Text domain for strings used in the tools.
-  "guix")
-
-(define %package-text-domain
-  ;; Text domain for package synopses and descriptions.
-  "guix-packages")
-
-(define G_ (cut gettext <> %gettext-domain))
-(define N_ (cut ngettext <> <> <> %gettext-domain))
-
-(define (P_ msgid)
-  "Return the translation of the package description or synopsis MSGID."
-  ;; Descriptions/synopses might occasionally be empty strings, even if that
-  ;; is something we try to avoid.  Since (gettext "") can return a non-empty
-  ;; string, explicitly check for that case.
-  (if (string-null? msgid)
-  msgid
-  (gettext msgid %package-text-domain)))
-
 (define-syntax-rule (define-diagnostic name prefix)
   "Create a diagnostic macro (i.e., NAME), which will prepend PREFIX to all
 messages."
-- 
2.15.0

[PATCH 4/6] services: 'fold-service-types' includes (gnu services).

[Ludovic Courtès]

* gnu/services.scm (all-service-modules): New procedure.
(fold-service-types): Use it for the default MODULES value.
---
 gnu/services.scm | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/services.scm b/gnu/services.scm
index 89c5d52c8..df1bedeb9 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -175,9 +175,14 @@
   (make-parameter `((,%distro-root-directory . "gnu/services")
 (,%distro-root-directory . "gnu/system"
 
+(define (all-service-modules)
+  "Return the default set of service modules."
+  (cons (resolve-interface '(gnu services))
+(all-modules (%service-type-path
+
 (define* (fold-service-types proc seed
  #:optional
- (modules (all-modules (%service-type-path
+ (modules (all-service-modules)))
   "For each service type exported by one of MODULES, call (PROC RESULT).  SEED
 is used as the initial value of RESULT."
   (fold-module-public-variables (lambda (object result)
-- 
2.15.0

[PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.

[Ludovic Courtès]

Suggested by Julien Lepiller and myglc2
at .

* gnu.scm (%try-use-modules): New procedure.
(package-module-hint, service-module-hint): New procedures.
(try-use-modules): New macro.
(use-package-modules, use-service-modules, use-system-modules): Use it.
* tests/guix-system.sh: Test it.
---
 gnu.scm  | 100 ---
 po/guix/POTFILES.in  |   1 +
 tests/guix-system.sh |  28 +++
 3 files changed, 125 insertions(+), 4 deletions(-)

diff --git a/gnu.scm b/gnu.scm
index 913ce6160..35cd2a7f6 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2014, 2015, 2016 Ludovic Courtès 
+;;; Copyright © 2014, 2015, 2016, 2017 Ludovic Courtès 
 ;;; Copyright © 2015 Joshua S. Grant 
 ;;; Copyright © 2017 Mathieu Othacehe 
 ;;;
@@ -19,6 +19,14 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (gnu)
+  #:use-module (guix i18n)
+  #:use-module (guix utils)
+  #:use-module (srfi srfi-34)
+  #:use-module (srfi srfi-35)
+  #:use-module (ice-9 match)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
+  #:use-module (gnu services)
   #:export (use-package-modules
 use-service-modules
 use-system-modules))
@@ -52,13 +60,97 @@
   (module-use! i (resolve-interface m
   %public-modules)))
 
+(define (%try-use-modules modules location make-hint)
+  "Attempt to load all of MODULES.  Report errors as coming from LOCATION, a
+ record, and use MAKE-HINT to produce a fix hint."
+  (define (location->string loc)
+(match loc
+  (#f "")
+  (($  file line column)
+   (format #f "~a:~a:~a: " file line column
+
+  (for-each (lambda (module)
+  (catch 'misc-error
+(lambda ()
+  (process-use-modules `((,module
+(lambda _
+  (raise
+   (apply
+make-compound-condition
+(condition
+ (&message
+  (message (format #f (G_ "module ~a not found")
+   module
+(condition
+ (&error-location (location location)))
+(or (and=> (make-hint module) list)
+'()))
+modules))
+
+(define (package-module-hint module)
+  (define last-name
+(match module
+  ((_ ... last)
+   (symbol->string last
+
+  (match (find-packages-by-name last-name)
+(()
+ (condition
+  (&fix-hint
+   (hint (G_ "\
+You may use @command{guix package --show=foo | grep location} to search
+for the location of package @code{foo}.
+If you get the line @code{location: gnu/packages/bar.scm:174:2},
+add @code{bar} to the @code{use-package-modules} form.")
+((package _ ...)
+ (condition
+  (&fix-hint
+   (hint (format #f (G_ "\
+Did you mean @code{(use-package-modules ~a)}?")
+ (basename (location-file (package-location package))
+   ".scm"
+
+(define (service-module-hint module)
+  (define last-name
+(match module
+  ((_ ... last)
+   last)))
+
+  (match (lookup-service-types last-name)
+(()
+ (condition
+  (&fix-hint
+   (hint (format #f (G_ "\
+You may use @command{guix system search ~a} to search for a service
+matching @code{~a}.
+If you get the line @code{location: gnu/services/foo.scm:188:2},
+add @code{foo} to the @code{use-service-modules} form.")
+ last-name last-name)
+((package _ ...)
+ (condition
+  (&fix-hint
+   (hint (format #f (G_ "\
+Did you mean @code{(use-service-modules ~a)}?")
+ (basename (location-file (service-type-location package))
+   ".scm"
+
+(define-syntax-rule (try-use-modules hint modules ...)
+  (eval-when (expand load eval)
+(%try-use-modules '(modules ...)
+  (source-properties->location
+   (current-source-location))
+  hint)))
+
 (define-syntax-rule (use-package-modules module ...)
-  (use-modules (gnu packages module) ...))
+  (try-use-modules package-module-hint
+   (gnu packages module) ...))
 
 (define-syntax-rule (use-service-modules module ...)
-  (use-modules (gnu services module) ...))
+  (try-use-modules service-module-hint
+   (gnu services module) ...))
 
 (define-syntax-rule (use-system-modules module ...)
-  (use-modules (gnu system module) ...))
+  (try-use-modules (const #f) ;no hint
+   (gnu system module) ...))
 
 ;;; gnu.scm ends here
diff --git a/po/guix/POTFILES.in b/po/guix/POTFILES.in
index e3f767cc6..6510b99e8 100644
--- a/po/guix/POTFILES.in
+++ b/po/gu

[PATCH 5/6] services: Add 'lookup-service-types'.

[Ludovic Courtès]

* gnu/services.scm (lookup-service-types): New procedure.
* tests/services.scm ("lookup-service-types"): New test.
---
 gnu/services.scm   | 11 +++
 tests/services.scm | 10 +-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/gnu/services.scm b/gnu/services.scm
index df1bedeb9..016ff08e0 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -55,6 +55,7 @@
 
 %service-type-path
 fold-service-types
+lookup-service-types
 
 service
 service?
@@ -192,6 +193,16 @@ is used as the initial value of RESULT."
 seed
 modules))
 
+(define lookup-service-types
+  (let ((table
+ (delay (fold-service-types (lambda (type result)
+  (vhash-consq (service-type-name type)
+   type result))
+vlist-null
+(lambda (name)
+  "Return the list of services with the given NAME (a symbol)."
+  (vhash-foldq* cons '() name (force table)
+
 ;; Services of a given type.
 (define-record-type 
   (make-service type value)
diff --git a/tests/services.scm b/tests/services.scm
index 8484ee982..ca32b565c 100644
--- a/tests/services.scm
+++ b/tests/services.scm
@@ -23,7 +23,8 @@
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-34)
-  #:use-module (srfi srfi-64))
+  #:use-module (srfi srfi-64)
+  #:use-module (ice-9 match))
 
 (define live-service
   (@@ (gnu services herd) live-service))
@@ -206,4 +207,11 @@
   (list (map live-service-provision unload)
 (map shepherd-service-provision load)
 
+(test-eq "lookup-service-types"
+  system-service-type
+  (and (null? (lookup-service-types 'does-not-exist-at-all))
+   (match (lookup-service-types 'system)
+ ((one) one)
+ (x x
+
 (test-end)
-- 
2.15.0

[PATCH 2/6] ui: Define and honor '&error-location' and '&fix-hint' conditions.

[Ludovic Courtès]

* guix/utils.scm (&error-location, &fix-hint): New condition types.
* guix/ui.scm (report-load-error): Handle them.
(call-with-error-handling): Honor '&error-location'.
---
 guix/ui.scm| 23 +++
 guix/utils.scm | 17 +
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/guix/ui.scm b/guix/ui.scm
index 40371e471..a1152605e 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -251,10 +251,20 @@ ARGS is the list of arguments received by the 'throw' 
handler."
(location->string loc) message)))
 (('srfi-34 obj)
  (if (message-condition? obj)
- (report-error (G_ "~a~%")
-   (gettext (condition-message obj)
-%gettext-domain))
- (report-error (G_ "exception thrown: ~s~%") obj)))
+ (if (error-location? obj)
+ (format (current-error-port)
+ (G_ "~a: error: ~a~%")
+ (location->string (error-location obj))
+ (gettext (condition-message obj)
+  %gettext-domain))
+ (report-error (G_ "~a~%")
+   (gettext (condition-message obj)
+%gettext-domain)))
+ (report-error (G_ "exception thrown: ~s~%") obj))
+ (when (fix-hint? obj)
+   (format (current-error-port) (G_ "hint: ~a~%")
+   (fill-paragraph (texi->plain-text (condition-fix-hint obj))
+   (terminal-columns) 8
 ((error args ...)
  (report-error (G_ "failed to load '~a':~%") file)
  (apply display-error frame (current-error-port) args
@@ -517,6 +527,11 @@ interpreted."
 directories:~{ ~a~}~%")
 (file-search-error-file-name c)
 (file-search-error-search-path c)))
+((and (error-location? c) (message-condition? c))
+ (format (current-error-port)
+ (G_ "~a: error: ~a~%")
+ (location->string (error-location c))
+ (gettext (condition-message c) %gettext-domain)))
 ((message-condition? c)
  ;; Normally '&message' error conditions have an i18n'd message.
  (leave (G_ "~a~%")
diff --git a/guix/utils.scm b/guix/utils.scm
index eb1ec29b3..c0ffed172 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -28,6 +28,7 @@
   #:use-module (srfi srfi-9)
   #:use-module (srfi srfi-11)
   #:use-module (srfi srfi-26)
+  #:use-module (srfi srfi-35)
   #:use-module (srfi srfi-39)
   #:use-module (ice-9 binary-ports)
   #:autoload   (rnrs io ports) (make-custom-binary-input-port)
@@ -60,6 +61,14 @@
 source-properties->location
 location->source-properties
 
+&error-location
+error-location?
+error-location
+
+&fix-hint
+fix-hint?
+condition-fix-hint
+
 nix-system->gnu-triplet
 gnu-triplet->nix-system
 %current-system
@@ -750,6 +759,14 @@ a location object."
 (column   . ,(location-column loc))
 (filename . ,(location-file loc
 
+(define-condition-type &error-location &error
+  error-location?
+  (location  error-location)) ;
+
+(define-condition-type &fix-hint &condition
+  fix-hint?
+  (hint condition-fix-hint))  ;string
+
 ;;; Local Variables:
 ;;; eval: (put 'call-with-progress-reporter 'scheme-indent-function 1)
 ;;; End:
-- 
2.15.0

[PATCH 3/6] services: 'fold-service-types' honors its seed.

[Ludovic Courtès]

* gnu/services.scm (fold-service-types): Use SEED instead of '().
---
 gnu/services.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/services.scm b/gnu/services.scm
index 50be28a38..89c5d52c8 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -184,7 +184,7 @@ is used as the initial value of RESULT."
   (if (service-type? object)
   (proc object result)
   result))
-'()
+seed
 modules))
 
 ;; Services of a given type.
-- 
2.15.0

[PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

Hi!

Here’s an improved version that supports hints (with Texinfo markup and
i18n) and error reporting with source location info.

Hints try to make suggestions.  If you write:

  (use-package-modules qemu)

You’ll get:

  configuration.scm:7:0: error: module (gnu packages qemu) not found
  hint: Did you mean `(use-package-modules virtualization)'?

If you write:

  (use-service-modules openssh)

You get:

  configuration.scm:9:0: error: module (gnu services openssh) not found
  hint: Did you mean `(use-service-modules ssh)'?

The “did you mean” hints are based on exact matches on the package or
service names.  We could go as far as doing inexact searches akin to
what “guix package -s” and “guix system search” do, but maybe that’s
overkill given that the suggestions could be wrong.

Anyway, I think that’s already an improvement and we can always refine
it later.

Thoughts?

Ludo’.

Ludovic Courtès (6):
  ui: Introduce (guix i18n).
  ui: Define and honor '&error-location' and '&fix-hint' conditions.
  services: 'fold-service-types' honors its seed.
  services: 'fold-service-types' includes (gnu services).
  services: Add 'lookup-service-types'.
  gnu: Improve error reporting of the use-.*modules macros.

 Makefile.am  |   1 +
 gnu.scm  | 100 ---
 gnu/services.scm |  20 +--
 guix/i18n.scm|  51 ++
 guix/ui.scm  |  50 --
 guix/utils.scm   |  17 +
 po/guix/POTFILES.in  |   1 +
 tests/guix-system.sh |  28 +++
 tests/services.scm   |  10 +-
 9 files changed, 243 insertions(+), 35 deletions(-)
 create mode 100644 guix/i18n.scm

-- 
2.15.0

Re: Let’s meet before FOSDEM!

[benjaminsutter]

It’s times like this when I wish I were older. 

> On Nov 8, 2017, at 5:23 AM, Efraim Flashner  wrote:
> 
>> On Tue, Nov 07, 2017 at 02:39:53PM +0100, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> Since we didn’t get a devroom this time in spite of the efforts of
>> Manolis and Pjotr, what about holding a Guix meeting let’s say on Friday
>> before FOSDEM (Feb. 2nd, in Brussels)?
>> 
>> We could meet for the whole day, in a place that remains to be defined,
>> to discuss about all things Guix{,SD}.  The event could be a mixture of
>> short talks on specific topics, discussions on technical and less
>> technical topics (multiple bootloader support & GuixSD on ARM, making
>> ‘guix pull’ great again, Cuirass, reaching out to more
>> users/contributors, Guix & HPC, improving our infrastructure and
>> organization, etc.), and possibly hacking sessions.
>> 
>> Who would be willing to join?  (You can reply privately if you prefer.)
>> 
>> Based on the show of hands, we’ll arrange for a venue of the appropriate
>> size.
>> 
>> Thanks!
>> 
>> Ludo’.
> 
> I should be able to make it again this year. Assuming I'm taking the
> same flight as last time I'll be in Brussels by about 5am. I'm not
> suggesting that we start that early, but depending on what everyone else
> is doing we could aim to have the talks/presentations when we have the
> most number of people and then have time before and after for hacking.
> 
> 
> -- 
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Re: Creating Docker containers in Scheme

[Ludovic Courtès]

Roel Janssen  skribis:

> Ludovic Courtès writes:

[...]

>> Move precisely:
>>
>>   (mlet %store-monad ((profile (profile-derivation …)))
>> (docker-image "my-container" profile))
>>
>
> Oh, of course! :)
>
> Unfortunately, I cannot seem to get it to work.
> Here's what I do (mind the GWL process- stuff):
>
> (define* (process->docker-derivation proc #:key (guile (default-guile)))
>   "Return a Docker container that can run the PROCEDURE described in PROC, 
> with
> PROCEDURE's imported modules in its search path."
>   (let ((name (process-full-name proc))
> (exp (process-procedure proc))
> (out (process-output-path proc))
> (packages (process-package-inputs proc)))
> (let ((out-str (if out (format #f "(setenv \"out\" ~s)" out) "")))
>   (mlet %store-monad ((set-load-path
>(load-path-expression (gexp-modules exp)))
>   (container (docker-image
>   (string-append (process-full-name proc)
>   "-docker")
>   (profile-derivation
>(packages->manifest packages)
^^
See above.  :-)

> (gexp->derivation
>  name
>  (gexp
>   (call-with-output-file (ungexp output)
> (lambda (port)
>   (format port "# Docker image: ~a~%" (ungexp container)
>  #:graft? #f)
>
> And the error I get is:
>   wrong-type-arg: string-prefix?
>
> Is there anything obviously wrong here?

Hmm, we’d need to see the backtrace, but it might be the fact that
‘profile-derivation’ is not bound (in the sense of >>=).

>>> Is this something we could add to the the public interface of a module?
>>
>> Sure.  For now the easiest solution would be to export ‘docker-image’
>> from (guix scripts pack).
>>
>> Longer-term, we could rename (guix docker) to (guix build docker) and
>> move ‘docker-image’ to a new (guix docker) module, but perhaps we’d also
>> need a (guix pack) modules containing tools that are shared between the
>> docker and tarball backends of ‘guix pack’.
>>
>> WDYT?
>
> It'd be nice to keep the (guix scripts ...) small, and only do
> command-line handling.  So I think a (guix build docker), and a (guix
> pack) module would be good.

Yes, I agree that this is the right direction.

Ludo’.

Re: Let’s meet before FOSDEM!

[Ludovic Courtès]

Efraim Flashner  skribis:

> I should be able to make it again this year. Assuming I'm taking the
> same flight as last time I'll be in Brussels by about 5am. I'm not
> suggesting that we start that early, but depending on what everyone else
> is doing we could aim to have the talks/presentations when we have the
> most number of people and then have time before and after for hacking.

I think we could aim for ~9am for the beginning.  5am is a bit too
early.  ;-)

Ludo’.

Re: Reporting module errors

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 07.11.2017 um 23:47 schrieb Ludovic Courtès:
>>   /tmp/config.scm:6:0: module (gnu packages foobar) could not be found
>
> Since one of the aims of guix is to empower users, this is more cryptic.
> One needs to know that ":6:0" means "line 6". Thus such a terse message
> raises the bar.

Well, Guix has always reported source code location like this, and
besides Guix all GNU tools and many non-GNU tools do.  At some point we
have to agree on conventions…

Ludo’.

Re: [PATCH 0/6] Error reporting and hints for missing modules

[julien lepiller]

Le 2017-11-08 14:09, Ludovic Courtès a écrit :

Hi!

Here’s an improved version that supports hints (with Texinfo markup and
i18n) and error reporting with source location info.

Hints try to make suggestions.  If you write:

  (use-package-modules qemu)

You’ll get:

  configuration.scm:7:0: error: module (gnu packages qemu) not found
  hint: Did you mean `(use-package-modules virtualization)'?

If you write:

  (use-service-modules openssh)

You get:

  configuration.scm:9:0: error: module (gnu services openssh) not found
  hint: Did you mean `(use-service-modules ssh)'?

The “did you mean” hints are based on exact matches on the package or
service names.  We could go as far as doing inexact searches akin to
what “guix package -s” and “guix system search” do, but maybe that’s
overkill given that the suggestions could be wrong.

Anyway, I think that’s already an improvement and we can always refine
it later.

Thoughts?


This is great! I don't understand it all, but it seems like when there 
is

no exact match for a package or service, we get the more generic hint
I wrote.

I'm happy with this version, so LGTM (though untested). Let's see what
George thinks about it.




Ludo’.

Ludovic Courtès (6):
  ui: Introduce (guix i18n).
  ui: Define and honor '&error-location' and '&fix-hint' conditions.
  services: 'fold-service-types' honors its seed.
  services: 'fold-service-types' includes (gnu services).
  services: Add 'lookup-service-types'.
  gnu: Improve error reporting of the use-.*modules macros.

 Makefile.am  |   1 +
 gnu.scm  | 100 
---

 gnu/services.scm |  20 +--
 guix/i18n.scm|  51 ++
 guix/ui.scm  |  50 --
 guix/utils.scm   |  17 +
 po/guix/POTFILES.in  |   1 +
 tests/guix-system.sh |  28 +++
 tests/services.scm   |  10 +-
 9 files changed, 243 insertions(+), 35 deletions(-)
 create mode 100644 guix/i18n.scm

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

On 11/08/2017 at 16:33 julien lepiller writes:

> Le 2017-11-08 14:09, Ludovic Courtès a écrit :
>> Hi!
>>
>> Here’s an improved version that supports hints (with Texinfo markup and
>> i18n) and error reporting with source location info.
>>
>> Hints try to make suggestions.  If you write:
>>
>>   (use-package-modules qemu)
>>
>> You’ll get:
>>
>>   configuration.scm:7:0: error: module (gnu packages qemu) not found
>>   hint: Did you mean `(use-package-modules virtualization)'?
>>
>> If you write:
>>
>>   (use-service-modules openssh)
>>
>> You get:
>>
>>   configuration.scm:9:0: error: module (gnu services openssh) not found
>>   hint: Did you mean `(use-service-modules ssh)'?
>>
>> The “did you mean” hints are based on exact matches on the package or
>> service names.  We could go as far as doing inexact searches akin to
>> what “guix package -s” and “guix system search” do, but maybe that’s
>> overkill given that the suggestions could be wrong.
>>
>> Anyway, I think that’s already an improvement and we can always refine
>> it later.
>>
>> Thoughts?
>
> This is great! I don't understand it all, but it seems like when there
> is
> no exact match for a package or service, we get the more generic hint
> I wrote.
>
> I'm happy with this version, so LGTM (though untested). Let's see what
> George thinks about it.

Oh YEAH! This is truly awesome!

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

Hi Ludo’,

I built and played with this. I see you also provide a search hint when
you don't find an obvious match, as in ...

sys.scm:3:0: error: module (gnu services sshx) not found
hint: You may use `guix system search sshx' to search for a service matching 
`sshx'.  If you get the line `location: gnu/services/foo.scm:188:2', add `foo' 
to the `use-service-modules'
form.

This is very nice indeed.

Based on testing, may I suggest the hint rewording shown below ...

On 11/08/2017 at 12:42 myglc2 writes:

> On 11/08/2017 at 16:33 julien lepiller writes:
>
>> Le 2017-11-08 14:09, Ludovic Courtès a écrit :
>>> Hi!
>>>
>>> Here’s an improved version that supports hints (with Texinfo markup and
>>> i18n) and error reporting with source location info.
>>>
>>> Hints try to make suggestions.  If you write:
>>>
>>>   (use-package-modules qemu)
>>>
>>> You’ll get:
>>>
>>>   configuration.scm:7:0: error: module (gnu packages qemu) not found
>>>   hint: Did you mean `(use-package-modules virtualization)'?

hint: Try adding `(use-package-modules virtualization)'

>>>
>>> If you write:
>>>
>>>   (use-service-modules openssh)
>>>
>>> You get:
>>>
>>>   configuration.scm:9:0: error: module (gnu services openssh) not found
>>>   hint: Did you mean `(use-service-modules ssh)'?

hint: Try adding `(use-service-modules ssh)'

Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 11:23 Ludovic Courtès writes:

> Hello,
>
> myglc2  skribis:
>
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>
> It should be noted that you were using a “developer setup”, specifically
> running Guix from a checkout with ./pre-inst-env and all.
>
> The issue with the stale module wouldn’t happen with “guix pull”, which
> is the recommended “user setup.”
>
> While I agree the situation is not ideal, I think we have to admit that
> developers can always shoot themselves in the foot, and that was one way
> of doing it.  ;-)
>
> Thoughts?
>
> Ludo’.

I think I misinterpreted this earlier as dismissing the usability
points.  Now I think you are referring to the bug specifically, and from
that point of view I agree. I have closed the bug as notabug.

I posted thoughts/questions re use of "developer setup" by users and
'make clean-go' here ...

http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00080.html

Best - George

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

Hi,

myglc2  skribis:

> I built and played with this. I see you also provide a search hint when
> you don't find an obvious match, as in ...
>
> sys.scm:3:0: error: module (gnu services sshx) not found
> hint: You may use `guix system search sshx' to search for a service matching 
> `sshx'.  If you get the line `location: gnu/services/foo.scm:188:2', add 
> `foo' to the `use-service-modules'
> form.
>
> This is very nice indeed.

Glad you like it.

 You get:

   configuration.scm:9:0: error: module (gnu services openssh) not found
   hint: Did you mean `(use-service-modules ssh)'?
>
> hint: Try adding `(use-service-modules ssh)'

Good idea.  I’ve made this change and pushed.

Thanks to the two of you!  I think this is really the kind of UI/UX
improvements we should be making, but die-hard Guix hackers like me
don’t necessarily think about it, so it’s great that you came up with
this idea.

Ludo’.

Re: Let’s meet before FOSDEM!

[ng0]

Ludovic Courtès transcribed 0.5K bytes:
> Efraim Flashner  skribis:
> 
> > I should be able to make it again this year. Assuming I'm taking the
> > same flight as last time I'll be in Brussels by about 5am. I'm not
> > suggesting that we start that early, but depending on what everyone else
> > is doing we could aim to have the talks/presentations when we have the
> > most number of people and then have time before and after for hacking.
> 
> I think we could aim for ~9am for the beginning.  5am is a bit too
> early.  ;-)
> 
> Ludo’.

Yeah. Depending on the means of transportation I choose, I
could arrive between 5 and 9AM at Brussel Central.
-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
  WWW: https://ng0.infotropique.org


signature.asc
Description: PGP signature

Re: Building Docker images of GuixSD

[Chris Marusich]

Hi Ludo and others following along,

I've run GuixSD in a Docker container and returned to tell the tale!
The attached patch requires a lot of cleaning up (e.g., proper ChangeLog
entry, update documentation, remove some unnecessary imports and debug
messages that are probably still in there), so I'm taking a moment to
share my results and ask for feedback before committing to spending more
time on this.

Run GuixSD in Docker


The attached patch makes it possible to build a GuixSD Docker image from
an operating system configuration file.

You can build your own like this:

1) Apply this patch to 3b2fa4787938a408fab27ef7b3bc1302b6b6a805.

2) Build an image (I used the attached file "very-bare-bones.scm"):

./pre-inst-env guix system disk-image -t docker very-bare-bones.scm

3) Copy the resulting image onto a host that has Docker installed.

4) On the host with Docker, load the image and note the image ID:

docker load < pw3d4r4m1x9yc3d1kg9x3y6abdzq9z7g-docker-image.tar.gz

5) Run a Docker container from the image, and note the container ID:

docker run --privileged -d -e GUIX_NEW_SYSTEM=/var/guix/profiles/system 
--net host --entrypoint /var/guix/profiles/system/profile/bin/guile 
dcaa8fb677c7 /var/guix/profiles/system/boot

6) Run a shell in the container, install a package, and use it:

docker exec -it -e USER=alice -u alice fb06fdcd3a0d 
/run/current-system/profile/bin/bash --login

7) Install a package and use it:

alice@komputilo /$ guix package -i hello
...
Creating manual page database for 1 packages... done in 0.110 s
1 package in profile
alice@komputilo /$ guix package --list-installed
hello   2.10out 
/gnu/store/wf65hjwqwpz4wllasn63zysi5irql2sx-hello-2.10
alice@komputilo /$ hello
Hello, world!

Pretty neat!

How Useful Is This?
===

Using Guix, it was already possible to generate Docker images using
"guix pack".  For example, I could have just generated a Docker image
from the GNU Hello package, created a container from that, and then run
"hello" from that container.  What does running GuixSD in Docker give us
that we don't have already?  At a minimum, it gives us the following:

* The ability to define what service(s) should run in the resulting
  Docker container, including their configs and start/stop scripts.
  
* Since the Docker image is generated from a GuixSD operating system
  configuration file, the rules for defining and configuring services
  are the same as always.  You don't have to learn anything new.

* If you want to run Guix on a system to which Guix hasn't been ported
  (like macOS) but your system does run Docker, now you can run Guix on
  that system by running it from a GuixSD Docker container.

Is this helpful?  Is it worth polishing up and maintaining?  I'm not
entirely sure, and I'd like to know what you think.

For the first two bullet points, that's nice, but instead of using a
full-blown OS and relying on the Shepherd for process management in this
case, would it be simpler to just provide a way to easily bundle
start/stop scripts inside of the packs produced by "guix pack"?  An
enterprising user can probably do this today by simply defining a
package that builds start/stop scripts for a given service; the user
would then just need to include that package in the pack.  The downside,
I guess, is that you can't re-use the service-specific stuff that you
can normally use in a GuixSD operating system configuration file.

For the third bullet point, I don't know of any other reasonable way to
get Guix working in Docker (although one could certainly run Guix in a
VM using a technology other than Docker, such as QEMU).  To run Guix,
you need the Guix daemon running somewhere, right?  And the Guix daemon
requires that certain build users exist.  It might require other things
from its environment, too.  In any case, you can't just run "guix pack
-t docker guix" and expect the "guix" command to work in the container
(I tried, and it doesn't work).  You have to take additional measures,
like create build users, at which point it seems easier to just put all
of GuixSD into a Docker image.  That's what my patch lets you do.

What do you think?  Is this worth polishing up and maintaining?

Problems I Noticed
==

Now I'll mention some specific problems I've noticed while running
GuixSD in a Docker container.  First, I saw this while the Docker image
was being generated:

tar: Removing leading `/' from member names
tar: Removing leading `/' from hard link targets
tar: ./dev/log: socket ignored

It's fine that we remove the leading '/' from member names, since it
looks like the tarball will be extracted relative to '/'.  I think the
same is true for the hard link targets.  However, because tar ignored
'/dev/log', that socket is missing in the Docker image.  I don't know if
that will interfere with syslogd, but it sure doesn't sound good.

Second, I noticed the foll

Re: Building Docker images of GuixSD

[Pjotr Prins]

Chris, this is very interesting! Even with privileged mode it makes it
much easier to experiment. 

Pj.

On Wed, Nov 08, 2017 at 10:15:38PM -0800, Chris Marusich wrote:
> Hi Ludo and others following along,
> 
> I've run GuixSD in a Docker container and returned to tell the tale!
> The attached patch requires a lot of cleaning up (e.g., proper ChangeLog
> entry, update documentation, remove some unnecessary imports and debug
> messages that are probably still in there), so I'm taking a moment to
> share my results and ask for feedback before committing to spending more
> time on this.
> 
> Run GuixSD in Docker
> 
> 
> The attached patch makes it possible to build a GuixSD Docker image from
> an operating system configuration file.
> 
> You can build your own like this:
> 
> 1) Apply this patch to 3b2fa4787938a408fab27ef7b3bc1302b6b6a805.
> 
> 2) Build an image (I used the attached file "very-bare-bones.scm"):
> 
> ./pre-inst-env guix system disk-image -t docker very-bare-bones.scm
> 
> 3) Copy the resulting image onto a host that has Docker installed.
> 
> 4) On the host with Docker, load the image and note the image ID:
> 
> docker load < pw3d4r4m1x9yc3d1kg9x3y6abdzq9z7g-docker-image.tar.gz
> 
> 5) Run a Docker container from the image, and note the container ID:
> 
> docker run --privileged -d -e GUIX_NEW_SYSTEM=/var/guix/profiles/system 
> --net host --entrypoint /var/guix/profiles/system/profile/bin/guile 
> dcaa8fb677c7 /var/guix/profiles/system/boot
> 
> 6) Run a shell in the container, install a package, and use it:
> 
> docker exec -it -e USER=alice -u alice fb06fdcd3a0d 
> /run/current-system/profile/bin/bash --login
> 
> 7) Install a package and use it:
> 
> alice@komputilo /$ guix package -i hello
> ...
> Creating manual page database for 1 packages... done in 0.110 s
> 1 package in profile
> alice@komputilo /$ guix package --list-installed
> hello 2.10out 
> /gnu/store/wf65hjwqwpz4wllasn63zysi5irql2sx-hello-2.10
> alice@komputilo /$ hello
> Hello, world!
> 
> Pretty neat!
> 
> How Useful Is This?
> ===
> 
> Using Guix, it was already possible to generate Docker images using
> "guix pack".  For example, I could have just generated a Docker image
> from the GNU Hello package, created a container from that, and then run
> "hello" from that container.  What does running GuixSD in Docker give us
> that we don't have already?  At a minimum, it gives us the following:
> 
> * The ability to define what service(s) should run in the resulting
>   Docker container, including their configs and start/stop scripts.
>   
> * Since the Docker image is generated from a GuixSD operating system
>   configuration file, the rules for defining and configuring services
>   are the same as always.  You don't have to learn anything new.
> 
> * If you want to run Guix on a system to which Guix hasn't been ported
>   (like macOS) but your system does run Docker, now you can run Guix on
>   that system by running it from a GuixSD Docker container.
> 
> Is this helpful?  Is it worth polishing up and maintaining?  I'm not
> entirely sure, and I'd like to know what you think.
> 
> For the first two bullet points, that's nice, but instead of using a
> full-blown OS and relying on the Shepherd for process management in this
> case, would it be simpler to just provide a way to easily bundle
> start/stop scripts inside of the packs produced by "guix pack"?  An
> enterprising user can probably do this today by simply defining a
> package that builds start/stop scripts for a given service; the user
> would then just need to include that package in the pack.  The downside,
> I guess, is that you can't re-use the service-specific stuff that you
> can normally use in a GuixSD operating system configuration file.
> 
> For the third bullet point, I don't know of any other reasonable way to
> get Guix working in Docker (although one could certainly run Guix in a
> VM using a technology other than Docker, such as QEMU).  To run Guix,
> you need the Guix daemon running somewhere, right?  And the Guix daemon
> requires that certain build users exist.  It might require other things
> from its environment, too.  In any case, you can't just run "guix pack
> -t docker guix" and expect the "guix" command to work in the container
> (I tried, and it doesn't work).  You have to take additional measures,
> like create build users, at which point it seems easier to just put all
> of GuixSD into a Docker image.  That's what my patch lets you do.
> 
> What do you think?  Is this worth polishing up and maintaining?
> 
> Problems I Noticed
> ==
> 
> Now I'll mention some specific problems I've noticed while running
> GuixSD in a Docker container.  First, I saw this while the Docker image
> was being generated:
> 
> tar: Removing leading `/' from member names
> tar: Removing leading `/' from hard link targets
> tar: ./dev/log: socke