Pharo 6 snap install

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Pharo 6 snap install

alistairgrant
Hi Everyone,

I've made a snap package for Pharo 6 which I think is far enough along
for some wider testing.

To get Pharo up and running on Ubuntu 16.04:

# Install Pharo
$ sudo snap install --edge pharo --classic
# If your system isn't configured for threaded heartbeat:
$ sudo pharo.config
# Download the latest Pharo 6 image
$ pharo.getimage
# Go...
$ pharo.ui Pharo.image
# or:
$ pharo Pharo.image eval 4+3

To get a list of available commands:

$ snap info pharo


If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see
https://snapcraft.io/docs/core/install


The VM is the threaded heartbeat, dated 201704101933.

The installation flags are:

    --edge - The edge channel is for development versions.  It
             progresses to beta, candidate and then stable.
    --classic - Snap packages are normally sandboxed for security
             reasons.  Since Pharo is a development environment
             in which we want to be able to run any executable,
             or load any library, it is installed with access to
             the entire system (as the running user).

Why use snap packages?

- They include all dependencies.  In particular, for the 32 bit
  versions, this means that it isn't necessary to install all the 32 bit
  architecture and associated dependencies.
- Including dependencies means that there shouldn't be any problems with
  incompatible library versions when upgrading.

Why not use snap packages?

- It's a relatively new technology, with a number of rough edges.
- There may still be issues with its sandboxing that I haven't
  discovered yet.
- Please let me know of any others to be listed here.
- Because the package uses classic confinement, it isn't
  cross-distribution in practice (unfortunately).

If you don't trust me to configure your system correctly (which requires
sudo):

- All the scripts that make up the sub-commands are visible, e.g.
  pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG


The packaging code is at: https://github.com/akgrant43/pharo-snap

I'm interested to know if people would like to see this eventually
become a supported package format.

Cheers,
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Offray Vladimir Luna Cárdenas-2
Thanks for this Alistair. Having more self contained package options, is
good.

I'm also interested in the upcoming Nix package initiative that has been
announced in the list recently, which also deals with installing
dependencies in a Linux distribution neutral fashion.

Cheers,

Offray


On 12/04/17 09:03, Alistair Grant wrote:

> Hi Everyone,
>
> I've made a snap package for Pharo 6 which I think is far enough along
> for some wider testing.
>
> To get Pharo up and running on Ubuntu 16.04:
>
> # Install Pharo
> $ sudo snap install --edge pharo --classic
> # If your system isn't configured for threaded heartbeat:
> $ sudo pharo.config
> # Download the latest Pharo 6 image
> $ pharo.getimage
> # Go...
> $ pharo.ui Pharo.image
> # or:
> $ pharo Pharo.image eval 4+3
>
> To get a list of available commands:
>
> $ snap info pharo
>
>
> If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see
> https://snapcraft.io/docs/core/install
>
>
> The VM is the threaded heartbeat, dated 201704101933.
>
> The installation flags are:
>
>      --edge - The edge channel is for development versions.  It
>               progresses to beta, candidate and then stable.
>      --classic - Snap packages are normally sandboxed for security
>               reasons.  Since Pharo is a development environment
>               in which we want to be able to run any executable,
>               or load any library, it is installed with access to
>               the entire system (as the running user).
>
> Why use snap packages?
>
> - They include all dependencies.  In particular, for the 32 bit
>    versions, this means that it isn't necessary to install all the 32 bit
>    architecture and associated dependencies.
> - Including dependencies means that there shouldn't be any problems with
>    incompatible library versions when upgrading.
>
> Why not use snap packages?
>
> - It's a relatively new technology, with a number of rough edges.
> - There may still be issues with its sandboxing that I haven't
>    discovered yet.
> - Please let me know of any others to be listed here.
> - Because the package uses classic confinement, it isn't
>    cross-distribution in practice (unfortunately).
>
> If you don't trust me to configure your system correctly (which requires
> sudo):
>
> - All the scripts that make up the sub-commands are visible, e.g.
>    pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG
>
>
> The packaging code is at: https://github.com/akgrant43/pharo-snap
>
> I'm interested to know if people would like to see this eventually
> become a supported package format.
>
> Cheers,
> Alistair
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

K K Subbu
In reply to this post by alistairgrant
On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote:
> Hi Everyone,
>
> I've made a snap package for Pharo 6 which I think is far enough along
> for some wider testing.

Just tried it now. worked like charm.

>     --classic - Snap packages are normally sandboxed for security
>              reasons.  Since Pharo is a development environment
>              in which we want to be able to run any executable,
>              or load any library, it is installed with access to
>              the entire system (as the running user).
Is this really necessary even if we want to work only within an image?

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Luke Gorrie
In reply to this post by Offray Vladimir Luna Cárdenas-2
On 12 April 2017 at 16:43, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
I'm also interested in the upcoming Nix package initiative that has been announced in the list recently, which also deals with installing dependencies in a Linux distribution neutral fashion.

This can only happen if the Pharo community somehow products a new release of the VM that I can package.

The suggestion from the list was that I pick a commit from the pharo-project/pharo-vm#master branch, but I have browsed the commit history and that is way too much of a moving target for me to ship onwards to Nix/NixOS users.

Pharo community: Please - somehow - make a new source release of your bloomin' VM!


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

alistairgrant
In reply to this post by K K Subbu
Hi Subbu,

On Wed, Apr 12, 2017 at 08:22:27PM +0530, K K Subbu wrote:
> On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote:
> >Hi Everyone,
> >
> >I've made a snap package for Pharo 6 which I think is far enough along
> >for some wider testing.
>
> Just tried it now. worked like charm.

Thanks!

> >    --classic - Snap packages are normally sandboxed for security
> >             reasons.  Since Pharo is a development environment
> >             in which we want to be able to run any executable,
> >             or load any library, it is installed with access to
> >             the entire system (as the running user).
> Is this really necessary even if we want to work only within an image?

No, I've used it successfully with strict confinement, however I think
most developers will quickly become frustrated with the restrictions.

If someone has a Pharo based application that they'd like to distribute,
I think strict confinement is a much more likely to be a realistic option.

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Stephane Ducasse-3
In reply to this post by alistairgrant
Thanks a lot for this effort!!!!!



On Wed, Apr 12, 2017 at 4:03 PM, Alistair Grant <[hidden email]> wrote:
Hi Everyone,

I've made a snap package for Pharo 6 which I think is far enough along
for some wider testing.

To get Pharo up and running on Ubuntu 16.04:

# Install Pharo
$ sudo snap install --edge pharo --classic
# If your system isn't configured for threaded heartbeat:
$ sudo pharo.config
# Download the latest Pharo 6 image
$ pharo.getimage
# Go...
$ pharo.ui Pharo.image
# or:
$ pharo Pharo.image eval 4+3

To get a list of available commands:

$ snap info pharo


If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see
https://snapcraft.io/docs/core/install


The VM is the threaded heartbeat, dated 201704101933.

The installation flags are:

    --edge - The edge channel is for development versions.  It
             progresses to beta, candidate and then stable.
    --classic - Snap packages are normally sandboxed for security
             reasons.  Since Pharo is a development environment
             in which we want to be able to run any executable,
             or load any library, it is installed with access to
             the entire system (as the running user).

Why use snap packages?

- They include all dependencies.  In particular, for the 32 bit
  versions, this means that it isn't necessary to install all the 32 bit
  architecture and associated dependencies.
- Including dependencies means that there shouldn't be any problems with
  incompatible library versions when upgrading.

Why not use snap packages?

- It's a relatively new technology, with a number of rough edges.
- There may still be issues with its sandboxing that I haven't
  discovered yet.
- Please let me know of any others to be listed here.
- Because the package uses classic confinement, it isn't
  cross-distribution in practice (unfortunately).

If you don't trust me to configure your system correctly (which requires
sudo):

- All the scripts that make up the sub-commands are visible, e.g.
  pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG


The packaging code is at: https://github.com/akgrant43/pharo-snap

I'm interested to know if people would like to see this eventually
become a supported package format.

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Stephane Ducasse-3
In reply to this post by Luke Gorrie
Hi luke

We will do that. Now we are under stress for the release :)
And PharoDays. Great conference!
Stef

On Wed, Apr 12, 2017 at 4:57 PM, Luke Gorrie <[hidden email]> wrote:
On 12 April 2017 at 16:43, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
I'm also interested in the upcoming Nix package initiative that has been announced in the list recently, which also deals with installing dependencies in a Linux distribution neutral fashion.

This can only happen if the Pharo community somehow products a new release of the VM that I can package.

The suggestion from the list was that I pick a commit from the pharo-project/pharo-vm#master branch, but I have browsed the commit history and that is way too much of a moving target for me to ship onwards to Nix/NixOS users.

Pharo community: Please - somehow - make a new source release of your bloomin' VM!



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Luke Gorrie
On 13 April 2017 at 12:20, Stephane Ducasse <[hidden email]> wrote:
We will do that.

Thank you! I will wait :).

Now we are under stress for the release :)
And PharoDays. Great conference!

Thank you for explaining. I am new around here ("oh, are you working on a release now?") so it helps me to have this kind of hint about short-term issues (e.g. busy period) vs long term ones (e.g. no longer making source releases of the VM for some reason.)


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Stephane Ducasse-3
We always try to have a major release around mid/end of april and this is in addition we have pharodays + several people moving to new houses :).
And deadline for projects on top. 

On Thu, Apr 13, 2017 at 12:39 PM, Luke Gorrie <[hidden email]> wrote:
On 13 April 2017 at 12:20, Stephane Ducasse <[hidden email]> wrote:
We will do that.

Thank you! I will wait :).

Now we are under stress for the release :)
And PharoDays. Great conference!

Thank you for explaining. I am new around here ("oh, are you working on a release now?") so it helps me to have this kind of hint about short-term issues (e.g. busy period) vs long term ones (e.g. no longer making source releases of the VM for some reason.)



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Luke Gorrie
On 14 April 2017 at 08:53, Stephane Ducasse <[hidden email]> wrote:
We always try to have a major release around mid/end of april

Once the dust settles, I think it would be wonderful to have this invariant:

- The latest Pharo VM source release is compatible with the latest Pharo image.

This would make it easy for me to help nix users. My job will be to package the latest source release of the VM, period, and I will know that users can use this to run the latest image. I don't have much scope to screw things up and make people sad e.g. by shipping a bad commit from the master branch.

(Of course it makes life harder for you upstream Pharo maintainers. Now updating the VM source release is a blocker for releasing a new image. Could be that this is too constraining in practice, I dunno. I'm just a guy who wants to setup a stable Pharo that I can use to build an application :-))


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Stephane Ducasse-3
This is what we always have when we release and we freeze it. 
The vm 60 will be compatible with latest pharo 60 image. 



On Fri, Apr 14, 2017 at 12:09 PM, Luke Gorrie <[hidden email]> wrote:
On 14 April 2017 at 08:53, Stephane Ducasse <[hidden email]> wrote:
We always try to have a major release around mid/end of april

Once the dust settles, I think it would be wonderful to have this invariant:

- The latest Pharo VM source release is compatible with the latest Pharo image.

This would make it easy for me to help nix users. My job will be to package the latest source release of the VM, period, and I will know that users can use this to run the latest image. I don't have much scope to screw things up and make people sad e.g. by shipping a bad commit from the master branch.

(Of course it makes life harder for you upstream Pharo maintainers. Now updating the VM source release is a blocker for releasing a new image. Could be that this is too constraining in practice, I dunno. I'm just a guy who wants to setup a stable Pharo that I can use to build an application :-))



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Luke Gorrie
On 14 April 2017 at 22:20, Stephane Ducasse <[hidden email]> wrote:
This is what we always have when we release and we freeze it. 
The vm 60 will be compatible with latest pharo 60 image. 

It is possible that I have misunderstood the whole situation and there is no problem at all. That would be awesome. Let's check :-) here is my understanding of the state of the world right now:

The latest stable image release is Pharo-50771.image.
The latest stable VM source release is pharo-vm-2016.02.18.
These two releases are not compatible: This interpreter (vers. 6505) cannot read image file (vers. 6521).

So the problem is that if a distribution packages the latest VM source release then the users won't be able to run the Pharo 5 VM that they download from pharo.org or via the pharo-launcher image.

Is that correct? If so that's fine and hopefully we can fix it for Pharo 6.0. But if I am misunderstanding and a fix is available today that would also be good to know.

I am looking for the "latest VM source release" in http://files.pharo.org/vm/src/vm-unix-sources/ and assuming that non-spur is the stable option for pre-6.0 images.

Cheers!
-Luke


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

alistairgrant
On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
> On 14 April 2017 at 22:20, Stephane Ducasse <[hidden email]> wrote:
>
>     This is what we always have when we release and we freeze it.
>     The vm 60 will be compatible with latest pharo 60 image.
>
>
> It is possible that I have misunderstood the whole situation and there is no
> problem at all. That would be awesome. Let's check :-) here is my understanding
> of the state of the world right now:

I think so...

> The latest stable image release is Pharo-50771.image.
> The latest stable VM source release is pharo-vm-2016.02.18.
> These two releases are not compatible: This interpreter (vers. 6505) cannot
> read image file (vers. 6521).

Is this from a VM you built yourself?  What's the output of:

$ pharo --version

I just downloaded:

$ curl http://get.pharo.org/50+vm | bash

And it started without problem.

The VM is dated Wed May  4 11:54:28 CEST 2016.


> So the problem is that if a distribution packages the latest VM source release
> then the users won't be able to run the Pharo 5 VM that they download from
> pharo.org or via the pharo-launcher image.
>
> Is that correct? If so that's fine and hopefully we can fix it for Pharo 6.0.
> But if I am misunderstanding and a fix is available today that would also be
> good to know.
>
> I am looking for the "latest VM source release" in http://files.pharo.org/vm/
> src/vm-unix-sources/ and assuming that non-spur is the stable option for
> pre-6.0 images.

Occasional bugs aside, my understanding is that V5.0 VMs will work with
V5.0 images.  They should at least start up OK.

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Luke Gorrie
On 15 April 2017 at 09:12, Alistair Grant <[hidden email]> wrote:
On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
> The latest stable image release is Pharo-50771.image.
> The latest stable VM source release is pharo-vm-2016.02.18.
> These two releases are not compatible: This interpreter (vers. 6505) cannot
> read image file (vers. 6521).

Is this from a VM you built yourself?

This is a VM built from source during packaging for NixOS Linux.

  What's the output of:

$ pharo --version

Here it is:

$ pharo-vm-nox --version
3.9-7 #1 Tue Mar 28 16:26:45 UTC 2017 gcc 5.4.0 [Production ITHB VM]
NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
https://github.com/pharo-project/pharo-vm.git Commit: ba1aa855f546b084ec0ebdeb85a36f2352f97b49 Date: 2016-02-18 17:17:13 +0100 By: Esteban Lorenzano <[hidden email]> Jenkins build #15040
Linux localhost 4.4.23 #1-NixOS SMP Fri Sep 30 08:20:43 UTC 2016 i686 GNU/Linux
plugin path: /nix/store/5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/pharo-vm-i386-2016.02.18/ [default: /nix/store/5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/pharo-vm-i386-2016.02.18/]

Note that the date 2016-02-18 corresponds with the latest non-spur source tarball release at http://files.pharo.org/vm/src/vm-unix-sources/

I just downloaded:

$ curl http://get.pharo.org/50+vm | bash

And it started without problem.

I *think* the difference is that you are downloading the VM as a binary and I am downloading it as source code, and we get different versions because pharo.org is regularly shipping updated binaries but not updating the source code releases at the same time. So the source releases lag behind over time and now it's at the point that they can't run the 5.0 image.


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

alistairgrant
On Sat, Apr 15, 2017 at 09:50:29AM +0200, Luke Gorrie wrote:

> On 15 April 2017 at 09:12, Alistair Grant <[hidden email]> wrote:
>
>     On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
>     > The latest stable image release is Pharo-50771.image.
>     > The latest stable VM source release is pharo-vm-2016.02.18.
>     > These two releases are not compatible: This interpreter (vers. 6505)
>     cannot
>     > read image file (vers. 6521).
>
>     Is this from a VM you built yourself?
>
>
> This is a VM built from source during packaging for NixOS Linux.
>
>
>       What's the output of:
>
>     $ pharo --version
>
>
> Here it is:
>
>
>     $ pharo-vm-nox --version
>     3.9-7 #1 Tue Mar 28 16:26:45 UTC 2017 gcc 5.4.0 [Production ITHB VM]
>     NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
>     4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
>     NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
>     4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  5 2016
>     https://github.com/pharo-project/pharo-vm.git Commit:
>     ba1aa855f546b084ec0ebdeb85a36f2352f97b49 Date: 2016-02-18 17:17:13 +0100
>     By: Esteban Lorenzano <[hidden email]> Jenkins build #15040
>     Linux localhost 4.4.23 #1-NixOS SMP Fri Sep 30 08:20:43 UTC 2016 i686 GNU/
>     Linux
>     plugin path: /nix/store/
>     5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/
>     pharo-vm-i386-2016.02.18/ [default: /nix/store/
>     5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/
>     pharo-vm-i386-2016.02.18/]
>
>
> Note that the date 2016-02-18 corresponds with the latest non-spur source
> tarball release at http://files.pharo.org/vm/src/vm-unix-sources/
>
>
>     I just downloaded:
>
>     $ curl http://get.pharo.org/50+vm | bash
>
>     And it started without problem.
>
>
> I *think* the difference is that you are downloading the VM as a binary and I
> am downloading it as source code, and we get different versions because
> pharo.org is regularly shipping updated binaries but not updating the source
> code releases at the same time. So the source releases lag behind over time and
> now it's at the point that they can't run the 5.0 image.

How about trying:

$ git clone https://github.com/pharo-project/pharo-vm.git
$ cd pharo-vm
$ git checkout b8ec25a570d7539653e1d793e97609adb509aaed

and build that?  It should be the source code for the binary VM on
get.pharo.org.

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Luke Gorrie
On 15 April 2017 at 10:08, Alistair Grant <[hidden email]> wrote:
How about trying:

$ git clone https://github.com/pharo-project/pharo-vm.git
$ cd pharo-vm
$ git checkout b8ec25a570d7539653e1d793e97609adb509aaed

and build that?  It should be the source code for the binary VM on
get.pharo.org.

First, thanks for taking the time to play along with me here, it really helps to make sure I don't hold things up due to a misunderstanding.

Grabbing the source directly from Git is attractive if (a) I know that I am choosing a good version and (b) I am able to build it in a good way.

Seems like a workable solution to (a) is to periodically check for a new binary release, work out which commit it is based off, and build that. This seems fairly reasonable and is probably also possible to automate. (I suppose you got the commit-id from --version or from checking Jenkins.)

I see (b) as problematic though. The source tarball releases have a simple build procedure ("make") while the Git checkouts require a more involved one (bootstrapping the VM from an existing Pharo image.) So I would need to revise the nix build scripts quite a bit if I want to build from Git instead of the tarballs. However, it seems that on the master branch last week the VM build procedure has been reworked so that it is _not_ necessary to run the bootstrapping procedure anymore, which sounds great to me, except that I understand this new build procedure to be quite bleeding edge and not yet documented or used for a binary release (it's not included in the commit that you cite above.)

So what to make of all that? Just right now I see only bad alternatives: sticking with the source release means not supporting Pharo 5.0, updating the build scripts to do bootstrapping takes effort and is already obsoleted by changes on the VM master branch, and shipping the VM master branch means making a pseudo-release without any QA and potentially causing problems for people downstream (there are lots of commits landing on that branch and I have no idea which ones are important/stable.)

So the most reasonable course of action from my point of view seems to be to sit and wait for a better solution to come along e.g. a new source release of the VM or a "blessed" Git commit ID that includes the updated build scripts. The downside is that meanwhile NixOS users can't run the 5.0 image. Could be that Pharo 6.0 will resolve this and that is fine for me -- but of course I'd take a solution sooner if there is a simple one.


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

alistairgrant
Hi Luke,

On Sat, Apr 15, 2017 at 10:34:31AM +0200, Luke Gorrie wrote:

> On 15 April 2017 at 10:08, Alistair Grant <[hidden email]> wrote:
>
>     How about trying:
>
>     $ git clone https://github.com/pharo-project/pharo-vm.git
>     $ cd pharo-vm
>     $ git checkout b8ec25a570d7539653e1d793e97609adb509aaed
>
>     and build that?  It should be the source code for the binary VM on
>     get.pharo.org.
>
>
> First, thanks for taking the time to play along with me here, it really helps
> to make sure I don't hold things up due to a misunderstanding.

No problem.  My answers below relate to Pharo 6, I haven't tried
building V5 (actually, I'm not sure why you're bothering since 6 should
be out before the end of the month, but that's your choice :-)).


> Grabbing the source directly from Git is attractive if
> (a) I know that I am choosing a good version and

The Pharo50-stable tag points to this commit.  Presumably it is kept at
the latest build, but someone else would have to confirm.

If the same isn't already done for V6, I'll certainly be pushing for it
(either a moving tag, or release numbers).


> (b) I am able to build it in a good way.
>
> Seems like a workable solution to (a) is to periodically check for a new binary
> release, work out which commit it is based off, and build that. This seems
> fairly reasonable and is probably also possible to automate. (I suppose you got
> the commit-id from --version or from checking Jenkins.)
>
> I see (b) as problematic though. The source tarball releases have a simple
> build procedure ("make") while the Git checkouts require a more involved one
> (bootstrapping the VM from an existing Pharo image.) So I would need to revise
> the nix build scripts quite a bit if I want to build from Git instead of the
> tarballs. However, it seems that on the master branch last week the VM build
> procedure has been reworked so that it is _not_ necessary to run the
> bootstrapping procedure anymore, which sounds great to me, except that I
> understand this new build procedure to be quite bleeding edge and not yet
> documented or used for a binary release (it's not included in the commit that
> you cite above.)
>
> So what to make of all that? Just right now I see only bad alternatives:
> sticking with the source release means not supporting Pharo 5.0, updating the
> build scripts to do bootstrapping takes effort and is already obsoleted by
> changes on the VM master branch, and shipping the VM master branch means making
> a pseudo-release without any QA and potentially causing problems for people
> downstream (there are lots of commits landing on that branch and I have no idea
> which ones are important/stable.)
>
> So the most reasonable course of action from my point of view seems to be to
> sit and wait for a better solution to come along e.g. a new source release of
> the VM or a "blessed" Git commit ID that includes the updated build scripts.
> The downside is that meanwhile NixOS users can't run the 5.0 image. Could be
> that Pharo 6.0 will resolve this and that is fine for me -- but of course I'd
> take a solution sooner if there is a simple one.

I agree that the build seems a bit messy at the moment.  Given how busy
everyone is with the release, I'm keeping quiet for now, but afterwards
I'd like to get my snap package completely automated.  Personally, I
think getting the build working reliably from git is worth the trouble
(can test any commit, test patches before submitting pull request, etc).

The (V6) linux install relies on a number of bash scripts to launch pharo
(bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo).  How are you producing
these, or are you doing something else?

I'd prefer to get the build using the image working properly as that is
where these scripts are generated (I think).

If you just want to build a single V6 pharo executable (no scripts,
linux 64 bit in the example below):

--
#!/bin/bash
set -e

git clone https://github.com/pharo-project/pharo-vm.git
git checkout <the stable code...>
cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
./mvm
--

BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my
experience is that it is significantly less stable than the latest
binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

K K Subbu
In reply to this post by Luke Gorrie
On Friday 14 April 2017 03:39 PM, Luke Gorrie wrote:
>
> - The latest Pharo VM source release is compatible with the latest Pharo
> image.

This is too strong a condition. For the OS, an image is just a
filesystem within a file. It is sufficient if the VM does not use the
same executable name if it cannot execute the same image. After all, the
VM is a machine and is not likely evolve as rapidly as the image it
runs. If it cannot handle an image format then it should not reuse that
VM's name.

Linux already supports binfmt_misc fs to handle such images. VMMaker can
generate magic(5) file in addition to src/* files from which package
post-installers can register multiple interpreters in
/proc/sys/fs/binfmt_misc/. Python and Qemu use this to run different
bytecode and instruction sets.

BTW, I am attaching a magic pattern file generated automatically from
ImageFormat class in VMMaker image to illustrate my point.

Regards .. Subbu
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

alistairgrant
In reply to this post by alistairgrant
On Sat, Apr 15, 2017 at 09:53:49AM +0000, Alistair Grant wrote:

>
> If you just want to build a single V6 pharo executable (no scripts,
> linux 64 bit in the example below):
>
> --
> #!/bin/bash
> set -e
>
> git clone https://github.com/pharo-project/pharo-vm.git
> git checkout <the stable code...>
> cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
> ./mvm
> --

And remembered that this will produce dragons, hopefully this will work:

--
#!/bin/bash
set -e

git clone https://github.com/pharo-project/pharo-vm.git
git checkout <the stable code...>
cd pharo-vm
../genVersion.sh
cd opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
./mvm
--

where genVersion.sh is:

--
#! /bin/bash

echo "`cat opensmalltalk-vm/platforms/Cross/vm/sqSCCSVersion.h | opensmalltalk-vm/.git_filters/RevDateURL.smudge`" > opensmalltalk-vm/platforms/Cross/vm/sqSCCSVersion.h
echo "`cat opensmalltalk-vm/platforms/Cross/plugins/sqPluginsSCCSVersion.h | opensmalltalk-vm/.git_filters/RevDateURL.smudge`" > opensmalltalk-vm/platforms/Cross/plugins/sqPluginsSCCSVersion.h
--

In case the mailer does formatting: there are only two lines of code,
each beginning with echo.

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 snap install

Luke Gorrie
In reply to this post by alistairgrant
On 15 April 2017 at 11:53, Alistair Grant <[hidden email]> wrote:
(actually, I'm not sure why you're bothering since 6 should
be out before the end of the month, but that's your choice :-)).

I just want something stable and reasonably modern for running existing applications and building new ones.

If that means waiting for Pharo 6.0 release then that is okay with me.

The (V6) linux install relies on a number of bash scripts to launch pharo
(bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo).  How are you producing
these, or are you doing something else?

Here is where those scripts are generated in the existing pharo-vm packaging:

(I didn't write the nix packaging code but I have volunteered to maintain it so if it's out of date then I should fix that.)

git clone https://github.com/pharo-project/pharo-vm.git
git checkout <the stable code...>
cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
./mvm
--

BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my
experience is that it is significantly less stable than the latest
binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb

This is really the bleeding edge :-) both of those commits were pushed within the past three days!

I will take a look at the ./mvm script now.



12