Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#12321 - [gimp] Could not load images via URL

Attached to Project: Arch Linux
Opened by Gerhard Brauer (GerBra) - Tuesday, 02 December 2008, 18:03 GMT
Last edited by Eric Belanger (Snowman) - Tuesday, 12 July 2011, 01:59 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Kieslich (tobias)
Eric Belanger (Snowman)
Architecture All
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Gimp doesn't load images directly from a url. Neither from the dialog in File-Menu nor from command line. It seems that we should use better configure option to solve this.
With the options from current PKGBUILD gimp is build with:
URI: yes (using GIO/GVfs)
But there is no dependency on gvfs. If i install gvfs loading a image still don't work. I assume that maybe gvfs was not installed on the machine when build this package. Or with gvfs it doesn't work either.

What works are configure Options like this:
--without-gvfs --with-gnomevfs --with-libcurl
URI: yes (using gnome-vfs)
if gnome-vfs and libgnomeui are installed.

--without-gvfs --without-gnomevfs --with-libcurl
URI: yes (using libcurl)
This works without gnome-vfs. Using libcurl for this procedure maybe could prevent from having too much gnome dependencies in gimp.

So we should use either gnomevfs or libcurl IMHO.

Additional info:
* package version(s)
gimp 2.6.3-1

Steps to reproduce:
Try to load a image from webite:
This task depends upon

Closed by  Eric Belanger (Snowman)
Tuesday, 12 July 2011, 01:59 GMT
Reason for closing:  Fixed
Comment by Gerhard Brauer (GerBra) - Tuesday, 02 December 2008, 18:45 GMT
Additional info:
I've build now gimp also with option --with-gvfs and gvfs installed. I don't know exactly if gvfs must setup something special, but also with this build a image from URL could not be loaded. So i assume that the gvfs-Option is not functionally in our enviroment...
Comment by P.H. (Vain) - Tuesday, 02 December 2008, 19:09 GMT
First, I can confirm that (images not loading).

And I'd be very happy if you choose libcurl (if that works). I'm not using gnome and I don't want to build gimp manually every time. :)
Comment by Gerhard Brauer (GerBra) - Tuesday, 02 December 2008, 19:37 GMT
@Vain: i don#t know exactly which gnome dependencies could be removed when using libcurl (for this one option of gimp: loading images via URL).
What maybe is a advantage of gnome-vfs is, that with this more protocols could be handled than with libcurl. But IMHO the most used protocol for loading images over internet was http which is handled perfectly with libcurl.
Comment by changed user account to dsohler (Dirk.Sohler) - Wednesday, 03 December 2008, 02:01 GMT
I can confirm this bug (well, i actually mentioned it in a german GIMP forum and the german arch forum *g*) and the other testing Gerhard made. dditionally i second Vains proposal not to use gvfs, because not every GIMP user is using Gnome, too nor wants to install gvfs just for using gimp.
Comment by Eric Belanger (Snowman) - Sunday, 08 February 2009, 02:49 GMT
"gimp"; works now. Should we close this?
Comment by Tobias Kieslich (tobias) - Monday, 09 February 2009, 08:00 GMT
yes, I think that one is taken care of with curl dependency and proper ./configure params
Comment by speps (archspeps) - Thursday, 27 May 2010, 17:54 GMT
Gimp still cannot load an image by its url (file-uri-load) using "gimp $someurl" or dragging an image from any browser to gimp area. This should be fixed.
Comment by speps (archspeps) - Saturday, 29 May 2010, 12:42 GMT
[gimp 2.6.8 - curl 7.20.1]
Still cannot figure out the matter with curl file-uri backend.

$ gimp -i "" --stack-trace-mode="always"
/usr/lib/gimp/2.0/plug-ins/file-uri: fatal error: Segmentation fault
#0 0x00007f300658bace in waitpid () from /lib/
#1 0x00007f30067b0f67 in g_on_error_stack_trace ()
#2 0x00007f3006ef0a90 in ?? () from /usr/lib/
#3 <signal handler called>
#4 0x0000000000401789 in ?? ()
#5 0x00007f3006ef0718 in gimp_main () from /usr/lib/
#6 0x00007f300623fb1d in __libc_start_main () from /lib/
#7 0x0000000000401389 in ?? ()
#8 0x00007fffc4662af8 in ?? ()
#9 0x000000000000001c in ?? ()
#10 0x0000000000000006 in ?? ()
#11 0x00007fffc4664ab9 in ?? ()
#12 0x00007fffc4664add in ?? ()
#13 0x00007fffc4664ae3 in ?? ()
#14 0x00007fffc4664ae5 in ?? ()
#15 0x00007fffc4664ae7 in ?? ()
#16 0x00007fffc4664aec in ?? ()
#17 0x0000000000000000 in ?? ()
GIMP-Error: L'apertura di "" è fallita: La procedura "file-uri-load" non ha restituito valori di ritorno

(that means Error: Opening "" failed: procedure "file-uri-load" has not return values)

Maybe this bug should be reported in upstream, in the while gimp can be compiled with --without-gvfs --with-gnomevfs --without-libcurl (gimp has four file-uri backends gvfs, gnomevfs, libcurl, wget) in order to use wget backend.
Comment by speps (archspeps) - Thursday, 02 September 2010, 09:41 GMT
Gimp 2.6.10-1 cannot load images via url, again.
Comment by Eric Belanger (Snowman) - Monday, 06 September 2010, 15:53 GMT
The -i switch seem to be the problem. Here it just hangs. Try not to use it, i.e.:
$ gimp "" --stack-trace-mode="always"

Does this works for you?
Comment by speps (archspeps) - Monday, 06 September 2010, 18:31 GMT
GIMP-Error: Opening "" failed: Could not open '' for reading: No such file or directory

I get the same error on "file-jpeg-load" procedure, with

gimp "$url"
gimp -i "$url"
with drag&drop from any browser or opening URI (from file menu).

Do you manage to get it work in some way?

(I'm on x86_64)
Comment by Eric Belanger (Snowman) - Monday, 06 September 2010, 20:45 GMT
They all work (using x86_64 too) except the one using the -i switch.
Make sure you have curl, gvfs and gconf installed. I think the package in the repo use gvfs for the uri support. Please report if it fix the problem.
Comment by speps (archspeps) - Tuesday, 07 September 2010, 12:26 GMT
Sorry for the delay.

Just tried on three different machines (x86_64 and two i686).

Same error on each machine (with curl,gvfs and gconf)
Btw seems like libwebkit is also a gimp help system dependency (on a machine i've got not found)

Current Gimp PKGBUILD has not file-uri backend specified so gvfs is used (and should be added as optdepends)

Since file-uri give a lot of problems,
gimp could be built with a safer backend (don't know which one, maybe wget so --without-{gnomevfs,gvfs,libcurl})
Comment by JM (fijam) - Tuesday, 03 May 2011, 13:58 GMT
gimp "" works properly for me. gimp -i with openexr doesn't but it seems to be unrelated to this issue. Please verify is opening a jpg from URL works so this bug can be closed.
Comment by Gerhard Brauer (GerBra) - Saturday, 07 May 2011, 10:36 GMT
Still doesn't work for me on x86_64, KDE, no gnome-vfs installed.
gimp 2.6.11-5
Error message in gimp is:
"Opening '' failed: Could not open '' for reading: No such file or directory"

Terminal message is: GLib-WARNING **: goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0
I have also tried starting gimp on a new X from only an xterm, same result.
Also opening the image via menu doesn't work.

IMHO the reason are still the -configure options we use, but i don't have looked on the current. Since opening this report there are so much changes in the affected packages... But if --with-curl is an option, maybe we should use this cause it may be the best for all users in all environments... My 2¢.
//Edit: if we have two to hundred "maybe possible solutions" as a choice IMHO the ebst is using the simplest solution -> libcurl
Comment by Eric Belanger (Snowman) - Saturday, 18 June 2011, 04:08 GMT
Could you guys try this one:
I only built the x86_64 pkg to save build and upload time.

It uses gnome-vfs instead of gfvs like the package in the repo. To use curl or wget, I'll need to pass --without-gnomevfs to the configure line but that also disable two Plug-In Features:
GNOME UI: no (disabled)
GNOME keyring: no (disabled)

I'll need to see what they do in case gnome-vfs doesn't work. Ideally, we want to keep the current features but we may not have the choice.

Let me know how it works for you (you'll need to install libgnomeui. it's a missing optdepends.). If it doesn't work, post the command line you used as well as the error message. Here, it works: gimp ""

Comment by mattia (nTia89) - Saturday, 18 June 2011, 07:12 GMT
my gimp loads but i have gnome DE installed ....
Comment by Gerhard Brauer (GerBra) - Saturday, 18 June 2011, 08:43 GMT
Eric, this works. But...
libart-lgpl-2.3.21-1 libgnomecanvas-2.30.3-1 libgnome-data-2.32.1-2 gnome-mime-data-2.18.0-5
gnome-vfs-2.24.4-3 libbonobo-2.32.1-1 libunique3-3.0.2-1 gnome-disk-utility-3.0.0-1
gvfs-1.8.2-1 libgnome-2.32.1-2 libbonoboui-2.24.5-1 libgnomeui-2.24.4-1
these are IMHO too much dependencies to get a simple image via http/ftp direct in my gimp...
I don't use Gnome nor a program which needs these libs, until now for gimp.

For myself the best solution is to have a homebrew compiled gimp with curl support. Myself don't need Gnome UI and keyring support in gimp. I don't know which features will break for Gnome users without these plugins.
But i stay with my opinion: IMHO the *simplest* solutuion is to drop any "foreign" dependency (gnome,kde,...) from a tool like gimp - when the same result could be reached by a more common solution like curl...

For this report: if libgnomeui comes to DEPEND in gimp package the command line and opening via menu works.
So i think: close it as solved, forgot it... ;-)

//Edit: i'm not sure if the new dependencies are a *OPT*DEPEND. Without libgnomeui intstalled we break a base function in gimp (as guessed via gimp --help or via Menu->Open from address, the main reason for this bugreport <g>). It's not something that *could* be enabled via preferences or similar, or - when present - offers additional menue entires. So if we go with gnome-vfs this should go to DEPENDS - with all the "bloatware" from libgnomeui...
Comment by Eric Belanger (Snowman) - Saturday, 18 June 2011, 19:13 GMT
After submitting the gnome-vfs package, I realized that the libgnomeui optdepends might bring a lot of dependencies for some users. If it need to be a depends instead, then that would be worst. The "Menu->Open Location" use the file-uri plugins which links to libgnomeui. It's just another way to do it instead of using the command line. So I thinks it's still an optdepends.

Anyway, I am currently building a gimp package that uses curl for URI support so you can test if it works. If both works, I'll check what the GNOME UI and GNOME keyring support actually do. I would prefer to use the curl support (if it works) because it has dependencies on only base packages and is probably already installed by more users.

I'll also try the current package in a clean chroot. Maybe it's just a missing depends as it works on my system.
Comment by Eric Belanger (Snowman) - Saturday, 18 June 2011, 19:42 GMT
The curl support doesn't work. The plug-in seg fault.
Comment by speps (archspeps) - Sunday, 19 June 2011, 01:47 GMT
@Eric What about wget? Building with --without-{gnomevfs,gvfs,libcurl} would use a simple and maybe more lucky wget backend.
Comment by Eric Belanger (Snowman) - Sunday, 19 June 2011, 03:04 GMT
With wget, it only display part of the image for jpeg "Premature end of JPEG file". For png, it doesn't display them. Maybe a problem with transparency. Anyway, I've uploaded them in case someone wnats to test them.

-with curl:
-with wget:

About the current package (gvfs), it wasn't working a while ago in my clean chroot but now it works. I'll need to see why (missing depends or update).
Comment by Eric Belanger (Snowman) - Sunday, 19 June 2011, 05:59 GMT
I figured out that the gimp package in extra depends on gvfs for URI support (even if namcap doesn't mention it). So you could try it with gvfs installed to see if that works for you. A gvfs optdepends would be heavy for some users. On a clean chroot with gimp installed:

$ sudo pacman -S gvfs
resolving dependencies...
looking for inter-conflicts...

Targets (22): libproxy-0.4.6-6 [0.07 MB] gsettings-desktop-schemas-3.0.1-2 [0.04 MB] glib-networking-2.28.7-1 [0.04 MB]
libsoup-2.34.2-1 [0.30 MB] libgnome-keyring-3.0.3-1 [0.09 MB] libsoup-gnome-2.34.2-1 [0.01 MB]
gtk3-3.0.11-1 [4.66 MB] libunique3-3.0.2-1 [0.04 MB] sg3_utils-1.30-1 [0.46 MB] polkit-0.101-2 [0.35 MB]
parted-2.4-1 [0.47 MB] libatasmart-0.17-1 [0.03 MB] lsof-4.84-3 [0.27 MB] eject-2.1.5-5 [0.02 MB]
udisks-1.0.3-3 [0.15 MB] libnotify-0.7.3-1 [0.03 MB] hicolor-icon-theme-0.12-1 [0.00 MB]
gnome-disk-utility-3.0.0-1 [1.65 MB] libcddb-1.3.2-2 [0.05 MB] libcdio-0.82-1 [0.47 MB] fuse-2.8.5-1 [0.11 MB]
gvfs-1.8.2-1 [0.80 MB]

Total Download Size: 0.00 MB
Total Installed Size: 64.65 MB

So the only ones that seem to work for me is the gvfs and gnome-vfs support.
Comment by speps (archspeps) - Sunday, 19 June 2011, 11:40 GMT
@Eric wait

> -with curl:
> -with wget:

That's the same url. Which one is built with wget? 5.1 - 5.2 - 5.3 ?
Comment by Eric Belanger (Snowman) - Sunday, 19 June 2011, 12:17 GMT Comment by Gerhard Brauer (GerBra) - Sunday, 19 June 2011, 14:33 GMT
Ok, two years after this report myself must say: code quality of all affected programs are went to bad... ;-)

confirmed: with wget **all** images are loaded only partially ->bad, bug
wget only download via commandline works.

confirmed: with libcurl gimp segfault -> bad, bug
curl only download via commandline works.

confirmed: the working solution seems gnomevfs option, with this i could open most of the tested images directly. Most because the command line option often doesn't work on the URI, but using via "open with gimp" from a browser work on the same image...
I've not tested the with-gvfs option, i assume this would work too, maybe with lesser dependencies (???).

On my PC (up-to-date system and abs)  FS#21907  is back:
checking for python version... 3.2
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python3.2/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python3.2/site-packages
checking for headers required to compile python extensions... File "<string>", line 1
import sys; print sys.prefix
SyntaxError: invalid syntax
File "<string>", line 1
import sys; print sys.exec_prefix
SyntaxError: invalid syntax
so i have builded my test packages without python support.

In 12/2008 i opened this report after a discussion in german bbs when a user run in this bug. At this time the libcurl option works perfectly... 2 1/2 year later we still must waste time in this annoying thing. If i summarize my and your time we could have downloaded thousand and thousand images "the old way" via browser/commandline and then opened this file(s) with gimp ;-)

A solution? I'm realy confused... I've looked a little on Debian BTS and gimp/curl bugtrackers and bbs, but don't find anything to get the libcurl opton to work. I will spent next week some time to write something on gimp and/or curl MLs or bugtracker, cause the libcurl option is IMHO the best solution... But the experience with this problem frightens me that this is a solution also for the next months/years...

My private solution: I will build my gimp without any affected plugin option for direct download of images. The only working solutions brings for myself really too much packages than it is worth...

Common solution: I mean, we don't have many options... gnome-vfs seems the only way, dep or optdepend - i don't care...
Maybe we could find a "middle way" with package splitting for some/most of the plugins gimp uses... So that we could reduce the dependencies for the base gimp package to a minimum, and if users want additional functionality they have to pay the price... But i don't know if splitting would help us in this situation...

Another "maybe": We drop gvfs/gnome-vfs/libcurl, and point crying, whining users (like me <g>) to: "Hey, use download in your browser or wget/curl command line to download your image, then open it with your gimp. Believe us, this will work forever.. -> Closed, Won't fixed..."
Myself would love this way meanwhile, simple and stupid <g>

If i found more infos on the libcurl problem (i will compile it with debugging symbols and try to use gdb, but i'm not firm with C/C++) or have infos from reports to gimp/curl upstream i post the news (or send a patch)...
Comment by speps (archspeps) - Sunday, 19 June 2011, 16:05 GMT
Habemus Patch-am! (maybe)

Taking a look to the wget backend source code, I've discovered it simply exec wget to retrieve files and analyse its output to
dirty check the download status. It didn't work because of the default wget output style (bar).
uri-backend-wget.c instead, suppose to get the old dot style to analyse causing a false finished status.

I've managed to get it work with my 2cents attached patch, that adds --progress=dot to wget parameters during execlp.
Hope this works for you too. Please test.

@Eric can you upload a package tar ball so everyone can test? Thanks
Comment by Eric Belanger (Snowman) - Sunday, 19 June 2011, 21:41 GMT
@GerBra : Add PYTHON=/usr/bin/python2 at beginning of configure line or build in a chroot
Can you post the links to images that failed with gnome-vfs (and comman line options)? I'll try to see if I can replicate as it might depends on things like command line options, file type and website.

Splitting the package won't improve anything. Gimp and its accompanying libraries only depends on gtk2 and common libraries. I could see if I can move some of the image libaries dependencies to optdepends. But they are usually small and don't have big dependency chains so it won't change much and it make sense for an image manipulation app to depends on image libraries.

The file-uri plugin it likely to stay in the package with an optdepends. Users for which it doesn't work or who don't want to install the optdepends could be told to download the image manually.
Comment by Eric Belanger (Snowman) - Sunday, 19 June 2011, 22:29 GMT
it doesn't improve anything here. Like the unpatched code, some time it works :
$ gimp
sometime it doesn't:
$ gimp

For the links that the patched gimp work, try to see it it is also works with the unpatched wget support.

I've uploaded the package anyway:

-wget patched:

Maybe the progress bar needs to be removed completely.
Comment by speps (archspeps) - Monday, 20 June 2011, 10:29 GMT
Yep, adding the dotted progress bar was not enough to solve.
It was just the first step, but now I've got it.

uri-backend-wget.c did not consider a "sixth" wget output line, the "Saving to:"
probably added in a newer wget version (uri-backend-wget.c is from 2008).
So it considered the ":" of that line as the separator of the end date displayed
when download is finished.
About dots, that's just a way to display the progress bar in gimp (counting dots).

With the attached patch all works fine, tested with every image, filetypes and sizes.

Please test again, I wish this is the last one ;)
Comment by ajs124 (andy123) - Monday, 20 June 2011, 18:53 GMT
nice patch but if the url is like ftp://user:password@host/file.png gimp fails with
"failed: A network error occurred: ==> SYST ... done. ==> PWD ... done."
Comment by Eric Belanger (Snowman) - Monday, 20 June 2011, 22:22 GMT
The latest patch ( ) works here althought I didn't tested any site which requires logins. Probably the patch still need some tweaking. This patch should be submitted upstream as well as a report on the libcurl problem (maybe with gdb output). I think it might be better to try to have the curl support fixed. As curl supplies a library, there's no need to mess with parsing command output and it might have a better handling for things like website login.

SepS and andy: BTW, did you tried the non-wget packages that I posted?
Comment by ajs124 (andy123) - Monday, 20 June 2011, 23:30 GMT
the curl version says:
Opening 'ftp://user:password@host/file.png' failed: Procedure 'file-uri-load' returned no return values
Comment by speps (archspeps) - Tuesday, 21 June 2011, 13:03 GMT
@andy Thanks for reporting the ftp failure. Ftp session have a different wget output.
Newer patch solves also ftp issue, please test. If no other issues come out I'll send upstream.

@Eric You're right, libcurl would be a cleaner solution. I'll have a look at libcurl backend source too,
to figure out what's going wrong with it.
Meanwhile, you can upload an --enable-debug package with !strip option for libcurl backend
to include debugging symbols.
Comment by Eric Belanger (Snowman) - Wednesday, 22 June 2011, 02:38 GMT Comment by speps (archspeps) - Thursday, 23 June 2011, 01:30 GMT
@Eric Thanks for your package upload. It was useful for catching an unseen warning.

curl_easy_getinfo from uri-backend-libcurl.c needs a long pointer for response code,
while a gint was wrongly used. A glong for response_code, solves segfaults.

I was asking to push upstream while I discovered last git applies this fix too.
I created the latest patch by diffing with latest git version and adding another fix,
that adds ftp success code (226) to the response code check, for fully supporting ftp.
Test this patch too.

Ok, now we have two working lightweight file-uri backends (libcurl - wget).
We need an heavy testing on both, to catch for unseen faults and make a choice on the more stable.
Comment by ajs124 (andy123) - Thursday, 23 June 2011, 15:53 GMT
you wrote patche instead of patch, but the patch is working fine...
gopher isn't working (e.g. gopher://
Comment by speps (archspeps) - Thursday, 23 June 2011, 17:32 GMT
@Andy Thanks, protocol man ;) Sorry for the "patche", oversight.

Yep, gopher was not listed in the protocol support list for curl file-uri backend.
Latest patch add support for gopher too, tested with your link.
Potentially every protocol supported by libcurl could be added (man curl for a list), just ask.

So +1 for libcurl.

Note, this patch fix also a build compilation with latest curl (v 7.21.7),
that does not provide anymore "types.h" header.

Please test this too, hoping we're close to the end of this task odyssey ;)
Comment by ajs124 (andy123) - Thursday, 23 June 2011, 18:06 GMT
+1 for libcurl (more protocols, no parsing, ...)
Comment by Eric Belanger (Snowman) - Friday, 24 June 2011, 00:10 GMT
with latest curl patch :

I also prefer curl over wget. And I'll probably go with curl instead of gvfs or gnome-vfs, despite the lost of the gnome UI and keyring (still not sure what they do), because it seems to work for everyone (I haven't had much input though) and will have small optdepends. Anyway, the package will go in testing first.
Comment by ajs124 (andy123) - Sunday, 03 July 2011, 19:43 GMT
why is the new gimp version still not in testing?
Comment by Eric Belanger (Snowman) - Tuesday, 05 July 2011, 18:20 GMT
gimp-2.6.11-6 and gimp-devel-2.7.2-2 are in testing with curl support for URI. They are basically cleaned up version of my last test packages. Please test them and let me know any problems. Hopefully, we'll be able to close this bug once for all. For gimp-devel, I had to remove parts of the patch as they were already applied upstream.
Comment by speps (archspeps) - Tuesday, 05 July 2011, 18:25 GMT
Both patches (wget and libcurl with some improvements) were pushed on gimp master git [1].
Attached is the latest libcurl patch applied upstream.

Comment by speps (archspeps) - Tuesday, 05 July 2011, 18:32 GMT
@Eric What a timing ;) Hoping this is the last re-build for you

Related bug with patch history >
Comment by Eric Belanger (Snowman) - Saturday, 09 July 2011, 03:17 GMT
I think I'll keep the gimp in testing as is. If there are problems, I'll switch to the patch version as accepted upstream. I don't think the difference isn't worth the trouble considering that both gimp and gimp-devel are involved and they take lot of time to build.