[00:50] PR snapcraft#3115 closed: build providers: ignore missing LXD instance when cleaning project [01:00] (I ended up just purging `snapd` and reinstalling it as suggested here - https://forum.snapcraft.io/t/download-snap-core-invalid-credentials/15253/17 - that worked.) [01:19] PR snapd#8645 closed: secboot: append uuid to ubuntu-data when decrypting [02:29] PR snapcraft#3116 opened: cli: fix following hints in channel status [03:52] Bug #1878131 opened: snapd caused problems in WSL [05:11] PR # closed: snapd#6258, snapd#7129, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7728, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8123, snapd#8143, snapd#8247, [05:11] snapd#8271, snapd#8301, snapd#8317, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8551, snapd#8558, snapd#8564, snapd#8566, snapd#8567, snapd#8568, snapd#8569, [05:11] snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608, snapd#8609, snapd#8612, snapd#8620, snapd#8631, snapd#8632, snapd#8633, snapd#8635, snapd#8639, snapd#8640, snapd#8643, snapd#8644 [05:11] morning [05:12] PR # opened: snapd#6258, snapd#7129, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7728, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8123, snapd#8143, snapd#8247, [05:12] snapd#8271, snapd#8301, snapd#8317, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8551, snapd#8558, snapd#8564, snapd#8566, snapd#8567, snapd#8568, snapd#8569, [05:12] snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608, snapd#8609, snapd#8612, snapd#8620, snapd#8631, snapd#8632, snapd#8633, snapd#8635, snapd#8639, snapd#8640, snapd#8643, snapd#8644 [06:14] mvo: hey [06:14] mborzecki: good morning! [06:16] PR snapd#8644 closed: cmd/snap-bootstrap/initramfs-mounts: append uuid to ubuntu-data when decrypting <⚠ Critical> [06:18] mvo: heh, i was wondering yesterday evening how that that problem fixed by ian's PR came up [06:18] PR snapd#8646 opened: tests: not fail when boot dir cannot be determined (2.45) [06:19] mborzecki: could you please check 8632 ? should be trivial :) [06:37] so weird, i can trigger the chooser trigger in recovery initrd, but not in other initrd modes for some reason [06:38] somehow it triggers after 2s instead of 10 === jamesh_ is now known as jamesh [06:56] uh, i'm stupid :/ [07:01] Hey [07:02] Winter is back! [07:02] morning [07:04] zyga: hopefully a couple of days only [07:04] zyga: pstolowski: hey ;) [07:11] Yeah :-) [07:11] Hey Paweł, any snow? [07:12] PR snapd#8647 opened: cmd/snap-bootstrap: tweak recovery trigger log messages [07:15] PR snapd#8632 closed: configcore: only reload journald if systemd is new enough (2.45) [07:15] PR snapd#8646 closed: tests: not fail when boot dir cannot be determined (2.45) [07:25] zyga: snow?? [07:25] zyga: no, it's nice and sunny, albeit only 8 C [07:27] hello, can somebody double check my commits from yesterday here: https://github.com/snapcore/snapd/pull/7129 [07:27] PR #7129: userd: allow setting default-url-scheme-handler [07:39] pedronis: looking [07:44] pedronis: only one question, but this is not something you changed, just stood out in the new test code [07:45] I found slightly odd, but then it's preexisting, always this messages are anyway completely different from the xdg-settings ones [07:45] hehe [07:45] I also found it slightly odd, but then it's preexisting, also these message are anyway completely different from the xdg-settings ones [07:45] yeah, let's land it [07:46] I'll fix the session agent service cleanup problem and carry on with usual stuf [07:47] anyway I plan to do a follow up because of the slightly confusing join/split [07:48] zyga: mborzecki: fwiw xdg-settings prints its entire help if you give it an invalid setting [07:48] that too [07:48] desktop weirdness [07:48] iirc it's a shell script anyway :P [07:49] at least it's not inventing a new IPC along the way (see new things now usnig varlink insteadof dbus or other stuff) [07:52] if anyone wants to read up more: https://varlink.org/ [07:53] i'm sure we'll go full circle back to corba & orbit at some point [07:57] mborzecki: hahahah [07:57] my first non-uni job was corba [07:57] C++ corba DRM server for a VOD service [08:51] pedronis: wdyt about including the mode in systems response for the current system? [08:52] pedronis: we also have system-info endpoint, where the mode could live too probably [08:53] mborzecki: what's the use case? [08:54] pedronis: find out the current mode (specifically adding a spread test that goes through run -> recovery -> run) [08:56] ah [08:57] pedronis: btw. can you take a look at https://github.com/snapcore/snapd/pull/8635 ? [08:57] PR #8635: o/devicestate: support doing system action reboots from recover mode [08:58] mborzecki: system-info seems the right place [08:58] pedronis: cool, i'll add it there then [08:58] mborzecki: system-mode probably [09:00] pedronis: ok [09:17] zyga: google:ubuntu-core-16-64:tests/main/snap-user-service-socket-activation is something you were debugging yesterday? [09:18] PR snapd#7129 closed: userd: allow setting default-url-scheme-handler [09:18] yes, it's debugged, just feeling some back pain so paused working [09:18] I'll fix it in a few hours [09:19] we should ask Chipaca to update the http snap to core18 [09:20] mborzecki: yes, I will look at that asap, I was in meeting and have some more [09:21] pstolowski: thanks for updating/merging master in the early config PRs, I will look at them as well [09:22] hmm we don't have grub-editenv in core18/core20 [09:22] pedronis: sure, ty. i'm looking at adding a spread test for core20 defaults (now that mvo's initramfs changes landed) [09:22] pedronis: but will likely make a separate PR [09:24] pedronis: nb core18 PR is bound to fail atm, new pc-kernel snap is not yet available and I've just removed my hack from the test [09:43] it's snowing here [09:43] mborzecki: no, that's related to why we added snap debug boot-vars [09:43] I think [09:56] errand, back in 1h or so [10:11] i still have no luck with tests/nested/core20/basic, does anyone know if it is expected to work? fails on ssh after mutiple retries [10:13] afair Sergio was working on it and fixedit, and an initrd change that was causing an issue with nested tests for core20 landed as well [10:34] re [10:35] PR snapd#8648 opened: vendor: update to latest secboot [10:41] mvo, is there an ETA for https://github.com/snapcore/snapd/pull/8329 ? (i guess 2.45 ? ) [10:41] PR #8329: interfaces: allow raw access to USB printers [10:41] ogra: correct, roughtly 2 weeks away [10:42] ogra: to hit stable, available in beta already [10:42] great, thanks ! [10:43] pedronis: are the changes in 8635 good now? [10:43] mvo: I haven't looked again, I will in a little bit (finishing lunch) [10:46] pedronis: no rush, more stuff is pending still :) [10:46] (but not that much!) [10:47] * mvo also considers lunch [10:49] it'd be so cool to learn spread about making qemu snapshots and be able to save/restore snapshot at a relevant test stage [10:50] s/learn/teach/ [10:50] iterating on uc20 tests is so annoying [11:06] mborzecki: mvo: done [11:10] pedronis: thanks [11:18] mborzecki: reviewed #8647 [11:18] PR #8647: cmd/snap-bootstrap: tweak recovery trigger log messages [11:32] hrm ... my core18 VM just rebooted in the middle of me running through console-conf ... do we do upgrades in the background even though console-conf is up ? [11:33] GRRRR ! [11:33] and again ... shutdown while creating user (a proper shutdown, not a crash) [11:34] tird time works now but this is a super annoying user experience [11:56] pstolowski: I reviewed #8533 [11:56] PR #8533: image, tests: core18 early config [11:58] mborzecki: is it expected/by design that we can't run the chooser if unseal fails? [11:59] cmatsuoka: imo it's not designed to that extent yet, when unsealing fails nothing really happens atm right? [12:00] cmatsuoka: i would expect to reboot to recovery mode and take actions from there [12:00] mborzecki: I would expect to be able to drop to a shell in recover mode without host/ubuntu-data mounted [12:00] mborzecki: yes, today you stop at the recovery key prompt [12:00] cmatsuoka: yes, so we need changes in initrd and the recovery chooser in recover mode [12:00] none of which is there atm :) [12:01] ok, just checking :) [12:01] we need to move more responsability to snap-bootstrap to control that [12:01] Ian is working on that, but is all post best stuff [12:01] s/best/beta/ [12:03] also the latest beta image is a bit confused about which certificates to use [12:03] cmatsuoka: is #8591 ready for review? [12:03] PR #8591: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot [12:04] pedronis: there's a conflict there, I still didn't merge Ian's uuid change [12:04] pedronis: will do that now [12:05] cmatsuoka: about the trigger, i'm stupid really ;) totally forgot that the time you need to hold the key is 2s only (we previously had concerns about even hitting taht long wait in iniramfs) [12:06] mborzecki: so the log is reporting what's expected? [12:06] mborzecki: and everything is consistent [12:07] cmatsuoka: yes, i think the cause is how long it takes to mount the snaps, and in recover mode your only chance of triggering it is in initramfs, because later when we seed snapd, we never start the trigger monitor service [12:09] hmmm [12:10] cmatsuoka: also for recovery mode, there sould be either a respective chooser with a bunch of actions, or something from the command line [12:10] i mean a dedicated thing that does not need to be triggered, because it's already a recovery mode [12:12] pedronis: merged and pushed [12:16] pedronis: thank you [12:16] cachio: hey, is tests/nested/core20/basic expected to work or are you working on it? [12:17] cmatsuoka: I have a question about the input [12:18] commented in the PR [12:18] pedronis: thanks, I'll check [12:18] sorry, I just updated it, was missing a not [12:22] pstolowski, hi, let me check [12:22] pedronis: yes, I think remodeling is still not ingrained in my mind -- we'll need a different approach there [12:24] pstolowski, It wotks in my branch, I think it fails in master because the change pushed to fix random generation issues [12:24] pstolowski, if you could take a quick loook should be great https://github.com/snapcore/snapd/pull/8558 [12:24] cmatsuoka: can't we fix it now? [12:24] PR #8558: tests: make the nested library usable independently of spread [12:25] pedronis: working on that [12:25] cmatsuoka: it probably need a more complicated input struct [12:25] also Chris will need to review this (hopefully more closely) [12:26] pedronis: I'm considering having model params containing model, load chains and cmdlines, and having a slice of those inside the seal params [12:26] sounds reasonable [12:28] PR snapd#8648 closed: vendor: update to latest secboot [12:29] ijohnson: can I squash merge 8635? [12:34] cachio: wasn't random generator fix supposed to fix this problem? [12:34] cachio: i'll look at your PR [12:34] pstolowski, no [12:34] pstolowski, it broke the nested run [12:35] cachio: ah [12:35] pstolowski, In my branch I fixed all the issues [12:36] shall we land https://github.com/snapcore/snapd/pull/8635 ? [12:36] PR #8635: o/devicestate: support doing system action reboots from recover mode [12:36] mborzecki: yeah, I want to squash it though [12:36] mborzecki: but yeah, lets do it, it's the last 2.45 PR :) [12:37] mborzecki: so yeah, let me land it [12:37] mvo: mghm, needs your superpowers [12:38] mvo: failed tests are unrelated [12:38] mborzecki: thanks, will merge [12:38] done and cherry-picked [12:38] yay [12:38] PR snapd#8635 closed: o/devicestate: support doing system action reboots from recover mode [13:09] PR snapcraft#3116 closed: cli: fix following hints in channel status [14:07] cachio: can you take a look at the console of machine may121345-800144 for me? [14:07] mb sure [14:07] mborzecki, ~ [14:08] mborzecki, https://paste.ubuntu.com/p/PsxkPmwcvy/ [14:10] cachio: thx, looks like it's in recover mode now [14:10] yes [14:10] it finished [14:11] mborzecki, you can't connect after that? [14:11] cachio: it rebooted again? [14:12] mborzecki, no [14:20] cachio: mvo: somehow in the spread test i cannot log into the gcp node with root/password used by spread :/ [14:20] (when in recovery0 [14:21] tbh spread should probably be better at reporting such errors [14:21] hi, is there a way to get the "prime/" dir on the host when building with --use-lxd? [14:21] ackk: use `snapcraft try` [14:22] re [14:22] * zyga is back with coffee [14:22] mborzecki: I bet it's because the hacks we apply to the image to get install mode to add the right user login bits to work don't get applied in such a way they work for install mode [14:22] standing desk helps but I had a bad back day :| [14:22] * ijohnson goes to look at that code [14:23] ijohnson, so, build with --use-lxd, then snapcraft try? or just the latter to build and try? [14:23] ackk: `snapcraft try --use-lxd` or `snapcraft --use-lxd try` I can't remember the correct order of options [14:23] ijohnson, ah I see, thanks [14:23] (and snapcraft is especially picky about such options for some reason) [14:23] mborzecki, let me try connecting through serial [14:24] mborzecki: cachio: see https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L378-L380 [14:25] ehh [14:25] ijohnson, ahhhh [14:25] ijohnson: let's see if i can tweak it :P [14:25] I'm wondering if actually an easier way to do this is just to hack the core20 snap instead [14:25] just stick our spread user/pw into the /etc/passwd that's in the core20 snap, then we can get rid of all this nonsense [14:26] ijohnson, nice find [14:26] or actually perhaps more realistically stick the spread user/pw into the var/lib/extrausers/passwd [14:26] (in the core20 snap) [14:26] though note that if you go the route of just sticking the user into the core20 snap, you still need a way to block spread from connecting via ssh during install mode [14:27] perhaps another hack script which runs during install mode and turns off ssh until run mode [14:27] mborzecki: in a meeting, let's talk about this in a wee bit, I have an idea [14:50] mborzecki: I think the problem is that in ephemeral mode we don't have https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L342 i.e. snapd.spread-tests-run-mode-tweaks.service which overlays the root user [14:51] mvo: yeah, ijohnson suggested the same, i've tweaked it a little to see what will happen now [14:52] PR snapd#8649 opened: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession [14:55] that's not urgent but small ^ [14:56] mvo: it's not easy to place a service in the ephemeral modes though, I suppose we can via hacking the initrd somehow [14:57] pedronis: yeah [14:58] but it seems we have code trying to do this but failing ? [14:58] or maybe being confused about how things work? [15:01] and it works, yay [15:28] PR snapcraft#3117 opened: ci: setup release-drafter [15:32] pstolowski: related to your naming comments, is this clearer https://github.com/pedronis/snappy/commit/959f89056cb2c5b6903fbdf30ef2159efa56a504 or worse? [15:32] looking [15:34] pedronis: yeah, it's great [15:34] thank you [15:34] pstolowski: ok, I'll propose an actual PR then [15:34] thx [15:35] once the prereq is merged [15:37] * cachio lunch [15:38] ok [15:42] PR snapd#8650 opened: daemon, tests: indicate system mode, test switching to recovery and back to run [15:42] ijohnson: mvo: ^^ [15:42] nice [15:42] cachio: ^^ also includes a tweak for restoring the seed in uc20 if that's what you had a problem with [15:45] mborzecki: nice [15:46] mborzecki: how did you fix the issue of the root login? [15:48] PR snapd#8651 opened: release: 2.45 [15:49] mvo: the special sauce is applied in run and recovery modes [15:49] mvo: https://github.com/snapcore/snapd/pull/8650/commits/a52172b01bfa470cc10b2687baa6aa8408ba3cc2 [15:49] PR #8650: daemon, tests: indicate system mode, test switching to recovery and back to run [15:50] ijohnson: haha, thanks for spotting [15:50] grr typo, meant systems: [ubuntu-core-20-*] [15:50] mborzecki: oh, nice! [15:50] hopefully I edited it in time [15:50] mborzecki: also what was the problem you found with the http snap ? [15:51] it was sending a POST when it shouldn't have been? [15:51] ijohnson: idk, switched to curl, i could see this in the logs: [15:51] May 12 10:00:26 ubuntu snapd[3346]: daemon.go:313: DEBUG: pid=3407;uid=0;socket=/run/snapd.socket; GET /v2/snaps?snaps=http%2Cjq 901.548µs 200 [15:51] May 12 10:00:28 ubuntu snapd[3346]: daemon.go:313: DEBUG: pid=3645;uid=0;socket=/run/snapd.socket; POST /v2/systems 93.149µs 405 [15:51] then the actual response was 405 method not allow and some error from our api [15:52] mborzecki: what `http` command? [15:52] ijohnson: `http snapd:///v2/systems` [15:52] same when i used `snap run http ..` [15:53] hmm [15:53] sigh [15:54] our restore is insufficient [15:55] afk for now [16:07] PR snapcraft#3118 opened: plugins: add support for local v2 plugins (core20) [16:30] PR snapd#8651 closed: release: 2.45 [16:54] mvo: the fix for the leaking units is coming along but I need to run some tests to ensure no other tasks are causing this [16:54] zyga: sure [16:54] I fixed the management script, packaging and some restore logic [16:55] but it's easy to trigger and we have many tests that use snapd as a snap === diddledan8 is now known as diddledan [17:34] PR snapcraft#3114 closed: npm v2 plugin: update doc string [17:34] PR snapcraft#3117 closed: ci: setup release-drafter [17:35] pedronis: changed the structure of seal key data to allow different sets of cmdline and load chains for different models [18:19] Has anyone else experienced Ubuntu Core suddenly prompting for a password after previously authenticating with SSH using keys? [18:19] PR snapd#8564 closed: asserts: introduce Pool [18:28] benfrancis, disk full or some such ? [18:29] orga: I don't think so, it is otherwise operating normally [18:30] well, if the key is in place it should never ask for a password [18:30] especially since we never set one by default in core (on purpose) [18:31] benfrancis: are you sure you didn't type the username wrong? I've done that before and gotten quite confused [18:33] typoing "ian" ? :) [18:33] PR snapd#8652 opened: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover [18:42] ijohnson: Hah! Genius. I forgot this box has a different username to all the others. Thanks for saving my sanity. [18:42] ogra: lol [18:42] hey it's a lot of letters [18:42] 3 > 0 hence there's a non-zero change I type it wrong [18:42] that and my sso username isn't as short as ian :-) [18:45] :) [18:56] PR snapd#8653 opened: asserts: make clearer that with label we mean a serialized label [18:57] * zyga commits some more fixes [19:03] PR snapd#8654 opened: tests: test registration with serial-authority: [generic] [19:08] pedronis: quick review https://github.com/snapcore/snapd/pull/8654#pullrequestreview-410339434 [19:08] PR #8654: tests: test registration with serial-authority: [generic] [19:10] zyga: it's derived from similar preexisting tests, maybe we should modernize them all [19:10] yeah, we used this style quite a lot [19:11] if you suggest good values for --wait and -n I can do a pss [19:11] *pass [19:13] we --maxmins nowadays [19:13] as well [19:13] anyway probably something for the next days [19:17] PR snapd#8655 opened: tests: remove generated session-agent units [19:17] --maxmins? [19:17] pedronis: https://github.com/snapcore/snapd/pull/8655 those are all the tests that needed fixing for the session agent bug [19:17] PR #8655: tests: remove generated session-agent units