[06:35] o/ [06:39] day of apple updates [06:40] everything has an update today [06:44] morning [06:59] mvo: mroning [07:00] mvo: could you take a look at https://github.com/snapcore/snapd/pull/8289 ? [07:00] PR #8289: xdgopenproxy: forward requests to the desktop portal [07:01] mborzecki: good morning [07:02] mborzecki: sure [07:39] good morning guys [07:39] I need to help with breakfast [07:41] thank you for reviewing the actions PR [07:41] I'll be around soon [07:55] zyga: good morning [07:56] 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] 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] mvo: or just a snap with desktop plug, run xdg-open [07:58] or [07:59] mborzecki: ok [08:05] morning [08:06] hey pstolowski [08:07] pstolowski: pedronis: hey [08:07] hm soemthing broken with travis <-> gh [08:08] re [08:08] 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] PR #8333: wrappers: fix timer schedules that are days only [08:08] mvo: can you please land https://github.com/snapcore/snapd/pull/8331 [08:08] PR #8331: github: run spread via github actions [08:08] there's a 2nd run of travis pending there [08:08] and it's just a waste of time to wait [08:09] zyga: if we land it as is, don't we generate twice the GCE cost? [08:09] mvo: hmm hmm [08:09] indeed [08:09] what do you suppose we should do [08:10] zyga: if we switch to GH action we should disable travis integration tests [08:10] mvo: how do we do that? [08:10] just edit the yaml? [08:11] zyga: yeah, i think so [08:11] ok, let me [08:12] mvo: I can move the macos build over as well [08:13] zyga: I think that makes sense, can GH actions do that? [08:13] yes [08:13] zyga: if we don't disable this we still have to wait for travis [08:14] mvo: libzt has tests for windows, macos and linux this way [08:14] zyga: we also need to make sure we don't regress [08:14] mvo: little by litte, let me move travis spread over first [08:14] yeh [08:14] I won't do it in one big change [08:14] zyga: in the sense that the static tests need to run shellcheck and all that [08:14] zyga: sure [08:14] yeah [08:14] zyga: just stating the obvious I guess :) [08:14] being careful is good :) [08:15] but I'm happy that this will save the team a *lot* of time [08:16] mborzecki: I'm going to pick #8336, if I understand correctly you reviewed the one after, and are mostly happy with it? [08:16] PR #8336: boot,many: add modeenv.WriteTo, make Write take no args [08:17] mvo: pushed https://github.com/snapcore/snapd/pull/8331 [08:17] PR #8331: github: run spread via github actions [08:17] just watch how they run [08:18] 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] ijohnson: good morning? ! [08:18] hey zyga [08:18] how are you up at this time? [08:19] ijohnson: well, I didn't expect you to be up at this time [08:19] eh it's not a big deal, didn't get much done last night so making up the time now [08:20] 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] s/work continue/continue work/ [08:21] could someone please tell me how google-tpm backends used? [08:22] do we only run them manually? [08:27] pedronis: yeah, i think it looks ok, devicemgr seems to be the only place where we may need add a consistency check [08:44] mborzecki: I'm just going reread it, as I said I want to remove it [08:44] in the next one [08:44] ok [08:58] mborzecki: ijohnson: pushed, please take a look [09:12] #8335 needs a second review if anyone has a moment, and it will help with one of my PRs [09:12] PR #8335: many: introduce naming.WellKnownSnapID [09:16] I'm seeing failures on core16 reboot test [09:16] kill timeout reached [09:17] is anyone else seeing this? [09:18] mborzecki: #8333 can land? [09:18] PR #8333: wrappers: fix timer schedules that are days only [09:19] pstolowski: it's finally green? [09:19] yes [09:19] squash merged it [09:20] mborzecki: \o/ will cherry-pick (in a meeting right now) [09:20] PR snapd#8333 closed: wrappers: fix timer schedules that are days only [09:20] mvo: ^^ [09:22] mborzecki: done [09:22] mvo: thank you! [09:22] mborzecki: thank *you* :) [09:23] * mborzecki is just fixing the bugs he introduced ;) [09:45] yes #8335 needs a 2nd review [09:45] PR #8335: many: introduce naming.WellKnownSnapID [09:45] mborzecki: ijohnson: thanks for looking 8336, will work on a follow up to remove DeviceManager.modeEnv [09:53] hi, I've got a snap that is complaining about $XDG_RUNTIME_DIR not existing [09:53] that is true, but I'm wondering what I'm supposed to do about it; shouldn't snapd be creating this? [09:54] Laney: do you have some more details, is is a strict orclassic snap? [09:54] hey zyga [09:54] Laney: how are you running it (ssh/desktop/etc) [09:54] hey :) [09:54] 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] 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] as the 'ubuntu' user [09:56] ok [09:56] how did you do that? [09:56] run the binary? [09:56] specifically the last past [09:56] *part [09:56] I just ran the thing that is in $PATH [09:56] as the ubuntu user [09:56] appstream-generator [09:56] lxc shell drops you as a root into the container [09:56] what did you do next? [09:56] sudo -u ubuntu -i [09:57] ok [09:57] ah ok, are you saying that I didn't get a full PAM sessino and the snap requires that? [09:57] did that define $XDG_RUNTIME_DIR? [09:57] I suspect that's the case [09:57] it's a mess/zoo, depending on how one looks [09:57] well no, but snapd sets it anyway ;-) [09:58] yes but we assume it was there to begin with since we use a subdirectory [09:58] Laney: can you try with runuser -l ubuntu please [09:58] or runuser -l - ubuntu [09:58] it's gimmicky [09:59] 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] that would be my guess [09:59] jamesh: yeah, I'm sure it's that [09:59] correct [09:59] I guess we could be smarter [09:59] so I've been given an invalid value there [09:59] there is a workaround in snapcraft-desktop-helpers to try and create it [09:59] by not setting it [09:59] if it's unset [09:59] it's not like we're pam [09:59] we don't want to be [10:00] we're in self-isolation mode [10:01] snap-confine used to create it, but the setup_user_xdg_runtime_dir call is commented out for some reason [10:01] jamesh: it's been dead for years [10:01] yep [10:01] jamesh: I think we cannot really create it because it's a part of a bigger setup process [10:01] I would prefer to understand why we're not getting one [10:01] and been tripping people up for years [10:04] PR snapd#8336 closed: boot,many: add modeenv.WriteTo, make Write take no args [10:05] got a call, hang on, I'll be back with you in a little minute [10:05] 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] 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] Laney: hmmm [10:11] Laney: no, that's a known bug :)" [10:12] but usually apps kind of handle that (sometimes0 [10:12] that bug we should fix [10:12] it was in the dark days of how do we fix this [10:12] and endless discussions on how to proceed [10:12] mvo: offtopic, unstable workers actually pass [10:12] heh [10:12] ok [10:13] zyga: haha [10:13] zyga: nice [10:17] can you merge 8331 [10:17] I think waiting for travis there is not useful [10:17] especially that reboot test seems to be failing [10:17] Laney: not to leave you hanging, I think this is our bug [10:22] PR snapd#8331 closed: github: run spread via github actions [10:28] zyga: ok, thanks, that part is at least not too hard to deal with though [10:29] PR snapd#8338 opened: boot/bootstate20: rm bootState20Base.loadModeenv() [10:30] PR snapd#8339 opened: dirs,many: add EarlyBootUbuntu{Data,Boot,Seed} [10:34] PR snapd#8340 opened: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg [10:34] 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] PR snapd#8326 closed: [wip] boot: move initramfs-mounts logic to boot pkg [10:38] PR snapd#8019 closed: [RFC] interfaces/apparmor: don't emit deny rules in devmode confinement [10:43] brb [11:19] PR snapd#8341 opened: github: don't fail-fast [11:24] re [11:37] Issue core20#27 closed: iptables is missing [11:37] PR core20#28 closed: Add iptables package [11:49] PR snapd#8342 opened: client, daemon, overlord/devicestate: request system action API and stubs [11:49] pedronis: ^^ [11:58] uh [11:59] getting a qemu image on focal run into this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951766 [12:03] PR snapd#8343 opened: config, features: move and rename config.GetFeatureFlag helper to features.Flag [12:06] ijohnson: mborzecki: https://github.com/snapcore/snapd/pull/8344 [12:06] PR #8344: overlord/devicestate,boot: do not hold to the originally read modeenv [12:06] PR snapd#8344 opened: overlord/devicestate,boot: do not hold to the originally read modeenv [12:09] #8309 needs a 2nd review [12:09] PR #8309: o/configcore: FilesystemOnlyApply method for early configuration of core (1/N) === facundo__ is now known as facubatista [12:16] brb [12:28] PR snapd#8341 closed: github: don't fail-fast [12:28] ta [12:28] 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] PR snapcraft#2972 closed: catkin plugins: remove bash workaround for catkin cmake args [12:37] mborzecki: some initial quick comments on #8342 [12:37] PR #8342: client, daemon, overlord/devicestate: request system action API and stubs [12:39] pedronis: thanks, let me see [12:41] pedronis: hm sytem label isn't part of SystemAction but we could use /v2/systems/{label}, wdyt? [12:42] mborzecki: ah, sorry [12:43] mborzecki: yes, that would be fine. you can do snap install foo with /snaps/foo action=install [12:44] cool [12:44] mborzecki: so DoSystemAction(sysLabel, sysAction) ? [12:45] pedronis: yes, and {"action":"do", "mode": ""} POST'ed to /v2/systems/{label} [12:46] pedronis: we can probably skip the "title" bit which is part of SystemAction in the request [12:46] mborzecki: I think is much easier to give back what we received [12:47] we just can make some bits optional [12:47] but I doube we just simply pass mode along forever [12:47] *doubt [12:49] ok [12:52] pedronis: yes, i'm having a quick lunch atm, will be available in ~20 minutes [13:10] pstolowski: ok, ping me [13:14] * zyga is happy to see green spread on unstable systems so often [13:14] pedronis: i'm ready [13:14] pstolowski: going to the standup [13:25] I think I know why session-tool _sometimes_ fails its spread test [13:56] PR snapd#8345 opened: boot/overlord: rename operating mode to system mode [13:58] zyga: got some apt failure there ^ with gh actions [13:58] do I need to merge master? [13:58] ijohnson saw this once as well [13:58] let me look [13:58] hmm [13:58] no, no need [13:59] I have an idea how to avoid this entirely [13:59] oh, standup [13:59] pedronis: I'll send a patch after the call [14:10] PR snapd#8346 opened: github: try caching apt archive [14:14] pedronis: fixed [14:14] I added apt-get update [14:14] and added caching so we should only fetch it once for now [14:14] until debian/control changes [14:49] pstolowski: please try https://paste.ubuntu.com/p/73PbWvsTfy/ [14:49] pstolowski: looks like a very silly bug if it's that [14:50] PR snapcraft#2993 opened: repo: remove dead code from deb implementation [14:55] so azure.archive.ubuntu.com is still out of sync now? [15:00] 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] PR #8160: overlord/configstate: add backlight option [15:03] pedronis: ack [15:07] mvo: yes, that fixes it! [15:11] ugh well I guess I have to live with 100% scaling on my high dpi monitors for a little while :-/ [15:17] mvo, which is the lp for the upgrade error? [15:18] mvo: are you going to propose that fix? [15:18] cachio: it's https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1865063 and/or https://bugs.launchpad.net/snapd/+bug/1868706 [15:18] Bug #1865063: snapd package hangs on deb postinst [15:18] Bug #1868706: Snapd postinst script hangs [15:18] ijohnson, thanks [15:20] mvo: nb, it's this bug https://bugs.launchpad.net/snapd/+bug/1864197 [15:20] Bug #1864197: errtracker unit tests interact with real whoopsie.service [15:23] ijohnson: i use the 1.25 scaling factor in gnome tweaks in my 4k setup [15:24] pstolowski: thanks, will do a PR shortly [15:24] 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] PR snapcraft#2994 opened: repo: move filtered package list from manifest.txt into a python list [15:29] mborzecki: I use 150% normally with the experimental x11 fractional scaling which worked great for me up until an update this morning [15:30] ijohnson: heh, abandon all hope ;) [15:30] 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] ijohnson: hm you're using wyaland right? [15:32] mborzecki: no x11 [15:33] 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] i remember upstream was wayland only [15:33] I don't remember, but I've been using the experimental scaling since like 17.10 I think ? [15:49] PR snapd#8347 opened: errtracker: add missing mocks [15:55] 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] ijohnson: yes, it should take the rootdir, that seems the natural thing [15:56] pedronis: ok sure [15:56] will push up changes shortly then [15:57] ijohnson: but do we use RunMnt for anything that is not boot related? [15:57] because otherwise it should move too [15:57] oh did you want me to remove RunMnt too [15:58] sorry I missed that, I just renamed it to RunMntDir [15:58] let me look and see where all we use it [15:58] ijohnson: sorry, but we it's only use cases, yes I would move it until we have a reason to do otherwise [15:58] *if boot is the only use case [15:59] so RunMnt is used in devicestate for cloud-init config dirs during install mode, as well as snap-bootstrap and boot [16:00] but in devicestate we could refactor to use boot.EarlyUbuntuSeed instead [16:00] so yeah I think we could safely move RunMnt to boot as well [16:01] ijohnson: it's used to make one of those dirs [16:01] I think [16:01] yes [16:02] 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] `cloudCfg := filepath.Join(boot.EarlyUbuntuSeed, "data/etc/cloud/cloud.cfg.d")` [16:02] yes [16:03] ack ok I will work a bit more to untangle these then [16:09] ijohnson: did you fix sysconfig , just checking ? [16:10] pedronis: yes like this https://pastebin.ubuntu.com/p/V6cqksVFm5/ [16:10] well, am fixing need to fix some unit tests too [16:10] ijohnson: ok [16:11] anyway I'll be around hacking a bit and doing review for a while today [16:11] but off tomorrow [16:11] okay sure I am trying to wrap up the dirs thing ASAP for you to look at [16:15] mvo: conflicts in https://github.com/snapcore/snapd/pull/8010 [16:15] PR #8010: snap-bootstrap: add support for "recover" mode [16:19] pedronis: should we have a helper var in boot for `filepath.Join(boot.EarlyUbuntuData,"system-data")` ? [16:19] I'm having to write that a lot in fixing things to not use dirs.RunMnt [16:22] ijohnson: yes, if we find a good name for it, maybe mvo as a suggestions, that's basically writable inside data ? [16:24] to pedronis what about `EarlyWritableDir` ? [16:24] sounds okish [16:25] 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] 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]