Focal Testing of Kubuntu 20.04 LTS

[kubicle]

and "Unlock Widgets" shows up on the right mouse click on the panel.

Then it's not 5.17.90 (which is 5.18 Beta), the lock mode is already gone in the beta.

[WWDERW]

Appimages don't really have a centralized store to find them, the format is basically meant for developer direct distribution. I'd probably use great care for picking them up on just any site that provides them en masse, the trustworthiness of such images is not easily determined, probably better to rely on appimages that are straight from the developer (this is what they are meant for).

Doesn't Snap have some of that concern as it is up to the person uploading the snap for distribution. It doesn't have the curated aspect as it would with regard to the deb packaging.

And that is a snap package, not a regular deb so it needs the snap "plumbing" to work. (https://snapcraft.io/blog/chromium-i...nap-transition)

And that is why I don't consider snaps a truly portable platform. Have the performance/storage hit of a portable program, but without some of the true benefits of the program being truly portable. Due to that, I would hate to see something like Ardour as a snap.

[kubicle]

Doesn't Snap have some of that concern as it is up to the person uploading the snap for distribution. It doesn't have the curated aspect as it would with regard to the deb packaging.

To a degree, of course (the situation is roughly similar to the ppas, which are mostly used for similar purposes), but we can't really know for sure that everyone that has upload rights to official deb repositories is 100% trustworthy either. We generally choose to trust official repositories because we trust the maintainers of the infrastructure to care enough to remove malicious code if it's distributed through them (it's still a system of trust, and not an absolute guarantee).

Some links:
Malware in the snap store: https://snapcraft.io/blog/trust-and-...the-snap-store (could obviously happen in any application delivery format, be it the repos, ppas, snap, flatpak or appimage)
Snap containment is vulnerable under X: https://itsfoss.com/snap-package-securrity-issue/ (not specific to snaps, of course, just that the "containment' offers very little security, although this might (should) improve on wayland)

[oshunluvr]

Ahem. I think I linked this at least three times in this tread.
With mentions of filesystem clogging and pathetic boot times.
I also guess no-one bothered to read it (the first post in the thread is enough.)

I have nothing against the idea of self-contained or portable apps. I have no problems with appimages. I have no experience of flatpaks.
The idea of snaps in fine... up to a point.
The implementation is absolutely horrible.

You have no obligation to reply, so feel free not to. I stated I was late to the thread.

[WWDERW]

kubicle, that is true. Just like any OS isn't totally without it's exploits for viruses, just some have less of a chance of getting them.

The thing that gets me is that with snaps, you have the performance hit of an Electron app (despite most snaps being written with low level languages that have direct access to hardware and this is coming from someone that not only likes Electron apps, but develops using that technology as well) without the true portability (other then the user not being bound to dep, rpm etc packages, which even that isn't all that true since deb and rpm packages are essentially compressed files and get be treated like a zip, tar, rar file) of a binary archive, .run. and/or AppImage.

So one has the hit of a containerized app, but very little benefit.

Now, my preference for portable/contained apps really isn't from the security aspect, but I don't like my production software bound to the OS system/libs to where I have to worry about updating this, that or the other breaks compatibility (and it may not be updating the snap itself, but a library that is updated breaking an extension that I use often. That type of thing). With snaps they always tough this always be up to date, but I may not want that for every piece of software as well. Some things yes, but not everything. But I certainly don't want an app that is already resource intensive (internet browsers) being even more so.

[kubicle]

kubicle, that is true. Just like any OS isn't totally without it's exploits for viruses, just some have less of a chance of getting them.

The thing that gets me is that with snaps, you have the performance hit of an Electron app (despite most snaps being written with low level languages that have direct access to hardware and this is coming from someone that not only likes Electron apps, but develops using that technology as well) without the true portability (other then the user not being bound to dep, rpm etc packages, which even that isn't all that true since deb and rpm packages are essentially compressed files and get be treated like a zip, tar, rar file) of a binary archive, .run. and/or AppImage.

So one has the hit of a containerized app, but very little benefit.

Now, my preference for portable/contained apps really isn't from the security aspect, but I don't like my production software bound to the OS system/libs to where I have to worry about updating this, that or the other breaks compatibility (and it may not be updating the snap itself, but a library that is updated breaking an extension that I use often. That type of thing). With snaps they always tough this always be up to date, but I may not want that for every piece of software as well. Some things yes, but not everything. But I certainly don't want an app that is already resource intensive (internet browsers) being even more so.

I don't disagree with you, and I'd absolutely hate it if someone feels I'm "defending" snaps here.

I've been quite vocal (even excessively so) about how IMO the technical impletentation is a mess (that can't easily be fixed) and how the whole snap infrastructure should be quickly placed to the same recycle bin where you find the rest of Canonical garbage (upstart, unity, mir) that all ended up there because Canonical stubbornly refuses to understand how the free software ecosystem works and how to work with it rather than trying to do their own thing and trying to coerce everyone else to accept their crappy excuse for software engineering.

[GreyGeek]

Then it's not 5.17.90 (which is 5.18 Beta), the lock mode is already gone in the beta.

Hmmm... could have fooled me. Here's the screen capture:

[GreyGeek]

Appimages don't really have a centralized store to find them, the format is basically meant for developer direct distribution. I'd probably use great care for picking them up on just any site that provides them en masse, the trustworthiness of such images is not easily determined, probably better to rely on appimages that are straight from the developer (this is what they are meant for).

It is obvious that AppImages don't have a "repository" in the regular sense, and the importance of site selection is also obvious.

With the discover backend installed by default, you can install them directly from Discover, not really complicated at all. Link: https://pointieststick.com/2018/01/1...t-in-discover/ (I am assuming the flatpak backend is installed by default on 20.04, but I'm not 100% sure, but in case it isn't, it's just one "apt install" away)


Due to the technical implementation of snaps, it's snapd's job to create the loop mounts (and other "plumbing") for the snap you run, so it's necessary to have the daemon running for running installed snap software (it's not just for installing, updating and removing snaps), terminology explained: https://askubuntu.com/questions/9634...nappy-refer-to


And that is a snap package, not a regular deb so it needs the snap "plumbing" to work. (https://snapcraft.io/blog/chromium-i...nap-transition)

Except that I deliberately removed snapd, and its sockets and its "plumbing" (squashfs mount points that chromium used), and chromium-browser. BTW, reinstalling snapd did not re-create the mount points. I had to do that manually. That's when I decided to forget the trench work and just roll back. Three minutes later I was running my 20200122 snapshots and 5 minutes later I had 202 updates installed.

[GreyGeek]

....
IMO the technical implementation is a mess (that can't easily be fixed) and how the whole snap infrastructure should be quickly placed to the same recycle bin where you find the rest of Canonical garbage (upstart, unity, mir) that all ended up there because Canonical stubbornly refuses to understand how the free software ecosystem works and how to work with it rather than trying to do their own thing and trying to coerce everyone else to accept their crappy excuse for software engineering.

It would be perfect if snapd were resting comfortable along side upstart, unity and mir in the trash bin. Something to hope for.

Since that may take a few months or years, my next concern is what Canonical plans to do with the repository that has accompanied Ubuntu/Kubuntu since their inception? They are redundant sources of application but will the repository contain the best and the latest, or will it shrivel on the vine and die? Discover/Muon/Synaptic have no running daemons and are not active when the user is not actually removing, installing or updating their applications. Snapd is in our face all the time. Flatpak requires that you "add remotes" (repositories) despite the fact that we have a repository already. So, in affect, it becomes just another PPA.

For years I've seen the packages in the repository grow in number from 35,000 to 85,000 and drop back to 65,000 only recently (dropping 32bit packages?). I can't imagine, at this point, that snapd or flatpak would have access to that many packages. All Canonical is doing is throwing mud into what was once a sparkling pool.

[Don B. Cilly]

Just out of curiosity, why would you want to have Chromium even though it's snap-only?
Brave for example is basically Chromium, it's open-source and does not come as a snap.

[kubicle]

Hmmm... could have fooled me. Here's the screen capture

That is certainly odd. It definitely shouldn't be there. So, the command 'plasmashell --version' reports 5.17.90 and the unlock widgets option is still there after restarting plasma (or logging out or rebooting)? It definitely shouldn't be, but I'd probably have to install the beta to dig any deeper.

Except that I deliberately removed snapd, and its sockets and its "plumbing" (squashfs mount points that chromium used), and chromium-browser. BTW, reinstalling snapd did not re-create the mount points. I had to do that manually.

I'd think that is probably because you manually disabled all that plumbing/mounts. While it can be considered somewhat unexpected that a user would purposefully disable things that are necessary for the snap to work, snapd *should* be able to handle such occurrences (and if it doesn't, it's just another example that the coding isn't technically up to par).

The "repository" version of chromium-browser (the deb package) is 47kb in size (it would obviously be quite a feat to fit a modern browser into it), the pre/postinstall scripts within the package just install the snap version from the snap store, and the /usr/bin/chromium-browser file installed by that deb is just this script (pasting only the important bits):

#!/bin/sh
if ! [ -x /snap/bin/chromium ]; then
echo "" >&2
echo "Command '$0' requires the chromium snap to be installed." >&2
echo "Please install it with:" >&2
echo "" >&2
echo "snap install chromium" >&2
echo "" >&2
exit 1
fi
...
[DESKTOP SPECIFIC CODE HERE]
...
[HL]exec /snap/bin/chromium "$@"[/HL]

Since that may take a few months or years, my next concern is what Canonical plans to do with the repository that has accompanied Ubuntu/Kubuntu since their inception?

Well, ubuntu basically copies the stuff they want from debian (with only small changes), and then put their crap on top of that. Obviously the base system will always come in debs, but my guess is that Canonical is planning to eventually replace the user facing apps in ubuntu with snaps, which reduces their maintenance efforts/costs (and shift that maintenance to upstream devs that will be responsible for maintaining the snaps). This will likely be a tough pill to swallow for many ubuntu users, but that's what you get with Canonical.

They are redundant sources of application but will the repository contain the best and the latest

The deb repositories of released versions will never contain "the latest" as *buntus aren't rolling releases. The snaps are probably also an attempt (a poor one) to remedy that (so you could get newer apps that are available in the repos...or apps that are unavailable in the repos).

Discover/Muon/Synaptic have no running daemons and are not active when the user is not actually removing, installing or updating their applications. Snapd is in our face all the time. Flatpak requires that you "add remotes" (repositories) despite the fact that we have a repository already. So, in affect, it becomes just another PPA.

While I dislike the snap infrastructure, the contained package formats do offer several advantages over the ppas (which really are problematic in many ways...compatibility and security issues are a real problem)...there are a few "official ppas" that can be considered quite secure, but even those suffer from many compatibility (and maintenance) issues.

[NoWorries]

I have certainly enjoyed reading all the contributions to views on snap and its uncertain future. But I am seeking help on a problem that I have encountered which is not related to snap.

When I enable muon updates with Pre-release updates, it tries to remove 8 essential packages as shown in this image



As far as I can tell the package ubuntu-drivers-common should not be installed. On my other system with Focal it is not install and it is treated as a virtual package which cannot be installed or upgraded. If I try to remove ubuntu-drivers-common it wants to remove:

• kubuntu-driver-manager
• kubuntu-desktop
• kubuntu-notifications-helper

I am wondering if I should remove ubuntu-drivers-common and then install the ones it has removed.

I am open to any suggestions to solve this problem.

[kubicle]

When I enable muon updates with Pre-release updates

My best recommendation is, don't.
the "proposed" repository is where packages are built and tested, and dependency breakage is fairly common, it makes very little sense to enable it unless you specifically wish to find out what is broken (development). When packages are issue free, they get moved to the regular repos in a matter of hours or days. The dependency problems could be caused by the python changes in focal or a number of other things, but are generally not really solvable by user actions (that's why they are in proposed).

As far as I can tell the package ubuntu-drivers-common should not be installed. On my other system with Focal it is not install and it is treated as a virtual package which cannot be installed or upgraded. If I try to remove ubuntu-drivers-common it wants to remove:

• kubuntu-driver-manager
• kubuntu-desktop
• kubuntu-notifications-helper

I am wondering if I should remove ubuntu-drivers-common and then install the ones it has removed.

I am open to any suggestions to solve this problem.

ubuntu-drivers-common is the driver check/install commands and backend used by the various DE specific GUI tools for driver install (like "kubuntu-driver-manager"), which depend on it...so it actually should be installed if you have "kubuntu-driver-manager" installed (i'm not on focal so I can't directly check if there are any changes to the dependency chain, but I doubt it). EDIT, checked, kubuntu-driver-manager still depends on ubuntu-drivers-common on focal.

[GreyGeek]

I ran into that same problem yesterday. This morning I rolled back to 20200122.

After doing a 22 file upgrade earlier today, I opened Muon to check my repository settings and when I entered the password it took me back to the main GUI.
This was the error msg:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Traceback (most recent call last):
File "/usr/bin/software-properties-kde", line 38, in <module>
from softwareproperties.qt.SoftwarePropertiesQt import SoftwarePropertiesQt
File "/usr/lib/python3/dist-packages/softwareproperties/qt/SoftwarePropertiesQt.py", line 56, in <module>
from UbuntuDrivers import detect
ModuleNotFoundError: No module named 'UbuntuDrivers'

But, XDG_RUNTIME_DIR was set:

:~$ env | grep XDG
XDG_CONFIG_DIRS=/etc/xdg/xdg-plasma:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_TYPE=x11
XDG_CURRENT_DESKTOP=KDE
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_VTNR=1
XDG_SESSION_ID=3
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/usr/share/plasma:/usr/local/share:/usr/share:/var/lib/snapd/desktop

I redid "sudo apt update & sudo apt full-upgrade" and got only two apps held back (libwin32 and wine32). So, out of curiosity, I opened Discover. It said I had 41 apps ready to update. So, I let it run. I still can't access my repository setting dialog, however.

Discover must bedrawing from the snap store. That means that either I abandon Muon and use Discover only, or I run apt from the command line and Discover from the menu.

I hope this is not the way Kubuntu is heading. And, if it is, how can Neon avoid it without re-engineering its Ubuntu base?

[NoWorries]

ubuntu-drivers-common is the driver check/install commands and backend used by the various DE specific GUI tools for driver install (like "kubuntu-driver-manager"), which depend on it...so it actually should be installed if you have "kubuntu-driver-manager" installed (i'm not on focal so I can't directly check if there are any changes to the dependency chain, but I doubt it). EDIT, checked, kubuntu-driver-manager still depends on ubuntu-drivers-common on focal.

I have two systems with Focal. One is an ASUS with an Nvidia video and the other is a HP with an AMD Radeon RX Vega video.

My ASUS does not have "kubuntu-driver-manager" installed or "ubuntu-driver-common" and has no problems with the Pre-release updates. Whereas my HP which is a UHD display has both "kubuntu-driver-manager" and "ubuntu-driver-common" installed.

I have with previous distributions encountered problems with Pre-release updated and waited for this problem to pass. In this case I found the difference a little odd and that is why I decided to seek a solution.

I will take your advice and wait out until the problem packaged is fixed. At least Muon gives me a good guide on what is going to be removed.