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

Project ideas for Guix and GuixSD

Aarch64 (ARM64) port

Port Guix to Arm64! See the porting instructions.

Possible mentors: Ludovic

RISCV port

Port Guix to RISCV! 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

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.

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.

Other ideas

Work on packaging GNU Ring. What is stopping this are the patches.

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 Fibers or maybe 8sync.

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

Project ideas for Cuirass

Cuirass is a build automation server using Guix.

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 Guile modules that would make it possible to have similar CI jobs written using Cuirass. Currently, useful support is limited to dist-package and (guix build gnu-dist), which facilitate the creation of jobs that run 'make distcheck'.