Specifically, I'd prefer we do this for arm*, just just for arm64, and that we include all the bus drivers, not just the i2c-thunderx driver. I don't know of any specific system that would be fixed by either of the above - but seems like a cleaner future-proofing. And obviously, it's ultimately your call.
I'd also like to continue to ask that we use 'dpkg --print-architecture' instead of 'uname -m'. From chatting on IRC, it sounds like qemu-user does emulate 'uname -m' to match the userspace, but that's just one form of a non-native build mechanism. Consider if we were building images for armhf on an arm64 host in an lxd container:
root@armhf:~# uname -m
armv8l
Whereas, we know in this case 'dpkg --print-architecture' will always report the thing we want to know:
root@armhf:~# dpkg --print-architecture
armhf
My comments from my original merge proposal still stand here: /code.launchpad .net/~dannf/ maas-images/ lp1702976/ +merge/ 327308
https:/
Specifically, I'd prefer we do this for arm*, just just for arm64, and that we include all the bus drivers, not just the i2c-thunderx driver. I don't know of any specific system that would be fixed by either of the above - but seems like a cleaner future-proofing. And obviously, it's ultimately your call.
I'd also like to continue to ask that we use 'dpkg --print- architecture' instead of 'uname -m'. From chatting on IRC, it sounds like qemu-user does emulate 'uname -m' to match the userspace, but that's just one form of a non-native build mechanism. Consider if we were building images for armhf on an arm64 host in an lxd container:
root@armhf:~# uname -m
armv8l
Whereas, we know in this case 'dpkg --print- architecture' will always report the thing we want to know: architecture
root@armhf:~# dpkg --print-
armhf