[03:33] dragonboard emmc flashing instead of SD [03:33] https://discuss.96boards.org/t/ubuntu-core-on-emmc/1611 === chihchun_afk is now known as chihchun [05:17] PR snapcraft#1304 opened: cleanbuild: set the container language to en_US.UTF-8 === chihchun is now known as chihchun_afk [07:04] PR snapd#3284 closed: interfaces: ensure that legacy interface methods are unused [07:16] good morning [07:16] hey there mvo! :) [07:16] thanks for merging that :) [07:16] woot, we are on one-page-long of PRs :) [07:20] zyga: hey, good morning [07:23] PR snapd#3286 closed: cmd/snap: tweak info channels output [07:32] mvo, jdstrand, tyhicks: in addition to coverity I would consider adding https://github.com/google/oss-fuzz [07:38] morning [07:39] hey hey :) [07:40] 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] PR snapd#3119: interfaces: API additions for interface hooks [07:40] zyga, yes, doing right now [07:40] excellent, thank you! [07:57] PR snapd#3287 opened: tests: unify tests/{main/completion,completion}/lib.exp0 [07:58] PR core-build#10 closed: make /etc/environment writable [08:27] zyga: ^ 3287 should fix the expect timeouts [08:32] PR core-build#11 opened: remove cruft from the writable-paths [08:38] Chipaca: looking [08:41] Chipaca: thank you! [08:44] zyga, update iface-hooks-api with master, waiting for tests [08:45] pstolowski: did you find any stale APIs? [08:46] 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] zyga, yes, but only in the "expected" ones (new interfaces that appeared in msaster) [08:46] *master [08:47] pstolowski: excellent, thank you! === chihchun_afk is now known as chihchun [09:19] zyga: feeling comfortable to give https://github.com/morphis/meta-snappy/pull/9 a shot? [09:19] PR morphis/meta-snappy#9: Add support for pyro and drop golang toolchain [09:20] morphis: yes, if you tell me how to try this [09:21] zyga: https://github.com/morphis/meta-snappy/blob/master/README.md but checkout out the pyro branch of poky instead of morty [09:21] ok [09:24] morphis: btw, what is it with the naming scheme? [09:24] pyro/morty/poky? [09:24] pyro and morty are release code names [09:25] poky is the name of the collection of recipes Yocto releases [09:25] https://www.yoctoproject.org/tools-resources/projects/poky [09:26] morty is the current stable release and pyro the next one [09:26] https://wiki.yoctoproject.org/wiki/Releases [09:27] * zyga mentally paste's chipaca's signature ascii emoji [09:30] 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] PR snapd#2929: interfaces/builtin: add storage-framework-service interface [09:32] zyga: nice, thank you [09:37] zyga: you mean ヽ(´▽`)/ right? [09:41] Chipaca: lol :D [09:41] zyga: ( ˘ ³˘)♥ [09:44] zyga: do the mount namespace thingies do the right thing on snapd restart? [09:45] PR snapd#3287 closed: tests: unify tests/{main/completion,completion}/lib.exp0 [09:45] Chipaca: which is? [09:45] Chipaca: (we don't touch them) [09:45] Chipaca: which is arguably perhaps wrong (I have a bug open for that) [09:45] zyga: I don't know what the right thing is :-) [09:45] https://bugs.launchpad.net/snapd/+bug/1667479 [09:45] Bug #1667479: mount namespace is not discarded when core snap changes revision [09:46] Chipaca: I only know about this thing being wrong [09:46] zyga: but i was wondering whether it was leftover state that could break if expectations changed [09:46] which is a special case of update-ns [09:46] aha [09:46] Chipaca: each test restore code unmounts them [09:46] Chipaca: so they should go away [09:46] Chipaca: as for restart [09:46] Chipaca: we re-gen new seccomp and apparmor profiles then but those don't affect the mount namespace [09:47] Chipaca: we don't regenerate (or update as update-ns is not finished) the mount profiles [09:52] mvo: hi, I +1ed snapd#3263 but it seems to have failing tests [09:52] PR snapd#3263: snap: make `snap prepare-image --extra-snaps` derive side info [09:52] pedronis: thanks, checking now [09:54] pedronis: test failures were in the completion tests, I think some fixes went into master, lets see if that helps [09:56] zyga: and should we? [10:04] Chipaca: yes [10:05] Chipaca: we should return to that [10:05] 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] PR core-build#11: remove cruft from the writable-paths [10:10] mvo: what are your thoughts on https://github.com/snapcore/snapd/pull/3226#discussion_r115584968 [10:10] PR snapd#3226: snap-repair: add `snap-repair run` [10:10] brb, new kernel to test [10:11] 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] looking [10:11] pstolowski: for your 3120 PR [10:13] morphis: I'll look at building oe soon [10:13] morphis: but I will do a few more reviews before that [10:13] zyga: ok [10:13] * zyga looks at mvo's https://github.com/snapcore/snapd/pull/2592 [10:13] PR snapd#2592: many: add support for session dbus services via snaps [10:15] fgimenez: hey, do you know why the openvswitch tests are failing? I see them fail frequently [10:15] 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] zyga: looking [10:16] fgimenez: thanks! [10:17] zyga: makes sense, no disagreement, I think we need to consider how far we want to go in each iteration [10:17] zyga: re the reapir run code question [10:18] pedronis: is the syntax of the `snap alias` command changing with the upcoming 2.26? [10:18] 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] pstolowski: great, do you want to wait for gustavo's review [10:21] 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] zyga: i'll try to reproduce and get a debug console for getting more info [10:22] fgimenez: thank you! [10:22] fgimenez: note that it happens frequently but not always [10:23] perhaps related to ordering? [10:23] fgimenez: can I restart that run now? [10:23] zyga: ok thanks! no idea, will let you know how it goes [10:23] zyga, with 3119 yes, i'd like niemeyer to review it too [10:23] pstolowski: ok [10:26] morphis: ? [10:26] it already changed in 2.25 [10:27] pedronis: hm, which isn't yet in stable, right? [10:27] no [10:27] that would explain why it breaks all our tests [10:28] but only when run against edge/beta/candidate [10:28] morphis: what kind of tests? [10:28] morphis: you have some real test failures on https://github.com/snapcore/snapd/pull/3222 [10:28] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [10:28] pedronis: spread tests we have for all snaps we maintain [10:29] pedronis: we call `snap alias pulseaudio parec` and then expect /snap/bin/parec to show up [10:29] 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] pedronis: we have them all in the store [10:30] morphis: ok, then not sure why you are using "snap alias" in those tests, we their are not the main spread tests [10:30] pedronis: need to look a bit more into that [10:30] bit confused here [10:31] pedronis: we list them in snapcraft.yaml [10:31] and then a `snap alias pulseaudio pactl` call was meant to create the alias in /snap/bin [10:31] morphis: well if they are in the store, no need for that [10:31] the snap-declaration in the store allows those aliases to be setup automatically [10:32] I mean that tests is not relevant anymore [10:32] that doesn't work that way, it's not inteded to work that way anymore [10:32] you get what the store sets up [10:32] pedronis: so how do I get now an alias for a locally installed snap? [10:33] morphis: it's all in the forum post: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18 [10:33] morphis: you can setup what we call manual aliases [10:33] the syntax is a bit different: snap alias SNAP.APP ALIAS [10:33] ah [10:33] that is why it breaks [10:33] so a `snap alias pulseaudio pactl` doesn't work anymore [10:34] yes, I said so maybe 3 times :) [10:34] but I didn't got the point that it now needs to be . [10:34] well, as I said I don't understand why you need that command? [10:34] is the test installing the snap locally? [10:34] yes [10:34] ah [10:35] pedronis: we were verifying that the alias defined in the snap was working [10:35] but as you said, that isn't needed anymore [10:35] that doesn't make sense anymore [10:35] there's is no alias defined in the snap concept anymore [10:35] I mean you can fix the test for the new syntax but as well drop it [10:36] if the intention was checking the aliases in the snapcraft.yaml [10:36] we will deprecate those at some point [10:36] ok [10:37] anyway the forum post explains a bit all of this [10:37] pedronis: are all assertions on the store side are updated automatically? [10:37] morphis: we did a pass of doing that with jdstrand [10:37] if I remember well they just defined a list of allowed aliases like [pactl, parec] [10:37] pedronis: great [10:38] linode seems busy now [10:38] coffee break then :) [10:38] 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] good [10:38] because now the assertions needs to list a target too [10:39] pedronis: so with 2.25 going to stable it is safe to drop the aliases: part from the snap, right? [10:40] however I think we will leave them for a bit more to gurantee everyone gets correctly updated [10:40] yes, when all your clients you care about are updated to 2.25 though [10:40] yeah, that is tricky [10:42] 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] pedronis: thanks! [10:42] * pedronis lunch [10:45] as best as I can tell so far, cking's fix for bug #1672819 works [10:45] Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid

[10:45] nearly done with all the reproducers [10:52] \o/ [11:06] re [11:12] zyga: something has changed in suse.. https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/i586 [11:17] morphis: aha, it seems that rst2man is no longer shipped by the package we install [11:17] yes [11:17] morphis: we can fix this by (perhaps) depending on /usr/bin/rst2man directly [11:17] (whatever the package name) [11:19] 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] zyga: is there macro for that? [11:20] zyga: the openvswitch test is disabled for debian on master and is enabled in https://github.com/snapcore/snapd/pull/3274 right? [11:20] 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] PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting [11:20] pedronis: also, hi :) [11:20] morphis: no, it's just Requires: /usr/bin/rst2man AFAIR, let me check [11:21] fgimenez: yes, something I still need to look into [11:21] zyga: nice, let me try that [11:21] fgimenez: yes, parts of that test are now enabled [11:21] fgimenez: note that this test was also failing on ubuntu [11:21] fgimenez: just not always [11:21] morphis: zyga aha ok thanks, i'll pull that branch and try to reproduce [11:22] fgimenez: it would be good to try to run that same seqeunce with -debug [11:22] zyga: do you have any reference to a failure in ubuntu? i haven't seen that one [11:22] PR snapd#3263 closed: snap: make `snap prepare-image --extra-snaps` derive side info [11:22] fgimenez: not at hand, I recall re-triggering tests a few times on this test [11:22] zyga: ok will try on ubuntu too [11:24] zyga: that requires line doesn't seem to help [11:25] PR snapd#3288 opened: tests: disable create-key test on ppc64el for artful (expect not working) [11:26] morphis: let me look [11:28] morphis: maybe it's just a fedora thing, e.g. look at Requires: /sbin/ifconfig in https://fedoraproject.org/wiki/Packaging:Guidelines [11:28] possible [11:28] morphis: worth asking in a opensuse IRC channel perhaps? [11:29] morphis: or looking at a few random packages [11:29] yeah, let me spend a bit more time with this and then I will do that [11:33] zyga: ok, looks like it is python-doctuils vs. python3-docutils [11:33] mvo: hey, is 2.26 cut yet such that we are doing point releases? [11:34] jdstrand: not quite done yet, zyga brought 1689332 to our attention and I think we want to fix this first [11:34] 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] PR snapd#3285: interfaces/network: workaround Go's need for NETLINK_ROUTE with 'net'. LP: #1689536 [11:36] mvo: do you need a hand with that? I will be done with reviews shortly (well, in 1-2 hours) [11:36] mvo: I can help you after the standup [11:36] jdstrand: well 2.25 is not even in stable, it will take a bit [11:36] jdstrand: yes, that one is in [11:37] 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] 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] 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] mvo: I think we should instead ask if we need to release ubuntu-core ever again [11:37] 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] pedronis: ok, let me take a note of that and at some point I'll introduce a warning [11:39] 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] zyga: ok, fixed it: https://build.opensuse.org/package/show/home:mrmorph:branches:system:snappy/snapd [11:51] morphis: let's stop building for 42.1 [11:52] morphis: why do we depend on openssh? for git clones? [11:56] mvo: did we ever tested anything working but apt upgrade for 16.04.1 ? [11:56] what else would you test ? [11:58] zyga: we now depend on ssh-keygen [11:58] mvo: oh (not that this needs to be handled with priority), did you see my PR for the classic snap? [11:58] ahh [11:59] mvo: (just want in on your radar) [11:59] jdstrand, given you already uploaded it ... thats just paperwork :) [12:00] ogra_: indeed, but I didn't want someone to upload without it :) [12:00] 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] and let me tell you, my logs are much happier now :) [12:00] yay [12:00] there is another issue with the pty (again) [12:01] jdstrand: not sure, I have a look [12:01] that i want to tackle soon [12:01] ogra_: not sure I can give you that, access is mostly done by gustavo [12:01] niemeyer, can i get commit access to https://github.com/snapcore/classic-snap ? [12:01] mvo: https://github.com/snapcore/classic-snap/pull/9 [12:01] PR classic-snap#9: plugs classic-support and update dump for latest snapcraft [12:02] mvo: again, not high priority [12:03] jdstrand: thank you! [12:04] jdstrand: merged, thank you. and you are very welcome to upload [12:04] mvo: thanks! [12:06] noise][, cprov: could I get some assistance with https://forum.snapcraft.io/t/sosreport-moved-under-sosreport-team/480 [12:07] ogra_: I will land #30 for snapcore/core and #5 for snapcore/core-build [12:07] * ogra_ checks [12:07] stokachu: I can take a look in a couple hrs i think [12:07] is that the cloud stuff ? [12:07] noise][: ok thanks [12:08] mvo, perfect, i wanted to bring that up in todays standup ... [12:10] PR core#30 closed: Update core snap cloud-init configuration [12:10] PR core-build#5 closed: Update cloud-init configuration [12:10] * ogra_ hugs mvo [12:10] rharper, ^^^ happy testing [12:11] ogra_: my pleasure, we really need to hug rharper here :) [12:11] yeah [12:13] mvo, oh, the second one needs a PPA upload and there is another sync missing that i need to do before [12:13] (i'll handle that) [12:13] pstolowski: what are the next steps for https://github.com/snapcore/snapd/pull/3212 [12:13] PR snapd#3212: api, ifacestate: resolve disconnect early [12:13] ogra_: cool, thank you [12:13] zyga: can you disable the 42.1 build? [12:13] morphis: let me know when you want to update the opensuse repository with the extra patches [12:13] morphis: yes [12:14] zyga: what do you mean with extra patches [12:15] morphis: extra build deps for the next release [12:16] ah [12:16] morphis: https://build.opensuse.org/package/show/system:snappy/snapd no longer builds for 42.1 [12:16] I will propose a review soon [12:16] excellent, thank you! [12:17] zyga: I need to look at it again it seems [12:17] 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] s/plug/plus/ [12:23] pedronis, pstolowski: aha, thank you; [12:24] Chipaca: can you do a trivial 2nd review on https://github.com/snapcore/snapd/pull/3288 [12:24] PR snapd#3288: tests: disable create-key test on ppc64el for artful (expect not working) [12:24] zyga: already am [12:27] thank you :) [12:28] PR core-build#12 opened: sync missing deb upload into branch [12:28] 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] morphis, mvo, https://github.com/snapcore/core-build/pull/12 please ... [12:29] PR core-build#12: sync missing deb upload into branch [12:29] jacekn: if an assertion is present in the store it will connect to log-observe [12:29] jacekn: other than that, no] [12:30] zyga: https://build.opensuse.org/request/show/494230 [12:30] ogra_: will have a look [12:30] thx [12:30] morphis: thank you [12:31] morphis: I approved but perhaps we can drop the python-docutils dependency [12:31] morphis: is one needed for 42.2 and other for tumbleweed? [12:32] zyga: joining us? [12:32] zyga: I think so [12:32] zyga: so I'm after allow-auto-connection yes? Where can I find docs about how to get it set up? [12:34] 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] pstolowski: givent that connect/disconnect involve exactly two snaps it should be possible to fix CheckChangeConflict [12:34] zyga: ok thanks a lot [12:34] (autoconnect is a different story but we will get there) [12:35] jacekn: follow the first bulletpoint under 'Process' in https://forum.snapcraft.io/t/process-for-reviewing-aliases-and-auto-connections/455 [12:37] jdstrand: aha (I was looking for something in the official docs: https://docs.ubuntu.com/core/en/reference/assertions/snap-declaration ) [12:37] jacekn: this is all new [12:37] so the docs haven't caught up yet [12:37] pedronis, fair point. i'll take a look at this soon, got sidetracked by other things (namely snapctl outside of hooks) [12:38] jdstrand: ok understood [12:41] PR snapd#3289 opened: daemon: do not allow to install ubuntu-core anymore [12:43] Mornings [12:43] mvo: I think you could as you were an admin on that repo, but done either way [12:43] mvo: I usually give access to a team rather than a person, btw.. [12:43] mvo: snapd-committers in this case [12:43] ogra_: Done [12:44] niemeyer: thank you [12:44] niemeyer, thanks ... i think that was rather special since it initially lived in a private branch... [12:44] well, not private but personal [12:44] PR snapd#3288 closed: tests: disable create-key test on ppc64el for artful (expect not working) [12:44] ogra_: Yeah, that should be it [12:47] zyga: 3262 has a conflict [12:47] zyga: looks good otherwise I think [12:52] mvo: I'll take care of that, thank you [12:53] ta === chihchun is now known as chihchun_afk [13:05] PR core-build#12 closed: sync missing deb upload into branch [13:05] mvo, thx! [13:19] 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] sborovkov, do you have libdbus-1-dev in build-packages ? [13:23] ogra_: in stage-packages [13:23] is that incorrect [13:23] try build-packages ... [13:23] thanks! [13:27]