[05:31] <mborzecki> morning
[05:31] <mborzecki> matrix bridge appears to be up, yay!
[06:12] <mborzecki> zyga-mbp: hey
[06:59] <mborzecki> mvo: hi, can you take a look at https://github.com/snapcore/snapd/pull/10387 ?
[07:01] <pstolowski> morning
[07:09] <mvo> good morning mborzeck and pstolowski 
[07:09] <mvo> mborzeck sure, looking
[07:10] <mborzecki> thanks!
[07:10] <mborzecki> pstolowski: hey
[07:24] <zyga-mbp> good morning guys :)
[07:36] <mvo> good morning zyga-mbp 
[08:06] <mborzecki> pedronis: hi, you've rebased #10388 on top of master?
[08:08] <pedronis> mborzecki: yes
[08:08] <pedronis> didn't change anything
[08:08] <pedronis> there were a lot of failing spread tests?
[08:08] <pedronis> are they failing on master?
[08:11] <mborzecki> pedronis: i don't think so, https://github.com/snapcore/snapd/pull/10394 seems to be the latest pr (not counting yours) and looks pretty green
[08:11] <pedronis> ok, then hopefully my rebase will help
[08:11] <pedronis> to be clear I rebased because both the reviews there were straight +1 without commnets
[08:11] <pedronis> *comments
[08:11] <pedronis> otherwise I would have merged
[11:07] <mborzecki> pedronis: i've updated https://github.com/snapcore/snapd/pull/10361
[11:11] <pedronis> mborzecki: thx
[11:50] <pedronis> mborzecki: question there
[11:55] <mborzecki> pedronis: ah, ok, makes sense, that will also change a bit of other tests, so maybe it'd be best to put it in a followup?
[11:55] <pedronis> mborzecki: ok
[12:53] <ijohnson[m]> hi folks
[12:59] <mborzecki> ijohnson: hey
[12:59] <ijohnson[m]> Oh whoops SU time
[13:06] <heol> Hi!
[13:06] <ogra> hey heol 
[13:06] <heol> Can someone advice how to add "wifi-ap" in a custom model assertion please?
[13:07] <heol> The eerror from ubuntu image is : "cannot add snap "wifi-ap" without also adding its base "core" explicitly"
[13:09] <ogra> you need to list core too in the model assertion
[13:09] <ogra> *before* wifi-ap
[13:09] <ogra> the assertion is processed top to bottom 
[13:10] <heol> ogra You mean "name: core20, type: base" ?
[13:10] <ogra> nope, name core ...
[13:11] <ogra> and iirc it has a special type 
[13:11]  * ogra checks one of hs models 
[13:11] <ogra> heol, https://people.canonical.com/~ogra/UC20/pi-mediacenter-appliance/mediacenter.model ...
[13:11] <ogra> type core ...
[13:12] <ogra> ths assertion actually uses core, core18 and core20 for different app snaps that require them and seeds the cores first
[13:15] <heol> Yes that did id :D
[13:16] <ogra> 🙂
[13:16] <heol> what would be the rule in this case. Because I ran "snap info wifi-ap" and it only specifies several "latest/*" tracks
[13:16] <ogra> use the --verbose switch to the info command and grep for base
[13:17] <ogra> that should always show you what base a snap is built against
[13:17] <ogra> oh, except for snaps that did not have a base ... these are always "core"
[13:18] <ogra> i just notice that wifi-ap is old enough to not specify a base)
[13:18] <heol> I guess that's the case for wifi-ap then as it doesn't show a base :)
[13:18] <ogra> yeah
[13:18] <heol> Thanks a lot for the help
[13:18] <ogra> it is one of these "special snowflakes" ... pulseaudio is another one 
[13:19] <heol> thankfully I don't need that one :)
[14:06] <cachio_> ijohnson[m], hi
[14:06] <cachio_> https://paste.ubuntu.com/p/XbP3WPV2SF/
[14:06] <cachio_> the test security-dev-input-event-denied
[14:06] <cachio_> is giving Operation not permitted instead of Permission denie
[14:06] <cachio_> for core-18
[14:07] <cachio_> mborzecki, ~
[14:07] <cachio_> any idea?
[14:07] <cachio_> it is in line 48
[14:07] <cachio_> not sure if there was a change that could make that fail sudenly
[14:14] <pstolowski> mborzecki: would you take a look at https://github.com/snapcore/snapd/pull/10385 when you have a moment?
[14:14] <ijohnson[m]> mvo: let me know if you want to sync to talk about the release
[14:21] <ijohnson[m]> cachio_: let me take a look
[14:21] <mborzecki> cachio_: ijohnson didn't we arrive to the conclusion that the order of apparmor vs device cgroup cannot be guaranteed?
[14:24] <ijohnson[m]> we did yeah, as per jj's comments but I think that was mainly just to be expected on newer kernels/systems ?
[14:24] <mborzecki> pstolowski: sure, will do
[14:24] <mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/10385#discussion_r650990148 
[14:34] <cachio_> ijohnson[m], it is happening in uc18
[14:34] <cachio_> the test is failing so often now
[14:35] <cachio_> I'll try to reproduce it in the other core systems
[15:02] <mborzecki> hmm some of the boostate 20 reseal tests are not too realistic
[15:03] <mborzecki> the catch is that we expect a test to do a reseal, but never setup the bootchain, so when the comparison time comes, it's empty bootchan vs a valid one, which always reseals
[15:03] <mborzecki> also resealForModel() went away at this point too
[15:10] <pedronis> mborzecki: resealForModel looked a bit strange to me
[15:10] <pedronis> fwiw
[15:10] <mborzecki> pedronis: well, it's gone now
[15:10] <pedronis> mborzecki: just tests problems, or did you find actual bugs?
[15:11] <mborzecki> pedronis: no, just tests afaict
[15:11] <pedronis> (might be my fault, but things evolve)
[15:11] <pedronis> mborzecki: good, and yes test realism is a complex matter, that's why it's recommended to get test to fail first but not always easy
[15:12] <mborzecki> pedronis: well, all of us worked and reviewed this so we share the blame fwiw 😉
[15:20] <cachio_> ijohnson[m], what I see is that if I execute the test security-dev-input-event-denied twice
[15:20] <cachio_> the seconnd time allways fails 
[15:21] <cachio_> in any core system
[15:21] <cachio_> allways first time works well
[15:21] <cachio_> but then it fails
[15:22] <cachio_> with the same error 
[15:22] <cachio_> mborzecki, ~
[15:29] <ijohnson[m]> yeah seems related, maybe you need to do the REBOOT thing after the end of the test
[15:30] <cachio_> ijohnson[m], in this case these is another one which is leaving this state
[15:30] <cachio_> to the reboot should go in more than 1 test I think
[15:32] <pedronis> mborzecki: I reviewed https://github.com/snapcore/snapd/pull/10386
[15:32] <pedronis> lgtm, some small things
[15:38] <cachio_> mborzecki, can you take quick look to  #10367 please? 
[15:43] <ijohnson[m]> cachio_: yeah I think we should make the security-dev-input-event-denied test work like you made the security-device-cgroups test in #10367
[15:43] <cachio_> ijohnson[m], ok, thanks
[15:43] <cachio_> I'll implement that
[15:44] <ijohnson[m]> ack, thanks for working on this
[15:57] <mborzecki> pedronis: thanks!
[16:00] <mvo> ijohnson[m]: sorry for the slow reply, had to prep for an interview. about 2.51.1, I can do it either latere tonight or in my morning
[16:02]  * cachio_ lunch
[16:03] <ijohnson[m]> mvo: I mean if all that's needed is to start the process I'm fine to start it, just wanted to check in with you about if there is anything outstanding for 2.51.1 that you wanted included
[16:56] <pedronis> ijohnson[m]: mvo: how are we going to deliver the netlink interface? a branch?
[16:56] <ijohnson[m]> is netlink one of the things that we need for 2.51.1 then?
[17:15] <zyga-mbp> mvo: interactive debug session in gitlab with spread: https://git.ostc-eu.org/OSTC/OHOS/components/sysota/-/merge_requests/20
[17:15] <zyga-mbp> mvo: too some setting up but it looks like a nice way to get into problematic builds
[17:17] <ijohnson[m]> zyga-mbp: woah that's super cool
[17:17] <ijohnson[m]> I assume it times out after a certain amount of time so as not to keep VM's running indefinitely ?
[17:31] <zyga-mbp> ijohnson[m] yes, it's fully configurable 
[17:32] <zyga-mbp> ijohnson[m]: there are two uses: a job that's running (it times out with the job)
[17:32] <zyga-mbp> ijohnson[m] and just-spaw-on-demand interactive terminal 
[17:32] <zyga-mbp> ijohnson[m] (available to project maintainers only)
[17:32] <zyga-mbp> ijohnson[m] that is also configurable but has an option of infinite time, so you can just keep a session running in a browser all you like
[17:34] <ijohnson[m]> Nice! Yeah I can't tell you the number of times I've wanted something like that, but I also don't need to tell you because you know exactly the pain :-D
[17:35] <zyga-mbp> haha, yes
[17:35] <zyga-mbp> I think  github actions has something similar now
[17:35] <zyga-mbp> but I've stopped using it for "big" things so I don't actively keep track
[17:35] <zyga-mbp> we're running into a weird error where clang-based builds work almost anywhere except in CI
[17:36] <zyga-mbp> where they seem to use instructions unsupported by the CPU
[17:36] <zyga-mbp> and we want to know what the hell the CPU is :)
[17:37] <zyga-mbp> but that's tomorrow
[17:37] <zyga-mbp> did the spread review session happen today by any chance?
[17:38] <zyga-mbp> it doesn't look like it has
[17:38] <zyga-mbp> mvo: did I miss it? is it the wrong Monday?
[17:38] <ijohnson[m]> zyga-mbp: yeah it happened, only one thing landed but two other PR's needed to be redesigned
[17:38] <ijohnson[m]> zyga-mbp: not sure what happened myself I only heard about it from mvo during standup this morning
[17:39] <zyga-mbp> ohhh
[17:39] <zyga-mbp> https://github.com/snapcore/spread/pull/112
[17:39] <zyga-mbp> landed!!!!
[17:40] <zyga-mbp> woot, thank you mvo
[17:40] <zyga-mbp> I'll send more patches :)
[17:42] <zyga-mbp> I need to EOD now but I'm happy to see some progress :)
[20:01] <pedronis> ijohnson[m]: I reviewed https://github.com/snapcore/snapd/pull/10381  it wasn't on my queue and didn't need particularly my review, but you said you were blocked on the 2nd review for it
[20:02] <ijohnson[m]> pedronis: ah nice thank you, yeah it didn't need your review just needed a second one
[20:02] <ijohnson[m]> I'm trying to do all the test moving in very targeted PR's so as not to confuse unnecessarily
[20:04] <ijohnson[m]> ah but wait now I have introduced more conflicts for myself for #10346 ☹️ oh well I suppose I can sort that out