Planet Debian

Wouter still does not like the 3.0 (quilt) packaging format. And as he writes on his blog, I shall answer on mine.

And what if one of the blogs becomes unreachable with time? Aha! That's one of the weaknesses, Wouter, on yuor closing comment:

I have all my packages stored in git with a proper Vcs-Git: header; if people really want to look at individual patches, they can just use debcheckout, kthxbye.

I am aware this would not be so much of an argument, or so much of a change. But the way I view a shipped package is that it should, by itself, be as a snapshot with its whole, full description. Say that three years from now Apple has scrubbed your brain and you went to work with them. And you decided to pull all of your non-iOS repositories. They have convinced you working for Debian is bad for mankind. So you erase all of your Git repos, including those in Alioth or whatever.

But Debian Wheezy has some of your packages. And three years from now, I decided to be the maintainer.

So, having fully commented and individually marked patches is a sort-of-way to avoid a situation akin to the tentacles of evil.

Now, it's not that I'm criticizing your workflow. I have sen many ways to manage patches in quite a natural way, and I undestand it might be way easier when dealing with complex packages (FWIW I usually deal with very little complexity). Still, it is an argument.

If you see a bunch of X.org packages upgrades pending in your Squeeze or brand new Wheezy system, don't panic!

Ilja van Sprundel, a security researcher from IOActive, has discovered a large number of issues in the various X client libraries and he has worked with X.Org's security team to analyze, confirm, and fix these issues. You can find more information in the security avisory from X.org.

The Debian Security and X.org teams have quickly updated all the affected packages in Squeeze and Wheezy. You can see the full list of updates in the debian-security-announce mailing list archives.

I had a look at the 3.0 source formats just now. I've never been very fond of that, mainly because of the fact that it wants to store individual patches for no particularly good reason1. However, recently I found out about the --single-debian-patch option to dpkg-source, which makes the 3.0 (quilt) format behave somewhat more like the non-native 1.0 format, which is good.

Unfortunately, "somewhat more" does not mean "entirely". For some weird reason, after converting the source to a 3.0 source package and running "dpkg-buildpackage", I find that suddenly my source tree is devoid of the patches that I'd applied to it.

I'm sure there's another option hidden somewhere to make it not do that either, but I was quickly annoyed about it enough that I didn't care anymore. I just removed the debian/source directory entirely again, instead.

Maybe I'll look into this again at some future point, but it's pretty unlikely.

1I have all my packages stored in git with a proper Vcs-Git: header; if people really want to look at individual patches, they can just use debcheckout, kthxbye.

Hopefully hiding this post will work this time. Apologies if not.

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

• In Total: 1080
  • Affecting Jessie: 276 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: 217 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 30 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 20 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 167 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 59 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.
      • 0 bugs are in packages that are unblocked by the release team.
      • 59 bugs are in packages that are not unblocked.

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:

I did a 0.2.2 maintenance release for umockdev to fix building with Vala 0.16.1, gcc 4.8 (the changed sizeof behaviour caused segfaults), and current udev releases (umockdev-record stumbled over the new “link priority” fields of udevadm). There are also a couple of bug fixes, but no new features.

In the series of my efforts of pushing for more Linked Data to be published by FLOSS development tools, here’s another installment.

The ADMS.SW plugin for FusionForge that I’ve developped has seen its first public deployment on the ADULLACT forge, thanks to the funding of the ISA programme of the European Commission.

This means that the 500 more projects hosted on the ADULLACT forge, mainly developped by public adminstrations, are now documented using the RDF Turtle dialect, as Linked Data.

A first use can be for Free and Open source portals which will be able to harvest them from the source.

See more details at First deployment of ADMS.SW plugin for FusionForge on Adullact.

Other forges are expected to follow, like CENATIC’s or Debian’s Alioth, all powered by FusionForge.

The plugin is not yet perfect, and in particular wrt performance issues, but that was kind of expected from a first prototype. Stay tuned for more news.

This is an update on the Xfce 4.10 transition to unstable. Most desktop components have been uploaded, built and installed to the archive.

We're now currently building and uploading the various goodies, and especially panel plugins. There's a lot of them so it takes some time.

Once we'll have finished to build and upload all the goodies, we'll ask for binNMUs on the packages which don't need a sourceful upload but need to be rebuilt against libxfce4util or xfce4-panel 4.10.

You can follow the transition status using the release team page.

In any case, please be patient while we upload all the packages. Again, no need to report installability issues in unstable for now, we are aware of it and don't need more warnings. We'll fix the fallouts in due time.

I’ve been hacking on some static analyses stuff for debuild.me, and i’ve been involved in a multi-year long yak shaving exercise. As today’s fun part, I wrote python-schroot to help run commands in a schroot chroot (say that 10 times fast!)

After a while, I got some neat stuff working. Here’s an honest example:

from schroot import schroot with schroot('unstable-amd64') as chroot: chroot.copy('/etc/issue', '/etc/issue', user='root')

This will copy a file (/etc/issue) from the “host” system into the schroot chroot. Neat!

Now, to run something:

with schroot('unstable-amd64') as chroot: out, err, ret = chroot.run("whoami") print(out)

Then, in an effort to make a DSL, I set out to create the following syntax:

with schroot('unstable-amd64') as chroot: "apt-get update" in chroot

 but, hit some issues with implementing it, and got the following to work:

with schroot('unstable-amd64') as chroot: "apt-get update" > chroot // "root" # apt-get update as root

More later!

I want a CLI WebDAV client that's better than cadaver or hdav.

I want a program that can sync an .ics file with a CalDAV server, by dividing it up into events and individually synchronizing each of those. I don't have a clue how deletions would be handled, but that would be nice too. Then I want a program that can synchronize the .ics file with org-mode files.

I want a SIP client that works as well as Twinkle but has the architecture of SFLphone or is a library upon which an arbitrary UI can be constructed.

I want an HTML-rendering library that has callbacks or hooks for security- and privacy-relevant things like cookies and SSL certificates. I want at least one browser built on this library. I want it to support vi-like keybindings.

I want an HTTP(S) proxy that can be dynamically-configured per-client or per-connection through a standardized protocol that web browsers or their plugins can speak. I want it to be able to handle all the relevant things covered by AdBlock Plus, RequestPolicy, and NoScript.

I want HTTPS authentication through Monkeysphere and mod_gnutls.

I want a git-annex backend for Ogg Vorbis files that treat the audio streams independently of the metadata yet stores them together in the same file so that everything behaves as usual but the annex doesn't bloat by 400Go after I run beets.

I want a file transfer queuing system that can work over any sort of transport mechanism, direct or asynchronous, that handles partial transfers and throttling, and is generally magical.

I want all kinds of accounting software improvements.

I want sane PBX software.

I want an OpenStack that doesn't use libvirt for KVM.

I want backup software that behaves some weird hybrid of BoxBackup and Dirvish.

I want a peer-to-peer card- and board-game platform that uses cryptographic assurance.

I want everyone to use YAML instead of XML.

I want a phone that's not running a doomed operating system.

I want lots of other stuff.

Although I've still not got the ability to reply to messages, and composing new ones is ugly, my toy mail client is working nicely.

I've received a couple of patches, and given commit access to the repository to one other user.

Currently I'm still juggling primitives around and working out what is missing. The big exceptions are the obvious:

• Cannot reply to a message.
• Cannot move a message to a new folder.
• When composing a mail to be sent no copy is saved in "sent-mail", or similar.
• Thread-view is absent. Indefinitely.

But on the plus side the lua scripting is lovely:

precious ~/git/lumail $ rm /tmp/unread.log precious ~/git/lumail $ ./lumail --rcfile ./lumail.lua --eval "dump_unread();" precious ~/git/lumail $ head /tmp/unread.log Selected folder /home/skx/Maildir/.Automated.backups Folder has 10 unread messages Selected folder /home/skx/Maildir/.Automated.bounces Folder has 3 unread messages Selected folder /home/skx/Maildir/.CRM.Spam Folder has 7 unread messages Selected folder /home/skx/Maildir/.facebook.com Folder has 4 unread messages ..

The website needs some love, most notably a logo. And there are several reported bugs/todo-items I need to work through.

Still for a toy program I'm using it daily. (Though still using mutt to reply to messages & view/save attachments.)

About 10 years ago I started using an electric shaver. An electric shaver is more convenient to use as it doesn’t require any soap, foam, or water. It is also almost impossible to cut yourself properly with an electric shaver which is a major benefit for anyone who’s not particularly alert in the morning. Generally my experience of electric shavers has been good, although the noise is quite annoying.

Recently a friend told me that an electric shaver is as noisy as a chain-saw. Given the inverse-square law and the fact that the shaver operates within 1cm of my ears that sounds plausible. So the risk of hearing loss is a great concern. Disposable ear plugs are very cheap and they can be used multiple times (they don’t get particularly dirty while shaving or get squashed in the short time needed to shave). So for a few weeks I’ve been using ear plugs while shaving which reduces the noise and presumable saves me from some hearing damage – although after 10 years of using electric shavers I may have already sustained some damage.

According to Cooper Safety their ear plugs reduce noise by 29dB, [1] I presume that the cheap ones I bought from Bunnings would be good for at least 15dB.

According to Better Hearing Sydney the noise from an electric shaver is typically around 90dB, less than the 100dB that is typical of a chain-saw [2]. So if my ear-plugs are good for 15dB then they would reduce the noise from a typical electric shaver to 75dB which is well below the 85dB that will cause hearing damage. Given that the noise from a typical shaver is only slightly above the damage threshold it seems that I might not need particularly good ear-plugs when shaving.

A quick scan of shaver reviews indicates that the amount of noise differs by brand and technology. The Hubpages review suggests that rotary shavers tend to make less noise than foil shavers [3], but I’m sure that it varies enough between brands that some rotary shavers are louder than the quietest foil shavers. It seems that the best thing to do when buying a new shaver would be to go to a specialised shaver shop (which has many models on offer) and get the staff to demonstrate them to determine which is the quietest. If a typical shaver produces 90dB then it seems likely that one of the more quiet models would produce less than 85dB.

Another item on my todo list is to buy a noise meter to measure the amount of noise produced in the places where I spend time. There are some Android apps to measure noise, I’m currently playing with the Smart Tools Co Sound Meter [4] which gives some interesting information. The documentation notes that phone microphones are limited to the typical volume and frequencies of human voice, so my Galaxy S3 can’t measure anything about 81dB. My wife’s Nexus 4 doesn’t seem to register anything above 74dB. Additionally there is some uncertainty about the accuracy of the microphone, there is a calibration feature but that requires another meter. Anyway the Sound Meter app suggests that my shaver (a Philips HQ7380/B) produces only 71dB at the closest possible range – and drops down to 67dB at the range I would use if I grew sideburns.

Conclusion

Getting a proper noise meter to protect one’s hearing seems like a good idea. An Android app for measuring noise is a good thing to have, even though it’s not going to be accurate it’s convenient and will give an indication.

When buying a shaver one should listen to all the options and choose a quiet one (I might have got a quiet one by luck).

Sideburns seem like a good idea if you value your hearing.

• [1] http://www.coopersafety.com/NoiseReduction.aspx
• [2] http://www.betterhearingsydney.org.au/content/view/46/53/
• [3] http://tinyurl.com/ojxfx9t
• [4] https://play.google.com/store/apps/details?id=kr.sira.sound

Related posts:

1. Testing Noise Canceling Headphones This evening I tested some Noise Canceling Headphones (as...
2. Noise Canceling Headphones and People Talking The Problem I was asked for advice on buying headphones...
3. Noise in Computer Rooms Some people think that you can recognise a good restaurant...

For a while now, I've been plagued with this ridiculous problem of the keyboard becoming "stuck" in my Fedora 17 VM running under VirtualBox. Keys would stop working until you held them down for several seconds, making typing close to impossible.

Of course, my first thought was to blame VirtualBox, since it has a lot to do with the keyboard. I found out some interesting things, like you can send scan-codes directly to virtual-machines with something like

$ VBoxManage controlvm UUID keyboardputscancode aa

(get the UUID via VBoxManage list vms; figuring out scan-codes is left to the reader!).

I noticed the problem primarily happening while emacs was in the foreground, meaning I was working on code or an email ... my theory was when I typed too fast some race got hit and put the keyboard into a weird state that a reboot fixed.

Well it turns out the problem is almost the exact opposite. Luckily, today I noticed "slow keys enabled" warning that sprung-up and went away quickly just before the keyboard stopped. Once I saw that the game was up; turns out this is a well-known bug that is easily fixed with xkbset -sl. It happens because I was typing too slowly; holding down the shift-key while I thought about something probably.

Hopefully this saves someone else a few hours!

It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2013. This is a snapshot of Debian "sid" at the time of the Debian "wheezy" release (May 2013), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release.

The installation ISO images can be downloaded from Debian Ports in the usual three Debian flavors: NETINST, CD, DVD. Besides the friendly Debian installer, a pre-installed disk image is also available, making it even easier to try Debian GNU/Hurd.

Debian GNU/Hurd is currently available for the i386 architecture with more than 10.000 software packages available (more than 75% of the Debian archive, and more to come!).

Please make sure to read the configuration information, the FAQ, and the translator primer to get a grasp of the great features of GNU/Hurd.

Due to the very small number of developers, our progress of the project has not been as fast as other successful operating systems, but we believe to have reached a very decent state, even with our limited resources.

We would like to thank all the people who have worked on GNU/Hurd over the past decades. There were not many people at any given time (and still not many people today, please join!), but in the end a lot of people have contributed one way or another. Thanks everybody!

This article appeared originally at GNU Hurd news and it's under the GNU Free Documentation License, Version 1.2 or any later version.

Not so long ago I read Dmitrijs' blog post on how to configure apt-cacher-ng to advertise it's service using avahi. As I normally use my laptop in my home and at work, and both networks have apt-cacher-ng running, I decided to give it a try.

I have been administering apt-cacher-ng for three networks so far, and I really find it a useful tool. Then, thanks to the aforementioned blog post, I discovered squid-deb-proxy. I don't use squid, so it's not for my normal use case, but some people will surely find it interesting.

But I found it's client package to be really interesting. It will discover any service providing _apt_proxy._tcp through avahi and let apt use it. But then the package wasn't available in Debian. So, I contacted Michael Vogt to see if he was interested in putting at least the client in Debian's archive. He took the opportunity to upload the full squid-deb-proxy, so thanks a lot Michael :-)

I then filled a wishlist bug against apt-cacher-ng to provide the avahi configuration for publishing the service, which Eduard included in the last version of it. So thanks a lot Eduard too!

tl;dr
You know only need apt-cacher-ng >= 0.7.13-1 and avahi-daemon installed on your server and your mobile users just need squid-deb-proxy-client. Then the proxy autoconfiguration for apt will just work.

One again, thanks a lot to the respective maintainers for allowing this into Jessie :-)

Gotchas
Yes, there are still some rough edges. On one of the networks I'm behind a proxy. While configuring my machine to use apt-cacher-ng's service as a proxy trough apt.conf, apt-listbugs would just work. But now, using the service as discovered by squid-deb-proxy-client, apt-listbugs just times out. Maybe I need to fill some other bug yet...

cowbuilder can call lintian via hook script, but piuparts needs to be run under privilege, then failed. umm... 

Finally arrived at LinuxTag after an extended flight delay.

Turns out that speakers get 5 free tickets and I have no idea what to do with them. If you want to visit my talk or just need a free ticket, please poke me on IRC or by email. First come, first served.

Sometimes it happens that for one reason or another there's a need to use a proprietary application (read: can not be modified due to its licence) that contains bashisms. Since the application can not be modified and it might not be desirable to change the default /bin/sh, dealing with such applications can be a pain. Or not.

The switchsh program (available in Debian) by Marco d'Itri can be used to execute said application under a namespace where bash is bind-mounted on /bin/sh. The result:

$ sh --help
sh: Illegal option --
$ switchsh sh --help | head -n1
GNU bash, version 4.1.5(1)-release-(i486-pc-linux-gnu)

Simple, yet handy.

Thanks to the release team ACK, I've started uploading Xfce 4.10 to unstable yesterday. For now, I've only pushed Xfce 4.10.1 desktop components, which means people using xfce4 + xfce4-goodies in unstable won't be able to upload at once.

That's because panel plugins have a quite hard dependency on the running xfce4-panel, and the communication protocol has changed between Xfce 4.8 and 4.10. So all panel plugins need to be rebuild against the new xfce4-panel. I'll start uploading new releases or packages revisions this evening, and binNMUs will be scheduled for the rest, but it'll take some days.

In the meantime, you can safely wait before upgrading xfce4. If you don't use external panel plugins, then you can accept to remove xfce4-goodies and the various xfce4-*-plugins and upgrade to xfce4 4.10.

There's no need to report a bug about that situation, we're already aware of it and it's somehow intended, things will settle in a few days.

AltOS 1.2.1 — TeleBT support, bug fixes and new AltosUI features

Bdale and I are pleased to announce the release of AltOS version 1.2.1.

AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based micro-controller firmware and Java-based ground station software.

The biggest new feature for AltOS is the addition of support for TeleBT, our ground station designed to operate with Android phones and tablets. In addition, there’s a change in the TeleDongle radio configuration that should improve range, some other minor bug fixes and new features in AltosUI

AltOS Firmware — Features and fixes

There are bug fixes in both ground station and flight software, so you should plan on re-flashing both units at some point. However, there aren’t any incompatible changes, so you don’t have to do it all at once.

New features:

• TeleBT support.

• Improved radio sensitivity. The TeleDongle receiver parameters have been tweaked to provide better reception.

• TeleMini now completely resets all radio parameters in recovery mode (with the two outer debug pins connected) — 434.550MHz, N0CALL, factory radio cal.

Bug fixes:

• USB device fixes. This improves operation with Windows, avoiding hangs and errors in many cases.

• Correct the Kalman filter error covariance matrix; the old parameters were built assuming continuous measurements.

AltosUI — Easier to use

AltosUI has also seen quite a bit of work for the 1.2.1 release. It’s got several fun new features and a few bug fixes.

New Graph UI features:

• Show tool-tips with the value near the cursor.

• Make the set of displayed values configurable. Add all of the available data values just in case you want to see them.

• Added a Map tab showing the ground track of the whole flight.

• The flight summary tab now includes the final GPS position. This lets you figure out where your rocket landed without replaying the whole flight.

Other new AltosUI features:

• TeleBT support, including Bluetooth connections (Linux-only, at present).

• Shows the callsign in the Monitor Idle and other command-mode windows so that you can tell what callsign is being used.

• Show the block number when downloading flight data. This lets you see something happen even for longer flights.

• Make the initial position of the AltosUI configurable so that you can position it out of the way of the rest of you desktop.

• Distribute Mac OS X in .dmg format (Mac OS Disk Image); this means you don’t need to explicitly unpack the bits.

Bug fixes:

• Deal with broken networking while downloading map tiles. Tiles are now always downloaded asynchronously so that the UI doesn’t freeze when the network is slow.

Keith and I are pleased to announce the immediate availability of TeleBT, a new Altus Metrum ground station product providing the equivalent of TeleDongle plus Bluetooth.

TeleBT working with AltosDroid on an Android device provides everything needed to monitor a rocket in flight, record telemetry, and know how to walk right to the airframe after it's back on the ground.

The Bluetooth capability of TeleBT is also supported by AltosUI on Linux, and with a micro USB cable TeleBT works just like TeleDongle on Windows, Mac, and Linux systems running AltOS version 1.2.1 or later.