@zyga-snapd, @degville this should probably be mentioned and linked to from The snap format
I’ve just added this to The snap format document. Thanks!
1 Like
Just wanted to give feedback that layouts have been working fine for me since 2.36 and switching to snapcraft v3 was seamless in that regard. I have had the passthrough wrapper active because I’m using launchpad for ARM builds and when I last checked, those builders didn’t have layouts enabled by default.
One minor hiccup that might be related to layouts: My snap’s install hook performs some tasks in the writable mounted directories. If the hook fails (because I had a thinko or something was missing), any attempt to reinstall a newer, fixed revision of the same snap will throw an error during the install hook that the layout mount at /var/snap/my-snap/current/some/subdir does not exist. Once I reboot, the error goes away and I can install the fixed revision just fine.
@tobias, is your issue similar to the one I encountered here: Snapd 2.37.1 refresh broke layouts snap remove/install ?
It would be interesting to see if you have a similar issue with the mount point showing up with //deleted at the end. You could try logging to $HOME the output of cat /proc/self/mountinfo during the hook.
@ijohnson The snap does not get installed when install fails, so I can’t really look inside the snap. I’ll see if I can throw together a test case that’s triggered on-demand after installation.
Interesting, please file a bug. It seems that on failed install we don’t discard any namespaces we have created.
Nice edits, really appreciated!
I wonder if this feature is compatible with the SNAPCRAFT_ARCH_TRIPLET variable?
Too lazy to verify it myself 
I wonder what’s the usecase of symlink ?
Not everything has to be a bind mount. A symlink is much more lightweight way to relocate something.
2 Likes
One of my snaps that uses layouts suddenly gets rejected on automatic review in the store:
invalid source mount: '$SNAP/api/tmp'(should be a legal path and not start with: /boot, /dev, /home, /lib/firmware, /lib/modules, /lost+found, /media, /proc, /run, /sys, /tmp, /var/lib/snapd, /var/snap lint-snap-v2_layout_target ($SNAP/api/tmp)
As you can see in the snapcraft.yaml source, I’m mapping $SNAP/some/path to $SNAP_DATA/some/path. The application running in $SNAP/api expects everything to exist beneath its root directory, but some of those have to be writable. The previous snap revisions (last one built on 2019-07-04) went through review just fine. I tried with and without the passthrough wrapper, so I presume that the store gained layout linting in the meantime.
Is this expected? What can I do to have my snap pass review again?
It did. I’ll take a look and respond via the store review process.
Ok, as you probably saw, I approved these. The fix is in master and I’ve requested a store pull.
1 Like
Thank you for the fast response + fix + approvals, much appreciated!
Is there a repo/status page where I can see if the fix has been deployed, so that I don’t push revisions until this passes again?
No, but it just got deployed so feel free to upload again 
1 Like
Given that review-tools are a separate public project, it might make sense for the dashboard to display somewhere which revision it is using ATM, probably not interesting for everybody and not super high-prio, but not silly either.
Currently, the version of the review tools a particular snap was scanned with is shown as part of the review results. For example, go to:
under "Automated review " there’s an expandable section with “X passes”, and expanding that will show the tools version such as:
20190717-1931UTC click-reviewers-tools version
But this, of course, requires doing a snap upload to see which tools version is active at the moment.
I’ll look into adding this information in a generic place, though we’d have to find such a place and also decide if it’s OK to show this (i.e. is it sensitive information in any way?).
- Daniel
As a user, I’d intuitively look over at https://status.snapcraft.io (though the deployed review-tools version is not really a status in that sense) or in the dashboard of my deployed snaps. But I guess the multitude of build options (build.snapcraft.io, launchpad project, …?) makes it hard to find a sensible and central place to put that information.