The Gnash project is still the most promising solution for a Free Software Flash implementation. A few days ago the project announced that it will participate in Google Summer of Code. I hope many students apply, and that some of them succeed in getting AVM2 support into Gnash.

I m once again on the program committee for the Linux Security Summit, so I d love to see people submit talks, attend, etc. It will be held along with the Linux Plumber s Conference, on September 8th in Santa Rosa, CA, USA. I d really like to see more non-LSM developers and end-users show up for this event. We need people interested in defining threats and designing defenses. There is a lot of work to be done on all kinds of fronts and having people voice their opinions and plans can really help us prioritize the areas that need the most attention. Here s one of many archives of the announcement, along with the website. We ve got just under 2 months to get talks submitted (May 27th deadline), with speaker notification quickly after that on June 1st. Come help us make Linux more secure! :)

So far I'm quite pleased by quality of GSoC applications we receive for phpMyAdmin. Tightening our applicant guide seems to be good idea and getting people active early and discuss the proposals seems to filter out the bad ones. This also means that we will probably receive much less applications than last year. We've received 64 last year and we're not yet at half of the count, while only three days are left for students to submit their proposals. Anyway take this as friendly reminder that not much time is left, especially if you want to receive some feedback for adjusting missing bits in the proposal.

Filed under: English Phpmyadmin 0 comments Flattr this!

Mandatory warning: What follows is for testing only, and insecure (root all over the place, giving access to host devices from the container, etc.). Problem of the day

• It d be nice to package Wayland. It s been split in several repositories: one for the core protocol/library implementation; one for the demo compositor and clients.
• Easy? Not quite, mesa needs to be rebuilt against the library. Doing so on a system running stable doesn t seem too good: some newer libraries might be needed; and using make install could make it harder to remember additional bits installed all over the place ($DESTDIR is our friend but that might mean more work on the build system side to get everything detected).
• What about having the whole development environment running in a Linux container? That s what I investigated.

Giving Linux containers a try

• Start from a squeeze system.
• apt-get install lxc, read its README.Debian, get the mount point set up.
• Copy the /usr/lib/lxc/templates/lxc-debian template somewhere as lxc-squeeze, and edit it:
  • Replace dhcp-client with dhcp3-client.
  • Replace lenny with squeeze.
  • Specify a better mirror than ftp.debian.org.
• Create a lxc-test directory, and create a container: ./lxc-squeeze -p lxc-test.
• Start the container, which gives access to a console: lxc-start -n test -f lxc-test/config (the test name passed through -n can be used to call lxc-stop -n test). Use root/root to get in.
• Edit /etc/apt/sources.list to point to sid instead, and dist-upgrade (using squeeze to start with means fewer headaches while bootstrapping, in case sid breaks or gets into some transition).
• Try lxc-stop and lxc-start to make sure the container can be stopped and restarted at will.

Getting devices

• First things first (and unless I missed something), udev + LXC = fail. So let s install it, note that it can t be configured, edit /var/lib/dpkg/info/udev.postinst, add exit 0 at the top, and dpkg --configure udev.
• Now, some devices are needed under /dev. Using mknod would be too easy, that s called a container for a reason. So let s edit the config file (the one passed to lxc-start earlier) to add a few devices (see below for an example).
• Once that done, restart (lxc-stop/lxc-start) the container, mknod on those devices is now possible.
• Input devices are not considered here, only video output is wanted for this test case. [This post might be edited if some examples get added later.]

Example, with a Radeon card, KMS enabled, let s assume those devices are wanted:

crw-rw---- 1 root video 226, 0 Apr  5 02:34 /dev/dri/card0
crw-rw---- 1 root video  29, 0 Apr  5 02:34 /dev/fb0
crw------- 1 root root    4, 7 Apr  5 02:34 /dev/tty7
crw------- 1 root root    4, 8 Apr  5 02:34 /dev/tty8

Note the major, minor right between owner groups and dates, and edit the config file accordingly, adding those lines (watch the syntax, it doesn t like extra whitespaces):

lxc.cgroup.devices.allow = c 226:0 rwm
lxc.cgroup.devices.allow = c 29:0 rwm
lxc.cgroup.devices.allow = c 4:7 rwm
lxc.cgroup.devices.allow = c 4:8 rwm

Once the container restarted, create the devices:

cd /dev
mkdir -p dri
mknod -m 666 dri/card0 c 226 0
mknod -m 666 fb0       c 29 0
mknod -m 666 tty7      c 4 7
mknod -m 666 tty8      c 4 8

Getting serious

• apt-get install xorg
• startx
• strace -f can help diagnose issues. If /dev/dri/card0 shows up with ENODEV, an old libdrm could even remove that device, so running mknod is needed again (but not sufficient)
• A likely cause of such issues might be that an X server already ran (or is still running) on the host system. Disabling the display manager on the host, rebooting, and trying startx from the container again should give better results (that s what happened here).
• If startx just works , just use ^Z then bg to put it in the background.
• Move on to installing a random window manager (e.g. awesome) and mesa-utils, and enjoy!

Enjoy:

export DISPLAY=:0
awesome &
# this is not a benchmark:
glxgears &
# direct rendering:
glxinfo egrep '(direct renderer)'

which printed here:

direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on ATI RS690

Today was the 30th annual Race That's Good for Life 5k race in Oak Park. I had run this in 2003, 2004, 2005 and 2006 but not afterwards as the spring marathons got in the way. As I am now on a more relaxed (and seemingly non-marathon ;-) schedule, I was able to participate again. Really nice to leave your house fifty minutes before race start and cycle over... And kudos to the Oak Park Runner's Club who once again put a nice race together. Given the lack of (more intense) training, I am also a lot slower: 21:50.7 was the chip time, or a 7:02 pace. We will see if I ever get faster again. On race day I am usually motivated; it remains to be seen if I get over to the track in the early morning to push myself through some speedwork.

Now that I have access to the serial console on Samsung e60 reader let s build a new linux kernel for it. The e60 reader has an ARM processor, to compile the kernel we need a cross compilation toolchain.
The first option is to use the one Samsung released with the other sources. It must work, however I don t really like the idea to run binaries from unknown sources.
The second option is to build our own toolchain, we often have to do that for systems that requires patches on the compiler.
Here, Samsung s binutils look like they were taken between 2.17 and 2.18 release (they are named 2.17.50 but are still slightly different from this snapshot) but they don t seam to embed homemade patches. As for ggc I didn t take time to check.
I choose to use the emdebian cross-development toolchain lenny version. (As the article in the french open silicium magazine #1 about FriendlyARM proposes to do). Installing the cross-development toolchain on debian First the archive keys:

sudo apt-get install emdebian-archive-keyring

Then we add a /etc/apt/sources.list.d/emdebian.list file with the following content:

deb http://ftp.uk.debian.org/emdebian/toolchains lenny main
deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main

The we update the package list to install the needed packages:

sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

That s it ! We have now our cross-compilation toolchain installed from packages, so easy to update or remove. The kernel sources Samsung released it s modified 2.6.29.4 version. By cloning the kernel 2.6.29.y git branch, I could quickly see that their changes applied well to the 2.6.29.6 version (the last in the branch). In order to better sort the changes michel.s had splat them into several patches
(patchs on e60-open project). After a few trials I build a series file allowing to apply those patches with quilt or better to import them to a git branch with git quiltimport. The order I choose allows to drop easily some patches (the last ones). One particular point on those patches is that some include binary files:

• fs/rfs/*.o a proprietary journaling layer over FAT. If you want my point ov vue, we don t need that. After all we have free journaling file systems available and linux is able to mount something else than FAT over USB
• drivers/usb/gadget/file_storage.o also the corresponding .c file was removed, the BSD/GPL license from the original code allows a binary distribution (however I didn t check if Alan Stern s name appears in the doc) but I d have liked that Samsung give that source code.

U-Boot Before compiling the kernel, we need the mkimage utility from U-Boot. Here, Let s build the U-Boot released by Samsung, and let s just copy the tools/mkimage to a location in our PATH (that s the only install method I could find).

make smdkc100_config
make CROSS_COMPILE=arm-linux-gnueabi-
cp tools/mkimage ~/bin/

Building linux For the config, one of the patches includes a .config. That file is a copy of config_rfs so even without the previous patch, we can get Samsung s config. Finally we can compile!

make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage

We can then load our kernel by following The kernel testing howto from e60-open project. To load the kernel we will need the following command:

sudo dnw arch/arm/boot/uImage

That it, and it works ! Well almost, the kernel cannot find his modules. This will not be a big deal for the ones included in the sources (but the subject of a next post) but the /lib/modules/max14540.ko and lib/modules/dhd.ko modules are not included in the sources while reporting a GPL license to the kernel. Missing source code The Samsung Open Source Release Center website has a contact form, but it does not seam to work (I even booted my netbook on windows to try with IE8 without success). After browsing the french e60 forum I found their email address and mailed them, no answer so far (not even automatic). Let s wait Conclusion We can compile a kernel for the e60 reader without using the cross tools from Samsung.
There still some work to load modules as the one on the reader are copiled for 2.6.29.4 and our kernel does not want to load them. (I ve already done a few tests but that will be a next posts topic.)
But without the missing sources it will be hard for us to best use our e60 reader. Update: I got an answer from Samsung, they updated the released archive. I still have to look at it.

So, the last countdown to Paris marathon started today for me. One week left. Nearly last run before it, today, with a quiet 12.5km trail at marathon speed. The point was testing my legs one week after the Eco-Trail 55km run. I'm balanced. Things seem to be OK but running 42km two weeks after such a hard trail is really like jumping in unknown water. I feel a small pain in my right leg. Not something really worrying, just not perfect at all. The hard choice is the starting pace. I'll probably be as careful as possible, with something like 5'25"/km, which should end up in 3h48'. If things are OK at half-marathon distance (OK being "perfect"), then I'll try to speed up slightly to 5'20", trying to hit the 3h45' mark. This one is probably the very best I can do. If things aren't OK, then I'll probably slow down from km 15, or even before, and try to keep up with 5'40" and stay below 4h. Marathon start is 8h45 in Champs-Elys es. Eh, maybe Zack and Ralf will show up in Bastille neighbourhood, between km 23 and 24, as they did last year. I should be there between 10h50 and 11h05 (watch the red cap!). Now.....just rest, drink, eat pasta and sleep!

I hope that registration for Debconf 11 will open soon as....I just booked my flights..:-) I'll be leaving Paris on Monday July 18th with EasyJet (wish me luck...but they were noticeably less expensive than Air France) and be back on Sunday July 31st. See you in Banja Luka!

Since I m soliciting donations to support my Debian work, the least I can do is explain what I do. You can thus expect to see an article like this one every month. Multi-Arch work I updated the code to use another layout for the control files stored in /var/lib/dpkg/info/. Instead of using a sub-directory per architecture (arch/package.type), we decided to use package:arch.type but only for packages which are Multi-Arch: same. dpkg is taking care to rename the files the first time it is executed with write rights and then updates /var/lib/dpkg/info/format to remember that the upgrade has been done and that we can rely on the new structure. I filed a few bugs on packages that are improperly accessing those internal files instead of using the appropriate dpkg-query interface. I sent a heads-up mail on -devel to make other people aware of those problems in the hope to discover most of them as early as possible. After that, the work stalled because Guillem went away for 2 weeks and thus stopped his review of my work. I hope he will quickly resume the review and that we will get something final this month. With the arrival of dpkg 1.16.0, it s now possible to start converting libraries to multi-arch even if full multi-arch support has not yet landed in dpkg proper. See http://wiki.debian.org/Multiarch/Bootstrapping for the detailed plan. If you re curious about Multi-Arch, you might want to read this article of Steve Langasek as well. Bug triage for dpkg in launchpad At the start of the month, there was close to 500 bugs reported against the dpkg package in Launchpad. Unfortunately most of it is noise many of the reported bugs are misfiled, they show an upgrade problem of a random package and that upgrade problem confuses update-manager which tries to configure an already configured package. This generates a second error that apport attributes to dpkg and the resulting bug report is thus filed on dpkg. There are literally hundreds of those that have to be reclassified. Michael Vogt and Brian Murray did some triaging, and I also spend quite some hours on this task. It s a bit frustrating as I tend to mark many reports Incomplete because there s no way they can be acted upon and many of them are so old that the reporter is unlikely to be able to provide supplementary information. But in the middle of this noise, there are some useful bug reports, like LP#739179 which enabled me to fix a regression even before it reached Debian Unstable (because Ubuntu runs a snapshot of dpkg with multiarch support). I subscribed to the Launchpad bugs for dpkg via the Debian Package Tracking System (thanks to the derivatives-bugs keyword) and will try to keep up with the incoming reports. Misc dpkg work The ftpmasters came up with a request for a new field (see 619131) in source packages. After a quick discussion and a round of review on debian-policy@l.d.o, I implemented the new Package-List field. This should allow the ftpmasters to save some time in NEW processing, but we deferred the change for the next dpkg version (1.16.1) to ponder a bit more on the design of the field. I also fixed a bunch of bugs (#619541, #605719, #598922, #616096) and merged a patch of Mark Hymers to recognize the new Built-Using field. Developers-reference work The review process for changes to the developers-reference is not working as it should. And I suffered from it while trying to integrate the patch I wrote for the Developer duties chapter (see #548867). We purposely changed the maintainer field from debian-doc to debian-policy in the hope to have more reviews of suggested changes and to seek some sort of consensus before committing anything. But we don t get more reviews and deciding to commit a patch is now even harder than it was (except for trivial stuff where personal opinions can t interfere). In my case, I only got the feedback of Charles Plessy which was very mixed to say the least. I tried to improve my patch based on what he expressed but I also clearly disagreed with some of his assertions and was convinced that my wording was in line with the dominant point of view within Debian. We tried to involve the release team in the discussion because most of what I documented was about helping making stable release happen, but nobody of the team answered. Instead of letting the situation (and my patch) rot, I solicited feedback from the DPL and from another developers-reference editor to see whether my patch was an improvement or not. After some more time, I went ahead and committed it. It was not pleasant for anyone. I don t know how we can improve this. Contrary to the policy, the developers-reference is a document that is not normative, I believe the result is better when we put some soul into it. But it s a real challenge when you seek a consensus and that the interest in reviewing changes is so low. DVD shop listed on debian.org In February, I launched a DVD shop whose benefits are used to fund my Debian work. Shortly after the launch I used the official form to be added to the official listing of Debian CD vendors and offered a few suggestions to deal with vendors who are selling unofficial images (with firmware in my case). A few weeks later, I got no answers: neither for my request nor for my suggestions, I mailed the cdvendors@debian.org team directly asking for a status update and quickly got an answer suggesting that Simon Paillard usually does the work and can t process the backlog due to some injury. At this point no concerns had been raised about adding me to the list. To save some time and some work for the team, I added myself to the list since I had commit rights and I informed them that I did it, so that they can review it. Shortly after I did that, Martin Zobel Helas objected to my addition. I cleared some misunderstandings but the discussion also lead to some changes to please everybody: the listing now indicates that some images are unofficial and I have prepared a special landing page for people coming from the Debian website through this listing. Debian column on OMG! Ubuntu I have always been a firm believer that it s important for Debian to reach out to the widest public with its message of freedom. Thus when Benjamin Humphrey contacted the debian-publicity team to find volunteers to write a Debian column on OMG! Ubuntu, I immediately jumped in. I wrote 4 articles over there. The tone is very different from my articles on my blog and I like that duality. Check out Debian is dying! Oh my word!, Debian or Ubuntu, which is the best place to contribute?, Are you contributing your share? and Ubuntu s CTO reveals DEX: an effort to close the gap with Debian. It s a great win-win situation, OMG! Ubuntu benefits from my articles, Debian s values are relayed further, and OMG! Ubuntu s large audience also helps me develop my own blog. Work on my book I had lots of paperwork to do this month (annual accounting stuff for my company) and I did not have as much time as I hoped for my book. Still I have a updated a few more chapters of my French book and I certainly hope to complete the update during April. This means that the work on the English translation could start in may. Work on my blog Just like for my book, it has been relatively difficult for me to cope with my policy of two articles every week. But I still managed to get quite some good stuff out. I interviewed Christian Perrier (Debian s translation coordinator) and also Bdale Garbee (chair of Debian s technical committee). I finished my series of Debian Cleanup Tips with 2 supplementary articles:

• Identify cruft that can be removed from your Debian system
• Remove automatically installed packages

The removal of firmware is causing troubles to quite some users so I wrote an article explaining how to deal with the problem. A regular reader also asked me to write an article about Jigdo, I executed myself because it was a good idea and that he has been very nice with me: Download ISO images of Debian CD/DVD at light speed with Jigdo. Last but not least, I shared my package maintainer pledge which inspired my developers-reference patch (see discussion above). Thanks Many thanks to all the people who showed their appreciation of my work. The 324.37 EUR that you gave me in February represented 2 days and a half of my time that I have spent working on the above projects. See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

After getting past a series of silly errors gjay version 0.3.2 is now available. The source code was uploaded to SourceForge and the debian package has been uploaded to the FTP master site. This version fixes the linking bug that have been extensively reported in a lot of Debian packages. This is where you are using symbols of a library from another but not explicitly linking to it. It means some versions of GCC will fail to link. gjay will now create playlists for Music Player Daemon or mpd and get mpd to run them too. It does need for mpd and gjay to be on the same computer, or at least the same directory structure, so both programs know what file is. While gjay has a full view of the filesystem, mpd uses a relative one off its own concept of a root directory. As a result of the two music players, both the audacious and mpd client libraries are not linked to gjay but are linked at runtime using dlsym(). It means you don t need the audacious libraries if you like mpd or vice versa. I m not that experienced in using dlsym so hopefully I ve not stuffed it up; it works for me! In theory, gjay could pass its playlists onto other music players. The problem is knowing how to get the list into the player. After it does its sorting and randomising, gjay ends up with a linked list of file-names. Now for audacious or (with some caveats) mpd it is pretty simple because they use file-names but others don t do this. If you know how it is done with your favourite player then let me know.

Here I write a little bit about my experiences running GRUB2 with a PowerPC Mac (actually, an iBook G4), since the current documentation is lacking in many places (outdated, incorrect, etc.). Some of what I say is platform agnostic, though, and may be of interest to users of GRUB in general.

Basics using GRUB2 with PowerPC First of all, it is important to understand (at least superficially) how botting on a Mac works. One of the first programs that run in your Mac is the OpenFirmware. It works with more or less the same purpose of a BIOS in a regular x86 system. The basic idea is the same: get the computer running with whatever programs you want it to run. The implementation, though, differs quite a bit. First of all, OpenFirmware (OF) usually presents itself as a command-line interface that is programmable, differently from the common day BIOSes from x86 boxes. As it is programmable, it is more flexible, but this flexibility comes at the price of an increased complexity. I may write some things more in a future article, if there is any interest. For now, it just suffices to say that to get to the OF prompt in a Mac, you have to press a combination keys during the time that your Mac gives a chime when you turn it on. At that moment, you have to press (simulaneously) Cmd + Option + O + F. (Note: the Cmd key is the key that has an Apple drawn on it, usually on the side of the space bar).

Limitations of Open Firmware Differently from usual BIOSes of x86 computers, Open Firmware can read the contents of a partition in your HD (or other devices), as long as it is formatted in the original HFS format (not in HFS+ or one of its descendents). This is the reason why some older versions of Linux create an HFS partition in your HD, even if you don't intent to run or use anything besides Linux. The yaboot bootloader consists of, among other things, one binary that is understandable by OpenFirmware. That binary is a file called yaboot, after the name of the booloader. As an aside, you have to indicate to OF what is the file that you want it to load during the boot process, so that it knows what to do. The way to indicate this is to "bless" the file (and the folder that contains it). Some ways to bless a file are to, for example, use the bless command in MacOS X or the hattrib -b command from hfsutils. Files in an HFS filesystem have two attributes that many other filesystems don't: a creator ID (the "application" that created the file) and the type ID (which determines what kind of file it is). OpenFirmware, in particular, looks for files with the type tbxi for the bootstrap process. The yaboot binary is loaded by OF into memory and, then, control is passed to the yaboot program, which then reads its configuration file (yaboot.conf) from the same folder where the binary was in. The file yaboot.conf contains instructions for yaboot to do its job. The file yaboot.conf is very similar in construction to configurations of an older bootloader for x86 computers, lilo.conf. Also, in a way similar to what LILO requires, after you install some new kernel, change some parameter in the configuration file, etc., you have to run a program that will set up everything so that the boot process can know of your new configuration. With LILO, this command was called lilo, while with yaboot the command is called ybin (which, essentially, takes care of putting yaboot.conf in the bootstrap/HFS partition and blesses the yaboot binary).

Going to GRUB2 One of the characteristics of yaboot (which is left as an exercise to the reader to determine if it is a drawback or not) is exactly the way that changes in the configuration have to be copied to the special HFS partition: the step of running ybin. GRUB2 (and its older sibling, GRUB legacy) do away with that: during boot-time, it can understand the filesystems that you have in your computer and interactively load whatever you want from there, also from a command-line like OF, before any (regular) operating system has even been started. But how do you start GRUB2? Well, the way that this is performed is copying a binary to that special HFS partition. Here things start to be hairy, because GRUB2 has a lot of functionality, but it comes at the price of it consuming a lot of space (especially if you are using encrypted partitions or some kind of logical volume managements with some journalling filesystem that allows files to be compressed etc. on top of it). The list goes on. Usually, that special HFS partition only has 800KB, which, BTW, is the size of an old 3.5" floppy used with older Macs (note: due to some contraints on partitions and aligments of such partitions on cylinders, it is not uncommon for disk partitioning software to create partitions slighly larger than 800KB, but not much larger than that). A full-featured binary of GRUB2 to be placed on that HFS partition can have much more than those 800KB. But how do you get that binary, in the first place? And how do you fit that in the HFS partition?

Creating the GRUB2 binary To answer the first question, you have to construct it from your grub-ieee1275 package (I'm assuming here that you are using Debian or Ubuntu, but similar instructions may apply to other distributions). Then, a first step would be to create such binary with:

 mkdir /tmp/foo
 cd /tmp/foo
 cp -a /usr/lib/grub/powerpc-ieee1275/* .
 grub-mkimage -O powerpc-ieee1275 -o ../grub.img *.mod

The last command of these create an executable named grub.img that is callable from OF and which contains every module from grub-ieee1275. This executable that I call here grub.img is called, in GRUB2 parlance, the core image and it it seems to be named core.img in many systems. On my system, with those commands, the binary grub.img is about 1208KB, which is 50% larger than that 800KB partition. And you would like it to be much smaller, becase you want to still have your yaboot bootloader by default while you are evaluating your bootloaders (or using it as a backup plan). As GRUB2 follow a modular design, you can mix and match the features that you want. This already hints you to the way we can fit it in the HFS partition, and it is always the same story: just trim the fat.

Creating the configuration file You will also have to have GRUB2 configuration's file (or you will have to play with way more commands than you'd want to). An important distinction here is that you usually have 2 or more partitions on your Mac:

• the special bootstrap/HFS partition where OF is going to look at (I'll call it /dev/hda2 here);
• the partition where your / filesystem resides (denoted by /dev/hda3 here);
• some partition to hold /boot (I don't have one of these, but let's say that it is /dev/hda7 for our discussion purposes), usually containing your kernels and initial ramdisks.
• other partitions.

With this in mind, you can With Let's say that this last one, in Linux parlance, is /dev/hda3 (as is the case of this author), and optionally a partition where your Linux kernel resides (people usually use it to store the /boot subtree of a Linux filesystem). Let's say that this last one is /dev/hda7. Then, you would compose something like the following as a configuration file for GRUB2 (named grub.cfg):

insmod part_apple
insmod ext2
set root='(hd,apple7)'
menuentry "Linux"  
    linux /vmlinux root=/dev/hda3
    initrd /initrd
 

There are one two important points here that deserve more comments:

• Note that, differently from a regular x86 system, in a Mac system with only one HD the way that you specify an HD does not have a trailing zero. For instance, in the case above of the variable root, we have (hd,apple7), while in a "common PC" we would have the (hd part replaced with (hd0. That's something that you should make your distribution aware of, if they aren't yet. As an addendum, I don't know how it works with systems with more than one HD, as I only have (PowerPC) Macs that are notebooks. If you can share any experiences, please do.
• One point of caution here: what GRUB2 calls root is not necessarily the root of your filesystem (i.e., the partition that holds /), but the device that everything that is "not fully qualified" is interpreted as being relative to. The "not fully qualified" above means anything that is not prefixed with GRUB's device notation. As an example, (hd,apple2)/boot/vmlinux if fully qualified for GRUB's purpose, while /boot/vmlinux is not.

Putting it all together The next step is to just copy the files grub.img and grub.cfg to the special HFS partition. You can do that using hmount, hcopy, and humount or you can use the regular Linux hfs module to copy to that partition. Then, boot your system, get into the OF prompt and execute:

boot hd:2,grub.img

Here, the 2 above is a reference to my HFS partition. Substitute that with yours, appropriately. You will then see the common (familiar?) GRUB prompt and, from there, everything else that you know will (hopefully) work.

The list of modules that "Works for Me(TM)" As I mentioned above, I use a subset of all modules that come with grub-ieee1275 to create my grub.img binary. Here is the list of modules that I use and that gives me a reasonably sized bootloader:

bitmap.mod        datehook.mod  gzio.mod         lsmmap.mod      reboot.mod          terminal.mod
bitmap_scale.mod  datetime.mod  halt.mod         memdisk.mod     regexp.mod          test.mod
blocklist.mod     echo.mod      help.mod         memrw.mod       relocator.mod       trig.mod
boot.mod          elf.mod       hexdump.mod      minicmd.mod     scsi.mod            true.mod
bufio.mod         ext2.mod      hfs.mod          msdospart.mod   search.mod          video.mod
cat.mod           fat.mod       hfsplus.mod      normal.mod      search_fs_file.mod  video_fb.mod
cmp.mod           font.mod      ieee1275_fb.mod  part_apple.mod  search_fs_uuid.mod  videoinfo.mod
configfile.mod    fshelp.mod    linux.mod        part_msdos.mod  search_label.mod
cpio.mod          gettext.mod   loadenv.mod      parttool.mod    setjmp.mod
crypto.mod        gfxmenu.mod   loopback.mod     probe.mod       sleep.mod
date.mod          gfxterm.mod   ls.mod           read.mod        suspend.mod

Just for the record, my grub.img file has 624KB, and that can certainly be shrunk.

The command line that "Works for Me(TM)" to create the image Actually, I lied when I told you that I used the lines above to create my grub.img file, because I'm lazy and I don't want to type the .img extension. I also embed my configuration file in the binary that I create with GRUB2, so that I don't have two files to copy to my HFS partition, but only one. I do that with:

grub-mkimage -c grub.cfg -o ../grub -O powerpc-ieee1275 -d . *.mod

OK. No more lies here. The nice aspect of GRUB is that one you install that image, you don't have to touch that HFS partition anymore: you simply update your regular filesystem's /boot/grub/grub.cfg file (which is usually performed when you install a new kernel, at least with Debian) and you're ready to go. The good way to do that is to use a minimal configuration file embedded in your grub binary in your HFS partition that will hook into the system's /boot/grub/grub.cfg to read newer kernels and leave the HFS partition (and your system's NVRAM) alone. Here is what I am using right now:

search --no-floppy --fs-uuid --set=root 35d26869-f7c9-4852-a9b8-100314560c34
set prefix=($root)/boot/grub
configfile /boot/grub/grub.cfg

You will, of course, want to modify the file above as you install newer kernels (perhaps even that unsupported operating system from that fruity company, who knows?). Don't forget to change the UUID's, and partition numbers to fit your needs. Well, that's it. I hope that it helps somebody out there, as the information that I got otherwise was way outdated, incomplete, etc. to keep up with GRUB2 from these days. Now, let's go patch the tools that we have so that not everybody who wants to use GRUB2 have to learn about its workings. Oh, of course, you can now have your kernels in ext4, btrfs, xfs etc. partitions without the fear that your bootloader won't load them.

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).

1. Let s start with a few common bugs reported over the past few weeks:
   • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
   • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
   • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
   • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on http://pkg-xorg.alioth.debian.org/, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
   • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
   • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
   • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
   • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. libI810XvMC.so.1 in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
   • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
   • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
   • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
   • [KiBi] xterm: new upstream, to unstable.
   • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
   • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
   • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
   • [KiBi] libxp to unstable, nothing fancy, that s libxp
   • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
   • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
   • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
   • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
   • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
   • [KiBi] siliconmotion video driver: to unstable.
   • [KiBi] pixman: new upstream release candidate, to experimental
   • [Sean] last but not least: many compiz packages to experimental.

For the past couple years I had been reading very little, two or three books a year.

For the past month my average has been two books per week.

The culprit is the Amazon Kindle 3 I bought during my stay in the US. I just can not recommend it enough. For starters, it is quite affordable at $139. The image quality is wonderful, and reading in daylight or even in direct sunlight is pleasant. This is a welcome change from a backlit screen as the eyes get noticeably less strained. The format of the device is even more convenient than of a real book (the size is perfect for plain text, start thinking about the Kindle DX if and only if you intend to read PDFs). The Kindle is quite thin and convenient to hold (and you do not need to keep it from closing as with paperback bindings). Battery life is on the order of weeks. Extra functionality (e.g., web browsing) is available, but not convenient, but that is almost an advantage as distractions are kept at bay. The Amazon store is great, I have already shelled out over $50 with little remorse (my time is much more expensive than the measly $9.99 a typical book costs). There are quite a few free books around too. And to top it off, the "screensaver" with pictures of writers is a very nice touch.

The Kindle is also useful for going through longer articles you would normally be reading on your laptop. The Chrome extension Send to Kindle has worked well for me, do check it out.

The most important drawback of the Kindle is that it is slow to turn pages, so it is not easy to browse a book. Turning a page takes a second or so. This is extremely annoying when reading in non-linearly, e.g. taking in study material, when you constantly need to go back to check up details of previous material. A PDF interpreter is available, but the screen is too small to show a full PDF page (a Kindle DX or an iPad would probably be better) and scrolling is painful because of the delays. Wireless seems to drain the battery noticeably, there have been a few cases where I forgot to turn it off and found a dead Kindle a few days later. I wish the WiFi connection would manage itself intelligently somehow.

The Kindle drove the point home for me that dead-tree books will be going the way of vinyl soon, much sooner than I had expected. And for good reasons. Go order now if you do not have an e-book reader yet (and do not forget to order a sleeve too, given the time you will be spending carrying the device it will come in very handy).

If you have been using Lintian you may also know that it has some limitations. One of these are that Lintian always checks every package isolated from each other unlike other tools like piuparts. It has its advantages (such as not requiring all dependencies being present) but it also has it disadvantages. Currently Lintian emits a binary-without-manpage -tag if the package contains a binary without a manpage. At first glance this appears reasonable, but it really is too simple (#512645). Basically Lintian complains about the missing manpage even if the manpage will always be present. A simple case is package foo depends on foo-data, the binary is in foo and the manpage is in foo-data. A live example of this is gedit and gedit-common[1]. The problem is that Lintian does not know if a given package is going to processed or not. Lintian does have a few cross package checks; namely binary checks can see the source package if it is available. This can be done with a bit of clever sorting (quote from Lintian source code):
# [...] (the sort is to make sure that source packages are
# before the corresponding binary packages--this has the advantage that binary
# can use information from the source packages if these are unpacked)
This works rather well, but its scope is very limited. Particularly it is no help, if we need to check if the manpage missing in foo might be in foo-data. This is what #513663 is all about. In January I branched the Lintian code and started working on grouping packages from the same source together. Yesterday I finished refactoring Lintian to do just that. However, this in itself is not very useful if the checks cannot take advantage of this. So today I sat down and extended our manpages check a bit and posted the results to the Lintian mailing list. [1]http://packages.debian.org/sid/gedit http://packages.debian.org/sid/gedit-common

Today we gathered the representatives of different distributions that are present at GNOME.Asia to discuss what GNOME could do to improve its support for distributions that distribute it, especially in matters of long-term support. It is kind of sad that there weren t any representatives from Canonical nor Red Hat, but the discussion turned out really interesting and we learned a lot about the packaging habits of each other. Furthermore, there were several concrete leads that were explored, which will lead to proposals from the GNOME foundation to all distributions. Helping with long-term support The most widespread GNOME version in the LTS releases that happened recently is 2.30, which is used by Debian squeeze, Ubuntu LTS 10.04, RHEL 6, and Solaris 11. It looks like an accident, but on the other hand:

• GNOME 2.32 isn t really suitable as is for an entreprise distribution;
• Linux distributions agreed on a kernel version to support long-term, so this had an impact on their release schedules, and this might well happen again for the next release.

In the future, a decision to use a common GNOME release could, anyway, only come from the distributions themselves, not from GNOME. A proposal that many people agreed upon was to give distribution maintainers commit access to old branches that GNOME module maintainers don t touch anymore. This way they could share their patches more easily and make new releases of these old branches. This would imply, of course, setting up rules about what changes are allowed, that distributions would have to agree upon (how to treat feature additions for example). Managing bugs Currently it is hard to tell, for a distributor, whether other distributions are affected too and whether they have released a fix for that. It was agreed upon that Launchpad s feature of linking bugs between distributions, including version tracking, would exactly fill that need. One of the solutions would then be to add such a feature to Bugzilla, but it is a lot of work since currently it doesn t have any kind of version tracking. Another proposal was to deploy a new Launchpad instance to do serve as a hub between downstream bug systems and the GNOME Bugzilla. The condition for this to work would be to make it extremely easy to clone bugs between it and Bugzilla, and also if possible from the downstream bug systems. On the side-related topic of how not to crawl under bugs, it might be possible to get bugs forwarded with a single command from the Debian BTS to Bugzilla, using the XML-RPC interface. Upstream also considers that bugs sent to Debian are generally of higher quality than those from e.g. Ubuntu, and would be OK with us routing some of them directly to upstream (like we already do for Evolution). Communicating about the availability of patches Currently distributors are hardly ever informed that patches relevant for their distribution have been committed. They often learn of them by sheer luck while lurking on Bugzilla. The distributors-list ML is clearly the relevant media for that purpose, but it is clearly not used enough. It would need to be advertised more among both GNOME module maintainers, and among downstream maintainers as well. On this matter, the disappearance of the x.y.3 GNOME releases (starting with 2.28) was evoked. The problem was that most of those releases were about insufficient changes to justify e.g. stable updates in distributions. The proposed solution is to encourage maintainers of modules with bugs to fix to release new versions (through an annoucement on desktop-devel-announce), and to send a list of modules with new versions to downstream distributors so that they can integrate them. This avoids the GNOME release team the hassle of making a new release, while still giving distributions that use them some bugfixes. Providing a new service to LTS distributions The idea of having the GNOME foundation employ a person to gather, on the GNOME side, all changes that are relevant to older GNOME versions, and prepare new stable versions, was discussed. This would be a new service for which commercial distributions would need to pay a fee. It s not clear how this information would be privately disclosed and the impact on non-commercial distributions. But it doesn t seem likely that e.g. Red Hat would be interested since they employ a lot of core GNOME hackers who are already doing this job.

---

I don t know what impact these proposals can have on GNOME packaging in Debian, but apart from the last one that I find dubious, it seems that they could greatly improve our support of GNOME in stable Debian releases, be it by having more versions to upload during the freeze, or by having more stuff in point releases. Fr d ric Muller promised to come back to us with more concrete stuff.

Due to cockups and/or willful sabotage by the telcos my ISP relies on for its DSL services, I am unreachable by email starting early this morning (UTC) and until further notice. My primary MX is off the net, mail is spooling on my backup MX so nothing should be lost. <expletive deleted> Update 2011-04-05: stupid telco finally rebuilt the line properly. I m back, no mail lost at first glance and I m slowly digging into that pile of mail. If you don t receive a reply by tomorrow, please resend.

I'm sure you already heard the news about the new joined Canterbury Distribution, and are eager about details. While our teams are struggling to integrate all the existing infrastructure, it's my pleasure to announce that the first pieces of the collaboration are already available for our users. As a first measurement, a common Canterbury Package Manager, called cant will be made available in all distributions. It is already available for the distribution formerly known as Archlinux, and with the next mirror push will also be available for those used to run Debian. You'll be pleased to know, that the command line syntax isn't much of a change, you can still run cant search, cant install or cant remove, but future version will also introduce all the features known from the other distributions. Stay tuned for further updates of Canterbury Linux!

For the whole week, I ve been in Bangalore for the GNOME.Asia 2011 hackfest. I ve been delegated by Stefano to represent Debian here, and my employer EDF has agreed to cover for travel costs since they are very interested in first-hand information the future of the Linux desktop and sharing our work on scientific computing. It s been a really exciting week; I ve spent quite some time packaging missing pieces of GNOME 3.0 (well, the release candidate versions of course) in experimental, together with Fred Peters. I think it s reaching a usable state now, so we ll probably soon provide metapackages to make it easily installable. The latest developments of the Shell make it a very exciting piece of software, with a strong focus on usability. Many things were written about it, but in the end my main criticism would be that it lacks some functionality - for example, the combined clock/weather/locations applet will be greatly missed. The good news is that it is extremely customizable, and with all the libraries being made accessible through GObject introspection, there are many features that are accessible from it. If you know how to write JavaScript, now is the time to write your favorite extension. On the good news front, Vincent Untz also spent a lot of time improving the so-called legacy mode , which is more and more starting to look like the Shell without special effects, and with all the features from gnome-panel 2.x that are still here. We will try in Debian to cover all uses cases that there were for GNOME 2 with GNOME 3 technology, so that panel lovers are not left behind. I ve also proposed an update to the dh_gsettings proposal, which will provide the same functionality as dh_gconf and allow to easily set distribution-specific overrides. It is still missing a way to set mandatory settings, which might come as a problem for some corporate users, but this is planned for a future version of GSettings. Today, we re having a business track where I and representatives of other companies (Oracle, Lanedo, Dexxa) are sharing experiences about making money with free software. Unfortunately the local organizers didn t manage to gather many people, despite our being in a city with an incredible number of IT industries. Tomorrow, the public conference starts, and this should be the opposite: we re expecting around 1000 people, which is a great achievement for a free software conference. For an unrelated topic, being around so many GNOME hackers has some interesting side effects; I ve been added to Planet GNOME. So, hey, hello Planet GNOME readers!

Warning, this post is COMPANY CONFIDENTIAL, do not spread outside of authorized corporate internal communication channels. Today Nokia will announce that in order to increase investor confidence and foster brand loyalty all Nokia Symbian phones in the world will receive two free Nokia-themed games. The first game will be Angry Nokias Nokias have discovered that other phones are taking their market share away and now they are very, very angry! Fling cool and shiny Nokia phone and destroy the competition. Complete all free 30 levels and be first to collect all golden Ovi s by gathering MeeGo and Windows Phone 7 logos in the levels! The other game that is sure to be an instant hit among true Nokia fans will be the Nokia Ninja you are a humble user and sales people are throwing phones at you all kinds of phones. But beware most of those phones are not Nokias! Use your finger to slice trough the competition, rake up combos and achievements! But be careful you do not want to slice trough a Nokia phone! Only trough instant brand recognition you can rake up truly great scores in this game. Nokia connecting people. (P.S. Check the date)

In one of the corners of what is now know as Europa, there was a rich, prosperous and beautiful kingdom known as Trist nia. In the past, not that long ago, it had been a number of smaller kingdoms and caliphates, all with their own cultures, religions and ways of life. Wars, and series of marriages of convenience eventually configured what ended up being the united kingdom of Trist nia. Throughout the years, some of the unified cultures grew and flourished, while others struggled to survive in their ever-shrinking areas of influence. A required introduction Sometimes, the minor cultures would suffer due to oppression coming from the delegates of the King, who would ban any expression of these cultures, as they were seen as a potential threat to the kingdom's stability and unity. For example, just a few decades before the main subject of this tale, the predecessor of the incumbent King took power by force, after crushing everyone who opposed his uprise during a bloody and hard civil war. His reign was ruthless and he imposed draconian laws uppon his people: usage and teaching of the minor languages was banned, and everyone was forced to use the language of the Centr lia region, in public or private. After four decades, the majority of the Tristanian people were sick enough of the situation to consider standing against their fear of the regime and demand freedom, but repression prevailed until the old general died. His place was taken by the King's grandson even if the people had expressed, just before the Great War, that they had had enough kings and demanded a ruler they could choose directly. Of course, the new King seemed a lot nicer than who they had been suffering for ages, so when asked if they accepted the new situation, an overwhelming majority said yes . However, there was a region, Verd lia, where the majority said no . Things were actually more complicated. Verdalians formed a traditional, proud society, and while the years of oppression had undoubtedly weakened it, they had managed to preserve their very unique culture, language and traditions healthy. The Verdal language was really weird to the ears of Centr lians and even other minor cultures of the Kingdom, and erudites struggled to find its real origins, not being able to reach plausible conclusions. Verdanians, as we already know, were a traditional society, living in a land of deep and poorly connected valleys. Little they knew or cared about the complicated matters of Centr lia and other regions. What made them happy was to take care their sheep and cows, keep a good fire in their living room and, every now and then, enjoy one of their log cutting contests. The impositions of the former dictator were too much for them, and some of them started sabotaging, assaulting and killing some of the dictator's soldiers, agents and officers. This was a huge risk at the time; getting caught meant death penalty for sure, and at first, even people from other regions were in favour of these actions. However, this popular support greatly diminished when the new King took the throne, as these minority continued with the killings, while most of the people saw it was no longer justified. The Royal Ball One of the very first measures the young King introduced was to organise the Royal Ball of Trist nia , a major event through which the people of the different regions would be able to elect their delegates to the Crown. Every four years, a Great Ball contest would happen in Centr lia, and the winners would be able to decide by their own on some of the matters that affected their region. Verdanians would send a few teams of dancers, each of which came from different towns or areas. Some Verdanian teams were happy about the King and the new political situation, but other teams weren't so much. And some others, while being simple non-violent dancers, were known to be supporters of the violent minority who kept on harassing, assaulting and even killing in their struggle for freedom of Verd nia . The Verdanian groups aligned with the different culture of Verd nia (including those who were said to support the violent) tended to get a lot more points in the dancing contest, and a majority of the elected delegates were appointed by them, making it easier to pass laws and edicts that favoured protection of their ways, traditions and language. No matter how hard they tried, the dancing groups closer to Centr lia kept losing to the majority. After many years of dance contests, these groups used their closeness to the King's court to pass the Ball Law of Tristanian, that would ban any dancing group which didn't condemn the assaults and killings that kept happening in Verd nia. The unsurprising result was that, with less dancing groups participating in the following Royal Ball, the Verdanian majority was broken and new delegates, friendly of the Centralian officers, were elected. Many people who had been in favour of assaults and killings began to question this strategy, and this political movement's unity started to break. In the end, the dancers decided to part ways with the violent; they wanted to dance in the next ball, and to do so, they wrote a letter to the King, in which they explicitly expressed their rejection of violent ways, and their embracing of dancing as the only means to drive their political agenda. An objective reading of the new Ball Law clearly showed that this was enough: the text only said the requisite for a dancing group was to disavow all kinds of violence. This wasn't really expected in Centr lia, so they started to add new requirements in an attempt to keep this group from the contest: their decisive majority in Verd nia was at stake. The Royal Ball was nearing and registrations for the contest would soon close. The Centralian government first argued that the dancing group should reject the violence coming from the Verdanian extremists in particular. The dancers did it. Then they argued that the dancers were the same people who had been supporting violence in Verd nia for years, and obviously their violence rejection statement was a lie. The dancers struggled to find new dancers who had not been involved in past dances. But it was not enough. They then claimed that this dance group should be quarantined for four years, until they could prove they really were serious about their new non-violent ideas. The dance group made a plea to the Trist nian Supreme Counsel, a group of sixteen experts in law of the Kingdom, and argued that all of these draconian requirements were not part of the law that was being enforced by the King. Their appeal to the elder counselors was in vain, though. They ruled this dancing group was as criminal as the violent minority they had once supported, and should by no means take part in the Royal Ball. As a last, desperate measure, the dancing group reached an agreement with other Verdanian dancers to join forces. They would adopt a new name and new dancing costume colours. Many feared this would only end up in the ban of the other dancing group. Unfortunately, the end of this story has not been written yet, but it will be completed very soon. Only time will tell if things continue being very sad and unfair in Trist nia, or if the dance contest will once again be impartial, with legitimate results.