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.

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!

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

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

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.

A common topic of discussion on computer users group mailing lists is advice on buying a PC. I think that most of the offered advice isn t particularly useful with an excessive focus on building or upgrading PCs and on getting the latest and greatest. So I ll blog about it instead of getting involved in more mailing-list debates. A Historical Perspective the PC as an Investment In the late 80 s a reasonably high-end white-box PC cost a bit over $5,000 in Australia (or about $4,000 without a monitor). That was cheaper than name-brand PCs which cost upwards of $7,000 but was still a lot of money. $5,000 in 1988 would be comparable to $10,000 in today s money. That made a PC a rather expensive item which needed to be preserved. There weren t a lot of people who could just discard such an investment so a lot of thought was given to upgrading a PC. Now a quite powerful desktop PC can be purchased for a bit under $400 (maybe $550 if you include a good monitor) and a nice laptop is about the same price as a desktop PC and monitor. Laptops are almost impossible to upgrade apart from adding more RAM or storage but hardly anyone cares because they are so cheap. Desktop PCs can be upgraded in some ways but most people don t bother apart from RAM, storage, and sometimes a new video card. If you have the skill required to successfully replace a CPU or motherboard then your time is probably worth enough that getting more value out of a PC that was worth $400 when new and is worth maybe $100 when it s a couple of years old probably isn t a good investment. Times have changed and PCs just aren t worth enough to be bothered upgrading. A PC is a disposable item not an investment. Buying Something Expensive? There are a range of things that you can buy. You can spend $200 on a second-hand PC that s a couple of years old, $400 on a new PC that s OK but not really fast, or you can spend $1000 or more on a very high end PC. The $1000 PC will probably perform poorly when compared to a PC that sells for $400 next year. The $400 PC will probably perform poorly when compared to the second-hand systems that are available next year. If you spend more money to get a faster PC then you are only getting a faster PC for a year until newer cheaper systems enter the market. As newer and better hardware is continually being released at low enough prices that make upgrades a bad deal I recommend just not buying expensive systems. For my own use I find that e-waste is a good source of hardware. If I couldn t do that then I d buy from an auction site that specialises in corporate sales, they have some nice name-brand systems in good condition at low prices. One thing to note is that this is more difficult for Windows users due to anti-piracy features. With recent versions of Windows you can t just put an old hard drive in a new PC and have it work. So the case for buying faster hardware is stronger for Windows than for Linux. That said, $1,000 isn t a lot of money. So spending more money for a high-end system isn t necessarily a big deal. But we should keep in mind that it s just a matter of getting a certain level of performance a year before it is available in cheaper systems. Getting a $1,000 high-end system instead of a $400 cheap system means getting that level of performance maybe a year earlier and therefore at a price premium of maybe $2 per day. I m sure that most people spend more than $2 per day on more frivolous things than a faster PC. Understanding How a Computer Works As so many things are run by computers I believe that everyone should have some basic knowledge about how computers work. But a basic knowledge of computer architecture isn t required when selecting parts to assemble to make a system, one can know all about selecting a CPU and motherboard to match without understanding what a CPU does (apart from a vague idea that it s something to do with calculations). Also one can have a good knowledge of how computers work without knowing anything about the part numbers that could be assembled to make a working system. If someone wants to learn about the various parts on sale then sites such as Tom s Hardware [1] provide a lot of good information that allows people to learn without the risk of damaging expensive parts. In fact the people who work for Tom s Hardware frequently test parts to destruction for the education and entertainment of readers. But anyone who wants to understand computers would be better off spending their time using any old PC to read Wikipedia pages on the topic instead of spending their time and money assembling one PC. To learn about the basics of computer operation the Wikipedia page for CPU is a good place to start. Then the Wikipedia page for hard drive is a good start for learning about storage and the Wikipedia page for Graphics Processing Unit to learn about graphics processing. Anyone who reads those three pages as well as a selection of pages that they link to will learn a lot more than they could ever learn by assembling a PC. Of course there s lots of other things to learn about computers but Wikipedia has pages for every topic you can imagine. I think that the argument that people should assemble PCs to understand how they work was not well supported in 1990 and ceased to be accurate once Wikipedia became popular and well populated. Getting a Quality System There are a lot of arguments about quality and reliability, most without any supporting data. I believe that a system designed and manufactured by a company such as HP, Lenovo, NEC, Dell, etc is likely to be more reliable than a collection of parts uniquely assembled by a home user but I admit to a lack of data to support this belief. One thing that is clear however is the fact that ECC RAM can make a significant difference to system reliability as many types of error (including power problems) show up as corrupted memory. The cheapest Dell PowerEdge server (which has ECC RAM) is advertised at $699 so it s not a feature that s out of reach of regular users. I think that anyone who makes claims about PC reliability and fails to mention the benefits of ECC RAM (as used in Dell PowerEdge tower systems, Dell Precision workstations, and HP XW workstations among others) hasn t properly considered their advice. Also when discussing overall reliability the use of RAID storage and a good backup scheme should be considered. Good backups can do more to save your data than anything else. Conclusion I think it s best to use a system with ECC RAM as a file server. Make good backups. Use ZFS (in future BTRFS) for file storage so that data doesn t get corrupted on disk. Use reasonably cheap systems as workstations and replace them when they become too old. Update: I find it rather ironic when a discussion about advice on buying a PC gets significant input from people who are well paid for computer work. It doesn t take long for such a discussion to take enough time that the people involved could spent their time working instead, put enough money in a hat to buy a new PC for the user in question, and still had money left over.

• [1] http://www.tomshardware.com/

In the past, we have had multiple heated discussions involving systemd. We (the pkg-systemd-maintainers team) would like to better understand why some people dislike systemd. Therefore, we have created a survey, which you can find at http://survey.zekjur.net/index.php/391182 Please only submit your feedback to the survey and not this thread, we are not particularly interested in yet another systemd discussion at this point. The deadline for participating in that survey is 7 days from now, that is 2013-05-26 23:59:00 UTC. Please participate only if you consider yourself an active member of the Debian community (for example participating in the debian-devel mailing list, maintaining packages, etc.). Of course, we will publish the results after the survey ends. Thanks! Best regards,
the Debian systemd maintainers

I usually try to avoid administering printers whenever possible. As a result I end of flailing around the CUPS web interface before I figure out how to re-enable a printer. And, when I get a call to help debug a printer, I can't easily tell people what to do. When I try to do what I need via the command line, I end up spending at least 10 or 15 minutes re-reading man pages before I piece together the steps. Here's my attempt to document the steps so I don't have to re-read man pages. Setup In these examples, the printer name in question is: stability and it is a network printer, with local DNS that properly resolves the hostname stability to an IP address. The cups commands in these examples can be run as a non-root user if that user is in the lpadmin group. Type:

groups

To see if lpadmin is listed. If not:

sudo adduser <your-user-name> lpadmin

Then, to gain access to the new group without logging out and logging in again:

newgrp lpadmin

Network access First, try to ping the printer:

ping stability

If this fails, restart the printer and/or check network cables. No point in doing anything else until it responds to pings. Can't submit new jobs to the printer Next, if the problem is that the printer is greyed out when you try to print a document or your application tells you that the printer is rejecting jobs, confirm this status with:

lpstat -a stability

It will either output:

stability accepting requests since Mon 20 May 2013 10:28:57 AM EDT

Or

stability not accepting requests since Mon 20 May 2013 10:28:57 AM EDT -
  Rejecting Jobs

If it is rejecting jobs, try:

/usr/sbin/cupsaccept stability

Accepts new jobs, but just doesn't print On the other hand, if the printer is accepting jobs, but the jobs are not printing, find out if the printer is enabled with:

lpstat -p stability

You should get either:

printer stability is idle.  enabled since Mon 20 May 2013 10:28:57 AM EDT

Or:

printer stability disabled since Mon 20 May 2013 10:35:10 AM EDT -
  Paused

If it is disabled, you should first see what queued jobs there are:

lpq

If you have a list of duplicate pending jobs, be sure to delete the duplicates to avoid having your print job come out multiple times. To delete a queued job, type the following (n should be the number in the Job column of the lpq output):

cancel <n>

After you have deleted duplicate jobs, try "enabling" it:

/usr/sbin/cupsenable stability

Then, re-rerun the lpq command and see if it's now "ready." At this point, the jobs should start printing. Review of concepts For review... a few important concepts:

• cupsaccept/cupsreject: controls whether a printer will accept or reject new jobs. It doesn't matter whether the printer is enabled or disabled.
• cupsenable/cupsdisable: controls whether a printer will print existing jobs. It doesn't matter whether the print is accepting or rejecting new jobs.

Occasionally, someone asks me whether we should encourage use of the --ask-cert-level option when certifying OpenPGP keys with gpg. I see no good reason to use this option, and i think we should discourage people from trying to use it. I don't think there is a satisfactory answer to the question "how will specifying the level of identity certification concretely benefit anyone involved?", and i don't see why we should want one. gpg gets it absolutely right by not asking users this question by default. People should not be enabling this option. Some background: gpg's --ask-cert-level option allows the user who is making an OpenPGP identity certification to indicate just how sure they are of the identity they are certifying. The user's choice is then mapped into four levels of OpenPGP certification of a User ID and Public-Key packet, which i'll refer to by their signature type identifiers in the OpenPGP spec:

0x10: Generic certification

The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID.

0x11: Persona certification

The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified.

0x12: Casual certification

The issuer of this certification has done some casual verification of the claim of identity.

0x13: Positive certification

The issuer of this certification has done substantial verification of the claim of identity.

Most OpenPGP implementations make their "key signatures" as 0x10 certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types.

By default (if --ask-cert-level is not supplied), gpg issues certificates ("signs keys") using 0x10 (generic) certifications, with the exception of self-sigs, which are made as type 0x13 (positive). When interpreting certifications, gpg does distinguish between different certifications in one particular way: 0x11 (persona) certifications are ignored; other certifications are not. (users can change this cutoff with the --min-cert-level option, but it's not clear why they would want to do so). So there is no functional gain in declaring the difference between a "normal" certification and a "positive" one, even if there were a well-defined standard by which to assess the difference between the "generic" and "casual" or "positive" levels; and if you're going to make a "persona" certification, you might as well not make one at all. And it gets worse: the problem is not just that such an indication is functionally useless; encouraging people to make these kind of assertions actively encourages leaks of a more-detailed social graph than just encouraging everyone to use the default blanket 0x13-for-self-sigs, 0x10-for-everyone-else policy. A richer public social graph means more data that can feed the ravenous and growing appetite of the advertising-and-surveillance regimes. i find these regimes troubling. I admit that people often leak much more information than this indication of "how well do you know X" via tools like Facebook, but that's no excuse to encourage them to leak still more or to acclimatize people to the idea that the details of their personal relationships should by default be public knowledge. Lastly, the more we keep the OpenPGP network of identity certifications (a.k.a. the "web of trust") simple, the easier it is to make sensible and comprehensible and predictable inferences from the network about whether a key really does belong to a given user. Minimizing the complexity and difficulty of deciding to make a certification helps people streamline their signing processes and reduces the amount of cognitive overhead people spend just building the network in the first place.Tags: openpgp

You may not know this, but I am a huge PowerDNS fan. This may be because it is so simple to use, supports different databases as backends or maybe just because I do not like BIND, pick one. I also happen to live in Germany where ISPs usually do not give static IP-addresses to private customers. Unless you pay extra or limit yourself to a bunch of providers that do good service but rely on old (DSL) technology, limiting you to some 16MBit/s down and 1MBit/s up. Luckily my ISP does not force the IP-address change, but it does happen from time to time (once in a couple of month usually). To access the machine(s) at home while on a non-IPv6-capable connection, I have been using my old (old, old, old) DynDNS.com account and pointing a CNAME from under die-welt.net to it. Some time ago, DynDNS.com started supporting AAAA records in their zones and I was happy: no need to type hostname.ipv6.kerker.die-welt.net to connect via v6 just let the application decide. Well, yes, almost. It s just DynDNS.com resets the AAAA record when you update the A record with ddclient and there is currently no IPv6 support in any of the DynDNS.com clients for Linux. So I end up with no AAAA record and am not as happy as I should be. Last Friday I got a mail from DynDNS:

Starting now, if you would like to maintain your free Dyn account, you must now log into your account once a month. Failure to do so will result in expiration and loss of your hostname. Note that using an update client will no longer suffice for this monthly login. You will still continue to get email alerts every 30 days if your email address is current.
Yes, thank you very much

Given that I have enough nameservers under my control and love hacking, I started writing an own dynamic DNS service. Actually you cannot call it a service. Or dynamic. But it s my own, and it does DNS: powerdyn. It is actually just a script, that can update DNS records in SQL (from which PowerDNS serves the zones). When you design such a service , you first think about user authentication and proper information transport. The machine that runs my PowerDNS database is reachable via SSH, so let s use SSH for that. You do not only get user authentication, server authentication and properly crypted data transport, you also do not have to try hard to find out the IP-address you want to update the hostname to, just use $SSH_CLIENT from your environment. If you expected further explanation what has to be done next: sorry, we re done. We have the user (or hostname) by looking at the SSH credentials, and we have the IP-address to update it to if the data in the database is outdated. The only thing missing is some execution daemon or cron(8). :) The machine at home has the following cron entry now:

*/5 * * * * ssh -4 -T -i /home/evgeni/.ssh/powerdyn_rsa powerdyn@ssh.die-welt.net

This connects to the machine with the database via v4 (my IPv6 address does not change) and that s all.
As an alternative, one can add the ssh call in /etc/network/if-up.d/, /etc/ppp/ip-up.d/ or /etc/ppp/ipv6-up.d (depending on your setup) to be executed every time the connection goes up. The machine with the database has the following authorized_keys entry for the powerdyn user:

no-agent-forwarding,no-port-forwarding,no-pty,no-X11-forwarding,no-user-rc,\ 
command="/home/powerdyn/powerdyn/powerdyn dorei.kerker.die-welt.net" ssh-rsa AAAA... evgeni@dorei

By forcing the command, the user has no way to get the database-credentials the script uses to write to the database and neither cannot update a different host. That seems secure enough for me. It won t scale for a setup as DynDNS.com and the user-management sucks (you even have to create the entries in the database first, the script can only update them), but it works fine for me and I bet it would for others too :) Update: included suggestions by XX and Helmut from the comments.

3 comment(s) this blog is flattr enabled

I use RSS feeds to keep up with academic journals. Because of an undocumented and unexpected feature (bug?) in my (otherwise wonderful) free software newsreader NewsBlur, many articles published over the last year were marked as having been read before I saw them. Over the last week, I caught up. I spent hours going through abstracts and downloading papers that looked interesting or relevant to my research. Because I did this for hundreds of articles, it gave me an unusual opportunity to reflect on my journal reading practices in a systematic way. On a number of occasions, there were potentially interesting articles in non-open access journals that neither MIT nor Harvard subscribes to and that were otherwise not accessible to me. In several cases where the research was obviously important to my work, I made an interlibrary request, emailed the papers authors for copies, or tracked down a colleague at an institution with access. Of course, articles that look potentially interesting from the title and abstract often end up being less relevant or well executed on closer inspection. I tend to cast a wide net, skim many articles, and put them aside when it s clear that the study is not for me. This week, I downloaded many of these possibly relevant papers to, at least, give a skim. But only if I could download them easily. On three or four occasions, I found inaccessible articles at this margin of relevance. In these cases, I did not bother trying to track down the articles. Of course, what appear to be marginally relevant articles sometimes end up being a great match for my research and I will end up citing and building on the work. I found several suprisingly interesting papers last week. The articles that were locked up have no chance at this. When people suggest that open access hinders the spread of scholarship, a common retort is that the people who need the work have or can finagle access. For the papers we know we need, this might be true. As someone with access to two of the most well endowed libraries in academia who routinely requests otherwise inaccessible articles through several channels, I would have told you, a week ago, that locked-down journals were unlikely to keep me from citing anybody. So it was interesting watching myself do a personal cost calculation in a way that sidelined published scholarship and that open access publishing would have prevented. At the margin of relevance to ones research, open access may make a big difference.

PyBit is a distributed build system able to build packages in response to VCS commits or other triggers, across multiple architectures, multiple clients and multiple build environments with automated uploads to a nominated repository.

Support is included in 1.0.0 for building Debian packages using sbuild in response to subversion commits or changes in debian-devel-changes@lists.debian.org (by using apt as a version control handler) for any architecture and build environment which sbuild can support. There is also an example git commit template. Pybit has been designed to be fully extensible, so support for RPM or other package formats can be added as well as other version control handlers, other build environments and other architectures. Pybit is also scalable, when one type of client is struggling with the workload, another machine of the same architecture can be added to the pool to share the load. Pybit can also build a package for any number of architectures and build environments at the same time. The Pybit web interface provides an at-a-glance summary of all current builds as well as options to blacklist certain combinations, cancel and retry specific jobs and add monitor each pybit client. Current use cases include:

• Rapidly changing VCS - one or more subversion repositories with lots of Debian packages, built automatically for any number of build environments and architectures every time the debian/changelog is modified. Clean chroot builds provide continuous integration testing of the every package.


• Rebuilding the archive with different compilers or flags - a dedicated email account subscribed to debian-devel-changes@lists.debian.org feeding messages through procmail to the changes-debian hook, passing build requests to the apt handler to rebuild each package in your own sbuild chroots, using whatever environments, suites and build options can be configured within those chroots.


• something else we haven't thought of yet ... there is scope for a lot more hooks, package formats, chroot tools and handler plugins.




Pybit 1.0.0 has arrived in Debian unstable as a direct result of the efforts put in by the pybit team during a sprint on 18th May 2013. Thanks to everyone involved in Pybit.

https://freecode.com/projects/pybit

http://nicholasdavidson.github.io/pybit/

https://github.com/nicholasdavidson/pybit

Most UNIX users have heard of the nice utility used to run a command with a lower priority to make sure that it only runs when nothing more important is trying to get a hold of the CPU:

nice long_running_script.sh

That's only dealing with part of the problem though because the CPU is not all there is. A low priority command could still be interfering with other tasks by stealing valuable I/O cycles (e.g. accessing the hard drive).

Prioritizing I/O Another Linux command, ionice, allows users to set the I/O priority to be lower than all other processes. Here's how to make sure that a script doesn't get to do any I/O unless the resource it wants to use is idle:

sudo ionice -c3 hammer_disk.sh

The above only works as root, but the following is a pretty good approximation that works for non-root users as well:

ionice -n7 hammer_disk.sh

You may think that running a command with both nice and ionice would have absolutely no impact on other tasks running on the same machine, but there is one more aspect to consider, at least on machines with limited memory: the disk cache.

Polluting the disk cache If you run a command (for example a program that goes through the entire file system checking various things, you will find that the kernel will start pulling more files into its cache and expunge cache entries used by other processes. This can have a very significant impact on a system as useful portions of memory are swapped out. For example, on my laptop, the nightly debsums, rkhunter and tiger cron jobs essentially clear my disk cache of useful entries and force the system to slowly page everything back into memory as I unlock my screen saver in the morning. Thankfully, there is now a solution for this in Debian: the nocache package. This is what my long-running cron jobs now look like:

nocache ionice -c3 nice long_running.sh

Turning off disk syncs Another relatively unknown tool, which I would certainly not recommend for all cron jobs but is nevertheless related to I/O, is eatmydata. If you wrap it around a command, it will run without bothering to periodically make sure that it flushes any changes to disk. This can speed things up significantly but it should obviously not be used for anything that has important side effects or that cannot be re-run in case of failure. After all, its name is very appropriate. It will eat your data!

If I did everything right, this post will not appear on any RSS feed yet still make it to my blog to maintain history. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1088
  • Affecting Jessie: 214 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: 183 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 43 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 15 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 125 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 31 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.
      • 31 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:

Previously i d talked about how we use GNOME technologies in the Moblin Myzone. Now i m going to talk about another component that i m responsible for, the People Panel. An important aspect of the Moblin user experience is about communicating with others and this panel provides quick access to do this. The core of the content is provided by an abstraction, simplification and aggregation library called Anerley. This provides a feed of items (an addressbook of people) that aggregates across the system addressbook, powered by EDS, and your IM roster, powered by Telepathy. You have small set of actions you can do on these people such as start an IM conversation / email / edit them with Contacts. The core of our IM experience is supplied by the awesome Empathy. We ve been working with the upstream maintainers to accomodate some of the needs of Moblin into the upstream source. This included the improvements to the accounts dialog and wizard that landed for GNOME 2.28. One of the biggest problems with the IM experience in Moblin 2.0 was that it was easy to miss when somebody was talking to you. If you were looking away when the notification popped up, whoops, it s gone. With our switch to Mission Control 5 I was able to integrate a Telepathy Observer into Anerley and the People Panel. An Observer will be informed of channels that are requested on the system. This allows us to show ongoing conversations in the panel and by exploiting channel requests and window presentation allow the user to switch between ongoing conversations. This wouldn t have been possible without the assistance of the nice folks in #telepathy and at Collabora: Sjoerd, Will, Jonny and countless others.

Debian Edu / Skolelinux is an operating system based on Debian intended for use in schools. It contain a turn-key solution for the computer network provided to pupils in the primary schools. It provide both the central server, network boot servers and desktop environments with heaps of educational software. The project was founded almost 12 years ago, 2001-07-02. If you want to support the project, which is in need for cash to fund developer gatherings and other project related activity, please donate some money. A topic that come up again and again on the Debian Edu mailing lists and elsewhere, is the question on how to transform a Debian or Ubuntu installation into a Debian Edu installation. It isn't very hard, and last week I wrote a script to replicate the steps done by the Debian Edu installer. The script, debian-edu-bless in the debian-edu-config package, will go through these six steps and transform an existing Debian Wheezy or Ubuntu (untested) installation into a Debian Edu Workstation:

1. Add skolelinux related APT sources.
2. Create /etc/debian-edu/config with the wanted configuration.
3. Install debian-edu-install to load preseeding values and pull in our configuration.
4. Preseed debconf database with profile setup in /etc/debian-edu/config, and run tasksel to install packages according to the profile specified in the config above, overriding some of the Debian automation machinery.
5. Run debian-edu-cfengine-D installation to configure everything that could not be done using preseeding.
6. Ask for a reboot to enable all the configuration changes.

There are some steps in the Debian Edu installation that can not be replicated like this. Disk partitioning and LVM setup, for example. So this script just assume there is enough disk space to install all the needed packages. The script was created to help a Debian Edu student working on setting up Raspberry Pi as a Debian Edu client, and using it he can take the existing Raspbian installation and transform it into a fully functioning Debian Edu Workstation (or Roaming Workstation, or whatever :). The default setting in the script is to create a KDE Workstation. If a LXDE based Roaming workstation is wanted instead, modify the PROFILE and DESKTOP values at the top to look like this instead:

PROFILE="Roaming-Workstation"
DESKTOP="lxde"

The script could even become useful to set up Debian Edu servers in the cloud, by starting with a virtual Debian installation at some virtual hosting service and setting up all the services on first boot.

I previously wrote a post with some calculations about the power supplied to laptops from a car battery [1]. A comment on the post suggested that I might have made a mistake in testing the Voltage because leaving the door open (and thus the internal lights on) will cause a Voltage drop. So I ve done some more tests:

Test	Voltage
battery terminals	12.69
front power socket with doors closed	12.64
front power socket with doors open OR ignition switch on	12.37
cigarette lighter socket with ignition switch on	12.32
front power socket with doors closed and headlights on	11.96
front power socket with engine running	14.38
front power socket with engine running and headlights on	14.29

In my previous tests I recorded 12.85V inside my car (from the front power socket which although having the same connector as a cigarette lighter isn t designed for lighting cigarettes) and 13.02V from the battery terminals a 0.17V difference. In my tests today I was unable to reproduce that but I think that my biggest mistake was to take the reading too quickly. Today I noticed that it took up to a minute for the Voltage to stabilise after opening a door (the Voltage dips after any current draw and takes time to recover) so a quick reading isn t going to be accurate. My car is a Kia Carnival which has two sockets in the front for power and for actually lighting cigarettes. The one for lighting cigarettes has a slightly lower Voltage and only works when the ignition is turned on. The car also has a power socket in the boot (the trunk for US readers) which delivers the same Voltage as the power socket in the front. Also one thing to note is that today is a reasonably cold day (16.5C outside right now) and my car hasn t been driven since last night so the battery would be quite cold (maybe 12C or less). My previous measurements were taken in summer so the battery would have been a lot warmer and therefore working more effectively. Conclusion The Voltage drop from turning on the internal lights surprised me, I had expected that a car battery which is designed to supply high current wouldn t be affected by such things. Certainly not to give a 2% Voltage drop! The Voltage difference from reading inside the car and at the battery terminals might be partly due to the apparent lead coating on the terminals, I pushed the probes of my multimeter beneath the surface of the metal and got a really good connection. The 14% Voltage increase when the engine was running was also a surprise. It seems to me that if you are running a power hungry device (such as a laptop) it would be a good idea to disconnect it when the engine is turned off. A 14% higher voltage will give a 14% lower current if the PSU is efficient and therefore less problems with heat in the wiring and less risk of blowing a fuse. Also it s a good idea to be more methodical about performing tests than I was before my last post. There are lots of other tests I could run (such as testing after the engine has been running for a while) but at the moment I don t have enough interest in this topic to do more tests. Please leave a comment if there s something interesting that you think I missed.

• [1] http://etbe.coker.com.au/2013/01/24/power-supplies-wires/

Back in 2010 I packaged Google s ipaddr module because I needed a light weight IP address manipulation library that supported both IPv4 and IPv6 and (at the time) python-subnettree was IPv4 only. Well, ipaddr is all grown up now and included in python3.3 as the ipaddress manipulation module in the standard library. You can find details, as well as some description of the differences, in PEP 3144. I just converted one package that I m upstream for to use either ipaddr (for python2.6/2.7/3.2) or ipaddress instead of some custom code. It turned out to be pretty easy to make it work with either. Other than the name, the only difference I ran into was the removal of the common, generic IPAddress and IPNetwork functions that are replaced by ip_address and ip_network.
-import ipaddr
+try:
+ import ipaddress
+except ImportError:
+ import ipaddr as ipaddress

- address = ipaddr.IPAddress(ip)
- if isinstance(address, ipaddr.IPv4Address):
+ try:
+ address = ipaddress.ip_address(ip)
+ except AttributeError:
+ address = ipaddress.IPAddress(ip)
+ if isinstance(address, ipaddress.IPv4Address):
Currently, python3-ipaddr has no reverse-dependencies in the archive (python-ipaddr does). Once python3.2 is dropped from Jessie, I think I ll drop the python3-ipaddr binary on the assumption people newly coding for python3.3 should use ipaddress. The python-ipaddr module will stick around for use with python2.7.

Dear all, DebConf13 sponsorship application date extended As communicated through the debconf-announce@lists.debconf.org mailing list, the deadline to apply for DebConf13 sponsorship has been extended to the end of this week, May 19th. If you intend to attend DebConf13 in August and would like to apply for sponsored registration, now is the time to register in Penta! After this deadline you will no longer be able to apply for sponsored food, accomodation or travel. Please refer to the announcement and to the registration documentation for details. Please contact us on the debconf-discuss mailing list if you have any questions. DebConf12 final report The DebConf team is also happy to announce the release of the DebConf12 Final Report. It s a 39-page document which gives the reader an idea about the conference as a whole. It includes descriptions of talks, DebCamp and Debian Day activities, personal impressions, attendee and budgeting numbers, the work of various teams, social events and so on. If you attended Debconf12, the report may refresh some of your memories and bring you closer to the organization team work. If not, it will certainly encourage you to be part of future Debian events. We thank the Universidad Centroamericana, the Government of Nicaragua, Google and all other DebConf12 sponsors for their support that made the event possible. The DebConf team