Packaging vm 3.11.3 for Debian

 
Hi, in the process to upload a new version of the vm to Debian, I've
been redoing the packaging and testing it a bit.
The results are available at
http://svn.debian.org/viewsvn/pkg-squeak/packages/squeak-vm/trunk/debian/ or to anyone joining to the collaborative project to maintain squeak in Debian:
https://alioth.debian.org/projects/pkg-squeak/

This is a brief collection of the problems I got after testing:
- The scripts squeak & squeak.sh don't work in Debian (or don't do it
for me)

- Gstreamer and Pango plugins segfault in amd64, so any image using them
will segfault in this architecture. So latest version of etoys will have
this problem.

- There are lintian problems with the FFI plugin, the error is explained
here: http://lintian.debian.org/tags/shlib-with-non-pic-code.html and
some possible workarounds are available
http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well

- There are still some patches needed for sound in 64 bits that I apply
because haven't been applied in the squeak-vm subversion, they're
available at
http://svn.debian.org/viewsvn/pkg-squeak/packages/squeak-vm/trunk/debian/patches/sound64bits.dpatch?view=log

- The browser plugin can not be compiled anymore


For the plugins problem I don't have enough knowledge of them to be able
to fix them, if anyone has time or ideas to help in fixing them, they're
very welcome.

Regards.
José L.

 
On Tue, Dec 29, 2009 at 01:55:12PM +0100, Jos? L. Redrejo Rodr?guez wrote:
>  
> Hi, in the process to upload a new version of the vm to Debian, I've
> been redoing the packaging and testing it a bit.
> The results are available at
> http://svn.debian.org/viewsvn/pkg-squeak/packages/squeak-vm/trunk/debian/ or to anyone joining to the collaborative project to maintain squeak in Debian:
> https://alioth.debian.org/projects/pkg-squeak/

Excellent, thanks!

>
> This is a brief collection of the problems I got after testing:
> - The scripts squeak & squeak.sh don't work in Debian (or don't do it
> for me)
>
> - Gstreamer and Pango plugins segfault in amd64, so any image using them
> will segfault in this architecture. So latest version of etoys will have
> this problem.

I can confirm this. I believe that there are some underlying issues with
SurfacePlugin that affect Pango and possibly others on 64-bit hosts.
No fix is available at the present time.

I just realized that we don't have a Mantis report for this issue, so
I added one: http://bugs.squeak.org/view.php?id=7433

> - There are lintian problems with the FFI plugin, the error is explained
> here: http://lintian.debian.org/tags/shlib-with-non-pic-code.html and
> some possible workarounds are available
> http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well

Note also that FFI does not yet work on 64-bit systems:
  http://bugs.squeak.org/view.php?id=7237
Fixing this will also correct the lint warnings that you are seeing.

 
El mar, 29-12-2009 a las 09:57 -0500, David T. Lewis escribió: ok

> > - There are lintian problems with the FFI plugin, the error is explained
> > here: http://lintian.debian.org/tags/shlib-with-non-pic-code.html and
> > some possible workarounds are available
> > http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well
>
> Note also that FFI does not yet work on 64-bit systems:
>   http://bugs.squeak.org/view.php?id=7237
> Fixing this will also correct the lint warnings that you are seeing.
>


I don't think so. I saw these errors in i386. I didn't tested this
plugin in amd64.


Regards.
José L.

 
On Tue, Dec 29, 2009 at 04:07:55PM +0100, Jos? L. Redrejo Rodr?guez wrote:
The lint errors that you see on i386 are a symptom from the type
declaration problems that cause crashes on amd64.

Dave

On 29.12.2009, at 15:57, David T. Lewis wrote:
Thanks indeed!

Can't we just disable building of these plugins until this is resolved? It's better to not have them than have them crashing.

Unless Ian or David beat me to it I guess I'll have to read up on cmake then ...

- Bert -

 
On Tue, Dec 29, 2009 at 08:59:13PM +0100, Bert Freudenberg wrote:
IMO, the simplest way to handle this near term is just to maintain a
different VMMaker .config file for the 64-bit build.

But I do think that there are some points that need to be clearly stated
to avoid misunderstanding:

- For general use on Linux distributions, the currently supported
  configuration is the 32-bit VM running on 64-bit Linux. This is
  stable and provides good performance. It does require the installation
  of various 32-bit libraries as a prerequisite.

- There is currently no supported 64-bit Linux VM. If you choose to
  build and distribute one, you are necessarily taking on the responsibility
  of selecting the subset of plugins that you are comfortable supporting.

- Building and distributing a 64-bit VM using the generated source code
  in the platforms/unix/src/ tree is likely to cause problems. All of
  the supported VMs that are found on http://squeakvm.org/unix/ are
  built from that source tree, and they are all 32-bit VMs. If you
  build this source in 64-bit mode, you will be compiling a number of
  plugins that will not work.

I would have no hesitation in recommending the use of 64-bit VMs for
applications such as Seaside servers, or for use by anyone who does
not require multimedia, Pango, and so forth. I use one all the time
for my own use, and it is no problem at all. But supporting a 64-bit
distribution for general Linux users is a big job. If someone chooses
to do it, that's a Really Good Thing, but it should be done with an
awareness of the current limitations of the 64-bit VM.

I also want to emphasize that there is nothing at all wrong with
running the 32-bit VM on 64-bit Linux. The only drawback is the need
for installing some 32-bit runtime libraries. But it works great, it's
stable, it's fast, and you can download all the sources and executables
from http://squeakvm.org/unix/.

Dave