On Tue, Feb 17, 2026 at 12:55:16PM -0500, Boyuan Yang wrote: > 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.
Yep, seems like both of us have the same bad habit :) > 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/ . It's a minor point, but I was not aware of that -- do you happen to have a reference? In any case... > > 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. ...that's a pretty good reason to fetch from GitHub instead of PyPI, indeed! > 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. I understand the reasoning (you even identified a real failure through those tests, that I didn't). I also understand that it comes down on how pedantic you want to be with the DFSG. Note however https://github.com/harfbuzz/uharfbuzz/issues/234 -- I don't think we have the full license for all fonts, sadly. > > 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. Oh I didn't notice that. That's great :) > > 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. Will do. Faidon
