guix-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

02/02: website: reproducible-build-summit-2019: Add draft topics.


From: Andreas Enge
Subject: 02/02: website: reproducible-build-summit-2019: Add draft topics.
Date: Sun, 15 Dec 2019 12:24:34 -0500 (EST)

andreas pushed a commit to branch master
in repository guix-artwork.

commit 09462c5cfd35bfa2311aec9442028b4d2a7bebfe
Author: Andreas Enge <address@hidden>
Date:   Sun Dec 15 17:39:51 2019 +0100

    website: reproducible-build-summit-2019: Add draft topics.
    
    * website/drafts/reproducible-build-summit-2019.md: Add sections on Java
    and Android, the Guix Data Service and file formats for build information.
---
 website/drafts/reproducible-build-summit-2019.md | 74 ++++++++++++++++++++++--
 1 file changed, 68 insertions(+), 6 deletions(-)

diff --git a/website/drafts/reproducible-build-summit-2019.md 
b/website/drafts/reproducible-build-summit-2019.md
index 442b1b2..28022bb 100644
--- a/website/drafts/reproducible-build-summit-2019.md
+++ b/website/drafts/reproducible-build-summit-2019.md
@@ -1,6 +1,6 @@
 title: Reproducible Builds Summit, 5th edition
 date: 2019-11-12 14:00
-author: Ludovic Courtès, YOUR NAME HERE!
+author: Ludovic Courtès, Jan Nieuwenhuizen, Andreas Enge, YOUR NAME HERE!
 tags: Reproducible builds
 ---
 
@@ -22,12 +22,76 @@ life on the roof top of the lovely riad that was home to 
the summit.
 
 # Java
 
-  - F-Droid
-  - Maven
-  - ?
+Java is a notoriously difficult topic, as far as bootstrapping and
+reproducibility go.  For instance, [Gradle](https://gradle.org/)
+is now the most common tool
+for building Java code, and in particular Android apps. However, the
+current way of building Gradle is to use Gradle and a
+[build script](https://github.com/gradle/gradle/blob/master/build.gradle.kts)
+written in Kotlin.  The 
+[Kotlin](https://kotlinlang.org/)
+project, in turn, is also built using Gradle and a 
+[build 
script](https://github.com/JetBrains/kotlin/blob/master/build.gradle.kts)
+written in Kotlin.  So we end up with the _most cyclic_ graph one
+can imagine with two packages: a circle between the two, and two additional
+loops from the packages to themselves.  However, the Kotlin dependency
+of Gradle was introduced less than two years ago, so there is some hope we
+can disentangle the bootstrapping mess...
+
+Andreas took part in a session on bootstrapping the Android toolchain,
+with a very vague hope of getting more than adb, fastboot and a few more
+utilities into Guix.  The task looks daunting, since the sourcecode is
+spread over a large number of git repositories with gigabytes of data,
+and the idea of modular builds apparently has not influenced the design
+decisions.  But all is not lost, people from the Reproducible/Rebuild Android 
(?)
+project have done a lot of work to disentangle the sources, and we could
+also look for inspiration from the Replicant project.  Interestingly, the
+Android NDK, which provides a _foreign function interface_ to C libraries,
+appears to be an easier target.
+
+Some discussions have also evolved around F-Droid, the free app store for
+Android, and the topic of building the apps reproducibly and adding
+relevant information to the
+[competition](https://tests.reproducible-builds.org/).
+
 
 # Verifying and sharing build results
 
+Speaking of which, the [website](https://tests.reproducible-builds.org/)
+retracing reproducibility feats and issues was also the subject of a
+cross-distribution discussion round between Debian, Arch, Nix, Guix and
+OpenWRT.  Currently the page is tightly connected to a continuous
+integration instance rebuilding distributions such as Debian and Arch.
+We have discussed a file format (probably based on JSON) that would
+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.
+
+
+# Guix Data Service
+
+This nifty project
+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
+machines behind
+[bayfront.guix.gnu.org](https://bayfront.guix.gnu.org/).
+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.
+
+
 # Bootstrapping
 
 This year the summit had an official extended format; encouraging
@@ -154,8 +218,6 @@ there, but it could well be our horizon!
 
 # More cool hacks
 
-  - Ten Years reproducibility challenge
-
 During the summit, support for [_system provenance tracking_ in `guix
 system`](https://issues.guix.gnu.org/issue/38441) landed in Guix.  This
 allows a deployed system to embed the information needed to rebuild it:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]