Esteban’s list of blocking issues for release Pharo 6.0
Locked
 
|
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. 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. |
|
|
> On 24 Mar 2017, at 11:29, Esteban Lorenzano <[hidden email]> 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. > 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. > > |
|
|
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. :) Esteban
|
|
|
Wow, that sucks! Thanks!
|
|
|
In reply to this post by EstebanLM
Hi!
I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes. Maybe this long lasting issue is solve… Alexandre
|
|
|
I’m aware of this, that was my “solution to test” :) but if you can confirm it works, I will commit the image changes Eliot gave me :) Esteban
|
|
|
I will do a couple of more tests.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
Re: Esteban’s list of blocking issues for release Pharo 6.0
|
|
In reply to this post by EstebanLM
2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <[hidden email]>: Hi, Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files - No VM for windows. Again, this is a know issue… but maybe I can add a StackVM for windows… I need to Yes please, try stack VM for Win64. The bleeding edge pharo VM are automatically built by appveyor https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.stack.spur_201703222227.zip |
|
|
yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;) Esteban
|
Re: Esteban’s list of blocking issues for release Pharo 6.0
|
|
In reply to this post by abergel
Where can I get this new VM? Is it on files.pharo.org yet? |
|
|
> On 24 Mar 2017, at 14:33, webwarrior <[hidden email]> wrote: > > abergel wrote >> Hi! >> >>> Image >>> ===== >>> >>> - Cairo surface crash. >> >> I may have a good news on this issue. Recently Eliot produced a new VM >> that prevents garbage collection while doing a bitblt. I have used this VM >> for a couple of days and have not experienced any crashes. >> >> Maybe this long lasting issue is solve… >> >> Alexandre > > Where can I get this new VM? Is it on files.pharo.org yet? yes, if you download latest you should have the fixes. Esteban > > > > -- > View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6-0-tp4939826p4939848.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
|
|
In reply to this post by webwarrior
Try this one:
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
|
|
In reply to this post by EstebanLM
On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <[hidden email]> wrote:
> > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <[hidden email]>: >> >> >> 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 :) > > Hi Esteban, > Doesn't the Travis build correctly succeed? > https://bintray.com/opensmalltalk/vm/cog/201703222227#files > > yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P > if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;) Do you mean build libgit2 standalone? or as part of pharo-vm build? I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I could upgrade to try if needed. I don't know about the rpath warning. I ignored it. Standalone... 502 mkdir LIBGIT 503 cd LIBGIT/ 504 git clone https://github.com/libgit2/libgit2.git 505 cd libgit2 521 git checkout v0.23.0 522 mkdir ../build && cd ../build 525 cmake ../libgit2 -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: git2 526 cmake --build . 528 file libgit2.0.23.0.dylib libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library x86_64 529 cmake --version cmake version 3.0.0 530 uname -a Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 Should I be testing something else? cheers -ben |
Re: Esteban’s list of blocking issues for release Pharo 6.0
|
|
In reply to this post by EstebanLM
Tried it. Now Pharo doesn't crash, but merely gives the following error in BitBlt>>copyBits method: Error: Bad BitBlt arg (Fraction?); proceed to convert. I don't see any Fractions, though destX and destY are Floats. If I proceed, image becomes kinda unresponsive, but can be interrupted using alt+. |
Re: Esteban’s list of blocking issues for release Pharo 6.0
|
|
In reply to this post by Ben Coman
2017-03-24 17:23 GMT+01:00 Ben Coman <[hidden email]>: On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <[hidden email]> wrote: Same for me here on OSX 10.11.6 El Capitan, libgit2 builds out of the box, same warning for RPATH Maybe we could reactivate on travis? Should I be testing something else? |
|
|
On Sat, Mar 25, 2017 at 5:17 AM, Nicolas Cellier
<[hidden email]> wrote: > > > 2017-03-24 17:23 GMT+01:00 Ben Coman <[hidden email]>: >> >> On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <[hidden email]> >> wrote: >> > >> > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <[hidden email]>: >> >> >> >> >> >> 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 :) >> > >> > Hi Esteban, >> > Doesn't the Travis build correctly succeed? >> > https://bintray.com/opensmalltalk/vm/cog/201703222227#files >> > >> > yes, but the PharoVM for mac in 64bits is not including libgit2 (because >> > I was unable to compile it) :P >> > if you (or anyone) find the time and helps me doing that, I will be >> > very, very, very grateful (and release will be earlier ;) >> >> Do you mean build libgit2 standalone? or as part of pharo-vm build? >> >> I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I >> could upgrade to try if needed. >> I don't know about the rpath warning. I ignored it. >> >> Standalone... >> >> 502 mkdir LIBGIT >> 503 cd LIBGIT/ >> 504 git clone https://github.com/libgit2/libgit2.git >> 505 cd libgit2 >> 521 git checkout v0.23.0 >> 522 mkdir ../build && cd ../build >> 525 cmake ../libgit2 >> -- Configuring done >> CMake Warning (dev): >> Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run >> "cmake >> --help-policy CMP0042" for policy details. Use the cmake_policy command >> to >> set the policy and suppress this warning. >> MACOSX_RPATH is not specified for the following targets: >> git2 >> >> 526 cmake --build . >> 528 file libgit2.0.23.0.dylib >> libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library >> x86_64 >> >> 529 cmake --version >> cmake version 3.0.0 >> >> 530 uname -a >> Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: >> Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 >> x86_64 >> > > Same for me here on OSX 10.11.6 El Capitan, > libgit2 builds out of the box, same warning for RPATH > Maybe we could reactivate on travis? Is this relevant regarding using ssh with using libgit ? https://github.com/libgit2/libgit2/issues/2665 cheers -ben |
|
|
On Sat, Mar 25, 2017 at 8:12 AM, Ben Coman <[hidden email]> wrote:
> On Sat, Mar 25, 2017 at 5:17 AM, Nicolas Cellier > <[hidden email]> wrote: >> >> >> 2017-03-24 17:23 GMT+01:00 Ben Coman <[hidden email]>: >>> >>> On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <[hidden email]> >>> wrote: >>> > >>> > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <[hidden email]>: >>> >> >>> >> >>> >> 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 :) >>> > >>> > Hi Esteban, >>> > Doesn't the Travis build correctly succeed? >>> > https://bintray.com/opensmalltalk/vm/cog/201703222227#files >>> > >>> > yes, but the PharoVM for mac in 64bits is not including libgit2 (because >>> > I was unable to compile it) :P >>> > if you (or anyone) find the time and helps me doing that, I will be >>> > very, very, very grateful (and release will be earlier ;) >>> >>> Do you mean build libgit2 standalone? or as part of pharo-vm build? >>> >>> I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I >>> could upgrade to try if needed. >>> I don't know about the rpath warning. I ignored it. >>> >>> Standalone... >>> >>> 502 mkdir LIBGIT >>> 503 cd LIBGIT/ >>> 504 git clone https://github.com/libgit2/libgit2.git >>> 505 cd libgit2 >>> 521 git checkout v0.23.0 >>> 522 mkdir ../build && cd ../build >>> 525 cmake ../libgit2 >>> -- Configuring done >>> CMake Warning (dev): >>> Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run >>> "cmake >>> --help-policy CMP0042" for policy details. Use the cmake_policy command >>> to >>> set the policy and suppress this warning. >>> MACOSX_RPATH is not specified for the following targets: >>> git2 >>> >>> 526 cmake --build . >>> 528 file libgit2.0.23.0.dylib >>> libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library >>> x86_64 >>> >>> 529 cmake --version >>> cmake version 3.0.0 >>> >>> 530 uname -a >>> Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: >>> Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 >>> x86_64 >>> >> >> Same for me here on OSX 10.11.6 El Capitan, >> libgit2 builds out of the box, same warning for RPATH >> Maybe we could reactivate on travis? > > Is this relevant regarding using ssh with using libgit ? > https://github.com/libgit2/libgit2/issues/2665 I'm having trouble with my mac-mini with extended pauses between shell commands so I've not been able to test whether this is relevant, but doing... $ cd ~/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur $ ./mvm I see==> tar x -f ../../.thirdparty-cache/libgit2-v0.23.0.tar.gz -C builddbg/third-party cd builddbg/third-party/libgit2-0.23.0 \ && cmake \ -DCMAKE_INSTALL_PREFIX=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64 \ -DUSE_SSH=ON \ -DCURL=ON \ -DBUILD_CLAR=OFF \ -DOPENSSL_FOUND=ON \ -DLIBSSH2_FOUND=ON \ -DLIBSSH2_INCLUDE_DIRS=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/include \ -DLIBSSH2_LIBRARIES=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib \ -DCMAKE_C_FLAGS="-L/usr/lib -L/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib -lssl -lcrypto -liconv" \ -DCMAKE_OSX_ARCHITECTURES=x86_64 \ -DCMAKE_SHARED_LINKER_FLAGS=-Wl,-rpath,@executable_path:@executable_path/Plugins \ && make \ && make install -- The C compiler identification is AppleClang 6.0.0.6000056 ... -- checking for module 'libssh2' -- package 'libssh2' not found -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib - found ---------------- Trying again on its own in a clean dir... 533 cd ~/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/builddbg/third-party 534 rm -r libgit2-0.23.0 535 tar x -f ../../../../.thirdparty-cache/libgit2-v0.23.0.tar.gz -C . 536 cd libgit2-0.23.0/ 537 cmake ....same...params...as...above I get the same error, -- package 'libssh2' not found but if I up-arrow to run `cmake` again, that message doesn't appear. Maybe its caching the result from the next line from the -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib - found So does that mean SSH ended up found and cmake cached the result? $ make ==> Linking C shared library libgit2.dylib [100%] Built target git2 $ otool -L libgit2.dylib ==> /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/builddbg/third-party/libgit2-0.23.0/libgit2.23.dylib (compatibility version 23.0.0, current version 0.23.0) /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.16) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0) /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib (compatibility version 2.0.0, current version 2.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) So does that look like libgit is set up to use ssh okay? ------ btw, I found a related topic... http://stackoverflow.com/questions/32744681/libgit2-and-libssh2-cmake-package-libssh2-not-found and here is the quick reference diff... https://www.diffchecker.com/SOGHWKRC So I notice among other things that changes LIBSSH2_INCLUDE_DIRS to LIBSSH2_INCLUDE_DIR, and our build uses -DLIBSSH2_INCLUDE_DIRS thats all I got for now. cheers -ben |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |