I'm experimenting with building Qt Embedded for armel using Emdebian toolchains and Debian packaging/patches. Initially, I've just "got it to build" with a few too many things nobbled and disabled - the results (using the package from Squeeze) are in Emdebian SVN - and the next task is to enable the missing bits and get closer to the standard Qt4-X11 binaries. Certain packages will simply not exist, even when finished, but it's been fun working out how to create a qmake.conf to map the Emdebian toolchain to what Qt expects from toolchains like CodeSourcery.

If it continues to work, it may be worth pushing upstream - but it may be better to wait until Multi-Arch supports cross-building, I'd only have to submit a different qmake.conf with updated paths otherwise.

I've also got a basic qmake.conf to help Qt applications cross-build using the Emdebian toolchains. This also needs updating once we finally get Multi-Arch-Cross.

The way I see this working is that the Qt Embedded packages would have to kept entirely separate from the Debian Qt4-X11 binaries from the KDE/Qt team because they use the same package names. That's relatively simple if the embedded packages are kept for cross-building only, either as -armel-cross packages generated by dpkg-cross or (eventually) as Multi-Arch packages. What won't work is having Qt-X11 and Qt-Embedded installed on the same architecture, without using a chroot or similar.

Initially, I hoped to keep the changes small enough that the Debian package could include the tweaks in a conditional part of debian/rules via a DEB_BUILD_OPTION. The current diff is a little too awkward (mainly in the .install files) but that's still worth keeping as a goal.

No warranty, created in the hope it's useful etc. etc., nothing to say it'll build on your system, no support for anything except the Debian armel port and only tested with the Emdebian toolchains from Lenny, not coming to a distribution near you anytime soon, don't blame me if it messes up your entire Qt-X11 installation on your desktop.... yada, yada.

It's just a bit of tinkering really, although it would be more fun if Qt didn't take quite so many hours to build each time I want to test a change....

Good morning, and welcome to another day of archive damage, i mean hackery. Well, at least at the time of this writing it is morning and we are starting off into another day of work. As we promised to try to have at least a once-a-day-installation run I am currently processing the queue of uploaded packages, around 4gigabytes from 431 changes files. After that a dinstall will follow to push that all out. Lets see how often we can do this again today, yesterday we managed multiple times. Yesterday my work consisted of getting the ries sync into something nice and acceptable, starting to think of the change to only use the suite codenames in future (long term making lots of code issues easier, but short term a good headache) and doing the groundwork so we can upgrade the security and backports archive to squeeze/pg9 too. Mark finished of the Built-Using flag and then moved on to think about database file tracking changes related to multiple archives/locations. Which sounds simple in so few words but is definitely not simple at all. Torsten started to work on source contents and also on generating the packages/sources files out of our database. Both together is taking a good amount of time, so he continues to work on those today. In the evening we had a meeting with the Debian Hurd porters about the future of their port within the Debian archive. The perceived Hurd situation until then was that every port has to follow certain rules or gets thrown out but Hurd doesn t seem to ever get into a releasable state . Well, we did get a clean view on both sides standpoint and in the end emerged with a solution which works for both sides: The Hurd port stays on FTPMaster until Wheezy is released. Should they have managed to get the port into a state that it is released together with all the others (probably as a technology preview), it is kept in the archive. Should they not manage this, the port will be removed from the main archive and move fully to debian-ports.org. It may then reenter the main archive whenever it is ready to get released with the next release. For today we are all continuing in our parts, Mark is yelling at the insanity of the multi-location thing (something we DO need when we want to merge multiple archives, which we do want), Torsten curses the code for Packages/Sources and while I hope that DSA can find time today to upgrade our security- and backports-archive machines to Squeeze, I try to wrap my head around the code we kindly got provided by Serafeim Zanikolas - the dinstall programming fun task I asked a while ago. Im not sure yet I will succeed. :) And then we will get more arrivals this evening, so more people doing stuff tomorrow.

I posted a brief snippet of code on Friday which was my initial stab at a reverse HTTP proxy in Javascript (using node.js). Over the past couple of days I've tidied it up, added a command line parser, and made it flexible enough that it works for me. My node reverse HTTP proxy is now both documented ( a little ) and available for further eyeballs. Usage is pretty much:

$ node ./node-reverse-proxy.js --config ./path/to/config.file.js

The configuration file defines lists of virtual hosts along with the destination back-ends to proxy to - which is usually going to be a server running upon a high port on the loopback adapter, but might not be. In addition to that we can perform rewrites such as:

/**
  * Handler for wildcard host: *.repository.steve.org.uk
  *
  */
'([^.]*).repository.steve.org.uk':
     
        /**
         * Rewrites for static files - these will be handled via a
         * separate virtual host.
         */
        'rules':  
            '^/robots.txt':  'http://repository.steve.org.uk/robots.txt',
            '^/favicon.ico': 'http://repository.steve.org.uk/favicon.ico',
         ,
      ,

That says requests for http://chronicle.repository.steve.org.uk/robots.txt will be redirected to http://repository.steve.org.uk/robots.txt. Alternatively we can invoke javascript for each request matching a pattern:</p.>

    /**
     * static.steve.org.uk will mostly proxy to 127.0.0.1:1008
     * but files beneath /private/ have an IP-based ACL.
     */
    'static.steve.org.uk':
     
        host: 'localhost',
        port: '1008',
        'functions':  
            '/private': (function(orig_host, vhost,req,res)  
                var remote = req.connection.remoteAddress;;
                if ( ( remote != "80.68.85.46" ) &&
                     ( remote != "82.41.51.252" ) &&
                     ( remote != "89.16.161.34") &&
                     ( remote != "89.16.161.98" ) )
                 
                    res.writeHead(403);
                    res.write( "Denied access to " + req.url  + " from " + remote );
                    res.end();
                 
            ),
         
     ,

Fun stuff. It was live for my server, replacing apache, for a few hours today. I need to add some trivial HTTP Basic-Auth handling then it will go back. Otherwise I hope it is vaguely useful to others, and that the provided examples explain things neatly. ObQuote: "Only one thing alive with less than four legs can hear this frequency" - Superman.

Recently there has been some major developments in DebConf11 organization. In short, I will list some of the most important.

Website

Official DC11 website has finally been completed and now contains a great deal of information for those interested in attending this years conference. Some of the most notable changes include:

Navigation

Frontpage now contains a small menu with links to most important parts of website, like About, Registration, Contact Sidebar menu is now divided in 3 categories:

• The Conference Links to pages which are directly connected with the Conference like About DC, Debian Day, Registration, Call for Papers, Talk Schedules, Payments Most of these links are hidden at the moment, and will be until the registration is open, to avoid any unnecessary confusion.
• More Information Basic information for attendees like Important Dates, Accommodations, Venue, Visa Everything you need to know about your stay in Banja Luka.
• Practical While these pages have almost nothing to do with the Conference itself, they do provide a vast information about city, getting to Bosnia, some practical information, as well as the Map of the whole city made my me :)

New Pages added

• How Can I Help This page contains some basic information for anyone who wants to help out. Weather by volunteering, sponsoring, or just by adding a banner on their website
  DC11: How Can I Help?
• Contact Instead of just sending visitors to mailto, we replaced it by a page which contains ALL contact information, emails AND phone numbers (which will be added just before DebCamp starts).
  DC11: Contact
• Sponsorship Just like with the contact page, we made a page to be more user friendly to any interested parties or individuals, and contains most important info, such as sponsorship levels and contact address.
  DC11: Sponsorship
• About DebConf11 Actually it s just a page with a content copied from frontpage (which is now used for something else).
  DC11: About DebConf11

New features:

• Documentation Is now used to store all important documents and records for public use and sharing, like brochures, official government documents, important public mails, as well as the recordings of all IRC meeting logs. Can be found at:
  DC11: Documentation
• Frontpage: Navigation To ensure the main goal of website, information availability, frontpage has been redesigned to provide maximum accessibility as well as easy access to any part of the website. DC11: Frontpage
• Frontpage: Latest News To keep the public and attendees well informed of any important events and developments, we decided to add latest news section. Note however, that if you want to stay completely informed of any changes and updates, we still recommend subscribing to our mailing list, which can be found under contact page.
  DC11: Frontpage
• Map of Banja Luka Because of lack of data on Google Maps and Open Street Map, as well as some other minor local maps, we made a small map of almost whole city and added around 60 or 70 locations which we consider to be of importance for our attendees. Such locations include hotels, parking spots, restaurants, bars, clubs, petrol stations, taxi stations, etc. This page uses simple JavaScript and is not dragable . Therefore we added Index Location to auto-locate the needed locations, as well as the legend to clarify the category of locations. Pointing your mouse over a certain location will open a small bubble with some info on that location/object. We should also point out that some of this data may not be 100% correct (ie working hours may be off ). Map is available at:
  DC11: Banja Luka City Map

Bosnian language

Site is now available on Bosnian language for native speaking attendees, should they have problems with English version. Every page is available on both languages, which can be changed by clicking on ba/en flag in upper left corner, or DC11: Bosnian Version.

Design

As you may have noticed, the official page received a small face lift. New header with the Government building, a small token of appreciation for all the help the Government is providing; as well as some minor changes in CSS and color scheme. While talking about design, we d like to thank Leandro G mez for his help with the header.

Sponsorship Sponsorship Levels

As agreed on the meeting, which took place on 22. of February, [Meeting logs], following sponsorship levels will be used for this years conference:

• Steel < 1.000
• Bronze > 1.000
• Silver > 5.000
• Gold > 10.000
• Platinum > 20.000

Main reason for lowering amounts is due to last years results of high increase in the same. As for the benefits of these levels, the only thing changed is t-shirts / bags places; we believe t-shirts are much more noticeable than bags, and have therefore been promoted to Silver, while bags have been downgraded to Bronze. For a full list of requirements and benefits, please visit: DC11: Sponsorship Sponsorship Brochure

Sponsorship brochures have finally been completed and are available for a public distribution. The brochures are available in 3 qualities: low, high and original. Low and high quality brochures, ~6Mb and ~8Mb respectively, are for normal distribution to our sponsors, while original quality, at around 240Mb, is intended for maximum quality printing. Just as with the website, each quality is available in both Bosnian and English. Current version of the brochure is 1.1 and is most likely the final one. These brochures are available at Documentation page: DC11: Documentation >> Documents made by Local Team Or download them directly:

• Sponsorship Brochure LQ [en]
• Sponsorship Brochure HQ [en]
• Sponsorship Brochure OQ [en]
• Sponsorship Brochure LQ [ba]
• Sponsorship Brochure HQ [ba]
• Sponsorship Brochure OQ [ba]

Also, I d like to thank Mirosal Remetic for making a great template and Pablo Duboue for some very valuable suggestions regarding the structure of the brochure.

Visas and Customs Rules

Many questions have been raised regarding Bosnian visa regime. We got in contact with the embassy and they clarified who can enter our country with(out) Visa. The list can be found on DC11 Wiki: Visa regime. It also states, which countries have a privilidge of ID-only entrance. If your country is not listed, that means you will need visa. If you want to know what exactly you need to get one, please visit the this official Government page and chose your country from a drop-down menu. As for the visa itself, as well as the list of Customs Rules, please read DC11: Visa.

Also, thanks to Darjan Prtic for getting the list from the Government officials.

So, what s next?

If you think, that is it for now, you are dead wrong. At this very moment following is being organized and developed:

• Registration Registration Team is currently hacking penta and modifying it for this years needs and conditions. We expect to have registrations open by the end of March / beginning of April.
• Travel and getting to Banja Luka Being one of the greatest obstacle, Travel Team is working hard on finding best routes for attendees and mapping the city
• Sponsorship With final decision and agreement for sponsorship levels and brochures ready for public distribution, Sponsorship Team is now actively looking for new sponsors, global and local, preparing various promotional material, as well as planning our advertising strategy.

Final word

Well, these are pretty much the highlights of some recent and some future developments of DebConf11 organizational team. Mind you, there s a lot more going on, but I tried to give a small summary from the inside. Should you be interested in attending, helping out, sponsoring or just have some questions, feel free to ask them on our mailing list at: debconf11-localteam@lists.debconf.org. I should inform you that this is a public mailing list and its archives are available for a broader public. If you do not wish for your mail to be made public, please direct any enquiry directly to me trough the Contact Form or any other member of Core Local Team, Adnan Hodzic or Velimir Iveljic.

A while back I was working on a mod_rewrite compatible proxy server written in C. The reason for this is that my current webhost uses Apache2 in front ofa number of thttpd processes, and I'd like to remove apache and use something smaller/faster/neater. Dividing things up I'm running about ten domains, and only around half of them use mod_rewrite rules - small enough perhaps to port the rules, large enough to make it annoying. Upon reflection I think the thing to do is to replace apache with javascript - via node.js. Writing proxies with node.js is almost ridiculously simple - in fact doing anything HTTP-like is very very simple thanks to the bundled libraries. Time will tell whether this is a waste of time or not, but I'm confident I could listen upon *:80 and route requests to localhost:N for a few domains. As a trivial toy I wrote a simple transforming proxy last night which performed simple rewrites as it passed traffic about. Another fun, and possibly useful, thing I put together was a node.js port of the simple httpstat.us website. That server would have been easy to write in any number of languages, but in node it was almost too easy. Update - here is my rewriting node.js-based reverse-proxy. ObQuote: "I just need you to stop being nice to me unless you're gonna marry me. " - He's just not that into you.

You know it already, since Debian 6.0 non-free firmware are no longer provided by a standard Debian installation. This will cause some troubles to users who need them. I m thus going to do a small overview on the topic and teach you what you need to know to deal with the problem. What are firmware and how are they used? From the user s point of view, a firmware is just some data that is needed by some piece of hardware in order to function properly. The driver for that hardware typically loads the firmware on the device as part of its initialization. In the Linux kernel, the drivers are all using a standardized interface (request_firmware) to retrieve the firmware before sending it to the device. Thanks to this standardization, it s possible to either embed the firmware in the kernel or to have it request the firmware from user-space when needed. Debian (like most distributions) has selected the latter option. Thus when the kernel needs a firmware, it sends out a request to user-space. udev is getting the request with the name of the firmware, and in its default configuration (see /lib/udev/rules.d/80-drivers.rules) it executes /lib/udev/firmware.agent in response. Where are firmware stored? firmware.agent is a simple shell script that tries to locate a firmware before sending it back to the kernel through a sysfs entry. It looks into the following directories:

• /lib/firmware/$(uname -r)
• /lib/firmware
• /usr/local/lib/firmware
• /usr/lib/hotplug/firmware

Firmware provided by packages are thus usually in /lib/firmware and you can use /usr/local/lib/firmware for manually installed firmware. How do I know whether I need a firmware? First of, you can notice messages from the kernel telling you that it tried to load a firmware but it failed. They look like this:

e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin": -2

But you might be informed sooner. When you install a new version of the Linux kernel with the official Debian packages, the post-installation script will go through all loaded modules (those listed by lsmod) and it will verify whether this module as provided by the newly installed kernel might require firmware files. This information can be retrieved with modinfo:

$ modinfo -F firmware /lib/modules/2.6.32-5-amd64/kernel/drivers/net/e100.ko
e100/d102e_ucode.bin
e100/d101s_ucode.bin
e100/d101m_ucode.bin

If one (or more) of those firmware is (are) not yet available on the system, you will get a warning message similar to this one:
update-initramfs will also generate a similar warning on the terminal:

update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
W: Possible missing firmware /lib/firmware/e100/d102e_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101s_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101m_ucode.bin for module e100

The Debian installer also detects when you have hardware that might require a missing firmware file. You have the option to supply the missing files on a USB stick (either directly or through the corresponding package). How do I find and install the missing firmware? Now that you have the name of the firmware file that you want, it s relatively easy to identify the package that provides the required file. You can use apt-cache search <filename> because the firmware packages embed the list of firmware files in their description. You can also use apt-file (provided by the package of the same name) or the web interface at packages.debian.org.

$ apt-cache search d101m_ucode.bin
firmware-linux-nonfree - Binary firmware for various drivers in the Linux kernel
$ apt-file search d101m_ucode.bin
firmware-linux-nonfree: /lib/firmware/e100/d101m_ucode.bin

If the above commands return nothing, you probably need to enable the non-free repository in your /etc/apt/sources.list (you can also enable it within synaptic). And you also want to run sudo apt-file update to have the latest information. Now you can install the right package, in the example above it was firmware-linux-nonfree. How do I install all firmware just to be sure I don t miss any? There s no meta-package depending on all firmware packages so there s no easy answer to this question. Furthermore not all firmware packages respect the naming convention firmware-* (there s for example zd1211-firmware). So your best bet is to look up all the packages with a generic search like this one:

$ apt-file --package-only search /lib/firmware/
atmel-firmware
[...]

And then install them all. Are there DVD or CD images with non-free firmware? Yes. Debian provides an unofficial netinst image for i386/amd64/powerpc with the non-free firmware, you can find it here: http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/. I provide complete DVD sets with firmware, and Multi-Arch CD/DVD with firmware, it s over there in my DVD shop: http://raphaelhertzog.com/go/debian-cd/ (i386/amd64 only) When using those installation discs, the Debian-installer will be able to find the required firmware immediately. There s no need for you to provide them on a USB stick. Other questions? I think I covered the most important things you have to know about firmware on Debian. But should you still have a question, feel free to share it in the comments so that I can improve this article.

Click here to subscribe to my free newsletter and get my monthly analysis on what s going on in Debian and Ubuntu. Or just follow along via the RSS feed, Identi.ca, Twitter or Facebook.

6 comments Liked this article? Click here. My blog is Flattr-enabled.

I've changed jobs recently and after 5 years of not having to work with a Windows system I am having all sorts of adaptation-to-Windows problems at the new job.

First I just had to have the usual X-mouse behaviour and so I installed True X-Mouse Gizmo for Windows. This provides focus under mouse, middle click paste after select (not perfect, but it works), right click to push to bottom the window.

Second I had to have a virtual desktop, so I installed Microsoft's Virtual Desktop Manager from the PowerToys page. I tried another virtual desktop manager before using MSVDM, but I found it too clumsy so I switched to MSVDM which I knew from way back when I used Windows the last time. Good, now I can have my applications organised the way I am used to.

UPDATE: I gave up on MSVDM in favour of Virtual Dimension since I wasn't able to send a particular window to the intended desktop unless I had in the taskbar all apps visible (Shared Desktop option). I might try other suggestions (Virtual Dimension does not have a way to send a window directly to a specific desktop, but just to the neighbours of the current one.)


Third, I had to make Caps Lock work as Ctrl. I just can't go back to an inferior setup. I found information on this page and ended up at this page from where I got a zip file with various registry keys which allow the deactivation of caps, or turning it into another Ctrl.

Fourth, I am used to write with diacritics in Romanian with the secondary layout of the standard (SR 13392:2004), so I rushed to Cristian Secar 's page for the keyboard driver since on XP the Romanian layout is retarded (some history in which some arbitrary German guy decided y and z had to be switched on Romanian keyboards and some other similarly weird stuff). Since the installation, my keyboard behaves according to this layout:




Things started to look well, but I soon was reminded that Outlook is an idiotic mailer since it doesn't require a confirmation on send, not even if you didn't set a subject. And this is problematic since sending the mail is done via Alt+S, so if the current layer is NOT Romanian, when I want to type (s with a comma below), a fairly common character in Romanian words, you end up looking like an idiot on the recipient side since they receive an incomplete mail. Remember, no confirmation AND no default spell checking before send. Yay!

At my second such accidental mail sending (of which the last two were sent to the same person), I decided to see if this can't be fixed. I initially looked for changing the short cut, but I couldn't find it (I might be inept at finding things in Windows, remember, I haven't touched Windows systems in the last 5 years) but I found another workaround and decided it's good enough to share with other people that might hit the problem.

Just setup a delay rule following these steps.
1. Go to Tools....Rules Wizard
2. Click 'New' Rule
3. Select "Check messages after sending"
4. Click Next on "Which conditions you want to Check?" dialog.
5. Press yes to "This Rule will be applied to every message" message box
6. In the "What do you want to do with message?" dialog, Select "Defer delivery by a number of minutes"
7. Select your favourite number of minutes.... I usually select 2 mins.
8. Select Finish. and close the Rules Wizard.

Now everytime you send an email it will sit in your outbox
for specified number of minutes. If you ever wanted to change it, delete it etc, You have sufficient time to do it :)

I used 3 minutes for the delay. At least now I can prevent looking retarded in front of people... more than necessary :D .


Oh, and Windows' clock display is retarded. It shows, by default, the hour and minutes, but there's no way to change that in a sane way. If you want the date, you must hover over the clock and it shows it, but the day of week is missing. Great job! You can see that information, too, but you have to drag the toolbar to be 2 or even 3 rows high (here it requires 2, but I've seen people saying they needed 3) to get that information, too. Great! One has to choose between wasting desktop real estate and having access to useful information. Or you could install an independent application for the clock... retarded. I am not making this shit up.

I hope this helped.

Getting a birthday present is always nice, of course. This one made me itch to go outside and hunt for nice motifs, though ... Images are straight from the camera, just a bit cropped (look at the EXIF if you feel like it.) If you don't want to look at the EXIF: the beautiful new lens is the Canon Canon EF 70-200mm 1:2.8 L IS II USM (like all manufacturers, Canon likes to collect funny abbreviations at the end of their product names though I feel they're not as bad as some...), and I truly like what I'm seeing so far. That this lens has excellent sharpness goes without saying (especially on the 40D with modest 10MPixel on a crop sensor), see the comparison with the old EF 100-300mm f/4.5-5.6 USM (the piccolo picture.) Beyond sharpness, there's the 1:2.8 aperture, the IS really keeps what it promises (and is absolutely silent), and AF is quiet and ultra fast as well. I've only got it today, so I took only a few shots I'm confident that CA, flare resistance etc. will live up to reputation though. Now I'm really starting about a full frame camera with higher MP count to take full advantage of my lenses (you may remember that I quite like decent equipment; the wideangle is said to be usable for full frame down to ca. 14mm although it's really designed for crop sensor...) The obvious question is if I really can take better pictures just because I'm now lugging around a 6kg bag of stuff ... but honestly, having a telephoto lens without image stabilisation was a pain, so getting the old tele replaced was the obvious next step.Oh yes, and: see you in Banja Luka! :-)

Those who followed the live stream or read our News already knew it: Debian has been honored with the Linux New Media Award in the Categories "Best Open Source Server Distribution" and Outstanding Contribution to Open Source/Linux/Free Software. Especially the second one, considered to be the "kings class" of the LNM awards, is a great honour. While it is called the Linux New Media award, the decision of whom to honor with them isn't done by the company themselves, but by a bigger jury, consisting of over 300 representative community members, developers, journalists and companies. Deciding in a secret vote¹. To the best of my knowledge, there's nothing similar. So one can truly say, we weren't awarded by a company, but by the entire Free Software community! Congratulations to everyone involved! For our Outstanding Contribution to Open Source/Linux/Free Software award, we also had the special pleasure, to receive our presentation speech from Karsten Gerloff, president of the Free Software Foundation Europe, who found words, I can hardly explain myself. As it might take some time for the video of the award ceremony to be published and several people already asked for it, you'll find the text of the speech below. Still, you might want to watch the video for a special surprise by Karsten:

I'm here to congratulate the Debian project. Debian has recently taken a nearly unprecedented step, one that many people thought would never come to pass: The project has updated its website design. Today, Debian receives the Linux New Media Award for its outstanding contribution to Free Software. I could hardly think of a more fitting recipient for such an award. Debian is coming of age, literally. In August, the distribution will turn 18. Debian offers great technology. It's stable. Really stable. It's highly flexible, and performs well in lots of different roles. IT supports more different architectures than almost anything else out there. It runs on pretty much anything. The package management is great. It makes a highly complex system of almost 30,000 packages extremely simple to configure and use. Debian started out as a true pioneer. When the project was created in 1993, the whole concept of a distribution wasn't too well established. Ian Murdock announced the project thus:

"Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the past, Debian is being developed openly in the spirit of Linux and GNU. [...] Debian is being carefully and conscientiously put together and will be maintained and supported with similar care." At a recent conference, the current Debian project lead, Stefano Zacchiroli, gave a talk titled Who the bloody hell cares about Debian? Turns out that many people do indeed. Debian is the GNU/Linux distribution that has the most derivatives based on it currently 128, if Distrowatch.com is to be believed: Ubuntu, Knoppix, gNewSense, and many more. And those distributions again have their own derivatives. None of these could function without Debian. Lots of people rely on Debian. That makes it all the more important that Debian is so reliable. The Debian project gives us Free Software that is both rock-solid and exciting. But the greatest thing about Debian is not the fact that it delivers great software. Other distributions do that, too. The big thing about Debian is the *idea* of Debian: The idea that a massive Free Software project can be totally independent. Debian shows how it's possible to build a highly reliable operating system without a formal body. The project has created some pretty complex structures to run itself, as a do-ocracy, based on consensus and running code. This is important. We are currently debating how Free Software projects can best be governed in the long run. How do we make sure that a project's users can always enjoy the freedom they deserve? How can we structure a project in a way that makes it immune to a hostile takeover? Oracle's acquisition of Sun has shown that these are important question. A Free Software license, preferably one like the GPL that protects freedom in the long run, is an important first step. But a Free Software project consists of much more than code. While uncounted people and companies are earning good money with Debian, the Debian project itself can't be bought simply because there is noone you could buy it from. Debian has been doing vendor independence long before it was cool. What I love most about Debian is that like few other big projects, Debian has the idea of freedom at its core. Debian's Free Software guidelines are a central manifesto for software freedom. The Debian Social Contract does not mention a single package or program. But it is without a doubt one of Debian's most important pieces of documentation. In Debian, quality is the focus of everyone's attention. But those who work on the Debian system know that great software is worth nothing without Freedom. With the release of Squeeze, the latest stable version, in February, Debian has taken the important step of offering a completely free kernel, with no binary blobs. This is a first for a major distribution in recent times. Debian is giving its users Freedom by default. And this Freedom for users and developers on a massive scale truly is Debian's outstanding contribution, not just to Free Software, but to the information society. On behalf of the Free Software Foundation Europe, I would like to thank everyone in Debian for their work, and congratulate them on this award. It's well deserved. Keep up the good work!

1: I forgot to mention one small, but important detail: The voting period for the jury ended on December 23, 2010, so long before Squeeze was released. So we can be quite sure, that the Jury didn't followed the Squeeze-Hype with their decision, but really thinks, we did something great :)

Time for a seventh Debian XSF News issue!

• On the documentation side, I tried to come up with a squeeze backports policy. There are some new upstream releases and xorg-server 1.10 coming up (read below), as well as X stack s migration to testing, to consider before thinking of backporting though.
• Where backports will likely help is for old intel cards (see our FAQ entry). According to Chris Wilson, current kernels/intel drivers are better for 855+, but 830/845 still need a miracle.
• Migrating the X stack to testing needs a bit of coordination, because of the always painful dependency between the nouveau driver and the Linux kernel version. As mentioned in my mail to debian-release@ that would be quite self-contained otherwise. Bottom line: we re waiting for the kernel.
• As announced on debian-x@, the plan is to wait for this migration to happen before uploading new upstream releases of libdrm, the intel driver, and mesa to unstable. Both libdrm and mesa were prepared for Ubuntu, and will be likely uploaded to experimental soon. The intel driver was prepared, but only built against xorg-server 1.10 and uploaded to experimental for now.
• On the xorg-server 1.10 side, the (very late) RandR patches were proven broken, so reverting RandR 1.4 was decided. With some minor tweaks (to the radeon driver), that went quite well, and xorg-server 1.10 got released. Unfortunately, there s still some missing fix for the build system, which explains why I didn t upload a final 1.10 to experimental yet; several patches were proposed already (I checked a bunch of them), but we re still waiting for a final patch.
• As a result of the RandR 1.4 reverts, the video ABI was broken again. Fortunately I gave it a quick try right before 1.10rc3 got released, and noticed the breakage, so the video ABI got bumped. I was therefore very happy with my decision to only upload a bunch of drivers to experimental, built against 1.10rc* (see DXN#6), since I only needed to upload the following video drivers again: ati, dummy, fbdev, intel, mach64, nouveau, r128, vesa. It might make sense to add cirrus to that list next time, for tests under kvm and the like.
• After I poked Peter Hutterer, he kindly and promptly released snapshots for the following input drivers: kbd, mouse, and synaptics, which I uploaded both to unstable (built against 1.9), and to experimental (built against 1.10).
• If you re having troubles with your synaptics device, make sure you have no configuration issues in xorg.conf; even if that used to work somehow, autoconfiguration might fail if there s a misconfigured device (for example, wrong Device option there). You might want to have a look at our how to configure input documentation.
• On the driver side, for 1.9/unstable, Tormod Volden prepared updates for the mga and savage video drivers, which I sponsored.
• Julien Viard de Galbert prepared a new xserver-xorg-video-openchrome snapshot, which I uploaded to unstable.
• He also prepared the addition of a debug package, which I also sponsored after setting the Dm-Upload-Allowed field to yes since he s doing a pretty good job already. It s currently sitting in NEW accordingly.
• A while ago, Thibaut Girka requested the addition of an udeb for the libxtst library, it s now sitting in NEW. Thibaut is working on a virtual on-screen keyboard, initially for use in the Graphical Installer for devices lacking a keyboard (but likely useful in other circumstances). Work is going on, stay tuned.
• Steve Langasek was kind enough to MultiArch-ify both libx11 and xorg; both were uploaded.
• Wayland is getting way more funnier than planned: it is now needed to get mesa built against wayland libraries (to get the wayland EGL platform), and the needed mesa bits are (last I asked) only in master for now.
• On the bugs side, I spent many hours pinging submitters and triaging bugs, mostly on the ati and intel video drivers, as well as on xorg-server again, along with the xorg meta package. (Clicking on a bug graph below leads to a cached full-year view.)

  x-x-video-ati	x-x-video-intel	xorg-server	xorg

• According to the UDD view of XSF bugs, and to Julien s TXBW1, we went down from 880 bugs in november to 540 bugs now.

Christian is a figure of Debian, not only because of the tremendous coordination work that he does within the translation project, but also because he s very involved at the social level. He s probably in the top 5 of the persons who attended most often the Debian conference. Christian is a friend (thanks for hosting me so many times when I come to Paris for Debian related events) and I m glad that he accepted to be interviewed. He likes to speak and that shows in the length of his answers but you ll be traveling the world while reading him. My questions are in bold, the rest is by Christian. Who are you? I am a French citizen (which is easy to guess unless you correct my usual mistakes in what follows). I m immensely proud of being married for nearly 26 years with Elizabeth (who deserves a statue from Debian for being so patient with my passion and my dedication to the project). I m also the proud father of 3 wonderful kids , aged 19 to 23. I work as team manager in the Networks and Computers Division of Onera the French Aerospace lab , a public research institute about Aeronautics, Space and Defense. My team provides computer management services for research divisions of Onera, with a specific focus put on individual computing. I entered the world of free software as one of the very first users of Linux in France. Back in the early 1990 s, I happened (though the BBS users communities) to be a friend of several early adopters of Linux and/or BSD386/FreeBSD/NetBSD in France. More specifically, I discovered Linux thanks with my friend Ren Cougnenc (all my free software talks are dedicated to Ren , who passed away in 1996). You re not a programmer, not even a packager. How did you come to Debian? I m definitely not a programmer and I never studied computing (I graduated in Materials Science and worked in that area for a few years after my PhD). However, my daily work always involved computing (I redesigned the creep testing laboratory and its acquisition system all by myself during my thesis research work). An my hobbies often involved playing with home computers, always trying to learn about something new. So, first learning about a new operating system then trying to figure out how to become involved in its development was quite a logical choice. Debian is my distro of choice since it exists. I used Slackware on work machines for a while, but my home server, kheops, first ran Debian 1.1 when I stopped running a BBS on an MS-DOS machine to host a news server. That was back in October 1996. I then happened to be a user, and more specifically a user of genealogy software, also participating very actively in Usenet from this home computer and server, that was running this Debian thing. So, progressively, I joined mailing lists and, being a passionate person, I tried to figure out how I could bring my own little contribution to all this. This is why I became a packager (yes, I am one!) by taking over the geneweb package, which I was using to publish my genealogy research. I applied as DD in January 2001, then got my account in July 2001. My first upload to the Debian archive occurred on August 22nd 2001: that was of course geneweb, which I still maintain. Quite quickly, I became involved in the work on French localization. I have always been a strong supporter of localized software (I even translated a few BBS software back in the early 90 s) as one of the way to bring the power and richness of free software to more users. Localization work lead me to work on the early version of Debian Installer, during those 2003-2005 years where the development of D-I was an incredibly motivating and challenging task, lead by Joey Hess and his inspiring ideas. From user to contributor to leader, I suddenly discovered, around 2004, that I became the coordinator of D-I i18n (internationalization) without even noticing You re the main translation coordinator in Debian. What plans and goals have you set for Debian Wheezy? As always: paint the world in red. Indeed, this is my goal for years. I would like our favorite distro to be able to be used by anyone in the world, whether she speaks English, Northern Sami, Wolof, Uyghur or Secwepemcts n. As a matter of symbol, I use the installer for this. My stance is that one should be able to even install Debian in one s own language. So, for about 7 years, I use D-I as a way to attract new localization contributors. This progress is represented on this page where the world is gradually painted in red as long as the installer supports more languages release after release. The map above tries to illustrate this by painting in red countries when the most spoken language in the country is supported in Debian Installer. However, that map does not give enough reward to many great efforts made to support very different kind of languages. Not only various national languages, but also very different ones: all regional languages of Spain, many of the most spoken languages in India, minority languages such as Uyghur for which an effort is starting, Northern Sami because it is taught in a few schools in Norway, etc., etc. Still, the map gives a good idea of what I would like to see better supported: languages from Africa, several languages in Central Asia. And, as a very very personal goal, I m eagerly waiting for support of Tibetan in Debian Installer, the same way we support its sister language, Dzongkha from Bhutan. For this to happen, we have to make contribution to localization as easy as possible. The very distributed nature of Debian development makes this a challenge, as material to translate (D-I components, debconf screens, native packages, packages descriptions, website, documentation) is very widely spread. A goal, for years, is to set a centralized place where translators could work easily without even knowing about SVN/GIT/BZR or having to report bugs to send their work. The point, however, would be to have this without making compromises on translation quality. So, with peer review, use of thesaurus and translation memory and all such techniques. Tools for this exist: we, for instance, worked with the developers of Pootle to help making it able to cope with the huge amount of material in Debian (think about packages descriptions translations). However, as of now, the glue between such tools and the raw material (that often lies in packages) didn t come. So, currently, translation work in Debian requires a great knowledge of how things are organized, where is the material, how it can be possible to make contribution reach packages, etc. And, as I m technically unable to fulfill the goal of building the infrastructure, I m fulfilling that role of spreading out the knowledge. This is how I can define my coordinator role. Ubuntu uses a web-based tool to make it easy to contribute translations directly in Launchpad. At some point you asked Canonical to make it free software. Launchpad has been freed in the mean time. Have you (re)considered using it? Why not? After all, it more or less fills in the needs I just described. I still don t really figure out how we could have all Debian material gathered in Rosetta/Launchpad .and also how Debian packagers could easily get localized material back from the framework without changing their development processes. I have always tried to stay neutral wrt Ubuntu. As many people now in Debian, I feel like we have reached a good way to achieve our mutual development. When it comes at localization work, the early days where the everything in Rosetta and translates who wants stanza did a lot of harm to several upstream localization projects is, I think, way over. Many people who currently contribute to D-I localization were indeed sent to me by Ubuntu contributors .and by localizing D-I, apt, debconf, package descriptions, etc., they re doing translation work for Ubuntu as well as for Debian. Let s say I m a Debian user and I want to help translate Debian in my language. I can spend 1 hour per week on this activity. What should I do to start? Several language teams use Debian mailing lists to coordinate their work. If you re lucky enough to be a speaker of one of these languages, try joining debian-l10n-<yourlanguage> and follow what s happening there. Don t try to immediately jump in some translation work. First, participate to peer reviews: comment on others translations. Learn about the team s processes, jargon and habits. Then, progressively, start working on a few translations: you may want to start with translations of debconf templates: they are short, often easy to do. That s perfect if you have few time. If no language team exists for your language, try joining debian-i18n and ask about existing effort for your language. I may be able to point you to individuals working on Debian translations (very often along with other free software translation efforts). If I am not, then you have just been named coordinator for your language I may even ask you if you want to work on translating the Debian Installer. What s the biggest problem of Debian? We have no problems, we only have solutions We are maybe facing a growth problem for a few years. Despite the increased welcoming aspects of our processes (Debian Maintainers), Debian is having hard times in growing. The overall number of active contributors is probably stagnating for quite a while. I m still amazed, however, to see how we can cope with that and still be able to release over the years. So, after all, this is maybe not a problem Many people would point communication problems here. I don t. I think that communication inside the Debian project is working fairly well now. Our famous flame wars do of course still happen from time to time, but what large free software project doesn t have flame wars? In many areas, we indeed improved communication very significantly. I want to take as an example the way the release of squeeze has been managed. I think that the release team did, even more this time, a very significant and visible effort to communicate with the entire project. And the release of squeeze has been a great success in that matter. So, there s nearly nothing that frustrates me in Debian. Even when a random developer breaks my beloved 100% completeness of French translations, I m not frustrated for more than 2 minutes. You re known in the Debian community as the organizer of the Cheese & Wine Party during DebConf. Can you tell us what this is about? This is an interesting story about how things build themselves in Debian. It all started in July 2005, before DebConf 5 in Helsinki. Denis Barbier, Nicolas Fran ois and myself agreed to bring at Debconf a few pieces of French cheese as well as 1 or 2 bottles of French wine and share them with some friends. Thus, we settled an informal meeting in the French room where we invited some fellows: from memory, Benjamin Mako Hill, Hannah Wallach, Matt Zimmermann and Moray Allan. All of us fond of smelly cheese, great wine plus some extra p t home-made by Denis in Toulouse. It finally happened that, by word of mouth, a few dozens of other people slowly joined in that French room and turned the whole thing into an improvized party that more or less lasted for the entire night. The tradition was later firmly settled in 2006, first in Debconf 6 in Mexico where I challenged the French DDs to bring as many great cheese as possible, then during the Debian i18n meeting in Extremadura (Sept 2006) where we reached the highest amount of cheese per participant ever. I think that the Creofonte building in Casar de C ceres hasn t fully recovered from it and is still smelling cheese 5 years after. This party later became a real tradition for DebConf, growing over and over each year. I see it as a wonderful way to illustrate the diversity we have in Debian, as well as the mutual enrichment we always felt during DebConfs. My only regret about it is that it became so big over the years that organizing it is always a challenge and I more and more feel pressure to make it successful. However, over the years, I always found incredible help by DebConf participants (including my own son, last year a moment of sharing which we will both remember for years, i think). And, really, in 2010, standing up on a chair, shouting (because the microphone wasn t working) to thank everybody, was the most emotional moment I had at Debconf 10. Is there someone in Debian that you admire for their contributions? So many people. So, just like it happens in many awards ceremonies, I will be very verbose to thank people, sorry in advance for this. The name that comes first is Joey Hess. Joey is someone who has a unique way to perceive what improvements are good for Debian and a very precise and meticulous way to design these improvements. Think about debconf. It is designed for so long now and still reaching its very specific goal. So well designed that it is the entire basis for Joey s other achievement: designing D-I. Moreover, I not only admire Joey for his technical work, but also for his interaction with others. He is not he loudest person around, he doesn t have to .just giving his point in discussion and, guess what? Most of the time, he s right. Someone I would like to name here, also, is Colin Watson. Colin is also someone I worked with for years (the D-I effect, again ) and, here again, the very clever way he works on technical improvements as well as his very friendly way to interact with others just make it. And, how about you, Rapha l? I m really admirative of the way you work on promoting technical work on Debian. Your natural ability to explain things (as good in English as it is in French) and your motivation to share your knowledge are a great benefit for the project. Not to mention the technical achievements you made with Guillem on dpkg of course! Another person I d like to name here is Steve Langasek. We both maintain samba packages for years and collaboration with him has always been a pleasure. Just like Colin, Steve is IMHO a model to follow when it comes at people who work for Canonical while continuing their involvment in Debian. And, indeed, Steve is so patient with my mistakes and stupid questions in samba packaging that he deserves a statue. We re now reaching the end of the year where Stefano Zacchiroli was the Debian Project Leader. And, no offense intended to people who were DPL before him (all of them being people I consider to be friends of mine), I think he did the best term ever. Zack is wonderful in sharing his enthusiasm about Debian and has a unique way to do it. Up to the very end of his term, he has always been working on various aspects of the project and my only hope is that he ll run again (however, I would very well understand that he wants to go back to his hacking activities!). Hat off, Zack!I again have several other people to name in this Bubulle hall of Fame : Don Armstrong, for his constant work on improving Debian BTS, Margarita Manterola as one of the best successes of Debian Women (and the most geeky honeymoon ever), Denis Barbier and Nicolas Fran ois because i18n need really skilled people, Cyril Brulebois and Julien Cristau who kept X.org packaging alive in lenny and squeeze, Otavio Salvador who never gave up on D-I even when we were so few to care about it. I would like to make a special mention for Frans Pop. His loss in 2010 has been a shock for many of us, and particularly me. Frans and I had a similar history in Debian, both mostly working on so-called non technical duties. Frans has been the best release manager for D-I (no offense intended, at all, to Joey or Otavio .I know that both of them share this feeling with me). His very high involvment in his work and the very meticulous way he was doing it lead to great achievements in the installer. The Installation Guide work was also a model and indeed a great example of non technical work that requires as many skills as more classical technical work. So, and even though he was sometimes so picky and, I have to admit, annoying, that explains why I m still feeling sad and, in some way, guilty about Frans loss. One of my goals for wheezy is indeed to complete some things Frans left unachieved. I just found one in bug #564441: I will make this work reach the archive, benefit our users and I know that Frans would have liked that.

---

Thank you to Christian for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

7 comments Liked this article? Click here. My blog is Flattr-enabled.

I'll collect here links to the various linux-2.6 distribution trees based on the longterm release 2.6.32. I won't go into details of bigger external patches (grsec, openvz, rt, xen, ..), which in consequence also aligned themselves on 2.6.32. Important bug fixes usually are connected to some bug report, which may be publicly viewable. So from the patch and changelog entry one can usually assume if a certain patch satisfies the stable criteria and forward it for 2.6.32 longterm inclusion (+ other branches where it might apply). If the patch applies and compiles fine with the Debian tree one can assume that the patch will be fine for upstream 2.6.32 as Debian with small exceptions mostly follows the longterm release: 2.6.32 branch of Debian linux-2.6 (Comment: This is currently only a svn mirror but this bug is worked on for next release). The canonical 2.6.32 linux-2.6 longterm repository is of course on kernel.org maintained by gregkh. Opensuse publishes it's kernel-source on gitorious including all branches and the especially interesting SLE11-SP1 2.6.32 branch. Fedora was following till late Autumn 2.6.32 and the F12 branch has the relevant patches. Ubuntu released 10.04 with 2.6.32 as in a collaborative decision they also based their drm on 2.6.33 (same story as in Debian, thus particularly relevant for us). Oracle had a 2.6.32 that was maintained until Sept 2010 or such. It is already bad that kernel source in Red Hat doesn't really follow upstream 2.6.32 longterm release itself. For 2.6.18 of course no such option existed, but for 2.6.32 this policy already shows a certain snobbery. Red Hat 6.0 Beta at least shipped kernel-2.6.32-37.el6.src.rpm with broken out patches - since then no patch series or git tree to be seen from RH. This strange move got since picked by lwn - RH "obfuscated" kernel source.

Australia s Department of Finance has mandated that the MS-Office document format should be the standard document format for all agencies [1]. Paul Wayper notes the fact that MS doesn t plan to support it s own standards and suggests ODF, also known as ISO/IEC standard 26300:2006. [2].Psychology Today has an interesting blog post by Marnia Robinson about scientific reasons for avoiding porn addiction [3]. Her post links to a number of other posts on the topic on Psychology Today.Psychology Today has an interesting post by Noam Shpancer titled What Doesn t Kill You Makes You Weaker [4]. It seems to me that the belief to the contrary is due to people rationalising bad things that happened to them, it s not all bad as it made me stronger .Psychology Today has an interesting article by Noam Shpancer about the soldier as hero myth [5]. He argues that soldiers are really just employees, the risk to American soldiers in war zones really isn t that great and that they are just pawns to the military-industrial complex.Anders Ynnerman gave an interesting TED talk about visualising medical data which includes many startling 3D pictures of humans and animals that are being scanned [6]. He describes how this is useful in forensic analysis by the police and in better understanding biological processes.Margarita Manterola gave an interesting Debconf talk titled Making Debian Rule, again , she has some interesting ideas for improving Debian [7]. She is most focussed on social problems and the questions and comments had some interesting ideas. The Center for Non-Violent Communication [8] was mentioned in the questions, apparently their success includes teaching better communication skills to violent criminals, so it seems that they can help with some big problems.Benjamin Mako Hill wrote an interesting article about the ratio of writers to readers on Wikipedia [9]. While he makes some good points I m wondering about the measure of an editor , there have been few months where I have made 5 edits, so I guess I m just a reader. I probably should take more care in logging in when I make changes though, I ve made more than a few small changes from random systems (client sites, Internet cafes, etc) without bothering to login. This would mess up the stats a bit.The Reid Report has an interesting article about Bush being limited in his international travel due to the fact that he has admitted being a war criminal [10].Understanding Prejudice is an interesting article that summarises a lot of psychological research [11]. It gives many ideas for anyone who wants to reduce prejudice.Robin Harris wrote an interesting ZD Net article about vibrations and the impact on disk performance [12]. Apparently it s very common to be able to get more performance from drive arrays if you dampen vibration, previously I believed that unless you had extreme vibration to cause catastrophic problems then nothing would go wrong. But it seems that even smaller amounts of vibration can cause a 30% performance loss or worse! There is work in progress on vibration-damping racks.In a story published in The Australian about the NSW ambulance service being shut down due to a virus, Professor Caelli cites SE Linux as an example of a technology to make computers more virus resistant [13]. Professor Caelli also states that there should be a legal requirement to have backup systems for computers that have such grave consequences if they crash.Sinclair Community College is offering a new class Fundamentals of Linux Security , it includes SE Linux [14].Slate has an interesting article about Pickpockets [15]. Apparently they are becoming extinct in the US as law enforcement has prevented the Fagins from training younger people, and it s only in Eastern Europe that the skills base remains.

• [1] http://www.itnews.com.au/News/245276,australia-mandates-microsofts-open-office-xml.aspx
• [2] http://www.mabula.net/tbfw/blosxom.cgi/2011/01/19#2011-01-19-minister-leigh-letter
• [3] http://www.psychologytoday.com/blog/cupids-poisoned-arrow/201007/not-all-warnings-about-porn-are-moralistic-or-unscientific
• [4] http://www.psychologytoday.com/blog/insight-therapy/201008/what-doesnt-kill-you-makes-you-weaker
• [5] http://www.psychologytoday.com/blog/insight-therapy/201101/soldier-hero
• [6] http://www.ted.com/talks/anders_ynnerman_visualizing_the_medical_data_explosion.html
• [7] http://penta.debconf.org/dc10_schedule/events/627.en.html
• [8] http://www.cnvc.org/
• [9] http://mako.cc/copyrighteous/20110206-00
• [10] http://blog.reidreport.com/2011/02/bush-cancels-geneva-and-other-consequences-of-torture/
• [11] http://www.understandingprejudice.org/apa/english/
• [12] http://www.zdnet.com/blog/storage/bad-bad-bad-vibrations/896
• [13] http://www.theaustralian.com.au/australian-it/world-focus-on-ambulance-system-failure/story-e6frgakx-1226005951185
• [14] http://www.sinclairclarion.com/home/campus/2011/02/07/new-linux-class-starting-in-spring-quarter/
• [15] http://www.slate.com/id/2286010/pagenum/all/

I was going to make this a comment against Ritesh Raj Sarraf's post about patents and pharmaceuticals but the comment got way too long.

The basic problem is that patents on pharmaceuticals cannot be directly compared to patents on software and the explanation gets a bit involved. It's worse than apples and oranges, it's more like comparing an algorithm to a piece of DNA.

Patented pharmaceuticals must declare the precise chemical formula of the molecule (and a whole lot else besides) before the molecule can be brought to market but the company holding the patent is legally prevented from protecting themselves against slightly different molecules which are blatantly based on the protected molecule. All modification results in a new patentable product, legally separated from the original.

Therefore, the first company to patent a molecule from a new class is instantly joined in the field by other companies who are (obviously) watching the research news channels very carefully. (In their shoes, you would do the same or you go bust.) These companies simply add a flourine ion or change a hydrogen to a hydroxl group or any other number of minor, apparently inconsequential, changes. Changes which, in software, would be deemed a derivative work and would be roughly equivalent to changing a single local variable from a 16bit integer to a 32bit integer in a single function in a single file in the entire codebase. i.e. a trivial bug fix or even a typo.

A molecule with a couple of hundred atoms can have a change affecting one atom and be a completely new patentable item without any risk of the other company being sued for patent infringement, plagiarism, copyright violation (there is no copyright) or any other barrier. It's common to find that molecule foo is joined on the market by a desoxyfoo and a flourofoo etc. with a chlorofoo just around the corner, within months of the class-leader being launched. It can't be compared to software - effectively, every new release gets a new patent which covers the entirety of everything contained in that release, even if 99.999999999% of it is precisely the same as is covered under other several other patents held by extremely litigious competitors.

Modification is simply not prohibited - copying without making any changes whatsoever to the active molecule is prohibited. Changes to the inactive ingredients will be prosecuted - changes to the active ingredient will not. Comparing this with software is likely to drive you insane.

For example, the mere process of packaging an upstream release for a distribution would be patent infringement in pharmaceutical terms - UNLESS you deliberately patch the original source to make an utterly trivial and apparently pointless change. At that point, the upstream completely disown your entire release and you would have to fix every bug yourself - without the original upstream even telling you whether they fixed the same bug themselves, because they aren't ABLE to modify the upstream code without starting a whole new project and they won't tell you why or how they changed things. There is no such thing as an alpha-release of a molecule. Every release is final and no subsequent modification is possible - unless it only affects the inactive ingredients, e.g. by adding a slow release coating. These changes can affect the way that the molecule acts on the test subject / patient but must not change the active ingredient itself in any identifiable way. So the upstream can make a new wrapper (new packaging) but nobody else is allowed to do so until the patent expires. Once the patent expires, every one and their dog is allowed to make identical copies of the active ingredient in their own inactive packaging and these are called generics. Generics still need testing to ensure that the active ingredient truly is the same and that the generic behaves in the same way as the original but this process is cheaper than making a change to the active molecule.

A changed active molecule is an entirely new substance, it gets a new patent and it needs to go through largely the same amount of testing as the patented original but the new company still gets a head start on what the molecule is likely to do and what side-effects (by now noticeable with the class-leader product which is in large scale trials or even on the market) would be harmful to the future usefulness of their new, derivative, molecule. The new company simply jumps onto the bandwagon shouting "I want a piece of that action!" and there is absolutely nothing the original company can do about it, except try to show that their original molecule is better than the new competitors and to try and build a substantial market share before everyone switches to the new derivative. (Prescribers are human and tend therefore to be lazy, so unless there's a reason to change, the class leader will still have substantial share even after several derivatives exist.)

It's an arms race - each company tries to create as many of these potential "me-too" variants as possible in-house, put as many as can be (financially) supported through trials, keep pursuing those which don't have prohibitive side-effects / problems in tests and hope that, at the end, one of their versions will actually turn out to have better effectiveness or fewer side-effects. If not, they just have to market one as "as-effective-and-no-more-harmful-but-CHEAPER-than" the class leader. The majority of "me-too" molecules come under this category - even if the company concerned would try to point to infinitesimal differences in trial data to pretend otherwise. All this with the knowledge that the very hour that the patent expires, a dozen generic manufacturers will flood the market with copies which do not need to recover the massive costs of the original research and are therefore massively cheaper.

How much cheaper? patented molecules may cost 30 for 28 doses on Monday and one generic may cost 3p for 500, another may cost 40p for 10,000 on Tuesday, the day after the patent expiry. Generic houses only need to cover the actual costs of manufacture, not the costs of the original patent etc. and by the time the patent expires, the efforts of the patent holder to generate market share mean that economies of scale become evident. The absolute cheapest isn't necessarily the one who gets the contract either, these things all have expiry dates and all 10,000 have to be sold / supplied from a single location within that date to actually deliver the full savings. So then you get satellite generics who buy in quantities of a few million and pack down into 56 or less so that the total purchased quantity can sit on many shelves instead of just one. It's the same tablet in the end, with the same markings too. All that differs is the marking on the foil and the colour of the cardboard. (Oh and the same foil and colour cardboard can contain tablets with different markings from different manufacturers from one batch to the next, all within the branding of the same repackaging company.)

The original patent-holding company also has an interest in generating their own "me-too" derivatives, sometimes marketed under the name of a company which turns out to be solely owned by the parent of the original company. It can get horribly recursive.
Sometimes, the derivative from the sibling company hits the market before the "true" competitor from a different company - simply because all companies try to have many molecules in development at any one time (because most changed molecules fail in testing) and sometimes they get lucky and come up with two v.similar molecules and have to do something to justify the cost of developing both. That can turn out to be a poisoned chalice rather than two golden geese.

Sometimes, the company fails to get enough variants through testing and the company then gets bought out by a rival - who then gains their research and continues experimenting with other derivative molecules based on the ones already tested and dismissed. The limiting factor is the money.

At this point, I must now declare my cards. I used to be a pharmacist and although I am still entitled to call myself the holder of a Batchelor of Sciences degree in Pharmaceutical Sciences I am most definitely no longer a pharmacist. I therefore defer to my still-registered colleagues in case I've messed up any of the detail here. The above cannot be declared as the opinion of a pharmacist. I am an ex-pharmacist who voluntarily chose to resign his registration to take up full time work as a software developer rather than pay the exorbitant costs of maintaining such registration and all the "proof-of-competency" requirements which such registration requires.

Finally, before you ask, I am very happy to be an ex-pharmacist - my erstwhile colleagues have my ongoing sympathy but no matter how much some of them may beg, they all know that I will not be rejoining them on that side of the dispensary bench if I've got any choice in the matter.

Software is just better. It's all just recycled electrons.

Enough news to release another Debian XSF News issue, after less than a week.

• Given HAL is deprecated, and going to die for real at some point, I ve tried to look for alternatives since it s still used on GNU/kFreeBSD to handle input hotplug in the X server. There s devd on the FreeBSD side, but that only lets us know about device updates. I tried to get some input (pun intended) through debian-bsd@/freebsd-x11@/xorg-devel@, played a bit with devd and came up with a proposal. It s quite ugly but it looks like it would work with minimal efforts, and I could then forget about HAL entirely. Guillem proposed something more generic/universal, but unfortunately, I have seen no replies yet.
• I uploaded a new xserver-xorg-video-ati upstream release to unstable, which comes with plenty of bug fixes, and better Evergreen support.
• It looks like the switch to r600 Gallium in mesa was a bit premature, so it s going to be reverted in the next upload.
• I prepared stable updates for xorg-server and xserver-xorg-video-intel, which got both accepted quickly by our nice release managers. Our todo-list for squeeze is now empty again: no more bugs usertagged squeeze-candidate but not squeeze-accepted.
• I also updated xorg-server in unstable, including an important fix to the EXA acceleration layer, especially fixing a bunch of issues with the radeon driver. In other news, a big clean-up happened there, making the good ol build system ( xsfbs ) go away.
• The missing video drivers for 1.9 were uploaded: Julien sponsored qxl, I uploaded the sparc drivers (suncg14, suncg3, suncg6, sunffb, sunleo, suntcx) from a porter box (thanks to the very responsive DSA team for the quick installation of needed build dependencies), and Aur lien Jarno kindly uploaded the newport driver for mips.
• In the meanwhile I uploaded the newly-released xorg-server 1.10rc2 to experimental, but only built a few drivers against it. On the video side, the API didn t change much, so most drivers build without modifications: fbdev, then ati, mach64, r128 (ati depends on the other ones), as well as intel, nouveau, dummy (useful when there s no monitor connected), and vesa. On the input side, many changes happened and one needs new upstream releases, except for the evdev driver (which I uploaded accordingly). Upstream is currently in the process of releasing other input drivers, so the following drivers should hit experimental soon: keyboard/kbd, mouse (both for non-Linux ports), and synaptics (better than evdev for touchpads).
• I put some bits of documentation in xorg-server s README.source mentioning what to keep an eye on when upgrading to a new upstream release. For example, forgetting a version bump in xserver-xorg-dev s dependencies could lead to build failures when xorg-server.pc is used, which is why I uploaded a new xorg-server revision

Enough writing for now, I m getting new mails in xorg-announce@.

Time for a fifth Debian XSF News issue!

• Lintian was tweaked to stop rejecting packages for buggy reasons. The 45 prepared driver packages could be uploaded again, and got accepted, making X installable again in unstable. Plenty of bug reports came along accordingly.
• Julien Cristau uploaded a bunch of packages to unstable (merging stuff prepared in experimental over the last weeks/months, and some new upstream versions): twm, x11-apps, x11-session-utils, x11-utils, x11-xfs-utils, x11-xkb-utils, x11-xserver-utils, xterm, xft, xbacklight.
• He also prepared xorg-server 1.10 for experimental, with Christopher James Halse Rogers. That meant updating randr and xext proto packages. We re currently waiting for 1.10rc2 before uploading to experimental, probably with a restricted set of drivers.
• Thanks to Samuel Thibault s and Pino Toscano s help (and a lot of patience), mesa builds on hurd-i386 again. xorg-server is no longer BD-Uninstallable accordingly. Ditto for kfreebsd-i386, the server was built right after mesa, and all driver packages were built after that.
• In the same mesa upload, I made the bug script report a bit more: it runs glxinfo if available, and the xserver-xorg-core bug script as well. That, together with a report-with: xserver-xorg xserver-xorg-core in the bug control file for each binary package should spare a few mails asking submitters for more info.
• I also uploaded a new libdrm revision, cherry-picking a fix for a bug preventing X to start with some Intel cards. Since we had several reports of run-time issues with older libdrm-intel1 (squeeze s/2.4.21), I bumped symbols/shlibs to make sure packages building against it pick a higher version.
• I uploaded a new xorg-server to unstable with the following changes:
  • The hellish dependency loop (#362313) is finally gone!
  • Since drivers reached unstable, there was no need to keep the virtual packages with both major andminor versions. Those were meant to ease the transition from experimental to unstable, making it possible to install experimental s drivers with unstable s server.
  • The bug script now reports KMS configuration files (/etc/modprobe.d/$driver-kms.conf) and their contents. The lspci call was also updated. Finally, libGL-related diversions are now reported as well.
• Those bug script improvements were cherry-picked in the debian-squeeze branch, which should be finalized next week. This branch also features a bug fix for RandR on nvidia.
• On the documentation side, I started a general FAQ as well as a how to build mesa guide.
• I d like to thank all submitters taking time to report bugs, even more so when they reply quickly with more info. Special thanks to the submitters who forward their bugs upstream, even marking the Debian bugs forwarded accordingly!

As you know, I very often advocate using the bycicle as the main means of transportation in Mexico City. The city is very apt for biking through it, and contrary to the fears of mostly everybody, the city is neither aggressive nor as dangerous as people say. However, I have seen cyclists which seem to be looking for the best ways to be hit by a car, or to hit a pedestrian. Yesterday, I read this note in La Jornada: The local Environment Secretary calls cyclists to respect vial regulations. Many cyclists assume they are a special case of pedestrians, and zig-zag as they please between the road and the walkway, or just stay in the walkway. That is dangerous, both to pedestrians and to themselves. You might find children, elderly or motion-challenged people on your way. Also, not only will pedestrians only expect other people in the walkway, moving at their pace or slightly more, but cars will also not expect somebody moving at 10-20Km/h. A car driver pulling out of his garage, or crossing a street, will not have enough warning when he sees you, and you are very likely to end up in an accident. Since ~5 years ago, Mexico City is growing a grid of Metrob s and confined troleb s cero emisiones (trolleybus) lanes. Many cyclists use those lanes That is VERY dangerous. Public transport vehicles are large, have a lot of inertia, and will take longer to react to finding you ahead of them. Besides, they can go way faster than a regular bike (~60Km/h for metrob s, ~40Km/h for troleb s), and have to stop every couple of blocks. So, you will be uncomfortable if trailing them, and you will be a liability to ~100 people if you go ahead of them. Besides, it is illegal to drive in the confined lanes if you are not a public, semimassive transport vehicle! Surprisingly many people have argued they prefer riding their bicycles against the traffic I think they prefer staring at Death into its blue, glowing eyes (or into its long, thin whiskers)... By far, most cars that hit a bicycle do so from the side, when crossing a road. And if you arrive at a crossing from the wrong way, the way a driver does not expect you, don't expect the driver to be aware of you. Also, in the much less likely event of a car running into you, would it be better to be hit at 80Km/h (60Km/h of the car plus 20Km/h of your own speed on a full frontal crash), or at 40Km/h (substracting instead of adding)? Yes, some people say that looking at the car will allow you to maneuver How far in advance would you know a car coming from the front will hit you? One second? That's 22 meters at 80Km/h (again, if you realize the 60Km/h car is heading straight to you, at 20Km/h). Too short notice for you to do anything Any maneuver will most likely end in an accident. And the driver would not be so much to blame, as he would not be anticipating you riding against the traffic. Make sure you get seen. By night, always use proper lights (red on the back, white on the front, and reflective material to the sides). Day or night, wear bright, reflective clothes (or over-clothes material). Act in a predictable fashion. Remember you are riding a vehicle and are subject to the same rules any driver is A cyclist is not exempt from driving correctly! Do not jump red lights. Never ride on the walkway. Do your best to enjoy the ride. And ride. Yes, ride, take the streets, enjoy the streets. But don't attempt to drive the traffic out of it The streets belong to us all, and we can all share them. PS I also saw this note in the same paper: Sunday Rides in "Campo Militar N mero Uno". The main military field was open as a park this weekend! I have to make sure it is regularly open I am definitively going there!

Sponsoring a package means uploading a package for someone else (usually a new contributor starting out as package maintainer). This is an activity reserved to Debian Developer who are supposed to be knowledgeable about packaging. This article tries to document the process to ensure the sponsor is doing a reasonably good job according to Debian s standards. Sponsoring a package in the Debian archive is not a trivial matter. It means that you verified the packaging and that it is of the level of quality that Debian strives to have. Let s have a look to what you can and should do when you re sponsoring a package. Sponsoring the initial upload Sponsoring a brand new package into Debian requires a thorough review of the Debian packaging. Building the package and testing the software is definitely not enough! You should open every file in the debian directory and look out for potential problems. Here s a checklist that you can use to perform the audit:

• Verify that the upstream tarball provided is the same that has been distributed by the upstream author (when the sources are repackaged for Debian, generate the modified tarball yourself).
• Run lintian. It will catch many common problems. Be sure to verify that any lintian overrides setup by the maintainer is fully justified.
• Run licensecheck and verify that debian/copyright seems correct and complete. Look for license problems (like files with All rights reserved headers, or with a non-DFSG compliant license).
• Build the package with pbuilder (or any similar tool) to ensure that the build-dependencies are complete.
• Proofread debian/control: does it follow the best practices? are the dependencies complete?
• Proofread debian/rules: does it follow the best practices? do you see some possible improvements?
• Proofread the maintainer scripts (preinst, postinst, prerm, postrm, config): will the preinst/postrm work when the dependencies are not installed? are all the scripts idempotent (i.e. can you run them multiple times without consequences)?
• Review any change to upstream files (either in .diff.gz, or in debian/patches/ or directly embedded in the debian tarball for binary files). Are they justified? Are they properly documented (with DEP-3 for patches)?
• For every file, ask yourself why the file is there and whether it s the right way to achieve the desired result. Is the maintainer following the best packaging practices described by the Developers Reference?
• Build and install the packages, try the software. Ensure you can remove and purge the packages. Maybe test the packages with piuparts.

If the audit did not reveal any problem, you can upload the package. But remember that even if you re not the maintainer, the sponsor is still responsible of what he uploaded to Debian. That s why you re encouraged to keep up with the package through the Package Tracking System. Sponsoring an update of an existing package You will usually assume that the package has already gone through a full review. So instead of doing it again, you will carefully analyze the difference between the current version and the new version prepared by the maintainer. If you have not done the initial review yourself, you might still want to have a more deeper look just in case the initial reviewer was sloppy. To be able to analyze the difference you need both versions. Download the current version of the source package (with apt-get source) and rebuild it (or download the current binary packages with aptitude download). Download the source package to sponsor (usually with dget). Read the new changelog entry, it should tell you what to expect during the review. The main tool you will use is debdiff, you can run it with two source packages (.dsc files), or two binary packages, or two .changes files (it will then compare all the binary packages listed in the .changes). If you compare the source packages (excluding upstream files in the case of a new upstream version, for example by filtering the output of debdiff with filterdiff -i '*/debian/*'), you must understand all the changes you see and they should be properly documented in the Debian changelog. If everything is fine, build the package and compare the binary packages to verify that the changes on the source package have no unexpected consequences (like some files dropped by mistake, missing dependencies, etc.). You might want to check out the Package Tracking System to verify if the maintainer has not missed something important. Maybe there are translations updates sitting in the BTS that could have been integrated. Maybe the package has been NMUed and the maintainer forgot to integrate the changes from the NMU in his package. Maybe there s a release critical bug that he has left unhandled and that s blocking migration to testing. Whatever. If you find something that she could have done (better), it s time to tell her so that she can improve for next time. And so that she has a better understanding of her responsibilities. If you have found no problem, upload the new version. Otherwise ask the maintainer to provide you a fixed version.

---

This article will be repurposed to enhance the Debian Developers Reference, hopefully leading to a fix for the wishlist bug #453313. Click here and help me fix more of those. You re also welcome to suggest improvements in the comments. Are there other checks that you re always doing? Do you have some handy tip to make it easier to review a package?

7 comments Liked this article? Click here. My blog is Flattr-enabled.

The backports team is proud to announce the next generation of backports:
squeeze-backports. From now on all contributors will be able to upload
backports of packages available in wheezy (testing) to squeeze-backports.
Additionally the previously announced lenny-backports-sloppy is now officially
open for uploads.

To ensure the basic principle that a system consisting of lenny plus
lenny-backports can be upgraded to squeeze proper, the handling of the
lenny-backports branch has changed. From now on uploads to lenny-backports
need manual approval from a backports team member similar to the handling of
the proposed-updates queue within the regular archive. Feel free to upload
packages here, especially security updates to previously backported versions,
but please ensure the versions are lower than those in stable /
stable-security.

If you feel the need of newer versions for lenny than which are available in
squeeze, please do upload them to lenny-backports-sloppy. The rules for this
suite are practically the same as for squeeze-backports: Do base your uploads
on packages available in testing (wheezy) and build them in the appropriate
environment.

Please remember when using lenny-backports-sloppy you can't easily upgrade to a
plain squeeze. This suite is specificly meant to contain newer versions than
squeeze. While the aim is to only carry packages that will also be provided in
squeeze-backports for upgrade possibilities, we can't guarantee that, so be
careful.

User visible change to squeeze-backports

As the apt maintainers had been so kind to introduce a new archive wide option
in squeeze, the usage of backports.debian.org is easier than ever before: In
the past you had to explicitly configure pinning for the backports repository
to enjoy the full feature set including upgrades to new versions of packages
you had installed from there. As this is cumbersome, errorprone and a nuisance
this new setting got introduced. With this feature backports get handled in a
way that updates for packages installed from squeeze-backports will happen out
of the box.

And last but definitely not least, let us send a big "thank you" to all
contributors that backports.debian.org enjoys to have - you made it possible to
serve more than 1400 binary packages through 837 source backports since
lenny-backports got kicked into life. Keep up the good work.

Thank you very much!