[12:55] <kyrofa> Good morning everyone
[12:57] <kyrofa> shuduo_, I'd like to discuss your ROS problems today if you're around
[13:05] <asac> utlemming: do you have all-snap builds already for gce?
[14:08] <asac> hmm... latest ubuntu-core all-snap breaks my etherpad :(
[14:08] <asac> good news is rollback ubuntu-core resurrected it
[14:09] <asac> hmm. who broke stuff?
[14:10]  * asac updates again
[14:12] <asac> jdstrand: tyhicks: ok latest core bails my ethpad because it restricts syscall=49 which seem to not have caused issues before
[14:14]  * asac reboots and tries to find where the security pol info now lives
[14:16] <asac> hmm. what was the script againthat spits out syscall names?
[14:26] <asac> kyrofa: snapcraft generated something odd for caps for me: http://paste.ubuntu.com/14164111/
[14:26] <asac> any idea?
[14:26] <asac> my input was not having caps as a list item:
[14:26] <kyrofa> asac, eww
[14:26] <asac> cat snapcraft.yaml  | pastebinit
[14:26] <asac> http://paste.ubuntu.com/14164118/
[14:27] <asac> anything that strikes you?
[14:27] <kyrofa> Hmmmmm
[14:27] <asac> wow :)
[14:27] <asac> interestingly this worked though
[14:27] <asac> it gave my pad the network-servbices permission
[14:27] <kyrofa> Wait, what?
[14:27] <kyrofa> Hahaha
[14:27] <asac> and now the node process does not go defunct with bind syscall bailing anymore
[14:27] <asac> weird
[14:28] <asac> let me double check
[14:28] <asac> that i am on the ubuntu-core that has that problem with that that caps entry
[14:28] <asac> kyrofa: do you see in code whats going on with the caps transform?
[14:28] <kyrofa> There's got to be a bug here. Two I'd say, if that actually runs :P
[14:29] <asac> yeah
[14:29] <asac> :)
[14:29] <kyrofa> asac, I'm looking now
[14:29] <asac> let me commit this so you can run it yoursel;f
[14:29] <asac> give me one sec
[14:30] <asac> so confirmed that without that odd caps it bails on bind
[14:30] <asac> now adding it again and committing
[14:31] <kyrofa> asac, which snapcraft are you using?
[14:34] <asac> kyrofa: master HEAD ... https://github.com/asac/etherpad-lite/tree/snap-support
[14:34] <asac> get that branch, cd bin/snappy
[14:34] <asac> run snapcraft snap
[14:34] <asac> from master HEAD
[14:35] <kyrofa> Alright, let me play with it for a minute
[14:35] <asac> https://github.com/asac/etherpad-lite/tree/snap-support/bin/snappy
[14:35] <asac> also works with 1.x
[14:35] <asac> which is coolie :)
[14:36] <asac> but i suspect that we never really prevented bind etc. because it stopped working on all snaps from -2 to -4 when i didnt have that caps
[14:36] <asac> (in case you care about ubuntu-core runtime as well)
[14:36] <asac> ok stepping out for 5 min
[14:36] <asac> bbiab
[14:37] <asac> kyrofa: oh one more thing... i rfind it odd that we dont run "snap" as default on master... it just bails if i dont pass any target
[14:37] <asac> anyway... bbi5
[14:37] <kyrofa> asac, yeah it surprised me as well
[14:38] <kyrofa> asac, we'll pass that by sergio when he gets back, see how he feels about a default target again
[14:49] <asac> kyrofa: i get the same caps syntax on 1.x
[14:50] <kyrofa> asac, alright. We were just about to release, so I'll hold off
[14:50] <asac> lets see if 15.04 also eats this fine at least
[14:51] <kyrofa> asac, and yeah, I can reproduce so I'm working on this now
[14:51] <asac> kyrofa: release without sergio around or might he pop in today?
[14:52] <asac> asking bc i had two pulls i think woudl be nice to have included
[14:52] <asac> https://github.com/ubuntu-core/snapcraft/pulls
[14:52] <asac> topmost
[14:52] <asac> not needed for the variant above, but for my other build from outside recipe its needed
[14:52] <kyrofa> asac, I was hoping he might pop in long enough to make sure I didn't blow it to kingdom come, though that may not have happened anyway (in which case I wouldn't release, of course)
[14:53] <asac> e.g. for https://github.com/asac/etherpad-lite-snap
[14:53] <asac> ok... well, since i made this inline approach now the pull above could wait if it feels risky
[14:53] <asac> but have it for 1.x and master in case
[14:54] <asac> anyway, the caps is probably more interesting :)
[14:54] <kyrofa> asac, ah okay. I'll make sure I take a look at those :)
[14:54] <asac> ok so seems 15.04 also eats the - caps
[14:54] <asac> ODDDD
[14:54] <asac> :)
[14:54] <kyrofa> asac, yeah that's quite an impressive screwup
[14:54] <kyrofa> asac, you should be proud
[14:54] <shuduo> kyrofa, hi
[14:54] <kyrofa> shuduo, hey!
[14:55] <shuduo> kyrofa, let me post ROS build log
[14:56] <kyrofa> shuduo, please do. If you can post the ROS code, that would be great as well
[14:57] <shuduo> kyrofa, http://pastebin.com/RHbPTeWv actually i am trying to build ros example code of snapcraft I git clone from github.com
[14:58] <kyrofa> shuduo, ah that makes it easy
[15:02] <asac> ok filed bug for odd runtime beahviour here: https://bugs.launchpad.net/snappy/+bug/1528871
[15:03] <asac> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1528873 is the other side
[15:05] <kyrofa> asac, excellent, thank you :)
[15:05] <kyrofa> shuduo, wow, probably the most helpful error ever, huh?
[15:06] <kyrofa> shuduo, I'm particularly sorry that happened while you were trying to show it to someone
[15:06] <kyrofa> shuduo, that error, while being insanely unhelpful, I believe indicates that you're trying to launch a binary that can't be found, so it can't be wrapped
[15:07] <kyrofa> shuduo, I only know this because it happened to me just a bit ago (an error message I plan on fixing)
[15:07] <kyrofa> shuduo, can you give me a link to what you're trying to build?
[15:08] <kyrofa> asac, give me a sanity check?
[15:09] <shuduo> kyrofa, that's fine if you are already aware. I'm trying to build https://github.com/ubuntu-core/snapcraft/tree/master/examples/ros
[15:10] <kyrofa> asac, http://pastebin.ubuntu.com/14164908/ == good yaml?
[15:10] <kyrofa> (in python form)
[15:10] <asac> kyrofa: which one?
[15:10] <asac> ahh
[15:10] <asac> thougth pull etc.
[15:11] <asac> kyrofa: give me a patch and i try the real snap
[15:11] <asac> but the first looks ok now
[15:11] <asac> the binaries list
[15:11] <kyrofa> asac, I'm not to that point just yet. To me, that paste looks good. It's handed off to yaml.write, then if I read the write that's written, it looks terrible (as you've seen)
[15:12] <kyrofa> I think yaml.write is a third-party lib
[15:12] <asac> oddd
[15:12] <kyrofa> asac, excuse me-- yaml.dump
[15:12] <kyrofa> Still investigating
[15:13] <kyrofa> asac, have you tried making your caps lists regular lists (i.e. not inline [item1, item2] but:
[15:13] <kyrofa> -item1
[15:13] <kyrofa> - item2)
[15:13] <asac> so yeah i think it might be correct actually :(
[15:13]  * asac looks again
[15:13] <asac> yeah its correct
[15:14] <asac> just super unfortunate ordering
[15:14]  * asac marks invalid
[15:15] <kyrofa> asac, ohhhh it IS isn't it! the hyphen caps was really throwing me
[15:15] <asac> right
[15:15] <kyrofa> But yeah, still a valid map
[15:15] <asac> a way to guuide the yaml formatter?
[15:15] <kyrofa>  /list of maps
[15:15] <kyrofa> asac, I doubt it :(
[15:15] <asac> think we would love to see the serializer to produce name first
[15:15] <asac> and exec then
[15:15] <asac> etc.
[15:15] <asac> and caps last :)
[15:15] <asac> lol
[15:15] <asac> ok neat
[15:16] <kyrofa> asac, I'll look into it though
[15:20] <kyrofa> asac, why did you look at the generated package.yaml? How often do you think devs do that?
[15:21] <asac> many times
[15:22] <asac> caps will be very frequent
[15:22] <asac> it hink we should investigate if we can subclass Dumper
[15:22] <asac> or something and give some sanity hints somehow
[15:22] <asac> so it looks neat
[15:22] <asac> like you would write it
[15:22] <asac> start with name
[15:22] <asac> exec/start:
[15:22] <asac> description:
[15:22] <asac> end with caps list
[15:23] <asac> maybe we could use an event parser to remember the order for those elements that are just pass through?
[15:23] <asac> let me file a bug that the formatting looks ugly
[15:23] <asac> :)
[15:23] <asac> but nothing important afaics
[15:23] <kyrofa> asac, yeah if people look at that very often you're probably right. Do you mind logging a separate bug?
[15:23] <kyrofa> Haha, yeah thanks :)
[15:24] <kyrofa> Yeah I agree-- I'll get back to squashing release-blocking bugs. I'll take a look at your PRs as well :)
[15:26] <asac> ok filed https://bugs.launchpad.net/snapcraft/+bug/1528878
[15:28] <asac> oh i think the real thing is that my stuff gets transformed from map style to list style... where the name is in the name: field... maybe we could just keep same style to make things better for now
[15:29] <asac> ok added comment to bug for this
[15:30] <asac> oh seems my pull request adds too long line :)
[15:31] <kyrofa> asac, thanks for working out the kinks!
[15:31]  * asac fixes
[15:50] <asac> kyrofa: i have no idea how the test stuff works. where does it find the test package.json for the node test?
[15:50] <kyrofa> asac, the nodejs plugin test?
[15:51] <asac> kyrofa: yeah
[15:51] <kyrofa> asac, master branch?
[15:51] <asac> sure
[15:53] <asac> guess i dont get the mock
[15:53] <kyrofa> asac, after a quick look, there seems to be only one test that would require one, and it makes it itself (test_build_local_sources)
[15:53] <kyrofa> asac, the others just mock out the npm install
[15:54] <asac> right
[15:54] <asac> hmm
[15:54] <asac> let me think
[15:54] <asac> so i added a new option
[15:54] <asac> that allows to point to a dir other topdir for part to have the package.json
[15:54] <kyrofa> asac, well, since npm install is essentially shelled out (using snapcraft.common.run), if one mocks snapcraft.common.run, you can verify that npm install was called correctly without actually calling it
[15:55] <asac> fguess we are not testing npm /path/to/where/package.json is right now
[15:55] <kyrofa> asac, no, since (I'm assuming) /path/to/where was always the root?
[15:56] <asac> in the past it was
[15:56] <asac> now its allows to use a subdir of the part
[15:56] <asac> ok let me try something
[15:56] <kyrofa> asac, okay, so make a new test that sets up that environment, with the subdir etc
[15:56] <asac> how do i run those tests though locally?
[15:57] <kyrofa> Then assert that the run_mock was called with the right path
[15:57] <kyrofa> asac, that's outlined in the readme, but you can run the unit tests with ./runtests.sh unit
[15:59] <asac> git diff | pastebinit
[15:59] <asac> http://paste.ubuntu.com/14166326/
[15:59] <asac> how about that?
[15:59] <asac> err bad syntax
[15:59] <asac> moment
[16:00] <asac>  git diff | pastebinit
[16:00] <asac> http://paste.ubuntu.com/14166382/
[16:00] <asac> that oen
[16:00] <asac> ok let me in the readme
[16:08] <kyrofa> Sorry asac uhh... my mouse pointer disappeared :P
[16:09] <kyrofa> Having trouble getting those links. I guess X needs a restart
[16:09] <kyrofa> asac, be back in a minute and I'll be happy to help :)
[16:10] <asac> ok i think i fixed it :)
[16:11] <asac> lets see what travis thinks
[16:13] <kyrofa> Back
[16:13] <asac> kyrofa: ok so i think i fixed those i have a clue about
[16:13] <asac> those that are left i dont understand
[16:14] <asac> https://travis-ci.org/ubuntu-core/snapcraft/builds/98540359
[16:14] <asac> oh
[16:14] <asac> one sec
[16:15] <kyrofa> asac, alright so you may have a bug here
[16:16] <kyrofa> The npm install call happens with a working directory of the builddir
[16:16] <kyrofa> But you seem to have modified it to pass an extra parameter which in the case of test_build_local_sources is the same as the working directory
[16:16] <kyrofa> That may work fine, but the test will need to be updated to assert a different call on the mock
[16:16] <kyrofa> (i.e. including that extra parameter)
[16:18] <kyrofa> asac, the second failure is similar, though it seems like you're actually using subdir there. You need to change the mock assertion to make sure that extra parameter is there
[16:18] <asac> right will update test
[16:19] <asac> ok let me do this after dinner etc.
[16:19] <asac> thanks for your help
[16:19] <asac> no need to hold back release
[16:21] <kyrofa> asac, no problem! And yeah, I don't think the release is happening today. Sergio hasn't gotten back to me (I don't blame him) and I found another bug :(
[16:22] <kyrofa> asac, so a) don't work too hard, and b) releases are easy. We can always make another
[18:01] <kyrofa> Ugh... who ever thought that "Santa Baby" was a decent song