In this report from LSM 2012 in Geneva I will report about

1. Medical imaging using Debian
2. Debian Med packaging workshop
3. Integration of VistA into Debian
4. Other interesting talks

Medical imaging using Debian There were about 10 attendees basically upstream developers of medical imaging software. The talk got some attention and the message to include even more medical imaging software into Debian was well percived. Thanks to Mathieu Malaterre there was some live demonstration which was way easier for him as a medical imaging expert than it would have been for me.
Debian Med packaging workshop Due to my advertising in the talk yesterday three students (two of them from one medical imaging project, one from an other project) attended the workshop. Thanks to Axel Beckert who helped me out surviving the challenge to walk on unexplored ground.

The idea of the workshop was to ask the attendees to name a package of their own and just package this. Because two of the attendees were upstream developers of CreaTools we decided to go on for packaging this. After circumeventing some pitfalls in the beginning it went rather smoothly and after about 2.5 hours we were able to commit some initial packaging to the Debian Med Git repository which comes quite close to a ready package (perhaps some split into a library and a development package needs to be done and for sure testing is needed).
Quoting Frederic Cervenansky, upstream of CreaTools

Thanks for your work. Your workshop was very interesting and didactic: a relevant discussion between Claire and me for the future of Creatools has emerged from the difficulties you encountered to package creatools. I will try, before the end of the month, to fully package creatools. And for sure, I will contact the debian-med mailing list.

Integration of VistA into Debian I had the good chance to directly address some issues of Claudio Zaugg the speaker in the talk Implementing open source Health Information Systems in Low- and Middle Income Countries a practical review directly before mine. It turned out that by using Debian packaged software might help simplifying the issues they had in supporting health care workers in Low- and Middle Income Countries.
My talk was partly repeating some basic ideas about Debian Med from the talk on Monday because the audience was completely different. Than I tried to explain in detail how we tried hard to establish good contacts to upstream developers and why this is essential to finalise the goal to include hospital information systems straight into Debian any by doing so open the doors of hospitals for large scale Debian installations.
There is also video recording of this talk. Other interesting talks OpenEMR, a multi-language free open source electronic health record for international use Just discussed the packaging of OpenEMR which is prepared for Debian Med as it can be seen on our tasks page. The contact to the creator of some inofficial package will be established to finalise this task.
OpenFovea : when open-source and biophysical research get married Just another target for Debian Med popped up in this talk to further enhance Debian Med in covering all issues of medical care on one hand and on the other hand helping upstream authors to distribute their code
more effectively.
Collaborative software development for nanoscale physics The talk would have fit very nicely into the Debian Science workshop at ESRF (European Synchrotron Radiation Facility) in Grenoble because it was about ETRF (European Theoretical Radiation Facility). At previous LSM events I had just talked with Yann and the work to include their software into Debian is on its way.
Free software and High Performance Computing This talk was not directly connected to my Debian work but I simply enjoyed to see how "two people" had a really entertaining talk about Top 500 computers. Vittoria, you made my last day at LSM.

Paolo Bonzini noticed something a little awkward in the Linux kernel support code for Microsoft's HyperV virtualisation environment - specifically, that the magic constant passed through to the hypervisor was "0xB16B00B5", or, in English, "BIG BOOBS". It turns out that this isn't an exception - when the code was originally submitted it also contained "0x0B00B135". That one got removed when the Xen support code was ripped out.

At the most basic level it's just straightforward childish humour, and the use of vaguely-English strings in magic hex constants is hardly uncommon. But it's also specifically male childish humour. Puerile sniggering at breasts contributes to the continuing impression that software development is a boys club where girls aren't welcome. It's especially irritating in this case because Azure may depend on this constant, so changing it will break things.

So, full marks, Microsoft. You've managed to make the kernel more offensive to half the population and you've made it awkward for us to rectify it.

comments

Android vs iPad I m currently in discussions with a client about a potential future project which involves a tablet computer talking to some electronic equipment. The options are an Android tablet and an iPad. One advantage of Android is that it runs on devices of all shapes and sizes, so we can choose a device that fits the need rather than designing everything around the iPad. But the real problem with iPad is Apple. To run an app on an iPad you need to submit it to Apple, hopefully get it accepted into the App Market, then install it. This process causes some delay, a minor fee, and has the potential to derail the project if Apple doesn t accept the app on the first try. With Android there is no need to even deal with Google, the app can be installed directly without the Google Play store. I may end up working with an iPad (which admittedly is really nice hardware), but it seems most likely that the project in question will run on Android only. Windows vs Linux and Apple OS/X One of my clients recently paid a web development company to redevelop his web site. I turned out that the web developers in question only knew how to develop for Windows and my client didn t discover this until too late. Now a site that s currently using a small fraction of the resources on a $80 per month Linode instance will run on a Windows virtual server costing $300 per month (which includes SQL server license). The Windows virtual server will probably be managed (because my client uses only Apple and Linux systems and doesn t employ anyone with Windows skills) which adds an extra $100 per month. If the server isn t managed then they will have to hire someone to apply patches and that won t necessarily be cheaper. So using Windows is going to cost my client an extra $400 per month when compared to the possibility of running a Linux system on the existing virtual server. Even if my client had someone with Windows skills to run the server it would still be an extra $300 per month. If the NBN was available then my client could run a Windows server in their office, but it s not yet available in their area. Even for a company that employs people with more Windows skills than Linux skills there are still economic factors in favor of Linux due to smaller hardware requirements and the lack of license fees for all the core software (OS, database server, web server, etc). Summary These anecdotes aren t unusual, it s the sort of thing that happens all the time. Sometimes the result is good (EG avoiding the iPad), sometimes it isn t (being stuck with a proprietary web service). I think I ll have to suggest to my clients that every contract have a no proprietary software clause. Contracts can be amended if there is a reason, but it seems best to make a preemptive strike against companies that sneak proprietary software in and cause significant unexpected expense and difficulty. Related posts:

1. The Lenovo U1 Hybrid an example of how Proprietary OSs Suck Lenovo have announced their innovative new U1 Hybrid laptop [1]....
2. My Prediction for the iPhone I have previously written about how I refused an offer...
3. Liberty and Mobile Phones I own two mobile phones at the moment, I use...

Continuing in my better running through technology phase that I'm currently going through, I got all excited when I discovered that Polar make a Bluetooth-enabled heart rate monitor chest strap. Prior to this, I'd be lamenting how there wasn't a large choice of ANT+ enabled Android phones (to my knowledge there's just something Sony makes) So I got all excited and ordered a strap and it arrived today. This is my initial review (I haven't gone running with it yet, I've just had a tinker) I'll start with the bad first

the battery cover is a bit dicky

I took the battery cover off to confirm it came with a battery and then had a whale of a time getting it back on. I haven't managed to get it on as flush with the back as before I took it off. This appears to be a common complaint in the Amazon product reviews also.

hard to tell what its auto off timeout is, whether it's on, etc

Basically there's a large lack of feedback as to what's going on. Is it on or off? Is it wet enough to turn itself on? Is it reading a heart rate, or is the Bluetooth pairing just not working? The most accurate way I've found to determine if it's "working" or not is to unpair it and then repair it again. If you get a PIN prompt it's talking. By accident, I've found indications that it will turn itself off after not reading a heart rate for 10 minutes, and to reset it, you detach it and wait 30 seconds and reattach it. This would have been good information to include in the manual

Now for the good

reasonable Android app support

Heart Rate Monitor for Polar claims to support it, but I haven't managed to get it to do anything useful yet. I was pleasantly surprised to discover that My Tracks has support for it. Noom CardioTrainer is one that I was already trying out alongside Strava Run (which doesn't have support for it). There's also Sports Tracker and Endomondo. The UI for both of these also show the battery level. I've found that trying to have multiple apps reading the heart rate monitor simultaneously seems to be an exercise in fail, and that the Sports Tracker app seems to start a background service which subsequently causes all sorts of problems for any of the other apps started after it has started.

And the ugly Looking back at all the Amazon product reviews, they're pretty much split equally between 5 stars and 1 stars. The product seems to either work flawlessly or absolutely dreadfully. I was beginning to think I was in the latter group and that I'd bought a white elephant, but now that I've gotten to the bottom of the idiosyncrasies of talking to it from Android, it seems to be behaving fairly reliably. Talking to it from Linux, and the reason behind the title of this post One of the first things I tried doing after Android was being initially flaky for me, was to try and talk to it from a Linux laptop. This proved fairly straightforward using rfcomm. I didn't get anything human readable out of it though. Being curious as to how these Android apps were able to decode the data, I went looking for some API documentation, and a Google search led me to this sad forum discussion. So the API information is not freely available, and their CEO personally signs off on who gets access to it. How ludicrous. Do they want to sell product or not? That said, I did also find this blog post which, courtesy of the aforementioned Open Source My Tracks Android app, lays it all out for you. So them being all anti-development with their information is kind of pointless. Polar's website doesn't mention anything about their management, so I have no idea who their CEO even is. Wikipedia is also none the wiser. I'm looking forward to going for a run tomorrow and seeing how this thing pans out.

Even though I've planned to do this on Monday, it somehow slipped to Wednesday, but I've finally filled in GSoC 2012 evaluations for all students I mentor at phpMyAdmin. Generally all of them perform quite well, but there is always room for improvements :-). The greatest pain every year is filling up evaluations for more students - every each of them starts with same questions for mentor (eg. how many GSoC did you participate in or how much time you spend on GSoC). I know I can copy and paste answers, but still this looks like something not necessary. Also some information is probably already known to Google (eg. in which years I did participate in GSoC).

Filed under: English Phpmyadmin 0 comments Flattr this!

I have this bunch of Dell R610, with iDrac6 Express management cards. I used these, among other things, for developing IPMI support in NUT and working on Infrastructure & Cloud power management. But that's the topic of another post (still, if you're interested in, check this and that). The thing is that this "IPMI" monitoring development has been limited to local support (Ie, power supplies can't be monitored remotely by the nut-ipmipsu driver), due to an issue : any attempt to enable IPMI access over the network was miserably failing! Well, these attempts were limited to a couple of 15 minutes runs, without plain motivation, almost a year ago. The various firmwares were up to date (iDrac 1.70, ...) , everything was running and configured fine, locally. But still... no IPMI available through the network! Looking on the Net, I've learned that many Dell customers with iDrac Express cards, were having the same issue. Dell support seems to have replaced tons of motherboards! There, I switched to other things, and time has passed.... A good year later (last week), I decided that it was time to get back on this. And I've found the solution there Incredible: this was due to a 'bug' in the Broadcom NetXtreme II LoM (LAN on Motherboad) firmware! I've not had time to dig this issue in depth, but here is a base explanation, for what it's worth: Some LoM initial self tests are failing. Thus, the LoM are not switched to the managed mode, and can't actually be available for BMC management (thus no IPMI over the network). In my case, the tests were wrongly failing at 'A07', a test which tries to establish a Gigabit connection! Strangely, all these servers are connected on a Gb switch! Not a fully satisfactory answer, but that said, there is a solution, and I've not much time to pour into this investigation (comments may always change my mind though!). So here is a comprehensive procedure to fix this, from your Linux system, and using FreeDOS:

• Get a USB key, at least 1,44 Mb (damn!), but a good old 32Gb will also do the trick
• Open a terminal and format the USB key (WARNING: this will ERASE all data on the key! You've been warned. Really!)

$ mkfs.msdos /dev/sdX1

Note: 'X' is to be replaced by the exact name of your USB key. An hint: call 'tail -f /var/log/syslog" and unplug / replug your USB key. You will see some entries like "...sdb Attached SCSI removable disk". So, there, it's "sdb".

• Download a FreeDOS image
• Now use qemu to create the DOS boot disk on your USB key (replace 'X' again!):

$ qemu -boot a -fda balder10.img -hda /dev/sdX A:\> sys c: A:\> xcopy /E /N a: c:

Note that you will need "root" privileges.

• (Optional) You can check the bootability with:

$ qemu -hda /dev/sdX

• Download Broadcom DOS utilities there
• Unzip this archive (self extract)

$ unzip Bcom_LAN_14.2.x_DOSUtilities_A03.exe

• Copy only 'Userdiag/NetXtremeII/uxdiag.exe' to your USB key.
• Plug the key in your server, and reboot it
• Press F11 to enter the BIOS boot sequence,
• Select the default entry, and press Enter. Once the system is booted, type:

c:\ uxdiag -t abcd mfw 1

• Reboot your system, and enjoy your *working* IPMI access over the network

For what it's worth (again), I just hope that it will be useful to others... I will now prepare another post using using FreeIPMI to manage your servers, the GNU way... cheers,
-- Arno Thanks to Jordi Clariana, his enlightening post, Daniel for this one, Aur lien was motivating me again in solving this iDrac Express issue and Al Chu (FreeIPMI project leader) for all his invaluable help on IPMI.

Hey fellows Debian lovers, and old friends reading this, after more than a decade serving Debian, our greatest and beloved OS, I've finally decided to start blogging. Please, bear with me, I'm still very new at blogging. Thus, constructive comments and mails are welcome So here we actually go with the usual 'quick introduction post': I'm Arnaud Quette, 36 years old, and Debian developer since 2001. I'm leading the upstream project called 'NUT' (Network UPS Tools project) since 2005, and I'm a Free Software hacker since 1997 (incomplete list of contribs and linkedIn profile). I'm working at Eaton, a Debian partner participating in the power protection of our Debian infrastructure (FTP masters and Alioth). If you're a Debian admin, and feel Eaton can help, drop me a mail. My main Opensource contribution, for some years, is to lead 'NUT', and the related power management developments and distribution. As such, I also ensure that all this work lands finely in Debian, and is useful and reliable to users. In the past, I've also been working on some Media Center packages (Coherence UPnP, moovida, LIRC, ...), Synaptics touchpads app and some more. Here is the current list of maintained and co-maintained packages, though not up to date. It's not always that easy to balance between upstream lead and the numerous developments on one hand, and Debian packaging and support on the other hand... Not counting real life and the many others responsibilities I have. Just forgive me for the time it has taken (and is still taking, sometimes) to update my various packages. Just remember that I'm always doing my best So dear Planet Debian readers, I'll be bothering you with some news on power management and GreenIT in Debian. There will be both upstream and Debian developments and releases info, so that you all can react. There may probably be some diversion, on other Debian related topics, one way or another... All this will depend on your feedback, and the balance with my available time and pleasure to share with you these few tech bits. cheers,
Arnaud

Thanks to the awesome work of a lot of people (some not even here), this time we did the setup in one day less then previous years, and IMHO it was mostly rather very relaxed and efficient as well!
As you probably will know already, the streams are linked on the DebConf12 webpage and the recordings will be linked there, too, when they are ready. The scheduled release for that is tomorrow evening localtime, we ll see if we can deliver :-)
To make this happen, there will be a video training session tomorrow morning at 11:00 in talkroom 2, Roberto Ter n. The training will cover both the live session setup and the reviewing workflow and is definitly still open for new members!
So once again (one cannot say it enough, so please express your thanks as well) muchisimas gracias to all members of the dc12 videoteam! As Biella once said, you re ninjas!
Last and definitly not least, many thanks to our equipment sponsors too (HP, IRILL, Debian and individuals)!
cheers, a very happy h01ger!

I ve just broken my second SATA connector. This isn t a lot considering the number of hard drives I ve worked with, but it s still really annoying as I generally don t break things. The problem is that unplugging a SATA cable requires pushing a little clip, this isn t overly difficult but it unfortunately doesn t fit well with habits formed from previous hardware. The power cables used for hard drives based on the ST-506 interface which was copied for the IDE interface was large and had a fairly tight fit. Removing such a cable requires a significant amount of force which is about the same as the amount of force required to break a SATA connector. When I first started using PCs a reasonably configured AT system cost over $5,000 (maybe something like $10,000 in today s money). With that sort of price hardly anyone had a set of test PCs. When hardware prices dropped such that hard drives of reasonable size became reasonably affordable on the second-hand market I bought more disks and used some for extra storage and some for testing software. As there was nothing like VMWare for testing OS images the way to test a new OS was to plug in a different hard drive and boot it. So I got a lot of practice at removing IDE power cables with as much force as was necessary. Now I own a pile of test PCs, SATA disks less than 100G are free, I use Xen for a lot of my testing, and generally I have much less need to swap hard drives around. In most situations in which I would swap hard drives in the 90 s I will now swap PCs and I have piles of PCs ready for this purpose. So I haven t had enough practice with SATA disks to develop habits for safely removing them. So far this lack of habit development has resulted in damaging two disks due to changing drives while not concentrating enough. Fortunately duct-tape works well for holding a SATA connector in place when the plastic that attaches to the clip is broken. Related posts:

1. Strange SATA Disk Performance Below is a GNUPlot graph of ZCAV output from a...
2. Vibration and Strange SATA Performance Almost two years ago I blogged about a strange performance...
3. Dell PowerEdge T105 Today I received a Dell PowerEDGE T105 for use by...

It's been a week with quite some changes to http.debian.net, the Debian mirrors redirector, and it keeps coping very well with the continuously increasing traffic: over 1.5 million requests from APT clients in the last seven days! half-million more from the week before.

The good news is, those rare Hash Sum mismatch errors should be mostly gone. Ditto for some other sort of errors. There is now a second server that takes care of monitoring the mirrors and is ready to handle some of the traffic if there's any need. With this new server, http.debian.net will soon be available over IPv6 too.

Those who are at Debconf12 and followed my advice to use http.debian.net will have noticed that it is redirecting users to the local mirror. So, once again, forget about switching mirrors!

Thanks are also due to J rg Jaspert and Philipp Kern, for the new server and for the work needed to allow http.debian.net access to Debconf12's local mirror, respectively.

Many thanks again to those who keep providing feedback and have helped the project along the way.

What's next? even more improvements and fixing some issues, some of which involve further collaboration and cooperation with the mirror administrators.

Some parts of the Debian mirrors network are fragile and may bite every once in a while, but those are being worked on. If you administer a mirror, please use ftpsync and submit your Debian mirror.
You might be happy to know that I'm working on restricting mirrors to specific Autonomous System, or countries. More on this later.

Forward Error Correction with the TI CC1120 Sub-GHz transceiver We re building a new, fancier flight computer and decided to give the new, fancier TI CC1120 chip a try. It has significantly more transmit power (+16dBm) and receive sensitivity (-109dBm) than the transciever built in to the TI CC1111 RF SoC that we ve built our other boards with. Given that we d already decided to use a fancier STM32L processor, using the nicest stand-alone radio chip we could find seemed to make good sense. One of the nice features found in the CC1111 is support for FEC using a 1/2 rate constraint length 4 convolutional code. Both the encoder and the soft-decision Viterbi decoder are built right into the chip; all we had to do was flip a couple of bits and we got error correction, interleaving, data whitening and CRC checking all for free. We assumed that, as the CC1120 was advertised as a better replacement for our CC1111 radio, that it would also include all of these fine features. After we got the chip all soldered down to our first prototype boards, we read through the reference manual looking for the right register values to flip for forward error correction. We found support for CRC computation and data whitening, but no mention of interleaving or forward error correction at all. Thanks, TI. Of course, without the FEC pieces, the other packet handling hardware is worthless you can t exactly do a CRC on the encoded data and expect it to be useful on the other end of the link, and data whitening happens after the CRC. Basic CC1120 driver I assumed I d eventually figure out something to do about the FEC pieces and started writing a basic CC1120 driver AltOS, the operating system used in all of our projects. I started with the transmit side, as that seemed easier as I could use the existing packet hardware by uploading the desired bit sequence using whatever fancy encoding desired and the hardware would happily transmit it. I first tested that using low data-rate bits (2kbps), transmitting an alternating sequence of zeros and ones to generate a 1kHz tone on a regular 70cm receiver. That seemed to work just fine, demonstrating that I had some grasp of the basic operation of the chip. Convolutional Encoding in Software Not to be daunted by a small challenge in software, I set out to replicate the encoding scheme used in the CC1111 chips for use in our CC1120-based design. We obviously want our CC1120 boards to interoperate with the CC1111 boards. Fortunately, TI fully documents the CRC, data whitening, convolutional encoding and interleaving done in the hardware. I created my own implementation of the encoder (licensed, as usual, under the GPLv2) which you can see in the file ao_fec_tx.c It s not quite as flexible as the hardware, it always whitens the data and always appends the CRC bytes to the end of the packet, along with the necessary trellis termination bytes. The core of that code is surprisingly simple:

static const uint8_t ao_fec_encode_table[16] =  
/* next 0  1      state */
    0, 3,   /* 000 */
    1, 2,   /* 001 */
    3, 0,   /* 010 */
    2, 1,   /* 011 */
    3, 0,   /* 100 */
    2, 1,   /* 101 */
    0, 3,   /* 110 */
    1, 2    /* 111 */
 ;
uint8_t
ao_fec_encode(const uint8_t *in, uint8_t len, uint8_t *out)
 
    uint8_t     extra[AO_FEC_PREPARE_EXTRA];
    uint8_t     extra_len;
    uint32_t    encode, interleave;
    uint8_t     pair, byte, bit;
    uint16_t    fec = 0;
    const uint8_t   *whiten = ao_fec_whiten_table;
    extra_len = ao_fec_prepare(in, len, extra);
    for (pair = 0; pair < len + extra_len; pair += 2)  
        encode = 0;
        for (byte = 0; byte < 2; byte++)  
            if (pair + byte == len)
                in = extra;
            fec  = *in++ ^ *whiten++;
            for (bit = 0; bit < 8; bit++)  
                encode = encode << 2   ao_fec_encode_table[fec >> 7];
                fec = (fec << 1) & 0x7ff;
             
         
        interleave = 0;
        for (bit = 0; bit < 4 * 4; bit++)  
            uint8_t byte_shift = (bit & 0x3) << 3;
            uint8_t bit_shift = (bit & 0xc) >> 1;
            interleave = (interleave << 2)   ((encode >> (byte_shift + bit_shift)) & 0x3);
         
        *out++ = interleave >> 24;
        *out++ = interleave >> 16;
        *out++ = interleave >> 8;
        *out++ = interleave >> 0;
     
    return (len + extra_len) * 2;
 

ao_fec_encode_table takes care of the convolutional piece, ao_fec_whiten_table (not shown) contains the data whitening codes while the little loop at the bottom does the interleaving. I didn t spend a lot of time optimizing this as it seemed to run plenty fast on the 32MHz processor. With the bits all nicely encoded, I passed them to my simple CC1120 driver and let it send them along to our CC1111 receiver. Much to my delight, with only a few bugs fixed, it worked just fine! I d managed to get one direction working, validating the hardware and making it clear that we d at least be able to use the board in flight for telemetry. Getting Soft-decision data out of the CC1120 In packet mode, the CC1120 receiver converts the incoming GFSK stream directly into bits, making its best guess as to whether the detected value was a one or zero. Of course, like any FM modulation, the receiver will be producing intermediate values, especially when the signal is weak or masked by interference. A Viterbi decoder can make good use of this information;these noisy intermediate values are less influential in the final resulting path cost which allows the strong 0/1 values to pull the solution to the right one. Soft decision decoding yields a theoretical 2dB gain over hard decision decoders, and given our desire for maximum packet reception over long distances, it seemed important to make this work. The CC1120 has a way to recover the soft decision values, but only one 8-bit value at a time. It does, however, helpfully provide a GPIO wire which can be programmed to interrupt the CPU when the soft decision data has arrived. So, I hooked up a GPIO line on the processor to the GPIO line on the CC1120 and let it interrupt once per bit time, or 38400 times per second, to read this valuable soft decision data out of the radio part. According to TI support, this is the only way to make this work, and that they generally recommend that developers use the packet mode stuff and throw away this valueable source of data. I was happily surprised to learn that the STM32L can in fact survive this interrupt rate, and by setting interrupt priorities appropriately, I manage to reliably capture an entire packets worth of data without dropping a single bit. I set up a simple packet dumping function to run on the prototype board and captured raw encoded bytes from our CC1111-based flight computer so that I d have some real data to work from. Soft-decision Viterbi Decoding The sample encoding implementation from TI made that piece fairly straightforward. Lacking a similar sample for the decoding piece meant that I d be starting from scratch. And, implementing something that seemed like magic to me when I started. I started by reading a few articles on Viterbi decoding: I found Chip Fleming s tutorial very useful as it included a bunch of worked examples using a convolutional encoders with constraint length (k) of 3 instead of 4; this makes all of the trellis diagrams half the size. I also sent my friend, Phil Karn, a query about this process, and he responded with a bunch of helpful suggestions, while also recommending that I just steal his DSP and FEC library implementation. Of course, I don t like using code that I can t understand, and his code only implements much longer codes than I needed, so I d have to understand it anyways to make it work for me. Phil s code is a marvel, but it s not exactly comprehensible to someone who doesn t even know what a Viterbi decoder is supposed to do. So, with Chip s tutorial on my screen, I wrote a primitive Viterbi decoder. This did only the Viterbi step, and split that into two phases. The first computed the cost for each state in the system for every received pair of symbols received. It also tracked the chain of states through the entire decode process:

    for (state = 0; state < 8; state++)  
        struct ao_soft_sym zero = ao_soft_sym(ao_fec_encode_table[state * 2 + 0]);
        struct ao_soft_sym one = ao_soft_sym(ao_fec_encode_table[state * 2 + 1]);
        uint8_t zero_state = ao_next_state(state, 0);
        uint8_t one_state = ao_next_state(state, 1);
        int zero_cost = ao_cost(s, zero);
        int one_cost = ao_cost(s, one);
        zero_cost += cost[b][state];
        one_cost += cost[b][state];
        if (zero_cost < cost[b+1][zero_state])  
            prev[b+1][zero_state] = state;
            cost[b+1][zero_state] = zero_cost;
         
        if (one_cost < cost[b+1][one_state])  
            prev[b+1][one_state] = state;
            cost[b+1][one_state] = one_cost;
         
     

At the end of the packet, it found the least costly path and walked that from back to front, generating output bits (yes, one bit per element of the bits array):

for (state = 1; state < 8; state++)  
    if (cost[b][state] < c)  
        c = cost[b][state];
        min_state = state;
     
 
for (b = len/2; b > 0; b--)  
    bits[b-1] = min_state & 1;
    min_state = prev[b][min_state];
 

Completely separate from this code were the interleaving and data whitening stages. Keeping those separate allowed them to be tested independently, which made debugging them far easier. None of this code ever ran on the STM32L processor, it was instead run in a test framework on my laptop. I first got this working with data generated by the software convolutional encoder, then I managed to get it to decode the raw packets that I had recorded directly from the receiver it self. This marked a significant milestone in my mind I d managed to replace, in software, the CC1111 FEC encoder and decoder. However, the decoder performance was not fast enough to manage back-to-back packets yet. Having something in hand that worked meant that further development would be directly comparable to something that did work, making optimization much easier. Yet another lesson in making it work, and then making it work fast. Optimizing the Viterbi Decoder The first step was to reduce memory usage within the decoder. While it s best to defer computing the path until the very last bit has been received, it s also true that the chances of a bit affecting old data reduces as the distance between the new and old data increases. With the rule of thumb being a distance of k 6 or k 7, I saved 32 output bits for each state and wrote the oldest of 8 each time the buffer filled up, making a distance of 24 bits between the newest saved data and the current decoding position. That meant a fixed amount of storage was needed for an arbitrarily long packet. I tested a variety of different history sizes from 8 to 56 bits (cooresponding to 16, 32 and 64 bits of saved data for each state). With 100000 random packets generated that had gaussian noise added to each bit, here are the error rates for the different history lengths:

History Length	Total Packets	Correct	Incorrect
8 bits	100000	90520 (90.52%)	9480 (9.48%)
24 bits	100000	93614 (93.61%)	6386 (6.39%)
56 bits	100000	93620 (93.62%)	6380 (6.38%)

The performance of the 8-bit history and 16-bit history versions turned out to be essentially identical (given the 32-bit nature of the STM32L, that shouldn t be too surprising). The performance of the 56-bit version, which manipulated uint64_t data types was sigificantly slower, and given the very modest benefit, deemed not worth it. If we move to a larger constraint length (k > 4), or started using a punctured convolutional encoding, we would want to re-measure this. The next step was to combine the de-interleaving, decoding, de-whitening and CRC computation into a single loop. This would eliminate a pile of data copying and extra memory usage. Nothing fancy here, but it made enough of a difference that I could decode most of the incoming packets now, dropping only about 25% of them. To get to being able to decode every packet, I needed to start decoding the packet while it was being received. Because of interleaving, I had to have 32 bits of data to be able to decode anything, so it was a simple matter of having my per-soft-value interrupt handler start the decoder going after each interleave block of data was received. With this in place, I was able to decode a 76-byte payload (160 transmitted bits) in 14.7 ms, or just about 50% of the time it took to transmit the packet. Unrolling one of the inner decoding loops eliminated a bunch of computation and sped this up even more, decoding packets in 9.5ms. Success at last, a solid 100% of packets received were being decoded, as long as the CPU was otherwise idle. Finally, I went and re-read Phil Karn s code and pondered over how it works. It was opaque until I wrote a message back to Phil asking how it worked and pointing out sections that were confusing. Fortunately, simply phrasing my confusion in words made me understand how the code works. Here s my original code for computing the per-state cost metric:

/* Metric for a zero bit */
uint32_t    bitcost = ((uint32_t) (s0 ^ ao_fec_decode_table[(state<<1)]) +
               (uint32_t) (s1 ^ ao_fec_decode_table[(state<<1)+1]));
 
    /* Total path metric and state for a zero bit */
    uint32_t    cost0 = cost[p][state] + bitcost;
    uint8_t     state0 = ao_next_state(state, 0);
    /* Compare the total path metric against all existing
     * metrics heading into the same new state, choosing
     * the least expensive and killing the others.  Record
     * the new lowest cost and output bit.
     */
    if (cost0 < cost[n][state0])  
        cost[n][state0] = cost0;
        bits[n][state0] = (bits[p][state] << 1)   (state & 1);
     
 
 
    /* Total path metric and state for a one bit.  Because
     * encoding a one is always exactly the opposite of
     * encoding a zero from any state, this cost is
     * 255*2 - bitcost
     */
    uint32_t    cost1 = cost[p][state] + 510 - bitcost;
    uint8_t     state1 = ao_next_state(state, 1);
    if (cost1 < cost[n][state1])  
        cost[n][state1] = cost1;
        bits[n][state1] = (bits[p][state] << 1)   (state & 1);
     
 

Before this loop is run, I have to initialize cost[n] to a large value so that the comparisons will be true for the first case to reach each state. Phil s code, in contrast, doesn t have to initialize cost[n] as we know which two states can reach any possible new state. His code looks like this:

/* Metric for a zero bit */
bitcost = ((uint32_t) (s0 ^ ao_fec_decode_table[(state<<1)]) +
       (uint32_t) (s1 ^ ao_fec_decode_table[(state<<1) 1]));
/* Only state and state+4 reach state<<1 with a zero bit */
/* Cost from state to state<<1 for a zero bit*/
m0 = cost[p][state] + bitcost;
/* Cost from state+4 to state<<1 for a zero bit */
m1 = cost[p][state+4] + (510 - bitcost);
/* Which source state is cheaper? */
bit = m0 > m1;
/* Record the cheaper cost and the add to the path of bits */
cost[n][state<<1] = bit ? m1 : m0;
bits[n][state<<1] = (bits[p][state + (bit<<2)] << 1)   (state&1);
/* State and state+4 reach (state<<1)+1 with a one bit */
/* Cost from state to (state<<1)+1 for a one bit */
m0 -= (bitcost+bitcost-510);
/* Cost from state+4 to (state<<1)+1 for a one bit */
m1 += (bitcost+bitcost-510);
/* Which source state is cheaper? */
bit = m0 > m1;
/* Record cheaper cost and add to the path of bits */
cost[n][(state<<1)+1] = bit ? m1 : m0;
bits[n][(state<<1)+1] = (bits[p][state + (bit<<2)] << 1)   (state&1);

This code does two states at a time, and so while it s slightly longer than the above, it only needs to run half as many times. The resulting code now decodes packets in 5.7ms. The final version of the code can be see in ao_fec_rx.c The whole AltOS operating system, with many drivers and support for CC1111, AVR and STM32L processirs is available, under the GPLv2 from git://git.gag.com/scm/git/fw/altos

I ve spent some more time on Debian Maintainer Dashboard (DMD), a maintainer/team-centric dashboard relying on Ultimate Debian Database. Done:
- added tabs (jquery really rocks) see example
- added a hacking.html file that describes how to setup a development environment
- created a pad (http://debian.titanpad.com/DMD) to store ideas. TODO:
- recruit contributors ;)

It's still good to be at Debcamp before DebConf and I'm not running all day long, contrary to what you might think by reading my posts. Of course, I'm always busy with "social-like" activities such as doing my best for us to have a good Cheese and Wine Party as, now that I'm trapped into it, people expect it to be better and better each year. Or to revive the traditional Assassins game. But Debian is not only about killing cheese with socks and I try to also achieve a few things while being here. As of now, I can already count a few things:

• completing dpkg translation and dpkg manpages translations (I blessed Guillem Jover a lot for being so picky and changing so many details in dpkg messages....and I blessed Rapha l a lot for writing so detailed manpages). To be honest, that part was not achieved during Debcamp but during.....the flight from Paris to Atlanta and partly during the Atlanta-Managua flight. Being upgraded to Premium helped as there are power sockets in seats there..:-)
• completing APT translation and APT manpages translations. Here, a big work had been done by Justin Rye to bring more English in a big pile of Germish and I had to fight hard to check significative changes out of the typo and grammar fixes
• preparing a backport of samba for squeeze. We'll have samba 3.6.6 in wheezy and our squeeze users deserve it also
• go through a few leftovers from the Paris i18n sprint that created i18n.debian.org, such as creating a page for the I18n team.
• discuss (briefly) with David Pr votto have the Debian website l10n pages point to material from i18n.debian.org and no longeri18n.debian.net

The only thing I nearly haven't worked on yet is....the talk I have on Sunday and that is supposed to explain newcomers how to join the crowd of localization fanatics. Oh, and I'm still jetlagged and go to bed daily at 10pm...:-)

For my GSoC project this year I need to be able to enumerate all elementary circuits of a directed graph. My code is written in Ocaml but neither the ocamlgraph library nor graph libraries for other languages seem to implement a well tested algorithm for this task. In lack of such a well tested solution to the problem, I decided to implement a couple of different algorithms. Since it is unlikely that different algorithms yield the same wrong result, I can be certain enough that each individual algorithm is working correctly in case they all agree on a single solution. As a result I wrote a testsuite, containing an unholy mixture of Python, Ocaml, D and Java code which implements algorithms by D. B. Johnson, R. Tarjan, K. A. Hawick and H. A. James.

Algorithm by R. Tarjan The earliest algorithm that I included was published by R. Tarjan in 1973.

Enumeration of the elementary circuits of a directed graph
R. Tarjan, SIAM Journal on Computing, 2 (1973), pp. 211-216
http://dx.doi.org/10.1137/0202017

I implemented the pseudocode given in the paper using Python. The git repository can be found here: https://github.com/josch/cycles_tarjan

Algorithm by D. B. Johnson The algorithm by D. B. Johnson from 1975 improves on Tarjan's algorithm by its complexity.

Finding all the elementary circuits of a directed graph.
D. B. Johnson, SIAM Journal on Computing 4, no. 1, 77-84, 1975.
http://dx.doi.org/10.1137/0204007

In the worst case, Tarjan's algorithm has a time complexity of O(n e(c+1)) whereas Johnson's algorithm supposedly manages to stay in O((n+e)(c+1)) where n is the number of vertices, e is the number of edges and c is the number of cycles in the graph. I found two implementations of Johnson's algorithm. One was done by Frank Meyer and can be downloaded as a zip archive. The other was done by Pietro Abate and the code can be found in a blog entry which also points to a git repository. The implementation by Frank Meyer seemed to work flawlessly. I only had to add code so that a graph could be given via commandline. The git repository of my additions can be found here: https://github.com/josch/cycles_johnson_meyer Pietro Abate implemented an iterative and a functional version of Johnson's algorithm. It turned out that both yielded incorrect results as some cycles were missing from the output. A fixed version can be found in this git repository: https://github.com/josch/cycles_johnson_abate

Algorithm by K. A. Hawick and H. A. James The algorithm by K. A. Hawick and H. A. James from 2008 improves further on Johnson's algorithm and does away with its limitations.

Enumerating Circuits and Loops in Graphs with Self-Arcs and Multiple-Arcs.
Hawick and H.A. James, In Proceedings of FCS. 2008, 14-20
www.massey.ac.nz/~kahawick/cstn/013/cstn-013.pdf

In contrast to Johnson's algorithm, the algorithm by K. A. Hawick and H. A. James is able to handle graphs containing edges that start and end at the same vertex as well as multiple edges connecting the same two vertices. I do not need this functionality but add the code as additional verification. The paper posts extensive code snippets written in the D programming language. A full, working version with all pieces connected together can be found here: https://github.com/josch/cycles_hawick_james The algorithm was verified using example output given in the paper. The project README states how to reproduce it.

Input format All four codebases have been modified to produce executables that take the same commandline arguments which describes the graphs to investigate. The first argument is the number of vertices of the graph. Subsequent arguments are ordered pairs of comma separated vertices that make up the directed edges of the graph. Lets look at the following graph as an example: The DOT source for this graph is:

digraph G  
  0;
  1;
  2;
  0 -> 1;
  0 -> 2;
  1 -> 0;
  2 -> 0;
  2 -> 1;
   

To generate the list of elementary circuits using Tarjan's algorithm for the graph above, use:

$ python cycles.py 3 0,1 0,2 1,0 2,0 2,1
0 1
0 2
0 2 1

The commandline arguments are the exact same for the other three methods and yield the same result in the same order. If the DOT graph is in a format as simple as above, the following sed construct can be used to generate the commandline argument that represents the graph:

$ echo  sed -n -e '/^\s*[0-9]\+;$/p' graph.dot   wc -l   sed -n -e 's/^\s*\([0-9]\) -> \([0-9]\);$/\1,\2/p' graph.dot 

Testsuite As all four codebases take the same input format and have the same output format, it is now trivial to write a testsuite that compares the individual output of each algorithm for the same input and checks for differences. The code of the testsuite is available via this git repository: https://github.com/josch/cycle_test The other four repositories exist as submodules of the testsuite repository.

$ git clone git://github.com/josch/cycle_test.git
$ cd cycle_test
$ git submodule update --init

A testrun is done via calling:

$ ./test.sh 11

The argument to the shell script is an integer denoting the maximum number N of vertices for which graphs will be generated. The script will compile the Ocaml, Java and D sourcecode of the submodules as well as an ocaml script called rand_graph.ml which generates random graphs from v = 1..N vertices where N is given as a commandline argument. For each number of vertices n, e = 1..M number of edges are chosen where M is maximum number of edges given the number of vertices. For every combination of number of vertices v and number of edges e, a graph is randomly generated using Pack.Digraph.Rand.graph from the ocamlgraph library. Each of those generated graphs is checked for cycles and written to a file graph-v-e.dot if the graph contains a cycle. test.sh then loops over all generated dot files. It uses the above sed expression to convert each dot file to a commandline argument for each of the algorithms. The outputs of each algorithm are then compared with each other and only if they do not differ, does the loop continue. Otherwise the script returns with an exit code. The tested algorithms are the Python implementation of Tarjan's algorithm, the iterative and functional Ocaml implementation as well as the Java implementation of Johnson's algorithm and the D implementation of the algorithm by Hawick and James.

Future developments Running the testsuite with a maximum of 12 vertices takes about 33 minutes on a 2.53GHz Core2Duo and produces graphs with as much as 1.1 million cycles. It seems that all five implementations agree on the output for all 504 generated graphs that were used as input. If there should be another implementation of an algorithm that enumerates all elementary circuits of a directed graph, I would like to add it. There are some more papers that I would like to read but I lack access to epubs.siam.org and ieeexplore.ieee.org and would have to buy them. Benchmarks seem a bit pointless as not only the algorithms are very different from each other (and there are many ways to tweak each of them) but also the programming languages differ. Though for the curious kind, it follows the time each algorithm takes to enumerate all cycles for all generated graphs up to 11 vertices.

algorithm	time (s)
Johnson, Abate, Ocaml, iterative	137
Johnson, Abate, Ocaml, functional	139
Tarjan, Python	153
Hawick, D	175
Johnson, Meyer, Java	357

The iterative Ocaml code performs as well as the functional one. In practice, the iterative code should probably be preferred as the functional code is not tail recursive. On the other hand it is also unlikely that cycles ever grow big enough to make a difference in the used stack space. The Python implementation executes surprisingly fast, given that Tarjan's algorithm is supposedly inferior to Johnson's and given that Python is interpreted but the Python implementation is also the most simple one with the least amount of required datastructures. The D code potentially suffers from the bigger datastructures and other bookkeeping that is required to support multi and self arcs. The java code implements a whole graph library which might explain some of its slowness.

Pretty much on schedule, Weblate 1.1 has been released today. It comes with translation updates, bug fixes, improvements in working with Git repositories and brings support for offloading indexing. Full list of changes for 1.1:

• Improved several translations.
• Better validation while creating subproject.
• Added support for shared git repositories across subprojects.
• Do not necessary commit on every attempt to pull remote repo.
• Added support for offloading indexing.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances can be found in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you (this will be decided case by case as my hosting space is limited). Update: Weblate appliace has now also been updated to 1.1.

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

Hello A while ago, Peter Knowles wrote a configuration model for Kerberos. Unfortunately, his priorities shifted before he completed this work. He was kind enough to send me the prototype in hope someone could take over. Although I do not know Kerberos, I believe the model is rather complete. Just click on the image below to judge for yourself: This work was released under a LGPL-2+ license. There are some tasks left to get a Kerberos configuration editor. These are mentioned in config-model-kerberos readme file. To look at the code, just clone config-model-kerberos with

git://github.com/dod38fr/config-model-kerberos.git

If you need more information on Config::Model, see:

• https://github.com/dod38fr/config-model/wiki
• http://search.cpan.org/dist/Config-Model/lib/Config/Model/Manual/ModelCreationIntroduction.pod

If you are interested in adopting Kerberos model, please keep us informed on config-model-users at lists.sourceforge.net. This will avoid duplicated work. On my side, I ll gladly answer questions related to Config::Model to help you get started. All the best
Tagged: Config::Model, Kerberos, Perl

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (168.12 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg This month, I resumed my work on dpkg. I concentrated my efforts on some polishing of the 3.0 (quilt) format. With the latest version (1.16.6 which was uploaded to unstable shortly before the freeze), dpkg-source restores the source tree in a clean state after a failed patch application (#652970), doesn t overwrite the patch header from the pre-existing automatic patch, updates automatically debian/source/include-binaries during dpkg-source commit, and supports a new no-unapply-patches option for those who dislike the auto-unapplication at the end of the process when the patches were not applied at the start. I wanted to go further and offer a new feature that could insert the automatic patch at the bottom of the quilt series but I have been short on time to complete this feature. I just managed to factorize all the quilt handling in a dedicated Perl module (Dpkg::Source::Quilt) to have cleaner code in the module handling the source format (Dpkg::Source::Package::V3::quilt). For those who wonder, this feature is meant primarily for the X Strike Force team which maintains packages in Git and are doings lots of upstream cherry-picks (to fix regressions, etc.). But they also use quilt on top of that tree to keep some lasting Debian specific changes. With the 1.0 format, the automatic diff is a bit messy but at least it gets smaller automatically when a new upstream release gets out, there s nothing to clean out. I d like them to be able to use 3.0 (quilt) while keeping their workflow. I m leaning towards allowing --auto-commit=first:cherry-picks that would name the automatic patch cherry-picks and put it in the first position in the quilt series. (Opinions welcome on that feature, BTW) Packaging There s been quite some packaging in this last month before the freeze:

• I packaged CppUTest (a test framework for C/C++), and I wrote an article about it.
• I prepared a stable update of Publican to fix a missing dependency. I also updated the unstable version to include a backport of a fix that some user requested me to include.
• I updated dh-linktree to improve its documentation (following a discussion that happened on debian-devel) and to deal properly with trailing slashes in its input (#673408).
• I sponsored dblatex 0.3.4-1 and ledgersmb 1.3.18-1.
• I updated gnome-shell-timer to a new upstream snapshot that was tagged as compatible with GNOME 3.4 (#6776516).
• I packaged wordpress 3.4 and spent a whole day triaging the old bugs that accumulated. A few days later I developed a new infrastructure to properly manage plugins/themes/language files. The canonical directory where the user is expected to drop his custom plugins/themes is now in /var/lib/wordpress/wp-content/ and the official plugins/themes are installed there with symlinks pointing back to /usr/share/wordpress/wp-content/ where they actually reside.
• I wanted to commit 2 patches for the developers-reference but then I noticed that some translations were complete and were waiting for an upload. So I cleaned the packaging (switch to dh) and I uploaded version 3.4.8 before committing the patches for #678710 and #678712.

While doing all this packaging work, I found 2 possible improvements that I filed as bug reports:

• #676606: debcommit should be able to identify alone that a new release is prepared (when the distribution field of the changelog changes from UNRELEASED to something else).
• #679132: lintian outputs false positives for the tag package-uses-local-diversion when neither local nor package is given on the dpkg-divert command line.

Debian France Booth at Solutions Linux From June 19th to June 21th, I manned the Debian France booth at Solutions Linux together with Carl Chenet, Tanguy Ortolo and other members of the association. We answered lots of questions, sold all t-shirts and umbrellas that Carl imported from Germany and Switzerland (we really need to get our own merchandising stuff produced in France!), got people to join the association. We also presented a printed copy of the Debian Administrator s Handbook and of the corresponding French book. You can see Carl, me and Tanguy on this picture (click on it to see a bigger picture, thanks to S bastien Dubois of Evolix for this one!):
I know lots of people are preparing for Debconf but I decided to not attend this year, the price of the air plane ticket was a bit too hefty for me and it was also in partial conflict with our family vacations. I thought about attending the Libre Software Meeting instead but alas I won t go there either (but Roland Mas will be there!), I have too much work to complete before my own vacation in 2 weeks. Thanks See you next month for a new summary of my activities.

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

For the last 10 years, I've been working on many Free Software projects. From Debian to OpenStack, through awesome, Emacs, XCB and many more. This obviously allowed me to enhance my technical skills, but it also taught me about Free Software and Open Source development processes, and how to work with and close to the community. Working for almost 6 years at Easter-eggs taught me how to work in an autonomous manner, how to lead and manage a project. And how to run a company, thanks to the cooperative status of this great one. These are the reasons why I decided to leave my latest job and run my own company to work as a freelance consultant & developer specialized in Free Software, starting today. Therefore, I am now able and available to provide expertise and development on Free Software, including upstream contribution. Especially on projects I already worked on recently, like OpenStack.

Already chilled by Wheezy freeze? It s been a long ride since the release of Squeeze, and your beloved FTP Team tried to assist our tireless developers and contributors at its best. Here are some hot stats to give you a figure about what happened behind the scenes. Since the release of Squeeze, 7462 .changes files with NEW components were processed by dak, with an average of 14.660 NEW packages per day. On the FTP Team side, we had 6877 accepts (13.511 per day), 641 rejects (1.259 per day) and 280 comments to maintainers (0.550 per day). This table represents the activity by single team member:

Login	Accepts	Rejects	Comments
ansgar	407 accepts (0.800 per day)	71 rejects (0.139 per day)	53 comments (0.104 per day)
dak	12 accepts (0.024 per day)	1 rejects (0.002 per day)	0 comments (0.000 per day)
dktrkranz	4319 accepts (8.485 per day)	381 rejects (0.749 per day)	104 comments (0.204 per day)
joerg	100 accepts (0.196 per day)	12 rejects (0.024 per day)	1 comments (0.002 per day)
mhy	214 accepts (0.420 per day)	14 rejects (0.028 per day)	5 comments (0.010 per day)
stew	67 accepts (0.132 per day)	16 rejects (0.031 per day)	7 comments (0.014 per day)
tolimar	1480 accepts (2.908 per day)	93 rejects (0.183 per day)	84 comments (0.165 per day)
twerner	278 accepts (0.546 per day)	53 rejects (0.104 per day)	26 comments (0.051 per day)

---

Who were the most prolific maintainers who got a NEW processing? Here is our special top ten:

1. Debian Perl Group (559 accepts)
2. Debian Haskell Group (491 accepts)
3. Debian Ruby Extras Maintainers (285 accepts)
4. Debian Java Maintainers (257 accepts)
5. Debian Med Packaging Team (164 accepts)
6. Debian Multimedia Maintainers (160 accepts)
7. Debian Fonts Task Force (156 accepts)
8. Debian Javascript Maintainers (137 accepts)
9. Debian Python Modules Team (129 accepts)
10. Debian Qt/KDE Maintainers (98 accepts)

That doesn t reflect the real developers, though. Here s our Changed-By top ten:

1. Clint Adams (216 accepts)
2. Jonas Smedegaard (208 accepts)
3. Ben Hutchings (203 accepts)
4. Joachim Breitner (153 accepts)
5. TANIGUCHI Takaki (112 accepts)
6. Alessio Treglia (101 accepts)
7. David Paleino (95 accepts)
8. Nicholas Bamber (76 accepts)
9. Mathieu Parent (68 accepts)
10. Jeff Breidenbach (63 accepts)

Clint rocks with tons of Haskell packages, followed by Jonas (mostly Perl packages), and Ben (kernel uploads). Italian cabal stands still, with Alessio and David respectively at 6th and 7th place

---

How long does a package stay in NEW? Some more, some less, but the average is 3 days, 15 minutes and 21 seconds. Now go and check your dak mails to see whether you had a fast processing or not liblog4ada 1.2-1 surely had, as it was accepted after 30 seconds! gsoap 2.7.17-1 was not so lucky, it took 103 days, 8 hours, 20 minutes and 43 seconds to clear NEW, but then made its way to the archive. Better late than never

---

FTP Team is not just accepting NEW packages, but also removing obsolete ones. Here are some details about this task:

• Source packages removed: 2159
• Binaries for architecture all: 8773
• Binaries for architecture alpha: 3646
• Binaries for architecture amd64: 14653
• Binaries for architecture arm: 3
• Binaries for architecture armel: 13283
• Binaries for architecture armhf: 3423
• Binaries for architecture hppa: 1418
• Binaries for architecture hurd-i386: 6923
• Binaries for architecture i386: 15655
• Binaries for architecture ia64: 12365
• Binaries for architecture kfreebsd-amd64: 10972
• Binaries for architecture kfreebsd-i386: 10998
• Binaries for architecture mips: 12478
• Binaries for architecture mipsel: 12479
• Binaries for architecture powerpc: 13945
• Binaries for architecture s390: 12374
• Binaries for architecture s390x: 3884
• Binaries for architecture sparc: 12295

---

FTP Team also took care of override changes:

• Number of priority changes: 853
• Number of section changes: 975