Hi all,
First, please, we would love if you can test what Pablo proposed and give us some feedback.
It will be super helpful to evaluate if it is worth to generate a new vm release!!!
Also, besides what Pablo said in the previous email, I wanted to share some more precisions.
=== Precisions on the problem ===
First, just to clarify, we isolated the issue happening only on Windows10 #1903 on Pharo64 bits.
Pharo32 bits does work well on that update number does work well.
The origin of the problem seems to be a bad integration between libssh2 1.7.0 and the windows CNG crypto layer, which seemingly changed in this update.
=== The path to the solution ===
The solution was theoretically super straight forward (upgrade to openssh 1.9.0 + openssl for crypto instead of windows CNG).
It was however super time consuming.
- installing the windows update #1903 to test, reproduce and understand the issue took for us a couple of hours, reconfiguring the virtual machines to enlarge disks to download it, then install it...
- compiling openssl took literally the entire afternoon yesterday in Pablo���s machine.
- then we found several bugs in cmake openssl integration when compiling libssh2 on Cigwin + mingw, because life cannot be easy ^^
And fortunately, we found no incompatibilities between the different versions of these libraries (and libgit2 too!) so it could have been more time consuming :P.
=== Alternative solutions and workarounds ===
Alternatively for testing the libraries that Pablo sent in the previous email, there are some other workarounds that people could try in the meantime:
1) Use Pharo32 bits, which as I said above, does not have the problem.
2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello integration to HTTP by default).
We are also evaluating setting HTTPS by default in Iceberg as it is simpler to setup.
Github, Gitkraken do use HTTPS as a sensible default too.
Cheers
Hi all,
with Guille we have been working in this issue since Monday, it
was a complicated issue to solve as we require to compile and test
different versions of the libgit2 library and its dependencies
(openssl and libssh2).
We have a workaround for using ssh in windows.
We have produced a new set of libraries with the correct versions.
These libraries are available in
https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1The idea is to start testing them while we are working on a new
release of the VM.
Cheers,
Pablo
On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito
<guillermopolito@gmail.com> wrote:
Hi all,
Sorry for not communicating better :).
We know this is an important issue and we did move it to top priority even prior to this email ;).
Doru, to answer you, what people can do for the moment is to test what we are going to propose in a couple of hours in your windows machines.
With Pablo we have tested in several Windows 10 machines pre- and post- update 1903. Still we would like people testing on their setups and other windows versions
We have been working the last couple of days debugging openssh and libgit, and building a version with a more up-to-date version of openssh.
We will come back later this morning / early afternoon with
- a new vm setup using up to date versions of openssh
- a description of workarounds for those tied to old versions of the VM
So people can test.
Cheers,
Guille and Pablo
El 4 sept 2019, a las 8:38, ducasse <stepharo@netcourrier.com> escribi��:
I saw everybody super busy and I imagine that they will reply soon.
I���m travelling to give Pharo lectures.
On 3 Sep 2019, at 19:23, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Is there a way to speed the work on this one?
At this moment, people cannot load any code in Pharo on Windows 10.
Cheers,
Doru
--
www.feenk.com
"Every thing has its own flow."
On 28 Aug 2019, at 16:20, ducasse <stepharo@netcourrier.com> wrote:
tx doru
Stef
On 28 Aug 2019, at 16:01, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi
I opened an issue: https://github.com/pharo-project/pharo/issues/4437
I believe this should be treated as critical given that we cannot load code in Pharo 7 (or 8) which makes it almost useless for users.
Cheers,
Doru
On Aug 27, 2019, at 10:54 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
We just encountered this on two different machines. We got this after the update to Windows 1903. For us it���s a critical issue at this point. What can we do to help with this?
Cheers,
Doru
On Aug 17, 2019, at 12:50 PM, Ben Coman <btc@openInWorld.com> wrote:
hi Stef,
I feel you missed my point. Probably I wasn't clear this has already been tested with latest Pharo 8 launched by PharoLauncher.
The problem occurs with Pharo 7.0.3(64 bit) and with Pharo8.0-SNAPSHOT-build.635(64 bit)
after Microsoft Windows Update 1903...
https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-1803-to-1903-forced-upgrade.html
If indeed 1903 is the cause, with this update now being *forced* down on people, this will potentially soon impact more and more Windows users.
But my guess that 1903 is the culprit needs to be confirmed.
So I am requesting someone with access to multiple Windows machines directly compare a 1903 machine with a pre-1903 machine.
cheers -ben
On Sat, 17 Aug 2019 at 12:58, ducasse <stepharo@netcourrier.com> wrote:
Hi ben
in the pharo launcher if you click on P8.0 (development version) you get access to all the builds.
Stef
On 16 Aug 2019, at 16:02, Ben Coman <btc@openinworld.com> wrote:
IThis morning the May 2019 Windows Update "1903" forced itself onto my computer and now 64-bits Pharo seems to have a problem with git_remote_fetch() FFI callout. I no longer have a non-1903 machine to directly compare behaviour before "1903". Can someone familiar with this area with both "pre-1903" and "1903" machines triage whether "1903" is indeed the cause?
A few other recent reports are noted here...
https://github.com/pharo-project/pharo/issues/3418
cheers -ben
--
feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
--
feenk.com
���Live like you mean it."
--
Pablo Tesone.
tesonep@gmail.com