Does anyone have access to a Debian testing/unstable system? Could you check if Etoys really gets stuck, and maybe figure out why?
I suspect it might be because they're running on x86_64. The VM is 4.10.2-2614.
- Bert -
---------- Forwarded message ---------- From: Víctor Bettachini victorb@gmx.net Date: Sun, May 14, 2017 at 9:50 PM Subject: Bug#862576: etoys: Doesn't get beyond Squeak security key generation To: Debian Bug Tracking System submit@bugs.debian.org
Package: etoys Version: 5.0.2408-1 Severity: grave Justification: renders package unusable
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation? Just running etoys&. * What exactly did you do (or not do) that was effective (or ineffective)? Run etoys& * What was the outcome of this action? It gets stuck at 99% of the Squeak security key generation procedure. * What outcome did you expect instead? The same procedure in a Jessie installation in the same system just took a few seconds and led to eToys main screen.
*** End of the template - remove these template lines ***
-- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.utf8, LC_CTYPE=es_AR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Versions of packages etoys depends on: ii squeak-vm 1:4.10.2.2614-4+b1
Versions of packages etoys recommends: ii etoys-doc 5.0.2408-1
etoys suggests no packages.
-- no debconf information
On Tue, May 23, 2017 at 12:27:42PM +0200, Bert Freudenberg wrote:
Does anyone have access to a Debian testing/unstable system? Could you check if Etoys really gets stuck, and maybe figure out why?
I suspect it might be because they're running on x86_64. The VM is 4.10.2-2614.
- Bert -
I don't have a Debian system, but you are probably right. I did a quick check of running an Etoys-To-Go-5.0 image on a 64-bit interpreter VM, compiled locally, version level 4.16.3-3748. It seems to run fine on my 64-bit Ubuntu. But the 4.10.2-2614 VM is really quite old now and probably does have some issues on a 64-bit system.
Being Debian, I suspect that the VM needs to be compiled from source, is that right? Or would a pre-compiled VM be sufficient?
I am not in a position to set up a Debian system, so hopefully someone else can volunteer to check this out.
Dave
---------- Forwarded message ---------- From: V??ctor Bettachini victorb@gmx.net Date: Sun, May 14, 2017 at 9:50 PM Subject: Bug#862576: etoys: Doesn't get beyond Squeak security key generation To: Debian Bug Tracking System submit@bugs.debian.org
Package: etoys Version: 5.0.2408-1 Severity: grave Justification: renders package unusable
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate
- What led up to the situation? Just running etoys&.
- What exactly did you do (or not do) that was effective (or ineffective)? Run etoys&
- What was the outcome of this action? It gets stuck at 99% of the Squeak security key generation
procedure.
- What outcome did you expect instead? The same procedure in a Jessie installation in the same system just
took a few seconds and led to eToys main screen.
*** End of the template - remove these template lines ***
-- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.utf8, LC_CTYPE=es_AR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Versions of packages etoys depends on: ii squeak-vm 1:4.10.2.2614-4+b1
Versions of packages etoys recommends: ii etoys-doc 5.0.2408-1
etoys suggests no packages.
-- no debconf information
On 23-05-2017, at 5:08 AM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, May 23, 2017 at 12:27:42PM +0200, Bert Freudenberg wrote:
Does anyone have access to a Debian testing/unstable system? Could you check if Etoys really gets stuck, and maybe figure out why?
I suspect it might be because they're running on x86_64. The VM is 4.10.2-2614.
- Bert -
I don't have a Debian system, but you are probably right. I did a quick check of running an Etoys-To-Go-5.0 image on a 64-bit interpreter VM, compiled locally, version level 4.16.3-3748. It seems to run fine on my 64-bit Ubuntu. But the 4.10.2-2614 VM is really quite old now and probably does have some issues on a 64-bit system.
Being Debian, I suspect that the VM needs to be compiled from source, is that right? Or would a pre-compiled VM be sufficient?
My experience suggests being *very* careful with the way Debian mangles our code. Last time I had to dig into it there was an override of our jpeg reading code that quite blatantly broke reading the files. Worse, it appeared that no one there had even bothered to contact any of us to ask why we needed that particular code.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Debugger: A tool that substitutes afterthought for forethought.
It's been a while since I ran the interpreter VM heavily so this may no longer be the case but one thing I remember learning early on was *not* to use the Debian VM package as it was almost always out of date and/or had some sort of build problem. Whatever the latest Linux binary from squeak.org almost always worked for me unless I needed custom plugins etc. and this was on every release starting with Debian 6 running in a variety of unstable/testing/release 32/64-bit environments. So building from source usually wasn't necessary.
On May 23, 2017 12:48 PM, "tim Rowledge" tim@rowledge.org wrote:
On 23-05-2017, at 5:08 AM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, May 23, 2017 at 12:27:42PM +0200, Bert Freudenberg wrote:
Does anyone have access to a Debian testing/unstable system? Could you check if Etoys really gets stuck, and maybe figure out why?
I suspect it might be because they're running on x86_64. The VM is 4.10.2-2614.
- Bert -
I don't have a Debian system, but you are probably right. I did a quick check of running an Etoys-To-Go-5.0 image on a 64-bit interpreter VM, compiled locally, version level 4.16.3-3748. It seems to run fine on my 64-bit Ubuntu. But the 4.10.2-2614 VM is really quite old now and probably does have some issues on a 64-bit system.
Being Debian, I suspect that the VM needs to be compiled from source, is that right? Or would a pre-compiled VM be sufficient?
My experience suggests being *very* careful with the way Debian mangles our code. Last time I had to dig into it there was an override of our jpeg reading code that quite blatantly broke reading the files. Worse, it appeared that no one there had even bothered to contact any of us to ask why we needed that particular code.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Debugger: A tool that substitutes afterthought for forethought.
More info on the VM problem: it disappears when compiled with -O1. Sounds like it may be some undefined behavior, which may have been fixed in the mean time?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862576
- Bert -
On Tue, Jun 06, 2017 at 11:40:36PM +0200, Bert Freudenberg wrote:
More info on the VM problem: it disappears when compiled with -O1. Sounds like it may be some undefined behavior, which may have been fixed in the mean time?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862576
- Bert -
I think that to some extent the issue is how or if to support Etoys directly as a Debian package, as opposed to something that a Debian user might expect to download from an Etoys web site without compiling the VM.
Supporting the interpreter VM as a Debian package is something that we have not done well in the past, and it will require some time and effort if we want to do it in the future. I don't think it would be terribly difficult, but it does require time and effort, and it is not something that I would have the cycles to support right now (but maybe someone else might have an interest? if so please speak up!).
The squeak-vm 4.10.2.2614-4 package on Debian is based on some fairly old sources, so it is quite likely that whatever bug is being reported on the Debian list has been long since fixed.
To give an idea of how much has changed since that time, see the attached list of changes from VMMaker. If we were to update the Debian squeak-vm package with current sources, it would include all of these changes, along with matching changes on the ./platforms side.
Dave
On Wed, Jun 7, 2017 at 3:23 AM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 06, 2017 at 11:40:36PM +0200, Bert Freudenberg wrote:
More info on the VM problem: it disappears when compiled with -O1. Sounds like it may be some undefined behavior, which may have been fixed in the mean time?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862576
- Bert -
I think that to some extent the issue is how or if to support Etoys directly as a Debian package, as opposed to something that a Debian user might expect to download from an Etoys web site without compiling the VM.
Supporting the interpreter VM as a Debian package is something that we have not done well in the past, and it will require some time and effort if we want to do it in the future. I don't think it would be terribly difficult, but it does require time and effort, and it is not something that I would have the cycles to support right now (but maybe someone else might have an interest? if so please speak up!).
The squeak-vm 4.10.2.2614-4 package on Debian is based on some fairly old sources, so it is quite likely that whatever bug is being reported on the Debian list has been long since fixed.
To give an idea of how much has changed since that time, see the attached list of changes from VMMaker. If we were to update the Debian squeak-vm package with current sources, it would include all of these changes, along with matching changes on the ./platforms side.
Dave
We only need to provide a new source tarball at http://squeakvm.org/unix/release/ ... AFAIK the Debian packages are built pretty much directly from the Squeak-4.10.2.2614-src.tar.gz in that directory.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
David T. Lewis -
Phil B -
tim Rowledge