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
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
|
Details
Description:
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: gimp http://bbs.archlinux.org/img/titlelogo.png |
This task depends upon
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...
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. :)
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.
Still cannot figure out the matter with curl file-uri backend.
$ gimp -i "http://www.gimp.org/images/frontsplash.jpg" --stack-trace-mode="always"
/usr/lib/gimp/2.0/plug-ins/file-uri: fatal error: Segmentation fault
#0 0x00007f300658bace in waitpid () from /lib/libpthread.so.0
#1 0x00007f30067b0f67 in g_on_error_stack_trace ()
#2 0x00007f3006ef0a90 in ?? () from /usr/lib/libgimp-2.0.so.0
#3 <signal handler called>
#4 0x0000000000401789 in ?? ()
#5 0x00007f3006ef0718 in gimp_main () from /usr/lib/libgimp-2.0.so.0
#6 0x00007f300623fb1d in __libc_start_main () from /lib/libc.so.6
#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 "http://www.gimp.org/images/frontsplash.jpg" è fallita: La procedura "file-uri-load" non ha restituito valori di ritorno
(that means Error: Opening "http://www.gimp.org/images/frontsplash.jpg" 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.
$ gimp "http://www.gimp.org/images/frontsplash.jpg" --stack-trace-mode="always"
Does this works for you?
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)
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.
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 libwebkit-1.0.so.2 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})
gimp 2.6.11-5
Error message in gimp is:
"Opening 'http://www.gimp.org/images/frontsplash.jpg' failed: Could not open 'http://www.gimp.org/images/frontsplash.jpg' 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
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 "http://www.gimp.org/images/frontsplash.jpg"
-------------
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...
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.
-with curl: http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.1-x86_64.pkg.tar.xz
-with wget: http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.1-x86_64.pkg.tar.xz
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).
$ 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.
> -with curl: http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.1-x86_64.pkg.tar.xz
> -with wget: http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.1-x86_64.pkg.tar.xz
That's the same url. Which one is built with wget? 5.1 - 5.2 - 5.3 ?
gnome-vfs : http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.1-x86_64.pkg.tar.xz
curl : http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.2-x86_64.pkg.tar.xz
wget : http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.3-x86_64.pkg.tar.xz
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#21907is 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)...
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
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.
it doesn't improve anything here. Like the unpatched code, some time it works :
$ gimp http://www.google.ca/logos/2011/fathersday11-ig.jpg
sometime it doesn't:
$ gimp http://www.rds.ca/images/chroniques/321494.jpg
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: http://dev.archlinux.org/~eric/gimp/gimp-2.6.11-5.4-x86_64.pkg.tar.xz
Maybe the progress bar needs to be removed completely.
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 ;)
"failed: A network error occurred: ==> SYST ... done. ==> PWD ... done."
SepS and andy: BTW, did you tried the non-wget packages that I posted?
Opening 'ftp://user:password@host/file.png' failed: Procedure 'file-uri-load' returned no return values
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.
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.
gopher isn't working (e.g. gopher://gopher.thurman.org.uk/I/imgur/Sg0SW.jpg).
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 ;)
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.
Both patches (wget and libcurl with some improvements) were pushed on gimp master git [1].
Attached is the latest libcurl patch applied upstream.
[1] http://git.gnome.org/browse/gimp/log/plug-ins/file-uri
Related bug with patch history > https://bugzilla.gnome.org/show_bug.cgi?id=653980