Bug#1060960: Bug #1060960 (libslf4j-java: FTBFS: make: *** [debian/rules:4: build] Error 25) is tagged patch but I can't find a patch

[Emmanuel Bourg]

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