Debian Patches

Status for python-taskchampion-py/2.0.2-5

Patch Description Author Forwarded Bugs Origin Last update
0001-Update-PyO3-46.patch Update PyO3 (#46) "Dustin J. Mitchell" <dustin@v.igoro.us> no 2026-02-22
0002-Make-remote-sync-optional-44.patch Make remote sync optional (#44)
* Run CI on all branches

* Make remote sync optional

This is useful to reduce the needed Rust crates.		 Jochen Sprickerhof <github@jochen.sprickerhof.de> no 2026-02-24
0003-Fix-num_undo_points-to-call-the-right-Rust-method.patch Fix num_undo_points to call the right Rust method "Dustin J. Mitchell" <dustin@v.igoro.us> no 2026-03-29
0004-define-__new__-instead-of-__init__.patch define __new__ instead of __init__ "Dustin J. Mitchell" <dustin@v.igoro.us> no 2026-03-29
0005-Make-index-to-__getitem__-positional.patch Make index to __getitem__ positional "Dustin J. Mitchell" <dustin@v.igoro.us> no 2026-06-13
0006-Update-to-TaskChampion-3.patch Update to TaskChampion 3
This leaves the Python API sync, despite the underlying Rust API being
async. The two don't actually play together nicely -- while there are
[adapters](https://docs.rs/crate/pyo3-async-runtimes/latest), they do
not handle self-references very well. Which makes sense -- if Python
calls a method `r.foo(&mut self, ..)`, and that method returns a future
that carries within it that `&mut self` reference, then nothing stops
another Python call that also uses `&mut self`. Fixing this requires
using `Arc<Mutex<..>>` with quite a bit more implementation complexity,
and very little benefit: the pyo3-async-runtimes crate runs the Rust
event loop in a separate thread, so this is no better than running a
sync call to `replica.sync()` on a Python thread.		 "Dustin J. Mitchell" <dustin@v.igoro.us> no 2026-03-29
0007-Update-for-taskchampion-in-Debian.patch Update for taskchampion in Debian
- Use default features
- Disable server-gcp (not in Debian)		 Jochen Sprickerhof <git@jochen.sprickerhof.de> no 2026-09-18

All known versions for source package 'python-taskchampion-py'

Links