That was how I was reading things, too. I’m glad I’m not going too crazy
@ijohnson not sure if you know anyone on the app review team, but it would be good to get an update about whether we can get this app approved soon. I’d like to make this available to our linux users vs distributing appimages. Snap is so much better!
@reviewers, please review this request for allow-sandbox
support for the browser-support
interface. It is requested to be allowed and automatically connected.
I think one action item here is to explore upstreaming electron to understand more chromium flags, specifically --disable-dev-shm-usage
, I would try this out myself, but I have no idea how to rebuild electron
well, check my second link, you should be able to hand over options to chromium from inside your app … (not via an electron commandline switch though)
Forgive me if I’m being dumb here, but from what I remember seeing when I was looking into this, --disable-dev-shm-usage
did have an effect, see the post here where Electron starts writing to /run/user instead of /dev/shm, and still continued to fail.
I think it’s a bit onerous to expect every electron-using app to figure out that they need to add code to fix electron…
indeed, this was just to get rolling, not a permanent solution
So from a reviewers point-of-view, it would be great if beeper
can be made to work without allow-sandbox: true
since this can be done without the requirement of a snap declaration.
In the meantime, if this is definitely needed, I would request that the snap publisher be vetted as is done for classic confinement requests as this request gives the snap quite a lot of privilege on the device.
@advocacy could you please perform publisher vetting?
+1 from me, I vetted the publisher, so if we want to go ahead with an interim classic confinement, although it would be better to try to resolve specific sandboxing issues.
Great, thanks everyone! Let me know what the next steps are. There are two apps to approve: Beeper and Beeper-beta
FYI the reason I asked for vetting was not for classic confinement but so that we could gain trust in the publisher for this specific request for allow-sandbox:true
- as background, this grants more privileges to a snap (so that it can configure the internal chromium sandbox) and so we need to gain more trust in the publisher in this case (so it is similar to the case of when we grant classic confinement in that regard).
+1 from me to then grant allow-sandbox: true
for beeper-beta
and beeper
.
+2 votes for, 0 votes against, this is now live. Any new snap revision which is uploaded should automatically pass review.
@beeper You should be good to go now - The next step is to reupload your builds which will now go through the checking without issues.
Works perfectly! Thanks everyone for the help
Unfortunately running into an error. This snap works fine when I compile it and run it locally with sudo snap install --devmode
but after I’ve uploaded it to Snapcraft I tried sudo snap install beeper-beta
the app no longer works correctly. It appears that it cannot connect to the internet from the snap container…all the network calls are failing
Here is a copy of the snap that I uploaded with snapcraft upload --release=stable
https://dl.todesktop.com/201202u1n7yn5b0/builds/210226a4sz0eba0/linux/snap/x64
I don’t have a beeper account but it seems to work fine for me - after installing and launching beeper-beta I am presented with a sign-in dialog and if I try and specify a random username/password I am told ‘Incorrect username and/or password’ - perhaps there is an issue with your local install… Can you try retesting on a separate machine?
Interesting, maybe it’s just my ubuntu install. I tried a fresh ubuntu vm and it works fine…thanks for checking for me @alexmurray
Excellent - thanks for checking - let me know if you do notice anything amiss still.