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
(In reply to Daniel Engberg from comment #6) 1. I recently switched from fetching DISTFILES from Github to fetching them from the official OpenZIM/Kiwix sites. We'll see if that proves to be a suboptimal strategy (Github may have the most bandwidth, counterbalanced by the fact that there is not much to download on the official sites). 2. Yes, I know that (hence also the use of BINARY_ALIAS for the build). I think I see what you mean in general, but then for OpenZIM/Kiwix ports I don't see how USES=shebang is going to help as Python scripts that actually get installed are simply copied by their Meson's scripts and are never executed, so no breakage can be detected at build-time with USES=shebang and missing files in SHEBANG_FILES in these cases. 3. True here, but still more fragile in general. I agree that's a minor point. Thanks for your answers. Regards.
(In reply to Olivier Certner from comment #7) To clarify, we should always use static distfiles whenever possible. Just a friendly reminder that USE_GITHUB is not the same as downloading assets "attached" to the release. I would argue as a good "netizens" that we should default to mirrors and fall back to primary site in general.
(In reply to Daniel Engberg from comment #8) > USE_GITHUB is not the same as downloading assets "attached" to the release I don't think I'm really getting what you mean here. Are you talking specifically about the PATCHFILES and PATCH_SITES in your patch leading to a download from Github? With USE_GITHUB, I can specify tags, which causes download of what seems to me exactly the assets corresponding to the release represented by the tag, and doesn't seem much different from what you're doing in the patch (except you're using a precise commit hash, making the patch immune to tag changes; that said, USE_GITHUB also works with precise commit hashes instead of tag names). Or perhaps your concern is that distfiles from Github are not "static"? > I would argue as a good "netizens" that we should default to mirrors and fall back to primary site in general. I interpret this as meaning we should in particular use Github in preference to other, lower traffic official sites, assuming Github has enough bandwidth to be considered a mirror itself, is that correct?
(In reply to Olivier Certner from comment #9) I referred to the distfile not the patch, see https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/ however in this specific case it's not attached to releases on GitHub (also covered in Porters Handbook's GitHub section). In this case upstream doesn't provide one unfortunately but there are many projects that do. As long as the mirror site be it GitHub or anything else is suitable for most users we should try to use it, this is also how bsd.sites.mk lists sites.
(In reply to Daniel Engberg from comment #10) Understood. Thanks.