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!

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.

/tmp/lab announces the second Hacker Space Festival
(Paris, 26-30 June 2009) Hacker Space Festival 2009 Call For Proposals HSF2009 In 2008, we organized HSF[1] on the spot, as an ad-hoc meeting for
hackerspaces-related networks, technical and artistic research emerging
from them and social questionning arising from them. This sudden
experiment proved to be a huge success, as much as on the
self-organizing level as on the participants and meetings quality, as
well as the emotionally-charged ambient, the kind of which you make
fond memories. The 2008 edition generated a strong emulation in France, from its
historical role as the first official hack meeting there, and in Europe
with the subsequent creation of the Hacker Space Brussels[2], the
rapprochement with The Fiber in Amsterdam and the hackerspaces.org[3]
network. Initiatives of hackerspace openings in Grenoble or Lille, or
the upcoming FrHack[4] conference show an actual enthusiasm in the
French hackers community that was doomed to the underground not so
long ago. We salute these initiatives and their diversity! Soon enough, we wanted to reiterate the HSF experience : however, it
was out of the question to institutionalize this temporary autonomous
zone, nor make it an ersatz of the previous edition, nor even to wrap
it into an elite or underground aura. On the opposite, we ardently
desire; and especially to explore further, in all directions some
lesser known domains (see below) et foster meeting and sharing around
experiences at the confluence of art, technology and politics. The world financial crisis, the decay of democracy in Europe, the
obscurantism, paranoia and lack of culture presiding over legislation
(Internet and Reaction Err Creation Law[5][6]) seem a fertile
environment for the sensible development of new (social ) life forms.
Quick! Let s rest for a few days in jubilation and ecstasy to take a
deep breathe of freedom under the indelicate smells of the medicine
factory nearby! For if the public space is shrinking to oblivion, where any side-step
becomes suspect, and that, from an early age (deviant behavior
detection in nursery school), where moving without a mobile phone
becomes suspect (hello you Julien Coupat[7], a French political
prisoner in France!), there s a domain that the Leviathan would have a
lot of trouble to contain, and for a reason: that of sensitivity. Even
the desperate attempts of the State to block the free and premonitory
expression of sense (hello you Demeure du Chaos![8]) cannot do anything
against a loud laughter or a knowing glance, a sensual kiss or an
explosion of colors. Sensitivity, we could say, is what is left to a human being when she
has nothing anymore, and differenciates her from the body corporate or
the institution, that are, in essence, devoid of it. Therefore, Art
definitely remains the public space to share between humans, and only
between us. And if it the last one to share, we propose to explore it
and take it over during the upcoming edition of the Hacker Space
Festival, from the 26th to 30th of June, 2009 at Vitry sur Seine[9]. ========================================================================
Keynote Speakers: Sergey Grim and Larry Fake with Eric Schmoudt
Groogle Summer of Crode, Survivor style
VLC, I vote against you because you really fucked up when ========================================================================
== W A N T E D ========================================================= Focus on solutions rather than problems. * The Final (Hardware) Frontier: Open FPGA Cores, Reverse Engineering
* Designer Religions and Creative Beliefs Systems
* WiFiDoors & WiFi System-on-Chip controllers firmware hacking,
infection & backdooring
* Telecom Core Network Equipment Reverse Engineering: MSC, STP,
Switches,
* Algebraic Attacks and Modern Cryptography Attacks
* Autonomous, Parasitic and Viral Drones
* Enhanced or Infected Reality Swarms
* Auto-Builders / Self-Fabrication
* Embedded OS breakins stories & recipes
* Actualization rather than mere concepts
* FPGA & ASIC hacking / backdooring
* Cloud+Privacy+Open Source: O Brave New World?
* Explosion-Proof clothing
* Radio Appz & Hackz: Mesh @ RF Layer 1-3
* Database & Privacy
* Problematic & Ethical Open Source/Content Licenses
* Institutional Relationships: Lobbying or Licking?
* Non Lethal Protection (anti-taser vests?)
* Survival in the Age of the Ministry of Immigration and National
Identity
* Mental asylum improvised visit
* Open Source Legacy Media(TM) Production Solutions (TV, Radio, Press,
DRM)
* Gas Sensors & Environmental Benchmarking
* Building Hackerspaces Without Money
* Milsatcomm hacking: Military satellites shots, broken birds in the
sky
* Other research topics on security and insecurity
* Academics and Hackers
* Organics and Fermentation
* Clean Food in Tainted Environment
* Low Impact Energy & Recycling
* Media Sandwich: layers of crap makes good food?
* Deconstructing Carla Sarkozy
* Knitting DIY Factory (jazzy, eh?)
* Signs of life among industrial wasteland
* Hallucinogenic & Computing: Can you Code on Acid?
* Mesh Networking (Wireless BattleMesh Royal!)
* Legal Sabotage: When Democracy Needs You And anything that does not fit. ========================================================================
== P R O P O S E ======================================================= Send you contributions to HSF2009-CFP@lists.tmplab.org + Type of the proposal: 1. conference (45min. presentation + 10min. for questions)
2. workshop / demo (30min. 2 heures)
3. installation / performance (music, plastic, sound, video) Lightning talks can be proposed and organized until the last moment,
according to available space and schedule, in the form of BarCamps or
Blitz Conferences. + Required Information: * Title of the presentation
* Type (see above)
* Language : French or English
* Name of speaker(s)
* Affiliation (organization / company)
* Short biography
* Abstract (5 to 10 lines)
* Topics / Keywords
* Includes a demo? YES NO
* Release during the festival? YES NO
* Internet connection required? YES NO + Acceptable Formats * Open Document
* PDF
* Plain Text
* RTF + Agenda * beginning of proposals : now
* end of proposals : 01 May 2009
* selection notification : 07 May 2009
* publication of program : 15 May 2009 + Evaluation criteria for proposals: 1. Innovating Topic
2. Open Technology
3. Demonstration / Live Act
4. DIY Reproducibility
5. Fun Potential The Programming Committee resembles that of last year
See : http://hackerspace.net/committee ========================================================================
== V E N U E =========================================================== /tmp/lab
6 Bis rue Leon Geffroy
94400 Vitry sur Seine
France http://hackerspace.net/directions ========================================================================
== P A R T I C I P A T E =============================================== Email : http://lists.tmplab.org/listinfo.cgi/hsf2009-talk-tmplab.org
CFPmail: HSF2009-CFP@lists.tmplab.org
IRC : irc://irc.freenode.net/frlab
Jabber : xmpp:hsf2009@space.cepheide.org?join
Wiki : http://hackerspace.net/hsf2009 ========================================================================
== L I N K S =========================================================== The CFP is available online at http://hackerspace.net/cfp [1] http://hackerspace.net/hsf2008
[2] http://hsb.wikidot.com/
[3] http://hackerspaces.org/
[4] http://www.frhack.org/
[5] http://jaimelesautistes.fr/
[6] http://laquadrature.net/
[7] http://fr.wikipedia.org/wiki/Julien_Coupat
[8] http://www.demeureduchaos.org/
[9] http://hackerspace.net/
Philippe Langlois
Email: philippelanglois@free.fr
PGP Key: 8DAEE244

Due to the later date of easter this year we had a rather long season this year. I started snowboarding on 2008-12-06 and stopped today 2009-04-19. Following up on previous entries here is the balance sheet:

	2005/06	2006/07	2007/08	2008/09
number of (partial) days	25	17	29	37
Dam ls	10	10	5	10
Diedamskopf	15	4	24	23
Warth/Schr cken	0	3	0	4
total meters of altitude	124634	74096	219936	226774
highscore	10247m	8321m	12108m	11272m
# of runs	309	189	503	551

In the second half of the season we actually had a lot of snow, up two 130 cm down at 800m above sealevel. Complete snow cover lasted from December until mid of April. Riding was good, I did not have any major injury, my skills did not increase though. The addition of a snowboard, a SG Speed 173 to my quiver worked out well. Loads of fun and less danger in slushy conditions (nose-in) compared to the shorter slalom board. Now the waiting starts. ;-)

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.

Irma and Bob of CALYX information essentials wrote in:

For those interested and not able to participate in the KohaCon 09 action in Plano. Some conferees are Twittering: Cover it live or pipes. Some are blogging Some again are having their photo taken on flickr. Presentations are starting to show up on slideshare tag kohacon09 and twitter #kohacon It sounds like a great conference!

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

Update: It turns out that the original PSB code is still on the moblin site - I just failed to notice that there's two pages of git repositories. I fail. Last update is from March 2008, though.

Edited again: An up-to-date version of the drm code is available as part of the Moblin kernel SRPM - repo.moblin.com isn't obviously linked off the Moblin website, but I should have thought to find and check their source repository.

By and large, working with Intel is a pleasure. In fact, a while ago I said so in a fairly obvious way. So it's a shame that the support for Poulsbo is still an absolute fucking mess with absolutely no obvious end in sight. Intel's Moblin group (the people who seem to be closest to having responsibility for providing any public Linux support for that hardware, though it's really not clear if they've got any more say in this than I do) have a kernel team that don't want or need a git tree despite having someone who's working on forward porting the driver to modern kernels - probably a job that requires more than one person given what a godawful fucking mess the last public release was, but it'd at least be nice to see what the current state is. Especially since you don't even seem to be able to get the last public release - moblin's git repositories have been rearranged and I can't find the psb-kmod one on their gitweb any more.

The most terribly depressing thing about this is that development is clearly still happening internally. Ubuntu is still being sent tarball releases by Intel, not that the code's getting any better judging by the type of diff involved. This is made even more entertaining by the bug in question being private, leaving no indication whatsoever about what bugs this code is meant to fix or why.

Closed development, random private tarball drops to partners without any public releases or changelogs, no indication of any upstream release, kernel developers entirely unrelated to the development of the driver trying to get code merged so people can actually use the hardware they bought? I'd expect this of some random far-east vendor with no experience in working with Linux, but not a company that's consistently one of the top ten contributors to the kernel and has frequently touted their level of support. There's no meaningful support for Poulsbo. There's just a thin cardboard cutout that's been carefully placed in front of a hole filled with users' hopes and money.

Seriously Intel. Sort it the fuck out.

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.

DPL candidacy woes Well, time to face it publicly: I lost and Steve/Luk won, it is as simple as that This post is to:

• congratulate with Steve and Luk for the result, I wish you a happy and fruitful DPL term
• thanks all the people which supported me, in particular:
  • lucas, paravoid, and gismo: my candidacy started as a typical "DebConf joke"; if then it has become a reality is for friends like them insisting (or pretending :-P) I was up to the task. Actually, I'm quite happy about the result, so it was definitely worth trying!
  • all the people which contributed comments for my platform, a list in no particular order follows (in the hope of not having forgot anyone!): madduck, enrico, lucas, tbm, godog, gismo, gregoa, dato, ralf, paravoid, buxy. Thank you guys, my platform would have been much worst without your input.
  • all the people who voted for me (of course!)

All in all, standing for DPL has been worth and interesting no matter the result. Time to get back to my usual Debian duties now ...

Yay! I'm finally allowed to (and starting to) port the application I'm working on at work from Oracle to PostgreSQL. Oh, and I note that PostgreSQL 8.4 (beta out yesterday) introduces support for WITH RECURSIVE queries (closures, or for you Oracle folks, CONNECT BY, if I understand the feature correctly), the lack of which has always made tree / graph type data structures a pain to work with in current and older versions. Of course, many other improvements, too.

Do you listen to the radio? I don t, and there are multiple reasons for that: First and foremost, I don t like the music they play these days. Even though there are stations which will occasionally play a more eclectic tune, the Swiss government does not, to my knowledge, dictate any quota, like New Zealand actually requires stations to broadcast New Zealand music at least 20% of the time. The result is music made by producers, who stand pop icons with little clothing in front of microphones, instruct them to move their bodies in obscene ways, and coach them to croak songs someone else wrote en masse in some basement somewhere. All those songs sound alike. To ensure a constant supply of pop dolls, they hype television shows with titles such as Germany s seeks the next superstar , when most of Germany actually couldn t care less, and only those with vacuous brain capacity follow with excitement, because they wouldn t know what else to do. Second, I don t have the time or energy to listen to discussion rounds on the radio, especially not when topic are about society , which noone can define in the first place. Wittgenstein always had it right. The same goes for most commentaries. If I don t have anything to do, I prefer to listen to birds in the trees, rather than someone s polished opinion. The scariest aspect is that those people actually believe that they have something worthwhile to say, and so do their producers and the other staff, when in most cases, they don t. At least not worthwhile to people who have other things occupying their minds. I also don t like someone to make a pre-selection of news and squash that into 5-15 minute time slots, to be read out by dull-sounding speakers. I d rather skim over articles, and the Web ensures that I get the information I want much quicker than the radio stations can transmit them. And sports over the radio waves makes me come close to aural epileptic seizures. I am painting the sky black a bit. I am fully aware that there exist people with thought-provoking arguments, that some stations play interesting music I would otherwise never discover, and that the radio is a source of entertainment in the lives of thousands of other people who are less privileged than me. But when the Billag rang my doorbell today and wanted CHF 14,10 per month for posession of any device capable of turning radio waves into sound, including those radio waves broadcast over the Internet these days, I got a bit furious. In the past, they concentrated only on actual radio and TV receivers. When I moved into my previous flat in Zurich in 2002, they wanted money because my stereo had a tuner button. I refused to pay, opened the device, unsoldered the radio coil, and sent it to them with an angry letter of refusal; they let me off the hook. Since then, they changed the law in 2007 (but haven t actually updated the forms they force you to sign) to include audio players, cellular phones, and computers, which are all radio-capable. I d really prefer if they used their funds to revert that trend, or at least remove the loudspeakers from all mobile phones. But instead, this morning, I skid right into their claws. As I said before, the radio is also a social support system, and as such I have less of a problem to subsidise it. However, given that I strongly disagree with the quality level broadcast, I would prefer to direct my money towards causes I consider more useful, and with which I could better identify. Unfortunately, the whole system is governmentalised to the point where this choice is taken away from me. The Billag website helpfully offers answers to the common questions, including one along the lines of quality. They suggest that you get in touch directly with the programme directors to complain about their content, and offer suggestions. Shortly after I moved to Zurich, Radio Lora offered me a radio show. Radio Lora is a private station, but they also receive subsidies from the monies exacted by the government, so I am using them as an example here. I suggested that I concentrated only on progressive and psychedelic rock from the sixties and the seventies. They refused the show in the end, claiming that this would not be what their listeners want. So instead I now get to pay for content that is deemed more appropriate. I can only imagine the pains I d have to go through to be able to host a radio show concentrating on eclectic tunes on one of the public radio stations. And even if I succeeded (without becoming a full-time public radio broadcaster), then I could only contribute a few hours a week to that content. If you ask me, the Swiss government is overstepping its competencies a bit. NP: Mono: Hymn to the Immortal Wind

Over the Easter holidays, I finally did a bit of real programming again, adding some quantum chemistry related C++ code to OpenBabel and Avogadro. I added support for molecular vibrations to the NWChem and Molden file formats, as well as writing support for the MOLPRO input and output formats mostly from scratch. The latter was something I wanted to do for a long time, as I have been almost exclusively using MOLPRO for my Ph.D. over the last couple of years. The event which sparked my interest was the addition of animated vibrations in the Avogadro 0.9.3 release on April 1st, something I considered one of the last missing features in Avogadro in order for it to be useful as a general purpose quantum chemistry visualization app. Once I had started coding, I decided to also do contribute to the visualization of molecular orbitals in Avogadro. So far, it was required to have formatted Gaussian or Q-Chem checkpoint files (both seem to use the same format, but you do not usually have those around) or Mopac2000 logfiles (Mopac2000 is non-free, unlike Mopac7, which is in Debian). My patch adds support for reading orbitals from MOLPRO logfiles on top of that. It has to be said that rendering molecular orbitals (while a bit unintuitive from a GUI perspective) is really impressive in Avogadro, thanks to the work done by Marcus Hanwell. See for exampe this picture for a Povray rendered molecular orbital exported by Avogadro. If I manage to find some more time, I would like to (i) move the basis set and molecular orbital parsing code to OpenBabel, where it rightfully belongs and (ii) enhance and unify the OpenBabel quantum chemistry input file export code, so that they can be used by Avogadro directly. Right now, Avogadro reimplements a GUI and code for exporting an input file for each supported quantum chemistry package (Gaussian, Q-Chem, GAMESS and Mopac2000, currently).

SSH is really the Swiss Army pocket knife of sysadmin tools. When I needed to periodically synchronize log files from an old server (old as in customer-would-never-update-it-or-install-anything-new), I built a simple and secure solution using rsync and ssh. This is what I did: (I will call remote the system where the logs I want to retrieve are, and local system where I want them to be copied to) First I created an account with a restricted shell (ideally this should be a system account, but we ll get there!):

remote# adduser --ingroup nogroup --shell /bin/rbash rlogs

Then locally, I created a new, password-less ssh key pair, copying it to my remote system:

local$ ssh-keygen
>>> When asked where to save it, I chose a different name, like .ssh/rlogs
local$ ssh-copy-id -i .ssh/rlogs.pub rlogs@remote
...
>>> You can delete the password of user rlogs, so it, effectively,
>>> cannot log-in with it (almost like a system user).
remote# passwd -d rlogs

Now you should be able to run password-less rsync already (note that I use -e option to point to a different key):

local$ mkdir logs
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
receiving file list ... done
./
file1
file2
...
fileN

But even with a restricted shell, I wanted even less possible things to happen. That s what command= directive is for It will only allow that command to be run in a session started by that key. Since rsync translates a lot of its command-line options, I run it again with a dirty ps-in-a-loop in the remote host, just to see what running rsync locally causes remotely:

remote$ while 1; do ps wp $(pgrep rsync); sleep 1; done
...
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
>>> in the remote loop you should be able to get the command:
  PID TTY      STAT   TIME COMMAND
 6183 ?        Ss     0:00 /usr/bin/rsync --server --sender -vlogDtpre.i . logs/

Here comes the authorized_keys magic. At the remote host I edited .ssh/authorized_keys to add a command= line with what I found out in my dirty loop. Also, I added a couple of directives to restrict it even further (they are pretty self-explanatory):

rlogs@remote$ cat .ssh/authorized_keys
command="rsync --server --sender -vlogDtpre.i . logs/",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa (...) myuser@local

Now everything is set. I just added the rsync command to the local crontab and it s done.