Description of problem: Since last updates of ufraw, ufraw-common, ufraw-gimp I cannot open a raw file directly from Gimp, but it works if I use Ufraw Version-Release number of selected component (if applicable): 0.19.2.6.fc19 How reproducible: always Steps to Reproduce: 1.open a raw file directly with Gimp 2. 3. Actual results: I get a window importing from TIFF and another window-TIFF directory is missing required "ImageLength" field Expected results: just open the file using the ufraw-gimp plugin Additional info: working fine till latest updates
the only working release is 0.19.2-2, also intermediate releases are no good
Hmm, opening *.NEF and *.ARW raw image files works for me both from the file manager and from GIMP directly: gimp-2.8.6-3.fc19.x86_64 ufraw-0.19.2-6.fc19.x86_64 ufraw-gimp-0.19.2-6.fc19.x86_64 Which version of gimp do you use? Would you please attach the file ~/.gimp-2.8/pluginrc and one raw image file that exhibits the problem for you? Thanks.
My raw image is coming from Pentax gear,i.e. is *.pef
Created attachment 809395 [details] plugin configuration file
Created attachment 809396 [details] test case
gimp-2.8.6-3.fc19.i686
The image file you attached opens for me just as I'd expect it. One difference I see is that you're on 32bit and I'm on 64bit (you also use a private plugin (gmic), but I don't think it matters here). Let me check out if 32bit vs. 64bit makes a difference here.
I've tried this out on an x86 virtual machine, to no avail -- everything works as it should. Can you try this as a different user and/or on a different machine?
Created attachment 810013 [details] Screenshot when using Gimp tried a new user and different machine,also deleted ./gimp and.ufawc. No way, see also next shot
Created attachment 810015 [details] another screen shot see also this screen-shot Please note that Ufraw standalone works fine
additional info: If I open a PEF file from a Pentax Kx i get only a green imag,also as preview. I cannot get any preview with PEF files coming from an old 1stDS
if I use the command send to Gimp in Ufraw I get this message: L'apertura di "/tmp/IMGP0733.PEF_BZMJ4W.ufraw" è fallita: Impossibile aprire '/tmp/IMGP0733.PEF_BZMJ4W.ufraw' in lettura: Motivo sconosciuto opening of "/tmp/IMGP0733.PEF_BZMJ4W.ufraw"failed: impossible to open /tmp/IMGP0733.PEF_BZMJ4W.ufraw" in read: unknown reason. Don't know if connected
I have the same problem with raw dx7100 nikon. I tried with a 32bit and a 64bit machine with the same results. I must downgrade to 0.19.2-2 version. Franco Pasquarelli
happy not be alone.
workaround: whith 0.19.2-6 version installed edit the .gimp-2.8/pluginrc file in user home, search the lines (load-proc (extension "3fr,ari,arw,cap,cine,cr2,crw,cs1,dc2,dcr,dng,erf,fff,hdr,ia,iiq,jpeg,jpg,k25,kc2,kdc,mdc,mef,mos,mrw,nef,nrw,orf,pef,pxn,qtk,r3d,raf,raw,rdc,rw2,rwl,sr2,srf,srw,sti,tif,tiff,ufraw,x3f") (magic "0,string,II*\\0,0,string,MM\\0*,0,string,<?xml") (thumb-loader "file-ufraw-load-thumb")) delete the line (magic"0,string,II*\\0,0,string,MM\\0*,0,string,<?xml")
I confirm that this workaround works flawlessly: of course it is not system wide ;-)
The problem isn't in ufraw-gimp plugin, but in the identifier for file formats; quite I have $ file IMGP7272.PEF IMGP7272.PEF: TIFF image data, big-endian $ file DSC_1258.NEF DSC_1258.NEF: TIFF image data, little-endian
Well, many raw formats being modeled after TIFF doesn't help much... I'm a bit surprised that removing the "(magic...)" line helps, because it registers ufraw as a loader for file types matching the TIFF magic values (little-endian "II*\0", big-endian "MM\0*) and XML which is used for "sending" the image to GIMP from the standalone program (it writes an XML control file and then tells GIMP to open it, the ufraw gimp plugin then should read that file , then load the real raw image file and "develop" it with the recorded settings).
The problem is that with the magic line ufraw-gimp is not used. I report some lines obtained with strace: -------------------------- --- without magic line -------------------------- access("/home/matem/pasqui/foto/pentax_k7_01.pef", F_OK) = 0 stat64("/home/matem/pasqui/foto/pentax_k7_01.pef", {st_mode=S_IFREG|0644, st_size=12923627, ...}) = 0 access("/home/matem/pasqui/foto/pentax_k7_01.pef", R_OK) = 0 pipe([11, 12]) = 0 pipe([14, 15]) = 0 fstat64(11, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(11, F_GETFL) = 0 (flags O_RDONLY) fstat64(15, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(15, F_GETFL) = 0x1 (flags O_WRONLY) fstat64(14, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(14, F_GETFL) = 0 (flags O_RDONLY) fstat64(12, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(12, F_GETFL) = 0x1 (flags O_WRONLY) open("/usr/lib/gimp/2.0/plug-ins/ufraw-gimp", O_RDONLY|O_LARGEFILE) = 16 ----- correct ----------------- ------------------------------------- -----with magic line ------------------------------------- access("/home/matem/pasqui/foto/pentax_k7_01.pef", F_OK) = 0 stat64("/home/matem/pasqui/foto/pentax_k7_01.pef", {st_mode=S_IFREG|0644, st_size=12923627, ...}) = 0 access("/home/matem/pasqui/foto/pentax_k7_01.pef", R_OK) = 0 pipe([11, 12]) = 0 pipe([14, 15]) = 0 fstat64(11, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(11, F_GETFL) = 0 (flags O_RDONLY) fstat64(15, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(15, F_GETFL) = 0x1 (flags O_WRONLY) fstat64(14, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(14, F_GETFL) = 0 (flags O_RDONLY) fstat64(12, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fcntl64(12, F_GETFL) = 0x1 (flags O_WRONLY) open("/usr/lib/gimp/2.0/plug-ins/file-tiff-load", O_RDONLY|O_LARGEFILE) = 16 ------ not correct
last information, ufraw-gimp is correctly used if I comment the magic line related to the tiff files whitout delete the magic line related to raw: (load-proc (extension "tif,tiff") #(magic "0,string,II*\\0,0,string,MM\\0*") (mime-type "image/tiff")) "" so the problem is to discern the raw files to the tiff files with magic.
is anybody working on it??
ufraw-0.19.2-12.20140414cvs.fc20.x86_64 doesn't fix this bug while fixes Bug 1043854
Hmm, ufraw-0.19.2-13.20140414cvs.fc20.x86_64 (which contains an unrelated fix) fixes this issue for me -- gimp loads *.ARW (from three camera models) and all *.NEF and *.PEF files I have properly here.
I deleted .gimp folder in user's space, then I restarted Gimp and I get same error. Ufraw as stand-alone software opens the .Pef file.....so there is somenthing unreliable in .pluginrc file in Gimp directory. I am using PEF files from a Pentax 1stDS DSLR, a sample will be mailed directly to your mailbox
I've tried three ways with gim,p 2.8 as shipped in Fedora and a recent development version (after deleting/renaming my respective gimp configuration folders): - ufraw <file> -> Send to GIMP - gimp-<version> <file> - gimp-<version> -> Open All of these work for me, so color me amazed why it behaves differently for you.
Created attachment 891293 [details] screenshot when I use Gimp+Ufraw as plugin No way of making Gimp+Ufraw work. (see image) ________________________________________________________________ When using Ufraw with the option to send to Gimp: ufraw IMGP5743.PEF [antonio@Fujiantonio Immagini]$ (gimp:5981): Gimp-Widgets-CRITICAL **: gimp_device_info_set_device: assertion '(info->device == NULL && GDK_IS_DEVICE (device)) || (GDK_IS_DEVICE (info->device) && device == NULL)' failed (file-svg:5997): GLib-WARNING **: (gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0) ______________________________________________________________________ using in a terminal gimp IMGP5743.PEF (gimp:6192): Gimp-Widgets-CRITICAL **: gimp_device_info_set_device: assertion '(info->device == NULL && GDK_IS_DEVICE (device)) || (GDK_IS_DEVICE (info->device) && device == NULL)' failed and same image ___________________________________________________________________________ did you check with the PEF image I sent by e-mail???
(In reply to antonio montagnani from comment #26) > did you check with the PEF image I sent by e-mail??? That one landed in my spam folder... but works as well here. Have you tried this as a different (preferably freshly created) user? Please run these commands and attach the resulting /tmp/gimp-plugins-normalized.txt file to this bug: fgrep '(plug-in-def' ~/.gimp-2.8/pluginrc | sed 's,^ *(plug-in-def *",,g;s," *[0-9]*$,,g;s,^/usr/lib[0-9]*,%{_libdir},g' > /tmp/gimp-plugins-normalized.txt
Oh, the command is one single line only (BZ broke it up).
Created attachment 892609 [details] test case as per needinfo Very strange, one system now seems to be wortking fine, but the desktop has the usual problem
Created attachment 892612 [details] second test case on second system confirm that both systems still suffer from same bug.I note that in one case I have some digits that are not present here
in usr/lib64/gimp2.0 gimp-ufraw is defined as (application/x-executable). Is it correct???
Hmm, I'm at a loss what is different on your system (cf. comment 29) that could cause this issue. Order in the pluginrc notwithstanding, I have three more plugins installed but I really don't think they are pertinent to the problem: - gutenprint - help-browser - resynth (In reply to antonio montagnani from comment #31) > in usr/lib64/gimp2.0 gimp-ufraw is defined as (application/x-executable). > > Is it correct??? This path seems odd. Here's the ufraw plugin binary I use: -rwxr-xr-x. 1 root root 1256720 Apr 29 17:24 /usr/lib64/gimp/2.0/plug-ins/ufraw-gimp
both my systems (and also a Fedora 20 of my friend) suffer of same bug. Sorry for my typing mistake: [root@Fujiantonio plug-ins]# ls -l ufraw-gimp -rwxr-xr-x. 1 root root 1302960 29 apr 17.24 ufraw-gimp so both you and me have same plugin, not understand why transfer from ufraw to gimp doesn't work with my files. Any way to debug (by different logs for example) ??
(In reply to antonio montagnani from comment #33) > both my systems (and also a Fedora 20 of my friend) suffer of same bug. > Sorry for my typing mistake: > > [root@Fujiantonio plug-ins]# ls -l ufraw-gimp > -rwxr-xr-x. 1 root root 1302960 29 apr 17.24 ufraw-gimp Your file size is different from mine, do you have prelink installed? > so both you and me have same plugin, not understand why transfer from ufraw > to gimp doesn't work with my files. > > Any way to debug (by different logs for example) ?? At the moment I'm not aware how to trace GIMP choosing a file loader plugin other than running it in a debugger. I guess I'll have to poke upstream about this issue.
no idea if pre-link is installed (I guess no), all systems that I tried (mine and also have a friend of mine) are standard Fedora installation (32 and 64 bit, fresh and updated with Fedora). I am not an expert, but I guess tha comment #20 is a good starting point: my two cents
prelink is installed (0.5.0-1.fc20)
if I remove prelink everything seems to be working !!!!
please do not consider comment #37
(In reply to antonio montagnani from comment #38) > please do not consider comment #37 I'm curious what prompted it then... ;-) Anyhow, AIUI to dig deeper, we'd somehow have to trace the issue in the code itself, how the file loader plugin gets chosen differently on your systems than on mine. How familiar are you with using debuggers (e.g. gdb or ddd)?
Just to clarify, I removed prelink package by yum, I rebooted, but nothing apparently changed.Is this what you mean when you say to remove prelink? Not very familiar with using debuggers but I can try (good way to learn debugging)
I don't think it has much bearing on the issue, but to undo prelinking you need to have prelink installed, then run "prelink -ua". Afterwards, remove the package again. If you're not overly familiar with debugging, I wouldn't want to get you started here because there are various plugins and parts of the main app involved, so the calls between various pieces of code are pretty complicated, you can easily get lost in it. Do you know how to build GIMP from sources? If so, it would probably be better if I added some instrumentation to the code in question which logged how the file plugin gets chosen to standard output. Then we could compare both logs and hopefully find out better what's different between your and my setup.
Not familiar with building GIMP from sources - it could be a good chance to learn :-) Comment #19 should be a good starting point
Hmm, the strace output in comment #19 isn't terribly informative -- it doesn't expose the actual decision taking process at all, just the outcome, i.e. that in one case it loads ufraw-gimp and in the other file-tiff-load. Ok, for starters here's the upstream documentation how to build GIMP from git: http://www.gimp.org/source/howtos/gimp-git-build.html Just so we're on the same page, I'll assume that you set PREFIX=$HOME/opt/gimp-2.8-git. You'll want to build from the gimp-2-8 branch, so add "--branch gimp-2-8" to the "git clone ..." command. Additionally, after cloning the gimp source repository, if you don't have it, install the "yum-utils" package, then download the Fedora RPM spec file: wget http://pkgs.fedoraproject.org/cgit/gimp.git/plain/gimp.spec Afterwards run (as root) "yum-builddep /path/to/gimp.spec" which should install all -devel packages needed for building gimp. Then continue with going to the checked out source directory, running "autogen.sh" and so on. Meanwhile I'll try to add some debugging code which shows us where gimp decides to use one or the other plugin for loading these files. Please report when you've managed to build and run gimp from source, or when you encounter problems. Thanks!
we are working on the issue but when at final stage we get an error: we will report, another friend is going to join us in this effort and he will send the full report.
Did you manage to build GIMP from source?
yes, but I am waiting for the friend to give more infos after joining Bugzilla, as he actually did the job on his computer
What is my mistake??? [antonio@Fujiantonio ~]$ export PREFIX='echo /home/antonio/gimp-git' [antonio@Fujiantonio ~]$ export PATH="$PREFIX/bin:$PATH" [antonio@Fujiantonio ~]$ export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH" [antonio@Fujiantonio ~]$ export LD_LIBRARY_PATH="$PREFIX/lib:$LD_LIBRARY_PATH" [antonio@Fujiantonio ~]$ export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS" [antonio@Fujiantonio ~]$ export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS" [antonio@Fujiantonio ~]$ git clone git://git.gnome.org/gimp Cloning into 'gimp'... remote: Counting objects: 383398, done. remote: Compressing objects: 100% (58705/58705), done. remote: Total 383398 (delta 330086), reused 376124 (delta 324098) Ricezione degli oggetti: 100% (383398/383398), 217.79 MiB | 1.14 MiB/s, done. Risoluzione dei delta: 100% (330086/330086), done. Checking connectivity... fatto. [antonio@Fujiantonio ~]$ cd gimp [antonio@Fujiantonio gimp]$ [antonio@Fujiantonio gimp]$ ./autogen.sh --prefix=$PREFIX I am testing that you have the tools required to build the GNU Image Manipulation Program from git. This test is not foolproof, so if anything goes wrong, see the file HACKING for more information... checking for libtool >= 1.5 ... Major version might be too new (2.4.2) checking for gtkdocize ... yes checking for autoconf >= 2.54 ... yes (version 2.69) checking for automake >= 1.10.0 ... yes (version 1.13.4) checking for intltool >= 0.40.1 ... yes (version 0.50.2) checking for xsltproc ... yes I am going to run ./configure with the following arguments: --prefix=echo /home/antonio/gimp-git aclocal-1.13: error: non-option arguments are not accepted: '/home/antonio/gimp-git/share/aclocal'. aclocal-1.13: Try '/usr/bin/aclocal-1.13 --help' for more information. aclocal-1.13 gave errors. Please fix the error conditions and try again.
new run, but no luck ;-) [antonio@Fujiantonio ~]$ export PREFIX='/home/antonio/gimp-git' [antonio@Fujiantonio ~]$ export PATH="$PREFIX/bin:$PATH" [antonio@Fujiantonio ~]$ export LD_LIBRARY_PATH="$PREFIX/lib:$LD_LIBRARY_PATH" [antonio@Fujiantonio ~]$ export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS" [antonio@Fujiantonio ~]$ cd gimp [antonio@Fujiantonio gimp]$ ./autogen.sh --prefix=$PREFIX I am testing that you have the tools required to build the GNU Image Manipulation Program from git. This test is not foolproof, so if anything goes wrong, see the file HACKING for more information... checking for libtool >= 1.5 ... Major version might be too new (2.4.2) checking for gtkdocize ... yes checking for autoconf >= 2.54 ... yes (version 2.69) checking for automake >= 1.10.0 ... yes (version 1.13.4) checking for intltool >= 0.40.1 ... yes (version 0.50.2) checking for xsltproc ... yes I am going to run ./configure with the following arguments: --prefix=/home/antonio/gimp-git aclocal-1.13: warning: couldn't open directory '/home/antonio/gimp-git/share/aclocal': File o directory non esistente configure.ac:476: warning: macro 'AM_GLIB_GNU_GETTEXT' not found in library configure.ac:534: warning: macro 'AM_PATH_GLIB_2_0' not found in library configure.ac:574: warning: macro 'AM_PATH_GTK_2_0' not found in library libtoolize: putting auxiliary files in `.'. libtoolize: linking file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4macros'. libtoolize: linking file `m4macros/libtool.m4' libtoolize: linking file `m4macros/ltoptions.m4' libtoolize: linking file `m4macros/ltsugar.m4' libtoolize: linking file `m4macros/ltversion.m4' libtoolize: linking file `m4macros/lt~obsolete.m4' configure.ac:484: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:546: error: possibly undefined macro: AM_PATH_GLIB_2_0 configure.ac:586: error: possibly undefined macro: AM_PATH_GTK_2_0 [antonio@Fujiantonio gimp]$
A further step.....please note that --branch gimp-2.8 gives: git clone git://git.gnome.org/gimp --branch gimp-2.8 Cloning into 'gimp'... fatal: Il branch remoto gimp-2.8 non è stato trovato in upstream origin Anyway: [antonio@Fujiantonio gimp]$ export PREFIX='/home/antonio/gimp-git' [antonio@Fujiantonio gimp]$ export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH" [antonio@Fujiantonio gimp]$ export LD_LIBRARY_PATH="$PREFIX/lib:$LD_LIBRARY_PATH" [antonio@Fujiantonio gimp]$ export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS" [antonio@Fujiantonio gimp]$ cd gimp bash: cd: gimp: File o directory non esistente [antonio@Fujiantonio gimp]$ ./autogen.sh --prefix=$PREFIX I am testing that you have the tools required to build the GNU Image Manipulation Program from git. This test is not foolproof, so if anything goes wrong, see the file HACKING for more information... checking for libtool >= 1.5 ... Major version might be too new (2.4.2) checking for gtkdocize ... yes checking for autoconf >= 2.54 ... yes (version 2.69) checking for automake >= 1.10.0 ... yes (version 1.13.4) checking for intltool >= 0.40.1 ... yes (version 0.50.2) checking for xsltproc ... yes I am going to run ./configure with the following arguments: --prefix=/home/antonio/gimp-git aclocal-1.13: warning: couldn't open directory '/home/antonio/gimp-git/share/aclocal': File o directory non esistente libtoolize: putting auxiliary files in `.'. libtoolize: linking file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4macros'. libtoolize: linking file `m4macros/libtool.m4' libtoolize: linking file `m4macros/ltoptions.m4' libtoolize: linking file `m4macros/ltsugar.m4' libtoolize: linking file `m4macros/ltversion.m4' libtoolize: linking file `m4macros/lt~obsolete.m4' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking dependency style of gcc... gcc3 checking whether to enable maintainer-specific portions of Makefiles... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.16... yes checking for target architecture... x86_64-unknown-linux-gnu checking for some Win32 platform... no checking for native Win32... no checking whether make sets $(MAKE)... (cached) yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking whether to turn on debugging... no checking whether to turn on profiling... no checking whether gcc understands -Wdeclaration-after-statement... yes checking whether gcc understands -Wmissing-prototypes... yes checking whether gcc understands -Werror=missing-prototypes... yes checking whether gcc understands -Wstrict-prototypes... yes checking whether gcc understands -Wmissing-declarations... yes checking whether gcc understands -Winit-self... yes checking whether gcc understands -Wpointer-arith... yes checking whether gcc understands -Wold-style-definition... yes checking whether gcc understands -Wmissing-format-attribute... yes checking whether gcc understands -Wformat-security... yes checking whether gcc understands -fno-common... yes checking whether gcc understands -fdiagnostics-show-option... yes checking whether gcc understands --omg-optimized... no checking whether gcc understands --disable-instructions... no checking for ANSI C header files... (cached) yes checking for sys/wait.h that is POSIX.1 compatible... yes checking whether time.h and sys/time.h may both be included... yes checking execinfo.h usability... yes checking execinfo.h presence... yes checking for execinfo.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/times.h usability... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking for sys/wait.h... (cached) yes checking for unistd.h... (cached) yes checking for backtrace... yes checking for pid_t... yes checking for vprintf... yes checking for _doprnt... no checking for size_t... yes checking for working alloca.h... yes checking for alloca... yes checking for fsync... yes checking for difftime... yes checking for mmap... yes checking whether binary relocation support should be enabled... no checking for _NL_MEASUREMENT_MEASUREMENT... yes checking whether NLS is requested... yes checking for intltool >= 0.40.1... 0.50.2 found checking for intltool-update... /usr/bin/intltool-update checking for intltool-merge... /usr/bin/intltool-merge checking for intltool-extract... /usr/bin/intltool-extract checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for perl... /usr/bin/perl checking for perl >= 5.8.1... 5.18.2 checking for XML::Parser... ok checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... yes checking for dgettext in libc... yes checking for bind_textdomain_codeset... yes checking for msgfmt... (cached) /usr/bin/msgfmt checking for dcgettext... yes checking if msgfmt accepts -c... yes checking for gmsgfmt... (cached) /usr/bin/msgfmt checking for xgettext... (cached) /usr/bin/xgettext checking for recommended xgettext version (>= 0.19)... no checking for iso-codes... yes checking for BABL... no configure: error: Package requirements (babl >= 0.1.11) were not met: Requested 'babl >= 0.1.11' but version of babl is 0.1.10 Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables BABL_CFLAGS and BABL_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Configure failed or did not finish!
(In reply to antonio montagnani from comment #49) > A further step.....please note that --branch gimp-2.8 gives: > > git clone git://git.gnome.org/gimp --branch gimp-2.8 > Cloning into 'gimp'... > fatal: Il branch remoto gimp-2.8 non è stato trovato in upstream origin The branch name is "gimp-2-8", not "gimp-2.8". > Anyway: [...] > checking for BABL... no > configure: error: Package requirements (babl >= 0.1.11) were not met: > > Requested 'babl >= 0.1.11' but version of babl is 0.1.10 If you want to build GIMP from its master branch, it needs babl and gegl built from their respective master branches as well, i.e. built them like GIMP into the same $PREFIX. Alternatively and perhaps better would be building the 2.8 branch (as you attempted), then it should be sufficient to have the babl-devel and gegl-devel packages installed (instead of cloning again, you can simply switch the branch in the checked out repository: "git checkout gimp-2-8". Either way, you need to symlink the ufraw-gimp plug-in into the new $PREFIX: ln -s /usr/lib64/gimp/2.0/plug-ins/ufraw-gimp "$PREFIX/lib/gimp/2.0/plug-ins"
babl-devel is already installed (0.1.10-8) gegl-devel is already installed (0.2.0-12) Or am I missing what you mean?? Tnx anyway
OK, I think I phrased that badly: - If you want to build the gimp master branch, the packaged babl- and gegl-devel versions are too old. You need to first build their respective master branches and install them into the same prefix as gimp (master). - If you want to build the 2.8.x branch ("gimp-2-8"), having the babl- and gegl-devel packages installed is sufficient. If you have a clone of the gimp repository (e.g. with master checked out), a simple "git checkout gimp-2-8" will create a local tracking branch of that upstream branch and switch to that.
success!!! but opening one of my PEF file is exactly the same as with the RPM-based one from Fedora Repo
i have an additional comment: the first time I started the "new" Gimp (mine compiled version) all .gimp folder was overwritten, so I have to modify again the .pluginrc line in order to have it working with raw files.
(In reply to antonio montagnani from comment #54) > i have an additional comment: the first time I started the "new" Gimp (mine > compiled version) all .gimp folder was overwritten, so I have to modify > again the .pluginrc line in order to have it working with raw files. That's expected -- the plugin executables are new, so the pluginrc gets rewritten to reflect changes.
same behaviour on Fedora 21: so a complete release cycle was not sufficient to fix this issue...
I understand that the bug should be given to ufraw-gimp, and not to gimp or ufraw (from a Gimp support list)
http://sourceforge.net/p/ufraw/bugs/392/ is it connected????
still present in F22 :-(
it seems that with lates updates (still in updates-testing) bug has been cleared Installed Gimp 2.8.14-1.fc22 ufraw-gimp 0.21-1.fc22 ufraw-common.x86_64 0.21-1.fc22
Hi, can you try ufraw-0.22 ? I have built it in copr for F22 and F23 [1], for F24 and rawhide you got official packages . If no issues, can we close this bug with fixed ? Thanks. [1] https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/build/288584/
Closing accordingly.
I prefer mark as duplicated since seems is not completely fixed. *** This bug has been marked as a duplicate of bug 1350210 ***