Pharo CI stopped working - libgit errors

[JanBliznicenko]

I am not exactly sure what is the source of the problem, but all Pharo CI/CD on Linux and Mac stopped working in last 24 hours. Win builds seem unaffected. I have seen different errors. Mostly IceGenericError: error reading from the zlib stream, but few times IceGenericError: bad packet length.

MetacelloNotification: Loaded -> BaselineOfUMLProfiles-CompatibleUserName.1658909608 --- https://github.com/openponk/uml-profiles.git[master] --- https://github.com/openponk/uml-profiles.git[master]
I got an error while cloning: There was an authentication error while trying to execute the operation: . 
This happens usually because you didn't provide a valid set of credentials. 
You may fix this problem in different ways: 

1. adding your keys to ssh-agent, executing ssh-add ~/.ssh/id_rsa in your command line.
2. adding your keys in settings (open settings browser search for "Use custom SSH keys" and
add your public and private keys).
IceGenericError: error reading from the zlib stream
IceLibgitErrorVisitor>>visitGenericError:
IceLibgitErrorVisitor>>visitERROR:
LGit_GIT_ERROR>>acceptError:
[ :error |
        location exists ifTrue: [ location ensureDeleteAll ].
        error acceptError: (IceLibgitErrorVisitor onContext: self) ] in IceGitClone>>execute in Block: [ :error |...
FullBlockClosure(BlockClosure)>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
LGit_GIT_ERROR(Exception)>>signal
LGit_GIT_ERROR class(LGitCallReturnHandler class)>>signalWith:
LGitReturnCodeEnum>>handleLGitReturnCode
LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
LGitRepository>>clone:options:to:
LGitRepository>>clone:options:
[location ensureCreateDirectory.

    repo := LGitRepository on: location.
    cloneOptions := repo cloneOptionsStructureClass withCredentialsProvider: (IceCredentialsProvider defaultForRemoteUrl: url).

    "Keeping references, because if not the GC take them."
    checkoutOptions := cloneOptions checkoutOptions.
    callbacks := cloneOptions fetchOptions callbacks.
    callbacks transferProgress: IceGitTransferProgress new.

    checkoutOptions checkoutStrategy: LGitCheckoutStrategyEnum git_checkout_force.
    checkoutOptions progressCallback: IceGitCheckoutProgress new.

    repo clone: url options: cloneOptions.

    (LGitRemote of: repo named: 'origin')
        lookup;
        setUrl: url.

    ] in IceGitClone>>execute in Block: [location ensureCreateDirectory....
FullBlockClosure(BlockClosure)>>on:do:
IceGitClone>>execute
IceRepositoryCreator>>cloneRepository
[
        self validate.
        self isCloning
            ifTrue: [ self cloneRepository ]
            ifFalse: [ self addLocalRepository ] ] in IceRepositoryCreator>>createRepository in Block: [...
FullBlockClosure(BlockClosure)>>on:do:
IceRepositoryCreator>>createRepository
[ repository := builder createRepository ] in MCGitHubRepository(MCGitBasedNetworkRepository)>>createIcebergRepositoryFor: in Block: [ repository := builder createRepository ]
FullBlockClosure(BlockClosure)>>on:do:
MCGitHubRepository(MCGitBasedNetworkRepository)>>createIcebergRepositoryFor:
[ ^ self createIcebergRepositoryFor: urlToUse ] in MCGitHubRepository(MCGitBasedNetworkRepository)>>createIcebergRepositoryWithFallbackFor:url: in Block: [ ^ self createIcebergRepositoryFor: urlToUse ]
FullBlockClosure(BlockClosure)>>on:do:
MCGitHubRepository(MCGitBasedNetworkRepository)>>createIcebergRepositoryWithFallbackFor:url:
[ | remote |
            remote := IceGitRemote url: remoteUrl.
            self createIcebergRepositoryWithFallbackFor: remote url: remoteUrl ] in MCGitHubRepository(MCGitBasedNetworkRepository)>>getOrCreateIcebergRepository in Block: [ | remote |...
OrderedCollection(Collection)>>detect:ifFound:ifNone:
OrderedCollection(Collection)>>detect:ifNone:
MCGitHubRepository(MCGitBasedNetworkRepository)>>getOrCreateIcebergRepository
3. using HTTPS instead SSH (Just use an url in the form https://etc.git)./ I will try to clone the HTTPS variant.

Error with status code 1:
653 travis_wait /home/runner/.smalltalkCI/helpers.sh

Source of the log: https://github.com/OpenPonk/class-editor/runs/7543017828?check_suite_focus=true

Probably related to https://github.com/pharo-vcs/iceberg/issues/1600 and https://github.com/hpi-swa/smalltalkCI/issues/562

[kasperosterbye]

I am bitten by this in an other project (pillar-markup/Microdown).

I believe it is related to https://github.com/pharo-project/pharo/issues/11222.

[badetitou]

Yes, It kills all my projects and Moose projects

[guillep]

Is this happening for GitHub actions only? or others too?

[JanBliznicenko]

Is this happening for GitHub actions only? or others too?

@guillep I use only GitHub actions, unfortunately, but @badetitou said in https://github.com/hpi-swa/smalltalkCI/issues/562#issuecomment-1198182062 that GitLab works fine for him

[badetitou]

Note that some GitHub actions work randomly (maybe if the baseline load only a few dependencies) It is the case for

• https://github.com/badetitou/Carrefour
• https://github.com/moosetechnology/Fast-Java

GitHub

GitHub - badetitou/Carrefour: Binding between Famix and FAST

Binding between Famix and FAST. Contribute to badetitou/Carrefour development by creating an account on GitHub.

GitHub

GitHub - moosetechnology/FAST-JAVA

Contribute to moosetechnology/FAST-JAVA development by creating an account on GitHub.

[JanBliznicenko]

Most of my projects use Moose and all these fail consistently at the time it usually fetches the Moose, but that is probably because the Moose is large. My small projects with few simple dependencies (and no Moose) seem to mostly work, but some of them not (and these fail always the same time as well).

[kasperosterbye]

I get it not when building, but this piece of code in a fresh image (before I apply my github credentials)

IceGitHubAPI new in: [ :api |   50 timesRepeat:  [ api get: 'repos/pillar-markup/Microdown']     ]

However, I am not sure it is related.

[badetitou]

Does it work after setting up credentials?

[kasperosterbye]

After credentials I can do around 5000 api calls per hour, which so far has been enough. It is in the iceberg wiki.

But how to make sure the credentials are set in the CI I have no idea. Also, I have no idea why the CI is suddenly broken.

[Rinzwind]

After doing this:

#(
    'https://github.com/SeasideSt/Seaside-Legacy30'
    'https://github.com/pharo-project/pharo-zeroconf.git'
    'https://github.com/pharo-project/pharo.git'
    'https://github.com/pharo-project/pharo-launcher.git'
    'https://github.com/pharo-project/pharo-vm.git'
    'https://github.com/pharo-project/pharo-site.git'
    'https://github.com/pharo-project/pharo-changelogs.git'
    'https://github.com/pharo-project/pharo-core.git'
) do: [ :url |
    Transcript show: url; cr.
    [
        IceRepositoryCreator new 
            url: url;
            location: FileLocator temp / ('IceRepositoryCreator Test ' , Time microsecondClockValue asString);
            createRepository
    ] on: Error do: [ :error |
        Transcript show: error asString; cr ]
] separatedBy: [ Transcript cr ]

My Transcript shows:

https://github.com/SeasideSt/Seaside-Legacy30
IceGenericError: error reading from the zlib stream

https://github.com/pharo-project/pharo-zeroconf.git

https://github.com/pharo-project/pharo.git
IceGenericError: error reading from the zlib stream

https://github.com/pharo-project/pharo-launcher.git

https://github.com/pharo-project/pharo-vm.git
IceGenericError: bad packet length

https://github.com/pharo-project/pharo-site.git
IceGenericError: bad packet length

https://github.com/pharo-project/pharo-changelogs.git

https://github.com/pharo-project/pharo-core.git
IceGenericError: error reading from the zlib stream

So: 3 OK, 2 times ‘bad packet length’ and 3 times ‘error reading from the zlib stream’.

[badetitou]

I try setting up the token as described in the Iceberg wiki and proposed by @kasperosterbye in https://github.com/moosetechnology/Moose/commit/30d5dc67beaa3d28103e845ebba2e29e60d93af1 It does not work

Yes I have killed this token in my personal account right after the test

[badetitou]

GitHub action virtual environment has changed the 20220724. Maybe it created the problem for us (updating of one lib) https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-Readme.md

GitHub

virtual-environments/Ubuntu2004-Readme.md at main · actions/virtual-environments

GitHub Actions virtual environments. Contribute to actions/virtual-environments development by creating an account on GitHub.

[badetitou]

And also, we have this issue now

MetacelloNameNotDefinedError: project group, or package named: 'FileTree' not found when used in requires: or includes: field of package: 'Metacello-FileTree' for version: baseline of BaselineOfMetacello.

[Rinzwind]

I suspect the problem has to do with the following point in the changes listed for libgit2 v1.0.1:

• A bug where the smart HTTP transport could not read large data packets has been fixed. Previously, fetching from servers like Gerrit, that sent large data packets, would error.

The following gives v1.0.0 as the version of libgit2 used in Pharo:

LGitLibrary uniqueInstance version "=> #(1 0 0)"

Using that version of libgit2, the C program given below reproduces the error:

$ ./test 
libgit2 version: 1.0.0
cloning to: /tmp/libgit2_clone_test.uhfXQw
git_clone returned: -1
error message: error reading from the zlib stream

Upgrading to v1.0.1 fixes the error:

$ ./test 
libgit2 version: 1.0.1
cloning to: /tmp/libgit2_clone_test.TBNpFL
git_clone returned: 0

I used MacPorts to install the different versions of libgit2, making use of the instructions on the page “How to install an older version of a port”. The ‘Portfile’ for v1.0.1 can be found in: https://github.com/macports/macports-ports/commit/abe3087564d83e7e. A diff for v1.0.0 is given below.

test.c:

#include <unistd.h>
#include <stdio.h>
#include <git2/global.h>
#include <git2/clone.h>
#include <git2/errors.h>

int main() {
    int major, minor, rev;
    git_libgit2_init();
    if (git_libgit2_version(&major, &minor, &rev) != 0) {
        printf("git_libgit2_version failed\n");
        return 1;
    }
    printf("libgit2 version: %i.%i.%i\n", major, minor, rev);
    char dir[] = "/tmp/libgit2_clone_test.XXXXXX";
    if (mkdtemp(dir) == NULL) {
        printf("mkdtemp failed\n");
        return 1;
    }
    printf ("cloning to: %s\n", dir);
    git_repository *repo;
    int value = git_clone(&repo, "https://github.com/SeasideSt/Seaside-Legacy30", dir, NULL);
    printf("git_clone returned: %i\n", value);
    const git_error *error = git_error_last();
    if (error != NULL)
        printf("error message: %s\n", error->message);
    return (value == 0) ? 0 : 1;
}

Makefile:

test: test.c
    cc -I/opt/local/include -L/opt/local/lib test.c -o test -lgit2

Portfile diff:

diff --git a/devel/libgit2/Portfile b/devel/libgit2/Portfile
index 7c7d6c532e0..e8120559c40 100644
--- a/devel/libgit2/Portfile
+++ b/devel/libgit2/Portfile
@@ -9 +9 @@ PortGroup           legacysupport 1.0
-github.setup        libgit2 libgit2 1.0.1 v
+github.setup        libgit2 libgit2 1.0.0 v
@@ -27,3 +27,3 @@ homepage            https://libgit2.org/
-checksums           rmd160  3f9ced0e0dff170a8156e4aa8fcb0abce66c8f60 \
-                    sha256  5dae7cb32b6977cd95ed849d24f3692f0b7e9eb9b0ee9ffaa14baebb9cac76e1 \
-                    size    5304918
+checksums           rmd160  f46ca0500f159e058d854ed6aeb8d4418420b419 \
+                    sha256  1d3135077f7b0401c1172e41f561cadd06fd159e75aa24d710de1bd3a24b1440 \
+                    size    5302852

[badetitou]

I can confirm that version 1.0.0 is used in the CI https://github.com/moosetechnology/Moose/runs/7626118950?check_suite_focus=true#step:4:65

GitHub

CI should use https · moosetechnology/Moose@a41ce25

MOOSE - Platform for software and data analysis. . Contribute to moosetechnology/Moose development by creating an account on GitHub.

[JanBliznicenko]

Was not the libgit 1.0.0 there the whole time? I wonder why is it problem now. Maybe GitHub changed something about data transfers (since GitLab does not seem affected)?

[Rinzwind]

The description of the change in libgit2 I referred to says “fetching from servers like Gerrit, that sent large data packets, would error.” I assume GitHub just didn’t send large data packets before but now does.

[gcotelli]

Sadly, the error seems to be a bit random. I've run again the failing builds and sometimes fail but other times don't. And for jobs having a build matrix, they failed for some configurations but not for others, even when the only difference is the packages loaded.

[gcotelli]

I was able to reproduce the problem without using GitHub actions at all, but by doing a docker build in my notebook. The first 2 times it failed with IceGenericError: error reading from the zlib stream and IceGenericError: bad packet length, but the third time worked.

[jbrichau]

As mentioned in https://github.com/pharo-project/pharo/issues/11481#issuecomment-1201163105, libgit2 needs an update in the Pharo vm... where does this need to be reported to get it done?

[Ducasse]

Here but the team is on vacation :( I will see if we can do something with christophe monday. And yes we will have to make sure that not everybody is on vacation at the same time.

[Ducasse]

It is a bit crazy that such changes are not backward compatible. :( and impacts everybody.

[jbrichau]

@Ducasse thanks for the reply Stef. I suspected that France is in holiday mode right now ;-). Just wanted to make sure it reaches the right people.

[Ducasse]

It does :) we got impacted too. I cannot build some of my projects and not even load the code :(

[estebanlm]

I'm working on this. I will have news tomorrow :)

[badetitou]

Is this happening for GitHub actions only? or others too?

I have some GitLab project that fails with the same error now

[estebanlm]

hello back, sadly, I have not yet a solution here... I am on holidays and my times to dedicate to this issue (or any) are (very)limited. In any case what I dug here is:

1. nothing changed from our side, VMs are still the same, and code is still the same.
2. hence, something had to change from the other side, which seems to be the case :)
3. libgit2 library may have become incorrect for the context, and we are using for the zeroconf version a pre-built library that we put on the path (see here: https://github.com/guillep/libgit_build).
4. I do not have the elements with me here to build a new one myself.

Ultimately, the right way to do this would be to not use zeroconf for the CI (since is very hard to ensure it will always work) and rely on the OBS versions (https://build.opensuse.org/package/show/devel:languages:pharo:latest/pharo9) which should provide the right working version. I understand that would be maybe too radical, but eventually that would be the path... So, I would like to suggest two tests I can't do right now to see if we can untangle this:

1. remove libgit2 from the downloaded zeroconf vm as an extra step before running the tests from CI to let pharo rely on the system libgit2 (ensuring it is present).
2. figure out how to use the OBS version.

Of course first one is a lot easier, but Ideally we should have a dockerized github action that encapsulates all this (version 2) and makes the running of tests better (maybe @gcotelli can help here? in Argentina is winter, no holidays there! :P)

[Rinzwind]

@estebanlm, about:

3. libgit2 library may have become incorrect for the context […]

See my comment from August 1st: my ‘test.c’ reproduces the error with libgit2 v1.0.0, but not with libgit2 v1.0.1. The relevant change between those versions is probably the fix for “a bug where the smart HTTP transport could not read large data packets” as stated in the changes listed for libgit2 v1.0.1.

[estebanlm]

yes, I know that... but that does not change the fact that 1.0.0 was working and now it doesn't so they changed something. and that does not changes the fact that I can't build a new zeroconf version with the right library at the moment ;)

On Aug 10 2022, at 3:58 pm, Kris @.***> wrote:

@estebanlm (https://github.com/estebanlm), about:

libgit2 library may have become incorrect for the context […] See my comment from August 1st (https://github.com/pharo-project/pharo/issues/11481#issuecomment-1201163105): my ‘test.c’ reproduces the error with libgit2 v1.0.0, but not with libgit2 v1.0.1. The relevant change between those versions is probably the fix for “a bug where the smart HTTP transport could not read large data packets” as stated in the changes listed for libgit2 v1.0.1 (https://github.com/libgit2/libgit2/releases/tag/v1.0.1).

— Reply to this email directly, view it on GitHub (https://github.com/pharo-project/pharo/issues/11481#issuecomment-1210713248), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAD5MXRZPSQGYABJFHMJ4G3VYOYP5ANCNFSM542EGMHQ). You are receiving this because you were mentioned.

[Rinzwind]

@estebanlm OK no problem, I couldn’t quite tell from your comment whether you had read that so just wanted to make sure. I assume that what changed is that GitHub started sending large data packets too, and perhaps GitLab now as well (per @badetitou’s earlier comment).

[estebanlm]

yeah. And we need to adapt, of course... just the timing of the change is the worst for us :( that's why I was suggesting as a workaround to just remove libgit2 and rely on the one provided by the system.

On Aug 10 2022, at 4:09 pm, Kris @.***> wrote:

@estebanlm (https://github.com/estebanlm) OK no problem, I couldn’t quite tell from your comment whether you had read that so just wanted to make sure. I assume that what changed is that GitHub started sending large data packets too, and perhaps GitLab now as well (per @badetitou’s earlier comment (https://github.com/pharo-project/pharo/issues/11481#issuecomment-1210649509)). — Reply to this email directly, view it on GitHub (https://github.com/pharo-project/pharo/issues/11481#issuecomment-1210727425), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAD5MXXE5NQ47XDL7YE6IZDVYOZYLANCNFSM542EGMHQ). You are receiving this because you were mentioned.

[Rinzwind]

OK, I see that LGitLibrary>>#macLibraryName tries to find libgit2.1.0.1.dylib first, so I installed that version through MacPorts again. Then I can run the VM with LD_LIBRARY_PATH set to the MacPorts lib directory:

$ LD_LIBRARY_PATH=/opt/local/lib "${pharovm:?}" "${pharoimage:?}"

And LGitLibrary uniqueInstance version returns #(1 0 1).

[badetitou]

OK, I see that LGitLibrary>>#macLibraryName tries to find libgit2.1.0.1.dylib first, so I installed that version through MacPorts again. Then I can run the VM with LD_LIBRARY_PATH set to the MacPorts lib directory:

$ LD_LIBRARY_PATH=/opt/local/lib "${pharovm:?}" "${pharoimage:?}"

And LGitLibrary uniqueInstance version returns #(1 0 1).

I also try to install the last version of libgit and I overwrite the way LGitLibrary find the libgit.so to find my version.

LGitLibrary found my lib. But then it fails. I imagine that the binding must be changed with the last version of libgit

Bug in gitlab

I imagine bugs in gitlab comes because I load project from GitHub in the gitlab ci

[gcotelli]

There's a workaround at least with GitHub actions and it's to re-run the failing steps until they pass. :see_no_evil: And you can run only the failed configurations in the matrix and let the passing ones as is.

[badetitou]

There's a workaround at least with GitHub actions and it's to re-run the failing steps until they pass. :see_no_evil: And you can run only the failed configurations in the matrix and let the passing ones as is.

Does not work for Moose. There is toooo much dependency loaded even for one configuration.

But great for little project 😁

[Rinzwind]

@badetitou, about:

I also try to install the last version of libgit and I overwrite the way LGitLibrary find the libgit.so to find my version.

LGitLibrary found my lib. But then it fails.

I tried with libgit2 v1.5.0. Then this didn’t work:

(MCGitHubRepository location: 'github://SeasideSt/Seaside-Legacy30/repository') getOrCreateIcebergRepository

It made the VM crash:

Pharo(24248,0x10616de00) malloc: Incorrect checksum for freed object 0x7fd1f91730e0: probably modified after being freed.

It does work with libgit2 v1.0.1. The MacPorts ‘Portfile’ for v1.0.1 is in: https://github.com/macports/macports-ports/commit/abe3087564d83e7e. There’s a page on their wiki which explains “How to install an older version of a port”. Homebrew can probably also be used, but I’m not that familiar with it so I don’t know how.

[estebanlm]

yeah, in linux until now we are compatible until 1.4 if you check in LGitLibrary>>unix64LibraryName, you will see the list. you may just add 1.5 to that list and see what happens (sometimes is compatible, sometimes there are changes that break).

On Aug 11 2022, at 9:39 am, Kris @.***> wrote:

@badetitou (https://github.com/badetitou), about:

I also try to install the last version of libgit and I overwrite the way LGitLibrary find the libgit.so to find my version. LGitLibrary found my lib. But then it fails. I tried with libgit2 v1.5.0. Then this didn’t work:

(MCGitHubRepository location: 'github://SeasideSt/Seaside-Legacy30/repository') getOrCreateIcebergRepository

It made the VM crash: Pharo(24248,0x10616de00) malloc: Incorrect checksum for freed object 0x7fd1f91730e0: probably modified after being freed.

It does work with libgit2 v1.0.1. The MacPorts ‘Portfile’ for v1.0.1 is in: @.*** (https://github.com/macports/macports-ports/commit/abe3087564d83e7e). There’s a page on their wiki which explains “How to install an older version of a port” (https://trac.macports.org/wiki/howto/InstallingOlderPort). Homebrew (https://formulae.brew.sh/formula/libgit2) can probably also be used, but I’m not that familiar with it so I don’t know how. — Reply to this email directly, view it on GitHub (https://github.com/pharo-project/pharo/issues/11481#issuecomment-1211648680), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAD5MXVWLHCLDWBQZG3S2LDVYSU2HANCNFSM542EGMHQ). You are receiving this because you were mentioned.

[guillep]

I cannot reproduce the issue on my ARM64 OSX...

@gcotelli can you share your docker setup? is it a normal pharo docker from ba-st? https://github.com/ba-st/docker-pharo-runtime?

We have found that ARM64 builds are shipped with libssh 1.9 while x64 builds are shipped with libssh 1.7 We are working on upgrading it, but we would like a reproducible case so we can test if it's effectively fixed.

GitHub

GitHub - ba-st/docker-pharo-runtime: Docker image for Pharo

Docker image for Pharo. Contribute to ba-st/docker-pharo-runtime development by creating an account on GitHub.

[guillep]

I confirm that executing the script above reproduces it in a docker container.

#Dockerfile
FROM ghcr.io/ba-st/pharo:v10.0.0
COPY doit.st .
RUN pharo doit.st

"doit.st"
#(
    'https://github.com/SeasideSt/Seaside-Legacy30'
    'https://github.com/pharo-project/pharo-zeroconf.git'
    'https://github.com/pharo-project/pharo.git'
    'https://github.com/pharo-project/pharo-launcher.git'
    'https://github.com/pharo-project/pharo-vm.git'
    'https://github.com/pharo-project/pharo-site.git'
    'https://github.com/pharo-project/pharo-changelogs.git'
    'https://github.com/pharo-project/pharo-core.git'
) do: [ :url |
    Transcript show: url; cr.
    [
        IceRepositoryCreator new 
            url: url;
            location: FileLocator temp / ('IceRepositoryCreator Test ' , Time microsecondClockValue asString);
            createRepository
    ] on: Error do: [ :error |
        Transcript show: error asString; cr ]
] separatedBy: [ Transcript cr ]

docker build .

Output

=> => # IceGenericError: error reading from the zlib stream
 => => # https://github.com/pharo-project/pharo-site.git
 => => # IceGenericError: bad packet length
 => => # https://github.com/pharo-project/pharo-changelogs.git
 => => # https://github.com/pharo-project/pharo-core.git
 => => # IceGenericError: error reading from the zlib stream
 ...

[Rinzwind]

@guillep about:

I cannot reproduce the issue on my ARM64 OSX...

I assume that’s because it’s using libgit2 v1.0.1, as the following shows that pharo-vm-Darwin-arm64-stable.zip includes libgit2.1.0.1.dylib (while pharo-vm-Darwin-x86_64-stable.zip includes libgit2.1.0.0.dylib but not libgit2.1.0.1.dylib).

$ for z in pharo-vm-Darwin-arm64-stable.zip pharo-vm-Darwin-x86_64-stable.zip; do
    curl --silent --output $z http://files.pharo.org/get-files/100/$z &&
    sha256sum $z &&
    zipinfo -1 $z '*libgit2*'
  done
697b68460ce0338b1399497c03f94858f40f7695b814daf2ac063d4d916b2881  pharo-vm-Darwin-arm64-stable.zip
Pharo.app/Contents/MacOS/Plugins/libgit2.1.0.1.dylib
Pharo.app/Contents/MacOS/Plugins/libgit2.1.0.dylib
Pharo.app/Contents/MacOS/Plugins/libgit2.dylib
95d1dcae804df89b3d09b9a0cf9832f735649507cc8ad01e59aa470c2ab2341d  pharo-vm-Darwin-x86_64-stable.zip
Pharo.app/Contents/MacOS/Plugins/libgit2.0.25.1.dylib
Pharo.app/Contents/MacOS/Plugins/libgit2.1.0.0.dylib
Pharo.app/Contents/MacOS/Plugins/libgit2.25.dylib
Pharo.app/Contents/MacOS/Plugins/libgit2.dylib

[guillep]

I assume that’s because it’s using libgit2 v1.0.1, as the following shows that pharo-vm-Darwin-arm64-stable.zip includes libgit2.1.0.1.dylib (while _pharo-vm-Darwin-x8664-stable.zip includes libgit2.1.0.0.dylib but not libgit2.1.0.1.dylib).

That's not the only difference. ARM64 vms are distributed with newest versions of libssh2 and openssl.

We are now working on upgrading the distributed binaries to libgit2 v1.4.4, libssh2 v1.9.0 and openssl v1.1.1k.

We should have news by tomorrow.

[guillep]

Just to tell that we have confirmed that the combo of libs above works (libgit2 v1.4.4, libssh2 v1.9.0 and openssl v1.1.1k)!

We are building everything and working on providing new distributable VMs!

[badetitou]

Does the fix will work for old version of Pharo? ( I'm thinking from Pharo 9 to 11 )

Thanks a lot for your work

[guillep]

It requires not only upgrading lib versions in the distributable VMs, but also upgrading code in the libgit bindings. We have tested the general setup on linux and osx so far and it's ok. We are working now on

• an iceberg + libgit binding release to point to the new libs
• making a VM release with the new libraries

That should make the patch available for latest Pharo11, making it available for Pharo10 requires a new Pharo10 release pointing to the new iceberg release. Making it for Pharo9 will require probably the same plus a bit of testing.

[guillep]

Progress can be followed in here

[DONE] Upgrading Libgit bindings:

• changes: https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c3170d2f19a984a54c01a294b
• release: https://github.com/pharo-vcs/libgit2-pharo-bindings/releases/tag/v2.2.6

[DONE] Upgrading Iceberg:

• pr: https://github.com/pharo-vcs/iceberg/pull/1605
• release: https://github.com/pharo-vcs/iceberg/releases/tag/v2.0.7

[DONE] Upgrading library dependencies in the VM: https://github.com/pharo-project/pharo-vm/pull/447

• [DONE] Linux (x86-64, ARM64, ARM32)
• [DONE] OSX (x86-64, ARM64)
• [LATER] Windows (x86-64, ARM64)
• [DONE] Release VM 9.0.16 https://github.com/pharo-project/pharo-vm/releases/tag/v9.0.16

[DONE] Update Pharo 10 with iceberg release https://github.com/pharo-project/pharo/pull/11545

[DONE] Update Pharo 9 with iceberg release https://github.com/pharo-project/pharo/pull/11546

[LATER] Upgrading library dependencies in the Windows VM (x86-64, ARM64)

[gcotelli]

I'm getting a segmentation fault running smalltalkCI, it looks like it's using the newer VM. The revision is v9.0.16 but the version is Pharo 9.0.15. Need these two values to be the same?:

Segmentation fault Fri Aug 19 16:50:00 2022

/home/runner/.smalltalkCI/_cache/vms/Pharo64-10/pharo-vm/lib/pharo
PharoVM version:5.0-Pharo 9.0.15 built on Aug 19 2022 16:12:41 Compiler: 5.4.0 20160609 5.4.0 20160609 [Production Spur 64-bit VM]
Built from: CoInterpreter * VMMaker-tonel.1 uuid: 99807766-faa2-0d00-90d7-7066092bce84 Aug 19 2022
 With:StackToRegisterMappingCogit * VMMaker-tonel.1 uuid: 99807766-faa2-0d00-90d7-7066092bce84 Aug 19 2022
 Revision: v9.0.16 - Commit: 5de0bf0 - Date: 2022-08-19 15:35:38 +0200

The image version is:

Pharo10.0.0
Build information: Pharo-10.0.0+build.523.sha.d67dd1ef55ff7967b3afa26b9e1d44844748f384 (64 Bit)

[JanBliznicenko]

Does this all mean that these new Pharo releases require new VM releases and these are incompatible with older ones? So, Pharo 9 image from month ago is incompatible with todays VM and vice versa, right?

(and confirm the segfault in my repos, see https://github.com/OpenPonk/openponk/runs/7929905675?check_suite_focus=true )

[Rinzwind]

@guillep Any news? Given the reports of segmentation faults with the new VM, I was thinking: maybe do a smaller update of the libraries first? As far as I know, updating libgit2 to v1.0.1 suffices to fix the cloning problem (see ‘test.c’ in my comment from August 1st). It would help to already have that.

[jbrichau]

Possibly related issue: https://github.com/pharo-project/pharo/issues/11561

[guillep]

Hi all, we are working on this right now.

• we mistakingly replaced libgit1.0.1 by 1.4.4 in OSX ARM64 versions, breaking compatibility with old images => we are now making it have both versions for compatibility reasons
• the linux versions were compiled for newer versions of libc than the ones found in CI servers => we are recompiling them in an older *nix