09:10 bentiss: DavidHeidelberg: done: ml29 has i386, arm-12 has armv7
09:54 DavidHeidelberg: bentiss: thanks!
10:06 mupuf: got a zink-anv-tgl flake, should I just add a commit in my series to add the flake to the list?
10:06 mupuf: or do you want a separate series?
10:06 mupuf: DavidHeidelberg: I guess this is for you ^
10:06 dj-death: flaking on what?
10:08 mupuf: spec@ext_timer_query@time-elapsed,Fail
10:09 mupuf: dj-death: ^
10:09 mupuf: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/51551128
10:12 dj-death: oh
10:13 dj-death: yeah I think they flake across drivers
10:13 dj-death: but Kayden recently noticed we might not accurately scale the timestamp from gpu to cpu
10:17 Kayden: I think those flake across drivers and always have
10:20 mupuf: never seen it fail on zink-radv
10:24 mupuf: Kayden: since you have more context than me, mind sending the MR to mark it as flaking on all intel platforms?
11:45 daniels: add it as a global flake
11:46 mupuf: daniels: please, don't
11:46 daniels: if the test is known unsound, and I'm not surprised that timer tests are not always going to be super robust even without a broken implementation, just do that
11:46 mupuf: we never had it
11:46 daniels: mupuf: ok
11:56 kode54: are these VMs? maybe their timing is being prone to hypervisor level context switching?
11:59 dj-death: I'm not sure what the tests are trying to do tbh
12:00 dj-death: the only thing you can tell is that cpu timestamp should be around the GPU ones if you flush everything
12:00 dj-death: but it looks like it's trying to somehow scale that to amount of time the GPU should take to complete a task
12:00 dj-death: can't see that ever be reliable
12:04 kode54: that does sound like a thing prone to flaking out
12:10 mupuf: dj-death: well, seems like a candidate for deletion in piglit then, or fixes
12:24 bentiss: migrating the registry data from the old cluster to the new right now. Impact should be minimum, except maybe for a few images pushed in the last 2 hours
12:25 bentiss: (those pushes should be fixed in ~1h30 min)
12:37 daniels: kode54: no, they're not VMs, they're run bare-metal on dedicated machines
12:37 daniels: mupuf: that's what I mean, if the test is something that can only work most of the time under ideal conditions, then we shouldn't be running it as part of pre-merge
12:38 daniels: even if it does happen to work most of the time on AMD
12:38 mupuf: +1
12:38 mupuf: I was just not comfortable with not looking first at what the test does ;)
12:40 kode54: daniels: got it, I needed that further explanation from dj-death to understand how this could be something that would flake out even in perfect conditions
12:40 kode54: no perfect guarantees that a given task will perfectly fit calculated timing
12:41 kode54: maybe there is a range of error in there though
12:41 kode54: (in the testing of the results, I haven't looked, sorry :( )
21:01 DavidHeidelberg: "Error: initializing source docker://quay.io/centos/centos:7: can't talk to a V1 container registry"... RedHat has some lovely ratelimiting or what...
21:15 gallo[m]: yeah, quay is down https://status.quay.io/