01:35 mareko: where did the raven CI job go? I don't see them in the CI anymore
02:19 maratman: I looked a little, and lkl - Linux kernel library is fairly interesting, I think with mixture of mono and limbo, plus some enhancements to all I could offer on long run, something amazing, some gaming extreme performance distro.
02:26 mareko: FLHerne: RADEON_NOOP=1?
03:06 mareko: how did you make chanserv do that?
03:12 airlied: akick #dri-devel add *@*.elisa.ee
03:12 airlied: is what I did last
03:13 mareko: thanks
03:27 emersion: airlied: this bans a loooot of users...
03:34 airlied: emersion: yeah it sucks, but whack-a-mole sucks more
03:35 emersion: i suppose we can always add ban exemptions if we need to
06:23 dj-death: gitlab apppears to be struggling quite a bit
06:25 daniels: dj-death: wfm
06:32 dj-death: might be my internet somehow
07:23 daniels: the intel machines have been stuck with an enormous backlog for the last few hours; it's recovering now but could be bumpy for a little while
07:30 dj-death: something odd again
07:30 dj-death: like :
07:30 dj-death: git fetch "git@gitlab.freedesktop.org:nchery/mesa.git" 'perf-fix/anv-igfx12-rc-ccs'
07:30 dj-death: git@gitlab.freedesktop.org: Permission denied (publickey).
07:31 dj-death: and now it works
07:37 daniels: cf. #freedesktop
07:39 dj-death: ah right
07:53 mlankhorst: remote: GitLab is not responding
07:55 dj-death: mlankhorst: security update
07:55 mlankhorst: ah k
07:55 mlankhorst: airlied: could we ban *.ee?
08:00 pinchartl: mlankhorst: or * ? that would solve the problem once and for all :-)
08:01 airlied: mlankhorst: we did ban ee once before though I think he gets ipv6 every so often
08:01 pq: That would be really harsh, condemning a whole country for one person. And then they come through IPv6 without DNS.
08:39 mlankhorst: pq: It's only 1.3 million people though. :)
08:45 mlankhorst: My guess is banning the whole ip range of estonia, *.ee and variations of all ip addresses from the range in ident would probably solve most
08:47 DemiMarie: pinchartl: I agree with pq, banning a whole country is unreasonable.
08:48 MrCooper: yeah, up there with some US ISP rejecting all e-mail from Europe as spam
08:48 DemiMarie: mlankhorst: what if one of those 1.3 million people needs to ask a question?
08:48 pq: pinchartl was joking, that would ban everyone.
08:48 mlankhorst: Would solve the problem too!
08:48 DemiMarie: Replied to wrong persob
08:49 DemiMarie: s/person/person/
08:49 FLHerne: how about closing the channel and replacing it with a Facebook group
08:49 DemiMarie: FLHerne: Matrix >> Facebook
08:50 mlankhorst: or a mastodon hashtag
08:50 FLHerne: DemiMarie: yeah, but that could be misread as a serious suggestion :p
08:50 DemiMarie: FLHerne: I assumed your suggestion was serious!
08:51 FLHerne: judging by the Matrix-bridge-spam problems on Libera I'm not sure Matrix has got effective banning worked out either
08:51 pq: joking is hard in the internet, I try to avoid it
08:51 DemiMarie: Not your fault FLHerne, I have a hard time telling if something is serious or joking.
08:51 mlankhorst: I don't see anything on mstdn.social if I look for #dri-devel, could always begin there
08:51 mlankhorst: mastodon*
08:51 DemiMarie: pq: or add an explicit tone marker
08:52 psykose: every friend i've had on matrix in even small <20 person groups deals with endless harassment/targeted spam issues with no way to moderate it
08:52 psykose: they definitely don't have anything figured out :p
08:53 pinchartl: we should go back to BBS. it charged based on the time spent connected, that would become too expensive for spammers
08:53 DemiMarie: FLHerne: I don't think one can have effective banning without either proof of work, CAPTCHAs (easy to circumvent with ML models), or manual approval
08:54 psykose: captchas are definitely broken in current year
08:54 ccr: I think it is highly unlikely that the "usual suspect" would be deterred by any of those either, apart from manual approval.
08:54 emersion: proof of work, CAPTCHAs don't help here
08:54 ccr: he has mental issues and is determined to bring his wisdom here
08:55 mlankhorst: not sure it's actually wisdom now or just upset about being banned
08:58 pinchartl: should we file a legal complain ?
08:59 DemiMarie: Against who?
08:59 ccr: to where? what authority? all we (probably) know that he might be from estonia
08:59 ccr: but he is often using some kind of VPNs or something
09:00 pq: I first tried to make sense out of them more than 20 years ago, then soon learnt it was futile.
09:00 pq: hmm, no, not more than 20. Around 15 maybe.
09:01 DemiMarie: Same person?
09:02 pinchartl: ccr: Estonian authorities possibly. the chances it would succeed are fairly low though
09:08 pinchartl: or contacting the abuse support from his ISP/VPN provider
09:52 pq: DemiMarie, seems so
10:01 DemiMarie: pinchartl: if the VPN provider is a good one they won‘t keep logs
10:39 pinchartl: DemiMarie: I don't think it's useful to speculate
13:09 Junie_: Hello everyone, My name is Isoken Ibizugbe and I am an outreachy applicant. I look forward to working on open source software with the linux community.
13:30 mripard: Junie_: welcome :)
15:16 MTCoster: Am I going crazy or is the doc comment on list_move_to() backwards? "in front of" seems to imply item is inserted *before* loc, but it's actually added *after*
15:17 daniels: MTCoster: they're big-endian lists
15:21 MTCoster: So "in front of" means "closer to the tail"?
15:25 daniels: sorry, that wasn't a serious reply :\
15:45 ccr:boogies.
15:49 gfxstrand: NGL, I kinda want nir_var_shader_patch to be a thing...
16:23 MTCoster:definitely didn't think big-endian lists were a real thing...
16:37 robclark: lol big-endian lists
16:37 donaldrobson: The documentation for drm_syncobj_find_fence() says it's "just a convenience function that combines drm_syncobj_find() and drm_syncobj_fence_get().", but the implementation does a bunch of other stuff after drm_syncobj_fence_get() that doesn't look unimportant. Is the doc text wrong?
17:03 mattst88: lol
17:23 cmarcelo: people interested in ralloc, looking for thoughts on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25482?
17:26 cmarcelo: gfxstrand: re: nir_var_shader_patch, seems to be in line with what we've done for other things like task mem, rt payload data etc. what's worrying you, just the churn on the code?
18:00 gfxstrand: Yeah, mostly