[04:01] <qengho> Are there any Classic RPi kernel images that support the apparmor snapd requires?
[05:36] <niemeyer> qengho: ogra_ will know the answer when he's around
[06:15] <Girish> hello
[06:16] <Girish> anybody is there?
[06:16] <qengho> Girish: Why?
[06:17] <Girish> i have question to ask.
[06:17] <seb128> what about asking it then?
[06:17] <seb128> instead of asking if somebody is interested in you to ask
[06:18] <Girish> how to download source codes for kernel version 3.19.0-15-generic?
[06:19] <seb128> that's not really a snappy question
[06:20] <seb128> Girish, unsure if that's the one you want but https://launchpad.net/ubuntu/+source/linux/3.19.0-15.15
[06:24] <dholbach> hey, good morning!
[06:25] <seb128> hey dholbach
[06:33] <dholbach> hey seb128
[06:38] <didrocks> hey dholbach!
[06:38] <dholbach> salut didrocks
[06:47] <qengho> Girish: You should not expect anyone to commit to answering your unasked question. When on IRC, just ask, and say what you tried already to find the answer.
[06:55] <niemeyer> Morning dholbach, seb128
[06:55] <dholbach> hey niemeyer
[06:56] <niemeyer> qengho: Probably a good life advice too, even if a bit raw.. ;)
[07:07] <tsimonq2> !help | Girish
[07:08] <tsimonq2> qengho: ^ that's a thing :)
[07:13] <niemeyer> Folks.. that's enough do-not-ask-to-ask advice for a life time :)
[07:14] <niemeyer> Girish: Sorry about that..
[07:16] <tsimonq2> yes, I apologize Girish :)
[07:30] <seb128> hey niemeyer
[07:30] <niemeyer> seb128: o/
[07:49] <zyga> good morning
[07:50] <seb128> hey zyga, how are you today?
[07:50] <tsimonq2> o/ zyga
[07:51] <zyga> hey guys, I'm good :-)
[07:51] <tsimonq2> that's good :)
[08:38] <ogra_> qengho, http://cdimage.ubuntu.com/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz
[09:02] <zyga> ara: coming
[09:02] <ara> zyga, I am running late as well
[09:38] <Girish> hello anybody is there?
[09:39] <Girish> how to make a kernel module from a source code ?
[09:40] <zyga> hi
[09:40] <zyga> Girish: you have to build the whole kernel snap, you cannot ship one module
[09:41] <Girish> what does it mean? actually i am new in linux environment
[09:46] <Girish> actually i have to modify the source code in order to detect a LTE modem in its USB interface but the linux (ubuntu 15.10, kernel version 3.19.0-15-generic) that i m using have option.ko file instead of option.c file so i download the option.c file and modify it now i am confused how do i make its make file?
[09:47] <Girish> zyag are you there?
[09:48] <zyga> Girish: yes
[09:48] <nhaines> Girish: are you doing this for a desktop system or an Ubuntu Core system?
[09:48] <zyga> Girish: I think the question nhaines asked is crucial
[09:49] <Girish> actually i m using lenovo desktop which is boot into linux through UEFI/LEGACY
[09:50] <nhaines> Then this is the wrong channel, although I'm not sure which would be the right one.
[09:51] <zyga> Girish: then you just want to fix the issue in the ubuntu kernel, snappy is not a part of this
[09:51] <Girish> how to do this?
[09:52] <ogra_> Grtry asking in the #ubuntu or #ubuntu-kernel channel then
[10:15] <zyga> jdstrand: do you think we can allow sched_setparam or switch seccomp to EPERM instead of killing the process?
[11:01] <zyga> kyrofa: is this something we still want? https://code.launchpad.net/~kyrofa/snap-confine/create_user_common_data/+merge/293555
[12:21] <sborovkov> Hi. From what I understand currently systemd logs on snappy are written to SD card (in case of RPI at least). Is it possible to configure it to use tmpfs for logs?
[12:22] <jdstrand> zyga (cc tyhicks): we can probably allow sched_setparam with seccomp arg filtering (sched_setparam 0). as for EPERM, that is on the security team's todo list
[12:26] <kyrofa> zyga, no. It's no longer necessary with snap run
[12:31] <ogra_> hmm, do we have any interface that allows setpriority ?
[12:32] <zyga> jdstrand: thanks
[12:40] <qengho> ...probably from chromium.
[12:42] <tsimonq2> kyrofa: changed
[12:42] <ogra_> qengho, heh, well, i'm packahing nw.js .. so chromium is kind of involved (in case you talked to me above)
[12:43] <ogra_> runs fine in --devmode ... and makes an awesome webapp container ;)
[12:46] <jdstrand> niemeyer, zyga: hey, I'm having some trouble with go accessing the data in []interface{}. Can you look at: http://paste.ubuntu.com/18023741/
[12:47] <zyga> jdstrand: looking
[12:47] <jdstrand> niemeyer, zyga: I feel like I am being dense or missing a critical piece of info
[12:48] <jdstrand> zyga, niemeyer: dang it, that had a typo. use this: http://paste.ubuntu.com/18023866/
[12:48] <zyga> jdstrand: interface{} is "anything" but the real object behind is has its true type, what you want to do is to progressively check that the type is of a given kind until you reach the data you want
[12:49] <zyga> looking again
[12:49] <jdstrand> zyga: yes, I have no problem with interface{}. that is easy. eg: something.(string)
[12:49] <zyga> jdstrand: "baz" is a []interface{} probably
[12:50] <jdstrand> zyga: the problem is []interface{}. I can't .([]string) it and I can't range or iterate on it
[12:50] <jdstrand> zyga: it is
[12:50] <zyga> jdstrand: so you want baz, ok := slot.Attrs.([]interface{})
[12:50] <jdstrand> I say that in the paste :)
[12:50] <zyga> and then access items in baz the same way
[12:50] <jdstrand> ok, let me try that
[12:50] <zyga> it's not a []string!
[12:50] <zyga> it's a []interface{}
[12:50] <zyga> and baz[0] may be a .(string)
[12:50] <zyga> right?
[12:50] <zyga> that's distinct from []string
[12:51] <zyga> because baz[1] may be .(int)
[12:51] <qengho> Go is still martian to me.
[12:51] <jdstrand> baz[0] is a .(string), yes. I understand why .([]string) doesn't work. I just couldn't figure out what *would* work
[12:51] <jdstrand> let me try the thing you mentioned
[12:54] <jdstrand> zyga: baz, ok := slot.Attrs.([]interface{})
[12:54] <jdstrand> invalid type assertion: slot.SlotInfo.Attrs.([]<inter>) (non-interface type map[string]interface {} on left)
[12:55] <jdstrand> for baz, ok := range slot.Attrs.([]interface{}) doesn't work either
[13:00] <jdstrand> zyga: sorry, I've looked at this for far longer than I care to admit but I just can't seem to pull out the data. it seems like I need to iterate on slot.Attrs["baz"] so I can .(string) on baz[0], baz[1], but I can't figure out how to do that and I'm not sure if I should be doing something else
[13:02] <zyga> jdstrand: let me help you after the standup
[13:23] <zyga> jdstrand: can you push something more concrete? do you have a branch with a new interface?
[13:35] <jdstrand> zyga: well, I have a branch that I am converting to using the yaml as described and it is severely broken because I'm blocked on this, but give me a few minutes and I can push that somewhere
[13:35] <zyga> jdstrand: ok
[13:35] <zyga> jdstrand: I'll help you out
[14:00] <jdstrand> zyga: https://github.com/jdstrand/snapd/tree/dbus-bind-broken
[14:01] <zyga> jdstrand: thanks
[14:01] <jdstrand> zyga: I'm using: go build -tags=excludeintegration -v github.com/snapcore/snapd/... && go test -tags=excludeintegration -v github.com/snapcore/snapd/interfaces/builtin
[14:01] <zyga> FYI, test implies build
[14:02] <jdstrand> zyga: you'll see soon enough, the problem is in SanitizeSlot
[14:02] <zyga> jdstrand: looking :)
[14:09] <sabdfl> zyga, hi
[14:09] <zyga> sabdfl: hey :-)
[14:10] <tsimonq2> o/ sabdfl, how are you?
[14:11] <sabdfl> well thank you, sad at brexit
[14:11] <sabdfl> understandable frustrations, incomprehensible response
[14:11] <sabdfl> on the bright side... SNAPS! :)
[14:12] <tsimonq2> yes! :)
[14:12] <tsimonq2> sabdfl: have you seen the increasing amout of snaps in the playpen? https://github.com/ubuntu/snappy-playpen
[14:12] <jamiebennett> sabdfl: lets not mention the England football result either
[14:12] <tsimonq2> *amount
[14:13] <sabdfl> jamiebennett, there are some games where one side HAS to lose
[14:13] <sabdfl> other gae where everybody CAN win
[14:13] <sabdfl> games, that is
[14:14] <sabdfl> let's just say this was not a game where penalty shootouts were called for :)
[14:14] <sabdfl> tsimonq2, yes, great traction, and with distros too
[14:15] <tsimonq2> sabdfl: I'm curious, speaking of other distros, what's your opinion on Flatpak?
[14:16] <sabdfl> tsimonq2, it will end up duplicating snaps, judging from the roadmap they announced, unfortunately
[14:16] <sabdfl> cant really prevent it, the nature of competitive instincts
[14:17] <tsimonq2> sure, I get it :)
[14:17] <tsimonq2> just wondering your opinion
[14:17] <sabdfl> i wish they wouldn't say nasty things about us to try to get support for their own efforts
[14:17] <sabdfl> it's fine to NIH stuff if you feel you have to do that
[14:17] <sabdfl> i uspect most fedora / rhel user will choose to use snaps if they are high quality
[14:17] <tsimonq2> yeah, I recently started contributing to Snapcraft, and now I love snaps. I used to find them confusing, but I became pleasantly surprised
[14:18] <sabdfl> but it's fine that to have other options too
[14:18] <sabdfl> tsimonq2, :D
[14:18] <sabdfl> we just have to blog loudly about the great thinking that underpins the snap architecture
[14:18] <sabdfl> technology and quality should win these races, and we should challenge the other guys to leave the politics at home
[14:19] <tsimonq2> yes, agreed
[14:19] <tsimonq2> it's sort of ironic how we are supposed to have a universal package format now
[14:19] <tsimonq2> but there is multiple formatsd
[14:19] <tsimonq2> *formats
[14:20] <tsimonq2> Snappy, Flatpak, and I hear of more
[14:20] <ogra_> appimage ?
[14:20] <tsimonq2> yeah I think that :)
[14:21] <tsimonq2> sabdfl: on the note of me contributing, I am really glad I decided to work with the people in the Snapcraft team to get som code in
[14:21] <tsimonq2> *some
[14:21] <tsimonq2> I've learned a lot
[14:22] <ogra_> pay it back by teaching someone else in the community later ;)
[14:22] <tsimonq2> that's my plan :)
[14:22] <ogra_> :D
[14:23] <sabdfl> tsimonq2, did you make a plugin?
[14:24] <tsimonq2> sabdfl: well no, I added Subversion support
[14:25] <sabdfl> just as useful :)
[14:25] <tsimonq2> \o/
[14:25] <tsimonq2> sabdfl: but I have a couple bugs assigned to me right now
[14:25] <tsimonq2> for example, I'm adding checksum support for tar and zip sources
[14:26] <sabdfl> that's nice, will help all the different user communities
[14:26] <sabdfl> gtg
[14:27] <tsimonq2> o/
[14:40] <jdstrand> zyga: any luck?
[14:52] <zyga> jdstrand: I was pulled into a few meetings
[14:52] <zyga> jdstrand: I have vim open but I didn't touch it much
[14:52] <jdstrand> heh, ok, no worries
[14:53] <jdstrand> I have a meeting myself soon
[14:59] <zyga> jdstrand: ok, I'm more available now
[15:41] <zyga> jdstrand: sorry, this is a pretty interesting day
[15:41] <zyga> jdstrand: I'll be with you shortly
[15:42] <ysionneau> hi, about socket activated services in Snappy. Are they automatically started at bootup?
[15:42] <ysionneau> Or only when socket is accessed?
[15:42] <jdstrand> zyga: no worries. out of meeting and have a bunch of other stuff I can work on
[15:42] <ysionneau> The behaviour I am seeing here is : it's started at bootup. is this normal?
[15:43] <jdstrand> zyga: I am quite curious what I'm missing though
[16:07] <zyga> jdstrand: hacking on it now
[16:08] <zyga> jdstrand: quick note, pulsaudio 9.0.1 changes APIs a lot, we could drop the shm stuff entirely
[16:08] <zyga> jdstrand: we should have a backlog item for it
[16:08] <zyga> jdstrand: arch has it today
[16:11] <sergiusens> elopio hey, thinking about migrating the sources while we wait; is it just a matter of movinf the organization?
[16:11] <elopio> sergiusens: yes, afaik. You can ask niemeyer if he had to do something else.
[16:11] <joc_> sergiusens: hey, i'm trying to use the python3 plugin to pull in plainbox to my snaps, as per the plugin discussion, however i don't get entry points for the programs in the package created like i do if just run pip3 on my host - do you know why that might be?
[16:12] <elopio> sergiusens: oh, and reset the jenkins hook, set the team permissions, that too.
[16:13] <elopio> re-enable coveralls, update the badges in the README.
[16:13] <pcoca> Chipaca, Hi! I've been trying to make a snap of httpie
[16:14] <pcoca> Chipaca, I just realised that you did one a few weeks ago
[16:14] <pcoca> Chipaca, But with a very different approach.
[16:15] <pcoca> Chipaca, I am struggling with the relative modules and this snapcraft.yaml: https://github.com/pedrococa/httpie_snap/blob/master/snapcraft.yaml
[16:15] <niemeyer> sergiusens: Moving the repo? Yeah, it's straightforward, and GH internally maps the old links to the new place
[16:18] <pcoca> Chipaca, Do you know how to overcome the relative modules issues with httpie, when you point to the repo and use the python3 plugin?
[16:24] <sergiusens> niemeyer yup. already done ;-) Sent an email and it is kind of cool that redirects happen automatically and all PRs just DTRT
[16:25] <sergiusens> elopio ok, I can take care of badges et.al. but no idea how to reset the jenkins stuff
[16:25] <tsimonq2> wooooooooooooah
[16:25] <tsimonq2> https://github.com/snapcore/snapcraft !!!
[16:28] <elopio> sergiusens: In setting of the project > hooks. Set http://162.213.35.179:8081/ghprbhook/, with permission to Pull Request and Issue comment.
[16:28] <elopio> sergiusens: I'm leaving now, I can help when I'm back.
[16:28] <sergiusens> elopio sure; all good
[16:32] <sergiusens> elopio heh, lost my admin :-P
[16:32] <sergiusens> niemeyer can you make me admin of snapcraft?
[16:33] <niemeyer> @sergiusens Of course
[16:33] <nothal> niemeyer: No such command!
[16:33] <sergiusens> joc_ they all have those script entries in setup.py, right?
[16:33] <niemeyer> Oops :)
[16:33] <niemeyer> sergiusens: Of course :)
[16:35] <sergiusens> thanks niemeyer
[16:35] <joc_> sergiusens: not too familiar with the format of setup.py but i think so, there are entry points declared like this: http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/setup.py#L95
[16:36] <sergiusens> joc_ yeah, console_scripts should just work, let me try something simpler to see if there's a hidden bug (later today though)
[16:36] <niemeyer> sergiusens: You and kyrofa are admins, and added the snapcraft-contributors team as write access
[16:36] <sergiusens> thanks!
[16:37] <niemeyer> np
[16:37] <kyrofa> Thanks niemeyer
[16:37] <joc_> sergiusens: ok thanks
[16:38] <niemeyer> sergiusens, kyrofa: I've also created a snapcraft-bots team.. not sure what level of access you'll want to give it, but let's please keep real contribs and bots separated
[16:38] <niemeyer> We've been doing that already on the other teams
[16:50] <sergiusens> kyrofa lool https://github.com/snapcore/snapcraft/pull/611
[16:51] <lool> sergiusens: LGTM, do you want me to do something to land it?
[16:51] <lool> I dont think I'm in the snapcore org
[16:54] <sergiusens> lool no, just sending your way since you complained ;-)
[16:55] <sergiusens> lool I will wait for elopio on this one
[16:55] <lool> sergiusens: I didn't complain!
[16:55] <lool> I sent you a heads up in case you didn't about it
[16:55] <sergiusens> elopio btw, the hook is already configured
[16:55] <sergiusens> lool ah, well, a complaint I took in a positive way ;-)
[16:55] <lool> sergiusens: FYI snapcraft/tests/test_sources.py mentions the old branches, if real checkouts are made and we ever remove the old branch, you would want to update them to the new one
[16:55] <ogra_> lool, stop complaining that you didnt complain !
[16:55] <ogra_> :)
[16:56] <lool> I'm being harassed by people who pretend I'm complaining, I'll file a complaint
[17:00] <sergiusens> lool those never reach the checkout phase :-)
[17:00] <lool> sergiusens: ok, I didn't check
[17:01] <lool> hence the conditional
[17:01] <lool> and caveats
[17:50] <netphreak> Hi, guys!
[17:51] <Guest32438> hello on  http://snapcraft.io/ there is a little mistake in section Release channels. the channel option is mentioned with a single dash (-) yet in the section beneath it is mentioned with a equal (=) . just happened to see this and thought to inform you. have a nice day!
[17:57] <zyga> jdstrand: hey
[17:57] <zyga> jdstrand: sorry it took me so long, really unpredictable day
[17:58] <zyga> jdstrand: if you pull from my remote you will see how to use this
[17:58] <zyga> jdstrand: I can expand this anyway you like so please just have a look and tell me if that answers your question
[17:58] <zyga> jdstrand: and if not let's work on this some more
[17:59]  * zyga coffee and back to snap-confine
[18:01] <jdstrand> zyga: thanks! I see what you are doing. man, I was so close
[18:01] <jdstrand> I almost tried something like that. thanks!
[18:03] <zyga> jdstrand: syntax can be confusing :)
[18:08] <jdstrand> zyga: yes, and go's interface{} isn't the most intuitive thing in the world
[18:19] <zyga> jdstrand: it helps to read how it is implemented
[18:20] <zyga> jdstrand: it is essentially a proxy that knows how to dispatch each of the methods defined inside (note that {} doesn't have to be empty!)
[18:24] <netphreak> Any eta. on a release image for Rpi3?
[18:42] <jdstrand> zyga: yeah, I did read how it was implemented. there was a nice article on it. it was the '[]' part of '[]interface{}' that threw me since I couldn't range it and it seemed like I should be able to
[18:47] <sergiusens> kyrofa su?
[18:47] <kyrofa> sergiusens, ah sorry, mentioned on telegram but should have put it here-- I'm not feeling well, I need to lay down
[18:48] <josepht> kyrofa: I hope you feel better
[18:48] <sergiusens> kyrofa ah, get better
[18:48] <kyrofa> Thanks guys
[18:51] <zyga> jdstrand: you can range it
[18:51] <zyga> jdstrand: you can range it and each element is a interface{}
[18:57] <zyga> slangasek: hey, I'm just doing this not to forget
[18:58] <zyga> slangasek: I'd love if you could commit debian packaging back to snap-confine master, this would help us in tetsing debina
[18:58] <zyga> slangasek: and then merge the one change back to debian, the change in debian/rules, specifically commit 2b130c575010a6f35a9f05d8683a761c8c02e2a0
[18:59] <zyga> slangasek: this will become critical when we switch to snap-exec and when snap-confine will be started from a relative path
[18:59] <zyga> slangasek: which will be essential for core snap updates
[19:01] <slangasek> zyga: I'm pretty sure I don't have commit rights on snap-confine master fwiw, but I will take time this week to review and raise pull requests
[19:01] <jdstrand> zyga: that is what I tried to do, but I didn't end up with the right incantation
[19:01] <zyga> slangasek: just send me a pull request or a branch on alioth that can be merged easily
[19:02] <zyga> slangasek: I looked at doing this but I gave up because master's weren't compatible
[19:02] <zyga> jdstrand: ack
[19:02] <jdstrand> hence the 'so close' comment
[19:02] <jdstrand> :)
[19:02] <jdstrand> anyhoo, thanks!
[19:02] <zyga> jdstrand: my pleasure
[19:02] <zyga> slangasek: I'd like to upload a sid vm to linode so that we can do per-commit tests on debian too
[19:02] <zyga> slangasek: and then having dpkg-vendor patches would be essential
[19:14] <sergiusens> josepht https://bugs.launchpad.net/snapcraft/+bug/1596044
[19:15] <josepht> sergiusens: is that different from the ordering refactoring you mentioned in the SU?
[19:16] <sergiusens> josepht nope
[19:16] <elopio> sergiusens: ah, what's missing is to update the jobs. I'm on it.
[19:16] <josepht> sergiusens: I see.  I was reading it as the "parser's parts loader".  I'll assign to me.
[19:19] <elopio> sergiusens: the tests can be triggered now. But the user can't update the status on the PR, it says: http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1082/
[19:20] <elopio> so you need to give snappy-m-o write access.
[19:28] <sergiusens> elopio ok, write access as in to comment?
[19:29] <sergiusens> the webhook or the user/bot?
[19:32] <elopio> sergiusens: the user. Write access as in pushing changes to the repo.
[19:36] <sergiusens> niemeyer hey, can you add elopio's bot to https://github.com/orgs/snapcore/teams/snapcraft-bots ?
[19:37] <sergiusens> niemeyer also, can you enable coveralls for snapcore/snapcraft, seems it needs an org admin
[19:38] <elopio> niemeyer: and please send us the token in case it's needed.
[19:41] <sergiusens> mhall119 give this a try https://github.com/snapcore/snapcraft/pull/612 you will get further but stuck on the fact you need to export alternate paths for GIR
[19:50] <sergiusens> attente hey you around? Can you tell me what would be needed to be able to open "resources" using a snap app; like https://telegram.me/joinchat/BQHZRAiN_pnOeE4mT31YCQ in the telegram snap?
[19:51] <attente> sergiusens: what kind of resources? is it just a url opened via xdg-app?
[19:52] <sergiusens> attente yeah, probably, going to that link offers tg://join?invite=BQHZRAiN_pnOeE4mT31YCQ
[19:52] <attente> sergiusens: the snapd-xdg-open helper only allows http, https and mailto
[19:52] <sergiusens> attente so it is the other way around than from the bug you were working on
[19:52] <sergiusens> attente right that is from snap to world
[19:52] <sergiusens> attente I face a much simpler problem now, from world to snap
[19:55] <attente> sergiusens: that doesn't sound easier. wouldn't we have to hack the default xdg-open script that comes with xdg-utils?
[19:56] <sergiusens> attente I don't know, hence I am asking you :-)
[19:57] <sergiusens> attente does xdg-open look for desktop files to figure out uri handlers or are they registered at install time?
[19:58] <attente> sergiusens: just glancing at the script right now, it looks like it examines the desktop files, so maybe there's some way to prioritize the ones in the snaps
[19:58] <sergiusens> attente right, right now I click and nothing happens :-)
[20:00] <attente> sergiusens: maybe that's an apturl problem actually
[20:01] <attente> sergiusens: er. sorry, never mind
[20:03] <attente> sergiusens: is there an open bug for this?
[20:12] <sergiusens> attente no, just brought to my attention by pmcgowan :-)
[20:14] <attente> sergiusens: is there a general directory where the desktop files of snaps is located? the same way that there's /snap/bin?
[20:14] <sergiusens> attente yup
[20:14] <sergiusens> attente /var/lib/snapd/desktop/applications/
[20:15] <sergiusens> mvo or zyga can correct me if I am wrong here ^
[20:15] <attente> sergiusens: looks right here
[20:17] <attente> sergiusens: maybe adding /var/lib/snapd to XDG_DATA_HOME in the session might make the xdg-open script look there first
[20:17] <sergiusens> attente so as it is right now it should be looking?
[20:18] <sergiusens> in my case, it is not opening anything at all
[20:18] <sergiusens> attente what desktop key would I need for this?
[20:19] <attente> desktop key?
[20:20] <sergiusens> attente yeah, in the desktop file
[20:21] <attente> i would've thought MimeType=x-scheme-handler/tg, but your telegram snap already has it
[20:27] <niemeyer> sergiusens, elopio: Still out for some exercising, but will do
[20:53] <attente> sergiusens: can you try manually editing ~/.config/mimeapps.list to add x-scheme-handler/tg=telegram-sergiusens_telegram.desktop
[20:54] <attente> this seemed to launch the snapped telegram for me
[21:13] <mhall119> sergiusens: that didn't seem to help me any
[21:14] <mhall119> sergiusens: does snapcraft cleanbuild install snapcraft in the lxc, or does it copy the host's snapcraft install into it?
[21:15] <pmcgowan> attente, that worked
[21:16] <pmcgowan> attente, although it seems to always open a new instance
[21:17] <mhall119> hmmm, looks to install it via apt
[21:20] <attente> yeah, same here
[21:24] <mhall119> sergiusens: I'm cowboy-patching snapcraft in the lxc container created by cleanbuild
[21:24] <mhall119> will see how it goes
[21:24]  * genii hands mhall119 the lariat
[21:33] <mhall119> sergiusens: so I patched /root/parts/mail/bin/pkg-config and re-ran "snapcraft snap" and it did indeed get further, but it spit out a whole bunch of cmake warnings about link directories or something
[21:34] <mhall119> oh wait, it might be something I did
[21:37] <mhall119> ah ha, yes, I threw an extra print(env) line in there, and evidently something was consuming that
[21:43] <mhall119> thanks sergiusens, that unblocks me on snapcraft now I think, I'll try and get vala/gir help from the elementary devs tomorrow