[06:32] morning [06:38] driving kids to school, back in 30 [07:06] re [07:26] git pull [07:26] pff wrong window [07:32] PR snapd#7863 closed: interfaces: add uio interface [08:04] morning [08:04] pstolowski: hey [08:18] PR snapd#8107 opened: tests/lib/prepare: use a local copy of uc20 initramfs skeleton [08:41] PR snapd#8075 closed: boot: don't use "kernel" from the modeenv anymore [08:42] pedronis: hey, thanks for merging 8075, there's some conflicts in #8076 now but i'll push an update there [08:42] PR #8076: boot: add TryBase and BaseStatus to modeenv; use in snap-bootstrap [08:43] mborzecki: thank you [08:43] mborzecki: and hi, reminder about reviewing #7588 [08:43] PR #7588: cmd/snap: add a "snap routine portal-info" command [08:44] pedronis: yeah, got it in my queue, wanted to push out the uc20 kernel thing first [08:45] mborzecki: makes sense, but we are over the of hump of getting snap-bootstrap injected/things booting [08:45] pedronis: yeah, finally [08:48] No snap packaging for Dropbox? [08:49] 8076 needs a 2nd review [08:52] mborzecki: I'll look at it in a bit [09:10] pstolowski: hi, did a pass on #8102 [09:10] thank you for it [09:10] PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate [09:10] pedronis: hey, thanks! [09:19] mvo took a sick day? [09:20] mborzecki: not sure about the reason, but he said he would be off today [09:23] wonder if https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1861648 is snapd running xdelta maybe [09:23] Bug #1861648: When booting 20.04 an 'ld-2.23.so' process consumes 100% CPU for minutes [09:28] o/ [09:28] hey all, do you guys know if there's API to trigger builds on build.snapcraft.io? [09:28] Saviq you'd need to use the launchpad API directly I think [09:29] PR snapd#8093 closed: cmd/snap-confine: detect base transitions on core16 [09:29] Lukewh: right, so I'd need a recipe on LP, that we do know [09:29] to answer your question directly though - build.snapcraft.io doesn't have an api :) [09:29] probably should have started with that [09:35] pedronis: good morning! did mvo decide to do another 2.43.x? [09:36] zyga: yes, but he is off today, there's a couple of things marked from 2.43 that are not backported yet, that we should discuss with him whether to backport or not [09:36] aha, I see [09:36] thanks, I'll add a launchpad milestone then [09:38] mborzecki: pstolowski: I think it was planned either way for him to be off, he is using a swap day from CPT [09:38] same as me on Monday [09:38] pedronis: thank you for backporting uio dependencies and working on the feedback, I read the comments now [09:38] ack [09:39] hey zyga ! [09:39] I didn't notice the uio hotplug leftover, thanks for chasing that [09:39] hey pawel :) [09:39] zyga: hey! feeling better? [09:39] mborzecki: yeah, no more fever, just some cough left [09:39] mborzecki: kind of wished I was sick next week but what can you do [09:41] looking at the list of open PRs I have this feeling: https://imgflip.com/i/3ogq6y [11:09] hmmm, taken from environment.d manpage: `If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence` and we have `990-snapd.conf` [11:15] pedronis: found the bug in rawsockstopper, details coming shortly [11:15] pstolowski: thx [11:24] * pedronis lunch [11:30] * zyga did first real c20 review in a while https://github.com/snapcore/snapd/pull/8103#pullrequestreview-355082288 [11:30] PR #8103: snap-bootstrap: store encrypted partition recovery key [11:34] pedronis: commented on 8101 [11:36] pedronis, pstolowski: I did a pass over https://github.com/snapcore/snapd/pull/8102#issuecomment-583352987 [11:36] PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate [11:36] zyga: yep, just saw it, thank oyu [11:36] *you [11:40] zyga: interesting remark about KeepAlive [11:40] didn't know about it [11:40] pstolowski: https://github.com/snapcore/snapd/pull/8101#issuecomment-583354904 [11:40] PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets [11:40] pstolowski: yeah, golang is full of that [11:42] zyga: afaiu setting non-blocking mode is not possible here until go-1.11 (see PR desc) [11:43] pstolowski: why? [11:43] pstolowski: I mean, we do syscall* everything [11:43] so we can just do it too [11:43] pstolowski: but regardless of what go provides, my comment stands, it's a system, not go, property [11:44] pstolowski: we can use non-blocking IO without wrapping it in existing structs [11:47] zyga: did land the code to parse the snap apparmor labels (or just security labels)? [11:47] zyga: i don't know the details of why non-blocking is problematic, pedronis / mvo investigated this [11:48] mborzecki: I don't recall us having such code [11:49] zyga: i recall us-2 discussing the need to have such code in the context of cgroupv2, but i don't remember whether anything was written actually [11:49] mborzecki: no, my code needs review [11:49] mborzecki: can you look, I can iterate once it lands :/ [11:50] https://github.com/snapcore/snapd/pull/7825 [11:50] PR #7825: many: use transient scope for tracking apps and hooks [11:53] zyga: fyi, that PR is high on the list. I hoped today, likely monday now [11:53] zyga: it is a big one for me [11:53] jdstrand: hey :) [11:53] jdstrand: thanks, [11:53] jdstrand: big note: that's still behind a feature flag [11:53] so I need a big chunk of time to devote to it [11:53] jdstrand: and I want to iterate on more {features,tests,stuff} [11:54] jdstrand: so please keep that in mind, I just want to make progress [11:54] jdstrand: understood (on time) [11:55] zyga: I understand. code and future work is one thing, but the design is novel (to me) and I want to make sure I give your code due respect :) [11:55] yep :) [11:55] but ack [11:55] I'm just saying there are TODOs there and I know :) [11:55] * jdstrand nods [11:56] I'm not concerned with that bit [11:56] this is milestoned for 2.44 [11:56] I'm just letting you know I haven't forgotten about it [11:56] sure :) [11:56] jdstrand: given you are here, is my response to https://github.com/snapcore/snapd/pull/7614#issuecomment-580649998 sensible? [11:56] PR #7614: cmd/snap-confine: implement snap-device-helper internally [12:00] zyga: yes [12:00] * jdstrand thumbs ups the comment [12:04] pedronis: some comments in #7588, but nothing large, i can push some fixes there [12:04] PR #7588: cmd/snap: add a "snap routine portal-info" command [12:13] pedronis: wdyt about https://github.com/snapcore/snapd/pull/7588#discussion_r376358272 ? [12:13] PR #7588: cmd/snap: add a "snap routine portal-info" command [12:24] grumble, google:ubuntu-20.04-64:tests/main/interfaces-pulseaudio [12:26] heh, again? [12:28] mborzecki: we have context things for snaps, I still think SnapApp is what we want [12:29] ok [12:29] pstolowski: is pulseaudio trying to poke bluez again? [12:29] mborzecki: I commented in the PR as well [12:34] mborzecki: i've no idea [12:41] pstolowski: thanks for finding that issue out, I will try to do a pass also taking zyga comment into account later today [12:41] pedronis: yw, and thanks for investigating it further [12:57] * zyga reads about x509 [13:00] zyga: have headache pills ready [13:00] mborzecki: hmm? [13:00] are you sending a long review :D ? [13:00] zyga: for x509 [13:00] ah :) [13:01] #8063 needs reviews, at this point both mvo and me have added code to it [13:01] PR #8063: cmd/snap: implement 'snap remove-user' [13:02] pedronis: just after 8100 [13:02] wrapping up [13:05] * zyga is very happy with the "viewed" tick on gh [13:07] pedronis: do you have logs from the stuck pulseaudio interfaces test? [13:08] pedronis: doing remove-user review now [13:11] mborzecki: this one failed, not stuck, but yes [13:12] mborzecki: here, https://api.travis-ci.org/v3/job/647158169/log.txt [13:12] is the other jamesh PR === ricab is now known as ricab|lunch [13:12] pedronis: thx [13:20] ok, let's see if the test order matters [13:21] PR snapcraft#2914 closed: meta: ensure Application passthrough is scrubbed for snap.yaml [13:21] PR snapcraft#2915 closed: rust plugin: respect Cargo.lock if present in project [13:33] hey all o/ [13:33] good morning Ian [13:34] morning zyga [13:34] or afternoon :-) [13:34] are you feeling better today ? [13:34] indeed, it's half past two for me [13:34] yeah, I think I had the easiest ride out of our bunch [13:34] $wife took $baby to the doc to check up on her [13:34] now that she's better and safer to handle [13:35] $son is pretty happy to have skipped this week, now that it's just cough and no fever :) [13:35] fever sucks, makes you useless [13:35] just sleep all day [13:35] yeah fevers are pretty bad [13:36] glad to hear that you're doing better, I hope the rest of your family does likewise [13:36] yeah, it's passing now, I only worry it will jump to $olderdaughter just as winter holidays start [13:38] yeah getting sick over holidays isn't fun, I was sick the latter half of holidays this past christmas, no bueno [13:39] pedronis: is it okay to add the TODO:UC20: comment you requested in 8076 to 8077 instead? 8076 is green with 2 +1s now, so would be good to merge I think :-) [13:40] ijohnson: yes, it's fine [13:40] pedronis: ack [13:41] PR snapd#8076 closed: boot: add TryBase and BaseStatus to modeenv; use in snap-bootstrap [13:41] brb, door [13:48] ijohnson: thanks for cleanups un #8097! [13:48] PR #8097: tests/lib/prepare: fix hardcoded loopback device names for UC images [13:49] uh meant #8094 :) [13:49] PR #8094: tests: repack the initramfs + kernel snap for UC20 spread tests [13:49] mborzecki: yes I'm happy we have working tests now, but I'm a bit worried that it's going to lead to more timeouts though [13:49] I think we should look at your firmware dropping changes ASAP [13:49] ijohnson: firmare is already dropped, we can enable dropping the kernel modules too though [13:51] mborzecki: oh right, well in addition to that we should probably also not even extract the firmware given how big it is, the tests are probably getting slowed down by decompressing all of that as well [13:51] ijohnson: oh and #8107 should interest you [13:51] PR #8107: tests/lib/prepare: use a local copy of uc20 initramfs skeleton [13:51] mborzecki: yes I was looking at that this morning [13:52] ijohnson: i think something's getting broken when the initrd is extracted by unmkinitramfs, there's a log about cpio stripping ../../ prefixes form hardlinks (?!) [13:52] mborzecki: have you asked xnox about that yet? [13:53] ijohnson: no, looks like he's busy with other stuff, and we have a workaround for now [13:53] mborzecki: ack, I might try to add a PR which doesn't extract the firmware at least to see if that helps [13:54] ijohnson: we need to extrac to get the modules (probably could hack a solution that uses the actual kernel snap modules), but i supose there may be something fishy in the way that unmkinitramfs does it [13:55] ouch [13:55] mborzecki: but we shouldn't need to extract the firmware at all should we ? [13:55] (from the kernel snap that is) [13:56] ijohnson: i think we could skip it, if we build the right directory structure with lib/modules/ to satisfy dracut ;) [14:00] 2fa [14:00] cachio: standup? [14:13] PR snapcraft#2917 opened: rust plugin: fetch correct (locked) crates during pull [14:22] cachio: I sent a small review for the udisks test [14:22] mborzecki: I sent you an invite to colloborate on the ubuntu-core-initramfs-snap github repo [14:22] so you can push to it directly [14:23] ijohnson: cool, thanks! [14:23] (and I merged your PR you opened as well) [14:28] zyga, tx [14:38] pedronis: https://github.com/snapcore/snapd/pull/8063#pullrequestreview-355155796 [14:38] PR #8063: cmd/snap: implement 'snap remove-user' === ricab|lunch is now known as ricab [14:42] cmatsuoka: thanks for the replies on cryptsetup PR, I only have one follow-up https://github.com/snapcore/snapd/pull/8103#discussion_r376425353 [14:42] PR #8103: snap-bootstrap: store encrypted partition recovery key [14:44] zyga: thanks, I'm still verifying the cryptsetup kill thing, will check that after lunch and the parents meeting at the school [14:44] zyga: some it is more for mvo, we are behind documenting our API [14:47] cachio: any idea what might be the cause of the failure on https://github.com/snapcore/snapd/pull/8106 ? [14:47] PR #8106: tests: add "core" suite for UC specific tests [14:48] ijohnson, let me see [14:48] cachio: it seems to be that the new "core" suite directory isn't getting copied over, but it only happens for uc18 and uc16 confusingly, uc20 is fine [14:49] ijohnson: that's so weird [14:49] ijohnson: maybe it's something unrelated, like an exclude mechanism? [14:50] yeah I looked at all our excludes and couldn't find anything [14:50] though note it only happens when we go to reboot, so I think it might be something with how we prepare the new image before we reflash that [14:51] ijohnson, first time I see that, let me check a bit more [14:53] * zyga has hot soup for lunch === ricab is now known as ricab|bbl [15:00] ijohnson, I am running the tests here [15:00] ijohnson, I see that hte core20 directory is still created in tests dir [15:00] hmmm interesting [15:01] are you running on google or via qemu ? [15:01] I wonder if it has something to do with the repack git thing we do to reduce delta when running on google [15:02] cachio: ^ [15:06] pstolowski: https://github.com/snapcore/snapd/pull/8102#pullrequestreview-355216316 [15:06] PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate [15:12] * cachio lunch [15:32] cachio: the reason that it's not copied over is due to the `-C` option we pass to rsync in setup_reflash_magic [15:33] not sure what's the implications of removing that, nor why rsync following CVS (?!?!?) exclude patterns makes tests/core/ be ignored [15:34] silly CVS.... https://stackoverflow.com/questions/8746419/using-cvs-exclude-in-rsync-suddenly-ignores-core-folder [15:36] * zyga goes afk for a while [15:36] it doesn't happen for uc20 because we don't use rsync for uc20, we create a tar archive instead which is extracted after the img is reflashed === ricab|bbl is now known as ricab [15:40] zyga: thanks for the review [15:52] ah [15:57] ijohnson, ahh, not sure, did you tried removing it? [16:00] cachio: I added `--include core` and it worked on my local run, seeing what travis spread does now [16:00] afk little bit [16:00] ijohnson, nice, thanks!! [16:10] can we land https://github.com/snapcore/snapd/pull/8058 ? [16:10] PR #8058: run-checks, travis: allow skipping spread jobs by adding a label [16:10] zyga: ^ do you know? [16:11] I don't mind [16:11] but I think it should be acked by cachio [16:12] pstolowski, zyga checking [16:14] ijohnson: #8077 seems to need a merge, there's conflicts now [16:14] PR #8077: boot: enable base snap updates in bootstate20 [16:17] pstolowski, zyga I see this is a bit dangerous, is there any way to just allow to some people to add this labels? [16:18] pedronis: yes resolving now just a few minutes [16:18] cachio: no, it's all or nothing [16:19] zyga, I would like to discuss it on monday during standup [16:19] that's reasonable, let's hold it until [16:19] just to make sure all agree with this [16:19] sure [16:20] nice, thanks [16:20] cachio: mark it blocked then [16:22] pstolowski, done [16:22] thx [16:33] pedronis: resolved now, I also made one more small tweak to `snap-bootstrap initramfs-mounts`, where we don't read the modeenv if the base is already mounted [16:34] pedronis: what do you think of that? it makes sense to me because it removes unnecessary read/write cycles when we don't need it [16:34] ijohnson: makes sense, but when we get the valid kernel thing next will need to tweak again [16:35] pedronis: oh right I forgot about that [16:35] hmm oh well I already pushed the commit, so I will just undo that change when we get to the valid kernel thing [16:35] pedronis: thoughts on what to name the modeenv setting for the kernels ? I had current_kernels but was thinking maybe something like trusted_kernels is better ? [16:55] pstolowski: I approved #7705, not sure if that's ready to go in now then, but it's green now :-) [16:55] PR #7705: o/devicestate: handle preseed in firstboot [17:00] ijohnson: yay, thank you! [17:00] pstolowski: you're very welcome [17:00] pstolowski: pedronis: which is the next preseeding/services PR I should look at? [17:02] ijohnson: #8046, give me a sec, i'll merge master [17:02] PR #8046: many, tests: integrate all preseed bits and add spread tests [17:02] PR snapd#7705 closed: o/devicestate: handle preseed in firstboot [17:02] ack, I probably won't get to it til my PM [17:05] updated [17:05] .. and eow. cu! [17:10] PR snapd#7983 closed: tests: adding more tests to core20 test suite [18:33] ijohnson, a question in #8106 [18:33] PR #8106: tests: add "core" suite for UC specific tests [18:33] the rest is ok for me [18:34] cachio: I didn't try "core/", I can try locally after my lunch [18:35] cachio: if it works I'll update the PR [18:35] ijohnson, nice, thanks [19:52] * cachio afk [20:50] PR snapcraft#2917 closed: rust plugin: fetch correct (locked) crates during pull [20:53] PR snapcraft#2918 opened: elf: ensure _GNU_VERSION_R section is of type GNUVerNeedSection [21:20] PR snapcraft#2800 closed: introduce `--apt-mirror` build provider flag [21:20] PR snapcraft#2819 closed: isort: automatic formatting/sorting of imports [21:20] cjp256: hey [21:20] cjp256: question about python stuff [21:21] cjp256: is isort doing something that black is not? [21:21] cjp256: should I stick to black or is there more beyond that? [21:22] zyga: isort does something black does not do [21:22] yeah, it organizes imports. black really just controls the spacing between them, but doesn't sort by pep8 rules [21:22] ... yes that :) [21:22] I see, thanks! [21:23] the problem is historically is that isort does not currently fully support black formatting, so the two fight each other in some cases - they have a 5.0 release coming up which should work well together with black [21:31] cjp256, you can just fix that though [21:31] it's pretty simple [21:33] techalchemy: there was one edge case affecting snapcraft they fixed but won't be in until 5.0: https://github.com/psf/black/issues/251 [21:33] but yeah, you can get it pretty close in config [21:34] cjp256, oh that's interesting actually [21:35] i'm a big fan of automatic formatting, so I'm gonna reopen that PR once it lands.. [21:35] I never bothered looking into it but it makes perfect sense because of how the introspection works [21:35] I just use # fmt: off [21:36] ah [21:36] cjp256, https://github.com/sarugaku/vistir/blob/master/src/vistir/compat.py#L135 <- like this [21:38] * sergiusens is not a fan of fmt: off [21:39] so glad we got rid of that with our move to python "greater-than" 3.5 [21:39] i rather use fmt: off for a line here and there than have 0 automated formatting :) [21:39]