NeonOrganization
ActivePublic

Recent Activity

Fri, Jan 17

sitter triaged T12558: lintqml install without recommends as High priority.
Fri, Jan 17, 5:28 PM · Neon

Wed, Jan 15

sitter triaged T12545: revise lintqml as Low priority.
Wed, Jan 15, 4:23 PM · Neon
sitter closed T10513: HWE again! as Resolved.

Revisit for 20.04 I guess. Not much worth putting effort into this now.

Wed, Jan 15, 1:49 PM · Neon

Wed, Jan 8

jriddell closed T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future as Invalid.

If I understand "the Neon position" correctly here, Neon aims to be the base OS + Plasma desktop. The only reason it still bothers with packaging apps is because it has to because nobody is going to use an empty shell, and the Linux world isn't all app-ified yet.

Wed, Jan 8, 5:13 PM · Neon

Wed, Jan 1

ouwerkerk added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

If I understand "the Neon position" correctly here, Neon aims to be the base OS + Plasma desktop. The only reason it still bothers with packaging apps is because it has to because nobody is going to use an empty shell, and the Linux world isn't all app-ified yet.

Wed, Jan 1, 11:41 PM · Neon
ngraham added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

I think this started out as the idea that Neon (not KDE in general, but Neon in particular) should be more "opinionated" with regards to which next-gen packaging format it steers users towards. If that's a no-go, then I guess there's nothing to do here, and we should just focus on increasing the coverage for our apps on Snap and Flatpak (and AppImage too, I guess?).

Wed, Jan 1, 10:11 PM · Neon
ouwerkerk added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

As far as I am aware our flatpaks are purely packaging formats, and don't take advantage of any sandboxing features. So I don't see what there is to recommend our flatpak implementation over our snap implementation, say. But then again, that could be part of this: pushing the packaging forward.
On the other hand: has anybody asked the application developers about their opinion on this? After all, they will be expected to take on additional maintenance efforts to make sure their app continue to work well with the chosen packaging format and they might just have opinions on that.

Wed, Jan 1, 2:19 PM · Neon
jriddell added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

I'm not clear on the purpose of this task. KDE neon wants to support using every package format so our users can install and use software in any format it comes in.

Wed, Jan 1, 1:22 PM · Neon

Dec 21 2019

cblack added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

BTW The point seems moot for Dolphin since there's already a Flatpak version of it.

Dec 21 2019, 7:11 PM · Neon
ngraham added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

True, but that's a one-time thing for each app though, right? Once it's done, the release team mostly needs to take care of releasing it as new versions come out.

Dec 21 2019, 7:10 PM · Neon
davidre added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 21 2019, 7:07 PM · Neon
ngraham added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 21 2019, 7:04 PM · Neon
cblack added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 21 2019, 6:51 PM · Neon
ngraham added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 21 2019, 6:33 PM · Neon
cblack added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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?

Dec 21 2019, 6:27 PM · Neon
ngraham added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 21 2019, 6:26 PM · Neon
cblack added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 21 2019, 6:25 PM · Neon
ngraham updated subscribers of T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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

Dec 21 2019, 4:11 PM · Neon
sitter added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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

Dec 21 2019, 12:19 PM · Neon
apol added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 21 2019, 11:55 AM · Neon
ngraham added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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."

Dec 21 2019, 5:43 AM · Neon

Dec 20 2019

The-Feren-OS-Dev added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 20 2019, 10:55 PM · Neon
ngraham updated subscribers of T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.
Dec 20 2019, 10:53 PM · Neon
ngraham added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 20 2019, 10:51 PM · Neon
cblack added a comment to T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.

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.

Dec 20 2019, 10:51 PM · Neon
cblack updated the task description for T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.
Dec 20 2019, 10:48 PM · Neon
niccolove created T12400: Consider what position KDE Neon should take regarding Flatpak, Snaps, and packages future.
Dec 20 2019, 10:47 PM · Neon

Dec 18 2019

skadinna moved T12257: Webpage advertising Linux distributions with KDE Software from Incoming - All new tasks and ideas go here to Done on the KDE Promo board.
Dec 18 2019, 7:01 PM · Neon, Kubuntu, KDE Promo

Dec 16 2019

zachus added a comment to T3481: VNC test instances.

is this not a Gnome built-in capability ?

Dec 16 2019, 8:00 PM · Neon

Dec 11 2019

sitter updated the task description for T9376: calamares by default.
Dec 11 2019, 8:28 PM · Neon

Dec 4 2019

ognarb closed T12257: Webpage advertising Linux distributions with KDE Software as Resolved.
Dec 4 2019, 6:20 PM · Neon, Kubuntu, KDE Promo

Dec 3 2019

ngraham added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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

Dec 3 2019, 7:01 PM · Neon, Kubuntu, KDE Promo
ngraham added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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.

Dec 3 2019, 7:00 PM · Neon, Kubuntu, KDE Promo
ognarb added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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

Already on kde reddit!

Dec 3 2019, 3:30 PM · Neon, Kubuntu, KDE Promo
rikmills added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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

Dec 3 2019, 2:37 PM · Neon, Kubuntu, KDE Promo
ognarb added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

I update the text for Neon. Sorry I missed it

Dec 3 2019, 1:39 PM · Neon, Kubuntu, KDE Promo
jriddell added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

@jriddell I added the Made by KDE brand for neon

Dec 3 2019, 12:21 PM · Neon, Kubuntu, KDE Promo
ognarb added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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

Dec 3 2019, 12:15 PM · Neon, Kubuntu, KDE Promo
jriddell added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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

Dec 3 2019, 11:27 AM · Neon, Kubuntu, KDE Promo
skadinna added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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

Dec 3 2019, 11:11 AM · Neon, Kubuntu, KDE Promo
sitter updated subscribers of T12257: Webpage advertising Linux distributions with KDE Software.

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

Dec 3 2019, 10:36 AM · Neon, Kubuntu, KDE Promo
IlyaBizyaev added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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.

Dec 3 2019, 7:16 AM · Neon, Kubuntu, KDE Promo
ngraham added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

Looks amazing.

Dec 3 2019, 4:55 AM · Neon, Kubuntu, KDE Promo
ognarb added a comment to T12257: Webpage advertising Linux distributions with KDE Software.

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

Dec 3 2019, 12:49 AM · Neon, Kubuntu, KDE Promo

Nov 25 2019

ognarb created T12257: Webpage advertising Linux distributions with KDE Software.
Nov 25 2019, 4:36 PM · Neon, Kubuntu, KDE Promo

Nov 19 2019

sitter closed T5621: ccache as Wontfix.

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.

Nov 19 2019, 2:04 PM · Neon
sitter triaged T12072: move snaps to binary factory as Normal priority.
Nov 19 2019, 9:49 AM · Neon

Nov 6 2019

KonqiDragon updated the task description for T11979: KDE Welcome Screen.
Nov 6 2019, 12:58 AM · VDG
KonqiDragon updated the task description for T11979: KDE Welcome Screen.
Nov 6 2019, 12:57 AM · VDG

Nov 5 2019

KonqiDragon created T11979: KDE Welcome Screen.
Nov 5 2019, 10:28 PM · VDG