[03:37] PR snapd#4508 opened: New spread test for hardware-random-observe interface === jkridner|pd is now known as jkridner_ [06:35] morning [06:42] hey mborzecki - good morning [06:49] PR snapd#4480 closed: snap-mgmt: extend spread tests, stop, disable and cleanup snap services [06:49] mvo: watchdog notify is a bit of a hassle, i got the apparmor rule for /run/systemd/notify (the path is hardcoded) then figured i could use systemd-notify from the shell script to avoid making a heavier snap, turns out we may need to tweak NotifyAccess for this to work [06:53] mborzecki: what does notifyacess do? [06:55] mvo: https://www.freedesktop.org/software/systemd/man/systemd.service.html#NotifyAccess= aiui it selects who, from the spawned process group, can send notifications to systemd (or rather whose notifications will be accepted) [06:57] mborzecki: interssting - and slightly strange because we use type=notify in snapd but we do not set notifyaccess [06:57] mvo: it defaults to main, so the main rpocess can send notifications [06:58] mborzecki: aha, indeed. sounds like we need to support it for the poor souls who need != main then [06:58] right [06:59] i'm thinking, cause using systemd-notify is actually a legitimate case (found some java library that does exactly that), so the apparmor template would need to allow `/bin/systemd-notify ixr` and `/run/systemd/notify w` [06:59] and NotifyAccess on top :/ [07:00] yeah, worthwhile to talk to jdstrand if we need a special interface for this [07:02] mvo: also thought that the service will run under the same systemd as snapd does, so we could take NOTIFY_SOCKET from our env and adjust apparmor rule dynamically [07:06] mborzecki: that is a nice idea! [07:07] mborzecki: because I'm concerned that we can't hardcode this [07:31] mvo, mborzecki: it's been in our queue to look at an interface for this. Chipaca and I discussed it a while ago (around the time of the comments in the forum) [07:31] mvo, mborzecki: it is behind quite a few things at this point though [07:33] mvo: what is the priority of this work relative to layouts, portals, userd/xdg-settings and priv dropping? [07:34] note: there are other snappy items that are higher priority atm too [07:34] jdstrand: i can try and propse and interface [07:34] well, developing the interface isn't necessarily the issue, it is the investigation on its safety [07:36] and that kinda needs to happen beforehand. honestly, idr all the details for why this is needed atm since this was from afew months ago [07:36] mborzecki: what is requiring it? [07:36] jdstrand: i have a PR #4505 that implements WatchdogSec= in service spec [07:36] PR #4505: interfaces/mount,snap: early support for snap layouts [07:36] w8, bad number [07:37] #4504 [07:37] PR #4504: snap, wrappers: systemd WatchdogSec support [07:39] mborzecki: I'm going to infer a couple things from that pr. please correct as needed cause, as mentioned, I've not done any investigation and haven't used watchdog personally [07:39] mborzecki: so, we declare some yaml so systemd can keep an eye on a service [07:40] mborzecki: that service then needs some sort of security policy to receive sd_notify events? [07:41] no that isn't quite right [07:41] jdstrand: yes, it needs to sendmsg on $NOTIFY_SOCKET (set by systemd), which is /run/systemd/notify atm [07:41] it is starting to come back [07:41] https://www.freedesktop.org/software/systemd/man/sd_notify.html [07:42] right, systemd doesn't poll, the service pushes via sd_notify() [07:42] mborzecki: iwhat is $NOTIFY_SOCKET? [07:42] like, name based file, abstract socket, anonymous socket, ...? [07:43] it's the path to the notification socket, it's set by systemd in service'env when running the service [07:49] mborzecki: ok, I'm now caught up with what I was concerned about [07:49] mborzecki: so, it appears (again, inferring here), that systemd will set NOTIFY_SOCKET per service (fine) [07:50] willcooke you around? [07:50] mborzecki: but what is the *actual* value of NOTIFY_SOCKET? I suspect that it is not namespaced wrt to the snap. eg, maybe it is a random string, etc [07:50] jdstrand: it's /run/systemd/notify [07:51] mborzecki: ok, so if we give all snaps (or an interface) access to that, what would prevent one snap from reporting events for another snap? [07:52] mborzecki: ie, what isolation guarantees are in place in systemd? if it is system's design and implementation that this is secure and you can't spoof notifications, then we could just allow it, and accesses violating that just become security bug that would get a CVE [07:52] jdstrand: from what i see, systemd will look at ancilliary data and figure out a pid of the sender, then depending on the NotifyAccess= setting in service files, either all processes in process group of the service can send the nofication or jsut the main process [07:53] mborzecki: but if there are no guarnatees, then we have to decide what to do [07:53] jdstrand: i.e.even if you send MAINPID= and that other-service is not part of your pg systemd will reject the notification [07:53] mborzecki: if that were true, and the enforcement was real, then it would be fine to allow by default [07:55] mborzecki: but now we are where I was a few months ago-- need to look at that. if you want to do that investigation and provide details on your findings, that might help move things along [07:56] mborzecki: for the moment it sounds like it is safe, but that needs to be verified. assuming for a moment it is safe, then it might make sense to only add the access to the socket *if* the watchdog yaml is present [07:57] mborzecki: today, we don't really have a way to do that (a sort of implied interface). it could be a separate sd notify interface, but it feels weird to way you want watchdog *and* you need to declare an interface for it to work [07:58] mborzecki: ie, snapd already has all it needs to with either [07:58] mborzecki: actually, could look at it the other way. create a watchdog interface, and plugging that is what adds the bit to the service definition [07:58] (just food for thought) [07:59] jdstrand: right, a separate 'watchdog' or 'software-watchdog' interface sounds right [08:00] we came across this type of thing with the dbus service discussions, which I think was before you starting focusing on snappy. I mention that only because the idea of declaring in one place something that affects service and interfaces is useful to more than just this [08:01] jdstrand: now the second part, with spread test https://github.com/snapcore/snapd/commit/9ec6594c4d53d4b548e964e7d66ea4ba68dea89e i also need to allow ixr on systemd-notify, that why using a separate interface would make more sense [08:01] mborzecki: what is a little weird about declaring it in 'plugs' is that 'plugs' can be toplevel, and therefore apply to the whole snap. I guess if you did that, you would simply apply watchdog to all services (so not really that weird after all) [08:02] jdstrand: systemd-notify is just a helper that does the notification thing on behalf of the caller [08:02] * jdstrand nods [08:03] 'Note that systemd will refuse reception of status updates from this command unless NotifyAccess= is set for the service unit this command is called from.' [08:03] that is consisent with what you said earlier [08:03] consistent* [08:03] good morning [08:03] hey zyga-ubuntu [08:03] jdstrand: i had to set NotifyAccess=all to get it to work [08:03] zyga-ubuntu: morning [08:04] * zyga-ubuntu catches up on backlog [08:06] mborzecki: hmm. the man page says that 'systemd-notify will first attempt to invoke sd_notify() pretending to have the PID of the invoking process. This will only succeed when invoked with sufficient privileges.' [08:07] daemons run as root, so we probably have sufficient privileges to use sd_pid_notify() for anything [08:08] so my plan was to pore through the man pages for sd_notify and sd-notify, then go through the code and see what could be attacked by a malicious root user with access to the socket [08:09] I feel that is still needed after reminding myself of sd_pid_notify. again, if you'd like to provide that investigation,I can take a look and that might make things go faster. if not, need mvo's input on relative priority for me to look at this [08:10] if we can't come up with something reasonable there, we can raise this up to ratliff to see if someone else could look at it. the timing of meltdown/spectre makes that problematic though [08:11] jdstrand: ok, let's do this, i'll label #4504 as blocked for now and propose an separate PR with software-watchdog interface, then once the security check is complete the code will be there already [08:11] PR #4504: snap, wrappers: systemd WatchdogSec support [08:12] jdstrand: we can start simple by just allowing write on /run/systemd/notify [08:12] ok. I'll futz our board to bubble this up a little higher, but it is still behind quite a few things [08:12] well [08:12] sd-notify is just a wrapper around sd_notify() and friends [08:13] if the socket api allows specifying arbitrary pids, that (may) mean that the root daemon could spoof notify events [08:14] for the interface to go through, we'd need to understand that to set the auto-connection policy accordingly [08:15] jdstrand: i'm looking at systemd code right now, the itneresting bits are https://github.com/systemd/systemd/blob/07fbf8807c7555981c9449151bdc51ba867cde1e/src/core/service.c#L3375 and https://github.com/systemd/systemd/blob/07fbf8807c7555981c9449151bdc51ba867cde1e/src/core/manager.c#L1992 [08:15] spineau: o/ [08:15] mborzecki: looking at my notes from before, it looks like I was strongly leaning for the socket (and sd-notify) to be in a separate interface [08:16] so that is consistent with what we came up with here [08:16] right [08:17] note I'm at a sprint atm and note able to provide the focus needed for this [08:17] not* [08:17] I've grabbed those urls and put them in the card (where my notes are) [08:17] jdstrand: sure, thanks for your input anyway :) [08:17] i'm marking 4504 as blocked and will leave a note there [08:18] mborzecki: ok. if this is problematic or needs to be reprioritized, ping me again and we can pull in mvo and ratliff and decide on a path forward [08:18] * kalikiana sliff [08:18] kalikiana: hey [08:18] kalikiana: you didn't write that spec for me last night [08:19] * jdstrand puts entire conversation into trello [08:19] kalikiana: I'd love to help you with that regexp [08:19] jdstrand: sure, thanks [08:19] mornings! [08:19] hey pawel [08:20] morning zyga-ubuntu [08:21] zyga-ubuntu: what kind of spec do you imagine? this is in the context of snapcraft#1800 [08:21] PR snapcraft#1800: grammar: on..to statement [08:21] kalikiana: yes, that one [08:21] did you get it to work in the end? [08:22] I can still help you write the regular expression [08:22] zyga-ubuntu: nope. I pushed it because the code refactoring is done, but there's still a test failure due to the regex [08:23] k, let me look at what it's supposed to do by reading some of the PR log and iterate on my small regexp here === daniel is now known as Guest8611 === Guest8611 is now known as Odd_Bloke [08:34] kalikiana: ok [08:35] https://pastebin.ubuntu.com/26415334/ [08:35] and obviously I pasted the older version [08:35] https://pastebin.ubuntu.com/26415337/ [08:36] kalikiana: so what else do we need here? [08:43] kalikiana: https://pastebin.ubuntu.com/26415372/ [08:43] kalikiana: how am I doing? [08:44] zyga-ubuntu: this `on amd64, ubuntu` should parse as "amd64, ubuntu" despite the space [08:44] zyga-ubuntu: oh, I think you just did that one [08:44] what is ubuntu, the os name? [08:44] I didn't see that in the spec [08:44] wait no [08:45] zyga-ubuntu: No. It's a test string. The grammar doesn't care what the value is, as long as it is a string [08:45] it could be `on i386, amd64` or `on spams, eggs` [08:46] https://pastebin.ubuntu.com/26415382/ [08:46] try this [08:47] https://pastebin.ubuntu.com/26415383/ improved comments [08:47] hey koza [08:47] koza: white easter coming ;) [08:48] zyga-ubuntu: how do you actually run this? just in a python console? [08:48] zyga-ubuntu, hey, yeah although I expect meltdown soon ;-) [08:48] kalikiana: in ipython3 [08:48] koza: ha ha [08:49] kalikiana: it's very good at iteration as the history and editing is superb [08:49] zyga-ubuntu: erm. let me try to be clear on what those things are. `on foo,bar,spam,eggs` can be a very long list of arbitrary things. there's not going to be a "host os" or anything like it [08:49] ah, ok [08:49] sorry ;) [08:49] just a moment [08:50] zyga-ubuntu: no worries, I should've pointed this out properly [08:50] zyga-ubuntu: note "on foo" also works, no list at all [08:51] so there's no split for architecture and os? [08:51] https://pastebin.ubuntu.com/26415395/ [08:52] (this one still assumes there's a split) [08:52] without a split the code can be simpler [08:54] zyga-ubuntu: practically speaking only architectures are recognized atm. they'll be evaluated much later [08:57] zyga-ubuntu: also, this can only be "on foo" or "on foo to bar", the rest is yaml [08:57] kalikiana: https://pastebin.ubuntu.com/26415406/ [08:57] kalikiana: it matches that, just not sure what foo and bar are here [08:58] see if this makes sense in the last pastebin [08:58] zyga-ubuntu: I mean there won't be : [bla,blub] [08:58] that's handled by yaml [08:58] aha [08:58] well, cut that part out :) [08:58] I think doing this in verbose mode is much more manageable [08:58] does this help you get what you want? [09:00] zyga-ubuntu: I think so, typing it all in here to test it atm [09:02] zyga-ubuntu: NoneType has no attribute 'goupdict', and have to retype. this is tedious to do with so many lines :-P [09:02] kalikiana: no no [09:02] run ipython [09:02] go up (keyboard) [09:02] and just edit :) [09:02] don't retype this insanely [09:03] oh, didn't see the i there [09:03] ipython3 is your friend [09:03] there are even shinier versions but this is a big step up from python [09:03] check out tab completion [09:03] or foo? for docs [09:05] kalikiana: for ultimate shiny try bpython3 (b) [09:06] kalikiana: though ipython handles multiline far better [09:06] zyga-ubuntu: woot, it actually has multi-lines. this is crazy [09:06] kalikiana: bpython is crazier for UI [09:06] hmmmm still this "AttributeError: 'NoneType' object has no attribute 'groupdict'" [09:07] kalikiana: then it doesn't match [09:07] kalikiana: the problem with REs is that it's all or nothing [09:07] kalikiana: I'd say, that at the complexity you are now [09:07] kalikiana: it's better to use a parser [09:07] oh, haha, silly me, you're right [09:07] kalikiana: because then you have sensible error recovery and you can introduce syntax for errors with tailored messages [09:08] kalikiana: anything like extra commas, repeated entries, wrong order, whatever, can be parsed and just handled explicitly [09:08] kalikiana: it's a step up from REs but the results are also a lot better [09:10] zyga-ubuntu: perhaps that's the next step. introducing two expressions side by side is what's making it complex now [09:12] hmmm ipython is fun [09:13] try ?? [09:13] Object `` not found [09:14] define a function [09:14] and then type "function_name ??" [09:14] (try with ? and ??) [09:15] oh, neato [09:15] quick help [09:19] kalikiana: ping me if I can help somehow, I'll get back to snapd now [09:54] E: Failed to fetch http://mirrors.linode.com/ubuntu/pool/main/s/systemd/libpam-systemd_204-5ubuntu20.25_amd64.deb Connection failed [IP: 2600:3c01:1::607e:6379 80] [09:55] hmm [09:55] src/github.com/snapcore/snapd/advisor/backend.go:26:2: cannot find package "github.com/snapcore/bolt" in any of: [09:55] /root/rpmbuild/BUILD/snapd-1337.2.30/src/github.com/snapcore/snapd/vendor/github.com/snapcore/bolt (vendor tree) [09:55] /usr/lib/golang/src/github.com/snapcore/bolt (from $GOROOT) [09:55] /root/rpmbuild/BUILD/snapd-1337.2.30/src/github.com/snapcore/bolt (from $GOPATH) [09:55] /usr/share/gocode/src/github.com/snapcore/bolt [09:55] mvo: ^ what shall we do about bolt on fedora? [09:55] error: Bad exit status from /var/tmp/rpm-tmp.VNVcCw (%build) [09:57] * zyga-ubuntu begs for reviews of 4471 [10:09] zyga-ubuntu: yeah, this all sucks, I'm not sure what is the best way forward, let me take a walk and think about it [10:14] is it known that the maas snap dumps core on install on 16.04? [10:18] * Chipaca pastebins the configure hook output and continues [10:20] mborzecki: can you have a 2nd look at https://github.com/snapcore/snapd/pull/4505 please [10:20] PR #4505: interfaces/mount,snap: early support for snap layouts [10:20] mborzecki: it should now work ok for arch [10:20] mvo: thank you [10:20] Chipaca, mvo: can you please review/approve 4471 [10:20] I'm blocked by this [10:20] pr 4471 [10:20] PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS [10:23] mvo: I think we just have to package bolt [10:23] mvo: is it ready in debian? [10:24] zyga-ubuntu: we could carry on using regular bolt outside of ppc [10:24] probably needs some build shenanigans for ppc though :-/ [10:25] Chipaca: bolt doesn't exist for fedora now, that's a separate problem [10:25] ah, ok [10:25] i need to go out for a bit before it's too late for me to go out for a bit :-) [10:25] * Chipaca runs, leaving things ticking over [10:26] ttyl [10:26] mvo: I have a crazy plan to make layouts easier [10:27] mvo: I may do a spike around that today, [10:27] make / a tmpfs, [10:37] zyga-ubuntu: all looking very nice now on the grammar front! thank you for pulling me out of that mental swamp! [10:43] zyga-ubuntu: https://src.fedoraproject.org/rpms/golang-github-boltdb-bolt ? [10:43] PR snapd#4509 opened: interfaces/builtin: add support for software-watchdog interface [10:44] mborzecki: ah, cool so perhaps we just need to add a new dependency to packaging [10:46] kalikiana: glad to hear that! [10:56] https://github.com/snapcore/snapd/pull/4505 is green and easy to review :) [10:56] PR #4505: interfaces/mount,snap: early support for snap layouts [11:10] zyga-ubuntu: you mean we need to package bbolt? or bolt? bolt is packaged, we could patch it with our fixes [11:10] zyga-ubuntu: but that still would not solve our vendor'ed version (boltdb/bolt would still be buggy on ppc) [11:23] niemeyer: can you please re-review 4471 now [11:28] mvo, did you notice that we ship update-motd in core (seems to be pulled in by libpam-modules recommends for whatever reason) ... so https://github.com/snapcore/core/blob/master/live-build/hooks/14-set-motd.chroot only applies half and we always get the additional update-motd info [11:28] mvo, do you think we could purge update-motd during build ? [11:30] or instead put correct files to /etc/update-motd.d and forget about the /etc/motd [11:30] mvo, ogra ^^ [11:30] ogra: I was not aware of this [11:30] thanks [11:30] * kalikiana taking a break, back in a few [11:30] anyways the welcome motd seems just not right with all of the links pointing to desktop-centric resources also referencing 'Snappy Ubuntu Core' which as far as I understand is now just called Ubuntu Core [11:31] mvo ^^ [11:31] koza: +1 [11:31] mvo, it is mainly this part we should drop i think: [11:31] printf " * Documentation: https://help.ubuntu.com\n" [11:31] printf " * Management: https://landscape.canonical.com\n" [11:31] printf " * Support: https://ubuntu.com/advantage\n" [11:31] sice it points to completely generic ubuntu docs and services [11:31] or replace with Core & Stacks documentation links [11:32] well, /etc/motd already points to the snappy docs [11:32] desktop/snappy ;-) [11:32] if we move that over we should be fine [11:32] imho it should point here: https://www.ubuntu.com/core [11:33] ogra, koza I think we need a forum post with the prosoal for the update so that gustavo can weight in. but +1 for fixing the motd! [11:33] koza, well, it is supposed to tell you how to use snaps ... not how to create core :) [11:33] (i guess at least) [11:33] probably it should point to both :) [11:34] it is up to mvo and the team but I see a two worlds collide here: a) static motd from /etc/motd; b) dynamic approach via update-motd; I would suggest one or another - not mix them. I mean if /etc/motd is the choice then remove update-motd package as it runs every 10 mins stealing cycles ;-) [11:34] otherwise kill /etc/motd as it just creates confusion to where the stuff is coming from [11:34] koza: I'm in favor of the static motd, simpler this way [11:34] well [11:35] we might want to be able to abuse it for IoT status information [11:35] yeah, good point [11:35] (at least that sounds like a useful feature) [11:35] so keeping the functionality might make sense [11:35] ogra: fair enough, if that is planned in the (near) future that is fine with me [11:35] (perhaps even an interface that could allow writing such info would) [11:36] mvo, i'm only brainstorming :) nothing specific is planned ... but such a future feature sounds like a reason to keep update-motd [11:37] (instead of having to pull it in again later) [11:41] zyga-ubuntu: left some comments in 4505, also the unit tests pass on arch (none of this is really dynamic by anyway) [11:41] mborzecki: thank you, examining [11:43] Chipaca: idk if you noticed this: https://paste.ubuntu.com/26416072/ it's not failing though [12:01] mvo, https://github.com/snapcore/core/pull/76 and lets take it from here [12:01] PR core#76: hooks: update the set-motd hook to provide better motd [12:01] PR core#76 opened: hooks: update the set-motd hook to provide better motd === ogra_ is now known as ogra [12:11] mvo, asked Thibaut about what he thinks about changing motd, you are on cc [12:20] jdstrand: https://pastebin.ubuntu.com/26416195/ snapd not liking plug and slot in same snap :( [12:20] I'll have a look to see why that is [12:22] anyone recommend an IDE for go? [12:24] PR snapd#4510 opened: asserts: use Attrer in policy checks [12:26] greyback: plug and slot must have unique names [12:26] greyback: just call one x11-slot [12:26] greyback: I use sublime text [12:26] greyback: and vim [12:26] greyback: both with go-specific plugins [12:26] zyga-ubuntu: just installed sublime :) [12:27] zyga-ubuntu: my trouble is that I was trying for one app to provide the x11 slot, so that the other app can plug into it [12:27] greyback: that's ok, it's just that the string "x11" is no longer unique [12:27] you need to name the plug and the slot uniquely [12:27] both can be of type "x11" (just say interface: x11) [12:27] zyga-ubuntu: oh ok, I understand [12:28] pstolowski: do you have an URL with smaller diff [12:29] zyga-ubuntu, what do you mean? can I do that with github? [12:29] yes, something that can be reviewed more easily [12:30] zyga-ubuntu, I know how to do that in LP (set a base branch for a proposed branch), but not with github. let me see [12:34] pstolowski: I think you can ask github for a diff between any two points [12:34] zyga-ubuntu, any idea why netlink-audit interface could be denying the connection https://paste.ubuntu.com/26412541/ [12:34] zyga-ubuntu, this is executed with the interface connected https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind [12:38] [ 515.303103] audit: type=1400 audit(1516303185.355:62): apparmor="DENIED" operation="capable" profile="snap.test-snapd-netlink-audit.bind" pid=25254 comm="python3" capability=37 capname="audit_read" [12:38] this says it all [12:38] the interface doesn't grant the capability audit_read [12:39] the interface must define an apparmor rule that grants access to that capability [12:39] now [12:39] if this is sane or not, I don't know [12:44] PR core-build#25 opened: make /etc/update-motd.d writable for branding purposes [12:44] zyga-ubuntu, I'm able to do that only if my repo is the landing target [12:45] mborzecki: I hadn't noticed that (but I added those to stress test this :)) but it's interesting; what's doing the stat? [12:45] ogra: you! [12:45] mvo, https://github.com/snapcore/core-build/pull/25 is an additional one for the topic ... [12:45] PR core-build#25: make /etc/update-motd.d writable for branding purposes [12:45] ogra: you *you* you [12:45] * ogra hugs Chipaca [12:46] ogra: error: cannot perform the following tasks: [12:46] - Mount snap "packageproxy" (1) (snap is unusable due to bad permissions; contact develper) [12:46] ogra: thank you, looking [12:46] huh ? [12:46] Chipaca, any more details ? i run packageproxy on several machines without issues here [12:46] 2018/01/19 12:46:33.887323 check_snap.go:338: in snap "packageproxy": "meta/gui/icon.png" should be world-readable, and isn't: -rw------- [12:47] ogra: /ʌnˈjuːzəb(ə)l/ [12:47] ogra@acheron:~/Devel$ snap services packageproxy [12:47] Snap Service Startup Current [12:47] packageproxy approx enabled active [12:47] zyga-ubuntu: are you planning to push more patches to #4502? [12:47] PR #4502: interfaces/builtin: add support for content "source" section (v2) [12:48] Chipaca, woah [12:48] mborzecki: not [12:48] mborzecki: I'm planning a follow up with spread test but it dependson 4471 [12:48] Chipaca, thanks, will fix that (or even drop the icon, we'll see ) [12:48] zyga-ubuntu: ok [12:49] zyga-ubuntu, well the idea of that interface is to access specifically to that [12:49] cachio: netlink audit vs cap audit_read, fly this past jdstrand and it should be simple to patch [12:50] zyga-ubuntu, sure, tx [12:50] brrrrrr [12:51] jdstrand, the test for the netlink-audit interface is getting this denial of the connection https://paste.ubuntu.com/26412541/ [12:51] * kalikiana sat on the balcony with the laptop for a bit because it's sunny... but also freezing :-/ [12:51] kalikiana: at least it's sunny [12:51] kalikiana: it's ~0 but cloudy all day here [12:51] jdstrand, this is the code https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind [12:52] zyga-ubuntu: sometimes direct sun briefly lets me forget about the cold. not strong enough today it seems [12:52] my fingers were freezing last time I tried that [12:52] (but it was far warmer then) [12:54] in fairness, I'm fairly cold tolerant and massively addicted to sun, so I'm persistent :-D [12:55] * kalikiana getting a hot beverage [12:55] Chipaca, so since i "helped" you so much, mind giving a second ack on https://github.com/snapcore/core-build/pull/25 ? (trivial change) [12:55] PR core-build#25: make /etc/update-motd.d writable for branding purposes [12:57] ogra: ( ¬_¬) [12:59] ogra: I look forward to the day we can bury writable-path (this is my "Ceterum censeo Carthaginem esse delendam" from now on) [13:01] mvo: "Ceteru censeo /etc etc" [13:01] mvo, well, if someone comes up with something super bright to replace it :) [13:01] (i still dont see how ... ) [13:02] mborzecki: updated the layout PR [13:04] * zyga-ubuntu reboots [13:10] PR core-build#25 closed: make /etc/update-motd.d writable for branding purposes [13:34] * kalikiana lunch [14:03] they're having some perfromance at my daugter's school, gotta run, bbl to read more on apparmor and unix sockets [14:04] ttyl [14:06] 4505 needs a 2nd review now [14:30] re [14:44] zyga-ubuntu, updated the desc 4510 with an URL that only shows the relevant changes, minus interface hooks PR [15:01] pstolowski: thank you! [15:01] looking [15:26] pstolowski: small comments there [15:26] thanks [15:49] zyga-ubuntu, re interface-hooks, do you have any suggestion for the naming of test-snapd interface? just snapd-test maybe? [15:56] * zyga-ubuntu walk [15:56] pstolowski: I'll be back in one hour [15:56] k [15:56] pstolowski: hmm, maybe 'dummy [15:56] or fake or something appropriate [15:57] so that it is a "real" interface [15:57] just a no-op [15:57] indeed, nice idea [15:57] no-op [16:00]