ANN: separate Squeak packages created for different Debian vesions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Friends,

To make sure that Squeak can be installed on every relevant Debian
(GNU/Linux) version, I decided to create builds for all the three Debian
versions:
- - Sarge (known as "stable")
- - Etch (known as "testing")
- - Sid (known as "sid")

It was not necessary because the same squeak binaries worked quite well
on all of these Debian versions but it might have been confusing to add

  deb http://ftp.squeak.org/debian/ sid main
  deb-src http://ftp.squeak.org/debian/ sid main

to `sarge' or `etch'. Additionally, the fact that the same set of
prebuilt binaries worked well on all the three Debian versions is more
coincidence than a rule. It is safer to distribute separate binaries
because of the possible (non-)availability dynamic libraries against
which our (Squeak virtual machine) binary is linked. This set of dynamic
libraries in general differs from Debian version to Debian version.

Details (what to write to your /etc/apt/sources.list file) are explained
in http://wiki.squeak.org/squeak/3616

I have tried to install and use the following three packages:
- - squeak
- - squeak-plugin
- - seaside
on all the three Debian versions:
- - stable
- - testing
- - unstable
I have noticed no problems. If anyone does, let me know.

When new Debian version rotation occurs (testing becomes stable,
unstable becomes testing and new unstable will be forked), those
repositories will be properly rotated to reflect that too.

New packages (if some will have to be created) and enhancements of the
existing ones will be put to the `unstable' subdirectory.

If Squeak relicensing to Apache License 2.0 succeeds, that will also
open new possibilities.

Regards
- --
Matej Kosik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFmN5sL+CaXfJI/hgRAsMiAKCkZ3CHi3m5IQFD9sPh930aTwyX6ACeI1PX
O0u4K3fOk0OvFkLTveDDyQ8=
=lakM
-----END PGP SIGNATURE-----

Recently, an image I've been using for years has started crashing more
or less constantly (e.g., every few minutes, even if I don't do
anything).  I think this may have coincided with my doing an upgrade
and reboot of my Debian system a few days ago, though the last change
to my VM was Apr 02 of this year.

I'm using squeak-vm 3.9.7-11 from the squeak Debian archives (sid).

Under strace, the end of the last session looked like
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1177216794, 848817}, NULL) = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
nanosleep({0, 1000000}, {2000154628, 134618861}) = 0
gettimeofday({1177216794, 856229}, NULL) = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
gettimeofday({1177216794, 856329}, NULL) = 0
gettimeofday({1177216794, 856381}, NULL) = 0
gettimeofday({1177216794, 856429}, NULL) = 0
gettimeofday({1177216794, 856476}, NULL) = 0
gettimeofday({1177216794, 856523}, NULL) = 0
gettimeofday({1177216794, 856568}, NULL) = 0
gettimeofday({1177216794, 856625}, NULL) = 0
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1177216794, 856718}, NULL) = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
gettimeofday({1177216794, 856821}, NULL) = 0
gettimeofday({1177216794, 856869}, NULL) = 0
gettimeofday({1177216794, 857087}, NULL) = 0
gettimeofday({1177216794, 857181}, NULL) = 0
gettimeofday({1177216794, 857234}, NULL) = 0
gettimeofday({1177216794, 857283}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cf8000
write(1, "\n", 1)                       = 1
write(1, "Segmentation fault\n", 19)    = 19
write(1, "\n", 1)                       = 1
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(21689, 21689, SIGABRT)           = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++

It's not clear to me whether the fstat64 is likely to have triggered
the sigsegv, or if the call to fstat64 is a consequence of handling
the error.

There are a lot of odd things about the image.  It is old, originally
from 3.0 and updated through about 3.6 when conflicts with DateAndTime
(which I had obtained outside the regular update stream) made further
updates challenging.

It is very big and very slow.  The disk image is 42MB; the resident
set size according to top is 32MB.  The vm preallocates about 1G on
startup; I don't know a good way to figure what's really going on with
memory.

I have a background process that sleeps and then updates the
application, which keeps track of time spent in activities.

The image crashes under both a Linux 2.6.18 kernel (the strace above)
and a 2.4.27 kernel (which is what I've been running under).

I started up a clean, default squeak image (under the 2.6 kernel), and
it has not crashed in the same time that my image has crashed
repeatedly.

I have an AMD Athlon CPU (i.e., 32 bit Intel type CPU).
man fstat64 turns up nothing, though the call does seem to be in some
of the system headers.

Any ideas?

Ross Boylan