Compile from source on RPi4 failed

[raymondclowe]

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.

[raymondclowe]

Java version:

java --version
openjdk 16.0.1 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-16.0.1+9 (build 16.0.1+9)
OpenJDK Server VM AdoptOpenJDK-16.0.1+9 (build 16.0.1+9, mixed mode)

[craigraw]

Did you clone with submodule recursion?

Honestly I'm not sure it's worth it though - the RPi is very underpowered for Sparrow.

[raymondclowe]

Thanks for replying.

I got the source code wrong. Sorry. When I did the recursion properly then it will compile.

But still can't run it.

./sparrow

fails with a bunch of errors but importantly

Loading library prism_es2 from resource failed: java.lang.UnsatisfiedLinkError: /home/pi/.openjfx/cache/16/libprism_es2.so: /home/pi/.openjfx/cache/16/libprism_es2.so: wrong ELF class: ELFCLASS64 (Possible cause: can't load AMD 64 .so on a ARM platform)

I guess this isn't going to work on ARM.

I agree RPi may not be worthwhile. I was looking for one more device in the room for some various workflows using airgapped offline signing.

[craigraw]

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: openjfx/javafx-gradle-plugin#103

[alaznem]

There is a PR to allow specification of platform: openjfx/javafx-gradle-plugin#103

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

• Add how to use sparrow on raspberry pi to the sparrow docs.
• Integrate sparrow into @rootzoll's rootzoll/raspiblitz
• Add the sparrow feature to whirlpool mix from the command line without starting the sparrow gui.

* Notes

• The state of the PR openjfx/javafx-gradle-plugin#103 is: @jperedadnr has requested 3 months ago the singing of the CLA[https://cla.gluonhq.com/] from @shahzaibj (the creator of the pull request).

[craigraw]

If I'm the first which comes around this, I'll do the same. ❤️

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.

❓ Do you agree on my perspective about this use case of sparrow in general or do you have a different view about your project?

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.

❓ 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)?

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.

❓ What do you think how can one contribute to make the onboarding process smooth for dedicated hardware users?

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.

[alaznem]

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.

❓ @raymondclowe : Do you have the intention to follow this suggested path and how are your estimated resources for this?

My side:

Importance: This topic is located quite high in my priorities, so I'd like to give it a try.
Time: I will be available to look into this starting from Thursdays at the earliest.
Skills: Never looked into gradle plugins nor JavaFX. I'm not sure if my skills suffice to generate a worthwile solution in the near future.

My open questions (more of a self note):

• Where to start?

• Find the relevant code piece(s) of the gradle plugin inside of Sparrow. (build.gradle,)

• Find out what is affected by Sparrow and what comes from upstream.

• What to do (probably)

• Patch javafx-gradle-plugin with pr 103 locally

• find out how to use local javafx-gradle-plugin as source for running Sparrow. (SO "Adding local plugin to a Gradle project", general ddg search)

• Should provide the information if applying pr 103 is sufficient for running Sparrow on Raspberry Pi.

• Feedback collected informations to this issue Compile from source on RPi4 failed #292

[raymondclowe]

❓ @raymondclowe : Do you have the intention to follow this suggested path and how are your estimated resources for this?

I would be interested to follow any instructions you can write, and provide feedback, but don't have the skills to do it myself. Although I am familiar with Pi/Linux and programming in general I have zero Java skills.

Also I can only try it on existing RPi machines. I don't have ones I can easily wipe to do clean test; my Pi's are all production household servers so I can't mess with them too much.

[raymondclowe]

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.

I realize the architecture and tech are very different, but just as a reference-point I can run Electrum on the RPi4 and it works fine, no noticable slowness more than any other program on the Pi. I use it both "locally" via the GUI console session, via VNC, and also via XWindows (to a Xwindows server on a PC).

[craigraw]

Just a note that some of the included native libraries may not support the ARM architecture atm - I'm thinking particularly BWT (used to connect directly to Bitcoin Core) and HWI (used for USB hwws) may not work. Neither are requirements for Whirlpool though, and they can probably be recompiled under the correct architecture and included in future.

[craigraw]

Support for linux aarch64 (including Raspberry Pi 64-bit OS) is in progress.

Testing of the pre-release binaries would be appreciated: https://github.com/craigraw/beta/releases/tag/1.6.6-linux-aarch64

[RequestPrivacy]

X@X:~ $ neofetch
OS: Debian GNU/Linux 11 (bullseye) aarch64 
Host: Raspberry Pi 4 Model B Rev 1.4 

X@X:~ $ uname -a
Linux debian 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux

X@X:~ $ java --version
openjdk 17.0.4 2022-07-19
OpenJDK Runtime Environment (build 17.0.4+8-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.4+8-Debian-1deb11u1, mixed mode, sharing)

Downloading the https://github.com/craigraw/beta/releases/download/1.6.6-linux-aarch64/sparrow_1.6.6_aarch64.tar.gz extracting and running the binary in ./Sparrow/bin/Sparrow gives me:

X@X:~/Downloads $ Sparrow/bin/Sparrow 
Exception in thread "main" java.lang.UnsupportedOperationException: Unable to open DISPLAY
        at javafx.graphics@18/com.sun.glass.ui.gtk.GtkApplication.lambda$new$6(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Unknown Source)
        at javafx.graphics@18/com.sun.glass.ui.gtk.GtkApplication.<init>(Unknown Source)
        at javafx.graphics@18/com.sun.glass.ui.gtk.GtkPlatformFactory.createApplication(Unknown Source)
        at javafx.graphics@18/com.sun.glass.ui.Application.run(Unknown Source)
        at javafx.graphics@18/com.sun.javafx.tk.quantum.QuantumToolkit.startup(Unknown Source)
        at javafx.graphics@18/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
        at javafx.graphics@18/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
        at javafx.graphics@18/com.sun.javafx.application.LauncherImpl.startToolkit(Unknown Source)
        at javafx.graphics@18/com.sun.javafx.application.LauncherImpl.launchApplication1(Unknown Source)
        at javafx.graphics@18/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)

Updated to the minimum Java version 18 as I thought that it may have to do with the @18part of the error:

X@X: ~ $ java --version
openjdk 18.0.1 2022-04-19
OpenJDK Runtime Environment Temurin-18.0.1+10 (build 18.0.1+10)
OpenJDK 64-Bit Server VM Temurin-18.0.1+10 (build 18.0.1+10, mixed mode, sharing)

But nothing changed.

I'm in a terminal ssh session so I guess terminal mode with the -tflag isn't fully supported yet as it produces the same error?

[craigraw]

@RequestPrivacy does your OS have a desktop, or is the "Lite" version?

[RequestPrivacy]

I'm unsure honestly as it's a while ago since setting the pi up. I can't see a familiar window manager like xorg or wayland with top nor an desktop environment so I tend to assume its the "lite" version.

After some research I haven't found out how to definitely tell though. Do you have a command to find out at hand?

[craigraw]

Do you have a command to find out at hand?

On Linux systems, you should be able to use

> echo $DISPLAY
:0

If there is no output, it's headless.

[RequestPrivacy]

Yeah so it's headless. Does this mean it's an expected behavior? I was under the impression the release supports terminal only mode?!

[craigraw]

The binary linked above is for testing on linux aarch64 with displays.

[tmakerman]

@craigraw I'm happy to share that your beta build works great. I just got a fresh install of OS setup, my configuration:

Raspberry Pi 4 Model B Rev 1.5 2GB
Raspberry Pi OS 64-bit with Desktop
Release Date: September 22nd 2022

I haven't spent too much time with it yet, but I'd say the performance is looking pretty good! I started in testnet, connected to public electrum, restored a wallet, and it all loaded up fine, looks like it picked up my test coinjoin where it left off.

I also connected to bitcoin core on testnet and successfully sent a transaction (Bitcoin Core 23 / BWT 0.2.4).

I have use case similar to what was discussed above. I want to keep a hot wallet behind firewall at home always online that I can connect to remotely. I had initially setup an RPi for this configuration before realizing it wasn't going to work, and then bought an x86 SBC - LattePanda v1 4GB. FYI - it works pretty well there (until it failed the other day), but I think performance on RPi 4 so far is looking better.

I can do some more testing if you want to suggest anything. HWI/HWW?

[craigraw]

@tmakerman Thanks for the report! It's particularly positive to hear it working well with such limited RAM.

Your testing is already pretty good, but testing HWI and the internal Tor would be great (for the latter, specify an onion address for the server and disable the proxy). Also, in the unlikely chance of the Pi having a camera attached, the webcam.

[tmakerman]

Sure thing, I will test those today or tomorrow.

[tmakerman]

@craigraw

On HWI

I installed udev rules and scanned for my connected Ledger Nano S Plus. That worked great. Mostly signing also works well, had several successes. Sometimes I get the following error:

Could not open client or get fingerprint information: ('0x5515', 'Error in <DefaultInsType.GET_VERSION: 1> command', '')

but after trying again it will work. I do not think it is just the order in which I start the app on Ledger and connect. If you like I could try and come up with reproducible steps that cause this.

Also FYI - not HWI related - but one time when signing from software wallet, Sparrow crashed. I could not find anything related in my sparrow log. That is only time I saw this. I've signed several times successfully from software wallet.

On camera

I connected a webcam to USB, it just used the drivers that came with Raspberry Pi OS, and the connection and scanning a QR worked great
webcam: Logitech, Inc. HD Pro Webcam C920

On Tor

Probably unrelated to Tor itself, but when I hit “Edit Connection” Sparrow crashed. I am attaching the error and also call stack from the generated err pid log file. The subsequent times I edited connection no troubles.

edit_connection_crash_call_stack.txt
edit_connection_crash_error.txt

I did attempt connecting to .onion address of my node, I got lots of Tor initialization logging on the first attempt, but I did not yet get a successful connection. That said I just tried connecting via Sparrow from my Ubuntu desktop and I had the same issues, so I believe it is probably an error in my configuration somewhere. I will report back after I give it another shot.

[craigraw]

Thanks for great report @tmakerman.

Re the HWI issue, this is coming from HWI itself so it's not a platform specific issue I think. It might be worth reporting on the HWI project.

The 'Edit Connection' crash seems to be related to BWT shutting down. Along with the signing crash, it may be related to RAM usage. I still surprised that Sparrow runs well with 2G RAM!

[tmakerman]

Thanks, if I keep seeing that HWI error I will report it at their project.

Yes, it is running surprisingly well. Surely not as fast as laptop etc, but still quite usable. When I was also running Chromium and had maybe seven tabs open, Sparrow started running very slowly. After shutting down Chromium it was back to running well. I will pay attention to memory usage and see if crashes happen when it is high. I'll switch over to 4GB or 8GB RPi when I can get my hands on one.

[craigraw]

Sparrow v1.7.0 has been released with support for the RPi4 when running a 64-bit Linux OS.

Closing this issue off.