scratch team mailing list archive

[Bert Freudenberg <bert@xxxxxxxxxxxxxxx>]

On 22.03.2010, at 21:50, Amos Blanton wrote:
> Hi Kevin,
> 
> This is great! I don't have a red hat system with which to test this. 
> 
> On Sun, Mar 21, 2010 at 1:38 AM, Kevin Somervill <ksomervi@xxxxxxxxxxxxxx> wrote:
> 
> I need a few things for the spec file, so if you could check the following.
> 
> Name: scratch
> Version: 1.4.0
> Release: 1%{?dist}
> Summary: Programming system and content development tool
> Group: Lifelong Kindergarten Group at the MIT Media Lab
> License: unknown
> URL:  http://scratch.mit.edu
> Packager: Kevin Somervill <ksomervi@xxxxxxxxxxxxxx>
> Source0: http://info.scratch.mit.edu/sites/infoscratch.media.mit.edu/files/file/scratch_1.4.0.tgz
> 
> If the license field can hold non-standard text, you might add a link to:
> http://info.scratch.mit.edu/Scratch_License
> If not that's ok.
> If Sourc0 indicates a page that should be watched for updates, it should probably be this one:
> http://info.scratch.mit.edu/Linux_Installer
> Group should be: MIT Scratch Team
> Summary should be: easy to use programming environment for ages 8 and up
>  
> How attached are you to having the files in /usr/lib/scratch? These are the Plugins, Scratch.image, and scratch.ini files and I think they should be in /usr/libexec/scratch, as well as the scratch_squeak_vm.
> 
> I'm pretty sure it's fine to move these, but the final answer depends on the way paths are coded inside the Scratch.image, about which I'm not certain. I suspect there are absolute path references to the media / help / language files, but probably not to the Plugins, image, and vm. So if everything works when you set it up that way, that's proof enough. :)

Everything is coded relative to the image location. The VM path does not mater at all.

Since the image and media are platform-indepent, /usr/share would be the right place. Plugins and vm are platform-dependent, so /usr/libexec would be fine. The squeak vm and plugins are traditionally in /usr/lib but it doesn't really matter. And it sounds like you want to copy the vm instead of sharing with the other squeak-based apps?

> 
> The scratch script would be updated as follows: 
> 
> <quote>
> #!/bin/sh
> # Squeakvm wrapper to load Scratch image.
> #------------------------------------------------------------
> 
> SCRATCH_PATH="/usr/libexec/scratch"
> 
> ${SCRATCH_PATH}/App/scratch_squeak_vm \
> -plugins ${SCRATCH_PATH}/Plugins \
> -vm-sound-ALSA \
> ${SCRATCH_PATH}/Scratch.image "${@}"
> </quote>
> 
> You'll notice I changed to ALSA from pulse (don't have or use pulse). I'm trying to figure out a way to test for pulse and use it if it's available, just not there yet.
> 
> That's great! It's fine to edit the startup script - the only thing we don't want to change for different Linux versions is the actual squeak code that lives in Scratch.image. 
> 
> re: pulse plugin -- The ALSA plugin should work just fine on systems without pulse, and performance should be the same, so just use it. We had to make (or rather, we begged our friend and contributor Derek O'Connell to make for us) the pulse plugin because the existence of pulse broke the ALSA plugin on Ubuntu systems. So if you don't have pulse, use ALSA.

In case you still need code to detect pulse, there is some near the end of the etoys wrapper script:

http://etoys.laptop.org/src/etoys.in

- Bert -

> 
> I've posted an rpm to
> http://www.brokenlogo.com/downloads/scratch-1.4.0-1.i386.rpm
> 
> 
> This is great! Thanks for your help! 
> Should I post it here for testing...
> 
> http://info.scratch.mit.edu/Linux_Installer
> 
> ...or do you want to make changes based on above responses first? Either way is fine. Also, I'm not as familiar with rpm based distributions these days - which ones would you expect this package to be compatible with? Do you happen to know if we can test this on the Fedora based OS that runs on OLPC laptops?
> 
> Many thanks,
> Amos
> 
>  
> It builds and installs clean on my machine (a CentOS 5.3). Give it a whirl if you can, or let some other folks test it.
> 
> With minor tweaks (noted above) to the files in the tar package, the rpm builds pretty easily.
> 
> Let me know what you think.
> ./ks
> 
> 
>