[reproducible-website] 01/01: Correct spelling mistakes.

Edward Betts edward at moszumanska.debian.org
Tue Apr 24 15:46:53 CEST 2018


This is an automated email from the git hooks/post-receive script.

edward pushed a commit to branch master
in repository reproducible-website.

commit 1d2591ba8ce9cfb8a4335078ac9d46195cfc7819
Author: Edward Betts <edward at 4angle.com>
Date:   Tue Apr 24 14:41:28 2018 +0100

    Correct spelling mistakes.
---
 _blog/posts/154.md                             | 2 +-
 _events/athens2015/debian_buildinfo_review.md  | 2 +-
 _events/athens2015/post-event_collaboration.md | 4 ++--
 _events/athens2015/reprotest.md                | 4 ++--
 _events/athens2015/use_cases.md                | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/_blog/posts/154.md b/_blog/posts/154.md
index 92e1f90..208fe84 100644
--- a/_blog/posts/154.md
+++ b/_blog/posts/154.md
@@ -12,7 +12,7 @@ Here's what happened in the [Reproducible Builds](https://reproducible-builds.or
 
 * Juro Bystricky posted to [our mailing list](https://lists.reproducible-builds.org/pipermail/rb-general/) on [the Linux kernel's `srcversion` field](https://lists.reproducible-builds.org/pipermail/rb-general/2018-April/000845.html).
 
-* Chris Lamb uploaded [python-setuptools](39.0.1-1.0~reproducible1) to our local package repository to work around an issue where version 39.0.1 onwards generated `PKG-INFO` files with a non-deterministic "`Provides-Extra`" output ([#894215](https://bugs.debian.org/894215)). This was subsequently superceded by [Matthias Klose upload of 39.0.1-2 into unstable](https://tracker.debian.org/news/944926/accepted-python-setuptools-3901-2-source-into-unstable/).
+* Chris Lamb uploaded [python-setuptools](39.0.1-1.0~reproducible1) to our local package repository to work around an issue where version 39.0.1 onwards generated `PKG-INFO` files with a non-deterministic "`Provides-Extra`" output ([#894215](https://bugs.debian.org/894215)). This was subsequently superseded by [Matthias Klose upload of 39.0.1-2 into unstable](https://tracker.debian.org/news/944926/accepted-python-setuptools-3901-2-source-into-unstable/).
 
 * anthraxx [added Arch Linux support](https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=9e5b7f8) for the [Gnumeric](http://www.gnumeric.org/) spreadsheet comparator in [diffoscope](https://diffoscope.org).
 
diff --git a/_events/athens2015/debian_buildinfo_review.md b/_events/athens2015/debian_buildinfo_review.md
index 8980746..552bae0 100644
--- a/_events/athens2015/debian_buildinfo_review.md
+++ b/_events/athens2015/debian_buildinfo_review.md
@@ -34,7 +34,7 @@ dependencies, so the package name, arch and version do not uniquely identify an
 exact dependency binary.
 
 Installation order of dependency packages doesn't *appear* to be recorded—the
-list of depedencies is in alphabetical order, and there are ways the
+list of dependencies is in alphabetical order, and there are ways the
 installation order of dependency packages could affect the build environment.
 
 There are two camps here—either we fix the order (to make reproduction easier)
diff --git a/_events/athens2015/post-event_collaboration.md b/_events/athens2015/post-event_collaboration.md
index 37b617e..1f91f23 100644
--- a/_events/athens2015/post-event_collaboration.md
+++ b/_events/athens2015/post-event_collaboration.md
@@ -12,7 +12,7 @@ benefits from collaboration
 ---------------------------
 
  - learning from each other
- - not duplicating the work (not reinventing the wheel, like producing identical tools, debugging the same issues agains)
+ - not duplicating the work (not reinventing the wheel, like producing identical tools, debugging the same issues again)
  - larger userbase that gets exposed to reproducible builds (good for shaking out bugs)
  - different communities coming together can help to think out-of-the-box
  - sharing infrastructure
@@ -26,7 +26,7 @@ what do we have
  - mailing lists
  - twitter account (ReproBuilds)
 
-issues and challenges in collaboration (competative advantages)
+issues and challenges in collaboration (competitive advantages)
 ---------------------------------------------------------------
 
  - specific project information too specific
diff --git a/_events/athens2015/reprotest.md b/_events/athens2015/reprotest.md
index 3fa2aeb..11cfc07 100644
--- a/_events/athens2015/reprotest.md
+++ b/_events/athens2015/reprotest.md
@@ -46,7 +46,7 @@ To control which variations are being tested:
 
     $ reprotest --variations=date build.sh
     # fail with something like:
-    #     Sorry, date is not suported in direct mode
+    #     Sorry, date is not supported in direct mode
     # (or do we want to use libfaketime?)
 
     $ reprotest --variations=date --runner=virtualbox build.sh
@@ -143,7 +143,7 @@ Run build twice, reproducing `$DEFAULT` set of information from build environmen
 
     $ reprotest make
 
-Run build once, reproducing `$DEFAULT` set of infomation from `xxx.buildinfo`:
+Run build once, reproducing `$DEFAULT` set of information from `xxx.buildinfo`:
 
     $ reprotest --buildinfo=bash_amd64.buildinfo make
 
diff --git a/_events/athens2015/use_cases.md b/_events/athens2015/use_cases.md
index 44d9916..05525b9 100644
--- a/_events/athens2015/use_cases.md
+++ b/_events/athens2015/use_cases.md
@@ -17,7 +17,7 @@ Use cases & success stories for build reproducibility:
  - Reproducible builds reduce developers' risk of being forced by law enforcement into creating malicious binaries
  - Google: Build reproducible allows cache sharing and increases build speed tremendously (99% cache hits, associated with actual $$$ value), simplifies debugging because builds can be re-done and discrepancies easily discovered
  - F-Droid: Reasonable easy secure release build process, builds can be easily verified with different machines. This increases confidence in the apps. Even for closed source apps, this allows developers to verify that the copy on Google Play is the same than you intended it to be.
- - NixOS: Ability to have decentralized continous build system, build infrastructure can be distributed. Tests are a big topic, because they're not always reproducible; re-running tests can possibly be avoided if the binaries are exactly those that have previously been tested. Reproducibility enables purely functional package management, which avoids implicit dependecies (e.g. on the environment).
+ - NixOS: Ability to have decentralized continuous build system, build infrastructure can be distributed. Tests are a big topic, because they're not always reproducible; re-running tests can possibly be avoided if the binaries are exactly those that have previously been tested. Reproducibility enables purely functional package management, which avoids implicit dependencies (e.g. on the environment).
  - Debian: Reproducible builds enable small delta updates, particularly if there is no delta. If toolchain changes don't change the binary re-testing can be avoided and changes can be reviewed.
  - MacPorts: Reproducibility can provide confidence that a build on a user's machine produces what was intended by the packager; this reduces the support burden.
  - Core Boot (bootloader) & Seabios: gain assurance of what's running at the lowest layers of your stack, and it runs in system management mode so it has full access.

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-website.git


More information about the rb-commits mailing list