Re: classic 32 bit application

2017-04-04 Thread Alistair Grant
Hi Loic & Sergio,

On Tue, Apr 04, 2017 at 06:19:50PM +0200, Lo??c Minier wrote:
> Hi!
> 
> ...
> 
> If the runtime
> linker can't be found for some reason, create your own wrapper to launch
> your executable by calling the runtime linker directly (run
> "/lib/ld-linux.so.2" to get help output or see man page).

Thank you!

Not finding the loader was the problem.  I think this makes sense since 
classic confinement only mounts the bin directories from the snap 
packages, other directories, e.g. /lib, use the host directory.

Just for the record, the following works for me:

$ export HOSTFS=$SNAP
$ export 
LD_LIBRARY_PATH="$HOSTFS/usr/lib/i386-linux-gnu/libfakeroot:$HOSTFS/usr/local/lib:$HOSTFS/lib/i386-linux-gnu:$HOSTFS/usr/lib/i386-linux-gnu:$HOSTFS/usr/lib/i386-linux-gnu/mesa-egl:$HOSTFS/usr/lib/i386-linux-gnu/mesa:$HOSTFS/lib32:$HOSTFS/usr/lib32:$LD_LIBRARY_PATH"
$ export 
PATH="$HOSTFS/usr/local/sbin:$HOSTFS/usr/local/bin:$HOSTFS/usr/sbin:$HOSTFS/usr/bin:$HOSTFS/sbin:$HOSTFS/bin:$HOSTFS/usr/games:$HOSTFS/usr/local/games:$PATH"
$ $SNAP/lib/ld-linux.so.2 $SNAP/usr/bin/pharo-vm/pharo --version


On Tue, Apr 04, 2017 at 03:17:05PM +, Sergio Schvezov wrote:

> I am not sure how the low levels work here wrt to program loaders and
> 32bit versus 64bit support, if they are different, there is currently
> no support in snapcraft for this, which for classic confined snaps
> sets the program loader to a specific binary, you can of course
> override this with a combination of LDFLAGS to set the loader to
> something more appropriate (just make sure the loader comes from the
> core snap or you won't be cross distro or even cross series on
> Ubuntu).

This is what I'll try next.  pharo isn't working properly at the moment 
because it looks for files relative to the executable, and manually 
loading pharo using ld-linux.so.2 is confusing that code.  But this 
needs further investigation on my part (just setting the dynamic-linker
in LDFLAGS isn't working).


> > The project is at: https://github.com/akgrant43/pharo-snap
> > I'm just changing the confinement to classic to reproduce the problems.
> 
> You can't just switch the confinement value, you will need to rebuild.

Yep, I'm doing this.


Thanks again,
Alistair



-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-04-04 Thread Loïc Minier
Hi!

On Tue, Apr 4, 2017 at 4:53 PM, Alistair Grant 
wrote:

> The project is at: https://github.com/akgrant43/pharo-snap
>

I gave this a quick build-try, but build failed in the pharo part with this
tail in build.log:

Set up version info...
Add PharoV50.sources...
cp: cannot stat 'PharoV50.sources': No such file or directory


Looking at the error you're getting, first check if you're running ldd
against a shell script or an ELF file; it should work against a 32-bits
ELF. I did manage to bundle a prebuilt 32-bits app in an amd64 snap here:

https://github.com/lool/quortus-epc-snap/blob/master/snap/snapcraft.yaml

and it basically just involved shipping libc6:i386 in the snap, so
double-check that the runtime linker (/lib/ld-linux.so.2) and all dependent
32-bits libraries are in the snap and in the search path. If the runtime
linker can't be found for some reason, create your own wrapper to launch
your executable by calling the runtime linker directly (run
"/lib/ld-linux.so.2" to get help output or see man page).

Hope this helps!
- Loïc Minier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-04-04 Thread Sergio Schvezov
On Tue, 4 Apr 2017 14:53:17 +, Alistair Grant wrote:
> 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  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 
>>  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.

I am not sure how the low levels work here wrt to program loaders and 32bit 
versus 64bit support, if they are different, there is currently no support in 
snapcraft for this, which for classic confined snaps sets the program loader to 
a specific binary, you can of course override this with a combination of 
LDFLAGS to set the loader to something more appropriate (just make sure the 
loader comes from the core snap or you won't be cross distro or even cross 
series on Ubuntu).

> The project is at: https://github.com/akgrant43/pharo-snap
> I'm just changing the confinement to classic to reproduce the problems.

You can't just switch the confinement value, you will need to rebuild.

> (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 :-)).

When going classic you might need more knowledge of how everything is connected 
and linked though. Even with a code base I know I ran into things like this 
https://forum.snapcraft.io/t/classic-snaps-and-python/141

-- 
Sent using Dekko from my Ubuntu device

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-04-04 Thread Alistair Grant
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  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  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


Re: classic 32 bit application

2017-04-04 Thread James Henstridge
On 4 April 2017 at 03:25, Alistair Grant  wrote:
> Hi James,
>
> Thanks for your reply.
>
> On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote:
>> On 31 March 2017 at 05:38, Seth Arnold  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.

James.

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-04-03 Thread Alistair Grant
Hi James,

Thanks for your reply.

On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote:
> On 31 March 2017 at 05:38, Seth Arnold  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.

Thanks again,
Alistair




On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote:
> Hi All,
> 
> 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.
> 
> The error message displayed when attempting to run the executable is "No
> such file or directory"
> 
> Attempting to print the shared object dependencies from within a snap
> shell with ldd results in:
> 
> $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo
> not a dynamic executable
> 
> Since the only change is the confinement from devmode to classic and
> I've checked that the executable file does actually exist, and it's the
> same one as in devmode, my current hypothesis is that somehow the 32 bit
> environment isn't working properly in classic mode, probably because it
> isn't configured correctly, and not that there's a problem with the
> executable.
> 
> Are there any known problems with 32-bit applications and classic
> confinement, or anything in particular that needs to be configured for
> it to work properly?

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-03-31 Thread James Henstridge
On 31 March 2017 at 05:38, Seth Arnold  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.

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-03-30 Thread Alistair Grant
On 30 March 2017 at 23:38, Seth Arnold  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 think so.  Since this is being used by developers, I've got no way of
knowing which executables they'll want to call, which libraries will be
loaded, etc.  This also seems to fit in with
https://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/
which says that classic confinement is typically used "for all your
scripting and tooling needs".

If you were packaging python or java for use by developers on their
desktop, would you use strict or classic?

Thanks,
Alistair

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-03-30 Thread Seth Arnold
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?

Thanks


signature.asc
Description: PGP signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-03-30 Thread Alistair Grant
Hi Sergio,

Thanks for your reply.

On 30 March 2017 at 15:36, Sergio Schvezov
 wrote:
> On Thu, 30 Mar 2017 08:10:26 +0200, Alistair Grant wrote:
>> Hi All,
>>
>> 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.
>>
>> The error message displayed when attempting to run the executable is "No
>> such file or directory"
>>
>> Attempting to print the shared object dependencies from within a snap
>> shell with ldd results in:
>>
>> $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo
>> not a dynamic executable
>>
>> Since the only change is the confinement from devmode to classic and
>> I've checked that the executable file does actually exist, and it's the
>> same one as in devmode, my current hypothesis is that somehow the 32 bit
>> environment isn't working properly in classic mode, probably because it
>> isn't configured correctly, and not that there's a problem with the
>> executable.
>>
>> Are there any known problems with 32-bit applications and classic
>> confinement, or anything in particular that needs to be configured for
>> it to work properly?
>
> Did you just switch confinement type without rebuilding?

The build environment is docker snapcraft/xenial-amd64.  I rebuilt the
package from scratch, i.e. in the docker container:

$ cd /path/to/pharo-snap
$ snapcraft clean
$ snapcraft prime

Then on the host (Ubuntu 4.8.0-45.48~16.04.1-generic 4.8.17):

$ sudo snap try /path/to/pharo-snap/prime --classic
$ pharo --version


> Are you on a 32 bit system?

No, does this mean that 32 bit snap'd applications don't work on 64
bit systems with classic containment?

Thanks,
Alistair

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


Re: classic 32 bit application

2017-03-30 Thread Sergio Schvezov
On Thu, 30 Mar 2017 08:10:26 +0200, Alistair Grant wrote:
> Hi All,
>
> 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.
>
> The error message displayed when attempting to run the executable is "No
> such file or directory"
>
> Attempting to print the shared object dependencies from within a snap
> shell with ldd results in:
>
> $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo
> not a dynamic executable
>
> Since the only change is the confinement from devmode to classic and
> I've checked that the executable file does actually exist, and it's the
> same one as in devmode, my current hypothesis is that somehow the 32 bit
> environment isn't working properly in classic mode, probably because it
> isn't configured correctly, and not that there's a problem with the
> executable.
>
> Are there any known problems with 32-bit applications and classic
> confinement, or anything in particular that needs to be configured for
> it to work properly?

Are you on a 32 bit system? Did you just switch confinement type without 
rebuilding?

-- 
Sent using Dekko from my Ubuntu device

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft


classic 32 bit application

2017-03-29 Thread Alistair Grant
Hi All,

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.

The error message displayed when attempting to run the executable is "No
such file or directory"

Attempting to print the shared object dependencies from within a snap
shell with ldd results in:

$ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo
not a dynamic executable

Since the only change is the confinement from devmode to classic and
I've checked that the executable file does actually exist, and it's the
same one as in devmode, my current hypothesis is that somehow the 32 bit
environment isn't working properly in classic mode, probably because it
isn't configured correctly, and not that there's a problem with the
executable.

Are there any known problems with 32-bit applications and classic
confinement, or anything in particular that needs to be configured for
it to work properly?

Thanks very much,
Alistair

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft