=== shuduo-afk is now known as shuduo === chihchun_afk is now known as chihchun [07:49] good morning [08:26] Chipaca, mvo: if I build the snapd binary, is there an easy way of getting it running on a snappy VM? [08:29] stevebiscuit: yes, for some definition of "easy". Chipaca has the details, it should be a matter of just building and scp to the snappy system $HOME and starting it here. However I have not done this yet, I can give it a quick try. you could even do the development on snappy itself from the classic environment. let me quickly try if my suggestion actually works [08:35] mvo: I've tried killing off the running snapd and then running the scp'd one but it gives me "error: daemon does not handle 0 listeners right now, just one" which is do with systemd from my reading of the code [08:35] stevebiscuit: ok, this is actually slightly more complicated, I get the same. here is what you need to do: [08:36] stevebiscuit: sudo systemctl stop ubuntu-snappy.snapd.service ubuntu-snappy.snapd.socket [08:36] stevebiscuit: sudo /lib/systemd/systemd-activate -l /run/snapd.socket ./snapd [08:41] mvo: that works a treat, cheers! [08:46] stevebiscuit: great! https://github.com/ubuntu-core/snappy/pull/291 so that this is easier to find in the future [09:01] Chipaca, ping [09:58] sergiusens: is it right that its odd that if i have a typo in snapcraft python code like referencing an non existing var [09:58] that it just bails with the error but no indication of line number etc.? [09:59] or is that normal for python? [09:59] * asac feels like being in debugging stoneage when hacking on snapcraft etc. [10:00] asac, it is not normal, just user friendly, for devel I recommend you change one thing [10:01] asac, either remove try/except here or change sys.exit to raise e [10:02] asac, I'll add an envvar there so you can devel easier [10:25] Chipaca, hey, mind doing a review? [10:26] sergiusens: REVIEWS FOR THE REVIEW GOD [10:26] sergiusens: but she's busy, so I guess I'll do them instead [10:26] Chipaca, https://github.com/ubuntu-core/snapcraft/pull/201 [10:27] Chipaca, just the semantics for license keywords if you don't want to check code [10:28] sergiusens: reviewed [10:29] sergiusens: you dun good [10:31] sergiusens: user friendly? [10:36] asac, end user; someone not introducing new code but using the tool [10:36] Chipaca, thanks [10:40] sergiusens: ok, just couldnt see how not printing line number faults on error could help someone [10:40] i would think best case someone using tool wont see errors [10:40] but if he does he probably would want to have something useful to bug report [10:41] but maybe i am missing some error cases where this would help === chihchun is now known as chihchun_afk [10:52] sergiusens: anyway, env paired with entry in hacking.md etc. would be good (not that i read hacking.md, but at least i would have done that next i think) [11:01] sergiusens: thoughts on https://gist.github.com/asac/d66ecdbb286e4a60269e [11:01] thanks [11:01] (note its not complete= [11:02] not sure about run_raw... but i couldnt figure better way [11:10] mvo: are there changes to snappy config protocol coming on master branch or do we stick to current approach for now? [11:39] when I build a snap with snapcraft, not every file from the stage is copied to the snap folder. What are the filter criterias? === chihchun_afk is now known as chihchun [11:58] kickinz1: so downloading i386 vs. amd64 docker-latest from https://docs.docker.com/engine/installation/binaries/ ... i see that the i386 is 7.X M and the amd64 is like 30M+ ? [11:58] does that make sense? [11:58] asac: for me seems like i386 is only client side docker. [11:58] kickinz1: like http://paste.ubuntu.com/14419442/ [11:59] 1.6 is 15M... latest is 30M [11:59] even for 64 [11:59] * asac scratches head [12:00] asac, there has been a lot of changes between 1.6 and 1.8-1.9 series (with arch support breakage). [12:00] kickinz1: how do you check if a docker binary has just client? [12:01] You can try running it as a daemon, 'docker daemon' or 'docker -d' for prev 1.8 [12:01] asac ^ [12:02] asac, looks good, just not so sure about raw_config [12:07] kickinz1: i moved to a different machien... do you have the link again :)? [12:07] err [12:07] sergiusens: ^ [12:07] sorry kickinz1 [12:07] thank kickinz1 ... seems that latest is busted i guess upstream [12:09] asac: https://docs.docker.com/engine/installation/binaries/ [12:09] right wrong ping :) [12:09] asac: docker just support amd64 arch, so all other arches are client only iirc [12:10] sergiusens: nevermind... found that github has history for me [12:10] sergiusens: there is no raw_config ... just run_raw [12:10] sergiusens: what i need to run is "yes" "" | make oldconfig [12:10] asac, good, because I have no idea what you were talking about wrt docker [12:10] asac, there are patches and an un-upstream way to build it that allow other arches to work. [12:11] i couldnt figure how to do that with existing run methods [12:11] sergiusens: ignore docker :) [12:11] sergiusens: just the gist [12:11] asac, yeah, run_raw is what I meant, sorry [12:12] sergiusens: yeah. so no ideas how to do it different? e.g. good? [12:13] * asac finishes the patch and then thinks about tests [12:16] asac, I'm mostly sure you can implement run with what you have in run_raw [12:16] asac, btw https://gist.github.com/asac/d66ecdbb286e4a60269e#file-kbuild-diff-L56 your assert message is wrong here [12:17] asac, but I don't mind either way, this whole run thing is waiting for a refactor since forever [12:18] asac, the only thing missing in your diff are unit tests ;-) [12:19] right. have to add one more featuure to allow starting with the kconfigfile instead of defconfig [12:19] then will think about tests [12:19] but i am very illeterate onthat,, so might need hand holding [12:22] sergiusens: you think using an argument raw=False for run in __init__.py (avoiding a dupe in that file) would be good? [12:22] oir should i rather just leave it to the refactor master? [12:24] Good morning [12:25] hey kyrofa [12:35] Good morning again now that my internet is working [12:40] asac, I mean, the `exec $*` in regular run might as well be what you have in raw [12:40] kyrofa, ah, that explains the absence :-P [12:40] good morning [12:41] sergiusens, hey :P [13:27] Gahhh sergiusens the yaml tests sent me for a loop this morning [13:27] patcher = unittest.mock.patch('os.path.exists') [13:27] mock_wrap_exe = patcher.start() [13:27] mock_wrap_exe.return_value = True [13:27] ^^ didn't see that [13:28] sergiusens, I was starting to add debug prints to /usr/lib/python3.4/os.py :P [13:50] kyrofa, yeah, patching can do this sometimes [14:02] sergiusens: right. i kind of sensed there is something in here... guess having exec nicely takes over the process and hides the parent shell hack for env [14:02] sergiusens: on that, do you know why the initial code does not set the env through the python call_ [14:02] ? [14:02] not complaining for my case, just wondered if python doesnt have easy way to just pump env to the command it runs [14:04] bah... out of all the skills i have, i seem to be not smart enough to login to my local all snaps kvm using ssh -p XXXX ubuntu@localhost [14:04] asac, I inherited like this; I don't know [14:05] let me reboot to latest .... maybe the dev 17 image is buggy on this, but i thought i managed to log in at some point [14:05] asac, all the env management still needs some work so actually use keys instead of a list [14:07] sergiusens: does ssh to all snap kvm work for you? [14:11] interestingly all host keys are 0 size... guess i know what might have happened ... i killed the first boot when it generated stuff [14:12] * asac redoes image [14:13] do we crewate those keys using cloud-init still? [14:13] * asac wonders where to file bug in case this is the prob [14:14] asac, yes, still with cloud-init [14:17] jdstrand: * adjust program to not use 'setgid' until per-snap user/groups are supported [14:18] jdstrand: could we reference a tracking bug for that feature in the comment (though very nice guidance here) [14:18] thats with snappy-debug.security scanlog [14:19] asac: sure [14:23] elopio, bumper https://github.com/ubuntu-core/snapcraft/pull/201 [14:24] jdstrand: do you remember why busybox did use setgid on everything? [14:24] kyrofa, hey! shall we continue? :) [14:24] i remember we looked at the code a while back [14:24] for the hello-world.sh thingy [14:24] Hey enoch85 :) . I have a meeting here in a minute, let me ping you [14:25] kyrofa, okay! :) [14:28] * asac tries to disable SUID [14:32] sergiusens, elopio sorry guys... internet is flaking [14:33] kyrofa, we can wait [14:33] jdstrand: nevermind... i fixed a config in build system to not support suid of bb and now it works \o/ [14:33] asac: I don't, however bash can be used for hello-world.sh these days [14:34] (just fyi) [14:38] yeah [14:38] seems bizbox has a feature called CONFIG_FEATURE_SUID... i disabled it and now its fun [14:39] sergiusens: is stage a no-op these days? seems that stage happens for each part during build? [14:59] sergiusens: is there a wildcard feature for binaries? i would like to add all that is in stage/bin/ as binaries without having to keep them in sync [15:02] asac, you can use directories in your 'snap' directive [15:03] asac, stage is more complex in 2.x; it takes into account the dependencies (1.x is broken in this regard) [15:07] jdstrand, hey; is there a reason why I can't have spaces in my start keyword? [15:07] jdstrand, without allowing that I have to resort to things like this https://github.com/ubuntu-core/snapcraft/blob/master/examples/shout/snapcraft.yaml#L9 [15:07] jdstrand, with a wrapper script that only does https://github.com/ubuntu-core/snapcraft/blob/master/examples/shout/shout.sh [15:09] sergiusens: are you saying you want to put the contents of the shout.sh script in 'start' in the yaml? [15:10] jdstrand, I want to be able to write 'start: shout --home $SNAP_APP_DATA_PATH' [15:10] right [15:10] jdstrand, ah, '$' is also not allowed [15:11] so, 'start' is not used with the APP_ID since in this example the app id is shout_server_0.52.0 [15:12] so, I think this is to make sure that the systemd file is sane [15:12] jdstrand, I don't follow [15:13] what is in 'start' ends up in ExecStart in the systemd service [15:14] jdstrand, correct, and I'm using SNAP_APP_DATA_PATH, no APP_ID [15:14] not* [15:15] we need to be careful with ExecStart, since a crafted 'start' could run commands outside of confinement [15:16] jdstrand, so basically if I need switches or envvars I need to resort to wrapper scripts? [15:16] if we make the review tools and snappy not allow ';', perhaps we could allow arguments to start [15:17] I wasn't talking about env vars [15:17] jdstrand, that sounds reasonable [15:17] I would assume that if the unit properly set SNAP_APP_DATA_PATH then whatever was in ExecStart would see it [15:18] jdstrand, just asking since it is not allowed, spaces either iirc [15:19] if it is just because of a ; then I hope we can just block offenders [15:19] jdstrand, no rush though [15:19] if someone were to expand this in the manner you would like, we would have to proceed very carefully, because that would be an avenue of attack for a malicious app developer [15:19] jdstrand, yeah, that's why I say no rush :-) [15:20] historically, I feel like 'start' was used as part of the app id. ie, if 'name' was not specified or something [15:21] if start is not part of the app id ever any more, then allowing arguments would seem to make sense (if done carefully) [15:22] jdstrand, so appids are now uuids, right? [15:22] Chipaca, ? ^ [15:22] well """now""" (many air quotes) [15:23] sergiusens: no, not in my current understanding. the app id is today as always. what we are moving to is uuid_appname_revision [15:24] sergiusens: where appname the 'name' in the yaml [15:24] for a service/binary [15:24] so pkgname goes to uuid and version goes to revision [15:24] but appname stays the same [15:25] jdstrand, right, pkgname is snap-id basically which is a uuid [15:26] * jdstrand nods [15:27] jdstrand, another thought is that the only envvars that can be used in a service are those exported in the service itself and we control that (snappy) [15:36] sergiusens: I thought that is more or less what systemd is doing with Environment [15:41] ping stgraber: I was trying to get a xenial lxc in travis to run the snapcraft tests, but it doesn't have network access: [15:41] https://travis-ci.org/ubuntu-core/snapcraft/builds/100523000 [15:41] can you help me here? [15:46] enoch85, today may not work very well... I seem to be having some internet connectivity issues [15:46] elopio: it may just be a timing thing, that is, your container doesn't have an IP address yet [15:46] stgraber: mmm, I'll add a sleep to check. [15:47] enoch85, but I do plan on working on that .snap today [15:47] kyrofa, ok, feel free to work on the apache snap whenever you want. It's above my skill set anyway, so I feel I can't contribute. [15:47] elopio: I'm also very surprised that you're able to install and run lxd in what looks like Travis' docker based environment. I thought they restricted what package and repositories you could install to prevent getting their whole infrastructure to be taken over [15:47] kyrofa, I'm available all day. Just ping me. :) [15:47] enoch85, very good. I'll make sure to walk you through wha tI've done :) [15:47] stgraber: this is not a docker container. This is a trusty machine in google compute. [15:48] elopio: oh, interesting, I didn't know they supported that [15:49] stgraber: it's been working for a couple of months. It's nice, but now we need xenial. [15:49] kyrofa, sounds good :) [15:50] enoch85, sorry about that. I just keep dropping today :( [15:51] kyrofa, np mate. get a better line :) ;) [15:51] I wish [15:51] kyrofa, anyway, no stress. [15:52] kyrofa, need to be done by the 20:th, so there is plenty of time [15:52] enoch85, alright sounds good :) === chihchun is now known as chihchun_afk [16:33] stgraber: no luck. After the sleep it still can't ping anything. [16:38] elopio: might be worth running ifconfig inside the container and outside of it, just to check if things look sane [16:39] stgraber: ok, it'll take some minutes. Travis is slow today... [16:39] kyrofa, elopio I'll bbl in case someone pings me [16:40] sergiusens, alrighty [17:04] elopio, mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/204 ? [17:23] stgraber: the host shows lxcbr0. The container shows nothing: [17:23] http://pastebin.ubuntu.com/14422058/ [17:23] kyrofa: let me see. [17:24] kyrofa: what about an example test for this change? [17:28] elopio, what does that mean in snapcraft? Something that exercises this in snapcraft/examples? [17:30] elopio: what's your travis.yml? [17:30] kyrofa: yes. Like a real world example that uses the new code. [17:30] elopio: the behavior you're getting would be consistent with having an older version of lxc, or lack of lxcfs or systemd being unhappy in the container [17:31] stgraber: https://github.com/elopio/snapcraft/blob/lxd/.travis.yml [17:31] stgraber: I'm getting it from the lxd-stable ppa. [17:31] elopio, alright I'll throw something together :) [17:31] kyrofa: thank you. [17:32] elopio: ok, add a "sudo apt-get dist-upgrade -y" after the apt-get update and add "lxcfs" on the apt-get install line, just in case travis runs with recommends disabled by default. [17:32] * elopio tries. [17:32] elopio: and add a "lxc exec xenial -- ps faux" too so we can see what's running in the container [17:36] elopio, do I also add the new example to TestSnapcraftExamples ? [17:36] kyrofa: to build it, yes. I'm guessing that it will require manual inspection to check that it works ok, am I right? [17:37] elopio, ah, yeah this is a runtime fix, not build [17:37] we might need to add a manual_tests dir, like in snappy. [17:37] elopio, and we're not running runtime tests, right? [17:38] kyrofa: we can from xenial, so just let me finish this PR and there will be automated runtime tests. [17:39] kyrofa: but I'm wondering is how to confirm that your example works ok automatically. Well, I better wait to see the example. [17:40] elopio, yeah, basically without this fix it fails to run since it can't link up with libgl. But it builds fine. With the fix it links and runs successfully [17:41] kyrofa: ok, so we can at least check that it doesn't return an error. For now leave it with the build test, and soon we'll start adding runtime tests for the examples. [17:41] elopio, good deal, adding now [18:07] elopio, alright, take another look at that PR for the example [18:09] stgraber: it pinged! [18:09] kyrofa: are you in a hurry, or can I go and get something to eat first? [18:09] cool, so it was either an old pre-installed lxc or missing lxcfs [18:09] elopio, I'd like to get this merged today just so I can prepare the release, but my EOD is a few hours away yet [18:10] elopio, I'd never stand between you and food ;) [18:11] kyrofa: let me better review it first. Otherwise I'll keep thinking of you during lunch :p [18:11] elopio, hahaha [18:12] elopio, fortunately I don't think it could be simpler [18:13] yes, looks good. I like that we now have an opencv example! [18:13] elopio, awesome! [18:54] stgraber: is there a fancy way to wait for the ip? The sleep is making my nice script ugly. [18:55] elopio: not a very nice one, but there is nicer than just a big sleep, yeah [18:55] while ! lxc info tryit | grep -q eth0.*IPV4; do [18:55] sleep 5s [18:55] done [18:55] replace tryit by your container name [18:56] thanks! [18:56] - [20:32] sergiusens, is the fix to bug #1530995 to chmod before running, or run with sh? [20:32] bug 1530995 in Snapcraft "Snapcraft requires autogen.sh to be executable" [Medium,Triaged] https://launchpad.net/bugs/1530995 [20:33] sergiusens, which is the safer assumption-- we have permission to chmod, or it's actually using sh and not bash or something? === joachim is now known as Guest60026 [20:51] sergiusens: by default all files from stage/ go to snap/ right? [20:51] * asac about to hit send on answer on ML [20:57] damage done := === cprov_ is now known as cprov [22:08] asac, answer is yes