LXD Packaging Report, 32bit edition
We’ll start today with a PSA: 32bit architectures still exist.
Similar to C, golang has an
int variable type whose size depends on the actual architecture that the code is compiled for. Usually this doesn’t cause an issue, but sometimes it does. Like when dealing with large numbers (cryptography, or computing exponents) that can overflow a 32bit value, or if you have code that assumes pointers will always be 8 bytes long. It was interesting to see packages hitting the various Debian buildds, and then noticing patterns with 32bit builds failing. So, this is a good reminder for everyone that while 32bit architectures may no longer be as common, they still exist and it’s a good idea to occasionally check that your code works on them.
Also similar to C, golang has
int64 variable types that explicitly set the size of the variable, regardless of the architecture. If you use these, then you don’t have unexpected issues when your code is compiled on a 32bit system and suddenly
int is smaller than on a 64bit system.
In other news, last week I was able to successfully compile LXD for the first time, using only properly-packaged dependencies! A handful of packages still need to pass through NEW before all the dependencies are available in the archive, but this is a big step. Several of LXD’s tests fail, but it’s encouraging to see that the army of unpackaged dependencies is finally under control. :)
NEW/updated packages accepted into unstable:
NEW packages pending upload:
Pending updates to existing packages:
As usual, thanks to Aloïs Micard for continued feedback and sponsoring my changes.