Build-farm slave FSM fails early on

[Jeroen T. Vermeulen]

On my system at least, running in a chroot, the TranslationTemplatesBuildManager fails at an early stage when processing a real TranslationTemplatesBuildJob fed to it by the buildd master.

The slave does set up its chroot, but after that it goes (IIRC) from "unpacking" state straight to cleanup, where it breaks even more for apparently unrelated or loosely-related reasons. The FSM code receives an unexpected success code of None, which is not equal to 0 and is therefore interpreted as a failure. An attempt to close down the iteration then triggers an exception because the shutdown is supposed to happen only while in BUILDING state.

[Jeroen T. Vermeulen (jtv)]

This is following the instructions on https://dev.launchpad.net/Translations/BuildTemplatesOnLocalBuildFarm

Those instructions may be wrong, or it may be something with my system... big mystery so far.

[Henning Eggers (henninge)]

To be clear: These are two unrelated issues.

1) Why does the "UNPACK" state come back with a "None" result?

2) iterate_CLEANUP calls _slave.buildComplete() on both failed and successful runs but that throws an exception as mentioned. Should it be doing that?

[Jeroen T. Vermeulen (jtv)]

wgrant reports he's seen this working, so it's probably just something in my local setup.

[Данило Шеган (danilo)]

Let's see if we can confirm this on another machine before we worry about it.

[Jeroen T. Vermeulen (jtv)]

Got the little creep. TranslationTemplatesBuildJob.getName used self.job.id instead of getUtility(IBuildQueueSet).getByJob(self.job).id. So verifying it failed.

Told you this id stuff was unnecessarily complex!

[Jeroen T. Vermeulen (jtv)]

And in case anyone was wondering why I didn't test for this: I did. It just so happened in the test that the matched Job and BuildQueue objects I created in the test got the same ids, and the test passed by sheer accident.

[Ursula Junque (ursinha)]

Fixed in stable r10555 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10555>