Greetings.

I'm looking for some help for a build failure on armel related to
compiling Java that has cropped up in the last couple of weeks. This is
keeping Debian packages zeroc-ice as well as mumble from transitioning
to Testing.

The compile seems to fail during a Gradle / Java memory check and seems
to be specific to armel.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069538

I've done additional test builds on 2 armel Debian porter boxes and the
error is repeatable.

:test:compileJava
Putting task artifact state for task ':test:compileJava' into context
took 0.0 secs.
Up-to-date check for task ':test:compileJava' took 47.549 secs. It is
not up-to-date because:
  No history is available.
All input files are considered out-of-date for incremental task ':test:compileJava'.
Use of target 1.7 is no longer supported, switching to 8
Use of source 1.7 is no longer supported, switching to 8
Compiling with JDK Java compiler API.
Failed to execute org.gradle.process.internal.health.memory.DefaultMemoryManager$MemoryCheck@12c1b75.
An exception has occurred in the compiler (17.0.11). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the
following diagnostic, and the parameters passed to the Java compiler
in your report. Thank you.
java.lang.OutOfMemoryError: Java heap space
:test:compileJava FAILED
:test:compileJava (Thread[Task worker for ':',5,main]) completed. Took
48 mins 58.651 secs.

I'd like to know how to fix or work around this bug if possible.

Thanks

--

Chris Knadle
[email protected]

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

Hi,

Unfortunately I do not have an armel box accessible, but maybe
tweaking Gradle heap size through 'export GRADLE_OPTS=-Xmx<heapsize>'
might help?
I have tried with export GRADLE_OPTS=-Xmx512M and the package was
built successfully.

Best Regards,
Vladimir.

On Wed, May 1, 2024 at 4:08 PM Chris Knadle <[email protected]> wrote:

Greetings.

I'm looking for some help for a build failure on armel related to
compiling Java that has cropped up in the last couple of weeks. This is keeping Debian packages zeroc-ice as well as mumble from transitioning
to Testing.

The compile seems to fail during a Gradle / Java memory check and seems
to be specific to armel.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069538

I've done additional test builds on 2 armel Debian porter boxes and the
error is repeatable.

:test:compileJava
Putting task artifact state for task ':test:compileJava' into context
took 0.0 secs.
Up-to-date check for task ':test:compileJava' took 47.549 secs. It is
not up-to-date because:
No history is available.
All input files are considered out-of-date for incremental task ':test:compileJava'.
Use of target 1.7 is no longer supported, switching to 8
Use of source 1.7 is no longer supported, switching to 8
Compiling with JDK Java compiler API.
Failed to execute org.gradle.process.internal.health.memory.DefaultMemoryManager$MemoryCheck@12c1b75.
An exception has occurred in the compiler (17.0.11). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the
following diagnostic, and the parameters passed to the Java compiler
in your report. Thank you.
java.lang.OutOfMemoryError: Java heap space
:test:compileJava FAILED
:test:compileJava (Thread[Task worker for ':',5,main]) completed. Took
48 mins 58.651 secs.

I'd like to know how to fix or work around this bug if possible.

Thanks

--

Chris Knadle
[email protected]

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

On Thu, May 02, 2024 at 01:54:51PM +1200, Vladimir Petko wrote:

Unfortunately I do not have an armel box accessible, but maybe
tweaking Gradle heap size through 'export GRADLE_OPTS=-Xmx<heapsize>'
might help?
I have tried with export GRADLE_OPTS=-Xmx512M and the package was
built successfully.

Hi Chris,

If it saves you any time (it's a long build), I was able to build
zeroc-ice successfully on armel after adding Vladimir's suggestion to debian/rules.

Cheers,
tony

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

iQIzBAABCgAdFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAmY0Yr4ACgkQIdIFiZdL Ppay0RAAzAEcy7rKmYeg3j262hcLVjDEjfF205OSJilNhr8qu2sd4L2C9jswy50y T8l4RN+v0bYyj9g1CQeb9O9E+2FdGaxnvodXIVtWWaLCxFL309nfLVyvLv3ONvLB DzH7M1b9+PejeKiYqKJs226LnhwGg1wuOFFNI1rV4CYaQqJ8+3tL+TBEPcNUvbDY dQEtq0YOQGQzz3bWF7qIVL1ZzMEZE2DQzqeYofMc8mGOhgQWkYaKP57dOjXzesur jIrKs24dAspRnZqnR7spk80xMhId7e1MwcEPFbpCxUpIzoTRGF1oXEuKNsPIiYmi CYRPLc8cK2xJM+5XwPcCwzTvE863/8fGHzMNdq78tWa5KvhHNXJ/Ka9lpkwfEnMz SPOEPWfzLkpXDNgv3Ir4qK4XS7FVlbgeMPlRMkX0sVk6gh/U67zZh5UXJSUc2yhS 0YLnwwcNnQgdMg5bGoy4d3qeRVU9RELAQVLDLUhBWGcriclp4qvXIs99uXm7LiUk Rp7AqdsVzJw6mOj2752xKbuUgWVNEeRsUVa8EIKVkiFi4HxIQlgDq1349M/BkdY2 D883mWXat7Vk0xQ78hPEFBQ/sA8QrD0iclC5ncxO8iAFy/0csH7LxVWiu2Re9IOR ypJegAn5ZckmTAU0UIS7tYp27b2ZKzInT88Ri21ZlUPrFnPS9uo=
=SLf/
-----END PGP SIGNATURE-----

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

Thank you this sounds promising.

Would you consider this option in debian/rules to be safe to deploy to
all architectures?

i.e. would adding this globally be an acceptable bug fix?

Cheers,

Chris

On 5/3/24 00:06, tony mancill wrote:

On Thu, May 02, 2024 at 01:54:51PM +1200, Vladimir Petko wrote:

Unfortunately I do not have an armel box accessible, but maybe
tweaking Gradle heap size through 'export GRADLE_OPTS=-Xmx<heapsize>'
might help?
I have tried with export GRADLE_OPTS=-Xmx512M and the package was
built successfully.

Hi Chris,

If it saves you any time (it's a long build), I was able to build
zeroc-ice successfully on armel after adding Vladimir's suggestion to debian/rules.

Cheers,
tony

--
Chris Knadle
[email protected]

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

On Fri, May 03, 2024 at 09:13:09PM -0400, Chris Knadle wrote:

Thank you this sounds promising.

Would you consider this option in debian/rules to be safe to deploy to all architectures?

i.e. would adding this globally be an acceptable bug fix?

Hi Chris,

Yes, I think this is suitable for all builds.

Cheers,
tony

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

iQIzBAABCgAdFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAmY1r4sACgkQIdIFiZdL PpbgZQ//abHpfGFABKoL2oOqlfoG4B0cW0NYDRji+kbtZDsID+KnvgR/g4c4uhcv Yc15uF26XYFg3k0Y8QWi6f2mdQ6lFOJWcSl9Z1VOfMKGI+b4t4/bv4rTODG/IEHJ wKFALEDGV9V+TMgry2XuNDKmglo7TB4vwTeCPIF8+WqMLtlZA5125BebsGQMylbF n+feigxm+/dcfjekEMlrDQZJ5lc9Maoc2GLvIMXyH/GDFYsXDEyFdT1ovTJyYRak A2diLKkAvqFWeQMAVmn5IUBv7c0LbulbdEMi/+8UlEhDP6IYx3OEGFSRL+AOULug gw86+aMvNkrbWFkUhpkVbQR9NT7hlPJLvW7kVetPTXbBShb22q01B6EQLlprYcAk 5GWDffNwrSFAtNLehs9RJz/iX0mvsdDowa53SBR2JjibMv+MSHx75+2i03+oYdKl Or5YUYbeksfuKAQp4LH9bypmUhnO0pTs1yR8Lr4A0uzaFDEEdXOIYnty55ZUPfyc 3uVjk3DUKrScYRAzSC89hvIulf0qv6rnOj3SeHRyry/R0+1ieecVMsBm3AaMviqk wr4ItJuAcKba5sKMonWqdxBcQEmboQJQLhnL0Odi9Ti2azrTqoavJ6f76Npns1pX E/ZbEUi+uCs1zMBpUfPhVICH5uE+EnkieGRno2UcpL2p/wH+7vU=
=VfuV
-----END PGP SIGNATURE-----

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