[Reproducible-commits] [reproducible-website] 18/55: Minor tweaks coming in...

[Chris Lamb]

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

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

commit a048b6551797b8a3fb1031c84def502b7af3434d
Author: Paul Gevers <elbrus at debian.org>
Date:   Mon Nov 2 20:12:37 2015 +0100

    Minor tweaks coming in...
---
 _docs/archives.md   |  4 ++--
 _docs/build_path.md | 14 +++++++-------
 _docs/perimeter.md  | 21 +++++++++++----------
 _docs/randomness.md |  2 +-
 4 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/_docs/archives.md b/_docs/archives.md
index bf19bd2..95bdc06 100644
--- a/_docs/archives.md
+++ b/_docs/archives.md
@@ -7,8 +7,8 @@ permalink: /docs/archives/
 Most archive formats record metadata that will capture details about the
 build environment if no care is taken. File last modification time is
 obvious, but file ordering, users, groups, numeric ids, and permissions
-can also be concerns. Tar will be used as the main example but these tips
-should apply to other archive formats as well.
+can also be of concern. Tar will be used as the main example but these tips
+apply to other archive formats as well.
 
 File modification times
 -----------------------
diff --git a/_docs/build_path.md b/_docs/build_path.md
index 6d83d73..ae2938a 100644
--- a/_docs/build_path.md
+++ b/_docs/build_path.md
@@ -6,25 +6,25 @@ permalink: /docs/build-path/
 
 Some tools will record the path of the source files in their output.
 
-Most compilers will write the path of the source in the debug
+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 will prevent them to write
+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
 other tools might be sufficiently easy.
 
-But in most cases, post-processing will be required to either remove the
-build path or normalize it to a predefined value.
+In most cases however, post-processing is required to either remove the
+build path or to normalize it to a predefined value.
 
 For the specific case of [DWARF
 symbols](https://en.wikipedia.org/wiki/DWARF), there is currently no good
 tool to
-change them after a build to a pre-determined value[^debugedit]. A work-around is to
+change them to a pre-determined value after a build[^debugedit]. A work-around is to
 [define the build path as part of the build environment]({{ "/docs/perimeter/" | prepend: site.baseurl }}).
 
-[^debugedit]: [debugedit](https://fedoraproject.org/wiki/Releases/FeatureBuildId) can replace the path used at build time by a predefined one but it will do it by rewriting bytes in place. As this does not reorder the hash table of strings, the resulting bytes will still be different depending on the original build path.
+[^debugedit]: [debugedit](https://fedoraproject.org/wiki/Releases/FeatureBuildId) can replace the path used at build time by a predefined one but it does that by rewriting bytes in place. As this does not reorder the hash table of strings, the resulting bytes are still depending on the original build path.
 
 This is also problematic because this will also apply to intermediate
 source files that other tools generate. As they typically will use [random
 file names]({{ "/docs/randomness/" | prepend: site.baseurl }}), having a
-fixed build path will not be enough in such cases.
+fixed build path is not enough in such cases.
diff --git a/_docs/perimeter.md b/_docs/perimeter.md
index 91e9028..8195824 100644
--- a/_docs/perimeter.md
+++ b/_docs/perimeter.md
@@ -5,8 +5,8 @@ permalink: /docs/perimeter/
 ---
 
 Reproducible builds does not mandate that a given piece of source code
-be turned into the same bytes in all situations. This would be
-infeasible. The output of a compiler is likely to be different from one
+is turned into the same bytes in all situations. This would be
+unfeasible. The output of a compiler is likely to be different from one
 version to another as better optimizations are integrated all the time.
 
 Instead, reproducible builds happen in the context of a *build
@@ -18,7 +18,7 @@ any distributed binary package.
 Requirements
 ------------
 
-What exactly makes the build environment is going to be different for
+What exactly makes up the build environment is going to be different for
 each project. There might even be several build environments for a
 single release to accommodate different target operating systems.
 But there are some important aspects common to all environments.
@@ -28,8 +28,9 @@ system. Ideally it should only be made of free software available on
 public Internet sites. The best way to provide the environment is
 probably using a documented and easily understood script.
 
-It should be **auditable**. It must be easy to understand what tools
-are part of the build environment, and ideally review and rebuild them.
+It should be **auditable**. It must be easy to understand what tools are part
+of the build environment. And ideally it must be easy to review and rebuild
+them.
 
 Content
 -------
@@ -39,12 +40,12 @@ XXX: Not really happy with this section. Please help!
 -- Lunar
 {% endcomment %}
 
-What is exactly defined as the build environment needs to be properly
-specified as this will determine how much of the build system will need
-to be [made deterministic]({{ "/docs/deterministic-build-systems/" | prepend: site.baseurl }}).
+The scope of the build environment needs to be properly
+specified as this will determine how much of the build system needs
+to be [deterministic]({{ "/docs/deterministic-build-systems/" | prepend: site.baseurl }}).
 
-The defined environment will have the list of the tools used by the
-build process and versions that must be used.
+At least the defined environment has a list of the tools used by the
+build process and their versions.
 
 The rest can be different from one project to the next, as long as it
 can be reproduced by interested users. To give some examples:
diff --git a/_docs/randomness.md b/_docs/randomness.md
index 03e0bf4..ce9206d 100644
--- a/_docs/randomness.md
+++ b/_docs/randomness.md
@@ -12,7 +12,7 @@ generator](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). This
 value can be read from some file, a changelog or the version control system.
 
 When Link-Time Optimizations are turned on, GCC users will write random
-identifiers to binary objects it creates. Using `-frandom-seed` can be used for
+identifiers to binary objects they create. Using `-frandom-seed` can be used for
 this particular case. As it will hash arbitrary data, passing the file name
 should work in most cases.
 

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