scrubbbbs
Questions about wip branch and status of project
I didn't want to clutter my other issue, so here is another one. EDIT: is there a possibility of enabling discussions or is using issues for this sort of thing ok with you?
I noticed that the wip branch is gone and there were commits on Sep. 4th. Was wip merged into main? You mentioned that you updated select-grid option.
I had to compile this from scratch because I use Linux with arm64 and I also wanted all the non-free codec support. Should I compile again now, or are you planning some other changes within the month for a version bump?
Also, on the subject of compiling to get non-free codec support, is there a way like in windows to just look for a FFmpeg (or whatever) library file in a custom directory? So I can keep a compiled version of that and just point cbird to it? Compiling FFmpeg is time-consuming, so it would be nice to only do it every sub-major version.
I noticed that the wip branch is gone and there were commits on Sep. 4th. Was wip merged into main? You mentioned that you updated select-grid option.
There is no unstable/development/wip branch, so "main" contains the current code. I'm generally not going to commit anything that is unstable/wip. There are version tags for each binary release version if there is any need to go back.
Also, on the subject of compiling to get non-free codec support, is there a way like in windows to just look for a FFmpeg (or whatever) library file in a custom directory? So I can keep a compiled version of that and just point cbird to it? Compiling FFmpeg is time-consuming, so it would be nice to only do it every sub-major version.
On windows, in most cases you can copy the .dll into the same dir as the .exe (this should work with cbird). On Linux you set LD_LIBRARY_PATH in the environment to contain the folder with the *.so stuff in it. This requires compiling libraries with a different install prefix. For example, instead of /usr/local, use /home/user/cbird, then you would have to set this in your bashrc file:
export LD_LIBRARY_PATH=/home/user/cbird/lib:$LD_LIBRARY_PATH
You could also build the .appimage for Linux which packages up everything.
You could also build the .appimage for Linux which packages up everything.
Do the instructions for building the AppImage also include compiling and using custom FFmpeg?
Do the instructions for building the AppImage also include compiling and using custom FFmpeg?
I've never tried on arm so YMMV, but yes, the appimage recipe shows how to compile most of the libraries, you can modify it to get a custom FFmpeg. You don't necessarily have to compile them all, but I've never tried that myself. In theory the packager can collect all the libraries even if they came with the system package manager.
Somewhat off-topic. Do you happen to know if there is an open-source decoder for every proprietary format that works in 90% of cases? Is it possible that I don't even need these non-free codecs? I know there is some overlap for h265 because of x265 which is open-source.
Do you happen to know if there is an open-source decoder for every proprietary format
FFmpeg is pretty much it. Proprietary/closed formats have been reverse-engineered in some cases like Apple ProRes.
How do I compile the AppImage for aarch64?
EDIT: I'm just going to make a docker image to compile it for me. I am concerned about the time for rebuilding the image, so I think I will just bind in a directory with the downloaded cbird source code.
According to the search on github, there are only 3 files which mention linuxdeployqt. I have used sed to edit all of them to replace the Downloads full path with just linuxdeployqt. I cannot use the appimage because I am on arm64. Still, it is using that path. Where is it getting it from?
The files I have edited are cbird.pro before calling qmake, deploy.sh and Makefile after calling qmake. Did I miss something? This is the last step for the Dockerfile and I will have a new build.
EDIT:
one of my sed commands is like this sed 's/~\/Downloads\/linuxdeployqt-continuous-x86_64\.AppImage/linuxdeployqt/g' cbird.pro
I cannot use the appimage because I am on arm64. Still, it is using that path. Where is it getting it from?
cbird.pro contains the only relevant reference to linuxdeployqt, and "make appimage" should work provided you have it pointed to the arm64 version of linuxdeployqt.
deploy.sh has never been used for release binaries, it appears to use a completely different linuxdeployqt script (not the official version).
I forgot the -i in the sed command. D'oh!
I am having trouble getting cbird and linuxdeployqt happy on the same image. linuxdeployqt needs qt5 and cbird needs qt6. I am unsure what package to install on Ubuntu bionic for the base qt5 install to get linuxdeploy compiling. I was compiling it on a different image and copying it, but then it can't find the qt5 shared libraries. UGH!
OK, I got it working, except it seems that I cannot make an appimage for aarch64 on my machine.
I get error
ERROR: findDependencyInfo: "/bin/bash: error while loading shared libraries: libtinfo.so.5: ELF load command alignment not page-aligned\n"
OK, I got it working, except it seems that I cannot make an appimage for aarch64 on my machine.
Is this from running or making the appImage? Seems to be a common issue on ARM when linker flags are incorrect. Does cbird work in the container without the appImage?
This is from the make appimage command. I have compiled cbird directly in the container, and it works in the container (older version). I compiled the new version, but have not used it yet. I have an M1 Mac mini. I ditched macOS and have Linux on it, but I also run a Whonix VM. I was hoping to compile the AppImage once for both. I guess that is out of the question for now.
Any chance of a flatpak as well as an appimage? Or do you know how I could compile my own flatpak?
Any chance of a flatpak as well as an appimage? Or do you know how I could compile my own flatpak?
Not a priority, I feel AppImage is more accessible. I haven't looked into flatpak at all, all I know is that it annoys me whenever I have to use it.
The version in releases does not have your latest changes. When will the appimage be released with the new changes. I am finally done with arm64 and back on good 'ol x86-64.
It hasn't been on my mind but I appreciate the interest. I guess I could do a quick build and release as a beta
"quick" build is up, took me longer than I thought because of an issue with the recipe. I did not update libraries (using versions from 0.7.0) but everything seems OK. Found out the windows/mac build are broken, not too badly though.