I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available. I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
Chris
[1]
BOX3 - start script used
TEST FOR VERSION: cogvm -version r2776
/usr/bin/cogvm
BINARIES AVAILABLE: /usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793 /home/chrismuller/vm/lib/squeak/4.0-2761 /home/chrismuller/vm/lib/4.4.7-2357
localdebs: cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb squeak-sources_4.1-1_all.deb
BOX3 - no start script used?
TEST FOR VERSION: squeak -version cannot find VM to run image 'squeak' with option ''
BINARIES AVAILABLE: /usr/local/lib/squeak/4.10.2-2793/squeakvm /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild] /var/lib/jenkins/jobs/*
localdebs: squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
The interpreter VM is installed on both box3 and box4. The debs are in /root/localdebs and a record of the installation is in the log file in the root account (I don't remember the name).
Dave
I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available. I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
Chris
[1]
BOX3 - start script used
TEST FOR VERSION: cogvm -version r2776
/usr/bin/cogvm
BINARIES AVAILABLE: /usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793 /home/chrismuller/vm/lib/squeak/4.0-2761 /home/chrismuller/vm/lib/4.4.7-2357
localdebs: cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb squeak-sources_4.1-1_all.deb
BOX3 - no start script used?
TEST FOR VERSION: squeak -version cannot find VM to run image 'squeak' with option ''
BINARIES AVAILABLE: /usr/local/lib/squeak/4.10.2-2793/squeakvm /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild] /var/lib/jenkins/jobs/*
localdebs: squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
On Jul 2, 2014, at 12:32 PM, David T. Lewis lewis@mail.msen.com wrote:
The interpreter VM is installed on both box3 and box4. The debs are in /root/localdebs and a record of the installation is in the log file in the root account (I don't remember the name).
Yup, I see it. Here it is.
admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb
OK, r2793 is the Interpreter VM and it's installed in both boxes. It's installed in a different location that Cog:
/usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793
To my mind that means there's no naming conflict, but I suspect that's not what you mean. In both box3 and box4 the only script in /usr/bin is cogvm in box4. The interpreter VM has no script to start it, which I think explains why "squeak -version" produces nothing at all; whereas, "cogvm -version" does. And this is the naming convention you want to clear with Eliot, right? What to call the script that starts a VM process? I don't think the Interpreter has one installed on either box.
Closer?
Chris
Dave
I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available. I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
Chris
[1]
BOX3 - start script used
TEST FOR VERSION: cogvm -version r2776
/usr/bin/cogvm
BINARIES AVAILABLE: /usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793 /home/chrismuller/vm/lib/squeak/4.0-2761 /home/chrismuller/vm/lib/4.4.7-2357
localdebs: cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb squeak-sources_4.1-1_all.deb
BOX3 - no start script used?
TEST FOR VERSION: squeak -version cannot find VM to run image 'squeak' with option ''
BINARIES AVAILABLE: /usr/local/lib/squeak/4.10.2-2793/squeakvm /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild] /var/lib/jenkins/jobs/*
localdebs: squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
The script is installed as /usr/local/bin/squeak.
Yes that is the one that might get stepped on by the Cog install.
From a Debian packaging point of view, there may be other overlapping
files also.
Dave
On Jul 2, 2014, at 12:32 PM, David T. Lewis lewis@mail.msen.com wrote:
The interpreter VM is installed on both box3 and box4. The debs are in /root/localdebs and a record of the installation is in the log file in the root account (I don't remember the name).
Yup, I see it. Here it is.
admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb
OK, r2793 is the Interpreter VM and it's installed in both boxes. It's installed in a different location that Cog:
/usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793
To my mind that means there's no naming conflict, but I suspect that's not what you mean. In both box3 and box4 the only script in /usr/bin is cogvm in box4. The interpreter VM has no script to start it, which I think explains why "squeak -version" produces nothing at all; whereas, "cogvm -version" does. And this is the naming convention you want to clear with Eliot, right? What to call the script that starts a VM process? I don't think the Interpreter has one installed on either box.
Closer?
Chris
Dave
I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available. I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
Chris
[1]
BOX3 - start script used
TEST FOR VERSION: cogvm -version r2776
/usr/bin/cogvm
BINARIES AVAILABLE: /usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793 /home/chrismuller/vm/lib/squeak/4.0-2761 /home/chrismuller/vm/lib/4.4.7-2357
localdebs: cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb squeak-sources_4.1-1_all.deb
BOX3 - no start script used?
TEST FOR VERSION: squeak -version cannot find VM to run image 'squeak' with option ''
BINARIES AVAILABLE: /usr/local/lib/squeak/4.10.2-2793/squeakvm /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild] /var/lib/jenkins/jobs/*
localdebs: squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
On Jul 2, 2014, at 3:04 PM, David T. Lewis lewis@mail.msen.com wrote:
The script is installed as /usr/local/bin/squeak.
Yes that is the one that might get stepped on by the Cog install.
From a Debian packaging point of view, there may be other overlapping
files also.
OK, I see it now. I think these two kinds of VM are being loaded in different places.
/usr/lib/squeak/4.0-2776 /usr/bin/cogvm
/usr/local/lib/squeak/4.10.2-2793 /usr/local/bin/squeak
Chris
Dave
On Jul 2, 2014, at 12:32 PM, David T. Lewis lewis@mail.msen.com wrote:
The interpreter VM is installed on both box3 and box4. The debs are in /root/localdebs and a record of the installation is in the log file in the root account (I don't remember the name).
Yup, I see it. Here it is.
admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb
OK, r2793 is the Interpreter VM and it's installed in both boxes. It's installed in a different location that Cog:
/usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793
To my mind that means there's no naming conflict, but I suspect that's not what you mean. In both box3 and box4 the only script in /usr/bin is cogvm in box4. The interpreter VM has no script to start it, which I think explains why "squeak -version" produces nothing at all; whereas, "cogvm -version" does. And this is the naming convention you want to clear with Eliot, right? What to call the script that starts a VM process? I don't think the Interpreter has one installed on either box.
Closer?
Chris
Dave
I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available. I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
Chris
[1]
BOX3 - start script used
TEST FOR VERSION: cogvm -version r2776
/usr/bin/cogvm
BINARIES AVAILABLE: /usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793 /home/chrismuller/vm/lib/squeak/4.0-2761 /home/chrismuller/vm/lib/4.4.7-2357
localdebs: cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb squeak-sources_4.1-1_all.deb
BOX3 - no start script used?
TEST FOR VERSION: squeak -version cannot find VM to run image 'squeak' with option ''
BINARIES AVAILABLE: /usr/local/lib/squeak/4.10.2-2793/squeakvm /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild] /var/lib/jenkins/jobs/*
localdebs: squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
Just that it is not lost,
debian provides a facility to provide normally incompatible binaries. (eg, different versions, different vendors) they call it alternatives. (See /etc/alternatives)
one example: jvm. or cc. on my server:
$ ls -l /usr/bin/cc lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
$ ls -l /etc/alternatives/cc lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
and you can select: $ upate-alternatives --list cc /usr/bin/gcc /usr/bin/clang
That way, we could provide different squeakvm's via this tool :)
Best -Tobias
On 02.07.2014, at 18:27, Chris Cunnington brasspen@gmail.com wrote:
I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available. I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
Chris
[1]
BOX3 - start script used
TEST FOR VERSION: cogvm -version r2776
/usr/bin/cogvm
BINARIES AVAILABLE: /usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793 /home/chrismuller/vm/lib/squeak/4.0-2761 /home/chrismuller/vm/lib/4.4.7-2357
localdebs: cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb squeak-sources_4.1-1_all.deb
BOX3 - no start script used?
TEST FOR VERSION: squeak -version cannot find VM to run image 'squeak' with option ''
BINARIES AVAILABLE: /usr/local/lib/squeak/4.10.2-2793/squeakvm /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild] /var/lib/jenkins/jobs/*
localdebs: squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
On Jul 2, 2014, at 12:59 PM, Tobias Pape Das.Linux@gmx.de wrote:
Just that it is not lost,
debian provides a facility to provide normally incompatible binaries. (eg, different versions, different vendors) they call it alternatives. (See /etc/alternatives)
one example: jvm. or cc. on my server:
$ ls -l /usr/bin/cc lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
$ ls -l /etc/alternatives/cc lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
and you can select: $ upate-alternatives --list cc /usr/bin/gcc /usr/bin/clang
That way, we could provide different squeakvm's via this tool :)
Sounds interesting.
"The generic name is not a direct symbolic link to the selected alterna‐ tive. Instead, it is a symbolic link to a name in the alternatives directory, which in turn is a symbolic link to the actual file refer‐ enced. This is done so that the system administrator's changes can be confined within the /etc directory: the FHS (q.v.) gives reasons why this is a Good Thing."
Chris
Best -Tobias
On 02.07.2014, at 18:27, Chris Cunnington brasspen@gmail.com wrote:
I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available. I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
Chris
[1]
BOX3 - start script used
TEST FOR VERSION: cogvm -version r2776
/usr/bin/cogvm
BINARIES AVAILABLE: /usr/lib/squeak/4.0-2776 /usr/local/lib/squeak/4.10.2-2793 /home/chrismuller/vm/lib/squeak/4.0-2761 /home/chrismuller/vm/lib/4.4.7-2357
localdebs: cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb squeak-sources_4.1-1_all.deb
BOX3 - no start script used?
TEST FOR VERSION: squeak -version cannot find VM to run image 'squeak' with option ''
BINARIES AVAILABLE: /usr/local/lib/squeak/4.10.2-2793/squeakvm /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild] /var/lib/jenkins/jobs/*
localdebs: squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de wrote:
Just that it is not lost,
debian provides a facility to provide normally incompatible binaries. (eg, different versions, different vendors) they call it alternatives. (See /etc/alternatives)
one example: jvm. or cc. on my server:
$ ls -l /usr/bin/cc lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
$ ls -l /etc/alternatives/cc lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
and you can select: $ upate-alternatives --list cc /usr/bin/gcc /usr/bin/clang
That way, we could provide different squeakvm's via this tool :)
Nope. That would work only if all VMs could open all images.
- Bert -
On 02.07.2014, at 21:02, Bert Freudenberg bert@freudenbergs.de wrote:
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de wrote:
Just that it is not lost,
debian provides a facility to provide normally incompatible binaries. (eg, different versions, different vendors) they call it alternatives. (See /etc/alternatives)
one example: jvm. or cc. on my server:
$ ls -l /usr/bin/cc lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
$ ls -l /etc/alternatives/cc lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
and you can select: $ upate-alternatives --list cc /usr/bin/gcc /usr/bin/clang
That way, we could provide different squeakvm's via this tool :)
Nope. That would work only if all VMs could open all images.
Why would that be a requirement?
best -tobias
On 02.07.2014, at 21:03, Tobias Pape Das.Linux@gmx.de wrote:
On 02.07.2014, at 21:02, Bert Freudenberg bert@freudenbergs.de wrote:
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de wrote:
Just that it is not lost,
debian provides a facility to provide normally incompatible binaries. (eg, different versions, different vendors) they call it alternatives. (See /etc/alternatives)
one example: jvm. or cc. on my server:
$ ls -l /usr/bin/cc lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
$ ls -l /etc/alternatives/cc lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
and you can select: $ upate-alternatives --list cc /usr/bin/gcc /usr/bin/clang
That way, we could provide different squeakvm's via this tool :)
Nope. That would work only if all VMs could open all images.
Why would that be a requirement?
best -tobias
Because this mechanism is for choosing between alternatives, not for having multiple alternatives at the same time.
If you point /etc/alternatives/squeak to the interpreter, and write a script, it may be fine. If you repoint it later to cog, stuff breaks.
In contrast, gcc and clang are equivalent. They compile the same C files. If you don't care which one to use, you can just use "cc" in a script.
- Bert -
box-admins@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Cunnington -
David T. Lewis -
Tobias Pape