Group: Guix/GSoC-2016

This page is for tracking ideas and process for participating in Google Summer of Code 2016.

Project ideas for Guix and GuixSD

Installer wizard for GuixSD

A program that can be bundled with a bootable image which provides an "installer wizard" for the Guix System Distribution. This would walk users through partitioning, setting up users, etc, then set up the disk appropriately, write out the proper Guix system description file, and use it to build the first bootable version of the system.

This could use guile-ncurses, or maybe libRUIN, or maybe even some graphical toolkit.

Possible mentors:

Packages for foreign distributions

Packages for the guix package manager for Debian/Ubuntu, Fedora/Red Hat/CentOS, etc, to help users of these GNU/Linux distributions come up to speed with Guix much faster. Work to build these packages from within Guix (similar to how we build the "Guix from tarball" install medium). Build a Guix API for the building of Debian and etc packages.

 There is (used to be?) something in Nixpkgs that produces a derivation to build stuff in a Debian VM, build the .deb with CheckInstall, and return that .deb as the derivation’s output.  Something like this is definitely programming, and possibly fun as well.  :-)  -- Ludovic Courtès

Explore hosting "PPA" type resources within Guix's own resources, and work with upstream distributions to explore likelihood of Guix being packaged within those distributions.

Possible mentors:

Graphical package / system manager

Provide a GUI (ncurses, gtk, or something) for installing, upgrading, and rolling back a user's profile. Do the same for the system profile, and provide a way to configure the system.

Possible mentors:

Aarch64 (ARM64) port

Port Guix to Arm64! See the porting instructions.

Possible mentors: Ludovic

Guile based build-tool

Guile-based build tool for advanced software developers who do not want to deal with the complexity of multi-platform deployment and dependency hell. By default runs inside the GNU Guix build system and effectively replaces the likes of autotools, cmake, etc.

Build tools such as automake and cmake are complex beasts. What they try to do is target multiple build environments by generating make files using a complex list of string expansions. Complexity, in general, means hard to understand, change and maintain. The bad thing is that almost every software project has to deal with this complexity to make the software deployable.

What is wrong with these build tools? In short:

1. Complex - and therefore hard to understand and maintain

2. Simplistic language - simple string expansion systems are not nice and not DRY

3. Race conditions - make's time stamps are not suitable for building across servers

4. Different combinations of options are badly handled.

5. No intermediate representation

Alternatives, such as Java ant, Scala sbt, and Ruby rake, try to resolve similar issues but are specialised for their environments. Here we have a *fresh* start of a build tool which should ultimately be able to run complex workflows on multiple servers and make use of opportunistic execution, i.e. jobs may be distributed multiple times and the first one that comes back wins.

We primarily targets GNU Guix because Guix already solves the complexity of handling dependencies and software deployment. This simplifies things dramatically because the build system does not have to deal with platform or architecture targets. Even so, in time, we can target out of GNU Guix builds.

Mentors: Pjotr Prins and other Guix members

NPM package importer and builder

Building packages for npm is hard. Help make it easy!

Mentors:

Port GuixSD to GNU/Hurd

Make the proper modifications to Guix so it can handle and use the Hurd mechanisms (i.e subhurds, firmlinks instead of bind-mounts), isolate Linuxisms and produce a working GuixSD Hurd system.

Mentors: Ludovic (+ Justus, Samuel?)

Rewrite build daemon in Guile Scheme

Currently the build daemon of Guix is written in C++, inherited from Nix. It works fine but is not as hackable as we'd like, and has poor integration with the rest of Guix. For instance, the daemon calls out to the 'guix substitute', 'guix authenticate', and 'guix offload' commands, but its interface to these commands is very limited. Furthermore, a large part of the daemon's code is already implemented in Scheme: container functionality is available with 'call-with-container', archive creation is implemented in (guix nar), writing derivation files (.drv) is done in (guix derivations), and so on.

The goal of this project would be to rewrite the daemon in Guile Scheme using the building blocks already available. Important missing bits include the garbage collector and its scanner (which scans files for references to /gnu/store items), the scheduler, which schedules derivation builds in topological order, using the specified number of cores, etc.

Mentors: Ludovic (+ David, +...?)

Content-addressed protocol for substitutes

The goal of this project would be to reduce the amount of data that needs to be transferred when retrieving substitutes. The rationale and design idea is described in this message.

Adding modules in support of continuous integration

Currently, the NixOS project kindly offers to run continuous integration (CI) jobs at hydra.nixos.org for GNU packages, as explained here.

The goal would be to provide Guix modules that would make it possible to have similar CI jobs written using Guix. Currently, useful support is limited to dist-package and (guix build gnu-dist), which facilitate the creation of jobs that run 'make distcheck'.

Write a Bourne-shell compiler front-end for Guile

Guix relies on a set of bootstrap binaries (GCC, Binutils, libc, Bash, Coreutils, etc.) from which everything is built. These binaries must be trusted, so we'd rather have as few bootstrap binaries as possible.

The goal of this project is to build on Bournish, a simplistic Bourne-shell-like front-end to Guile's compiler, and extend it to support all the features needed to run a 'configure' script (including pipes, functions, and globbing), including features normally provided by sed, grep, find, and Coreutils. When that is done, a whole bunch of binaries can be removed from the bootstrap binaries.

Rewrite Hydra to be more integrated with Guix

Hydra is a Nix-based continuous build system which is used by Guix ([1]) to compile and distribute package substitutes and to check if packages are built successfully on different architectures. With time, nix-daemon and guix-daemon are evolving differently. Hydra being heavily dependent on nix-daemon, Guix is currently not able to use its newest versions. Moreover there are some performance issues in the current Guix infrastructure. that are unlikely to be solved considering the foreignness of Hydra Perl implementation to Guix hackers.

The idea of this project would be to write the basic building blocks composing a continuous build system in Guile Scheme in order improve Guix infrastructure parenthood.

Project ideas for the GNU Shepherd

Syntax and semantics of systemd units in the Shepherd

The GNU Shepherd has a Scheme interface to define services, most importantly their dependencies and actions associated with them. The goal of this project is twofold. The first part consists in matching the semantics of systemd's .service unit files, more precisely a subset thereof (for instance, the DBus-related part may be omitted.) As part of this work, the Shepherd should be extended with cgroup support on systems that support it. The Shepherd should also be extended with a procedure to load a .service file and return a <service> object.

The second part will consist in implementing other types of units, in particular socket activation and .device.

Mentors: Ludovic

Add an extensible event loop

As of version 0.3, the Shepherd uses a trivial event loop where it waits for connections from clients such as the 'herd' command and also, via Guile "system asyncs", waits for SIGCHLD signals corresopnding to the death of child processes. Thus, we assume that clients will not block, and we also expect the 'start' and 'stop' methods of each service (and in fact, each service action) to be non-blocking. Consequently, the Shepherd can only serve one client request at a time, and services are retricted in what they can do. For instance, it's currently impossible to have a REPL server in the Shepherd, unless resorting to multiple threads, which is not an option.

The goal of this project is to make the Shepherd rely on an extensible event loop. Services should be able to add file descriptors to watch or delays to wait for to the event loop. The event loop will avoid the "callback hell" by using either a monad (a monad is essentially "continuation-passing style", CPS, which is essentially "callbacks"), or by using delimited continuations, for instance via 8sync.

Mentors: Ludovic + Chris Webber(, +...?)