Hi James, Thanks for your follow-up.
On Tue, Apr 04, 2017 at 06:10:32PM +0800, James Henstridge wrote: > On 4 April 2017 at 03:25, Alistair Grant <akgrant0...@gmail.com> wrote: > > Hi James, > > > > On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote: > >> On 31 March 2017 at 05:38, Seth Arnold <seth.arn...@canonical.com> wrote: > >> > On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote: > >> >> I'm trying to package a 32 bit software development environment: Pharo > >> >> Smalltalk (http://pharo.org). > >> >> > >> >> I've got it working OK as a devmode package, but as soon as I switch it > >> >> to classic confinement it fails to run. > >> > > >> > I was under the impression the usual progression is from devmode to > >> > strict. Are you certain classic is the correct direction for your snap? > >> > >> I ran into a similar conundrum for the Python snap I built. If your > >> package contains a language runtime and interactive shell, it is > >> difficult to decide what sort of confinement policy makes sense. It > >> is possible to run under strict confinement with few or any interfaces > >> connected, but depending on what the user wants to do might want a lot > >> more permission (e.g. ability to access the network, ability to write > >> to the home directory, etc). > >> > >> At present the best option seems to be to package things with strict > >> confinement but ensure that it will be functional if installed with > >> --classic. That gives safety by default, but full functionality on > >> request. Of course, this means snapcraft isn't giving any help with > >> the necessary link flags to get things working reliably on non-Ubuntu > >> systems. I guess that's something to try and solve next. > >> > >> James. > > > > This is a step closer, but is still problematic as the bin directories > > (/bin, /usr/bin, etc.) are still mapped to the snapcraft package. > > > > Looks like I'll have to wait until the 64 bit version of the > > application is available. > > If there are particular utilities usually found in /bin or /usr/bin > that aren't part of the "core" snap, you will probably need to include > them in your own snap. If you still want help with this, it'd be > useful to give a link to your in-progress snap or snapcraft project. > Without that, it is a bit difficult to tell what is causing the > problem. OK, thanks for the clarification. The real problem is that I'm unable to get a 32 bit application working with classic confinement. The application runs fine in devmode, but building with classic confinement and running produces: $ pharo --version /snap/pharo/x1/usr/bin/pharo: line 13: /snap/pharo/x1/usr/bin/pharo-vm/pharo: No such file or directory $ ls -l /snap/pharo/x1/usr/bin/pharo-vm/pharo -rwxr-xr-x 1 root root 4599008 Apr 4 15:15 /snap/pharo/x1/usr/bin/pharo-vm/pharo $ snap run --shell pharo $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo not a dynamic executable My guess is that I've either configured it incorrectly, or for some reason the 32 bit architecture isn't working in classic confinement. The project is at: https://github.com/akgrant43/pharo-snap I'm just changing the confinement to classic to reproduce the problems. (A bit of a disclaimer, this is my first snapcraft project and I'm not familiar with the pharo build process, so the whole thing is still a work-in-progress, and needs plenty of tidying up :-)). Thanks again, Alistair -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
