that's not true, we call libraw_dcraw_process() (not c++ and not document
mode), but we set params.document_mode = 2 before that.
j.
On Thu, Jun 6, 2013 at 12:21 PM, Michael Born wrote:
> I posted in the libraw developers blog that darktable needs the
> LibRaw::dcraw_document_mode_processing
>
I posted in the libraw developers blog that darktable needs the
LibRaw::dcraw_document_mode_processing
Is there anything more that is required for darktable and was removed?
Cheers,
Michael
Am 06.06.2013 10:04, schrieb Michael Born:
> Why not talk to the libraw maintainers? They seem not to be a
Hi.
On Thu, 2013-06-06 at 09:29 +1200, johannes hanika wrote:
>
> i was under the impression that came only up in 15.0+, which we never
> updated to.
Absolutely correct impression.
http://blog.lexa.ru/2013/05/28/o_spiskakh_uyazvimostei_v_programmakh.html
Sorry, in russian (alex tutubalin blog
Why not talk to the libraw maintainers? They seem not to be aware that
darktable uses the functionality.
Michael
Am 05.06.2013 22:08, schrieb johannes hanika:
> changelog:
> [..]
> API changes:
> [..]
> 2. deleted (nobody uses those)
>- LibRaw::dcraw_document_mode_processing (and respectiv
2013/6/5 Togan Muftuoglu :
> On 06/05/2013 10:56 PM, jeremy rosen wrote:
>> IIUC what hanatos said, it's not just a question of adapting. upstream has
>> removed features that we need.
>>
>> so either we drop libraw entirely or we fork it entirely, but we can't use
>> upstream because upstream has
On Thu, Jun 6, 2013 at 9:14 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:56 PM, jeremy rosen wrote:
> > IIUC what hanatos said, it's not just a question of adapting. upstream
> has
> > removed features that we need.
> >
> > so either we drop libraw entirely or we f
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
i'll look into adding a compile switch to build without it, if that
resolves your packaging concerns. it'll remove a couple of features though.
j.
On Thu, Jun 6, 2013 at 9:08 AM, Togan Muftuoglu <
[email protected]> wrote:
> On
On 06/05/2013 10:56 PM, jeremy rosen wrote:
> IIUC what hanatos said, it's not just a question of adapting. upstream has
> removed features that we need.
>
> so either we drop libraw entirely or we fork it entirely, but we can't use
> upstream because upstream has droped features we need.
>
> thi
On 06/05/2013 10:51 PM, johannes hanika wrote:
> On Thu, Jun 6, 2013 at 8:45 AM, Togan Muftuoglu <
>> If maintaining the fork is not worth maintaining, how about keeping upto
>> date with the current libraw, meaning adapting the code.
>>
>
> let me repeat this, they removed features we depended on
IIUC what hanatos said, it's not just a question of adapting. upstream has
removed features that we need.
so either we drop libraw entirely or we fork it entirely, but we can't use
upstream because upstream has droped features we need.
this is not a chage of API this is a change of feature
On W
On Thu, Jun 6, 2013 at 8:45 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:28 PM, johannes hanika wrote:
> > On Thu, Jun 6, 2013 at 8:23 AM, Togan Muftuoglu <
> > [email protected]> wrote:
> >
> >> On 06/05/2013 10:15 PM, johannes hanika wrote:
> >>> just
On 06/05/2013 10:28 PM, johannes hanika wrote:
> On Thu, Jun 6, 2013 at 8:23 AM, Togan Muftuoglu <
> [email protected]> wrote:
>
>> On 06/05/2013 10:15 PM, johannes hanika wrote:
>>> just for reference, it might be possible that reverting half of this
>> could
>>> make it work again.
>>
On Thu, Jun 6, 2013 at 8:23 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:15 PM, johannes hanika wrote:
> > just for reference, it might be possible that reverting half of this
> could
> > make it work again.
> >
> > a91165396a0a7b41e6f08847a5ac932110ae4ff8
> >
>
>
On 06/05/2013 10:15 PM, johannes hanika wrote:
> just for reference, it might be possible that reverting half of this could
> make it work again.
>
> a91165396a0a7b41e6f08847a5ac932110ae4ff8
>
You lost me here this belongs to which git darktable or Libraw
On Thu, Jun 6, 2013 at 8:14 AM, Togan Muftuoglu <
[email protected]> wrote:
> On 06/05/2013 10:08 PM, johannes hanika wrote:
> > changelog:
> > [..]
> > API changes:
> > [..]
> > 2. deleted (nobody uses those)
> >- LibRaw::dcraw_document_mode_processing (and respective C-API)
> >
just for reference, it might be possible that reverting half of this could
make it work again.
a91165396a0a7b41e6f08847a5ac932110ae4ff8
j.
On Thu, Jun 6, 2013 at 8:08 AM, johannes hanika wrote:
> changelog:
> [..]
> API changes:
> [..]
> 2. deleted (nobody uses those)
>- LibRaw::dcraw_d
On 06/05/2013 10:08 PM, johannes hanika wrote:
> changelog:
> [..]
> API changes:
> [..]
> 2. deleted (nobody uses those)
>- LibRaw::dcraw_document_mode_processing (and respective C-API)
>- [..]
>
> which means we can't update any more.
>
So how about providing an option to disable t
changelog:
[..]
API changes:
[..]
2. deleted (nobody uses those)
- LibRaw::dcraw_document_mode_processing (and respective C-API)
- [..]
which means we can't update any more.
j.
On Thu, Jun 6, 2013 at 2:51 AM, Togan Muftuoglu <
[email protected]> wrote:
> Tere's a double-fre
Tere's a double-free (fixed in 0.15.2[3]) and a buffer overflow
(fixed in 0.15.1[2]).
References:
[1]http://www.libraw.org/download
[2]http://www.libraw.org/news/libraw-0-15-1
[3]http://www.libraw.org/news/libraw-0-15-2
http://secunia.com/advisories/53547/
https://bugzilla.novell.com/show_bug.cg
19 matches
Mail list logo
