[00:08] PR snapcraft#2968 opened: git: always fetch specified source-commit before using === diddledan5 is now known as diddledan [04:18] Bug #1857358 changed: Not yet operational on Fedora systems [06:20] morning [06:20] hey mborzecki [06:20] PR snapd#8240 closed: tests: just remove user when the system is not managed on create-user-2 test (2.44) [06:35] mborzecki: a second review for 8231 would be great [06:37] mvo: wow, that AARE for nvme is scary ;) [06:38] PR snapd#8231 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s [06:40] school run, back in 30 [06:40] mborzecki: aare? [07:07] PR snapd#8243 closed: o/snapstate: set base in SnapSetup on snap revert [07:08] re [07:08] mvo: apparmor regular expressions [07:10] mborzecki: aha, right [07:11] and with the latest regulations, parents can no longer enter school buildings, at least in my area [07:12] wouldn't be surprised if they close down all schools for a week or so [07:14] mborzecki: that's likely to happen [07:14] I think [07:20] hm the failures in 8185 that pedronis saw yday is probably services-watchdog test state leaking into subsequen tests [07:28] PR snapd#8185 closed: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs [07:48] PR snapd#8238 closed: many: fix a pair of ineffectual assignments [07:52] mborzecki: I think 8206 is ready for a review too and hopefully an easy win [07:52] mborzecki: we are at 52 now, maybe we can hit 50! [07:53] PR snapd#8237 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s - 2.44 [07:53] mborzecki: we have some simple ones like 8220 pending (unfortunately I think this one needs a security review) [07:53] mvo: ha, so it was a hanging sleep command [07:55] mborzecki: yes [07:58] good morning [07:58] how are things? [07:58] mvo: maybe we should set Ptdeahtsig to syscall.SIGKILL for most commands, not sure we use it at all [07:59] zyga: morning [08:02] mborzecki: I think we don't [08:02] hey zyga [08:06] morning [08:06] pstolowski: hey [08:07] mvo: #8206 is green! [08:07] PR #8206: travis.yml: run unit tests on arm64 as well [08:21] zyga: want to double check 8100 ? it got your +1 already but it changed a bit since (more abstractions mostly) [08:22] yeah sure [08:22] zyga: shoudl be simple [08:22] I am in despair [08:22] found my gpg key [08:22] and it's locked [08:22] and I don't recall the password :) [08:26] PR snapd#8206 closed: travis.yml: run unit tests on arm64 as well [08:26] one more and we are down to 50! maybe 8197? no code change just a refactor for snap downloads via snapd? [08:27] zyga: oh no! [08:33] some heavy rain today [08:46] mvo: i'm not dropping SetRecoverySystemEnv from uboot struct yet, for now i've updated ExtractedRecoveryKernelImage.. iface [08:47] mvo: although i don't expect needing to use SetRecoverySystemEnv, we'll know for sure after the meeting with the foundations [08:54] mborzecki: +1 [08:55] mborzecki: I also added samuele as optional, not sure if he wants to join or not [08:55] ok [08:58] pedronis: hi, #8224 has conflicts now [08:58] PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds [08:59] mborzecki: yes, saw that, will try to merge master and address at least partially the XXXs soon [08:59] mborzecki: thx [09:01] pstolowski: thanks for your update to 8201! [09:01] mvo: np. i'm nervous to see if it passes [09:02] pstolowski: heh :) [09:02] pstolowski: *fingers crossed* [09:02] mvo: can you please refresh my memory [09:02] how is snap-repair updated? [09:04] zyga: snap-repair is part of the snapd snap and gets updated when snapd gets updated, was that the question? [09:04] yes, that's mostly it [09:04] I recall we had a copy of snap-repair in core16 systems [09:04] somewhere in writable [09:05] is that the case? [09:05] zyga: I think we talked about it, I don't recall we did it [09:06] mvo: it's still a todo [09:06] ok, that's what I was curious about thanks [09:07] mvo: there are still current todos: https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/39 and https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/42 [09:08] so the packaging bits, the task for this cycle, plus consider how early it can be run [09:10] yeah :/ [09:11] I wonder if snap-repair makes sense in core 20 world [09:14] it has a role, going through a recovery reboot is not always acceptable especially if there are other solutions [09:14] otoh it hasn't been used yet for real, so hard to judge [09:18] mvo: reviewed [09:20] pstolowski: I reviewed 8201, it needs a 2nd review [09:22] pedronis: ty [09:41] pedronis, pstolowski I did a pass on 8201 [09:42] mvo: thanks! [09:43] pstolowski: hope it's not too annoying [09:43] mvo: no worries [09:54] mvo: the extra ticks might be do go through Ensure as well [09:54] it's not just about prune [09:54] yes. but i'll add a comment [10:03] pedronis: thanks, could be, I am just puzzled because AIUI we only mock the ticks for the pruneC and that calls st.Prune() directly, so not sure how Ensure() comes into play. but it's fine, it's so much nicer than before, just tried to get a good understanding what is going on [10:04] mvo: aborting might need two passes through Ensure [10:04] mvo: each time we tick prune we also go throgh Ensure [10:04] or something like that [10:05] pedronis: ok [10:10] cachio: good morning! if you still see this failure of importing the user assertion on uc20 even in the second boot, could you please pastebin/take-a-picture of "journalctl -u systemd-udevd" from the second boot in run mode? [10:22] * zyga feels so so and goes for some tea/coffee upstairs [10:22] pedronis: when I'm back I'll attack env again [10:22] pedronis: I read your comments and I'll go and simplify the expression logic and combine it all into Apply [10:35] mvo, sure [10:35] mvo, good morning, I just triggered a new run [10:36] mvo, yesterday it was not goind the run mode, just install mode [10:36] I was waiting for the new core snap that should help on that [10:37] cachio: ok [10:37] cachio: thank you [10:41] mvo, today it is going into the run mode [10:41] https://paste.ubuntu.com/p/n6GJpXNjwQ/ [10:41] but still it is not importing the user assertion [10:42] zyga: I added some more comments about further simplifications I would like to see for now [10:42] pedronis: ok [10:42] I'll read them now [10:44] zyga: let me know if you have questions [10:44] ack [10:44] cachio: can you do a reboot once it's in run mode and paste me the output of "journalctl -u systemd-udevd" please? [10:45] weird [10:45] yes, waiting for the reboot [10:45] github comments I mean [10:45] I can respond to some of your comments but not all [10:45] pedronis: I was thinking and I'm very happy with []osutil.ExpandableEnv [10:45] because that removes the need for some extra glue logic [10:46] and expresses more naturally what is really going on [10:46] mvo: do we have a formatting problem in interfaces/policy/basedeclaration_test.go or it's just different go versions [10:46] mvo, https://paste.ubuntu.com/p/GZsNPyNRCC/ [10:46] pedronis: I'm not aware of one, but it could be go version screw [10:47] pedronis: I ony edit that file in nano [10:47] zyga: as far as I know there's no way to "merge" those envs before applying them, that would do what we need [10:47] pedronis: yeah, I came to the same conclusion [10:47] pedronis: I'll get to it :) [10:48] zyga: we can probably also leave out the Overrides bit from those methods, and just call them Envs() []osutil.ExpandableEnv [10:49] pedronis: I just wanted something that is distinct from the field (Environment) [10:49] pedronis: perhaps we don't need a real method after all [10:50] pedronis: if we change the type to ExpandableEnv [10:50] we can just reach out to app.Snap.Environment and app.Environment [10:50] but we'll see [10:50] first some of the big moves [10:51] mborzecki: I merged master and updated #8224, the last changes need a new pass [10:51] PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds [10:53] cachio: thanks, do you see /lib/udev/rules.d/66-snapd* in your image? [10:54] I cant login to the image [10:55] but let me check if I can unsquash it [10:55] cachio: oh, so the journal output is also not from inside the image? [10:55] no [10:55] the journal output is from the host machine [10:56] in that case let me try to shell on it [10:57] cachio: ok, we probably need to somehow create an image that you can add "systemd.debug-shell=1" to the kernel commandline so that you get a root-shell [10:57] cachio: the output of the udevd would be great to have, that hopefully gives us clues what is brekaing [10:57] * mvo needs to leave for a wee bit [10:58] { [10:58] ok [11:01] kid invasion [11:01] silly stuff is lucyasd=ad [11:01] 4WT~WWW [11:03] noo, #8201 failed on google:ubuntu-core-20-64:tests/core/snapd-failover. and on prepare for fedora. and on google-unstable:opensuse-15.1-64:tests/main/session-tool [11:03] PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <⚠ Critical> [11:04] ^ zyga [11:04] zyga: https://api.travis-ci.org/v3/job/660982235/log.txt [11:04] pstolowski: ack, [11:05] pstolowski: there must be something I'm missing there [11:05] as it only fails infrequently, there must be some kind of race that makes PAM module which sets up XDG_RUNTIME_DIR fail [11:07] zyga: grab the log if you need it, i'm going to restart the tests soon [11:07] done [11:19] mvo, https://pastebin.com/Gh8rrwNP [11:20] for some reason it is getting stuck in that line [11:20] the shell never appeards [11:20] hmm arm64 unit tests still hanging? [11:20] mvo, could you chekc pleaseif I did it correctly? [11:20] mvo, https://paste.ubuntu.com/p/fHTdPT2j6Q/ [11:22] cachio: please try setting it in �*Run Ubuntu Core 20 � [11:22] cachio: so when the second grub screen is there you need to press "e" for edit [11:22] cachio: and it in the line with the chainload...kernel.efi there [11:22] cachio: does that make sense? [11:23] mvo, ok, thanks [11:23] cachio: not sure if it gives you a debug shell on the serial console though, gives you one on vt9 for sure [11:26] mvo, I did what you said but it is getting stuck in the same line [11:27] mvo, https://paste.ubuntu.com/p/S8gQq64WPq/ [11:37] cachio: oh no! maybe you just don't get a debug shell on the serial port :/ that's sad [11:41] mvo, do you want to connect? [11:41] cachio: not right now, I need to ponder a bit, I will probably need to try to run this locally in qemu to have the full vritual console access :/ [11:42] ok, just ping me in case you need the image [11:46] mborzecki: I pushed https://github.com/snapcore/pi-gadget/pull/34 [11:46] PR pi-gadget#34: gadget.yaml: move ubuntu-boot to VFAT [11:55] PR snapd#8100 closed: httputil: add support for extra snapd certs [12:07] PR snapd#8244 opened: [RFC] config: add system.certs.[a-zA-Z0-9] support [12:21] mvo: commented on the pi-gadget PR [12:24] * pstolowski lunch [12:25] PR snapcraft#2963 closed: project: add fallbacks for os.sched_getaffinity [12:27] zyga: thanks [12:44] mvo, hey [12:44] I am trying from serial port and I get this [12:44] https://paste.ubuntu.com/p/6RkcpYd4TV/ [12:49] mvo, the following run I did't see tha terror https://paste.ubuntu.com/p/Cfkv2w7mfT/ [12:53] cachio: this looks like a OVMF bug, I wonder what version is available in gce [12:56] ovmf: [12:56] Installed: 0~20191122.bd85bf54-2 [12:56] Candidate: 0~20191122.bd85bf54-2 [12:56] Version table: [12:56] *** 0~20191122.bd85bf54-2 500 [12:56] 500 http://us-east1.gce.archive.ubuntu.com/ubuntu focal/main amd64 Packages [12:56] 100 /var/lib/dpkg/status [12:57] mvo, is it ok? [13:04] mvo: can we turn off arm tests again, they timeout: https://travis-ci.org/github/snapcore/snapd/jobs/661020356?utm_medium=notification&utm_source=github_status [13:04] sometimes [13:17] pedronis: type Foo *Bar behaves in odd ways in go [13:17] that hides the entire method set of Bar [13:17] is there any way to "reach" it? [13:21] zyga: that's annoying, I missed this detail, or forgot it [13:22] PR snapcraft#2969 opened: snap: re-add xml development packages for non x86 [13:23] zyga: anyway the text here https://golang.org/ref/spec#Method_sets has that implication [13:30] thanks [13:30] zyga: so embedding the OrderedMap seems the only solution [13:30] yeah, I see that [13:31] I think type a = b would be nicer [13:31] but we cannot for now [13:31] ok, I'm not blocked, thank you [13:49] suspend resume on linux with fractional scaling in gnome resizes everything, clipping parts of windows [13:49] oh well [13:57] pedronis: sure, let me do that [13:59] PR snapd#8245 opened: travis: disable arm64 again [14:40] PR snapd#8244 closed: [RFC] config: add system.certs.[a-zA-Z0-9] support [14:40] PR snapd#8246 opened: client, daemon, overlord/devicestate: structures and stubs for systems API [14:40] pedronis: ^^ [14:52] PR snapd#8245 closed: travis: disable arm64 again [14:52] * cachio lunch [15:03] * zyga lunch as well [15:03] and small break to fix backup server [15:04] PR snapd#8247 opened: .travis.yml: enable arm64 again as unstable <⛔ Blocked> [15:59] mborzecki: I queued it [15:59] thx [16:07] * zyga is back to finish work [16:08] pstolowski: 8201 is green, do you want to squash merge it and edit the description? I will cherry pick to 2.44 then [16:09] offtopic, firefox is really really fast [16:13] mvo: yes, let's squash merge [16:14] mvo: doing [16:14] pstolowski: thank you! [16:15] PR snapd#8201 closed: tests: mock prune ticker in overlord tests to reduce wait times

<⚠ Critical> [16:21] PR snapd#8248 opened: snap: introduce Container.RandomAccessFile [16:33] zyga: I looked at the uio fix, one question, also I notice that one of jdstrand comment isn't addressed, it didn't sound just a nice to have from him, in one form or the other [17:06] PR snapd#8249 opened: interfaces: make gpio robust against not-existing gpios in /sys [17:07] pedronis: hmm, which comment was that? [17:07] pedronis: the one about ordering? [17:07] * zyga looks [17:07] yes [17:09] pedronis: I would not do that in this PR, as I explained in my response that's not a new property and doing anything better (for auditing) would require a smaller dive into the apparmor backend. Doable but not for 2.44 IMO [17:10] PR snapd#8250 opened: tests: mock prune ticker in overlord tests to reduce wait times (2.44) [17:10] zyga: I understand, let's see what he says [17:11] ok [17:12] if needed I can probably implement that ordering tomorrow if I didn't take the swap day [17:12] is he around today? [17:12] I haven't seen him yet, let me check mail [17:13] no mail about absence (which he carefully sends each time) so I would assume he's around [17:16] PR snapd#8251 opened: overlord: remove unneeded overlord.MockPruneInterval() mocks [17:25] so [17:25] pedronis: env question [17:25] pedronis: snap run --shell foo [17:25] I guess we should apply the environment then, right? [17:25] I guess we should [17:26] I didn't look there deeply, just realized we do that "late" in snap-exec [17:26] and not in snap-confine [17:44] zyga: fyi, https://github.com/snapcore/snapd/pull/8241#pullrequestreview-372983889 [17:44] PR #8241: interfaces: work around apparmor_parser slowness affecting uio [17:44] jdstrand: checking [17:44] zyga: conditional ack provided one small change. while doing that, you might do: s/clariry/clarity/ [17:45] jdstrand: sure [17:45] jdstrand: I get it, that's sensible, [17:45] thanks! [17:46] * zyga needs to apologize to everyone, school is cancelled across the country and kids got crazy and are really bothering me all the time now [17:50] zyga: we should apply the enviroment yes, don't we atm ? [17:50] pedronis: I _hope_ so :) [17:50] I'll get there soon [17:50] pedronis: just thinking about this [17:51] there's some discrepancy between hook and app environment [17:51] specifically we don't perform the save-restore across setuid-lost environment [17:51] though _perhaps_ that's okay, but there's no comment to account for why [17:52] zyga: as I mentioned, we should move that logic to osutil I think, though it's a bit of an orthogonal problem [17:52] and not something I would try in this PR [17:52] ok [17:55] zyga: basically ForExec and OSEnviroment should grow flags or variants to deal with that [17:55] mmm [17:55] I'll stash that as a follow up, close to finishing the changes for the comments in the PR so far [17:57] zyga: it's relates to this comment here: https://github.com/snapcore/snapd/pull/8242#discussion_r390880508 [17:57] PR #8242: many: improve environment handling, fixing duplicate entries [18:27] pedronis: so env, all but Transform is now done [18:28] I had to invent a method name EnvStack() so please look if you like it [18:28] in any case it's just an implementation detail and doesn't change the big picture [18:29] I'll go after Transform and try to wrap up for today [18:29] mvo: I'll send the paperwork tomorrow [18:29] it's late today [18:36] zyga: sure, see you [18:37] mvo, quick question, I am working tieh the snapd-failover16 test which fails randomly [18:37] mvo, I see this line Mar 11 18:36:27 localhost.localdomain systemd[1]: Started Failure handling of the snapd snap. [18:37] but the service cant fix the dydtem [18:38] is any other source of information to take alook why? [18:38] cachio: hm, journalctl -u snapd.failure should have some info [18:39] I got that info from there [18:39] I just see that it tries to fix it but no mere info [18:40] cachio: oh, so it tries to fix and fails :( [18:40] cachio: snapd and snapd.failure are the relevant sources [18:40] mvo, right [18:40] cachio: can you pastebin those two when the failure happens? [18:41] mvo, snapd https://paste.ubuntu.com/p/W67D9yf7PG/ [18:42] snapd-failure https://paste.ubuntu.com/p/SxGVRzn8YH/ [18:42] mvo, it happens right after it installs the snapd broken snap [18:43] cachio: interessting, is it random, i.e. does it sometimes work? or always failing currently? [18:45] first time worked, and 2nd failed [18:45] iwht this vm [18:45] I'll run again [18:45] cachio: so it's essentially random? [18:45] cachio: the logs are really not giving clues, that's a bit sad [18:45] mvo, not happening 100% of the times for sure [18:46] but can't say if it random or not [18:46] cachio: aha, could be another test polluting it? [18:46] mvo, yes, but still trying to figure out that [18:47] cachio: thanks [18:48] pedronis: done [18:51] mvo: if you want to get https://github.com/snapcore/snapd/pull/8242 in to 2.44 please organize some review tomorrow [18:51] PR #8242: many: improve environment handling, fixing duplicate entries