Hi,

I tried to do some RC bug fixing to help the release and stumbled upon #1060960. It is tagged patch and was forwarded upstream. But I can't
find anything like a patch. Is this tag valid in this case?

Kind regards
Andreas.

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

I believe the patch tag was inherited from #1061025 that has an
associated MR[1]. This is not a true solution, merely a workaround to
resolve the circular dependency causing this issue.

Best Regards,
Vladimir.


[1] https://salsa.debian.org/java-team/libcommons-logging-java/-/merge_requests/7

On Fri, Apr 11, 2025 at 6:39 PM Andreas Tille <andreas@an3as.eu> wrote:

Hi,

I tried to do some RC bug fixing to help the release and stumbled upon #1060960. It is tagged patch and was forwarded upstream. But I can't
find anything like a patch. Is this tag valid in this case?

Kind regards
Andreas.

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: tag -1 - patch

On Fri, 11 Apr 2025 18:44:22 +1200 Vladimir Petko <vladimir.petko@canonical.com> wrote:

Hi,

I believe the patch tag was inherited from #1061025 that has an
associated MR[1]. This is not a true solution, merely a workaround to
resolve the circular dependency causing this issue.

[...]

Right, so I'm removing the patch tag.

I tried bisecting the changes between bookworm and unstable to find the
source of the breakage:

- bookworm: success
- unstable snapshot 20230630T210935Z: success
- unstable snapshot 20240531T143744Z: failure (tests complete)
- unstable snapshot 20241115T204403Z: failure (tests hang)
- unstable snapshot 20240823T205308Z: failure (tests complete)
- unstable snapshot 20241008T203645Z: failure (tests complete)
- unstable snapshot 20241026T203202Z: failure (tests hang)
- unstable snapshot 20241017T204911Z: failure (tests complete)
- unstable snapshot 20241022T083247Z: failure (tests complete)
- unstable snapshot 20241024T143718Z: failure (tests hang)
...
- unstable snapshot 20241024T083042Z: failure (tests complete)

(For the purposes of this bisection I treated test failures without a
hang as "good" because that's not the issue reported, though they may in
fact be related.)

So then I compared the build dependency versions in the last good and
first bad snapshots, and tried upgrading the Java packages one by one.
The result was that libsurefire-java (= 2.22.3-3) made the difference:

surefire (2.22.3-3) unstable; urgency=medium

* Team upload.
* No longer build maven-surefire-report-plugin
* Removed the unused dependency on velocity
* Standards-Version updated to 4.7.0

-- Emmanuel Bourg <ebourg@apache.org> Thu, 24 Oct 2024 14:27:13 +0200

Now, the test failures have tracebacks like:

java.lang.IllegalStateException: Recursive update
at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1763)
at org.apache.commons.logging.impl.Slf4jLogFactory.getInstance(Slf4jLogFactory.java:286)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:999)
at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:77)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
at org.apache.commons.logging.impl.Slf4jLogFactory.lambda$getInstance$0(Slf4jLogFactory.java:287)
at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708)
at org.apache.commons.logging.impl.Slf4jLogFactory.getInstance(Slf4jLogFactory.java:286)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:999)
at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:77)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
at org.slf4j.InvocationTest.testNull(InvocationTest.java:89)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:61)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)

So I don't know that this is really a regression in surefire, or whether
the plugin that was removed just happened to interact with the bug and
changed it from a deadlock into an exception.

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgOhf8ACgkQ57/I7JWG EQnEpxAAiuQ+PVKxrMSLKbks0sUz3+gJwvLcSeJ72MqOqNkexoefuXzkxUeXjB3Q Yw20tgWpt9PDv71aEJFcHPz1C+wbTAOrV7lVijzm7AWbsnmMY0JsD24188Yabrst i9QAHBdHm5qqREl3np9nmqp1aQ8iohouVzfEYdGSmjBKoD3UuxriLd+H/Wp23DIR R9GFE4Ni+qAmK2VFBNBbWA2iU1V72O6HSfvOkf2Tp/V3JBlZX3zdsC5fOHGRCzE4 VQ1gEtbYMdco+Gs1Y/vQuY2DSzsEqB0SJEPzx6clYPV/Zo9Z6P0Kp2JC+4uXy7qu SkufcYx76OK1KEo4XPSCIaodPsZuQ9W/2q+bU7lE5N2dLxS5w8wej9jj4vqgj79g GxdOk3rnHCrHa84FtMNf4Cm0c1161KAZlFxMO5yxgLAWkAkbP4WhJ6HpLF7hQ0hx IpA8IE3YI68da/79As2Ov/0TFMxI2hj+G8VQs/ylvBvYL5hx0AHUi7IZQp4xvYj6 7zzy3dKNNA6z2FL061nWmxfqoOMpFJgnKwGZo0LhBCczDtKWIVq2y+E5W5ZYxCZA a2NXrbkqACm7kOvXSynEOrWZmvVIaRM6S4hY8aHC3yAcs8LXuGAJvlIkBjCOIjqi jKBDq5t2yNsEftS2KCq/+Dc9DSwkiZ8L4LrgQo/VJrraumSALiI=
=llPi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2025-04-28 at 15:49 +0200, Ben Hutchings wrote:

On Mon, 2025-04-28 at 08:31 +0200, Emmanuel Bourg wrote:

[...]

* the test freeze is surprising, the test threads seem to be idling for
an unknown reason. maven-surefire-report-plugin 2.22.3 isn't compatible with maven-reporting-api 4.0 used by the version of Maven in Debian.
We'll have to upgrade surefire to the latest version to fix this, but
this won't be possible before Forky (too much impact on other Maven components). I recommend disabling the slf4j tests for now.

That would be unfortunate. And I wonder if we wouldn't end up with the
same issue in sfl4j's reverse-dependencies.

Actually I am confused by this: I was able to build with everything else
from current unstable and only libsurefire-java downgraded.

So I wonder just how incompatible that plugin really is.

Of course it could be that the incompatibility causes a quiet fallback somewhere and that is what avoids the hang.

Anyway, I think I am done with this bug. Good luck!

Ben.

--
Ben Hutchings
Kids! Bringing about Armageddon can be dangerous. Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgPjzEACgkQ57/I7JWG EQk0Ww//RrNvnne2smXT5L/Ud655nb/BqQQTo9JK3LY8oqbCQbU0NCkXfMHHJVtr NzdEarw0I2JKEu1NT1uCrvWtNSQHxu74yGt11t23ibctv18MWVHgB8vbjJkJNId4 8Opf68kyuXA4kkO/sHWq+S3SPM3xI2jzBEg0rUR41stVn6arNK0slCzr578k9mqS 0DiQv8OZNMmhagvCkqK+6fk70X3Gn63/haW3Jw4U5UNkLtnD0H5KZSwuxEJlX0ot VtqEXyOwUb9P32TPY+HhhhQn2xoU8j/KlVDEiaVZIgPDNfX+FUoWieeQCzzxgdFL c9NnURSMU/DxUoal08wsRsvvmjk4bVPnZsyJE/wuC+NHOu/bMisbNuhheolc3QKT IUUcUIZY6ofqfePhsYcxM9dJjBi3aoSVm0OQjnx4bBybfGt7BFpHPLkyTckfTsHz KbCgm1MfPEU8C7i6BOojM95C3fHXHmB79OQHMer7Q/0JY4AfEBtQYyOVzY686Qgk d9ndZ3hG3p3NjD/9GvmJbKkMAMFIz+lppHfiq+bYHMaBF4VVDgxe9l7UOdAr4K59 h1jPhMhBHYro97Kps26XR0BYGlXE/uVN4AMjwFSRGfu/1HTKmhkrM6vqC885oGuE tP0mItZtxFfoYMstRhXFCMzdjJplNUAdncC1mPjRILCY+jNbNcY=
=30Do
-----END PGP SIGNATURE-----

--- SoupGate-

On 28/04/2025 16:22, Ben Hutchings wrote:

It turns out that it is possible to do this from the slf4j side, by
replacing the Slf4jLogFactory class. See the attached patch. With
the patch applied and libsurefire-java downgraded, the tests pass.

Slf4jLogFactory is called from LogFactory which is already replaced by
slf4j, so I don't think replacing Slf4jLogFactory if useful if
jcl-over-slf4j is already on the classpath.

I recommend disabling the slf4j tests for now.

That would be unfortunate. And I wonder if we wouldn't end up with the
same issue in sfl4j's reverse-dependencies.

A few unit tests may break, but that shouldn't affect applications at
runtime since commons-logging and jcl-over-slf4j shouldn't be
simultaneously on the classpath.

For example pdfsam has jcl-over-slf4j.jar in /usr/share/pdfsam/lib/ but
not commons-logging.jar. Same thing for Maven in /usr/share/maven/lib/. openrefine on the other hand has both (in /usr/share/openrefine/webapp/WEB-INF/lib/) and that seems wrong.

Actually I am confused by this: I was able to build with everything else
from current unstable and only libsurefire-java downgraded.

So I wonder just how incompatible that plugin really is.

Of course it could be that the incompatibility causes a quiet fallback somewhere and that is what avoids the hang.

It's source and binary incompatible, but the report plugin is never used
in Debian (it generates an HTML report of the unit tests, we never use
that when building packages), so it never blows up.

We could try restoring the reporting plugin, but commenting the
incompatible code. That may be enough to fix the freezing tests.

Anyway, I think I am done with this bug. Good luck!

Thanks again for the help, it's nice to have a kernel guru tackling
Maven issues :)

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2025-04-28 at 17:38 +0200, Emmanuel Bourg wrote:

On 28/04/2025 16:22, Ben Hutchings wrote:

It turns out that it is possible to do this from the slf4j side, by replacing the Slf4jLogFactory class. See the attached patch. With
the patch applied and libsurefire-java downgraded, the tests pass.

Slf4jLogFactory is called from LogFactory which is already replaced by slf4j, so I don't think replacing Slf4jLogFactory if useful if jcl-over-slf4j is already on the classpath.

[...]

There are 2 different class names, differing only in capitalisation:

1. SLF4JLogFactory: defined in jcl-over-slf4j
2. Slf4jLogFactory: defined in commons-logging since 1.3.0

This adds a replacement for (2) to slf4j-jcl to break the recursion.

Ben.

--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgSIVEACgkQ57/I7JWG EQm3ghAAxST4faojht7zU+K7Qhi92eZh29qVdhetNxDWzAP7j7+UFgWGwZClmyeG oqlOAVUVvtUBjMII+mc25PSqKF0eVnUTsOMK8T+0Ic/hBRESKaGCj36wNg5WmKQP ulBG2Iz+mBKSy2cLcQP8ByHVxtBNQkzmSFNl6bx3otRSgyUbhMpifJxAr2f1/bqX kJfABccHCE22No68zDr1lj7OBI7u6zX79+KqHgbJcREx1/sy4h6AEBu+QwwfSwGx 1AQkzqH2qA25q7YHvdxOI2QhOMCUrGU0VPDVAauFbqSjVnjff11uEWERb1iFm4wT ZuOXvuy/Hs/TWgD03GJxLZKXrrOjSkJwMOKqPFk0SwKq+bH4G81C0B3OKjUVIr2D nmibKXlKvIwxqcH/t4ZZ5PSi8z91F2cU6r2pZ6Y0tv5YS7aDMgkXIp5vr1rTY//k zbfBbPEkztCcwKJMoYeVbRzcgbDu5pMg0w7r6CsS+RHRHvK8AN2cyWrIAUN7/8/3 7aQZO//uLu6hH8pGb355wwkIFO7yLLsv/qGkIf4PNTZKtHtQhDuUxRa41Pt8cDJF 8rGO1pUmZW8GD3SD50l8vm/rSkGsrohf73mm4j8qF7fUDu5VN2E99iQn7LIQ/M9L Pw3o8d+z4yo4+EqTDzb/Z/K7HoydnbOofOMRpys87E5yO1My6WI=
=t49O
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)