kronolith: fix make(1) substitution in INSTALLATION_DIRS
Back in May 2020, make(1) was changed to disallow the particular
substitution form used in one of the INSTALLATION_DIRS assignments.
https://github.com/NetBSD/src/commit/3b58d8437a0b171a42895aedbcd93e4f8b8c10e0
Incorrect/useless DESTDIR directories have been created by builds using
newer versions of the tool, though this is harmless.
shells/oh-my-posh: update to 28.7.0
v28.7.0
Bug Fixes
- git: fallback to git_icon on no upstream
Features
- claude: use session_id for session key
- config: display actual error
v28.6.0
Features
- cli: add claude command and segment for Claude Code integration
v28.5.1
Bug Fixes
- python: better uv command
chat/matrix-synapse: Update to 1.143.0
(This update is overdue and should have been in 2025Q4, but was
delayed due to incorrect pydantic packaging.)
Upstream NEWS content:
* Synapse 1.143.0 (2025-11-25)
Features
Support multiple config files in
register_new_matrix_user. (#18784)
Remove authentication from POST /_matrix/client/v1/delayed_events,
and allow calling this endpoint with the update action to take
(send/cancel/restart) in the request path instead of the
body. (#19152)
[16 lines not shown]
devel/py-pydantic-*: Drop incorrect relaxation of exact dep and add caution
As posted to tech-pkg on 5 December, pydantic really does have an
exact dependency on pydantic-core (even though the version numbers do
not match). The previous update was broken, and matrix-synapse failed
to build.
Drop the patch to pyproject.toml that relaxes the dependency, as 1)
wrong and 2) not documented or reported upstream (who would say no,
it's right).
Add comments that these two packages need to be updated in sync with
version numbers that meet upstream's dependency patterns.
No PKGREVISION++, as the binary package doesn't change. It's just
that a future bad update will cause a build failure, if someone does
that without reading the comments.
kea: updated to 3.1.4
Welcome to Kea 3.1.4, a maintenance release of the 3.1 development
series. As with any other development release, use this with caution:
development releases are not recommended for production use.
py-django-admin-sortable2: updated to 2.3
2.3
Prepare for Django-6.0.
fix 397: Remove Django popup when using list action after dragging items in list view.
fix 417: Increase height of drag area in Stacked-Inlines.
fix 371: default_order_field might not be set on model.
fix 400: Check for change permission when rendering "Move" actions in list view.
fix 408: Validate POST request from action form.
fix 423: Remove novalidate from action form in list view.
fix 425: Give better explanation what to do if ordering numbers get negative.
py-django-filer: updated to 3.4.1
3.4.1 (2025-11-24)
fix: Add missing JS bundles and LICENSE file
3.4.0 (2025-11-21)
feat: Add Django 6.0 support
feat: Add CSP support by collecting all JS code in bundles
fix: preserve "limit search to folder" state in pagination links
py-mediafile: updated to 0.14.0
0.14.0
Refactored the monolith mediafile.py (2400 lines) into a modular structure with multiple files under the mediafile/ directory. This should make it easier to maintain and extend the codebase.
Dropped support for Python 3.7, 3.8 and 3.9. MediaFile now requires Python 3.10 or later. This aligns with the current long-term support (LTS) versions of Python.
Added minimal contribution guidelines to CONTRIBUTING.md
Changed project linter and formatter from flake8 to ruff. Reformatted the codebase with ruff.
Moved changelog into its own file, changelog.rst. Also added github workflow for automatic changelog reminders.
Modernized package and tests setup to use poetry.
Run pyupgrade to align code with Python 3.10+ syntax.
Added TSO2 tag to albumartist_sort, matching how Picard >= 1.2, iTunes and Swinsian interpret tags.
Added TXXX:LABEL and TXXX:MEDIA tags to label and media fields, respectively, for MP3 files.
py-rst2pdf: updated to 0.103.1
0.103.1 (2024-12-24)
* Changed: Updated pyproject classifiers to include Python 3.13
* Changed: Various project changes to allow releasing using uv
0.103 (2024-12-24)
* Added: We now support Python 3.13
* Added: We now support ``emphasize-lines`` asa an alias for ``hl_lines``
* Changed: Support PyMuPDF when it's installed as fitz_old
* Changed: We now use pyproject.toml and uv
* Fixed: We now run our Sphinx tests again
* Fixed: We no longer add a second document to Sphinx builds
py-svglib: added version 1.6.0
Svglib is a Python library for reading SVG files and converting them (to a
reasonable degree) to other formats using the ReportLab Open Source toolkit.
py-reportlab: updated to 4.4.7
CHANGES 4.4.7 21/12/2025
* fix table layout error reported by Andy Hagar atboom33w at gmail dot com
CHANGES 4.4.6 10/12/2025
* fix CHANGES versions wrongly marked as 4.3.x --> 4.4.x
* remove url from default PDF metadata
CHANGES 4.4.5 17/11/2025
* remove random monkey patches in randomtext
* add and use testutils.invariantSeed in tests
* fix (maybe partially) Table row splitting of ListFlowable
* apply patch for in row splitting bug reported by Christian Zwicknagl via Yoshua Wakeham
CHANGES 4.4.4 18/09/2025
* raise an error for table cell flowables given negative width
* fix the rotatedEnclosingRect algorithm so it allows variable angles
* allow 2 as value for lineplots inFill lines get drawn after fill
[25 lines not shown]
py-rlpycairo: added version 0.4.0
This is a plugin for the ReportLab PDF Toolkit which constructs rich PDF
documents, and also creation of charts in a variety of bitmap and vector
formats.
This plugin is intended to replace most of the usage of the libart based C
extension _renderPM which has been shown to have issues when rendering complex
documents.
This backend can be brought into use by setting
reportlab.rl_config.renderPMBackend = 'rlPyCairo' any of the methods detailed
in reportlab/rl_config.py can be used to accomplish this.
devel/concurrencykit: update to (concurrencykit) ck-0.7.2
Release announcement:
This release adds support for riscv, as provided by Mitchell Horne,
as well a miscellaneous bug fixes and improvements.
lang/ghc910: Removed the "doc" option which had been enabled by default
Sorry, wiz@, but turning doc generation on was such a bad idea. Prior to
ghc910 it was off by default. It wasn't even a proper option. I (pho@) was
personally trying it from time to time to see if it worked.
In the past years it was hopeless. It almost always failed because of
version subtleties. But when I packaged ghc910, the API of Sphinx seemed
stable enough so I thought it was safe to use for building GHC docs.
I was wrong. It wasn't safe at all. Sphinx 9 came along and it broke
again. wiz@ applied a hack to unbreak the build, but I think it's not a
sustainable solution tbh. We must really turn it off and forget docs.
