[06:30] morning [06:51] zyga: hey, have you tried #8272 with #8089? [06:51] PR #8272: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates [06:51] PR #8089: features: enable robust mount ns updates [07:00] good morning [07:00] mborzecki: I did [07:01] mborzecki: I ran a local test and it passed [07:01] I pushed the update to GH [07:01] haven't looked since [07:01] cool [07:01] man, my dog decided to do a marathon this morning [07:01] we woke up at 6:30 [07:01] and I took him for a walk because Iza was sleepy [07:01] and I just got back [07:01] nice [07:02] I left my coffee in the office and now it's cold :) [07:02] on the up side it is lovely outside [07:02] chance to get another one ;) [07:02] I need to charge my mouse, it ran out [07:02] time for that coffee I guess [07:02] mborzecki: yeah, it is green [07:03] yay [07:03] mborzecki: please review 8089 :) [07:03] or just leave a comment [07:03] I think we should get it for 2.44 [07:03] though I see it's marked for 2.45 [07:03] but I think only because it was red [07:03] I'll talk to mvo [07:04] mborzecki: btw, did you read about the new x13, t14, t14s and t15? [07:04] mborzecki: lenovo's new lineup of thinkpads [07:04] new thinkpads? [07:04] based on both 10th gen intel and ... 4th gen mobile ryzen :) [07:04] and [07:04] you won't believe this :) [07:04] the ryzen parts have longer battery life [07:04] 17.5h vs 17h intel [07:04] how the world has changed [07:04] hopefully they work better than the previous mobile lineup [07:05] x13 touts 8 core, 16 thread 32GB monster [07:05] people complained about the drivers and overall stability [07:05] and it has rather superb GPU for a x13-like box [07:05] time will tell [07:05] I wonder what they will do with naming though [07:05] will next year model be called just x113 [07:05] and then x213 [07:07] ok, mouse is charged now [07:07] oh, it seems there's also x13s [07:08] I will probably skip it as 16" is just superb and I rarely think about the thikpad now [07:08] but perhaps the next year refresh will go to the update of the linux-running laptop [07:08] I kind of want the x13 with +1 gen mobile ryzen [07:08] that has ray tracing acceleration [07:09] as I bet that the other life of that machine will be minecraft RT [07:09] ok, let's look at PRs [07:11] mborzecki: do you think https://github.com/snapcore/snapd/pull/8265 should be merged [07:11] PR #8265: tests: add regression test for MAAS refresh bug [07:11] or skipped [07:11] hm still drivers are key, hopefully they have resource to make linux support great [07:11] it's probably a "heavy" test [07:11] mborzecki: yeah, it's a big mystery as to how this works on linux [07:11] last mobile apu lineup ha bad support even on windows [07:11] mborzecki: I was briefly considering not putting linux on it as well [07:11] mborzecki: and tie this with WSL2 release in 2004 [07:11] (2004 as in windows 10 version) [07:12] idk if i want to trade one broken system for another ;) [07:12] are you sure? [07:12] have you seen it [07:12] it's pretty remarkable [07:13] say what you want but the chance that suspend and wifi works ok on windows is pretty much close to 100% [07:13] I think it will be the next battleground, what works best in WSL2 [07:13] I really think snapd should be a prime contender there [07:14] hm occasionally play witcher 3 on windows, kinda works, but there's tiny little details that could be improved [07:15] for one, getting my bt headphones connected is way easier with bluez & pa than on windows xD [07:16] or prehaps sony makes crap headphones that only work great with smartphones [07:17] mborzecki: I think you have to think wider [07:17] not use windows for witcher :) [07:17] mborzecki: use it for the witcher _and_ for work [07:17] for snapd [07:17] for hangouts [07:17] and see how that behaves [07:17] what's the experience of ubuntu on windows [07:17] I also think desktop vs laptop is key [07:17] haha no i'm too far gone [07:17] laptops are the majority of sold devices and, historically, those that struggle more on linux [07:17] are you sure, you might just like it :) [07:18] my point is, keep an open head [07:18] people will use WSL2 [07:18] it will explode [07:18] it will have more users than all non-virtual linux combined [07:18] and many times over [07:18] we should provide a great experience there [07:18] hard to know unless we try [07:20] mborzecki: and I'm not saying we should all switch to it entirely [07:20] just add it to the pool of thins we consider [07:25] mvo: hey [07:25] mvo: https://github.com/snapcore/snapd/pull/8279 is LGTM [07:25] I marked it as 2.44 [07:25] PR #8279: snap: do not hardlink on overlayfs [07:25] I think we haven't released it yet, right? [07:27] mvo: hey, 8272 is also marked for 2.44, be great to include it [07:28] zyga, mborzecki good morning [07:28] thanks guys, looking over the 2.44 stuff now [07:29] mvo: oh, one more thing [07:29] mvo: can we please reconsider https://github.com/snapcore/snapd/pull/8089 as 2.44 [07:29] PR #8089: features: enable robust mount ns updates [07:29] it's flipping the robust ns switch [07:29] and it should just go out already [07:30] zyga: let's talk with samuele, a bit worried that it makes it very late into 2.44 so we won't spot regression that easily (and then it's on the 20.04 cd) [07:31] PR snapd#8279 closed: snap: do not hardlink on overlayfs [07:34] PR snapd#8281 opened: snap: tweak comment in Install() for overlayfs detection [07:44] mborzecki: did you push the 1.10 formating changes to whitelist-lzo on purpose? [07:45] mvo: yues [07:45] mborzecki: some unhappy static test there or what's the reason? [07:48] mborzecki: aha, I see now [07:49] mborzecki: it looks like the static test failure is a red-herring, there is a real unit test issue it seems that I overlooked [07:49] mborzecki: in TestPackPacksASnapWithCompressionUnhappy [07:52] heh, missed that [07:52] mborzecki: no worries [07:53] mborzecki: I fixed and force pushed [07:53] mborzecki: I often wondered why the go test output we have is so unreadable :( [07:53] mvo: ta [07:53] mborzecki: but never had enough energy to look [07:53] mborzecki: like, when a unit test in the middle fails it's really hard to spot [07:54] mvo: yeah, it's a wall of text [08:01] morning [08:07] pstolowski: morning, may i entertain you with a review https://github.com/snapcore/snapd/pull/8272 [08:07] PR #8272: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates [08:07] it's green and ripe for landing ;) [08:10] mborzecki: looking [08:14] mvo: we could test without -verbose [08:14] hey pawel :) [08:15] pstolowski: thanks! [08:22] zyga: interessting, yeah, I think that helps a bit [08:27] PR snapd#8282 opened: run-tests: disable -v for go test to avoid spaming the logs [08:29] PR snapd#8273 closed: interfaces/greengrass-support: add new 1.9 access [08:29] PR snapd#8274 closed: interfaces/greengrass-support: add new 1.9 access (2.44) [08:30] PR snapd#8272 closed: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates [08:30] yay [08:31] mvo: can you cherry pick the patches from 8272 to 2.44? [08:34] mborzecki: yes, just did that, thank you! [08:34] mvo: thanks! [08:34] mborzecki: once you see samuele, we need a review for 8275, I would love to include that too [08:36] mvo: i want to add a unit test there too [08:41] PR snapd#8217 closed: o/devicestate: delay the creation of mark-seeded task until asserts are loaded [08:47] PR snapd#8246 closed: client, daemon, overlord/devicestate: structures and stubs for systems API [08:48] PR snapd#8283 opened: overlord,timings,daemon: separate timings from overlord/state [09:08] wow, our daemon tests setup is complicated [09:14] nottrobin: thanks! [09:29] pedronis: #8280 +1, thank you! [09:29] PR #8280: many: introduce snapdenv.Preseeding instead of release.PreseedMode [09:32] * zyga is not feeling very good today and will focus on reviews [09:32] at least for a while [09:35] pedronis: if you have a chance, could you please check https://github.com/snapcore/snapd/pull/8275 ? [09:35] PR #8275: daemon: do a forceful server shutdown if we hit a deadline [09:36] mvo: yes, it was one of the first things I wanted to look at today [09:38] PR snapd#8280 closed: many: introduce snapdenv.Preseeding instead of release.PreseedMode [09:40] pstolowski: thx for the review, I also made this: https://github.com/snapcore/snapd/pull/8283 bit annoying [09:40] PR #8283: overlord,timings,daemon: separate timings from overlord/state [09:41] pedronis: yes, i'll review it soon [09:45] zyga, hi, I just got this error: https://paste.ubuntu.com/p/pv3MQwTGTk/ with robust namespaces on. not sure if it's the same issue as before [09:46] hmm [09:46] it is a different issue [09:46] not device or resource busy (removing a mount point) [09:46] zyga, trying again (the snap is still there) I get: https://paste.ubuntu.com/p/nTZvF7s6mq/ [09:47] do you have instructions to reproduce [09:47] the mount system is not perfect, there are known limitations that end up with things like that [09:47] zyga, well, I just had a maas snap installed via "snap try" and tried to remove it [09:47] ackk: can you try (as in wipe and try again) to see if it happens [09:47] zyga, you mean reproduce from a clean state? [09:48] yes please [09:48] if it is reproducible that's awesome [09:48] zyga, I'll try [09:48] zyga, how do I get out of this situation though? I'd need to remove the maas snap [09:48] shoulld I just reboot? [09:48] *should [09:48] discard the ns [09:49] ah yeah that worked thanks [09:57] zyga, clean bionic container: https://paste.ubuntu.com/p/PBVtYywcJF/ [09:57] thanks, I'll jump into it after today reviews [09:58] zyga, you want me to file a bug or are you ok with just the paste? [09:58] a bug is best [09:58] those regression/lp- things are great way to organize things like that [10:06] mborzecki: hi, +1 on 8275 with some suggestions [10:06] pedronis: thanks! [10:25] PR snapcraft#2976 closed: cli: formalize developer debug as hidden build option [10:25] PR snapcraft#2981 closed: colcon plugin: rewrite poco absolute library paths [10:26] zyga, https://bugs.launchpad.net/snapd/+bug/1867752 [10:26] Bug #1867752: Unable to remove snap with content interface (with robust namespace on) [10:41] snapd in focal fails to build with unit test error [10:41] zyga, sparkiegeek added some extra info to that bug, FTR [10:42] right, specifically output with SNAPD_DEBUG=1 [10:42] but that was after attempting the initial removal (install, remove, set debugging, reload snapd, remove again) [10:42] filed https://bugs.launchpad.net/snapd/+bug/1867755 if someone wants to dig [10:42] Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails [10:43] thanks, ackk, sparkiegeek: I will look at that soon [10:43] zyga: thanks! [10:43] zyga, ty [10:57] * zyga has some annoying back pain all morning :/ [10:57] pleas forgive me if I'm somehow grumpy [11:23] mborzecki: when you have a moment can you do a first pass #8159 as well [11:23] PR #8159: snap-bootstrap: remove created partitions on reinstall [11:23] pedronis: sure, will do [11:40] PR snapd#8281 closed: snap: tweak comment in Install() for overlayfs detection [12:02] mborzecki: https://github.com/snapcore/snapd/pull/8275/files is really interesting (the test) [12:02] PR #8275: daemon: do a forceful server shutdown if we hit a deadline [12:22] abeato: reviewed https://github.com/snapcore/snapd/pull/8271#pullrequestreview-375973389 [12:22] PR #8271: interfaces: add hugepages-control [12:23] zyga, cool, thanks [12:40] PR snapd#8276 closed: snap: whitelist lzo as support compression for snap pack [12:55] mvo: #8251 has a conflict [12:55] PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks [12:58] pstolowski: thanks, will fix [12:59] * zyga did some stretching and feels less pain :) [13:01] PR snapd#8268 closed: snap-seccomp: robustness improvements [13:01] PR snapd#8282 closed: run-tests: disable -v for go test to avoid spaming the logs [13:09] hi folks [13:21] hey ian [13:21] hey zyga [13:21] * zyga installs debian on metal [13:23] PR snapcraft#2974 closed: project_loader: use -isystem instead of -I for system include paths [13:36] ackk: hey, can you tell my why maas puts a layout on /root ? [13:40] zyga, so ssh can find authorized_keys [13:40] ssh? [13:40] does maas bundle ssh? [13:40] zyga, yes (the client) [13:40] aha [13:40] hmmm [13:40] I mean [13:41] that ssh goes into maas [13:41] not into the host, right? [13:41] PR snapcraft#2978 closed: tests: add microk8s spread test [13:41] PR snapcraft#2979 closed: tests: add multipass adhoc spread backend [13:41] PR snapcraft#2980 closed: vcs: add direnv files to .gitignore [13:41] zyga, maas uses ssh to connect to remote virsh [13:41] I see [13:41] and there's no way to say, hey, ssh, pick those keys? [13:41] I mean [13:42] layout over /root feels a bit too powerful [13:42] not that it buys you anything [13:42] but it's a bit weird too [13:42] zyga, no, ~/.ssh is hardcoded [13:42] (I would think for security purposes) [13:42] ah [13:42] can you put a layout over /root/.ssh [13:42] would be cleaner IMO [13:42] zyga, why powerful? it's not exposing the host /root, it's putting a dir over /root [13:43] the snap container one [13:43] powerful in the sense that is has broad effect for the app [13:43] it's not a security issue [13:43] zyga, sure, but that's kinda intended [13:43] zyga, is this causing issues with snapd? [13:44] zyga, I mean, would it be different if we changed the overlay? [13:44] yes [13:44] but that's a real bug I will fix anyway [13:44] it just happens to happen that this causes a bug :) [13:44] I will have details soon [13:44] and a fix [13:44] I was mostly curious about /root, [13:46] zyga, cool [13:47] ackk: in addition I would suggest using $SNAP_COMMON [13:47] otherwise each revision has lots of mount changes for that [13:47] but it's not cancelling that two other layouts so perhaps not that important [13:47] as you wish [13:47] zyga, ah I see [14:04] Lukewh: [14:04] bah [14:04] bah to you too [14:04] lol [14:04] ackk: https://bugs.launchpad.net/snapd/+bug/1867752/comments/6 [14:04] Bug #1867752: Unable to remove snap with content interface (with robust namespace update) [14:05] we should really run *all* tests in lxd [14:05] eh [14:05] zyga, thanks. great that you found the source of the issue [14:05] zyga, why does LXD make a difference in this case? [14:06] ackk: as I indicated, because the filesystem type for snaps is no longer squashfs but fuse [14:07] oh, I missed that detail, I see [14:07] thank you for this bug report [14:07] it's a great find [14:07] I think this never worked correctly [14:07] to the extent that all the squashfs checks were moot [14:09] it'd be great if lxd could passthrough kernel modules to containers, so that they could use proper squashfs [14:12] ackk: it's not that [14:12] ackk: containers cannot mount things because that's really the kernel mounting things [14:12] ackk: so containers could attack all FS code [14:12] and that's considered unsafe [14:12] I see [14:13] I would love if lxd had some magic where it could identify squashfs that is signed and trusted (fs_verity maybe) and allow mounting that [14:13] stgraber: ^ maybe crazy idea [14:16] the problem is that if the user has access to the underlying file, they can still mess with it while the kernel has it mounted [14:16] so us doing any kind of hashing would just be a TOCTOU race [14:17] and dm-verity on loop would similarly only really be trustable if there was no way for root in the container to modify the file that's assigned to the loop [14:19] stgraber: indeed, that's true [15:10] * zyga breaks for lunch === adrian- is now known as alvesadrian [15:22] hello guys [15:22] since snap [15:22] is an squashfs [15:22] means read only [15:22] how u can write data on it? [15:23] I hafe a case where i need to write data afer install in conf files of the snap [15:23] user data [15:23] how this can be orted if snap is an squashfs? [15:24] there is a way to sort this out??? [15:25]