Simon D saulniers: [GSOC] Final report

Debian
I ve had the great opportunity to go to the Debian Conference 2016. I ve been
introduced to the debian community and debian developpers ( dd in short :p). I
was lucky to meet with great people like the president of the FSF, John
Sullivan. You can have a look at my Debian conference report here.
If you want to read my debian reports, you can do so by browsing the Google
Summer Of Code category on this blog.
What I have done
Ring is now in official debian
repositories since June 30th. This
is a good news for the GNU/Linux community. I m proud to say that I ve been able
to contribute to debian by working on OpenDHT and developing new
functionalities to reduce network traffic. The goal behind this was to finally
optimize the data persistence traffic consumption on the DHT.
Github repository: https://github.com/savoirfairelinux/opendht
Queries
Issues:
- #43: DHT queries
Pull requests:
- #79: [DHT] Queries: remote values filtering
- 93: dht: return consistent query from local storage
- #106: [dht] rework get timings after queries in master
Value pagination
Issues:
- #71: [DHT] value pagination
Pull requests:
Indexation (feat. Nicolas Reynaud)
Pull requests:
General maintenance of OpenDHT
Issues:
- #72: Packaging issue for Python bindings with CMake: $DESTDIR not honored
- #75: Different libraries built with Autotools and CMake
- #87: OpenDHT does not build on armel
- #92: [DhtScanner] doesn t compile on LLVM 7.0.2
- #99: 0.6.2 filenames in 0.6.3
Pull requests:
- #73: dht: consider IPv4 or IPv6 disconnected on operation done
- #74: [packaging] support python installation with make DESTDIR=$DIR
- #84: [dhtnode] user experience
- #94: dht: make main store a vector>
- #94: autotools: versionning consistent with CMake
- #103: dht: fix sendListen loop bug
- #106: dht: more accurate name for requested nodes count
- #108: dht: unify bootstrapSearch and refill method using node cache
View by commits
You can have a look at my work by commits just by clicking this link:
https://github.com/savoirfairelinux/opendht/commits/master?author=sim590
What s left to be done
Data persistence
The only thing left before achieving the totality of my work is to rigorously
test the data persistence behavior to demonstrate the network traffic reduction.
To do so we use our benchmark python module. We are able to analyse traffic
and produce plots like this one:

Plot: 32 nodes, 1600 values with normal condition test.
This particular plot was drawn before the enhancements. We are confident to
improve the results using my work produced during the GSOC.
TCP
In the middle of the GSOC, we soon realized that passing from UDP to TCP would
ask too much efforts in too short lapse of time. Also, it is not yet clear if we
should really do that.
Queries
Issues:
- #43: DHT queries
Pull requests:
- #79: [DHT] Queries: remote values filtering
- 93: dht: return consistent query from local storage
- #106: [dht] rework get timings after queries in master
Value pagination
Issues:
- #71: [DHT] value pagination
Pull requests:
Indexation (feat. Nicolas Reynaud)
Pull requests:
General maintenance of OpenDHT
Issues:
- #72: Packaging issue for Python bindings with CMake: $DESTDIR not honored
- #75: Different libraries built with Autotools and CMake
- #87: OpenDHT does not build on armel
- #92: [DhtScanner] doesn t compile on LLVM 7.0.2
- #99: 0.6.2 filenames in 0.6.3
Pull requests:
- #73: dht: consider IPv4 or IPv6 disconnected on operation done
- #74: [packaging] support python installation with make DESTDIR=$DIR
- #84: [dhtnode] user experience
- #94: dht: make main store a vector>
- #94: autotools: versionning consistent with CMake
- #103: dht: fix sendListen loop bug
- #106: dht: more accurate name for requested nodes count
- #108: dht: unify bootstrapSearch and refill method using node cache
View by commits
You can have a look at my work by commits just by clicking this link:
https://github.com/savoirfairelinux/opendht/commits/master?author=sim590
What s left to be done
Data persistence
The only thing left before achieving the totality of my work is to rigorously
test the data persistence behavior to demonstrate the network traffic reduction.
To do so we use our benchmark python module. We are able to analyse traffic
and produce plots like this one:

Plot: 32 nodes, 1600 values with normal condition test.
This particular plot was drawn before the enhancements. We are confident to
improve the results using my work produced during the GSOC.
TCP
In the middle of the GSOC, we soon realized that passing from UDP to TCP would
ask too much efforts in too short lapse of time. Also, it is not yet clear if we
should really do that.
- #71: [DHT] value pagination
Indexation (feat. Nicolas Reynaud)
Pull requests:
General maintenance of OpenDHT
Issues:
- #72: Packaging issue for Python bindings with CMake: $DESTDIR not honored
- #75: Different libraries built with Autotools and CMake
- #87: OpenDHT does not build on armel
- #92: [DhtScanner] doesn t compile on LLVM 7.0.2
- #99: 0.6.2 filenames in 0.6.3
Pull requests:
- #73: dht: consider IPv4 or IPv6 disconnected on operation done
- #74: [packaging] support python installation with make DESTDIR=$DIR
- #84: [dhtnode] user experience
- #94: dht: make main store a vector>
- #94: autotools: versionning consistent with CMake
- #103: dht: fix sendListen loop bug
- #106: dht: more accurate name for requested nodes count
- #108: dht: unify bootstrapSearch and refill method using node cache
View by commits
You can have a look at my work by commits just by clicking this link:
https://github.com/savoirfairelinux/opendht/commits/master?author=sim590
What s left to be done
Data persistence
The only thing left before achieving the totality of my work is to rigorously
test the data persistence behavior to demonstrate the network traffic reduction.
To do so we use our benchmark python module. We are able to analyse traffic
and produce plots like this one:

Plot: 32 nodes, 1600 values with normal condition test.
This particular plot was drawn before the enhancements. We are confident to
improve the results using my work produced during the GSOC.
TCP
In the middle of the GSOC, we soon realized that passing from UDP to TCP would
ask too much efforts in too short lapse of time. Also, it is not yet clear if we
should really do that.
- #72: Packaging issue for Python bindings with CMake: $DESTDIR not honored
- #75: Different libraries built with Autotools and CMake
- #87: OpenDHT does not build on armel
- #92: [DhtScanner] doesn t compile on LLVM 7.0.2
- #99: 0.6.2 filenames in 0.6.3
- #73: dht: consider IPv4 or IPv6 disconnected on operation done
- #74: [packaging] support python installation with make DESTDIR=$DIR
- #84: [dhtnode] user experience
- #94: dht: make main store a vector>
- #94: autotools: versionning consistent with CMake
- #103: dht: fix sendListen loop bug
- #106: dht: more accurate name for requested nodes count
- #108: dht: unify bootstrapSearch and refill method using node cache
View by commits
You can have a look at my work by commits just by clicking this link:
https://github.com/savoirfairelinux/opendht/commits/master?author=sim590
What s left to be done
Data persistence
The only thing left before achieving the totality of my work is to rigorously
test the data persistence behavior to demonstrate the network traffic reduction.
To do so we use our benchmark python module. We are able to analyse traffic
and produce plots like this one:

Plot: 32 nodes, 1600 values with normal condition test.
This particular plot was drawn before the enhancements. We are confident to
improve the results using my work produced during the GSOC.
TCP
In the middle of the GSOC, we soon realized that passing from UDP to TCP would
ask too much efforts in too short lapse of time. Also, it is not yet clear if we
should really do that.
Data persistence
The only thing left before achieving the totality of my work is to rigorously
test the data persistence behavior to demonstrate the network traffic reduction.
To do so we use our benchmark python module. We are able to analyse traffic
and produce plots like this one:

Plot: 32 nodes, 1600 values with normal condition test.
This particular plot was drawn before the enhancements. We are confident to
improve the results using my work produced during the GSOC.
TCP
In the middle of the GSOC, we soon realized that passing from UDP to TCP would
ask too much efforts in too short lapse of time. Also, it is not yet clear if we
should really do that.

Plot: 32 nodes, 1600 values with normal condition test.

A new and unplanned release in quick succession. I have uploaded testing packages to experimental which incorporate
From the list of new packages I want to pick out the group of phf* packages that seem from a quick reading over the package documentations as very interesting.
But most important is the incorporation of tex4ht into the TeX Live packages, so please report bugs and shortcomings to the BTS. Thanks.
New packages
Gathering from some recent discussions it seems to be not that well
known that
Yesterday, I've released
Since GPG 2 was set as default for Debian (Sid, August 2016), an error message appeared inside jails triggered by chroot, when using debuild/debsign commands:

Like
My monthly report covers a large part of what I have been doing in the free software world. I write it for
Many people worked on finishing DEP 5. I think that the blog of
I was assigned another 14.7 hours of work by Freexian's Debian LTS
initiative and carried over 1 from last month. I worked a total of
15 hours, carrying over a fraction of an hour.
I spent another week in the Front Desk role and triaged various new
CVEs for wheezy.
I spent the remainder of the time working on the next Linux stable
updates (3.2.82 and Debian 3.2.81-2), but didn't release them - that
will be done in the next few days.
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:
Wrapping libudev using LD_PRELOAD
Peter Hutterer and I were chasing down an X server bug which was
exposed when running the libinput test suite against the X server with
a separate thread for input. This was crashing deep inside libudev,
which led us to suspect that libudev was getting run from multiple
threads at the same time.
I figured I'd be able to tell by wrapping all of the libudev calls
from the server and checking to make sure we weren't ever calling it
from both threads at the same time. My first attempt was a simple set
of cpp macros, but that failed when I discovered that libwacom was
calling libgudev, which was calling libudev.
Instead of recompiling the world with my magic macros, I created a new
library which exposes all of the (public) symbols in libudev. Each of
these functions does a bit of checking and then simply calls down to
the 'real' function.
Finding the real symbols
Here's the snippet which finds the real symbols: