One of the other guys here joked that the baggage handlers at the airports are more likely to be careful with your luggage now.
Since there is a higher threat level, the chance of a bag exploding if a handler mistreats it should be higher. Therefore it is in their best interests to be careful.
So the airports in the UK went crazy today after a terror plot was uncovered. The upshot is severe restrictions on what you can take on as hand luggage, and a fair number of flight cancellations.
The restrictions mean you can’t carry laptop computers on board. Instead they want you to check them through and trust them to the baggage handlers …
I’m meant to be flying back to Australia on Saturday, so we’ll see what happens. I’m not particularly looking forward to getting home with a broken laptop.
Have you wanted to play around with bzr but had nowhere to share your branches? You can now publish them through Launchpad. David Allouche provides the details.
In short, you can upload branches to sftp://bazaar.launchpad.net/, and they will be published on http://bazaar.launchpad.net/.
Yesterday there were some news reports about the opposition party in Victoria issuing a FOI request and finding that the breath testers used to test blood alcohol content routinely under report the readings by up to 20%. They used this fact to show that it was giving negative readings for some people who are a little over the limit. On the face of it this sounds like a problem, but when you look at the statistics the automatic reduction makes sense.
The main point is that breathalyzer tests are not completely accurate. Let’s consider the case where the breathalyzer which does no adjustments gives a 0.05 BAC reading. We’d expect the probability distribution for the real BAC reading to be a normal distribution with 0.05 BAC as the mean:
So the real BAC may be either above or below 0.05. Given that it is only an offence to have a BAC above 0.05, the test would only give even odds that the person had broken the law. That would make it pretty useless for getting a conviction.
If you automatically reduce the displayed reading on the breathalyzer by 2 standard deviations, there is a different picture. For a BAC reading of 0.05, the real BAC will still be normally distributed but the mean will be offset:
So this gives a 97.5% probability that the BAC is above 0.05. So while removing the automatic result reduction might catch more people over the 0.05 limit, it would also drastically increase the number of people caught while below the limit.
To reduce the number of false negatives without increasing the false positives, the real answer is to use a more accurate test so that the error margins are lower.
I’ve been doing most JHBuild development in my bzr branch recently. If you have bzr 0.8rc1 installed, you can grab it here:
bzr branch http://www.gnome.org/~jamesh/bzr/jhbuild/jhbuild.dev
I’ve been keeping a regular CVS import going at http://www.gnome.org/~jamesh/bzr/jhbuild/jhbuild.cvs using Tailor, so changes people make to module sets in CVS make there way into the bzr branch. I’ve used a small hack so that merges back into CVS get recorded correctly in the jhbuild.cvs branch:
It’s a bit of a hack, but it allows me to do repeated merges from the CVS import to my development branch (and back again). It also means that any file moves I do in my bzr branch are reflected in the CVS import when merged.
So now when filing bug reports on jhbuild, you can submit fixes in the form of bzr branches as well as patches.
So, on to the improvements:
Generic Version Control Interface
Previously, to add support for a new version control system the following additions were needed:
This was quite a bit of work, and in the end would only help if the code in question was set up to build the same way as most Gnome modules (i.e. with a autogen.sh script and autotools). If you wanted to build a module using Python distutils out of Subversion, a new module type would be needed. If you wanted to build a distutils module from a tarball, that would be another module type again.
With the new system, the different version control support modules provide a common interface. This means that a single module type is capable of implementing the build state machine for any version control system. Similarly, it should now be possible to implement distutils module support such that it will work with any supported version control system.
This work is not yet finished though. A bit more work needs to be done to parse version control system agnostic module definitions from .modules files. When this is done, a fair bit of the current syntax can be deprecated and eventually removed. When this is done, adding support for a new version control system shouldn’t take more than 100-200 lines.
Module Type Simplifications
As well as reducing the number of module types that need to be maintained in JHBuild, I’ve been working on simplifying the code in these module types. Previously, each stage of a module build was represented by a method call on the module type. The return value of the method was used to say (a) whether the stage succeeded or not, (b) what the next state would be and (c) if an error occurred some alternative next states to go to (e.g. offer to rerun autogen.sh).
With the new system, the next state and error states are declared as attributes on the method object. The method can indicate a failure by raising a particular exception. This greatly simplifies the cases where a build stage involves a number of separate actions that could each fail individually, since the exception cuts processing short without the error checks getting in the way of the code.
There are still a few module build stages not converted to the new system since their next state depends on various config settings (e.g. if running “make check” has been enabled or not). Since these generally involve skipping a stage based on some criteria, the plan is to move the logic to the stage being skipped, which should simplify things further.