[rb-commits] [website] master: Fix grammar, typos, and wordings (5737fff)
lunar at jenkins.debian.net
lunar at jenkins.debian.net
Sun Dec 20 18:40:06 CET 2015
Repository : ssh://jenkins/website
On branch : master
>---------------------------------------------------------------
commit 5737fff894cde8637835ab92bbb721bad4905d29
Author: Georg Koppen <gk at torproject.org>
Date: Sun Dec 20 18:38:55 2015 +0100
Fix grammar, typos, and wordings
>---------------------------------------------------------------
5737fff894cde8637835ab92bbb721bad4905d29
_docs/build_path.md | 4 ++--
_docs/build_toolchain_from_source.md | 8 ++++----
_docs/buy_in.md | 2 +-
_docs/checksums.md | 6 +++---
_docs/definition_strategies.md | 2 +-
_docs/deterministic_build_systems.md | 10 +++++-----
_docs/embedded_signatures.md | 6 +++---
_docs/formal_definition.md | 4 ++--
_docs/locales.md | 6 +++---
_docs/plans.md | 4 ++--
_docs/proprietary_os.md | 2 +-
_docs/recording.md | 2 +-
_docs/sharing_certifications.md | 2 +-
_docs/test_bench.md | 2 +-
_docs/timestamps.md | 2 +-
_docs/timezones.md | 2 +-
_docs/version_information.md | 4 ++--
_docs/volatile_inputs.md | 2 +-
18 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/_docs/build_path.md b/_docs/build_path.md
index ae2938a..95994da 100644
--- a/_docs/build_path.md
+++ b/_docs/build_path.md
@@ -9,8 +9,8 @@ Some tools will record the path of the source files in their output.
Most compilers write the path of the source in the debug
information in order to locate the associated source files.
-Some tools have flags (like gzip's `-n`) that prevent them to write
-the path in their output. Proposing patches to add similar feature in
+Some tools have flags (like gzip's `-n`) that prevent them from writing
+the path in their output. Proposing patches to add a similar feature in
other tools might be sufficiently easy.
In most cases however, post-processing is required to either remove the
diff --git a/_docs/build_toolchain_from_source.md b/_docs/build_toolchain_from_source.md
index b35e892..d0bb2f2 100644
--- a/_docs/build_toolchain_from_source.md
+++ b/_docs/build_toolchain_from_source.md
@@ -5,7 +5,7 @@ permalink: /docs/build-toolchain-from-source/
---
Building the tools that make the environment from source is one way to
-allow user to reproduce it. Using source directly makes it easier to
+allow user to reproduce it. Using the source code directly makes it easier to
rely on new features, and easily works on a variety of platforms. It
might not scale well for a long list of dependencies, and asking users
to rebuild GCC for every piece of software they use might make them
@@ -18,7 +18,7 @@ Building using external resources
---------------------------------
The source for the different components can be retrieved from online
-repository. Using release tarballs might be preferable as they are
+repositories. Using release tarballs might be preferable as they are
easier to cache, [mirror, checksum and verify]({{ "/docs/volatile-inputs/" | prepend: site.baseurl }}).
When retrieving the source from a version control system repository,
it's best to have a precise reference to the code version. With Git,
@@ -36,7 +36,7 @@ Check-in everything
Another approach is to check the source of the entire toolchain in the
project's version control system.
-This is how several integrated operating systems like *BSD are
+This is how several integrated operating systems like \*BSD are
developed. “Building the world†will start by building the toolchain in
the version control system before building the rest of the system.
@@ -45,7 +45,7 @@ released [Bazel](http://bazel.io/) which is based on their
internal compilation tool. Bazel is designed to drive large scale
builds with speed and reproducibility in mind.
-Outside of fully integrated operating systems or corporate environment,
+Outside of fully integrated operating systems or corporate environments,
it might be hard to push the idea of adding ten or more times the actual
code base in the toolchain…
diff --git a/_docs/buy_in.md b/_docs/buy_in.md
index 1146426..e3bb764 100644
--- a/_docs/buy_in.md
+++ b/_docs/buy_in.md
@@ -21,7 +21,7 @@ from the Snowden leaks the abstract of a talk at an
[Strawhorse: Attacking the MacOS and iOS Software Development
Kit](https://theintercept.com/document/2015/03/10/strawhorse-attacking-macos-ios-software-development-kit/).
The abstract clearly explains how unnamed researchers have been creating
-modified version of XCode that would — without any knowledge of the
+a modified version of XCode that would — without any knowledge of the
developer — watermark or insert spyware in the compiled applications.
A few months later, a malware dubbed “XcodeGhost†has been found
diff --git a/_docs/checksums.md b/_docs/checksums.md
index 27fc6d5..a68370c 100644
--- a/_docs/checksums.md
+++ b/_docs/checksums.md
@@ -7,11 +7,11 @@ permalink: /docs/checksums/
How can users know that the build they just made has successfully
reproduced the original build?
-The easiest way is to make sure that the build output are always
-byte-for-byte identical. Byte for byte comparison is a trivial operation
+The easiest way is to make sure that the build outputs are always
+byte-for-byte identical. Byte-for-byte comparison is a trivial operation
and can be performed in many different environments.
-The other benefit of having identical bytes is that it makes possible to
+The other benefit of having identical bytes is that it makes it possible to
use [cryptographic
checksums](https://en.wikipedia.org/wiki/Cryptographic_hash_function).
Such checksums are really tiny compared to the full build products. They
diff --git a/_docs/definition_strategies.md b/_docs/definition_strategies.md
index 0c4bd20..7752f13 100644
--- a/_docs/definition_strategies.md
+++ b/_docs/definition_strategies.md
@@ -58,7 +58,7 @@ easily perform the build in a more controlled environment. The build
user, system hostname, network configuration, or other aspects can be
enforced easily on all systems.
-The downside is that it can introduce a lot of software that has be
+The downside is that it can introduce a lot of software that has to be
trusted somehow. For example, it's currently not possible to install
Debian in a reproducible manner[^reproducible-install]. This makes it
harder to compare different installations.
diff --git a/_docs/deterministic_build_systems.md b/_docs/deterministic_build_systems.md
index 2d811f1..aea81a5 100644
--- a/_docs/deterministic_build_systems.md
+++ b/_docs/deterministic_build_systems.md
@@ -4,7 +4,7 @@ layout: docs
permalink: /docs/deterministic-build-systems/
---
-A software cannot be easily be built reproducibly if the source varies
+A software cannot easily be built reproducibly if the source varies
depending on factors that are hard or impossible to control like the
ordering of files on a filesystem or the current time.
@@ -24,7 +24,7 @@ or `sed` where the requirement for the environment can be as loose as
But it's hardly a good idea to mandate that the system pseudo-random
number generator be initialized with a given value before performing a
-build, so better not have randomness affect a build output.
+build, so better not having randomness affect a build output.
Another concrete example on where to draw the line: there is no need to
care about making the build system give constant output when run in
@@ -43,15 +43,15 @@ as:
* Capture as little as possible from the environment.
What follows are some advices on common issues that can affect source
-code or build systems that makes multiple builds from the exact same
+code or build systems that make multiple builds from the exact same
source different.
Disclaimer
----------
-Not all problems currently have solutions. Some tools that might be used
+Not all problems have solutions currently. Some tools that might be used
in a build process might require fixes to become non-deterministic. The
-Debian effort keep a list of [all issues
+Debian effort keeps a list of [all issues
found](https://reproducible.debian.net/index_issues.html) while
investigating reproducibility problems in its 22,000+ source packages.
While some require changes in the package source itself, some can be
diff --git a/_docs/embedded_signatures.md b/_docs/embedded_signatures.md
index 34460dd..956844a 100644
--- a/_docs/embedded_signatures.md
+++ b/_docs/embedded_signatures.md
@@ -4,7 +4,7 @@ layout: docs
permalink: /docs/embedded-signatures/
---
-Software that are distributed using embedded cryptographic signatures
+Software that is distributed using embedded cryptographic signatures
can pose a challenge to allow users to reproduce identical results.
By definition, they will not be able to generate an identical signature.
This can either be solved by making the signature part of the build
@@ -16,7 +16,7 @@ Pasting signatures
One way to handle embedded cryptographic signatures is to make the
signature an (optional) input of the build process. When a signature
-is available, it just get copied at the right location.
+is available, it just gets copied at the right location.
This enables the following workflow:
@@ -48,7 +48,7 @@ Another option is to ship a tool that can strip the signatures from the
official releases. The result can then be compared byte-for-byte with
the results from the user.
-This method has the downside that it requires user to download the
+This method has the downside that it requires a user to download the
official releases to do the comparison. It's also harder to attest that
the data that is being removed will not make the software behave
differently.
diff --git a/_docs/formal_definition.md b/_docs/formal_definition.md
index 3243709..237473f 100644
--- a/_docs/formal_definition.md
+++ b/_docs/formal_definition.md
@@ -4,8 +4,8 @@ layout: docs
permalink: /docs/formal-definition/
---
-Most free software distribution are self-contained: all tools required
-to build its component are part of the distribution. In such cases, it's
+Most free software distributions are self-contained: all tools required
+to build their components are part of the distribution. In such cases, it's
possible to specify the build environment in a machine readable format
that can be later used to reinstall the environment.
diff --git a/_docs/locales.md b/_docs/locales.md
index 04ba2a5..2c0bae4 100644
--- a/_docs/locales.md
+++ b/_docs/locales.md
@@ -17,7 +17,7 @@ Time format
-----------
Several common time formatting functions will have output depending
-on the current locale. On POSIX system the formatting will depend on
+on the current locale. On a POSIX system the formatting will depend on
the `LC_CTIME` environment variable, which can be overridden by
`LC_ALL`.
@@ -38,8 +38,8 @@ Collation order
---------------
Common sorting functions are affected by the `LC_COLLATE` environment
-variable, which can which can be overridden by `LC_ALL`. Some locales can
-be quite surprising:
+variable, which can be overridden by `LC_ALL`. Some locales can
+be quite surprising.
This typically shows when using `sort`. The `fr_FR` locale will sort
independently of the character case:
diff --git a/_docs/plans.md b/_docs/plans.md
index 521187e..0dfed7e 100644
--- a/_docs/plans.md
+++ b/_docs/plans.md
@@ -40,7 +40,7 @@ developed or it can be recorded at build time.
Distributing the build environment
----------------------------------
-Users need to be able to know what build environment needs to be setup
+Users need to be able to know what build environment needs to be set up
to rebuild the software.
If the build environment is defined ahead and part of the source code,
@@ -59,7 +59,7 @@ source code, perform the build, and compare the results.
Ideally, the comparison protocol should be simple to see if resulting
binaries are identical. Comparing bytes or cryptographic hash
-functions is easy to do and understand.
+values is easy to do and understand.
Other technologies might require removing cryptographic signatures or
ignore specific parts. Such operations must be both documented and
diff --git a/_docs/proprietary_os.md b/_docs/proprietary_os.md
index 4e992b1..f37f8b5 100644
--- a/_docs/proprietary_os.md
+++ b/_docs/proprietary_os.md
@@ -17,7 +17,7 @@ the technique to build their Windows and Mac OS X versions.
Windows
-------
-For Windows, [ming-w64](http://mingw-w64.org/) will build Windows
+For Windows, [mingw-w64](http://mingw-w64.org/) will build Windows
binaries on POSIX compatible operating systems.
[NSIS](http://nsis.sourceforge.net/) can be used to create integrated
diff --git a/_docs/recording.md b/_docs/recording.md
index 633dca7..3c321c7 100644
--- a/_docs/recording.md
+++ b/_docs/recording.md
@@ -14,7 +14,7 @@ of the build environment irrelevant to the build output, or ensure they
are mandatory to rebuild the software exactly as distributed.
All irrelevant information should not be recorded. What information is
-irrelevant depends on what defined to be
+irrelevant depends on what is defined to be
[part of the build environment]({{ "/docs/perimeter/" | prepend: site.baseurl }}),
but it likely includes information such as date and time of the build, build
system hostname, path, network configuration, CPU type, memory size,
diff --git a/_docs/sharing_certifications.md b/_docs/sharing_certifications.md
index 7303ef3..4afa4b6 100644
--- a/_docs/sharing_certifications.md
+++ b/_docs/sharing_certifications.md
@@ -10,7 +10,7 @@ get the same build results?
Debian is thinking of allowing [multiple Debian Developers to upload
signatures](https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification#buildinfo_signatures)
-attesting that they have been to reproduce a build.
+attesting that they have been able to reproduce a build.
The question is also related to the work lead by Ben Laurie on [binary
transparency](https://groups.google.com/forum/#!forum/binary-transparency).
diff --git a/_docs/test_bench.md b/_docs/test_bench.md
index b4b8eee..6af18e1 100644
--- a/_docs/test_bench.md
+++ b/_docs/test_bench.md
@@ -7,7 +7,7 @@ permalink: /docs/test-bench/
It is important to detect reproducibility problems in the build system
before the users do, to avoid any false alarms.
-The method is usually as followed:
+The method is usually as follows:
1. Build a first time.
2. Save the result.
diff --git a/_docs/timestamps.md b/_docs/timestamps.md
index ebe86a8..cdbf12d 100644
--- a/_docs/timestamps.md
+++ b/_docs/timestamps.md
@@ -18,7 +18,7 @@ Often the time of the build was used as an approximate way to know which
version of the source has been built, and which tools had been used to do
it. With reproducible builds, recording the time of the build becomes
meaningless: on one side, the source code needs to be tracked more accurately
-that just a timestamp, and on the other side, the build environment needs to be
+than just a timestamp, and on the other side, the build environment needs to be
defined or extensively recorded.
If a date is required to give users an idea on when the software was
diff --git a/_docs/timezones.md b/_docs/timezones.md
index e6a0189..876f073 100644
--- a/_docs/timezones.md
+++ b/_docs/timezones.md
@@ -20,7 +20,7 @@ Tue, 19 Jan 2038 04:14:07 +0100
{% endhighlight %}
</div>
-Despite being given a pre-determined time in the form of an [Unix
+Despite being given a pre-determined time in the form of a [Unix
time](https://en.wikipedia.org/wiki/Unix_time) (also called *epoch*),
this output would fail to be reproducible in a different timezone
than UTC+0100. The easy solution is to set the required environment
diff --git a/_docs/version_information.md b/_docs/version_information.md
index dca49ba..c2b04b4 100644
--- a/_docs/version_information.md
+++ b/_docs/version_information.md
@@ -4,13 +4,13 @@ layout: docs
permalink: /docs/version-information/
---
-Version information embedded in the software need to be made
+Version information embedded in the software needs to be made
deterministic. Counter-examples are using the current date or an
incremental build counter.
The date and time of the build itself is hardly of value as an old
source code can always be compiled long after it has been released.
-It's best when version information give a good indication of what source
+It's best when version information gives a good indication of what source
code has been built.
The version number can come from a dedicated source file, a *changelog*,
diff --git a/_docs/volatile_inputs.md b/_docs/volatile_inputs.md
index 43fb745..d0c1157 100644
--- a/_docs/volatile_inputs.md
+++ b/_docs/volatile_inputs.md
@@ -21,6 +21,6 @@ contain a list of
[`MASTER_SITES`](https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites),
a list of files to be retrieved in `DISTFILES`, and a `distinfo` file
with cryptographic checksums for each of these files. The FreeBSD
-infrastructure ensure that a copy of all *distfiles* are kept available
+infrastructure ensures that a copy of all *distfiles* are kept available
on a mirror network. When building a port, the files will be downloaded
from there if the original *master site* is unreachable.
More information about the rb-commits
mailing list