Philipp is a Debian developer since 2005 and a member of the release team since 2008. Since he took the responsibility of Stable Release Manager, the process has evolved for the best. I asked him to explain how the release team decides what s fit for stable or not. His work on the buildd infrastructure is also admirable but I ll let him describe that. My questions are in bold, the rest is by Philipp. Who are you? I m a 24 year old Computer Science student, living in Karlsruhe, Germany. As a student assistant I m currently in two jobs: one is taking care of getting our university IPv6 network in shape, or rather generally getting fringe technologies into the network. The second is taking care of a s390x machine in the basement which my faculty got sponsored recently. In my spare time I tend my Debian duties and I m active in the student council (Fachschaft) as a sys-admin, software developer and until recently as treasurer. I got accepted as a Debian Developer in 2005. I m only really active since I was invited to join the Release Team in early 2008 after I contributed rewrites of some scripts that got lost in a disk crash of ftp-master. In late 2008 I also took on wanna-build/buildd duties. What s your notable achievement within Debian? For one I worked on the deployment of a single buildd/sbuild combination over all of our buildds and I rebased it on the sbuild in the archive several times already. All buildds basically look the same on all architectures, with only few variations. The chroots are now also created in a mostly predictable manner. Then we finally got build autosigning after years of constant poking. However the policy decision to allow it was made by the ftp-masters anyway, for which I m grateful, as it eases the workload of the buildd maintainers, the Security Team and the Release Team quite a bit. On the release side there s the integration of volatile into the proper structures of Debian. But there I m guilty for choosing the bad name squeeze-updates is, in comparision with security s squeeze/updates. Let s see if we can improve that for wheezy. The policy for stable updates have changed over time. Can you summarize what kind of updates are allowed nowadays? All the changes that were made to the policy were driven by the aim to keep stable (and to some lesser degree oldstable) usable throughout its lifetime. I have to admit that we got slightly more liberal in what we accept since I took over. The previous stable update policy included the fixes of critical bugs that break the system in interesting ways and security fixes. We also opened up the possibility of including important fixes for annoying bugs on a case-by-case basis. The whole don t update that much part of the stable release management is rooted in let s don t change the behaviour of a running system and let s have as few regressions as possible . We currently try to counter that with a review process that only allows self-contained fixes that were tested in unstable first, if applicable. In the future I d also like to have a feedback process that includes the users of the packages to report problems more early. In fact that s also why we now send calls for testing to debian-stable-announce one week in advance (see this mail as an example). So stable is updated through point releases that happen roughly every two months for stable and roughly every four for oldstable. They are accompanied by announcements and new CD/DVD sets. To be able to push some updates with less delay to our users and to avoid that they have to pick them from proposed-updates, there is stable-updates. The current policy for this suite is available in this post on debian-devel-announce. It boils down to everything urgent like tzdata, regression fixes and volatile packages. We noticed that some packages in stable just weren t useful anymore when they got updated through volatile. Hence those are folded into stable, too. We also relaxed the rules a bit so that leaf packages like clive, that rely on external websites not to change their URLs, can be updated too. If somebody wonders what happened to the and a half releases Those were intended to mark the inclusion of new hardware support (mostly by including a co-installable new kernel version). This kind of flag point release is thankfully no longer needed because our marvellous kernel team now backports certain hardware drivers to the kernel version in stable. They have some trouble soliciting test feedback for them, though. It would be cool if more people using stable could respond to their calls for testing. What are your plans for Debian Wheezy? Luckily the wanna-build/buildd side isn t much dependent on release cycles. The stable release management also just takes care of what gets dumped on them by the testing RMs. The near-term goals are certainly:

• getting d-i to use some development process in the archive that s compatible with the normal flow of packages into testing and
• hopefully getting wanna-build to use a sane SQL layout and hence better performance

Apart from that my work is mainly squashing the bugs on buildd.debian.org for the wanna-build part, so if you want something fixed, you need to report it, I m afraid. You have several roles within Debian, in particular stable release manager and member of the wanna-build team. Which role do you enjoy more and why? So the regular duties of the SRM, apart from setting up policies, are reviewing requests for uploads to proposed-updates, accepting them, chasing builds and scheduling point releases. It s mainly steady work. As for the Release Team it s working in a fabulous team where everyone s doing an awesome job. For me the wanna-build role is holding the things together and fixing up stuff that breaks while the world continues to evolve. And occassionally taking a stab at the ftp-masters. So rather different. My heart is probably siding with the buildd side because it s infrastructure but release work is fun, too. What s the biggest problem of Debian? Mainly that we re not quick in picking up new technologies and that we got slow on innovation. Distro-wide changes are usually a very big effort to coordinate and to finally complete. I guess people should be able to push fixes for release goals more eagerly into the archive. Also it seems to me that many DDs are actually disengaging from the release process, especially during the freeze but also before, which makes me a bit sad. However I m still not sure how we could counter that. As we re all volunteers you can t suddenly make others love the idea of releasing something together, I guess. Do you have wishes for Debian Wheezy? It s getting old, but there s certainly multiarch. Also a usable Python 3 is something I d really appreciate. Is there someone in Debian that you admire for their contributions? Peter Palfrader did an awesome job of getting a nicely working team together for DSA and got many tasks as automated as they are now. It s a pleasure to work with them and setting up a new buildd is, for example, a real breeze. He also developed a sane archive snapshot service, kudos for that.

---

Thank you to Philipp 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.

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

Earlier this year, I agreed to join the board of Eben Moglen's FreedomBox Foundation, and to chair the recently announced Technical Advisory Committee. To date, most of the time I've been able to personally invest in the foundation has gone towards work "behind the scenes", all of which was necessary, but little of which is worthy of external report or attention. I now believe it's time to take a more active role in communicating what we're actually trying to do, and how I think we can get there. To that end, I intend to be more visible in discussions on the freedombox-discuss mailing list. I'm also accumulating a list of interesting technical challenges that I'll articulate here over time, along with status reports I believe are worthy of broad dissemination.

Gearman is a distributed queue with several language bindings.

While Gearman has a nice Python implementation (python-gearman) of the client and worker, I chose to use the libgearman bindings (python-libgearman) directly since they are already packaged for Debian (as python-gearman.libgearman).

Unfortunately, these bindings are not very well documented, so here's the sample application I wished I had seen before I started.

Using the command-line toolsBefore diving into the Python bindings, you should make sure that you can get a quick application working on the command line (using the gearman-tools package).

Here's a very simple worker which returns verbatim the input it receives:

gearman -w -f myfunction cat

and here is the matching client:

gearman -f myfunction 'test'

You can have have a look at the status of the queues in the server by connecting to gearmand via telnet (port 4730) and issuing the status command.

Using the Python libgearman bindingsOnce your gearman setup is working (debugging is easier with the command-line tools), you can roll the gearman connection code into your application.

Here's a simple Python worker which returns what it receives:

#!/usr/bin/python

from gearman import libgearman

def work(job):
   workload = job.get_workload()
   return workload

gm_worker = libgearman.Worker()
gm_worker.add_server('localhost')
gm_worker.add_function('myfunction', work)

while True:
   gm_worker.work()

and a matching client:

#!/usr/bin/python

from gearman import libgearman

gm_client = libgearman.Client()
gm_client.add_server('localhost')

result = gm_client.do('myfunction', 'test')
print result

This should behave in exactly the same way as the command-line examples above.

Returning job errorsIf you want to expose to the client errors in the processing done by the worker, modify the worker like this:

#!/usr/bin/python

from gearman import libgearman

def work(job):
   workload = job.get_workload()
   if workload == 'fail':
       job.send_fail()
   return workload

gm_worker = libgearman.Worker()
gm_worker.add_server('localhost')
gm_worker.add_function('myfunction', work)

while True:
   gm_worker.work()

and the client this way:

#!/usr/bin/python

from gearman import libgearman

gm_client = libgearman.Client()
gm_client.add_server('localhost')

result = gm_client.do('myfunction', 'fail')
print result

LicenseThe above source code is released under the following terms:

To the extent possible under law, Francois Marier has waived all copyright and related or neighboring rights to this sample libgearman Python application. This work is published from: New Zealand.

Disclaimer: There is a huge discussion going on right now in the debian-devel mailing list, about different ways to rearrange how Debian development happens, and maybe to provide a Debian users with an additional release. This blog entry is not a comment on that discussion, which I am ignoring. The discussion did, however, prompt a dent about "test driven development". That prompted a short exchange of thoughts with Tom Marble, and this blog post is a cleaned up version of my part in that discussion.

Currently Debian development happens roughly like this: all packages are uploaded to a part of the Debian archive called unstable. Once they've been in use for a while without serious problems, they get automatically copied into another part called testing. Every year or two, testing is frozen and any remaining problems are fixed, after which all of testing gets copied into yet another part of the archive called stable, and that's the actual release. There is a little bit of automatic testing, but only a little. Almost all testing is done by people, by them using unstable or testing on their usual computers. If they have problems, they report them. Contrast this with development using Test Driven Development, or TDD, and other modern development methodologies. Here's a rough summary of what I do when I write (much) of my software.

• first write one or more automatic tests (unit or functional ones)
• write the actual code, enough to make all tests pass
• add more tests
• write more code, or change existing code
• repeat this until tests describe all the behavior desired of the code

In addition, I measure coverage to make sure all parts of the code gets tested. I usually aim for 100% coverage, except for those parts that very hard or quite pointless to test. (That's easier to achieve than you'd think, but that's the topic of another blog post.) This all sounds like a lot of bureaucratic nonsense, but what I get out of this is this: once all tests pass, I have a strong confidence that the software works. As soon as I've added all the features I want to have for a release, I can push a button to push it out. (Well, actually there's a little bit more to it.) This does mean I never have bugs in my software. Of course I do. However, there's a lot fewer of them. In fact, there's so few of them, after tests pass, that I would almost be happy to make an automatic release after every successful run of "make check". Another aspect of the way I do development is distributed version control. The relevant feature is powerful branching and merging. Most things I develop happen in short-lived single-purpose branches: whenever I start work on a feature or bugfix, I create a branch for it. (Unless I'm feeling particularly lazy, which happens more often than you'd think.) When I've finished the feature, or fixed the bug, I merge the branch back into the trunk branch. This way, the trunk is always in releaseable state. It might not have all the features I want for the next release, but the features that are there, do work. The branch probably has bugs, but if I've written tests that are good enough, I know the software works well enough. Or that's the idea. Sometimes things go wrong. Then I write more tests and the next time goes better. (It doesn't have to be perfect, as long as it gets better every time.) See the contrast between automatic tests with good coverage, and the Debian style of relying on user feedback? There's no need to wait for user feedback with automatic tests. This speeds up development, makes releasing easier, but most importantly takes away any reason to fear making changes, even big changes. Automatic tests and good test coverage are easy achieve in small projects. For a system as huge as Debian, good test coverage is quite hard to achieve. The thing about automatic tests, though, is that even a little bit of it is helpful, and after you have a few tests, it gets easier to add more. The first test is the hardest to get done, since you need to set up all the infrastructure for it. Debian does do a bit of automatic testing already. (See lintian, piuparts, autopkgtest, edos, etc.) I don't want to belittle that, but I think we could do better. Here's what I would love to see:

• we have a part of the archive that corresponds to a trunk branch, i.e., it is always in a releasable state (the "testing" area was originally meant to be that; we could make it so now)
• releaseable state is determined by two things:
  • an automatic test suite
  • user feedback, particularly in the form of bug reports (as now)
• whenever changes are made, they happen in "branches"
  • the branch is not affected by changes elsewhere in the archive, except by manual synching ("merge from trunk")
  • individual package uploads, as well as groups of packages such as for transitions, are each in their own branch
  • this is sort of similar to a PPA, but more powerful
• when a branch is to be merged into trunk, the automatic tests must first pass (or at least no new failures in them can be introduced)
  • tests can also be run for any other branch, of course, so that those developing the branch know if they're ready to push their changes into trunk
• there's a culture of writing tests for bugs (whenever that is feasible), and for new features
  • particularly release goals should be expressed as automatic test suites
• there's a culture of sharing tests with upstreams, and with other distributions

Since full test coverage is going to be impossible for Debian, some subset should be targeted. Perhaps something like this would suffice to start with:

• a version of debian-installer is generated from a branch
• test installation of a new system from scratch
  • with a large set of tasks selected
• test upgrade from previous stable release to the branch
  • with a large set of packages installed (as many as possible, actually)
• test upgrade from trunk branch to branch to be merged
  • ditto large set of packages
• test with lintian, reject on specific tests failing
• test with piuparts
• test the whole system for specific functionality
  • ssh access from outside
  • sudo access for a logged in user
  • sending mail with SMTP
  • web server
  • possibly test specific web applications
  • possibly test Samba and NFS services
  • possibly test printing services (CUPS)
  • possibly test essential desktop functionality (automatic login, at least)
• if package comes with package specific tests, run those too

These tests would not guarantee that a set of changes would not break Debian, but they would give a high confidence that at least basic stuff would still work after the changes. Now, obviously implementing all of this I'm dreaming of (it is just past midnight, after all) is going to be impossible. There's way too much work to do, there's not enough tools for writing tests, and it would require too much computing power to run, and so on and so forth. But it's late, and I've had a bad day, and I might as well dream of something nice. Anyway, anyone interested in these things should perhaps help drive DEP8.

Since my laptop features WWAN connectivity, I purchased a 3G mobile broadband plan from SFR, a French mobile phone company. I took the cheapest one available: 250 MB per month for 10 .

Optimizing transparent proxy by SFR While browsing, I was curious about the fact that there were multiple accesses to non-public IP, like 10.141.0.4. I was browsing the mobile version of Le Monde, a French daily newspaper. I enabled Chromium developer tools and watched what happened in the Network tab. All images were served from IP like 10.141.0.4. Looking at the HTML source code, I discovered that <img> tags were rewritten to point to those images. The smaller one were identical to the original one but the larger ones (more than 50 KB) were of reduced quality (and therefore reduced size). <img> tags were not the only one to be rewritten. <style> and <script> tags that were pointing to external resources (with a src attribute) were also rewritten to include the CSS or the javascript inline. Before:

<script src="http://s1.lemde.fr/js/lib/jquery/1.5.1/jquery.js"></script>

After:

<script oldSrc="http://s1.lemde.fr/js/lib/jquery/1.5.1/jquery.js" NG="replaced">
/*!
 * jQuery JavaScript Library v1.5.1
 *
 * Copyright 2011, John Resig
 * Dual licensed under the MIT or GPL Version 2 licenses.
 * http://jquery.org/license
 * [...] */
</script>

This means that each page that includes jQuery, a popular javascript library, as an external resource, will be turned into a page that includes the whole jQuery code which is about 85 KB. Each page will weight more than 85 KB instead of relying on an external and cacheable resource. Nowadays, most browsers support HTTP keep-alive which allows to serve multiple resources into a single request. There are two cases:

1. If the resource is served from the same server as the HTML page, keep-alive would enable to get almost the same result without hindering the cache: the browser would first request the HTML page, then the javascript resource into the same TCP connection. There is a small penalty of about 100 ms to let the browser request the second resource. The browser may decide to open another connection because the initial document is not loaded yet. Some browsers may even negotiate this additional connection before needing it. In this case, it can use this idle connection at no cost. Otherwise, we may fall in the second case.
2. If the resource is served from another server (like in the example above) or if the browser does not have an idle connection ready for reuse, it would download the resource in parallel with the help of another connection. It will only costs about 300 ms of additional time due to the establishment of a new TCP connection with the server. Those 300 ms are a very small price to pay compared to the 2 seconds needed to download 85 KB for each page. Moreover, other static resources will likely be downloaded from the same server and therefore, this is 300 ms the first time and about 100 ms for additional resources (round-trip time for a new HTTP request into the same TCP connection).

UPDATED: In a previous version of this article, I confused pipelining and keep-alive mechanisms. While keep-alive allows to reuse an existing connection to download a new resource, only one request at a time by connection could be issued. Pipelining allows to push additional requests in the same TCP connection without waiting for answers. As noted by ric Daspet in a comment, pipelining is disabled for most browsers. However, keep-alive is well supported. Searching on the web for oldSrc and NG="replaced", I find very little information about what is used. It seems that such a feature may also break some scripts, like TinyMCE, trying to get additional resources relative to the path where the script is installed. It appears that SFR is using a product from Flash Networks called Harmony Gateway. I have asked SFR more info about this and if it was possible to disable the use of this feature but got no answer so far. I have retried a bit later and there was no rewriting for Javascript and CSS. Images were still degraded and served by a special server. The next day, my requests did not travel through a transparent proxy anymore (no more Via header in answers). Each try was done at a different location. The proxies may be installed at some locations only and configured differently. Another explanation is that SFR silently disabled this functionality for my account. If it was done correctly, such an accelerator service could be be proposed as an opt-out option since most users would appreciate faster page downloads. If you care about network neutrality, you can disable this option. Of course, it needs to be properly advertised, for example as a free option in your mobile plan.

Setting up our own optimizing proxy Google provides mod_pagespeed as a solution to optimize a website on the fly. This is an Apache module. It is targeted at optimizing your own website but since Apache can act as a regular proxy, it seems possible to enable mod_pagespeed for any website. That s pretty easy to setup if you don t mind using a precompiled version of mod_pagespeed. Download mod_pagespeed. I have downloaded the 64bit version for Debian.

# touch /etc/default/mod-pagespeed
# dpkg -i ~/download/mod-pagespeed-beta_current_amd64.deb
Selecting previously deselected package mod-pagespeed-beta.
(Reading database ... 277699 files and directories currently installed.)
Unpacking mod-pagespeed-beta (from .../mod-pagespeed-beta_current_amd64.deb) ...
dpkg: dependency problems prevent configuration of mod-pagespeed-beta:
 mod-pagespeed-beta depends on apache2.2-common; however:
  Package apache2.2-common is not installed.
dpkg: error processing mod-pagespeed-beta (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mod-pagespeed-beta
# apt-get install -f
[...]
Unpacking apache2.2-common (from .../apache2.2-common_2.2.19-1_amd64.deb) ...
Processing triggers for man-db ...
Setting up apache2.2-common (2.2.19-1) ...
[...]
# apt-get install apache2-mpm-worker
[...]
Unpacking apache2-mpm-worker (from .../apache2-mpm-worker_2.2.19-1_amd64.deb) ...
Setting up apache2-mpm-worker (2.2.19-1) ...
Starting web server: apache2.
# a2enmod proxy_http
Considering dependency proxy for proxy_http:
Enabling module proxy.
Enabling module proxy_http.
To to activate the new configuration, you need to run:
  /etc/init.d/apache2 restart

Then, we modify /etc/apache2/mods-enabled/proxy.conf:

ProxyRequests On
<Proxy *>
    AddDefaultCharset off
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Proxy>

Of course, this makes little sense to run the proxy on your laptop since you don t want to download the non-optimized content over your WWAN link. You need to run it on another server and therefore allow your laptop to access it. Also, we need to modify /etc/apache2/mods-enabled/pagespeed.conf to add the directive ModPagespeedDomain * to let mod_pagespeed rewrite any page. You should restart Apache after that. Now, check if the proxy is working:

$ curl -six http://localhost:80 http://www.lemonde.fr/   grep ^X-Mod-Pagespeed
X-Mod-Pagespeed: 0.9.17.7-716

All is working! Let s try a very simple site, like Debian Backports. It features one HTML file and two CSS files: We downloaded a total of 8 KB (compression included). Let s use our proxy and try again: mod_pagespeed succeeds in reducing the size of the HTML file and combined the CSS files. Moreover, it minified the resulting CSS file. There seems to be a bug in Chromium that display incorrect transfert sizes (including in the timeline representation) when using a proxy. I have checked with Wireshark that the overall quantity transferred was about 8 KB. The gain is very thin here but you can imagine that you will get better results on larger sites. mod_pagespeed seems to handle well most sites. However, it only optimizes pages that already are in its cache. The first time you grab a page, you will get the unoptimized version. I don t know if it is the expected behaviour.

During the past week I finally got around to give the Vendor Profiles branch some attention. I suspect the most exciting change is that I got support for non-overridable tags. Along with making --ftp-master-rejects an alias for the ftp-master profile. This means that you will get the same behavior from Lintian and from the ftp-master auto-reject mechanism. The only issue is that the overrides are silently ignored. We also made dropped the default profile symlink in favor of using dpkg-vendor to find the best profile. This causes a slight conflict with solving #626476. I have asked the dpkg maintainers if that part of the libdpkg-perl API is stable enough for us to use. Finally I fixed an issue where profiles would ignore all display settings (--display-info etc.) and just show all tags (except experimental tags). Beyond the vendor profile branch, there are also a number of interesting changes applied in the master branch. Together with some people from #debian-python (ScottK and jwilk as I recall), I prepared some python related goodies. Particularly we fixed a false-positive missing-python-build-dependency with python3 and marked dh_pycentral and dh_python as deprecated. On a related note, we have also removed the tag uses-dh-python-with-no-pycompat. Based on feedback from Eric Lavarde, we redefined the classpath-contains-relative-path tag. It now only emits the bad parts of the Classpath and relative entries are allowed in they exists or point to /usr/share/java/$file.jar and there is a strong libX-java dependency. While the change breaks overrides, according to lintian.d.o we do not have any yet. The next release will feature a check for non-empty dependency_libs fields in la files and a fix to a flaw in logic for architecture dependent overrides. We will be reducing our dependency of dpkg-dev to a Suggests (#626476). Currently the xz-utils is in the pseudo-essential set, but it may not stay that way. So in the future you may need to explicitly install xz-utils for Lintian to support .xz source packages. Last, but not least, if you have felt that the lintianrc file has been rather useless to you, then you are not alone. I have made a prototype patch to improve the situation and hopefully soon you get to specify default options in your lintianrc.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work, then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. I have been Doing some work towards Debian Rolling At the start of the month, the discussions about Debian rolling were still very active on debian-devel. Declaring that testing would be rolling did not make it (as I hoped), the argument that some RC bugs last for far too long in that distribution carried the discussion and thus the most consensual proposition ended up being the one of Josselin Mouette were rolling would be testing plus a few selected cherry-picked packages from unstable. I believe it s a workable solution if we only care about a subset of architectures. Otherwise the same reasons that keep the fixed packages out of testing would probably also apply for rolling. Given this, I did setup britney (the software that controls testing) on my laptop to investigate how we can create rolling. It turns out britney is a very specialized software with very few configuration knobs. At the same time Joachim Breitner made a proposition that immediately grabbed my attention. He suggests to use SAT solvers to find out the set of packages that should migrate from unstable to testing. I thought that rolling would be a good testbed for this new implementation of britney (which he calls SAT-britney) so I jumped right in this project. I was not at all familiar with this science field, so I looked up quite some documentation: I learned that all SAT solvers expect the problem to be presented in CNF form, and that DIMACS was the file format of choice to represent those boolean constraints. Several SAT solvers are available in Debian and picosat appears to be one of the best. Then I started some early coding/prototyping to play with the concept. You can find the result in this git repository, you can grab a copy with git clone git://git.debian.org/~hertzog/sat-britney.git. There s not much yet, except some Python code to generate a SAT problem that can be fed to a SAT solver. But I really look forward to this project. Representing Debian during Solutions Linux During the second week, I spent 3 days in Paris to help manage the Debian booth at Solutions Linux. We have responded to lots of queries but most visitors already knew Debian, and many of them use it at work and/or at home. We tried to recruit those people as new members for Debian France, the local association. We also sold all our remaining goodies. The Ubuntu people were interviewed by France 3 (an important TV channel) and we took this opportunity (with the consent of the Ubuntu guys) to show our Debian t-shirts in the background: you can watch the video here (in French), you can see me with Carl Chenet at 1:21. We have also been interviewed by Intelli n TV: here and here (both in French). I m not very good at this exercise. Improving dpkg triggers The third week was a vacation week, in theory I should have stayed away from my computer but I really wanted to take this opportunity to improve the state of dpkg triggers in Debian. I already covered my work in another article: Trying to make dpkg triggers more useful and less painful. The result is not merged yet, I just asked a question to all package maintainers who are using triggers to be able to decide whether I ll merge it as is, or if I can make the new behavior the default one. Supporting users after Alioth s migration When I came back from my vacation, many services provided by Alioth.debian.org were non-functional after a migration to a new setup that involves two machines instead of one. Given that I used to be an Alioth admin, I know that in those periods you tend to be get bogged down on many user support requests. So I re-joined #alioth on IRC and tried to help a bit. I did investigate some of the reported problems and prepared fixes (updated scripts, configuration files, etc.) for some of the issues. I also created a list of remaining issues that should have lasted only a few days but that s still active because there are still regressions left. The most important things still missing are:

• proper support for delegation of rights. We used ACL setup by the admins in the past. With the new FusionForge, each project admin should be able to delegate rights to external roles . There s a Debian Developer role already but trying to grant him right fails
• access to the Ultimate Debian Database. Many tools rely on this database to work.
• anonymous FTP access to download project files.
• clear guidelines on how we re supposed to deal with websites that are updated by VCS hooks.
• clear guidelines on how we re supposed to deal with personal git repositories

Improving the 3.0 (quilt) source format I have made some proposals to change the way the new source format would work. The goals are to be less painful for packagers who are using a VCS, and to avoid unexpected changes slipping through a new patch generated by dpkg-source. It seems that the proposals are relatively consensual so I ll implement them at some point. Missing in action on my blog I did a lots of stuff for Debian between travel and vacation, and in the remaining time, I did not manage to write many articles for my blog. In fact, besides the article on my triggers work mentioned above I only published one interview: People behind Debian: Steve Langasek, release wizard. I ll try to do better this month! Thanks Many thanks to the people who gave me 151.61 in May. See you next month for a new summary of my activities.

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

So I just read that Google will only support modern browsers starting 2 months from now.

As of August 1st, we will discontinue support for the following browsers and their predecessors: Firefox 3.5, Internet Explorer 7, and Safari 3. In these older browsers you may have trouble using certain features in Gmail, Google Calendar, Google Talk, Google Docs and Google Sites, and eventually these apps may stop working entirely.

Given the importance of Google, the impact is huge. This company has acquired the power to basically dictate what browser you can provide to your users - otherwise they won t be able to access what many of them now consider vital functionality. Such a decision denotes a grave misunderstanding of the workstation ecosystem from the Google people. It means they consider their only target to be nerdy users with home computers they can (and want to) upgrade and break every 3 months with the latest version of Windows or Fedora. What about corporate computers? What about non-techy people who buy a computer and stick with the OS that was sold with it for 4 years? I m afraid they are still the vast majority of web users. You can t decide to deploy a new version of IE of Firefox on a large number of computers for next month. Sometimes, this is not even possible (hello Windows 2000/XP users). For Debian squeeze, this means no more Firefox for you. Epiphany and Konqueror might still work, but Google loves sending JavaScript that make old versions of Webkit struggle. And anyway, this is just the beginning. In a few months they will tell us to upgrade again to Firefox 4.2 and IE 12. One week after their release, yeah! Let s quote a comment which should help understanding the reasoning behind such decisions.

Andy, while I understand staying on LTS, I think it's a little bit silly to use a mission critical machine for web browsing in that way. Also, there is no reason your browser has to be tied in lockstep to your OS. Two simple solutions:
1. Don't use the built-in browser for your main web browsing. Install Chrome, for example. or,
2. Since LTS is designed for servers and other "can't have any chance of downtime" machines, quit using that machine as your web browsing box and use a personal laptop for such things, which you can keep up to date with the current OS release instead of waiting 2 years.

Belief #1: the browser can (and should) be independent from the OS . It s interesting to note that the same people who say this are the ones who also jerk off at the idea of desktops and phones with tight web integration. This integration comes at a cost: this restricts your ability to change everything in the browser from one day to another. Belief #2: long-term OSes are for mission-critical servers only . Yeah sure, that s why Windows has a lifecycle of 3 years. Desktops are no different at all from servers on this matter. You don t upgrade your desktop every 6 months when you do serious work with it; the cost and the risk are just too high. And anyway, this comes again from the same people who want to upgrade every single component of said mission-critical servers every 2 months to install the latest version of their preferred web framework. Belief #3: people can upgrade their browsers or OSes . No really they can t. Many people wouldn t know how to do this, even with a step-by-step documentation. And in enterprise deployments, they are restricted from doing so. Thanks for spreading the clich that web developers are clueless, spotty nerds, incapable of understanding the needs of production environments. Apparently Google is not exempt from this disease.

Network effects are such a pernicious thing. They give us the internet, but they also give us an internet full of monopolistic worse-is-better players that use network effects to stifle improvements and competition. Sometimes the best you can manage is to be a parasite. facebook So I'm back on facebook ... sort of. My strategy for facebook is to be as near to a featureless datapoint as I can. I won't post anything. I entered as bad quality information as I could get away with. I turned all privacy controls off, on the theory that this way I don't have to worry about facebook eroding privacy since everything about me on facebook is aggressively public. By never posting anything to facebook, I am trying to fight the network effect; trying to avoid increasing the value of facebook due to me being on it. I've adblocked the text entry field on facebook just to avoid the temptation. I want to erase the Like buttons too. Technologically, I think a good approach would be a browser plugin that does these things while extracting all available content and optionally sending it to a RECAP-type system. I only friend people who I need to keep up with and who have little or no other internet presence. This is because I am aware that each person I friend still propels facebook's network effect a little bit; even though they'll never see any useful information from me, they will know that they are able to talk to me via facebook. I only log into facebook once a week or so (this is easy when you're not interacting with it anyway), and read whatever sample of farmville and other posts facebook selects as "important" (worse than usual probably since I never give it feedback). So people I friend can't rely on me reading everything they do, which reduces the value a little more. I will probably delete this account occasionally, and then re-add it later. Just often enough to be really annoying. twitter Similarly, I no longer gate my identi.ca account to twitter, and have deleted as many tweets as I could stand to (one click and one keypress per tweet; no mass-delete; ugh!), and protected my account to avoid accidential new tweets leaking out. Since twitter is not quite as evil as facebook I feel slightly less bad about exposing more of my social graph there. Only the folks who are too lame to get on an OpenMicroBlogging site like identi.ca. phone Of course there was a network effect with the telephone as well, and while it got deregulated it's still pretty bad, and also a technology that I mostly dislike using. Oddly my phone behavior is backwards to the other two networks; I only make outgoing phone calls, never answering the phone (unless real life intervenes very severely). I listen to some random fraction of my voice mail and read whatever ones manage to get machine-transcribed.

When I installed my new laptop, I decided to switch from sleepd to GNOME Power Manager (GPM). The rationale behind this decision was to get screen dimming for free while keeping other features because GPM uses UPower which uses pm-suspend and pm-powersave behind the scene. This means that it is easy to execute scripts on suspend or when the AC is unplugged by putting them in /etc/pm. I don t use a full GNOME desktop. My desktop is running FVWM which is just a window manager. However, I already use some parts of the GNOME environment:

• GDM as a display manager because it is the only one that is able to handle ConsoleKit correctly. This means that GDM is able to register your session to ConsoleKit and make it active. Without that, you won t be considered as the user sitting in front of the screen and DBus won t allow you to interact with most of your hardware unless you add yourself to a lot of groups. ConsoleKit enables the at_console property used by most policies.
• Network Manager to handle both wired and wireless connections. Connecting to some random AP using only command line tools is rather cumbersome (assume that the AP is using WPA). Connecting to a broadband network with a 3G dongle is even more cumbersome.
• GNOME bluetooth applet because interacting with BlueZ bluetooth stack is now done with DBus only and the command line tools have been removed. Therefore, you need to write your own tools or use this small applet that do most of the work for you.

What s working It happens that most of the features just do not work. However, suspend when closing the lid works fine. The icon in the systray works fine too (but there is a small bug). The screen dimming feature on idle also works (but there are annoying bugs with it). The visual feedback when pressing brightness keys works too.

What s not working It seems that I am not the only one to have problem with GPM: there are currently 115 bugs opened in the Debian BTS. If you want to get some debug output from gnome-power-manager, run it with --verbose flag. --debug flag does nothing (and supersedes --verbose).

Nothing happens when pressing the power button I have configured GPM to ask me what to do when I press the power button. But when I press the button, nothing happens. Looking at the source, here is the snippet of code that is executed:

1 2 3 4 5 6 7

if (policy == GPM_ACTION_POLICY_INTERACTIVE) GpmSession *session; egg_debug ("logout, reason: %s", reason); session = gpm_session_new (); gpm_session_logout (session); g_object_unref (session);

In fact, this is not GPM that will ask you the question, but GNOME session manager because GPM triggers logout. If you don t run a full GNOME session, nothing will happen. My workaround is just to set the action to Suspend .

Does not sleep when idle GPM is configured to go to sleep after 2 hours on AC or 30 minutes on battery. This does not work for me because idle detection is delegated to external programs. There are four variables used by GPM to determine if we are idle:

• session_idle which is the idle hint from ConsoleKit,
• idle_inhibited which is set when another program asks to disable idle detection (a video player which does not want the screen to be dimmed),
• suspend_inhibited which means a program do not want we going to sleep (a music player for example)
• x_idle which tells if X is idle or not (someone is moving the mouse or typing on the keyboard).

To allow GPM to suspend when we are idle, x_idle and session_idle must be true while suspend_inhibited and idle_inhibited must be false. For screen dimming purpose, you just need to have x_idle set to true and idle_inhibited set to false. Currently, only GNOME Screensaver seems to tell ConsoleKit if the session is idle or not. XScreenSaver does not contain anything about this. I am using xautolock with xlock and I am pretty sure they won t tell GPM if I am idle. You can use dbus-send to circumvent this problem:

1 2 3 4 5 6 7 8 9 10 11

$ dbus-send --system --dest=org.freedesktop.ConsoleKit \ > --type=method_call --print-reply --reply-timeout=2000 \ > /org/freedesktop/ConsoleKit/Manager \ > org.freedesktop.ConsoleKit.Manager.GetCurrentSession method return sender=:1.6 -> dest=:1.106 reply_serial=2 object path "/org/freedesktop/ConsoleKit/Session1" $ dbus-send --system --dest=org.freedesktop.ConsoleKit \ > --type=method_call --print-reply --reply-timeout=2000 \ > /org/freedesktop/ConsoleKit/Session1 \ > org.freedesktop.ConsoleKit.Session.SetIdleHint boolean:true method return sender=:1.6 -> dest=:1.108 reply_serial=2

While I understand what is the rationale behind those choices (no code duplicate and allowing external programs to hinder power management), it lacks some fallback in case you don t use GNOME Screensaver (which is the key component here). I first though this was bug #594706 but this is not the case. I have opened (and closed) bug #628755. UPDATED: Jump to the conclusion for an updated solution for this problem.

Brightness is not restored to the previous value after idle When GPM undims the screen, it does not restore the previous value. It seems to be bug #617310 which is marked as fixed in upstream. I did not investigate it.

Wrong number of batteries reported I only have one battery but after one suspend/resume cycle, GPM thinks I have two. Maybe this is a bug of UPower. Maybe this is bug #606434. I did not investigate it. Maybe there is an happy interaction with bug #456280.

Inability to set configure actions when the UPS runs out of battery This is bug #390602. In addition to laptop batteries, UPower also supports UPS. In this case, GPM displays a special icon to tell if the UPS is fully charged. However, there is no possibility to execute special actions when the UPS is unplugged, like hibernate after 10 minutes or something like this. This seems to be a problem with the interface because looking with gconftool-2, we can spot variables like low_ups or critical_ups which allow to set actions when the UPS is almost out of battery. Moreover, the UPS icon only displays after one suspend/resume cycle but I am too lazy to report and debug this issue. Since, the icon disappear if I restart GPM, I am confident that the bug is in GPM.

Conclusion The conclusion is that GPM is not really that buggy but it really needs to be run in a full-blown GNOME desktop. The main problem is not really GPM. New technologies like UPower and ConsoleKit get pushed by freedesktop.org initiative, they get implemented by GNOME (and, I suppose, KDE) because they have tons of people following the appropriate mailing lists and any alternative just gets crushed by all those unpublicized changes. UPDATED: I got several helpful comments about this problem. There are two possible solutions:

1. Use xfce4-power-manager. It handles brightness control in a better way and don t need an external program to tell when the current session is idle. It still needs a session manager to ask what to do when using the power button. The drawback to this solution is that you start to pull another desktop environment into your environment. You had some parts of GNOME and now you have some parts of XFCE. This solution was proposed by Sylvain Collilieux.
2. Use gnome-session, gnome-screensaver and keep gnome-power-manager. As pointed by Julien Valroff, gnome-screensaver needs gnome-session to detect idleness. However, gnome-session starts a whole GNOME desktop. Again, there are two solutions. The first one is to replace gnome-session by something lighter implementing the bare minimum to make gnome-screensaver happy. Another suggestion is to configure gnome-session to start your favorite environment.

I start mine from ~/.xsession and here is what I have added at the top of it:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# If not done, restart ourself with gnome-session if [ -z "$SESSION_MANAGER" ]; then [ -d ~/.config/autostart ] mkdir ~/.config/autostart rm -f ~/.config/autostart/* cat <<EOF > ~/.config/autostart/xsession.desktop [Desktop Entry] Name=Xsession Comment=Start .xsession Exec=$(readlink -f $0) Type=Application X-GNOME-Autostart-enabled=true EOF exec gnome-session --autostart=$HOME/.config/autostart fi # Otherwise, keep starting stuff # [...] exec fvwm-crystal

You'd think it'd be easy to reboot a PC, wouldn't you? But then you'd also think that it'd be straightforward to convince people that at least making some effort to be nice to each other would be a mutually beneficial proposal, and look how well that's worked for us.

Linux has a bunch of different ways to reset an x86. Some of them are 32-bit only and so I'm just going to ignore them because honestly just what are you doing with your life. Also, they're horrible. So, that leaves us with five of them.

• kbd - reboot via the keyboard controller. The original IBM PC had the CPU reset line tied to the keyboard controller. Writing the appropriate magic value pulses the line and the machine resets. This is all very straightforward, except for the fact that modern machines don't have keyboard controllers (they're actually part of the embedded controller) and even more modern machines don't even pretend to have a keyboard controller. Now, embedded controllers run software. And, as we all know, software is dreadful. But, worse, the software on the embedded controller has been written by BIOS authors. So clearly any pretence that this ever works is some kind of elaborate fiction. Some machines are very picky about hardware being in the exact state that Windows would program. Some machines work 9 times out of 10 and then lock up due to some odd timing issue. And others simply don't work at all. Hurrah!
  
• triple - attempt to generate a triple fault. This is done by loading an empty interrupt descriptor table and then calling int(3). The interrupt fails (there's no IDT), the fault handler fails (there's no IDT) and the CPU enters a condition which should, in theory, then trigger a reset. Except there doesn't seem to be a requirement that this happen and it just doesn't work on a bunch of machines.
  
• pci - not actually pci. Traditional PCI config space access is achieved by writing a 32 bit value to io port 0xcf8 to identify the bus, device, function and config register. Port 0xcfc then contains the register in question. But if you write the appropriate pair of magic values to 0xcf9, the machine will reboot. Spectacular! And not standardised in any way (certainly not part of the PCI spec), so different chipsets may have different requirements. Booo.
  
• efi - EFI runtime services provide an entry point to reboot the machine. It usually even works! As long as EFI runtime services are working at all, which may be a stretch.
  
• acpi - Recent versions of the ACPI spec let you provide an address (typically memory or system IO space) and a value to write there. The idea is that writing the value to the address resets the system. It turns out that doing so often fails. It's also impossible to represent the PCI reboot method via ACPI, because the PCI reboot method requires a pair of values and ACPI only gives you one.

Now, I'll admit that this all sounds pretty depressing. But people clearly sell computers with the expectation that they'll reboot correctly, so what's going on here?

A while back I did some tests with Windows running on top of qemu. This is a great way to evaluate OS behaviour, because you've got complete control of what's handed to the OS and what the OS tries to do to the hardware. And what I discovered was a little surprising. In the absence of an ACPI reboot vector, Windows will hit the keyboard controller, wait a while, hit it again and then give up. If an ACPI reboot vector is present, windows will poke it, try the keyboard controller, poke the ACPI vector again and try the keyboard controller one more time.

This turns out to be important. The first thing it means is that it generates two writes to the ACPI reboot vector. The second is that it leaves a gap between them while it's fiddling with the keyboard controller. And, shockingly, it turns out that on most systems the ACPI reboot vector points at 0xcf9 in system IO space. Even though most implementations nominally require two different values be written, it seems that this isn't a strict requirement and the ACPI method works.

3.0 will ship with this behaviour by default. It makes various machines work (some Apples, for instance), improves things on some others (some Thinkpads seem to sit around for extended periods of time otherwise) and hopefully avoids the need to add any more machine-specific quirks to the reboot code. There's still some divergence between us and Windows (mostly in how often we write to the keyboard controller), which can be cleaned up if it turns out to make a difference anywhere.

Now. Back to EFI bugs.

I m proud to be able to announce a new stable release of Grml, the Debian based Live system for system administrators. This release is a very special one for me. On the one hand of course because of the special release name Just Mari , being dedicated to my lovely wife. But it s also special because of the way the release management worked out. I ve been the release manager for Grml since the very beginning, which turned out to be more than 6 years since the first stable release already. I developed grml-live as build framework based on FAI for generating a Grml and Debian based Linux Live system to streamline the build process. Anyway it was mainly me who managed the release chroots, doing the update management during release freeze, editing main web page etc. As I want to make the project as independent from myself as much as possible and to keep the Bus factor in balance we started to improve our project infrastructure so it s not just me who can do this kind of release management. As a result Grml core developer Christian Hofstaedtler became the release sergeant of this release. The release candidate version was even released without myself being available (the release happened behind my back during our marriage). Major work on the final stable release was also done by Grml core developers Ulrich Dangel, Christian Hofstaedtler, Frank Terbeck and Alexander Wirt and I m very happy about that. Kudos guys for all your work and all the hidden efforts going on behind my back. The details regarding the new Grml release are available in the official release announcement, get the ISOs from grml.org/download. I hope you enjoy the release as much as I do. Happy hacking!

The Mahara project has just moved to mandatory code reviews for every commit that gets applied to core code.

Here is a description of how Gerrit Code Review, the peer-review system used by Android, was retrofitted into our existing git repository on Gitorious.

(If you want to know more about Gerrit, listen to this FLOSS Weekly interview.)

Replacing existing Gitorious committers with a robotThe first thing to do was to log into Gitorious and remove commit rights from everyone in the main repository. Then I created a new maharabot account with a password-less SSH key (stored under /home/gerrit/.ssh/) and made that new account the sole committer.

This is to ensure that nobody pushes to the repository by mistake since all of these changes would be overwritten by Gerrit.

Basic Gerrit installationAfter going through the installation instructions, I logged into the Gerrit admin interface and created a new "mahara" project.

I picked the "merge if necessary" submit action because "cherry-pick" would disable dependency tracking which is quite a handy feature.

Reverse proxy using NginxSince we wanted to offer Gerrit over HTTPS, I decided to run it behind an Nginx proxy. This is the Nginx configuration I ended up with:

server  
     listen 443;
     server_name reviews.mahara.org;
     add_header Strict-Transport-Security max-age=15768000;

     ssl on;
     ssl_certificate  /etc/ssl/certs/reviews.mahara.org.crt;
     ssl_certificate_key  /etc/ssl/certs/reviews.mahara.org.pem;

     ssl_session_timeout  5m;
     ssl_session_cache shared:SSL:1m;

     ssl_protocols  TLSv1;
     ssl_ciphers  HIGH:!ADH;
     ssl_prefer_server_ciphers   on;

     location /  
             proxy_pass   http://127.0.0.1:8081;
             proxy_set_header X-Forwarded-For $remote_addr;
             proxy_set_header Host $host;
      
 

Things to note:

• An HTTP to HTTPS redirection is not provided.


• The HSTS headers indicates to modern browsers that this URL should only be accessed via HTTPS.


• Only strong SSL ciphers are enabled.


• Before proxying requests to Gerrit, Nginx adds a few headers to identify the origin of the request. The Host header in particular must be present otherwise built-in Gerrit redirections will fail.

Mail setupTo enable Gerrit to email reviewers and committers, I installed Postfix and used "reviews.mahara.org" as the "System mail name".

Then I added the following to /home/gerrit/mahara_reviews/etc/gerrit.config:

[user]
 email = "gerrit@reviews.mahara.org"

to fix the From address in outgoing emails.

Init script and cronFollowing the installation instructions, I created these symlinks:

ln -s /home/gerrit/mahara_reviews/bin/gerrit.sh /etc/init.d/gerrit
cd /etc/rc2.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc3.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc4.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc5.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc0.d && ln -s ../init.d/gerrit K21gerrit
cd /etc/rc1.d && ln -s ../init.d/gerrit K21gerrit
cd /etc/rc6.d && ln -s ../init.d/gerrit K21gerrit

and put the following settings into /etc/default/gerritcodereview:

GERRIT_SITE=/home/gerrit/mahara_reviews
GERRIT_USER=gerrit
GERRIT_WAR=/home/gerrit/gerrit.war

to automatically start and stop Gerrit.

I also added a cron job in /etc/cron.d/gitcleanup to ensure that the built-in git repository doesn't get bloated:

MAILTO=admin@example.com
20 4 * * * gerrit GIT_DIR=/home/gerrit/mahara_reviews/git/mahara.git git gc --quiet

Configuration enhancementsTo allow images in change requests to be displayed inside the browser, I marked them as safe in /home/gerrit/mahara_reviews/etc/gerrit.config:

[mimetype "image/*"]
 safe = true

Another thing I did to enhance the review experience was to enable the gitweb repository browser:

apt-get install gitweb

and to make checkouts faster by enabling anonymous Git access:

[gerrit]
  canonicalGitUrl = git://reviews.mahara.org/git/
[download]
  scheme = ssh
  scheme = anon_http
  scheme = anon_git

which requires that you have a git daemon running and listening on port 9418:

apt-get install git-daemon-run
ln -s /home/gerrit/mahara_reviews/git/mahara.git /var/cache/git/
touch /home/gerrit/mahara_reviews/git/mahara.git/git-daemon-export-ok

Finally, I included the Mahara branding in the header and footer of each page by providing valid XHTML fragments in /home/gerrit/mahara_reviews/etc/GerritSiteHeader.html and GerritSiteFooter.html.

Initial import and replicationOnce Gerrit was fully working, I performed the initial code import by using my administrator account to push the exiting Gitorious branches to the internal git repository:

git remote add gerrit ssh://username@reviews.mahara.org:29418/mahara
git push gerrit 1.2_STABLE
git push gerrit 1.3_STABLE
git push gerrit master

Note that I had to temporarily disable "Require Change IDs" in the project settings in order to import the old commits which didn't have these.

To replicate the internal Gerrit repository back to Gitorious, I created a new /home/gerrit/mahara_reviews/etc/replication.config file:

[remote "gitorious"]
 url = gitorious.org:mahara/$ name .git
 push = +refs/heads/*:refs/heads/*
 push = +refs/tags/*:refs/tags/*

(The $ name variable is required even when you have a single project.)

Contributor instructionsThis is how developers can get a working checkout of our code now:

git clone git://gitorious.org/mahara/mahara.git
cd mahara
git remote add gerrit ssh://username@reviews.mahara.org:29418/mahara
git fetch gerrit
scp -p -P 29418 reviews.mahara.org:hooks/commit-msg .git/hooks/

and this is how they can submit local changes to Gerrit:

git push gerrit HEAD:refs/for/master

Anybody can submit change requests or comment on them but make sure you do not have the Cookie Pie Firefox extension installed or you will be unable to log into Gerrit.

Identity checks and trust The OpenPGP web of trust is composed of keys linked to each other by two things:

• identity checks: signing a key means that you verified the link between a key with user IDs, an official identity document with a photograph, and a person with a face;
• trust: on your public key ring, you manually decide who you trust to correctly check other people's identity.

With these two pieces of information, GnuPG is able to determine whether or not the key of someone you never met can trusted to belong to its alleged owner. Signatures Signing a key is usually a binary action: either you sign it or you do not sign it. Thus your signature on a key will give other people a rough identity check information and no trust information at all. In fact, the OpenPGP standard does allow to publish precise identity check and trust information on signatures, but unfortunately this is now enabled with GnuPG by default. These features are called certification level and trust signatures.Certification level To indicate how careful you verified someone's identity, run GnuPG with the option --ask-cert-level, or add ask-cert-level to your configuration file .gnupg/gpg.conf. When you make a signature with this option, GnuPG will ask you how carefully you verified the key owner's identity. According to the manpage gpg(1), the available levels are:

• 0: no indication;
• 1: personal belief but no verification, useful for signing pseudonymous IDs;
• 2: casual verification;
• 3: extensive verification.

Trust level You can also indicate how much you trust someone, sign his key with the command tsign instead of sign. GnuPG will then ask you three questions:

1. how far you trust him to verify other people's keys: marginally or fully (I personally only fully trust people that were trained or challenged by myself or by people I trust even more)
2. how far you allow him to make trust signatures on your behalf: usually answer 1; answering 3 would allow him to issue trust signature with level 2, thus allowing other people to issue trust signatures on your behalf (this features exists to implement pyramidal certification systems, but can be interesting for signing your own keys when you have several);
3. if you wish to restrict this signature to a domain: I have no idea of what this means so I give none.

Conclusion Although certification level and trust signatures are not very widely used, thanks to GnuPG's default settings, it allows to publish more information about your signatures, adding value to the web of trust at no cost, which I believe is a good think. Thus I think it is worth doing it. If you want to use these features with the caff wrapper, remember that it has its own GnuPG configuration .caff/gnupghome/gpg.conf. In addition it does not implement trust signatures natively: to use them, you have to abort the automatic signing, which gives you a GnuPG prompt, where you are then able to tsign, then exit to return to caff that will consider your trust signatures. Credits

• Wikimedia Commons for Saint Peter's key photograph, GFDL 1.2 licensed.

What do Assholes do? Rusty just wrote a post titled If you didn t run code written by assholes, your machine wouldn t boot [1] about some of the anti-social tendencies demonstrated by programmers, including some that are implied to be fairly important. His post seems to imply that there are really great programmers who are anti-social and that we should just put up with it because of their great code. One of the problems with his post is that he doesn t define asshole . Holocaust deniers and all other Nazi supporters seem to clearly by assholes by any definition. People who have silly ideas about medicine and tell others seem to be merely misguided (although my dictionary gives stupid or irritating or ridiculous in the definition of asshole so technically they can meet the criteria). In the comments Rusty states that nuttiness is relative . While that is correct it doesn t seem to have much bearing on whether someone is an asshole. For example I know some very nice people who are utterly convinced by creationism. Is Anyone Essential to Free Software? Most projects have one person or several people in leadership positions, usually there seems to be a combination of project management and lead-programmer positions. Such people are obviously quite important to a project. But we have seen examples of people dying, being employed by Microsoft, retiring, relicensing the source in a bad way, and just losing interest without the project ceasing. It seems clear that in most cases when a project which has a significant amount of use has significant bugs and no maintainer then someone will step in. The cases where no-one takes over the project are often resolved by someone creating a competing project. If no-one takes over an abandoned Free Software project then it s a strong indication that the project wasn t particularly important anyway. I have no doubt that if any bug or missing feature made Linux systems stop booting then someone would fix it quite quickly. In a more general sense it seems that every time someone takes a position in a project that is of wide interest they are displacing someone else who might have done the job. When you volunteer to do significant work for a project you may be displacing someone who is more skillful than you this isn t necessarily a bad thing as there are plenty of other projects to work on, some of which require more skill. Growing More Programmers It seems to me that a large part of becoming a great programmer is facing great challenges. People who could be described as optimistic or arrogant will tend to take on more challenging tasks and therefore learn more. I m sure that there are a lot of people out there who have the potential to be great programmers apart from not taking on the challenging work, this seems to be an unfortunate waste of talent. Given a large enough population if someone leaves a senior position there should be someone else who can obtain the skills needed to take over. One advantage of this for Free Software development is that even if the best person to take on the challenge isn t living in the most convenient continent that won t be an obstacle, while with proprietary software development projects the teams are small and it s common that no-one else is capable of stepping up to a lead position. Another advantage is that when the lead developer leaves there are generally many candidates to replace them, all of whom can start work and be judged on the work that they do. I think that the best claims that can be made regarding essential people are not in regard to technical skill alone but to a combination of technical and people skills. Getting a group of programmers to work together is really hard but it s something that needs to be done for any significant project. Also the larger projects tend not to stand alone, being able to get changes included in other projects requires some skill. Ben Collins-Sussman and Brian Fitzpatrick gave an insightful talk at Google IO 2008 titled How to Protect Your Open Source Project From Poisonous People [2]. The first half of their talk is mostly about people who are misguided or difficult rather than what most people would consider poisonous and the second half is more about people who are actively poisonous and need to be removed. They advocate a community based on Politeness, Respect, Trust, and Humility. They describe in detail how the methods they advocate result in the members of their community being more productive, it seems obvious that those principles will lead to better career growth for people within the community and more friendly people wanting to join. When is being an Asshole OK? I once worked for a company that apparently had a team consisting solely of assholes. Apparently one asshole got promoted to management and after some internal transfers they ended up with all the assholes in the company on one team. I guess that when someone has negative interactions with everyone they won t notice the difference if they are put in a team where everyone is difficult. For a corporate environment that lacks a no jerks hiring policy this is probably a good way of improving productivity overall. I am not aware of any significant Free Software project that was comprised of mostly jerks although I have seen a few with dysfunctional environments that encourage the worst behavior from their members. The smaller Free Software projects have less need for people who can relate to other people. There are many useful Free Software projects which have only one developer, in most cases anyone can take the source code and use it without dealing with the author. But even for a single-developer project an asshole can cause some serious problems. One example I know of concerns a developer who had unclear licenses and started making legal threats in response to a request for a clear license. Another example is of a developer who released code that was designed to not work when one particular user compiled it and redistributed the binaries. Both of them caused some significant amounts of time to be wasted by people who were unfortunate enough to develop systems that interacted with the code in question, and even more time was wasted when some misguided people defended them in the inevitable flame-wars. Even for a project with only one developer it s still better for everyone if that developer isn t an asshole. One comment I ve seen related to this issue suggesting that some types of asshole behavior shouldn t be a problem an example that was cited is a colleague who cheats on a romantic partner. Jeremy Clyman (who is currently doing a Ph.D in Psychology) has written an interesting article about this for Psychology Today [3]. He reviews the movie The Dilemma which deals with someone catching their colleague s wife cheating. Jeremy analyses the psychological issues involved and how they can (among other things) impact the ability for such people to work. I once worked in an office where two married employees were very open about having an affair and we were all apparently expected to lie on their behalf if necessary, it really affected the quality of the working environment. Extreme Assholes There are lots of people involved in Free Software development who are difficult and many who are to some extent assholes. But some of them take being an asshole to the extreme, such as Holocaust deniers (an example which Rusty used). In the comments on his post the Westboro Baptist Church is also mentioned. It is possible to entirely disagree with someone on a contentious issue such as abortion but still be able to get along with them. But when someone supports a hate-based organisation such as the WBC or supports Nazis in any way then there will be many people who just can t tolerate them and no-one should be expected to tolerate such people. I have seen two instances where Free Software developers advocated pro-Nazi positions (one had an archive of neo-Nazi propaganda and the other claimed that Nazis were not responsible for the Holocaust). Neither of the pro-Nazi programmers was evicted for defending Nazis, but both of them ended up leaving the community in adverse ways after causing other damage in the mean time. I don t think it takes any great ability to predict the future to determine that someone who defends Nazis will eventually end up doing something that requires expulsion and drive away users and developers in the mean-time. There is no possibility that someone can support the Nazi or WBC ideology only when not associated with your project, it will affect all aspects of their life. When a Holocaust denier is allowed to be a member of a community it also sends out a message that members of the groups which were persecuted by Nazis aren t particularly welcome in the community. Helping Minor Assholes There are a lot of people who don t have malevolent aims but who unintentionally cause some difficulty (it seems that the truly malicious are a tiny minority). I don t think that excusing the bad things that they do on the basis of writing good code helps them in the long term. Many of the suggestions that Ben Collins-Sussman and Brian Fitzpatrick make seem likely to help people who don t want to be assholes and direct them towards positive involvement in the community. One trend that seems apparent is the non-linear response to certain types of bad behavior. There is often little difference in severity between something that gets almost no attention and something that results in a large and extremely hostile reaction. If someone persists in acting like an asshole for long enough it seems to be inevitable that they will eventually exceed some threshold for what is tolerated and get a very significant negative response. It would be good if things didn t need to get to that stage. I think that the most unfortunate aspect of Rusty s blog post is that most people will probably interpret it as encouragement to write better code as a way of getting a free pass for being an asshole. I know that this isn t what Rusty intended, but most people on the Internet don t know Rusty as well as I do. Conclusion Ben Collins-Sussman and Brian Fitzpatrick seem to have some of the best ideas for how to deal with these issues when you control a project, but most of us aren t in that position. Everyone can advocate better behavior. Extreme assholes need to be removed quickly and without a great debate about their contributions, freedom of speech, or other issues. Since considering this issue I ve been wondering about when one should avoid the lesser assholes and asshole-positive environments. People tend to adapt to their environment, so if you associate with assholes a lot then there s a good chance you will start to become like them. Is

• [1] http://rusty.ozlabs.org/?p=196
• [2] http://www.youtube.com/watch?v=-F-3E8pyjFo
• [3] http://www.psychologytoday.com/blog/reel-therapy/201105/what-causes-the-dilemma

Or how to get rid of Evolution without removing your whole system There is a complain I have heard several times from people after they installed Debian: I use Icedove/Thunderbird so I do not need Evolution: I tried to remove it but this would remove my whole system, that sucks! Explanation The reason behind this situation is that GNOME is installed by a meta-package, which is a dummy package that depends on each component of the official GNOME desktop, including Evolution. So it got installed as a dependency of that dummy package. This means that you, or rather, the Debian installer, never asked explicitly to install either Evolution or any other specific software: it came automatically. Now, you want to remove Evolution: very well, but this implies removing the meta-package, as you are removing one of its dependencies. But if you are removing this meta-package, there is no reason to keep all this software you did not asked for, so, as they got installed automatically, they are now removed automatically as well The solution So, do you still want to remove Evolution but keep the remaining of your GNOME desktop? Of course you will not keep GNOME , because GNOME includes Evolution, so strictly speaking GNOME without Evolution is not GNOME any more. Well, there is a solution: marking all the dependencies of the meta-package as manually installed, that is, faking that you installed them explicitly Aptitude is able to do that with its powerful search functions:

# aptitude unmarkauto '?reverse-depends(gnome)   ?reverse-recommends(gnome)'
# aptitude unmarkauto '?reverse-depends(gnome-core)   ?reverse-recommends(gnome-core)'
# aptitude unmarkauto '?reverse-depends(gnome-desktop-environment)'\
'   ?reverse-recommends(gnome-desktop-environment)'

What did we do? Well, exactly what is written: unmarking as automatically installed the packages that reverse-depend or reverse-recommend gnome or gnome-desktop-environment. In other words, those that are dependencies or recommendations of gnome, gnome-core or gnome-desktop-environment. Why these three packages? Because the GNOME environment that Debian provides by default is composed of several meta-packages: I shall let you refer to their respective descriptions for further information. Now, you can safely remove Evolution without pulling out your whole desktop system:

# aptitude remove evolution

long time no post about my RC bug fixing activities. & indeed, I haven't been very active during the last weeks. here's a quick update; it includes two NMUs done for the perl 5.12 transition, the rest is just "normal" maintainance work (interesting to see how much stuff can break behind our backs ...).

• #578940 libhttp-proxy-perl: "libhttp-proxy-perl: FTBFS with perl 5.12.0-1: POD coverage"
  add patch as a workaround (pkg-perl)
• #603251 libsys-syslog-perl: "libsys-syslog-perl: obsoleted by perl in squeeze"
  upload new upstream release (pkg-perl)
• #612780 libnet-ssleay-perl: "libnet-ssleay-perl: FTBFS against openssl 1.0.0c-2 from experimental"
  upload package with patch by chrisb (pkg-perl)
• #615571 libclone-fast-perl: "libclone-fast-perl: FTBFS with perl 5.12.3: test failures"
  upload with patch from niko tyni (pkg-perl)
• #616566 libconfig-model-itself-perl: "libconfig-model-itself-perl: Failing test t/itself.t"
  upload package prepared by dod (pkg-perl)
• #621019 libwww-perl: "typo in depends makes package uninstallable"
  fix typo in dependency (pkg-perl)
• #621135 libwww-perl: "libwww-perl: Breaks partial upgrades from squeeze"
  upload package prepared by periapt (pkg-perl)
• #621468 libmodule-cpants-analyse-perl: "libmodule-cpants-analyse-perl: FTBFS: Can't locate Test/YAML/Meta/Version.pm in @INC"
  grab patch from upstream bugtracker (pkg-perl)
• #621469 src:libmojomojo-perl: "libmojomojo-perl: FTBFS - failing tests"
  upload new upstream release with fixed dependency (pkg-perl)
• #622919 libjifty-dbi-perl: "libjifty-dbi-perl: security SQL injection"
  upload new upstream release (pkg-perl)
• #623510 libjgoodies-looks-java-doc,libjgoodies-common-java: "libjgoodies-common-java and libjgoodies-looks-java-doc: error when trying to install together"
  fix Document files in .doc-base file
• #624767 src:libbuffy-bindings: "libbuffy-bindings: FTBFS"
  update build dependencies, upload to DELAYED/2
• #624811 src:mapserver: "mapserver: FTBFS: ld: cannot find -lepsilon"
  add missing build dependency, upload to DELAYED/2
• #625840 libnet-freedb-perl: "libnet-freedb-perl: FTBFS - test suite needs internet access"
  disable tests that need internet access (pkg-perl)
• #625908 libmath-random-perl: "libmath-random-perl: Not whitelisted for autobuildding in non-free"
  add XS-Autobuild field (pkg-perl)
• #627170 src:libdata-amf-perl: "libdata-amf-perl: Can't locate YAML/Base.pm in @INC"
  add missing build dependency (pkg-perl)
• #627177 src:libtest-www-mechanize-perl: "libtest-www-mechanize-perl: Failing tests"
  upload new upstream release (pkg-perl)
• #627229 src:libaudio-ecasound-perl: "libaudio-ecasound-perl: Ecasound.xs:5:23: fatal error: ecasoundc.h: No such file or directory"
  upload package with fixed build dependencies prepared by ghedo (pkg-perl)
• #627231 src:libdbix-class-candy-perl: "libdbix-class-candy-perl: Failing tests t/irc-schema.t"
  adjust versioned build dependencies (pkg-perl)
• #627238 src:libcatalyst-modules-perl: "libcatalyst-modules-perl: failing tests"
  update the faulty module (pkg-perl)
• #627270 src:libstring-errf-perl: "libstring-errf-perl: failing test in t/basic.t"
  upload package prepared by ghedo (pkg-perl)

I still hope to find some more time in the future to look at other RC bugs; after all we want to have a not-too-long freeze for wheezy, don't we?

This has been several months since I didn t use much my laptop, an Asus S5N: it was crippled by a short battery life and was hit by several bugs, most of them targeting the i855GME graphic chipset thanks to the use of GEM and KMS in the latest Xorg. I did not want to invest too much in a laptop and I have found a rebate from Lenovo for Thinkpad Edge series. Voil , I have a Thinkpad Edge 11 .

Hardware Thinkpad Edge is a entry-level notebook from Lenovo. In France, it is available for around 500 , thanks to the usual parity between dollar and euro.

Hardware configuration Lenovo do not sell directly in France. Therefore, you cannot configure your laptop as you want. There is two or three configurations available. This can be a bit frustrating if you want something specific. Here is the configuration that I bought:

• Intel Core i3 380UM at 1.33 GHz CPU.
• 11.6 LED screen, with a resolution of 1366x768.
• 4 GB RAM.
• 320 GB hard drive.
• Wireless network (Centrino Wireless-N) and bluetooth.
• Broadband modem (WWAN)

It s a small laptop but it is not as light as it should be (1.5 kg or 3.3 pounds). Apart from the power supply, you don t get any extra. My Asus was shipped with a wireless mouse, a transport bag, a sleeve, an USB key and a CD burner. On one side, you get two USB ports and on the other side, one USB port, an HDMI port, a network outlet and a speaker jack. The VGA connector is placed on the rear.

BIOS First step: checking BIOS settings. WiMAX can be disabled as well as any other component that you may not need. The keyboard can be configured so that function keys are available directly instead of having to use the Fn key. There is an option called Computrace from AbsoluteSoftware which seems targeted at find back your laptop in case it gets stolen or just let the FBI know where you are. I have disabled it.

Debian installation Debian can be installed from an USB stick. This is really easy now. You grab the ISO image you want to use (I take the one for AMD64 in testing because I will run unstable) and to copy it on the USB stick:

1	# dd if=debian-testing-amd64-netinst.iso of=/dev/sdb

The previous way of making the USB stick bootable, installing a kernel, an initrd and the ISO image is deprecated (and does not work). Moreover, using testing to install Debian allows me to use a 2.6.37 kernel and circumvent some problems that may have happen with an older kernel. During the installation, I choose a guided partitioning using encrypted LVM. I choose to have several partitions but I keep /usr in the root partition since having a separate /usr is less and less supported, especially with piece of software like udev. The partitioning tool in Debian installer do not allow to resize volumes, you need to destroy them and recreate them as well as their content. However, this is still faster than writing a patch for this. When the installation is finished, the laptop boots on a 2.6.38 kernel, asks for the passphrase to decrypt the LUKS volume and display the login prompt a few seconds later.

Software configuration Most of the hardware seems to be supported. No obscure commands to run to get a working network. Therefore, I start by setting up my usual environment.

Setting up the desktop First, I change /etc/apt/sources.list to get unstable:

deb http://ftp.fr.debian.org/debian/ unstable main
deb-src http://ftp.fr.debian.org/debian/ unstable main
deb http://ftp.fr.debian.org/debian/ experimental main contrib non-free

I also want that everything that is installed from experimental to be upgraded if an update is available in experimental. This is done by creating a file /etc/apt/preferences.d/experimental:

Package: *
Pin: release experimental
Pin-Priority: 101

Then, I install the following packages:

• zsh, my favourite shell with my hand-made maturating configuration. I should put it on GitHub one day.
• mg, is the editor that I use to quickly edit a configuration file. I don t like vi. I have used jed for a long time but its default configuration can be cumbersome and it misses some emacs keybinding.
• emacs, my work environment. I use it as a text editor and mail reader (with Gnus). I don t use it as a browser nor as a terminal. As for zsh, I have my configuration files ready to be copied anywhere.
• fvwm, my window manager since quite some time. I use fvwm-crystal on top of it. My configuration is described in another post. I also use conky.
• rxvt-unicode, a terminal. It has a very good terminal emulation and some fancy features like transparency (using compositing or not). It is light and fast and allows to search in the backbuffer. It can use a client/server system that will close all your windows when the server crashes. This almost never happens.
• unison, a synchronisation tool that allows me to keep the same files on my different computers.
• gdm3 is the only display manager that is able to talk correctly to ConsoleKit and get the rights set correctly without adding yourself to a lot of groups.

Nowadays, I use the kernel from Debian and I do not have to run my own configuration for it. The glory days where I had to recompile the kernel before plugging a new USB toy have passed. I remove rpcbind and nfs-common. I use ferm to setup a simple firewall. Here is my ferm.conf:

domain (ip ip6)  
  table filter  
chain INPUT  
    policy DROP;
    mod state state INVALID DROP;
    mod state state (ESTABLISHED RELATED) ACCEPT;
    interface lo ACCEPT;
    proto tcp dport ssh ACCEPT;
    
chain OUTPUT  
    policy ACCEPT;
    mod state state (ESTABLISHED RELATED) ACCEPT;
    
chain FORWARD  
    policy DROP;
    
     
 

unison will then sync my configuration files and my documents. After this step, my environment is ready.

Hardware configuration This is usually the most troublesome part. However, looking at the output of lspci and lsusb, everything seems pretty easy to get supported. Here is lspci output:

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)
00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 06)
00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 (rev 06)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 06)
03:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)

And lsusb output (I disabled the broadband modem in the BIOS and therefore, it does not appear here):

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader
Bus 001 Device 004: ID 0a5c:217f Broadcom Corp. Bluetooth Controller
Bus 002 Device 003: ID 5986:01a7 Acer, Inc Lenovo Integrated Webcam

There is a dedicated page for the Thinkpad Edge 11 on ThinkWiki. This wiki is one of the best source of information when you get a Thinkpad. The kernel as shipped by Debian kernel team contains every module that you may need. One of them, thinkpad_acpi will handle most of the perks under the hood. I do not use a complete desktop like Gnome. I usually prefer to use command line tools and put them in .xsession for persistence. There is usually some graphical utility to do the same thing. There are however some configuration steps that are now far easier to do with a graphical tool. Since I use X all the time, I just rely on those tools when necessary.

BIOS upgrade From lshw output, I see that I already have the latest BIOS available. No need to update then. In case you need to update, yours, ThinkWiki has a documentation to upgrade. You can find memdisk image in syslinux package.

Graphic card The graphic card is integrated into the CPU. Intel usually ships graphic cards well supported by open source drivers. ThinkWiki tells us:

A very recent Linux distribution with kernel 2.6.33 and Intel Xorg driver 2.11 or newer is recommended. Note that XVideo (Xv) playback at certain frame sizes does not work properly unless you have at least version 2.12 of the Intel Xorg driver.

With Debian Wheezy, you get version 2.15. Therefore, configuring the graphic card is just a matter of installing xserver-xorg-video-intel and that s all. No /etc/X11/xorg.conf needed. HDMI and VGA outputs are detected without configuring anything. They can be enabled with xrandr. I did not try if it was possible to use both of them at the same time.

Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm
   1366x768       60.0*+   50.0  
   1360x768       59.8     60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)

Compositing works without any problem. I use only transparency and therefore, I don t know what the speed is on a desktop with all effects turned on. Regarding video acceleration, XVideo is supported but the graphic card also features hardware decoding with i965-va-driver package. Here is the output of vainfo:

libva: libva version 0.32.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/i965_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA API version: 0.32
vainfo: Driver version: i965 Driver 0.1
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple            : VAEntrypointVLD
  VAProfileMPEG2Main              : VAEntrypointVLD
  VAProfileH264Baseline           : VAEntrypointVLD
  VAProfileH264Main               : VAEntrypointVLD
  VAProfileH264High               : VAEntrypointVLD

With Debian, VLC can make use of this if you put ffmpeg-hw=1 in your ~/.config/vlc/vlcrc. We are then greeted by this:

[0x2629040] avcodec decoder: Using VA API version 0.32 for hardware decoding.

Network The network card works out of the box. ThinkWiki tells us that there can be stability problems with 2.6.36 kernel. During the installation, a 2.6.37 was used without any problem. I am now running a 2.6.38 and never got a glitch. It is likely that the described problem was solved with 2.6.37.

UltraNav UltraNav is the combination of the usual touchpad and the trackpoint which is a small joystick in the center of the keyboard and is well known to Thinkpad users since most of them have one. The trackpoint is a great input device. Nowadays, all input devices are configured with the help of xinput command. Here is the output of xinput list:

  Virtual core pointer                      id=2    [master pointer  (3)]
      Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
      SynPS/2 Synaptics TouchPad                id=11   [slave  pointer  (2)]
      TPPS/2 IBM TrackPoint                     id=12   [slave  pointer  (2)]
  Virtual core keyboard                     id=3    [master keyboard (2)]
  Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
  Power Button                              id=6    [slave  keyboard (3)]
  Video Bus                                 id=7    [slave  keyboard (3)]
  Power Button                              id=8    [slave  keyboard (3)]
  Integrated Camera                         id=9    [slave  keyboard (3)]
  AT Translated Set 2 keyboard              id=10   [slave  keyboard (3)]
  ThinkPad Extra Buttons                    id=13   [slave  keyboard (3)]

The command xinput list-props will give you additional information on each input device listed above. You can then configure any settings using xinput set-prop. For example, if you want to enable scrolling by using the edges of the touchpad and enable palm detection, you can use the following commands:

1 2	$ xinput set-int-prop "SynPS/2 Synaptics TouchPad" 'Synaptics Edge Scrolling' 8 1 1 0 $ xinput set-int-prop "SynPS/2 Synaptics TouchPad" 'Synaptics Palm Detection' 8 1

If you want to disable the touchpad and only use the trackpoint, use the following command:

1	$ xinput set-int-prop "SynPS/2 Synaptics TouchPad" 'Synaptics Off' 8 1

Each property has a type and a size. There is no place for guessing since every property is listed in man 4 synaptics. The same applies for the trackpoint but the correct manual page is man 4 evdev. For example, if you want to enable scrolling using the middle button, use:

1 2	$ xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation" 8 1 $ xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Button" 8 2

All those commands can be tossed in ~/.xsession.

Keyboard hot keys Thinkpad laptops usually have a lot of hot keys. This is not the case of the Thinkpad Edge which only features a few of them:

• volume control
• brightness control
• webcam and external screen toggle
• wireless toggle
• multimedia keys

All those keys trigger an event in one of the keyboard listed in xinput list. Therefore, your window manager or any other application can intercept them and act upon. You can use evtest to check which key triggers which event on which keyboard. The acpid daemon listen on those keyboards and can also trigger some actions. For example, it will run ibm-wireless.sh when you hit the wireless toggle. By default, this will enable or disable your wireless card. But you can configure the script to use a multistate toggle and disable or enable the bluetooth card as well.

Sound card As for the network card, the sound card works out of the box. I use PulseAudio because it allows per-application volume control and per-application sound card selection. It comes handy if you have some bluetooth headset. To make PulseAudio the default application for most applications, I put this in my ~/.asoundrc:

pcm.!default  
  type pulse
 
ctl.!default  
  type pulse
 

Wireless card A firmware is needed to make this card work. On Debian, you need to install firmware-iwlwifi package. Then, iwlagn module needs to be loaded. You can check with rfkill list that the wireless card has not been disabled. iw list will then give the status:

Wiphy phy0
Band 1:
    Capabilities: 0x872
        HT20/HT40
        Static SM Power Save
        RX Greenfield
        RX HT20 SGI
        RX HT40 SGI
        No RX STBC
        Max AMSDU length: 3839 bytes
        No DSSS/CCK HT40
    Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
    Minimum RX AMPDU time spacing: 4 usec (0x05)
    HT RX MCS rate indexes supported: 0-15, 32
    TX unequal modulation not supported
    HT TX Max spatial streams: 1
    HT TX MCS rate indexes supported may differ
    Frequencies:
        * 2412 MHz [1] (14.0 dBm)
        * 2417 MHz [2] (14.0 dBm)
        * 2422 MHz [3] (14.0 dBm)
        * 2427 MHz [4] (14.0 dBm)
        * 2432 MHz [5] (14.0 dBm)
        * 2437 MHz [6] (14.0 dBm)
        * 2442 MHz [7] (14.0 dBm)
        * 2447 MHz [8] (14.0 dBm)
        * 2452 MHz [9] (14.0 dBm)
        * 2457 MHz [10] (14.0 dBm)
        * 2462 MHz [11] (14.0 dBm)
        * 2467 MHz [12] (14.0 dBm) (passive scanning, no IBSS)
        * 2472 MHz [13] (14.0 dBm) (passive scanning, no IBSS)
    Bitrates (non-HT):
        * 1.0 Mbps
        * 2.0 Mbps (short preamble supported)
        * 5.5 Mbps (short preamble supported)
        * 11.0 Mbps (short preamble supported)
        * 6.0 Mbps
        * 9.0 Mbps
        * 12.0 Mbps
        * 18.0 Mbps
        * 24.0 Mbps
        * 36.0 Mbps
        * 48.0 Mbps
        * 54.0 Mbps
max # scan SSIDs: 20
Supported interface modes:
     * IBSS
     * managed
     * monitor

I don t know why, but 802.11a channels have been disabled. I don t have interest in them and therefore I did not search why this happens.

iwlagn 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C
iwlagn 0000:03:00.0: device EEPROM VER=0x15d, CALIB=0x6
iwlagn 0000:03:00.0: Device SKU: 0X9
iwlagn 0000:03:00.0: Valid Tx ant: 0X1, Valid Rx ant: 0X3
iwlagn 0000:03:00.0: Tunable channels: 13 802.11bg, 0 802.11a channels
iwlagn 0000:03:00.0: irq 44 for MSI/MSI-X
iwlagn 0000:03:00.0: loaded firmware version 128.50.3.1 build 13488

Wireless is one of the thing that make me use graphical applications like Network Manager. Command line tools are too low level to quickly connect to some random wireless network. There was a large debate in debian-devel@ldo to determine if Network Manager was ready to replace ifup and ifdown commands, even for servers. It seems that this is not something impossible and therefore, I think it has become flexible enough to ensure most of the configuration tasks I need.

Bluetooth The bluetooth chipset is hosted on the USB bus. hci_usb module will take care of it. It supports AD2P and can be used to listen to music with a compatible headset. hciconfig will tell us if the chipset is working. Again, bluetooth is easier to configure with a graphical tool. BlueZ, the bluetooth stack in Linux, uses DBus to communicate with other applications. The command line tools have been deprecated and therefore, you need to fight with some DBus binding to pair your computer to your headset. gnome-bluetooth package comes with an applet which allows you to quickly pair to any device. If you install pulseaudio-module-bluetooth package, any bluetooth headset should work out of the box.

Broadband (WWAN) To configure the broadband modem, the most difficult thing to do is to grab the appropriate firmware. ThinkWiki comes with various instructions to get it. I did not keep my Windows installation and therefore, I grabbed the Qualcomm Gobi 2000 Wireless WAN driver and I unpacked it with some Windows host with msiexec as instructed (I did have to execute the installation program first, otherwise, msiexec tells that the file is invalid). I choosed the default firmware since my laptop is unlocked. ThinkWiki page explains which firmware to choose in which situation. The package gobi-loader needs to be installed. The firmware files amss.mbn, apps.mbn and UQCN.mbn should be placed in /lib/firmware/gobi. They will be loaded by udev. To avoid to reboot, I used this command:

1	# /lib/udev/gobi_loader -2000 /dev/ttyUSB0 /lib/firmware/gobi

To configure the 3G connection, I just used Network Manager. Ensure with rfkill list that your WWAN card is not blocked. I did not test the GPS part that needs to be enabled on Windows.

Webcam Nowadays, USB webcam are UVC device and there is a driver to support this class of devices. Check that the uvcvideo module is correctly loaded and you should have something like this in your dmesg:

uvcvideo: Found UVC 1.00 device Integrated Camera (5986:01a7)

cheese is a small application that can be used to check if the webcam operates as expected.

Card reader Nothing to do. This works out of the box.

Suspend to memory and disk Install the uswsusp package which will also pull pm-utils. You will get pm-suspend and pm-hibernate commands. pm-suspend will enable suspend to memory. On resume, the system takes a whole minute to become operational. I get the following message:

r8169 0000:09:00.0: eth0: unable to apply firmware patch
PM: resume of devices complete after 60786.035 msecs
PM: Finishing wakeup.

Installing firmware-realtek package solves this issue. It should also be solved by a future kernel. I also have this message when I come back from sleep:

[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 9297, at 9297], missed IRQ?

The X server is then slow as hell. The message can be fixed by using i915.semaphores=1 as a kernel parameter but the X server is still slow. It seems that running powertop restores the original speed. This is a known problem. On sleep, the battery loses 2% every 6 hours. This allows you to keep your laptop on sleep for several days if needed. pm-hibernate enable suspend to disk. The suspend part works well but on resume, the kernel freezes after reading back the image into memory. There are some documentation to debug this problem but I prefer to wait for 2.6.39 which may just solves this issue.

Power management Let s see on how we could enhance battery life. First, cpufrequtils package will slow down the processor when it is not used by using the ondemand governor. The frequency will drop from 1.33 GHz to 666 MHz. Several tools are then available:

• pm-utils package comes with scripts to enable some powersaving features. Those scripts are run on ACPI events (for example, when you unplug the AC adapater). There is no way to put the laptop to sleep after two hours of inactivity for example. You need something like sleepd to handle this part. I have found nothing that could dim the screen on inactivity.
• laptop-mode-tools is also a set of script to be run on ACPI events. It is therefore somewhat superseded by pm-utils.
• gnome-power-manager is a daemon that makes use of upowerd. Despite its name, you can run it outside of the Gnome environment. It will put your laptop to sleep on inactivity and will dim the screen when needed. All other functionalities are handled to upowerd. This seems the way to go on today Linux desktops.

Behing the scene, upowerd will call at some point pm-powersave from pm-utils. This allows to run scripts when unplugging the AC adapter. There are some scripts shipped in /usr/lib/pm-utils/power.d. You can add your own in /etc/pm/power.d. Some scripts are configurable. For example, if you create /etc/pm/config.d/local and put SATA_ALPM_ENABLE=true in it, this will enable SATA ALPM mode on battery. You can check what needs to be done with powertop or go to a website like Less Watts to get some tips on what to configure to get a better battery life. Without adding any script, I get 5 hours of battery life with the laptop doing almost nothing. Lenovo tells that you should get 6 hours of battery life. I think that on moderate workloads, you should get 4 hours.

Conclusion This Lenovo Edge has a good value for money. It features a great keyboard for a laptop of its size. It could be lighter and thinner. Its battery life is pretty good. Almost everything works out of the box with GNU/Linux. I hope that 2.6.39 kernel will solve the remaining issues like the suspend on disk issue.

Here is some updates on the LLVM world into Debian.
LLVM and CLANG getting better and better after each release. After some lag, it is now time to have all these packages up-to-date into the archive. Here is an update of their status in Debian:

• LLVM
  LLVM 2.8 and 2.9 are now available into the archive.
  For version 2.8, Matthias Klose deserves most of the credit.
  Version 2.9 is available in experimental. They both build pretty well on most of the architectures besides kfreebsd. It is on my TODO list.
• Clang. A C/C++ compiler.
  clang 2.8 and 2.9 are respectively available in unstable and experimental.
  These versions cover most of C/C++ specifications and more and more big software (Qt, Boost, Scilab, etc) succeed to be built with it. Like LLVM, it is available under most of the Debian architectures (but I haven't tested the quality of the ASM generated). clang can be used just like gcc. With most of software, calling configure/make with CC="clang" or CXX="clang" should be enought.
• * Dragonegg
  Dragonegg is a gcc plugin (llvm-gcc-4.5) which allows gcc to use optimizer and code generators of LLVM.
  It is now straightforward to use:
  
llvm-gcc -o foo foo.c
I have lighten the "contact" between the gcc version used to build the extension and the version used to run it.
  It required the exact same version of gcc (even if the sources say it is probably a too strong requirement). Now, a warning like this one is displayed:
  
Potential incompatible plugin version. GCC: 4.5.3. Expected: 4.5.2
Defines 'dragonegg_disable_version_check' as env variable to remove this warning
Please note that unexpected errors might occur.
If there is a better way to tackle this issue, I will be happy to hear it.
• llvm-defaults
  Last but not least, I uploaded llvm-defaults, a work of Arthur Loiret. This package allows a similar behavior to gcc-defaults. The installation of llvm will provide the default version of llvm.

Deprecated stuffs:

• llvm
  The llvm package has been removed. Actually, it was just the version 2.6 of llvm (see bug #625729). llvm (from llvm-defaults) is now providing the favorite version of llvm.
• llvm-gcc-4.2
  Upstream stopped the development of this plugin.
  It has been removed from the archive (see bug #626007) and dragonegg is taking the relay.
• llvm-snapshot
  llvm-snapshot (see bug #626083) followed the same direction as llvm-gcc-4.2
• llvm-2.7
  llvm-2.7 is still in the archive (see bug #626081) because of some reverse dependencies...

Connectivity can be a force for autonomy and freedom, or it can be used for control and subjugation. The Nintendo 3DS is an example of the latter. Okay, yeah, I just said a cute video game console is a threat to personal freedom. Hear me out. If you haven't read the highlights of Nintendo's Terms of Service for the 3DS yet, you should do that. On one hand, it's "just" a games console. On the other hand, it's a computer, marketed to children, which monitors your location (based on proximity to wifi access points), uploads your photos and messages to Nintendo's servers (giving them a license to re-use that information in various ways), and tracks your activity. Now that's entertainment. If you wanted your Nintendo computer to stop doing those things, you could try to install some 3rd-party "homebrew" software on it. Except then, according to the Terms, Nintendo would "brick" your device render it inoperable, when the modified software is detected. Would you accept Ford disabling your car because you had a mechanic friend fix a problem using some aftermarket parts? Microsoft breaking your computer hardware because you installed Firefox? The ability to stop your electronics from spying on you is an important freedom to defend, even if you don't ever plan on purchasing a Nintendo device. Such terms, and the Digital Restrictions Management software that enforces them, are a problem in all areas of digital life. It's the same fundamental strategy as Apple controlling what you can install on the iPhone or iPad, or Sony sending police officers to a programmer's house because he showed other people how to modify their own computers to make them able to run non-Sony-approved software. If we don't set a strong precedent against this behavior, it will become more prevalent. If we lose the ability to install what we like on our computers, then we lose the ability to use those computers in any way that isn't pre-approved by a corporation. We lose it not only because we ourselves can't install some software maybe we hate changing anything on our computers at all but because the people who write the software we rely on lose that freedom, which ends up impacting even the most non-technical of computer users. Companies like to portray anyone arguing for this freedom as criminals just wanting to illegally copy software. But that's obviously not true -- a person who follows all laws, even the most absurd, might still want to install something to stop Nintendo from receiving copies of her photos or reporting on her location. Companies use the threat of illegal copying to justify massive infringements on real personal freedoms. People often say, "well, just don't buy it then". I agree don't buy it. But don't think this is merely a consumer issue. Terms like Nintendo's are backed by the force of criminal law the Digital Millennium Copyright Act in the US for example which can put you in jail for helping people to modify their own computers. So this is more than a mere preference issue, it's also one of law and ethics. It's not a free market when one side has coercive state resources in play to prop up its arbitrary business model. To help send this message, I just donated to send 5 bricks to Nintendo. I hope you'll send one or five too. The campaign has a goal of sending 200 bricks by the end of today (Monday, May 16th). Nintendo clearly wants to get into the brick-making business, so surely they'll appreciate the extra inventory. (Disclosure: While I do work for the Free Software Foundation and am paid partly to run the Defective by Design campaign, I really did donate, and support this campaign personally.)