It’s official: I’ve joined the Free Standards Group as Chief Technology Officer and chair of the FSG’s Linux Standard Base (LSB) workgroup. (The FSG made some great additions to its board too.) This promises to be a breakout year for the LSB and for free standards in general, and I’m excited to be a part of it. Some of the things on tap for the coming year are:

• The LSB 3.1 release (which adds Desktop functionality to the ISO standard LSB Core, among other things)
• A crisp, well defined roadmap for LSB 4.0 and beyond, with increased emphasis on synchronicity with the major distros and stability, predictability and consistency of the LSB ABIs/APIs over time
• A renewed emphasis on increasing direct involvement of distros, ISVs, and upstreams in the LSB development process
• A developer outreach program that will make it easier than ever for software developers to target the Linux platform in a portable way (hint: ever wish there was a Linux Developer Network?)
• A franchised certification program that will allow third parties to integrate LSB certification into their own value-added certification offerings (our recent announcement that we’ve teamed up on a certification center in China is a hint of things to come here)

As with most major life changes, this one’s bittersweet in some ways, as in the process of embracing this exciting project, I’ve had to step away from another, namely Progeny, the company I co-founded way back in 1999 (!). It’s always hard to move on from something that’s been a big part of your life for such a long time, and it’s particularly hard when you don’t feel like you’re “done” yet. On the positive side, I leave Progeny in excellent hands, and I’m able to remain involved in that wonderful position called “advisor”. Speaking of Progeny, I’m exceedingly proud of all we accomplished over the years. Not only did we survive the .com bust, but we successfully reinvented ourselves in the midst of it all. Furthermore, we not only survived, we pioneered: we were among the first (if not the first) to build a business model around the customization and integration of open source code, a model that’s been adopted by some of the hottest open source startups of the past few years. I’m also immensely proud of the DCC Alliance—indeed, my new role with the FSG is, in a lot of ways, a natural progression from that latest waypoint in a string of projects that date back to 1993. That’s it for now. Watch this space for additional news about the LSB as it continues to unfold. Better yet, get involved and help make it all happen!

Debian Today I uploaded a new revision of Apachetop, fixing several bugs reported by Sven Koch. It is always a pleasant suprise to me when people will file bugs along with a patch. I guess I shouldn’t be so suprised as this is the very reason that open source works, and works so well. I think it is fair to say that Debian has a reasonably technical target audience which probably helps with the submission of patches. (Although this may not actually be the case.) In other news I updated my website, changing all occurences of the ficticious word ‘publically’ to the correct ‘publicly’. Work Yesterday whilst calling SCO to enquire about pricing for their software support I was asked by the receptionist for my number. Rather than giving the company number I gave her my home phone number. Ooops. Otherwise I’m starting to get the hang of being back at work Contracts To support my upcoming “remote sysadmin” / “Debian Linux setup” services. I’m getting in touch with all the companies for whom I’ve done remote contract work, asking for permission to list their names as “previous happy clients/customers”. I’m sure that some will agree, some will pass it on to their legal department and decline, and yet more will wait to see who else I’m going to list. Fun stuff. Cool Toys The new release of OpenSSH allows you to create VPNs using tun devices. Cool. That will be enormously useful. Once a package makes it into Sid I’ll backport to Sarge so I can play with it.

From today's Snowmail (Jon Snow is my personal hero by the way):

We must also though note that in a poll today, almost half of Americans said they would approve of a war with Iran tomorrow.

Oh dear God, Really, I'm lost for words. An expanded article will follow when I stop thinking "but...". NP: Best Of, Otis Redding

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.

Sorry I've been late getting Xorg 6.9 in to unstable. The holidays combined with unexpected last minute fun with Xrender are responsible for the delays. I'm in the final stages of checking that everything will build properly, then it's on to some cleanup (translations, last minute bug fixes, etc) and getting final permission to start the transition from the release team. Hopefully in the next few days.

I'm dying to get this done so I can get 7.0 in good shape and in to experimental.

Well, I've done it. The XSF svn repo now contains a full set of packages for the Xorg modular tree that enable it to run an X server in a chroot from a clean install. Note that the packages are still very sloppy because I've been mainly beating them in to shape enough to simply run the server. But that part's now done, and I can happily get that grey hatched background to show up from inside my chroot. The next step will be to finish packaging everything, so that we have a full set of packages to install, run, test, and clean up to the standards of quality we expect from Debian. Note that I don't recommend anyone but developers even take a look at these things yet, since I've been very lax in getting them in to good shape. I had a good base to work from (more on that in a moment) but I took some liberties and cut some corners in order to get to this point. Once we have a full set of packages, I'll throw them in to experimental for people to play with, but right now they're not going to be much fun for anyone.

I couldn't have gotten this far this fast without the help of Daniel Stone, so a big thanks goes out to him. Not only has he been great about showing me just which packages to steal from and where, but every time I ran in to some obscure bug he had already been there and quickly pointed me to the way out, often with a package update ready to go. The packages he made are wonderfully simple and easy to understand, which let me get moving on them right away, and they'll form a wonderful basis for the future of Debian's X distribution.

On a further note, I've asked the release team to let us upload 6.9 to unstable when it's released, which should be next week. So far there's been no objection, and a bunch of people have chipped in so far to help out with the xlibs-dev transition. Thanks to everyone who's been helping out so far with getting 6.9 in. 6.9 will set the stage for the modular packages, by giving everyone the most up to date drivers for the next few months and taking the pressure off of me to deliver the modular packages right away :-) My goal is to ship the modular packages with etch, and I'm going to keep working to do that, but 6.9 should keep people happy until those are ready for unstable.

I've been relatively quiet lately because I've been plodding along, working on modular packages for Xorg. For those who don't know, the next release of Xorg will actually be two releases of the same code. One release, 6.9, will be based on the old monolithic build system. This system requires me to build every single part of Xorg whenever I want to update any one part. This means that whenever I push out an Xorg fix, no matter which component it's in, you have to download all the other components even if they are 100% identical to the previous version already on your hard drive. We've all lived with this for a long time, and while it's not pleasant, we all seem to get by. The packaging apparatus for this system is mature, stable, and well understood, if complex. That's why I've been able to get the 6.9 release candidate packages out to experimental fairly quickly after they are released.

The other release happening is for 7.0, which is obviously a major version number bump. The actual code you run for 6.9 and 7.0 is 100% identical, but the build system has been totally rewritten around the venerable autotools (you know... configure /make/make install). Each piece has been split out from the others so that you can build any one component without building all the others. This means that if we want to ship a driver update, you don't have to download all of the fonts and other things that weren't touched. That also means that you won't have to install the drivers for cards you don't own if you don't want them. Furthermore, it lowers the barrier for things like hacking on X significantly.

The problem with the modular tree is that the packages for it are brand new. Ubuntu shipped modularized versions of the libraries, and I've already stolen those, fixed them up for Debian, and built them locally (they're sitting in our svn repo, but running them won't get you anything at this point.) The server and driver packages are brand new, and I've been taking the packages from Ubuntu's development branch and working on them for Debian. Today was a milestone day because in addition to the libs, with Daniel Stone's constant help I've finally managed to build packages for the modular X server itself. Now I can't run it yet (I haven't packaged the drivers and a few other bits) but the fact that I managed to produce what will be a functional server package is a huge step, and constitutes the cornerstone of the whole thing.

Once we can create packages that can actually run on at least the machines of the XSF, we can start looking at getting the packages in to the archive. Since these aren't well tested like the monolithic packages, we'll have to do a lot of polishing to get them to the same level of quality. My goal is to get that done for etch though, and I think we can do it. Exciting things are happening, and I'm hoping that the modular packages will encourage more people to hack on X, leading to even more exciting things. Build that momentum.

Xorg 6.9 RC1 packages for x86 are in incoming and will hit experimental tomorrow. Enjoy!

Long time no blog I guess. Things haven't been that exciting on the Debian front for me. Many of you may have noticed the Xorg -8 packages just hit unstable, complete with minor annoying debconf bug (fixed in svn now). That work was almost all packaging bugs, most of which are now taken care of. All those changes apply to the 6.9 packages too, so it's like I'm getting a two for one. This means that the 6.9 packages will be pretty well cleaned up on the Debian side of things when they actually ship. Thanks to Sven Luther, Julien Cristau, and Ari Pollak we can build 6.9 for powerpc, sparc, and amd64 (although there's currently an unrelated bug on amd64 stopping us from building any X packages there). Hopefully we can get the remainder of the arches ready to go so that we can drop 6.9 in to unstable as soon after it's released as possible.

One of the very cool changes that's come about lately is that David Mart nez Moreno has taken up the torch for xterm and produced a package for experimental. xterm never really lived at X.Org, and now we're getting it from the real upstream source. So thanks to David we'll have an up to date xterm ready to go with 6.9. It's sort of a little taste of the modular tree: if you need to get an xterm update for some reason, then you don't have to update all of X in the process.

Terrifyingly, I've reached a point where I can start working on the modular packages the moment I sit down to do Debian work next time. I'm going to repeat what I did with 6.8 and start with the Ubuntu packages and work from there. Now that I know a little more about how the whole thing is laid out I feel a lot more confident in what I'm doing. Last time it was really by the seat of my pants. The scariest thing for me is that I finally have to break down and learn the autotools, which is something I've managed to avoid until now. That should be the biggest hurdle for me in moving the modular packages forward. I have no idea how long it'll take, although history has shown that my time estimates are about 1/3 of the time that it actually takes to do a thing :-) The first third of what I set out to do (get Xorg in to Debian) is finished. The second third will be when 6.9 is in testing. The final third is when the modular packages that I'm happy with land in testing. It may take the entire etch release cycle to run this marathon, but I feel like I've reached the halfway point around now, with 6.9 stabilizing.

I've started talking with people about where to go after all that. Once the Debian packaging work is done, I want to start working on the Xorg codebase itself, preferrably on making the xserver a little nicer on the user. I have a project or two in mind, but I don't want to start on them until Debian's X packages are well in hand for the forseeable future.

Thanks to Mr. RM, Xorg has hit etch, thereby unblocking the transitions of gnome, kde, and anything else X-related.

Furthermore, if you check experimental today, you'll find i386 debs for 6.9rc0 (aka 6.8.99.900). It took a little (well... a lot) longer than expected, but there they are. Getting debs for other arches will take some time, but they should be on their way. As ever, please don't report bugs to my blog. That's what the wonderful reportbug program is for.

Two major milestones in one week. How's that for progress?

I didn't make it in time for dinstall today, but I uploaded xorg-6.8.2.dfsg.1-6 to unstable a few minutes ago. Most of the fixes aren't that exciting to the average user, but we did clear out a few developer-related bugs that are holding Xorg out of testing. The big thing is that David Mart nez Moreno kicked some serious ass and not only fixed a lot of those RC bugs, but he even backported the savage driver from CVS HEAD! So savage users, you've now got the latest stuff around.

Meanwhile I've been whittling away at 6.9rc0. I've finally managed to produce packages and run the thing, so the majority of it is good to go. Once I got the basic build issues worked out, Michel D nzer suggested that we switch the way our xserver-xorg-dbg package was built. In the past, the code that loads the individual drivers and other modules in to the X server was a source of serious problems, and because of that the debugging server was built entirely staticly linked, with every driver and module built in to the thing no matter what video card you had. For 6.9 the default loader has been switched to a much better one, so Michel suggested we make a more normal -dbg package. This sounded like a good idea to me, so I spent a few days working that out, and it seems to be finished. There are 100 files that I was able to remove from the debian packaging dir (a lot less to keep track of!) and the -dbg packages for all the libraries in addition to the xserver have shrunk considerably. As such, these packages should take up less space on your hard drive, should you ever need to install them.

With that out of the way, we have a few more things before I can actually upload 6.9rc0 to experimental. Upstream has split out xterm and we'll be doing the same. xterm has lived at Thomas Dickey's website for a long time now, and we're finally going to start using that as our primary upstream for the program. David Mart nez Moreno has volunteered to take this on, and he already has the work done, it's just waiting for an svn repo creation. I also need to update both the render and xrender packages in experimental, since Xorg requires both to build. Once these things are done, 6.9rc0 will hit experimental, hopefully beating rc1 out of the gate. From there, some basic tuning on 6.9 will be ongoing while we work on getting the 7.0 packages moving. Things are happening, and while they might not be as fast as I'd hoped, I'm pretty happy with how they're progressing.

After seeing everyone shill for their favorite scm lately, with most of the predictable ones getting the attention, I thought I'd throw my choice out there, just to see it represented.

I primarily use svn with my work on X in Debian, and it's a wonderful system. Fortunately though, I don't have to maintain the repos, and when something goes wrong I can cry to our beloved DPL to get his admin on, and he fixes things up. This works out fairly well for me as a basic user, but I don't want to be dealing with these sorts of hassles for smaller projects. The distributed scm thing appealed to me in this sense, so when arch started to become a serious buzzword in the Debian crowd I had a look.

Well, more than a look. I fought for over a month with tla and baz and found that they were both so unuseable and poorly documented that I couldn't do more than scream and cry. bzr looked cool, but it wasn't ready (I sorta tried to manage one of the X.Org releases in Debian with it and failed miserably). Darcs was slow and in a minority language, which was a major turnoff for me. And I don't have a ton of diskspace, so git was out. Svk struck me as a hack (it still does) so I didn't want to go with that. Monotone was ok, but not good enough, so I sighed, gave up, and went back to svn thinking that this was as good as it could get. Indeed, we added a quilt-based patch system to the Xorg packages, so now I have a mini-scm (quilt) inside an scm (svn) and it works amazingly well.

But one of my friends just got hired by the people who make Xen, and he mentioned that they used mercurial, and asked if I had tried it yet. I scoffed and said no, and that all scm's suck harder than anything has ever sucked before, but I had a lot of time to kill while I was waiting on an X build, so I gave it a look.

Mama, I'm home. I was stunned that I was able to pick up mercurial in about half an hour after tearing my hair out for over a month with arch.

The UI is apparently very darcs-like (by accident, according to the mercurial author) which is known to be fantastic. Branching, merging, etc is simple as can be so far, although upstream is still working out better methods to deal with merging.

It's very fast, built for large trees (i.e. the kernel) so it will be suitable for managing X with (although I haven't tried this yet, but I plan to). For X, I'll need something fast to keep my sanity. This rules out darcs and baz (which has somehow managed to get amazingly slow in addition to being difficult as of late).

Unlike git, it keeps changesets in xdelta format rather than storing whole files, so it doesn't eat my hard drive.

It's written in python, so it's something I could hack on if I want to.

It supports an easy server setup with apache, and you can push your repos and serve them via static http if you don't have a server, like me.

Like monotone, it exposes hashes to the user, but unlike monotone it also provides a local revision number to make sure you don't spend all your time copying and pasting hashes, which is what put me off from monotone.

It has a fairly small command set, with 39 commands in the current tip (i.e. HEAD) as opposed to the > 150 in baz which made me weep.

It feels like using bzr, except it's here now and ready for production. Indeed, it's already used in production in making Xen.

There's a bunch more that I won't talk about, mainly because these are the things that have grabbed me. A note of caution is that I've only been hacking on local projects by myself (mainly configure-debian) with it, so I don't have the tons of real world experience with multiple trees that the thing is built for yet. I'm thinking about putting up a parallel mercurial tree to the XSF tree just for fun (the svn repo would remain the canonical one) if people are interested and I can find a server. I hope though, that all the people out there who, like me, were bouncing around trying out scm after scm and never being quite happy with any of them at least give mercurial a fair chance. I'm still amazed at how much I like it, and I think some others might feel the same.

A number of people have been asking for the X.Org 6.9 Release Candidate 0 packages I promised a little while back. I don't have them because I haven't been able to build them yet. I've managed to build 6.9rc0 itself, but not actual packages as of yet. Debian makes various alterations to the standard build, and these have been causing snags. I'm currently working my way through various build failures one at a time as they come, crossing my fingers each time I run dpkg-buildpackage. Hopefully in a few days I'll get packages ready, but I can't really give an estimate since I don't know all the build issues until they've been solved. I won't be able to work on X packages for a few days starting late in the week for various reasons, so things may be delayed. I still want very badly to get 6.9 pre-release packages in to Debian before 6.9 itself is released, and I'm going to keep at it until that happens.

In the meantime, hopefully the 6.8-5 packages recently uploaded to unstable will tide people over. Thanks to Jean-Christophe Dubacq, who provided easy drop-in patches of backports from X.Org's CVS HEAD, the -5 packages have the most up to date i810 drivers available. Many people reported problems with the old version of the driver, and this backport should help out with some of those issues. I've blogged previously about the other various features in -5 that were added, so I won't repeat them here. You can also read the massive changelog for -5 to see for yourself what we were up to while waiting for our own build dependencies to get fixed. I have to admit, looking at the changelog, I'm proud of our team.

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.

It seems like everyone and their grandma is asking me about things like nvidia-glx and other things that X.Org breaks in the archive. Yes, we know. Yes, it was planned. The breakages are due to things like the C++ ABI change (transition from gcc3 to gcc4) which causes any issues you might have with libglu1 or xlibmesa-glu. Those two packages are dead and will be phased out. So any packages still depending on them have to be rebuilt and re-uploaded. This is how unstable works, for those of you running it at the beginning of a release cycle for the first time. Things break and the fixes filter in as time goes on. So your options are to either hold off on X.Org or install X.Org and lose access to a few programs temporarily (or 3d acceleration with NVidia drivers also temporarily). How you decide to run your system is up to you.

Also, please note that I'm not going to respond to bug reports and such in official packages in my blog. So those of you reporting such things in my comments section, I won't reply. Please check the debian-x mailing list archive as well as the BTS for such things, and if you find no such bug then please report one in the usual manner (I highly recommend reportbug, especially when reporting a bug against X).

Oh, and for those of you who are new to it: Welcome To Unstable.

I wish I could say that the subject says it all, but that's not quite true.

First off: it's true that X.Org has been uploaded to unstable. Steve Langasek talked with the gcc maintainers and they decided that X.Org wouldn't block gcc4, so I got the approval to upload. Steve, as ever, is awesome.

Then Daniel Stone noticed that the packages are missing updated MANIFEST files for many of the ports. These files were put in place in the X build system long ago so as to manage to complexity of new upstream revisions. Because there's just so much stuff in the X source tree, there had to be an automated way to deal with making sure everything was present and accounted for. The end result of this is that if a MANIFEST that we have doesn't match up with the one generated while building the package, the build will fail. So what's going to happen is that with this upload, some architectures will get the X.Org packages, and others will not due to build failures. I uploaded i386 packages, so that will definitely go through right away, and ppc, sparc, amd64, and I believe mips should all go through as well.

The reason we went with this plan is that when the builds fail, the build logs will give us a diff for the MANIFEST for each arch. So what I can do is use those to fix the MANIFEST files tomorrow, rebuild as fast as my laptop can manage, and upload the -2 revision which has correct MANIFEST files. Steve, Daniel, and Ryan Murray all directed me in deciding on this plan, and I owe them a ton for all their help.

Already we've hit a build error in s390 that we're working through, but hopefully we can get all the ports in line ASAP so that this can transition to etch. But here it is. After a long wait and lots of work by lots of people, X.Org is finally entering Debian.

I think I need a glass of scotch.

Today was a very good day. One of those days where somehow things just go very well.

First, I managed to debug a problem at work over which I've been tearing my hair out for the past year. This means I can start generating some real data tomorrow and maybe even graduate one day.

Second, I checked my mail to find that kick-ass ftpmaster Joerg Jaspert has approved almost all the modular packages I uploaded to experimental. This includes the protocol headers and libraries which are a big chunk of the whole. He also gave me some stuff to fix up on two packages which didn't make it, so I'll be working on getting those two ready ASAP, but simply having some of the mass start to enter experimental is nice. Note: I seriously do not recommend running the modular stuff yet from experimental, since the change from X11R6 to X11R7 introduces a serious change that will break unless you know what you're doing or have a full X11R7 system (which you won't). I'm not even running 7.0 yet outside of a chroot, which brings me to the next item...

Third, I finally managed to get the modular X server running entirely from what's packaged in our svn repo. This is a huge step because it means that I'm getting much closer to the full functionality offered by the current 6.9 packages. This is a major milestone for me personally, because I'm starting to see the end of what I set out to do when I took on the Xorg packages a few months ago. It also gives me a serious hope for shipping 7.0 with etch. Needless to say, I'm pretty happy.

Today my boss asked me for a method to clearly umount and afterwards eject a CDROM media on the event of trying to eject the tray using the drive button. I googled around a bit and found auto-eject-cdrom, in the public domain, and originally written by Jens Axboe, from SuSe, and Peter Willis, in 2001 and 2005 respectively. The problem with this little application is that it was unable to eject both my boss drive and mine. It did umount the filesystem but did not eject the tray. So I dig into the code and found that it used plain, old cdrom events, handled by the cdrom kernel module. The event was, in fact, defined in <linux/cdrom.h> as:
#define CDROMEJECT 0×5309 /* Ejects the cdrom media */ I found out that using system (”eject”); as my quick and dirty solution after the umount was working ok, but I was losing performance because eject is used for ejecting floppy disks, tapes and several other media. In fact, eject can figure out which media is he working with so he selects the proper method of ejecting, but I was bitten by the curiosity. So I implemented both the cdrom commands and the SCSI commands for ejecting the tray, in two functions, copypasted from the eject.c, previously apt-get source‘ed and I’m putting this interesting piece of code to the public domain (most likely it should go with a GPL license, since I used GPL’ed code on it) here: auto-eject-cdrom v0.3. A relevant and important piece of code goes now:

        /* Here I use two different methods for ejecting the CDROM. This is for fun only,
           since I could use system(\"eject\"); but this is the dirty hack. Here I use the only
           two CDROM-related eject functions from the eject.c file of the eject program
           by Jeff Tranter (tranter@pobox.com) - Note by Jose Parrella  */

Installing is just a matter of compiling and copying to /usr/local/sbin and running it as auto-eject-cdrom &. I hope it’s useful for those of you who can not afford to use one of the keys of your keyboard to assign the eject command to it. Enjoy!