Arch Linux User Repository

After adding some missing ConsoleHelper implementation and modifying the download link in the last few commits, I believe the previous issues have been resolved, and recommend trying to rebuild with the latest PKGBUILD.

The version 2.17.0 is currently broken because of two reasons.

1. The download appears to require registration and the workaround doesn't appear to work anymore. Hence the zero byte file.

2. ST removed any option from installing without a GUI: https://community.st.com/t5/stm32cubeprogrammer-mcus/installation-of-stm32cubeprogrammer-without-a-graphical/td-p/695449

There appears to be an internal ticket which requests to fix this.

The only way I was able to install was to download the installer from ST and running it directly going through the GUI install wizard.

I though to give more input why the current stm32cubeprog 2.16.0-2 fails and how I managed to install the application: I found out that the ZIP file size of en.stm32cubeprg-lin-v2-16-0.zip was in my case 0 B while the real packet should have been over 280 MB. Thus sha256sum fails.

As @hoe10 suggest, downloading the stm32cubeprog from ST's website and replacing cached version of the ZIP file with it, yay allows me to build and install the application as now the correct ~280 MB ZIP file exist in yay's build files at ~/.cache/yay/stm32cubeprog/.

So why it was 0 bytes then? While I was trying to install the packet I tried to do the cleanBuild (in yay this removes pre-downloaded build files from yay's cache and downloads them again) with verbose command yay -Sv stm32cubeprog, it didn't download the ZIP file at all. Instead I got an error curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2). Google search suggests there is something wrong with HTTP/2 or then it might be the curl syntaxes are missing some key parameters in the PKGBUILD starting at line 41.

I hope this helps someone and gives some light for the maintainers why the packet fails to build.

The installation fails with

Validating source files with sha256sums...
    en.stm32cubeprg-lin-v2-16-0.zip ... FAILED
...

Workaround was to directly download the zip file from st website and replace the one downloaded by makepkg. The sha256 matches with the one specified in the PKGBUILD. Weird and a bit fishy

I had to set it manually to work:

$ sudo archlinux-java set java-8-openjdk

Thanks for maintaining this.

nvm. my fault

gretings

@GPereira Thanks for the update. I have an additional advice: Arch Linux usually use the latest JDK available on the system to provide the default java environment. I have version 8, 11, 17, 22 installed on my device, and the javac command uses version 22 by default.

==> 正在开始 build()...
./SetupSTM32CubeProgrammer-2.16.0.linux
/home/sots/.cache/paru/clone/stm32cubeprog/src
chdir /home/sots/.cache/paru/clone/stm32cubeprog/src/.
current dir /home/sots/.cache/paru/clone/stm32cubeprog/src
Command line arguments: -options-auto install.options
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/st/CustomPanels/AnalyticsPanelsConsoleHelper has been compiled by a more recent version of the Java Runtime (class file version 66.0), this version of the Java Runtime only recognizes class file versions up to 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)

It is recommended to use archlinux-java-run to set the JDK version.

prepare() {
  JAVA_HOME=$(archlinux-java-run --max 8 --feature jdk --java-home) \
      && "$JAVA_HOME"/bin/javac -cp "Setup${_pkgname}-${pkgver}.exe" -d . AnalyticsPanelsConsoleHelper.java
  7z a Setup${_pkgname}-${pkgver}.exe com/st/CustomPanels/AnalyticsPanelsConsoleHelper.class
}

@sots you should be able to build it now.

@xiretza I did you changes, and it works now. Thank you for your contributions! However I don't particularly like the fact you must have the Java 8 selected in your system before installing this. This might be boring when doing package upgrades with AUR helpers. I rather have it compiled but I don't want to increase the effort in maintaining the package (having to build things manually). What do you think about this?

Can't build izpack:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile (default-compile) on project izpack-installer: Compilation failure: Compilation failure:
[ERROR] /home/sots/.cache/paru/clone/izpack/src/izpack-izpack-5.2.1/izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/Pack200FileUnpacker.java:[34,21] Can't find symbol
[ERROR]   Symbol:   Class Pack200
[ERROR]   Location: Pack java.util.jar
[ERROR] /home/sots/.cache/paru/clone/izpack/src/izpack-izpack-5.2.1/izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/Pack200FileUnpacker.java:[88,20] The pack Pack200 does not exist
[ERROR] /home/sots/.cache/paru/clone/izpack/src/izpack-izpack-5.2.1/izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/Pack200FileUnpacker.java:[76,20] The pack Pack200 does not exist
[ERROR] /home/sots/.cache/paru/clone/izpack/src/izpack-izpack-5.2.1/izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/Pack200FileUnpacker.java:[90,16] The pack Pack200 does not exist
[ERROR] /home/sots/.cache/paru/clone/izpack/src/izpack-izpack-5.2.1/izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/Pack200FileUnpacker.java:[90,37] Can't find symbol
[ERROR]   Symbol:   variable Pack200
[ERROR]   Location: Class com.izforge.izpack.installer.unpacker.Pack200FileUnpacker
[ERROR] -> [Help 1]