Today we got access to all the audio equipment and the remaining cables we needed in our main venue, the Parliamentary Tower. We've worked out locations of the various equipment (projectors, screens, speakers, microphones, camera, computers) and wired them all together. We were unable to get a sight-line for a wireless link from the tower to the rest of our network, but the centre finally agreed to let us use their house network for this purpose. We have to go through a 10 Mbps hub, but it should be sufficient. Finally this evening we were able to test streaming video and audio from the camera and mixer in the tower down to the rest of the network. The tower is now closed, but we will test from the hacklab to the outside world tonight. Fingers crossed, Debian Day should go live to the world tomorrow!

The magic switch for the Debconf wireless network is sharing its socket with a TV. When the TV is plugged in or unplugged, sometimes the switch's plug comes loose, and the whole wireless network goes down. Our Internet connection is dependent on an antenna on the roof of the local Internet caf that sometimes comes down in high wind, and which has a flaky power connection. And now the route from the airport is blocked too. (Maybe not any more.. we don't know.) On a more personal note, my laptop's power cable is now held together with insulating tape.

At Debconf we'll be having talks in the Parliamentary Tower and some other sessions in a room by the hacklab. In each of these rooms there will be one small quiet computer capturing video from the camera over Firewire, connected by Ethernet to a second computer (preferably outside the room) with more disk space and processor power, which will record, transcode and stream the video to the outside world. On the first of these we just need to pipe dvgrab into netcat. On the second we need to netcat to a file and simultaneously feed that file into the transcoding and streaming software (ffmpeg2theora and oggfwd). Since our link to the Internet may not be reliable (and certainly isn't now) we expect that streaming may lag behind; that's where dvtail (which I mentioned previously) comes in. Having identified the various pieces of the video puzzle, last night I actually wrote the scripts to do this. I didn't have a chance to test them properly, so they didn't actually work. Today I packaged them, fixed various silly bugs, and tried them on some of the computers we plan to use. This was stalled for a stupidly long time by the lack of Internet access, since Ganneff had planned to create users on an LDAP server elsewhere and then use a local LDAP cache, rather than create them entirely locally. Eventually we ended up with user accounts created on each machine. Next problem: we attached a camera to a Powerbook G4 and got nothing but errors from the Firewire driver and dvgrab. We tried changing cameras, cables, kernel versions, but with no success. Changing the kernel itself was a problem without access to backports. I was cursing the air blue and banging my head against the wall in frustration. Finally we tried using different computers, and suddenly everything worked. I had missed one option to ffmpeg2theora, but once I added that we were able to stream across the LAN. Of course, that won't be of much use if we don't get the Internet connection working much better soon.

Courtesy of my phrasebook:

English	Spanish
I'd like to get Internet access	Quisiera usar el Internet
broken	roto
tomorrow	ma ana

I noticed this morning that the book has a section on romance, going from "asking someone out" through "sex" to "problems". Suddenly this book became more interesting to my breakfast companions.

English	Spanish
I can't get it up - sorry	Lo siento, no puedo levantarla

Nattie (tea_cantata) and I arrived safely in Mexico and have been fairly busy since then, while not blocked by lack of network access. The Debian archive mirror prepared by Steve made it here safely and is now attached to our main server. Yay for USB2. Video team preparations are a bit behind schedule but we are just about to do a smoke test with cameras and computers (but no audio mixer yet). I have backported Icecast 2.3 and Ffmpeg2Theora to sarge, and written a "dvtail" program to read the DV recordings for streaming, so that problems with our Internet link won't break recording or result in a huge lag in the streams. I have also had to make and lay out a 100m power extension cable for a switch in the middle of a 200m stretch of network cable. This requiring fixing the crappy extension socket shut with a hammer, jumping^Wclimbing from rooftop to rooftop with cable, and then untangling it under a baking sun. I'm loving the spicy food here, though I think I can do without jelly as a "vegetarian" dessert (I think this mistake will not be repeated) and may have to ask for refritos sin queso (without cheese). The heat is bearable and my hat and sun cream have so far protected me from sun burn. The insects are horribly noisy, but one eventually tunes them out, like the noise of fans.

Between myself and new DD Ben Hutchings, I think we have enough wombles to make a fair showing. <grin>

Womble2 (Ben Hutchings) as one of your newest DDs! Quite a few people know him in the UK, and some of you may have met him over at DC5.

I'm not sure if I've got the subject of this post right, but it is meant to be Spanish, as we're so near DC6 :)

Over the last 2.5 weeks I have built the complete Debian archive on a quad-core MIPS machine donated by Broadcom using the recently released version 4.1 of GCC. In parallel, I have done the same on an EM64T box donated to Debian by Intel. The purpose of this exercise was three-fold:

• Find out about compiler problems in GCC 4.1 itself as well as in packages that may fail with the new version before GCC 4.1 is uploaded to unstable. GCC, in particular G++, is becoming stricter regarding adherence to standards and packages may fail to build with 4.1 due to invalid code that was accepted previously.
• Find out about MIPS specific problems in GCC 4.1 and to answer Matthias Klose's question as to which platforms can move to GCC 4.1 as the default compiler once it is uploaded to unstable.
• Find MIPS specific assembler warnings and create a list of all users of xgot (a MIPS specific toolchain problem).

Executive summary GCC 4.1 itself appears to be very stable, both on MIPS and AMD64. There are, however, a large number of packages using code (especially C++) which GCC 4.1 treats as errors. Fortunately, most of them are trivial to fix. By compiling about 6200 packages, over 500 new bugs have been discovered and submitted, 280 of which are specific to the increased strictness of GCC 4.1. Patches for 2/3 of those GCC 4.1 specific bugs have been submitted. Based on my findings, Ben Hutchings has prepared a summary of the most common C++ syntax errors (that weren't treated as errors before G++ 4.1). Most common programming errors Basically, it all boils down to broken C++ code. There were a few bugs in C code, but the majority was in C++. The most common errors I found are:

• extra qualification
• reliance on friend injection
• wrong escape characters (e.g. "\.", most commonly seen in regular expressions)
• iterator problems (such as assigning 0 or NULL to an iterator)
• template specialisation in wrong namespace
• template reliance on a function declared later
• use of template's base class members, unqualified, where the base class is dependent
• use of assert without #include <cassert>
• dereferencing type-punned pointer will break strict-aliasing rules (a warning) combined with -Werror

I've posted a detailed report to debian-devel. Acknowledgements (abridged)

• Broadcom for supporting our MIPS port through the donation of hardware to the project and developers. Without Broadcom, our little and big endian MIPS ports would have a hard time meeting the release criteria regarding autobuilders.
• Google for supporting my PhD, thereby allowing me to spend two weeks compiling the archive with GCC 4.1 and sorting out failures.
• Intel for supporting some PhD work which led to this experiment.
• Ben Hutchings for explaining many of the C++ bugs I found to me. I've learned more about C++ in these two weeks than I ever wanted to know. ;-)