●About
●About LibrePlanet
●Mission Statement
●Founding documents
●Support this Community
●Code of Conduct
●Anti-harassment policy
●Teams
●Activists
●Wiki Helpers
●LibrePlanet Artists
●FSF Community Team
●Local & Student Teams
●Conferences
●LibrePlanet Conference
●Non-official
●Get involved
●Participate
●Discussion channels
●Events
●Login
This page is for tracking ideas and process for participating in Google Summer of Code 2017.
Port Guix to Arm64! See the porting instructions.
Possible mentors:
Ludovic
Port Guix to RISCV! See the porting instructions.
Possible mentors:
Ludovic
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
Currently the build daemon of Guixiswritten 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, +...?)
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.
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.
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
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(, +...?)
Cuirass is a build automation server using Guix.
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'.
Mentors: Ludovic
Retrieved from "https://libreplanet.org/wiki?title=Group:Guix/GSoC-2017&oldid=42440"
The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom.
We defend the rights of all software users. (Read more)