<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi all!<div><br></div><div>Build version 19647 is not Squeak 5.3. It is Trunk, 6.0alpha. The Squeak release version 5.3 is at build 19438.</div><div><br></div><div>If you start updating an older 5.3alpha image, you end up with 6.0alpha, not the 5.3 release version.</div><div><br></div><div>@Tim: If you want to run all the tests after such an update, make sure to run "ReleaseBuilder prepareSourceCode; prepareEnvironment" first. Maybe take a look at ReleaseBuilder class >> #saveAsNewClean.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 11.05.2020 02:07:19 schrieb tim Rowledge <tim@rowledge.org>:</p><div style="font-family:Arial,Helvetica,sans-serif"><br><br>> On 2020-05-10, at 1:58 PM, David T. Lewis <lewis@mail.msen.com> wrote:<br>> <br>> On Sun, May 10, 2020 at 11:50:35AM -0700, tim Rowledge wrote:<br>>> More results in digging into this list of failures - <br>>> <br>>> A partial explanation for the failed socket (not just the SSL) tests - I remembered that we recently decided to turn on the IPv6 switch to see what happens. Well, on a Pi all the socket tests fail. Turn off IPv6 and they all pass. Sigh. Is there some magic I would need to do to turn on IPv6 on Raspbian? Is it a compile flag issue in the VM build?<br>>> <br>> <br>> The IPv6 primitives are all in SocketPlugin. I would not expect the actual primitives<br>> to work any differently, but as Windows users have noticed there are definitely<br>> differences in the resolvers on different platforms, and you may be hitting issues<br>> related to that. Also, I think that some of our network code assumes that there<br>> is such a thing as "the IP address of my computer", which is generally wrong and<br>> probably causes mischief in some of the tests. My best suggestion would be just<br>> to step slowly though any of the failing tests and see if you can spot where<br>> it's getting confused.<br>> <br>> Also, try turning off the "EnableIPv6" preference and see if the tests start passing.<br><br>Yup, done that - " Turn off IPv6 and they all pass."<br><br>I've also now tried the test on a Mac 64bit system and the socket (and SSL of course) tests fail there too.<br><br>I had to exclude the AllocationTest stuff since that just tried to eat the Mac when I attempted it.<br><br>For extra fun, on the Mac FloatTest>>#testTimesTwoPowerGradualUnderflow failed where it did not on Pi. As did the PolygonMorphTest>testContainsPoint. Quite what would make them different I can't see right now.<br><br><br><br><br>tim<br>--<br>tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>Strange OpCodes: BYEBYE: Store in Write-Only Storage<br><br><br><br></lewis@mail.msen.com></div></blockquote></div>