> Am 05.12.2024 um 13:49 schrieb Guillermo Polito <guillermopol...@gmail.com>: > >>> I've rolled the stable version back to 10.3.1, please test. >> >> thanks, that means the 10.3.1 is still build with ubuntu and 10.3.2 is >> debian based? > > The binary for version 10.3.1 was built on ubuntu 16 or 18 I think, maybe > Christophe or Pablo can give more details, I don’t recall it right now. > > 10.3.2 was built on the new linux server infrastructure. > > $ uname -a > Debian 6.1.99-1 (2024-07-15) x86_64 GNU/Linux > > We are evaluating different alternatives (e.g., downgrading the build server > for a while). > >> Just to be sure. In that case it would be nice to have a way to download >> precisely 10.3.1 in order to stay safe and we have time to plan >> countermeasure. > > If you want to control what you download, right now the safest way is to go > to files.pharo.org <http://files.pharo.org/>, more precisely to > https://files.pharo.org/vm/pharo-spur64/, and look for your architecture.
ok, thanks. > > There you will find the archives with the binaries we built. > Details about naming conventions are found here: > https://github.com/pharo-project/pharo-vm/wiki/About-Build-and-Artifacts > > That file server stores both released artifacts and intermediate build > results. > The released artifact is the first artifact with the corresponding version > tag (e.g., 10.3.1, 10.2.0). > This is generally the oldest in timestime, but you can confirm with the tags > on github. > > Moreover, the general advice is to avoid zeroconf as much as possible. > We don’t have the manpower to maintain build farms for each possible linux > flavor. Agreed. It is really hard to do. The only way would be to extract them from the OBS build. OBS's purpose is to have that build farm building all flavors. So if there would be a way to extract files from there and adjusting the zeroconf bash script it would be feasible. But probably not really easy to do. > > Internally, we recently started discussing the deprecation of zeroconf and > the migration path to OBS for *nixes. That would be really sad because it is super handy. But it would also be understandable to shut down it down when it does the wrong thing. > The early sketch is that each released version will have its own package in > OBS. This is inevitable. > Then a virtual package will gather them all together (and help people update > or downgrade on need) This is nice but less important then the above. > More of this will come soon. > cool > >> I think on one of the issues there was a mentioning that Kris add some patch >> for their CI. > > I’m not aware of this, can you post a link here? > https://discord.com/channels/223421264751099906/492279831216783360/1314169201883353090 >> Maybe this is a good addition to zeroconf? Or can this be achieved >> differently > > Zeroconf worked very well until now, and we have put lot of effort in its > modernization lately. > However, as it is it has problems to scale: > - executing an untrusted script that downloads unverified binaries that is a user choice, putting a warning label is sufficient. > - we manage only one nix build, which works only as soon as all nixes keep > compatibility with the version we built on see above > - it is designed to expose two versions: latest and stable. to my memory these versions are fully arbitrary so you could remove them to gain at least clarity. > > Much of this is solved by OBS, and we hope this improves our stability and > visibility. > >> >> Overall this is quite unfortunate. I hope there will be a better solution >> then everyone has to build their own vms. I think I need to plan some time >> to do it. > > We understand, and believe me, it’s unfortunate for us too. > We are working on it and hope to have some news in the following weeks. > >>> >>> @Norbert et al, we identified at least two issues: >>> - a glibC incompatibility with Ubuntu 20.04 that arises because recently >>> the build servers changed to a Debian, so all zeroconf users are impacted >>> (except those using stable debian). >> >> I can confirm that. The segfault was always in ZdcSocketStream when >> accessing a native glibc function. Sadly the console I cannot see anymore >> because too many builds in between. > > Thanks, could you share your OS/setup ? (uname -a probably is enough). Ubuntu 22.04 Linux fe1102acfb5f 5.15.0-122-generic #132-Ubuntu SMP Thu Aug 29 13:45:52 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux that is based on a docker ubuntu:22.04 > > Also, anybody having a couple of minutes to test and help, if you see this > issue locally, could you > - build a VM (https://github.com/pharo-project/pharo-vm/), checking out tag > v10.3.2 > - run locally the failing tests I will take that for creating a vm build on my CI. > > This information could help us reduce the search space, and identify if it’s > just the build environment or there is something else we have to deal with. > Yes, you should have some procedure how to get data so we can help. And everyone complaining about instability is suspect to exactly follow that :) thanks again, Norbert > Cheers, > G
