Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 1 hour 26 min ago

Joey Hess: Hacker Holler

3 July, 2016 - 22:50

A quiet place in which to get away and code is all I was looking for when I moved here. I found much more, but that's still the essence of the place.

On returning home from the beach, I've just learned that after several years renting this house, I will soon have to leave, or buy it.

The house is an EarthShip, tucked away in its own private holler (as we say here in the Appalachian Mtns of Tennessee), below a mountain that is National Forest, two miles down back roads from a river.

A wonderful place to relax and code, but developing only free software for twenty years doesn't quite stretch to being able to afford buying this kind of place.

But, I got to thinking of times friends were able to visit me here. Grilling over wood fires with friends from Debian. Steep hikes and river swims. Sharing dialup bandwidth between our Linux laptops. A bunch of us discussing Haskell in the living room at midnight. And too, I've many times talked about the place with someone who got a gleam in their eye, imagining themselves living there.

And then there's my Yurt, my relief valve before I moved here. And a great spot I like to visit on an old logging road above a creek.

Could we put all this together somehow? Might a handful of my friends be able to contribute somewhere in the range of $10 thousand to buy in?

Interested? Want more details? Have ideas?
Visit the Hacker Holler website and get in touch.

(Limited to folks I've met in person or spent a lot of time online with.)

Elena 'valhalla' Grandi: Debconf streaming and kudos to the video team

3 July, 2016 - 20:56
Debconf streaming and kudos to the video team

With being in South Africa, a lot of people (like me) probably weren't able to attend and are missing the cheese and wine party, mao games and general socialization that is happening there.

One thing we don't have to miss, however, are the talks: as usual the video team is doing a great job recording and all talks so that people can still participate a bit from their home.

What they do, however, requires a lot of manpower, so if you are attending Debconf please consider volunteering to help: from my experience last year they are very nice people who are welcoming towards new contributors and they have periodical training sessions to help people getting started with the various tasks. More informations about video team meetings and training session are in the topic of the IRC channel, #debconf-video@OFTC.

I don't think there are cookies involved (which just proves that the video team isn't evil), but you may get a t-shirt and you will get a warm fuzzy feeling of having helped people around the world.

@Debian #debconf

Petter Reinholdtsen: How to use the Signal app if you only have a land line (ie no mobile phone)

3 July, 2016 - 19:20

For a while now, I have wanted to test the Signal app, as it is said to provide end to end encrypted communication and several of my friends and family are already using it. As I by choice do not own a mobile phone, this proved to be harder than expected. And I wanted to have the source of the client and know that it was the code used on my machine. But yesterday I managed to get it working. I used the Github source, compared it to the source in the Signal Chrome app available from the Chrome web store, applied patches to use the production Signal servers, started the app and asked for the hidden "register without a smart phone" form. Here is the recipe how I did it.

First, I fetched the Signal desktop source from Github, using

git clone

Next, I patched the source to use be able to talk to other Signal users using

cat <<EOF | patch -p0
diff -ur ./js/background.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js
--- ./js/background.js  2016-06-29 13:43:15.630344628 +0200
+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js    2016-06-29 14:06:29.530300934 +0200
@@ -47,8 +47,8 @@
-    var SERVER_URL = '';
+    var SERVER_URL = '';
     var messageReceiver;
     window.getSocketStatus = function() {
         if (messageReceiver) {
diff -ur ./js/expire.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js
--- ./js/expire.js      2016-06-29 13:43:15.630344628 +0200
+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js2016-06-29 14:06:29.530300934 +0200
@@ -1,6 +1,6 @@
 ;(function() {
     'use strict';
-    var BUILD_EXPIRATION = 0;
+    var BUILD_EXPIRATION = 1474492690000;
     window.extension = window.extension || {};

The first part is changing the servers, and the second is updating an expiration timestamp. This timestamp need to be updated regularly. It is set 90 days in the future by the build process (Gruntfile.js). The value is seconds since 1970 times 1000, as far as I can tell.

Based on a tip and good help from the #nuug IRC channel, I wrote a script to launch Signal in Chromium.

cd $(dirname $0)
mkdir -p userdata
exec chromium \
  --proxy-server="socks://localhost:9050" \
  --user-data-dir=`pwd`/userdata --load-and-launch-app=`pwd`

The script set start the app and configure Chromium to use the Tor SOCKS5 proxy to make sure those controlling the Signal servers (today Amazon and Whisper Systems) as well as those listening on the lines will have a harder time location my laptop based on the Signal connections if they use source IP address.

When the script starts, one need to follow the instructions under "Standalone Registration" in the file in the git repository. I right clicked on the Signal window to get up the Chromium debugging tool, visited the 'Console' tab and wrote 'extension.install("standalone")' on the console prompt to get the registration form. Then I entered by land line phone number and pressed 'Call'. 5 seconds later the phone rang and a robot voice repeated the verification code three times. After entering the number into the verification code field in the form, I could start using Signal from my laptop.

As far as I can tell, The Signal app will leak who is talking to whom and thus who know who to those controlling the central server, but such leakage is hard to avoid with a centrally controlled server setup. It is something to keep in mind when using Signal - the content of your chats are harder to intercept, but the meta data exposing your contact network is available to people you do not know. So better than many options, but not great. And sadly the usage is connected to my land line, thus allowing those controlling the server to associate it to my home and person. I would prefer it if only those I knew could tell who I was on Signal. There are options avoiding such information leakage, but most of my friends are not using them, so I am stuck with Signal for now.

Holger Levsen: I won't be going to DebConf16

3 July, 2016 - 16:49

With great sadness I'm acknowledging and announcing that I won't be going to DebConf16 today, due to sudden health issues (which should be ok soon). Seeing the first pictures on planet Debian a few minutes ago made me very very sad, but still didn't change my mind.

Have a whole lot of fun in Cape Town, have great discussions in corridors and while hiking, enjoy the talks and the workshops and hugs to everyone who wants to be hugged. I'll follow online from the distance…

I('ll) miss you.

Paul Wise: DebConf16 Open Festival day 1

3 July, 2016 - 12:17

Today was day one of the DebConf16 Open Festival and I attended the open hardware panel, part of the talk about Code For South Africa, shirish's experiences and the DebConf new folks session.

The open hardware panel was a wide ranging discussion between bdale, Andy and indiebio. bdate talked about the experiences he has had with his rocketry hardware. bdale said "Make concious decisions about what you are buying", referencing a case where he investigated, found a GPL violation and didn't buy. Various people care about openness of different layers of the hardware. Off-the-shelf products are very strongly integrated, which is great for makers but means that people who care about lower layers like CPU micro-architecture aren't able to participate. Andy said "We are just beginning to come out of the shareware stage [of open hardware]". bdale mentioned the companies who do hardware production as a service from design files. Later in the pub some folks mentioned j-core, an open re-implementation of SuperH processors.

I missed most of the code4sa talk unfortunately, but it was about government services and open data.

shirish covered his journey through life to Debian. His youth, how satellite TV and knowledge of the outside world came to India around the time of the Iraq war. His experience accessing the Internet for the first time, uncensored vs the usual censorship in India's media. His experiences of Windows 95 viruses and crashes. He learned of PCTwist Linux through a magazine cover. His initial install was not a success but eventually managed to break through and install a desktop, but experienced network and other issues. Eventually he encountered Ubuntu and began contributing bug reports. His experiences there led him to Debian. He began blogging about Debian. In the last few years he and others have been going around the country doing mini-DebConfs at institutes around India. The first question was predictably about having a DebConf in India and how shirish might like to get more involved. DebConf in India sounds like a possibility some day and shirish was thinking about getting involved in publicity, marketting and the Debian installer.

The DebConf new folks session was a great intro to DebConf for folks new to the community. There were some quite excellent touches added to this year's version of the event by indiebio and Rhonda.

I also got some things done. Usual spam reporting. Reviewed wiki RecentChanges. Talked to the chromium-bsu/MacPorts maintainer about AX_CHECK_GL brokenness. Filed Debian wishlist bug #829292 asking to update autoconf-archive. Redirected a Hurd porterbox request to the exodar admin and quickly found out I was wrong to do that, rectified. Then we found out the LDAP sync to exodar was broken. Replied to someone who intends to sell Debian pre-installs. Thanked BunsenLabs folks for joining the derivatives list. Applied reproducible builds patch for cats from Chris Lamb. Heard about awesome new terminal-mode screensaver. Moo! Prepared a blog post about check-all-the-things.

Russ Allbery: Review: Coming Home

3 July, 2016 - 11:55

Review: Coming Home, by Jack McDevitt

Series: Alex Benedict #7 Publisher: Ace Copyright: November 2014 Printing: November 2015 ISBN: 0-425-26088-7 Format: Mass market Pages: 356

Coming Home is a direct sequel to Firebird, the first time McDevitt has done that in this series. You therefore don't want to start here, although the nature of the sequel doesn't require that you remember Firebird in that much detail.

The mystery of the disappearing starships was understood in Firebird but not resolved. The title advertises that as a major theme in this book, but it progresses very slowly. There's more media bickering and various factional attempts to draw Alex (and, to a lesser extent, Chase) into the controversies. McDevitt does a good job writing popular media, the strange position of public intellectual and talk-show favorite, and the way this filters into popular arguments. But with Alex trying to take a nuanced and unsure position and with a lot of talk but little action, it's not the most compelling reading.

Coming Home holds to form in balancing a mystery and a second plot. Since the starship problem is understood, it can't be the central mystery of the book. That role is taken by the discovery of communication device from the very early days of space flight, which takes Alex and Chase to Earth for the first time in this series (at least that I can recall). This time, the search is for a legendary trove of historical artifacts that was moved from a space flight museum in Florida when the ocean rose to cover the state. From there, its location was lost in the middle of a general economic collapse called the Time of Troubles that destroyed most of Earth's governmental systems (and, apparently rather more importantly to McDevitt, the space program).

Anyone who has gotten this far in the series will know the standard problem with McDevitt's futures: they're indistinguishable from the 1960s except that they have flying cars. There is a tiny break from that tradition here, since climate change has clearly happened to Earth, covering Florida with the ocean and shifting the major cities north. But the sense of deep history that McDevitt is trying for in this series doesn't work: I just don't believe as much time has gone by as the story claims. He does offer an explanation for why technology has been stagnant for apparently millennia, but it's just a contention that science ran out of more things to discover due to authorial fiat and is now just a matter of engineering and step-wise refinement. (I think the science behind the disappearing starships happening in this very same book undermines that contention considerably.)

Even if one can put that aside, Earth is, well, boring. This is partly an intriguing stylistic choice by McDevitt: Earth is intended to be just one more world. It might have a longer history than many other human-occupied worlds, but history is so long everywhere that this only matters to a few people like Alex and Chase. The choice makes sense, but it doesn't make a good story. And there are other things that I flatly didn't believe, such as the supposed isolation of Earth from the communication network of Alex's home world of Rimway for... no apparent reason other than that different communication networks don't talk to each other except via, essentially, letters. Even if one is willing to ignore the mysterious failure of forward progress in technology, this makes no social or engineering sense given the capabilities already shown in the series.

I found the main mystery at best mildly interesting. McDevitt does a good job showing the research and investigation process, with all its tedium and dead ends, but I wasn't as invested in the search as he wanted me to be. The endless space boosterism started getting on my nerves, as it so often does in science fiction of a certain type, and I had a much harder time swallowing McDevitt's Earth than his fictional Rimway. I will give him credit for a surprisingly affecting conclusion of the main mystery, but the missing starship subplot putters to an undistinguished end.

I think this series is running out of steam. It's become increasingly formulaic, and the characters, like McDevitt's future technology, have stopped developing. I was hoping the reunion foreshadowed since Firebird would shake things up, but at least in this book it doesn't. Maybe it will in subsequent books, but I'm starting to question whether I really want to keep reading.

Rating: 5 out of 10

Kevin Avignon: Tech questions 11-16: Artificial intelligence

3 July, 2016 - 10:31
11. Why use a genetic algorithm instead of a backpropagation algorithm to train a neural net ? 12. What is the difference between a support vector machine (SVM) and an artificial neural network (ANN) ? 13. What’s a Naives Bayes classifier ? 14. What is the difference between supervised and unsurpervised learning 15. What is … Continue reading Tech questions 11-16: Artificial intelligence →

Junichi Uekawa: Looking at old code I wrote I am grumpy I used automake.

3 July, 2016 - 09:18
Looking at old code I wrote I am grumpy I used automake. automake / autoconf / make are three layers of historical cruft that was only necessary when commercial unices were around. When I have code that only really runs on Linux that's so redundant.

Thadeu Lima de Souza Cascardo: Debian on old Linux versions

3 July, 2016 - 09:18

On recent posts, I mentioned that I have a Chromebook, and that I would like to run Debian on devices that ship with old Linux versions. The Samsung ARM Chromebook is such a device, it has Linux 3.4, and that's still what I am running on it most of the time.

After an upgrade of Debian, systemd stopped working, and it took me some time before I could look into it. In order to boot, I had to temporarily use System V init. The bug involves the use of new interfaces, bugs in such interfaces, and how versioning would not be a solution to such cases. Cases like this are not common, so it's no excuse to doing the right thing when developing software, like considering portability, API and ABI maintenance and not bundle. But they expose some of the challenges when trying to support different OSes on top of old versions of Linux, or maybe even new versions.

The new version of systemd included in Debian Jessie uses a feature of Linux of checking the mount ID of a file by inspecting the mnt_id line in the fdinfo files. fdinfo files are not that new, they have been present since 2007, Linux 2.6.22. The mnt_id line, however, is from Linux 3.15, from 2014. So, a fairly new feature. But systemd falls back to other methods if the feature is not present.

However, during the last few weeks of development of Linux 3.4, a bug was introduced to fdinfo handling, which will cause its access to fail in a way that will cause systemd to halt. It simply will refuse to mount the most basic filesystems and not proceed. The bug was fixed not much longer than two weeks after that, but that window of time was enough to have it on a shipped product, one that was not using systemd, let alone one that required a feature not yet present on Linux.

But now I wanted to run this new systemd on this old Linux version. Being too early in the boot process, systemd even ignored some of the debug options and I had to resort to other methods of debugging. As I am running a kernel I built by myself, it wasn't hard for me to have a fixed kernel up and running after I found out the problem. Unfortunately, not everyone will be able to do it by themselves. And the point of getting different OSes working on these many varied devices is scaling. If every device needs to be tested, we lose this scalability.

The other problem I found was that this old Linux version didn't load firmware files by itself, and requested help from userspace, which used to be the job of udev. Well, udev now does not support loading firmware, and the kernel must do it by itself. I managed to backport that feature too. But now, it sounds like I should get upstream support for this device.

Unfortunately, this means not working on the scalability problem, but going back to get upstream support for a lot of devices out there, which is very hard to scale without the necessary people to do the work. I am certainly going to do that, because it's the right thing to do. But not as many people will benefit from that.

But I think it has been interesting to look into the possible problems we might find when trying to make Debian and other OSes working on old Linux versions. I know even older Debian versions won't boot fine on Linux 2.6.32, one of the LTS versions of Linux. I have one other device which runs on it, and I am also working on getting better upstream support for it. Let's see if I can get some news on that soon.

Lisandro Damián Nicanor Pérez Meyer: Upcoming KDEPIM changes in unstable (KMail, Kontact, KOrganizer, etc)

3 July, 2016 - 07:38
For those who care about kdepim (kmail, kontact, korganizer, etc)

Currently the latest version of kdepim is available in experimental. According to our limited tests it's working way better than kdepim 4.14 (more stable, more performant, less bugs). However migrating from one to the other is not a trivial process (distribution wise, hopefully not for our users).

Among the drawbacks in the new kdepim: knode, ktimetracker and kjots were dropped from the official kdepim components. kjots is now an independent project, not tied to the kdepim release cycle. But more importantly, knode and ktimetracker are not maintained upstream any more, we are temporarily still shipping the old KDE 4 versions, but we will drop them after stretch unless they get new upstream maintainers.

To iron out the wrinkles that are surely still there, we are now planning to start a transition for kdepim, effectively blocking all kdepim related packages in unstable until the transition is complete. This will allow us to keep the current kdepim in testing unchanged until kdepim 16.04 is ready to migrate fully to testing.

If you want to test the new kdepim versions right now, please use the version in experimental, as uploading all the packages to unstable will take some time until there is a working kdepim in unstable (mixing experimental and the unstable uploads should be fine).

If you depend on having a working kdepim, please avoid installing the new kdepim packages that will be landing in unstable in the following days, until all the components are available. We expect this will take a couple of weeks, we will post another entry when the packages are ready in unstable.

A list of the binary packages involved in the transition can be found [here].

If you find issues in the new packages, please let us know either via irc in #debian-kde, the kde mailing list, or send us a bug report (please make sure that it wasn't reported before).

We'll send an updated note when kdepim is fully uploaded to unstable.

Happy hacking,

The Debian Qt/KDE Team.

Thorsten Alteholz: APU and Debian

3 July, 2016 - 04:13

I just got an APU1D4 made by PC Engines. I bought it from a German retailer called VARIA System GmbH. They are also located in Chemnitz, so at least I could support the local economy. I purchased a bundle consisting of mainboard, case, power supply and 16GB SSD. The board has 4GB RAM and three network adapters and shall replace my old PC that I use as router to the internet.

As there is no VGA/HDMI output, the first hurdle was organizing a null-modem cable. Of course I could have prepared the SSD on another PC, but I wanted to try PXE. After finding the cable on the ground of a box, deeply buried under other boxes, I could start.

The DHCP server got an entry

host apu1d4 {
  hardware ethernet 00:0d:b9:42:a0:e8;
  fixed-address apu1d4;
  option broadcast-address;
  option routers;
  filename "pxelinux.0";

and the TFTP server got a file …/tftp/pxelinux.cfg/01-00-0d-b9-42-a0-e8

default install
label install
        menu label ^Install
        menu default
        kernel debian-installer/amd64/linux
        append initrd=debian-installer/amd64/initrd.gz --- vga=off console=ttyS0,115200n8

The files debian-installer/amd64/linux and debian-installer/amd64/initrd.gz are the normal debian installer files obtained from the official Debian servers.

That’s it, the installer starts, spits its output over the serial line and I can install the system. Great! Thanks DebianInstaller team. Why couldn’t everything be always so easy?

Jonathan Carter: So, that was DebCamp16!

3 July, 2016 - 03:57

University of Cape Town, host location to DebConf 16. Picture: Adrian Frith

What an amazingly quick week that was

Our bid to host DebConf in Cape Town was accepted nearly 15 months ago. And before that, the bid itself was a big collective effort from our team. So it’s almost surreal that the first half of the two weeks of DebCamp/DebConf is now over.

Things have been going really well. The few problems we’ve had so far were too small to even mention. It’s a few degrees colder than it usually is this time of the year and there’s already snow on the mountains, so Cape Town is currently quite chilly.

Gathering some heat by the fire at the sports club while catching up to the world the day before it all started.

All Kinds of Quality Time

I really enjoyed working with the video team last year, but this year there was just 0 time for that. Working on the orga team means dealing with a constant torrent of small tasks, which is good in its own way because you get to deal with a wide variety of Debian people you might not usually get to interact with, but video team problems are more fun and interesting. Next year I hope to do a lot more video work again. If you’re at DebConf over the next week, I can highly recommend that you get involved!

Video team members hacking away at problems late at night during DebCamp

The first time I met Debian folk was early in 2004. I worked at the Shuttleworth Foundation as “Open Source Technical Co-ordinator” at the time, and Mark Shuttleworth had them over for one of the early Ubuntu sprints in Canonical’s early days. I was so intimidated by them back then that I could hardly even manage to speak to them. I was already a big free software fan before working there, but little did I even dream to think that I would one day be involved in a project like Ubuntu or Debian. My manager back then encouraged me to go talk to them and get involved and become a Debian Developer and joked that I should become I guess that was when the initial seeds got planted and since then I’ve met many great people all over the world who have even became friends during UDS, DebConf, BTS and other hackfests where Debianites hang out. It gave me a really nice warm feeling to have all these amazing, talented and really friendly people from all over coming together in this little corner of the world to work together on projects that I think are really important.

Finding a warm space to work in the Happy Feet hack lab

Oh the Chicken

Back at DebConf12, someone (I don’t remember the exact history) brought a rubber chicken to DebConf who was simply called “Pollito” (“chicken” in Spanish). Since then the chicken has grown into somewhat of a mascot for DebConf. Back in 2012 I already imagined that if we would ever host a DebConf, I’d make a little of picture book story about Pollito. Last year after DC15, when bringing Pollito over, I created a little story called “Pollito’s first trip to Africa“. I was recovering from flu while putting that together and didn’t spend much time on it, but it turned out to be somewhat of a hit. I was surprised to see it in the #debconf topic ever since I posted it :)

We gave a tour of the campus on the first and second days and it was quite time consuming and there was no way we could do it every day for the rest of DebCamp, so on the 2nd day I smacked together a new rush job called “Pollito’s Guide to DC16“. The idea was that newcommers could use it as a visual guide and rely on others who have been there for a while if they get stuck. I wish I had the time to make it a lot nicer, but I think the general idea is good and next year we can have a much nicer one that might not be quite as Pollito focused.

Pollito’s Guide to DC16

Debian Maintainer

After all these years, I finally sat down and applied to become a Debian Maintainer, and the application was successful (approved yesterday \o/). Now just for the wait until my key is uploaded to the keyring. I haven’t yet had time to properly process this but I think once the DebConf dust settles and I had some time to recover, I will be ecstatic.

Some actual DebCampy work

Everywhere I go, I see people installing a bunch of GNOME extensions on their Debian GNOME desktops shortly after installation using (I noticed this even at DebCamp!). A few months ago I thought that it’s really about time someone package up some of the really popular ones. So I started to put together some basic packaging for AIMS Desktop around a month ago. During the last few days of DebCamp, things were going well enough with the organisational tasks that I had some time to do some actual packaging work and improve these so that they’re ready for upload to the Debian archives. The little DebCamp time I had ended up being my very own little extension fest :)

I worked on the following packages which are ready for upload:

  • gnome-shell-extension-pixelsaver
  • gnome-shell-extension-move-clock
  • gnome-shell-extension-dashtodock
  • gnome-shell-extension-remove-dropdown-arrows

I worked on the following packages which still need minor work, might be able to get them in uploadable state by the end of DebConf:

  • gnome-shell-extension-trash-applet
  • gnome-shell-extension-topicons
  • gnome-shell-extension-taskbar
  • gnome-shell-extension-refresh-wifi
  • gnome-shell-extension-disconnect-wifi
  • gnome-shell-extension-hide-activities
  • gnome-shell-extension-impatience

The actual packaging of GNOME extensions is actually pretty trivial. It’s mostly source-only JavaScript with some CSS and translations and maybe some gsettings schemas and dialogs. Or at least, it would be pretty trivial, but many extensions are without licenses, contain embedded code (often JavaScript) from other projects, or have no usable form of upstream tarball, to name a few of the problems. So I’ve been contacting the upstream authors of these packages where there have been problems, and for the most part they’ve been friendly and pretty quick to address the problems.

So that’s it, for now.

I couldn’t possibly sum up the last week and everything that lead up to it in a single blog post. All I can really say is thank you for letting me be a part of this very special project!

Guido Günther: Debian Fun in June 2016

3 July, 2016 - 02:23
Debian LTS

June marked the fourteenth month I contributed to Debian LTS under the Freexian umbrella. I spent the 8 hours working on these LTS things:

  • Reviewed and tested libxml2 2.8.0+dfsg1-7+wheezy6

  • Fixed #825508 in mozilla-devscripts to prepare for the Icedove update resulting in DLA-518-1.

  • Rebased the proposed Wheezy Icedove update against the Jessie version and uploaded resulting in DLA-519-1.

  • Sent out the DLA-521-1 for Iceweasel, the upload was all done by Mike Hommey.

  • Rebuilt enigmail with the fixed mozilla-devscripts so it can still be used in Wheezy, resulting in DLA-523-1.

  • continue to work on updates for CVE-2016-0753 for ruby-active{record,support}-3.2 - not yet finished.

  • Looked into open qemu-kvm and qemu CVEs marking CVE-2015-8666 as no-dsa and fixing CVE-2016-3710 and CVE-2016-3712 via DLA-540-1 and DLA-539-1.

Other Debian stuff

Besides the usual bunch of libvirt* uploads I addressed several bugs in git-buildpackage, upload pending.

Lior Kaplan: Implementing NATO’s standards (STANAG)

3 July, 2016 - 01:04

I recently joined Linnovate, and while working on one of the open source projects the company produces, we needed to process video content according to NATO’s standard agreement (STANAG) 4609: NATO Digital Motion Imagery Standard.

Obviously we started with trying to find code already done, but we only found some implementation in Java, while our project is written in JavaScript. We decided to just implement the standard in the way most convenient to us, and later refactoring the project when more standards (STANAGs) will get implemented.

So I’m happy to introduce our new project: STANAG at , also available with NPM (see

Filed under: Linnovate

Joey Hess: twenty years of free software -- part 6 moreutils

3 July, 2016 - 00:27

moreutils is a little love letter to the Unix Tools philosophy. It was interesting to try to find new tools as basic as cat and ls. With sponge and vidir and ifne and chronic and others, we managed to find several such tools.

So, it was fun to work on moreutils, but it also ran into inherent problems with the Unix Tools philosophy. One is namespacing; there are only so many good short names for commands, and a command like parallel can easily collide with something else. And since Unix Tools have a bigger surface area than a pure function, my parallel is not going to be quite compatible with your parallel, even if they were developed with (erm) parallel intentions.

Partly due to that problem, I have gotten pickier about adding new tools to moreutils as it's gotten older, and so there's a lot of suggested additions that I will probably never get to.

And as my mention of pure functions suggests, I have kind of moved on from being a big fan of the Unix Tools philosophy. Unix tools are a decent approximation of pure functions for their time, but they are not really pure, and not typed at all, and not usefully namespaced, and this limits them.

Next: ?twenty years of free software -- part 7 git-annex

Paul Tagliamonte: Hello, InfluxDB

3 July, 2016 - 00:13

Last week, I posted about python-sense, and API wrapper for the internal Sense API. I wrote this so that I could pull data about myself into my own databases, allowing me to use that information for myself.

One way I'm doing this is by pulling my room data into an InfluxDB database, letting me run time series queries against my environmental data.

#!/usr/bin/env python

from influxdb import InfluxDBClient

import json
import datetime as dt
from sense.service import Sense

api = Sense()

data = api.room_sensors(quantity=20)

def items(data):
    for flavor, series in data.items():
        for datum in reversed(series):
            value = datum['value']
            if value == -1:

            timezone = dt.timezone(dt.timedelta(
                seconds=datum['offset_millis'] / 1000,

            when = dt.datetime.fromtimestamp(
                datum['datetime'] / 1000,

            yield flavor, when, value

client = InfluxDBClient(

def series(data):
    for flavor, when, value in items(data):
        yield {
            "measurement": "{}".format(flavor),
            "tags": {
                "user": "paultag"
            "time": when.isoformat(),
            "fields": {
                "value": value,


I'm able to run this on a cron, automatically loading data from the Sense API into my Influx database. I can then use that with something like Grafana, to check out what my room looks like over time.

Paul Wise: DebCamp16 day 8

2 July, 2016 - 12:21

Apply wget security update to Poke the DebConf video team about archiving the one Debian & stuff podcast episode. Discuss exclusion, privilege & DebConf. Usual spam reporting. Review wiki RecentChanges. Fix some typos from RecentChanges. File Debian wishlist bug #829177 against Mention the recent post about breaking Android full-disk encryption on the exploits Debian wiki page. Answer questions about recommended build configuration for chromium-bsu from the maintainer of it in FreeBSD. Mention that HTML SRI could help secure initial Debian downloads. File Debian bug #829199 against file and add workaround in derivatives census. Report broken boss-gnome source package to BOSSLinux folks on IRC. Delete and re-download Parsix apt folder to stop hash sum mismatches. File Debian minor/wishlist bugs #829209/#829211/#829212 against cypher-lint. Add a porterbox guest account for one of the RTC GSoC students. Extend the expiry of another guest account. Direct query about the excuses HTML to the release team. File Debian bug #829241 against fonts-play. Discuss accessibility, life, the universe and rakia.

Russ Allbery: Review: Ashes of Honor

2 July, 2016 - 11:05

Review: Ashes of Honor, by Seanan McGuire

Series: October Daye #6 Publisher: DAW Copyright: September 2012 ISBN: 1-101-59480-2 Format: Kindle Pages: 368

This is the sixth book in the October Daye series, contains payoffs for some relationships that have been building over the whole series, and involves entangled politics set up by previous books. It's not the place to start with the series.

Ashes of Honor starts, as so many of Toby's books do, with a friend asking her for help. But this request is entirely unexpected, and the help needed comes as a complete surprise: a previously unknown changeling, who has disappeared. A changeling whose powers are completely out of control, and who poses a threat to reality itself.

As Toby's cases go, this involves a lot fewer horrible things happening to her and a lot more faerie politics and maneuvering than usual. I appreciated that; I'm not as fond of the books that go deep into despair or desperation. It does involve Toby getting almost killed multiple times, but, due to earlier events of the series, that isn't quite as bad as it used to be. More focus on investigation and political maneuvering and less Toby braving her way through horrors works for me.

Even more notably, this book marks Toby finally figuring out that she has friends and allies who are there to help, not just be obligations she feels overwhelmed by or aid that she's not allowed to accept. This was one of her most frustrating characteristics; it's a relief to see her finally relax. This opens the way not only for deeper friendships and more complex plots but also a relationship that I've been awaiting for the entire series, and it's as much fun as I was hoping it would be. Toby started the series rather messed up and unwilling to let anyone close. It was for understandable reasons, but I like her better when she realizes why people respect her.

Toby's connections with the royalty of the Bay Area also allow McGuire to tell a political story that moves farther afield from the Shadowed Hills. First in One Salt Sea and now in Ashes of Honor we see more of local politics, more of the lore of McGuire's universe, and another dangerous queen. Toby is particularly fun when she's dangerously outflanking people with considerably more power than she has. At this point, you could call it a specialty. I thought McGuire's take on San Jose and the sort of person who would be in charge of its fae was on point.

We also get more of the Luidaeg, which is always a good sign for a Toby novel, and more of Tybalt, who is entangled in a major subplot of the story. Next to Luidaeg, Tybalt is my favorite of Toby's friends, so this book is full of the things that make me happy. McGuire adds some more pieces to her transplanted Celtic mythology and some tantalizing hints of what the fae have left behind. I'm hoping we see more of that in future books. (I suspect that may be what this whole series is building up to.)

The story doesn't have quite as much oomph as One Salt Sea, but it's still one of the best books in the series so far. If you've enjoyed the series up to this point, keep reading.

Followed by Chimes at Midnight.

Rating: 8 out of 10

Thorsten Alteholz: My Debian Activities in June 2016

2 July, 2016 - 03:45

FTP assistant

This month I marked 233 packages for accept and rejected 29. I also sent 11 emails to maintainers asking questions. Currently there are 33 packages in NEW and the minimum this week has been as low as 24 packages. Come on you fellow developers, where are your packages? I am sure you can do better .

Debian LTS

This was my twenty-fourth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

This month my all in all workload has been 18.75h. This resulted in patches for 13 CVEs and the following uploads:

  • [DLA 522-1] python2.7 security update
  • [DLA 533-1] php5 security update
  • [DLA 534-1] libgd2 security update
  • [DLA 536-1] wget security update

I also looked at mxml and libstruts1.2-java and marked CVEs for these packages as “no-dsa”. I also reviewed a patch of Salvatore for an embargoed CVE of xerces-c. Last but not least I looked at the remaining two CVEs for asterisk, but was not really able to create working patches …

This month I called again for testing php5. Thanks a lot to Stefan and anybody else who sent in their reports! As there are already new CVEs for php5 available, I am afraid I need your support again in July …

This month I also had another term of frontdesk work and answered questions or looked for CVEs that are important for Wheezy LTS or could be ignored.

Other stuff

I made some progress with the Alljoyn framework. Up to now the following packages are available:

  • alljoyn-core-1504
  • alljoyn-core-1509
  • alljoyn-core-1604
  • alljoyn-gateway-1504
  • alljoyn-services-1504
  • alljoyn-services-1509
  • alljoyn-thin-client-1504
  • alljoyn-thin-client-1509
  • alljoyn-thin-client-1604
  • duktape

Unfortunately as some of those modules still need to be released in current versions, there are some gaps.

Anyway, the next uploads will include an XMPP connector, to basically bridge a local AllJoyn bus to a remote AllJoyn bus over XMPP. Further, with the lighting module, real lamps can be switched on and off and much more. Also the Home Appliances and Entertainment Service Framework seems to be interesting as well.

In the Javascript world I uploaded some new packages …

  • node-strip-ansi
  • node-lodash-compat
  • node-has-flag
  • node-errs
  • node-ejs
  • node-absolute-path

… and uploaded new versions for the following packages:

  • node-base62
  • node-array-flatten
  • node-eventsource
  • node-xmlhttprequest-ssl
  • node-wrappy

Joachim Breitner: When to reroll a six

2 July, 2016 - 02:47

This is a story about counterintuitive probabilities and how a small bit of doubt turned out to be very justified.

It begins with the game “To Court the King” (German: „Um Krone und Kragen“). It is a nice game with dice and cards, where you start with a few dice, and use your dice rolls to buy additional cards, which give you extra dice or special powers to modify the dice that you rolled. You can actually roll your dice many times, but every time, you have to set aside at least one die, which you can no longer change or reroll, until eventually all dice have been set aside.

A few years ago, I have played this game a lot, both online (on as well as in real life. It soon became apparent that it is almost always better to go for the cards that give you an extra die, instead of those that let you modify the dice. Intuitively, this is because every additional die allows you to re-roll your dice once more.

I concluded that if I have a certain number of dice (say, n), and I want to have a sum as high as possible at the end, then it may make sense to reroll as many dice as possible, setting aside only those showing a 6 (because that is the best you can get) or, if there is no dice showing a 6, then a single die with the best score. Besides for small number of dice (2 or 3), where even a 4 or 5 is worth keeping, this seemed to be a simple, obvious and correct stategy to maximize the expected outcome of this simplified game.

It is definitely simple and obvious. But some doubt that it was correct remained. Having one more die still in the game (i.e. not set aside) definitely improves your expected score, because you can reroll the dice more often. How large is this advantage? What if it ever execeeds 6 – then it would make sense to reroll a 6. The thought was strange, but I could not dismiss it.

So I did what one does these days if one has a question: I posed it on the mathematics site of StackExchange. That was January 2015, and nothing happened.

I tried to answer it myself a month later, or at least work towards at an answer, and did that by brute force. Using a library for probabilitstic calculations for Haskell I could write some code that simply calculated the various expected values of n dice for up to n = 9 (beyond that, my unoptimized code would take too long):

1:  3.50000 (+3.50000)
2:  8.23611 (+4.73611)
3: 13.42490 (+5.18879)
4: 18.84364 (+5.41874)
5: 24.43605 (+5.59241)
6: 30.15198 (+5.71592)
7: 35.95216 (+5.80018)
8: 41.80969 (+5.85753)
9: 47.70676 (+5.89707)

The result supported the hypothesis that there is no point in rolling a 6 again: The value of an additional die grows and approaches 6 from beyond, but – judging from these number – is never going to reach it.

Then again nothing happend. Until 14 month later, when some Byron Schmuland came along, found this an interesting puzzle, and set out a 500 point bounty to whoever solved this problem. This attracted a bit attention, and a few not very succesful attempts at solving this. Eventually it reached twitter, where Roman Cheplyaka linked to it.

I do not know if the tweet made a difference, but a day later some joriki came along, and he had a very good idea: Why not make our life easier and think about dice with less sides, and look at 3 instead of 6. This way, and using a more efficient implementation, he could do a similar calculation for up to 50 dice. And it was very lucky that he went to 50, and not just 25, because up to 27, the results were very much as expected, approaching value of +3 from below. But then it surpassed +3 and became +3.000000008463403.

In other words: If you have roll 28 dice, and you have exactly two dice showing a 3, then it gives you better expected score if you set aside only one 3, and not both of them. The advantage is miniscule, but that does not matter – it is there.

From then on, the results behaved strangely. Between 28 and 34, the additional value was larger than 3. Then, from 35 on again lower than 2. It oscillated. Something similar could be observed when the game is played with coins.

Eventually, joriki improved his code and applied enough tricks so that he could solve it also for the 6-sided die: The difference of the expected value of 198 dice and having 199 dice is larger than 6 (by 10 − 21...)!

The optimizations that allowed him to calculate these numbers in a reasonable amount of time unfortunately was to assume that my original hypothesis (never rerolling a 6 is optimal), which held until n < 199. But this meant that for n > 199, the code did not yield correct results.

What is the rationale of the story? Don’t trust common sense when it comes to statistics; don’t judge a sequence just from a few initial numbers; if you have an interesting question, post it online and wait for 16 months.


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