[04:36] Hi === amurray` is now known as amurray [05:07] morning [05:29] PR snapd#6884 opened: WIP LP:#1828354 [05:29] mborzecki: I've opened a draft PR above [05:29] and I'm rushing to the car to take Iza to the new school [05:30] ttyls :) [05:30] zyga: ok, i'll take a look [05:30] I'll get rid of other bits from that branch [05:30] namely defer patches [05:30] and various other changes that can be broken out [05:30] the essence of the main thing is there [05:30] I'm not 100% sure about one part though [05:31] https://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R94 [05:31] PR #6884: WIP LP:#1828354 [05:31] I need to make the test more clear so that the relationship (peer groups) is clearly visible [05:33] mborzecki: the mountinfo-tool program can probably land in tests/lib somewhere [05:38] On my way to the new school now [05:40] mborzecki: darn, I committed the broken version that was going to work on older python [05:40] Well, let’s fix that [05:42] btw. totally forgot about the draft PRs, maybe should open one for all of gadget update code [05:43] yeah! [05:46] force pushed [05:47] some weird gnome bug [05:47] with x11 I have no desktop background [05:47] with wayland I do but lots of other things are broken [05:48] some error messages about using freed object in gnome shell [05:48] eh [06:10] Daughter is now at the new school [06:11] Apart from the fact that we cannot leave because someone parked next to our car all is good [06:53] mborzecki: trivial https://github.com/snapcore/snapd/pull/6885 [06:53] PR #6885: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND [06:54] PR snapd#6885 opened: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND [07:03] hey pedronis [07:03] hey zyga, pedronis and mborzecki [07:03] hey mvo, didn't see you join earlier [07:04] zyga: no worries, reading PRs and reporting bugs :) [07:04] how are you doing? I have a very eventful day but I'm hoping to make progress [07:04] pedronis: mvo: hey [07:06] zyga: +1 on the PR, i think we had a note about that somewhere earlier in s-c code [07:07] oh, I'll check [07:07] thanks! === pstolowski|afk is now known as pstolowski [07:07] morning [07:10] good morning pawel [07:13] mborzecki: one more similar change: https://github.com/snapcore/snapd/pull/6886 -- I'm shaving the main branch to have other tweaks separate so that they don't cloud the non-trivial review of the main part [07:13] PR #6886: cmd/snap-update-ns: use "none" for propagation changes [07:13] PR snapd#6886 opened: cmd/snap-update-ns: use "none" for propagation changes [07:32] zyga: we have this mount propagation bug that we want in 2.39.1, right? I'm looking into doing 2.39.1 soon(ish) and just wanted to check whats missing [07:38] mvo: yes, I'm shaving the branch for that now, there's a draft PR with some cruft still [07:39] mvo: and one test that I mentioned yesterday that fails in the restore phase (fuse mounts, so related) [07:39] ok [07:39] mvo: the essence of the fix is https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07 [07:39] PR #6884: WIP LP:#1828354 [07:39] (though as I said the diff will still shrink slightly) [07:40] zyga: woah, thats big - reading [07:41] mvo: it's not *that* big, mostly verbose diff in test changes [07:41] mvo: the non-test code changes are tiny [07:41] zyga: yeah, lots of test changes [07:41] mvo: the essence of the idea builds from ... [07:41] https://github.com/zyga/mimic-bug/blob/master/bug.sh [07:42] mvo: what we were missing is MS_SHARED so that ns:snap events propagate to ns:user [07:42] * mvo nods [07:42] mvo: interestingly, due to inheritance of sharing flags, bulk of the changes are in snap-confine bootstrap [07:42] mvo: the only other changes are to mimic construction code: [07:42] https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-4480ffd44957efa3395867c929f88014R488 [07:42] here [07:42] PR #6884: WIP LP:#1828354 [07:42] literally one line :) [07:43] mvo: the change makes the stash used during mimic construction private [07:43] because due to the sharing that is now everywhere, events made during mimic construction would clobber it, this essentially makes the mimic behave as it did before sharing was added on the outer layer [07:44] mvo: on top of this I wrote a tool like findmnt [07:44] https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-427083700c87c7cd79d1ac50787fab0fR1 [07:44] PR #6884: WIP LP:#1828354 [07:44] it's just a think wrapper around mountinfo [07:44] but has two properties: it shows propagation flags better than findmnt [07:44] and it has good renumbering features so that it works well in tests [07:44] it's also great for interactive use [07:45] using that tool I crafted some new tests [07:45] https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-f54c331654290afe84ce29593d97a871R70 [07:45] PR #6884: WIP LP:#1828354 [07:46] that check how things behave with content initially connected, initially disconnected and finally connected then disconnected and reconnected [07:46] there's a smilar one for layout [07:46] and I will still replicate that for parallel instances [07:46] there's a chance parallel instances are still broken because the failure I observed is exactly in that scenario [07:47] I wrote the test in defer style because it was way faster [07:47] zyga: ok [07:47] but I will remove defer from this patch [07:47] so that it can land separately [07:47] mvo: one interesting thing is this existing test [07:47] https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-a6e200ddb24754df8611a002020deccdR1 [07:47] PR #6884: WIP LP:#1828354 [07:47] that used to be broken and is now fixed [07:48] it essentially captures the fact that layouts *can* correctly change from revision to revision, now, with this fix [07:49] mvo: it needs careful review [07:50] and anyone doing so needs to readhttps://lwn.net/Articles/159077/ and https://lwn.net/Articles/159092/ [07:53] zyga: maybe worth linking to that in the PR description(?) [07:53] zyga: thank you for the link! [07:53] mvo: great idea, I will do so [07:56] ta [08:01] PR pc-amd64-gadget#15 opened: add .travis.yml to enable basic smoke testing [08:12] PR pc-amd64-gadget#16 opened: add .travis.yml to enable basic smoke testing (18) [08:13] PR pc-amd64-gadget#17 opened: add .travis.yml to enable basic smoke testing (20) [08:17] * zyga is back home [08:29] PR snapd#6885 closed: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND [08:29] pedronis: https://gopenpgp.org/ ! [08:33] Chipaca: bookmarked [08:34] Chipaca: does my answer in the download topic makes sense? [08:37] zyga: is there a bug open for content snaps not being connected sometimes, causing apps to fail? [08:37] zyga: I suspect this kde calc bug is a snapd bug https://bugs.kde.org/show_bug.cgi?id=407234 [08:37] popey_: perhaps many [08:37] zyga: as it can't find libqtcore which is in the kde frameworks snap [08:37] yeah [08:37] this is all coming together in https://github.com/snapcore/snapd/pull/6884 [08:37] it will be in 2.39.1 [08:37] PR #6884: WIP LP:#1828354 [08:38] just shaving the yak so that it can land [08:38] it fixes a bug where connect/disconnect would be broken for desktop apps [08:38] thanks [08:39] popey_: that was one tricky bug [08:39] popey_: sorry for taking so long to nail it [08:39] I can only imagine! [08:39] np, glad it's on the radar [08:39] popey_: reading the test here https://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R50 should show you what is ensured to work correctly now [08:39] PR #6884: WIP LP:#1828354 [08:39] the key is that this test runs both as root and as non-root user [08:40] that's where the bug has been mostly lurking [08:40] root users are OK [08:40] ironically all our tests run as root by default [08:40] hah! [08:40] ironically wouldn't be the word I use [08:41] There are many adjectives that could be used here. But we're a family friendly channel ;) [08:41] I always thought it was just problems waiting to happen [08:41] mborzecki: silly question - do we use the ":role" yaml property in any of our gadgets? just looking at ubuntu-image [08:41] though is convenient [08:41] pedronis: I agree [08:41] pedronis: when I was coding this test I ran it locally as user and coded most of the test to use sudo [08:41] mvo: we should be, type: mbr is supposed to be legacy, we ought to have role: mbr there instead [08:42] pedronis: I think I would not stumble onto that part of the problem otherwise [08:42] pedronis: yes indeed [08:42] mborzecki: aha, I see - I have not seen role: system-boot/system-data in the wild I think(?) [08:42] mborzecki: we probably need system-recovery here in the future :) [08:42] mvo: neither did i [08:42] mvo: we can add a new role [08:42] mborzecki: maybe a case of YAGNI? anyway [08:42] mvo: system-recovery fwiw [08:42] * mvo adds a note to the trello [08:43] mvo: probably better to have a new role in case there's actually someone using system-{boot,data} [08:43] mvo: oh, and system-data may be used implicitly when a rootfs paritition is added automatically [08:43] mborzecki: yeah, given that its already docuemtned and used in the wild I think you are right [08:43] mborzecki: yeah, I need to look at this and make it not-automatic but maybe not for v0 [08:44] * mvo adds it to trello [08:45] mvo: i should be albe to dump the whole gadget update branch as a draft work-in-progress pr, it includes the tool for building images [08:47] sergiusens silly question - running snapcraft in travis now blocks with "Support for 'LXD' needs to be set up. Would you like to do that [y/N]" - do you have an example for a .travis.yml with snapcraft3/base: core18 that just builds the snap ? (or maybe popey knows?) [08:48] Oh, maybe I do. I'll see if I can find one [08:48] mborzecki: nice, yeah, I may be able to get away with a hack - marking the system-recovery partition with role: system-data so ubuntu-image will not create writable and will also put the files into the right place on disk [08:49] mborzecki: its a bit of a fugly hack but maybe enough to get me one step further [08:49] popey_: that would be lovely [09:03] PR snapcraft#2570 opened: cli: do not prompt when there is no tty available on stdin [09:07] pedronis: I'll be working on the users as soon as i've deconflicted the cohort refresh one [09:07] Chipaca: sounds good [09:09] pedronis sorry to bother you, I saw that you found some time to address the pending forum tags... could you give a look at our request too? https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189/5 Thanks [09:12] mvo: https://github.com/snapcore/snapcraft/pull/2570/files#r286389212 [09:12] PR snapcraft#2570: cli: do not prompt when there is no tty available on stdin [09:16] zyga: thank you! [09:19] mvo: socket activation when daemon goes off doesn't work; systemd stops snapd.socket too [09:19] (totally offtopic) [09:20] pedronis: in the cohort refresh pr I added an UpdateOptions struct [09:20] pedronis: should device ctx be part of that? [09:20] mvo: the test squashfs we mount on snapd startup briefly flashes in unity launcher, I think we are missing the mount option that makes the launcher ignore it [09:20] pedronis: or is it being separate (like userID is separate) better? [09:20] zyga: oh? meh, that will need some investigation then [09:22] x-nothing-to-see-here [09:23] Chipaca: Re your code import question on #launchpad, LP staff can edit existing code imports [09:24] cjwatson: hi :) i think i probably broke something, or don't understand how any of it works as the whole ppa vanished now afaict [09:24] ... PPA? [09:24] you mean import? [09:24] there was a ppa and a recipe and an import [09:24] the import was failing, the recipe wasn't reciping and the ppa was stale [09:25] but the gnu parallel people reply to "where's instructions for ubuntu" with "john lenton has a ppa" [09:25] Changing a code import will not delete a PPA under any circumstances [09:25] so i thought rather than try to convince gnu people that they're being bottom sombreros, i'd get it working again, but i probably broke something along the way [09:25] cjwatson: never underestimate the power of a sleepy chipaca [09:25] Right, *you* might :)( [09:25] :) [09:26] https://code.launchpad.net/~chipaca/parallel/+git/parallel looks promising now though [09:26] yep yep [09:26] cjwatson: that's a new one i made last night (trying to import the same thing to bzr failed with a credentials error?) [09:27] something about the host name not matching the cert [09:27] anyway [09:27] cjwatson: I'll pick this up again on the weekend, there is no real urgency to it [09:27] Chipaca: power tip: if you're quick then you might be able to use https://staging.launchpad.net/~chipaca as a reference for resurrecting deleted config, since staging is only restored from production weekly [09:27] cjwatson: I do appreciate you reaching out though :) [09:27] Chipaca: but you will need to do that before the weekend as it will vanish early on Saturday [09:29] cjwatson: ack. I guess it's material for tonight then :) thanks! [09:32] - Run install hook of "fwupd" snap if present (run hook "install": install: cannot create regular file '/usr/share/polkit-1/rules.d/org.freedesktop.fwupd.rules': No such file or directory) [09:42] PR snapd#6887 opened: cmd/snap-confine: combine sc_make_slave_mount_ns into caller [09:42] mborzecki: one more bit of yak shave https://github.com/snapcore/snapd/pull/6887 [09:43] PR #6887: cmd/snap-confine: combine sc_make_slave_mount_ns into caller [09:49] Bug #1829558 changed: Unable to install fwupd [09:53] Chipaca: no, it should be kept separate, it might also be that once we pass context.Context everywhere we might need to use it less deeply, but we will see. [09:54] ok [10:16] PR snapd#6886 closed: cmd/snap-update-ns: use "none" for propagation changes [10:22] Thanks! [10:22] PR snapd#6888 opened: tests: add mountinfo-tool [10:31] pstolowski: is snap unset implemented now? [10:33] zyga Im just about to propose it in a series of PRs [10:34] great, looking forward to use it :) [10:34] brb for quick coffee [10:48] mvo, hey [10:49] * zyga had a great idea [10:49] brb [10:53] re [10:57] we live in interesting times for sure: https://www.bbc.com/news/technology-48363772 [11:06] sigh [11:07] we have a test that waits for a condition in a limited loop, and then checks for the condition on exit [11:07] which sounds fine and correct [11:07] except those two conditions? not the same one [11:07] so guess what :) [11:17] i have a system where core18 won't install. It fails at the mount step. What info do I need to get from it? [11:24] 5 files changed, 2256 insertions(+) <-- guess nobody will the code now :( [11:24] at least that 1639 lines are tests [11:25] * zyga is happy about this: > [11:25] mountinfo-tool on core18 :) https://www.irccloud.com/pastebin/J8uVY9P4/ [11:27] PR snapd#6889 opened: tests/main/auto-refresh-retry: fix loop/break condition [11:28] popey_: depends :) [11:28] popey_: _how_ does it fail at the mount step? [11:28] https://forum.snapcraft.io/t/core18-fails-to-install-mount/11472 [11:28] yes [11:30] PR snapd#6890 opened: gadget: mounted filesystem writer & updater [11:31] popey_: anything interesting about this system? is it running /var off nfs from a server in antartica, for example? [11:32] nope, it's an hp microserver in my house [11:32] it has a few snaps installed [11:33] huh, I can't even remove snaps either [11:36] hmm [11:36] popey_: what does dmesg say? [11:37] sounds like something nasssty [11:37] nothing out of the ordinary [11:38] popey_: what does it say when you try to remove a snap? also a timeout from mount? [11:38] yeah, added to the forum post [11:38] repeatedly [11:38] (every 3 mins) [11:38] hmmm [11:39] popey_: ^C should abort that cleanly fwiw [11:39] zyga: want to have fun? ^ [11:39] Chipaca: I always want to have fun [11:39] ikr [11:40] meanwhile I'll go have lunch instead [11:40] popey_: can you look at dmesg to see any suspicious kernel messages? [11:41] I'm tailing it and see nothing out of the ordinary, just a bunch of the usual apparmor stuff [11:41] popey_: when something survives SIGKILL it is either 1) kernel recycled processes and systemd is confused or 2) the process is in an uninterruptible part of the kernel and cannot be killed [11:41] popey_: run top, any process with "D" state? [11:41] hmm, yes [11:42] might be io blocked [11:42] Chipaca: did another pass on 6564, thanks for the work there, fear a couple more nitpicks though [11:42] pedronis: :'( but also agreed with you [11:47] pedronis: fwiw #6816 is defonclicted and green [11:47] * Chipaca tries to actually go have lunch [11:47] PR #6816: daemon, overlord: support for cohort-key in refresh and switch [11:48] Chipaca: yes, next on my list [11:48] thank you [11:59] hey cachio ! [12:00] cachio: thanks for the update on the stable core release! [12:00] cachio: all makes sense now :) [12:01] PR snapd#6887 closed: cmd/snap-confine: combine sc_make_slave_mount_ns into caller [12:02] mvo, hey [12:02] mvo, yesterday we were waiting until last hour to do the promotion but finally we couldnt [12:02] mvo: thank you [12:03] mvo, do you prefer to make it after the stand up? or now? [12:09] cachio: either way is fine [12:09] cachio: now is ok === ricab is now known as ricab|lunch [12:17] zyga: Chipaca a reboot """fixed""" it ;) [12:17] sorry for the noise [12:18] pedronis: cachio: oops, yes 6889 and 6883 address the same issue [12:19] Chipaca, :) [12:20] cachio: what does the 'ip netns delete testns' accomplish? [12:20] cachio: wondering whether i should merge yours into mine or viceversa :) [12:21] Chipaca, if you execute twice the same test, the "ip netns add testns" fails [12:21] because it is not deleted during the restore [12:21] cachio: ah [12:21] the test was leaving the namespace created [12:21] cachio: wrt your fix for the loop thing, i like mine more because it uses a variable for the string (no dupe string), and doesn't print out the failure in a loop [12:22] cachio: but yours has more fixes than just that [12:23] cachio: i'll close mine [12:23] Chipaca, nice, thanks :) [12:24] PR snapd#6889 closed: tests/main/auto-refresh-retry: fix loop/break condition [12:33] Chipaca: commented on #6816, I think we need to agree on the func signatures/Options [12:33] PR #6816: daemon, overlord: support for cohort-key in refresh and switch [12:42] pedronis: the way i split it, UpdateOptions had everything that was about the update, whereas outside were things about how/where the update run (so state, user id, context would be outside of options, but name and flags would be inside) [12:42] pedronis: not sure what the rationale would be to split out name and flags [12:44] Chipaca: because you can craft an options and use it with many names, we don't support it or want but in theory you could pass it in UpdateMany as well [12:45] Chipaca: about flags, it's already a struct. I don't think the goal is to have functions that take one struct. The goal is to bundle things reasonably [12:46] Chipaca: anyway my strong opinion at the moment is about name and the order of userID [12:49] Chipaca: st, name, options, userID, flags seems a decent signature from where we stand atm [12:49] pedronis: and device context? [12:49] yes [12:49] pedronis: at the end? [12:50] there are different functions taking that [12:50] yes, at the end [12:50] I could just do like I did in install, and multiply the functions [12:51] leave the struct for later [12:51] that is a problem too, multiple styles [12:51] but when i did install we said yeah do it via options so i did so i now i need to do over [12:52] Chipaca: we agree to do options, not exactly how they would look like [12:52] Issue core18#129 opened: Multiarch isn't working [12:52] mup still has the typo "issues" (good) vs "issue" (broken) [12:52] Chipaca: I mean, doing a refactor and a feature in one commit/PR is a risky move [12:54] Chipaca: anyway, it's probably personal but this snapstate.Update(st, 0, &snapstate.UpdateOptions{Name: "foo", Channel: "stable"}) looks weird to me [12:54] the 0 position, and the name inside [12:54] it might also be that I don't feel the name is an option here [12:55] is the main thing we act on [12:55] being in the struct means you can also swap it around [12:56] &snapstate.UpdateOptions{Channel: "stable", Name: "foo"} [12:56] again not a clear win to be able to do that [12:56] * zyga watches spread cycles cycle [12:57] Chipaca: maybe I'm sounding unreasonable, hope not [12:58] pedronis: it seems arbitrary, but that might be on me [12:59] Chipaca: maybe your reference point it the store methods, SnapInfo / Find [12:59] not a fan of them, but they are fairly different, in terms of what they take or not [13:00] both of these seem to be trying hard not to be SomeOperation{ the stuff it needs }.Do() [13:00] * Chipaca hides [13:00] maybe go needs named arguments a la python [13:00] * Chipaca hides even more [13:00] Chipaca: maybe it does [13:01] pedronis, Chipaca standup :) ? [13:01] ops [13:01] yes [13:01] Chipaca: but I invite to consider the differences between name for Update vs Query in Find [13:01] zyga: standup? [13:01] Chipaca: also notice that at the moment SnapSpec is just Name [13:01] sorry, joining [13:01] which is funny [13:02] in its own way [13:02] Chipaca: so maybe it merits the reverse treatment at some point [13:44] Bug #1830051 opened: Fails to recognize UTF-8 locale