Debian Bug report logs - #682980
darktable: should use system shared libraw

version graph

Package: darktable; Maintainer for darktable is Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>; Source for darktable is src:darktable.

Reported by: Jonas Smedegaard <dr@jones.dk>

Date: Fri, 27 Jul 2012 16:03:01 UTC

Severity: normal

Tags: moreinfo, wontfix

Found in version darktable/1.0.5-1

Done: David Bremner <bremner@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>:
Bug#682980; Package darktable. (Fri, 27 Jul 2012 16:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
New Bug report received and forwarded. Copy sent to Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>. (Fri, 27 Jul 2012 16:03:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Jonas Smedegaard <dr@jones.dk>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: darktable: should use system shared libraw
Date: Fri, 27 Jul 2012 18:02:16 +0200
Package: darktable
Version: 1.0.5-1
Severity: normal

Apparently (judging from latest upstream release changelog) darktable
uses libraw, but does not link against the system shared library as
documented at a "should" in Debian Policy §4.13.

 - Jonas



Added blocking bug(s) of 682980: 682982 Request was from David Bremner <bremner@debian.org> to control@bugs.debian.org. (Fri, 27 Jul 2012 17:42:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>:
Bug#682980; Package darktable. (Fri, 27 Jul 2012 17:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list. Copy sent to Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>. (Fri, 27 Jul 2012 17:57:07 GMT) Full text and rfc822 format available.

Message #12 received at 682980@bugs.debian.org (full text, mbox):

From: Jonas Smedegaard <dr@jones.dk>
To: David Bremner <david@tethera.net>
Cc: 682980@bugs.debian.org, Debian Shotwell Maintainers <pkg-shotwell-maint@lists.alioth.debian.org>
Subject: Re: [Pkg-phototools-devel] Bug#682980: darktable: should use system shared libraw
Date: Fri, 27 Jul 2012 19:56:10 +0200
[Message part 1 (text/plain, inline)]
On 12-07-27 at 02:28pm, David Bremner wrote:
> Jonas Smedegaard <dr@jones.dk> writes:
> 
> > Apparently (judging from latest upstream release changelog) 
> > darktable uses libraw, but does not link against the system shared 
> > library as documented at a "should" in Debian Policy §4.13.
> 
> Hi Jonas;
> 
> It's a good point, but as usual there are a few problems to be 
> overcome.
> 
> 1) the embedded copy currently leads the version in Debian by one
>    upstream release. I filed a wishlist bug 682982 asking for an upgrade
>    before I learned the following 

Ok, but do darktable really _require_ newest version of libraw?


> 2) The version in darktable is actually patched, in some way that seems
>    incompatible with upstream.  I don't know the details of this yet,
>    but I'm not too hopeful after chatting with upstream.

Indeed.  A diff between upstream LibRaw and the convenience copy shipped 
with darkroom reveals these 3 lines of difference:

+++ internal/dcraw_common.cpp<->2012-07-21 12:44:08.000000000 +0200
--- /home/jonas/src/tmp/darktable/LibRaw-0.14.7/internal/dcraw_common.cpp<----->2012-06-27 18:39:
@@ -5904,8 +5904,6 @@
       || (tiff_bps == 8 && !strstr(make,"KODAK") && !strstr(make,"Kodak") &&
 <----->  !strstr(model2,"DEBUG RAW")))
       is_raw = 0;
+  if(dng_version && max_bps > 16)
+      is_raw = 0;
   for (i=0; i < tiff_nifds; i++)
     if (i != raw && tiff_ifd[i].samples == max_samp && tiff_ifd[i].offset && tiff_ifd[i].bytes &&
 <----->tiff_ifd[i].t_width * tiff_ifd[i].t_height / SQR(tiff_ifd[i].bps+1) >


Even if upstreams could not be persuaded to carry that change, it does 
not seem unlikely to me that Debian maintainers of libraw might perhaps 
be convinced to include a patch that added above as an ifdef which 
darktable could then make use of - if it does not turn out to be 
harmless to include in all cases (I don't know the code well enough to 
judge).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>:
Bug#682980; Package darktable. (Fri, 27 Jul 2012 18:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Bremner <david@tethera.net>:
Extra info received and forwarded to list. Copy sent to Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>. (Fri, 27 Jul 2012 18:12:03 GMT) Full text and rfc822 format available.

Message #17 received at 682980@bugs.debian.org (full text, mbox):

From: David Bremner <david@tethera.net>
To: Jonas Smedegaard <dr@jones.dk>, 682980@bugs.debian.org
Cc: Debian Shotwell Maintainers <pkg-shotwell-maint@lists.alioth.debian.org>
Subject: Re: [Pkg-phototools-devel] Bug#682980: darktable: should use system shared libraw
Date: Fri, 27 Jul 2012 14:28:04 -0300
Jonas Smedegaard <dr@jones.dk> writes:

> Apparently (judging from latest upstream release changelog) darktable
> uses libraw, but does not link against the system shared library as
> documented at a "should" in Debian Policy §4.13.

Hi Jonas;

It's a good point, but as usual there are a few problems to be overcome.

1) the embedded copy currently leads the version in Debian by one
   upstream release. I filed a wishlist bug 682982 asking for an upgrade
   before I learned the following 

2) The version in darktable is actually patched, in some way that seems
   incompatible with upstream.  I don't know the details of this yet,
   but I'm not too hopeful after chatting with upstream.

d



Message sent on to Jonas Smedegaard <dr@jones.dk>:
Bug#682980. (Fri, 27 Jul 2012 20:12:05 GMT) Full text and rfc822 format available.

Message #20 received at 682980-submitter@bugs.debian.org (full text, mbox):

From: Pascal de Bruijn <pmjdebruijn@pcode.nl>
To: 682980-submitter@bugs.debian.org
Subject: darktable: should use system shared libraw
Date: Fri, 27 Jul 2012 22:08:33 +0200
Linking Darktable against the debian supplied Libraw is a bad idea
(regardless of patches)

We, the Darktable team, release specific versions of Darktable with
specific versions of LibRaw. As the specific versions of RawSpeed and
LibRaw significantly affect which camera's Darktable supports (which
are often listed specifically in our release notes), so it's quite
important to use the versions we actually ship.

When Darktable is linked against an external Libraw (or for that
matter RawSpeed) library, we likely would get lots of camera support
bugs which aren't reproducible (assuming the Debian Libraw version is
older), wasting our time. Or we aren't getting any valid camera
support bugs reported (assuming the Debian Libraw version is newer).
So both cases (newer and older) are detrimental to our project.

And even assuming you'd ship the same of Libraw as the current release
of Darktable ships, another project might "need" another specific
version of LibRaw, effectively creating a version conflict.

So in my opinion Darktable should get a permanent exception to this
Debian policy.

Regards,
Pascal de Bruijn

PS: Please don't misunderstand, I generally agree with the policy in
this regard, it's just that it makes very little sense for projects
like Darktable.



Information stored :
Bug#682980; Package darktable. (Fri, 27 Jul 2012 22:33:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and filed, but not forwarded. (Fri, 27 Jul 2012 22:33:09 GMT) Full text and rfc822 format available.

Message #25 received at 682980-quiet@bugs.debian.org (full text, mbox):

From: Jonas Smedegaard <dr@jones.dk>
To: Pascal de Bruijn <pmjdebruijn@pcode.nl>, 682980-quiet@bugs.debian.org
Subject: Re: Bug#682980: darktable: should use system shared libraw
Date: Sat, 28 Jul 2012 00:28:22 +0200
[Message part 1 (text/plain, inline)]
Hi Pascal,

On 12-07-27 at 10:08pm, Pascal de Bruijn wrote:
> Linking Darktable against the debian supplied Libraw is a bad idea 
> (regardless of patches)
> 
> We, the Darktable team, release specific versions of Darktable with 
> specific versions of LibRaw. As the specific versions of RawSpeed and 
> LibRaw significantly affect which camera's Darktable supports (which 
> are often listed specifically in our release notes), so it's quite 
> important to use the versions we actually ship.
> 
> When Darktable is linked against an external Libraw (or for that 
> matter RawSpeed) library, we likely would get lots of camera support 
> bugs which aren't reproducible (assuming the Debian Libraw version is 
> older), wasting our time. Or we aren't getting any valid camera 
> support bugs reported (assuming the Debian Libraw version is newer). 
> So both cases (newer and older) are detrimental to our project.

Bugs from users of Debian should go to Debian for this exact reason: The 
Debian package maintainers should pass upstream to you the Darktable 
developers only bugs relevant for you.


> And even assuming you'd ship the same of Libraw as the current release 
> of Darktable ships, another project might "need" another specific 
> version of LibRaw, effectively creating a version conflict.

Thanks for your concern, but we are dealing with this already in Debian.


> So in my opinion Darktable should get a permanent exception to this
> Debian policy.
> 
> Regards,
> Pascal de Bruijn
> 
> PS: Please don't misunderstand, I generally agree with the policy in
> this regard, it's just that it makes very little sense for projects
> like Darktable.

Sorry, but I fail to see how this issue is any different from e.g. 
consumers of libexiv and the resulting changes to richness of the EXIF 
data supported with various versions of that library: as long as the API 
is the same, newest version of the library most often is preferred.

If I misunderstood and there is really something more intimate going on 
specifically with Darktable and its libraries could you please try 
elaborate more on that?


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
[signature.asc (application/pgp-signature, inline)]

Information stored :
Bug#682980; Package darktable. (Fri, 27 Jul 2012 22:45:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Pascal de Bruijn <pmjdebruijn@pcode.nl>:
Extra info received and filed, but not forwarded. (Fri, 27 Jul 2012 22:45:10 GMT) Full text and rfc822 format available.

Message #30 received at 682980-quiet@bugs.debian.org (full text, mbox):

From: Pascal de Bruijn <pmjdebruijn@pcode.nl>
To: Jonas Smedegaard <dr@jones.dk>
Cc: 682980-quiet@bugs.debian.org
Subject: Re: Bug#682980: darktable: should use system shared libraw
Date: Sat, 28 Jul 2012 00:42:19 +0200
On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard <dr@jones.dk> wrote:
> Hi Pascal,
>
> On 12-07-27 at 10:08pm, Pascal de Bruijn wrote:
>> Linking Darktable against the debian supplied Libraw is a bad idea
>> (regardless of patches)
>>
>> We, the Darktable team, release specific versions of Darktable with
>> specific versions of LibRaw. As the specific versions of RawSpeed and
>> LibRaw significantly affect which camera's Darktable supports (which
>> are often listed specifically in our release notes), so it's quite
>> important to use the versions we actually ship.
>>
>> When Darktable is linked against an external Libraw (or for that
>> matter RawSpeed) library, we likely would get lots of camera support
>> bugs which aren't reproducible (assuming the Debian Libraw version is
>> older), wasting our time. Or we aren't getting any valid camera
>> support bugs reported (assuming the Debian Libraw version is newer).
>> So both cases (newer and older) are detrimental to our project.
>
> Bugs from users of Debian should go to Debian for this exact reason: The
> Debian package maintainers should pass upstream to you the Darktable
> developers only bugs relevant for you.

Yeah, but that's not reality. People will just come and ask on our
mailing lists and irc channels, often not telling us they are running
Debian (unless we specifically ask), wasting our time.

>> And even assuming you'd ship the same of Libraw as the current release
>> of Darktable ships, another project might "need" another specific
>> version of LibRaw, effectively creating a version conflict.
>
> Thanks for your concern, but we are dealing with this already in Debian.
>
>> So in my opinion Darktable should get a permanent exception to this
>> Debian policy.
>>
>> PS: Please don't misunderstand, I generally agree with the policy in
>> this regard, it's just that it makes very little sense for projects
>> like Darktable.
>
> Sorry, but I fail to see how this issue is any different from e.g.
> consumers of libexiv and the resulting changes to richness of the EXIF

Having an older libexiv2 will not prevent files from being read at
all. Having an old libraw could result in images being "green" instead
of properly white balanced in some cases. And in even fewer cases it
could result in files not loading at all (where they should have just
loaded just fine (and/or not being green) with unpatched darktable
sources).

> data supported with various versions of that library: as long as the API
> is the same, newest version of the library most often is preferred.

Yes, but that isn't what happens in reality. What happens in reality
is that Debian is usually behind, really...

> If I misunderstood and there is really something more intimate going on
> specifically with Darktable and its libraries could you please try
> elaborate more on that?

With regard to the patch, LibRaw does RAW reading _and_ processing, we
only use the RAW reading bits (which is fairly atypical). But the
LibRaw processing bits don't support float DNGs (which we use for HDR
IIRC), so the LibRaw authors are blocking them from being read. So we
need to patch that up for our particular use.

Besides the above, there is nothing more intimate going on, except
that I see lots of potential problems, with little or no gain at all
in our particular case.

Regards,
Pascal de Bruijn



Information stored :
Bug#682980; Package darktable. (Sat, 28 Jul 2012 00:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and filed, but not forwarded. (Sat, 28 Jul 2012 00:27:06 GMT) Full text and rfc822 format available.

Message #35 received at 682980-quiet@bugs.debian.org (full text, mbox):

From: Jonas Smedegaard <dr@jones.dk>
To: Pascal de Bruijn <pmjdebruijn@pcode.nl>, 682980-quiet@bugs.debian.org
Subject: Re: Bug#682980: darktable: should use system shared libraw
Date: Sat, 28 Jul 2012 02:26:10 +0200
[Message part 1 (text/plain, inline)]
On 12-07-28 at 12:42am, Pascal de Bruijn wrote:
> On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard <dr@jones.dk> wrote:
> > On 12-07-27 at 10:08pm, Pascal de Bruijn wrote:
> >> When Darktable is linked against an external Libraw (or for that 
> >> matter RawSpeed) library, we likely would get lots of camera 
> >> support bugs which aren't reproducible (assuming the Debian Libraw 
> >> version is older), wasting our time. Or we aren't getting any valid 
> >> camera support bugs reported (assuming the Debian Libraw version is 
> >> newer). So both cases (newer and older) are detrimental to our 
> >> project.
> >
> > Bugs from users of Debian should go to Debian for this exact reason: 
> > The Debian package maintainers should pass upstream to you the 
> > Darktable developers only bugs relevant for you.
> 
> Yeah, but that's not reality. People will just come and ask on our 
> mailing lists and irc channels, often not telling us they are running 
> Debian (unless we specifically ask), wasting our time.

I recognize that issue from users of Debian reporting bugs about 
packages derived from Debian but changed in various ways unknown to us.

What I do with that is not try enforce one single use of the packages we 
provide, but a) tell our users that they are free to use Debian also in 
(to us) weird ways (that's one of the freedoms that DFSG-free licensing 
provides!), but b) they are strongly recommended to tell us very clearly 
up front when reporting bugs if their setup of Debian is unusual, to not 
waste our time e.g. chasing bugs inefficiently.



> >> So in my opinion Darktable should get a permanent exception to this 
> >> Debian policy.
> >>
> >> PS: Please don't misunderstand, I generally agree with the policy 
> >> in this regard, it's just that it makes very little sense for 
> >> projects like Darktable.
> >
> > Sorry, but I fail to see how this issue is any different from e.g. 
> > consumers of libexiv and the resulting changes to richness of the 
> > EXIF
> 
> Having an older libexiv2 will not prevent files from being read at 
> all. Having an old libraw could result in images being "green" instead 
> of properly white balanced in some cases. And in even fewer cases it 
> could result in files not loading at all (where they should have just 
> loaded just fine (and/or not being green) with unpatched darktable 
> sources).
> 
> > data supported with various versions of that library: as long as the 
> > API is the same, newest version of the library most often is 
> > preferred.
> 
> Yes, but that isn't what happens in reality. What happens in reality 
> is that Debian is usually behind, really...
> 
> > If I misunderstood and there is really something more intimate going 
> > on specifically with Darktable and its libraries could you please 
> > try elaborate more on that?
> 
> With regard to the patch, LibRaw does RAW reading _and_ processing, we 
> only use the RAW reading bits (which is fairly atypical). But the 
> LibRaw processing bits don't support float DNGs (which we use for HDR 
> IIRC), so the LibRaw authors are blocking them from being read. So we 
> need to patch that up for our particular use.
> 
> Besides the above, there is nothing more intimate going on, except 
> that I see lots of potential problems, with little or no gain at all 
> in our particular case.

Thanks for the details.

It still sound to me like Darktable would make good sense to link 
against shared libraries for Debian.


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
[signature.asc (application/pgp-signature, inline)]

Information stored :
Bug#682980; Package darktable. (Sat, 28 Jul 2012 10:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Pascal de Bruijn <pmjdebruijn@pcode.nl>:
Extra info received and filed, but not forwarded. (Sat, 28 Jul 2012 10:12:03 GMT) Full text and rfc822 format available.

Message #40 received at 682980-quiet@bugs.debian.org (full text, mbox):

From: Pascal de Bruijn <pmjdebruijn@pcode.nl>
To: Jonas Smedegaard <dr@jones.dk>
Cc: 682980-quiet@bugs.debian.org
Subject: Re: Bug#682980: darktable: should use system shared libraw
Date: Sat, 28 Jul 2012 12:09:03 +0200
On Sat, Jul 28, 2012 at 2:26 AM, Jonas Smedegaard <dr@jones.dk> wrote:
> On 12-07-28 at 12:42am, Pascal de Bruijn wrote:
>> On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard <dr@jones.dk> wrote:
>> > On 12-07-27 at 10:08pm, Pascal de Bruijn wrote:
>> >> When Darktable is linked against an external Libraw (or for that
>> >> matter RawSpeed) library, we likely would get lots of camera
>> >> support bugs which aren't reproducible (assuming the Debian Libraw
>> >> version is older), wasting our time. Or we aren't getting any valid
>> >> camera support bugs reported (assuming the Debian Libraw version is
>> >> newer). So both cases (newer and older) are detrimental to our
>> >> project.
>> >
>> > Bugs from users of Debian should go to Debian for this exact reason:
>> > The Debian package maintainers should pass upstream to you the
>> > Darktable developers only bugs relevant for you.
>>
>> Yeah, but that's not reality. People will just come and ask on our
>> mailing lists and irc channels, often not telling us they are running
>> Debian (unless we specifically ask), wasting our time.
>
> I recognize that issue from users of Debian reporting bugs about
> packages derived from Debian but changed in various ways unknown to us.
>
> What I do with that is not try enforce one single use of the packages we
> provide, but a) tell our users that they are free to use Debian also in
> (to us) weird ways (that's one of the freedoms that DFSG-free licensing
> provides!), but b) they are strongly recommended to tell us very clearly
> up front when reporting bugs if their setup of Debian is unusual, to not
> waste our time e.g. chasing bugs inefficiently.

I guess that's a similar issue.

However, there is a difference with users personally modifying things.
And distributions shipping non-standard versions.

We'd like to make sure that users get a user experience that is
representative of our intended Darktable user experience.

>> >> So in my opinion Darktable should get a permanent exception to this
>> >> Debian policy.
>> >>
>> >> PS: Please don't misunderstand, I generally agree with the policy
>> >> in this regard, it's just that it makes very little sense for
>> >> projects like Darktable.
>> >
>> > Sorry, but I fail to see how this issue is any different from e.g.
>> > consumers of libexiv and the resulting changes to richness of the
>> > EXIF
>>
>> Having an older libexiv2 will not prevent files from being read at
>> all. Having an old libraw could result in images being "green" instead
>> of properly white balanced in some cases. And in even fewer cases it
>> could result in files not loading at all (where they should have just
>> loaded just fine (and/or not being green) with unpatched darktable
>> sources).
>>
>> > data supported with various versions of that library: as long as the
>> > API is the same, newest version of the library most often is
>> > preferred.
>>
>> Yes, but that isn't what happens in reality. What happens in reality
>> is that Debian is usually behind, really...
>>
>> > If I misunderstood and there is really something more intimate going
>> > on specifically with Darktable and its libraries could you please
>> > try elaborate more on that?
>>
>> With regard to the patch, LibRaw does RAW reading _and_ processing, we
>> only use the RAW reading bits (which is fairly atypical). But the
>> LibRaw processing bits don't support float DNGs (which we use for HDR
>> IIRC), so the LibRaw authors are blocking them from being read. So we
>> need to patch that up for our particular use.
>>
>> Besides the above, there is nothing more intimate going on, except
>> that I see lots of potential problems, with little or no gain at all
>> in our particular case.
>
> Thanks for the details.
>
> It still sound to me like Darktable would make good sense to link
> against shared libraries for Debian.

I don't see how you'd resolve the float issue. But even if that were
to be resolved. What is the perceived benefit in this particular case?

Regards,
Pascal de Bruijn



Information forwarded to debian-bugs-dist@lists.debian.org, Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>:
Bug#682980; Package darktable. (Sat, 28 Jul 2012 16:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list. Copy sent to Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>. (Sat, 28 Jul 2012 16:21:05 GMT) Full text and rfc822 format available.

Message #45 received at 682980@bugs.debian.org (full text, mbox):

From: Jonas Smedegaard <dr@jones.dk>
To: Pascal de Bruijn <pmjdebruijn@pcode.nl>
Cc: 682980@bugs.debian.org
Subject: Re: Bug#682980: darktable: should use system shared libraw
Date: Sat, 28 Jul 2012 18:19:43 +0200
[Message part 1 (text/plain, inline)]
[switching to non-quiet flavor of bug address]

On 12-07-28 at 12:09pm, Pascal de Bruijn wrote:
> On Sat, Jul 28, 2012 at 2:26 AM, Jonas Smedegaard <dr@jones.dk> wrote:
> > On 12-07-28 at 12:42am, Pascal de Bruijn wrote:
> >> On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard <dr@jones.dk> 
> >> wrote:
> >> > On 12-07-27 at 10:08pm, Pascal de Bruijn wrote:
> >> >> When Darktable is linked against an external Libraw (or for that 
> >> >> matter RawSpeed) library, we likely would get lots of camera 
> >> >> support bugs which aren't reproducible (assuming the Debian 
> >> >> Libraw version is older), wasting our time. Or we aren't getting 
> >> >> any valid camera support bugs reported (assuming the Debian 
> >> >> Libraw version is newer). So both cases (newer and older) are 
> >> >> detrimental to our project.
> >> >
> >> > Bugs from users of Debian should go to Debian for this exact 
> >> > reason: The Debian package maintainers should pass upstream to 
> >> > you the Darktable developers only bugs relevant for you.
> >>
> >> Yeah, but that's not reality. People will just come and ask on our 
> >> mailing lists and irc channels, often not telling us they are 
> >> running Debian (unless we specifically ask), wasting our time.
> >
> > I recognize that issue from users of Debian reporting bugs about 
> > packages derived from Debian but changed in various ways unknown to 
> > us.
> >
> > What I do with that is not try enforce one single use of the 
> > packages we provide, but a) tell our users that they are free to use 
> > Debian also in (to us) weird ways (that's one of the freedoms that 
> > DFSG-free licensing provides!), but b) they are strongly recommended 
> > to tell us very clearly up front when reporting bugs if their setup 
> > of Debian is unusual, to not waste our time e.g. chasing bugs 
> > inefficiently.
> 
> I guess that's a similar issue.
> 
> However, there is a difference with users personally modifying things. 
> And distributions shipping non-standard versions.
> 
> We'd like to make sure that users get a user experience that is 
> representative of our intended Darktable user experience.

Users of Debian are not only personal.  One user of Debian is the 
distribution Ubuntu.


> >> >> So in my opinion Darktable should get a permanent exception to 
> >> >> this Debian policy.
> >> >>
> >> >> PS: Please don't misunderstand, I generally agree with the 
> >> >> policy in this regard, it's just that it makes very little sense 
> >> >> for projects like Darktable.
> >> >
> >> > Sorry, but I fail to see how this issue is any different from 
> >> > e.g. consumers of libexiv and the resulting changes to richness 
> >> > of the EXIF
> >>
> >> Having an older libexiv2 will not prevent files from being read at 
> >> all. Having an old libraw could result in images being "green" 
> >> instead of properly white balanced in some cases. And in even fewer 
> >> cases it could result in files not loading at all (where they 
> >> should have just loaded just fine (and/or not being green) with 
> >> unpatched darktable sources).
> >>
> >> > data supported with various versions of that library: as long as 
> >> > the API is the same, newest version of the library most often is 
> >> > preferred.
> >>
> >> Yes, but that isn't what happens in reality. What happens in 
> >> reality is that Debian is usually behind, really...
> >>
> >> > If I misunderstood and there is really something more intimate 
> >> > going on specifically with Darktable and its libraries could you 
> >> > please try elaborate more on that?
> >>
> >> With regard to the patch, LibRaw does RAW reading _and_ processing, 
> >> we only use the RAW reading bits (which is fairly atypical). But 
> >> the LibRaw processing bits don't support float DNGs (which we use 
> >> for HDR IIRC), so the LibRaw authors are blocking them from being 
> >> read. So we need to patch that up for our particular use.
> >>
> >> Besides the above, there is nothing more intimate going on, except 
> >> that I see lots of potential problems, with little or no gain at 
> >> all in our particular case.
> >
> > Thanks for the details.
> >
> > It still sound to me like Darktable would make good sense to link 
> > against shared libraries for Debian.
> 
> I don't see how you'd resolve the float issue. But even if that were 
> to be resolved. What is the perceived benefit in this particular case?

Same benefits as with other cases.  This is nicely described in Debian 
Policy: http://www.debian.org/doc/debian-policy/footnotes.html#f30


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>:
Bug#682980; Package darktable. (Sat, 28 Jul 2012 17:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Pascal de Bruijn <pmjdebruijn@pcode.nl>:
Extra info received and forwarded to list. Copy sent to Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>. (Sat, 28 Jul 2012 17:09:04 GMT) Full text and rfc822 format available.

Message #50 received at 682980@bugs.debian.org (full text, mbox):

From: Pascal de Bruijn <pmjdebruijn@pcode.nl>
To: Jonas Smedegaard <dr@jones.dk>
Cc: 682980@bugs.debian.org
Subject: Re: Bug#682980: darktable: should use system shared libraw
Date: Sat, 28 Jul 2012 19:08:17 +0200
On Sat, Jul 28, 2012 at 6:19 PM, Jonas Smedegaard <dr@jones.dk> wrote:
> [switching to non-quiet flavor of bug address]
>
> On 12-07-28 at 12:09pm, Pascal de Bruijn wrote:
>> On Sat, Jul 28, 2012 at 2:26 AM, Jonas Smedegaard <dr@jones.dk> wrote:
>> > On 12-07-28 at 12:42am, Pascal de Bruijn wrote:
>> >> On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard <dr@jones.dk>
>> >> wrote:
>> >> > On 12-07-27 at 10:08pm, Pascal de Bruijn wrote:
>> >> >> When Darktable is linked against an external Libraw (or for that
>> >> >> matter RawSpeed) library, we likely would get lots of camera
>> >> >> support bugs which aren't reproducible (assuming the Debian
>> >> >> Libraw version is older), wasting our time. Or we aren't getting
>> >> >> any valid camera support bugs reported (assuming the Debian
>> >> >> Libraw version is newer). So both cases (newer and older) are
>> >> >> detrimental to our project.
>> >> >
>> >> > Bugs from users of Debian should go to Debian for this exact
>> >> > reason: The Debian package maintainers should pass upstream to
>> >> > you the Darktable developers only bugs relevant for you.
>> >>
>> >> Yeah, but that's not reality. People will just come and ask on our
>> >> mailing lists and irc channels, often not telling us they are
>> >> running Debian (unless we specifically ask), wasting our time.
>> >
>> > I recognize that issue from users of Debian reporting bugs about
>> > packages derived from Debian but changed in various ways unknown to
>> > us.
>> >
>> > What I do with that is not try enforce one single use of the
>> > packages we provide, but a) tell our users that they are free to use
>> > Debian also in (to us) weird ways (that's one of the freedoms that
>> > DFSG-free licensing provides!), but b) they are strongly recommended
>> > to tell us very clearly up front when reporting bugs if their setup
>> > of Debian is unusual, to not waste our time e.g. chasing bugs
>> > inefficiently.
>>
>> I guess that's a similar issue.
>>
>> However, there is a difference with users personally modifying things.
>> And distributions shipping non-standard versions.
>>
>> We'd like to make sure that users get a user experience that is
>> representative of our intended Darktable user experience.
>
> Users of Debian are not only personal.  One user of Debian is the
> distribution Ubuntu.

Yes, which multiplies the problem for us. But at least for Ubuntu I
can point people to my Darktable PPAs.

>> >> >> So in my opinion Darktable should get a permanent exception to
>> >> >> this Debian policy.
>> >> >>
>> >> >> PS: Please don't misunderstand, I generally agree with the
>> >> >> policy in this regard, it's just that it makes very little sense
>> >> >> for projects like Darktable.
>> >> >
>> >> > Sorry, but I fail to see how this issue is any different from
>> >> > e.g. consumers of libexiv and the resulting changes to richness
>> >> > of the EXIF
>> >>
>> >> Having an older libexiv2 will not prevent files from being read at
>> >> all. Having an old libraw could result in images being "green"
>> >> instead of properly white balanced in some cases. And in even fewer
>> >> cases it could result in files not loading at all (where they
>> >> should have just loaded just fine (and/or not being green) with
>> >> unpatched darktable sources).
>> >>
>> >> > data supported with various versions of that library: as long as
>> >> > the API is the same, newest version of the library most often is
>> >> > preferred.
>> >>
>> >> Yes, but that isn't what happens in reality. What happens in
>> >> reality is that Debian is usually behind, really...
>> >>
>> >> > If I misunderstood and there is really something more intimate
>> >> > going on specifically with Darktable and its libraries could you
>> >> > please try elaborate more on that?
>> >>
>> >> With regard to the patch, LibRaw does RAW reading _and_ processing,
>> >> we only use the RAW reading bits (which is fairly atypical). But
>> >> the LibRaw processing bits don't support float DNGs (which we use
>> >> for HDR IIRC), so the LibRaw authors are blocking them from being
>> >> read. So we need to patch that up for our particular use.
>> >>
>> >> Besides the above, there is nothing more intimate going on, except
>> >> that I see lots of potential problems, with little or no gain at
>> >> all in our particular case.
>> >
>> > Thanks for the details.
>> >
>> > It still sound to me like Darktable would make good sense to link
>> > against shared libraries for Debian.
>>
>> I don't see how you'd resolve the float issue. But even if that were
>> to be resolved. What is the perceived benefit in this particular case?
>
> Same benefits as with other cases.  This is nicely described in Debian
> Policy: http://www.debian.org/doc/debian-policy/footnotes.html#f30

1. Having multiple copies of the same code in Debian is inefficient

Ok. I get that. But it's hardly worth creating problems for.

2. often creates either static linking or shared library conflicts

I'm not sure how that would happen. Including local libraries
generally avoids that problem, instead of creating it.

3. and, most importantly, increases the difficulty of handling
security vulnerabilities in the duplicated code.

This is a good point, particularly for network/Internet facing program
and libraries.

Though for LibRaw it's a rather theoretical point. I've never seen a
report of a crafted RAW (not that it couldn't exist). And considering
the amount of code handling the different RAW formats I would be
surprised if it's not vulnerable in multiple ways already (if one were
to look). Really take a look at the LibRaw code :)

Also, taking UFRaw as an example, includes it's own internally linked
copy of dcraw.c which serves the exact same purpose for UFRaw as
LibRaw does for us. It seems odd we should get different treatment.

Regards,
Pascal de Bruijn



Added tag(s) moreinfo. Request was from David Bremner <bremner@debian.org> to control@bugs.debian.org. (Sun, 09 Dec 2012 19:00:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>:
Bug#682980; Package darktable. (Sun, 09 Dec 2012 19:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Bremner <bremner@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>. (Sun, 09 Dec 2012 19:21:03 GMT) Full text and rfc822 format available.

Message #57 received at 682980@bugs.debian.org (full text, mbox):

From: David Bremner <bremner@debian.org>
To: 682980@bugs.debian.org
Cc: pkg-shotwell-maint@lists.alioth.debian.org
Subject: Any way to resolve this bug?
Date: Sun, 09 Dec 2012 15:18:32 -0400
To recap, darktable ships an embedded copy of LibRaw with the following
patch applied:

diff --git a/src/external/LibRaw/internal/dcraw_common.cpp b/src/external/
index 20ed524..822b68a 100644
--- a/src/external/LibRaw/internal/dcraw_common.cpp
+++ b/src/external/LibRaw/internal/dcraw_common.cpp
@@ -5904,8 +5904,6 @@ void CLASS apply_tiff()
       || (tiff_bps == 8 && !strstr(make,"KODAK") && !strstr(make,"Kodak")
          !strstr(model2,"DEBUG RAW")))
       is_raw = 0;
-  if(dng_version && max_bps > 16)
-      is_raw = 0;
   for (i=0; i < tiff_nifds; i++)
     if (i != raw && tiff_ifd[i].samples == max_samp && tiff_ifd[i].offset
        tiff_ifd[i].t_width * tiff_ifd[i].t_height / SQR(tiff_ifd[i].bps+1

It seems libraw upstream doesn't want to apply this patch (although I
might misunderstand what Pascal writes there), and darktable won't work
(or at least loses some functionality) without it.

We _could_ hypothetically ask the debian libraw maintainers to apply
this patch, but I could certainly understand them not wanting to do
something that upstream is explicitly declines to do.

I don't see an obvious way forward; some motivated person could pursue
this with libraw upstream I guess.

I think having up to date versions of libraw in debian is less of a
problem, since it is fixable by e.g. NMUing if it becomes a problem.

I have put the Debian libraw maintainers in copy, in case they have any
ideas.

d










Added tag(s) wontfix. Request was from David Bremner <bremner@debian.org> to control@bugs.debian.org. (Wed, 30 Jan 2013 12:03:05 GMT) Full text and rfc822 format available.

Reply sent to David Bremner <bremner@debian.org>:
You have taken responsibility. (Wed, 30 Jan 2013 12:09:03 GMT) Full text and rfc822 format available.

Notification sent to Jonas Smedegaard <dr@jones.dk>:
Bug acknowledged by developer. (Wed, 30 Jan 2013 12:09:03 GMT) Full text and rfc822 format available.

Message #64 received at 682980-done@bugs.debian.org (full text, mbox):

From: David Bremner <bremner@debian.org>
To: 682980-done@bugs.debian.org
Subject: won't/can't fix 682980 for now
Date: Wed, 30 Jan 2013 08:07:04 -0400
Having double checked the Debian version of libraw doesn't support DNG
images at more than 16 bits, I'm tagging this bug wontfix and closing
it.  If the DNG support in Debian's libraw changes, then the bug can be
re-opened.

Cheers,

David



Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 28 Feb 2013 07:27:30 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 17:51:58 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.