Another month, another update to http.debian.net. This time around most of the work was done outside the redirector's code base, as strange as it may sound.

The redirector heavily relies on the mirrors doing at least a couple of things right, for the rest it can and does compensate. When it needs to compensate, certain requests are redirected to automatically-detected good mirrors, thus avoiding mirrors that might work fine for some parts of the day but cause headaches during the rest.

So, part of the work done since the last update was to prod more mirror administrators to upgrade to the latest version of ftpsync. This reduces the number of mirrors for which compensation is needed in order to avoid errors during installations and upgrades. Hopefully, no additional work is needed for the redirector to notice the upgrades. This results in immediate improvements.

However, not all mirrors comply with the bare minimum requirements. As stated in my previous blog post, running rsync once is not enough. When mirrors break these assumptions they lead to the "bad apple" effect. The effects in this case are temporary errors, as experienced by some people. The interesting part of those issues is that the affected population may quickly change given the redirector's use of geo location and the way it creates mirror subsets.

As interesting as the distribution of the effects may be, they are not really welcome. So I put together some code to attempt to detect the bad apples. This resulted in a list of mirrors that have now been disabled in the redirector and whose administrators are going to be contacted so that they comply with the minimum requirements. Given that detection is time-sensitive, there's no 100% guarantee that all of them have been identified so far. The code to detect them will have to be adapted and integrated into the redirector's code base to be proactive on avoiding this kind of issues.

Last but not least, the redirector is now using a database of AS peers for better (re-)routing. This is the next move towards a decision making based more on network location/topology than in geographic location. This first use of a peers database is limited to IPv4 and is based on a recent routing table dump and on feedback provided by interested people. If you are a mirror or network administrator, or you are familiar with the topology of your network please drop me an email so that the redirector can make a better use of your peering agreements.

N.b. in the case of the database, the term peer may also include transit providers. It is used to refer to and establish a relationship between two AS(N)s.


Feedback is, as always, welcome. I read each and every email but it may take me some time to get to it, or reply.

Next week end, November 24th and 25th, the mini Debconf will take place at EPITA in Paris. Mehdi Dogguy and I worked hard on the organization and on building a great program for this 2012 conference. This mini debconf will cover many subjects like Gnome (both as upstream and downstream), the Release team, how the Linux is packaged in Debian, etc.
The keynote will be "Free software and Debian, 20 years after" by Roberto Di Cosmo. Also, some merchandising will be proposed during the event by the association Debian France. Here is a quick list: Polos

Long-sleeved polo
40 euros - 10 pieces
Sleeveless polo
25 euros - 100 pieces Thanks to Tanguy Ortolo for taking take of the order. Buff

Buff Debian
18 euros - 75 pieces. It is described as Original Multifunctional Headwear. Real life example in video.
I love them! Finally, we will sell two kinds of Debian branded Sticker Portable:

Sticker Debian
1 euro - 100 pieces. They can be also ordered on the it2l website. Thanks to J r me Lemaire for providing these great products. If these products are successful, we will probably produce more for FOSDEM! For more information about the conference:
The official website
Wiki page for subscription

Last week, just before the branching of 3.6.4 was the peak of my recent work in LibreOffice. The motivation from attending the conference and working with others lasted long for me with the help of a few collaborations done since (thanks Caolan and Eike). My own patches were approved just in time to make it to the 3-6 branch, which, along other fixes, pretty much makes 3.6.4 a better release to the RTL users in general, and Hebrew users specifically. Things aren t perfect, but they re improving nicely (on going status is at RTL bugs wiki page). I m also very happy that most RTL related fixes since the conference have been cherry-picked from master to 3-6 branch, so the users won t have to wait till February for the 4.0 release. Last year I had to wait till the 3.5 release to see some of my work fruits, now I can see them in much shorter intervals. The motivation and involvement go hand in hand, each enhances the other for me. I ve started reviewing patches sent for RTL bugs to verify the suggested fixes with private builds and marking bugs as verified when the patches do get accepted. Compering to a month ago, I m now busy with helping the developers do their part instead of just reporting problems. Seeing things go forward (and helping them do so) is much more motivating than waiting for someone to pick the bug report and try solve it. I hope having fast response to their code changes is also motivating for the developers, in that case everyone enjoys the collaboration.
Filed under: LibreOffice

Miklos published about his LibreOffice RTF import Drawing Objects improvements which was done to fix my report (fdo#42407). As an anecdote I want to mention that he test document was my flight ticket to the LibreOffice conference in 2011. So I feel I got an extra value from attending the conference in the form of having a this RTF compatibility implemented. In addition, Miklos fixed an import problem with Hebrew with these old documents (fdo#56512) double value. Miklos I owe you a drink (: I m not sure if I should thank the traveling company for working with such old software which produced the old formatted RTF files, but in any case, it turned out to be a good thing.
Filed under: LibreOffice

Since converting the phpMyAdmin documentation to new format and updating it's content, I was quite frightened how this will affect translated versions of it. Fortunately giving it more attractive format and more advertisement lead to increased contributions. Since Friday, we already have one language which has reached 100% - Spanish. Mat as Bellone simply did there awesome job and went through all fuzzy and new strings in just few days. Now I'm looking forward to other contributors as well, I hope we will be able to deliver translated manual for phpMyAdmin 4.0 in many languages. I'll definitely try to translate to Czech, but any help with that is welcome.

Filed under: English Phpmyadmin 2 comments Flattr this!

While working on a Norwegian translation of the Free Culture by Lawrence Lessig (76% done), which cover the problems with todays copyright law and how it stifles creativity, one idea occurred to me. The idea is to get the tax office to help make more works enter the public domain and also help make it easier to clear rights for using copyrighted works. I mentioned this idea briefly during Yesterdays presentation by John Perry Barlow, and concluded that it was best to put it in writing for a wider audience. The idea is not really based on the argument that copyrighted works are "intellectual property", as the core requirement is that copyrighted work have value for the copyright holder and the tax office like to collect their share from any value controlled by the citizens in a country. I'm sharing the idea here to let others consider it and perhaps shoot it down with a fresh set of arguments. Most valuables are taxed by the government. At least here in Norway, the amount of money you have, the value of our land property, the value of your house, the value of your car, the value of our stocks and other valuables are all added together. If the tax value of these values exceed your debt, you have to pay the tax office some taxes for these values. And copyrighted work have value. It have value for the rights holder, who can earn money selling access to the work. But it is not included in the tax calculations? Why not? If the government want to tax copyrighted works, it would want to maintain a database of all the copyrighted works and who are the rights holders for a given works, to be able to associate the works value to the right citizen or company for tax purposes. If such database exist, it will become a lot easier to find out who to talk to for clearing permissions to use a copyrighted work, which is a very hard operation with todays copyright law. To ensure that copyright holders keep the database up-to-date, it would have to become a requirement to be able to collect money for granting access to copyrighted works that the work is listed in the database with the correct right holder. If copyright causes copyright holders to have to pay more taxes, they will have a small incentive to "disown" their copyright, and let the work enter the public domain. For works with several right holders one of the right holders could state (and get it registered in the database) that she do not need to be consulted when clearing rights to use the work in question and thus will not get any income from that work. Stating this would have to be impossible to revert and stop the tax office from adding the value of that work to the given citizens tax calculation. I assume the copyright law would stay the same, allowing creators to pick a license of their choosing, and also allowing them to put their work directly in the public domain. The existence of such database will make it even easier to clear rights, and if the right holders listed in the database is taxed, this system would increase the amount of works that enter the public domain. The effect would be that the tax office help to make it easier to get rights to use the works that have not yet entered the public domain and help to get more work into the public domain and . Why have such taxing not happened yet? I am sure the tax office would like to tax copyrighted work values if they could.

A minor bug-fix release 3.4.4 of Armadillo came out upstream a few days ago. RcppArmadillo, our wrapper for R and Armadillo, is now on CRAN with its corresponding version 0.3.4.4. No R level or interface changes were made and the upstream changes are summarized below.

Changes in RcppArmadillo version 0.3.4.4 (2012-11-15)

• Upgraded to Armadillo release 3.4.4
  • fix for handling complex numbers by sparse matrices
  • fix for minor memory leak by sparse matrices

Courtesy of CRANberries, there is also a diffstat report for 0.3.4.4 relative to 0.3.4.3 As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

It s likely that most people make things like comfort, style, and price the main criteria when purchasing clothes. But there are other things that can be more important such as the ability to fit a phone in the pocket. My last pair of jeans was from Rivers (one of the more affordable Australian clothing stores which also has online sales) [1]. They were the long leg version and have front pockets that are 28cm deep (measured from the bottom of the pocket to the lowest part of the lip) and 15cm wide (a 15cm ruler will barely fit sideways in the pocket). I ve just got some new jeans from Rivers which are the regular leg length, they have front pockets which are 21cm deep and slightly more than 16cm wide. The old pair could fit a Nexus 7 tablet in the front pocket. The new pair should more easily fit such a tablet in the pocket but it might be less comfortable to walk with the tablet in the pocket. I don t plan to try using my front pocket for a tablet (I d be more likely to use a backpack or my Scott e vest [2]), but a Galaxy Note 2 (which is about the largest device that most people would want in their pocket) would fit nicely. I find the Rivers jeans to be quite comfortable and I like the way they look. They also only cost $25 online or $30 in the store. When I bought my first pair before I even had a 4 phone they were good value and they will be even better value early next year when I get a bigger phone. Even though Rivers jeans may wear out faster than more expensive brands, for $30 it s easy to just buy a few pairs at a time. During an email discussion of geeky clothing the issue of women s clothes having fewer and smaller pockets was raised. Unfortunately I didn t think to measure the pockets in women s jeans when I was at the Rivers to discover whether they have big pockets too. I ll do that next time I m in the area.

• [1] http://rivers.com.au/
• [2] http://www.scottevest.com/

In case you care, there's a short discussion about when to publish this info and how it relates to DWN on the Debian publicity mailing list. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 906
  • Affecting wheezy: 401 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 258 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 41 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 7 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 213 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting wheezy only: 143 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.

How do we compare to the squeeze cycle ? Yes, how indeed. There's not automatic way to generate this data, yet. Stay tuned for now.

After my last post I got curious about booting the Macbook in EFI mode. Because, well, why not? So I googled for a while and found this blog post which served as a great reference and comment on two other. I understand EFI is somewhat buggy and what works for me might not work for you. So be careful, have a rescue disk at hand. On that topic, I should say that I could not get this to work with Debian sid s 3.2 kernel, but 3.5 from experimental worked fine for me.

Hopefully, you after booting EFI succesfully. My main question before doing this was What works? , I had heard some weird rumours and mentions that you had to run X in framebuffer mode and weird stuff like that. This is bullshit. Everything works fine, with the same standard software and setup. Features:

• GNOME Shell, hence acceleration, works
• All drivers work: wireless, bluetooth, etc.
• No need to force AHCI mode on the disk controller
• No graphic flicker during the boot process
• A feeling of catching up with the times

So, here we go. I am posting my notes in shell-like since I find little benefit in turning them into an essay or something more textual. Good luck! # Install grub-efi-$arch.
# Usually $arch depends on your processor.
# Best bet: you can use OSX to check for this:
#
# $ ioreg -l -p IODeviceTree grep firmware-abi
# It will print EFI32, or EFI64. You know what to do.
$ sudo apt-get install grub-efi-amd64 # Now we need to mount the system EFI partition for GRUB2 to install
# itself on it.
# NOTE: you have to do this, installing the package is NOT enough.
$ sudo mkdir /boot/efi
$ sudo mount /dev/sda1 /boot/efi # Did you get the right partition?
# It should have an EFI directory with an APPLE directory inside.
# DO NOT DELETE THE APPLE DIRECTORY, PRICK.
$ ls /boot/efi
EFI/
$ ls /boot/efi/EFI/
APPLE/ # Create a new directory, debian will do.
# Run grub-install so GRUB2 drops its EFI code in the new directory.
$ sudo mkdir /boot/efi/EFI/debian
$ sudo grub-install
$ ls /boot/efi/EFI/
$ ls /boot/efi/EFI/debian/ # Help rEFIt know this is a GNU/Linux boot.
# rEFIt assigns icons depending on the name of the EFI file, grub64x is not in its list
$ sudo mv /boot/efi/EFI/debian/grub64x.efi /boot/efi/EFI/debian/e.efi # IMPORTANT: Add the proper modeset.
# For EFI-only systems: efi_uga
# For UEFI systems: efi_gop
# Without this you won t have any graphics.
$ sudo vim /etc/default/grub
...
GRUB_VIDEO_BACKEND="efi_uga"
... # Update grub, reboot. Hope that everything worked.
$ sudo update-grub Extra credit
You can clean your MBR from the old GRUB2-pc installation (if you installed it to the hybryd-MBR, like a sane person) from OSX:
$ sudo fdisk -u /dev/disk(tab-to-complete, verify it is the right disk) (Read the man page for your fdisk to be sure -u still means fix MBR while keeping partitions )

Quite on updated schedule (ie. one month later than originally planned), Weblate 1.3 has been released today. It comes with lot of improvements, especially in support of non gettext files, new quality checks and improved performance. Full list of changes for 1.3:

• Compatibility with PostgreSQL database backend.
• Removes languages removed in upstream git repository.
• Improved consistency checks processing.
• Added new checks (BB code, XML markup and newlines).
• Support for optional rebasing instead of merge.
• Possibility to relocate Weblate (eg. to run it under /weblate path).
• Support for manually choosing file type in case autodetection fails.
• Better support for Android resources.
• Support for generating SSH key from web interface.
• More visible data exports.
• New buttons to enter some special characters.
• Support for exporting dictionary.
• Support for locking down whole Weblate installation.
• Checks for source strings and support for source strings review.
• Support for user comments for both translations and source strings.
• Better changes log tracking.
• Changes can now be monitored using RSS.
• Improved support for RTL languages.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you (this will be decided case by case as my hosting space is limited).

Filed under: English Phpmyadmin Weblate 0 comments Flattr this!

As I've mentioned before, there was a keysigning party in Prague yesterday. Though we were afraid that not so many people will arrive, in the end I have signed 19 keys and assured 13 people for CAcert. The nice outcome of this is that I can now give up to 25 points when assuring for CAcert and altogether we are able to give you over 50 points in the Prague SUSE office. Unfortunately this also reminded me my problems with Unicode on CAcert and quick look at the bug tracker showed me that my bugs 769 and 770 are still open, valid and did not receive any attention :-(. PS: Of course after key signing, we had some fun with the openSUSE beer.

Filed under: English Suse 0 comments Flattr this!

A few months ago, I wrote about my reverse engineering attempt to Logitech Unifying devices. Back then, I concluded my post with big hopes on the future after receiving a document with some part of the specification of the HID++ 2.0 from Logitech. A couple of weeks ago, some of my summer work has been merged to UPower, adding battery support for some Logitech devices. HID++ As I discovered late in my first reverse engineering attempt, Logitech developed a custom HID protocol named HID++. This protocol exists in two versions, 1.0 and 2.0. Some devices talk with version 1 of the protocol (like my M705 mouse) and some others talk with version 2 of the protocol (like my K750 keyboard). Recently, I've been able to be in touch with a Logitech engineer who worked on the Linux support for the Unifying receiver, and he has been really helpful and exposed me some details about this protocol. Logitech made the decision to publish their HID++ specification publicly about a year ago, but still didn't do it. The internal review needed to publish such documents hasn't be done yet. The only published draft is just an extract of the specification, with even some typo in it as I discovered. Some other documents have been recently published, but I didn't have the time to review them. They contains HID++ 1.0 specifications and some details I asked for about the K750 keyboard. UPower support It took me sometime to get a full understanding of the protocol, its different version etc. After reverse engineering my K750 keyboard, I've also reverse engineered the data stream used to get my M705 mouse battery status. I've also received some information about the HID++ 1.0 protocol, so I've been able to discover a bit more on what the packets mean. Most of my discoveries are now used to do proper #define in up-lg-unifying.c so the code makes more sense. My first patch implements a new property for UPower devices, named luminosity, that use with K750 keyboard to report the light level received. The second patch add support for Logitech Unifying devices (over USB only) and should work with at least Logitech M705 and K750 devices. This should be available with the next version of UPower, which should be 0.9.19. So far, Logitech has been kind enough to help me understanding part of the protocol and even sent me a few devices so I can play and test my work with them. Unfortunately, this will probably requires some work and time, and so far Logitech was not able to help with that. There should be enough information out there to at least add support for battery to HID++ 2.0 devices, and probably a few other things too. I hope I'd get the time do this at some point, but feel free to beat me in this race!

As a followup to my toy over at debtree, I ve taken some suggestions from my buddy Arno and found some time in the hotel during a visit for work up to Canada with the Open North folks hacking on open13. The hack is called debfriends (I need to purge personal details from the source tree before I can push it to VCS, since it uses the nm.d.o dump. Sorry, I should have been better about that.) I ve posted a cute front-end on my staging machine to play with over at graph.lucifer.pault.ag There s also an API, but it has all the data in the NM dump exposed. If you re a DD who will treat this data right, I can add a key (it s not secure, like, at all). I m going to publish the source ASAP so that others can stand up an instance if they d like. It s a cute toy, though! In the tradition of using nhandler for my examples, here s an example path from pabs to Nathan: pabs > nhandler

• nhandler was advocated by paultag
• paultag was advocated by mako
• micah was advocated by mako
• pabs was advocated by micah

Also, we re a shockingly well connected bunch. Well done :) Feel free to play with it!

When someone wants to give you access to a Cisco VPN, they might give you a .mobileconfig file. This is apparently used by MacOS and iOS to encapsulate the configuration parameters needed to connect to a VPN. You should be able to connect to it with open source software (such as NetworkManager and vpnc) as long as you have the right configuration. Some helpful soul has tried to give you that configuration, but it s wrapped up in an Apple-specific container. Here s how you rip it open and get the goodies. File format A .mobileconfig appears to contain:

1. Some binary garbage which is safe to ignore
2. An XML document containing the good bits, i.e.:
   1. The local identifier (i.e. IPsec group name)
   2. The remote address (i.e. IPsec gateway host)
   3. The shared secret (base64 encoded)
3. Some more binary garbage which is safe to ignore

and it looks like this:

<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>IPSec</key>
      <dict>
        <key>AuthenticationMethod</key>
        <string>SharedSecret</string>
        <key>LocalIdentifier</key>
        <string>LOCAL_IDENTIFIER_HERE</string>
        <key>LocalIdentifierType</key>
        <string>KeyID</string>
        <key>RemoteAddress</key>
        <string>REMOTE_ADDRESS_HERE</string>
        <key>SharedSecret</key>
        <data>
        BASE64_ENCODED_SHARED_SECRET_HERE
        </data>
      </dict>
      <key>IPv4</key>
      <dict>
        <key>OverridePrimary</key>
        <integer>0</integer>
      </dict>
      <key>PayloadDescription</key>
      <string>...</string>
      <key>PayloadDisplayName</key>
      <string>...</string>
      <key>PayloadIdentifier</key>
      <string>...</string>
      <key>PayloadOrganization</key>
      <string>...</string>
      <key>PayloadType</key>
      <string>com.apple.vpn.managed</string>
      <key>PayloadUUID</key>
      <string>...</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>Proxies</key>
      <dict>
        <key>HTTPEnable</key>
        <integer>0</integer>
        <key>HTTPSEnable</key>
        <integer>0</integer>
        <key>ProxyAutoConfigEnable</key>
        <integer>0</integer>
        <key>ProxyAutoDiscoveryEnable</key>
        <integer>0</integer>
      </dict>
      <key>UserDefinedName</key>
      <string>...</string>
      <key>VPNType</key>
      <string>IPSec</string>
    </dict>
  </array>
  <key>PayloadDescription</key>
  <string>...</string>
  <key>PayloadDisplayName</key>
  <string>...</string>
  <key>PayloadIdentifier</key>
  <string>...</string>
  <key>PayloadOrganization</key>
  <string>...</string>
  <key>PayloadRemovalDisallowed</key>
  <false/>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>...</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

The shared secret is base64-encoded, so you can decode it with: $ echo -n 'BASE64_ENCODED_SECRET_HERE' base64 -d Network Manager configuration

1. Make sure you have network-manager-vpnc installed
2. Click the Network Manager icon, select VPN Connections , Configure VPN
3. Create a Cisco-compatible (vpnc) connection
   
   

   Create a Cisco-compatible (vpnc) VPN connection

4. Configure the connection settings as follows:
   
   

   Configure the connection settings

   • Enter the remote address in the Gateway field
   • Enter the local identifier in the Group name field
   • Enter the shared secret in the Group password field
5. To connect, click the Network Manager icon, select VPN Connections , and select the connection you just configured

Good luck and enjoy!

A year ago I wrote in Useful but Unknown Unix Tools: How wdiff and colordiff help to choose the right Swiss Army Knife about using wdiff and colordiff together. Colordiff ed wdiff output looks like this:

$ wdiff foobar.txt barfoo.txt   colordiff
[-foo-]bar fnord
gnarz hurz quux
bla  +foo+  fasel

But if you have colour, why still having these hard to read wdiff markers still in the text? There exists a tool named dwdiff which can do word diffs in colour without textual markers and with even less to type (and without being git diff --color-words ;-). Actually it looks like git diff --color-words, just without the git:

$ dwdiff -c foobar.txt barfoo.txt
foo bar fnord
gnarz hurz quux
bla foo fasel

Another cool thing about dwdiff (and its name giving feature) is that you can defined what you consider whitespace, i.e. which character(s) delimit the words. So lets do the example above again, but this time declare that f is considered the only whitespace character:

$ dwdiff -W f -c foobar.txt barfoo.txt
foo bar bar fnord
gnarz hurz quux
bla foo fasel

dwdiff can also show line numbers:

$ dwdiff -c -L foobar.txt barfoo.txt
   1:1    foo bar fnord
   2:2    gnarz hurz quux
   3:3    bla foo fasel
$ dwdiff -c -L foobar.txt quux.txt
   1:1    foo bar fnord
   1:2    foobar floedeldoe
   2:3    gnarz hurz quux
   3:4    bla foo fasel

(coloured shell screenshots by aha)

I had a dream that many prominent members of the Linux community were dressed in Nazi SS uniforms on the Arctic ice, clubbing baby seals to death. I can t bear the thought that so many Linux people may secretly be Nazi seal murderers, so I demand that they be excluded from any future Linux-related events or conferences that I might wish to attend. My nightmare and the strength of my personal reaction to it are conclusive proof that they are guilty. I can t remember all those who were identified in my dream right now, so I need to be able to point the finger at any time in the future and have any individual shunned excluded and banned from events, conferences, mailing lists, and open source projects in general with any who communicate with them (or, worse, support the evil-doers by pretending to a moderate, reasonable, rational, and/or evidence-based stance) being likewise exiled. After all, remember that even in these enlightened times there is still a seething culture of penguin-supremacism in the Linux community overtly pushing the agenda of the pure penguin race over the pernicious and corrosive evil of seals .this culture of seal-murder must be stamped out by whatever means necessary. Zero tolerance for seal-murder apologists! Thank you for understanding and supporting me in my very real fears. You make the world a safer place for everyone. I had a dream is a post from: Errata

Contrary to http://blog.einval.com/2012/11/13, I ve just been and voted (four times, or 2 2 one for me, one as a proxy) for a police and crime commissioner. I agree with much of what Steve writes and more besides. It s a very bad election. But I voted for three main reasons: Firstly, parties I don t like will get their core vote out anyway. If we don t turn put, the election becomes more about party structures, less the popular wish. Secondly, democracy is imperfect, but it s the best we ve got. I ve interacted with two appointed police authorities and they re rubbish and they re untouchable/unaccountable. Thirdly, I expect policing to be a hot topic here if the government do actually try to build the incinerator that 65,000 people/90+% voted against. Best try to get a non-gov commissioner now, I think. So that s why I ve voted and encouraged other members of our co-op to vote.

No sooner had Henrique de Moraes Holschuh announced the availability of improved microcode updating in Wheezy (sadly non-free) than Stephan Seitz pointed out that this support was broken for systems running Xen, which is unfortunate since as Henrique notes the impact of not applying such an update could be pretty much anything. There's a bit of a saga here: a patch has been available for several years which adds Xen support to the kernel's microcode driver in a nicely self contained way. However the Linux maintainers have decided that loading microcode from the kernel is too late and it should be done earlier (e.g. by the bootloader, or some shim between the bootloader and the kernel) in order to be effective and on that basis rejected the Xen patch implementing the existing kernel based scheme. In the meantime Xen has implemented early loading of microcode via an additional multiboot module passed by the bootloader and this was released in Xen 4.2 in September. (so far I've not seen any progress on making any change to the native side but that's by the by). However Wheezy is going to be shipping with Xen 4.1 which doesn't yet have this support in it. So we are basically faced with two choices, either we backport the support from Xen 4.2 or we apply the kernel patch. The downside of backporting rather than taking the kernel patch is that the backport is non-trivial (although not totally unwieldy) while the kernel patch is pretty much entirely self-contained. The other downside of early the early loading scheme in general (for either native or Xen) is the need to update tools (e.g. update-grub) as well as modifying the microcode packaging to put the files somewhere that the bootloader can see them (so /boot). This certainly can't happen for Wheezy at this stage which basically rules out the backport approach. So, the upshot is I've filed Debian bug #693053 and applied the kernel patch to our tree. It's all a bit unsatisfactory but at least microcode loading will work for users running Xen on Wheezy. With any luck for Jessie the native early microcode loading code will have landed as well and the pain of the infrastructure updates can be shared.

As systems developer I like just being able to pick the most useful Perl modules from CPAN and preferably use quite recent versions of the modules I need. On the other hand our systems administrators prefer running Debian Stable and deploy software using .deb packages. I do not want to maintain hundred small packages by hand. I just want a single package with all needed the Perl dependencies for a given project. After looking at different possibilities for bundling Perl dependencies I finally found Carton written by Tatsuhiko Miyagawa. Given a list of your direct Perl dependencies, Carton can maintain the full dependency chain and manage which versions of each module you deploy. One of the nice features is that you get a reproducible set of versions each time and not just the latest, greatest, and recently broken versions. The initial step is to set Carton up to install the dependencies for my project. This part is done just like the Carton documentation describes. To ensure independence from whatever is available on CPAN I end by calling carton bundle. The next step is to write a small Perl module making sure you load modules from the right place. I end up with installing modules in /usr/lib/projectname. My module looks like this:

package My::Bundle::ProjectName;
=head1 NAME
My::Bundle::ProjectName - Bundle of CPAN modules used by ProjectName
=cut
our $VERSION = 1.0;
use Config;
use Carp;
use Carp::Heavy;  # Ensure that all parts of Carp are loaded before @INC mangling
use File::Spec;
our $BASE = '/usr/lib/projectname';
sub import  
    carp (__PACKAGE__ . " bundle not installed")
        unless -d $BASE;
    unshift @INC, 
        File::Spec->catdir( $BASE, 'lib', 'perl5' ),
        File::Spec->catdir( $BASE, 'lib', 'perl5', $Config archname );
 
1;

Now I need to install this module and all the modules maintained by Carton. I do this by a enhanced Module::Build script:

use v5.10.0;
use strict;
use warnings;
use Module::Build;
my $class = Module::Build->subclass(
    class => "My::Builder",
    code  => q 
        sub ACTION_build  
            my $self = shift;
            $self->SUPER::ACTION_build;
            !system 'carton', 'install', '--cached';
         
        sub ACTION_install  
            my $self = shift;
            $self->SUPER::ACTION_install;
            
            my $installdir = $self->destdir . "/usr/lib/projectname";
            system 'install', '-d', $installdir;
            !system 'cp', '-a', 'local/lib', $installdir;
         
     ,
);
$class->new(
    module_name       => 'My::Bundle::ProjectName',
    dist_author       => 'Peter Makholm <peter>',
    dist_version_from => 'lib/My/Bundle/ProjectName.pm',
    add_to_cleanup    => [ 'local/lib', 'local/bin' ],
)->create_build_script;

The last step is to create a .deb package. This is mostly just a standard debian/ directory using debhelper. You just need to override the dh_perl to pick up the correct binary dependencies. So this is my debian/rules:

#!/usr/bin/make -f
%:
        dh $@
override_dh_perl:
        dh_perl /usr/lib/projectname/lib

That s it. Then all the scripts and applications making up my project just needes to use My::Bundle::ProjectName and the rest is automatic. I am thinking about enhancing Carton to provide individual .deb packages instead of just installing the modules. This would make it quite easy to maintain the packages in a more The Debian Perl Group-compatible way. That could be cool.