[00:07] ogra_, I suppose you're long gone into the night? [00:26] ogra_, when you get in tomorrow: how hard would it be to fix https://bugs.launchpad.net/snappy/+bug/1650207 ? No ROS stuff will build in classic mode [00:44] Oh, it's writable in classic, handy [02:43] if i have an additional top level command 'conjure-down' for this do i need to register with the store to have that alias created? [02:44] ahoneybun: it would be better off with a Qt5 part, it doesn't need all of KDE === chihchun_afk is now known as chihchun [08:43] PR snapd#2666 closed: interfaces: add ability to set system time zone to timeserver_control interface [08:43] PR snapd#2679 opened: Ubuntu/14.04 [08:43] PR snapd#2585 closed: debian: move systemd files out of ./debian and into ./data/systemd [08:43] PR snapd#2680 opened: interfaces: shutdown: also allow shutdown/reboot/suspend via logind [08:43] PR snapd#2681 opened: tests: only build test binaries if they are not present [09:06] jdstrand: I may have an idea why other snaps than my own corebird-diddledan aren't able to launch URLs via xdg-open. I need to test it, but I did NOT build my snap with the snapd-glib interface but bundled glib into my snap directly [09:14] o/ [09:14] diddledan: hey, I think this part is broken/needs love [09:14] diddledan: it's on our roadmap but always has low priority and gets postponed [09:14] mvo: ^^ FYI [09:14] (snapd-xdg-open) [09:16] zyga: the confusing bit was my own snap works as it should, but jdstrand had noticed other snaps not working correctly which prompted questions as to what was different about my snap that made mine work [09:16] diddledan: so to make it work you need two pieces [09:16] diddledan: and because it has been a bit neglected we don't have a well designed responsiblity as to who owns them [09:17] diddledan: on the desktop side you need snapd-xdg-open installed, in theory snapd should recommend that on the destkop [09:17] diddledan: on the othoer hand, core snap (or ubuntu-core) should ship the shim xdg-open from snapd-xdg-open [09:17] diddledan: AFAIK neither are true now [09:17] diddledan: if you install snapd-xdg-open on your desktop manually [09:17] diddledan: and build and install the shim in your snap manually [09:18] diddledan: then I believe, apart from bugs in the actual shim, it should work [09:18] diddledan: it's just not what we want people to have to go through :/ [09:18] zyga: I only installed snapd-xdg-open. jdstrand tested on his system so it's not something specific to my system [09:19] zyga: as I say, corebird-diddledan WORKS CORRECTLY. it is OTHER snaps ON THE SAME SYSTEM WHERE MINE WORKS that fail [09:20] I wasn't shouting there, but wanted to highlight the important bits, sorry if it appears aggressive - wasn't meant to be [09:21] diddledan: no, that's fine [09:21] diddledan: if corebird works ok but others don't then I suspect they don't ship the shim [09:21] I don't ship the shim in mine [09:22] I did absolutely nothing special apart from installing snapd-xdg-open on the host [09:23] diddledan: feels like magic, is there xdg-open in the core/ubuntu-core snap? [09:24] but even if it is in the core snap, that would suggest that other snaps should also work when they currently do not ON THE SAME SYSTEM [09:26] ok, the xdg-open shim is NOT in core NOR is it in corebird-diddledan [09:26] it doesn't exist [09:26] at all [09:26] diddledan: as I said, this story is neglected, I may be missing something, those other snaps may have tried to make it work but did something that made it more roken [09:26] *broken [09:27] yeah that's what we want to understand. the WHY [09:28] personally I'm happy that mine works. for the project it needs to be understood what is different [09:31] diddledan: hmm [09:31] diddledan: is your snap classic? [09:31] diddledan: (it should never work then) [09:31] diddledan: how do you observe it working? [09:31] diddledan: (in any case, there's a well-known list of things to do to fix this) [09:31] diddledan: do hello-xdg-open snap [09:31] diddledan: I bet it won't work if you run xdg-open [09:31] diddledan: maybe there's a dbus service that also opens URLs that is somehow allowed via unity [09:31] * zyga has huge lag to IRC network [09:31] my snap is strict confinement [09:32] I observe it working by clicking links or other actions that open a url directly from corebird [09:34] diddledan: and then your browser opens? [09:34] diddledan: I don't have time to investigate this now [09:34] diddledan: if you want to do that, I suggest stracing your application to see if it fork/execs something [09:34] yes it does [09:39] well blow me down. it's _stopped_ working now [09:40] I've not changed _anything_ and now it no longer works [09:41] well, at least that is good [09:41] it should not have worked [09:41] did you run the app outside of confinement / sandbox by any chance [09:41] e.g. running it directly from /snap/$SNAP_NAME/current/... [09:42] I'm unsure now [09:43] well, [09:43] do what I suggested [09:43] you may get it to work for real then [09:47] hmm, still all bots gone [11:19] mup: you ok? [11:19] niemeyer: I really wish I understood what you're trying to do. [11:19] bug 12345 [11:19] Bug #12345: isdn does not work, fritz avm (pnp?) [11:19] ogra_: mup back with its usual mood [11:19] yeah, looks fine [11:53] PR snapd#2724 opened: overlord,tests: have enable/disable affect security profiles [12:09] PR snapd#2725 opened: overlord/ifacestate: use ParseConnRef [12:24] PR snapcraft#1079 opened: Add snapcraft plugin for Qt Build Suite (qbs) [12:29] Bug #1659534 opened: userdel doesn't supports extrausers === yofel_ is now known as yofel [13:26] PR snapd#2726 opened: interfaces: core-support: also allow enable/disable of a systemd unit [13:33] PR snapd#2725 closed: overlord/ifacestate: use ParseConnRef [13:39] kirkland: hey, any update on that bug? [13:39] er [13:39] kissiel: ^ [13:39] (sorry kirkland) [13:41] zyga: https://bugs.launchpad.net/snapd/+bug/1659272; nope; @ mtg [13:41] Bug #1659272: dbus access denied in nested python [13:41] kissiel: thanks [13:44] kyrofa: hi! remember the ca-certificates-java thing? I have an extra clue. if I build a snap that stage-packages openjdk-8-jre-headless and ca-certificates-java but doesn't have either of those installed on the system as debs, I get snapcraft creating a dangling symlink: [13:44] /home/ubuntu/snappy-apps/minecraft-snap/parts/minecraft/install/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts will be a dangling symlink [13:45] jdstrand: hey, morning :) [13:45] kyrofa: if I use the same stage-packages but install the debs on the system, snapcraft finds it and uses the system one and the snap is fine: [13:45] Copying needed target link from the system /etc/ssl/certs/java/cacerts [13:46] hey zyga :) fyi 2718 and 2658 are at the top of my list today [13:46] jdstrand: no worries, we're busy with a release :) [13:46] jdstrand: the update-ns PR is does not need a deep review now (it should not land yet), I just wanted to get first impression [13:46] *impressions [13:46] ok [14:06] * kirkland waves at zyga [14:21] slangasek, what day does the SRU team normally process verification-done bugs? [14:24] slangasek, or if you could flip the bit on snapd 2.21 so it'll make it into xenial-updates today that would be even better :) [14:27] rmescandon: ping, I saw that you have a Solr snap in the store, have you been in contact with the upstream to see if they will adopt it? [14:28] mhall119, nope [14:45] mhall119, https://issues.apache.org/jira/browse/SOLR-10044 [14:46] mhall119: hey, fyi, I issued snap declarations for dbus for two kde snaps and approved them, but they still need to be released (btw, why isn't apachelogger here?) [14:46] mhall119, no problem in moving code to another organization/place if needed [15:29] stokachu: the SRU team releases SRUs Mon-Thu; I'll look at snapd now [15:29] slangasek, awesome ty! [15:32] ogra_: how do I do a let n=n+1 with /bin/sh? [15:33] morphis, n=$((n+1)) [15:33] ok! [15:33] ogra_: thanks [15:33] np :) [15:40] thanks rmescandon [15:40] thanks jdstrand [15:53] morphis, you kept "let n=n+1" in the upper function ... [15:53] uups [15:54] also check if it works with non-integers ... i'm not sure it does [15:54] (or probably set wait_time=1 instead) [15:55] ogra@localhost:~$ n=$((n+0.1)) [15:55] -bash: n+0.1: syntax error: invalid arithmetic operator (error token is ".1") [15:55] yeah [15:58] ogra_: can you comment that in the MP? [15:58] PR snapd#2727 opened: overlord/ifacestate: register all security backends with the repository [15:59] morphis, oh, sorry, i mis-took wait_time for wait_attempts ... all good [15:59] ok :-) [16:02] morphis, btw, probably good to bookmark this https://wiki.ubuntu.com/DashAsBinSh has all the POSIX vs bashism bits [16:03] (including let) [16:03] ogra_: thanks [16:05] morphis, o/ [16:05] morphis, dunno if my review made sense [16:05] the `while $n -lt 10 $wait_attempts ! is_ssh_unit_enabled` line is fairly borked :-) [16:07] Chipaca: thanks [16:19] jdstrand, interesting-- the broken symlink is an absolute one, I assume? [16:20] kyrofa: it points to /etc/ssl/certs/java, yes [16:20] which doesn't exist in core [16:21] the review tools notice that, but a locally installed snap user might not [16:21] jdstrand, indeed... hmm. Perhaps the repo should be rewriting stage package symlinks [16:23] PR snapd#2728 opened: tests: add extra debugging to security-setuid-root test [16:49] Hey ogra_, how hard of a bug is https://bugs.launchpad.net/snappy/+bug/1650207 ? [16:50] kyrofa, i landed a potential fix for it today ... not sure if mvo did re-build the edge core snap already since [16:50] there was a release going on today to i didnt touch the build button [16:50] And will the fix mean that /etc/lsb-release is different in the core snap, or only in the classic shell? [16:51] ogra_, awesome, thanks for working on that :) [16:51] kyrofa, in the classic shell [16:52] ogra_, will it be exactly xenial's, then? [16:52] but the classic shell tarball is created during build of the core snap ;) [16:52] the classic snap just unpacks it [16:52] so the fix is in the core snap build itself [16:52] I suppose that does make sense. So they're intrinsically tied, eh? [16:52] yes [16:53] Are there docs for the snapd-control interface? [16:53] the tarball contains all bits that we rip out during build :) [16:53] not a pressing thing, just curious about it [16:53] ogra_, heh. So the /etc/lsb-release in the classic shell will be exactly xenial's? [16:54] if the fix works, yes [16:54] ogra_, excellent, thanks for the update! [16:54] havent tested it yet ... i simply "dpkg -i" the original base-files package [16:54] ryebot, what kind of documentation are you looking for? [16:55] (but i'm not 100% sure it will overwrite the modified lsb-release file ... thats up for testing still) [16:55] I just want to know what it can do, more or less [16:55] ryebot, we have an Interfaces wiki: https://github.com/snapcore/snapd/wiki/Interfaces#snapd-control [16:55] But it doesn't say much [16:55] Does it allow you to launch other snap's apps? [16:55] ryebot, it allows the snap to talk to the snapd socket (install/update/remove snaps over REST API) [16:55] ryebot, no [16:56] PR snapd#2729 opened: tests: use test snap [16:56] okay, understood; thanks for the typically quick response :) [16:56] ryebot, that interface is used for example by snapweb. Have you used that? [16:56] I have, yes [16:57] I was toying with the idea of writing a snap that hooked into custom urls to install/launch other snaps [16:57] ryebot, that's a confined snap, but it allows you to search for/install snaps by talking to snapd. The only way it can talk to snapd like that is via the snapd-control interface [16:57] makes sense [16:58] ryebot, I think such a utility would need to be outside confinement. It sounds like the snap-xdg-run utility that supports opening URLs from snaps [16:58] (not sure that's actually what it's called... but it's something like that :P ) [16:58] oh cool, thanks, I'll look into that [16:58] ryebot, talk to jdstrand, he knows all [16:58] :D [17:01] ryebot: snapd-control does not allow launching other snaps. nothing does in strict confinement atm. snapd-xdg-open allows running a url handler, but that isn't tied into snaps yet [17:02] that's understandable [17:02] ogra_: not rebuild anything yet, feel free to do that [17:02] ryebot: you are probably interested in https://bugs.launchpad.net/snappy/+bug/1639746 [17:02] Bug #1639746: Snap launching other snaps [17:03] jdstrand: yep! just signed up, thanks :) [17:05] ryebot: the point of confinement is that snaps can't interfere with each other. transitioning from one confinement to another while honoring that requirement is tricky [17:05] ogra_, if you happen to get a new classic into edge, I'd be happy to test it [17:05] kyrofa, core you mean :) [17:06] it is all in core [17:06] ogra_, well, both, right? :P [17:06] nope [17:06] jdstrand: yeah, no doubt [17:06] ogra_, wait... how does the classic snap update? [17:06] ogra_, so the classic snap literally installs and then unpacks something that core is holding onto? [17:06] I thought you extracted that from core and put it into the classic snap, they were just released in lockstep [17:07] the classic snap unsquashes core ... then unpacks the tarball (from insiode core) on top [17:07] if classic gets updated nothing happens [17:07] ogra_, what if I've already run that step? Will classic notice it's out of date? [17:07] no, we dont fiddle with developer chroots once they are created [17:07] its up to you to apt update/upgrade it then [17:08] ogra_, ah interesting. So if I've already created that chroot, will an apt upgrade get me a new /etc/lsb-release? [17:08] nope [17:08] ogra_, can I kill the chroot and re-create it, then? [17:08] apt-get install --reinstall base-files perhaps [17:09] yeah [17:09] that should work [17:09] ogra_, where is it, so that I can kill it? [17:09] snap remove classic [17:09] ;) [17:09] Oh, well. [17:09] its in the common dir of the classic snap [17:11] ogra_, perfect, thank you. Okay so then: if you happen to publish a new core snap with this change, please let me know, I've got a dragonboard setup I can use to test it [17:11] ok [17:11] ogra_, thanks for the explanation, I understand classic mode quite a lot more now [17:12] i just triggered a new core build ... in ~30min there should be a new one in edge [17:19] slangasek, thanks for the push to updates [17:21] question, I'm about to upload a new revision of my conjure-up snap that has a new binary called 'conjure-down' do I need to ask someone to register an alias to conjure-down? [17:21] stokachu, good question. Do you already have an alias? [17:21] stokachu, I mean, do your aliases already auto-connect? [17:22] kyrofa, not that i know of [17:22] so i have https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml [17:22] Ah, then you don't need to talk to anyone. You can declare interfaces all day long, but snapd won't automatically enable them for you (or your users) without someone flipping a switch in the assertion store-side [17:22] stokachu: you can have as many aliases as you want to declare. users manullay add them to the system so there is nothing to worry about on the store end. only if you weant the alias auto-added do you need to ask a reviewer to grant that to you [17:22] Argh, not interfaces-- aliases [17:22] I type that word too much [17:23] man, I can't type [17:23] so i would like to have them auto connected, do i need to upload the snap with the alias defined beforehand? [17:23] jdstrand, you always make me feel better [17:23] kyrofa: thanks? :P [17:23] jdstrand, :P [17:23] stokachu: it doesn't matter [17:24] I suspect just uploaded PERIOD so it has an ID [17:24] jdstrand, so i want to create the conjure-down alias for https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml#L15 [17:24] my snap is already uploaded it just doesn't have that latest build [17:25] stokachu: done [17:25] jdstrand, awesome ty! [17:25] now that 2.21 is in xenial-updates i can finally flip the switch to pure snap of conjure-up [17:25] well classic snap anyway [17:26] jdstrand, do i still need to add the aliases: [conjure-down] in my snapcraft? [17:26] snapcraft.yaml* [17:27] stokachu: yes [17:27] jdstrand, are aliases individually granted? Or do you just say "yes, this snap can automatically have any aliases it declares"? [17:27] perfect thanks [17:28] PR snapd#2730 opened: snap: be more helpful in the `snap install ` error message [17:28] stokachu: you have to let snapd know what the aliases are. once it knows what they are, it looks at the snap declaration to see what to auto add [17:28] jdstrand, ack, makes sense ty [17:34] jdstrand: ping [17:34] niemeyer: hey [17:35] jdstrand: Heya [17:35] jdstrand: Today we've been having a long debate about the configure script for core [17:36] jdstrand: Lot's of back and forth on several details [17:36] jdstrand: By now it's getting pretty obvious that we want direct systemctl access on it [17:36] niemeyer: morphis let me in a few of those details [17:37] niemeyer: I thought he was able to use dbus-send fine? [17:37] jdstrand: I know you were against that, and I could see why.. wondering if some of your worries are relieved by having the interface as core-support [17:37] jdstrand: No, that was the first impression, but it's actually very messy === chihchun is now known as chihchun_afk [17:37] * jdstrand notes he say later commits to his hook [17:38] jdstrand: We can't easily tell the result of the call.. the original hook was doing stop, but we really want stop+disable [17:38] jdstrand: So there's a loop in there, which isn't nice because it's waiting regardless of knowing why [17:38] etc etc [17:38] jdstrand: So the proper thing to do was to wait for the job, as systemctl does, ... [17:39] jdstrand: This is getting unwise to pursue, IMO [17:39] niemeyer: from my perspective, the security policy is clean right now with core-support, and that was my primary concern. the fact that only core can use it is important, yes, but systemctl isn't written with mediation in mind, so I didn't like all the extra unrelated security policy [17:39] niemeyer: if you want systemctl, then just put systemctl Uxr, in the policy [17:40] niemeyer: then we aren't pretending anything with the confinement [17:40] jdstrand: +1 [17:40] jdstrand: Given this is just an extension of snapd, I think that's okay [17:40] 'Uxr' says systemctl can run unconfined [17:40] jdstrand: It's not quite ideal, but an excellent start IMO [17:41] jdstrand: The high-level goal of that one setting is precisely to have a properly abstracted way to enable and disable ssh in pure snap systems [17:41] niemeyer: it is good for the configure hook. it is poor from a security policy perspecitve. it is acceptable based on base declaration restrictions [17:42] jdstrand: If we render it technically flaky, or end up giving up altogether and putting the logic into the snapd binary proper, it won't be any better [17:42] niemeyer: this achieves that goal, but does not restrict it to only that goal [17:42] which is what I really didn't like [17:43] jdstrand: It doesn't on itself, but arguably the configure of core, specifically, is bound to be doing system-level configuration on behalf of the user and of other snapd that have snapd access [17:43] there are ways to do stopping/starting/disabling/enabling services properly, but that couldn't be implemented today [17:43] niemeyer: that's why I said the base declaration makes it 'acceptable' [17:44] jdstrand: Ok, thanks [17:44] jdstrand: Let's move on with this then, and learn our lessons on the way [17:44] niemeyer: can someone ping me on the updated PR if this is time-sensitive? [17:46] jdstrand: It is time sensitive, and morphis plans to be doing work on it tomorrow morning [17:46] (his) [17:46] jdstrand: I'll mail him with the outcome of our conversation and one more detail today [17:49] roadmr: hi! would you mind pulling r833 of the review tools. it isn't terribly urgent (next week would be 'ok'). sonner is better, but don't feel like you have to do extraordinary measures [17:50] roadmr: also, I had the idea of shipping the review tools as a snap and floated that out to cprov. He loved it. that would allow staging to point at edge and prod stable and then no more pulls [17:51] sergiusens: this also means snapcraft could call the review tools if the command was available (ie, the snap installed) and we'd never have to worry about an out of date deb [17:51] sergiusens: ^ [17:53] sergiusens: you could finally run the review tools and have confidence that what they and the store report was the same [17:57] jdstrand: awesome idea on the snap!!!! [17:58] jdstrand: yup, instead of channels we we actually need refresh-control server side, but having the review-tools as a snap will be definitely an improvement [17:59] jdstrand: having the service be mutable and update some component out-of-release-cycle sounds a bit scary, we try not to have mutable services, but totally worth a think. cprov this would be my main concern [17:59] (so don't think I'm opposed, on the contrary, but we need to consider implications) [17:59] jdstrand: also... sure, r833 coming up in a sec ! [17:59] roadmr: a nice property is that the review tools run confined [18:00] moving to a snap is not super soon in the queue, but I'll let you guys know when it is then you can start using it whenever you want [18:05] thanks jdstrand ! yes, because it'll have implications on how the service is deployed and hosted. Weighing immutability vs. confination will make for a fun exercise [18:07] roadmr: I was mostly saying that it is a benefit. wasn't arguing immutability [18:08] jdstrand: yes, I absolutely agree on the benefit of confination [18:09] jdstrand: hehe so again please don't take my ramblings as any sort of pushback, I think it's an awesome idea and once the snap is available I'm happy to push for that to be the way we use the tools. I'll find a way to deal with any other concerns [18:09] sounds great :) [18:17] PR snapd#2717 closed: interfaces: builtin: mir: allow recv and send [18:36] PR snapcraft#1076 closed: autotools: extend Make plugin instead of repeating code [18:38] Hello, got one question [18:38] Hey there KristijanZic, fire away :) [18:38] Does snappy hard depend on Systemd? Could it be ported one day to BSD? [18:44] kyrofa: ^ [18:44] KristijanZic, at the moment yes, systemd is a hard dependency. But the spec doesn't require it [18:45] KristijanZic, when one writes a snap that declares a service, the keys one uses to describe the service behavior (simple daemon, forking, etc.) would need to be satisfiable by the given system, and snapd would need to support it [18:45] PR snapcraft#1080 opened: python plugin: avoid the use of PYTHON* env vars [18:45] KristijanZic, as of right now, the only system supported is systemd [18:46] KristijanZic, but that may be refactored at some point [18:46] kyrofa, it would be beneficial to make it extensible so that other service management systems could easily be hooked in with a form of a plugin or something. Once they're stable enough, potentially upstreamed [18:46] kyrofa: ah, not what I was hoping for but I hope that gets redesigned. [18:47] jamespage, stokachu, marcoceppi_ hey, mind testing this branch https://github.com/snapcore/snapcraft/pull/1080 ? It sort of solves the PYTHON* env var leaking but want to be sure it still works for you [18:47] PR snapcraft#1080: python plugin: avoid the use of PYTHON* env vars [18:47] kyrofa, thanks! :) [18:47] dstolfa, I wholeheartedly agree, but there's always work to be done. The question is the priority that should be associated to such work [18:49] sergiusens: how do I test that branch? you got a snap ;) [18:49] kyrofa, well, it could be done in a privsep way, that is separating the actual plugin that does it into different components, such as systemd, launchd, SMF, ..., and then have the standard functionality that it needs to provide. Somewhat similar to what the MAC framework does in FreeBSD. Now, that's probably not so much of an urgency, but I would be willing to write such a plugin once we have a service management system in place in FreeBSD(current w [18:50] I believe that people would find use of it on Apple systems though, through launchd which can provide such behaviour [18:50] marcoceppi_, from source right now; I intend to have a solid snap on classic thing going soon but this branch needs to get in first [18:50] dstolfa, well, you're assuming that the REST of snapd's dependencies are available on such systems as well [18:50] Which isn't necessarily the case [18:50] sergiusens: I'll add it to my todo, won't have much time today [18:50] dstolfa, I'm really talking about apparmor here [18:50] kyrofa, I'm not aware of all the dependencies, is there a list somewhere? [18:50] marcoceppi_, no problem, thanks [18:51] dstolfa, the confinement tech isn't available everywhere [18:51] dstolfa, in fedora they have selinux, for example [18:51] Ah, well that's really just a form of access control, couldn't it be extensible? [18:51] marcoceppi_, if not, give me your branch and tell me what to run to ensure it all works ok (to smoke it a bit) [18:51] dstolfa, indeed, but you see how this blossoms [18:51] That way, if someone wanted to, one could apply even things like grsec RSBAC to it [18:51] kyrofa, well, it does. There is work to be done, but imo would be useful to do eventually, as the need arises :) [18:52] dstolfa, right, I completely agree [18:52] sergiusens: https://github.com/juju-solutions/charm-pkg it's here for now, need to move the snapcraft yaml into the project root now that I've removed all the weird workaround files [18:52] sergiusens: once built and installed, try `charm version; charm create foobar; cd foobar; charm build` [18:52] dstolfa, don't get me wrong, I think we can all agree we'd like to see snapd everywhere. But I'd rather have a good product in less places than a bad product everywhere because we devoted all our time to that [18:53] sergiusens: if you get tracebacks, you know something went wonky [18:53] The only requirement in doing so really, is just keeping the dependencies in check -- that is, not allowing dependencies to branch out too much, rather wrapping them so that it's an easier job later on. [18:53] kyrofa, agreed there. [18:54] sergiusens: just pushed up the latest changes [18:54] Either way, be right back. Food :) [19:00] marcoceppi_, thanks! [20:45] PR snapcraft#1081 opened: local source: preserve symlinks to directories [20:46] PR snapd#2697 closed: cmd,snap,wrappers: systemd reload command support [20:49] PR snapd#2728 closed: tests: add extra debugging to security-setuid-root test