[07:28] <didrocks> ogra_: hey! when you have some time, do you mind answering on http://askubuntu.com/questions/741088/qemu-snappy-15-04-how-to-tune-sysctl-conf ?
[07:28] <didrocks> ogra_: and please poke me, I'm interested in the answer as well :)
[07:54] <dholbach> good morning
[08:08] <didrocks> good morning dholbach
[08:08] <dholbach> salut didrocks
[08:30] <zyga> good morning
[08:38] <noizer> good morning
[08:42] <didrocks> mvo: hey, it seems that even if we branch snapcraftv1, we can't build anymore 15.04 snaps on xenial.
[08:42] <didrocks> mvo: Snapping /
[08:42] <didrocks> open /home/didrocks/work/ubuntu-core/demos/youtube-streamer/snap/meta/snap.yaml: no such file or directory
[08:42] <didrocks> I guess the issue is the new metadata snappy files
[08:42] <didrocks> and so snappy snap doesn't know it's some 15.04 snaps and look for this
[08:44] <didrocks> (I did downgrade snappy for now)
[08:46] <mvo> didrocks: yeah, snappy is unfortunately not able to do 15.04 stuff in xenial
[08:46] <mvo> didrocks: if that is important we could introduce a snappy-15.04 package, but then 16.04 is going to be released in some weeks so not sure about it
[08:47] <didrocks> mvo: I agree, but it seems that a lot of people have (unfortunately) interests in 15.04. I guess if we tell them to use < 16.04 for now, it's ok, but still something to keep in mind in case people starts complaining
[09:02] <noizer> Hi I played some with the REST API but i got an error with this call.
[09:02] <noizer> http://pastebin.com/e4yVQTKj
[09:04] <zyga> noizer: which version of snappy did you use?
[09:04] <zyga> noizer: can you run "snap interfaces"
[09:05] <noizer> 16.04
[09:05] <noizer> zyga
[09:05] <zyga> noizer: and FYI: https://github.com/ubuntu-core/snappy/pull/559
[09:06] <zyga> mvo: thank you!
[09:07] <noizer> ok but i got it for other different calls like /2.0/snaps/nameOfSnap/services
[09:07] <zyga> noizer: you might have to authenticate
[09:07] <zyga> noizer: or run as root
[09:08] <noizer> hmmm ok i will check it first out
[09:08] <zyga> noizer: look at the rest.md file
[09:08] <zyga> noizer: it says what each of the method requires
[09:08] <zyga> noizer: including authentication
[09:08] <zyga> noizer: currently if you connect as root over the local socket then we trust you and you can touch any of the bits exposed
[09:09] <noizer> zyga: but with the /2.0/snaps there needed to be authentication too but it works right out the box
[09:09] <zyga> noizer: maybe your image still has /2.0/skills
[09:10] <zyga> noizer: I'd recommend using my devtools scripts to run latest master on your image
[09:10] <noizer> maybe
[09:10] <zyga> noizer: try the get with /2.0/skills
[09:10] <zyga> if that works you have older snappy in your image
[09:11] <noizer> zyga: I will build a new image
[09:12] <noizer> zyga when was the last update
[09:12] <noizer> zyga because I build it before with you previous monday (22/02/16)
[09:14] <zyga> noizer: you don't have to build a new image
[09:14] <zyga> noizer: that won't change anything
[09:14] <zyga> noizer: images auto-update if there are new releases
[09:14] <zyga> noizer: I'd suggest injecting new snappy into your existing image
[09:14] <zyga> noizer: my devtools scripts do exactly that
[09:18] <noizer> zyga: oooh ok i will have a  look at it how i need to do it
[09:27] <noizer> zyga can you push me fast around how it works again you devtools
[09:27] <zyga> noizer: sure, clone it somewhere
[09:27] <zyga> noizer: make sure you can run the kvm image or you have a device around
[09:28] <zyga> noizer: make sure you can ssh to your device under the names listed in the readme file (e.g. ssh snappy-pi2)
[09:28] <zyga> noizer: then run ./refresh-bits --pi2 setup snap snapd snappy run-snapd
[09:28] <zyga> noizer: and read the script, it's very simple
[09:29] <noizer> I don't need to do some things with go?
[09:29] <zyga> mvo: I've added sorting tests, the test for Interfaces() is in a subsequent branch, do you want me to cherry pick it in or can it land separetely?
[09:29] <zyga> noizer: sure, you have to be able to build the snappy tree, that's covererd by README.md in the snappy repo
[09:34]  * zyga needs a bigger switch
[09:35] <mvo> dpm: a new os snap is now in rolling/edge so you may need to update your example app
[09:37] <dpm> mvo, thanks! so I need to 'snappy update ubuntu-core' as well I guess?
[09:41] <mvo> dpm: yeah, its in edge right now, I promote to stable in a bit
[09:42] <dpm> ok, I just wanted to see if I did it right, as I caouldn't see any update yet
[09:43] <noizer> Zyga building !!!! niceee
[09:44] <zyga> noizer: cool,
[09:44] <zyga> noizer: patches are welcome, if you can improve the devtools or documentation around them
[09:45] <noizer> zyga: I will think about it and let you know
[09:49] <dpm> mvo, looks about right? http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/revision/282
[09:51] <noizer> zyga: strange its just like you script is blocking
[09:52] <mvo> dpm: yes
[09:53] <dpm> great, thanks
[09:57] <zyga> noizer: it is blocking
[09:57] <zyga> noizer: the run-snapd subcommand blocks
[09:57] <zyga> noizer: and you can see what snapd says if it says something interesting
[09:57] <zyga> noizer: you can ctrl-c it to stop snapd
[09:57] <zyga> noizer: if it's blocking for other reason it's probably misconfigured ssh on your side
[10:01] <zyga> mvo: follow up with more tests https://github.com/ubuntu-core/snappy/pull/571/files
[10:04] <noizer> ubuntu
[10:06] <noizer> zyga here its blocking :s http://pastebin.com/aBafF3RW
[10:11] <zyga> noizer: it's doing exactly what I said it does
[10:11] <zyga> noizer: it's running snapd
[10:11] <zyga> noizer: that's _expected_
[10:11] <zyga> noizer: you can now ssh into your board and run ./snap
[10:11] <noizer> so its done?
[10:11] <zyga> noizer: no
[10:11] <zyga> noizer: it's not done, it's _running_ snapd in the foreground for you to see
[10:12] <zyga> + ssh snappy-pi2 sudo /lib/systemd/systemd-activate -l /run/snapd.socket ./snapd
[10:12] <zyga> ubuntu@192.168.0.133's password:
[10:12] <zyga> Listening on /run/snapd.socket as 3.
[10:12] <zyga> noizer: keep that session around, use another session to play with snappy
[10:12] <noizer> this needs then open all the time?
[10:13] <zyga> noizer: yes
[10:13] <zyga> noizer: this is a development tool
[10:13] <zyga> noizer: it's not something you'd run for any production need
[10:14] <noizer> oooh ok :D
[10:16] <noizer> And now i can make some REST Calls to the new API
[10:18] <zyga> noizer: great!
[10:18] <noizer> zyga I think so
[10:18] <noizer> zyga im trying right know
[10:20] <noizer> zyga  unix connect failed: Permission denied
[10:21] <noizer> nc: unix connect failed: Permission denied
[10:21] <noizer> wasn't complete
[10:28] <noizer> zyga: I can't make any calls to the socket right now
[10:30] <zyga> noizer: is the daemon running?
[10:30] <zyga> noizer: ah, just chmod the socket
[10:30] <zyga> noizer: or run as root
[10:30] <zyga> noizer: systemd-activate makes a socket with restrictive permissions by default
[10:30] <zyga> noizer: that's just a side effect of devtools
[10:35] <noizer> I think its works now
[10:35] <noizer> zyga
[10:38] <zyga> mvo: FYI https://github.com/ubuntu-core/snappy/pull/548#discussion-diff-54862218
[10:38] <zyga> mvo: otherwise yes, LGTM
[11:06] <popey> mvo: is it possible to switch (for example my pi 2) to edge/rolling? So I get latest crack? (I also have a stable pi 2)
[11:10] <mvo> popey: only with a tiny bit of hackery, something like "for f in /var/lib/snappy/meta/*; do sed -i 's/channel: stable/channel: edge/g' $f; done
[11:10] <mvo> popey: Chipaca is working on channel switching from the commandline
[11:10] <popey> ah
[11:10] <mvo> popey: will land soon but not there yet
[11:10] <popey> okay, thanks!
[11:10] <mvo> yw
[11:47] <ogra_> zzarr, (continuing from the other channel) ... i doubt you will make X11 work on snappy unless you drop all security (which in turn will make it un-upgradeable)
[11:48] <ogra_> Mir will work at some point but we are still a bit away from graphical drivers and such on the dragonboard specifically
[11:49] <zzarr> would Mir be sw accelerated, or not work at all?
[11:50] <ogra_> no idea, i'm still working on the basics of the image, i can tell you once i tried the driver ... really depends what state the freedreno driver is in
[11:54] <zzarr> thanks ogra_, I'll begin with a Linaro image
[12:24] <kyrofa> Good morning
[12:32] <didrocks> ogra_: hey, have you seen my askubuntu link?
[12:32] <didrocks> hey kyrofa!
[12:32] <kyrofa> Hey didrocks!
[12:32] <olli_> m
[12:37] <ogra_> didrocks, answered now
[12:43] <didrocks> ogra_: thx!
[12:44] <zyga> mvo: quick question, on reboot, when the system is brought back to life, is there something that takes existing apparmor profiles, compiles them and inserts them into the kernel?
[12:44] <zyga> mvo: it seems that there is something like that as my demos work after rebooting but I cannot find anything like that
[12:45] <ogra_> zyga, s/inserts them into the kernel/rebuilds the cache/
[12:46] <ogra_> it is like on the phone :)
[12:47] <zyga> ogra_: hmm, not sure what "rebuilds the cache" means
[12:48] <zyga> ogra_: apparmor_parser --reload /path/to/profile parsers, compiles and inserts the profile into the kernel
[12:48] <zyga> ogra_: is that what you meant?
[12:51] <kyrofa> enoch85, ping
[12:53] <ogra_> zyga, qwll, i always thought it reads the binary profile from disk ... but yeah, thats what i mean
[12:53] <ogra_> *well
[12:54] <zyga> ogra_: so what does that?
[12:54] <zyga> ogra_: does snappy do that somewhere?
[12:55] <ogra_> there should be a systemd job that checks if they are outdated and kicks in on boot
[12:55] <ogra_> at least that is how it works on the phone
[12:55] <ogra_> ask tyhicks or jdstrand_ how it exactly works on snappy
[12:56] <ogra_> but i would imagine largely the same ...
[13:04] <kyrofa> zyga, I suspect that ubuntu core launcher does it, actually
[13:05] <kyrofa> zyga, not 100% sure about that
[13:08] <kyrofa> zyga, I figure apparmor is configured with the directory to the profiles, and when u-c-l launches the app for the first time the profile is loaded and cached
[13:17] <zyga> kyrofa: no, it doesn't I did check
[13:17] <zyga> kyrofa: currently snappy does that on changes
[13:17] <noizer> zyga Hi what is the best way to connect to the socket with some code
[13:17] <zyga> kyrofa: but I'm curious about the reboot case
[13:18] <zyga> noizer: in which language?
[13:18] <noizer> uuuhm python
[13:18] <zyga> noizer: in go? using our offcial client API
[13:18] <zyga> noizer: in python, using http package or even requests
[13:18] <zyga> noizer: it's just http
[13:18] <zyga> noizer: over a unix socket
[13:18] <noizer> zyga ok I will give it a shot
[13:19] <kyrofa> zyga, how did you check?
[13:19] <zyga> noizer: you can look at the client package
[13:19] <zyga> kyrofa: I read the source of the laucher
[13:19] <zyga> noizer: it's well tested and has example requests and responses
[13:19] <zyga> noizer: it's pretty nice as documentation
[13:19] <zyga> kyrofa: the launcher handles seccomp profile compilation to ebpf
[13:19] <noizer> zyga: client package? where can I find this
[13:19] <zyga> kyrofa: but apparmor profile has to be already loaded in the kernel AFAIR
[13:20] <zyga> noizer: in the snappy source code, the package client/ is in the top-level directory
[13:20] <zyga> https://github.com/ubuntu-core/snappy/tree/master/client
[13:20] <zyga> noizer: e.g. interface related API is here: https://github.com/ubuntu-core/snappy/blob/master/client/interfaces_test.go
[13:22] <kyrofa> zyga, ah, you're right-- the man page says profiles need to already be loaded with apparmor_parser
[13:24] <zyga> kyrofa: I suspect there's a systemd unit that does this on boot
[13:24] <zyga> kyrofa: but I need to dig and I'm in the middle of meetings
[13:30] <zyga> noizer: if you want to build python APIs that'd be quite useful
[13:30] <zyga> noizer: I can work with you on that in small capacity
[13:32] <kyrofa> zyga, etc/init/apparmor.conf in 15.04
[13:32] <noizer> zyga for me thats good
[13:33] <noizer> Just know how to start best on it
[13:34] <zyga> noizer: noizer cool
[13:34] <zyga> kyrofa: thanks!
[13:35] <zyga> I'm not sure that's doing anything in 16.04, I need to see this in more detail
[13:37] <kyrofa> zyga, yeah, same file on 16.04
[13:38] <noizer> zyga when can we start on the python API?
[13:38] <zyga> noizer: for now I'd make that a separate git/pypi project
[13:38] <zyga> noizer: we're super busy with 16.04 and I'd not complicate it by trying to put it in the main snappy repo
[13:39] <zyga> noizer: after 16.04 we can explore doing that
[13:39] <noizer> oooh ok
[13:39] <zyga> noizer: I'd model a python api after the current Go api
[13:39] <zyga> noizer: if you look at cmd/snap/cmd_* you will see that each command is really trivial
[13:39] <noizer> first i will experience some with the REST
[13:39] <zyga> noizer: and you could re-implement snap (the tool) in python in a handful of screens of text
[13:40] <zyga> noizer: so start a new project (say python-snappy) and start working on the initial package with methods that map to go methods
[13:40] <zyga> noizer: and we can work on a case-by-case basis from there
[13:41] <zyga> noizer: which APIs are you going to touch/need first?
[13:42] <noizer> zyga start and stop services
[13:43] <noizer> so the REST api to maybe the python API
[13:45] <zyga> noizer: that might not be exposed yet, look at cmd/snap/cmd_snap_op.go
[13:45] <zyga> noizer: those are "snap operations"
[13:45] <zyga> noizer: and I don't see service operations yet
[13:47] <noizer> zyga I will have a look at it tonight first and then i will let you know what we can start first.
[13:47] <mvo> zyga: yes, there is a systemd job for this
[13:47] <noizer> zyga just an other question about the REST api. I see that it is possible to start and stop services with a PUT
[13:48] <zyga> mvo: ah, interesting piece of the security puzzle
[13:48] <zyga> mvo: I sure hope we don't race with that job
[13:48] <zyga> noizer: oh? perhaps -- I'm mostly focused on interfaces, perhaps all the bits you want are in
[13:49] <mvo> zyga: something like snappy-runhooks
[13:49] <mvo> zyga: I think it is ordered early
[13:50] <zyga> mvo: ideally we'd start like this <run-hooks> <snappy> <snappy activates various apps>
[13:50] <zyga> mvo: but that's only when we have dynamic interfaces that may not be "the same" after a reboot due to hook decisions
[13:50] <zyga> mvo: for static world, it is nor relevant
[13:59] <noizer> zyga ooh ok but it is interesting too. but for now i need to start services with the rest api. But I will try to make a python API
[13:59] <kyrofa> Chipaca, sergiusens how fleshed out are the 16.04 gadget snaps? Can I write one today?
[13:59]  * zyga wants to know too, I have some interface integration I want to do there
[13:59] <zyga> at least for pi
[13:59] <kyrofa> zyga, for pi here too
[14:00] <zyga> kyrofa: you know where the sources for the gadge snap are, right?
[14:00] <zyga> kyrofa: I want to add static interface declarations there so that bits like I2c and some GPIOs are exposed
[14:00] <ogra_> kyrofa, i dont think they will change much
[14:01] <zyga> kyrofa: and more as I enable
[14:01] <noizer> zyga ok are  you online tonight. then we can discuss how to start the api etc.
[14:01] <kyrofa> zyga, nice
[14:01] <kyrofa> ogra_, change much from 15.04?
[14:01] <ogra_> no, from 16.04
[14:01] <zyga> noizer: just ping me here, even if I'm not around
[14:01] <ogra_> 15.04 is dead and done
[14:02] <noizer> zyga ok I will do that
[14:02] <ogra_> (15.04 did not have gadget snaps ... only oem snaps ;) )
[14:02] <kyrofa> ogra_, argh, I'm lost in a sea of terminology :P
[14:02] <ogra_> haha
[14:02] <ogra_> not only you
[14:03]  * ogra_ updates his personal snaps for interskillcapability supoort
[14:03] <ogra_> :P
[14:03] <kyrofa> Ha!
[14:03] <zyga> ogra_: if you could rename it one more time, which word would you pick?
[14:03] <kyrofa> interskillability reads better
[14:04]  * ysionneau ordered an rpi2, to play with Snappy on real HW.
[14:04] <zyga> ysionneau: cool
[14:04] <kyrofa> zyga, powers
[14:04] <ysionneau> I abandonned the fucked up Tegra X1 boards we have
[14:04] <kyrofa> zyga, maybe special-powers
[14:04] <ogra_> zyga, i would rename it to "nomoresprints"
[14:04] <ogra_> every time you gusy have a sprint i need to rebuild my world :P
[14:04] <ogra_> *guys
[14:04] <kyrofa> zyga, we should host a light-hearted poll on that
[14:05] <kyrofa> zyga, regarding sources, you mean the rpi gadget? No, where is that?
[14:06] <ogra_> https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
[14:06] <ogra_> (note that i havent updated rpi2 there yet, i only bumped the 15.04 oem snap a while ago)
[14:06] <kyrofa> Hmm... pi2 or pi2.moved?
[14:06] <ogra_> pi2 iirc
[14:06] <wiggleworm> has anyone here created a snapcraft.yaml file to build tools usbutils or pciutils? If so can you point me to your file?
[14:07] <ogra_> kyrofa, whichever has a snap.yaml (vs package.yaml)
[14:07] <kyrofa> ogra_, indeed, rpi2
[14:07] <jdstrand> zyga: regarding --reload. yes. that command doesn't have any caching options though, so it is just a compile and (re)load
[14:08] <jdstrand> kyrofa: snappy should be using the appropriate caching options when generating the profile on install. and interfaces should when updating the profile.
[14:08] <jdstrand> err
[14:08] <jdstrand> zyga: ^
[14:08] <kyrofa> Thanks jdstrand, I was curious as well :)
[14:09] <kyrofa> ogra_, and gadget snaps are the only way to have snaps preinstalled in the generated image, right?
[14:09] <jdstrand> zyga: and there is an initscript that is called on early boot that makes sure all the profiles are loaded before stuff runs. it will create caches and update outdated ones
[14:11] <ogra_> kyrofa, no, you should be able to just use the --install option ... though that seems to be broken currently (i pointed mvo to it but didnt open a bug yet, seems the "current" link is missing and system units dont get installed for such snaps)
[14:11] <kyrofa> ogra_, oh darn
[14:11] <ogra_> (the --install option of u-d-f that is)
[14:11] <kyrofa> Right
[14:11] <ogra_> probably it is webdm specific though, i installed webdm that way (which btw breaks all upgradeability )
[14:12] <kyrofa> ogra_, well... log that bug!
[14:12] <kyrofa> :P
[14:17] <zyga> jdstrand: thanks
[14:18] <zyga> jdstrand: I'll be doing exactly this today and tomorrow (meetings aside)
[14:18] <zyga> jdstrand: everything else has landed or waits for a review
[14:19] <beuno_> zyga, sounds like enough of the syntax has landed in snap.yaml that we could kick off store integration?
[14:20] <ogra_> identity crisis ?
[14:20] <beuno> yes, going from sprint to sprint messes you up  :)
[14:21] <zyga> beuno: yes, I think it's all in for 16.04
[14:21] <beuno> ooook
[14:21]  * beuno rolls up sleeves
[14:21] <zyga> beuno: I don't know what the channel for transferring local interfaces over to the store is though
[14:21] <zyga> beuno: I would imagine we'd send them in "search" requets
[14:21] <beuno> zyga, we'll work out the API together
[14:21] <zyga> requests*
[14:21] <beuno> yes, in search requests
[14:22] <zyga> beuno: but the primitives have landed now so snappy has this knowledge
[14:22] <jdstrand> zyga, beuno: are you guys talking about skills -> interfaces is now in 16.04 images?
[14:22] <zyga> beuno: it sounds like a nice card to work on next week (mid week)
[14:22] <zyga> jdstrand: yes
[14:22] <jdstrand> alright, I get the review tools branch landed then
[14:22] <jdstrand> I'll*
[14:23] <kyrofa> sergiusens, FYI ^^ time to release
[14:23] <beuno> zyga, I'll find someone to work on this on the store side
[14:23] <zyga> beuno: sounds good
[14:29] <jdstrand> pindonga: can you do a pull of the review tools? (for the skills to interfaces change
[14:29] <jdstrand> )
[14:29] <jdstrand> pindonga: and hi! :)
[14:29] <pindonga> jdstrand, hi :)
[14:30] <pindonga> ack, will do, but not sure it'll get to prod this week
[14:30] <pindonga> btw, we're on 599 on staging
[14:30] <jdstrand> understood
[14:30] <pindonga> with the new click-review stuff
[14:30] <jdstrand> great
[14:30] <jdstrand> nice! :)
[14:30] <pindonga> if you can submit a few snaps/clicks to test it it'd be great
[14:30] <mvo> ogra_: hm, that should work, the symlink should get created on first boot
[14:31] <jdstrand> ok
[15:02] <kyrofa> ogra_, do you know if we have working kernel snaps as well?
[15:11] <ogra_> kyrofa, all in the store
[15:12] <kyrofa> ogra_, awesome, any chance you know where the sources are?
[15:12] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[15:13] <ogra_> dragonboard  is still a local build from the deb in the archive
[15:13] <ogra_> all others come from these device tarballs
[15:18] <kyrofa> ogra_, I mean the thing containing the snap.yaml. These are all built, right?
[15:18] <ogra_> manually
[15:19] <ogra_> using the scripts from http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
[15:19] <ogra_> (which i hope to have integrated into the build system soon)
[15:20] <kyrofa> ogra_, ah, thanks!
[15:26] <sergiusens> ogra_, kyrofa --install is no different in udf logic to putting it in  a gadget
[15:26] <kyrofa> sergiusens, awesome
[15:26] <ogra_> sergiusens, well
[15:26] <ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --gadget canonical-dragon.canonical --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical -o dragonboard-all-snap.img
[15:27] <ogra_> that gets me an installed webdm without anyx systemd units in place and without the current symlink
[15:27] <ogra_> in that state i cant remove or install the package and auto-upgrades break when trying to stop the webdm service
[15:27] <ogra_> err
[15:27] <ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --gadget canonical-dragon.canonical --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical --install webdm.canonical -o dragonboard-all-snap.img
[15:28] <jdstrand> pindonga: something isn't right. I just uploaded hello-world 16.04-2 (20) to the store and I see:
[15:28] <jdstrand>  2 Passes
[15:28] <jdstrand> OK Stated package version matches the manifest
[15:28] <jdstrand> OK Is a valid click package
[15:28] <ogra_> that was the right one (sorry, pasted from the wrong terminal)
[15:28] <sergiusens> ogra_, right; I'm saying if it is roken for one case it is also brokem for the other
[15:28] <kyrofa> ogra_, man was I confused :P
[15:28] <ogra_> sergiusens, well, gadget is installed ... and i can manually upgrade ubuntu-core
[15:28] <jdstrand> pindonga: the review tools aren't being run
[15:28] <ogra_> the system works fine otherwise
[15:29] <jdstrand> pindonga: https://myapps.developer.ubuntu.com/dev/click-apps/1999/rev/20/
[15:29] <pindonga> jdstrand, errr... staging... the new stuff hasn't landed on prod yet
[15:29] <jdstrand> oh
[15:30] <jdstrand> pindonga: when do we expect that to happen?
[15:31] <pindonga> jdstrand, early next week
[15:31] <pindonga> I'll see if I can do that today
[15:31] <pindonga> but no promises
[15:32] <jdstrand> ok, thanks
[15:32] <renat> Hi all! It's Renat from Screenly=)
[15:33] <kyrofa> Hey renat :)
[15:33] <renat> First of all I want to thank snappy team for help.
[15:33] <renat> =)
[15:33] <pindonga> jdstrand, if I pull this off, is r601 of crt good to go?
[15:33] <renat> Our first snap worked well=)\
[15:33] <jdstrand> pindonga: yes
[15:33] <ogra_> renat, yay !
[15:34] <renat> I have questions, as usual=)
[15:35] <renat> What do snap developers use to build their snaps for raspberry pi? We used Ubuntu MATE, but maybe there are other solutions?
[15:35] <pindonga> jdstrand, pls test on staging sca as we won't roll out to prod if we find the review tools broken there
[15:35]  * pindonga is testing as well
[15:36] <jdstrand> pindonga: the last time I tried on staging istr that I wasn't able to test
[15:36] <beuno> renat, we're building out snap building into Launchpad
[15:36] <pindonga> jdstrand, why?
[15:36] <jdstrand> pindonga: can you tell me where to go to try again?
[15:36] <beuno> renat, so you can build them for ARM in there if you don't have the hardware
[15:36] <jdstrand> idr
[15:36] <pindonga> jdstrand, https://myapps.developer.staging.ubuntu.com
[15:36] <jdstrand> I'll try now though
[15:37] <pindonga> thx, let me know if you have any troubles
[15:37] <beuno> renat, just push a branch with snapcraft, and there will be an option to build a snap from it
[15:37] <renat> I have=) I build on the RaspberryPI2. It's ultra slow=)
[15:37] <renat> beuno, thanks! Amazing!
[15:38] <jdstrand> pindonga: I can't login with the shared account
[15:38] <beuno> renat, you probably need to enable ARM specifically, I think it doesn't build for ARM by default
[15:38] <beuno> on the change details for the snap, once you create it
[15:39] <jdstrand> pindonga: should I try with my personal lp account?
[15:39] <ogra_> renat, for native builds i use the classic dimension under snappy itself ... "sudo snappy enable-classic; snappy shell classic".... then just use apt as usual
[15:40] <renat> ogra_, never tried that.
[15:40] <renat> Thanks for help. Now I have something to experiment with!
[15:40] <ogra_> :)
[15:42] <pindonga> jdstrand, remember staging myapps uses staging sso
[15:42] <pindonga> so separate account
[15:42] <renat> beuno, never used launchpad before. Going to investigate its capabilities soon, thanks.
[15:47] <jdstrand> pindonga: I'm not trying to be dense, but I don't know what to do with that information. are you saying I need to use a separate staging account? if so, how do I get one?
[15:47] <jdstrand> I think I see now why I wasn't able to test on staging :P
[15:49] <pindonga> jdstrand, sorry, yes, you need a staging sso account (login.staging.ubuntu.com)
[15:49] <pindonga> jdstrand, don't worry, I'll do the testing
[15:49] <jdstrand> zyga: hey, I have this yaml: http://paste.ubuntu.com/15274178/ and if I try to install then I see:
[15:49] <pindonga> no point in you having to struggle with this
[15:49] <jdstrand> $ sudo snappy install /tmp/snappy-interfaces-security_0.1_all.snap
[15:49] <jdstrand> Installing /tmp/snappy-interfaces-security_0.1_all.snap
[15:49] <jdstrand> Waiting for snaps-snappy\x2dinterfaces\x2dsecurity.sideload-LSDpPYfYXdlm.mount to stop.
[15:49] <jdstrand> /tmp/snappy-interfaces-security_0.1_all.snap failed to install: only a single slot is supported, 2 found
[15:49] <jdstrand> pindonga: ok thanks. I think it's possible that was the exact outcome we had last time :)
[15:50] <pindonga> quite likely :)
[15:50] <jdstrand> zyga: is there a bug in the yaml or is this just that the interfaces work isn't completed yet?
[15:51] <jdstrand> I believe I am following the documented spec
[15:56] <ysionneau> zyga : so I'm still trying to find out why my hello world (which does dlopen) crashes when it's cross compiled with my own toolchain, but works when using native compiling (in classic shell)
[15:56] <ysionneau> I've attached gdb to the process
[15:57] <jdstrand> mvo_: ok, fyi, hello-world uploaded with updated bash. the store fixes are only on staging. pin donga is working on getting them in prod today, but it might be monday
[15:57] <ysionneau> and when I look at /proc/<pid>/maps , it shows it's using the libraries from the .snap (libc, libdl, libgcc_s) but it's using the dynamic linker from the system
[15:57] <ysionneau> /lib/arm-linux-gnueabihf/ld-2.21.so
[15:57] <ysionneau> I guess this causes the crash
[16:01] <ysionneau> any idea how I can try to use /snaps/hello.sideload/IOCceQHPQPfQ/lib/ld-linux-armhf.so.3 instead of /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ?
[16:03] <ysionneau> I can confirm if I run /lib/ld-linux-armhf.so.3 /snaps/hello.sideload/IOCceQHPQPfQ/usr/bin/hello it crashes, if I run /snaps/hello.sideload/IOCceQHPQPfQ/lib/ld-linux-armhf.so.3 /snaps/hello.sideload/IOCceQHPQPfQ/usr/bin/hello it works
[16:03] <ysionneau> so it's indeed a dynamic linker issue
[16:04] <ogra_> try a wrapper script that sets PATH ?
[16:04] <ogra_> hmm, though that wont help i guess
[16:17] <ysionneau> ok I get it now
[16:17] <ysionneau> I will wrap all my binaries with something that will call $SNAP/lib/ld-linux-armhf.so.3 <binary_name>
[16:18] <ysionneau> 17:04 < ogra_> hmm, though that wont help i guess < nop because the dynamic linker does not use LD_LIBRARY_PATH or PATH, it's loaded by the kernel, taking the string in the "interp" section of the ELF
[16:18] <ysionneau> but it's OK to prefix the binary with the path to the dynamic linker in a wrapper
[16:18] <ysionneau> o/
[16:18] <ysionneau> I might end up with something which works after all...
[16:18] <ogra_> awful, but will likely work :)
[16:19] <ysionneau> not more awful than all the already existing wrappers :p
[16:19] <ogra_> haha, yeah
[16:19] <ogra_> wrappers in wrappers that are in wrapped wrappers :)
[16:19] <ysionneau> ;)
[16:19] <ysionneau> yep
[16:20] <ysionneau> it's either this, or hard coding it in ubuntu-core-launcher like "if (there is a dynamic linker in the snap) execve prefixed with it"
[16:20] <ysionneau> but I suspect you would not like this upstream
[16:20] <ogra_> no idea, i dont maintain the launcher ;)
[16:21] <ysionneau> ah so maybe you would +2 this :p
[16:21]  * ysionneau joking
[16:21] <ogra_> if it saves the dve from hassles i could actually imagine it going upstream
[16:21] <ysionneau> dve ?
[16:21] <ogra_> but i guess the heuristics of "whats a wrapper, how do we identify there is one" might be pretty complicated
[16:21] <ogra_> err
[16:21] <ogra_> s/wrapper/linker/
[16:22] <ogra_> (my head is also full of wrappers it seems)
[16:22] <ogra_> *dev
[16:22] <ogra_> tedg, ^^
[16:24] <tedg> ogra_: ?
[16:25] <ogra_> tedg, if a package ships its own linker,, would it make sense to handle that from ubuntu-core-launcher ?
[16:25] <ogra_> (instead of having to have another wrapper to prefix all calls with the linker path)
[16:26] <tedg> ogra_: I'd say that we don't have a way to signal things to the launcher today, so the wrapper is the better option. I'd like to see the launcher get smarter, but I think that needs to be engineered.
[16:27] <ysionneau> 17:22 < ogra_> (my head is also full of wrappers it seems) < that's when you wrap your head around it
[16:27] <tedg> ogra_: It would be nice if it could load all the environment variables in a consistent way as well, for instance.
[16:27] <ogra_> tedg, yeah, in the case of the linker you dont really have an env var though
[16:27] <tedg> ogra_: Sure, just talking about other things that a more rich launcher would handle.
[16:27] <ogra_> you need to wrap your exec calls into something like "$SNAP/lib/ld-linux-armhf.so.3 <binary_name>"
[16:28] <ogra_> and it would be nice if we could just tell the launcher to do that for us
[16:29] <ysionneau> yep, when you detect that the interp of the binary does exist in the $SNAP/
[16:29] <ysionneau> means you need to parse the ELF to get the interp string
[16:29] <ysionneau> that's actually not that hard to add to the launcher :o
[16:30] <ogra_> well, it could be some option ... or config
[16:31] <ogra_> you dont want to do it all the time
[16:31] <ogra_> (most people will likely just use the system linker)
[16:32] <ogra_> (and rely on LD_LIBRABRY_PATH for their own libs)
[17:01] <kyrofa> wiggleworm, you still around?
[17:12] <ysionneau> well, if you have a path that corresponds to the dynamic linker in your $SNAP, you most likely want to use it
[17:25] <jdstrand> niemeyer: you seem to have disconeected
[17:44] <kyrofa> ogra_, so if cdimage is used to create the kernel snaps, where might I find the kernel configs that we use?
[17:46] <ogra_> either in the source package or in the git trees on kernel.ubuntu.com (ask the kernel team for specific branch urls)
[17:48] <kyrofa> ogra_, excellent thank you
[18:19] <sergiusens> ogra_, do you know if your initrd made it into an OS snap?
[18:20] <ogra_> sergiusens, it made it into all tarballs ... no idea if mvo rebuilt the os snaps today though
[18:20] <ogra_> (its all manual)
[18:20] <ogra_> http://people.canonical.com/~ogra/core-image-stats/20160303.changes
[18:22] <sergiusens> yeah
[18:23] <ogra_> worst case roll your own http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
[18:23] <ogra_> (the mk-os ones should suffice)
[18:35] <sergiusens> ogra_, he'll be pushing one soon
[18:35] <ogra_> k
[18:35] <sergiusens> ogra_, where is this generic initrd installed btw?
[18:36] <ogra_> ogra@styx:~/Devel/packages/initramfs-tools-ubuntu-core-0.7.20$ cat debian/ubuntu-core-generic-initrd.install
[18:36] <ogra_> build/boot/* usr/lib/ubuntu-core-generic-initrd/
[18:36] <ogra_> ogra@styx:~/Devel/packages/initramfs-tools-ubuntu-core-0.7.20$
[18:36] <ogra_> :)
[18:36] <sergiusens> thanks
[18:41] <pindonga> jdstrand, hey, got crt 601 to prod... could you please test uploading some snap ?
[18:41] <pindonga> the fact we can't upload snaps with the same name anymore is a nuisance for testing :/
[18:49] <sergiusens> jdstrand, hey, I never got your ack/nack on https://github.com/ubuntu-core/snapcraft/pull/360
[18:58] <rajen> Folks. Is there a place where you are uploading ".img" file or ".snap's" of daily-preinstalled xenial builds.  I am looking for ubuntu-core snap files when they get released.
[19:10] <jdstrand> pindonga: it is
[19:11] <jdstrand> sergiusens: I'm going to test that snap, have a quick bite to eat, then review your PR
[19:12] <jdstrand> sergiusens: btw, I dig 'snapcraft snap <dir>'
[19:12] <jdstrand> :)
[19:12] <jdstrand> so much nicer than remembering the mksquashfs commands
[19:12] <jdstrand> s/commands/args/
[19:14] <jdstrand> pindonga: woo!
[19:14] <jdstrand>  1 Warning
[19:14] <jdstrand> could not determine fstime of squashfs security-snap-v2_squashfs_supports_fstime
[19:14] <jdstrand> 58 Passes
[19:14] <jdstrand> perfect-o!
[19:14] <pindonga> \o/
[19:15] <jdstrand> pindonga: what interesting though is I don't see the review tools commit number in the passes output any more
[19:16] <jdstrand> pindonga: that certainly doesn't have to be a rushed fix
[19:16] <pindonga> it's only listed for reviewers
[19:16] <jdstrand> ah
[19:16]  * pindonga double checks though, should be there
[19:16] <jdstrand> pindonga: I can do it
[19:17] <jdstrand> pindonga: 601 click-reviewers-tools version
[19:17] <pindonga> yep
[19:18] <jdstrand> pindonga: thanks for the quick turnaround
[19:18] <pindonga> happy it (seemed) to work well (so far)
[19:18] <pindonga>  :)
[19:18] <jdstrand> beuno: fyi, the store is back to reviewing again :)
[19:18] <jdstrand> thanks to pindonga :)
[19:18] <jdstrand> I guess I helped a little
[19:18] <pindonga> :)
[19:26] <the-solipsist> Sorry for a stupid question, but I'm a newbie... If snappy already does app isolation, why would anyone want to install docker on it?
[19:27] <Mikaela> Probably because docker has mostly everything available while snappy doesn't have so much
[19:30] <the-solipsist> So, it's just a matter of time?  And, if Docker provides the kind of app isolation that snappy does, then why create snappy at all?  I can understand the need for LXD, but not for Snappy...
[19:36] <sergiusens> the-solipsist, there's a nice email from Mark in the mailing lists explaining when to use one or the other
[19:39] <ogra_> there are people using snappy in cloud envs ... they are used to docker and have their setups ready to just use them ...
[19:39] <popey> ogra_: I'm told that in the debian world, one just does a dist-upgrade and rpi-update of an image inside a pi 2, to make it work in a pi 3.
[19:39] <popey> https://twitter.com/winkleink/status/705477199042838528
[19:40] <popey> so I guess we need to find out what that does, and update our image, then our image will work on pi 2 and pi 3
[19:40] <ogra_> popey, yeah, most likely some kernel changes to get the devicetree file for the new pi ... and likely also some bootloader updates
[19:40] <ogra_> i'll check on the weekend
[19:41] <wiggleworm> orga_: Do you know anyone who has created a snapcraft.yaml file to build tools usbutils or pciutils?
[19:41] <ogra_> wiggleworm, i doubt that will be possible in a way that you can upload this snap to the store
[19:42] <ogra_> (i might be wrong, but i suspect you will need to access most of /proc and such which means you need to run unconfined ... which in turn means you wont be allowed into the store)
[19:43] <ogra_> wiggleworm, if you want unconfined you can take a look at somehting like http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files though
[19:43] <wiggleworm> thank you - I will look
[19:44] <ogra_> (note though that this hasnt been ported to the security model de jour yet (now called "interfaces") bt still uses last weeks "skills" system)
[19:45]  * ogra_ goes afk ...
[20:48] <dduffey> kyrofa, lool : I am compiling the 3.18 kernel now and seeing if my compile of that vmlinuz still links with with binary modules I have ... if so, then I will re-compile that 3.18 with the necessary kernel settings snappy needs ... do you have a list of config options that I need (and I'm assuming it is okay to statically compile in items rather than have them as modules/add them to initrd)
[20:57] <jdstrand> sergiusens: done
[21:05] <sergiusens> jdstrand, thanks
[21:07] <sergiusens> jdstrand, hm, should I add umask != 0 as well?
[21:13] <jdstrand> sergiusens: you could. that is actually something I would expect the review tools to catch (ie, 0777 file perms)
[21:14] <jdstrand> plus, other access isn't as big of a deal-- a snap shouldn't be shipping private data since it isn't actually private
[21:14] <jdstrand> I don't think it is needed. let the review tools discover weird perms
[21:15] <sergiusens> jdstrand, ok, seems good
[21:17] <sergiusens> kyrofa, mind to start reviewing https://github.com/ubuntu-core/snapcraft/compare/master...sergiusens:feature/1552168/kernel-plugin#diff-a6d756e312a41b33e3a9de439c8527a8R9 ?
[21:20] <sergiusens> kyrofa, the busybox example already works
[21:20] <sergiusens> let me just create a PR
[23:43] <popey> ogra_: fyi, sudo iwconfig wlan0 power off - needed on pi 3, it power saves wifi which means it's unusable
[23:47] <zyga> jdstrand: thanks for the meeeting notes