Diazo theme no longer working

python3 unicode errors.patch

1 Like

After a 3-week break, I'm giving the problem a fresh try. My current hypothesis is as follows:

  • InternalResolver successfully retrieves my rules.xml via "/++theme++/..."

  • BUT, somehow, lxml doesn't like the result (wrong type?) and then tries its built-in resolver, which tries to load "/++theme++/..." from the filesystem.

So, I'm trying to find if I should do something with the output of InternalResolver so that lxmlwill accept it.

1 Like

I tried a plain Plone 6.1.2 installation with older libxml2-2.11.9 and libxslt-1.1.43 packages from ports 2025Q2 branch on FreeBSD/amd64 14.3-RELEASE-p1. It works.

I suspect that the combination of the latest libxml2 and lxml is somewhat wrong.

1 Like

I agree :slight_smile: Actually, I settled for a similar solution: I "fished out" an old version of libxml2 from /usr/local/lib/compat/pkg, libxml2.so.2.11.9, and it allowed me to continue using my old lxml 4.8.0 egg. I regularly purge that directory on my machines, good thing I wasn't thorough...

Only, I renamed it from lxml-4.8.0-py3.9-freebsd-13.5-RELEASE-amd64.egg to lxml-4.8.0-py3.9-freebsd-14.3-RELEASE-amd64.egg so that I could rebuild the buildout if required, without it trying to recompile lxml 4.8.0.

Note about the FreeBSD packaging system:
When you upgrade a package, pkg moves existing shared libraries from /usr/local/lib to /usr/local/lib/compat/pkg, instead of just deleting them, in order to avoid possibly breaking other apps depending on the app being upgraded.

1 Like

PS: which means you can have both versions of libxml2 installed in the same time: the current one in /usr/local/lib, and the old/"good" one in /usr/local/lib/compat/pkg (it should also work in /usr/local/lib). No need to choose between them.

2 Likes

I found lxml bug report #2059910: version 5.2.0 causes an "Illegal instruction" crash.
And running buildout with CC=gcc14 CFLAGS=”-march=(proper one)” was successful.

2 Likes

Hi Hiroyuki,

I got stuck with “Illegal instructions” recently on a server. After investigating the problem (it took me some time…), I found out that the CPU was older than I remembered (Core 2 Quad Q6600, 18 years old (!)), and FreeBSD had probably recently changed their default C flags.

So, in the future, I’ll remember to check the age of the CPUs whhen I get that kind of problems :slight_smile:

1 Like

Incidentally (but I lack the motivation to experiment), it seems that libxml2 is evolving again, after having been left abandoned for months, so the problem may have been solved.

1 Like

I wrote a summary in Japanese. Intel(R) Xeon(R) CPU E3-1220 v5 and Intel(R) Pentium(R) CPU G3420 needed “-march=x86-64-v2”, and AMD Sempron(tm) 145 Processor needed “-march=k8-sse3”. Thanks.