I m on vacation the 1rst two weeks of June in Manerba del Garda at Lago di Garda. If some dudes are around for beering / chatting / keysigning, feel free to contact me til Friday.
In case of urgent actions (for example #530271), I m without regular internet access there. Feel free to NMU if needed, but try to avoid breaking things. For secuirty related issues please coordinate with team@security.debian.org.
Since I m probably most of the rest of the week busy with organising our camping, please send a short ping, if I m not responding by time, please go ahead.

Apart from having been on vacation under the sun, I ve been busy working with a friend of mine on something we called vmfs-tools, which is partly why there is still no part 2 to the previous post. In case you don t know, VMFS is a clustered filesystem designed to store virtual machine disks for VMware ESX or ESXi Server hosts. Our ultimate goal is to give read-write access to these filesystems from some other host, for maintenance tasks such as, e.g. backup. Files within the VMFS file systems can be accessed either from a CLI tool, or through a FUSE filesystem. For the moment, only read support is available, and some known issues are still to be fixed, as well as a revamp of a part of the internal API. The (quite sparse) homepage for this project is hosted here. A Debian package is also sitting in NEW.

From my friends around who read my "running" posts, here are some news. Since my first marathon, I had a full week rest, then gradually began running again, first starting with 10 to 15 kilometers runs and then slowly reclimbing up distances to reach 23km 3 weeks after the marathon and 26km on May 3rd. Both these were done at a 5:35 to 5:40 mins/km pace, which seems to be the pace I can keep for a long time at this moment. On later weeks, I diminished efforts slightly, cutting off on distances, to concentrate on speed, so running distances between 7 and 12km, with a faster pace (between 5:15 and 5:30). That culminate in a very sharp 6km at 5:06 on a week day, after work (and that loop includes a very steep slope). The target for this "preparation" was indeed May 19th. I was on holidays all week long and that seemed to be a great occasion to try out something I wanted to do for quite a long time: run a marathon....alone. I completed it, moreover with a very great loop in Rambouillet forest, running the 42.2 kilometers in 4h22. Not that a great time (6:12/km), compared to the 4h10 of the Paris Marathon, but fairly interesting as that was done by running lonely...and also by running in woods, partly on very muddy paths. What's even more interesting is that I ended up nearly without cramps and had only to walk on the steepest slope....at km41 (about 20% slope for 200 meters). Note that I made a stop around km25 in order to eat dry fruits as, contrary to official marathons, in lonely marathons, you need to have your own food and beverage with you. So, well, the full time is around 4h30. Even more interesting: I was not tired at all the day after and, accordinng to my wife, much more "alive" than after Paris marathon..:). That probably explains why I could run again only 4 days after (a small but fast 6km) as well as today, 5 days after, for a 14km loop at 5:25/km despite the heat (my very best time on such a distance). So, Debconf runners, bring on your shoes in C ceres. I'll be there and ready..:-)

When starting with Python or just when you haven t read PEP 8 you usually fall into some frequent mistakes. Mostly because you take your experience in other languages to Python and your mind gets confused with the new conventions (or something like that). Some of these errors and their explanation:

• if a == None:
  Really common. None is a singleton, so you can (well, actually, have) to compare to it like if a is None or if a is not None .
• if (condition):
  This is not really pythonic, if doesn t take () around the condition in python, () purpose is grouping, you can use them in an if but only to clarify a really complex condition or similar stuff. Please don t clutter code with unneeded characters.
• if len(list):
  This is a misunderstanding of Python way of things, any empty sequence (string, list, tuple) is False. So if you want to make sure a list is empty, just check if it s False. Same for tuples, and in some ocassions for strings.
• if type(obj) is type(1):
  This is killing kittens, there s a builtin function for this purpose, it s called -surprise- isinstance(object, type). For example isinstance(123, int)

Read more about this and other conventions in PEP 8.

It would appear that debian.org rejected mail for maybe up to twelve hours from late yesterday afternoon (Central timezone) to some time shortly after I got up this morning. Things appear to be back to normal, so a big Thanks to the mail admins. If you happened to have sent me mail to my debian.org address during that time period, you may have gotten a hard reject ('550 Administrative prohibition') as did a test mail of mine. In this case mail may not be respooled, so please do send it again. My alternate address, formed by my first name followed by the family name and the commercial top-level domain, remained functional as a fallback.

Lenny well supported We re pleased that Lenny released with good support for the Eee PC and are now turning our efforts to make Squeeze even better, while continuing to provide support for our Lenny user base. The standard Lenny installer can install Debian on all models of Eee and our custom installer provides the ability to install over wireless for almost every model (more about this later) from a very small image. The latter continues to be our recommended install method, since in addition to being wireless-ready, the custom installer also handles a few other small eee-specific configuration chores to make as much as possible just work right after the install. Solid mainstream support We ve made good on our promise to make Debian work on the Eee PC, not a derivative, many of which use a custom kernel instead of the stock kernel as we do and use a special desktop instead of our users favourites. While we agree that some intriguing things can be done in these areas, it is no substitute for mainstream support. Our users are better served by a solid foundation than specialised modifications that limit their choices. We want them to be able to enjoy the freedom to mold Debian, the universal OS, into whatever suits them best. Squeeze support started Work is well underway on supporting all Eee models in Squeeze. For months, several team members have been experimenting with new kernels, producing support for them in eeepc-acpi-scripts. The current release of this key package (version 1.1.0) supports Linux 2.6.29 and contains enhancements for wifi, sound hotkeys, bluetooth, external displays and OSD. Squeeze will support wired & wifi on all current models With the appearance of 2.6.29 in Sid, all ethernet and wifi cards used in all models of Eee today are supportable without the need for out-of-kernel or non-free drivers. Madwifi is replaced by the free ath5k driver, the non-free rt2860 package is replaced by mainstream kernel support, (though it still requires non-free firmware provided separately,) rtl8187se is included, making it possible now for us to support the model 701SD, and ath9k is included, making full support for newer models such as the 1000HE possible. Lenny backports and live demo All of these changes can be enjoyed today by Lenny users. Just add Daniel Baumann s Lenny kernel backport repository and then install the 2.6.29 kernel and an updated acpid. See our upgrade howto for details. You can try a small (less than 256M) demo of this configuration by downloading beta 2 of our Live USB image. Accessibility Late last year, we discussed how to make it easier for the blind to install Debian unassisted on their Eee PCs. As it was a simple change, we now include brltty in the custom installer, but we understand that some users also need software synthesized text-to-speech, something for which there is no support yet in the standard Debian-installer. We understand this isn t an easy thing to fix, but hope someone will rise to the challenge. Growing team of developers We welcome Darren Salt and Raphael Geissert to the team this year. Both have been actively making contributions to the eeepc-acpi-scripts package over the past months, fixing some outstanding bugs and readying it to handle changes in more recent kernel releases. Moved eeepc.debian.net to new hosting Nico Golde, who hosted eeepc.debian.net for the first year development, has turned his focus to other areas of Debian. Glenn Saberton has stepped in to provide a new home for it. We thank them both for their efforts and for a smooth, uneventful transition from one host to the other. Size of user community Speaking of the move, earlier this year, Glenn shared with us some interesting archive traffic statistics that give us a rough idea how many users we have. For the months of December and January, after factoring out bot hits, we were seeing about 300,000 hits from 15,000 unique users per month. The site handles roughly 60G of traffic per month, most of that from thousands of downloads of our custom installer image. It s hard to draw any firm conclusions about the size of our user base from these stats, as many users may be on dynamic IP numbers, inflating the numbers, but we can conservatively say we have at least 5000 users. Other interesting statistics are that we have anywhere up to 80 users at any given time on our irc channel and over 250 users on the mailing list. Help wanted The Asus Eee PC line continues to expand, with 24 models listed so far. It is a challenge to keep up support for all of them. We re encouraged to see Asus choose a new b/g/n wifi chipset for their 1002HA that is supported by a DFSG free driver ath9k in this case. It appears that the new Atom N280-based 1000HE uses the same chipset as well (though be careful: I know of at least one user who bought a 1000HE in Argentina expecting it to have this chipset and was disappointed to find it had the Ralink chipset instead, we guess because of availability). If this trend continues, we ll be that much closer to our goal of full support for Squeeze main. As it stands, we re already as close as we can get given the state of rt2860 and no prospect on the horizon for replacing the non-free firmware. If you would like to help us out in any way, whether by testing, debugging, patching, or improving our documentation, get in touch with our team. We rely on your feedback to keep Lenny in good shape and work towards making Squeeze even better for all users of Debian on the Eee PC.

A few dud universes can really clutter up your basement. - Neal Stephenson, In The Beginning. . . was the Command Line

What a fun read. It s about technology, sure, but more about culture. Neal takes a good look at operating systems, why we get emotionally involved with them, and why Windows is still so popular. He does this with a grand detour to Disneyland, and a hefty dose of humor. The above quote was from near the end of the book, where he imagines hackers creating big bangs from the command line. He starts out the book from some anecdotes from the early 1970s, when he had his first computer class in high school. His school didn t have a computer, but they did have a teletype (the physical kind that used paper) with a modem link to some university s system. But time on that system was so expensive that they couldn t just dial in and run things interactively. The teletype had a paper tape device. You d type your commands in advance, and it would punch them out on the tape. Then when you dial in, it would replay the tape at high speed . Neal liked this because the stuff punched out of the tape were, actually, bits in both the literal and the mathematical sense. This, of course, led to a scene at the end of the schoolyear where a classmate dumped the bin of bits on the teacher, and Neal witnessed megabytes falling to the floor. Although the book was written in 1999, and needs an update in some ways, it still speaks with a strong voice today and is now also an interesting look at what computing was like 10 years ago. He had an analogy of car dealerships to operating systems. Microsoft had the big shiny dealership selling station wagons. Their image was all wrapped up in people feeling good about their purchase like they got something for their money. And he said that the Linux folks were selling tanks, illustrated with this exchange:

Hacker with bullhorn: Save your money! Accept one of our free tanks! It is invulnerable, and can drive across rocks and swamps at ninety miles an hour while getting a hundred miles to the gallon! Prospective station wagon buyer: I know what you say is true but er I don t know how to maintain a tank! Bullhorn: You don t know how to maintain a station wagon either! Buyer: But this dealership has mechanics on staff. If something goes wrong with my station wagon, I can take a day off work, bring it here, and pay them to work on it while I sit in the waiting room for hours, listening to elevator music. Bullhorn: But if you accept one of our free tanks we will send volunteers to your house to fix it for free while you sleep! Buyer: Stay away from my house, you freak! Bullhorn: But Buyer: Can t you see that everyone is buying station wagons?

That doesn t mean that Stephenson is just a Linux apologetic. He points out that the CLI has its place, and has a true love-hate relationship with the text-based config files (remember XF86Config before the days of automatic modelines? Back when you had to get out a calculator and work some things out with pencil and paper, or else risk burning out your monitor?) He points out that some people want to just have the thing work reasonably well. They don t want control in fact, would gladly give it up if offered something reasonably pretty and reasonably functional. He speaks to running Linux at times:

Sometimes when you finish working with a program and shut it down, you find that it has left behind a series of mild warnings and low-grade error messages in the command-line interface window from which you launched it. As if the software were chatting to you about how it was doing the whole time you were working with it.

Even if the application is imploding like a damaged submarine, it can still usually eke out a little S.O.S. message.

Or about booting Linux the first time, and noticing all sorts of cryptic messages on the console:

This is slightly alarming the first time you see it, but completely harmless.

I use emacs, which might be thought of as a thermonuclear word processor. . . Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer i.e., if someone else is getting paid to worry about how your words are formatted and printed emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. For page layout and printing you can use TeX: a vast corpus of typesetting lore written in C and also available on the Net for free.

I love these vivid descriptions: programs secretly chatting with us, TeX being a corpus of typesetting lore rather than a program. Or how about this one: Unix. . . is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic. Yes, my operating system is an oral history project, thankyouverymuch. The book feels like a weird (but well-executed and well-written) cross between Douglas Adams and Cory Doctorow. Which makes is so indescribably awesome that I can t help but ending this review with a few more quotes.

Because Linux is not commercial because it is, in fact, free, as well as rather difficult to obtain, install, and operate it does not have to maintain any pretensions as to its reliability. Consequently, it is much more reliable.

what really sold me on it [Debian] was its phenomenal bug database (http://www.debian.org/Bugs), which is a sort of interactive Doomsday Book of error, fallibility, and redemption. It is simplicity itself. When had a problem with Debian in early January of 1997, I sent in a message describing the problem to submit@bugs.debian.org. My problem was promptly assigned a bug report number (#6518) and a severity level (the available choices being critical, grave, important, normal, fixed, and wishlist) and forwarded to mailing lists where Debian people hang out.

That should be our new slogan for bugs.debian.org: Debian s interactive Doomsday Book of error, fallibility, and redemption.

Unix is hard to learn. The process of learning it is one of multiple small epiphanies. Typically you are just on the verge of inventing some necessary tool or utility when you realize that someone else has already invented it, and built it in, and this explains some odd file or directory or command that you have noticed but never really understood before.

I ve been THERE countless times.

Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.

It is obvious, to everyone outside of the United States, that our arch-buzzwords, multiculturalism and diversity, are false fronts that are being used (in many cases unwittingly) to conceal a global trend to eradicate cultural differences. The basic tenet of multiculturalism (or honoring diversity or whatever you want to call it) is that people need to stop judging each other-to stop asserting (and, eventually, to stop believing ) that this is right and that is wrong, this true and that false, one thing ugly and another thing beautiful, that God exists and has this or that set of qualities.

The stone tablets bearing the Ten Commandments carved in immutable stone the original command-line interface

Apparently this actually works to some degree, for police in many lands are now complaining that local arrestees are insisting on having their Miranda rights read to them, just like perps in American TV cop shows. When it s explained to them that they are in a different country, where those rights do not exist, they become outraged. Starsky and Hutch reruns, dubbed into diverse languages, may turn out, in the long run, to be a greater force for human rights than the Declaration of Independence.

Unix has always lurked provocatively in the background of the operating system wars, like the Russian Army.

Available for free online, or as a 160-page book from Amazon.

I've just released the first stand-alone distribution of the test suite driver that I use for nearly all of my software that both has a test suite and isn't only for Perl. C TAP Harness is a pure-C implementation of TAP, the Test Anything Protocol. (TAP is the text-based protocol used by Perl's test suite.) This package provides a harness similar to Perl's Test::Harness for running tests, with some additional features useful for test suites in packages that use Autoconf and Automake, and C and shell libraries to make writing TAP-compliant test programs in those languages easier. I wrote the underlying program that's the core of this distribution for INN's test suite a long time ago and tweaked it over time, but over the past year or so I've added a lot of TAP features I wasn't aware of at the time and significantly improved the supporting libraries. There is now special support for builds outside the source directory, both to help the harness find the test programs (even if they're not compiled) and to help test programs find supporting data. While one can build and install this package, that's not its intended use. Instead, just the harness program and the bits of TAP library that one wants to use are meant to be copied into any package that needs a test suite. My main purpose for making it a separate package is so that I can easily update all of my packages to benefit from improvements in the shared code. Support for the TAP protocol isn't entirely complete. I don't yet support giving the plan last instead of first or reporting the text for individual skipped tests in a useful way, and the handling of todo tests is a bit lame. But all the standard features I've wanted to use in the past are supported, including skipping entire test cases. Also, while I'm admittedly biased, I think the result reporting is a bit cleaner and nicer than Perl's Test::Harness. You can get the current version from the C TAP Harness distribution page.

Here are a few hints if you want your reports to be treated more promptly. When testing fails, try unstable If you are running testing, not all bug reports are interesting. More specifically, the relevant ones are about insufficient dependencies that let slip into testing a non-working combination of packages. Think of the I upgraded foo, then bar broke category. Otherwise, the reason why reportbug looks for newer versions of a package in unstable is that, in most cases, the bug is fixed in unstable. If you can, always try the unstable version before reporting the bug. Report bugs against the failing package This is related to printing in a GNOME program, so I report this against libgnomeprint. Always file reports against the failing program. If there is a library involved, reportbug will include the necessary information so that the maintainer can easily reassign. If you re not sure of the affected package, use a metapackage (for example, gnome for GNOME-related packages). Do not second-guess the origin of the bug After upgrading libfoo, bar starts crashing, so I m reporting it against libfoo. Unless you can tell which function is at fault and how this is ABI breakage, you should report the bug against the program that crashes. The program s maintainer will reassign if needed, and will hit the library s maintainer with a hammer if needed. Don t forget to explain what s wrong The frobniz in libfrob is broken, you should change /usr/share/libfrob/blah line 13 to something else. I don t know what libfrob is about, but I have some problems that look frobniz-related. Do not second-guess, always start explaining what bug you are seeing first. Your attempts at investigating it can be interesting, but don t forget to explain what bug lead you on investigating. What is the use case we should cover? I m trying to do that with your package and it looks extremely complicated/doesn t work as expected/fails miserably. Your package is clearly broken! If your attempts to do something that should be trivial, given the purpose of the package, fail, then you are probably looking at the problem at the wrong angle. There may be a much simpler, though radically different, way to do what you are trying to achieve. In these situations, always include in your report what you are trying to do and why you want to do it. strace is not a general-purpose debugging tool Whether you observe a crash, a deadlock or a livelock, strace is not the tool that will give us information. The only thing you do by adding a strace log to the bug report is making it unreadable with its thousands of lines of output. For the specific cases that require strace for debugging, these traces are welcome but if you re not sure, don t attach them. The developers will ask them for you. Otherwise, the general-purpose debugging tool is gdb. Use reportbug There is a good reason why some packages include bug control files and scripts. Use a reporting tool that takes them into account. Unless you are requesting an enhancement, always use reportbug. Please avoid reportbug-ng since it only provides parts of the required information.

In close to 11 years of living in Europe, I've accomplished plenty beyond working in the high-tech sector: I've also been fairly active in Immigration Policy, especially on aspects that affect migrant labor. Because of this, I keep on getting more and more requests to produce statements or to appear on panels to discuss issues pertaining to migrant labor and to immigrants' integration. The hot topic of last week was Swedish language for immigrants, the crux of the issue being that even though Swedish has an official language status in Finland, in practice, it is pretty much impossibly for immigrants to register their kids at the Swedish language school, to claim public services in Swedish or, even more so, to request labor training in the Swedish language at the Employment Office. The weekly newspaper Helsinki Times, in collaboration with the media think tank Magma, recently conduced a survey of the immigrant population, to find out how much they know about Swedish culture in Finland and about the Swedish language. It was in this context that the Helsinki Times and the national television's Swedish programming (FST) asked for an interview with yours truly, because I have recently visited the Ministry of Employment and Economics with a concrete proposal to facilitate the availability of labor training in the Swedish language. This FST webcast, starting at 16:03 minutes into the show, and the above Helsinki Times article provide more details about the context and about my proposal to the Ministry.

It's taken a lot longer than I expected (mostly due to getting other things done in Emdebian etc.) but now that Lenny is out, QOF can finally drop all the previously deprecated code and move to libqof2, so the upstream code has now been released via Alioth (0.8.0) and the binaries have been uploaded to Debian and are waiting in NEW.

QOF provides a set of C language utilities for performing generic structured complex queries on a set of data held by a set of C/C++ objects. This framework allows programmers to add query support to their applications without having to hook into a SQL Database. QOF is a large part of my attempts to get some degree of data freedom to complement the source code freedom. This remains a problem with certain applications, especially financial ones, so I've tried to make it easier to both import and export data between programs using QOF and to convert the default QOF data storage formats into other common formats using simple tools and scripts based on XSL or perl. Having a SQL-type query interface accessible via the command line is a huge bonus when dealing with large data sets.

There is a patch for gnotime that makes the final adjustments to handling the removed code. pilot-qof and gpe-expenses already build cleanly without the deprecated code but each of these is also pending a new upstream release, so rather than need a binNMU, I'm simply going to make those releases when QOF clears NEW.

Having said that, pilot-qof and gpe-expenses introduce new binary packages themselves so they will spend time in NEW too. pilot-qof will be the last of the set to be released because the new upstream version can use symbols from the new gpe-expenses release to make it easier to move data between applications. However, that support is optional at build time and could be done via a Debian revision, so I might do it that way.

This also marks the completion of the migration of QOF from SourceForge to Alioth - principally for easier bug tracking and a usable mailing list archive. The QOF VCS is in svn.debian.org.

The mailing list for QOF development is therefore at alioth:
QOF-devel and archives also.

I'm still working on two other QOF-based utilities - one that can handle simple accounts and one to handle simple invoices. The invoice handling is already partially implemented in pilot-qof but I'm looking at a GTK+ frontend with a robust command line interface so that scripts can update the invoice data behind-the-scenes. Hopefully, some form of arbitrary-format parser can be arranged that can handle extracting data from whatever form the client happens to send - typically PDF. It'll need tweaking for each client, but it could work. The objects used by gpe-expenses and pilot-qof (including invoices) are exposed via QOF and can be mixed together in any new QOF application, easily able to read data from multiple sources, merge data sets, query data sets and export into other formats. The core currency and expense types come from pilot-link but are then enhanced to support GnuCash conventions.

For information on another QOF application called "estron" - an idea for a data-driven query interface - see http://estron.alioth.debian.org/. Problem 1 with estron: the examples all rely on postgres and I just can't get that to setup properly as either a test system or as a Debian package. Problem 2: estron was intended to be an interpreter that could be written "in itself" but whilst this is possible for the simpler examples, doing more complicated stuff like calculating values from other values makes the estron XML very obtuse. The current codebase uses GOB2 to

QOF is now stable and I don't expect to need another SONAME bump for quite a while. If anyone is interested in taking on estron or helping with the Cash and/or Invoice frontends, let me know. The problem with estron currently is bitrot - the GTK+ frontend has too many gtk1.2 hangovers which now fail to build.

I managed to break the LCD on my HP r717 digital camera a while back, but couldn't find anything that excited me as a replacement, so have been doing without and borrowing my son's camera from time to time. That changed recently... my new camera is a Casio High Speed EXILIM model EX-FC100BK. I've never been able to get the timing right to take photos of our rockets leaving the launch rails. I manage to get passable videos from time to time, and a lot of pictures of smoke trails... but WOW, the ability to take a burst of high-resolution still photos at a fast frame rate (some of which are even before the shutter release gets fully pressed!) completely and totally rocks my world! I just put a few of the best frames I captured at Saturday's launch up on Flickr. Enjoy!

• Marco d Itri about adding support for yet-unknown-to-kernel-drivers devices. More specifically: how to make udev tell ftdi-sio that it should accept a certain VendorID/ProductID combination in addition to previously supported ones.
• Thomer M. Gil about ICMPTX, a combination made from proxy and server that tunnels IP through ICMP. Nice thing if you need a connection from some NATed and heavily firewalled location I guess. (Thanks go to Runa Sandvik for finding this.)
• Non-technical in a way, but still a nice link: Image of the Shuttle transiting the sun, thanks to Pablo Lorenzzoni for this link.
• Another post by Marco d Itri that explains how to install Debian on a SheevaPlug. Not that I need this info now, but it might come in handy some day.

That s it for now, will update the post if I find more interesting links in the next few days.

Some common classes of USB devices are supported by the same drivers because they share an identical or almost identical hardware design, but since each manufacturer uses its own Vendor and Product IDs the drivers need to be updated for each one. Some popular examples are 3G modems and devices which present a serial interface. As an interim solution until the kernel can be updated, the Linux device model provides a sysfs parameter called new_id which can be used to notify a driver that it should recognize a VID/PID pair as supported. The following example uses udev to add support for the Sheevaplug to ftdi_sio, the driver for the widely used USB to UART chips manufactured by FTDI. First we need a rule to automatically load the driver when the device is plugged in: udev cannot load it by itself since it does not know about the Sheevaplug VID and PID:

# if no driver has claimed the interface yet, load ftdi_sio
ACTION=="add", SUBSYSTEM=="usb", ENV DEVTYPE =="usb_interface", \
        ATTRS idVendor =="9e88", ATTRS idProduct =="9e8f", \
        DRIVER=="", \
        RUN+="/sbin/modprobe -b ftdi_sio"

And then we instruct udev to add the new VID and PID after the driver has been loaded:

# add the sheevaplug VID and PID to the list of devices supported by ftdi_sio
ACTION=="add", SUBSYSTEM=="drivers", \
        ENV DEVPATH =="/bus/usb-serial/drivers/ftdi_sio", \
        ATTR new_id ="9e88 9e8f"

While we are configuring udev we can also make it create a symlink for the console interface, since the FTDI chip in the Sheevaplug provides two serial interfaces: interface 0 is connected the JTAG lines and interface 1 to the serial console:

# create a convenience symlink for the console device
ACTION=="add", KERNEL=="ttyUSB*", \
        ATTRS interface =="SheevaPlug JTAGKey FT2232D B", \
        ATTRS bInterfaceNumber =="01", \
        SYMLINK+="sheevaplug"

This last rule shows an important misfeature of udev: while the keys ending in "S" can match nodes at any level of the devices chain, the matched nodes must be all at the same level. In this case this means that a single rule cannot have keys matching both the interface number and the VID and PID: this would require multiple rules and GOTO directives, so my rule matches the interface node which is available at the same level.

Russel, I agree that some porn sites are facing interesting technical challenges, but I wouldn't suggest using them as example for anything, just like a talk about the challenges of torture is always inappropriate in a human society.

Porn is, except for self made porn and some other corner cases, abuse and oppression. Simple as that.

And please, before you try to argue against that simple statement, read the lyrics of no answer for a dancer from one of my favorite bands, consolidated, and think for more than ten minutes. If we were living in really free societies, porn could be fun.

Which reminds me of a quote from Rebecca L. Eisenberg: "A truly radical view of pornography recognizes that we are what we consume -- and if we are going to alter the face of society, and destroy Victorian and religious notions like gender altogether -- as I believe we must -- we must be willing to evaluate and change every aspect of our lives, including the images we feed ourselves as we fuck, as terrifying as it sounds. Like it or not, revolution is a scary concept." The complete text where this quote is from can be found online on her webpage.

P.S: If you hear me playing "the internet is for porn" (this musicalsong) or remember me doing so - can you now see the great irony? I would have hoped you've seen it before. Or at least wondered, what the hell I was doing.

There is currently some discussion about a talk which used pornographic imagery and jokes to illustrate points about Ruby programming [1]. A similar event happened in 2006 here is the description of the event from the author - which includes an unreserved apology [2]. It seems to me that the current discussion focusing on what is inappropriate for a public lecture is the wrong way to do it as there is a vast range of inappropriate material. I suggest that instead a white-list of appropriate references to porn in lectures will be more effective - if nothing else it makes for a much smaller list. Here is a first draft of such a list:

1. Pornographic web sites handle a lot of traffic. There are significant technical problems that need to be solved. A lecture from an employee of an Internet porn company which covers the solutions to those technical problems would be of interest to many system administrators. Of course such a lecture should not promote the Internet porn company or show any samples of their products.


2. Digital processing of images is an interesting topic. Having a digital editor from a magazine such as Vogue describe in detail how they do their job would be really interesting. There is a lot of overlap between the range of pictures displayed in Vogue and those displayed on porn sites. Having an employee of a porn company demonstrate how they touch up the picture of a fully clothed model would be an interesting technical topic, but of course it would be totally inappropriate to make any specific mentions of how the parts of the picture which are not PG-13 rated are edited. Even showing a picture of a porn star might be controversial, but I m sure that the same work could be reproduced with a photo of someone who has a more respectable career. Touching up a picture of RMS to make him look like a politician would make for a challenge for the presenter and an interesting lecture.


3. The image known as Lenna is a photograph of a Playboy model named Lena that is widely used to test image compression [3]. While the image remains controversial, it seems to me that it would be impossible to give a complete and factual account of the history of image compression without mentioning it.


4. The police have great discretionary powers to determine which crimes should be actively investigated. Senior police decide how many resources to assign to each case. I believe that in many jurisdictions the police will assign a much lower priority to a hacking case if the victim is running a porn service. Rumor has it that porn sites put a lot more effort into system security than most Internet services, partly due to not having as much protection from the police as other industries and partly because their customers don t want to be identified. I would be very interested in attending a presentation about practical computer security by a system administrator from a porn site. As an aside I m always interested in talking to people who do security work, so I would like to have a chat with someone who does such work for a porn site.


5. A few years ago I attended a lecture about the security implications of porn surfing. It had some scary statistics on the number of porn sites that try to deploy malware on the computers of the people who view porn, and it made a good business case for banning porn at work without reference to HR issues (which is very relevant for the jurisdictions where viewing porn at work is not considered to be a social problem). I would like to see a new version of that talk with statistics based on more recent research, my theory is that modern porn sites are more toxic than the old ones due to the general increase in criminal activity on the net - but I have no evidence to support it.

Of course in all cases jokes about porn are not acceptable, mentions of porn need to be strictly on the basis of historical analysis or the description of technical and legal issues which are relevant to the audience. Delivering a talk about porn without inappropriate jokes would take a great deal of effort, but it can be done (and I ve seen it done once). For these five cases (and the few others that will probably be suggested in comments) it would probably be best if the conference organisers viewed the talk first to ensure that there was no misunderstanding about what is appropriate. I think that comparing a short list of specific cases where porn can reasonably be mentioned in a public lecture with the vast number of potential inappropriate references illustrates the probability of a random porn reference being acceptable. The probability of making a random porn reference that is appropriate is probably slightly less than that of winning the lottery.

• [1] http://use.perl.org/~jarich/journal/38978


• [2] http://use.perl.org/~Alias/journal/31986


• [3] http://en.wikipedia.org/wiki/Lenna

Some spring days just seem full to bursting with unusual experiences. I spent the night at the yurt and in just four hours today:

• Worked to protect my ethernet cables from spinning blades of doom by encasing them in pipes where my sister wants to mow.
• Just as I was getting into the creek for a dip, a hawk (or similar) flew down the creek through a tangle of trees and almost into my face. We were both pretty startled.
• Got in a splashing war with a dog. Lucy is capable of swimming out into the creek and splashing water three feet high, right at you. We had way too much fun, and now I think one of us is smarter than I'd thought, and the other, perhaps sillier.
• Got home to find a huge box from Amazon. Hmm, I hadn't ordered anything from Amazon... Double hmm, the inside was just full of packing paper... Yipes, there's a big red axe buried in here!

Thanks to Iain M from Melbourne who writes, "We have never met. I have used your software and gained insight from your blog, over the years. So thanks. Also, I have never bought someone an axe before. This is cool." I forgot I had that in my wishlist, but now I can split wood with ease, when I run out of Amazon packaging material to burn.

I've said it multiple times, but all mailing list managers suck. Especially mailman. (On that topic SELinux is nasty, Emacs is the one true editor, and people who wear furry boots are silly.) Having setup some new domains I needed a mailing list manager, and had to re-evaluate the available options. Mostly I want something nice and simple, that doesn't mess around with character sets, that requires no fancy deamons, and has no built in archiving solution. Really all we need is three basic operations:

• Confirmed opt-in subscription.
• Confirmed opt-out unsubscription.
• Post to list.

Using pipes we can easily arrange for a script to be invoked for different options:

# Aliases for 'list-blah' mailing list.
#
^list-blah-subscribe$:   " /sbin/skxlist --list=list-blah --domain=example.com --subscribe"
^list-blah-unsubscribe$: " /sbin/skxlist --list=list-blah --domain=example.com --unsubscribe"
^list-blah$:             " /sbin/skxlist --list=list-blah --domain=example.com --post"

The only remaining concerns are security related. The most obvious concern is that the script named will be launched by the mailserver user (Debian-exim in my case). That suggests that any files it creates (such as a list of email addresses - i.e. list members) will be owned by that user. That can be avoided with setuid-fu and having the mailing list manager be compiled. But compiled code? When there are so many lovely Perl modules out there? No chance! In conclusion, if you're happy for the exim user to own and be able to read the list data then you can use skxlist. It is in live use, allows open lists, member-only lists, and admin-only lists. It will archive messages in a maildir, but they are ignored for you to use if you see fit. List options are pretty minimal, but I do a fair amount of sanity checking and I see no weaknesses except for the use of the Debian-exim UID. ObFilm: Blade

continuing on the trend of finding novel ways to make life more interesting with git, here's the description from a new hook:

# prepare-commit-msg hook for debian package git repositories
#
# this script scans the diff that is going into a commit, and automatically
# injects some "proposed" comments based on what it finds in the diff.  this
# can be used to avoid a few extra keystrokes when performing some of the
# more standard/boring tasks.

(see below for how to fetch the script) this one definitely falls in the "carrot" category, as it encourages properly isolated (and thus automatically identifiable) changes. the proposed comments are then given to the standard editor, so one can easily amend them, append "Closes:" lines, etc. some sample use-cases currently implemented:

• changelog entries
  • detect when a new version is introduced in debian/changelog

    prepare release information for <dist>/<vers>
    
    

  • detect when an existing version is updated in debian/changelog

    release information for <dist>/<vers>
    
    

• debconf translations
  • detect when one or more po files are modified

    updates to (<lang1>,<lang2>...) debconf translations
     * <lang1>: <translator for lang1>
     * <lang2>: <translator for lang1>
    
    

• updates in debian/patches
  • detect when a new patch is introduced

    new debian patch <patchname>
    <patch header (anything before the diff)>
    
    

  • detect when an existing patch is modified

    update debian patch <patchname>
    <patch header>
    
    

  • detect when several patches are imported simultaneously

    import <n> files in debian/patches
    <patch1>:
      <patch header>
    <patch2>:
      <patch header>
    <non-patch-file (series/etc)>:
      no patch description/comments found
    ...
    
    

  • detect when several patches are created/modified simultaneously

    create/update <n> files in debian/patches
    ...
    
    

as always, comments/feedback/suggestions/etc welcome using this new hook note this is the same repo as the previous hooks i've blogged about, so if you already have that set up you can skip the clone and instead just pull in the changes. also note that this is in your local repo, not the remote one. to set it up:

REPO_PATH=/path/to/your/repo.git
HOOK_REPO_PATH=/somewhere/you/want/to/put/it
git clone git://git.debian.org/users/seanius/vcs-hooks/git-hooks.git $HOOK_REPO_PATH
ln -sf $HOOK_REPO_PATH/debian/git-hooks/prepare-commit-msg-guess-message.py $REPO_PATH/.git/hooks/prepare-commit-msg

there aren't currently any configurable options in this hook.

To the extent possible under law, Antti-Juhani Kaijanaho has waived all copyright and related or neighboring rights to
Asynchronous transput and gnutls. This work is published from Finland. GnuTLS is a wonderful thing. It even has a thick manual but nevertheless its documentation is severely lacking from the programmer s point of view (and there doesn t even seem to be independent howtos floating on the net). My hope is to remedy with this post, in small part, that problem. I spent the weekend adding STARTTLS support to the NNTP (reading) server component of Alue. Since Alue is written in C++ and uses the Boost ASIO library as its primary concurrency framework, it seemed prudent to use ASIO s SSL sublibrary. However, the result wasn t stable and debugging it looked unappetizing. So, I wrote my own TLS layer on top of ASIO, based on gnutls. Now, the gnutls API looks like it works only with synchronous transput: all TLS network operations are of the form do this and return when done ; for example gnutls_handshake returns once the handshake is finished. So how does one adapt this to asynchronous transput? Fortunately, there are (badly documented) hooks for this purpose. An application can tell gnutls to call application-supplied functions instead of the read(2) and write(2) system calls. Thus, when setting up a TLS session but before the handshake, I do the following:

                gnutls_transport_set_ptr(gs, this);
                gnutls_transport_set_push_function(gs, push_static);
                gnutls_transport_set_pull_function(gs, pull_static);
                gnutls_transport_set_lowat(gs, 0);

Here, gs is my private copy of the gnutls session structure, and the push_static and pull_static are static member functions in my sesssion wrapper class. The first line tells gnutls to give the current this pointer (a pointer to the current session wrapper) as the first argument to them. The last line tells gnutls not to try treating the this pointer as a Berkeley socket. The pull_static static member function just passes control on to a non-static member, for convenience:

ssize_t session::pull_static(void * th, void *b, size_t n)
 
        return static_cast<session *>(th)->pull(b, n);
 

The basic idea of the pull function is to try to return immediately with data from a buffer, and if the buffer is empty, to fail with an error code signalling the absence of data with the possibility that data may become available later (the POSIX EAGAIN code):

class session
 
        [...]
        std::vector<unsigned char> ins;
        size_t ins_low, ins_high;
        [...]
 ;
ssize_t session::pull(void *b, size_t n_wanted)
 
        unsigned char *cs = static_cast<unsigned char *>(b);
        if (ins_high - ins_low > 0)
         
                errno = EAGAIN;
                return -1;
         
        size_t n = ins_high - ins_low < n_wanted
                ?  ins_high - ins_low
                :  n_wanted;
        for (size_t i = 0; i < n; i++)
         
                cs[i] = ins[ins_low+i];
         
        ins_low += n;
        return n;
 

Here, ins_low is an index to the ins vector specifying the first byte which has not already been passed on to gnutls, while ins_high is an index to the ins vector specifying the first byte that does not contain data read from the network. The assertions 0 <= ins_low, ins_low <= ins_high and ins_high <= ins.size() are obvious invariants in this buffering scheme. The push case is simpler: all one needs to do is buffer the data that gnutls wants to send, for later transmission:

class session
 
        [...]
        std::vector<unsigned char> outs;
        size_t outs_low;
        [...]
 ;
ssize_t session::push(const void *b, size_t n)
 
        const unsigned char *cs = static_cast<const unsigned char *>(b);
        for (size_t i = 0; i < n; i++)
         
                outs.push_back(cs[i]);
         
        return n;
 

The low water mark outs_low (indicating the first byte that has not yet been sent to the network) is not needed in the push function. It would be possible for the push callback to signal EAGAIN, but it is not necessary in this scheme (assuming that one does not need to establish hard buffer limits). Once gnutls receives an EAGAIN condition from the pull callback, it suspends the current operation and returns to its caller with the gnutls condition GNUTLS_E_AGAIN. The caller must arrange for more data to become available to the pull callback (in this case by scheduling an asynchronous write of the data in the outs buffer scheme and scheduling an asynchronous read to the ins buffer scheme) and then call the operation again, allowing the operation to resume. The code so far does not actually perform any network transput. For this, I have written two auxiliary methods:

class session
 
        [...]
        bool read_active, write_active;
        [...]
 ;
void session::post_write()
 
        if (write_active) return;
        if (outs_low > 0 && outs_low == outs.size())
         
                outs.clear();
                outs_low = 0;
         
        else if (outs_low > 4096)
         
                outs.erase(outs.begin(), outs.begin() + outs_low);
                outs_low = 0;
         
        if (outs_low < outs.size())
         
                stream.async_write_some
                        (boost::asio::buffer(outs.data()+outs_low,
                                             outs.size()-outs_low),
                         boost::bind(&session::sent_some,
                                     this, _1, _2));
                write_active = true;
         
 
void session::post_read()
 
        if (read_active) return;
        if (ins_low > 0 && ins_low == ins.size())
         
                ins.clear();
                ins_low = 0;
                ins_high = 0;
         
        else if (ins_low > 4096)
         
                ins.erase(ins.begin(), ins.begin() + ins_low);
                ins_high -= ins_low;
                ins_low = 0;
         
        if (ins_high + 4096 >= ins.size()) ins.resize(ins_high + 4096);
        stream.async_read_some(boost::asio::buffer(ins.data()+ins_high,
                                                   ins.size()-ins_high),
                               boost::bind(&session::received_some,
                                           this, _1, _2));
        read_active = true;
 

Both helpers prune the buffers when necessary. (I should really remove those magic 4096s and make them a symbolic constant.) The data members read_active and write_active ensure that at most one asynchronous read and at most one asynchronous write is pending at any given time. My first version did not have this safeguard (instead trying to rely on the ASIO stream reset method to cancel any outstanding asynchronous transput at need), and the code sent some TLS records twice which is not good: sending the ServerHello twice is guaranteed to confuse the client. Once ASIO completes an asynchronous transput request, it calls the corresponding handler:

void session::received_some(boost::system::error_code ec, size_t n)
 
        read_active = false;
        if (ec)   pending_error = ec; return;  
        ins_high += n;
        post_pending_actions();
 
void session::sent_some(boost::system::error_code ec, size_t n)
 
        write_active = false;
        if (ec)   pending_error = ec; return;  
        outs_low += n;
        post_pending_actions();
 

Their job is to update the bookkeeping and to trigger the resumption of suspended gnutls operations (which is done by post_pending_actions). Now we have all the main pieces of the puzzle. The remaining pieces are obvious but rather messy, and I d rather not repeat them here (not even in a cleaned-up form). But their essential idea goes as follows: When called by the application code or when resumed by post_pending_actions, an asynchronous wrapper of a gnutls operation first examines the session state for a saved error code. If one is found, it is propagated to the application using the usual ASIO techniques, and the operation is cancelled. Otherwise, the wrapper calls the actual gnutls operation. When it returns, the wrapper examines the return value. If successful completion is indicated, the handler given by the application is posted in the ASIO io_service for later execution. If GNUTLS_E_AGAIN is indicated, post_read and post_write are called to schedule actual network transput, and the wrapper is suspended (by pushing it into a queue of pending actions). If any other kind of failure is indicated, it is propagated to the application using the usual ASIO techniques. The post_pending_actions merely empties the queue of pending actions and schedules the actions that it found in the queue for resumption. The code snippets above are not my actual working code. I have mainly removed from them some irrelevant details (mostly certain template parameters, debug logging and mutex handling). I don t expect the snippets to compile. I expect I will be able to post my actual git repository to the web in a couple of days. Please note that my (actual) code has received only rudimentary testing. I believe it is correct, but I won t be surprised to find it contains bugs in the edge cases. I hope this is, still, of some use to somebody