I confirm, problem solved !
Thanks
Le 08/02/2013 07:43, johannes hanika a écrit :
> should be fixed now, can you retry?
>
> j.
>
> On Fri, Feb 8, 2013 at 10:17 AM, johannes hanika wrote:
>> thanks.
>>
>> and that's a very stupid little error in our code, the string buffer
>> isn't large enough.
hey,
with fluxbox (again, didn't we have that before?) selection via mouse
click in lighttable mode is broken.
it comes back to life if i revert those two commits:
Revert "Make the UI behave as expected when an image rating is changed"
This reverts commit fc4c157596fdd9727d33dad5a8ec074783993f47
should be fixed now, can you retry?
j.
On Fri, Feb 8, 2013 at 10:17 AM, johannes hanika wrote:
> thanks.
>
> and that's a very stupid little error in our code, the string buffer
> isn't large enough. should be very easy to fix, i'll do that as soon
> as i get back to a machine where i can compil
On 02/07/2013 10:31 PM, Pascal de Bruijn wrote:
> On Thu, Feb 7, 2013 at 8:47 PM, Togan Muftuoglu
> wrote:
>> On 02/07/2013 08:23 PM, Pascal de Bruijn wrote:
>>> On Thu, Feb 7, 2013 at 9:29 AM, Madko wrote:
btw, darktable with libjpeg-turbo workaround patch build fine on Fedora 18!
Grea
On Thu, Feb 7, 2013 at 8:47 PM, Togan Muftuoglu
wrote:
> On 02/07/2013 08:23 PM, Pascal de Bruijn wrote:
>> On Thu, Feb 7, 2013 at 9:29 AM, Madko wrote:
>>> btw, darktable with libjpeg-turbo workaround patch build fine on Fedora 18!
>>> Great!
>>
>> While nothing is set in stone, it's likely we'l
thanks.
and that's a very stupid little error in our code, the string buffer
isn't large enough. should be very easy to fix, i'll do that as soon
as i get back to a machine where i can compile and test..
thanks for reporting.
jo
On Fri, Feb 8, 2013 at 10:08 AM, Florian GOULEAU
wrote:
> Yeah, of
Yeah, of course :
http://pastebin.com/0Yz2XEqD
http://pastebin.com/K9MjyXLP
Sorry for the blinking adds, Free.fr is my internet provider
so I do not see them.
florian
Le 07/02/2013 21:59, johannes hanika a écrit :
> On Fri, Feb 8, 2013 at 9:12 AM, Florian GOULEAU
> wrote:
>> Hello,
>>
>> Well
On Fri, Feb 8, 2013 at 9:12 AM, Florian GOULEAU
wrote:
> Hello,
>
> Well, I removed my darktable directory, .cache/darktable, .config/darktable
> and /opt/darktable
> Then I made a fresh new clone from git, loaded a photo without
> associated xmp
> and still encounter the same crash when playing w
Hello,
Well, I removed my darktable directory, .cache/darktable, .config/darktable
and /opt/darktable
Then I made a fresh new clone from git, loaded a photo without
associated xmp
and still encounter the same crash when playing with custom iop presets.
Here is the output of "darktable -d all" on
On 02/07/2013 08:23 PM, Pascal de Bruijn wrote:
> On Thu, Feb 7, 2013 at 9:29 AM, Madko wrote:
>> btw, darktable with libjpeg-turbo workaround patch build fine on Fedora 18!
>> Great!
>
> While nothing is set in stone, it's likely we'll start the release
> process tomorrow or the day after, and t
On Thu, Feb 7, 2013 at 9:29 AM, Madko wrote:
> btw, darktable with libjpeg-turbo workaround patch build fine on Fedora 18!
> Great!
While nothing is set in stone, it's likely we'll start the release
process tomorrow or the day after, and this checkout will likely be
very close to the released ver
On Thu, Feb 7, 2013 at 5:44 PM, Rob Z. Smith wrote:
> Hi,
>
> Currently starting up dt hangs without displaying gui, crashing or
> generating system errors. Output from ‘darktable –d all’ is:
>
> [memory] at startup
>
> [memory] max address space (vmpeak): 165928 kB
>
> [memory] cur address
Hi,
Currently starting up dt hangs without displaying gui, crashing or generating
system errors. Output from 'darktable -d all' is:
[memory] at startup
[memory] max address space (vmpeak): 165928 kB
[memory] cur address space (vmsize): 165928 kB
[memory] max used memory (vmhwm )
2013/2/7 johannes hanika
> On Thu, Feb 7, 2013 at 8:45 PM, Madko wrote:
> > Thanks Pascal and Klaus for this quick workaround. In fact fedora 19 is
> > using libjpeg-turbo, in what looks like a pre version from the project
> svn
> > (1.2.90-0.1.20130204svn922). So it's not really libjpeg, could
>>jpg-turbo should be a drop-in replacement with the same api, right? so
>> maybe it's not quite the same after all in this case.
Yes - exactly..
libjpeg-turbo tells it is ABI version 6b, but in reality it has some
version 8 features implemented. This leads to a linker collision, since I
define
On Thu, Feb 7, 2013 at 8:45 PM, Madko wrote:
> Thanks Pascal and Klaus for this quick workaround. In fact fedora 19 is
> using libjpeg-turbo, in what looks like a pre version from the project svn
> (1.2.90-0.1.20130204svn922). So it's not really libjpeg, could the problem
> come from that? Do you
16 matches
Mail list logo
