Planet Debian

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

Russ Allbery: Another book haul

8 November, 2014 - 12:05

Someday there will be reviews. Also, software releases. But these posts are much easier to write in the evening when my brain is fried. Also, the anticipation of reading good books is delightful. The motivating reason for this order was that Powell's was giving away $10 gift cards with an order, so I bought books to buy more books later.

Iain M. Banks — Feersum Endjinn (sff)
Jacqueline Carey — Autumn Bones (sff)
Robert Caro — The Path to Power (non-fiction)
Keith Houston — Shady Characters (non-fiction)
Jan Morris — Hav (mainstream)
Arika Okrent — In the Land of Invented Languages (non-fiction)

I've been in a non-fiction mood lately, so lots of random non-fiction here.

The Caro is the first volume of his huge biography of LBJ, which is apparently one of the best biographies ever written. The other non-fiction is less serious: one about intentionally-created languages, and the other about the history of punctuation characters. Hav is a travel book about a city that doesn't actually exist, so it fits somewhat with the non-fiction theme.

Martin-Éric Racine: HEL has just frozen over. Wait. No. Debian did.

8 November, 2014 - 00:48
Noticing that Debian just entered its freeze, I went ahead and changed the APT sources on a spare host that is currently running stable. Then, it was time for this command to be executed:

sudo apt-get update && \
sudo apt-get install apt dpkg locales && \
sudo apt-get --purge dist-upgrade && \
sudo apt-get --fix-policy install && \
sudo apt-get --purge autoremove $(deborphan --guess-all)

I guess I'll be busy filing bug reports for the next few hours. Wish me (and each faulty package's maintainer) luck!

PS: Apparently, so many aspects of Debian have become dependent upon GPG features that merely upgrading APT, DPKG and libc6+locales is no longer enough. One must also upgrade gnupg and gnupg2. Thus, the second element of the above recipe has become:

sudo apt-get install apt dpkg gnupg gnupg2 locales && \

Hopefully, APT's dist-upgrade command already knows that these must be upgraded first...

PPS: Hosts running Network-Manager cannot be upgraded remotely, because Network-Manager insists upon killing the network connection and the SSH daemon with it, when its turn comes to get upgraded.

Richard Hartmann: Release Critical Bug report for Week 45

8 November, 2014 - 00:28


Please note that Lucas hacked a "key packages" count into this list. If you have spare cycles, look at those first.

I hope to have a (somewhat) random bug of the week thingie by next week which picks stalled bugs for increased exposure.

As you can see, we are a bit worse than in the Squeeze cycle, but way ahead of Wheezy. Stats with proper diffs will also start next week.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1154 (Including 190 bugs affecting key packages)
    • Affecting Jessie: 295 (key packages: 150) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 229 (key packages: 116) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 22 bugs are tagged 'patch'. (key packages: 12) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 14 bugs are marked as done, but still affect unstable. (key packages: 8) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 193 bugs are neither tagged patch, nor marked done. (key packages: 96) Help make a first step towards resolution!
      • Affecting Jessie only: 66 (key packages: 34) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 37 bugs are in packages that are unblocked by the release team. (key packages: 24)
        • 29 bugs are in packages that are not unblocked. (key packages: 10)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Diff 43 284 (213+71) 468 (332+136) +184 (+119/+65) 44 261 (201+60) 408 (265+143) +147 (+64/+83) 45 261 (205+56) 425 (291+134) +164 (+86/+78) 46 271 (200+71) 401 (258+143) +130 (+58/+72) 47 283 (209+74) 366 (221+145) +83 (+12/+71) 48 256 (177+79) 378 (230+148) +122 (+53/+69) 49 256 (180+76) 360 (216+155) +104 (+36/+79) 50 204 (148+56) 339 (195+144) +135 (+47/+90) 51 178 (124+54) 323 (190+133) +145 (+66/+79) 52 115 (78+37) 289 (190+99) +174 (+112/+62) 1 93 (60+33) 287 (171+116) +194 (+111/+83) 2 82 (46+36) 271 (162+109) +189 (+116/+73) 3 25 (15+10) 249 (165+84) +224 (+150/+74) 4 14 (8+6) 244 (176+68) +230 (+168/+62) 5 2 (0+2) 224 (132+92) +222 (+132/+90) 6 release! 212 (129+83) +212 (+129/+83) 7 release+1 194 (128+66) +194 (+128/+66) 8 release+2 206 (144+62) +206 (+144/+62) 9 release+3 174 (105+69) +174 (+105/+69) 10 release+4 120 (72+48) +120 (+72/+48) 11 release+5 115 (74+41) +115 (+74/+41) 12 release+6 93 (47+46) +93 (+47/+46) 13 release+7 50 (24+26) +50 (+24/+26) 14 release+8 51 (32+19) +51 (+32/+19) 15 release+9 39 (32+7) +39 (+32/+7) 16 release+10 20 (12+8) +20 (+12/+8) 17 release+11 24 (19+5) +24 (+19/+5) 18 release+12 2 (2+0) +2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

Niels Thykier: Release sprint – Preparing for Jessie

7 November, 2014 - 21:52

The release team are doing a sprint right now up the mini-DebConf in Cambridge, kindly hosted by ARM.

We have a fairly large agenda of around 10 items, ranging from “simple” things like determine the name for the next release to reviewing the list of RC bugs affecting Jessie.

Personally, I am very pleased with our progress.  We managed to finish 8 of items on the first day.  Furthermore, we spent several hours on the RC bug list and keeping up with the unblock requests.

There is also live status of the release team, courtesy of Jonathan Wiltshire.  Mind you it is manually updated.

We will announce the results of our sprint Sunday morning in our Release update talk.  The announcement will also be posted to debian-devel-announce like our freeze announcement.


Andrew Cater

7 November, 2014 - 19:09
At mini-Debconf Cambridge:

Much unintentional chaos and hilarity and world class problem solving yesterday.

A routine upgrade from Wheezy - Jessie died horribly on my laptop when UEFI variable space filled, leaving No Operating System on screen.

Cue much running around: Chris Boot, Colin Walters, Steve dug around, booted the system usng rescue CD and so on. Lots more digging, including helpful posts by mjg59 - a BIOS update may solve the problem.

Flashing BIOS did clear the variables and variable space and it all worked perfectly thereafter. This had the potential for turning the laptop into a brick under UEFI (but still working under legacy boot).

As it is, it all worked perfectly - but where else would you get _the_ Grub maintainer, 2 x UEFI experts and a broken laptop all in the same room ?

If it hadn't happened yesterday, it would have happened at home and I'd have been left with nothing. As it is, we all learnt/remembered stuff and had a useful time fixing it.

Andrew Cater

7 November, 2014 - 18:55
Here at the Debian mini-conf in Cambridge at ARM.

16 developers sat in near-total silence, the only noise keyboards and a server sitting next to me.

Some of them I've seen only on video presentations: one I first knew 20 years ago, one wrote all the HOWTO's I knew a couple of years before that - and was the second Linux user ever.

The release team is in another room behind me: Jessie froze the night before last - whatever else will be said/done, we're on the path to release.

It feels very strange and comforting to see Debian in the round: to be able to talk to someone you might argue with in email and see a real person.

And HUGE thanks to all at ARM for time, effort, chasing around and to Sledge and Jo  Jo most of all for being stuck on a front desk waiting for people :)

Steinar H. Gunderson: xkcd

7 November, 2014 - 18:04

Achievement unlocked: xkcd today has a comic about a product where I was part of the initial launch team. I suppose my work here is done.

Johannes Schauer: automatically suspending cpu hungry applications

7 November, 2014 - 15:51

TLDR: Using the awesome window manager: how to automatically send SIGSTOP and SIGCONT to application windows when they get unfocused or focused, respectively, to let the application not waste CPU cycles when not in use.

I don't require any fancy looking GUI, so my desktop runs no full-blown desktop environment like Gnome or KDE but instead only awesome as a light-weight window manager. Usually, the only application windows I have open are rxvt-unicode as my terminal emulator and firefox/iceweasel with the pentadactyl extension as my browser. Thus, I would expect that CPU usage of my idle system would be pretty much zero but instead firefox decides to constantly eat 10-15%. Probably to update some GIF animations or JavaScript (or nowadays even HTML5 video animations). But I don't need it to do that when I'm not currently looking at my browser window. Disabling all JavaScript is no option because some websites that I need for uni or work are just completely broken without JavaScript, so I have to enable it for those websites.

Solution: send SIGSTOP when my firefox window looses focus and send SIGCONT once it gains focus again.

The following addition to my /etc/xdg/awesome/rc.lua does the trick:

local capi = { timer = timer }
client.add_signal("focus", function(c)
if c.class == "Iceweasel" then
awful.util.spawn("kill -CONT " ..
client.add_signal("unfocus", function(c)
if c.class == "Iceweasel" then
local timer_stop = capi.timer { timeout = 10 }
local send_sigstop = function ()
if client.focus ~= c then
awful.util.spawn("kill -STOP " ..
timer_stop:add_signal("timeout", send_sigstop)

Since I'm running Debian, the class is "Iceweasel" and not "Firefox". When the window gains focus, a SIGCONT is sent immediately. I'm executing kill because I don't know how to send UNIX signals from lua directly.

When the window looses focus, then the SIGSTOP signal is only sent after a 10 second timeout. This is done for several reasons:

  • I don't want firefox to stop in cases where I'm just quickly switching back and forth between it and other application windows
  • When firefox starts, it doesn't have a window for a short time. So without a timeout, the process would start but immediately get stopped as there is no window to have a focus.
  • when using the X paste buffer, then the application behind the source window must not be stopped when pasting content from it. I assume that I will not spend more than 10 seconds between marking a string in firefox and pasting it into another window

With this change, when I now open htop, the process consuming most CPU resources is htop itself. Success!

I haven't encountered any disadvantages of this setup yet. If 10 seconds prove to be too short to copy and paste I can easily extend this delay. Even clicking on links in my terminal works flawlessly - the new tab will just only load once firefox gets focused again.

Russ Allbery: On tolerating personal abuse

7 November, 2014 - 12:04

While I don't consider myself part of the science fiction community directly (my con-going days are probably over), I do follow it across a wide variety of blogs. There are a lot of hard conversations and considerable soul-searching going on right now concerning an on-line commentator in that community who had been nasty and vicious to people, but originally for reasons that many people thought were good causes. (I had been one of those people. It's always very, very tempting to appreciate a good vitriolic rant from someone who shares your world view. And very easy to lose track of the people those rants are aimed at, or the excesses to which those rants go.)

I'm not going to go into the details of the SF community issues here, since I have no context other than what I've read, and it's something to work out within that community. But I've been taking it as a useful reminder that abusive behavior not acceptable, even if it comes from people who are arguably on your side.

Anger is important. Anger is often how the world changes. But anger and abuse are not the same thing.

I wrote something a little bit ago in a different context. Given that reminder, and given some of the arguments that are going on in the free software community as well, it seemed like a good idea to post a somewhat edited version of it in a more public place:

None of us should be willing to continue to participate in a project in which we're expected to tolerate being abused and attacked, and all consequences of that abuse are our problem to deal with. It is simply not fun, and not motivating, and not interesting, and does not lead to us doing good work.

I say this from lots of hard-won personal experience. I was deeply involved in Usenet governance for many years. I have made all the same arguments that I see today in favor of "blunt" speech, vitriol, and attacks. I have been a passionate advocate for the "free speech" approach. I have told other people to just filter and use killfiles. I have said that words aren't worth getting worked up about, and it's easy to ignore people.

I was wrong.

It took a long time for me to figure out that I was wrong, not just for other people, but for myself as well. It took me much longer to walk away from Usenet governance for good because the environment was too toxic. It remains one of the best decisions I have ever made in my life. It was the best bit of self-care that I ever did.

I learned from that experience, and earlier this year, I walked away from a job for related reasons. I enjoyed the work, the job was much easier than the job that I have now, and I had a lot of time to work on free software and on Debian, but the emotional environment was toxic. (It was not as openly abusive, but it was an environment of disrespect, hierarchical dominance games, fear, blame, and emotional blackmail.) As a result, I've had to shift priorities considerably, but I'm a much happier person. It's worth having less time for things that I was previously enjoying to not to have to deal with an emotionally negative and confrontational environment. Life is too short, and I have the luxury of having choices.

Both of those incidents taught me that it's very easy for me to leave that sort of situation to fester for too long, and that I underestimate how much of an improvement it is for my quality of life to walk away from abusive and negative emotional situations. I am belatedly learning how to be more ready and willing to do this.

I very much understand the people who are concerned with ensuring there is space for strongly-worded opinions and heartfelt anger.

But we have to draw a line, and that line needs to rule out emotional abuse of people in our community even in the name of passionate polemics about something that's important. We have to enforce that line, and if that means ejecting people from our community, that's what we have to do. Because, if we don't, we're also ejecting people from our community: the quiet people, the people who are just trying to get work done, or the people who have had past experience with abusive environments and understand the need to bail when an environment starts going in that direction.

I'm not going to put up with the sort of environment I put up with when doing Big Eight newsgroup creation. I'm not saying this as some sort of threat -- I'm saying this to try to be very clear that not standing up for the members of our community and not supporting each other against abuse and emotional attacks also has consequences, and will destroy that community for a lot of us. I'm saying that I am not interested in living in an environment of fear and blame. And one should never underestimate the human power of giving people space and community in which they can be comfortable, relaxed, and truly happy.

Walking the line between this stance and the "tone argument," in which people who are being abused or disenfranchised are attacked for being angry, is very difficult. There are some helpful rules of thumb, such as distinguishing between punching up and punching down, but those rules of thumb can fail or be distorted, as the SF community is learning. It's important that people be able to express anger. It's also important that people be able to name names and identify specific behaviors that they believe are worthy of that anger. But when that anger escalates into attacks, there is a real danger that passionate righteousness turns into passionate abusiveness, a danger of losing the sense of community in our own sense of righteousness. And that's not something we can or should accept.

It's going to take a lot of hard work, a lot of open conversation, and a lot of empathy and care to find that line. There are many things in the world right now that should provoke anger, and with that anger comes power for good. But with that anger can also come a destructive blindness. The anger I want is the anger that drives us to change the world together, the anger that leads to confronting others with a reflection of their own better natures and challenging them to become better, more compassionate people. The anger that leads a man to feed the homeless in the true meaning of civil disobedience. Not the anger that crushes our enemies.

Dirk Eddelbuettel: RcppRedis 0.1.2

7 November, 2014 - 09:34

A new release of RcppRedis is now on CRAN. It contains additional commands for hashes and sets, all contributed by John Laing and Whit Armstrong.

Changes in version 0.1.2 (2014-11-06)
  • New commands execv, hset, hget, sadd, srem, and smembers contributed by John Laing and Whit Armstrong over several pull requests.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. As always, more detailed information is on the RcppRedis page page.

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

Daniel Kahn Gillmor: GnuPG 2.1.0 in debian experimental

7 November, 2014 - 06:27
Today, i uploaded GnuPG 2.1.0 into debian's experimental suite. It's built for amd64 and i386 and powerpc already. You can monitor its progress on the buildds to see when it's available for your architecture.


GnuPG 2.1 offers many new and interesting features, but one of the most important changes is the introduction of elliptic curve crypto (ECC). While GnuPG 2.1 discourages the creation of ECC keys by default, it's important that we have the ability to verify ECC signatures and to encrypt to ECC keys if other people are using this tech. It seems likely, for example, that Google's End-To-End Chrome OpenPGP extension will use ECC. Users who don't have this capability available won't be able to communicate with End-To-End users.

There are many other architectural changes, including a move to more daemonized interactions with the outside world, including using dirmngr to talk to the keyservers, and relying more heavily on gpg-agent for secret key access. The gpg-agent change is a welcome one -- the agent now holds the secret key material entirely and never releases it -- as of 2.1 gpg2 never has any asymmetric secret key material in its process space at all.

One other nice change for those of us with large keyrings is the new keybox format for public key material. This provides much faster indexed access to the public keyring.

I've been using GnuPG 2.1.0 betas regularly for the last month, and i think that for the most part, they're ready for regular use.

Timing for debian

The timing between the debian freeze and the GnuPG upstream is unfortunate, but i don't think i'm prepared to push for this as a jessie transition yet, without more backup. I'm talking to other members of the GnuPG packaging team to see if they think this is worth even bringing to the attention of the release team, but i'm not pursuing it at the moment.

If you really want to see this in debian jessie, please install the experimental package and let me know how it works for you.

Long term migration concerns

GnuPG upstream is now maintaining three branches concurrently: modern (2.1.x), stable (2.0.x), and classic (1.4.x). I think this is stretches the GnuPG upstream development team too thin, and we should do what we can to help them transition to supporting fewer releases concurrently.

In the long-term, I'd ultimately like to see gnupg 2.1.x to replace all use of gpg 1.4.x and gpg 2.0.x in debian, but unlikely to to happen right now.

In particular, the following two bugs make it impossible to use my current, common monkeysphere workflow:

And GnuPG 2.1.0 drops support for the older, known-weak OpenPGPv3 key formats. This is an important step for simplification, but there are a few people who probably still need to use v3 keys for obscure/janky reasons, or have data encrypted to a v3 key that they need to be able to decrypt. Those people will want to have GnuPG 1.4 around.

Call for testing

Anyway, if you use debian testing or unstable, and you are interested in these features, i invite you to install `gnupg2` and its friends from experimental. If you want to be sensibly conservative, i recommend backing up `~/.gnupg` before trying to use it:

cp -aT .gnupg .gnupg.bak
sudo apt install -t experimental gnupg2 gnupg-agent dirmngr gpgsm gpgv2 scdaemon
If you find issues, please file them via the debian BTS as usual. I (or other members of the pkg-gnupg team) will help you triage them to upstream as needed.

Tags: ecc, experimental, gnupg

Junichi Uekawa: I was looking for a way to lock and reboot from gnome.

7 November, 2014 - 04:43
I was looking for a way to lock and reboot from gnome. And found out that those services are provided by GDM that lightdm didn't work.

Steve Kemp: Planning how to configure my next desktop

7 November, 2014 - 04:26

I recently setup a bunch of IPv6-only accessible hosts, which I mentioned in my previous blog post.

In the end I got them talking to the IPv4/legacy world via the installation of an OpenVPN server - they connect over IPv6 get a private IP address, and that is masqueraded via the OpenVPN-gateway.

But the other thing I've been planning recently is how to configure my next desktop system. I generally do all development, surfing, etc, on one desktop system. I use virtual desktops to organize things, and I have a simple scripting utility to juggle windows around into the correct virtual-desktop as they're launched.

Planning a replacement desktop means installing a fresh desktop, then getting all the software working again. These days I'd probably use docker images to do development within, along with a few virtual machines (such as the pbuilder host I used to release all my Debian packages).

But there are still niggles. I'd like to keep the base system lean, with few packages, but you can't run xine remotely, similarly I need mpd/sonata for listening to music, emacs for local stuff, etc, etc.

In short there is always the tendency to install yet-another package, service, or application on the desktop, which makes migration a pain.

I'm not sure I could easily avoid that, but it is worth thinking about. I guess I could configure a puppet/slaughter/cfengine host and use that to install the desktop - but I've always done desktops "manually" and servers "magically" so it's a bit of a change in thinking.

Riku Voipio: Adventures in setting up local lava service

7 November, 2014 - 03:28
Linaro uses LAVA as a tool to test variety of devices. So far I haven't installed it myself, mostly due to assuming it to be enermously complex to set up. But thanks to Neil Williams work on packaging, installation has got a lot easier. Follow the Official Install Doc and Official install to debian Doc, roughly looking like:

1. Install Jessie into kvm

kvm -m 2048 -drive file=lava2.img,if=virtio -cdrom debian-testing-amd64-netinst.iso
2. Install lava-server

apt-get update; apt-get install -y postgresql nfs-kernel-server apache2
apt-get install lava-server
# answer debconf questions
a2dissite 000-default && a2ensite lava-server.conf
service apache2 reload
lava-server manage createsuperuser --username default
$EDITOR /etc/lava-dispatcher/lava-dispatcher.conf # make sure LAVA_SERVER_IP is right
That's the generic setup. Now you can point your browser to the IP address of the kvm machine, and log in with the default user and the password you made.

3 ... 1000 Each LAVA instance is seite customized for the boards, network, serial ports, etc. In this example, we are ready to add a single arndale board.

cp /usr/lib/python2.7/dist-packages/lava_dispatcher/default-config/lava-dispatcher/device-types/arndale.conf /etc/lava-dispatcher/device-types/
sudo /usr/share/lava-server/ -s arndale arndale-01 -t 7001
This generates us a almost usable config for the arndale. For site specifics I have usb-to-serial. Outside kvm, I provide access to serial ports using the following ser2net config:

7001:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT
7002:telnet:0:/dev/ttyUSB1:115200 8DATABITS NONE 1STOPBIT
TODO: make ser2net not run as root and ensure usb2serial devices always get same name..

For automatic power reset, I wanted something cheap, yet something that wouldn't require much soldering (I'm not a real embedded engineer.. I prefer software side ;) . Discussed with Hector, who hinted about prebuilt relay boxes. Chose one from Ebay 8-port USB Relay. So now I have this cute boxed nonsense hack.

The USB relay is driven with a short script, hard-reset-1

stty -F /dev/ttyACM0 9600
echo -e '\xFF\x01\x00' > /dev/ttyACM0
sleep 1
echo -e '\xFF\x01\x01' > /dev/ttyACM0
Sidenote: If you don't have or want automated power relay for lava, you can always replace this this script with something along "mpg123 puny_human_press_the_power_button_now.mp3"

Both the serial port and reset script are on server with dns name aimless. So we take the /etc/lava-dispatcher/devices/arndale-01.conf that created and make it look like:

device_type = arndale
hostname = arndale-01
connection_command = telnet aimless 7001
hard_reset_command = slogin lava@aimless -i /etc/lava-dispatcher/id_rsa /home/lava/hard-reset-1
Since in my case I'm only going to test with tftp/nfs boot, the actual arndale boards needs only to be setup to have a u-boot bootloader ready on power-on.

Now everything is ready for a test job. I have a locally built kernel and device tree, and I export the directory using the httpd available by default in debian.. Python!

cd out/
python -m SimpleHTTPServer
Go to the lava web server, select api->tokens and create a new token. Next we add the token and use it to submit a job

$ sudo apt-get install lava-tool
$ lava-tool auth-add http://default@lava-server/RPC2/
$ lava-tool submit-job http://default@lava-server/RPC2/ lava_test.json
submitted as job id: 1
The first job should now be visible in the lava web frontend, in the scheduler -> jobs part. If everything goes fine, the relay will click in a moment and the job will finish in a few minutes.

Michal Čihař: Weblate 2.0

6 November, 2014 - 20:00

Weblate 2.0 has been released today. It comes with lot of improvements in backend and completely new user interface.

Full list of changes for 2.0:

  • New responsive UI using Bootstrap.
  • Rewritten VCS backend.
  • Documentation improvements.
  • Added whiteboard for site wide messages.
  • Configurable strings priority.
  • Added support for JSON file format.
  • Fixed generating mo files in certain cases.
  • Added support for GitLab notifications.
  • Added support for disabling translation suggestions.
  • Django 1.7 support.
  • ACL projects now have user management.
  • Extended search possibilites.
  • Give more hints to translators about plurals.
  • Fixed Git repository locking.
  • Compatibility with older Git versions.
  • Improved ACL support.
  • Added buttons for per language quotes and other special chars.
  • Support for exporting stats as JSONP.

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. Ready to run appliances will be soon available in SUSE Studio Gallery.

Weblate is also being used as official translating service for phpMyAdmin, Gammu, Weblate itself and others.

If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far!

Filed under: English phpMyAdmin SUSE Weblate | 0 comments | Flattr this!

Matthias Klumpp: The state of AppStream/GNOME-Software in Debian Jessie

6 November, 2014 - 17:34

… or “Why do I not see any update notifications on my brand-new Debian Jessie installation??”

This is a short explanation of the status quo, and also explains the “no update notifications” issue in a slightly more detailed way, since I am already getting bug reports for that.

As you might know, GNOME provides GNOME-Software for installation of applications via PackageKit. In order to work properly, GNOME-Software needs AppStream metadata, which is not yet available in Debian. There was a GSoC student working on the necessary code for that, but the code is not yet ready and doesn’t produce good results yet. Therefore, I postponed AppStream integration to Jessie+1, with an option to include some metadata for GNOME and KDE to use via a normal .deb package.

Then, GNOME was updated to 3.14. GNOME 3.14 moved lots of stuff into GNOME-Software, including the support for update-notifications (which have been in g-s-d before). GNOME-Software is also the only thing which can edit the application groups in GNOME-Shell, at least currently.

So obviously, there was no a much stronger motivation to support GNOME-Software in Jessie. The appstream-glib library, which GNOME-Software uses exclusively to read AppStream metadata, didn’t support the DEP-11 metadata format which Debian uses in place of the original AppSTream XML for a while, but does so in it’s current development branch. So that component had to be packaged first. Later, GNOME-Software was uploaded to the archive as well, but still lacked the required metadata. That data was provided by me as a .deb package later, locally generated using the current code by my SoC student (the data isn’t great, but better than nothing). So far with the good news.

But there are multiple issues at time. First of all, the appstream-data package didn’t pass NEW so far, due to it’s complex copyright situation (nothing we can’t resolve, since app-install-data, which appstream-data would replace, is in Debian as well). Also, GNOME-Software is exclusively using offline-updates (more information also on [1] and [2]) at time. This isn’t always working at the moment, since I haven’t had the time to test it properly – and I didn’t expect it to be used in Debian Jessie as well[3].

Furthermore, the offline-updates feature requires systemd (which isn’t an issue in itself, I am quite fine with that, but people not using it will get unexpected results, unless someone does the work to implement offline-updates with sysvinit).

Since we are in freeze at time, and obviously this stuff is not ready yet, GNOME is currently without update notifications and without a way to change the shell application groups.

So, how can we fix this? One way would of course be to patch notification support back into g-s-d, if the new layout there allows doing that. But that would not give us the other features GNOME-Software provides, like application-group-editing.

Implementing that differently and patching it to make it work would be more or at least the same amount of work like making GNOME-Software run properly. I therefore prefer getting GNOME-Software to run, at least with basic functionality. That would likely mean hiding things like the offline-update functionality, and using online-updates with GNOME-PackageKit instead.

Obviously, this approach has it’s own issues, like doing most of the work post-freeze, which kind of defeats the purpose of the freeze and would need some close coordination with the release-team.

So, this is the status quo at time. It is kind of unfortunate that GNOME moved crucial functionality into a new component which requires additional integration work by the distributors so quickly, but that’s something which isn’t worth to talk about. We need a way forward to bring update-notifications back, and there is currently work going on to do that. For all Debian users: Please be patient while we resolve the situation, and sorry for the inconvenience. For all developers: If you would like to help, please contact me or Laurent Bigonville, there are some tasks which could use some help.

As a small remark: If you are using KDE, you are lucky – Apper provides the notification support like it always did, and thanks to improvements in aptcc and PackageKit, it even is a bit faster now. For the Xfce and <other_desktop> people, you need to check if your desktop provides integration with PackageKit for update-checking. At least Xfce doesn’t, but after GNOME-PackageKit removed support for it (which was moved to gnome-settings-daemon and now to GNOME-Software) nobody stepped up to implement it yet (so if you want to do it – it’s not super-complicated, but knowledge of C and GTK+ is needed).


[3]: It looks like dpkg tries to ask a debconf question for some reason, or an external tool like apt-listchanges is interfering with the process, which must run completely unsupervised. There is some debugging needed to resolve these Debian-specific issues.

Dirk Eddelbuettel: A Software Carpentry workshop at Northwestern

6 November, 2014 - 09:44

On Friday October 31, 2014, and Saturday November 1, 2014, around thirty-five graduate students and faculty members attended a Software Carpentry workshop. Attendees came primarily from the Economics department and the Kellogg School of Management, which was also the host and sponsor providing an excellent venue with the Allen Center on the (main) Evanston campus of Northwestern University.

The focus of the two-day workshop was an introduction, and practical initiation, to working effectively at the shell, getting introduced and familiar with the git revision control system, as well as a thorough introduction to working and programming in R---from the basics all the way to advanced graphing as well as creating reproducible research documents.

The idea of the workshop had come out of discussion during our R/Finance 2014 conference. Bob McDonald of Northwestern, one of this year's keynote speakers, and I were discussing various topic related to open source and good programming practice --- as well as the lack of a thorough introduction to either for graduate students and researcher. And once I mentioned and explained Software Carpentry, Bob was rather intrigued. And just a few months later we were hosting a workshop (along with outstanding support from Jackie Milhans from Research Computing at Northwestern).

We were extremely fortunate in that Karthik Ram and Ramnath Vaidyanathan were able to come to Chicago and act as lead instructors, giving me an opportunity to get my feet wet. The workshop began with a session on shell and automation, which was followed by three session focusing on R: a core introduction, a session focused on function, and to end the day, a session on the split-apply-combine approach to data transformation and analysis.

The second day started with two concentrated session on git and the git workflow. In the afternoon, one session on visualization with R as well as a capstone-alike session on reproducible research rounded out the second day.

Things that worked

The experience of the instructors showed, as the material was presented and an effective manner. The selection of topics, as well as the pace were seen by most students to be appropriate and just right. Karthik and Ramnath both did an outstanding job.

No students experienced any real difficulties installing software, or using the supplied information. Participants were roughly split between Windows and OS X laptops, and had generally no problem with bash, git, or R via RStudio.

The overall Software Carpentry setup, the lesson layout, the focus on hands-on exercises along with instruction, the use of the electronic noteboard provided by etherpad and, of course, the tried-and-tested material worked very well.

Things that could have worked better

Even more breaks for exercises could have been added. Students had difficulty staying on pace in some of the exercise: once someone fell behind even for a small error (maybe a typo) it was sometimes hard to catch up. That is a general problem for hands-on classes. I feel I could have done better with the scope of my two session.

Even more cohesion among the topics could have been achieved via a single continually used example dataset and analysis.


Robert McDonald from Kellogg, and Jackie Milhans from Research Computing IT, were superb hosts and organizers. Their help in preparing for the workshop was tremendous, and the pick of venue was excellent, and allowed for a stress-free two days of classes. We could not have done this without Karthik and Ramnath, so a very big Thank You to both of them. Last but not least the Software Carpentry 'head office' was always ready to help Bob, Jackie and myself during the earlier planning stage, so another big Thank You! to Greg and Arliss.

Dirk Eddelbuettel: RPushbullet 0.1.1

6 November, 2014 - 09:17

A minor bugfix release 0.1.1 of the RPushbullet package (interfacing the neat Pushbullet service) landed on CRAN yesterday morning.

It cleans up a small issue related to the ability to transfer files between devices via the Pushbullet service where the ability to select a (non-default) target device has now been restored.

With that, allow me to borrow one excellent use case of RPushbullet from the blog of Karl Broman: how to use RPushbullet for error notifications from R:

options(error = function() {
    pbPost("note", "Error", geterrmessage())

This is very clever: should an error occur, you get immediate notification in browser or on your phone. Left as an exercise for the reader is to combine this with the equally excellent rfoaas package (github|cran) to get appropriately colourful error messages...

More details about the package are at the RPushbullet webpage and the RPushbullet GitHub repo.

Courtesy of CRANberries, there is also a diffstat report for this 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.

Lisandro Dami&aacute;n Nicanor P&eacute;rez Meyer: Early announce: Qt4 removal in Jessie+1

6 November, 2014 - 08:56
We the Debian Qt/KDE Team want to early-announce [maintainer warning] our decision to remove Qt4 from Jessie+1. This warning is mostly targeted at upstreams.

Qt4 has been deprecated since Qt5's first release on December 19th 2012, that means almost two years ago!

So far we had bugfixes-only releases, but upstream has announced that they will end this support on august 2015. This already means we will have to do a special effort from that point on for Jessie in case RC bugs appears, so having it in Jessie+1 is simply a non-go.

Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4. In order to easy the transition time we have provided Wheezy backports for Qt5.

Don't forget to take a look at the C++ API change page [1] whenever you start porting your application.


[maintainer warning] **Remember the freeze** and do not upload packages ported to Qt5 to unstable. The best thing you can do now is to ask your upstream if the code can be compiled against Qt5 and, why not, try it yourself.

Our first priority now is to release Jessie, and this is why this is an early announce.

Rapha&#235;l Hertzog: My Free Software Activities in October 2014

5 November, 2014 - 22:19

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

Packaging work

With the Jessie freeze approaching, I took care of packaging some new upstream releases that I wanted to get in. I started with zim 0.62, I had skipped 0.61 due to some annoying regressions. Since I had two bugs to forward, I took the opportunity to reach out to the upstream author to see if he had some important fixes to get into Jessie. This resulted in me pushing another update with 3 commits cherry picked from the upstream VCS. I also sponsored a wheezy-backports of the new version.

I pushed two new bugfixes releases of Publican (4.2.3 and 4.2.6) but I had to include a work-around for a bug that I reported earlier on docbook-xml (#763598: the XML catalog doesn’t allow libxml2/xmllint to identify the local copy of some entities files) and that is unlikely to be fixed in time for Jessie.

Last but not least, I pushed the first point release of Django 1.7, aka version 1.7.1 to unstable and asked release managers to ensure it migrates to testing before the real freeze. This is important because the closer we are to upstream, the easier it is to apply security patches during the lifetime of Jessie (which will hopefully be 5 years, thanks to Debian LTS!). I also released a backport of python-django 1.7 to wheezy-backports.

I sponsored galette 0.7.8+dfsg-1 fixing an RC bug so that it can get back to testing (it got removed from testing due to the bug).

Debian LTS

See my dedicated report for the paid work I did on that area. Apart from that, I took some time to get in touch with all the Debian consultants and see if they knew some companies to reach out. There are a few new sponsors in the pipe thanks to this, but given the large set of people that it represents, I was expecting more. I used this opportunity to report all bogus entries (i.e bouncing email, broken URL) to the maintainer of the said webpage.

Distro Tracker

Only 30 commits this month, with almost no external contribution, I’m a bit saddened by this situation because it’s not very difficult to contribute to this project and we have plenty of easy bugs to get you started.

That said I’m still happy with the work done. Most of the changes have been made for Kali but will be useful for all derivatives: it’s now possible to add external repositories in the tracker and not display them in the list of available versions, and not generate automatic news about those repositories. There’s a new “derivative” application which is only in its infancy but can already provide a useful comparison of a derivative with its parent. See it in action on the Kali Package Tracker: Thanks to Offensive Security which is sponsoring this work!

Since I have pushed Django 1.7 to wheezy-backports, all distro tracker instances that I manage are now running that version of Django and I opted to make that version mandatory. This made it possible to add initial Django migrations and rely on this new feature for future database schema upgrade (I have voluntarily avoided schema change up to now to avoid problems migrating from South to Django migrations).


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

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


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