My Free Software Activities in April 2016

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it’s one of the best ways to find volunteers to work with me on projects that matter to me.

Debian LTS

I handled a new LTS sponsor that wanted to see wheezy keep supporting armel and armhf. This was not part of our initial plans (set during last Debconf) and I thus mailed all teams that were impacted if we were to collectively decide that it was OK to support those architectures. While I was hoping to get a clear answer rather quickly, it turns out that we never managed to get an answer to the question from all parties. Instead the discussion drifted on the more general topic of how we handle sponsorship/funding in the LTS project.

Fortunately, the buildd maintainers said they were OK with this and the ftpmasters had no objections, and they both implicitly enacted the decision: Ansgar Burchardt kept the armel/armhf architectures in the wheezy/updates suite when he handled the switch to the LTS team, and Aurélien Jarno also configured wanna-build to keep building armel/armhf for the suite. The DSA team did not confirm that this change was not interfering with one of their plans to decommission some hardware. Build daemons are a shared resource anyway and a single server is likely to handle builds for multiple releases.

DebConf 16

This month I registered for DebConf 16 and submitted multiple talk/BoF proposals:

Kali Linux’s Experience of a Debian Derivative Based on Testing (Talk)
2 Years of Work of Paid Contributors in the Debian LTS Project (Talk)
Using Debian Money to Fund Debian Projects (BoF)

I want to share the setup we use in Kali as it can be useful for other derivatives and also for Debian itself to help smooth the relationship with derivatives.

I also want to open again the debate on the usage of money within Debian. It’s a hard topic but we should really strive to take some official position on what’s possible and what’s not possible. With Debian LTS and its sponsorship we have seen that we can use money to some extent without hurting the Debian project as a whole. Can this be transposed to other teams or projects? What are the limits? Can we define a framework and clear rules? I expect the discussion to be very interesting in the BoF. Mehdi Dogguy has agreed to handle this BoF with me.

Packaging

Django. I uploaded 1.8.12 to jessie-backports and 1.9.5 to unstable. I filed two upstream bugs (26473 and 26474) for two problems spotted by lintian.

Unfortunately, when I wanted to upload it to unstable, the test suite did not ran. I pinned this down to a sqlite regression. Chris Lamb filed #820225 and I contacted the SQLite and Django upstream developers by email to point them to this issue. I helped the SQLite upstream author (Richard Hipp) to reproduce the issue and he was quick to provide a patch which landed in 3.12.1.

Later in the month I made another upload to fix an upgrade bug (#821789).

GNOME 3.20. As for each new version, I updated gnome-shell-timer to ensure it works with the new GNOME. This time I spent a bit more time to fix a regression (805347) that dates back to a while and that would never be fixed otherwise since the upstream author orphaned this extension (as he no longer uses GNOME).

I have also been bitten by display problems where accented characters would be displayed below the character that follows. With the help of members of the GNOME team, we found out that this was a problem specific to the cantarell font and was only triggered with Harfbuzz 1.2. This is tracked in Debian with #822682 on harfbuzz and #822762 in fonts-cantarell. There’s a new upstream release (with the fix) ready to be packaged but unfortunately it is blocked by the lack of a recent fontforge in Debian. I thus mailed debian-mentors in the hope to find volunteers to help the pkg-fonts team to package a newer version…

Misc Debian/Kali work

Distro Tracker. I started to mentor Vladimir Likic who contacted me because he wants to contribute to Distro Tracker. I helped him to setup his development environment and we fixed a few issues in the process.

Bug reports. I filed many bug reports, most of them due to my work on Kali:

#820288: a request to keep the wordpress package installable in older releases (due to renaming of many php packages)
#820660: request support of by-hash indices in reprepro
#820867: possibility to apply overrides on already installed packages in reprepro
#821070: jessie to stretch upgrade problem with samba-vfs-modules
#822157: python-future hides and breaks python-configparser
#822669: dh_installinit inserts useless autoscript for System V init script when package doesn’t contain any
#822670: dh-systemd should be merged into debhelper, we have systemd by default and debhelper should have proper support for it by default

I also investigated #819958 that was affecting testing since it has been reported to Kali as well. And I made an NMU of dh-make-golang to fix #819472 that I reported earlier.

Thanks

See you next month for a new summary of my activities.

john kozacik says

May 18, 2016 at 6:02 pm

Raphaël , and other writers,
First of all, thank you for assembling and making available The Debian Administrator’s Handbook. I’m a scientist (Zoology, neurobiology) enjoying the final segment of his life by learning Debian/GNU/Linux. Work such as yours, and all the other sources of documentation I’ve been able to locate, are valuable assets for anyone who wants to learn how to leverage this amazing, growing technological achievement. I would like to offer the following observations in the hopes that they may make your efforts even more valuable to their consumers.
Reading an effective technical communication not only produces an understanding of the subject under study but is also a joy. Creating documents that offer this is difficult. My own insight here came from a course I took where there were two textbooks assigned. One was newly published by two of the rising stars in the field and it was filled with the latest findings, the other was comparatively small as well as being an 8 year-old text. Yet, the small and old text was vastly more informative and took much less time to understand. This made me aware of the enormous value of good technical writing, and started me on a quest to find out what it was that made excellent writing and to learn how to produce such writing myself.
As I progressed in my studies of the nervous system, I began learning how to use computer technology, incorporating it in support of my research pursuits. When I got to where I was writing code, that job was simple because I always had a framework in hand that kept me on course: my experimental design. That design always made it clear what I wanted the code to achieve. In a 10-year period outside of academia, where I worked in the consumer-products industry developing department-level information systems, I was astounded to find the high failure rate seen in such efforts – and the reason was obvious: In that environment people worked by throwing technology in the direction of the client’s need and stopped when they got a buy-in from the client. Carrying the practices I had developed in academia into the business world, I produced the documentation first, and when the user/client/… realized what it was they were asking for, use that description to implement the technology. I created an ontology that the user was able to recognized in order to communicate with the user, and then developed that ontology into appropriate levels of detail, right down to the implementation. Such maps (ontologies) can be developed to abstract any system to any level of detail – and everyone understands a map when they are familiar with it’s context.

What I see working with the documentation available in Debian/GNU/Linux is that this documentation is an afterthought to the code. What is going to produce effective documentation is the understanding that the abstraction of the code that the documentation is supposed to represent needs to be as clear and efficient as the code it’s describing. It should take the reader down a path that is simplest, most direct and unambiguous means to the goal. This text should be as excellent as the code itself – if the writer can’t write text that does that then they can’t communicate effectively about the technology.
To develop technology the worker must be informed by a broad foundation of mathematics and experience with complex stems. To develop documentation the writer must be informed with sound understanding of the language and a broad foundation in the many ways that that language is used.

As something concrete, I offer:
Anne Eisengert, a professor at Polytechnic University in Brooklyn, NY, has authored at least four books on scientific writing. She wrote a one page essay on ‘keeping up with computerese’ in the August 1993 issue of Scientific American that’s worth reading, in support of the above.

Comments

john kozacik says

May 18, 2016 at 6:02 pm

Raphaël , and other writers,
First of all, thank you for assembling and making available The Debian Administrator’s Handbook. I’m a scientist (Zoology, neurobiology) enjoying the final segment of his life by learning Debian/GNU/Linux. Work such as yours, and all the other sources of documentation I’ve been able to locate, are valuable assets for anyone who wants to learn how to leverage this amazing, growing technological achievement. I would like to offer the following observations in the hopes that they may make your efforts even more valuable to their consumers.
Reading an effective technical communication not only produces an understanding of the subject under study but is also a joy. Creating documents that offer this is difficult. My own insight here came from a course I took where there were two textbooks assigned. One was newly published by two of the rising stars in the field and it was filled with the latest findings, the other was comparatively small as well as being an 8 year-old text. Yet, the small and old text was vastly more informative and took much less time to understand. This made me aware of the enormous value of good technical writing, and started me on a quest to find out what it was that made excellent writing and to learn how to produce such writing myself.
As I progressed in my studies of the nervous system, I began learning how to use computer technology, incorporating it in support of my research pursuits. When I got to where I was writing code, that job was simple because I always had a framework in hand that kept me on course: my experimental design. That design always made it clear what I wanted the code to achieve. In a 10-year period outside of academia, where I worked in the consumer-products industry developing department-level information systems, I was astounded to find the high failure rate seen in such efforts – and the reason was obvious: In that environment people worked by throwing technology in the direction of the client’s need and stopped when they got a buy-in from the client. Carrying the practices I had developed in academia into the business world, I produced the documentation first, and when the user/client/… realized what it was they were asking for, use that description to implement the technology. I created an ontology that the user was able to recognized in order to communicate with the user, and then developed that ontology into appropriate levels of detail, right down to the implementation. Such maps (ontologies) can be developed to abstract any system to any level of detail – and everyone understands a map when they are familiar with it’s context.

What I see working with the documentation available in Debian/GNU/Linux is that this documentation is an afterthought to the code. What is going to produce effective documentation is the understanding that the abstraction of the code that the documentation is supposed to represent needs to be as clear and efficient as the code it’s describing. It should take the reader down a path that is simplest, most direct and unambiguous means to the goal. This text should be as excellent as the code itself – if the writer can’t write text that does that then they can’t communicate effectively about the technology.
To develop technology the worker must be informed by a broad foundation of mathematics and experience with complex stems. To develop documentation the writer must be informed with sound understanding of the language and a broad foundation in the many ways that that language is used.

As something concrete, I offer:
Anne Eisengert, a professor at Polytechnic University in Brooklyn, NY, has authored at least four books on scientific writing. She wrote a one page essay on ‘keeping up with computerese’ in the August 1993 issue of Scientific American that’s worth reading, in support of the above.