[05:04] PR snapd#9209 opened: Correctly parse Content-Type HTTP header [07:02] morning [07:04] hey pstolowski [07:28] good morning [07:29] maciek's question from last evening made me realize why things are broken [07:29] good morning zyga [07:32] I think the 11AM thing will be necessary, today kids were very time consuming [07:32] and grandparents had to leave early in the morning so it was all on my head [07:32] anyway, maciek asked why are we hitting session bus for hooks and he is right, we should not [07:33] hah, there's even a TODO that says exactly what maciej suggested in the code [07:33] so that's easy [07:47] pstolowski what are you using for IRC? [07:48] zyga: textual7 [07:48] same [07:48] I stand up and make tea and my mbp suspends :) [07:48] I miss an always-on imac [07:48] well, imac also suspends [07:48] so it's just an illusion [07:48] macos suspends so aggressively [07:53] zyga: hmm, doesn't happen here, but i'm plugged most of the time [07:53] pstolowski I'm on defaults and suspend time is ... [07:54] 2 minutes [07:54] yeah on a cable its' 10 [07:55] zyga: ah, ok, i bumped them a bit and already forgot [08:45] PR snapd#9210 opened: [RFC] daemon: add /v2/systems "reboot" action API [08:46] testing the change now [08:50] * zyga makes coffee while tests run [08:50] I think my PT is starting to work [08:56] pedronis: would be great if you could double check https://github.com/snapcore/snapd/pull/9158/commits/a0786608b312063025ff713b2a896cecf6a1df43 - had to do a small extra change to this PR because of a bug in go 1.9 :/ [08:56] PR #9158: logger: add support for setting snapd.debug=1 on kernel cmdline [08:58] ok that worked fine [08:58] but now I have new denials [08:59] type=AVC msg=audit(08/25/20 08:57:14.811:930) : avc: denied { search } for pid=29402 comm=snap name=dbus dev="tmpfs" ino=17427 scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir permissive=1 [08:59] type=AVC msg=audit(08/25/20 08:57:14.811:931) : avc: denied { write } for pid=29402 comm=snap name=system_bus_socket dev="tmpfs" ino=17428 scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=1 [08:59] type=AVC msg=audit(08/25/20 08:57:14.816:932) : avc: denied { connectto } for pid=29402 comm=snap path=/run/dbus/system_bus_socket scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1 [08:59] I'll propose this separately and park that until Maciek is back [09:01] mvo: ok, will look in a little bit [09:12] * zyga adds tests for tracking services and hooks to verify everything [09:35] tested hooks and services now, let's expand that to more systems and add session-level service tracking tests [09:45] oh drat [09:45] need power [10:05] ok, let's test on all the systems now [10:05] and add a test for session-level service tracking [10:30] PR snapd#9211 opened: o/snapstate: disk space check with InstallMany <⛔ Blocked> [10:51] zyga: if you are in review mood, please check out 8982 :) [10:51] mvo let me look [10:52] oh a biggie [10:52] but I need to grok snapshots more anyway [10:53] in 10 minutes, let me open a PR with a small but important fix [10:59] mvo reviewing now [11:00] https://github.com/snapcore/snapd/pull/9212 is ready for review, this will help with the feedback from maciek and will allow me to adjust the selinux policy next [11:00] PR #9212: cgroup,snap: track hooks on system bus only [11:01] PR snapd#9212 opened: cgroup,snap: track hooks on system bus only [12:01] PR snapd#9213 opened: secboot: read kernel efi image from snap file [12:13] * zyga goes for lunch [12:13] mvo 90% done with review [12:13] mvo but it will be a -1 so please don't merge [12:48] mvo done [12:57] zyga: thanks you [12:58] thanks me :) [13:30] PR snapcraft#3262 opened: specifications: configurable apt mirror === marcustomlinson is now known as marcustomlinson1 === marcustomlinson1 is now known as marcustomlinson [13:51] PR snapd#9158 closed: logger: add support for setting snapd.debug=1 on kernel cmdline [13:54] zyga: mvo: I checked the go code (quickest thing), there is padding, probably not completed padding but is there [13:54] s/completed/complicated/ [13:59] pedronis in the per-member header? [14:01] In the call I was confused by the question and I replied about gzip padding, not tar padding [14:02] I think we can expland the tar writer to have an optimized mode when TarWriter.Write cheats and assumes the header had the right size and ignores the source [14:04] we were talking about tar [14:04] the zip files are just put in a tar [14:04] yes, I looked at tar now as well [14:05] I think the optimization is not hard to do, we should fix the small stuff, land this and I can open a follow-up [14:32] * cachio afk [14:37] pedronis: instead of `emptyMap` is `cleanBootVars` an ok var name for #9205 ? [14:37] PR #9205: boot/initramfs_test.go: reset boot vars on the bootloader for each iteration [14:37] ijohnson: yes, either clean or reset [14:38] pedronis: ack since it's just 7 lines I am going to force push with `cleanBootVars` [14:38] https://github.com/snapcore/snapd/pull/9212 is green and relatively simple (most changes are just additional testes) [14:38] PR #9212: cgroup,snap: track hooks on system bus only [14:40] coffee and back to debugging [14:42] cachio: hey I just noticed we don't actually run the tests/nested/core20 suite with the run-nested label do we ? [14:45] PR snapcraft#3260 closed: tools: update setuptools in environment-setup [14:50] PR snapcraft#3261 closed: requirements: pin setuptools devel requirement [14:54] zyga: +1d that simple PR [15:01] PR snapcraft#3263 opened: colcon v2 plugin: honour http(s) proxy for all build commands [15:01] thanks! [15:12] pedronis: actually I looked into a bit more, I don't think we should use `-f` for reboot from the initramfs, see https://github.com/snapcore/snapd/pull/9207#discussion_r476526179 [15:12] PR #9207: boot/bootstate20: reboot to rollback to previous kernel [15:12] pedronis: given my findings there, do you think we should actually switch to using `systemctl reboot`? or should I ask x n o x (who is away this week at plumbers) [16:00] * zyga runs one more tests and calls it a day [16:11] ijohnson, sorry for the delay, I had to to buy a medicine and the had lunch [16:11] it should run core20 [16:11] we are running tests/nested/ [16:11] cachio: no worries, which spread-nested task on github actions runs tests/nested/core20 ? [16:12] google-nested:ubuntu-20.04 [16:13] cachio: ah thanks, I got confused by the breakdown [16:13] thanks I see the test I was interested in actually failed [16:15] ijohnson, which one? [16:15] cachio: a test I proposed in https://github.com/snapcore/snapd/pull/9208/checks?check_run_id=1023281431 [16:15] PR #9208: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel [16:15] tests/nested/core20/kernel-failover failed there due to silly bashisms [16:19] cachio: 2.46 is getting released now, snapd snap beta should be ready in ~30min, core will be ~1h or so [16:19] mvo, nice, thanks [16:20] ijohnson good silly or bad silly [16:20] ijohnson was it masking a real bug [16:20] zyga: nah just I thought using `local` would work not in a function but it doesn't, I made a change to the test after it passed locally thinking it was harmless, seems it's not [16:20] 2020-08-24T20:19:32.8528139Z + local retry=120 [16:20] 2020-08-24T20:19:32.8528330Z /bin/bash: line 82: local: can only be used in a function [16:21] oh hey this came up while you were out zyga [16:21] yeah? [16:21] nested.sh needs love [16:21] forgot to bring this up, but retry does not work with functions sourced from i.e. nested.sh [16:21] I need to review the changes from cachio tomorrow [16:21] how do you think we could make retry work with functions ? [16:21] zyga: I'm done with my meetings and mostly with the release, I'm happy to do your suggested fixes on 8982 in my morning (I will be up early). but if you get to it that's welcome of course. but don't feel obliged, you have a a lot of important stuff on your plate :) [16:21] ijohnson retry doesn't work with any function [16:21] it works with programs [16:21] zyga: yes [16:21] zyga: but could it be made to work with functions ? [16:22] or is this just another rat hole not worth trying to fix [16:22] PR snapd#9214 opened: release: 2.46 [16:22] ijohnson it would be unsafe, I really don't want to go there [16:22] fair [16:22] I think it could be [16:22] I mean, yeah, [16:22] but the semantics is not something I'm 100% sure [16:22] zyga, tx [16:22] I realize this would work much better if nested.sh becomes a tool program instead of a sourced program [16:23] so maybe we just do that instead of trying to make retry work with functions [16:23] yeah, I think so [16:23] ok, fair enough [16:24] this came up while you were out and I forgot about it til just now [16:24] I think that's a fail desire but it's really more robust to compose programs than functions [16:24] let's see what we can do about nested.sh first [16:24] I lied, I ran more tests [16:24] but I need to run [16:25] my wife calls me [16:46] mvo released snapd [16:46] arch pings me to update [16:46] heh [16:54] zyga: how dare we not release to arch immediately, we must be lazy :-) [17:33] zyga, should we test on opensuse leap 15.2 as well? [17:33] there are new gce images [17:47] cachio: armhf failed to build in the ppa so core is a little bit delayed there [17:48] mvo, ok, np [17:48] I'll start with snapd [17:48] mvo, is snapd delayed as well? [17:49] cachio: no, but it looks like the change to "mkversion.sh" we did gives it a terrible version number :( [17:49] mvo, 2.46+git2.46.2.46 [17:49] mvo, is it the final version for snapd? [17:51] oh no was that my fault [17:51] cachio: well, it should be 2.46 [17:51] sorry [17:51] ijohnson: a bit unclear, no worries just yet [17:51] mvo, ijohnson no problem [17:51] just wanted to make sure [17:52] cachio: it's the right binary content but the version needs fixing :/ [17:56] PR snapcraft#3109 closed: pcache: introduce persistent cache decorator [17:56] PR snapcraft#3110 closed: repo: use persistent cache for fetching stage packages [18:04] ijohnson: hm, I suspect "git describe --dirty" is not quite fixed :/ [18:04] ah darn do we build with an old version of snapcraft in LP? [18:04] ijohnson: I think I set it to "candidate" [18:05] ijohnson: we build it here https://code.launchpad.net/~snappy-dev/+snap/snapd-2.46 [18:06] mvo: but that bug is marked as fix released for snapcraft 3.1 which was released in jan 2019 :-( [18:06] the bug that the dirty thing referenced that is, https://bugs.launchpad.net/snapcraft/+bug/1806746 [18:06] Bug #1806746: Move state file to avoid dirtiness when snap is used for code <19.04> <19.04-external> [18:07] mvo: when I run mkversion.sh from master with your changelog placeholder mkversion.sh works fine [18:08] ah but I bet it is built from the release/2.46 branch let me try that one [18:08] mvo: it still gives me a valid version number it just has [18:08] ./mkversion.sh [18:08] *** Setting version to '2.46' from git. [18:08] ijohnson: it might be snapcraft in LP that is the problem [18:08] ijohnson: it works for me locally too [18:09] argh I think I know why [18:09] the core snap builds with "legacy" snapcraft because it doesn't specify a base or build-base in the snapcraft.yaml [18:09] ijohnson: this is the snapd snap [18:09] oh then I don't know why [18:11] mvo: I'm going to try and reproduce building snapd locally from release/2.46 then [18:11] mvo: does it only happen for snapd snap or the core snap too ? [18:12] PR snapd#9215 opened: mkversion.sh: do not use git describe --dirty [18:13] ijohnson: just snapd snap it seems [18:13] ijohnson: core just finished [18:13] ok, I've got a build going locally, should be done in a couple minutes [18:14] ijohnson: thanks, I will need to do some stuff around the house, should be back in 15min or so [18:14] ijohnson: in the meantime *maybe* 9215 will help [18:14] mvo: I will start a parallel build of your branch too just to see [18:17] silly snapcraft doesn't let multiple lxd containers for the same snap to run simultaneously [18:26] PR snapcraft#3264 opened: colcon v2 plugin: don't strip environment for stage-runtime-dependencies [18:30] mvo: I did manage to reproduce with snapcraft locally, debugging now [18:31] ah but actually there is a diff, it is dirty! [18:31] - "checksumSHA1": "UHhUJNcYbKn3xxZDuPh9GX6BWrM=", [18:31] + "checksumSHA1": "uLS+3ymPr8NztAjDjmiRkpKIsIQ=", [18:32] oh, what makes it dirty? [18:32] get-deps.sh modifies vendor.json with the above patch [18:32] I'm gonna try a fresh build with that changed on release/2.46 and committed [18:33] ah but then it won't be building 2.46 tag [18:33] hmm [18:33] I could always move the tag locally on my repo [18:34] oh, interessting [18:34] alright build running again let's see what happens [18:35] aha, secboot hm, hm [18:35] strange that we did not encounter this before [18:35] mvo: but actually though we have encountered this frequently [18:36] that secboot SHA keeps changing for myself and claudio and pedronis and possibly also others too locally [18:40] oh [18:42] so maybe that's the fix - updating vendor.json instead of --dirty [18:42] anyway, stuff for tomorrow, I need to call it a day [18:42] * mvo waves [18:57] PR snapd#9216 opened: vendor.json: update mysterious secboot SHA again <⚠ Critical> [20:18] PR snapd#9217 opened: run-checks: add typos from auto-tools when using `make hack` === Aavar_ is now known as Aavar [21:48] PR snapd#9218 opened: tests: running tests on opensuse leap 15.2 === benfrancis2 is now known as benfrancis