The debmans package I had so lovingly worked on last month is now officially abandoned. It turns out that another developer, Michael Stapelberg wrote his own implementation from scratch, called debiman.
Both software share a similar design: they are both static site
generators that parse an existing archive and call another tool to
convert manpages into HTML. We even both settled on the same converter
mdoc). But while I wrote
debmans in Python,
debiman is written
debiman also seems much faster, being
written with concurrency in mind from the start. Finally,
more feature complete: it properly deals with conflicting packages,
localization and all sorts redirections. Heck, it even has a pretty
logo, how can I compete?
debmans was written first and was in the process of being
deployed, I had to give it up. It was a frustrating experience because
I felt I wasted a lot of time working on software that ended up being
discarded, especially because I put so much work on it, creating
extensive documentation, an almost complete test suite and even
filing a detailed core infrastructure best practices report In the
end, I think that was the right choice: debiman seemed clearly
superior and the best tool should win. Plus, it meant less work for
me: Michael and Javier (the previous
did all the work of putting the site online. I also learned a lot
about the CII best practices program,
and, ultimately, the Go programming language itself, which I'll refer
to as Golang for brievity.
debiman definitely brought Golang
into the spotlight for me. I had looked at Go before, but it seemed to
be yet another language. But seeing Michael beat me to rebuilding the
service really made me look at it again more seriously. While I really
appreciate Python and I will probably still use it as my language
of choice for GUI work and smaller scripts, but for daemons, network
programs and servers, I will seriously consider Golang in the future.
This obviously brings me to the latest project I worked on, Wallabako, my first Golang program ever. Wallabako is basically a client for the Wallabag application, which is a free software "read it later" service, an alternative to the likes of Pocket, Pinboard or Evernote. Back in April, I had looked downloading my "unread articles" into my new ebook reader, going through convoluted ways like implementing OPDS support into Wallabag, which turned out to be too difficult.
Instead, I used this as an opportunity to learn Golang. After reading the quite readable golang specification over the weekend, I found the language to be quite elegant and simple, yet very powerful. Golang feels like C, but built with concurrency and memory (and to a certain extent, type) safety in mind, along with a novel approach to OO programming.
The fact that everything can be compiled in one neat little static binary was also a key feature in selecting golang for this project, as I do not have much control over the platform my E-Reader is running: it is a Linux machine running under the ARM architecture, but beyond that, there isn't much available. I couldn't afford to ship a Python interpreter in there and while there are solutions there like pyinstaller, I felt that it may be so easy to deploy on ARM. The borg team had trouble building a ARM binary, restoring to tricks like building on a Raspberry PI or inside an emulator. In comparison, the native go compiler supports cross-compilation out of the box through a simple environment variable.
So far Wallabako works amazingly well: when I "bag" a new article in Wallabag, either from my phone or my web browser, it will show up on my ebook reader then next time I open the wifi. I still need to "tap" the screen to fake the insertion of the USB cable, but we're working on automating that. I also need to make the installation of the software much easier and improve the documentation, because so far it's unlikely that someone unfamiliar with Kobo hardware hacking will be able to install it.
According to Github, I filed a bunch of bugs all over the place (25 issues in 16 repositories), sent patches everywhere (13 pull requests in 6 repositories), and tried to fix everythin (created 38 commits in 7 repositories). Note that excludes most of my work, which happens on Gitlab. January was still a very busy month, especially considering I had an accident which kept me mostly offline for about a week.
Here are some details on specific projects.
After much discussions, it was decided to fork the linkchecker project, which now lives in its own organization. I still have to write community guidelines and figure out the best way to maintain a stable branch, but I am hopeful that the community will pick up the project as multiple people volunteer to co-maintain the project. There has already been pull requests and issues reported, so that's a good sign.
I re-rolled my pull requests to the feed2tweet project: last time they were closed before I had time to rebase them. The author was okay with me re-submitting them, but he hasn't commented, reviewed or merged the patches yet so I am worried they will be dropped again.
At that point, I would more likely rewrite this from scratch than try to collaborate with someone that is clearly not interested in doing so...
- calibre 2.75.1 backport - thanks to Nicholas Steeves for finding out about the security issues as well!
- dnsdiag 1.4.0 - sponsored,
in NEW, now in unstable!
- monkeysign 2.2.3 - a quick bugfix release to ship a good version in stretch, now finally with GnuPG 2.x support!
- pepper 0.3.3-3 - just regular package maintenance
- tty-clock 2.3 - new upstream release, also got access to the upstream project
- tuptime 3.3.1 - sponsored
This month I worked on a few issues, but they were big issues, so they took a lot of time.
I have done a lot of work trying to backport the heading sanitization patches for CVE-2016-8743. The full report explain all the gritty details, but I ran out of time and couldn't upload the final version either. The issue mostly affects Apache servers in proxy configurations so it's not so severe as to warrant an immediate upload anyways.
Finally, there was a small discussion surrounding tools to use when building and testing update to LTS packages. The resulting conversation was interesting, but it showed that we have a big documentation problem in the Debian project. There are a lot of tools, and the documentation is old and distributed everywhere. Every time I want to contribute something to the documentation, I never know where to start or go. This is why I wrote a separate debian development guide instead of contributing to existing documentation...