> On 24 Mar 2017, at 12:04, Esteban Lorenzano <[email protected]> wrote: > >> >> On 24 Mar 2017, at 11:54, Max Leske <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On 24 Mar 2017, at 11:29, Esteban Lorenzano <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, >>> >>> I wanted to share with you the list of blocking issues I see to do the >>> release :) >>> >>> Image >>> ===== >>> >>> - Cairo surface crash. >>> Of course, as it is now is unnaceptable... I have some solution to test but >>> if that does not work, I will >>> workaround the problem by adding a (hopefully temporal) CairoPlugin. >>> - Iceberg needs to enter the system as preview before release. >>> This is needed to use the new process, and it was almost ready but we get >>> blocked for a problem in VM for linux >>> (see below). >>> - I'm quite sure there is still a leak. During too much time we had the >>> compactor problem so we blame it for our >>> increasing sizes. Now it works and images continue growing without control, >>> so we need to find it. >>> >>> Image 64bits >>> ============ >>> - Athens is working in general, but there are still some places where it >>> uses a `long` as a pointer and of course, >>> that's not true on 64bits (at least in windows). >>> >>> VM >>> == >>> - New VM compactor has problems when image hits a big size. >>> Eliot is working on it, but we cannot release with VM as it is now... I >>> hope it will be fixed next days too. >>> - here are still some glitches and tests do not pass completely. >>> Methods failing in travis are: >>> >>> DelayMicrosecondSchedulerTest>>#testForMilliseconds >>> MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne >>> >>> This, in linux VM. I think is important but I think we will have a solution >>> next days >>> - Dependency libraries problem. Again, in linux... we distribute libgit2, >>> libssh2 and libssl (because we cannot >>> rely on linux installed versions), and there is a problem to solve the >>> paths. >> >> Really?? I thought I had solved that. > > nope :( > at the end, the only solution is to ensure those libs are first in > “resolution” list, and that’s with an LD_LIBRARY_PATH :( > anyway, this is fixed, I’m just testing it/adapting zeroconf, etc. :) >
Wow, that sucks! Thanks! > Esteban > >> >>> Ultimate solution is to use a script >>> as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. >>> I’m testing this. >>> >>> >>> VM 64bits >>> ========= >>> - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one >>> we are using) for macOS, which makes >>> impossible to use Iceberg. Not sure this is blocking, but well... I needed >>> to point it :) >>> - No VM for windows. Again, this is a know issue… but maybe I can add a >>> StackVM for windows… I need to >>> see how is working.
