Taking over Qcontrol upstream When I took over the qcontrol package in Debian, back in October 2012, I was aware that upstream hadn't been active for quite a while (since late 2009). I figured that would be OK since the software was pretty simple and pretty much feature complete. Nevertheless since I've been maintaining the package I've had a small number of wishlist bugs (many with patches, thanks guys!) which are really upstream issues. While I could carry them as patches in the Debian package they would really be better taken care of by an upstream. With that in mind I mailed the previous upstream (and original author) Byron Bradley back in February to ask if he would mind if I took over as upstream. Unfortunately I haven't yet heard back, given how long upstream has been inactive for this isn't terribly surprising so having waited several months I have decided to just go ahead and take over upstream development. Thanks Byron for all your work on the project, I hope you don't mind me taking over. Since it is unlikely that I will be able to access the old website or Subversion repository I have converted the repository to git and uploaded it to gitorious:

• https://gitorious.org/qcontrol/qcontrol/
• git://gitorious.org/qcontrol/qcontrol.git

I don't expect I'll be doing an awful lot of proactive upstream development but at least now I have a hat I can put on when someone reports an "upstream" issue against qcontrol and somewhere which can accept upstream patches from myself and others. I'm still deciding what to do about a website etc. I may just enable the gitorious wiki or I may setup an ikiwiki software site type setup, which has the advantage of being a little more flexible and providing a neat way of dealing with bug reports without being too much overhead to setup up. In the meantime its been almost 5 years since the last release, so... New Release: qcontrol 0.5.0 This is a rollup of some changes which were made in the old upstream SVN repository but never released and some patches which had been made in the Debian packaging. What's here corresponds to the Debian 0.4.2+svn-r40-3 package. The 0.4.2 release was untagged in SVN, but corresponds to r14, new stuff since then includes:

• Support for more hardware (TS-119, TS-219, TS-41x, all by Martin Michlmayr)
• Support auto power on feature (by Martin Michlmayr)
• Support for the A125 LCD on TS-419P devices (by Bernhard R. Link)
• Support for a daemon mode, including syslog (Byron Bradley)
• Support for disabling the watchdog on TS-219P II and TS-419P II (Helmut Pozimski)
• Various other fixes (Lo c Minier, Martin, Bernhard, Byron)

As well as the change of maintainer I think the addition of the daemon mode warrants the bump to 0.5.0. Get the new release from git or http://www.hellion.org.uk/qcontrol/releases/0.5.0/.

Dear Project Members,

   "Now that I have your attention, I would like to make the following
delegations:"

... nah, scrap that. In my last day in office I first of all owe you a report of DPL activities for the last reporting period of this term, i.e. March 8th until today. Here it is! Highlights

• At LibrePlanet (see below) I've discussed at length with Karen Sandler as GNOME representative the possibility of Debian participation in the FOSS Outreach Program for Women. I've then proposed that we do participate and, as you might have read on d-d-a, we're now doing that. Many thanks to the volunteer co-organizers for Debian participation in the program: M nica Ram rez Arceda, Ana Guerrero L pez, and Patty Langasek.
• A couple of years of work with the auditors has come together. At elgar.debian.org:/srv/accounting.debian.org/ledger/ you can now find Debian monetary transactions for the 2010-2013 period. Note that: 1) They are not all of our transactions, most notably because we haven't yet managed to get access to all our bank transactions at SPI (while we do have access to other transactions there, e.g. donations). Given the relevance of the missing transactions for our budget, this is a blocker for producing meaningful public periodic reports of Debian finances. This is clearly annoying, but I'm confident that our feedback to SPI over the past years has helped them better understand our needs and improve. I hope this could be finally solved during the next DPL term. And, 2) Donor names have been anonymized in the ledger files, in wait of a donation system that allow to express privacy preferences. Complete donation information is available in the companion ledger.git repository, which is accessible to auditors only. I'd like to thank the Debian auditors, and in particular Martin Michlmayr, for their amazing work on this over the past 3 years.
• As you might have noticed, we now have an official Debian Project blog, finally entering the brave new Web 1.5 era I've only helped "politically" here and there with this over the years, and I'm happy to see it live. Your thanks for this should go to the blog editors---Francesca Ciceri and Ana Guerrero Lopez---and to DSA for making it real. A proper delegation for the editors is pending and I'm confident the next DPL will pick it up.

Talks Over the past month or so I've attended and spoken on behalf of Debian in the following occasions:

• "Debian: 20 years and counting" talk at the New York Linux User Group; slides are available. Many thanks to Brian Gupta and Tom Limoncelli for inviting me.
• "Debian and GNU" talk at LibrePlanet 2013; slides are available. Many thanks to John Sullivan and the Free Software Foundation for inviting me to talk at their main conference. My presence there has also been a chance to reassess the status of collaboration with FSF (see John's brief summary) and discuss further technical collaboration with the Trisquel maintainers.
• "Legal issues from a radical community angle" keynote at the yearly workshop of FSFE's European Legal Network; slides are available. The talk has also been covered by a LWN feature article last week (the link should become unembargoed for non-LWN subscribers starting tomorrow).

Assets I've approved the budget for the following forthcoming sprints:

• 6th Debian Groupware Meeting (~500 EUR)
• DSA sprint (~3'000 EUR)

Also, we've bought a 3-year warranty pack for the disk array that powers ftp-master.d.o (~900 USD). On the income side, Brian Gupta has started an interesting matching fund experiment, in order to raise funds for the forthcoming DebConf13. The matching fund will be open until April 30th, so your help in spreading news would be welcome. Many thanks to Brian for the idea and to his company, Brandorr Group, for funding it. DPL helpers Three more DPL helpers IRC meetings have been held; minutes are available at the usual place. Legal Spring Cleaning I've finally cleaned up the pile of pending legal matters (but I'm sure new ones will show up for the delight of the next DPL :-P)

• one is merely internal for trademark@d.o: our procedures for (n)acks on incoming requests has now been vetted by our legal advisors
• the second one is relevant for our mentors.debian.net service: one of the blockers to officialize it as mentors.debian.org have historically been DMCA-related concerns. We now have a DMCA policy for (wannabe) mentors.d.o, which I've shared with the service maintainers and DSA. This specific part should no longer be a concern.
• the last one concerns the possibilities of playing DVDs with Debian. We now have legal guidelines on how to include installer packages that allow to do so; that should allow us to have a decent solution for our users in the Jessie time frame.

Once again, I'd like to thank SFLC for the pro bono and very high quality legal advice they keep on offering to Debian. Miscellaneous

• I've mentioned last month that, as a Debian representative, I've joined a working group by the Italian public administration (PA) that should define procurement rules for software in the PA at large, together with representatives of other well-known FOSS initiatives (e.g. KDE, FSFE). The first meetings have now been held and I've participate in some, for the moment on my own budget. I'll check with the next DPL the feasibility of keep on doing so on in the future.

---

Now, before I get sentimental, let me thank Gergely, Lucas, and Moray for running in the recently concluded DPL election. Only thinking of running and then go through a campaign denote a very high commitment to the Project; we should all be thankful to them. Then I'd like to congratulate Lucas for his election. I've known him for a long time, and I can testify about his clear vision of the role Debian has to play in Free Software and on what Debian needs to improve to do so. Best wishes for the term ahead, Lucas! Finally, I'd like to thank you all for the support you've shown me over the past 3 years. Serving as DPL is a great honor, but also a very demanding job. Thank to you all, and to how cool Debian is, it has been for me an incredibly rewarding experience. I had no idea what I were doing when I embarked on this adventure, but in hindsight I don't regret any of it. See you around, as I don't plan to be anywhere far away from Debian anytime soon. Cheers.

---

PS the day-to-day activity logs for March and April 2013 are available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.20130 3,4

Paul Wise poked me this morning about uploading fatrace ( file access trace , see the original announcement for details) to Debian, thanks for the reminder! So I filed an Intent To Package, and will upload it in a few days, unless some discussion evolves. I also took the opportunity to do some modernization: The power-usage-report script now uses the current PowerTop 2.x instead of the old 1.13, uses Python 3 now, and includes the process device activity in the report. I released this as 0.5. The actual fatrace binary didn t change its behaviour, it just got some code optimizations; thanks to Yann Droneaud for those.

The script apt-show-versions is developed by another Debian Developer called Christoph Martin in Perl. Recently, it turned out that apt-show-versions is too slow for some users; so I decided to rewrite his program using APT s C++ API. I expect this to be part of a future APT release, rendering the original apt-show-versions obsolete. The rewrite is sadly not 100% backwards compatible to the original version; as some option names had to be renamed due to our command-line parser not supporting option names like -nh, and some other options were dropped because they are hard to support (like status-file and lists-dir) with our command-line parsing. I also decided not to keep the the -p and -r options, but use the standard APT command-line conventions insteads. For now, it also cannot show you the distribution names you have specified in your sources.list file, but will always display codenames instead; if available. I hope to fix this in Jessie by extending APT s cache format a bit. On the performance side, this program now takes about 0.09s compared to the 1.40 seconds needed by apt-show-versions. The times are taken with all data in caches. The current version can be found in a git repository, a link to gitweb is: http://anonscm.debian.org/gitweb/?p=users/jak/apt-show-versions.git
Please also note that support for allversions is not 100% implemented yet, but it should work for most uses. Now, go testing and report back!
Filed under: Debian

PostgreSQL just released security updates. 9.1 (as found in Debian testing and unstable and Ubuntu 11.10 and later) is affected by a critical remote vulnerability which potentially allows anyone who can access the TCP port (without credentials) to corrupt local files. If your PostgreSQL database exposes the TCP port to any potentially untrusted location, please shut down your servers and update now! PostgreSQL 8.4 for Debian stable (squeeze) and Ubuntu 8.04 LTS and 10.04 LTS also got an update, but these are much less urgent. Debian and Ubuntu advisories for all stable releases, as well as Debian testing are going out as we speak. The updates are already on security.debian.org and security.ubuntu.com. I also uploaded updates for Debian unstable (8.4, 9.1, and 9.2 in experimental) and the Ubuntu backports PPA, but it will take a bit for these to build as we don t have embargoed staging builds for those. Christoph updated the apt.postgresql.org repository as well. Warning: If you use the current Ubuntu raring Beta-2 candidate images, you will still have the old version. So if you do anything serious with those installations, please make sure to upgrade immediately. Update: Debian and Ubuntu security announcements have been sent out, and all packages in the backports PPA are built. Please see the official FAQ if you want to know some more details about the nature of the vulnerabilities.

So. following up on my previous post about implementing a libravatar server, this will be an announcement of a quick Qt5 based client library for libravatar so that everyone can put avatars everywhere! Get it while it is hot on
git.kde.org There isn t much screenshots to show off, given it is effectively just converting a string with an email into a URL for a image. And thanks to Martin Sandsmark for coming up with such a great name. Now I expect him to show off what it can be used for. Another thanks goes to Andreas Hartmetz for going thru the code & api.

I just pushed out a new python-dbusmock release 0.6. Calling a method on the mock now emits a MethodCalled signal on the org.freedesktop.DBus.Mock interface. In some cases this is easier to track than parsing the mock s log or using GetMethodCalls. Thanks to Lars Uebernickel for this. DBusMockObject.AddTemplate() and DBusTestCase.spawn_server_template() can now load local templates from your own project by specifying a path to a *.py file as template name. Thanks to Lucas De Marchi for this feature. I also wrote a quite comprehensive template for systemd s logind. It stubs out the power management functionality as well as user/seat/session objects, and is convincing enough for loginctl. Some bits like AttachDevice is missing, as this sounds unlikely to be required for D-BUS mock tests, but please let me know if you need anything else. The mock processes now terminate automatically if their connected D-BUS goes down, as advertised in the documentation. You can get the new tarball from Launchpad, and I uploaded it to Debian experimental now. Enjoy!

Given how Debian and Ubuntu nowadays enable IPv6 support by default, the routing table includes some IPv6 entries by standard. However, this has the unpleasant side-effect that lib C tries to connect to public IPv6 addresses, even in a case when the only IPv6 entries are for loopback and local link. Apparently, libc incorrectly assumes that the mere presence of any IPv6 means that there is a usable default IPv6 route. This results in, among other things, APT failing at fetching packages from the Debian repository if the DNS rotation returned the IPv6 address for the server first. I was thus wondering whether libc6 could be made to reject public IPv6 addresses, in cases when the host has no IPv6 gateway in its routing table? Or would there be a smarter way to prevent applications from failing at contacting IPv6 addresses whenever there is no IPv6 connection to the outside world?

Last week I had another birthday, which was nice. I'm now all mature, and everything. Honest. I received a few surprise gifts from friends and strangers alike, which was pretty good. Other than that I didn't do too much. This weekend I'm going to be using "airbnb" to spend the weekend in Dundee with my partner who is regularly commuting between Edinburgh and Perth/Dundee, to work in various hospitals. With all the commuting time she's not had too much time to explore the actual city, and I've only been there once before so I'm sure it will be a fun weekend. The templer static site generator got a little bit of pimping on LWN.net the other day, thanks to Martin Michlmayr, although embarassingly I seem to have read the article and repeated the content in the conclusion, and duplicated that in my own comment. Ooops. Beyond that I've done little coding recently, although I suspect now that nodejs has had a stable release I might do something interesting soon. I don't want to dwell on the failure of Sim City - because I don't run windows and couldn't have tried it even if I wanted to - but I'm pondering the idea of a persistant grid-space where different items can be placed. I've not tried anything browser-based before, but the popularity of things like minecraft make me wonder if you had an "infinite grid" where folk could store "stuff", and scroll around in a browser you might be able to do interesting things. Starting small, with a 100x100 grid, and some kind of updated play-by-mail turfwars/drug-war like experience should be simple. But then again enthusiasm is easy to generate until you start working out how you'd interface with the server and what kind of client you'd need. Now to enjoy some 21 year old whisky and call it a night..

Many libraries build a GObject introspection repository (*.gir) these days which allows the library to be used from many scripting (Python, JavaScript, Perl, etc.) and other (e. g. Vala) languages without the need for manually writing bindings for each of those. One issue that I hear surprisingly often is there is zero documentation for those bindings . Tools for building documentation out of a .gir have existed for a long time already, just far too many people seem to not know about them. For example, to build Yelp XML documentation out of the libnotify bindings for Python:

  $ g-ir-doc-tool --language=Python -o /tmp/notify-doc /usr/share/gir-1.0/Notify-0.7.gir

Then you can call yelp /tmp/notify-doc to browse the documentation. You can of course also use the standard Mallard tools to convert them to HTML for sticking them on a website:

  $ cd /tmp/notify-doc
  $ yelp-build html .

Admittedly they are far from pretty, and there are still lots of refinements that should be done for the documentation itself (like adding language specific examples) and also for the generated result (prettification, dynamic search, and what not), but it s certainly far from nothign , and a good start. If you are interested in working on this, please show up in #introspection or discuss it on bugzilla, desktop-devel-list@, or the library specific lists/bug trackers.

Replying to an old blog post of Martin F. Krafft: Configuration management, I want to give my point of view. The problems listed by madduck are quite common with Puppet, but I think Puppet is still worth, mostly because you can solve all these problems. Let give you my opinion on the list:

• Non-Unix approach to everything (own transport, self-made PKI, non-intuitive configuration language, a faint attempt at versioning (bitbucket), and much much more )

True. I think the approach of puppet is not really UNIXish. It is probably on purpose. The biggest issue is probably the PKI. It breaks frequently for unknown reason. The "non intuitive configuration language" is probably a matter of taste. I think the language is not very well designed and strange, but I can cope with that. The attempt to versioning -- if I understand correcly what it means -- refers to the fact that when Puppet replace a file it moves the old file to a bucket. This is not a good thing, but you can say "backup => '.puppet-bak'" and you get almost the same behavior as ".dpkg-old".

• Ruby

False debate. We can discuss for hours on Ruby, PHP, Java or whatever pet language people has invented. I am not a fan of Ruby but it is still nice as a general purpose language. To my mind, Ruby is still better to write daemon than bash.

• Abysmal slowness

False debate.

   info: Caching catalog for centi.....
   info: Applying configuration version '1350597216'
   notice: Finished catalog run in 3.08 seconds

The config of this node is not complex, but 3s is not that bad for something that runs every 30min. If you need sub-second speed for this kind of thing, maybe you are not looking for this kind of tool. Does 144s of server time per day is a big deal ? With a lot more complex setup, I can reach 30s for a run, although this is the point where I manage a lot of thing with it.

• Lack of basic functionality (e.g. replace a line of text)

False and True. Augeas allows you to replace a single value (even more precise than a line). Just have a look at the augeas type. This is pretty nice and allow to do thing like replacing "Defaults env_reset" by "Defaults env_reset, !tty_tickets" in 4 lines of code. So this i not precisely "a single line of text", but there is other way to do it.

• Host management and configuration programming intertwined, lack of a high-level approach to defining functionality

False. Well if you organize your code with manifests/site.pp and manifests/classes/*.pp, it seems like there is a separation between the two. Next you can try inheritance and define to create specific high-level features.

• Horrific error messages

False-ish. Hey at least there are error message ;-) Now, most of the error that are related to the programming language are useless (at least as cryptic as a C++ error message). But as usual with error message in programming language

• Catastrophic upgrade paths

True. Multi versions installation is horrible and you have to fix a lot of stuff to manage a sane overall configuration.

• Lack of IPv6 support

Not sure to understand this point, I use puppet over IPv6... To whoever is considering using puppet, this is worth a try. It is a nice system that really helps to maintain a decent configuration across nodes.

I just released umockdev 0.2. The big new feature of this release is support for evdev ioctls. I. e. you can now record what e. g. X.org is doing to touchpads, touch screens, etc.:

  $ umockdev-record /dev/input/event15 > /tmp/touchpad.umockdev
  # umockdev-record -i /tmp/touchpad.ioctl /dev/input/event15 -- Xorg -logfile /dev/null

and load that back into a testbed with X.org using the dummy driver:

  cat <<EOF > xorg-dummy.conf
  Section "Device"
        Identifier "test"
        Driver "dummy"
  EndSection
  EOF
  $ umockdev-run -l /tmp/touchpad.umockdev -i /dev/input/event15=/tmp/touchpad.ioctl -- \
       Xorg -config xorg-dummy.conf -logfile /tmp/X.log :5

Then e. g. DISPLAY=:5 xinput will recognize the simulated device. Note that Xvfb won t work as that does not use udev for device discovery, but only adds the XTest virtual devices and nothing else, so you need to use the real X.org with the dummy driver to run this as a normal user. This enables easier debugging of new kinds of input devices, as well as writing tests for handling multiple touchscreens/monitors, integration tests of Wacom devices, and so on. This release now also works with older automakes and Vala 0.16, so that you can use this from Ubuntu 12.04 LTS. The daily PPA now also has packages for that. Attention: This version does not work any more with recorded ioctl files from version 0.1. More detailled list of changes:

• umockdev-run: Fix running of child program to keep stdin.
• preload: Fix resolution of /dev and /sys
• ioctl_tree: Fix endless loop when the first encountered ioctl was unknown
• preload: Support opening a /dev node multiple times for ioctl emulation (issue #3)
• Fix parallel build (issue #2)
• Support xz compressed ioctl files in umockdev_testbed_load_ioctl().
• Add example umockdev and ioctl files for a gphoto camera and an MTP capable mobile phone.
• Fix building with automake 1.11.3 and Vala 0.16.
• Generalize ioctl recording and emulation for ioctls with simple structs, i. e. no pointer fields. This makes it much easier to add more ioctls in the future.
• Store return values of ioctls in records, as they are not always 0 (like EVIOCGBIT)
• Add support for ioctl ranges (like EVIOCGABS) and ioctls with variable length (like EVIOCGBIT).
• Add all reading evdev ioctls, for recording and mocking input devices like touch pads, touch screens, or keyboards. (issue #1)

* Inspired by DPL Game post. Not in order,
1. Christian Perrier
2. Martin Zobel-Helas
3. Russ Allbery
4. Cyril Brulebois Pick anyone. All four are capable leaders! Although, I only met Christian personally from list, I ve watched others doing great work in Debian since long time.

In his latest bits from the DPL, Stefano wrote:

I'd like to respond (also) here to inquiries I'm receiving these days: I will not run again as DPL. So you have about 20 days to mob\^Wconvince other DDs to run, or decide to run yourself. Do not to wait for the vary last minute, as that makes for lousy campaigns.

Ladies and gentlemen, I am pleased to present you... THE DPL GAME GOALS:
The goal of the game is to let people know you think they'd be nice DPLs.
The point is not to pressure them, but to let them know they're awesome and make them at least consider the idea to run for DPL. The winners are those who have at least one of their Fantastic Four running for DPL. Bonus points if one of them ends being the next DPL. RULES:
Name three persons (plus a reserve, just in case) you'd like to see as candidates for DPL. Publicly list them (on your blog or on identi.ca using the hashtag #DPLgame) or at least let them know that you'd like to have them as candidate for DPL (via private mail).
You may want to add a couple of lines explaining the rationale for your choices. AGE:
0-99 NUMBER OF PLAYERS:
The more the merrier Some suggestions on how to play:
First think of the qualities a DPL needs to do, in your opinion, a good job. Then look around you: the people you work with, the people you see interact on mailing list, etc. There must be someone with those qualities.

---

Here are my Fantastic Four (in rigorous alphabetic order):

• Russ Allbery
• Gregor Herrmann
• Christian Perrier
• Martin Zobel-Helas

In my opinion, they all more or less have: enthusiasm, a general understanding of dynamics inside the project and of various technical sides of the project itself, ability to delegate and coordinate with different people (inside and outside the project), good communication skills and some diplomacy and ability in de-escalating conflicts. These are people I worked with or I observed working and discussing on mailing lists, and I think they'd do a good job. But -hey!- we are almost a thousand of developers and you cannot possibly know everyone or observe all the people who work in the various teams. This is why you should pick your four names!

What is this? umockdev is a set of tools and a library to mock hardware devices for programs that handle Linux hardware devices. It also provides tools to record the properties and behaviour of particular devices, and to run a program or test suite under a test bed with the previously recorded devices loaded. This allows developers of software like gphoto or libmtp to receive these records in bug reports and recreate the problem on their system without having access to the affected hardware, as well as writing regression tests for those that do not need any particular privileges and thus are capable of running in standard make check. After working on it for several weeks and lots of rumbling on G+, it s now useful and documented enough for the first release 0.1! Component overview umockdev consists of the following parts:

• The umockdev-record program generates text dumps (conventionally called *.umockdev) of some specified, or all of the system s devices and their sysfs attributes and udev properties. It can also record ioctls that a particular program sends and receives to/from a device, and store them into a text file (conventionally called *.ioctl).
• The libumockdev library provides the UMockdevTestbed GObject class which builds sysfs and /dev testbeds, provides API to generate devices, attributes, properties, and uevents on the fly, and can load *.umockdev and *.ioctl records into them. It provides VAPI and GI bindings, so you can use it from C, Vala, and any programming language that supports introspection. This is the API that you should use for writing regression tests. You can find the API documentation in docs/reference in the source directory.
• The libumockdev-preload library intercepts access to /sys, /dev/, the kernel s netlink socket (for uevents) and ioctl() and re-routes them into the sandbox built by libumockdev. You don t interface with this library directly, instead you need to run your test suite or other program that uses libumockdev through the umockdev-wrapper program.
• The umockdev-run program builds a sandbox using libumockdev, can load *.umockdev and *.ioctl files into it, and run a program in that sandbox. I. e. it is a CLI interface to libumockdev, which is useful in the debug a failure with a particular device use case if you get the text dumps from a bug report. This automatically takes care of using the preload library, i. e. you don t need umockdev-wrapper with this. You cannot use this program if you need to simulate uevents or change attributes/properties on the fly; for those you need to use libumockdev directly.

Example: Record and replay PtP/MTP USB devices So how do you use umockdev? For the debug a problem use case you usually don t want to write a program that uses libumockdev, but just use the command line tools. Let s capture some runs from libmtp tools, and replay them in a mock environment:

• Connect your digital camera, mobile phone, or other device which supports PtP or MTP, and locate it in lsusb. For example

    Bus 001 Device 012: ID 0fce:0166 Sony Ericsson Xperia Mini Pro

• Dump the sysfs device and udev properties:

    $ umockdev-record /dev/bus/usb/001/012 > mobile.umockdev

• Now record the dynamic behaviour (i. e. usbfs ioctls) of various operations. You can store multiple different operations in the same file, which will share the common communication between them. For example:

    $ umockdev-record --ioctl mobile.ioctl /dev/bus/usb/001/012 mtp-detect
    $ umockdev-record --ioctl mobile.ioctl /dev/bus/usb/001/012 mtp-emptyfolders

• Now you can disconnect your device, and run the same operations in a mocked testbed. Please note that /dev/bus/usb/001/012 merely echoes what is in mobile.umockdev and it is independent of what is actually in the real /dev directory. You can rename that device in the generated *.umockdev files and on the command line.

    $ umockdev-run --load mobile.umockdev --ioctl /dev/bus/usb/001/012=mobile.ioctl mtp-detect
    $ umockdev-run --load mobile.umockdev --ioctl /dev/bus/usb/001/012=mobile.ioctl mtp-emptyfolders

Example: using the library to fake a battery If you want to write regression tests, it s usually more flexible to use the library instead of calling everything through umockdev-run. As a simple example, let s pretend we want to write tests for upower. Batteries, and power supplies in general, are simple devices in the sense that userspace programs such as upower only communicate with them through sysfs and uevents. No /dev nor ioctls are necessary. docs/examples/ has two example programs how to use libumockdev to create a fake battery device, change it to low charge, sending an uevent, and running upower on a local test system D-BUS in the testbed, with watching what happens with upower --monitor-detail. battery.c shows how to do that with plain GObject in C, battery.py is the equivalent program in Python that uses the GI binding. You can just run the latter like this:

  umockdev-wrapper python3 docs/examples/battery.py

and you will see that upowerd (which runs on a temporary local system D-BUS in the test bed) will report a single battery with 75% charge, which gets down to 2.5% a second later. The gist of it is that you create a test bed with

  UMockdevTestbed *testbed = umockdev_testbed_new ();

and add a device with certain sysfs attributes and udev properties with

    gchar *sys_bat = umockdev_testbed_add_device (
            testbed, "power_supply", "fakeBAT0", NULL,
            /* attributes */
            "type", "Battery",
            "present", "1",
            "status", "Discharging",
            "energy_full", "60000000",
            "energy_full_design", "80000000",
            "energy_now", "48000000",
            "voltage_now", "12000000",
            NULL,
            /* properties */
            "POWER_SUPPLY_ONLINE", "1",
            NULL);

You can then e. g. change an attribute and synthesize a change uevent with

  umockdev_testbed_set_attribute (testbed, sys_bat, "energy_now", "1500000");
  umockdev_testbed_uevent (testbed, sys_bat, "change");

With Python or other introspected languages, or in Vala it works the same way, except that it looks a bit leaner due to proper object semantics. Packages I have a packaging branch for Ubuntu and a recipe to do daily builds with the latest upstream code into my daily builds PPA (for 12.10 and raring). I will soon upload it to Raring proper, too. What s next? The current set of features should already get you quite far for a range of devices. I d love to get feedback from you if you use this for anything useful, in particular how to improve the API, the command line tools, or the text dump format. I m not really happy with the split between umockdev (sys/dev) and ioctl files and the relatively complicated CLI syntax of umockdev-record, so any suggestion is welcome. One use case that I have for myself is to extend the coverage of ioctls for input devices such as touch screens and wacom tablets, so that we can write some tests for gnome-settings-daemon plugins. I also want to find a way to pass ioctls back to the test suite/calling program instead of having to handle them all in the preload library, which would make it a lot more flexible. However, due to the nature of the ioctl ABI this is not easy. Where to go to The code is hosted on github in the umockdev project; this started out as a systemd branch to add this functionality to libudev, but after a discussion with Kay we decided to keep it separate. But I kept it in git anyway, given how popular it is today. For the bzr lovers, Launchpad has an import at lp:umockdev. Release tarballs will be on Launchpad as well. Please file bugs and enhancement requests in the git hub tracker. Finally, if you have questions or want to discuss something, you can always find me on IRC (pitti on Freenode or GNOME). Thanks for your attention and happy testing!

The first time I met my Debian team mates (from the Publicity and WWW teams) was during DebConf11 in Banja Luka, in 2011. I was very excited, and being the craft geek I am, I decided to bring them little handmade gifts. After some thought, I opted for a Debian swirl plush charm/keychain. And here is how I made it, in six easy steps. It's a really simple project, you just need a bit of patience for the sewing part: the swirl is sewn by hand and it's very important to make regular stitches. The finished swirl measures approximately 7.5x12 cm. What you'll need

• red felt: a square of at least 15x24 cm
• poly-fil stuffing (or other filling)
• ~ 4 cm of ribbon
• a keychain ring
• red thread
• pins and needle
• fabric shears
• pen (or chalk pencil)

Step 1 Make a sketch of your swirl on paper or, if you don't feel too confident about your drawing skills, print this pattern I made. Trace it on the felt and cut it on felt twice (you'll need two swirl-shaped pieces for the plushie). You can also fold the felt double and cut just one time (as I did). Step 2 Pin the two swirl-shaped pieces together, with the wrong sides inside. With the red thread, using back stitch, sew them together, starting from the lower end as indicated in the image above. Step 3 When you reach the point marked in the image above, start stuffing the filling into the curved part of the swirl (use a pen to stuff it more easily in the narrow part of the curve). Step 4 Continue stuffing the swirl and sewing it until you reach the point marked in the picture above. Step 5 Now it's time to add the ribbon and the ring: cut 4 cm of ribbon and fold it lenghtwise. Slide on it the ring and fold it again, then put the two ends between the folds of the swirl, as shown in the picture above. Step 6 Continue sewing til the end. Congratulations, you now have a Debian plushie. I really loved creating these, and I'm really happy to know that the swirls I made are now scattered around the world: one in Austria, one in Australia, one in Denmark, four in Germany, three in Italy and one in Martinique. And the one I made for this tutorial will end in Italy as well (Mark, it's yours). If you have any doubts about the pattern, you can contact me. And if you make one, please send me a pic. This pattern is released under CC-BY-SA 3.0 license: this means that you can share, distribute, modify and even use it commercially but you'll need to mention the original author (OH HAI! it's me!) and maintain the same license.

It was interesting to read recently from Martin F. Krafft a botnet-like configuration management proposal. Professionally I've used CFEngine, which in version 2.x, supported a bare minimum of primitives, along with a distribution systme to control access to a central server. Using thse minimal primitives you could do almost anything:

• Copy files, and restart services that depend upon them.
• Make minor edits to files. (Appending lines not present, replacing lines you no longer wanted, etc)
• Installing / Removing packages.
• More ..

Now I have my mini cluster (and even before that when I had 3-5 machines) it was time to look around for something for myself. I didn't like the overhead of puppet, and many of the other systems. Similarly I didn't want to mess around with weird configuration systems. From CFEngine I'd learned that using only a few simple primitives would be sufficient to manage many machines provided you could wrap them in a real language - for control flow, loops, conditionals, etc. What more natural choice was there than perl, the sysadmin army-knife? To that end slaughter was born:

• Download polices (i.e. rules) to apply from a central machine using nothing more complex than HTTP.
• Entirely client-driven, and scheduled via cron.

Over time it evolved so that HTTP wasn't the only transport. Now you can fetch your policies, and the files you might serve, via git, hg, rsync, http, and more. Today I've added one final addition, and now it is possible to distribute "modules" alongside policies and files. Modules are nothing more than perl modules, so they can be as portable as you are careful. I envisage writing a couple of sample modules; for example one allowing you to list available sites in Apache, disable the live ones, enable/disable mod_rewrite, etc. These modules will be decoupled from the policies, and will thus be shareable. Anyway , I'm always curious to learn about configuration management systems but I think that even though I've reinvented the wheel I've done so usefully. The DSL that other systems use can be fiddly and annoying - using a real language at the core of the system seems like a good win. There are systems layered upon SSH, such as fabric, ansible, etc, and that was almost a route I went down - but ultimately I prefer the notion of client-pull to server-push, although it is possible in the future we'll launche a mini-daemon to allow a central host/hosts to initial a run.

Following my last rant about configuration management, I've had a closer look at Salt, both for my personal use, as well as for a client who would like to deploy something that is not Puppet. Salt has some very good ideas, for instance:

• Configuration is just data in YAML format, which makes it really easy to whack up stuff and also to generate it using other means;
• There's a lot of plugability: runners, renderers, states, modules, returners, outputters, all of which can be replaced with custom implementations;
• It builds on remote execution. In fact, in the docs, they talk first about remote execution and then about configuration management. Not only does this makes a lot of sense, it also gives the admin the additional benefit of having quick, remote access to all hosts in the infrastructure. I like that as it means I don't also have to deploy a parallel-execution solution.
• Salt supports both, a push and a pull model for configuration management. In fact, the push model is part of its remote execution base and it's implemented through persistent connections from the clients to the master. This neatly solves all problems relating to firewalling and NAT, and it also means that the master always has a pretty good understanding of who's around. It feels good to me. And there is no NIH going on with respect to pulling: there is no daemon, you have to use cron. Good.

But there are also a couple of downsides to Salt:

• The default templating engine is Jinja. While that may be an excellent choice for applications in inherently insecure environments, such as the Web, they are quite painful in the context of Salt: no multi-line logic, whitespace control is a nightmare, and a completely unfamiliar set of conditionals and filters, rather than access to e.g. Python. This is only the default, and mako is an alternative, but it seems like a poor choice and that does not instill confidence.
• I don't think that the method of targeting hosts that Salt uses is scalable. I don't want to intersperse my configuration with if-then-else statements referencing hostnames (what would that mean if a hostname changed or a new host was added?). Instead, I want the configuration to be fully parametrised and assemble the parameters from a node database, ideally a hierarchical one. I have a solution for that which works with Salt, called reclass.
• I don't think much of "pillars", which are Salt way to provide random data (parameters) to nodes, again because data needs to be targeted at hosts, rather than defined for a host. This is also solved with reclass.
• Logging and error reporting in Salt are abysmal, inconsistent, and useless. This is offset a little bit by the ability to use pdb, but it's not ideal.
• Exceptions are not properly handled, the file descriptors aren't closed when daemonising, children are not reaped as they should, and the exit code will almost always be zero, even on failure.
• State requirements are not enforced where they are required, but only come into play when a higher order function is called.
• The code reinvents module loading and does that in very complex ways, while putting tight limitations on what's possible. State functions and modules cannot be namespaced, for instance, nor can they easily make use of each other. There is also no way to quickly define macros without resorting to the templating language (and thus a completely different syntax and paradigm), and the concept of having modular, self-contained states (e.g. one for sudo, one for SSH, etc.) with all their dependencies in one hierarchy is not really part of the design. Also, it's not trivial for a state definition to export an interface for other states to use.
• While we're on the topic of code and design, there's a lot of duplicate stuff in need of refactoring (e.g. saltutil._sync, and it seems that this even causes a lot of crypto work to be done over and over again. It also doesn't help that salt-call, which is used to execute commands on the clients (e.g. pull configuration), works completely independently of the daemon process running on each client (although the same code base is being used).
• And why aren't state and execution modules implemented as classes? Instead, the module is itself treated as an entity, and a home-cooked "virtual" system is used to determine which platforms support which modules. Object-oriented programming principles gives you all of that, and more.
• Fortunately, the Salt authors didn't cave in and write the entire communication layer themselves. Instead, they employed ZeroMQ, but it's still quite common for a client to become unreachable (permanently), e.g. due to an IP address change, or networking problems. What's worse is that the master does not keep track of who's listening.
• While we're on the subject of standing on the shoulders of giants, Python's msgpack apparently cannot handle Unicode. Yay.

Those are the big issues. There are many small issues two, but those won't be around for too long as the project is moving along quickly and the community is vibrant. This is surely an important point that speaks for Salt. However, the above issues seem to hint at design choices that might well turn out to stand in the way later. Following a day of frustration, I now feel the overpowering urge to write my own configuration management system, because of course I feel that I could do it better than everyone else. Does this sound familiar to you? Let's just say hypothetically that I would, then I'd want to reuse as much existing functionality as possible. For instance, I'd want the entire remote execution framework to be independent from any configuration management implemented on top. So what does this mean? What would such a remote execution framework need? Here are some thoughts:

• I'd want to keep it the way of Salt, i.e. the clients maintain persistent connections to the master, and the master regularly pings the clients, for housekeeping. And the clients know to expect such pings at regular intervals, so can reset themselves in case they don't hear from the master. Or scream.
• Of course, authentication and encryption need to be part of this. Ideally, key and roster management are already available in the tool that's being reused. I don't want to have to have a new PKI for this
• The protocol would probably be something like XMLRPC, with an extensible list of modules on the client to do the work. Data would be standardised to JSON-format.
• Asynchronous execution would be a plus. I am even tempted to say that it should be all built asynchronously, even though I don't really know a use case for this.
• The clients should be able to feed back information to the master, where data can be accumulated, allowing for cross-node configuration (cf. http://comments.gmane.org/gmane.comp.sysutils.salt.user/2098). This could be implemented using master-side polls to keep the protocol easier.

Doesn't this sound like a Unix botnet to you? ;) I could imagine whacking this up with a bit of Python, some shell glue, socat and SSH: the server would have an authorized_keys file with forced commands connecting the client to the server process via sockets. Or I could imagine using twisted for that. But I would prefer if something like this already existed. Anyone? Comments are broken on my blog, and I cannot be bothered to work on them. If you have any input, please write to me. I will (eventually) condense all feedback into a new article. NP: Mouse on Mars: Parastrophics

Today in the USA is Martin Luther King, Jr., day. But sometimes these holidays get confusing for a 6-year-old. I asked Jacob the other day if he knew what holiday was coming up. He thought about it for a second, then declared it would be St. Patrick s Day. He was excited because St. Patrick s Day is green. When he realized that it was really MLK Day, he was disappointed. That day isn t green. So I said, Jacob, how about we celebrate pretend St. Patrick s Day on Monday? His face lit up, he got a huge smile, and said, Oh yes! Great idea, dad! Oliver got all excited about it too. I was already planning on us doing some cooking, and thankfully had green food coloring already. So I sort of discarded my plans so each meal could have something green in it. When the boys woke up this morning, I wished each of them Happy Pretend St. Patrick s Day! We all wore green. Jacob put his shirt on backwards so the side with more green would be facing front. For breakfast, our green dish was green crepes with a succotash (based on baby lima beans and corn) filling. The boys were excited to discover that the crepes could be green on one side, and green and a little brown on the other. Jacob was unsure of the succotash idea, but after having a few bites, declared it excellent . After breakfast, we made bread. They loved watching the green food coloring disperse in the water. We checked on how green the dough looked periodically. We watched how it was rising and whether it was staying green. And we checked in on it backing, as the crust turned from green to brown. We discussed green bread over and over. Important questions were asked and answers were attempted. And then, of course, the moment of truth removing the loaf from the pan. The boys jabbered excitedly that there was some green peeking out. While we waited for it to cool, we went out to the creek. The creek is dry this year, so we got to walk in it. Jacob used his stick to make a line behind him. I asked him, Is that a line so we can find our way back? Oh! Uhm. Yes! And then he added arrows so we d know which way to go. Jacob stopped every 20 or so feet to collect pretend train tickets from Oliver and me. Oliver eventually grew tired of this, so Jacob started collecting Oliver s ticket from me. They climbed on some trees, managed to find some mud, drew outlines of train cars in the dirt, and then followed Jacob s line back down the creek bed. They pointed out any green things they saw. Then we went back to the house, took off our warm coats, and cut into the bread. Can you imagine the excitement? I hadn t realized green is a flavor, but it must have been somehow, because those boys absolutely loved this green bread. When we got out the jam, Jacob realized that it was red on the green bread, and that now his bread was Christmas-colored. All sorts of green bread discoveries were made, but the best among them was that if you hold a slice of green bread up to the bright sun, the sun makes it glow green and it looks like a stained-glass window. Sometimes a few drops of food coloring can add a ton of excitement to a day.

I love free software. Two more patches from users of my AFS monitoring scripts (primarily for Nagios) on the heels of the last release, so have another release. This one adds another ignore line to check_afs_bos for the output when there are long-running scheduled jobs, and adds an optional regex filter to check_afs_quotas to select the volumes whose quota one wants to check. Thanks to Georg Sluyterman and Christian Ospelkaus for the patches. You can get the latest version from the afs-monitor distribution page. As before, Debian packages have been uploaded to my personal repository. Also, a quick note about a previous journal entry: Philip Martin and Bernhard R. Link pointed me at the relevant part of the gpg source, which will only check signatures if all signatures use the same class and digest. I updated my previous entry. Thank you!