Recent versions of xorg have seen changes in defaults for the behaviour of mice/touchpads, such as third button emulation or edge scrolling suddenly not working anymore. What is worse now is that the corresponding entries in the xorg.conf are now ignored... Wait, wait, don't go flaming the Xorg maintainers, but keep on looking rather. This is where I found out about xinput, the new way to customize/parametrize input devices for the X server. And, lets face it, it beats any customization that could have been done in xorg.conf ! Here's how to use it. First, you'll have to install it from its own package (xinput), as it doesn't come bundled with standard X clients. Second, you can find out about the devices connected to your X server using:

~ xinput --list
  Virtual core pointer                          id=2    [master pointer  (3)]
      Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
      SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]

It is easy to find the device you're interested in (here, say the touchpad entry). Then, you list the properties you can set/get using:

~ xinput --list-props "SynPS/2 Synaptics TouchPad"
[...]
        Synaptics Edge Scrolling (269): 0, 0, 0
 

The list is quite impressive, so I have only shown the one I'm interested in. You see here everything is 0, which probably explains why edge scrolling is disable (I don't have a clue what the actual numbers mean). You can finally change the properties this way:

xinput --set-prop "SynPS/2 Synaptics TouchPad" "Synaptics Edge Scrolling"  6 6 6

This gave me back edge scrolling. I used a similar approach to enable again the third button emulation... What is neat here is that the property names are readable enough, and there's a lot of them to play with. Great !

Just two days ago I wrote about S3TC-compressed textures and that it is a little bit tricky for amd64 users to get the correct libraries installed. Since then I've been in contact with Christian Marillat, the guy behind debian-multimedia.org and he immediately responded with uploading ia32-libs-libtxc-dxtn0 to make it easier to install the 32 bit variant of libtxc_dxtn0 on 64 bit platforms. A big Thank You! to Christian! And if you find his service helpful, consider donating to him (I can only guess at the amount of traffic he gets, especially since a lot of people certainly don't use one of the mirrors). (Just a short disclaimer: Christian didn't ask me to put the donation request in this post, in fact he'll only know about it, as soon as this goes online.) I'll add an Suggests: in the next upload of wine-unstable to the server on libtxc-dxtn0/ia32-libs-libtxc-dxtn0 so people'll have an easier time to get S3TC working. But again: before installation: make sure it is legal for you to install the library.

Last night I wanted to buy an album on Amazon and I couldn't do the checkout as the site required me to install the Amazon MP3 Downloader to make the purchase and download of the album. The downloader is not needed for a single song though, but buying each song separately would be more expensive and more work. The good news is that it automatically offered me packages for different Linux distros: Ubuntu, Debian, Fedora and OpenSUSE instead of telling me off for using Linux and leaving me behind with a Windows only download. But here comes the catch, all offered packages are only for the Intel 32-bit architecture. Now this is a showstopper for me, as I am running an AMD64 Debian which is a 64-bit architecture. I first tried to download and run the 32-bit debian package nonetheless as there was some hope with the ia32-libs and ia32-libs-gtk package. But this was not working as the application needs gtkmm libraries like libglademm and bailed when I tried to run it. So I filed a wishlist bug report against ia32-libs-gtk for inclusion of gtkmm and possibly other needed libraries to run the Amazon MP3 downloader on AMD64. So I bought the album using MusicLoad instead which simply puts all songs in a single archive on-the-fly and let me download that archive. When I tweeted my frustration on Twitter I was hinted by Jo Shields and also by Gabriel Burt that there would have been a much simpler solution to this issue by using Banshee which includes an Amazon MP3 Store plugin: This plugin allows you to log into your Amazon account browse their store like the regular Amazon store, plays the song samples directly, purchase songs, downloads the songs and imports them into Banshee's database so you can play them right away. And as if this wasn't good enough yet, with the the purchase of MP3 songs on Amazon using Banshee automatically makes a donation to the GNOME foundation. As I am the only one who forgot or wasn't aware of this awesome solution this deserved some blogging. Update: some people pointed out that clamz is also available to make MP3 purchases on Amazon.

So how much wind energy can we realistically use? A paper (Earth System Dynamics, DOI: 10.5194/esd-2-1-2011) by Miller,Gans and Kleidon (MGK10) has generated a lot of controversy courtesy of a New Scientist review (See Climate Progress for a good rebuttal). They argue that the effective limit we can safely extract without (bad) climatic consequences is around 18--68 TW (we currently use 0.2 TW of wind power). This paper is a follow-on to Kleidons work on the thermodynamics of the climate, where he points out that the free energy is the important measure of what energy can be generated by renewables. The free energy of the atmosphere is on the scale of hundreds of TW, he argues, much less than the heat energy of ~10^5 TW that comes from the sun. He argues that not enough attention is paid to the free energy budget, and argues that from MEP theory that free energy flows through different geophysical processes are more important than people currently think: such energy and momentum flows then lead to faster depletion of gradients than people currently use in their models. Frequently we use "diffusive-like" approximations to stuff we can't explicitly handle,such as convection and eddies below the resolution of our computer models. That the free energy budget, and small-scale processes need more detailed study (such as the transfer of momentum and energy from wind to water), I agree. But paradoxically, MGK10's estimates based on diffusive processes are what gets it into trouble. The critiques (e.g. Jacobsen and Archer) seem to concentrate on the estimates for diffusive and other energy losses (eg. wake fields) and climatic consequences are very loose, and out by factors of 50-100. They also ignore the fact that using wind as a substitute for more destructive energy sources produces a net gain, climate-wise. Based on these numbers, the real limits on wind power are more limited by where we can realistically place turbines, and the use and availability of rare earth metals in turbine magnets (MW sized turbines use over a ton of neodynium each in magnets!) One of the focuses of research at ICHEC and Met Eireann is wind for wind power: this becomes increasingly important for Ireland as we have more energy production by wind. I've been recently involved in a European project Weather Intelligence for Renewable Energies on investigating weather and climate forecasting needs of wind energy. In our weather models, we are getting to finer and finer resolutions (down to 2-5 km operationally, but working on 1 km in research), but as yet do not take account of wind energy changes. Modelling the wake turbulence, etc. and other effects of turbines is a 'fluid dynamics' problem done by the wind turbine manufacturers, mostly, in order to lay out turbines in a farm efficiently; this is done on the timescale of metres and seconds, while on the other end of the spectrum work is done in climate research on the changes in potential winds to see if wind energy will change in a few decades. But little is done on 'weather' scales of kilometres, minutes and hours: it turns out there are wind patterns that we don't predict in our models (vortices, etc.; especially for offshore turbines) that affect wind energy production, but would be very useful for wind farm and electrical grid operators to know about. So we should think about adapting our weather models for these. Either way, it looks like more detailed work on the interactions between atmospheric dynamics and wind farms would be a good thing. Incidentally, whatever about the alarmist nature of the article, kudos to New Scientist for their linking to papers: they quoted the names of the journals (Earth System Dynamics,Philosophical Transactions of the Royal Society), but where the article was not yet published (or behind a paywall), linked to the Arxiv.org version. More could do this. Tags climate, energy, thermodynamics, science, wind, renewables

Meike Reichle is a Debian developer since 2008 but has been involved for longer than that, in particular in Debian Women. She s a great speaker and shared her experience in a Debconf talk. She s also part of the Debian publicity team and managed the live coverage of the last release on identi.ca. Enough introduction, learn more about her by reading the interview. My questions are in bold, the rest is by Meike. Who are you? My name is Meike Reichle, I am a studied information scientist and work as a project manager at Pengutronix, an embedded Linux company probably best known for their ARM kernel work. I live in Germany, more exactly in Lower Saxony, but I was originally born and raised in Swabia. Although I moved here ten years ago I still have a rather strong Swabian cultural identity. (Among other things I pride myself on having introduced a number of fellow DDs to the true promise that are real hand-made Sp tzle ) I am married to Alexander Reichle-Schmehl, we ll have our third wedding anniversary this summer. Apart from Debian most of my spare time is used for all kinds of crafts and DIY activities. Making things with my hands always gives me a great sense of accomplishment. My Free software history is summed up pretty quickly. Like most women of my age I wasn t introduced to computers until well into my teens. I didn t have a computer of my own until I started studying at the university in 2001. From there on things developed rather quickly: Working on the University s Unix terminals got me hooked on *nixes, so I got me one of those Linuxes everyone talked about. I tried a couple of different distributions, ended up with Debian around 2004, started contributing in 2005, and finally became a full DD what a nice coincidence! exactly this day (Apr 18th) three years ago. You re part of Debian Women. How is the project going? I have the feeling that the number of women involved in Debian has not significantly increased. The amount of women active within Debian is a tricky thing to judge. Here s a quick example why: When the DPL was elected in 2004 there were 911 Debian Developers eligible to vote, 4 of them were female. Shortly after, during DebConf4, debian-women was founded. When the current DPL was reelected last month, there were again 911 Debian Developers eligible to vote, but this time 13 of them were women. You can look at these numbers and say The number of female DDs has more than tripled, what a success! Or you can pull out your calculator and it will tell you that in terms of ratio this puts us from a measly 0.4% to an only slightly less measly 1.4% ratio of female DDs. This still is pardon my language a bloody shame, but sadly also pretty close to the average ratio of women in Free Software. So, while I do think that the debian-women project did already have a significant impact on the Debian project as a whole, I don t think it has achieved its goals yet. Not for a long time. There s still a lot to be done but unfortunately the debian-women project has somewhat run out of steam at the moment. The seven years of its existence divide quite equally into the first half, which was very active and saw great results, and the second half, which was very slow and much more passive. In my impression debian-women is currently undergoing a rather bumpy generational change. On the one hand a lot of the original members, including myself, have reduced their involvement. Speaking for myself this is caused by shift of interests as much as general weariness. On the other hand there are only very few women following up. This development is also reflected quite harshly in DD numbers: If I don t misjudge any first names (and I desperately hope I do!) for the last three years not a single woman has joined Debian as a developer! After the great start debian-women has had, this is a very painful thing to see! That said, things don t look all bad. There is a number of women maintaining packages without being DDs and there s also at least one woman currently in NM, so there s hope this standstill won t last very much longer. But still, the fact remains that debian-women is suffering from a rather serious recruitment problem and I hope that this interview might actually help to spur some new or not yet active members into action. The aim of debian-women is far from achieved and now that its initial members are receding its time for new members to step up and take initiative. What should Debian do to be more attractive to women ? I think the general atmosphere has improved, we re less tolerant with rude behaviour, the usual tone on mailing lists has improved. Yet it doesn t seem to be enough. If there was a female DD for every time I answered that question First of all, I agree, Debian as a community has improved tremendously! Our general tone is much more friendly and cooperative and there is now a much better awareness of the impression we give to outsiders and newcomers. Now on to the difficult part: The question what should be done to get more women into Free Software has been around almost as long as Free Software exists, and it has been answered very well by a lot of people: Twenty years ago Ellen Spertus wrote Why are There so Few Female Computer Scientists? and most of it still holds true. Almost ten years ago Val Henson (now Aurora) wrote HOWTO Encourage Women in Linux and that also is still pretty accurate. In 2006 Floss Pols undertook extensive research to find out why there were so few women in Open Source and Free Software and how that could be changed. They also came up with a very good set of recommendations. All of these texts highlight different aspects of that question and all of them have very good points. I personally have, over the years, arrived at a rather sociological, not to say holistic point of view. In fact I answered the exact same question a few days ago, and the answer I gave then was this: After ~10 years of women in tech advocacy I d say the ultimate and final measure to get more women into Free Software is by finally achieving a truly equal society and at the same time dramatically improving child care support in almost any country. I ve come to the conclusion that what really holds women back in practice is not so much a lack of skill or interest but a simple lack of opportunity. For most of us Free Software is what we do in our spare time and that s something that women, even today, have considerably less of than men. Even in couples where both partners work full-time it is still mostly the woman who does the majority of the housework and child care duties. In most cultures men have a perceived right to their leisure time that does not to the same degree exist for women. That is one major reason, the other is instilled modesty, which has kind of become my personal arch-enemy by now. I ve talked to so many girls and women at all sorts of events about why they won t take up Computer Science studies or join a Free Software project and the answer I hear most often is that they do not consider themselves good enough in one or another aspect. Sometimes they will doubt their technical skills, sometimes their language skills, sometimes their stamina. Needless to say these girls and women were not any less qualified than the people already active in Free Software. So, yes, in the short and medium term making Debian a more welcoming and friendly place is the way to go. As many others pointed out already this will not only benefit prospective contributors but the community as a whole: those new to it as well as those who ve been in it for a long time. In the long term however what we need is empowerment! Women who are just as confident about their skills as men and are not discouraged by uncooperative environments. This is of course something that is culturally deep-rooted and can only happen in a very large time frame. So, for the moment the way to go in my view is accessibility: a cooperative atmosphere, a code of conduct, comprehensive documentation not only of technical aspects but also of structures and processes. The other thing we need to do is to have as many already active women as possible attend as many Linux/Debian/Free Software/Whatever events as possible. In my experience it happens quite often that other women see these women, feel very inspired by them, get to talk to them and then a few days later show up on some mailing list or IRC channel. From what I ve seen personal contact still beats any other kind of recruiting measures. You re a Debian developer but you re also married with a Debian developer (Alexander Reichle-Schmehl). Did you meet because of Debian? If not, who introduced Debian to the other one? We did in fact meet because of Debian. More specifically during our booth shift at the Debian booth at LinuxTag 2005, where I did a talk on the debian-women project and Alex organised the DebianDay. After that our relationship developed pretty much along our Debian activities: After our initial meeting we talked a lot on #debian.de, when Alex went to DebConf5 and I didn t we noticed that we kind of missed each other. The first gift he ever gave me was a Debconf5 shirt and a box Finnish chocolates (I still have one of them today. ) Our first secret kiss was at ApacheCon 2005, where we were both staffing the Debian booth (kudos to abe for pretending not to notice). We then became an official couple at Berlinux 2005 where we were both staffing the Debian booth and giving talks on packaging and user motivation. Our first real relationship stress test was when we both joined the DebConf6 orga team. It was a stressful time, but we passed it with flying colours! About a year later we announced our engagement via planet.debian.org. Our wedding was a veritable MiniDebConf, one of the best gifts we got was a Debian cookbook including the favourite recipes of DDs from around the world. By now we ve both finished university and work full-time jobs, so we don t do as many talks and attend as many Debian events as we used to. Instead we now mainly focus on press and publicity work, which is quite practical to work on as a pair. It s actually rather funny that way, Alex and I get confused with each other quite often, since we have almost the same name, often pick up on each other s E-Mail conversations and are most often quoted by our function rather than by name. Because of we have kind of merged into this virtual Debian Press Person in the perception of many of our contacts. You also have another hat : Debian Press Officer. What is this about? What would you suggest to people who would like get involved in that domain? Debian press work is mainly about providing an official and coordinated point of contact to anyone wanting information from or about Debian. The press team answers all sorts of inquiries (the most popular one is is of course always the next release date) and makes sure all important events and developments within Debian receive the attention and recognition they deserve. Debian is a diverse project where every sort of contributor is free to voice his or her opinion in any way. We don t have NDAs or prescribed terminology. That s one of the things I love about Debian but also something that makes us difficult to handle for conventional media. They want official statements, in generally understandable terms, at appointed times. That s what the press team takes care of. Almost all of the press work is done in the publicity team, which coordinates using IRC, Mail and SVN. The publicity team also publishes the Debian Project News, which are very popular among our users and developers. Press work is also an area of work that offers lots of possibilities for non-technical contribution. http://wiki.debian.org/Teams/Publicity lists a number of possibilities for contribution and, like most Debian Teams, we d be more than grateful to get some more helping hands and happy to introduce interested newcomers to our work. What s the biggest problem of Debian? In my view: Overwork. Debian has thousands of contributors but still a lot of the main work rests on very few shoulders. We need more contributors, especially, but not only in the key teams. In order to get more people we need to do some marketing which is very hard for us, since we are very proud of our independence and have a strong focus on purely technical aspects rather than aiming for popularity. However, with the current amount of Open Source and Free Software projects to join we find ourselves not only in a contest on technical excellence but also a sort of popularity contest that is about perception rather than hard facts. This popularity contest is difficult for Debian and currently costs us quite a bunch of very capable people. Do you have wishes for Debian Wheezy? My answer to that is a non-technical one: I think Debian is currently very under-appreciated, we do a lot of great work and maybe even more importantly we do a lot of important work for Software Freedom, sometimes even at the cost of our above-mentioned popularity. I hope people will appreciate that more again in the future. Is there someone in Debian that you admire for their contributions? Over the years I have made a lot of friends within the Debian community, some have even become family. That makes it somewhat hard to single out individual people. I think what I admire most is continuous commitment. I am very impressed by those among us who have kept up a high level of commitment over many years and at the same time managed to bring that in line with a fulfilled personal/family life. That s something that I hope I ll also be able to achieve in the years to come.

---

Thank you to Meike for the time spent answering my questions. I hope you enjoyed reading her 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.

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

When you don t update a blog, it gets stale fast. Tim Bray Of course, I didn t intend to violate this basic rule of blogging. It just happened one thing leads to another, and pretty soon you notice just how little your front page has changed in the past two-and-a-half years. So, I shall begin again. Quite a bit has changed:

• It s especially ironic, given the previous post, that our family has given in and replaced the main television with a HDTV. Not that I ve changed pmy mind much; it s just that I ve decided to live with the limitations of the technology, and have figured out how to work around some of them.
• Although my suspicion of the cloud remains, my participation has greatly increased. I m now on Twitter, Facebook, LinkedIn, and piles of Google services.
• There s been a major health scare in the family, which is now behind us.

All of these will get their own posts in the very near future. In the meantime, enjoy the new look. (Especially on mobile!)

One of the more exciting upcoming features of Farsight is the ability to change the amount of required bandwidth depending on network conditions. Which means Telepathy based VoIP clients will be able to use higher resolutions and better audio/video quality if the network connectivity allows. And ofcourse, when the available bandwidth is low, the bandwidth usage can be lowered such that calls are still possible with lower but hopefully still acceptable quality. One side of the full story is measuring the available bandwidth, which hopefully Olivier will tell at some point. The other part is actually using less bandwidth. In case technical details are not that interesting to you, probably best to stop reading at this point.. An important way to control the bandwidth we're using in a call is setting the target bitrate on the encoding GStreamer element. While previously it was enough for us to set the bitrate before encoding started, we now need to be able to change it at runtime. And not only that, the codec implementation should ideally respond within a few frames and have a reasonable constant per-frame size. All in all, a lot of requirements on codecs we didn't really have before. Which usually means we need to retest the various codecs we often use and make sure we configure them correctly for the behaviour we'd like to see (and fix them if necessary). To do this I've written a small test program, which simply changes the target bitrate over time and outputs some numbers suitable to feed into gnuplot to turn into graphs. For example, when using x264enc with the current default farsight settings a part of the resulting graph looks something like this (full graph here): The blue impulses is the per-frame size (scaled), the green line the bitrate average over 10 frames and the red line the target bitrate. Clearly this isn't an ideal picture, we will need to do some more tweaks to our default settings to make x264 behave the way we want. The same will be true for all other codecs and codec elements, at the moment the GStreamer VP8 element doesn't handle run-time bitrate changes at all and the Theora element acts it its very own interesting way (graph here)

Jacob really enjoys his pajamas. By this point, he can mostly get himself ready for bed. He still wants help brushing his teeth but that s about it. His favorite pajamas are his rocket ship pajamas , which also cover his feet and have a white pad underneath the feet. That s his favorite part. They have rockets all over them, and he sometimes will run out of a room and inform me with delight, I m all rocket ships! Oliver has really started to form up words. We can pick out words like lettuce, truck, book, look, and dad John . He also has a way of saying there it is , most particularly when looking at trains. Jacob still loves trains. In church, he will take his markers, connect them end to end, and have a marker train that will keep him entertained for quite a long while. He will slide it back and forth on the pew, and eventually it will slide in a tunnel (behind my back). This actually started with hymnbook trains get a few books in a row, and it s a train. Anything can be a train to Jacob. Driving down the road, we might see what he calls tree trains, which are just trees in a row. Last Sunday, the Kansas Mennonite Men s Chorus had its first concert of the season. I sing with this group, which has nearly 300 men in it. It s a lot of fun to be a part of that group, and the music is wonderful. Jacob and Oliver were there on Sunday, and both started to take more of an interest in the music that before. Jacob particularly loved the song Dry Bones, which had a number of odd percussion instruments in it. He was laughing at spots, and wanted to hear me sing it for the next several days. He even wanted Terah to read the program from the concert to him before his nap one day. Oliver enjoyed it too, and kept saying dad John (his word for me) whenever there was a soloist. I didn t sing a solo, but apparently to 1-year-old eyes, 300 guys all dressed alike all look like dad. Jacob and I recently have been reading Winnie the Pooh stories at his bedtime. Not the Disney books, but the original A. A. Milne stories. We read a few pages every night, and have made it to page 214 by now. Jacob loves it. And he s becoming increasingly interested in reading things. Sometimes we ve been unsure if he s reading something or just had it memorized. Last night, I got out the book, and we were on a page he had never seen or heard before. He pointed to a word, and said, It says Roo there! And indeed it did. Then he added, It says said Roo. . Yep. And then he read me the whole sentence:

I love jumping, said Roo.

I believe that s the first time I ve been certain Jacob has read me an entire sentence without having memorized any of it beforehand. And he won t be old enough to start Kindergarten for another year and a half. We then read the story, and when I came to the sentence Jacob had read to me, he interrupted, saying, No, dad, I will read that one! And he did.

I've read bits and pieces of the recent "Network Manager as default" thread on debian-devel. I have a strong personal preference towards one side, but that's not the point of this post (and I hope I can keep the tone neutral, hence why I didn't get into the mailing list discussion). I think this discussion is just a proxy flame-war to a bigger issue that lurks behind the scenes. That is, what is the most efficient way to configure systems. On one side, we have the sysadmins, with their toolbox, and who desire the most reliable way to configure systems. In the other corner, we have people whose problem is how to configure systems with the least amount of human involvement. Whether it's ifupdown versus NetworkManger, or explicit groups versus things like PolicyKit, it's basically the same thing: do we want to have an OS that is slimmer, more customisable and more stable, but needs hand-holding, or do we accept some degradation in flexibility/customisation in exchange for decreasing the cost of administration? I have personal preferences to one side, and practical preferences to another side. I'm not sure which is best in 2011, and it depends on many factors, but looking forward in 20 years: I don't think we will afford to hand-hold a Linux machine as mach as we were doing it 10 years or even 5 years ago. Presuming that software capabilities advance, it should be possible to hand-over responsibility of autoconfiguration to software, rather than hand-configuring config files (doing it via configuration management systems is beside the point, as it is a mixed setting; I'm discussing only the extremes). So in any case, we'll have to accept that at one point we will have to rely on automated stuff for some parts of the system. The question is when we as sysadmins will be ready to do that, and when the software will be mature enough to bear that kind of responsibility. And then there's my next gripe: what is good for a few systems (dpkg/apt-get) might not be good for many. I find lately that relying on dpkg plus a configuration management tool to keep many machines in sync is not the best way. Keeping with the time means changes, whether we want it or not. PS: for the record, not even my laptop(s) run NetworkManager

Update: I reported the deluge issues and added a new problem about the lack of click on tapping on the touchpad.

---

I know that installation reports and upgrade reports need to be submitted to the BTS, but I just want to point out some issues for people that might hit the same issue on upgrade from lenny to squeeze.

But before that I must say I like the new Debian site(s) look.

Issue number one: When upgrading from lenny's deluge to squeeze's deluge, the new version of the app is quite different from the prevoious version. Here are some things to take into account:

• when starting for the first time the new version it will take ages to check (and probably recalculate some checksums); make sure you don't mind the I/O activity when you start it; a torrent will not be available until this check is done
  
• the new version relies on a client-server model which is disabled if you use the "classic mode" (Edit->Preferences->Interface)
• some features available in the old version are not available in the new version (e.g.: graph for traffic and embedded search function)
• some features are availbale as modules, but there are just a few modules
• when starting the graphical interface in the new mode, don't use the "Start daemon" button, use the "Connect" button. If you start the daemon via the "Start daemon" button the "Connect" button will become "Disconnect" although the client is NOT connected. Using the "Connect" button directly solves the problem.
• There is an ugly side panel (on the left side) which, IMHO has no real function or use, except filtering in the view the active downloads or similar things
• when choosing the place to save a torrent and trying to set that place as the default location, deluge will not remember that setting
• closing now (with the daemon option) the app will close just the client, but the server/daemon will remain in the background, unless is explicitly closed (there is a dedicated menu entry)
  

Issue number 2: I seem to experience some weird glyph/graphic area reshuffling in GNOME (maybe X?) after recovering from hibernate. With a total (according to my current sloppy counting) 5 resumes, things get back to normal, but I suspect the next hibernate-resume cycle will restart the glyph reshuffling cycle.

By glyph/graphic area reshuffling I mean alterations of the shapes of the glyphs (and some areas on the background picture) in such a manner that it seems that within a set of 8/16/N (?) lines are shifted/rotated sideways with some undefined and different ammount each, but in a reproducible manner ("b" will always be doodled in the same way, no matter if is in the word "be" or if is in the word "absurd".

I'll try to provide some picture in the bug report, once I report this issue in BTS.

Update: I reported this in Debian's BTS and upstream (with screenshots, too). I am not convinced the problem is in the kernel since I tried an old kernel and saw the same issue. I suspect X is at fault.

Issue number 3: This is more like a convenience issue. In the past I was using "hibernate" with uswsusp which I understand is now broken beyond repair and replaced by pm-utils. The thing I miss in the hibernate process now is the ability to abort the hibernation process as it was possible in lenny's uswsusp by pressing the backspace key during the storing of the state on disk phase.


Issue number 4: The upgrade process was quite tedious because once I tried upgrading aptitude, python2.6 was pulled in and almost all apps ended up needing upgrading due to the chaining of necessary package upgrades.


Issue number 5: For some weird reason pulseaudio was initially installed making playback of any audio impossible (the apps wanting to emit noises would just freeze but they were TERM-inatable) and later I've seen a default null audio sink was defined for me. Killing pulseaudio and removing the ~/.pulse directory fixed the issue (but I should probably see why pulseaudio didn't work properly in the first place because I suspect the problem will reappear at the next restart - I usually use hibernate).

Issue number 6: Tapping the touchpad no longer results in a click. Maybe some packages got removed? And, no, it is the same when I remove the external mouse, so it is not because of some smart behaviour of that sort.

Otherwise I am quite satisfied with the result of the upgrade. A huge "thank you" to all people involved in the development of squeeze.

Most probably haven't noticed yet but I finished the Mono 2.10.1 debian packaging effort of the past 3 months and uploaded it to Debian/Experimental. With Mono 2.10 I had to make the biggest changes in Mono packaging since the big Mono 2.0 upload. The runtime no longer supports the 1.0 and 2.0 runtime profile, instead it now supports the 2.0 and 4.0 runtime profile. This meant I had to drop all libmono*1.0-cil packages and add libmono*4.0-cil packages. This sounds like a lot of s/1.0/4.0/ work but it actually wasn't. Mono 2.10 ships a lot of new libraries over 2.6 and I had again to decide where they should go. "Where should this $library go?" I have been playing this game for the past 7 years maintaining Mono and I finally gave up on it... What, where, when, why? I could give now a 2 hours talk of the issues behind the current packaging approach (keeping the number of library packages low) but instead I will do something else. Please, just take a look at this picture for a second: If your browser crashed, your eyes hurt or your brain simply melted, I think you have got the idea. The Big Split The cure? cli-common-dev! This is a package that contains 2 extremely important debhelper packaging tools for packaging Mono/CLI related packages called dh_makeclilibs and dh_clideps. If you don't know these, they do exact the same thing as dh_makeshlibs and dh_shlibdeps do. dh_makeclilibs generates library dependency tracking information and dh_clideps consumes that information to automatically generate the package dependencies for you. So each library of the 4.0 runtime profile has now it's own package, simple as that, the rest does cli-common-dev for me and you. "Hey, that Mono packaging bastard is polluting the Debian archive because of his laziness!" No, I am not. This packaging change not only has the advantage of simplifying the packaging and with that bringing new Mono versions faster to you but also reduces the typical install size for applications as they will only pull in the really used libraries of Mono instead of groups of them. I don't have any numbers handy right now as none of the applications are built against Mono 2.10 (yet), but when the transition starts we will get numbers. New Features There is also a new SGen flavor of Mono available called mono-runtime-sgen which is no longer using the conservative non-generational Boehm's garbage collector but SGen which is a simple generational garbage collector with promising advantages. And here some more Mono 2.8/2.10 news from /usr/share/doc/mono-runtime/NEWS.Debian.gz:

• SGen Precise Stack Scanning
• Enhanced SIMD with new methods for Vector data type conversions and swapping elements in vectors
• ASP.NET MVC 3.0 (not included, only supported)
• The C# Interactive Shell can now be used as shebang: #!/usr/bin/csharp
• .NET 4.0 runtime
• C# 4.0 compiler
• ASP.NET 4.0
• Managed Extensibility Framework (MEF)
• System.Data.Services.Client (OData)
• glib was replaced with eglib
• Removed .NET 1.1 runtime

Architecture Regressions With the initial upload of Mono 2.10.1 to Debian/Experimental the architecture world broke apart and it regressed on all Mono architectures except for i386 and amd64 There is a reason it's called experimental isn't there? In mono 2.10.1-3 I could solve all regressions except for kfreebsd-* and armel. Jo Shields fixed the remaining regressions and the world started to look good again in mono 2.10.1-4! He also took care of mono-basic, mod-mono and xsp, but mod-mono and xsp are still waiting for the translation call deadline to pass by so they can also be uploaded to Debian/Experimental. Planned Transition As mentioned above, there will be a Mono 2.10 transition needed when the packages hit Debian/Unstable. There is no ETA yet on this when it will happen as I have to coordinate this with debian-release first. But as things are not showtime ready in experimental anyhow, this will not happen too soonish. The Mono 2.10 transition plan will be covered in a following post. GIVMENOWPLX OMG, all this rumbling about Mono 2.10 and I still haven't said a word on how to obtain it, sorry about this, just do this and I will shut up now:

echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list
apt-get update
apt-get install -t experimental mono-complete

(this is the easiest way of getting only mono 2.10.1 from experimental)

I often see on debian-perl IRC changelog related to e-mail changes. For instance, when a Debian contributor becomes a Debian developer, he often wants to change his old e-mail address in his brand new debian e-mail address. This change is mostly done while updating packages to fix bugs or ship a new upstream releases. Since this change is trivial and mostly boring, forgetting about it is likely. Well, at least, that s true for the author of this blog who did have to change he e-mail address recently. The last version Config::Model Perl module (and its Dpkg model) offers a way to automatically perform this boring update task for you while you work on more interesting problems. Dpkg model now provides a bunch of meta Dpkg parameters. These Meta parameters are used to customize the behavior of the Dpkg editor tool to suit your needs. Among these parameters, the email-updates meta parameters enable you to specify which email address to update and how. Here s a screenshot of config-edit GUI invoked on a package (with config-edit -application dpkg): In this case, all occurrences of the dominique.dumont email will be replaced with the new domi.dumont email in the control and in the copyright file. You can change or add new addresses using the GUI. When the package data (i.e. control, copyright and source) is saved, all meta information is also saved. Meta dpkg data is saved in its own file, so the email change will be applied to all packages you will be working on: E-mail address changes can also be specified in a command line:

$ config-edit -application dpkg \
  'meta email-updates:"domi@old.fr"="dod@new.fr"' \
 -ui none -save

Note: this command must be run in a source package directory. This new address change is stored in ~/.local/share/.dpkg-meta.yml or ~/.local/share/.dpkg-meta.yml:

---
email-updates:
  domi@old.fr: dod@new.fr

From now on, anytime you run config-edit -application dpkg (and save the data) while you work on a package, all occurrences of your old e-mail adress in debian.control will be changed with the new email address. All the best

forked-daapd v0.15 is here! The database speedups did not make it into this release as they still need some more work. Now let s talk about what did make it into this release: AppleTV metadata support. When streaming to an AppleTV, you ll now get the cover art, artist, album, title and playback position displayed on your TV. This was made possible by a forked-daapd user who offered me one of the new AppleTVs, so thanks much to him! Although we haven t got the database speedups this time around, we ve got some other speedups:

• the code generating the song list was slightly reworked;
• hash tables of static data were replaced with static hash tables generated by gperf;
• the artwork code can now send out both PNG and JPEG to clients.

The first two items bring in a new build-dependency: gperf. I promise it s not some Java-based monstrosity ;) It s small and C++, so no issue getting that running on whatever your platform is. Pre-generated files are not provided for this. The last item means if your cover art is mostly JPEG, forked-daapd won t be spending time turning it into PNG before sending it out to the client. That s some CPU time that can be put to better use. Next release: when it s ready! For Squeeze users, I am providing backports on backports.debian.org; due to the update policy, they are lagging behind the releases. Tarballs available at http://alioth.debian.org/~jblache/forked-daapd/ ; GPG signatures made with my Debian key F5D65169.

Yesterday one of my free software halves was very, very happy, because after a lot of work, GNOME 3 was released!

I've been following GNOME 3.0's development since Debian got the first GNOME Shell snapshots uploaded to experimental. While my first experience, on an old, 2 or 3 generations behind Athlon 800MHz with 512MB of RAM was horrid due to the lack of features (it wasn't even an alpha!) and the incredible slowness due to the crappy Radeon 9200, I've seen it evolve to the gem that was released yesterday. I haven't been so excited about GNOME since GTK+ and GNOME 2.0 were released after their eternal development cycle, and was happy to see how positive the atmosphere in #gnome-hackers was last night when vuntz sent the email and everyone was able to relax after a very long sprint of hard work. Congratulations everyone, because not only this a great, solid release, but it's also a brave one. Change does not come without resistance, but I am very sure the path GNOME opened last night has a bright and innovative future. I will be delighted to walk this path to enjoy it!

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now Release manager , a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen. You could expect the release managers to have some rest after a big release, but it s not really the case. With the long freeze, loads of transitions have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions. He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam. Who are you? I m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf. As well as being on the release team, I m a member of the maintainer teams for devscripts and lintian. Can you describe your journey in Debian and in the release team? I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels. When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9. As most readers will be aware, we unfortunately reached a point during last year where we didn t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say How much time do you usually spend working for the release team ? I ve been trying to work out how to usefully answer this question. My initial answer was approximately two hours each day , but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I ve decided to stick with my initial answer. During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I m reliably informed that at that point the correct answer to the question is too much time . What s your own retrospective of the Squeeze release? What went well and what needs to be improved? Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle. One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS s blocking functionality to indicate reasons why a request cannot be fulfilled right now. Are you in favor of time based freeze? I think there s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package. One thing I m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about. What are your plans for Debian Wheezy? The Wheezy to-do list I started before the final Squeeze release begins multiarch, multiarch, multiarch . It looks like we re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so and more transparent. With my package maintenance hats on, I d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian. Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing stable can be accommodated to support this? I m not yet convinced that the concept of a rolling, constantly usable distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The testing distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions. It s been suggested that testing and rolling could be basically the same for most of the cycle, with rolling then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that testing was intended to avoid (i.e. the old frozen suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time. What s the biggest problem of Debian? The thing that I ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves. That s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a do-ocracy then we need to permit people the freedom to do . Is there someone in Debian that you admire for their contributions? All previous release managers, for making the job look much easier than it seems when you re in the hot seat . Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.

---

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

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

Last week, I had to put my daily (real) work off for a bit, to get some rest. I took this occasion to implement a few ideas I had for the Buildd Status Pages. Mainly, I wanted to get rid of my external dependencies which are:

• https://buildd.debian.org/build.php which shows all build logs available for a package. It s nice and simple, but old and not easy to read. In my opinion, it s almost useless because it takes some time to realize (visually) what happened to the package (there are no colors to distinguish successful builds from failures, text is not aligned, etc ).
• https://buildd.debian.org/fetch.cgi which shows the content of a build log given a package, a version, an architecture and a time-stamp identifying the log file (you can see this as an example). The page works, there is no real need to rewrite it, modify it or whatever. It just does its job perfectly, but it was my last external dependency

Besides of getting rid of external dependencies, there were also a few feature requests (#618676, #612174, #518526) waiting for a while and it was good time to fix them. Hopefully, there are related to what I was fixing. The final version is now deployed and can be used. The implemented changes are :

• From the regular package view, you have now a link to all logs available for that packages (click on Logs in the table), or all logs for a specific architecture (click on old in the table, for you preferred architecture).
• The listing of available build logs has now its own new page. The default listing shows everything, i.e. every version available and everywhere known architecture (just like the old page did before). But now, you get with that the build time and disk space consumed during the build, when available. Furthermore, it groups the logs by version so that it becomes easier to see that all that group are logs for the same version . And you can also show build logs for a specific architecture by choosing one (links in rows) ; or restrict on versions, in a similar way. And, of course, there are some additional colors in each row to distinguish successful builds from those who failed.
• The page that fetches the log is now available from other pages. And this removes the last external dependency.
• All pages have an appropriate HTML title set (yeah, it s a shame that I didn t fix that since the first deployment).

I think that I tested well enough this new version and it works okay. Nevertheless, if you encounter a bug or a strange behavior, please don t hesitate to contact me (either by mail or on irc) or submit a bug report against buildd.debian.org. The next steps (probably) are :

• add the last feature that pkg.cgi has which the ability to select a list of packages according to their maintainer (or co-maintainer).
• a better integration with P-A-S files.
• show tail of logs for build failures.
• ask wb-adm if build.cgi, bymaint.php, fetch.php, info.cgi are still needed/useful. If you do use use/need them, please speak up before they get removed.
• if you have any other idea, do submit a bugreport.

Imagine a conversation where some people would like to try to make Debian better, and several people say things like this:

as soon as you make this particular change, I will stop using Debian and all my customers will stop using Debian too

Quite a number of different possible responses pop up in my head immediately.

• you're trying to blackmail us; we're better off without you, regardless of who you or your customers are
• you're about four years old
• you're delusional: Debian is too hard a habit to get rid of, so you're going to be using Debian anyway, regardless of what we do

More seriously: should this kind of behavior be acceptable on the Debian mailing lists? Not only is it insulting and anti-social, but trying to influence purely technical decisions by threats is not going to make Debian better.

A brand new and shiny 0.9.3 release of Rcpp is now on CRAN and Debian. This version contains an actual bug fix for Rcpp modules and a few build improvements, including for both clang/llvm and g++-4.6 (which, being in Debian, is already used for conformance checks on CRAN's incoming directory) and g++-4.5. We also updated the main introductory vignette Rcpp-introduction to the content of what should be a forthcoming paper in the Journal of Statistical Software. The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.3   2011-04-05
    o   Fixed a bug in which modules code was not behaving when compiled 
        twice as can easily happen with inline'ed version
    o   Exceptions code includes exception_defines.h only when g++ is 4.5 or
        younger as the file no longer exists with g++-4.6
    
    o   The documentation Makefile now uses the $R_HOME environment variable
    o   The documentation Makefile no longer calls clean in the all target
    o   C++ conformance issue found by clang/llvm addressed by re-ordering
        declarations in grow.h as unqualified names must be declared before
        they are used, even when used within templates
    o   The 'long long' typedef now depends on C++0x being enabled as this
        was not a feature in C++98; this suppresses a new g++-4.5 warning
    o   The Rcpp-introduction vignette was updated to the forthcoming JSS paper

Thanks to CRANberries, there is also a diff to the previous release 0.9.2:

Diff between Rcpp versions 0.9.2 dated 2011-02-24 and 0.9.3 dated 2011-04-05
 ChangeLog                                                      60 
 DESCRIPTION                                                     8 
 R/00_classes.R                                                  5 
 R/01_show.R                                                    44 
 R/Module.R                                                      1 
 cleanup                                                         2 
 inst/NEWS                                                      23 
 inst/doc/Makefile                                              74 
 inst/doc/Rcpp-FAQ.pdf                                       binary
 inst/doc/Rcpp-FAQ/Rcpp-FAQ.Rnw                                  2 
 inst/doc/Rcpp-extending.pdf                                 binary
 inst/doc/Rcpp-introduction.Rnw                               1355 +++++++------
 inst/doc/Rcpp-introduction.pdf                              binary
 inst/doc/Rcpp-modules.pdf                                   binary
 inst/doc/Rcpp-package.pdf                                   binary
 inst/doc/Rcpp-quickref.pdf                                  binary
 inst/doc/Rcpp-sugar.pdf                                     binary
 inst/doc/Rcpp-unitTests.pdf                                 binary
 inst/doc/Rcpp.bib                                              99 
 inst/doc/jss.bst                                            only
 inst/doc/unitTests-results/Rcpp-unitTests.html                 18 
 inst/doc/unitTests-results/Rcpp-unitTests.txt                  46 
 inst/include/Rcpp/Module.h                                     40 
 inst/include/Rcpp/Vector.h                                      6 
 inst/include/Rcpp/config.h                                      2 
 inst/include/Rcpp/grow.h                                       91 
 inst/include/Rcpp/module/Module_generated_ctor_signature.h     18 
 inst/include/Rcpp/vector/RangeIndexer.h                         5 
 inst/include/RcppCommon.h                                       6 
 inst/unitTests/runit.Module.R                                  19 
 inst/unitTests/testRcppModule/src/stdVector.cpp                 7 
 src/exceptions.cpp                                              2 
 32 files changed, 1167 insertions(+), 766 deletions(-)

As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

Today I shot an image of a bear my daughter gave to my wife for mothers day. This week I am also including a behind the scenes shot that shows how cheap my home "studio" is. In case you can't tell that is my bed with t-shirt covered boxes on it. All the light for this image comes from the window. After a little editing of the image the final outcome is what you see at the top of this post.

Since I m soliciting donations to support my Debian work, the least I can do is explain what I do. You can thus expect to see an article like this one every month. Multi-Arch work I updated the code to use another layout for the control files stored in /var/lib/dpkg/info/. Instead of using a sub-directory per architecture (arch/package.type), we decided to use package:arch.type but only for packages which are Multi-Arch: same. dpkg is taking care to rename the files the first time it is executed with write rights and then updates /var/lib/dpkg/info/format to remember that the upgrade has been done and that we can rely on the new structure. I filed a few bugs on packages that are improperly accessing those internal files instead of using the appropriate dpkg-query interface. I sent a heads-up mail on -devel to make other people aware of those problems in the hope to discover most of them as early as possible. After that, the work stalled because Guillem went away for 2 weeks and thus stopped his review of my work. I hope he will quickly resume the review and that we will get something final this month. With the arrival of dpkg 1.16.0, it s now possible to start converting libraries to multi-arch even if full multi-arch support has not yet landed in dpkg proper. See http://wiki.debian.org/Multiarch/Bootstrapping for the detailed plan. If you re curious about Multi-Arch, you might want to read this article of Steve Langasek as well. Bug triage for dpkg in launchpad At the start of the month, there was close to 500 bugs reported against the dpkg package in Launchpad. Unfortunately most of it is noise many of the reported bugs are misfiled, they show an upgrade problem of a random package and that upgrade problem confuses update-manager which tries to configure an already configured package. This generates a second error that apport attributes to dpkg and the resulting bug report is thus filed on dpkg. There are literally hundreds of those that have to be reclassified. Michael Vogt and Brian Murray did some triaging, and I also spend quite some hours on this task. It s a bit frustrating as I tend to mark many reports Incomplete because there s no way they can be acted upon and many of them are so old that the reporter is unlikely to be able to provide supplementary information. But in the middle of this noise, there are some useful bug reports, like LP#739179 which enabled me to fix a regression even before it reached Debian Unstable (because Ubuntu runs a snapshot of dpkg with multiarch support). I subscribed to the Launchpad bugs for dpkg via the Debian Package Tracking System (thanks to the derivatives-bugs keyword) and will try to keep up with the incoming reports. Misc dpkg work The ftpmasters came up with a request for a new field (see 619131) in source packages. After a quick discussion and a round of review on debian-policy@l.d.o, I implemented the new Package-List field. This should allow the ftpmasters to save some time in NEW processing, but we deferred the change for the next dpkg version (1.16.1) to ponder a bit more on the design of the field. I also fixed a bunch of bugs (#619541, #605719, #598922, #616096) and merged a patch of Mark Hymers to recognize the new Built-Using field. Developers-reference work The review process for changes to the developers-reference is not working as it should. And I suffered from it while trying to integrate the patch I wrote for the Developer duties chapter (see #548867). We purposely changed the maintainer field from debian-doc to debian-policy in the hope to have more reviews of suggested changes and to seek some sort of consensus before committing anything. But we don t get more reviews and deciding to commit a patch is now even harder than it was (except for trivial stuff where personal opinions can t interfere). In my case, I only got the feedback of Charles Plessy which was very mixed to say the least. I tried to improve my patch based on what he expressed but I also clearly disagreed with some of his assertions and was convinced that my wording was in line with the dominant point of view within Debian. We tried to involve the release team in the discussion because most of what I documented was about helping making stable release happen, but nobody of the team answered. Instead of letting the situation (and my patch) rot, I solicited feedback from the DPL and from another developers-reference editor to see whether my patch was an improvement or not. After some more time, I went ahead and committed it. It was not pleasant for anyone. I don t know how we can improve this. Contrary to the policy, the developers-reference is a document that is not normative, I believe the result is better when we put some soul into it. But it s a real challenge when you seek a consensus and that the interest in reviewing changes is so low. DVD shop listed on debian.org In February, I launched a DVD shop whose benefits are used to fund my Debian work. Shortly after the launch I used the official form to be added to the official listing of Debian CD vendors and offered a few suggestions to deal with vendors who are selling unofficial images (with firmware in my case). A few weeks later, I got no answers: neither for my request nor for my suggestions, I mailed the cdvendors@debian.org team directly asking for a status update and quickly got an answer suggesting that Simon Paillard usually does the work and can t process the backlog due to some injury. At this point no concerns had been raised about adding me to the list. To save some time and some work for the team, I added myself to the list since I had commit rights and I informed them that I did it, so that they can review it. Shortly after I did that, Martin Zobel Helas objected to my addition. I cleared some misunderstandings but the discussion also lead to some changes to please everybody: the listing now indicates that some images are unofficial and I have prepared a special landing page for people coming from the Debian website through this listing. Debian column on OMG! Ubuntu I have always been a firm believer that it s important for Debian to reach out to the widest public with its message of freedom. Thus when Benjamin Humphrey contacted the debian-publicity team to find volunteers to write a Debian column on OMG! Ubuntu, I immediately jumped in. I wrote 4 articles over there. The tone is very different from my articles on my blog and I like that duality. Check out Debian is dying! Oh my word!, Debian or Ubuntu, which is the best place to contribute?, Are you contributing your share? and Ubuntu s CTO reveals DEX: an effort to close the gap with Debian. It s a great win-win situation, OMG! Ubuntu benefits from my articles, Debian s values are relayed further, and OMG! Ubuntu s large audience also helps me develop my own blog. Work on my book I had lots of paperwork to do this month (annual accounting stuff for my company) and I did not have as much time as I hoped for my book. Still I have a updated a few more chapters of my French book and I certainly hope to complete the update during April. This means that the work on the English translation could start in may. Work on my blog Just like for my book, it has been relatively difficult for me to cope with my policy of two articles every week. But I still managed to get quite some good stuff out. I interviewed Christian Perrier (Debian s translation coordinator) and also Bdale Garbee (chair of Debian s technical committee). I finished my series of Debian Cleanup Tips with 2 supplementary articles:

• Identify cruft that can be removed from your Debian system
• Remove automatically installed packages

The removal of firmware is causing troubles to quite some users so I wrote an article explaining how to deal with the problem. A regular reader also asked me to write an article about Jigdo, I executed myself because it was a good idea and that he has been very nice with me: Download ISO images of Debian CD/DVD at light speed with Jigdo. Last but not least, I shared my package maintainer pledge which inspired my developers-reference patch (see discussion above). Thanks Many thanks to all the people who showed their appreciation of my work. The 324.37 EUR that you gave me in February represented 2 days and a half of my time that I have spent working on the above projects. See you next month for a new summary of my activities.

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