Bug#1057933: libjose4j-java: FTBFS: IOException: Only named ECParameters supported
severity 1057933 normal thanks Hi. It works on m6a.large instances, which have an AMD EPYC processor. I'm downgrading as a cautionary measure. My theory right now is that the package needs more than 4 GB of RAM to build, but does not show a meaningful error message if that's not the case. Now you may ask: Why am I building this package with so little memory? Well, I monitor /proc/meminfo during the build and collect the results, so that I never try to build a given package on a machine which I know will need more than the machine has. This usually works well enough most of the time, but sometimes I have to make exceptions. (Also, 99.1% of all packages build ok with 4 GB of RAM, so it's not really such a low amount). I have to do additional checks. Thanks.
Bug#1057933: libjose4j-java: FTBFS: IOException: Only named ECParameters supported
El 10/12/23 a las 23:31, tony mancill escribió: I'm not able to reproduce this locally, and the only potentially relevant difference I see between the AWS testbed and my local environment is that I am running Intel and the AWS system is AMD. Well spotted! Yes, I believe that could explain the difference. In fact, I have failed builds on AWS instances of type t3a.small, t3a.large, c6a.large and r6a.large, all of which (I believe) have AMD processors, and I still keep some successful builds logs made in the past on GCP instances of type t2d (Intel). Thanks.
Bug#1057933: libjose4j-java: FTBFS: IOException: Only named ECParameters supported
On Sun, Dec 10, 2023 at 08:18:03PM +0100, Santiago Vila wrote: > Package: src:libjose4j-java > Version: 0.7.12-2 > Severity: serious > Tags: ftbfs > > [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.063 > s <<< FAILURE! - in org.jose4j.jwk.EllipticCurveJsonWebKeyTest > [ERROR] > testParseExampleWithPrivate256(org.jose4j.jwk.EllipticCurveJsonWebKeyTest) > Time elapsed: 0.031 s <<< FAILURE! > java.lang.AssertionError: > expected: [8b:e2:14:0f:3a:17:e9:25:d1:ae:df:18:a3:b2:9a:fd:63:04:41:11] > X: > 7fcdce2770f6c45d4183cbee6fdb4b7b580733357be9ef13bacf6e3c7bd15445 > Y: > c7f144cd1bbd9b7e872cdfedb9eeb9f4b3695d6ea90b24ad8a4623288588e5ad > > but was: > at > org.jose4j.jwk.EllipticCurveJsonWebKeyTest.testParseExampleWithPrivate256(EllipticCurveJsonWebKeyTest.java:53) > ... > > If required, the full build log is available here: > > https://people.debian.org/~sanvila/build-logs/202312/ Thank you for making this available. > About the archive rebuild: The build was made using virtual machines > from AWS, with enough memory, enough disk, and either one or two > CPUs, using a reduced chroot with only build-essential packages. I'm not able to reproduce this locally, and the only potentially relevant difference I see between the AWS testbed and my local environment is that I am running Intel and the AWS system is AMD. > If you could not reproduce the bug please contact me privately, as I > am willing to provide ssh access to a virtual machine where the bug is > fully reproducible. Will do, as time permits. This package has a low popcon, and is a build-dependency of libcallstats-java, which also has a low popcon, and has no reverse dependencies. I believe both are part of an effort to get Jitsi back into Debian. If that's not likely to happen, an alternative is to file RM bugs for both of them. (I am adding the Uploaders to the cc:) Thanks, tony signature.asc Description: PGP signature
Bug#1057933: libjose4j-java: FTBFS: IOException: Only named ECParameters supported
Package: src:libjose4j-java
Version: 0.7.12-2
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
debian/rules binary
dh binary
dh_update_autotools_config
dh_autoreconf
dh_auto_configure
mh_patchpoms -plibjose4j-java --debian-build --keep-pom-version
--maven-repo=/<>/debian/maven-repo
dh_auto_build
/usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar
-Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<>
-Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties
org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml
-Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode
package -DskipTests -Dnotimestamp=true -Dlocale=en_US
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were
deprecated in JDK 13 and will likely be removed in a future release.
[0m[0m[INFO] Scanning for projects...
[INFO]
[INFO] --< org.bitbucket.b_c:jose4j >--
[INFO] Building jose4j 0.7.12
[INFO] [ jar ]-
[... snipped ...]
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
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.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)
14:19:37.806 DEBUG org.jose4j.jwk.JsonWebKeySet - Ignoring an individual JWK in a JWKS due to a problem processing it. JWK params: {kty=null, x=riwTtQeRjmlDsR4PUQELhejpPkZkQstb0_Lf08qeBzM, y=izN8y6z-8j8bB_Lj10gX9mnaE_E0ZK5fl0hJVyLWMKA, crv=P-256} and the full JWKS content:
