Hi folks
This is not so much a request for a connection and a request for troubleshooting an existing one!
I’ve had a few issues reported against GIMP where it fails to connect to certain theme content snaps (icons, themes, etc.)
The issue is here: [Bug]: Gimp is still not connecting to Theme Snaps. · Issue #422 · snapcrafters/gimp · GitHub
Can someone check that everything is okay store-side?
Thank you!
This request has been added to the queue for review by the @reviewers team.
Hello @jnsgruk.
The content slots that are failing to connect appear to already have global auto-connection enabled. Removing the content plugs information from the snap declaration should resolve the issue.
Let me know if that does the trick.
Ugh sorry if this is a stupid question - are you suggesting I need to make a change to the actual snapcraft.yaml here? 
If so, I’m not sure what that would look like since they’re not mentioned in the snapcraft.yaml
Thanks!
Apologies for the confusion earlier—that was my mistake in how I explained it. This is actually a change that needs to be made on our side.
I’ll let you know once it’s live so you can test it on your end.
Hi folks, a bit of context about the issue:
In most cases any snap is able to auto-connect to content slots that have global auto-connection enabled, as it the case for many theme snaps.
On the other hand, if the snap needs to auto-connect to a content slot that does not have global auto-connection (which is the case for gimp that needs to auto-connect to npu-libs-2404, openvino-libs-2404, openvino-ai-plugins-gimp-2404), we need to create a snap-declaration in the store side to enable it.
The problem is that the way it was designed, having a explicit list of allowed auto-connections (which is needed for npu-libs-2404, openvino-libs-2404, openvino-ai-plugins-gimp-2404) makes snapd to ignore all global auto-connection. This is the reason why gimp is not auto-connecting to some theme snaps.
In summary, either the snap (gimp) exclusively auto-connects to content slots with global auto-connections (and benefits from the global-auto-connection) or every content slot that snap (gimp) is expected to auto-connect to is explicitly listed in its snap-declaration.
For the first option, if we don’t want to break the auto-connection to npu-libs-2404, openvino-libs-2404, openvino-ai-plugins-gimp-2404, they would need to receive global auto-connection first (and it is probably not a good option considering that at least openvino-ai-plugins-gimp-2404 is very gimp specific).
For the second option, you will need to ask us to add any failing auto-connection (as it is the case for gtk-theme-pocillo, gtk-theme-qogirbudgie and flugir-budgie-theme) to add them to the list of explicitly allowed auto-connection for gimp. In this case, if the content slot already have global auto-connection enabled, we can just add them to the list without voting.
Considering that the explicit list can be huge if we need to add every theme snap, a potentially more convenient alternative would be creating a slot side declaration for npu-libs-2404, openvino-libs-2404, openvino-ai-plugins-gimp-2404 with a plug-snap-id constraint, limiting the auto-connection potential just to gimp. However, I would like to know if that sounds ok to @pedronis first.
Ah interesting! Thanks for the context! I think we’ll see a similar issue with Audacity/OBS in the near future, as @wfrench is also working on adding OpenVINO support to those snaps.
In that case, maybe it makes sense to push for global auto-connection for npu-libs-2404 and openvino-libs-2404 content slots if publishers commit to properly maintain these snaps and avoid disruptive changes within a track (what do you think?).
In that case, for openvino-ai-plugins-gimp-2404 we would still need to rely on the alternative solution I proposed. However, I think it makes even more sense if it is limited to this slot, as the name indicated it is created specifically for gimp. I will still wait for @pedronis input on this
I think this is reasonable - @wfrench might have more details of the maintenance plan for those content snaps and API changes, etc.
Am I right in thinking all 3 of these snaps, Audacity, OBS, and GIMP, are all in the Snapcrafters developer account?
Snapd will automatically connect content snaps when the same developer account is used, so, if these content snaps were transferred over to Snapcrafters, hypothetically then the store override can be dropped on the GIMP snap for the OpenVino content whilst letting the global autoconnects handle the theming?
(I might be wrong, and for some reason, I can’t see these snaps on the WebUI to see who currently owns them, but it sounds reasonable at least for the GIMP specific content snap)
That’s correct (as of the last few days!)
We recently got a commitment from Intel to include maintenance of these snaps in our contract, so yes I think we can (Canonical) can commit to maintaining them. We have tracks for openvino-toolkit-2404 but none of the others quite yet, but that will come soon. The snaps have actually remained in edge and beta grades only because of the open support question, but now that we’ve reached an agreement I will be promoting them all the candidate and stable shortly.
About the publishers of the snaps:
You’ll notice the last two are published under openvino. In practice that will be my squad (Intel) within Partner Engineering, but we do have collaborators from upstream and long-term hope to garner more involvement from them.
Some potentially relevant details about the auto-connections:
Plugins within GIMP are quite flexible in that they are designed to run as forked child processes and support different programming languages. This made snapd’s content interface a natural choice for delivering the OpenVINO AI plugins to GIMP and means we can manage the plugins separately in their own snap (openvino-ai-plugins-gimp) independently from the gimp snap.
The plugins for audacity (which we are actively working on) are a different story. They use an audacity module which is a .so that is dynamically linked against audacity and openvino. As a result, we could not easily deliver the plugins over the content interface (since there are audacity and openvino build-time dependencies), and instead must build openvino-toolkit-2404 directly into the snap (with build-snaps and stage-snaps). All that’s to say, there will be no openvino-libs-2404 interface for audacity, and there will be no separate openvino-ai-plugins-audacity snap. However, audacity will use the npu-libs-2404 content interface and intel-npu custom device interface like we had for GIMP since the NPU libs are dynamically loaded (dlopen’d) by openvino and friends.
The situation for OBS is still a bit unclear. Another engineer on my squad is working on that and we’re still in the discovery phase.
Maybe more than you all wanted to know but hopefully that provides helpful details/context!
given the current constraints, this is fine with me, it would also be fine for the first two that are not gimp specific to see whether we could make them globally auto-connect?
For what it’s worth, this would be my personal preference (global auto-connections for npu-libs-2404 and openvino-libs-2404). I just finished work on integrating OpenVINO plugins with audacity and need npu-libs-2404 to auto-connect there, so this would kill two birds with one stone.
Sound good. Then, next steps:
@jslarraz will update openvino-ai-plugins-gimp-2404 to allow auto-connection on the slot side with a plug-snap-id constraint to limit it to gimp. I don’t think we (reviewers) need to vote as gimp already was granted auto-connection to the aforementioned interface.
@wfrench Could you please create (separate) requests in the forum asking for global auto-connection for npu-libs-2404 and openvino-libs-2404 so other reviewers have the chance to vote? Please link this topic on these requests for additional context
@jslarraz remove gimp’s plug side declaration once all global auto-connections would be setup and close the topic on the reviewers end
Update:
I just granted auto-connection on the slot side for npu-libs-2404, openvino-libs-2404 and openvino-ai-plugins-gimp-2404 limited to gimp snap. I also removed gimp’s plug side declaration, so all auto-connections should work fine now (including both, existent auto-connections and previously failing theme-snap auto-connection). @jnsgruk @wfrench Could you please double check that everything works as expected?
Once global auto-connection requests for npu-libs-2404, openvino-libs-2404 are approved I’ll just remove the only gimp constraint from their declarations.
@jslarraz I just tested GIMP and everything looks good!
@jslarraz @pedronis @jnsgruk @James-Carroll Request for global auto-connections for npu-libs-2404 and openvino-libs-2404 submitted here: Global auto-connections for `npu-libs-2404` and `openvino-libs-2404`
