As it happens I've just done a completely fresh load on an old Pi. J-R is correct - this doesn't work.


> On 2021-05-29, at 7:26 PM, John-Reed Maffeo <jrmaffeo at gmail.com> wrote:
> 
> Tested using Squeak5.3-19 for a fresh installation of RAS[BERRY PI OS (32-BIT) obtained using Raspberry Pi Imager v.1.6.1
> 
> The squeak install file was downloaded from:
> http://files.squeak.org/5.3/Squeak5.3-19435-32bit/Squeak5.3-19435-32bit-202003021730-ARMv6.zip

So, first observation in my case - Chrome stinks. Go ti squeak.org and click on the initial link that claims to download the ARMv6 linux system and .... nothing happens at all. Go to the downloads page and try there. Nothing happens at all. Is that a problem with our page code? Or just that, as mentioned above, Chrome is junk?

I eventually got a download from the files.squeak.org page, via the 5.3/Squeak5.3-19435-32bit/ directory.

And here we stumble across another longstanding issue with unix  stuff. Just where should the files go? And how do we (ie not-expert users) get them there? The zip file seems to be setup such that it will just create a directory named after the zip file and drop everything there. Given the bin/lib/shared directory names I can't help thinking that files are really intended to go to... what /usr/bin, /usr/lib, /usr/shared ? Or /usr/local etc? Or /var etc? Where? I realise the primary intent of unix has always been to destroy people's dreams but this stuff just infuriates me.

So, let's say we just accept the irritating Squeak5.3-19435-32bit-blahblahblah directory name and open a terminal there.  I'd say there really ought to be a README of some sort right there to give new users a clue. Let's try running squeak.sh for grins - ooh, it actually has permissions set, so that's good ... BOOM.

Right, so there is the rtprio thing. This annoys me because I am certain from my older notes that we didn't used to have  a problem with this on Raspbian. It has also become a real issue on the ubuntu systems I have to use for work - where ubuntu appears to flat out refuse to pay attention to the /etc/security/limits.d file 

Is there no way we can manage this better? Some install process script that does the check and creates the file and requests the user do the reboot thing?

I note that the apt-get install package/script/doohickey provided by RPF does this.

> 
> Recursive not understood error encountered
> 
> /home/pi/Squeak5.3-19435-32bit-202003021730-ARMv6/bin/squeak
> Squeak VM version: 5.0-202003021730  Tue Mar  3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM]
> Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar  3 2020
> With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar  3 2020
> Revision: VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96
> Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux
> plugin path: /home/pi/Squeak5.3-19435-32bit-202003021730-ARMv6/bin/ [default: /home/pi/Squeak5.3-19435-32bit-202003021730-ARMv6/bin/]

This is a VM bug that got fixed. The fixed VM really ought to be included in the 5.3 package and the squeak.org pages updated.

My email records tell me we solved this on or about March 20 2020. The 19435 zip package claims to date from 16 April 2020, so evidently something happened to prevent the fixed VM from getting in there? I see that even in the http://files.squeak.org/5.3/Squeak5.3-19458-32bit/Squeak5.3-19458-32bit-202003021730-ARMv6.zip the VM is the broken 202003021730 version.

What did we screw up and what can we do to fix it ASAP?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: RDL: Rotate Disk Left