[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
01/01: website: reproducible-build-summit-2019: Expand a couple of secti
01/01: website: reproducible-build-summit-2019: Expand a couple of sections.
Sun, 15 Dec 2019 18:21:30 -0500 (EST)
cbaines pushed a commit to branch master
in repository guix-artwork.
Author: Christopher Baines <address@hidden>
Date: Sun Dec 15 23:16:39 2019 +0000
website: reproducible-build-summit-2019: Expand a couple of sections.
* website/drafts/reproducible-build-summit-2019.md (author): Add
[Verifying and sharing build results]: Link to the Guix Data Service
Git repo, and add a paragraph about Bernhard's new site in planning.
[Guix Data Service]: Don't use HTTPS for bayfront, as the certificate
isn't quite right. Work my summary of the changes in to the existing
website/drafts/reproducible-build-summit-2019.md | 42 +++++++++++++++++-------
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/website/drafts/reproducible-build-summit-2019.md
index 28022bb..40ec627 100644
@@ -1,6 +1,6 @@
title: Reproducible Builds Summit, 5th edition
date: 2019-11-12 14:00
-author: Ludovic Courtès, Jan Nieuwenhuizen, Andreas Enge, YOUR NAME HERE!
+author: Ludovic Courtès, Jan Nieuwenhuizen, Andreas Enge, Christopher Baines,
YOUR NAME HERE!
tags: Reproducible builds
@@ -66,7 +66,14 @@ We have discussed a file format (probably based on JSON)
help to separate the process of creating the reproducibility information
from collecting, evaluating and displaying it. From a Guix point of view,
the idea would be to have the website communicate with an instance of
-the Guix Data Service.
+the [Guix Data
+Additionally, Bernhard started a discussion about a possible new site
+to easily show for a package, if it builds reproducibly in different
+distributions, this is mentioned on [this post about the
+This would probably also consume some data about the reproducibility
+of packages within Guix from the Guix Data Service.
# Guix Data Service
@@ -76,20 +83,31 @@ can serve to collect data from a number of independent
Guix build farms (of which we currently have two, the farm behind
[ci.guix.gnu.org](https://ci.guix.gnu.org/), and the farmlet of one or two
Meeting in person was the occasion to update the bayfront configuration
to mimic more closely that of ci; in particular, the build farm results
are now exported to the web frontend.
-We had quite some discussion (so far without conclusion) about the exact
-boundaries between the Cuirass and the Guix Data Service: should the former
-only be a thin layer on top of the Guix daemon with the latter processing
-all the data towards a web frontend, or should Cuirass continue to handle
-its own web page? In any case, Chris worked tirelessly in all free moments
-to get the Guix Data Service into good shape, and as a result we can
-already compare build results and check for reproducibility between the
-two build farms
-TODO: Add a [link to](https://data.guix.gnu.org), or what it is called.
+We had quite some discussion (so far without conclusion) about the
+exact boundaries between the
+the [Guix Data
+should the former only be a thin layer on top of the Guix daemon with
+the latter processing all the data towards a web frontend, or should
+Cuirass continue to handle its own web page?
+While the Guix Data Service is not currently running at
+data.guix.gnu.org as the server is down for maintenance, lots of
+progress was made with the code. Information about [normalized
+such as package binaries, that are provided by [substitute
+can now be imported and stored in the database, and the ability to
+fetch and store builds from Cuirass has been improved. This is
+building towards being able to automatically and continuously track
+the reproducibility of Guix packages.