[07:16] <dholbach> good morning
[08:19] <fgimenez> good morning
[08:20] <zyga> hey fgimenez :)
[08:21] <fgimenez> hi zyga! :)
[09:23] <dshihovtsev> Chipaca, ogra_  hey guys. Is there any way to set nofile limits for service before snap packages install, in package.yaml or somewhere else?
[09:37] <JamesTait> Good morning all; happy Wednesday, and happy Day Of Reconciliation! 😃
[10:22] <ogra_> dshihovtsev, i doubt that ... the new "capabilities" implementation miht change that in the future though
[10:22] <ogra_> but probably Chipaca knows more
[11:04] <Chipaca> dshihovtsev: no. I'd expect the gadget (in 15.04: oem) snap to do that, fwiw
[11:41] <dshihovtsev> Chipaca, ogra_ got it, thanks
[14:29] <stevebiscuit> Chipaca: for your pleasure: https://github.com/ubuntu-core/snappy/pull/258
[14:32] <kyrofa> elopio, having trouble?
[14:36] <kyrofa> elopio, you must be, heh. Ping me when you get back :)
[14:37] <fgimenez> Chipaca, regarding snappy-m-o's comment https://github.com/janinko/ghprb
[14:58] <jdstrand> Chipaca: hi!
[14:58] <jdstrand> Chipaca: I had a couple of questions regarding all snaps. are you around?
[15:58] <kgunn> stgraber: hey there, i've been using lxc reliably and had lxcbr0 working....but after just updating my xenial host last night, not lxc fails to start
[15:58] <kgunn> i've reinstalled
[15:58] <kgunn> and tried to delete, and launch new containers...
[15:58] <kgunn> all fail to start with the same err
[15:59] <kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFQ0tDZjh4YVJlVlk/view?usp=sharing
[16:00] <kgunn> stgraber: that's my lxc info --showlog ^
[16:14] <stgraber> kgunn: looks like the problem is that cgmanager isn't running or not working
[16:15] <stgraber> kgunn: do you have lxcbr0 on your system?
[16:15] <kgunn> stgraber: nope, it's weird and it fails to start if i try to ifup manually....
[16:16] <kgunn> stgraber: full disclosure, i've also got it tied to static ip....wondering if i need to reboot my router ?
[16:16]  * kgunn is a networking noob
[16:16] <stgraber> kgunn: can you run "sudo /usr/lib/x86_64-linux-gnu/lxc/lxc-net restart", see if lxcbr0 comes back up
[16:16] <kgunn> will try that in a sec...actually on a HO :)
[16:17] <kgunn> oh..lxc, can do now
[16:18] <kgunn> stgraber: ah...yeah, i see it's up now
[16:20] <kgunn> stgraber: fwiw, also...that command spewed back
[16:20] <kgunn> https://pastebin.canonical.com/146291/
[16:20] <kgunn> even tho lxcbr0 came up...
[16:20] <kgunn> dunno if that matters
[16:34] <kgunn> stgraber: thanks btw, back in biz
[17:03] <plars> elopio: around? Did you see that I got it working yesterday?
[17:15] <elopio> plars: I am now.
[17:15] <elopio> plars: I didn't, but that's great news :)
[17:16] <elopio> kyrofa: hey, sorry. There was a blackout all morning, and crappy 3g internet.
[17:16] <kyrofa> elopio, wow!
[17:16] <kyrofa> elopio, not a problem at all
[17:16] <kyrofa> elopio, power back up now?
[17:16] <plars> elopio: It was building from the downloaded trunk rather than the branch I told it to build, so I had to just symlink my branch after removing the one it pulled down. Do you have some way of automatically dealing with stuff like this? It seems like it would be common to want to use a local copy for testing rather than pulling trunk in every case
[17:18] <elopio> kyrofa: all good now. I survived :)
[17:18] <elopio> plars: what was pulling trunk?
[17:18] <kyrofa> elopio, glad to hear it ;)
[17:18] <Chipaca> jdstrand: i am around now!
[17:19] <elopio> balloons: yesterday I reviewed xcub snap and it is installable, but it doesn't do anything.
[17:19] <Chipaca> stevebiscuit: um ... do you want to go that way?
[17:19] <Chipaca> stevebiscuit: I would've expected to use the REST API directly?
[17:19] <plars> elopio: in the go path, from getting the dependencies
[17:20] <elopio> balloons: if I understand correctly, he's packaging a chat server, so it should be a service that runs on the background, not a binary.
[17:20] <jdstrand> Chipaca: hey, I was just wondering what the status is of all snaps and 16.04. can I flash an rpi2, bbb, amd64 vm? how? do I need a special snapcraft for all snaps? where is it? will all-snaps os image support installing tar snaps or just squashfs?
[17:20] <elopio> balloons: when I was about to reply to him, he left. And I don't understand how to leave comments in codein.
[17:21] <elopio> plars: I'm not sure how do you have your workspace set up. I have workspace/go/src/github.com/ubuntu-core, and there I cloned the git repo.
[17:21] <Chipaca> jdstrand: i don't know about snapcraft and all-snaps. you do need a special u-d-f for all-snaps. An all-snaps os image will not support ar snaps.
[17:21] <elopio> so I can checkout a branch that's not master.
[17:21] <Chipaca> jdstrand: http://people.canonical.com/~mvo/all-snaps/ is what i have for all-snaps
[17:22] <jdstrand> Chipaca: ok, thanks
[17:22] <plars> elopio: I just pointed my GOPATH to /tmp/go, and I was hacking on it in ~/code/snappy or something like that, along with git remotes for your repo
[17:23] <plars> elopio: so it sounds like with go, you either adhere to their way of doing things, and either swap dirs around by hand or manually manage the checkout you have there, or you push symlinks around to hack around the way it pulls things in through GOPATH?
[17:23] <elopio> plars: yes, my go path and workspace are the same. I suffered a lot with bzr and symlinks trying to keep them separated. git makes it a lot easier.
[17:24] <plars> I imagine so... for some definition of "easier" :). at least with git you can have multiple branches and just checkout the one you want
[17:24] <elopio> with symlinks you can do pretty much everything you like, but it becomes messy.
[17:25] <plars> elopio: so one thing that is still keeping it from running without me manually doing something, is that it seems to want a json testconfig file. Is this something we would need to create by hand? I see it's done in main.go right now, but that's not getting used I think if we just use go test
[17:25] <elopio> plars: yes, that's how we pass arguments from the host to the testbed.
[17:26] <stevebiscuit> Chipaca: do you think it would be better to have that code in WebDM itself instead? I saw that work to develop a client lib had already started and thought it wouldn't be great to duplicate effort. I almost had to toss a coin tbh
[17:27] <Chipaca> stevebiscuit: I ... i honestly don't know. I *do* know that the situation we have now, where webdm needs to be released in lockstep with snappy is a pain (and running webdm on systems with old snappys a nightmare)
[17:28] <Chipaca> stevebiscuit: I fear we may inadvertently slip into this again even using the rest api if we link against a client in snappy itself
[17:28] <Chipaca> stevebiscuit: that's why for a while i entertained making client a separate project entirely
[17:28] <Chipaca> otherwise it's too easy to make it chummy with snappy itself
[17:28] <Chipaca> and on good days i'll catch those, but on bad days i won't
[17:30] <stevebiscuit> Chipaca: yeah, separating webdm from snappy is a priority from my pov, currently that client lib is just handling HTTP-over-socket
[17:31] <stevebiscuit> Chipaca: maybe bite the bullet and create a new snappy-client project now?
[17:31] <stevebiscuit> Chipaca: as it stands, my PR can be relocated easily
[17:32] <Chipaca> stevebiscuit: go for it
[17:32] <Doughball> Hello all. I'm working on a new product that uses the Beaglebone Black as a gateway device. I would really like to use Ubuntu Snappy Core in this product, but I am worried that it is not yet "production" worthy. Is Ubuntu Core completely stable at this point for product use?
[17:33] <Chipaca> mectors: ^
[17:35] <Chipaca> Doughball: 15.04 is being used for production by a few folks
[17:35] <Chipaca> Doughball: I work on rolling, which is most definitely not stable :-)
[17:35] <Chipaca> because we break it all the time
[17:35] <Chipaca> Doughball: but 15.04 should be stable enough (and we do fix bugs in it if you find any)
[17:36] <Chipaca> Doughball: but mectors is probably a better person to talk to if you need commercial guarantees
[17:36] <stevebiscuit> Chipaca: ok, I'm game, I'll close that PR and work at creating a new project containing the existing commits to the client lib
[17:37] <Chipaca> stevebiscuit: holler if you need help, as always
[17:37] <plars> elopio: from what I gather, I mostly just need to give it the release and channel
[17:37] <Doughball> Chipaca: Thanks.
[17:37] <Chipaca> zyga: elopio: ^^^ stevebiscuit is going to create a snappy rest api client project
[17:38] <Chipaca> a lot of the team is out most days until next year (the old “yikes, i never used my holidays” dance)
[17:38] <stevebiscuit> heh
[17:38] <Chipaca> stevebiscuit: but i guess you know that already
[17:39] <zyga> Chipaca: mmm?
[17:39] <elopio> plars: we could probably also get default values if the file doesn't exist.
[17:39] <zyga> Chipaca: so now bits go to separate project?
[17:39] <zyga> Chipaca: client bits
[17:39] <plars> elopio: do the tests actually need them?
[17:39] <Chipaca> zyga: so webdm and snap both talk to that
[17:39] <Chipaca> zyga: yarr
[17:39] <zyga> Chipaca: ok, so I guess 'snap' the executable is going to live there too?
[17:39] <Chipaca> zyga: and ubuntu-image
[17:40] <Chipaca> zyga: either there, or in a *third* place
[17:40] <zyga> Chipaca: so all the capable patches I'll post (har har) will target that
[17:40] <elopio> plars: we use it to tell the setup to start with an update or rollback. If you don't want those scenarios, then it won't be needed.
[17:40] <Chipaca> zyga: how deep is your pipeline right now?
[17:40] <Chipaca> stevebiscuit: hold it
[17:41] <zyga> Chipaca: well, all the stuff I have now can be neatly dropped on top of trunk, it's entirely self contained
[17:41] <Chipaca> stevebiscuit: maybe we land zyga's work first, then split, in which case your change could land as is
[17:41] <zyga> Chipaca: I haven't touched renaming CLI bits and other things we've agreed to
[17:41] <Chipaca> stevebiscuit: zyga: you guys work it out, i've got to go make kids do homework :-)
[17:41] <zyga> Chipaca: I don't have any strong feelings about landing it before
[17:41] <zyga> stevebiscuit: so without reading the backlog, how urgent is this?
[17:42] <Chipaca> i'm flexible, you both know the forces driving the change, so
[17:42] <stevebiscuit> Chipaca, zyga: I'm just about to EOD now so wouldn't be starting until tomorrow
[17:42] <zyga> stevebiscuit: same here
[17:43] <elopio> stevebiscuit: please involve fgimenez tomorrow.
[17:43] <Chipaca> ah, ok, let's talk tomorrow then
[17:43] <Chipaca> fgimenez is like elopio but utc+1
[17:43] <elopio> we could use the same client for the user tests.
[17:43] <elopio> and less hair.
[17:44] <stevebiscuit> heh
[17:45] <stevebiscuit> ok, I'll start a discussion in the GMT morning and we can decide what's going in and being taken out of where
[17:47] <elopio> ogra_: would this work even if test exists != 0?
[17:47] <elopio> test "$(./stage/bin/test)" = "Hello world"
[17:49] <ogra_> elopio, what are you assigning that hello world to ?
[17:51] <elopio> ogra_: mmm, nothing. It's just checking the output of the test binary.
[17:52] <ogra_> test "$(./stage/bin/test)" && echo  "Hello world"
[17:52] <ogra_> that will echo "hello world" if test exits true
[17:52] <Chipaca> stevebiscuit|awa: zyga: elopio: ftr niemeyer says we should split it later, to keep the speed, as long as we can keep an eye on the issue of chumminess
[17:52] <ogra_> test "$(./stage/bin/test)" || echo  "Hello world"
[17:53] <ogra_> and that if test exits false
[17:54] <elopio> ogra_: right. But I wanted to know if test "$bin" = "something" would be affected by the exit value of bin.
[17:54] <elopio> I've just thrown it at travis, we'll see soon.
[17:55] <ogra_> oh, no, it shouldnt if you exec it in a subshell and just use the output value( i.e. "$(...)"  )
[18:00] <elopio> damn it. I spend the whole night debugging why the binary failed when run from python.
[18:00] <elopio> it was not that. It has always failed when run in travis. :@
[18:41] <balloons> elopio, load https://codein.withgoogle.com/dashboard/task-instances/5486692492378112/, and enter your comments
[18:45] <kyrofa> elopio, when you're able: https://github.com/ubuntu-core/snapcraft/pull/169/files
[18:45] <kyrofa> elopio, https://github.com/ubuntu-core/snapcraft/pull/169 rather
[22:13] <jerryG> tedg are u there?
[22:14] <tedg> Yup, howdy jerryG
[22:15] <jerryG> tedg: I'm trying to get pkgconfig working.  How do i use pkg-config-sysroot in snapcraft?
[22:15] <jerryG> tedg: I found this: https://github.com/ubuntu-core/snapcraft/blob/master/examples/godd/snapcraft.yaml
[22:16] <jerryG> tedg: but I'm trying to add .pc files
[22:16] <jerryG> tedg: the .yaml in that example is only .so files
[22:18] <tedg> jerryG: pkg-config will work generally if you just install it as a stage-package, we'll setup the paths and such.
[22:18] <tedg> jerryG: Are you trying to mkae a part fo the library with a .pc file?
[22:19] <jerryG> tedg:  yeah I've got a few .pc files I need to add to pkgconfig
[22:20] <tedg> jerryG: So if you stage-packages pkgconfig you should be able to install them into the staged area of /usr/lib/pkgconfig
[22:21] <tedg> jerryG: Make sure to use the after directive to align your parts so they build in order.
[22:22] <jerryG> tedg:  thank you
[22:23] <jerryG> tedg: do I put the .pc files under filesets?
[22:25] <tedg> jerryG: You shouldn't need to worry about that starting out as the default is to copy everything. You'll probably want to filter them later, but don't worry about that at first.
[22:26] <jerryG> tedg: do u have any examples on pkg-config w/ stage-packages ?
[22:28] <tedg> jerryG: Hmm, I can't think of one. But I know I fixed a few bugs with it, so we've done it. Doesn't look like the current examples do it though.
[22:28] <jerryG> tedg: can u send me one?
[22:28] <jerryG> tedg: :)
[22:29] <jerryG> tedg: plz
[22:30] <tedg> jerryG: I don't have one, but if I run across one I can pass it along.
[22:30] <jerryG> tedg: k thx.  do u need my email?
[22:32] <tedg> jerryG: Sure, but also you could post a message to snappy-app-dev to see if anyone else has one.
[22:32] <jerryG> ok
[22:32] <jerryG> tedg: is that another irc?
[22:32] <jerryG> tedg: or just mailing list?
[22:32] <tedg> jerryG: Mailing list
[22:36] <jerryG> tedg: pastebin.com/raw/wSjA2zVp
[22:39] <tedg> Got it
[22:39] <jerryG> tedg: thx