[02:10] PR snapcraft#2418 closed: Release changelog for 3.0.1 [06:11] morning [06:27] Hi [06:57] zyga: hey [07:07] Hej [07:07] Breakfasting [07:07] I sent a PR last night [07:08] Fixing leap issues [07:08] I will make a small variant for 2.36 [07:46] 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] looks like the current run was good, I do another one now [07:50] 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] mborzecki: heh [07:51] mborzecki: ok, it had one green now and I just triggered it again (via rename of GIL->GML) [07:57] super simple review #6241 [07:57] PR #6241: tests/main/parallel-install-store: verify installation of more than one instance at a time === pstolowski|afk is now known as pstolowski [07:58] mornings [08:01] Back from walk [08:01] Brrrr [08:01] Though I really like it when winter makes everything dry [08:02] Hey mvo [08:02] I will be around shortly [08:03] zyga: hey, no worries [08:03] zyga: all is looking great, I'm in a very good mood, PRs look super interessting [08:03] I posted the leap fix last night [08:03] Just the master version [08:04] 2.36 will be microscopic [08:04] Master has a cleanup as well [08:04] zyga: aha, even better [08:28] mborzecki: I put a question in #6079 [08:28] PR #6079: [RFC] `snap connections` command [08:29] PR snapd#6234 closed: overlord: don't write system key if security setup fails (2.36) [08:33] pedronis: thanks, finishing up with snapd update for arch now, will lack at your review in a bit [08:41] PR snapd#6221 closed: interfaces: return security setup errors (2.36) <⛔ Blocked> [08:46] mvo: https://github.com/snapcore/snapd/pull/6245 [08:46] PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) [08:46] it won't pass entirely [08:47] after that there will be only one small patch that makes apparmor-parser errors really reported and 2.36 is green [08:47] similar to the one you closed above in 6221 [08:47] PR snapd#6245 opened: interfaces/backends: detect too old apparmor_parser (2.36) [08:47] if you want I can add it here [08:50] 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] pstolowski: yeah, I found this too, its interessting [08:56] zyga: it sounds like like it can be added to 6245 if its small [08:56] mvo: yes, and one will not pass without the other [08:56] I'll do just that [08:56] mvo: thank you for merging the 2.36 fix even though it was not passing [08:57] pstolowski, mvo: what's the special case with brave? [08:57] zyga: sudo snap install brave && sudo snap install brave_test && sudo snap remove brave brave_test [08:57] zyga: (with instances feature on) [08:57] mhm [08:57] pstolowski: hi, do we have developer docs for interface hooks? [08:58] zyga: results in a bunch of conflicts and retries on the last step, take a good while to finish [08:58] pstolowski: conflicts on what? [08:59] pedronis: yes, they were written a couple of weeks ago [08:59] pedronis: conflicts on disconnects on removal (last op) [08:59] I see [09:00] 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] pedronis: yes, we expect it, but mvo observed a noticable slowdown with edge (which i can confirm) [09:02] ok [09:02] pedronis: it was noticed ~last week [09:02] pedronis: and again, it completes and work, is just slow [09:03] pstolowski: any candidate on why? feel free to dig a bit when you have a bit of time [09:05] pedronis: yeah i'm on, investigating, don't know yet [09:10] 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] oh [09:10] can we do that ourselves? [09:10] in the package file? [09:11] zyga: i can, but it's unclear whether i should, you know, the unwritten policy of doing nothing :) [09:11] hehe [09:11] does that also apply to libc breaking people on upgrades? [09:11] is there any limit? [09:11] hahah, it's /r/archlinux, or bbs.archlinux.org or just archlinux.org main page with 'manual steps needed' memo [09:12] /o\ [09:12] though i don't recall any major screwups for years now [09:12] * zyga is happy with opensuse :) [09:13] i mean, surprisingly, it just works [09:19] does it make sense to request snapd restart on a classic system where reexec is not supported? [09:19] mmm [09:20] probably not [09:20] that's what happens on arch, fedora and prooably opensuse too [09:21] morning Chipaca [09:21] morning [09:21] this basically https://paste.ubuntu.com/p/xRnrQMNTH8/ [09:21] Chipaca: morning, sir [09:21] Chipaca: hi [09:22] 'sup [09:24] mborzecki: hi, you have various things under review, but no current task that isn't blocked on feedback? is that true? [09:26] 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] mborzecki: ah ok, so you are not blocked atm? [09:27] Chipaca: did you see https://github.com/snapcore/snapd/pull/6236#discussion_r237451827 ? [09:27] PR #6236: Staticcheck fixes [09:27] pedronis: no [09:27] pedronis: I did [09:27] I'm assuming it's technically correct [09:28] in practice, not sure how important it is :-) [09:30] Chipaca: ? [09:30] * pedronis is probably missing something [09:30] pedronis: the current regep means we won't run staticcheck on ".0" releases [09:31] because go doesn't do .0, instead just does "" [09:31] apparently [09:31] Chipaca: not sure why you say is not important? having a test that doesn't run for a while [09:31] and then again [09:32] is usually source of confusion [09:32] of which if have enough I think [09:32] s/if/we/ [09:33] Chipaca: or you thinking that .0 never makes it into Ubuntu anyway? [09:33] I'll fix it (not that way though) [09:33] anyway changing it is likely quicker than this silly discussion :) [09:33] but, i'm worried that already 1.11 is breaking things for us [09:34] wonder what 1.12 will bring [09:34] and then there's go 2 [09:34] one thing at a time [09:35] pedronis: did you see"go 2 considered harmful"? [09:35] https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf [09:35] * Chipaca grins [09:36] no [09:36] lol [09:37] changing subjects, I pushed a little "make snapd start faster" pr after talking with cachio yesterday [09:37] and mvo fixed the spread tests (thanks mvo!) [09:37] and now it's so fast, systemd freaks out :-/ [09:38] I saw it [09:38] ah [09:38] :-) [09:38] no good deed goes unpunished [09:38] bah, it might be something else [09:38] i need to dig [09:38] but [09:38] 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] that thing :) [09:38] Chipaca: let's try to merge 6192 first [09:38] ok [09:39] * Chipaca looks at what's missing there [09:39] couple of minors there, and it needs a 2nd review (I cannot review twice) [09:44] pedronis: looking at the revision of the local snap would split error messages even more though [09:44] i mean, either snap could be local [09:47] * Chipaca gives it a stab [09:47] Chipaca: ? [09:47] pedronis: your suggestion to, in the local case, say "current local" [09:47] yes [09:47] pedronis: is about the current snap [09:48] pedronis: the revision we talk about in the error messages so far is about the new snap [09:48] cachio: oh seems it worked this time: https://travis-ci.org/MirServer/mir/jobs/461685223 [09:48] Chipaca: let me look [09:48] I might be very confused [09:49] pedronis: unless you meant to always say "current local", as in that-which-is-locally-current [09:49] and not as in that-which-is-locally-current-and-has-a-revision-that-is-local [09:50] Chipaca: I see, I'm confused [09:50] but something is off either way [09:50] hello confused i'm dad [09:51] Chipaca: so we are looking at snapInfo revision [09:51] great [09:51] except that calling a local installed snap new revision in the 2nd message [09:51] i could've caled them newInfo and curInfo instead of snapInfo and curInfo i guess [09:51] is confusing and what threw me off [09:52] * Chipaca looks [09:52] Chipaca: if I do snap install --dangerous foo.snap [09:52] calling the incoming thing new revision [09:52] is confusing [09:52] aha [09:52] (tough technically correct) [09:52] i'll happily drop in any other noun :-) [09:53] I might even drop in a verb if i'm in a hurry [09:54] 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] Chipaca: "new epoch %s being locally installed" would be the verbose thing [09:57] «cannot refresh "foo" because new epoch 123 being locally installed can't read [...]»? [09:57] yes [09:57] that's confusing to read [09:57] I'm happy to suggestion, the current error confused me though, so we need to do better [09:58] so, it can be a try or a --dangerous [09:58] yes [09:59] cannot refresh "foo" with local snap because its epoch ...? [10:00] «cannot refresh "foo" because the one you're trying to install has epoch [...]» [10:00] ? [10:00] hm [10:01] cannot refresh "foo" with local snap with epoch %s ... ? [10:01] cannto refresh "foo" to local snap with epoch...? [10:02] that also work [10:02] s [10:02] good, let me write it out in full just in case [10:03] cannot refresh %q to local snap with epoch %s, because that can't read current revision's epoch of %s [10:03] or maybe change the that to an it [10:03] cannot refresh %q to local snap with epoch %s, because it can't read current revision's epoch of %s [10:03] bah, that "revision's" there is noise [10:03] noise][1: no offence [10:04] can be dropped I suppose [10:04] cannot refresh %q to local snap with epoch %s, because it can't read the current epoch of %s [10:04] snap install hello-world does-not-exist, giving 'error: store.SnapNotFound with 2 snaps' is not super user friendly [10:04] mborzecki: my PR will fix it [10:04] pedronis: ack [10:04] mborzecki: i disagree, it's super friendly. You're just not its friend. [10:04] I'm actually hoping to get to it today [10:06] 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] mborzecki: tbf that error means there's a bug, it's meant as an error for us and not for users [10:08] we're lucky then that users install snaps one by one [10:08] but it did give me a bit of panic yesterday when 'snap install hello-world_foo hell-world_bar' didn't work :/ [10:09] Chipaca: there's two part of the code that make different assumptions, anyway #5712 should stop that afaiu [10:09] PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <⛔ Blocked> [10:09] pedronis: 🖒 [10:14] Chipaca: we probably should drop revision's alos in the other one, current epoch alone seems ok, no? [10:15] pedronis: heh [10:15] given also that it might be local or not in its own [10:15] 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] ^ current code [10:15] where desc is "local snap" or "new revision %s" [10:15] sounds good [10:16] Chipaca: we get the {} notation right if the epoch is complicated ? [10:16] yes [10:17] that's fine for now [10:17] 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] for now it's the json one [10:17] although from using it, just {[],[]} might be enough [10:18] (as opposed to {"read":[],"write":[]} ) [10:18] pstolowski: I'm available in a couple of minutes [10:19] pedronis: ok, ping me then (mvo feel free to skip it) [10:22] silly Go, not telling that when I write lcoal I mean local [10:23] pstolowski: ready now, in the standup [10:23] pedronis: ok coming [10:24] 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] mvo: https://github.com/snapcore/snapd/pull/6245 needs a review [10:45] PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) [11:03] pstolowski: reading https://github.com/snapcore/snapd/pull/6180 [11:03] PR #6180: snap/info: bind global plugs/slots to implicit hooks [11:04] zyga: thanks! [11:08] mvo: zyga: Chipaca: I'll be late for standup, I posted a forum message to the team about this [11:08] thank you [11:09] pedronis: thank you [11:09] pstolowski: sorry, was away but I take it you clarified this? [11:10] mvo: yep, no worries [11:10] zyga: I do a new round of review now [11:10] thank you [11:10] the local authority has finally (nearly 12 months later!) come to a decision about the boys' school \o/ [11:10] I'm not feeling well, sorry about being very slow today [11:10] … so I might miss the standup entirely today [11:10] zyga: no worries [11:10] * Chipaca hugs zyga [11:10] Chipaca: good news! (about the boys - not that you miss the standup ;) [11:10] but … from far away just in case it's cooties [11:11] * mvo hugs zyga as well [11:11] just cold, nothing fancy :) [11:11] I'll be allright [11:11] Chipaca: ok [11:13] 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] Chipaca, nice, I'll try it [11:15] thanks [11:16] Saviq, nice [11:16] please let me know if we need any change to that image [11:17] pstolowski: that seems strange, we are missing something, I suppose some prints in the taskrunner might help [11:18] Chipaca, which is the PR number? [11:18] #6192 needs a 2nd review [11:18] PR #6192: overlord/snapstate: on refresh, check new rev can read current [11:18] pedronis: yep [11:19] cachio: #6242 [11:19] PR #6242: overlord/snapstate: use file timestamp to initialize timer [11:19] degville: might you could look quickly at the new errors in #6192, if you have some feedback on them [11:20] notice that in most sitation the store should avoid us hitting them tough [11:20] they are more relevant for local development using try or local installs [11:20] zyga: did you mean to open #6245 with target set to release/2.36? it's targeting master now [11:20] PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) [11:20] ooh [11:20] shit :) [11:20] yes [11:21] fixed [11:21] this version is for the stable release [11:21] I was surprised it passed alone [11:21] heh, same here [11:21] (also surprised) [11:22] degville: thanks for https://forum.snapcraft.io/t/the-docs-roadmap/8763 [11:22] cachio: the problem is nfs-support restarts snapd 11 times :-) [11:22] cachio: and it's fast enough for that to be a problem now [11:22] cachio: I'm fixing [11:23] Chipaca, nice, thanks for that !!! [11:24] 5845 is ready for a second review [11:24] no problem. [11:24] * pedronis can't type today [11:26] PR snapd#6241 closed: tests/main/parallel-install-store: verify installation of more than one instance at a time [11:28] mup: kicked off another spread run in #6243 [11:28] mborzecki: In-com-pre-hen-si-ble-ness. [11:28] mvp: kicked off another spread run in #6243 [11:28] mvo: kicked off another spread run in #6243 [11:28] PR #6243: systemd: allow only a single daemon-reload at the same time <⛔ Blocked> [11:29] mborzecki: thanks, I run this now also locally against google:ubuntu-18.04-64, so far no issues, lets see [11:31] 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] 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] PR #6236: Staticcheck fixes [11:32] jamesh: I am keeping your user session pr in mind, have not finished the review yet though [11:32] Chipaca: I have it on my list, hope to get to it before lunch [11:33] mvo: excellent thanks [11:41] mvo: https://github.com/snapcore/snapd/pull/6245 is green! [11:41] PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) [11:41] that's lucky [11:52] 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] moar fire [11:55] toasty [11:56] pretty please review on 6245 [11:56] sir yes sir [11:57] thank you, that's almost all needed to make 2.36 green again [11:57] Chipaca: I think we fixed this but we did not communicate this well :(/ [11:57] Chipaca: I need to look what PR fixed it, don't quite remember offhand [11:57] mvo: is is in 2.36.x ? [11:57] Chipaca: thanks. [11:57] maybe we need a .3 [11:57] zyga: I think so [11:57] zyga: oh, why .3? what is missing? [11:57] I mean, if this is not in stable [11:57] but in 2.37 / beta only [11:58] but no need otherwise [11:58] don't propose a new .X on the eve of a sprint dude, that's just mean [11:58] you need to do it the monday of the sprint and write a CVE, that's the sporting way [11:58] Chipaca: *wahhhhh* [11:58] * mvo runs away screaming [11:58] HAHHAHA [11:59] * Chipaca 's job is done [11:59] Chipaca: make sure to msg mvo on his cell at 23:00 on sunday ;) [11:59] PLANES FALLING OFF THE SKY, NEED .3 [12:01] zyga: you guys are so mean! [12:01] mvo: we will attach patches :) that's foss spirit, right? [12:01] * zyga hugs mvo [12:01] lol [12:01] * mvo hugs zyga [12:01] no worries, we will wait until after breakfast [12:05] mborzecki: updated https://github.com/snapcore/snapd/pull/6244 [12:05] PR #6244: release: detect too old apparmor_parser [12:13] PR snapd#6246 opened: spread: show AVC audits when debugging, start auditd on Fedora [12:15] PR snapd#6247 opened: tests/lib: do not pick up xatts when repacking core snap [12:16] mborzecki: ^ don't we have xattrs that we care about in core tough? [12:17] pedronis: afaik not yet [12:17] pedronis: not that I know of, ubuntu will enable xattrs but it's not done yet [12:17] still is that change just exchaing a bug for another later? [12:17] heh, in some way yes [12:18] but xattrs will not show up by accident [12:18] and I think we will have some changes around snapd too [12:18] we are not the one adding them, though? are we [12:18] ? [12:18] sorry? [12:18] zyga: I mean, it depends on what you mean by accident, [12:19] other teams doing things without telling can be considered an "accident" [12:19] mborzecki: can we add some code to detect if there's xattrs that are not selinux related around? [12:19] 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] zyga: you are an optimistic [12:20] pedronis: i'll think about it, with the context applied via mount that change may not be needed at all [12:20] thx [12:21] 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] mborzecki: is there no utility to run something controlling the context? [12:24] anyway I let you look into this further [12:31] PR snapd#6248 opened: tests/lib/reset: restore context of removed snapd directories [12:34] PR snapd#6237 closed: client, store: don't use store from client (use client from store) [12:53] zyga: hey, curious, does leap run on arm? [12:53] jdstrand: hey [12:53] yes, I think there were some pi3 announcements by suse [12:54] https://en.opensuse.org/HCL:Raspberry_Pi3 [12:54] I haven't tried myself [12:54] why? :) [12:54] 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] zyga: it is because of your fyi :) [12:55] haha [12:55] I see [12:55]