- the flakpak is not an official package, unless somethig changed this release
- the comment about it being “against policy” is from some random person, you all have taken that comment and run with it.
- the version update bumps by bot for the flaktpak, all one needs to do is click merge. Adding new features is extra work.
- @hub doesn’t seem super hyped about AI, given what I’ve seen on mastodon
- nothing stopping anyone else from submitting a PR to enable it. flakpack is also easy to build locally.
1 Like
I recommend maybe just waiting a bit for what @hub will say about this before we jump to conclusions and get the pitchforks out 
.
This is in terms that development does not create it. The only official items are source code and the AppImage. I agree on that. But also install | darktable lists it as a variation in terms of packages. Personally - I would not have expected some features to be out.
I can see a valid point.
My perception is that there is no safe approach with it. I am sorry - I am very much behind on social. Are you pointing to something like this?
I guess this is a good approach.
Sure, under the header “Community maintained packages for Linux/Unix” which is the same as OBS.
I only meant this as to say “this is why updates come pretty quickly”
I meant this to mean “if I had to make a guess, he is probably not enthusiastic about spending time to enable this” and also why I suggested a PR from someone else.
Sorry for the lack of clarity
1 Like
Your assumption is wrong. The AI features of dt are optional. GitHub - darktable-org/darktable: darktable is an open source photography workflow application and raw developer · GitHub
- first you need to compile with an opt in flag that enables the AI features.
- then turn it on
- and you need to download the models you are comfortable with.
This was the approach to appease the anti-ai folks. It was not enough.
All of the packagers for distro, OSB, flatpaks, etc need to add the flag in the setup to enable ai features at compile. It is a detail they may not know about.
I see the point that you are making and thank you for the clarification!
It is a bit of unexpected approach. But I can see some reasons behind it. At the same time if the approach is overused - it has the potential to affect the experience of users in a wrong way.
I guess the question is kind of
- AI is omitted from the package because of change in the build that should be done or
- AI is omitted intentionally because of a personal view or conviction.
I doubt it all users will completely agree on “for or against AI”. I find it - the approach in the preference alone is sufficient. Disabled by default but user can enable it (the choice is in the hands of the users)
If the choice is predetermined - then the user would not have a choice (nothing to do with good, bad, right or wrong choice).
Thanks again for clarifying and pointing to important details!
This is a common approach in Linux land, at least, especially for applications with a lot of dependencies.
Thank you - time for me to learn. I was not aware of that.
I just pushed a PR to flakpak to enable the AI features. It made me think that the models will also need to be accessible in the flatpak environment.
3 Likes
Has anyone used the app Gear Lever (ironically a flatpak) to manage appimages? It helps with creating a desktop icon for appimages and keeping them up to date.
2 Likes
I have also just received the OBS version for Fedora of 5.6 and disappointedly noticed that it was built without the AI functionality.
It is of course the responsibility of every packager to design his work according to his ideas, but I was already very sad, because I have used this variant for many years and now have to switch to the Appimage.
Too bad that the packages are so inconsistent and the personal preferences for AI have apparently gained the upper hand.
It is just like this.
What will be the next point, which a packager isn’t fine with?
You guys are getting a bit dramatic. As @paperdigits said: An omission of a new compile flag is not necessarily a conscious decision. Raise an issue with the packager and see where it goes. For the time being there is always the AppImage.
1 Like
Exactly. It’s not even an official package. Even if the maintainer doesn’t want it, just fork and release a new darktable flatpak package called darktable-ai or something, which brings in all those dependencies.
No, it shouldn’t sound dramatic. I left a request for AI on the comments page of OBS at the graphics/darktable package (lack of a different idea where I should place like this).
The Appimage is of course an option, but for me it causes some difficulties that I would have to explore again (Textwidgets are not readable → Cinnamon under Xorg and some own LUA scripts are no longer running.) Everything is probably not insoluble, but needs research effort again.
The OBS package for Fedara was my all-round carefree package for years. Well, wait and see, there is also the option of the native Fedora package when that is finished.
1 Like
The PR build action couldn’t reach ONNX:
Yeah I notcied. I think the OSB packager had the same issue. I will need to see how other resolve this. I don’t use flatpaks, so I was just trying to help.
I think your assumption is incorrect. The OSB packager tried to enable the ai features but it fails to build due to onnx. Looks like he disabled the AI just for folks to be able to use 5.6.
1 Like
I wonder if this is why distros haven’t built 5.6 yet? Distros like Fedora, Opensuse, and Arch are usually fast on the updates.
At the moment, apparently, the automated builds are failing for a simple patch.
https://koji.fedoraproject.org/koji/taskinfo?taskID=146895924
But I think that the maintainer hasn’t just worked on it yet.
1 Like