[03:02] <mup> PR snapd#2970 opened: Add support for retrieving snap history from API <Created by justincan> <https://github.com/snapcore/snapd/pull/2970>
[04:01] <mup> PR snapcraft#1165 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1165>
[04:01] <mup> PR snapcraft#1167 opened: tests:install wget in the container that triggers the beta tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1167>
[07:07] <mup> PR snapd#2959 closed: data: re-add snapd.refresh.{timer,service} with weekly schedule <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2959>
[07:23] <mup> PR snapd#2971 opened: data: ship "snap.mount" service that ensures /snap is MS_SHARED <Created by mvo5> <https://github.com/snapcore/snapd/pull/2971>
[08:15] <mup> PR snapd#2972 opened: cmd/libsnap: add sc_quote_string <Created by zyga> <https://github.com/snapcore/snapd/pull/2972>
[08:57] <mup> PR snapd#2973 opened: cmd/snap-confine: use sc_do_mount everywhere <Created by zyga> <https://github.com/snapcore/snapd/pull/2973>
[09:21] <mup> PR snapcraft#1168 opened: Add support for 7-zip sources <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1168>
[10:02] <pshod> installedsnappy ubuntu for pi3
[10:02] <pshod> able to ssh into it with my sso login
[10:02] <pshod> how do i install my snaps developed at host
[10:02] <pshod> ?
[10:07] <mup> Bug #1669329 opened: "error: cannot install snap has changes in progress" should exit >1 <Snappy:New> <https://launchpad.net/bugs/1669329>
[10:14] <ogra_> pshod, snap install ...
[10:16] <pshod> i would also want to develop for the pi3
[10:16] <pshod> can i scp my snap into the pi?
[10:18] <ogra_> well, unless your snap only contains shell scripts you probably want to build on the pi to get the binaries built for the armhf architecture
[10:18] <ogra_> you can easily set up a classic development environment on the pi:
[10:18] <ogra_> snap install classic --devmode --edge
[10:18] <ogra_> sudo classic
[10:18] <pshod> i want to build for the pi arch so either i will have to develop on board or using alaunchpad project
[10:19] <ogra_> then ... in the classic shell ... sudo apt update and you are good to go ... it behaves like any other ubuntu in there
[10:19] <pshod> building on board sounds better
[10:19] <pshod> why whould i sudo apt update?
[10:19] <ogra_> to exit the classic shell you can just hit ctrl-d (or type exit) ... to enter it again just run "sudo classic" again
[10:20] <pshod> if release my snap onto edge or beta
[10:20] <pshod> then i can use only snap install
[10:20] <ogra_> the classic shel gives you a deb based system ... you can apt install snapcraft to build snaps
[10:20] <pshod> yes yes
[10:20] <ogra_> the shell shares the same home dir with the outside snap system
[10:21] <pshod> doesnt that bring in security vulnerablities?
[10:21] <ogra_> so once you built your snap inside the classic shell, you exit it and run snap install /path/to/your.snap to install it
[10:21] <ogra_> only if you give people full access to the board :)
[10:22] <pshod> if i develop there then I wont have to publish my snap too
[10:22] <pshod> hmmmm
[10:22] <pshod> i can always remove the classic env
[10:22] <pshod> right?
[10:22] <ogra_> (teh classic shell cant run system daemons (well, it can if you manually start them for dev. purposes, but they wont auto-start))
[10:22] <ogra_> just snap remove classic and it is all gone
[10:22] <pshod> before sending it to production i would do that then
[10:23] <pshod> ogra: remember _prasen_?
[10:23] <pshod> i guess that is the user name i was using
[10:23] <ogra_> if it is a larger project launchpad is surely better for building and all ... but for quick iteration and development on the board the classic shell is the best option
[10:23] <ogra_> yup, i do :)
[10:23] <pshod> trying to run core on a vm
[10:23] <pshod> well I have got the pi now
[10:23] <pshod> :D
[10:24] <pshod> hey!
[10:24] <pshod> hell everything is better outside the office
[10:24] <pshod> took the pi home yesterday
[10:24] <pshod> was able to do some stuff
[10:24] <pshod> brought it back
[10:25] <pshod> network proxy and lack of hdmi monitor
[10:25] <pshod> :'(
[10:26] <ogra_> sad
[10:30] <pshod> yes
[10:56] <Rumple> I have a package stuck on 'Manual review pending', and can't push a new version - which would fix the review issue. The same issue as in https://bugs.launchpad.net/snapcraft/+bug/1632136
[10:56] <mup> Bug #1632136: Releasing a new snap is blocked by a previous uploading pending manual review <store> <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1632136>
[11:06] <Rumple> Can the 'Manual review pending' revision be removed? The package is fancon
[11:30] <mup> PR snapd#2954 closed: overlord: phase 2 with 2nd setup-profiles and hook done after restart for core installation <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2954>
[11:31] <mup> PR snapd#2974 opened: many: add new (hidden) `snap debug ensure-state-soon` command and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2974>
[11:57] <mup> PR snapd#2975 opened: overlord/snapstate: small cleanup of ensureForceDevmodeDropsDevmodeFromState <Created by chipaca> <https://github.com/snapcore/snapd/pull/2975>
[13:09] <gbisson_> hi all, what's the latest stable core version/rev of snappy?
[13:09] <gbisson_> I built an image for my platform (i.MX6Q) and get core     16-2     1292  canonical  -
[13:10] <gbisson> however when I look at RPi3 I get: core        16-2          1267  canonical  -
[13:10] <gbisson> (even after a snap refresh)
[13:10] <gbisson> why aren't the two revisions aligned?
[13:11] <ogra_> gbisson, run snap info core on both of them ;)
[13:12] <ogra_> i assume you use different channels (unless they are actually different arches ... i.e. arm64 vs armhf)
[13:13] <gbisson> ogra_: thanks yes my boards tracks beta...
[13:14] <ogra_> i'd use edge while doing development
[13:14] <gbisson> whereas rpi follows stable which makes sense
[13:14] <gbisson> ogra_: thanks for the quick reply
[13:14] <ogra_> (it rarely breaks)
[13:14] <gbisson> well the problem I have with beta it that I can't install snapwbe
[13:14] <gbisson> snapweb
[13:14] <ogra_> oh ?
[13:14] <ogra_> whats the error ?
[13:14] <gbisson> error: cannot install "snapweb": snap "snapweb" has changes in progress
[13:15] <gbisson> so I'd rather stick to the stable version ;)
[13:15] <ogra_> and snap changes ? what does it tell ??
[13:15] <ogra_> (you can see details with "snap change $changenumber")
[13:16] <gbisson> http://pastebin.com/TqkCk936
[13:16] <gbisson> nothing about snapweb I think
[13:16] <ogra_> Error   2017-03-01T17:39:40Z  2017-03-01T17:39:49Z  Install "webdm" snap
[13:16] <gbisson> then I tried webdm
[13:16] <gbisson> but it's not the same right?
[13:16] <ogra_> no, indeed
[13:16] <gbisson> I have to say webdm/snapweb is confusing
[13:16] <ogra_> webdm was the old name of snapweb
[13:17] <gbisson> depending on the website you read it's either one or the other that is mentioned
[13:17] <gbisson> how can I clear the snap changes ?
[13:17] <ogra_> well, old docs might still mention webdm
[13:17] <gbisson> how can I switch to stable channel for core?
[13:17] <ogra_> sure
[13:17] <ogra_> snap refresh core --stable
[13:18] <gbisson> error: cannot refresh "core": snap "core" has changes in progress
[13:18] <gbisson> I'm cursed
[13:19] <gbisson> 1    Doing   2017-03-01T17:06:27Z  -                     Initialize system state
[13:19] <gbisson> isn't this stuck somehow?
[13:19] <ogra_> looks like
[13:20] <ogra_> how did you create that image ... looks like there are issues with it
[13:20] <gbisson> yes I'll check that process, thanks for the precious feedback
[13:20] <ogra_> not properly signed assertion, broken gadget or some such
[13:20] <gbisson> yes it's weird cause I don't see my kernel snap
[13:20] <ogra_> yeah, that definitely means it wasnt properly initialized
[13:21] <gbisson> yep, I'll let you know, thanks!
[13:21] <ogra_> core, kernel and gadget should always be there before you do anything
[13:21] <ogra_> else it would install a core ... rthats definitely worng
[14:32] <jdstrand> mvo: thanks for reviewing and merging my branches yesterday :)
[14:57] <mup> PR snapd#2714 closed: interfaces: interface to allow autopilot introspection <Created by sbaldassin> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2714>
[15:24] <mterry> didrocks: looks like in snapd trunk, the content: field for content interfaces is now mandatory -- so that bit of doc in snapcraft-desktop-helpers might need updating to include it
[15:25] <didrocks> mterry: hum, is that an error? on the spec it's told that content is implicitely plugname is not named
[15:26] <didrocks> unsure if zyga is around ^
[15:26] <didrocks> if so, it's a regression compared to previous behavior
[15:30] <mterry> agreed it's a regression compared to before
[15:30] <mup> PR snapd#2969 opened: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
[15:30] <mterry> But spec is correct for latest stable release at least
[15:30] <mterry> Just won't be soon
[15:31] <didrocks> mterry: mind opening a bug? :)
[15:31] <didrocks> should be high/critical before release
[15:31] <didrocks> mvo: ^
[15:31] <didrocks> let's avoid that regression
[15:32] <jdstrand> morphis: hey, fyi https://github.com/snapcore/snapd/pull/2969. This is the PR I was talking about last week
[15:32] <mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
[15:32] <morphis> jdstrand: oh nice
[15:33] <mterry> didrocks: https://bugs.launchpad.net/snappy/+bug/1669476
[15:33] <mup> Bug #1669476: content: piece of content interfaces now mandatory in trunk <Snappy:New> <https://launchpad.net/bugs/1669476>
[15:33] <mup> Bug #1669476 opened: content: piece of content interfaces now mandatory in trunk <Snappy:New> <https://launchpad.net/bugs/1669476>
[15:35] <didrocks> mterry: commented, thanks! I hope mvo is going to have a look at it
[15:36] <mup> Bug #1669477 opened: Snap installed as devmode can end up running confined <Snappy:New> <https://launchpad.net/bugs/1669477>
[15:38] <morphis> jdstrand: btw. I am going to hook up our CI soon so it runs nightly against edge for the core snap so that we spot problems early on
[15:46] <pedronis> didrocks: which spec?
[15:56] <jdstrand> morphis: that sounds great :)
[16:02] <mup> PR snapd#2967 closed: tests: remove workaround for docker again, snap-declaration is fixed now <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2967>
[16:30] <amosbird> hi
[16:31] <amosbird> does snap support centos 6?
[16:33] <ogra_> amosbird, https://github.com/snapcore/snapd/wiki/Distributions
[16:34] <amosbird> hmm
[16:36] <mvo> didrocks: looking now
[16:36] <mvo> didrocks: I will look over the code, I don't remember reviewing that
[16:38] <didrocks> mvo: thanks!
[17:43] <cvldrg> Hi, would anyone help me to install wget or curl with snao ?
[18:03] <joc> elopio: hi, do you think the plainbox-provider plugin PR will be ok to go in next snapcraft release?
[18:06] <elopio> joc: oh, I hope so. I'm seeing that the test error is not related to your change. I'll hit update to get a fresh run.
[18:07] <joc> elopio: great, thank you
[18:10] <jdstrand> tyhicks: hey, wondering if you would have time to review the description and my comments in this PR: https://github.com/snapcore/snapd/pull/2969 (ie, don't need a code review yet (unless you want to), just verify the approach and advise on my comment)
[18:10] <mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
[18:10] <mup> PR # closed: snapd#2230, snapd#2302, snapd#2592, snapd#2624, snapd#2644, snapd#2749, snapd#2752, snapd#2782, snapd#2787, snapd#2793, snapd#2837, snapd#2855, snapd#2869, snapd#2877, snapd#2895, snapd#2929, snapd#2930, snapd#2932, snapd#2938, snapd#2941, snapd#2942, snapd#2944, snapd#2947,
[18:10] <mup> snapd#2950, snapd#2951, snapd#2952, snapd#2953, snapd#2963, snapd#2969, snapd#2970, snapd#2971, snapd#2972, snapd#2973, snapd#2974, snapd#2975
[18:10] <genii> Whoa
[18:10] <jdstrand> tyhicks: if now isn't convenient, I have other things I can work on
[18:11] <mup> PR # opened: snapd#2230, snapd#2302, snapd#2592, snapd#2624, snapd#2644, snapd#2749, snapd#2752, snapd#2782, snapd#2787, snapd#2793, snapd#2837, snapd#2855, snapd#2869, snapd#2877, snapd#2895, snapd#2929, snapd#2930, snapd#2932, snapd#2938, snapd#2941, snapd#2942, snapd#2944, snapd#2947,
[18:11] <mup> snapd#2950, snapd#2951, snapd#2952, snapd#2953, snapd#2963, snapd#2969, snapd#2970, snapd#2971, snapd#2972, snapd#2973, snapd#2974, snapd#2975
[18:18] <tyhicks> jdstrand: how come you were thinking that netlink_sendmsg() doesn't call out to the LSM in some situations?
[18:18] <mup> PR snapd#2977 opened: releasing package snapd version 2.23 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2977>
[18:18] <tyhicks> I quickly walked through netlink_sendmsg() but don't see any short circuits for the root user
[18:19] <tyhicks> jdstrand: oh, I think I see it now
[18:19]  * tyhicks reads
[18:20] <jdstrand> tyhicks: early in the function. search for -EPERM
[18:21] <tyhicks> jdstrand: that's equiv to DAC being applied before MAC (the only time the LSM isn't called is when the user doesn't have CAP_NET_ADMIN and the sendmsg() fails)
[18:22] <jdstrand> tyhicks: yes
[18:22] <tyhicks> jdstrand: ah! I thought you were saying that LSM is bypassed in some non-error conditions
[18:22] <tyhicks> I misunderstood
[18:23] <jdstrand> tyhicks: no. I was only saying that I observed socket(AF_NETLINK, ..., NETLINK_ROUTE) as root did not go through the lsm
[18:23] <tyhicks> ok
[18:23] <tyhicks> I need to go back and read the first comment in the PR
[18:24] <tyhicks> there looks to be a good amount to digest so it'll take me a little bit
[18:24] <jdstrand> tyhicks: because if I remove 'socket AF_NETLINK - NETLINK_ROUTE', I get a seccomp denial. if I add it, I get no apparmor denial for a lack of 'network netlink ...,' rule
[18:33] <tyhicks> jdstrand: ok, I'm still missing some context on why you think the netlink-audit and netlink-connector "escape hatches" are needed
[18:36] <tyhicks> I can say that NETLINK_AUDIT will be needed by any trusted helpers that audit through the audit subsystem (dbus-daemon is an example)
[18:37] <jdstrand> tyhicks: currently, NETLINK_AUDIT is only in account-control. I did a rdepends on libaudit1 and there was enough there that made me feel like a 3rd party app may try to use it
[18:38] <jdstrand> tyhicks: and we wouldn't want something that simply uses 'python-audit' to be able to create user accounts
[18:38] <tyhicks> jdstrand: ok, I understand the desire for netlink-audit
[18:39] <tyhicks> jdstrand: you didn't justify netlink-connector very much
[18:39] <tyhicks> jdstrand: it has been years since I looked at NETLINK_CONNECTOR but I don't remember anything using it
[18:40] <jdstrand> tyhicks: NETLINK_CONNECTOR isn't used in any of the policy, but I saw it in a few places on codesearch
[18:40] <jdstrand> lvm2, ulatencyd, ruby-god, powerstat and v86d
[18:41] <jdstrand> and stress-ng
[18:42] <tyhicks> jdstrand: ok, that makes some sense but note that we won't be able to mediate individual NETLINK_CONNECTOR users
[18:42] <jdstrand> tyhicks: my concern is that we had a bare socket rule before and that all accesses aren't going through the lsm. I was hoping every AF_NETLINK would need a corresponding 'network netlink <type>' rule, but at least with NETLINK_ROUTE, that isn't the case
[18:42] <tyhicks> jdstrand: from what I remember, it is just a common transport mechanism and anything that we can NETLINK_CONNECTOR access to will be able to set up a side channel
[18:43] <tyhicks> s/that we can/that we grant/
[18:43] <jdstrand> tyhicks: right, which is why I thought a separate interface that requires manual connection would be good
[18:43] <jdstrand> same with audit
[18:43] <mup> PR snapcraft#1169 opened: tests: update the ftp source for integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1169>
[18:43] <tyhicks> well, not quite the same
[18:44] <tyhicks> I think the routing for NETLINK_CONNECTOR is done based on the addr.nl_groups value
[18:44] <jdstrand> tyhicks: because we are now mediating all socket(AF_NETLINK, ...) socket calls, I wanted to make sure people had a way to do what they could do before
[18:44] <jdstrand> tyhicks: all I meant by same was the base declaration requires manual connection
[18:45] <tyhicks> ah, gotcha
[18:47] <jdstrand> tyhicks: is that a +1 on netlink-audit and netlink-connector?
[18:48] <tyhicks> jdstrand: still confused about one thing... the java server that hit the NETLINK_ROUTE seccomp denial worked fine after you added the seccomp rule even thought you didn't add an apparmor rule?
[18:48] <jdstrand> tyhicks: that is precisely correct, which was puzzling. I did not chase down why
[18:50] <tyhicks> jdstrand: ok, +1 on both (I'll leave a comment) but I'm going to spend a little bit of time looking at the NETLINK_ROUTE code path
[18:54] <jdstrand> tyhicks: ok, thanks (on both)
[20:28] <lazyPower> mvo is my new hero. Holy cow the response time on http://pad.lv/1668659 is intense. Just wanted to stop by and say thanks for all the help both in here and on the bug everyone.
[21:20] <jhodapp> Is there a standard place that I should put a custom wrapper script in for an app for my snap's source tree?
[21:21] <kyrofa> jhodapp, nope, it's completely your playground!
[21:21] <kyrofa> jdstrand, I typically just put stuff like that in a bin/ dir in the root of the snap
[21:21] <jhodapp> kyrofa, so putting it in snap/ is not bad? I heard that snap/ is starting to become standard directory for other things
[21:21] <kyrofa> jdstrand, sorry, I meant jhodapp
[21:21] <jhodapp> it's ok, that happens to jdstrand and me all the time :)
[21:22] <kyrofa> jhodapp, I'm just so used to typing his nick! :P
[21:22] <kyrofa> jhodapp, anyway, you're right-- snap is actually not the best place
[21:22] <kyrofa> jhodapp, snapcraft likes to own that dir
[21:22] <jhodapp> ok, I saw another snap use it and I copied that...so I'll make sure to move away from that
[21:22] <jhodapp> thanks kyrofa
[21:22] <kyrofa> jhodapp, so you're not asking about where it should be the _final_ snap so much as asking for recommendations about how to organize your source tree?
[21:23] <jhodapp> kyrofa, yes exactly
[21:23] <kyrofa> jhodapp, I typically make a src/ directory, with a subdirectory for each part
[21:23] <jhodapp> kyrofa, hmm interesting
[21:24] <jhodapp> kyrofa, this might be something to start recommending...maybe a blog post or whatnot
[21:25] <kyrofa> jhodapp, yeah, perhaps elopio and I could put together a weekly "tips and tricks" post of some kind
[21:26] <jhodapp> kyrofa, would love that...snaps are so powerful with so much choice...knowing best practices would be *very* helpful
[21:26] <jhodapp> kyrofa, to take off of Effective C++, could be an Effective Snapping series
[21:26] <kyrofa> Ah, my favorite book
[21:26] <jhodapp> mine too :)
[21:27] <kyrofa> jhodapp, you and I need to meet sometime ;)
[21:27] <jhodapp> haha, cheers
[21:27] <kyrofa> Hmm. That came off creepier than I anticipated
[21:27] <jhodapp> no I got your gist ;)
[21:27] <jhodapp> no worries
[21:27] <kyrofa> Hahaha
[21:27] <kyrofa> elopio, how do you feel about something along those lines? ^^
[21:39] <jdstrand> mwhudson: fyi, I approved your snap, but you need to release it still
[21:39] <mwhudson> jdstrand: thanks
[22:03] <mwhudson> huh snap install core in my lxd container downloads 5 megs really quickly then fails
[22:03] <mwhudson> outside the container it is much slower but appears to be working?
[22:04] <mwhudson> oh no, snap download core in the container is slow and working too
[22:08] <mwhudson> hm if i've run snap download, how do i make snapd see the assertions file?
[22:09] <kyrofa> mwhudson, snap ack
[22:09] <kyrofa> mwhudson, then you can just `snap install` without --dangerous
[22:10] <mwhudson> kyrofa: oh of course
[22:11] <mwhudson> mount: wrong fs type, bad option, bad superblock on /var/lib/snapd/snaps/core_1395.snap,
[22:11] <mwhudson> eh what
[22:11] <kyrofa> mwhudson, do you have squashfuse?
[22:11] <mwhudson> yes
[22:11] <kyrofa> mwhudson, you've reached the limit of my expertise :P
[22:12] <kyrofa> (I've not tried this before)
[22:13] <mwhudson> i'm trying to reproduce that thing where classic snap builds on !amd64 don't work
[22:15] <mwhudson> "interpreter /snap/core/current/i386-linux-gnu/ld-2.23.so"
[22:15] <mwhudson> that path looks pretty unlikely
[22:15] <mwhudson> it's missing a /lib
[22:17] <mwhudson> because someone didn't understand how symlink resolution works??
[22:18] <kyrofa> Hmm... it actually looks like i386 is missing the core-dynamic-linker field all-together
[22:21] <kyrofa> So it does a readlink on /snap/core/current/lib/ld-linux.so.2 and appends that to /snap/core/current
[22:22] <kyrofa> Which of course won't work if the link is relative
[22:22] <kyrofa> mwhudson, is that what you're talking about?
[22:25] <mwhudson> kyrofa: yes
[22:26] <kyrofa> Yeah, it should make that link relative to the core path before appending back onto it
[22:30] <mwhudson> uh i hope /lib/ld-linux.so.2 is always a symlink
[22:31] <kyrofa> Indeed
[22:43] <mwhudson> oh readlink raises if it's not a symlink
[22:44] <mwhudson> that's at least confusing than if it just returned its argument
[22:44] <mwhudson> *less confusing
[22:59] <elopio> kyrofa: +1. Like a short post of a couple of paragraphs? Or like a tutorial to snap something from 0, including an interesting detail?
[23:00] <kyrofa> elopio, I was thinking something relatively short and sweet. The Effective Snapping idea was excellent
[23:01] <mwhudson> https://github.com/snapcore/snapcraft/pull/1170
[23:01] <mup> PR snapcraft#1170: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170>
[23:02] <mup> PR snapcraft#1170 opened: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170>
[23:02] <kyrofa> Thanks for that mwhudson
[23:02] <mwhudson> after the amount of time i spent figuring out what was going on, the least i can do is save anyone else from the pain
[23:03] <mwhudson> now can i have the fix on launchpad pls? :)