JS8Call-improved
Replies: 11 comments
|
I am not member of that forum. But you can pass this on if you like: JS8Call 2.4.0 and later require Qt 6.9.3. All versions of JS8Call require a specific version of Hamlib, the 2.5.x series require Hamlib 4.6.5, current JS8Call master requires Hamlib 4.7.0. Since most linux distributions do not provide these libraries, distribution on linux for the project is AppImage only, which bundles the required libraries with the binary. We do provide build scripts for both Debian-based and Redhat/Fedora-based linux systems that are semi-automated and will pull the proper libraries from our repo for a build. And will subsequently install JS8Call for the local user. Linux package maintainers are welcome to try to figure out how to package JS8Call 2.5 and later for their distribution, this has already been done by some like Arch. But otherwise, CPack is deprecated in the JS8Call project and no longer used. The provided build scripts COULD be modified to install JS8Call system-wide. But it MUST be packaged with the proper libraries that the build scripts will fetch during the build. The library package that will be fetched is a unified js8lib library package, which is required alongside the Qt6.9.3 package. |
|
To be clear, cmake install targets are separate from CPack. Regardless, if highly specific versions of libraries are required, it's probably best not to try to force it into Fedora. |
|
We do not define any install() targets in our CMakeLists.txt. It is designed to build the binary and link the libs only. Then external tools are used for packaging on the three supported platforms; MacOS Xcode since the .app bundle and .dmg must be sent to Apple twice for notarization. Windows Inno Setup to produce a Windows installer. Linux is bundled to .AppImage with scripting. The old CPack definitions that built .deb or .rpm were scrapped since they were no longer practical with our library requirements. MacOS and Windows are the vast majority of our user-base, well over 90%, necessitating use of newer libraries to support those systems. MacOS 26 Tahoe, for instance, requires minimum Qt 6.9.3 to compile and Windows needs Qt6.9.3 for FFmpeg audio support. So our code is wired for Qt 6.9.3 and the newest Hamlib that supports newer radios like the IC-7300 MkII. We fully support linux, but only via AppImage or the provided build scripts since I spent a considerable amount of time building the required library packages TO support it. But unfortunately, the conventional "linux way" of packaging software does not work here because linux distributions are notoriously slow with updating their repos to include the needed libraries. |
|
@hobbes1069 while I'm not familiar with how Fedora packages their software, it is possible to disassemble one of our AppImages and use the pre-built library assets in the virtual file structure inside it to package dependency libraries that your repo doesn't have. Then build the binary with the proper cmake prefix paths to link the extracted libraries. The only real difference between AppImage and the actual file structure on your system is that the kernel mounts the virtual filesystem in the AppImage with libfuse2 so the binary uses the virtual filesystem in the AppImage that carries the necessary libs. The other option would be to get your package maintainers to update their Qt package to 6.9.3 and Hamlib 4.7.0 (for our current master branch). Modify our CMakeLists.txt to include an install() target where you want the binary to live on your system, then use your packaging tools to package it. This is not impossible, IF you can come up with a way to package the necessary libs in the way required for your distribution. The Arch Linux guys did it so I know it's possible to do. You can look at our github workflows to get an idea of what's required to build and package it. |
|
@wmiler may be able to provide you with some pointers on how to fork the JS8Call-improved project, then design a custom workflow to build and package the newer JS8Call for your distribution. |
|
@hobbes1069 Richard, as @Chris-AC9KH has said, we don't offer a good, old fashion I haven't had the time available to work on other packaging routes (flatpak, snap, whatever Fedora uses). Sorry I can't give you an easier answer. :( |
|
I return back to AppImage & installed last available version 2.5.2 & it working very okay & now my TX working again to bring the needed PWR output that I select. What is optimistic, by the last version as AppImage I received for the 1st time in my life JS8 mode STN on 40mb !!! Since my start to use this mode I never ever before copied any such signals at all !! Just 2 days ago when installed last AppImage I copied JS8 mode signals on 40mb !! One of them was TX used only 10W & I set my antenna not for 40mb !! Regarding AppImage option, what is bad is that it need manual removal & re-installation. I remembered since a long time & not sure if this is still possible or not, you can add built-in option within AppImage to update it without need to delete it & repeating installation steps every new release. If this feature still available for AppImage, why you do not add it ? If you add this feature, so that when program check for new update & find new update, the update notification message from AppImage will give user an "update" option the user can click on it (click on "update") then AppImage will start to download AND VERIFY NEW UPDATE BEFORE APPLYING IT then apply it after okay verification. If this feature possible then I will open a "feature request" for it. YI1CW (ex: YI1YJK) |
|
@Nokia808 v2.5.2 will notify you if a newer release is available if you have |
|
@Nokia808 It is still possible to build the AppImage with the zsync file, but we don't do it that way. |
|
I believe this issue is dead. While we are more than willing to help linux distribution package maintainers with packaging JS8Call for their distribution, we cannot do it for them. We do provide the necessary libraries, but obviously not packaged in the format that different distributions require, and there is no standard for that either. So I will close this issue and convert it to a discussion category where the linux developers can discuss alternative methods to package JS8Call. |
|
As time has gone on, linux distributions fail to keep JS8Call up-to-date in their software repositories and still distribute an obsolete and no-longer-supported version of JS8Call. This is mainly due to linux distributions being quite limited in what they can offer to meet the dependency requirements of JS8Call 3.0.2. Arch LInux is the exception - they package the latest JS8Call. The primary method of distribution for the JS8Call project is AppImage. However, we do provide pre-built libraries including a custom-built Qt6 package built with the Clang compiler (which Qt now recommends) for JS8Call, with FFmpeg audio support. These libraries are updated for each new version of JS8Call and are hosted here: https://github.com/JS8Call-improved/js8lib/releases There is a build script for linux that will fetch the required libraries to build v3.0.2. So the base tools are in place for linux distribution package maintainers to distribute JS8Call v3.0.2 in the package format their distribution requires. We cannot do this for them - it is up to the distribution maintainers to examine the scripts and come up with their own modifications to build for their system, either by building the REQUIRED libraries from source or using our pre-built libs. Our pre-built libraries are compatible with any distribution back to glibc 2.39. If it is not possible for linux distribution package maintainers to do this, it is recommended by the official project to remove the outdated version of JS8Call from their repos, as that version built with Fortran is many years obsolete, and require users to obtain JS8Call from the official project. |
Uh oh!
There was an error while loading. Please reload this page.
Hello !
Can you, kindly, help with this problem - see the following:
https://bugzilla.redhat.com/show_bug.cgi?id=2439679
YI1CW (ex: YI1YJK)
73
All reactions