00:42 <karolherbst> is there something broken with ./.gitlab-ci/bin/ci_run_n_monitor.py? It seems to fail to fetch pipelines for any projects you don't own

03:14 <gallo[m]> karolherbst: what is the exact command you are trying to execute? I can try to investigate here.

03:37 <gallo[m]> karolherbst: what is the exact command you are trying to execute? I can try to investigate here.

06:35 <eric_engestrom> karolherbst: yeah, if the pipeline is not in $your_username/mesa, it won't auto-detect it

06:35 <eric_engestrom> karolherbst: for that usecase you need to pass `--pipeline https://...`

08:05 <karolherbst> eric_engestrom: that's what I'm doing, but it doesn't work

08:08 <karolherbst> ./.gitlab-ci/bin/ci_run_n_monitor.py --target 'llvmpipe-piglit-rusticl' --pipeline-url 'https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/944652'

08:08 <karolherbst> `RuntimeError: Could not find any pipelines for {'projectPath': 'mesa/mesa', 'sha': '31a8a465563ab26588eb6d929e5c4c02759d4fba'}`

09:35 <eric_engestrom> karolherbst: that pipeline is for a different commit

09:36 <karolherbst> that's what the script is throwing at me

09:37 <eric_engestrom> if you don't pass `--rev` it uses HEAD of wherever you're running from

09:37 <karolherbst> ohh....

09:37 <eric_engestrom> you can specify `--rev c2329c008af1b66be6660613a6cfa838ce5082bf` to override that

09:37 <karolherbst> right.. I'm just confused on why that's needed at all though

09:38 <eric_engestrom> because ci_run_n_monitor needs a bit of a rewrite, it should pull the git hash from the pipeline when `--pipeline` is passed

09:38 <eric_engestrom> I've known that for a few weeks but haven't got around to doing it

09:38 <eric_engestrom> sorry :]

09:39 <karolherbst> ahh don't be. I'm more confused why the commit rev is required at all for any of this

09:39 <karolherbst> doesn't really make sense kinda, but I guess there is some weirdo gitlab reason for it?

09:41 <daniels> karolherbst: no, it's because the script was originally written to take no arguments, and just find the pipeline based on the SHA of HEAD and the project; the pipeline-url stuff was retconned in afterwards

09:41 <karolherbst> ahh

12:37 <eric_engestrom> bentiss: I'm getting "AttributeError: 'User' object has no attribute 'is_admin'" on `damspam request-webhook`, which I would think it is because the token isn't working for some reason, but that token works for everything else I do (it has full permissions because I'm lazy)

12:37 <eric_engestrom> so I'm thinking perhaps the instructions at https://gitlab.freedesktop.org/freedesktop/damspam#usage-for-gitlab-project-maintainers are not up to date anymore?

12:40 <eric_engestrom> if I don't have the file I get "One of --token-file or --token-env is required" so at least the token is in the right file (and also now I'm using the --token-env because I prefer that rather than writing it to a file

12:42 <eric_engestrom> just cooked a fresh token to make sure, I still get the same error

12:55 <bentiss> eric_engestrom: damn. Looks like a regression in https://gitlab.freedesktop.org/freedesktop/damspam/-/commit/2237d80436a147c55b2d5f92d4b0e4270c194a1c

12:57 <eric_engestrom> hehe, let me guess, it was only tested by instance admins? :P

12:59 <bentiss> eric_engestrom: yep, and yep :)

13:40 <alatiera> bentiss, daniels btw there's a weird issue creeping up randomly on some gitlab-runners with the following error:

13:40 <alatiera> ninja: error: loading 'build.ninja': Value too large for defined data type

13:40 <alatiera> apparently, that's specific to 32bit jobs and it's a btrfs issue

13:40 <alatiera> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4S52TXRSMT4BMVZYKZ5GY3636ZTHPHAK/?sort=thread

13:41 <daniels> hilarious - inode too big?

13:41 <alatiera> yeap

13:41 <alatiera> just fyi if anyone asks

13:42 <daniels> we're only using ext4+overlayfs tho

13:42 <daniels> at least looking quickly at the x86-64 builders

13:42 <alatiera> oh really?

13:42 <alatiera> https://gitlab.freedesktop.org/amyspark/ffmpeg/-/jobs/45520521 here's when I saw it last

13:44 <daniels> ah, -22 is xfs

13:48 <alatiera> hmm

13:48 <alatiera> oh looks like the xfs 32bit inode is a mount option, so I guess it also can't work in containers on top the existing 64bit mount

13:49 <alatiera> containers_are_a_lie_dot_com

14:00 <pendingchaos> I got a bunch of "Failed to parse rule for ...: rules:changes:compare_to is not a valid ref": https://gitlab.freedesktop.org/pendingchaos/mesa/-/pipelines/945139

14:03 <pendingchaos> I'm guessing it's related to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24305 , so I've made a comment there

16:21 <eric_engestrom> DavidHeidelberg[m]: ^, and the fact I think we should revert this; I'll let you chime in first, in case you have a solution, but otherwise I'll revert it tomorrow :)

16:21 <eric_engestrom> (see discussion on the MR)

18:01 <DavidHeidelberg[m]> eric_engestrom: yeah, I sent revert. Damn, why we can have nice things :D

18:02 <DavidHeidelberg[m]> I usually keep the main branch of my fork up-to-date, so that why it looked fine for me when sending the MR.

18:03 <DavidHeidelberg[m]> Impose need for doing that for everyone is too high cost, I have to agree with that.