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 ***