Ufraw fix:

Download and compile dcraw current:

http://www.cybercom.net/~dcoffin/dcraw/

using

http://www.cybercom.net/~dcoffin/dcraw/dcraw.c

and from that URL,

gcc -o dcraw -O4 dcraw.c -lm -DNODEPS

works on SL6x

Next,

Download and install into gimp the file rawphoto.c

http://www.cybercom.net/%7Edcoffin/dcraw/rawphoto.c

After installing "dcraw", do "gimptool --install rawphoto.c

You will need to have installed the rpm containing gimptool; this can be 
gotten through the standard add/remove software GUI tool under System 
--> Administration from the top bar of the standard gnome GUI.

Note:

 From the dcraw URL:

My plugin provides a simple dialog box for loading raw files into the 
Gimp. Udi Fuchs and Joseph Heled have written much nicer plugins, with 
live preview, histograms, and color curves.

End quote.  If someone has the time,  one may try to build the current 
ufraw (the Udi Fuchs gimp plugin mentioned above), either from the 
src.rpm or from

http://ufraw.sourceforge.net/

At the moment, the dcraw workaround seems to be functioning for our 
immediate need; however, I would appreciate the current (latest 
production source) ufraw plugin if this is available.  Also, if someone 
finds the Joseph Heled plugin and can build it, this might be a 
worthwhile comparison.

Yasha Karant


On 06/17/2013 08:45 AM, Yasha Karant wrote:
> On 06/17/2013 07:07 AM, David Sommerseth wrote:
>> On 16/06/13 17:31, Akemi Yagi wrote:
>>> On Sun, Jun 16, 2013 at 7:52 AM, Yasha Karant <[log in to unmask]> wrote:
>>>> I need the current ufraw plugin plus support files for gimp.
>>>>
>>>> I could find:  ufraw-0.19.2-2.fc17.1 rpm
>>>>
>>>> for Fedora 17, but this will not install into SL 6x .  According to the
>>>> ufraw URL, the above ufraw release does support the raw digital image
>>>> formats we need.
>>>>
>>>> Yasha Karant
>>>
>>> NuxRo's repo has ufraw 0.18-2:
>>>
>>> http://pkgs.org/search/?keyword=ufraw
>>>
>>> If you need 0.19, try compiling it from the fc17 source. There might
>>> be some dependency issue though.
>>
>> Just what I would suggest as well.  Pull down the src.rpm package and do:
>>
>>      $ rpmbuild --rebuild $SRC_RPM
>>
>> This will be some iterations to get proper -devel packages installed.
>> But if you start to need other source packages, then it will be
>> considerably harder - as that may break your SL installation if you
>> update some commonly shared libraries.
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>>
>
> Let me approach this general issue from a different point.  None of the
> linux systems designs easily enable proper encapsulation and
> polymorphism, as the above comment illustrates (that may break your SL
> installation if you update some commonly shared libraries, end quote).
>
> Can one build an application (in this case, GIMP "plug in") to use only
> static libraries within a unique build tree that does not overlap with
> the standard SL installation?
>
> Unless the incompatibility is at the kernel, Xwindows, etc., API level,
> then a fully static (in open systems parlance, not .so, but .a
> libraries) implementation should work.  Such a static image could
> require considerably more memory (both RAM for execution as well a mass
> storage for the image), but should not interfere with the standard SL
> (SL Nx, currently N = 6).
>
> If such a static "isolated" build is possible within SL, are there any
> tools/packages/scripts that more easily enable such an approach?
>
> Yasha Karant