Codehelp blog

Linpus Lite (or maybe just aspire one mail) is only going to last a few more days on this aspire1, it's beginning to annoy me:

Update

sylpheed has now replaced aspire mail. OK, I still use aspire mail for calendar and addressbook stuff (for now), but sylpheed is a much better email client.

1. aspire one mail has no GnuPG support


2. aspire one mail has no non-HTML composition support. No, really, it doesn't even send plain text alongside the HTML. email sent from the aspire to myself comes in as an attachment in other email clients! (i.e. spam)

So, I would have to investigate a different email client but then there are niggles with Linpus itself:

1. the aspire default kernel build lacks the pl2303 kernel module so that I can't use the aspire to control my balloon3 board over usb serial


2. intermittent problem with network manager forgetting WPA passphrases

Testing continues - probably resulting in installing Lenny at the end of this week. Some of these things might be fixable using pages like taoofmac and Reg Hardware.
Unfortunately, the problem with usbserial means that I'll have to take two laptops if I want to demonstrate the balloon3 board in places.
I also don't seem to be able to locate any copyright files which makes me nervous. Maybe it's just a lack of knowledge of Fedora (at least not since FC5).

OK, it's still running Linpus Lite and yum but that's enough to get things like drivel and ssh installed. Add in xchat-gnome and it's quite usable. The whole machine bounces around quite insanely when I'm typing this blog entry on my lap, though.
pilot-qof and a bit of XSL from the data-freedom package from the same source, allows easy import of ICS calendar data and VCF contact data.
Aspire Mail is clearly based on evolution.
I'll live with Linpus (sounds freakishly similar to lupus - or maybe that is just my medical bias) for a month or so - I'll get Debian on this sometime before my return to Extremadura.

A few speakers at DebConf8 used gobby during their talks to collate ideas without breaking the flow of the session.
I've just come back from the Emdebian meeting in Extremadura (of which more later) where we also used Gobby - FAI used it too. Once the network setup was working, it was simply a case of clicking Create Session in gobby on my laptop and everyone else clicking Join Session, entering the IP of my laptop (only accessible locally) and choosing a colour.
Gobby is real-time, currently plain-text only but clearly indicates how sections have been edited and has an integrated IRC box for each session. At the end of the meeting, every gobby user has a copy of every document they opened in every session they joined. updated to the moment they quit the session.
Based on using gobby in events like this, I'd strongly recommend that someone at each worksession-type meeting starts a gobby session and maintains that session for the duration of the meeting.
Gobby even does syntax highlighting - depending on how many people join and the colours they choose, this might become difficult so it can be turned off too.
There are only a few minor issues:

1. The colour bar warning box isn't particularly intuitive - you need to click on what looks like a dimmed progress bar to select a unique colour for yourself.


2. I initially thought that Gobby had no authentication - in a local meeting, anyone who can connect to the specified IP address is able to edit the document. Since then, I've noticed it does support password authentication and there is mention of fully encrypted connections so it may be possible to use it over public networks.


3. According to Wikipedia, there is a gobby server that allows non-GNU/Linux clients to run gobby and join any gobby session - I didn't explore this and the Debian package doesn't mention anything about a server option or mixed-OS support.
   
   • Update - the server is called Sobby and is in Debian.
   
   


4. The right hand side of the window is a bit wasted - maybe some kind of sidebar would be handy, especially docking the userlist into the window so that edits can be identified more quickly.

The current method of patching into place a series of ./configure variables as $(DEB_HOST_GNU_TYPE).cache files is becoming a pain - it blocks native builds of Emdebian packages for a start. So, I've been experimenting with a different method of support.

Centralised cache value support

Initially, I've collated all the current cache values needed (i.e. beyond the ones already provided for specific architectures) into /etc/dpkg-cross/cross-config.cache and have a script in emdebian-tools called emcache that will manage the central values by comparing them to the real values used in each build tree.
So, cache values, what are they?

1. Cross-builds fail if ./configure tries to compile a test program and then try to execute it because it will have been compiled with the cross-compiler - instead, the cross-build passes the value that the test was trying to calculate so that ./configure does not need to try to execute any cross-compiled code.


2. The values are derived from native builds, written to a $(DEB_HOST_GNU_TYPE).cache file that is passed to ./configure via debian/rules.


3. The values turn out to be mostly (completely?) architecture-independent, so are eminently suitable for collation into a central cache file.


4. Quite package-specific. There is some overlap but most are customised for a specific package. This led to a development of the central cache file: package-maintained cache files to support extensibility.

Package maintained cache files

I'm now experimenting with cache files written (and maintained) by packages during normal builds and dropped into /etc/dpkg-cross/cross-config.d/ - which would later migrate into dpkg support. Ideas welcome!
The basic idea will be that IF cross-building, the build process would check for /etc/dpkg[-cross]/cross-config.d/$source_package and, if found, add that to the cache value list for that build.
Cache files are shell scripts so this it be manageable to bring some intelligence to the process.

Where does MIPS come in?

Well, all the builds, so far, have been ARM or armel (where the cache values are likely to be identical) and i386 (which doesn't need a cross-compiler at all and therefore does not need cache files). MIPS is the first chance to check the cache values and ensure that the above criteria really are true.
Now that we have a volunteer looking at MIPS, the current MIPS builds are a suitable test bed.

What does this have to do with Debian?

Once Lenny is released, I'll be looking to implement this support via the long term mass bug filing for cross-build support into the packages themselves. It is possible that the process can be entirely automated - as long as the script knows which values are relevant. A normal cache file, post-build, can be very, very long whereas most cache files for Emdebian are just a few lines long - the longest is about 20 lines.
The current process is outlined on the Emdebian website, including a list of packages that currently need cache files to cross-build.
Oh, and just a note - when I start this phase of the long term mass bug filing, I'll first do delayed NMUs for the existing bug reports - hence the delay until Lenny is released.
In order to speed things along, I have also been doing some RC bugs - downgrading some, fixing others etc. (I've finished 6 since coming back from DebConf, so far, IIRC.) All efforts to get Lenny released will help Emdebian too, so if you want to help Emdebian, then help Lenny get out of the door and let's get to work on Squeeze.

(Squeeze is a great name for a release with lots of fixes for embedded stuff, don't you think?)