[squeak-dev] Re: Can you launch a squeak image on an etoys vm in Ubuntu?

>Chris Kassopulo ckasso at sprynet.com
>Tue Apr 14 02:00:01 UTC 2009 wrote:
>
Atually this sounds like it is on the path to a solution.

Can we get a DEB package that we can offer from the website in such a way
that when Ubuntu goes searching for a squeak to install it installs that vm?

Bert: That that sound like the way to go?





>Note to Jerome - you can type commands from a "terminal".  Edit
>previous commands by using uparrow.  You get more feedback in a
>terminal.  Applications>>Accessories>>Terminal
>
Very good suggestion. I did find this very informative.
And the workaround is:


/usr/share/Etoys.app/Contents/Linux686/etoys
        -plugins /usr/share/Etoys.app/Contents/Linux686/
                  /home/MyHome/squeak.image

That will start the squeak image with sound.
The /usr/share/Etoys.app/Contents/Linux686/ path is where squeakland installed my etoys
And /home/MyHome/squeak.image is where Ubuntu via squeak.org installed the default squeak image.

And I did experience the problem you described below. I needed to use the world menu for quiting.

Second workaround:
squeak -plugins /usr/share/Etoys.app/Contents/Linux686/  /home/MyHome/squeak.image

That launches the default image with the default squeak vm using the etoys plugins
The image then has sound. Clicking the top right x on the window quits w/o asking for confirmation.

So now the work around is known. Time to get back to solving the original problem.
In another post perhaps.


>The only problem encountered is that squeak does not respond to
>closing of its host window.  Etoys puts up a confirmation message box.
>I remember seeing something in the archives about fixes to the vm in
>how that is handled, but it also requires changes to the image.  Are
>those changes available?

I have no idea on that. See work around two.
>
Yours in curiosity and service, --Jerome Peace
>


     

(Sorry, this is going to be a longer post, covering a lot of basics,  
but I feel even most Linux Squeakers are unaware of how open-source  
software actually gets to users in Linux)

On 15.04.2009, at 09:05, Jerome Peace wrote:

Not really, that would just be a workaround.

In the closed-source world (Mac, Win) typically the software authors  
provide binary packages for end users. This is even true for open-
source software on these platforms, the authors provide ready-to-
install packages, separate from with the source code. That's why we  
have Windows and Mac downloads on our website. It's a one-size-fits-
all approach, and all work is done by the authors.

Not so in Linux. Here, building the binary packages that fit into a  
specific Linux distribution is typically done by users of that Linux  
version. These volunteers ("package maintainers") take the source code  
from an "upstream" author and make a binary package from that,  
typically by writing a few scripts that compile and install the  
software in the right place and with the right supporting files (which  
may be different for each Linux distribution).

Because of these volunteers it is that you can simply install about  
*any* free software from your distro's "software installer". Every  
single one of these thousands of packages was added and is maintained  
by someone.

As you can guess, package maintainers are usually no experts in the  
software they package. They will try the canonical "./configure; make;  
make install" command, and if that appears to work they make a package  
from that, do a few tweaks maybe and release it. People can install  
that package easily now, and everything appears to be fine.

Except it's not. E.g., unless the package builder declared a build-
dependency on the "alsa-lib-devel" package (that's what it is called  
in Fedora anyway) the Squeak VM will be built without ALSA sound  
support. The "configure" script is smart enough to not build the "vm-
sound-ALSA" plugin if it does not find the necessary files. It also  
writes out a message that the plugin was disabled. But that is easy to  
overlook, and also not fatal - there are good reasons for not wanting  
to build that plugin.

Now what needs to happen is that a user who discovers that sound is  
not working must file a bug report for the package *maintainer*. Not  
with the author (us), because that would bypass the maintainer. So use  
your distro's bug tracker, not bugs.squeak.org. The maintainer either  
fixes the problem, or opens an "upstream" bug with the authors.  
Sometimes it's even a chain of "upstreams", in Ubuntu's case the  
package may come from Debian, so a user would file a report at  
Ubuntu's tracker, the Ubuntu maintainer at Debian's tracker, and the  
Debian maintainer with us.

If instead we bypass the maintainers, we get precisely the chicken-and-
egg problem  we are in now. The distro packages do not work well, so  
the experienced developers do not use them but compile their own.  
Which leaves the packages in their bad state because nobody  
knowledgeable cares about them.

To be fair, in the "sound on Ubuntu" case in fact the proper procedure  
was followed:
https://bugs.launchpad.net/ubuntu/+source/squeak-vm/+bug/235146
but apparently did not get fully resolved yet. Not sure what needs to  
happen next in this specific case.

But in general, we should try to make it as easy for package  
maintainers as possible. Even if it is just by letting them know that  
their package is used. So Squeak developers on Linux should try to use  
the distro's packages, and if they are insufficient, give feedback.  
Also, the source code should come with clear instructions on how to  
build it, what dependencies there are etc.

Maybe having a mailing list specifically for maintainers would be  
useful? But even just tracking down what packages are already out  
there, who is maintaining them etc. would be very valuable. And  
monitoring the bug trackers, participating on the distro-maintainers  
lists etc. Here is just a short list for squeak packages in various  
distros:

Debian:
http://packages.debian.org/search?keywords=squeak-vm
Fedora:
https://admin.fedoraproject.org/pkgdb/packages/name/squeak-vm
Ubuntu:
https://launchpad.net/ubuntu/+source/squeak-vm
OpenSuSE:
http://download.opensuse.org/repositories/devel:/languages:/smalltalk/openSUSE_11.0/repodata/repoview/Squeak-0-3.9.8-288.1.html
Gentoo:
http://gentoo-portage.com/dev-lang/squeak
Arch:
http://aur.archlinux.org/packages.php?ID=13021

The good news is that once there are "good" packages in the major  
Linux distributions, the smaller ones can follow suite much more  
easily. The big issues of e.g. what build dependencies exist are  
solved by then, and everyone can learn from each other.

Squeakers have been pretty much ignorant of the larger open-source  
community in the past. But I think there is a lot to be gained by  
becoming a proper part of it. I have been working towards that goal  
for a while now, in particular as part of the OLPC / Sugar development  
efforts. Etoys is distributed as part of Sugar and depends on an up-to-
date Squeak-VM package, so we do have allies in the Sugar maintainers.  
And everyone can help - as I wrote above, no deep VM knowledge is  
necessary to monitor bug trackers or keep contact with the maintainers.

So there. Who else wants to get involved?

- Bert -

PS: Note that I am primarily concerned with the VM packages for now.  
Packaging images is a somewhat separate issue, simpler because no  
dependencies are involved, and at the same time harder because there  
is no established practice of where to put them in the file system  
hierarchy. There used to be the license issue with images, too, but we  
should shoot for proper packaging with the license-clean upcoming 4.0  
release. If you want to discuss this, please start a different thread.

On April 15, 2009, Bert Freudenberg wrote:
<<snip>>
> Maybe having a mailing list specifically for maintainers would be
> useful?

Yes! We could suggest to Tim we create squeak-etoys-maintainers list at squeakland (or maybe it belongs to squeak)?, and advertise it's existence on the main distros. We can offer to the subscribed maintainers that:
- it would be reasonably low volume
- the squeak and etoys community would report distro-specific problems
- the squeak and etoys community would monitor it for questions and try to help

> But even just tracking down what packages are already out
> there, who is maintaining them etc. would be very valuable. And
> monitoring the bug trackers, participating on the distro-maintainers
> lists etc. Here is just a short list for squeak packages in various
> distros:
>
> Debian:
> http://packages.debian.org/search?keywords=squeak-vm
> Fedora:
> https://admin.fedoraproject.org/pkgdb/packages/name/squeak-vm
> Ubuntu:
> https://launchpad.net/ubuntu/+source/squeak-vm
> OpenSuSE:
> http://download.opensuse.org/repositories/devel:/languages:/smalltalk/openS
>USE_11.0/repodata/repoview/Squeak-0-3.9.8-288.1.html Gentoo:
> http://gentoo-portage.com/dev-lang/squeak
> Arch:
> http://aur.archlinux.org/packages.php?ID=13021
>
> The good news is that once there are "good" packages in the major
> Linux distributions, the smaller ones can follow suite much more
> easily. The big issues of e.g. what build dependencies exist are
> solved by then, and everyone can learn from each other.
>
> Squeakers have been pretty much ignorant of the larger open-source
> community in the past. But I think there is a lot to be gained by
> becoming a proper part of it. I have been working towards that goal
> for a while now, in particular as part of the OLPC / Sugar development
> efforts. Etoys is distributed as part of Sugar and depends on an up-to-
> date Squeak-VM package, so we do have allies in the Sugar maintainers.
> And everyone can help - as I wrote above, no deep VM knowledge is
> necessary to monitor bug trackers or keep contact with the maintainers.
>
> So there. Who else wants to get involved?

I use openSuSE, so I can contact the opensuse people. I was in fact thinking I try to build Squeak for OpenSuse (they have well published and documented build system), but cannot commit to that much time.

So I think we should first create the list ,come up with a standard (nothing too complicated) email that we send to the main distros lists.

Cross-posting this to squeakland software list...

Milan

>
> - Bert -
>
> PS: Note that I am primarily concerned with the VM packages for now.
> Packaging images is a somewhat separate issue, simpler because no
> dependencies are involved, and at the same time harder because there
> is no established practice of where to put them in the file system
> hierarchy. There used to be the license issue with images, too, but we
> should shoot for proper packaging with the license-clean upcoming 4.0
> release. If you want to discuss this, please start a different thread.

On April 16, 2009, Bert Freudenberg wrote:
> On 16.04.2009, at 07:21, Milan Zimmermann wrote:
> > On April 15, 2009, Bert Freudenberg wrote:
> > <<snip>>
> >
> > > Maybe having a mailing list specifically for maintainers would be
> > > useful?
> >
> > Yes! We could suggest to Tim we create squeak-etoys-maintainers list
> > at squeakland (or maybe it belongs to squeak)?, and advertise it's
> > existence on the main distros.
>
> It should be a squeak.org list - the VM is not Etoys-specific. How
> does [hidden email] sound?

Very good.

A note, would that be more like [hidden email] ? They "dig" to the same IP, so maybe it's irrelevant.

>
> > We can offer to the subscribed maintainers that:
> > - it would be reasonably low volume
> > - the squeak and etoys community would report distro-specific problems
> > - the squeak and etoys community would monitor it for questions and
> > try to help
>
> Not quite. IMHO this should not be a list for users to report bugs. It
> would be a list specifically for maintainers to discuss packaging
> issues, to alert packagers of new releases, and to provide a help
> forum for them. But it should be driven by the needs of maintainers,
> not as a general complaint sink.

Yes, I agree with your points. Also the drive would be help towards packaging VM, not images, at least initially.

> The volume then would be in control
> of the maintainers, and indeed be expected to be rather low.
>
> > So I think we should first create the list ,come up with a standard
> > (nothing too complicated) email that we send to the main distros
> > lists.
>
> Sounds reasonable.

If it helps and there are no objections, I can ask Ken(?) to setup the mailing list, subscribe to it and post here a suggested email to the main distros by next weekend end (out of time). I am interested there is Squeak and later Etoys in Linux distros and will help; having said that, I know very little about building the Squeak VM, and it would not be fair to send that email to main distros without having at least one or two people who can actually provide educated help subscribed. So I am really talking out of my league here...

Milan

>
> - Bert -