Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#78492 - [java-commons-lang] FTBFS
Attached to Project:
Community Packages
Opened by Levi Zim (kxxt) - Friday, 12 May 2023, 04:14 GMT
Last edited by Leonidas Spyropoulos (inglor) - Saturday, 02 September 2023, 12:14 GMT
Opened by Levi Zim (kxxt) - Friday, 12 May 2023, 04:14 GMT
Last edited by Leonidas Spyropoulos (inglor) - Saturday, 02 September 2023, 12:14 GMT
|
DetailsDescription:
check() failed. Upstream has already fixed it in https://github.com/apache/commons-lang/commit/ab96fb0245702e74397f15ad49955d581af5a3d9 I have created a patch for trunk/PKGBUILD and attached it here. Additional info: * package version(s) 3.12.0-1 Steps to reproduce: asp checkout java-commons-lang cd java-commons-lang/trunk extra-x86_64-build errors from check(): [ERROR] Failures: [ERROR] ThreadUtilsTest.testThreadGroups:236 expected: <1> but was: <3> [ERROR] MultiLineToStringStyleTest.testCollection:80 expected: <java.lang.Integer@3b67019f[ a=<size=0> ]> but was: <java.lang.Integer@3b67019f[ a=java.util.Collections$EmptyList@348be0a ]> [ERROR] NoClassNameToStringStyleTest.testCollection:79 expected: <[a=<size=0>]> but was: <[a=java.util.Collections$EmptyList@348be0a]> [ERROR] RecursiveToStringStyleTest.testObject:75 expected: <java.lang.Integer@3b67019f[a=<size=0>]> but was: <java.lang.Integer@3b67019f[a=java.util.ArrayList@713b7d4f]> [ERROR] ShortPrefixToStringStyleTest.testCollection:80 expected: <Integer[a=<size=0>]> but was: <Integer[a=java.util.Collections$EmptyList@348be0a]> [ERROR] ToStringBuilderTest.after:48->validateNullToStringStyleRegistry:592 Expected null, actual: {[]=null} ==> expected: <null> but was: <{[]=null}> [ERROR] ToStringBuilderTest.after:48->validateNullToStringStyleRegistry:592 Expected null, actual: {[]=null} ==> expected: <null> but was: <{[]=null}> [ERROR] ToStringBuilderTest.after:48->validateNullToStringStyleRegistry:592 Expected null, actual: {[]=null} ==> expected: <null> but was: <{[]=null}> [ERROR] ToStringBuilderTest.after:48->validateNullToStringStyleRegistry:592 Expected null, actual: {[]=null} ==> expected: <null> but was: <{[]=null}> [ERROR] ToStringBuilderTest.after:48->validateNullToStringStyleRegistry:592 Expected null, actual: {[]=null} ==> expected: <null> but was: <{[]=null}> [ERROR] ToStringBuilderTest.after:48->validateNullToStringStyleRegistry:592 Expected null, actual: {[]=null} ==> expected: <null> but was: <{[]=null}> ... |
This task depends upon
Closed by Leonidas Spyropoulos (inglor)
Saturday, 02 September 2023, 12:14 GMT
Reason for closing: Fixed
Additional comments about closing: 3.13.0-1 incorporates fixes for this
Saturday, 02 September 2023, 12:14 GMT
Reason for closing: Fixed
Additional comments about closing: 3.13.0-1 incorporates fixes for this
fix.patch
For me, I am building in a clean chroot and extra-x86_64-build picks openjdk 19 so it fails.
I don't know whether extra-x86_64-build will pick other jdk versions on other machines.
cd java-commons-lang/trunk
should be
cd java-commons-lang/repos/community-any
So the fix should be either
1. copy trunk to community-any
2. or apply the patch: https://github.com/apache/commons-lang/pull/788
Ahh, makes sense now. Fixes were committed to trunk but the pkg hasn't been rebuilt/released since. This is not really a bug then...but we can try nudging the PM for a rebuild.
[ERROR] Failures:
[ERROR] ThreadUtilsTest.testThreadGroups:236 expected: <1> but was: <3>
[INFO]
[ERROR] Tests run: 7796, Failures: 1, Errors: 0, Skipped: 6
The package maintainer seems inactive for a long time.
Could other PMs handle this ticket by either merging my patch (so that it can be built using latest JDK) or just make a new release (with JDK version locked to 11)?
Here I attach an updated patch that solves all the two problems without locking JDK version to 11.