Satyam Zode: Google Summer of Code 2016 : Final Report
Project Title : Improving diffoscope tool and reproducibility of Debian packages
- Project details
- Mentor and Co-Mentor
- Project Discussion
- Project Implementation
- Challenges and Work Left
- Future work
- Acknowledgement
.buildinfo feature. This project is a part of Reproducible Builds effort
Mentor and Co-Mentor
- J r my Bobbio (Lunar) : Mentor
- Reiner Herrmann (deki) : Co-Mentor
- Holger Levsen (h01ger) : Co-Mentor
- Mattia Rizzolo (mapreri) : Co-Mentor
- Introduction to Reproducible Builds in Debian
First time I came to know about Reproducible Builds was during Debconf 2015. I started to get involve from the start of March 2016. At the beginning Lunar suggested me to watch the talks given on Reproducible Builds wiki. I read documentation on Reproducible Builds site and started to participate in IRC discussions on
#debian-reproducible.
- Application Review Period During proposal discussion period we discussed the areas where work needs to be done. I wrote the proposal and got it reviewed by community on the mailing list. Simultaneously, I worked on bug #818111 and submitted patch for same. That not only helped me to understand the concept of Reproducible Builds but also helped me to setup testing environment required to check the reproducibility of Debian packages.
- Community Bonding Period During community bonding period I studied the codebase of diffoscope and also spent enough amount of time for learning Python3 metaprogramming and other OOP concepts. We also discussed more about hiding differences and options for same. I couldn t finish my project research work during this period since I had exams in May 2016 and it consumed almost half of community bonding period and week 1 of coding period.
- Coding Period
I continued my research regarding behaviour of diffoscope and Lunar suggested me to write specification for hiding options.
I spent most of the time researching differences present on
https://tests.reproducible-builds.org/debian/reproducible.html. Based on the work done, I came up with specification calledHide Profilefor allowing diffoscope to hide different profiles. Link to the specification: Later, I started to work on wish-list feature bug#826711. Links to commits:- https://anonscm.debian.org/cgit/reproducible/diffoscope.git/commit/?id=d733cb47903c54a3c4a699131e1b7bde3e492bbf
- https://anonscm.debian.org/cgit/reproducible/diffoscope.git/commit/?id=77dfd8d3e5e2e5d8ba31e606ef36cbd8f2315743
- https://anonscm.debian.org/cgit/reproducible/diffoscope.git/commit/?id=c15e6b5f74ae92462dee226a699e120d7017effb
- Build different Debian packages using prebuilder to study the output of diffoscope in different cases. Link : https://github.com/satyamz/buildinfo-cases/commits?author=satyamz
- Collected information regarding how other Free softwares implements ignore options/interfaces. Link: https://gist.github.com/satyamz/77d86e1fc78d104c784c0238a3a7c0e3
- Implementation of
Ignoring .buildinfo file while comparing .changes filesuse case.
- To understand the main purpose of diffoscope in the context of Reproducible Builds. I had to go through complete Reproducible Builds project. It consumed significant amount of time to understand what Reproducible Builds is, why it s necessary important for Free software to build reproducibly. Diffoscope is the last tool in Reproducible Builds toolchain. It was a big challenge for me to understand whole process and objective of diffoscope.
- Work Left:
- Implement important use cases given in the
Hide Profiles Specification.
- Implement important use cases given in the
- Based on the research work and implementation done during
Coding Periodmake diffoscope better and enhance ignoring capabilities of diffoscope. - Improve the parallel processing feature of diffoscope. This particular problem is hard to understand and implement.
- Make diffoscope better by solving
exsting bugs.





Over the weekend I've played with continuous integration for
Executive summary
Since October 2015, I've been running a
FLOSS consulting company,
specialized on Debian, called 
A couple of weeks ago I started looking into wrapping the 
Today it is 23 years ago since Ian Murdock published his intention to
develop a new Linux distribution, Debian. It also about 20 years since
I became a Debian developer and made my first package upload.
In the time since:
Happy Independence Day to all. I had been looking forward to this day so I can use to share with my brothers and sisters what little I know about TOR . Independence means so many things to many people. For me, it means having freedom, valuing it and using it to benefit not just to ourselves but to people at large. And for that to happen, at least on the web, it has to rise above censorship if we are to get there at all. I am 40 years old, and if I can t read whatever I want to read without asking the state-military-Corporate trinity than be damned with that. Debconf was instrumental as I was able to understand and share many of the privacy concerns that we all have. This blog post is partly a tribute to being part of a community and being part of Debconf16.
So, in that search for privacy couple of years ago, I came across TOR . TOR stands for The Onion Router project. Explaining tor is simple. Let us take the standard way in which we approach the website using a browser or any other means.
a. We type out a site name, say debian.org in the URL/URI bar .
There are various motivations for doing that. For myself, I m just a private person and do not need or want that any other person/s or even the State should be looking over my shoulder as to what I m doing. And the argument that we need to spy on citizens because Terrorists are there doesn t hold water over me. There are many ways in which they can pass messages even without tor or web. The Government-Corporate-Military just get more powerful if and when they know what common people think, do, eat etc.
So the question is how does you install tor if you a private sort of person . If you are on a Debian machine, you are one step closer to doing that.
So the first thing that you need to do is install the following

At some point back when the dinosaurs roamed the Earth and I was in
high school, I borrowed my first digital signal processing book from a friend.
I later went on to an engineering education and master's thesis about DSP,
but the very basics of DSP never stop to fascinate me. Today, I wanted to
write something about one of them and how it affects audio processing in
Nageru (and finally, how Debian's policies put me in a bit of a bind on
this issue).
DSP texts tend to obscure profound truths with large amounts of maths,
so I'll try to present a somewhat less general result that doesn't require
going into the mathematical details. That rule is:
Adding a signal to weighted, delayed copies of itself is a filtering operation.
(It's simple, but ignoring it will have sinister effects, as we'll see later.)
Let's see exactly what that means with a motivating example. Let's say that
I have a signal where I want to get rid of (or rather, reduce) high frequencies.
The simplest way I can think of is to add every neighboring sample; that is,
set yn = xn + xn-1. For each sample, we
add the previous sample, ie., the signal as it was one sample ago.
(We ignore what happens at the edges; the common
convention is to assume signals extend out to infinity with zeros.)
What effect will this have? We can figure it out with some trigonometry,
but let's just demonstrate it by plotting instead: We assume 48 kHz sample rate
(which means that our one-sample delay is 20.83 s) and a 22 kHz
note (definitely treble!), and plot the signal with one-sample delay
(the x axis is sample number):
As you can see, the resulting signal is a new signal of the same frequency
(which is always true; linear filtering can never create new frequencies,
just boost or dampen existing ones), but with much lower amplitude.
The signal and the delayed version of it end up cancelling each other mostly
out. Also note that there signal has changed phase; the resulting signal
has been a bit delayed compared to the original.
Now let's look at a 50 Hz signal (turn on your bass face). We need to zoom out a bit to see
full 50 Hz cycles:
The original signal and the delayed one overlap almost exactly! For a lower
frequency, the one-sample delay means almost nothing (since the waveform is
varying so slowly), and thus, in this case, the resulting signal is amplified,
not dampened. (The signal has changed phase here, too actually exactly as much
in terms of real time but we don't really see it, because we've zoomed out.)
Real signals are not pure sines, but they can be seen as sums of many sines
(another fundamental DSP result), and since filtering is a linear operation,
it affects those sines independently. In other words, we now have a very
simple filter that will amplify low frequencies and dampen high frequencies
(and delay the entire signal a little bit). We can do this for all
frequencies from 0 to 24000 Hz; let's ask Octave to do it for us:
(Of course, in a real filter, we'd probably multiply the result with 0.5
to leave the bass untouched instead of boosting it, but it doesn't really
change anything. A real filter would have a lot more coefficients, though,
and they wouldn't all be the same!)
Let's now turn to a problem that will at first seem different: Combining
audio from multiple different time sources. For instance, when mixing video,
you could have input from two different cameras or sounds card and would want
to combine them (say, a source playing music and then some audience sound
from a camera). However, unless you are lucky enough to have a professional-grade setup
where everything runs off the same clock (and separate clock source cables
run to every device), they won't be in sync; sample clocks are good, but they are
not perfect, and they have e.g. some temperature variance. Say we have really
good clocks and they only differ by 0.01%; this means that after an hour of
streaming, we have 360 ms delay, completely ruining lip sync!
This means we'll need to resample at least one of the sources to match the
other; that is, play one of them faster or slower than it came in originally.
There are two problems here: How do you determine how much to resample
the signals, and how do we resample them?
The former is a difficult problem in its own right; about every algorithm
not backed in solid control theory
is doomed to fail in one way or another, and when they fail, it's extremely
annoying to listen to. Nageru follows
(Some) people seem to be anxious to know what I m doing next, and my answer is, go mind your own fucking business. However, life is short and I would love to do any of the following: