mupPR snapd#4508 opened: New spread test for hardware-random-observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4508>03:37
=== jkridner|pd is now known as jkridner_
mvohey mborzecki - good morning06:42
mupPR snapd#4480 closed: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4480>06:49
mborzeckimvo: 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 work06:49
mvomborzecki: what does notifyacess do?06:53
mborzeckimvo: 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:55
mvomborzecki: interssting - and slightly strange because we use type=notify in snapd but we do not set notifyaccess06:57
mborzeckimvo: it defaults to main, so the main rpocess can send notifications06:57
mvomborzecki: aha, indeed. sounds like we need to support it for the poor souls who need != main then06:58
mborzeckii'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
mborzeckiand NotifyAccess on top :/06:59
mvoyeah, worthwhile to talk to jdstrand if we need a special interface for this07:00
mborzeckimvo: 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 dynamically07:02
mvomborzecki: that is a nice idea!07:06
mvomborzecki: because I'm concerned that we can't hardcode this07:07
jdstrandmvo, 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
jdstrandmvo, mborzecki: it is behind quite a few things at this point though07:31
jdstrandmvo: what is the priority of this work relative to layouts, portals, userd/xdg-settings and priv dropping?07:33
jdstrandnote: there are other snappy items that are higher priority atm too07:34
mborzeckijdstrand: i can try and propse and interface07:34
jdstrandwell, developing the interface isn't necessarily the issue, it is the investigation on its safety07:34
jdstrandand that kinda needs to happen beforehand. honestly, idr all the details for why this is needed atm since this was from afew months ago07:36
jdstrandmborzecki: what is requiring it?07:36
mborzeckijdstrand: i have a PR #4505 that implements WatchdogSec= in service spec07:36
mupPR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>07:36
mborzeckiw8, bad number07:36
mupPR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>07:37
jdstrandmborzecki: 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 personally07:39
jdstrandmborzecki: so, we declare some yaml so systemd can keep an eye on a service07:39
jdstrandmborzecki: that service then needs some sort of security policy to receive sd_notify events?07:40
jdstrandno that isn't quite right07:41
mborzeckijdstrand: yes, it needs to sendmsg on $NOTIFY_SOCKET (set by systemd), which is /run/systemd/notify atm07:41
jdstrandit is starting to come back07:41
jdstrandright, systemd doesn't poll, the service pushes via sd_notify()07:42
jdstrandmborzecki: iwhat is $NOTIFY_SOCKET?07:42
jdstrandlike, name based file, abstract socket, anonymous socket, ...?07:42
mborzeckiit's the path to the notification socket, it's set by systemd in service'env when running the service07:43
jdstrandmborzecki: ok, I'm now caught up with what I was concerned about07:49
jdstrandmborzecki: so, it appears (again, inferring here), that systemd will set NOTIFY_SOCKET per service (fine)07:49
sergiusenswillcooke you around?07:50
jdstrandmborzecki: 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, etc07:50
mborzeckijdstrand: it's /run/systemd/notify07:50
jdstrandmborzecki: 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:51
jdstrandmborzecki: 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 CVE07:52
mborzeckijdstrand: 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 process07:52
jdstrandmborzecki: but if there are no guarnatees, then we have to decide what to do07:53
mborzeckijdstrand: i.e.even if you send MAINPID=<other-service> and that other-service is not part of your pg systemd will reject the notification07:53
jdstrandmborzecki: if that were true, and the enforcement was real, then it would be fine to allow by default07:53
jdstrandmborzecki: 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 along07:55
jdstrandmborzecki: 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 present07:56
jdstrandmborzecki: 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 work07:57
jdstrandmborzecki: ie, snapd already has all it needs to with either07:58
jdstrandmborzecki: actually, could look at it the other way. create a watchdog interface, and plugging that is what adds the bit to the service definition07:58
jdstrand(just food for thought)07:58
mborzeckijdstrand: right, a separate 'watchdog' or 'software-watchdog' interface sounds right07:59
jdstrandwe 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 this08:00
mborzeckijdstrand: 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 sense08:01
jdstrandmborzecki: 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:01
mborzeckijdstrand: systemd-notify is just a helper that does the notification thing on behalf of the caller08:02
* jdstrand nods08:02
jdstrand'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
jdstrandthat is consisent with what you said earlier08:03
zyga-ubuntugood morning08:03
jdstrandhey zyga-ubuntu08:03
mborzeckijdstrand: i had to set NotifyAccess=all to get it to work08:03
mborzeckizyga-ubuntu: morning08:03
* zyga-ubuntu catches up on backlog08:04
jdstrandmborzecki: 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:06
jdstranddaemons run as root, so we probably have sufficient privileges to use sd_pid_notify() for anything08:07
jdstrandso 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 socket08:08
jdstrandI 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 this08:09
jdstrandif 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 though08:10
mborzeckijdstrand: 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 already08:11
mupPR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>08:11
mborzeckijdstrand: we can start simple by just allowing write on /run/systemd/notify08:12
jdstrandok. I'll futz our board to bubble this up a little higher, but it is still behind quite a few things08:12
jdstrandsd-notify is just a wrapper around sd_notify() and friends08:12
jdstrandif the socket api allows specifying arbitrary pids, that (may) mean that the root daemon could spoof notify events08:13
jdstrandfor the interface to go through, we'd need to understand that to set the auto-connection policy accordingly08:14
mborzeckijdstrand: 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#L199208:15
zyga-ubuntuspineau: o/08:15
jdstrandmborzecki: looking at my notes from before, it looks like I was strongly leaning for the socket (and sd-notify) to be in a separate interface08:15
jdstrandso that is consistent with what we came up with here08:16
jdstrandnote I'm at a sprint atm and note able to provide the focus needed for this08:17
jdstrandI've grabbed those urls and put them in the card (where my notes are)08:17
mborzeckijdstrand: sure, thanks for your input anyway :)08:17
mborzeckii'm marking 4504 as blocked and will leave a note there08:17
jdstrandmborzecki: 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 forward08:18
* kalikiana sliff08:18
zyga-ubuntukalikiana: hey08:18
zyga-ubuntukalikiana: you didn't write that spec for me last night08:18
* jdstrand puts entire conversation into trello08:19
zyga-ubuntukalikiana: I'd love to help you with that regexp08:19
mborzeckijdstrand: sure, thanks08:19
zyga-ubuntuhey pawel08:19
spineaumorning zyga-ubuntu08:20
kalikianazyga-ubuntu: what kind of spec do you imagine? this is in the context of snapcraft#180008:21
mupPR snapcraft#1800: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>08:21
zyga-ubuntukalikiana: yes, that one08:21
zyga-ubuntudid you get it to work in the end?08:21
zyga-ubuntuI can still help you write the regular expression08:22
kalikianazyga-ubuntu: nope. I pushed it because the code refactoring is done, but there's still a test failure due to the regex08:22
zyga-ubuntuk, let me look at what it's supposed to do by reading some of the PR log and iterate on my small regexp here08:23
=== daniel is now known as Guest8611
=== Guest8611 is now known as Odd_Bloke
zyga-ubuntukalikiana: ok08:34
zyga-ubuntuand obviously I pasted the older version08:35
zyga-ubuntukalikiana: so what else do we need here?08:36
zyga-ubuntukalikiana: https://pastebin.ubuntu.com/26415372/08:43
zyga-ubuntukalikiana: how am I doing?08:43
kalikianazyga-ubuntu: this `on amd64, ubuntu` should parse as "amd64, ubuntu" despite the space08:44
kalikianazyga-ubuntu: oh, I think you just did that one08:44
zyga-ubuntuwhat is ubuntu, the os name?08:44
zyga-ubuntuI didn't see that in the spec08:44
kalikianawait no08:44
kalikianazyga-ubuntu: No. It's a test string. The grammar doesn't care what the value is, as long as it is a string08:45
kalikianait could be `on i386, amd64` or `on spams, eggs`08:45
zyga-ubuntutry this08:46
zyga-ubuntuhttps://pastebin.ubuntu.com/26415383/ improved comments08:47
zyga-ubuntuhey koza08:47
zyga-ubuntukoza: white easter coming ;)08:47
kalikianazyga-ubuntu: how do you actually run this? just in a python console?08:48
kozazyga-ubuntu, hey, yeah although I expect meltdown soon ;-)08:48
zyga-ubuntukalikiana: in ipython308:48
mborzeckikoza: ha ha08:48
zyga-ubuntukalikiana: it's very good at iteration as the history and editing is superb08:49
kalikianazyga-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 it08:49
zyga-ubuntuah, ok08:49
zyga-ubuntusorry ;)08:49
zyga-ubuntujust a moment08:49
kalikianazyga-ubuntu: no worries, I should've pointed this out properly08:50
kalikianazyga-ubuntu: note "on foo" also works, no list at all08:50
zyga-ubuntuso there's no split for architecture and os?08:51
zyga-ubuntu(this one still assumes there's a split)08:52
zyga-ubuntuwithout a split the code can be simpler08:52
kalikianazyga-ubuntu: practically speaking only architectures are recognized atm. they'll be evaluated much later08:54
kalikianazyga-ubuntu: also, this can only be "on foo" or "on foo to bar", the rest is yaml08:57
zyga-ubuntukalikiana: https://pastebin.ubuntu.com/26415406/08:57
zyga-ubuntukalikiana: it matches that, just not sure what foo and bar are here08:57
zyga-ubuntusee if this makes sense in the last pastebin08:58
kalikianazyga-ubuntu: I mean there won't  be : [bla,blub]08:58
kalikianathat's handled by yaml08:58
zyga-ubuntuwell, cut that part out :)08:58
zyga-ubuntuI think doing this in verbose mode is much more manageable08:58
zyga-ubuntudoes this help you get what you want?08:58
kalikianazyga-ubuntu: I think so, typing it all in here to test it atm09:00
kalikianazyga-ubuntu: NoneType has no attribute 'goupdict', and have to retype. this is tedious to do with so many lines :-P09:02
zyga-ubuntukalikiana: no no09:02
zyga-ubunturun ipython09:02
zyga-ubuntugo up (keyboard)09:02
zyga-ubuntuand just edit :)09:02
zyga-ubuntudon't retype this insanely09:02
kalikianaoh, didn't see the i there09:03
zyga-ubuntuipython3 is your friend09:03
zyga-ubuntuthere are even shinier versions but this is a big step up from python09:03
zyga-ubuntucheck out tab completion09:03
zyga-ubuntuor foo? for docs09:03
zyga-ubuntukalikiana: for ultimate shiny try bpython3 (b)09:05
zyga-ubuntukalikiana: though ipython handles multiline far better09:06
kalikianazyga-ubuntu: woot, it actually has multi-lines. this is crazy09:06
zyga-ubuntukalikiana: bpython is crazier for UI09:06
kalikianahmmmm still this "AttributeError: 'NoneType' object has no attribute 'groupdict'"09:06
zyga-ubuntukalikiana: then it doesn't match09:07
zyga-ubuntukalikiana: the problem with REs is that it's all or nothing09:07
zyga-ubuntukalikiana: I'd say, that at the complexity you are now09:07
zyga-ubuntukalikiana: it's better to use a parser09:07
kalikianaoh, haha, silly me, you're right09:07
zyga-ubuntukalikiana: because then you have sensible error recovery and you can introduce syntax for errors with tailored messages09:07
zyga-ubuntukalikiana: anything like extra commas, repeated entries, wrong order, whatever, can be parsed and just handled explicitly09:08
zyga-ubuntukalikiana: it's a step up from REs but the results are also a lot better09:08
kalikianazyga-ubuntu: perhaps that's the next step. introducing two expressions side by side is what's making it complex now09:10
kalikianahmmm ipython is fun09:12
zyga-ubuntutry ??09:13
kalikianaObject `` not found09:13
zyga-ubuntudefine a function09:14
zyga-ubuntuand then type "function_name ??"09:14
zyga-ubuntu(try with ? and ??)09:14
kalikianaoh, neato09:15
kalikianaquick help09:15
zyga-ubuntukalikiana: ping me if I can help somehow, I'll get back to snapd now09:19
zyga-ubuntuE: 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:54
zyga-ubuntusrc/github.com/snapcore/snapd/advisor/backend.go:26:2: cannot find package "github.com/snapcore/bolt" in any of:09:55
zyga-ubuntu/root/rpmbuild/BUILD/snapd-1337.2.30/src/github.com/snapcore/snapd/vendor/github.com/snapcore/bolt (vendor tree)09:55
zyga-ubuntu/usr/lib/golang/src/github.com/snapcore/bolt (from $GOROOT)09:55
zyga-ubuntu/root/rpmbuild/BUILD/snapd-1337.2.30/src/github.com/snapcore/bolt (from $GOPATH)09:55
zyga-ubuntumvo: ^ what shall we do about bolt on fedora?09:55
zyga-ubuntuerror: Bad exit status from /var/tmp/rpm-tmp.VNVcCw (%build)09:55
* zyga-ubuntu begs for reviews of 447109:57
mvozyga-ubuntu: yeah, this all sucks, I'm not sure what is the best way forward, let me take a walk and think about it10:09
Chipacais it known that the maas snap dumps core on install on 16.04?10:14
* Chipaca pastebins the configure hook output and continues10:18
zyga-ubuntumborzecki: can you have a 2nd look at https://github.com/snapcore/snapd/pull/4505 please10:20
mupPR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>10:20
zyga-ubuntumborzecki: it should now work ok for arch10:20
zyga-ubuntumvo: thank you10:20
zyga-ubuntuChipaca, mvo: can you please review/approve 447110:20
zyga-ubuntuI'm blocked by this10:20
Chipacapr 447110:20
mupPR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>10:20
zyga-ubuntumvo: I think we just have to package bolt10:23
zyga-ubuntumvo: is it ready in debian?10:23
Chipacazyga-ubuntu: we could carry on using regular bolt outside of ppc10:24
Chipacaprobably needs some build shenanigans for ppc though :-/10:24
zyga-ubuntuChipaca: bolt doesn't exist for fedora now, that's a separate problem10:25
Chipacaah, ok10:25
Chipacai 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 over10:25
zyga-ubuntumvo: I have a crazy plan to make layouts easier10:26
zyga-ubuntumvo: I may do a spike around that today,10:27
zyga-ubuntumake / a tmpfs,10:27
kalikianazyga-ubuntu: all looking very nice now on the grammar front! thank you for pulling me out of that mental swamp!10:37
mborzeckizyga-ubuntu: https://src.fedoraproject.org/rpms/golang-github-boltdb-bolt ?10:43
mupPR snapd#4509 opened: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>10:43
zyga-ubuntumborzecki: ah, cool so perhaps we just need to add a new dependency to packaging10:44
zyga-ubuntukalikiana: glad to hear that!10:46
zyga-ubuntuhttps://github.com/snapcore/snapd/pull/4505 is green and easy to review :)10:56
mupPR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>10:56
mvozyga-ubuntu: you mean we need to package bbolt? or bolt? bolt is packaged, we could patch it with our fixes11:10
mvozyga-ubuntu: but that still would not solve our vendor'ed version (boltdb/bolt would still be buggy on ppc)11:10
zyga-ubuntuniemeyer: can you please re-review 4471 now11:23
ogramvo, 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 info11:28
ogramvo, do you think we could purge update-motd during build ?11:28
kozaor instead put correct files to /etc/update-motd.d and forget about the /etc/motd11:30
kozamvo, ogra ^^11:30
mvoogra: I was not aware of this11:30
* kalikiana taking a break, back in a few11:30
kozaanyways 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 Core11:30
kozamvo ^^11:31
mvokoza: +111:31
ogramvo, it is mainly this part we should drop i think:11:31
ograprintf " * Documentation:  https://help.ubuntu.com\n"11:31
ograprintf " * Management:     https://landscape.canonical.com\n"11:31
ograprintf " * Support:        https://ubuntu.com/advantage\n"11:31
ograsice it points to completely generic ubuntu docs and services11:31
kozaor replace with Core & Stacks documentation links11:31
ograwell, /etc/motd already points to the snappy docs11:32
kozadesktop/snappy ;-)11:32
ograif we move that over we should be fine11:32
kozaimho it should point here: https://www.ubuntu.com/core11:32
mvoogra, 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
ograkoza, well, it is supposed to tell you how to use snaps ... not how to create core :)11:33
ogra(i guess at least)11:33
ograprobably it should point to both :)11:33
kozait 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
kozaotherwise kill /etc/motd as it just creates confusion to where the stuff is coming from11:34
mvokoza: I'm in favor of the static motd, simpler this way11:34
ograwe might want to be able to abuse it for IoT status information11:35
kozayeah, good point11:35
ogra(at least that sounds like a useful feature)11:35
ograso keeping the functionality might make sense11:35
mvoogra: fair enough, if that is planned in the (near) future that is fine with me11:35
ogra(perhaps even an interface that could allow writing such info would)11:35
ogramvo, i'm only brainstorming :) nothing specific is planned ... but such a future feature sounds like a reason to keep update-motd11:36
ogra(instead of having to pull it in again later)11:37
mborzeckizyga-ubuntu: left some comments in 4505, also the unit tests pass on arch (none of this is really dynamic by anyway)11:41
zyga-ubuntumborzecki: thank you, examining11:41
mborzeckiChipaca: idk if you noticed this: https://paste.ubuntu.com/26416072/ it's not failing though11:43
kozamvo, https://github.com/snapcore/core/pull/76 and lets take it from here12:01
mupPR core#76: hooks: update the set-motd hook to provide better motd <Created by bergotorino> <https://github.com/snapcore/core/pull/76>12:01
mupPR core#76 opened: hooks: update the set-motd hook to provide better motd <Created by bergotorino> <https://github.com/snapcore/core/pull/76>12:01
=== ogra_ is now known as ogra
kozamvo, asked Thibaut about what he thinks about changing motd, you are on cc12:11
greybackjdstrand: https://pastebin.ubuntu.com/26416195/ snapd not liking plug and slot in same snap :(12:20
greybackI'll have a look to see why that is12:20
greybackanyone recommend an IDE for go?12:22
mupPR snapd#4510 opened: asserts: use Attrer in policy checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>12:24
zyga-ubuntugreyback: plug and slot must have unique names12:26
zyga-ubuntugreyback: just call one x11-slot12:26
zyga-ubuntugreyback: I use sublime text12:26
zyga-ubuntugreyback: and vim12:26
zyga-ubuntugreyback: both with go-specific plugins12:26
greybackzyga-ubuntu: just installed sublime :)12:26
greybackzyga-ubuntu: my trouble is that I was trying for one app to provide the x11 slot, so that the other app can plug into it12:27
zyga-ubuntugreyback: that's ok, it's just that the string "x11" is no longer unique12:27
zyga-ubuntuyou need to name the plug and the slot uniquely12:27
zyga-ubuntuboth can be of type "x11" (just say interface: x11)12:27
greybackzyga-ubuntu: oh ok, I understand12:27
zyga-ubuntupstolowski: do you have an URL with smaller diff12:28
pstolowskizyga-ubuntu, what do you mean? can I do that with github?12:29
zyga-ubuntuyes, something that can be reviewed more easily12:29
pstolowskizyga-ubuntu, I know how to do that in LP (set a base branch for a proposed branch), but not with github. let me see12:30
zyga-ubuntupstolowski: I think you can ask github for a diff between any two points12:34
cachiozyga-ubuntu, any idea why netlink-audit interface could be denying the connection https://paste.ubuntu.com/26412541/12:34
cachiozyga-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/bind12:34
zyga-ubuntu[  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
zyga-ubuntuthis says it all12:38
zyga-ubuntuthe interface doesn't grant the capability audit_read12:38
zyga-ubuntuthe interface must define an apparmor rule that grants access to that capability12:39
zyga-ubuntuif this is sane or not, I don't know12:39
mupPR core-build#25 opened: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <https://github.com/snapcore/core-build/pull/25>12:44
pstolowskizyga-ubuntu, I'm able to do that only if my repo is the landing target12:44
Chipacamborzecki: I hadn't noticed that (but I added those to stress test this :)) but it's interesting; what's doing the stat?12:45
Chipacaogra: you!12:45
ogramvo, https://github.com/snapcore/core-build/pull/25 is an additional one for the topic ...12:45
mupPR core-build#25: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <https://github.com/snapcore/core-build/pull/25>12:45
Chipacaogra: you *you* you12:45
* ogra hugs Chipaca 12:45
Chipacaogra: error: cannot perform the following tasks:12:46
Chipaca- Mount snap "packageproxy" (1) (snap is unusable due to bad permissions; contact develper)12:46
mvoogra: thank you, looking12:46
ograhuh ?12:46
ograChipaca, any more details ? i run packageproxy on several machines without issues here12:46
Chipaca2018/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:46
Chipacaogra: /ʌnˈjuːzəb(ə)l/12:47
ograogra@acheron:~/Devel$ snap services packageproxy12:47
ograSnap          Service  Startup  Current12:47
ograpackageproxy  approx   enabled  active12:47
mborzeckizyga-ubuntu: are you planning to push more patches to #4502?12:47
mupPR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>12:47
ograChipaca, woah12:48
zyga-ubuntumborzecki: not12:48
zyga-ubuntumborzecki: I'm planning a follow up with spread test but it dependson 447112:48
ograChipaca, thanks, will fix that (or even drop the icon, we'll see )12:48
mborzeckizyga-ubuntu: ok12:48
cachiozyga-ubuntu, well the idea of that interface is to access specifically to that12:49
zyga-ubuntucachio: netlink audit vs cap audit_read, fly this past jdstrand and it should be simple to patch12:49
cachiozyga-ubuntu, sure, tx12:50
cachiojdstrand, 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
zyga-ubuntukalikiana: at least it's sunny12:51
zyga-ubuntukalikiana: it's ~0 but cloudy all day here12:51
cachiojdstrand, this is the code https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind12:51
kalikianazyga-ubuntu: sometimes direct sun briefly lets me forget about the cold. not strong enough today it seems12:52
zyga-ubuntumy fingers were freezing last time I tried that12:52
zyga-ubuntu(but it was far warmer then)12:52
kalikianain fairness, I'm fairly cold tolerant and massively addicted to sun, so I'm persistent :-D12:54
* kalikiana getting a hot beverage12:55
ograChipaca, 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
mupPR core-build#25: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <https://github.com/snapcore/core-build/pull/25>12:55
Chipacaogra: ( ¬_¬)12:57
mvoogra: I look forward to the day we can bury writable-path (this is my "Ceterum censeo Carthaginem esse delendam" from now on)12:59
Chipacamvo: "Ceteru censeo /etc etc"13:01
ogramvo, well, if someone comes up with something super bright to replace it :)13:01
ogra(i still dont see how ... )13:01
zyga-ubuntumborzecki: updated the layout PR13:02
* zyga-ubuntu reboots13:04
mupPR core-build#25 closed: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/25>13:10
* kalikiana lunch13:34
mborzeckithey're having some perfromance at my daugter's school, gotta run, bbl to read more on apparmor and unix sockets14:03
zyga-ubuntu4505 needs a 2nd review now14:06
pstolowskizyga-ubuntu, updated the desc 4510 with an URL that only shows the relevant changes, minus interface hooks PR14:44
zyga-ubuntupstolowski: thank you!15:01
zyga-ubuntupstolowski: small comments there15:26
pstolowskizyga-ubuntu, re interface-hooks, do you have any suggestion for the naming of test-snapd interface? just snapd-test maybe?15:49
* zyga-ubuntu walk15:56
zyga-ubuntupstolowski: I'll be back in one hour15:56
zyga-ubuntupstolowski: hmm, maybe 'dummy15:56
zyga-ubuntuor fake or something appropriate15:56
zyga-ubuntuso that it is a "real" interface15:57
zyga-ubuntujust a no-op15:57
pstolowskiindeed, nice idea15:57
mvohm, I have a peculiar issue here - when I run snapcraft inside travis in my makefile $(DESTDIR) is "" but its clear from the log that make DESTDIR=/dfasf was used and it works locally. (context is https://github.com/snapcore/base-18/pull/34)16:00
mupPR base-18#34: add .travis.yml <Created by mvo5> <https://github.com/snapcore/base-18/pull/34>16:00
zyga-ubuntumake DESTDIR=foo and DESTDIR=foo make are distint16:01
zyga-ubuntuthey have different override priorities16:01
zyga-ubuntuand now I'm gone, sorry16:01
kalikianamvo: whom are you expecting to set DESTDIR?16:15
mvokalikiana: snapcraft, but I found it now, travis is using an older make so I had to update the makefile a bit16:16
kalikianamvo: you might want to build in lxd to get xenial tooling16:18
mborzeckimvo: do you think it makes sense to to look into abstract sockets in #4509 even if those do not seem to be used by systemd for notifications?16:19
mupPR #4509: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>16:19
mvomborzecki: if they are not used, then no, I think not16:21
mvokalikiana: this is in .travis.yml need to see if that works16:21
mvokalikiana: anyway, I'm good for now,thanks!16:22
kalikianamvo: for the record, yes it does https://github.com/CanonicalLtd/multipass/blob/master/.travis.yml16:23
mborzeckimvo: while at it, could you glance over 4509 when you're done with the makefile? :) hope i didn't do anything too stupid there16:24
mvokalikiana: cool16:25
mvomborzecki: sure!16:25
mborzeckimvo: thanks16:25
mupPR snapcraft#1880 opened: Provide stub for when /etc/os-release doesn't exist <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1880>16:28
kalikianaPharaoh_Atem: ^^ you might be interested in this one. it's the "other distros", but even worse16:30
Chipacakalikiana: workaround: install an actual distro?16:33
kalikianaChipaca: nice try :-D16:33
mborzeckimvo: thanks for the review, right the reset code is only needed if i use the 'cached' snipped, otherwise i can drop it altogether16:33
kalikianasergiusens: kyrofa FYI snappy-docs#32516:41
kalikianahmmm bot fail16:41
mupPR canonical-docs/snappy-docs#325: Explain how to use "to" in conjunction with "on" <Created by kalikiana> <https://github.com/canonical-docs/snappy-docs/pull/325>16:41
Chipacamardy: ping16:41
Chipacamardy: your "visualsfm-mardy" has a 0600 file in meta/ that'll make it uninstallable in an upcoming release16:46
Chipacamardy: given the file in question is meta/gui/.VisualSFM.desktop.swp, I suspect it's included in the snap in error16:47
* kalikiana calling it a week17:15
ChipacaI think I'm calling it a week as well17:29
* Chipaca needs to go to the shops, might as well go now17:29
mborzeckii'm done for this week too17:38
mborzeckienjoy your weekend guys17:38
kyrofaI swear, whenever I need to record some sound effects someone decides to cut down a tree18:30
kyrofaIt must be the biggest tree of all time, too18:33
zyga-ubuntukyrofa: I hope the tree respawns for another recording session19:53
jamesb192I am working on a *ntoo package for snapd. I have a manifest of files in the latest iteration of the package -> https://paste.debian.net/1006034/ . How much am I missing?21:09
kyrofajamesb192, you probably want zyga-ubuntu, but he may be gone already (he's in Poland)21:11
jamesb192I figured. I worked from his blog post on centos. It will keep.21:15
palassojamesb192: There was a gentoo overlay that had been done about 1.5 year ago21:17
jamesb192the latest there was 2.15.2 I'm working on 2.30 atm. git pull will come later.21:19
SuperJonotrondocker snap on ubuntu core giving "no space left on device" error21:30
SuperJonotronplenty of space left, completely removed all containers, images and volumes and removed and installed the snap21:30
SuperJonotronstill reporting this issue which didn't happen until i tried to install a second image21:31
SuperJonotronany ideas on how to fix this docker snap issue?21:31

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