Planet Guix

Introducing functions and modules in Guile Scheme and Guix

Now and then I find myself having to open a file or an application that I don't fully trust. A common technique to deal with this is to create a disposable environment (for example a so-called container or a virtual machine) where the file or application can be safely opened. Once used, the environment can be discarded.

Guix package structure: build-system overview build arguments

With the release of Libntlm version 1.8 the release tarball can be reproduced on several distributions. We also publish a signed minimal source-only tarball, produced by git-archive which is the same format used by Savannah, Codeberg, GitLab, GitHub and others. Reproducibility of both tarballs are tested continuously for regressions on GitLab through a CI/CD pipeline. If that wasn’t enough to excite you, the Debian packages of Libntlm are now built from the reproducible minimal source-only tarball. The resulting binaries are reproducible on several architectures.

We built GCC 4.6.4 with RISC-V support and C++ and all that and we made it run in Guix, finally.

We’ve got sidetracked, but it doesn’t really matter if we continue forward.

Guix package structure: inputs, native-inputs and propagated-inputs

tl;dr: If you use WireGuard, make sure NTP (or a similar time synchronisation mechanism) is set up on all VPN endpoints as the WireGuard protocol is sensitive to time-sync issues. Also, if you connect to a WireGuard server in an IPv6 network, make sure the server's firewall has sufficiently permissive ICMPv6 rules. Read on to find out why this is important.

We built GCC 4.6.4 with RISC-V support and C++ and all that in a Debian machine, in a VisionFive board. Here is how.

Rebuilding software five years later, how hard can it be? It can’t be that hard, especially when you pride yourself on having a tool that can travel in time and that does a good job at ensuring reproducible builds, right?