I don’t even know if this goes here, but it seems like the closest match. Arch packaged 6.0 in their extra repo (For non-arch users, it’s supposed to have stable and reliable software branches, not beta stuff like 6.0) and it’s not getting the attention it needs in the forums. Only one developer answer so far and the rest are regular users and, frankly, jackasses.
This isn’t me asking for a defense army or something, I just want this thing fixed so I can update my OS already instead of using the appimage, and to avoid other artists losing progress on their work like it already happened to one other user in the forum thread. If anyone here is using arch or a derivative, it’s a good moment to pipe in.
There’s also a bugtracker for arch packages, but I’m unable to access it as account creation is gated. If anyone here already has one it’d probably help a TON if they could create a thread for it.
If the arch maintainer does not care and completely disregards the Krita developers recommendation on the basis that the string beta is not part of the version number, than there is not much we can do about it, really.
I’m not going to touch the Arch forums, but to refute the claims in there: aside from putting it in the documentation, when building Krita 6, the build clearly warns the packager that they are building an unstable version.
Building Krita with Qt6 is not yet production-ready. Please don’t package this and ship it as a stable version of the software. If you want to continue regardless, pass:
-DALLOW_UNSTABLE=QT6
And unlike the forum posts claiming it, this isn’t some kind of automated bot’s doing, an automated process would have just bumped Krita’s version and built the stable release. The packager decided to enable the Qt6 build and then overrode the safeguard telling them that it’s a mistake manually. To fix it, they just need to not build it against Qt6, that way they get the stable version without even having to change their sources.
It seems like the packager in questions is responsible for a lot of packages, so they may simply not have read the message too closely. For the same reason, they probably also don’t follow the announcements too closely. So I’d assume it was just a hasty mistake under the assumption that Qt6 will work fine like it does for other applications they’ve switched over. We’d hoped it would be more stable as well, but turns out there’s still a lot of crashing bugs and undocumented incompatibilities to work around or patch in the framework itself.
Sorry, this is somewhat off-topic, but it’s related to the apparent refusal of the responsible Arch maintainer to follow the build instructions:
Arch is fighting tooth and nail to remain the distribution from which we receive the highest percentage of Linux bug reports here for well over three years now.
The joke so far is, and hopefully remains to be, the maintainers of Arch based distros, interestingly, seem to be able to read carefully, because most of them had working Krita builds in the same period!
But hey, at least Arch can always claim they have the highest build numbers in their repo, which seems to be their main goal (our distros edge bleeds the most ). That these not necessarily have to work is another story - and they don’t care about it.
But anyone who uses Arch to work productively - or even to make a living - is beyond help anyway. I suppose you could call that actively refusing to acknowledge reality - or self-destructive behavior.
For productivity, make your living, you better use SUSE Linux Enterprise Desktop or the desktop version of RHEL.
I’ve been reading and following all the comments about this subject, and as it is said above, it’s a good example of the Arch philosophy about getting all the last updates, no matter what’s happening once it’s installed. It’s interesting here, because a bit controversial.
But it’s also a shame, because (for example on Cachy os) you can’t “sudo downgrade krita” to version 5.3, because there’s no 5.3 in the Arch repo, so you can’t benefit all the upgrades made. Your os package would remains the 6.0, or downgraded to the 5.2, no other choices.
The workaround I think for the moment, is to use the official appimage 5.3 (or 5.3.1), and always launch Krita with it. You can still keep the 6.0 as a system package, keep on updating it, maybe re-try it sometimes to check evolutions. Appimage and system packages are sharing the same settings folders, so when opening the appimage for the first time, everything should be in place already.
Yes, in principle it is the same issue from back then as Krita 5 included G’MIC into the build (and later with 5.2.0 and FFmpeg too), and tons of distros, Arch running in front of the pack, did miss paying attention and therefore not included it, because: “It never was in, why should we include it now?”, and a flood of users came to us with the mess created by people who can obviously no longer read longer texts these days, at least not a text as long as the Krita build instructions, or this one (because it exceeds the 169 character SMS limit … ).
And we had the same discussions: “I want to have this (or that), because …”, or best of all: “The AppImage is not secure!”. Let’s see what the next weeks will bring us as “extra fun”.
Well yes it’s very well known appimages are somehow magically more insecure than downloading a tarball with binaries despite being the exact same thing. Especially when the repo maintainers forced you to download tarballs or appimages because they made it clear their software repo being usable, safe, or secure is not a priority in any shape or form.
Although somewhat off-topic, when using any distribution, the system and software should be kept separate to avoid dependency issues. This also helps prevent problems with software that hasn’t been compiled and packaged according to the developer’s instructions.
For using the latest software on Linux distributions, versions packaged by the original developers are recommended: AppImage (e.g., Krita), Flatpak (e.g., OBS), or extract-and-run compressed packages (e.g., Blender). Unless there is no other option, using the Linux distribution’s repositories is not recommended.
).