Hello,
Opera starts building snap packages with gnome-3-28 extension and core18 base. We would like to have auto-connect to gnome-3-28-1804 interface for the desktop environment it needs.
You can test the opera-developer build on its edge channel:
snap install opera-developer --edge
Please noted that opera, opera-beta and opera-developer will need to auto-connect to gnome-3-28-1804. New snaps for opera and opera-beta will be uploaded later.
Thank you very much!
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.
I just released opera-beta 66.0.3515.8 to its edge channel and installed it to my machine. I don’t think gnome-3-28-1804 is connected and the browser crashes with the issue I posted in Opera stops working after upgrade due to gnome connection issue.
$ snap connections opera-beta
Interface Plug Slot Notes
audio-playback opera-beta:audio-playback :audio-playback -
avahi-observe opera-beta:avahi-observe - -
browser-support opera-beta:browser-sandbox :browser-support -
camera opera-beta:camera - -
content[chromium-ffmpeg-93464] opera-beta:chromium-ffmpeg-93464 chromium-ffmpeg:chromium-ffmpeg-93464 -
content opera-beta:gnome-3-28-1804 - -
content opera-beta:gtk-3-themes - -
content opera-beta:icon-themes - -
content opera-beta:sound-themes - -
cups-control opera-beta:cups-control - -
dbus - opera-beta:dbus-daemon -
desktop opera-beta:desktop :desktop -
desktop-legacy opera-beta:desktop-legacy :desktop-legacy -
gsettings opera-beta:gsettings :gsettings -
home opera-beta:home :home -
mount-observe opera-beta:mount-observe - -
network opera-beta:network :network -
network-control opera-beta:network-control - -
network-manager opera-beta:network-manager - -
opengl opera-beta:opengl :opengl -
password-manager-service opera-beta:password-manager-service - -
process-control opera-beta:process-control - -
pulseaudio opera-beta:pulseaudio :pulseaudio -
screen-inhibit-control opera-beta:screen-inhibit-control :screen-inhibit-control -
unity7 opera-beta:unity7 :unity7 -
upower-observe opera-beta:upower-observe :upower-observe -
wayland opera-beta:wayland :wayland -
x11 opera-beta:x11 :x11 -
sudo snap connect opera-beta:gnome-3-28-1804 gnome-3-28-1804 solves the crash for me.
Your snap is using:
gnome-3-28-1804:
default-provider: gnome-3-28-1804:gnome-3-28-1804
interface: content
target: $SNAP/gnome-platform
I think the default-provider may be wrong. Other snaps that auto-connect use:
gnome-3-28-1804:
interface: content
target: $SNAP/gnome-platform
default-provider: gnome-3-28-1804
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]
You can find the whole snapcraft.yaml here.
@kenvandine - can you or someone from your team help @xshi?
Hello, @jdstrand @kenvandine. Any update about the default-provider issue?
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!
@kenvandine (or someone from the desktop team) or perhaps @zyga-snapd, can you comment?
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-snapd - 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.
Having used 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).