We're working on bringing up new arm64 builder infrastructure in Launchpad scalingstack to replace the current bare-metal builders, and the current plan is that they should be able to cover armhf as well. Ideally, we would be able to do this using the same guest images: scalingstack builders are reset at the end of the previous build so that latency for new builds is lower when the build farm isn't at 100% use, which means that we don't in general know which architecture a given builder is going to need to build next, so we can get better density out of our hardware by having the same guest images be able to handle more than one architecture.
Things mostly work just by chrooting into an armhf chroot under linux32. However, this causes "uname -m" to print "armv8l", while our current value on our armhf builders is "armv7l". I'd initially thought that this would be tolerable, but my understanding from Adam Conrad is that the breakage from poorly-written build scripts that misdetect the architecture as a result is quite widespread. So, we would like to have a personality value available that would cause "uname -m" to print "armv7l".
This doesn't look completely trivial, because newuname() basically just has compat and non-compat mode for architectures based on whether the personality is PER_LINUX32 or not, and doesn't currently seem to have extension points beyond that. I'm hoping this is fixable. If not, we need to know with as much lead time as possible so that we can bring up separate armhf guests, since that's going to be a fair amount of work for us to arrange.
This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:
apport-collect 1520627
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.