I built a new package with the snapcraft candidate (3.9.3) and the default-provider issue is fixed. You can find this new snap on opera-developer’s edge channel (67.0.3540.0).
However, I still need to connect gnome-3-28-1804 manually to make opera work:
snap connect opera-developer:gnome-3-28-1804 gnome-3-28-1804
Could you have a look at the auto-connect problem again? Thanks a lot!
I don’t know what is happening here, but I can confirm what @xshi is seeing. I installed opera-developer from the edge channel in a clean VM, and gnome-3-28-1804 didn’t get auto-connected. This can be reliably reproduced.
Happy new year everyone!
I just reinstalled and tested the opera-developer snap on edge channel again. I can still reproduce the issue.
Is there any news about this? The issue has been preventing us from updating Opera on snap store for more than I month now.
@zyga - can you comment?
Its been close to 2 months now since Opera snap version was updated. Two newer browser version releases (non-snap formats) have happened during this period.
Please understand that for people on fresh install of Ubuntu flavors 19.10, Opera Snap is an easier way to get required chromium codecs (which are being shipped as snap by default from Ubuntu) for videos to play on browser.
In spite of an Opera developer requesting repeatedly for support in resolving issue (s) which is preventing them from releasing newer version, it is disappointing to see no help from concerned folks at Snap team. Doesn’t make for a great impression guys.
Snap team, please provide the required help to Opera developers soon so that we consumers can benefit from newer releases.
Canonical Team, please fix the issue.
I’m looking at this issue now. Using snapd 2.42.2 on Fedora 31, having installed
opera-developer I can see the following thing:
The snap defines several content plugs, among them
gnome-3-28-1804 with a default provider of the same name. What was weird is that despite having it installed it was not auto-connected upon installation. This is unexpected. In fact out of all the content interfaces only
chromium-ffmpeg was connected. I wonder if this is in any way related to the arity work that was done in snapd recently.
I’m looking into the code to see why.
snap known snap-declaration I scanned the output for the declaration of opera-developer and found this:
type: snap-declaration format: 2 authority-id: canonical revision: 3 series: 16 snap-id: Qu7SvRkGy1tMWSmmxEcK7jTgssFDHHp6 plugs: browser-support: allow-auto-connection: true allow-connection: true content: allow-auto-connection: - plug-attributes: content: $SLOT(content) slot-snap-id: - XXzVIXswXKHqlUATPqGCj2w2l7BxosS8 publisher-id: JILUl2YHFAreIPbjDCgh7HDCwDlhnBpd slots: dbus: allow-connection: - slot-attributes: name: com.opera.opera-developer deny-auto-connection: true snap-name: opera-developer timestamp: 2019-11-22T20:45:53.487824Z sign-key-sha3-384: BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul
For context, snap declaration is a snapd assertion given to snapd by the store. It contains special language that grants non-default behaviour to a specific snap. It is further documented on
On first read of the resulting assertion I suspect that in absence of other declarations, only single auto-connection for the content snap is allowed.
@jdstrand I think the solution is to issue a new snap declaration for the affected set of opera snaps to allow them to auto-connect to the current set of content interfaces that they desire.
@kenvandine what should be the access rules for chromium-ffmpeg? All this would be greatly simplified if it sported its access rules (like the gnome-* snaps) instead of having each snap using it doing it.
More generally the brittleness here is related to the rules for snap-declarations that have fairly a blunt approach to simplify reasoning ( plug snap rules mask slot snap rules which mask plug base decl rules which mask slot base decl rules ) against the fact that in practice content is one interface implementing a family of them (one per content label value).
@pedronis: I’m not sure I understand what you mean by “access rules”. The usage documentation for chromium-ffmpeg shows how a consumer snap needs to declare a corresponding plug in its
snapcraft.yaml, and as far as I can tell it doesn’t differ from how consumer snaps connect to e.g. the
gnome-3-28-1804 content snap.
The documentation mention asking for auto-connection on a case-by-case basis. Do we have a reason to limit that vs allowing any snap with the right plug definition to auto-connect to these libraries?
I don’t see a reason not to allow any snap to consume chromium-ffmpeg without having to go through the auto-connection request. This would certainly make it easier for third-party browser snaps (such as opera).
Unless there’s a licensing or security concern, maybe?
Hello @zyga. Thank you very much for checking this issue. Is there any news on your side?
Please feel free to contact me if you have anything you need to change in the Opera snap.
This is something that the store team needs to handle.
I’ve done this just now for opera-developer, opera-beta and opera. I tested that auto-connect is happening correctly with:
$ snap interfaces opera-developer Slot Plug chromium-ffmpeg:chromium-ffmpeg-93464 opera-developer ... gnome-3-28-1804:gnome-3-28-1804 opera-developer gtk-common-themes:gtk-3-themes opera-developer gtk-common-themes:icon-themes opera-developer gtk-common-themes:sound-themes opera-developer ... $ snap interfaces opera-beta Slot Plug chromium-ffmpeg:chromium-ffmpeg-93464 opera-beta ... gnome-3-28-1804:gnome-3-28-1804 opera-beta gtk-common-themes:gtk-3-themes opera-beta gtk-common-themes:icon-themes opera-beta gtk-common-themes:sound-themes opera-beta ... $ snap interfaces opera Slot Plug chromium-ffmpeg:chromium-ffmpeg-93464 opera ... gnome-3-28-1804:gnome-3-28-1804 opera gtk-common-themes:gtk-3-themes opera gtk-common-themes:icon-themes opera gtk-common-themes:sound-themes opera ...
I noticed that opera didn’t pass automated review due to it adding the dbus interface, and granted a snap declaration for that as well.
Thank you very much for all your help. It’s indeed working now. I just released new versions of Opera and Opera Beta.
opera 66.0.3515.44 rev.63 from
stable – works fine.