Also, human review is needed for our opera-beta build.
The Store automatic review failed.
A human will soon review your snap, but if you can't wait please write in the snapcraft forum
asking for the manual review explicitly.
If you need to disable confinement, please consider using devmode, but note that devmode
revision will only be allowed to be released in edge and beta channels.
Please check the errors and some hints below:
- human review required due to 'deny-connection' constraint (interface attributes)
The snap added a dbus slot. I issued the snap declaration just now and future uploads should pass automated review. I reran the review on r52 and it passed automated review (but you’ll need to release to a channel still).
This should already be happening when you install from the store since gnome-3-28-1804 has a snap declaration that allows it. Once your new revision is pushed to a channel (see my last response), please verify this is the case and report back if it is not.
Hum, maybe I am wrong but I don’t think that’s configurable from my snapcraft.yaml. I updated the yaml file according to this guide https://snapcraft.io/docs/gtk3-applications. It seems the only line related to gnome-3-28 is this part: extensions: [gnome-3-28]
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:
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.
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.
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.
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.
