Hi,
在 2026/2/17 11:53, Faidon Liambotis 写道:
Control: block 1062808 by -1
On Mon, Feb 16, 2026 at 08:29:49PM -0500, Boyuan Yang wrote:
* Package name : uharfbuzz
Through no fault of yours and as a result of my bad judgement (for not
filing an ITP first) and extremely bad luck (for the wild coincidence),
I worked on packaging uharfbuzz over the weekend, and placed the
finishing strokes yesterday... I was about to send the ITP when I saw
yours. Oh well!
No problem; it was my (bad) habit to do 100% of packaging work first,
file ITP, and then immediately upload the prepared package to the NEW
queue with the ITP number. I wish I had filed the ITP earlier this week.
I pushed my work now to https://salsa.debian.org/paravoid/uharfbuzz and
I'm comparing it to yours; a few notes:
1) Did you generate the tarball by hand to remove the vendored harfbuzz
source? I repacked the tarball through have "Files-Excluded: harfbuzz".
I picked the tarball up from PyPI, not GitHub, but I see the GitHub one
also includes it.
With my Python Team member hat on:
I remember the (Python) Team had the conclusion that pypi was not the
preferred point for retrieving source code, and the actual upstream source
code repository (GitHub in this case) should be used whenever possible.
This is exactly what I did in https://salsa.debian.org/fonts-team/uharfbuzz/ .
(I know this package was not placed in python-team namespace, but anyway.)
2) I also stripped the tarball from the pregenerated Cython code
(src/uharfbuzz/_harfbuzz.cpp, src/uharfbuzz/_harfbuzz_test.cpp) through
Files-Excluded, as well as debian/clean.
Repacking will not be necessary if we directly take the upstream source
code from GitHub.
3) On the matter of test data - I checked the source of some of these
(like Adobe Blank), and realized that a) the binaries are not the
preferred source of modification - some use afdko etc. b) they are
modified (likely using (u)harfbuzz itself) to remove glyphs etc. So I
did the following:
a) Added tests/data to Files-Excluded;
b) Used the fonts that exist in Debian (STIX and Open Sans) as B-D
c) Wrote a script to generate the subsets that uharfbuzz expects,
which uses fonttools. See debian/generate_test_data.py.
d) Patched the upstream source to skip tests for not-found fonts.
Longer-term, I was also thinking of packaging the remaining fonts.
All fonts in uharfbuzz are test data, and are not shipped to the end
user anyway. In this case, I don't think we should bother pursuing
the preferred source of modification with patches since they do not
affect our delivered .deb file in any way. On the other hand, preserving
upstream unit tests ensures quality test in post-build tests and
autopkgtest. As a result, I did not repack to strip the font files,
but opted to document the full license of test data. Let's see what
the DFSG Team may say about it.
4) I think you need python3-all and python3-all-dev, not
python3/python3-dev.
Oh, this is not the case. If you read into the build system, you will
find out that uharfbuzz enabled the CPython limited API [1], which (largely)
ensures ABI stability across different supported python3 versions. Building
with python3-all-dev will thus have no effect, and even raises a warning in
the build log. You should also observe through the generated dependency
that dh_python3 did not have a python3 dependency version range due to
the use of PY_LIMITED_API.
5) I think my extended description is a bit nicer :) I did not know the
source extended description trick though! TIL.
You are welcome to integrate this part into future packaging once
uharfbuzz cleared the NEW queue.
Let me know what you think of the above, and I can commit them to the
repository. (I used to maintain some fonts, so I'll check whether I have
access to the DFTF salsa.)
Feel free to let me know what I can help; if you need access to
salsa.debian.org/fonts-team/ , you may need to contact the Salsa group
Owners.
[1] https://docs.python.org/3/c-api/stable.html#limited-c-api
Best,
Boyuan Yang
