[04:31] <hardwire> Hi all.  Anybody familiar with specifying a custom base for an ubuntu-image model?  I've been able to compile core18 with my own stuffs in it and I'm reviewing the source for all the tools but can't quite figure out how to specify ./my-core18-img.snap or some such in the device model.
[04:31] <hardwire> also how do you generate a properly signed snap with snapcraft?  It doesn't pass in the account-key into the signed assertions file
[04:45] <jamesh> hardwire: you can create a "grade: dangerous" model assertion with unpublished snaps using the new syntax for model assertions
[04:45] <hardwire> nice
[04:45] <jamesh> hardwire: here's an example model definition using an unpublished base snap: https://github.com/canonical/ubuntu-core-desktop/blob/main/gdm-spike-model.json
[04:45] <hardwire> how do you reference the .snap file or locally register it?  Just via ack?
[04:45] <hardwire> many thanks!
[04:46] <hardwire> I like that it uses core20.  I had limited success even getting that booted.
[04:47] <jamesh> you can point ubuntu-image to local snaps with the --snap command line option.  If they match the name of a snap in the model definition, they'll be used in preference to whatever is in the store
[04:48] <jamesh> If you don't specify a snap-id for a snap in the model definition, it will be the equivalent of installing it with "snap install --dangerous"
[04:48] <hardwire> This explains a lot.  I was looking for more details on how snap prepare-image worked.
[04:49] <hardwire> Dude..  Thank you so much.
[04:49] <jamesh> "snap refresh" won't be able to upgrade it, and you can't easily set up interface auto-connection via the gadget snap.
[04:49] <hardwire> and you can't publish a base snap to snapcraft.io ;)
[04:49] <jamesh> but it is easily enough to get started.
[04:49] <hardwire> going to have to find another way to publish it so that our factory can snag it.
[04:50] <hardwire> at least if we need to refresh ever.
[04:50] <jamesh> you'd need manual review to publish a base snap.  You're right that it would fail automated review
[04:50] <hardwire> ok.  I'll research how to make that happen.
[04:51] <hardwire> I'm not making any proprietary changes.  Just adding rng-tools and swapping out timesyncd.
[04:51] <jamesh> you also have a bit more freedom with brand stores: you're given a bit more leeway if we assume you've effectively got root on all the devices attached to that store.
[04:53] <hardwire> I'll have to figure out how to set that up.
[04:53] <hardwire> Ideally we'd just want to use our own CDN for this stuffs.
[04:54] <hardwire> To not annoy all the peoples with useless namespace drivel.
[04:58] <hardwire> now to figure out how to specify the architecture.
[05:00] <hardwire> seems like it's easiest to compile armhf on top of ubuntu server armhf using SNAPCRAFT_BUILD_ENVIRONMENT=host
[05:02] <hardwire> ah.. yeh.. bootstrap plugin is chrooty and this needs done in another way.
[06:14] <jamesh> hardwire: I'd think setting the architecture in your model definition would be enough
[06:14] <hardwire> the bootstrap plugin for base builds doesn't support a foreign arch
[06:14] <hardwire> but that's ok
[06:15] <jamesh> ah.  You're talking about the snap builds rather than the image builds
[06:15] <hardwire> snapcraft build of snapcore/core18
[06:15] <hardwire> yeh.. not specifically the compositioning of the snaps for a custom model build
[06:15] <jamesh> for image builds, it should download whatever architecture snaps the model specifies
[06:16] <hardwire> it's hard talking about image builds when it's two different processes.  I'm specifically referring to creating a new base snap ;)
[06:16] <hardwire> You can't cross build those it seems and that's fine.
[06:20] <jamesh> You can create Snapcraft projects for cross-builds, but it isn't automatic.  It's not going to magically enable cross builds for a project without cross build capable build infrastructure.
[06:21] <jamesh> Most of Ubuntu is built native, so we haven't bothered trying to cross build the official base snaps
[06:28] <hardwire> It would be a pain to do that.
=== zyga_ is now known as zyga
=== SeasonsBeatings is now known as grumble
[19:23] <hardwire> So general question.  I see a lot of dependencies and snap packages are compiled rather than simply set as stage-packages and pulled from 18.04 or 20.04.  Is this because of some special rpath related fixups being done?  I'm a bit confused because the build-packages are there but snaps aren't using things like dnsmasq (see network-manager) from the official repos with all the security patches, etc..
[19:23] <hardwire> I'm planning on making some simple snaps that bring in some packages via snap simply by way of stage-packages.  Is that a huge nono?