[01:04] https://pastebin.com/GNiXtqE2 [01:04] i don't know where the error is [02:15] RingtailedFox: try `SKIP_GOFMT=1 ./run-checks` [02:16] RingtailedFox: run-checks will also check gofmt using an old version of Go, so if you are using a new version of Go sometimes there is differences [02:18] i think my version of go is up to date [02:20] right that's the issue, run-checks is checking your code against an old version of gofmt [02:23] that one almost worked [02:24] https://pastebin.com/h4Fc7giq [02:24] i'm installing libseccomp now [02:24] RingtailedFox: you need libseccomp-dev installed [02:25] lessee if that works [02:28] now it's complaining about xfs/xqm.h... [02:28] also still whining about sys/capability.h [03:14] RingtailedFox: what distro are you building on ? [03:20] Mageia Linux (the continuation of Mandrake/Mandriva) [03:21] it uses RPM but only some fedora RPMS work with it [03:21] mostly becuase mandrake split from fedora back during the Red Hat 5.2 days (around 1996) [03:41] PR snapd#9567 closed: tests: using the nested-state tool in nested tests [05:06] PR snapd#9576 closed: [RFC] snap-bootstrap: be more robust for recover mode, ignore some errors [07:04] hey mvo [07:04] hey zyga [07:08] hey mbeierl [07:08] mborzecki, [07:08] morning [07:09] zyga: heya [07:10] good morning mborzecki [07:10] rainy morning [07:10] mvo: hey [07:10] zyga: indeed, fugly weather back again [07:10] mborzecki, trump is going to win, ;-) [07:12] zyga: wrong channel (seriously) for this kind of discussion [07:12] mvo, sorry, I was referring to the weather as a joke [07:12] but I'll stop [07:12] zyga: oh, ok, sorry, did not get the joke [07:12] mborzecki: a second review for 9541 would be great [07:22] mvo: sure [07:24] ta! [08:00] mvo: can you take a look at https://github.com/snapcore/snapd/pull/9593 ? it's a simple one [08:00] PR #9593: tests/lib/nested: enable snapd logging to console for core18 [08:02] mborzecki: sure [08:04] mborzecki: looks like test failures in there, should I restart? [08:05] mvo: restarted it just now [08:05] ta [08:08] morning [08:11] good morning pstolowski [08:11] hey mvo [08:11] hey pawel [08:37] mborzecki: how does 9592 look - should I do a full review or does it need work anyway? [08:37] PR snapd#9541 closed: osutil/disks: re-implement partition searching for disk w/ non-adjacent parts [08:39] mvo: imo it looks nice with the improvements i discussed yday with ian, but it'd be useful if you take a look and comment whether the approach is sound [09:20] Saviq: hey [09:36] mborzecki: aha, I see - you mean the new approach using the state machine? I think that is pretty neat indeed, feels very nice [09:43] mborzecki: added some bikeshed comments [09:49] mvo: cool, let me see, i can address some and update the PR [09:52] mborzecki: yeah, nothing deep except the meta question but I don't think we need to solve this one today :) [10:01] wondering where this bits comes from: audit: type=1400 audit(1604471452.215:462): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=413579 comm="snap-confine" capability=4 capname="fsetid" [10:01] i see it on opensuse and arch with 5.9 kernels === ogra_ is now known as Guest75299 [10:03] mborzecki: a good question, something implicit from a newer libc maybe? [10:04] mvo: idk, we don't allow fsetid for s-c in the aa profile, but it does not seem to break anything either [10:04] mvo: wish there was an ip address included in the log [10:05] s/ip/instruction pointer/ ofc [10:10] hmm no denial on groovy it seems [10:10] pstolowski: mvo: trivial PR https://github.com/snapcore/snapd/pull/9596 [10:11] PR #9596: spread: use the official image for Ubuntu 20.10, no longer an unstable system [10:13] PR snapd#9596 opened: spread: use the official image for Ubuntu 20.10, no longer an unstable system [10:16] mborzecki: +1 [11:08] PR snapd#9593 closed: tests/lib/nested: enable snapd logging to console for core18 [11:09] hi everyone, is there a chance that someone here knows/understands about Routers/switchs/TCP and stuff like that, i need to rearange my home network and I cannot find on google what I need.. Please PM me. Thank you very much. [11:31] Saviq: hey, any chance for full output of 'snap tasks 1627' wrt https://bugs.launchpad.net/snapd/+bug/1902230 ? I think tail -n20 stripped potentially interesting bits ;) [11:31] Bug #1902230: Tasks stuck if api.snapcraft.io not found [12:02] mvo: i think we may need to update our bugtriage calendar [12:03] (if you already did, then sorry, ignore me) [12:05] pstolowski: yeah, it's on my list but haven't managed yet [12:05] np [12:28] cachio: hi, can you take a look at https://github.com/snapcore/snapd/pull/9596 ? there's a bunch of failures, some are caused by missing packages, [12:28] PR #9596: spread: use the official image for Ubuntu 20.10, no longer an unstable system [12:28] cachio: do we pre-install those packages in our images? [12:30] pstolowski: sorry, it's gone now :/ [12:31] :( [12:31] But, as far I could tell, there was nothing interesting there [12:36] Saviq: i was hoping to see what tasks errored out and/or were undone. i can make guesses but tasks list would clear any doubts. can you pastebin "snap debug timings 1627" (although I don't expect much info from there) [12:47] mborzecki, cheking [12:48] I need to manually create this image in our projecy [12:48] project [12:48] I'll do it now [12:54] cachio: cool, thanks! [12:55] update is in progress [12:55] lets see [13:03] PR snapd#9597 opened: gadget: correct sfdisk arguments [13:32] pstolowski: that change is purged I'm afraid [13:34] here's some journal, but doubt that will help much… https://paste.ubuntu.com/p/s5Pc3JGDCP/ [13:37] Saviq: the change may be purged but debug timings may still be there [13:38] mborzecki: re fsetid, that is just noise. I fixed it once but then a refactor of snap-confine reintroduced it [13:39] mborzecki: I've always planned on fixing it, though at this point it will be a while [13:39] jdstrand: ah, that's fine, i'll prep something for master to silence that down [13:40] mborzecki: is it causing problems? it is serving as a reminder to fix it currently :) [13:40] jdstrand: afaict it's not, the topic where this came up was clearly opened because of other errors [13:41] jdstrand: also, ahven't noticed any issues on arch or opensuse, still a myster why it does not appear on grovvy, even though we are using the same policy [13:41] mborzecki: if you deny it, be sure to keep an eye on snaps in lxd. it shouldn't be an issue ime, but just keep an eye on it [13:42] jdstrand: ok, thanks for the tip, i'll look into it once i'm not knee deep in uc20 :/ [13:42] pstolowski: no, change not found [13:42] mborzecki: I don't have a lot of time to talk now, but recall that the kernel enforces rate limits on logging and with appamor, there is additional rate limiting with capabilities [13:43] Saviq: hmm ok, thanks [13:44] mborzecki: so you're not always going to see it when it hits. also, the section of code that triggers it is very late and has to do with the sensitive ordering of things when priv dropping (caps, setgid, setuid, apparmor profile transition, nnp (that isn't the order!)) [13:45] mborzecki: I'd have to look at the code, but on distros that aren't strict, you might not see it since everything might not be in play (though, I don't think that is the case) [13:46] jdstrand: interesting, so far it appears only on distros with aa, but not missing some features [15:00] hm need to drive the kids to a dentist for a checkup, bbl [15:07] mvo: let me know what I can do to help with #9592, seems Maciej handled all of his comments left this morning [15:07] PR #9592: many: implement degraded recover mode [15:08] ijohnson: yeah, just having another look but I think once tests are finished this can go in [15:08] ijohnson: but please also double check his changes [15:08] (if you haven't done already) [15:08] mvo: just to be clear you mean the individual unit tests for each state transition ? [15:08] mvo: yes I'm going through those changes now [15:10] ijohnson: sorry I mean once the spread test run finished [15:11] oh ok, right I will open up the individual unit tests for state transitions as a follow-up [15:11] ijohnson: I think the individual unit tests can wait a little bit, ideally we would check with Samuele tomorrow if he wants to see bigger changes [15:11] ijohnson: and if not then we can tackle those, how does that sound? [15:11] mvo: ok that sounds good to me [15:11] ijohnson: cool :) [15:12] mvo: ah actually looking at Maciej's changes I think I am missing a unit test for degraded mode with no encryption setup [15:13] mvo: should I push that up too after you're done looking ? [15:13] or is that case ok to wait until this has landed too? [15:14] ijohnson: I think it's ok as a followup, spread run will take ~1h :/ [15:16] ok [15:27] mvo: hmm seems some uc20 spread runs just failed in prepare but a few others passed, seems suspicious, but I am trying to reproduce now [15:31] ta [16:17] ijohnson: more nitpicks but all followup material for 9592 I think (and in a meeting again :/ [16:17] mvo: thanks looking now [16:21] mvo: well now that I read the log more clearly, the only uc20 spread runs that passed were the tests/lib/tools/suite/... which doesn't actually run inside uc20 :-/ so all the real uc20 runs failed, and I can reproduce locally [16:21] mvo: I'm looking into it now [16:30] ijohnson: uh ok [16:31] yeah not good at any rate, it's unclear what's wrong since it worked locally for me in my VM [16:31] perhaps my VM is magic [16:32] heh - ok. sorry for being so terse, in a meeting right now :/ [16:32] no worries [16:39] PR snapd#9596 closed: spread: use the official image for Ubuntu 20.10, no longer an unstable system [16:55] * cachio afk [16:57] mvo I think I figured it out, will let you know if my hypothesis is correct [16:58] ta [17:45] PR snapd#9524 closed: tests: new boot state tool [17:45] mvo: I have it fixed here, but unfortunately it's a bit more code :-/ there are two issues, one is simple to fix and the other requires a new function in snapd's secboot wrapper, which also necessitates some additional testing inside snapd's secboot [17:45] mvo: I am wrapping up the testing here, do you think I should open a separate PR for the new secboot function to make it easier to review? [17:46] hey ijohnson [17:47] hello zyga-mbp [17:47] ijohnson I must retract my earlier statement, new star trek has equally new plot! [17:47] * ijohnson hasn't seen it, but just assumed it was the same :-) [17:48] * zyga-mbp goes quiet to let ijohnson and mvo work on secboot [17:50] * ijohnson hugs zyga-mbp [18:02] ijohnson: it's fine, just include it [18:02] * mvo hugs zyga-mbp [18:02] mvo: ok I have it done will push in a minute [18:04] ijohnson: ta [18:05] PR snapd#9482 closed: bootloader/assets/grub: adjust fwsetup menuentry label [18:07] mvo: pushed [18:08] mvo: I have another spread run going here, if something comes up I will let you know [18:08] ijohnson: thank you, I check back a bit later then [18:11] mvo: the last 3 commits are only 162 additional lines so hopefully not too bad [18:11] I'm sure pedronis will opinions on naming tomorrow [18:20] ijohnson: yeah, replied [18:20] ijohnson: I wonder if I should wait with the merge until tomorrow, spread run will take ~1h so it will get late in my TZ :/ [18:31] re [18:31] mvo that sounds reasonable, if you are considering waiting til tomorrow, I think it might be wise to split up the changes into more manageable chunks if only to make it easier for pedronis to review tomorrow [18:31] hey mborzecki [18:32] ijohnson: ah so we're waiting for pedronis then? sounds good to me [18:32] mborzecki: mostly wondering if it's worth it to stay up late to do 2.48 [18:32] mborzecki: I mean, it will be at least +1h until spread finishes [18:33] assuming no re-runs are necessary [18:33] mborzecki: and then ~1-2h until the snapd/core builds are there [18:33] haha [18:33] yes [18:33] mborzecki: wdyt? [18:33] the more we talk about it the more I think we need to have more than one mvo to do this sort of thing across timezones :-) [18:33] ijohnson: splitting does sound good fwiw, if we wait [18:33] ijohnson: haha - are you volunteering ;) [18:34] mvo: hm tbh approaching this tomorrow with clear and rested head sounds better than staying late today [18:34] some day maybe - probably not today [18:34] ijohnson: but seriously, I think it's fine, we have enough to do :/ [18:34] ijohnson: yeah, exactly [18:34] mborzecki: +1 [18:34] ijohnson: I think it's settled, let's do it in the .eu morning. feel free to split but only if it's not too much trouble [18:34] mvo: we can sync with samuele in the morning [18:35] PR snapcraft#3349 opened: cli: allow snap-id for validate [18:35] mborzecki: yeah, sounds good to me [18:35] re mborzecki [18:36] * zyga-mbp agrees that being overworked is not a good thing [18:36] mvo: then we'll ahve tomorrow and friday right? [18:36] mborzecki: I think it's settled, let's call it a day [18:36] mborzecki: yeah, totally fine for beta/candidate work [18:37] mvo: idk if cachio needs to supevise stuff, but then maybe some tests can run over the weekend [18:38] mborzecki: yeah, that's a good point, I think it's mostly automatic [18:38] cool, so we're set then :) [18:38] * mvo nod [18:39] Sounds good [18:39] Thanks mvo and mborzecki [18:40] * mvo hugs ijohnson and mborzecki and heads out [18:40] me too, cu tomorrow [20:25] PR snapcraft#3350 opened: [WIP] project loader: advanced grammar for build-environment === JanC_ is now known as JanC [20:55] PR snapcraft#3351 opened: storeapi: import sort with isort [20:55] PR snapcraft#3352 opened: tests: import sort with isort [20:55] PR snapcraft#3353 opened: tools: import sort with isort [21:00] PR snapcraft#3354 opened: cli: import sort with isort [21:06] PR snapd#9598 opened: secboot: add LockTPMSealedKeys() to lock access to keys independently [21:21] PR snapd#9599 opened: secboot: refactor Unlock...IfEncrypted to take keyfile + check disks first [22:06] PR snapd#9600 opened: cmd/s-b/initramfs-mounts: refactor recover mode to implement degraded mode [23:16] PR snapd#9601 opened: tests: using systemd-run instead of manually create a systemd unit - part 1