Open xela92 opened 2 years ago
Can confirm that this is reproducible on my Ubuntu 22.04 machine. This does look like it might be an issue with the confinement of the snap given the output of dmesg
:
sudo dmesg | grep masscode
There are a lot of AppArmor denied messages being generated. Also, the file chooser has issues accessing other file system locations such as removeable media.
If had to give my best guess as to what the issue is, I believe the snap package is missing a couple of interfaces common for advanced Electron apps. The snap package could probably benefit from these interfaces:
I have built snaps for Electron apps before so I am going to play around with this issue a bit.
When I hit the "Move Code" button, this is what I get.
Can confirm that this is reproducible on my Ubuntu 22.04 machine. This does look like it might be an issue with the confinement of the snap given the output of
dmesg
:
sudo dmesg | grep masscode
There are a lot of AppArmor denied messages being generated. Also, the file chooser has issues accessing other file system locations such as removeable media.Potential solution
If had to give my best guess as to what the issue is, I believe the snap package is missing a couple of interfaces common for advanced Electron apps. The snap package could probably benefit from these interfaces:
I have built snaps for Electron apps before so I am going to play around with this issue a bit.
The strangest thing is: I expected that manually putting the path won't work if it was a snap confinement issue, instead it works fine 🤔 is it related to the "--dangerous" flag passed during installation?
The strangest thing is: I expected that manually putting the path won't work if it was a snap confinement issue, instead it works fine thinking is it related to the "--dangerous" flag passed during installation?
The --dangerous
flag just tells snap to install the package without checking its PGP signature. This allows you to install .snap files without needing to link against the author and/or Snap store. Without the signature check, the package is considered "unverified," which is fine if you trust the author and the author is trustworthy.
That being said, if I install the package as snap install masscode_2.6.1_amd64.snap --dangerous --devmode
, I am able to read my external storage device, but I still do not have write access to any of my directories. --devmode
is essentially --classic
(do not confine the snap) but you cannot release snaps in --devmode
from the Snap store.
Considering the above, there might be one or two issues here :thinking:. It might be an issue with how the snap is confined, or how the snap is confined + how the file chooser is configured for Linux distros. I am going to take a swing at this issue tonight (America/New_York time) to see if it is just a confinement issue with the snap. My first idea is that I am thinking we might need to delegate the snap build to a snapcraft.yaml
file from electron-builder.
I think this is maybe a solution:create a path /mnt/masscode,link the path to the storage directory and add the "removable-media" plugin to snap file, according to removable-media-interface
temporary solution: (1)add the directory to the left column of nautilus (2)edit the snapcraft.yaml file,change "confinement: strict" to "confinement: devmode". (3)rebuild massCode (4)reinstall massCode。
snap install masscode_2.9.0_amd64.snap --dangerous --devmode
(5)change massCode "storage" by selecting the directory in the left column of nautilus
Yeah, after playing with the snap build for the past couple of days, I believe there is a multitude of issues with the Linux build in general. Not sure if any of you are experiencing this, but MassCode is not detecting any of my fonts and the cursor in the editor doesn't behave right.
I should have something brewed up soon for fixes, but I believe part of it will involve editing some of massCode's source code as well as modifying the snap build. Also, you shouldn't need to rebuild the snap to enable devmode
. You should just be able to install massCode in devmode
by just passing the --devmode
flag when you install the already built snap package.
If it's so complicated with .snap, maybe you could just try another build, like AppImage?
Just set here target: ['AppImage']
@NucciTheBoss thank you.I just let the font setting blank,the cursor in the editor behaves right.a temporary solution ^_^
If it's so complicated with .snap, maybe you could just try another build, like AppImage? Just set here
target: ['AppImage']
I quote, appImage would also make the update feature more useful (you would have a download file for Linux), or you could even integrate appImage update mechanism
I wouldn't say the issue is that the snap is too complicated - it's more that I'm an apprentice with JavaScript x Electron so this is a bit of a learning experience 😅
Adding the removable-media
interface fixes the external drive issue, but the issue with the fonts is that it is preconfigured to use fonts that are not traditionally available on Linux-based systems. I figured this out by comparing the snap package with the unpacked massCode build. This could be resolved by either adding a font stagePackage or changing the default fonts for Linux.
Regarding AppImage
, this would be a good idea given that not every Linux distro system rolls with systemd
and thus you cannot install snapd
. The update feature could piggy back off of each's respective update mechanism. For now I'm going to focus on the snap because I know what's up with that, but we could tack on AppImage in another pull request.
Symbolic link could be a temporary solution for sync files:
sudo ln -s /path/to/your/sync/db.json /defaultPath/to/masscode
Symbolic link could be a temporary solution for sync files:
sudo ln -s /path/to/your/sync/db.json /defaultPath/to/masscode
As stated in the OP, another workaround is to manually specify the path from the file picker UI (CTRL+L), the file is being created on the destination folder
I'm getting a similar error to @xela92 which is apparently related to snap issues with Electron. I second the desire for an AppImage (or Flathub, which works great). Running on Manjaro Linux over here, so have access to the AUR but nobody is posting MassCode anywhere, it's a standalone snap file or nothing. I love the app (use it on my Mac) and would love to use it on my Linux box too!
It is not a problem to just specify the target for the build as an AppImage, the problem is that I can not run AppImage in Ubuntu virtualization, I just get a blank application screen, while .snap
works. This is the reason why I'm shipping the build in .snap
. https://github.com/massCodeIO/massCode/issues/100#issuecomment-1186086270
Hi Anton, thanks for your quick reply! I fully understand and I'm already beyond grateful there's even a Linux version to play with. It's just unfortunate that snap is causing this issue on my system. It seems to be an error between Electron & snap in some cases.
It's highlighted in this issue for draw.io as well: https://github.com/jgraph/drawio-desktop/issues/368 Is it possible / easy to create a flatpak instead? They're very similar in design to a snap, but they tend to be faster (the whole "Firefox being a foced snap" Ubuntu conversation highlighted that and made me move away from Ubuntu to Manjaro, for example). Flatpaks may compile easily too? On Aug 13 2022, at 3:49 pm, Anton Reshetov @.***> wrote:
It is not a problem to just specify the target for the build as an AppImage, the problem is that I can not run AppImage in Ubuntu virtualization, I just get a blank application screen, while .snap works. This is the reason why I'm shipping the build in .snap. #100 (comment) (https://github.com/massCodeIO/massCode/issues/100#issuecomment-1186086270) — Reply to this email directly, view it on GitHub (https://github.com/massCodeIO/massCode/issues/100#issuecomment-1213942194), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AFQT3CARIASQZZQHRSE26SLVY5HO5ANCNFSM52V5NX6Q). You are receiving this because you commented.
I cant access any location in the home folder, even with the appImage build.
Is there any update on this? I am having the same issue.
Describe the bug
On Linux (snap), it's difficult to select a directory to move storage to.
The file chooser seems to be confined to default directory: but if a user hits CTRL+L and specifies manually a path, the file gets written and everything works.
That leads to misunderstandings, initially I thought there was a problem with snap confinement, but seems it's not the case.
To reproduce
Version
2.6.1
OS
Ubuntu 22.04
Validations