Call for testing: chromium-browser deb to snap transition

2 posts were merged into an existing topic: Please, do not use snap into UBUNTU, it’s too early

A custom AppArmor profile. Interfaces are all or nothing, for $HOME access, with some built in protection like no access to hidden dirs. Yes you can disconnect the home interface, but then you have no access at all and you have to hunt down specific snap version’s protected “home”… Yes, theres “current” symlink but that means no persistence on update, if you want some dirs persistently available to the snap.

But this is just one example. The ability to have custom, persistent profiles for snaps is of critical importance, IMHO, if snaps are to replace .deb packaged applications (or to be precise, if snaps are to replace non-containerized installations with full filesystem access by default).

I have not tested that use case myself, but the import mechanism is a per-user one, so that part at least should work as expected.

Any plans for making Firefox (and to less extent Thunderbird) also a snap program by default?

1 Like

Anybody made chromium-snap 75 work with widevine ?

one click test here

Yes, widevine works here, see this thread on the snapcraft forum.

A bump for a very visible (invisible?) regression from the deb :smiley: Bug #1821765 “[snap] Missing icon in indicator” : Bugs : chromium-browser package : Ubuntu

I have apt installing some packages, and thus holding the lock. I have snap installed yet it tries to install it (or check?). I have Firefox on screenshot but it doesn’t matter. Probably the correct action is just do snap install if apt is busy

snapd and apt are two totally independent packaging systems, the lock for the former doesn’t affect the latter, and vice versa. If the problem persists please report it by running ubuntu-bug gnome-software, and please try to keep the feedback on this thread related to the chromium snap. Thanks!

1 Like

Over the past couple of days I’ve tested the installation of Chromium on each of the Ubuntu flavours using that day’s ISO. Unfortunately, I don’t currently have the necessary resources to install to disk or VM so the installation of Chromium was done in a live session.

Installation completed quickly for Ubuntu but was very slow for the flavours as I saw an “INFO Waiting for restart…” message displayed for some time. Is this due to Ubuntu already having snaps installed and configured? However, installation was successful in every case.

Further to my comment in a previous post in this thread, I see that on Ubuntu and Ubuntu Budgie, the mouse pointer when hovering over a link is a black upward pointing hand but on Ubuntu MATE, Kubuntu, Lubuntu and Xubuntu it is a rather retro looking white left pointing hand. Is this something that can be fixed?

1 Like

Why is the removable-media connection not enabled by default?

1 Like

Thank you for your testing and feedback Paul, this is much appreciated!

The slow installation observed on flavours is indeed because snapd isn’t installed and configured there, whereas it is installed and the core snaps are preseeded on Ubuntu proper.

Could you please file a bug for the mouse pointer issue? I’ll certainly investigate to try and fix it.

1 Like

Auto-connection for the removable-media interface has been requested, the request has to go through the approval process by store moderators now.


Bug 1833611.

In a new installation of EOAN it’s not possible to install gnome extensions in Chromium.
You get this error message
“Although GNOME Shell integration extension is running, native host connector is not detected.” Refer documentation for instructions about installing connector."
The method advised in the instruction “GNOME Shell integration for Chrome Installation Guide”
$ sudo apt-get install chrome-gnome-shell
isn’t working.

You already posted that content in comment #26 there is no need to repeat the information

If you want to use Snaps, why don’t you install Snaps instead of installing a deb to install a Snap? What if the user don’t want to use this Snap? You have all the right to use Snap as default to most apps, and i thinks it’s a good idea, but use the Snap’s CLI and Store to do so and do not hijack apt/deb packages. It will only confuse users and break systems and distros.

1 Like

This is a transition from the deb to the snap. At some point in time the deb ceases to be supported, and its users need to be upgraded to the snap, as seamlessly as possible.

Of course new users are encouraged to install the snap directly, instead of the transitional deb wrapper.

Can you elaborate on breaking systems and distros?

As some users already stated there are yet several drawbacks in using Snaps (themes, extensions, init time, …). For instance, installing it on a system that doesn’t have snap pre-installed the icon will not appear in the menus right after installation is finished because snap path is not loaded yet. Trying to install a legacy version of the package is also not an easy task, because the packages names are the same, including dependencies. Apt/Debs installations may conflict with Snap installations, because now one is a dependency of another. It even takes out the opportunity of other distros build their own packages, because packages name are already taken.

Also, breaking a system doesn’t necessarily means breaking it completely, but if the user is used to do something and having a result, if he/she does the same in an updated system it is expected the same result. So, if chromium is installed using apt/deb is expected to work in a way but this is not true if instead a Snap is installed. Themes are the the easiest example to give, as you may see in the picture. I’ve test with several themes, including Arc and Numix that were installed via apt. Arc was the only one that worked, but even Adwaita didn’t work as expected.

Please rethink this idea of converting actual apt packages into snap wrappers. I know it makes sense for Canonical as a market move, but it’s totally against system’s transparecy, user freedom and project coherency, things that Canonical are known for. You should use Snap but please don’t mess up with apt repositories, just remove the packages and instruct people to use snaps or the store. Inexperienced users will probably use the Store anyway and advanced users will notice that the only available source is snap.

The reason is nor a ‘market’ move as you wrote but simply ensuring that users upgrading don’t get stucked in a old insecure version. If we were to remove the deb then an user upgrading to the next version of Ubuntu would end up with a chromium deb installed that would never get any update ever (since the archive wouldn’t have any new build for that package)…