Debian Patches

Status for pytorch/2.14.1+dfsg-1

Patch Description Author Forwarded Bugs Origin Last update
1020-dirtyhack.patch The elegant patching work is based on the master branch https://github.com/pytorch/pytorch/issues/14699
And we will be able to use that solution in the next upstream release.
I don't want to rebase my patches back to this version, so let's go with a fast, yet dirty hack.		 Mo Zhou no 2026-09-11
1030-use-system-dnnl.patch Enable DNNL/ideep integration Mo Zhou not-needed 2023-09-30
1040-cmake-strip-3rdparty.patch Patch cmake to strip third-party directory includes/checks. Mo Zhou not-needed 2023-08-22
1045-filemirroring-cutedsl-optional.patch do not abort the CUDA configure when the cutlass tree is absent cmake/FileMirroring.cmake (new in 2.14.0) copies one CuTeDSL grouped-GEMM
kernel out of third_party/cutlass into the wheel and, for CUDA builds,
fails the configure when that submodule is missing. The +dfsg repack
strips cutlass (the CUDA variant builds against libcutlass-dev instead),
so downgrade the error to a status message and simply ship no vendored
CuTeDSL kernel, as the 2.13 setuptools flow did.		 Aron Xu <aron@debian.org> not-needed 2026-09-11
1050-use-system-httplib.patch use system cpp-httplib instead.
===================================================================		 not-needed 2026-09-11
1060-use-system-mimalloc.patch Link against system libmimalloc instead of the embedded copy. Upstream auto-enables USE_MIMALLOC on Windows and non-Apple aarch64
(CMakeLists.txt l.418) and bundles its own copy under
third_party/mimalloc. The embedded directory is dropped from the
Debian +dfsg2 tarball, which broke arm64 builds at the CMake configure
stage (add_subdirectory complains the directory does not exist).
.
Replace the embedded reference with find_package(mimalloc), provided
by Debian's libmimalloc-dev. c10's link site is updated to use the
imported target name "mimalloc" exported by Debian's CMake config.
.
amd64/ppc64el/riscv64/s390x are unaffected: upstream leaves
USE_MIMALLOC=OFF on those arches and the block below is skipped.		 Aron Xu <aron@debian.org> not-needed 2026-05-17
1070-formatting-fmt11-ostreambuf-iterator.patch Route Formatting.cpp printValue through fmt::memory_buffer fmt 11.1+ tightened the internal format_decimal overloads: the templated
output-iterator variant now requires is_back_insert_iterator, and
std::ostreambuf_iterator satisfies neither that nor the raw-pointer
variant. Using FMT_COMPILE'd specs with std::ostreambuf_iterator therefore
fails to compile with system libfmt >= 11.1.1.
.
Format into a fmt::memory_buffer via std::back_inserter (which does
satisfy is_back_insert_iterator) and flush the buffer to the stream in
one write. Behaviour is preserved; the fix is also a no-op for libfmt 10.
.
Upstreamability: not forwarded. Upstream pins fmt 12.1.0 in
third_party/fmt (same tightened overload as 11.1.1) yet builds
Formatting.cpp cleanly in CI -- the FMT_COMPILE double-with-g/e/f path
SFINAE-dispatches around the strict format_decimal(OutputIt, ...)
overload in the vendored-header-only configuration. The break appears
to be specific to Debian's system libfmt path (USE_SYSTEM_LIBS=ON),
which changes the overload set in scope. No matching upstream issue or
PR found (searched pytorch/pytorch for Formatting.cpp/fmt/format_decimal/
ostreambuf_iterator/is_back_insert_iterator, 2026-07). Kept Debian-local
pending a reproducer against upstream's own vendored fmt.		 Talha Can Havadar <havadartalha@gmail.com> not-needed 2026-07-10
2000-version.patch make the "torch.__version__" and wheel version correct. The upstream use env vars instead. debian specific. Never forward this.
===================================================================		 not-needed 2026-10-08
2050-pytorch_glog_update.patch move IsGoogleLoggingInitialized() to public API It was an internal function and project used hacks to reach it. Now it's part
of the public API.		 Laszlo Boszormenyi (GCS) <gcs@debian.org> not-needed 2022-03-08
2060-fix-wrong-shebang.patch fix wrong shebang
--
===================================================================		 Mo Zhou not-needed 2023-07-17
2080-fix-aten-config-cmake-path.patch avoid including the build path in the cmake configuration file not-needed 2023-09-06
2090-drop-six-from-pyproject.patch drop unused six dependency from pyproject.toml python3-six is being phased out in Debian. The "six" entry is only
reachable through the optional NNPACK -> PeachPy chain, which is
disabled in the Debian build, so each Debian binary package must
declare only the dependencies it actually needs. Removing the entries
here prevents python3-torch from pulling python3-six back in via
pybuild.		 no debian 2026-09-11
2101-fix-ftbfs-ld-sleef.patch =================================================================== not-needed
2210-disable-fno-math-errno-on-arm64-to-workaround-gcc14-bug.patch Disable -fno-math-errno on arm64 to workaroun gcc 14 bug (#1094828) Shengqi Chen <harry@debian.org> yes debian upstream 2025-02-18
2220-qconv-fp8-non-x86-gate.patch Gate qconv FP8 cpuinfo helper by architecture. When the system oneDNN/ideep is >= 3.9 the ONEDNN_FP8_QCONV_SUPPORTED
macro is defined (aten/.../OnednnUtils.h:467), and qconv.cpp +
qconv_prepack.cpp call cpuinfo_has_x86_amx_fp16() unconditionally to
decide whether to take the AMX-accelerated FP8 path. The helper is
only declared on x86, so non-x86 builds (ppc64el, aarch64, etc.) fail
with "'cpuinfo_has_x86_amx_fp16' was not declared in this scope".
.
Upstream already added a __powerpc__ guard in qlinear.cpp and
qlinear_prepack.cpp (commit a4c7e7f9837, "[PowerPC]: Fixed build
issue that occur because of datatype f8 enablement for onednn in
qlinear and prepack") but forgot to apply the same fix to the qconv
pair. We extend the gate to all non-x86 arches so the simple
fp8-fallback path is taken everywhere except x86.		 Aron Xu <aron@debian.org> invalid 2026-05-17
2300-torch-cuda-no-use-nvtx3.patch let it fallback to use the old NVTX3 headers. Grep the code with TORCH_CUDA_USE_NVTX3 can you will find the simple fallback logic. The new
header needs new nvtx packages. The old one is already in nvidia-cuda-dev.
===================================================================		 no
2310-disable-non-portable-flags.patch Disable non-portable flags
===================================================================		 Santiago Vila <sanvila@debian.org> no debian 2025-04-09
2330-gloo-skip-half-bfloat16-without-torch-dtypes.patch Skip Half/BFloat16 in gloo operations when gloo lacks supportWhen using system gloo that was built without GLOO_USE_TORCH_DTYPES,
the template instantiations for c10::Half and c10::BFloat16 don't exist
in libgloo_hip.so (or libgloo_cuda.so). This causes linker errors:
.
undefined reference to `gloo::HipAllreduceRingChunked<c10::Half, ...>
undefined reference to `gloo::HipAllreduceRingChunked<c10::BFloat16, ...>
.
This patch checks GLOO_USE_TORCH_DTYPES from gloo/config.h and provides
two versions of the GENERATE_ALL_TYPES macro - one with Half/BFloat16
support when gloo has it, and one without when gloo lacks it.
.
At runtime, attempting to use Half/BFloat16 types with gloo collective
operations will result in an "Invalid scalar type" error.		 Talha Can Havadar <talha.can.havadar@canonical.com> not-needed 2026-09-11
2340-c10d-tests-link-gloo-explicitly.patch Link gloo explicitly into the ROCm c10d Gloo tests debian/patches/1020-dirtyhack.patch already adds the gloo imported target
to the CUDA and CPU-only variants of ProcessGroupGloo(Async)Test, but the
ROCm variants under test/cpp/c10d/hip/ were missed. Against Debian's
system libgloo (from libgloo-rocm-dev) the ROCm test link then fails with
"undefined reference to gloo::Context::setTimeout" because gloo is a
private dependency of libtorch_cpu and is not re-exported to test links.
.
Complete the pattern by adding gloo to LINK_LIBRARIES on the hip/ Gloo
tests, mirroring what the NCCL/UCC ROCm tests already do with their own
dependency targets.
.
Upstreamability: not appropriate for upstream. The CUDA variants of the
same tests upstream (test/cpp/c10d/CMakeLists.txt:61-62) also do not
link gloo explicitly, so ROCm here is only mirroring upstream policy.
The missing link only manifests with USE_SYSTEM_GLOO=ON, which is a
Debian-specific configuration -- upstream's vendored-gloo build path
static-links gloo into libtorch_cpu and does not need the propagation.
A companion Debian-side fix for CUDA lives in 1020-dirtyhack.patch.		 Talha Can Havadar <havadartalha@gmail.com> not-needed 2026-07-10
2400-vulkan-spv-reproducible-order.patch gen_vulkan_spv: sort shader files for reproducible builds tools/gen_vulkan_spv.py collects the Vulkan GLSL shaders and template YAML
files with glob.glob(), which returns them in filesystem (readdir) order.
That order is not stable across builds, and it is preserved all the way into
the generated spv.cpp: the SPIR-V byte arrays, the shader-name strings and the
register_shader() calls are emitted in glob order. As a result libtorch_cpu.so
differs between builds (reordered .rodata strings, different .data.rel.ro
shader-registry pointers, and different register allocation in the generated
registration function), breaking reproducible builds. Sort the glob results so
the registry order is deterministic. This is only relevant with USE_VULKAN=1

===================================================================		 Aron Xu <aron@debian.org> no 2026-06-01
2500-scikit-build-core-0.11-compat.patch build with the scikit-build-core version available in Debian (0.11) Upstream's pyproject.toml requires scikit-build-core >= 1.0 and uses three
constructs that only exist there; sid ships 0.11.6. Rewrite the build
configuration against the 0.11 schema (1.x still accepts the result, so this
does not have to be reverted when a newer scikit-build-core lands):
.
* build-system.requires / requirements-build.txt / [dependency-groups]:
lower the floor to scikit-build-core >= 0.11. requirements-build.txt
matters beyond the build itself: debian/rules feeds it to
"dh_python3 --requires", so a >= 1.0 line would generate an unsatisfiable
python3-scikit-build-core (>= 1.0) dependency.
* The standard top-level [[tool.dynamic-metadata]] table (dynamic-metadata
0.3 spec, new in 1.0) becomes the 0.11 per-field
[tool.scikit-build.metadata.<field>] table with provider/provider-path,
which needs experimental = true for an in-tree provider.
* The provider entry points are adapted to accept both plugin APIs:
0.11 calls dynamic_metadata(field, settings, project) and wants the bare
value of that field, 1.0 calls dynamic_metadata(settings, project) and
wants a dict of fields. The three-parameter signature is what makes 0.11
pass the project mapping at all, and the first argument's type selects the
convention. dynamic_wheel() is adapted the same way (0.11 never calls it).
* The [tool.scikit-build.env] table (new in 1.0) is dropped; it has no 0.11
equivalent. Its two effects are reproduced by the caller: debian/rules
exports CMAKE_BUILD_PARALLEL_LEVEL (was aliased from MAX_JOBS) and CC/CXX
(listing them in the env table suppressed scikit-build-core's sysconfig
compiler injection, which 0.11 performs unconditionally when they are
unset). The same table inside the win32-only override goes with it.
.
Selecting the build type still works: the REL_WITH_DEB_INFO override uses
if.env, which 0.11 supports. Only the 1.0 "cmake.build-type honors
CMAKE_BUILD_TYPE from the environment" behaviour is lost; with 0.11 use
SKBUILD_CMAKE_BUILD_TYPE=<type> or -C cmake.build-type=<type>.		 Aron Xu <aron@debian.org> not-needed 2026-09-11
2510-license-files-dfsg.patch drop the license-files glob that matches nothing in the +dfsg tree The +dfsg repack strips every third_party submodule, so
"third_party/**/LICENSE.rst" no longer matches any file. pyproject_metadata
(vendored by scikit-build-core, both 0.11 and 1.x) refuses a
project.license-files pattern that matches nothing, which aborts wheel
metadata generation before CMake even starts. The two remaining
third_party globs still match (miniz, mslk, perfetto, llvm-openmp).		 Aron Xu <aron@debian.org> not-needed 2026-09-11
rocm-disable-aotriton-download.patch =================================================================== no

All known versions for source package 'pytorch'

Links