Screen is an Electron-based app that supports WebRTC-based voice, video and “multiplayer” screen sharing (where others can click & type on the shared screen).
Strict confinement doesn’t currently support the ability to register the app for the screen: URL protocol, although this will be added soon via https://github.com/snapcore/snapd/pull/7129/files
Let us know if you need any other information. Thank you!
Since there is already a PR up to address the need for classic confinement (and that PR is on my list of things to review), I think granting classic at this time would be premature.
@jdstrand: do you have a timeframe for when that may happen by? If we could get classic confinement access now, we’d be happy to switch out from it once everything’s done.
No… why do you say that?
Oh, okay, my bad. Ignore me.
Hello all,
We have been patiently waiting for months for this approval since December 19th. It’s now March 30th.
We have now launched, and have users complaining about the fact that they aren’t able to run our snap unless they manually run /snap/screen/current/screen/Screen.
To fix this on our end, we’re now adding .deb and .rpm as recommended paths over Snap (just like Slack has).
Can our request for classic confinement be reconsidered and granted (just like Slack)? If not, we’ll likely be forced to leave the Snap Store since the user experience for our customers is quite sub-optimal.
J
@screen-j - my understanding was that https://github.com/snapcore/snapd/pull/7129 was the only thing that justified the request for classic. Since there has been progress on that PR and it is milestoned for the next snapd release (it needs another review from @pedronis), classic was not needed and this was removed from the reviewers queue. I apologize if this was done in error.
Your last message said that your users have to run /snap/screen/current/screen/Screen manually, but it isn’t clear to me why that is. Assuming that https://github.com/snapcore/snapd/pull/7129 will be in the next release of snapd, can you (re)state any other reasons why this needs classic?
We launched last week, and have a large number of Linux users for whom the only option is currently our snap, which is broken because we a) don’t have approval for classic confinement, and b) the PR in question has been “close to release” for more than four months. We need either one of those for our product to work (it’s why we asked for classic confinement in the first place). It’s likely why Slack also has classic confinement (although I can’t speak for the company).
Here’s a link to an article that came out reviewing our product: https://techcrunch.com/2020/03/24/screen-screensharing/
We worked really hard to have Linux support on day 1, but because our only distribution (snap) is broken, it effectively means our users are unable to fully benefit from our work. We’re now scrambling to figure out a fix.
I don’t know how many more weeks the PR review will take, but if you can grant us classic confinement now, it’ll relieve us of a huge issue where everything is ready on Linux, but our users cannot properly use our product.
I’m sorry for the difficulties you’re having. Slack’s reasoning for classic are their own and that only detracts from the conversation about your snap.
You didn’t answer my specific question: “Your last message said that your users have to run /snap/screen/current/screen/Screen manually, but it isn’t clear to me why that is. Assuming that https://github.com/snapcore/snapd/pull/7129 will be in the next release of snapd, can you (re)state any other reasons why this needs classic?”
Put another way, is that 7129 isn’t applied the only reason you need classic or are there other reasons? If other reasons, can you please list them?
Sorry this has been taking a while @screen-j. Personally, my feeling would be if a snap isn’t working, it shouldn’t be promoted, but perhaps unlisted until the technical issues are resolved. Granting classic is a bit of a brute force tool to resolve this issue. I understand it’s frustrating that a pull request which arguably would have been beneficial to land sooner, is blocking you. I too have a snap which would benefit from this change.
Have you tested the application in classic (not devmode) to make sure it functions properly?
If you’re happy it functions as expected, I’m happy for it to be temporarily granted classic, and I’ll work with you to confine it in the future.
Note though, that the people who currently have the stable release installed won’t get an automatic refresh to a classic confined version, that requires them to manually specify snap refresh --classic, if granted and published.
@popey: We have tested it in classic mode, and it does work. If you could temporarily grant us classic access, that would solve our breaking issue. We can then work to confine it once the PR is in.
We can also handle the communication with our customers to ensure they manually refresh --classic.
Thanks for providing this information. All that is left is for @advocacy to vet the publisher. They should be reaching out to you outside of this thread.
Vetting done, +1 to continue.
Granted. This is now live.
Thank you, we are now live with classic confinement and everything is working perfectly!
Is it also possible to get classic confinement for our dev package screen-dev?
Currently, we have 2 sub-optimal options:
We set our CI build server to build strict or devmode dev builds, which means our build isn’t 100% like our prod build, and we can’t test to ensure the missing functionality in these builds.
We abandon CI builds, and only build classic builds manually, but this breaks our entire automated QA system, which relies on CI.
Granting us classic confinement for screen-dev will unblock us on this issue, and will speed up our improvements to the snaps we’re able to publish.
Thanks!
Since yesterday, we’ve been alerted to the fact that our latest snap update is causing a segmentation fault on Ubuntu 19.10, but works perfectly everywhere else. Here’s a summary:
Electron v6 to v8
Support for xdg-open
Classic confinement
What doesn’t work: the snap installed from the snap store, on Ubuntu 19.10
What does work: the snap installed from the snap store, on Ubuntu 16-18, including Kubuntu
What also works: the .deb created alongside the build that’s on the snap store, on all platforms (including Ubuntu 19.10)
The issue happens only with builds built from our Azure Devops (aka VSTS) CI build servers, and not from our local machines, even when running an identical script. I even created a fresh Ubuntu 18 VM, installed everything from scratch just like our CI script does, and that worked. But for some reason, the CI build consistently causes the crash on Ubuntu 19.10.
I was wondering if anyone had any thoughts. I’m honestly at my wits end, having spent the last 12 hours on this problem along with our other senior engineer. We’re leaning towards removing snap as a download option until we have the mental bandwidth to troubleshoot this. Unfortunately, the only way to test this is to push a build out to the snap store, and then test to see if it breaks, since when we build locally, everything works fine. So having classic confinement for screen-dev would help, but it still wouldn’t solve the problem fully.
It looks like other folks have had similar issues (e.g. Slack crashes on Ubuntu 18.04), but it’s not clear exactly what they did to solve the issue. If anyone has any recommendations on how to fix this, please let us know!
Sorry this request was missed. Since this is simply a different build of screen from the same publisher who was previously vetted, granting use of classic to screen-dev. This is now live.
