05:30 airlied: zzoon: did you ever look at intel av1?
05:32 zzoon: airlied: yes.. a bit long ago though.
05:32 zzoon: https://gitlab.freedesktop.org/zzoon/mesa/-/commits/av1_dec_anv
05:33 zzoon: film grain support is the high priority for this branch.
05:40 airlied: zzoon: I'm just playing with zink video support, and was going to look into trying it on some other hw
05:43 zzoon: I think you can use this branch with av1 video that doesn't require filmgrain.
05:47 airlied: I was pondering if we should do filmgrain with shaders at the vaapi level here
09:53 mripard: emersion, sima, pq, zamundaaa: https://lore.kernel.org/igt-dev/20240717143947.28437-1-dmitry.baryshkov@linaro.org/
09:57 sima: mripard, I wonder whether that'll lead to some test gaps
09:57 sima: like do we want to guarantee that single zpos is immutable?
10:01 sima: mripard, typed some reply
10:17 sima: tzimmermann, jfalempe I'm wondering whether we could use the fb_info flag for no panic support to eventually decide whether fbcon will be registered as one of the new kernel consoles (not vt consoles) with the new locking
10:17 sima: so that we get the guarantee that our console printing code is always run from process context
10:17 sima: the issue is a bit that this decision is another layer away in the vt code ...
10:19 tzimmermann: sima, the fb_info flag?
10:20 jfalempe: tzimmermann: the fb_info->skip_panic flags I added with https://patchwork.freedesktop.org/series/136182/
10:20 sima: tzimmermann, yeah
10:20 tzimmermann: jfalempe, sima. i'm out of the loop
10:20 sima: but one step further so that we decide in the vt console code
10:20 jfalempe: But I think it's a good idea, if panic is the only case where the new console won't fit.
10:21 sima: tzimmermann, ah I think that discussion was with javierm, not you maybe
10:21 tzimmermann: jfalempe, can we unregister panic support for a DRM device when we register fbdev support?
10:22 tzimmermann: such that panic is on by default and the fbdev code actively replaces it?
10:22 jfalempe: tzimmermann: that should be possible.
10:24 jfalempe: sima: I'm also considering writing a drm_log, to be able to log the early boot message, without relying on VT_CONSOLE and fbcon
10:25 sima: tzimmermann, other way round, we should make sure fbdev panic doesn't work because at least with the current locking it's terminally broken
10:25 jfalempe: I think it would be one of the last piece to push for disabling VT on Linux distor.
10:25 tzimmermann: sima, taking away panic messages from the console might not sit well with everybody
10:26 jfalempe: tzimmermann: with the kmsg panic screen, you will get the exact same message on the drm panic screen.
10:26 sima: tzimmermann, oh I mean only for drm drivers that do have panic
10:26 sima: *native panic support
10:28 tzimmermann: jfalempe, we know that. :) but people have their working setups and expectations
10:29 javierm: tzimmermann: yeah, we have seen that when pushing for a change proposal to use DRM panic + plymouth kernel log instead of fbcon panic + vt console
10:30 sima: yeah it would maybe make this transition a bit more gradual
10:30 javierm: there's also confusion because VT_CONSOLE only means that the kernel will use a VT as a system console (and use it to print its messages) but people thought that this would meant not having a VT console at all
10:31 sima: kinda like the current patch set from jfalempe is great since it doesn't require compile-time decision anymore for at least enabling drm panic
10:31 javierm: we had to clarify in the fedora-devel thread that with jfalempe
10:31 javierm: sima: exactly, that was based on the feedback from the fedora users
10:31 sima: javierm, the naming with both vt console and kernel console being abbreviated to console doesn't help :-/
10:31 javierm: yeah...
10:33 javierm: jfalempe: drm log could be useful indeed to close the gap of not having kernel messages between earlycon and plymouth (or systemd) redirecting /dev/kmsg to the fbcon
10:34 javierm: jfalempe: the idea would be to implement as a DRM client (like the fbdev DRM emulation) and then detach once the fbdev DRM emulation is attached ?
10:35 jfalempe: I think you won't need fbdev emulation, if you use drm-log.
10:35 javierm: jfalempe: but you do need for fbcon right ?
10:35 javierm: otherwise you will take from users their precious VT console
10:36 jfalempe: the final goal is to have user-space console. but it could be better to do that step by step.
10:37 jfalempe: so yes drm-log will stop logging when the first userspace apps open the drm device, or when fbcon attach to fbdev emulation.
10:37 javierm: jfalempe: agreed on final goal to completely disable CONFIG_VT
10:37 jfalempe: it should also be disabled when quiet is on the kernel command line.
10:53 mripard: sima: great, thanks :)
12:04 tzimmermann: jfalempe, i'm going to send out an update to the vblank patch immediately
12:05 jfalempe: tzimmermann: yes you can remove the iclear write ;)
12:05 jfalempe: if it's the only change, you can keep my review-by, no need to send a new version.
12:06 tzimmermann: jfalempe, i see
12:07 tzimmermann: jfalempe, i intend to just write the VLINE bit. the reserved bits are supposed to be zero, so i don't want to write 0xffffffff. and if we ever use another of those interrupts, we'll have the necessary clear op already in place
12:08 jfalempe: tzimmermann: that's fine for me too.
12:13 zmike: eric_engestrom: or maybe best to just talk here since I don't think the resolution will be so simple
12:14 eric_engestrom: ack
12:14 eric_engestrom: but also I'm kinda lost so not sure how much I can help :]
12:14 zmike: yeah it's not a simple problem
12:15 zmike: maybe one thing that's easier to focus on is the loader changes
12:15 zmike: src/loader/loader.c now has a function which directly calls symbols from targets/dri
12:15 zmike: so it needs linkage there
12:15 zmike: but libloader is used by a ton of different components, which leads to undefined symbols in all those cases
12:16 zmike: I think dlsym(NULL, "symbolname") to pull from the current process's symbol table would be better, but then even though the dri frontend symbols are declared PUBLIC they aren't accessible
12:18 eric_engestrom: `gnu_symbol_visibility : 'hidden',`
12:19 eric_engestrom: zmike: sounds like you need to change this? ^
12:19 zmike: that explains it
12:20 zmike: though like I said
12:20 zmike: the functions are declared with PUBLIC
12:20 zmike: which explicitly sets visibility("default")
12:20 zmike: so shouldn't that override -fvisibility=hidden?
12:25 eric_engestrom: I'm not sure what overrides what
12:26 zmike: I'm reasonably sure the compiler flag just sets the default visibility and it's up to the code to explicitly make things public
12:26 zmike: which also makes sense considering the current loader dlsyms them
12:27 eric_engestrom: > With -fvisibility=hidden, you are telling GCC that every declaration not explicitly marked with a visibility attribute has a hidden visibility.
12:27 eric_engestrom: (from https://gcc.gnu.org/wiki/Visibility)
12:27 zmike: yeah
12:29 zmike: ugh I guess maybe the best solution maybe IS trying to split this code out of libloader again
12:29 zmike: I made an attempt last night and it...didn't go well
12:30 karolherbst: does it work if you declare everything PUBLIC in the linker script?
12:30 zmike: the symbols are already PUBLIC in the code
12:31 karolherbst: so you haven't tried it
12:31 zmike: I'm not sure what you're proposing
12:31 karolherbst: checking the linker script, because I think it can overwrite whatever you specify in code
12:32 zmike: what is the linker script in this context?
12:32 karolherbst: -Wl,--version-script
12:32 karolherbst: e.g. dri.sym for target/dri/
12:33 zmike: ah
12:33 zmike: the symbols are public in that already
12:33 zmike: so I guess I have tried it
12:33 karolherbst: okay
12:33 karolherbst: yeah, then it's odd
12:36 karolherbst: though I also don't know how much you've reworked. that script needs to be passed and correct when linking the final so file
12:36 zmike: I haven't changed anything related to that
12:39 zmike: oh dlsym fails because libgallium isn't loaded
12:39 zmike: tremendous
12:39 zmike: htf...
12:40 zmike: ah right, because doing dlsym removes the linkage
12:40 zmike: fml I hate build systems
12:40 karolherbst: uhhh... pain
12:41 karolherbst: there was this linker flag...
12:41 karolherbst: --whole-archive?
12:44 zmike: maybe I'm thinking about this wrong
12:47 zmike: maybe this will work
12:47 zmike: pray for me
12:57 daniels: oh no, I need jenatali
12:57 daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61205465#L888 is a pile of ??
12:57 daniels: especially given that it works just fine in the piglit build https://gitlab.freedesktop.org/mesa/piglit/-/jobs/61195851#L3817
12:58 daniels: though that is using python 3.10 rather than 3.12
13:00 daniels: of course, an actual error message would be helpful ...
13:08 jenatali: Oh you probably didn't see my messages because NickServ didn't tell me I lost connection
13:08 jenatali: I see some overflows due to negation later on in the log, but they're just warnings afaict
13:15 daniels: yeah, I just tagged you in the MR with the actual failures pulled out
13:15 daniels: though it seems like it’s always missing the final line which tells you the most interesting detail, which is cool
13:16 daniels: sorry to punt this on you but my Windows machine is long gone
13:17 jenatali: Yeah I understand
13:17 jenatali: It's the price I pay for keeping Windows in CI and it's worth it
13:26 daniels: jenatali: <3
13:31 mairacanal: mripard, tzimmermann: have you had the time to take a look at this e-mail? https://lore.kernel.org/dri-devel/0f5cf733-7f22-4b93-b13e-08916aa3f152@igalia.com/ I was wondering if we could get those patches cherry-picked
13:34 tzimmermann: mairacanal, hi. in cases like this it's better to first merge all fixes into drm-misc-fixes; then backmerge into drm-misc-next and apply the rest of the patchset on top
13:36 tzimmermann: if we cherry-pick them now, we'll likely run into merge conflicts in drm-tip and drm-next
13:36 mripard: mairacanal: to add to what tzimmermann said, is it actual fixes (like, do they fix a bug that was reported somewhere), or are they just to improve the current code without a clear bug?
13:36 tzimmermann: sima, airlied, ^
13:36 mripard: in the latter case, there's no need for them to go through drm-misc-fixes
13:37 tzimmermann: mripard, will someone pick them up for drm-fixes?
13:38 mripard: tzimmermann: what do you mean?
13:38 tzimmermann: AFAIU these are fixes for upstream. they will now sit in drm-misc-next or drm-next for a while
13:39 tzimmermann: and they should go via drm-misc-fixes->drm-fixes->upstream instead
13:39 sima: tzimmermann, yeah backmerge would have been better, but since they're already in drm-misc-next cherry-pick with the dim wrapping is the way to go
13:39 sima: mairacanal, ^^
13:39 mripard: tzimmermann: not necessarily
13:39 mripard: if they don't fix bugs, they are better off in drm-misc-next anyway
13:39 tzimmermann: mairacanal, right, what sima said.
13:39 sima: and yeah if it's just polish, no need to put into -fixes
13:40 sima: but at least from the summaries doesn't sound like that
13:40 tzimmermann: do a 'dim cherrypick' to get them into drm-misc-fixes. the dim command will add additional information
13:40 mripard: tzimmermann: also, we're supposed to do the cherry-picks ourselves :)
13:40 sima: ah yes that too, in the past it resulted in some fun when commmitters did that
13:41 tzimmermann: ok, i'll volunteer :)
13:41 mripard: tzimmermann: but really, if there's no bug associated to it, they shouldn't be in drm-misc-fixes at all, so we should clear that up first
13:41 tzimmermann: mairacanal ^ you what patches 1 to 5 cherry-picked ?
13:43 mairacanal: yeah, if possible
13:43 tzimmermann: mripard, they have fixes tags AFAICT
13:43 tzimmermann: mairacanal, processing...
13:43 mripard: which means that there was something to fix in the original commit, not that there's a bug.
13:45 mairacanal: those patches are avoiding memory leaks and avoiding userspace to perform invalid actions
13:45 tzimmermann: mripard, i don't understand what you mean. the commit message says "drm/v3d: Prevent out of bounds access in performance query extensions" and the fixes tag refers to a patch that is in v6.9. that is clearly material for drm-misc-fixes
13:46 mairacanal: currently, userspace can access out of bounds memory, which I don't believe is ideal :(
13:46 mripard: mairacanal: I guess the question is, does it?
13:47 mripard: it can do that, sure, but if it doesn't, there's no rush to merge it anyway
13:47 mairacanal: I don't have control over userspace
13:48 mairacanal: I cannot guarantee that every process using this IOCTL is passing a valid number of perfmons
13:49 mripard: let me rephrase then. What's the reproducer?
13:49 sima: they all look like real -fixes material to me
13:49 sima: maybe an evil igt would be nice, maybe that even exits
13:50 mairacanal: mripard, it is just a matter of submitting the IOCTL with a invalid number
13:51 mairacanal: Mesa isn't doing it, because I coded the implementation for this IOCTL (and this is probably why I didn't think about this verification)
13:52 mairacanal: But I can't guarantee that every user space program using this IOCTL knows about this and it would end up with a invalid address access
13:54 mripard: my point is: is a theoretical bug that we haven't seen anywhere in real life is worth creating merge conflicts, history and bisection mess that will frustrate people. it's a judgement call.
13:55 mripard: especially since it's going to be backported to every relevant stable kernel anyway, so it's just a matter of weeks
13:56 mairacanal: I could understand this point if we were talking about a theoretical race condition
13:57 mairacanal: But it's not the case, it is a bug that allows userspace to pass a number of perfmons bigger than the array we allocate in memory
14:03 mairacanal: Also I believe those 5 commits apply fine in -next-fixes and -fixes
14:08 zmike: jenatali: good news, I think my MR is okay on Windows now
14:08 jenatali: zmike: great
14:10 mairacanal: sima, mripard, tzimmermann: so, it won't be possible to cherry-pick the commits, right? or they can be cherry-picked?
14:10 mripard: mairacanal: again, these patches should probably have been applied to drm-misc-fixes indeed. I'm not discussing whether the fault is there. I'm discussing whether it's worth cherry-picking.
14:11 tzimmermann: mairacanal, i cherry-picked and built them. i'm going to push them in a minute. there's possible upside and little downside to it
14:11 jenatali: zmike: after that change goes in I think we might be able to de duplicate some of the egl backends
14:11 zmike: jenatali: yes, I'm planning to slowly delete all the interfaces
14:11 zmike: and eventually glx/egl/gbm will just be symlinks to libgallium
14:11 jenatali: Wonderful
14:11 zmike: and maybe the code will even be readable
14:12 jenatali: Well, on Windows we'll still want egl to be a separate dll
14:12 zmike: you do you
14:13 mairacanal: mripard, i didn't apply them to -fixes because they are the beginning of a 11 patches series. if they were applied at -fixes, i wouldn't be able to have the rest of the series on -next
14:13 mripard: mairacanal: of course you would have been
14:13 mripard: not at once, though
14:14 mairacanal: i was a bit in doubt about what to do, but i read "If you’re unsure, apply your patch here, it can always be cherry-picked to one of the -fixes branches later on" from the maintainers docs
14:14 mairacanal: and i thought that cherry-picking could be a reasonable approach
14:14 mairacanal: sorry about the disturbance, i'll try to approach such situations differently in the future
14:15 mairacanal: tzimmermann, thanks about it!
14:16 mripard: mairacanal: sorry, I'm not trying to be picky about it. cherry-picking has real downsides though, so for bugs/regressions we have a clear reproducer, it's a clear call
14:16 mripard: for issues that *might* be there, it's less clear
14:16 mripard: and I guess we're in that grey area
14:20 mairacanal: i also apologize, this is my first time dealing with such situation and i didn't know about the cherry-picking downsides
14:31 rodrigovivi: mairacanal, the drm-tip rebuild is broken on some v3d conflicts... could you please help there?
14:34 mairacanal: checking now
14:40 tzimmermann: rodrigovivi, i'm working on it
14:40 rodrigovivi: thanks
14:42 mairacanal: thanks tzimmermann
14:49 tzimmermann: rodrigovivi, should be good now
14:50 tzimmermann: mairacanal, done
14:52 mairacanal: thanks tzimmermann, sima, and mripard for all the help
14:52 tzimmermann: mairacanal, no worries
16:14 jenatali: daniels: "OverflowError: Python integer -2147483648 out of bounds for uint32"
16:17 jenatali: Looks like we're pulling in a new version of numpy
16:19 daniels: I wonder why that doesn't trigger on arm32
16:22 daniels: right, so I get endless spam of:
16:22 daniels: /home/daniels/mesa/piglit/generated_tests/gen_intel_shader_integer_functions2_tests.py:321: DeprecationWarning: NumPy will stop allowing conversion of out-of-bound Python integers to integer arrays. The conversion of -9223372036854775808 to uint64 will fail in the future.
16:22 daniels: For the old behavior, usually:
16:22 daniels: np.array(value).astype(dtype)
16:22 daniels: will give the desired result (the cast overflows).
16:23 daniels: return [np.uint64(x) for x in srcs]
16:23 jenatali: What numpy version do you have?
16:25 eric_engestrom: zmike, daniels: do we want to merge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27607 now?
16:25 eric_engestrom: /me feels weird about pushing changes to someone else's MR and then merging it, feels like someone else should do the second part 🫣
16:26 jenatali: daniels: Looks like NumPy 2.0 just hit stable a month ago
16:26 daniels: jenatali: numpy 1.26.4 on python 3.12
16:26 jenatali: Yeah that'll do it
16:26 daniels: eric_engestrom: there you go, no need to feel weird ;)
16:27 jenatali: If I set up a new Python locally, without specifying explicit versions, I get NumPy 2.0
16:27 eric_engestrom: daniels: ta!
16:29 jenatali: daniels: https://numpy.org/doc/stable/numpy_2_0_migration_guide.html#changes-to-numpy-data-type-promotion
16:31 zmike: eric_engestrom: I've been doing it to ajax's MRs for years
16:31 zmike: it's the only way
16:31 eric_engestrom: haha
16:32 jenatali: daniels: We can either try to fix piglit for numpy2.0 or we can freeze numpy in the Windows container builds to 1.26.x
16:33 daniels: jenatali: yeah, should we freeze to 1.26.2 for now and then figure out how to fix the tests? I was poking around a little bit but have just realised I have no 32-bit system to check anything on rn
16:34 jenatali: Do we need a 32-bit system? These VMs are x86-64?
16:36 daniels: just re-read the notes and indeed it shouldn't really be material; I was worried that NumPy changing its precision and not preserving through bigint may have been an issue on 32-bit, but I don't think it should be
16:36 jenatali: daniels: As for the build container failure... C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\yvals_core.h(898,1): error: static assertion failed: error STL1000: Unexpected compiler version, expected Clang 17.0.0 or newer.
16:37 jenatali: Apparently the latest minor VS version includes new headers that are incompatible with the older clang we're using. Upgrading LLVM/Clang is probably doable but might be problematic due to the typed pointer stuff karolherbst has been fighting with...
16:37 daniels: heh ... https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/222
16:37 daniels: jenatali: oh no.
16:38 daniels: jenatali: is there any way to pull an older msvc?
16:38 jenatali: Probably. I'm also looking to see if we can suppress this error
16:39 jenatali: Ah: _ALLOW_COMPILER_AND_STL_VERSION_MISMATCH
16:51 jenatali: daniels: Workarounds pushed
16:52 daniels: jenatali: did you just push to my branch?
16:52 jenatali: Yep
16:52 daniels: nice! thanks so much
17:07 jenatali: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61220681 didn't rebuild the container. You'll need to re-bump the tag for it, or else delete the image so it gets rebuilt. That's where numpy is getting pulled in
17:11 daniels: jenatali: yeah, literally just re-pushed that
17:18 daniels: jenatali: mm, libclc still unhappy :( https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61220682
17:19 eric_engestrom: zmike: !29771 is breaking llvmpipe/softpipe (and virgl but I think it runs on llvmpipe so that would be why)
17:19 jenatali: daniels: :(
17:21 jenatali: Oh, weird, it's using actual MSVC instead of clang-cl? One sec...
17:22 daniels: the only thing I can think of that's weird is that we have 'z.lib' on the command line and does that actually exist, or is it zlib handling being somehow broken?
17:23 daniels: that comes in via LLVM system libs in libclc's cmake
17:23 jenatali: I'm trying to reproduce the CI environment. My local build was using clang-cl
17:31 jenatali: Nope even when I switch to MSVC it still passes for me...
17:34 daniels: hngh
17:34 daniels: I really wonder why ninja doesn’t bother capturing the salient errors
17:34 daniels: ‘how is line ending formed’, I guess
17:36 zmike: eric_engestrom: ffffffffff so close
17:37 eric_engestrom: haha
17:37 daniels: it is objectively funny that you broke zink-lvp
17:39 eric_engestrom: daniels: zink-lvp works though
17:39 eric_engestrom: (which is weird since most of llvmpipe is broken)
17:40 daniels: oh, maybe that was the other MR
17:40 daniels: (the DRI3 one)
17:40 eric_engestrom: wait that's the thing though, lavapipe works but llvmpipe/softpipe is broken
17:40 eric_engestrom:got confused with acronyms for a minute
17:40 eric_engestrom: I'm talking about !29771 "glx/egl/gbm: link directly to gallium"
17:54 jenatali: daniels: It's a gitlab bug that's causing the errors to be missing. The raw view has it: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61220682/raw
17:54 jenatali: LINK : fatal error LNK1181: cannot open input file 'z.lib'
17:59 jenatali: Looks like maybe LLVM_ENABLE_ZLIB ?
18:05 jenatali: I don't understand what changed but I can work around it at least
18:08 jenatali: Oh cool
18:13 daniels: eric_engestrom: yeah, I’m talking about a DRI3 MR
18:13 daniels: jenatali: oh! I didn’t even think of looking at the raw view … how bizarre
18:15 jenatali: daniels: I pushed an alternate workaround to your MR and kicked off the first container build
18:18 daniels: jenatali: thankyou so much
19:00 Lynne: is there's anyone here who's truly pedantic about the vulkan spec, is dedicated allocation meant to work with host mapping?
19:01 Lynne: because with host mapping, you're required to use the memoryTypeBits given by vkGetMemoryHostPointerPropertiesEXT, which disregards the bits that vkGetBufferMemoryRequirements2 returns and you're also meant to use
19:02 Lynne: or are you supposed to take the AND of the flags?
19:36 eric_engestrom: daniels: the log viewer is quite buggy, and gitlab is not going to fix it, instead they're working on a replacement once (which also won't have the 500KiB log limit); you can already try it by adding `/viewer` to a job log url (the same url you would add `/raw` to, to get the raw log)
19:40 jenatali: Oh looks to be a problem with stdout vs stederr
19:41 jenatali: stderr*
19:57 zmike: eric_engestrom: I did a test pipeline and I think it should merge this time
19:57 zmike: hopefully
19:58 eric_engestrom: zmike: 29771?
19:58 zmike: yes
20:00 eric_engestrom: 💪
20:00 zmike: 🙏
20:08 daniels: eric_engestrom: this is really good to know, thanks
20:22 jenatali: daniels: libclc and piglit both built successfully in !29649
20:52 karolherbst: jenatali: well.. you can carry the spirv-tools patch and the MR
20:52 karolherbst: maybe we should just merge the mesa MR
20:52 karolherbst: worst case the method name changes
21:18 zmike: eric_engestrom: !!!
21:18 eric_engestrom: for 29771? I was monitoring it :)
21:18 eric_engestrom: congrats!
21:19 eric_engestrom: that said... radeonsi job (https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61229674) filled with hundreds of `MESA-LOADER: failed to open radeonsi: driver not built!)`... looks like something's wrong :(
21:20 zmike: hmmmmm
21:21 eric_engestrom:needs to go to sleep now though
21:21 zmike: seems like that has to be spurious though considering all the baselines are still valid
21:21 zmike: something for tomorrow for sure
21:22 eric_engestrom: daniels: jenatali's windows changes look reasonable to I'm sending !29649 to Marge
21:23 eric_engestrom: zmike: thanks for having a look, but yeah the tests are sill passing so it's likely just that we shouldn't print the message
21:24 eric_engestrom: if I don't see anything else in https://gitlab.freedesktop.org/mesa/mesa/-/milestones/47#tab-merge-requests tomorrow morning I'll make the branchpoint :)
21:24 zmike: it seems like it isn't harmful, at the least, but it's confusing how it's reaching that point
21:24 eric_engestrom: agreed
21:25 zmike: sidebar: any idea what's going on with llvm updates?
21:25 zmike: 15 is so old I can't even install it on my distro
21:26 jenatali: What about llvm updates?
21:27 airlied: do we rely on the base distro to update it?
21:27 eric_engestrom: zmike: I assume you mean bump the version used by CI? can you create an issue for this?
21:28 zmike: ok
21:28 eric_engestrom: we can use whatever debian has, so check there too
21:28 eric_engestrom:is off for real this time