10:07 <swatish2> IDENTIFY swati@108 swatish2

10:12 <pinchartl> swatish2: I really recommend identifying using a TLS certificate instead of a password. see https://www.oftc.net/NickServ/CertFP/

10:51 <daniels> zmike: note that non-merge jobs are explicitly prioritised all the way down so they don't grief pre-merge runs

10:52 <daniels> pq: we need to sync the gitlab-ci.yml with Mesa so that we don't create duplicate pipelines - you're getting one pipeline created for the push to the branch, and another created for the MR - there should only be one

10:53 <pq> daniels, and due to some server delays, I first see the wrong one in the MR page? And something stop it from running?

11:01 <daniels> it's not delays per se, it's just a race. right now, the way the CI rules are constructed, the server will always create two pipelines for a branch that has an open MR. the MR page will always show the MR pipeline if it exists (auto-run) or the branch pipeline (all manual) if not. the way to fix that would be to fix the rules to say 'don't create a branch pipeline if there's an open MR'

11:01 <daniels> mesa/mesa/.gitlab-ci.yml has a bunch of pretty well-documented rules for this, although they're much more complex because of the different workflow Mesa uses

11:02 <pq> a race, ok

14:43 <alanc> these "CVE Detection in the repo" issues are bordering on spam

14:44 <dwfreed> s/bordering on//

16:24 <phryk> i'm currently trying to work out a minimal example for creating a gbm buffer. i have code that compiles, but dies with "_amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)".

16:26 <phryk> so i have a suspicion i would like to confirm: can only one program that manages hardware-accelerated buffers be running at any one time?

16:27 <phryk> i have fuzzy memories of this being a big issue back in the day, but also that dri/drm were supposed to be an extra abstraction that sidesteps the resource contention issue, so i'm unsure if i'm right.

16:28 <phryk> i was honestly kind of hoping i could just have X running on one display and run my own drm rendering stuff on the other.

16:32 <MrCooper> phryk: this is again more suitable for #dri-devel, this channel is about the freedesktop.org infrastructure

16:33 <MrCooper> that said, unless you want to display the buffers via KMS, see the discussion starting at https://gitlab.freedesktop.org/mesa/mesa/-/issues/13607#note_3028341

16:35 <phryk> oh, i thought #dri-devel was for the development *of* dri itself, not development *with* it.