Maybe many people have missed this: Aptitude package manager is undergoing a revival. Two fellows, Daniel Hartwig and Manuel A. Fernandez Montecelo, started triaging bugs and preparing a possible new version. Daniel Burrows, who maintained it for years (and did a really good job in this, given the high exposure of aptitude, which happened to be the recommended package managers during a few years), has currently less free time for doing the work. So, this is really great to see people motivated in taking the job over. In case you want to help, please joing the "aptitude-devel" mailing list on lists.alioth.debian.org. There is an Alioth project but Daniel is currently the only administrator. I might ask for admin privileges so that I can validate new team members. Of course, I personnally can't do much in this (C++ programming, coding, ah ah ah...things that are black magic for me), except my usual help for i18n/l10n. But, at minimum, I can make noise about this effort to encourage the volunteers who commit themselves to revive the project. And, I can certainly help by sponsoring their work (none of them is DD as of now) even if I am not skilled enough to review everything. I don't want to see good work wasted because people insist on nitpicking each and every commit line before "approving" it (any idea what I'm talking about, here? :-)).

Steve McIntyre has been contributing to Debian since 1996, 2 years before I joined! But I quickly stumbled upon Steve: in 1999, he was struggling with getting his debian-cd script to produce 2 ISO images (it was the first time that Debian did no longer fit on a single CD), I helped him by rewriting debian-cd with a robust system to split packages on as many ISO images as required. I remember those times very well because Steve was very supportive of my efforts and it was a real pleasure to get this done. His friendly nature probably also explains why he got elected Debian Project Leader twice! Anyway, enough history, check out his interview to learn more about the great work he s doing nowadays. My questions are in bold, the rest is by Steve. Raphael: Who are you? Steve: I m a professional software engineer, 37, living in Cambridge (England) with my new wife Jo. I studied for the EIST degree at the University of Cambridge, then (like many people here, it seems) I just forgot to go home again afterwards and settled here. I spent more of my study time playing with Linux than working on my degree, so I guess I m lucky that it worked and I found a career in that area! Raphael: How did you start contributing to Debian? Steve: During my time in college, I started hacking on software in my free time, using Slackware as my first Linux distribution from the middle of 1994. After encountering more and more problems with Slackware, I was encouraged by a number of friends to make the jump over to Debian and in October 1996 I did. The installation process back then was much harder than anything people see today, but after a long weekend I finally had my Debian system up and running. I was already one of the main upstream developers for the Mikmod music player at that time, so that very same weekend I applied to be a DD so I could maintain it in Debian too. Back then, the NM process was much simpler: I just mailed a key to Bruce and he set me up with an account almost immediately! I then found that Joey Hess had beaten me to it and already packaged Mikmod. Grrr! Raphael: What s your biggest achievement within Debian? Steve: Without a doubt, my proudest achievement within Debian is being elected Project Leader for 2 years by the other developers. It s a great feeling to have earned the trust of your friends and peers, and also a great responsibility to go and help Debian where needed: talking to the press about Debian, assisting wherever problems crop up, etc. The DPL job is certainly a lot of hard work, and I have nothing but respect for anybody who volunteers for it.

It s a great feeling to have earned the trust of your friends and peers.

Elsewhere, I ve been leading the Debian CD team for years too, both doing most of the maintenance of the debian-cd package and producing and testing the regular installation CDs and DVDs that we ship to the world. Again, this is a time-consuming job but it needs doing and it s worthwhile. Raphael: You re currently employed by ARM. What are you working on and are they supportive of your Debian involvement? Steve: The situation within ARM is very interesting; I m employed in PDSW (Processor Division, SoftWare), a new group founded just a couple of years back to help improve the state of software on ARM. Most of the people in the group are working on Free Software at this stage (e.g. toolchains, browsers, Linux kernel), which is lovely. Some of the engineers have also been seconded into a new non-profit company Linaro, which is a collaboration between ARM and a number of other companies investing in core Linux software and tools for ARM-based CPUs. I m one of the ARM engineers in Linaro, and I m a Technical Architect in the Office of the CTO. My role includes looking at future projects for Linaro to help with (e.g. ARM servers), but for the last few months I ve been concentrating on the new armhf architecture in Debian, Ubuntu and elsewhere. armhf is a new architecture in Debian and Ubuntu terms, but it s not strictly a new type of hardware. Instead, it s a new ABI. We have two reasons for doing this work:

1. It targets the latest version of 32-bit ARM CPUs (v7) and makes better use of the hardware, for better performance. Compare targetting i686 instead of i386, for example. We ll still support the older armel port for the foreseeable future for users with older hardware that can t run armhf.
2. More importantly: we are standardising on the ABI / compiler options / hardware support for future users.

In the past, there has been a huge amount of specialisation (aka fragmentation) in the ARM Linux environment, and that worked OK for specialised devices that only ever ran the software shipped with them. ARM CPUs are now becoming more and more mainstream, so people will expect to be able to install generic software on their machines. That gives a requirement for a standard base platform, and armhf (arm-linux-gnueabihf in GNU triplet terms) is that standard that we are pushing in the community. Debian, Ubuntu, Fedora, Suse and others are all going to use this, making compatibility possible. I ve been working with a small team of people to make armhf happen, helping where needed: putting together build machines; patching Debian packages directly; discussing and fixing toolchain issues with Ubuntu folks; agreeing ABI specifications with people from Fedora; advising people from other distros bootstrapping their new ARM ports. ARM and Linaro are very supportive of this work, and it s been lovely being sponsored to work directly on Free Software like this. It s work that will directly benefit ARM and its partners (of course!), but it s also helping out more generally too: Debian QA work, cross-build support, bootstrapping efforts, multi-arch. More and more of the ARM market is driven by Free Software, and companies are acknowledging that. I should probably also mention that we re hiring ! Raphael: What are your plans for Debian Wheezy? Steve: There are three main tracks here. Obviously, I m interested in seeing armhf release with Wheezy. We ve just been added to Testing last weekend, so that s going well. We ve got over 90% of the archive built now, and we re mopping up the remaining issues. I m the primary maintainer of cdrkit at this point, but I d prefer to have it go away. Xorriso and the associated software in libisoburn is almost capable of replacing all the aging cdrtools-derived software that we have in Debian, The only missing feature that I m aware of is creating the HFS hybrid filesystems that we use for installations on Mac systems. I ve been talking with the upstream folks about this for some time already, and I m hoping we can finish this soon enough that we can get it into Wheezy. Finally, I ve got the ever-growing wishlist of things for debian-cd. We ve got the beginnings of an automated test suite that Mart n Ferrari has written, but it needs integrating and improving. I want to help get regular weekly/daily/release debian-live builds running on the main CD build machine. There s work needed if we want to make good installation media for the new multi-arch world, too. The Emdebian people are asking for help making CD images The list goes on Raphael: The ARM community seems to be very interested in multi-arch. Can you explain why? Steve: There are a number of reasons for ARM people to be interested in multi-arch; two really stand out for me:

• With the historical issues around the plethora of ARM ABIs in the wild, multi-arch will allow us to potentially support multiple ABIs cleanly on one system. That allows users to have (for example) an up-to-date system that makes the most of their current hardware, yet also run legacy programs that might use an older ABI. There s also a new 64-bit architecture coming (ARMv8) which will run older 32-bit software; again, multi-arch makes mixed installation of old and new software reasonable.
• ARM has traditionally been a common target for cross-compilation, and I d expect that to remain the case for a long time to come yet. For a lot of embedded developers, using a big fast i386/amd64 machine to compile is much faster than using a limited-power small ARM CPU. However, setting up sane cross-compilation environments has long been a bugbear for developers. Getting the toolchain and all the cross-architecture libraries to work together correctly can be like black magic. This is potentially the killer app for multi-arch: simply install the libraries for the target architecture directly on your development machine. Install a simple cross-gcc package and (maybe) qemu, and you re all set.

This is potentially the killer app for multi-arch: simply install the libraries for the target architecture [ ], install a simple cross-gcc package [ ] and you re all set.

Raphael: What s the biggest problem of Debian? Steve: For me, Debian s biggest problem has been the same for a long time: we are forever short of enough people to do the work that we re trying to do. That might sound like a weird thing to claim when Debian is one of the largest Free Software projects on the planet, but it s more a statement of just how huge our goals are. Many of the largest things in Debian are developed or controlled by very small teams working very hard, and there s always a risk of losing people due to burnout in those situations.

We are forever short of enough people to do the work that we re trying to do.

Some of the tasks that should be easy given our large membership (e.g. large-scale packaging transitions) can often instead take a very long time. We are fortunate to have more people wanting to join in Debian s work all the time, but we also need to be careful to keep on promoting what we re doing and recruiting new contributors, encouraging them to get more and more involved in core work. Debian gets ever bigger in terms of the size and the number of packages we distribute; we re not currently matching that growth rate elsewhere. Raphael: What motivates you to continue to contribute year after year? Steve: This one is much easier to answer! The thing that first attracted me to Debian was the fact that I could help to develop it, help to decide how things could and should be done within it. Instead of being forced to accept what some corporation decided I could do with my computer, I could change the software to suit my needs and preferences. Alongside that, I could get involved with a strong community of similar people all over the world, all with their own strong opinions about how software should work. I joined in and found it was great fun and very rewarding. That hasn t changed for me in the intervening years, and that s why I m still around. I work on Debian because it helps me to get the OS that I want to use. It seems that lots of people around the world find it useful too, and that s awesome. Raphael: Do you believe that Stefano Zacchiroli will be the first DPL who managed to stay 3 consecutive years on the seat? Would you like him to candidate again? Steve: To be honest, I would be very surprised if Zack stood again for DPL this year. He told me himself that he wasn t planning on it, and I can understand that decision. He s been an awesome DPL in my opinion, and I m glad that he took the job. But: it is also a very difficult and time-consuming task that would be enough to wear down anybody. If Zack does decide to stand again, I would support him 100%. But I know that we also have lots of other good people in Debian who would be ready to take up the challenge next. Raphael: Is there someone in Debian that you admire for their contributions? Steve: There are lots of people I admire in Debian, so many so that I almost don t want to list individuals here for fear of missing people out. But Bdale Garbee has been an inspiration to many of us, for many years. He s technically excellent, a great friend to many of us, an endless source of sage advice and (last but not least) he has some wonderful stories to tell about his experiences over the years. On top of that, he s just cool. Christian Perrier is another exceptional developer, in my eyes he s great at co-ordinating people in translations, working tirelessly to make this very important part of Debian work better and better with every release. He s also a really nice guy and we all love him. I also have to mention Joey Hess here, whether he likes it or not. *grin* He s been responsible for so many good things in Debian over the years, even if he did steal my first package Finally, the teams of people who make sure that Debian is always working: the security team and DSA. The rest of us can choose to take time off from Debian to go and do other things, but these people need to cover things every day. That s a major responsibility, and I salute them for taking on that challenge.

---

Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

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, Google+, Twitter and Facebook.

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

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	1537
Affecting Wheezy:	900
Wheezy only:	188
Remaining to be fixed in Wheezy:	712

Of these 712 bugs, the following tags are set:

Pending in Wheezy:	48
Patched in Wheezy:	111
Duplicates in Wheezy:	45
Can be fixed in a security Update:	24
Contrib or non-free in Wheezy:	11
Claimed in Wheezy:	0
Delayed in Wheezy:	2
Otherwise fixed in Wheezy:	46

Ignoring all the above (multiple tags possible) 477 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 799 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

I just got confirmed my flight bookings for FOSDEM 2012, so I'm looking to meet all great people there again. This year we've again arranged there meeting of phpMyAdmin developers, now it also includes three new faces from last years GSoC. As for my schedule I did not yet find time to check all the schedule, but what definitely sounds interesting for me is Open Mobile Linux Devroom and some talks in MySQL and Friends Devroom. Rest will be (as usual) scheduled on the fly as I meet people there. This year I decided to deliberately skip keysigning as last year I anyway did not manage to attend it and I expect this year to be equally busy. In case you want to meet me there, just let me know, we can try to arrange something in free slots :-).

Filed under: Debian English Gammu Phpmyadmin Suse 0 comments Flattr this!

I just got confirmed my flight bookings for FOSDEM 2012, so I'm looking to meet all great people there again. This year we've again arranged there meeting of phpMyAdmin developers, now it also includes three new faces from last years GSoC. As for my schedule I did not yet find time to check all the schedule, but what definitely sounds interesting for me is Open Mobile Linux Devroom and some talks in MySQL and Friends Devroom. Rest will be (as usual) scheduled on the fly as I meet people there. This year I decided to deliberately skip keysigning as last year I anyway did not manage to attend it and I expect this year to be equally busy. In case you want to meet me there, just let me know, we can try to arrange something in free slots :-).

Filed under: Debian English Gammu Phpmyadmin Suse 0 comments Flattr this!

I had a bit of an adventure yesterday, which would have taken some explaining if the police had gotten involved. It went a little something like this... My friend and former co-worker Sara was in the US Virgin Islands for the holidays. Her boyfriend, Karl, flew there separately for the tail end of her time there. Yesterday, I received a phone call from Sara, saying that Karl had managed to fly out to the Virgin Islands without his passport. Apparently you can get there without one, but to get back into the mainland US, you need one. She wanted to know if I could get one of my lock-picking co-workers to break into their apartment and retrieve Karl's passport and mail it them. Karl was supposed to fly out the next day. Attempts by Sara to contact her landlord had failed, so they didn't have many other options (apart from mailing me a key, which would have cost them another day). I asked one of my co-workers, Jason, who I knew was into lock picking, if he was up for it, and he offered to put me in touch with another guy who had dominated the recent lock picking night that he'd run. So now I'm talking to David, who's on board with the mission, but doesn't have his lock picking gear on him. No problem, Jason says he'll lend me his, which was at work with him. So we have a plan. Our friends Ian and Melinda are currently in Australia. They've lent us their car because it's leased, and they have some minimum mileage they're supposed to do and they're under it, so I've been driving to work in their car some days. As it happens, I drove to work in it yesterday. So now David and I set out in a car that neither of us own, with a lock picking set that belongs to another person, to break into an apartment of someone who's in the Virgin Islands. What could possibly go wrong? I'm told that it's not illegal to own a lock picking set, but if you're caught with one on your person and you're not a locksmith, you can get into all sorts of trouble. On top of that I'd have a hard time explaining the car I'm driving. We get to Sara and Karl's condo complex. It has a common gate that visitors would normal get buzzed through. Turns out it's not that hard to climb over. It's got some benign-looking spiky things on top, but I could get a leg over from the left hand side of the gate and jump over without impaling myself. Then I let David in and we proceeded upstairs to Sara and Karl's apartment door, where David set to work. Sara said that just the dead bolt was locked. David started at it with Jason's tools, trying to be as discreet as possible. It was about 3:30pm and there was no one around, but we could hear some noises from the neighbouring apartment (the two front doors were right next to each other). After what felt like about half an hour without success (the last pin of the lock was particularly tricky apparently) David was having to resort to more noisy techniques with the lock, so I decided to take the up-front approach and just inform the next door neighbour what we were doing in case he/she (I think it was a she) decided to call the cops on us. I told her through the door why we were there and what we were doing. She didn't seem to care too much. David then proceeded to start "raking" the lock, essentially brute forcing the pins with a lot of jiggling, and finally managed to pick it and we were in. I quickly found Karl's passport where it was suspected to be, and then we pondered how we were going to lock the door again. We could have just locked the door knob instead of the deadbolt and closed the door behind us, but we weren't sure if Sara and Karl had a key to the doorknob (Sara said they always just locked the deadbolt). Sara was fine with leaving the door unlocked until they got home, but weren't so keen on leaving our fingerprints all over the place and then leaving the door unlocked. David tried to re-pick the deadbolt so that he could lock it via the same means as opened it, and I scouted around for a key. I managed to find a key that locked both the deadbolt and the doorknob, so I took that with us and locked up their apartment. In David's defense, the deadbolt was a bit stiff to lock even with the key. I dropped David back at work, collected my stuff (it was now about 4:30pm) and headed to the UPS Store to ship Karl's passport to him as fast as humanly possible. I just made the 5pm pick up. Today I received an SMS from Sara informing me that they had received the passport. I was very impressed with how fast it got to them. So that was all a bit of an adventure. I'm not sure how much longer Karl is going to have to stay in the Virgin Islands as a result. I'm going to suggest that Sara and Karl leave a spare key with someone in future.

Hello, World! Last year, a bit of a fuss was kicked up in the Perl community about the low quality of search results for the phrase "Perl tutorial". Various ideas for fixing this were proposed, including the handy Perl tutorial hub, but kicking Leeds University off the coveted top spot is going to be a real challenge. The problem is, most Perl tutorials on the internet were written for Perl 4; modern Perl doesn't get a look-in. It's a miracle anyone manages to learn Perl at all... While thinking over this problem, I was reading Mithaldu's original criteria for the "content creation" option. "Community effort"... "github repo"... "exported to HTML regularly"... if only Perl had some central site where you can publish documentation... that all Perl hackers can access and update... like CPAN. So although my documentation-writing skills are pretty weak, I proudly introduce the Perl-Tutorial CPAN dist and github repository. The great thing about writing Perl documentation using POD is that you can link to other CPAN references so easily - as the basics get filled out, they can guide the user towards how to learn more about each topic. Everyone who's anyone knows how to send a pull request on github, and there seems to be far more of a community feel to CPAN these days. Version 0.001 is just "Hello, World!" - but watch this space. :)

Current status Back in September, I wrote about the machines that I set up to help bootstrap the new armhf port in Debian. Basing on Konstantinos' huge efforts in bringing up the new "architecture" in debian-ports, we started importing armhf into the main Debian archive on the 24th of November. Since then, those builders have been churning away night and day to build the huge collection of software that makes up the Debian archive. The current state can be seen on the armhf buildd status page, and there's a nice graph showing how quickly we've managed to run from 0 to over 90% of the archive here. (Click on the image for a larger version, or visit https://buildd.debian.org/stats/ for other versions. We overtook hurd-i386 quickly and are now ahead of the kfreebsd-* architectures. We've recently brought 3 more similar build machines online (hildegard, howells and hummel), again sponsored by the nice folks at Linaro but now hosted at the York NeuroImaging Centre at the University of York. This gives us both more build horsepower to keep up with building more different bits of Debian (experimental, updates etc.) and more redundancy in case of problems. We now have the vast majority of the archive built, and now a number of us are concentrating on fixing the remaining issues: language bootstraps and bugs. Also, on the 7th of January we were just added into testing, the next step on our path for inclusion as a Debian release architecture. Setting up the machines A lot of people have been asking me about the physical setup I showed in my last blog about these machines, so here's more details for those who are interested.

• 3U mini-rack
  • Schroff model 24563-192 subrack (3U, 235mm deep), ordered from Farnell in the UK.
  • Added some 24560-353 220mm guide rails (Farnell link).
  Lovely kit, which fits together easily for a rigid enclosure.
• ATX PSU
  • Ideally with lots of old-style Molex power connectors. I bought the cheapest one I could find from my supplier, and dismantled it. I cannibalised another old PSU and soldered on some extra Molex connectors.
  • In theory, the 6 boards and disks I'm using here could use up to 15W each on the 5V rail (but in practice much less); any current PSU on the market should handle that easily.
  • While I had the case open, I drilled holes and put some bolts through so I could mount it to the mini-rack.
  • Finally, connect together pins 15 and 16 on the ATX power connector so that the PSU will come on without needing to be connected to a PC motherboard (details on wikipedia).
• Freescale iMX53 Quickstart boards
  • These are the little 3-inch square dev boards I'm using. I bought them from Mouser here, but there are quite a few other companies selling them too. Apparently this exact part has just gone EOL, but there is a replacement that I would hope to work in its place.
• 2.5 inch SATA hard drives
  • I just bought what looked reasonably priced from my local supplier, 320 GB on the first machines and 250 GB on the next three after the recent rise in disk prices.
• Cables and connectors
  • 45cm right-angle SATA cable with one right-angled end like this
  • Molex to twin SATA-power cable like this
  • 2.1mm/5.0mm power plug like here (L48AY at Maplin)
  The downside of the Quickstart board is that it doesn't include a SATA power connector on the board, just a SATA data connector. So, what I've done for my boards is modify Molex to SATA power splitters. This way I get a single power input for the board/drive combination as a whole.
  • The Molex socket will connect to the Molex plug from the PSU
  • The first SATA power connector goes to the laptop drive
  • Cut off the second SATA connector
  • Using the red and black (5V and ground) wires remaining, solder on a power plug to drive the board itself
• Perspex board
  • I found a supplier near Cambridge for some perspex. Each machine has a base card measuring 220mm x 100mm, 2mm thick. I drilled holes and mounted each board with a drive and its cables as shown here.

Mount the 6 boards into the mini-rack, connect up the Molex power connectors to each board, attach ethernet cables and turn it all on! Each board comes with a micro-SD card containing uboot and an Ubuntu installation. I've configured uboot to boot off the hard drive directly, but leaving configuration available to use the Ubuntu on the micro-SD as a simple rescue system should the need arise. The Quickstart boards are not ideal physically for two reasons: the lack of SATA power, plus you need to push a power button on each board to boot it - they don't boot automatically the moment power is applied. However, they're quite inexpensive little machines and have done a great job of building the Debian archive so far! The ideal machines for us would also include more RAM at this point. CPU on these is adequate, but the larger C++ packages (yay webkit!) use a huge amount of memory at link time. Linking in swap is not the best thing, performance-wise... :-( UPDATE 2012-01-12: Ian tells me that the newer Quickstart-R boards apparently have a different power controller; these now boot up straight away without needing you to push a button. That sounds useful.

I am happy to announce that today we managed to wrap up and publish the second beta version of Debian Edu / Skolelinux. If you want to test a LDAP backed Kerberos server with out of the box PXE configuration for running diskless machines and installing new machines, check it out. If you need a software solution for your school, check it out too. The full announcement is available on the project announcement list.

Linux 3.2 was released yesterday. It s been a fairly busy release for ASoC in terms of the subsystem, including the first piece of work at moving the register I/O code over to regmap to eliminate the duplication there, but a pretty quiet one on the drivers front.

• Substantial optimization of the DAPM algorithm, substantially reducing the CPU usage when power states change. This is especially beneficial with larger modern devices.
• Support for CODEC drivers using the regmap API.
• Some smaller API updates support for larger register maps, support for specifying a source when setting a sysclk.
• New CPU drivers for Alchemy and Freescale MXS.
• New CODEC drivers for Analog ADAU1373, Realtek RT5631 and Wolfson Microelectronics WM1811 and WM5100.

The end of the year is a period of time during which many people sit down and decide to donate some money to initiatives that pursue the public good. I have that habit myself. At the end of 2011 I've decided to donate to Wikipedia, as I consider Wikipedia to be one of the greatest achievements of humanity and I see a lot of value in keeping it running on a purely non-profit basis. (Not to mention that it's already quite annoying to see Jimbo's banners one month per year, go figure what would happen if those banners would suddenly turn into permanent advertisement banners!) You may wonder why I haven't donated to Debian, given my involvement in the project. In fact, that involvement is precisely why I didn't donate to Debian: there is some sort of sanity in keeping a distinction between causes to which I donate my spare time (the case of Debian) and those to which I donate money (the case of Wikipedia), and I like to keep that distinction. As DPL, I've the luxury of being cc:-ed on Debian donation notifications that flow through SPI, and I can also check the flow of donations to other Debian trusted organizations. This year, I've been particularly impressed by the high flow of Debian donations during the end of the year. Thank you, donors, it is thanks to your generosity that we keep many Debian activities going. Using the money people like you regularly donate to Debian we:

• buy hardware and hardware-related services that keep the Debian infrastructure running
• sponsor sprints and other events that allow volunteer developers to get together and work on Debian in fun and productive contexts
• support travel expenses of Debian developers that attend conferences or meetings as representatives of the Debian Project

On a more political note, I'm happy to observe that Debian incomes come almost entirely from private citizens. We do have big corporate sponsors, but their contributions tend to be concentrated as specifically earmarked donations for our annual conference. This is good for them, because they get the fancy banners on the DebConf website and at the conference. But it is also good for Debian, because a donation-based economy (as Debian's, with DebConf exception) is less likely to be influenced by the whims of a few big donors. But with (great) donations comes (great) responsibility. In particular, it comes the need of budget transparency. You can't go out soliciting donations and simply say "thanks, your contribution is appreciated". You need to show donors how their money are used, so that they can judge whether they made the right choice in donating to you or not. Whether they will donate again in the future or not granting long term sustainability to your project usually depends on that. So, if you have donated to Debian or are considering doing so in the future, here are a few of places where you can check what we have been doing with donated money:

• Minutes of SPI monthly meetings, that come with monthly reports of incomes and expenses of all affiliated projects
• the list of sprints, past and forthcoming
• "Bits from the DPL" mails (indexed on the DPL "team" page), that often come with a "money" section highligthing significant expenses for the reporting period
• the DebConf reports, that come with detailed "budgeting" sections of each DebConf edition

Albeit quite detailed, the above is not enough: we should do better on the transparency of Debian budget. For one thing, the above is too scattered: budget transparency should not depend on (potential) donors mixing and matching too many sources of information. Further more, the above is not even complete: SPI is not the only Debian trusted organization, and the accessibility of information about Debian budgets hosted at other organizations varies quite a bit. We've been working on improving this for the past year or so: we're not there yet, but I'm positive we can have detailed and comprehensive budgets encompassing all Debian trusted organizations published in the coming months . Why has it taken so long and what could possibly be so difficult about it? I think the cause of the delay is twofold:

1. The disperse nature of Debian adds some difficulties to regular accounting challenges. Contrary to other FOSS projects I'm aware of, we've many different trusted organizations, each one with its own different way of reporting things. The advantage of such a setup is that we can often avoid the costs of money transfers around the world, costs in which we'd incur had we a single organization holding our assets, say, in the US. Still, having too many organizations is counterproductive. This is why for the past 1.5 years I've been working on consolidating our money assets into as few budgets as possible (avoiding, for instance, to use more than one organization per currency).
2. We tend to be good at recruiting packaging geeks, but not so good at recruiting other kinds of geeks: budget geeks, artwork geeks, journalist geeks, management geeks, etc. But it is upon those other kinds of "geekness" that many activities of "standard" Debian geeks depend. For example: if you want to have a steady flow of new project members, you need to communicate effectively Debian values and make some buzz around them, so that you could hope they get to the right ears. If you want to organize sprints for maintainers to work together you need money donations, and to solicit donations you need a transparent budget. Etc. In the specific case of accounting, we're now lucky enough to have found "standard" Debian geeks who also have a passion for accounting and auditing; but that appaears to be, essentially, a coincidence. If we don't fix the more general problem, I believe our difficulties in recruiting "non-standard" Debian geeks might hurt us quite a bit in the long run.

Recently I've been wanting to replace my old point and shoot camera, a Canon PowerShot A620. I've got a pair of DLSR cameras and I do frequently carry one of them out with me, but there are undoubtedly occasions where I'd rather not bother, or where I find myself wanting to take a picture without having one to hand. Unfortunately the PowerShot is pretty large itself, although significantly less so than the DSLRS I possess. (I cannot remember the last time I used the PowerShot outside my flat, that is how rarely it goes outdoors). The PowerShot has been a good camera to me for many years and the three features I liked the most:

• A real view-finder.
• It runs on 4x AA batteries; easy to find.
• Shoots (smallish) movies.
  • This last thing is no longer a concern now I have a Kodak Playsport HD video toy.

Picking a replacement camera, even with the help of fine comparison websites like snapsort.com is hard. Cameras have moved on and "improved" a lot over the last few years - to the extent that finding one with a built-in viewfinder is hard. Finding one with a built-in viewfinder and running on easily replaceable batteries was virtually impossible. Eventually I settled on the Panasonic Lumix FS16, which omits both:

• Integrated rechargeable battery.
• LCD-only viewfinder.

The way that you use the LCD or viewfinder differs pretty significantly, but the LCD wasn't as bad as I'd feared:

ViewFinder

You hold the camera to your eye, and press the appropriate buttons.

LCD

You typically hold the camera at arms length, which means you're prone to shaking your hands/arms and getting blurry shots. Because you're holding the camera relatively far away from your eyes if you have the sun at your back you're liable to need to squint.

The LCD on the Lumix FS-16 isn't amazing, but neither is it horrific and it is better than expected in dark locations. So after a week what do I think? On the whole it is a fine camera, better than the PowerShot in many ways, and while it has draw-backs none are deal-breakers:

Size

The best camera is one you have with you; on that basis this camera is a clear win being smaller, lighter, and more compact than the Canon. I've taken this camera with me, randomly, to several places and returned with useful and interesting images.

Low Light

Low light performance is pretty poor. With only one manual control you see noise if you're shooting in gloomy pubs, and outdoors. With the flash you can get acceptable pictures if you're careful - but its a tricky thing to get right. (To update this a little: Outdoors at night? No. In a pub with poor lighting you'll be alright.)

Manual Controls

The camera features precisely two manual controls:

• "Flash on" vs. "Flash off".
• ISO can be changed from: Auto, 100, 200, 400, 800, 1200 and 1600.

There is no notion of shutter speed, nor is there any ability to change the aperture size. (Though both these values are displayed on the screen as you take a picture I wonder why? As you can't change anything you can't use the information in any useful fashion, and presumably a non-camera-person wouldn't understand what these numbers represent.) The lack of these two controls is a little galling, but pretty common for the low-end P&S cameras.

Video Recording

There is no external MIC so sounds aren't great, but they're not horrible either. Video recordings are limited to the smaller of 8 minutes or 2Gb. So no long films, but short ones look fine. Just be aware that once you start recording focus won't change, nor will zooming work. Compared to the canon the quality is improved; but the Canon allowed you to (optically) zoom whilst recording. Here you can only zoom with your feet.

Recharging Time

When I received the camera it took about an hour to charge. The battery life seems reasonable - the level is 2/3 a week later and I've been shooting, reviewing, and deleting regularly. (Note: I never use USB to transfer pictures, I always remove the card and plug it into my PC. Whether this makes a difference to battery life I don't know.)

Controls

Physical controls are reasonable. There is a mechanical slide-switch to turn on/off. I like that, as it is less prone to being knocked by keys, change, etc. There is also a physical slide-switch to change from "shoot" to "review current images/videos". (Same as my Canon) I think this is a mistake, and don't see why it can't be a soft-button.

Full Auto

There are several modes available in the camera (remember the caveat about lack of aperture/shutter speed) I've been using both full-auto and manual modes, and both are good. Full auto would suit most people - it has clever face-tracking.

Focusing Speed

As expected this is not stellar. Walking to the corner shop the other lunchtime I found a cat in the road, I talked to her and she rubbed herself against my ankles. Could I focus fast enough to catch her looking up at me? No. For static scenes, and candid shots of people it'll suffice. For fast action and moving children probably not a chance.

On balance, the upgrade was worthwhile. ObQuote: "I don't mean to lecture and I don't mean to preach. And I know I'm not your father..." - Spider-Man

I've just finished reading "Flow My Tears, the Policeman Said" by Philip K Dick, one of 13 novels collected in the Library of America's wonderful "The Philip K. Dick Collection" boxed set. This story has never jumped out at me as one to read with any particular urgency, despite the title being a reference to a composition by my namesake. I was reminded about it whilst listening to one of BBC Radio 4's "Great Lives" broadcasts, where Michael Sheen read a passage from the book. As an aside, the "Great Lives" series is a really interesting listen: I particularly enjoyed their episode on Ludwig Wittgenstein. You can get the whole series in podcast form. Back to the book. It features Dick's trademark theme of fractured realities, perhaps more so than in many of his more well-known works such as Ubik or A Scanner Darkly. It also has much better characterisation than I expect from his writing. His female characters remain as always sinister, threatening, mischevious, but they are at least fleshed out. There is a lot more of an exploration of the human condition than usual. Dick wrote that the novel begun as an attempt to explore different varieties of love. I enjoyed the mystery of the weird goings-on whilst they were mysterious, but I felt mildly let down when the explanation was eventually proffered.

Debian is finally transitioning from the unmaintained and Debian-specific font manager called defoma. The replacement is called fontconfig and it is maintained upstream and in Debian (by upstream) and is cross-distribution with wide support from our upstreams and other distributions. With the upload of libwmf 0.2.8.4-9 (thanks Lo c!) the last package in Debian sid declaring a strict dependency on defoma has removed this dependency. There is still more to do, some more bugs to file and some lenny->squeeze->wheezy upgrade testing to do. Thanks go to Christian PERRIER for slogging through and providing encouragement, bug reports and NMUs. The transition is unfortunately not without loss of functionality;

• Xorg does not yet support fontconfig so for now programs relying on server-side fonts will only be able to use the xfonts- packages shipping their fonts in the directories known by the X server. According to Keith Packard it isn't easy to add fontconfig support to Xorg, there are some ways to paper over this though. We could use the Xorg server's font catalogue system to link to a fontconfig provided symlink farm (similar to what is done with defoma & Xorg). We could adjust the Xorg fonts utils to recurse into subdirectories. As far as I can tell, other distributions have completely ignored this issue and not all fonts are available to the Xorg server there.
• There are some issues with Ghostscript and CJK that I do not fully understand, I am hoping these can be resolved before the release of wheezy. We need people to restart work on this issue.

TeX uses a different directory for fonts to the rest of the system. Fonts used by TeX cannot be used by the rest of the system and vice versa. This issue has always existed in Debian and other distributions and is unrelated to the removal of defoma. If your software doesn't use one of the text renderers (such as Pango, Qt or QuesoGLC) that find fonts on their own and fall back on other fonts where needed (due to missing fonts or glyphs), please switch text rendering systems. If you are unable to switch, please use fontconfig to search for font filenames rather than hard-coding them at build time. This message brought to you by the Debian Fonts Task Force. We welcome people who want to help us maintain font packages or improve support and quality assurance for fonts and font related software.

Part of our work to make it possible to use UEFI Secure Boot on Linux has been to improve our EFI variable support code. Right now this has a hardcoded assumption that variables are 1024 bytes or smaller, which was true in pre-1.0 versions of the EFI spec. Modern implementations allow the maximum variable size to be determined by the hardware, and with implementations using large key sizes and hashes 1024 bytes isn't really going to cut it. My first attempt at this was a little ugly but also fell foul of the fact that sysfs only allows writes of up to the size of a page - so 4KB on most of the platforms we're caring about. So I've now reimplemented it as a filesystem[1], which is trickier but avoids this problem nicely.

Things were almost working fine - I could read variables of arbitrary sizes, and I could write to existing variables. I was just finishing hooking up new variable creation, but in the process accidentally set the contents of the Boot0002 variable to 0xffffffff 0xffffffff 0x00000000. Boot* variables provide the UEFI firmware with the different configured boot devices on the system - they can point either at a raw device or at a bootloader on a device, and they can do so using various different namespaces. They have a defined format, as documented in chapter 9 of the UEFI spec. At boot time the boot manager reads the variables and attempts to boot from them in a configured order as found in the BootOrder variable.

Now, obviously, 0xffffffff 0x00000000 is unlikely to conform to the specification. And when I rebooted the machine, it gave me a flashing cursor and did nothing. Fair enough - I should be able to choose another boot path from the boot manager. Except the boot manager behaves identically, and I get a flashing cursor and nothing else.

I reported this to the EDK2 development list, and Andrew Fish (who invented EFI back in the 90s) pointed me at the code that's probably responsible. It's in the BDS (Boot Device Selection) library that's part of the UEFI reference implementation from Intel, and you can find it here. The relevant function is BdsLibVariableToOption, which is as follows (with irrelevant bits elided):

BdsLibVariableToOption (
  IN OUT LIST_ENTRY                   *BdsCommonOptionList,
  IN  CHAR16                          *VariableName
  )
 
  UINT16                    FilePathSize;
  UINT8                     *Variable;
  UINT8                     *TempPtr;
  UINTN                     VariableSize;
  VOID                      *LoadOptions;
  UINT32                    LoadOptionsSize;
  CHAR16                    *Description;
  //
  // Read the variable. We will never free this data.
  //
  Variable = BdsLibGetVariableAndSize (
              VariableName,
              &gEfiGlobalVariableGuid,
              &VariableSize
              );
  if (Variable == NULL)  
    return NULL;
   

So so far so good - we read the variable from flash and put it in Variable, Variable is now 0xffffffff 0xffffffff 0x00000000. If it hadn't existed we'd have skipped over and continued. VariableSize is 12.

  //
  // Get the option attribute
  //
  TempPtr   =  Variable;
  Attribute =  *(UINT32 *) Variable;
  TempPtr   += sizeof (UINT32);

Attribute is now 0xffffffff and TempPtr points to Variable + 4.

  //
  // Get the option's device path size
  //
  FilePathSize =  *(UINT16 *) TempPtr;
  TempPtr      += sizeof (UINT16);

FilePathSize is 0xffff, TempPtr points to Variable + 6.

  //
  // Get the option's description string size
  //
  TempPtr     += StrSize ((CHAR16 *) TempPtr);

TempPtr points to 0xffff 0x0000, so StrSize (which is basically strlen) will be 4. TempPtr now points to Variable + 10.

  //
  // Get the option's device path
  //
  DevicePath =  (EFI_DEVICE_PATH_PROTOCOL *) TempPtr;
  TempPtr    += FilePathSize;

TempPtr now points to Variable + 65545 (FilePathSize is 0xffff).

  LoadOptions     = TempPtr;
  LoadOptionsSize = (UINT32) (VariableSize - (UINTN) (TempPtr - Variable));

LoadOptionsSize is now 12 - (Variable + 65545 - Variable), or 12 - 65545, or -65533. But it's cast to an unsigned 32 bit integer, so it's actually 4294901763.

  Option->LoadOptions = AllocateZeroPool (LoadOptionsSize);
  ASSERT(Option->LoadOptions != NULL);

We attempt to allocate just under 4GB of RAM. This probably fails - if it does the boot manager exits. This probably means game over. But if it somehow succeeds:

CopyMem (Option->LoadOptions, LoadOptions, LoadOptionsSize);

we then proceed to read almost 4GB of content from uninitialised addresses, and since Variable was probably allocated below 4GB that almost certainly includes all of your PCI space (which is typically still below 4GB) and bits of your hardware probably generate very unhappy signals on the bus and you lose anyway.

So now I have a machine that won't boot, and the clear CMOS jumper doesn't clear the flash contents so I have no idea how to recover from it. And because this code is present in the Intel reference implementation, doing the same thing on most other UEFI machines would probably have the same outcome. Thankfully, it's not something people are likely to do by accident - using any of the standard interfaces will always generate a valid entry, so you could only trigger this when modifying variables by hand. But now I need to set up another test machine.

[1] All code in Linux will evolve until the point where it's implemented as a filesystem.

comments

For my lab work, I have developed an (almost) cross-platform program based on Qt4 that help us analyze our data. One of the motivations to use Qt was the ability to port the program to other platforms, and in particular MacOSX (half of my team uses them). After installing the required development tools using MacPorts (mind you, the MacOS version of the development tools, not the X11 one), I was able to compile and run the program without a single code change on my bosses' Mac. But here come problems: several things do not work the same way in Mac and in Linux (whereas it should, I think), so additional tweaking and debugging will be necessary.This is where the problem comes in: I don't own a Mac and don't intend to, so I need to connect to my bosses' Mac in order to perform testing. How can I connect to a Mac display ? X11 connection won't work, since my application is a Mac application and not a X11 one. I had him turn on screen sharing (the most basic tick box), which sets up a VNC server on the Mac. Unfortunately, when I connect using the command-line VNC clients available for debian, ie vncviewer (from the packages xvnc4viewer or xtightvncviewer), I get the following problems:

~ vncviewer chrismac
VNC Viewer Free Edition 4.1.1 for X - built Mar 10 2010 22:31:05
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Wed Dec  7 10:40:41 2011
 CConn:       connected to host chrismac port 5900
 CConnection: Server supports RFB protocol version 3.889
 CConnection: Using RFB protocol version 3.8
 CConnection: No matching security types
 main:        No matching security types

The good news is that remmina is able to connect graphically, although for me it required that I set the display depth to 24 bits (else it seems to connect, but the connection dies immediately). Great, I'll be able to debug, then...
Edit: after a while, I found out that remmina had some drawbacks when connecting to a Mac, such as, at least in my case, a weird problem with Shift: once I hit Shift, I'm never able again to type in lowercase characters, which is quite painful. I tried also Vinagre, who handled that better (but had some quite painful freezing moment), so I must say that I finally found a client I'm happy with: gtkvncviewer.

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	1614
Affecting Wheezy:	945
Wheezy only:	148
Remaining to be fixed in Wheezy:	797

Of these 797 bugs, the following tags are set:

Pending in Wheezy:	47
Patched in Wheezy:	135
Duplicates in Wheezy:	45
Can be fixed in a security Update:	28
Contrib or non-free in Wheezy:	10
Claimed in Wheezy:	0
Delayed in Wheezy:	6
Otherwise fixed in Wheezy:	50

Ignoring all the above (multiple tags possible) 532 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 845 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

One of Django applications I maintain is our internal tool used at SUSE used for managing incoming L3 requests. Recently request to add some API arose (read only for now). Looking at available solutions, I came to conclusion that django-piston should be the best choice for me. Adding simple model based API with it is indeed quite simple, all basic information you need is written in getting started part of their documentation. On the other side, things can never go without problems, so I was hit by well known bug. Fortunately fix exists, though it is not yet merged upstream. While digging so deep into problem anyway, I've submitted a request to include this patch in devel:languages:python OBS repo.

Filed under: Django English Suse 4 comments Flattr this!

procps-ng version 3.3.2 was released today. This version fixes some bugs introduced in version 3.3.1 as well as a number of enhancements. Below is the most significant set of changes that 3.3.2 brings. NLS The most visible change is that procps-ng is now international. The NLS changes took a long windy path but we got there in the end. This means all procps-ng programs can now use standard gettext PO files to output in any supported language. While the programs have been enabled for translations, there are no po files as yet but we expect them to follow soon. Library Changes procps always had a closed library, meaning that it wasn t supposed to be used for other non-procps programs. This meant the library was always called libprocps-(version) rather than using a SONAME. Procps 3.3.2 now uses a SONAME of version 0.0.0 The API hasn t changed but it will be in subsequent versions. Patch Backporting Due to the stagnant natute of procps development in the past, there have been a large number of patches each distribution carries for procps. A significant number of patches have been incorportated into procps-ng, giving a more consistent look across the distributions and meaning any subsquent fixes or enhancements are done in one place. A major goal of procps-ng was to reduce the number of distribution specific patches which this change has helped greatly. debian Packages The Debian packages will be worked on soon and will clear up some confusion about the procps binaries and library packages as this will now be split into two. It also means that some programs that depend on libprocps will break, but going on from this point will be able to use the normal shlibs process to manage that, rather than the ugly crunch we will have now.