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