[01:17] <kenvandine> pedronis: thanks
[01:52] <mup> PR snapd#6604 opened: tests: tests add check to detect a broken snap on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6604>
[06:03] <zyga> Good morning
[06:03] <zyga> stgraber: ouch, thanks for sharing!
[06:22] <mborzecki> morning
[06:26] <zyga> Hey hey
[06:27] <zyga> More rain today
[06:27] <zyga> I’ll be home soon, just finishing morning walk
[06:42] <zyga> back in the office now
[06:56] <zyga> mborzecki: hey, what is https://github.com/snapcore/snapd/pull/6329 blocked on?
[06:56] <mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
[06:56] <zyga> or blocked by
[07:03] <mborzecki> ah, it's not now
[07:03] <mborzecki> zyga: forgot to take the label off
[07:03] <zyga> :-)
[07:03] <zyga> la-la-land-it
[07:04] <mborzecki> oh, and it's green too
[07:04] <zyga> quick, before it turns sour ;)
[07:04] <mborzecki> haha
[07:04] <mborzecki> pedronis: do you want to take a look at #6329? it's snap-confine
[07:04] <mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
[07:05] <zyga> https://github.com/snapcore/snapd/pull/6601 is a low hanging fruit
[07:05] <mup> PR #6601: errortracker: fix panic in Report if db cannot be opened <Simple 😃> <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6601>
[07:06] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6601 is green and +2 :)
[07:06] <mup> PR #6601: errortracker: fix panic in Report if db cannot be opened <Simple 😃> <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6601>
[07:06]  * zyga breakfast
[07:08] <mborzecki> wow, emacs crashed
[07:10] <zyga> too many open tabs?
[07:19] <mborzecki> zyga: backtrace leads back to imagemagick
[07:19] <zyga> I...
[07:19] <zyga> well
[07:19] <mborzecki> must have been that treemacs thing i tried
[07:19] <zyga> unusual but what can I say
[07:20] <mborzecki> hmm https://paste.ubuntu.com/p/h7MtPn3cYr/
[07:35] <pedronis> mborzecki: do we need jdstrand reviews for 6485 and 6592, I thought he +1 the original long branch? did things change a lot from it?
[07:35] <pedronis> sorry
[07:35] <pedronis> mborzecki: 6592 and 6593
[07:36] <pedronis> we can still ask him to (re)review the final bit
[07:37] <mborzecki> pedronis: only significant change in 6592 is the test to check whether we accounted for all syscalls known to seccomp
[07:37] <mborzecki> 6593 has a little api tweak, but that's all
[07:38] <pedronis> mborzecki: yea, I think if they have two review they can land without jdstrand
[07:38] <mborzecki> pedronis: ack
[07:39] <mup> PR snapd#6593 closed: sandbox/seccomp: a helper package wrapping calls to snap-seccomp <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6593>
[07:41] <mup> Bug #1819629 changed: no default locale in core18 causes pam errors <snap-core18:Fix Released by sil2100> <Snappy:Fix Released by sil2100> <https://launchpad.net/bugs/1819629>
[07:49] <mup> PR snapd#6601 closed: errortracker: fix panic in Report if db cannot be opened <Simple 😃> <⚠ Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6601>
[07:53] <mvo> sil2100: hey, hope I don't get on your nerves already - if you could upload the bionic version of systemd from -proposed to ppa:canonical-foundations/ubuntu-image that would be awesome, then I can trigger a core18 build and add UC18 to the regression test for the systemctl hang
[07:53] <mvo> sil2100: (I would love to do that myself and safe you trouble but I don't have the right permissions)
[07:58] <zyga> hello mvo :)
[07:58] <pedronis> mvo: hello
[07:58] <pedronis> mvo: sil2100:  ogra last night was reporting that snapfuse is not available with core18
[07:59] <mvo> zyga: good morning!
[08:01] <mvo> pedronis: hm,hm, thats a tricky one, it comes from the snapd binary and is in /usr/bin/snapfuse, we should probably move it to /usr/lib/snapd/snapfuse and make /usr/bin/snapfuse a symlink
[08:01] <pstolowski> mornings!
[08:01] <mvo> hey pstolowski
[08:07] <mvo> sil2100: I'm looking at the xenial systemd ADT issues right now and I see enough failure to think we should pull the update for now :(
[08:07] <mvo> sil2100: at least the xenial version, looking at bionic next
[08:08] <sil2100> mvo: I thought I copied systemd to ubuntu-image yesterday
[08:08]  * sil2100 looks
[08:09] <sil2100> mvo: yeah, systemd is there since yesterday systemd 237-3ubuntu10.16
[08:09] <sil2100> (binary copy, identical to the one in -proposed)
[08:09] <mvo> sil2100: oh, maybe I looked at the wrong thing, sorry
[08:09] <mvo> sil2100: we need to pull the xenial verison :( I just asked in #ubuntu-release
[08:17]  * zyga just updated to .4 via SRU
[08:17] <zyga> thanks everyone!
[08:17] <zyga> mvo: what's wrong with the systemd update?
[08:20] <mvo> sil2100: and one last question (promised!) - did steve had any idea why trusty snapd was in dep-wait state?
[08:22] <sil2100> mvo: no, I guess we'll have to dig into that today again, he just said demoting snapd to universe is not an option, but in the end he didn't say if our predictions about the reason for the failure are correct
[08:23] <sil2100> mvo: btw. so hmmm, even without us copying systemd to ubuntu-image I guess should have the new systemd?
[08:23] <sil2100> mvo: I mean, aren't we getting systemd from ubuntu-base?
[08:23] <mvo> zyga: some failures like this http://autopkgtest.ubuntu.com/packages/p/python-systemd/xenial/i386
[08:24] <mvo> sil2100: we get it from ubuntu-base - is that building from -proposed?
[08:24] <sil2100> mvo: yes, which now actually scares me a bit
[08:24] <mvo> zyga: https://paste.ubuntu.com/p/8hF3mPxKTR/
[08:25] <mvo> sil2100: uhhhh
[08:25] <mvo> sil2100: yes, me too
[08:25] <sil2100> mvo: since it means in the core18 snap we're actually using packages from -proposed everytime ;/
[08:25] <mvo> sil2100: I was not aware of this
[08:25] <mvo> sil2100: yeah, also people who build other things on ubuntu-core may not be aware of this
[08:25] <mvo> sil2100: is this a conscious decision and if so, whats the reasoning behing it?
[08:26] <sil2100> mvo: yeah, so by default in Ubuntu when a stable lts series is released but still gets its daily-builds, they're by default built using -proposed to ease testing of proposed packages IIRC
[08:27] <sil2100> Anyway, this needs to be fixed
[08:27] <sil2100> Somehow
[08:27] <sil2100> Either by revisiting this policy or by building ubuntu-base without -proposed somewhere for our purposes
[08:28]  * sil2100 gets the shivers now
[08:28] <mvo> sil2100: thank you!
[08:37]  * zyga hugs mvo
[08:37] <zyga> thank you for being on the front line of systemd issues
[08:38] <mborzecki> tests unhappy again or something really broke? Remove data for snap "test-snapd-tools" (x1) (failed to remove snap "test-snapd-tools" base directory: remove /var/snap/test-snapd-tools: directory not empty)
[08:41] <pedronis> mborzecki: there was a change in that area:  273d4853d
[08:41] <zyga> mborzecki: it sounds like a known issue
[08:41] <zyga> mborzecki: chipaca and I discussed it about two weeks ago
[08:42] <zyga> mborzecki: rm -rf vs rmdir
[09:18] <Chipaca> so, turns out that having a snap confuse snapd with the assertions in a refresh is pretty bad
[09:18] <Chipaca> i now have a broken snap i can't remove :-|
[09:22]  * Chipaca encourages snapd to remove it
[09:48]  * pstolowski runs a quick errand
[09:58] <ogra> sil2100, the enw gadget is fine ... the user with the issue also confirmed he sees the missing interfaces now
[09:58] <sil2100> ogra: \o/
[09:59] <ogra> s/enw/new/ ... (tsk ... *glares at his fingers* )
[09:59] <sil2100> ogra: hm, crap, forgot to ask CE for validation, anyway, I'll make it move forward today
[09:59] <ogra> i guess the user is fine using edge for the moment, so i doubt there is any pressure
[10:05] <mup> PR snapd#6592 closed: cmd/snap-seccomp: version-info subcommand <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6592>
[10:17] <ogra> mvo, as a reminder ... https://bugs.launchpad.net/snapd/+bug/1820242
[10:17] <mup> Bug #1820242: snapfuse missing in core18 breaks snap installation in lxd containers <snapd:New> <https://launchpad.net/bugs/1820242>
[10:23] <pstolowski> re
[10:49] <mup> PR snapd#6605 opened: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
[11:01] <zyga> brb, coffee
[11:23]  * zyga really goes to grab that coffee now
[11:23] <cachio> niemeyer, hey, I yesterday pushed this one https://github.com/snapcore/spread/pull/75
[11:23] <mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
[11:30] <mborzecki> i've updated #6485, anyone who was involved in the review, please take a look
[11:30] <mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
[11:37] <niemeyer> cachio: Reviewed
[11:44] <cachio> niemeyer, thanks
[12:28] <Saviq> oSoMoN: hey, I've been trying to update the subsurface snap for new snapcraft (no remote bases) https://github.com/Subsurface-divelog/subsurface/compare/master...Saviq:update-snap-packaging - but the launcher doesn't seem to be setting the QML env... you seem to be somewhat active in that repo ;), any idea?
[12:28] <Saviq> `$ snap run --shell subsurface -c '$SNAP/bin/desktop-launch env' | grep QML` turns up empty
[12:29] <Saviq> ah I think I see the problem
[12:37] <mup> PR snapd#6606 opened: selinux, systemd: support mount contexts for snap images <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6606>
[12:37] <mborzecki> another selinux piece ^
[12:54] <mup> PR snapd#6607 opened: cmd: typedef mountinfo structures <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6607>
[13:02]  * zyga has a *wild* idea
[13:02] <zyga> **wild**
[13:24] <jdstrand> mborzecki: I know you're working on selinux support in snapd. I'm not sure of your grand plans but note there are *many* limitations to ultimately have an selinux backend that is equivalent to apparmor and it really isn't feasible. lsm stacking is the answer for strict snaps on selinux systems
[13:25] <jdstrand> mborzecki: that's been discussed elsewhere and a long time ago and not sure you were aware
[13:30] <jdstrand> that isn't to say it is impossible. but there would be a high up front and persistent maintenance cost
[13:32] <jdstrand> with stacking, that's all avoided (again, I'm talking about strict mode snaps, not targetted policy for snapd to run them (which, aiui, is what you're working on and good))
[13:33]  * jdstrand might be optimistic on 'not impossible'. there would need to be a lot of investigation
[13:34] <cachio> mvo, pedronis hey, do you know is anyone is looking at the error: task.go:337: DEBUG: 2019-03-15T10:29:19Z ERROR failed to remove snap "test-snapd-tools" base directory: remove /var/snap/test-snapd-tools: directory not empty?
[13:35] <pedronis> Chipaca: hi, zyga said you were looking into that area at some point ^
[13:35] <pedronis> also it's close to were you landed something recently
[13:36] <Chipaca> yes, i landed a fix for a cleanup that wasn't happening that would cause that
[13:36] <Chipaca> cachio: you'll have some random revision in /var/snap/test-snapd-tools, rm -r that revision, try the remove again, should work
[13:37] <cachio> Chipaca, it is failing on the master
[13:37] <cachio> on the travis executions
[13:37] <Chipaca> every time?
[13:37] <cachio> I saw many testa failing because of that
[13:37] <Chipaca> hmm
[13:37] <Chipaca> dunno then
[13:38] <cachio> Chipaca, https://api.travis-ci.org/v3/job/506691205/log.txt
[13:38] <Chipaca> more cleanup needed?
[13:38] <Chipaca> whoa
[13:38] <Chipaca> cachio: could the tar be wrong in some way?
[13:39] <Chipaca> anyway, I'll look
[13:39] <cachio> Chipaca, , not sure, It didnt change
[13:39] <cachio> I though it was related to the clean up changes
[13:39] <cachio> Chipaca, thanks
[13:41] <Chipaca> cachio: the cleanup changes should've made it not happen, not happen more :-)
[13:42] <cachio> Chipaca, :)
[13:44] <oSoMoN> Saviq, problem solved, then? (just back from lunch and seeing your messages)
[13:48] <Saviq> oSoMoN: yeah, would be solved even more if https://github.com/ubuntu/snapcraft-desktop-helpers/pull/177 was merged ;) can you review in helpers?
[13:48] <mup> PR ubuntu/snapcraft-desktop-helpers#177: [qt] fix prepend_dir usage <Created by Saviq> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/177>
[13:49] <oSoMoN> looking
[13:52] <oSoMoN> Saviq, that looks fine, I guess the gtk part of the helpers gets much more testing than its qt counterpart, which would explain why this slipped in
[13:54] <Saviq> indeed
[13:56] <mvo> cachio: I saw that error in some tests but it does not ring any bell
[13:56] <mborzecki> jdstrand: no worries, right now it's merely accounting for what snapd, s-c, s-u-n and s-d-n do so that they do not cause unnecessary selinux denials
[13:57] <mvo> cachio: we did get a new systemd recently though
[13:57] <mborzecki> jdstrand: similar thing for snaps with sevices, make sure that it's possible to start them without causing additional denials
[14:01] <mup> PR snapd#6608 opened: cmd/snap-confine: umount scratch dir using UMOUNT_NOFOLLOW <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6608>
[14:04] <jdstrand> mborzecki: yep, that's all good and thanks for doing that :) just wanted to make sure you got the memo on the other bits
[14:15] <dot-tobias> I'd like to put configuration in a gadget.yaml for a snap that I have not yet released on the store. I have its snap ID, but putting that in gadget.yaml seems to have no effect. The snap is included in ubuntu-image via --extra-snaps and installs fine, just no configuration applied. Also, connecting another snap to it does not do anything (nothing in snap tasks #id), so I suspect it's something with the ID. An idea, anyone?
[14:19] <mup> PR snapd#6609 opened: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>
[14:28] <Chipaca> dot-tobias: do you have the right id?
[14:51] <zyga> jdstrand: suse review is going forward, they will be looking at apparmor and snapd proper as well
[14:52] <zyga> jdstrand: I must say I'm very pleased with the outcome so far and with the interaction in particular
[14:52] <jdstrand> zyga: curious what they are looking at with apparmor; they have had it for years. I guess the policy
[14:53] <jdstrand> but regardless, cool and yes
[15:08] <zyga> jdstrand: yes, they are reviewing the policy
[15:11] <Chipaca> niemeyer: if you could find the time to read https://forum.snapcraft.io/t/use-of-markdown-in-snap-metadata-summary-description/2128/40 and comment there I'd appreciate it
[15:16] <niemeyer> Chipaca: Done
[15:16] <Chipaca> niemeyer: thank you
[15:23] <Chipaca> pedronis: http://paste.ubuntu.com/p/qKBpN4Zsjz/ fwiw
[15:28] <pedronis> Chipaca: it looks kind of what I would have expected
[15:28] <Chipaca> pedronis: I maintain that it works by magic and happy accident
[15:28] <Chipaca> but if you're happy with it until we refactor, ok
[15:28] <pedronis> Chipaca: we need store changes too, though?
[15:29] <Chipaca> pedronis: for the more limited retry strategy, yes?
[15:29] <pedronis> yes
[15:29] <Chipaca> pedronis: yes
[15:29] <Chipaca> but those don't scare me :-)
[15:29] <pedronis> ok
[15:29] <Chipaca> trying to repro https://api.travis-ci.org/v3/job/506691205/log.txt now though
[15:40]  * cachio lunch
[16:47] <mup> PR # closed: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433,
[16:47] <mup> snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#2502
[16:50] <mup> PR # opened: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433,
[16:50] <mup> snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#2502
[16:57] <Chipaca> off to the gym for me
[16:58] <Chipaca> happy EOW all (i'll bbl to see how spread is doing wrt repro'ing the thing)
[17:00] <zyga> jdstrand: super-low-hanging-fruit for EOW: https://github.com/snapcore/snapd/pull/6607
[17:00] <mup> PR #6607: cmd: typedef mountinfo structures <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6607>
[17:04] <mup> PR snapd#6610 opened: interfaces/builtin: add add exec "/" to docker-support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6610>
[17:13] <sil2100> mvo: hey! I'd need some super-powers to the cm3 and pi2 old core16 gadget snap github repos if you have a moment ;)
[17:15] <cjwatson> mvo: Hi - did you notice my comments on https://code.launchpad.net/~mvo/launchpad/add-cnf-metadata-to-release-file/+merge/343161 ?  They should be easy, and then I can land it
[17:17] <mvo> cjwatson: I missed those, looking now, thank you
[17:18] <mvo> sil2100: what do I need to do?
[17:21] <sil2100> mvo: we'd need foundations having super-power powers at https://github.com/snapcore/cm3-gadget and https://github.com/snapcore/pi2-gadget
[17:21] <mvo> sil2100: sure, on it
[17:22] <mvo> sil2100: please try now - ubuntu-foundations is now marked "admin" in both
[17:22] <sil2100> \o/
[17:23] <sil2100> I have power!
[17:42] <mup> PR snapd#6600 closed: timings: add new helpers, Measurer interface and DurationThreshold <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6600>
[17:56] <cachio> niemeyer, the PR https://github.com/snapcore/spread/pull/75 has been updated
[17:56] <mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
[17:56] <cachio> niemeyer, thanks for reviewing
[18:11] <cjwatson> mvo: Cheers.  Landing now
[18:34] <niemeyer> cachio: Responded
[18:36] <zyga> cachio: question about tumblweed, what happened so that that branch enabling it finally landed?
[18:40] <mvo> cjwatson: thank you
[18:40] <cachio> zyga, tumbleweed is being used currently
[18:40] <cachio> zyga, why?
[18:40] <cachio> niemeyer, thanks
[18:41] <zyga> cachio: yes, I noticed
[18:41] <zyga> cachio: the PR enabling it used to fail
[18:41] <zyga> cachio: so I wonder what changed
[18:44] <cachio> zyga, there was a problem with a dependency
[18:45] <cachio> zyga, which was fixed in the opensuse repo, so then I updated the image and everything worked again
[18:45] <zyga> nice
[18:45] <zyga> thank you
[18:45] <cachio> zyga, np
[19:01] <mvo> cjwatson: just saw the test failure in my LP branch, fixing it now
[19:02] <cachio> niemeyer, hey, about the change I did for the residue test
[19:02] <cachio> niemeyer, do you think it is better to add it in a different PR?
[19:03] <cachio> niemeyer, I added that to have 100% test passing
[19:03] <cachio> otherwise we will see 1 error
[19:03] <niemeyer> cachio: More generically, it's never a good idea to pack side changes that are completely unrelated to the stated purposed for the PR
[19:03] <niemeyer> cachio: Ah, interesting
[19:04] <niemeyer> cachio: So it is related to making tests pass.. it doesn't look like so
[19:04] <niemeyer> cachio: Why is the change necessary?
[19:04] <cachio> niemeyer, when I added the repeat option for spread I broke this test
[19:04] <niemeyer> cachio: When you added that option where?
[19:04] <cachio> niemeyer, so, residue is not working in case hte test fails
[19:05] <cachio> niemeyer, in spread code
[19:05] <cachio> niemeyer, long time ago
[19:05] <niemeyer> cachio: Sorry, I don't get
[19:05] <mvo> cjwatson: https://code.launchpad.net/~mvo/launchpad/add-cnf-metadata-to-release-file/+merge/364599 <- sorry again for not spotting this earlier
[19:05] <cachio> niemeyer, I added a options to be able to do > spread -repeat 10
[19:05] <niemeyer> cachio: Yeah, ok
[19:06] <niemeyer> cachio: And..?
[19:06] <cachio> niemeyer, so the residue test it is broken since that time
[19:07] <niemeyer> cachio: The residue test always fails then?
[19:07] <cachio> niemeyer, yes
[19:07] <cachio> niemeyer, this change fixes the problem
[19:09] <niemeyer> cachio: I see.. do we have a test exercising residue with repeat at the same time?
[19:09] <cachio> niemeyer, no
[19:10] <cachio> niemeyer, the residue test checks spread leave residue in 2 scenarios
[19:10] <cachio> niemeyer, 1 when the test pass
[19:10] <cachio> niemeyer, 2. when the test fails
[19:11] <cachio> niemeyer, so the residue test is failing in the second scenario/part
[19:11] <niemeyer> cachio: Cool, thanks for the explanation.. sounds good
[19:11] <cachio> niemeyer, nice
[19:12] <cachio> niemeyer, perfect I'll retest the cache system and leave a message in the PR
[19:12] <cachio> thanks for reviewing
[19:13] <niemeyer> cachio: Thank you!
[19:13] <yotux> Can someone explain why an app has multiple loops directorys
[19:44] <cjwatson> mvo: Heh, wonder why I missed that.  Landing, thanks
[19:53] <yotux> I found the answer to my question sorry its like pacman has 3 versions
[20:05] <mup> PR snapcraft#2473 closed: plugins: improve python and go schema validation <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2473>
[20:20] <kjackal> Hey snappy people, there is this TGI Kubernetes right now https://www.youtube.com/watch?v=3Px-kbcIaVE . They are going to deploy MicroK8s snap on arch, centos etc. It might be good feedback for snaps
[20:21] <kjackal> plus you may be able to help in case some distros do not work
[21:18] <Chipaca> kjackal: thanks for the heads up
[21:18] <Chipaca> it's being fun
[21:23] <kjackal> thanks people
[21:30] <cjwatson> mvo: Don't worry about the next failure - transient glitch, I'll retry until it works
[21:32] <Chipaca> ok, have great weekends people
[21:32]  * Chipaca EOWs
[21:41] <mvo> cjwatson: thank you!
[21:42]  * mvo calls it a day
[21:44] <mup> PR snapcraft#2503 opened: cli: disable raven if not running from package <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2503>
[22:29] <mup> PR snapcraft#2502 closed: meta: fix management of snap/local <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2502>