Can't connect to content slot, since "content" directive somehow gets dropped from snapcraft.yaml

snapcraft
1

Pretty simple but puzzling problem. I have the following in my snapcraft.yaml:

slots:
  control:
    interface: content
    content: socket-directory
    write:
      - $SNAP_DATA/sockets

I’m trying to connect a corresponding plug to that slot; but getting the following error:

error: cannot perform the following tasks:
- Connect ammp-edge:control to ammp-wifi-ap:control (connection not allowed by slot rule of interface "content")

Sure enough, in $SNAP/meta/snap.yaml I actually have the following:

slots:
  control:
    interface: content
    write:
    - $SNAP_DATA/sockets

With the content: socket-directory line missing. Any ideas what’s causing that? Build log is here if that’s of interest - couldn’t find anything relevant in there.

2

Things I’ve tried:

  • Reshuffling my snapcraft.yaml file
  • Changing the content directive name to something else

Still no luck. I’ve definitely previously used this same syntax to create snaps with content slots, which are then built on build.snapcraft.io - and everything worked fine. No idea what’s causing this to now fail in such an odd way.

3

This is probably a bug, we will look into this

4

Confirmed bug, sorry @svet for the troubles.

I put a PR up to fix this: https://github.com/snapcore/snapcraft/pull/2934

1 Like
5

Thank you @cjp256 for the quick turnaround on fixing this!

I have kind of a tangential question, since I’m under a bit of time pressure to deploy this snap to devices we’ll be putting out in the field in the coming days. So I need to work out the best option for building this for armhf. Would you say I should:

  1. Wait for the fix to make it into a new snapcraft release, and for that to be deployed to the launchpad build farm (probably not in the next days?)
  2. Use snapcraft remote-build to build with an older snapcraft version on launchpad (not sure it’s possible to specify the snapcraft version used?)
  3. Just build it myself, by using snapcraft from the master branch, on an armhf device

Thanks in advance for any advice!

6

@svet it should get merged soon, but give edge/pr-2934 channel a try:

sudo snap refresh snapcraft --channel=edge/pr-2934

Alternatively, stable/3.8 may work too.

7

@svet: @sergiusens just merged this to master, so it should populate into the edge channel in the next couple hours. That’ll make it work with snapcraft remote-build (as it uses the edge channel by default).

1 Like
8

Great thank you @cjp256!

Out of curiosity - would triggering the build via build.snapcraft.io be the same as running snapcraft remote-build? I know both approaches build on launchpad, but not sure if there’s a difference (e.g. in terms of snapcraft version used).

9

I believe that build.snapcraft.io will use the stable channel.

Snapcraft’s remote-build is currently set to use edge channel, though if you picked up snapcraft from edge/pr-2933 you’ll get have a --launchpad-snapcraft-channel option to make it configurable.

1 Like
10

Thanks @cjp256! I had a go at what you suggested - wanted to make two observations. These are more related to the snapcraft remote-build experience than my original question, but figured I’d just drop them in here also.

  1. I noticed in the recent comments on https://github.com/snapcore/snapcraft/pull/2933 that the default (remote) channel is now “stable” rather than “edge”, so using the edge/pr-2399 version (locally) in order to explicitly set the remote channel to “edge” was indeed necessary - thanks for the tip :+1:
  1. For some reason the contents of my local source directory (from where I run snapcraft remote-build) do not actually get uploaded to the builder - only my snapcraft.yaml. This was leading to a patch file (from https://github.com/ammpio/ammp-wifi-ap/) missing from $SNAPCRAFT_PROJECT_DIR on the builder (which is basically https://git.launchpad.net/~svetb/+git/snapcraft-ammp-wifi-ap-05beb5/). The most immediate workaround I thought of was to add wget to build-packages and specifically download that file as part of override-pull so it’s available. But I’m guessing this is otherwise a bug?

Thanks again for the help.