(Sometimes a blog is just somewhere to put stuff you'll otherwise forget.)

dpkg -l colrm 90 colrm 1 2 grep '^ ' column -t

(There are two spaces in that grep, just in case it doesn't come out right in the final blog rendering.)

For those times when you just want the package list without the fluff - or, as a script that can accept a parameter:

#!/bin/sh

dpkg -l "$*" colrm 90 colrm 1 2 grep '^  ' sort column -t

$ ~/scripts/versiontable.sh apt* dpkg*

Could add grep ii as an extra pipe in that (after the initial dpkg -l call) to only list installed versions etc.

$ ~/scripts/versiontable.sh dpkg* apt*

apt              0.7.21

apt-arm-cross    0.7.11

apt-cross        0.13.0

apt-doc          0.7.21

aptitude         0.4.11.11-1+b1

apt-show-source  0.10

apt-utils        0.7.21

dpkg             1.14.26

dpkg-cross       2.5.1

dpkg-dev         1.14.26

dpkg-www         2.54+nmu1

Interesting side-effects though - *foo* is different to "*foo*" or \*foo\*. Might be better to use $@ but that means always needing quote marks for multiple package queries.

There are two topics that seem to receive a steady stream of comments on this blog. My entry on Edmonton garners a smattering of comments every few months, usually giving E-town a huge thumbs down. The other entry concerns my tribulations with BCBS and here I receive a steady stream of sad stories all of which point to the horrors caused by some branch of BCBS such as my least favorite one Horizon Blue Cross Blue Shield of NJ. Along with the comment posted above, I got this one asking me to reveal the email address of the PR director of BCBS NJ. In the past I advised folks to google it to find it. But I just tried and it is actually a bit harder to find and I wonder if I should post to one of the many press releases that exist on the web with this information? I hope thats some with some sort of time and lots of anger (toward BCBS) to start a website specifically geared toward and against BCBS. Call it Blue Cross No Shield (I think I actually own that and am pretty proud of the name) or something of that nature and throw up some blog and post horror stories in the style of the consumerist. There will be no shortage of them, especially if the blog is national in scope. Get a mailing list going and start a fax campaign among many others. Share contact information about public relations directors and Other People in Power, tips and advice on fighting them, and perhaps even move to the next level of organizing. I am not sure writing this here will do anything to inspire other and I would love to do this sort of rabble rousing as I get immense pleasure from doing so. But I simply am in the red when it comes to time. But I hope that some of the folks that have posted comments on this blog take the initiative to start a larger campaign (or someone can point me to an exisitng one). update: Now that I think of it, The Consumerist should really take up this cause and devote a section JUST to health insurance. They are already a brand name of sorts with lots of eyeballs on the site, everyday.

While shopping at Highpoint [1] today I noticed that they had a new loyalty system. It s called Mo Rewards [2] (for which the real web site is at MoCoMedia.net [3] which has no link from the main site because they didn t care enough about their web presence). The way that Mo works is that everyone gets a free RFID token similar to the two in the above photograph. The token comes with a pseudo-random seven letter code that you have to SMS to register it to your phone. You SMS the code and then receive a confirmation SMS. After that you can wave your token near a detector any time you visit the shopping center and you will receive three SMS messages with discount offers. You can send an SMS with your gender and birth-year to receive more targeted offers. To redeem offers you have to wave your token near a detector at the store so they know who is using the offers. Then of course once the database knows that you are a regular customer at a certain shop they can send you targeted advertising to entice you to buy from that shop on every visit. I presume that they have some sort of bidding system for adverts from the shops of a similar nature to the Google advertising. It s an interesting system and a lot better than most loyalty programs. One interesting thing about this is that high quality RFID devices are being given out for free. The tokens are quite solidly constructed and could be used for a variety of other purposes. I couldn t find anyone offering RFID tags at a reasonable price with a quick Google search (the cheapest was $75 for 100 tags - and they were the fragile ones used for marking stock in shops). So a hobbyist who wanted to do some RFID stuff could buy a cheap reader under one of the demo offers (where you get a reader and a small quantity of keys for a reasonable price) and then collect free RFID tokens from shopping centers. I expect that the number of people who would do such things is small enough to not be statistically significant and therefore not affect the business model. The tags are given out freely with no requirement that you must use them for the expected purpose (Mo Rewards) instead of using them for your own RFID work.

• [1] http://www.highpoint.com.au/


• [2] http://www.morewards.com.au/


• [3] http://www.mocomedia.net/

DarkSEO has some code to attack php3bb captchas. (Note: I didn't even look at the code, it could be a virus or anything).I do not find that very surprising that this has happened, most of the captchas around are very naive, and I've seen multiple scientific articles detailing how to attack various captchas. Many use colors and thin lines to make them look hard, but after applying a naive energy function and doing some blurring to remove the thin lines, they break down.ReCaptcha is quite interesting, because it doesn't bother with some useless colorification that doesn't change contrast. But I wonder if it can't be overrun by spammers and how long it will scale. Still I figure it is what I would pick right now, because they can upgrade it if it actually is attacked by solvers.It doesn't help much for the proxy attack on Captchas though (offer users to view some pr0n in exchange for solving a Captcha that you actually were given to solve by another site) - at least not when combined with some XSS and/or bot net. (The 'obvious' proxy approach can be IP-filtered.)

My SE Linux Play Machine [1] has a file named thanks.txt for users to send messages to me [2]. On a number of occasions people have offered to give me things in exchange for the password for the bofh account (the one with sysadm_r privileges). I ve been offered stolen credit cards, a ponzi scheme of root access to servers on the net, and various other stuff. Today I received an amusing joke entry: Hello Kind Sir, I am Dr. Adamu Salaam, the the bank manager of bank of africa (BOA) Burkina Faso West I am sending you this message about the $3.14159 million dollars in bank account number 2718281828450945. I will give you this money in exchange for the password to the bofh account. The amount of money is based on the value of Pi. The account number is based on the mathematical constant e [3]. It s a pity that the author of that one didn t sign their real name. Whoever created that should have claimed credit for their work.

• [1] http://www.coker.com.au/selinux/play.html


• [2] http://doc.coker.com.au/computers/thankstxt-on-my-play-machine/


• [3] http://en.wikipedia.org/wiki/E_(mathematical_constant)

Following to the email sent regarding the French law known as HADOPI (I blogged about it a few weeks ago), I had a meeting this afternoon with my local representative. This half an hour meeting allowed me to explain my fears regarding this firewall which could be set up on French citizens computers to enable them to prove their non-culpability (provided their computer runs a popular proprietary OS). My representative kindly listened to me and his assistant understood the situation very well. I was even impressed that they have worked a lot on this law before the meeting. They both proposed to raise this issue to Christine Albanel, the current French Minister for Culture and Communication, who is at the origin of this law. They agreed to say that this wouldn t be changed for the next lecture (planned for the end of the month), as this particular chapter was meant to be detailed in further texts. They also admitted that this law had little chance to be really applied as is, as they consider some aspects to be anti-constitutional - they hence think that the French Constitutional Council will prevent this law to be applied, at least as it is when writing this post.
My representative also admitted that this law was somewhat outdated (even if not yet voted!). Actually, this kind of law will ever be outdated I kindly thank my representative for his time and his frankness (even if on the bad side for this law, he was very open to my thoughts). Good to know France is still a real Democracy!

Raphael Bauduin emailed me to say that he s organising an event for Profoss: (28 april in Brussels) will take a look at legal aspects of the use of FOSS in professional environments. http://www.profoss.eu/events It will bring interesting information for most ICT professionals, even for those specialised in FOSS, but if this is not for you, it might be of interest to people around you (your boss or colleagues), so don t hesitate to spread the information around you. There is problem with the current website: it requires javascript. An updated site without that problem will appear very soon . If you go to the event, I d love to hear how it goes - please leave a comment on this article!

TED published an interesting interview with Shai Agassi about electric cars [1]. One idea that I hadn t heard before is that of moving car batteries between regions as they lose capacity. An old battery for an electric car that can only handle short journeys may be useful in a region where journeys are typically short. On a similar note I expect that in a few decades the less prosperous countries will import old electric vehicles and fit them with 4 or more batteries. Last time I checked the Prius battery pack weighed about 120Kg, so the car would be usable with 4 battery packs if driven at low speeds. Shai Agassi also gave a TED talk on this topic [2]. The real solution for the problem of providing convenient and affordable electric vehicles is to start by recharging the batteries whenever the vehicle is parked (at the office, shopping center, home, etc). Then on the rare occasions when the car is being driven for longer distances and the battery gets flat it can be swapped for a charged battery. They have apparently designed a robot for changing car batteries, so changing the battery would be like driving through a car-wash. He describes this as an economic model that decouples the expensive battery from the car, so you pay for the use of the battery not the ownership - just as with a petrol car you pay for the petrol you use not for a portion of the ownership of an oil well. He also pointed out that cars produce 25% of the world s CO2 emissions, so his plan for all electric cars everywhere seems to be an essential part of solving the environmental problems. He then compared this to the UK parliamentary discussion on ending slavery, at the time slaves provided 25% of the energy used by the UK. After a month of discussion the decision was made to make the moral choice and end slavery regardless of the cost.

• http://blog.ted.com/2009/04/from_software_e.php


• http://www.ted.com/index.php/talks/shai_agassi_on_electric_cars.html

When Kubuntu switched to KDE4 as it s main desktop, I was disheartened. KDE 4, at the time was just, well, pretty unusable for me. It kept crashing, I couldn t do the things that I wanted to, and I spent more time fighting with KDE than I did actually doing work. After about a week, I d had enough, and I switched to Gnome. Now, a lot of people are probably going to respond to this with Gnome vs KDE flames, but let me explain my viewpoint on the whole Desktop Environment war I prefer KDE, but if a desktop will let me do the work I need to do without getting in my way and causing issues, then I can learn to use it. The above is possibly the reason that I can get along ok with Windows XP, but if I have to use Vista, I ll end up wanting to throw the machine out of the window. So, for possibly the last year or so (I m not too sure on the timescale!) I ve been using Gnome in Ubuntu, and I must say, I ve liked it. the fact that I can login, and instantly get access to my servers without having to type in my SSH key password (yes, insecure I know!), and that everything seems to integrate in a nice way, well.. it s been fun. But still, my heart lies with KDE, and I ve been flipping back to it to see how KDE4 is coming along on a regular basis. So far, I ve seen it gradually improving, and well, it looks damned sexy to be honest, but there were a few things that I felt it was missing. The ability to have multiple rows of apps on the task switcher was a big one for me. I generally have a lot of windows open, and I don t like the Grouping functionality. So when I get more than a few apps open, I could only see the icons. That s been fixed in KDE4.2, and it does it in a nicer way than Gnome does it (only switching to two rows once there are a certain amount of windows open. Next on the list is the whole password management thing. Gnome does a GREAT job at this. I login, and it unlocks the default keyring, sets up the SSH agent, adds my key, unlocking it from the keyring, and I don t have to do anything but login with my normal user and password (though I intend to switch that to biometric login once I can be bothered to setup the fingerprint reader). I ve fixed that little issue (well, for SSH) by setting up an autostart script using ksshaskpass to add my SSH key when I login. So far, KDE seems pretty usable for me now, but then, I m quite happy to plod along on my Laptop and try things out. I m feeling a bit lost with all the new functionality, and wishing that the Ubuntu Gnome Notifications (from pidgin, which I use as my IM client) didn t look so ugly in the new sexy KDE Desktop (in fact, if anyone knows a way to get pidgin to use the Jaunty style notifications in KDE, let me know, as they d fit in quite well under the new KDE look :D) - I d like to see some sort of common ground for notifications across the desktops, but who knows when that s going to happen! I ll also try using it at work, if I can use it there without it getting in the way, then I will happily switch back permanently, but that s the ultimate test. I m pretty sure that KDE 4 will be usable for me soon, and I ll let you know if that s now

xmodmap has long been the only way to modify the keyboard map of the X server, short of the complex configuration daemon approaches used by the large desktop managers, like KDE and GNOME. But it has always been a hack: it modifies the X keyboard map and thus requires a baseline to work from, kind of like a patch needs the correct context to be applicable. Worse yet, xmodmap weirdness required me to invoke it twice to get the effect I wanted. When the recent upgrade to X.org 7.4 broke larger parts of my elaborate xmodmap configuration, I took the time to finally ditch xmodmap and implement my modifications as proper xkb configuration.

Background information I had tried before to use per-user xkb configuration, but could not find the answers I want. It was somewhat by chance that I found Doug Palmer s Unreliable Guide to XKB configuration at the same time that Julien Cristau and Matthew W. S. Bell provided me the necessary hints on the #xorg/irc.freenode.org IRC channel to get me started. The other resource worth mentioning is Ivan Pascal s collection of XKB documents, which were instrumental in my gaining an understanding of xkb. And just as I am writing this document, Debian s X Strike Force have published their Input Hotplug Guide, which is a nice complement to this very document you are reading right now, since it focuses on auto-configuration of xkb with HAL. The default xkb configuration comes with a lot of flexibility, and often you don t need anything else. But when you do, then this is how to do it:

Installing a new keyboard map The most basic way to install a new keyboard map is using xkbcomp, which can also be used to dump the currently installed map into a file. So, to get a bit of an idea of what we ll be dealing with, please run the following commands:

xkbcomp $DISPLAY xkb.dump
editor xkb.dump
xkbcomp xkb.dump $DISPLAY

The file is complex and large, and it completely went against my aesthetics to simply edit it to have xkb work according to my needs. I sought a way in which I could use as much as possible of the default configuration, and only place self-contained additional snippets in place to do the things I wanted done differently. setxkbmap and rule files Thus began my voyage into the domain of rule files. But before we dive into those, let s take a look at setxkbmap. Despite the trivial invocation of e.g. setxkbmap us to install a standard US-American keyboard map, the command also takes arguments. More specifically, it allows you to specify the following high-level parameters, which determine the sequence of events between key press and an application receiving a KeyPress event:

• Model: the keyboard model, which defines which keys are where
• Layout: the keyboard layout, which defines what the keys actually are
• Variant: slight variantions in the layout
• Options: configurable aspects of keyboard features and possibilities

Thus, with the following command line, I would select a US layout with international (dead) keys for my Thinkpad keyboard, and switch to an alternate symbol group with the windows keys (more on that later):

setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch

In many cases, between all combinations of the aforementioned parameters, this is all you ever need. But I wanted more. If you append -print to the above command, it will print the keymap it would install, rather than installing it:

% setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch -print
xkb_keymap  
  xkb_keycodes    include "evdev+aliases(qwerty)"        ;
  xkb_types       include "complete"     ;
  xkb_compat      include "complete"     ;
  xkb_symbols     include "pc+us(intl)+inet(evdev)+group(win_switch)"    ;
  xkb_geometry    include "thinkpad(us)"         ;
 ;

There are two things to note:

1. The -option grp:win_switch argument has been turned into an additional include group(win_switch) on the xkb_symbols line, just like the model, layout, and variant are responsible for other aspects in the output.
2. The output seems related to what xkbcomp dumped into the xkb.dump file we created earlier. Upon closer inspection, it turns out that the dump file is simply a pre-processed version of the keyboard map, with include instructions exploded.

At this point, it became clear to me that this was the correct way forward, and I started to investigate those points in order. The translation from parameters to an xkb_keymap stanza by setxkbmap is actually governed by a rule file. A rule is nothing more than a set of criteria, and what setxkbmap should do in case they all match. On a Debian system, you can find this file in /usr/share/X11/xkb/rules/evdev, and /usr/share/X11/xkb/rules/evdev.lst is a listing of all available parameter values. The xkb_symbols include line in the above xkb_keymap output is the result of the following rules in the first file, which setxkbmap had matched (from top to bottom) and processed:

! model         layout              =       symbols
  [...]
  *             *                   =       pc+%l(%v)
! model                             =       symbols
  *                                 =       +inet(evdev)
! option                            =       symbols
  [...]
  grp:win_switch                    =       +group(win_switch)

It should now not be hard to deduce the xkb_symbols include line quoted above, starting from the setxkbmap command line. I ll reproduce both for you for convenience:

setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch
xkb_symbols     include "pc+us(intl)+inet(evdev)+group(win_switch)"    ;

A short note about the syntax here: group(win_switch) in the symbols column simply references the xkb_symbols stanza named win_switch in the symbols file group (/usr/share/X11/xkb/symbols/group). Thus, the rules file maps parameters to sets of snippets to include, and the output of setxkbmap applies those rules to create the xkb_keymap output, to be processed by xkbcomp (which setxkbmap invokes implicitly, unless the -print argument was given on invocation). It seems that for a criteria (option, model, layout, ) to be honoured, it has to appear in the corresponding listing file, evdev.lst in this case. There is also evdev.xml, but I couldn t figure out its role.

Attaching symbols to keys I ended up creating a symbols file of reasonable size, which I won t discuss here. Instead, let s solve the following two tasks for the purpose of this document:

1. Make the Win-Hyphen key combination generate an en dash ( ), and Win-Shift-Hyphen an em dash ( ).
2. Let the Caps Lock key generate Mod4, which can be used e.g. to control the window manager.

To approach these two tasks, let s create a symbols file in ~/.xkb/symbols/xkbtest and add two stanzas to it:

partial alphanumeric_keys
xkb_symbols "dashes"  
  key <AE11>  
    symbols[Group2] = [ endash, emdash ]
   ;
 ;
partial modifier_keys
xkb_symbols "caps_mod4"  
  replace key <CAPS>  
    [ VoidSymbol, VoidSymbol ]
   ;
  modifier_map Mod4   <CAPS>  ;
 ;

Now let me explain these in turn:

1. We used the option grp:win_switch earlier, which told xkb that we would like to use the windows keys to switch to group 2. In the custom symbols file, we now simply define the symbols to be generated for each key, when the second group has been selected. Key <AE11> is the hyphen key. To find out the names of all the other keys on your keyboard, you can use the following command:

   xkbprint -label name $DISPLAY -   gv -orientation=seascape -
   
   

   I had to declare the stanza partial because it is not a complete keyboard map, but can only be used to augment/modify other maps. I also declared it alphanumeric_keys to tell xkb that I would be modifying alphanumeric keys inside it. If I also wanted to change modifier keys, I would also specify modifier_keys. The rest should be straight-forward. You can get the names of available symbols from keysymdef.h (/usr/include/X11/keysymdef.h on a Debian system, package x11proto-core-dev), stripping the XK_ prefix.
2. The second stanza replaces the Caps Lock key definition and prevents it from generating symbols (VoidSymbol). The important aspect of the second stanza is the modifier_map instruction, which causes the key to generate the Mod4 modifier event, which I can later use to bind key combinations for my window manager (awesome).

The easiest way to verify those changes is to put the setxkbmap -print output of the keyboard map you would like to use as a baseline into ~/.xkb/keymap/xkbtest, and append snippets to be included to the xkb_symbols line, e.g.:

"pc+us(intl)+inet(evdev)+group(win_switch)+xkbtest(dashes)+xkbtest(caps_mod4)"

When you try to load this keyboard map with xkbcomp, it will fail because it cannot find the xkbtest symbol definition file. You have to let the tool know where to look, by appending a path to its search list (note the use of $HOME instead of ~, which the shell would not expand):

xkbcomp -I$HOME/.xkb ~/.xkb/keymap/xkbtest $DISPLAY

You can use xev to verify the results, or just type Win-Hyphen into a terminal; does it produce ? By the way, I found xev much more useful for such purposes when invoked as follows (thanks to Penny for the idea):

xev   sed -ne '/^KeyPress/,/^$/p'

Unfortunately, xev does not give any indication of which modifier symbols are generated. I have found no other way to verify the outcome, other than to tell my window manager to do something in response to e.g. Mod4-Enter, reloaded it, and then tried it out.

Rules again, and why I did not use them in the end Once I got this far, I proceeded to add option-to-symbol-snippet mappings to the rules file, and added each option to the listing file too. A few bugs [[!debbugs 524512 desc=later]], I finally had setxkbmap spit out the right xkb_keymap and could install the new keyboard map with xkbcomp, like so:

setxkbmap -I$HOME/.xkb [...] -print   xkbcomp -I$HOME/xkb - :0

I wrote a small script to automatically do that at the start of the X session and could have gone to play outside, if it hadn t been for the itch I felt due to the entire rule file stored in my configuration. I certainly did not like that, but I could also not find a way to extend a rule file with additional rules. When I looked at the aforementioned script again, it suddenly became obvious that I was going a far longer path than I had to. Even though the rule system is powerful and allows me to e.g. automatically include symbol maps to remap keys on my Thinkpad, based on the keyboard model I configured, the benefit (if any) did not justify the additional complexity. In the end, I simplified the script that loads the keyboard map, and defined a default xkb_keymap, as well as one for the Thinkpad, wich I identify by its fully-qualified hostname. If a specific file is available for a given host, it is used. Otherwise, the script uses the default.

This is a continuation from before. Before I go plunging into writing code for a generic vcs-pkg implementation, I wanted to take a close look at my current, working, non-generic implementation: making sure that the generic implementation can support at least this one concrete work-flow will keep me grounded. One of the features of my home grown porcelain for building package has been that I use a fixed layout for all the packages I maintain. There is a top level directory for all working trees. Each package gets a sub-directory under this working area. And in each package sub-directory, are the upstream versions, the checked out VCS working directory, and anything else package related. With this layout, knowing the package name is enough to locate the working directory. This enable me to, for example, hack away at a package in Emacs, and when done, go to any open terminal window, and say stage_release kernel-package or tag_releases ucf without needing to know what the current directory is (usually, the packages working directory is several levels deep /usr/local/git/debian/make-dfsg/make-dfsg-3.91, for instance. However, this is less palatable for a generic tool imposing a directory structure layout is pretty heavy. And I guess I can always create a function called cdwd, or something, to take away the tedium of typing out long cd commands. Anyway, looking at my code, there is the information that the scripts seem to need in order to do their work.

• Staging area. This is where software to be built is exported (and this area is visible from my build virtual machine).
  • User specified (configuration)
• Working Area. This is the location where all my packaging work happens. Each package I work on has a sub-directory in here, and the working directories for each package live in the package sub-directory. Note: Should not be needed.
  • User specified.
• Working directory. This is the checked out tree from the VCS, and this is the place where we get the source tree from which the package can be built.
  • Since we know the location of the working are, if the package name is known, we can just look in the package s sub-directory in the working area.
    • For rpm based sources, look for the spec file
    • For Debian sources, locate debian/rules
  • If package name is not known, look for spec or debian/rules in the current directory, and parse either the spec file or debian/changelog.
  • If in a VCS directory, look for the base of the tree
    • tla tree-root
    • bzr info
    • git rev-parse --show cdup
    • hg root
    • You have to climb the tree for subversion
  • If you are in a debian directory, and changelog and rules files exist
  Then, look for the spec file or debian/rules in the base directory
• package name
  • User specified, on the command line
  • If in the working directory of the package, can be parsed from the spec or changelog files.
• upstream tar archive
  • Usually located in the parent directory of the working directory (the package specific sub-directory of the working area)
  • If pristine-tar is in use, given two trees (branches, commits. etc), namely:
    • a tree for upstream (default: the branch ~upstream~)
    • a tree for the delta (default: the branch ~pristine-tar~)
    The tree can be generated
  • Given an upstream tree (default: the branch ~upstream~), a tar archive can be generated, but is likely to be not bit-for-bit identical to the original tar archive.

So, if I do away with the whole working area layout convention, this can be reduced to just requiring the user to:

• Specify Staging area
• Call the script in the working directory (dpkg-buildpackage imposes this too).
• Either use pristine-tar or have the upstream tar archive in the parent directory of the working directory

Hmm. One user specified directory, where the results are dumped. I can live with that. However, gitpkg has a different concept: it works purely on the git objects, you feed it upto three tree objects, the first being the tree with sources to build, and the second and third trees being looked at only if the upstream tar archive can not be located, and passes the trees to pristine tar to re-construct the upstram tar. The package name and version are constructed after the source-tar archive is extracted to the staging area. I like the minimality of this. This is continued here.

And while I'm on the subject of bitching about hardware support, I had some time to poke at the Qualcomm Gobi hardware a bit more last week. With the aid of Dan Williams of Network Manager fame we identified[1] that the hardware actually does rather more than is obvious from the qcserial driver. There's two extra ports - one is for diagnostics, and the other claims to be an NMEA port. Poking support for these into qcserial is easy enough, but they don't seem especially chatty. The more interesting factor is that the fourth interface on the endpoint is a network device. This isn't unusual in modern hardware - PPP isn't a terribly helpful layering for data transfer, so most recent high speed data cards also provide support for some kind of network device. If you're lucky it's a spec-compliant cdc device. If you've got a gobi then it claims to be a vendor defined class and type and the .inf file for the driver claims that it's a proprietary cdc device. Testing this got cut short by us not actually having an account on Verizon[2], so we don't have any data dumps to work out what the framing looks like.

Interestingly, doing USB dumps revealed that Windows seemed to do everything via the network device. We didn't see any traffic from the other ports, even when attempting to turn on the GPS. So it may also have some magic out of band configuration that doesn't simply use AT commands.

If anyone has this stuff working under Windows, it'd be interesting to try getting some dumps to try to work out what's going on here.

[1] By the simple process of opening the device manager under Windows. Ahem.

[2] The test machine was a Vaio P, which came with a gobi but no SIM slot. Thanks, Sony. Thony.

There's been a lot of questions about the new input system (referred to as "input-hotplug" or "i-h") that we've enabled in the latest X upload. Questions range from "how do I configure my keyboard now?" to "why are you making me install all this other stuff I didn't have before?" While the XSF has been dealing mainly with bug triage for the software itself, we've also been wanting some documentation on the system so people can understand it.

Thus was born our Input Hotplug Guide. The first portion of the doc explains the rationale behind input-hotplug and how it works. The second section is a HOWTO, explaining how to configure it. Hopefully this will answer some of the questions that are out there right now. So if you're curious or just plain frustrated with the changes happening to the X server's input subsystem I recommend that you check it out.

LVM can be a virtue. However, it can also be a pain at times; for instance, there's loss of diskspace due to LVM's metadata that needs to be stored as well. This amounts to approximately 5% of the diskspace (if I'm not mistaken), which can be quite a bit. Also, this is an extra abstraction layer, which requires memory and CPU time to be processed. This will be negligable on most modern computers, but sometimes it isn't. I had a system that had quite a few things on LVM, and wanted to get rid of them. Unfortunately, to remove the LVM physical volumes would mean that I'd have to get rid of the data, which would mean storing it somewhere else, which in turn would probably mean that I wouldn't be able to use the system for quite a long time. That wasn't acceptable. So, instead, what I did was to export a whole hard disk (one with enough space to hold the logical volumes on that machine) using NBD, and migrate stuff that way:

• First, set up the NBD export. The config file should look something like this:

[generic]
	user = nbd
	group = disk
[export]
	exportname = /dev/hde
	port = 1234

This will export all of /dev/hde on port 1234. Obviously you wouldn't want to do this on an untrusted network, but that's always true with NBD (in my case, the link was a 1M crossed cable -- quite safe).
• Next, we'll connect the client:

nbd-client <server> 1234 /dev/nbd0

... assuming /dev/nbd0 is not in use yet. Provided the client machine is running kernel 2.6.26 or newer and nbd-client 2.9.10 or later (e.g., Debian Lenny or later), and you're running udev, this will create a number of /dev/nbd0pX device nodes, with X starting at 1, one for each partition on the disk. Of course, one can also export a specific partition rather than the whole disk, or just one file on a filesystem, or create a physical volume of the entire disk rather than just a partition -- your choice.
• Now we need to add the networked block device to the LVM volume group. Assuming the second partition is the one we want to use:

pvcreate /dev/nbd0p2
vgextend /dev/<vg> /dev/nbd0p2

If you now run 'vgdisplay', you'll see that the size of the LVM volume has increased considerably.
• Next, we'll want to move data over the network. Assuming the 'local' LVM volume is on /dev/sda7:

pvmove -v /dev/sda7

This will show progress information every 15 seconds while the data is being moved from the local hard disk to the NBD device. You'll be able to continue using the system as usual--although of course the system will gradually get slower and slower as more and more data is only available through a comparatively slow network connection.
• Once everything's moved to the other sytem, you're all set to change stuff locally:

vgreduce -a /dev/<vg>
cfdisk /dev/sda
...

• Finally, you'll need to move the data from the NBD device back to the local hard disk. If you're still using LVM, that can be done using another pvmove operation. If not, you'll have to do something else, like cp -a. Obviously in that case, there will be some time in which you won't be able to use the system properly.

This final step might not be as simple as it sounds; e.g., if your /home filesystem is on LVM currently and you want to move that out of LVM, you'll have to make sure only root is logged on; If /var is on LVM, too, you may have to go to single-user; etc. Figuring out the details for this one is left as an exercise to the reader. However, I will note that since somewhere between etch and lenny, doing root-on-NBD is possible; and if you're running unstable, then doing root-on-LVM-on-NBD should be possible, too, although I would suggest a little caution before trying that. In any case, using NBD in this way just saved me a whole lot of no-computer-time here. Which is great.

Reportbug-NG s ability to filter and sort bugreports in various ways can greatly help triaging bugreports after a certain criterion. In this example I use the bugs of the KDE team, because they have quite a lot of bugs and are currently on a bug triage. Two releases ago I tried to help them cleaning their BTS from obsolete bugeports. My tactic back then was to find bugreports where no action has been taken for a long time. I noticed that there was no easy way to find such bugs since neither reportbug nor the BTS allowed to sort the bugs this way, so finding the candidates I searched for was very cumbersome. So let s try to find those bugs with rng: To get all bugs belonging to the KDE team start rng with the maintainer as argument:
rng debian-qt-kde@lists.debian.org
After rng started you see a table with all bugreports against the packages of the KDE team. To find potentially solved or unreproducible bugs, click on the last column header to sort the list by the date of the last action. The date of the last action is the date where the bugreport received it s last mail (including control@b.d.o mails). You will see that there are quite a lot bugs which haven t been touched for more than two years. Many of them don t have a unreproducible or moreinfo tag. If you want to help the KDE team, you can now start trying to reproduce the bug. If that s not possible you can tag them with moreinfo and unreproducible. If there is no reply in roughly one month or so it s probably safe to close this bug. To quickly find a lot of other candidates to close one can use the filter of rng. Just enter moreinfo in the filter and the table will reduce to all bugreports containing this word or tag. Now you can again sort this list by date of last action and you will see quite a lot bugs bugs where more info was requested but no action took place for more than one year. Those need to be inspected, but probably quite a few of them are safe to close. This example shows how filtering and sorting can greatly help to find certain bugs and support bug triaging. But please: don t carelessly close very old bugs! Read the reports and try to reproduce them, find matching bugreports in upstream s BTS and ask the submitter if in doubt.

This sunday, the 19th of april, at 11 CEST, I will start work my way thru many open filed against KDE in the Debian Bug Tracking System that really belongs at bugs.kde.org - or just doesn t apply anymore. Feel free to join in in #debian-kde on irc.debian.org aka oftc. See you there.

For a research project, I'm looking for some real-world time series data. Time-series are an interesting thing to study, however it is hard to get access to interesting non-trivial real-world data.I was wondering if some people could contribute me some summarized web access data; no URLs or IP addresses.The data I'd like to get can best be explained by the preprocessing step:

...   perl -ne '/\[(\d+\/\w+\/\d 4 :\d\d):\d\d/
&& print $1."\n";'   sort   uniq -c

(Sorry if you aren't fluent in regexp - it extracts the date and hour out of an Apache default log file, nothing else. These lines are then summarized by counting their unique appearances.)That should produce 24 lines per day (one per hour), looking like this:

  count day-of-month/month/year:hour

It would be cool if you could send me some series for a couple of sites, if you happen to be in the position to provide this data. The data should cover at least a few weeks, the longer the better even up to a few years.Too small sites are however not very useful but might be too noisy (so probably not the personal home page of your mom). If you are providing a larger number of series, you are of course free to include them.I don't care much about what the site actually contains, I'd just ask you to give a tiny amount of meta information:

• Server timezone if not UTC
• Typical user timezone (if applicable, that mostly applies to 'regional' sites)
• Coarse classification of site (e.g. "product website", "web service", "search engine", "company site", "OSS software site" or something like that ...)
• Redistribution permission (if possible; most likely I'll only use data series where redistribution is allowed, since some conferences ask you kindly to provide such material)
• Your email address will be withheld, to increase anonymity of the data

Data use:The main project idea is to evaluate different distance metrics in their capability of separting the different data sources, assuming that there is some difference in the shape in these curves. A different problem can be constructed by breaking the series into chunks covering approximately a day and then trying do separate different days, starting hours of the series (or offset server timezone vs. user timezone) and/or weekdays from weekends.In our experiments, we've come to the conclusion that the experimental results are most interesting when there is a sufficient number of classes; so I'd like to get like 20 different interesting data series. At the same time, the series should be long enough, so I can break them into multiple chunks to have a reasonable number of 'sub-series' per class. If I have really long series, or e.g. series covering the same site but from multiple servers, I could even experiment with taking sample of different length from these sets.(Say I have series covering 2 years, that is ~17k samples, from 3 servers, then I can take 51 disjoint sub-series of length 1000, or 102 of length 500, ...)But it's obviously not possible for me to collect this data myself - I don't operate two dozen of such sites myself ...An extra project I've been considering some time is some peak prediction for web accesses. Say you're running some fast growing site, wouldn't it be useful to have a prediction when the number of accesses will likely hit some magical limit (and e.g. overload your server) so you can increase your capacity on time? Of course it would be more sensible to apply this prediction e.g. onto CPU usage, e.g. predicting when your system might hit 90% load average over a 5 minute window in regular operation. Network bandwidth and disk IO also come into mind. You get the idea.Please send them via email to erich.schubert AT gmail comThank you.[P.S. Already recieved the first series, thank you! I can take care of sorting myself, no need to worry about that. And yes, I'm aware that the series will probably all be quite similar - common computer usage patterns such as work hours - but that is common in real world data and part of the challenge. Separting apples from dinosaurs is not a challenge.]

Drivel 2.0.4 ("Alive again")
============================

* Improvements:
- Add current patches from Debian and Ubuntu
- Add patches from bugzilla that have accumulated since 2.0.3
- New member of upstream team: Neil Williams
- Add tag support for LiveJournal. Closes #307967

* Translation updates:
- Added Italian translation (Vincenzo Campanella)
- Updated Germann translation (Mario Bl ttermann)
- Updated Portuguese translation. (Am rico Monteiro)
- Updated Canadian English translation. (Adam Weinberger)
- Updated Nepali translation. (Basanta shrestha)
- Updated Portuguese translation. (Miguel Figueiredo)
- Updated Russian translation. (Yuri Kozlov)

Drivel 2.0.4-1 has also arrived in Debian unstable - Ubuntu will update in due course but there's an Ubuntu release to get out before then (I assume).

http://incoming.debian.org/drivel_2.0.4-1_amd64.changes

Description:
drivel - Blogging client for the GNOME desktop
Closes: 465805 521452 521903 522335 522661 523425
Changes:
drivel (2.0.4-1) unstable; urgency=low
.
* New upstream release.
* [INTL:ru] Russian program translation update (Closes: #521452)
* [INTL:pt] Updated Portuguese translation (Closes: #521903)
* Update Standards Version (no changes)
* Drop previous patches and dpatch support, patches implemented
upstream.
* Switch to libcurl4-gnutls-dev instead of libcurl4-openssl-dev
to avoid linked against OpenSSL (Closes: #522335)
* Add LiveJournal tags support (Closes: #465805)
* [INTL:ru] Russian program translation update - added string
(Closes: #522661)
* [INTL:it] New Italian translation (Closes: #523425)
* Add gnome-doc-utils to build-depends

I have been involved in vcs-pkg.org since around the time it started, a couple of years ago. The discussion has been interesting, and I learned a lot about the benefits and disadvantages of serializing patches (and collecting integration deltas in the feature branches and the specific ordering of the feature branches) and maintaining integration branches (where the integration deltas are collected purely in the integration branch, but might tend to get lost in the history, and a fresh integration branch having to re-invent the integration deltas afresh). However, one of the things we have been lax about is getting down to brass tacks and getting around to being able to create generic packaging tools (though for the folks on the serializing patches side of the debate we have the excellent quilt and the topgit packages). I have recently mostly automated my git based work-flow, and have built fancy porcelain around my git repository setup. During IRC discussion, the gitpkg script came up. This seems almost usable, apart from not having any built-in pristine-tar support, and also not supporting git submodules, which make is less useful an alternative than my current porcelain. But it seems to me that we are pretty close to being able to create a distribution, layout, and patch handler agnostic script that builds distribution packages directly from version control, as long as we take care not to bind people into distributions or tool specific straitjackets. To these ends, I wanted to see what are the tasks that we want a package building script to perform. Here is what I came up with.

1. Provide a copy of one or more upstream source tar-balls in the staging area where the package will be built. This staging area may or may not be the working directory checked out from the underlying VCS; my experience has been that most tools of the ilk have a temporary staging directory of some kind.
2. Provide a directory tree of the sources from which the package is to be built in the staging area
3. Run one or more commands or shell scripts in the staging area to create the package. These series of commands might be very complex, creating and running virtual machines, chroot jails, satisfying build dependencies, using copy-on-write mechanisms, running unit tests and lintian/puiparts checks on the results. But the building a package script may just punt on these scripts to a user specified hook.

The first and third steps above are pretty straight forward, and fairly uncontroversial. The upstream sources may be handled by one of these three alternatives:

1. compressed tar archives of the upstream sources are available, and may be copied.
2. There is a pristine-tar VCS branch, which in conjunction with the upstream branch, may be used to reproduce the upstream tr archive
3. Export and create an archive from the upstream branch, which may not have the same checksum as the original branch

The command to run may be supplied by the user in a configuration file or option, and may default based on the native distribution, to dpkg-buildpackage or rpm. There are a number of already mature mechanisms to take a source directory and upstream tar archive and produce packages from that point, and the wheel need not be re-invented. So the hardest part of the task is to present, in the staging area, for further processing, a directory tree of the source package, ready for the distribution specific build commands. This part of the solution is likely to be VCS specific. This post is getting long, so I ll defer presenting my evolving implementation of a generic vcs-pkg tool, git flavour, to the next blog post. This is continued here.