Add files to allow generation of Flatpak packages. #600
Conversation
There was a problem hiding this comment.
Per current project policy, having flatpak-builder patch LPCNet is preferable to opening a PR in this project as it will eventually become deprecated/obsolete.
There was a problem hiding this comment.
(Flatpak does not appear to provide the ability to copy lpcnet_191005_v1.0.tgz to the correct location in the unpatched version. Without this patch, CMake will attempt to download this file, which as mentioned in the PR's README, will fail in the Flatpak environment.)
|
My initial reaction to seeing the comments on the ML about using Flatpak was OMG please no! |
I see it as a supplement, not a replacement for distro packages. The concern would be if the distro maintainers decide to remove FreeDV packages because "people can just use Flatpak". I'm not sure how likely that is, though. |
|
I was looking for package statistics and found this: https://repology.org/project/freedv-gui/versions Basically, only Arch and some sort of Windows package repo appear to be on 1.9.4. Every other distro's freedv package is some level of outdated. |
This concern will almost never happened at all ! There are so many packages in official Fedora repositories that have currently correspondent flatpak packages on FlatHub since some years ago but still existing till now & continuously updated (BUT AT MUCH SLOWER RATE) than their correspondent flatpak ..... Till now I did not hear - please correct to me if wrong - about any package discontinued from official repositories just for being available as flatpak ! |
I haven't heard of any happening but I also don't keep up with packaging/distro news all that much. @barjac or @Tyrbiter might know more. |
|
It's difficult for me to comment in any illuminating manner about the Flat* ecosystem, while I understand why people like the idea of Flathub/pak it's something that I don't use myself. The delay in getting up to date freedv is apparently due to sioclient not being available in Fedora, but I get round it by using the Fedora spec file and creating my own tarball including the sioclient files which are downloaded during the build process. My suggestion is to learn how to build your own rpms but not using the mock build tool as that makes including code from outside Fedora more difficult. It is also possible to download the freedv git tree from github and use the build_linux.sh method, then run the freedv executable with all libraries included that this build method creates. It's a good opportunity to learn more about Fedora and the build system. I recommend trying to keep up to date with Fedora releases if possible, Fedora 39 is better and more stable than Fedora 38, once Fedora 40 has stabilised for a month or two then that will probably have better stability again. Fedora has always been a moving target. |
|
If sioclient was added as a Git submodule, would that help at all? Or would Fedora and other distros still not be able to grab it for building packages? |
This is probably outside my knowledge, maybe @hobbes1069 could comment as he is the freedv packager for Fedora. |
|
@Tyrbiter |
|
Looks like the Fedora maintainer is creating an sioclient-cpp package request: https://bugzilla.redhat.com/show_bug.cgi?id=2271219 Once that is added to the repos then I think updated freedv to include the reporting facility will happen fairly quickly. |
|
Well, I tried to get freedv to build using the sioclient-cpp package but I can't get it to find and use the include files. I expect @tmiw knows how to do this. |
Might need to provide |
Not sure, but it seems gcc 14 is stricter with all sorts of code requirements, wouldn't surprise me if this has prevented my build system from working even with using the previous working setup. Fedora 40 beta being clever. Any help appreciated :) |
What errors is it spitting out now, exactly? Still stuff about not being able to find the include files or something else? |
|
This is the only red text error in the build output until the build stops later: /home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/src/reporting/FreeDVReporter.cpp: In member function ‘void FreeDVReporter::connect_()’: then eventually: [ 87%] Linking CXX static library libfdv_gui_dialogs.a If you need more information please shout. |
|
If I try to use the build_linux.sh method I get this: [ 4%] Building C object _deps/wxwidgets-build/libs/CMakeFiles/wxzlib.dir////src/zlib/gzlib.c.o Might be due to a security problem that has caused a return to an earlier version of the xz packages. I'm not sure. |
|
Considering that it's complaining about standard library functions not being there, I suspect something is messed up in one or more of the Fedora compiler/library packages :( Might be worth trying again once they update anything in those. |
|
There are a few issues, but that's betas for you. I will wait a while and see what happens. I have a working package installed so it's no rush. If I really have to I can always build in a mock chroot, which I usually don't need to do. |
|
Dear friends, I observed that this issue is active & recent posts coming. But, I see them - please correct to me if I'm wrong - about something away from Flatpak ! I see that you searching to prepare Fedora specific package, an rpm package ! My opinion is that: flatpak is much better from trying to make a distro specific package .... Even if you solved problem of Fedora, what about other distros ? Instead of multiple heavy efforts for many distros, unify efforts (& totally will be much less) to prepare flatpak package that will work on almost all of Linux distros ..... Regards. |
I think both can coexist. Only releasing Flatpaks could turn off a significant number of people who prefer distro packages for lower overhead, for example. |
Turns out that what breaks the build is installing the sioclient-cpp packages (which are not yet official packages), the build process fails probably because it sees the -devel package headers but does not know where the package files are actually installed. I shall wait for @hobbes1069 to update his spec file and submit sioclient-cpp so that he can update freedv too. I think this will help @Nokia808 because he will be able to get an up to date freedv in Fedora. |
Finally got back round to looking at this, where do I need to add that -D string @tmiw ? |
Add that to the end of the |
|
OK, so I have been trying to make this work with the Fedora build system after installing the sioclient-cpp packages from @hobbes1069 I think I need to do something in the cmake/BuildSocketIo.cmake file to make things behave in the same way as the cmake/BuildHamlib.cmake and similar files for codec2 and LPCNet, I see that those have CMAKE_SHARED_LIBRARY_SUFFIX whereas the Socket.Io file has CMAKE_STATIC_LIBRARY_SUFFIX It's way above my head really, sorry to keep asking about it. |
|
If it's able to detect the sioclient-cpp package, I would think that you wouldn't need to update BuildSocketIo.cmake. That file should only be getting used if it can't find the library for whatever reason. |
|
OK, so I tried the build_linux.sh edit with -DSIOCLIENT_ROOT=/usr/ added as suggested, I wanted to eliminate the Fedora build system from the process. This is a trimmed output from the console: -- Finding PulseAudio... As you can see, it finds the path to libsioclient.so and the include file path for the -devel package files but then gives the warning about the SIOCLIENT_ROOT variable. |
|
Hmm, seems like nothing special is needed for the build environment to find the library at least. You still get compile errors afterward I assume? If so, the same ones as above (i.e. with |
|
This one: /home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/src/reporting/FreeDVReporter.cpp: In member function ‘void FreeDVReporter::connect_()’: and eventually it errors out further down, I assume where the linker fails to find the function offset it's looking for. |
|
Ah, actually on this occasion, here is the final error, it is different from the one when using the spec file and rpmbuild: [ 66%] Building CXX object src/reporting/CMakeFiles/fdv_reporting.dir/FreeDVReporter.cpp.o |
|
So I'm wondering what version of sioclient-cpp is getting used here because per their latest master on GH, the correct function should exist: // Client Functions - such as send, etc.
void connect(const std::string& uri);
void connect(const std::string& uri, const message::ptr& auth);
void connect(const std::string& uri, const std::map<std::string,std::string>& query);
void connect(const std::string& uri, const std::map<std::string,std::string>& query, const message::ptr& auth);
void connect(const std::string& uri, const std::map<std::string,std::string>& query,
const std::map<std::string,std::string>& http_extra_headers);
void connect(const std::string& uri, const std::map<std::string,std::string>& query,
const std::map<std::string,std::string>& http_extra_headers, const message::ptr& auth);I suspect making sure that the sioclient-cpp package uses |
|
It's version 3.1.0, which I see is actually over 2 years old. No new release since then, but I see there have been 253 commits to master, which could explain a lot. |
Yeah, we actually need the functionality added by those unfortunately. It would be nice if they released another official version if it's not possible to just refer to Git hashes in the package. |
I will request this for the Fedora packages of sioclient-cpp, so far @hobbes1069 has not yet completed the packaging and submitted it to the testing repos so might be able to get that sorted out. |
|
I cloned the socket.io-client-cpp git repo master code, created a local sioclient-cpp build for Fedora 40 using the CMakeLists.txt that @hobbes1069 used for his Fedora packages, built and installed these packages and then rebuilt freedv. The build succeeded and the resulting installed freedv packages seem to work OK and I can see the FreeDV Reporter data in the application window as normal. I get this, which is definitely linking to the shared object: bdm@deangelis:~/rpmbuild/SPECS$ ldd /usr/bin/freedv | grep sio |
|
Is there a hope to see freeDV shipped as flatpak package on FlatHub or not ? It seem that flatpak is the ONLY WAY to make freeDV up-to-date version available on Linux ! Otherwise, MOST Linux user will remain for ever with old out dated version ! |
We haven't forgotten about this! We're still working on some higher priority items (for example, the RADAE mode); once that's farther along we'll revisit this. EDIT: @Tyrbiter, any more work done on the Fedora side lately? |
Yes, things are moving along but still have not got a recent sioclient-cpp package into Fedora 40, or even Fedora 41. @hobbes1069 is working on it, I had a response from him earlier today, he's getting the build spec file polished after a review cycle, then will look at an sioclient snapshot and at that point it should be possible to get freedv updated to a 1.9.x version. Local builds of the latest code work perfectly well for me under Fedora 40. I would advise @Nokia808 to be ready to update his system to Fedora 41 as soon as it's available, the beta should be due on 24th September, release in late October or early November. I can't see the new packages being released in earlier Fedora versions. |
|
Closing this since we're not currently doing any work on Flatpak distribution. Please create a feature request in GH if you'd like this to be revisited. |
|
On 07/09/2024 13:06, Nokia808 wrote:
Is there a hope to see freeDV shipped as flatpak package on FlatHub or not ? It seem that flatpak is the ONLY WAY to make freeDV up-to-date version available on Linux ! Otherwise, MOST Linux user will remain for ever with old out dated version !
It is not the only way at all. And please don't promote Flatpak.
You could use this:
https://github.com/barjac/freedv-rade-build
...which I and many others are using on various Linux distributions.
Barry
G4MKT
|
This PR adds a new
flatpakfolder in the source tree to enable generation of Flatpak packages for FreeDV. By doing so, this should hopefully allow users who prefer to run the newest versions of FreeDV to do so. It's presumed that distro-specific packages will still be maintained and available (albeit slightly older than the Flatpak one) for those who don't want to take on the additional overhead.(More information about Flatpak at https://flatpak.org/.)
Remaining tasks: