[00:19] <mwhudson> series_16 = lp.snappy_serieses.getByName(name='16')
[00:19] <mwhudson> series_16.preferred_distro_series is now None
[00:19] <mwhudson> what changed there?
[00:20] <mwhudson> i guess i should forum this, noone is going to be listening now :)
[07:21]  * davidcalle back from hol, morning all o/
[07:23] <Saviq> davidcalle: elo, should've disabled your IRC bouncer for when you were not around ;)
[07:23] <davidcalle> Saviq: hehe :)
[07:26] <Saviq> davidcalle: when you have time, please let us know if you need anything more from us on https://github.com/canonical-websites/developer.ubuntu.com/pull/305
[07:28] <davidcalle> Saviq: I'm going to do a round of testing on this before merging, but hopefully today
[07:52] <mwhudson> zyga-suse: o/
[07:52] <mwhudson> zyga-suse: did you see https://forum.snapcraft.io/t/updating-snapd-in-debian/1645
[07:52] <zyga-suse> hey hey
[07:52] <zyga-suse> no, just waking up and checking things
[07:52] <zyga-suse> agreed on all the exclusions
[07:52] <zyga-suse> looking at pastebin
[07:54] <zyga-suse> replied
[07:54] <mwhudson> thanks
[07:55]  * zyga-suse just edited the list to remove the obvious paste mistakes
[07:56] <mwhudson> i think the fedora packaging ships some of those files in the snap-confine package, unless i'm missing something
[07:56] <zyga-suse> that's legacy
[07:56] <zyga-suse> they should be merged into one package
[08:05] <mwhudson> zyga-suse: are we reasonably sure 2.27 fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872071 ?
[08:05] <mwhudson> zyga-suse: that's the 'hang on configuring core snap' thing
[08:05] <zyga-ubuntu> mwhudson: no, it doesn not
[08:05] <mwhudson> zyga-suse: boo
[08:05] <zyga-ubuntu> mwhudson: we have not identified the reason yet, I believe
[08:06] <zyga-ubuntu> but chose not to block on it because it is an existing bug, not a regression
[08:06] <mwhudson> zyga-suse: it looked like mvo had a favoured theory, did that not turn out to be it?
[08:07] <zyga-ubuntu> mwhudson: not sure I know the theory
[08:07] <mwhudson> zyga-suse: https://forum.snapcraft.io/t/debian-core-configure-hang-on-first-snap-install/1586/6?u=mwhudson
[08:07] <zyga-ubuntu> mwhudson: i think he posted about it
[08:07] <zyga-ubuntu> ah
[08:07]  * zyga-ubuntu reads
[08:07] <mwhudson> i guess i can add that to the changelog after i actually test the debs :)
[08:07] <zyga-ubuntu> ah
[08:08] <zyga-ubuntu> I hope it is asimple as that
[08:08] <mwhudson> oh haha this debian vm called 'debian-stretch-amd64' is actually sid
[08:08] <zyga-ubuntu> yes
[08:08] <zyga-ubuntu> the qemu one is realyl stretch
[08:08] <mwhudson> that saves a step
[08:08] <zyga-ubuntu> the linode one is sid
[08:08] <mwhudson> zyga-suse: no this is a local one
[08:08] <zyga-ubuntu> ah, I see :)
[08:09] <mwhudson> zyga-suse: i need to test https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851473 again too
[08:09] <zyga-ubuntu> I think it will still be the same
[08:09] <zyga-ubuntu> I don't think we took any action on it
[08:09] <mwhudson> probably
[08:11] <mwhudson> well it does this with 2.26.14 from the core snap:
[08:11] <mwhudson> debian@debian:~$ hello.universe
[08:11] <mwhudson> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[08:14] <zyga-ubuntu> that's a new bug, where snapd sees unpatched apparmor and choses not to enable the apparmor backend
[08:15] <zyga-ubuntu> and thus snap-confine does not get its own profile
[08:15] <zyga-ubuntu> but then snap-confine sees the kernel has apparmor enabled
[08:15] <zyga-ubuntu> and it is setuid root
[08:15] <zyga-ubuntu> but the profile is nowhere to be found, so it bails out
[08:21] <zyga-ubuntu> US seems to be a troubled land recently :/
[08:53] <mwhudson> zyga-suse: the hang on configure does indeed seem to be fixed \o/
[08:54] <mwhudson> root@debian:~# hello.universe
[08:54] <mwhudson> /usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
[08:54] <mwhudson> wtf!!
[08:54] <zyga-suse> that is great news!!
[08:54] <zyga-suse> the libcap one is interesting
[08:54] <zyga-suse> is snap-confine linking libcap dynamically?
[08:55] <mwhudson> whut
[08:55] <zyga-suse> mwhudson: note that one way to test the hang reliably is to snap install hello while *not* having core
[08:55] <mwhudson> oh
[08:55] <mwhudson> no wait
[08:55] <mwhudson> zyga-suse: http://paste.ubuntu.com/25311128/
[08:56] <mwhudson> zyga-suse: could this be caused by the core that i just downloaded being older than the snapd i have installed?
[08:56] <mwhudson> no
[08:57] <mwhudson> open("/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
[08:57] <mwhudson> i guess this is apparmor being potty again
[08:57] <mwhudson> yea
[08:57] <mwhudson> Aug 14 20:56:57 debian kernel: [ 3608.590506] audit: type=1400 audit(1502701017.760:10): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/lib/x86_64-linux-gnu/libcap.so.2.25" pid=2365 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[08:57] <mwhudson> lets turn apparmor off for now...
[08:58] <zyga-suse> mwhudson: ah, I think this *is* apparmor
[08:58] <zyga-suse> but wait, didn't you say you disabled apparmor?
[08:58] <zyga-suse> ah, no you enabled it sorry
[08:58]  * zyga-suse is really sleepy still
[08:59] <zyga-suse> so, with older core you will not re-exec
[08:59] <mwhudson> i've disabled it *now* and it works
[08:59] <zyga-suse> and you will use snap-confine from debian
[08:59] <zyga-suse> and you may see profile incompatibility
[08:59] <mwhudson> ah yeah, i think i knew that once
[08:59] <zyga-suse> since snap-confine profile is written for more recent apparmor behavior
[09:02] <mwhudson> zyga-suse: any ideas for things i should test on this vm?
[09:04] <zyga-suse> mwhudson: did you try the "I have no core and I snap install hello" use-case?
[09:05] <mwhudson> zyga-suse: yes
[09:05] <mwhudson> that was the first thing i tried :)
[09:06] <zyga-suse> hmm, not sure then, just a random collection of snaps perhaps: ... one sec
[09:06] <zyga-suse> https://github.com/snapcore/snapd/pull/3692
[09:09] <mwhudson> zyga-suse: is there some easy way to run this on the vm?
[09:10] <zyga-suse> not sure, I think if you can just hand install the top three it would be a good test
[09:10] <mwhudson> heh heh good to see my only important snap on there :)
[09:14] <zyga-ubuntu> which one is that?
[09:14] <zyga-ubuntu> :)
[09:14] <zyga-ubuntu> mvo: welcome back
[09:14] <mvo> hey zyga-ubuntu
[09:16]  * zyga-ubuntu needs 2nd coffee
[09:16] <zyga-ubuntu> head.ache()
[09:17] <mvo> zyga-ubuntu: I get a cup of tea now too - I looked briefly at backporting asic control to 2.27.1 but there are quite a few changes to common interfaces that would also need backporting, it seemed overly broad for the scope of a .1
[09:18] <zyga-ubuntu> mvo: if you want I can make a simpler backport, with a custom interface type
[09:18] <mvo> zyga-ubuntu: lets
[09:18] <mvo> zyga-ubuntu: sorry, let see if we need a .2 and only do it if we do
[09:18] <zyga-ubuntu> mvo: ok, when will we know?
[09:19] <mwhudson> zyga-suse: go
[09:19] <mvo> zyga-ubuntu: hopefully soon, I will ask cachio to do the 2.27.1 validation today
[09:19] <zyga-ubuntu> ok
[09:20] <zyga-ubuntu> I'll do some more reviews for garry and work on 2.27.1 packaging
[09:20] <mvo> +1
[09:22] <mwhudson> heh i appear to have rocketchat installed on debian sid
[09:22] <zyga-ubuntu> the funny thing is it would also install on debian *stable*
[09:42] <zyga-ubuntu> hmm, mup is not reporting PRs
[09:49] <ikey> ok so github is seriously tripping right now
[09:49] <ogra> oh, while you mention github ...
[09:50] <ikey> zyga-ubuntu, https://ibin.co/3Wq1GWrSnkGi.png
[09:50] <zyga-suse> hey
[09:50] <zyga-suse> hmmm
[09:50] <zyga-suse> I merged master into your branch
[09:50] <zyga-suse> that should fix the fedora failures
[09:50] <ikey> yeah but look where you pushed
[09:50] <ikey> that shouldnt be possible
[09:50] <ikey> thats the forked repo
[09:50] <zyga-suse> yes
[09:51] <zyga-suse> it is, that's a github feature
[09:51] <ikey> then github is on crack
[09:51] <ikey> because repo permissions
[09:51] <ikey> lol
[09:51] <zyga-suse> I pushed that *into* your branch because when there's an active PR contributors can do that
[09:51] <zyga-suse> it's an opt-out feature for about 3 months
[09:51]  * ikey calls crack
[09:51] <zyga-suse> it does makes sense :)
[09:51] <ikey> meth then
[09:51] <ikey> :p
[09:51] <zyga-suse> it's weird but when you think about it
[09:51] <zyga-suse> people close the PR and reopen with more things
[09:52] <zyga-suse> but that's just a time waste
[09:52] <ikey> rebase/force push
[09:52] <zyga-suse> why?
[09:52] <ikey> i mean in response to "people close the PR"
[09:52] <zyga-suse> ah
[09:52] <mup> PR snapd#3724 opened: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
[09:52] <zyga-suse> no, I mean people close the PR because they cannot push to it
[09:53] <ikey> oh others
[09:53] <zyga-suse> contributor comes along and makes a PR but then looses interest
[09:53] <ikey> ah
[09:53] <zyga-suse> maintainers are willing to fix so they close and reopen with their fixes
[09:53] <zyga-suse> this just cuts one step
[09:53] <zyga-suse> not saying that it happens all the time
[09:53] <zyga-suse> but even inside the core team we do that all the time
[09:53] <zyga-suse> esp timezones
[09:53] <zyga-suse> it helps
[09:54] <zyga-suse> btw, I'm curious -- what was that UI that showed me doing this?
[09:54] <zyga-suse> is that something I can use?
[09:55] <mup> PR snapd#3702 closed: interfaces: add missing test for camera interface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3702>
[09:56] <ikey> zyga-suse, that was just on my github front page
[09:56] <zyga-suse> aha
[09:56] <zyga-suse> interesting theme :)
[09:56]  * mwhudson uploads snapd_2.27.1-1_source.changes
[09:56] <ikey> https://ibin.co/3Wq3LA9vK99y.png
[09:59] <zyga-ubuntu> ikey: nice, is that a custom theme applied somehow or something I can toggle just on github?
[09:59] <ikey> i use userstyles extension in chrome
[09:59] <zyga-ubuntu> ah, right
[09:59] <ikey> or stylish
[09:59] <ikey> or h/e you call it .. lol
[10:00] <ikey> "GitHub Dark"
[10:00] <ikey> wth gdk-pixbuf
[10:00] <ikey> what kind of a mad man statically links libtiff
[10:00]  * zyga-suse ventures into /usr/lib/rpm 
[10:01] <ikey> i feel i should say "It's dangerous to go alone!" and offer you a sword.
[10:02] <zyga-ubuntu> I think I'm already out, I was looking at how /usr/lib64/go vs /usr/lib/go can be abstracted
[10:03] <ikey> ah
[10:08] <pedronis> mvo: hi,  snapd#3710 is the thing that needs a review for 2.28 btw
[10:08] <mup> PR snapd#3710: many: allow and support serials signed by the 'generic' authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3710>
[10:09] <mvo> pedronis: thanks, I have a look
[10:09] <Chipaca> zyga-ubuntu: any luck with a branch to disable sync in tests?
[10:10] <zyga-ubuntu> Chipaca: nope, I left it on a hanger last week
[10:10] <zyga-ubuntu> Chipaca: let me refresh it
[10:18] <Chipaca> zyga-ubuntu: no worries, just curious
[10:22] <Chipaca> huh, the autopkgtests run without a core snap
[10:27] <ogra> jospoortvliet, hey ho ... why does this section if the nextcloud install doc tell you to install debs alongside the snap ? https://docs.nextcloud.com/server/12/admin_manual/installation/source_installation.html#example-installation-on-ubuntu-16-04-lts-server
[10:28] <jospoortvliet> ogra: it is meant to be a choice
[10:28] <jospoortvliet> either install the snap
[10:28] <jospoortvliet> or go the 2nd way: install things manually
[10:28] <jospoortvliet> it isn't very clear
[10:28] <jospoortvliet> not at all :D
[10:28] <ogra> yeah :)
[10:29] <jospoortvliet> ogra: I would suggest to have a header "option 1" and "option 2"
[10:29] <jospoortvliet> if you want, you can propose the change: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/source_installation.rst
[10:29] <jospoortvliet> edit the source of the documentation there
[10:30] <ogra> jospoortvliet, FYI  https://lists.ubuntu.com/archives/ubuntu-users/2017-August/291222.html
[10:31] <jospoortvliet> ogra: if you happen to be on that list, replying to explain the problem would be welcome, I'm not a member...
[10:32] <jospoortvliet> and mention me ( @jospoortvliet ) if you make a pr for the documentation. Just use the web UI of github... or let me know if you can't figure out how to, I'd be happy to help!
[10:34]  * zyga-suse focuses on suse package again
[10:35] <jospoortvliet> +1 for that zyga-suse - I have moved to using the tarball but as openSUSE user I'd consider moving back to packages. Though then I can't help test RC's etc so easily. choices, choices... ;-)
[10:35] <zyga-suse> hmm?
[10:35] <zyga-suse> I mean suse package of snapd
[10:36] <jospoortvliet> aaah zyga-suse that is also cool :D
[10:36] <jospoortvliet> zyga-suse: esp on small devices that you don't want to maintain I think the snap is super useful
[10:36] <jospoortvliet> so +1 on that, too :D
[10:38] <ogra> jospoortvliet, https://github.com/nextcloud/documentation/pull/554
[10:38] <mup> PR nextcloud/documentation#554: make clearer that it is either snap or deb in the example <Created by ogra1> <https://github.com/nextcloud/documentation/pull/554>
[10:57]  * zyga-suse ponders 
[10:57] <zyga-suse> https://paste.gnome.org/pasc7ndpu
[11:04]  * zyga-ubuntu -> lunch
[11:07] <ogra> zyga-ubuntu, thanks for merging the spi stuff in the pi3 gadget (i thought you said you wanted manual tests in your last comment on the PR, this is why i had not merged it yet)
[11:07] <zyga-ubuntu> it looked ok
[11:08] <ogra> yeah, and it goes to edge first anyway :)
[11:10] <Chipaca> ok, time for me to take a break (run + lunch + etc
[11:10] <Chipaca> )
[11:30]  * zyga-ubuntu resumes hacking
[11:53] <zyga-ubuntu> can someone please do a 2nd review for 3714
[11:57] <mup> PR snapd#3705 closed: interfaces: convert lxd_support to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3705>
[12:03] <ikey> i updated my PR to remove the mkversion changes
[12:04] <ikey> (and rebased it on master to drop the 30 odd pull requests on top of it :P)
[12:05] <zyga-ubuntu> ikey: ok,
[12:05] <ikey> it seemed to be the main sticking point of the PR
[12:05] <ikey> and it means changing all of 2 lines in my package.yml
[12:05] <ikey> so its a silly thing to keep around
[12:06] <ikey> actually no it just means adding one line, easier again
[12:06] <zyga-ubuntu> Thank you!
[12:06] <zyga-ubuntu> I asked jdstrand to review that PR
[12:06] <ikey> s'all good dude
[12:06] <ikey> i like streamlined :p
[12:12] <pedronis> ikey: notice that we tend to frown upon rebases once a PR has got comments
[12:13] <pedronis> at least that's what I always heard from niemeyer
[12:13]  * ikey blinks
[12:13] <ikey> i didnt exactly have a choice :p
[12:13] <ikey> zyga-ubuntu pushed a merged master on top of it, and the only way to edit my own patch was to rebase it back on top of master
[12:14] <zyga-ubuntu> that's fine
[12:14] <ikey> i wasn't going to dig through 30 merged PRs for my patch and then reapply them lol
[12:14] <niemeyer> ikey: You can just merge master in those cases, I believe
[12:14] <ikey> it was already merged
[12:14] <ikey> thats the problem
[12:14] <ikey> i couldnt amend my commit
[12:15] <niemeyer> ikey: You can just continue changing the content of the PR further.. no need to amend
[12:15] <niemeyer> This way reviews continue to make sense on the timeline
[12:15] <ikey> which means you would need to cherry-pick my commits and would lose my gpg signature
[12:15] <niemeyer> Otherwise all previous references to commits are lost
[12:15] <ikey> idk maybe we just git differently
[12:16] <ikey> github shows when a comment is for an outdated diff
[12:16] <pedronis> we have a slightly messy mainline
[12:16] <pedronis> but we don't care it seems, so yes we make different git choices I think
[12:16] <ikey> well, i know for future
[12:17] <niemeyer> The mainline is pretty clean, mainly because we squash merges
[12:17] <ikey> which then loses gpg signatures, etc
[12:17] <pedronis> often but not always
[12:17] <niemeyer> It does, yes
[12:17] <ikey> debian has been pushing for signed commits for some time
[12:17] <ikey> as well as signed tags
[12:18] <niemeyer> Thanks for the changes, and good morning btw :)
[12:18] <ikey> morning!
[12:18] <ikey> at times github is enough to make me miss gerrit
[12:18] <ikey> which is an awful thing to say
[12:20] <niemeyer> GitHub is pretty reasonable these days in terms of code reviews.. it used to be unacceptable for anything non trivial
[12:20] <ikey> yeah
[12:21] <ikey> at least its no longer trying to hide all the things
[12:21] <Son_Goku> beh
[12:21] <Son_Goku> signed commits and tags cause issues
[12:21] <ikey> update your git client?
[12:21] <ikey> dont use gitkraken?
[12:21] <ikey> etc. :p
[12:21] <Son_Goku> if GitHub throws 500 errors, there's not a lot I can do
[12:22] <ikey> github makes no attempt to verify signatures
[12:22] <Son_Goku> it's a known issue with how GitHub's gpgverify works
[12:22] <Son_Goku> yes it does
[12:22] <ikey> only that the issue belongs to an account
[12:22] <Son_Goku> it actually *does* attempt to verify them
[12:22] <ikey> because you have to upload your gpg key to github for it to do so
[12:22] <ikey> not to a keyserver
[12:22] <Son_Goku> well, yeah, not to hkp
[12:22] <Son_Goku> but it does actually attempt to verify them
[12:22] <ikey> right so its not doing **normal** verification is what im saying :p
[12:23] <Son_Goku> mvo, have you attempted to get this fixed yet? https://github.com/golang/go/issues/20556
[12:29] <Son_Goku> woo, someone fixed mongodb ftbfs on s390x :D
[12:29] <Son_Goku> that means I can finally build snapd on rawhide
[12:29] <zyga-suse> someone *cares* :D
[12:29] <zyga-suse> how is that related?
[12:33] <Son_Goku> snapd -> go mongodb driver -> mongodb-libs -> mongodb
[12:34] <Son_Goku> zyga-suse: it's really silly that snapd depends on mongodb transitively, but whatever
[12:36] <Son_Goku> god, I hate arm: https://koji.fedoraproject.org/koji/taskinfo?taskID=21222949
[12:36] <Son_Goku> it takes FOREVER...
[12:43] <ikey> "god, I hate arm" - which one? :trollface:
[12:43]  * ikey legs it
[12:43] <zyga-suse> Son_Goku: how is that possible?
[12:43] <zyga-suse> ah
[12:43] <zyga-suse> Son_Goku: mongodb driver is a part of golang?
[12:43] <Son_Goku> no, it's the mgo driver the niemeyer wrote
[12:47] <ogra> "the niemeyer" ... <highlander voice> there can be only one, my friend </highlander voice>
[12:47] <ogra> :)
[12:49] <niemeyer> How would snapd depend on it transitively? It definitely doesn't in general
[12:52] <Son_Goku> https://koji.fedoraproject.org/koji/rpminfo?rpmID=10629107
[12:52] <Son_Goku> if this is an error, then tell me, so I can poke someone to fix it
[12:53] <mvo> Son_Goku: thanks for the reminder, mwhudson offered to help me with pushing the patch from https://github.com/golang/go/issues/20556 to upstream, I had some problems with the account creation
[12:53] <Chipaca> niemeyer: o/
[12:53] <pedronis> niemeyer: we are using mgo.v2/bson  seems to bring in stuff on distros
[12:53] <Son_Goku> mvo, well, I noticed it when I audited the source tree to update dependencies
[12:54] <Son_Goku> when I see weird forks and stuff like that, I want to be sure I can avoid them :)
[12:55] <Chipaca> Son_Goku: that's because you hate freedom
[12:55] <Chipaca> oh wait no that was us
[12:55] <Son_Goku> :)
[12:56] <Chipaca> is spread on linode having a bad day?
[12:57] <niemeyer> pedronis: I see.. that doesn't make a lot of sense, in quite a few ways
[12:58] <niemeyer> First, it's a build dependency..
[12:58] <niemeyer> Then, it's a driver.. building something with a driver shouldn't bring in a database
[12:58] <Son_Goku> yeah, as a result, I can't build snapd
[12:59] <niemeyer> Son_Goku: How come?
[12:59] <Son_Goku> pulling that godep causes it to try to install mongo, and mongo wasn't rebuilt for new boost successfully because borkiness in test suite on s390x
[13:00] <pedronis> niemeyer: yea, but it's a problem in the mgo packages , not in snapd afaiu
[13:00] <Chipaca> I interrupt this fascinating documentary about how all packaging is broken all the time to bring you this bit of news: it's standup o'clock
[13:00] <pedronis> Chipaca: :)
[13:00] <Son_Goku> pedronis: yep
[13:00] <niemeyer> Son_Goku: That makes no sense on itself, even despite anything else, right?
[13:01] <Son_Goku> unless you expect to run the mgo unit tests in your build, I think it doesn't make sense to be a hard dep
[13:02] <Son_Goku> after all, the server could exist somewhere else, in theory
[13:02] <Son_Goku> unless the driver requires the mongodb C libs to build correctly
[13:10] <ogra> mvo, did you see the discussion on https://forum.snapcraft.io/t/in-progress-snapd-2-27-1/572 ?
[13:11] <ogra> (i guess we should pull the xdg fix into 2.27.1)
[13:15] <zyga-ubuntu> morphis: hey
[13:15] <zyga-ubuntu> morphis: around?
[13:15] <morphis> zyga-ubuntu: hey!
[13:16] <morphis> zyga-ubuntu: what's up?
[13:16] <zyga-ubuntu> morphis: would you have a moment for a opensuse package review?
[13:16] <morphis> sure
[13:16] <zyga-suse> excellent, I'll put the sync request up soon
[13:31] <zyga-suse> Chipaca: that's for you: https://github.com/snapcore/snapd/pull/3725
[13:31] <mup> PR snapd#3725: osutil: honor SNAPD_UNSAFE_IO for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/3725>
[13:31] <mup> PR snapd#3725 opened: osutil: honor SNAPD_UNSAFE_IO for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/3725>
[13:33] <Chipaca> zyga-suse: https://people.canonical.com/~john/howmanyvmsdoesittake
[13:33] <zyga-suse> hehe
[13:33] <Chipaca> zyga-suse: (also it's curl-able)
[13:34] <zyga-suse> Chipaca: oh, lovely, how did you do that?
[13:34] <Chipaca> zyga-suse: apache is magic
[13:34] <zyga-suse> ah, via apache
[13:34] <Chipaca> :-)
[13:35] <zyga-suse> I didn't know we can do that on p.c.c
[13:36] <zyga-suse> mvo: ok, I'll do your backport now
[13:45]  * zyga-ubuntu actually goes to eat something
[13:48] <mvo> zyga-ubuntu: \o/
[13:48] <Son_Goku> damn, I really should go to work now
[13:49] <zyga-suse> Son_Goku: thank you for the updates!
[13:49] <Son_Goku> np
[13:49] <Son_Goku> I suspect I'm going to have 2.27.2 soon, aren't I?
[13:50] <zyga-suse> yed
[13:50] <zyga-suse> yes*
[13:50] <zyga-suse> I need to backport one thing
[13:50] <zyga-suse> and we need two cherry picks from master
[13:50] <zyga-suse> sorry about that :(
[13:50]  * Son_Goku shrugs
[13:51] <Son_Goku> I'm only really annoyed when it's really close to making it into the repository
[13:51] <Son_Goku> because each update resets the counter
[13:52] <zyga-suse> we feel it the same way for ubuntu and elsewhere :/
[13:55] <Son_Goku> and because no one ever tests the Fedora snapd updates, it's aggravating
[13:55] <zyga-suse> I will start doing that again, sorry for letting you down there :/
[13:55] <Son_Goku> because I have to wait the full five days, and then it has to be reset :/
[13:55] <zyga-suse> what is the average rate of tests for a package?
[13:56]  * Son_Goku shrugs
[13:56] <zyga-suse> in bodhi I mean
[13:56] <Son_Goku> the stats are in Bodhi itself
[13:56] <Son_Goku> https://bodhi.fedoraproject.org/metrics
[13:56] <Son_Goku> https://bodhi.fedoraproject.org/releases/F26
[14:16] <niemeyer> mvo: Do we have a topic for the known issue with snapd reverts?
[14:16] <niemeyer> mvo: core revert leaving snapd unrestarted, that is
[14:18] <mvo> niemeyer: not yet, let me add it
[14:18] <niemeyer> mvo: Thanks!
[14:30] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3726
[14:30] <mup> PR snapd#3726: interfaces: backport broadcom-asic-control interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
[14:30] <zyga-ubuntu> morphis: ^^
[14:31] <mup> PR snapd#3726 opened: interfaces: backport broadcom-asic-control interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
[14:31] <mvo_> niemeyer: https://forum.snapcraft.io/t/snapd-not-restarting-on-revert/
[14:33] <mup> PR snapd#3727 opened: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[14:33] <zyga-ubuntu> mvo_: anything else I can help with wrt 2.27?
[14:34] <mup> PR snapd#3728 opened: tests: adding more debug information for the interfaces-cups-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3728>
[14:35] <mup> PR snapd#3728 closed: tests: adding more debug information for the interfaces-cups-control test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3728>
[14:35]  * zyga-ubuntu reboots
[14:36] <mup> PR snapd#3729 opened: store: do not resume a download when we already have the whole thing  (2.27) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3729>
[14:36] <ikey> i think the arch nvidia code might be broken
[14:37] <ikey> https://ibin.co/3WrQ0U7eu5Ao.png
[14:37] <ikey> getting the undefined symbol issues .. which i shouldnt be getting
[14:37] <ikey> unless its mercilessly copying across host side GL libs regardless of whether or not its nvidia
[14:37] <mvo_> zyga-suse: I think we are good otherwise
[14:39] <mup> PR snapd#3730 opened: tests: adding more debug information for the interfaces-cups-control … <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3730>
[14:40] <mup> PR snapd#3731 opened: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3731>
[14:40] <mup> PR snapd#3732 opened: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3732>
[14:40] <ikey> ah
[14:40] <ikey> 	if (config->on_classic_distro) {
[14:40] <ikey> 		sc_mount_nvidia_driver(scratch_dir);
[14:40] <ikey> 	}
[14:40] <ikey> its unconditional
[14:40] <ikey> reality being it should only actually mount in the presence of the nvidia driver
[14:40] <ikey> that came out wrong..
[14:43] <ikey> we basically need this in mount-support-nvidia.c sc_mount_nvidia_driver:
[14:43] <ikey> 	if (access(SC_NVIDIA_DRIVER_VERSION_FILE, F_OK) != 0) {
[14:43] <ikey> 		return;
[14:43] <ikey> 	}
[14:43] <mvo_> zyga-suse: all 2.27 bits are now running tests, fingers crossed, once things are green I will work on 2.27.2
[14:43] <ikey> and make the define global, not limited purely to ubuntu impl
[14:47] <zyga-suse> mvo_: conflict on 3732
[14:48] <zyga-suse> ikey: aha, indeed - a similar check exists for the more-tested ubuntu path
[14:48] <zyga-suse> ikey: thank you for finding that
[14:48] <ogra> mvo_, since you didnt answer my pings, pinging again ... did you see the xdg-open discussion on the 2.27.1 thread ?
[14:48] <ikey> ill stick the patch into solus and build a VM with it zyga-suse
[14:48] <zyga-suse> ogra: I think he did
[14:48] <ikey> if that works ill submit the PR
[14:48] <ogra> (just want o make sure it doesnt get missed)
[14:48] <zyga-suse> ogra: that's why we are getting 2.27.2
[14:48] <ogra> awesome
[14:48] <zyga-suse> ikey: sounds good
[14:49] <ikey> looks like this atm https://hastebin.com/afozimumuv.swift
[14:49] <ogra> zyga-suse, i didnt want to be pushy ... just didnt know if he saw it
[14:50] <zyga-suse> it's all good :)
[14:50] <ogra> :)
[14:52] <chad_young> anyone free to help with snapcraft.yaml file issues?
[14:53] <zyga-ubuntu> chad_young: hey, what is the matteR?
[14:53] <chad_young> I am trying to snap mosquitto and the clients into one snap but I cant seem to put everything in it place
[14:53] <chad_young> I have a file on github - its the "clean" version
[14:54] <mup> PR snapd#3691 closed: tests: installing snapd for nested test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3691>
[14:54] <chad_young> i.e. default
[14:56] <chad_young> file is here: https://github.com/chadyoungdell/Ubuntu-Core/blob/master/IOT_Apps/Mosquitto/snapcraft.yaml
[14:57] <chad_young> when I snap the "mosquitto" service does start but after I try adding the client file the snap complete
[14:58] <tpatel> can I update my snap from my own snap, rather than waiting on auto refresh?
[15:02] <niemeyer> "We went looking everywhere, but couldn’t find those commits.
[15:02] <niemeyer> Sometimes commits can disappear after a force-push. Head back to the latest changes here."
[15:02] <niemeyer> That's why we don't force-push after reviews are up.. :/
[15:02] <niemeyer> (aka "rebase")
[15:04] <ogra> chad_young, why cant you use the existing snap package of mosquitto ?
[15:04] <ogra> is that missing anything ?
[15:05] <ogra> oh, sorry
[15:05] <ogra> missed that you want to bundle clients
[15:05] <chad_young> np :)
[15:06] <niemeyer> Irony: I went to add 10 more machines to our Linode pool, and found all 70 machines down right now.
[15:06] <niemeyer> As in, powered off..
[15:06] <Son_Goku> :D
[15:06] <niemeyer> I don't recall ever having seen all of them powered down at once :)
[15:07] <zyga-ubuntu> niemeyer: maybe we should have a dynamic scaling thing
[15:07] <zyga-ubuntu> niemeyer: at least 10, at most 150
[15:07] <zyga-ubuntu> not sure what the pricing model is
[15:07] <niemeyer> zyga-ubuntu: Right, that's the tricky bit
[15:08] <zyga-ubuntu> if that is competetive maybe linode should just make that easy
[15:08] <zyga-ubuntu> (it must be saving real stuff for them)
[15:08] <zyga-ubuntu> I wish they had as "dormant" pricing for powered off machines
[15:08] <niemeyer> zyga-ubuntu: They do make it easy, and they are also smart about it
[15:09] <niemeyer> zyga-ubuntu: The cost of holding one of those machines for a month is $10, but the price per hour is .015.. do the math
[15:09] <ogra> tpatel, yes you can by using a local snap file and the --dangerous flag for "snap install" but it wont auto-update anymore then
[15:09] <zyga-ubuntu> aww :D
[15:10] <zyga-ubuntu> niemeyer: that's both good and not good, I wish there was at least, say, 30% delta
[15:10] <zyga-ubuntu> worth the money to make our side smarter
[15:11] <niemeyer> zyga-ubuntu: In practice, it's cheap.. that level of machine is much more expensive on other providers
[15:12] <zyga-ubuntu> niemeyer: 30% of 100 is still 30 :D but I see the point
[15:12] <zyga-ubuntu> I wonder if we could marry spread and juju to be cross-cloud one day
[15:13] <tpatel> orga: can I issue 'snap refresh' which should pull it from store and update it?
[15:13] <niemeyer> zyga-ubuntu: spread is cross-cloud
[15:13] <ogra> not sure about that ... but i dont think so
[15:13] <niemeyer> zyga-ubuntu: and cross-your-disk too:)
[15:13] <zyga-ubuntu> niemeyer: well, arguably the disk image is something that is tricky but this feels like a problem somehow must have solved
[15:13] <niemeyer> zyga-ubuntu: But part of the point is having something that tends to work without us having to spend a lot of time on this
[15:13] <ogra> (note that --dangerous is rather for developers when testing locally built snaps before uploading to the store)
[15:14] <niemeyer> zyga-ubuntu: Your time has a cost, you know :)
[15:14] <mvo_> ogra: sorry, must have missed the earlier ping. I noticed the issue with xdg-open, I pushed a PR that shouöd fix it
[15:14] <ikey> yeah my gl patch works
[15:14] <ogra> mvo_, yeah, i saw that now ... sorry for the noise (though there is a conflict)
[15:14] <zyga-ubuntu> niemeyer: I know, hence me saying "worth the money to make our side smarter"
[15:15] <mvo_> ogra: thanks, looking into this one now
[15:17] <ikey> zyga-suse, should i add the new patch to my existing PR?
[15:18] <mup> PR snapd#3732 closed: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3732>
[15:19] <niemeyer> zyga-ubuntu: We now have 70 machines running (!).. how much would AWS charge for 70 machines running for 1h?  More than $3, and that's assuming no network, no local SSD, etc...
[15:19] <zyga-suse> Chipaca: FYI, I applied the unsafe-io patch for tests to opensuse and it's a fantastic improvement
[15:21] <mvo_> jdstrand: if you could do a quick sanity check of PR 3726, that would be great
[15:24] <pstolowski> niemeyer, should the 'upcoming' stories that already landed be tagged with 'done' now? (sorry, I missed the conclusion about the tag)
[15:25] <zyga-ubuntu> pstolowski: no, we should just drop the name and upcoming from the tags
[15:25] <pstolowski> zyga-ubuntu, ok, thx
[15:25] <mvo_> ogra: re pings> I had some network hickups today, my dsl provider seems to be unhappy, this is probably why I missed the pings
[15:26] <ogra> ah, k
[15:26] <niemeyer> 10 VMs added, please retry / let me know of issues
[15:26] <niemeyer> Note that some tests running moments ago may have failed
[15:26]  * niemeyer => lunch
[15:27] <ikey> anyone? re: pushing patch to existing PR..
[15:28] <jdstrand> mvo_: ok
[15:28] <mvo_> jdstrand: thanks! should be super trivial I hope, straight backport from master just the old layout instead of the new commonInterfaces code
[15:30] <mup> PR snapd#3729 closed: store: do not resume a download when we already have the whole thing  (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3729>
[15:33] <ahasenack> hi guys, I'm having a problem installing a snap: http://pastebin.ubuntu.com/25312811/
[15:33] <ahasenack> getting a 404
[15:33] <ahasenack> was getting the same 404 a few moments ago for an older revision, 117
[15:34] <ogra> ahasenack, https://forum.snapcraft.io/t/snap-install-refresh-fails-with-404/1676
[15:34] <ogra> ??
[15:34] <ahasenack> let me try re-login
[15:35] <ahasenack> ogra: logout/login fixed it for me
[15:35] <ogra> yeah, thought so
[15:39] <mvo_> pedronis: thanks a lot for your feedback on the ensureCore PR!
[15:40] <jdstrand> mvo_: done
[15:41]  * mvo_ hugs jdstrand
[15:41]  * jdstrand hugs mvo_ back :)
[15:42]  * mvo_ hugs zyga-ubuntu for making the PR in the first place
[15:42]  * zyga-ubuntu blushes :)
[15:42] <mvo_> just one more to go for 2.27.2 :)
[15:46] <pedronis> mvo_: np, I fear the move is a bit more complicated than we thought, also the code we had in api is okish for classic, but if we need to support based etc we will need to be more careful about failure modes
[15:46] <pedronis> s/based/bases/
[15:47] <zyga-suse> morphis: https://build.opensuse.org/request/show/516894
[15:47] <mvo_> pedronis: indeed, I ponder some more how to make it more robust in the morning, its good feedback :)
[15:47] <pedronis> niemeyer: we never tried but I suppose we do support waiting for tasks across changes? at least we they are different lanes?
[15:48] <pedronis> s/we they/if they/
[15:51] <zyga-ubuntu> mvo_: hmm
[15:51] <zyga-ubuntu> mvo_: the upgrade/basic test failed with "no registered handlers for hook "install"
[15:51] <zyga-ubuntu> mvo_: what was the resolution for that?
[15:51] <zyga-ubuntu> mvo_: was it just a silly test or do we need action?
[15:52] <mvo_> zyga-ubuntu: iirc this has only happend when we went "upgraded" from master to 2.27, i.e. when the versions are out of sync, iirc I did a PR for the 2.27.1 changelog?
[15:52]  * mvo_ looks
[15:53] <mvo_> zyga-ubuntu: hm, edge should be ok, i.e. master - where do you see this error?
[15:53] <mvo_> zyga-ubuntu: when pstolowski and I last looked at it we had this version issue but if you see it on a current branch then it might be something deeper
[15:53] <zyga-ubuntu> mvo_: here, on ppc https://github.com/snapcore/snapd/pull/3726
[15:53] <mup> PR snapd#3726: interfaces: backport broadcom-asic-control interface (2.27) <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
[15:53] <zyga-ubuntu> mvo_: on the backport branch
[15:54] <mvo_> zyga-ubuntu: aha, in autopkgtest
[15:55] <mvo_> zyga-ubuntu: I need to look but the version in the log look a bit bogus
[15:56] <mvo_> pedronis: InstallMany is a real problem, you are right
[15:56] <Chipaca> hmm... the work i'm doing for package names / cnf could just as well apply to sections
[15:58] <Chipaca> ogra: is /var/cache writable on core? (do you know without checking?)
[15:58] <Chipaca> otherwise i can check myself :-D
[15:59] <ogra> ogra@nanopi:~$ touch /var/cache/foo
[15:59] <ogra> touch: cannot touch '/var/cache/foo': Read-only file system
[15:59] <ogra> :P
[15:59] <ogra> i can check faster :P
[15:59] <ogra> Chipaca, /var/cache/apparmor is writable
[16:00] <Chipaca> /var/lib/snapd/cache it is then :-D
[16:00] <ogra> but nothing on the higher level
[16:00] <ogra> well, you could have /var/cache/snapd
[16:00] <ogra> if that feels cleaner
[16:00] <ogra> it is trivial to add
[16:01] <Chipaca> I'm not convinced it is better, but good to know -- i'll mention it in the PR
[16:02] <chad_young> looking for help on the mosquitto snap (all inclusive- broker and pub/sub)
[16:02] <chad_young> I have both parts working - just cant get the combined to work
[16:02] <chad_young> that is broker in one snap and pub/sub in another
[16:05] <Chipaca> chad_young: how is it not working? that is, what errors do you see?
[16:05] <ogra> whats the exact issue ?
[16:05] <ogra> the snapcraft.yaml you linked above looks okayish
[16:07] <chad_young> usually when I add the client portion the snap create fails as it cant find a "config.mk" - which is there in the folder
[16:08] <chad_young> there are two make files - one for the broker and one for the client - each using the same config.mk file
[16:10] <ogra> just add another part ?
[16:11] <chad_young> I did that but it still failed - I will update the yaml file on the github and comeback when its ready
[16:11] <ogra> well, show us code and errors ... :)
[16:11] <ogra> like Chipaca said
[16:13] <chad_young> will do
[16:38] <zyga-ubuntu> Chipaca: hey
[16:38] <zyga-ubuntu> Chipaca: can you hand-hold me with tab completion issues again please
[16:38] <zyga-ubuntu> Chipaca: on opensuse now, I'm shipping the various files
[16:38] <zyga-ubuntu> Chipaca: (better yet, write a forum post)
[16:38] <zyga-ubuntu> Chipaca: enough for "tab completion doesn't work, here's some debug data for you to understand"
[16:39] <chad_young> ok @orga and Chipaca - here is the update
[16:39] <chad_young> https://github.com/chadyoungdell/Ubuntu-Core/tree/master/IOT_Apps/mosquitto.snap/snap
[16:40] <Chipaca> zyga-ubuntu: i'll hand-hold you, and if a pattern emerges, forum post
[16:40] <zyga-ubuntu> Chipaca: probably packaged something incorrectly
[16:40] <Chipaca> zyga-ubuntu: but … what issues are you seeing
[16:41] <chad_young> will post error in a sec
[16:41] <zyga-ubuntu> Chipaca: http in beta, http -<tab> does nothing
[16:42] <Chipaca> zyga-ubuntu: ok, so first of all, start a new terminal and tell me what you see for "complete -p -D"
[16:42] <chad_young> here is the error https://pastebin.com/BjM6KHU7
[16:42] <zyga-suse> zyga@faroe:~> complete -p -D
[16:42] <zyga-suse> complete -F _completion_loader -D
[16:43] <Chipaca> zyga-suse: ok, so you aren't sourcing complete.sh
[16:43] <zyga-suse> Chipaca: what should be doing that?
[16:43] <Chipaca> zyga-suse: you :-)
[16:43] <zyga-suse> as in, my profile?
[16:43] <Chipaca> zyga-suse: the need to add that to your .bashrc is addressed by snapd#3724
[16:43] <mup> PR snapd#3724: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
[16:44] <Chipaca> zyga-suse: well, we tried to make it automagic but hit a wall
[16:44] <Chipaca> so, in the snapd you have, you need to do this
[16:46] <zyga-ubuntu> ...
[16:46]  * zyga-ubuntu waits for what "this" is
[16:46] <Chipaca> zyga-ubuntu: this == "source complete.sh"
[16:46] <zyga-suse> aha
[16:47] <zyga-suse> as in
[16:47] <zyga-suse> zyga@faroe:~> . /usr/lib/snapd/complete.sh
[16:47] <zyga-suse> did that
[16:47] <Chipaca> zyga-suse: or . /snap/core/current/usr/lib/snapd/complete.sh
[16:47] <zyga-suse> no effect
[16:47] <zyga-suse> zyga@faroe:~> complete -p -D
[16:47] <zyga-suse> complete -F _complete_from_snap_maybe -D
[16:47] <Chipaca> ok, good
[16:47] <Chipaca> now
[16:47] <Chipaca> complete -p http
[16:48] <zyga-suse> zyga@faroe:~> complete -p http
[16:48] <zyga-suse> complete -F _minimal http
[16:48] <Chipaca> right, so you did http -<tab> _before_ sourcing complete.sh
[16:48] <Chipaca> so that loaded a completer for http
[16:48] <Chipaca> you need to remove it: complete -r http
[16:48] <Chipaca> and try again
[16:49] <zyga-suse> zyga@faroe:~> complete -r http
[16:49] <zyga-suse> zyga@faroe:~> complete -p http
[16:49] <zyga-suse> bash: complete: http: brak definicji dla uzupełnienia
[16:49] <Chipaca> zyga-suse: ok, http -<tab>?
[16:49] <zyga-suse> yep
[16:49] <zyga-suse> that worked!
[16:49] <zyga-suse> ok
[16:49] <Chipaca> ok
[16:49] <zyga-suse> so what should I do in general
[16:49] <zyga-suse> is it a default in opensuse
[16:49] <zyga-suse> is it something I can tweak in packaging?
[16:50] <Chipaca> zyga-suse: it depends on whether suse's shells always source /etc/profile or if it's only for login shells
[16:50] <Chipaca> zyga-suse: on debian it's only login shells
[16:51] <Chipaca> zyga-suse: on fedora it's all of 'em
[16:51] <Chipaca> afaik
[16:51] <zyga-suse> https://paste.gnome.org/pxh1jvxfw
[16:51] <zyga-suse> this is /etc/profile
[16:51] <Chipaca> zyga-suse: which is why in debian there's bash completion loaded twice, once in /etc/profile.d, once in .bashrc
[16:51] <Chipaca> zyga-suse: what's in /etc/skel/.bashrc
[16:51] <Chipaca> zyga-suse: bah
[16:52] <Chipaca> zyga-suse: easy way of answering what's going on is to try it and see :-)
[16:52] <zyga-suse> note, this is tumbleweed
[16:52] <zyga-suse> as in "sid"
[16:52] <Chipaca> zyga-suse: _but_, snapd#3724 would fix this
[16:52] <mup> PR snapd#3724: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
[16:52] <zyga-suse> https://paste.gnome.org/phffmxefk
[16:53] <zyga-suse> Chipaca: aha, I may just review it then :D
[16:54] <Chipaca> zyga-suse: basically, in a default user on suse, in a default gnome terminal tab (say), is bash tab completion enabled? and if it is, is it via /etc/profile.d, and if it is, can we drop /etc/profile.d/zzz-sneaky-snapd-completion in there that overrides the default completer
[16:54] <Chipaca> and then if a user has modified stuff it'll still break
[16:54] <Chipaca> so that PR is really the best approach
[16:55] <Chipaca> even though it'll require packaging tweaks (to remove snap completion snippets on purge)
[16:55] <zyga-suse> mmm, no idea
[16:56] <zyga-suse> note
[16:56] <zyga-suse> we have a file in /etc/profile.d
[16:56] <zyga-suse> snapd.sh is there
[16:56] <zyga-suse> as is snapd-xdg.sh
[16:56] <zyga-suse> (I will merge them actually)
[16:56] <mup> PR snapd#3718 closed: tests: enable regression and completion suites for opensuse <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3718>
[16:57] <cachio> mvo_, do you know who should I contact to get a connection to the machines where the autopkgtest for each build on travis?
[16:57] <chad_young> @orga have you had a chance to look at my update
[16:57] <nothal_> chad_young: No such command!
[16:57] <cachio> mvo_, I need that to see why the refresh-all* tests are failing
[16:58] <chad_young> orga: have you had a chance to look at my update
[16:58] <chad_young> Chipaca: same Q to you
[16:59] <Chipaca> chad_young: I'm afraid if it's a snapcraft problem I'm not the right person to help you
[17:01] <Chipaca> chad_young: it looks like you're missing a configure step
[17:02] <Chipaca> chad_young: if you run a "make" in the checkout of that git repository, does it work?
[17:03] <chad_young> yes, if I run make/make install in each folder seperately they both build
[17:03] <Chipaca> chad_young: what's 'each folder'?
[17:04] <Chipaca> chad_young: i guess your problem is the last bit, the 'client' part, where you tell it to make using a source of ../client
[17:04] <chad_young> looking at the github there is a make file in "src" folder for the broker and another make file in the "client" folder that makes the pub/sub client
[17:04] <Chipaca> chad_young: that would pull just the client directory somewhere, and config.mk is in the parent directory which would not be where the make expects it?
[17:05] <Chipaca> pure speculation on my part
[17:05] <Chipaca> note what it's not finding is ../config.mk
[17:05] <Chipaca> which is in the repository root
[17:05] <chad_young> if I look at the github I see config.mk in the root folder
[17:06] <Chipaca> yes
[17:06] <Chipaca> but you're trying to build the client with just the "client" subdirectory, without the config.mk from the root folder
[17:06] <chad_young> I am ?
[17:06] <Chipaca> that's what "source: ../client" means, isn't it?
[17:07] <chad_young> I thought that putting in "../client" was just telling make where the Makefile was
[17:09] <chad_young> since I am starting the snapcraft from the folder "snap" I thought I would have to specify that the new make file (for the clients) is in the "../client" folder
[17:12] <zyga-suse> Chipaca: re, sorry
[17:12] <zyga-suse> Chipaca: I'm EOD, let's catch up tomorrow
[17:13] <Chipaca> zyga-suse: k
[17:14] <Chipaca> chad_young: you're going to have to find somebody who knows more snapcraft than myself, I'm afraid
[17:19] <chad_young> Ok, Thank you
[17:39] <Chipaca> ok, this works. tests are a thing for tomorrow.
[17:39]  * Chipaca EODs
[17:49] <niemeyer> ikey: Not sure if someone responded to you yet, but we try to split up patches as much as we can
[17:49] <niemeyer> ikey: Within reason, of course.. but different ideas generally belong on different patches
[17:50] <ikey> niemeyer, its still the same idea
[17:50] <ikey> "Initial Solus support"
[17:51] <ikey> but I had a feeling it *might* be one way or the other
[17:51] <ikey> Which is why I asked ages ago
[17:51] <niemeyer> ikey: Well, we can also say that "snapd" is an idea.. :P
[17:51] <niemeyer> ikey: I really mean in terms of the logical change instead of the overall goal
[17:51] <ikey> Ack
[17:51] <niemeyer> ikey: Thanks for asking
[17:51] <ikey> you can ignore the secondary commit and ill open a second PR for it
[17:52] <ikey> likely wont be happening tonight as that came up during QA and we're prepping a solus release here
[17:52] <ikey> so it was more "emergency patch"
[17:52] <niemeyer> ikey: It ends up being much easier to review and consequently to get things merged
[17:52] <ikey> aye
[17:52] <niemeyer> ikey: otherwise a small controversy on a tiny part blocks the whole
[17:52] <ikey> yeah thats why i blitzed the other yokey
[17:52] <ikey> the mkversion thingy
[17:53]  * ikey can't word
[18:33] <tpatel> can i check within my snap if the interface is connected?
[18:35] <tpatel> can i check within my snap if the interface is connected?
[18:37] <mup> PR snapd#3731 closed: interfaces: allow /usr/bin/xdg-open in unity7 (2.27) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3731>
[18:45] <niemeyer> zyga-ubuntu, ikey, mvo: Folks, let's please stop supporting mkversion.sh to take the version as an argument..
[18:45] <niemeyer> Actually, let me open a forum topic for that
[18:45] <ikey> well im not gonna support dpkg-parsechangelog :p
[18:46] <niemeyer> ikey: mkversion.sh encodes the version into the filesystem
[18:46] <ikey> shouldn't the "if git" stuff be more relevant, with a well defined in-tree version?
[18:46] <ikey> vs "i have a vendored tarball that should know what its own version is"
[18:46] <niemeyer> ikey: There shouldn't be any need to support the changelog
[18:46] <ikey> because mkversion is mostly about dirty trees
[18:46] <ikey> from what i can tell.
[18:47] <niemeyer> ikey: No, clean trees produce clean versions as well
[18:47] <ikey> not in a vendor tarball :D
[18:48] <niemeyer> Well, that's exactly the point.. it shouldn't ever be run in a tarball.. the tarball should contain the actual version instead
[18:49] <ikey> right
[19:04] <niemeyer> Topic in the forum..
[19:11] <zyga-suse> niemeyer: sounds ok
[19:11]  * zyga-suse returned from a long walk
[19:19] <niemeyer> I should go out as well.. it's been a while since I've taken some proper sunlight..
[19:21]  * niemeyer steps out for a while
[19:29] <tpatel> Does brand store include all public snaps by default? If not, can I select the needed public snaps to be included in brand store?
[19:42] <noise][> tpatel: it is possible to either include the entire contents of the default store or select individual snaps
[19:47] <tpatel> noise: thanks. Will the selected public snaps when updated on the public store, gets auto update on the brand store as well?
[19:48] <noise][> yes
[19:55] <tpatel> noise: Can i control the public snap update to be updated on brand store? Make sure all the snap in my brand store are working without any issue with updated public snaps and then release them to stable.
[20:08] <mup> PR snapcraft#1436 closed: cli: properly handle exceptions <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1436>
[20:08] <mup> PR snapcraft#1486 opened: core: improve source caching logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1486>
[20:59] <mup> PR snapcraft#1487 opened: python plugin: record manifest <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1487>
[21:13] <mwhudson> woop https://buildd.debian.org/status/package.php?p=snapd
[21:47] <ahoneybun> anyone have example electron apps?
[21:47] <ahoneybun> looking to see if we can snap riot.im
[22:22] <Chipaca> ahoneybun: did you search the forum?
[22:35] <mup> PR snapd#3733 opened: switch to canonical path for gopkg.in/cheggaaa/pb.v1 <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3733>