Re: Verification Builds for Guix

[zimoun <zimon.toutoune@gmail.com>]

Dear,

I do not know if it is relevant and if it completes what janneke already said.


On Wed, 13 May 2020 at 08:54, Jan Nieuwenhuizen <janneke@gnu.org> wrote:

> > Checking out the packages part of the website I found that there is at
> > least an CI creating binaries. Are those also offered to users?

The build farm (by default) is reachable at [1] and it offers binary
substitutes.  Another entry point is Guix Data Service [1] which
collects data about packages, builds, branches, etc.; for example the
history of versions [3] or the status of builds [4].  Moreover, there
is a recent proposal: build-coordinator [5].

[1] https://ci.guix.gnu.org/
[2] http://data.guix.gnu.org/
[3] https://data.guix.gnu.org/repository/1/branch/master/package/git
[4] https://data.guix.gnu.org/repository/1/branch/master/package/git/output-history?output=out&system=armhf-linux&target=none
[5] https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00323.html


> This hash includes the transitive dependencies and can be calculated
> without compiling anything.  The "binary package", once built, will be
> installed using this hash, e.g.:
> "/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2".

This hash identifies the package and the transitive dependencies, so
the hash is an unique identifier (modulo hash collisions which are
another story).
The same hash should produce the same binary or there is source of
non-determinism.  That's why "guix build --check" rebuilds and compare
the two builds.

I do not know what is the policy on the build farm ci.guix.gnu.org
about checking the rebuild.


> Guix does have the "guix challenge" command
>
> --8<---------------cut here---------------start------------->8---
> guix challenge --help
> Usage: guix challenge [PACKAGE...]
> Challenge the substitutes for PACKAGE... provided by one or more servers.
>
>       --substitute-urls=URLS
>                          compare build results with those at URLS
> --8<---------------cut here---------------end--------------->8---
>
> now the trick is, to get "someone" to run that on an interesting portion
> of the archive...and to report the results in some common format.

I am not aware of such initiative.  Which should be really cool.

On the other hand, using this information of challenging the local
builds against remote builds would allow to share /gnu/store/; other
said full distributed substitutes mechanism.



Best regards,
simon