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.
@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).
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.
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:
The update contains a few additions:
Electron v6 to v8
Support for xdg-open
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!