Created attachment 251428 [details] Patch for libxml2 This will be a "Meta" PR, at least libxslt will also be needed to updated at the same time. Compile tested on FreeBSD 14.0-RELEASE (amd64) (make, make check-plist, make test) Compile tested on FreeBSD 14.1-RELEASE (aarch64) (make, make check-plist, make test) Poudriere testport OK 13.2-RELEASE (amd64) Poudriere testport OK 14.0-RELEASE (amd64) Tested with all listed consumers (including ones for py-libxml2) on freshports.org on 13.2-RELEASE (amd64) using Poudriere: https://pdr2.bofh.network/build.html?mastername=132-diizzy&build=2024-06-12_15h36m18s
I have a patch for libxslt ready which I'll submit soon, for now we can work on the fallout of ports that are already known (see link to pdr2).
Comment on attachment 251428 [details] Patch for libxml2 This needs the legacy option exposed and enabled by default, amongst other things. Will reduce the fallout somewhat. Also note that meson is now available. Upstream still indirectly recommends autotools for Unix-like systems, especially as evidenced by their CI.
It would be great if we could do without legacy as we're essentially just pushing work in front of us for a later date by using it. Ports that have ~dead/inactive upstream and no users in tree textproc/diffmark - Abandonware (should be marked as unfetchable at least) also removes... textproc/p5-XML-DifferenceMarkup textproc/liblingoteach - Abandonware (last activity ~20 years ago) also removes... misc/lingoteach devel/libiqxmlrpc - ~ Abandonware, upstream requests patches textproc/libcroco - Needs patch, deprecated/dead and already removed in other repos such as Debian and Fedora Compatibility: databases/spatialite - Probably needs the http functionality in libxml2 enabled to keep if the libxml module is enabled There are also a few compatibility patches recently added to upstream libxml2 repo: https://gitlab.gnome.org/GNOME/libxml2/-/commit/599ceaffad97faff9e77a3237d319f18cdc2984a https://gitlab.gnome.org/GNOME/libxml2/-/commit/bd208d5fe110999b17ef88d45648e2a248dc964e Even without these (for now) we can try to prepare as much as possible. General note, Most of the fallout is from 2.12.X which we didn't import due the amount of work required to migrate to 2.11.X.
No, I've actually had 2.12 in my own WIP tree this entire time, but yes even with legacy exposed and enabled by default some downstream stuff had to give. This is one of those ports where you cannot only account for ports consumers. Further, it's not so much work for us, but the consumers' upstream projects need time and effort to migrate from the legacy APIs. Legacy stays.
Updated list regarding http functionality, databases/spatialite - Probably needs the http functionality in libxml2 enabled to keep the libxml module is enabled cad/openvsp - Probably depends on the http functionality in libxml2
Created attachment 251475 [details] Patch for libxml2 v2 Enable http module as some ports requires this functionality such as databases/spatialite and cad/openvsp
Created attachment 251491 [details] Patch for libxml2 v3 Backport upstream commits: 95939d6ea3718c458620eeda850add549cd07e99 7c3151903da31efb7a42f3e27857f9f7df6f88e1 b61a960bf6dba639b310646300a1fc21ef473afc References: https://gitlab.gnome.org/GNOME/libxml2/-/commit/95939d6ea3718c458620eeda850add549cd07e99 https://gitlab.gnome.org/GNOME/libxml2/-/commit/7c3151903da31efb7a42f3e27857f9f7df6f88e1 https://gitlab.gnome.org/GNOME/libxml2/-/commit/b61a960bf6dba639b310646300a1fc21ef473afc
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=14ef9b0ef00043e34cd1f0f9611667503ebe1006 commit 14ef9b0ef00043e34cd1f0f9611667503ebe1006 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2024-06-16 16:16:18 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2024-06-16 16:35:52 +0000 textproc/p5-XML-DifferenceMarkup: Deprecate and set expiration date to 2024-07-16 Depends on deprecated port textproc/diffmark PR: 279705 Approved by: portmgr (blanket) textproc/p5-XML-DifferenceMarkup/Makefile | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e1a4636af2dc1f4e3b002b6458371ee3fa558155 commit e1a4636af2dc1f4e3b002b6458371ee3fa558155 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2024-06-16 16:26:12 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2024-06-16 16:35:53 +0000 devel/libiqxmlrpc: Deprecate and set expiration date to 2024-07-16 Fails to build with libxml2 2.13.0 PR: 279705 devel/libiqxmlrpc/Makefile | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=86be50192c1a97237c9923dc878cae46e2f6a3f2 commit 86be50192c1a97237c9923dc878cae46e2f6a3f2 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2024-06-16 16:20:58 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2024-06-16 16:35:52 +0000 textproc/liblingoteach: Deprecate and set expiration date to 2024-07-16 Abandonware, last activity 18+ years ago and fails to build with libxml2 2.13.0 PR: 279705 textproc/liblingoteach/Makefile | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=0fea4d9fc1398edf126dd255c5490c32af6f2c58 commit 0fea4d9fc1398edf126dd255c5490c32af6f2c58 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2024-06-16 16:23:11 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2024-06-16 16:35:52 +0000 misc/lingoteach: Deprecate and set expiration date to 2024-07-16 Depends on deprecated port textproc/liblingoteach PR: 279705 misc/lingoteach/Makefile | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=20ee0c7068c50c85dabfb99e1d3a86ada9fdab32 commit 20ee0c7068c50c85dabfb99e1d3a86ada9fdab32 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2024-06-16 16:13:14 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2024-06-16 16:35:52 +0000 textproc/diffmark: Deprecate and set expiration date to 2024-07-16 Deprecate as port fails to build with libxml2 2.13.0 and upstream is gone PR: 279705 textproc/diffmark/Makefile | 4 ++++ 1 file changed, 4 insertions(+)
Comment on attachment 251491 [details] Patch for libxml2 v3 Backports are fine otherwise
Created attachment 251599 [details] Patch for libxml2 v4 Update to 2.13.1 Remove deprecated MEM_DEBUG option New mini-exp run can be found here: https://pdr2.bofh.network/build.html?mastername=140-diizzy&build=libxml2-2131
Created attachment 251644 [details] Patch for libxml2 v5 Backport upstream patches aaa24ca6be56d1573357c88ac82a1542f832576d, 7759765c6c3fcd0735fe7caeb83f1be0f2da7775 and MR 266 References: https://gitlab.gnome.org/GNOME/libxml2/-/commit/aaa24ca6be56d1573357c88ac82a1542f832576d https://gitlab.gnome.org/GNOME/libxml2/-/commit/7759765c6c3fcd0735fe7caeb83f1be0f2da7775 https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/266
Created attachment 251885 [details] Patch for libxml2 v6
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=8e35b11ca62acfd1e1cb81506c64f3ad773521d9 commit 8e35b11ca62acfd1e1cb81506c64f3ad773521d9 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2024-07-06 11:40:15 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2024-07-06 12:02:09 +0000 games/manaplus: Deprecate and set expiration date to 2024-08-06 Fails to build with libxml2 2.13.2, unmaintained for years and very little activity upstream for the past 2 years PR: 279705 games/manaplus/Makefile | 3 +++ 1 file changed, 3 insertions(+)
New run here: https://pdr2.bofh.network/build.html?mastername=140-diizzy&build=libxml2-2132-libxslt-1142-run1 PRs applied: 279705, 279741, 279976 and 279956 Ignore tclxml, that's my fault
Created attachment 252032 [details] v7 Back to autotools. LEGACY option added and enabled by default, resurrect STATIC, both for the benefit of consumers not in the tree. LEGACY implies http, lzma and zlib, which can be exposed as separate options. Rename the python child port to textproc/libxml2-python, as the Python package name is "libxml2-python" (and not "libxml2"). Currently has USE_PYTHON=distutils despite a pyproject.toml existing (USE_PYTHON=pep517) but need to slightly modify python.mk to allow the parent port's do-configure to run (setup.py is generated).
Created attachment 252033 [details] Patch for libxml2 v7 Backport upstream patches dd5adf54c9a2edd452ff828277d85b1d18431d75, e30cb632e734394ddbd7bd62b57cee3586424352 and bf43e8a888cbee75e13622fea8a722b9d166c437 References: https://gitlab.gnome.org/GNOME/libxml2/-/commit/dd5adf54c9a2edd452ff828277d85b1d18431d75 https://gitlab.gnome.org/GNOME/libxml2/-/commit/e30cb632e734394ddbd7bd62b57cee3586424352 https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf43e8a888cbee75e13622fea8a722b9d166c437
Created attachment 252189 [details] Patch for libxml2 v8 Backport upstream patches 8699ba234b5a1328f0f30ca739b8f1dbc90ccf5e, a0330b53c8034bb79220e403e8d4ad8c23ef088f and ed8b4264f65b1ced1e3b13967dd1cf90102cfa40 References: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8699ba234b5a1328f0f30ca739b8f1dbc90ccf5e https://gitlab.gnome.org/GNOME/libxml2/-/commit/a0330b53c8034bb79220e403e8d4ad8c23ef088f https://gitlab.gnome.org/GNOME/libxml2/-/commit/ed8b4264f65b1ced1e3b13967dd1cf90102cfa40
Created attachment 252261 [details] Patch for libxml2 v9 Update to 2.13.3
Created attachment 253697 [details] Patch for libxml2 v10
Created attachment 255146 [details] Patch for libxml2 v11
Is there any timeframe for this update to happen?
The "major" blocker is www/webkit2-gtk* (listed in 279741) which is outdated (by ~2 years) and from what I can tell by looking at upstream supposedly have multiple CVE issues. If someone wants to "hotfix" it feel free to submit a patch otherwise we're looking at ~100 desktop ports or so not being available. x11-toolkits/wxgtk3* also depends on webkit2-gtk so that's why it's so "many" ports being affected.
Hi, I'd like to request an exp-run with following patches applied, https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255146 (this PR) https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251682 (PR 279976) https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251886 (PR 279741) Best regards, Daniel
Please combine all the patches in 1 patch
Created attachment 257570 [details] Exp-run patch Patch for exp-run
Some new failure logs: https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/cava-0.10.2_2.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/pinot-1.21_16.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/recoll-1.33.1_8.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/libaravis-0.8.20_3.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/php81-pear-1.10.13.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/apache-openoffice-4.1.15_4.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/apache-openoffice-devel-4.2.1731847285_3,4.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/citra-s20220902_3.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/virtualbox-ose-6.1.50_8.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/virtualbox-ose-legacy-5.2.44_27.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/virtualbox-ose-nox11-6.1.50_8.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/virtualbox-ose-nox11-legacy-5.2.44_27.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/connectagram-1.3.7.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/cutemaze-1.3.5.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/gottet-1.2.6.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/tanglet-1.6.7.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/librsvg2-2.40.21_4.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/rawstudio-2.0_26.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/openjfx14-14.0.2.1+1_16.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/py311-igraph-0.10.6_5.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/scilab-6.1.1_21.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/zabbix5-proxy-5.0.45.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/zabbix5-server-5.0.45.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/guacamole-server-1.5.5.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/yazproxy-1.3.9_3.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/orthanc-1.12.6.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/hs-cardano-cli-10.4.0.0.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/p5-XML-GDOME-0.86_5.log https://pkg-status.freebsd.org/gohan04/data/141amd64-default-foo/2025-02-18_07h40m21s/logs/errors/compiz-0.8.8_15.log
Created attachment 257626 [details] Patch for libxml2 v12 Version 2.13.6 , fixes CVEs
Since there doesn't seem to be any further progress on the remaining issues and there's nothing major known broken I'm going to suggest that we push libxml2 and friends this weekend and mark the rest as broken. This will also give us about one month to iron out the remaining ports (if anyone still wants to spend time on those) otherwise they'll be sunset and the tree will have versions supported by upstreams.
For zabbix5 ports, I'll update them as soon as the libxml2 update will be done.
(In reply to Daniel Engberg from comment #32) With desktop@ hat: absolutely not. The use of cmake is still not approved, and the legacy option is still missing. Having legacy enabled by default can significantly cut down on breakages. And again, libxslt needs to be approved and committed first.
This exp-run is not valid. Another will be requested later. This and libxslt need to be run and committed separately, as (slightly) newer libxslt can run with (slightly) older libxml2, but not necessarily the other way around. Some failures stem from libxslt, and not necessarily libxml2, changing things. Also for the aforementioned lack of the LEGACY option enabled by default.
(In reply to Charlie Li from comment #35) It's perfectly valid and you haven't listed any actual issues like the last time you tried to do the same and got told to stop being obstructive. Unit tests are as you've been told before are there for a reason.
(In reply to Daniel Engberg from comment #36) The actual issues that you choose to ignore are still present. Updated patches are inbound.
Created attachment 258048 [details] v13 - back to autotools - introduce legacy option - move Python child port to the correct package name - remove ICU option, broken and not upstream-recommended Once again, upstream designates autotools "for POSIX systems like Linux, BSD, macOS" directly in its README.md under build instructions. Until upstream changes this exact verbiage, no other arguments to using other provided build systems will be considered. Any exp-run has to be ran with the legacy option enabled. This is the FreeBSD ports tree where we have a diverse collection of software that is not necessarily always fully-updated or caught up to API/ABI changes. Yes, we should encourage keeping up-to-date, but it's ultimately up to each individual maintainer, both here and upstream. The legacy option buys time and reduces the supposed "obstruction" in that regard. The Python package name for the child port is libxml2-python, not libxml2. Consumers to have PORTREVISION bumps separately.
Comment on attachment 258048 [details] v13 And for the record, with autotools, the test suite ran via `make test` completely passes.
(In reply to Charlie Li from comment #39) You have yet to show what acutally breaks instead of just throwing around words, you're the only one obstructing similar to other PRs. Another exp-run is not need until 2.14 is out which is right around the corner and this way will skip a lot of ports as many also utilizes libxslt.
Created attachment 259342 [details] Patch for libxml2 v14 Backport upstream commits 19de8b47b1fe4b87b06bc6b89f5ee9697870a0ad and 5f3ca31dbb33abda5807dbc2e36d47417f43ed02 Notable changes: * Version script is removed upstream https://gitlab.gnome.org/GNOME/libxml2/-/commit/eed1a07d055d9592f13f42e9cc786f9664e733a5 * Trailing null bytes are detected as errors https://gitlab.gnome.org/GNOME/libxml2/-/issues/886 Issue(s) to monitor: https://gitlab.gnome.org/GNOME/libxml2/-/issues/889 References: https://gitlab.gnome.org/GNOME/libxml2/-/commit/19de8b47b1fe4b87b06bc6b89f5ee9697870a0ad https://gitlab.gnome.org/GNOME/libxml2/-/commit/5f3ca31dbb33abda5807dbc2e36d47417f43ed02
Created attachment 259343 [details] Exp-run patch
Hi, I'd like to request a new exp-run for 2.14-branch, patch is attched. Thanks in advance!
(In reply to Daniel Engberg from comment #43) Nope, not yet. ICU option needs to go, legacy option has to remain, Python child port name is still wrong. Also needs to be autotools still. In fact, since HTTP and LZMA are not part of the legacy option, may need to explore putting them in a legacy option group (enabled by default).
Comment on attachment 259343 [details] Exp-run patch Includes change suggested in PR 285738
(In reply to Charlie Li from comment #44) I'm going to simply direct you to portmgr at this point since you show the same tendencies as in 271673. ICU doesn't need to go and either way it doesn't affect the exp-run.
(In reply to Daniel Engberg from comment #46) Reminder that you are not the maintainer of this port. There are actual technical issues that need addressing. Also should not be requesting exp-runs when there are known unresolved breakages that should be fixed first. ICU was only implemented for exactly one use case: Chrome. As long as it still builds and our Chrome ports still need it, then it can stay but upstream does have it on the chopping block: https://gitlab.gnome.org/GNOME/libxml2/-/issues/819
(In reply to Charlie Li from comment #47) It's not a requirement and even so everyone is free to join any group if you want to use that card. You have yet to turn your claims into something that's usable information. What breakage are you talking about that we don't already know about that isn't documented? You've been asked multiple times and have yet to provide information. We also want to preserve POLA which have been brought up several times during port renaming discussions.
Created attachment 259556 [details] Patch for libxml2 v15 Fixes CVE-2025-32414 Backport upstream commits: 81f76df74f28a87680e3acbe8bfe5937b1315898 53d259454161eee801d22c56e08ea331b4c495b5 https://gitlab.gnome.org/GNOME/libxml2/-/commit/81f76df74f28a87680e3acbe8bfe5937b1315898 https://gitlab.gnome.org/GNOME/libxml2/-/commit/53d259454161eee801d22c56e08ea331b4c495b5
Created attachment 259641 [details] Patch for libxml v16 Fixes CVE-2025-32415
Hi, I'd like to request a new exp-run for the 2.14 series Thanks in advance, Daniel
@ portmgr Ping?
(In reply to Daniel Engberg from comment #52) ping what? there are still plenty of PR depending on this. And there are several exp-runs in the queue
(In reply to Antoine Brodin from comment #53) I apologize after asking for an update after more than a week with no response. The remaining ports are mostly leaf ports with patches that only works with newer versinos and/or will be sunset, we need to know what/if many major showstoppers remains.
(In reply to Daniel Engberg from comment #54) An exp-run can take 1 week to complete and there are a few in the queue
Some new failure logs: https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/mariadb1011-server-10.11.11.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/mariadb105-server-10.5.28.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/mariadb106-server-10.6.21.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/mariadb114-server-11.4.5_1.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/recoll-1.33.1_9.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/electron34-34.5.3.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/php81-pear-1.10.13.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/xeus-zmq-2.0.0_2.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/xmlcopyeditor-1.3.1.0_4.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/virtualbox-ose-6.1.50_12.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/virtualbox-ose-legacy-5.2.44_30.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/virtualbox-ose-nox11-6.1.50_12.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/virtualbox-ose-nox11-legacy-5.2.44_27.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/gnucash-5.11.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/armagetronad-0.2.8.3.5_4.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/librsvg2-2.40.21_4.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/rawstudio-2.0_27.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/openjfx14-14.0.2.1+1_16.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/py311-igraph-0.10.6_6.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/scilab-6.1.1_21.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/vcdimager-2.0.1_6.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/realmd-0.17.1_1.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/zabbix5-proxy-5.0.45.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/zabbix5-server-5.0.45.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/yazproxy-1.3.9_3.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/paraview-5.13.3.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/p5-XML-GDOME-0.86_5.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/xmlstarlet-1.6.1_4.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/redmine51-5.1.8.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/ungoogled-chromium-135.0.7049.114.log https://pkg-status.freebsd.org/gohan04/data/134amd64-default-foo/2025-05-05_20h23m05s/logs/compiz-0.8.8_15.log
This seems to fix the x11/mate-terminal random build failure. That said, I don't think that textproc/libxml2/files/patch-python_libxml.c is necessary. It's commit history says: -# Workaround https://bugzilla.gnome.org/show_bug.cgi?id=789714 -# Obtained from openSuse / Fedora In that bug ticket: Bug 789714 - crash: xmlParserPrintFileContextInternal mangles utf8 a similar fix is proposed. but comments 3 and 4 say a more complete fix should be done elsewhere in the code. Discussion continues in this ticket: https://gitlab.gnome.org/GNOME/libxml2/-/issues/64 This ticket was closed with this commit: https://gitlab.gnome.org/GNOME/libxml2/-/commit/76c6da420923f2721a2e16adfcef8707a2454a1b which was included in the 2.11.0 release.
Created attachment 260387 [details] Patch for libxml2 v17 Drop files/patch-python_libxml.c
Created attachment 260433 [details] Patch for libxml2 v18 Backport upstream patches cb7ded125e67264974262b94b3eb5ec1b02dd87b and 71f6a71deead836d53f756df5babfc3e380e8701 https://gitlab.gnome.org/GNOME/libxml2/-/commit/cb7ded125e67264974262b94b3eb5ec1b02dd87b https://gitlab.gnome.org/GNOME/libxml2/-/commit/71f6a71deead836d53f756df5babfc3e380e8701
From what I gather after reading all the comments, there are several distinct concerns: * CMake vs. autotools. I think we should stay with CMake now that port is already switched. I don't think we should switch it back and forth each time Charlie or Daniel does an upgrade. At the same time, I wasn't fond of switch to CMake to begin with, but I think this battle is over now. * Enabling the "legacy" option. I didn't get it from Charlie's comments why we do need it, but I also see no reason to not enable it, if it would help at least Charlie. * There is still quite a fallout from the update accroding to the last exp-run. I agree that it might be too demanding to ask Daniel to fix all of that himself, so maybe let's just wait until 2025Q3 is branched and fix what is possible to fix. This PR is taking too long already, so I'd rather push it and then fix the remaining stuff rather than waiting even more. @Charlie I feel like I'm sidestepping you on this, but unfortunately your reaction times is usually very long. I understand that you're busy with daily job, and I patiently waiting on glib and py-wheel cases, but it just isn't scalable. Sorry about that, but sometimes we need to move forward with maybe an imperfect solution rather than just sitting doing nothing.
(In reply to Gleb Popov from comment #60) It has never been about perfection, it's about a baseline sense of correctness such that others (particularly upstream projects) outside of our project cannot easily blame us for their bugs, amongst other things. cmake was absolutely the wrong choice. Upstream has always recommended autotools for "for POSIX systems like Linux, BSD, macOS", so that alone invalidates every other argument for any other build system. A previous iteration of the port using autotools may have used some local port patches, but that stemmed from a simple oversight which did not justify a wholesale build system switch on maintenance grounds. My autotools copy for this version (and previous versions before being superseded) did not need any local patches whatsoever. Additionally, cmake still has not achieved functionality parity with autotools. "They are receptive to improvements" is not an argument when autotools is still recommended. LEGACY has to be an options group now, since prior to this version it included HTTP and LZMA support [0]. Between 2.12-2.13, LEGACY kept a lot more symbols on life support [1] that consumers needed (and time to evaluate and fix). Previous exp-runs would not have as much fallout and port updates committed sooner had there not been some outside insistence to omitting this option. While the aforementioned symbols are a moot point with this version now, there may still be consumers of HTTP, LZMA and zlib support out there, so if anything helps to remove a few exp-run fallout during this cycle without doing too much "extra" work, specifically with those consumers, we should be doing that. [0] https://gitlab.gnome.org/GNOME/libxml2/-/commit/884c89969671d6daca3b08ddf99f3928d29216aa [1] https://gitlab.gnome.org/GNOME/libxml2/-/commit/cdc5cfed0b16ef4e0d75f08aead39870e553b47e
(In reply to Gleb Popov from comment #60) On the cmake vs autotools, as Charlie says, upstream says to use autotools. The current crusade to move everything that can be to cmake really needs to stop. The worst reason ever to go forward with a PR ever is "it's been open for too long". A PR will stay open and uncommitted for as long as it needs to be until everyone is satisfied. After a quick glance at the comment trail, the points to fix are switching back to autotools, and finish fixing the fallout.
Created attachment 260683 [details] v18, autotools edition LEGACY is an option group, since only zlib is part of the legacy option now. May need to re-run the exp-run with all of HTML, LZMA, ZLIB enabled since some consumers may still use them, which may reduce fallout somewhat.
Update: electron34 and ungoogled-chromium builds fine on 14.2-RELEASE (amd64) using current tree Multiple committers including pkgmgr have tested and/or resolved issues reported, there's no benefit in throwing that away now. We need to move on as there are multiple CVEs and our current version is unsupported upstream. As far as building framework goes, upstream currently have Autotools, CMake and Meson in tree. Meson is the newest addition and it needs more work for be on par with the other ones. We've carried patches/hacks for Autotools for years which no one bothered to upstream or seemlingly wanting to spend time on upstreaming. Found issues with current soulution have been reported, resolved upstream and there have also been other benefits from it. Either way, we should try to do a final push of fallouts and just move on after branching. 2.14.4 is probably released by then which contains a few fixes otherwise we can just backport. It would also be nice if we could include des@ PR ( https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/313 ) however it's not a showstopper. Looking at other distros some add legacy but do not enable http and lzma support, the few fallouts from exp-runs have been resolved.
..and given that py-libxml2 is getting deprecated upstream there's very little benefit in renaming it at this point and breaking POLA.
Created attachment 260686 [details] Patch for libxml2 v19 Backport upstream patches 9a8e9bf17a7ed0bd9b9bb7007ffcb7ba9893dcfc, 811cad9297912514a95b60534237925d80aa83b6 and c9fe8e1aa8b238aa41513501a445864afa894bc1 References: https://gitlab.gnome.org/GNOME/libxml2/-/commit/9a8e9bf17a7ed0bd9b9bb7007ffcb7ba9893dcfc https://gitlab.gnome.org/GNOME/libxml2/-/commit/811cad9297912514a95b60534237925d80aa83b6 https://gitlab.gnome.org/GNOME/libxml2/-/commit/c9fe8e1aa8b238aa41513501a445864afa894bc1
I presume Mat was speaking with portmgr@ hat on, so now there is no point in reuploading your patch over Charlie's one. It is now decided to switch the port back to Autotools. Can you please bring back Charlie's patch?
(In reply to Gleb Popov from comment #67) No idea as it's not being clear. I'll resign in that case as I have no interest in spending my time re-testing, making sure things works (again) and this also removes some .cmake helpers. It's also good way of wasting peoples time given what everyone have been testing and working on during this whole time. If anything, switch it next version or possibly look into Meson (which Arch already adopted) if that for whatever reason sits better with people. In general, The claim "My autotools copy for this version (and previous versions before being superseded) did not need any local patches whatsoever." is debatable as fetching patches from GitLab instances frequently break due to metadata changes, that's not something new and previous versions did in fact include local patches. "Previous exp-runs would not have as much fallout and port updates committed sooner had there not been some outside insistence to omitting this option." is dishonest given the amount of overall involvement in getting consumers ready and the fact that most failed to due other changes in upstream's code. www/webkit2-gtk* did get upgraded during this time which did fail however. It now also pulls in USES= autoreconf and gmake which it didn't do before.
Created attachment 260743 [details] v19, autotools edition USES=gmake was always required when using autotools; the local patches that existed for Makefiles were specifically to work around GNUisms that errored in bmake. These are part of the aforementioned oversights that were never corrected and did not warrant a full-scale change to a different build system against upstream's recommendations, even if they include different ones for different purposes. USES=autoreconf is required for at least this point release because a generated configure is no longer provided in the tarball. Direct upstream commits *always* take precedence over local patches. Local patches are based on the state after distribution patches are applied.
Created attachment 260841 [details] Patch for libxml2 v20 Backport upstream commits 509ea95aecabfaa7d8aafc1f84a85cf5d51f753b , acbbeef9f5dcdcc901c5f3fa14d583ef8cfd22f0 and 65304b699b6f61bf59c004dbc99a7425151812ca References: https://gitlab.gnome.org/GNOME/libxml2/-/commit/509ea95aecabfaa7d8aafc1f84a85cf5d51f753b https://gitlab.gnome.org/GNOME/libxml2/-/commit/acbbeef9f5dcdcc901c5f3fa14d583ef8cfd22f0 https://gitlab.gnome.org/GNOME/libxml2/-/commit/65304b699b6f61bf59c004dbc99a7425151812ca
(In reply to Charlie Li from comment #69) Upstream release tarball ships with a configure script and so have previous versions. https://download.gnome.org/sources/libxml2/2.14/libxml2-2.14.3.tar.xz What benefit is there in fetching patches if they break / cannot be verified due to checksum mismatch?
Patch from comment #70 applies cleanly for me and compiles with no problems. I'm holding off on installing it because I'm in the middle of updating chromium (for the latest security fix), even though I'll have to recompile it anyway. Thanks very much for all the work you have put into this!
Note for context: I use portmaster, not poudriere. So after applying the 2025-05-27 patch, I had to be a little careful in choosing the order to recompile everything that uses libxml2, and after a couple of flubs, I did textproc/libxslt and textproc/py-libxml2 before starting on all the other affected ports. They're still in progress but I'm optimistic.
I haven't yet been able to compile textproc/xmlstarlet with the patch applied, but I'm not using that port so I'm skipping it for now. I've been postponing updating llvm19, but I'll try that tonight. (Apparently I also need llvm14 to compile virtualbox-ose.)
(In reply to George Mitchell from comment #74) Hi, Have you tried applying patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279976 ? xmlstarlet is since long abandoned upstream and only 5 ports are still using it so I guess you're using one of these? Worth noting is that net/asterisk* doesn't declare xmlstarlet as a (build) dependency but usage is at least patched. security/gvmd games/colobot net/asterisk20 net/asterisk18 net/asterisk22 I've verified that all builds fine (gvmd shows qa error but unrelated to this change) except for net/asterisk18 that's still building as it pulls in llvm 14. Best regards, Daniel
(In reply to Daniel Engberg from comment #75) xmlstarlet builds fine on 14.2-RELEASE (amd64), 13.5-RELEASE (i386 and amd64) at least using Poudriere with patch applied.
May i ask, what the next steps about this update are? We'd like to quickly fix the open CVEs but there sadly aren't any patches for 2.11.9 and the upstream patches can't easily be applied either.
Trying to be a helpful user, I'll see what I can determine about all those "Depends on" bugs as soon as I get my own system in stable working order, which should be within a day and a half. But I personally think that May 31 patch will mostly do the job, and I thank you, Daniel Engberg!
(In reply to Dani I. from comment #77) Most known breakages are leaf ports and "not the end of world" if they break. java/openjfx14 is an exception however current version is ancient and from what I could gather having a quick look also have at least one low level known CVE. Other than that overall testing would be highly appreciated (and feedback), 2.13+ is much more strict that our current legacy version so there might be some silent (runtime) breakage. If any there's a higher probability to occur with GUI (Desktop) related applications as the tree in general tend to carry ports that lag behind upstream and/or are abandoned projects. We do of course also have non GUI ports sharing the same issues but they're fewer. With that being said, I've haven't experienced any so far but I'm using far from all affected ports.
New failure logs with patch v19 autotools edition: https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/mariadb1011-server-10.11.11.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/mariadb105-server-10.5.28.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/mariadb106-server-10.6.21.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/mariadb114-server-11.4.5_1.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/recoll-1.33.1_10.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/php81-pear-1.10.13.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/virtualbox-ose-6.1.50_14.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/virtualbox-ose-legacy-5.2.44_31.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/virtualbox-ose-nox11-6.1.50_14.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/virtualbox-ose-nox11-legacy-5.2.44_27.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/armagetronad-0.2.8.3.5_4.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/librsvg2-2.40.21_4.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/rawstudio-2.0_27.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/openjfx14-14.0.2.1+1_16.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/py311-igraph-0.10.6_6.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/vcdimager-2.0.1_6.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/realmd-0.17.1_1.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/zabbix5-proxy-5.0.47.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/zabbix5-server-5.0.47.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/liblinphone-5.4.4.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/p5-XML-GDOME-0.86_5.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/xmlstarlet-1.6.1_4.log https://pkg-status.freebsd.org/gohan06/data/142amd64-default-foo/2025-06-05_06h40m28s/logs/errors/compiz-0.8.8_15.log
zabbix 5.0 will not be fixed as it will expire on 20250630.
The virtualbox-ose errors should be fixed now; see bug #287284. I can compile virtualbox-ose-6.1 (etc.) here without problem.
Added a patch to fix x11-wm/compiz, bug #285906.
Added a patch to fix bug #279960, deskutils/recoll.
I took a look at bug #279961, math/py-igraph, but no fix yet.
(In reply to Antoine Brodin from comment #80) - MariaDB: bug 285895 - recoll: bug 279960 - php81: bug 280153 - virtualbox-ose: bug 287284 - armagetronad: bug 285901 - I will look into librsvg2 - rawstudio: bug 281593 - openjfx14: bug 280158 - py-igraph: bug 279961 - vcdimager: bug 285893 - realmd: bug 286785 - zabbix5 is expiring (comment 81) - liblinphone: ? - p5-XML-GDOME: ? - xmlstarlet: bug 279976 - compiz: bug 285906 None of these are from changing the build system, purely API changes.
Created attachment 261154 [details] v20, autotools edition Upstream commits in PATCH_FILES are fetched and used directly because that is where they come from, and our build process processes them as distribution patches before anything in ${PATCHDIR}. This allows matching the precise order that upstream committed them (since successive commits can modify the same file), preserves copyright and attribution per commit, and makes it easy on this end to add or remove commits as needed (like for updates). Patches in ${PATCHDIR} are to be based on the source state after PATCH_FILES are applied. The only checksum mismatches are either when the GNOME Project updates their GitLab instance where the patch file footers change across the board (mostly moot since the footer where the git version normally goes simply reads "GitLab" anymore), or repository growth necessitating displaying more characters in the short hash, so the contents can still be verified manually (before regenerating the checksums). USES=autoreconf was a holdover from when configure.ac, Makefile.am et al needed local modifications; it is better to modify those and regenerate than modify the provided generated assets directly. I just forgot to remove USES=autoreconf when those modifications were removed.
Created attachment 261155 [details] v21 (autotools) finish chasing the bsd.sites.mk update Regarding the Python port change: while there may be talk about deprecation upstream, we still have consumers. There are not many consumers so POLA hardly applies. Again, this rename/move is to follow the proper name of the Python package, as registered in a Python distribution (ie ${PYTHON_SITELIBDIR}), "libxml2-python", not "libxml2".
(In reply to Charlie Li from comment #88) This patch is missing pkg-descr for libxml2-python
(In reply to Einar Bjarni Halldórsson from comment #89) > This patch is missing pkg-descr for libxml2-python The pkg-descr file is not missing. The patch attached to comment #88 has to be applied with git: diff --git a/textproc/py-libxml2/pkg-descr b/textproc/libxml2-python/pkg-descr similarity index 100% rename from textproc/py-libxml2/pkg-descr rename to textproc/libxml2-python/pkg-descr
(In reply to Gunther Nikl from comment #90) Oh, sorry. I did apply the patch with `git apply` but I had to edit the patch since it wouldn't apply cleanly to MOVED. I must have messed it up when I edited it.