I wasn't going to comment on the recent openssl security update, because too many people have already done so. Personally I thought that Aigars Mahinovs made the best writeup I've seen so far. However I would like to say that having 20+ people all mailing security[at]debian.org to say the webpage we referenced in the security advisory is currently blank is not useful, or ask for details already released in the advisory they replied to, or ask for even more details is not so much fun. Having people immediately start mailing questions like "Huh? What can I do" is only natural, but you can't expect a response when things are as hectic as they have been recently. Ideally people would sit on their hands and bite their tongues. Realistically that isn't going to happen, and realistically this post will make no difference either... Had the issue not leaked to unstable so quickly (and inappropriately IMHO) then we'd have had a little more time. But once an issue is reported you need to coordinate with other distributions, and etc. Handling something as severe as this is not fun, and random mails from users are a distraction, and a resource-hog. I should say I was not in any way involved in the discovery, the reporting, the preparation of the fix(es), or the releasing of the update. I knew it was coming, but everybody else seemed to have it well in hand. When there are mails going back and forth for 5+ days with ever-growing Cc: lists, and mailing lists being involved I figure one more cook wouldn't be useful. So in conclusion:

a. Bad hole. b. Fixing this will take years, probably. c. 50+ mails to the security team within an hour of the advisory going public complaining of missing information is not helpful, not useful, and quite irritating. (Albeit understandable). d. People who don't know the details of an attack, or issue, shouldn't speculate and start panic, fear, and confusion. Esp. when details are a little vague. e. I still like pies.

Once again thanks to everybody who was involved and put in an insane amount of work. Yes this is only the start - our users have to suffer the pain of regenerating everything - but we did good. Really. Debian did good. It might not look like it right now, but it could have been so much worse, and Debian did do good. ObQuote: X-Men: The Last Stand

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.

A little off-topic exercise conducted in the "eye of the storm", when Ilenia and Helen were still in the hospital: A post on Seth Robert's blog brings up the idea that many Chinese restaurants were opened as a way to go into business without competing with native male workers. The post made the rounds of several other online journals. That was the push I needed to get up and go collect a few statistics of my own, regarding an idea I've been kicking around for a while. My theory is that the number of restaurants of a given type, divided by the number of immigrants from that country might be an interesting way of guaging the popularity of the cuisine in question. In order to simplify things just a bit, I actually used data from Italy, for the following reasons:

• Most immigration to Italy is pretty recent, so it's not necessary to account for the length of time different immigrant groups have been present, and the effects that may have had on the diffusion of a given cuisine.
• Immigration statistics were readily available: http://demo.istat.it/str2006/index.html
• Italian the language almost completely corresponds to Italy the country (outside of a chunk of Switzerland, San Marino, and the Vatican), something that makes things that much easier.
• I speak Italian, so it was easy to find out all the information I needed

Unfortunately, finding out the number of restaurants of various types is far from an exact measurement, and since this is a quick fun project, I just went for Yahoo search (they deserve credit for keeping their search API open when Google's was closed) results on terms like "Ristorante Turco" (Turkish), "Ristorante Messicano" (Mexican), and so on. This was the most expedient means of gathering information quickly, but this approach does present a number of obvious problems, listed here in the hope that someone without diapers to change and a business to run might come up with some good answers:

• Some hits likely come from people talking about a restaurant that happens to be in a country, like "ristorante americano". "Nel tipico ristorante americano, ...." or in other words, "In a typical American restaurant", rather than an American-style restaurant in Italy, which is what we were looking for in the first place. This is probably also true of countries close to Italy, where people go on vacation and thus have occasion to write about their experiences in a "ristorante tedesco" (German), rather than going to eat in a German restaurant in Italy. Perhaps the search query could be improved in an attempt to eliminate this sort of false positive.
• Some restaurants probably are not known as, nor brand themselves with a country name, but instead utilize titles like "Middle Eastern", "Arab", "South American", "African", or others that do not correspond with any one country in particular. It would be possible to group countries together with other adjectives, and get statistics for these clusters as well.
• Measuring hits is measuring what people are talking about, rather than simply restaurants that exist, so if restaurants from a certain country are more talked about than others, that would muddy the statistics a bit. However, it seems reasonable that people would mostly talk about restaurants in proportion to their popularity, and I don't see a particular reason why there would be more talk of Vietnamese restaurants, say, than Thai restaurants, compared to the actual numbers.

That said, for a quick project, this approach seemed to work out ok, and the results appear credible. Obviously, the results also reflect people discussing certain cuisines, rather than an actual number of restaurants, but since it does reflect interest, we'll use the number in any case. Since the number of restaurants/interest in a type of restaurant was clearly not correlated directly with the number of immigrants, other factors must come into play. For instance, "ristorante giapponese" turns up 125,000 hits, but the stats say only 6873 Japanese nationals live in Italy. As above, hits don't mean actual restaurants, but clearly Japanese cuisine is not being popularized through immigration. Here's my guess: these statistics show, to some degree, what people in the host country actually like to eat. Food that tastes good means more restaurants. Things that aren't that popular mean few restaurants, even if there are many immigrants. To pick on one country, there are many Philippino immigrants in Italy, but very few search hits - and anecdotally, I've never seen a Philippino restaurant in Italy either, whereas even smaller towns like Padova have Chinese, Mexican (well, it's called that, even if it's a shadow of the real thing), Japanese, various Arab and middle eastern restaurants, and even a few less common things like Eritrean. And I know that many native and foreign restaurants employ Philippino cooks. Below is the chart I whipped up showing the number of Yahoo hits per immigrant. The Italian names shouldn't be too hard to figure out. A few tricky ones: Giordano-Jordanian, Giamaicano-Jamaican, Spagnolo-Spanish. If you're interested in numbers or source code, contact me.

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.

My slug was temporarily bricked for a few days due to a mistake on my part. Fortunately, numerous write-ups by Martin Michlmayr and others helped me. Here I am adding one more source of the same information!The following assumes that you have a backup.img which contains bootable Debian firmware for the slug but has the wrong kernel and initrd. One can probably use the Debian firmware that is the Debian Installer image otherwise --- but I have not tested this!Moreover, I also assume that you have the full system installed on a USB disk which you have mounted on your regular desktop at /mnt.

Copy the kernel and initrdWe just create an new "recovery" directory and copy boot/ over from the mounted USB disk.

mkdir recover; cd recover
cp -a /mnt/boot .

At this point you can un-mount the USB disk and keep it ready to connect it to the slug.

Extract the files from the slug imageNext we extract the files from the slug backup image into another directory.

mkdir files; cd files
slugimage -u -i ../../backup.img

(Here you must use the actual path to the backup image file)

Replace initrd and vmlinuz by new onesWe first pad the initrd

dd if=../boot/initrd.img of=new-ramdisk ibs=4M conv=sync

(here you must you the actual file name of the initrd.img that you want to use to boot the slug) ... and then swap bytes

devio '<< new-ramdisk; xp $ 4' > ramdisk.gz 
rm new-ramdisk 

Next we swap bytes for the kernel as well

devio '<< ../boot/vmlinuz; xp $4' > vmlinuz 

(again you must use the actual file name of the kernel image in place of ../boot/vmlinuz above).

Actually build the imageThis is just a single command

slugimage -L apex.bin -r ramdisk.gz -k vmlinuz -p -o ../../new.img

Put the slug in "firmware upload mode"

1. Put the slug off and disconnect everything from it.
2. Connect an ethernet cable ¹ between your desktop and the slug. Connect the power plug for the slug but do not switch it on yet.
3. Push a pin into the hole marked RESET at the back of the slub. Keep the pin pressed, while pressing and releasing the power button on the slug. Wait with the pin pressed until the top light on the slug turns red and the instantly release the pin.

You slug is now reset and waiting for a firmware upload.

Upload the firmwareOn your desktop run the command

sudo upslug2 -i ../../new.img -d eth0

(Here ../../new.img should be replaced by the path for the image created above and eth0 should be the name of the ethernet interface on the desktop to which you connected the other end of your lan cable.)This step takes a short while but shows you some progress information.

All systems "Go!"If all went well you have rejuvenated your slug. You can now reconnect your USB disk to your slug and the system should boot as usual.

---

1. You may need a cross-over cable if your desktop lan card is really old. ↩

We've been blessed with really wonderful neighbours in our apartment building. We know four out of the seven households in our building really well. A while ago, we thought it'd be cool to rent a house and have a weekend away together, so we booked it for this weekend, rented a house in Rio Monte on the Russian River, and hung out together for the weekend. Eight adults, 3 kids, and we're all still talking to each other afterwards. Trying to coordinate outings with 2 small kids nap schedules was tricky, so we only made it to the Korbel winery, but we picked up some cheap champagne (an I thought you could only call it champagne if it came from Champagne, France). Sadly, because Gavin and Christina have a second son on the way, they've bought a house up in greater Sacramento, and are moving out next weekend. We'll miss having them and Aiden as next-door neighbours. We've decided that we should make this an annual event, so there'll be an annual "building 4" reunion. Photos from the weekend are here.

There should be a website to coordinate cinema-dates. I don't like going to the cinema alone and have, in the past, frequently missed viewing films rather than go alone. This is a habit I'm growing out of, but I still think it is better to go with a friend or two. In the near future I'm going to view the last Indianna Jones movie, and the Sex & The City film. I have partners for both of those. But after that? There are a few films which I can't immediately think of who I'm going to lure away with me. I could either :

• Go alone, regardless.
• Randomly ask people to come

If there were a site that had list of upcoming films, and allowed you to express interest in going to see them that would be a fantastic idea. (Obviously location based). I'd not even assume "dating", because I think in my life I've had a first-date at a cinema once. When I was about 14. Because it just doesn't work - you can't talk during, (and back then we couldn't go to the pub afterward to discuss the film. I think we did anyway ;) For bonus points you could allow people to rate the films, or even each other. Hmm. Somebody write it for me? I've got too much on my plate ..probably ObQuote: Se7en

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

I have updated apt-p2p to version 0.1.3, which is available now in unstable and my repository (see my previous post introducing apt-p2p). This update brings mostly speed improvements to finding peers to download from, and performing the download. Nodes in the DHT are now checked for responsiveness more thoroughly before adding them to the routing table, and rechecked more frequently afterwards. This should prevent bad nodes from propagating through the system, and departing nodes remaining in the system long after they have left. Downloading from peers is also quicker, as bad peers are dropped with a quicker timeout value and after a small number of errors. There was also a bug revealed by about 10% of the mirrors that caused downloads to fail, and was fixed in version 0.1.2. This update is STRONGLY recommended, as keeping unresponsive nodes out of the DHT will make everyone's experience better. If you tried apt-p2p and had some problems, I hope you'll consider trying again now. Unfortunately, these are enhancements I could not predict needing before releasing to the public, as the problems they solve are all caused by having a larger number of users, some of which are unresponsive. There are still a large number of peers (maybe 50% of them) that are unreachable, and so can not share any files with other peers. I don't have a good way to check yet, but you can go to sites such as this one to probe your client for you. Just enter the remote IP address and port (available on the status page) of your client in the form http://ipaddress:port/ (e.g. http://1.2.3.4:9977/). If the check returns any HTTP headers (even a 404 Not Found response) then you're fine, but if it doesn't return anything then your peer is firewalled or NATted and should probably be fixed. Here are the changelog entries for 0.1.2 and 0.1.3:

• Speed up downloading from peers
  • Set a new peer's ranking values so they don't get an unfair advantage.
  • Reduce the HTTP connection timeout to 10s.
  • Drop peers after a limited number of errors.
• Speed up the DHT requests when nodes fail
  • Schedule a re-ping message after adding a new node.
  • When a node fails, schedule a future ping to check again.
  • Send periodic finds to nodes that are stale.
  • Increase the stored value redundancy to 6.
  • Increase the concurrency of DHT requests to 8.
  • Add early termination and ignoring slow responses to recursive DHT actions when timeouts occur.
• Remove the debconf note about port forwarding (Closes:#479492)
  • Add a NEWS entry for port forwarding
• Fixed a bug in the HTTP downloader that caused errors with some mirrors that always close the connections (Closes: #479455)

My previous entry was somewhat misleading in one respect - the discussion of the power consumption of a downclocked processor. The problem is that nowadays, halving your CPU frequency doesn't halve the power consumption (see the figures in Arjan's slides from OSCON last year, for instance). I'm assuming that this is due to the cache size on modern hardware being sufficiently large that it dominates the power consumption of the processor. Dropping the frequency doesn't reduce the amount of power required to keep the contents of the cache alive, so the saving is less than you'd expect. Deeper C states disable the cache and save much more power.

So, if halving your speed means everything takes twice as long but doesn't even halve your power consumption, what's the point in having P states at all? There's a certain amount of latency and power involved in moving between C states, and if the choice is between rapidly cycling between full speed and C4 or just sticking at low speed and maybe dropping into C1 or C2, then executing code at the lower performance state may be beneficial. The ondemand governor takes this into account by looking at the amount of load on the processor over time, so if this doesn't hit a threshold value it'll assume that you're better off staying at the lower performance level.

I would not blame the people I speak to regularly for getting some kind of fatigue regarding Nine Inch Nails. It seems like a week hasn't gone by this year without something happening: a single, an album, or tour dates. It didn't come as much of a suprise that a new album was released in it's entirety this monday gone. ID3 tags in previously-released singles said "watch nin.com on 5th of may". It wasn't even that suprising that the whole album was free, either. What was a suprise, to me at least, was that this album is fantastic. I'd heard two tracks prior to the album being released (although one only by a few days). Whilst I enjoyed them, they were pretty safe, lyrically and musically. They didn't push any boundaries. They also did not forshadow the album at all. This album is the best Nine Inch Nails release this century. It's too early to tell whether it stands higher in my estimation than 1999's The Fragile. If so, it's the best release since 1994. I had not even considered this a possibility. I also think it's the best album to present to someone who isn't familiar with their work to see if they'd like to look for more. It has a good range of tracks covering loud, aggressive, introspective, instrumental, dancable, dark and delicate. I'm now starting a self-imposed ban on listening to the album, so as to not overdo it too much so early on. Regardless, I can still hear The four of us are dead playing over and over again in my head. This is a strong candidate for my favourite NIN song ever. It made me think of what the Cure should be writing. Each track in this release (like each of the 36 tracks in the last album) have their own unique embedded picture in them. There is scant software in Debian that can handle these, unfortunately. I think "tagtool" can add and remove art. Amarok copes admirably. Rhythmbox doesn't, unless you apply this patch, which is stagnating in gnome's BTS, unfortunately. For the lazy (with 32bit x86), here's a tarball of a recent-ish rhythmbox rebuilt with this patch. I'd supply a Debian package but I didn't feel like building the documentation at the time. I haven't found a single program for the n800 that can handle the artwork.

Some of you might have noticed that in the recent weeks I wasn't active at all online. This was because I was on a vacation in Italy. On the way back I was eager to write about my experiences, but after entering Romania, I found out that may parents had been involved in a motorcycle accident due to a careless driver.

The accident took place on the second day of the Orthodox Easter (on the 28th of April)[1] while my parents were coming back from my sister's, just 20 km away from my home town, Caracal, in a village called Z noaga. There, a Daewoo Cielo was parked on the left side of the road[2], facing the direction towards Caracal. The driver decided that it was a good idea to turn his vehicle and, according to his declaration, instead of looking himself if there was anything comming, he asked a passenger if there were any cars comming.

Since a motorcycle is not a car, I guess the passenger thought it was OK to answer "no".

So the driver simply started his maneuver and managed to occupy the entire right lane, according to the accident schematics (I saw the official police schematics of the accident site with my own eyes). There were only 30 cm from the front most point of the car to the ditch on the right side of road, while the rear wheels were on the mark indicating the axis of the road. That left only 2 meters free on the opposite lane out of the 6.60 meters wide road, so there was no way for my father (driving the motorcycle) to avoid the collision, in spite of the fact he was travelling at about 40-50 km/h[3], within the legal speed limit (50 km/h).

My father barely had enough time to avoid the central pillar and aim for the rear right door of the car, obviously, a safer place to hit. Still, this wasn't enough to keep my mother on the motorcycle, a safer place for her than anywhere on the road.

My mother was projected over my father and over the car, and, luckily, landed on the side of the road, between the asphalt and the ditch, on an area covered with grass. She landed straight onto her head (the helmet protected her really well), and the shock of the landing propagated along the spine, resulting in the fracture of the L1 vertebra. She also got a fissure in the right clavicula, but that should already be OK now.

My father managed to remain on the motorcycle, but the impact was violent enough that he managed to bend the gas tank and has two huge bruises on the inside of his thighs (one for each leg). He also accuses pains in his shoulders and the lower end of the spine (unfortunately he "managed" not to do the medical investigations after the accident), but I hope all of these will pass soon and will have no ill effects. Also, out of sheer luck, at that time, my father was wearing a full-face helmet, contrary to his habit of earing an open-face helmet; due to this, his face was protected and suffered no harm, while the chin of the helmet broke after the impact with the motorcycle windshield. Also some deep scratches starting from the half of the helmet windshield up to the top of the helmet were the signs of a (probably second) violent impact with the motorcycle windshield.



So, the next time you are on the wheel, please look out for motorcycles, too. Motorcycles do exist on the road!

Also, I advice anyone driving a motorcycle to wear good protection equipment like a full-face helmet, jacket, pants, boots, gloves, etc. These helped a lot my parents, and will help you too, if, God forbid, you are involved in an accident.


My mother is in a cast that covers her from hips to shoulders to help with the fracture recovery and also wears a collar (just for safety reasons since she is suffering of spondyloses).
My father is able to walk (with some pain) and seems not to have any injures (I will take him for a close investigation some time soon in spite of his stubbornness).



[1] worrying for us (me and my future spouse), my parents didn't told us and waited for us to return to Romania
[2] in Romania the vehicles travel on the right side of the road, so the driver also drove on opposite lane, a fact which, according to the law, is punished with the suspension of the driving license
[3] he speed was confirmed by the measurements done by the police

I was excited by Pierre s idea to add Git branch information to the Zsh prompt and even more so when I saw Mike implement support for multiple VCSs. Unfortunately, Mike s a Bash user, and so I took it upon myself to port the idea to Zsh. The file 60vcsprompt is sourced from my .zshrc, which sets psvar[1] through psvar[3]. Those are then used in 80prompt (also sourced from .zshrc) when setting $PS1. My prompt follows the same principle as Mike s and puts the branch name at the repository root location in the repository path. In the following example, ~, ~/code, and ~/code/netconf/netconf are three separate Git repositories, while ~/code/unionfs-fuse and ~/code/unperish are maintained with Mercurial and Bazaar respectively:

lapse:~ master % cd code
lapse:~/code master % cd netconf 
lapse:~/code master netconf% cd netconf
lapse:..e/netconf/netconf master % cd src
lapse:..etconf/netconf master src% git checkout no-threads
Switched to branch "no-threads"
lapse:..nf/netconf no-threads src% cd ../../../unionfs-fuse 
lapse:../unionfs-fuse hg:default % cd ../unperish
lapse:..unperish bzr:unperish@159 %

You ll notice that unlike Mike s prompt, mine s limited to a maximum length of 25 characters. However, the repository root path is kept at least 10 characters long, so the prompt might get longer than 25 characters if you descend deep into a repository s subdirectories. I couldn t easily figure out how to add support for other version control systems, so if you do, please feed back the patches! And the same goes for suggestions and improvements. One of the next things I am planning to implement is an indicator for when your working tree contains uncommitted changes, e.g.:

lapse:..etconf/netconf master src% touch foo
lapse:..tconf/netconf master* src%

So watch those files. NP: Gazpacho: Bravo

Surveillance, massive patent litigation, and toxic trails are just a few of the atrocities that are part and parcel of the global giant Monsanto. They do not just produce a lot of the worlds GE crops but some MAJOR FUD with real muscle as this disturbing in-depth article demonstrates . Whether it is their shadowy, relentless fight against American farmers to “protect” their patents or their fight to scare dairy farmers from labeling their milk BST free, they deploy an astonishing range of legal and extra-legal tactics to make sure they stay on top. Below is a smattering of some of their creepiest tactics, which kinda make the RIAA look angelic in comparison.

“To gather leads, the company maintains an 800 number and encourages farmers to inform on other farmers they think may be engaging in seed piracy. Once Pilot Grove had been targeted, Monsanto sent private investigators into the area. Over a period of months, Monsanto s investigators surreptitiously followed the co-op s employees and customers and videotaped them in fields and going about other activities. At least 17 such surveillance videos were made, according to court records

“Studies by health authorities consistently found elevated levels of PCBs in houses, yards, streams, fields, fish, and other wildlife and in people. In 2003, Monsanto and Solutia entered into a consent decree with the E.P.A. to clean up Anniston. Scores of houses and small businesses were to be razed, tons of contaminated soil dug up and carted off, and streambeds scooped of toxic residue. The cleanup is under way, and it will take years, but some doubt it will ever be completed the job is massive. To settle residents claims, Monsanto has also paid $550 million to 21,000 Anniston residents exposed to PCBs, but many of them continue to live with PCBs in their bodies. Once PCB is absorbed into human tissue, there it forever remains.”

The company contends that advertising by Kleinpeter and other dairies touting their no rBGH milk reflects adversely on Monsanto s product. In a letter to the Federal Trade Commission in February 2007, Monsanto said that, notwithstanding the overwhelming evidence that there is no difference in the milk from cows treated with its product, milk processors persist in claiming on their labels and in advertisements that the use of rBST is somehow harmful, either to cows or to the people who consume milk from rBST-supplemented cows. Monsanto called on the commission to investigate what it called the deceptive advertising and labeling practices of milk processors such as Kleinpeter, accusing them of misleading consumers by falsely claiming that there are health and safety risks associated with milk from rBST-supplemented cows.

Tonight, I converted the XML-Security-C package from Stanford's internal Subversion repository to Git and packaged 1.4.0, but unfortunately I can't upload yet because Xalan needs to be updated to build against the latest Xerces-C. (I'd NMU, but I should not be taking on more things right now.) This is the first of the three current Shibboleth packages, and I hope to tackle OpenSAML and Shibboleth SP tomorrow or Wednesday. An Alioth project for Shibboleth packaging now exists and the pkg-shibboleth-devel mailing list is being created. I've requested Git space on git.debian.org, and as soon as that's set up, I'll push the three existing repositories. Shibboleth 2.0 packaging will add at least three more packages (OpenSAML 2.0, Shibboleth SP 2.0, and another XML support library), possibly four if we have to package log4shib, but I still hope to use the standard log4cpp. And then there will be another couple of packages once the group packages the Shibboleth IdP and WAYF, which I hope someone with more Java experience can tackle. One of the main goals for getting this set up is so that people other than me can do more of the work so that I can work on other things. Like, for example, krb5 packaging. Bastian Blank started using the Kerberos server packages and posted a whole flurry of bugs, a couple of which are (somewhat arguably) RC, and I'm trying to absorb that and fix the ones I can ASAP. OpenLDAP is in desperate need of attention, but I don't feel as much responsibility for that. I said going in that I'd only have time to work on it in fits and starts, and just because no one else has any time to work on it either doesn't change that. However, I do need to find time to post an RFH, since it really needs an active maintainer, and I'll at least find time to upload the upcoming 2.4.9 release before lenny freezes more, since the current version has a ton of bugs. Frank Lichtenheld has been doing a lot of the work on Lintian lately, which is wonderful, but I still have at least 10 bugs and patches that I want to deal with as soon as possible for it and get another upload out. We're well over my magic threshold of 100 bugs, and a lot of the stuff that's in the BTS just needs to be reviewed and committed. And then there's Policy, which is just about ready for an upload, and where I owe several responses on bugs and discussion threads. It's in the best shape right now of the stuff on my hot list, but there really should be a new upload in May, and preferrably in the first half. The current goal is to get the two other RC bugs against the Shibboleth packages dealt with in the next couple of days, then do a krb5 upload before the end of the week, and then Policy and Lintian are back at the top of the list, insofar as work lets me concentrate on anything else. BTW, I have to say, the more I use Git, the more I'm becoming a convert. I still think I'd rather use quilt if I have complex merges. Ironic, given that that's supposed to be Git's strength, but I have fifteen years of experience merging patches and I really understand how quilt works. That may mean I'll change my mind when I become even more familiar with Git. But for the typical package with a small number of divergences from upstream, I'm getting the hang of managing those on branches and I think I like it. I've yet to see a good reason to use rebase instead of merge, though, at least as part of a Debian packaging workflow. So either I'm still not getting something, or many of the people using Git are way more obsessive than I am about their branch merge graphs (which is weird, because I tend to be remarkably obsessive about things like that). I suppose if I ever get to using git bisect, that may change my mind.

It might happen that you (I mean you, gentle reader of this blog) being a Debian developer or maintainer, just receive one of my numerous "Intent to NMU to fix pending l10n bugs" or "Announce of the upcoming NMU of ". The first gives you 10 days to react....then I send the latter which opens an 8 days translation update round. In such case, as the carefully written template for these (pretty long) mails says, please DON'T immediately upload. Speak to /me instead so that we coordinate the translation update round. That will also allow me to send you possible QA enhancements I found in your packaging while trying to build your package *and* translators to send more material. Some (rare) maintainers just uploaded immediately after getting these mails and they're now getting what could be expected: they're receiving new translations...and are then likely to be catched pretty soon by the patrol, again..:-). The "intent to NMU" mails are sent to the i18n mailing list and some translators find this to be a good opportunity to send translations in their language (that's why Finnish, Galician are for instance climbing up pretty quickly in statistics). The main intent of these NMUs is to get updates done, not doing NMUs so, of course, I will welcome uploads...it is however more efficient to coordinate them.

Adrian, it looks like you are looking for apt-zeroconf. It looks like great idea, but it does not seem to be really active recently and unfortunately it did not yen find it's way to official archives...

Going just from the title of Cameron's post about his apt-p2p tool: How about automatically running a zeroconf-enabled webserver serving /var/cache/apt/archives (and any mounted local repositories?) during install and while aptitude is running (and, if the user allows, as a daemon by default on a running system) and of course a corresponding sources.list line and apt retrieval module. This would hugely improve installation time for people with just a few machines who are too lazy to set up their own apt cache. Obviously, the details would be tricky, but since there is a security chain from Release.gpg to the .deb, downloading packages from untrusted peers shouldn't be a problem, even if the package name / version pair is not really unique (or even if someone actually tries a spoofing attack.) (There's a thought: running a tftp / dhcp server with a fai network boot in addition would be a step towards world domination, too, closely followed by automated hacking tools to install Debian on all computing devices on the network. Support call: “My printer only prints one page saying debian:~# after power on and then stops.”) Update 2008-05-07: Both Nijel and Florian Ludwig himself pointed out his apt-zeroconf project, which is unfortunately not very actively developed at the moment. Yet another thing I should/could do if I had the time.

After a fair amount of clean-up, a lot of waiting for review, and some ruthless pruning, I and my colleagues at Solarflare finally got our net driver accepted for Linux 2.6.26. Meanwhile a larger version of the driver made it into Xen's Linux tree, along with dependent drivers to provide a secure fast path to the hardware from domU. Somewhere down the road we're going to have to resolve these two versions, but now I'm just pleased to have a working driver in-tree. There are some other changes I've worked on over the past few months:

• I maintain diagnostic scripts for our NICs and drivers. Among other things they include Vital Product Data (VPD). There's a standard way to read VPD in PCI (actually there are two, in different versions of the spec) but in Linux this is only accessible to root, and even then there are race conditions. We provide an MTD driver for flash and/or EEPROM attached to the NIC, and I know where the VPD appears in there, but most users won't be loading that driver. So I wrote this: Expose PCI VPD through sysfs
• Along the way I found a bug in sysfs, which I fixed: Disallow truncation of files in sysfs
• One day I accidentally bridged one of our network interfaces, which has Large Receive Offload (LRO) enabled by default, with one of the motherboard's network interfaces, and the results were not pretty. LRO isn't really compatible with packet forwarding, and currently causes the GSO code to crash or warn. I wanted to solve this by disabling forwarding of LRO skbs, but it turns out to be trickier than I thought.
• We wanted to use topology information to allocate one IRQ per CPU package, not per core (or per thread, with HT enabled) for Receive-Side Scaling. Unfortunately this information is only available in some kernel configurations and not for all architectures. I had a go at providing reasonable defaults, but it didn't work too well!

However, this is still only part of my work. My main task at the moment is to write more unit tests for our next NIC.

Just up on arxiv.org this week appeared Warming the early Earth - CO2 considered, by von Paris et al. Just a preprint, and i'm working through its 53 pages now, put its likely to put the cat among the pidgeons:

Abstract: Despite a fainter Sun, the surface of the early Earth was mostly ice-free. Proposed solutions to this so-called "faint young Sun problem" have usually involved higher amounts of greenhouse gases than present in the modern-day atmosphere. However, geological evidence seemed to indicate that the atmospheric CO2 concentrations during the Archaean and Proterozoic were far too low to keep the surface from freezing. With a radiative-convective model including new, updated thermal absorption coefficients, we found that the amount of CO2 necessary to obtain 273 K at the surface is reduced up to an order of magnitude compared to previous studies. For the late Archaean and early Proterozoic period of the Earth, we calculate that CO2 partial pressures of only about 2.9 mb are required to keep its surface from freezing which is compatible with the amount inferred from sediment studies. This conclusion was not significantly changed when we varied model parameters such as relative humidity or surface albedo, obtaining CO2 partial pressures for the late Archaean between 1.5 and 5.5 mb. Thus, the contradiction between sediment data and model results disappears.

The suspected composition of the eary Earth (the Archean, when life is believed to have started, 3.8 to 2.5 billion years ago), has alternated between CO2 and other reducing gases, such as methane. Originally CO2 was thought to be the main greenhouse gas, making life possible. However the high CO2 levels required were a problem; high CO2 levels would have created siderite (FeCO3) in the top layers of soil as iron interacted with CO2 in the oxygen-free air. Since then methane has top billing as the greenhouse gas responsible, with significant hydrogen levels a possibility. Over time, methane has come out on top. And thats what I wrote when I did my literature review for my PhD. Now I'm tidying it up a bit, and that section may be in for a rewrite. But what does it mean for our Climate change models of today? Tags climate, co2, thesis