[00:17] oh the curtin repo i'm pulling from is missing tags [07:28] PR snapd#9600 closed: cmd/s-b/initramfs-mounts: refactor recover mode to implement degraded mode [07:33] PR snapd#9614 closed: tests: enable main lxd test on 20.10 [08:04] morning [08:13] PR snapd#9616 opened: tests: enable lxd test on ubuntu-core-20 and 16.04-32 [08:16] +1 [08:17] good morning pstolowski [08:19] hey mvo [08:21] hi pstolowski, mvo [08:22] good morning jamesh ! [08:22] mvo: https://github.com/snapcore/snapd/pull/9530 has my review approval + security approval now [08:22] PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider

<⚠ Critical> [08:22] probably one other person look at it and it can be merged [08:22] jamesh: yay, let me do a final review then [08:23] thanks for driving this forward jamesh ! [08:29] hi jamesh! [08:32] mvo: i may have the improvements suggested by xnox for #9613 soon, ok to push them to that PR or would you prefer a followup at this point? [08:32] PR #9613: snapd-generator: set standard snapfuse options when generating units for containers [08:32] (don't want to slow down landing this PR) [08:43] pstolowski: followup please for now [08:43] mvo: ok, np [08:43] pstolowski: I want to look and then we can always close 9613 and just use the followup [08:43] pstolowski: but I don't want 2.48 to be held back [08:44] mvo: yep, that was my concern, makes sense [08:44] ta [09:01] * dot-tobias waves [09:53] PR snapd#9530 closed: interfaces: share /tmp/.X11-unix/ from host or provider <⚠ Critical> [10:08] PR snapd#9617 opened: tests: compare options of mount units created by snapd and snapd-generator [10:13] hmm network-retry test failed on core16 [10:47] Hello! I have a quick question - zyga at one point regarding a u-boot bug we have in uc18 mentioned something about a possible 'repair assertion' - what is that and where could I read a bit more about it? [10:54] sil2100: https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/42 (i don't know if there is any newer doc) [11:28] pstolowski: thanks! [11:29] yw [11:34] PR snapd#9618 opened: tests: minor test tweaks suggested in the review of 9607 [11:59] * pstolowski lunch [12:26] Are interface hooks run before the install hook *if* the interface connection is established through a gadget default? I'm building a core20 gadget that connects my snap to network-manager:service, and does some setup inside my snap once the interface is connected. This works fine in manual testing as the snap has to be installed [12:27] (premature enter key there) … *before* I can even run `snap connect …`, but when seeding through the gadget, it seems that the interface hook runs before the install hook, which will break the interface hook logic (as there's no database to write to at the time) [12:33] ^ (question maybe for ogra, ijohnson) [12:54] dot-tobias: perhaps pstolowski can help answer, I don't know when we run interface hooks for gadget auto-connected interfaces, I would assume at the same time as all the other auto-connects [12:59] dot-tobias, ijohnson this is correct, it's in auto-connect task and it runs before install hook [13:03] pstolowski: Ok thanks, at least I didn't bork something there. Is there any way I can hold off the interface hook until the snap is actually installed, or do I need to rewrite my snap application to run the tasks from the interface hook on each service startup (wrapped in a conditional)? I had hoped to encapsulate the one-time setup in the hook, as it's the ideal place for it – if the hook runs *after* installation ;-) [13:11] dot-tobias: no way to hold off interface hook.. maybe we need to think about early-install hook that runs before auto-connect. it all depends on use cases i suppose [13:13] pstolowski: Ok, thanks for clarifying 😊 Sure, myriad ways to use means myriad ways of possible conflicts … Well then I'll rewrite my application and start a thread on the forums about this later. Thank you! [13:13] dot-tobias: yes, i think we can discuss and consider this [13:30] ijohnson: would you take a look at https://github.com/snapcore/snapd/pull/9613 ? [13:30] PR #9613: snapd-generator: set standard snapfuse options when generating units for containers [13:30] pstolowski: sure [13:47] ijohnson: thanks [13:49] pstolowski: +1 with some suggested spread changes === popey3 is now known as popey [13:54] PR snapd#9616 closed: tests: enable lxd test on ubuntu-core-20 and 16.04-32 [13:57] ijohnson: thanks, replied [14:25] PR snapd#9592 closed: many: implement degraded recover mode [14:35] PR snapd#9613 closed: snapd-generator: set standard snapfuse options when generating units for containers [14:48] pedronis: let me know when your pr is ready [14:49] ijohnson: https://github.com/snapcore/snapd/pull/9619 mvo [14:49] PR #9619: cmd/snap-bootstrap,o/devicestate: use a secret to pair data and save [14:49] that was impeccable timing [14:49] pedronis: thanks I'll review it now [14:50] PR snapd#9619 opened: cmd/snap-bootstrap,o/devicestate: use a secret to pair data and save [14:54] Could anyone from the store team confirm if the review-tools now allows `compression: lzo` stanza in snapcraft yaml [14:55] om26er: if it's not yet allowed, it will probably be allowed sometime this week, in the mean time your snaps uploaded with lzo should be manually approved at some point soon [14:56] We are being extra cautious as enabling that for our snap would mean we won't be able to test the edge channel unless someone gets around to manual review. [14:57] I just pinged some store folks to check in on it, I don't see any in this channel [14:59] om26er: sounds like they are trying to get it deployed today, but it might get delayed [14:59] Ok, no problem, can revisit this close to end of week. [15:01] ijohnson can you also help with https://forum.snapcraft.io/t/download-snap-and-assert-without-snap-download-command/20869/9 ? Not sure what we need to do to avoid shipping core snap [15:01] om26er: I asked the store folks to comment on this forum post after it is deployed so you can just wait for an update here: https://forum.snapcraft.io/t/lzo-automatically-rejected/20860/11 [15:02] om26er: sorry I have been busy with other things, I will try to find some time to respond this week [15:02] * cachio lunch [15:02] Alright, cool. Thank you ;-) [15:04] * om26er should do a write up on running snapd with confinement on yocto based devices, with seeding a few snaps by default. [15:07] does anyone know which nvidia driver we recommend for debian users so snaps work for them ? [15:07] (i have a zoom issue where the driver doesnt seem to be found at all in the snap env) [16:30] mvo: I gave some inpunt in 9540 [16:30] pedronis: cool, thanks [16:32] pedronis: approved 9619, one suggestion about marking the mismatch in degraded.json I think [16:38] mvo: pedronis: should I review 9540 too ? [16:38] (since mborzecki is off today/tomorrow) [16:39] ijohnson: would be nice, should be simple, I applied pedronis feedback already but did not push yet, local spread run against the nested test is just running [16:39] mvo: ack I will start on that now [16:40] ijohnson: \o/ [16:42] mvo: it seems spread was unhappy for a bit at least, lots of read in my PR [16:43] ijohnson: the feedback aobut putting something in error-log seems fair [16:43] yeah seems useful to be able to know that [16:45] good morning [16:45] hey [16:45] hey, today was a busy day :) [16:46] good morning zyga ! [16:46] I worked on a flashing tool [16:46] and played with bus pirate and lava LMP boards from linaro days [16:46] hey mvo [16:46] how is core20? [16:46] zyga: closer than yesterday [16:47] more encryption complexity? [16:48] mvo: approved 9540, note that pedronis' suggestion had a typo, not sure if you just copy and pasted it in (I have done this before is the only reason I ask :-) ) [16:55] % /usr/lib/snapd/snapd --help [16:55] AppArmor status: apparmor is enabled and all features are available [16:55] cannot run daemon: cannot read the state file: open /var/lib/snapd/state.json: permission denied [16:56] ijohnson: thanks, I updated the string based on your suggestion [16:56] What's most amazing isn't that we missed --help, but that we never actually missed it.. [16:56] I need to do some errands and then I will push some tweaks to my PR [16:58] pedronis, ijohnson I will have dinner and check back, it seems we can still branch 2.48 today :) [16:58] :-) [17:00] mmm seems store is unhappy, lots of 4XX's from the store right now [17:03] niemeyer hello, could you help me restore my forum account? [17:03] zyga: Heya [17:03] zyga: Maybe [17:03] niemeyer I didn't realize it was using my @canonical.com address [17:04] zyga: I'll need to go through and see what's associated with it [17:04] Might be easier to rename/recreate [17:04] associated in which sense? [17:04] In the data sense [17:04] well, only the forum data, I suspect [17:09] zyga: It was indeed suspended by IS as part of the normal process [17:09] zyga: Easiest is probably to move it away and recreate it [17:09] with a different login name? I'd like to see all the previous pings I've got [17:12] zyga: Done.. you should be able to recreate your account with your original username [17:12] woot, [17:12] thank you [17:12] zyga: You won't see pings to the old user, though [17:12] ah, I see [17:12] zyga: As it still exists [17:12] oh well [17:13] thank you :) [17:13] No problem, welcome back, to some degree :) [17:14] Old user is zyga-snapd, FWIW [17:15] right, I've found that, thanks [17:24] pedronis: mvo: I retried thej obs in 9619, the store was a bit unwell this morning but should be good now [17:24] *the jobs [17:24] ijohnson: ah, I need to push to it anyway [17:25] pedronis: ah ok, well I guess it won't matter anyways [17:35] mvo: there was a bit of confusion my suggestion was to add the explantion of show-keys to the longer description of the command, and keep the short option description [17:39] ijohnson: I pushed changes to 9450 if you want to double check [17:39] heh sorry [17:39] ijohnson: I meant 9619 [17:45] pedronis: ack [17:47] ijohnson: mvo: couple more comments in 9450 [17:47] pedronis: one super minor error message suggestion in 9619 [17:47] but it can wait [17:48] pedronis: should I address your comments ti 9540 now? [17:49] ijohnson: if you can, not sure if mvo is taking a break or not, I will have dinner soon [17:50] ijohnson: we are not super consistent about , vs : in those kind of errors fwiw [17:51] pedronis: sure I can push it, to be clear you want this as the short option description though: [17:51] ``` [17:51] Show recovery keys (if available) to unlock encrypted partitions. [17:51] ``` [17:51] and then the longer one I proposed in the main help ? [17:51] Hmm.. apparently nothing checks whether snapd is actually under systemd before standing by [17:55] ijohnson: yes, something short like the original text [17:55] pedronis: ok, I will use exactly what I sent here in IRC [17:55] just a moment [17:56] PR snapd#9618 closed: tests: minor test tweaks suggested in the review of 9607 [17:56] niemeyer: it's quite possible, I think we found recently a few cases where some behavior doesn't check for context enough [17:56] * pedronis dinner [17:56] ijohnson: ^, afk to have a dinner for a bit [17:56] k [17:56] pedronis: It's one more of those cases that nobody cares too much really [17:57] Unless you're abusing snapd enough, in which case you know what to do and can fix it [17:57] pedronis: Enjoy! [18:15] PR snapcraft#3363 opened: repo: apt sources management refactor [18:15] PR snapcraft#3364 opened: project loader: ensure all key assets are utilized [18:21] ijohnson: I'm back now fwiw [18:22] ijohnson: anything I should do (reading backlog now)? [18:22] mvo I have itocally just waiting for spread run to confirm [18:22] So I can push the adjustments as soon as the spread run finishes [18:23] ijohnson: \o/ [18:23] ijohnson: thanks [18:33] mvo: pedronis: pushed === ijohnson is now known as ijohnson|lunch [18:35] ijohnson|lunch: thank you! [18:35] looks grat [18:35] great [19:18] ijohnson|lunch: mvo: I pushed another tweak to 9619 === ijohnson|lunch is now known as ijohnson [19:19] pedronis: mvo: still seems we have store troubles as of like 20ish minutes ago [19:19] pedronis: ack I'll take a look again at 9619 [19:19] might need some force merges [19:25] PR snapcraft#3365 opened: github actions: bootstrap CI workflow [19:31] ijohnson: sure, I have a look [20:21] PR snapd#9620 opened: spread.yaml: increase number of workers on 20.10 [20:32] ijohnson: still around? [20:32] yes [20:33] ijohnson: do you want to chat about https://github.com/snapcore/snapd/pull/9619/files#r520848163 ? [20:33] PR #9619: cmd/snap-bootstrap,o/devicestate: use a secret to pair data and save [20:33] pedronis: sure if you think there are things to discuss [20:33] ijohnson: I'm going to the SU [20:34] pedronis: ok be there in a moment [20:44] * cachio afk [20:56] ijohnson: pushed [20:56] ack, I'll look now