[06:35] <zyga> o/
[06:39] <zyga> day of apple updates
[06:40] <zyga> everything has an update today
[06:44] <mborzecki> morning
[06:59] <mborzecki> mvo: mroning
[07:00] <mborzecki> mvo: could you take a look at https://github.com/snapcore/snapd/pull/8289 ?
[07:00] <mup> PR #8289: xdgopenproxy: forward requests to the desktop portal <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8289>
[07:01] <mvo> mborzecki: good morning
[07:02] <mvo> mborzecki: sure
[07:39] <zyga> good morning guys
[07:39] <zyga> I need to help with breakfast
[07:41] <zyga> thank you for reviewing the actions PR
[07:41] <zyga> I'll be around soon
[07:55] <mvo> zyga: good morning
[07:56] <mvo> mborzecki: what is the best snap to test the xdg branch with? just want to give it a quick test run for realz on my focal system
[07:57] <mborzecki> mvo: hm i think some browser, download a file and then choose to open it or open the download directory, firefox or chromium should work
[07:58] <mborzecki> mvo: or just a snap with desktop plug, run xdg-open <somefile>
[07:58] <mborzecki> or <some-dir>
[07:59] <mvo> mborzecki: ok
[08:05] <pstolowski> morning
[08:06] <mvo> hey pstolowski
[08:07] <mborzecki> pstolowski: pedronis: hey
[08:07] <mborzecki> hm soemthing broken with travis <-> gh
[08:08] <zyga> re
[08:08] <mborzecki> the travis job in #8333 was green, but the status in gh page was still in-progress, i've restarted one of the jobs to see if the status will get updated, but we should monitor whether this is a wider problem :/
[08:08] <mup> PR #8333:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
[08:08] <zyga> mvo: can you please land https://github.com/snapcore/snapd/pull/8331
[08:08] <mup> PR #8331: github: run spread via github actions <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8331>
[08:08] <zyga> there's a 2nd run of travis pending there
[08:08] <zyga> and it's just a waste of time to wait
[08:09] <mvo> zyga: if we land it as is, don't we generate twice the GCE cost?
[08:09] <zyga> mvo: hmm hmm
[08:09] <zyga> indeed
[08:09] <zyga> what do you suppose we should do
[08:10] <mvo> zyga: if we switch to GH action we should disable travis integration tests
[08:10] <zyga> mvo: how do we do that?
[08:10] <zyga> just edit the yaml?
[08:11] <mborzecki> zyga: yeah, i think so
[08:11] <zyga> ok, let me
[08:12] <zyga> mvo: I can move the macos build over as well
[08:13] <mvo> zyga: I think that makes sense, can GH actions do that?
[08:13] <zyga> yes
[08:13] <mvo> zyga: if we don't disable this we still have to wait for travis
[08:14] <zyga> mvo: libzt has tests for windows, macos and linux this way
[08:14] <mvo> zyga: we also need to make sure we don't regress
[08:14] <zyga> mvo: little by litte, let me move travis spread over first
[08:14] <zyga> yeh
[08:14] <zyga> I won't do it in one big change
[08:14] <mvo> zyga: in the sense that the static tests need to run shellcheck and all that
[08:14] <mvo> zyga: sure
[08:14] <zyga> yeah
[08:14] <mvo> zyga: just stating the obvious I guess :)
[08:14] <zyga> being careful is good :)
[08:15] <zyga> but I'm happy that this will save the team a *lot* of time
[08:16] <pedronis> mborzecki: I'm going to pick #8336, if I understand correctly you reviewed the one after, and are mostly happy with it?
[08:16] <mup> PR #8336: boot,many: add modeenv.WriteTo, make Write take no args <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8336>
[08:17] <zyga> mvo: pushed https://github.com/snapcore/snapd/pull/8331
[08:17] <mup> PR #8331: github: run spread via github actions <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8331>
[08:17] <zyga> just watch how they run
[08:18] <ijohnson> pedronis: sorry I missed your ping last night I am working now and will address your comments in that PR if you are not already done
[08:18] <zyga> ijohnson: good morning? !
[08:18] <ijohnson> hey zyga
[08:18] <zyga> how are you up at this time?
[08:19] <pedronis> ijohnson: well, I didn't expect you to be up at this time
[08:19] <ijohnson> eh it's not a big deal, didn't get much done last night so making up the time now
[08:20] <pedronis> ijohnson: I'm kind of half way, if you can work continue downstream it's fine, I also want to remove DeviceManager.modeEnv in an immediate follow up
[08:20] <pedronis> s/work continue/continue work/
[08:21] <zyga> could someone please tell me how google-tpm backends used?
[08:22] <zyga> do we only run them manually?
[08:27] <mborzecki> pedronis: yeah, i think it looks ok, devicemgr seems to be the only place where we may need add a consistency check
[08:44] <pedronis> mborzecki: I'm just going reread it, as I said I want to remove it
[08:44] <pedronis> in the next one
[08:44] <mborzecki> ok
[08:58] <pedronis> mborzecki: ijohnson: pushed, please take a look
[09:12] <pstolowski> #8335 needs a second review if anyone has a moment, and it will help with one of my PRs
[09:12] <mup> PR #8335: many: introduce naming.WellKnownSnapID <Created by pedronis> <https://github.com/snapcore/snapd/pull/8335>
[09:16] <zyga> I'm seeing failures on core16 reboot test
[09:16] <zyga> kill timeout reached
[09:17] <zyga> is anyone else seeing this?
[09:18] <pstolowski> mborzecki: #8333 can land?
[09:18] <mup> PR #8333:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
[09:19] <mborzecki> pstolowski: it's finally green?
[09:19] <pstolowski> yes
[09:19] <mborzecki> squash merged it
[09:20] <mvo> mborzecki: \o/ will cherry-pick (in a meeting right now)
[09:20] <mup> PR snapd#8333 closed:  wrappers: fix timer schedules that are days only <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8333>
[09:20] <mborzecki> mvo: ^^
[09:22] <mvo> mborzecki: done
[09:22] <mborzecki> mvo: thank you!
[09:22] <mvo> mborzecki: thank *you* :)
[09:23]  * mborzecki is just fixing the bugs he introduced ;)
[09:45] <pedronis> yes #8335 needs a 2nd review
[09:45] <mup> PR #8335: many: introduce naming.WellKnownSnapID <Created by pedronis> <https://github.com/snapcore/snapd/pull/8335>
[09:45] <pedronis> mborzecki: ijohnson: thanks for looking 8336, will work on a follow up to remove DeviceManager.modeEnv
[09:53] <Laney> hi, I've got a snap that is complaining about $XDG_RUNTIME_DIR not existing
[09:53] <Laney> that is true, but I'm wondering what I'm supposed to do about it; shouldn't snapd be creating this?
[09:54] <zyga> Laney: do you have some more details, is is a strict orclassic snap?
[09:54] <Laney> hey zyga
[09:54] <zyga> Laney: how are you running it (ssh/desktop/etc)
[09:54] <zyga> hey :)
[09:54] <Laney> It's a strict one that I've been working with ximion on creating over the last few days (we've been running with dev mode up until now)
[09:55] <Laney> ok, so I created an LXD container running bionic, used `lxc shell` to get into that, installed the snap and then tried to run its binary
[09:55] <Laney> as the 'ubuntu' user
[09:56] <zyga> ok
[09:56] <zyga> how did you do that?
[09:56] <Laney> run the binary?
[09:56] <zyga> specifically the last past
[09:56] <zyga> *part
[09:56] <Laney> I just ran the thing that is in $PATH
[09:56] <zyga> as the ubuntu user
[09:56] <Laney> appstream-generator <some arguments>
[09:56] <zyga> lxc shell drops you as a root into the container
[09:56] <zyga> what did you do next?
[09:56] <Laney> sudo -u ubuntu -i
[09:57] <zyga> ok
[09:57] <Laney> ah ok, are you saying that I didn't get a full PAM sessino and the snap requires that?
[09:57] <zyga> did that define $XDG_RUNTIME_DIR?
[09:57] <zyga> I suspect that's the case
[09:57] <zyga> it's a mess/zoo, depending on how one looks
[09:57] <Laney> well no, but snapd sets it anyway ;-)
[09:58] <zyga> yes but we assume it was there to begin with since we use a subdirectory
[09:58] <zyga> Laney: can you try with runuser -l ubuntu please
[09:58] <zyga> or runuser -l - ubuntu
[09:58] <zyga> it's gimmicky
[09:59] <jamesh> Laney: it's probably because snap-confine modifies XDG_RUNTIME_DIR (setting it to $XDG_RUNTIME_DIR/snap.$SNAP_NAME), but doesn't create that directory
[09:59] <jamesh> that would be my guess
[09:59] <zyga> jamesh: yeah, I'm sure it's that
[09:59] <Laney> correct
[09:59] <zyga> I guess we could be smarter
[09:59] <Laney> so I've been given an invalid value there
[09:59] <jamesh> there is a workaround in snapcraft-desktop-helpers to try and create it
[09:59] <zyga> by not setting it
[09:59] <zyga> if it's unset
[09:59] <zyga> it's not like we're pam
[09:59] <zyga> we don't want to be
[10:00] <zyga> we're in self-isolation mode
[10:01] <jamesh> snap-confine used to create it, but the setup_user_xdg_runtime_dir call is commented out for some reason
[10:01] <zyga> jamesh: it's been dead for years
[10:01] <jamesh> yep
[10:01] <zyga> jamesh: I think we cannot really create it because it's a part of a bigger setup process
[10:01] <zyga> I would prefer to understand why we're not getting one
[10:01] <jamesh> and been tripping people up for years
[10:04] <mup> PR snapd#8336 closed: boot,many: add modeenv.WriteTo, make Write take no args <Simple 😃> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8336>
[10:05] <Laney> got a call, hang on, I'll be back with you in a little minute
[10:05] <pstolowski> i need to do some shopping while it's quiet in the shops. will be back in ~1h
[10:06]  * pstolowski goes to grocery
[10:11] <Laney> zyga: Right, ok, so if I have a PAM session then the regular $XDG_RUNTIME_DIR is created but the snap-specific one isn't - is it up to me to make that atm?
[10:11] <zyga> Laney: hmmm
[10:11] <zyga> Laney: no, that's a known bug :)"
[10:12] <zyga> but usually apps kind of handle that (sometimes0
[10:12] <zyga> that bug we should fix
[10:12] <zyga> it was in the dark days of how do we fix this
[10:12] <zyga> and endless discussions on how to proceed
[10:12] <zyga> mvo: offtopic, unstable workers actually pass
[10:12] <Laney> heh
[10:12] <Laney> ok
[10:13] <mvo> zyga: haha
[10:13] <mvo> zyga: nice
[10:17] <zyga> can you merge 8331
[10:17] <zyga> I think waiting for travis there is not useful
[10:17] <zyga> especially that reboot test seems to be failing
[10:17] <zyga> Laney: not to leave you hanging, I think this is our bug
[10:22] <mup> PR snapd#8331 closed: github: run spread via github actions <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8331>
[10:28] <Laney> zyga: ok, thanks, that part is at least not too hard to deal with though
[10:29] <mup> PR snapd#8338 opened: boot/bootstate20: rm bootState20Base.loadModeenv() <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8338>
[10:30] <mup> PR snapd#8339 opened: dirs,many: add EarlyBootUbuntu{Data,Boot,Seed} <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8339>
[10:34] <mup> PR snapd#8340 opened: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
[10:34] <ijohnson> pedronis: ok, I finished the middle ground implementation, see ^ it is stacked on 8339, so I'd recommend looking at that one first
[10:35]  * ijohnson needs to go eat something, biab
[10:37] <mup> PR snapd#8326 closed: [wip] boot: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8326>
[10:38] <mup> PR snapd#8019 closed: [RFC] interfaces/apparmor: don't emit deny rules in devmode confinement <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8019>
[10:43] <zyga> brb
[11:19] <mup> PR snapd#8341 opened: github: don't fail-fast <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8341>
[11:24] <pstolowski> re
[11:37] <mup> Issue core20#27 closed: iptables is missing <Created by alfonsosanchezbeato> <Closed by xnox> <https://github.com/snapcore/core20/issue/27>
[11:37] <mup> PR core20#28 closed: Add iptables package <Created by alfonsosanchezbeato> <Closed by xnox> <https://github.com/snapcore/core20/pull/28>
[11:49] <mup> PR snapd#8342 opened: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
[11:49] <mborzecki> pedronis: ^^
[11:58] <zyga> uh
[11:59] <zyga> getting a qemu image on focal run into this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951766
[12:03] <mup> PR snapd#8343 opened: config, features: move and rename config.GetFeatureFlag helper to features.Flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8343>
[12:06] <pedronis> ijohnson: mborzecki: https://github.com/snapcore/snapd/pull/8344
[12:06] <mup> PR #8344: overlord/devicestate,boot: do not hold to the originally read modeenv <Created by pedronis> <https://github.com/snapcore/snapd/pull/8344>
[12:06] <mup> PR snapd#8344 opened: overlord/devicestate,boot: do not hold to the originally read modeenv <Created by pedronis> <https://github.com/snapcore/snapd/pull/8344>
[12:09] <pedronis> #8309 needs a 2nd review
[12:09] <mup> PR #8309: o/configcore: FilesystemOnlyApply method for early configuration of core (1/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
[12:16] <zyga> brb
[12:28] <mup> PR snapd#8341 closed: github: don't fail-fast <Simple 😃> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8341>
[12:28] <zyga> ta
[12:28] <pedronis> pstolowski: I have quite a few meetings today after the standup, can we talk about the code reorg in conficore before the standup?
[12:34] <mup> PR snapcraft#2972 closed: catkin plugins: remove bash workaround for catkin cmake args <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2972>
[12:37] <pedronis> mborzecki: some initial quick comments on #8342
[12:37] <mup> PR #8342: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
[12:39] <mborzecki> pedronis: thanks, let me see
[12:41] <mborzecki> pedronis: hm sytem label isn't part of SystemAction but we could use /v2/systems/{label}, wdyt?
[12:42] <pedronis> mborzecki: ah, sorry
[12:43] <pedronis> mborzecki: yes, that would be fine. you can do snap install foo  with /snaps/foo action=install
[12:44] <mborzecki> cool
[12:44] <pedronis> mborzecki: so DoSystemAction(sysLabel, sysAction) ?
[12:45] <mborzecki> pedronis: yes, and {"action":"do", "mode": "<action>"} POST'ed to /v2/systems/{label}
[12:46] <mborzecki> pedronis: we can probably skip the "title" bit which is part of SystemAction in the request
[12:46] <pedronis> mborzecki: I think is much easier to give back what we received
[12:47] <pedronis> we just can make some bits optional
[12:47] <pedronis> but I doube we just simply  pass mode along forever
[12:47] <pedronis> *doubt
[12:49] <mborzecki> ok
[12:52] <pstolowski> pedronis: yes, i'm having a quick lunch atm, will be available in ~20 minutes
[13:10] <pedronis> pstolowski: ok, ping me
[13:14]  * zyga is happy to see green spread on unstable systems so often
[13:14] <pstolowski> pedronis: i'm ready
[13:14] <pedronis> pstolowski: going to the standup
[13:25] <zyga> I think I know why session-tool _sometimes_ fails its spread test
[13:56] <mup> PR snapd#8345 opened: boot/overlord: rename operating mode to system mode  <Created by pedronis> <https://github.com/snapcore/snapd/pull/8345>
[13:58] <pedronis> zyga: got some apt failure there ^ with gh actions
[13:58] <pedronis> do I need to merge master?
[13:58] <zyga> ijohnson saw this once as well
[13:58] <zyga> let me look
[13:58] <zyga> hmm
[13:58] <zyga> no, no need
[13:59] <zyga> I have an idea how to avoid this entirely
[13:59] <zyga> oh, standup
[13:59] <zyga> pedronis: I'll send a patch after the call
[14:10] <mup> PR snapd#8346 opened: github: try caching apt archive <Created by zyga> <https://github.com/snapcore/snapd/pull/8346>
[14:14] <zyga> pedronis: fixed
[14:14] <zyga> I added apt-get update
[14:14] <zyga> and added caching so we should only fetch it once for now
[14:14] <zyga> until debian/control changes
[14:49] <mvo> pstolowski: please try https://paste.ubuntu.com/p/73PbWvsTfy/
[14:49] <mvo> pstolowski: looks like a very silly bug if it's that
[14:50] <mup> PR snapcraft#2993 opened: repo: remove dead code from deb implementation <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2993>
[14:55] <mborzecki> so azure.archive.ubuntu.com is still out of sync now?
[15:00] <pedronis> pstolowski: I forgot, this is the PR to pick up: https://github.com/snapcore/snapd/pull/8160 once the configcore stuff is a bit more settled (target is 2.45)
[15:00] <mup> PR #8160: overlord/configstate: add backlight option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8160>
[15:03] <pstolowski> pedronis: ack
[15:07] <pstolowski> mvo: yes, that fixes it!
[15:11] <ijohnson> ugh well I guess I have to live with 100% scaling on my high dpi monitors for a little while :-/
[15:17] <cachio> mvo, which is the lp for the upgrade error?
[15:18] <pstolowski> mvo: are you going to propose that fix?
[15:18] <ijohnson> cachio: it's https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1865063 and/or  https://bugs.launchpad.net/snapd/+bug/1868706
[15:18] <mup> Bug #1865063: snapd package hangs on deb postinst <focal> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1865063>
[15:18] <mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1868706>
[15:18] <cachio> ijohnson, thanks
[15:20] <pstolowski> mvo: nb, it's this bug https://bugs.launchpad.net/snapd/+bug/1864197
[15:20] <mup> Bug #1864197: errtracker unit tests interact with real whoopsie.service <snapd:Confirmed> <https://launchpad.net/bugs/1864197>
[15:23] <mborzecki> ijohnson: i use the 1.25 scaling factor in gnome tweaks in my 4k setup
[15:24] <mvo> pstolowski: thanks, will do a PR shortly
[15:24] <mborzecki> ijohnson: otherwise it's too small, and can't really use fractional scaling as that's wayland only and then sharing windows doesn't work :/ yay for linux desktop
[15:26]  * zyga breaks for lunch
[15:26] <mup> PR snapcraft#2994 opened: repo: move filtered package list from manifest.txt into a python list <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2994>
[15:29] <ijohnson> mborzecki: I use 150% normally with the experimental x11 fractional scaling which worked great for me up until an update this morning
[15:30] <mborzecki> ijohnson: heh, abandon all hope ;)
[15:30] <ijohnson> someone is helping me debug the issue in #ubuntu-desktop though, so probably can at least figure out what to revert for now :-)
[15:31] <mborzecki> ijohnson: hm you're using wyaland right?
[15:32] <ijohnson> mborzecki: no x11
[15:33] <mborzecki> ijohnson: hmmmm assumed that when you wrote x11 you actually meant wayland :) but that's interesting, do you know if it's part of upstream mutter on x11 or just patched in ubuntu?
[15:33] <mborzecki> i remember upstream was wayland only
[15:33] <ijohnson> I don't remember, but I've been using the experimental scaling since like 17.10 I think ?
[15:49] <mup> PR snapd#8347 opened: errtracker: add missing mocks <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8347>
[15:55] <ijohnson> pedronis: ok so I have the dirs refactored, one question though, should the callback take the new rootdir as an arg, I assume yes, but also I have a test to make sure it works to just reference a derived var (i.e. dirs.RunMnt) in the callback and that works too, since I think that will be the most common case
[15:56] <pedronis> ijohnson: yes, it should take the rootdir, that seems the natural thing
[15:56] <ijohnson> pedronis: ok sure
[15:56] <ijohnson> will push up changes shortly then
[15:57] <pedronis> ijohnson: but do we use RunMnt for anything that is not boot related?
[15:57] <pedronis> because otherwise it should move too
[15:57] <ijohnson> oh did you want me to remove RunMnt too
[15:58] <ijohnson> sorry I missed that, I just renamed it to RunMntDir
[15:58] <ijohnson> let me look and see where all we use it
[15:58] <pedronis> ijohnson: sorry, but we it's only use cases, yes I would move it until we have a reason to do otherwise
[15:58] <pedronis> *if boot is the only use case
[15:59] <ijohnson> so RunMnt is used in devicestate for cloud-init config dirs during install mode, as well as snap-bootstrap and boot
[16:00] <ijohnson> but in devicestate we could refactor to use boot.EarlyUbuntuSeed instead
[16:00] <ijohnson> so yeah I think we could safely move RunMnt to boot as well
[16:01] <pedronis> ijohnson: it's used to make one of those dirs
[16:01] <pedronis> I think
[16:01] <pedronis> yes
[16:02] <ijohnson> right devicestate does `cloudCfg := filepath.Join(dirs.RunMnt, "ubuntu-seed/data/etc/cloud/cloud.cfg.d")` but it could just as easily do:
[16:02] <ijohnson> `cloudCfg := filepath.Join(boot.EarlyUbuntuSeed, "data/etc/cloud/cloud.cfg.d")`
[16:02] <pedronis> yes
[16:03] <ijohnson> ack ok I will work a bit more to untangle these then
[16:09] <pedronis> ijohnson: did you fix sysconfig , just checking ?
[16:10] <ijohnson> pedronis: yes like this https://pastebin.ubuntu.com/p/V6cqksVFm5/
[16:10] <ijohnson> well, am fixing need to fix some unit tests too
[16:10] <pedronis> ijohnson: ok
[16:11] <pedronis> anyway I'll be around hacking a bit and doing review for a while today
[16:11] <pedronis> but off tomorrow
[16:11] <ijohnson> okay sure I am trying to wrap up the dirs thing ASAP for you to look at
[16:15] <mborzecki> mvo: conflicts in https://github.com/snapcore/snapd/pull/8010
[16:15] <mup> PR #8010: snap-bootstrap: add support for "recover" mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8010>
[16:19] <ijohnson> pedronis: should we have a helper var in boot for `filepath.Join(boot.EarlyUbuntuData,"system-data")` ?
[16:19] <ijohnson> I'm having to write that a lot in fixing things to not use dirs.RunMnt
[16:22] <pedronis> ijohnson: yes, if we find a good name for it, maybe mvo as a suggestions, that's basically writable inside data ?
[16:24] <ijohnson> to pedronis what about `EarlyWritableDir` ?
[16:24] <pedronis> sounds okish
[16:25] <ijohnson> alright I'll go with that for the PR, if anybody thinks of something different it's easy to rename later
[16:32]  * mvo is not good with names
[16:33] <pedronis> zyga: mvo: can we reach some conclusion here: https://github.com/snapcore/snapd/pull/8346  , I'm getting an email about each of my PRs saying it failed
[16:33] <mup> PR #8346: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8346>
[16:33] <mvo> pedronis, zyga we should do one that just adds "apt update"
[16:33] <mvo> zyga, pedronis this will make the failure go away
[16:34] <zyga> mvo: let me do that quickly
[16:34] <mvo> ta
[16:36] <clmsy> hi everyone
[16:36] <clmsy> i am in need of a bit help
[16:36] <clmsy> i am building an image that contains some snaps (with the ubuntu-image tool)
[16:36] <clmsy> this image is going to be an image to flash other images to devices
[16:36] <clmsy> thus i want to include godd with it
[16:36] <clmsy> and i can do this by
[16:36] <clmsy> --snap godd=beta
[16:37] <zyga> https://github.com/snapcore/snapd/pull/8348/files
[16:37] <mup> PR #8348: github: apt-get update before installing build-deps <Skip spread> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8348>
[16:37] <clmsy> giving this arg to ubuntuimage tool
[16:37] <mup> PR snapd#8348 opened: github: apt-get update before installing build-deps <Skip spread> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8348>
[16:37] <clmsy> but this doesnt work for me because it somehow ends up in strict confinement
[16:37] <zyga> mvo: I love how those tests just start *instantly*
[16:37] <zyga> I feel so discouraged by travis sometimes
[16:38] <clmsy> the tool says i can describe risk with the decleration ( ubuntu-image snap --help)
[16:38] <clmsy> it says i need to do this [16:38] <clmsy>  
[16:38] <clmsy> so i tried a lot of things
[16:38] <clmsy> --snap godd=beta/devmode
[16:38] <zyga> mvo: it passed the github action, please merge it
[16:38] <clmsy> --snap godd=beta|devmode
[16:39] <clmsy> non of it works
[16:39] <zyga> clmsy: risk level is not devmode
[16:39] <zyga> clmsy: you are asking to install a snap in devmode
[16:39] <mvo> clmsy: it sounds like godd should get an update, i.e. to non-devmode and using the home and block-devices interfaces or something like this
[16:39] <clmsy> yeah so the image is in /writable/system-data/snap/blahblah
[16:39] <clmsy> godd cannot see this path
[16:39] <clmsy> :(
[16:40] <clmsy> i was trying to give it global access
[16:40] <clmsy> so when i do sudo godd if=/writable/blahblah it can access it
[16:40] <zyga> hmm
[16:40] <zyga> so you put some extra files in /writable?
[16:41] <clmsy> yes basically i am baking an image that has an image already included in it
[16:41] <clmsy> this image will be used to flash the inside image to devices permanently
[16:41] <clmsy> there is an .img file there under writable
[16:41] <clmsy> i need to make godd access it
[16:41] <clmsy> but audit logs show that its kinda restricted
[16:42] <clmsy> i thought i can just do --snap godd=beta/devmode
[16:42] <zyga> I understand
[16:42] <zyga> nope, IIRC there's no switch for that
[16:43] <mvo> clmsy: would using good old "dd" as a workaround work for you?
[16:43] <clmsy> ill try that i guess
[16:49] <mup> PR snapd#8348 closed: github: apt-get update before installing build-deps <Skip spread> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8348>
[16:52] <zyga> pedronis: it should be better now
[16:58] <mup> PR snapd#8349 opened: tests: cleanup security-private-tmp properly <Simple 😃> <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8349>
[17:02] <ijohnson> pedronis: #8339 is updated now, it grew quite a bit though
[17:02] <mup> PR #8339: dirs: rm RunMnt; boot: add vars for early boot env layout <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8339>
[17:02] <ijohnson> should be pretty simple to review though
[17:02] <pedronis> thx
[17:09] <ijohnson> hey folks, my travis <-> github link isn't working, so I can't restart jobs, can someone restart https://travis-ci.org/github/snapcore/snapd/builds/666710776?utm_source=github_status&utm_medium=notification for me? debian-sid just failed because a network error
[17:10] <mup> PR snapd#8346 closed: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8346>
[17:14] <mup> PR snapd#8350 opened: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[17:24] <mvo> pedronis: is 8010 something you want to review too or are the existing +2 it has enough? it has a conflcit right now so I need to do some work on it anyway first :)
[17:25] <ijohnson> mvo: note that 8010 will conflict with 8339, just fyi. I'm happy to fix my branch if that one lands first
[17:26] <pedronis> mvo: sorry, I need to talk what is 8010
[17:26] <pedronis> s/talk/look/
[17:27] <pedronis> mvo: it needs my +1, you need to answer my question in the check-list actually :)
[17:29] <mvo> pedronis: uh, I missed this question, trying to find it now
[17:29] <pedronis> mvo: maybe my reasoning in the check-list is off, but we need to agree what are the constraints on recover
[17:29] <mvo> pedronis: looking now, sorry
[17:30] <mvo> ijohnson: thanks, yeah, it sounds like someone needs to do some more conflict resolving :)
[17:30] <pedronis> ijohnson: at this point 8010 needs probably to wait next early next week
[17:31] <ijohnson> pedronis: ack, mvo if you're okay with it I can re-de-conflict 8010 when my PR lands to make it use the new shiny things, it should be easy
[17:31] <mvo> pedronis: replied
[17:31] <mvo> ijohnson: sure, works for me
[17:34] <pedronis> mvo: I suppose that the sealing will put a lock on things so maybe we are safe anyway
[17:34] <pedronis> we will not enable it until we add the right command line to the policies
[17:34] <mvo> pedronis: aha, good idea
[17:34] <pedronis> but we need to be careful
[17:34] <mvo> pedronis: really nice idea :)
[17:34] <mvo> +1 for careful
[17:43] <pedronis> ijohnson: I did a pass on #8339,  my biggest (naming) wondering there is this: https://github.com/snapcore/snapd/pull/8339#discussion_r398043578
[17:44] <mup> PR #8339: dirs: rm RunMnt; boot: add vars for early boot env layout; sysconfig: take targetdir arg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8339>
[17:44] <ijohnson> hmm yes I did forget to add a Dir suffix on all of those
[17:45] <ijohnson> I'm not sure how else to rename the vars to make it clear they are meant to be used in early boot, I guess we could say something like InitramfsRunMnt maybe ?
[17:45] <ijohnson> err InitramfsRunMntDir
[17:45] <ijohnson> pedronis: ^
[17:45] <mup> PR snapd#8351 opened: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
[17:45] <pedronis> yes, it's boring and long, but maybe it's what we need
[17:47] <mvo> :like: fwiw - even though it's long
[17:48] <ijohnson> ok I will rename to InitramfsRunMntDir
[17:48] <pedronis> s/Early/Initramfs/ basically
[17:48] <pedronis> to be clear
[17:48] <pedronis> not just the first one
[17:48] <ijohnson> yes
[17:49] <pedronis> the rest of comments should be more directly applicable
[17:49] <ijohnson> pedronis: but I should add a Dir suffix to all of them, correct ?
[17:49] <pedronis> yes
[17:49] <ijohnson> so we have InitramfsUbuntuSeedDir for example
[17:50] <pedronis> it's consistent with what dirs itself does
[17:50] <ijohnson> yes good point
[17:54] <pedronis> zyga: should we land https://github.com/snapcore/snapd/pull/8265 ? and then replace it when we can?
[17:55] <mup> PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
[17:55] <zyga> pedronis: yeah, that sounds acceptable
[17:55] <zyga> pedronis: I can look quickly tomorrow morning at changing the test, the snap content is not that complex IIRC
[17:55] <zyga> just "curious"
[17:57] <mvo> grrr travis gree - 8347 is green since a while but travis did not report this back to GH
[17:57] <mup> PR snapd#8347 closed: errtracker: add missing mocks <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8347>
[18:02] <mup> PR snapd#8352 opened: wrappers: generate service files with EnsureDirState [WIP] <Created by zyga> <https://github.com/snapcore/snapd/pull/8352>
[18:05] <zyga> mvo: travis just loves us today
[18:06] <ijohnson> pedronis: ok renamed everything in 8339, do you need to re-review it or is it okay if I get 2 other +1s while you're off the rest of the week ?
[18:07]  * zyga EODs
[18:07] <zyga> pedronis: I cleared up the archive issue with IS
[18:07] <zyga> pedronis: apt-get update is correct, the archive just moved and the worker wakes up with older cache
[18:07] <pedronis> ijohnson: I need to go have dinner, but then I'll be around some more, I can try to give it a look
[18:07] <zyga> pedronis: so that's good, it's not (hopefully) unreliable
[18:07] <ijohnson> ok, thanks, I will break for lunch now too
[18:08] <pedronis> ijohnson: yes, I would close #8338 for now, I'm not completely against but also not super +1
[18:08] <mup> PR #8338: boot/bootstate20: rm bootState20Base.loadModeenv() <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8338>
[18:09] <mup> PR snapd#8338 closed: boot/bootstate20: rm bootState20Base.loadModeenv() <Simple 😃> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8338>
[18:10] <mup> PR snapd#8265 closed: tests: add regression test for MAAS refresh bug <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8265>
[18:10] <zyga> pedronis: I'd like to land https://github.com/snapcore/snapd/pull/8089
[18:10] <mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
[18:10] <zyga> given that 2.45 is open
[18:11] <zyga> pedronis: also, but this is potentially a longer read, https://github.com/snapcore/snapd/pull/8123 given that it's 2.45 and we landed the simple version for 2.44
[18:11] <mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
[18:11] <zyga> pedronis: but no rush on this one, not a priority
[18:47] <pedronis> zyga: yes, #8123 is on my queue
[18:47] <mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
[19:18] <pedronis> ijohnson|lunch: done, +1 with some final comments
[19:27] <pedronis> https://www.traviscistatus.com/
[19:29] <mvo> pedronis: fun
[19:29] <pedronis> not
[19:30] <mvo> :P
[19:30] <mvo> it seems like this whole GH actions comes at the right time
[19:33] <ijohnson> thanks pedronis
[20:14] <mup> PR snapd#8353 opened: interfaces/docker-support: make containerd abstract socket more generic <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8353>
[21:22]  * ijohnson EODs early