02:51mareko: how does the CI invoke jobs on remote machines? does it have hardcoded IP addresses or domain names?
02:55airlied: mareko: gitlab runners
02:55airlied: the runners are registered with the gitlab instance and keep a connection to it
03:03mareko: airlied: is that the place where the IP address is entered? does it have to be a public one?
03:06airlied: mareko: no IP addresses
03:06airlied: you register the runner with the gitlab instance using a token
03:06airlied: and you start the runner and it connects to the gitlab and waits for instruction
03:07airlied: so it can be run on a private network just fine, as long as the machine can access the gitlab in some way
03:08airlied: the biggest security concern is someone sending MRs to the runner that try to hack internal company networks
03:08airlied: so usually companies prefer to have them hosted in a separate area/network
03:09airlied: if they are dealing with public MRs
03:14mareko: airlied: the runner runs on a different machine than the test machine, right? does the runner control local test machines?
03:18airlied: mareko: depends on the lab setup you want
03:18airlied: I think some of our runners run on the test machine, and then some use abstractions like lava to control a lab
03:19airlied: mupuf, DavidHeidelberg : might know variations between what Collabora does, Valve does and others
03:24airlied: mareko: I think if you need power control to reset hw machines, then lava or whatever Valve are using might be needed
03:25airlied: http://www.mupuf.org/ actually has some articles on valve's setup,
03:36mareko: that's perfect
03:36mareko: thanks
04:00mupuf: mareko: here is a gotcha presentation we gave at xdc: https://xdc-2023-slides-eric-6482caf87de21c275335c8afa0325e225798ce9525.pages.igalia.com/
04:09mareko: I just realized that ci-tron is a lemon
06:32mupuf: mareko: hehe, yeah. Citron in French means lemon. We thought it was funny
08:37mlankhorst: can confirm it's spelled the same in swedish too, though pronounced slightly different
08:47mripard: lumag: we can't really get rid of it: the problem is that there's no way to access the state from ALSA hooks reliably wrt locking
08:51lumag: mripard, so ideally we should migrate it to the audio-specific part.
08:51lumag: of the driver.
08:52mripard: I'm not sure what you have in mind here, copying the char rate to the global structure that can be accessed by ALSA hooks look reasonable to me
08:52lumag: Looking at several HDMI codecs it looks like there should be a common code for some parts of that. Like getting N / CTS values, etc.
09:02mripard: yeah, but why wouldn't the tmds char rate in the global structure work in that case?
09:02mripard: possibly with the introduction of a helper if needed
09:08daniels: mareko: broadly speaking, the external interface is a runner (any machine) which polls the GitLab service (outbound HTTPS requests only) for new jobs. once it receives those jobs, how it distributes it is dependent on the local setup. bare-metal machines will just directly bang on power controls, serial ports, NFS, etc, to set the machine up for booting, so the gitlab-runner needs to be next to the devices
09:09daniels: both LAVA and ci-tron make HTTPS requests to an external scheduler which drives each machine in different ways; LAVA has more low-level control with kernel/devicetree/rootfs/etc, whereas ci-tron is mostly focused around booting into a locally-installed agent which will pull a container down to the local machine and execute out of that
09:11daniels: so both bm and LAVA arguably make more sense for smaller machines with 'strange' (i.e. not UEFI BIOS) boot flows, whereas ci-tron is better suited to larger machines which can handle the load of pulling+storing+unpacking containers without either blowing through available RAM or having to attach NVMe storage which costs 4x as much as the board
09:11daniels: (and LAVA is better suited to devices which will execute non-GitLab jobs e.g. KernelCI, which is why we're still using it)
14:57glehmann: cwabbott: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29433 how did the turnip test here pass before this MR? lower_pack_split didn't handle the flush to zero variant and ir3 doesn't either
14:59glehmann: or did it just change from crash to pass?
15:01glehmann: to fail I mean
15:57mareko: daniels: what Gitlab privileges are required to be able to run the CI in Gitlab? "Developer"?
16:00jenatali: mareko: A member of a group. That can be the ci-ok group
16:03Hazematman: Hey, I've been trying to debug this CI issue i've got with llvmpipe https://gitlab.freedesktop.org/Hazematman/mesa/-/jobs/59331629
16:03Hazematman: The issue seems a bit weird. It seems deqp gles2 cases fail because CTS will report pbuffers as not being supported. I've been testing with older Mesa versions and it seems to be broken in the same way.
16:03Hazematman: I'm a bit confused as to why this problem is just manifesting now and it makes me think I may be missing something. I see this change from eric_engestrom https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28343 that could be what caused it to manifest. But that was merged 2 months ago so I'm a little hesitant to think its related
16:06mareko: jenatali: for Mesa, that's all developers, right?
16:06jenatali: mareko: Yes, it includes all developers (and I think reporters)
17:01daniels: mareko: do you need to restrict it?
17:06mareko: daniels: not yet, I'm just learning and forwarding this internally
17:07daniels: mareko: happy to talk directly with people if it helps; just drop a mail
17:09mareko: I don't know if anything will come out of this
19:34jessica_24: hey just wondering, is there any init script where I can add `xrandr -o 1` and have GDM and GNOME come up as rotated? Or any x11/gnome/gdm config that I can set so that the orientation is landscape by default for all users
19:55abhinav__: pq emersion Hi, do you have any suggestions for ^^ or can tag someone who might
19:57emersion: i'd suggest asking in a GNOME channel
19:57emersion: i think there is a config file somewhere fwiw
20:07abhinav__: emersion ack, thank you