According to the backports guidelines [1], it is required to update backports when changes in testing are done. Of course, this is still volunteer work, but it would still be nice to have mesa 26.0.x in Debian trixie-backports [1] https://backports.debian.org/Contribute/
Am Fr., 3. Apr. 2026 um 23:09 Uhr schrieb Charlemagne Lasse <charlemagnelasse@gmail.com>: Can somebody check if my understanding is correct and packages uploaded to Debian backports should get updated when a new version hits testing?
Good morning, I do not think it is that simple. The main point is that bpo is not fire-and-forget. - If you upload you will need to support it. However that does not imply that bpo must strictly track testing. There can be reasons to have foo v2 in stable and keep bpo at v3 although v4 is available in testing. e.g. v4 breaks a huge number of rdeps but v4 doesn't. Or if v4 is at 4.0 and experience shows that a little bit of extra waiting time before upgrading foo has not hurt in there past. Imho a bpo maintainer may make judgement calls like these. cu Andreas
Hi, That's not my understanding of [1] this: """ This means, you have to keep track of the changes in unstable, update your backport when a new version enters testing... """ I've always understood that backports is supposed to follow testing, not some older version that the maintainer likes. If there are worries about the backport, there should be worries about it migrating to testing too (and it should have been hold in unstable longer, or should have been uploaded to experimental). If it breaks stuff, a +reallyv3 version should be in unstable/testing too. I assume the backport ftp-masters can confirm. Paul [1] https://backports.debian.org/Contribute/
Hi, Am 17.05.26 um 09:10 schrieb Paul Gevers: I've only ever did this on changes where the bpo user has an effect on. For sid-only transition changes there's no need to update a backport. (see e.g. liborcus' backport, anything newer than what is backported is for the libparquet filter which won't be enabled in backports as there is no apache-arrow there, and backporting that one is nozt possible without backporting cython3 and whatever else...) The instructions even say "Don't backport minor version changes without user visible changes or bugfixes" And if a new mesa, as implied, breaks stuff and needs a big transition, this falls into the "That said, Debian Backports Policy does not allow backports of libraries that would break all dependent packages in stable (eg: new Qt 5.x releases), and by virtue of this, Debian Backports are considered generally safe when used as intended on an individual package basis." Regards, Rene
jftr, I did that for backporting harlequin and the only parts that are needed are apache-arrow (with apache-arrow-testing and apache-parquet-testing) and cython3, nothing more: https://packages.fastforward.debian.net/#apache-arrow jftr, it doesn't (I'm using backported mesa 26.1 since ~2 weeks now on multiple systems). Regards, Daniel
Hi Rene, While I think this isn't according to the letter of the comment I quoted, I think it is according to the spirit. What you describe here is quite different from the v3 vs v4 example of the mail I replied to. Hmm, that sentence is a bit ambigue. I was reading it as "don't backport a package where the delta between testing and stable is without user visible changes or bugfixes" but I see what you mean too. (Maybe the backports ftp-masters can clarify the sentence on the web page). So it should be removed from bpo instead of not updated? This is more of a question to those that are in charge of the backports policy. Paul
Hi, Am 17.05.26 um 10:17 schrieb Daniel Baumann: Ah, thanks. JFTR, I probably won't do it anyway since I would then responsible for maintaining the backport and I don't know anything about cython (and don't really care about it either, for apache-arrow I just care about libparquet :)) But if you want to do that (together with harlequin) in official bpo, feel free :) But that is getting off-topic in this bug :) Regards, Rene
replaced Debian backports with Debian fastforward. If you also want to do this, you need to download the key: ``` mkdir -p /etc/apt/keyrings/ curl \ https://deb4.fastforward.debian.net/debian-fastforward/project/pgp/fastforward-debian-13-trixie-signing-key.pub \ -o /etc/apt/keyrings/fastforward.asc ``` Then enable it via /etc/apt/sources.list.d/fastforward.sources (see attachment). And then some packages (according to https://packages.fastforward.debian.net/#mesa tree) have to be pinned using /etc/apt/preferences.d/mesa (see attachment)
Hi everyone, I've been following the discussion regarding the Mesa 26 transition for trixie-backports. While the team evaluates the blockers for the major 26.0 upgrade, I would like to provide a tested, ready-to-use intermediate update. I have successfully built and tested *Mesa 25.2.8-2* in a clean Debian Trixie (amd64) environment. This allows the archive to move from 25.2.6 to the latest stable point release of the 25.2 branch without requiring major updates to the base system. My changes involve two minimal adjustments in debian/control.in to ensure compatibility with Trixie's current packages: 1. Lowered libdrm-dev and runtime dependencies to >= 2.4.124-1. 2. Adapted spirv-tools-dev to spirv-tools (>= 2025.1~rc1-1) due to the package renaming in the current archive. Attached is the debdiff for *mesa_25.2.8-2~bpo13+1*. It installs cleanly and runs perfectly (tested with llvmpipe). I hope this helps as a reliable fallback while the transition to Mesa 26 is finalized. Best regards,
Dear Dylan, Timo, I'm the same person who submitted the Mesa 25.2.8 backport (#50). I now offer a fully tested backport of Mesa 25.3.3 (including security fixes up to 25.3.6) for trixie-backports. Key adjustments for Trixie: - LLVM 21 → 19 - libdrm-dev >= 2.4.124-2 (instead of 2.4.125-1) - spirv-tools-dev → spirv-tools (>= 2025.1~rc1-1) - DirectX-Headers relaxed to >= 1.614.1 - Disabled native D3D12 driver (unused on Linux) Added patches for a Meson scope error and two CVEs (CVE-2026-40393). The backport compiles cleanly in Trixie amd64/i386 and has run stably on my Intel Arc B580 system for days (gaming and LLMs via vulkan). Due to the size of the [debdiff](https://stornic56hub.duckdns.org/git/stornic56/mesa-debian/raw/branch/main/debdiffs/mesa-v25.3.3/mesa_25.3.3-1~bpo13+1.debdiff) (~10MB, includes new source files for CVE patches), I have uploaded it to my [repository](https://stornic56hub.duckdns.org/git/stornic56/mesa-debian/releases/tag/v25.3.3). Please review, I'm willing to help maintain this backport. Thanks for your work. Best regards,
Hi, FWIW, I’m starting work on backporting a newer mesa in Trixie-bpo. Best regards, Dylan