00:26 <demarchi> emersion: not if someone got the reply from the mailing list and then replied to that

00:27 <demarchi> if the person was copied and got a reply directly to their inbox, then they will have the original header

00:28 <demarchi> however if the person who replied got the email from the mailing list (the same way lore.kernel.org gets a copy), then that person won't be in the Cc (since the mailing list consider they already received a copy and sending it again would be a duplicate)

00:28 <demarchi> the problem is that when someone outside the original To: / Cc: replies, they won't reply to that person

00:29 <demarchi> and it will appear like the person was dropped on purpose from the Cc

00:31 <demarchi> I learned that the hard way when a patch of mine from a year or so ago crossed 3 or 4 subsystems. The CC's were all over the place depending on who replied it and from where they got the email from

02:05 <DavidHeidelberg[m]> daniels: I have feeling that some of mine gfx-ci/linux artifacts expired after 1w, 2w? Is there chance to wipe current artifacts uploaded to S3 (currently all experiments except the latest one which I'll regenerate anyway) and made the bucket... persist 1 - 2 years? It's kernels + modules.tar.zst, so max. 100M per kernel uprev?

07:59 <daniels> DavidHeidelberg[m]: hmm yeah, it just uses the /mesa-lava/ bucket which isn't supposed to be persistent at all

07:59 <daniels> DavidHeidelberg[m]: we can keep it much longer for sure, as long as it's only the ones which actually get used ... like if we're doing automated uprevs or people are throwing 1000 versions at it, suddenly that 100MB becomes ... quite a lot

08:13 <MrCooper> demarchi: it's a per-subscription setting (so they can fix it themselves there), not a global one for the list

08:14 <MrCooper> it might be the worst mailman anti-feature

09:46 <pq> then you have those people who complain if someone dares cc them on something they get via a mailing list anyway

09:47 <pq> and then you have gmail users who get the no-dupes behavior, wanted it or not - unsure what that does to the cc lists

14:37 <demarchi> MrCooper: that assumes people know about that setting...

14:37 <demarchi> I think that the mailing list itself changing the header is a very bad behavior

14:38 <demarchi> if it could not change it and just not deliver, it would be less evil

14:40 <emersion> indeed, that's what i thought it did until now :<

22:17 <robclark> btw, speaking of mailman, is resetting list passwd a thing I need to ask an admin to do? Or is it just well hidden? (Browser remembered for all these years my freedreno@lists... pw ... but somehow that didn't carry over to new laptop and digging out old laptop to moderate all the spam is a bit annoying)

23:40 <DavidHeidelberg[m]> RPi's feel sad "ERROR: Job failed: failed to pull image "harbor.freedesktop.org/mesa/mesa/debian/arm64_test:2023-06-08-asan-arm32--2023-06-07-deqp--d5aa3941aa03c2f716595116354fb81eb8012acb" with specified policies [always]: Error response from daemon: Get "https://harbor.freedesktop.org/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) (manager.go:237:15s)" on FDO or

23:40 <DavidHeidelberg[m]> RPi farm issue?

23:44 <DavidHeidelberg[m]> tanty: ^

23:44 <DavidHeidelberg[m]> seems like RPi farm issue, nothing else seems to be affected

23:46 <DavidHeidelberg[m]> noticed in this pipeline: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/915371/builds