[00:11] PR snapd#8927 closed: tests: avoid exit 1 when nested type var is not defined === jamesh_ is now known as jamesh [01:36] PR snapd#8748 closed: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 [01:40] ijohnson: thanks! [01:40] jamesh: np [05:20] morning [06:06] Hey [06:07] I’ll start at nine [06:07] zyga: heya, last day of 'school' [06:07] Yes. Kids are very happy [06:07] Too bad the circumstances are not better [06:22] hey zyga and mborzecki [06:30] Hey [06:30] The [06:30] hey mvo, thx for the fontconfig and freetype fix ... do you have any hint on the easiest way to test the change? [06:30] Took meds now [06:30] Will be able to work in 30 [06:31] seb128: I can build a custom snapd snap for trying it out, will take some minutes [06:32] mvo, that would be nice if you could, I'm happy to give it a try today [06:35] seb128: sure, building now and once done will ping you [06:39] thx [07:05] morning [07:11] good morning pstolowski [07:14] pstolowski: heya [07:14] need coffee [07:25] * zyga starts with reviews [07:26] mborzecki: btw, for evening reading: https://lwn.net/Articles/824380/ [07:26] oh and https://github.com/snapcore/snapd/pull/8728 is a low hanging fruit [07:26] PR #8728: tests: detect stray dbus-daemon [07:26] zyga: oh, nice [07:28] PR snapd#8928 opened: tests: add spread test for disconnect undo caused by failing disconnect hook [07:28] zyga: ^ something easy for a warmup ;) [07:30] zyga: if you've got time, could you give this a review? https://github.com/snapcore/snapd/pull/8861 [07:30] PR #8861: data,packaging,wrappers: extend D-Bus service activation search path [07:31] jamesh: I'll do my best to help [07:31] zyga: thanks. You gave it a once over earlier, and now I just need a second sign off [07:34] jamesh: ah, I really like how github shows what I reviewed [07:34] and shows only changes [07:37] zyga: nb, snap remove --force needs ack from Samuele [07:37] sure [07:37] I was thinking if it makes sense to fail on interface hooks when removing a snap [07:41] zyga: indeed [08:09] seb128: sorry, took a while, had some unclean checkout and a bug in the cleanup: https://people.canonical.com/~mvo/tmp/snapd_2.45.1+git1648.gf492c71_amd64.snap is the test snaps [08:13] mborzecki: https://github.com/snapcore/snapd/pull/8925#pullrequestreview-438094666 [08:13] PR #8925: bootloader: allow managed bootloader to update its boot config [08:13] brb [08:19] zyga: thx [08:21] mvo: can you cherry pick https://github.com/snapcore/snapd/commit/3192141bc8481f58639e71a099b17a608366b7a0#diff-ccde24f4fb0b0adce138f9b26cea79ed to 2.45 in case we do another point release? [08:21] mborzecki: sure thing [08:22] mvo: thanks [08:22] mborzecki: thanks, done [08:22] yay [08:22] mborzecki: nice one! [08:29] mborzecki: what does NoSlashBoot do? [08:29] zyga: haha, so it means you're lookin at the root of the boot fs [08:29] hmm? [08:30] zyga: instead of the actual rootfs where you'd normally find /boot/.. [08:30] so /foo/bar/froz becomes just /? [08:30] iow no /boot [08:30] * zyga looks at the source [08:30] zyga: not necessarily, we ahve /boot/grub/.. which is a bind mount of /EFI/ubuntu from system-boot iirc [08:50] mvo, thx, I will give a try a bit later and let you know if it improves things [08:53] seb128: thanks [09:20] mborzecki: https://github.com/snapcore/snapd/pull/8924#pullrequestreview-438131587 [09:20] PR #8924: gadget, bootloader: preserve managed boot assets during gadget updates [09:32] more reviews [09:32] thank you for looking at the tracking PR [09:32] I will iterate on it soon [09:37] zyga: thanks for the reviews too [09:42] pstolowski: https://github.com/snapcore/snapd/pull/8923#pullrequestreview-438156283 [09:42] PR #8923: wrappers: helper for enabling services (8/9) [09:42] jdstrand: is https://github.com/snapcore/snapd/pull/8920 something that I should review now or is it better to wait for the final form? [09:42] PR #8920: interfaces: update cups-control and add cups for providing snaps <β›” Blocked> [09:43] jdstrand: also note that opening a draft vs a blocked PR is probably more idiomatic for GH [09:43] zyga: thanks! [09:48] PR snapd#8929 opened: [RFC] many: add new "daemon-startup: inhibit" option [09:53] mvo: ^ quick comment [09:58] zyga: thanks, interessting idea [09:58] mvo: it doesn't have to be complex [09:58] perhaps just [09:58] startup-presets: default: app-name: disabled [09:58] if you catch my "language" [09:58] default would be the only supported value now [09:59] presets are somewhat different, as they come from the distro [09:59] but we could convey the same idea [09:59] e.g. apache is not started automatically [09:59] but the server preset makes that so [09:59] while desktop does not [10:00] (just a made up example) [10:00] perhaps an app could even have a snapctl level influence over the preset to use [10:00] anyway, just an idea [10:00] https://www.freedesktop.org/software/systemd/man/systemd.preset.html has some docs about tihs [10:00] *this [10:02] #8928 needs 2nd review and is a low hanging 🍎 [10:02] PR #8928: tests: add spread test for disconnect undo caused by failing disconnect hook [10:03] pstolowski: I see what you did there :D [10:03] PR snapd#8930 opened: many: managed boot config during run mode setup [10:03] :) [10:05] zyga: yeah, the idea of having hooks that would enable/disable under certain conditions is part of the idea for this [10:07] ijohnson: https://github.com/snapcore/snapd/pull/8918#pullrequestreview-438161318 [10:07] PR #8918: many: make nested spread tests more reliable [10:08] review days are good [10:55] ok, only dbus to review [10:55] and then back to iteration [10:56] or maybe small lunch break and then iteratoin [10:56] *iteration [11:18] PR snapd#8931 opened: tests/main/install-fontconfig-cache-gen: enhance test by verifying, add fonts to test [11:30] jamesh: https://github.com/snapcore/snapd/pull/8861#pullrequestreview-438214407 [11:30] PR #8861: data,packaging,wrappers: extend D-Bus service activation search path [11:30] cc mvo ^ [11:30] not +1, not sure what to do about this [11:30] I think we need to revisit our reexecution strategy with regards to how it should be structured internally [11:30] what's okay and not and if we need any belts and suspenders to make it sane over time [11:33] 9% of battery, time for a trip downstairs for the charger [11:33] oh boy [11:39] zyga: probably best to wait for cups-control. I wasn't expected it to be blocked for so long but I got pulled away. if you're looking to review things, I suggest https://github.com/snapcore/snapd/pull/8699 and https://github.com/snapcore/snapd/pull/8301 [11:39] PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps [11:39] PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share [11:39] expecting* [11:39] jdstrand: ack, thanks! [11:39] but I am getting back to cups-control today (want to right a spread test) [11:39] I'll do both, just need to charge [11:40] thanks! [11:54] in the office [11:54] stairs feel wobbly [12:17] https://github.com/snapcore/snapd/pull/8728 needs a 2nd review\ [12:17] PR #8728: tests: detect stray dbus-daemon [12:25] * zyga takes a break to rest [12:44] PR snapd#8932 opened: Update security profiles after disconnecting plug-slot in connect und… [12:59] PR snapd#8933 opened: tests/core/uc20-recovery: apply hack to get gopath in recover mode w/ external backend [13:33] cachio: downloaded the image, trying now [13:34] mborzecki, tx [13:37] I will resume work in 30 minutes [13:38] the schedule for painkillers is somewhat annoying [13:38] btw, typing on the faceless keyboard is really much easier than I anticipated; I think the only thing I stil struggle with are arrow keys [13:41] cachio: in what scenarios does the test fail? [13:41] so [13:41] just need to run the test like this [13:42] first prepare ssh [13:42] ./tests/lib/external/prepare-ssh.sh localhost 8022 sergio-j-cazzolato [13:42] with your lp id [13:42] export SPREAD_EXTERNAL_ADDRESS=localhost:8022 [13:42] and run spread -debug external:ubuntu-core-20-64:tests/core/snap-set-core-config [13:43] mborzecki, to start the vm I do [13:43] sudo qemu-system-x86_64 -smp 2 -m 2048 -snapshot -net nic,model=virtio -net user,hostfwd=tcp::8022-:22 -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=~/workspace/validator/images/output/pc-amd64-20-edge/pc.img,cache=none,format=raw,id=disk1,if=none -device virtio-blk-pci,drive=disk1,bootindex=1 -machine accel=kvm [13:43] cachio: hmm, i've built a pc20 image and the test would fail there too from what i can see [13:43] wonder why it does not fail when we run it on gce [13:43] mborzecki, that's my concern [13:44] not sure where the difference is [13:44] PR snapd#8728 closed: tests: detect stray dbus-daemon [13:44] I didn't see any special config for console conf in the code [13:45] cachio: what's the test that doesn't work ? [13:45] sorry I had to drop from SU before you could share details [13:45] ijohnson, snap-set-core-config [13:45] I'm all setup to run external spread tests easily now though :-) [13:45] cachio: ack I will give it a try right now [13:45] cachio: same pc.img.xz as yesterday ? [13:46] yes [13:52] cachio: much like the other test, if this is being run with an external backend, it functions differently [13:53] cachio: the issue is that this test tries to re-enable console-conf after disabling it, but that only works if console-conf was never run manually by the user [13:53] heh, 2nd thunderstorm today [13:53] cachio: in our case, we manually run console-conf in order to be able to create the test / ubuntu users [13:54] hah [13:54] cachio: which means that snapd does the right thing and when we unset the system config, snapd doesn't undo console-conf disabling itself [13:54] cachio: the test needs to be adjust to special case external backend, I will prep a PR for oyu [13:55] ijohnson: thanks for investigating! [13:59] ijohnson, thanks [14:00] ijohnson, everything is realted to all the magic we did to prepare snapd to be executed on google [14:04] PR snapd#8934 opened: overlord: mock timings.DurationThreshold in TestNewWithGoodState [14:20] * zyga finally had lunch and meds and can get back to work :) [14:57] cachio: yes essentially all these bugs are related to the magic we do for snapd + UC on google [15:03] ijohnson: o/ [15:04] hey zyga [15:04] ah, you're around - great [15:04] I'll push tweaks to comments in 8829 in a moment, wanted to ask if you could look at my explanations there [15:04] I'll let you know when they are up [15:05] zyga: yes I'll take a look just let me know when they're up [15:05] thank you [15:11] * cachio lunch [15:23] ijohnson: pushed https://github.com/snapcore/snapd/pull/8829 [15:23] PR #8829: sandbox/cgroup: add tracking helpers [15:23] it's broken down in commits so you can see it more easily [15:23] https://github.com/snapcore/snapd/pull/8829/commits/6430d396deb9ad5daaced3b119b9bb1d64b413a9 [15:23] https://github.com/snapcore/snapd/pull/8829/commits/d20c0bfb6d48ce1cd650229c8d8b718ae9fe8640 [15:23] https://github.com/snapcore/snapd/pull/8829/commits/89d8a1a34426dfc94adc33147c186a2a9caa5f0a [15:23] https://github.com/snapcore/snapd/pull/8829/commits/105748396066ddd45c455b177f6accad5e670871 [15:24] that's all [15:24] if you have cycles today I'd love a review of the counterpart https://github.com/snapcore/snapd/pull/8863 [15:24] PR #8863: sandbox/cgroup: allow discovering PIDs of given snap [15:26] zyga: thanks, one small comment then LGTM [15:26] zyga: I'll take a look at the other one today too [15:45] xnox: what is the canonical way to know if console-conf ran? I thought it was the presence of the /var/lib/console-conf/complete file, but it doesn't appear that file is ever written by console-conf itself ? that file simply seems to be used to _disable_ console-conf, not to tell whether console-conf ran or not [15:52] ijohnson: applied now [15:53] ijohnson: pass. I am not sure if it is possible to tell if it ran, or did anything, or if it's state was cleared, or like who/what created the managed user.... [15:53] xnox: I'm wondering about for our tests in snapd about disable console-conf [15:54] xnox: we can hack some things into place, but our test was checking for that file, but it seems that file is not actually created when we expected it to be [15:54] ijohnson: hey, would you take a look at #8928? it's test only PR [15:54] PR #8928: tests: add spread test for disconnect undo caused by failing disconnect hook [15:54] xnox: if there's not an "official way" that's fine I can replace it with a working hack to see that the test is checking the right thing [15:54] pstolowski: sure, will be my afternoon though at this point [15:55] thanks! [15:56] ijohnson: maybe something is buggy? It should be leaving that stamp file at the end... When ran successfully. At least that's what I thought. [15:56] seb128: did my updated snapd snap help with the fc-cache issue? no rush, just curious if I can update anything in the PR [15:56] xnox: it doesn't leave a stamp file on uc20 or uc18 afaict [15:56] xnox: shall I file a bug ? [15:57] zyga: thanks for adding that Error(), I'll keep an eye on the PR and merge it for you tonight [15:58] mvo, ah, sorry, I meant to comment, I just tested half an hour ago, I wiped the cache, installed your snap and the font was correctly listed in the newly generated cache, so seems to work from that testing [15:58] thanks [15:58] seb128: \o/ yay [15:58] once it lands I need to merge it back into to big helper [15:58] mvo, thanks for the quick fix :) [15:58] seb128: my pleasure, thanks for all your help with this! (and to jamesh) [16:01] mvo: regarding that bug, how will the spread tests get the fix for that? do we build the fc-cache helpers in the snapd deb the way we do for the snapd snap? just wondering how we could properly fix my spread test showing that it works [16:01] mvo, I've added a comment on the bug and the pr now [16:02] cachio: do you have time today to verify #8933 ? [16:02] PR #8933: tests/core/uc20-recovery: apply hack to get gopath in recover mode w/ external backend [16:03] ijohnson: I think we just merge the fix into edge, rebuild the snap and then re-run your test (that now no longer needed to rebuild the snapd snap). it's not as nice as you test but we can always revert again if needed [16:03] ijohnson: sorry, it's very low-tech, a real friday evening suggestion :) [16:03] mvo: so the test will use the snapd snap ? [16:03] mvo: that's fine, just wondering since it's a little annoying in the test to have to revert from the snapd snap to the deb, certainly doable though I think [16:03] ijohnson: yeah, once fc-cache-builder is in git and the snapd snap is rebuild we should have the right version [16:04] mvo: ah actually all the font tests are run on classic, so it's not a problem, the magic spread restore should take care of it [16:04] nvm me, thanks mvo [16:04] ijohnson: aha, ok [16:04] ijohnson: sorry, I think I was not even grasping the depth of the question :) [16:04] ijohnson: but happy to help! [16:04] mvo: haha no worries it's probably EOW time for you anyways :-) [16:05] ijohnson: it is - plus it's hot here :) [16:05] yah I hear that [16:05] * mvo is good at making excuses [16:05] * mvo will just write one or two more mails and then call it a day [16:10] xnox: seems that /run/console-conf/login-details* is the best indicator if console-conf ran successfully / normally on the system [16:13] ijohnson: but that could also be generated if the system got provisioned elsehow too I think [16:13] xnox: I don't see it, I tried both with cloud-init and with system user assertions and don't see that dir [16:13] Interesting. [16:13] xnox: maybe I checked in bad ways [16:13] And after reboot it's still there? [16:13] xnox: but I can make my test pass now, so that's all that's important :-) [16:13] xnox: afaict yes [16:14] Cool. Roll with it. [16:14] Next time I touch consoleconf I will try to understand how it works. [16:14] haha sounds good === benfrancis1 is now known as benfrancis [16:45] ijohnson, sure [17:50] ijohnson, https://paste.ubuntu.com/p/RvVKN4978X/ [17:51] https://paste.ubuntu.com/p/JfCz4D3Rfz/ [17:51] cachio: very interesting, was this when the system was in recover mode or run mode ? [17:51] https://paste.ubuntu.com/p/hsNtwZNYsw/ [17:51] no space error [17:51] cachio: ah I see that is in recover mode === benfrancis0 is now known as benfrancis === benfrancis4 is now known as benfrancis [18:16] cachio: also re: the snap-set-core-config, the test exposed a real bug, so I will need to fix that bug before we can fix the test [18:33] ijohnson, hehe [18:34] good news in that case [18:34] cachio: yeah :-) [18:34] cachio: also for your uc20-recovery is that snapd panic reproducible for you ? [18:34] or did it just happen once, as I don't see that with my VM [18:36] yes [18:36] the once I sent before? [18:36] cachio: the one from https://paste.ubuntu.com/p/hsNtwZNYsw/ [18:37] cachio: what arguments are you running the external VM with ? [18:37] yes [18:37] I have a debug session opened [18:37] cachio: I use this: [18:37] https://www.irccloud.com/pastebin/DDPDyNii/ [18:38] maybe I need to provide less RAM to the VM [18:38] ijohnson, I use https://paste.ubuntu.com/p/mCyynrpCpQ/ [18:38] 2048 [18:38] big diff [18:39] cachio: ack I'll try with 2048 to see if I can reproduce it [18:39] cause yeah we might have run out of space, but we shouldn't panic in that case I'm pretty sure [18:39] I'll try with 3gb [18:40] PR snapd#8829 closed: sandbox/cgroup: add tracking helpers [19:25] ijohnson, with 3GB didn't work [19:25] trying with 4GB now [19:25] got stuck after reboot [19:28] cachio: you mean with 3 GB it didn't panic but it did get stuck after reboot? [19:28] dont know because after 20 minutes I killed spread [19:28] https://paste.ubuntu.com/p/JC4kDVGCWV/ [19:29] ijohnson, this is the output [19:32] ah cachio that seems to be the bug that I thought I fixed by deleting the ~/.ssh/rc file [19:32] cachio: interesting, I need to step out for a while now, but I will try again to see if I can reproduce that issue [19:32] * ijohnson -> afk for bit [19:34] ijohnson, np, see you then [19:38] ijohnson, with 4GB workerd well [19:39] ijohnson, https://paste.ubuntu.com/p/PDt2jk3W2f/ [19:53] the problem is that in the lab devices we don't have 4gb [19:59] PR snapcraft#3190 opened: extensions: export content snap egl vendor dir [20:01] cachio: yes I will see what to do about using 2G, also won't this test be run on devices like rpi that might only have 1G of RAM? [20:25] ijohnson, yes [20:25] it runs in pi3 with 1 or 2 gb [20:26] and pi4 with 4/8gb [20:26] which is fine [21:09] PR snapcraft#3174 closed: link_or_copy: do not try to create hardlinks to symlinks [21:09] PR snapcraft#3190 closed: extensions: export content snap egl vendor dir [22:04] PR snapcraft#3191 opened: plugins: introduce v1.FlutterPlugin