Debian Patches
Status for datalad/1.6.5-1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| no_self_typing | no | |||||
| deb_no_utf8 | Disable unicode strings in commands to be executed in tests As you could see largely it is about executing a command with unicode, or later logging it. Whenvever Python2 seems to do it automagical conversions without blowing up, on Python3 I found no reliable way to achieve desired -- logger would not accept bytes, but would puke upon attempt to encode unicode into 'ascii', etc Problems go away if UTF-8 locale is configured and set (instead of C or POSIX) |
Yaroslav Halchenko <debian@onerussian.com> | no | 2018-06-05 | ||
| python3.patch | use python3 interpreter, not python by default in Makefile The rest of the original patch by Steve Langasek <steve.langasek@ubuntu.com> are no longer needed/adopted upstream |
no | ||||
| up-pip-develop | PATCH: rework `make bin`'s setup.py develop, now pip-based and network-broken Modern setuptools' `develop` command is deprecated and now internally shells out to `pip install -e . --target <dir>` with no --no-deps / --no-build-isolation, which (a) requires pip to be present at all and (b) reinstalls the full dependency closure from PyPI into <dir>, which fails offline (e.g. in a real, network-less buildd) and even when it doesn't fail, duplicates dependencies already satisfied by the system's installed packages. Call pip ourselves instead, with --no-deps (nothing here needs datalad's dependencies re-resolved, they are already on sys.path) and --no-build-isolation --no-index (use the ambient, already-installed build backend; touch no network). Target build/ rather than the project root or a bare ./bin, to keep pip's own bookkeeping (.dist-info, the editable .pth/finder) out of the tracked source tree and inside the existing, already-fully-cleaned build/ scratch dir; pip's own console-script convention then places the generated scripts at build/bin/ (not build/, and not build/bin/bin/ -- pip --target always appends its own "bin" level for scripts, so passing "build" here, not "build/bin", is what avoids a doubly-nested bin/bin). Verified this still refreshes ./datalad.egg-info the same way `setup.py develop` did (needed by debian/rules' later `cp -rp datalad.egg-info ...`), and still produces working console-script entry points, now at build/bin/ instead of directly under the old --install-dir. |
Yaroslav Halchenko <debian@onerussian.com> | no | 2026-09-26 | ||
| deb-pyproject-license.patch | drop the PEP 639 `license`/`license-files` keys from pyproject.toml Some still-supported setuptools releases predate PEP 639 support in the `[project]` table and reject it outright: . - `license = "MIT"` (SPDX string form) is rejected on Ubuntu 24.04 noble's setuptools with "configuration error: `project.license` must be valid exactly by one definition (2 matches found)" - `license-files = ["COPYING"]` is rejected on Debian 12 bookworm's and Ubuntu 24.04 noble's setuptools with "configuration error: `project` must not contain {'license-files'} properties" . Since the actual license grant is already tracked authoritatively in debian/copyright, just drop both fields here rather than rewrite them to older table forms, which newer setuptools may in turn reject as deprecated. noble and Debian bookworm backports) |
no | debian | 2026-09-28 | ||
| py315-multiprocessing.patch | Set multiprocessing start method to fork for test suite Under Python 3.15, forkserver is the default start method on POSIX, which fails in the test harness when tracking child processes across runners. =================================================================== |
Maximiliano Curia <maxy@debian.org> | no |