Yes, I confirmed that adding AssumedAppArmorLabel=unconfined to kwallet service make dbus activation works again
Considering that almost all services don’t have Apparmor profile thus run unconfined then we can conclude that dbus activation is generally broken for snaps. Moreover patching every service, either upstream or in every distro separately sound like herculean if not impossible task. Maybe you should ask dbus upstream to revert https://cgit.freedesktop.org/dbus/dbus/commit/?id=dc25979eb or fix it some other way?
I’ve started another topic to discuss broken D-Bus activation. Hopefully there exists a solution that doesn’t involve patching every single D-Bus service file out there.
For some reason my chromium profile does not import from .config/chromium when I start the snap chromium. How does one go about importing their profile manually?
Yes, the connection should have happened automatically, sorry for the inconvenience (this is being tracked by bug #1849160).
As for the profile import, it happens only the first time the chromium snap is run, and it basically copies the contents of $HOME/.config/chromium to $SNAP_USER_DATA/.config/chromium.
It seems like the Chromium snap takes longer to start than the .deb and support for desktop “app” generation through .desktop files remains completely broken.
If you go to “More Tools… Create Shortcut / Open In New Window”, you should end up with a new “app” that you can find in the launcher and will have it’s own icon and handling when added to the dock.
The flow to create a new “app” finishes without error in the Snap now, yet no app is found in the launcher and the new app is grouped with the original Chromium app in
the dock.
I tried to workaround this issue by installing the “.deb” instead of the “.snap”, but this did
not work. The .deb file redirects to install the snap instead.
This is very frustrating. Now to get Chromium working again on Ubuntu I either have to track down a non-snap / non-deb version or switch to a Linux distribution with non-broken Chromium package.
The issue is that the snap package does not use the standard ~/.config" directory to store files. The “native client” installer for the extension installs files into ~/.config/chromium, but this fails because it’s not the directory used by the browser.
The workaround for the broken Chromium snap and the “.deb” package that redirects to it is to install the “ungoogled-chromium” package, which will works almost exactly the same except for some privacy improvements and is still available in the non-broken .deb format:
It’s not possible to share files through /tmp. The snap chromium doesn’t have access to /tmp and maps /tmp to /tmp/snap.chromium/tmp. The regular users needs super user permissions to access /tmp/snap.chromium/tmp. This is a really sad thing.
The fact that there’s one process running right now is perfectly normal, the problem was when multiple instances of it were kept running after exiting chromium.