Merge lp://qastaging/~sergiusens/snappy/frameworkPath into lp://qastaging/~snappy-dev/snappy/snappy-moved-to-github

Thanks, this looks good.

Does more need to change for this to land, i.e. do we need apparmor changes in lock-step?

On Wed, May 27, 2015 at 06:40:01AM -0000, Michael Vogt wrote:
> Does more need to change for this to land, i.e. do we need apparmor changes in lock-step?

Not sure if in lockstep, but the apparmor changes would need to land
before this, reason for adding jdstrand as a reviewer.

I've not looked at the code changes, but this states that it needs apparmor work. What is needed, adjustments to handle /frameworks instead of just /apps? If so, I think this should be sufficient in click-apparmor's click.py:

=== modified file 'src/apparmor/click.py'
--- src/apparmor/click.py 2015-04-15 21:32:33 +0000
+++ src/apparmor/click.py 2015-05-27 19:56:41 +0000
@@ -542,7 +542,7 @@
     # snappy hardcodes these and doing this allows snappy images to not require
     # click
     if os.path.exists("/usr/bin/snappy"):
- return "{%s}" % ",".join(["/apps", "/oem"])
+ return "{%s}" % ",".join(["/apps", "/oem", "/frameworks"])

     from gi.repository import Click

Oh, and I *hate* 'if os.path.exists("/usr/bin/snappy")' - is there a better way to determine if this is an actual snappy system?

> I've not looked at the code changes, but this states that it needs apparmor
> work. What is needed, adjustments to handle /frameworks instead of just /apps?
> If so, I think this should be sufficient in click-apparmor's click.py:
>
> === modified file 'src/apparmor/click.py'
> --- src/apparmor/click.py 2015-04-15 21:32:33 +0000
> +++ src/apparmor/click.py 2015-05-27 19:56:41 +0000
> @@ -542,7 +542,7 @@
> # snappy hardcodes these and doing this allows snappy images to not
> require
> # click
> if os.path.exists("/usr/bin/snappy"):
> - return "{%s}" % ",".join(["/apps", "/oem"])
> + return "{%s}" % ",".join(["/apps", "/oem", "/frameworks"])
>
> from gi.repository import Click

With this installation works fine but the profile symlinks are wrong:

(amd64)ubuntu@localhost:~$ ls /var/lib/apparmor/snappy/profiles/ -l
total 0
lrwxrwxrwx 1 root ubuntu 36 Jun 3 19:10 webdm_snappyd_0.8 -> /apps/webdm/0.8/meta/snappyd.profile

that's a broken link; who creates the symlink these days? Snappy or apparmor?

snappy creates the symlink in /var/lib/apparmor/clicks, and apparmor creates the profile in /var/lib/apparmor/profiles based on the symlink.

Oh, webdm uses aa-profile-hook, not aa-clickapparmor. In that case, snappy creates the symlink in /var/lib/apparmor/snappy/profiles, then apparmor (aa-profilehook) creates the profile in /var/lib/apparmor/profiles.

(Gosh it will be nice to get this cleaned up)

ah, stale files, actually no link is being created.

ugh, this was related to the bug Chipaca mentioned and is ready for review here: https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934

When applying https://code.launchpad.net/~sergiusens/click-apparmor/snappyFameworksDir/+merge/261032 we should be good.

You've resurrected agreerator, which points to a bad merge; fix that.

Please also consider changing targetDirForType() to a method of type. This is more work, because you'd have to add something like SetRootDir to pkg, and call it from snappy's SetRootDir, so only do it if you're feeling fancy.

I suspect this is going to conflict with some of the branches i've had up for review for a few days now... sigh.

PASSED: Continuous integration, rev:474
http://10.55.60.183:8080/job/snappy-rolling-ci/28/
Executed test runs:

Click here to trigger a rebuild:
http://10.55.60.183:8080/job/snappy-rolling-ci/28/rebuild

this has a conflict with trunk.