[02:23] <stgraber> secretfader: a combination of private snaps on the public store + https://docs.ubuntu.com/snap-store-proxy/en/ for onsite delivery may be able to do what you want
[02:25] <oerheks> oh nice
[05:16] <mborzecki> morning
[05:22] <mup> PR snapd#8915 closed: gadget: do only one mount point lookup in mounted fs updater <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8915>
[05:22] <mup> PR snapd#8921 opened: gadget: fix typo in mounted filesystem updater <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8921>
[05:52] <mup> PR snapd#8921 closed: gadget: fix typo in mounted filesystem updater <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8921>
[05:52] <mborzecki> yay
[05:52] <mborzecki> mvo: hey
[05:56] <mvo> mborzecki: good morning
[06:02] <mup> PR snapd#8911 closed: asserts,seed: split handling of essential/not essential model snaps <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8911>
[06:20] <mvo> zyga: can I help with 8881 ? looks super close, just reading the reamaining comments
[06:27] <zyga> Good morning. Let me try finishing it. I think today will be smoother than yesterday
[06:28] <mborzecki> zyga: heya
[06:28] <zyga> Hey :-)
[06:32] <mvo> ok
[06:58] <pstolowski> morning
[07:13] <mborzecki> pstolowski:  hey
[07:14] <mborzecki> anyone investigated the random failure in unit tests related to GPG?
[07:19] <zyga> not yet
[07:19] <zyga> settling in for work
[07:19] <pedronis> mborzecki: not yet
[07:20] <pedronis> mborzecki: can you explain why you think chasing the dm hiearchy is simpler? it sounds like more code, am I wrong?
[07:26] <mborzecki> pedronis: yes, it may be a bit more code, but upside is the information is coming directly from device hierarchy rather than from a specially formatted name
[07:27] <mborzecki> pedronis: otoh the name format will remain stable throughout the release as udev/systemd versions are frozen effectively
[07:28] <pedronis> mborzecki: less code is more compelling at this point to me, also because is not clear that slaves couldn't have many entries?
[07:30] <mborzecki> pedronis: it should be one for simple lvm/luks, i can find out about other scenarios
[07:31] <pedronis> mborzecki: it's ok, just pointing out that the error cases will also grow
[07:31] <mborzecki> pedronis: anyways, not a strong opinion, thought it may be worth considering given how easy it is to chase down the device with shell
[07:37] <mup> PR snapd#8922 opened: tests: fix incorrect check in smoke/remove test <Simple 😃> <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8922>
[08:24] <mborzecki> it's supper annyoing how google meet is hiding the bootom bar with the (un)mute/hangup buttons each time the window goes out of focus
[08:25] <mborzecki> obviously accompanied by an animation of the bar rolling up and down
[08:33] <zyga> heh, yes
[08:47] <mup> PR snapd#8922 closed: tests: fix incorrect check in smoke/remove test <Simple 😃> <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8922>
[08:50] <zyga> pedronis: left a small question on the assertion sequence PR: https://github.com/snapcore/snapd/pull/8906/files#r445405988
[08:50] <mup> PR #8906: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
[08:56] <pedronis> zyga: I tried to answer
[08:58] <zyga> thanks, that makes sense
[09:15] <mborzecki> meh another random test failure https://paste.ubuntu.com/p/Y5G6hx4QG7/
[09:17] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/8881/files#r445419656 it's missing a } in the template list
[09:17] <mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[09:17] <zyga> oh,
[09:18] <zyga> looking
[09:18] <mborzecki> zyga: `AddParametricSnippet([]{"/dev/", "rw," <<<hgere>>>, "sda1")`
[09:18] <mborzecki> zyga: and probably []string too
[09:19] <zyga> ah
[09:19] <zyga> I se
[09:20] <zyga> fixed
[09:21] <mborzecki> zyga: thx :)
[09:22] <zyga> I fixed string as well, just didn't push again
[09:31] <mvo> zyga: what's the state of 7700 ?
[09:31] <mvo> zyga: should this be reviewed by pedronis ?
[09:31] <zyga> looking
[09:31] <zyga> yes, it needs review to establish direction
[09:31] <mvo> zyga: preping for vMontreal I was wondering if we can try a push for refresh awareness again :)
[09:31] <mvo> zyga: cool, I add the tag
[09:31] <zyga> thanks
[09:32] <mvo> zyga: do you have an order in which these should be reviewed?
[09:32] <mvo> zyga: is 7700 the first one we should look at?
[09:32] <zyga> mvo: no, there are two PRs now, that are critical
[09:32] <zyga> this and ...
[09:33] <zyga> https://github.com/snapcore/snapd/pull/8573
[09:33] <mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
[09:33] <zyga> though that one was already reviewed and I need to expand it a littie
[09:33] <zyga> *little
[09:33] <zyga> mvo: it was reviewed already :)
[09:33] <mvo> zyga: ok, let's try to move this a bit forward before vMontreal
[09:33] <zyga> apart from that there is https://github.com/snapcore/snapd/pull/8829
[09:33] <mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
[09:33] <zyga> that needs a 2nd review and I think is ready to land
[09:34] <mvo> zyga: I do the second review
[09:34] <mvo> zyga: after my current meeting
[09:34] <zyga> and after 8829 lands I can shring https://github.com/snapcore/snapd/pull/7825 once again, it will be closer to something that is reviewable then
[09:34] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[09:35] <zyga> thank you!
[09:35] <zyga> mvo: then there is https://github.com/snapcore/snapd/pull/8863
[09:35] <mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
[09:35] <zyga> which is the lsat of the group I have now
[09:35] <zyga> it needs two reviews and I also think it is ready
[09:36] <zyga> those two should shrink the main backend PR by quite a bit, perhaps enough for it to be mostly just tests
[09:36] <zyga> there's one more PR that can be broken out but I'm blocked by those two helpers landing first
[09:37] <zyga> man github is slow on large pages :/
[09:37] <zyga> I mean, my laptop is slow
[09:37] <zyga> I want to be healthy again and use my normal work stuff
[09:39] <zyga> hrm
[09:40] <zyga> go language server is swapping on my system
[09:45] <zyga> disabled go support in code, it's useless at this stage
[09:48] <zyga> mvo: I think https://github.com/snapcore/snapd/pull/8881 is ready now
[09:48] <mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[09:49] <zyga> mvo: I'm open to changing the API again to make it even harder to use incorrectly but I don't consider it blocked anymore
[09:51]  * zyga small break to change the workspace
[09:53] <mup> PR snapd#8905 closed: bootloader: introduce managed bootloader, implement for grub <Simple 😃> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8905>
[09:53] <mborzecki> finally landed, took a bunch of restarts
[09:54] <mborzecki> now which part should i open next
[09:59] <jamesh> mvo: for what it is worth, I think some of the font cache differences come from all the static versions of fc-cache versions being linked against xenial's freetype
[10:02] <mvo> jamesh: thanks, that is good to know, so if we fix that and build with the right freetype it should be better?
[10:02] <jamesh> hopefully.  I think this is the cause of color emoji compatibility at least
[10:02] <jamesh> mvo: I think the private fontconfig cache is probably the best bet going forward though
[10:03] <mvo> jamesh: yeah, I would *love* to remove this from snapd and move it into the snaps
[10:11] <zyga> ls
[10:11] <zyga> ps
[10:11] <zyga> id
[10:11] <zyga> o/
[10:13] <mvo> bash: o/: No such file or directory
[10:14] <zyga> trying to work from the office
[10:14] <zyga> will see how it goes
[10:14] <zyga> maybe an hour or two a day
[10:17] <seb128> jamesh, mvo, should bug #1858636 be assigned to someone from the snapd team again in regard of the recent findings? ijohnson was assigned but unassigned himself
[10:17] <mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Invalid> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1858636>
[10:23] <mup> PR snapd#8923 opened: wrappers: helper for enabling services (8/9) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8923>
[10:48] <mup> PR snapd#8924 opened: gadget, bootloader: preserve managed boot assets during gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8924>
[11:02] <zyga> mborzecki: hi
[11:02] <zyga> question about managed boot assets PR
[11:02] <mborzecki> zyga: hm?
[11:02] <zyga> should BootAssets return nil if IsCurrentlyManaged returns false?
[11:03] <zyga> I know the usage below is correct
[11:03] <zyga> just asking conceptually
[11:04] <mborzecki> zyga: no, i'm not sure it's needed, i actually thought about making it part of the Bootloader interface even
[11:07] <mborzecki> zyga: iow, it answers the question as to where inside the tree can the bootloader assets be located, IsCurrentlyManaged() indicates whether those are really managed
[11:08] <pstolowski> zyga: updated #8914 per your suggestions, thanks
[11:08] <mup> PR #8914: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8914>
[11:11] <zyga> pstolowski: looking
[11:11]  * pstolowski lunch
[11:11] <zyga> pstolowski: one more question there
[11:12] <zyga> in the beginning of the diff
[11:12] <zyga> is there any risk that "old" stores more than the undesired flag?
[11:13] <zyga> perhaps we should do something like task.Set("old-conn", ConnectionState{Undesired: old.Undesired})
[11:13] <zyga> (I forgot the type names so forgive me for making the name up
[11:15] <zyga> pstolowski: not sure if you see what I'm worried about
[11:42]  * zyga breaks to wait for meds to help 
[11:42] <zyga> please review https://github.com/snapcore/snapd/pull/8881
[11:42] <mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[11:48] <mborzecki> it'd be nic to have auto cancel of runs when a PR gets updated
[11:48] <mborzecki> s/nic/nice/
[11:48] <mup> PR snapd#8925 opened: bootloader: allow managed bootloader to update its boot config <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8925>
[12:06] <pstolowski> re
[12:24]  * zyga feels better
[12:31] <pstolowski> zyga: great to hear that!
[12:31] <zyga> temporary but yeah
[12:31] <pstolowski> ijohnson: hey, can you take a look at #8899 (i think you assigned it to yourself anyway)?
[12:31] <mup> PR #8899: tests: add servicestate.Control tests (7/9) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8899>
[12:41] <ijohnson> Hey pstolowski yes it's in my queue, I started yesterday but got distracted; should finish this morning
[12:41] <pstolowski> ijohnson: sure, thanks
[13:31] <zyga> ijohnson: about ram, try the code snap and open snapd there
[13:31] <zyga> install the go extension it recommends
[13:31] <zyga> and observe ram usage
[13:31] <zyga> the official go language server immediately eats 4+GB
[13:31] <zyga> after indexing snapd
[13:32] <ijohnson> zyga: I did, I filed an issue about strict and classic snaps being confused about each other, so I don't use the code snap any more :-/
[13:32] <zyga> I had to close the editor to join the hangout
[13:32] <ijohnson> cause the code snap can't use the go snap
[13:32] <zyga> I see
[13:32] <zyga> I think it's pretty nice overall (code itself)
[13:32] <ijohnson> but I do remember trying the language server and it has some weirdness I don't remember so I turned it off
[13:33] <ijohnson> but I'm quite happy with vs code, I would love to use the snap when we can fix that bug
[13:33] <zyga> yeah but the features are really great
[13:33] <ijohnson> have you used the remote sharing feature yet?
[13:33] <zyga> no?
[13:33] <pedronis> pstolowski: I don't think I need to review that tests PR
[13:33] <ijohnson> it's quite nice actually, we used it a bit at the virtual snapcraft summit
[13:33] <ijohnson> ah live share is the name of it
[13:33] <ijohnson> https://code.visualstudio.com/blogs/2017/11/15/live-share
[13:33] <zyga> is it like something that atom had a while ago
[13:33] <pstolowski> pedronis: ok, i thought so, thanks
[13:33] <zyga> where >1 people can code in one workspace
[13:34] <zyga> really nice
[13:34] <zyga> we should try that
[13:34] <ijohnson> zyga: yeah sounds like it, I've never used atom though
[13:34] <zyga> maybe next week?
[13:34] <ijohnson> yeah we could try doing some kind of pair coding session I know we talked about trying that out all the way back in paris iirc haha
[13:41] <zyga> yeah
[13:41] <roadmr> we'll always have paris 💛
[13:43]  * zyga makes coffee
[13:44] <mup> PR snapd#8881 closed: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8881>
[13:49] <mborzecki> when snap run runs a hook (as root ofc), should we really try to create /roon/snap/<name>/<rev> ?
[13:49] <mborzecki> we don't expect hooks to try to manipulate home
[13:50] <pstolowski> mborzecki: probably not. this happens in snap-run?
[13:50] <mborzecki> pstolowski: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1884929
[13:50] <mup> Bug #1884929: snap creates (or tries to create) a direcotry in /root/snap/ <amd64> <apport-bug> <focal> <package-from-proposed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1884929>
[13:50] <mborzecki> it's running a configure hook
[13:57] <mborzecki> hmm, there's a bunch of things that happen but maybe shouldn't be when we run --hook, it's creating $HOME/snap, migrating Xauthority and activating a document portal
[14:07] <pedronis> mborzecki: it probably makes sense to do only a subset of that for hooks
[14:07] <pstolowski> mborzecki: not sure about $HOME/snap (maybe it should be crated), it's also related to what is exposed via SNAP_* env vars
[14:12] <mborzecki> pstolowski: still the hook runs as root, not sure why there would bea need to store anything inside /root instead of /var/snap/
[14:18] <pstolowski> mborzecki: they shouldn't, worried about silly hooks though
[14:29] <mup> PR snapd#8926 opened: Add microstack-support interface <Created by dshcherb> <https://github.com/snapcore/snapd/pull/8926>
[14:29] <pstolowski> oh, i think undo of snap connect has yet another bug /o\, it doesn't restore security profiles. it's only a problem with undo of individual snap connect, and not when run as part of a install/refresh change
[14:31] <pstolowski> i wonder how/when did this sneak it. probably at the time undo handlers were re-arranged
[14:59] <mup> PR snapd#8927 opened: tests: avoid exit 1 when nested type var is not defined <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8927>
[15:09]  * cachio lunch
[15:14] <pedronis> ijohnson: I think we should try to land #8683 with the current approach, https://github.com/snapcore/snapd/pull/8683#discussion_r445635143
[15:14] <mup> PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
[15:15] <ijohnson> pedronis: ok, I have not yet had a chance to explore mborzecki's recommendation but it seems that it would be more code
[15:19] <pedronis> ijohnson: I mean, if we are really paranoid about udev then we shouldn't use udevadm at all, but I don't think we are there yet
[15:19] <ijohnson> sure, I mean the udev that's there right now seems to be good enough, so I'm fine to keep using it until we have reason to want to rip it out
[15:19] <pedronis> yes
[15:24] <zyga> mvo: thank you for merging 8881
[15:24] <zyga> mvo: I will open some follow-ups for it
[15:30] <mvo> zyga: sounds good
[15:34] <pedronis> pstolowski: I reviewed #8914, lgtm
[15:34] <mup> PR #8914: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8914>
[15:35] <pstolowski> pedronis: ty
[15:35] <pedronis> pstolowski: you said there's more to fix though?
[15:36] <pstolowski> pedronis: yes, i'm afraid so, but it can be a followup. we're missing m.setupSecurityProfiles on undo
[15:36] <pedronis> pstolowski: only if it's not an auto-connect one?
[15:36] <pedronis> I mean only if we did setup profiles
[15:36] <pedronis> right?
[15:40] <pstolowski> pedronis: doConnect sets up security profiles (unless delayed-setup-profiles is set). but undo doesn't do this at all. this affects manual 'snap connect ..' if you have a hook that fails after connect
[15:41] <pedronis> pstolowski: I mean it matters only if !delayedSetupProfiles or what should happen in that case?
[15:43] <pstolowski> pedronis: we should do repo.Disconnect and then m.setupSnapSecurity like we do on connect,
[15:44] <pedronis> only if !delayedSetupProfiles ?
[15:46] <pstolowski> pedronis: yes
[15:46] <pedronis> ok, thx
[15:46] <pstolowski> pedronis: for delayedSP==true it's a different case (refresh, instal) where everything is undone and initial setup-profiles should do the right thing
[15:49] <pstolowski> pedronis: btw, with a disconnect hook that fails it is impossible (not really a surprise) to uninstall affected snap
[15:50] <pstolowski> a flag for such cases would be handy
[15:59] <pstolowski> it could set IgnoreError=true on all hooks
[15:59] <zyga> pstolowski: snap remove --force
[15:59] <zyga> ?
[16:00] <pstolowski> yep
[16:00] <zyga> mvo: any chance for a review of https://github.com/snapcore/snapd/pull/8829
[16:00] <mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
[16:00] <zyga> mborzecki: not sure if you have time today but a look at https://github.com/snapcore/snapd/pull/8863 would be great
[16:00] <mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
[16:00] <zyga> with those two I can make progress on r-a-a
[16:00] <mvo> zyga: having fun with freetype now, but let me try
[16:00] <zyga> mvo: it's not much code, just a pair of functions
[16:04] <ijohnson> zyga: I will try to review that in my PM if mvo does not finish
[16:05] <zyga> thank you so much!
[16:05] <ijohnson> zyga: I've been waiting for nested spread runs to finish, so it's easy for me to do reviews while waiting for results :-)
[16:06] <zyga> :)
[16:06] <ijohnson> cachio: so I finally got around to try and reproduce your uc20-recovery test and it finished fine for me, I ran it with `spread --debug -v google:ubuntu-core-20-64:tests/core/uc20-recovery`, is that the right test you said was failing ?
[16:08] <pedronis> cmatsuoka: I looked at #8824
[16:08] <mup> PR #8824: many: move encryption and installer from snap-boostrap to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
[16:09] <cmatsuoka> pedronis: thanks, I'll check
[16:09] <mup> PR snapd#8914 closed: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8914>
[16:20] <ish> Is there a way for a user to alter the layout after installing a snap? For example, the app I'm snapping produces datafiles as output.  Our classic install dumps this data /var/log/<app_name>..  Could they redirect it there if they choose to? By default it happily logs to a confined space I've mapped with a layout.
[16:20] <zyga> ish: users cannot alter the layout
[16:21] <ish> Ok.  Thats what I thought.  Was hoping for some command that I couldn't find to "connect" directories together.
[16:26] <mvo> zyga: fwiw, I pushed https://github.com/snapcore/fc-cache-static-builder/pull/2 - will have dinner now so let's hope ijohnson  can review, otherwise I do it in my morning
[16:26] <mup> PR fc-cache-static-builder#2: build freetype from the security pocket too <Created by mvo5> <https://github.com/snapcore/fc-cache-static-builder/pull/2>
[16:27] <zyga> mvo: ack
[16:28] <zyga> uh, 5% battery left
[16:30] <zyga> brb
[16:31] <zyga> plugged in
[16:42] <zyga> hmm
[16:42] <zyga> Variable NESTED_TYPE not defined. Exiting...
[16:43] <zyga> on tests/main/lxd-no-fuse on 18.04
[16:58] <zyga> ah
[16:58]  * zyga fixed the problem
[17:02] <cachio> zyga, there is a PR for that
[17:02] <zyga> yeah, I know, different problem
[17:03] <cachio> zyga, nice
[17:03] <zyga> it was just a message that confused me
[17:03] <zyga> cachio: updated https://github.com/snapcore/snapd/pull/8728
[17:03] <mup> PR #8728: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8728>
[17:04] <cachio> ijohnson, yes
[17:04] <cachio> ijohnson, but it is not failing in google
[17:04] <ijohnson> cachio: do you think I should just run that test in a loop ?
[17:04] <cachio> it fails with edge image
[17:04] <cachio> using external backedn
[17:04] <ijohnson> cachio: ah right now you said it was with external
[17:04] <ijohnson> cachio: ok, can you remind me which external image I need to use?
[17:04]  * zyga returns to bed
[17:05] <cachio> ijohnson, yes, 1 sec
[17:05] <zyga> (it was great to work from office again today)
[17:05] <ijohnson> zyga: glad to hear you are feeling better today :-)
[17:05] <cachio> zyga, happy to hear that
[17:05] <zyga> little by little :)
[17:06] <cachio> ijohnson, https://storage.googleapis.com/spread-snapd-tests/images/pc-amd64-20-edge-snapd_edge/pc.img.xz
[17:07] <cachio> ijohnson, I am testing now the beta image
[17:07] <ijohnson> cachio: thanks, so I just run that via qemu on my local machine, then how do I point spread to use that as the external image ?
[17:07] <ijohnson> err external backend
[17:07] <ijohnson> do I need to change some IP address or set some env var ?
[17:07] <cachio> ijohnson, then you do
[17:07] <cachio> export SPREAD_EXTERNAL_ADDRESS=localhost:8022
[17:08] <cachio> ./tests/lib/external/prepare-ssh.sh localhost 8022 sergio-j-cazzolato
[17:08] <cachio> with you lp id
[17:08] <cachio> ijohnson, and  spread -debug external:ubuntu-core-20-64:tests/core/uc20-recovery
[17:08] <cachio> that should be enough
[17:12] <ijohnson> cachio: ack will give it a try
[17:12] <cachio> ijohnson|lunch, tx
[17:19] <mup> PR snapd#8824 closed: many: move encryption and installer from snap-boostrap to gadget <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
[17:32] <sdhd-sascha> hey, zyga, not sure you are there... but is the merge of master ok. (just for speed...) Or should i look for an error? I'm just past the age of 40' ;-) ... maybe i'm different, ...
[17:33] <sdhd-sascha> i didnt like to make error... but i can't denied it...
[17:38] <ijohnson> sdhd-sascha: hi, which PR are you referring to? it's almost always ok to merge master into your branch
[17:40] <sdhd-sascha> hey, ijohnson ... i love, to rename "master" to something... ;-) I'm not bad at you ;-) All okay...
[17:41] <ijohnson> sdhd-sascha: ah are you asking about if github.com/snapcore/snapd will rename it's "main" branch from master to something else ?
[17:41] <sdhd-sascha> it's sun down here...
[17:41] <sdhd-sascha> very nice...
[17:42] <sdhd-sascha> i listen some techonicic sound
[17:42] <sdhd-sascha> i'm good, and fine...
[17:43] <sdhd-sascha> maybe, i look for my wife, what she do...
[17:45] <sdhd-sascha> Hey, ijohnson, Is not an PR. Or, did you need an Graph Algo, for GO ?
[17:46] <sdhd-sascha> At all ;) I hate programmer who analye text, and do the same reverse...
[17:50] <ijohnson> sdhd-sascha: sorry I don't quite follow your question? is there something you need help with ?
[17:57] <sdhd-sascha> ijohnson: no, no, but i give you great respect, for your development in this divicult times...
[17:57] <ijohnson> thanks
[17:57] <sdhd-sascha> :-)
[18:02] <sdhd-sascha> ijohnson: i think think you have more knowleghe, then i.... but is it okay, to say, no?
[18:08] <ijohnson> sdhd-sascha: no worries
[18:08] <ijohnson> cachio: yeah so I can reproduce the issue you were seeing, I think I understand the problem
[18:09] <sdhd-sascha> hey, you. ijohnson and cachio ;-) thank you
[18:09] <sdhd-sascha> can i send, what i want before:
[18:09] <sdhd-sascha> hey, zyga.. don't matter i respect you all. i know, that you all maybe know more formulas and grammer then i... but i stil believe, that i can scane a graph in a way, wich should to follow a goal
[18:10] <ijohnson> cachio: the issue is that with the google backend, when we boot uc20, it has that special tweak service unit to copy files into place, but we don't have such a thing for the external backend, and by default recover mode does not copy all the user data from the run mode ubuntu-data to the ephemeral ubuntu-data in recover mode
[18:10] <ijohnson> cachio: I need to look but I think I can propose a fix for this
[18:12] <sdhd-sascha> hmm
[18:15] <sdhd-sascha> ijohnson: today, i'm in flaw with my wife (lucky, that she sleep... but i love her... damn....)... okay, where should i start? I still have PR to ubuntu-image. But not the access to google...
[18:18] <sdhd-sascha> cachio: you, have my respect. Because you, like you said... Love Graph's ...
[18:19] <sdhd-sascha> hey, i need to go
[18:20] <sdhd-sascha> is it okay, for you?
[18:22] <sdhd-sascha> https://www.irccloud.com/pastebin/2OcYYwcr/
[18:25] <cachio> sdhd-sascha, sure, thanks
[18:25] <cachio> ijohnson, ood news
[18:25] <sdhd-sascha> ?
[18:27] <cachio> ijohnson, which is the problem?
[18:29] <ijohnson> cachio: the issue is that in google with uc20, /home/gopath is copied by the special snapd snap we use in the image, the snapd snap in the external backend image you showed me does not have that special snapd
[18:29] <cachio> ijohnson, ah, right
[18:30] <cachio> well snapd snap in external is not modified like we do in google
[18:30] <ijohnson> cachio: I'm looking at ways we could abuse the system to make it copy this data from the host ubuntu-data to tmpfs
[18:30] <ijohnson> cachio: exactly
[18:30] <sdhd-sascha> heym cachio yi want o talk to o  you... but my moude didnt. You are a badhttps://www.irccloud.com/?/pastebins
[18:31] <sdhd-sascha> he is bad
[18:34] <sdhd-sascha> sorry, he was nice to me.... but  hd was hard to me...
[18:35] <cachio> sdhd-sascha, sorry, do you need any help?
[18:37] <sdhd-sascha> No, why should i ly?
[18:40] <ijohnson> cachio: is there an env var for what user spread is running as on the target system, should I just use $USER ?
[18:41] <cachio> SPREAD_BACKEND external
[18:41] <sdhd-sascha> cachio: did you know the-mentor9011 big bugs. )seven centimer) are found here... I don't know whagt todo.. (IF TH4Y TO NOTHING, ok .. but else... then i love family.. _ OR?
[18:42] <cachio> ijohnson, we use that
[18:42] <ijohnson> thanks cachio
[18:43] <sdhd-sascha> :-)
[18:44] <sdhd-sascha> ijohnson: it's okay ;-9 since brexit i want another way ;-)
[19:01] <mup> PR snapcraft#3188 closed: snap: allow for different compressions for pack <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3188>
[19:01] <mup> PR snapcraft#3189 opened: Snap compression <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3189>
[20:20] <ijohnson> cachio: have you ever seen a failure like this:
[20:20] <ijohnson> https://www.irccloud.com/pastebin/pL4KWHcb/
[20:20] <ijohnson> the external VM was alive and working fine, I could ssh to it, so I'm not sure what the issue is with that
[20:21] <ijohnson> cachio: I'll retry it again, but if I could get past that I have fixed the test I think, at least I resolved the issue with not copying the gopath to recover mode
[20:25] <cachio> ijohnson, no, first time+
[20:26] <ijohnson> cachio: ack I will try again with -vv maybe I can see where it got stuck
[20:51] <mup> PR snapcraft#3189 closed: Snap compression <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3189>
[21:36]  * cachio afk