[01:42] PR snapcraft#3583 opened: build providers: snapcraft's new base is core20 (CRAFT-544) === popey2 is now known as popey [05:56] Bug #1944625 changed: snapctl returns EOF [07:03] morning [07:20] PR snapd#10822 closed: spread: display information about current device cgroup in debug dump [07:20] PR snapd#10823 closed: sysconfig: set TMPDIR in tests to avoid cluttering the real /tmp [07:30] PR snapd#10814 closed: o/ifacestate: don't lose connections if snaps are broken [07:35] PR snapd#10715 closed: secboot: move to new version [07:53] pstolowski: hi! [07:55] PR snapd#10815 closed: fde: add HasDeviceUnlock() helper [07:55] PR snapd#10830 opened: gadget: add `encryptedDevice` and add encryptedDeviceLUKS [08:47] mvo: could you please merge https://github.com/snapcore/snapd/pull/10810 ? [08:47] PR #10810: o/assertstate, api: update validation set assertions only when updating all snaps [08:47] sure [08:50] PR snapd#10810 closed: o/assertstate, api: update validation set assertions only when updating all snaps [09:46] thanks! [10:16] Hi. Can someone tell me why does snapd create directories under /root/snap/ when installing? Is it intended behavior or should it be using the user's home? [10:18] miguelpires: are you sure? i just did a quick test and don't see it. this normally happens if you run the snap for the first case as the given user [10:18] s/case/time/ [10:21] Yeah, I just tried installing again and it's there, so it's created during install (I assumed because installed as root). Then when doing snap run, the app's files are written to ~/snap so /root/snap is just empty [10:22] Also, I noticed this while testing my ~/.snap changes, there were AppArmor denials for /root/.snap [10:27] miguelpires: ok, i think the first depends on whether the snap has hooks or not [10:27] miguelpires: i can confirm /root/snap/skype gets created on install for skype, but not for hello-world snap [10:27] because skype has configure hook [10:27] (which does nothing :}) [10:30] miguelpires: these user directories get created by snap run (cmd_run.go) for the user who executes it, and hooks are run via snap run --hook=... by snapd as root user [10:30] makes sense? [10:30] Ah, then it's intended for that case. I saw that snap-confine was getting permission denied during the install when writing to /root/snap because it was called by 'snap run --hook'. I wasn't sure why the directory was different [10:30] yes, exactly. Makes sense. Thank you [10:31] yw [11:05] PR snapd#10831 opened: osutil: add new `CreateLinearMapper` helper [11:45] mvo: can you please merge https://github.com/snapcore/snapd/pull/10630 ? AFAICT, the failures are unrelated [11:45] PR #10630: o/snapstate: update default provider if missing required content [12:00] miguelpires: sure [12:01] PR snapd#10630 closed: o/snapstate: update default provider if missing required content [12:04] ty [12:21] PR snapd#10832 opened: tests: skip system-usernames-microk8s when TRUST_TEST_KEYS is false [12:45] damn, conflicts when merging large test files (here: snapstate_update_test.go) can be quite confusing [13:33] mvo: can you merge https://github.com/snapcore/snapd/pull/10812 please? The test failures are unrelated [13:33] PR #10812: o/ifacestate: don't fail remove if disconnect hook fails [14:01] PR snapd#10833 opened: tests: fix error trying to create the extra-snaps dir which already exists [14:23] PR snapcraft#3583 closed: build providers: snapcraft's new base is core20 (CRAFT-544) [14:28] ijohnson[m], hi, I see this in the netplan test https://paste.ubuntu.com/p/sm7kP7Gzc3/ [14:29] should we skip it, right? [14:29] core20 snap is not available on i386 [14:30] cachio_: yes good catch [14:31] still don't know why it is not failing on ubuntu-18-32 [14:31] ijohnson[m], any idea? [14:32] ahh, it is not executed tehre [14:32] is in the core suite [14:32] ijohnson[m]: thanks for your feedback about 10831 any opinion on the https://github.com/snapcore/snapd/pull/10831/files#r714698094 maybe? [14:32] PR #10831: osutil/disks: add new `CreateLinearMapper` helper [14:34] mvo did you mean more opinions? I left some opinions, not sure I have more I can try and think of some more if you like haha [14:34] ijohnson[m]: I meant specifically about the suggestion from alberto what kind of "size" should be passed in - or did a miss a comment from you there maybe :) ? [14:35] Oh sorry the link didn't work for me to see that comment [14:35] Let me take a look [14:35] Maybe I do have more opinions for you [14:35] :-) [14:37] ijohnson[m]: excellent, sorry if I pasted the wrong link! [14:39] mvo: I think the link to the comment you pasted was before you pushed the updates, so it references a comment that doesn't exist, whereas if you grab the link from the main PR page and not the files one, that is more "persistent" [14:40] mvo: oh noes though you are hard-coding the block size [14:40] or wait was it sector size that was the problem [14:43] ijohnson[m]: yeah, afaik blocks are ok [14:46] PR snapd#10834 opened: tests: fix netplan test on i386 architecture [14:51] mvo: ok I left a review for you [14:51] PR snapd#10828 closed: tests: cleanup the job workspace as first step of the actions workflow [14:51] PR snapd#10829 closed: tests: use our own image for ubuntu impish [14:51] cachio_: +1 to that PR thanks for catching that too [14:52] ijohnson[m], yaw [14:57] ijohnson[m], mardy pr updated [15:06] PR snapd#10835 opened: tests: fix lxd-mount-units test which is based on core20 in ubuntu focal system [15:34] mvo: I think #7700 is ready to land now [15:34] PR #7700: cmd/snap: wait while inhibition file is present <:birthday:> [15:34] ijohnson[m]: yay [15:35] 🙂 [15:41] PR snapd#7700 closed: cmd/snap: wait while inhibition file is present <:birthday:> [15:42] \o/ [15:45] ijohnson[m]: I also updated the mapper one :) [15:50] thanks! [15:57] * mvo hugs mardy pstolowski ijohnson[m] for their excellent reviews [16:40] woot, I'm so happy to see those branches finished and merged :) [23:28] PR snapd#10836 opened: many: add experimental setting to move ~/snap to ~/.snap/data