[00:31] PR snapcraft#2764 closed: Snapd doesn't actually honor the slot specified in the default-provider [05:24] hey mbo [05:36] morning [05:38] hey mborzecki [05:39] mvo: PRs still red? [05:39] mborzecki: looks better today [05:39] mborzecki: at least the one from zyga 7h ago is green [05:40] wth https://github.com/snapcore/snapd/pull/7647 has pending build status, but when you go to the details page it's actually green [05:40] PR #7647: gadget: skip structures with MBR role during remodel [05:41] mborzecki: oh no [05:41] mvo: i've restated the cla check job, maybe it's enough to switch the status :/ [05:42] mborzecki: the cla job is not finished [05:42] mborzecki: which is slightly strange [05:42] mborzecki: I can cancel and restart? [05:42] mvo: restarted it just now intentionally [05:42] mborzecki: aha, ok [05:43] mvo: all the other jobs were green, and cla runs are shortest, hope that when it completes travis will report the status back to gh [05:43] mborzecki: right, makes sense. if not, I will just merge and override the missing check [06:02] PR snapd#7647 closed: gadget: skip structures with MBR role during remodel [06:16] PR snapd#7657 closed: snap: fix default-provider in seed validation [06:20] hey [06:21] mborzecki: the secret for green spread PRs is to open them at 1AM [06:21] spread has logic for that [06:21] really ;) [06:21] juts look at 1AM and you will see it [06:21] zyga: i.e. switch timezones then [06:21] zyga: and hey :) [06:21] * zyga had a horrible horrible night [06:22] Janek decided to sleep in our bed and we couldn't convince him otherwise [06:22] and that's just not enough space [06:22] my whole body hurts [06:22] mvo: I found a curious bug [06:22] I discussed it with jamie a little [06:22] but I couldn't convince him at the time [06:23] mvo: I opened a thread about it to discuss it https://forum.snapcraft.io/t/classic-confinement-breaks-high-dpi-support/13868 [06:23] mvo: I think the bug is more serious for non-x-wayland sockets because it is likely that classic software is broken and unable to open files it expects [06:24] Ideally we wouldn't change XDG_RUNTIME_DIR for confined snaps either... [06:24] by applying the attached fix all my snap apps are non-blurry now [06:24] jamesh: I tend to agree, after all we have apparmor for confinement [06:25] jamesh: I think jamie wanted to do this (set it to a custom value) to support things like instances [06:25] but I don't know if that is sensible, how are apps expected to talk to each other? [06:25] hey jamesh :-) [06:25] zyga: by that I mean mounting something over /run/user/$UID for strict confinement, with bind mounts of wayland, dbus, pulse sockets [06:26] jamesh: mhm [06:26] jamesh: for strict apps that's sensible IMO [06:26] jamesh: especially that we can "recover" those socktes via hostfs [06:26] zyga: is this 7659 ? [06:26] jamesh: so even regular mount backend code would make it work [06:26] mvo: yes [06:27] zyga: aha, I see [06:27] actually using wayland, snaps on the desktop [06:27] brave new world [06:27] I need to figure out the horrid suspend issue where x input breaks [06:27] (but works in console) [06:27] zyga: this looks fine to me but I don't know enough [06:27] I only can reboot to recover from that [06:27] need to learn how xinput works [06:28] zyga: do you think could have a look at 7640? this would allow us to ship this in the initramfs [06:28] yes, I think you pinged me about that yesterday [06:28] let me do so now [06:29] mvo: question about the path, we have /run/snapd/* already, could that path be /run/snapd/recovery or something like that? [06:29] zyga: sure, I can change that [06:29] zyga: this is in initramfs [06:30] zyga: so we don't have /run/snapd yet but its fine to add it [06:30] yeah, just for consistency, [06:30] it's not a blocker in any way [06:30] mvo: total lack of docstrings makes this harder to review [06:31] mvo: I'm not following core20 work as closely [06:31] mvo: what kind of filesystems are going to be mounted? [06:31] zyga: vfat and ext4 currently [06:31] mvo: by deployFilesystemContent [06:31] ok [06:38] zyga: i'm looking for the place where we creat that per snap XDG_RUNTIME_DIR but i don't see it [06:38] zyga: there's some dead code in s-c [06:38] zyga: and nothing in snap run? [06:39] mborzecki: snap run [06:39] mborzecki: cmd/snap/cmd_run.go:495 [06:39] zyga: btw. wonder if that also breaks the thing with xdg-open & classic snaps that cause new browser window to pop up [06:39] mborzecki: probably [06:39] yeah, it's just silly we set it [06:39] for classic I mean [06:39] PR snapd#7660 opened: snap-recovery: rename to "snap-bootstrap" [06:43] zyga: hmm that code in snap run doesn't create /run/user//snap.* [06:45] there's code in snapcraft-desktop-helpers that creates it, with a comment referencing https://bugs.launchpad.net/snappy/+bug/1656340 [06:45] Bug #1656340: XDG_RUNTIME_DIR is not created on app startup [06:49] mvo: https://github.com/snapcore/snapd/pull/7640#pullrequestreview-307007679 [06:49] PR #7640: snap-recovery: deploy gadget content when creating partitions [06:50] zyga: thank you! about the ShiftStructureTo - thats something for mborzecki [06:51] zyga: I will follow the second suggestion in a followup, I need to make it transactional and then its good for now [06:51] PR snapd#7640 closed: snap-recovery: deploy gadget content when creating partitions [06:52] +1 [06:56] thanks zyga ! [06:59] mvo: is https://github.com/snapcore/snapd/pulls/zyga something for 2.42.1 or 2.43? [07:02] I'll get breakfast and then work on follow ups === pstolowski|afk is now known as pstolowski [07:05] morning [07:08] hey palasso [07:08] pawel :) [07:08] hello zyga [07:11] PR snapd#7630 closed: overlord/devicestate: check snap handler for gadget remodel compatibility [07:17] hey pstolowski ! good morning [07:19] zyga: reading the comments from ian about docker snap, wtf is docker doing there? [07:20] btw. wonder if we could snap podman and use the same docker interface [07:23] i have ideas [07:23] breakfasting [07:28] zyga: #7632 is green [07:28] PR #7632: interfaces: de-duplicate emitted update-ns profiles [07:29] yep [07:36] re [07:36] okay [07:36] mborzecki: we had an issue with docker in the past [07:37] mborzecki: it was trying to use /sys from ... /var/lib/snapd/hostfs/sys [07:37] mborzecki: I think it's a bit "too" smart [07:37] mborzecki: I'll start by hiding the cgroup from snap view [07:37] mborzecki: let's see if that is enough to fix it [07:37] zyga: so smart that the smartness overflowed [07:38] zyga: won't the cgroup always appear via /proc/$$/cgroup? [07:39] mborzecki: nuclear gandhi [07:40] mborzecki: yes but if it doesn't show up mounted maybe it will ignore it [07:40] mborzecki: we need to check docker logic [07:40] afk again [07:41] zyga: iirc when i looked at libcontainer it tried to parse /proc/self/cgroup and /proc/mountinfo [07:43] mborzecki: we can remove it from mountinfo [07:43] if it parses cgroup then we're SOL [07:43] but then again, it's silly to do :P [08:03] PR snapd#7661 opened: packaging: tweak handling of usr.lib.snapd.snap-confine [08:06] mvo: thanks [08:06] mvo: is it working? [08:06] is that tested? [08:06] we did that before and it was a hit-and-miss [08:06] mborzecki: I wrote a small patch - checking if that makes docker work [08:06] zyga: we test it in one spread test but I could not reproduce [08:07] aha [08:07] well [08:07] I wrote that patch for moving that out of /etc [08:07] but it's not finished (tests need adjusting) [08:07] I think it's fine [08:07] * mvo nods [08:12] mborzecki: it works [08:13] mborzecki, ijohnson: this fixes docker [08:13] https://github.com/snapcore/snapd/pull/7547/commits/1c60b84df1faf7ca2e80bf30d50850e6322da87b [08:13] PR #7547: many: use a dedicated named cgroup hierarchy for tracking <â›” Blocked> [08:13] so yay [08:44] mvo: should #7642 be merged? #7626 and #7645 need a master merge I think [08:44] PR #7642: travis.yml: add 'sh -x' to run-checks [08:44] PR #7626: managers: add remodel undo test for new required snaps case [08:44] PR #7645: client: add xerrors and wrap errors coming from "client" [08:45] mborzecki: hi, maybe you can do a 2nd review of 7626 [08:48] PR snapd#7632 closed: interfaces: de-duplicate emitted update-ns profiles [09:22] lots of repeated red :/ [09:29] * dot-tobias says hi [09:31] pstolowski: https://github.com/snapcore/snapd/pull/7662 [09:31] hey dot-tobias [09:31] PR snapd#7662 opened: interfaces: simplify AddUpdateNS and emit [09:31] PR #7662: interfaces: simplify AddUpdateNS and emit [09:33] zyga: ty [09:37] mvo: did you see my ping here about some of your PRs ? [09:41] pedronis: re 7642> if we don't see the mysterious error 6 anymore I think we can omit it [09:41] pedronis: I suspect something with travis was wrong that triggered these errors [09:44] ok [09:45] pedronis: feel free to close, we can always reopen if these mysterious errors come ack [09:51] PR snapd#7663 opened: tests: add 14.04 canonical-livepatch test [09:52] PR snapd#7664 opened: cmd/cmdutil: version helper [10:03] PR snapd#7642 closed: travis.yml: add 'sh -x' to run-checks [10:16] PR snapd#7665 opened: devicestate: add support for gadget->gadget remodel [10:17] mvo: pedronis: ^^ decided against splitting it further for now [10:18] still 12 files changed, 820 insertions(+), 97 deletions(-) :/ meh [10:22] zyga nice [10:22] hey :) [10:22] yeah [10:25] Much better than trying to patch docker :-) [10:33] mborzecki: sounds ok size wise, I imagine a bunch is the managers_test.go test ? [10:33] pedronis: yup, managers_test, devicestate tests, spread test ;) [10:34] yea, sounds alright :) [10:37] thanks mborzecki [10:37] mvo: got some reviews for zyga and then i'll look into the copr repo with xerrrors to unblock you [10:38] mborzecki: \o/ [10:50] * Chipaca gets confuzzled and takes a break [10:51] * pstolowski lunch [11:25] mvo Chipaca We (popey and I) have things to discuss with you for todays catch up :-) [11:27] PR snapd#7648 closed: interfaces/policy: expand cstrs/cstrs1 to altConstraints/constraints [11:28] Wimpress: sounds interesting [11:29] PR snapd#7655 closed: interfaces: allow introspecting network-manager on core [11:30] Wimpress: I can make it if we keep it short [12:10] * zyga afk === ricab is now known as ricab|lunch [12:35] PR snapcraft#2707 closed: manifest: sort package and snap lists for consistency [12:35] PR snapcraft#2755 closed: extensions: kde-neon: add icon and sound themes [12:50] morning [12:50] pstolowski: I did a pass on #7658 [12:50] PR #7658: cmd/snap-start-preseed: add snap-start-preseed executable (1/N) [12:59] pedronis: yes just saw it, thank you [12:59] pstolowski: thanks for the review, will address your suggestions today [13:08] mborzecki: about this copr repo - do I need to add something to the xerrors pr under review? [13:09] mvo: i'll open a PR adding that to the early setup we do on fedora [13:09] mborzecki: \o/ [13:10] PR snapd#7662 closed: interfaces: simplify AddUpdateNS and emit [13:18] jdstrand: can you re-review https://github.com/snapcore/snapd/pull/7547 [13:18] PR #7547: many: use a dedicated named cgroup hierarchy for tracking [13:18] jdstrand: mainly to check the comments about v1 vs v2 mode [13:23] huh [13:23] https://www.irccloud.com/pastebin/eonsNHRx/ [13:23] mborzecki: did you see this when changing delta code in spread recently? [13:23] not sure why this didn't flag before [13:24] perhaps just 19.10 -> amazon is the problem [13:24] zyga: nope? this an opensuse host? [13:24] no, ubuntu 19.10 [13:24] ah 19.10 hm, maybe some defaults changed? [13:24] mhm [13:28] how good is "snap set core experimental.refresh-app-awareness=true"? [13:31] sergiusens: it's partially useful, it's not handling classic confinement which will be fixed shortly (code ready, waiting on reviews) [13:31] sergiusens: there's no UX but that's under development [13:31] PR snapd#7666 opened: tests: don't depend on GNU time [13:31] sergiusens: there will be some in the next two weeks [13:32] zyga: I just want to prevent updates for when running confined snaps like the browser, which updates frequently and too many weird things start to happen :-) [13:32] * sergiusens sets the flag [13:32] sergiusens: yes, please set it [13:32] sergiusens: and report all weird stuff [13:32] sergiusens: I'm working on making it much better [13:33] mborzecki: small python helper if you want to look [13:33] https://github.com/snapcore/snapd/pull/7666/files [13:33] PR #7666: tests: don't depend on GNU time [13:37] pedronis: I will look at your seedwriter PR now [13:38] Installing updates.... === ricab|lunch is now known as ricab [13:43] ijohnson: thx [13:46] PR snapd#7667 opened: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors [13:46] mvo: ^^ [13:57] pedronis: reviewed one question about the tests [13:57] * ijohnson goes to get coffee before meeting [14:02] zyga: it is on the list, yes. pedronis, I commented (only) on pr 7659. I am not explicitly blocking the PR, but wanted to make sure my concerns were considered [14:02] PR #7659: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement [14:02] jdstrand: ack [14:03] well, I did vote -1 for 2.42.x [14:03] but anyhoo, it is all in the PR [14:04] zyga: also, I don't think I'm needed for 7666, but I glanced at it and the approach looks good. thanks for the followup :) [14:05] jdstrand: thanks! :) [14:20] jdstrand, hey, is https://github.com/snapcore/snapd/pull/7603 on your radar? the MP contains a couple of new interfaces for dpdk [14:20] PR #7603: interfaces: add dpdk and hugepages interfaces [14:22] abeato: it is. I need to dig in a bit on that one [14:22] great [14:27] i see two content snaps listed when i do snap connections on my snap so can someone point me to where connections grabs its info from? [14:27] i'm building my snap in a normal way, only pointing to one extension. that extension only points to one platform snap. [14:33] does the core18 base know about extensions? [14:36] hellsworth: look at `sudo cat /var/lib/snapd/state.json | jq .data.conns`. [14:37] hellsworth: probs you are suffering from the bug where your snap you are working on was previously installed and had that connection to the other content interface and so now `snap connections` shows that [14:37] how can i clear that history though [14:37] yes i did previously have this snap installed with the old extension [14:38] which connected to the old content snap [14:38] Oct 25 16:19:28 ... systemd[1]: [/etc/systemd/system/snap-pi2\x2dkernel-102.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount' [14:38] Oct 25 16:19:28 ... systemd[1]: [/etc/systemd/system/snap-core18-1226.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount' [14:38] hmm, thats a new one [14:38] (my log is full of these) [14:44] * zyga goes for lunch === JanC_ is now known as JanC [14:49] jdstrand, have you seen my last message on https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705/8 ? [14:49] auto-connection of personal-files for chromium is refused, I thought you had allowed it? [14:50] oSoMoN: I hadn't, but I'll look at it [14:50] zyga: ok, reviewed pr 7547, please see both the review comments and the additional comment I added after [14:51] PR #7547: many: use a dedicated named cgroup hierarchy for tracking [14:51] jdstrand, you wrote "Granting use of the updated path. This is now live.", I assumed this was good to go [14:52] oSoMoN: it should be. that is why I need to look at it :) [14:52] ok, thanks :) [14:53] * cachio lunch [14:55] jdstrand: ack [14:56] oSoMoN: btw, the memory usage PR as merged. it should be in edge whenever the core snap is rebuilt [14:56] zyga: it probably wouldn't be terrible to get that ^ in 2.42 [14:56] I'll let others decide [14:57] jdstrand: the apparmor memory fix? I think that's up to mvo to cherry pick but I agree it's not likely to be hard to do or breaking stuff [14:57] so yeah =1 [14:57] +1 [14:57] zyga: yeah [14:59] zyga: if you and jdstrand are good I can cherry pick the appamror de-dup fix to 2.42.1 (unless pedronis objects of course) [14:59] jdstrand, I subscribed to the PR so I got a notification when it was merged, that's very nice, thanks! [15:00] my opinion doesn't count, but I'm totally +1 for cherry-picking :) [15:00] mvo: +1 [15:00] mvo: yes, just remember it was split into three PRs [15:00] mvo: 1) OrderedSet, 2) emit 3) the actual fix with spread test [15:01] btw, thanks zyga for working on this [15:02] mvo: regression potential should be shallow. if snap-update-ns isn't working right, it should be broken in many places. asking QA for explicitly testing the preinstalled gnome snaps is likely not a bad idea to build confidence [15:02] zyga, jdstrand lets quickly catchup with pedronis (he is in a meeting right now) and if he is +1 I will cherry-pick [15:05] oSoMoN: typo in snap decl. I thought it was chromium-browser-init. it is chromium-browser.init [15:05] oSoMoN: shall I fix the snap decl or you fix the snap? [15:05] oSoMoN: it is easy to fix the snap decl [15:07] oSoMoN: I see the original request was for chromium-browser.init, so I'll fix the snap decl [15:10] oSoMoN: fixed: https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705/8 [15:11] oSoMoN: be sure to 'snap refresh' before install if using the same system [15:13] * zyga made coffee [15:13] zyga, did you see my error above ? seems all my machines are spamming their logs with that [15:13] ogra: no, I did not [15:13] Okt 24 20:52:26 anubis systemd[1]: [/etc/systemd/system/snap-core-7917.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount' [15:13] I see that now [15:13] ogra@anubis:~$ journalctl |grep -c lvalue [15:13] 1483 [15:13] ogra: oh, I've seen that. I kept meaning to mention it somewhere [15:13] older versions of systemd don't understand lazy unmount [15:13] ogra: which version is that? [15:14] of the distribution [15:14] zyga: for me it was uc16 [15:14] i just noticed it on a pi here ... and checked the other machines ... seems all of them show it [15:14] I see [15:14] thats 16.04 and a Core 16 Pi [15:14] it's a part of a fix [15:14] that doesn't work on old systems [15:14] so both, core and desktop [15:14] mvo: what's the question? [15:14] yeah, i was guessing you use some new systemd feature there :) [15:15] zyga: perhaps use of the conditional needs to be conditional on new enough systemd? not sure if that is system-key material... [15:15] meh [15:15] it is https://github.com/snapcore/snapd/commit/5f16e6b0738410d07995b85bc516d9bbb50263c8 [15:15] use of the feature* [15:16] pedronis: if we can backport the de-duplication for apparmor lines into 2.42.1 [15:16] jdstrand: we don't re-generate mount units today, system key won't help [15:16] jdstrand: I agree it would be nicer to know if it is supported [15:17] I need a moment to finish the coffee [15:17] then jumping into a customer bug [15:17] ogra: I'm thinking there should be a bug. I suspect we'll get customers wondering about it [15:18] ogra: and that will help the snapd team to prioritize [15:18] mvo: it seems ok, if jdstrand is also +1 [15:20] zyga: has the 3rd part landed already? [15:20] mvo: yes, all parts are inn [15:20] *in [15:20] pedronis (cc mvo): I am, though asking for some light additional QA for say running gnome snaps and verifying no new denials would not be unreasonable. I know there are nice tests for that in the PRs, so, all of your call [15:21] zyga, jdstrand https://bugs.launchpad.net/snapd/+bug/1849861 [15:22] Bug #1849861: Unknown lvalue 'LazyUnmount' message in logs with latest snapd on 16.04 based systems [15:22] ogra: thanks! [15:25] mvo: as jdstrand says a bit of extra QA would be good? what was your plan, do 2.42.1 straight? do a pre? [15:30] pedronis: probably no pre, should be very controlled but we can keep it longer in candidate for example [15:30] ok [15:30] zyga: what was the pr number for the 3rd part [15:30] mvo: just install a snap before and after and check sha1 of the kernel image of the profile [15:30] mvo: one moment [15:31] mvo: 7632 7633 7639 [15:32] mvo: please make sure to cherry pick the test as well, so that you can see it pass [15:34] zyga: thank you! 7632 [15:35] zyga: 7632 tripped me over [15:35] mvo: do you need help? [15:42] zyga: in a meeting right now, I will probably do this on monday, but you are welcome to prepare a PR against 2.42 - but no worries, I will get to it eventually [15:43] mvo: not today, I'll just inspect that bug and EOD [15:43] mvo: I -1 one of your branches, sorry, just a question but need to make sure it does not land unanswered [15:51] zyga: thats fine, its a valid question, we do it in other tests too but I will have a look later [15:52] * zyga is under invasion from a particularly lovely toddler :D [15:55] zyga: eod> totally fine! === pstolowski is now known as pstolowskiafk [16:01] * zyga breaks to run an errand [16:36] hellsworth: sorry I missed your response, probably what you can do is first remove the snap, then make a backup of your state.json, stop snapd with `systemctl stop snapd.socket && systemctl stop snapd` and then delete the conns for the snap in question in state.json and then re-enable snapd with `systemctl start snapd.socket && systemctl start snapd`and finally try installing your snap again [16:36] note that afaik the bug is just about the connections showing up in `snap connections`, I don't think the security policy still actually has the stuff that those connections implies [16:39] ok thanks. should snap-discard-ns also cleare this cached history too? [17:10] hellsworth: snap-discard-ns will clean up the security policy stuff (well specifically the mount ns), but it won't clean up the connections themselves [17:11] ok thanks for clearing that up ijohnson [17:11] np, sorry you are encountering that bug [17:11] bugs happen :) [17:12] hellsworth: that bug fwiw is https://bugs.launchpad.net/snapd/+bug/1848516 [17:12] Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh [17:12] ah thanks [18:11] zyga: oh, I meant to ask, what was up with all the .keep files in PR 7632? [18:11] PR #7632: interfaces: de-duplicate emitted update-ns profiles [18:23] jdstrand: those are so that we have a [18:23] Directory structure [18:23] It is like gnome system monitor snap [18:23] Just frozen in time [18:23] And empty [18:24] zyga: oh right, git [18:24] Yeah :-) [18:24] zyga: it was weird cause github said 'No changes' in the PR [18:24] so it threw me [18:24] Yeah, all empty [18:24] ok, thanks :) [18:24] :-) [19:00] PR snapcraft#2768 opened: remote-build: autorecovery and improved resiliency [19:08] * cachio afk [19:29] sergiusens: https://paste.ubuntu.com/p/HTgWjC9tJV/ [19:29] that is me building with the WIP gnome-3-34 extension which uses gnome-3-34-1804-sdk build snap [19:30] libffi.so.7 is in the same directory as libgobject-2.0.so [19:30] PR snapcraft#2761 closed: Core20 base [19:31] sergiusens: any suggestions appreciated [19:31] PR snapd#7667 closed: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors [19:35] PR snapd#7664 closed: cmd/cmdutil: version helper [19:37] PR snapd#7654 closed: cmd/snap, store: include snapcraft.io page URL in snap info output [19:38] PR snapd#7605 closed: tests: configure the journald service for core systems [19:53] PR snapd#7656 closed: tests: verify host is not affected by mount-ns tests