Re: Proposal: Mesa 25.3.3 backport for trixie-backports

stornic56 <[email protected]> Sat, 13 Jun 2026 13:00:02 +0000
Newsgroups gmane.linux.debian.backports.general
Message-ID <ZdHZB5EptcbMSzh5o02tCN6k0fMzelXk0S70JPJIP6XztlQHwf0DNqlClQJgqtp75jNjJW7Au8s5dx0R1I1hv42xLOr-L-nEhgN0qI5HozI=@proton.me>
Hi Paul,


Thanks for the clarification on the policy.


I understand the rule, but I'd like to make a case for 25.3.3:


1. The "too intrusive" backport is done. The security team marked CVE-2026-=
40393 as ignored for Trixie because the fix was deemed too intrusive to bac=
kport into 25.2.6. I've already done that work: 25.3.3 includes the upstrea=
m fix (MR !39866) and it's not intrusive at all, it's just a proper point r=
elease.


2. Dylan A=C3=AFssi hasn't touched mesa in trixie-backports for 6 months. B=
ug #1132617 has been open since April with no response. The backports guide=
lines allow a volunteer to step in when the maintainer is unresponsive.


3. The package required real work: LLVM downgrade, dependency fixes, meson =
patch, CVE patches, and FTBFS fixes for stack_array.h and rusticl. It's bee=
n running on my Arc B580 for days with Vulkan 1.4.309 and OpenGL 4.6. It's =
ready for upload.


4. Mesa 26.0.8 is extra work. I'm not opposed to working on it if the team =
requires it, but that means redoing the LLVM adaptation and dealing with wh=
atever new issues 26.x brings. An exception for 25.3.3 gives Trixie users a=
 secure update now while a 26.x backport is being prepared.


Since the guidelines allow for exceptions discussed with the team, just let=
 me know what the next step should be.

Best regards,
stornic56