[00:50] <mup> PR snapcraft#3115 closed: build providers: ignore missing LXD instance when cleaning project <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3115>
[01:00] <mpontillo> (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] <mup> PR snapd#8645 closed: secboot: append uuid to ubuntu-data when decrypting <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8645>
[02:29] <mup> PR snapcraft#3116 opened: cli: fix following hints in channel status <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3116>
[03:52] <mup> Bug #1878131 opened: snapd caused problems in WSL <Snappy:New> <https://launchpad.net/bugs/1878131>
[05:11] <mup> 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] <mup> 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] <mup> 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] <mborzecki> morning
[05:12] <mup> 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] <mup> 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] <mup> 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] <mborzecki> mvo: hey
[06:14] <mvo> mborzecki: good morning!
[06:16] <mup> PR snapd#8644 closed: cmd/snap-bootstrap/initramfs-mounts: append uuid to ubuntu-data when decrypting <UC20> <⚠ Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8644>
[06:18] <mborzecki> mvo: heh, i was wondering yesterday evening how that that problem fixed by ian's PR came up
[06:18] <mup> PR snapd#8646 opened:  tests: not fail when boot dir cannot be determined (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8646>
[06:19] <mvo> mborzecki: could you please check 8632 ? should be trivial :)
[06:37] <mborzecki> so weird, i can trigger the chooser trigger in recovery initrd, but not in other initrd modes for some reason
[06:38] <mborzecki> somehow it triggers after 2s instead of 10
[06:56] <mborzecki> uh, i'm stupid :/
[07:01] <zyga> Hey
[07:02] <zyga> Winter is back!
[07:02] <pstolowski> morning
[07:04] <mborzecki> zyga: hopefully a couple of days only
[07:04] <mborzecki> zyga: pstolowski: hey ;)
[07:11] <zyga> Yeah :-)
[07:11] <zyga> Hey Paweł, any snow?
[07:12] <mup> PR snapd#8647 opened: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
[07:15] <mup> PR snapd#8632 closed: configcore: only reload journald if systemd is new enough (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8632>
[07:15] <mup> PR snapd#8646 closed:  tests: not fail when boot dir cannot be determined (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8646>
[07:25] <pstolowski> zyga: snow??
[07:25] <pstolowski> zyga: no, it's nice and sunny, albeit only 8 C
[07:27] <pedronis> hello, can somebody double check my commits from yesterday here: https://github.com/snapcore/snapd/pull/7129
[07:27] <mup> PR #7129: userd: allow setting default-url-scheme-handler <Needs Samuele review> <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[07:39] <zyga> pedronis: looking
[07:44] <zyga> pedronis: only one question, but this is not something you changed, just stood out in the new test code
[07:45] <pedronis> I found slightly odd, but then it's preexisting, always this messages are anyway completely different from the xdg-settings ones
[07:45] <pedronis> hehe
[07:45] <pedronis> 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] <zyga> yeah, let's land it
[07:46] <zyga> I'll fix the session agent service cleanup problem and carry on with usual stuf
[07:47] <pedronis> anyway I plan to do a follow up because of the slightly confusing join/split
[07:48] <pedronis> zyga: mborzecki: fwiw xdg-settings prints its entire help if you give it an invalid setting
[07:48] <mborzecki> that too
[07:48] <mborzecki> desktop weirdness
[07:48] <mborzecki> iirc it's a shell script anyway :P
[07:49] <zyga> 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] <mborzecki> if anyone wants to read up more: https://varlink.org/
[07:53] <mborzecki> i'm sure we'll go full circle back to corba & orbit at some point
[07:57] <zyga> mborzecki: hahahah
[07:57] <zyga> my first non-uni job was corba
[07:57] <zyga> C++ corba DRM server for a VOD service
[08:51] <mborzecki> pedronis: wdyt about including the mode in systems response for the current system?
[08:52] <mborzecki> pedronis: we also have system-info endpoint, where the mode could live too probably
[08:53] <pedronis> mborzecki: what's the use case?
[08:54] <mborzecki> pedronis: find out the current mode (specifically adding a spread test that goes through run -> recovery -> run)
[08:56] <pedronis> ah
[08:57] <mborzecki> pedronis: btw. can you take a look at https://github.com/snapcore/snapd/pull/8635 ?
[08:57] <mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
[08:58] <pedronis> mborzecki: system-info seems the right place
[08:58] <mborzecki> pedronis: cool, i'll add it there then
[08:58] <pedronis> mborzecki: system-mode probably
[09:00] <mborzecki> pedronis: ok
[09:17] <mborzecki> zyga: google:ubuntu-core-16-64:tests/main/snap-user-service-socket-activation is something you were debugging yesterday?
[09:18] <mup> PR snapd#7129 closed: userd: allow setting default-url-scheme-handler <Needs Samuele review> <Created by jwheare> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7129>
[09:18] <zyga> yes, it's debugged, just feeling some back pain so paused working
[09:18] <zyga> I'll fix it in a few hours
[09:19] <mborzecki> we should ask Chipaca to update the http snap to core18
[09:20] <pedronis> mborzecki: yes, I will look at that asap, I was in meeting and have some more
[09:21] <pedronis> pstolowski: thanks for updating/merging master in the early config PRs, I will look at them as well
[09:22] <mborzecki> hmm we don't have grub-editenv in core18/core20
[09:22] <pstolowski> pedronis: sure, ty. i'm  looking at adding a spread test for core20 defaults (now that mvo's initramfs changes landed)
[09:22] <pstolowski> pedronis: but will likely make a separate PR
[09:24] <pstolowski> 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] <zyga> it's snowing here
[09:43] <pedronis> mborzecki: no, that's related to why we added snap debug boot-vars
[09:43] <pedronis> I think
[09:56] <mborzecki> errand, back in 1h or so
[10:11] <pstolowski> 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] <pstolowski> 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] <mborzecki> re
[10:35] <mup> PR snapd#8648 opened: vendor: update to latest secboot <Created by mvo5> <https://github.com/snapcore/snapd/pull/8648>
[10:41] <ogra> mvo, is there an ETA for https://github.com/snapcore/snapd/pull/8329 ? (i guess 2.45 ? )
[10:41] <mup> PR #8329: interfaces: allow raw access to USB printers <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8329>
[10:41] <mvo> ogra: correct, roughtly 2 weeks away
[10:42] <mvo> ogra: to hit stable, available in beta already
[10:42] <ogra> great, thanks !
[10:43] <mvo> pedronis: are the changes in 8635 good now?
[10:43] <pedronis> mvo: I haven't looked again, I will in a little bit (finishing lunch)
[10:46] <mvo> pedronis: no rush, more stuff is pending still :)
[10:46] <mvo> (but not that much!)
[10:47]  * mvo also considers lunch
[10:49] <mborzecki> 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] <mborzecki> s/learn/teach/
[10:50] <mborzecki> iterating on uc20 tests is so annoying
[11:06] <pedronis> mborzecki: mvo: done
[11:10] <mborzecki> pedronis: thanks
[11:18] <pedronis> mborzecki: reviewed #8647
[11:18] <mup> PR #8647: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
[11:32] <ogra> 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] <ogra> GRRRR !
[11:33] <ogra> and again ... shutdown while creating user (a proper shutdown, not a crash)
[11:34] <ogra> tird time works now but this is a super annoying user experience
[11:56] <pedronis> pstolowski: I reviewed #8533
[11:56] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[11:58] <cmatsuoka> mborzecki: is it expected/by design that we can't run the chooser if unseal fails?
[11:59] <mborzecki> cmatsuoka: imo it's not designed to that extent yet, when unsealing fails nothing really happens atm right?
[12:00] <mborzecki> cmatsuoka: i would expect to reboot to recovery mode and take actions from there
[12:00] <cmatsuoka> mborzecki: I would expect to be able to drop to a shell in recover mode without host/ubuntu-data mounted
[12:00] <cmatsuoka> mborzecki: yes, today you stop at the recovery key prompt
[12:00] <mborzecki> cmatsuoka: yes, so we need changes in initrd and the recovery chooser in recover mode
[12:00] <mborzecki> none of which is there atm :)
[12:01] <cmatsuoka> ok, just checking :)
[12:01] <pedronis> we need to move more responsability to snap-bootstrap to control that
[12:01] <pedronis> Ian is working on that, but is all post best stuff
[12:01] <pedronis> s/best/beta/
[12:03] <cmatsuoka> also the latest beta image is a bit confused about which certificates to use
[12:03] <pedronis> cmatsuoka: is #8591 ready for review?
[12:03] <mup> PR #8591: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
[12:04] <cmatsuoka> pedronis: there's a conflict there, I still didn't merge Ian's uuid change
[12:04] <cmatsuoka> pedronis: will do that now
[12:05] <mborzecki> 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] <cmatsuoka> mborzecki: so the log is reporting what's expected?
[12:06] <cmatsuoka> mborzecki: and everything is consistent
[12:07] <mborzecki> 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] <cmatsuoka> hmmm
[12:10] <mborzecki> 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] <mborzecki> i mean a dedicated thing that does not need to be triggered, because it's already a recovery mode
[12:12] <cmatsuoka> pedronis: merged and pushed
[12:16] <pstolowski> pedronis: thank you
[12:16] <pstolowski> cachio: hey, is tests/nested/core20/basic expected to work or are you working on it?
[12:17] <pedronis> cmatsuoka: I have a question about the input
[12:18] <pedronis> commented in the PR
[12:18] <cmatsuoka> pedronis: thanks, I'll check
[12:18] <pedronis> sorry, I just updated it, was missing a not
[12:22] <cachio> pstolowski, hi, let me check
[12:22] <cmatsuoka> pedronis: yes, I think remodeling is still not ingrained in my mind -- we'll need a different approach there
[12:24] <cachio> pstolowski, It wotks in my branch, I think it fails in master because the change pushed to fix random generation issues
[12:24] <cachio> pstolowski, if you could take a quick loook should be great https://github.com/snapcore/snapd/pull/8558
[12:24] <pedronis> cmatsuoka: can't we fix it now?
[12:24] <mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
[12:25] <cmatsuoka> pedronis: working on that
[12:25] <pedronis> cmatsuoka: it probably need a more complicated input struct
[12:25] <pedronis> also Chris will need to review this (hopefully more closely)
[12:26] <cmatsuoka> 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] <pedronis> sounds reasonable
[12:28] <mup> PR snapd#8648 closed: vendor: update to latest secboot <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8648>
[12:29] <mvo> ijohnson: can I squash merge 8635?
[12:34] <pstolowski> cachio: wasn't random generator fix supposed to fix this problem?
[12:34] <pstolowski> cachio: i'll look at your PR
[12:34] <cachio> pstolowski, no
[12:34] <cachio> pstolowski, it broke the nested run
[12:35] <pstolowski> cachio: ah
[12:35] <cachio> pstolowski, In my branch I fixed all the issues
[12:36] <mborzecki> shall we land https://github.com/snapcore/snapd/pull/8635 ?
[12:36] <mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
[12:36] <mvo> mborzecki: yeah, I want to squash it though
[12:36] <mvo> mborzecki: but yeah, lets do it, it's the last 2.45 PR :)
[12:37] <mvo> mborzecki: so yeah, let me land it
[12:37] <mborzecki> mvo: mghm, needs your superpowers
[12:38] <mborzecki> mvo: failed tests are unrelated
[12:38] <mvo> mborzecki: thanks, will merge
[12:38] <mvo> done and cherry-picked
[12:38] <mvo> yay
[12:38] <mup> PR snapd#8635 closed: o/devicestate: support doing system action reboots from recover mode <Squash-merge> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8635>
[13:09] <mup> PR snapcraft#3116 closed: cli: fix following hints in channel status <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3116>
[14:07] <mborzecki> cachio: can you take a look at the console of machine may121345-800144 for me?
[14:07] <cachio> mb sure
[14:07] <cachio> mborzecki, ~
[14:08] <cachio> mborzecki, https://paste.ubuntu.com/p/PsxkPmwcvy/
[14:10] <mborzecki> cachio: thx, looks like it's in recover mode now
[14:10] <cachio> yes
[14:10] <cachio> it finished
[14:11] <cachio> mborzecki, you can't connect after that?
[14:11] <mborzecki> cachio: it rebooted again?
[14:12] <cachio> mborzecki, no
[14:20] <mborzecki> cachio: mvo: somehow in the spread test i cannot log into the gcp node with root/password used by spread :/
[14:20] <mborzecki> (when in recovery0
[14:21] <mborzecki> tbh spread should probably be better at reporting such errors
[14:21] <ackk> hi, is there a way to get the "prime/" dir on the host when building with --use-lxd?
[14:21] <ijohnson> ackk: use `snapcraft try`
[14:22] <zyga> re
[14:22]  * zyga is back with coffee 
[14:22] <ijohnson> 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] <zyga> standing desk helps but I had a bad back day :|
[14:22]  * ijohnson goes to look at that code
[14:23] <ackk> ijohnson, so, build with --use-lxd, then snapcraft try? or just the latter to build and try?
[14:23] <ijohnson> ackk: `snapcraft try --use-lxd` or `snapcraft --use-lxd try` I can't remember the correct order of options
[14:23] <ackk> ijohnson, ah I see, thanks
[14:23] <ijohnson> (and snapcraft is especially picky about such options for some reason)
[14:23] <cachio> mborzecki, let me try connecting through serial
[14:24] <ijohnson> mborzecki: cachio: see https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L378-L380
[14:25] <mborzecki> ehh
[14:25] <cachio> ijohnson, ahhhh
[14:25] <mborzecki> ijohnson: let's see if i can tweak it :P
[14:25] <ijohnson> I'm wondering if actually an easier way to do this is just to hack the core20 snap instead
[14:25] <ijohnson> 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] <cachio> ijohnson, nice find
[14:26] <ijohnson> or actually perhaps more realistically stick the spread user/pw into the var/lib/extrausers/passwd
[14:26] <ijohnson> (in the core20 snap)
[14:26] <ijohnson> 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] <ijohnson> perhaps another hack script which runs during install mode and turns off ssh until run mode
[14:27] <mvo> mborzecki: in a meeting, let's talk about this in a wee bit, I have an idea
[14:50] <mvo> 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] <mborzecki> mvo: yeah, ijohnson suggested the same, i've tweaked it a little to see what will happen now
[14:52] <mup> PR snapd#8649 opened: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <https://github.com/snapcore/snapd/pull/8649>
[14:55] <pedronis> that's not urgent but small ^
[14:56] <pedronis> 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] <mvo> pedronis: yeah
[14:58] <pedronis> but it seems we have code trying to do this but failing ?
[14:58] <pedronis> or maybe being confused about how things work?
[15:01] <mborzecki> and it works, yay
[15:28] <mup> PR snapcraft#3117 opened: ci: setup release-drafter <project-health> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3117>
[15:32] <pedronis> pstolowski: related to your naming comments, is this clearer https://github.com/pedronis/snappy/commit/959f89056cb2c5b6903fbdf30ef2159efa56a504 or worse?
[15:32] <pstolowski> looking
[15:34] <pstolowski> pedronis: yeah, it's great
[15:34] <pstolowski> thank you
[15:34] <pedronis> pstolowski: ok, I'll propose an actual PR then
[15:34] <pedronis> thx
[15:35] <pedronis> once the prereq is merged
[15:37]  * cachio lunch
[15:38] <pstolowski> ok
[15:42] <mup> PR snapd#8650 opened: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8650>
[15:42] <mborzecki> ijohnson: mvo: ^^
[15:42] <ijohnson> nice
[15:42] <mborzecki> cachio: ^^ also includes a tweak for restoring the seed in uc20 if that's what you had a problem with
[15:45] <mvo> mborzecki: nice
[15:46] <mvo> mborzecki: how did you fix the issue of the root login?
[15:48] <mup> PR snapd#8651 opened: release: 2.45 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8651>
[15:49] <mborzecki> mvo: the special sauce is applied in run and recovery modes
[15:49] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/8650/commits/a52172b01bfa470cc10b2687baa6aa8408ba3cc2
[15:49] <mup> PR #8650: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8650>
[15:50] <mborzecki> ijohnson: haha, thanks for spotting
[15:50] <ijohnson> grr typo, meant systems: [ubuntu-core-20-*]
[15:50] <mvo> mborzecki: oh, nice!
[15:50] <ijohnson> hopefully I edited it in time
[15:50] <ijohnson> mborzecki: also what was the problem you found with the http snap ?
[15:51] <ijohnson> it was sending a POST when it shouldn't have been?
[15:51] <mborzecki> ijohnson: idk, switched to curl, i could see this in the logs:
[15:51] <mborzecki> 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] <mborzecki> 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] <mborzecki> then the actual response was 405 method not allow and some error from our api
[15:52] <ijohnson> mborzecki: what `http` command?
[15:52] <mborzecki> ijohnson: `http snapd:///v2/systems`
[15:52] <mborzecki> same when i used `snap run http ..`
[15:53] <ijohnson> hmm
[15:53] <zyga> sigh
[15:54] <zyga> our restore is insufficient
[15:55] <mborzecki> afk for now
[16:07] <mup> PR snapcraft#3118 opened: plugins: add support for local v2 plugins (core20) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3118>
[16:30] <mup> PR snapd#8651 closed: release: 2.45 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8651>
[16:54] <zyga> 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] <mvo> zyga: sure
[16:54] <zyga> I fixed the management script, packaging and some restore logic
[16:55] <zyga> but it's easy to trigger and we have many tests that use snapd as a snap
[17:34] <mup> PR snapcraft#3114 closed: npm v2 plugin: update doc string <documentation> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3114>
[17:34] <mup> PR snapcraft#3117 closed: ci: setup release-drafter <project-health> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3117>
[17:35] <cmatsuoka> pedronis: changed the structure of seal key data to allow different sets of cmdline and load chains for different models
[18:19] <benfrancis> Has anyone else experienced Ubuntu Core suddenly prompting for a password after previously authenticating with SSH using keys?
[18:19] <mup> PR snapd#8564 closed: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8564>
[18:28] <ogra> benfrancis, disk full or some such ?
[18:29] <benfrancis> orga: I don't think so, it is otherwise operating normally
[18:30] <ogra> well, if the key is in place it should never ask for a password
[18:30] <ogra> especially since we never set one by default in core (on purpose)
[18:31] <ijohnson> benfrancis: are you sure you didn't type the username wrong? I've done that before and gotten quite confused
[18:33] <ogra> typoing "ian" ? :)
[18:33] <mup> PR snapd#8652 opened: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8652>
[18:42] <benfrancis> ijohnson: Hah! Genius. I forgot this box has a different username to all the others. Thanks for saving my sanity.
[18:42] <benfrancis> ogra: lol
[18:42] <ijohnson> hey it's a lot of letters
[18:42] <ijohnson> 3 > 0 hence there's a non-zero change I type it wrong
[18:42] <ijohnson> that and my sso username isn't as short as ian :-)
[18:45] <ogra> :)
[18:56] <mup> PR snapd#8653 opened: asserts: make clearer that with label we mean a serialized label <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8653>
[18:57]  * zyga commits some more fixes
[19:03] <mup> PR snapd#8654 opened: tests: test registration with serial-authority: [generic] <Created by pedronis> <https://github.com/snapcore/snapd/pull/8654>
[19:08] <zyga> pedronis: quick review https://github.com/snapcore/snapd/pull/8654#pullrequestreview-410339434
[19:08] <mup> PR #8654: tests: test registration with serial-authority: [generic] <Created by pedronis> <https://github.com/snapcore/snapd/pull/8654>
[19:10] <pedronis> zyga: it's derived from similar preexisting tests, maybe we should modernize them all
[19:10] <zyga> yeah, we used this style quite a lot
[19:11] <zyga> if you suggest good values for --wait and -n I can do a pss
[19:11] <zyga> *pass
[19:13] <pedronis> we --maxmins nowadays
[19:13] <pedronis> as well
[19:13] <pedronis> anyway probably something for the next days
[19:17] <mup> PR snapd#8655 opened: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
[19:17] <zyga> --maxmins?
[19:17] <zyga> pedronis: https://github.com/snapcore/snapd/pull/8655 those are all the tests that needed fixing for the session agent bug
[19:17] <mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
[19:18] <zyga> I have follow ups to improve the packaging
[19:18] <zyga> and I have some more for test restore but I won't propose is as it needs some more work
[19:19] <zyga> this is the other part of it
[19:19] <zyga> https://github.com/snapcore/snapd/pull/8656
[19:19] <mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
[19:19] <zyga> the rest needs more work and some discussion
[19:20] <zyga> https://github.com/snapcore/snapd/pull/8655/files is rather mechanical and mundane but will get us a lot fewer failing tests
[19:20] <mup> PR snapd#8656 opened: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
[19:20] <mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
[19:24] <zyga> cachio: hey, about that mount-ns test
[19:24] <zyga> cachio: I don't know if you noticed my comment during the standup
[19:24] <zyga> cachio: but it would be best if you push a change to use the new image and disables the mount-ns test on ubuntu 18.04
[19:24] <zyga> cachio: and I can follow-up with a change that re-enables the test
[19:25] <cachio> zyga, sure
[19:25] <zyga> cachio: thanks, if you push that I can follow up tomorrow
[19:25] <cachio> I'll create the pr to disable mount-ns right now
[19:29] <cachio> zyga, #8657
[19:29] <zyga> thanks!
[19:29] <mup> PR #8657: tests: disable mount-ns test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
[19:29] <mup> PR snapd#8657 opened: tests: disable mount-ns test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
[19:29] <cachio> I'll merge it once tests pass and then I will promote the new bionic image
[19:29] <cachio> zyga, thanks f
[19:29] <zyga> ok
[19:42] <zyga> ijohnson: could you spare a moment to look at pawel's comment on https://github.com/snapcore/snapd/pull/8633 -- specifically this one: https://github.com/snapcore/snapd/pull/8633#discussion_r423134486
[19:42] <mup> PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
[19:43] <ijohnson> zyga: sure let me quick look
[19:43] <zyga> I'd love to get this merged so that detecting issues (of more than just this kind) os easier
[19:43] <ijohnson> zyga: the separate PR comment you mean?
[19:43] <zyga> but perhaps I picked the unlucky first problem :)
[19:43] <zyga> yes
[19:43] <ijohnson> mmm
[19:43] <zyga> I mean, I wonder what to do with /home/ubuntu - I'd be happy to park that for now and focus on more pressing problems
[19:44] <zyga> but perhaps pawel is right and we should explicitly discuss this
[19:44] <ijohnson> I guess I'm kinda leaning towards doing this in a separate PR, but that's only if you are not about to immediately work on debugging what is creating those things
[19:45] <ijohnson> if you are going to work on debugging that very soon, then I'd say let's just merge it and you can debug in a followup
[19:45] <zyga> I spent some time on it and my best theory is that it's cloud init as it happens in GCE but not in qemu
[19:45] <ijohnson> ah
[19:45] <ijohnson> interresting
[19:45] <zyga> I think the real bug is that /home/ubuntu is root-owned
[19:46] <zyga> it's late so I'll EOD anyway but I want to attack this early tomorrow and make progress
[19:46] <pedronis> I'm a bit confused, why I said ignore ubuntu I meant ignore it, not override it
[19:47] <zyga> pedronis: ignore as in exclude?
[19:47] <pedronis> well, I asked whether it matters, you said no
[19:47] <pedronis> so yes, excelude
[19:47] <pedronis> unless it matters
[19:47] <pedronis> for actual tests
[19:47] <ijohnson> actually I agree with pedronis just excluding that dir from the check I think is best for now
[19:48] <zyga> not for actual tests (at least not yet)
[19:48] <zyga> ok, I'll do that then
[19:48] <zyga> I think it only matters to the extent that we should understand our stack and what's going on
[19:50] <pedronis> also at some point we should really rename some of the *-tool because I really don't expect a thing called invariant-tool to anything but check them
[19:51] <zyga> happy to sit down and discuss names when you have a moment
[20:38] <mup> PR snapd#8658 opened: cmd/snap-bootstrap/initramfs-mounts: cosmetic changes in prep for future work <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8658>
[20:56] <mup> PR snapd#8659 opened: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8659>
[21:04] <mup> PR snapcraft#3119 opened: elf: fix string format for debug log <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3119>
[21:09] <teward> any way to disable snap autoupdates for a specific snap?
[21:17] <TheCowboy> Is there any straightforward workaround to giving a snap app access to a NFS mount? I've tried mounting under /home/$USER without any luck
[21:24] <oerheks> teward, i find no such option, for a single snap
[21:24] <teward> any way to do it globally then for all snaps on a given snapd instance?
[21:24] <oerheks> TheCowboy, see softwarecenter > installed > snapname > settings ?
[21:25] <oerheks> else reinstall the snap with the --classic option, to escape confinement
[21:26] <TheCowboy> --classic didn't work, --classic --edge didn't work
[21:34] <TheCowboy> i don't see it installed in the software center but i installed it via commandline
[22:01] <TheCowboy> Might this work? https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552
[22:01] <mup> Bug #1662552: snaps don't work with NFS home <snapd:Fix Released by zyga> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1662552>
[22:05] <oerheks> interesting; " If a user logs in and snapd is restart, NFS support is then enabled." https://forum.snapcraft.io/t/snaps-and-nfs-home/438/23
[22:05] <oerheks> marq 19
[23:00] <ijohnson> oerheks: that does not work, you cannot install a strictly confined snap in classic mode
[23:01] <ijohnson> oerheks: the --classic option is just ignored for strict snaps, it does not let you escape confinement
[23:01] <oerheks> correct, confinement is not the right word, i meant access to the /home folder
[23:02] <oerheks> and not knowing which snap.