| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-I-initialize-the-Python-extension-type-in-a-more-cor.patch | [PATCH 1/2] I initialize the Python extension type in a more correct way From d365c1ba53217d242a09b1ed8e97cb01ee4ae1d5 Mon Sep 17 00:00:00 2001 The older guides use PyObject_HEAD_INIT, and the newer ones use PyVarObject_HEAD_INIT: https://docs.python.org/3/extending/newtypes_tutorial.html I was doing the former, which caused a build failure with gcc-14: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075295 The new compiler build works now. |
Dima Kogan <dima@secretsauce.net> | no | debian | 2024-07-06 | |
| 0002-autodiff.hh-I-explicitly-prevent-all-the-symbols-fro.patch | [PATCH 2/2] autodiff.hh: I explicitly prevent all the symbols from being exported Turns out that if the compiler decided to un-inline any of these class methods, they would generate an exported symbol. I don't want to export ANY of these: the API is pure C. So I now do that explicitly |
Dima Kogan <dima@secretsauce.net> | no | 2024-07-06 | ||
| 0003-NumPy-2-workaround.patch | NumPy 2 workaround https://github.com/dkogan/mrcal/commit/0934dfe97099873f6b4415de23b3e784c745673c |
Dima Kogan <dkogan@debian.org> | no | upstream, | 2025-01-29 |