I am following up on reviewer feedback after a Snap Store rejection.
snap store listing: https://snapcraft.io/iris-incuvers/listing
snap name: iris-incuvers
snap publisher: Incuvers Inc
We are developing a Raspberry Pi snap that will monitor various sensors to control an incubator environment. This will include sending telemetry to an MQTT broker as well as displaying it on an attached screen. The snap set to is private as it will only work for our specific hardware setup (sensors, screen, input, etc)—I can’t imaging someone wanting to install this snap other than when using our setup.
The snap needs privileged access to some interfaces that are not automatically connected (
At the moment, I’d like to publish to the snap store (edge) to test out over the air updates before shipping beta units. This is still in development and I am not yet certain of all the privileged interfaces that will be needed.
A handy tool for troubleshooting/understanding denials and getting interfaces recommendations is snappy-debug. If you haven’t used it yet, do so and feel free to ask any questions here so we can help!
If you only need to monitor sensors, can the
network-manager-observe interface be used instead?
network-manager is a privileged interface which allows to configure networking and this is not your use case iiuc.
Following the same reasoning, can you please explain why you need
gpio-control? It allows privileged access to hardware so probably
gpio is enough?
In general, could you please explain the reason for each interface you would like auto-connection? In case you are interested or have further questions, you can read more about our Process for aliases, auto-connections and tracks
@dav ping, can you please provide the requested information?
Sorry for the late reply.
The device has a very limited interface (just a rotary knob—no keyboard), so we opted to host an access-point and have the user setup their networking through a webserver (via the access-point). Once the user inputs their requirements (SSID/password/ethernet), we apply the changes and reboot.
We use the gpio inputs to connect the rotary knob as our sole human interface device.
The gpio’s are also used to trigger different lighting for the microscope, some which use the
spi interface. I am not sure if the
spi interface falls under the
wiring-pi) so I added both.
Although we use an arduino to interface directly with the sensors, we use the
serial-port to interface between the pi and arduino. Again, I am not sure if
serial-port can simply be absorbed into the
gpio-control umbrella. I want to mention we do open the
/dev/ttyAMA0 devices (to flash the arduino’s firmware and communicate with the it, respectively).
In case the user wants to unplug the device, we have a selectable shutdown option (we also offer a reboot in order to enter a service-menu).
Our main app runs using
pygame that directly interfaces with the framebuffer (SDL2) (we don’t want X11 to try to stay lightweight).
Note: I doubt this is the full list of auto-connections needed. We are still trying to look at what
apparmour plugs for us in
devmode in order to explicitly add them in the snap. I may add the new ones here as we discover them.
Since this snap is very device specific, and you are planning to ship devices with this snap, perhaps a brand store might be more appropriate - with your own brand store you can directly control things like what privileged interfaces are auto-connected etc and more.
I agree, our situation where the snap is tailored to a very specific device, doesn’t fit well with the general snap-store. The brand store perfectly fits our use-case. I spoke with a sales person and, we just cannot justify the steep pricing ($30 000 start package and $15 000 per year) in order to use a brand store.
Don’t get me wrong, it’s definitely something that can be pursued in some future when we’re at a stage ready for production/distribution. At the current development stage (and for the duration of beta testing), where we want to deal with about a few dozen units, it’s just too steep.
spi is a tricky one to grant auto-connect for via the store since there can be many possible hardware
spi instances - this is best done via a custom gadget snap for the device - however these are only available in brand stores.
So whilst it would be possible to grant auto-connect for
framebuffer I wonder if these 5 would be sufficient for the snap?
@dav - can you please advise?
We can perhaps get away with a bit-banged
spi, as speed isn’t the biggest concern.
Before, I do want to specify the only intendended hardware for this snap is a Raspberry Pi 4. In my understanding, the gadget snap supplies the
spi interface (excerpt from the gadget’s snapcraft.yaml):
With UbuntuServer installed on a pi, the gadget snap is not present, could it be installed first and have it provide the plug to our snap?
Classic Ubuntu Server does not use gadget snaps etc - they are only used on Ubuntu Core so this is not an option in this case. Is your snap expected to run on classic Ubuntu systems as well or only Ubuntu Core? @ogra I know you have looked at spi stuff in the past for snaps, could you perhaps advise on the best way forward here for a snap wanting to use spi on classic Ubuntu systems?
You can create a classic image with the
ubuntu-image snap and provide it a “classic gadget” and I know our gadget tree at:
ships configs for classic installs, but I have never built such an image for a Pi nor do I know how to build the gadget above as a classic one, perhaps @waveform or @sil2100 can help out here with some build instructions.
Hey @dav, could you check the advises provided?
Thank for all the tips! I’m hoping to attend Canonical’s Snapcraft101 course in a few weeks. Once the course complete I’ll be in a better position to come back to this (and perhaps ask better targeted questions).
Thanks @dav. We are then removing this request from our review queue. When you complete the course simply ask again here any question you might have, and we can add the request back to the queue. Thanks