This is extremely strange, and seems to be non-deterministic: different builders booted using the same VM image end up with different variables visible in launchpad-buildd's environment. My best guess is that the environment set up by su(1) is sensitive to some other bit of the boot process and thus causes launchpad-buildd's environment to vary depending on when it's started.
The simplest way to fix this may be to convert launchpad-buildd from an init script to a systemd service, since it's usually easier to control its environment that way: in particular, su(1) would no longer need to be involved.
This is extremely strange, and seems to be non-deterministic: different builders booted using the same VM image end up with different variables visible in launchpad-buildd's environment. My best guess is that the environment set up by su(1) is sensitive to some other bit of the boot process and thus causes launchpad-buildd's environment to vary depending on when it's started.
The simplest way to fix this may be to convert launchpad-buildd from an init script to a systemd service, since it's usually easier to control its environment that way: in particular, su(1) would no longer need to be involved.