Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 2 hours 57 min ago

Steve Kemp: I've built a product, not a project

2 February, 2017 - 14:15

The past few days I've been doing more arduino-work. In between dying of sleep-exhaustion.

One thing that always annoyed me was that I had to hard-code my WiFi credentials in my projects, with code like this:

// Connect to the SCOTLAND network
WiFi.begin("SCOTLAND", "highlander1");

// Attempt to connect - TODO: Timeout on failure
while (WiFi.status() != WL_CONNECTED)

// Now we're connected show the local IP address.
lcd.print("WiFi connected  ");

Whilst looking at another project I found a great solution though. There is a library called WiFiManager which behaves perfectly:

  • If you've stored connection details it will connect to the local WiFI network using those, automatically.
  • If you've not saved previous connection details it will instead configure the device to work as an Access Point
    • You can then connect to that access point and see a list of local WiFi networks.
    • Choose the appropriate one from the list, enter your password, and these details are saved for the future.
    • The device will then reset, join the network via your saved choices and acquire an IP via DHCP as you'd expect.

The code for this is beautifully simple:

// Connect to WiFI with saved credentials, if any.
// Otherwise work as an access-point, named TRAM-TIMES, and
// let the user fill out their details.
WiFiManager wifiManager;

This means my current project, which continues to revolve around tram-times, is so very much more user-friendly. It is a product you could package and take to a friends house, not a project you have to recompile to tweak.

For that reason, user-niceness, I reworked the on-board HTTP status-page to use bootstrap, be themed, and look nicer. Other than being housed in a horrid case the project actually looks like a product. Not one I'd buy, but neither one I'm ashamed of sharing.

Paul Wise: FLOSS Activities January 2017

2 February, 2017 - 07:29
Changes Issues Review Administration
  • Debian: reboot 1 non-responsive VM, redirect 2 users to support channels, redirect 1 contributor to xkb upstream, redirect 1 potential contributor, redirect 1 bug reporter to mirror team, ping 7 folks about restarting processes with upgraded libs, manually restart the sectracker process due to upgraded libs, restart the package tracker process due to upgraded libs, investigate failures connecting to the XMPP service, investigate /dev/shm issue on abel.d.o, clean up after rename of the fedmsg group.
  • Debian mentors: lintian/security updates & reboot
  • Debian packages: deploy 2 contributions to the live server
  • Debian wiki: unblacklist 1 IP address, whitelist 10 email addresses, disable 18 accounts with bouncing email, update email for 2 accounts with bouncing email, reported 1 Debian member as MIA, redirect 1 user to support channels, add 4 domains to the whitelist.
  • Reproducible builds: rescheduled Debian pyxplot:amd64/unstable for themill.
  • Openmoko: security updates & reboots.
Debian derivatives
  • Send the annual activity ping mail.
  • Happy new year messages on IRC, forward to the list.
  • Note that SerbianLinux does not provide source packages.
  • Expand URL shortener on SerbianLinux page.
  • Invite PelicanHPC, Netrunner, DietPi, Hamara Linux (on IRC), BitKey to the census.
  • Add research publications link to the census template
  • Fix Symbiosis sources.list
  • Enquired about SalentOS downtime
  • Fixed and removed some 404 BlankOn links (blog, English homepage)
  • Fixed changes to AstraLinux sources.list
  • Welcome Netrunner to the census

I renewed my support of Software Freedom Conservancy.

The openchange 1:2.2-6+deb8u1 upload was sponsored by my employer. All other work was done on a volunteer basis.

Iustin Pop: The snow is gone

2 February, 2017 - 05:25

Almost all traces of the snow are gone.

After a very dry December, January was an awesome month. Lots of snow, even in the city, that held for (I think) three weeks—very rare for Zürich. This happened because the temperature never went above -5°C, even during the day—proper winter for the city!

It was awesome to bike in these conditions. At first fresh snow (best! but slow), then packed snow, it never actually became dangerous ice.

And then, at the end of last week, temperatures started climbing. First near zero, then 1-2°C above, then it finally started going warm (above freezing even during the night). And the snow started melting a bit, then more, and then it started raining.

And it rained for three days. The worst thing, seeing snow being rained upon. Dirty grey snow, slowly melting away… I don't like this picture.

At least now the snow is gone, and the streets are almost dry, and we can look to either some more snow (I wish…) or spring.

I'd rather take -2°C global average temperatures than +2°C. I'm not sure what -5° would mean, but compared to no winter…

Lars Wirzenius: Hacker Noir, chapter 2: Development setup phase

1 February, 2017 - 18:29

It is a new month, and time to publish the next chapter in Hacker Noir. This is chapter 2, titled "Development setup phase". I hope you enjoy it. Feedback via email, irc,, twitter are welcome. Or come talk to me at FOSDEM if you're there.

Wouter Verhelst: Resetting a Raspberry Pi to default using Ansible

1 February, 2017 - 17:19

I got myself a bunch of Raspberry Pi 3s a short while ago:

...the idea being that I can use those to run a few experiments on. After the experiment, I would need to be able to somehow remove the stuff that I put on them again. The most obvious way to do that is to reimage them after every experiment; but the one downside of the multi-pi cases that I've put them in is that removing the micro-SD cards from the Pis without removing them from the case, while possible, is somewhat fiddly. That, plus the fact that I cared more about price than about speed when I got the micro-SD cards makes "image all the cards of these Raspberry Pis" something I don't want to do every day.

So I needed a different way to reset them to a clean state, and I decided to use ansible to get it done. It required a bit of experimentation, but eventually I came up with this:

- name: install package-list fact
  hosts: all
  remote_user: root
  - name: install libjson-perl
      pkg: libjson-perl
      state: latest
  - name: create ansible directory
      path: /etc/ansible
      state: directory
  - name: create facts directory
      path: /etc/ansible/facts.d
      state: directory
  - name: copy fact into ansible facts directory
      dest: /etc/ansible/facts.d/allowclean.fact
      src: allowclean.fact
      mode: 0755

- name: remove extra stuff
  hosts: pis
  remote_user: root
  - apt: pkg={{ item }} state=absent purge=yes
    with_items: "{{ ansible_local.allowclean.cleanable_packages }}"

- name: remove package facts
  hosts: pis
  remote_user: root
  - file:
      path: /etc/ansible/facts.d
      state: absent
  - apt:
      pkg: libjson-perl
      state: absent
      autoremove: yes
      purge: yes

This ansible playbook has three tasks. The first task installs a custom ansible fact (written in perl) that emits a json file which defines cleanable_packages as a list of packages to remove. The second uses that fact to actually remove those packages; and the third removes the fact (and the libjson-perl library we used to produce the JSON).

Which means, really, that all the hard work is done inside the allowclean.fact file. That looks like this:


use strict;
use warnings;
use JSON;

open PACKAGES, "dpkg -l|";

my @packages;

my %whitelist = (

while(<PACKAGES>) {
    next unless /^ii\s+(\S+)/;

    my $pack = $1;

    next if(exists($whitelist{$pack}));

    if($pack =~ /(.*):armhf/) {
        $pack = $1;

    push @packages, $1;

my %hash;

$hash{cleanable_packages} = \@packages;

print to_json(\%hash);

Basically, we create a whitelist, and compare the output of dpkg -l against that whitelist. If a certain package is in the whitelist, then we don't add it to our "packages" list; if it isn't, we do.

The whitelist is just a list of package => 1 tuples. We just need the hash keys and don't care about the data, really; I could equally well have made it package => undef, I suppose, but whatever.

Creating the whitelist is not that hard. I did it by setting up one raspberry pi to the minimum that I wanted, running

dpkg -l|awk '/^ii/{print "\t\""$2"\" => 1,"}' > packagelist

and then adding the contents of that packagelist file in place of the ... in the above perl script.

Now whenever we apply the ansible playbook above, all packages (except for those in the whitelist) are removed from the system.

Doing the same for things like users and files is left as an exercise to the reader.

Side note: ... is a valid perl construct. You can write it, and the compiler won't complain. You can't run it, though.

Daniel Pocock: Going to FOSDEM, Brussels this weekend

1 February, 2017 - 16:07

This weekend I'm going to FOSDEM, one of the largest gatherings of free software developers in the world. It is an extraordinary event, also preceded by the XSF / XMPP Summit

For those who haven't been to FOSDEM before and haven't yet made travel plans, it is not too late. FOSDEM is a free event and no registration is required. Many Brussels hotels don't get a lot of bookings on weekends during the winter so there are plenty of last minute offers available, often cheaper than what is available on AirBNB. I was speaking to somebody in London on Sunday who commutes through St Pancras (the Eurostar terminal) every day and didn't realize it goes to Brussels and only takes 2 hours to get there. One year I booked a mini-van at the last minute and made the drive from the UK with a stop in Lille for dinner on the way back, for 5 people that was a lot cheaper than the train. In other years I've taken trains from Switzerland through Paris or Luxembourg.

Real-time Communication (RTC) dev-room on Saturday, 4 February

On Saturday, we have a series of 23 talks about RTC topics in the RTC dev-room, including SIP, XMPP, WebRTC, peer-to-peer (with Ring) and presentations from previous GSoC students and developers coming from far and wide.

The possibilities of RTC with free software will also be demonstrated and discussed at the RTC lounge in the K building, near the dev-room, over both Saturday and Sunday. Please come and say hello.

Please come and subscribe to the Free-RTC-Announce mailing list for important announcements on the RTC theme and join the Free-RTC discussion list if you have any questions about the activities at FOSDEM, dinners for RTC developers on Saturday night or RTC in general.

Software Defined Radio (SDR) and the Debian Hams project

At 11:30 on Saturday I'll be over at the SDR dev-room to meet other developers of SDR projects such as GNU Radio and give a brief talk about the Debian Hams project and the relationship between our diverse communities. Debian Hams (also on the Debian Ham wiki) provides a ready-to-run solution for ham radio and SDR is just one of its many capabilities.

If you've ever wondered about trying the RTL-SDR dongle or similar projects Debian Hams provides a great way to get started quickly.

I've previously given talks on this topic at the Vienna and Cambridge mini-DebConfs (video).

Ham Radio (also known as amateur radio) offers the possibility to gain exposure to every aspect of technology from the physical antennas and power systems through to software for a range of analog and digital communications purposes. Ham Radio and the huge community around it is a great fit with the principles and philosophy of free software development. In a world where hardware vendors are constantly exploring ways to limit their users with closed and proprietary architectures, such as DRM, a broad-based awareness of the entire technology stack empowers society to remain in control of the technology we are increasingly coming to depend on in our every day lives.

Russ Allbery: Review: A Closed and Common Orbit

1 February, 2017 - 12:24

Review: A Closed and Common Orbit, by Becky Chambers

Series: Wayfarers #1 Publisher: Harper Voyager Copyright: October 2016 ISBN: 0-06-256942-2 Format: Kindle Pages: 384

A Closed and Common Orbit has two threads, one that takes place twenty years in the past and one that happens simultaneously with the very end of The Long Way to a Small, Angry Planet. That second part is the motivating plot thread, but it's unfortunately impossible to talk about in any depth without seriously spoiling the previous book. You could otherwise read them out of order, but I think the previous book is too good to spoil, so you want to carefully avoid reading any descriptions of this book until after you've read The Long Way to a Small, Angry Planet.

Per my normal review policy, I'm going to try to avoid spoilers, but just about everything about half of this book would give away spoilers if you're paying attention. So you may want to just go read the other book before reading this review. (It's excellent!)

The part that I can safely say is that half this book is about Pepper, her partner Blue, Pepper's store and Blue's art, and her attempt to help a friend find a place and a sense of identity that she'd never asked for or expected, while keeping a very dangerous secret. That friend starts somewhat passive, but one of the things I liked the most about this story is that Pepper is neither always right in her advice nor always wrong. Sidra is wrong about some of the limitations that she thinks she has and some of the things she thinks she wants, but she's also right about other things where Pepper is wrong. She has a complicated, careful, and courageous journey.

The best part of this book for me, though, was the other half, told in alternating chapters with Sidra's story. This is Pepper's own backstory, which is rather awful (although Chambers does avoid being too graphic about the most horrible parts), but is also an amazing story of someone finding her own power, her own skills, and her own identity. And building a relationship that's something quite special. At first, this seems only vaguely related to Sidra's story and the other half of the book, but they both come together in a way that's both heartbreaking and wonderful.

I found this story particularly wonderful because one of my favorite SF tropes is sentient computers or sentient ships, which play a significant role in Pepper's backstory. And one of my favorite characters to read about is the technician who can cobble together fixes to things and who is always finding something to repair. Pepper is a delight, her story explains so much about how she became the person she is (and adds so much emotional heft to it), and she has a relentless, practical determination that I loved reading about.

A Closed and Common Orbit doesn't have the sprawling cast of The Long Way to a Small, Angry Planet. The story is tightly focused on five characters. I think I liked that even better than the previous book, even when I was finding Sidra a bit too passive and not as interesting. Chambers's characters have so much depth, thoughtfulness, and basic decency, while still being uniquely themselves, that I feel like I could read about them for months and keep uncovering new, interesting facets. I particularly loved the occasional excerpts from the chat system where Pepper hangs out (and would have loved about three times more of them). Speaking as someone who spends a lot of time in chat, Chambers got the tone just about perfect.

Just about the only complaint I have about this book is that I thought the ending was too abrupt. It's so important, the climax of Pepper's story and a hugely significant piece of character development, and I wanted more than the short scene and aftermath we got. I really wanted to spend some time feeling with the characters, savoring the emotional release. Another three or four pages would have been greatly appreciated.

The Long Way to a Small, Angry Planet was a happy surprise in 2015. A Closed and Common Orbit is fully as good, if not better. If you liked the previous book, you will definitely want to read this. I pre-ordered it and then read it within months after it was released, something that I almost never do. I can hardly wait to read whatever Chambers writes next.

Rating: 9 out of 10

Hideki Yamane: How to check your package for FTBFS with clang

1 February, 2017 - 10:04
GCC 7 doesn't go into Debian9, but gcc maintainers now file FTBFS bugs for it.

Also you can check packages via building with clang easily. I've already prepared pbuilder (and cowbuilder) build hook script for it. So, if you want to check a package with clang 4.0,

$ mkdir ~/hookdir$ ln -s /usr/share/doc/pbuilder/examples/D65various-compiler-support ~/pbuilder-hookdir(modify your pbuilderrc as adding 1 line like below)
HOOKDIR=/home/henrich/pbuilder-hookdir$ sudo CHOOSE_COMPILER="clang-4.0" cowbuilder --build yourpackage_1.0-1.dsc
That's all - it's handy, isn't it? Please try it to make your package more healthy :)

Antoine Beaupré: Testing new hardware with Stressant

1 February, 2017 - 07:36

I got a new computer and wondered... How can I test it? One of those innocent questions that brings hours and hours of work and questionning...

A new desktop: Intel NUC devices

After reading up on Jeff Atwood's blog and especially his article on the scooter computer, I have discovered a whole range of small computers that could answer my need for a faster machine in my office at a low price tag and without taking up too much of my precious desk space. After what now seems like a too short review I ended up buying a new Intel NUC device from, along with 16GB of RAM and an amazing 500GB M.2 hard drive for around 750$. I am very happy with the machine. It's very quiet and takes up zero space on my desk as I was able to screw it to the back of my screen. You can see my review of the hardware compatibility and installation report in the Debian wiki.

I wish I had taken more time to review the possible alternatives - for example I found out about the amazing Airtop PC recently and, although that specific brand is a bit too expensive, the space of small computers is far and wide and deserves a more thorough review than just finding the NUC by accident while shopping for laptops on

Reviving the Stressant project

But this, and Atwood's Is Your Computer Stable? article, got me thinking about how to test new computers. It's one thing to build a machine and fire it up, but how do you know everything is actually really working? It is common practice to do a basic stress test or burn-in when you get a new machine in the industry - how do you proceed with such tests?

Back in the days when I was working at Koumbit, I wrote a tool exactly for that purpose called Stressant. Since I am the main author of the project and I didn't see much activity on it since I left, I felt it would be a good idea to bring it under my personal wing again, and I have therefore moved it to my Gitlab where I hope to bring it back to life. Parts of the project's rationale are explained in an "Intent To Package" the "breakin" tool (Debian bug #707178), which, after closer examination, ended up turning into a complete rewrite.

The homepage has a bit more information about how the tool works and its objectives, but generally, the idea is to have a live CD or USB stick that you can just plugin into a machine to run a battery of automated tests (memtest86, bonnie++, stress-ng and disk wiping, for example) or allow for interactive rescue missions on broken machines. At Koumbit, we had Debirf-based live images that we could boot off the network fairly easily that we would use for various purposes, although nothing was automated yet. The tool is based on Debian, but since it starts from boot, it should be runnable on any computer.

I was able to bring the project back to life, to a certain extent, by switching to vmdebootstrap instead of debirf for builds, but that removed netboot support. Also, I hope that Gitlab could provide with an autobuilder for the images, but unfortunately there's a bug in Docker that makes it impossible to mount loop images in Docker images (which makes it impossible to build Docker in Docker, apparently).

Should I start yet another project?

So there's still a lot of work to do in this project to get it off the ground. I am still a bit hesitant in getting into this, however, for a few reasons:

  1. It's yet another volunteer job - which I am trying to reduce for health and obvious economic reasons. That's a purely personal reason and there isn't much you can do about it.

  2. I am not sure the project is useful. It's one thing to build a tool that can do basic tests on a machine - I can probably just build an live image for myself that will do everything I need - it's another completely different thing to build something that will scale to multiple machines and be useful for more various use cases and users.

(A variation of #1 is how everything and everyone is moving to the cloud. It's become a common argument that you shouldn't run your own metal these days, and we seem to be fighting an uphill economic battle when we run our own datacenters, rack or even physical servers these days. I still think it's essential to have some connexion to metal to be autonomous in our communications, but I'm worried that focusing on such a project is another of my precious dead entreprises... )

Part #2 is obviously where you people come in. Here's a few questions I'd like to have feedback on:

  1. (How) do you perform stress-testing of your machines before putting them in production (or when you find issues you suspect to be hardware-related)?

  2. Would a tool like breakin or stressant be useful in your environment?

  3. Which tools do you use now for such purposes?

  4. Would you contribute to such a project? How?

  5. Do you think there is room for such a project in the existing ecology of projects) or should I contribute to an existing project?

Any feedback here would be, of course, greatly appreciated.

Antoine Beaupré: My free software activities, January 2017

1 February, 2017 - 07:09 launched

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 in Go. debiman also seems much faster, being written with concurrency in mind from the start. Finally, debiman is 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?

While 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 maintainer) did all the work of putting the site online. I also learned a lot about the CII best practices program, flask, click 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.

The site is now online at I even got credited in the about page which makes up for the disappointment.

Wallabako downloads Wallabag articles on my Kobo e-reader

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.

Other work

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.

Stressant and a new computer

I revived the stressant project and got a new computer. This will be covered in a separate article.

Linkchecker forked

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.

Feed2tweet refresh

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...

Debian uploads Debian Long Term Support (LTS)

This is my 10th month working on Debian LTS, started by Raphael Hertzog at Freexian. I took two months off last summer, which means it's actually been a year of work on the LTS project.

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.

A lot of my time was spent battling the tiff package. The report mentions fixes for 15 CVEs and I uploaded the result in the DLA-795-1 advisory.

I also worked on a small update to graphics magic for CVE-2016-9830 that is still pending because the issue is minor and we're waiting for more to pile up. See the full report for details.

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...

Enrico Zini: Links for February 2017

1 February, 2017 - 06:00
On Progress and Historical Change [archive]
«Is progress inevitable? Is it natural? Is it fragile? Is it possible? Is it a problematic concept in the first place? Many people are reexamining these kinds of questions as 2016 draws to a close, so I thought this would be a good moment to share the sort-of “zoomed out” discussions the subject that historians like myself are always having.»
A projection of the ISS live feed as a night light [archive]
«I always wanted the ISS live feed as a "night light" / ambiance to fall asleep to on my ceiling» how to build a "night light" that is actually a small video projector projecting the ISS live feed
Vatican Climate Forest [archive]
«The Vatican Climate Forest, to be located in the Bükk National Park, Hungary, was donated to the Vatican City by a carbon offsetting company. The forest is to be sized to offset the carbon emissions generated by the Vatican during 2007. The Vatican's acceptance of the offer, at a ceremony on July 5, 2007, was reported as being "purely symbolic", and a way to encourage Catholics to do more to safeguard the planet. No trees have been planted under the project and the carbon offsets have not materialised.» I'm fascinated by how purely symbolic "purely symbolic" can be.

Bdale Garbee: ACLU

1 February, 2017 - 05:42

When I was younger, and worked in an "old HP" test and measurement division, I sometimes sat at lunch in the cafeteria with a group of older co-workers who I grew to have immense respect for. They told great stories. I learned a lot of practical electronics from them... and other things too.

Each carried on their person a copy of the US Constitution and Bill of Rights, and most also had a "concealed carry" permit, which they would refer to as their "redneck license". I quickly learned that they weren't all gun fanatics... at that time, the vetting process for such a permit was a bit daunting, and having one was their way of "proving" that they were honest, law-abiding citizens. Citizens who knew their rights. Who enjoyed debating boundary conditions in those rights inspired by current events at the lunch table. I miss those guys and those conversations.

I mention this because it's one of those things that I realize now had a significant formative impact on my adult values and world view. Freedom matters. That's why, despite my long-standing appreciation for and support of the organization's activities, I'm embarrassed to admit that it wasn't until this week that I personally joined the American Civil Liberties Union and sent them a donation.

Sean Whitton: sorcererscode

31 January, 2017 - 23:37

The Sorcerer’s Code

This is a well-written biographical piece on Stallman.

Michal &#268;iha&#345;: Weblate 2.11

31 January, 2017 - 20:30

Exactly on the schedule, Weblate 2.11 is out today. This release brings extended stats available to users and various other improvements and bug fixes.

Full list of changes:

  • Include language detailed information on language page.
  • Mercurial backend improvements.
  • Added option to specify translation component priority.
  • More consistent usage of Group ACL even with less used permissions.
  • Added WL_BRANCH variable to hook scripts.
  • Improved developer documentation.
  • Better compatibility with various Git versions in Git exporter addon.
  • Included per project and component stats.
  • Added language code mapping for better support of Microsoft Translate API.
  • Moved fulltext cleanup to background job to make translation removal faster.
  • Fixed displaying of plural source for languages with single plural form.
  • Improved error handling in import_project.
  • Various performance improvements.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Weblate is also being used on as official translating service for phpMyAdmin, OsmAnd, Aptoide, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English phpMyAdmin SUSE Weblate | 0 comments

Rapha&#235;l Hertzog: My Free Software Activities in January 2017

31 January, 2017 - 17:33

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (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 was allocated 10 hours to work on security updates for Debian 7 Wheezy. During this time I did the following:

  • I reviewed multiple CVE affecting ntp and opted to mark them no-dsa (just like what has been done for jessie).
  • I pinged upstream authors of jbig2dec (here) and XML::Twig (by private email) where the upstream report had not gotten any upstream reply yet.
  • I asked on oss-security for more details about CVE-2016-9584 because it was not clear whether it had already been reported upstream. Turns out that it was. I then updated the security tracker accordingly.
  • Once I got a reply on jbig2dec, I started to backport the patch pointed out by upstream, it was hard work. When I was done, I had also received by private email the fuzzed file at the origin of the report… unfortunately that file did not trigger the same problem with the old jbig2dec version in wheezy. That said valgrind still identified read outside of allocated memory. At this point I had a closer look at the git history only to discover that the last 3 years of work consisted mainly of security fixes for similar cases that were never reported to CVE. I thus opened a discussion about how to handle this situation.
  • Matthias Geerdsen reported in #852610 a regression in libtiff4. I confirmed the problem and spent multiple hours to come up with a fix. The patch that introduced the regression was Debian-specific as upstream did not fix those issues yet. I released a fixed package in DLA-610-2.
Debian packaging

With the deep freeze approaching, I made some last-minute updates:

  • schroot 1.6.10-3 fixing some long-standing issues with the way bind mounts are shared (#761435) and other important fixes.
  • live-boot 1:20170112 to fix a failure when booting on a FAT filesystem and other small fixes.
  • live-config 5.20170112 merging useful patches from the BTS.
  • I finished the update of hashcat 3.30 with its new private library and fixed RC bug #851497 at the same time. The work was initiated by fellow members of the pkg-security team.
Misc work

Sponsorship. I sponsored a new asciidoc upload demoting a dependency into a recommends (#850301). I sponsored a new upstream version of dolibarr.

Discussions. I seconded quite a few changes prepared by Russ Allbery on debian-policy. I helped Scott Kitterman with #849584 about a misunderstanding of how the postfix service files are supposed to work. I discussed in #849913 about a regression in building of cross-compilers, and made a patch to avoid the problem. In the end, Guillem developed a better fix.

Bugs. I investigated #850236 where a django test failed during the first week after each leap year. I filed #853224 on desktop-base about multiple small problems in the maintainer scripts.


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

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Chris Lamb: Free software activities in January 2017

31 January, 2017 - 15:54

Here is my monthly update covering what I have been doing in the free software world (previous month):

  • Created github-sync, a tool to mirror arbitrary repositories onto GitHub.
  • Submitted two pull requests to the word-wrap Chrome browser extension that adds the ability to wrap text via the right-click context menu:
    • Support dynamically-added <textarea> elements in "rich" Javascript applications such as mail clients, etc. (#2)
    • Avoid an error message if no "editable" has been selected yet. (#1)
  • Submitted a pull request to wordwarvi (a "retro-styled old school side-scrolling shooter") to ensure the build is reproducible. (#5)
  • Filed a pull request with the yard Ruby documentation tool to ensure the generated output is reproducible. (#1048)
  • Made some improvements to, my hosted service for projects that host their Debian packaging on GitHub to use the Travis CI continuous integration platform to test builds on every code change:
    • Merged a pull request from Evgeni Golov to allow for skipped tests. (#39)
    • Add logging when running autopkgtests. (commit)
  • Merged a pull request from jwilk for python-fadvise my Python interface to the posix_fadvise(2) interface to predeclare an pattern for accessing data. (#6)
  • Filed an issue against the redis key-value database regarding build failures on non-x86 architectures. (#3768)
Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users.

The motivation behind the Reproducible Builds effort is to permit verification that no flaws have been introduced — either maliciously or accidentally — during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

(I have previously been awarded a grant from the Core Infrastructure Initiative to fund my work in this area.)

This month I:

I also made the following changes to our tooling:


diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues.

  • Comparators:
    • Display magic file type when we know the file format but can't find file-specific details. (Closes: #850850).
    • Ensure our "APK metadata" file appears first, fixing non-deterministic tests. (998b288)
    • Fix APK extration with absolute filenames. (Closes: #850485).
    • Don't error if directory containing ELF debug symbols already exists. (Closes: #850807).
    • Support comparing .ico files (Closes: #850730).
    • If we don't have a tool (eg. apktool), don't blow up when attempting to unpack it.
  • Output formats:
    • Add Markdown output format. (Closes: #848141).
    • Add RestructuredText output format.
    • Use an optimised indentation routine throughout all presenters.
    • Move text presenter to use the Visitor pattern.
    • Correctly escape value of href="" elements (re. #849411).
  • Tests:
    • Prevent FTBFS by loading fixtures as UTF-8 in case surrounding terminal is not Unicode-aware. (Closes: #852926).
    • Skip tests if binutils can't handle the object file format. (Closes: #851588).
    • Actually compare the output of text/ReST/Markdown formats to fixtures.
    • Add tests for: Comparing two empty directories, HTML output, image.ICOImageFile, --html-dir, --text-color & no arguments (beyond the filenames) emits the text output.
  • Profiling:
    • Count the number of calls, not just the total time.
    • Skip as much profiling overhead when not enabled for a ~2% speedup.
  • Misc:
    • Alias an expensive Config() lookup for a 10% optimisation.
    • Avoid expensive regex creation until we actually need it, speeding up diff parsing by 2X.
    • Use Pythonic logging functions based on __name__, etc.
    • Drop milliseconds from logging output. is my experiment into how to process, store and distribute .buildinfo files after the Debian archive software has processed them.

  • Store files directly onto S3.
  • Drop big unique_together index to save disk space.
  • Show SHA256 checksums where space permits.

Debian LTS

This month I have been paid to work 12.75 hours on Debian Long Term Support (LTS). In that time I did the following:

  • "Frontdesk" duties, triaging CVEs, etc.
  • Issued DLA 773-1 for python-crypto fixing a vulnerability where calling with an invalid parameter could crash the Python interpreter.
  • Issued DLA 777-1 for libvncserver addressing two heap-based buffer overflow attacks based on invalid FramebufferUpdate data.
  • Issued DLA 778-1 for pcsc-lite correcting a use-after-free vulnerability.
  • Issued DLA 795-1 for hesiod which fixed a weak SUID check as well as removed the hard-coding of a fallback domain if the configuration file could not be found.
  • Issued DLA 810-1 for libarchive fixing a heap buffer overflow.
  • python-django:
    • 1:1.10.5-1 — New upstream stable release.
    • 1:1.11~alpha1-1 — New upstream experimental release.
  • gunicorn (19.6.0-10) — Moved debian/README.Debian to debian/NEWS so that the recent important changes will be displayed to users when upgrading to stretch.
  • redis:
    • 3:3.2.6-2 & 4:4.0-rc2-2 — Tidy patches and rename RunTimeDirectory to RuntimeDirectory in .service files. (Closes: #850534)
    • 3:3.2.6-3 — Remove a duplicate redis-server binary by symlinking /usr/bin/redis-check-rdb. This was found by the dedup service.
    • 3:3.2.6-4 — Expand the documentation in redis-server.service and redis-sentinel.service regarding the default hardening options and how, in most installations, they can be increased.
    • 3:3.2.6-5, 3:3.2.6-6, 4:4.0-rc2-3 & 4:4.0-rc2-4 — Add taskset calls to try and avoid build failures due to parallelism in upstream test suite.

I also made the following non-maintainer uploads:

  • cpio:
    • 2.12+dfsg-1 — New upstream release (to experimental), refreshing all patches, etc.
    • 2.12+dfsg-2 — Add missing autoconf to Build-Depends.
  • xjump (2.7.5-6.2) — Make the build reproducible by passing -n to gzip calls in debian/rules. (Closes: #777354)
  • magicfilter (1.2-64.1) — Make the build reproducible by passing -n to gzip calls in debian/rules. (Closes: #777478)
Debian bugs filed RC bugs

I also filed 16 FTBFS bugs against bzr-git, coq-highschoolgeometry, eclipse-anyedit, eclipse-gef, libmojolicious-plugin-assetpack-perl, lua-curl, node-liftoff, node-liftoff, octave-msh, pcb2gcode, qtile, rt-authen-externalauth, ruby-hamster, ruby-sshkit, tika & txfixtures.

FTP Team

As a Debian FTP assistant I ACCEPTed 35 packages: chromium-browser, debichem, flask-limiter, golang-github-golang-leveldb, golang-github-nebulouslabs-demotemutex, golang-github-nwidger-jsoncolor, libatteanx-endpoint-perl, libproc-guard-perl, libsub-quote-perl, libtest-mojibake-perl, libytnef, linux, lua-sql, node-graceful-readlink, node-invariant, node-rollup,, node-timed-out, olefile, packaging-tutorial, pgrouting, pyparallel, python-coards, python-django-tagging, python-graphviz, python-irc, python-mechanicalsoup, python-persistent, python-scandir, python-stopit, r-cran-zelig, ruby-ast, ruby-whitequark-parser, sagetex & u-boot-menu.

Benjamin Mako Hill: Supporting children in doing data science

31 January, 2017 - 11:54

As children use digital media to learn and socialize, others are collecting and analyzing data about these activities. In school and at play, these children find that they are the subjects of data science. As believers in the power of data analysis, we believe that this approach falls short of data science’s potential to promote innovation, learning, and power.

Motivated by this fact, we have been working over the last three years as part of a team at the MIT Media Lab and the University of Washington to design and build a system that attempts to support an alternative vision: children as data scientists. The system we have built is described in a new paper—Scratch Community Blocks: Supporting Children as Data Scientists—that will be published in the proceedings of CHI 2017.

Our system is built on top of Scratch, a visual, block-based programming language designed for children and youth. Scratch is also an online community with over 15 million registered members who share their Scratch projects, remix each others’ work, have conversations, provide feedback, bookmark or “love” projects they like, follow other users, and more. Over the last decade, researchers—including us—have used the Scratch online community’s database to study the youth using Scratch. With Scratch Community Blocks, we attempt to put the power to programmatically analyze these data into the hands of the users themselves.

To do so, our new system adds a set of new programming primitives (blocks) to Scratch so that users can access public data from the Scratch website from inside Scratch. Blocks in the new system gives users access to project and user metadata, information about social interaction, and data about what types of code are used in projects. The full palette of blocks to access different categories of data is shown below.

Project metadata User metadata Site-wide statistics

The new blocks allow users to programmatically access, filter, and analyze data about their own participation in the community. For example, with the simple script below, we can find whether we have followers in Scratch who report themselves to be from Spain, and what their usernames are.

Simple demonstration of Scratch Community Blocks

In designing the system, we had two primary motivations. First, we wanted to support avenues through which children can engage in curiosity-driven, creative explorations of public Scratch data. Second, we wanted to foster self-reflection with data. As children looked back upon their own participation and coding activity in Scratch through the project they and their peers made, we wanted them to reflect on their own behavior and learning in ways that shaped their future behavior and promoted exploration.

After designing and building the system over 2014 and 2015, we invited a group of active Scratch users to beta test the system in early 2016. Over four months, 700 users created more than 1,600 projects. The diversity and depth of users creativity with the new blocks surprised us. Children created projects that gave the viewer of the project a personalized doughnut-chart visualization of their coding vocabulary on Scratch, rendered the viewer’s number of followers as scoops of ice-cream on a cone, attempted to find whether “love-its” for projects are more common on Scratch than “favorites”, and told users how “talkative” they were by counting the cumulative string-length of project titles and descriptions.

We found that children, rather than making canonical visualizations such as pie-charts or bar-graphs, frequently made information representations that spoke to their own identities and aesthetic sensibilities. A 13-year-old girl had made a virtual doll dress-up game where the player’s ability to buy virtual clothes and accessories for the doll was determined by the level of their activity in the Scratch community. When we asked about her motivation for making such a project, she said:

I was trying to think of something that somebody hadn’t done yet, and I didn’t see that. And also I really like to do art on Scratch and that was a good opportunity to use that and mix the two [art and data] together.

We also found at least some evidence that the system supported self-reflection with data. For example, after seeing a project that showed its viewers a visualization of their past coding vocabulary, a 15-year-old realized that he does not do much programming with the pen-related primitives in Scratch, and wrote in a comment, “epic! looks like we need to use more pen blocks. :D.”

Doughnut visualization Ice-cream visualization Data-driven doll dress up

Additionally, we noted that that as children made and interacted with projects made with Scratch Community Blocks, they started to critically think about the implications of data collection and analysis. These conversations are the subject of another paper (also being published in CHI 2017).

In a 1971 article called “Teaching Children to be Mathematicians vs. Teaching About Mathematics”, Seymour Papert argued for the need for children doing mathematics vs. learning about it. He showed how Logo, the programming language he was developing at that time with his colleagues, could offer children a space to use and engage with mathematical ideas in creative and personally motivated ways. This, he argued, enabled children to go beyond knowing about mathematics to “doing” mathematics, as a mathematician would.

Scratch Community Blocks has not yet been launched for all Scratch users and has several important limitations we discuss in the paper. That said, we feel that the projects created by children in our the beta test demonstrate the real potential for children to do data science, and not just know about it, provide data for it, and to have their behavior nudged and shaped by it.

This blog post and the paper it describes are collaborative work with Sayamindu Dasgupta. We have also received support and feedback from members of the Scratch team at MIT (especially Mitch Resnick and Natalie Rusk), as well as from Hal Abelson. Financial support came from the US National Science Foundation. The paper itself is open access so anyone can read the entire paper here. This blog post was also posted on Sayamindu Dasgupta’s blog, on the Community Data Science Collective blog, and in several other places.

Reproducible builds folks: Reproducible Builds: week 92 in Stretch cycle

31 January, 2017 - 09:08

Here's what happened in the Reproducible Builds effort between Sunday January 22 and Saturday January 28 2017:

Media coverage Upcoming Events
  • Introduction to Reproducible Builds will be presented by Vagrant Cascadian at Scale15x in Pasadena, California, March 5th.

  • "Verifying Software Freedom with Reproducible Builds" will be presented by Vagrant Cascadian at Libreplanet2017 in Boston, March 25th-26th.

Reproducible work in other projects

John Gilmore wrote an interesting mail about how worked on reproducible builds in the early 1990s. (It's eye opening to see how the dealt with basically the very same problems we're dealing with today, how they solved them and then to realize that most of this has been forgotten and bit-rotted in the last 20 years. How will we prevent history repeating it)self here?)

Toolchain development and fixes

Christoph Biedl wrote a mail describing an interesting problem in to the way binNMUs are done in Debian.

Guillem Jover made a number of changes to dpkg that affect the Reproducible Builds effort within Debian:

  • Always set SOURCE_DATE_EPOCH in dpkg-buildpackage and dpkg-source. Use the current date if the changelog does not have one. Closes: #849081

  • Add initial support for DEB_BUILD_OPTIONS to dpkg-genbuildinfo. This will make it possible to enable or disable specific features that should be recorded in the .buildinfo file. For now only “all” and “path” are supported. Closes: #848705

  • Include .buildinfo files also for source-only uploads in dpkg-genchanges. Closes: #846164

  • Add support for signed .buildinfo files to dpkg-buildpackage. Add new -ui and --unsigned-buildinfo options. Closes: #843925

  • Make dpkg-buildpackage --unsigned-changes not sign .buildinfo either. This breaks the expectations of users and tools, because there was no way previously to request no signing at all. Closes: #852822

Packages reviewed and fixed, and bugs filed

Chris Lamb:


Reviews of unreproducible packages

17 package reviews have been added, 4 have been updated and 6 have been removed in this week, adding to our knowledge about identified issues.

2 issue types have been added:

1 issue type has been removed:

  • ftbfs_due_to_jenkins_semaphore_setup
Weekly QA work

During our reproducibility testing, the following FTBFS bugs have been detected and reported by:

  • Chris Lamb (6)
  • Holger Levsen (1)
diffoscope development reprotest development development
  • h01ger experimented with reusing SSH control connections but stopped that experiment when we ran into more network issues than before. To be continued, as we'll have 10k SSH connections per day and saving 2 seconds each time would sum up, especially on the Jenkins host itself.
  • h01ger made the scheduler run 3 times a day, 2.5h after dinstall runs, instead of every 3h as before.
  • h01ger restructured the and improved the corresponding Jenins job.
  • h01ger also unblacklisted xmds2, sofia-sip and ck - if you think other packages should be unblacklisted (maybe only on some architectures), please do tell us.

This week's edition was written by Chris Lamb and Holger Levsen & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Dirk Eddelbuettel: gunsales 0.1.2

31 January, 2017 - 08:59

An update to the gunsales package is now on the CRAN network. As in the last update, some changes are mostly internal. We removed the need to import two extra packages with were used in one line each -- easy enough to be replaced with base R. We also update the included data sets, and update a few things for current R packaging standards.

Courtesy of CRANberries, there is also a diffstat report for the most recent release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Keith Packard: FOSDEM-2017

31 January, 2017 - 07:40
FOSDEM 2017 -- The Machine and ChaosKeys

Yay! I get to go to FOSDEM this year. I'll be speaking about Free Software for The Machine on Sunday afternoon at 14:00 in K.1.105 (La Fontaine).

I'll also be bringing along a number of ChaosKeys and will have them available for either $40 US or €40. You can either bring cash or pre-pay at the Altus Metrum shop.

Hope to see you there.


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้