09:16Dharma: Hi all, I was integrating a reviewed patch and followed these steps: dim checkout drm-misc-next dim b4-shazam 4e7faa33-6e39-4b9c-b5df-bccaa9cbb1cc@microchip.com dim checkpatch dim sparse dim rebuild-tip Now that the local tip is updated, can I do dim push-branch drm-misc-next?
09:20Dharma: Hi @tzimmermann
09:21tzimmermann: Dharma, first: you never rebuild the local tip. it's alwaysthe public drm-tip branch (maybe except when using -d)
09:22tzimmermann: you should apply your patches to drm-misc-next. i've never used b4-shazam, but it appears to be the command to do that.
09:23tzimmermann: you may want to rebuild your drm-misc-next, so that you know it works
09:23tzimmermann: when you're ready, run 'dim push-branch drm-misc-next' to send out your patch.
09:24tzimmermann: push-branch adds your patch to the public drm-misc-next branch and also rebuilds the drm-tip
09:24tzimmermann: from your description, you should be good to go
09:24Dharma: yes, I applied the patch on drm-misc-next branch. yes, b4-shazam picks the reviewed-by tag and appends my signed-off by tag too
09:24Dharma: Thank you so much
09:25tzimmermann: Dharma, np
09:26tzimmermann: a manual 'dim rebuild-tip' is for cases where you had to resolve a merge conflict. but that's a different story
09:31Dharma: Roger that
10:12RobHughesArm_: Hi, looking for a review in llvmpipe "llvmpipe: work around WSL1 missing memfd_create()" - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37679
11:26karolherbst: okay, so the mesamatrix developer would be interested in moving the generation of the page into mesa and I was wondering what would be the best way to approach this. Currently the project creates a database of stuff and each new run builds upon that
11:36Company: I remember people telling me they don't like that it involves extra maintenance of docs/features.txt when that info is better available by querying the driver
11:37Company: and pointing me towards gpuinfo.org for accurate infos
11:44karolherbst: well depends on what you are after. But I think maintaining a feature matrix properly does have benefits especially for rare devices where you won't find entries on at gpuingo
11:44karolherbst: *gpuinfo
11:44zmike: I like this step since it moves us closer to having all of that be autogenerated in some way
12:39alyssa: zmike: +1
12:40alyssa: I would love to see autopopulates mesamatrix via drm-shim, but ingesting mesmatrix into mesa is step 1 of that anyway so +1 from me
12:40alyssa: I'm skeptical of the pile of PHP in there, though
12:41alyssa: the "way" i'd expect this to work would be python running as part of the docs script
12:43alyssa: I'm unsure what problem would be solved by sticking it as-is (bespoke php) in the repo
12:43alyssa: although I guess we can install php in CI and do it as a static build anyway
14:15zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37766
14:15zmike: or anyone, really
14:32tomba: Any maintainer to check https://lore.kernel.org/all/20251001-xilinx-formats-v6-0-014b076b542a%40ideasonboard.com/ ([PATCH v6 00/11] drm: Add new pixel formats for Xilinx Zynqmp)? It's been unchanged for half a year now. I'd like to get it merged, but it has changes to the core framework.
16:25karolherbst: alyssa: the issue is, that atm it creates a database of previous commits. Anyway, I brought it up because the dev apparently doesn't have a lot of time and I changed the layout of the rusticl stuff and apparently the server that it runs on needs to be upgraded and....
16:25karolherbst: but I think if somebody wants to rewrite all of it nobdy would mind
16:31alyssa: karolherbst: yeah probably needs a rewrite but I ain't signing up
16:32alyssa: I'm too busy, these corp trainings aren't going to complete themselves ;)
16:32karolherbst: well at least it's not intended to be run as a dynamic php, it's all static generated already
16:32karolherbst: *statically
16:33karolherbst: uhh don't remind me of corp trainings 🙃
16:44Leftmost: ~~There are a thousand static site generators in Rust.~~