This is my 5th month working on Debian LTS, started by Raphael Hertzog at Freexian. This is my largest month so far, in which I worked on completing the Xen and NSS packages updates from last month, but also spent a significant amount of time working on phpMyAdmin and libidn.
This basically consisted on following up on the reviews from other security people. I basically continued building up on Brian's work and tested the package on a test server at Koumbit, which seems to have survived well the upgrade. The details are in this post to the debian-lts mailing list.
As for NSS, the package was mostly complete, but I forgot to ship the tests for some reason, so I added them back. I also wrote the release team to see if it was possible to update NSS to the same version in all suites. Unfortunately, this issue is still pending, but I still hope we can find better ways of managing that package in the long term.
Most of my time this month was spent working on IDN and
phpMyAdmin. Unfortunately, it turns out that
someone else had worked on the libidn package. This is partly my
fault: I forgot to check in the
dsa-needed.txt file for assignment
before working on the package. But considering how in flux the
workflow currently is with the switch between the main security team
and the LTS team for the wheezy maintenance, I don't feel too
bad. Still, I prepared a package which was a bit more painful than
it should have been because of GNUlib. I didn't even know about
GNUlib before, oddly enough, and after that experience, I feel that it
should just not exist at all anymore. I have filed a bug to
remove that dependency at the very least, but I do not clearly see
how such a tool is necessary on Debian at this point in time.
But phpMyAdmin, no one had worked on that. And I understand why:
even though it's a very popular package, there were quite a few
outstanding issues (8!) in Wheezy, with 10-15 patches to be
ported. Plus, it's ... well, PHP. And old PHP at that, with parts of
it with modern autoloader classes, and other with mixed HTML and PHP
require (and not
require_once) and all sorts of nasty
things you still find in the PHP universe. I nevertheless managed to
produce a new Debian package for wheezy and test it on Koumbit's
test servers. Hopefully, that can land into Wheezy soon.
I am a little worried that we are, both in Jessie and Wheezy sitting in between stable releases for phpMyAdmin, something that is a recurring issue for a lot of packages in Debian stable or LTS. Sometimes, it just happens that the version that happens to be in Debian testing when it is released as stable is just not a supported release upstream. It's the case for phpMyAdmin in Jessie (4.3, whereas 4.0 and 4.4 are supported) and Wheezy (3.4, although it's unclear how long that was supported upstream). But even if the next Debian stable (Stretch), would pick a stable release upstream, there is actually no phpMyAdmin release that has a support window as long as Debian stable (roughly 3 years), let alone as long as Debian LTS (5 years).
This is a similar problem with NSS: upstream is simply not supporting their product in the long term, or at least not in the terms we are used to in the Debian community (ie. only security fixes or regressions). This is, in my opinion, a real concern for the reliability and sustainability of the computing infrastructure we are creating. While some developers are of the opinion that software older than 18 months is too old, here we are shipping hardware and software in space or we have Solaris, which is supported for 16 years! Now that is a serious commitment and something we can rely on. 18 months is really, really, a tiny short time in the history of our civilization. I know computer programmers and engineers like to think of themselves in elitist terms, that they are changing the world every other year. But the truth is that things have not changed much in the last 4 decades where computing has existed, both in terms of security or functionality. Two quotes from my little quotes collection come to mind here:
Software gets slower faster than hardware gets faster. - Wirth's law
The future is already here – it's just not very evenly distributed. - William Gibson
Because of course, the response to my claims that computing is not really advancing is "but look! we have supercomputers in our pockets now!" Yes, of course, we do have those fancy phones and they are super-connected, but they are a threat to our fundamental rights and freedom. And those glittering advances always pale in comparison to what could be done if we wouldn't be wasting our time rewriting the same software over and over again on different, often proprietary, platforms, simply because of the megalomaniac fantasies of egoistic programmers.
It would be great to build something that lasts, for a while. Software that does not need to be updated every 16 months. You'd think that something as basic as a screensaver release could survive what is basically the range of human infancy. Yet it seems we like to run mindlessly in the minefield of software development, one generation following the other without questioning the underlying assumption of infinite growth that permeates our dying civilization.
I have talked about this before of course, but working with the LTS project just unnerves me so bad that I just needed to let out another rant.
(For the record, I really have a lot of respect for JWZ and all the work he has done in the free software world. I frequently refer to his "no-bullshit" backup guide and use Xscreensaver daily. But I do think he was wrong in this case: asking Debian to remove Xscreensaver is just too much. The response from the maintainer was exemplary of how to handle such issues in the future. I restarted Xscreensaver after the stable update, and the message is gone, and things are still all fine. Thanks JWZ and Tormod for keeping things rolling.)
With that in mind, I obviously didn't stop doing other computing work this month. In fact, I did a lot of work to try to generally fix the internet, that endless and not-quite-gratifying hobby so many of us are destroying our bodies to accomplish.
I have experimented a bit more with different build tools. I got worried because at some point cowbuilder got orphaned and I figured I could refresh the way I build packages for LTS. I looked into sbuild, but that ended up not bringing much improvements over my current cowbuilder setup (which I really need to document better). I was asked by the new maintainer to open a bug report to make such setups easier by guessing the basepath better, so we'll see how that goes.
I did enjoy the simplicity of gitpkg and discovered cowpoke
which made it about 2 times faster to build packages because I could
use another server to build larger packages. I also found that gitpkg
-n by default when calling gzip, which makes it harder
to reproduce tarballs when they are themselves built reproducibly,
which is the case for Github tarballs (really nice of them). So I
filed bug #820842 about that.
It would be pretty awesome if such buildds would be available for
Debian Developers to do their daily tasks. It could simply be a
machine that would spin up a chroot with
cowbuilder or it could even
be a full, temporary VM although that would take way more resources
than a simple VM with a cowbuilder setup.
In the meantime, I should probably look at whalebuilder as an alternative to cowbuilder. It is a tool that supports building packages within a Docker chroot, which means that packages are built from a clean environment like pbuilder, and using COW optimisations but also without privileges or network access, which is a huge plus especially when you build untrusted packages.
I have done some work to implement Moinmoin-like admonitions in Ikiwiki, something I am quite happy about since it's something I was really missing about Moinmoin. Admonitions bring a really nice way to outline certain blocks with varying severity levels and distinct styles. For example:
This was done with a macro, but basically, since Markdown allows more
or less arbitrary HTML, this can also be done with the
<div> tag. I
like that we don't have a new weird markup here. Yet, I still liked
the sub-parser feature of MoinMoin, something that can be implemented
in Ikiwiki, but it's a little more clunky. Normally, you'd probably do
this with the inline macro and subpages, but it's certainly less
intuitive that directly inlined content.
I got a new e-reader! I was hesitant between the Kobo Aura H20 and the Kobo Glo HD, which were the ones available at Bestbuy. So I bought both and figured I would return the other. That was a painful decision! In the end, both machines are pretty nice:
- Aura H2O
- larger screen (makes it easier to see web pages and better for the eyes)
- naturally drawn to it
- larger (fits in outside pocket though)
- port cover finicky
- more expensive (180$) - prices may go down in future
- Aura Glo HD
- smaller (fits in inside pocket of both coats)
- better resolution in theory (can't notice in practice)
- cheaper (100$)
- may be less common on the future (larger models more common? just a guess)
- no SD card
- smaller screen
- power button in the middle
... but in the end, I ended up settling down on the Glo, mostly for the price. Heck, I saved around 100$, so for that amount, I could have gotten two machines so that if one breaks I would still have the other. I have ordered a cover for it on Deal Extreme about two weeks ago, and it still hasn't arrived. I suspect it's going to take a few more months to get there, by which point I may have changed e-reader again.
Note that both e-readers needed an update to calibre, so I started working on a calibre backport (#818309) which I will complete soon.
So anyways, I looked into better ways of transferring articles from the web to the e-reader, something which I do quite a bit to avoid spending too much time on the computer. Since the bookmark manager I use (Bookie) is pretty much dead, I started looking at other alternatives. And partly inspired by Framasoft's choice of Wallabag for their bookmarking service (Framabag), I started to look into that software, especially since my friend who currently runs the Bookie instance is thinking of switching to Wallabag as well.
It seems the simplest way to browse articles remotely through a standard protocol is by implementing OPDS support in Wallabag. OPDS is a standard developed in part by the Internet Archive and it allows for browsing book collections and downloading them. Articles and bookmarks would then be presented as individual books that would be accessible from any OPDS-compatible device.
Unfortunately, the Kobo e-readers don't support OPDS out of the box: you need to setup some OPDS-compatible reader like Koreader. And that I found nearly impossible to do: I was able to setup KSM (the "start menu", not to be confused with that KSM), but not Koreader in KSM. Besides, I do not want a separate OS running here on the tablet: I just want to start Koreader every once in a while. KSM just starts another system when you reboot the e-reader, something which is not really convenient on the Kobo.
Basically, I just want to add Koreader as a tile in the home screen on the e-reader. I found the documentation on that topic to be sparse and hard to follow. It is often dispersed across multiple forum threads and involves uploading random binaries, often proprietary, to the e-reader. It had been a long time since I was asked to "register my software" frenetically, and I hadn't missed that one bit. So I decided to stay away from this until that solution and its documentation matures a bit.
I have worked a bit on my home radio stream. I simply turned the Liquidsoap stream back online, and did a few tweaks to the documentation that I had built back then. All that experimenting led me to do two NMUs. One was for gmpc-plugins to fix a FTBFS (bug #807735) and to properly kill the shout streamer when completing the playback (bug #820908).
The other was to fix the ezstream manpage (bug #573928), a patch that had been sitting there for 5 years! This was to try to find an easy way to stream random audio (say from a microphone) to the Icecast server, something which is surprisingly difficult, consider how basic that functionality is. I was surprised to see that Darkice just completely fails to start (bug #821040) and I had to fallback to the simplest ices2 software to stream the audio.
I am still having issues with Liquidsoap: it's really unstable! As a server, I would expect it to keep running for days if not years. Unfortunately, there's always something that makes it crash. I had assertion failed (bug #821112) and I keep seeing it crash after 2-3 days fairly reliably, a bug I reported 3 years ago and that is still not fixed (bug #727307).
Switching back the stream to Vorbis (because I was having problems
with the commandline mp3 players and
ogg123 is much more
lightweight) created another set of problems too, this time with the
phone. It seems that Android cannot stream Vorbis at all,
something that is even worse in Cyanogenmod... I also had to tweak my
MPD config to make the Android client be able to load the larger
playlists (see dmix buffer is full).
So I have also done quite a bit of work again on my phone. I finally was told how to access from Termux from adb shell which is pretty cool because now I can start a screen on my phone and then, when I'm tired of tapping to type, I can just reconnect to it when I plug in a USB cable on my laptop. I sent a pull request to fix the documentation regarding that.
I also tried to see how my SMS and Signal situation could be improved. Right now, I have two different apps to do SMS on my phone: I use both Signal and the VoIP.ms SMS client, because I do not have a contract or SIM card in my phone. Both work well independently, but it's somewhat annoying to have to switch between the two.
(In fact, I feel that Signal itself has an issue with how it depends on the network to send encrypted messages: I often have to "ping" people in clear text (and therefore in the other app) so that they connect to their data plan to fetch my "secure" signal messages...)
Anyways, I figured it would be nice if at least there would be a SMS fallback in Signal that would allow me to send regular text messages from signal through Voip.MS. That was dismissed really fast. Moxie even closed the conversation completely, something I had never experienced before, and doesn't feel exactly pleasant. The Voip.MS side was of course not impressed and basically shrugged it off because Signal was not receptive.
I also tried to clear up the Libresignal confusion: there are 3 different projects named "Libresignal", and I am not sure I figured out the right thing, even though the issue is now closed and there's a FAQ that is supposed to make all that clear. Nevertheless, I opened two distinct feature requests to try to steer the conversation into a more productive direction: GCM-less calls and GCM support. But I'm not sure neither will go anywhere.
In the meantime, I am using the official signal client, which I downloaded using gplaycli and which I keep up to date with Aptoide. Even though the reliability of that site is definitely questionable, it seems that once you have a trusted version, it is safe to upgrade, regardless of the source because there is a trust path between you and the developer.
I also filed a few issues with varying levels of success/response from the community:
- Green address feature requests: pin change and pin confirmation
- AntennaPod icons are reversed, but apparently, I'm the one that's backwards, go figure
- Asked for NYC support in the excellent Transportr app, it seems that's not going to happen until I find the space to run the Android dev environment...
And then there's of course the monthly background noise of all the projects I happened to not only stumble on, but also file bugs or patches against:
- neomutt credits improvements: Neomutt is an amazing effort to converge all the Mutt third party patches in a common tree
- request to improve acme comparison: acme is an interesting go client for Let's Encrypt
- a small set of issues and patches for borg, mostly documentation:
- finally filed a bug report in debian about symlink support in ncdu
- internationalization SNAFUs:
- classic "my printer is not working" never ending story: printing fails by default with "cannot open printer description file"
- small fixes to the tuptime project, which i mentionned before
- last nit-picking: znc homepage errors