Sorry, I missed those modifications and only noticed at full rebuild. disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up ( Phyllis, Andrea - can you test this on regular x86, including older/random distro?
I can't compile in either arch 64-bit or Debian 11 32-bit (VM). I attach the two logs.
Here did some testing yesterday late, the x86_84 build works fine on Fedora_35. The aarch64 builds on both Debian_11 and Fedora_35 failed, from a quick look at the same spots. I did the make with the --trace option added, easier to find where it goes wrong. Have not looked in detail yet, but certainly an error building libaom, and one for config.guess . MatN On Fri, 26 Nov 2021 13:22:32 +0100 Andrea paz via Cin <[email protected]> wrote:
I can't compile in either arch 64-bit or Debian 11 32-bit (VM). I attach the two logs.
On Friday, November 26, 2021, mnieuw--- via Cin <[email protected]> wrote:
Here did some testing yesterday late, the x86_84 build works fine on Fedora_35.
The aarch64 builds on both Debian_11 and Fedora_35 failed, from a quick look at the same spots. I did the make with the --trace option added, easier to find where it goes wrong. Have not looked in detail yet, but certainly an error building libaom, and one for config.guess .
i think you can try and capture and post build log fir aarch64 here? i think different autoconf configurations behave.. um, differently. I renamed configure.in into configure.ac for libavc1394, yet it builds both ways for me...
MatN
On Fri, 26 Nov 2021 13:22:32 +0100 Andrea paz via Cin <[email protected]> wrote:
I can't compile in either arch 64-bit or Debian 11 32-bit (VM). I attach the two logs.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
try this patch on top of earlier patch? also, be sure to remove thirdparty/build/libavc1394* and thirdparty/libavc1394-0.5.4 On Friday, November 26, 2021, Andrea paz <[email protected]> wrote:
I can't compile in either arch 64-bit or Debian 11 32-bit (VM). I attach the two logs.
I tested the 2 patch with same error. I have no .../thirdparty/build/, but I have .../thirdparty/src/ In .../thirdparty/src/ I have only libavc1394-0.5.4.tar.xz In .../thirdparty/ I havn't libavc1394-0.5.4, but, after patching, I have libavc1394-0.5.4.patch1 and libavc1394-0.5.4.patch2 After the failed build I have also .../thirdparty/build/ with libavc1394.source Maybe I need to apply the 0002 patch after compiling and getting the error? I wouldn't know how to do that....
On Friday, November 26, 2021, Andrea paz <[email protected]> wrote:
I tested the 2 patch with same error.
I have no .../thirdparty/build/, but I have .../thirdparty/src/
In .../thirdparty/src/ I have only libavc1394-0.5.4.tar.xz
In .../thirdparty/ I havn't libavc1394-0.5.4, but, after patching, I have libavc1394-0.5.4.patch1 and libavc1394-0.5.4.patch2
in thirdparty or in thirdparty/src?
After the failed build I have also .../thirdparty/build/ with libavc1394.source Maybe I need to apply the 0002 patch after compiling and getting the error? I wouldn't know how to do that....
no.. for some reason both builds failed to patch configure.ac?? for me it exist after successfull build: $ ls thirdparty/libavc1394-0.5.4/configure.ac -la -rw------- 1 u0_a116 u0_a116 627 Nov 26 16:09 thirdparty/libavc1394-0.5.4/ configure.ac $ how exactly you patch? git am or simple patch?
On Friday, November 26, 2021, Andrea paz <[email protected]> wrote:
in thirdparty or in thirdparty/src? In /thirdparty only
ow, then it was misplaced. try to move both into thirdparty/src
how exactly you patch? git am or simple patch? I use the classic patch < ... from the directory where the patch should be applied. (/thirdparty in this case).
hm, in my case patch was constructed by git format-patch and thus better to be applied by git am.
Andrea, I patch while in the cinelerra5.1 directory using the -p parameter. That strips the specified number of forward slashes plus all that precedes it before applying the patch. For instance, Andrew's recent 0001.. patch has in it: +++ b/cinelerra-5.1/thirdparty/Makefile Using -p2 that is shortened to +++ thirdparty/Makefile which is exactly right when you are in the cinelerra5.1 directory. So I patch like patch -p2 <~/Downloads/0001-Add-libavc1394-termux-patch-mod-thirdparty-Makefile-.patch MatN On Fri, 26 Nov 2021 18:32:24 +0100 Andrea paz via Cin <[email protected]> wrote:
in thirdparty or in thirdparty/src? In /thirdparty only
how exactly you patch? git am or simple patch? I use the classic patch < ... from the directory where the patch should be applied. (/thirdparty in this case)
This initial patch worked with no errors on Fedora 32. Will be trying older versions today yet. I did NOT apply 0002-Test-try-to-fix-autoreconf-in-libav1394.patch because this one worked. What now? On Fri, Nov 26, 2021 at 12:25 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Sorry, I missed those modifications and only noticed at full rebuild.
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Saturday, November 27, 2021, Phyllis Smith via Cin < [email protected]> wrote:
This initial patch worked with no errors on Fedora 32. Will be trying older versions today yet. I did NOT apply 0002-Test-try-to-fix-autoreconf-in-libav1394.patch because this one worked. What now?
wait for Andrea's test after repatching... (a bit afraid about breaking build just before release - we can put this and future related patches after monthly release is out..)
On Fri, Nov 26, 2021 at 12:25 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Sorry, I missed those modifications and only noticed at full rebuild.
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
1- Applying only the first patch and then moving the result (libavc1394-0.5.4.patch1) to .../thirdparty//src, the compilation is successful, without even using patch 2. I used patch < ... instead of git am 2- Using also the second patch and moving the result (libavc1394-0.5.4.patch1 and libavc1394-0.5.4.patch2) to .../thirdparty/src, the compilation is still successful. I couldn't tell the differences. 3- Using only the first patch with "git am" the compilation is successful. In this case I put the patch in .../cinelerra-5.1, without entering /thirdparty and without moving the result of the patch to /thirdparty/src. I can't tell if there are any differences with the other builds.
On Saturday, November 27, 2021, Andrea paz <[email protected]> wrote:
1- Applying only the first patch and then moving the result (libavc1394-0.5.4.patch1) to .../thirdparty//src, the compilation is successful, without even using patch 2. I used patch < ... instead of git am
2- Using also the second patch and moving the result (libavc1394-0.5.4.patch1 and libavc1394-0.5.4.patch2) to .../thirdparty/src, the compilation is still successful. I couldn't tell the differences.
3- Using only the first patch with "git am" the compilation is successful. In this case I put the patch in .../cinelerra-5.1, without entering /thirdparty and without moving the result of the patch to /thirdparty/src. I can't tell if there are any differences with the other builds.
oh, very cool, I was afraid i broke build too hard for even fixing (once in time I tried autoreconf on kde3 sources.. it failed in mysterious for me ways!) still, because I suspect more of such patches will be needed for new-ish architectures (ppc64le, aarch64, e2k..) this specific patch might go in or wait depending on Phyllis feelings as de-facto our release engineer (most periodic-release softwares tend to have feature/code freeze just before release)
still, because I suspect more of such patches will be needed for new-ish architectures (ppc64le, aarch64, e2k..) this specific patch might go in or wait depending on Phyllis feelings as de-facto our release engineer (most periodic-release softwares tend to have feature/code freeze just before release)
Yes, I had a cutoff date of the 25th to put in patches and was hoping that everything for Termux/Android would be done but we can wait until next month to add any more mods that were missed. Best to stop now until after the 30th.
I also tried the build on Debian 11 32-bit (VM) with patch 0001 and everything is Ok. @MatN Thanks for the explanations about the "patch" command. I tried the -p2 option and everything works fine. I've always been confused about which -p(n) to use; for example in this case I would have used -p3, also counting the slash of "b/...". Anyway, I thought that by copying the patch to the directory where the file to be patched is located, there was no need to specify -p(n). I was wrong!
I have tested with patch 001. On Fedora_35, native X86_64, build of static and appimage are fine. They load too. On Debian_11. Qemu/aarch64, build fails early on. Log and bld.sh I used attached. For the record: I never yet had a successful build in aarch64. MatN On Sat, 27 Nov 2021 02:58:09 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
On Saturday, November 27, 2021, Phyllis Smith via Cin < [email protected]> wrote:
This initial patch worked with no errors on Fedora 32. Will be trying older versions today yet. I did NOT apply 0002-Test-try-to-fix-autoreconf-in-libav1394.patch because this one worked. What now?
wait for Andrea's test after repatching... (a bit afraid about breaking build just before release - we can put this and future related patches after monthly release is out..)
On Fri, Nov 26, 2021 at 12:25 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Sorry, I missed those modifications and only noticed at full rebuild.
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Saturday, November 27, 2021, mnieuw--- via Cin < [email protected]> wrote:
I have tested with patch 001.
On Fedora_35, native X86_64, build of static and appimage are fine. They load too.
On Debian_11. Qemu/aarch64, build fails early on. Log and bld.sh I used attached. For the record: I never yet had a successful build in aarch64.
thanks a lot, will try to find causes of errors...
MatN
On Sat, 27 Nov 2021 02:58:09 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
On Saturday, November 27, 2021, Phyllis Smith via Cin < [email protected]> wrote:
This initial patch worked with no errors on Fedora 32. Will be trying older versions today yet. I did NOT apply 0002-Test-try-to-fix-autoreconf-in-libav1394.patch because this one worked. What now?
wait for Andrea's test after repatching... (a bit afraid about breaking build just before release - we can put this and future related patches after monthly release is out..)
On Fri, Nov 26, 2021 at 12:25 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Sorry, I missed those modifications and only noticed at full rebuild.
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Saturday, November 27, 2021, mnieuw--- via Cin < [email protected]> wrote:
I have tested with patch 001.
On Fedora_35, native X86_64, build of static and appimage are fine. They load too.
On Debian_11. Qemu/aarch64, build fails early on. Log and bld.sh I used attached. For the record: I never yet had a successful build in aarch64.
try to pass '--disable-dav1d' on aarch64 and see if process progressed into compilation stage? you also can run 'make' in thirdparty, it will advance in single-thread mode so it will be easier to see failures..
MatN
On Sat, 27 Nov 2021 02:58:09 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
On Saturday, November 27, 2021, Phyllis Smith via Cin < [email protected]> wrote:
This initial patch worked with no errors on Fedora 32. Will be trying older versions today yet. I did NOT apply 0002-Test-try-to-fix-autoreconf-in-libav1394.patch because this one worked. What now?
wait for Andrea's test after repatching... (a bit afraid about breaking build just before release - we can put this and future related patches after monthly release is out..)
On Fri, Nov 26, 2021 at 12:25 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Sorry, I missed those modifications and only noticed at full rebuild.
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
With patch 0001, builds fine here on Mint 19.2. MatN On Sat, 27 Nov 2021 02:58:09 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
On Saturday, November 27, 2021, Phyllis Smith via Cin < [email protected]> wrote:
This initial patch worked with no errors on Fedora 32. Will be trying older versions today yet. I did NOT apply 0002-Test-try-to-fix-autoreconf-in-libav1394.patch because this one worked. What now?
wait for Andrea's test after repatching... (a bit afraid about breaking build just before release - we can put this and future related patches after monthly release is out..)
On Fri, Nov 26, 2021 at 12:25 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Sorry, I missed those modifications and only noticed at full rebuild.
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I have just published the Hungarian version of the Cinelerra Wikipdia pages. https://hu.wikipedia.org/wiki/Cinelerra Translated from a combination of the EN/DE/NL CinGG Wikipedia pages using DeepL, verified by the same person who did the Hungarian Cinelerra-GG review on Youtube . He found surprisingly few language errors, DeepL is really good. The article could do with a few more references, but I am not sure how useful those references (which would be in English) are for most Hungarians. MatN
Oh, how exciting! I was hoping it would make it before the end of the month so it could be announced then. On Sat, Nov 27, 2021 at 2:42 PM mnieuw--- via Cin < [email protected]> wrote:
I have just published the Hungarian version of the Cinelerra Wikipdia pages. https://hu.wikipedia.org/wiki/Cinelerra
Translated from a combination of the EN/DE/NL CinGG Wikipedia pages using DeepL, verified by the same person who did the Hungarian Cinelerra-GG review on Youtube .
He found surprisingly few language errors, DeepL is really good.
The article could do with a few more references, but I am not sure how useful those references (which would be in English) are for most Hungarians.
MatN -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew,
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro?
OSS is a choice in Settings->Preferences, Playback A/B for an Audio driver. Therefore, I do not want to disable this for everyone, as is done in the lines for the thirdparty/Makefile:
-a52dec.cfg_params?=--enable-djbfft +a52dec.cfg_params?=--enable-djbfft --disable-oss but the "thirdparty/src/libavc1394-0.5.4.patch1" is good.
On Sunday, December 12, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrew,
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro?
OSS is a choice in Settings->Preferences, Playback A/B for an Audio driver. Therefore, I do not want to disable this for everyone, as is done in the lines for the thirdparty/Makefile:
well, this disables oss output (?) for library (or even some test program shipped with it), so _i think_ main Cinelerra oss output should remain unaffected? But I have little idea how to test this - by using aoss (from alsa utils)? direct oss kernel sound system was removed in kernels after 2.6.38 (from memory). BSD uses some version of oss....
-a52dec.cfg_params?=--enable-djbfft +a52dec.cfg_params?=--enable-djbfft --disable-oss
but the "thirdparty/src/libavc1394-0.5.4.patch1" is good.
Checked into GIT, MatN's patch for aarch64 in guicast/Makefile Checked into GIT, Andrew's patches in thirdparty/src of tiff-4.1.0.patch1 and libavc1394-0.5.4.patch1 On Fri, Nov 26, 2021 at 12:25 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Sorry, I missed those modifications and only noticed at full rebuild.
disabling oss in liba52 should have no impact, hopefully, but full reconfiguring for libavc1394 might blow up (
Phyllis, Andrea - can you test this on regular x86, including older/random distro? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
mnieuw＠zap.a2000.nl -
Phyllis Smith