Re: Class confinement for Python snaps
On Fri, Mar 10, 2017 at 04:02:54PM +, Sergio Schvezov wrote: > On Fri, 10 Mar 2017 10:14:04 -0500, Barry Warsaw wrote: > > I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm > > running into some problems. ubuntu-image is a Python 3 application, and I'm > > using snapcraft 2.27.1+17.4 on Zesty. > Any reaosn you are moving from devmode to classic? The progression should > be classic->devmode->strict ubuntu-image is a commandline tool that operates on arbitrary files on the filesystem at the user's instruction. This seems to be in the wheelhouse for classic snaps - and certainly, the /tmp issue is very confusing for users and AFAICS isn't truly solvable outside of classic mode. Given this, I don't see any reason we would want to move ubuntu-image from classic to strict mode. Do you disagree? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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: Class confinement for Python snaps
On Mar 10, 2017, at 04:52 PM, Didier Roche wrote: >Note as well that I opened https://bugs.launchpad.net/snapcraft/+bug/1670388 >against the snapcraft project a couple of days ago. I think snapcraft should >at least fail the build to warn you about this. Thanks, subscribed! -Barry -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Class confinement for Python snaps
On Mar 10, 2017, at 04:02 PM, Sergio Schvezov wrote: >Any reaosn you are moving from devmode to classic? The progression should be >classic->devmode->strict A couple of reasons. Probably the most problematic one is that /tmp inside the snap is not the same as /tmp outside the snap, and we have a bunch of crufty workarounds to fail early (when possible) if those directories are used to communicate information across the boundaries. ubuntu-image builds core images. People like to put their extra snaps, or their models in /tmp, or write the resulting images to /tmp. All of that works with the u-i deb but doesn't work with the u-i snap. I *think* we've identified most of the places where this happens, so we can issue an error and exit, but it's an unfortunate asymmetry between the snap and the deb. (And I'm not 100% sure we've identified all the cases; and it makes the code more complicated, etc.) >It is however unfortunate that classic confined snaps can make it to the >stable channel while devmode ones cannot That's another limitation I was hoping to eliminate with the switch to classic. Currently we use edge as our "beta" release channel, then we do any manual QA against that, and promote to beta for our blessed release. I'd love to be able to push the blessed version to stable, since it's way more discoverable. >, maybe we need an alias for devmode (which would be as secure as classic >confinment but with the common root as root) as in some cases it is an >improvement over classic (not needing to deal with libraries and installable >on Ubuntu Core). Isn't classic supposed to be a more or less replacement for traditional debs? I probably misunderstand its purpose but our thinking was that we could bundle it up as a classic snap as a possible, eventual, replacement for SRUing the debs back to X and Y (and soon, Z also). I didn't realize that classic is viewed as the first stepping stone to strict confinement. Cheers, -Barry -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Class confinement for Python snaps
On Fri, 10 Mar 2017 10:14:04 -0500, Barry Warsaw wrote: > I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm > running into some problems. ubuntu-image is a Python 3 application, and I'm > using snapcraft 2.27.1+17.4 on Zesty. Any reaosn you are moving from devmode to classic? The progression should be classic->devmode->strict It is however unfortunate that classic confined snaps can make it to the stable channel while devmode ones cannot, maybe we need an alias for devmode (which would be as secure as classic confinment but with the common root as root) as in some cases it is an improvement over classic (not needing to deal with libraries and installable on Ubuntu Core). -- 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: Class confinement for Python snaps
Le 10/03/2017 à 16:14, Barry Warsaw a écrit : I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm running into some problems. ubuntu-image is a Python 3 application, and I'm using snapcraft 2.27.1+17.4 on Zesty. The first problem I'm having is I think directly related to LP: #1670749. Hey Barry, Note as well that I opened https://bugs.launchpad.net/snapcraft/+bug/1670388 against the snapcraft project a couple of days ago. I think snapcraft should at least fail the build to warn you about this. Cheers, Didier I ended up reopening this because while Corey found that he ultimately only needed to set the $PATH environment variable, I still also had to $PYTHONPATH and I had to make sure the snap versions come before the system versions: environment: PATH: $SNAP/bin/:$PATH PYTHONPATH: $SNAP/lib/python3.5/site-packages:$PYTHONPATH This gets me pretty close, but then I run into my second problem which is that we depend on pyparted, in Ubuntu as python3-pyparted. This package contains both Python source and an extension module and to further complicate things, its tarball is only released on GitHub, not on PyPI, so adding it to python-packages in the ubuntu-image part doesn't work. Further, it doesn't help to add python3-parted to stage-packages because it appears that with classic confinement, none of those Python packages end up in the snap. I tried to add a scriptlet to copy things over, but that also fails. E.g.: parts: ubuntu-image: plugin: python source: https://github.com/CanonicalLtd/ubuntu-image.git source-type: git python-packages: - PyYAML - attrs - voluptuous prime: - bin/ubuntu-image - usr - lib - sbin stage-packages: - e2fsprogs - mtools - python3-debian - python3-parted - util-linux install: | cp -a ../install/usr/lib/python3/dist-packages/parted ../stage/lib/python3.5/site-packages cp -a ../install/usr/lib/python3/dist-packages/pyparted-*.egg-info ../stage/lib/python3.5/site-packages $ snapcraft ... /home/barry/projects/ubuntu/allsnappy/ubuntu-image/parts/ubuntu-image/build cp: cannot create directory '../stage/lib/python3.5/site-packages': No such file or directory cp: cannot create regular file '../stage/lib/python3.5/site-packages': No such file or directory Command '['/bin/sh', '/tmp/tmpfeczxcco', '/tmp/tmp2__1bdau']' returned non-zero exit status 1 This happens because ./stage/ is empty at the point that the install scriptlet is run. I can think of a couple of approaches that might be useful. * Allow python-packages specifications to pip install from repositories other than PyPI. * Allow python-packages to come from git and/or https URLs (I tried this and it didn't work). * Integrate dirtbike and wheels into the Python parts building phases. (dirtbike is a tool that Debian/Ubuntu uses in very limited cases to turn installed distro packages into .whl files.) * Provide a scriptlet hook that runs after the normal part installation step. My current WIP snapcraft.yaml file is here: https://github.com/CanonicalLtd/ubuntu-image/blob/lp1638645/snapcraft.yaml I'm going to keep trying a few things, but any suggestions are welcome. I'm happy to file bugs as needed. Cheers, -Barry -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
