JS8Call-improved
JS8Call Roadmap #317
Replies: 53 comments 40 replies
|
A note with the above build process: we are using Clang 18 to build Qt6. The Qt Group no longer recommends using gcc to build Qt from source on linux. If you try it you'll get a bunch of warnings and likely a failed build. 
The Qt6 build script will handle this automatically. |
|
Very good @Chris-AC9KH -- I'll try the process this afternoon on my U24 server. 73, |
|
Very clever. I'll give it a try.
…On Sun, Jun 7, 2026 at 9:26 AM Joe-K0OG ***@***.***> wrote:
Very good @Chris-AC9KH <https://github.com/Chris-AC9KH> -- I'll try the
process this afternoon on my U24 server.
73,
-Joe-
K0OG
—
Reply to this email directly, view it on GitHub
<#317?email_source=notifications&email_token=AAFQNXISPZIFZI6VJUUFIYD46VUQLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSGA4TQMJVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17209815>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFQNXJEDJZCMYZOO4D22TT46VUQLAVCNFSM6AAAAACZ5TDJICVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMRQHE4DCNI>
.
You are receiving this because you were mentioned.Message ID:
<JS8Call-improved/JS8Call-improved/repo-discussions/317/comments/17209815@
github.com>
|
|
The libraries are there for arm64. I'm relying on @Joe-K0OG to build the required x86_64 libs, which will probably take awhile on an Intel machine. If they are available on your dropbox or something, I can upload them. The libs only have to built once unless a library is updated. The new arm64 deb works and it will cleanly replace an installed 2.2.0 version: chris@debian-vm:~$ apt-cache show js8call Package: js8call So if this ends up being usable, I have to update all the documentation for it, and improve some of the comments in the shell code. And we should have a pretty much fully automated system for building .deb's. |
|
@Chris-AC9KH I'm building now, following your procedure. The js8lib built fine with the Distribution_package_js8lib script, of course (it was already built on this machine before, so I knew it would). However, when I ran the Linux-Dist_pkg_Qt6 script in js8call/tools, I got a "directory ffmpeg already exists" error at the point where ffmpeg was to be cloned. I removed the ffmpeg directory, and it's now proceeding. I'll let you know how it goes as it proceeds, which as you say may take a while. 73, |
|
O.k., I think I understand what's happening. It failed again when it got to building Qt6 with the Distribution script. I see now that it's building it all from scratch again, but I built it a few days ago on this same machine, so it's running into the previous build. I cleared out the old ffmpeg and Qt6 builds, and am starting over. Instruction step "0." should be, "Start with a system clear of ffmpeg and Qt6." Report later... 73, |
|
@Chris-AC9KH The js8lib Distribution build is finished, and am working on the Linux-Dist Qt6 build now. It may be this evening before I finish the Distribution script, then I'll let you know, and post it at: 73, |
|
@Chris-AC9KH As I understand Step 5:
This Debian_build_deb script can be run on any machine, either the Ubuntu 24 server, or any other machine, and it will produce a distributable .deb file (once the x86_64 libraries are placed in Github js8lib). Is that correct? 73, |
|
@Joe-K0OG that's correct. You should be able to run the deb script anywhere. Just be aware of your glibc version because it does build JS8Call in place so if you use a newer glibc it won't run on an older glibc. While it does not have an Ubuntu 24 Server restriction like the other two, I should've put that in the deb script to make it harder to build on any old thing and then we get loose .deb's floating around that don't work because the JS8Call binary itself was built against the wrong version of glibc. These are NOT destined to be end-user scripts. They are developer tools that merely execute a long line of commands to accomplish a build with some consistency. As a developer you are expected to clean up your build artifacts. I hesitate to perform automatic removal of build artifacts for development because they are useful for figuring out problems like discovering the libicu objects need to have symlinks preserved in Qt. If I perform auto-removal of those artifacts then it's like chasing ghosts if there's a problem you're trying to diagnose. |
|
Thanks Chris. It would be good to add a preliminary step warning that the Linux-Dist_pkg_Qt6 script won't run unless the distribution/ffmpeg and distribution/Qt6 directories are either removed or renamed, and including the instructions, including your comments about building on a machine with glibc 2.38, and that this is intended as a developer tool, so, "Please do not distribute .deb packages that are not built according to developer standards" (or something similar). (1183/7925) at this point in the build.... so it will be this evening before I can post the Qt6 library to my Dropbox. 73, |
|
@Chris-AC9KH It "may" be possible to produce a Fedora .rpm installer from the .deb resulting from this process, and have it run properly. I'll test that idea once we get through this. I've done such a thing successfully before using the "alien" tool on Debian-based machines. Sometimes this works, and sometimes it doesn't depending on Debian vs. Fedora library compatibility. It's more likely to work in this case since the libraries are rolled into the .deb, in a similar way as how the AppImage built on Debian works fine on a Fedora machine. 73, |
|
@Joe-K0OG there is a x86_64 .deb on the 3.0.2 releases that you can try if you want. |
|
I just got back home, and the Qt6.9.3 library build completed, so it's posted at the Dropbox. Go get the libraries if needed. 73, |
|
@Chris-AC9KH The .deb you posted installs and runs fine on Linux Mint 22.3. I used it to convert to a .rpm and will try it on Fedora in a few minutes and let you know how that goes -- then it will be bedtime... 73, |
|
Joe, the libraries are all in place. You can get the script from the tools on master and build .deb's all you want now :-) Just make sure to watch the glibc version because a .deb built on glibc 2.41 will not run on glibc 2.39, for instance, due to the binary being linked with the glibc version it is built on. For official production releases I recommend the .deb be only built on Ubuntu 24 Server with glibc 2.39. |
|
@Chris-AC9KH Well, way past my bedtime now! I built a .deb on the Ubuntu 24 server, and find it installs and runs fine. It is posted at my Dropbox if anyone wants to compare mine to your build. I found that the Fedora .rpm conversion from .deb failed to install on Fedora 41 with the following error: Installing on Fedora 43 might yield a better result, but that might be for another day. Good evening. 73, |
|
@Joe-K0OG I don't think it's gonna work. The internal structure of the deb, plus what the binary is linked with, is different from Debian-based to Redhat-based. And Qt is built with clang, not gcc, so it doesn't use libstdc++. Clang consistently builds more efficient code than gcc and I'd like to look at switching the whole linux toolchain to it. Mac and Windows already use clang. |
|
@Joe-K0OG I don't think it's worth wasting a lot of time on, trying to convert a .deb to a .rpm. If you look at the install_deps() function in the new linux build script Fedora names all the library headers -devel and Debian-based uses -dev. And the base library is not named the same. Your conversion tool might work for a very simple build that doesn't have extensive binary linking. But that's not what we have here. The newly implemented linux build system installs JS8Call with the user script identical to how the .deb does it. With the difference that the .deb registers the package with the package manager on Debian-based systems and the user script does not. The method that the Debian .deb uses to register the package is not the same as Fedora, and that's baked into the .deb control file. This gets back to the fact that there is no consistency or standards in linux like there is with Mac and Windows. I just happened to be familiar enough with Debian-based systems to get it to work. Fedora is a different animal and it seems to me there was a fellow @hobbes1069 on the Fedora thread that might be able to help with something like this and create a script that can build a .rpm similar to the way the Debian one does it. But I have only ever run Fedora for testing some things and I am not familiar enough with that system to attempt it. |
|
Even though I started in Linux with RedHat in its earliest days (beta release times) after many years of Unix experience, I'm not as familiar with it these days as I am with Debian-based distributions. My understanding is that the "alien" rpm conversion tool takes into account some of the things you mention, but maybe I'm giving it too much credit. As an experiment, I'm building a Fedora 43 system to try the converted rpm on to see if it works any differently/better than Fedora 41 did. After that, I'll probably give up... 73, |
|
Same result with Fedora 43 as with Fedora 41 -- so the "alien" rpm conversion shortcut won't work. We will definitely need a Fedora expert to come up with a .rpm script. Not a big deal though since JS8Call AppImage works fine on Fedora, and it can be built from source on Fedora. 73, |
|
I suspected that would be the case. If I did enough studying I could probably figure it out. But it might be a point of no return since few people use it. The arm64 .deb will work on Pi 4 & 5 with Pi OS 6.2 or newer. It won't work on Bullseye because their glibc is too old. Going to run into the same glibc problem on Fedora. So who has a build machine that is modern enough to have the proper build tools, but old enough to be glibc-compatible? And it would be x86_64 only because who runs Fedora on arm64 hardware? No linux can run bare metal on Apple silicon - it has to run in a VM and few Mac users have any interest in linux. The Qualcomm Snapdragon is optimized for arm64 Windows. And the Pi arm64v8 world belongs to the Debian universe. Although I suppose one COULD run arm64 Fedora on a Pi, but who does that? It would be an outlier and is that outlier running JS8Call? Probably not. |
|
And... the AppImage runs fine on Fedora. |
|
Since I was experimenting with Fedora, I built the latest Fedora 44, then tried the AppImage and Linux Install script, and both work perfectly there. I think that is enough to keep 99.99% of operators happy! 73, |
|
The new user build script should install identical to the way a .deb or .rpm does. Just that it does not register the install with the system package manager. Being all contained in one script, plus adding arch, I think made it a pretty decent upgrade over what we had. |
|
@Joe-K0OG @wmiler @jsherer We got another new thing now. I took the .deb building script and modified it to create AppImage instead of .deb and added the new AppImage script to the tools directory in master. Just run the script and it will fetch everything you need, create an AppDir, build JS8Call, then fire up linuxdeploy with the Qt plugin to populate the AppDir and make an AppImage out of it. It took me several hours and about 29 tries to get it to work, mainly because I don't know what I'm doing. Just like the .deb building one, there's only one variable you have to set in it, and that's the variable that tells it what branch to check out and build. If you're building on a headless server then make sure to install libfuse2 first. But after I got it working I built an AppImage with it that runs on Debian 13 arm64 on my MacBook Pro M5. Didn't try it on Fedora 43 arm64, mainly because I just bought the MacBook Pro M5 today and Debian 13 is the only one I got installed in the VM so far on it. In theory, run it on Ubuntu 24 Server and it should make an AppImage that will run on anything with glibc 2.39 or newer. So @Joe-K0OG another new toy to play with :-) |
|
@Chris-AC9KH It works great Chris! Nice tool! After installing libfuse2, then running the script, in just a few minutes there was the AppImage, so I copied it to my Linux Mint 22.3 system and it runs fine there. Then I booted Fedora 41, and it runs fine there also. It's nice to have these tools available in case the CI build system chokes for some reason, so we have alternate/backup ways to generate distributables. Thanks! 73, |
|
That's good to hear that it works on Fedora and Mint after being run on a headless server. I added a little conditional to it that extracts the CMake version so it names the final product the same as what we use on the releases by parsing the VERSION line in CMakeLists.txt. Much simpler to do with bash shell than it is with yaml on the runner. |
|
I posted a couple of AppImages to my Dropbox, if anyone wants to test them. Of course, built on my Ubuntu 24 semi-headless (laptop lid closed) server. One of them is the latest main branch, the other is release/3.0.2. As far as I can tell, this works flawlessly. Thanks Chris! |
|
What I'm wondering is; @wmiler is having some issues getting the linux build with the required Qt modules to work. Can you just call the Shell script from tools and run it in the workflow file? The shell script does require sudo to install the required dependencies, but otherwise does everything in one whack. Which seems to require a lot of complex programming with yaml. |
|
@Joe-K0OG definitely would be prudent to build on linux with gcc as well to see what kind of errors that one throws. |
|
@Chris-AC9KH On Windows, built with QtCreator/Qt6.11.1/clang, your updated pr/Qt6.11_deprecations branch builds quietly, with the only warnings being the persistent sqlite ones: On Windows, built with the JTSDK64-Tools build system, which uses mingw64 (gcc), the following warnings are shown: ...and all the rest builds clean. On Linux Mint 22.3, no warnings are flagged when built with clang, and no errors with gcc, but just these warnings: All the above test builds run fine. 73, |
|
The sqlite code is vendor code, and I could look at upgrading to the next version sqlite3. But that doesn't mean they fixed those issues in their code. With this one:
What we're seeing here is a fundamental difference between gcc and clang. gcc's -Wswitch treats every enumerator in the enum as something that must be covered by a case, full stop. It does not care whether the enumerator is marked [[deprecated]]/QT_DEPRECATED_* or not in Qt 6.11 Clang's -Wswitch does this different. It does not flag a missing case for an enumerator that's marked deprecated in the Qt headers. LLVM has a little more common sense than gcc - if you add case QtAudio::UnderrunError: to satisfy -Wswitch, merely naming that deprecated value triggers a separate -Wdeprecated-declarations warning. LLVM-clang said if it's deprecated it's dead: don't make people write deprecated case labels just to silence an exhaustiveness check. gcc, OTOH, is a bloated 5 ton hippo. Unlike Clang/LLVM, which separates its frontend from the backend, gcc’s pipeline is monolithic and heavily intertwined. So even if gcc developers realize something like this that they're doing is wrong, the gcc codebase is so bloated and monstrous that it likely will never get changed. LLVM/Clang is my preferred compiler these days because it's fast, builds better code, is modular and doesn't waste developer time. gcc and its GNU libraries is deeply entrenched in the linux world. So it is what it is. At least it's been verified that it builds with gcc, even though gcc is gonna complain about stuff that it shouldn't be complaining about since the Qt 6.11 headers are perfectly clear on what's been deprecated in this particular enum. Same Qt 6.11.1 headers, same QtAudio::Error enum, same switch - the only variable is two different compiler's frontends. So I don't think I'm going to add a deadweight |
|
Agreed - I don't worry much about warnings as long as everything works. Like you say, clang is likely the future anyway. 73, |
|
Actually, in the case of JTSDK64-Tools it might not be the same Qt 6.11 headers. Your configure-time warning on Windows points to this. CMake checked for four wrappers which do not exist in MinGW but they do exist in an official Qt 6.11 build. They are generated as a post-install step. This is how toolchains like JTSDK64-Tools or MSYS2 typically deliver Qt, and it's even tracked by QTBUG‑142336 "No qtpaths executable found for deployment purposes" on MinGW/MSYS2 gcc toolchains. It's harmless configure time "noise" that CMake is going to create because of the gcc-based toolchain. However, it does point to MinGW/MSYS2 stripping out some Qt headers to get Qt 6.11 to build, which is probably why the Qt Group now recommends using LLVM-clang to built Qt. They have optimized their code for the clang compiler. |
|
@Joe-K0OG I am testing Qt 6.11 workflows. When you get a chance, could you run the Qt packaging script that is contained in this test repository on x86_64 to build a linux Qt6.11.1 package? It has already been changed in that branch to build the 6.11 package, but must be run on Ubuntu 24 server with no GUI installed so it doesn't put GUI-specific hooks in the build. I can get it from your dropbox for testing if you can build it. |
|
Will do @Chris-AC9KH -- I'll start the job now and let you know when it's been uploaded. |
|
@Chris-AC9KH Just to make sure, I'm building with https://github.com/Chris-AC9KH/JS8Call-improved/blob/pr/Qt6.11_deprecations/tools/Linux-Dist_pkg_Qt6.sh -- correct? |
|
Just a little F.Y.I.: A few days ago I built Qt6.11.1 on my Ubuntu 24 server by changing the Linux-Dist_pkg_Qt6.sh "checkout" from 6.9.3 to 6.11.1 (and I note that the script I used did used clang), and have been using it in my Mint 22.3 build tests I have been reporting on. I'll proceed to make a fresh build with your current script in case there is anything else you changed in it as compared to my modified 6.9.3 script. 73, |
|
Joe, yes that's the correct script that creates a Qt6 package. The other one is just for testing on your local machine and you can set the version of Qt in the variables in the test script. The version of Qt built with the packaging script is hardcoded into the script logic for each release. |
|
That's the script I've been using to build for myself. I wasn't sure what the "test" script was for, so haven't even tried it. |
|
@Chris-AC9KH The Qt6.11.1 library I just built on the Ubuntu 24 server is now posted at my Dropbox: 73, |
|
@wmiler @rruchte @Joe-K0OG I'm very close to a PR that will provide a one-step migration to Qt 6.11.1 on master. I switched the linux workflow builds to llvm-clang 18 instead of gcc. Since the codebase is optimized for clang, plus the Qt6 libs are built with clang, this seems like a logical choice going forward. Got completely compiler spam-free runs on the runners for the first time ever. The runner time seems to be tuned pretty good now. Linux and Windows run neck and neck for time. Mac kicks butt on both of them, but the runner is an Apple silicon machine so there's no real mystery there - it takes less than half the time of the other two. On the linux side the arm64 one is quite a bit faster than x86_64 - it took 4 minutes 45 sec to build the arm64 AppImage. It's the x86_64 one that takes 6 min 31 sec. But this is no real mystery either - due to Apple's influence in the world of arm64 clang is highly optimized and very mature on arm64 RISC chips. There is no workflow cacheing going on anymore. The build libraries come completely from our js8lib repo - I changed the Windows one too because Qt 6.11.1 is not available in the jurplel/install-qt-action pipeline. Each platform has its own branch on js8lib, with scripted toolchain to build the libraries. MacOS is a unified library that contains everything in one tarball. The other two have separate dependency/Qt tarballs or (for Windows) zip archives. Joe, if you could test this AppImage, it would be great. I already tested the arm64 one. Built with llvm-clang 18. With Qt 6.11.1 the binaries are slightly smaller built with clang vs gcc. I extracted the AppImages and inspected them, the binary is linked with the packaged libc++ instead of the GNU libstdc++, which provides 100% compatibility with the Qt builds. The end-user build script will stick with gcc since most end-users are not going to have the LLVM toolchain or libraries installed on their system (except on arm64 where it's standard). Still doing some testing and optimizing, but the goal here is a single PR that switches master over from Qt 6.9.3 to 6.11.1 going forward with minimum hassle and one merge - done. Do all the testing ahead of time instead of chasing your tail trying to fix everything that got broke. Makes it simple to transition to future Qt 6.11 versions. And much easier to transition to Qt 6.12, which will be the next Qt LTS release. |
|
@Chris-AC9KH The AppImage seems to work perfectly - I don't find any hiccups. I do notice that it's slightly larger than the 3.0.2 AppImage: This is not a problem, just an observation - possibly meaningless. 73, |
|
Qt 6.11 libraries and frameworks are slightly bigger than Qt 6.9. I'm running the development build on that branch for a few days to see if there's anything I missed. If everything looks good then I'll create a PR branch from it and PR it. It's a fairly invasive change to go from Qt 6.9.3 to Qt 6.11.1 that touches quite a few files in the source tree. |
|
Basically 12 individual commits on top of master to make the switch. I'll see what I can do to squash some of those down into categories. This does not include any of the experiments I was trying with the new callback-based lock-free audio ring buffer in Qt 6.11. There seems to be some timing issues with that, but master would have to be moved to Qt 6.11 before I could do anything more with it. Allan sent me some code that he is using in SDRTrunk and the implementation is sound. But audio for a SDR application is different from a precision-timed application like JS8Call. I'd like to dig into that further. So I may prepare a PR branch in the next couple hours so can at least work off a branch that is compatible with master and the PR merge stream so I can use the JS8Call-improved workflow builds to validate it. |
|
@Joe-K0OG @wmiler @rruchte I created a Development Snapshot release with a beta tag and there's a actually a few users interested in testing these and they're downloading them. https://github.com/JS8Call-improved/JS8Call-improved/releases/tag/v4.0-beta_1 I think this is good. Most people will stick with the stable software. But the more beta testers we can get on master builds, the better it is IMO. I just grabbed these from the workflow runs. Except for the MacOS one, which I ran locally and sent in to Apple for notarization, otherwise it won't run. Apple will allow one un-versioned beta build per month to run thru their notarization workflow. |
|
@wmiler @Joe-K0OG @rruchte we have successfully made the transition to Qt 6.11 on master and I have detected no issues with it. The release/3.x-series are still built on Qt 6.9.3. Due to deprecations I fixed in the main JS8Call code for Qt 6.11, master will no longer build on an earlier version of Qt, even if the Qt requirement is relaxed. Wyatt, you had requested looking into using Ubuntu 22 Server as the build platform to provide support for legacy glibc versions on linux. I have been looking into this in my spare time. But even installing clang-18 from the official LLVM repo's, I can't get Qt 6.11 to compile on Ubuntu 22, using a "borrowed" Ubuntu 22 Server that a friend of mine owns. And Qt 6.11 requires clang to compile now. So obviously, JS8Call won't build on Ubuntu 22 either since our linux Qt libraries are compiled with clang, requiring glibc 2.38 minimum. I haven't found a way to "hack" that one to make it work. I think Joe's assessment that we need to give up on trying to support every linux distribution and version that was ever invented is probably the most practical. As far as I can tell, this kicks Ubuntu 22, Debian 12, Mint 21 and Fedora 40/RedHat 9 to the curb as no longer supported. Like Joe said, there is probably few people running these anymore since they are so old. I'm sure there is a few, but they have to run the older software, JS8Call 3.0.2 and earlier, since the release/3.0.3 was built using the new build system with Qt 6.9.3 requiring glibc 2.38 or newer. Arch Linux and its derivatives, like Manjaro, seem to not be affected by this. They seem to have a better system in place with their "rolling release" schedule that keeps up with the latest stuff, so they can support the latest stuff. Others, like pure Debian, are the absolute worst of the bunch, locking in legacy stuff for years in some cases with no set schedule as to when it's going to be updated. Ubuntu seems to set the "standard" in the Debian-based world. And while Ubuntu 22 is still in LTS, that's only for security updates, not software. With Ubuntu 26 officially on the streets, Ubuntu 24 becomes the new baseline for minimum glibc version. |
Yes - and if people really need support for even older O.S. versions, they can still download and run JS8Call 2.x and still be compatible on-air. We have done a really good job of maintaining backward compatibility of the JS8 modem, and I hope we can continue to do so. 73, |
Just need to state which is the last version to support glibc < 2.38 and add it to the documentation. Master doesn't have to stay with the limitation. |
|
6.11 adds a native PipeWire backend for Linux that 6.9 doesn't have. Hopefully this will help to get rid of some of these audio problems on linux like hung connections that won't close. The 6.9 pulse audio compatibility layer was a steppingstone that obviously has some issues. It will be up to the linux developers to take advantage of the new native backend. |
|
@wmiler even with a universal build I found out I can't support older than MacOS 14 Sonoma on Intel Macs. The SDK is too old and Qt 6.9.3 does not support it. There was weirdness like the Mode Button failing to update, incoming decodes never display in textEditRX. And several other anomalies. So I "fixed" it. I refuse to host the universal build on the official release, and instead linked it to my personal repo for legacy Mac users. I re-built the package, requiring minimum MacOS 14. This is hopefully the last universal build I ever have to do because we're only two months away from MacOS 27 and then Mac on Intel is officially dead, as least as far as software support. https://github.com/Chris-AC9KH/JS8Call-improved/releases/tag/v3.0.3 I positively locked it down so this build will not run on anything less than MacOS 14: 
|
|
That's fine. We do need to have a block of documentation somewhere that states things like, last version supported on 32bit OSes, or QT5, etc. Such that people know where the breakpoints are for their hardware. |
|
I now have code that migrates the current v1 JSON blob MSG inbox.db3 to a new v2 relational column-based database schema. Not available for public testing yet as it semi-breaks backwards compatibility with the old v1 database table schema. The software runs fire-once code that creates the new v2 database table, reads in the old v1 table and populates the new one. The old v1 database table, while not removed during the migration, is then abandoned and will be cleaned up and removed in a future release after it is deemed migration to the new schema is (mostly) complete. Along with a future PR (as soon as some other MSG inbox-related stuff lands in master) that will have one commit for the database migration, it will include a second commit that adds push notification of stored MSG's that does not depend on HB ACK or QUERY MSG's to be notified that you have stored MSG(s) to be retrieved on another station. The two commits kind of go together because querying the old JSON blob schema is not all that efficient and is not suitable for new enhancements we've added to the MSG inbox system to make it a more integral part of the UI instead of being tacked on as afterthought. This obviously changes how things are done in the code and we no longer use scary and fragile methods like |
|
Along with the above roadmap another thing on my radar is to move the QSettings-created JS8Call.ini, which is extremely fragile, to a SQL database. With everything on my target list at present this will likely not happen until next winter sometime, but definitely before JS8Call 4. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
@wmiler @Joe-K0OG @aknrdureegaesr @jsherer I decided to prove everybody wrong and demonstrate that a Debian .deb for JS8Call 3.0.2 can be built.
Steps to build a Debian .deb
MUST be done on Ubuntu 24 Server with no GUI. If you build the Qt6 package on any system with a GUI installed it will put GUI-specific hooks in QtCore and your deb will not run on anything but the system configuration it was built on - it will not be portable. Theoretically, it should be possible to build on a stripped down Debian system as well, but you won't get the correct glibc version, and the scripts are hard-coded to require Ubuntu 24 Server.
Clone the js8lib repo and checkout the Linux_3.0 branch
Run the Distribution_package_js8lib script that you find in that branch.
In the tools directory in master use wget or another method to obtain and run the Linux-Dist_pkg_Qt6 script. On a Mac mini M4 Pro it takes roughly 4 1/2 minutes to built Qt6. On a x86_64 machine it will probably take a lot longer.
Upload both of the resulting tarballs to js8lib 3.0 release. They will NOT work from the local builds on your build machine, so don't even try it.
In the tools directory in master obtain and run the Debian_build_deb script. It will fetch the distribution libraries from js8lib, build JS8Call and package it as a .deb that will work on any Debian-based system with glibc 2.39 and later.
The resulting .deb carries both js8lib3.0 (with Hamlib 4.7.1) and Qt6.9.3 as part of the .deb payload. It will install and run on a Debian-based system with no other dependancies required. With these tools, Debian-based distribution package maintainers should have no problem building and packaging JS8Call 3.0.2 for their distribution. They will have to modify the scripts as necessary to fit their policies. But I did the legwork, and laid the groundwork, to make it possible.
I tried to document every step in the .deb building script as thoroughly as possible in the event we want to put this into a github workflow.
I am not familiar enough with the Tachometer-based Distributions to do anything with rpm's. Somebody else will have to figure that one out.
All reactions