08:28 <pq> Looks like there is no Gitlab notifications email setting for my personal group, is there? There are for non-personal groups, and for individual projects.

08:31 <pq> Only now I realized that I'm not getting any notifications from any of my personal projects due to notification settings. >_<

13:51 <pq> What happened to the Gitlab "allow edits from maintainers" tick box? Is it hardcoded to "yes" in gitlab.fd.o now?

13:54 <MrCooper> enabled by default, not hardcoded

13:54 <pq> I don't see a tick box to disable it, so

13:54 <MrCooper> which MR?

13:55 <pq> just wondering I don't need to check it with ci-fairy anymore

13:55 <pq> MrCooper, one I didn't create yet, on project in my personal group.

13:57 <MrCooper> maybe it depends on project settings

13:58 <MrCooper> still seeing it on a Mesa MR

14:00 <MrCooper> or maybe it just couldn't make any difference for that MR in your project?

14:00 <pq> I see it in a Weston MR of mine, yeah. Just not in https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/5 - maybe because I am a maintainer?

14:01 <pq> or maybe because the source and destination repo are the same?

14:02 <MrCooper> yeah, something like that I suspect

14:04 <MrCooper> it's not there when I create an MR for my Mesa project either

14:05 <pq> hmm, I tried to fork a project my personal group into my personal group, and it failed but didn't say why. Just "try again".

14:06 <pq> it's a bit difficult to operate, when when the project being in my personal group makes me special.

14:07 <MrCooper> I wonder if the ci-fairy check will pass

14:08 <pq> I wonder that too, but.. oh hey, it did, it seems

14:08 <MrCooper> cool

14:08 <pq> it just took... 6.5 minutes to run the whole job :-o

14:10 <pq> every CI "step" took around one minute, including the step that uploaded no artifacts

14:11 <pq> https://gitlab.freedesktop.org/pq/color-and-hdr/-/jobs/14624505 in case anyone's interested

14:30 <pq> both fbo-packet-m1xl-1 and fdo-packet-m1xl-3 seems to be affected by the slowness

14:30 <bentiss> fdo-packet-m1xl-1 seems on its knees, I am trying to ssh to it and just getting a shell is slow

14:30 <pq> they run, but every little thing takes one minute

14:32 <bentiss> that's weird, I do not see too many jobs eating CPU

14:32 <bentiss> well, now it started again, though the load average is 100

14:33 <bentiss> iotop, htop and df seem happy, I wonder if one of the other jobs is not doing something nasty

14:34 <bentiss> ouch, swap is full

14:35 <bentiss> memory is almost unused, but swap is full

14:35 <bentiss> I guess time to reboot them

14:35 <pq> thank you for looking into it :-)

14:39 <bentiss> seems that saigowth/igt-gpu-tools entered in a bad state on this runner at least

14:49 <bentiss> FWIW, m1xl-2 is also not very responsive

14:57 <bentiss> heh, nobody noticed m1xl-2 simply because it is so dead gitlab-runner is not even pinging gitlab.fdo

15:06 <bentiss> m1xl-1 and m1xl-2 are back, waiting on some tasks to finish on m1xl-3 before hitting the hard reboot

16:11 <bentiss> I forgot to mention that m1xl-3 was back too

17:17 <hikiko> hello, I've got a question about a MR: some days ago I tried to rebase it with the button and then assign it to marge bot. The pipeline was blocked and then I received a message tha Marge Bot cannot merge it because CI takes too long. We've manually rebased it, and I re-assigned it to marge bot but it seems blocked. My question is: 1- is there something I've done wrong in the process? 2- how can I unblock it? MR: https://gitlab.freedesktop.org

17:17 <hikiko> /mesa/mesa/-/merge_requests/13236 thanks in advance!

17:17 <hikiko> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13236 (it was splitted)

17:24 <anholt> hikiko: looks like that one long marge pipeline did pass eventually, a reassign probably would have worked.

17:26 <anholt> marge hasn't gotten to it today because things are backed up with lots of merges this morning (including a number of build failures that should have been caught pre-marge)

17:27 <anholt> though we've also got some other flakiness. tomeu, daniels: more grunt timeouts, I don't see NFS messages this time but I'd guess it's related to yesterday's. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/14634229

17:29 <hikiko> anholt, I see, thank you! then do you think it's ok it delays and the delay is not related to this message "Merge blocked: the source branch must be rebased onto the target branch."? I had rebased it about 1 hr ago (55 minutes or so)

17:29 <hikiko> sorry

17:29 <hikiko> :s/rebased/reassigned it!

17:30 <anholt> you don't need to manually rebase unless there are conflicts, marge does that as she decides which MR to try to merge next

17:30 <anholt> another top flake this week https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13318

17:31 <hikiko> good to know that about rebase

17:32 <hikiko> yes, it seems there are more flakes

17:32 <hikiko> so, I'll just wait maybe marge starts later

17:33 <hikiko> thanks a lot anholt :)

17:33 <anholt> https://gitlab.freedesktop.org/marge-bot tells you what she's up to

17:34 <hikiko> right! I should had thought to check it!

17:34 <hikiko> bookmarked!

21:34 <daniels> anholt: I’d guess - as it happened on the first run of the bunch - that it’s related to the lastclose OOPS, which I’d also guess is related to the fbcon alloc fail?

21:34 <daniels> agd5f: ^ is that something you’ve seen?

21:34 <daniels> anholt: I’m also on holiday this week so not going to be able to do anything about it either way

21:36 <anholt> I'm not seeing an oops in my logs, just the warn

21:36 <anholt> but yeah, the warn seems to happen on every lastclose

21:37 <anholt> new test setup is now keeping things alive longer, unfortunately long enough now to oom the poor grunt for unclear reasons.