https://pdr2.bofh.network/data/141-diizzy/2024-12-23_15h36m26s/logs/errors/libzim-9.2.1.log
Maintainer informed via mail
Created attachment 256430 [details] Patch for zim Updated to latest version, imported upstream PR 936 to fix build Simplify port References: https://github.com/openzim/libzim/pull/936 Multiple unit tests fails however that's also true for current version in tree, please try to fix unit tests
Thanks for the heads-up. Didn't see this PR at first. Have already updated to the latest version. Currently handling it.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=eb6e7079deccdb7b8b7376f6df1c4af91eed68b8 commit eb6e7079deccdb7b8b7376f6df1c4af91eed68b8 Author: Olivier Certner <olce@FreeBSD.org> AuthorDate: 2025-01-16 13:09:50 +0000 Commit: Olivier Certner <olce@FreeBSD.org> CommitDate: 2025-01-16 13:48:23 +0000 devel/libzim: Support ICU 76.1 The added patch is an upstream's candidate to fix the build against ICU 76.1, and will make it in the next release in this or another form. In the meantime, adopt it in the ports tree as is as it does not disturb the build against older versions of ICU. This is a maintainer update (olce.freebsd.ports@certner.fr). PR: 283542 Sponsored by: The FreeBSD Foundation devel/libzim/files/patch-meson.build (new) | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
(In reply to Daniel Engberg from comment #2) I've just integrated the upstream patch, so closing this bug. I have a few remarks/questions on the patch you proposed above: 1. For a single patch, and given that the distfile itself doesn't come from GitHub, I prefer to integrate it directly in the ports tree, that's one less network connection and one less dependence on Github. 2. Replacing `BINARY_ALIAS` with `USES=shebang` makes the process more fragile, as I now have to list the files where the shebang should be altered. Given that the Python scripts in this port's code are used only during the build process and in the end are not installed, there is no obligation to use `USES=shebang`, so switching to it doesn't look as a simplification to me. Am I missing something? 3. `PLIST_SUB`: Your proposed change is correct but is more fragile than the current regular expression (it assumes 3 numbers separated by dots, contrary to the latter). I think I've seen double `:R` used in other places, but I'm reluctant to use it for this reason.
(In reply to Olivier Certner from comment #5) 1. You're not going to get very far without GitHub these days but if that's your preferred approach that's fine. 2. The binary names python3 and python3-config aren't a part of the distribution and only provided as a "compatibility hack" via lang/python3 which you shouldn't depend upon. I would argue that it's better to get errors during build than have to verify that runtime isn't affected which you'd need to patch files anyway if that would be the case. 3. Upstream have used that layout since 2007 so I think it's safe to assume it wont break in this case and more commonly used than custom regexps so for consistency. Best regards, Daniel