s/there is no apply lens correction/there is no way to apply lens correction

Please read : https://bugzilla.redhat.com/show_bug.cgi?id=1350210 
as workaround I'm building officially without lensfun 
  
This is temporary fix "until we find a fix". 
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787569 and other reports is not just a crash also result in artifacts in some images ... so shouldn't be so easy to fix . 

I just report it upstream: https://sourceforge.net/p/ufraw/bugs/406/

(In reply to Sergio Monteiro Basto from comment #2)
> Please read : https://bugzilla.redhat.com/show_bug.cgi?id=1350210 
> as workaround I'm building officially without lensfun 
>   
> This is temporary fix "until we find a fix". 
> From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787569 and other
> reports is not just a crash also result in artifacts in some images ... so
> shouldn't be so easy to fix . 
> 
> I just report it upstream: https://sourceforge.net/p/ufraw/bugs/406/

Ah, I did not realize that this was done intentionally. It is unfortunate that there is no fix yet; I did not encounter a single crash when I processed 100+ raw photos over the weekend.

Thanks for the pointer; please feel free to close this issue. I will continue to use my local ufraw build in the mean time.

(In reply to Deepak Bhole from comment #3)

> Ah, I did not realize that this was done intentionally. It is unfortunate
> that there is no fix yet; I did not encounter a single crash when I
> processed 100+ raw photos over the weekend.

so you could use ufraw-0.22-1.fc24 [1] without crashes? 

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=766945

or you use ufraw-0.21 ?  ufraw-0.22-1.fc24 and your local build have any difference ? 

> Thanks for the pointer; please feel free to close this issue. I will
> continue to use my local ufraw build in the mean time.

Thanks for the report ...

(In reply to Sergio Monteiro Basto from comment #4)
> (In reply to Deepak Bhole from comment #3)
> 
> > Ah, I did not realize that this was done intentionally. It is unfortunate
> > that there is no fix yet; I did not encounter a single crash when I
> > processed 100+ raw photos over the weekend.
> 
> so you could use ufraw-0.22-1.fc24 [1] without crashes? 
> 
> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=766945
> 
> or you use ufraw-0.21 ?  ufraw-0.22-1.fc24 and your local build have any
> difference ? 
> 

I am using ufraw 0.22-2, which I rebuilt on my F24 system with lensfun-devel installed. Here are the versions:

$ rpm -q ufraw lensfun
ufraw-0.22-2.fc24.x86_64
lensfun-0.3.2-2.fc24.x86_64

No changes were made to the code or to the spec file. I just downloaded the srpm from koji and ran 'rpmbuild --rebuild ufraw-0.22-2.fc24.src.rpm' after making sure that I had lensfun-devel installed.

FWIW, I am using raw images in ARW format from a Sony RX-100 (first gen) camera.

So your package should be equal to ufraw-0.22-1.fc24 [1] the commit for release 2 was [2] , can you test if  ufraw-0.22-1.fc24 works for you ? :/
 

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=766945

[2] 
https://pkgs.fedoraproject.org/cgit/rpms/ufraw.git/commit/?id=87b7b32e620ba0e33cd65ae9e125b68b26d3170c

(In reply to Sergio Monteiro Basto from comment #6)
> So your package should be equal to ufraw-0.22-1.fc24 [1] the commit for
> release 2 was [2] , can you test if  ufraw-0.22-1.fc24 works for you ? :/
>  
> 
> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=766945
> 

I just tried the above packages and processing a couple of images (adjusting lens distortion, WB, Exposure, temperature, gamma, linearity, saturation, contrast and cropping the image) and then saving to jpg. Everything seems to work perfectly fine for me.

Is there anything specific I can try to trigger a crash?

Hey Sergio, I'll second Deepak's question: Do you know of a way to fairly reliably trigger the crash or cause the artifacts? Might involve a certain raw image file, certain lensfun parameters... I don't see any progress upstream or in the Debian bug report and we shouldn't just let this linger.

May we close this bug as duplicated of 1350210 , to me doesn't make sense have 2 bugs discuss the same thing ? 

I don't know what to do , I just want update UFRaw , to fix security issues IIRC 
we have ufraw-0.22-1.fc24 with lensfun and ufraw-0.22-2.fc24 without lensfun , so user can choose , I prefer have less functionalities and less crashes than more functionalities but more issues. 

Deepak could try follow Moravcik usage, of bug #1350210 , to see if can reproduce the bug. 

Anyway feel free to do whatever you want .

Thanks.

(In reply to Sergio Monteiro Basto from comment #9)
> May we close this bug as duplicated of 1350210 , to me doesn't make sense
> have 2 bugs discuss the same thing ? 
> 
> I don't know what to do , I just want update UFRaw , to fix security issues
> IIRC 
> we have ufraw-0.22-1.fc24 with lensfun and ufraw-0.22-2.fc24 without lensfun
> , so user can choose , I prefer have less functionalities and less crashes
> than more functionalities but more issues. 
> 
> Deepak could try follow Moravcik usage, of bug #1350210 , to see if can
> reproduce the bug. 
> 
> Anyway feel free to do whatever you want .
> 
> Thanks.

Hi Sergio,

I just tried it (with an NEF no less, as mentioned in the bug, as I recently bought a new camera :))

Anyway, I am not able to reproduce a crash. I can use ufraw normally and when I hit the gimp button, ufraw closes gracefully and gimp opens. Gimp however does not work as it is unable to load the temporary svg that ufraw creates. On cmdline, I see:

(file-svg:29790): GLib-WARNING **: (gerror.c:405):g_error_new_valist: runtime check failed: (domain != 0)

I don't think that this is related to the ufraw crash though as ufraw seems to exit properly (even when running in gdb, no errant signals detected).

Did you press on cancel ?  seems to me a problem on cancel

Do you mean press cancel at the bottom right? Just tried it, no crash. It exits gracefully.

(In reply to Deepak Bhole from comment #10)
> (In reply to Sergio Monteiro Basto from comment #9)
> > May we close this bug as duplicated of 1350210 , to me doesn't make sense
> > have 2 bugs discuss the same thing ? 
> > 
> > I don't know what to do , I just want update UFRaw , to fix security issues
> > IIRC 
> > we have ufraw-0.22-1.fc24 with lensfun and ufraw-0.22-2.fc24 without lensfun
> > , so user can choose , I prefer have less functionalities and less crashes
> > than more functionalities but more issues. 
> > 
> > Deepak could try follow Moravcik usage, of bug #1350210 , to see if can
> > reproduce the bug. 
> > 
> > Anyway feel free to do whatever you want .
> > 
> > Thanks.
> 
> Hi Sergio,
> 
> I just tried it (with an NEF no less, as mentioned in the bug, as I recently
> bought a new camera :))
> 
> Anyway, I am not able to reproduce a crash. I can use ufraw normally and
> when I hit the gimp button, ufraw closes gracefully and gimp opens. Gimp
> however does not work as it is unable to load the temporary svg that ufraw
> creates. On cmdline, I see:
> 
> (file-svg:29790): GLib-WARNING **: (gerror.c:405):g_error_new_valist:
> runtime check failed: (domain != 0)
> 
> I don't think that this is related to the ufraw crash though as ufraw seems
> to exit properly (even when running in gdb, no errant signals detected).

Hmm that sounds dubious to me, ufraw shouldn't produce SVG files, a vector format. I guess it could rather be that ufraw produces some XML, passes that onto GIMP which wrongly guesses this to be SVG (which is an XML format, too). I'll have to mull over this a bit.

Sergio, yes let's handle the lensfun issue in the other bug.

(In reply to Nils Philippsen from comment #13)
> 
> Hmm that sounds dubious to me, ufraw shouldn't produce SVG files, a vector
> format. I guess it could rather be that ufraw produces some XML, passes that
> onto GIMP which wrongly guesses this to be SVG (which is an XML format,
> too). I'll have to mull over this a bit.
> 

I think that is exactly what is happening. Ufraw produces a *.ufraw file in /tmp and the content of it is an xml file (though a custom one, not an svg). Gimp seems to think that this is an svg for some reason; I am not sure if gimp is expected to know the ufraw xml format at all though.

> Sergio, yes let's handle the lensfun issue in the other bug.

(In reply to Deepak Bhole from comment #14)
> Gimp seems to think that this is an svg for some reason; I am not sure if
> gimp is expected to know the ufraw xml format at all though.

Do you have the ufraw gimp plug-in installed? I guess that would need to be present for this process to work.

(In reply to Nils Philippsen from comment #15)
> (In reply to Deepak Bhole from comment #14)
> > Gimp seems to think that this is an svg for some reason; I am not sure if
> > gimp is expected to know the ufraw xml format at all though.
> 
> Do you have the ufraw gimp plug-in installed? I guess that would need to be
> present for this process to work.

I don't think I do. I tried doing a dns search for it but I cannot find a package that seems to provide it. Does Fedora have the plug-in?

(In reply to Deepak Bhole from comment #16)
> (In reply to Nils Philippsen from comment #15)
> > (In reply to Deepak Bhole from comment #14)
> > > Gimp seems to think that this is an svg for some reason; I am not sure if
> > > gimp is expected to know the ufraw xml format at all though.
> > 
> > Do you have the ufraw gimp plug-in installed? I guess that would need to be
> > present for this process to work.
> 
> I don't think I do. I tried doing a dns search for it but I cannot find a
> package that seems to provide it. Does Fedora have the plug-in?

ufraw-gimp package 

dnf repoquery -i ufraw-gimp 
Summary     : GIMP plugin to retrieve raw image data from digital cameras
Description :
The ufraw-gimp package contains a GIMP plugin for opening raw format images of
digital cameras.


Deepak Bhole, so you use another ufraw-gimp plugin than fedora provides ?

(In reply to Sergio Monteiro Basto from comment #17)
> (In reply to Deepak Bhole from comment #16)
> > (In reply to Nils Philippsen from comment #15)
> > > (In reply to Deepak Bhole from comment #14)
> > > > Gimp seems to think that this is an svg for some reason; I am not sure if
> > > > gimp is expected to know the ufraw xml format at all though.
> > > 
> > > Do you have the ufraw gimp plug-in installed? I guess that would need to be
> > > present for this process to work.
> > 
> > I don't think I do. I tried doing a dns search for it but I cannot find a
> > package that seems to provide it. Does Fedora have the plug-in?
> 
> ufraw-gimp package 
> 
> dnf repoquery -i ufraw-gimp 
> Summary     : GIMP plugin to retrieve raw image data from digital cameras
> Description :
> The ufraw-gimp package contains a GIMP plugin for opening raw format images
> of
> digital cameras.
> 
> 
> Deepak Bhole, so you use another ufraw-gimp plugin than fedora provides ?


I don't have a ufraw/gimp plugin installed atm. I am also unable to find a package for ufraw-gimp:

$ rpm -qa | grep ufraw
ufraw-0.22-1.fc24.x86_64
ufraw-common-0.22-1.fc24.x86_64


$ dnf repoquery -i ufraw-gimp
Last metadata expiration check: 0:00:12 ago on Fri Oct 21 09:57:45 2016.
<nothing else was shown>


$ dnf search ufraw-gimp
Last metadata expiration check: 0:00:27 ago on Fri Oct 21 09:57:45 2016.
Error: No matches found.

Weird

repoquery --qf "%{repoid} %{sourcerpm} %{name}" --releasever=24 --available ufraw-gimp
fedora ufraw-0.22-1.fc24.src.rpm ufraw-gimp
updates ufraw-0.22-2.fc24.src.rpm ufraw-gimp

(In reply to Sergio Monteiro Basto from comment #19)
> Weird
> 
> repoquery --qf "%{repoid} %{sourcerpm} %{name}" --releasever=24 --available
> ufraw-gimp
> fedora ufraw-0.22-1.fc24.src.rpm ufraw-gimp
> updates ufraw-0.22-2.fc24.src.rpm ufraw-gimp

Sorry, it was a dnf config issue on my side :/ I am able to see/install it now.

So after installing, I can still use ufraw+lensfun, and I can launch gimp from ufraw. There are no crashes and gimp now loads the image as expected.

Sergio, Deepak, should or shouldn't this bug be closed as a duplicate of bug #1350210 now?

Bug #1350210 states that a fix patch may be applied soon and lensfun re-enabled. If that is indeed the plan, +1 to closing this as a dupe.

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