Repository navigation
Conversation
gtk4 eventually depends on harfbuzz which was recently split on CF such that the .typelib files were moved to a -devel package. However, the typelib files are used by gobject at runtime. Missing this file leads to import failures. I used opus-5-5 to help debug the failures in our appveyor and to review the CF repo history.
|
conda-forge/harfbuzz-feedstock#172 / conda-forge/harfbuzz-feedstock#171 are the downstream issues. |
|
Correct. This issue in particular is a bug in a non-Python package which the wheel ecosystem can not even describe (it can provide it by stuffing random unknown name mangled binaries into wheels, but that is a different discussion). |
|
The fix upstream has been merged, I'm not sure it is possible that by tomorrow morning this will have sorted itself out and we can close this with no-action or we can merge this now and revert it next week or so when the CF side of things has definitely had time to propagate. |
|
@tacaswell I’ll leave the decision to you whether to merge and later revert or whether to wait for the fix to propagate. |
|
#32446 had the appveyor test pass without this merged so I think the downstream fix propagated and we do not need this work around. |
3 participants
PR summary
gtk4 eventually depends on harfbuzz which was recently split on CF such that the .typelib files were moved to a -devel package. However, the typelib files are used by gobject at runtime. Missing this file leads to import failures.
Next step is to open an issue downstream.
AI Disclosure
I used opus-5-5 to help debug the failures in our appveyor and to review the CF repo history.
PR quality check