Hi Luke, On 19 January 2018 at 10:17, Luke Gorrie <[email protected]> wrote: > Hi Esteban, > > I am really happy that everything is working so well for you and I hope that > other people are having a similar experience. > > For me it's another story. I'm on an unsupported platform (NixOS Linux), I'm > building the VM from random git commits because the source releases are all > antiquated, Iceberg segfaults the moment I start it,
Are you building 32 or 64 bit VMs? My experience has been that 64 bit VMs on linux have problems with libgit2. If you can use 32 bit VMs for now you might get better stability. I'm currently running: 5.0-201801110739 Thursday 11 January 09:30:12 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 VM: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Wed Jan 10 23:39:30 2018 -0800 $ Plugins: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/core/3748/lib/i386-linux-gnu/ [default: /snap/core/3748/lib/i386-linux-gnu/] without any problems. I've tried looking at the libgit2 issue in a debug vm, but (with my meagre skills): - the memory corruption isn't consistent, i.e. the crash occurs in different places on multiple runs - the crash doesn't occur until sometime after the corruption :-( HTH, Alistair > and > epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of > obstacles between me and maintaining my application. > > The way I am coping is to scale back my ambitions. I spent a lot of time > making a complete packaging for NixOS but without proper source releases > from upstream that was too much work so I abandoned it. I take the > non-reproducible builds from Jenkins and import them as binary-blobs into > the build environment that I actually want to use. I accumulate fixes as > changesets in a patches/ directory instead of sending them upstream. > > To me it's a slap in the face when you tell me that it's so simple, there is > only one true way to contribute to Pharo, and the first step of that > procedure is to *install a binary that is not compatible with my Linux > distribution.* > >
