[Reproducible-commits] [blog] 01/01: Publish

[Ceridwen]

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

ceridwen-guest pushed a commit to branch master
in repository blog.

commit a52aaf8c76c15837cc9eced327d486ae00c92c88
Author: Ceridwen <ceridwenv at gmail.com>
Date:   Thu May 19 23:20:20 2016 -0400

    Publish
---
 drafts/people/ceridwen/first.mdwn | 42 ---------------------------------------
 posts/people/first.mdwn           | 41 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+), 42 deletions(-)

diff --git a/drafts/people/ceridwen/first.mdwn b/drafts/people/ceridwen/first.mdwn
deleted file mode 100644
index 3da0188..0000000
--- a/drafts/people/ceridwen/first.mdwn
+++ /dev/null
@@ -1,42 +0,0 @@
-[[!meta title="Improving the process for testing build reproducibility"]]
-
-Hi!  I'm Ceridwen.  I'm going to be one of the
-[Outreachy](https://www.gnome.org/outreachy/) interns working on
-[Reproducible Builds](https://wiki.debian.org/ReproducibleBuilds) for
-the summer of 2016.  My project is to create a script, tentatively
-named reprotest, to make the process of verifying that a build is
-reproducible easier.
-
-The current
-[tool chain](https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain)
-and the
-[Reproducible Builds site](http://tests.reproducible-builds.org/) have
-limits on what they can test, and the tool chain is not very user
-friendly.  (For instance, I ended up needing to edit the rebuild.sh
-script to run it on my system.)  Reprotest will automate some of the
-busywork involved and make it easier for maintainers to test
-reproducibility without detailed knowledge of the tool chain.
-[reproducible-builds.org/events/athens2015/reprotest/](https://reproducible-builds.org/events/athens2015/reprotest/)
-outlines the some of the functionality and command-line and
-configuration file API goals for reprotest.  I also intend to use
-some ideas, and command-line and config processing boilerplate, from
-[Autopkgtest](https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html).
-One major feature is that reprotest, like autopkgtest, should be able
-to interface with more build environments, such as schroot and qemu.
-Both autopkgtest and [diffoscope](https://diffoscope.org/), the
-program that the Reproducible Builds project uses to check binaries
-for differences, are written in Python, and as Python is the scripting
-language I'm most familiar with, I will be writing reprotest in Python
-too.
-
-One of my major goals is to get a usable prototype released in the
-first three to four weeks.  At that point, I want to try to solicit
-feedback (and any contributions anyone wants to make!).  One of my
-experiences in open source software is that connecting people with
-software they might want to use is often the hardest part of a
-project.  I've reimplemented existing functionality myself because I
-simply didn't know that someone else had already written something
-equivalent, and seen many other people do the same.  Once I have the
-skeleton fleshed out, I'm going to be trying to find and reach out to
-other communities who might find reprotest useful, outside the Debian
-Reproducible Builds project itself.
diff --git a/posts/people/first.mdwn b/posts/people/first.mdwn
new file mode 100644
index 0000000..c81f413
--- /dev/null
+++ b/posts/people/first.mdwn
@@ -0,0 +1,41 @@
+[[!meta title="Improving the process for testing build reproducibility"]]
+
+Hi!  I'm Ceridwen.  I'm going to be one of the
+[Outreachy](https://www.gnome.org/outreachy/) interns working on
+[Reproducible Builds](https://wiki.debian.org/ReproducibleBuilds) for
+the summer of 2016.  My project is to create a tool, tentatively named
+reprotest, to make the process of verifying that a build is
+reproducible easier.
+
+The current
+[tools](https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain)
+and the [Reproducible Builds
+site](http://tests.reproducible-builds.org/) have limits on what they
+can test, and they're not very user friendly.  (For instance, I ended
+up needing to edit the `rebuild.sh` script to run it on my system.)
+Reprotest will automate some of the busywork involved and make it
+easier for maintainers to test reproducibility without detailed
+knowledge of the process involved.  A [session during the Athens
+meeting](https://reproducible-builds.org/events/athens2015/reprotest/)
+outlines some of the functionality and command-line and configuration
+file API goals for reprotest.  I also intend to use some ideas, and
+command-line and config processing boilerplate, from
+[autopkgtest](https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html).
+Reprotest, like autopkgtest, should be able to interface with more
+build environments, such as schroot and qemu.  Both autopkgtest and
+[diffoscope](https://diffoscope.org/), the program that the
+Reproducible Builds project uses to check binaries for differences,
+are written in Python, and as Python is the scripting language I'm
+most familiar with, I will be writing reprotest in Python too.
+
+One of my major goals is to get a usable prototype released in the
+first three to four weeks.  At that point, I want to try to solicit
+feedback (and any contributions anyone wants to make!).  One
+experience I've had in open source software is that connecting people
+with software they might want to use is often the hardest part of a
+project.  I've reimplemented existing functionality myself because I
+simply didn't know that someone else had already written something
+equivalent, and seen many other people do the same.  Once I have the
+skeleton fleshed out, I'm going to be trying to find and reach out to
+any other communities, outside the Debian Reproducible Builds project
+itself, who might find reprotest useful.

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