12:28 <mupuf> bentiss: you were fast to pick up the new b2c release :D

12:30 <mupuf> Another couple of months and we should have the 1.0 release which will provide backwards compatibility of the interface

12:55 <danvet> mupuf, sponsor box?

12:56 <mupuf> bentiss: For ^, I'll need access to the indico namespace again. Mind adding me back?

13:04 <bentiss> mupuf: sure

13:05 <bentiss> mupuf: re adding the latest release: simply because my pipelines started to fail :)

13:07 <mupuf> bentiss: ah, right, I guess gitlab removed the previous one. I asked it to keep HEAD

13:08 <bentiss> mupuf: it's also because the url of the job changed. Something happened in the job definition I couldn't pin point

13:09 <mupuf> right. Well, using a release is a good idea anyway

13:22 <bentiss> mupuf: IIRC, that's all you need. but I might be wrong. feel free to ping if something is not right

13:22 <mupuf> bentiss: thanks, I will

14:54 <mupuf> anholt_, danvet, daniels, karolherbst: interested in having a testing workshop at XDC? I am thinking on focusing on the kernel and trace testing

14:55 <daniels> mupuf: sure

14:55 <karolherbst> sounds good

14:56 <karolherbst> I think you might want to ping robclark as well. Rob wanted to look into some kernel compile testing for msm and/or drm-misc

14:56 <mupuf> OK, will send a proposal

14:56 <karolherbst> if I remember correctly

14:56 <mupuf> Nice

14:57 <mupuf> I made a patchwork <-> gitlab CI bridge, so we can use that for IGT and the kernel

14:58 <karolherbst> cool

15:12 <robclark> karolherbst: btw, the other day we hit on the idea of having the gitlab .yml stuff in kernel tree, but with an include/import directive to pull in a file from a different tree that just setup some variables about which runners / ci farms were online (ie. so we could disable offline runners/farms without needing a kernel patch, but could otherwise keep the rest of CI yml in drivers/gpu/drm/ci

15:13 <robclark> (but I didn't really have more time since then to work on it.. and out this week and then merge window time when I get back.. so might be a bit..)

15:22 <mupuf> robclark: no need to put anything in-tree, we can use another project's gitlab-ci.yml

15:33 <robclark> mupuf: I know that.. but we defn what *at least* xfails to be in-tree (when we get to point of running things like igt/deqp)

15:33 <robclark> I think it is probably better to have it all in-tree except the per runner/farm kill-switches

15:34 <mupuf> I don't think you want to run IGT like you run gl test suites as it is flaky AF

15:35 <mupuf> And you don't want everything in the flakes.txt file

15:35 <robclark> well, if that is the case, I think we want to get to the point where it isn't the case ;-)

15:36 <mupuf> I915 has been trying for many many many years...

15:36 <robclark> also, addition of new tests for new features, should be in sync with the kernel tree

15:36 <mupuf> But maybe it is just i915 being racy left and right!

15:37 <mupuf> Yeah, would be great if we could

15:40 <robclark> I think we could include nearly all of it in drivers/gpu/drm/ci .. and just have a `include:\n - project: ...` thing pull in a file from different tree with online/offline status of runners.. actually that would maybe be a useful thing for mesa too so we didn't need MR's when someone's fiber gets cut or whatever

15:42 <mupuf> Yeah. That or have an auto-approve after a deadline

15:42 <robclark> mupuf: fwiw, https://gitlab.freedesktop.org/robclark/msm/-/tree/gitlab-ci/drivers/gpu/drm/ci .. my idea was to have gitlab-ci-$drivername.yml for each driver that has it's own -next tree.. which basically just sets FDO_UPSTREAM_REPO and then includes the common stuff.. each driver tree configures drivers/gpu/drm/ci/gitlab-ci-$driver.yml as it's toplevel yml file

15:50 <mupuf> Well, that sounds like a plan to me! Let's get building + IGT's DRM_auth working, then see how it behaves

15:51 <mupuf> It would already have prevented a regression in amdgpu on 5.13.8 (build failure)

15:55 <robclark> cool.. and back to your original question, I'd be interested in a workshop covering kernel CI

15:56 <bentiss> mupuf: not sure if it was clear from your initial question, but count me in too for the workshop

16:06 <mupuf> Good, I'll file it tonight!

19:23 <karolherbst> bentiss: pmoreau tried forking drm/nouveau today and it still takes 10-15 minutes. Any way on how to speed it up? I thought you were planning some infra changes to make it possible?