Last updated Nov 25th, 2019
Overview
With initial Guix building support having landed in #15277, we should start thinking about what features are lacking, and which ones are required for a transition of our release process to Guix.
ATTN: I’m actively looking for feedback on this, please don’t hesitate to ask for clarification or propose changes!
Open PR chains
Features
Prerequisites for Release Process transition
- Non-Linux cross-compilation
- OS X
- x86_64-apple-darwin14
- Windows
- x86_64-w64-mingw32
- OS X
- Signing and verification
- Inferiors (reproducibility across time) #16519
- Filesystem channels (Guix upstream feature)
- Guix release process documentation
Nice-to-have’s
- APT repository for Guix itself
- Finer-grain documentation of compiler/glibc/linux-header versions
-
guix environmentas a single-command development setup tool - Guix importer for depends syntax
- Backup plan for releases if all depends download sources are down
Details and Notes
Non-Linux cross-compilation
OS X
Our native_cctools package in depends assumes that the base system is Ubuntu, and downloads a binary clang. There needs to be a way to use a system-supplied clang. It seems that forks of Bitcoin Core already have that functionality, so it should be back ported: #15277 (comment)
depends PR Open Oct 10th, 2019: #17099
Windows
Porting NSIS to Guix was somewhat difficult the last time I attempted it, mostly because I don’t know scons that well and NSIS doesn’t have great compilation documentation.
Update Aug 9th, 2019: #16496 (comment) PR Open Nov 25th, 2019: #17595
Signing and verification
I looked briefly into signify, but decided that we don’t want to put the burden of extra key material on maintainers. Current thought is that a clear signature of the find output/ -type f -print0 | sort -z | xargs -r0 sha256sum might be sufficient.
Inferiors
Work has mostly been finished on my branch here: https://github.com/bitcoin/bitcoin/compare/master...dongcarl:2019-06-guix-channels-and-inferiors (commit-ish permalink)
I did some thorough testing of the inferiors infrastructure with this branch and found a bug, reported here: https://issues.guix.gnu.org/issue/36777
Luckily we were able to bisect where the error was introduced and lead Guix maintainers are actively helping with this issue.
PR Open Aug 1st, 2019: #16519 Resolved upstream Aug 16th, 2019: https://issues.guix.gnu.org/issue/36777#7
Filesystem channels
A Guix channel is like a debian APT repository but more powerful. Right now in my branch, we use my bitcoin-guix channel (seen here) which supplies all of the bitcoin-specific toolchain packages, as seen here.
I’d much prefer to embed this channel into the bitcoin repository, but right now Guix channels can only refer to git repositories. After asking on IRC, this seems like a feature that the other Guix maintainers want as well, so it should be implemented and used.
Update Nov 25th, 2019: :man_shrugging: Let’s just use https://github.com/bitcoin-core/packaging
APT repository for Guix itself
A debian maintainer Vagrant Cascadian has done most of the heavy-lifting here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850644, however, he warned me that it might be a while before it gets into debian proper, so we could have an APT repository for Guix to make the installation process for Guix easier.
Finer-grain documentation of compiler/glibc/linux-header versions
Right now we are using:
0gcc-9
1glibc-2.27
2linux-libre-headers-4.19
This can be verified here. We can now explicitly document this, as it won’t change at the whim of Ubuntu developers. (motivating example)
guix environment as a single-command development setup tool
Right now, on any machine with guix installed, guix environment --manifest=contrib/guix/manifest.scm sets up a native build environment for depends. I would like to extend this to also be able to setup a cross-build environment. And with “Guix importer for depends syntax”, guix environment --manifest=contrib/guix/manifest.scm can even build the dependencies.
Guix importer for depends syntax
AFAIK @nothingmuch has gotten started on this. It will allow for automatic generation of Guix package definitions of our depends packages so that we can maintain a single source of truth but get the caching/inferior/etc. benefits of native Guix packages.
