| === FourDollars_ is now known as FourDollars | ||
| === sarnold_ is now known as sarnold | ||
| === Tristit1a is now known as Tristitia | ||
| 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:28 |
| dholbach | good morning | 07:54 |
| didrocks | good morning dholbach | 08:08 |
| dholbach | salut didrocks | 08:08 |
| zyga | good morning | 08:30 |
| noizer | good morning | 08:38 |
| 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:42 |
| didrocks | (I did downgrade snappy for now) | 08:44 |
| 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:46 |
| 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 | 08:47 |
| === popey_ is now known as popey | ||
| 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:02 |
| zyga | noizer: which version of snappy did you use? | 09:04 |
| zyga | noizer: can you run "snap interfaces" | 09:04 |
| noizer | 16.04 | 09:05 |
| noizer | zyga | 09:05 |
| zyga | noizer: and FYI: https://github.com/ubuntu-core/snappy/pull/559 | 09:05 |
| zyga | mvo: thank you! | 09:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| noizer | zyga: I will build a new image | 09:11 |
| noizer | zyga when was the last update | 09:12 |
| noizer | zyga because I build it before with you previous monday (22/02/16) | 09:12 |
| 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:14 |
| noizer | zyga: oooh ok i will have a look at it how i need to do it | 09:18 |
| 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:27 |
| 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:28 |
| 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:29 |
| * zyga needs a bigger switch | 09:34 | |
| mvo | dpm: a new os snap is now in rolling/edge so you may need to update your example app | 09:35 |
| dpm | mvo, thanks! so I need to 'snappy update ubuntu-core' as well I guess? | 09:37 |
| mvo | dpm: yeah, its in edge right now, I promote to stable in a bit | 09:41 |
| dpm | ok, I just wanted to see if I did it right, as I caouldn't see any update yet | 09:42 |
| noizer | Zyga building !!!! niceee | 09:43 |
| zyga | noizer: cool, | 09:44 |
| zyga | noizer: patches are welcome, if you can improve the devtools or documentation around them | 09:44 |
| noizer | zyga: I will think about it and let you know | 09:45 |
| dpm | mvo, looks about right? http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/revision/282 | 09:49 |
| noizer | zyga: strange its just like you script is blocking | 09:51 |
| mvo | dpm: yes | 09:52 |
| dpm | great, thanks | 09:53 |
| 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 | 09:57 |
| zyga | mvo: follow up with more tests https://github.com/ubuntu-core/snappy/pull/571/files | 10:01 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| noizer | ubuntu | 10:04 |
| noizer | zyga here its blocking :s http://pastebin.com/aBafF3RW | 10:06 |
| 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:11 |
| 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:12 |
| 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:13 |
| noizer | oooh ok :D | 10:14 |
| noizer | And now i can make some REST Calls to the new API | 10:16 |
| zyga | noizer: great! | 10:18 |
| noizer | zyga I think so | 10:18 |
| noizer | zyga im trying right know | 10:18 |
| noizer | zyga unix connect failed: Permission denied | 10:20 |
| noizer | nc: unix connect failed: Permission denied | 10:21 |
| noizer | wasn't complete | 10:21 |
| noizer | zyga: I can't make any calls to the socket right now | 10:28 |
| 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:30 |
| noizer | I think its works now | 10:35 |
| noizer | zyga | 10:35 |
| zyga | mvo: FYI https://github.com/ubuntu-core/snappy/pull/548#discussion-diff-54862218 | 10:38 |
| zyga | mvo: otherwise yes, LGTM | 10:38 |
| === lool- is now known as lool | ||
| 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:06 |
| 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:10 |
| 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:47 |
| ogra_ | Mir will work at some point but we are still a bit away from graphical drivers and such on the dragonboard specifically | 11:48 |
| zzarr | would Mir be sw accelerated, or not work at all? | 11:49 |
| 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:50 |
| zzarr | thanks ogra_, I'll begin with a Linaro image | 11:54 |
| kyrofa | Good morning | 12:24 |
| didrocks | ogra_: hey, have you seen my askubuntu link? | 12:32 |
| didrocks | hey kyrofa! | 12:32 |
| kyrofa | Hey didrocks! | 12:32 |
| olli_ | m | 12:32 |
| === olli_ is now known as olli | ||
| ogra_ | didrocks, answered now | 12:37 |
| didrocks | ogra_: thx! | 12:43 |
| 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:44 |
| ogra_ | zyga, s/inserts them into the kernel/rebuilds the cache/ | 12:45 |
| ogra_ | it is like on the phone :) | 12:46 |
| zyga | ogra_: hmm, not sure what "rebuilds the cache" means | 12:47 |
| 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:48 |
| kyrofa | enoch85, ping | 12:51 |
| ogra_ | zyga, qwll, i always thought it reads the binary profile from disk ... but yeah, thats what i mean | 12:53 |
| ogra_ | *well | 12:53 |
| zyga | ogra_: so what does that? | 12:54 |
| zyga | ogra_: does snappy do that somewhere? | 12:54 |
| 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:55 |
| ogra_ | but i would imagine largely the same ... | 12:56 |
| kyrofa | zyga, I suspect that ubuntu core launcher does it, actually | 13:04 |
| kyrofa | zyga, not 100% sure about that | 13:05 |
| 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:08 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| kyrofa | zyga, ah, you're right-- the man page says profiles need to already be loaded with apparmor_parser | 13:22 |
| 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:24 |
| 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:30 |
| kyrofa | zyga, etc/init/apparmor.conf in 15.04 | 13:32 |
| noizer | zyga for me thats good | 13:32 |
| noizer | Just know how to start best on it | 13:33 |
| zyga | noizer: noizer cool | 13:34 |
| zyga | kyrofa: thanks! | 13:34 |
| zyga | I'm not sure that's doing anything in 16.04, I need to see this in more detail | 13:35 |
| kyrofa | zyga, yeah, same file on 16.04 | 13:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| zyga | noizer: which APIs are you going to touch/need first? | 13:41 |
| noizer | zyga start and stop services | 13:42 |
| noizer | so the REST api to maybe the python API | 13:43 |
| 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:45 |
| 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:47 |
| 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:48 |
| mvo | zyga: something like snappy-runhooks | 13:49 |
| mvo | zyga: I think it is ordered early | 13:49 |
| 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:50 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| === jdstrand_ is now known as jdstrand | ||
| * 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:03 |
| * 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:04 |
| kyrofa | zyga, regarding sources, you mean the rpi gadget? No, where is that? | 14:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:11 |
| kyrofa | ogra_, well... log that bug! | 14:12 |
| kyrofa | :P | 14:12 |
| zyga | jdstrand: thanks | 14:17 |
| 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:18 |
| beuno_ | zyga, sounds like enough of the syntax has landed in snap.yaml that we could kick off store integration? | 14:19 |
| === beuno_ is now known as beuni | ||
| === beuni is now known as beuno | ||
| ogra_ | identity crisis ? | 14:20 |
| beuno | yes, going from sprint to sprint messes you up :) | 14:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:29 |
| 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:30 |
| jdstrand | ok | 14:31 |
| === rcj` is now known as rcj | ||
| kyrofa | ogra_, do you know if we have working kernel snaps as well? | 15:02 |
| ogra_ | kyrofa, all in the store | 15:11 |
| kyrofa | ogra_, awesome, any chance you know where the sources are? | 15:12 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 15:12 |
| ogra_ | dragonboard is still a local build from the deb in the archive | 15:13 |
| ogra_ | all others come from these device tarballs | 15:13 |
| kyrofa | ogra_, I mean the thing containing the snap.yaml. These are all built, right? | 15:18 |
| ogra_ | manually | 15:18 |
| 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:19 |
| kyrofa | ogra_, ah, thanks! | 15:20 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| jdstrand | pindonga: when do we expect that to happen? | 15:30 |
| pindonga | jdstrand, early next week | 15:31 |
| pindonga | I'll see if I can do that today | 15:31 |
| pindonga | but no promises | 15:31 |
| jdstrand | ok, thanks | 15:32 |
| renat | Hi all! It's Renat from Screenly=) | 15:32 |
| 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:33 |
| renat | I have questions, as usual=) | 15:34 |
| 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:35 | |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| renat | ogra_, never tried that. | 15:40 |
| renat | Thanks for help. Now I have something to experiment with! | 15:40 |
| ogra_ | :) | 15:40 |
| 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:42 |
| 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:47 |
| 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:49 |
| 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:50 |
| jdstrand | I believe I am following the documented spec | 15:51 |
| 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:56 |
| 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 | 15:57 |
| 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:01 |
| 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:03 |
| ogra_ | try a wrapper script that sets PATH ? | 16:04 |
| ogra_ | hmm, though that wont help i guess | 16:04 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| ogra_ | (my head is also full of wrappers it seems) | 16:22 |
| ogra_ | *dev | 16:22 |
| ogra_ | tedg, ^^ | 16:22 |
| tedg | ogra_: ? | 16:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| ogra_ | and it would be nice if we could just tell the launcher to do that for us | 16:28 |
| 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:29 |
| ogra_ | well, it could be some option ... or config | 16:30 |
| ogra_ | you dont want to do it all the time | 16:31 |
| ogra_ | (most people will likely just use the system linker) | 16:31 |
| ogra_ | (and rely on LD_LIBRABRY_PATH for their own libs) | 16:32 |
| kyrofa | wiggleworm, you still around? | 17:01 |
| ysionneau | well, if you have a path that corresponds to the dynamic linker in your $SNAP, you most likely want to use it | 17:12 |
| jdstrand | niemeyer: you seem to have disconeected | 17:25 |
| kyrofa | ogra_, so if cdimage is used to create the kernel snaps, where might I find the kernel configs that we use? | 17:44 |
| ogra_ | either in the source package or in the git trees on kernel.ubuntu.com (ask the kernel team for specific branch urls) | 17:46 |
| kyrofa | ogra_, excellent thank you | 17:48 |
| sergiusens | ogra_, do you know if your initrd made it into an OS snap? | 18:19 |
| 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:20 |
| sergiusens | yeah | 18:22 |
| 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:23 |
| sergiusens | ogra_, he'll be pushing one soon | 18:35 |
| ogra_ | k | 18:35 |
| sergiusens | ogra_, where is this generic initrd installed btw? | 18:35 |
| 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:36 |
| 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:41 |
| sergiusens | jdstrand, hey, I never got your ack/nack on https://github.com/ubuntu-core/snapcraft/pull/360 | 18:49 |
| 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. | 18:58 |
| jdstrand | pindonga: it is | 19:10 |
| jdstrand | sergiusens: I'm going to test that snap, have a quick bite to eat, then review your PR | 19:11 |
| 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:12 |
| 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:14 |
| jdstrand | pindonga: what interesting though is I don't see the review tools commit number in the passes output any more | 19:15 |
| 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:16 |
| jdstrand | pindonga: 601 click-reviewers-tools version | 19:17 |
| pindonga | yep | 19:17 |
| 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:18 |
| 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:26 |
| Mikaela | Probably because docker has mostly everything available while snappy doesn't have so much | 19:27 |
| 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:30 |
| sergiusens | the-solipsist, there's a nice email from Mark in the mailing lists explaining when to use one or the other | 19:36 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| * ogra_ goes afk ... | 19:45 | |
| 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:48 |
| jdstrand | sergiusens: done | 20:57 |
| sergiusens | jdstrand, thanks | 21:05 |
| sergiusens | jdstrand, hm, should I add umask != 0 as well? | 21:07 |
| jdstrand | sergiusens: you could. that is actually something I would expect the review tools to catch (ie, 0777 file perms) | 21:13 |
| 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:14 |
| sergiusens | jdstrand, ok, seems good | 21:15 |
| sergiusens | kyrofa, mind to start reviewing https://github.com/ubuntu-core/snapcraft/compare/master...sergiusens:feature/1552168/kernel-plugin#diff-a6d756e312a41b33e3a9de439c8527a8R9 ? | 21:17 |
| sergiusens | kyrofa, the busybox example already works | 21:20 |
| sergiusens | let me just create a PR | 21:20 |
| popey | ogra_: fyi, sudo iwconfig wlan0 power off - needed on pi 3, it power saves wifi which means it's unusable | 23:43 |
| zyga | jdstrand: thanks for the meeeting notes | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!