Space isn't too much of an issue on cdn.kde.org:

Filesystem                Size  Used Avail Use% Mounted on
/dev/md1                  1.9T  1.2T  631G  65% /
none                      492K  4.0K  488K   1% /dev
/dev/mapper/vg0-archives  4.9T  1.6T  3.4T  32% /srv

We just have to ensure that they are expired in a reasonably efficient manner (and with some kind of sensible naming convention that is scalable). Discussing how to implement all of this is probably best done elsewhere though rather than here.

No code commits on Kube in 6 months. Is anyone still working on it? https://invent.kde.org/pim/kube/-/branches

Moved to GitLab issue https://invent.kde.org/teams/flathub/issues/-/issues/23 as it's more visible than an old Phabricator issue.

This is all handled in Gitlab with CI job logs displayed easily for Flatpak builds. Flathub has it's own build page where you can see build status as well. As for AppImages they're not centralised anywhere so no real infrastructure to speak of. Snaps I'm not certain of, perhaps @scarlettmoore can weigh in there.

This is all now handled on Gitlab so closing.

Snap has been created but is out of date @scarlettmoore
Flatpak is on Flathub and up to date
AppImage doesn't really have a centralised place to store them, and thus distribute them from.
If we want a central AppImage repo for KDE apps it could be hosted on cdn.kde.org but as they can be quite large due to bundling many libraries I'm not sure what the space requirements would be for them or how much space we have @bcooksley

Makes sense to me too, but I've seen many projects that have taken ownership of the flatpak recipe to let it degrade over time. We need ways to make sure it doesn't happen.

Flathub builds a Skrooge flatpak from its own spec at https://github.com/flathub/org.kde.skrooge/blob/master/org.kde.skrooge.json , and kdeapps checks Skrooge's git master every day for changes and builds using https://invent.kde.org/office/skrooge/-/blob/master/org.kde.skrooge.json .

thanks! this is the first commit that I actually got around to setting arc up properly and landing myself. so thanks!

Thanks.

+1 good stuff!

The Skrooge Binary Factory jobs have now been regenerated and will use the new configuration going forward.

Commited

I'm going to close this since the qt 5.10 branch of the flatpak sdk is now "unmaintained".

Works for tarballs, good enough.

Not needed anymore

Sure

Let's leave this branch die with Qt 5.11. Users should be moving away from it anyway.

Thanks!

5.12 is enough for *me*.

It's qt5.10 branch

Same as 5.9, works for me if you really need it, but I wouldn't be putting new things there.

For which branch is this?

Right, for master and stable (currently "3.2").

Just to be sure, you want to have it built both for master and specific branches?

@apol Thanks, adding another nightly for other branch was my initial though. Can we add this? We would be done then.

And doesn't the nightlies we have now already tackle this?
https://phabricator.kde.org/source/flatpak-kde-applications/browse/master/org.kde.kexi.json

Yes, Ben summarized what I meant. Thanks. We're not yet there (that is, production-ready flatpack or app store of any kind, with QA and regular contributors). We can't have all of this the day one, we need nighties so would-be contributors who are not developers have the chances to test current software (stable/unstable). Current state is that many contributors (power users) run 1 or 2 years old software so even initial conversation within bugs.kde.org is problematic.

With regards to the Windows Store - the work by myself and Hannah only extends to publishing on the Binary Factory. Validation of a working application, and then publishing as part of a release (on download.kde.org and the Windows Store) would still be up to a maintainer as part of their release work.

In T10377#174777, @apol wrote:

In T10377#174613, @staniek wrote:

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?

I'd say it's not very practical. But we could do it if necessary.

Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

I'd say going all the way on Windows stable releases would mean to get the application on the Windows Store. It should be the maintainer who does that.

With regards to Windows, we do have both unstable nightly builds (which the Binary Factory produces for many projects) along with stable builds (which the Binary Factory also produces).

In T10377#174613, @staniek wrote:

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?
Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

I'm not planning to offer stable releases of KDE software at the moment. I'd like our software maintainers to take responsibility for the binaries we produce. Flathub seems to be reasonably good infrastructure for that so I suggest using it as users already have the remote installed in their systems.

Reassigning this to the Flatpak project, as there is nothing for Sysadmin to do here.

Could this be the problem?

Aleix, the app I built is a my custom app which absent in any repo.
I tried to push it to my local repo(tutorial-repo) but Discover doesn't see anything there, see the scrinshot.

you don't have to install app data for flatpak. it's downloaded automatically.

@apol @bshah

You probably want to keep x11 and wayland.

• rebase

• Rebase

• Apol's Suggestions
• Add Cleanups

In D13604#280010, @laysrodrigues wrote:

I think that for this we should wait to move Atelier from Playground to Extragear.

I think that for this we should wait to move Atelier from Playground to Extragear.

sorry path its looking before is inside the flatpak

In D11276#224660, @rizzitello wrote:

they are installed to app/lib64/plugins/AtCore. without setting the qt_plugin_install_dir at run time the flatpak looks in /usr/lib/qt/plugins (my real system dir). This overides that path.

they are installed to app/lib64/plugins/AtCore. without setting the qt_plugin_install_dir at run time the flatpak looks in /usr/lib/qt/plugins (my real system dir). This overides that path.

• remove the filesystem option
• set qt plugin path

Oh, one thing: we now have a new dependency, on libgif.

Pushed

Coincidence, was just checking myself as well!
Can't find it, please push and I'll update flatpak-kde-applications so that we build the nightlies with this recipe.

Did this already land, or should I commit it?