02:39 <DavidHeidelberg> anyone encountered "ci-fairy: command not found" after recent rebuilds? I didn't changed anything related to the ci-templates

02:41 <DavidHeidelberg> I prolonged a bit MESA_IMAGE_TAG but still below 128 chars

08:31 <eric_engestrom> bentiss: https://gitlab.freedesktop.org/freedesktop/planet.freedesktop.org/-/issues/22#note_2231021 trying to deal with spam on the planet repo, but I'm getting a 404 when trying to register it

08:33 <eric_engestrom> (also, this is the spam issue, so if you get a 404 when opening this link that means someone managed to register the project for spam management ^^)

08:58 <bentiss> eric_engestrom: I think this is because the project name has dots in it

08:59 <bentiss> eric_engestrom: the trick was to rely on the project id: `./damspam.py --token-file $XDG_CONFIG_HOME/damspam/user.token request-webhook 9659`

09:01 <bentiss> ouch, same thing happen on the call for damspam hide-issue :(

09:02 <bentiss> whot: ^^, if a project has dots in it, damspam is lost. I'll try to work around by changing the arguments in the webhook

09:05 <bentiss> scratch that, we are giving the full url to the issue, so changing it with the project id is going to be tough

09:22 <whot> bentiss: guess it's not regex-ing hard enough...

09:42 <bentiss> whot: OK, I think I fixed it in https://gitlab.freedesktop.org/freedesktop/damspam/-/merge_requests/51, do you want me to merge it ASAP or want to have a look at it first?

09:43 <bentiss> maybe we need some tests for that in the future...

09:49 <whot> bentiss: already wrote those, one sec

09:50 <bentiss> I forced push the test on my commit

09:52 <whot> oops, I just pushed to your branch

09:53 <whot> clearly we're not used to being awake at the same time :)

09:55 <eric_engestrom> haha

09:56 <eric_engestrom> I used the code in the MR (before whot's push), it creeated the issue but spambot says the hook is already there: https://gitlab.freedesktop.org/freedesktop/fdo-bots/-/issues/102#note_2231136

09:59 <whot> hmm, yeah, it was added twice too. question is which one is now the valid one, probably the latter

09:59 <bentiss> anyway it worked

10:00 <eric_engestrom> oh, bentiss I missed that you already had created the request issue

10:00 <bentiss> eric_engestrom: no worries

10:00 <bentiss> I can clean up that manually

10:02 <eric_engestrom> oh, so even though it said "hook already exists" it added it again?

10:02 <bentiss> yeah, it's not fully smart

10:07 <whot> that's rather a bug then, I thought we tested for that...

10:10 <eric_engestrom> the issue is not being deleted, is that normal?

10:23 <whot> eric_engestrom: the Spam tag only marks it private and links it in the tracker issue (+ blocking the reporter), so that's intended

10:23 <whot> since it's a bot action we figured it's better not to wipe a user account directly

10:23 <whot> plus with the spammers, as soon as it's no longer visible and they cannot use that acct anymore they move on anyway (they rarely use the same acct for more than a few attempts)

10:24 <eric_engestrom> yeah only blocking the user and not deleting it automatically makes sense

10:24 <eric_engestrom> but I thought the script used to delete the spam issue?

10:24 <bentiss> forced push the 2 repos to remove the extra commit related to the second webhook request FWIW

10:24 <eric_engestrom> ack, thanks for the cleanup :)

10:25 <whot> theres a damspam purge-spammers command that will delete all users. the issues are then deleted by gitlab as part of the user deletion. but we never deleted issues via damspam

10:26 <whot> anyway -> bed for me, bentiss can answer any remaining questions :)

10:28 <eric_engestrom> o/

10:28 <eric_engestrom> thanks

10:28 <eric_engestrom> and I guess I misremembered

14:04 <agd5f> Does anyone know why I keep getting my membership to amd-gfx and dri-devel disabled on my gmail account? Seems to happen like twice a week for the last month or so. Some special change I need to make on the gmail side?

14:04 <agd5f> due to excessive bounces

14:12 <bentiss> agd5f: AFAICT from the backlog here that I skeemed through is that gmail is less and less a good candidate for our services. Random bounces that makes things awful :(

14:12 <agd5f> bentiss, :(

17:16 <bochecha> Hi everyone, I have some projects of mine hosted on gitlab.freedesktop.org, I was wondering if that Gitlab instance was using hookshot to send event notifications to Matrix?

17:21 <daniels> nope, it's not

17:23 <daniels> but it looks like you can just run your own hookshot and configure that to post to whichever channels you want, if you then add the webhook in your project config

17:31 <bochecha_> ah, interesting, I'll try to see how to do that then, thank you :)

17:54 <DavidHeidelberg> eric_engestrom: around? btw. this look like feature and not an bug: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/53500918#L764

17:54 <DavidHeidelberg> I just looked at scripts and arm*_test.sh don't install ci-templates

17:55 <DavidHeidelberg> .. but it depends on rootfs which have them hmm..

19:09 <karolherbst> jenatali: ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25568

19:09 <jenatali> karolherbst: I assume you meant to ping in #dri-devel, but I thought you also still had to address static linking issues?

19:10 <karolherbst> I did

19:10 <karolherbst> (for both)

19:11 <jenatali> LGTM

19:13 <karolherbst> let's hope the current code resolves all those silly "where are my headers" bugs.. but I think it's the first time I'm confident about what we are doing there.

20:58 <eric_engestrom> DavidHeidelberg: for the ci-fairy issue, I tried to understand but I don't, especially since it randomly exists or not when retrying the exact same job

21:10 <DavidHeidelberg> eric_engestrom: haha, it doesn't exist there. replay_s3_upload_images() conditionally invoke ci-fairy

21:11 <DavidHeidelberg> if the trace hash exist and is file, it never invoke ci-fairy

21:47 <daniels> so it's presumably not copied from the container into the rootfs

22:14 <eric_engestrom> ah, that makes more sense

22:16 <DavidHeidelberg> ... and but.. downloaded container and I see ci-fairy there in /rootfs-arm64

22:17 <DavidHeidelberg> I'll compare with production container, if it's issue there too I'll merge (if it'll pass) and resolve later

22:33 <daniels> bentiss: btw, have you seen this when updating gitlab-deploy?

22:33 <daniels> Error: Failed to render chart: exit status 1: Error: template: freedesktop/templates/smtp-secret.yaml:11:15: executing "freedesktop/templates/smtp-secret.yaml" at <include "freedesktop.smtp_password" .>: error calling include: template: freedesktop/templates/_helpers.tpl:76:55: executing "freedesktop.smtp_password" at <.Values.smtp.password>: nil pointer evaluating interface {}.password

22:34 <daniels> I've tried to inject secrets/equinix-DC/freedesktop.gotmpl with smtp.password {{ readFile | fromYaml | ... }} but that still doesn't change anything :\

22:34 <daniels> wondering if it's something dumb I'm missing, or if you've got uncommitted changes, or if there's just something weird going on