Bug 1015796 - Opening raw images with gimp doesn't work anymore
Opening raw images with gimp doesn't work anymore
Status: CLOSED DUPLICATE of bug 1350210
Product: Fedora
Classification: Fedora
Component: ufraw (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-05 10:50 EDT by antonio montagnani
Modified: 2016-10-30 13:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-23 08:39:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
plugin configuration file (276.48 KB, text/plain)
2013-10-08 12:10 EDT, antonio montagnani
no flags Details
test case (9.81 MB, image/x-pentax-pef)
2013-10-08 12:13 EDT, antonio montagnani
no flags Details
Screenshot when using Gimp (264.66 KB, image/png)
2013-10-09 11:49 EDT, antonio montagnani
no flags Details
another screen shot (17.85 KB, image/png)
2013-10-09 11:50 EDT, antonio montagnani
no flags Details
screenshot when I use Gimp+Ufraw as plugin (165.47 KB, image/png)
2014-04-30 16:50 EDT, antonio montagnani
no flags Details
test case as per needinfo (9.54 KB, text/plain)
2014-05-05 12:18 EDT, antonio montagnani
no flags Details
second test case on second system (7.67 KB, text/plain)
2014-05-05 12:32 EDT, antonio montagnani
no flags Details

  None (edit)
Description antonio montagnani 2013-10-05 10:50:14 EDT
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
Comment 1 antonio montagnani 2013-10-05 11:06:35 EDT
the only  working release is 0.19.2-2, also intermediate releases are no good
Comment 2 Nils Philippsen 2013-10-08 11:29:55 EDT
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.
Comment 3 antonio montagnani 2013-10-08 12:05:20 EDT
My raw image is coming from Pentax gear,i.e. is *.pef
Comment 4 antonio montagnani 2013-10-08 12:10:19 EDT
Created attachment 809395 [details]
plugin configuration file
Comment 5 antonio montagnani 2013-10-08 12:13:14 EDT
Created attachment 809396 [details]
test case
Comment 6 antonio montagnani 2013-10-08 12:14:42 EDT
gimp-2.8.6-3.fc19.i686
Comment 7 Nils Philippsen 2013-10-09 05:19:12 EDT
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.
Comment 8 Nils Philippsen 2013-10-09 09:15:04 EDT
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?
Comment 9 antonio montagnani 2013-10-09 11:49:10 EDT
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
Comment 10 antonio montagnani 2013-10-09 11:50:51 EDT
Created attachment 810015 [details]
another screen shot

see also this screen-shot

Please note that Ufraw standalone works fine
Comment 11 antonio montagnani 2013-10-09 12:29:01 EDT
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
Comment 12 antonio montagnani 2013-10-10 06:22:32 EDT
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
Comment 13 f.pasquarelli 2013-10-11 08:17:12 EDT
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
Comment 14 antonio montagnani 2013-10-11 08:45:43 EDT
happy not be alone.
Comment 15 f.pasquarelli 2013-10-14 07:57:04 EDT
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")
Comment 16 antonio montagnani 2013-10-14 09:13:15 EDT
I confirm that this workaround works flawlessly: of course it is not system wide ;-)
Comment 17 f.pasquarelli 2013-10-15 04:22:14 EDT
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
Comment 18 Nils Philippsen 2013-10-15 06:00:11 EDT
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).
Comment 19 f.pasquarelli 2013-10-16 02:45:17 EDT
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
Comment 20 f.pasquarelli 2013-10-16 03:34:35 EDT
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.
Comment 21 antonio montagnani 2014-03-14 17:39:27 EDT
is anybody working on it??
Comment 22 antonio montagnani 2014-04-27 11:20:09 EDT
ufraw-0.19.2-12.20140414cvs.fc20.x86_64 doesn't fix this bug while fixes Bug 1043854
Comment 23 Nils Philippsen 2014-04-30 08:59:40 EDT
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.
Comment 24 antonio montagnani 2014-04-30 09:43:37 EDT
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
Comment 25 Nils Philippsen 2014-04-30 11:32:11 EDT
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.
Comment 26 antonio montagnani 2014-04-30 16:50:02 EDT
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???
Comment 27 Nils Philippsen 2014-05-05 09:23:24 EDT
(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
Comment 28 Nils Philippsen 2014-05-05 09:24:26 EDT
Oh, the command is one single line only (BZ broke it up).
Comment 29 antonio montagnani 2014-05-05 12:18:54 EDT
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
Comment 30 antonio montagnani 2014-05-05 12:32:14 EDT
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
Comment 31 antonio montagnani 2014-05-05 13:27:48 EDT
in usr/lib64/gimp2.0 gimp-ufraw is defined as (application/x-executable).

Is it correct???
Comment 32 Nils Philippsen 2014-06-03 11:42:01 EDT
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
Comment 33 antonio montagnani 2014-06-03 15:59:21 EDT
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) ??
Comment 34 Nils Philippsen 2014-06-06 05:59:10 EDT
(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.
Comment 35 antonio montagnani 2014-06-06 06:10:18 EDT
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
Comment 36 antonio montagnani 2014-06-06 06:14:06 EDT
prelink is installed (0.5.0-1.fc20)
Comment 37 antonio montagnani 2014-06-06 06:15:59 EDT
if I remove prelink everything seems to be working !!!!
Comment 38 antonio montagnani 2014-06-06 06:17:01 EDT
please do not consider comment #37
Comment 39 Nils Philippsen 2014-06-10 09:16:17 EDT
(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)?
Comment 40 antonio montagnani 2014-06-10 09:45:53 EDT
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)
Comment 41 Nils Philippsen 2014-06-12 05:43:30 EDT
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.
Comment 42 antonio montagnani 2014-06-14 06:27:28 EDT
Not familiar with building GIMP from sources - it could be a good chance to learn :-)

Comment #19 should be a good starting point
Comment 43 Nils Philippsen 2014-06-17 11:00:06 EDT
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!
Comment 44 antonio montagnani 2014-07-01 03:09:27 EDT
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.
Comment 45 Nils Philippsen 2014-07-01 09:17:19 EDT
Did you manage to build GIMP from source?
Comment 46 antonio montagnani 2014-07-02 07:56:22 EDT
yes, but I am waiting for the friend to give more infos after joining Bugzilla, as he actually did the job on his computer
Comment 47 antonio montagnani 2014-07-12 16:32:49 EDT
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.
Comment 48 antonio montagnani 2014-07-12 17:19:38 EDT
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]$
Comment 49 antonio montagnani 2014-07-12 17:41:59 EDT
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!
Comment 50 Nils Philippsen 2014-07-14 08:14:56 EDT
(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"
Comment 51 antonio montagnani 2014-07-14 09:00:14 EDT

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
Comment 52 Nils Philippsen 2014-07-14 12:09:38 EDT
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.
Comment 53 antonio montagnani 2014-07-14 16:56:26 EDT
success!!! but opening one of my PEF file is exactly the same as with the RPM-based one from Fedora Repo
Comment 54 antonio montagnani 2014-07-14 17:11:36 EDT
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.
Comment 55 Nils Philippsen 2014-07-16 07:02:08 EDT
(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.
Comment 56 antonio montagnani 2014-12-09 14:51:52 EST
same behaviour on Fedora 21: so a complete release cycle was not sufficient to fix this issue...
Comment 57 antonio montagnani 2014-12-12 18:38:43 EST
I understand that the bug should be given to ufraw-gimp, and not to gimp or ufraw (from a Gimp support list)
Comment 58 antonio montagnani 2014-12-12 18:53:46 EST
http://sourceforge.net/p/ufraw/bugs/392/

is it connected????
Comment 59 antonio montagnani 2015-05-27 05:04:37 EDT
still present in F22 :-(
Comment 60 antonio montagnani 2015-06-03 12:33:50 EDT
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
Comment 61 Sergio Monteiro Basto 2016-05-19 12:22:20 EDT
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/
Comment 62 Nils Philippsen 2016-05-23 08:39:01 EDT
Closing accordingly.
Comment 63 Sergio Monteiro Basto 2016-10-30 13:44:52 EDT
I prefer mark as duplicated since seems is not completely fixed.

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

Note You need to log in before you can comment on or make changes to this bug.