Considering that i won't be in Mexico for the debconf 6, i ask myself (and i think i'm not the only one), where will be the Debconf 6+1. Say to me that it will be in South America or Europe, please. :)

<span style="font-weight: bold;">Debian Python Modules Team</span> <span style="font-weight: bold;"><span style="font-weight: bold;"><br /></span></span>The group is receiving new members, old packages from these new members and of course brand new packages every week, to say the least. I would like to say thanks for those who joined and for buxy, fatalerror and arnaud. We're working on a lot of interesting stuff and QA in the packages, you will notice the difference in Etch. Btw, i hope to see just Python 2.4 (and not 2.3 too, since we already dropped 2.1 and 2.2) in our upcoming release and a lot of interesting modules already packaged and well supported (dpmt is working on this, right now).<br /><br /><span style="font-weight: bold;">pkg-gnome</span><br />I'm a newbie in the group, i'm cleaning up bugs (pinging submitters) and already did some work on the packages on our svn repository. Unfortunately my first upload (totem) was rejected due to some naming and compatibility issues with the browsers plugins (mozilla vs libxul). seb128 jumped in and saved us. totem 1.4 is still almost ready to go and the rest of the gnome 2.14 is entering the archive.<br /><br />Well, i'm counting the days to the debcamp. Hopefully i'll participate in: ltsp modularization (pkg-ltsp), cleaning up bugs (pkg-gnome) and do some utnubu (read desktop) related work on tasksel. Since utnubu-meta was rejected. :/<span style="font-weight: bold;"><br /><br /></span>

...do a lot of different things while your new Debian Desktop is booting.<br /><br />Well, it's clear that some people in the project are thinking how we can speed up the boot times (no unfortunately i wasn't at debconf). I would like to invite you to split your ideas in two groups: a) Good For Etch; b) Dreams. :P My point here is that with what we've today, without break too much stuff for sure, applying some work where it's necessary we will have something good in December.<br /><br />Btw, i ran bootchart on three scenarios, using the latest weekly built image of testing, installing the desktop task, see my results:<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973355&size=o">Boot without changes (gdm left out)</a> - 2 m 29 s<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973357&amp;size=o">Adding "CONCURRENCY=shell" in /etc/default/rcS (gdm left out)</a> - 1 m 46 s<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973356&amp;size=o">Installing insserv and following the instructions in its README</a> - *1 m 29 s*<br /><br />I would like to hear what's the status of this "concurrency" stuff in /etc/default/rcS (is startpar default in sid now?) and if it breaks something. The other point is that we could push insserv tests forward, please read the documentation and do it yourself preparing your own bootchart results for comparison.<br /><br />The next step would add LSB headers in our init scripts, that will take more time because it involves a lot of packages. I think if we can guarantee that insserv and its dependency tree is ok, then we have the needed headers but they're not in the packages. We could release Etch this way, and add this workload to the individual maintainers of packages with init scripts during Etch+1 release cycle.

Being improved as we speak for Etch, but needing testers...<br /><br />Quick howto:<br /><span style="font-weight: bold;">aptitude install gnome-desktop</span> <span style="font-weight: bold;">desktop</span><br />or<br /><span style="font-weight: bold;">tasksel install gnome-desktop<br /><br /></span>You can download the <a href="http://www.us.debian.org/devel/debian-installer/">testing weekly images</a> and select "Desktop environment" after base installation, if you want to help testing this from scratch.<br /><br />Some known issues are:<br />- It could boot faster;<br />- There's no visual consistency yet (login screen, splash and wallpaper);<br />- It doesn't fit in the first CD (it should, really).<br /><span style="font-weight: bold;"><br /></span>I'm helping with the current known issues and probably some more useful packages will be added soon in the desktop. By the way thanks to joeyh, kov and joss.<br /><br />Suggestions and general feedback to my email are welcome. That would be good if the people that i've contacted and once worked for a better Debian desktop start replying my emails.<br /><br />Closing, i don't want to work for extend the supermarket catalog. I prefer to focus on some fridges and if it isn't enough for all the users, they're free to install something more from the next fridge. Hint: Pick your fridge in Debian and work there, avoid this supermarket bloat!

Well, two days ago Jason Norwood-Young published in Tectonic the worst article about Ubuntu, Debian and the Ubuntu latest release Dapper Drake until now. I would like to point out where he's wrong here, just to clarify for Debian users my view on the subject.<br /><br />Source: http://www.tectonic.co.za/view.php?id=1026<br /><br /><span style="font-style: italic;" class="viewbody">"I can only guess where Ubuntu went wrong. The first mistake, I think, was its desire to be a bleeding edge distribution, rather than a leading edge distro. Basing itself on Etch, Debian's unstable release, could be a problem. When the early versions of Ubuntu used the then-unstable Sarge as their foundations, it wasn't a risk -- Sarge was on the cusp of being released. Etch, on the other hand, is brand-new, and far from getting a thumbs-up as a stable distribution."</span><br /><br />The truth is that Ubuntu Dapper Drake was never based on Debian testing that we will be our next release, that we already call Etch. Ubuntu spend some time importing packages from Debian Unstable (that we always call sid too) and merging them with the changes they had and applying new changes, adding more packages software and all that. For more information about Debian release cycle, check our <a href="http://www.us.debian.org/releases/">Debian release page</a>.<br /><br /><span style="font-style: italic;" class="viewbody">"I also wonder who is doing the up-stream support. Shuttleworth poached the best-of-the-best Debian developers for Ubuntu. So who's working on Debian? The hald bug has been identified as an up-stream problem -- a Debian problem in other words. Perhaps Debian doesn't have the man-power to run around fixing Ubuntu bugs. "<br /><br /></span>Mr. Jason failed miserably here. Considering that he's right and Mark hired the best-of-the-best Debian developers for Ubuntu, the hald bug that is a software <a href="http://www.freedesktop.org/wiki/Software_2fhal">from freedesktop</a> and not Debian, should be solved by the best-of-the-best, no? Perhaps Ubuntu doesn't have the man-power to run around fixing every freedesktop bug.<br /><br /><span style="font-style: italic;" class="viewbody">"Finally, there's the problem of prioritising. Ubuntu, at its heart, is a community project. Many of the developers are not Canonical employees and don't get paid to work on Ubuntu -- they do it because the want to."<br /><br /><span style="font-style: italic;"></span></span><span class="viewbody">Great, Ubuntu at its heart, is a community project and what Debian is?<br /><br />I think the guy isn't a troll, but he should be more polite with both projects, after all he likes the previous Ubuntu release without considering that we (Debian) had some input there. In other words if it works it's Ubuntu, if it breaks is it upstream's fault? He can't recognize that Ubuntu upstream isn't always Debian.<br /><br />Meanwhile:<br /></span> <span class="body"><b>"Comment added</b></span><br /><span class="body">Thank you for your contribution <b>Gustavo Franco</b>. <br />Your comments will be posted on the site as soon as they have been moderated by the editors."<br /><br />We will see which kind of moderation i'll receive there.<br /></span>

Well, after some issues it's true, the Python transition is still going on. No flames, after all i'm in the Debian Python Modules Team from the start, and i'm trying to burn the pythonX.Y-foo from quite some time. Hopefully we will see Python 2.4 as default in Etch and maybe 2.5 in too (without a new transition and weird package names), for this we need to squash some more bugs. Join us at irc.d.o / #debian-python.<br /><br />I haven't dedicated the time i should in pkg-ltsp group, but Otavio and others are doing this and i'm for some time just a tester, organized online meetings and all that. I've a branch ready to be carefully tested and merged with our main. There's now stuff coming in for sure and hopefully we will be able to add a 'thin client server' task and deliver it in time for Etch. :-)<br /><br />xchat-gnome (hopefully) is back, just sponsored the upload for Marco Cabizza (from pkg-gnome). The package is of course sitting in NEW.<br /><br />Have you heard about wotomae? We're all waiting wotomae... Go Arnaud!<br /><br /><worldcup>2 hours for the next Brazil game. The country is almost stopped (it really is) waiting and i'm done with mails and builds at the office, writing this blog entry warming up to go home.</worldcup>

Let me start with what makes me happy. I'm almost done "porting" gnome-tasksel from gtk+1 to gtk+2 (that libglade-convert thing is nice, thanks Guilherme). I need to upload the bzr repository, open bugs and contact the current upstream again. If they're not interested in the tool anymore i'm. I've some task related ideas that hopefully will be ready in time for Etch. Meanwhile, i do some python transition related uploads too.<br /><br />I am on vacation, and since i'm not miles away from my home travelling i've the motivation and enough free time to do everything Debian i ever dreamed, right? Sure, but not after somebody else inform you that this is almost game over from where you were. Bad news, no?

Sometimes you look at the NEW queue and feel bad, because in a way some old and new volunteers' work is there waiting somebody else (that is a volunteer too). If it happens for one time or two you don't consider this a real problem, but after some months the person will notice that it isn't uncommon and will feel frustrated. It's really hard to explain in words, so i see a lot of flamewars about the subject after so many years contributing to the project, and the result is questionable to say the least. Sometimes you need to say thank you.<br /><br />I'm on vacation and feeling motivated to contribute with uploads, so i haven't sent a VAC notice to any mail list. I'm on vacation from paid work, but doing my best for Debian. After some sponsored uploads and stuff that i uploaded by myself, i uploaded notify-python, a NEW package. I thought "ok, if i'm lucky in 15 days it will hit the archive and i can prepare the -2 upload from there". What? Thinking in a second upload before upload the first one? Yes. The fact is that we've a new Python infrastructure and i prepared the package to work over that, but just for our current default Python version (2.3). Technically it can work well with Python 2.4, but it wasn't strict needed for the first upload and after all "i've at least 15 days to do it better". No, i don't...<br /><br />notify-python was accepted today and the package count in NEW is 19. I don't need to, but i want to add the Python 2.4 support there right now. Why? It's hard to explain in words, as i said. I think others share the same feel and maybe it's time to keep the package count in NEW really low until Etch and maybe the fun will be back. It won't solve all our problems, but is really helpful. Those who feel the same after reading ACCEPTED will agree. Thanks ftp team: masters and assistants. Keep it going this way, if possible.

Christoph Berg (myon) is my hero of the day. He worked on <a href="http://bugs.debian.org/377673">#377673</a> and implemented task support on ddpo. You can now see a package overview for each task in tasksel, eg: <a href="http://qa.debian.org/developer.php?task=desktop">desktop</a>, <a href="http://qa.debian.org/developer.php?task=gnome-desktop">gnome-desktop</a>. This is a killer feature for keep the tasks healthy, helping tasksel users, aptitude users using tasks and new Debian users (debian-installer includes tasksel).<br /><br />Task list (except l10n related): database-server, desktop, dns-server, file-server, gnome-desktop, kde-desktop, laptop, mail-server, manual, print-server, web-server. There are a lot of l10n related tasks too, eg: swedish, swedish-desktop.<br />Tasks being considered: xfce-desktop, bluetooth.<br /><br />I did some work to put gnome-tasksel in shape (see <a href="http://bugs.debian.org/368518">#368518</a>), but this is still in progress. After this, the plan is write a new tool to suggest tasks on the desktop based on events. If you plug your scanner and you're using the tool, it can suggest you the scanner task. It will be in pygtk and will notify the user through python-notify that i already uploaded. Unfortunately, i don't think it will be good enough to be in Etch. My goal for Etch is put all the tasks in shape (at least the desktop related), and bring back gnome-tasksel.<br /><br />It's good to point out that the new d-i (post sarge) guesses and suggests to the user which task could be useful to install (just some, it won't guess between web and dns server of course) based on your hardware and partition layout.

Well, the GNU General Public Licence states -- as part of Section 3) of the licence that I must provide source code on request for no more than the cost of physically performing the distribution.

Given that the host this box is on actually costs me $110.95AUD every thirty (30) days to run, $9.90, as nice as that is -- still will cost me over $100 AUD to distribute the code at all.

No, that's the "I paid $20,000 to buy this webserver, and the bandwidth is $200 per gigabyte, and you're the only person asking for the source so you have to pay all of it" argument. The GPL isn't meant to cover the cost of a CD burner, merely the cost of the media and postage. It doesn't cover the cost of your connection, but it could cover the specific cost of the bandwidth (if you're charged per byte). If it genuinely costs you AUD5 to send 50MB or so, then fine. But you made it sound like the money was supposed to cover the time and effort you put into it, and that's not fine. If you're distributing GPLed binaries to people, you either give them the source at the same time or you provide the source at cost.

And, for what it's worth, the correct response to a polite note from a copyright holder requesting that you conform to your license obligations is generally to apologise for breaching their license rather than , say, posting a petulant whine. Especially if you're counting a request to conform to the license as a "request to remove the code".

I previously mentioned that my brand new Dell Inspiron XPS m1710 notebook broke down just a few weeks after I got it. It took from Wednesday to Friday to arrange for pick-up n the notebook. The DHL guy came to my house on Monday morning and picked my laptop up. He said that the official line on these is that I will get it back in a week, but usually they get them back in a couple of days. On Tuesday I received an SMS saying that my laptop has arrived to repair centre and then another saying that it has proceeded to repair. Nothing happened on Wednesday but on Thursday I received another SMS, again saying that it proceeded to repair. On Friday I finally called back on the XPS support line and got an answer that my laptop is fixed and currently is being tested and that I will most probably get it back on Monday as Dell does not use the delivery option to deliver on Saturdays. And finally today at 11.00 in the morning a DHL courier knocked on my door with my notebook in hand. There was a note in the package saying that the CPU has been replaced. All in all - 10.5 days from first report until the laptop is fixed. I assume that is the worst case scenario. The techs on the phone were competent, but did not have the information about what I went trough in their online diagnostics wizard and did not have the information about emails that I sent them. One tech answered me on the phone, but another answered my email. There could be more integration there. Also I could not find any way to see more details about the progress of the repairs on Dell website - that should be easy to provide. In an ideal world, in cases when it is clear that the problem is in hardware, but not in the hard drive, it would be great if Dell could provide a temporary replacement laptop for the time of repair and put the hard drive of my existing laptop into the temporary replacement notebook, so that I an contiue working like nothing happened. It might not be the same spec, but it must be easy to swap the hard drive in, so I suppose that means that the same model is required. Note: just as I was starting to write this post, a Dell Customer Advocate commented on my previous blog post. They sure deserve some plus points for that

I have always hated and despised the Caps Lock key. Not only it is useless to anybody who works writing code, sysadmining, or plainly writing real text, but its mere existence has degraded the work quality of millions of people's work. Suddenly, IT GETS NORMAL TO WRITE LIKE THIS - It's just a magic spell that allows you to get rid of those old-fashioned rules about the language, about where to write in which case. Even worse, in Spanish some people tend to think that uppercase letters do not carry accents, so they produce text that is, um... Lets say it is readable, but that's often an overstatement.
[switch context]
I have been a happy and loyal user of Window Maker since 1997, when Juan Pablo Romero pointed me to it (BTW, I found Juan Pablo's homepage after searching for some links to post here and finding his, very old and probably unmaintained, WindowMaker page), back in the time where one of my favorite webpages was Window managers for X - clear sign that I didn't really like anything I had been using. And with WMaker, I was happy for (WOW) almost ten years. I still am. But after last week's ugly XFS corruption episode, I decided to follow the trend among some Debian people, and installed ion3.
My impression so far, with two and a half days of usage? I LOVE IT. It is the only WM I've met that really comes from a different point of view, stating that what most so-called modern WMs offer is just counter-productive. It just stays out of your way, not providing any visual distractions, and limiting to providing screens and frames to organize your windows. It acknowledges that its target audience (in my life I'd never set up ion3 for my mother ;-) ) usually hates using the mouse if unneeded, and that there is little point in wasting screen real estate with docks and desktops with functionality. It just sits there waiting for you to command its working via the keyboard - of course, the mouse is also an option, but not the natural one.
Anyway, I won't discuss the beauty of ion3 here - mostly because I have only scratched the surface so far. I have loved it, let me tell you. A little more on this in a couple of lines... Just for my Spanish-prefering friends, I found this piece of text explaining what ion3 is about: Ion3: Rompiendo con los entornos gr ficos convencionales
[merge contexts]
My only grudge is that in its default configuration, ion3 becomes the 0wn3r of Meta. What is Meta? What some people call "the Alt key". That key that is not Ctrl, but has become a controlling key. And I'm a heavy Meta user - Remember that my favorite way of interacting with the computer is Emacs. Yup, the nice OS without a decent editor, nicknamed after "Escape-Meta-Alt-Ctrl-Shift". Rob me of my Meta, and the gained productivity might as well go down the drain.
Here comes the link to my first paragraph: Ion3 is very configurable. No, it's not configurable - it's programmable. The configuration files are pieces of Lua, a full programming language. Of course, this means you can do mostly anything with it... But you have to do it in the end. Editing ion3's behaviour is not just clicking on selectors - You can take a dive to get the feeling. It looks quite easy, but I yet have to get around it and start poking the configuration.
After mourning my lack of Meta, I came across a very useful post in Gregor Hermann's blog. Gregor, I owe you a beer or three - You not only gave me back my productivity, you also gave use to the most despised key in my keyboard. Two lines into XModmap, one line into a couple of Ion3 files (I have yet to be sure it is needed in all of them), and I now have a perfectly useful CapsLock key, which is the key I will manage my WM with. It just rocks! It stands in nobody's way, and I am sure I'll very soon grow used to it.

We just released Gobby 0.4.0rc4 (together with its library dependencies net6 1.3.0rc3 and obby 0.4.0rc4) with the hope that it is one of the last release candidates before the final 0.4 release. Our application tests all went very well, without any further desyncronisation. Please test this release, as we need to weed out any further bugs. From our point of view those packages should be usable for productive working, but your mileage may vary, of course. I will push this branch into Debian unstable as soon as the final release is available, to enter Etch in time. Packages are already in Debian experimental (which, of course, might require that unstable is also available on your system). For i386 only, though. I lack build machines for other architectures, and although experimental is autobuilt nowadays, builds would need to be requeued manually due to the bumped library dependencies. Backports to Sarge are not yet available, do not hesitate to request them if needed, it will be easier to backport them than it is for the 0.3 branch. Sobby is missing, too, as it needs some updates to be made in the course of this week. If you use Ubuntu Dapper, just follow these instructions. Changes from the last set of release candidates:

• Basic IPv6 support (uh, yeah... our contribution to Debian's release goal...)
• New --join and --new-instance command line options
• Window is now requesting user attention on new chat messages (the window's name is highlighted in both the task bar and the window decoration)
• User palette changes are preserved

For more changes between the 0.3.x and 0.4.x branch please read the NEWS file.

Sound Juicer "Don't Blow Those Brains Yet" 2.15.5.1 is out. Tarballs are available on burtonini.com, or from the GNOME FTP servers. Hmm, I've done very little here, and there are 91 open bugs in Bugzilla. This sucks.

• Update the icon cache on install (#348972)
• Fix intltool requirements (Kjartan Maraas)

Update: 2.15.5.1 is released, with a tarball that will configure.

In an attempt to clear out some of the stuff I never use, I've put a Thinkpad charger and a Lowepro camera bag on eBay.
IBM ThinkPad charger. This will charge most of the ThinkPads in existence, I don't know when it was introduced but I got it for my ThinkPad X22 (bought in 2001), and has since been used with an X32, a T40p, and a T43. Basically if you have a ThinkPad and the charger is not a brand new 20V Lenovo model (?60 range only as far as I know), this is what you want. This retailed at £50.
Lowepro Nova 3 AW camera bag. Good condition, excellent quality camera bag from Lowepro, capable of storing an SLR, 3-4 lenses, flash, filters, charger, and more. The bag is is dark grey and black. I've been using it to hold a Canon EOS-300D, 18-55mm, 50mm, 28-135mm, a Speedlite 380EX, cables and a number of filters. This retailed at £45. NP: Boys for Pele, Tori Amos

Beta 3 of debian-installer has been released recently and some people are wondering about the status of Debian on Linksys NSLU2. This ARM based device includes an Ethernet chip for which Intel provides a driver (based on some code which only recently became free software and which still requires some microcode which is only distributable together with a click-through license). During the beta 3 development process, I tested the installation on NSLU2 with my USB Ethernet gadget to make sure it works. When beta 3 came out, I wanted to integrate Intel's module and make unofficial images available. Marcus Better did some great work in the last few weeks putting the sources into a Debian packages from which the modules can easily be created. Unfortunately, they don't seem to work. My kernel oopses immediately when I insert them. I spent more than a day compiling the modules myself, trying various things, but to no avail. I have now given up and sent a call for help. What this means is that the unofficial images with the Ethernet driver are unsupported right now, even though Debian on NSLU2 works fine if you have a USB Ethernet adapter. In the long run, I hope to be able to support Ethernet using a driver which is currently being developed. The author has made good progress already and is aiming for mainline inclusion. I hope it will be usable on the NSLU2 in the next few weeks but it's hard to tell. There has also been some development that users may not directly see but which is important maintenance work. The firmware of the NSLU2 has a 1 MB limit for the kernel. So far, we have provided a special kernel for the NSLU2 but it would be better if we could use one generic kernel for all IXP4xx based devices. Together with Marc Singer, the author of APEX, we're now integrating his boot loader as a 2nd stage loader to work around this limit. In summary, NSLU2 development work is still being done, even though the in-built Ethernet is currently not supported. This problem will be addressed in the long run with a proper, mainline driver which will hopfully be usable in the next few weeks. Help with NSLU2 support is welcome because even though I'm still working on it, I now have a number of more interesting devices I'm currently working on (more on this later).

So where will search engines evolve to? With Google not doing many improvements to their search results page, I can see a certain group of users actually preferring other search engines. Live.com - Microsofts new generation - is so slow here, it's unuseable. And it actually doesn't have any benefits over Google. In fact, it looks like an mere ajaxified copy of Google. More interesting are the contenders Snap.com, Exalead and Clusty. Snap.com definitely has the prettiest Ajax interface of the three. It has keyword completion like Google Suggest, and will display a screenshot of the currently selected result. However it only displays one screenshot at a time; and since screenshots are most useful for finding again a page you didn't bookmark thats only of limited use. Clusty offers you the benefit of grouping the results automatically by topics. If you aren't very experienced at searching, this can offer huge benefits for you. Searching e.g. for "sports" with Google is rather pointless. Clusty actually gives you useful ways of refining your search. Exalead sits inbetween. It has an ajaxish interface (but isn't overdoing it like live.com), it has screenshots (but not as big as snap; you can get an overview with 12 screenshots per page which is IMHO much more useful; however there are still some slight bugs) and it has some clusterin (though not as good as Clusty, but you can select multiple clusters) Anyway, I'm looking forward to what these search engines become, and what Google will do to draw even with them. (Yes, I'm aware that some people like Google because of its minimality. But not everyone does. Some users will actually need search assistance such as offered by Clusty and to a lesser extend by Exalead.)

I fixed the known bugs in WebDVD, renamed it to VideoLink and uploaded it to Debian. To get it into Debian, I had to make it work with Mozilla/XULRunner 1.8 (roughly the same code base as Firefox 1.5) since Mozilla 1.7 is no longer supported. In the process of doing that I also fixed a bug in setting the nominal screen resolution - I tell Mozilla it's 40 dpi because I reckon that's the average resolution when the video is played full-screen - which is likely to change existing layouts. The sarge version still seems to ignore the claimed screen resolution which I'll need to investigate and fix as I really don't want layout to depend on which version of Mozilla was used. I have stopped procrastinating on finishing off the DebConf video files, put all the information I have into a database and used that to work out what's left to do. The answer to that was, not that much really. Based on the database you can see the status of all the recordings and final files which shows that we have all the final files for all the official sessions. About 20 of the final files (mostly Theora unscaled versions) have still to be uploaded, which will take a few days over my 448 kbps uplink. (Due to a deficiency of my schema, the lightning talks are shown as not having final files. Actually they just weren't split up into separate files.) I'm intending to produce 3 DVDs this time - two for DebConf sessions and one for Debian Day plus any Spanish-language material from DebConf - because these recordings just won't fit on 2 single-layer DVDs. There should be room for some extras such as Biella's recordings and the day trip, which I have still to deal with. I need to sort out menus for the DVDs. Please suggest good background pictures that can be distributed under the DebConf video licence.

I'm giving up on backporting SELinux to sarge. Too many changes are needed in too many apps to make them really compatible with SELinux. Nothing serious, but just lots and lots of small things. For example, the amavisd-new package will need a cronjob modification. This has already been resolved (somewhat) for unstable, but it means I would need to provide a modified amavisd-new package or a backport. I hope that when etch gets released end of the year (and I actually believe this will happen), many issues will already be resolved. But it depends of course on many people using SELinux in different settings. My most-annoying-issue with SELinux on Debian: cron bug #333837, open for some 300 days now. The debian cron package will backup e.g. /etc/shadow, which actually sounds like a quite inappropriate place for this task. And of course it's all in one file named /etc/cron.d/standard, instead of e.g. /etc/cron.d/backup-key-system-files or so, which I could then label backup_exec_t or something else to assign the special privilege of reading shadow files... It's bugs like these, unhandled for 300 days, together with having the impression of being the only one trying to get SELinux running and receiving basically no support by the SELinux upstream "community" (which is almost exclusively "enterprise", it seems). It's pretty much like everybody wants you to not use SELinux. Or in my case, not enable people to use SELinux on Debian, since I'm not just "joe average user", but actually trying to add SELinux support to the Debian distribution (which would help Ubuntu to get SELinux, too. The Ubuntu people seem to have given up on SELinux already).

We had an active day around here getting ready to fly off to wt:Odense in wt:Denmark for Wikisym. I finally debugged the last testing error with the MediaWiki 1.7.1 upgrade for Wikitravel, so I did a rollout this morning, and things seem to be working great. The Wikimedia team's rollout schedule -- they run the Subversion trunk version on e.g. Wikipedia and make quarterly stable drops -- has worked out pretty well. It's interesting to see the Free Software world moving away from "It'll be done when it's done" to "Here's what we have since the last 6 months, and it more or less works". It doesn't seem to be damaging the quality of the software released or the willingness to innovate -- more the opposite. And users seem to really appreciate not having to decide between "stable" and "up-to-date". Having a bleeding edge that everyone can afford to be on makes things a little less bloody. tags: free software mediawiki scheduled releases mediawiki wiki wikitravel

Burn I also started the insurance process for our Montreal local Burning Man event in September. All Burning Man regional events have to be fully insured, which is pretty annoying when you are paying for it and pretty calming when you've got a big bonfire going. Next up: toilets. This is the glamour of Burning Man, folks. tags: burning man regional montreal insurance

Baby carriers Maj, Amita June and I took a trip to nearby B b Dep t on Christophe Colombe and St. Zotique -- yes, non-wt:Montreal-residents, those are real street names -- to get some baby carrying units. Baby carrying is serious technology. A week before Amita June was born, we got this 12-foot-long elastic cloth that you're supposed to wrap around your body 4 times and the baby ends up in one or more of the various folds. It seemed like a good idea at the time, but trying to get a newborn into it turned out to be a real hassle. So, a few days after we came home from the hospital, I ran out to Bummie's on Mont Royal and got a black Heart-to-Heart shoulder sling. It's been absolutely fantastic -- the real workhorse of our baby-carrying needs. But as Amita got bigger, it got harder to go for long walks with her in the sling. So when we were at 2006 SxSW Interactive I ran out early one morning to the Walmart near our hotel and got a $12.99 umbrella stroller. Amita loves it -- go figure -- but the thing is about 6 inches too short for me, so I've developed a real hunch pushing it around. For our trip to Europe, we decided to shell out some serious dough -- far into the double digits -- to get major technology for our baby-carrying needs. We got a really nice stroller from Chicco with a canopy and comfy handles that reach up just about to where I need them, which is very nice. And we got a baby backpack -- porte-b b sac- -dos -- that Amita can sit in while I carry her on my back. That's by far the most fun for me so far. She cried like the dickens when we put her in, but pretty soon she was cooing like a dove. It was really comfortable for me, too. We're taking the backpack and not the stroller to Europe... we're both trepidatious about the choice and I hope it turns out well. tags: baby carrier amitajune maj