| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 07:53 |
|---|---|---|
| om26er | Hi! Where can I download the latest snappy image ? | 07:59 |
| JamesTait | Good morning all; happy Friday, and happy English Toffee Day! 😃 🍬 | 09:25 |
| === joc_ is now known as joc | ||
| asac | adduser/useradd does not work on 15.04 latest? | 12:07 |
| asac | tells me that it cant lock passwd | 12:07 |
| asac | didnt we implement this? | 12:08 |
| asac | ogra_: ? | 12:08 |
| asac | oh i am not on 15.04 to start with :) | 12:08 |
| asac | lol | 12:08 |
| === Chipaca` is now known as Chipaca | ||
| asac | mvo: when will my classic fixes land? | 12:10 |
| asac | really was hoping that i could demo it next week | 12:11 |
| asac | or rather today to prep for that demo | 12:11 |
| mvo | asac: it got merged last night. you are running on an all-snap system? what arch? amd64? rpi2? | 12:13 |
| asac | mvo: pi2 for now | 12:13 |
| asac | otherwise i wouldnt need classic that badly | 12:13 |
| ogra_ | asac, you need the extrausers option | 12:13 |
| asac | and yes i am on all-snap | 12:13 |
| ogra_ | but even with that there is one bug left | 12:13 |
| ogra_ | (see --help, i forgot the exact syntax) | 12:14 |
| mvo | asac: pi2 and all-snaps? | 12:14 |
| asac | ogra_: /usr/bin/chfn: unrecognized option '--extrausers' | 12:14 |
| asac | thats the bug left? | 12:14 |
| ogra_ | yeah | 12:15 |
| asac | mvo: ack!! | 12:15 |
| ogra_ | you can ignore it | 12:15 |
| mvo | asac: ok, I will prepare a new image | 12:15 |
| ogra_ | user addition should still process | 12:15 |
| asac | mvo: will i get it thropugh update? | 12:15 |
| asac | thanks!!! | 12:15 |
| mvo | asac: yes | 12:15 |
| asac | i can also reflash for sure | 12:15 |
| asac | nice | 12:15 |
| mvo | asac: you will need to destroy/create the classic though after you got the new version | 12:15 |
| asac | ogra_: so you say it succeeded? | 12:16 |
| * asac checks | 12:16 | |
| asac | ogra_: urright | 12:16 |
| asac | works :) | 12:16 |
| * asac prefers being asac tghan ubuntu | 12:16 | |
| asac | mvo: sure... already destroyed it hoping that the fix was there | 12:16 |
| ogra_ | asac, http://paste.ubuntu.com/14437429/ thats the script i use for setting up machines | 12:16 |
| ogra_ | (for syntax reference) | 12:17 |
| asac | mvo: find it odd that we have enable-classic vs destroy ... rather think create-classic if its destroz, but afaik it all moves to a snap anyway soon? | 12:17 |
| mvo | asac: yeah, I need to get the details from guastvo about the exact UI but it will change | 12:18 |
| asac | cool | 12:18 |
| asac | mvo: how long you think until the new image is up? | 12:18 |
| mvo | asac: ~1h | 12:18 |
| asac | gogogogo | 12:19 |
| mvo | asac: sorry, there is the potential for it to be (much) faster but right now its not because we reuse a lot of the infrastructure | 12:19 |
| asac | mvo: 1h is better than what i was scared to hear :) | 12:20 |
| asac | so no worries | 12:20 |
| asac | mvo: how would it be much faster by not reusing infra? | 12:20 |
| asac | oh is that about taking lxc images as starting point and patching up? | 12:20 |
| mvo | asac: the process is build snappy git snapshot in the ppa, wait for it to build and publish, trigger image build on cdimage, wait for it to build and get imported, generate OS snap and upload to the store. if there was a way to do the building locally everything would be way quicker | 12:23 |
| mvo | asac: anyway, the ppa build is running, once that is in I will trigger the image build etc | 12:24 |
| ogra_ | mvo, just a reminder poke about the u-d-f merge (it will really not interfere with all-snaps, all code runs after image creation) | 12:26 |
| asac | ogra_: so i unpacked our initrd and noticed that all the bbox binaries were copies rather than symlinks to busybox binary | 12:27 |
| asac | is that because i used wrong cpio flags? or do we really have them all duplicated? | 12:28 |
| asac | mvo: gotcha | 12:29 |
| ogra_ | asac, are you sure they are bb binaries ? ... | 12:44 |
| ogra_ | i think the binaries you see are all native versions | 12:44 |
| asac | ogra_: sure... same size | 12:44 |
| ogra_ | well, then i dont know | 12:45 |
| asac | all same size identical with bb? | 12:45 |
| ogra_ | we only run update-initramfs to create the initrd ... nothing fancy | 12:45 |
| asac | ogra_: http://paste.ubuntu.com/14437554/ | 12:46 |
| ogra_ | yeah, i belive you | 12:46 |
| ogra_ | i'm pretty sure inside the initrd they are links | 12:46 |
| ogra_ | did you unpack in a vfat ? | 12:47 |
| asac | ogra_: no its on my tmpfs on my normal laptop | 12:58 |
| ogra_ | weird | 12:58 |
| asac | ogra_: anyway... dont worry for now... did you ever try to snap up screen? | 12:58 |
| asac | ogra_: i used cpio -i to unpack | 12:58 |
| asac | if that matters | 12:58 |
| ogra_ | heh, no, that never struck me | 12:58 |
| ogra_ | (to snap screen) | 12:58 |
| asac | ok let me try what happens then :) | 12:58 |
| ogra_ | might need some device rules ... | 12:59 |
| ogra_ | (to access ptys and ttys) | 12:59 |
| asac | device rules? | 13:02 |
| asac | you mean grant permissions to non dialout group? | 13:02 |
| ogra_ | well, permissions | 13:02 |
| ogra_ | it will be confined, most of /dev wont be accessible without extra work ... | 13:03 |
| ogra_ | (hw-assign, capabilities etc) | 13:04 |
| asac | sure | 13:04 |
| kyrofa | Good morning | 13:05 |
| ogra_ | anyway ... | 13:05 |
| * ogra_ goes back to do vacation stuff | 13:05 | |
| asac | oh darn :( ... of course i ahve to wait for classic | 13:06 |
| * asac sets countdown and goes for basic food | 13:06 | |
| ogra_ | heh | 13:06 |
| kyrofa | sergiusens, good progress on the yaml changes. I do have a few questions though | 13:25 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| sergiusens | kyrofa, we can discuss them in 15 minutes live if you wnt ;-) | 14:14 |
| kyrofa | sergiusens, sounds good to me | 14:14 |
| kyrofa | sergiusens, worst case, I forgot-- we can actually host our own rosdep yamls in a github fork | 14:56 |
| sergiusens | kyrofa, sounds good to | 14:56 |
| kyrofa | sergiusens, because it looks like the cache is pickled :( | 14:57 |
| sergiusens | kyrofa, better if it is in the plugin itself though | 14:57 |
| sergiusens | ah | 14:57 |
| sergiusens | darn | 14:57 |
| kyrofa | sergiusens, agreed, we'd need to keep it up to date which isn't ideal | 14:57 |
| sergiusens | kyrofa, how about patching rosdep itself? | 14:57 |
| kyrofa | sergiusens, you mean officially, or in the plugin? | 14:58 |
| sergiusens | kyrofa, in the plugin; not sure about officially | 14:59 |
| kyrofa | sergiusens, are we fighting this too much? Should the plugin just support different sources for ros releases and compare them against the ubuntu release and error out if it's not supported? | 14:59 |
| sergiusens | kyrofa, maybe so | 15:00 |
| kyrofa | sergiusens, I mean, it's not ideal, but it's how they've chosen to support ubuntu | 15:00 |
| sergiusens | kyrofa, but jade only goes all the way to vivid :-P | 15:00 |
| kyrofa | sergiusens, gahh | 15:00 |
| * rsalveti kicks asac :P | 15:15 | |
| asac | rsalveti: what did i do :) | 15:16 |
| kyrofa | sergiusens, alright, I figured out a way around this, but there's sort of a greater limitation I'd like to discuss. Right now the catkin plugin has the trusty .deb repos hard-coded, as you know | 15:16 |
| rsalveti | asac: are you playing with the db410c board/ | 15:16 |
| kyrofa | sergiusens, which means any rosdistro not in there will error out | 15:16 |
| asac | rsalveti: not personally, but others do :) | 15:16 |
| asac | i didnt receive one yet :) | 15:17 |
| rsalveti | alright :-) | 15:17 |
| asac | ricmm and lool etc. | 15:17 |
| asac | ogra as well | 15:17 |
| kyrofa | sergiusens, fortunately, rosdep has a command line parameter for what version of ubuntu to use to resolve dependencies | 15:17 |
| rsalveti | great, want to make sure you guys are using the stuff we are producing (or getting the patches from it at least) | 15:17 |
| kyrofa | sergiusens, so for now I can just say "use trusty" even if they're on vivid or xenial | 15:17 |
| rsalveti | asac: how is the kid going? listening metallica already? | 15:18 |
| kyrofa | sergiusens, I'll test that out-- perhaps that's enough for 1.0 to be releasable | 15:18 |
| kyrofa | We can revisit the repos later | 15:18 |
| ogra_ | rsalveti, i'm on vacation, i did work out a proper kernel config for our tree before my holidays, ppisati is preparing a package i can use after i return then .. i think we're fine on track | 15:18 |
| rsalveti | ogra_: cool, then what are you doing online? :-) | 15:19 |
| ogra_ | stuff :) | 15:19 |
| rsalveti | :P | 15:19 |
| asac | rsalveti: no, i moved to mozart instaed :P | 15:20 |
| kyrofa | sergiusens, since both jade and indigo are supported in trusty, and pretty much everyone is using one of those | 15:20 |
| asac | j.k. | 15:20 |
| rsalveti | :P | 15:21 |
| sergiusens | kyrofa, that's fine for 1.x, not so for 2.x | 15:21 |
| kyrofa | sergiusens, how come? | 15:22 |
| kyrofa | sergiusens, just to support newer releases, you mean? | 15:22 |
| sergiusens | kyrofa, we said snapcraft 2.x would only work on xenial; or better said, starting this new iteration; build on target is the way to go; we can discuss in a bit if you want; I'm in no call no so now is also good | 15:23 |
| kyrofa | sergiusens, I'm not sure this affects that. Yeah, let's discuss (we can wait a bit though if you like) | 15:26 |
| elopio | mvo: for some failover tests we need to break the kernel, and for some we need to break the os. Is there a way to query for the name of a type of snap? | 15:37 |
| mvo | elopio: from the commandline? I think we don't have this right now, so we need to add it | 15:38 |
| elopio | mvo: do you want me to report a bug? | 15:40 |
| mvo | elopio: yes please. in the meantime you can find the name via "grub-editenv list|grep ^snappy_os=" but its not a great workaround | 15:41 |
| elopio | okay, I'll make a note of that too. | 15:42 |
| elopio | mvo: fgimenez: so the thing here is to have a break in the fake update. Prepare the update, break the app, and then do the update. | 15:43 |
| elopio | fgimenez: and we'll have to change all the logic about current and other partition on the failover tests. Basically, rewrite them :) But it seems they will be a lot simpler. | 15:44 |
| fgimenez | elopio, that sounds good :) | 15:44 |
| mvo | elopio: yeah, with the new "make-fake-update" code we "just" need to inject our breaking in there | 15:44 |
| mvo | elopio: if you want I can create a skeleton with what I have in mind (if what I said was unclear or anything) | 15:45 |
| elopio | mvo: maybe. I was thinking of just calling the steps of the good fake update one by one, and add a call to the break method in the middle. | 15:46 |
| elopio | mvo: it sounds you have something fancier in mind. | 15:46 |
| mvo | elopio: just a callback with custom injections when building the new snap, but either way is fine, if you have a plan just go ahead, I'm in the middle of something else right now :/ | 15:47 |
| elopio | mvo: okay, I was thinking of overwriting methods, like the current tests. But a callback sounds good, I can try. First I'll try something dirty just to see if I can break the reboot. | 15:48 |
| mvo | elopio: cool, thanks a lot for working on this, its very exciting! | 15:51 |
| mvo | elopio: keep me updated | 15:51 |
| elopio | it is indeed. Makes testing a lot easier. | 15:51 |
| mvo | its also much cleaner | 15:51 |
| * mvo really is excited | 15:51 | |
| elopio | mvo: https://bugs.launchpad.net/snappy/+bug/1532245 for next week :D | 15:57 |
| ubottu | Launchpad bug 1532245 in Snappy "there is no way to tell which snaps are os, kernel and gadget" [Undecided,New] | 15:57 |
| sergiusens | kyrofa, lets have a call now? | 16:02 |
| kyrofa | sergiusens, alright sounds good | 16:05 |
| kyrofa | sergiusens, I'm in the standup url | 16:08 |
| sergiusens | kyrofa, joining then | 16:08 |
| kyrofa | sergiusens, note that those hard coded sources will only work until the next version of ROS is released. Then we'll have to be a little smarter about it | 16:14 |
| kyrofa | sergiusens, but that shouldn't be too bad | 16:14 |
| sergiusens | kyrofa, that is fine; when we get close to 16.04 releasing we can start working on a plan to support whatever ros LTS release will come out | 16:21 |
| kyrofa | sergiusens, perfect | 16:22 |
| sergiusens | kyrofa, in theory there should be a K release, right? | 16:26 |
| kyrofa | sergiusens, indeed | 16:26 |
| sergiusens | kyrofa, documentation suffers on the ros site as everywhere :-P | 16:26 |
| kyrofa | sergiusens, haha, yes it does | 16:27 |
| sergiusens | kyrofa, ROS Kinetic Kame | 16:27 |
| sergiusens | 16:27 | |
| sergiusens | May, 2016 | 16:27 |
| sergiusens | 16:27 | |
| sergiusens | TDB | 16:27 |
| sergiusens | 16:27 | |
| sergiusens | TDB | 16:27 |
| sergiusens | 16:27 | |
| sergiusens | May, 2021 | 16:27 |
| sergiusens | oops | 16:27 |
| sergiusens | supposed to be a one liner :-) | 16:27 |
| sergiusens | http://wiki.ros.org/Distributions | 16:27 |
| kyrofa | sergiusens, what on earth is a Kame | 16:28 |
| sergiusens | A kame is a geomorphological feature, an irregularly shaped hill or mound composed of sand, gravel and till that accumulates in a depression on a retreating glacier, and is then deposited on the land surface with further melting of the glacier. | 16:28 |
| sergiusens | google images shows anything but that | 16:29 |
| sergiusens | must be a popular "star" name | 16:29 |
| genii | So a pile of detritus | 16:30 |
| kyrofa | sergiusens, https://github.com/ubuntu-core/snapcraft/pull/212 . Should be a painless review | 16:38 |
| * asac wonders if there is a way to convince screen to not write to /var/run/ without patching | 16:59 | |
| asac | ok SCREENDIR looks like a candidate | 17:01 |
| asac | jdstrand: debug.security saying "* add 'mknod' to 'syscalls' in security-override | 17:04 |
| asac | " | 17:04 |
| asac | is good guidance? | 17:04 |
| ogra_ | asac, btw, ii thijnk i'll give up on my postfix/dovecot snap ... i really dont want to maintain users in an SQL db or some such and want to be able to use procmail ... getting that to work in a snap will be super tricky | 17:07 |
| sergiusens | kyrofa, I need to drop for a bit, baby issues | 17:14 |
| kyrofa | sergiusens, hey I have those too, no worries :) | 17:16 |
| jdstrand | asac: it may also say to adjust the program to not use mknod | 17:18 |
| jdstrand | asac: on a 16.04 system to get the snap running, you can do: | 17:18 |
| jdstrand | service: | 17:18 |
| jdstrand | - name: foo | 17:18 |
| jdstrand | caps: network-client | 17:19 |
| jdstrand | security-override: | 17:19 |
| jdstrand | syscalls: [ mknod ] | 17:19 |
| jdstrand | lots of caveats: you will likely have other things to add (eg, write-path), this would be blocked by the store, security-override is going away | 17:19 |
| jdstrand | (in favor of new capabilities system) | 17:20 |
| jdstrand | I advise adjusting the program to not use mknod | 17:20 |
| kyrofa | elopio, any chance you have a minute to review https://github.com/ubuntu-core/snapcraft/pull/212? | 17:24 |
| asac | jdstrand: ok lety me try that | 17:24 |
| sergiusens | kyrofa, I reviewed it, just wanted to test it on xenial :-) | 17:24 |
| elopio | kyrofa: oh, even better. I'll merge my xenial branch to confirm it now passes. | 17:25 |
| elopio | give me a second... | 17:25 |
| kyrofa | sergiusens, oh, okay! | 17:25 |
| asac | jdstrand: and click-review tools? | 17:25 |
| asac | is that supposed to work with squash? | 17:25 |
| sergiusens | elopio, that seems to be the way ;-) | 17:25 |
| sergiusens | knowing that it runs though is a big bonus too ;-) | 17:25 |
| jdstrand | asac: if you have the latest checkout, yes, it should work | 17:26 |
| jdstrand | asac: I don't think that the tools ppa has it though, since all snaps hasn't landed yet | 17:27 |
| asac | jdstrand: http://paste.ubuntu.com/14439310/ | 17:27 |
| jdstrand | asac: snapcraft may not understand the 16.04 security-override. sergiusens, can you comment? | 17:28 |
| asac | ok seems not :/ | 17:28 |
| asac | jdstrand: is apparmor and seccomp still an option or not valid anymore on 16.04? | 17:30 |
| kyrofa | jdstrand, anything 16.04 specific hasn't been released yet | 17:30 |
| kyrofa | sergiusens, elopio also look over https://github.com/ubuntu-core/snapcraft/pull/211 when you have a chance. We've started getting PRs with no associated bugs | 17:32 |
| asac | jdstrand: i am running click-review from lp: trunk | 17:34 |
| asac | tells me its not a debian package | 17:34 |
| asac | jdstrand: http://paste.ubuntu.com/14439370/ | 17:35 |
| jdstrand | asac: so, security-override changed in 16.04 to be usable | 17:36 |
| jdstrand | this was before Brazil | 17:36 |
| jdstrand | on 15.04 you do: | 17:36 |
| jdstrand | services: | 17:36 |
| jdstrand | - name: foo | 17:36 |
| jdstrand | security-override: | 17:36 |
| jdstrand | apparmor: path/to/foo.apparmor | 17:36 |
| jdstrand | seccomp: path/to/foo.filter | 17:37 |
| jdstrand | and path/to/foo.apparmor was a click security manifest (json) and path/to/foo.filter was a list of syscalls | 17:37 |
| jdstrand | it was crap and bad and removed | 17:37 |
| jdstrand | so on 16.04 there is: | 17:37 |
| jdstrand | services: | 17:37 |
| jdstrand | - name: foo | 17:37 |
| jdstrand | security-override: | 17:38 |
| jdstrand | syscalls: [ a, b ] | 17:38 |
| jdstrand | read-paths: [ /c, /d ] | 17:38 |
| jdstrand | ... | 17:38 |
| jdstrand | snapcraft isn't accounting for the yaml change in 16.04 | 17:38 |
| jdstrand | but, in Brazil, security-override will be removed (probably why snapcraft isn't updated) | 17:39 |
| jdstrand | asac: so in light of that, remove security-override from your yaml. if you are just debugging, add mknod to /var/lib/snappy/seccomp/profiles/... for your app | 17:40 |
| jdstrand | asac: if this is for the store, do that ^ until you are happy, then use 'security-policy' | 17:41 |
| jdstrand | we are at a weird point for developing on snappy-- things are changing a lot and it is a bit bumpy | 17:41 |
| sergiusens | jdstrand, asac reason was that snapcraft used work across all versions, now it is bound to release; I haven't made that change yet | 17:49 |
| elopio | I'm running more than 10 sets of tests at the same time :D | 17:56 |
| elopio | travis, vm, real machine, I'm going to explode. | 17:56 |
| kyrofa | elopio, *achievement unlocked* | 17:56 |
| kyrofa | I can hear you now "And they're ALL failing! What are the odds?" | 17:57 |
| elopio | kyrofa: I can build and install the snap. But when I run the binaries I get python not found, rosrun not found, cat not found. | 17:57 |
| elopio | that's like: half of the test passed :) | 17:58 |
| kyrofa | elopio, argh. Which version of ubuntu core are you running? | 17:58 |
| elopio | kyrofa: rolling edge #310, kvm. | 17:58 |
| kyrofa | elopio, investigating now | 18:04 |
| elopio | goal for the next week, get the examples install and execution suite automated. | 18:05 |
| kyrofa | elopio, yeah something must have changed pretty significantly from vivid (which is what I'm running). I'll get a rolling VM up | 18:11 |
| kyrofa | elopio, any chance you know why u-d-f is giving me "generic-amd64 failed to install: snappy package not found" when I try to create a rolling image? | 18:16 |
| kyrofa | (on xenial) | 18:17 |
| elopio | kyrofa: yes, use --oem generic-amd64/stable | 18:17 |
| === joc is now known as joc|away | ||
| sergiusens | kyrofa, elopio we really want to make sure 15.04 works for 1.x though | 18:18 |
| kyrofa | elopio, hmm... that gives me other errors ("generic-amd64/stable failed to install: exit status 2"). What incantation are you using? | 18:18 |
| kyrofa | sergiusens, 15.04 works fine in my tests | 18:18 |
| elopio | sergiusens: I'm testing that with my left hand :) | 18:18 |
| kyrofa | elopio, hahaha | 18:18 |
| elopio | kyrofa: sudo ubuntu-device-flash core rolling --channel edge --oem generic-amd64/stable --developer-mode -o ubuntu-snappy-rolling-edge-amd64-generic.img | 18:18 |
| kyrofa | elopio, huh, yeah "exit status 2." | 18:19 |
| kyrofa | elopio, maybe I'll try on wily instead | 18:19 |
| elopio | kyrofa: I'm with u-d-f 0.33-0ubuntu2 | 18:20 |
| kyrofa | elopio, same here. What on earth | 18:21 |
| kyrofa | u-d-f needs to depend upon ubuntu-snappy | 18:23 |
| kyrofa | cli | 18:24 |
| kyrofa | elopio, is this really the first snapcraft issue you've hit on rolling? | 18:29 |
| elopio | stgraber: hey look, all green \o/ https://travis-ci.org/ubuntu-core/snapcraft/builds/101115699 | 18:30 |
| elopio | The only thing I didn't like was that I had to chmod 777 the directory I mounted on the container. | 18:30 |
| elopio | I tried chown 100100, but it gave errors when the tests created links, and when touching the coverage file in the base directory. | 18:30 |
| elopio | kyrofa: it's the first I tested this year. | 18:31 |
| kyrofa | elopio, huh, wily gave me the same problems. Wonder if it has something to do with lxc | 18:32 |
| kyrofa | elopio, any chance you can share your image? :P | 18:33 |
| kyrofa | sergiusens, if it's verified that this works for 15.04, is it good for 1.0? | 18:33 |
| stgraber | elopio: to avoid the chmod you can either run a privileged container (pass -c security.privileged=true to launch) or chown or add an acl for uid 101000 (the mapped uid of user ubuntu in the container) | 18:33 |
| elopio | kyrofa: hum, no, that would take like the whole day. Remember that I'm bandwidth handicapped. Do you have access to canonistack? | 18:34 |
| kyrofa | elopio, oh yeah :P | 18:34 |
| kyrofa | elopio, and yes, I do | 18:34 |
| elopio | stgraber: I tried chown. Maybe I'll go the privileged container way. | 18:35 |
| elopio | kyrofa: there is a rolling image of yesterday in there. Do you know how to start it? | 18:36 |
| stgraber | elopio: you could apt-get install acl and do "setfacl -m default:user:101000:rwX -R $(pwd) && setfacl -m user:101000:rwX -R $(pwd)", that should set the posix ACL everywhere where it matters including a default ACL that should automatically be set for any new entry | 18:36 |
| kyrofa | elopio, oh brilliant! Yeah, thanks :) | 18:36 |
| stgraber | elopio: but otherwise, since it's an ephemeral environment and you don't really care about security, security.privileged=true would certainly be the easiest way out of the problem :) | 18:37 |
| elopio | stgraber: okay, so more tries for next week :) | 18:38 |
| elopio | stgraber: look at this one: https://travis-ci.org/ubuntu-core/snapcraft/builds/101121816 | 18:38 |
| elopio | travis is awesome, free machines for everybody. Now we have trusty, vivid and xenial for each suite. | 18:38 |
| stgraber | :) | 18:42 |
| sergiusens | kyrofa, yeah | 18:42 |
| kyrofa | elopio, has your 15.04 test finished? | 18:43 |
| elopio | kyrofa: I'm using trusty to build the examples. The two go ones failed, I'm investigating. And I'm starting a 15.04 snappy to run the ros I've built in there. | 18:45 |
| kyrofa | elopio, and the ros was built from xenial? | 18:48 |
| kyrofa | elopio, or vivid? Something past trusty | 18:49 |
| elopio | kyrofa: the ros built from trusty works on 15.04 | 18:52 |
| elopio | kyrofa: the packages built on xenial can't be installed on 15.04 | 18:52 |
| kyrofa | elopio, alright. I built the ros package on xenial using the 1.x branch, and it installed and ran fine | 18:53 |
| kyrofa | elopio, well, with the bugfix branch actually | 18:53 |
| elopio | ah, using the 1.x branach | 18:53 |
| kyrofa | elopio, right | 18:53 |
| kyrofa | elopio, use my backport branch | 18:53 |
| elopio | ok, now let me refocus. | 18:54 |
| kyrofa | elopio, but yeah, sounds like 1.x has some issues with later versions of snappy, which isn't entirely surprising | 18:54 |
| elopio | I wanted to confirm that 1.x worked on trusty. kyrofa: do you want me to confirm that 1.x ros works on vivid too? | 18:54 |
| kyrofa | elopio, it wouldn't hurt, but we've now confirmed that 1.x works on trusty and xenial, so... | 18:55 |
| kyrofa | (at least as far as ros goes) | 18:55 |
| kyrofa | elopio, so I'm satisfied with that bugfix anyway | 18:56 |
| elopio | for 1.x, if you have already built it and run it, I agree. | 18:56 |
| kyrofa | elopio, alright. Shall I merge it and update the release PR, then? | 18:58 |
| elopio | kyrofa: sure. I'll start firing my vivid vm to see if I find something weird in there. | 18:59 |
| elopio | where did sergiusens go? | 19:00 |
| kyrofa | elopio, just back to general release testing? | 19:00 |
| kyrofa | elopio, not sure. Perhaps more problems with the little one | 19:00 |
| elopio | kyrofa: I'm getting errors in the go examples in trusty. Also travis is failing there: https://travis-ci.org/ubuntu-core/snapcraft/jobs/101121821 | 19:00 |
| elopio | oh wait, wrong link. That's the one your pr fixes. | 19:01 |
| elopio | sergiusens: kyrofa: https://travis-ci.org/ubuntu-core/snapcraft/jobs/101121821 go examples failed to build in trusty. | 19:01 |
| sergiusens | elopio, archive errors it seems | 19:02 |
| sergiusens | elopio, Failed doing pull for godd: W:Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/binary-amd64/Packages Hash Sum mismatch | 19:02 |
| kyrofa | sergiusens, elopio yeah I've noticed those a few times too-- rerun | 19:02 |
| elopio | ah, yeah, I'll retry for that one. But also: | 19:02 |
| elopio | http://pastebin.ubuntu.com/14440028/ | 19:02 |
| elopio | this is the one I get with godd on my vm: | 19:03 |
| elopio | http://pastebin.ubuntu.com/14440034/ | 19:03 |
| sergiusens | elopio, oh, right, godd might not be buildable on trusty anymore; or did we not talk about this at some point already? I forget | 19:04 |
| elopio | well, it seemed to have been building before. My guess is that something installed in the travis trusty machine made it work. | 19:05 |
| elopio | now that we are in a lxc, we need to figure out what that was. | 19:05 |
| sergiusens | elopio, no worries, I have my trusty lxc instance and it worked last I checked | 19:06 |
| elopio | yes, it passed on kyle's branch for the changelog. | 19:06 |
| jerryG | kgunn: are u there? | 19:10 |
| kyrofa | sergiusens elopio, alright the release branch has been updated | 19:11 |
| elopio | ok, the only problem I can find on trusty is that with the go examples, which if is a bug it's not new. | 19:17 |
| elopio | kyrofa: sergiusens: if you want, you can wait for me to do some validation on vivid. Or you can release now. | 19:17 |
| jerryG | chipaca: u there? | 19:18 |
| elopio | kyrofa was trying stuff in vivid, so I doubt I will find something here. | 19:18 |
| kyrofa | jerryG, capital-C: Chipaca | 19:18 |
| jerryG | kyrofa: k thx | 19:18 |
| jerryG | Chipaca: u there? | 19:18 |
| kyrofa | sergiusens, your call | 19:19 |
| sergiusens | elopio, kyrofa I have no issues with waiting and not having to look back ;-) | 19:19 |
| elopio | sergiusens: ok. Can we release on monday then so I can have a relaxed lunch? or do you want to release today? | 19:20 |
| sergiusens | kyrofa, ? are you in a rush? | 19:21 |
| kyrofa | sergiusens, elopio fine by me | 19:21 |
| elopio | monday it is then :D Actually we should make a rule of never ever releasing on friday. | 19:21 |
| sergiusens | elopio, I love releasing on Friday | 19:22 |
| sergiusens | check the history ;-) | 19:22 |
| kyrofa | Hahaha, elopio you don't want to come back a million bug reports on Monday? | 19:22 |
| elopio | I would prefer the million bugs to be on tuesday ;) | 19:24 |
| kyrofa | :F | 19:24 |
| kyrofa | Err, :D. Wow | 19:25 |
| kyrofa | Beaver smiley? | 19:25 |
| sergiusens | lol | 19:26 |
| Chipaca | kyrofa: jerryG: OHI | 19:26 |
| jerryG | Chipaca: hey! | 19:27 |
| Chipaca | kyrofa: i'm case-insensitive, fwiw, but you guys always seem to call me post-EOD =) | 19:27 |
| elopio | post-EOW :) | 19:28 |
| jerryG | Chipaca: im trying to get mir clocks example running on snappy stable. But I'm getting a "connection to mir failed... check if MIR is running" error | 19:28 |
| kyrofa | Chipaca, heh. I'm not calling you though! | 19:28 |
| Chipaca | jerryG: is mir running? | 19:29 |
| kyrofa | Chipaca, if you're EOD you should ignore us! | 19:29 |
| jerryG | Chipaca: yeah. I'm using mir.mvp-demo though. But I get the cursor on black background. | 19:29 |
| Chipaca | jerryG: and where does that mir have its socket? | 19:30 |
| jerryG | Chipaca: how to check? ps-ax? | 19:30 |
| Chipaca | jerryG: or find perhaps | 19:30 |
| Chipaca | kgunn: wasn't there a newer mir than mir.mvp-demo? | 19:31 |
| jerryG | Chipaca: mir_demo_server --window-manager fullscreen --file /run/mir_socket --vt 1 | 19:32 |
| Chipaca | jerryG: k | 19:32 |
| Chipaca | jerryG: and is your client using that same socket, and does it have access to it? | 19:32 |
| jerryG | Chipaca: how to check?... my "clocks" shell script executes /apps/mir/current/bin/mir-run | 19:35 |
| jerryG | Chipaca: and I have "framwork" set to mir in the yaml | 19:35 |
| Chipaca | jerryG: have you checked syslog for apparmor denials? | 19:38 |
| kyrofa | jerryG, or run snappy-debug | 19:39 |
| jerryG | Chipaca: snappy service logs? | 19:41 |
| jerryG | kyrofa: how do i use snappy-debug? | 19:43 |
| kyrofa | jerryG, install it: sudo snappy install snappy-debug, and run it: sudo snappy-debug.security scanlog | 19:44 |
| kyrofa | jerryG, it parses syslog for apparmor denials and gives you some helpful advice | 19:44 |
| jerryG | kyrofa: kk thx. i see all the denials | 19:46 |
| jerryG | Chipaca: kyrofa: I fixed apparmor denials. But still getting same "connection to mir failed" output from clocks example. | 20:02 |
| Chipaca | jerryG: what socket is it trying to connect to? | 20:49 |
| mvo | jdstrand: I have a branch that renames /apps to /snaps - is there apparmor work needed for this? pardon my ignorance on this, I did change some code in security.go for this new location but I'm not sure if there is more to do for that | 20:50 |
| sergiusens | Chipaca, just noticed that my PR for licenses was wrong, it was supposed to be meta/license.txt, not meta/hooks/license.txt ;-) | 20:51 |
| mvo | jdstrand: https://github.com/ubuntu-core/snappy/pull/308 fyi, but its pretty borning | 20:51 |
| sergiusens | jdstrand, I solve the fact that we can't use envvars in command (former start) within snapcraft itself, so if snapcraft is used, it is allowed (given our wrapping) ;-) | 20:52 |
| jdstrand | mvo: with click-apparmor gone, the only thing should be your change to security.go. if you can install hello-world.mvo and run hello-world_env, it should be fine | 20:54 |
| jdstrand | mvo: (ie, that is why we use apparmor variable for INSTALL_DIR instead of hardcoding it in policy) | 20:55 |
| mvo | jdstrand: cool, thanks | 20:56 |
| jdstrand | np | 20:56 |
| sergiusens | elopio, is there a way to get a better pep8 on trusty? | 21:06 |
| sergiusens | elopio, these drive me nuts :P https://travis-ci.org/ubuntu-core/snapcraft/jobs/101158429 | 21:07 |
| mvo | ogra_: arm64 build works again | 21:19 |
| sergiusens | kyrofa, elopio if nothing to do you guys have, maybe check this you might https://github.com/ubuntu-core/snapcraft/pull/215 | 21:29 |
| sergiusens | Chipaca, zyga mvo as well ^ | 21:29 |
| sergiusens | that's snap.yaml in full except capabilities with full backwards support for package.yaml and readme.md | 21:30 |
| sergiusens | just needs documentation updates | 21:30 |
| jerryG | Chipaca: how to check? | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!