/srv/irclogs.ubuntu.com/2017/05/10/#snappy.txt

abesdragonboard emmc flashing instead of SD03:33
abeshttps://discuss.96boards.org/t/ubuntu-core-on-emmc/161103:33
=== chihchun_afk is now known as chihchun
mupPR snapcraft#1304 opened: cleanbuild: set the container language to en_US.UTF-8 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1304>05:17
=== chihchun is now known as chihchun_afk
mupPR 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:04
zygagood morning07:16
zygahey there mvo! :)07:16
zygathanks for merging that :)07:16
zygawoot, we are on one-page-long of PRs :)07:16
mvozyga: hey, good morning07:20
mupPR snapd#3286 closed: cmd/snap: tweak info channels output <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3286>07:23
zygamvo, jdstrand, tyhicks: in addition to coverity I would consider adding https://github.com/google/oss-fuzz07:32
pstolowskimorning07:38
zygahey hey :)07:39
zygapstolowski: can you please merge master into https://github.com/snapcore/snapd/pull/3119 and add the extra description for the old interface methods07:40
mupPR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>07:40
pstolowskizyga, yes, doing right now07:40
zygaexcellent, thank you!07:40
mupPR snapd#3287 opened: tests: unify tests/{main/completion,completion}/lib.exp0 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3287>07:57
mupPR core-build#10 closed: make /etc/environment writable <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/10>07:58
Chipacazyga: ^ 3287 should fix the expect timeouts08:27
mupPR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>08:32
zygaChipaca: looking08:38
zygaChipaca: thank you!08:41
pstolowskizyga, update iface-hooks-api with master, waiting for tests08:44
zygapstolowski: did you find any stale APIs?08:45
pstolowskizyga, 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 PR08:46
pstolowskizyga, yes, but only in the "expected" ones (new interfaces that appeared in msaster)08:46
pstolowski*master08:46
zygapstolowski: excellent, thank you!08:47
=== chihchun_afk is now known as chihchun
morphiszyga: feeling comfortable to give https://github.com/morphis/meta-snappy/pull/9 a shot?09:19
mupPR morphis/meta-snappy#9: Add support for pyro and drop golang toolchain <Created by morphis> <https://github.com/morphis/meta-snappy/pull/9>09:19
zygamorphis: yes, if you tell me how to try this09:20
morphiszyga: https://github.com/morphis/meta-snappy/blob/master/README.md but checkout out the pyro branch of poky instead of morty09:21
zygaok09:21
zygamorphis: btw, what is it with the naming scheme?09:24
zygapyro/morty/poky?09:24
morphispyro and morty are release code names09:24
morphispoky is the name of the collection of recipes Yocto releases09:25
morphishttps://www.yoctoproject.org/tools-resources/projects/poky09:25
morphismorty is the current stable release and pyro the next one09:26
morphishttps://wiki.yoctoproject.org/wiki/Releases09:26
* zyga mentally paste's chipaca's signature ascii emoji09:27
zygamvo: 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/292909:30
mupPR snapd#2929: interfaces/builtin: add storage-framework-service interface <Created by michihenning> <https://github.com/snapcore/snapd/pull/2929>09:30
mvozyga: nice, thank you09:32
Chipacazyga: you mean ヽ(´▽`)/ right?09:37
zygaChipaca: lol :D09:41
Chipacazyga: ( ˘ ³˘)♥09:41
Chipacazyga: do the mount namespace thingies do the right thing on snapd restart?09:44
mupPR 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
zygaChipaca: which is?09:45
zygaChipaca: (we don't touch them)09:45
zygaChipaca: which is arguably perhaps wrong (I have a bug open for that)09:45
Chipacazyga: I don't know what the right thing is :-)09:45
zygahttps://bugs.launchpad.net/snapd/+bug/166747909:45
mupBug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479>09:45
zygaChipaca: I only know about this thing being wrong09:46
Chipacazyga: but i was wondering whether it was leftover state that could break if expectations changed09:46
zygawhich is a special case of update-ns09:46
zygaaha09:46
zygaChipaca: each test restore code unmounts them09:46
zygaChipaca: so they should go away09:46
zygaChipaca: as for restart09:46
zygaChipaca: we re-gen new seccomp and apparmor profiles then but those don't affect the mount namespace09:46
zygaChipaca: we don't regenerate (or update as update-ns is not finished) the mount profiles09:47
pedronismvo: hi, I +1ed snapd#3263 but it seems to have failing tests09:52
mupPR snapd#3263: snap: make `snap prepare-image --extra-snaps` derive side info <Created by mvo5> <https://github.com/snapcore/snapd/pull/3263>09:52
mvopedronis: thanks, checking now09:52
mvopedronis: test failures were in the completion tests, I think some fixes went into master, lets see if that helps09:54
Chipacazyga: and should we?09:56
zygaChipaca: yes10:04
zygaChipaca: we should return to that10:05
zygaChipaca: it dates back to the BuildID thing10:05
* zyga thinks that https://github.com/snapcore/core-build/pull/11 is scary10:09
mupPR core-build#11: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>10:09
zygamvo: what are your thoughts on https://github.com/snapcore/snapd/pull/3226#discussion_r11558496810:10
mupPR snapd#3226:  snap-repair: add `snap-repair run`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3226>10:10
Chipacabrb, new kernel to test10:10
zygapstolowski: 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.gz10:11
pstolowskilooking10:11
zygapstolowski: for your 3120 PR10:11
zygamorphis: I'll look at building oe soon10:13
zygamorphis: but I will do a few more reviews before that10:13
morphiszyga: ok10:13
* zyga looks at mvo's https://github.com/snapcore/snapd/pull/259210:13
mupPR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>10:13
zygafgimenez: hey, do you know why the openvswitch tests are failing? I see them fail frequently10:15
zygafgimenez: 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=notification10:15
fgimenezzyga: looking10:16
zygafgimenez: thanks!10:16
mvozyga: makes sense, no disagreement, I think we need to consider how far we want to go in each iteration10:17
mvozyga: re the reapir run code question10:17
morphispedronis: is the syntax of the `snap alias` command changing with the upcoming 2.26?10:18
pstolowskizyga, 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 ok10:18
zygapstolowski: great, do you want to wait for gustavo's review10:19
fgimenezzyga: 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 ubuntu10:21
fgimenezzyga: i'll try to reproduce and get a debug console for getting more info10:21
zygafgimenez: thank you!10:22
zygafgimenez: note that it happens frequently but not always10:22
zygaperhaps related to ordering?10:23
zygafgimenez: can I restart that run now?10:23
fgimenezzyga: ok thanks! no idea, will let you know how it goes10:23
pstolowskizyga, with 3119 yes, i'd like niemeyer to review it too10:23
zygapstolowski: ok10:23
pedronismorphis: ?10:26
pedronisit already changed in 2.2510:26
morphispedronis: hm, which isn't yet in stable, right?10:27
pedronisno10:27
morphisthat would explain why it breaks all our tests10:27
morphisbut only when run against edge/beta/candidate10:28
pedronismorphis: what kind of tests?10:28
zygamorphis: you have some real test failures on https://github.com/snapcore/snapd/pull/322210:28
mupPR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>10:28
morphispedronis: spread tests we have for all snaps we maintain10:28
morphispedronis: we call `snap alias pulseaudio parec` and then expect /snap/bin/parec to show up10:29
pedronismorphis: 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 names10:29
morphispedronis: we have them all in the store10:29
pedronismorphis: ok, then not sure why you are using "snap alias" in those tests, we their are not the main spread tests10:30
morphispedronis: need to look a bit more into that10:30
pedronisbit confused here10:30
morphispedronis: we list them in snapcraft.yaml10:31
morphisand then a `snap alias pulseaudio pactl` call was meant to create the alias in /snap/bin10:31
pedronismorphis: well if they are in the store, no need for that10:31
morphisthe snap-declaration in the store allows those aliases to be setup automatically10:31
pedronisI mean that tests is not relevant anymore10:32
pedronisthat doesn't work that way, it's not inteded to work that way anymore10:32
pedronisyou get what the store sets up10:32
morphispedronis: so how do I get now an alias for a locally installed snap?10:32
pedronismorphis: it's all in the forum post:  https://forum.snapcraft.io/t/improving-the-aliases-implementation/1810:33
pedronismorphis: you can setup what we call manual aliases10:33
pedronisthe syntax is a bit different:   snap alias  SNAP.APP ALIAS10:33
morphisah10:33
morphisthat is why it breaks10:33
morphisso a `snap alias pulseaudio pactl` doesn't work anymore10:33
pedronisyes, I said so maybe 3 times :)10:34
morphisbut I didn't got the point that it now needs to be <snap>.<app>10:34
pedroniswell, as I said I don't understand why you need that command?10:34
pedronisis the test installing the snap locally?10:34
morphisyes10:34
pedronisah10:34
morphispedronis: we were verifying that the alias defined in the snap was working10:35
morphisbut as you said, that isn't needed anymore10:35
pedronisthat doesn't make sense anymore10:35
pedronisthere's is no alias defined in the snap concept anymore10:35
pedronisI mean you can fix the test  for the new syntax but as well drop it10:35
pedronisif the intention was checking the aliases in the snapcraft.yaml10:36
pedroniswe will deprecate those at some point10:36
morphisok10:36
pedronisanyway the forum post explains a bit all of this10:37
morphispedronis: are all assertions on the store side are updated automatically?10:37
pedronismorphis: we did a pass of doing that with jdstrand10:37
morphisif I remember well they just defined a list of allowed aliases like [pactl, parec]10:37
morphispedronis: great10:37
zygalinode seems busy now10:38
zygacoffee break then :)10:38
pedronismorphis: 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
morphisgood10:38
pedronisbecause now the assertions needs to list a target too10:38
morphispedronis: so with 2.25 going to stable it is safe to drop the aliases:  part from the snap, right?10:39
morphishowever I think we will leave them for a bit more to gurantee everyone gets correctly updated10:40
pedronisyes, when all your clients you care about are updated to 2.25 though10:40
morphisyeah, that is tricky10:40
pedronismorphis: 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
morphispedronis: thanks!10:42
* pedronis lunch10:42
Chipacaas best as I can tell so far, cking's fix for bug #1672819 works10:45
mupBug #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
Chipacanearly done with all the reproducers10:45
Chipaca\o/10:52
zygare11:06
morphiszyga: something has changed in suse.. https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/i58611:12
zygamorphis: aha, it seems that rst2man is no longer shipped by the package we install11:17
morphisyes11:17
zygamorphis: we can fix this by (perhaps) depending on /usr/bin/rst2man directly11:17
zyga(whatever the package name)11:17
jdstrandpedronis: 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:19
morphiszyga: is there macro for that?11:20
fgimenezzyga: the openvswitch test is disabled for debian on master and is enabled in https://github.com/snapcore/snapd/pull/3274 right?11:20
jdstrandpedronis: 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
mupPR 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
jdstrandpedronis: also, hi :)11:20
zygamorphis: no, it's just Requires: /usr/bin/rst2man AFAIR, let me check11:20
morphisfgimenez: yes, something I still need to look into11:21
morphiszyga: nice, let me try that11:21
zygafgimenez: yes, parts of that test are now enabled11:21
zygafgimenez: note that this test was also failing on ubuntu11:21
zygafgimenez: just not always11:21
fgimenezmorphis: zyga aha ok thanks, i'll pull that branch and try to reproduce11:21
zygafgimenez: it would be good to try to run that same seqeunce with -debug11:22
fgimenezzyga: do you have any reference to a failure in ubuntu? i haven't seen that one11:22
mupPR 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
zygafgimenez: not at hand, I recall re-triggering tests a few times on this test11:22
fgimenezzyga: ok will try on ubuntu too11:22
morphiszyga: that requires line doesn't seem to help11:24
mupPR 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:25
zygamorphis: let me look11:26
zygamorphis: maybe it's just a fedora thing, e.g. look at Requires: /sbin/ifconfig in https://fedoraproject.org/wiki/Packaging:Guidelines11:28
morphispossible11:28
zygamorphis: worth asking in a opensuse IRC channel perhaps?11:28
zygamorphis: or looking at a few random packages11:29
morphisyeah, let me spend a bit more time with this and then I will do that11:29
morphiszyga: ok, looks like it is python-doctuils vs. python3-docutils11:33
jdstrandmvo: hey, is 2.26 cut yet such that we are doing point releases?11:33
mvojdstrand: not quite done yet, zyga brought 1689332 to our attention and I think we want to fix this first11:34
jdstrandmvo: ok. I just wanted https://github.com/snapcore/snapd/pull/3285 in there, but that is already in master so sounds like we are good11:34
mupPR 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:34
zygamvo: do you need a hand with that? I will be done with reviews shortly (well, in 1-2 hours)11:36
zygamvo: I can help you after the standup11:36
pedronisjdstrand: well 2.25 is not even in stable, it will take a bit11:36
mvojdstrand: yes, that one is in11:36
pedronisjdstrand: but we do want to deprecate aliases in snap.yaml and not need auto-aliases in decls but it will take a while11:37
jdstrandpedronis: sure, I was more talking about making sure that PR made it into the correct branch if there was one outside of 2.2611:37
mvozyga: 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-core11:37
zygamvo: I think we should instead ask if we need to release ubuntu-core ever again11:37
jdstrandpedronis: oh haha. you were talking about aliases. funny cause your comment actually sorta worked for what I was talking about with mvo :)11:37
jdstrandpedronis: ok, let me take a note of that and at some point I'll introduce a warning11:38
mvozyga: 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:39
morphiszyga: ok, fixed it: https://build.opensuse.org/package/show/home:mrmorph:branches:system:snappy/snapd11:48
zygamorphis: let's stop building for 42.111:51
zygamorphis: why do we depend on openssh? for git clones?11:52
pedronismvo: did we ever tested anything working but apt upgrade for 16.04.1 ?11:56
ogra_what else would you test ?11:56
morphiszyga: we now depend on ssh-keygen11:58
jdstrandmvo: oh (not that this needs to be handled with priority), did you see my PR for the classic snap?11:58
zygaahh11:58
jdstrandmvo: (just want in on your radar)11:59
ogra_jdstrand, given you already uploaded it ... thats just paperwork :)11:59
jdstrandogra_: 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
jdstrandand let me tell you, my logs are much happier now :)12:00
ogra_yay12:00
ogra_there is another issue with the pty (again)12:00
mvojdstrand: not sure, I have a look12:01
ogra_that i want to tackle soon12:01
mvoogra_: not sure I can give you that, access is mostly done by gustavo12:01
ogra_niemeyer, can i get commit access to https://github.com/snapcore/classic-snap ?12:01
jdstrandmvo: https://github.com/snapcore/classic-snap/pull/912:01
mupPR classic-snap#9: plugs classic-support and update dump for latest snapcraft <Created by jdstrand> <https://github.com/snapcore/classic-snap/pull/9>12:01
jdstrandmvo: again, not high priority12:02
mvojdstrand: thank you!12:03
mvojdstrand: merged, thank you. and you are very welcome to upload12:04
jdstrandmvo: thanks!12:04
stokachunoise][, cprov: could I get some assistance with https://forum.snapcraft.io/t/sosreport-moved-under-sosreport-team/48012:06
mvoogra_: I will land #30 for snapcore/core and #5 for snapcore/core-build12:07
* ogra_ checks12:07
noise][stokachu: I can take a look in a couple hrs i think12:07
ogra_is that the cloud stuff ?12:07
stokachunoise][: ok thanks12:07
ogra_mvo, perfect, i wanted to bring that up in todays standup ...12:08
mupPR core#30 closed: Update core snap cloud-init configuration <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/core/pull/30>12:10
mupPR 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 testing12:10
mvoogra_: my pleasure, we really need to hug rharper here :)12:11
ogra_yeah12:11
ogra_mvo, oh, the second one needs a PPA upload and there is another sync missing that i need to do before12:13
ogra_(i'll handle that)12:13
zygapstolowski: what are the next steps for https://github.com/snapcore/snapd/pull/321212:13
mupPR snapd#3212: api, ifacestate: resolve disconnect early <Created by stolowski> <https://github.com/snapcore/snapd/pull/3212>12:13
mvoogra_: cool, thank you12:13
morphiszyga: can you disable the 42.1 build?12:13
zygamorphis: let me know when you want to update the opensuse repository with the extra patches12:13
zygamorphis: yes12:13
morphiszyga: what do you mean with extra patches12:14
zygamorphis: extra build deps for the next release12:15
morphisah12:16
zygamorphis: https://build.opensuse.org/package/show/system:snappy/snapd no longer builds for 42.112:16
morphisI will propose a review soon12:16
zygaexcellent, thank you!12:16
pedroniszyga: I need to look at it again it seems12:17
pstolowskizyga, 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 yet12:17
pstolowskis/plug/plus/12:18
zygapedronis, pstolowski: aha, thank you;12:23
zygaChipaca: can you do a trivial 2nd review on https://github.com/snapcore/snapd/pull/328812:24
mupPR 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
Chipacazyga: already am12:24
zygathank you :)12:27
mupPR core-build#12 opened: sync missing deb upload into branch <Created by ogra1> <https://github.com/snapcore/core-build/pull/12>12:28
jaceknhello. 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 slot12:28
ogra_morphis, mvo, https://github.com/snapcore/core-build/pull/12 please ...12:29
mupPR core-build#12: sync missing deb upload into branch <Created by ogra1> <https://github.com/snapcore/core-build/pull/12>12:29
zygajacekn: if an assertion is present in the store it will connect to log-observe12:29
zygajacekn: other than that, no]12:29
morphiszyga: https://build.opensuse.org/request/show/49423012:30
morphisogra_: will have a look12:30
ogra_thx12:30
zygamorphis: thank you12:30
zygamorphis: I approved but perhaps we can drop the python-docutils dependency12:31
zygamorphis: is one needed for 42.2 and other for tumbleweed?12:31
morphiszyga: joining us?12:32
morphiszyga: I think so12:32
jaceknzyga: so I'm after allow-auto-connection yes? Where can I find docs about how to get it set up?12:32
zygajacekn: I think you need to request a new snap declaration assertion from the store, jdstrand can set one up for you, I think12:34
pedronispstolowski: givent that connect/disconnect involve exactly two snaps it should be possible to fix CheckChangeConflict12:34
jaceknzyga: ok thanks a lot12:34
pedronis(autoconnect is a different story but we will get there)12:34
jdstrandjacekn: follow the first bulletpoint under 'Process' in https://forum.snapcraft.io/t/process-for-reviewing-aliases-and-auto-connections/45512:35
jaceknjdstrand: aha (I was looking for something in the official docs: https://docs.ubuntu.com/core/en/reference/assertions/snap-declaration )12:37
jdstrandjacekn: this is all new12:37
jdstrandso the docs haven't caught up yet12:37
pstolowskipedronis, fair point. i'll take a look at this soon, got sidetracked by other things (namely snapctl outside of hooks)12:37
jaceknjdstrand: ok understood12:38
mupPR snapd#3289 opened: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>12:41
niemeyerMornings12:43
niemeyermvo: I think you could as you were an admin on that repo, but done either way12:43
niemeyermvo: I usually give access to a team rather than a person, btw..12:43
niemeyermvo: snapd-committers in this case12:43
niemeyerogra_: Done12:43
mvoniemeyer: thank you12: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 personal12:44
mupPR 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
niemeyerogra_: Yeah, that should be it12:44
mvozyga: 3262 has a conflict12:47
mvozyga: looks good otherwise I think12:47
zygamvo: I'll take care of that, thank you12:52
mvota12:53
=== chihchun is now known as chihchun_afk
mupPR 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:05
sborovkovHi. 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.h13:19
ogra_sborovkov, do you have libdbus-1-dev in build-packages ?13:20
sborovkovogra_: in stage-packages13:23
sborovkovis that incorrect13:23
ogra_try build-packages ...13:23
sborovkovthanks!13:23
abeatoogra_, is there any good description around of what UC does on first boot? Is there any special service that is run?13:27
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 here13:28
abeatoogra_, ok13:29
* abeato waiting for some more info from pinged guys ;)13:30
zygaabeato: yes it does special stuff13:32
zygaabeato: it installs all the pre-seeded snaps13:32
zygaabeato: and runs the device-prepare hook13:32
sborovkovogra_: that helped, thanks!13:33
ogra_:)13:33
=== dasjoe_ is now known as dasjoe
ali1234if 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:36
abeatozyga, where is that done? from a systemd unit?13:37
zygaabeato: internally by snapd13:38
pedronisabeato: it's all doen from inside snapd13:38
pedronisthere are no special units anymore13:38
ogra_we should have some blog post or a doc for it one day ;)13:38
abeatozyga, pedronis got it, thanks13:39
pedronisabeato: notice thought that one of the things we discussed recently is to reintroduce some way to know seeding has happened at the systemd level13:39
ogra_a little step by step overview would be nice13:39
pedronisogra_: yea, mvo or me should do at least a doc forum post on this13:39
abeatoogra_, +113:39
ogra_+113:39
zygafg13:39
* ogra_ backgrounds zyga again13:39
fgimenezzyga: no luck reproducing the openvswitch test error in isolation so far, will try the full suite next13:40
zygafgimenez: perhaps get it to run with the same seed13:41
zygafgimenez: as it failed in the PR13:41
zygafgimenez: and thank you for checking!13:41
fgimenezzyga: indeed, i didn't save it though, do you happen to have it?13:41
fgimenezzyga: np :)13:41
zygafgimenez: ah, I think not13:42
fgimenezzyga: no problem, i'll execute with -reuse in a loop13:42
mupPR snapd#3290 opened: add support for `snap install foo --channel=3.4` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3290>13:42
zygathanks13:42
mvofgimenez: could you please double check if 1689332 also happens with ubuntu-core from stable?13:42
Chipacamvo: niemeyer: dunno if you decoded my blathering earlier about cking having found a fix for bug #167281913:46
mupBug #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
Chipacawas going to mention it in the standup and forgot13:46
Chipacawith that, and mwhudson having backported go 1.8's fix for the EAGAIN from pthread_create, we should have no more issues with exec13:46
fgimenezmvo: 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 goes13:49
rharperogra_: mvo \o/13:49
fgimenezmvo: yes, all works fine with ubuntu-core from stable http://paste.ubuntu.com/24549041/14:06
mvofgimenez: thank you!14:06
ogra_niemeyer, https://forum.snapcraft.io/t/allow-handling-of-certain-system-services-on-ubuntucore-images/53114:06
zygawho wants to take https://github.com/snapcore/snapd/pull/329114:07
mupPR 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:07
Chipacaniemeyer: fyi go's ProxyFromEnvironment docs say the HTTP_PROXY and http_proxy are both checked (and the code confirms this)14:08
Chipacanot wanting to describe your trousers as aflame, but there's that14:09
mvofgimenez: where is that test that was used to find bug 1689332 ?14:10
mupBug #1689332: internal error with any command using ubuntu-core snap on classic <snapd:In Progress by zyga> <https://launchpad.net/bugs/1689332>14:10
mvoogra_: can you please stop auto-building ubuntu-core for now?14:10
ogra_mvo, ok14:10
zygapstolowski: maybe you? :)14:10
ogra_mvo, done (cronjob on lillipilly disabled)14:12
mvota14:12
pstolowskizyga, sure, will take a look14:13
fgimenezmvo: 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-cron14:13
fgimenezmvo: 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 rev14:14
mvofgimenez: I think we will just need to tweak like this: https://github.com/snapcore/snapd/pull/3289/commits/cecad5139c5867a03ae50607a46f1d5b35058b8314:15
mupPR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>14:15
mvofgimenez: 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 release14:15
mvofgimenez: 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
fgimenezmvo: great, thank you! :) i'll give it a try14:16
fgimenezmvo: 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 checks14:17
zygaChipaca: maybe you can look at https://github.com/snapcore/snapd/pull/329114:18
mupPR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>14:18
zygaChipaca: if I can land this quickly I'll fixup the other PRs instead of constantly updating this one :)14:18
zygaChipaca: (other meaning remaining branches that add new interfaces)14:19
mupPR 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:20
Chipacazyga: 's good14:22
zygaChipaca: 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 same14:23
Chipacazyga: any sorting beyond dependency analysis is probably circumstantial14:24
mupPR 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:24
mupBug #1674794 changed: journald.conf storage=volatile config support <Snappy:Invalid> <https://launchpad.net/bugs/1674794>14:29
fgimenezmvo: works great, thanks a lot! :)14:35
mvofgimenez: \o/14:37
mvofgimenez: 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 core14:39
fgimenezmvo: sure sounds great, i'll prepare spread-cron branches to make it happen14:40
mvofgimenez: thanks \o/14:40
mvofgimenez: I updated edge for ubuntu-core, could you please run the test again to see if things are happy now?14:42
juanrubioHi 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:43
zygajuanrubio: do you get any apparmor denials (tip: dmesg | grep DENIED)14:44
juanrubiozyga: yes, I'm getting that14:45
zygajuanrubio: can you please share them14:45
juanrubiozyga: in Fedora 25, this work always (with or without --devmode)14:46
zygajuanrubio: in fedora 25 confinement is disabled14:46
juanrubiozyga: I see.14:49
juanrubiohttps://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml14:49
juanrubiozyga: the snap link is coming14:49
Chipacaconfinement is *currently* disabled14:49
Chipacain the fullness of time that will not be the case14:50
zygajuanrubio: I'd rather see the list of denials on 16.04 than the snap14:50
juanrubiozyga: denials -> https://gist.github.com/juanrubio/d8752890ac6780d3627d9a1eae048de914:52
zygajuanrubio: quick comment, what did you hope to achieve with this declaration? https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml#L2114:56
zygajuanrubio: (it is wrong)14:56
zygamorphis: [ 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
zygamorphis: does X11 use abstract sockets too?14:57
pstolowskiniemeyer, 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-x1114:57
ogra_we discussed that yesterday14:57
zygajuanrubio: 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
juanrubiozyga: dbus? - tizonia uses a resource manager daemon, but that fuctionality is disabled right now14:58
ogra_s/ofr/for/14:58
zygajuanrubio: in any case, the dbus plug definition is wrong14:58
ogra_juanrubio, y<ou have dbus-x11 in your snapcraft.yaml14:58
ogra_(at least you did yesterday when i looked :) )14:59
zygajuanrubio: you need to add an entry as I said, with bus: and name: keys14:59
* zyga gets back to coding14:59
zygamvo: maybe you can do a 2nd review on https://github.com/snapcore/snapd/pull/329114:59
mupPR 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 conflicts14:59
Chipacamvo: it's long, but mechanical15:00
zygaChipaca: it shows that github stops parsing/colorizing code at some point :)15:00
juanrubiozyga,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 installations15:01
Chipacazyga: not here15:02
Chipacazyga: suspect it might be your browser giving up in disgust15:02
mupPR snapd#2929 closed: interfaces/builtin: add storage-framework-service interface <Created by michihenning> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2929>15:34
lutostagCan 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
lutostagand snapcraft push fails with a similar but different error...15:35
zygamvo: replied to your questions, thank you for reading that monster :)15:35
zygamvo: either merge all the interfaces or refrain from doing so, so that 3291 won't conflict15:41
zygamvo: I'm happy with either :)15:41
mvozyga: hm, 2869 looks like an easy win too15:42
zygamvo: get them all in then15: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
mvozyga: it now conflicts though and 2941 too15:42
zygamvo: I'll do all de-conflicting on the other side15:42
zygamvo: hehe15:43
zygamvo: all those conflicts is why I made the 3291 in the first place :)15:43
zygamvo: no worries, just give me +1 to merge and I'll resolve the rest15:43
mvoogra_: oh, I guess I will need to read that15:43
juanrubiozyga: do we know what's the issue with the apparmor denials?15:43
mvoogra_: 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 well15:43
zygajuanrubio: no, I don't know15:44
zygajuanrubio: I didn't dig deeply though15: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 moot15:44
ogra_seems sensible to me ...15:45
ogra_not sure where backward compat would be an issue15:45
rharpermvo: 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 yet15:45
juanrubiozyga: thanks. Do you feel a bug should be filed for this?15:45
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 core15:46
zygajuanrubio: no, not immediately, please open a forum topic, use the snap category15:46
rharperogra_: ok, thanks15:46
mvozyga: hm, hm, I guess your sequence (3291, then the other interface code) would have been more efficient, each interface branch that lands conflicts right now15:46
juanrubiozyga: ok, i'll do that15:46
zygamvo: no worries :)15:48
mvozyga: sorry for that!15:48
mvozyga: its just two interface branches left, right? so not toooooo terrible15:48
zygamvo: I'm just happy to land this eventually so that other people have less headache :)15:48
zygamvo: yep15:48
zygamvo: plus several waves of cleanups I'm working on15:48
zygalots of silly stuff that's crufily copy-pasted around15:48
pstolowskizyga, ah, 3291 has conflicts now15:57
zygayeah, I'll resolve them after finishing one more branch16:00
morphiszyga: looks like16:08
morphiszyga: need to explore a bit what the X abstraction allows today16:08
* zyga nods16:09
mupPR snapd#3119 closed: interfaces: API additions for interface hooks <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3119>16:17
* zyga looks at https://github.com/snapcore/snapd/pull/3291 and cries a little16:18
mupPR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>16:18
zygawell :D16:18
juanrubiozyga,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=juanrubio16:29
zygajuanrubio: thanks16:32
morphisjuanrubio: thanks!16:33
cachioChipaca, hey, I need to add the proxy to a ubuntu core instance to run spread tests16:33
Chipacacachio: hey16:33
Chipacacachio: I think the fix to make /etc/environment writable in core isn't ready yet16:33
Chipacacachio: but if it's just for testing, it's easy to work around16:33
cachioChipaca, yes, I need to run the spread tests on that machine16:34
Chipacacachio: pop a file anywhere (e.g. /root/, or /var), and then mount --bind /the/file /etc/environment16:34
Chipacacachio: (it's also very easy to make this fix permanent, if it were something that needed to work longer term)16:35
Chipacajust 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/system16:35
cachioChipaca, ok16:36
cachioChipaca, do you know if the snap client will support proxy?16:36
Chipacacachio: there's some tricky details for the second half; give me a shout if you need it16:36
Chipacacachio: yes, in the same way as snapd16:37
Chipaca(set HTTPS_PROXY or https_proxy or HTTP_PROXY or http_proxy in the environment)16:37
Chipacausually your login shell sources /etc/environment also, so you should be set16:37
cachioChipaca, since when?16:38
Chipacacachio: since when what?16:38
cachioChipaca, is it already upported? or will be supported?16:38
zygahmm hmm hmm16:38
zygaI think pawel's branch had a bug16:39
Chipacacachio: already16:39
Chipacacachio: super easy to confirm, also: http_proxy=potato snap download what16:40
Chipaca<snap vomits>16:40
zygaaww16:41
zygayes it does16:41
zygapawel, you didn't listen to me :/16:42
zygamaster is broken16:42
cachioChipaca, ok, I'll try that too, tx16:42
Chipacazyga: psh, who needs master16:43
mupPR 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:43
morphisPharaoh_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
Chipacazyga: so how do we fix?16:48
zygamaster is fixed with https://github.com/snapcore/snapd/pull/329116:48
mupPR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>16:48
zygaI'll add the missing tests pawel didn't add16:49
zygaok, tests written16:54
zygaChipaca: I'm going to EOD now, can you merge https://github.com/snapcore/snapd/pull/3291 once green16:57
mupPR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>16:57
zygaChipaca: I pushed the missing test as well16:57
Chipacazyga: yes16:58
niemeyerzyga: Which PRs were blocking you?16:58
zyganiemeyer: I'd like to land https://github.com/snapcore/snapd/pull/3225 and iterate on integration, testing and perhaps discard the change.IsNeeded code16:58
mupPR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>16:58
zygaI'll probably come back later tonight to de-conflict remaining interface PRs16:59
niemeyerzyga: Looking, and thanks17:01
zygathanks, and see you tomorrow!17:01
=== ejat_ is now known as ejat
=== cachio is now known as cachio_afk
=== Chipaca is now known as ChipAway
niemeyerzyga: Feedback provided17:12
niemeyerzyga: Some of the points still seem open17:12
morphisniemeyer: do you have time to look at those PRs https://github.com/snapcore/snapd/pulls/morphis except the snapd --user one today?17:13
niemeyermorphis: I'm keen on sorting these out first, and would appreciate help doing that: https://forum.snapcraft.io/t/review-sprint-1/37717:14
morphisI can see what I can do tomorrow17:14
niemeyermorphis: Anything in there is open for more than two weeks17:14
niemeyermorphis: Thanks!17:15
morphisniemeyer: https://github.com/snapcore/snapd/pull/3222 being one of them17:15
mupPR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>17:15
niemeyermorphis: Looking right now17:15
morphisthanks!17:15
mupPR snapcraft#1305 opened: Use architectures field which existed in older LXD <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1305>17:23
ogra_rharper, a new core is building, should be ready within the next 30-45min17:26
ogra_(including your changes)17:26
rharperogra_: thanks!18:02
zygajdstrand: ouch https://lwn.net/Articles/722363/18:03
jdstrandzyga: yeah18:05
jdstrandthe kerenls should be all fixed already though18:06
jdstrandkernels even18:06
zygajdstrand: except for core pi2/318:10
nandayI'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:10
nandayAlternatively, does anyone have any suggestions about who I might talk to?18:11
zygananday: hey18:12
zygananday: you may want to talk to niemeyer18:12
zygananday: but I can also answer some questions if you post them18:12
jdstrandzyga: well, yes, which is the lack of updates is something I keep bringing up. hopefully that was resolved at the sprint?18:13
zygajdstrand: I think it was discussed but we need to work on the implementation18:14
zygajdstrand: I think the design was resolved18:14
jdstrandthat's good news18:16
=== cachio_afk is now known as cachio
zygajdstrand: I made some improvements to interface code, there should be less conflicts now18:19
zygajdstrand: I have some more cleanups piled up, nothing semantic, just lots of cruft in tests and copy-paste badness18:19
jdstrandzyga: fewer conflicts? what do you mean?18:19
zygajdstrand: adding a new interface will no longer change many files18:20
jdstrandoh with PRs?18:20
zygajdstrand: well, less many :-)18:20
zygajdstrand: yes18:20
zygahttps://github.com/snapcore/snapd/pull/3291/files18:20
mupPR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>18:20
jdstrandI see. that'll be nice18:20
ChipAwayzyga: the tests on snapd#3291 have only just started running (~10 mins ago)18:20
zygajdstrand: also merging a PR will now test if it's using any of the old APIs18:20
=== ChipAway is now known as Chipaca
zygaChipaca: yeah, I restarted them18:20
Chipacaoh18:20
zygaChipaca: we ran out of machines18:20
Chipacawhen i left for dinner it hadn't started yet18:21
zygaChipaca: gustavo added more to the pool so I'm hoping this one will pass18:21
zygaChipaca: yes, it ran but timed out after 49 minutes18:21
jdstrandzyga: oh, that's cool18:21
zygajdstrand: https://github.com/snapcore/snapd/pull/3291/commits/f1faec05b48d70f0ebf4a45e48226cbc9278c21b :-)18:21
mupPR snapd#3291: interfaces/builtin: distribute code of touching allInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3291>18:21
Pharaoh_Atemmorphis: I dropped them because rpm will remove it18:23
Pharaoh_Atemthe directory is owned by the package, and if all contents are already gone, rpm will get rid of the directory18:23
jdstrandhuh, neat18:28
mupPR snapd#3293 opened: spread.yaml: increase linode workers by 50% <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3293>18:52
cachioChipaca, did you see what I wrote? I lost connection19:00
cachiodo you have an example of that .mount?19:02
mupPR 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
Chipacacachio: I did not see what you wrote19:31
Chipacacachio: I do have an example of that mount19:32
Chipacacachio: do you have the snapd tree?19:32
Chipacaif so it's super easy to show you :-)19:32
Chipacaotherwise i'll pastebin19:32
cachiopastbin please19:32
mupPR 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
cachioChipaca, I wrote that spread tests are rebooting the target machine and it is making the mount unusable19:33
Chipacacachio: http://pastebin.ubuntu.com/24550581/19:33
Chipacacachio: that's a bind mount .mount unit19:34
Chipacacachio: basically What=<the rw file>, Where=/etc/environment19:34
Chipacafor you19:34
Chipacathe rest remains the same (but edit the description :-) )19:34
Chipacacachio: and, the tricky bit is19:34
Chipacacachio: it *needs* to be called etc-environment.mount19:35
cachioChipaca, great, and just I need to leave it in /etc/systemd/system ?19:35
cachionad restart snapd?19:35
Chipacadrop it in /etc/systemd/system/etc-environment.mount19:35
Chipacathen enable it (systemctl enable etc-environment.mount)19:35
Chipacathen start it (systemctl start ...)19:36
Chipacathen confirm it worked19:36
Chipacathen restart snapd :-)19:36
cachioChipaca, great, I'll try now19:36
cachioChipaca, tx19:36
Chipacacachio: man systemd.mount if you want to learn the how and the why19:37
cachioChipaca,  :) sure19:37
Chipacazyga: src/github.com/snapcore/snapd/interfaces/builtin/storage_framework_service_test.go:87: not enough arguments in call to spec.AddConnectedSlot <- wat19:42
morphisPharaoh_Atem: hm, then that works differently on suse19:46
morphisI don't see /var/lib/snapd removed19:46
mupPR 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:53
mupPR snapcraft#1306 opened: recording: record global build-packages installed on the host <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1306>19:56
* Chipaca looks for the big red STOP THE LINE button20:22
rharperogra_: 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 stable20:29
Chipacarharper: "snap version" output should be enough to know20:32
Chipaca(if not, we should improve it :) )20:32
rharperok, we run early in boot, would snap version run ?20:33
Chipacarharper: if you're in early bring up and not yet at the stage of having snapd running, /etc/os-release might help20:33
rharperok20:33
Chipacaor early boot yeah20:33
Chipacadunno if etc/os-release is there in early boot; it's in the root filesystem20:33
rharperit will20:33
Chipacak20:33
rharpercloud-init runs after localfs is mounted (one of the stages)20:33
Chipacaah ok20:33
rharperthat looks solid, ID=ubuntu-core is similar to the match we did in channel.ini20:34
Chipacarharper: another way is to check whether the root fs is a squashfs :-)20:34
rharperwell, we boot root squashfs in  maas ephemeral, os-release looks good though20:34
rharperthanks for the suggestion20:34
mupPR snapcraft#1307 opened: cli: new UI and internal refactor <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1307>20:41
rharperChipaca: 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:04
rharpernot 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 classic21:05
Chipacayeah, maybe we should include the flags as we do in the user-agent string21:09
mupPR snapcraft#1308 opened: allow capital Y to accept the dev agreement <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/1308>21:59
mupPR 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:54
newbsieI'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?22:58
zyganewbsie: is your putty key added to your launchpad account?23:07
newbsiezyga: yes.23:08
zyganewbsie: note that putty and ssh on linux/macos don't use the same key format23:08
newbsiezyga: 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:08
zyganewbsie: aha23:09
zyganewbsie: so are you using putty or ssh on windows+ubuntu23:09
newbsiezyga: I was using putty, but since it didn't work, I'm trying ssh on windows+ubuntu.23:09
zyganewbsie: so is your windows+ubuntu ssh key on launchpad?23:10
zyganewbsie: it is in ~/.ssh/id_rsa.pub by default23:10
newbsiezyga: It's the same key as on putty, but I exported the private key to ssh format.23:11
zyganewbsie: the id_rsa is the private key23:11
zyganewbsie: id_rsa.pub is the public key23:11
zyganewbsie: public key is short, the private key is a longer block of stuff that begins with -----BEGIN RSA PRIVATE KEY-----23:12
newbsiezyga: The key is generated in puttygen. For the public key, I did ssh-rsa <long hex string> and put it into launchpad.23:13
newbsiezyga: for the private key, it is in ppk format, and then I export it to openssh format23:13
newbsiezyga: but it is not working. Maybe I should start from scratch and use openssh to generate the keys.23:15
zyganewbsie: not sure, it's too late for me :)23:16
zyganewbsie: you can always yank the card from pi23:16
zyganewbsie: put it into your laptop23:16
zyganewbsie: and look at what is in the .ssh/authorized_keys23:16
newbsiezyga: how do I tell ssh to use a private key?23:17
zyganewbsie: man ssh has all the secrets, I believe it is the -i option23:18
zyganewbsie: (and I assume you meant to ask "which key to use", it always uses private keys23:18
newbsiezyga: this whole SSO is frustrating23:18
Chipacanewbsie: ssh is very picky about permissions23:19
Chipacanewbsie: if you add the -v option it will print a lot of info about what's going on23:20
Chipacanewbsie: if you want you could pastebin that, maybe it'll help us help you23:20
Chipacaotoh, putty _should_ work but i don't have a way to try it23:20
zygaChipaca: oh, good idea23:21
Chipacaoh wait, there's a putty for ubuntu23:21
zyganewbsie: on windows+ubuntu files is often 777 by default23:21
Chipacawonder if it's the same23:21
zygachmod -og= -R .ssh23:21
newbsieChipaca: ssh complaining about file permission is to open.23:22
zyganewbsie: yep23:22
zygado the chmod23:22
Chipacanewbsie: that thing with the chmod zyga suggested is not him having a fit, he was trying to tell you to run that :-)23:22
newbsieit's saying there is no -og= mode23:23
zygahmm23:23
zygamy bad23:23
Chipacaog-r, i think?23:23
zygachmod -R og= ~/.ssh/23:23
Chipacaah23:24
zyga^ tested23:24
* Chipaca looks up =23:24
zygaChipaca: assign23:24
zygaChipaca: I fixed master and all the open branches that touch interfaces23:24
Chipacaassign nothing, ie clear23:24
Chipacagotcha23:24
Chipacazyga: i saw my branch magically fix itself23:24
Chipacazyga: thanks :-)23:25
zygaChipaca: with the extra workers we can now run several tests in parallel23:25
zygaChipaca: I have one more branch if you want to read :)23:25
newbsieSo I do the following: ssh -i private_key.pub <username>@192.168.1.9 -v23:25
zygaChipaca: makes all of interface implementation private23:25
zygaChipaca: and exposes only one function, interfaces.Interfaces()23:25
zygaChipaca: doing that makes goling happy and found a few ugly things in tests23:26
newbsieBut then get an error, unable to open file. Permission denied.23:26
Chipacanewbsie: which file?23:26
Chipacazyga: sure, shoot23:26
zygaChipaca: one sec, just need to rebase it23:26
zygaChipaca: it's another monster-ish branch23:26
zygaChipaca: :D23:27
newbsieChipaca: private_key.pub23:27
newbsiewhich is the private key. I think it is misnamed.23:27
zygawith a space?23:27
newbsiezyga: It's underscore23:27
Chipacanewbsie: permission denied might mean exactly that23:27
Chipacanewbsie: what does "ls -l private_key.pub" say?23:27
* zyga looks at http://paste.ubuntu.com/24551684/23:28
zygaand cries a little :D23:28
newbsieChipaca: only owner has read, everything else is disabled.23:28
Chipacanewbsie: and the owner is the user you're trying to ssh as?23:29
Chipacanewbsie: in other words23:29
Chipacaeasy way to check23:29
Chipacaif you enter "cat private_key.pub"23:29
Chipacado you see the contents of the file23:29
zyga(just don't paste them)23:30
newbsieChipaca: No. That's odd.23:30
newbsieChipaca: I created the file as the current user, and it has my username23:30
Chipacanewbsie: what does “id” say?23:30
Chipacathat is, does “id” agree that you are you23:30
newbsieChipaca: Yes23:31
zyganewbsie: quick question23:31
zyganewbsie: how did you create it23:31
zyganewbsie: did you created it from windows?23:31
zyganewbsie: or from windows+ubuntu?23:31
newbsiezyga: nano private_key.pub23:31
zyganewbsie: ok23:31
newbsiezyga: from within windows+ubuntu23:31
zygaChipaca: if you don't know you cannot ever touch anything from windows that is in windows+ubuntu or it explodes in magic ways23:32
Chipacazyga: I thought they'd fixed that with the latest patch23:32
Chipacathe ... anniversary edition, or something23:32
newbsieSo, 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
zygaChipaca: not that I know23:33
zygafo23:33
zygaof23:33
Chipaca¬_¬23:33
zyganewbsie: wait23:33
zyganewbsie: not o23:33
zyganewbsie: o is 'oter'23:34
zygaother23:34
zyganewbsie: you want 'u'23:34
zyganewbsie: chmod og=,u=rwX23:34
Chipacayeah, don't let otters read your keys23:34
zygachmod that recursively on .ssh23:34
Chipacahands up if you think it should've worked from putty23:35
Chipacao/23:35
zyga\o23:35
* zyga is left handed23:35
Chipacanewbsie: i think we asked you this before, but, the key you uploaded to launchpad, was it in the format openssh expects?23:36
newbsieIt 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
mercurio56help23:36
Chipacanewbsie: they == us :-)23:36
Chipacamercurio56: wat23:36
newbsieChipaca: I believe so. That's the same format I used to configure Ubuntu Server i.e. ssh-rsa <long hex string>23:37
newbsieThe problem is private key is missing begin marker.23:37
Chipacanewbsie: progress!23:37
newbsieChipaca & zyga: I appreciate the help so far!23:38
Chipacanewbsie: so23:38
Chipacanewbsie: silly question23:38
Chipacanewbsie: is there a reason you can't generate a whole new key pair direclty with openssh?23:38
Chipacanewbsie: that's "ssh-keygen"23:39
newbsieChipaca: 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:39
zyganewbsie: otherwise it'd be totally insecure23:40
zyganewbsie: how would you log in? ubuntu/ubuntu?23:40
newbsiezyga: yes, and change the password.23:40
Chipacanewbsie: yeah, no, that's how the IoT botnets exist23:40
zyganewbsie: what about 99% of the people who will never do that?23:40
newbsiezyga: better yet, have a script to run and do whatever it needs to do23:40
Chipacaanyhow, you are right in that we should make a guide for windows23:41
Chipacai wonder who has windows that could write a guide for this23:41
newbsieI'm just frustrated since I spent so much time, and I'm not completely new to Ubuntu.23:41
newbsieJust rusty.23:41
Chipacanewbsie: if you could channel this frustration into a forum topic about this, it'll help other people pick it up and fix it23:42
Chipacanewbsie: otherwise I'll do it23:42
zyganewbsie: yes! you can help everyone!23:42
newbsieI will definitely do that.23:43
Chipacaexcellent :-)23:43
Chipacaalso, try not to swear too much :-p23:43
newbsieMy wise fiance says, swearing is for those that cannot express themselves.23:43
newbsieSo I try to learn to express myself.23:44
zygaChipaca: almost done23:44
newbsieAnyhow, I appreciate not being told to RTFM or that you suck during my outburst of frustration.23:44
Chipacai tell my boys that they have this awesome vocabulary, and it's a shame to waste it and go the lazy route of just swearing23:45
ChipacaI only tell people to RTFM when I know they wrote the M in the first place :-)23:45
* Chipaca just realized that "write the fine manual" has a very apropos initialism23:47
Chipacazyga: huzzah23:47
newbsieChipaca: lol23:47
newbsieChipaca: How do the people that wrote the manual take it? :)23:47
Chipacathey know me, so they take it well23:48
Chipacazyga: we should package putty as a snap23:49
zygaChipaca: for... ? nostalgia?23:50
Chipacazyga: to watch the world burn?23:51
Chipacazyga: i think it's just that it's 1am and my brain is easily amused23:51
zygaChipaca: ok, here it comes23:51
Chipacazyga: also, it's 2am for you (again)23:51
zygahttps://github.com/snapcore/snapd/pull/329523:52
mupPR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>23:52
zygamore red than green :D23:52
mupPR snapd#3295 opened: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>23:52
newbsieis the username@host after the ssh-rsa <key> needed?23:52
zygaah, wait, new interfaces are public23:52
Chipacanewbsie: it's the key name or something like that23:53
Chipacanewbsie: i've always copied it23:53
Chipacanot sure if it's needed23:53
Chipacazyga: does that mean i should hold off reviewing?23:54
zygaChipaca: pushed again23:54
zygajust one interface23:54
zygaChipaca: go ahead now23:54
Chipacayouch23:54
Chipaca+831 −1,16523:54
zygahahaha23:54
zygayes23:54
zygabut the fact that interfaces are private now makes test easier to verify23:55
zygathey can only observe what is public, and they must ask for an interface, by name, from the registry23:55
zygaChipaca: honestly I don't expect you to really review this today :)23:55
Chipacayeah, i'd not trust it to fit in my brain at this time23:56
Chipacaif it were more mechanical, sure23:56
Chipacabut it's not23:56
zygait's very boring23:56
zygathere are a few interesting spikes23:56
zygabut it is for tomorrow23:56
zygaI think spread will be busy for now23:56
zygaI'll just merge master into broken branches23:56
Chipacanewbsie: i'm checking out, but i don't want to leave you hanging23:57
Chipacanewbsie: so, um, i'll stay logged in here until i'm back from brushing my teeth?23:57
Chipacashout if you need me :-)23:57
Chipaca(otherwise i'll assume everything worked and you're off to the races)23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!