In T12400#214555, @ngraham wrote:

Perhaps the solution here is for the Release Service to take care of the Snap and Flatpak packaging to ensure 100% coverage of our apps on both the Snap Store as well as Flathub so they're first-class citizens. Because right now, if I want to replace all my distro-packaged KDE apps with Snap or Flatpak versions, I cannot. The Snap store is missing Dolphin, Discover, Elisa, Filelight, Kamoso, KInfoCenter, Konsole, KSysGuard, and System Settings, and the ones that are there are out of date (there's no 19.12 release, and some are even older). Meanwhile, Flathub is missing Discover, Gwenview, Filelight, Kamoso, Kate, KInfoCenter, Konsole, KSysGuard, Skanlite, Spectacle, and System Settings. And many of the KDE apps on Flathub show the old Oxygen icon instead of the current Breeze icon.

In T12400#214569, @cblack wrote:

A lot of these points are targeted only for third party applications to a given platform— apps like system settings and file managers and task managers are intended to be distributed as part of the desktop they're designed to be used in. Case in point: all current atomic distros distribute system settings and file managers and task managers and the like with the same mechanism as they distribute the desktop. File managers and terminals and task managers could probably be handled with more APIs for apps like these in the future, but system settings should always be part of the desktop they're for.

In T12400#214568, @ngraham wrote:

No, one point is sandboxing. Another is decoupling apps' release to users from the distro's own packaging release cycle. Another is providing a single packaging format for developers to target. Another is allowing developers to specify and depend on consistent library versions rather than needing to support whatever random version is in 500 distros. And so on. If these apps in question got on Flathub or the Snap store with no sandboxing whatsoever, it would still be a win over traditional distro packaging.

No, one point is sandboxing. Another is decoupling apps' release to users from the distro's own packaging release cycle. Another is providing a single packaging format for developers to target. Another is allowing developers to specify and depend on consistent library versions rather than needing to support whatever random version is in 500 distros. And so on. If these apps in question got on Flathub or the Snap store with no sandboxing whatsoever, it would still be a win over traditional distro packaging.

In T12400#214566, @ngraham wrote:

In T12400#214565, @cblack wrote:

A lot of these apps require more probing into the system than Flatpak allows, like Filelight, KInfoCenter, Konsole, KSysGuard, and SySe5. Apps like these are better off being shipped as native applications rather add-ons.

That would seem to defeat the entire point of these packaging formats. If they can't handle any kind of app, why bother?

In T12400#214565, @cblack wrote:

A lot of these apps require more probing into the system than Flatpak allows, like Filelight, KInfoCenter, Konsole, KSysGuard, and SySe5. Apps like these are better off being shipped as native applications rather add-ons.

In T12400#214555, @ngraham wrote:

Meanwhile, Flathub is missing Discover, Gwenview, Filelight, Kamoso, Kate, KInfoCenter, Konsole, KSysGuard, Skanlite, Spectacle, and System Settings. And many of the KDE apps on Flathub show the old Oxygen icon instead of the current Breeze icon.

In T12400#214512, @sitter wrote:

We ship with both enabled. And have been for like a year!

In T12400#214443, @ngraham wrote:

I think it would be nice if we shipped Neon with Flathub out of the box rather than the Snap Store

If anything, KDE Neon (and any distro, IMHO) should embrace these formats. It's not about rejecting them. We need both Discover plugins installed by default and with latest stable releases for its support libraries for both, which is a problem as is: snapdglib-qt, libflatpak and I'd say libappstream-qt as well.

Yeah, regardless of whether Snap or Flatpak winds up the winner, I think it makes sense, as @cblack and @The-Feren-OS-Dev, suggest, to embrace the future and ship app user-facing apps using a containerized format. It feels like there's an emerging consensus that the future of packaging is an immutable base OS with containerized userland software installed on top. Personally I think this makes a lot of sense and solves one of the biggest problems I've always had with Linux distros--the fact that there generally wasn't an option to use a rolling release model for apps and the graphical shell (which you want to be up-to-date) but a stable/discrete release model for the base OS and its supporting software libraries. ...Otherwise known as "the way everyone else does it outside the FOSS world."

While I haven't been in the loop much regarding the advantages and disadvantages of both packaging systems, I do know making use of Flatpak or Snaps is a good idea on the terms that we can nail the desktop integration between applications and the overall Plasma and KDE experience first time.

Personally I've grown rather fond of Flatpak for the reasons mentioned in the task description (as well as a few others). It feels like there is a real community growing up around Flatpak whereas Snap is continuing to be a Canonical-only thing. I think it would be nice if we shipped Neon with Flathub out of the box rather than the Snap Store, and if we put more resources into packaging our apps on Flathub. Quite a few are there already, but I think we need more. And unlike the Snap store, getting more of our apps on Flathub benefits users in more distros because Flatpak is more widely distributed than Snap at this point.

I agree with a lot of the points raised about this. Personally, I think the traditional packaging model is going to fade from prominence sooner rather than later, and KDE Neon should take steps to be ready when distros start packing up and using new and unique packaging formats.

is this not a Gnome built-in capability ?

Anyway this is up now; shall we close the Phab task?

In T12257#212511, @IlyaBizyaev wrote:

Regarding the suggestion to use ROSA image writer, this may be my American perspective creeping in, but the .ru domain name of the download links might scare off some people. Sucks, but it is what it is. I wonder if Etcher (https://www.balena.io/etcher/) might be a more neutral recommendation.

This tool has been recommended for Neon for ages, and I didn't see any pushback.

In T12257#212583, @rikmills wrote:

In T12257#212558, @ognarb wrote:

For my sanity, I won't make this change very public other than in the community mailing list.

Already on kde reddit!

In T12257#212558, @ognarb wrote:

For my sanity, I won't make this change very public other than in the community mailing list.

I update the text for Neon. Sorry I missed it

@jriddell I added the Made by KDE brand for neon

@skadinna @ngraham Thanks for suggestions. I updated the webpage.

"Kubuntu is the Ubuntu version with KDE software by default." version -> flavour (or flavor)

This is great, Carl! Thank you so much for your work 👍 🙏

Jonathan said our writer isn't ready for this sort of spotlight IIRC. @jriddell input?

Regarding the suggestion to use ROSA image writer, this may be my American perspective creeping in, but the .ru domain name of the download links might scare off some people. Sucks, but it is what it is. I wonder if Etcher (https://www.balena.io/etcher/) might be a more neutral recommendation.

Looks amazing.

I polished a bit https://kde.carlschwan.eu/distributions.

The arm setup actually disappeared since (possibly wasn't carried into new server) so there are no up to date metrics. It does not really matter though since we do not have a way to pull this off for amd64. We'd require a persistent storage for the cache as nodes are largely ephemeral so result need "offsite" storage. This would be tricky to do since we currently have no space for this and the actual transfer overhead would like destroy any gains made by the cache. Plus there is of course the risk of false positives anyway. All in all no longer viable to implement.

Calamares needs to be run as root, unfortunately (so that it can mangle disks and write essentially arbitrary files in the target filesystem). That is usually done through pkexec or sudo. In both cases, you need to take care to preserve enough of the environment that Calamares can find the theming. I'm not sure if pkexec -E is sufficient. In any case, by pointing enough XDG things to the home directory of the live user, rather than root, you can improve theming without doing any work on / in Calamares itself. Not resetting $HOME might be enough.

I think one of the goal of Calamares was to be distribution independent and DE independent (the universal installer). So I don't think using KDE design decision is a good idea, but making Calamares more themable would be cool ;)

Yeah, this is just a matter of styling. @adridg might be able to help with this.

Considering that most Calamares devs are KDE devs (https://calamares.io/about/), it might make sense to see if they're interested in having the default look of Calamares changed. Even if they aren't, Calamares supports custom styling, so there's no need to make a fork of the installer.
https://github.com/calamares/calamares/blob/master/src/branding/README.md
https://github.com/calamares/calamares/wiki/Deploy-Guide#styling-calamares
https://github.com/calamares/calamares/wiki/Deploy-Configuration#how-to-integrate-calamares-with-the-used-system-style-and-theme

Not sure if that sort of application really needs to have regular commits ;)

seems not to have had a commit in 14 months

This got implemented and released: https://fbgsoc.home.blog/2019/08/22/kde-iso-image-writer-release-announcement/

yes

Is this done then from our side?

looks good

published at 1 location now with symlink from the old ones

Excitingly enough apt rdepends doesn't actually manage to generate a list for the virtual package qtbase-abi-5-9-5 so we need custom tooling to even get a list of offending packages -.-

I e-mailed kdeedu-i18n-doc

In point of fact, that's literally what the last build failure says

I think the only thing blocking this is the not set branch. what you describe are l10n data assets, those have literally no requirements other than knowing where to get them from (i.e. a branch)

seems good but needs to update to newer qt for the qt bits and to get into debian

let's ignore it then

This in fact only became active recently.

Current issue seem to be that digikam.mo translation doesn't get picked up by our stuff. Investigate why.

Also apply to 18.04. Needs investigation on how to actually pull in the upgrade. Possibly -desktop should recommend the HWE packages, but this may not be enough. So, check what is the least invasive but reliably upgrading approach here.

OMG they are finally all green.
https://build.neon.kde.org/job/bionic_unstable_extras_calligra/
https://build.neon.kde.org/job/bionic_stable_extras_calligra/
https://build.neon.kde.org/job/bionic_release_extras_calligra/
https://build.neon.kde.org/job/bionic_release-lts_extras_calligra/

At akademy 2019 we decided to just switch to HWE in future for all users

done

all done

Look at all bugs see if they have impact on production and if not close this task

snap building apparently has troubles with it. needs investigation

also needs removal of phonon-backend-vlc (that is the qt4 thingy)

Thanks @sitter . I just got the 5.1.2 update in KDE Neon user updates today and it worked like a charm. Thanks again for all the amazing work. When the time comes we should do a post on /r/kde about it too!

Yep. It should be out this week, so we likely are good to promote torrents next week or the week after so distros had a chance to adopt it.

@sitter Thanks for the hard work. Does this mean we are waiting for the 5.1.2 release of KTorrent?

@kives spam.

@sitter Any idea what is going on here with this other user? I have no idea who he is or why he is upset.

[spam comment removed by sysadmin]