Focal Testing of Kubuntu 20.04 LTS

[kubicle]

I get the same behaviour with my system which has KDE Plasma 5.17.90. In System Settings > Audio > Applications, I find that when I slide the notifications volume line, even to maximum volume, it immediately returns to 0%. I have not found a way to alter this response and I recognize that I am dealing with a beta version. (I have kmix and pavucontrol installed as well.)

And you have tried unmuting with kmix? Just tested it and it seems to work fine on my end (but I'm still not on 5.17.90, so it's possible the results are different)

[NoWorries]

And you have tried unmuting with kmix? Just tested it and it seems to work fine on my end (but I'm still not on 5.17.90, so it's possible the results are different)

Yes I did install kmix and I was puzzled that I did not see it on my desktop. I only found things different when I went to the speaker symbol on the panel and found a change in the controls which allowed me to unmute the event sounds.



So all is well now.

BTW, this morning I have been updated to 5.18.0 and the most significant change was the colour in the Login screen. All other features that I have encountered are the same, kazam doesn't record sound with an image, ie totally silent.

[rec9140]

Probably this bug: https://bugs.kde.org/show_bug.cgi?id=407397
Older bug, seems it is still not fixed

As a workaround, you should be able to unmute using kmix (install package 'kmix'...or using pavucontrol). It shoud work after that (even if you uninstall kmix after).

OK.. sudo apt... kmix

OK... now two speakers in the kicker.. and THAT WORKS to unmute them... Umm I guess there is some other Audio control thing in the kicker now Its been Kmix in the past until So whats the other speaker widget thing? Oh let me guess some crud from pusle(phewftt)audio...

Any way thats solved.. Thanks... Really would like to some traction that bug...

You mean the actual sound files, or the settings for changing the notification sounds for apps?

No the settings for what plays at say login, logoff, new mail etc... Its buried 20 layers deep now not in intuiative (to me) locations.. but I found it...

BUT still missing the spot where you can "test" audio devices and it play what I call the KDE sound to test that its working... from 18.04 see screen grab...

Another thing I noticed.. can't run systemsettings5 via XForwarded ssh session.. 18.04 just did it.. and got that screen grab.

Other programs from synaptic to kate to fireturdkeyox ran in a remote X SSH session fine... (thats one of my big things...I've just not went through to change all that, yet for XDMCP etc.. need to change to LightDM, lightdm-gtk-greeter, some setup to turn on... just not done it yet, YET. ) but XForwarded on SSH at least on systemsettings5 doesn't work.. it shows up on the LOCAL desktop.. no errors or anything in konsole, just popups on the local desktop.

[rec9140]

I've seen quite a few Ubuntu users install whatever is listed first in their software center thus ending up with a snap instead of a deb.

Discover, in Kubuntu 20.04, currently seems to default to the deb with a Sources button allowing the user to switch to a snap instead
I don't know what Ubuntu's Software Center does in 20.04, but Kubuntu 20.04 should see fewer complaints of users installing snaps when they didn't mean to (chromium-browser excepted!).

There are 2, ok 3 ways to install software

1) apt-get/dpgk -i via CLI for stuff I know the names or stuff I get from a DEB on a site ...

2) Synaptic - and then after I get a name I may opt to revert to sudo apt-get install just depends...

3) source - compile it, rarely

discover, muon etc. are never used... or anything like what ever those software center things are... those things need to go, go go away and take their snaps and flatpaks with them!

[kubicle]

Yes I did install kmix and I was puzzled that I did not see it on my desktop. I only found things different when I went to the speaker symbol on the panel and found a change in the controls which allowed me to unmute the event sounds.
BTW, this morning I have been updated to 5.18.0 and the most significant change was the colour in the Login screen. All other features that I have encountered are the same, kazam doesn't record sound with an image, ie totally silent.

OK.. sudo apt... kmix

OK... now two speakers in the kicker.. and THAT WORKS to unmute them... Umm I guess there is some other Audio control thing in the kicker now Its been Kmix in the past until So whats the other speaker widget thing? Oh let me guess some crud from pusle(phewftt)audio...

kmix has it's own icon in the notification area, the other is the newer "plasma-pa" volume widget. And if I wasn't clear in my previous post, you only need to unmute once with kmix, you don't need to start it automatically at startup or even have it installed after that (So you don't need to have to volume icons in the notification area...of course you can also disable the plasma volume widget if you prefer kmix). Once you've unmuted once with kmix, it will continue to work even if you don't have kmix running or uninstall it.

You can still mute/unmute and change the volume in the settings (even if you previously couldn't). Continues to work even after reboot.

Other programs from synaptic to kate to fireturdkeyox ran in a remote X SSH session fine... (thats one of my big things...I've just not went through to change all that, yet for XDMCP etc.. need to change to LightDM, lightdm-gtk-greeter, some setup to turn on... just not done it yet, YET. ) but XForwarded on SSH at least on systemsettings5 doesn't work.. it shows up on the LOCAL desktop.. no errors or anything in konsole, just popups on the local desktop.

That suggests systemsettings5 doesn't respect the DISPLAY env variable for some mysterious reason, when I have some free time I'll see if I'm getting the same. EDIT: Ah yes, have to wait for Plasma 5.18 and/or Neon 20.04 to test that, works fine on Neon 18.04/Plasma 5.17.5.

There are 2, ok 3 ways to install software
1) apt-get/dpgk -i via CLI for stuff I know the names or stuff I get from a DEB on a site ...
2) Synaptic - and then after I get a name I may opt to revert to sudo apt-get install just depends...
3) source - compile it, rarely
discover, muon etc. are never used... or anything like what ever those software center things are... those things need to go, go go away and take their snaps and flatpaks with them!

I am an "aptitude" guy (replaced synaptic for me a few years back), I don't use any GUI installers at all (or have any installed), just apt and aptitude (when I need to do more complex package management or browse packages). I also don't shy away from compiling stuff if I need to. But there are also valid use cases for contained package formats, they don't need to go away (except snaps, of course ), but should always be just options, not forced. I also think Discover is fine for new users, or users who don't like to work with cli (although I think everyone should ).

[NoWorries]

When I installed the latest updates using the command line, I noticed Discover snap packages being installed. So I checked with Muon and found snap for Discover. This is show in the graphic below.



These packages are only 295.0 KiB and 23.0KiB. Compared with the deb files which are 1.7 MiB and 8.8 MiB. I have removed them and Discover seems to still work. I must confess that I very rarely use it and keep it for when Muon configurer software sources fails, I can restore it with Discover.

[kubicle]

When I installed the latest updates using the command line, I noticed Discover snap packages being installed. So I checked with Muon and found snap for Discover. This is show in the graphic below.

[ATTACH=CONFIG]8655[/ATTACH]

These packages are only 295.0 KiB and 23.0KiB. Compared with the deb files which are 1.7 MiB and 8.8 MiB. I have removed them and Discover seems to still work. I must confess that I very rarely use it and keep it for when Muon configurer software sources fails, I can restore it with Discover.

Which packages?

The 'plasma-discover-backend-snap' and 'plasma-discover-snap-backend' are not snap packages, they are the snap backend for discover so one can install snap packages with discover if one chooses to (they depend for obvious reasons on snapd, but are not snap packages themselves, and can be uninstalled without issues if one chooses to...you just can't install snaps with discover without the backend). The reason there are two of them is that the package name has changed from plasma-discover-snap-backend > plasma-discover-backend-snap (and the former is now a transitional package that depends on the latter for smooth upgrades). There are also similar packages for the flatpak-backend, which aren't flatpaks, but regular debs (https://packages.ubuntu.com/search?k...lasma-discover).

plasma-discover is also a regular deb in the focal repos.

[NoWorries]

Thanks VERY MUCH for the clarification. This is important for those, like me, who do not want snap packages at this stage.

As you are probably aware, I tend to take risks. However, I only take those risks with Kubuntu sources and not those new ideas being promoted by Canonical.

[jglen490]

Well, there's always good old

sudo apt autoremove --purge snapd

It's supposed to get rid of all things snap-related

[rec9140]

kmix has it's own icon in the notification area, the other is the newer "plasma-pa" volume widget. And if I wasn't clear in my previous post, you only need to unmute once with kmix, you don't need to start it automatically at startup or even have it installed after that (So you don't need to have to volume icons in the notification area...of course you can also disable the plasma volume widget if you prefer kmix). Once you've unmuted once with kmix, it will continue to work even if you don't have kmix running or uninstall it.

You can still mute/unmute and change the volume in the settings (even if you previously couldn't). Continues to work even after reboot.

I prefer KMix.. and will likely remove the other widget as I find it bland, and brain dead.

That suggests systemsettings5 doesn't respect the DISPLAY env variable for some mysterious reason, when I have some free time I'll see if I'm getting the same. EDIT: Ah yes, have to wait for Plasma 5.18 and/or Neon 20.04 to test that, works fine on Neon 18.04/Plasma 5.17.5.

I didn't play with it to see if was not respecting it or otherwise... since it comes up on the desktop you probably are right its not looking at it or ignoring it... which tells me volumes... of why I have to fight to restore XDMCP support etc...

I am an "aptitude" guy (replaced synaptic for me a few years back), I don't use any GUI installers at all (or have any installed), just apt and aptitude (when I need to do more complex package management or browse packages).

I go back and forth between synaptic and apt.. just depends on which I type first...

I also don't shy away from compiling stuff if I need to.

I don't have an issue with compiling IF IF YOU DEVELOPERS FOLLOW THE RULES. 9/10 they do not.

What rules... COMPLETE RECIPES on what is needed to compile their software!

Don't give the trite ./configure make sudo make install line..

Your README.TXT should include

sudo apt-get install libsuperduper-dev livsuperduper, etc. right on down the line to all dependencies...

Don't expect me to decode 1000 lines of make errors to figure out libs/dependencies needed.

But there are also valid use cases for contained package formats, they don't need to go away (except snaps, of course ), but should always be just options, not forced. I also think Discover is fine for new users, or users who don't like to work with cli (although I think everyone should ).

I have ONE program which comes as appimage thingy... Etcher.. which I am fine with that... I can live with it.. as it doesn't spew 50 loop or what ever things all over the place etc..

DEB is an OUTSTANDING package management system.. compared to RPM (spit! pffft! spit! blech!) I don't know that rates right up there with some other garbage.. snaps, systemurd, pulseaudio...2 of those have bled their cancer into distros... and I am not going willingly with the first.. I fought the other 2 and lost those battles. ALSA is a great thing and can do a lot.. unfortunately you have to have written it or being able to figure out its black magic to get it to do all that it can like plugins, loopback..

I have no intention of giving into the loss of DEB!

These things are appealing to new users in line with the application "stores" on certain phones... meh.. not the path to take in my view... I think DEB via synaptic can offer all that is needed... Just new users are not willing to get into learning the steps... Like the sounds setup.. I don't mind digging through some menus.. but geez people.. that stuff is not very intuitive to me where its at now... its a least 2 layers too deep.

[kubicle]

I don't have an issue with compiling IF IF YOU DEVELOPERS FOLLOW THE RULES. 9/10 they do not.
What rules... COMPLETE RECIPES on what is needed to compile their software!
Don't give the trite ./configure make sudo make install line..
Your README.TXT should include
sudo apt-get install libsuperduper-dev livsuperduper, etc. right on down the line to all dependencies...

That isn't actually a rule. And is quite a bit more labor intensive than it sounds, as all distro families package things (and the development headers/libraries) differently. Of course, some developers might provide detailed dependency instructions (usually for the distro family they are running themselves, as the list is easy enough to put together), but it is a bit out there to demand a developer that runs arch or redhat (for example) to provide complete instructions for a debian based distro (or any distro X that you happen to run) and constantly monitor all packaging changes in every distro in existence, forever, to keep all the detailed instructions up to date.

Building stuff takes some extra work, that's why we have distributions and binary packages. If you build stuff that is available in the repos, there are apt commands to get the build dependencies quite easily (https://www.guyrutenberg.com/2017/09...get-build-dep/ and https://askubuntu.com/questions/2137...s-of-a-package). Unfortunately that only works for sources in the repos (which you usually don't need to compile, but it can help if you're compiling a newer version that is available in the repos).

Don't expect me to decode 1000 lines of make errors to figure out libs/dependencies needed.

"I'd rather they did the work than I" is a valid point of view, but it is just as valid from the perspective of the developer.

---
This is actually one of the problems contained package delivery offers one solution to. A developer can make an appimage (or flatpak) available for the freshest version of their software (which should work as is in any distro), and distributions can package things in their own package formats/repos based on their own update/release schedule. Best of both worlds, kind of. One can install binary packages from the repos (or build them if they so choose), and if you really need a version that is newer or software that hasn't been packaged yet by your distribution, you can get a contained package without much hassle (that is often associated with building from source).

[rec9140]

That is... source).

I think at this point. its pretty clear we don't agree on 99% of things.

While I see you perspective and point. No. if I am the developer I KNOW WHAT libs were needed to create my superduper software...

Telling some one to

download source
untar
cd to dir
./configure, make, sudo make install

and the they get 1000's of lines of errors because this lib, that lib, some other lib, even more lib is not there...

Thats my job as a user to figure out this Really ? Thats a USER PROBLEM? Thats rich.. really rich... and thats my public snowflake version.

Thats just pointless... the DEVELOPER KNEW THIS TO START. Advise the users.. You developed this you KNOW/KNEW you installed libsuper-dev and libsuper on your distro.. That is not that hard to cross between Debian/Ubuntu land and lesser package systems like RPM etc..

And the work you are saying this is for developer.. well thats part of developing software.

I don't see this as being a leg for snaps etc. to be the route forward over DEB...

There is no point in going further this is way off Focal development...and as I started off with ... we are not in agreement and never will be. And this site is not welcoming to vociferous discussions any way.

[kubicle]

if I am the developer I KNOW WHAT libs were needed to create my superduper software...
You developed this you KNOW/KNEW you installed libsuper-dev and libsuper on your distro.. That is not that hard to cross between Debian/Ubuntu land and lesser package systems like RPM etc..

Umm...no. While you can put a list of needed headers (and the list of packages needed to build for your own distro is relatively easy to get), the packaging (and package names) are not standardized between different distros, so while the needed headers might come in package 'libsuperduper-dev" in one distro, it might come in "superxthreadheaders-2.7" in another and "somethingcompletelydiffent" in yet another, finding out these for every imaginable distro out there is rather tedious (as you commonly do not have all of them installed). The information is much easier to get if you are actually running the distro in question (like when you are building it yourself, the build process will tell you what headers/libraries you need, and you can commonly get the packages these come in with your distro tools).

There is no reason for agitation, I apologize if I come across as confrontational (not my intention), I'm just telling you how things are. You don't have to agree, I'm fine with that. And you are of course just as free to voice your opinions, but developers don't owe you anything (or have to do any of the work for you, even if you think they should, unless you are paying them to do it)...you don't want to put an effort into building stuff, use the binary packages provided by your distro.

Also, software sources aren't normally directed at regular users (users that build from source are a very small minority), but at other developers and software distributors (who usually know very well what is needed in their distro). All extra time spent on doing things that will only offer any real benefits to very few, is always time away from doing things that will benefit basically everyone, like improving features, fixing bugs etc. Telling them what you think they should do does not magically increase the resources they have available for development.

[Snowhog]

And this site is not welcoming to vociferous discussions any way.

vo·cif·er·ous

/vōˈsifərəs/

adjective
(especially of a person or speech) vehement or clamorous.
"he was a vociferous opponent of the takeover"

expressing feelings or opinions in a very loud or forceful way

We do prefer that when expressing views and opinions we aren't 'loud or forceful'. We do welcome discussions. We are tolerant of others points of view. What we find problematic is providing qualified answers to questions and then being told the answer isn't satisfactory or to ones liking. "You can please all of the people some of the time, or some of the people all of the time, but you can't please all of the people all of the time." If that isn't a core tenant of programming, it should be.

[WWDERW]

"You can please all of the people some of the time, or some of the people all of the time, but you can't please all of the people all of the time."

Maverick had a little different approach to that.

"You can fool all of the people some of the time, some of the people all the time and those are pretty good odds." - Shady Deal at Sunny Acres

I can definitely see both sides to this (and I have developed software as well, although some people would probably call it lazy developing as it is with the Electron framework and not plain jane C++ or similar). And there is for sure a difference in the naming schema of packages between distros (one package that I get for mapping my drives on ubuntu its "x"-common and on say Arch it's "x"-utils.

As to using distro repos if don't want to build from source, some software is only available with building (unless they have say github setup to compile everything and have it under releases section of the repo), no other option. No PPAs, no AURs, nothing. That will take out the "normies", if it is only available via building from source. That could also take out a pool of users that could help with bringing in bug reports and/or feature requests as well.

It's not quite as black and white as lot of people would like to think.

All extra time spent on doing things that will only offer any real benefits to very few, is always time away from doing things that will benefit basically everyone, like improving features, fixing bugs etc.

Even github can be setup for automatic building and releasing various methods of distributing (deb, rpm, appimage etc) that a particular project may need without much continued effort for the dev (there would be some as the project changes and the setup needs to be changed accordingly and the initial outlay of effort, but in between it's fairly stable and automatic). The benefit to all that may use this particular software is that they don't individually have to go through the building process themselves and just download what they need/want and test that out. Builds that are generated from pull requests would be targeted to devs and latest releases would be targeted to those that need more production ready builds. It drastically improves efficiency for all and it overall improves the software as it allows more people to participate in it's testing, bug reporting and/or feature requests.

Now, for the devs that just release a project in the hopes that it helps others, but it was mainly done due to a need that the devs themselves had and that's it, it won't matter one way or the other I would imagine. And that's fine. It is what it is. It all depends on what the end goals are for the project. Those projects that fit into this later category are probably not going to be ones that are going to see a wide adoption as it is. And that's fine, I'm not trying to say that it isn't.