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 <
cin@lists.cinelerra-gg.org> wrote:
> Sorry, I missed those
On Sunday, December 12, 2021, Phyllis Smith via Cin <
cin@lists.cinelerra-gg.org> 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
>>
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.
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,
> 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
With patch 0001, builds fine here on Mint 19.2.
MatN
On Sat, 27 Nov 2021 02:58:09 +0300
Andrew Randrianasulu via Cin wrote:
> On Saturday, November 27, 2021, Phyllis Smith via Cin <
> cin@lists.cinelerra-gg.org> wrote:
>
> > This initial patch worked with no errors on Fedora 32. Will be
> >
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
On Saturday, November 27, 2021, Andrea paz
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
On Saturday, November 27, 2021, mnieuw--- via Cin <
cin@lists.cinelerra-gg.org> 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.
On Saturday, November 27, 2021, mnieuw--- via Cin <
cin@lists.cinelerra-gg.org> 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.
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
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
On Saturday, November 27, 2021, Phyllis Smith via Cin <
cin@lists.cinelerra-gg.org> 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
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 <
cin@lists.cinelerra-gg.org>
On Friday, November 26, 2021, Andrea paz
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
> 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)
--
Cin mailing list
Cin@lists.cinelerra-gg.org
On Friday, November 26, 2021, Andrea paz
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
>
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
wrote:
> I can't compile in either arch 64-bit or Debian 11 32-bit (VM). I
> attach the two logs.
>
From
On Friday, November 26, 2021, mnieuw--- via Cin
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
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
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?
From
21 matches
Mail list logo