Currently if you just type “snapcraft snap” in a subiquity checkout, the build fails because subiquity accesses files from message catalogues during the build, and snapcraft builds in a minimal cloud image by default. Can I change this somehow? I guess I can work around it by downloading the debs I need rather than using build-packages but I was a little surprised…
you can use --use-lxd to make it use an lxd container of an already set up lxd instance on the host …
or you can use --destructive-mode to make it fully use the host filesystem (but then your host OS must match the base: declaration in your snapcraft.yaml) …
or you can combine the two … create a container per base you will build/support and do:
$ lxc shell bionic
# snap install snapcraft --classic
# ... clone your tree, cd into it ...
# snapcraft --destructive-mode
...
Yeah, I can figure some ways of building it on my machine, but there’s nothing I can do in snapcraft.yaml so that it “just works” on someone else’s system, it seems?
If you’re building with snapcraft --use-lxd, you should be seeing the same build root as Launchpad builds will use:
For something like Subiquity, presumably you need stable release builds to happen through Launchpad. So it’s probably best to work with that build root. There do seem to be some differences for Multipass’s base image, so it might be easier to stick with the LXD mode.
Yeah, it works OK in launchpad. But I got an email from a potential contributor wondering why “snapcraft snap” didn’t work. I can probably tweak my build process not to care but this was pretty confusing!
I’m not sure how Snapcraft’s Multipass images are generated. It’s not the first time differences have been reported between them and the LXD/Launchpad images, for example:
It’s probably a question for @sergiusens or @cjp256.
Both are generated from the same, but booting a multipass VM requires more tooling to be available, if the version of multipass in use does not point to these already, they soon should be using https://git.launchpad.net/livecd-rootfs/tree/live-build/buildd/hooks/52-linux-virtual-image.binary which from a packaging standpoint is a superset of the LXD ones we use.
That means the two images, while similar, are not identical. I feel that to ensure accuracy of debugging builds the LXD image, the Multipass image, and the setup on Launchpad builders should be bit-for-bit identical. Having one image include more packages than another might seem innocuous, but it means switching providers is potentially going to end-up with confusion because you’re not starting from the same baseline.