Hi, a later announcement (this have been done some months ago... but I
never send the mail).
We have upgraded in Pharo 9 to use the latest stable version of Libgit.
It required to have some improvements in Libgit to handle the updated
version and also to support the previous version.
From the point of view of new features, it does not add new things.
However, this version fixes a lot of existing problems in Libgit.
We can be sure this was a successful deployment as we don't have
problems with it. We are really happy that this has been done
transparently and keeping the working version with different
configurations of images and VMs. As we should support new and old
images, on the same VM. And also running new images in old VMs
Thanks.
--
Pablo Tesone.
tesonep@gmail.com
Thanks, this is great news.
Are there instructions on how to make P9 actually use the new version of
libgit2? I see that the stable Linux VM for 9.0 does include
"libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1.
...this may be because Pharo's libgit2.1.0.0.so has not-found
dependencies on libpcre.so.3 and libpcreposix.so.3.
I find Debian's versioning of libpcre somewhat confusing. The package
"libpcre3" is the old libraries, and new stuff is supposed to use
"pcre2." 2 is apparently newer than 3. At any rate PCRE library naming
is rather distro-specific, and although I have the right packages
installed, the libraries have different filenames.
But libgit2 is not supposed to have PCRE as a dependency. The source
code for PCRE is included in the source for libgit2. Seems like it would
be possible (and nice!) to compile the libgit2.1.0.0.so included with
the VM to include the PCRE code internally, rather than depend on an
external library.
Thanks,
-Martin
On 10/12/20 2:26 AM, tesonep@gmail.com wrote:
Hi, a later announcement (this have been done some months ago... but I
never send the mail).
We have upgraded in Pharo 9 to use the latest stable version of Libgit.
It required to have some improvements in Libgit to handle the updated
version and also to support the previous version.
From the point of view of new features, it does not add new things.
However, this version fixes a lot of existing problems in Libgit.
We can be sure this was a successful deployment as we don't have
problems with it. We are really happy that this has been done
transparently and keeping the working version with different
configurations of images and VMs. As we should support new and old
images, on the same VM. And also running new images in old VMs
Thanks.
Hi Martin,
thanks for testing it. Can you tell me the version / flavour of
Debian are you using?
Maybe we need to ship PCRE with the VM. I am not fun of that, but we
need to do it until we can have a proper packaging for each Linux
distribution (Esteban is working on having a nice OBS configuration
for the VM extending what Holger has previously done).
It takes time and a lot of testing, but the idea is to fix (or at
least control better) the dependency nightmare between different Linux
distributions.
Cheers,
Pablo
On Tue, Oct 13, 2020 at 7:49 AM Martin McClure martin@hand2mouse.com wrote:
Thanks, this is great news.
Are there instructions on how to make P9 actually use the new version of
libgit2? I see that the stable Linux VM for 9.0 does include
"libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1.
...this may be because Pharo's libgit2.1.0.0.so has not-found
dependencies on libpcre.so.3 and libpcreposix.so.3.
I find Debian's versioning of libpcre somewhat confusing. The package
"libpcre3" is the old libraries, and new stuff is supposed to use
"pcre2." 2 is apparently newer than 3. At any rate PCRE library naming
is rather distro-specific, and although I have the right packages
installed, the libraries have different filenames.
But libgit2 is not supposed to have PCRE as a dependency. The source
code for PCRE is included in the source for libgit2. Seems like it would
be possible (and nice!) to compile the libgit2.1.0.0.so included with
the VM to include the PCRE code internally, rather than depend on an
external library.
Thanks,
-Martin
On 10/12/20 2:26 AM, tesonep@gmail.com wrote:
Hi, a later announcement (this have been done some months ago... but I
never send the mail).
We have upgraded in Pharo 9 to use the latest stable version of Libgit.
It required to have some improvements in Libgit to handle the updated
version and also to support the previous version.
From the point of view of new features, it does not add new things.
However, this version fixes a lot of existing problems in Libgit.
We can be sure this was a successful deployment as we don't have
problems with it. We are really happy that this has been done
transparently and keeping the working version with different
configurations of images and VMs. As we should support new and old
images, on the same VM. And also running new images in old VMs
Thanks.
--
Pablo Tesone.
tesonep@gmail.com
tesonep@gmail.com wrote
Esteban is working on having a nice OBS configuration
for the VM extending what Holger has previously done
Awesome! I code on Mac, but this is super important to the community and
often for deployment...
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Pablo,
I run Gentoo stable on my main systems (though Ubuntu on others).
I ran an experiment this morning.
By default, when you build libgit2, it uses the system's PCRE library if
there is one.
However, if you build libgit2 with
cmake -DREGEX_BACKEND=builtin ../libgit2-1.0.0
cmake --build .
Then it builds libgit2 with PCRE support built-in from libgit2's own
copy of the PCRE sources, and gets rid of the external dependency.
Pharo seems to like the resulting library just fine.
Shipping libgit2.so with PCRE built-in seems like the cleanest
short-term solution.
I also noticed that in the stable 9.0 VM from June (which I believe is
the latest stable VM?) the libgit2 v1.0.0 library has the wrong name and
so P9 always loads the 0.25.1 version.
The shipped name:
libgit2.1.0.0.so
should be
libgit2.so.1.0.0
Thanks,
-Martin
On 10/13/20 1:20 AM, tesonep@gmail.com wrote:
Hi Martin,
thanks for testing it. Can you tell me the version / flavour of
Debian are you using?
Maybe we need to ship PCRE with the VM. I am not fun of that, but we
need to do it until we can have a proper packaging for each Linux
distribution (Esteban is working on having a nice OBS configuration
for the VM extending what Holger has previously done).
It takes time and a lot of testing, but the idea is to fix (or at
least control better) the dependency nightmare between different Linux
distributions.
Cheers,
Pablo
On Tue, Oct 13, 2020 at 7:49 AM Martin McClure martin@hand2mouse.com wrote:
Thanks, this is great news.
Are there instructions on how to make P9 actually use the new version of
libgit2? I see that the stable Linux VM for 9.0 does include
"libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1.
...this may be because Pharo's libgit2.1.0.0.so has not-found
dependencies on libpcre.so.3 and libpcreposix.so.3.
I find Debian's versioning of libpcre somewhat confusing. The package
"libpcre3" is the old libraries, and new stuff is supposed to use
"pcre2." 2 is apparently newer than 3. At any rate PCRE library naming
is rather distro-specific, and although I have the right packages
installed, the libraries have different filenames.
But libgit2 is not supposed to have PCRE as a dependency. The source
code for PCRE is included in the source for libgit2. Seems like it would
be possible (and nice!) to compile the libgit2.1.0.0.so included with
the VM to include the PCRE code internally, rather than depend on an
external library.
Thanks,
-Martin
On 10/12/20 2:26 AM, tesonep@gmail.com wrote:
Hi, a later announcement (this have been done some months ago... but I
never send the mail).
We have upgraded in Pharo 9 to use the latest stable version of Libgit.
It required to have some improvements in Libgit to handle the updated
version and also to support the previous version.
From the point of view of new features, it does not add new things.
However, this version fixes a lot of existing problems in Libgit.
We can be sure this was a successful deployment as we don't have
problems with it. We are really happy that this has been done
transparently and keeping the working version with different
configurations of images and VMs. As we should support new and old
images, on the same VM. And also running new images in old VMs
Thanks.
--
Pablo Tesone.
tesonep@gmail.com