[03:33] <abes> dragonboard emmc flashing instead of SD
[03:33] <abes> https://discuss.96boards.org/t/ubuntu-core-on-emmc/1611
[05:17] <mup> PR snapcraft#1304 opened: cleanbuild: set the container language to en_US.UTF-8 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1304>
[07:04] <mup> PR snapd#3284 closed: interfaces: ensure that legacy interface methods are unused <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3284>
[07:16] <zyga> good morning
[07:16] <zyga> hey there mvo! :)
[07:16] <zyga> thanks for merging that :)
[07:16] <zyga> woot, we are on one-page-long of PRs :)
[07:20] <mvo> zyga: hey, good morning
[07:23] <mup> PR snapd#3286 closed: cmd/snap: tweak info channels output <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3286>
[07:32] <zyga> mvo, jdstrand, tyhicks: in addition to coverity I would consider adding https://github.com/google/oss-fuzz
[07:38] <pstolowski> morning
[07:39] <zyga> hey hey :)
[07:40] <zyga> pstolowski: can you please merge master into https://github.com/snapcore/snapd/pull/3119 and add the extra description for the old interface methods
[07:40] <mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
[07:40] <pstolowski> zyga, yes, doing right now
[07:40] <zyga> excellent, thank you!
[07:57] <mup> PR snapd#3287 opened: tests: unify tests/{main/completion,completion}/lib.exp0 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3287>
[07:58] <mup> PR core-build#10 closed: make /etc/environment writable <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/10>
[08:27] <Chipaca> zyga: ^ 3287 should fix the expect timeouts
[08:32] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[08:38] <zyga> Chipaca: looking
[08:41] <zyga> Chipaca: thank you!
[08:44] <pstolowski> zyga, update iface-hooks-api with master, waiting for tests
[08:45] <zyga> pstolowski: did you find any stale APIs?
[08:46] <pstolowski> zyga, note, I didn't add the checkers for optional ValidatePlug/Slot methods since they really appear in the followup PR #3120, so if we want them, they should be added in that other PR
[08:46] <pstolowski> zyga, yes, but only in the "expected" ones (new interfaces that appeared in msaster)
[08:46] <pstolowski> *master
[08:47] <zyga> pstolowski: excellent, thank you!
[09:19] <morphis> zyga: feeling comfortable to give https://github.com/morphis/meta-snappy/pull/9 a shot?
[09:19] <mup> PR morphis/meta-snappy#9: Add support for pyro and drop golang toolchain <Created by morphis> <https://github.com/morphis/meta-snappy/pull/9>
[09:20] <zyga> morphis: yes, if you tell me how to try this
[09:21] <morphis> zyga: https://github.com/morphis/meta-snappy/blob/master/README.md but checkout out the pyro branch of poky instead of morty
[09:21] <zyga> ok
[09:24] <zyga> morphis: btw, what is it with the naming scheme?
[09:24] <zyga> pyro/morty/poky?
[09:24] <morphis> pyro and morty are release code names
[09:25] <morphis> poky is the name of the collection of recipes Yocto releases
[09:25] <morphis> https://www.yoctoproject.org/tools-resources/projects/poky
[09:26] <morphis> morty is the current stable release and pyro the next one
[09:26] <morphis> https://wiki.yoctoproject.org/wiki/Releases
[09:27]  * zyga mentally paste's chipaca's signature ascii emoji
[09:30] <zyga> mvo: is good-to-go, if you want you can override the review from gustavo (it is applied) and merge when green https://github.com/snapcore/snapd/pull/2929
[09:30] <mup> PR snapd#2929: interfaces/builtin: add storage-framework-service interface <Created by michihenning> <https://github.com/snapcore/snapd/pull/2929>
[09:32] <mvo> zyga: nice, thank you
[09:37] <Chipaca> zyga: you mean ヽ(´▽`)/ right?
[09:41] <zyga> Chipaca: lol :D
[09:41] <Chipaca> zyga: ( ˘ ³˘)♥
[09:44] <Chipaca> zyga: do the mount namespace thingies do the right thing on snapd restart?
[09:45] <mup> PR snapd#3287 closed: tests: unify tests/{main/completion,completion}/lib.exp0 <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3287>
[09:45] <zyga> Chipaca: which is?
[09:45] <zyga> Chipaca: (we don't touch them)
[09:45] <zyga> Chipaca: which is arguably perhaps wrong (I have a bug open for that)
[09:45] <Chipaca> zyga: I don't know what the right thing is :-)
[09:45] <zyga> https://bugs.launchpad.net/snapd/+bug/1667479
[09:45] <mup> Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479>
[09:46] <zyga> Chipaca: I only know about this thing being wrong
[09:46] <Chipaca> zyga: but i was wondering whether it was leftover state that could break if expectations changed
[09:46] <zyga> which is a special case of update-ns
[09:46] <zyga> aha
[09:46] <zyga> Chipaca: each test restore code unmounts them
[09:46] <zyga> Chipaca: so they should go away
[09:46] <zyga> Chipaca: as for restart
[09:46] <zyga> Chipaca: we re-gen new seccomp and apparmor profiles then but those don't affect the mount namespace
[09:47] <zyga> Chipaca: we don't regenerate (or update as update-ns is not finished) the mount profiles
[09:52] <pedronis> mvo: hi, I +1ed snapd#3263 but it seems to have failing tests
[09:52] <mup> PR snapd#3263: snap: make `snap prepare-image --extra-snaps` derive side info <Created by mvo5> <https://github.com/snapcore/snapd/pull/3263>
[09:52] <mvo> pedronis: thanks, checking now
[09:54] <mvo> pedronis: test failures were in the completion tests, I think some fixes went into master, lets see if that helps
[09:56] <Chipaca> zyga: and should we?
[10:04] <zyga> Chipaca: yes
[10:05] <zyga> Chipaca: we should return to that
[10:05] <zyga> Chipaca: it dates back to the BuildID thing
[10:09]  * zyga thinks that https://github.com/snapcore/core-build/pull/11 is scary
[10:09] <mup> PR core-build#11: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[10:10] <zyga> mvo: what are your thoughts on https://github.com/snapcore/snapd/pull/3226#discussion_r115584968
[10:10] <mup> PR snapd#3226:  snap-repair: add `snap-repair run`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3226>
[10:10] <Chipaca> brb, new kernel to test
[10:11] <zyga> pstolowski: some test failures here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/ppc64el/s/snapd/20170510_094222_ff1d7@/log.gz
[10:11] <pstolowski> looking
[10:11] <zyga> pstolowski: for your 3120 PR
[10:13] <zyga> morphis: I'll look at building oe soon
[10:13] <zyga> morphis: but I will do a few more reviews before that
[10:13] <morphis> zyga: ok
[10:13]  * zyga looks at mvo's https://github.com/snapcore/snapd/pull/2592
[10:13] <mup> PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
[10:15] <zyga> fgimenez: hey, do you know why the openvswitch tests are failing? I see them fail frequently
[10:15] <zyga> fgimenez: e.g. debian-unstable-64:tests/main/interfaces-openvswitch failed here: https://travis-ci.org/snapcore/snapd/builds/230619514?utm_source=github_status&utm_medium=notification
[10:16] <fgimenez> zyga: looking
[10:16] <zyga> fgimenez: thanks!
[10:17] <mvo> zyga: makes sense, no disagreement, I think we need to consider how far we want to go in each iteration
[10:17] <mvo> zyga: re the reapir run code question
[10:18] <morphis> pedronis: is the syntax of the `snap alias` command changing with the upcoming 2.26?
[10:18] <pstolowski> zyga, ah, looks like one of the failing spread tests needs some reworking now. thanks, will look at it some time later. in the meantime it looks like 3119 is ok
[10:19] <zyga> pstolowski: great, do you want to wait for gustavo's review
[10:21] <fgimenez> zyga: the package installation seems to fail in debian-unstable https://travis-ci.org/snapcore/snapd/builds/230619514#L2868 i haven't seen this error on ubuntu
[10:21] <fgimenez> zyga: i'll try to reproduce and get a debug console for getting more info
[10:22] <zyga> fgimenez: thank you!
[10:22] <zyga> fgimenez: note that it happens frequently but not always
[10:23] <zyga> perhaps related to ordering?
[10:23] <zyga> fgimenez: can I restart that run now?
[10:23] <fgimenez> zyga: ok thanks! no idea, will let you know how it goes
[10:23] <pstolowski> zyga, with 3119 yes, i'd like niemeyer to review it too
[10:23] <zyga> pstolowski: ok
[10:26] <pedronis> morphis: ?
[10:26] <pedronis> it already changed in 2.25
[10:27] <morphis> pedronis: hm, which isn't yet in stable, right?
[10:27] <pedronis> no
[10:27] <morphis> that would explain why it breaks all our tests
[10:28] <morphis> but only when run against edge/beta/candidate
[10:28] <pedronis> morphis: what kind of tests?
[10:28] <zyga> morphis: you have some real test failures on https://github.com/snapcore/snapd/pull/3222
[10:28] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[10:28] <morphis> pedronis: spread tests we have for all snaps we maintain
[10:29] <morphis> pedronis: we call `snap alias pulseaudio parec` and then expect /snap/bin/parec to show up
[10:29] <pedronis> morphis: aliases work very differently now, unless you have them setup in the store, there is little point in playing witht them, it is something only the user can do now picking their own names
[10:29] <morphis> pedronis: we have them all in the store
[10:30] <pedronis> morphis: ok, then not sure why you are using "snap alias" in those tests, we their are not the main spread tests
[10:30] <morphis> pedronis: need to look a bit more into that
[10:30] <pedronis> bit confused here
[10:31] <morphis> pedronis: we list them in snapcraft.yaml
[10:31] <morphis> and then a `snap alias pulseaudio pactl` call was meant to create the alias in /snap/bin
[10:31] <pedronis> morphis: well if they are in the store, no need for that
[10:31] <morphis> the snap-declaration in the store allows those aliases to be setup automatically
[10:32] <pedronis> I mean that tests is not relevant anymore
[10:32] <pedronis> that doesn't work that way, it's not inteded to work that way anymore
[10:32] <pedronis> you get what the store sets up
[10:32] <morphis> pedronis: so how do I get now an alias for a locally installed snap?
[10:33] <pedronis> morphis: it's all in the forum post:  https://forum.snapcraft.io/t/improving-the-aliases-implementation/18
[10:33] <pedronis> morphis: you can setup what we call manual aliases
[10:33] <pedronis> the syntax is a bit different:   snap alias  SNAP.APP ALIAS
[10:33] <morphis> ah
[10:33] <morphis> that is why it breaks
[10:33] <morphis> so a `snap alias pulseaudio pactl` doesn't work anymore
[10:34] <pedronis> yes, I said so maybe 3 times :)
[10:34] <morphis> but I didn't got the point that it now needs to be <snap>.<app>
[10:34] <pedronis> well, as I said I don't understand why you need that command?
[10:34] <pedronis> is the test installing the snap locally?
[10:34] <morphis> yes
[10:34] <pedronis> ah
[10:35] <morphis> pedronis: we were verifying that the alias defined in the snap was working
[10:35] <morphis> but as you said, that isn't needed anymore
[10:35] <pedronis> that doesn't make sense anymore
[10:35] <pedronis> there's is no alias defined in the snap concept anymore
[10:35] <pedronis> I mean you can fix the test  for the new syntax but as well drop it
[10:36] <pedronis> if the intention was checking the aliases in the snapcraft.yaml
[10:36] <pedronis> we will deprecate those at some point
[10:36] <morphis> ok
[10:37] <pedronis> anyway the forum post explains a bit all of this
[10:37] <morphis> pedronis: are all assertions on the store side are updated automatically?
[10:37] <pedronis> morphis: we did a pass of doing that with jdstrand
[10:37] <morphis> if I remember well they just defined a list of allowed aliases like [pactl, parec]
[10:37] <morphis> pedronis: great
[10:38] <zyga> linode seems busy now
[10:38] <zyga> coffee break then :)
[10:38] <pedronis> morphis: the syntax is a bit different in the assertion as well, at the moment we defined both old and new syntax in the assertions (the store checks for that)
[10:38] <morphis> good
[10:38] <pedronis> because now the assertions needs to list a target too
[10:39] <morphis> pedronis: so with 2.25 going to stable it is safe to drop the aliases:  part from the snap, right?
[10:40] <morphis> however I think we will leave them for a bit more to gurantee everyone gets correctly updated
[10:40] <pedronis> yes, when all your clients you care about are updated to 2.25 though
[10:40] <morphis> yeah, that is tricky
[10:42] <pedronis> morphis: this is the pulseaudio assertion btw atm: http://pastebin.ubuntu.com/24548266/  you can see the old syntax (auto-aliases) and the new (aliases)
[10:42] <morphis> pedronis: thanks!
[10:42]  * pedronis lunch
[10:45] <Chipaca> as best as I can tell so far, cking's fix for bug #1672819 works
[10:45] <mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-da-key> <xenial> <Linux:Unknown> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):Incomplete by colin-king> <https://launchpad.net/bugs/1672819>
[10:45] <Chipaca> nearly done with all the reproducers
[10:52] <Chipaca> \o/
[11:06] <zyga> re
[11:12] <morphis> zyga: something has changed in suse.. https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/i586
[11:17] <zyga> morphis: aha, it seems that rst2man is no longer shipped by the package we install
[11:17] <morphis> yes
[11:17] <zyga> morphis: we can fix this by (perhaps) depending on /usr/bin/rst2man directly
[11:17] <zyga> (whatever the package name)
[11:19] <jdstrand> pedronis: re no alias in the snap concept> I still see these trickle in. should I add a warning (and therefore needs human review) to the review tools to let people know to not include that?
[11:20] <morphis> zyga: is there macro for that?
[11:20] <fgimenez> zyga: the openvswitch test is disabled for debian on master and is enabled in https://github.com/snapcore/snapd/pull/3274 right?
[11:20] <jdstrand> pedronis: also, I've been adding v1 to the snap declaration as a matter of course in all cases in case of rollbacks, etc. how long do you think I should do that?
[11:20] <mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
[11:20] <jdstrand> pedronis: also, hi :)
[11:20] <zyga> morphis: no, it's just Requires: /usr/bin/rst2man AFAIR, let me check
[11:21] <morphis> fgimenez: yes, something I still need to look into
[11:21] <morphis> zyga: nice, let me try that
[11:21] <zyga> fgimenez: yes, parts of that test are now enabled
[11:21] <zyga> fgimenez: note that this test was also failing on ubuntu
[11:21] <zyga> fgimenez: just not always
[11:21] <fgimenez> morphis: zyga aha ok thanks, i'll pull that branch and try to reproduce
[11:22] <zyga> fgimenez: it would be good to try to run that same seqeunce with -debug
[11:22] <fgimenez> zyga: do you have any reference to a failure in ubuntu? i haven't seen that one
[11:22] <mup> PR snapd#3263 closed: snap: make `snap prepare-image --extra-snaps` derive side info <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3263>
[11:22] <zyga> fgimenez: not at hand, I recall re-triggering tests a few times on this test
[11:22] <fgimenez> zyga: ok will try on ubuntu too
[11:24] <morphis> zyga: that requires line doesn't seem to help
[11:25] <mup> PR snapd#3288 opened: tests: disable create-key test on ppc64el for artful (expect not working) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3288>
[11:26] <zyga> morphis: let me look
[11:28] <zyga> morphis: maybe it's just a fedora thing, e.g. look at Requires: /sbin/ifconfig in https://fedoraproject.org/wiki/Packaging:Guidelines
[11:28] <morphis> possible
[11:28] <zyga> morphis: worth asking in a opensuse IRC channel perhaps?
[11:29] <zyga> morphis: or looking at a few random packages
[11:29] <morphis> yeah, let me spend a bit more time with this and then I will do that
[11:33] <morphis> zyga: ok, looks like it is python-doctuils vs. python3-docutils
[11:33] <jdstrand> mvo: hey, is 2.26 cut yet such that we are doing point releases?
[11:34] <mvo> jdstrand: not quite done yet, zyga brought 1689332 to our attention and I think we want to fix this first
[11:34] <jdstrand> mvo: ok. I just wanted https://github.com/snapcore/snapd/pull/3285 in there, but that is already in master so sounds like we are good
[11:34] <mup> PR snapd#3285: interfaces/network: workaround Go's need for NETLINK_ROUTE with 'net'. LP: #1689536 <Critical> <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3285>
[11:36] <zyga> mvo: do you need a hand with that? I will be done with reviews shortly (well, in 1-2 hours)
[11:36] <zyga> mvo: I can help you after the standup
[11:36] <pedronis> jdstrand: well 2.25 is not even in stable, it will take a bit
[11:36] <mvo> jdstrand: yes, that one is in
[11:37] <pedronis> jdstrand: but we do want to deprecate aliases in snap.yaml and not need auto-aliases in decls but it will take a while
[11:37] <jdstrand> pedronis: sure, I was more talking about making sure that PR made it into the correct branch if there was one outside of 2.26
[11:37] <mvo> zyga: it should be fine, I was thinking we could simply forbid to install ubuntu-core. existing systems with older ubuntu-core will auto-transition on refresh so it is really only a problem if you frehsly install ubuntu-core
[11:37] <zyga> mvo: I think we should instead ask if we need to release ubuntu-core ever again
[11:37] <jdstrand> pedronis: oh haha. you were talking about aliases. funny cause your comment actually sorta worked for what I was talking about with mvo :)
[11:38] <jdstrand> pedronis: ok, let me take a note of that and at some point I'll introduce a warning
[11:39] <mvo> zyga: maybe that works as well, we just need to make sure that the transition works for those people who install from old 16.04.1 mediums (dvd/thumb)
[11:48] <morphis> zyga: ok, fixed it: https://build.opensuse.org/package/show/home:mrmorph:branches:system:snappy/snapd
[11:51] <zyga> morphis: let's stop building for 42.1
[11:52] <zyga> morphis: why do we depend on openssh? for git clones?
[11:56] <pedronis> mvo: did we ever tested anything working but apt upgrade for 16.04.1 ?
[11:56] <ogra_> what else would you test ?
[11:58] <morphis> zyga: we now depend on ssh-keygen
[11:58] <jdstrand> mvo: oh (not that this needs to be handled with priority), did you see my PR for the classic snap?
[11:58] <zyga> ahh
[11:59] <jdstrand> mvo: (just want in on your radar)
[11:59] <ogra_> jdstrand, given you already uploaded it ... thats just paperwork :)
[12:00] <jdstrand> ogra_: indeed, but I didn't want someone to upload without it :)
[12:00] <ogra_> mvo, btw, could i have commit access to the core-snap branch (i'd have merged jamies PR already if i was able)
[12:00] <jdstrand> and let me tell you, my logs are much happier now :)
[12:00] <ogra_> yay
[12:00] <ogra_> there is another issue with the pty (again)
[12:01] <mvo> jdstrand: not sure, I have a look
[12:01] <ogra_> that i want to tackle soon
[12:01] <mvo> ogra_: not sure I can give you that, access is mostly done by gustavo
[12:01] <ogra_> niemeyer, can i get commit access to https://github.com/snapcore/classic-snap ?
[12:01] <jdstrand> mvo: https://github.com/snapcore/classic-snap/pull/9
[12:01] <mup> PR classic-snap#9: plugs classic-support and update dump for latest snapcraft <Created by jdstrand> <https://github.com/snapcore/classic-snap/pull/9>
[12:02] <jdstrand> mvo: again, not high priority
[12:03] <mvo> jdstrand: thank you!
[12:04] <mvo> jdstrand: merged, thank you. and you are very welcome to upload
[12:04] <jdstrand> mvo: thanks!
[12:06] <stokachu> noise][, cprov: could I get some assistance with https://forum.snapcraft.io/t/sosreport-moved-under-sosreport-team/480
[12:07] <mvo> ogra_: I will land #30 for snapcore/core and #5 for snapcore/core-build
[12:07]  * ogra_ checks
[12:07] <noise][> stokachu: I can take a look in a couple hrs i think
[12:07] <ogra_> is that the cloud stuff ?
[12:07] <stokachu> noise][: ok thanks
[12:08] <ogra_> mvo, perfect, i wanted to bring that up in todays standup ...
[12:10] <mup> PR core#30 closed: Update core snap cloud-init configuration <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/core/pull/30>
[12:10] <mup> PR core-build#5 closed: Update cloud-init configuration <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/5>
[12:10]  * ogra_ hugs mvo 
[12:10] <ogra_> rharper, ^^^ happy testing
[12:11] <mvo> ogra_: my pleasure, we really need to hug rharper here :)
[12:11] <ogra_> yeah
[12:13] <ogra_> mvo, oh, the second one needs a PPA upload and there is another sync missing that i need to do before
[12:13] <ogra_> (i'll handle that)
[12:13] <zyga> pstolowski: what are the next steps for https://github.com/snapcore/snapd/pull/3212
[12:13] <mup> PR snapd#3212: api, ifacestate: resolve disconnect early <Created by stolowski> <https://github.com/snapcore/snapd/pull/3212>
[12:13] <mvo> ogra_: cool, thank you
[12:13] <morphis> zyga: can you disable the 42.1 build?
[12:13] <zyga> morphis: let me know when you want to update the opensuse repository with the extra patches
[12:13] <zyga> morphis: yes
[12:14] <morphis> zyga: what do you mean with extra patches
[12:15] <zyga> morphis: extra build deps for the next release
[12:16] <morphis> ah
[12:16] <zyga> morphis: https://build.opensuse.org/package/show/system:snappy/snapd no longer builds for 42.1
[12:16] <morphis> I will propose a review soon
[12:16] <zyga> excellent, thank you!
[12:17] <pedronis> zyga: I need to look at it again it seems
[12:17] <pstolowski> zyga, probably a discussion whether we want to do anything about the fact that we may have conflicting changes (other than disconnect) in progress and currently there is no way to achieve this sort of dependency; plug CheckChangeConflict question needs adressing/answering but I haven't looked at this yet
[12:18] <pstolowski> s/plug/plus/
[12:23] <zyga> pedronis, pstolowski: aha, thank you;
[12:24] <zyga> Chipaca: can you do a trivial 2nd review on https://github.com/snapcore/snapd/pull/3288
[12:24] <mup> PR snapd#3288: tests: disable create-key test on ppc64el for artful (expect not working) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3288>
[12:24] <Chipaca> zyga: already am
[12:27] <zyga> thank you :)
[12:28] <mup> PR core-build#12 opened: sync missing deb upload into branch <Created by ogra1> <https://github.com/snapcore/core-build/pull/12>
[12:28] <jacekn> hello. Is there a way to install and connect snap to a slot in one step? I'm building a snap that will not start unless it's connected to log-observe slot
[12:29] <ogra_> morphis, mvo, https://github.com/snapcore/core-build/pull/12 please ...
[12:29] <mup> PR core-build#12: sync missing deb upload into branch <Created by ogra1> <https://github.com/snapcore/core-build/pull/12>
[12:29] <zyga> jacekn: if an assertion is present in the store it will connect to log-observe
[12:29] <zyga> jacekn: other than that, no]
[12:30] <morphis> zyga: https://build.opensuse.org/request/show/494230
[12:30] <morphis> ogra_: will have a look
[12:30] <ogra_> thx
[12:30] <zyga> morphis: thank you
[12:31] <zyga> morphis: I approved but perhaps we can drop the python-docutils dependency
[12:31] <zyga> morphis: is one needed for 42.2 and other for tumbleweed?
[12:32] <morphis> zyga: joining us?
[12:32] <morphis> zyga: I think so
[12:32] <jacekn> zyga: so I'm after allow-auto-connection yes? Where can I find docs about how to get it set up?
[12:34] <zyga> jacekn: I think you need to request a new snap declaration assertion from the store, jdstrand can set one up for you, I think
[12:34] <pedronis> pstolowski: givent that connect/disconnect involve exactly two snaps it should be possible to fix CheckChangeConflict
[12:34] <jacekn> zyga: ok thanks a lot
[12:34] <pedronis> (autoconnect is a different story but we will get there)
[12:35] <jdstrand> jacekn: follow the first bulletpoint under 'Process' in https://forum.snapcraft.io/t/process-for-reviewing-aliases-and-auto-connections/455
[12:37] <jacekn> jdstrand: aha (I was looking for something in the official docs: https://docs.ubuntu.com/core/en/reference/assertions/snap-declaration )
[12:37] <jdstrand> jacekn: this is all new
[12:37] <jdstrand> so the docs haven't caught up yet
[12:37] <pstolowski> pedronis, fair point. i'll take a look at this soon, got sidetracked by other things (namely snapctl outside of hooks)
[12:38] <jacekn> jdstrand: ok understood
[12:41] <mup> PR snapd#3289 opened: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
[12:43] <niemeyer> Mornings
[12:43] <niemeyer> mvo: I think you could as you were an admin on that repo, but done either way
[12:43] <niemeyer> mvo: I usually give access to a team rather than a person, btw..
[12:43] <niemeyer> mvo: snapd-committers in this case
[12:43] <niemeyer> ogra_: Done
[12:44] <mvo> niemeyer: thank you
[12:44] <ogra_> niemeyer, thanks ... i think that was rather special since it initially lived in a private branch...
[12:44] <ogra_> well, not private but personal
[12:44] <mup> PR snapd#3288 closed: tests: disable create-key test on ppc64el for artful (expect not working) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3288>
[12:44] <niemeyer> ogra_: Yeah, that should be it
[12:47] <mvo> zyga: 3262 has a conflict
[12:47] <mvo> zyga: looks good otherwise I think
[12:52] <zyga> mvo: I'll take care of that, thank you
[12:53] <mvo> ta
[13:05] <mup> PR core-build#12 closed: sync missing deb upload into branch <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/12>
[13:05] <ogra_> mvo, thx!
[13:19] <sborovkov> Hi. My snap build started failing recently. Because dbus-python can't be compiled... Anyone encountered such issue? dbus/dbus-arch-deps.h: No such file or directory. It's present though - /build/snaps/full/parts/playlist/install/usr/lib/arm-linux-gnueabihf/dbus-1.0/include/dbus/dbus-arch-deps.h
[13:20] <ogra_> sborovkov, do you have libdbus-1-dev in build-packages ?
[13:23] <sborovkov> ogra_: in stage-packages
[13:23] <sborovkov> is that incorrect
[13:23] <ogra_> try build-packages ...
[13:23] <sborovkov> thanks!
[13:27] <abeato> ogra_, is there any good description around of what UC does on first boot? Is there any special service that is run?
[13:28] <ogra_> abeato, well, the stuff happening before console-conf runs is probably only documented in the snapd source ... pedronis and mvo know the process in and out though ... then there is console-conf .... mwhudson is the specialist here
[13:29] <abeato> ogra_, ok
[13:30]  * abeato waiting for some more info from pinged guys ;)
[13:32] <zyga> abeato: yes it does special stuff
[13:32] <zyga> abeato: it installs all the pre-seeded snaps
[13:32] <zyga> abeato: and runs the device-prepare hook
[13:33] <sborovkov> ogra_: that helped, thanks!
[13:33] <ogra_> :)
[13:36] <ali1234> if i put snapcraft.yaml in the root of a repo, and it is a symlink to the real location, will it be dereferenced before running it? eg if it does things like "source ."?
[13:37] <abeato> zyga, where is that done? from a systemd unit?
[13:38] <zyga> abeato: internally by snapd
[13:38] <pedronis> abeato: it's all doen from inside snapd
[13:38] <pedronis> there are no special units anymore
[13:38] <ogra_> we should have some blog post or a doc for it one day ;)
[13:39] <abeato> zyga, pedronis got it, thanks
[13:39] <pedronis> abeato: notice thought that one of the things we discussed recently is to reintroduce some way to know seeding has happened at the systemd level
[13:39] <ogra_> a little step by step overview would be nice
[13:39] <pedronis> ogra_: yea, mvo or me should do at least a doc forum post on this
[13:39] <abeato> ogra_, +1
[13:39] <ogra_> +1
[13:39] <zyga> fg
[13:39]  * ogra_ backgrounds zyga again
[13:40] <fgimenez> zyga: no luck reproducing the openvswitch test error in isolation so far, will try the full suite next
[13:41] <zyga> fgimenez: perhaps get it to run with the same seed
[13:41] <zyga> fgimenez: as it failed in the PR
[13:41] <zyga> fgimenez: and thank you for checking!
[13:41] <fgimenez> zyga: indeed, i didn't save it though, do you happen to have it?
[13:41] <fgimenez> zyga: np :)
[13:42] <zyga> fgimenez: ah, I think not
[13:42] <fgimenez> zyga: no problem, i'll execute with -reuse in a loop
[13:42] <mup> PR snapd#3290 opened: add support for `snap install foo --channel=3.4` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3290>
[13:42] <zyga> thanks
[13:42] <mvo> fgimenez: could you please double check if 1689332 also happens with ubuntu-core from stable?
[13:46] <Chipaca> mvo: niemeyer: dunno if you decoded my blathering earlier about cking having found a fix for bug #1672819
[13:46] <mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-da-key> <xenial> <Linux:Unknown> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):Incomplete by colin-king> <https://launchpad.net/bugs/1672819>
[13:46] <Chipaca> was going to mention it in the standup and forgot
[13:46] <Chipaca> with that, and mwhudson having backported go 1.8's fix for the EAGAIN from pthread_create, we should have no more issues with exec
[13:49] <fgimenez> mvo: sure, on it, iirc snap and snapd weren't from the snap (2.25 was reported in snap version), will let you know how it goes
[13:49] <rharper> ogra_: mvo \o/
[14:06] <fgimenez> mvo: yes, all works fine with ubuntu-core from stable http://paste.ubuntu.com/24549041/
[14:06] <mvo> fgimenez: thank you!
[14:06] <ogra_> niemeyer, https://forum.snapcraft.io/t/allow-handling-of-certain-system-services-on-ubuntucore-images/531
[14:07] <zyga> who wants to take https://github.com/snapcore/snapd/pull/3291
[14:07] <mup> PR snapd#3291 opened: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[14:07]  * zyga goes to get some water and will garden PRs 
[14:08] <Chipaca> niemeyer: fyi go's ProxyFromEnvironment docs say the HTTP_PROXY and http_proxy are both checked (and the code confirms this)
[14:09] <Chipaca> not wanting to describe your trousers as aflame, but there's that
[14:10] <mvo> fgimenez: where is that test that was used to find bug 1689332 ?
[14:10] <mup> Bug #1689332: internal error with any command using ubuntu-core snap on classic <snapd:In Progress by zyga> <https://launchpad.net/bugs/1689332>
[14:10] <mvo> ogra_: can you please stop auto-building ubuntu-core for now?
[14:10] <ogra_> mvo, ok
[14:10] <zyga> pstolowski: maybe you? :)
[14:12] <ogra_> mvo, done (cronjob on lillipilly disabled)
[14:12] <mvo> ta
[14:13] <pstolowski> zyga, sure, will take a look
[14:13] <fgimenez> mvo: https://github.com/fgimenez/validator/blob/master/tests/tasks/validate-ubuntu-core-snap/task.yaml i've started adding there tasks that i needed to do manually before, and them wire it with spread-cron
[14:14] <fgimenez> mvo: in this case it is very similar to the transition tests in snapd's suite, but refreshing ubuntu-core to the channel with the new rev
[14:15] <mvo> fgimenez: I think we will just need to tweak like this: https://github.com/snapcore/snapd/pull/3289/commits/cecad5139c5867a03ae50607a46f1d5b35058b83
[14:15] <mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
[14:15] <mvo> fgimenez: I can have a look in  a tiny bit and then the test can continue to run as is. I will set all channels of ubuntu-core to the current stable release
[14:16] <mvo> fgimenez: i.e. we need a test that ensures the current ubuntu-core transitions correctly to core which I think this validation test is doing(?)
[14:16] <fgimenez> mvo: great, thank you! :) i'll give it a try
[14:17] <fgimenez> mvo: yes, the test is triggered when a new ubuntu-core is detected, does some validations that we don't have in snapd's transition test (rev number, snapd version) and then the same transition checks
[14:18] <zyga> Chipaca: maybe you can look at https://github.com/snapcore/snapd/pull/3291
[14:18] <mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[14:18] <zyga> Chipaca: if I can land this quickly I'll fixup the other PRs instead of constantly updating this one :)
[14:19] <zyga> Chipaca: (other meaning remaining branches that add new interfaces)
[14:20] <mup> PR snapcraft#1271 closed: tests: increase the staging registration limit to 100 <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1271>
[14:22] <Chipaca> zyga: 's good
[14:23] <zyga> Chipaca: btw, I didn't know that go sorts init() invocation order internally, I was pleasantly surprised. I added the sorting anyway to sort on interface name rather than file name but I think the result is the same
[14:24] <Chipaca> zyga: any sorting beyond dependency analysis is probably circumstantial
[14:24] <mup> PR core#21 closed: allow disabling of timesyncd and syslog (LP: #1504657, LP: #1587453) <Created by ogra1> <Closed by niemeyer> <https://github.com/snapcore/core/pull/21>
[14:29] <mup> Bug #1674794 changed: journald.conf storage=volatile config support <Snappy:Invalid> <https://launchpad.net/bugs/1674794>
[14:35] <fgimenez> mvo: works great, thanks a lot! :)
[14:37] <mvo> fgimenez: \o/
[14:39] <mvo> fgimenez: could we also run this test as part of spread cron when a new "core" is released? i.e. we will freeze ubuntu-core but we will still want to ensure that ubuntu-core->core works for each new core
[14:40] <fgimenez> mvo: sure sounds great, i'll prepare spread-cron branches to make it happen
[14:40] <mvo> fgimenez: thanks \o/
[14:42] <mvo> fgimenez: I updated edge for ubuntu-core, could you please run the test again to see if things are happy now?
[14:43] <juanrubio> Hi guys, wrt tizonia's snap pulseaudio issue that we discussed yesterday, I've noticed that pulseaudio is not accessible in 16.04 when my snap is installed without the --devmode flag...
[14:44] <zyga> juanrubio: do you get any apparmor denials (tip: dmesg | grep DENIED)
[14:45] <juanrubio> zyga: yes, I'm getting that
[14:45] <zyga> juanrubio: can you please share them
[14:46] <juanrubio> zyga: in Fedora 25, this work always (with or without --devmode)
[14:46] <zyga> juanrubio: in fedora 25 confinement is disabled
[14:49] <juanrubio> zyga: I see.
[14:49] <juanrubio> https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml
[14:49] <juanrubio> zyga: the snap link is coming
[14:49] <Chipaca> confinement is *currently* disabled
[14:50] <Chipaca> in the fullness of time that will not be the case
[14:50] <zyga> juanrubio: I'd rather see the list of denials on 16.04 than the snap
[14:52] <juanrubio> zyga: denials -> https://gist.github.com/juanrubio/d8752890ac6780d3627d9a1eae048de9
[14:56] <zyga> juanrubio: quick comment, what did you hope to achieve with this declaration? https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml#L21
[14:56] <zyga> juanrubio: (it is wrong)
[14:57] <zyga> morphis: [ 1832.541645] audit: type=1400 audit(1494426806.130:76): apparmor="DENIED" operation="connect" profile="snap.tizonia.tizonia" pid=7495 comm="audio_renderer" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" peer="unconfined"
[14:57] <zyga> morphis: does X11 use abstract sockets too?
[14:57] <pstolowski> niemeyer, i've read again all the comments you made to the old PR for snapctl-outside-of-hooks PR; I agree with almost all suggestions, but one is disputable/problematic; do you have a moment do discuss in the HO?
[14:57]  * ogra_ has a dejavu ... 
[14:57] <ogra_> zyga, the player uses mpris and dbus-x11
[14:57] <ogra_> we discussed that yesterday
[14:58] <zyga> juanrubio: the dbus plug/slot need an attribute, instead of saying: `plugs: [foo]' alone you need to say plugs: [my-happy-plug] and then in another section say plugs:\n  my-happy-plug:\n    interface: dbus\n    key: value... (with appropriate attributes)
[14:58] <ogra_> it will at least need the x11 interface (and ofr mpris even the unity7 one since i think no other interface provides mpris currently)
[14:58] <juanrubio> zyga: dbus? - tizonia uses a resource manager daemon, but that fuctionality is disabled right now
[14:58] <ogra_> s/ofr/for/
[14:58] <zyga> juanrubio: in any case, the dbus plug definition is wrong
[14:58] <ogra_> juanrubio, y<ou have dbus-x11 in your snapcraft.yaml
[14:59] <ogra_> (at least you did yesterday when i looked :) )
[14:59] <zyga> juanrubio: you need to add an entry as I said, with bus: and name: keys
[14:59]  * zyga gets back to coding
[14:59] <zyga> mvo: maybe you can do a 2nd review on https://github.com/snapcore/snapd/pull/3291
[14:59] <mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[14:59]  * zyga wants to land that before it conflicts
[15:00] <Chipaca> mvo: it's long, but mechanical
[15:00] <zyga> Chipaca: it shows that github stops parsing/colorizing code at some point :)
[15:01] <juanrubio> zyga,ogra_: the dbus stuff in my yaml is still work in progress. It will most likely be removed since I'm not planning to enable that feature in snap installations
[15:02] <Chipaca> zyga: not here
[15:02] <Chipaca> zyga: suspect it might be your browser giving up in disgust
[15:34] <mup> PR snapd#2929 closed: interfaces/builtin: add storage-framework-service interface <Created by michihenning> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2929>
[15:35] <lutostag> Can other's not upload new snaps to the store? I'm hitting Oops! There was an unrecoverable error, please try uploading your file again. (Sentry id: 2232db8e490a485b87961d3c3c9b08f8)
[15:35] <lutostag> and snapcraft push fails with a similar but different error...
[15:35] <zyga> mvo: replied to your questions, thank you for reading that monster :)
[15:41] <zyga> mvo: either merge all the interfaces or refrain from doing so, so that 3291 won't conflict
[15:41] <zyga> mvo: I'm happy with either :)
[15:42] <mvo> zyga: hm, 2869 looks like an easy win too
[15:42] <zyga> mvo: get them all in then
[15:42] <ogra_> mvo, http://paste.ubuntu.com/24549394/  (in conclusion with https://forum.snapcraft.io/t/allow-disabling-system-services-on-ubuntu-core/531/12 )
[15:42] <mvo> zyga: it now conflicts though and 2941 too
[15:42] <zyga> mvo: I'll do all de-conflicting on the other side
[15:43] <zyga> mvo: hehe
[15:43] <zyga> mvo: all those conflicts is why I made the 3291 in the first place :)
[15:43] <zyga> mvo: no worries, just give me +1 to merge and I'll resolve the rest
[15:43] <mvo> ogra_: oh, I guess I will need to read that
[15:43] <juanrubio> zyga: do we know what's the issue with the apparmor denials?
[15:43] <mvo> ogra_: slightly concerned about backward compat and remote logging and all that. and funny since I was against rsyslog a long time ago in the default. oh well
[15:44] <zyga> juanrubio: no, I don't know
[15:44] <zyga> juanrubio: I didn't dig deeply though
[15:44] <ogra_> mvo, well, niemeyer suggests in the discussion that we can ship rsyslog as a snap for remote logging ... all other bits seem to be moot
[15:45] <ogra_> seems sensible to me ...
[15:45] <ogra_> not sure where backward compat would be an issue
[15:45] <rharper> mvo: when and where would I look for new core snap with those PR's landed ?
[15:45] <ogra_> rharper, in edge ... but it didnt land yet
[15:45] <juanrubio> zyga: thanks. Do you feel a bug should be filed for this?
[15:46] <ogra_> rharper, the ubuntu-core-config deb still needs to land in the PPA (i'm working on this atm) ... once thats there i'll trigger a new core
[15:46] <zyga> juanrubio: no, not immediately, please open a forum topic, use the snap category
[15:46] <rharper> ogra_: ok, thanks
[15:46] <mvo> zyga: hm, hm, I guess your sequence (3291, then the other interface code) would have been more efficient, each interface branch that lands conflicts right now
[15:46] <juanrubio> zyga: ok, i'll do that
[15:48] <zyga> mvo: no worries :)
[15:48] <mvo> zyga: sorry for that!
[15:48] <mvo> zyga: its just two interface branches left, right? so not toooooo terrible
[15:48] <zyga> mvo: I'm just happy to land this eventually so that other people have less headache :)
[15:48] <zyga> mvo: yep
[15:48] <zyga> mvo: plus several waves of cleanups I'm working on
[15:48] <zyga> lots of silly stuff that's crufily copy-pasted around
[15:57] <pstolowski> zyga, ah, 3291 has conflicts now
[16:00] <zyga> yeah, I'll resolve them after finishing one more branch
[16:08] <morphis> zyga: looks like
[16:08] <morphis> zyga: need to explore a bit what the X abstraction allows today
[16:09]  * zyga nods
[16:17] <mup> PR snapd#3119 closed: interfaces: API additions for interface hooks <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3119>
[16:18]  * zyga looks at https://github.com/snapcore/snapd/pull/3291 and cries a little
[16:18] <mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[16:18] <zyga> well :D
[16:29] <juanrubio> zyga,morphis: I've replied to the same pulseaudio thread I created yesterday -> https://forum.snapcraft.io/t/pulseaudio-access-denied-accessing-pulseaudio-for-audio-playback-in-fedora-25-and-ubuntu-16-04/519?u=juanrubio
[16:32] <zyga> juanrubio: thanks
[16:33] <morphis> juanrubio: thanks!
[16:33] <cachio> Chipaca, hey, I need to add the proxy to a ubuntu core instance to run spread tests
[16:33] <Chipaca> cachio: hey
[16:33] <Chipaca> cachio: I think the fix to make /etc/environment writable in core isn't ready yet
[16:33] <Chipaca> cachio: but if it's just for testing, it's easy to work around
[16:34] <cachio> Chipaca, yes, I need to run the spread tests on that machine
[16:34] <Chipaca> cachio: pop a file anywhere (e.g. /root/, or /var), and then mount --bind /the/file /etc/environment
[16:35] <Chipaca> cachio: (it's also very easy to make this fix permanent, if it were something that needed to work longer term)
[16:35] <Chipaca> just a matter of doing the above (possibly with the file in under /etc/writable to make it less hackish) and then write an appropriate .mount file and drop it in /etc/systemd/system
[16:36] <cachio> Chipaca, ok
[16:36] <cachio> Chipaca, do you know if the snap client will support proxy?
[16:36] <Chipaca> cachio: there's some tricky details for the second half; give me a shout if you need it
[16:37] <Chipaca> cachio: yes, in the same way as snapd
[16:37] <Chipaca> (set HTTPS_PROXY or https_proxy or HTTP_PROXY or http_proxy in the environment)
[16:37] <Chipaca> usually your login shell sources /etc/environment also, so you should be set
[16:38] <cachio> Chipaca, since when?
[16:38] <Chipaca> cachio: since when what?
[16:38] <cachio> Chipaca, is it already upported? or will be supported?
[16:38] <zyga> hmm hmm hmm
[16:39] <zyga> I think pawel's branch had a bug
[16:39] <Chipaca> cachio: already
[16:40] <Chipaca> cachio: super easy to confirm, also: http_proxy=potato snap download what
[16:40] <Chipaca> <snap vomits>
[16:41] <zyga> aww
[16:41] <zyga> yes it does
[16:42] <zyga> pawel, you didn't listen to me :/
[16:42] <zyga> master is broken
[16:42] <cachio> Chipaca, ok, I'll try that too, tx
[16:43] <Chipaca> zyga: psh, who needs master
[16:43] <mup> PR snapd#3292 opened: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292>
[16:48] <morphis> Pharaoh_Atem: any reason why you dropped those lines https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-14.04/snapd.postrm#L86 from the snapd-mgmt.sh script?
[16:48] <Chipaca> zyga: so how do we fix?
[16:48] <zyga> master is fixed with https://github.com/snapcore/snapd/pull/3291
[16:48] <mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[16:49] <zyga> I'll add the missing tests pawel didn't add
[16:54] <zyga> ok, tests written
[16:57] <zyga> Chipaca: I'm going to EOD now, can you merge https://github.com/snapcore/snapd/pull/3291 once green
[16:57] <mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[16:57] <zyga> Chipaca: I pushed the missing test as well
[16:58] <Chipaca> zyga: yes
[16:58] <niemeyer> zyga: Which PRs were blocking you?
[16:58] <zyga> niemeyer: I'd like to land https://github.com/snapcore/snapd/pull/3225 and iterate on integration, testing and perhaps discard the change.IsNeeded code
[16:58] <mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
[16:59] <zyga> I'll probably come back later tonight to de-conflict remaining interface PRs
[17:01] <niemeyer> zyga: Looking, and thanks
[17:01] <zyga> thanks, and see you tomorrow!
[17:12] <niemeyer> zyga: Feedback provided
[17:12] <niemeyer> zyga: Some of the points still seem open
[17:13] <morphis> niemeyer: do you have time to look at those PRs https://github.com/snapcore/snapd/pulls/morphis except the snapd --user one today?
[17:14] <niemeyer> morphis: I'm keen on sorting these out first, and would appreciate help doing that: https://forum.snapcraft.io/t/review-sprint-1/377
[17:14] <morphis> I can see what I can do tomorrow
[17:14] <niemeyer> morphis: Anything in there is open for more than two weeks
[17:15] <niemeyer> morphis: Thanks!
[17:15] <morphis> niemeyer: https://github.com/snapcore/snapd/pull/3222 being one of them
[17:15] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[17:15] <niemeyer> morphis: Looking right now
[17:15] <morphis> thanks!
[17:23] <mup> PR snapcraft#1305 opened: Use architectures field which existed in older LXD <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1305>
[17:26] <ogra_> rharper, a new core is building, should be ready within the next 30-45min
[17:26] <ogra_> (including your changes)
[18:02] <rharper> ogra_: thanks!
[18:03] <zyga> jdstrand: ouch https://lwn.net/Articles/722363/
[18:05] <jdstrand> zyga: yeah
[18:06] <jdstrand> the kerenls should be all fixed already though
[18:06] <jdstrand> kernels even
[18:10] <zyga> jdstrand: except for core pi2/3
[18:10] <nanday> I'm doing an article about packages for The New Source. Anybody involved with the design of snap packages who has the time to reply to some basic questions?
[18:11] <nanday> Alternatively, does anyone have any suggestions about who I might talk to?
[18:12] <zyga> nanday: hey
[18:12] <zyga> nanday: you may want to talk to niemeyer
[18:12] <zyga> nanday: but I can also answer some questions if you post them
[18:13] <jdstrand> zyga: well, yes, which is the lack of updates is something I keep bringing up. hopefully that was resolved at the sprint?
[18:14] <zyga> jdstrand: I think it was discussed but we need to work on the implementation
[18:14] <zyga> jdstrand: I think the design was resolved
[18:16] <jdstrand> that's good news
[18:19] <zyga> jdstrand: I made some improvements to interface code, there should be less conflicts now
[18:19] <zyga> jdstrand: I have some more cleanups piled up, nothing semantic, just lots of cruft in tests and copy-paste badness
[18:19] <jdstrand> zyga: fewer conflicts? what do you mean?
[18:20] <zyga> jdstrand: adding a new interface will no longer change many files
[18:20] <jdstrand> oh with PRs?
[18:20] <zyga> jdstrand: well, less many :-)
[18:20] <zyga> jdstrand: yes
[18:20] <zyga> https://github.com/snapcore/snapd/pull/3291/files
[18:20] <mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[18:20] <jdstrand> I see. that'll be nice
[18:20] <ChipAway> zyga: the tests on snapd#3291 have only just started running (~10 mins ago)
[18:20] <zyga> jdstrand: also merging a PR will now test if it's using any of the old APIs
[18:20] <zyga> Chipaca: yeah, I restarted them
[18:20] <Chipaca> oh
[18:20] <zyga> Chipaca: we ran out of machines
[18:21] <Chipaca> when i left for dinner it hadn't started yet
[18:21] <zyga> Chipaca: gustavo added more to the pool so I'm hoping this one will pass
[18:21] <zyga> Chipaca: yes, it ran but timed out after 49 minutes
[18:21] <jdstrand> zyga: oh, that's cool
[18:21] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/3291/commits/f1faec05b48d70f0ebf4a45e48226cbc9278c21b :-)
[18:21] <mup> PR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>
[18:23] <Pharaoh_Atem> morphis: I dropped them because rpm will remove it
[18:23] <Pharaoh_Atem> the directory is owned by the package, and if all contents are already gone, rpm will get rid of the directory
[18:28] <jdstrand> huh, neat
[18:52] <mup> PR snapd#3293 opened: spread.yaml: increase linode workers by 50% <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3293>
[19:00] <cachio> Chipaca, did you see what I wrote? I lost connection
[19:02] <cachio> do you have an example of that .mount?
[19:31] <mup> PR snapd#3294 opened: interfaces: fix broken master after merging the storage_framework_services branch <Created by mvo5> <https://github.com/snapcore/snapd/pull/3294>
[19:31] <Chipaca> cachio: I did not see what you wrote
[19:32] <Chipaca> cachio: I do have an example of that mount
[19:32] <Chipaca> cachio: do you have the snapd tree?
[19:32] <Chipaca> if so it's super easy to show you :-)
[19:32] <Chipaca> otherwise i'll pastebin
[19:32] <cachio> pastbin please
[19:33] <mup> PR snapd#3291 closed: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3291>
[19:33] <cachio> Chipaca, I wrote that spread tests are rebooting the target machine and it is making the mount unusable
[19:33] <Chipaca> cachio: http://pastebin.ubuntu.com/24550581/
[19:34] <Chipaca> cachio: that's a bind mount .mount unit
[19:34] <Chipaca> cachio: basically What=<the rw file>, Where=/etc/environment
[19:34] <Chipaca> for you
[19:34] <Chipaca> the rest remains the same (but edit the description :-) )
[19:34] <Chipaca> cachio: and, the tricky bit is
[19:35] <Chipaca> cachio: it *needs* to be called etc-environment.mount
[19:35] <cachio> Chipaca, great, and just I need to leave it in /etc/systemd/system ?
[19:35] <cachio> nad restart snapd?
[19:35] <Chipaca> drop it in /etc/systemd/system/etc-environment.mount
[19:35] <Chipaca> then enable it (systemctl enable etc-environment.mount)
[19:36] <Chipaca> then start it (systemctl start ...)
[19:36] <Chipaca> then confirm it worked
[19:36] <Chipaca> then restart snapd :-)
[19:36] <cachio> Chipaca, great, I'll try now
[19:36] <cachio> Chipaca, tx
[19:37] <Chipaca> cachio: man systemd.mount if you want to learn the how and the why
[19:37] <cachio> Chipaca,  :) sure
[19:42] <Chipaca> zyga: src/github.com/snapcore/snapd/interfaces/builtin/storage_framework_service_test.go:87: not enough arguments in call to spec.AddConnectedSlot <- wat
[19:46] <morphis> Pharaoh_Atem: hm, then that works differently on suse
[19:46] <morphis> I don't see /var/lib/snapd removed
[19:53] <mup> PR snapcraft#1301 closed: recording: record global build-packages installed on the host <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1301>
[19:56] <mup> PR snapcraft#1306 opened: recording: record global build-packages installed on the host <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1306>
[20:22]  * Chipaca looks for the big red STOP THE LINE button
[20:29] <rharper> ogra_: testing the edge image;  what's the best way to ask if the system booted is a ubuntu-core  system? cloud-init had used either 'channel.ini'  or 'config.d' in /etc/system-image to check; but the current core snap only has 'writable-paths' present;  That'll need fixing in cloud-init and I'd like to find something stable
[20:32] <Chipaca> rharper: "snap version" output should be enough to know
[20:32] <Chipaca> (if not, we should improve it :) )
[20:33] <rharper> ok, we run early in boot, would snap version run ?
[20:33] <Chipaca> rharper: if you're in early bring up and not yet at the stage of having snapd running, /etc/os-release might help
[20:33] <rharper> ok
[20:33] <Chipaca> or early boot yeah
[20:33] <Chipaca> dunno if etc/os-release is there in early boot; it's in the root filesystem
[20:33] <rharper> it will
[20:33] <Chipaca> k
[20:33] <rharper> cloud-init runs after localfs is mounted (one of the stages)
[20:33] <Chipaca> ah ok
[20:34] <rharper> that looks solid, ID=ubuntu-core is similar to the match we did in channel.ini
[20:34] <Chipaca> rharper: another way is to check whether the root fs is a squashfs :-)
[20:34] <rharper> well, we boot root squashfs in  maas ephemeral, os-release looks good though
[20:34] <rharper> thanks for the suggestion
[20:41] <mup> PR snapcraft#1307 opened: cli: new UI and internal refactor <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1307>
[21:04] <rharper> Chipaca: for snap version:  the only difference I can tell between classic and core is that in classic, snap version includes 'ubuntu  16.04'  where as my core image does not include the ubuntu line;  both say series 16 .
[21:05] <rharper> not sure if it it's worth saying classic vs. core or something like;   cloud-init has to do somethings differently (like using extrausers database in core)  vs. in classic
[21:09] <Chipaca> yeah, maybe we should include the flags as we do in the user-agent string
[21:59] <mup> PR snapcraft#1308 opened: allow capital Y to accept the dev agreement <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/1308>
[22:54] <mup> PR snapd#3294 closed: interfaces: fix broken master after merging the storage_framework_services branch <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3294>
[22:58] <newbsie> I'm having some problem login into my Raspberry Pi after first time setup with Ubuntu Core. Putty keeps responding with key is denied. Anyone know what to do?
[23:07] <zyga> newbsie: is your putty key added to your launchpad account?
[23:08] <newbsie> zyga: yes.
[23:08] <zyga> newbsie: note that putty and ssh on linux/macos don't use the same key format
[23:08] <newbsie> zyga: I'm trying to get ssh working on Linux subsystem for Windows 10, but don't know where to put the private key file. Trying to locate the .ssh dir.
[23:09] <zyga> newbsie: aha
[23:09] <zyga> newbsie: so are you using putty or ssh on windows+ubuntu
[23:09] <newbsie> zyga: I was using putty, but since it didn't work, I'm trying ssh on windows+ubuntu.
[23:10] <zyga> newbsie: so is your windows+ubuntu ssh key on launchpad?
[23:10] <zyga> newbsie: it is in ~/.ssh/id_rsa.pub by default
[23:11] <newbsie> zyga: It's the same key as on putty, but I exported the private key to ssh format.
[23:11] <zyga> newbsie: the id_rsa is the private key
[23:11] <zyga> newbsie: id_rsa.pub is the public key
[23:12] <zyga> newbsie: public key is short, the private key is a longer block of stuff that begins with -----BEGIN RSA PRIVATE KEY-----
[23:13] <newbsie> zyga: The key is generated in puttygen. For the public key, I did ssh-rsa <long hex string> and put it into launchpad.
[23:13] <newbsie> zyga: for the private key, it is in ppk format, and then I export it to openssh format
[23:15] <newbsie> zyga: but it is not working. Maybe I should start from scratch and use openssh to generate the keys.
[23:16] <zyga> newbsie: not sure, it's too late for me :)
[23:16] <zyga> newbsie: you can always yank the card from pi
[23:16] <zyga> newbsie: put it into your laptop
[23:16] <zyga> newbsie: and look at what is in the .ssh/authorized_keys
[23:17] <newbsie> zyga: how do I tell ssh to use a private key?
[23:18] <zyga> newbsie: man ssh has all the secrets, I believe it is the -i option
[23:18] <zyga> newbsie: (and I assume you meant to ask "which key to use", it always uses private keys
[23:18] <newbsie> zyga: this whole SSO is frustrating
[23:19] <Chipaca> newbsie: ssh is very picky about permissions
[23:20] <Chipaca> newbsie: if you add the -v option it will print a lot of info about what's going on
[23:20] <Chipaca> newbsie: if you want you could pastebin that, maybe it'll help us help you
[23:20] <Chipaca> otoh, putty _should_ work but i don't have a way to try it
[23:21] <zyga> Chipaca: oh, good idea
[23:21] <Chipaca> oh wait, there's a putty for ubuntu
[23:21] <zyga> newbsie: on windows+ubuntu files is often 777 by default
[23:21] <Chipaca> wonder if it's the same
[23:21] <zyga> chmod -og= -R .ssh
[23:22] <newbsie> Chipaca: ssh complaining about file permission is to open.
[23:22] <zyga> newbsie: yep
[23:22] <zyga> do the chmod
[23:22] <Chipaca> newbsie: that thing with the chmod zyga suggested is not him having a fit, he was trying to tell you to run that :-)
[23:23] <newbsie> it's saying there is no -og= mode
[23:23] <zyga> hmm
[23:23] <zyga> my bad
[23:23] <Chipaca> og-r, i think?
[23:23] <zyga> chmod -R og= ~/.ssh/
[23:24] <Chipaca> ah
[23:24] <zyga> ^ tested
[23:24]  * Chipaca looks up =
[23:24] <zyga> Chipaca: assign
[23:24] <zyga> Chipaca: I fixed master and all the open branches that touch interfaces
[23:24] <Chipaca> assign nothing, ie clear
[23:24] <Chipaca> gotcha
[23:24] <Chipaca> zyga: i saw my branch magically fix itself
[23:25] <Chipaca> zyga: thanks :-)
[23:25] <zyga> Chipaca: with the extra workers we can now run several tests in parallel
[23:25] <zyga> Chipaca: I have one more branch if you want to read :)
[23:25] <newbsie> So I do the following: ssh -i private_key.pub <username>@192.168.1.9 -v
[23:25] <zyga> Chipaca: makes all of interface implementation private
[23:25] <zyga> Chipaca: and exposes only one function, interfaces.Interfaces()
[23:26] <zyga> Chipaca: doing that makes goling happy and found a few ugly things in tests
[23:26] <newbsie> But then get an error, unable to open file. Permission denied.
[23:26] <Chipaca> newbsie: which file?
[23:26] <Chipaca> zyga: sure, shoot
[23:26] <zyga> Chipaca: one sec, just need to rebase it
[23:26] <zyga> Chipaca: it's another monster-ish branch
[23:27] <zyga> Chipaca: :D
[23:27] <newbsie> Chipaca: private_key.pub
[23:27] <newbsie> which is the private key. I think it is misnamed.
[23:27] <zyga> with a space?
[23:27] <newbsie> zyga: It's underscore
[23:27] <Chipaca> newbsie: permission denied might mean exactly that
[23:27] <Chipaca> newbsie: what does "ls -l private_key.pub" say?
[23:28]  * zyga looks at http://paste.ubuntu.com/24551684/
[23:28] <zyga> and cries a little :D
[23:28] <newbsie> Chipaca: only owner has read, everything else is disabled.
[23:29] <Chipaca> newbsie: and the owner is the user you're trying to ssh as?
[23:29] <Chipaca> newbsie: in other words
[23:29] <Chipaca> easy way to check
[23:29] <Chipaca> if you enter "cat private_key.pub"
[23:29] <Chipaca> do you see the contents of the file
[23:30] <zyga> (just don't paste them)
[23:30] <newbsie> Chipaca: No. That's odd.
[23:30] <newbsie> Chipaca: I created the file as the current user, and it has my username
[23:30] <Chipaca> newbsie: what does “id” say?
[23:30] <Chipaca> that is, does “id” agree that you are you
[23:31] <newbsie> Chipaca: Yes
[23:31] <zyga> newbsie: quick question
[23:31] <zyga> newbsie: how did you create it
[23:31] <zyga> newbsie: did you created it from windows?
[23:31] <zyga> newbsie: or from windows+ubuntu?
[23:31] <newbsie> zyga: nano private_key.pub
[23:31] <zyga> newbsie: ok
[23:31] <newbsie> zyga: from within windows+ubuntu
[23:32] <zyga> Chipaca: if you don't know you cannot ever touch anything from windows that is in windows+ubuntu or it explodes in magic ways
[23:32] <Chipaca> zyga: I thought they'd fixed that with the latest patch
[23:32] <Chipaca> the ... anniversary edition, or something
[23:33] <newbsie> So, I can't change it to chmod a+r, because ssh complains, but if I change it to chmod o+r, then I cannot read it.
[23:33] <zyga> Chipaca: not that I know
[23:33] <zyga> fo
[23:33] <zyga> of
[23:33] <Chipaca> ¬_¬
[23:33] <zyga> newbsie: wait
[23:33] <zyga> newbsie: not o
[23:34] <zyga> newbsie: o is 'oter'
[23:34] <zyga> other
[23:34] <zyga> newbsie: you want 'u'
[23:34] <zyga> newbsie: chmod og=,u=rwX
[23:34] <Chipaca> yeah, don't let otters read your keys
[23:34] <zyga> chmod that recursively on .ssh
[23:35] <Chipaca> hands up if you think it should've worked from putty
[23:35] <Chipaca> o/
[23:35] <zyga> \o
[23:35]  * zyga is left handed
[23:36] <Chipaca> newbsie: i think we asked you this before, but, the key you uploaded to launchpad, was it in the format openssh expects?
[23:36] <newbsie> It should have worked from putty and would have saved me a lot of trouble. There should be an official guide on Ubuntu Core website. They only did one for Ubuntu.
[23:36] <Chipaca> (is it to launchpad you upload your ssh keys, still)
[23:36] <mercurio56> help
[23:36] <Chipaca> newbsie: they == us :-)
[23:36] <Chipaca> mercurio56: wat
[23:37] <newbsie> Chipaca: I believe so. That's the same format I used to configure Ubuntu Server i.e. ssh-rsa <long hex string>
[23:37] <newbsie> The problem is private key is missing begin marker.
[23:37] <Chipaca> newbsie: progress!
[23:38] <newbsie> Chipaca & zyga: I appreciate the help so far!
[23:38] <Chipaca> newbsie: so
[23:38] <Chipaca> newbsie: silly question
[23:38] <Chipaca> newbsie: is there a reason you can't generate a whole new key pair direclty with openssh?
[23:39] <Chipaca> newbsie: that's "ssh-keygen"
[23:39] <newbsie> Chipaca: no, there is no reason. Probably save me more time than doing this. It's just that I have one keyboard and the stupid thing requires first time signup to have physical access. Completely bonkers that it has so many barriers.
[23:40] <zyga> newbsie: otherwise it'd be totally insecure
[23:40] <zyga> newbsie: how would you log in? ubuntu/ubuntu?
[23:40] <newbsie> zyga: yes, and change the password.
[23:40] <Chipaca> newbsie: yeah, no, that's how the IoT botnets exist
[23:40] <zyga> newbsie: what about 99% of the people who will never do that?
[23:40] <newbsie> zyga: better yet, have a script to run and do whatever it needs to do
[23:41] <Chipaca> anyhow, you are right in that we should make a guide for windows
[23:41] <Chipaca> i wonder who has windows that could write a guide for this
[23:41] <newbsie> I'm just frustrated since I spent so much time, and I'm not completely new to Ubuntu.
[23:41] <newbsie> Just rusty.
[23:42] <Chipaca> newbsie: if you could channel this frustration into a forum topic about this, it'll help other people pick it up and fix it
[23:42] <Chipaca> newbsie: otherwise I'll do it
[23:42] <zyga> newbsie: yes! you can help everyone!
[23:43] <newbsie> I will definitely do that.
[23:43] <Chipaca> excellent :-)
[23:43] <Chipaca> also, try not to swear too much :-p
[23:43] <newbsie> My wise fiance says, swearing is for those that cannot express themselves.
[23:44] <newbsie> So I try to learn to express myself.
[23:44] <zyga> Chipaca: almost done
[23:44] <newbsie> Anyhow, I appreciate not being told to RTFM or that you suck during my outburst of frustration.
[23:45] <Chipaca> i tell my boys that they have this awesome vocabulary, and it's a shame to waste it and go the lazy route of just swearing
[23:45] <Chipaca> I only tell people to RTFM when I know they wrote the M in the first place :-)
[23:47]  * Chipaca just realized that "write the fine manual" has a very apropos initialism
[23:47] <Chipaca> zyga: huzzah
[23:47] <newbsie> Chipaca: lol
[23:47] <newbsie> Chipaca: How do the people that wrote the manual take it? :)
[23:48] <Chipaca> they know me, so they take it well
[23:49] <Chipaca> zyga: we should package putty as a snap
[23:50] <zyga> Chipaca: for... ? nostalgia?
[23:51] <Chipaca> zyga: to watch the world burn?
[23:51] <Chipaca> zyga: i think it's just that it's 1am and my brain is easily amused
[23:51] <zyga> Chipaca: ok, here it comes
[23:51] <Chipaca> zyga: also, it's 2am for you (again)
[23:52] <zyga> https://github.com/snapcore/snapd/pull/3295
[23:52] <mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
[23:52] <zyga> more red than green :D
[23:52] <mup> PR snapd#3295 opened: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
[23:52] <newbsie> is the username@host after the ssh-rsa <key> needed?
[23:52] <zyga> ah, wait, new interfaces are public
[23:53] <Chipaca> newbsie: it's the key name or something like that
[23:53] <Chipaca> newbsie: i've always copied it
[23:53] <Chipaca> not sure if it's needed
[23:54] <Chipaca> zyga: does that mean i should hold off reviewing?
[23:54] <zyga> Chipaca: pushed again
[23:54] <zyga> just one interface
[23:54] <zyga> Chipaca: go ahead now
[23:54] <Chipaca> youch
[23:54] <Chipaca> +831 −1,165
[23:54] <zyga> hahaha
[23:54] <zyga> yes
[23:55] <zyga> but the fact that interfaces are private now makes test easier to verify
[23:55] <zyga> they can only observe what is public, and they must ask for an interface, by name, from the registry
[23:55] <zyga> Chipaca: honestly I don't expect you to really review this today :)
[23:56] <Chipaca> yeah, i'd not trust it to fit in my brain at this time
[23:56] <Chipaca> if it were more mechanical, sure
[23:56] <Chipaca> but it's not
[23:56] <zyga> it's very boring
[23:56] <zyga> there are a few interesting spikes
[23:56] <zyga> but it is for tomorrow
[23:56] <zyga> I think spread will be busy for now
[23:56] <zyga> I'll just merge master into broken branches
[23:57] <Chipaca> newbsie: i'm checking out, but i don't want to leave you hanging
[23:57] <Chipaca> newbsie: so, um, i'll stay logged in here until i'm back from brushing my teeth?
[23:57] <Chipaca> shout if you need me :-)
[23:58] <Chipaca> (otherwise i'll assume everything worked and you're off to the races)