-*- mode: org; coding: utf-8; -*- Copyright © 2012, 2013 Ludovic Courtès Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. * integrate needed Nix code ** Remove dependency on OpenSSL The ‘openssl’ command-line tool is used in libstore to sign store paths to be exported, and to check such signatures. The signing keys are usually in /etc/nix/signing-key.{pub,sec}. They are a PKCS#8-encoded X.509 SubjectPublicKeyInfo. These can be decoded with the [[http://lists.gnu.org/archive/html/help-gnutls/2012-12/msg00012.html][C API of GnuTLS]], but not yet with its Guile bindings. There’s also ‘gnutls_privkey_sign_data’ to sign, and related functions. ** Add `guix publish' to publish the store using Guile's web server Generate narinfos and nars on the fly, upon HTTP GET requests. Ideally, extend .nix-cache-info to include the server's public key, and also reply to requests for .narinfo.sig. Optionally, use Guile-Avahi to publish the service. ** MAYBE Add a substituter that uses the GNUnet DHT Would be neat if binaries could be pushed to and pulled from the GNUnet DHT. Guix users would sign their binaries, and define which binaries they trust. ** Add a remote build hook Like scripts/build-remote.pl in Nix. * infrastructure ** have a Hydra instance build Guix packages [[http://nixos.org/hydra/][Hydra]] is a continuous integration tool based on Nix. It now has [[https://github.com/NixOS/hydra/commit/f27ae1d5663680400cb99cfb898970f34d8d21be][Guile/Guix support]], which allows “build recipes” written in Guile using Guix to be used directly on Hydra. For a start, we may use the instance at hydra.nixos.org, generously provided by TU Delft. However, in the future, we may want to setup our own instance at gnu.org. * user interface ** Add a package.el (Emacs) back-end Unfortunately package.el is monolithic, so most likely we’d have to write a new one based on it, as opposed to actually using it. * extend ** add OpenPGP signatures: (origin (method http-fetch) (uri "http://.../foo.tgz") (signature-uri (string-append uri ".sig")) (signer-openpgp-fingerprint "...")) ** allow to be a derivation/package or a file * extend ** add support for ‘search-paths’ This should be passed to the build system, to extend package-specific search path environment variables–like ‘GUILE_LOAD_PATH’, ‘PERL5LIB’, etc. ** add a ‘user-environment-hook’ This should specify builder code to be run when building a user environment with ‘guix-package’. For instance, Texinfo’s hook would create a new ‘dir’. ** add ‘patches’ there ** extend ‘propagated-build-inputs’ with support for multiple outputs #+BEGIN_SRC scheme (outputs '("out" "include")) (propagated-build-inputs `(((("i1" ,p1 "o1") ("i2" ,p2)) => "include") ("i3" ,p3))) #+END_SRC * synchronize package descriptions with the [[http://directory.fsf.org][FSD]] and/or the Womb Meta-data for GNU packages, including descriptions and synopses, can be dumped from the FSD: http://directory.fsf.org/wiki?title=GNU/Export&action=purge . We could periodically synchronize with that. The [[./guix/gnu-maintenance.scm][Womb]] also contains synopses for all the GNU packages. * support cross-compilation Implement ‘package-cross-derivation’, and add the corresponding code in ‘gnu-build-system’. Then, actually bootstrap a cross-compilation environment–e.g., a cross-GNU environment. * add a guildhall build system The Guildhall is Guile’s packaging system. It should be easy to add a ‘guildhall-build-system’ that does the right thing based on guildhall recipes. * gnu-build-system: produce a ‘debug’ derivation Set a .gnu_debuglink in the main derivations to point to the sibling file name (only the basename, to not retain a dependency on the ‘debug’ derivation.) For /nix/store/xyz-foobar/bin/foo, we should have /nix/store/abc-foobar-debug/lib/nix/store/xyz-foobar/bin/foo.debug (info "(gdb) Separate Debug Files"). Users should have a default GDB setting with ~/.guix-profile/lib/debug as their ‘debug-file-directory’. * build-expression->derivation: define `%system' in the builder Would allow build expressions to have system-dependent code, like `glibc-dynamic-linker'. * add ‘allowed-references’ in [[file:~/src/nix/src/libstore/build.cc::if%20(drv.env.find("allowedReferences")%20!%3D%20drv.env.end())%20{][See how Nix implements that internally]]. * union Support sophisticated collision handling when building a union: check whether the colliding files are identical, honor per-package priorities, etc. * guix package ** add ‘--list-generations’, and ‘--delete-generations’ * guix build utils ** Add equivalent to Nixpkgs's ‘wrapProgram’ ** MAYBE Change ‘ld-wrapper’ to add RPATH for libs passed by file name ** MAYBE Add equivalent to chrpath, possibly using [[https://gitorious.org/guile-dlhacks/guile-dlhacks/][guile-dlhacks]] ** MAYBE Add a hash-rewriting thing for deep dependency replacement without rebuild See [[https://github.com/NixOS/nixpkgs/commit/d1662d715514e6ef9d3dc29f132f1b3d8e608a18][Shea Levy's `replace-dependency' in Nixpkgs]]. * distro ** port to new GNU/Linux platforms, notably ‘mipsel64-linux’ ** port to GNU/Hurd, aka. ‘i686-gnu’ Problems include that current glibc releases do not build on GNU/Hurd. In addition, there haven’t been stable releases of GNU Mach, MiG, and Hurd, which would be a pre-condition. ** make a bootable GNU/Linux-Libre distro, with OS configuration EDSL Similar in spirit to /etc/nixos/configuration.nix.