[02:10] <mup> PR snapcraft#2418 closed: Release changelog for 3.0.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2418>
[06:11] <mborzecki> morning
[06:27] <zyga> Hi
[06:57] <mborzecki> zyga: hey
[07:07] <zyga> Hej
[07:07] <zyga> Breakfasting
[07:07] <zyga> I sent a PR last night
[07:08] <zyga> Fixing leap issues
[07:08] <zyga> I will make a small variant for 2.36
[07:46] <mvo> good morning! it looks like the tests in 6243 got restarted, did we see any trace of the protocol error in the last run?
[07:48] <mvo> looks like the current run was good, I do another one now
[07:50] <mborzecki> mvo: i restarted them twice already, first time failed in prepare of juju observe test (unrelated), next failure was centos mirrors being flaky
[07:51] <mvo> mborzecki: heh
[07:51] <mvo> mborzecki: ok, it had one green now and I just triggered it again (via rename of GIL->GML)
[07:57] <mborzecki> super simple review #6241
[07:57] <mup> PR #6241: tests/main/parallel-install-store: verify installation of more than one instance at a time <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6241>
[07:58] <pstolowski> mornings
[08:01] <zyga> Back from walk
[08:01] <zyga> Brrrr
[08:01] <zyga> Though I really like it when winter makes everything dry
[08:02] <zyga> Hey mvo
[08:02] <zyga> I will be around shortly
[08:03] <mvo> zyga: hey, no worries
[08:03] <mvo> zyga: all is looking great, I'm in a very good mood, PRs look super interessting
[08:03] <zyga> I posted the leap fix last night
[08:03] <zyga> Just the master version
[08:04] <zyga> 2.36 will be microscopic
[08:04] <zyga> Master has a cleanup as well
[08:04] <mvo> zyga: aha, even better
[08:28] <pedronis> mborzecki: I put a question in #6079
[08:28] <mup> PR #6079: [RFC] `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
[08:29] <mup> PR snapd#6234 closed: overlord: don't write system key if security setup fails (2.36) <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6234>
[08:33] <mborzecki> pedronis: thanks, finishing up with snapd update for arch now, will lack at your review in a bit
[08:41] <mup> PR snapd#6221 closed: interfaces: return security setup errors (2.36) <⛔ Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6221>
[08:46] <zyga> mvo: https://github.com/snapcore/snapd/pull/6245
[08:46] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[08:46] <zyga> it won't pass entirely
[08:47] <zyga> after that there will be only one small patch that makes apparmor-parser errors really reported and 2.36 is green
[08:47] <zyga> similar to the one you closed above in 6221
[08:47] <mup> PR snapd#6245 opened: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[08:47] <zyga> if you want I can add it here
[08:50] <pstolowski> mvo: that case you found with brave install & removal sequence is amazing; it really has to involve all the three ops, just installing the instance and removing it (2 ops) is not enough
[08:55] <mvo> pstolowski: yeah, I found this too, its interessting
[08:56] <mvo> zyga: it sounds like like it can be added to 6245 if its small
[08:56] <zyga> mvo: yes, and one will not pass without the other
[08:56] <zyga> I'll do just that
[08:56] <zyga> mvo: thank you for merging the 2.36 fix even though it was not passing
[08:57] <zyga> pstolowski, mvo: what's the special case with brave?
[08:57] <pstolowski> zyga: sudo snap install brave && sudo snap install brave_test && sudo snap remove brave brave_test
[08:57] <pstolowski> zyga: (with instances feature on)
[08:57] <zyga> mhm
[08:57] <pedronis> pstolowski: hi, do we have developer docs for interface hooks?
[08:58] <pstolowski> zyga: results in a bunch of conflicts and retries on the last step, take a good while to finish
[08:58] <pedronis> pstolowski: conflicts on what?
[08:59] <pstolowski> pedronis: yes, they were written a couple of weeks ago
[08:59] <pstolowski> pedronis: conflicts on disconnects on removal (last op)
[08:59] <pedronis> I see
[09:00] <pedronis> pstolowski: I suppose at this point they are expected, no? we'll need to step back to improve that? or is there a low hanging fruit?
[09:01] <pstolowski> pedronis: yes, we expect it, but mvo observed a noticable slowdown with edge (which i can confirm)
[09:02] <pedronis> ok
[09:02] <pstolowski> pedronis: it was noticed ~last week
[09:02] <pstolowski> pedronis: and again, it completes and work, is just slow
[09:03] <pedronis> pstolowski: any candidate on why? feel free to dig a bit when you have a bit of time
[09:05] <pstolowski> pedronis: yeah i'm on, investigating, don't know yet
[09:10] <mborzecki> hmm no smart way of reloading snap-confine aa profile on arch when installing/updating snapd, i expect people to run into problems with snap-confine
[09:10] <zyga> oh
[09:10] <zyga> can we do that ourselves?
[09:10] <zyga> in the package file?
[09:11] <mborzecki> zyga: i can, but it's unclear whether i should, you know, the unwritten policy of doing nothing :)
[09:11] <zyga> hehe
[09:11] <zyga> does that also apply to libc breaking people on upgrades?
[09:11] <zyga> is there any limit?
[09:11] <mborzecki> hahah, it's /r/archlinux, or bbs.archlinux.org or just archlinux.org main page with 'manual steps needed' memo
[09:12] <zyga>  /o\
[09:12] <mborzecki> though i don't recall any major screwups for years now
[09:12]  * zyga is happy with opensuse :)
[09:13] <mborzecki> i mean, surprisingly, it just works
[09:19] <mborzecki> does it make sense to request snapd restart on a classic system where reexec is not supported?
[09:19] <zyga> mmm
[09:20] <zyga> probably not
[09:20] <mborzecki> that's what happens on arch, fedora and prooably opensuse too
[09:21] <zyga> morning Chipaca
[09:21] <Chipaca> morning
[09:21] <mborzecki> this basically https://paste.ubuntu.com/p/xRnrQMNTH8/
[09:21] <mborzecki> Chipaca: morning, sir
[09:21] <pedronis> Chipaca: hi
[09:22] <Chipaca> 'sup
[09:24] <pedronis> mborzecki: hi, you have various things under review, but no current task that isn't blocked on feedback? is that true?
[09:26] <mborzecki> pedronis: i'm addressing feedback on the PRs and chopping selinux branch up to pull out the bits that aren't strictly related (mostly tests)
[09:27] <pedronis> mborzecki: ah ok, so you are not blocked atm?
[09:27] <pedronis> Chipaca: did you see https://github.com/snapcore/snapd/pull/6236#discussion_r237451827 ?
[09:27] <mup> PR #6236: Staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6236>
[09:27] <mborzecki> pedronis: no
[09:27] <Chipaca> pedronis: I did
[09:27] <Chipaca> I'm assuming it's technically correct
[09:28] <Chipaca> in practice, not sure how important it is :-)
[09:30] <pedronis> Chipaca: ?
[09:30]  * pedronis is probably missing something
[09:30] <Chipaca> pedronis: the current regep means we won't run staticcheck on ".0" releases
[09:31] <Chipaca> because go doesn't do .0, instead just does ""
[09:31] <Chipaca> apparently
[09:31] <pedronis> Chipaca: not sure why you say is not important? having a test that doesn't run for a while
[09:31] <pedronis> and then again
[09:32] <pedronis> is usually source of confusion
[09:32] <pedronis> of which if have enough I think
[09:32] <pedronis> s/if/we/
[09:33] <pedronis> Chipaca: or you thinking that .0 never makes it into Ubuntu anyway?
[09:33] <Chipaca> I'll fix it (not that way though)
[09:33] <pedronis> anyway changing it is likely quicker than this silly discussion :)
[09:33] <Chipaca> but, i'm worried that already 1.11 is breaking things for us
[09:34] <Chipaca> wonder what 1.12 will bring
[09:34] <Chipaca> and then there's go 2
[09:34] <pedronis> one thing at a time
[09:35] <Chipaca> pedronis: did you see"go 2 considered harmful"?
[09:35] <Chipaca> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
[09:35]  * Chipaca grins
[09:36] <pedronis> no
[09:36] <zyga> lol
[09:37] <Chipaca> changing subjects, I pushed a little "make snapd start faster" pr after talking with cachio yesterday
[09:37] <Chipaca> and mvo fixed the spread tests (thanks mvo!)
[09:37] <Chipaca> and now it's so fast, systemd freaks out :-/
[09:38] <pedronis> I saw it
[09:38] <pedronis> ah
[09:38] <Chipaca> :-)
[09:38] <pedronis> no good deed goes unpunished
[09:38] <Chipaca> bah, it might be something else
[09:38] <Chipaca> i need to dig
[09:38] <Chipaca> but
[09:38] <Chipaca> Job for snapd.service failed because start of the service was attempted too often. See "systemctl status snapd.service" and "journalctl -xe" for details.
[09:38] <Chipaca> that thing :)
[09:38] <pedronis> Chipaca: let's try to merge 6192 first
[09:38] <Chipaca> ok
[09:39]  * Chipaca looks at what's missing there
[09:39] <pedronis> couple of minors there, and it needs a 2nd review (I cannot review twice)
[09:44] <Chipaca> pedronis: looking at the revision of the local snap would split error messages even more though
[09:44] <Chipaca> i mean, either snap could be local
[09:47]  * Chipaca gives it a stab
[09:47] <pedronis> Chipaca: ?
[09:47] <Chipaca> pedronis: your suggestion to, in the local case, say "current local"
[09:47] <pedronis> yes
[09:47] <Chipaca> pedronis: is about the current snap
[09:48] <Chipaca> pedronis: the revision we talk about in the error messages so far is about the new snap
[09:48] <Saviq> cachio: oh seems it worked this time: https://travis-ci.org/MirServer/mir/jobs/461685223
[09:48] <pedronis> Chipaca: let me look
[09:48] <pedronis> I might be very confused
[09:49] <Chipaca> pedronis: unless you meant to always say "current local", as in that-which-is-locally-current
[09:49] <Chipaca> and not as in that-which-is-locally-current-and-has-a-revision-that-is-local
[09:50] <pedronis> Chipaca: I see, I'm confused
[09:50] <pedronis> but something is off either way
[09:50] <Chipaca> hello confused i'm dad
[09:51] <pedronis> Chipaca: so we are looking at snapInfo revision
[09:51] <pedronis> great
[09:51] <pedronis> except that calling a local installed snap new revision in the 2nd message
[09:51] <Chipaca> i could've caled them newInfo and curInfo instead of snapInfo and curInfo  i guess
[09:51] <pedronis> is confusing and what threw me off
[09:52]  * Chipaca looks
[09:52] <pedronis> Chipaca: if I do snap install --dangerous foo.snap
[09:52] <pedronis> calling the incoming thing new revision
[09:52] <pedronis> is confusing
[09:52] <Chipaca> aha
[09:52] <pedronis> (tough technically correct)
[09:52] <Chipaca> i'll happily drop in any other noun :-)
[09:53] <Chipaca> I might even drop in a verb if i'm in a hurry
[09:54] <Chipaca> pedronis: I mean: «cannot refresh "foo" because [this new thing]  has epoch 123 that can't read [the old thing]'s epoch of 0»
[09:55] <pedronis> Chipaca: "new epoch %s being locally installed"  would be the verbose thing
[09:57] <Chipaca> «cannot refresh "foo" because new epoch 123 being locally installed can't read [...]»?
[09:57] <pedronis> yes
[09:57] <Chipaca> that's confusing to read
[09:57] <pedronis> I'm happy to suggestion, the current error confused me though, so we need to do better
[09:58] <Chipaca> so, it can be a try or a --dangerous
[09:58] <pedronis> yes
[09:59] <pedronis> cannot refresh "foo" with local snap because its epoch ...?
[10:00] <Chipaca> «cannot refresh "foo" because the one you're trying to install has epoch [...]»
[10:00] <Chipaca> ?
[10:00] <Chipaca> hm
[10:01] <pedronis> cannot refresh "foo" with local snap with epoch %s ... ?
[10:01] <Chipaca> cannto refresh "foo" to local snap with epoch...?
[10:02] <pedronis> that also work
[10:02] <pedronis> s
[10:02] <Chipaca> good, let me write it out in full just in case
[10:03] <Chipaca> cannot refresh %q to local snap with epoch %s, because that can't read current revision's epoch of %s
[10:03] <Chipaca> or maybe change the that to an it
[10:03] <Chipaca> cannot refresh %q to local snap with epoch %s, because it can't read current revision's epoch of %s
[10:03] <Chipaca> bah, that "revision's" there is noise
[10:03] <Chipaca> noise][1: no offence
[10:04] <pedronis> can be dropped I suppose
[10:04] <Chipaca> cannot refresh %q to local snap with epoch %s, because it can't read the current epoch of %s
[10:04] <mborzecki> snap install hello-world does-not-exist, giving 'error: store.SnapNotFound with 2 snaps' is not super user friendly
[10:04] <pedronis> mborzecki: my PR will fix it
[10:04] <mborzecki> pedronis: ack
[10:04] <Chipaca> mborzecki: i disagree, it's super friendly. You're just not its friend.
[10:04] <pedronis> I'm actually hoping to get to it today
[10:06] <mborzecki> Chipaca: hehe :P didn't bother me until yesterday i didn't notice a typo in snap name i tried to install and ended up going through snapd code to figure it out
[10:07] <Chipaca> mborzecki: tbf that error means there's a bug, it's meant as an error for us and not for users
[10:08] <mborzecki> we're lucky then that users install snaps one by one
[10:08] <mborzecki> but it did give me a bit of panic yesterday when 'snap install hello-world_foo hell-world_bar' didn't work :/
[10:09] <pedronis> Chipaca: there's two part of the code that make different assumptions, anyway #5712 should stop that afaiu
[10:09] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Reviewed> <⛔ Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[10:09] <Chipaca> pedronis: 🖒
[10:14] <pedronis> Chipaca: we probably should drop revision's alos in the other one, current epoch alone seems ok, no?
[10:15] <Chipaca> pedronis: heh
[10:15] <pedronis> given also that it might be local or not in its own
[10:15] <Chipaca> 	return fmt.Errorf("cannot refresh %q to %s with epoch %s, because it can't read the current epoch of %s", snapInfo.InstanceName(), desc, snapInfo.Epoch, curInfo.Epoch)
[10:15] <Chipaca> ^ current code
[10:15] <Chipaca> where desc is "local snap" or "new revision %s"
[10:15] <pedronis> sounds good
[10:16] <pedronis> Chipaca: we get the {}  notation right if the epoch is complicated ?
[10:16] <Chipaca> yes
[10:17] <pedronis> that's fine for now
[10:17] <pstolowski> mvo, pedronis ok, i understood the problem with slowness on brave+brave_test install+remove. perhaps HO would be fastest to explain if you have a few minutes
[10:17] <Chipaca> for now it's the json one
[10:17] <Chipaca> although from using it, just {[],[]} might be enough
[10:18] <Chipaca> (as opposed to {"read":[],"write":[]} )
[10:18] <pedronis> pstolowski: I'm available in a couple of minutes
[10:19] <pstolowski> pedronis: ok, ping me then (mvo feel free to skip it)
[10:22] <Chipaca> silly Go, not telling that when I write lcoal I mean local
[10:23] <pedronis> pstolowski: ready now, in the standup
[10:23] <pstolowski> pedronis: ok coming
[10:24] <mborzecki> another thing we maybe could improve, when installing a snap that pulls in a content snap, the prompt will stay on 'Automatically connect eligible ..' for a long time, while the content snap is downloading
[10:45] <zyga> mvo: https://github.com/snapcore/snapd/pull/6245 needs a review
[10:45] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[11:03] <zyga> pstolowski: reading https://github.com/snapcore/snapd/pull/6180
[11:03] <mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
[11:04] <pstolowski> zyga: thanks!
[11:08] <pedronis> mvo: zyga: Chipaca: I'll be late for standup, I posted a forum message to the team about this
[11:08] <zyga> thank you
[11:09] <mvo> pedronis: thank you
[11:09] <mvo> pstolowski: sorry, was away but I take it you clarified this?
[11:10] <pstolowski> mvo: yep, no worries
[11:10] <mvo> zyga: I do a new round of review now
[11:10] <zyga> thank you
[11:10] <Chipaca> the local authority has finally (nearly 12 months later!) come to a decision about the boys' school \o/
[11:10] <zyga> I'm not feeling well, sorry about being very slow today
[11:10] <Chipaca> … so I might miss the standup entirely today
[11:10] <mvo> zyga: no worries
[11:10]  * Chipaca hugs zyga 
[11:10] <mvo> Chipaca: good news! (about the boys - not that you miss the standup ;)
[11:10] <Chipaca> but … from far away just in case it's cooties
[11:11]  * mvo hugs zyga as well
[11:11] <zyga> just cold, nothing fancy :)
[11:11] <zyga> I'll be allright
[11:11] <pedronis> Chipaca: ok
[11:13] <pstolowski> pedronis: retry mechanism seems to work *most of the time*, but there is something fishy there, *sometimes* it doesn't pick any other task until retry time of previous one is reached - see the proof with some extra debug https://pastebin.ubuntu.com/p/TYMffsdTQX/
[11:15] <cachio> Chipaca, nice, I'll try it
[11:15] <cachio> thanks
[11:16] <cachio> Saviq, nice
[11:16] <cachio> please let me know if we need any change to that image
[11:17] <pedronis> pstolowski: that seems strange, we are missing something, I suppose some prints in the taskrunner might help
[11:18] <cachio> Chipaca, which is the PR number?
[11:18] <pedronis> #6192  needs a 2nd review
[11:18] <mup> PR #6192: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
[11:18] <pstolowski> pedronis: yep
[11:19] <Chipaca> cachio: #6242
[11:19] <mup> PR #6242: overlord/snapstate: use file timestamp to initialize timer <Created by chipaca> <https://github.com/snapcore/snapd/pull/6242>
[11:19] <pedronis> degville: might you could look quickly at the new errors in #6192, if you have some feedback on them
[11:20] <pedronis> notice that in most sitation the store should avoid us hitting them tough
[11:20] <pedronis> they are more relevant for local development using try or local installs
[11:20] <mborzecki> zyga: did you mean to open #6245 with target set to release/2.36? it's targeting master now
[11:20] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[11:20] <zyga> ooh
[11:20] <zyga> shit :)
[11:20] <zyga> yes
[11:21] <zyga> fixed
[11:21] <zyga> this version is for the stable release
[11:21] <zyga> I was surprised it passed alone
[11:21] <mvo> heh, same here
[11:21] <mvo> (also surprised)
[11:22] <pedronis> degville: thanks for https://forum.snapcraft.io/t/the-docs-roadmap/8763
[11:22] <Chipaca> cachio: the problem is nfs-support restarts snapd 11 times :-)
[11:22] <Chipaca> cachio: and it's fast enough for that to be a problem now
[11:22] <Chipaca> cachio: I'm fixing
[11:23] <cachio> Chipaca, nice, thanks for that !!!
[11:24] <mvo> 5845 is ready for a second review
[11:24] <degville> no problem.
[11:24]  * pedronis can't type today
[11:26] <mup> PR snapd#6241 closed: tests/main/parallel-install-store: verify installation of more than one instance at a time <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6241>
[11:28] <mborzecki> mup: kicked off another spread run in #6243
[11:28] <mup> mborzecki: In-com-pre-hen-si-ble-ness.
[11:28] <mborzecki> mvp: kicked off another spread run in #6243
[11:28] <mborzecki> mvo: kicked off another spread run in #6243
[11:28] <mup> PR #6243: systemd: allow only a single daemon-reload at the same time <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6243>
[11:29] <mvo> mborzecki: thanks, I run this now also locally against google:ubuntu-18.04-64, so far no issues, lets see
[11:31] <Chipaca> actually, i wonder if systemd seeing the restarts as problematic are because we don't exit from the main loop properly
[11:31]  * Chipaca digs
[11:32] <Chipaca> could I get a second review of #6236? it's got a minor fix pending (in a Suggestion already) but I'd rather not re-trigger a travis just for that unless it's the only thing left
[11:32] <mup> PR #6236: Staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6236>
[11:32] <Chipaca> jamesh: I am keeping your user session pr in mind, have not finished the review yet though
[11:32] <mvo> Chipaca: I have it on my list, hope to get to it before lunch
[11:33] <Chipaca> mvo: excellent thanks
[11:41] <zyga> mvo: https://github.com/snapcore/snapd/pull/6245 is green!
[11:41] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[11:41] <zyga> that's lucky
[11:52] <Chipaca> mvo: looks like we dropped the ball on https://forum.snapcraft.io/t/anything-changed-around-snapcraft-yaml-gpio-interface-for-2-36/7852/4 (unless there was more communication out of band)
[11:54] <zyga> moar fire
[11:55] <Chipaca> toasty
[11:56] <zyga> pretty please review on 6245
[11:56] <Chipaca> sir yes sir
[11:57] <zyga> thank you, that's almost all needed to make 2.36 green again
[11:57] <mvo> Chipaca: I think we fixed this but we did not communicate this well :(/
[11:57] <mvo> Chipaca: I need to look what PR fixed it, don't quite remember offhand
[11:57] <zyga> mvo: is is in 2.36.x ?
[11:57] <jamesh> Chipaca: thanks.
[11:57] <zyga> maybe we need a .3
[11:57] <mvo> zyga: I think so
[11:57] <mvo> zyga: oh, why .3? what is missing?
[11:57] <zyga> I mean, if this is not in stable
[11:57] <zyga> but in 2.37 / beta only
[11:58] <zyga> but no need otherwise
[11:58] <Chipaca> don't propose a new .X on the eve of a sprint dude, that's just mean
[11:58] <Chipaca> you need to do it the monday of the sprint and write a CVE, that's the sporting way
[11:58] <mvo> Chipaca: *wahhhhh*
[11:58]  * mvo runs away screaming
[11:58] <zyga> HAHHAHA
[11:59]  * Chipaca 's job is done
[11:59] <zyga> Chipaca: make sure to msg mvo on his cell at 23:00 on sunday ;)
[11:59] <zyga> PLANES FALLING OFF THE SKY, NEED .3
[12:01] <mvo> zyga: you guys are so mean!
[12:01] <zyga> mvo: we will attach patches :) that's foss spirit, right?
[12:01]  * zyga hugs mvo
[12:01] <mvo> lol
[12:01]  * mvo hugs zyga 
[12:01] <zyga> no worries, we will wait until after breakfast
[12:05] <zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6244
[12:05] <mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
[12:13] <mup> PR snapd#6246 opened: spread: show AVC audits when debugging, start auditd on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6246>
[12:15] <mup> PR snapd#6247 opened: tests/lib: do not pick up xatts when repacking core snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6247>
[12:16] <pedronis> mborzecki: ^ don't we have xattrs that we care about in core tough?
[12:17] <mborzecki> pedronis: afaik not yet
[12:17] <zyga> pedronis: not that I know of, ubuntu will enable xattrs but it's not done yet
[12:17] <pedronis> still is that change just exchaing a bug for another later?
[12:17] <zyga> heh, in some way yes
[12:18] <zyga> but xattrs will not show up by accident
[12:18] <zyga> and I think we will have some changes around snapd too
[12:18] <pedronis> we are not the one adding them, though? are we
[12:18] <pedronis> ?
[12:18] <zyga> sorry?
[12:18] <pedronis> zyga: I mean,  it depends on what you mean by accident,
[12:19] <pedronis> other teams doing things without telling can be considered an "accident"
[12:19] <pedronis> mborzecki: can we add some code to detect if there's xattrs that are not selinux related around?
[12:19] <zyga> I meant that there will be coordination and I expect things will fail if we rip them out in some tests. programs that were setuid root will require on capabilities instead
[12:20] <pedronis> zyga: you are an optimistic
[12:20] <mborzecki> pedronis: i'll think about it, with the context applied via mount that change may not be needed at all
[12:20] <pedronis> thx
[12:21] <mborzecki> otherwise a way of doing this without adding selinux context would be nice, but not sure if that's entirely possible when we repack the snap
[12:24] <pedronis> mborzecki: is there no utility to run something controlling the context?
[12:24] <pedronis> anyway I let you look into this further
[12:31] <mup> PR snapd#6248 opened: tests/lib/reset: restore context of removed snapd directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6248>
[12:34] <mup> PR snapd#6237 closed: client, store: don't use store from client (use client from store) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6237>
[12:53] <jdstrand> zyga: hey, curious, does leap run on arm?
[12:53] <zyga> jdstrand: hey
[12:53] <zyga> yes, I think there were some pi3 announcements by suse
[12:54] <zyga> https://en.opensuse.org/HCL:Raspberry_Pi3
[12:54] <zyga> I haven't tried myself
[12:54] <zyga> why? :)
[12:54] <zyga> jdstrand: FYI, I sent some patches that disable apparmor on 43.3 because apparmor_parser 2.10.3 doesn't parse our profiles
[12:55] <jdstrand> zyga: it is because of your fyi :)
[12:55] <zyga> haha
[12:55] <zyga> I see
[12:55] <zyga> :)
[12:55] <zyga> can you expand, I don't yet see a correlation between leap and arm
[12:56] <zyga> Chipaca: https://github.com/Juniper/libxo
[12:56] <zyga> remember the topic about snap foo --json
[12:56] <zyga> and friends?
[12:56] <jdstrand> zyga: you surely recollected that we added conditional support for unsafe in classic and there is https://github.com/snapcore/snapd/pull/5982
[12:56] <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
[12:56] <zyga> yes
[12:56] <zyga> but to interfaces
[12:57] <jdstrand> yes
[12:57] <zyga> snap-confine's own profile goes down in flames
[12:57] <zyga> we just never noticed
[12:57] <jdstrand> I know
[12:57] <zyga> until all hell broke loose
[12:57] <jdstrand> again, I read the pr
[12:57] <jdstrand> so I was thinking "should we even consider conditionally adding unsafe to the snap-confine profile?"
[12:58] <jdstrand> then I reread why we added it: https://github.com/snapcore/snap-confine/pull/133
[12:58] <mup> PR snap-confine#133: Adjust apparmor policy for compatibility with snap-exec <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/133>
[12:58] <zyga> 42.3 will be EOL in june next year
[12:58] <jdstrand> we added it for arm
[12:59] <jdstrand> so if arm is on leap, and we conditionally added it, the on arm leap would break
[12:59] <jdstrand> or rather, if leap is on arm
[13:00] <zyga> hmm, I don't recall the whole arm / leap part of the branch
[13:00] <jdstrand> so the answer is "no, we need to unconditionally add it"
[13:00] <zyga> ah
[13:00] <jdstrand> zyga: that branch wasn't done for leap
[13:00] <jdstrand> the branch was done to fix snapd on arm at all
[13:01] <zyga> ok, I read the patch again, I see what that was about
[13:01] <zyga> now back to the current patches
[13:01] <jdstrand> point is, if we decided to conditionally add unsafe to the snap-confine profile, then wherever we didn't add it, arm would be broken. that's silly
[13:01] <mborzecki> off to pick up the kids
[13:02] <zyga> jdstrand: where are we doing this conditionally? I must be missing something
[13:03] <jdstrand> zyga: huh? the interfaces
[13:03] <zyga> jdstrand: are you talking about the current set of patches?
[13:03] <zyga> jdstrand: ah. sorry, too many patches
[13:03] <zyga> so
[13:03] <zyga> there are two cases of broken
[13:03] <zyga> one was louder than another
[13:03] <jdstrand> zyga: I think you may be reading this irc conversation too quickly
[13:03] <zyga> we ignored some errors so the snap-confine profile being broken was below the radar for a long time
[13:03] <jdstrand> 06:57 < jdstrand> again, I read the pr
[13:03] <jdstrand> 06:57 < jdstrand> so I was thinking "should we even consider conditionally
[13:03] <jdstrand>                   adding unsafe to the snap-confine profile?"
[13:03] <zyga> but interfaces were
[13:03] <zyga> aha
[13:03] <zyga> I see
[13:04] <jdstrand> zyga: I asked you about arm on leap to answer my question that was in my head
[13:04] <zyga> thank you for explaining
[13:04] <zyga> so, we can do that in 2.37, I don't mind doing that
[13:04] <jdstrand> zyga: the pr is doing the right thing
[13:04] <zyga> we'd just have to check
[13:04] <zyga> (on a real board)
[13:04] <jdstrand> (in principle)
[13:05]  * jdstrand hasn't reviewed the code
[13:06] <zyga> jdstrand: note that there are two versions
[13:06] <jdstrand> zyga: are you planning a followup pr to clean up the classic template's conditional use of unsafe?
[13:06] <zyga> https://github.com/snapcore/snapd/pull/6245/files is super short for 2.36
[13:06] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[13:06] <jdstrand> zyga: I saw
[13:06] <zyga> I can do that, yeah
[13:06] <zyga> I didn't connect that dot last night
[13:06] <jdstrand> zyga: yeah, well, I didn't connect the dots with the snap-confine profile when doing the classic template pr
[13:07] <zyga> in hindsight logging errors and carrying on was a costly thing :)
[13:07] <jdstrand> zyga: when these land, I'll update that open docker-support pr
[13:07] <zyga> jdstrand: did you see https://github.com/snapcore/snapd/pull/6233
[13:07] <mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6233>
[13:08] <jdstrand> no
[13:08] <zyga> that took some time to track down
[13:08] <zyga> it was breaking 2.36 for all last week and this week
[13:09] <jdstrand> I need to read that carefully-- my first question is 'why is snapd restarting when snap-seccomp and apparmor_parser are running?
[13:09] <jdstrand> '
[13:09] <zyga> jdstrand: it is done in test prep
[13:09] <zyga> that's actually the only thing we don't have a 100% firm answer
[13:09] <zyga> as in
[13:10] <zyga> to be precise
[13:10] <zyga> why snapd is being restarted while those things are in flight
[13:10] <jdstrand> exactly
[13:10] <zyga> since we use sd_notify to tell systemd we are ready only after the managers have been constructed
[13:10] <zyga> one possible explanation
[13:11] <jdstrand> that sounds... weird and probably worth knowing cause there might be other bugs that are caused by this
[13:11] <zyga> is that overlord is indeed done but this is a part of some ensure cycle
[13:11] <zyga> (so normal activity)
[13:11] <zyga> I pasted traces
[13:11] <zyga> and there's a PR that can show you all the data in one spot
[13:11] <zyga> (closed now, I can revive it)
[13:11] <jdstrand> that 'weird' comment was for your 'why snapd is being restarted while those things are in flight' comment, not your sd_notify idea
[13:11] <zyga> yes
[13:12] <zyga> so we have journald/strace/forkstat and snap changes
[13:12] <zyga> I would love if someone had a deeper look at this
[13:12] <zyga> I feel tired after fighting 2.36 issues this week
[13:12] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/6230
[13:12] <mup> PR #6230: spread: detect "signal: terminated" in journal logs <⛔ Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6230>
[13:12] <zyga> the PR name is stale, it became a box of experiments
[13:13] <zyga> I can find the seed that reproduces the problem
[13:13] <pedronis> jdstrand: to be clear, this is in tests, there is quite a bit of manual restarting of snapd going on
[13:13] <zyga> though honestly any run on that branch will fail quickly
[13:14] <jdstrand> zyga: did you consider trapping the signal and waiting to stop til it was safe?
[13:14] <zyga> jdstrand: it's not our side that can trap
[13:14] <zyga> I mean, we'd have to change apparmor parser
[13:14] <pedronis> jdstrand: this is killing the helpers
[13:14] <zyga> systemd looks at the whole cgroup
[13:14] <pedronis> not snapd
[13:14] <zyga> and kills one by one
[13:14] <pedronis> anyway  we had a different solution as well
[13:14] <zyga> yes, mvo sent a PR with KillMode=process
[13:14] <zyga> though it was not merged
[13:15] <pedronis> it's not useful for non reexcing
[13:15] <jdstrand> zyga: well... snapd is calling the parser. if systemd tells us to stop and parser didn't complete...
[13:15] <pedronis> sorry, it's not useful for distros that don't update
[13:15] <zyga> jdstrand: systemd is killing both us and the parser and snap-confine
[13:15] <pedronis> but it would be cleaner
[13:15] <jdstrand> oh, I see
[13:15] <jdstrand> is that configurable in the systemd unit?
[13:15] <zyga> every process is
[13:15] <zyga> yes
[13:15] <pedronis> mvo: why did we close the KillMode change ?
[13:16] <jdstrand> I mean, sure, this may happen regularly in the tests, but maybe it happens legitimately somewhere
[13:16] <zyga> pedronis: I believe we could do both actually, it seems saner for kill mode to be process for snapd
[13:16] <pedronis> zyga: yes, my point
[13:16] <jdstrand> I don't know when that would be-- an admin restarting it? a deb upgrade?
[13:16] <zyga> but it doesn't fix reexecing cases
[13:16] <pedronis> I know
[13:16] <pedronis> but it gives us a saner future
[13:17] <zyga> yes
[13:17] <pedronis> (theoretically)
[13:17] <jdstrand> it seems rather harsh for systemd to just kill everything in the cgroup without given the parent a chance to cleanup
[13:18] <zyga> jdstrand: that's the default :)
[13:18] <zyga> but in hindsight I agree
[13:18] <pedronis> jdstrand: well, indeed there are ways to control that, it's the default tough as zyga said
[13:19] <jdstrand> there is no timeout associated with that?
[13:19] <jdstrand> anyway, I won't question the default of systemd here cause I don't have the context for that decision
[13:20] <jdstrand> but, if that is configurable, certainly for sanity we would want to at least try to have snapd shutdown cleanly
[13:20] <jdstrand> no?
[13:20] <pedronis> yes
[13:20] <pedronis> sorry, but I made a note, but we need mvo around but he is lunching
[13:21] <zyga> jdstrand: no, that's just SIGTERM
[13:21] <zyga> jdstrand: after that there is a wave of SIGKILL
[13:22]  * pstolowski lunch
[13:26] <jdstrand> zyga: that is my question. how long before the wave comes?
[13:26] <zyga> jdstrand: the wave of sigkill?
[13:26] <jdstrand> 07:21 < zyga> jdstrand: after that there is a wave of SIGKILL
[13:27] <jdstrand> zyga: you said that SIGTERM is sent. then a wave of SIGKILL
[13:27] <zyga> yes
[13:27] <zyga> DefaultTimeoutStopSec
[13:27] <jdstrand> zyga: I'm saying, trap SIGTERM, try to shutdown before the SIGKILLs
[13:27] <zyga> 90 seconds
[13:28] <zyga> jdstrand: assuming we are using kill mode process yes
[13:28] <zyga> but that would need some serious work
[13:28] <zyga> it's not easy to do now
[13:28] <zyga> e.g. manager startup is synchronous
[13:28] <zyga> so is overlord startup
[13:28] <zyga> we don't notify systemd that some startups need more time either
[13:28] <jdstrand> zyga: ok. so, certainly we can trap SIGTERM and signal the backend to finish the current parser and snap-seccomp calls, then exit without moving to the next batch, no?
[13:29] <zyga> jdstrand: we trap sigterm but the interaction between this and the rest of the daemon is not simple
[13:29] <zyga> I agree we can do this
[13:29] <jdstrand> hmm
[13:30] <jdstrand> well, I was only asking a question. it sounds like we have a stability/robustness concern here that the 6233 papered over
[13:30] <zyga> yes, I agree
[13:30] <jdstrand> not saying that 6233 is invalid for moving forward
[13:30] <zyga> we didn't notice that daemon was incorrectly stopping either
[13:31] <zyga> john sent some patches that caught that with static analysis
[13:31] <pedronis> well, first we need to stop systemd to send the SIGTERM to apparmor_parser as well, etc
[13:31] <jdstrand> ok, well, I don't mean to distract. just rasing the point that perhaps a followup for cleaning up cleanly when receiving SIGTERM is a good idea
[13:31] <jdstrand> raising*
[13:31] <zyga> it also makes testing more complex, since right now all systemd started snapd's behave the same
[13:31] <zyga> with changing of kill mode some will run under the old snapd.service unit
[13:31] <zyga> some will run under the new one
[13:32] <zyga> jdstrand: all fair points jamie,
[13:32] <zyga> I think it would be nice if we could fix this with reexec magic and systemd services
[13:34] <jdstrand> ok, reading the description of 6233, that seems like a good improvement regardless of sigterm
[13:38] <mvo> pedronis: hi, KillMode=process got closed mostly because the other changes made it less urgent, it is probably still a good idea
[13:39] <zyga> mvo: with kill mode = process, we should make sure that it also applies to snapd run from snapd.snap via that special service
[13:39] <mvo> zyga: yeah, we can install a snapd.service.d file
[13:39] <mvo> zyga: I mean, write it automatically
[13:39] <zyga> oh
[13:39] <zyga> super nice idea
[13:39] <zyga> +1001
[13:39] <mvo> zyga: :)
[13:40] <mvo> zyga: I can reopen my PR and add code to add the .d file
[13:40] <zyga> mvo: it's not urgent but yeah, for master +1
[13:41] <mvo> zyga: +1
[13:41] <zyga> mvo: though we need to think about revert consequences or just managing those .d files over time
[13:41] <mvo> zyga: indeed
[13:46] <mup> PR snapd#6249 opened: cmd/libsnap: introduce and use sc_strdup <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6249>
[13:47] <zyga> mborzecki: could you try to look at 6149 today?
[13:48] <mup> PR snapd#6250 opened: data: set KillMode=process for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6250>
[14:08] <mup> PR snapd#6247 closed: tests/lib: do not pick up xatts when repacking core snap <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6247>
[14:49] <Chipaca> degville: "keeping it the same" is that a +1 :-D
[14:52] <degville> Chipaca: yes!
[14:52] <degville> :)
[14:52] <Chipaca> wooowoeoeoo
[14:58] <pstolowski> pedronis: you're right, it's about AddBlocked predicate
[15:07] <zyga> mborzecki: hey
[15:07] <zyga> remember when you asked for a cleanup of how tools are invoked from snap-confine?
[15:16] <zyga> mborzecki: so you have your wish
[15:16] <pedronis> pstolowski: good, but yes we'll need to think a bit what to do about that
[15:16] <zyga> mborzecki: found a branch that does that :)
[15:16] <mborzecki> zyga: hah :)
[15:17] <Chipaca> mborzecki: i think you did half a review of 6912 already, could you finish it?
[15:17] <Chipaca> #6912
[15:17]  * Chipaca kicks mup
[15:17]  * Chipaca jumps up and down on mup
[15:18] <mborzecki> Chipaca: wrong PR #?
[15:18] <Chipaca> mborzecki: https://github.com/snapcore/snapd/pull/6192
[15:18] <mup> PR #6192: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
[15:18] <Chipaca> #6192
[15:19] <Chipaca> 6192, 6912, what EVAR
[15:19] <mborzecki> aah epoch read thing
[15:19] <Chipaca> yeh
[15:19] <Chipaca> tempted to run with graham's +1 but thought i'd follow process for once :-p
[15:20] <zyga> Chipaca: friday called and wants to +1 your PRs
[15:20] <Chipaca> well there's one less to +1 now
[15:21] <mup> PR snapd#6192 closed: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6192>
[15:21] <Chipaca> and I guess I need to address the comments on the other ones
[15:21] <Chipaca> ugh, that's too much like work
[15:23] <pedronis> Chipaca: the media one has a question by me, it probably needs discussion
[15:23] <Chipaca> pedronis: yeah
[15:23] <zyga> brb
[15:23] <Chipaca> pedronis: do you have the time to discuss?
[15:24] <pedronis> Chipaca: not really today, that one we'll have to wait when we are both back
[15:24] <Chipaca> pedronis: ok
[15:42] <zyga> re
[15:42] <zyga> mvo: hey
[15:42] <zyga> mvo: do you have a sec
[15:42] <zyga> https://github.com/snapcore/snapd/pull/6235 is green
[15:42] <mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
[15:42] <zyga> and should make 2.36 green
[15:42] <zyga> would you mind finishing your review there
[15:42] <zyga> I'm happy to backport / cherry pick tests
[15:43] <zyga> or other stuff
[15:43] <zyga> from the corresponding master branches
[15:55]  * zyga considers EODing
[15:55] <zyga> unless someone wants to look at 2.36 PRs
[15:56] <Chipaca> pedronis: I pushed the discussed reorg to #6104. If you won't have time to re-review, can I discard your block?
[15:56] <mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[15:59] <pedronis> Chipaca: yes, the direction looks what we discussed
[16:00] <pedronis> Chipaca: done myself
[16:08] <Chipaca> pedronis: i included your rationale in the commit message, for posterity, fwiw
[16:08] <Chipaca> pedronis: thank you
[16:08] <Chipaca> zyga: #6104 is now needing a second review, if you're still itching to do one
[16:08] <mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[16:09] <zyga> yep
[16:09]  * Chipaca goes to get tea and some ibuprofen
[16:09] <zyga> Chipaca: can you trade for trivial https://github.com/snapcore/snapd/pull/6249
[16:09] <zyga> I wanna land it :)
[16:09] <mup> PR #6249: cmd/libsnap: introduce and use sc_strdup <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6249>
[16:10] <zyga> 2.36.2 looks good on suse :)
[16:10] <zyga> and startup time for snaps is nice
[16:10] <zyga> though I wonder if we need to refresh each snap to see the effect
[16:11] <zyga> I disable/enable things to see that
[16:11] <zyga> mvo: ^
[16:11] <zyga> Is that expected?
[16:11] <mvo> zyga: one refresh or enable/disable should be enough to fix the fontconfig cache
[16:11] <mvo> zyga: (also in a meeting)
[16:12] <zyga> ta
[16:12] <mup> PR snapd#6236 closed: Staticcheck fixes <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6236>
[16:14] <zyga> kenvandine: ping
[16:14] <zyga> is this expected? https://www.irccloud.com/pastebin/G8zDQBdJ/
[16:16] <kenvandine> zyga: yes... jamesh submitted a PR to Yaru to fix that
[16:16] <zyga> cool
[16:16] <zyga> thanks
[16:16] <kenvandine> i'll check on the status
[16:16] <kenvandine> it's been weeks
[16:17]  * cachio lunch
[16:23] <mup> PR snapd#6213 closed: interfaces: let NM access ifindex/ifupdown files <Created by alfonsosanchezbeato> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6213>
[16:28] <zyga> Chipaca: +1
[16:29] <zyga> mvo: suse updated :)
[16:30] <zyga> error: snap "test-snapd-policy-app-consumer" has "remove-snap" change in progress
[16:30] <zyga> pstolowski: ^ is that something you were describing during the standup?
[16:31] <mvo> zyga: \o/
[16:31] <pstolowski> zyga: hmm not really, my issue doesn't cause errors
[16:33] <pstolowski> zyga: where do you see it?
[16:33] <zyga> random failure on strdup
[16:33] <zyga> (on that PR)
[16:33] <zyga> I restarted as it looked like noise
[16:34] <pstolowski> uhm
[16:36] <zyga> mvo: vscode startup on leap 42.3 and TW is very good
[16:37] <zyga> Chipaca: did you see my ping about http://juniper.github.io/libxo/libxo-manual.html xo?
[16:37] <Chipaca> zyga: i did
[16:38] <zyga> cool
[16:38] <Chipaca> zyga: I'm not adding anything to my stack right now though :-)
[16:38] <zyga> sure sure
[16:38] <zyga> it's a C api
[16:38] <zyga> but the idea is neat
[16:40] <mvo> zyga: cool
[16:41] <mvo> zyga: thanks for checking/confirming!
[16:48]  * pedronis calls it a week
[16:48] <pedronis> have a good weekend!
[16:51] <cachio> mvo, 2.36.2 in candidate
[16:53] <mvo> cachio: nice!
[16:55] <cwayne> Now with spread results on customer hw :D
[16:57] <pedronis> Chipaca: I managed to update my PR: https://github.com/snapcore/snapd/pull/5712
[16:57] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[16:57] <Chipaca> pedronis: i saw! excellent
[16:57] <Chipaca> pedronis: is that enough to unblock it?
[16:58] <pedronis> yes
[16:58] <Chipaca> cwayne: that sounds like a good thing. Is that a good thing?
[16:58] <Chipaca> pedronis: neat
[16:58] <cwayne> Chipaca: no it's a great thing :)
[16:58] <Chipaca> :)
[16:58] <pedronis> Chipaca: if it gets green, there is really the last commit than needs a review and then it could go in
[16:58] <pedronis> I mean real commit, not the master merges
[16:58] <cwayne> since we've now got my team's tests plus yours running on every core update in beta :)
[16:58] <Chipaca> a'ight
[16:58] <mvo> pedronis: nice
[16:59] <mvo> cwayne: woah, nice!
[16:59] <Chipaca> what, only beta?
[16:59] <Chipaca> :-D
[16:59] <cwayne> beta's my jam
[17:21] <mup> PR snapd#6249 closed: cmd/libsnap: introduce and use sc_strdup <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6249>
[17:23] <mup> PR snapd#6251 opened: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
[17:25] <zyga> mvo: not sure if you EOW but I'd love an ack on https://github.com/snapcore/snapd/pull/6245
[17:25] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[17:27] <mup> PR snapd#6242 closed: overlord/snapstate: use file timestamp to initialize timer <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6242>
[17:32] <mup> Bug #1781906 changed: Content provider interfaces introduced to snaps aren't correctly set up <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1781906>
[17:40] <mup> PR snapd#6104 closed: snapctl: add "services" <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[17:43] <mup> PR snapd#6252 opened: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
[17:45] <zyga> jdstrand: hey, not sure if you want or have time on Friday evening but... https://github.com/snapcore/snapd/pull/6244 :D
[17:45] <mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
[17:45] <zyga> you looked at it
[17:54] <Chipaca> EOW'ing here
[17:54] <zyga> o/
[17:54] <Chipaca> when you see me next, december will be into two (decimal) digits!
[17:55] <Chipaca> :-D
[17:55] <zyga> maaan
[17:55] <zyga> envy *
[17:55] <Chipaca> well, unless i'm bored or something
[17:55] <Chipaca> :-)
[17:55] <zyga> you can always do reviews *D*
[17:55] <zyga> NOT :)
[17:55] <zyga> enjoy the time off
[17:56] <Chipaca> if I'm tempted, instead I'll work on werm
[17:56] <Chipaca> ttfn :-)
[17:56] <zyga> werm?
[17:56] <zyga> well, I'll find out in Dec
[18:01] <jdstrand> zyga: I'll try. have a few things I must get done today
[18:01] <zyga> thanks cwayne
[18:01] <zyga> thank you jdstrand :)
[18:01] <cwayne> zyga: <3
[18:17] <kenvandine> zyga: the CLA check shouldn't fail if I'm a member of canonical, right?
[18:17] <zyga> kenvandine: if it does it's a bug :)
[18:17] <zyga> are you asking about https://github.com/snapcore/snapd/pull/6252 ?
[18:17] <mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
[18:17] <kenvandine> zyga: yes
[18:17] <zyga> review sent :)
[18:19] <zyga> I should EOW
[18:19] <zyga> I may be back in the office but not actively paying attention unles pinged
[18:19] <zyga> *unless
[18:58] <mup> PR snapd#6225 closed: tests: fix for failover test on how logs are checked <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6225>
[19:00]  * cachio afk
[19:08] <mup> PR snapd#6253 opened: Members of canonical LP group should pass CLA check <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6253>
[19:11] <mup> PR snapd#6224 closed: interfaces: return security setup errors <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6224>
[19:14] <zyga> kenvandine: https://github.com/snapcore/snapd/pull/6252/files#r237971362
[19:14] <mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
[20:37] <mup> PR snapd#6254 opened: tests: improve how the log is checked to see if the system is waiting for a reboot <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6254>
[23:43] <dennwc> Hi! Can anyone help me to setup snapcraft dev environment? I'm trying to fix a bug related to Go modules support, but I can't get the local version of snapcraft working.