> In article <87txl6lzc8@users.sourceforge.net>,
> tog...@users.sourceforge.net writes:
> "Madko" == Madko writes:
Madko> The problem about squish is that some (at least Fedora/RH)
Madko> thinks that distributing patented sources is as harmful as
Madko> distributing t
Am Montag, 10. Juni 2013, 17:50:44 schrieb Madko:
[...]
> therefor it's still distributed (within the SRPM). Fedora could decide to
> remove darktable from their repos for that :(
They are free to remove darktable if they don't like it, no one will try to
stop them.
Some people really have too
> "Madko" == Madko writes:
Madko> The problem about squish is that some (at least Fedora/RH)
Madko> thinks that distributing patented sources is as harmful as
Madko> distributing the compiled version... Debian's point of view
Madko> is that source code is like free speech (at
The problem about squish is that some (at least Fedora/RH) thinks that
distributing patented sources is as harmful as distributing the compiled
version... Debian's point of view is that source code is like free speech
(at least in the US), and it's just a description of the invention, not the
inven
> "Tobias" == Tobias Ellinghaus writes:
Tobias> Most arguments in that bug report are nonsense. It's not a
Tobias> matter of user experience, it's just that we added a new
Tobias> feature to libraw that we need and that doesn't exist
Tobias> upstream. And the latest ups
Am Montag, 10. Juni 2013, 14:16:28 schrieb tog...@users.sourceforge.net:
> > "Simon" == Simon writes:
> Simon> The reasons for not using 0.15 are summarized here:
> Simon> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
>
> Yes but the reasons could be valid for any software
perfect :)
2013/6/10 johannes hanika
> oh, i only pushed to master, now in darktable-1.2.x, too.
>
> -jo
>
>
> On Mon, Jun 10, 2013 at 2:45 PM, Madko wrote:
>
>> Thank you Johannes for this clear explaination about libraw. So the best
>> solution would be to use rawstudio code, any "plan" to d
oh, i only pushed to master, now in darktable-1.2.x, too.
-jo
On Mon, Jun 10, 2013 at 2:45 PM, Madko wrote:
> Thank you Johannes for this clear explaination about libraw. So the best
> solution would be to use rawstudio code, any "plan" to do that in future
> releases?
>
> Sorry to come back a
Thank you Johannes for this clear explaination about libraw. So the best
solution would be to use rawstudio code, any "plan" to do that in future
releases?
Sorry to come back about squish, I try the -DUSE_SQUISH=OFF with no success:
CMake Warning:
Manually-specified variables were not used by t
1) white balance for > 16 bit dng: alex doesn't want to support that format
at all, in fact our copy of libraw only doesn't crash on it because these
files are opened with rawspeed. so he has a point i guess.
the clean way to solve this would be on our end not to use libraw to read
camera-wb from
Do you know why they removed those functionnalities?
2013/6/10 johannes hanika
> no, not possible. we need to revert a couple of commits from upsteam to
> get back functionality that has been removed over the years.
>
> -jo
>
>
> On Mon, Jun 10, 2013 at 1:38 PM, Madko wrote:
>
>> Is it possibl
no, not possible. we need to revert a couple of commits from upsteam to get
back functionality that has been removed over the years.
-jo
On Mon, Jun 10, 2013 at 1:38 PM, Madko wrote:
> Is it possible to build darktable against LibRaw from the system, not
> against the one provided in src/exter
> "Simon" == Simon writes:
Simon> The reasons for not using 0.15 are summarized here:
Simon> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
Yes but the reasons could be valid for any software that is needing
external libraries and that makes it awkward for the package maint
The reasons for not using 0.15 are summarized here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
On 06/10/2013 01:38 PM, Madko wrote:
> Is it possible to build darktable against LibRaw from the system, not
> against the one provided in src/external?
>
>
> 2013/6/10 Jose Carlos Garcia So
Am Montag, 10. Juni 2013, 11:18:56 schrieb johannes hanika:
[...]
> >- LibRaw is suffering from a security issue
>
> not the version we use, ours is too old.
There was a fix [0] packported from the 0.15 branch to the 0.14 branch of
libraw. I applied it to our copy.
Tobias
[...]
[0]
https:/
Is it possible to build darktable against LibRaw from the system, not
against the one provided in src/external?
2013/6/10 Jose Carlos Garcia Sogo
> On Mon, Jun 10, 2013 at 11:55 AM, Madko wrote:
> > Thanks Johannes
> >
> > about squish and its patented algorithm (DXT), is it right to distribut
On Mon, Jun 10, 2013 at 11:55 AM, Madko wrote:
> Thanks Johannes
>
> about squish and its patented algorithm (DXT), is it right to distribute it
> in your sources tarballs?
Yes, it is: http://www.debian.org/reports/patent-faq
--
Thanks Johannes
about squish and its patented algorithm (DXT), is it right to distribute it
in your sources tarballs?
2013/6/10 johannes hanika
> git checkout master
> cmake -DUSE_SQUISH=off
>
> j.
>
>
> On Mon, Jun 10, 2013 at 11:18 AM, johannes hanika wrote:
>
>>
>> >- squish is unsuitable f
git checkout master
cmake -DUSE_SQUISH=off
j.
On Mon, Jun 10, 2013 at 11:18 AM, johannes hanika wrote:
>
> >- squish is unsuitable for Fedora, snce it implement s3tc, a patented
> algorithm ( found by Nicolas Chauvet )
>
> it's optional and switched off by default. i can make it a compile time
>- squish is unsuitable for Fedora, snce it implement s3tc, a patented
algorithm ( found by Nicolas Chauvet )
it's optional and switched off by default. i can make it a compile time
switch if that solves the problem?
>- LibRaw is suffering from a security issue
not the version we use, ours is to
Hi,
please can someone look at this bug report
https://bugzilla.redhat.com/show_bug.cgi?id=972604 and tell me if you agree
with the reporter (specially the license problem).
Thanks
--
Edouard Bourguignon
--
How ServiceN
21 matches
Mail list logo
