You really have to be a fucking son of a bitch for living in a world where you go out and see everyday’s people living on extreme poorness, unfairness all over the place, six year-olds performing like clowns on red stops and your fellow compatriots dying on the streets, among hundreds of all other kinds of shit happening. You really have to be one when, after all of that, you finally arrive and seat on your so comfortable chair and start blogging, working with free software or playing a movie on your iPod. We are all so cynic, and I’m particularly bitter. [ UPDATE: abrotman also pointed me to the term hypocrite. Yes. ]

Despite my previous choice to stick with an i386 system, I couldn’t resist any longer when I have seen that both openoffice.org and the proprietary Flash player were easily available in the amd64 port (not a fresh piece of news). I have thus just re-installed my main desktop machine which is now running a complete amd64 system. I have added this architecture to my unofficial packages repository, and all the arch-dependent packages in the unstable branch were re-built. Note that I do not plan to re-build packages available for the current stable distribution (namely etch). This might however change in the future if people show interest for
this. I have been able to build i386 packages in a chroot using pbuilder and cowdancer, which I will explain later in an article.

The laste week I started to work further on the (rejected) virtualbox package. The reason for the reject was that there were some license issues (the tarball contains code (c) Microsoft ... which has to be considered non-free). After working around this issues I found several other issues as missing copyright statements in some files (which makes them non-distributable) and some other problems concerninc the license of this piece of code. This is blog entry is meant to show that there is still work in progress Every other problem concerning virtualbox is removed, but I guess we'll have to wait for 1.5.0 for debian until innotek has remove these license issues. :S Maybe we'll can work around this license issues, but sadly I guess not :S

It seems like everything's coming up wiki these last few days. I guess it's just part of going to Wikimania -- wiki is in the air. For example, I'm glad to see that Wikispaces now supports OpenID for login. That's excellent news for the wiki world -- Wikispaces joins a growing number of wiki projects and wiki providers who support OpenID: WetPaint, Wikitravel, wikiHow, AboutUs, and many others. OpenID is really coming together as a global sign-on for wikis. This is good news, because it means we can start talking about distributed reputation systems for wikis, making for one big wiki family. I think it would be great if Wikipedia and Wikia were ready to come on board with OpenID sometime soon. It's unfortunate that OpenID deployment at Wikimedia is dependent on the single user login system, which is a huge effort that's taking longer than expected. Wikia is waiting to see what Wikimedia does. I tried out Wikispaces's OpenID support, and it seems pretty good. I got a spurious error when I logged in -- it responded to my automatically-provided nick, "Evan", with a message that made it sound like I'd just typed in that nickname. Other than that, it worked quite smoothly. Good job to Wikispaces, and real bonus for OpenID. tags: openid wiki wikispaces

udev 0.113-1 mounts /dev noexec, and this breaks the proprietary NVIDIA driver. So far I am inclined to revert the change, but I am soliciting opinions about applications mmap'ing PROT_EXEC /dev/zero and if it is a good idea and should be allowed, or not. Feel free to post to #435250.

I've been busy doing various things, so I've not had a chance to blog much lately. Time for a quick catch-up... We've had a bit of a development panic at work, so I've been working longer hours than normal. The scary thing is (and I've noticed this in the past too), I seem to enjoy the job more when there's real pressure involved. That's not to say I want it to always be stressful, but we've had more fun with a small group of us really concentrating on a single project, working well together. Outside of work, I've been really quite relieved to take a bit of a break from Debian stuff since Debconf has finished. Debconf (as always) was a really good way to be re-enthused about working on Debian, but it has taken me several weeks to get over it physically. I've finally finished upgrading all of my machines at home to Etch. In most cases it was easy, but the final one left was lump, the firewall/mail/web/foo server. I'd chickened out of upgrading it for quite a while due to the sheer number of services it hosts, and also the substantial amount of local config it therefore holds. In the end, things were thankfully mostly painless. The nice thing about doing the upgrade was that finally lots of new software has suddenly become readily available. Amongst other things, I've added iodine and openvpn, and now I'm looking into playing with voice over IP (probably Asterisk). My Nokia E70 has a VOIP client and wifi, so in theory I should be able to use my regular mobile phone as a voip handset on my wireless network at home and just get cheaper outbound calls. Yay! I visited my friend Matthew a couple of weeks ago, and also helped him upgrade/install his network of Debian machines. Unfortunately, his main workstation (dual AMD64 goodness) is still left just running Windows. BIOS/SATA RAID - just say NO! No matter what we did on that machine, we could not make it dual-boot XP and Debian without forcing him to reinstall it all from scratch. :-( The SPI board elections have just finished. Congratulations to the new mugs^H^H^H^Hmembers of the board, and best of luck in doing a good job. And comiserations to the people who lost - I'm sure most of you would have been good, useful board members too. We're having a final Debconf 7 wrapup meeting next weekend in York, where we're hoping to get the final conference report finished. There are a few more T-shirts to get finished and delivered to people and the sponsorship bags to go out, then it's all done for this year. It'll be good to meet up with people again anyway. Oh, and not long now until the big BBQ at my place. I've started getting some supplies in already, and I'm looking forwards to a bunch of geeks coming round to wreck my house again. Or something... *grin* Last but not least - I'm changing ISPs shortly. Noodles and Huggie have provided excellent service for nearly 3 years, but are exiting the business and moving on to other things. So I'll be moving my home ADSL back to UKFSN shortly. Hopefully the disruption will be minimal.

Being in any reasonably large free software project one tends to be confronted with endless little annoyances, frustrations and letdowns. Often it happens that these little things keep growing in our perception the longer they last and the more they trouble us. In these times it is good to be reminded that the actual thing we invest so much time and energy in is not those little issues that often annoy us so much, but the overlying ideal of free software which is still a great thing, even in view of all the little frustrations that we have to deal with when working on it. Yesterday I had one of these little experiences that just remind you, just how good a thing free software is:

• At Thu, 26 Jul 2007 14:38:49 I filed a whishlist bug against a software I recently started using.
• At Sat, 28 Jul 2007 19:04:35 the bug had been passed on to the software's upstream and I got an email from the upstream author telling me that the feature I wanted was already in the current development version of the software, where I could download the tar.bz2 and how to contact him on jabber.
• At about half to ten I downloaded the code, rolled it into a package and tried it, but couldn't get the new feature to work, so I wrote another email.
• An half hour later I got an answer telling me what I'd done wrong. I fixed my mistake, tested the new feature and found that it did right what I wanted. However, there was one more option I thought would be useful so I contacted the author via jabber.
• In the following 2.5 hours he implemented the additional option that I had asked for, renamed a button I found a bit unintuitive and fixed two bugs I discovered in the process of testing the new feature, sending me new code versions to test after every change.
• I am now using the software with the new feature I asked for and with all the options I wanted from a homemade package but expect the proper Debian package to show up in the archive any day.
• The whole process took three days.

... and this is exactly why free software (and the people in it) is so great. Because if there is something you'd think would be useful, all you have to do is ask and maybe lend a little help in testing and you got it. And this is why it's worth to put up with all the little annoyances, frustrations and letdowns that working with humans brings with it. Even if they sometimes seem to be overwhelming. PS: I know that there are also enough examples where things didn't go as smooth as this one. But this just makes it more worth and important to highlight and appreciate these examples where everything just worked out perfectly and not just take them as granted. So, inbetween posting rants and fuming at all the things that tick you off, how about if you think of a nice FLOSS experience you had and share it with the rest of the world?

Thanks to Centauri Dreams for the pointer to the ESA DARWIN proposal now here (high-resolution version also here). DARWIN is a space mission to detect the presence of life on other planets by spectroscopy: looking for biomarkers such as the presence of Ozone, water and methane together on terrestrial-sized planets. These are groups of gases that collectively would imply the presence of life. Unfortunately it appears that DARWIN is slipping: its not currently hardware-funded, and has a planned launch-date of 2020, having slipped from 2012. This is when NASAs alternative Terrestrial Planet Finder and Space Interferometry Mission have been defunded indefinitely. At the same time, the French COROT mission has just announced its first month-long series light-curves. COROT hunts for Earth-sized planets: it's a small space telescope that stares at the same patch of sky for long periods, looking for changes in the amount of light from stars that indicate a planet passing in front of a star. It has been much more successful than expected, having already announced its first exoplanet detection in April. NASA is also launching a similar mission, Kepler, in 2008. So we face the prospect that any day now we may know of Earth-sized planets in a Habitable zone, and yet be over a decade from determining if they could contain life. So do we have any other tricks up our sleeves? Other possibilities include the James Webb Space Telescope, the successor to the Hubble. With a launch planned in 2013, it would be able to determine some atmospheric features found in COROT detections, but would be too expensive to do the planet-hunting Darwin could do. Perhaps this could be imroved with occulters such as UMBRAS (thanks to enzo). Other novel detection missions include the Voyager Interstellar Mission (via), reusing exisiting 'end-of-life' spacecraft as telescopes. And finally, could ground-based telescopes do it? tests have just started on a new 10M telescope in the Canaries that could help; in terms of larger scopes, colleagues of mine in NUI Galway have been collaborating on the design of Euro50,a proposed 50 M telescope. Together with new techniques such as spectral deconvolution (via via) may help. Tags astronomy, exoplanets

Last night I had a Visual Migraine that was significantly worse than the previous ones. It started in the usual manner (flickering lights in my central vision and an inability to read text on a computer screen in a font that is normally quite readable) but then developed a new feature. Grey clouds appeared in the periphery of my vision which left me with only central vision which was obscured by flickering lights. About an hour later it was gone. I’m glad that I don’t drive much, such limited vision is enough to allow me to use public transport without serious problems (although crossing a road could be interesting). Spending an hour in a parked car at the side of a road waiting for a migraine to go away is not something I’m looking forward to.

Share This

The DebConf 7 videos needed some post-processing, mostly to recover missing pieces from tape. I've done a large part of that, but it's not yet complete. The video team to-do list has details of the recordings that still need work, and the sessions that we believe were not recorded. Please tell us if we did record some of these, and we will have another look through our tapes for them. The conversion to "publication" formats (i.e. small enough to offer for download) was started at the conference and I have continued this at home over the past 2 weeks. Unfortunately this has been interrupted by some hardware failures. It looks like the CPUs in two of my PCs were running hot enough to be damaged (slowly) but not hot enough to trigger an alarm or automatic shutdown. The remaining conversions will be running mostly on my laptop, which is pretty fast and should be able to finish conversion of the recordings that are in a good state in about 2 days. However, some of the converted files may be broken and need some manual attention. My upload bandwidth is only 448 kbit/s so the high-quality files will take about a week to upload. As ever, the video files are being published on meetings-archive.debian.net.

In my previous post, I briefly mentioned my K750i Sony-Ericsson mobile phone. I received it as a birthday gift this year, to replace my aging but trustworthy Nokia 3210 and, as with any multifunctional digital device, there was a learning curve during the adoption period. While some features were gladly and swiftly taken into use, some of the handset's usability issues became my pet peeve and, among them, the localization pack wins the jackpot. First, let's make one thing clear: I fully understand that memory constraints prevent manufacturers from including support for every language known to man, so a handset can only be loaded with a limited set of languages for the User Interface and for T9 predictive text input dictionaries. My issue is with the concept of grouping languages by linguistic families or continental areas, when compiling the localization packs for those handsets. In this particular case, I had a choice between the Baltic or Nordic packs. The former has UI language support for Estonian, Latvian, Lithuanian, Polish, Russian and Ukrainian, while the later has support for Finnish and the Scandinavian languages; English is also included in both cases. T9 support is a strangely mixed bag: the Baltic pack only includes predictive input for the Slavic languages, while the Nordic pack supports all the languages of its UI. What's my problem with the above language combinations? For starters, I'm in Finland. We don't interact with Danes or Icelanders outside very occasional pan-Nordic meetings and that mostly concerns politicians. Meanwhile, average Finns travel for work and play to Estonia and Russia on a fairly regular basis, which makes sense, since they are neighboring countries. However, available language packs don't take this into account. How should this be resolved? Either language packs are produced with specific countries in mind, rather than generic geographic areas, or the users should be allowed to freely mix and match among all available languages and get the result flashed into their handset at purchase time. The K750i language pack for Finland should therefore include: Finnish, Swedish, Estonian, Russian, English and Norwegian (essentially the current Nordic language pack, but with Danish and Icelandic replaced with Estonian and Russian). Then again, this only covers official state languages. Sam dialects, anyone? I guess not, because we'd soon be exceeding the handset's capacity. Hmm... Thus, the only real solution is to allow people to freely mix and match UI and T9 languages of their choice at purchase time. As a bonus, this would allow me to drop Norwegian and replace it with Joual... ... c lisse, French and finally have a language pack that I can truly find useful. I can easily picture a Transylvanian engineer working in Finland wanting to get Romanian support or a Kurdish immigrant preferring Turkish support instead. Sony-Ericsson, how about it?

It is not fresh news, but I haven't had time to comment about it before. Very soon after launch of Harry Potter and the Deathly Hallows, which was only made available worldwide in its original English version, you can read a free and non-academic version in Spanish. Spanish Hallows project, built up by a bunch of Harry Potter fans have made completely ridiculous efforts of J.K. Rowling and hers publishers (Bloomsbury Publishing) to try to delay versions in other languages. Perhaps this was not made with other intention than to avoid early publishing of copies sent to translators, which, as you know yet, happened anyway. Once again we see how is not only impossible, but stupid, to try to keep information in this new environment. I am pretty sure that most of books, movies and music publishers will disappear soon. But not because of piracy: they are not being able to adapt their corporate business model to the new environment. And I am sure that there are little start-ups out there working in this new model, and some of them will succeed. But nothing new here... it is how business world has worked for years now.

The key to productivity is avoiding other work. The weekend has just started, and I've successfully hooked up a JTAG probe to a Linux box and implemented half of debian/xcontrol stuff. xcontrol is a preprocessor for control files that accepts an extended syntax and compiles that into a policy compliant debian/control file, losing bits of information on the way (but whoever cares can just look into the xcontrol file). For now, I am planning to support the following extensions:

Build-Depends-Tool:

An additional build dependency line useful in cross compiling packages. The normal “Build-Depends” is reinterpreted as packages required for the target architecture, while this line specifies packages required on the host during the build.

Build-Depends[release]:

This overrides the build dependencies for a certain release, and comes in handy when backporting. Of course, this is orthogonal, so -Indep and -Tool fields exist too.

Optional: yes

This package is not normally built; if you need it, you have to invoke the “build-package” and “binary-package” targets.

per-package Build-Depends*:

This allows specifying the build dependencies for “Optional: yes” packages without adding them to the main list.

The syntax is still debateable at this point. The non-orthogonality of Build-Depends-Tool is intended, by the way. :-) The transformations done to make this policy compliant should be obvious: Build-Depends-Tool is folded into Build-Depends, the release-specific Build-Depends are omitted (or selected if xcontrol is told to target a specific release), Optional is stripped out and the per-package build dependencies for all non-Optional packages are accumulated. I don't know whether I'm going to do templates yet, this will probably wait until the second release. More on the JTAG adapter when I have the gdb stub working. Now I'm going to go back to what I should really be doing.

So, let’s join the postings about the currently running Debian maintainers GR. The short text of this post is I am against the proposal as it is right now and think it does more harm than good and so I did vote for Further Discussion. See below for a bit more about my reasoning, or just skip if you are already bored. :) The current proposal does look like a “yay, we have an idea thats not really thought through. And we do not want to get it into the currently existing procedures, that would involve more work and discussions. And anyway, everyone is ranting about the current procedures anyway, so lets take that bad mood against it to get this done”. (And yes, this is a bit exaggerated, so don’t take it personal, please). As you may have noticed I wrote that I am against the current proposal when it first was on vote. I was mostly on vacation back then and didnt want to read the whole thread, so I stayed mostly quiet. I am not against the DM concept itself. I am against it being seperate to the existing NM procedure. For me a proper solution has to be integrated with the existing procedures, not seperated. The main reasons why some support this proposal seem to be

1. Slow NM process.
2. Someone doesn’t want to go through NM
3. Someone doesn’t want to be in the Debian community

---

Slow NM process I am part of this, and not a small one. And yes, I feel (very) bad about it, but already think about ways this can be changed, after I got the current backlog done. Anyway, for this DM thing my backlog isn’t the main reason that people feel NM is slow. It seems to be the general “I have to wait for an application manager and then answer to a lot of questions and between that wait and wait and wait”.

---

True. People have to wait at some points, and those waiting periods can be frustrating. We should do our best to eliminate those waiting places. The other point is that of the lot of questions. Yes, we have a really big set of questions in the templates, that cover a whole lot of the possibly areas a future Developer can work in. And most of those questions got added after a large set of existing Developers showed that they completly do not know something. That way the templates are constantly growing and still intend to give the future Developers the possibility to learn about things in Debian they might never have heard about. And there is the thought that, if you read about a topic and had to answer to it in the past, you will at least remember that there is something if you encounter it in the future. But - there is also the fact that an AM is NOT forced to use the templates for their process. AMs are, and have always been, free to do the process on their own. There are some questions every AM has to ask, but thats a minority. If you look at the templates you will spot the needed ones easily. Other than those every AM can freely do whatever he wants to do with his applicant (as long as the applicant agrees to do that stuff and its legal :) ). The AM only has to keep the following in mind: Both, FrontDesk and DAM, usually do not work together with the applicant. They might have heard the applicants name at some point, in some bugreport or some packages Maintainer: field. But they usually did not interact with them. Which means that the AM has to make sure that FD and DAM are able to build up their opinion of the applicant just by reading the mailbox of the AM->NM communication. Which usually means: read between 20 - 70 mails of a communication someone else had before you decide if someone should or should not enter Debian. (Leaving alone checking packages.qa, lintian, bug lists and a bit of google).

---

Someone doesn’t want to go through NM Erm. Well. Then use sponsors for your packages. Or is it because you think NM is too hard? NM isn’t that hard, everyone that can read and write english texts (even if the english is bad) and use google is able to pass NM. (For the bad english - if you fear joining NM because of that: Well. If I go and reread my own report from back when I joined - ugh. I hate my english. And I know native people still hate my english texts, its named en_GANNEFF for a reason. :) It is not necessary for your English to be perfect; you only have to be able to make yourself understood. If an AM doesn’t understand what you wrote they can simply ask for clarification). DM also doesn’t help for people that don’t want to pass NM. They have to pass the advocate, the ID check and the same minimum set of of questions NMs have (as written a bit above). So you already have a large part of NM for the future DMs.

---

Someone doesn’t want to be in the Debian community Then they shouldn’t be able to upload on their own. They can use sponsors. After all the only thing you must do as a DD is to read debian-devel-announce. And thats something a DM also must do, or you can’t seriously consider to package anything. And then DD only adds rights for you, like taking part in votes and so expressing your opinion and getting things changed in Debian that you may not like.

---

How to integrate a concept of DM then? First - by starting in the right area - getting it into the NM system by talking to all those involved. There is FrontDesk, DAM and also the NM-Committee, the latter should be the right point for a proposal and discussion. What I can imagine that would work and do something good is a system integrated into NM that gives future Developers upload privileges after they passed a few steps with their AM. That way they can upload early in the process, which can then be part of the T&S set, and the following steps in their NM process “just” slowly add more rights to the NM until its the set of rights every DD has. Seen from the current layout of the process it would be somewhere after the ID check and the first set of P&P, ie. at the time the AM sends the second P&P part. After that point the AM could recommend to those maintaining the DM list that the applicant should be added to it, together with a list of packages where the applicant is allowed to upload them. The maintainers of that DM list could be FrontDesk + DAM + maybe someone else, but thats something to discuss. And list of packages - while one could take the current limits the GR wants to set or simply a plain list, that can be amended during the time someone is a DM. Now, one can add a turnoff for people that do not want to pass through the rest of the process at this place. Im not sure its such a good idea, but thats something one can discuss. But if so it should be attached to some rules like - must read our debian-devel-announce list, is included in regular pings of activity similar to the wat ping.

I have recently been using virt-install on CentOS 5 to install some virtual machines (I previously posted a summary of the experience). One problem I had is the inability to do an install of Fedora to /dev/hda - it insisted on partitioning the disk and installing it on a partition. I have filed Red Hat Bugzilla #249837 about this problem. # n=1
# while true ; do dd if=/dev/vg0/orig of=/dev/vg0/dest bs=512 skip=$n count=1000 ; echo $n ; file -sL /dev/vg0/dest ; n=$(($n+1)) ; done After doing a CentOS or Fedora install I then have to fix things so that my desired option (of using a single unpartitioned virtual disk) is used. To do this I first needed to determine how many sectors at the start of the filesystem were used for the partition table. I used the above shell commands to test skipping different numbers of sectors and using file -sL to determine whether the result was recognised as an Ext2/3 filesystem. Below is part of the output: 62
/dev/vg0/dest: data
1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.018812 seconds, 27.2 MB/s
63
/dev/vg0/dest: Linux rev 1.0 ext3 filesystem data (large files)
1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.115528 seconds, 4.4 MB/s
64
/dev/vg0/dest: data
1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.018623 seconds, 27.5 MB/s As you can see 63 sectors are used for the partition table and other boot blocks at the start of the disk. So I used the below command to fix it:
dd if=/dev/vg0/orig of=/dev/vg0/dest bs=512 skip=63 The next problem after this was booting. The pygrub program that is used by the CentOS Xen installation to boot DomU’s only works with partitioned block devices. This however is quite easy to solve, I merely had to copy the kernel and initrd from the Xen image to the Dom0 filesystem and use the files for booting. Of course every time I upgrade the kernel I will need to copy the files, but that’s not such a great inconvenience. I usually end up running multiple DomU’s with the same distribution so I can copy the kernel and initrd once and use it for all instances.

Share This

It was on my todo list since ages, finally I took some minutes to set up my own jabber server (reach me at mika@jabber.grml.org). I’m using ejabberd, a free and open source instant messaging server written in Erlang. Reference system: Debian etch (current stable), ejabberd version 1.1.2-6, installed via a simple:

# aptitude install ejabberd

Adjust the hostname in /etc/ejabberd/ejabberd.cfg (I suggest to use something like ‘jabber.$YOURDOMAIN’ so you can update jabber’s DNS SRV according on upgrades, downtimes, moves,…):

 hosts, ["jabber.yourdomain"] .

Register an account:

# /etc/init.d/ejabberd restart
# ejabberdctl register username jabber.yourdomain password

You might want to give your username admin permissions, so adjust /etc/ejabberd/ejabberd.cfg according:

 acl, admin,  user, "username" .

That’s it. If you want to disable registration of users just use (instead of the ‘allow’ line):

 access, register, [ deny, all ] .

Restart the server and make sure you have a running server:

# /etc/init.d/ejabberd restart
# ejabberdctl status

Now you should be able to point your browser to http://yourdomain:5280/admin/ and set up your new jabber account inside your jabber client.

When learning some code I didn't know before, my usual way to get familiar with it is to first find some documentation or a kind spirit to help me understand the big picture, and then to run the code in a debugger or to do something like '/bin/sh -x', or some such, so that I can understand how it actually flows. That works pretty well with most software. One of the things with which it does not work, however, is gcc's .md files. As far as I know, there are no debuggers for those files; and even though Simon helped me understand a few things about it at Debconf, I'm still not confident enough to just start editing stuff. Additionally, just randomly editing a 7k+ LOC file and expecting those edits to magically work is not something I consider very likely to succeed. So, dear lazyweb: how does one debug gcc's .md files?

Yesterday it was "The Simpsons Movie" time—and it was hilarious! Don't miss it, you'll regret it. I had a pretty good laugh at quite a lot scenes. There is also the obligatory celebrity starring, this times it has Green Day and Tom Hanks in it.
What are you waiting for! Stop reading and go to the cinema!

I'm standing in the SPI elections on a very clear platform including cooperative values and principles and reviewing SPI against the good practice standards (last done in June 2005) so please go vote for me if you're an SPI voting member. Voting closes Saturday. The last turnout I saw was a disappointing 15%.