Placeholder report for now, to coordinate testing and such because new major version once again brings API/ABI changes, but also textproc/libxslt > 1.1.43 requires at least this major version.
fwiw, 2.15.1 https://github.com/diizzyy/ports-overlay/tree/79aee3941fe2b1e654506a56de68a67c747d518a/textproc/libxml2 Works for me (tm) including building various ports
Created attachment 266536 [details] libxml2-2.15.1.patch https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.1
(In reply to takefu from comment #2) BUILD_DEPENDS= xsltproc:textproc/libxslt This causes circular dependency DOCS needs to be split out, also due to circular dependency and Python extension should be dropped
I think I have a working libxml2-docs split for good measure.
(In reply to Daniel Engberg from comment #3) why drop the Python extension?
Created attachment 266754 [details] patch to update libxml2 to 2.15.1, splitting out -docs and cleaning -python will seek approval of any of desktop@, ports-secteam@, portmgr@ This is a requisite for a security update of libxslt that has been required for months.
I'd like to see the same approach that was taken for devel/glib20 here. First of all, do we really need a new slave port for docs? If I understand it correctly, builds of libxml and libxml-docs differ only in a configure option and ${ALL_TARGET}. If that's the case, the FLAVORS approach would fit better. The second and most important thing is that in the glib20 case the default flavor provides all the features, while the bootstrap flavor is a "stripped" one that is used to break the cycle. In other words, I propose to have 1. textproc/libxml2@bootstrap, which is a libxml2 built without docs and thus not requiring textproc/libxslt 2. textproc/libxslt@bootstrap, which is a build of xsltproc linked to a "bootstrap" flavored libxml2 3. textproc/libxml2@default, which is a refular libxml2 build with BUILD_DEPENDS set to textproc/libxslt@bootstrap 4. textproc/libxslt@default, which is a usual build linked to a default libxml2 The problem with current approach is that when user does "pkg install libxml2", he gets a stripped down version of the software and has to additionally do "pkg install libxml2-docs" to get the full suite.
glib/gobject-introspection takes that approach because critical files needed by consumers are gated on satisfying the circular dependency at build time. I'm not sure if docs can be considered in the same vein. For this reason I'm also open to not shipping them, as they are the generated HTML developer documentation also available on gitlab pages.
Comment on attachment 266754 [details] patch to update libxml2 to 2.15.1, splitting out -docs and cleaning -python This comment serves as acknowledgement that this proposed patch is being evaluated and tested. Most of this is good. Apart from the -docs question, I'm not keen on including a patch that one of the now-current upstream maintainers hasn't updated since then.
Charlie, you don't get to cancel my requests for the soonest approval so we can have this fixed in due time. Charlie, what is the concrete test plan, and when can we expect to get this committed so we can fix libxslt? Cc:'ing core@. Gleb, I appreciate the suggestion, but I don't think flavors will work well here, at least not for the -python port, which already implies Python FLAVORS (and the autotools/pkg-config rig doesn't figure out anything about python-3.13t, the free-threaded variant, and barfs during configure claiming that python-3.13 is missing when it should go looking for python-3.13t - I have been unable to override that without attempting to patch a ton.) Gleb, Why would we need to have libxslt make similar dances? It already depends on libxml2, or could depend in your scenario on the libxml2@bootstrap, so can remain as a full-featured port.
(In reply to Matthias Andree from comment #5) It's disabled upstream and previous libxml2 maintainer has warned about using it due to poor quality and lack of maintenance (I don't recall the exact phrasing but its mention in at least one of the many PRs / Issue reports in upstream Gitlab project repo). There's also an open PR (we have already imported it) for lxml which is one of the last consumers in all major distros. https://gitlab.gnome.org/GNOME/libxml2/-/commit/fa931566d2f541d3162c7b98c8a12e6b2a6ae542 https://github.com/itstool/itstool/pull/57 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287143 deskutils/virt-manager is the last consumer in our tree and I think we can live with the fact that it may be temporarily broken (I haven't tracked upstream's progress lately). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289639
(In reply to Gleb Popov from comment #7) In worst case we can likely piggyback from another distro and use their docs package directly instead of jump through hoops just for the sake of it. The bootstrapping approach at least when it comes to glib is buggy when using ports (as in ports not Poudriere) as make clean / clean-depends doesn't clear all flavours when causes build issues later on so I'm not in favour of this approach.
lxml is popular downstream by Python ports still, so removing or breaking it is going to cause some uproar, and people would resort to installing python3-pip with all their stuff. Gleb, I wonder if flavors are as well-defined. They're non-trivial to make and seem to be somewhat easy to break. Unifying this probably worse than just renaming it to libxml2-core (or libxml2-bootstrap) and making a libxml2 meta-port and moving GNOME dependencies onto the -core package. People who only get it as dependency as run-time won't need the docs, people who "pkg install libxml2" get everything.
(In reply to Matthias Andree from comment #13) I'm not following you, lxml works fine and is already in (ports) tree
(In reply to Matthias Andree from comment #10) > Gleb, Why would we need to have libxslt make similar dances? It already depends on libxml2, or could depend in your scenario on the libxml2@bootstrap, so can remain as a full-featured port. Having libxslt@bootstrap allows for *-bootstrap packages to only be used inside the poudriere. On the client side running "pkg install libxslt" would result in installing libxslt@default and libxml2@default only. The circular dependency crap is hidden at the build stage.
(In reply to Daniel Engberg from comment #12) > The bootstrapping approach at least when it comes to glib is buggy when using ports (as in ports not Poudriere) as make clean / clean-depends doesn't clear all flavours when causes build issues later on so I'm not in favour of this approach. It is not the bootstrapping approach that is buggy, it is just "make clean" not cleaning all the FLAVORS is POLA violation. I think this should be fixed instead.
I think I have something coming up where we have: libxml2-core (that's the library port) libxml2 (that's the docs port) libxml2-python (that's the python port, to be deprecated and expired, but needs one or two consumers to be cleaned up) and the GNOME Uses framework points to libxml2-core as BUILD_ and LIB_DEPENDS, and libxml as RUN_DEPENDS.
(In reply to Matthias Andree from comment #10) You don't get to crash-out and complain when you don't get your way when actual objections have been raised. Since you insist, the plan is to come up with something that doesn't need to involve docs, ie can be dropped as it's not critical functionality. Patch to post immediately after this comment. exp-run it to check for consumer API/ABI breaks, and start getting those fixes (and maintainer approvals) moving. Concurrently, figure out how to deal with docs. If docs are not figured out after exp-run finishes and consumers fixed, commit without docs. https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/345 (by one of the current upstream maintainers) is not getting included here until it is committed upstream. A CI test upstream suggests this breaks API. (In reply to Matthias Andree from comment #17) Still need to think on this more. Unfortunately the doxygen overhaul they did also usurped man page generation, and that's more important to include in the "main" package than the HTML developer documentation.
Created attachment 266759 [details] without docs v0 (exp-run) textproc/libxml2-python: define DOXYGEN on the pre-build command line since it is otherwise undefined, causing this step to fail. textproc/libxml2: remove LZMA, removed upstream.
(In reply to Charlie Li from comment #18) > https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/345 (by one of the current upstream maintainers) This has since been rebased and CI passed, but still waiting on commit. Should not affect exp-run if upstream commits this in the meantime.
The upstream patch hasn't been provided by just anyone, but bears @suse.com, they do enterprise-grade Linux packaging FWIW. Since maintainership of libxml2 is in a state of flux, it's probably best to include it, it does not impair with self-docs.
Created attachment 266760 [details] alternative update patch that splits the library (not the docs) to a separate patch This patch shuffles ports around: - rename libxml2 to libxml2-core (without docs) - rename libxml2-docs (from prior patch) to libxml2 So we end up with three ports: - libxml2 (for normal users and RUN_DEPENDS) - libxml2-core (for bootstrapping libxml2, libxslt, and LIB_DEPENDS) - libxml2-python (now deprecated to match upstream intentions) It adds an UPDATING entry, but avoids the messy FLAVOR[S] dance in libxslt. libxslt "just works" as a plain update. This is what should be exp-run, too, because an exp-run with a half-baked update (suggested by vishwin@) isn't helping anyone.
Comment on attachment 266754 [details] patch to update libxml2 to 2.15.1, splitting out -docs and cleaning -python obsoleting this patch due to Gleb's comments.
Comment on attachment 266759 [details] without docs v0 (exp-run) This has been rejected by arrowd@ already. It should NOT be used.
Comment on attachment 266759 [details] without docs v0 (exp-run) Please don't speak for anyone else.
(In reply to Charlie Li from comment #25) If portmgr@ care to waste their time, their choice. @portmgr, please only use my patch for the exp-run unless you want to do two-exp runs, one half-baked and one real.
(In reply to Matthias Andree from comment #26) I don't think we need to make docs as much of a priority or a blocker to updating the library itself. It's not essential to the operation of the library. Therefore the patch without docs included is not half-baked. (In reply to Matthias Andree from comment #21) Doesn't mean much. There have been other proposed contributions from other prominent organisations to the upstream project trying to address vulnerabilities that, during review and testing, have found unnecessary or unintended API/ABI breakages, so they have not been committed. This one, the author and one of the current maintainers, just replied that it needs more work.
So we're back to square #one with Vishwin obstructing progress due to NIH syndrome. We have a solution including docs avoiding disruption on the table, why do you insist on wasting everyone's time with half-baked shit that strips the docs and needs revision?
Oh, and I have read the SUSE patch, it will change neither ABI nor API. It will change behavior though and was added to protect libxslt according to a proposal by the former maintainer, Nick Wellnhofer, who stepped down from libxml2 last year. Leaving vulnerabilites open is not an option if a solution is available until we know that solution causes regressions.
What should be done here: 1/ entirely disable doxygen. 2/ either prerender the manpages and put them in the files directory or use docbook2mdoc to render them at build time, (I checked it is not perfect, but neither is the conversion from docbook to manpage via xsltproc so) 3/ keep as a slave port the python thing for now (note it will be removed in 2.16) as virt-manager (and only virt-manager depends on it. Regarding the patches, for security vulnerabilities, none of the following downstream have committed any: - openbsd (they are on version 2.15.1) - debian (2.15.1 - they incorporated a patch which they later removed) - fedora (still 2.12 everywhere) - pkgsrc (still 2.14) - gentoo (2.15.1) - alpine Linux: 2.13.9 - Arch Linux (2.15.1) So I think we are good waiting for the patch to be merged. Which means if I am reading correctly the patches please to the exp-run Charlie's patch. Charlie, do you want me to amend your patch with use docbook2mdoc for us to get manpages again? (or maybe you prefer the pre-rendered) in anycase this does not block the exp-run
(In reply to Baptiste Daroussin from comment #30) So you suggest we follow the bad examples? That's not what I want FreeBSD ports to be and not how/why I came to FreeBSD.
(In reply to Baptiste Daroussin from comment #30) Baptiste, I'd like a technical explanation why your proposal is to add complextiy and more ports to get documentation when we already have something that desktop@ (Charlie) want to _test_ only, but are more or less already OK with it, modulo docs. See comment #9, later revised (see my comment #22 in response to Gleb's hint in #7 that we shan't surprise users by providing ports without docs).
(In reply to Baptiste Daroussin from comment #30) The recurring issue is that it takes us months to land PRs even security related as they're blocked by one person. Going with we're at least not the worst argument isn't constructive in trying to streamline the process. It's unclear if security is on portmgr's list of things to pay attention to given the previous events where Ports Security Team isn't recognized and some kind of clarification would certainly be beneficial so people know what to expect and where to put their time and efforts.
New failure log: https://pkg-status.freebsd.org/gohan06/data/143amd64-default-foo/2026-01-11_19h03m48s/logs/errors/xmlsec1-1.3.6_1.log 151 ports were skipped because of it
(In reply to Antoine Brodin from comment #34) Thanks for the exp-run. That issue is self-inflicted, that xmlsec1 beast uses -Werror to trip itself up over a minor issue. I'll try to have a look.
Created attachment 267121 [details] fallout fix: update xmlsec1 to 1.3.9 (from 1.3.6) to unbreak with libxml 2.15 Cc:ing hrs@-san because he maintains xmlsec1 @antoine, please try this incremental patch to unbreak xmlsec1, and if something else fails next time, please provide a list of skipped origins in the form category/portname (for instance, security/xmlsec1) so we have a quicker turnaround if someone wants to spend a local poudriere run first before submitting.
so, ports with libreoffice in the name account for 121 skips. These are the reamining 27 (sogo comes in four flavours): finance/aqbanking finance/gnucash finance/kmymoney finance/skrooge mail/py-django-mailman3@py311 net-im/py-matrix-synapse@py311 net-mgmt/netbox net-mgmt/peering-manager net/ocserv security/lasso security/oath-toolkit security/py-flask-saml@py311 security/py-pysaml2@py311 security/py-python3-saml@py311 security/py-social-auth-core@py311 security/py-xmlsec@py311 sysutils/pass-otp sysutils/plasma-pass www/mod_auth_mellon www/py-dj52-social-auth-app-django@py311 www/py-django-allauth@py311 www/py-djangosaml2@py311 www/py-hyperkitty@py311 www/py-postorius@py311 www/py-social-auth-app-django@py311 www/seahub www/sogo@mysql www/sogo@mysqlactivesync www/sogo@pgsql www/sogo@pgsqlactivesync
I haven't attempted to build libreoffice yet, everything else built nicely with both attachments https://bugs.freebsd.org/bugzilla/attachment.cgi?id=266760 and https://bugs.freebsd.org/bugzilla/attachment.cgi?id=267121 applied.
[00:17:31] Logs: /usr/local/poudriere/data/logs/bulk/150amd64-default/2026-01-15_01h47m59s [01:21:16] [01] [01:17:02] Finished editors/libreoffice | libreoffice-25.8.4.2: Success [01:21:21] [01] [00:00:00] Building german/libreoffice | de-libreoffice-25.8.4.2 [01:22:14] [01] [00:00:53] Finished german/libreoffice | de-libreoffice-25.8.4.2: Success
Exp-run looks fine
Created attachment 267274 [details] tarball with 4 git format-patch patches This tarball contains four patches made with "git format-patch" that improves upon 266760 by adding LIB_DEPENDS=libxml2.so:textproc/libxml2-core - this avoids a shitload of changes in ports that use libxml2, and achieves: * documentation built natively on FreeBSD, with xsltproc (from a port I am updating inline) * dependency chain: libxml2->libxml2-core, libxslt libxslt->libxml2-core Where libxml2-core has the libxml2.so and the executables (usually xmllint). Especially, we're avoiding this way: * no loss of documentation or its accuracy * no loss of native build * no surprises for end users, pkg install "libxml2" gives them docs + binaries + lib as before * no dance in downstream ports around @bootstrap flavors. While here, it deprecates libxml2-python to be honest about upstream intentions to kill that bit. It collects the xmlsec1 patch and adds the missing libxml2 dep to one port.
I should add that libxml2 then is the "docs" port that depends on the binaries and libs, and libxml2-core is the libraries core. I have heard criticizm that this is inconsistent, but as long as we do not have a canonical reference on how to avoid circular dependencies, every port is free to serve best, and we can add a better way compared to ports that solved similar issues before but did so in a more complex and complicated manner.
Re exp-patch, the direct libxml2* deps (not through the USES framework) except lang/swift510 build fine in my poudriere on 14.3-amd64, lang/swift510 hasn't built yet (it's a big port), I'll get "everything libxml2" test built over night.
Comment on attachment 267274 [details] tarball with 4 git format-patch patches LZMA support is removed, including that the configure flag no longer exists. The upstream issue for removing -python https://gitlab.gnome.org/GNOME/libxml2/-/issues/891 is still open. While this can signify dissatisfaction in the bindings' continued presence, no firm action has been taken by the current maintainers, so EXPIRATION_DATE is premature. Not to mention one consumer still uses it unfortunately. At most DEPRECATED without a date is fine. The current upstream maintainer has completed work on the XPath stuff and is now committed as https://gitlab.gnome.org/GNOME/libxml2/-/commit/0e50b31902cdb1eb242eb361c123e9e033b2af87 ; please use this commit directly (verified applies cleanly). net/pacemaker2 currently does not have a port maintainer so not sure why it's lumped in here, it could have been committed already. May also be a good idea to split security/xmlsec1 into a separate PR for approval since it has not been provided yet. Not totally satisfied with this design of providing docs. For the value that docs provides, it does not warrant a dance of flavours or child ports, unlike the bootstrap method from devel/glib20 and devel/gobject-introspection. The gtk-doc portion, ie the API documentation which are all HTML files, already live online as https://gnome.pages.gitlab.gnome.org/libxml2/html/index.html , so while nice to have locally, is not a priority if it introduces unnecessary complexity to build them. This leaves the man pages, which I'm more inclined to take bapt@'s approach of pre-rendering them or use docbook2mdoc at build time.
If people (diizzy, vishwin) would just stop whining and instead point out CONCRETE issues with the build approach (i. e. what breaks that did work before), we could go to fixing, instead of obstruction and blocking things from moving.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d3d978dc3979866f865b4a9e7570a283142fdb73 commit d3d978dc3979866f865b4a9e7570a283142fdb73 Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2026-01-19 20:22:18 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2026-01-19 20:27:12 +0000 textproc/p5-XML-GDOME: unbreak w/ newer libxml2 ...and add the missing #include lines. While here, fix up the dependencies. Approved by: portmgr@ (just-fix-it blanket approvals) PR: 291316 textproc/p5-XML-GDOME/Makefile | 4 ++-- textproc/p5-XML-GDOME/files/patch-GDOME.xs (new) | 12 ++++++++++++ textproc/p5-XML-GDOME/files/patch-dom.h (new) | 11 +++++++++++ 3 files changed, 25 insertions(+), 2 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d762b33dbaa8c8fba1f3cdc252ccff39d8782e72 commit d762b33dbaa8c8fba1f3cdc252ccff39d8782e72 Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2026-01-18 19:32:38 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2026-01-19 20:27:12 +0000 net/pacemaker2: add missing libxml2 dependency related to PR: 291316 net/pacemaker2/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
I use my own overlay ;-) Anyhow, this seems to work on my end avoiding circular dependencies https://github.com/diizzyy/ports-overlay/commit/5d626236495780da858be05f64ebaff92c96d190
(In reply to Daniel Engberg from comment #48) What's the retention time for the job artifacts on gitlab.gnome.org? Gitlab will sooner or later discard them.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f09a210a25c877e8f82a8cde9aff64eb5cd958fc commit f09a210a25c877e8f82a8cde9aff64eb5cd958fc Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2026-01-13 18:20:05 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2026-01-20 16:48:51 +0000 security/xmlsec1: update to v1.3.9 This unbreaks libxml 2.15, where some pointer types went "const", and the prior FreeBSD ports version of xmlsec1 wanted to error out instead of seeing warnings (-Werror) and broke. ChangeLog: https://www.aleksey.com/xmlsec/news.html required for: PR: 291316 (This builds with extant libxml2.14 and 2.15, so let's just commit this.) security/xmlsec1/Makefile | 12 +++++++----- security/xmlsec1/distinfo | 6 +++--- 2 files changed, 10 insertions(+), 8 deletions(-)
(In reply to Matthias Andree from comment #49) Probably not infinitive but it's a protected tag so it shouldn't at least be overwritten by another job. https://gitlab.gnome.org/GNOME/libxml2/-/pipelines/929155 https://docs.gitlab.com/ci/jobs/job_artifacts/#with-an-expiry I do not know what setting(s) gnome are using, however one could ask upstream for pre-rendered docs next release.
Created attachment 267346 [details] next iteration of libxml2 patch fixes LZMA leftover (removing it), adds a pre-everything:: sanity check for ports users to give them instructions, touches up a minor glitch in Mk/Uses/gnome.mk that referred to an interim libxml2-docs port in libxml2_RUN_DEPENDS, refreshes the xpath.c patch from what upstream merged, removes the unneeded pre-build part from libxml2.
Created attachment 267347 [details] libxslt security update patch refreshed in context with the libxml2 patch
Created attachment 267348 [details] INFO: libxml2 changes vs. previous iteration This diff is for perusal only and diffs libx* (skipping the Mk/Uses/ part) from the prior four-patch-tarball, to see what's new more easily. This is not to be committed!
Created attachment 267350 [details] next iteration of libxml2 patch (I guess this might be v5.1 now), adding PATCH_STRIP=-p1 after the xpath.c patch efresh we need PATCH_STRIP=-p1, the refreshed patch has a/xpath.c and b/xpath.c now that need to be stripped
Created attachment 267351 [details] INFO: libxml2 changes vs. previous iteration (refreshed for 267350)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=099bd713e09ebdd02d73fde770c50706f980404f commit 099bd713e09ebdd02d73fde770c50706f980404f Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2026-01-02 15:10:37 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2026-01-26 21:47:50 +0000 textproc/libxml2*: update to 2.15.1, split -core libxml2 now requires xsltproc from libxslt to build, yet libxslt depends on libxml2, so we need to break a dependency cycle. documentation needed to be split out to a separate port. libxml2 has therefore been split into two ports, * libxml2 builds the documentation (unless disabled), * library and executables in libxml2-core. Pull in one contributor patch suggested by the former libxml2 maintainer to address one downstream security issue in recent libxslt versions. This should address arrowd@'s hint that installing libxml2 should provide a full-featured package. While here, deprecate libxml2-python according to upstream plans, we have very few users in the ports tree, and expire end of 2026Q1. PR: 291316 Mk/Uses/gnome.mk | 6 +- UPDATING | 12 +++ textproc/Makefile | 1 + textproc/libxml2-core/Makefile (new) | 67 ++++++++++++ textproc/libxml2-core/distinfo (new) | 3 + textproc/libxml2-core/files/patch-xpath.c (new) | 130 ++++++++++++++++++++++++ textproc/libxml2-core/pkg-descr (new) | 4 + textproc/libxml2-core/pkg-plist (new) | 55 ++++++++++ textproc/libxml2-python/Makefile | 39 +++++-- textproc/libxml2/Makefile | 92 ++++++++--------- textproc/libxml2/distinfo (gone) | 3 - textproc/libxml2/pkg-descr | 5 +- textproc/libxml2/pkg-plist | 117 +-------------------- 13 files changed, 348 insertions(+), 186 deletions(-)
This has been cooking for eight weeks, and we need this in combination with libxslt to fix things. Let's take it forward and improve incrementally from the commits and MFH around Feb 7th.
No it has not been cooking for eight weeks. In fact, every iteration resets the timeout counter. And speaking of that, you did not provide the maintainer of security/xmlsec1 the proper period to review that portion. desktop@ has not approved any of these at all, and further, has explicitly disapproved this design of splitting. These will be reverted.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=fc6c145ef01c3418d7db4e7be89310d3f6225171 commit fc6c145ef01c3418d7db4e7be89310d3f6225171 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2026-01-27 02:13:49 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2026-01-27 02:34:39 +0000 textproc/libxml2: really update to 2.15.1 Changelog: https://gitlab.gnome.org/GNOME/libxml2/-/blob/2.15/NEWS Notably, all documentation generation requires a circular dependency on textproc/libxslt. While the API documentation, in HTML, lives on the upstream site [0], the man pages are now pre-rendered manually. Also includes an upstream commit addressing unsafe pointer usage in XPath, leading to security bugs in consumers like libxslt (CVE-2025-10911). [1] Mark the -python child port DEPRECATED without expiration date since upstream has not provided a firm one yet, particularly the release schedule for the next major version 2.16. [0] https://gnome.pages.gitlab.gnome.org/libxml2/html/index.html [1] https://gitlab.gnome.org/GNOME/libxml2/-/commit/0e50b31902cdb1eb242eb361c123e9e033b2af87 Event: Snowstorm Special January 2026 With hat: desktop PR: 291316 textproc/libxml2-python/Makefile | 13 +- textproc/libxml2/Makefile | 40 +- textproc/libxml2/distinfo | 8 +- textproc/libxml2/files/xml2-config.1 (new) | 32 ++ textproc/libxml2/files/xmlcatalog.1 (new) | 355 ++++++++++++++++ textproc/libxml2/files/xmllint.1 (new) | 656 +++++++++++++++++++++++++++++ textproc/libxml2/pkg-plist | 64 +-- 7 files changed, 1083 insertions(+), 85 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=5137742117b09d8dc550eb7b67dde5ab902fcdbf commit 5137742117b09d8dc550eb7b67dde5ab902fcdbf Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2026-01-27 02:07:42 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2026-01-27 02:34:37 +0000 Revert "textproc/libxml2*: update to 2.15.1, split -core" The design of this update was repeatedly rejected in the linked PR with a prescribed different design. This commit is therefore unauthorised. This reverts commit 099bd713e09ebdd02d73fde770c50706f980404f. With hat: desktop (textproc/libxml2), gnome (USES=gnome) PR: 291316 Mk/Uses/gnome.mk | 6 +- UPDATING | 12 --- textproc/Makefile | 1 - textproc/libxml2-core/Makefile (gone) | 67 ------------ textproc/libxml2-core/distinfo (gone) | 3 - textproc/libxml2-core/files/patch-xpath.c (gone) | 130 ----------------------- textproc/libxml2-core/pkg-descr (gone) | 4 - textproc/libxml2-core/pkg-plist (gone) | 55 ---------- textproc/libxml2-python/Makefile | 39 ++----- textproc/libxml2/Makefile | 92 +++++++++------- textproc/libxml2/distinfo (new) | 3 + textproc/libxml2/pkg-descr | 5 +- textproc/libxml2/pkg-plist | 117 +++++++++++++++++++- 13 files changed, 186 insertions(+), 348 deletions(-)
A commit in branch 2026Q1 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=87a0c21fa5687cc9020f2a94c02fef2721e8f1d9 commit 87a0c21fa5687cc9020f2a94c02fef2721e8f1d9 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2026-01-27 02:13:49 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2026-01-27 02:43:01 +0000 textproc/libxml2: update to 2.15.1 Changelog: https://gitlab.gnome.org/GNOME/libxml2/-/blob/2.15/NEWS Notably, all documentation generation requires a circular dependency on textproc/libxslt. While the API documentation, in HTML, lives on the upstream site [0], the man pages are now pre-rendered manually. Also includes an upstream commit addressing unsafe pointer usage in XPath, leading to security bugs in consumers like libxslt (CVE-2025-10911). [1] Mark the -python child port DEPRECATED without expiration date since upstream has not provided a firm one yet, particularly the release schedule for the next major version 2.16. [0] https://gnome.pages.gitlab.gnome.org/libxml2/html/index.html [1] https://gitlab.gnome.org/GNOME/libxml2/-/commit/0e50b31902cdb1eb242eb361c123e9e033b2af87 Event: Snowstorm Special January 2026 With hat: desktop PR: 291316 (cherry picked from commit fc6c145ef01c3418d7db4e7be89310d3f6225171) textproc/libxml2-python/Makefile | 13 +- textproc/libxml2/Makefile | 40 +- textproc/libxml2/distinfo | 8 +- textproc/libxml2/files/xml2-config.1 (new) | 32 ++ textproc/libxml2/files/xmlcatalog.1 (new) | 355 ++++++++++++++++ textproc/libxml2/files/xmllint.1 (new) | 656 +++++++++++++++++++++++++++++ textproc/libxml2/pkg-plist | 64 +-- 7 files changed, 1083 insertions(+), 85 deletions(-)
(In reply to Charlie Li from comments #59...#63) That's pretty bold to state it was unapproved or unauthorized or whatever (in comment #61) when a prior version had already been approved and then later refined, after justified criticism that the update should not obliterate the documentation, with the formal maintainers not delivering on the documentation for weeks on end. There was NO mention of what would have been broken technically by the bits I'd committed. I asked several times, no mention. What I committed in https://cgit.freebsd.org/ports/commit/?id=099bd713e09ebdd02d73fde770c50706f980404f kept the entry point libxml2 that installed documentation and binaries, it kept dependencies of all ports I tested working in my 2000+ ports test build, we fixed xmlsec1 (*) that was a blocker to many downstream ports, but except "not invented here, by vishwin@" no technical issue was mentioned. Then my good solution got reverted, and replaced by an inferior and more costly approach: One that raises technical debt, that bears the risk of delaying future updates (that are already slow) even more, or risks getting them incomplete, in that it burdens libxml2 maintainers with a manual build of documentation prior to commit. This all in a situation where the current maintainer role failed to deliver the update in over three months - although it had always been known to fix vulnerabilities not only in the port itself but also one of the companion downstream ports, libxslt. NB: I am not saying that being overloaded is bad in a volunteer-driven project, but I will say that increasing the maintenance burden on an already overloaded role is a bad decision.
xmlsec1 upgrade to 1.3.9 didn't reach quarterly (2026Q1) while libxml-2.15.1 did, xmlsec1-1.3.6 cannot build here…
A commit in branch 2026Q1 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=dae25dcecc6fbc70962f3716fd35f66026a40cd0 commit dae25dcecc6fbc70962f3716fd35f66026a40cd0 Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2026-01-13 18:20:05 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2026-01-28 18:48:16 +0000 security/xmlsec1: update to v1.3.9 This unbreaks libxml 2.15, where some pointer types went "const", and the prior FreeBSD ports version of xmlsec1 wanted to error out instead of seeing warnings (-Werror) and broke. ChangeLog: https://www.aleksey.com/xmlsec/news.html required for: PR: 291316 (This builds with extant libxml2.14 and 2.15, so let's just commit this.) (cherry picked from commit f09a210a25c877e8f82a8cde9aff64eb5cd958fc) security/xmlsec1/Makefile | 12 +++++++----- security/xmlsec1/distinfo | 6 +++--- 2 files changed, 10 insertions(+), 8 deletions(-)
(In reply to geoffroy desvernay from comment #64) It was missed in the MFH (as was libxslt that got MFH'd already). Fixed now & thanks for reporting this omission.
Seems we're now in a situation where the upstream FreeBSD-ports-latest repo at least for FreeBSD 15 holds the interim libxml2/libxml2-core split that got superseded by a monolithic approach. This is extremely confusing, so I will push a PORTREVISION bump to flush out the binary packages that have a libxml2-core dependency and get them rebuilt, to get binaries back in line with what is the port's status.
The branch main has been updated by mandree: URL: https://cgit.FreeBSD.org/ports/commit/?id=06690d64296464685b18299a802875606f56bc99 commit 06690d64296464685b18299a802875606f56bc99 Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2026-01-28 19:02:15 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2026-01-28 19:02:15 +0000 textproc/libxml2: bump PORTREVISION to force rebuild FreeBSD-ports-latest - for FreeBSD 15 - currently carries packages that have the libxml2-core package as a dependency (and the libxml2-core). Bump PORTREVISION to force the package builder to resynch onto ports where there is no libxml2-core package, to reduce confusion. (2026Q1 is unaffected, it did not have this change.) --- textproc/libxml2/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/textproc/libxml2/Makefile b/textproc/libxml2/Makefile index eeec6359b550..030ed280f9e8 100644 --- a/textproc/libxml2/Makefile +++ b/textproc/libxml2/Makefile @@ -1,5 +1,6 @@ PORTNAME?= libxml2 DISTVERSION= 2.15.1 +PORTREVISION= 1 CATEGORIES?= textproc gnome MASTER_SITES= GNOME DISTNAME= libxml2-${DISTVERSION}