sparrow: Compile from source on RPi4 failed
I tried to compile from source on a Rpi4 following the instructions for building in the readme.
But it failed as below.
./gradlew jpackage
Downloading https://services.gradle.org/distributions/gradle-7.1-bin.zip
..........10%...........20%...........30%..........40%...........50%...........60%..........70%...........80%...........90%...........100%
Welcome to Gradle 7.1!
Here are the highlights of this release:
- Faster incremental Java compilation
- Easier source set configuration in the Kotlin DSL
For more details see https://docs.gradle.org/7.1/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :buildSrc:compileJava
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors
> Task :buildSrc:processResources
> Task :buildSrc:classes
> Task :buildSrc:jar
> Task :buildSrc:assemble
> Task :buildSrc:pluginUnderTestMetadata
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:validatePlugins
> Task :buildSrc:check
> Task :buildSrc:build
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':compileJava'.
> Could not resolve all task dependencies for configuration ':compileClasspath'.
> Could not resolve project :drongo.
Required by:
project :
> No matching configuration of project :drongo was found. The consumer was configured to find an API of a library, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'javaModule' with value 'true' but:
- None of the consumable configurations have attributes.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 4m 35s
6 actionable tasks: 6 executed
Is this not a realistic thing to try? I know the Pi is underpowered and a strange platform.
If you think it is possible to resolve I’m happy to provide more info you require.
Thanks.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 24 (5 by maintainers)
I’d appreciate if an affected sparrow user could document how to patch the current state of sparrow and openjfx with the PR openjfx/javafx-gradle-plugin#103* mentioned by @craigraw to prevent that multiple affected sparrow users dig into this same platform issue and waste their resources.
If I’m the first which comes around this, I’ll do the same. ❤️
General sparrow platform situation from my POV
@craigraw , you’re wonderful sparrow wallet is the only desktop wallet which implements whirlpool. Even better, sparrow is the only wallet which can auto mix to cold storage.
Because of this I expect the use case to run sparrow on a dedicated hardware like the raspberry pi for mixing “life changing” amounts into cold storage to increase in numbers over time.
The current alternatives of running your own dojo or RoninDojo doesn’t make much sense if the user is not interesed in running Samourai Wallet and just interested in whirlpool mixing.
Therefore offering a smooth onboarding path for running sparrow on dedicated hardware like the raspberry would be nice to have.
❓ Do you agree on my perspective about this use case of sparrow in general or do you have a different view about your project?
❓ Do you think your sparrow project is ready to lift the burden for whirlpool mixing life changing amounts (when leaving aside that whirlpool itself is just in public beta currently)?
❓ What do you think how can one contribute to make the onboarding process smooth for dedicated hardware users?
My ideas for contributions
* Notes
Sparrow v1.7.0 has been released with support for the RPi4 when running a 64-bit Linux OS.
Closing this issue off.
If you get to it first, thanks! Ideally the gradle plugin should detect the architecture - detecting the new M1 chip architecture is another case in point.
I am growing more curious about how Sparrow would perform on a RPi4 - certainly your thoughts re dedicated hardware make sense from a minimizing trust perspective.
Sparrow uses the same Whirlpool client as Samourai, which has already had multiple years of mainnet use. I would say it is ready for mixing large amounts, yes.
Clearly we need to see whether it is practical once we have a build process ready for the RPi. If so, then the releases could start to include a package suitable for installation on that platform, which should be functional already should a windowing system be present.
Beyond that, it would be interesting to look at projects like Monocle which can enable remote display over VNC on headless systems.
JavaFX does work on ARM, but it appears that the JavaFX Gradle plugin that Sparrow uses does not support it - Linux is considered as AMD64. https://github.com/openjfx/javafx-gradle-plugin/blob/8d2a031fe1d7128439b9456239093e49dae17bca/src/main/java/org/openjfx/gradle/JavaFXPlatform.java#L57
There is a PR to allow specification of platform: https://github.com/openjfx/javafx-gradle-plugin/pull/103