A while ago I've been interviewed for a forthcoming article in the LinuxUser magazine on the topic of why there are so many Debian derivatives and on the potential impact, on them, of the (potential) advent of the so called "Debian Rolling" experiment. Below you can find my take on those topics. Questions are by Ferdinand Thommes, who has been involved in various Debian derivatives, including the forthcoming Siduction.

---

1.) Why do you think people base distributions on Debian? Looking at how many there is, since Corel and Libranet set sail in 1999, there must be a reason why, for one, people fork Debian in the first place, and secondly, why they choose Debian to do so and not some other distribution.

There are always advantages in creating a so called "derivative" distribution with respect to creating one from scratch. The main one is the possibility of reusing the packaging work which is already done in the "upstream" distro, focusing derivatives' efforts on customization, usually with clear target public in mind. Debian pushes most of those advantages (for derivatives) at their extremes.

• The Debian archive is huge (about 30'000 packages with Squeeze), meaning that the amount of packaging work that can be reused is similarly huge.
• Debian has a long history and a well established community, which reduces the risk of "betting" the efforts of derivatives on a distro that might disappear anytime soon.
• Debian is well known for its obsession with package quality, meaning that the risk of trusting pre-existing packages is greatly reduced, and that package behavior is on average very dependable as well as documented in standard documents such as the Debian Policy
• Debian is also well known for its obsession with licensing, at the point of being considered by many one of the authoritative sources for deciding what constitutes Free Software and what does not. For derivatives that implies that they do not need to worry---as long as they trust Debian, of course---neither about legal redistribution risks nor about software freedom claims on their distro.

But there are also a couple of "political" reasons for basing derivatives on Debian. One is quite subtle and applies mostly to commercial distributions. If you are designing one such commercial distro, you have to be based on an independent distro with no commercial interests, lest risking that petty (technical or otherwise) choices might be made just to undermine your business. Among "popular" GNU/Linux distros, Debian is essentially the only one which is both volunteer-based and not ascribable to any specific company. The last reason why I think many derivatives are based on Debian is our vocation to universality. Since we are not targeting any specific public, but rather trying to provide an operating system suitable for several different use cases (e.g. the tasks supported by the Debian installer or the choice of Debian Pure Blends), we offer an ideal starting point for those who are going to have customization as their main business.

2.) What could be the benefits for Debian and for its Derivates, if the discussions about a second Debian Release based on the Testing branch really come to be reality?

We are considering the possibility of adding a new Debian suite which is "rolling" like Testing, in the sense that new software releases flow in regularly rather than only at periodic bumps corresponding to major distribution releases. There seem to be user demand for that and I personally believe that such a scheme could address the needs of both advanced desktop users and of developers, which are now strand to mix and match Debian suites ending up using package combinations which benefit, as a whole, of very little quality check. The main issues to face to get there is how to make sure that adding such a suite would not get in the way of preparing high quality Stable releases, in terms of quality control, developer focus, etc. Note that such a hypothetical "rolling" suite needs does not necessarily need to be based on Debian Testing, although that is a good starting point. The reason why it's not a good endpoint is that Testing has been created (circa 2000), and is still used, as an internal tool to prepare the forthcoming Debian Stable release. As such, it is not entirely suitable for final user consumption. For instance, during the Debian "freeze" period the flow of new software releases that reach Testing is greatly reduced up to stopping completely just before the release of a new Debian Stable. I've been told that users of testing-based (derivative) rolling releases regularly complain about this aspect during Debian freezes, which is not surprising. The main advantage for derivatives which are already offering a Debian-based "rolling" release will then be the possibility of basing their work on a suite less bound to the life cycle of Debian Stable than Testing is at present. On the converse side, that would also mean that derivatives will need to differentiate more from Debian than by just saying they are "rolling", which is a good thing: differences among distros are healthy and drive innovation. With those derivatives, on the other hand, which will recognize their goals as being aligned with Debian's goals---Debian Stable today, maybe Debian "rolling" tomorrow---we will be happy to join efforts.

Fixing the Sandbrige MacBook Air display initialization We left our hero with Debian installed on the MacBook Air, but with the display getting scrambled as soon as the i915 driver loaded. As was reported to Matthew, the problem is as simple as a lack of the right mode for the eDP panel in the machine. This mode is supposed to come from the panel EDID data, but for some reason the driver wasn t able to query the EDID data, and so it decided to try some random panel timings it dug out of the VBT tables, which are generally supposed to be used by LVDS panels. Apple helpfully stuck valid data there, but for some other panel one that is 1280x800 pixels instead of the 1366x768 pixel panel in the MacBook Air. I heard rumors that some machines would get a black screen when the i915 driver loaded. I was fortunate my machine simply displayed a 1366x768 subset of the programmed 1280x800 mode. A bit of garbage on the right side, and a few scanlines missing at the bottom. Quite workable, especially after I ran fbset -yres 768 to keep the console in the visible portion of the screen. DDC failure Looking through the kernel logs, the Intel driver tries to access the EDID data and times out, as if DDC is just completely broken. This is rather unexpected; the eDP spec says that the panel is required to support DDC and provide EDID. Now, we ve seen a lot of panels which don t quite live up to the rigorous eDP specifications, but it s a bit surprising from Apple, who generally do VESA stuff pretty well. We ve heard reports about panels reporting invalid EDID data, or EDID data which didn t actually match the panel (causing us to prefer the VBT data on LVDS machines). But I ve not heard of an eDP panel which didn t have anything hanging off of the DDC channel. But X works fine? During early debugging, I happened to start X up. Much to my surprise, X came up at the native 1366x768 mode. Digging through the kernel logs after that, I discovered that EDID was successfully fetched from the eDP panel while X started up. At this point, I knew it was all downhill the EDID data was present, it just wasn t getting picked up during the early part of the driver initialization when the console mode is initialized. eDP power management The CPU is given complete control over the power management of the eDP panel; sequencing through various power states and waiting appropriate amounts of time when things change. Given the goal of keeping power usage as low as possible, this makes a huge amount of sense. The eDP spec is quite clear though, without power, the panel will not respond to anything over the aux channel, and that includes EDID data. The eDP panel power hardware in the Sandybridge chip has a special mode for dealing with this requirement. If the panel is not displaying data, you can supply power for the aux channel stuff by setting a magic bit in the panel power registers. When initializing the frame buffer, the kernel driver turns off the panel completely so that it has all of the hardware in a known state (yeah, this is not optimal, but that s another bug). When X started, the panel was already running with the console mode. Given the difference between these two states EDID querying with the panel off failed, while EDID querying with the panel on worked, it seemed pretty clear that the panel power wasn t getting managed correctly. So, it seemed pretty clear that the magic power the panel bit wasn t getting turned on at the right times. Getting the power turned on. I stuck a check inside all of the aux channel communication functions to see where things were broken. This pointed out several places missing the panel power calls. This wasn t quite sufficient to get EDID data flowing. The remaining problem was that the code wasn t waiting long enough after turning the panel power on before starting the aux channel communication. A few msleep calls and huzzah! EDID at boot time and the console had the right mode. Making it faster However, it turns out that the driver does this a lot, and the msleeps required were fairly long the eDP panel wants a 500ms delay from turning the panel power off before you can turn it back on. I fix this by simply delaying the panel power off until things were idle for a long time. Now mode setting goes zipping through, and a few seconds later, the bit to force panel power on gets turned off. Getting these bits for yourself I ve pushed out the code to my (temporary) kernel repository git://people.freedesktop.org/~keithp/linux in the fix-edp-vdd-power branch. I d love to hear if you ve tried this on either a MacBook Air or any other eDP machine from Ironlake onwards.

This morning, I was one of a mere 900 or so marathoners in the second (?) annual Fox Valley Marathon, along with a 20 mile training race (as Chicago's big marathon is coming up) and a half marathon. This all took place along the Fox river, which is about an hour west of Chicago. The race went well enough. I had been racing twice a year at this distance, but took a break after running with some minor injury and generally not too well (see e.g. my writeup from last year's Boston and Chicago marathons). So I wasn't even sure I'd run one this year at all, but the bug got me again when two friends signed up for this, and off we went to train over the summer. So with a few more miles from training, I was pretty antsy and went out too fast as usual, and paid with an as-usual slower half and few short walking breaks past mile 20. But I beat the hope-for target time of 3:25 quite handily with a 3:19:03 -- or a 7:36 min/mile pace. Which (as I noted in a quick post to Google+ started right after the race, and since edited/expanded -- prods to Google+) should hopefully get me back to Boston next spring.

Two tiny bits:

• Thanks to Micha Lenk and after a fruitful discussion with Andrew Ruthven, you can finally find the Python bindings for Gnucash in the archive.
• If you want to check how your favourite package evolved over time: All historic build times and disk space information available in the Debian build logs are now imported into our database and are hence visible on log overview pages such as the insighttoolkit one.

Installing Linux on Sandybridge MacBook Air Matthew Garrett got a report from someone who bought a brand new Sandybridge MacBook Air and was trying to install Fedora on it. The screen went black as soon as the i915 driver tried to set the initial mode. I bought one to try and help out. Just getting Linux installed turned out to be a minor adventure and I thought I d write a few notes for the next person who comes along and tries to do this. The obvious method I downloaded a collection of Debian ISO images, live images, netboot images from testing and CD-1 of squeeze. I downloaded a Fedora 16 alpha XFCE live image. I burned all of these to actual CDs, and then stuck them in a CD drive and held the c key while booting the machine. Nothing worked. The CD would spin up, the screen would switch from white to a black text mode with a blinking cursor at the upper left and then then CD would stop. rEFIt attempts rEFIt provides a boot selection menu and various configuration bits to provide for a multi-boot environment. This is necessary to leave the OS-X install on the disk and also install Linux. It also lets you boot from removable media, or at least that was the story. rEFIt would list removable USB flash storage devices, but it would not list CD drives, even after the CD drive spun up and did stuff for a while. This makes me wonder if the c key technique wasn t actually trying to boot from the CD. However, rEFIt wouldn t boot from a grub2-enabled USB key. ISO on USB flash key What rEFIt will boot is a Fedora or Debian ISO image copied directly to the USB flash device. The Ubuntu 11.04 live image and it did not work. Fedora F16 Alpha The live image came up and started X in frame buffer mode. However, when I went to install the image to the hard disk, it got stuck trying to discover devices. I waited about 20 minutes and it never finished, although it did chew up a lot of CPU time. Debian Squeeze I copied CD-1 of the 32-bit Squeeze distribution to my flash key. That booted up to text mode and went through the install. Nothing really unusual until it came to installing grub. I let it install grub to /dev/sda4, the new partition I had created for Linux. I figured installing grub to /dev/sda would be a bad idea (I think it would have actually worked just fine in retrospect). A slight out-of-sync diversion here I couldn t get the 32-bit kernel to talk to any keyboard or USB networking device, so I eventually installed a 64-bit kernel and that works just fine. You can run a 32-bit user space with a 64-bit kernel without any trouble. Making EFI boot Naturally, I couldn t get the machine to boot to Linux after this. rEFIt, the multi-boot tool for Mac OS X appears only interested in booting EFI images, or at least was not interested in booting my BIOS-based Grub2 installation on /dev/sda4. I used the rescue mode on the USB flash drive to get back to my installed Linux image and installed grub-efi-amd64. The OS X EFI version does not support 32-bit EFI code, which seems entirely reasonable to me. What took a while was figuring out that all of the grub files need to be readable through EFI, and that the Mac EFI code can only read FAT (and HFS?) partitions. So, the trick appears to be to stick the grub files on the Mac OS X efi partition (/dev/sda1). I created a directory over there, /EFI/grub and then mounted that as /efi and made a symlink from /boot/grub to /efi/EFI/grub. Now, grub-install sticks the files in the right place, and update-grub will even place grub.cfg in the directory where it needs to go. At this point, rEFIt will happily find the core.efi and grub.efi files and show them in the list of possible operating systems to boot. I don t know why there are both core.efi and grub.efi files; I ve only ever picked grub.efi and that has worked nicely. Broadcom WiFi I haven t gotten that working yet; the b43 supported chip list says it works in kernel 3.1. I m busy building a 3.1-rc4 kernel as I type this, so perhaps that will just work when I boot that. i915 KMS The whole reason for doing the install is to fix problems with the eDP EDID discovery which is currently preventing the machine from running X. I ll be working on that next; a quick kludge to just read the current mode from the device should get something on the screen (we already do that for LVDS panels). Beyond that, I ll be trying to figure out whether I can make EDID actually work, or whether it s just not available in this machine. Somehow the kernel frame buffer ended up as 1280x800, which was quite annoying. As a temporary kludge, I ran fbset -yres 768 to at least avoid having text disappear off the bottom of the screen. Once the panel size is discovered correctly, that should be fixed. Status This is sure not like installing Linux on a regular PC. However, I m reasonably hopeful that the devices in the machine will be working pretty well under Debian within the next few days.

Sounds easy doesn t it? You got a nice debian computer filled with mp3s and you got an iPod Shuffle. You want to get the mp3s onto the Shuffle, simple really! Well, no. I ve got a 2nd Generation iPod Shuffle; its a little blue thing the size of a postage stamp with no screen. Specifically a model A1204. It uses the headphone socket with a special connector to get it connected via USB. It also steadfastly refused to play anything I transferred onto it. gtkpod was first. I knew I was in trouble when my model doesn t appear in their list of supported devices. 2nd Generation Shuffles do, just not an A1204. After a lot of fiddling around and playing with special files and firewire IDs I got a file onto it. Great, but then turning the iPod on I got the green and orange sequence of lights which means no file found. Next, was Rhythmbox. It is supposed to understand iPods too. The funny thing was that it saw the music file I put on the iPod by gtkpod, but adding any file gave me the same colour sequence. What was worse is if you tried to look at the information about the iPod, Rhythmbox crashed. It seemed I was doomed to use iTunes on the windows computer in the living room. A program that seems designed not to work the way I want. (It tries to load all the mp3 files from my son s games into the iPod but ignores my music on the samba share, for starters). I just wanted the files on the player and the player to recognise and play them. It didn t seem like a too hard a task, but I was stuck. That was until I found a small (643 lines) python script called rebuild-db that builds the special iPod files with my music. I found the file at the rebuild-db sourceforge page and it was very simple process. Now I plug the iPod in, wait for the window to appear, push my songs onto the iPod and run the script. It s quick and simple and more importantly it works. Not bad for a program that hasn t been developed since April 2006.

Since it was Software Freedom Day again, I figured I should revisit my personal software freedom and see what has changed since my post two years ago. There hasn't been a vrms meme again this year so I don't have anyone else to compare with. A small survey on IRC indicates folks still need non-free nVidia drivers, embedded software, GNU documentation, Java and more. Since then I have switched my laptop from the Dell Inspiron 6400 to the Thinkpad X201 Tablet. Nothing really changed with my laptop, GNU documentation is still non-free and the new Intel WiFi chip on my new laptop still uses non-free embedded software. To remind myself of the non-free bits embedded in the hardware (CPU microcode, BIOS, EC etc), I have installed intel-microcode and microcode.ctl. Since then I didn't get any new phone, still the same OpenMoko FreeRunner. I'm now using QtMoko on a 4GB microSD card and Debian and SHR on other cards for testing. QtMoko is based on Debian and is the latest incarnation of Qtopia. It is probably free but I haven't done any audit of it. One interesting thing that changed with the FreeRunner in the past two years is that Harald Welte and friends started OsmocomBB, a project to create free software for the GSM modem built into the FreeRunner and many old feature-phones. I haven't tried it yet due to lack of time. While at the Chaos Communication Camp 2011 I learnt about the blackbox that SIM cards are (video), which hopefully OsmocomBB has a chance to protect against. AFAIK nothing else has changed to improve software freedom on the FreeRunner, the WiFi, GPS and other parts still contain non-free software with no chance of a replacement in sight. Since then I am still using the same wireless router and ADSL modem and I wasn't brave enough to try replacing their software. I still use gmail out of intertia, but I at least have started using offlineimap to prepare for the day when I will move away from it. I still use Google Maps, mainly for searching for public transport routes. With my recent travels in Europe I encountered many places where OpenStreetMap has much better coverage than Google. One nice thing about Google Maps adding public transport information is that public transport organisations have been publishing public data feeds for Google to consume. Apparently there is also a realtime variant. I also found one website using a JSON API for Google street view. The combination of these gives me hope for better support for spatial data in free software. The data (aerial and streets) will obviously remain a much longer term freeness issue though. For flash video on the web get-flash-videos appeared and made it even easier to ignore flash, especially since I got a few patches added to it. In addition Swfdec died but Gnash improved enough to replace it. Lightspark was also created but has so far been pretty buggy and unstable. Free RAR v3 format support appeared in the form of TheUnarchiver. The Voxware audio codec and DigiTrakker MDL files are still not supported by Rhythmbox. Unicode has been updated and so now Debian doesn't support every script fully. I still manage to avoid Skype. The nouveau drivers have matured enough to provide 3D support, multi-monitor support and general stability for the one nVidia card I used in the past two years. Overall, I'm reasonably happy with my level of software freedom. My main strategy for preventing regressions in my software freedom remains to just avoid doing things that require non-free software. The most problematic FLOSS issues for me are embedded software, spatial data support and Flash support. Please feel free to contact me with any comments or questions. Happy Software Freedom Day everyone!

I used to know guys who would take old computer hardware out in the desert and shoot it up. I never went, and I've never gratuitously destroyed a computer in 2 decades of working with the things. Until yesterday when I picked one up by the monitor and introduced it to the floor. My regret isn't that I violently destroyed a computer, but that it was my Mom's computer, and I did it right in front of her, and without even a story-worthy reason, just out of garden variety frustration. And perhaps there's some regret that I was actually unsucessful in destroying anything other than the monitor and some speakers. The computer was salvaged, and my mom has a new monitor and a working system again. Sorry Mom & Maggie. To make up for it, I'll humiliate myself with this recording of "broke mom's computer blues", which will only be available for a very limited time: click to listen (warning: contains harmonica). Anyway, don't worry; any remaining frustration will be taken out the usual way: Splitting firewood.

Our friend Susan was going to be in Chicago for a conference, and as we hadn't seen Chicago yet, and it was on the list of cities we wanted to visit, we made the semi-spur of the moment decision to have a three day weekend there last weekend. We got the Virgin America red-eye flight from SFO, which left on Friday at around 5pm, and got into Chicago at around 11:30pm, local time. Zoe didn't do as well as she has previously, and didn't sleep very well on the flight over, despite us getting lucky and scoring an empty seat between us on an otherwise fairly full flight. I think she's getting too big to comfortably sleep in the Ergo baby carrier (or isn't keen on sleeping vertically any more). We stayed at the Swissotel, because that was where Susan was staying (and was where her conference was) and nearby hotels seemed to be around the same price range. When we checked in, we let them talk us into an upgrade to a larger room, which had fantastic views of Lake Michigan and the Chicago River. Lake Michigan is just mind-bogglingly big. It's an inland sea. What can I say? I was totally in love with Chicago. The weather while we were there was unbelievable. Clear skies. High 20's (Celsius). It was more humid than the Bay Area, but less humid than Brisbane. The first thing we did on Saturday was go visit a friend of Sarah's who lived in Bryn Mawr. We took the "L" there. The elevated train was an interesting affair, and turned out to be less accessible than we'd been led to believe from some light research in advance. In fact, I found Chicago in general to be fairly wheelchair (and by extension, stroller) unfriendly. We had to lug Zoe's stroller up and down stairs quite a bit to get from the river level to where the hotel was. Zoe seemed to find it amusing, at least. Aside from that problem, the city seemed pretty flat. I'm really glad that we got out of the city and into Bryn Mawr, because it was really great to see that aspect of Chicago life as well. Lovely, quiet, tree-lined streets with wide sidewalks. Beautiful buildings. Sarah's friend was fostering 8 kittens, so Zoe got to have a play with all of them, which she thought was pretty cool. After we returned to the city, Sarah and I kicked back in Millennium Park while Zoe napped in the stroller. Saturday, being 9/10/11 in US date format, seemed to be particularly popular for weddings, and there were a lot of couples getting wedding photos taken in the park. That night, we tried to have some deep dish pizza at Uno, the home of deep dish pizza, but the line was ridiculous. We subsequently learned about Due, and went there the following night. The pizza was good, and I found the crust to be slightly different from what we'd get at Patxi's. We checked out the Navy Pier on both Sunday and Monday, taking Zoe to the Chicago Children's Museum both days (we got free entry thanks to our membership at the Children's Discovery Museum of San Jose). We had grand plans of checking out the Shedd Aquarium, but it turned out that Monday was a "free for all Illinois residents" day, and the line at 11am was ridiculous, so we gave it a miss and took at water taxi back to Navy Pier. It was Zoe's first boat ride, and she enjoyed it. I got some unbelievably good photos of the city skyline from the boat. Our flight out was at 7pm, so we took the train to Midway. I was very impressed that we could get all the way to the airport by train for the standard price. I love flat-rate fares. I really love a city with good mass public transit. The only thing that detracted from this in Chicago was the accessibility issues. We explicitly went to the Orange Line Clarke/Lake station to go to Midway because it was listed as being wheelchair accessible, and we had a stroller and a suitcase. We ended up going up to the wrong platform, and getting across to the other side was a bit of a mission. We'd entered the station from the street level, took the elevator up, and then realised we were on the wrong side. We had to go back down the elevator to the level below the street, cross the street from underneath it, and then go back up the elevator on the other side. Aside from these sorts of shenanigans, the whole elevated train thing was pretty cool (but I wouldn't have wanted to have an apartment with the train line right outside my window). If only the cars had glass roofs, the Loop would have been a lot more scenic. Overall, it'd be hard to say whether I liked Chicago or New York City better. I liked the clean, flat nature of Chicago, the architecture and the lower density of buildings, but I also really love New York just because it's New York, and has an awesome (probably equally stroller-unfriendly) subway system. Photos from the trip are here.

For convenience, I want to store copies of all my DVDs on my file server. It allow me to save shelf space flat while still having my movie collection easily available. It also make it possible to let the kids see their favourite DVDs without wearing the physical copies down. I prefer to store the DVDs as ISOs to keep the DVD menu and subtitle options intact. It also ensure that the entire film is one file on the disk. As this is for personal use, the ripping is perfectly legal here in Norway. Normally I rip the DVDs using dd like this:

#!/bin/sh
# apt-get install lsdvd
title=$(lsdvd 2>/dev/null awk '/Disc Title: /  print $3 ')
dd if=/dev/dvd of=/storage/dvds/$title.iso bs=1M

But some DVDs give a input/output error when I read it, and I have been looking for a better alternative. I have no idea why this I/O error occur, but suspect my DVD drive, the Linux kernel driver or something fishy with the DVDs in question. Or perhaps all three. Anyway, I believe I found a solution today using dvdbackup and genisoimage. This script gave me a working ISO for a problematic movie by first extracting the DVD file system and then re-packing it back as an ISO.

#!/bin/sh
# apt-get install lsdvd dvdbackup genisoimage
set -e
tmpdir=/storage/dvds/
title=$(lsdvd 2>/dev/null awk '/Disc Title: /  print $3 ')
dvdbackup -i /dev/dvd -M -o $tmpdir -n$title
genisoimage -dvd-video -o $tmpdir/$title.iso $tmpdir/$title
rm -rf $tmpdir/$title

Anyone know of a better way available in Debian/Squeeze? Update 2011-09-18: I got a tip from Konstantin Khomoutov about the readom program from the wodim package. It is specially written to read optical media, and is called like this: readom dev=/dev/dvd f=image.iso. It got 6 GB along with the problematic Cars DVD before it failed, and failed right away with a Timmy Time DVD. Next, I got a tip from Bastian Blank about his program python-dvdvideo, which seem to be just what I am looking for. Tested it with my problematic Timmy Time DVD, and it succeeded creating a ISO image. The git source built and installed just fine in Squeeze, so I guess this will be my tool of choice in the future.

Brown-bag release time for littler. One of the <emph>minor cleanups</emph> in the 0.1.4 release from Thursday actually introduced a nasty little bug as you can't call Rf_KillAllDevices() when you do not have any graphics device. Doh. So with apologies for the lower quality release, and the two hour malfuntioning window for CRANberries that it cause, a repaired version is now out there. The very brief (upstream) ChangeLog is as follows:

2011-09-17  Dirk Eddelbuettel  <edd>
        * configure.in: Mark as release 0.1.5
        * littler.c (littler_CleanUp): Remove call to Rf_KillAllDevices() 

littler provides r (pronounced littler), a shebang / scripting / quick eval / pipelining front-end to the the R language and data analysis environment. As usual, our code is available via our svn archive or from tarballs off my littler page and the local directory here. A fresh package is in Debian's incoming queue and will hit mirrors shortly.

So I decided, once the disk was in place, that the whole system should move to a RAID1 over the two disks. Basically this is not that hard as it may seem at a first glance, but I had some problems due to a new sector size in some recent harddisks, which is called Advanced Format.

1. Install mdadm with apt-get. Make sure to answer 'all' to the question which devices need to be activated in order to boot the system.
2. Partition the new disk (almost) identical.
   Because the new drive is somewhat bigger that wouldn't make sense, but at least the two partitions which should be mirrored on the second disk, need to be identical.
   Usually this is achieved easily by using

   sfdisk -d /dev/sda sfdisk /dev/second/sdb

   
   
   In this case, it wasn't that easy. But I will come to that in a minute.
3. Change the type of the partitions to 'FD' (Linux RAID autodetect) with fdisk
4. Erase evidence of an eventual old RAID from the partitions, which is probably pointless on a brand-new disk, but we want to be sure:

   mdadm --zero-superblock /dev/sdb1

   mdadm --zero-superblock /dev/sdb2

5. Create two DEGRADED raid1 arrays from the partitions:

   mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing

   mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb2 missing

6. Create filesystem on the first raid device, which will become /boot.
7. Mount that filesystem somewhere temporary and move the contents of /boot to it:

   mount /dev/md0 /mnt/somewhere

8. Unmount /boot, edit fstab to mount /boot from /dev/md0 and re-mount /boot (from md0)
9. Create mdadm configuration with mdadm and append it to /etc/mdadm/mdadm.conf:

   mdadm --examine --scan >> /etc/mdadm/mdadm.conf

10. Update the initramfs and grub (no manual modification needed with grub2 on my system)
    and install grub into the MBR of the second disk.

    
    

    update-initramfs -u

    update-grub

    grub-install /dev/sdb

11. The first point to pray: Reboot the system to verify it can boot from the new /boot.
12. Create a physical volume on /dev/md1:

    pvcreate /dev/md1

13. Extend the volume group to contain that device:

    vgextend <volgroup_name> /dev/md1

14. Move the whole volume group physically from the first disk to the degraded RAID:

    vgmove <volgroup_name> /dev/md1

    
    
    (Wait for it to complete... takes some time ;)
15. Reduce first disk from the VG:

    vgreduce <volgroup_name> /dev/sda2

16. Prepare it for addition to the RAID (see step 3 and 4) and add it:

    mdadm --add /dev/md0 /dev/sda1

    mdadm --add /dev/md1 /dev/sda2

17. Hooray! Watch into /proc/mdstat. You should see that the RAID is recovering.
18. When recovery is finished pray another time and hope that system is still booting with it running from the RAID entirely. If it does: Finished :-)

There is some action taking place with the hardware vendors to move to a new sector size. Physically my new device has a size of 4096 bytes per sector. Somewhat different to the 512 bytes disks used to have the last decade.

Device Boot Start End Blocks Id System

/dev/sdb1 2048 291154 144553+ fd Linux raid autodetect

/dev/sdb2 291160 625139334 312424087+ fd Linux raid autodetect

Just completed watching Ireland-Australia. What could I say except "I knew they could make it"? This so Irish team won the fight against Australia and, of course, I'm happy. Let's dream for IRL-FRA in final...:) Oh, that Rugby World Cup in case you hadn't noticed and such a game is exactly why I like rugby.

So tired, but so happy. Well worth it as a day out. Yesterday I went to the Tour of Britain as it passed through Cheddar Gorge. It was a fairly social trip, riding along with two from Bristol on the way in (hope they got back OK one bike broke crossing the orchard at Sandford, but I showed them Cheddar Cycle Store) and one from Milton on the way back. When I got there, I rode up the Gorge until I had to stop (or else fall off) and it was still packed with fans. It was a good half-hour before the race would pass by, but already almost every flattish piece of land by the road had either a spectator or a bicycle on it. I watched twitter for race news, posted an update @mjray, then put the phone away as the green-fronted police bikes came through just ahead of the racers. I tried videoing the race, but it s only the second outing for the handlebarcam and I seem to have deleted the recording before hooking it up to the laptop. Thankfully, the itv4 coverage (repeated 13:00) is pretty good. (My back is on TV! Ahem.) Now, today (Saturday) I will be mostly doing the work scheduled for Friday, but it was still worth it. Go along if you get the chance: Suffolk and Norfolk today, Westminster tomorrow. I suggested it to @enterprisehub s #coopsweekend because the Rabobank team are doing well.

I just download this tool here. After finishing a really simple setup wizard, which includes choosing your blog service provider, filling in your username&passwd info, I m now writing my first blog with this tool. Before I download and begin to use it, I knew from reviews that this is NOT a WYSIWYG tool. I really doubt it that it could be useful for a person like me who have nearly no HTML knowledge. But so many reviews mention this tool and all give it high options that I decide to give it a try. The tool looks pretty neat, isn t it? It s simple for me to use any buttons without guessing what they will do. And you can see that there s Preview tab, in which you can check the real layout when published. The preview tab(it seems the first picture is not uploaded successfully?) In all, I begin to love this editor even this is my first time using it! It s simple yet completely enough for users like me. And with this editing HTML directly, I can even learn a little bit about its syntax. Don t mention all the merits an offline desktop editor can provide. Now, I ll try the last and most important function Publish! See you on my blog!

Triaging bugs is one of the easiest way to start contributing to Debian. I ll teach you the basics in this article. 1. Prerequisites All interactions with the Debian Bug Tracking System (BTS) happen through email so you need to have an email account with an address that you re willing to make public. All the mail that you send to the BTS will be archived and publicly available through its web-interface. This also means that you should have some spam filters in place because it will inevitably be harvested by spammers. To ensure that this email address is consistently used by the various tools that we re going to use, it s a good idea to put this email address in the DEBEMAIL environment variable. You can also specify your full name in DEBFULLNAME (in case you don t want to use the name associated with your Unix account). You usually do this by modifying ~/.bashrc (if you use bash as login shell):

export DEBEMAIL="hertzog@debian.org"
export DEBFULLNAME="Rapha l Hertzog"

You should also install the devscripts package, it provides the bts command that we re going to use. 2. Find a package or a team with too many bugs You can literally pick any popular software that s in Debian, they almost always get more bug reports than the maintainers can handle. Instead of picking a package, you can also select a packaging team and concentrate your efforts on the set of packages managed by the team. In any case, it s important to receive the bug traffic for the packages that you re going to work on. If you went for a specific package, you should subscribe to the package via the Package Tracking System (there s a subscribe box on the bottom left corner once you selected the source package of interest). If you decided to help a team, there s usually a dedicated mailing list receiving all bug traffic. You can browse a list of packages with the most bugs if you have troubles finding a package to work on. 3. Triage bugs! Bug triaging is all about making sure that bugs are correctly classified so that when a developer looks at the bug list, he can quickly find bugs with all the information required to be able to fix them! 3.1 Adding information to bug Adding supplementary information is easily done just by sending a mail to XXXX@bugs.debian.org (replace XXXX with the bug number). But often you want to reply to a message in the bug history, in that case bts --mbox show XXXX is for you. It will grab the corresponding mailbox and open a mailer (mutt by default) on it. Now you can directly reply in your favorite mailer. 3.2 Classifying bugs The Debian BTS uses tags (click the link and read the doc!) to classify bugs. bts tag XXXX + foo will add the foo tag (replace the + with a to remove a tag). If you want to explain why you re adding a tag, you should instead reply in the bug log as explained above, put control@bugs.debian.org in Bcc (Blind Carbon Copy) and start the body of your message with your tag command:

tag XXXX + foo
thanks

But what tag should you add? When a bug is submitted, you should try to reproduce the bug. If you can reproduce it, then tag the bug confirmed (example in #641710). If you can t, you should request more information (ex: a sample document triggering the bug, a configuration file, the output of some relevant command, etc.) until you can reproduce it or conclude that it was a user mistake. When you request supplementary information due to this, you should tag the bug unreproducible moreinfo (example in #526774). moreinfo should be later dropped when the requested information are provided, and unreproducible should be dropped if those information were enough to actually help reproduce the bug (example in #526774). During that initial evaluation, it s also worth differentiating packaging bugs (which are specific to Debian) from upstream bugs (which are relevant also for non-Debian users). The latter should be tagged upstream (and forwarded upstream if the bug is reproducible or contains enough information for the upstream developers, example in #635112). If you saw a (viable) patch in the bug log, the bug should be tagged patch . This is usually done by the patch submitter but sometimes it s forgotten (example in #632460). Take care though to not reinstate the patch tag if it was initially set but then dropped by the package maintainer after a review of the patch. If the title of the bug report is not descriptive enough, you can change it with a retitle XXXX new-title command (example in #170850). You can also change the severity of the bug report depending on the impact of the problem (with a command severity XXXX new-severity , what a surprise!). Request for new features are wishlist , most documentation problems are minor . On the other side of the scale, you can use important for bugs that are very annoying but that should not block a release. serious , grave and critical are used for release critical bugs, check the official definitions of the severities (examples in 502738 or #506498). 3.3 Closing non-bugs and bugs that are already fixed If your analysis of the bug report is that it s not really a bug but a user mistake, then you should close it by sending a mail to XXXX-done@bugs.debian.org with some explanations of the user s mistake so that he can get past his problem (example in #592853). If the problem was a real bug, but one that is apparently already fixed, you should try to quickly find the version that fixed the bug. If you can t find it in the changelog (there s a link to it in the PTS, or you can use /usr/share/doc/package/changelog.Debian.gz), you ll make the safe assumption that the upstream version you re currently using is the first one where this is fixed. Then you send a mail to XXXX-done@bugs.debian.org but you start your mail with Version: version-that-fixed-the-bug and continue with a small explanation of why you believe the bug to be fixed by this version (example in #122948). 3.4 Reassigning misfiled bug reports Bug reports are not always filed against the proper package. Users file bugs against applications where they experience the bugs, but the real bug might be in an underlying library or application. When that happens, you should use the reassign XXXX correct-package version command to get it filed against the correct package. The version parameter is optional but should be provided if possible, it should be the oldest version that we know to have the problem (example in #626232). 3.5 Forwarding bugs Forwarding bugs means opening bug reports in the upstream bug tracker for issues that have been reported in Debian but that applies to the upstream (unmodified) source code. Be sure to include all the relevant information and a link to the corresponding Debian bug. Depending on the upstream bug tracker, you might have to open an account to be able to file new bug reports. On the Debian side, you must record that a bug has been forwarded with bts forwarded XXXX upstream-bug-url . upstream-bug-url is the URL corresponding to the upstream bug report you created (ex: http://projects.ciarang.com/p/feed2omb/issues/21/ recorded in #609345 ). If the upstream authors fix the bug you reported, you can tag the Debian bug with fixed-upstream so that it s easier to find bugs to close when the next upstream release comes out (example in #637275). 3.6 Updating version information The Debian BTS uses version tracking to know which package versions are affected by a given bug. It s particularly important to have correct version information for release critical bugs since it might affect the migration of packages to testing. You can learn more on this topic here: http://wiki.debian.org/HowtoUseBTS. 4. More advice Colin Watson wrote a constructive rant explaining some mistakes that bug triagers are often doing. While it refers mainly to Ubuntu s launchpad, the advice apply equally as well to Debian. Check it out to become a better bug triager! Note that you can refer to this article with this shorter URL: http://raphaelhertzog.com/go/bugtriaging/

Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.

One comment Liked this article? Click here. My blog is Flattr-enabled.

Happy 10th birthday Mozilla bug #98160, I hope you won t make it to your 11th, but who knows I hope the same for your younger brothers bug #166240 which is only 9 years old. Many thanks for all the people who tried to help RTL users switch their textarea directionality and alignment easier. Another bug in the it sometime sucks to be an RTL user department is bug #119857, soon to be age 10. I m lucky to have BiDi Mail UI as a good workaround, otherwise I couldn t read emails in Hebrew with the proper alignment/directionality. In another department, I must say I love daylight saving time, as I have more hours of sun, but this comes on the expense of my schedule as due to bug #504299 all my events aren t on the right local time, but an hour earlier. Although the post is written cynically, I would like to call the Mozilla community to help with fixing these issues. I also want to thank the people who are already helping with these issues or helped in the past.
Filed under: Free software applications, i18n & l10n, Mozilla

The fifth in a series; see also parts 1, 2, 3, and 4. One piece of advice we got in Mexico went like this: the nicer a place looks, the worse the food and prices will be. Roadside taco stands will be great, and nice-looking restaurants not so much. That seemed to be accurate. We only tried one real nice-looking restaurant and it was very good (though pricy), but it may have been sort of an exception. But perhaps the most interesting bit about eating in Mexico wasn t the food. It s the adventure. We ate one day at Guadalajara s San Juan de Dios market. In that huge labyrinth somewhere was a set of restaurants. They d tend to have a small cooking area, usually just open, and a few tables. We chose one. And at this point, I have to take brief detour and explain something. There are a lot of people in Mexico that do things for tips, and quite often without being asked. Some other examples might be washing a car s windshield at a stoplight. So anyhow, we had ordered our food, and before long, a guy wanders down the aisle and plonks down a boombox. And turns it on. And then he pulled out a microphone, which we quite soon realized was connected to the boombox. (I guess making it more of a karaoke box.) Anyhow, he started singing a song decently and seemed to be enjoying it. About 45 seconds into it, a competing boombox man plonked down a competing boombox 25 feet away, turned it on, and yes, you guessed it pulled out a microphone and started singing a different song. Worse than the first person but louder. Eventually the boombox people left and our lunchtime conversation could resume. But pretty soon a drum guy showed up. He had a bunch of drums on a strap so he could just walk around and play them. He apparently decided that an excellent place to play them would be directly behind my head. I did not entirely agree with his decision, but hey, it beat the competing karaoke guys. Eventually the drum guy left, and somehow between the time I looked down to get out money to pay our bill and the time I had it counted out, a clown had shown up and made several balloon animals for our boys. I tipped him, we paid, and then headed on. You might think from this story that this would be an annoying series of events. And honestly, if it had happened in a big mall in the USA, it would probably have been both annoying and creepy. But really I enjoyed it. The fact that dueling karaoke happened, despite sounding really awful, was pretty funny and really seeing this whole parade of people was interesting too. It made American restaurants seem a little boring. You always know what s going to happen here (and if something surprising does happen, the place probably gets a bad review on Yelp.) Interesting things sometimes happen at mealtimes in Mexico and I like it that way. I had a torta ahogada (drowned sandwich) at that restaurant. And at this point, another brief aside. I m the kind of person that can go to an average American restaurant, see items on the menu helpfully indicated as spicy, order one, and genuinely wonder if other people would find them spicy, because I either don t notice spiciness at all, or maybe notice a tiny bit if I concentrate really hard. Others, meanwhile, might take a bite and lunge for the water. Having said that, I know people that lived in Thailand for awhile and I have nowhere near their tolerance for spiciness. So, having been in Mexico a whole 24 hours or so, I decided not to follow Jonathan s wise lead in ordering a torta with the spicy sauce on the side. I figured I hadn t had anything spicy yet, so maybe this was would be nice and mild for me. Via Jonathan s translation, I ordered it with the spicy sauce. I believe the phrase I heard him use was con chile . The waitress looked at me, gave me an amused the American is ordering it con chile? Hahaha . sort of smile, and went off. Pretty soon our food arrived. (The food always seems to arrive pretty soon in Mexico, by the way.) Oliver was having a bit of a culture shock that day, and mostly refusing to eat (once hunger got the best of him later, he really enjoyed Mexican food.) But the rest of us dug in, including me. I enjoyed my torta. It was spicy, but not too bad. I took some big bites (it was, after all, a thick sandwich) and was really enjoying it. For about a minute. Slowest-acting spiciness I ve had in awhile. Then it hit me. Spiciness, and lots of it. I took a big gulp of my horchata (a creamy sweet rice drink that I found at many restaurants). That helped. A little. I really liked the torta and ate it, but it wouldn t surprise me if the waitress noticed how extremely quickly a drank my horchata Another interesting experience was in Guanajuato. It was raining as we walked towards the Guanajuato market. Their market was large and similar in concept to the Guadalajara one, though a lot smaller. The restaurants were all in a row, in a side of the building that was open to the outside. Most were on the ground level but it looked like a restaurant or two were upstairs. As we approached, all of a sudden people were yelling at us. First it was a guy on the second story, then pretty soon people at the restaurants on the first floor did so as well. They were yelling rapidly in Spanish, waving their menus around in the air. I m imagining they were naming foods they sold or reasons to eat there, but I don t know enough Spanish to know. As we walked down the long row of restaurants, the ones we left behind would quiet down in disgust and other hopeful restaurant owners would take up the yelling and waving cause. I imagine if we did some time-lapse videography and walked up and down that row, we could produce an effect not unlike the sound of a dot-matrix printer going back and forth on the page. Anyhow, we selected one of the quieter restaurants pretty much random. The others then quieted down until another person chanced to walk past at which point it would get loud again. The lunch there was good but I think I mainly will remember it for the selection process! On our way into Guanajuato, we stopped at a wonderful roadside taco place. In typical fashion, they had a large vertical pork thing (I don t know the proper word for it) from which they would carve off meat on the spot anytime someone ordered something with pastor. We found a table. And we ordered a few tacos and such. They were usually a few pesos each (working out to less than a dollar), small round things on a soft tortilla, with meat, cilantro, and onion on top. And typically delicious. They had very little in common with an American taco . We d often order a few, and if we wanted more, just order more. They were made quickly enough for that. Tacos were very similar from one restaurant to the next. My favorite flavors were pastor (pork), chorizo (sausage), and bistec (beef steak). A restaurant in Guadalajara sadly I ve forgotten its name, since we kept calling it the potato place had what I might call a Mexican version of the loaded baked potato, with a meat, queso (cheese), a delicious sauce with a flavor unlike anything I d had before, and some garnish. But really my favorite thing from that restaurant was their amazing juices. I am not much of a juice drinker normally, but in Mexico I went for them whenever they were offered. What passes as fruit juice in the USA has about as much resemblance to a real Mexican fruit juice as Taco Bell has to a real Mexican taco stand. (Very little, in case that wasn t crystal clear.) That particular restaurant offered three types of juices, which were, if I m remembering right, aguas, frescas, and jugos. I has a jugo verde (green juice) on the first visit there. It was good, but the one I can still remember was called, I think, the fresa fresca (fresh strawberry juice). And it was incredible. I m not sure how to describe it, other than real. One observation before I end. It seemed a common thread at some Mexican roadside taco stands to not have soap in their restrooms. Instead there would be a plastic cup holding I kid you not powder-form Tide laundry detergent. It was amusing anyhow. My hands left those places extremely soft and smelling like laundry. One of the last restaurants we visited on our trip was in Ajijic, near the Chapala lake. It was actually right on the lake and served seafood. This was the only restaurant with prices as high as I d be used to in the United States. I ordered a stew served in a stone bowl. It came out sizzling, and since the very thick stone bowl retains heat well, it kept sizzling the entire time I was eating. It was excellent as usual. Coming up in part 6: some thoughts on returning to the United States, our decision to visit, communication, and tips for anyone else considering a first visit to Mexico.

There's more funny business when using ccache in combination with clang. Last time I suggested that you use the invocation

./configure CC='ccache clang -Qunused-arguments -fcolor-diagnostics'

to get rid of the "argument unused during compilation" warnings.But you still might get loads of warnings that you wouldn't normally get without ccache, such as this example (from the PostgreSQL source code):

extension.c:382:35: warning: equality comparison with extraneous parentheses [-Wparentheses]
 if (( (((control->directory)[0]) == '/') ))
        ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
extension.c:382:35: note: use '=' to turn this equality comparison into an assignment

(This is the opposite of the warning that tells you to put two pairs of parentheses around an assignment used as a truth value.)Or:

path.c:727:7: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign]
 path = (path);
 ~~~~ ^  ~~~~

The problem is, these come from macro expansions, so wouldn't normally see them, because (I guess) the compiler driver is smart enough not to warn about such things when they come from macro expansions.The way ccache works is approximately

1. preprocess the input file
2. look for it in the cache
3. if not found, compile the preprocessed file

What would be better in this situation is

1. preprocess the input file
2. look for it in the cache
3. if not found, compile the original file

And indeed you can turn on that second behavior by setting the obscure environment variable CCACHE_CPP2 (as in, run cpp twice):

export CCACHE_CPP2=yes

Then all these extra warnings disappear.(The ccache man page is worth a read. There are a few interesting settings to play with.)I'm currently playing around with a shell script ccache-clang that looks like this:

CCACHE_CPP2=yes exec ccache clang -Qunused-arguments  test -t 2 && echo -fcolor-diagnostics  "$@"

Two days after my first update, here's a progress report about D-I l10n? Status for D-I level 1 (core D-I files):

• 11 languages 100% for all sublevels: bg cs de fr it ja ko pt ru si th
• 1 language 97%: eo
• 2 languages 96%: eu tr
• 3 languages 95%: ba sk zh_CN
• 4 langauges 94%: ast fa ga sv
• 5 languages 93%: bn gu lo nb
• 7 languages 92%: es id nl pl ro sl uk
• 5 languages 91% et hu mr vi zh_TW

So, Japanese and Sinhala reached 100%. Great effort by Danishka Davin, the translator from Sri Lanka, who also sent me impressive pictures of a local FLOSS event, apparently taken at the booth of HanthanaLinux, a local distro based on Debian. I had many privat email discussions with translators. Several of them were used to send me updates, which I committed in the past. I really want them to be able to commit themselves. So, I end up explaining how to svn+ssh on Alioth and remotely debugging their setup. I have to say this is really painful...:-) So, I may end up again in committing what they sent to me..:-(