I figured that just forking that snap and adding
base: core18 to snapcraft.yaml would probably be about it, but so far I’ve been proven wildly wrong. Before giving up, I wanted to put my situation out there in case anyone has any suggestions.
What I did to get it (kind of) working
The following are the changes I made with respect to the original wifi-ap (https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/wifi-ap) snapcraft.yaml. My version is at https://github.com/ammpio/ammp-wifi-ap/blob/master/snapcraft.yaml
- Made sure the original repo (with the right tag for the stable version of the wifi-ap snap) is used for all required code
- In order to get the
servicepart to build, added a
build-snaps: [go/1.9/stable]line - and removed the deprecated
gopart. Specifying the Go version appeared to be necessary to get the build to go through. Happily, it works and seems to pass all tests
- Excplicitly added a few libraries under
stage-packages, in order to squash “This part is missing libraries that cannot be satisfied with any available stage-packages known to snapcraft:” messages during build
- I also kept the
configurehook in place
The build now works fine on build.snapcraft.io, with an example log under https://launchpad.net/~build.snapcraft.io/+snap/89d6fa2f052b3d8da13a987ad11f7e2b/+build/831415
What’s working and what’s not
After installation of my core18-based snap, ammp-wifi-ap, I observe the following behavior:
- If the official wifi-ap snap is also installed, everything in the ammp-wifi-ap snap works normally.
- If the official wifi-ap snap is not installed, then the ammp-wifi-ap snap doesn’t work.
Removing or installing wifi-ap reliably toggles between the two states above.
In case #2, the specific thing that’s not working is the $SNAP/bin/service binary (mapped to ammp-wifi-ap.management-service), which is compiled from the Go code. By “does not work” I mean:
- The process has no output whatsoever - regardless of whether it’s run as a daemon or if I manually execute the binary from within the snap environment.
- It does not create the $SNAP_DATA/sockets/control socket file, which serves as an API endpoint for controlling the access point
- Needless to say, the access point itself is not brought up
In an act of desperation I added
adapter: full to the daemon definition in snapcraft.yaml, but that doesn’t appear to have made any difference.
The only way to get $SNAP/bin/service to run properly (and create the
control socket) is to install the official wifi-ap snap. Note that the wifi-ap services don’t need to be running, but the snap just needs to be installed.
That is obviously very weird behavior, given that the two snaps should exist more or less separately. Any ideas?
I don’t know enough about the snapd universe to tell what’s really going on here (or even to embark on proper diagnostics), but I wonder if this is something to do with libraries. In this regard I did notice two slightly odd things in the build log, though I’m not sure either is the key to the issue here:
- The following message comes up:
Priming network-utils This part is missing libraries that cannot be satisfied with any available stage-packages known to snapcraft: - libiw.so.30
libiw30 is explicitly listed under
stage-packages for that part, and I can see it is installed by snapcraft.
- When building for armhf I guess the message:
Priming service Unable to determine library dependencies for '/build/ammp-wifi-ap/prime/bin/service'
This does not appear for the amd64 build. (both builds exhibit the symptoms above)
snap version is as follows:
snap 2.43.2 snapd 2.43.2 series 16 ubuntu 18.04 kernel 4.15.0-72-generic