Open alextrical opened 11 months ago
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.
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
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
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
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
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?
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?
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