* potluck in the house
@ 2017-04-13 13:25 Andy Wingo
2017-04-13 15:42 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Andy Wingo @ 2017-04-13 13:25 UTC (permalink / raw)
To: guix-devel
Hi!
This is an update on "guix potluck", an attempt to support a more
decentralized way of developing Guix packages, as a complement to the
main package set.
I have a number of packages that I never packaged for external use, at
least beyond putting them in a git repo somewhere. Here's an example of
packaging one of these with guix potluck. Guile-Present is a library
that lets you write presentations in Texinfo and uses Cairo to render
nthat to slides.
I dug up the repo and pushed it to gitlab at
https://gitlab.com/wingo/guile-present. Then in the root directory of
that checkout I ran:
guix potluck init
and it carps, saying
guix potluck init: wrong number of arguments
usage: guix potluck init [OPT...] REMOTE-GIT-URL
Try 'guix potluck --help' for more information.
If you run help you see you need a URL for the public git repo. Cool, I
have that:
guix potluck init https://gitlab.com/wingo/guile-present
Now it says:
guix potluck: error: init: missing --build-system; try --build-system=help for options
OK, I do that:
guix potluck: Available build systems:
ant The standard Ant build system
asdf/ecl The build system for ASDF binary packages using ECL
asdf/sbcl The build system for ASDF binary packages using SBCL
asdf/source The build system for ASDF source packages
cargo Cargo build system, to build Rust crates
cmake The standard CMake build system
dub DUB build system, to build D packages
emacs The build system for Emacs packages
glib-or-gtk The GNU Build System—i.e., ./configure && make && make install,
augmented with definition of suitable environment variables for glib and gtk+
in program wrappers.
gnu The GNU Build System—i.e., ./configure && make && make install
haskell The standard Haskell build system
ocaml The standard OCaml build system
perl The standard Perl build system
python The standard Python build system
r The standard R build system
ruby The standard Ruby build system
trivial Trivial build system, to run arbitrary Scheme build expressions
waf The standard waf build system
Additionally, --autotools is like --build-system=gnu, but also indicating
that the package needs autoreconf before running ./configure.
OK great, sounds like --autotools is what I need.
guix potluck init --autotools https://gitlab.com/wingo/guile-present
Yaargh:
guix potluck: error: init: missing --license; try --license=help for options
OK let's get help then with --license=help:
guix potluck: Available licenses:
agpl1 https://gnu.org/licenses/agpl.html
agpl3 https://gnu.org/licenses/agpl.html
agpl3+ https://gnu.org/licenses/agpl.html
artistic2.0 http://www.perlfoundation.org/artistic_license_2_0
asl1.1 http://directory.fsf.org/wiki/License:Apache1.1
asl2.0 http://directory.fsf.org/wiki/License:Apache2.0
boost1.0 http://directory.fsf.org/wiki/License:Boost1.0
bsd-2 http://directory.fsf.org/wiki/License:FreeBSD
bsd-3 http://directory.fsf.org/wiki/License:BSD_3Clause
bsd-4 http://directory.fsf.org/wiki/License:BSD_4Clause
cc-by-sa2.0 http://creativecommons.org/licenses/by-sa/2.0/
cc-by-sa3.0 http://creativecommons.org/licenses/by-sa/3.0/
cc-by-sa4.0 http://creativecommons.org/licenses/by-sa/4.0/
cc-by2.0 http://creativecommons.org/licenses/by/2.0/
cc-by3.0 http://creativecommons.org/licenses/by/3.0/
cc0 http://directory.fsf.org/wiki/License:CC0
cddl1.0 http://directory.fsf.org/wiki/License:CDDLv1.0
cecill-c http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html
clarified-artistic http://gianluca.dellavedova.org/2011/01/03/clarified-artistic-license/
copyleft-next https://raw.github.com/richardfontana/copyleft-next/master/Releases/copyleft-next-0.3.0
cpl1.0 http://directory.fsf.org/wiki/License:CPLv1.0
epl1.0 http://directory.fsf.org/wiki/License:EPLv1.0
expat http://directory.fsf.org/wiki/License:Expat
fdl1.1+ https://www.gnu.org/licenses/fdl-1.1
fdl1.2+ https://www.gnu.org/licenses/fdl-1.2
fdl1.3+ https://www.gnu.org/licenses/fdl.html
freebsd-doc https://www.freebsd.org/copyright/freebsd-doc-license.html
freetype http://directory.fsf.org/wiki/License:Freetype
gfl1.0 http://www.gust.org.pl/projects/e-foundry/licenses/GUST-FONT-LICENSE.txt
giftware http://liballeg.org/license.html
gpl1 https://www.gnu.org/licenses/old-licenses/gpl-1.0.html
gpl1+ https://www.gnu.org/licenses/old-licenses/gpl-1.0.html
gpl2 https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
gpl2+ https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
gpl3 https://www.gnu.org/licenses/gpl.html
gpl3+ https://www.gnu.org/licenses/gpl.html
ibmpl1.0 http://directory.fsf.org/wiki/License:IBMPLv1.0
ijg http://directory.fsf.org/wiki/License:JPEG
imlib2 http://directory.fsf.org/wiki/License:Imlib2
ipa http://directory.fsf.org/wiki/License:IPA_Font_License
isc http://directory.fsf.org/wiki/License:ISC
lgpl2.0 https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html
lgpl2.0+ https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html
lgpl2.1 https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
lgpl2.1+ https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
lgpl3 https://www.gnu.org/licenses/lgpl.html
lgpl3+ https://www.gnu.org/licenses/lgpl.html
mpl1.0 http://www.mozilla.org/MPL/1.0/
mpl1.1 http://directory.fsf.org/wiki/License:MPLv1.1
mpl2.0 http://directory.fsf.org/wiki/License:MPLv2.0
ms-pl http://directory.fsf.org/wiki/License:MsPL
ncsa http://directory.fsf.org/wiki/License:IllinoisNCSA
nmap https://svn.nmap.org/nmap/COPYING
openldap2.8 http://directory.fsf.org/wiki/License:OpenLDAPv2.8
openssl http://directory.fsf.org/wiki/License:OpenSSL
opl1.0+ http://opencontent.org/openpub/
psfl http://docs.python.org/license.html
public-domain http://directory.fsf.org/wiki/License:PublicDomain
qpl http://directory.fsf.org/wiki/License:QPLv1.0
repoze http://repoze.org/LICENSE.txt
ruby http://directory.fsf.org/wiki/License:Ruby
sgifreeb2.0 http://directory.fsf.org/wiki/License:SGIFreeBv2
silofl1.1 http://scripts.sil.org/OFL_web
sleepycat http://directory.fsf.org/wiki/License:Sleepycat
tcl/tk http://www.tcl.tk/software/tcltk/license.html
unlicense https://unlicense.org/
vim http://directory.fsf.org/wiki/License:Vim7.2
wtfpl2 http://www.wtfpl.net
x11 http://directory.fsf.org/wiki/License:X11
zlib http://www.gzip.org/zlib/zlib_license.html
zpl2.1 http://directory.fsf.org/wiki?title=License:ZopePLv2.1
If your package's license is not in this list, add it to Guix first.
What is this package's license anyway????? I look and it's LGPLv3+
apparently. So now:
guix potluck init --autotools --license=lgpl3+ https://gitlab.com/wingo/guile-present
And voilà:
Cloning into '/tmp/guix-directory.861r57/git-checkout'... done.
Creating guix-potluck/
Creating guix-potluck/README.md
Creating guix-potluck/guile-present.scm
Done. Now open guix-potluck/guile-present.scm in your editor, fill out its "synopsis"
and "description" fields, add dependencies to the 'inputs' field, and try to
build with
guix build --file=guix-potluck/guile-present.scm
When you get that working, commit your results to git via:
git add guix-potluck && git commit -m 'Add initial Guix potluck files.'
Once you push them out, add your dish to the communal potluck by running:
guix potluck update https://gitlab.com/wingo/guile-present master
OK that's interesting! What I get in the file looks like this:
;;; guix potluck package
;;; Copyright (C) 2017 Andy Wingo
;;; This file 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. No warranty. See
;;; https://www.gnu.org/licenses/gpl.html for a copy of the GPLv3.
(potluck-package
(name "guile-present")
(version "v0.3.0-14-g3b0d2d9")
(source
(potluck-source
(git-uri "https://gitlab.com/wingo/guile-present")
(git-commit "3b0d2d967909dabdd3f86d3a50da79c6b1a8aeb2")
(sha256 "0sr5snj921k91frh5dx1gsqrc3679liydv3b6nwxkl48m7h5mals")))
(build-system 'gnu)
(inputs '())
(native-inputs '("autoconf" "automake" "libtool" "pkg-config"))
(propagated-inputs '())
(arguments
'(#:phases
(modify-phases
%standard-phases
(add-before
'configure
'autoconf
(lambda _ (zero? (system* "autoreconf" "-vfi")))))))
(home-page "https://gitlab.com/wingo/guile-present")
(synopsis "Declarative synopsis here")
(description "Guile-Present is a ...")
(license 'lgpl3+))
It pulled the copyright author from "git config user.name", the version
from "git describe", the commit from HEAD, and the sha256 from guix hash
-g. The inputs are as for --autotools, and the build system and license
come from the command line.
So I fill in the synopsis and add "guile", "guile-lib", and
"guile-cairo" to inputs list, and after trying the guix build -f line a
few times "texinfo" to native-inputs, and I change "guile" to
"guile@2.0" because of how guile-lib and guile-cairo are built. Final
version looks like this:
(potluck-package
(name "guile-present")
(version "v0.3.0-14-g3b0d2d9")
(source
(potluck-source
(git-uri "https://gitlab.com/wingo/guile-present")
(git-commit "3b0d2d967909dabdd3f86d3a50da79c6b1a8aeb2")
(sha256 "0sr5snj921k91frh5dx1gsqrc3679liydv3b6nwxkl48m7h5mals")))
(build-system 'gnu)
(inputs '("guile@2.0" "guile-cairo" "guile-lib"))
(native-inputs '("autoconf" "automake" "libtool" "pkg-config" "texinfo"))
(propagated-inputs '())
(arguments
'(#:phases
(modify-phases
%standard-phases
(add-before
'configure
'autoconf
(lambda _ (zero? (system* "autoreconf" "-vfi")))))))
(home-page "https://gitlab.com/wingo/guile-present")
(synopsis "Presentation software that can generate PDF slides from
Texinfo.")
(description "Guile-Present is a library for slide rendering. It
uses Guile's Texinfo parser to parse presentations written in that
language, and renders them to PDF using Guile-Cairo.")
(license 'lgpl3+))
It builds, which is pretty cool. (The wip-potluck branch extends guix
build -f to recognize potluck packages.)
Now I pushed this out to the public gitlab repo. You can include
guix-potluck files in the repo of the projects they package, or you can
include them in a separate repo -- doesn't really matter.
Now here's the cool thing, when you run the "update" command as
mentioned:
guix potluck update https://gitlab.com/wingo/guile-present master
By default it connects to guix-potluck.org; you can use --host to
specify a different host. All connections to the potluck host are over
HTTPS. OK it spews some trash on stdout:
ERROR: In procedure get-bytevector-n:
ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum The TLS connection was non-properly terminated.> read_from_session_record_port)'.
I don't understand this entirely; shouldn't nginx be terminating things
fine? I have never used the HTTP client with HTTPS though.
Anyway, fine. So the server received this request, checked out that git
repo and branch, looked for potluck packages in guix-potluck/, and added
those packages to a "source" git repo:
wingo@clucks:~/src$ mkdir guix-potluck
wingo@clucks:~/src$ cd guix-potluck/
wingo@clucks:~/src/guix-potluck$ git clone https://guix-potluck.org/git/source.git
Cloning into 'source'...
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 10 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (10/10), done.
wingo@clucks:~/src/guix-potluck$ ls source
https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-jpeg https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present
wingo@clucks:~/src/guix-potluck$ find source/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present/
source/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present/
source/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present/master
source/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present/master/guile-present.scm
Indeed that's my file, just as it was above. But the cooler thing is
that it also compiles this potluck package to a "standard" Guix package
and module:
wingo@clucks:~/src/guix-potluck$ git clone https://guix-potluck.org/git/target.git
Cloning into 'target'...
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 16 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (16/16), done.
wingo@clucks:~/src/guix-potluck$ cd target/
wingo@clucks:~/src/guix-potluck/target$ ls
gnu
wingo@clucks:~/src/guix-potluck/target$ find gnu
gnu
gnu/packages
gnu/packages/potluck
gnu/packages/potluck/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present
gnu/packages/potluck/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present/master
gnu/packages/potluck/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present/master/guile-present.scm
gnu/packages/potluck/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-jpeg
gnu/packages/potluck/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-jpeg/master
gnu/packages/potluck/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-jpeg/master/guile-jpeg.scm
wingo@clucks:~/src/guix-potluck/target$ cat gnu/packages/potluck/https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present/master/guile-present.scm
;;; guix potluck package
;;; Copyright (C) 2017 Andy Wingo
;;; This file 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. No warranty. See
;;; https://www.gnu.org/licenses/gpl.html for a copy of the GPLv3.
(define-module (gnu packages potluck https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present master guile-present)
#:pure
#:use-module ((guile) #:select (list quote define-public))
#:use-module ((guix packages) #:select (package origin base32))
#:use-module ((guix git-download) #:select (git-fetch git-reference))
#:use-module ((guix licenses) #:select ((lgpl3+ . license:lgpl3+)))
#:use-module ((guix build-system gnu) #:select (gnu-build-system))
#:use-module ((gnu packages pkg-config) #:select (%pkg-config))
#:use-module ((gnu packages texinfo) #:select (texinfo))
#:use-module ((gnu packages autotools) #:select (libtool automake autoconf))
#:use-module ((gnu packages gtk) #:select (guile-cairo))
#:use-module ((gnu packages guile) #:select (guile-lib guile-2.0)))
(define-public guile-present
(package
(name "guile-present")
(version "v0.3.0-14-g3b0d2d9")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://gitlab.com/wingo/guile-present")
(commit "3b0d2d967909dabdd3f86d3a50da79c6b1a8aeb2")))
(sha256 (base32 "0sr5snj921k91frh5dx1gsqrc3679liydv3b6nwxkl48m7h5mals"))))
(build-system gnu-build-system)
(inputs
(list (list "guile" guile-2.0)
(list "guile-cairo" guile-cairo)
(list "guile-lib" guile-lib)))
(native-inputs
(list (list "autoconf" autoconf)
(list "automake" automake)
(list "libtool" libtool)
(list "pkg-config" %pkg-config)
(list "texinfo" texinfo)))
(arguments
'(#:phases
(modify-phases
%standard-phases
(add-before
'configure
'autoconf
(lambda _ (zero? (system* "autoreconf" "-vfi")))))))
(home-page "https://gitlab.com/wingo/guile-present")
(synopsis "Presentation software that can generate PDF slides from\nTexinfo.")
(description "Guile-Present is a library for slide rendering. It\nuses Guile's Texinfo parser to parse presentations written in that\nlanguage, and renders them to PDF using Guile-Cairo.")
(license license:lgpl3+)))
Now this git repo should be able to be added to the GUIX_PACKAGE_PATH.
It's effectively a "channel" managed by "guix potluck host-channel"
running on guix-potluck.org. If you have a checkout of this repo, you
can build Guile-Present just via "guix build -L /path/to/target/checkout
guile-jpeg". Pretty cool, right??!!!?!?!
Incidentally here is the configuration for that server:
(use-modules (ice-9 match) (gnu) (guix records))
(use-service-modules networking mcron shepherd ssh web)
(use-package-modules admin certs guile package-management ssh tls version-control web)
(define-record-type* <fcgiwrap-configuration> fcgiwrap-configuration
make-fcgiwrap-configuration
fcgiwrap-configuration?
(package fcgiwrap-configuration-package ;<package>
(default fcgiwrap))
(socket fcgiwrap-configuration-socket
(default "tcp:127.0.0.1:9000")))
(define %fcgiwrap-accounts
(list (user-group
(name "fcgiwrap")
(system? #t))
(user-account
(name "fcgiwrap")
(group "fcgiwrap")
(system? #t)
(comment "Fcgiwrap Daemon")
(home-directory "/var/empty")
(shell (file-append shadow "/sbin/nologin")))))
(define fcgiwrap-shepherd-service
(match-lambda
(($ <fcgiwrap-configuration> package socket)
(list (shepherd-service
(provision '(fcgiwrap))
(documentation "Run the fcgiwrap daemon.")
(requirement '(networking))
(start #~(make-forkexec-constructor
'(#$(file-append package "/sbin/fcgiwrap")
"-s" #$socket)
#:user "fcgiwrap" #:group "fcgiwrap"))
(stop #~(make-kill-destructor)))))))
(define fcgiwrap-service-type
(service-type (name 'fcgiwrap)
(extensions
(list (service-extension shepherd-root-service-type
fcgiwrap-shepherd-service)
(service-extension account-service-type
(const %fcgiwrap-accounts))))))
(define %guix-potluck-accounts
(list (user-group
(name "guix-potluck")
(system? #t))
(user-account
(name "guix-potluck")
(group "guix-potluck")
(system? #t)
(comment "Guix potluck host")
(home-directory "/var/empty")
(shell (file-append shadow "/sbin/nologin")))))
(define-record-type* <guix-potluck-configuration> guix-potluck-configuration
make-guix-potluck-configuration
guix-potluck-configuration?
#;
(package guix-potluck-configuration-package ;<package>
(default guix-potluck))
(scratch guix-potluck-configuration-scratch
(default "/var/cache/guix-potluck/scratch"))
(source guix-potluck-configuration-source
(default "/var/cache/guix-potluck/source"))
(source-repo guix-potluck-configuration-source-repo
(default "/srv/git/source.git"))
(target guix-potluck-configuration-target
(default "/var/cache/guix-potluck/target"))
(target-repo guix-potluck-configuration-target-repo
(default "/srv/git/target.git")))
(define guix-potluck-activation-service
(match-lambda
(($ <guix-potluck-configuration>
scratch source source-repo target target-repo)
(with-imported-modules '((guix build utils))
#~(begin
(use-modules (guix build utils) (ice-9 ftw))
(define (chown-r dir user group)
(let ((uid (passwd:uid (getpwnam user)))
(gid (group:gid (getgrnam group))))
(for-each (lambda (f) (chown f uid gid))
(find-files dir #:directories? #t))))
(define (ensure-git-repo dir)
(unless (file-exists? dir)
(mkdir-p dir)
(unless (zero? (system* (string-append #$git "/bin/git")
"init" "--bare" dir))
(error "failed to create repository" dir))
(chown-r dir "guix-potluck" "guix-potluck")))
(define (ensure-checkout repo dir)
(unless (file-exists? dir)
(mkdir-p (dirname dir))
(unless (zero? (system* (string-append #$git "/bin/git")
"clone" repo dir))
(error "failed to check out repository" repo dir))
(chown-r dir "guix-potluck" "guix-potluck")))
(mkdir-p #$scratch)
(chown-r #$scratch "guix-potluck" "guix-potluck")
(ensure-git-repo #$source-repo)
(ensure-git-repo #$target-repo)
(ensure-checkout #$source-repo #$source)
(ensure-checkout #$target-repo #$target))))))
(define guix-potluck-shepherd-service
(match-lambda
(($ <guix-potluck-configuration>
scratch source source-repo target target-repo)
(list (shepherd-service
(provision '(guix-potluck))
(documentation "Run the guix-potluck daemon.")
(requirement '(networking))
(start #~(make-forkexec-constructor
'("/home/wingo/src/guix/pre-inst-env" "guix" "host-potluck"
#$(format #f "--scratch=~a" scratch)
#$(format #f "--source=~a" source)
#$(format #f "--target=~a" target))
#:user "guix-potluck" #:group "guix-potluck"))
(stop #~(make-kill-destructor)))))))
(define guix-potluck-service-type
(service-type (name 'guix-potluck)
(extensions
(list (service-extension activation-service-type
guix-potluck-activation-service)
(service-extension shepherd-root-service-type
guix-potluck-shepherd-service)
(service-extension account-service-type
(const %guix-potluck-accounts))))))
(define %gc-job
;; The garbage collection mcron job, once per day.
#~(job '(next-hour '(4))
(string-append #$guix "/bin/guix gc -F80G")))
(define %certbot-job
;; Attempt to renew the Let's Encrypt certificate twice a week.
#~(job (lambda (now)
(next-day-from (next-hour-from now '(3))
'(2 5)))
(string-append #$certbot "/bin/certbot renew")))
;;;
;;; NGINX.
;;;
(define %nginx-config
;; Our nginx configuration directory. It expects 'guix publish' to be
;; running on port 3000.
(computed-file
"nginx-config"
#~(call-with-output-file #$output
(lambda (port)
(format port "
# This is the nginx config file for guix-potluck.org.
user nginx;
worker_processes 2;
pid /var/run/nginx.pid;
error_log /var/log/nginx/error.log error;
events {
worker_connections 768;
# multi_accept on;
}
http {
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip off;
# We need to specify all these or nginx picks its own directory to
# store them, which doesn't work because the store is read-only.
client_body_temp_path /var/run/nginx/body;
proxy_temp_path /var/run/nginx/proxy;
fastcgi_temp_path /var/run/nginx/fastcgi;
uwsgi_temp_path /var/run/nginx/uwsgi;
scgi_temp_path /var/run/nginx/scgi;
# Use HTTP 1.1 to talk to the backend so we benefit from
# keep-alive connections and chunked transfer encoding. The
# latter allows us to make sure we do not cache partial downloads.
proxy_http_version 1.1;
server {
listen 80;
server_name guix-potluck.org;
# For use by Certbot.
location /.well-known { root /var/www; }
# Otherwise redirect to HTTPS.
location / { return 301 https://$host$request_uri; }
}
server {
listen 443 ssl;
server_name guix-potluck.org;
ssl on;
ssl_certificate /etc/letsencrypt/live/guix-potluck.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/guix-potluck.org/privkey.pem;
ssl_session_timeout 5m;
ssl_protocols TLSv1.2;
ssl_ciphers \"HIGH:!DSS:!aNULL@STRENGTH\";
ssl_prefer_server_ciphers on;
location / { proxy_pass http://127.0.0.1:8080/; }
location ~~ /git(/.*) {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME ~a/libexec/git-core/git-http-backend;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param GIT_HTTP_EXPORT_ALL \"\";
fastcgi_param GIT_PROJECT_ROOT /srv/git;
fastcgi_param PATH_INFO $1;
}
}
}
" #$git)))))
(define %nginx-mime-types
;; Provide /etc/nginx/mime.types (and a bunch of other files.)
(simple-service 'nginx-mime.types
etc-service-type
`(("nginx" ,(file-append nginx "/share/nginx/conf")))))
(define %nginx-cache-activation
;; Make sure /var/cache/nginx exists on the first run.
(simple-service 'nginx-/var/cache/nginx
activation-service-type
(with-imported-modules '((guix build utils))
#~(begin
(use-modules (guix build utils))
(mkdir-p "/var/cache/nginx")))))
(operating-system
(host-name "guix-potluck")
(timezone "Europe/Berlin")
(locale "en_US.UTF-8")
;; Assuming /dev/sdX is the target hard disk, and "my-root" is
;; the label of the target root file system.
(bootloader (grub-configuration (device "/dev/vda")))
(file-systems (cons (file-system
(device "/dev/vda1")
(mount-point "/")
(type "ext4"))
%base-file-systems))
;; This is where user accounts are specified. The "root"
;; account is implicit, and is initially created with the
;; empty password.
(users (cons (user-account
(name "wingo")
(group "users")
;; Adding the account to the "wheel" group
;; makes it a sudoer.
(supplementary-groups '("wheel"))
(home-directory "/home/wingo"))
%base-user-accounts))
;; Globally-installed packages.
(packages (cons* git guile-json gnutls openssh certbot nss-certs %base-packages))
(services (cons* (static-networking-service "eth0" "46.101.231.54"
#:netmask "255.255.192.0"
#:gateway "46.101.192.1"
#:name-servers '("8.8.8.8" "8.8.4.4"))
(nginx-service #:config-file %nginx-config)
%nginx-mime-types
%nginx-cache-activation
(service fcgiwrap-service-type
(fcgiwrap-configuration))
(service guix-potluck-service-type
(guix-potluck-configuration))
(service openssh-service-type
(openssh-configuration
(permit-root-login 'without-password)))
(service mcron-service-type
(mcron-configuration
(jobs (list %gc-job %certbot-job))))
%base-services)))
Hi! You scrolled down all this way, congratulations!
So, remaining tasks to do:
(1) All of this is currently in a WIP branch, wip-potluck. I need to
submit to upstream. It needs some documentation too.
(2) The host-channel facilities run user-supplied Scheme code. To do
so safely, that needs sandbox facilities from Guile. That will
need Guile 2.2.1. For the time being I have disabled the server.
(3) Someone needs to design and implement a "guix channel" facility to
take advantage of this branch :) Until then, GUIX_PACKAGE_PATH
and the -L argument are the things to use.
(4) Probably we need a story about what happens when Guix updates. We
can compile target repositories for Guix dev and also for Guix
stable branches, understanding that maybe packages move around to
different modules during Guix development.
(5) We need the main https://guix-potluck.org/ to show progress on the
work queue.
(6) We will need better facilities for updating potluck packages to
new repository versions. Maybe this is what "guix package update"
should do and the notify-the-server thing should be called
something else.
I think that's it though for an MVP. What do yall think?
Cheers,
Andy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: potluck in the house
2017-04-13 13:25 potluck in the house Andy Wingo
@ 2017-04-13 15:42 ` Ludovic Courtès
2017-04-13 16:20 ` Andy Wingo
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2017-04-13 15:42 UTC (permalink / raw)
To: Andy Wingo; +Cc: guix-devel
Hi!
Andy Wingo <wingo@igalia.com> skribis:
> This is an update on "guix potluck", an attempt to support a more
> decentralized way of developing Guix packages, as a complement to the
> main package set.
>
> I have a number of packages that I never packaged for external use, at
> least beyond putting them in a git repo somewhere. Here's an example of
> packaging one of these with guix potluck. Guile-Present is a library
> that lets you write presentations in Texinfo and uses Cairo to render
> nthat to slides.
Turns out Guile-Present is already in Guix proper, but Guile-JPEG isn’t!
:-)
> I dug up the repo and pushed it to gitlab at
> https://gitlab.com/wingo/guile-present. Then in the root directory of
> that checkout I ran:
>
> guix potluck init
>
> and it carps, saying
>
> guix potluck init: wrong number of arguments
> usage: guix potluck init [OPT...] REMOTE-GIT-URL
> Try 'guix potluck --help' for more information.
>
> If you run help you see you need a URL for the public git repo. Cool, I
> have that:
>
> guix potluck init https://gitlab.com/wingo/guile-present
>
> Now it says:
>
> guix potluck: error: init: missing --build-system; try --build-system=help for options
[...]
> guix potluck init --autotools --license=lgpl3+ https://gitlab.com/wingo/guile-present
>
> And voilà:
>
> Cloning into '/tmp/guix-directory.861r57/git-checkout'... done.
> Creating guix-potluck/
> Creating guix-potluck/README.md
> Creating guix-potluck/guile-present.scm
>
> Done. Now open guix-potluck/guile-present.scm in your editor, fill out its "synopsis"
> and "description" fields, add dependencies to the 'inputs' field, and try to
> build with
>
> guix build --file=guix-potluck/guile-present.scm
>
> When you get that working, commit your results to git via:
>
> git add guix-potluck && git commit -m 'Add initial Guix potluck files.'
>
> Once you push them out, add your dish to the communal potluck by running:
>
> guix potluck update https://gitlab.com/wingo/guile-present master
Pretty cool! I’m sure some of this could make sense for generic Guix
packages too.
> It builds, which is pretty cool. (The wip-potluck branch extends guix
> build -f to recognize potluck packages.)
Oh I see, I was wondering why that was working. :-)
Maybe we could have ‘guix potluck build’ or something?
> By default it connects to guix-potluck.org; you can use --host to
> specify a different host. All connections to the potluck host are over
> HTTPS. OK it spews some trash on stdout:
>
> ERROR: In procedure get-bytevector-n:
> ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum The TLS connection was non-properly terminated.> read_from_session_record_port)'.
>
> I don't understand this entirely; shouldn't nginx be terminating things
> fine? I have never used the HTTP client with HTTPS though.
We’d have to debug it, but (guix build download) works fine.
> Anyway, fine. So the server received this request, checked out that git
> repo and branch, looked for potluck packages in guix-potluck/, and added
> those packages to a "source" git repo:
Woow, that’s the really cool part.
> (define-module (gnu packages potluck https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present master guile-present)
> #:pure
> #:use-module ((guile) #:select (list quote define-public))
> #:use-module ((guix packages) #:select (package origin base32))
> #:use-module ((guix git-download) #:select (git-fetch git-reference))
> #:use-module ((guix licenses) #:select ((lgpl3+ . license:lgpl3+)))
> #:use-module ((guix build-system gnu) #:select (gnu-build-system))
> #:use-module ((gnu packages pkg-config) #:select (%pkg-config))
> #:use-module ((gnu packages texinfo) #:select (texinfo))
> #:use-module ((gnu packages autotools) #:select (libtool automake autoconf))
> #:use-module ((gnu packages gtk) #:select (guile-cairo))
> #:use-module ((gnu packages guile) #:select (guile-lib guile-2.0)))
Since #:select doesn’t play well with circular dependencies among
modules, we should probably avoid it for the (gnu packages potluck …)
modules.
Also, I wonder if this should use ‘specification->package’ for packages
provided by Guix?
> Now this git repo should be able to be added to the GUIX_PACKAGE_PATH.
> It's effectively a "channel" managed by "guix potluck host-channel"
> running on guix-potluck.org. If you have a checkout of this repo, you
> can build Guile-Present just via "guix build -L /path/to/target/checkout
> guile-jpeg". Pretty cool, right??!!!?!?!
Pretty cool, indeed!
The nice thing is that we can pretty much unleash it on Guile users very
soon!
> Incidentally here is the configuration for that server:
We should add a potluck server service in GuixSD, too, so that this
config can be shrinked, and to make it easier to run a potluck server.
> Hi! You scrolled down all this way, congratulations!
>
> So, remaining tasks to do:
>
> (1) All of this is currently in a WIP branch, wip-potluck. I need to
> submit to upstream. It needs some documentation too.
>
> (2) The host-channel facilities run user-supplied Scheme code. To do
> so safely, that needs sandbox facilities from Guile. That will
> need Guile 2.2.1. For the time being I have disabled the server.
Given that ‘potluck-package’ is very declarative, I was wondering
whether it would be simpler to simply interpret it as data (have a
‘potluck-sexp->package’ compiler), as opposed to setting up a sandbox
with a white-list of bindings. Of course inert data is not as nice as
something programmable, but in this case it looks like users would not
really depart from what the default template. Thoughts?
Anyway, that’s really an “implementation detail.”
> (3) Someone needs to design and implement a "guix channel" facility to
> take advantage of this branch :) Until then, GUIX_PACKAGE_PATH
> and the -L argument are the things to use.
>
> (4) Probably we need a story about what happens when Guix updates. We
> can compile target repositories for Guix dev and also for Guix
> stable branches, understanding that maybe packages move around to
> different modules during Guix development.
>
> (5) We need the main https://guix-potluck.org/ to show progress on the
> work queue.
>
> (6) We will need better facilities for updating potluck packages to
> new repository versions. Maybe this is what "guix package update"
> should do and the notify-the-server thing should be called
> something else.
>
> I think that's it though for an MVP. What do yall think?
I think it’s awesome, and the development pace is impressive.
I was wondering about #1 and whether it should be in Guile or in Guix,
but it’s probably technically more convenient to keep it in Guix.
Now, I realize that none of it is Guile-specific, is it? So there’s the
question of the effect it can have on contributions to Guix proper.
It’s probably OK as long as there’s enough value in using the reviewed
packages that are in Guix itself. Thoughts?
Thank you!
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: potluck in the house
2017-04-13 15:42 ` Ludovic Courtès
@ 2017-04-13 16:20 ` Andy Wingo
2017-04-14 12:54 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Andy Wingo @ 2017-04-13 16:20 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hi :)
On Thu 13 Apr 2017 17:42, ludo@gnu.org (Ludovic Courtès) writes:
> Turns out Guile-Present is already in Guix proper, but Guile-JPEG isn’t!
> :-)
Oh neat :)
>> (The wip-potluck branch extends guix build -f to recognize potluck
>> packages.)
>
> Oh I see, I was wondering why that was working. :-)
>
> Maybe we could have ‘guix potluck build’ or something?
We could, but I was getting a bit overloaded with all the config options
you might want (substitutes, grafts, input replacements, etc) so I just
extended "build". To do so, you just have to make the environment in
which the file is loaded also have the "potluck-package" and
"potluck-source" bindings, and then add another special case along with
package? / derivation? / etc. WDYT? OK or not the right thing?
>> Anyway, fine. So the server received this request, checked out that git
>> repo and branch, looked for potluck packages in guix-potluck/, and added
>> those packages to a "source" git repo:
>
> Woow, that’s the really cool part.
>
>> (define-module (gnu packages potluck https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present master guile-present)
>> #:pure
>> #:use-module ((guile) #:select (list quote define-public))
>> #:use-module ((guix packages) #:select (package origin base32))
>> #:use-module ((guix git-download) #:select (git-fetch git-reference))
>> #:use-module ((guix licenses) #:select ((lgpl3+ . license:lgpl3+)))
>> #:use-module ((guix build-system gnu) #:select (gnu-build-system))
>> #:use-module ((gnu packages pkg-config) #:select (%pkg-config))
>> #:use-module ((gnu packages texinfo) #:select (texinfo))
>> #:use-module ((gnu packages autotools) #:select (libtool automake autoconf))
>> #:use-module ((gnu packages gtk) #:select (guile-cairo))
>> #:use-module ((gnu packages guile) #:select (guile-lib guile-2.0)))
>
> Since #:select doesn’t play well with circular dependencies among
> modules, we should probably avoid it for the (gnu packages potluck …)
> modules.
Is this still the case? With Guile 2.2 we fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15540 so maybe this isn't
a problem.
> Also, I wonder if this should use ‘specification->package’ for packages
> provided by Guix?
It certainly could, and indeed it could do so for all packages.
Currently it uses specification->package only if it can't resolve the
module in which a package is exported at compile-time. I think this
probably leads to better run-time overhead when the files are compiled
to .go and a package graph that makes more sense but I don't know.
>> Now this git repo should be able to be added to the GUIX_PACKAGE_PATH.
>> It's effectively a "channel" managed by "guix potluck host-channel"
>> running on guix-potluck.org. If you have a checkout of this repo, you
>> can build Guile-Present just via "guix build -L /path/to/target/checkout
>> guile-jpeg". Pretty cool, right??!!!?!?!
>
> Pretty cool, indeed!
>
> The nice thing is that we can pretty much unleash it on Guile users very
> soon!
Guix users I guess you mean? :) There is of course nothing
Guile-specific in this facility. But yeah as a solution to the Guile
"CPAN problem", yes definitely!
>> Incidentally here is the configuration for that server:
>
> We should add a potluck server service in GuixSD, too, so that this
> config can be shrinked, and to make it easier to run a potluck server.
Yes, and improve the nginx configuration, and add a fcgiwrap service,
and add a git http service... :)
>> (2) The host-channel facilities run user-supplied Scheme code. To do
>> so safely, that needs sandbox facilities from Guile. That will
>> need Guile 2.2.1. For the time being I have disabled the server.
>
> Given that ‘potluck-package’ is very declarative, I was wondering
> whether it would be simpler to simply interpret it as data (have a
> ‘potluck-sexp->package’ compiler), as opposed to setting up a sandbox
> with a white-list of bindings. Of course inert data is not as nice as
> something programmable, but in this case it looks like users would not
> really depart from what the default template. Thoughts?
>
> Anyway, that’s really an “implementation detail.”
Yeah I don't know. I thought that would maybe be good but then it's
also kinda cool that we provide a capability for abstraction in these
package definitions. I can imagine interesting extensions given that
it's a programming language rather than data. And this way we do take
advantage of cheap syntax checking via macros, pushing people to program
Scheme, and it's nice to be able to paste these definitions into a REPL
too... and we certainly want the record type!
I see what you are saying but since it doesn't seem to be necessary I am
tempted to punt, given that we can get Guix-on-Guile-2.2.1 out very soon
(a couple weeks maybe?).
> Now, I realize that none of it is Guile-specific, is it? So there’s the
> question of the effect it can have on contributions to Guix proper.
> It’s probably OK as long as there’s enough value in using the reviewed
> packages that are in Guix itself. Thoughts?
Yes I wonder about this. I think overall it would increase the speed at
which packages go upstream to Guix, because people can have a feel that
a package is well-tested in a channel and when they start to depend on
it they want it upstream. It's possible that some packages go the other
way (especially packages with few users and no depending packages) but I
suspect that the majority of flow will go Guix-ward. And it's nice to
know that you have a working package definition produced by a machine --
there are many automation possibilities to make review easier.
I don't understand the dependency situation though. What happens when
someone makes a glibc potluck package? That wouldn't affect the static
links in Guix deps but it might affect the command line, depending on
how we make it happen.
I think we should make it so that the lower-potluck-package process
prefers "core" packages if available, and only goes to the channel if
the core does not provide a package matching the specification.
I think this is a question for the design of channels though: how to
resolve dynamically scoped (specification->package) links in the
presence of channels.
Andy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: potluck in the house
2017-04-13 16:20 ` Andy Wingo
@ 2017-04-14 12:54 ` Ludovic Courtès
2017-04-18 6:49 ` Andy Wingo
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2017-04-14 12:54 UTC (permalink / raw)
To: Andy Wingo; +Cc: guix-devel
Hi!
Andy Wingo <wingo@igalia.com> skribis:
> On Thu 13 Apr 2017 17:42, ludo@gnu.org (Ludovic Courtès) writes:
[...]
>>> (The wip-potluck branch extends guix build -f to recognize potluck
>>> packages.)
>>
>> Oh I see, I was wondering why that was working. :-)
>>
>> Maybe we could have ‘guix potluck build’ or something?
>
> We could, but I was getting a bit overloaded with all the config options
> you might want (substitutes, grafts, input replacements, etc) so I just
> extended "build". To do so, you just have to make the environment in
> which the file is loaded also have the "potluck-package" and
> "potluck-source" bindings, and then add another special case along with
> package? / derivation? / etc. WDYT? OK or not the right thing?
That sounds like a small change to ‘guix build’ so maybe it’s OK after
all. I’ll check the actual patch later.
>> Since #:select doesn’t play well with circular dependencies among
>> modules, we should probably avoid it for the (gnu packages potluck …)
>> modules.
>
> Is this still the case? With Guile 2.2 we fixed
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15540 so maybe this isn't
> a problem.
Oh right, awesome!
>> Also, I wonder if this should use ‘specification->package’ for packages
>> provided by Guix?
>
> It certainly could, and indeed it could do so for all packages.
> Currently it uses specification->package only if it can't resolve the
> module in which a package is exported at compile-time. I think this
> probably leads to better run-time overhead when the files are compiled
> to .go and a package graph that makes more sense but I don't know.
Probably we can fine-tune that as we go. Doing ‘specification->package’
at run time instead of compile-time would decouple things a bit more,
but maybe that’s overkill, maybe not, we’ll see.
>> We should add a potluck server service in GuixSD, too, so that this
>> config can be shrinked, and to make it easier to run a potluck server.
>
> Yes, and improve the nginx configuration, and add a fcgiwrap service,
> and add a git http service... :)
Right. We do have ‘git-daemon-service’, not sure if that’s what you
meant.
>>> (2) The host-channel facilities run user-supplied Scheme code. To do
>>> so safely, that needs sandbox facilities from Guile. That will
>>> need Guile 2.2.1. For the time being I have disabled the server.
>>
>> Given that ‘potluck-package’ is very declarative, I was wondering
>> whether it would be simpler to simply interpret it as data (have a
>> ‘potluck-sexp->package’ compiler), as opposed to setting up a sandbox
>> with a white-list of bindings. Of course inert data is not as nice as
>> something programmable, but in this case it looks like users would not
>> really depart from what the default template. Thoughts?
>>
>> Anyway, that’s really an “implementation detail.”
>
> Yeah I don't know. I thought that would maybe be good but then it's
> also kinda cool that we provide a capability for abstraction in these
> package definitions. I can imagine interesting extensions given that
> it's a programming language rather than data. And this way we do take
> advantage of cheap syntax checking via macros, pushing people to program
> Scheme, and it's nice to be able to paste these definitions into a REPL
> too... and we certainly want the record type!
>
> I see what you are saying but since it doesn't seem to be necessary I am
> tempted to punt, given that we can get Guix-on-Guile-2.2.1 out very soon
> (a couple weeks maybe?).
OK, sounds reasonable.
>> Now, I realize that none of it is Guile-specific, is it? So there’s the
>> question of the effect it can have on contributions to Guix proper.
>> It’s probably OK as long as there’s enough value in using the reviewed
>> packages that are in Guix itself. Thoughts?
>
> Yes I wonder about this. I think overall it would increase the speed at
> which packages go upstream to Guix, because people can have a feel that
> a package is well-tested in a channel and when they start to depend on
> it they want it upstream. It's possible that some packages go the other
> way (especially packages with few users and no depending packages) but I
> suspect that the majority of flow will go Guix-ward. And it's nice to
> know that you have a working package definition produced by a machine --
> there are many automation possibilities to make review easier.
>
> I don't understand the dependency situation though. What happens when
> someone makes a glibc potluck package? That wouldn't affect the static
> links in Guix deps but it might affect the command line, depending on
> how we make it happen.
Currently the CLI would report that “glibc” is ambiguous and pick one at
random. :-)
But yeah, there’s the question of what the potluck server should accept.
Should it reject dishes with a name that clashes with already-available
packages? If it does, how closely should it keep track of Guix?
> I think we should make it so that the lower-potluck-package process
> prefers "core" packages if available, and only goes to the channel if
> the core does not provide a package matching the specification.
>
> I think this is a question for the design of channels though: how to
> resolve dynamically scoped (specification->package) links in the
> presence of channels.
‘specification->package’ already transparently handles things in
GUIX_PACKAGE_PATH, so I suspect it wouldn’t be very different.
WDYT?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: potluck in the house
2017-04-14 12:54 ` Ludovic Courtès
@ 2017-04-18 6:49 ` Andy Wingo
2017-04-19 20:27 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Andy Wingo @ 2017-04-18 6:49 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Fri 14 Apr 2017 14:54, ludo@gnu.org (Ludovic Courtès) writes:
>> I think we should make it so that the lower-potluck-package process
>> prefers "core" packages if available, and only goes to the channel if
>> the core does not provide a package matching the specification.
>>
>> I think this is a question for the design of channels though: how to
>> resolve dynamically scoped (specification->package) links in the
>> presence of channels.
>
> ‘specification->package’ already transparently handles things in
> GUIX_PACKAGE_PATH, so I suspect it wouldn’t be very different.
>
> WDYT?
I don't know. I see a danger if person A makes a potluck package for
that depends on Guile, and person B makes a potluck package for some
development version of Guile with a later version number. Person A (and
person A's users) probably don't expect to be using a development
Guile, so the specifications in person A's package should probably *not*
resolve person B's guile as the "best" one. See what I'm saying?
Tricky stuff. A hierarchy of potential sources sounds best to me so
that specification->package only looks for "guile" in the potluck
GUIX_PACKAGE_PATH if it's not found (possibly with the version
constraint) in the "main" GUIX_PACKAGE_PATH.
Andy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: potluck in the house
2017-04-18 6:49 ` Andy Wingo
@ 2017-04-19 20:27 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2017-04-19 20:27 UTC (permalink / raw)
To: Andy Wingo; +Cc: guix-devel
Andy Wingo <wingo@igalia.com> skribis:
> On Fri 14 Apr 2017 14:54, ludo@gnu.org (Ludovic Courtès) writes:
>
>>> I think we should make it so that the lower-potluck-package process
>>> prefers "core" packages if available, and only goes to the channel if
>>> the core does not provide a package matching the specification.
>>>
>>> I think this is a question for the design of channels though: how to
>>> resolve dynamically scoped (specification->package) links in the
>>> presence of channels.
>>
>> ‘specification->package’ already transparently handles things in
>> GUIX_PACKAGE_PATH, so I suspect it wouldn’t be very different.
>>
>> WDYT?
>
> I don't know. I see a danger if person A makes a potluck package for
> that depends on Guile, and person B makes a potluck package for some
> development version of Guile with a later version number. Person A (and
> person A's users) probably don't expect to be using a development
> Guile, so the specifications in person A's package should probably *not*
> resolve person B's guile as the "best" one. See what I'm saying?
> Tricky stuff. A hierarchy of potential sources sounds best to me so
> that specification->package only looks for "guile" in the potluck
> GUIX_PACKAGE_PATH if it's not found (possibly with the version
> constraint) in the "main" GUIX_PACKAGE_PATH.
Indeed, good point. We should have a way to say that some channels have
precedence over other channels.
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-19 20:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-13 13:25 potluck in the house Andy Wingo
2017-04-13 15:42 ` Ludovic Courtès
2017-04-13 16:20 ` Andy Wingo
2017-04-14 12:54 ` Ludovic Courtès
2017-04-18 6:49 ` Andy Wingo
2017-04-19 20:27 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.