=== FourDollars_ is now known as FourDollars === sarnold_ is now known as sarnold === Tristit1a is now known as Tristitia [07:28] 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] ogra_: and please poke me, I'm interested in the answer as well :) [07:54] good morning [08:08] good morning dholbach [08:08] salut didrocks [08:30] good morning [08:38] good morning [08:42] mvo: hey, it seems that even if we branch snapcraftv1, we can't build anymore 15.04 snaps on xenial. [08:42] mvo: Snapping / [08:42] open /home/didrocks/work/ubuntu-core/demos/youtube-streamer/snap/meta/snap.yaml: no such file or directory [08:42] I guess the issue is the new metadata snappy files [08:42] and so snappy snap doesn't know it's some 15.04 snaps and look for this [08:44] (I did downgrade snappy for now) [08:46] didrocks: yeah, snappy is unfortunately not able to do 15.04 stuff in xenial [08:46] 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] 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 === popey_ is now known as popey [09:02] Hi I played some with the REST API but i got an error with this call. [09:02] http://pastebin.com/e4yVQTKj [09:04] noizer: which version of snappy did you use? [09:04] noizer: can you run "snap interfaces" [09:05] 16.04 [09:05] zyga [09:05] noizer: and FYI: https://github.com/ubuntu-core/snappy/pull/559 [09:06] mvo: thank you! [09:07] ok but i got it for other different calls like /2.0/snaps/nameOfSnap/services [09:07] noizer: you might have to authenticate [09:07] noizer: or run as root [09:08] hmmm ok i will check it first out [09:08] noizer: look at the rest.md file [09:08] noizer: it says what each of the method requires [09:08] noizer: including authentication [09:08] 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] zyga: but with the /2.0/snaps there needed to be authentication too but it works right out the box [09:09] noizer: maybe your image still has /2.0/skills [09:10] noizer: I'd recommend using my devtools scripts to run latest master on your image [09:10] maybe [09:10] noizer: try the get with /2.0/skills [09:10] if that works you have older snappy in your image [09:11] zyga: I will build a new image [09:12] zyga when was the last update [09:12] zyga because I build it before with you previous monday (22/02/16) [09:14] noizer: you don't have to build a new image [09:14] noizer: that won't change anything [09:14] noizer: images auto-update if there are new releases [09:14] noizer: I'd suggest injecting new snappy into your existing image [09:14] noizer: my devtools scripts do exactly that [09:18] zyga: oooh ok i will have a look at it how i need to do it [09:27] zyga can you push me fast around how it works again you devtools [09:27] noizer: sure, clone it somewhere [09:27] noizer: make sure you can run the kvm image or you have a device around [09:28] noizer: make sure you can ssh to your device under the names listed in the readme file (e.g. ssh snappy-pi2) [09:28] noizer: then run ./refresh-bits --pi2 setup snap snapd snappy run-snapd [09:28] noizer: and read the script, it's very simple [09:29] I don't need to do some things with go? [09:29] 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] 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] dpm: a new os snap is now in rolling/edge so you may need to update your example app [09:37] mvo, thanks! so I need to 'snappy update ubuntu-core' as well I guess? [09:41] dpm: yeah, its in edge right now, I promote to stable in a bit [09:42] ok, I just wanted to see if I did it right, as I caouldn't see any update yet [09:43] Zyga building !!!! niceee [09:44] noizer: cool, [09:44] noizer: patches are welcome, if you can improve the devtools or documentation around them [09:45] zyga: I will think about it and let you know [09:49] mvo, looks about right? http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/revision/282 [09:51] zyga: strange its just like you script is blocking [09:52] dpm: yes [09:53] great, thanks [09:57] noizer: it is blocking [09:57] noizer: the run-snapd subcommand blocks [09:57] noizer: and you can see what snapd says if it says something interesting [09:57] noizer: you can ctrl-c it to stop snapd [09:57] noizer: if it's blocking for other reason it's probably misconfigured ssh on your side [10:01] mvo: follow up with more tests https://github.com/ubuntu-core/snappy/pull/571/files === Odd_Blok1 is now known as Odd_Bloke [10:04] ubuntu [10:06] zyga here its blocking :s http://pastebin.com/aBafF3RW [10:11] noizer: it's doing exactly what I said it does [10:11] noizer: it's running snapd [10:11] noizer: that's _expected_ [10:11] noizer: you can now ssh into your board and run ./snap [10:11] so its done? [10:11] noizer: no [10:11] noizer: it's not done, it's _running_ snapd in the foreground for you to see [10:12] + ssh snappy-pi2 sudo /lib/systemd/systemd-activate -l /run/snapd.socket ./snapd [10:12] ubuntu@192.168.0.133's password: [10:12] Listening on /run/snapd.socket as 3. [10:12] noizer: keep that session around, use another session to play with snappy [10:12] this needs then open all the time? [10:13] noizer: yes [10:13] noizer: this is a development tool [10:13] noizer: it's not something you'd run for any production need [10:14] oooh ok :D [10:16] And now i can make some REST Calls to the new API [10:18] noizer: great! [10:18] zyga I think so [10:18] zyga im trying right know [10:20] zyga unix connect failed: Permission denied [10:21] nc: unix connect failed: Permission denied [10:21] wasn't complete [10:28] zyga: I can't make any calls to the socket right now [10:30] noizer: is the daemon running? [10:30] noizer: ah, just chmod the socket [10:30] noizer: or run as root [10:30] noizer: systemd-activate makes a socket with restrictive permissions by default [10:30] noizer: that's just a side effect of devtools [10:35] I think its works now [10:35] zyga [10:38] mvo: FYI https://github.com/ubuntu-core/snappy/pull/548#discussion-diff-54862218 [10:38] mvo: otherwise yes, LGTM === lool- is now known as lool [11:06] 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] 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] popey: Chipaca is working on channel switching from the commandline [11:10] ah [11:10] popey: will land soon but not there yet [11:10] okay, thanks! [11:10] yw [11:47] 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] Mir will work at some point but we are still a bit away from graphical drivers and such on the dragonboard specifically [11:49] would Mir be sw accelerated, or not work at all? [11:50] 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] thanks ogra_, I'll begin with a Linaro image [12:24] Good morning [12:32] ogra_: hey, have you seen my askubuntu link? [12:32] hey kyrofa! [12:32] Hey didrocks! [12:32] m === olli_ is now known as olli [12:37] didrocks, answered now [12:43] ogra_: thx! [12:44] 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] mvo: it seems that there is something like that as my demos work after rebooting but I cannot find anything like that [12:45] zyga, s/inserts them into the kernel/rebuilds the cache/ [12:46] it is like on the phone :) [12:47] ogra_: hmm, not sure what "rebuilds the cache" means [12:48] ogra_: apparmor_parser --reload /path/to/profile parsers, compiles and inserts the profile into the kernel [12:48] ogra_: is that what you meant? [12:51] enoch85, ping [12:53] zyga, qwll, i always thought it reads the binary profile from disk ... but yeah, thats what i mean [12:53] *well [12:54] ogra_: so what does that? [12:54] ogra_: does snappy do that somewhere? [12:55] there should be a systemd job that checks if they are outdated and kicks in on boot [12:55] at least that is how it works on the phone [12:55] ask tyhicks or jdstrand_ how it exactly works on snappy [12:56] but i would imagine largely the same ... [13:04] zyga, I suspect that ubuntu core launcher does it, actually [13:05] zyga, not 100% sure about that [13:08] 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] kyrofa: no, it doesn't I did check [13:17] kyrofa: currently snappy does that on changes [13:17] zyga Hi what is the best way to connect to the socket with some code [13:17] kyrofa: but I'm curious about the reboot case [13:18] noizer: in which language? [13:18] uuuhm python [13:18] noizer: in go? using our offcial client API [13:18] noizer: in python, using http package or even requests [13:18] noizer: it's just http [13:18] noizer: over a unix socket [13:18] zyga ok I will give it a shot [13:19] zyga, how did you check? [13:19] noizer: you can look at the client package [13:19] kyrofa: I read the source of the laucher [13:19] noizer: it's well tested and has example requests and responses [13:19] noizer: it's pretty nice as documentation [13:19] kyrofa: the launcher handles seccomp profile compilation to ebpf [13:19] zyga: client package? where can I find this [13:19] kyrofa: but apparmor profile has to be already loaded in the kernel AFAIR [13:20] noizer: in the snappy source code, the package client/ is in the top-level directory [13:20] https://github.com/ubuntu-core/snappy/tree/master/client [13:20] noizer: e.g. interface related API is here: https://github.com/ubuntu-core/snappy/blob/master/client/interfaces_test.go [13:22] zyga, ah, you're right-- the man page says profiles need to already be loaded with apparmor_parser [13:24] kyrofa: I suspect there's a systemd unit that does this on boot [13:24] kyrofa: but I need to dig and I'm in the middle of meetings [13:30] noizer: if you want to build python APIs that'd be quite useful [13:30] noizer: I can work with you on that in small capacity [13:32] zyga, etc/init/apparmor.conf in 15.04 [13:32] zyga for me thats good [13:33] Just know how to start best on it [13:34] noizer: noizer cool [13:34] kyrofa: thanks! [13:35] I'm not sure that's doing anything in 16.04, I need to see this in more detail [13:37] zyga, yeah, same file on 16.04 [13:38] zyga when can we start on the python API? [13:38] noizer: for now I'd make that a separate git/pypi project [13:38] 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] noizer: after 16.04 we can explore doing that [13:39] oooh ok [13:39] noizer: I'd model a python api after the current Go api [13:39] noizer: if you look at cmd/snap/cmd_* you will see that each command is really trivial [13:39] first i will experience some with the REST [13:39] noizer: and you could re-implement snap (the tool) in python in a handful of screens of text [13:40] 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] noizer: and we can work on a case-by-case basis from there [13:41] noizer: which APIs are you going to touch/need first? [13:42] zyga start and stop services [13:43] so the REST api to maybe the python API [13:45] noizer: that might not be exposed yet, look at cmd/snap/cmd_snap_op.go [13:45] noizer: those are "snap operations" [13:45] noizer: and I don't see service operations yet [13:47] zyga I will have a look at it tonight first and then i will let you know what we can start first. [13:47] zyga: yes, there is a systemd job for this [13:47] 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] mvo: ah, interesting piece of the security puzzle [13:48] mvo: I sure hope we don't race with that job [13:48] noizer: oh? perhaps -- I'm mostly focused on interfaces, perhaps all the bits you want are in [13:49] zyga: something like snappy-runhooks [13:49] zyga: I think it is ordered early [13:50] mvo: ideally we'd start like this [13:50] 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] mvo: for static world, it is nor relevant [13:59] 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] 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] at least for pi [13:59] zyga, for pi here too [14:00] kyrofa: you know where the sources for the gadge snap are, right? [14:00] kyrofa: I want to add static interface declarations there so that bits like I2c and some GPIOs are exposed [14:00] kyrofa, i dont think they will change much [14:01] kyrofa: and more as I enable [14:01] zyga ok are you online tonight. then we can discuss how to start the api etc. [14:01] zyga, nice [14:01] ogra_, change much from 15.04? [14:01] no, from 16.04 [14:01] noizer: just ping me here, even if I'm not around [14:01] 15.04 is dead and done [14:02] zyga ok I will do that [14:02] (15.04 did not have gadget snaps ... only oem snaps ;) ) [14:02] ogra_, argh, I'm lost in a sea of terminology :P [14:02] haha [14:02] not only you === jdstrand_ is now known as jdstrand [14:03] * ogra_ updates his personal snaps for interskillcapability supoort [14:03] :P [14:03] Ha! [14:03] ogra_: if you could rename it one more time, which word would you pick? [14:03] interskillability reads better [14:04] * ysionneau ordered an rpi2, to play with Snappy on real HW. [14:04] ysionneau: cool [14:04] zyga, powers [14:04] I abandonned the fucked up Tegra X1 boards we have [14:04] zyga, maybe special-powers [14:04] zyga, i would rename it to "nomoresprints" [14:04] every time you gusy have a sprint i need to rebuild my world :P [14:04] *guys [14:04] zyga, we should host a light-hearted poll on that [14:05] zyga, regarding sources, you mean the rpi gadget? No, where is that? [14:06] https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems [14:06] (note that i havent updated rpi2 there yet, i only bumped the 15.04 oem snap a while ago) [14:06] Hmm... pi2 or pi2.moved? [14:06] pi2 iirc [14:06] 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] kyrofa, whichever has a snap.yaml (vs package.yaml) [14:07] ogra_, indeed, rpi2 [14:07] zyga: regarding --reload. yes. that command doesn't have any caching options though, so it is just a compile and (re)load [14:08] kyrofa: snappy should be using the appropriate caching options when generating the profile on install. and interfaces should when updating the profile. [14:08] err [14:08] zyga: ^ [14:08] Thanks jdstrand, I was curious as well :) [14:09] ogra_, and gadget snaps are the only way to have snaps preinstalled in the generated image, right? [14:09] 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] 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] ogra_, oh darn [14:11] (the --install option of u-d-f that is) [14:11] Right [14:11] probably it is webdm specific though, i installed webdm that way (which btw breaks all upgradeability ) [14:12] ogra_, well... log that bug! [14:12] :P [14:17] jdstrand: thanks [14:18] jdstrand: I'll be doing exactly this today and tomorrow (meetings aside) [14:18] jdstrand: everything else has landed or waits for a review [14:19] zyga, sounds like enough of the syntax has landed in snap.yaml that we could kick off store integration? === beuno_ is now known as beuni === beuni is now known as beuno [14:20] identity crisis ? [14:20] yes, going from sprint to sprint messes you up :) [14:21] beuno: yes, I think it's all in for 16.04 [14:21] ooook [14:21] * beuno rolls up sleeves [14:21] beuno: I don't know what the channel for transferring local interfaces over to the store is though [14:21] beuno: I would imagine we'd send them in "search" requets [14:21] zyga, we'll work out the API together [14:21] requests* [14:21] yes, in search requests [14:22] beuno: but the primitives have landed now so snappy has this knowledge [14:22] zyga, beuno: are you guys talking about skills -> interfaces is now in 16.04 images? [14:22] beuno: it sounds like a nice card to work on next week (mid week) [14:22] jdstrand: yes [14:22] alright, I get the review tools branch landed then [14:22] I'll* [14:23] sergiusens, FYI ^^ time to release [14:23] zyga, I'll find someone to work on this on the store side [14:23] beuno: sounds good [14:29] pindonga: can you do a pull of the review tools? (for the skills to interfaces change [14:29] ) [14:29] pindonga: and hi! :) [14:29] jdstrand, hi :) [14:30] ack, will do, but not sure it'll get to prod this week [14:30] btw, we're on 599 on staging [14:30] understood [14:30] with the new click-review stuff [14:30] great [14:30] nice! :) [14:30] if you can submit a few snaps/clicks to test it it'd be great [14:30] ogra_: hm, that should work, the symlink should get created on first boot [14:31] ok === rcj` is now known as rcj [15:02] ogra_, do you know if we have working kernel snaps as well? [15:11] kyrofa, all in the store [15:12] ogra_, awesome, any chance you know where the sources are? [15:12] http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ [15:13] dragonboard is still a local build from the deb in the archive [15:13] all others come from these device tarballs [15:18] ogra_, I mean the thing containing the snap.yaml. These are all built, right? [15:18] manually [15:19] using the scripts from http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files [15:19] (which i hope to have integrated into the build system soon) [15:20] ogra_, ah, thanks! [15:26] ogra_, kyrofa --install is no different in udf logic to putting it in a gadget [15:26] sergiusens, awesome [15:26] sergiusens, well [15:26] 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] that gets me an installed webdm without anyx systemd units in place and without the current symlink [15:27] in that state i cant remove or install the package and auto-upgrades break when trying to stop the webdm service [15:27] err [15:27] 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] pindonga: something isn't right. I just uploaded hello-world 16.04-2 (20) to the store and I see: [15:28] 2 Passes [15:28] OK Stated package version matches the manifest [15:28] OK Is a valid click package [15:28] that was the right one (sorry, pasted from the wrong terminal) [15:28] ogra_, right; I'm saying if it is roken for one case it is also brokem for the other [15:28] ogra_, man was I confused :P [15:28] sergiusens, well, gadget is installed ... and i can manually upgrade ubuntu-core [15:28] pindonga: the review tools aren't being run [15:28] the system works fine otherwise [15:29] pindonga: https://myapps.developer.ubuntu.com/dev/click-apps/1999/rev/20/ [15:29] jdstrand, errr... staging... the new stuff hasn't landed on prod yet [15:29] oh [15:30] pindonga: when do we expect that to happen? [15:31] jdstrand, early next week [15:31] I'll see if I can do that today [15:31] but no promises [15:32] ok, thanks [15:32] Hi all! It's Renat from Screenly=) [15:33] Hey renat :) [15:33] First of all I want to thank snappy team for help. [15:33] =) [15:33] jdstrand, if I pull this off, is r601 of crt good to go? [15:33] Our first snap worked well=)\ [15:33] pindonga: yes [15:33] renat, yay ! [15:34] I have questions, as usual=) [15:35] What do snap developers use to build their snaps for raspberry pi? We used Ubuntu MATE, but maybe there are other solutions? [15:35] 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] pindonga: the last time I tried on staging istr that I wasn't able to test [15:36] renat, we're building out snap building into Launchpad [15:36] jdstrand, why? [15:36] pindonga: can you tell me where to go to try again? [15:36] renat, so you can build them for ARM in there if you don't have the hardware [15:36] idr [15:36] jdstrand, https://myapps.developer.staging.ubuntu.com [15:36] I'll try now though [15:37] thx, let me know if you have any troubles [15:37] renat, just push a branch with snapcraft, and there will be an option to build a snap from it [15:37] I have=) I build on the RaspberryPI2. It's ultra slow=) [15:37] beuno, thanks! Amazing! [15:38] pindonga: I can't login with the shared account [15:38] renat, you probably need to enable ARM specifically, I think it doesn't build for ARM by default [15:38] on the change details for the snap, once you create it [15:39] pindonga: should I try with my personal lp account? [15:39] 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] ogra_, never tried that. [15:40] Thanks for help. Now I have something to experiment with! [15:40] :) [15:42] jdstrand, remember staging myapps uses staging sso [15:42] so separate account [15:42] beuno, never used launchpad before. Going to investigate its capabilities soon, thanks. [15:47] 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] I think I see now why I wasn't able to test on staging :P [15:49] jdstrand, sorry, yes, you need a staging sso account (login.staging.ubuntu.com) [15:49] jdstrand, don't worry, I'll do the testing [15:49] zyga: hey, I have this yaml: http://paste.ubuntu.com/15274178/ and if I try to install then I see: [15:49] no point in you having to struggle with this [15:49] $ sudo snappy install /tmp/snappy-interfaces-security_0.1_all.snap [15:49] Installing /tmp/snappy-interfaces-security_0.1_all.snap [15:49] Waiting for snaps-snappy\x2dinterfaces\x2dsecurity.sideload-LSDpPYfYXdlm.mount to stop. [15:49] /tmp/snappy-interfaces-security_0.1_all.snap failed to install: only a single slot is supported, 2 found [15:49] pindonga: ok thanks. I think it's possible that was the exact outcome we had last time :) [15:50] quite likely :) [15:50] zyga: is there a bug in the yaml or is this just that the interfaces work isn't completed yet? [15:51] I believe I am following the documented spec [15:56] 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] I've attached gdb to the process [15:57] 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] and when I look at /proc//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] /lib/arm-linux-gnueabihf/ld-2.21.so [15:57] I guess this causes the crash [16:01] 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] 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] so it's indeed a dynamic linker issue [16:04] try a wrapper script that sets PATH ? [16:04] hmm, though that wont help i guess [16:17] ok I get it now [16:17] I will wrap all my binaries with something that will call $SNAP/lib/ld-linux-armhf.so.3 [16:18]