This adds a flatpak build manifest (for version 4.0) and instructions how to use it to create a bundle that can be distributed to users/testers. It's not meant to replace the stable builds on flathub.org, but to test development builds.
Diff Detail
Diff Detail
- Repository
- R37 Krita
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
By the way: The resulting bundle includes python scripting support and should contain support for audio in animations (I had no idea how to test that).
Comment Actions
And in case you are not familiar with the current state of flatpak: when the user has a recent version of Plasma Discover or GNOME Software installed, it's of course enough to click the the bundle to install it.
| packaging/linux/flatpak/org.kde.krita-dev.json | ||
|---|---|---|
| 369 ↗ | (On Diff #25356) | Why not just use git master? |
| packaging/linux/flatpak/org.kde.krita-dev.json | ||
|---|---|---|
| 369 ↗ | (On Diff #25356) | How about adding a extra org.kde.krita-nightly.json like GIMP does: |
Comment Actions
Would you consider adding <release> information to your AppStream metadata file here, so you don't need to patch it in on Flathub?
Also, while we're at it, how about fixing the upstream AppStream ID? You've currently got it set to org.kde.krita.desktop; it should be org.kde.krita. Having the AppStream IDs match between sources has substantial benefits: https://pointieststick.wordpress.com/2018/01/14/how-you-can-help-drive-flatpak-adoption/
Relevant section of the AppStream Spec for IDs:
<id/>
The <id> tag is a unique identifier for this component. It must contain only ASCII characters, dots, hyphens and numbers. Spaces are not allowed. The ID must follow a reverse-DNS scheme, consisting of {tld}.{vendor}.{product}, for example org.kde.Gwenview or com.hugski.ColorHug2. Ownership of {vendor}.{tld} in the domain name system guarantees uniqueness of IDs.
To accommodate a desktop file with a different name, you would add <launchable type="desktop-id">org.kde.krita.desktop</launchable>
Comment Actions
It's already there on master and will be dropped when 4.0 is released.
Also, while we're at it, how about fixing the upstream AppStream ID?
Take a look at the other appdata.xml files on flathub - they all add the .desktop suffix.
Comment Actions
I have no opinion in the appstream file question, but I'm fine with having these definitions in our repo, on the same basis as the snap definitions: I cannot maintain them.
| packaging/linux/flatpak/org.kde.krita-dev.json | ||
|---|---|---|
| 215 ↗ | (On Diff #25356) | Krita doesn't need openjpeg anymore. |
| packaging/linux/flatpak/org.kde.krita-dev.json | ||
|---|---|---|
| 369 ↗ | (On Diff #25356) | If you prefer, sure. When you do I'll make the binaries built by kde nightlies use this instead of the manifest in flatpak-kde-applications. |
Comment Actions
I could certainly maintain the flatpak manifest, I just thought you could use it when you make alpha/beta/RC releases to provide a bundle for Linux that includes everything (python etc.). Something you seem to struggle with when using AppImage, see https://phabricator.kde.org/T7679
If you don't want to use it, I would rename it to "org.kde.krita-nightly.json", so it will only be used for kde nightly builds.
| packaging/linux/flatpak/org.kde.krita-dev.json | ||
|---|---|---|
| 215 ↗ | (On Diff #25356) | How does it support jpeg2000 now? This applies only to 4.0, not 3.3 right? |
| packaging/linux/flatpak/org.kde.krita-dev.json | ||
|---|---|---|
| 215 ↗ | (On Diff #25356) | It doesn't. We removed jpeg2000 support because 1. Nobody used it, and 2. Most people selected it and then were upset the resulting files couldn't be read by any other program and blamed Krita for being broken. It seemed more sensible to just remove support. |
Comment Actions
When the KDE nightly build is switched to this manifest, it would be good, if a hint was added to krita's download page, with a link to the repo file:
https://distribute.kde.org/kdeapps.flatpakrepo
(see https://community.kde.org/Guidelines_and_HOWTOs/Flatpak)
Comment Actions
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.