After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795757 - Flatpak install: RAW files do not load / rawtherapee nor darktable are detected
Flatpak install: RAW files do not load / rawtherapee nor darktable are detected
Status: RESOLVED DUPLICATE of bug 791362
Product: GIMP
Classification: Other
Component: Plugins
2.10.0
Other Linux
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2018-05-02 16:06 UTC by mifi
Modified: 2018-05-03 23:47 UTC
See Also:
GNOME target: ---
GNOME version: 3.25/3.26


Attachments
RAW import: darktable nor rawtherapee found (48.97 KB, image/jpeg)
2018-05-02 16:06 UTC, mifi
Details

Description mifi 2018-05-02 16:06:45 UTC
Created attachment 371618 [details]
RAW import: darktable nor rawtherapee found

System: Ubuntu 18.04
Gimp: 2.10 installed as the preferred flatpak from flathub.org
Rawtherapee: 5.3.1 from standard apt repositories
Darktable: 2.4.3 as a flatpak from flathub.org

I installed gimp 2.10 with flatpak and saw a similar problem as was reported in a windows environment in bug 790740. However, I am on Ubuntu 18.04 and only when gimp is installed via flatpak and I suspect the cause of the problem is different.

When loading a raw file (file/open and then select a raw file) the standard Tharpee/darktable error message is shown, while both ratherapee as well as darktable are installed.

I have installed RawTherapee 5.3.1 from the normal apt-repositories,
and darktable 2.4.3 is installed as a flatpak as well.

Edit>Preferences>Image Import does not allow me to update the RAW Image Importer Plugin entry.

I also tried Gimp installing from a ppa:otto-kesselgulasch/gimp and in that version it is working like expected.

This suggests to me that this problem has something to do with the flatpak way of installing things.

mifi
Comment 1 Jehan 2018-05-02 18:15:01 UTC
This other bug on Windows is different and completely unrelated.

The fact that this doesn't work on flatpak is known and somehow expected. A sandboxed GIMP cannot find another program in the system, and this is the normal way of things.

We were told that we could package darktable together with GIMP, but well… obviously we are not going to do such a thing (unless you want to end up with a package of hundreds of MB packaging the whole ecosystem of software!). :P

I have thought a bit about it, and have thought about a few solutions. One of these involve a dbus service, etc. But well that would take time, and darktable/RawTherapee would have to be onboard, etc.
So don't expect it to happen too soon.

In the end, I am hesitating to just close this report. It is not a bug per-se, just an expected limitation of sandbox security.
Comment 2 mifi 2018-05-03 07:22:36 UTC
Thanks for your reply Jehan.

(In reply to Jehan from comment #1)

> The fact that this doesn't work on flatpak is known and somehow expected. A
> sandboxed GIMP cannot find another program in the system, and this is the
> normal way of things.
> [...]
> In the end, I am hesitating to just close this report. It is not a bug
> per-se, just an expected limitation of sandbox security.

Yes, well, this, sort of, negates some useful functionality in gimp that I am accustomed to and use almost daily.
I am not a flatpak expert, but I think I had understood that fastpak does not need to be used like a strict sandbox, like containers, but it appears to do exactly that.

If true, this shows, in my opinion, that the flatpak way of doing things is not suitable for an application like gimp. But that is a discussion I would not want to meddle in. I fear there are many other applications that will suffer from the same problems, as it is good practice to make use of existing stuff instead of reinventing the wheel. I would hate to think that flatpak's influence will lead to much copying of code, diverting versions, etc.etc. in the near future. It is not worth it.

It is a pity that I can no longer use the "preferred" way of installing... :-(
Frankly, opening raw files in gimp is more important to me than it is to avoid my good old apt.

I would prefer to keep this bug report open, because perhaps it might be a good reason to rethink flatpak.

I guess the status should be "CONFIRMED" now. After all, if one follows the "preferred" route, there will be missing functionality. The bug might be the preference for flatpak and not the code itself, but it is a bug regardless.

m
Comment 3 Jehan 2018-05-03 23:47:14 UTC
> I am not a flatpak expert, but I think I had understood that fastpak does not need to be used like a strict sandbox

Flatpak is a strict sandbox by default.
Well we actually give a lot of extra-permissions already (which flatpak devs recommend against), but not all of them.

> If true, this shows, in my opinion, that the flatpak way of doing things is not suitable for an application like gimp.

It is true that flatpak developers would have to consider advanced software which do a lot of things like GIMP. Unfortunately most of the software ecosystem is made of very simple software which just do 1 thing, so they are much easier to blend into flatpak logics.
Yet sandboxing may be a needed change too. It may be necessary that some things evolve.

> It is a pity that I can no longer use the "preferred" way of installing...

The "preferred" installation method for Linux is not flatpak but your distribution-provided package. See https://www.gimp.org/downloads/ where it is actually clearly stipulated:

> The flatpak build is very new and therefore may have shortcomings.
> It's very likely your Unix-like system distribution already comes
> with a GIMP package. It is the preferred method of installing GIMP,
> as the distribution maintainers take care of all the dependencies
> and bug fix updates. Nevertheless, note that many distros decide to
> pin a specific version of GIMP to their releases, whereas our flatpak
> will follow GIMP releases closely.

We provide a flatpak because it looks like it is an interesting path to a better future regarding software release on Linux (distribution of software through package repositories has many problems of its own), but we are still fully aware of its limitation. Some of these limitations are because of the security model, but many issues are also because the technology is too now and many things are yet to be implemented.
And this is why, even with all the problems of legacy package repositories, they are still the preferred way of installing GIMP and we clearly say it on our download page. This text will stay until/unless we feel that the Flatpak technology will have evolved enough to be considered our recommended method of installation.

> I would prefer to keep this bug report open, because perhaps it might be a good reason to rethink flatpak.

We are not developers of flatpak. This bug report is absolutely useless if the goal is to rethink flatpak.

Anyway I remembered that I did open a bug report about this a while back about this exact topic. So I will just close this bug as duplicate of bug 791362.

*** This bug has been marked as a duplicate of bug 791362 ***