We're still in wt:Copenhagen today, but we head out this afternoon for our tour of the Baltic Sea. We've had a great time in the city so far, mostly due to staying with longtime Wikitraveller wt:User:Elgaard, who generously offered us the extra room in his apartment for the time we're here. There's something about staying in an actual human being's home while you're travelling to really recharge the batteries. After a week in hotels and restaurants, a little time in a real house can make you feel a lot more human. We took our time getting to Copenhagen from wt:Odense at the end of the Wikisym conference, mostly because I was really hung over. I'd spent the last night of the event drinking at the Irish pub in the pedestrian area, and I probably had 1-5 pints too many. Paul Yount calls Irish pubs "the first Open Source franchise", and it's true: you can expect certain things at a pub no matter where it is in the world. Although we started out with about 30 people, the crowd thinned through the night. I had a good time talking with Brion Vibber and Chuck Smith about the state of Esperanto-language wikis on the Web -- in a mish-mash of English and Esperanto, of course. (In case you were wondering: the state is "fine".) I also chatted Wikimedia Foundation politics with Angela Beesley; we both think Erik Moeller is going to make a good addition to the WMF board. After the pub shut down, I headed to the deathly silent casino in the sub-basement of the Radisson of Odense. The bar was eerily silent, and the gaming tables were intense and serious; I don't think people could have been more somber if they were organ harvesters gambling for body parts. The last hangers-on were Andrea Forte of Georgia Tech, Alex Schroeder of CommunityWiki, Sunir Shah of MeatballWiki, and Eugene Eric Kim, of Blue Oxen and HyperCore. In other words, some of the smartest people in the wiki world today -- we talked wiki politics and theory until the wee hours of the morning. They all switched to mineral water while I was still slugging down pints of Carlsberg Special, which is probably where I went wrong. Wikisym, for me, was one of the best conferences I've been to this year, and I've been to a lot. It capped off a long summer of conference-going, and this fall should be relatively tranquil. Which is great: I have a lot of work to do, based on the ideas I've picked up this season. tags: wikisym2006 odense copenhagen wiki

sterbro All of which is to say that I was feeling pretty crufty the next morning as we got on the train. Kindly Maj got us a late checkout and let me sleep in late, which helped a lot; a falafel sandwich around 11AM also cleared my head a bit. The train ride from Odense to Copenhagen was great, and by the time we got to Niels Elgaard Larsen's house in sterbro (a neighborhood of Copenhagen) I was pretty refreshed. Niels took us out to an early dinner at a restaurant called Pixie in a square by his house. Copenhagen has some pretty strict traffic laws, and the number of cars on the street is possibly the least I've ever seen for a major metropolis, leaving a lot of room for sidewalks, bike paths, and open parks and plazas. We got to chat with Niels over a fresh pasta dinner, and thence home to his house for beers and more talk. One great thing about visiting Wikitravellers is that they tend to be a) very smart, b) well-travelled, and c) interested in Free Software and Free Culture. Niels is no exception; he's active in the Danish and European Free Software and information freedom communities, and he's extremely interesting to talk to on the subject. We shared travel stories and talked about Open Source and Open Content later than I would have thought, based on my earlier-morning hangover. Probably the high point of the evening, for me, was when Niels shared a brilliant idea for a way to distribute Wikitravel guides in digital form for a very wide array of users. We've had a hard time settling on a mobile document format for Wikitravel guides, since mobile devices like PDAs and cell phones support standards so poorly. It's one of the most requested features for Wikitravel, but it's going to take a huge amount of work to cover even a fraction of the mobile device owner community. Except Niels had a genius idea for how to distribute guides in a simple, standard format that works on a mobile digital device many if not most travellers carry with them every time they travel. The idea: make guides that are downloadable JPEG images which can be copied to a SD card or Compact Flash or Memory stick or whatever, then stuck into a digital camera. If the camera supports zooming on images, and has a decent screen for review, the guides might be useful and readable. I'm going to try to do some experiments with the idea -- I think it could be a real winner. Adding 30-40 images to a camera today is pretty cheap, and if they're just text I think some aggressive compression can work well. tag: jpeg sterbro niels copenhagen wikitravel mobile

Copenhagen on foot Yesterday we did a big tour of the city on our own. In the morning, we had some breakfast at the Laundromat Cafe right next door to Niels's house, and I took the opportunity to clean a week's worth of dirty laundry. Nothing like a stack of clean clothes to make you feel more like a decent citizen. I was down to a bathing suit and the ICANNWiki t-shirt Ray King gave me at Wikisym. Then we headed out on the town to do some sight-seeing. First we hit the Kastellet, a fortress in northeast Copenhagen that's the oldest operational military base in Europe. It's got the distinctive star-shaped outline typical of old fortifications, and is surrounded by a lovely park with ducks and swans. We had lunch at a nearby caf , with large beers. (Gee, I'm getting worried about the pattern here.) After lunch we made an unscheduled stop at den lille havfrue -- the famous Litle Mermaid statue in the harbour. It was miniscule and surrounded by perhaps 100 onlookers, crammed into a tiny swatch of sidewalk. We stopped about half a mile away, took some pictures of the crowd, and moved on. We then hoofed it down through the harbour and across Nyhavn and a bridge to Christianhavn and Christiania. We'd both heard about the city-within-a-city run on anarchist principles -- kind of like a giant squat -- but neither of us had been there before. It was an interesting place -- packed with people, lots of food cooking a beer-drinking, caf s and restaurants all over the place, interspersed with art installations and little gardens. But it had the unkempt scumminess of a big squat, too -- especially on the main drag -- and there were a few too many pitbulls and gutterpunks for my tastes. Overall a good experience but I don't know if I'll go back. After our long walk we took the metro back to Niels's, where we napped until he and wife Chiquita got home. Chiquita is an investment banker from wt:Toronto who does a lot of business in Europe, where she met Niels a few years ago. They were married last year and have had a long-distance relationship -- visiting each other a week or so out of each month -- for the whole time. She's moving here this year, which I think will be nice for both of them. We had a good dinner at a place called Thomas's -- a buffet, which seems to be very popular here -- and then back home for a nightcap and bed. Amita June was overtired by the time we got her to bed, and she let us know that we'd pushed her too hard with a quarter-hour of heavy crying. But we all got to sleep pretty well afterwards, and at least the parents know that we should take it easy in the future. tags: copenhagen kastellet christiania little mermaid

Argh... trying to get caught up on this journal in the wee hours of the morning here in wt:Odense. I've had pretty bad jet lag this trip -- I've never been particularly good with time changes, and the North-America-to-Europe switcheroo really throws me off. So by 2PM I'm falling down on my feet, but at 4AM I'm rarin' to go. Odense has been a particularly nice place to visit. We got into wt:Copenhagen a few days ago, and crashed at the Airport Hilton there. It's actually attached to the airport -- you can just walk right in. Maj got a good deal on a room, and we figured it would make sense to sleep with the baby right there, rather than fight the train system to find another hotel in the city centre. After a free brunch including many different kinds of pickled fish, and a looong nap, we took the train into the Central Station in Copenhagen, right by Tivoli Gardens. There were lines around the block for the amusement park, but we skirted them and headed into the pedestrian area near City Hall. Based on a recommendation in Wikitravel, we went to the line of caf s and restaurants off of Nyhavn, a sliver of water poking into the heart of the town. It was a great walk, and we had a casual sidewalk dinner at a place called Carl's Corner. The canal was lined with boats that had been converted to restaurants -- we may try one when we go back to Copenhagen this week. tags: travel copenhagen jetlag nyhaven

Wikisym The next morning I got up at dawn and got on a train to Odense for Wikisym. I missed my connection at the Central Station, and all the trains were running late, so I got real confused about where to go. The fact that I was carrying all of our luggage didn't help matters. But a few false starts later, I managed to get myself oriented and on my way. The train ride was beautiful -- wt:Denmark is a very pretty country, with rolling grassy hills and clusters of small, peak-rooved houses by the tracks. The trip from Copenhagen to Odense takes you from wt:Zealand to wt:Funen, across a long rail bridge. Very impressive. Once I'd landed in Odense and got myself organized, I slipped into the back of the room for Wikisym to catch the last few minutes of Angela Beesley's keynote address. Angela might be the hardest-working person in Wikidom -- she's a tireless community organizer not only for the Wikimedia Foundation sites like Wikipedia but also for Wikia's sites. After her talk, we did an wp:Open Space session, which continued throughout the day, interlaced with the academic presentations. I'm getting to be a big fan of Open Space; it was really effective for RecentChangesCamp, and I think it works well for organizing a conference. Ted Ernst led the sessions, with the help of Gerard Muller of the Danish Open Space Institute. Probably the most productive Open Space session for me was the one about non-text wikis -- using wiki techniques for video, audio, image and visual language editing. I'm fascinated by this stuff, and it's great to hear that some people are working with SVG and SMIL to do in-browser multimedia editing. The consensus is that the technologies Aren't There Yet but are around the corner. The other major thing I think I picked up from this session was Eugene Eric Kim's discussion of Wiki Ohana. Ohana is the Hawaiian word for family; the Wiki Ohana is a project to develop some interoperability and a transmission of our Wiki principles to new members of the family. I think it's a great idea and I'm going to try to get involved further. tags: wikisym2006 wikisym open space wiki ohana

Odense We had a great walk around Odense's core pedestrian area. It's not exceptional for Northern European towns -- it reminds me of the Netherlands, and Maj of Switzerland -- but the car-free cobble-stone walking areas are a real relief after years in North America. We have some pedestrian areas in Montreal, of course, but not in the same way. Odense is the childhood home of wp:Hans Christian Anderson, and the city is decorated with statues of HCA, and of characters from his stories (the Tin Soldier, Thumbelina, etc.) It gives a kind of fairy-tale air to the town. I'm not sure they should feel so proud of being Anderson's childhood home, though -- from everything I've read, his childhood was nightmarishly cruel, and his abysmally poor family was harshly treated by the society here. But, of course, that's in the past. Now, we had a real nice time walking around. Amita June likes tottering along on the cobblestones, and shouting really loud in the small streets to hear the echos. We ended up having dinner in a place called the Cuckoo Caf -- great food under a spreading tree in a little square. This morning -- no, yesterday morning -- Maj got up and took the first sessions, and Amita June and I slept in. We went off into town again to find a bakery, and shared a chunk of brunsviger, a sugary pastry that will probably rot out her tiny teeth. I had a cup of tea, which was less than satisfying. I've been trying to cut caffeine out of my life, so we've been having decaf at home, but they don't seem to serve it in caf s here. I'm a creature of habit, and I like the taste of coffee even if it doesn't have the caffeine oomph. tags: odense amitajune decaf hca

CAPS LOCK SUCKS In response to Lars's defense of CAPS LOCK: Lars, you ignorant slut. Caps lock has been the bane of online culture since the invention of mixed case in the late 1960s. It is a hallmark of clueless newbie-ism for people who are too analphabetic to remember the exceedingly simple English capitalization rules. The only legitimate purpose for CAPS LOCK is for doing C macros and defines, but hey, who writes in C any more? Anyways, that's just lazy programming. A real programmer would write a macro to capitalize the names of other macros where used. That's just good programming practice. Another important point is that CAPS LOCK is Eurocentric and imperialistic. What value does CAPS LOCK have for someone writing in Eritrean, Malayalam or Ojibwa? None at all. Yet dead white males like Lars Wirzenius want to force their CAPS LOCK cultural hegemony on an increasingly global culture. For shame. The worst thing about CAPS LOCK is that it squats in the middle of the most important letters on the keyboard, like a rat trap waiting to spring. Big and ugly, it always catches your left pinky when you're reaching for Ctl or Shift or Tab or A or whatever. Key-chording is here to stay, and CAPS LOCK not only ignores this important UI development but actively interferes with it. Modal interfaces are rightfully extinct, and CAPS LOCK needs to go the way of the dinosaur. It's time to eliminate this obsolete key once and for all. (This message brought to you by The Taxpayers Against Caps Lock Coalition. I, Evan Prodromou, endorse this message.) tags: caps lock ignorant slut

I'm back in Italy after a wonderful vacation in Oregon. I had a nice time in Portland at OSCON, and got to meet a bunch of people I most likely won't see for a while, which is always fun. In particular, David Jones of OFBiz was impressive in his determination to do anything and everything to make that project a success. It would have been nice to spend a bit more time at OSCON, but vacation called. On the negative side, I'd kind of forgotten how these things at time break down into cliques, but c'est la vie. It reminds me that I prefer the inclusiveness that is at times more present in Italy. Going a bit off topic from the topic of this journal, "computer stuff", we went all over Oregon... Portland, the Gorge, Mount Hood and Timberline Lodge, the central coast, Eugene of course, including a wine tasting trip along the applegate trail, Waldo Lake, Paulina Lakes, and over as far as Fort Rock and the high desert, which was quite a spectacle for us city dwellers acustomed to being surrounded by people. One of the great things about Oregon, and being on vacation there, is the bookstores. Powell's is probably the world's largest physical bookstore, and the separate technical shop is larger than all but the largest bookstores in Italy. I couldn't resist buying a bunch of books there, and at the Smith Family Bookstore in Eugene, which has loads of used books at good prices. I bumped into Russ Nelson, of the Free Software Business mailing list, in the Economics section of Powell's, which was an interesting chance encounter. Amongst the books I picked up: The Paradox of Choice: Why More Is Less A good read, but it could have been condensed significantly and still got its point across. I think there is a lot to be learned in this book for us programmer types, who tend to be very much 'maximizers' in what we do. I've written about this some here: Maximizers, Satisficers and Programming Languages Why Globalization Works The book explains what the title promises. It's a long read, because the author is very thorough and provides lots of supporting facts and figures. Growing a Business Good read on creating and growing a business, even if it's a bit dated, and related to the individual in question and his experiences. Now, if only I had the business... How to Bring a Product to Market for Less than $5000 Haven't read it yet, but I have some ideas for products completely unrelated to high tech (it's stuff from Italy, actually) that I think would do quite well in the US. Contact me if you're interested... The Design of Everyday Things Haven't got around to reading this one either (also, I have a backlog of The Economist to read here at home, which is usually time consuming). It comes high recommended though. The Third Chimpanzee: The Evolution and Future of the Human Animal I enjoyed Collapse as well as Guns, Germs and Steel by Jarod Diamond, and this one looks interesting too. In light of the aforementioned backlog, I left this one with my parents to read, and I'll check it out later this fall. Why Most Things Fail Doesn't seem to be rated very well on Amazon, but Ormerod's thesis that economics-as-a-machine isn't tenable is interesting, and I'm curious to see the details of that idea. Perhaps one of his earlier books would be good reading as well. I'll try and write up the books as I read them, if they prove worthwhile.

I said a few days ago that Ross Mayfield had one of the best blogs about wikis and the wiki business. But Eugene Eric Kim gives him a run for his money. EEK Speaks covers in detail a lot of the public and private aspects of wiki going on right now. Of course, I wouldn't paint EEK and Ross as rivals; after all, they won the Web 1.0 pitch contest at Wikimania together. tags: ross mayfield eek wikimania wiki blogs

Victory is mine (I think) For the last few weeks, some of the more advanced features of this wiki have been blowing up with a 500 Internal Server Error, to my great chagrin. I had switched from using CGI to FastCGI for WiLiKi and I'd seen a real improvement in the responsiveness of the site, but these occasional errors were becoming more frequent. I finally hunkered down to figure out the problem. Annoyingly, there was no error output in the Apache error logs, so I guessed that the problem was sooooo bad that the process didn't even get a chance to scream on stderr before dying. I had all kinds of theories about this. Most of the problems had to do with full-text searches of the database, so I guessed that the underlying cause had to do with I/O and concurrency. Gauche has a nice logging facility, so I threw in a lot of logging printf statements (or their equivalent) and isolated the problem to a few calls into Gauche's dbm libraries. Aha! The problem had to be concurrent DB access. I layered on a big slathery scoop of mutexes and locking and other such good concurrency stuff and... the problem was still there. D'oh! So much for my diagnostic skills. I decided to take a step back. After ascertaining for myself that any writes to stderr from within a FastCGI program should indeed show up in the error log -- by reading and by writing a couple of sample programs -- I turned to the debugging tool of last resort: strace. strace logs all system calls by a program, which can be a lot of information. I couldn't, of course, just start my FastCGI program, so I had to strace the entire Apache process, with lots of command-line flags to divvy up the output on a per-process level. Once I had that going, I could kind of see what was going on. My full-text searches were starting up fine, but about halfway through the search they'd get a SIGTERM and terminate. Holy moly! That wasn't an error in my program -- someone was murdering my poor little FastCGI processes. At first I suspected fratricide -- that the processes were terminating each other when they needed the database resource -- but I realized right away how dumb that was. That only left one suspect -- the parent! I dug a little bit into the fcgid documentation, and sure enough, if a process went too long without giving any output, fcgid would terminate it. I upped the time limit for this wait, and now all my search processes are working fine. I'm going to need to start doing something smarter with these full-text searches. I think doing some indexing at write time is the best bet -- that should probably speed stuff up quite well. But for the time being the processes will run, if slowly. The only bummer is now I have to go dig out all the mutex-y lock-y stuff I wrote earlier. tags: fcgid wiliki strace debugging fastcgi cgi 500

After more than three years away from home, we're going on vacation to Oregon this summer. Luckily, that will coincide with OSCON in Portland, so hopefully it will be possible to meet some people there that I ordinarly wouldn't get to see. Write me email if you'd like to get together for a beer or something! The rest of the time, we'll be in Eugene, or travelling around the state.

Via reddit (which kicks the crap out of slashdot and digg): What I've Learned From Failure.

The link above is a long, but fascinating piece. I've had to become a lot more interested in how to manage software projects since taking on Xorg maintainance, and the same lessons seem to scale up well to how Debian as a whole manages itself. This article talks about some of the major problems that I've seen myself deal with, and the experiences of this guy echo my own over the past year very strongly. Here's a few examples:

"Getting away from weak teams, another source of failure is the omnipresent threat of "chickens." A chicken is not necessarily a weak individual, but a sign of a weak management structure. A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project. Significant authority includes the authority to impose constraints on the team."

I like this and I've noticed it in the XSF and in Debian as a whole. People are free to work on what they want how they want, and this tends to work out well for us. But we also have no structure in which people must actually commit to what they do. As such, there's no accountability. This frees Debian developers from the preassure of having to work on something they don't enjoy, but it also creates abandoned packages, ignored bugs, and frustrated release schedules. In the past I've described a need for a stick in addition to a carrot for Debian developers, and the sentiment here echoes that idea. I've spoken with Manoj about his conception of personal responsibility in Debian, and I think it may truly be the bedrock on which Debian needs to rest. I still don't have a good mechanism for this yet though.

"Another sign of a weak team is poor development hygiene. There are dozens of development practices that seem trivial to the inexperienced outsider or to the manager focusing on "big wins." Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews)."

This is a something I myself have had a problem with over the past year. Branden was extremely good about keeping the XSF svn repo and the BTS up to date and well managed. I've done just about the opposite over the past year, and it's bitten me a few times. This however, was a conscious decision on my part, knowing that I was so far behind upstream that it was going to be hard to effectively manage the BTS without a recent codebase deployed to our users. So I focused on packaging instead, and luckily that road is nearly finished. Also fortunately, everyone else in the XSF managed the BTS for me, most notably (in alphabetical order by last name) Julien Cristau, Michel D nzer, Eugene Konev, and David Martinez Moreno, and they've managed to keep it relatively tidy. I'm going to spend some serious effort over the coming months to clean out the BTS so it's more manageable both for users and developers again. Luckly our SVN repo is in good shape still, so for the most part we're doing pretty well here. Debian as a whole also seems to be doing better at this, with lots of public svn repos springing up on alioth.

"It's mandatory to fail early. You need to know you're in trouble right away. That's essential when taking over an existing project or starting something new. You have to find out how you're doing within weeks. Not quarters, not months. The longer you wait, the more inertia the failure will have."

We're getting better at this, and I've sort of made it my mantra for this release cycle. Get things in to experimental as fast as possible, and then when I've fixed the majority of the bugs that show up there, put it in unstable as fast as possible. It worked out well for all the releases I've done so far and I'm going to keep doing it. Michel is really pushing me to keep CVS (or git as of Real Soon Now) snapshots from upstream in experimental, and I really like this idea and plan to follow through with it for this reason. This also echoes some of aj's ideas about speeding up development pace. Hopefully he'll implement them whether or not he becomes DPL, because I think they're going to be important for Debian as a whole.

"Dates are sacred."

We learned this during the sarge release cycle.

"The net result is that I've tried to find the happy medium where I generate weekly management reports on projects. A management report is something that is used to actually make a decision. Everything else is garbage. I've learned that when I haven't had management reports for a project, failure has resulted."

This is an interesting idea. It sort of echoes how I try and provide status updates on my blog, as well as the "Bits from" emails, but perhaps something more like this would be useful. I may try and play with this idea in the near future.

There's a lot more in there, but this entry already got way too long. Hopefully there's some food for thought in there for everyone who's interested in how Debian is run. The Debian development model has carried us very far, but I can't shake the feeling that we need to make some critical changes for it to continue. This will require a certain degree of boldness, but in order to fix the problems with the project I think we just need to clench our teeth and go for it. With that, I'll leave you with one last line from the above: "And if you decide to make changes, have the courage to go 100% with your gut. I've failed more than once when I watered down my convictions in order to appease dissenters. The only thing worse than evangelizing change and failing is looking back and realized you might have succeeded if you'd held firm on your convictions."

Last night I uploaded the last major pieces of Xorg 7.0 to experimental, including the server itself. Today I came home and found that Joerg Jaspert had already approved them to go in. Big thanks for him for processing these things in record time. The packages currently only have a few of our Debian-specific fixes applied, and the next major step before uploading to unstable will be to get those ported from 6.9 to 7.0, and also to pull in patches like benh's radeon patch that fixes a lot of crashes in 6.9. As things stand now though, you can pull the packages from experimental for i386 and be running Xorg 7.0 in all its modularized glory. Hopefully a few of you version junkies will try them out and report bugs so we can hammer them in to shape for release!

I wanted to give another note of thanks to Eugene Konev. Eugene helped out quite a bit in the past, getting 6.8 and 6.9 in good shape for Debian. For 7.0, I had done a pretty poor job on the xfonts and he put in a ton of effort to polish them up. In addition, he packaged xdm and even ported all the patches for monolith over to that. He really helped me get this last bit over the hill, and he deserves a lot of credit for it.

I'm feeling pretty good about this because it represents the end of about a year's worth of work. I won't feel like it's the end until a set of packages I'm happy with ends up in testing, but until recently I wasn't sure I'd be able to get this far in time for etch. Yet somehow, here I am, looking like we'll definitely be shipping modular Xorg with etch. There's still this last 10% to go through though (and you know what they say about that) but I'm confident that the end of this task is in sight and I can start to move Debian's X work from playing catch up to helping define the cutting edge. Hopefully with everything going on people will be getting excited about X again, get involved, and we can keep making cool things happen.

With Xorg 6.9, we've split xterm out from the main xorg package and have packaged it directly in its own source package taken from Thomas Dickey's site. He's been the maintainer of xterm for years now, and X.Org has just been pulling his stuff directly for their tree, so this way we skip the middleman. Thomas is also very notably a contributor and regular fixture on Debian lists, which is really cool.

David Mart nez Moreno did the grunt work a while back of making the individual xterm package, and he uploaded a version or two to experimental while 6.9 was sitting there. Now that 6.9 is in unstable (the next revision will hopefully be coming when I wake up tomorrow, btw) we needed the separate xterm package to join it. So today I did a little bit of work updating David's package to Thomas' most recent xterm version (208) and uploaded it to unstable, where it's already built on most arches.

This is the first bit of modularization you'll see, and I'm going to start uploading the more mundane bits of 7.0 to experimental this weekend if all goes well. The main requirement for getting 7.0 in to Debian is to have mesa updated. The package is ready for an NMU, and today I uploaded an NMU of libdrm to update it to the latest version. Once this package is accepted in to the archive, I can update mesa. From there on out, all the pieces will be in place to allow uploads of the modular tree to Debian as needed. Of course, these will go to experimental first until I'm confident in them, but my goal is still to ship them with Etch. Eugene Konev has started doing q&a; on the modular library packages, which will hopefully save us time and pain.

So that's where things stand with us. Once the major bugs are out of the way with 6.9, I'll be going full speed ahead for 7.0.

Today was a good day in Debian X land. X.Org released the "zeroth" release candidate for both the 6.9 (monolithic) and 7.0 (modular) versions of the X.Org tree. I downloaded the 6.9 tarball, imported it in to the XSF svn repo, and got to work on the patchlist. I'd already ported a number from 6.8, and tonight I managed to finish the rest. Except for a massive GNU/kFreeBSD patch, every single patch in the debian tree has been ported over to 6.9. This work took multiple weeks with multiple people for 6.8 using dbs. Using our new quilt-based patch system I blogged about in the past, this took me about half a week, with the bulk of the work over the past two nights.

Now I haven't actually been able to build 6.9rc0 yet, nor have I been able to build 6.8 for a few days. There's currently a bug in the linux-kernel-headers package that breaks the X.Org build, so the XSF has been working on polishing the -5 release. Eugene Konev has fixed things to we now build HTML docs for xspecs again, for those of you who hate the postscript versions. David Mart nez Moreno has been doing an enormous amount of cleanup, generally dealing with a lot of the bugs that have come in and taking care of the new translations that have been flooding in almost as fast as we can change the debconf templates :-) Christian Perrier has joined the team as translation coordinator, so as soon as he can get svn access the X packages should be well taken care of in his amazingly capable hands. Finally, I've included a new script for /etc/init.d supplied by Petter Reinholdtsen that will give Debian LiveCD-derivatives a standard way of generating an X server configuration on boot. Nothing too fancy, but we're tightening up the package a bit more and those fixes have already been merged in to the 6.9 branch.

So if people need updated drivers from Xorg's HEAD, keep an eye out for 6.9rc packages to hit experimental. As soon as I can build and test them, I'll put them there for people to play with. My goal is to get 6.9 in to unstable on the day it's released by upstream. We're (or at least, I'm) going to begin work on 7.0 as soon as 6.9 hits experimental as well, borrowing one more time from Ubuntu and attempting to stabilize that packaging alongside them, if they haven't already beaten us to it completely :-) So things are moving and we're going to try and keep up the momentum.

Some people have also been asking about xcompmgr/transset packages. It's still not packaged for Debian because it's either slow or crashy, depending on your driver, although fixes are in the works. I may have found someone to maintain it for Debian, and I'll try and keep people posted about it when I know more.

Last time I blogged about a bug a lot of people had reported with X.Org, and at that time the workaround was to download a file and replace the installed version with it. Well, Eugene Konev came through and found a more complete patch and we've got that bug essentially fixed on our end, so I think most people can now run X.Org on Debian without fear. The bug in gcc4 is still present, but the next upload of gcc will include a fix for the issue, so we'll feel a lot more confident that the bug is really dealt with the next time we upload. Another thing that's happened is that it appears that the current upload does finally build on all arches (after I messed up -3, which should have been the one to do so) so that's one major issue happily out of the way.

We've already begun putting together another X.Org upload that should happen soonish. There's a pretty crippling bug on alpha that Steve Langasek has already provided a patch for. The big news though is that I've finally ripped out the X.Org package reliance on dbs and replaced it with quilt. Eugene Konev hacked up a very good version of the debian/rules file (which controls building of the package, for those of you who haven't dealt with the internals of a .deb before) that uses quilt instead of dbs. I did a little work on it myself so that it would provide the same basic features that dbs gave us, and now it's been rolled in to the svn archive.

Now this won't directly affect any users, but what it will do is let us process patches much faster than with dbs. dbs requires that you copy the whole source tree once, copy it again after applying patches, and then diff the whole tree when it's done. For small trees this isn't a huge deal, but for X.Org this is crippling, especially on my laptop where I do all my work. quilt lets me edit patches in place, and only diff those files that are edited. In addition, if there's a patch that I already pulled from somewhere like X.Org CVS or Redhat's bugzilla, I can simply tell quilt to import it and it will. This literally will save me an hour per patch. quilt also buys us some cool features like being able to check patch dependencies, tell what patches alter what files, and sort patches in to subdirectory heirarchies rather than having hundreds of patches sorted solely by name. Plus, it knows about patch documentation, which dbs will overwrite by default, and quilt will happily preserve.

So hopefully this will make the XSF ever so slightly faster at getting things done, although we're still obviously hampered by the scale of the source tree. Future patch audits should be on the order of days rather than weeks with this system, which lays the groundwork for work on 6.9/7.0.

Last time I blogged about the libglu situation, which I explained was necessary because of the C++ ABI transition in changing over from gcc3 to gcc4. libglu is the one library written in C++ in all of the X.Org source tree, so it was the only one that had to be broken.

It turns out we were wrong about that. libglu is indeed written in C++, but Marcelo Magallon pointed out that it only exports a C ABI, and as such it doesn't need to be transitioned. I have admittedly little experience with shlibs myself, so I didn't know such a thing was even possible, and no one else caught it either. The next version of X.Org, which will be uploaded as soon as I can get it built, will have this fixed, and nvidia-glx, and everything that depended on xlibmesa3-glu will hopefully install just fine once that goes in. Sorry about that everyone.

In addition, this upload should have correct MANIFEST files for all arches, which will hopefully allow it to build successfully on all of them. This will allow X.Org to transition in to etch after a week and a half. This will also unstick gnome 2.10's transition in to etch, which is now tied up with X.Org. Daniel Stone helped pull those MANIFEST updates together, which has been a huge help, so you should send him your hugs 'n kisses. There is an issue with libvgahw which a lot of people have reported, which causes problems when you switch to a virtual text console and then back in to X, which should be fixed in this upload as well (you can thank David Mart nez Moreno for tracking that one down before I could even blink). Finally, xterm bold fonts have been looking like garbage, but Eugene Konev came up with a patch to fix that, which I'm working on rolling in right now.

So if all goes according to plan (that's your cue to laugh mercilessly at me) the next upload will move in to testing just fine, leaving us with room to make larger improvements in the X.Org packaging, as well as working towards getting the (currently unreleased) next version of X.Org in to Debian.

With Xorg 6.9, we've split xterm out from the main xorg package and have packaged it directly in its own source package taken from Thomas Dickey's site. He's been the maintainer of xterm for years now, and X.Org has just been pulling his stuff directly for their tree, so this way we skip the middleman. Thomas is also very notably a contributor and regular fixture on Debian lists, which is really cool.

David Mart nez Moreno did the grunt work a while back of making the individual xterm package, and he uploaded a version or two to experimental while 6.9 was sitting there. Now that 6.9 is in unstable (the next revision will hopefully be coming when I wake up tomorrow, btw) we needed the separate xterm package to join it. So today I did a little bit of work updating David's package to Thomas' most recent xterm version (208) and uploaded it to unstable, where it's already built on most arches.

This is the first bit of modularization you'll see, and I'm going to start uploading the more mundane bits of 7.0 to experimental this weekend if all goes well. The main requirement for getting 7.0 in to Debian is to have mesa updated. The package is ready for an NMU, and today I uploaded an NMU of libdrm to update it to the latest version. Once this package is accepted in to the archive, I can update mesa. From there on out, all the pieces will be in place to allow uploads of the modular tree to Debian as needed. Of course, these will go to experimental first until I'm confident in them, but my goal is still to ship them with Etch. Eugene Konev has started doing q&a; on the modular library packages, which will hopefully save us time and pain.

So that's where things stand with us. Once the major bugs are out of the way with 6.9, I'll be going full speed ahead for 7.0.