This is a new build based on core18. It has been thoroughly tested internally on all supported Ubuntu releases (from trusty to cosmic), debian testing and fedora 28, and is now open for wider testing.
How to install
snap install chromium --candidate
or, if you’re already using the chromium snap from the stable channel:
Also note that the snap can coexist with the ubuntu packages. If you wish to remove the ubuntu packages to use solely the snap, you can do:
sudo apt remove “chromium-*”
Specific Tests
I’m interested in your feedback using the snap for your normal browsing activities and workflows, including web development.
Please report any issues you encounter in this thread, especially those that appear to be regressions from the version in the stable channel (which is based on core16). Thanks!
Adding to @pachulo comment, using the GTK+ theme is broken in Ubuntu 18.10 with the default Yaru theme… Is this another case of snaps having wrong theming or is it specific to Chromium?
It appears that one profile is configured to use the system title bar and window borders, whereas the other one uses a custom frame. You can change that by browsing to chrome://settings/appearance
This may be not core18 specific (or even chromium specific) but when I open file dialog (i.e. to import bookmarks) and select my {HOME} dir, then I have access denied logged for most my dotfiles. This is especially annoying when aa-notify is running on system as it causes the whole screen being filled with notifications.
Is it possible to explicitly DENY access to all dotfiles in apparmor profile so access to them won’t be logged?
There are also denials for /etc/fstab, /etc/mtab, /run/mount/utab.
That’s not specific to core18 or the chromium snap indeed.
The home interface allows access to the home directory, except for .dotfiles, by design. @jdstrand, can you comment on the request for explicit denials?
The new version of the chromium snap is not starting for me.
Snap list
Name Version Rev Tracking Publisher Notes
chromium 70.0.3538.110 516 stable canonical✓ -
core 16-2.36.1 5897 stable canonical✓ core
core18 18 442 stable canonical✓ base
gtk-common-themes 0.1-4-g88bc1b2 818 stable canonical✓ -
After a fresh install of the chromium snap, I get the following error:
main.go:224: cannot change mount namespace of snap “chromium” according to change mount (/snap/gtk-common-themes/818/share/icons/Suru /snap/chromium/516/data-dir/icons/Suru none bind,ro 0 0): cannot use “/snap/gtk-common-themes/818/share/icons/Suru” as bind-mount source: not a directory
execl failed: No such file or directory
child exited with status 1
I am on Fedora Silverblue 29, where /snap does not exist.
Just tested on Fedora 29, and I can confirm the problem. This works on Fedora 28.
There’s one similar report on the forum, so it doesn’t seem to be chromium-specific.
I can also reproduce with the libreoffice snap in the candidate channel (based on core18), but not with the one in the stable channel (core16).
@zyga-snapd: is that a known issue with fedora 29 / core18 ?
Not from the store, all channels have been updated and are built based on core18 now.
You can check whether you still have an old revision in /var/lib/snapd/snaps/. If so, you could install it manually (passing snapd the --dangerous flag).
The first two should go away if you snap connect chromium:mount-observe. It is almost always fine to ignore these (it is noise from libc6). The last is not allowed in standard interfaces (see Namespace awareness of /run/mount/utab (and libmount)).
you could potentially put the older version on a channel branch as a momentary measure on stable/<branch-name> to ensure a fallback to stable is in place with the idea that it could be fixed by when the branch automatically closes.
Unfortunately I don’t have any older revisions in this folder. It would be nice, if a fallback channel exists, which users could use, until this problem is fixed.
Sorry for the delay. I have re-published an old revision based on core 16 in the stable/core16 channel (version 70.0.3538.77). Note that it’s amd64 only, and I don’t intend to update it, it’s just provided as-is as a workaround for a problem I hope will be fixed very soon on the snapd/Fedora side.
Similarly, I published a core16-based build of the libreoffice snap in the stable/core16 channel. The same disclaimer goes along with it.
