[08:07] <fgimenez> good morning
[08:36] <Sam_> First time to be here, hello everyone.
[09:26] <clobrano> good morning
[09:26] <clobrano> is there any snap available for the network manager?
[10:18] <JamesTait> Good morning all; happy Tuesday, and happy Sandwich Day! 😃
[11:29] <mvo> jdstrand: I started with the snappy policygen --compare branch, just a quick question about apparmor_profile - p - I understand that I need to take the old policy, write the new policy to a tempfile and then run both of them via apparmor_profile -p and compare if they are still identical?
[14:11] <balloons> elopio, fgimenez all ready for http://summit.ubuntu.com/uos-1511/meeting/22623/testing-snappy/?
[14:12] <elopio> balloons: all ready.
[14:12] <fgimenez> balloons, elopio yep, ready :)
[14:16] <balloons> elopio, fgimenez and you know how to setup the hangout and everything right
[14:42] <elopio> balloons: yes, no problem with that.
[14:45] <balloons> brillant
[14:58] <mvo> jdstrand: I looked at apparmor_parser -p again and I think I need a hand. it seems in order for this to work I would have to store something (hash?) of the flattended profile at profile generation time. and then compare the stored hash with a hash of apparmor_profile -p tmp_new_profile (?)
[15:10] <ogra_> http://summit.ubuntu.com/uos-1511/meeting/22623/testing-snappy/ will soon be  on air ....
[15:23] <jdstrand> mvo: re apparmor_parser -p, yes you are right. I don't think we want to do anything expensive though-- perhaps just apparmor_parser -p after install and save that off somewhere, then we can do a diff /saved/off /tmp/new || updateStuff
[15:24] <jdstrand> mvo: we should probably think about that a bit
[15:26] <mvo> jdstrand: ok, easy enough to add later I assume
[15:27] <jdstrand> mvo: well, yes and no. we have to deal with the apparmor package updates that have changes to the abstractions.
[15:28] <jdstrand> we could just unconditionally invalidate everything
[15:28] <jdstrand> which is basically what happens now, but that has always been a pain point
[15:28] <mvo> jdstrand: I mean we can add it later this week :)
[15:28] <jdstrand> ah
[15:28] <jdstrand> yes
[15:29] <jdstrand> mvo: fyi, I looked at your first patch yesterday and I thought it looked good. I didn't do more than read it yet
[15:29] <mvo> jdstrand: or next week, I mean when you have time to guide me
[15:29] <jdstrand> mvo: the main thing is I want it clean and it needs to be a cheap check
[15:30] <jdstrand> mvo: on personal people easily have 100 profiles
[15:31] <jdstrand> mvo: but, we do have a cheap check by storing off the version-- if the version didn't change, avoid everything
[15:31] <jdstrand> if it did change, then we try the regenerated policy, then if that is the same, try the -p
[15:33] <mvo> jdstrand: hm, what exactly is "version"?
[15:33] <mvo> in this context
[15:33] <mvo> jdstrand: tell me if you don't have time, we can talk later of course
[16:46] <jdstrand> mvo: sorry, I got pulled away. in a meeting now, but will respond
[16:46] <mvo> jdstrand: thanks
[16:46] <jdstrand> mvo: cheap check for storing off the version> I was talking about in the card where I talk about saving the version of apparmor and ubuntu-core-security* that are installed
[16:47] <jdstrand> mvo: if none of them change, do nothing
[16:47] <mvo> jdstrand: I pushed a --regenerate-all branch now too, some feedbcak would be great, need to add some tests, then it should be good to know and I'm keen to hear what is missing before we can replace the current aa-clickhook
[16:47] <mvo> jdstrand: aha, storing the package versions? that makes sense
[16:47] <jdstrand> mvo: if they do change, do the --compare
[16:47] <jdstrand> mvo: and then update the 'versions file'
[16:47] <mvo> jdstrand: I thought we would do the --regenerate-all on each boot, no?
[16:48] <jdstrand> mvo: well, it depends on what it does. these things can affect boot speed and we have a number of checks today to not affect boot speed unless we have to
[16:49] <jdstrand> mvo: so I didn't want to regress on that
[16:49] <jdstrand> mvo: without looking at your branch, if it were smart enough, '--regenerate-all --compare' could be done on every boot
[16:49] <mvo> jdstrand: right, so it will create a temp profile for each snap, cmpare with the installed one and re-generate for real if they are different
[16:50] <jdstrand> mvo: right
[16:50] <mvo> not sure how slow that is though
[16:50] <jdstrand> mvo: we need to be thinking about potentially hundreds of profiles
[16:50] <jdstrand> mvo: which is why I wanted that cheap check too
[16:51] <jdstrand> mvo: only run --regenerate-all --compare only if the system policy changed
[16:51] <mvo> jdstrand: right, so i can add this and only call --regen is the versions of apparmor and ubuntu-core-security** change
[16:51] <jdstrand> that sounds good
[16:51] <mvo> jdstrand: that is what you mean I assume?
[16:51] <mvo> jdstrand: cool, I will work on this next
[16:51] <jdstrand> mvo: btw, thanks you so much for helping out with all this :)
[16:52] <mvo> jdstrand: oh, thank you! and I can't wait to hear what else is missing before we can enter the brave-new-world
[16:53] <jdstrand> mvo: I'm finding it difficult to review these in a timely fashion between the sprint and UOS, but know I will get to it :)
[16:55] <jdstrand> mvo: (or put another way, the patches are coming in faster than I can review them atm, but I will get to them :)
[16:55] <mvo> jdstrand: no worries, I know how it is
[16:56] <mvo> jdstrand: even tiny reviews (like general direction looks valid) are useful. or your suggestion to use the version-compare to speed stuff up. and of course what else is missing :)
[16:56] <mvo> jdstrand: I can ask other people like Chipaca (sorry!) to do the in-depth code review
[16:56] <jdstrand> mvo: ok, cool. keep firing questions at me and I'll respond as quickly as I can :)
[16:57] <mvo> jdstrand: anyway, I get dinner now, thanks for your help and keep me updated about your findings
[17:06] <ricmm> mm
[17:36] <jdstrand> mvo: unfortunately I had a meeting conflict with the frameworks UOS session
[19:00] <tedg> mterry: we were talking a bit about manifest.txt and the packages in there, where is that list from? Just the ubuntu-core packages?
[19:00] <tedg> We were thinking it made sense to reduce the set some.
[19:00] <tedg> Specifically to drop libstdc++, but perhaps others as well.
[19:01] <ogra_> tedg, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ?
[19:02] <tedg> ogra_: very close: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/manifest.txt
[19:02] <ogra_> heh
[19:03] <tedg> mterry: Not sure if you saw my ping (or were trying to avoid it ;-) )
[19:03] <mterry> tedg, no I didn't see it!
[19:03] <tedg> mterry: we were talking a bit about manifest.txt and the packages in there, where is that list from? Just the ubuntu-core packages?
[19:04] <tedg> We were thinking it made sense to reduce the set some.
[19:04] <tedg> Specifically to drop libstdc++, but perhaps others as well.
[19:04] <mterry> tedg, you're talking in terms of deb2snap?
[19:05] <tedg> mterry: Initially, but today snapcraft: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/manifest.txt
[19:07] <mterry> tedg, my IRC connection is crap today.  "you're talking in terms of deb2snap?"
[19:07] <tedg> mterry: Initially, but today snapcraft: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/manifest.txt
[19:08] <mterry> tedg, oh yeah!  That was just a copy of ubuntu-core at the time.  It was a shortcut to a more dynamic solution
[19:08] <tedg> mterry: Do you have a specific reason for particular packages?
[19:09] <mterry> tedg, I don't *think* I edited the list
[19:09] <tedg> mterry: Okay, we didn't know how much experience and pain was involved :-)
[19:10] <mterry> tedg, no, and my intent was eventually to make it targetted (like if snapcraft can say "make me a snap for 15.04" we'd get the manifest for 15.04).  But yeah, short term I just copied the manifest.txt
[19:11] <tedg> mterry: I think that long term it shouldn't matter, the only thing you pull in is bash and libc, eh?
[19:12] <mterry> tedg, well if my snap uses libudev1 and snappy 16.10 uses libudev2, snapcraft needs to know that it can't depend on it from the system anymore and bundle it
[19:12] <mterry> (or just build for libudev2)
[19:13] <mterry> (or just always bundle it)
[19:13] <tedg> mterry: I think we want it to bundle always
[19:13] <tedg> Yeah
[19:13] <mterry> tedg, OK then you want to probably modify manifest.txt to the actual promised "always-there" libraries that Snappy promises
[19:14] <tedg> mterry: Okay, I don't think we've explicitly said which, but I think generally it's "not much"
[19:14] <mterry> tedg, which is not something I was aware we had a list of -- what sort of promises we make to snaps
[19:14] <tedg> The one that is killing today is the GCC migration.
[19:14] <tedg> For C++
[19:14] <mterry> tedg, well exactly -- even stuff we would have though would never change sometimes change  :)
[20:22] <tedg> elopio: is there a way to build all the examples?
[20:22] <tedg> (in snapcraft)
[20:28] <asac> stgraber: i vaguely recall seeing a busybox image you put out when I tested lxd ... do you have pointer to that again? how is that build?
[20:29] <stgraber> lxd-images import busybox --alias busybox
[20:29] <stgraber> assuming that you do have the busybox binary on your system as it builds it from your local system
[20:29] <ogra_> that will likely only get you the initramfs busybox
[20:30] <ogra_> (which is cut down)
[20:31] <stgraber> it's looking for /bin/busybox specifically so if it doesn't exist, it'll fail to create the busybox image
[20:31] <stgraber> note that we only really have this for our own testsuite's use and it's going away in 16.04, so not something we really support (busybox hardly counts as a Linux distro) :)
[20:32] <ogra_> oh, i know embedded people that would disagree with that statement :)
[20:33] <stgraber> I guess you can turn it into some kind of distro with a fair amount of shell script added on top, but with just the busybox binary, you get a mostly broken init system (doesn't handle all signals properly) which doesn't even bring up network for you
[20:33] <asac> stgraber: oh... thought you had an image for download
[20:34] <stgraber> nah, busybox is specifically used in environments where we can't download stuff or where we shouldn't (our testsuite)
[20:35] <asac> hmm. lxd wasnt SRUed to 14.04 yet it seems :)
[20:36] <ogra_> yeah, i noticed that today too :(
[20:36] <asac> hah ... so i am not alone running LTS :)
[20:36] <ogra_> my desktop always runs lts ... my laptop always latest release
[20:38] <stgraber> it's in backports
[20:38] <stgraber> apt-get -t trusty-backports install lxd
[20:38] <ogra_> who uses that !
[20:38] <ogra_> :)
[20:38] <asac> yeah thats kind of same as ppa
[20:38] <asac> does it work on 3.13?
[20:38] <stgraber> it does
[20:38] <ogra_> sigh ... i wasted my whole day trying to get live-build to behave
[20:38] <ogra_> another build failure and i'm out of ideas
[20:39] <asac> ogra_: its not wasted... now you know what you tried did not work :)
[20:39] <ogra_> asac, i'm poking in the dark here
[20:39] <asac> ogra_: do you have a busybox image? :)
[20:40] <ogra_> if i do exactly the same steps in a local chroot everything is fine ... if i run them under live-build the env is somehow so garbled up that the kernel package doesnt generate its initrd
[20:40] <ogra_> asac, heh, no
[20:40] <ogra_> stgraber, what do you use for these lxd images ?
[20:41] <ogra_> to create them i mean
[20:41] <stgraber> ogra_: "import ubuntu" uses cloud images. "import busybox" just takes your local busybox and dumps it into a tarball along with a few symlinks
[20:42] <ogra_> and how are these cloud images created ?
[20:42]  * ogra_ is desparately looking for a way away from live-build ... its such a pain
[21:03] <ogra_> oh man !
[21:04]  * ogra_ slaps forehead
[21:53] <elopio> tedg: the examples plainbox suite is doing that. But in the end is a for calling snapcraft build on each dir.
[21:54] <tedg> elopio: Oh, I just added a shell script
[21:54] <tedg> https://github.com/ubuntu-core/snapcraft/pull/74/files
[21:55] <elopio> tedg: that might be useful.
[21:55] <elopio> tedg: Take a look at ./runtests.sh plainbox examples
[21:57] <tedg> elopio: Ah, basically the same thing.
[21:57] <tedg> I like to say mine thinks outside the box though ;-)
[21:58] <elopio> tedg: of course, yours is unique and special ;)