[00:12] PR snapd#9534 opened: many: update to secboot v1 [02:18] hiya... is there a way to compile snapd from source since snap isn't available for my distro? [05:36] morning [05:57] PR core20#91 opened: hooks: add /var/lib/snapd/save [06:29] good morning [06:30] jamesh, o/ do you think you could look at the notifications we send in https://github.com/snapcore/snapd/pull/9446 [06:30] PR #9446: overlord,usersession: initial notifications of pending refreshes [06:31] zyga: okay [06:31] jamesh, the interesting code is in rest_api.go [06:32] jamesh, there we construct and make the dbus calls [06:32] here: https://github.com/snapcore/snapd/pull/9446/files#diff-fb842538ad8c6ce2555e74f75a07eadadc9f318b2ddd5106b18e83f285be17b5R215 [06:32] PR #9446: overlord,usersession: initial notifications of pending refreshes [06:33] meanwhile I will iterate on https://github.com/snapcore/snapd/pull/9530 [06:33] PR #9530: interfaces: x11 shares hosts /tmp/.X11-unix/ <⚠ Critical> [06:46] hey mvo [06:47] mvo, I've picked up the x11 socket PR from yesterday as you've marked it as critical [06:47] mvo, once done I will go back to boot protocol [06:50] good morning zyga [06:50] zyga: did security react? [06:51] mvo, about x11? [06:51] mvo, yes, yesterday, there will be a review next week [06:51] zyga: ok [06:52] I'm working on comments from jamesh - mainly to cover non-implicit slots and self-connections [06:52] ta [06:54] mvo: hi, can you take a look at https://github.com/snapcore/core20/pull/91 ? [06:54] PR core20#91: hooks: add /var/lib/snapd/save [06:56] mborzecki: sure [06:57] mborzecki: fwiw, I think it's fine if snapd auto-creates this dir if it's missing in it's code [06:58] mvo: also, if we add an entry to fstab systemd-mount should create destination directory as well [06:59] mborzecki: snap-bootstrap will do the mounting, yes? then that could also create the dir if missing. I mean, adding in core20 is totally fine [07:02] mvo: snap-bootstrap will do a mount under /run/mnt/ubuntu-save for now [07:06] mborzecki: aha, yes, make sense [07:07] jamesh, do you think we can use a read-only bind mount for .X11-unix? [07:07] morning [07:08] zyga: I think so. There's zero reason for clients to modify that directory, and the socket should still work [07:08] I'll code it as such and give it a try [07:09] and we definitely don't want snaps to go and delete those sockets from the host system [07:09] yeah, that's a good point [07:34] jamesh, could you look at the general idea I've added to https://github.com/snapcore/snapd/pull/9530/files again please [07:34] PR #9530: interfaces: x11 shares hosts /tmp/.X11-unix/ <⚠ Critical> [07:34] jamesh, it lacks tests and I did not verify it to work correctly yet [07:35] jamesh, but I want to see if we are aligned on the direction [07:35] * jamesh looks [07:37] * zyga goes for quick breakfast [07:44] PR snapd#9532 closed: tests: clean systems.sh helper and migrate last set of tests [08:01] re [08:03] zyga: hi, should we chat about splitting the export manager PR? [08:03] pedronis, yes [08:03] pedronis, I had several ideas [08:03] pedronis, a lot of the noise is related to the addition of the new tasks [08:04] pedronis, so we could split the export manager so that new tasks are not used yet [08:04] pedronis, and only later on add them [08:04] pedronis, the spread test is another natural boundary [08:04] pedronis, what do you think? [08:06] so manager + tasks but not used, use of tasks and rest but, last snap-confine changes + spread tests ? [08:06] pedronis, oh right, snap-confine is another natural chunk [08:07] yeah, that is very doable, there will be still some large patches but definitely smaller than now [08:08] jamesh, I have an idea about the permissions [08:08] jamesh, I'll work on that today, let's sync on Monday [08:08] jamesh, I'm sure this will work [08:08] zyga: fair enough [08:09] jamesh, the idea is to give snap-update-ns knowledge about implicit permissions [08:09] jamesh, so it can create those segment by segment [08:09] jamesh, and use values matching some patterns unless explicit mode is provided [08:09] zyga: also, a regular user running in the slot snap's sandbox should be able to write to /tmp/.X11-unix [08:09] it'd be all in snap-update-ns [08:09] zyga: I expect the first one to be fairly large, at least it will all be new code [08:09] that seems reasonable [08:09] zyga: in one place [08:10] pedronis, yes, it's all of the export manager [08:10] pedronis, we may need to register the link participant along with the new tasks but I think it will be manageable [08:12] github doesn't seem very responsive here, stalling opening comments [08:14] github status is all green, hopefully just local routing problems [08:20] yea, weird, is not all comments [08:31] pedronis: hi, can you take a look at this bit later on https://github.com/snapcore/secboot/pull/124 ? [08:31] PR secboot#124: Support setting LUKS2 metadata and keyslots area sizes when creating containers [08:32] yes [08:38] mvo, pedronis could you grab a few old snapd snaps (I think >=2.42, which was aroud Oct 2019) for the tests we talked about? [08:39] and corresponding core18s I suppose [08:44] good morning [08:44] o/ dot-tobias [08:46] pstolowski: 5760 would be 2.42.5 for amd64, does that work? [08:48] pedronis: yes that should be fine, it's Dec 2019, old enough but no too old [08:49] \o zyga 😊 I revisited the `layout` section in one of my snaps, that wouldn't have been possible without all your work on layouts. Still grateful that I started the snap around that time 😄 [08:50] dot-tobias, that's so nice to hear, thank you :) [08:52] pstolowski: core18 is messier, its version don't tell easily if something is a stable release or not [08:54] pedronis, we could take core18 from CD images perhaps [08:54] but yeah, it would be good to have release history [08:55] pedronis: Roger's pi3 has core18 20190723 rev 1076, but I guess it's not easy to remap to amd64 [08:55] no, that is fine [08:55] but that is much older than the snapd we are taking [08:56] pstolowski, btw, once gadget assets from kernel are done, we could update roger's pi [09:00] pedronis: right. we could go back to 2.39.x (which was Mar-Jun 2019). auto-connect was way older, from 2018 [09:01] pstolowski: need to do something else, will come back to this [09:01] np [09:16] jamesh, if you are still around, I pushed my idea for making the permissions right [09:16] zyga: okay. In a meeting right now, but will look afterwards [09:18] pstolowski: I'm back, I can also help with downloading [09:18] thanks, I'll adjust the remaining comment and work towards having proper end-to-end tests as well [09:18] but first, tea, it's cold, raining and warm tea is cheaper than heating [09:27] mvo: ty! [09:28] pstolowski: do you want a released version or is 2.38+git831.g9ac7e3e okay? or should it be 2.39? [09:30] mvo: no strong opinion, but i'd stick to released versions [09:31] pstolowski: sure, let me try to find the right revisions for this [09:31] pstolowski: it looks like the store api makes it hard to find things :( [09:32] pstolowski: old things [09:32] Do launchpad builders still get their internet connection cut after 2 hours? I have four parts that I need to build in sequence; the third part takes > 2h to build on ARM. If the connection is cut, snapcraft won't be able to download the sources for part 4. [09:32] dot-tobias, interesting, I guess that's a question for the launchpad team, I was not aware of that limitation [09:33] pstolowski: shared the .git version of 2.38 with you need to figure out how to get the store to filter the history by branch, then I can see the revisions for released versions [09:34] zyga: Yeah, last time I ran into this was > 1 year ago, so I thought I'd re-check. Who might I ping about this, as it cjp256 is probably [09:35] (that sentence should've continued) … not up yet [09:35] mvo: thanks, maybe put it on gdrive and share with cachio as well, we will want those files in gcloud storage [09:36] pstolowski: I found a stable core18 from 2019-12-04, does that work ? [09:36] mvo: I'm working on findind snaps for pstolowski [09:37] pedronis: yes, that should be fine with 2.42.5 [09:38] pedronis: ok [09:44] pstolowski: https://people.canonical.com/~pedronis/old-snapd/ let me know if you need something older instead [09:44] pedronis: thanks [10:19] zyga: left some comments on https://github.com/snapcore/snapd/pull/9446#pullrequestreview-515450485. Looking over the x11 PR again next [10:19] PR #9446: overlord,usersession: initial notifications of pending refreshes [10:21] jamesh, thanks [10:21] I've started testing it, fixed apparmor permissions [10:26] jamesh, thank you for the review! [10:32] sigh [10:33] some apparmor woes [10:37] woot [10:37] got that to work [10:39] jamesh, if you are looking [10:39] jamesh, I've pushed a fix for apparmor permissions to x11 [10:45] mvo, I'll park https://github.com/snapcore/snapd/pull/9530 for now and get back to notifications [10:45] PR #9530: interfaces: x11 shares hosts /tmp/.X11-unix/ <⚠ Critical> [10:46] zyga: ok [11:01] afk / walk [11:14] PR snapd#9535 opened: o/snapstate: generate snapd snap wrappers again after restart on refresh [11:35] back [11:35] WET [11:35] but okay [11:46] jamesh, thank you for the reviews! [11:51] jamesh: thanks for the review indeed [12:04] jamesh, I've updated https://github.com/snapcore/snapd/pull/9446 based on your comments [12:04] PR #9446: overlord,usersession: initial notifications of pending refreshes [12:05] (it's late so I don't expect you to review it today) [12:05] we need one more review anyway [12:12] degville: hi, the gdb docs look great, i've left some tips that may be worth adding at the bottom https://forum.snapcraft.io/t/using-gdb-and-gdbserver/20718 [12:13] mborzecki: brilliant, thank you! I'll add them! [12:23] cachio: have you seen this error before? https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/15660/signedlogcontent/85?urlExpires=2020-10-23T12%3A23%3A33.6075691Z&urlSigningMethod=HMACV1&urlSignature=6j4OihznEJx3htX02RAWE1Po54U1GfsTOZ9dYr6a5Po%3D (look for "certificate") [12:24] cmatsuoka, checking [12:24] uri expired [12:25] cmatsuoka, dou you have a pr number? [12:25] it's #9534 [12:25] PR #9534: many: update to secboot v1 [12:27] cmatsuoka, which syste? [12:27] m [12:28] ubuntu-20.04-64 [12:28] and others [12:31] cachio: hey, could you upload https://people.canonical.com/~pedronis/old-snapd/ to GC so I can use it in spread test? [12:31] pstolowski, sure [12:32] cmatsuoka, first time I see that error [12:33] perhaps a repo issue at maze-io [12:34] pstolowski, both core18 and snpad snaps¡ [12:35] ? [12:35] cachio: it seems so, I 'll investigate [12:35] cachio: yes [12:38] mborzecki, can you open bootstate16.go on line 102 please: is word "threading" there a mistake? [12:39] zyga: maybe it was meant to be treading (as in steppin over?) [12:40] mmm [12:40] yeah [12:40] makes sense, thanks [12:40] mhm, yeah, most likely, better if one of the native speakers confirms :P [12:40] I'll correct that [12:41] mborzecki: zyga: I wrote that [12:42] pedronis, should it say "treading"? [12:42] no [12:42] if you want to make it less, obscure s/threading/passing/ [12:42] so what does it mean, right now it doesn't read right [12:42] ah [12:43] yeah, I think that's better [12:43] threads != treads [12:43] heh languages are fun, not just the programming ones :P [12:45] to be clear I think the verb is fine (it's used like that in other programming contexts) but it's probably obscure [12:45] threading as in providing? [12:46] threading as in passing something around that also ties things together [12:49] zyga: it's probably more common in the compiler/functional world, but if you google for "threading state around" you'll find some computer science text using that expression [12:50] I see, I didn't know that [12:50] but probably a bit confusing to be honest, given that threading has such a strong semantic in computing now [12:51] oh my, almost standup time [13:05] PR snapd#9536 opened: RFC: bootloader ping/pong protocol [13:06] mvo, pedronis: something I'd love to discuss if you have a few minutes after the standup % [13:06] ^ [13:06] zyga: we have a secboot thing after but we can squeeze you in probably somehow [13:07] I just read that mvo said "boot" [13:07] must be yes ;) === probono9 is now known as probono [13:48] re (back with coffee) [13:48] I'll chop export manager now [13:57] zyga: \o/ thank you! [14:00] ijohnson: what was the url for the enumerating disk work you need review/feedback for from foundatoins? [14:00] ijohnson: I will put it on the agenda for todays meeting [14:00] pstolowski: current meeting overruning, we may be late for tgif (cc ijohnson ) [14:00] mvo: it's a lp bug let me grab it [14:01] ijohnson: ta! [14:01] mvo: ack [14:01] mvo: last comment on https://bugs.launchpad.net/snapd/+bug/1900842 [14:01] Bug #1900842: partitions can have different major numbers [14:04] ijohnson: ta [14:31] zyga: btw. i have govendor sync && rm vendor dirs in a loop on a tw system in gcp, it's been running for 1h+ now [14:32] mborzecki, I really wonder what's the magic that breaks there [14:32] maybe it's something with the hosts [14:32] ijohnson, btw, speaking of politics, what's up witch McConnell? [14:33] haha what's not up with McConnell [14:33] he could play in a harry potter zombie movie now [14:35] he could play any villain in any movie ever probably [14:36] "ONE MILLION DOLLARS" in evil voice [14:36] oh wow actually there is something up with him he's all different colors now [14:36] yeah, that's what I meant [14:40] PR snapd#9527 closed: o/snapstate: implement undo handler for unlink-snap [14:42] * zyga -> lunch [14:45] PR snapd#9537 opened: tests: also check snapst.Current in undo-unlink tests [15:05] * cachio lunch [15:12] back [16:05] * zyga EODs [16:06] PR snapd#9538 opened: o/snapstate/catalogrefresh.go: don't refresh catalog in install mode uc20 [16:10] zyga, do you have the tumbleweed links? [16:16] PR snapd#9414 closed: tests: new nested tool [16:36] PR snapd#9373 closed: snap: add new `snap recovery --show-recovery-key` option

[16:36] PR snapd#9539 opened: many: add /v2/system-recovery-key API and client [16:42] * cachio afk errands [16:51] PR snapd#9540 opened: snap: add new `snap recovery --show-recovery-key` optio === ubott2 is now known as ubottu === seyeongkim_ is now known as seyeongkim === Wimpress_ is now known as Wimpress === lfaraone_ is now known as lfaraone === philroche_ is now known as philroche === marosg_ is now known as marosg [18:04] PR snapcraft#3325 closed: snapcraftctl: add checks for empty string for set-version & set-grade [18:04] PR snapcraft#3333 closed: specifications: finalization of package repositories spec [18:04] PR snapcraft#3334 closed: package repositories: improve error handling [20:19] PR snapcraft#3335 opened: cli: remove spaces from progressive metrics [21:12] PR snapd#9541 opened: osutil/disks: re-implement partition searching for disk w/ non-adjacent parts [22:41] * ijohnson EOWs [23:32] Bug #1901262 opened: Unable to mount NTFS drives with write support