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