After my last experience, you'd think I'd have learned. But nope, when my girlfriend needed a new desktop system, I enthusiastically offered to build one for her. Hey, this time it's desktop hardware, and I know desktop hardware, right? I built my last machine myself, and I've replaced a couple motherboards and done various other work on computers since then.

Well, it seems there were a few changes since my last computer. First of all, there's the whole business of heatsinks. I don't remember spending any time on the heatsink last time around. I suppose this is because it was pre-attached to the chip or because the assembly process was "place the heatsink on top of the CPU", but I don't remember which. For the Athlon 64s, the heatsinks are so ginormous that you couldn't place the CPU into its slot if it was attached to the heatsink. So there's no option but for them to ship the two separately and have the user assemble them.

Problems? Well, consider the documentation. The store sold us a supposedly complete CPU box packaged by AMD which, when I opened it, contained a stern warning not to attach the heatsink without first applying a thermal material. Contradicting this, though, was the fact that there was something that looked suspiciously like thermal material already on the heatsink, and after quite a bit of research I decided that the warning was for people who want to overclock their systems or replace the stock thermal compound. Nowhere in the documentation does it say whether the heatsink comes pre-treated with thermal compound, though, and since I have no desire to let the magic smoke out, I wasted a lot of time checking up on this.

A second problem with the documentation is that it suffers from severe Lowest Common Denominator syndrome: the installation instructions are entirely word-free. For simple purposes this might suffice, but it took me a lot of squinting and several incorrect tries to figure out WTF the diagrams were telling me to do; in fact, I didn't really figure out what to do until I found an annotated version online with actual words. AMD, there's a reason we quit using cave paintings and invented written language. Please use the stuff, it'll make the rest of us much happier.

On to the practical problems: it's apparently necessary to attach the heatsink so tightly that you need a latching mechanism the size of Wyoming to hold it onto the motherboard, and actually activating it seems to take several metric tons of force. OK, I exaggerate, but just this step (attaching the heatsink assembly to the CPU) took me at least an hour of prying at the latch mechanism to lock it down. In fact, I didn't finish until I finally gave up using my fingers and used a screwdriver to apply a good portion of my weight. Predictably, of course, the screwdriver slipped as I secured the latch, bouncing off the motherboard. More on that in a moment.

The motherboard (an Abit K8N) had better documentation than the CPU, but not by much (this is apparently a pattern with computer components that most consumers never mess with). I had to make educated guesses about the orientation of several connectors, especially some of the case connectors, and it took me at least a dozen reads to understand what I was doing wrong with the power cable.

Once I got all my initial stupidity worked out, I flipped the switch and watched some of the fans turn on and the hard drive spin up...and that was it. Nothing. Nada. No beeps. No POST. Not even a blank video signal (although the video card's fan runs just fine).

So, my best guess is that I killed the motherboard dead with my screwdriver, which means I get to go buy a replacement and install it. And, of course, disassemble all the stuff I carefully assembled already. Including the CPU assembly. And the thermal material on that probably won't be good any more, so I'll have to replace it with what's left over from when I rebuilt my laptop. And there's always the possibility that it's actually the CPU that's dead (although I can't imagine why)...in which case I could waste a lot of time and effort replacing the motherboard needlessly. Blah.

I begin to think that it might be worthwhile to pay the store to install the critical components for me, or even just buy from a real PC vendor. At least then I'd avoid wasting my time and (presumably) get my money back if they screwed up.

This seems to be pretty old, but I only stumbled over it recently: Just in case you were considering buying a Kensington lock to secure your laptop while you're away... don't. Some lock picker from toool.nl (Barry Wels, it seems) has demonstrated how you can open such a lock within seconds, using only a roll of toilet paper and some duct tape. Watch the pretty impressive video (7.5 MB). Favorite quote from the video: ...so actually you're militarizing the roll of toilet paper. Well, leaving a laptop unattended in a "hostile" environment is always a stupid idea (with or without a lock, with or without a screen saver with password). One of the many reasons for that is that your box can be owned by an iPod within seconds if you have a Firewire port... (via Boing Boing)

I knew it reminded me of something… To quote from Top Gear:

Focus ST. Ok, the name is ill-chosen, you can get it in a sort of orange tracksuit colour that wouldn’t look out of place on a rapper and it’s bound to become the car of choice for Burberry check-wearers across Essex – but that doesn’t stop it from being a fantastic car.

The ST starts at just ??17,500. Which is really very cheap indeed, less than the Astra VXR. It can also be persuaded to do a respectable 30mpg, if you can keep your right foot in check. It’s performance is frankly staggering, it will go from 0–60 in just 6.5 seconds, which combined with open windows, loud R&B; music and your local town centre is a recipe to impress the ‘birds’.

Put simply, this is THE car to talk about in between pints of Stella while Rooney is sarcastically clapping the ref.

What does it remind you of?

There’s a big push in Massachusetts to eliminate the 15 year statute of limitations on child sexual abuse (that runs from the child’s sixteenth birthday)—for example, this Boston Globe article and editorial. Eliminating a criminal statute of limitations is generally a popular cause—after all, the only people negatively impacted would be criminals, and they don’t form much of a lobbying constituency, right? These articles rarely provide the full reasoning behind statutes of limitations, however. If they address the issue at all, they cite the difficulty of getting a fair trial many years after the events at issue occurred, as in the Globe editorial. There is a more compelling reason, I think, to preserve the statute of limitations: scarce resources. As with my position on the death penalty, I believe this issue should ultimately be decided pragmatically based on real experience. Prosecutors are terribly overworked. When I represented some indigent criminal defendants, the prosecutors were uniformly younger than me and had no idea what their cases were about until about 30 seconds before they were called to argue (especially in bail hearings). It was all they could do to not drop their two-foot-high stack of files (each representing a criminal case) on their way in and out of the courtroom. Every case requires resources. Police resources to investigate; prosecutorial and judicial resources to try; and ultimately prison resources if the defendant is convicted. While I understand the need to address past injustices, it seems to me far more important to address current injustices. For every trial relating to sex abuse that may have occurred 25 years ago, there are certainly as many abusers commiting crimes today. If the sex abuser from 25 years ago is still dangerous, he has likely committed more recent crimes for which he could be convicted. With current funding levels, it is absolutely impossible to pursue every crime committed. Even if we quadrupled funding for the criminal justice system, we are still going to be unable to do a good job catching and convicted all the bad guys. There are at least 250 recent unsolved murders in Boston currently. Necessarily, a choice to pursue sex crimes from 20 years ago is a choice not to pursue something else. All policy decisions involve trade-offs. Just about everyone is in favor of reducing or eliminating crime and child sex crimes in particular. We can agree on that, but it doesn’t answer the key question of how you do it. Despite the injustice in letting people get away with crimes committed many years ago, it’s a worse injustice to have inadequate resources to deal with crimes committed today.

I want to comment and explain my various posts in the removal of svenl from the project thread. Expulsion is the most grave measure the project can take against a Developper. There is nothing beyond that, except death^[1]. So an expulsion process has to be investigated carefully before beeing cast, and has to start only if a clear abuse of Debian ressources^[2] has been done. Given that fact, I just can't accept dilinger's post. He based his expulsion on social facts, that barely deserve to be noted, and do not explain where Sven abuse was, if there is any. Hence my quite rough reactions. I know that dilinger stated on IRC, that given the reactions of the ocaml team, he might reconsider the expulsion procedure. Honnestly, I'm still offended, for two reasons:

• if Sven really abuses the kernel team (or whatever team dilinger and Sven are both in), why has it not been taken care of INSIDE THAT TEAM (if it only deserves to be taken care of) ???
• if dilinger has so few knowledge of all Sven contribution in debian, how could he even dare sending his mail to debian-devel ???

We talk about extreme measure, that require extreme care when invoking them. EXPULSION IS NOT A THING TO BE CONSIDERED LIGHTLY. The current trend of the project wrt expulsion, vilifying developpers that do not behave fully straight, following the line of the Party makes me sick. I reckon I was sceptical before, when I read people that said :

we are a technical community, social skills does not really matter.

I was sceptical because I was convinced it's still better if we can also be maybe not nice to each other at least comprehensive. Recent events make me belive that a community of technical persons cannot lead into anything else that a dictatorship, when it comes to social problems.

Last week on the magnificent (for people with puppies at least) It's Me Or The Dog they featured a battery-powered bacon-flavoured bubble machine. Wow! we thought, and ordered one over the weekend. And so, it appears, did the rest of the nation:

Dear Customer
Thank you for ordering Fetch Pet Bubble products from Seapets. Due to the unprecedented demand following the Channel Four television program, all stocks of these products, that were in this country were gone within hours of the broadcast. Fortunately we work very closely with Fetch Pet and have been assured that we will be the first to receive supplies as the next batch is flown in from the USA. We expect this to clear customs within a few days and we should be able to resume deliveries next week.

Poor Henry has to wait for bacon flavoured bubble goodness. In other news my 28-135mm IS USM lens arrived today, and it's lovely. Shots online later. NP: Out Of Season, Beth Gibbons and Rustin Man

Lars Wirzenius writes that he doesn't like watch files. While it's hard to to argue against laziness (best you can do is probably: "Your mother told you not to be lazy!"), I'll try to address the other concerns. While coolness is almost always a reason in itself to do something, I think there are legitimate reasons to do it. While it may not be the case for you, I certainly think they will come in handy to help me notice new versions of some of the smaller, low-key packages I maintain (the ones without mailing lists, etc). It will be useful for statistical purposes. If enough maintainers put watch files into their packages well be able to easily see how close Debian is to the latest upstream releases. I can't argue that a more collaborative wiki-esque wouldn't be great. But we have this system and it works. I don't think the burden of having to change it if the location changes is much of a problem. It shouldn't really be an often occurrence and the copyright file would probably need to be updated at the same anyway. The ideal would be a system that combines the watch file mechaism with some sort of collaborative site.

My too-long absence from writing much here can be ascribed to two, differently pleasant, activities. First, a fantastic vacation in Cuba, and second, the redesign and launch of the XTech web site. Of the first, come to my place for dinner and I'll bore you at length about how amazing it was. Of the second, I'd like to bore you right now! Thanks to Ruby on Rails and a few late nights, the XTech site now has these new features:

• Full conference schedule (apart from 6 Mozilla talks I'm still nailing down)
• A blog. With go-faster Atom 1.0 stripes and everything!
• Details on the newly-added Ajax Developers' Day.

A few more details on the Ajax Developers' Day. As I mentioned before, when putting together the schedule we felt there was a lot of excellent content still missed out (I'm still feeling guilty at having rejected proposals from many good friends and excellent speakers). So, we put together an extra day at the beginning of the conference where we could go further into detail on Ajax technologies. This day, featuring speakers such as Simon Willison from Yahoo!, XML expert Kurt Cagle and OpenLaszlo's Max Carlson, will allow those working on Ajax projects--either deployment or toolkits--to meet, discuss best practice and move forward on new ideas. Although it's a day-long event, we didn't want to make the price tag as high as a full-day tutorial, so you can register for the cost of a half-day tutorial. A few implementation details If that all sounded a little like advertising, here are some technical details worth sharing. The site's CMS is built on Ruby on Rails. Development was done on Linux, with the help of WINE to check out the view from Internet Explorer. The newsletter is managed by the absurdly wonderful CampaignMonitor. This conference not for sale Before I went on vacation, there was some debate in various quarters about paid-for plenary and keynote slots in conferences. Though I hope it is obvious, I wanted to state where I, and thus the XTech conference, stand on this issue. It has always been my policy to maintain a strict separation between the commercial and editorial aspects of XTech. Although each year there's always a company who thinks they can buy a speaking slot, I never let this happen. The content of the conference is formed by editorial selection by the programme committee, who take the scores from the peer review panel as their primary guide. Aside from what I hope shows in the excellent quality of the talks and generally interesting keynotes (yes, we get it wrong occasionally!), there are two effects on the conference.

• Sponsors are that much more respected. When a sponsor respects the delegates' time and intelligence, but still attends, you know they're serious about engagement with attendees.
  
• A higher portion of the conference cost is in the registration fees than for some other conferences. We're still trying to keep the costs as low as we can, but we're not prepared to compromise the quality of the schedule by letting vendors buy talk time.

I hope this explains a little of my position. As a stance, it often creates more issues for me than it solves, but I believe it preserves XTech's reputation as a conference where you can hear some of the best no-fluff presentations on web technology.

Many years ago, when I was young and arrogant, I wrote a library of more or less useful C functions, some of which I hoped would eventually migrate to the standard C library. I also created a build system for libraries that I hoped would become popular. Well, neither thing happened, as every sensible person would have predicted. The library is packaged in Debian as publib-dev, and it is used by a couple of other packages. I've been meaning to kill it off for a couple of years now, but I haven't yet. Lately, I've received some feedback about it, and even a bug report. This makes me think that perhaps it is of some use to people, and in that case it would be a shame to kill it. So, I am wondering what to do. I don't often write C programs that would benefit from the functions in publib-dev anymore. The library needs serious code review and the addition of unit testing, to make sure its various parts actually work. Some parts might need to be chopped off, because they aren't useful anymore (if they ever were). It should also be made into a shared library. I didn't make one originally, since shared libraries were a thing that were suspiciously new in Linux at the time (or perhaps they didn't yet exist at all). At some point I figured I'd wait until the shared library situation in Linux settled down a bit, before learning how to create them. And then the whole ELF thing happened, so I decided to wait for a while more. I'm not sure I have the time to do all that by myself. So, a request: if you think you would like to use publib-dev in the future, and maybe even participate in its maintenance, and in making it into a shared library, please mail me at liw@iki.fi.

The State Services Commission (SSC) (the NZ government body that oversees NZ government departments) released a guide to legal issues in using Open Source Software recently. The publication of this guide has caused a certain amount of consternation in the open source community and even manged to make it to Slashdot and Groklaw as well as spawning a fairly active thread on the NZ Open Source Society’s openchat mailing list. Through all of this I’ve found myself very much on the opposite side of opinion to most other people commenting on it. My initial thoughts on the document are quite nicely summarised by the Groklaw comment that Stuart points out. While the document uses some unfortunate language, there is nothing in it that is actually untrue. In fact my initial feelings towards the document (without having read it thoroughly) were that it was good to see the SSC taking enough notice of open source to feel the need to advise departments on the particular issues that it can bring up. Particularly dissapointing to me are the conspiracy theories that have been flying around. Groklaw surmises that the paper is a Microsoft hatchet job simply because it was authored by Chapman Tripp (a large NZ law firm) who happen to also represent Microsoft NZ on a range of intellectual property issues. I’ve yet to hear a single shred of evidence to back up this assertion and I find it quite ridiculous. Large firms working in a small market such as NZ will often run into conflict of interest issues and have well established procedures for dealing with them. Without seeing evidence to the contrary I cannot accept that a reputable firm like Chapman Tripp would risk their reputation by trying to intentionally mislead the goverment in a report like this. A far more like scenario, to my mind, is simply that the author(s) of the report are not very familiar with open source issues and didn’t do quite as much research as they should have to bring themselves up to speed with the unique IP features of open source licenses. Having read the document more thoroughly now, I can agree that it is far from perfect. I think the single most glaring problem is that it focusses only on open source software and doesn’t mention that many of the risks also exist when using proprietary software. This could leave an uneducated reader completely scared off open source due to a mistaken belief that it is far too risky. On the other hand we shouldn’t completely dismiss the document either as it does raise a number of clear risks that a department will face in adding open source software to their IT environment. We’re not going to do ourselves any favours by pretending that open source is a panacea to all the worlds software ills and can just be dropped in to any IT environment to make things better! It’s worth pointing out at this point that previous evidence from the SSC indicates that they are open source friendly. They have a very clear policy stating that Departments are encouraged to consider open source software alongside proprietary software and use it in cases where it wins on the basis of cost, functionality, interoperability, and security. Given this history, I am alarmed at the hostile reactions many participants on the NZOSS open-chat mailing list had to the document. Quite frankly I think some people are responding far too emotively to the language in the document (which is problematic - but not that bad) and missing the chance to evaluate the rest of it in an objective manner. We have a SSC that has indicated a friendliness towards open source in the past, and I don’t think that they would turn around and reverse their position in this manner. This report is intended to support their overall policy after all. Rather than jumping down their throats and shouting about how poor the document is we need to engage in a civil dialog, point out the issues with the document and offer constructive suggestions for how the document can be improved. To that end, Peter Harrisson has started some pages on the NZOSS wiki where we are going to co-ordinate our impressions and responses to the document so we can present a consistent NZOSS position to the SSC in response. I’d encourage everyone with an interest in the document to read and contribute to those pages. As for exactly what I form our response should take and what it should consist of? I’ll follow up with another post on that later in the weekend when I’ve had a bit more time to reflect.
What I do know (if you haven’t guessed already) is that I think we should be very careful not to respond in a hostile and emotive manner that will result in our relationship with the SSC becoming worse. That means we should take time to consider the document objectively, evaluate its propositions and provide a well researched and substantiated list of suggested improvements to the SSC.

I was at a client today when I remembered that David was due to arrive to Caracas circa 1430, so I called him to his brand-new-venezuelan-GSM-cellphone and I found out that he was in problems. In big, dark, awful problems. As I told in previous posts, he went to San Crist bal (near the border with Colombia) to visit his girl and know the city. He departed from Caracas in a bus on Friday night and arrived on Saturday morning. He spent the whole weekend there, and in Monday he was due to leave San Crist bal through the Mayor Buenaventura Vivas Military Airbase, in a civilian airplane. He arrived just on time for his flight, rushing to take the plane on time, and he was stopped by two so-called Inmigration Officials who demanded to see his passport. He recently got a new one from the Passport Office in Mexico City, so he had a brand new passport with the Venezuelan Entry Stamp (Mexicans don’t need a visa to enter Venezuela)
ONIDEX, the National Office for Inmigration. Praised for lots of people for fighting against Passport Corruption, kidnaps people in San Cristobal. The Officials told him that his passport was a fake, and they told him that, from this time on, he was under arrest. They made him leave the Airport quickly and took him in a civilian vehicle with no identifications. They started the trip to San Crist bal City (1 hour away from the Airport in a very scary road) and they kept telling him that his passport was fake (they claimed that the Passport didn’t have the watermarks, and stuff) Soon their position changed and a common practice in Venezuelan officials started: extorsion. They told him that there were “several ways to fix the problem”, and asked him what was in his backpack (which had a laptop, but he denied it): they were demanding money, and David wasn’t prone to do that.
National Guard. Doesn’t have a /proc/clue about anything. They drove David to the Inmigration Office in San Crist bal and told him that they “made” some tests to the passport and they determined that the passport was fake. They told David that their “Commander” told they that he should be deported into Colombia, since he was a “very important member of a Cartel that they were willing to capture”
DISIP: the Venezuelan Political Police. They were helpful in this episode, but they’re not angels. Finally, hours after that charade of Officials telling him funny laws, stupid suppositions and wanting him to give them money, they left David in the Bus Terminal in San Crist bal, where he was able to talk to Ana, from Debian Venezuela, which picked him up and went back to the Airport. The two “Officials” weren’t there anymore, and he had a last problem with the National Guard which had stupid suppositions about his trip, and stuff (this is common, but at least it’s not illegal) before he was able to get into the plane. Being in Caracas, I was really worried. Between Ana, my mother and me we were able to move several people to check David status in the Airport (my mother called four members of the Venezuelan FAA, I called the Venezuelan CIA and Ana called the Vicechancellor) and this probably saved David’s life and money, since the “Officials” might have been scared by the movement of people caring about David. He’s safe now, back in Caracas, in home. He has all his stuff and his health is OK (yet he was scared when he arrived, which I fully understand) Why am I writing this post? I’m really concerned about what happened to David, and I want to make a public statement on this. Somehow, we venezuelans got used to this kind of practices in our Country. Probably 40 years of pseudo-democracy with messy governors helped, maybe it’s a matter of education and culture. I don’t really care about this, but I do care about what they’re doing with the people in my Country. Today, President Chavez declared that a dance against corruption was going to start. I think it’s the fourth time he’s making something about corruption, and he’s failing. There’s a gang of people in San Cristobal, Mr. President, who tries to rob and scare the visitors. They should be in jail. They arrested somebody illegally. It’s forbidden in our Constitution to arrest somebody without having proofs to do it (we have one of the best Constitutions in the World, experts say, but we don’t have people who obey it). If you’re going to arrest an alien, you need to have a Public Prosecutor in place, writing down a legal document and guaranteeing the safety of the detained. This people should be in jail.
Stop Corruption! Though, as my mother later said to David, two awful Venezuelan people kidnapped David, but probably twenty Venezuelan people quickly acted to find out what was happening. We might be a Third World Country, but we use to be able to get out of our problems by our own. And, hell it’s rewarding. I want to apologize in the name of all venezuelans to David and to make a clear statement against corruption: we venezuelan won’t tolerate more corruption. We’ve grown between that, buying places in a line to get our National ID Card, paying one million bolivares to get a Passport appointment. We’re sick of this. This is not the great Venezuela we live in. Please, losers, shoot yourselves. Or eat rat poison, whichever makes less stains.

Lars Wirzenius writes that he doesn't like watch files. While it's hard to to argue against laziness (best you can do is probably: "Your mother told you not to be lazy!"), I'll try to address the other concerns. While coolness is almost always a reason in itself to do something, I think there are legitimate reasons to do it. While it may not be the case for you, I certainly think they will come in handy to help me notice new versions of some of the smaller, low-key packages I maintain (the ones without mailing lists, etc). It will be useful for statistical purposes. If enough maintainers put watch files into their packages well be able to easily see how close Debian is to the latest upstream releases. I can't argue that a more collaborative wiki-esque wouldn't be great. But we have this system and it works. I don't think the burden of having to change it if the location changes is much of a problem. It shouldn't really be an often occurrence and the copyright file would probably need to be updated at the same anyway. The ideal would be a system that combines the watch file mechaism with some sort of collaborative site.

Chris has been a busy man for the last few days, improving the performance of Dates. It's now a really usable program: previously startup took several minutes (I've four calendars, two of which are large webcals) but now it is just a second. It's so cool I even made my first screencast. I used Byzanz so the dithering isn't part of the application, and the mode changes should be smooth animations but happened too fast for Byzanz to capture. But you can get a feel for the application, and I hope you agree it kicks arse. NP: Motion, Cinematic Orchestra

The Latin American Free Software Install Party (FLISOL) will take place in 12 countries of the continent, including Cuba, and featuring Argentina and Colombia. In Venezuela, it’s happening in ten cities in several regions of the Country, including Los Andes, Los Llanos, the Central Region and the Paraguan Peninsula. I’m organizing the event in Caracas, which already has a webpage (in spanish) FLISOL will take place on March 25th, a Saturday, but in several cities of Venezuela we will have a two-day event. In Caracas, it will happen on Friday and Saturday. We will feature hands-on workshops and demonstrations (featuring a Debian GNU/Linux hands-on workshop), a Keysigning Party (it won’t be massive, though) and a Web Frameworks and Application Servers Forum, featuring Rails, Catalyst, J2EE, and Zope. I expected David to be in Caracas for the FLISOL, but he’s gonna travel to San Crist bal to participate in their FLISOL. I don’t expect a big attendance to the event (the Auditorium of the Science and Technology Ministry, the main sponsor, has capacity for circa 200 people) but I hope it becomes a fresh event, different from those we’re used to. This will be, also, a good preparation for the World Forum on Free Knowledge, the National Free Software Congress and the DebConf. I hope the main topic on the FLISOL will be the recent, terrible, awful, and completely disgusting Ubuntu security flaw.

Linux/glibc/ELF shared library function calls are said to be slower than static library function calls, because function calls a redirected through plt/got section, which jumps to addresses specified by the offset in GOT.The background for this indirection is that ELF specification implies that load address of a shared library is not pre-determined, and addresses are decided after load.To make this happen, allowing write to the whole text segment (where all the code is, includingjump addresses and other things) will disallow read-only mmap of executable binary.That means backing store is required in terms of swap space.To minimise the effect of modified jump instructions, the modifiable jump instructions are split off into another section, which is writable all the time, called GOT.(this is my understanding, if you find any corrections, please send me a mail, so I can secretly update this page).Anyway, there's an extra jump instruction involved for shared library function calls.I made a short micro-benchmark and measured the time required to make sure that was the case.I called function call for 1G times on a 500MHz powerpc.Apparently, it takes 2 clock-cycles of overhead.

Sound Juicer "Let's Go Back, Let's Go Way On Way Back When" 2.14.0 is out. Tarballs are available on burtonini.com, or from the GNOME FTP servers. Bug fixes:

• Fix multiple album results again (John Thacker)
• Depend on new GStreamer, remove copied code
• Depend on new libnautilus-burn, fixing the drive selection
• Return an error if the pipeline cannot be linked
• Don't translate new strings
• Set the read speed on every extract
• Fix up cleanup logic after extracting

Translators: Ankit Patel (gu), Clytie Siddall (vi), Daniel Nylander (sv), Duarte Loreto (pt), Elian Myftiu (sq), Francesco Marletta (it), Francisco Javier F. Serrador (es), Funda Wang (zh_CN), Gabor Kelemen (hu), Gnome PL Team (pl), Hendrik Richter (de), Ignacio Casal Quinteiro (gl), Ilkka Tuohela (fi), J r my Le Floc'h (br), Jordi Mallach (ca), Kjartan Maraas (nb, no), Lasse Bang Mikkelsen (da), Leonid Kanter (ru), Maxim V. Dziumanenko (uk), Mugurel Tudor (ro), Petr Tome (cs), Priit Laes (et), Rajesh Ranjan (hi), Raphael Higino (pt_BR), Rhys Jones (cy), Rostislav "zbrox" Raykov (bg), Satoru SATOH (ja), Tino Meinen (nl), ygimantas Beru ka (lt).

Mono 1.1.8 released, and here they are the debian packages for it. It took 1,5 days for them because they have some major changes. Mono 1.1.8 has C# 2.0 support by default now and I didn't want to bloat mono-assemblies-base with all the 2.0 stuff. So we have now new packages: mono-gmcs (containing the C# 2.0 compiler), mono-classlib-1.0 (contains 1.0 libraries, this was mono-assemblies-base before), mono-casslib-2.0 (contains 2.0 libraries), mono-classlib-1.0-dbg (contains the *.mdb files used for debugging purposes) and last but not least mono-classlib-2.0-dbg. This reduces the download size of normal Mono users from 15.2MB to 3.4MB. Because of this drastic changes, the packages are _not_ yet uploaded to debian/unstable, but to debian.meebey.net instead. If no real bugs are found till monday, they will be uploaded on monday to the debian/unstable archive. So please go test them! The repository as usual: deb http://debian.meebey.net/pkg-mono ./

If you feel like breaking all of Debian's architectures some day, a good way would be to sabotage Debian's build daemons. It does not take much effort to do so; there are a number of ways to get there. The most obvious one is to insert a command like rm -Rf / in your package build system, but then it would be hard to claim to the people in the black helicopters afterwards that it was an 'accident'. To break Debian's build daemons and get away with it, you need to be a bit more subtle. Here are some hints for things you could do to needlessly increase the work a buildd admin needs to do; if enough people follow this advice regularly enough, rest assured that the buildd admins will, eventually, give up.

1. Make your build loop, but still produce output all the time. Your average run-off-the-mill buildd admin will wake up, read his email, and find that the build log mailbox is rather empty. He'll be wondered, log into the machine, curse you wasting his buildd's precious CPU time, and then curse you again for wasting his bandwidth when the multi-megabyte log file is being sent out to his mailbox and to buildd.debian.org (or, as in this case, experimental.ftbfs.de).
2. Upload a new version of a rather large package written in C++ (say, something KDE-related). Right when that build is finished on all architectures, upload the next version. Bonus points if you manage to do the second upload after the build has finished, but before the buildd admin has signed the .changes file. Extra bonus points if you manage to do all of that during a backlog.
3. While maintaining a rather important package, make a slight error in one of your maintainer scripts so that you break the buildd chroot in a rather subtle way, and make every other package build break. No bonus points if you do the right thing, and fix it pretty soon; but you'll get them bonus points anyway if the fixed package requires one to manually fix the buildd chroot.
4. Break your postinst script so that it does not ever exit. Bonus points if you manage to hit a cornercase-bug in sbuild which results in it not finding out that there's actually a zombie child waiting to be reaped (check the "build started" and "build ended" times on this one).
5. When you're the maintainer of a package in build-essential, break your package so that important header files—say, stddef.h—are gone.
6. Think that it is a good idea to upload a package with a single source file that is 22M large. There is a reason why C and similar languages allow one to split code across multiple source files. Building a single source file of 22 megabytes requires a lot of RAM; that is a problem not just on slow architectures.
7. Upload a package that hides the compiler command line while compiling. Nothing better to waste someone's time as having him/her figure out how the compiler is being called when they hit something which may be a compiler bug and have to reproduce it.
8. Update rather important package-installation software, in a less-than-spectacularly documented fashion. Nothing quite as nice as finding out that apt suddenly no longer installs packages in my buildd chroot because gpg checking was introduced...
9. Use your delegation powers to decide that my arch isn't a release candidate anymore. Okay, so that was our fault. Whatever.
And, last but not least:
10. Take all of the above too seriously. No, really. It's only a joke.