diff --git a/Posts/ReproducibleOPAM b/Posts/ReproducibleOPAM
index 40680b2..2a45046 100644
--- a/Posts/ReproducibleOPAM
+++ b/Posts/ReproducibleOPAM
@@ -25,7 +25,7 @@ Testing for reproducibility is achieved by taking the sources and compile them t
 
 Conceptually there should be two tools, the *initial builder*, which takes the latest opam packages which do not conflict, and exports exact package versions used during the build, as well as hashes of binaries. The other tool is a *rebuilder*, which imports the export, conducts a build, and outputs the hashes of the produced binaries.
 
-Opam has the concept of a `switch`, which is an environment where a package set is installed. Switches are independent of each other, and can already be exported and imported. Unfortunately the export is incomplete: if a package includes additional patches as part of the repository -- sometimes needed for fixing releases where the actual author or maintainer of a package responds slowly -- these package neither the patches end up in the export. Also, if a package is pinned to a git branch, the branch appears in the export, but this may change over time by pushing more commits or even force-pushing to that branch. In [PR #4040](https://github.com/ocaml/opam/pull/4040) (under discussion and review), also developed during the summit, I propose to embed the additional files as base64 encoded values in the opam file. To solve the latter issue, I modified the export mechanism to [embed the git commit hash](https://github.com/hannesm/opam/tree/export-build-info), and avoid sources from a local directory and which do not have a checksum.
+Opam has the concept of a `switch`, which is an environment where a package set is installed. Switches are independent of each other, and can already be exported and imported. Unfortunately the export is incomplete: if a package includes additional patches as part of the repository -- sometimes needed for fixing releases where the actual author or maintainer of a package responds slowly -- these package neither the patches end up in the export. Also, if a package is pinned to a git branch, the branch appears in the export, but this may change over time by pushing more commits or even force-pushing to that branch. In [PR #4040](https://github.com/ocaml/opam/pull/4040) (under discussion and review), also developed during the summit, I propose to embed the additional files as base64 encoded values in the opam file. To solve the latter issue, I modified the export mechanism to [embed the git commit hash (PR #4055)](https://github.com/ocaml/opam/pull/4055), and avoid sources from a local directory and which do not have a checksum.
 
 So the opam export contains the information required to gather the exact same sources and build instructions of the opam packages. If the opam repository would be self-contained (i.e. not depend on any other tools), this would be sufficient. But opam does not run in thin air, it requires some system utilities such as `/bin/sh`, `sed`, a GNU make, commonly `git`, a C compiler, a linker, an assembler. Since opam is available on various operating systems, the plugin `depext` handles host system dependencies, e.g. if your opam package requires `gmp` to be installed, this requires slightly different names depending on host system or distribution, take a look at [conf-gmp](https://github.com/ocaml/opam-repository/blob/master/packages/conf-gmp/conf-gmp.1/opam). This also means, opam has rather good information about both the opam dependencies and the host system dependencies for each package. Please note that the host system packages used during compilation are not yet recorded (i.e. which `gmp` package was installed and used during the build, only that a `gmp` package has to be installed). The base utilities mentioned above (C compiler, linker, shell) are also not recorded yet.