[Feature Add] Compiling RPM in GitHub CI

[alextrical]

Hi

I have currently got the GitHub CI to compile the RPM package, but I'm not sure how to get this into a state ready to be able to generate Both the existing .DEB and the new .RPM
Please can you look over the workflow found here https://github.com/alextrical/stl-thumb/blob/master/.github/workflows/build-ci.yml
And let me know how you feel about this. I suppose the best fix may be to add the X86_64 RPM generation to a new Step in the Workflow

The compiled binaries can be found at https://github.com/alextrical/stl-thumb/releases/tag/release

[unlimitedbacon]

Thanks. It would be very nice to get this going.

The current CI script cross compiles Debian packages for several different processor architectures. Specifically, armhf and arm64 for use on a Raspberry Pi or other embedded systems.

Do you think there is value in doing RPM builds for all these architectures as well? Or is x86_64 the only one that is really necessary? As far as I know, RedHat based distros are not commonly used on embedded systems.

[alextrical]

Awesome, I can look into getting the workflow into a format more acceptable for merging into the main repo then. Now it's shown that it's possible to compile a RPM in a Ubuntu based workflow ^_^

I'm not familiar with using Redhat/Fedora on anything other than x86_64, but depending on the difficulty it may be worth compiling for the other architectures too. (That's going to be a bit of a learning curve for me to work out how that loop logic works)

Give me a few days and I will try and have something ready to review for merge

[alextrical]

It seems one of the biggest issues with the workflow was getting it to actually run.
Ubuntu 18.04 doesn't seem to be in the roster anymore, so the workflow wouldn't run.
After updating the script to make use of 22.04 and getting it working as intended, I've started work on getting the RPM build added into the workflow, though i've got some bugs to iron out of that it seems (specifically Asset file not found: ./target/release/stl-thumb that cargo generate-rpm seems to love to throw.

Edit:
A bit of an ugly fix is to copy the files to the needed location, after cargo deb completes its build of the required files with cp -r ./target/${{ matrix.target }}/release ./target
It feels wrong that cargo deb compiles its required files/folder structure, but cargo generate-rpm doesn't

[alextrical]

From what i can tell the Build action is outputting into ./target/x86_64-unknown-linux-gnu/release/stl-thumb but the cargo generate-rpm expects the files to be at ./target/release/stl-thumb Now to work out how to get it to take the --target variable

[alextrical]

PR related to this feature has been submitted #84
Now to take a look at the requirements to get the KDE plugin working reliably on Fedora Atomic/Kinoite

[boredsquirrel]

thanks for your efforts! I am on Kinoite as well, and stl-thumb can be installed with cargo so that is no big deal.

But the KDE integration seems to require stl-thumb to be installed on the system, and thus fails.

https://github.com/unlimitedbacon/stl-thumb/actions/runs/11071515784/job/31012859387

It seems the RPM builds are currently failing?

[boredsquirrel]

I was able to compile it locally, in a distrobox

using this

https://github.com/cat-in-136/cargo-generate-rpm

The fedora rust "rust2rpm" can be installed with dnf too.

# distrobox
sudo dnf install -y cmake fontconfig-devel

# rustup install cargo
cargo install cargo-generate-rpm

git clone https://github.com/unlimitedbacon/stl-thumb
cd stl-thumb

export RUST_BACKTRACE=1
export PKG_CONFIG_PATH=/usr/share/fontconfig

cargo build --release

strip -s target/release/XXX #??

cargo generate-rpm

cd ./target/generate-rpm

exit

For some reason, I still get this error

Resolving dependencies... done
error: Konnte Transaktion nicht depsolven 1 Problem erkannt:
 Problem: widersprüchliche Anforderungen
  - nothing provides libstl_thumb.so()(64bit) needed by stl-thumb-kde-0.5.0-1.x86_64 from @commandline

I will try to reboot and do it again. It probably tries to resolve the dependencies relative to the current install? If that is not the case, there is something broken in detecting that library, as I 1. installed stl-thumb and 2. installed the kde integration.

Setting up an RPM repo for these 2 rpms would be really good.

https://linuxconfig.org/how-to-create-a-custom-rpm-repository-on-linux

this explains how the webserver should look like. Could this be done with github pages?