Version 2.6.18 of the kernel contained a small(ish) change to <linux/nbd.h>:

--- nbd.h	2006-10-17 19:53:55.000000000 +0200
+++ /usr/include/linux/nbd.h	2006-09-20 05:42:06.000000000 +0200
@@ -37,19 +37,28 @@
 /* userspace doesn't need the nbd_device structure */
 #ifdef __KERNEL__
 
+#include wait.h>
+#include mutex.h>
+
 /* values for flags field */
 #define NBD_READ_ONLY 0x0001
 #define NBD_WRITE_NOCHK 0x0002
 
+struct request;
+
 struct nbd_device  
 	int flags;
 	int harderror;		/* Code of hard error			*/
 	struct socket * sock;
 	struct file * file; 	/* If == NULL, device is not ready, yet	*/
 	int magic;
+
 	spinlock_t queue_lock;
 	struct list_head queue_head;/* Requests are added here...	*/
-	struct semaphore tx_lock;
+	struct request *active_req;
+	wait_queue_head_t active_wq;
+
+	struct mutex tx_lock;
 	struct gendisk *disk;
 	int blksize;
 	u64 bytesize;
@@ -68,11 +77,11 @@
  * server. All data are in network byte order.
  */
 struct nbd_request  
-	u32 magic;
-	u32 type;	/* == READ   == WRITE 	*/
+	__be32 magic;
+	__be32 type;	/* == READ   == WRITE 	*/
 	char handle[8];
-	u64 from;
-	u32 len;
+	__be64 from;
+	__be32 len;
  
 #ifdef __GNUC__
 	__attribute__ ((packed))
@@ -84,8 +93,8 @@
  * it has completed an I/O request (or an error occurs).
  */
 struct nbd_reply  
-	u32 magic;
-	u32 error;		/* 0 = ok, else error	*/
+	__be32 magic;
+	__be32 error;		/* 0 = ok, else error	*/
 	char handle[8];		/* handle you got from request	*/
  ;
 #endif

Which meant that the userland NBD utilities would not build against that anymore. The Debian packages are unaffected (they ship their own nbd.h since they need to build on non-Linux ports, too), but that doesn't mean we can leave it like that. The first hunk is unimportant, as it's enclosed within an #ifdef __KERNEL__. The others represent an interface change: rather than having u32 and u64, they come with __be32 and __be64. Nothing that can't be fixed with a few #define lines, but still something that had to happen. So today I released nbd versions 2.7.8 (from the outdated 2.7-branch), 2.8.7 (from the current stable and supported 2.8-branch), and 2.9.0-test3 (from the current development branch) to sourceforge, and released version 1:2.8.7-1 to Debian unstable. I'll probably also release 1:2.9.0-test3-1 to Debian experimental "some time soon", but not just yet. Apart from the obvious #define lines, the 2.9.0-test3 release also fixes some issues (in contrast to -test2 which was a bit of a crashing horror, -test3 actually works) and has revamped multi-file support. Most of the changes in -test3 (in fact, most likely all of them apart from the #define lines) were done by Phillip Hellewell, whom I owe a beer if I ever see him. Occasionally, the 2.9 line has some extra code and features that aren't available in 2.8, such as configuration file support and the ability to serve multiple block devices from one nbd-server parent process. Check it out if you have a chance and/or are interested. On top of that, the 1:2.8.7-1 release also contains some fixes in the debconf stuff, that close 3 bugs. Am I cool or what? Nah.

I took on the daunting task of deploying a content management system for my fraternity; most of the concepts are pretty clear already (wiki plus moderation system), but we also need database lookups on some pages. The general idea now is to have someone with database knowledge set up views, and to use a template in the wiki to reference it, but in a number of cases, the people writing the wiki pages, who are not used to working with databases, might need to adapt the query (limit something to a time period, select fields, etc.). So I'm looking for ideas for a presentation layer that eases writing selection and sorting criteria for non-computer-scientists, without dumbing it down too much (after all, the target user group comes from an academic setting, so abstract concepts are not a problem, but a steep learning curve is).

I spent the weekend cleaning up my vanity site, CSSizing it and such. Since I moved a few documents around, I wanted to make sure that they were still findable. Most of the site wasn't PHP before (it is now for common navigation / footer includes, etc.) so I had the challenge of how to send people to the new pages.

It's most common to find "refresh" pages, ones that you go and they redirect you to another location with a 0 timeout (and often a cute little notice that says if your browser doesn't DTRT, you should click the link). There doesn't seem to be another meta tag that could do the redirect trivially.

This is another case where PHP wound up being useful. Since I moved my weblog from my homesite to LiveJournal a while ago to let comment spam be Someone Else's Problem, I had that and a whole directory of stuff underneath it that was no longer there.

jbailey@titanium:~/web$ cat weblog.php
<?php
header("HTTP/1.0 301 Document Moved");
header("Location: http://jbailey.livejournal.com/");
exit();
?>

Now works for http://www.raspberryginger.com/jbailey/weblog and any of the directories underneath it. Another side trick to this is that if I had a file foo.html, I can create a foo.html.php file with the same sort of thing in it. Apache's automatic extension tracking will find the .php file and sort it out automatically.

One thing I did discover is that if I have "weblog.tar.gz" and "weblog.php" sitting side by side, apache will prefer the .tar.gz file. *sigh*

I get translations for dctrl-tools from multiple sources: one translator has direct commit rights to my darcs repository, others bug me; still others use Rosetta (dctrl-tools upstream). On top of this, I just found out that there are active translators working on the Ubuntu branch of dctrl-tools in Rosetta. There have been several cases of different sources of translations having different parts of the programs translated, so it would make sense to combine them somehow. Dear LazyWeb, how do I combine translations from all these sources?

The weekend of the 14th-15th October saw my third BSP in as many weekends, this time in Munich. Andreas Barth was in charge of the organisation, and the LiMux development team were kind enough to host us for the weekend at their offices in the centre of the city. Andi, Zobel and I headed into the office early on Saturday morning, ready to start hitting RC bugs. Others joined us during the morning, and we got to a total of 10 people working on fixing bugs. Personally I looked through many of the bugs listed on Andreas' page. It was heartening to see that a very large number of the RC bugs were already well in hand, with patches available and in lots of cases uploads already made. I spent some time looking into #389287, #392398, #389375 and #262440. I also helped out several other developers with their own bug fixes, giving out accounts on my wide range of machines at home so that they could debug on different architectures.

We worked late into the evening, ordering in pizza and then later cooking in the offices. I moved onto some more debian-cd hacking later on, making real progress and getting almost to the point of having my multi-arch CDs working. As always, there was a lot of discussion about the general issues in Debian, especially the 4 GRs that were due to finish that evening. On Sunday morning, things started slightly later as we took breakfast at the office. There was more discussion of the GRs, and the results were generally well received by the group. We continued looking into the RC list; I investigated #389434, but struggled to make much progress. At lunchtime, we quickly(!) headed into the city to see the famous Glockenspiel at the city hall, and went for a quick tour of the historic city centre so that us non-locals could see something of the city outside of the office. We returned and picked up on the bug-killing for a couple of hours. Then the LiMux guys showed us some of their work, and gave us a demo of the project. More on that later... Unfortunately, I had to head back for my flight comparatively early this weekend so I couldn't stay around for very long after the demo. Despite the last-minute attempt by an S-Bahn ticket machine to delay my trip to the airport, I got back without incident and even landed early at Stansted. The Germans I met this weekend were very serious about getting work done, and their efforts are much appreciated. With more people helping to reduce the RC bug counts, we should have no problem releasing Etch in December. Let's keep up the good work...! As always, my meagre attempts at photography are online now.

There are a several events coming up where I plan to hold my Shell Quoting Talk: First, there will be the BarCamp Zurich on October, the 28th at ETH Z rich HG and then there will be the 8th Linuxday.at on November, the 18th at the HTL at Dornbirn (Vorarlberg, Austria) organised by the LUG Vorarlberg. It’s also possible that, in addition to the Shell Quoting talk, I’ll also give a talk for beginners about Commandline Helpers. (Probably all the talks will be held in German.) I’m quite curious on both events, for very different reasons. On the one hand, a BarCamp is something completely new for me and it sounds like a very interesting mixture of a real life Wikipedia meeting and a flash mob to me. On the other hand, this year’s Linuxday.at will have several new facettes for me: First there were several changes in the organising team, so I wonder if and in that case how much this will change the face of the event. Then it’s the first Linxuday.at since I live in Zurich, which means it’s the first Linuxday without 1000km travelling during that weekend, so I also have some time to meet friends in the area in advance to or after the event. Yeah!

So I went out to a independent short film showing down in the mission today. I was able to put my bicycle inside the small theatre. I went down because one of the shorts that was supposed to be shown is called "Toddler Zombie Sluts", now with a title like that, I curious what is up. "Toddler Zombie Sluts" was not shown, instead I saw a music video for the song "My Pussy is Magic".

The other thing I learned is that going up Duboce from Castro is a rather steep section of road. I wasn't able to bike all the way up it. I'll have to work on that.

I moved up to the hippie district in the city today. The move wasn't too bad (thanks Katelyn), but Jeff's couch was a pain in the ass. It's in the living room at least.

On the way up to our place, taking a few things that didn't fit in the U-Haul, we drove up Castro St. On Castro we came across a group of men in long pink skirts twirling around. This city has some crazy stuff.

You might think that an organisation of over 1000 very smart people could do better. I certianly thought so -- until I sat through one of the Debian debates on -vote. Many of the participants acted the age they must have been when they first learned the mnemonic "Garbage In, Garbage Out." They argued, often quite belligerently, from their own narrow perspectives, unable (or unwilling) to see the situation from anybody else's point of view. [...] bureaucrats, not programmers.

Paraphrased from Rick Fienberg's editorial in November's Sky & Telescope, describing the IAU Pluto definition. The parallel seems amusing, especially since both cases involve silly votes.

One issue that has been the topic of some pointless discussion is whether a mail server should have an A record or an MX record. Mail can be delivered to a domain that has no MX record but simply an A record pointing to an IP address. But the most common practice is to have an MX record pointing to the name of the machine that serves the mail. A common use for this is to have a bulk mail hosting machine with multiple MX records pointing at it, which then allows you to have matching forward and reverse DNS entries for the machine name.

If you have no MX record for a domain then Postfix will do the following DNS requests:

IP postfix.34245 > DNS.domain:  3448+ MX? example.com. (32)
IP postfix.34261 > DNS.domain:  50123+ A? example.com. (32)

If you have an MX record then it does the following:

IP postfix.34675 > DNS.domain:  29942+ MX? example.com. (32)
IP postfix.34675 > DNS.domain:  33294+ A? mail.example.com. (37)

Now if there are multiple domains on a bulk mail hosting system then the A record might already be in a local cache on the sending machine, so having bulk mail hosting with MX records may reduce the number of DNS lookups, with the minumum number of lookups being half plus one.

If there is no bulk mail hosting then an MX record would still offer some slight benefits if the positive responses are cached for longer than negative responses. This would mean less lookups which gives faster and more reliable delivery of mail plus being more friendly to the net. I don't know what the cache behaviour is in this regard so I'm not sure if this would actually give a benefit (I'm sure someone will comment with the answer).

Now regardless of these issues I think that using an MX record is the better option. It's what most software expects and saves you from the excitement of discovering corner case bugs in various software that's out there on the net.

Just landed a sweet feature for bzr: dotted decimal revision numbers. There is a sample log (warning its 2Mb) where you can see this in all its glory. A sneak preview is here:

------------------------------------------------------------
revno: 1986
committer: Canonical.com Patch Queue
Manager<pqm@pqm.ubuntu.com>
branch nick: +trunk
timestamp: Wed 2006-09-06 00:33:01 +0100
message:
  (robertc) Add TestCase.applyDeprecated, a common-case
helper for testing deprecated functions.
    ------------------------------------------------------------
    revno: 1982.3.3
    merged:
robertc@robertcollins.net-20060905231840-bd95f673d0205a81
    committer: Robert Collins <robertc@robertcollins.net>
    branch nick: applyDeprecated
    timestamp: Wed 2006-09-06 09:18:40 +1000
    message:
      Change raise AssertionError to self.fail in the new
applyDeprecated test support method.
    ------------------------------------------------------------
    revno: 1982.3.2
    merged:
robertc@robertcollins.net-20060905230133-2c68611e38fd7922
    committer: Robert Collins <robertc@robertcollins.net>
    branch nick: applyDeprecated
    timestamp: Wed 2006-09-06 09:01:33 +1000
    message:
      New TestCase helper applyDeprecated. This allows you
to call a callable
      which is deprecated without it spewing to the screen,
just by supplying
      the deprecation format string issued for it. (Robert
Collins)
------------------------------------------------------------
revno: 1985
committer: Canonical.com Patch Queue
Manager<pqm@pqm.ubuntu.com>
branch nick: +trunk
timestamp: Tue 2006-09-05 23:13:00 +0100
message:
  (robertc) Add symbol_versioning.deprecation_string, a
helper for establishing what a deprecation warning for a
symbol, version-format pair will look like.

This is really nice for users, because it lets them address revisions in a somewhat more predictable manner than the UUID each revision has. This feature is in the mainline now, look for bzr 0.12 to be able to use it - or grab bzr.dev now!

After asking the lazyweb on how to seek on gzip streams I got a very useful and comprehensive reply by Paul Sladen. As my previous searches on this topic didn't turn up to much useful things I'd like to publish Pauls reply (with his approval) here to help other people having the same problem as well: In a later mail Paul also added the following: Thanks Paul!

There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla camp, that I, as the Firefox co-maintainer, the xulrunner maintainer, and (soon) Seamonkey iceape co-maintainer, have to rectify. They broke the –enable-official-branding flag
Half-true. We just replaced Bon Echo/Deer Park with Firefox at the appropriate places in the build tree so that we could have Firefox with the “unbranded” logo instead of the official logo, as Gervase Markham gave us authorization for. You’re still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken. Firefox logos being subject to trademarks, Debian thinks they are not free.
Trademark and copyright are different things. Mozilla has unnecessarily given a non-free license to “clarify” the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period. Debian isn t properly collaborating with Mozilla , sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum’s blog)
Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in… that’s exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming. The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas’s blog again).
So, let’s dig into our firefox_2.0~rc1+dfsg-1.diff.gz:

• Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
• Changes to fix “make distclean” so that it really cleans the build directory,
• Change not to build the “mangle” utility,
• Change not to call netstat to generate entropy, which is useless on linux,
• Changes to make Firefox build and work on architectures such as hppa, mips, mips64, m68k, ia64, sparc64, alpha, and arm, which the Mozilla guys don’t seem to care much for,
• Change to add a preference directory so that users can put their set of customized preferences in /etc/firefox/pref,
• Change to allow to build flat chrome without the zip utility,
• Change to allow to use system library for myspell, instead of statically linking the bundled one,
• Changes to allow to build s390 binaries on s390x host with s390 toolchain (same applies with x86 binaries on amd64 host with x86 toolchain),
• Changes to work around bugs with the hidden visibility pragma on gcc,
• Changes to make the pango backend actually build correctly,
• Changes to avoid some error messages while trying to create Makefiles from inexistant Makefile.in’s,
• Change to install in /usr/lib/firefox instead of /usr/lib/firefox-x.y,
• Change not to build useless chromelist.txt files,
• Changes to make helper applications with parameters work,
• Changes to allow builds against GTK 2.8,
• Changes to work around an Xrender bug,
• Changes to make the Gecko/yymmdddd string taken from preferences instead of being half-hard-coded (you could change it with preferences, but it would still be set to the hard-coded value at start time ; and you could change it again with preferences…),
• Change to allow mice extra buttons to act as something else than a left button,
• Change to allow to build with -Wl,–as-needed to avoid linking against a whole lot of useless libraries, without losing the link on libxpcom.so which is required by some extensions’ components,
• Changes not to shlibsign the NSS modules at build time, since we’re stripping the binaries afterwards, thus breaking the signature. We do build the signatures later, within the maintainer scripts.

That’s not that many changes, and most of them were taken from either some Mozilla CVS trunk or the Mozilla Bugzilla . And most of those that were not taken from there have been sent, except those that really don’t make much sense outside Debian. So, where are these frozen API changes ? And we’re not properly collaborating, huh ? The Mozilla project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett’s blog) That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I’m not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions. The only main difference now, between the official Firefox and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won’t explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files. Now, a little bit about differences the Mozilla guys don’t seem to care about while they really should: distributions build the Mozilla products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox that is linked against libstdc++6. You are lucky if that setup doesn’t crash. Little extra from comments in Lucas’s blog:
Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla s site.
How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more. Update:
Debian is going to replace Firefox with a GNU fork called Iceweasel
Half-true. For the etch release, Iceweasel will only be Firefox with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name… that’s quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can’t and won’t do more than a rename for the moment. Update 2:
We (Mozilla ) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla Corporation or Foundation)
Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it’s Ubuntu, it’s fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes. Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.

[2006-10-13 18:00]
There is a popular saying in Spanish, "en viernes 13 ni te cases ni te embarques" - Roughly, On Friday the 13th, don't get married and don't board a ship. That makes perfect sense - I'm already married, so I'm not worried about the first part. About the second, you never now - So I'd better take the plane to a country without sea access. Bolivia, here I go. [2006-10-13 23:30]
I'm writing this blog entry as I fly out of Mexico towards Bolivia, via Panama, on Lloyd Aereo Boliviano's flight number 911. The captain just announced that dinner will be served shortly, and invited those of us who want to enjoy the meal to open the tables, in order to get a better service. I fear that if I don't open it, I might get soup served straight over my pants, or something like that. [2006-10-14 02:40]
At the Panama airport. Captain informs again: "Passengers, we inform you we will replenish fuel. Therefore, if you choose not to go out for 15 minutes, we will request you to sit down with your seat belt unlocked. You will not be allowed to walk along the ailes. The bathrooms will be closed. Please do not ring the bells." Damn, that brings quite a lot of quiet about the refueling process - Of course I went down for 15 minutes, along with everybody else. BTW, shame I didn't take my laptop with me, as the battery is now at 15%... The Panama airport has (contrary to most airports I've been to in recent years) plenty of power outlets. Anyway, maybe on the way back. It's now 03:00 (Mexico time), and I think I'll have a better use for the next four hours until we arrive to Bolivia than coding.

During the Journ es du Logiciel Libre 2006 (an excellent event, thanks to the organizers), I had long chats with people from Mozilla Europe (in a more constructive way than what others did). This is mostly second-hand information, since the well-informed guys from Mozilla Europe I talked with got their info from other Mozilla developers, so it might be slightly inaccurate, but still help to understand the issue. More details welcomed in comments. The Mozilla Foundation goal is to prevent the web from becoming a proprietary web, by ensuring that Firefox, their product, has a big-enough market-share. I find it a bit disturbing to hear free software people speak about product and market-share, but well, OK. Of course, it’s quite difficult to achieve >20% market-share only with GNU/Linux users. They put a very high emphasis on the User experience. They want Firefox to look exactly the same on all platforms, even if some features (automatic plugin installation, automatic upgrades) do not fit well on a GNU/Linux system (such features don’t work with the Debian build). They want to enforce their trademark to prevent attempts to ruin their reputation to succeed. After a question asked by Dave Neary (GNOME) to Tristan Nitot (president of Mozilla Europe), Tristan gave the example of this hacker who said he found critical security bugs in Firefox before admitting it was a joke. He also gave the example of Microsoft indirectly founding SCO. Dave Neary remarked that some people could probably be trusted (like distro maintainers). But, if I remember correctly, Tristan said that it was difficult to allow some people to use the trademark without allowing everybody to do so. Also, allowing Debian to use the trademark without allowing derivatives to do so is not possible (DFSG#8). Iceweasel is considered a good thing inside Mozilla Europe (”It’s what we have asked them to do for a long time!“). However, some people are bitter about the fact that Debian seems to have chosen to use a gnu.org-hosted fork instead of just renaming the package to iceweasel. During Tristan Nitot’s conference, I asked a question about length of security support (only 18 months for the 1.0 branch). The answer was that distros were supposed to upgrade to newer Firefox releases even on their stable releases (!) or to come and help with security support for stable releases. Also, the fact that Debian chooses to package Firefox following the FHS is considered a source of problems. Somebody claimed that Debian was the only distribution to package Firefox this way (seems strange, but I did not checked this claim). I’m not sure how this fits with other Mozilla-based browsers such as epiphany. On a more technical side, they also claimed that Debian wasn’t properly collaborating with Mozilla, sending unusable 100000-lines patches for validation just before releases (haven’t checked this claim). It’s interesting to note that the same problem exists on the other side, with Mozilla releasing “security and stability” releases instead of just providing patches for the security bugs. My personal conclusion is that Iceweasel is really a good thing, and is quite unavoidable, even if it seems that the Debian/Mozilla collaboration could maybe have been better. Let’s advertise the use of Iceweasel, Epiphany, and other Web browsers! Note : comments open for people willing to fix inaccuracies or provide references, not for a stupid childish flame-war like the one in the comment of this post. Please write your own blog entry and use a trackback if you want to provide a detailed answer! Updates:

• I forgot to mention that the Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions, and causing bug reports on b.m.o or misleading forum posts. (again, not verified)
• Interesting blog post about the trademark issue here
• Mike Hommey addressed most of the points I reported in this blog entry.

Dear Bubulle, I am afraid that you do not know what you are talking about. Because you aren’t the only one in this case, here’s a short explanation of what happened. The existence of the IceWeasel fork is a reality that the Mozilla people need to accept and, optionally, understand (they also need to remember what Free Software is and how it all works). Unfortunately, some of the Mozilla people at the JDLL yesterday obviously couldn’t bear a little reminder about IceWeasel, but they were the minority. We hung the two posters in the morning, and they did not even notice them for something like 45 minutes. After what, somebody came and asked, in what can be described as an angry manner, if we knew why the IceWeasel fork got started. The answer was a plain and simple “I don’t care why the fork started. We’re going to rename Firefox in Debian so you people stop annoying us with your fucking trademark.” (which was obviously as rude an answer as their original question). At which point they just went away and never came back. They proceeded to fix the Firefox poster by adding a “TM” on it and, I think, fixing the capital “F” in the middle of the “FireFox” name, then stroke the “IceWeasel” line on the other poster. At this point, photos were taken and posted to one, then two blogs. Sam, for the sake of completeness, added the missing and markings to the Firefox poster, which the Mozilla people forgot to add. The whole thing could have stopped at that point, but Daniel Glazman, the famous Daniel Glazman, thought it’d be wise to link the first two blog posts on his blog, vomitting on Debian while he was at it. This was an extremely bad idea. His blog being syndicated on Planet Mozilla, he and the other Mozilla people are just helping spread the IceWeasel name and publicising the whole Mozilla trademarks debacle. I’m just not going to comment on the behaviour of the most vocal Mozilla supporters (no, dear Daniel Glazman, I’m not going to use the term “fanatics”, I leave that up to you), it’s just not worth bothering. Josselin linked the first blog post on his blog, so the thing made it to Planet Debian, too. This is no big news for Planet Debian readers, as the IceWeasel situation has been discussed at length on various blogs already. Now, what you Christian do not know, is that we have had several discussions about the Mozilla trademarks problems at the JDLL. Many people here were not aware of this problem and asked both the Mozilla people and us about it. We explained at length, several times, what happened, what their position was, what our position was, what had been proposed by both parties, why their proposals weren’t acceptable to us. Most of the people were quite astonished to learn that Mozilla Corporation refused the “Community Edition” idea, and most of them got our point. At the end of the day, one of the Mozilla people came and apologized for the blog posts and comments (although he isn’t the author of any post or comment, I believe), telling us that it wasn’t nice from them. Thanks for that, really. Overall, all of this is very positive for the Debian Project. We are doing the Good Thing. To everybody in Debian involved in the renaming of the Mozilla products: thanks, and good luck. Mozilla Corporation now has to face the Free Software community. It’s up to them to either come up with something that is acceptable for the community or stop whining about people complying with their trademark policy. Internet Explorer still has something like 82% of the market. You aren’t done yet, and you’re not going to progress without community support. So you’d better not lose this support now. Up to you.

Directed by jd & adn Genre: Action / Adventure / Sci-Fi / Thriller / Horror / Drama / Humor
Runtime: several weeks
Country: A lot
Language: English
Color: Color (Technicolor, QT, GTK and ncurses) Tagline: They stole their project, now they want it back. Plot Outline: In September 2006, a group of developpers from the Debian planet rise against the corruption leading the government.
User Comments: Great action, great suspense, great cultural satire, and a great mind-bender. Awards: Waiting for nomination. Quotes:

• Bah, if you don't want to read me, just don't , Sven Luther
• Oh my. , Clint Adams
• Or maybe I'm withdrawing my support because I'm busy with my chainsaw. , Josselin Mouette
• "I'm withdrawing my support because the developers might agree with AJ rather than me"? Come on. , Matthew Garett
• OH NO YOU DON'T. This thread is _not_ about you, it is _not_ about Frans Pop, and it is _not_ about debian-installer. , Peter Samuelson

Cast overview

	Anthony Towns (aj), as the Debian Project Leader		Denis Barbier (bouz), as The Recaller
	Aurelien Jarno (aurel32), as one Seconder		Clint Adams (schizo), as one Seconder
	MJ Ray (mjr), as one Seconder		Pierre Habouzit (madcoder), as one Seconder
	Martin Schulze (joey), as one Seconder		Marc Dequ nes (duck), as one Seconder

Joey Hess wonders if the Debian Weekly News are still a useful thing, and whether the planet has not taken it's place. In my opinion, that is not the case. I always looked forwared to Wednesday evening when the new DWN would come out. I enjoyed the nice overview of what's going on in the different corners of Debian and eagerly read the recently added or orphaned package lists. DWN was a nice news digest, just the right size, and seemed to me more balanced and a tad more objective than just the random blog entry.Unfortunately, the DWN are most useful for those who are currently not aware of all the things going on, who are not on all the high-traffic mailing lists (or don't read them), and these are of couse not the people who can run the DWN (I count me to that group). And those who are suitable to write the weekly letter are not those who need it...I still hope that someone and maybe some more can pick up the task and keep this institution running. <sarcasm>Maybe dunc-tank can sponsor them...</sarcasm>

Joey Hess wonders if the Debian Weekly News are still a useful thing, and whether the planet has not taken it's place. In my opinion, that is not the case. I always looked forwared to Wednesday evening when the new DWN would come out. I enjoyed the nice overview of what's going on in the different corners of Debian and eagerly read the recently added or orphaned package lists. DWN was a nice news digest, just the right size, and seemed to me more balanced and a tad more objective than just the random blog entry.Unfortunately, the DWN are most useful for those who are currently not aware of all the things going on, who are not on all the high-traffic mailing lists (or don't read them), and these are of couse not the people who can run the DWN (I count me to that group). And those who are suitable to write the weekly letter are not those who need it...I still hope that someone and maybe some more can pick up the task and keep this institution running. <sarcasm>Maybe dunc-tank can sponsor them...</sarcasm>