drowe67
Add files to allow generation of Flatpak packages.
This PR adds a new flatpak folder 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:
- [ ] Have others test the instructions in this PR to ensure that packages can be generated and that FreeDV executes normally inside the Flatpak container.
- [ ] Customize anything additional with the generated packages as needed (i.e. application icon)
My initial reaction to seeing the comments on the ML about using Flatpak was OMG please no! If package maintainers do not keep your version reasonably up to date contact them! File bug reports and/or change your distro to one that does!
My initial reaction to seeing the comments on the ML about using Flatpak was OMG please no! If package maintainers do not keep your version reasonably up to date contact them! File bug reports and/or change your distro to one that does!
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.
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. > >
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 !
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. > >
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?
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 You could probably use the Mageia libsioclient rpm for Fedora that I packaged some time ago. https://svnweb.mageia.org/packages/cauldron/libsioclient/ I had to use a git snapshot at the time as the last release broke the freedv build.
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.
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 -DSIOCLIENT_ROOT=/usr/ or wherever it got installed to when calling cmake.
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
-DSIOCLIENT_ROOT=/usr/or wherever it got installed to when callingcmake.
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 :)
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
-DSIOCLIENT_ROOT=/usr/or wherever it got installed to when callingcmake.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_()’:
/home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/src/reporting/FreeDVReporter.cpp:322:24: error: no matching function for call to ‘sio::client::connect(std::cxx11::basic_string
then eventually:
[ 87%] Linking CXX static library libfdv_gui_dialogs.a cd /home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/redhat-linux-build/src/gui/dialogs && /usr/bin/cmake -P CMakeFiles/fdv_gui_dialogs.dir/cmake_clean_target.cmake cd /home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/redhat-linux-build/src/gui/dialogs && /usr/bin/cmake -E cmake_link_script CMakeFiles/fdv_gui_dialogs.dir/link.txt --verbose=1 /usr/bin/ar qc libfdv_gui_dialogs.a CMakeFiles/fdv_gui_dialogs.dir/dlg_audiooptions.cpp.o CMakeFiles/fdv_gui_dialogs.dir/dlg_easy_setup.cpp.o CMakeFiles/fdv_gui_dialogs.dir/dlg_filter.cpp.o CMakeFiles/fdv_gui_dialogs.dir/dlg_options.cpp.o CMakeFiles/fdv_gui_dialogs.dir/dlg_ptt.cpp.o CMakeFiles/fdv_gui_dialogs.dir/freedv_reporter.cpp.o /usr/bin/ranlib libfdv_gui_dialogs.a gmake[2]: Leaving directory '/home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/redhat-linux-build' [ 87%] Built target fdv_gui_dialogs gmake[1]: Leaving directory '/home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/redhat-linux-build' gmake: *** [Makefile:159: all] Error 2
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 cd /home/bdm/git/freedv-gui-ms-leak-cleanup/build_linux/_deps/wxwidgets-build/libs && /usr/lib64/ccache/cc -DGIT_HASH="3e86449" -D_FILE_OFFSET_BITS=64 -D_UNICODE -I/home/bdm/git/freedv-gui-ms-leak-cleanup/build_linux/_deps/wxwidgets-build/lib/wx/include/gtk3-unicode-static-3.2 -Wall -g -fPIC -pthread -MD -MT _deps/wxwidgets-build/libs/CMakeFiles/wxzlib.dir////src/zlib/gzlib.c.o -MF CMakeFiles/wxzlib.dir////src/zlib/gzlib.c.o.d -o CMakeFiles/wxzlib.dir////src/zlib/gzlib.c.o -c /home/bdm/git/freedv-gui-ms-leak-cleanup/build_linux/_deps/wxwidgets-src/src/zlib/gzlib.c /home/bdm/git/freedv-gui-ms-leak-cleanup/build_linux/_deps/wxwidgets-src/src/zlib/gzlib.c: In function ‘gz_open’: /home/bdm/git/freedv-gui-ms-leak-cleanup/build_linux/_deps/wxwidgets-src/src/zlib/gzlib.c:14:17: error: implicit declaration of function ‘lseek’; did you mean ‘fseek’? [-Wimplicit-function-declaration] 14 | # define LSEEK lseek | ^~~~~ /home/bdm/git/freedv-gui-ms-leak-cleanup/build_linux/_deps/wxwidgets-src/src/zlib/gzlib.c:254:9: note: in expansion of macro ‘LSEEK’ 254 | LSEEK(state->fd, 0, SEEK_END); /* so gzoffset() is correct */ | ^~~~~ make[2]: *** [_deps/wxwidgets-build/libs/CMakeFiles/wxzlib.dir/build.make:146: _deps/wxwidgets-build/libs/CMakeFiles/wxzlib.dir///__/src/zlib/gzlib.c.o] Error 1 make[2]: Leaving directory '/home/bdm/git/freedv-gui-ms-leak-cleanup/build_linux'
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.
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.
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.
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.
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
-DSIOCLIENT_ROOT=/usr/or wherever it got installed to when callingcmake.
Finally got back round to looking at this, where do I need to add that -D string @tmiw ?
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
-DSIOCLIENT_ROOT=/usr/or wherever it got installed to when callingcmake.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 cmake call in build_linux.sh, i.e.
cmake $PULSEAUDIO_PARAM -DUNITTEST=$UT_ENABLE -DCMAKE_BUILD_TYPE=Debug -DCODEC2_BUILD_DIR=$CODEC2DIR/build_linux $LPCNET_CMAKE_CMD -DSIOCLIENT_ROOT=/usr/ ..
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. cmake output from your machine would probably be useful here to see what's going on.
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... -- PulseAudio library: /usr/lib64/libpulse.so -- PulseAudio headers: /usr/include -- Looking for hamlib... -- Hamlib library: /usr/lib64/libhamlib.so -- Hamlib headers: /usr/include -- Hamlib library found. -- Looking for sioclient... -- Socket.io library: /usr/lib64/libsioclient.so -- Socket.io headers: /usr/include -- Socket.io library found. -- Looking for samplerate... -- samplerate library: /usr/lib64/libsamplerate.so -- samplerate headers: /usr/include -- Looking for sndfile... -- sndfile library: /usr/lib64/libsndfile.so -- sndfile headers: /usr/include -- Looking for Speex DSP library. -- Speex DSP headers: /usr/include -- Speex DSP library: /usr/lib64/libspeexdsp.so System is Linux -- Looking for dl library. -- dl library: /usr/lib64/libdl.a -- Build type will be: Debug -- Configuring done (3.2s) -- Generating done (0.0s) CMake Warning: Manually-specified variables were not used by the project:
SIOCLIENT_ROOT
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 fseek) or different ones?
This one:
/home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/src/reporting/FreeDVReporter.cpp: In member function ‘void FreeDVReporter::connect_()’: /home/bdm/rpmbuild/BUILD/freedv-gui-1.9.9/src/reporting/FreeDVReporter.cpp:322:24: error: no matching function for call to ‘sio::client::connect(std::cxx11::basic_string, sio::message::ptr&)’ 322 | sioClient->connect(std::string("http://") + hostname + "/", authPtr); | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
cd /home/bdm/git/freedv-gui/build_linux/src/reporting && /usr/lib64/ccache/c++ -DAUDIO_ENGINE_PULSEAUDIO_ENABLE -DGIT_HASH="12de561b" -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/home/bdm/git/freedv-gui/build_linux -isystem /usr/lib64/wx/include/gtk3-unicode-3.2 -isystem /usr/include/wx-3.2 -Wall -pthread -g -std=c++14 -MD -MT src/reporting/CMakeFiles/fdv_reporting.dir/FreeDVReporter.cpp.o -MF CMakeFiles/fdv_reporting.dir/FreeDVReporter.cpp.o.d -o CMakeFiles/fdv_reporting.dir/FreeDVReporter.cpp.o -c /home/bdm/git/freedv-gui/src/reporting/FreeDVReporter.cpp
/home/bdm/git/freedv-gui/src/reporting/FreeDVReporter.cpp: In member function ‘void FreeDVReporter::connect_()’:
/home/bdm/git/freedv-gui/src/reporting/FreeDVReporter.cpp:322:24: error: no matching function for call to ‘sio::client::connect(std::cxx11::basic_string
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 master will solve this particular error at least.