[02:08] <sergiusens> elopio can you check https://github.com/ubuntu-core/snapcraft/pull/584 ... I have no vpn here
[02:29] <derpSauce> Dumb question, can I install snapd on ubuntu 14.04?
[05:18] <dholbach> hey hey
[07:03] <netphreak> Hi, guys!
[07:21] <zyga> good mornig
[07:22] <netphreak> morning :)
[07:37] <netphreak> Any news on Rpi3 support?
[08:13] <morphis> mvo: ping
[08:20] <mvo> morphis: pong
[08:21] <morphis> mvo: what's up with snapd 2.0.10 ? :-)
[08:21] <mvo> morphis: a bit of internal debate, I will enquire about this I think we can do one today otherwise
[08:22] <morphis> ok
[09:07] <didrocks> zyga: hum, seems that I'm stuck at removing one snap
[09:07] <didrocks> 161  Done    2016-06-24T08:31:46Z  2016-06-24T08:31:46Z  Try "atom" snap from "/home/didrocks/work/ubuntu-core/snappy-playpen/atom/prime"
[09:07] <didrocks> 162  Doing   2016-06-24T09:04:17Z  -                     Remove "atom" snap
[09:07] <didrocks> mount | grep atom returns nothing
[09:07] <didrocks> and as there are some operations in progress, I can't do anything
[09:11] <zyga> didrocks: what does 'snap change 162' say?
[09:14] <didrocks> zyga: http://paste.ubuntu.com/17792496/
[09:14] <didrocks> so, I was able to stop it manually (some processes were hanging the mount point)
[09:15] <didrocks> however, despite unmouting it, not snapd is stuck
[09:15] <didrocks> ah no, it's done
[09:15] <didrocks> (after a while)
[09:15] <didrocks> still the same change #
[09:16] <didrocks> but snap change <this_number> still shows the error
[09:16] <didrocks> (which is puzzling)
[09:16] <didrocks> at least, now, the transaction is over, thanks zyga :)
[09:23] <zyga> didrocks: snapd will recover after 5 minutes
[09:24] <zyga> didrocks: we already know about issues when the service doesn't shut down cleanly
[09:26] <zyga> jdstrand, tyhicks: i've tested the more strict version of snap-confine and it should be merged as tyhicks suggested
[09:26] <zyga> I'll adjust some tests and merge it
[09:34] <Snowie> Howdy all. Not sure where to report. Installing freecad on ubuntu as a snap didn't produce a working desktop shortcut or cli command. installing it from apt did. Just want to know where to let someone know?
[09:36] <didrocks> I think lool followed the freecad guys on their snappy journey ^
[10:00] <ogra_> well, works fine here
[10:00] <ogra_> freecad.FreeCAD the cli command it installs
[10:01] <ogra_> Snowie, ^^
[10:06] <lool> ogra_: did you get a desktop file?
[10:07] <ogra_> lool, hmm, i know ii used to have one ...
[10:07] <ogra_> seems gone
[10:08] <ogra_> or t least not found anymore
[10:08] <ogra_> the cli command is definitely still here though and the app starts and runs fine
[10:11] <Snowie> ogra_: i did try that, but let me give it another go.
[10:12] <ogra_> Snowie, are you on an Ubuntu 16.04 install or is that some other distro ?
[10:13] <Snowie> ogra_: standard 16.04
[10:13] <ogra_> k
[10:13] <ogra_> same here
[10:15]  * ogra_ is off to the dentist ... (at least something positive on this horrid day :P )
[10:15] <Snowie> no joy http://paste.ubuntu.com/17794309/
[10:15] <Snowie> ogra_: oh. good luck, hope it's not too terrible.
[10:16] <ogra_> nah, just a post surgery inspection .. all bad stuff already happened
[10:16] <Snowie> ogra_: lol. ok, hope all is well then
[10:16] <ogra_> Snowie, try freec<tab> ... doesnt that expand to freecad.FreeCAD ?
[10:17] <Snowie> ogra_: lol, yeah that did it. thanks
[10:17] <ogra_> (the binary is actually called like that, not just "freecad")
[10:17] <Snowie> still no icon thought but cheers
[10:17] <ogra_> yeah, thats a bug
[10:17] <ogra_> the binary should also just become "freecad"
[10:17] <Snowie> ogra_: and sounds like it's known by that comment too. ok cheers
[10:18] <ogra_> well, probably not by the freecad developer
[10:18] <ogra_> lool, ^^ can we get him that info somehow (i only know him from IRC)
[10:18] <ogra_> anyway ... -> out
[10:24] <lool> ogra_: I was looking for a public link to this email address but https://uappexplorer.com/app/freecad.vejmarie has a weird one
[12:32] <ogra_> re ...
[12:41] <zyga> jdstrand, tyhicks: I'd like a final yes/no vote on chdir branch
[12:48] <zyga> jdstrand, tyhicks: after your decision I'd like to merge remaining branches and release new snap-confine
[12:48] <zyga> and work on snapd changes to make policy changes automatic
[12:48] <zyga> so that refreshed policy is applied when needed
[13:05] <jdstrand> zyga: I responded in the PR
[13:06] <jdstrand> zyga: and yay on refreshing policy as needed as being up next :)
[13:07] <jdstrand> zyga: interestingly, the apparmor side of that bug (which is not needed for your work) is close to my next thing to work on :)
[13:08] <zyga> jdstrand: thank you, looking now
[13:09] <zyga> jdstrand: good point, I'll make the change now
[13:09] <zyga> jdstrand: cross-distro concern, how can we simplify our work to not have to synchronize various apparmor abstraction across the distros
[13:13] <jdstrand> zyga: this isn't actually just a cross distro concern and something we've thought about all along. a) abstractions don't change that much and b) when they do, we push the change both to apparmor upstream and to snapd policy so snapd can realize the benefits immediately
[13:14] <jdstrand> we can periodically prune the duplicate rules in snapd and say snapd required apparmor userspace version x.y.z
[13:14] <jdstrand> requires*
[13:17] <jdstrand> zyga: and thank you for merging the arg filtering branch-- it's been a long time coming :)
[13:18] <jdstrand> zyga: once snap-confine and snapd 2.0.10 land, that will allow me to fix a whole slew of policy bugs in 2.0.11+
[13:24] <dpm> dholbach, good work with summarizing the knowledge extracted from the playpen :)
[13:30] <ret2libc> hi! for what you know, has there been any attempt to create an opensource store/repo for snaps?
[13:31] <ogra_> ret2libc, not for ubuntu .. but see the mailing list, there is a discussion about stores on other distros
[13:32] <ogra_> (the "store" is just a webserver after all )
[13:32] <kyrofa> ret2libc, indeed, keep an eye on the mailing list, efforts are ongoing
[13:33] <zyga> jdstrand: I need to fix debian-8 builds by taking dpkg-vendor patches from alioth
[13:33] <zyga> jdstrand: please ignore debian-8 build failures for now
[13:34] <ret2libc> ogra_ kyrofa thanks, i'll have a look at it
[13:35] <stormchaser3000> is there a way i can get my application i have installed from .snap packages to use the system theme?
[13:35] <stormchaser3000> and is snapd available on debian 8?
[13:35] <zyga> stormchaser3000: not in debian 8
[13:36] <stormchaser3000> oh ok
[13:36] <zyga> stormchaser3000: system theme support is being explored, it's not easy due to gtk instability with theming
[13:36] <zyga> stormchaser3000: but we are exploring how to support this
[13:36] <zyga> stormchaser3000: and there are some technical bits that landed that make it possible to do pratical experiments now
[13:37] <stormchaser3000> does snapd work on OpenSUSE tubleweed?
[13:38] <dholbach> dpm, thanks
[13:42] <ogra_> if it doesnt yet, it will soon
[13:44] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/48/commits/0e690b310d1ce4fb772fab3085015897d62bf7d0
[13:44] <zyga> jdstrand: FYI, just in case I messed up something
[13:53] <kyrofa> sergiusens, ping
[14:19] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/50/files
[14:27] <ret2libc> can snap already run on other distros?
[14:27] <ogra_> ret2libc, yes, in several ( zyga has a list i think)
[14:28] <ret2libc> wow, that's cool! i really hope it will be adopted by others too
[14:30] <kyrofa> dholbach, I'd bring up the client cancellation (the broader issue you mentioned) in the channel, but there are too many conversations happening there right now :P
[14:30] <zyga> ret2libc: yes!
[14:30] <zyga> ret2libc: there are packages for fedora, arch and gentoo
[14:30] <zyga> ret2libc: I'm working on packages for suse
[14:31] <zyga> ret2libc: there's also a package in debian that propagates to ubuntu (snap-confine) and soon snapd too
[14:31] <zyga> ret2libc: and from debian and ubuntu to many other distributions
[14:31] <zyga> ret2libc: note that today snappy doesn't support confinement on distributions that don't use the ubuntu kernel, we are working on upstreaming everything and enabling other distributions to support the whole security
[14:31] <ret2libc> that's really nice, zyga!
[14:32] <zyga> ret2libc: if you have any questions about that I'm all ears :)
[14:32] <dholbach> kyrofa, yeah :)
[14:32] <dholbach> maybe a bug report would work better
[14:32] <ret2libc> zyga: i didn't you were changing the kernel to add features for confinement. aren't you using cgroups?
[14:32] <ret2libc> and apparmor?
[14:32] <kyrofa> ret2libc, among other things
[14:33] <zyga> ret2libc: we are using cgroups but that's very minor and it's not used most of the time
[14:33] <zyga> ret2libc: most of the patches are apparmor features that we developed to make this really solid
[14:33] <kyrofa> ret2libc, https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ if you're curious
[14:33] <zyga> ret2libc: those are being upstreamed and I'm looking at building supporting kernels for gentoo and arch
[14:33] <ret2libc> ahh that's nice! thanks kyrofa
[14:33] <zyga> ret2libc: but this work is still some time away
[14:34] <ret2libc> zyga: are those patches available?
[14:34] <zyga> ret2libc: of course :)
[14:34] <zyga> ttps://git.launchpad.net/~p-pisati/ubuntu/+source/linux/
[14:34] <zyga> https://git.launchpad.net/~p-pisati/ubuntu/+source/linux/
[14:35] <zyga> good people tell me that the apparmor features are posted to mainline but it's a process as you probably know
[14:35] <zyga> ret2libc: there are snappy branches there that contain everything required
[14:36] <zyga> ret2libc: it's really just the ba
[14:36] <zyga> ret2libc: it's really just the brand new apparmor features + corresponding configs that make snappy security work
[14:36] <zyga> ret2libc: seccomp and userspace apparmor bits are already upstream
[14:37] <plars> fgimenez: elopio: Hi, did you see the error I sent when I tried to run it from the branch?
[14:37] <ret2libc> zyga: i see. thanks a lot for those info
[14:40] <jdstrand> zyga, niemeyer: fyi, I'm taking a few minutes to clean up/expand docs/interfaces.md
[14:41] <niemeyer> jdstrand: Sweet
[14:41] <niemeyer> jdstrand: Btw, there's a problem we need to sort out with the network interface.. zyga is aware of it and looking into it, but it'd be nice if you two could discuss the issue too
[14:41] <jdstrand> niemeyer: see your inbox on cleaning up 'Usage'
[14:42] <niemeyer> jdstrand: Apparently even a boring network client right now depends on network-bind to do DNS, which kills the point of having the separation
[14:42] <jdstrand> that is surprising
[14:42] <jdstrand> is this an i386 thing?
[14:42] <jdstrand> cause that might be the socketcall issue
[14:42] <niemeyer> jdstrand: Would be good to get that fixed, either by understanding what's going on and fixing it, or by killing network-bind altogether if we cannot avoid the dependency
[14:43] <niemeyer> jdstrand: I don't know, zyga has the details
[14:43] <jdstrand> is there a bug?
[14:43] <niemeyer> zyga: ^
[14:43] <jdstrand> ok, zyga, please fill me in and with a reproducer
[14:43] <jdstrand> cause we've had the separation and its worked for a while. curious what changed
[14:47] <popey> jdstrand: wrt bug 1589671 - I have 2.0.9 and still see the issue, or a similar one - http://paste.ubuntu.com/17803532/
[14:47] <jdstrand> popey: that's a different issue
[14:48] <popey> \o/
[14:48] <popey> I love finding these and keeping you in work :)
[14:49] <popey> do you need me to file a bug for it jdstrand ?
[14:50] <jdstrand> yes please. add the snapd-interface tag and the udev denials
[14:52] <popey> okay, thanks.
[14:54] <popey> ok, filed bug 1595987
[14:55] <jdstrand> thanks
[15:03] <gouchi> same error here : https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1570860
[15:04] <gouchi> about /run/udev/data/c**
[15:05] <arcade_droid> I created a suggestion on Steam's Github to start using Snaps or flatpaks to distribute games in Steam. https://github.com/ValveSoftware/steam-for-linux/issues/4512 Now, the question is, is it possible to partially update a snap to avoid re-downloading 8+GB of data to patch one, simple thing?
[15:05] <arcade_droid> For example.
[15:06] <popey> gouchi: ooh, you're looking at love2d?
[15:06] <popey> awesome, I had a play with that a while back but not looked recently
[15:06] <popey> would... "love" to see that snapped
[15:07] <gouchi> popey: another project ;-)
[15:07] <popey> :)
[15:07] <popey> jdstrand: did I need to file a bug about 32-bit binaries, or was that a 'wontfix'?
[15:07] <gouchi> popey: but I like also love2d ;-)
[15:07] <jdstrand> popey: there is a bug already. it is likely won't fix
[15:08] <popey> :(
[15:08] <popey> no wine in snaps
[15:08] <popey> that's a shame, having wine/libwine would be a neat way to package up some windows apps (or games) in the store
[15:09] <ret2libc> zyga: what are exactly those new apparmor features that you want to add?
[15:09] <zyga> ret2libc: you'd have to go through the patches, there's quite a lot I've heard
[15:10] <zyga> niemeyer, jdstrand: I didn't file the bug for this yet
[15:10] <jdstrand> popey: wine doesn't mean 32bit only
[15:11] <zyga> jdstrand: and FYI, I don't quite know what the root problem is, I tried using spread (a go binary so it might be go specific) and it happily created variou sockets and tried to bind them on startup
[15:11] <zyga> jdstrand: let me pull the strace log and report this
[15:11] <niemeyer> zyga: Can we please get a bug with a reproducer?
[15:11] <niemeyer> zyga: Otherwise it'll fall through the cracks
[15:12] <zyga> niemeyer: yep, just doing that now
[15:13] <niemeyer> zyga: Thanks!
[15:13] <arcade_droid> Not sure if my previous message managed to send itself, my connection is a bit wonky. I'll ask again. I created a suggestion on Steam's Github to start using Snaps or flatpaks to distribute games in Steam. https://github.com/ValveSoftware/steam-for-linux/issues/4512 Now, the question is, is it possible to partially update a snap to avoid, for example, re-downloading 8+GB of data to patch one, simple thing?
[15:13] <popey> jdstrand: only 32-bit wine can run 32-bit windows apps, only 64-bit wine can run 64-bit windows apps, and not 32-bit ones AIUI
[15:13]  * popey is getting deja vu
[15:13] <popey> have we had this conversation already? :)
[15:15] <jdstrand> popey: sure. my point is that you can still ship 64bit wine to run 64bit wine apps
[15:15] <jdstrand> popey: and 32bit wine to run 32bit wine apps
[15:16] <jdstrand> architectures just needs to match
[15:16] <popey> so 32-bit wine will work on ubuntu-core i386? but not on ubuntu-core amd64?
[15:16] <jdstrand> I understand that doesn't address 32bit wine on 64bit machine, but I think there is still good things to be had
[15:16] <jdstrand> popey: sure, why not?
[15:17] <popey> we're in circles :)
[15:17] <popey> my problem is that 32-bit wine doesn't run on amd64 ubuntu-core
[15:17] <popey> and you said earlier that's a wontfix?
[15:18] <jdstrand> popey: you were too general with this statement: "no wine in snaps"
[15:18] <popey> hah, okay
[15:18] <jdstrand> popey: that is not accurate. you *can* have wine if wine matches the arch
[15:19] <popey> ok, so a more specific question would be "do we support 32bit binaries in 64-bit host ubuntu-core?"
[15:19] <popey> this isn't a wine specific issue is it?
[15:19] <popey> (so skype i386 on amd64 would be equally problematic)
[15:19] <zyga> jdstrand, niemeyer: https://bugs.launchpad.net/snappy/+bug/1595993
[15:19] <jdstrand> this is a kernel limitation with seccomp
[15:20] <fgimenez> plars, looking into it now
[15:21] <ret2libc> zyga: ok will do!
[15:21] <zyga> jdstrand: I think that bug above requires some deep dive into go to understand
[15:21] <zyga> jdstrand: but I wonder if there's something we could do with seccomp filtering to let it be
[15:22] <zyga> jdstrand: but I don't know, looks terribly like those very carefully profiled security things that only allow a given sequence of syscalls
[15:22] <jdstrand> zyga: ok-- it seems it is pretty clearly wanting to use socket. not sure what the problem is?
[15:22] <zyga> jdstrand: nothing in the code does this
[15:22] <zyga> jdstrand: it's some startup thing in go or maybe libc
[15:22] <jdstrand> something in the code is doing it :)
[15:22] <zyga> jdstrand: and this means that all the software will require network-bind in effect
[15:23] <jdstrand> but that's not true
[15:23] <zyga> jdstrand: not explicitly, this might be something each executable starts to do
[15:23] <zyga> jdstrand: I'll dig around, I wanted to report this first
[15:23] <jdstrand> there are plenty of applications that don't need network-bind to use the network
[15:24] <jdstrand> it might be a go thing, and yes, we might be able to do arg filtering somehow
[15:25] <jdstrand> zyga: why is this 'high'?
[15:26] <jdstrand> zyga: it only affects go and people can always specify 'network-bind' which is autoconnected
[15:26] <jdstrand> I'm not saying it shouldn't be fixed, I'm saying that it probably shouldn't trump other high priority work
[15:28] <zyga> jdstrand: I set it to high to investigate what the cause is; if there's something potentially causing many programs to require network-bind without knowing ti
[15:28] <zyga> it*
[15:28] <jdstrand> zyga: so, this application is very clearly binding to a port on the loopback: bind(4, {sa_family=AF_INET6, sin6_port=htons(0)...
[15:28] <jdstrand> that says that network-bind should be used
[15:29] <jdstrand> most programs don't need that
[15:29] <jdstrand> a go program might, but, so?
[15:29] <jdstrand> anyway, yes, it is worth investigating
[15:29] <zyga> jdstrand: but it's not doing this in the go code, there's no bind there anywhere
[15:29] <zyga> jdstrand: I want to check if this is endeminc to go runtime
[15:29] <jdstrand> but I'm not worried by this
[15:30] <jdstrand> it might be. go does all kinds of stuff
[15:30] <aatchison> Heyo
[15:30] <jdstrand> if you look at netstat -atuvpn, you should see it is listening on a port
[15:30] <aatchison> I'm getting the encrypted user directory apparmor error!
[15:30] <jdstrand> (one chosen by the kernel)
[15:31] <jdstrand> aatchison: that is on the verge of being fixed with the pending snap-confine upload
[15:31] <aatchison> cool
[15:31] <aatchison> how soon:P I just need a workaround if I can get it
[15:31] <aatchison> Can't tell what's going on
[15:31] <jdstrand> aatchison: https://bugs.launchpad.net/snappy/+bug/1574556 has a workaround
[15:32] <aatchison> awesome, thanks
[15:38] <popey> jdstrand: okay, thanks for clarifying :)
[15:38] <popey> I promise not to ask you about 32 bit again ㋛
[15:40] <jdstrand> hehe
[15:40]  * jdstrand -> errand
[15:48] <zyga> jdstrand: the issue is now well-understood
[15:48] <zyga> jdstrand: I'll look at it next week, I want to focus on bind mount support and next release of snap-confine
[15:56] <zyga> jdstrand: before you EOW today, can you weight in on https://github.com/snapcore/snap-confine/pull/50 please?
[16:19] <slangasek> zyga: fyi, snap-confine 1.0.33-1 has been accepted through Debian NEW now (including source package rename), so should also find its way into yakkety soon
[16:19] <slangasek> oh
[16:19] <slangasek> except that requires a merge
[16:19] <slangasek> er, no it doesn't, because it's a new source package name so it'll just take over the binary name
[16:20] <joc_> kyrofa: hi, do you how to easily go about setting default_plugin_output correctly in the list plugins tests of snapcraft? (after adding new plugin)
[16:20] <kyrofa> joc_, hahaha, aren't those lovely tests?
[16:21] <joc_> indeed, super lovely :)
[16:25] <joc_> kyrofa: do i need to set some environment variable on my local console to make sure i have correct output width or something?
[16:26] <kyrofa> joc_, honestly what I do is I copy/paste the "actual" output
[16:26] <zyga> slangasek: that's great news, thank you
[16:26] <kyrofa> joc_, watch the test fail, steal the output
[16:26] <kyrofa> = 100% useless test
[16:47]  * zyga -> dinner
[16:49] <plars> fgimenez: so running from the branch still doesn't work for me, but running uner checkbox I'm seeing a lot better results running on an allsnaps image vs. classic
[16:52] <fgimenez> plars, great! it would be nice anyway to have better logs in both cases, i'm not able to reproduce your error http://paste.ubuntu.com/17809595/ which version of go are you using?
[16:54] <plars> fgimenez: 1.6.1
[16:56] <fgimenez> plars, that should work.. are you executing from the gopath (not from a symlinked dir)? iirc we needed that when building from branch, not the case anyway
[16:57] <plars> fgimenez: hmm, no I'm not sure what you mean by symlinked dir, I was running from the dir of my checkout. Which I guess go just totally ignores. As soon as the run with checkbox finishes, I'll switch to the one it pulled into my GOPATH and try from there
[17:00] <fgimenez> plars, ok let me know how it goes
[17:01] <sergiusens> kyrofa pong?
[17:02] <kyrofa> sergiusens, I was going to ask you a question about the qmake plugin, but I asked in the PR instead
[17:03] <joc_> kyrofa: please please please dont land any other plugins before me, i dont want to have rebase and do that all again :p
[17:03] <kyrofa> joc_, muhahaha
[17:03] <kyrofa> joc_, I've done it twice now, stop whining!
[17:04] <kyrofa> sergiusens, we really need to toast those list_plugins tests
[17:05] <sergiusens> kyrofa we do, but they got a whole lot more special now, didn't they ;-)
[17:13] <sergiusens> elopio is the triggered on https://github.com/ubuntu-core/snapcraft/pull/566 running?
[17:17] <elopio> sergiusens: no, we are redeploying jenkins again.
[17:17] <jdstrand> zyga: done
[17:18] <elopio> sergiusens: like 30 minutes to go.
[17:21] <sergiusens> elopio yay
[17:21] <sergiusens> elopio doesn't matter as I added a comment to that PR for kyrofa ;-)
[17:22] <sergiusens> elopio just interested in the adt and examples on that one as snapcraft.internal was touched. If it fails and units pass we have more work to do ;-)
[17:23] <sergiusens> zyga how is it going with the font interface, do you know?
[17:27] <elopio> sergiusens: yes, when the branch is ready kyrofa can run adt or examples locally :) Or I can help, I have plenty of testbeds around.
[17:27] <elopio> jenkins might be ready earlier.
[17:52] <aatchison> Would anyone be interested in helping me hack on mycroft snap today?
[17:52] <zyga> sergiusens: we have the content sharing now, with somewhat different design (only one content can be consumed at a time)
[17:53] <zyga> sergiusens: with some more work and a test case we should be able to use that to share classic fonts
[17:54] <zyga> sergiusens: I'm looking at finalizing the snap-confine side of content sharing now
[17:55] <zyga> sergiusens: do you have a snap that can be used to test this?
[17:57] <zyga> note that we don't have the global sharing part yet (we need to allow all canonical-published slots to work this way)
[17:57] <kyrofa> elopio, sergiusens that branch is ready for another look. Do I need to run something locally, then?
[17:58] <sergiusens> zyga there are non, maybe start big and use kde? :-P
[17:58] <elopio> kyrofa: maybe ./runtests.sh snaps --skip-install
[17:58] <elopio> if you have a xenial vm, you could run with the install using --ip localhost.
[17:59] <kyrofa> elopio, I do, I'll use it
[17:59] <sergiusens> aatchison hey, so where are you at with this?
[17:59] <zyga> sergiusens: kde would be nice but I'd rather have others build something I can split
[17:59] <kyrofa> elopio, though it's not localhost. Can I use user@ip instead?
[18:00] <elopio> kyrofa: I think that the user is hardcoded to be ubuntu. There's a bug for that.
[18:00] <kyrofa> elopio, :(
[18:00] <aatchison> I'm having some issues all around, but I can build a snap. I've just included speech-dispatcher as a stage-package. I could use some help with the pulseaudio interface stuff, as I don't see the interface existing
[18:01] <kyrofa> I knew making a VM without ubuntu was dumb
[18:01] <kyrofa> I'll just --skip-install
[18:01] <aatchison> I finally figured  out that I needed to use the app armor work around, because I have an encrypted home directory
[18:02] <elopio> kyrofa: well, actually making the testbed assuming that ubuntu was the user was dumb.
[18:02] <aatchison> https://github.com/MycroftAI/snapcraft-mycroft-core
[18:02] <aatchison> there is my yaml, if one would like to try
[18:02] <kyrofa> elopio, heh
[18:02] <elopio> kyrofa: but on your vm you can clone, and run from there. I think you will have to mkdir /home/ubuntu
[18:02] <kyrofa> elopio, I seem to remember there being issues using snapd from newly-created users
[18:03] <elopio> please file bugs for anything that makes that experience awful. I'll fix them next week.
[18:03] <sergiusens> elopio I've updated #590
[18:04] <sergiusens> aatchison but does it work with --devmode, pulseaudio integration that is?
[18:05] <aatchison> I'm getting this error: ALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf
[18:05] <kyrofa> elopio, sergiusens crap. Ran out of hard drive space
[18:06] <aatchison> I now see the pulseaudio interface when I run snap interfaces though, which didn't happen before
[18:06] <sergiusens> aatchison so pulseaudio != alsa (one may use the other, but they are not the same thing)
[18:07] <sergiusens> aatchison forget the interface, is that the error you get in devmode?
[18:07] <aatchison> yeah, I thought that pulse would handle the alsa stuff
[18:07] <elopio> sergiusens: I think it is "inexistent" or "unexisting", not "inexisting". kyrofa can confirm.
[18:07] <aatchison> yeah, installed with devmode
[18:07] <sergiusens> in other words, don't paint the house if the cement has not dried yet ;-)
[18:08] <sergiusens> elopio yeah, I sort of knew that but kept it :-P I can change if needed
[18:08] <sergiusens> elopio wait, non-existing is valid english ;-)
[18:08] <sergiusens> oh, test name :-P
[18:09] <kyrofa> sergiusens, elopio nonexistent
[18:09] <elopio> kyrofa: I use unexisting. Is that wrong?
[18:10] <sergiusens> kyrofa elopio inexisting is also valid, just checked the dictionary ;-)
[18:10] <kyrofa> Hahaha
[18:10] <kyrofa> Fine fine, they're all valid. Stupid english
[18:10] <kyrofa> Just another reason to learn spanish I guess
[18:11] <zyga> kyrofa: I'm in a bind now
[18:11] <kyrofa> zyga, what's up?
[18:11] <zyga> kyrofa: how come I learned english and not spanish as a kid
[18:11] <kyrofa> Hahaha
[18:11] <kyrofa> Yeah no kidding
[18:12] <zyga> kyrofa: just reacting to your comment above :)
[18:12] <kyrofa> zyga, does learning english make it harder to learn something else?
[18:12] <zyga> kyrofa: yes, very
[18:12] <kyrofa> I can imagine
[18:12] <zyga> it made me lazy
[18:12] <zyga> all the books and movies are in english
[18:13] <sergiusens> elopio kyrofa there, changed it completely so no grammar flame war can happen
[18:13] <elopio> :)
[18:14] <sergiusens> aatchison oh, why would you need access to that; the core image where this runs on top of doesn't have alsa
[18:14] <sergiusens> zyga ideas for that? ^
[18:14] <aatchison> ahh, I see. I know that were is an alsa snap, but...
[18:15] <sergiusens> aatchison no there is no alsa snap, just pulseaudio
[18:15] <sergiusens> aatchison what code is trying to do this and why?
[18:16] <aatchison> mimic, out TTS program, is trying to use an alsa audio device. I don't know why it needs to access that file though
[18:16] <aatchison> There is pulse audio support in mimic as well
[18:17] <zyga> sergiusens: alsa is in the kernel, it's always there but confinement refuses access
[18:18] <zyga> aatchison: do you have the denial log?
[18:18] <zyga> aatchison: and does the code you are working with support pulseaudio?
[18:19]  * zyga is super sleepy
[18:19] <aatchison> http://paste.ubuntu.com/17814234/
[18:19] <aatchison> there is the audit log
[18:19] <aatchison> yeah, it does support pulse audio
[18:19] <zyga> looking
[18:20] <aatchison> thanks:)
[18:20] <zyga> aatchison: yes, that is clearly alsa
[18:20] <sergiusens> zyga his application fails as it wants to access alsa's config
[18:21] <zyga> sergiusens: those are harmless
[18:21] <zyga> aatchison: does this application support pulseaudio as a sound sink?
[18:21] <sergiusens> zyga in any case, that isn't a denial in devmode no is it?
[18:21] <aatchison> I...believe so
[18:21] <sergiusens> says ALLOWED
[18:21] <aatchison> let me check
[18:22] <zyga> sergiusens: that config file is probably just not there
[18:22] <zyga> aatchison: you need libpulse or similar in your snap
[18:22] <aatchison> ahh, stage-packages?
[18:22] <zyga> aatchison: yes
[18:23] <aatchison> awesome, ok
[18:23] <aatchison> I'll pop that in there
[18:23] <zyga> aatchison: and you need o use the pulseaudio plug on that application
[18:23] <aatchison> like so?:  plugs: [pulseaudio]
[18:23] <aatchison> under apps:
[18:24] <zyga> aatchison: uner the app that needs it
[18:24] <zyga> aatchison: pastebin the snapcraft yaml somewhere
[18:24] <aatchison> k, I think I have that bit right
[18:24] <aatchison> k
[18:24] <zyga> sergiusens: we need something like jsbin for snapcraft.yaml's
[18:24] <kyrofa> sergiusens, qmake look okay, then?
[18:24] <zyga> sergiusens: let people paste editable yaml
[18:24] <zyga> sergiusens: and others to edit that and share
[18:26] <aatchison> http://paste.ubuntu.com/17814586/
[18:26] <aatchison> There it is, didn't add lib pulse yet
[18:27] <wligtenberg> ok, I am here as well aatchison :)
[18:27] <sergiusens> zyga http://linkode.org/  seems to be down, but that is what you want
[18:27] <aatchison> wahoo!
[18:27] <wligtenberg> I was already lurking here :)
[18:27] <aatchison> hehe
[18:28] <aatchison> I'm swapping pulse sinks with pavucontrol while mimic is running, seems fine
[18:28] <aatchison> I'll add that lib
[18:29] <arcade_droid> > Papers, please!
[18:29] <wligtenberg> aatchison, I installed it, which command to run it? mycroft-core.cli-client?
[18:30] <aatchison> mycroft-core.mimic -t "hello" will run mimic
[18:30] <sergiusens> kyrofa did the --skip-install tests all work ok?
[18:30] <aatchison> .messagebus start, .skills-client start , .speech-client start or .cli-client start
[18:30] <zyga> aatchison: so alsa is a nogo, we could add an alsa interface but the problem is that alsa is harder and more limited and also, exclusive, so you'd kill all sound on the host
[18:30] <kyrofa> sergiusens, still running, I'll ping you. But the code looks okay?
[18:30] <aatchison> ahh, ok
[18:31] <wligtenberg> trying mimic results in: failed to create user data directory. errmsg: Permission denied
[18:31] <aatchison> I'm trying with the pulse lib installed
[18:31] <aatchison> oh, you have to use the workaround for encryped home dires
[18:31] <sergiusens> kyrofa yeah, all good
[18:31] <kyrofa> Awesome
[18:31] <aatchison> https://bugs.launchpad.net/snappy/+bug/1574556
[18:31] <wligtenberg> indeed, my home is encrypted
[18:34] <wligtenberg> aatchison: now it does a core dump because it cannot access /usr/share/alsa/alsa.conf
[18:34] <aatchison> ya
[18:34] <aatchison> try the mycroft stuff :D
[18:35] <aatchison> if I could at least get the thing to run with cli....
[18:35] <wligtenberg> that is the alsa issue, that was mentioned just now?
[18:35] <aatchison> yeah
[18:35] <aatchison> I'm asking if there is a pulse only flag for mimic
[18:36] <aatchison> added: stage-packages: [libpulse0] , no dices
[18:36] <wligtenberg> aatchison, I get a permission denied on the python dist-packages but is is still referring to the snapcraft parts directory...
[18:38] <aatchison> hrm
[18:38] <aatchison> yeah, I had that happen before
[18:38] <aatchison> I'm not sure why
[18:40] <wligtenberg> aatchison: do you remember how you fixed it? :)
[18:40] <kyrofa> sergiusens, elopio what on earth is this? http://pastebin.ubuntu.com/17815416/
[18:41] <kyrofa> Also, sorry about the lack of line breaks. /me looks at elopio
[18:41] <kyrofa> Oh there it is: "Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved"
[18:42] <aatchison> um, no.. i had that problem before I reinstalled my OS, now I don't have it anymore
[18:42] <kyrofa> Dangit... now I have to start that suite all over again?!
[18:42] <aatchison> I pushed a new commit to the git
[18:43] <elopio> kyrofa: run just yours.
[18:43] <elopio> --filter
[18:43] <wligtenberg> snapping the core
[18:43] <elopio> and the line breaks were solved in jenkins. I'm not sure I can do anything for the terminal. /me tries...
[18:44] <sergiusens> kyrofa network error or our test just broke and we need to update deps, not related to your stuff
[18:44] <sergiusens> elopio kyrofa echo interpret escape chars
[18:44] <kyrofa> sergiusens, elopio both qt examples run fine
[18:44] <elopio> ship it!
[18:45] <elopio> kyrofa: please file a bug for that maven one so I don't forget to debug it.
[18:45] <kyrofa> Yay! sergiusens sound okay?
[18:46] <sergiusens> kyrofa elopio echo -e http://pastebin.ubuntu.com/17815693/
[18:46] <kyrofa> sergiusens, ah! Nice
[18:46] <sergiusens> kyrofa yeah, should be good; elopio find the `echo -e` equivalent for `print` in python
[18:47] <aatchison> ok, compiling mimic with the --with-audio=pulseaudio flag, different results:D
[18:47] <kyrofa> Shipped
[18:47] <elopio> kyrofa: but wait, when you see the tests running they print newlines, right?
[18:48] <kyrofa> elopio, as they're running, yes. But not for errors
[18:48] <sergiusens> elopio kyrofa standup, come on!
[18:48] <elopio> sergiusens: omw.
[18:48] <kyrofa> Haha, sorry, got distracted pressing the button
[18:49] <kyrofa> Hey wait a minute... sergiusens isn't even here
[18:49] <sergiusens> kyrofa :-D
[18:49] <kyrofa> Jerk
[18:51] <wligtenberg> aarchison, mmm to be sure I installed all updates and rebooted... no luck...
[18:52] <sergiusens> zyga http://linkode.org/ is up again
[18:52] <wligtenberg> anybody else here, that would know why it tries to find a python lib from the parts directory where it got built?
[18:53] <aatchison> dang
[18:55] <wligtenberg> Let me set up a fresh 16.04 VM then
[18:56] <wligtenberg> this is my dev machine, that got upgraded from 14.04, so it might have some old cruft in the way
[18:57] <aatchison> that's actually the story of my last machine
[18:58] <aatchison> o *snap I think I might have build it with pulse only support, about to push a new commit
[18:59] <wligtenberg> lol, o snap :)
[18:59] <aatchison> hehe
[19:00] <aatchison> it's so close, I've seen it nearly run lol
[19:00] <aatchison> next ... serial port stuff :P
[19:02] <aatchison> mimic with pulse worked!
[19:02] <aatchison> one dwon
[19:04] <wligtenberg> ah, cool!
[19:04] <wligtenberg> installing the vm, haven't been much help yet :)
[19:05] <aatchison> hehe
[19:05] <aatchison> well, since it takes so much time to find out that some bits are broken, if it builds at all, the more people building the better!
[19:06] <aatchison> I updated the mycroft-core branch to use the correct cli entry point, if that will fly, we have mycroft ala cli
[19:07] <wligtenberg> aatchison: but from the version numbering it seems this was still using 0.6.x instead of 0.7
[19:10] <aatchison> ahh, yeah, it's actually not building from a release anymore
[19:10] <aatchison> I had to modify mycroft-core
[19:10] <aatchison> so, it's on the branch feature/snapcraft
[19:11] <wligtenberg> ah, I see
[19:11] <wligtenberg> so no popey yet?
[19:11] <aatchison> actually, it can have that
[19:11] <aatchison> The mimic folks are working on a release with the precompiled voice
[19:12] <wligtenberg> L) did you hear the latest Ubuntu UK podcast?
[19:12] <aatchison> so we don't have to cludge in this giant, slow flitevox file anymore
[19:12] <wligtenberg> snapcrafting again
[19:15] <aatchison> ok, I effed it up
[19:15] <aatchison> clean the pull!
[19:15] <popey> you making a mycroft snap?
[19:15] <aatchison> made another commit. I had my entry point all wring
[19:16] <aatchison> yuuup:P
[19:16] <popey> sweet
[19:16] <popey> i had a go at that
[19:16] <popey> not straightforward
[19:16] <aatchison> yeah, kinda complex
[19:16] <aatchison> I just got mimic working though!
[19:17] <aatchison> so, at the very least we can snap that up and your voice can live in snapspace
[19:19] <wligtenberg> aatchison, do I need to fully rebuild it? (it is still building the first run...)
[19:20] <aatchison> snapcraft clean
[19:20] <aatchison> that will clean all the way to the pull stage
[19:20] <aatchison> snpacraft clean -s build if you only want to clean to the build stage, etc
[19:22] <wligtenberg> ok, running snapcraft (again)
[19:23] <aatchison> it's running! no mimic voice for some reason, but hey
[19:24] <wligtenberg> ah, can't wait
[19:30] <aatchison> sweet
[19:31] <sergiusens> elopio why does this https://github.com/ubuntu-core/snapcraft/pull/590 not have examples in it, did you disable them?
[19:31] <sergiusens> elopio and 'waiting for status' for a while
[19:32] <elopio> sergiusens: jenkins is still not up, I'm testing it.
[19:32] <elopio> it shows autopkgtest because we have it configured in the github settings as required.
[19:33] <aatchison> ok, anything special that I might have to do to enable network connectivity?
[19:33] <wligtenberg> aatchison: did mimic work for you? I get an xcb_connection_has_error, shm_open() failed: permisson denied
[19:33] <aatchison> did you try sudo snap install --devmode ?
[19:33] <wligtenberg> ah, nope
[19:35] <wligtenberg> ok, that helps, I got an hello from mimic
[19:36] <aatchison> aha! plugs , network
[19:37] <sergiusens> aatchison network fr client side things or network-bind for servery ones
[19:37] <aatchison> so glad to be at the "it's running at least" stage
[19:38] <sergiusens> kyrofa question about https://github.com/ubuntu-core/snapcraft/pull/580/files
[19:38] <aatchison> client side to reach the net
[19:38] <sergiusens> kyrofa seems the primed_set is not really used for anything now, is it?
[19:38] <aatchison> but, actually we will need server side too
[19:38] <kyrofa> sergiusens, true, it doesn't need to exist, but I thought the need might arise to actually track them so I made it
[19:39] <kyrofa> sergiusens, not necessary though
[19:39] <sergiusens> kyrofa ok, was really confused on how primed_dependencies made things work
[19:39] <kyrofa> Hahaha, just the extra "if" is what solves the problem
[19:39] <sergiusens> kyrofa but it was actually the elif :-P
[19:39] <kyrofa> Yeah... if it's misleading I'll remove it
[19:39] <sergiusens> kyrofa it is fine
[19:39] <wligtenberg> aatchison: ok, I can start the messagebus and cli-client, but it doesn't seem to be doing anything
[19:40] <kyrofa> sergiusens, okay
[19:40] <aatchison> make sure you start the skills too
[19:40] <aatchison> bus -> skills -> client
[19:40] <wligtenberg> ah, I thought the cli-clinet did that as well
[19:41] <wligtenberg> aatchison: speechclient fails
[19:41] <aatchison> yeah, it's looking for pocketsphinx still
[19:42] <sergiusens> elopio http://162.213.35.179:8081/ghprbhook/  (issue_comment and pull_request) has a "is timing out" message on github
[19:42] <elopio> sergiusens: yes, jenkins is not up yet :D
[19:42] <aatchison> but cli is giving me a message that device isn't paired, but gives no code. Wondering if it can reach the server
[19:43] <elopio> give me a few minutes. I got one green examples execution. Waiting for the autopkgtest one before enabling.
[19:43] <wligtenberg> aatchison: yeah, I also get that, would that also prevent it from going into listening mode?
[19:43] <aatchison> it should still be able to detect the wakeword locally, it needs pocketshpinx though
[19:43] <aatchison> it should also be able to operate with cli only
[19:45] <wligtenberg> and how would I then interact with it?
[19:51] <plars> Is there a good solution to running a snap, but not have it think it's running as root? Something I'm working on detects that and helpfully exits telling me I shouldn't run it as root
[19:52] <plars> I don't see anything in the snapcraft schema that allows this to be specified, but then I also wondered about whether it would even have access to $SNAP_DATA and things like that
[19:52] <kyrofa> plars, I'm afraid not. Many projects do that unfortunately, for reasons that are not valid within a snap
[19:52] <kyrofa> plars, however, in my experience (two projects, apache and php-fpm) there are ways to say "please do as I ask"
[19:53] <kyrofa> plars, indeed, SNAP_DATA is owned by root
[19:54] <plars> kyrofa: a --just-do-it-dont-warn-me flag? :) I'll check, thanks!
[19:54] <aatchison> wligtenberg, you should be able to just type into the cli whatever question you like
[19:55] <aatchison> eg. 2 + 2
[19:55] <aatchison> eg. what's the weather
[19:55] <kyrofa> plars, yeah, something like --let-me-shoot-myself-in-the-foot-already
[19:55] <aatchison> but until it pairs, it will just ask you to pair
[19:55] <wligtenberg> aatchison: ok, that issue with no access to python libs, was also because I hadn't used dev-mode when installing. That does mean (if I understand it correctly) that it actually does a weird thing, because it tries to access the python lib from where it is built...
[19:55] <kyrofa> plars, for php-fpm it was -R
[19:55] <aatchison> ahh, maybe that's the del
[19:55] <wligtenberg> aatchison: indeed it asks me to pair :)
[19:56] <aatchison> I'll try that
[19:56] <aatchison> yeah, I have to check the server to see if it's actually trying to connect
[19:56] <wligtenberg> aatchison: that's the del?
[19:56] <wligtenberg> at least now I can work on my normal machine, instead of a vm
[19:57] <aatchison> *deal
[19:57] <wligtenberg> ah, ok :)
[19:57] <monsterjamp> Hello
[19:57] <aatchison> hello!
[19:58] <wligtenberg> hi
[20:00] <monsterjamp> I'm having trouble understanding how the snapcraft.yaml files are formatted and all the examples for the snapcraft.yaml files use make or autotools without passing any arguments. So my question is how would a snapcraft.yaml file look like using make with a target. e.g. on bash I would type "make release"
[20:00] <wligtenberg> wouldn't dev-mode also give it access to networking? I thought it would basically remove isolation
[20:01] <aatchison> well, it's not hitting the server for sure, that I ca nsee
[20:01] <aatchison> hmm
[20:01] <kyrofa> monsterjamp, does `make` not use the `release` target?
[20:01] <kyrofa> monsterjamp, regardless, you can use the `make-parameters` option
[20:01] <kyrofa> monsterjamp, see `snapcraft help make` for more information
[20:02] <kyrofa> monsterjamp, but in most cases, it's just make -> make install, so that's what snapcraft does out of the box
[20:03] <monsterjamp> I see, I haven't tried to make a snap yet, I was just following the "tour" and the tour seemed to avoid my question.
[20:03] <kyrofa> monsterjamp, ah ha. Well there you go!
[20:03] <monsterjamp> :D
[20:03] <kyrofa> monsterjamp, similarly, cmake and autotools have `configflags`
[20:04] <kyrofa> monsterjamp, you can run `snapcraft help <plugin>` to learn more about any of them
[20:04] <monsterjamp> I see, thanks for the help. I'm gonna try to make a snap and see how it goes.
[20:05] <kyrofa> monsterjamp, any time! Let us know if you have any questions :)
[20:05] <popey> feel free to poke us if you have questions
[20:06] <wligtenberg> popey, quick question. installing with --dev-mode removes all isolation, correct?
[20:06] <popey> you can also do "confinement: devmode" in the yaml
[20:06] <kyrofa> My gift to the world (mainly sergiusens): http://pastebin.ubuntu.com/17820191/
[20:07] <popey> but i dont think it removes all isolation,no
[20:07] <monsterjamp> Also I noticed that installing snaps doesn't need sudo, is that intentional?
[20:07] <wligtenberg> ok, so would we still have networking isolation?
[20:07] <wligtenberg> mycroft has issues calling home :)
[20:08] <aatchison> kyrofa, hahaha
[20:08] <kyrofa> aatchison, I have a recursion problem somewhere :P
[20:08] <aatchison> sure looks pretty though
[20:09] <elopio> hum, I thought that it was slow building the snaps, when it's actually slow executing snap remove :/
[20:11] <kyrofa> wligtenberg, devmode snaps still get installed in /snap/ and thus are isolated in that manner, but it doesn't require interfaces anymore
[20:11] <kyrofa> wligtenberg, so it's completely unconfined
[20:11] <wligtenberg> kyrofa, so no limitations to network access then?
[20:11] <kyrofa> wligtenberg, indeed
[20:12] <wligtenberg> ok, aatchison, so no confinement issue then...
[20:12] <aatchison> hmm
[20:12] <aatchison> I added the network and network-bind plugs, and they are interfacing I can see
[20:13] <kyrofa> wligtenberg, aatchison but you still have the fact that you're in an isolated container, with your dependencies bundled
[20:13] <kyrofa> isolated = dependencies bundled in that case, I guess
[20:17] <kyrofa> sergiusens, figured out my problem
[20:23] <aatchison> wligtenberg, I added the home plug, so mycroft can create those folders at least
[20:23] <wligtenberg> good idea, I have to go now, but I will look at it later. You can always ping me on slack if you want me to check something
[20:25] <aatchison> cool:) thanks for helping me check this out!
[20:59] <sergiusens> kyrofa do  tell
[20:59]  * sergiusens i going type slowly as he has popcorn grease on his other hand
[21:05] <sergiusens> elopio snapcraft/tests/test_yaml.py in the define PR, what gives?
[21:06] <elopio> sergiusens: sorry, I need more information. What is your question?
[21:10] <monsterjamp> So snapcraft makes the snap and I can install it but when I try to run my program via bash it returns "Bad system call"
[21:11] <monsterjamp> snapcraft.yaml: http://paste.ubuntu.com/17823434/ makefile: http://paste.ubuntu.com/17823441/
[21:11] <elopio> sergiusens: oh, I see. For some reason in #590 you removed the subversion lines: https://github.com/ubuntu-core/snapcraft/pull/590/files#diff-8dac611ed32f1d2128779826f0337076L207
[21:13] <sergiusens> elopio is it ok to readd it in this one?
[21:14] <elopio> sergiusens: sure, why not.
[21:14] <sergiusens> elopio this was me trying to work from the tablet and settling with vimdiff
[21:15] <sergiusens> elopio also confusing is merging versus rebasing, the panes swap :-P
[21:17] <elopio> sergiusens: no harm done.
[21:18] <elopio> sergiusens: speaking of confusing, I'm making a mess with this store integration test. It will only be able to run from an ubuntu-core branch, so when we land PRs. And I in order to test it, I need to propose two PRs. Ignore me for now.
[21:19] <josepht> monsterjamp: the Debugging section here might help: https://developer.ubuntu.com/en/snappy/guides/security/
[21:35] <monsterjamp> I think I'm gonna make a really program and see if I can make a proper snap of it
[21:39] <sergiusens> elopio I guess this needs an update branch to at least trigger adt https://github.com/ubuntu-core/snapcraft/pull/600
[21:40] <elopio> sergiusens: it sucks that we can't run update in other people's branches.
[21:40] <elopio> I guess that would be too much power. But I would trust you to use it for good :)
[21:47] <sergiusens> elopio well I am more for just using the main project when its a team thing
[21:48] <sergiusens> elopio just like I'd push to ~snappy-dev on launchpad for the team to be able to take over if required
[21:51] <sergiusens> elopio example tests failed now... so soon, so fast
[21:51]  * sergiusens connects to the vpn
[21:52] <sergiusens> elopio I haven't seen the openstack "too many security groups" error in a while!
[21:53] <elopio> maybe I didn't recover the cleanup job properly.
[21:58] <monsterjamp> Well I was able to get a simple snap to build/run
[22:00] <elopio> damn, yes, that's not doable in lgw01. I will need more bash superpowers to parse the output there.
[22:11] <monsterjamp> I can't get my other project to work though
[22:11] <monsterjamp> When I run it via bash it still says "Bad system call
[22:17] <monsterjamp> I really wish there was a good offline makefile example they had
[22:18] <monsterjamp> Why does every example need a remote :/
[22:37] <monsterjamp> People on ##linux are saying I'm getting "Bad system call" since the snap I'm making uses a different glibc version than what's supported by my kernel
[23:03] <monsterjamp> So I figured it out, I completely missed the part where you have to add interfaces for the snaps to work
[23:08] <sergiusens> monsterjamp might want to install your snap with --devmode to play around a bit
[23:09] <monsterjamp> What does devmode allow me to do?
[23:09] <monsterjamp> Is it the same as using snappy-debug?
[23:16] <sergiusens> monsterjamp it runs without confinement
[23:16] <monsterjamp> Oh, now I understand what confinement is
[23:16] <sergiusens> elopio seems master is no broken :-/ I'll crank up some fixes (adt)
[23:28] <sergiusens> elopio https://github.com/ubuntu-core/snapcraft/pull/604