Eddy Petri or wrote quite an interesting text about the shortcomings of the .deb packaging format, specially comparing it to Gentoo's ebuilds. And, basically, it all comes down to this phrase:

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file

Now... Is debian/rules really expected to be a makefile, or it is just customary for it to be so? Look at the very top of your rules files - you will see they (at least, almost) always start with #!/usr/bin/make -f - That means, of course, that you can omit the fact they are makefiles. While packaging/debugging, I often run -say- fakeroot debian/rules build && fakeroot debian/rules clean. That, my friend, is closer to the invocation you often use for a shell script than for a makefile. I don't know if we have tools that rely on having rules called via make (and that should be easy to correct if needed), but I really don't see it problematic at a first glance to create packages based on something different than a makefile.
Recently, I've been tempted by CDBS. I still don't fully understand its flow, and it's still mostly a dark-magic beast for me, but at least I am comfortable using it for my everyday packaging work (hey, pkg-perl group, I'll be bugging you again with my weird ideas soon ;-) ), but it surely has the advantages you quote in your message: It takes part of the complexity away. Of course, it introduces some extra bits. By using CDBS, the packaging entry level is considerably lowered - but the real understanding of properly maintaining a package becomes somewhat more difficult.
Or is it just me clinging to the comfort of having learned my way around writing debian/rules?

Been trying out upstart today. It's a nice piece of code, but unfortunately it's totally useless today. Not because its concepts suck; rather, because Debian packages today ship with SysV-style initscripts, and those do not integrate well with upstart: most of the features that make upstart so interesting require you to create an event.d script, which has a totally different syntax. The Debian Developer inside me couldn't help but start to think about a way to fix this, but that seems harder than what it initially would sound like to the uninitiated. My first idea was to add some /sbin executable to upstart or one of its supporting packages, so that a SysV-style initscript could exit if that binary told it that upstart was running, before doing anything. That way, a package could ship both upstart event.d files and SysV-style initscripts during a migration period, and we could get rid of the SysV-style initscripts when and if Debian eventually decides to migrate to upstar. But when I sent that past #debian-devel, someone mentioned initng, which is yet a different init implementation. If this would work for upstart, it could also work for initng, and I don't think many packages would want to ship initscripts for three different init implementations. So scratch that. My next idea was to generate initscripts, rather than have packages ship them. The amount of common code in our initscripts is huge, anyway, and it's not as if it's all that hard to write an initscript. The things an initscript needs to do are limited, anyway: start a daemon when requested, stop it, restart it, perhaps send it a SIGHUP if or when configuration updates have been performed, and provide some useful output on all that. In most cases, that's about it. So, I thought, why not create an RFC822-style file (analogously to other files in the debian/ directory of a debian source package) containing all the metadata on an initscript, and generate the correct style of initscript out of that? That should work, I thought. So I started writing a specification, and had a look at the initscript of one of my own packages, nbd-server. Which does this at some point (nonrelevant content cut out):

i=0
while [ ! -z $ NBD_FILE[$i]  ]
do
  start-stop-daemon --start --quiet --exec /bin/nbd-server (...)
  echo -n " $ NBD_FILE[$i]  ]
  i=$(( $i + 1 ))
done

There's no way you'll be able to express that type of flexibility with an RFC822-style file containing all the metadata. So, scratch that too. I still do think generating initscripts is the right thing to do, however; the question that remains is "how". One idea I had was to use m4 in an autoconf kind of way, since autoconf allows one to mix autoconf macros with "regular" shell snippets, which would be exactly the kind of flexibility that one would need. However, that totally ignores the fact that autoconf is only able to pull this off because its output is shellscript in every case. An m4 macro that has to produce output which are not, in fact, shellscripts (such as would be the case for this project) could not do that. I think I'm kinda stuck now...

Welcome to this 8th issue of the DeFuBu contest, the almost monthly championship of the funniest bug reported to the Debian BTS. The challengers

• Pierre Tramo with #409352 (mplayer_1.0~rc1-12.diff.gz is CHAOTIC)
• Christian Perrier with #230485 (apache2/ssl-cert's debconf abuse makes baby jesus cry)
• Jeroen van Wolffelaar with #409637 (tasksel: [INTL:eo] kelkaj korektoj pri la esperanta traduko.)
• Steve Langasek with #410605 (dpkg: bzip2 code in compression.c incorrectly uses zlib define (Z_ERRNO))
• Josh Triplett with #412460 (magicor-data: Penguins don't have teeth) and #398276 (xdm: don't bundle turning on sit0 irradiating me all day)
• Mike Hommey with #413660 (RFP: mozilla-firefox -- Mozilla's firefox package is required in non-free) and #413714 (iceweasel: overflow:hidden ugly chopping characters in half)

How the vote has been done Four Debian related people voted, Raphael Hertzog, Jeroen van Wolffelaar, Ana Guerrero and Margarita Manterola. Full ranking Bugs

• #409637 (tasksel: [INTL:eo] kelkaj korektoj pri la esperanta traduko.) (34 points)
• #412460 (magicor-data: Penguins don't have teeth) (29 points)
• #230485 (apache2/ssl-cert's debconf abuse makes baby jesus cry) (26 points)
• #398276 (xdm: don't bundle turning on sit0 irradiating me all day) (23 points)
• #410605 (dpkg: bzip2 code in compression.c incorrectly uses zlib define (Z_ERRNO)) (16 points)
• #409352 (mplayer_1.0~rc1-12.diff.gz is CHAOTIC) (15 points)
• #413660 (RFP: mozilla-firefox -- Mozilla's firefox package is required in non-free) (14 points)
• #413714 (iceweasel: overflow:hidden ugly chopping characters in half) (3 points)

Challengers

• Josh Triplett with (52 points with 2 bugs)
• Jeroen van Wolffelaar (34 points with 1 bug)
• Christian Perrier (26 points with 1 bug)
• Mike Hommey with (17 points with 2 bugs)
• Steve Langasek (16 points with 1 bug)
• Pierre Tramo (15 points with 1 bug)

The winners

• Bug: #409637 (tasksel: [INTL:eo] kelkaj korektoj pri la esperanta traduko.)
• Challenger: Josh Triplett
• Bug reporter: Serge Leblanc
• Voter: Raphael Hertzog with unordered tierc : #412460, #409637 and #230485

Notes To participate, simply drop me an email with a bug number or a request to vote, or anything that may help. About DeFuBu

Of late I have been:

• Tracking the progress of #413926 and the fate of Wordpress in etch.
• Celebrating 3 years in the NM queue.
• Working on Debian Live. Check out my test environment. Daniel Baumann is currently rewriting make-live and I have begun a new project which I like to pretentiously call the Universal Web terminal. :)

The previous DPL races which I actively followed consisted of hectic discussions on the debian-vote mailinglist, multiple parallel long threads full of questions and answers. Given that there were 9 candidates this year (of which only 8 are left now, after Sven Luther left the race, I expected to have to write an insane amount of time-sucking emails to that list, and had somewhat prepared for that eventuality. Strangely enough, though, that hasn't happened. Since the campaigning period will come to an end this sunday, that'll mean that either most developers are waiting 'till the last minute, or that there simply aren't that many questions this year. I'm really hoping for the latter... then again, I would prefer that people actually do ask questions -- the DPL is an important position in Debian, and people really should be informing themselves before voting.

Debian used to be the cool kid among Linux distributions. Because our stuff worked much better, was easy to install and especially to upgrade. Dependencies would be automatically resolved while others were fighting dependency chaos, and our menus would have all the apps in it, where others had to fill their menus on their own. And at the same time, Debian was very flexible and could be customized to become e.g. Knoppix. Our bugtracking was great and we were openly discussing bugs and all this stuff. Many of these Debian achievements are now common among distributions. Especially among Debian-derived distributions. Debian however has become a reliable 'stable' distribution often even called 'stale', while others stand in the spotlight of innovation. Other distributions have come up with maybe more advanced bugtrackers (I'm not talking bugzilla, which IMHO is overengineered) and other tools. Technically, this isn't completely true. There are still many fields where Debian is technically leading. But our focus has recently been a lot about individual packages or components (e.g. the installer). Maybe we should try focusing more on infrastructure again. In fact, Debian still has some very good infrastructure components others might be lacking. Our QA tools (including bug counters, tracking which versions are affected by which bugs, all kinds of graphs, wotomae) are great. All our update-* commands are missing in many other distributions, also things like invoke-rc.d. We have a solid Python policy to support multiple Python versions and precompilation (judging from the SELinux policy, none of the other distributions has that yet). We're able to use dash as a minimal shell instead of bash in most places (which does make a speed and memory difference). We have Debtags. But these projects don't play a key role in Debian anymore AFAICT. Trying to start a major infrastructure thing requires a LOT of engagement, maybe too much. I'd love to see better SELinux support in Debian, but I can't do it on my own, it's just too much. And I find it very hard to find people to help me with that effort. If Enrico hadn't been pushing Debtags again and again (and with a lot of code), it would also have gone stale. Despite being IMHO something that can take Debian on top again (making it a lot easier to find appropriate software). One of the reasons why Debian is still living pretty much outside is that it would be a huge effort to get maintainers to add the corresponding Tag information to their packages and so on. I've always balked at even trying that, fortunately Enrico got some tag information added via overrides to the Packages file already. Another thing that should have been happening within Debian (but happened at Ubuntu) is 'upstart'. There have been a couple of packages dealing with new init systems, but none ever managed to get support into other packages (nor is there any package in Debian with upstart support that I'm aware of). Getting SELinux strict support into init ramdisks is another big thing I'm too scared of to even attempt... i.e. I doubt that I'll be able to do that on my own, yet even to get it into the actual packages... DPL candidates: any ideas on how to be come more agile in such points (e.g. adding support to sysvinit+upstart+initng+runit to all packages with init scripts)? It took us already ages to get LSB headers added to many init scripts. Or on any of the other transitions we should do (SELinux support, Debtags, ...), or even why we've lost this flexibility? The one idea I have for that is to try to do some hackfests. Like an init transition day, where a group of people tries to NMU most of the packages that have init scripts. Or adds "Homepage:" to most packages, which some important package metadata we only have on some packages. Or adding 'watch' files. Some of these would be easier if we had a common way of packaging and a central SVN repository. That would make it both easier to prepare the transition (e.g. committing init scripts beforehand) or especially for adding Homepage metadata and watch files without actually interfering with the maintainers work by not doing an upload immedeately, but just adding them to SVN so the maintainer includes them on his next upload. (Sorry, no comments enabled in my blog.) P.S. another thing I'd really love to see is a (semantic) PackageWiki for Debian, that has a Wiki-like structure with a page for each (Source-) package. Including things like e.g. Screenshots, Homepage link, Link to the Freshmeat page of the package, support lists/groups ... Kind of like the QA pages, but for the actual users, and editable by visitors.

Today is the GUADEC 2007 Call for Papers deadline, and submissions are still coming in fast and furious. However a few people who would submit a paper cannot do so today due to existing commitments, and as I'm an exceedingly generous individual the deadline is now extended until Thursday 15^th March. That's the day after the GNOME 2.18 release, so if you want to submit a proposal and have a GNOME Release Party then remember to submit then party. We also need more Lightning Talks. A Lightning Talk is simply a five minute presentation, so typically in an hour slot there will be ten or so talks on different topics. They are easy to present (being so short) and fun to watch (as there is a wide range of topics covered). They are a great way to announce a new project, demo something very cool (IIRC, David Reveman got a standing ovation when he demod Compiz in Stuttgart), or give a progress report. Submit your lightning talk today! NP: Foley Room, Amon Tobin

44 translated template files remain in the BTS. I will rest and wait for them to be uploaded. It’s not yet the time for Russian translators to panic :-)

So, that was the debate. Now I can stop and read the answers properly. It was a bit disappointing that one candidate (gustavo) didn't appear, one was late (sjr) and one withdrew on the day of the debates (svenl). I guess I'll see what explanations are submitted. The debate opened with a fairly gentle question, asking for introductions. Makes sure the process is working, I guess. Generally inoffensive, but Anthony Towns's answer is puzzling: shouldn't he have documented stuff during the last transition if he thought it lacking? If he's re-elected, there won't be a transition, so any documentation would be based on year-old memories... he's giving an argument for electing someone else! The communication question got a variety of responses. Not sure that Wouter Verhelst's aim of better team communications is achievable, but maybe it is - don't know without more communication from people who aren't currently communicating well! Not sure whether Steve McIntyre is arguing for diplomacy and politeness or the truth of the Sapir-Whorf hypothesis, which is more worrying. Releases. Oh! Releases. Aigars Mahinovs's plan to release less often is interesting, but is it realist or defeatist? None of the candidates seem keen to give NM the radical revision that I think it needs - the median time in DAMnation is longer than the median time for the whole of the AM-led review, contrary to what Wouter Verhelst seems to claim later (line 754). About the only reforms suggested are Anthony Towns making permissions more gradual and Steve McIntyre's (IMO scary) social conformance test. Each of the candidates sees a slightly different thing as debian's biggest problem, although some of them overlap. Maybe this is the axis that differentiates the candidates most? Also, a full range of "code of conduct" views seem to be there: from it being a good idea, through leaving it for others to try, to being opposed. Then it was onto the buck-passing round. Another communication question brought some similar responses and this absolute gem from Aigars Mahinovs:-

"A technical solution to a social problem - a cron job that will send the email every two months, 6 text files with a template saying that nothing has been done and I just need to remember to write something good into those files before they are sent."

I like that idea! A few technical questions brought some interesting reminders about work that is actually already underway, but maybe not very visible, then there was a question about other distributions. Predictably, most of the focus fell on Utnubu and other derivatives, with a few mentions of Gentoo too. The targetted questions brought a few amusing replies: at least one candidate seems to say that they won't pursue a past comment if elected, while Anthony Towns seems to see the new FDL and CC licences and GPL'd Java as personal achievements. The cage fight (or open discussion, as it is more usually known) spent most of its time emphasising and clarifying points from earlier. It only seemed to be at the end when it cut new ground, with questions about demographics and $10million. Finally, closing summaries again showed the differences of approaches and views. Then that was that and the participants logged off into the night...

• The debate
• The audience
• The sources

Russel Coker explained how to generate a local policy module from the error log. Note that this approach (audit2allow) suffers from the same problems that automatic policy learning suffers from (at least when not done very smartly). The generated policy will exactly cover the behaviour you had during logging; functionality that you didn't use is not covered, but misbehaviour that occured during this time is. Thats basically why SELinux doesn't use this autolearning approach considered a "benefit" of AppArmor by some (as you've just seen, you can do that with SELinux, too). So let me show you an alternate way: First of all, install the refpolicy-*-dev (from my experimental repository on alioth) or selinux-policy-refpolicy-dev (unstable) packages. Next you'll need an audit error to fix, e.g.:

audit(1173577161.426:3436296): avc:  denied    search   for  pid=23862 comm="amavisd-new" name="lib" dev=md2 ino=63745 scontext=system_u:system_r:amavis_t tcontext=system_u:object_r:var_lib_t tclass=dir

So that obviously is amavis trying to access /var/lib (you can verify this by checking that ino= is the inode number of this directory). Looking at /var/lib/amavis reveals that these files are labeled amavis_var_lib_t, so the amavis policy is lacking just this simple tweak. While Russel's approach would work fine, I'll try to show how this would be fixed in the actual policy. The approach I use is documented somewhat in the README.Debian at least in my packages. I'll create a file named amavisfix.te:

policy_module(amavisfix,1.0.0);
require  
        type amavis_t;
 
files_list_var_lib( amavis_t )

The name "files_list_var_lib" was looked up in the Refpolicy API documentation. Granted, it takes some time to get used to their naming scheme, but it's actually quite consistent. Now I run

make -f /usr/share/selinux/refpolicy-strict/include/Makefile

and it creates a compiled module, amavisfix.pp, for me that I can install with "semodule -i amavisfix.pp". The audit error should now be gone, and amavis should function. I can now file a bug report with upstream that the amavis policy is lacking "files_list_var_lib( amavis_t )" and they'll be happy to add that. :-) Note that "files_list_var_lib" has an actual semantic meaning what the process is being granted; audit2allow lines are just technical representations of the access violations seen. Some of the more advanced SELinux IDEs might be able to suggest you appropriate interfaces by looking at the audit errors; I havn't tried them yet.

For those that believe patents in theory are good idea but who are critical of the actual implementation of system, this project, Big Patents India is a novel and important project to include some checks and balances in the patent-application and granting system. It is described as the “first (and only) site with all post-TRIPs Indian patent applications online, searchable, and free” and thus adds a much-needed and important dose of transparency… I look forward to seeing how this new technology refigures the politics of drug patents in India.

Well, after reading the rebuttals of my platform for DPL, i noticed that from the others candidates only one really disagree with a proposal I've included - 'backports' related. I'm really happy that they agree with some of the proposals. Unfortunately, it seems that it's common sense between the others candidates that I won't be able to do everything that's in my platform during a one year term. They're right, i won't. I won't do everything that is in my platform simple because Debian isn't a single person project. :-)

My platform is a request to in a way lead some changes and if you disagree with any idea, feel free to email me and do your suggestions. Keep in mind that I can't please every single person using or contributing to the Debian project. I'm sure that i can motivate enough people in the project to help me work on that proposals and I'll be directly involved in a lot of stuff that is there, but I've no problem share power, influence or whatever you call for the better of our operating system.

I've been working on a public Google Calendar with my schedule (if elected), maybe it will help some of the others candidate and Debian Developers understand how and when:

XML:
http://www.google.com/calendar/feeds/qkkr1fd8b2qu4ms0cr9dkq56i0%40group.calendar.google.com/public/basic

ICAL:
http://www.google.com/calendar/ical/qkkr1fd8b2qu4ms0cr9dkq56i0%40group.calendar.google.com/public/basic.ics

HTML:
http://www.google.com/calendar/embed?src=qkkr1fd8b2qu4ms0cr9dkq56i0%40group.calendar.google.com

There's also my Live Platform online. The Live Platform is basically my platform as in vote.do containing some HTML fixes and additional comments (in bold) based on questions or general feedback about my platform content.

See you during the debate!

Yesterday ICANN published an interesting article about last attack of root servers (6 February 2007): see http://www.icann.org/announcements/announcement-08mar07.htm . The paper is not so detailed and technical as one should expect, anyway it is worth to read it.

It seems that also the remaining root servers should move to anycast. I think this is good, but it will works reliable with TCP? Do someone use TCP to query DNS servers? Why is it not disabled? It seems that all root servers accept TCP ( dig @l.root-servers.net. . NS +tcp).

A side note: as you can see, root servers don't give you yet the IPv6 addresses of root servers. Now they do some test, prior to broke the root server 512-bytes packet rule. We are still away to the full IPv4/IPv6 inter-operative nets.

The last recommendation is: "ISPs should only accept DNS queries from trusted sources (i.e., their own customers) rather than allow anyone to use their servers." . This rule (on recursive queries) is already a well know rule, and I I think it is less problematic of mail-rely (ev. with SPF), but on the other side, we are moving to the point that we should trust our ISP and our ISP will firewall "non-proxied" traffic.

As last point, the fact sheet cite two wikipedia articles. Wikipedia is so good, or there are not better (updated) documentation on the net?

Living in Vim John, some tips for your new life with Vim (welcome!)

• "hide the most of the Debian changelog" can be toggled while already in Vim by typing "zi" (without quotes) in command mode. To turn it off completely add "set nofoldenable" to your ~/.vimrc. Have a look at ":help folding" for more info on the folding subject
• to turn off/on autoindent/highlighting/... the commands to be set are "set autoindent" vs "set noautoindent" and "syntax on" vs "syntax off". You can achieve global settings (no matter which file) putting them in ~/.vimrc or you can achieve per-filetype settings putting then in ~/.vim/after/ftplugin/FILETYPE.vim, where FILETYPE stands for the file type you're interested in. To check which is the FILETYPE name, just edit in Vim the file you like and have a look at the output of ":set ft"
• for editing a file without closing the one you're using (the Emacs "buffer" concept) do "set hidden" in your ~/.vimrc (briefly commented in /etc/vim/vimrc in the default Debian package). Have a look at ":help buffers" for more info
• to integrate with Mercurial and Darcs I've no ready solution, there is the VCSCommand plugin in vim-scripts but out of the box it only works with CVS/SVN. Try looking in the scripts section of Vim.org

Hope this helps,

I've been an Emacs user for many years, though of course I know some vi and vim commands out of necessity.

I want to try taking the plunge by spending a month using vim only, no Emacs.

Sadly the vim documentation isn't very helpful for me in a number of areas. I'm hoping someone can point me to some resources or recipes that will help with:

• Turning off that stupid "hide most of the Debian changelog" thing. I have no idea why it does that or how to make it stop.
• Turn on or off autoindent, syntax highlighting, etc. in various languages (really, I want to set global defaults for all of them)
• Be able to edit another file without closing or saving the first (:e doesn't seem to do what I want)
• Integrate it with Mercurial and Darcs

Yesterday I mentioned a small project of mine called reportbug-ng. The feedback so far was very positive. Looks like quite a few people out there would like to see a desktop version of reportbug. Since I’ve already received a few patches via email, I decided to move the project to alioth so contributers can easily keep track of the changes. So here it is: the official homepage and teh almighty SVN repository. Comments and contributions are very welcome! (Hint, hint: The source-tree also contains a TODO list. Once all the points under “urgend” are processed, I’ll consider uploading it to Debian.)

We're home now. We were reading through the comments and emails. Oh wow. It'll be a bit before we're able to respond.

Thank-you all so much for the love and support!

Last weekend I had great fun during my first cal otada with my Friends in Picamoixons, very near Valls in Tarragona. While it's already a tradition for my friends, this was the first time I went there, after having missed many other opportunities probably due to my overcommitment to triathlon training a few years ago. So on Friday we drove up North to Catalunya, and arrived quite late to Frago's house in the center of the town, where we slept in two packed rooms and the terrace after getting some beers in Dune. Early next morning we met Frago's friends and bought the necessary vegetables and wine for our great lunch, and soon after we were in the middle of some olive field outside Picamoixons, where we prepared a big fire and the cal ots. A cal ot is a special type of onion which grows in the area, which ends up being very long and thin. After cutting part of the green leaves, they are cooked over the flames, which carbonises the first few layers of the onion, but leaves the inner part ready for consumption. After this, you just need to pull from the inner leaves to get rid of the burnt stuff and eat the rest with a delicious and typical sauce for cal ots. So far, so good. What if your group of friends has extended the tradition, allowing for extra fun bits? In our cal otades, after you've peeled the cal ot, you keep the carbonised stuff. It's valuable ammo, which will soon be thrown at others' faces. Trying to remain clean is futile, you soon are covered by sauce and black stuff all over your head and clothes. This was real fun! After eating part of the group went up a mountain to visit an arab tower, which helped me not to get totally drunk before the night. When it got dark, we were all back to our positions around the fire, chatting and listening to varied music, while we waited for the lunar eclipse. The eclipse was impressive, seen from the country side, with absolutely no luminic contamination. My friend Jordi carefully prepared his camera to do a good photograph series of the event, and the results were impressive. When the eclipse was about to be full, it was great to see a miriad of stars appear in the sky, previously hidden by the perfect full moonlight. We were just too lucky that the weather fixed up just on time to have a completely clear sky.

The lunar eclipse, as seen from the Catalan countryside. Pics by Jordi Jover. Many were quite tired by 3 or so, so we started setting up tents and went to sleep by 4. Sunday was a slow day, dedicated to cleaning up our stuff and eating leftovers cooked on a new fire. We were back in Val ncia at 8PM or so and even after showering and cleaning my hair with shampoo, my head still smelled like smoke. Actually, I think it might still smell a tiny bit today. In short, a lovely weekend, which I hope to repeat next year. Too bad the lunar eclipse bit will be missing for quite a few more years. :)

Last weekend I had great fun during my first cal otada with my Friends in Picamoixons, very near Valls in Tarragona. While it's already a tradition for my friends, this was the first time I went there, after having missed many other opportunities probably due to my overcommitment to triathlon training a few years ago. So on Friday we drove up North to Catalunya, and arrived quite late to Frago's house in the center of the town, where we slept in two packed rooms and the terrace after getting some beers in Dune. Early next morning we met Frago's friends and bought the necessary vegetables and wine for our great lunch, and soon after we were in the middle of some olive field outside Picamoixons, where we prepared a big fire and the cal ots. A cal ot is a special type of onion which grows in the area, which ends up being very long and thin. After cutting part of the green leaves, they are cooked over the flames, which carbonises the first few layers of the onion, but leaves the inner part ready for consumption. After this, you just need to pull from the inner leaves to get rid of the burnt stuff and eat the rest with a delicious and typical sauce for cal ots. So far, so good. What if your group of friends has extended the tradition, allowing for extra fun bits? In our cal otades, after you've peeled the cal ot, you keep the carbonised stuff. It's valuable ammo, which will soon be thrown at others' faces. Trying to remain clean is futile, you soon are covered by sauce and black stuff all over your head and clothes. This was real fun! After eating part of the group went up a mountain to visit an arab tower, which helped me not to get totally drunk before the night. When it got dark, we were all back to our positions around the fire, chatting and listening to varied music, while we waited for the lunar eclipse. The eclipse was impressive, seen from the country side, with absolutely no luminic contamination. My friend Jordi carefully prepared his camera to do a good photograph series of the event, and the results were impressive. When the eclipse was about to be full, it was great to see a miriad of stars appear in the sky, previously hidden by the perfect full moonlight. We were just too lucky that the weather fixed up just on time to have a completely clear sky.

The lunar eclipse, as seen from the Catalan countryside. Pics by Jordi Jover. Many were quite tired by 3 or so, so we started setting up tents and went to sleep by 4. Sunday was a slow day, dedicated to cleaning up our stuff and eating leftovers cooked on a new fire. We were back in Val ncia at 8PM or so and even after showering and cleaning my hair with shampoo, my head still smelled like smoke. Actually, I think it might still smell a tiny bit today. In short, a lovely weekend, which I hope to repeat next year. Too bad the lunar eclipse bit will be missing for quite a few more years. :)