Pharo 6 snap install
Locked
12
12
 
|
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 |
Re: Pharo 6 snap install
|
|
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 > > |
|
|
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 |
|
|
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! |
|
|
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 |
|
|
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, |
|
|
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 13 April 2017 at 12:20, Stephane Ducasse <[hidden email]> wrote:
Thank you! I will wait :).
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.) |
|
|
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 14 April 2017 at 08:53, Stephane Ducasse <[hidden email]> wrote:
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 :-)) |
|
|
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 22:20, Stephane Ducasse <[hidden email]> wrote:
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 |
|
|
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 |
|
|
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: This is a VM built from source during packaging for NixOS Linux. What's the output of: Here it is:
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: 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. |
|
|
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 |
|
|
On 15 April 2017 at 10:08, Alistair Grant <[hidden email]> wrote:
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. |
|
|
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 |
|
|
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 |
magic (1K) |
|
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 |
|
|
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 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 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-proje 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. |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |