Student Application Template

Maria Valentina Marin Rodrigues

I am Venezuelan student currently finishing the first year of my Masters in Bioinformatics at Lund University in Sweden. I had to write VMD ( ) plug-in in Tcl for my bachelor thesis and now during my masters I took a course on Perl programming. I also know a bit of Python. I am a Debian user since 2012. Last autumn I learned about the reproducible builds project through Outreachy but due to my studies I did not have enough time to work on the project full time back then.

I started making some contributions since January 18 of this year:

Move forward reproducible builds

I think that my work can be split into the three parts like I split my contributions above. The three parts are toolchain fixes, filing individual bugs and housekeeping issues like: fixing jenkins, debbindiff, keeping packages.yml up to date and uploading toolchain packages to the experimental repository. I think it is important that I find a good balance between these three tasks. I am open to discuss priorities and the associated workload with my mentors and make changes accordingly.

  1. The toolchain issues that I should work on should be those that affect the most packages.
  2. When working on individual fixes then it is important to select those packages which are either used a lot according to popcon or which are build-essential-depends. I think that the build-essential-depends set is of particular importance because a piece of software can only be trusted if its dependencies and the dependencies of its dependencies and so on are reproducible
  3. Making fixes to debbindiff which will help me to identify and analyze issues that I encounter

A thorough list about why reproducible builds are good for Debian can be found on the reproducible builds wiki ReproducibleBuilds/About

Personally what I find are the most important benefits, are that this project will empower users by giving them more control over what they install. This means that the users has the ability to check easily for themselves that the software they want to use has not been tampered with by verifying that it corresponds byte by byte to the known source code.

Currently users have to trust that the DD and build daemons are not compromised by a malicious third party but reproducible builds change this system because the user can now always verify the software themselves. It also has the added benefit that users can help verify that the system of a DD or a build daemon have not been compromised in a way that changes the built packages.

I estimate 1 patch per day on average which would be 65 patches during the duration of my work. This number will variate depending on the complexity of the patch. Patches will be against toolchain, individual packages and tools like debbindiff

I can begin to work on May 25 but i still have classes until June 5. After that I am completely free for the rest of the summer and can dedicate myself full time to the project. The following division of time is just a rough draft which might change depending on the priorities that my mentors and I agree on.




Work through all the 126 packages are not affected anymore by the doxygen timestamp problem but they are affected by other issues.


Work on some of the unreproducible packages from the popcon_top1337 set


Work on some packages from the build-essential-depends list


Work on the 85 affected packages by timezones_manpages_podman


Working on some of the 171 packages affected by timestamps_in_pdf_generated_by_latex


Work on the 23 packages affected by timestamps_in_documentation_generated_by_javadoc


Time to write the final report and if there is time work on the 23 packages affected by use_epydoc

Debian has a really active team working on reproducible builds. The community has been very welcoming and helpful. I intend to keep working on the project after GSoC. I plan to attend Debconf'15 in Germany.