I’m giving a go at upgrading one of my snaps from core18 to core20. One of the parts has a source: patches stanza, which copies patch files under that directory to the stage area to be later applied in another part’s build step. The original implementation (that works today with core18 EDIT: it works on launchpad builders that use LXD, but fails similarly locally) looks like this:
In both cases though, when running snapcraft (version 4.2, classic snap, revision 5407 from the stable channel) with the default multipass backend (version 1.4.0, revision 2445 from the stable channel), the build fails because the patches are not copied.
I know, and that’s the intended behaviour: the patches are useful only for building, I don’t want them to end up in the snap.
No, it’s a plain directory containing two .patch files.
I simplified the part definition to this:
part-name:
plugin: dump
source: patches
and I’m still seeing /root/parts/part-name/{src,build,install} in the multipass VM are empty after (seemingly) successfully running the pull, build and stage phases for this part.
Lastly, if you still have problems after a clean, make sure you aren’t seeing any denials in the logs, the project is in $HOME, and multipass is up-to-date?
snapcraft --use-lxd successfully builds the 0ad-patches part (it fails later on but it’s an unrelated issue). However with the default multipass backend, it consistently fails to copy the local sources (even after cleaning, or using multipass to delete the VM and have snapcraft re-create it from scratch).
I’m not seeing any denials in the logs, my project is in $HOME and multipass is up-to-date. One tweak to the default configuration is that my multipass VMs are stored on a separate disk, and that directory is bind-mounted to /var/snap/multipass. I don’t expect this would make a difference, but maybe this has subtle side effects?
Lastly, if you still have problems after a clean, make sure you aren’t seeing any denials in the logs, the project is in $HOME, and multipass is up-to-date?
Sorry - to jump on someone else’s question - I have equivalent failures (source missing from the src directory) - on the dump wrapper.
Can you direct me to links about “denials” and how to diagnose? I do indeed see apparmor=DENIED for snap.multipass.mulitipassd, but no context to diagnose it further.
Additionally you’ve highlighted multipass operations - is there a way to get snapcraft to dump out each step it is taking (equivalent to --debug or set -x) so as to be able to identify which exact step is not proceeding as expected.
Hi @whitty, sorry for the late reply, this got lost in the influx of email
We do expect some to be logged still, even in normal Multipass operation. snappy-debug is a helpful debugging tool - if you show us your denials, we can tell you if it’s a real problem.
Exporting SNAPCRAFT_ENABLE_DEVELOPER_DEBUG=yes should help with this.
@Saviq, Thanks for your help - I eventually tracked it down to running from an encrypted home-directory. Is there somewhere I should log a bug - and if so -against snapcraft? or multipass?
Fwiw, I hit the same issue, would be great if snapcraft/multipass could somehow detect that it’s running on encrypted home and show some warning or something.
