[00:36] zyga[m]: hmm from a quick look I think it should be safe to allow kcmp in the default template - docker allows it in their base template https://github.com/moby/moby/blob/0ec744f43b52dd0b3065b84e685b89a2ede1dd8e/profiles/seccomp/default.json#L716 so I think we probably should too [05:55] morning [06:50] PR snapd#11861 opened: interfaces/system-packages-doc: allow read-only access to /usr/share/cups/doc-root/ and /usr/share/gimp/2.0/help/ (https://bugzilla.mozilla.org/show_bug.cgi?id=1770462) [06:53] zyga[m]: Hi! If I can dig a bit into your memory :-) Are you aware of any circumstance, under which a layout would end up being done twice? That is, on the desired mount point the same source is being bind-mounted twice (it's a file) [06:56] mborzecki: hi, I thought you were off today? [06:56] mardy: hey, yeah though so too, but apparently can't even use the calendar properly 🙂 [06:57] mardy, I just sent a PR for fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1770462 [06:59] mardy, osomon suggested me to do so, at least to open discussion on the matter, even if we both agree on the long term it might be a can of worm :/ [07:04] lissyx: nice, thanks! [07:04] (I have not yet signed the CLA because I'm unsure how to sign) [07:05] * mardy wonders if snapd is smart enough not to panic if the requested mount source is not found (that is, if gimp is not installed) [07:05] lissyx: did you fill this? https://ubuntu.com/legal/contributors/agreement [07:06] mardy, not this "how to" [07:06] I will be around in 30 min mardy: [07:06] mardy, rather "maybe mozilla is already signed? (I would expect so)" and "is it fine if I sign as an individual even if it's part of my work" [07:06] legalities ... [07:10] lissyx: uh, I'm not sure how it works if you are part of an organization [07:10] exactly [07:11] and I need to wait for some colleagues to wake up, we're looking at US west coast so later today :) [07:12] mardy: nothing rings a bell, I was initially thinking it could be some weird propagation but cannot think of a scenario when this would happen [07:27] mardy, ok it's signed but I have tests failures and I'm unable to understand them [07:30] oh little tests/main/interfaces-system-packages-doc/task.yaml [08:06] mardy, looks like I need you to re-review to run the updated PR https://github.com/snapcore/snapd/pull/11861 [08:06] PR #11861: interfaces/system-packages-doc: allow read-only access to /usr/share/cups/doc-root/ and /usr/share/gimp/2.0/help/ (https://bugzilla.mozilla.org/show_bug.cgi?id=1770462) [08:06] mardy, it should address the comment as well as fix the tests, I hope [08:37] mardy: lissyx: AFAIU there's no additional CLA check needed for accounts @mozilla.org as we have an organization level CLA or whatnot [08:39] mborzecki, not sure what you mean [08:40] lissyx: i thought you've signed the commit with some @mozilla.org account, if not then please ignore 😉 [08:40] define @mozilla.org ? [08:40] are you referring to the github org? or email address? [08:42] lissyx: email address [08:43] I used a mozilla.com [08:43] lissyx: fwiw the PR looks good to me, thank you for filing it, I've approved the CI run [08:43] cla-check somehow failed? [08:43] oh boy [08:43] lissyx: pretty sure https://github.com/snapcore/snapd/commit/1164e6f2b502b6203733d1bada6638854b516039.patch is using lissyx.dyndns.org [08:44] tooling constantly assumes same email everywhere ... [08:44] rewrote it [08:44] lissyx: you can --reset-author and force push 🙂 [08:45] I just did [08:45] lissyx: it's @free.fr now 🙂 [08:45] I guess you'll have to unblock CI once [08:45] yeah that should be the primary email of my launchpad account [08:46] cool, so then the cla check should be green [08:46] grmbl [08:47] it considers I have not signeed it ... [08:47] just take the PR and land it for me? [08:53] lissyx: fwiw it should be as simple as clicking through https://ubuntu.com/legal/contributors/agreement [08:53] mborzecki, I already did all of that [08:53] correct launchpadid and github account [08:54] lissyx: ok, let's wait a little bit, maybe there's some batch job that processes that, if not i'll ask mvo to take a look [09:09] mborzecki, looks like we're good for another round of approving, there was an assert on length I forgot [09:17] lissyx: it's running now [09:28] mborzecki, there's a failure and I'm unsure it is me: https://github.com/snapcore/snapd/runs/6828239687?check_suite_focus=true [09:35] PR snapd#11814 closed: cmd/snap: cleanup and make the code a bit easier to read/maintain for quota options [09:55] PR snapd#11862 opened: tests: add nested test variant that adds 4k sector size [10:11] PR snapd#11863 opened: tests: enable nested tpm test for core22 [10:19] PR snapcraft#3786 closed: providers: update craft-providers [12:10] so gio's g_file_get_path() return null when running under a snap [12:10] even if the snap is installed in devmode [12:11] and journalctl does not show anything [12:22] lissyx: that CI testing fail you linked earlier is failing in the cmd/snap-repair directory - if you haven't touched that directory then you're fine (I don't think you would have to be fixing a firefox-related issue) [12:56] PR snapd#11864 opened: many: add migrate-home debug command [13:01] PR snapd#11859 closed: secboot/keymgr, cmd/snap-fde-keymgr: two step encryption key change [13:14] diddledani, well I'll let you people verify and merge if it's okay [13:14] or just ping me if I need to fix something ? [13:26] PR snapd#11863 closed: tests: enable nested tpm test for core22 [13:26] PR snapd#11865 opened: secboot: stage and transition encryption keys [14:41] PR snapd#11866 opened: data: start snapd after time-set.target [14:52] PR snapd#11867 opened: squashfs: improve error reporting when `unsquashfs` fails [14:57] PR snapd#11813 closed: overlord/ifacestate: add journal bind-mount snap layout when snap is in a journal quota group (4/n)