The buildd-manager chooses chroots based on the job rather than the builder's architecture.

[Данило Шеган]

Because a TranslationTemplateBuildJob has no required architecture, it sets buildqueue.processor to None so that it can get dispatched to any available builder. This causes a few problems with the current code:

1. It can dispatch to restricted architecture builders when it should not
2. the selected chroot is based on the architecture of the job rather than the builder, so we can end up with architecture mismatches
3. the code looks for a distroarchseries based on the architecture of the builder selected, which may not exist for the current development series

https://dev.launchpad.net/LEP/BuildFarmBuilderPools will probably provide a solution for this problem.

We are working around this with bug 580016 for translations.

[Julian Edwards (julian-edwards)]

What's needed here is a generic way of queueing up builds rather than asking each build behaviour to get involved in the details of talking to the slave and making a buildqueue record.

Ideally, the behaviour will call a base class method where you can give it librarian aliases for any files that need to be sent to the build, along with an architecture indicator.

[Robert Collins (lifeless)]

I'm dropping this to low because it seems low priority relatively speaking for soyuz stability fixes etc. If thats wrong, by all means make it high again.

[Julian Edwards (julian-edwards)]

It's not high I guess, but we need to fix it before we can do recipe builds and TTBJs on !i386.

[William Grant (wgrant)]

Behaviours can pick a different chroot if they really want to.