Eric, I cann’t claim to 100% understand the situation but after glancing trough the logs of the discussions and of the patches the conclusion I came to was this - OpenSSL used supposed randomness of the uninitialized memory as an added source of entropy (interesting hack, but not an example of good coding as such). Valgring caught that problem and the Debian maintainer during a cleanup fixed it. Making such a fix can be considered a preventive step against possible attack vectors by poisoning the uninitialized memory. He took it up to upstream, they did not raise red flags, but did not quite merge the ‘clean up’ patch either. It fell through the cracks. The problem is that in the same file, in another function all other sources of entropy were being merged into the pool of randomness using exactly the same code line as the one code line flagged by Valgrind. The maintainer assumed that the second code line has a similar function to the first and commented that one as well. AFAIK that also did not show up in the emails to the upstream list. So we have:

• Upstream using clever hacks that rely on uninitialized memory having some randomness to it
• Upstream using same code and same variable names to describe different things
• Upstream having no comments in the code explaining the two things above
• Maintainer slightly over-generalizing a change
• A bug slipping trough the cracks in the review processes
• Another Debian Developer discovering the bug and recognizing its significance despite all of the above
• Debian project coming out and admitting all of the above and scrambling to get fixes out to its users ASAP

I am impressed by the swift action of the people involved in fixing this. And while I think everyone can find some lesson be learned here, I think this is another good example of free software in action. And I hope that in the aftermath of this we will find ways to prevent this from happening in the future without stifling our progress.

The configuration of this blog has been explained earlier. There was one thing still missing from this blog --- comments.The comments plugin that comes in the contrib tarball from the pyblosxom web site is well-documented and easy enough to install. One modification I made is to remove all the javascript stuff since I don't understand the latter.After all this one still needs some sort of authentication to prevent complete rubbish from cluttering the comments section. The natural candidate was openid which is supported by a plugin from snarfed.org.This seemed easy enough to configure except that there is no version of these libraries in Debian "etch" (which is what people.imsc.res.in runs). So I downloaded the latest 2.x.x version of these libraries. Since I rarely install my own python libraries, it took me a while to figure out that I need to run

python setup.py install --home $HOME

in order to install it in my home directory. This also needed the codebase variable to be set in config.py.Unfortunately, this still did not work. The plugin comments_openid.py actually uses the API from the older 2.0.x version of the python-openid libraries.Some error messages from our web server led me onto a completely different track and I thought that the rewrite rules from the .htaccess file were in error. This was a McGuffin and I had to revert to the comment-free version in order to clean-up the mess. Thank goodness for git!The plugin currently works with the 2.0.x version of the libraries which may be mildly worse than the 2.1.x version.Some other things which are not working are e-mail/rdf notification of comments. I don't know if I will bother to fix that.

I've read some more about this and especially had a look at some of the source code, so I've completely revised this blog post.There is no doubt that the Debian Maintainer who added this patch screwed up, seriously. But he's not the only one to blame:

• OpenSSL isn't valgrind-clean. It should be made, since valgrind is a very important debugging tool; the bad patch was introduced to make OpenSSL better in this respect due to the request by the users.
• The OpenSSL source code could be better documented in these places.
• There are two instances of this line in OpenSSL which can both generate the 'using uninitialized data' warning. One is safe to remove (it's supposed to fill the buffer with random data, and just uses the existing contents as additional source of randomness), the other is not (it's used to feed randomness coming from e.g. /dev/random into the pool).
• The Debian maintainer received the reply "if it helps with debugging, I'm in favour of removing them" by one of the current OpenSSL devs on the openssl-dev mailing list. Probably just referring to the 'safe one' of the two locations where this occurs, though?
• Nobody noticed the severity of this change for more than 2 years. We're all to blame.

I'm really sick of hearing comments like "Still, whoever took out the entire initialization should not be trusted with security intensive code." (guest comment on LWN). Yes, he screwed up there. But you bet he's going to be a lot more careful with any change in the future: he has learned his lesson. Better than having someone else screw up in a similar way again. And actually he didn't do this change half as easy-hearted as many people suggest, if you look at the discussions on the bug report and mailing lists. He was trying to fix the valgrind bug, and he talked to several people on how to do it properly.The best way the bug could have been avoided was if the OpenSSL upstream developers had cared more about the valgrind issue themselves. (E.g. by teaching valgrind to ignore the issue, documenting in the source code why this is intentional and not an issue, ...)P.S. in the previous version of this blog post I had asked why OpenSSL apparently relies on uninitialized data for security. It doesn't; the same lines exist in two places, and it's the other change that caused the problems. One place will 'usually' generate the warning, and it's not important (that's the place where you could just remove the line). The other place will generate the same warning when someone passes uninitialized data into the RNG. As long as the RNG is sufficiently seeded with other random data that isn't much of a problem. So if you take a buffer of 1024 bytes and fill it with 1000 bytes of good random data (e.g. from a hardware randomness source) and feed the whole buffer to the RNG, it will be seeded quite well, but the warning will be generated. The 24 uninitizialized bytes won't take the entropy away.(This blog does intentionally not have a comment function. Sorry.)

As noted in the comments here, one reason to forcibly slow down the CPU on a system (and waste power in the long run) is to deal with cases where failing to do so can result in the machine overheating. Part of the problem is that Linux still tends to be less power efficient than Windows, and so various components will be generating more heat than when the machine was tested. The ACPI spec includes support for passive cooling of processors, which allows the system to reduce heat generation by slowing the CPU down. The problem is that not all vendors include a passive trip point in their firmware, and in the absence of one Linux will happily let the temperature rise until it hits a critical level and the machine shuts down.

I've written a patch that generates a passive cooling trip point if your firmware doesn't provide one. Since there won't be a firmware event when the temperature crosses the trip point, it also forcibly enables polling (the spec actually requires this, so I've no idea why Linux doesn't do it anyway). The default polling interval is quite long - you can adjust it in /proc/acpi/thermal_zone/*/polling by just echoing in a value in seconds. I've gone for a long delay in order to reduce any possible power consumption issues caused by this, but in the long run I'd like it to reduce the polling interval if the temperature trend is upwards and increase it again if the trend is downwards.

The patch makes the assumption that you're never going to get within 5 degrees of the critical temperature in normal use, which I think is pretty reasonable. The probability that the machine will reach equilibrium at that point is fairly small, so if you get that close you'll almost certainly end up with a powered down machine unless we do something about it (like forcibly downclocking your CPU). I don't have any affected machines, so I've only been able to test it by artificially lowering the trip point - if people find that it still lets the processor get over temperature without attempting to slow it down first, then I'll probably need to implement the more advanced polling policy.

In any case, I'm interested in feedback.

How to generate bootable USB keys with simple-cdd simple-cdd is a lovely piece of software that builds a custom D-I image with the package selection and preseeding of your choice. Today I was asked to build a bootable USB key with the simple-cdd image. Here is how; the general case is described in the d-i manual: General USB key preparation:

1. download vmlinuz and initrd.img from hd-media
2. apt-get install syslinux mtools mbr
3. Partition the USB key as needed (from now on, I'll assume the usb key is in the device /dev/sdb1)
4. Format it as FAT: mkdosfs /dev/sdb1
5. Put the boot loader in it: syslinux /dev/sdb1
6. Put the MBR in it: install-mbr /dev/sdb
7. Mount it: mount /dev/sdb1 /mnt
8. Copy kernel and initrd: cp vmlinuz initrd.img /mnt/

simple-cdd specific part:

1. Run build-simple-cdd as usual
2. Copy the ISO file generated by build-simple-cdd in the USB key. Any name will do, as long as it ends in .iso the installer will find it
3. Configure the boot loader, fetching the kernel command line out of the cdrom boot loader generated by simple-cdd:
   • echo default vmlinuz > /mnt/syslinux.cfg
   • grep append tmp/cd-build/etch/boot1/isolinux/isolinux.cfg head -1 sed -e 's/^\t//' -e 's/ initrd=[^ ]*/ initrd=initrd.gz/' >> /mnt/syslinux.cfg

This is it, it works nicely, perfectly scriptable, tested today.

I am affiliated with a project whose origin is the northern parts of Canada, although whose members span the globe called What Sort of People Should There Be?. The idea behind this nifty and catchy title is to get a bunch of researchers in various fields, from disability studies to philosophy and everything that comes in between to start asking a series of questions about the role of human enhancement today and eugenics in the past, all within the context of thinking about the experience and politics of disability. I am super excited about the project because it spans the past and present to confront what it means to be human, how we value variation, how we seek to support or erase difference, and lastly something close to my academic heart, the role of technology in facilitating and dampening the politics of possibility and hope when it comes to disability. The project has recently launched an multi-author blog and I will be posting there from time to time. If you are interested in this topic, do come by for a visit. I am sure you won’t be disappointed. My most recent post is here and it covers an interesting article in the New York Times on Mad Pride, which oddly enough is in the Fashion & Style section.

DSA-1571 is totally embarrassing. But I disagree with Julien BLACHE: we don’t need a new openssl maintainer. Mistakes sometimes happen to people who do things. That sucks, but it’s unavoidable, no matter how many levels of checking you add. Kurt has done a lot of excellent work on Debian in the past years, and I’m sure he will continue. Of course, it’s a lot easier and less risky to write tons of stupid blog posts. By the way, Julien, there’s an RFH bug for openssl open for more than 2 years. What about getting involved and helping Kurt yourself? On a more constructive side: it’s not the first time that a Debian-specific change broke something (I can think of a recent grep change …). It might be useful to provide a simpler way to review those changes (reading the diff.gz files is not really user-friendly). We could have something like http://patches.ubuntu.com/ (or even something nicer :-).

So far, if you want to use KDE 4 under Debian, you need to install them from experimental. Under the ground, we prepared up-to-date packages from trunk (soon uploaded) and I took a snapshot of my current desktop: We didn’t know yet if Lenny will be shipped with KDE 4 but we hope it will be in good shape to have it. Everyday, improvements are done and the desktop is enough stable/solid to be used on a day to day basis. On other side, I reported a bug on plasma panel alignment isn’t saved and some hours later, Marco Martin (mart) fixed the issue \o/ Tips: if you want to have a transparent panel, you need to enable compositing.

Well, maybe I was a little noisy with my first DSA. I will try to be quieter next time :)

I think that many people are being very unfair with the OpenSSL s maintainers. They made (and are making) a really good job. Was an accident, that things happens.

What we need is a real auditory process of the Debian specific patches. It s hard, but it s necessary.

Just the other day I was wondering about what release of Debian a specific version of a package was in, and I knew it was older than oldstable. But searching the Packages files of archive.debian.org was tedious and I thought that there has to be better way. So I quickly set up a packages.debian.org instance for archive.debian.org at archive.debian.net I guess this isn't really interesting for the day-to-day use, but maybe someone can ocassionally profit from it. Caveats:

• There are no binary files on archive.d.o for rex and buzz, so currently no information is available about them.
• There are no Sources files available for rex, buzz and bo, only Packages, so no information about the source packages can be presented.
• The two above point of course mean together that there is no usable information at all about rex and buzz. If someone would create the missing indices and convince the ftp-masters to put them on archive.debian.org, I will gladly configure archive.debian.net to use them.
• Changelogs and copyright files are currently only available for pool-using releases, since the extraction script has some assumptions that depend on that. On archive.debian.org, the only release that uses pool/ is woody.

Feel free to help me improve that site, preferably by sending patches against the archive-master branch of git://git.debian.org/git/webwml/packages.git.

Imagine, for a moment, that you are a young man in your 20s, trying to make your way in the world. You are married and have a young daughter, just old enough to start to talk. You live in a run-down neighborhood, long passed-over by any economic advances. What schools you had access to barely taught anyone much. The few jobs you can reach have fierce competition, even though the pay is low. You worry about your health, but even more about that of your wife and child. Finding food is a constant concern. Although you are still healthy now, and you are willing and able to be a hard worker, there is simply nobody hiring people in your area. Not to mention the gunfights that erupt between gangs or drug dealers. Oh, and did I mention that your wife is 4 months pregnant?

Your top priority is to do your best to keep your family safe. You're afraid that your whole family will starve, or be killed by an errant bullet. You've tried for a long time -- it seems like forever -- to do everything you can think of, with no success. Finally, you decide that the only way you can have the hope for a better life is to move somewhere where the economy is better, and the drug dealers are fewer.

But moving hundreds or thousands of miles away is no easy task when you have no money to move. Somehow, with some luck, ingenuity, and tenacity, you have finally managed to find a way. You have no job offer in your new town, but conditions are so bleak at home that you just can't risk staying there. So the three of you move 1500 miles away.

You arrive with no money, no apartment, and don't know anybody. But you're a hard worker, and have talked yourself into a job. It pays what passes for minimum wage in your new home, but it's a fortune compared to what you made before. It's backbreaking work, and you work long hours. But soon you can afford a cramped apartment, and keep your refrigerator stocked with food. What a luxury!

Pretty soon your new baby son is born. You can afford to feed him, your daughter, your wife, and yourself, every day. When you're really lucky, you even have some money left over to send to your brother back home, who is still struggling to make ends meet there. You seem to have climbed the first rung on the American Dream ladder.

Years pass. Your old home becomes a memory; your daily life revolves around new struggles now. Your oldest child is in school, your wife finds part-time work sometimes too, cleaning houses for rich people. You've been laid off several times, your income isn't guaranteed, and the others in your new home don't take kindly to strangers -- and they still think you're one. But it's better than flying bullets and never knowing where your next meal will come from.

Then one day, while you are at work, federal agents show up. You are arrested and taken to jail. Agents show up at home, too, arresting your wife. It turns out that they realized you entered the country illegally from Ecuador those years ago. Meanwhile, your wife wonders what will happen to your son that was playing in a neighbor's yard while she was arrested, or to your daugther that was at school.

After months in jail, with little contact with each other, and poor medical care, the government decides to deport you to Mexico. Why Mexico? Well, it's cheaper, and there's no documentation showing where you came from. Apparently you "look" Mexican, and they don't believe your story.

After months in jail with no income, you are once again bankrupt. A government bus takes you to Mexico and drops you down someplace there, with your wife and your oldest child. Your younger child was born in the United States, and so is an American citizen and can't be deported. But the government isn't going to give him a free ride on a prison bus (and Mexico wouldn't take him anyway, since everyone knows he's American). You have no idea where he is. You have no idea how you're going to find food in Mexico, no idea how to find your son, no idea where to find refuge from the ever more prevalent drug dealers. Meanwhile, the Americans think you're scum because you wanted to protect your family, and it's going to be much more difficult to get back in to try to reunite your family.

This story is based on true events.

It's truly easy to demonize illegal immigrants, isn't it? Easy to round them up by the thousands, easy to build a bigger fence, easy to lock them away.

Sometimes it seems like this nation built on freedom, supposedly on Christian values, has lost sight of compassion for the lowly. In this country, we would throw in jail parents that didn't do everything humanly possible to find food for their children. We also throw in jail parents that grew up in other countries that are just doing the same.

How sad that we have people going on TV, suggesting we round up millions of Americans that happened to come here illegally, breaking up millions of families, creating an immense foster child problem, a human tragedy on a mass scale. How incredible that some of these people on TV wear the title "senator" or "candidate for president". How stupid do they think we are, suggesting that a poor South American family would somehow be able to navigate the arcane American immigration system and wait the 15 years to get here legally, if they manage to come up with all the necessary money somehow?

Politicians have been pushing our buttons for too long. We aren't a nation of selfish hoarders; we came together through tough times, survived the Depression, put in place the Berlin Airlift that saved countless lives in West Berlin. But the thought of someone with darkish skin coming to this country and building highways is enough to send some people looking for a rifle.

I hope that we will someday do better.

Mark Shuttleworth has written an interesting post about Ubuntu release dates [1]. He claims that free software distributions are better able to meet release dates than proprietary OSs because they are not doing upstream development. The evidence that free software distributions generally do a reasonable job of meeting release dates (and Ubuntu does an excellent job) is clear. But the really interesting part of his post is where he offers to have Ubuntu collaborate with other distributions on release dates. He states that if two out of Red Hat (presumably Enterprise Linux), Novell (presumably SLES), and Debian will commit to the same release date (within one month) and (possibly more importantly) to having the same versions of major components then he will make Ubuntu do the same. This is a very significant statement. From my experience working in the Debian project and when employed by Red Hat I know that decisions about which versions of major components to include are not taken lightly, and therefore if the plan is to include a new release of a major software project and that project misses a release date then it forces a difficult decision about whether to use an older version or delay the release. For Ubuntu to not merely collaborate with other distributions but to instead follow the consensus of two different distributions would be a massive compromise. But I agree with Mark that the benefits to the users are clear. I believe that the Debian project should align it’s release cycles with Red Hat Enterprise Linux. I believe that RHEL is being released in a very sensible manner and that the differences of opinion between Debian and Red Hat people about how to manage such things are small. Note that it would not be impossible to have some variations of version numbers of components but still stick mostly to the same versions. If Debian, Ubuntu, and RHEL released at about the same time with the same versions of the kernel, GCC, and major applications and libraries then it would make it much easier for users who want to port software between distributions and run multiple distributions on the same network or the same hardware. The Debian Social Contract [2] states that “Our priorities are our users and free software“. I believe that by using common versions across distributions we would help end-users in configuring software and maintaining networks of Linux systems running different distributions, and also help free software developers by reducing the difficulty in debugging problems. It seems to me that the best way of achieving the goal that Mark advocates (in the short term at least) is for Debian to follow Red Hat’s release cycle. I think that after getting one release with common versions out there we could then discuss how to organise cooperation between distributions. I also believe that a longer support cycle would be a good thing for Debian. I’m prepared to do the necessary work for the packages that I maintain and would also be prepared to do some of the work in other areas that is needed (EG back-porting security fixes).

• [1] http://www.markshuttleworth.com/archives/146


• [2] http://www.debian.org/social_contract

Share This

As some people have guessed, not posting means that I'm doing quite well these days! The major advancements in my life since the last post are:

* Feeling comfortable enough to drive a car.

I finally feel like I can look around enough to shoulder check, although I can't twist enough to back the car up. When it comes time to park in out parking spot, I get Angie to do that bit.

* I'm allowed in the hot tub!

While this one seems like less of a big deal, since sitting in a hot tub in mid-20 degree weather is a bit weird, it's one more thing to do when I'm at home, and really pleasant on my back and shoulder muscles.

* My first HIV test came back negative.

Yay blood transfusion. The doctors consider the risk to be so negligible that they don't actively recommend that people get tested. They do, however, make you sign scary paperwork. So in order to be a responsible partner, and not a hypocrite when I teach OWL, I'm getting tested. One more test at 3 months, one more at 6 months to go.

Otherwise, things are going well. Physical Therapy is continue to put me on harder weights and Therabands almost every week. I'm continuing to reduce my meds at one pill per week (So I think I might be able to have a "Yay, I've got a 5-year visa" celebratory drink when I can back!). I'm still taking the anti-nausea drugs almost every day, but hopefully as I get off the pain killers, that will be less of a problem.

Oh, and I got our Canadian taxes mailed off (yay!). Now if we can only get the accountant to get the US ones off...

We're going up to Vancouver soon. There'll be at least one party for Leif, please email me if you want info. When we get back, I'll be straight into work, so forgive me if I suddenly go silent for a few weeks. =)

Now, back to homework. A course started a month earlier than I thought it did. =(

We've had two serious bugs on the NSLU2 recently that both caused the system not too boot anymore. The first one was related to initramfs-tools. Kevin Price reported that after upgrading to initramfs-tools 0.92 the system would hang during boot waiting for the root filesystem. When I booted my NSLU2 and looked at the output, I noticed that no root device was set. When I mentioned this to maks, the maintainer of the initramfs-tools package, he immediately knew what was wrong and uploaded a fix. On the NSLU2, the boot loader doesn't pass a root device to the kernel so we set one in the initramfs itself. The code that loads this config variable is not used by many devices so nobody noticed that this got broken in 0.92 until the package moved to testing. The second problem, reported on Saturday by Paul Collins and diagnosed today with some help from Kevin Price is also related to the strange way the NSLU2 boots. The NSLU2 has 6 MB available for the ramdisk but due to a bug in APEX (the second stage loader used on the NSLU2 by Debian) only 4 MB are actually used. When you write a ramdisk that is larger than 4 MB but smaller than 6 MB, flash-kernel will happily write the full image, but APEX will only tell the kernel about the first 4 MB. As it turns out, everything works fine on arm with 2.6.25, but on armel some additional SCSI modules are enabled that result in the ramdisk becoming too large. The short term solution is to disable these modules, but really APEX should finally be fixed (patches have been available for quite a while thanks to Gordon Farquharson). Fortunately 2.6.25 hasn't moved to testing yet and this problem only occurs on armel, so few people were impacted. The nice thing about the NSLU2 is that you can write a new flash image via the network, so you can flash a good image in case your machine no longer boots. Nevertheless, we have to make sure such serious bugs don't occur in the future or that they are at least caught very early. Special thanks go to testers like Kevin Price.

• 1 am, cautiuosly feeling my way through a construction site with a dim flashlight, weird bits of metal on concrete, sticking to the center as there are no guardrails. Suprised by a spot in the middle where the stars are bright and clear.
• Crossing the other way one day, since a train parked for an hour blocking the road. It's nearly done except for the approaches, but I still nervously look for police cars. View of Holston mountain.
• Twilight yesterday, threatening to storm, and suddenly I realise there are other pedestrians on the bridge ahead of me. Crossing over from illicit to legit. Kids walking down the center line. Cerimonial tent in the park.
• Evening today and I only bring myself to walk over it with traffic whizzing by because I know this is the last crossing that will be special.
• (A few days from now, in a car. Up and over. Another boring, ugly concrete bridge.)

If you look at the po-debconf stats pages, you'll see that, as of today, the French translators translated 9693 strings out of 9688...:-) We are so clever! This is actually an annoyance on the scripts that generate these pages. Sometimes, in packages, the debian/po/*.po files contain *more* strings than the debian/po/templates.pot files. This happens when maintainers do not run "debconf-updatepo" in the clean target of their debian/rules files. People, there is a lintian warning for this...:) We will try to correct this (actually, more Nicolas Fran ois than me, indeed) but that will make my stats less easy to do... So, "sadly", we are indeed only about 99%... That said, the NMU campaign is still going on. Portuguese is now ahead of Czech (ranked 3rd). Russian passed Swedish and is very close to Spanish for rank 7. And, among the most actives, Finnish and Basque are still climbing up quickly.

Over the last few days, I have been working on merging audacious-1.5 and bmpx, to create an XMMS-lookalike GStreamer player. It’s fairly “stable” now, some stuff is obviously not there yet (Tuplez for one, getting stuff like bitrate etc for another), but you can check out the Hg repository at http://hg.atheme.org/users/nenolod/mudkip-player. What does this mean for Audacious and BMPx? Absolutely nothing will change involving both projects. The goal here is to create a simple player which looks like XMMS to satisfy the demand created by XMMS removal in many distros. Both already existing projects have their own direction, this is just a shared goal to create a solution for the strain placed on our projects. Hopefully distros will take this as a hint and run with it. Hopefully.

You might have already heard of it — the new Nine Inch Nails album "The Slip" has been released by them under the Creative Commons BY-NC-SA 3.0 US license. Yep, that's right, it's totally legal to download it from the web — and use it for any non-commercial purposes! It's a bit annoying that they want your email address, though. Nothing that bugmenot.com (or similar) cannot fix, but still. Luckily, the files are now also available from archive.org! This, and the fact that the music is CC-licensed allowed me to "play" one of the songs in my Creative Commons music podcast (RSS), and more will likely follow.

Lalala, it’s me again. Don’t shout, it’s not a long post! :) What did we do since I last dared to post with my Ftpmaster head on? (Yes, I should put a summary of all my blog posts into a Bits from mail sometime.)

• Fixed some bugs, like all of the waiting Please create/remove pseudopackage FOO ones. So we now have a BTS entry for wiki.debian.org, release.debian.org and the security-tracker.
• Merged a patch from Thomas so we now correctly reject packages where the maintainer tried to be clever, editing the changes file to get an orig.tar.gz mentioned after forgetting the -sa parameter to dpkg-buildpackage. SIGH. Especially sigh as that ##censored## wasn’t able to understand the format of those lines. Nor did he look, or he would have immediately spotted his mistake. Unfortunately it is not the first time this maintainer broke stuff with uploads he never checked in any way. Including uploads for important packages. Bah.
• Merged another patch from Thomas, which generally makes NEW look nicer. It drops the unneeded Checksums-foo headers completly, no need that we see them there again, they just waste space and are useless for us. The patch also changes the html files we generate for all packages in NEW, something which I added to dak a few months ago - based on a patch from Thomas. :) The stylesheet now applied got sent in from Mart n Ferrari who already created the style for the removals page.
• Done a whole lot of NEW. Yes, I continue to do most of NEW, as I’m still (and possibly for some time) are the one with the most experience and speed in doing it. Thomas is doing NEW too, mostly by picking a few packages and processing them. (Before someone yells - he is doing a very good job with removals and override changes, an area where I haven’t looked much into since he got added to the ftpteam).
• Did, together with Mark Hymers, a lot of cleanup work in the code, using pychecker and pylint. We only started, but there have been various changes already, like
  • change “import daklib.foo” and then using daklib.function to “from daklib import foo” and then using foo.function. Granted, the Ideal way would be to go “from daklib.foo import function1, function2, function3” (or so), explicitly naming every thing you use. Or even better, make the whole dak fully object oriented. Or so. Or whatever. :)
  • replaced all own string exceptions, which are deprecated, with real exception classes.
  The cleanups we did made pylint rate the code 5.21, with the initial rating (before we did anything cleanup related) was 3.59/10. (As if it would count, but still) :)
• Added two more headers to mails generated by dak and the queue daemon, X-Debian: DAK and X-Debian-Package: $something, following a suggestion from Bug #479953. Hopefully other tools follow this schema too, at least I announced it on debian-devel-announce, so hopefully it will be taken as a quasi-standard. :) Ok, yes, I admit, the queue daemon is currently not adding the X-Debian-Package header. It does add the X-Debian: DAK header, but not the package one. I got a headache when looking at it, its old and grown perl code. If someone wants to send a patch, fine, the bzr repository has it in tools/debianqueued-0.9. Update: Now the queue daemin also adds the X-Debian-Package header as I got two patches addressing the issue, in two different ways. Thanks to Stephen Gran and Matt Kraai for their work!

Comments: 2