| mborzecki | morning | 06:30 |
|---|---|---|
| mborzecki | zyga: hey, have you tried #8272 with #8089? | 06:51 |
| mup | PR #8272: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8272> | 06:51 |
| mup | PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089> | 06:51 |
| zyga | good morning | 07:00 |
| zyga | mborzecki: I did | 07:00 |
| zyga | mborzecki: I ran a local test and it passed | 07:01 |
| zyga | I pushed the update to GH | 07:01 |
| zyga | haven't looked since | 07:01 |
| mborzecki | cool | 07:01 |
| zyga | man, my dog decided to do a marathon this morning | 07:01 |
| zyga | we woke up at 6:30 | 07:01 |
| zyga | and I took him for a walk because Iza was sleepy | 07:01 |
| zyga | and I just got back | 07:01 |
| mborzecki | nice | 07:01 |
| zyga | I left my coffee in the office and now it's cold :) | 07:02 |
| zyga | on the up side it is lovely outside | 07:02 |
| mborzecki | chance to get another one ;) | 07:02 |
| zyga | I need to charge my mouse, it ran out | 07:02 |
| zyga | time for that coffee I guess | 07:02 |
| zyga | mborzecki: yeah, it is green | 07:02 |
| mborzecki | yay | 07:03 |
| zyga | mborzecki: please review 8089 :) | 07:03 |
| zyga | or just leave a comment | 07:03 |
| zyga | I think we should get it for 2.44 | 07:03 |
| zyga | though I see it's marked for 2.45 | 07:03 |
| zyga | but I think only because it was red | 07:03 |
| zyga | I'll talk to mvo | 07:03 |
| zyga | mborzecki: btw, did you read about the new x13, t14, t14s and t15? | 07:04 |
| zyga | mborzecki: lenovo's new lineup of thinkpads | 07:04 |
| mborzecki | new thinkpads? | 07:04 |
| zyga | based on both 10th gen intel and ... 4th gen mobile ryzen :) | 07:04 |
| zyga | and | 07:04 |
| zyga | you won't believe this :) | 07:04 |
| zyga | the ryzen parts have longer battery life | 07:04 |
| zyga | 17.5h vs 17h intel | 07:04 |
| zyga | how the world has changed | 07:04 |
| mborzecki | hopefully they work better than the previous mobile lineup | 07:04 |
| zyga | x13 touts 8 core, 16 thread 32GB monster | 07:05 |
| mborzecki | people complained about the drivers and overall stability | 07:05 |
| zyga | and it has rather superb GPU for a x13-like box | 07:05 |
| zyga | time will tell | 07:05 |
| zyga | I wonder what they will do with naming though | 07:05 |
| zyga | will next year model be called just x113 | 07:05 |
| zyga | and then x213 | 07:05 |
| zyga | ok, mouse is charged now | 07:07 |
| zyga | oh, it seems there's also x13s | 07:07 |
| zyga | I will probably skip it as 16" is just superb and I rarely think about the thikpad now | 07:08 |
| zyga | but perhaps the next year refresh will go to the update of the linux-running laptop | 07:08 |
| zyga | I kind of want the x13 with +1 gen mobile ryzen | 07:08 |
| zyga | that has ray tracing acceleration | 07:08 |
| zyga | as I bet that the other life of that machine will be minecraft RT | 07:09 |
| zyga | ok, let's look at PRs | 07:09 |
| zyga | mborzecki: do you think https://github.com/snapcore/snapd/pull/8265 should be merged | 07:11 |
| mup | PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265> | 07:11 |
| zyga | or skipped | 07:11 |
| mborzecki | hm still drivers are key, hopefully they have resource to make linux support great | 07:11 |
| zyga | it's probably a "heavy" test | 07:11 |
| zyga | mborzecki: yeah, it's a big mystery as to how this works on linux | 07:11 |
| mborzecki | last mobile apu lineup ha bad support even on windows | 07:11 |
| zyga | mborzecki: I was briefly considering not putting linux on it as well | 07:11 |
| zyga | mborzecki: and tie this with WSL2 release in 2004 | 07:11 |
| zyga | (2004 as in windows 10 version) | 07:11 |
| mborzecki | idk if i want to trade one broken system for another ;) | 07:12 |
| zyga | are you sure? | 07:12 |
| zyga | have you seen it | 07:12 |
| zyga | it's pretty remarkable | 07:12 |
| zyga | say what you want but the chance that suspend and wifi works ok on windows is pretty much close to 100% | 07:13 |
| zyga | I think it will be the next battleground, what works best in WSL2 | 07:13 |
| zyga | I really think snapd should be a prime contender there | 07:13 |
| mborzecki | hm occasionally play witcher 3 on windows, kinda works, but there's tiny little details that could be improved | 07:14 |
| mborzecki | for one, getting my bt headphones connected is way easier with bluez & pa than on windows xD | 07:15 |
| mborzecki | or prehaps sony makes crap headphones that only work great with smartphones | 07:16 |
| zyga | mborzecki: I think you have to think wider | 07:17 |
| zyga | not use windows for witcher :) | 07:17 |
| zyga | mborzecki: use it for the witcher _and_ for work | 07:17 |
| zyga | for snapd | 07:17 |
| zyga | for hangouts | 07:17 |
| zyga | and see how that behaves | 07:17 |
| zyga | what's the experience of ubuntu on windows | 07:17 |
| zyga | I also think desktop vs laptop is key | 07:17 |
| mborzecki | haha no i'm too far gone | 07:17 |
| zyga | laptops are the majority of sold devices and, historically, those that struggle more on linux | 07:17 |
| zyga | are you sure, you might just like it :) | 07:17 |
| zyga | my point is, keep an open head | 07:18 |
| zyga | people will use WSL2 | 07:18 |
| zyga | it will explode | 07:18 |
| zyga | it will have more users than all non-virtual linux combined | 07:18 |
| zyga | and many times over | 07:18 |
| zyga | we should provide a great experience there | 07:18 |
| zyga | hard to know unless we try | 07:18 |
| zyga | mborzecki: and I'm not saying we should all switch to it entirely | 07:20 |
| zyga | just add it to the pool of thins we consider | 07:20 |
| zyga | mvo: hey | 07:25 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/8279 is LGTM | 07:25 |
| zyga | I marked it as 2.44 | 07:25 |
| mup | PR #8279: snap: do not hardlink on overlayfs <Bug> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8279> | 07:25 |
| zyga | I think we haven't released it yet, right? | 07:25 |
| mborzecki | mvo: hey, 8272 is also marked for 2.44, be great to include it | 07:27 |
| mvo | zyga, mborzecki good morning | 07:28 |
| mvo | thanks guys, looking over the 2.44 stuff now | 07:28 |
| zyga | mvo: oh, one more thing | 07:29 |
| zyga | mvo: can we please reconsider https://github.com/snapcore/snapd/pull/8089 as 2.44 | 07:29 |
| mup | PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089> | 07:29 |
| zyga | it's flipping the robust ns switch | 07:29 |
| zyga | and it should just go out already | 07:29 |
| mvo | 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:30 |
| mup | PR snapd#8279 closed: snap: do not hardlink on overlayfs <Bug> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8279> | 07:31 |
| mup | PR snapd#8281 opened: snap: tweak comment in Install() for overlayfs detection <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8281> | 07:34 |
| mvo | mborzecki: did you push the 1.10 formating changes to whitelist-lzo on purpose? | 07:44 |
| mborzecki | mvo: yues | 07:45 |
| mvo | mborzecki: some unhappy static test there or what's the reason? | 07:45 |
| mvo | mborzecki: aha, I see now | 07:48 |
| mvo | 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 |
| mvo | mborzecki: in TestPackPacksASnapWithCompressionUnhappy | 07:49 |
| mborzecki | heh, missed that | 07:52 |
| mvo | mborzecki: no worries | 07:52 |
| mvo | mborzecki: I fixed and force pushed | 07:53 |
| mvo | mborzecki: I often wondered why the go test output we have is so unreadable :( | 07:53 |
| mborzecki | mvo: ta | 07:53 |
| mvo | mborzecki: but never had enough energy to look | 07:53 |
| mvo | mborzecki: like, when a unit test in the middle fails it's really hard to spot | 07:53 |
| mborzecki | mvo: yeah, it's a wall of text | 07:54 |
| pstolowski | morning | 08:01 |
| mborzecki | pstolowski: morning, may i entertain you with a review https://github.com/snapcore/snapd/pull/8272 | 08:07 |
| mup | PR #8272: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8272> | 08:07 |
| mborzecki | it's green and ripe for landing ;) | 08:07 |
| pstolowski | mborzecki: looking | 08:10 |
| zyga | mvo: we could test without -verbose | 08:14 |
| zyga | hey pawel :) | 08:14 |
| mborzecki | pstolowski: thanks! | 08:15 |
| mvo | zyga: interessting, yeah, I think that helps a bit | 08:22 |
| mup | PR snapd#8282 opened: run-tests: disable -v for go test to avoid spaming the logs <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8282> | 08:27 |
| mup | PR snapd#8273 closed: interfaces/greengrass-support: add new 1.9 access <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8273> | 08:29 |
| mup | PR snapd#8274 closed: interfaces/greengrass-support: add new 1.9 access (2.44) <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8274> | 08:29 |
| mup | PR snapd#8272 closed: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8272> | 08:30 |
| mborzecki | yay | 08:30 |
| mborzecki | mvo: can you cherry pick the patches from 8272 to 2.44? | 08:31 |
| mvo | mborzecki: yes, just did that, thank you! | 08:34 |
| mborzecki | mvo: thanks! | 08:34 |
| mvo | mborzecki: once you see samuele, we need a review for 8275, I would love to include that too | 08:34 |
| mborzecki | mvo: i want to add a unit test there too | 08:36 |
| mup | PR snapd#8217 closed: o/devicestate: delay the creation of mark-seeded task until asserts are loaded <Bug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8217> | 08:41 |
| mup | PR snapd#8246 closed: client, daemon, overlord/devicestate: structures and stubs for systems API <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8246> | 08:47 |
| mup | PR snapd#8283 opened: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <https://github.com/snapcore/snapd/pull/8283> | 08:48 |
| mborzecki | wow, our daemon tests setup is complicated | 09:08 |
| cjwatson | nottrobin: thanks! | 09:14 |
| pstolowski | pedronis: #8280 +1, thank you! | 09:29 |
| mup | PR #8280: many: introduce snapdenv.Preseeding instead of release.PreseedMode <Created by pedronis> <https://github.com/snapcore/snapd/pull/8280> | 09:29 |
| * zyga is not feeling very good today and will focus on reviews | 09:32 | |
| zyga | at least for a while | 09:32 |
| mvo | pedronis: if you have a chance, could you please check https://github.com/snapcore/snapd/pull/8275 ? | 09:35 |
| mup | PR #8275: daemon: do a forceful server shutdown if we hit a deadline <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8275> | 09:35 |
| pedronis | mvo: yes, it was one of the first things I wanted to look at today | 09:36 |
| mup | PR snapd#8280 closed: many: introduce snapdenv.Preseeding instead of release.PreseedMode <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8280> | 09:38 |
| pedronis | pstolowski: thx for the review, I also made this: https://github.com/snapcore/snapd/pull/8283 bit annoying | 09:40 |
| mup | PR #8283: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <https://github.com/snapcore/snapd/pull/8283> | 09:40 |
| pstolowski | pedronis: yes, i'll review it soon | 09:41 |
| ackk | 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:45 |
| zyga | hmm | 09:46 |
| zyga | it is a different issue | 09:46 |
| zyga | not device or resource busy (removing a mount point) | 09:46 |
| ackk | zyga, trying again (the snap is still there) I get: https://paste.ubuntu.com/p/nTZvF7s6mq/ | 09:46 |
| zyga | do you have instructions to reproduce | 09:47 |
| zyga | the mount system is not perfect, there are known limitations that end up with things like that | 09:47 |
| ackk | zyga, well, I just had a maas snap installed via "snap try" and tried to remove it | 09:47 |
| zyga | ackk: can you try (as in wipe and try again) to see if it happens | 09:47 |
| ackk | zyga, you mean reproduce from a clean state? | 09:47 |
| zyga | yes please | 09:48 |
| zyga | if it is reproducible that's awesome | 09:48 |
| ackk | zyga, I'll try | 09:48 |
| ackk | zyga, how do I get out of this situation though? I'd need to remove the maas snap | 09:48 |
| ackk | shoulld I just reboot? | 09:48 |
| ackk | *should | 09:48 |
| zyga | discard the ns | 09:48 |
| ackk | ah yeah that worked thanks | 09:49 |
| ackk | zyga, clean bionic container: https://paste.ubuntu.com/p/PBVtYywcJF/ | 09:57 |
| zyga | thanks, I'll jump into it after today reviews | 09:57 |
| ackk | zyga, you want me to file a bug or are you ok with just the paste? | 09:58 |
| zyga | a bug is best | 09:58 |
| zyga | those regression/lp- things are great way to organize things like that | 09:58 |
| pedronis | mborzecki: hi, +1 on 8275 with some suggestions | 10:06 |
| mborzecki | pedronis: thanks! | 10:06 |
| mup | PR snapcraft#2976 closed: cli: formalize developer debug as hidden build option <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2976> | 10:25 |
| mup | PR snapcraft#2981 closed: colcon plugin: rewrite poco absolute library paths <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2981> | 10:25 |
| ackk | zyga, https://bugs.launchpad.net/snapd/+bug/1867752 | 10:26 |
| mup | Bug #1867752: Unable to remove snap with content interface (with robust namespace on) <snapd:New> <https://launchpad.net/bugs/1867752> | 10:26 |
| zyga | snapd in focal fails to build with unit test error | 10:41 |
| ackk | zyga, sparkiegeek added some extra info to that bug, FTR | 10:41 |
| sparkiegeek | right, specifically output with SNAPD_DEBUG=1 | 10:42 |
| sparkiegeek | but that was after attempting the initial removal (install, remove, set debugging, reload snapd, remove again) | 10:42 |
| zyga | filed https://bugs.launchpad.net/snapd/+bug/1867755 if someone wants to dig | 10:42 |
| mup | Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails <snapd:New> <https://launchpad.net/bugs/1867755> | 10:42 |
| zyga | thanks, ackk, sparkiegeek: I will look at that soon | 10:43 |
| sparkiegeek | zyga: thanks! | 10:43 |
| ackk | zyga, ty | 10:43 |
| * zyga has some annoying back pain all morning :/ | 10:57 | |
| zyga | pleas forgive me if I'm somehow grumpy | 10:57 |
| pedronis | mborzecki: when you have a moment can you do a first pass #8159 as well | 11:23 |
| mup | PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159> | 11:23 |
| mborzecki | pedronis: sure, will do | 11:23 |
| mup | PR snapd#8281 closed: snap: tweak comment in Install() for overlayfs detection <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8281> | 11:40 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/8275/files is really interesting (the test) | 12:02 |
| mup | PR #8275: daemon: do a forceful server shutdown if we hit a deadline <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8275> | 12:02 |
| zyga | abeato: reviewed https://github.com/snapcore/snapd/pull/8271#pullrequestreview-375973389 | 12:22 |
| mup | PR #8271: interfaces: add hugepages-control <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271> | 12:22 |
| abeato | zyga, cool, thanks | 12:23 |
| mup | PR snapd#8276 closed: snap: whitelist lzo as support compression for snap pack <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8276> | 12:40 |
| pstolowski | mvo: #8251 has a conflict | 12:55 |
| mup | PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251> | 12:55 |
| mvo | pstolowski: thanks, will fix | 12:58 |
| * zyga did some stretching and feels less pain :) | 12:59 | |
| mup | PR snapd#8268 closed: snap-seccomp: robustness improvements <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8268> | 13:01 |
| mup | PR snapd#8282 closed: run-tests: disable -v for go test to avoid spaming the logs <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8282> | 13:01 |
| ijohnson | hi folks | 13:09 |
| zyga | hey ian | 13:21 |
| ijohnson | hey zyga | 13:21 |
| * zyga installs debian on metal | 13:21 | |
| mup | PR snapcraft#2974 closed: project_loader: use -isystem instead of -I for system include paths <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2974> | 13:23 |
| zyga | ackk: hey, can you tell my why maas puts a layout on /root ? | 13:36 |
| ackk | zyga, so ssh can find authorized_keys | 13:40 |
| zyga | ssh? | 13:40 |
| zyga | does maas bundle ssh? | 13:40 |
| ackk | zyga, yes (the client) | 13:40 |
| zyga | aha | 13:40 |
| zyga | hmmm | 13:40 |
| zyga | I mean | 13:40 |
| zyga | that ssh goes into maas | 13:41 |
| zyga | not into the host, right? | 13:41 |
| mup | PR snapcraft#2978 closed: tests: add microk8s spread test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2978> | 13:41 |
| mup | PR snapcraft#2979 closed: tests: add multipass adhoc spread backend <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2979> | 13:41 |
| mup | PR snapcraft#2980 closed: vcs: add direnv files to .gitignore <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2980> | 13:41 |
| ackk | zyga, maas uses ssh to connect to remote virsh | 13:41 |
| zyga | I see | 13:41 |
| zyga | and there's no way to say, hey, ssh, pick those keys? | 13:41 |
| zyga | I mean | 13:41 |
| zyga | layout over /root feels a bit too powerful | 13:42 |
| zyga | not that it buys you anything | 13:42 |
| zyga | but it's a bit weird too | 13:42 |
| ackk | zyga, no, ~/.ssh is hardcoded | 13:42 |
| ackk | (I would think for security purposes) | 13:42 |
| zyga | ah | 13:42 |
| zyga | can you put a layout over /root/.ssh | 13:42 |
| zyga | would be cleaner IMO | 13:42 |
| ackk | zyga, why powerful? it's not exposing the host /root, it's putting a dir over /root | 13:42 |
| ackk | the snap container one | 13:43 |
| zyga | powerful in the sense that is has broad effect for the app | 13:43 |
| zyga | it's not a security issue | 13:43 |
| ackk | zyga, sure, but that's kinda intended | 13:43 |
| ackk | zyga, is this causing issues with snapd? | 13:43 |
| ackk | zyga, I mean, would it be different if we changed the overlay? | 13:44 |
| zyga | yes | 13:44 |
| zyga | but that's a real bug I will fix anyway | 13:44 |
| zyga | it just happens to happen that this causes a bug :) | 13:44 |
| zyga | I will have details soon | 13:44 |
| zyga | and a fix | 13:44 |
| zyga | I was mostly curious about /root, | 13:44 |
| ackk | zyga, cool | 13:46 |
| zyga | ackk: in addition I would suggest using $SNAP_COMMON | 13:47 |
| zyga | otherwise each revision has lots of mount changes for that | 13:47 |
| zyga | but it's not cancelling that two other layouts so perhaps not that important | 13:47 |
| zyga | as you wish | 13:47 |
| ackk | zyga, ah I see | 13:47 |
| sparkiegeek | Lukewh: | 14:04 |
| sparkiegeek | bah | 14:04 |
| Lukewh | bah to you too | 14:04 |
| ackk | lol | 14:04 |
| zyga | ackk: https://bugs.launchpad.net/snapd/+bug/1867752/comments/6 | 14:04 |
| mup | Bug #1867752: Unable to remove snap with content interface (with robust namespace update) <snapd:In Progress by zyga> <https://launchpad.net/bugs/1867752> | 14:04 |
| zyga | we should really run *all* tests in lxd | 14:05 |
| zyga | eh | 14:05 |
| ackk | zyga, thanks. great that you found the source of the issue | 14:05 |
| ackk | zyga, why does LXD make a difference in this case? | 14:05 |
| zyga | ackk: as I indicated, because the filesystem type for snaps is no longer squashfs but fuse | 14:06 |
| ackk | oh, I missed that detail, I see | 14:07 |
| zyga | thank you for this bug report | 14:07 |
| zyga | it's a great find | 14:07 |
| zyga | I think this never worked correctly | 14:07 |
| zyga | to the extent that all the squashfs checks were moot | 14:07 |
| ackk | it'd be great if lxd could passthrough kernel modules to containers, so that they could use proper squashfs | 14:09 |
| zyga | ackk: it's not that | 14:12 |
| zyga | ackk: containers cannot mount things because that's really the kernel mounting things | 14:12 |
| zyga | ackk: so containers could attack all FS code | 14:12 |
| zyga | and that's considered unsafe | 14:12 |
| ackk | I see | 14:12 |
| zyga | 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 |
| zyga | stgraber: ^ maybe crazy idea | 14:13 |
| stgraber | 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 |
| stgraber | so us doing any kind of hashing would just be a TOCTOU race | 14:16 |
| stgraber | 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:17 |
| zyga | stgraber: indeed, that's true | 14:19 |
| * zyga breaks for lunch | 15:10 | |
| === adrian- is now known as alvesadrian | ||
| alvesadrian | hello guys | 15:22 |
| alvesadrian | since snap | 15:22 |
| alvesadrian | is an squashfs | 15:22 |
| alvesadrian | means read only | 15:22 |
| alvesadrian | how u can write data on it? | 15:22 |
| alvesadrian | I hafe a case where i need to write data afer install in conf files of the snap | 15:23 |
| alvesadrian | user data | 15:23 |
| alvesadrian | how this can be orted if snap is an squashfs? | 15:23 |
| alvesadrian | there is a way to sort this out??? | 15:24 |
| ijohnson | hey cachio, have you had a chance to look at https://github.com/snapcore/snapd/pull/8169 ? | 15:25 |
| mup | PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8169> | 15:25 |
| alvesadrian | maxiberta ping | 15:26 |
| cachio | ijohnson, I'l do it now | 15:28 |
| ijohnson | thanks cachio | 15:28 |
| ogra | alvesadrian, snaps have two dirs they can always write to ... these are defined in the SNAP_DATA (root/services) and SNAP_USER_DATA (enduser) environment variables | 15:34 |
| zyga | alvesadrian: you have $SNAP_DATA and $SNAP_USER_DATA | 15:34 |
| zyga | alvesadrian: and $SNAP which is what you ship in the package | 15:35 |
| alvesadrian | the problem is | 15:35 |
| ogra | alvesadrian, just make sure your snap writes to the respective dir | 15:35 |
| zyga | alvesadrian: the data things are not immutable | 15:35 |
| alvesadrian | the app is a java app | 15:35 |
| alvesadrian | and sometimes need to write war files jar files | 15:35 |
| ogra | there are many snapped java apps | 15:35 |
| zyga | alvesadrian: you can write those to $SNAP_DATA | 15:35 |
| zyga | alvesadrian: I explained this last week, you cannot modify the $SNAP in any way apart from shipping an update of the pacakge | 15:36 |
| ogra | well, then write them to a writable dir and make sure to also read them from there | 15:36 |
| zyga | alvesadrian: so either disable the self-update and use snapd to update | 15:36 |
| zyga | alvesadrian: or use $SNAP_DATA as a writable space for the things you download | 15:36 |
| zyga | mvo: we fail to build for s390x: Failed to fetch stage packages: Error downloading packages for part 'mokutil': The package 'libefivar-dev' was not found.. | 15:37 |
| zyga | sorry, this was for ppcel64 | 15:37 |
| xnox | zyga: well, mkutil only makes sense on arm64 & amd64 | 15:38 |
| xnox | *mokutil | 15:38 |
| xnox | zyga: as neither s390x nor ppc64el use UEFI with Shim and MokManager | 15:38 |
| ogra | only i you use secureboot anyway, no ? | 15:38 |
| ogra | *fi | 15:38 |
| ogra | bah | 15:38 |
| zyga | yeah | 15:38 |
| ogra | *if | 15:38 |
| xnox | ogra: unrelated to secureboot, people can use mokmanager without secureboot | 15:38 |
| ogra | to manage what ? | 15:39 |
| ogra | modules ? | 15:39 |
| xnox | ogra: and we do have secureboot on s390x and ppc64el without uefi | 15:39 |
| xnox | ogra: to manage keys | 15:39 |
| ogra | ah, k | 15:39 |
| xnox | ogra: MokManager => machine owner key | 15:39 |
| ogra | (i thought it only signs unsigned modules) | 15:39 |
| xnox | ogra: it doesn't even do that | 15:39 |
| ogra | oh | 15:39 |
| xnox | ogra: it only manages a keyring of keys that shim may use to validate stuff. | 15:39 |
| xnox | in an UEFI environment. | 15:40 |
| ogra | <-- full of ignorance when it comes to secureboot on non-armhf systems :) | 15:40 |
| xnox | private key should be stored/handled externally | 15:40 |
| mvo | zyga: do you have a url for me? | 15:40 |
| mvo | zyga: I don't remember us adding these dependencies | 15:40 |
| diddledan | U. E. F. I. ting tang walla walla bing bang. | 15:40 |
| diddledan | U. E. F. I. ting tang walla bing bang! | 15:41 |
| zyga | yeah AH | 15:41 |
| zyga | mvo: sorry that's a test snap | 15:41 |
| zyga | https://launchpad.net/~snappy-dev/+snap/test-snapd-mokutil/+build/871766 | 15:41 |
| zyga | alvesadrian: does what we say make sense to you? | 15:42 |
| alvesadrian | zyga | 15:44 |
| ijohnson | mvo: #8169 is merged now, shall I open an equivalent PR to 2.44, even if just for a possible 2.44.1 ? | 15:57 |
| mup | PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8169> | 15:57 |
| mup | PR snapd#8169 closed: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8169> | 15:57 |
| zyga | ackk: I tentatively fixed it now | 16:01 |
| ackk | zyga, awesome | 16:02 |
| mvo | ijohnson: for a possible 2.41 and it would be nice to see if it also fixes sergios 2.44 issue | 16:02 |
| mvo | ijohnson: possible 2.44.1 | 16:02 |
| mvo | ijohnson: there will be one | 16:02 |
| ijohnson | sure I will open the PR now then | 16:02 |
| mvo | ijohnson: for the search v2 api | 16:02 |
| mvo | ijohnson: \o/ | 16:02 |
| === adrian- is now known as alvesadrian | ||
| mvo | zyga: google:ubuntu-20.04-64:tests/main/snap-confine-undesired-mode-group : fails, is that something you might know about? full log in https://api.travis-ci.org/v3/job/663438502/log.txt | 16:09 |
| alvesadrian | zyga PM | 16:09 |
| zyga | yeah | 16:10 |
| zyga | mvo: looking | 16:10 |
| zyga | mvo: ah, interesting | 16:11 |
| zyga | so spawning a user session and leaving it behind is a bad idea | 16:11 |
| zyga | mvo: this just tells us that there's a user logged | 16:12 |
| zyga | specifically test | 16:12 |
| zyga | and that it has lingering stuff | 16:12 |
| zyga | mvo: is that failing reliably or is that some leftover from a prior test | 16:12 |
| * zyga looks what ran before | 16:12 | |
| mvo | zyga: only saw it now for the first time | 16:13 |
| zyga | mvo: ok | 16:13 |
| zyga | mvo: what I learned while working on session-tool | 16:13 |
| zyga | mvo: is that session cleanup is async | 16:13 |
| zyga | mvo: so none of our tests synchronize against that (except for the test for session-tool) | 16:13 |
| zyga | mvo: I guess restore-each should do something like this: | 16:13 |
| zyga | https://github.com/snapcore/snapd/blob/master/tests/main/session-tool/task.yaml#L16 | 16:14 |
| zyga | mvo: we can later drop that once we transition everything over from su - ... test | 16:14 |
| zyga | to session-tool | 16:14 |
| zyga | *and* have a restore section much like this one in said tests | 16:14 |
| mvo | zyga: ok, this sounds like I can merge this pr desite the test failure? | 16:14 |
| zyga | yeah | 16:14 |
| zyga | I would also say that kill-user is not enough | 16:15 |
| zyga | because that will just kill the proceses | 16:15 |
| zyga | cgroup cleanup is another async step after that | 16:15 |
| zyga | it's a sad sad sad thing but reality | 16:15 |
| zyga | this is in scope for my work on session-tool and fixes for the pending tracking branch | 16:15 |
| zyga | I will write this down to fix | 16:15 |
| mvo | zyga: ta | 16:18 |
| mvo | mborzecki: I will squash merge 8275, any specific commit message you want there? | 16:19 |
| * ijohnson should have squash-merged 8169 :-( | 16:19 | |
| zyga | I need to run an errand | 16:21 |
| zyga | ttyl | 16:21 |
| mup | PR snapd#8275 closed: daemon: do a forceful server shutdown if we hit a deadline <Squash-merge> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8275> | 16:34 |
| * cachio lunch | 16:40 | |
| * ijohnson -> lunch | 16:45 | |
| mvo | pedronis: I created a snapd-ssl-certs update with the snap revert test we talked about and as predicted it hits the "on-revert-we-don't-run-configure-hook" bug. do you have some ideas about how the fix could look like? mostly wondering, I can dig myself, just finished the test | 16:58 |
| pedronis | mvo: interesting, I thought we run configure hook, it probably doesn't do the correct thing? | 17:02 |
| pedronis | mvo: can you confirm if we don't run it? or we run it but is not doing something sensible? | 17:03 |
| pedronis | anyway I would need to look at the code a bit to make a suggestion | 17:03 |
| ogra | diddledan, https://bugs.launchpad.net/bugs/1863904 ... | 17:03 |
| mup | Bug #1863904: Gimp 2.10 snap doesn't start, and you can't even reinstall it. <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1863904> | 17:03 |
| diddledan | thanks ogra, I'll take a look | 17:05 |
| mup | PR snapd#8284 opened: config: add system.certs.[a-zA-Z0-9] support <Created by mvo5> <https://github.com/snapcore/snapd/pull/8284> | 17:07 |
| mvo | pedronis: no worries, I can poke at it a bit | 17:07 |
| mvo | pedronis: maybe the revert is indeed just doing something silly in the cert case, I dig a bit | 17:09 |
| mvo | pedronis: I think the issue is that on a revert there are no changes, my code is too naive and only looks at changes right now but it really needs to also sync disk<->conf | 17:13 |
| mvo | pedronis: i.e. the transaction.Chnages is empty (just to clarify what I mean with the above) | 17:14 |
| pedronis | mvo: yes, we need to think a bit in which cases that is true and what it means | 17:14 |
| pedronis | mvo: in the case of a revert, we would have to empty disk and copy out all the values from the conf | 17:15 |
| pedronis | but I don't know if that is what we should do for all cases where Changes is empty | 17:15 |
| pedronis | and also whether there are corner cases | 17:15 |
| mvo | pedronis: yeah, I think we need to think a bit, I updated the PR to improve the XXX and will see what I can do tomorrow | 17:17 |
| pedronis | mvo: also because our own code might do tr.Set at some point which would change Changes | 17:18 |
| pedronis | so empty Changes needs to be checked earlier | 17:18 |
| pedronis | or we need to flag Transaction by purpose early on | 17:18 |
| pedronis | somehow | 17:18 |
| mvo | pedronis: yeah, there are some options, I think I sketch something tomorrow that syncs the on-disk state with the config state. this should also fix the case that something tries to bypass our snapd configuration mechanism | 17:20 |
| * mvo takes a break first | 17:21 | |
| diddledan | is anyone tracking problems from classic-confinement snaps when launching an HTTP(s) URL via xdg-open where firefox pops a dialog saying it can't find your profile? | 17:42 |
| diddledan | e.g. I just installed slack and can't login to any workspaces because of this | 17:42 |
| RingtailedFox | how would i go about compiling a .spec file into an RPM for my distro? i want to try to port snapd/snapcraft to mageia Linux | 17:42 |
| diddledan | ... at least I presume it's via xdg-open. I need to double check that. it might be spawning firefox directly? | 17:44 |
| diddledan | ok. it is spawning firefox inside the slack cgroup. possibly slack is trying to launch firefox directly? | 17:51 |
| zyga | re | 17:57 |
| * zyga delivered some food to his parents | 17:57 | |
| diddledan | well done :-) | 17:57 |
| diddledan | good deed for the day :-) | 17:57 |
| zyga | RingtailedFox: snapcraft is distributed as a snap | 17:57 |
| zyga | RingtailedFox: snapd is already available in mageia, no? | 17:58 |
| RingtailedFox | no | 17:58 |
| zyga | ok, time to focus on work :) | 17:58 |
| RingtailedFox | zyga, i want to port snapd | 17:58 |
| zyga | RingtailedFox: could you look at snapd in fedora | 17:58 |
| zyga | it is well maintained there | 17:58 |
| RingtailedFox | yes, i was doing so. a user here said they got the fedora spec file to work on mageia | 17:58 |
| RingtailedFox | mageia is just a reincarnation of the old Mandrake/Mandriva linux | 17:58 |
| zyga | RingtailedFox: good luck, I need to focus on a test I was writing | 18:00 |
| RingtailedFox | good luck with your test :D | 18:00 |
| zyga | RingtailedFox: if you are serious about mageia support it really requires cooperation with snapd team | 18:00 |
| zyga | RingtailedFox: as we develop changes rapidly and heavily rely on CI | 18:01 |
| zyga | RingtailedFox: and our CI is invoked against different real distributions | 18:01 |
| RingtailedFox | CI? | 18:01 |
| RingtailedFox | mageia's a real distribution... it's not a re-labelling like kubuntu | 18:02 |
| zyga | RingtailedFox: continuous integration, we run thousands of integration tests on specific real distributions for each patch | 18:03 |
| RingtailedFox | ohh | 18:03 |
| zyga | RingtailedFox: packaging snapd is just a step towards proper long-term support | 18:03 |
| RingtailedFox | so it'll be more work than just some guy in canada can provide :P | 18:03 |
| zyga | RingtailedFox: all help is welcome | 18:03 |
| zyga | RingtailedFox: not all help can be supported at all times, we also have our priorities and commitments | 18:04 |
| RingtailedFox | of course | 18:04 |
| RingtailedFox | i can provide bug reports and testing at least | 18:04 |
| zyga | starting with a package available for testing is great | 18:04 |
| zyga | getting around of feedback | 18:04 |
| zyga | trying snaps | 18:05 |
| zyga | checking what works and what doesn't | 18:05 |
| zyga | there's the forum so if you want I would recommend you to post about your experiences and progress there | 18:05 |
| zyga | as others may find it and join the cause | 18:05 |
| RingtailedFox | ok | 18:06 |
| mup | PR snapd#8252 closed: tests: update test to make snapd snap fixed twice <Simple 😃> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8252> | 18:06 |
| diddledan | this is slack trying to open firefox: http://cloud.bowlhat.net/index.php/s/A6wjmRp3tqm9wby | 18:21 |
| mup | PR snapd#8285 opened: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8285> | 18:30 |
| zyga | kenvandine: ^ | 18:30 |
| zyga | ackk: https://github.com/snapcore/snapd/pull/8285 | 18:31 |
| mup | PR #8285: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8285> | 18:31 |
| zyga | sparkiegeek: ^ | 18:31 |
| zyga | is the maintenance window now? LP is throwing errors left and right | 18:32 |
| sparkiegeek | zyga: nice, thanks | 18:35 |
| zyga | I guess it only makes sense | 18:35 |
| zyga | now from the perspective of knowing about it | 18:36 |
| sparkiegeek | zyga: AIUI maintenance window not until tomorrow (00:30 - 01:30 UTC) | 18:36 |
| zyga | hmmm | 18:36 |
| zyga | I'll try again in a moment | 18:36 |
| zyga | I got timeouts on anything I do | 18:36 |
| mup | PR snapcraft#2982 opened: specifications: experimental snap compression <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2982> | 18:38 |
| sparkiegeek | if username == zyga: time.sleep(20) | 18:38 |
| zyga | *knew it* | 18:39 |
| * zyga shakes fist | 18:39 | |
| sparkiegeek | :) | 18:39 |
| sergiusens | zyga: fwiw I pointed RingtailedFox to Neil G. | 18:41 |
| zyga | thanks | 18:43 |
| sergiusens | zyga: have you ever seen someting like this https://pastebin.ubuntu.com/p/3DKvfQRcfV/ ? | 18:45 |
| zyga | no | 18:46 |
| zyga | I don't think so | 18:46 |
| diddledan | what are you breaking now, sergiusens?! | 18:46 |
| diddledan | #blamepopey | 18:47 |
| sergiusens | diddledan: installing lxd I just built in a multipass adhoc spread backend and trying to remove it right after install | 18:51 |
| diddledan | weird | 18:52 |
| sergiusens | well LXD is a special snowflake | 18:52 |
| diddledan | haha | 18:52 |
| diddledan | just like me, then ;-) | 18:52 |
| sergiusens | and installing with --dangerous might not get me all my required connections | 18:52 |
| diddledan | that's an interesting thought | 18:53 |
| diddledan | it'ld be handy if there was an easy way to install a local package (--dangerous) but use the connections that the store would normally mandate | 18:54 |
| diddledan | maybe --really-really-dangerous mode? | 18:54 |
| mvo | cachio: I'm preparing 2.44 now (-final) - anything you need in there that e.g. fails with tests or something? | 19:51 |
| diddledan | mvo, 2.44-final-final-really_final-latest-v2? | 20:02 |
| mvo | diddledan: exactly 2.44-really-really-really-i-mean-it-this-time-final :) | 20:02 |
| diddledan | immediately followed by 2.44-really-really-really-i-mean-it-this-time-final-dammit-popey! | 20:03 |
| mvo | diddledan: lol | 20:04 |
| pedronis | we do plan a 2.44.1 | 20:09 |
| pedronis | already | 20:09 |
| sdhd-sascha | hey, i'm still here. If you need help, then just say ;-) | 20:12 |
| mvo | hey sdhd-sascha ! nice to see you. I'm good right now but appreciate the offer! hope you are doing well? | 20:20 |
| sdhd-sascha | Nice to hear :-) My wife and I are okay. Thank you | 20:24 |
| mup | PR snapd#8286 opened: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286> | 20:25 |
| mup | PR snapcraft#2982 closed: specifications: experimental snap compression <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2982> | 20:27 |
| mup | PR snapd#8287 opened: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8287> | 20:27 |
| ijohnson | mvo: I unfortunately didn't remember to squash merge 8169, so I spent too much time trying to port the changes to 2.44, and ended up just squash merging that branch on top of master locally, then cherry picking that squash merge onto a branch off release/2.44 and submitting that as the above PR ^ | 20:28 |
| ijohnson | it was rather complicated to port all the commits to release/2.44, because the PR was opened before 2.44 branched, and had merges from master both before and after release/2.44 was branched :-/ | 20:28 |
| sdhd-sascha | mvo: last week, i just send some application to canonical ;-) | 20:29 |
| mvo | ijohnson: thanks, this will make merging 2.44 back into master a bit painful :/ | 20:33 |
| ijohnson | ah hmm hadn't thought about that | 20:33 |
| mvo | sdhd-sascha: oh! you need to tell me some details tomorrow, good luck with that | 20:33 |
| sdhd-sascha | thank you :-) | 20:33 |
| ijohnson | mvo: yeah I just tried locally and there were conflicts with it | 20:33 |
| mvo | ijohnson: you can try to merge that back into master and see how bad the conflicts are, if it's not too much it's fine, otherweise we should probably chat tomorrow, maybe we can do something minimal | 20:34 |
| ijohnson | grr | 20:34 |
| mvo | ijohnson: some conflicts are fine | 20:34 |
| mvo | ijohnson: happens all the time, if it's a gazillion that is annoying :) | 20:34 |
| ijohnson | let me see how bad that is | 20:34 |
| ijohnson | mvo: the conflicts aren't too bad, the big thing was actually just the changelog, the rest of the conflicts are trivial to resolve it seems | 20:35 |
| ijohnson | mvo: see https://pastebin.ubuntu.com/p/kSMKG5nGcf/ | 20:36 |
| mvo | ijohnson: aha, nice | 20:36 |
| mvo | ijohnson: yeah, that sounds fine | 20:36 |
| ijohnson | okay, cool | 20:36 |
| mvo | ijohnson: thank you! | 20:36 |
| ijohnson | sorry about that I know either I or someone else mentioned to mark that original PR as squash-merge and I forgot to tag it as such and then forgot to merge it as such /o\ | 20:37 |
| mvo | ijohnson: no worries | 20:40 |
| mup | PR snapd#8288 opened: release: 2.44 <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8288> | 20:43 |
| mvo | cachio: core 2.44 should be in beta in ~1-2h, unfortunately the snapd snap is not ready tonight, LP is hanging on code import it seems | 20:44 |
| cachio | mvo, awesome | 20:45 |
| cachio | I'll start as soon I have resutls | 20:45 |
| cachio | thanks! | 20:45 |
| mvo | cachio: looks like snapd snap will also build tonight, LP finally imported the updated code. should also be ready in ~1h | 20:53 |
| cachio | nice | 20:53 |
| cachio | tests should start automatically once the snap is published | 20:54 |
| mvo | very cool | 20:59 |
| mup | PR snapcraft#2977 closed: cli: merge build options into provider options <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2977> | 21:15 |
| mup | PR snapcraft#2983 opened: tests: add LXD spread test <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2983> | 21:18 |
| mup | PR snapcraft#2983 closed: tests: add LXD spread test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2983> | 21:30 |
| sdhd-sascha | hello, ijohnson: didn't look much about the PR. Thank you, for your advice. Really much thank's :-) If there is something i didn't see, then i like critism .... | 21:35 |
| ijohnson | sdhd-sascha: we're always open to contributions like yours, just in that specific case I think it doesn't add very much utility to our current workflow | 21:43 |
| * ijohnson -> EOD | 21:43 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!