Five build fixes a day

[Jani Monoses]

> [1] If your primary focus is main, you may be tempted to say "oh, they're
>      in universe, so they don't matter very much".
>
>      Firstly, the noise causes a problem in itself; many Launchpad bug
>      views don't make it particularly easy to see what component bugs
>      affect, and we often have to filter things out in order to do
>      release management effectively.
>
>      Secondly, we often have to promote packages from universe or fix
>      problems in universe in order to meet user/customer demand or clean
>      up various bits of the archive, so allowing universe buildability to
>      be a swamp causes us velocity problems.
>
>      Thirdly, we provide universe for the benefit of our users; even if
>      Canonical engineers generally have main as their primary focus, we
>      all lose out if our users are having upgrade problems due to a
>      popular package in universe failing to build and so being stuck on
>      an old version of a library that conflicts with other newer
>      packages, or something like that. [2]

Fourthly, for armel at least, fixing toolchain related build failures 
(quite a few and usually gcc regressions) in universe helps make the 
tools better and can translate to similar fixes in main. This is less of 
an issues on x86/amd64 where the toolchain is more mature and better 
tested in general.

Jani