Bug#1051570: [Mlt-devel] Fwd: Bug#1051570: mlt: FTBFS with RtAudio 6
Fixed in git, supports old (4) and new versions. See also https://github.com/mltframework/mlt/issues/930 On Thu, Oct 12, 2023 at 6:34 AM Patrick Matthäi via Mlt-devel < mlt-de...@lists.sourceforge.net> wrote: > Hello, > > I have got this patch for RTAudio 6 "support" (not tested, but it builds > with 7.18.0). This patch also applies to the 7.20.0 version. > The problem is with the patch applied mlt builds against rtaudio 6.0.1, > but it fails against 5.2.0 just with: > > [ 57%] Linking CXX shared module ../../../out/lib/mlt/libmltmovit.so > cd /build/mlt-7.20.0/obj-x86_64-linux-gnu/src/modules/movit && > /usr/bin/cmake -E cmake_link_script CMakeFiles/mltmovit.dir/link.txt > --verbose=1 > /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/build/mlt-7.20.0=. > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 > -Wl,-z,relro -Wl,-z,now -shared -o ../../../out/lib/mlt/libmltmovit.so > CMakeFiles/mltmovit.dir/factory.c.o > CMakeFiles/mltmovit.dir/filter_glsl_manager.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_blur.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_convert.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_crop.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_deconvolution_sharpen.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_diffusion.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_flip.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_glow.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_lift_gamma_gain.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_mirror.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_opacity.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_rect.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_resample.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_resize.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_saturation.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_vignette.cpp.o > CMakeFiles/mltmovit.dir/filter_movit_white_balance.cpp.o > CMakeFiles/mltmovit.dir/mlt_movit_input.cpp.o > CMakeFiles/mltmovit.dir/transition_movit_luma.cpp.o > CMakeFiles/mltmovit.dir/transition_movit_mix.cpp.o > CMakeFiles/mltmovit.dir/transition_movit_overlay.cpp.o > CMakeFiles/mltmovit.dir/consumer_xgl.c.o > -Wl,-rpath,/build/mlt-7.20.0/obj-x86_64-linux-gnu/out/lib: -lm > ../../../out/lib/libmlt++-7.so.7.20.0 /usr/lib/x86_64-linux-gnu/libX11.so > ../../../out/lib/libmlt-7.so.7.20.0 /usr/lib/x86_64-linux-gnu/libGLX.so > /usr/lib/x86_64-linux-gnu/libOpenGL.so > /usr/lib/x86_64-linux-gnu/libmovit.so /usr/lib/x86_64-linux-gnu/libepoxy.so > make[3]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu' > [ 57%] Built target mltmovit > make[2]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu' > make[1]: *** [Makefile:139: all] Error 2 > make[1]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu' > dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j2 "INSTALL=install > --strip-program=true" VERBOSE=1 returned exit code 2 > make: *** [debian/rules:11: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > status 2 > > > A better fix would be welcome :) > > > Weitergeleitete Nachricht > Betreff: Bug#1051570: mlt: FTBFS with RtAudio 6 > Weitersenden-Datum: Sat, 09 Sep 2023 21:15:01 + > Weitersenden-Von: IOhannes m zmoelnig > > Weitersenden-An: debian-bugs-d...@lists.debian.org > Weitersenden-CC: Patrick Matthäi > > Datum: Sat, 09 Sep 2023 23:10:59 +0200 > Von: IOhannes m zmoelnig > Antwort an: IOhannes m zmoelnig > , 1051...@bugs.debian.org > An: Debian Bug Tracking System > > > Source: mlt > Version: 7.18.0-2 > Severity: serious > Tags: ftbfs patch > Justification: fails to build from source (but built successfully in the > past) > > Dear Maintainer, > > mlt ftbfs with RtAudio 6 (currently in experimental). > > ``` > [ 89%] Building CXX object > src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o > cd /build/mlt-zme0kO/mlt-7.18.0/obj-x86_64-linux-gnu/src/modules/rtaudio > && /usr/lib/ccache/c++ -Dmltrtaudio_EXPORTS > -I/build/mlt-zme0kO/mlt-7.18.0/src/framework/.. -isystem > /usr/include/rtaudio -g -O2 > -ffile-prefix-map=/build/mlt-zme0kO/mlt-7.18.0=. -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -fPIC -mmmx -msse -msse2 > -pthread -D__LINUX_ALSA__ -D__LINUX_PULSE__ -D__UNIX_JACK__ -D_REENTRANT > -MD -MT > src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -MF > CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o.d -o > CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -c > /build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp > /build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp: In > member function ‘bool RtAudioConsumer::create_rtaudio(RtAudio::Api, int, > int)’: > /build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:164:26: > error: ‘struct RtAudio::DeviceInfo’ has no member named ‘probed’ > 164 | i
Bug#770035: [Mlt-devel] Bug#770035: kdenlive: Processed videos have image pauses or accelerations while sound goes well
No. I do not know how to reproduce the problem. The bug reporter needs to narrow down the problem. Is it something in the project, something related specifically to those source files, or something related to that combination of MLT and Libav versions? I do consider the usage of the latest versions of Libav and FFmpeg with MLT somewhat experimental. On Wed, Nov 19, 2014 at 6:03 AM, Patrick Matthäi wrote: > Hi Dan, > > do you have an idea to http://bugs.debian.org/770035 ? > > Am 19.11.2014 um 14:54 schrieb Javier Ortega Conde (Malkavian): > >Could you retest it with the libmlt*, mlt*, melt* packages from >> experimental (not jessie/sid)? >> > > Done, and problem persists. > > >
Bug#737428: [Mlt-devel] Bug#737428: [src:mlt] Sourceless flash file
On Wed, Feb 12, 2014 at 2:39 AM, Patrick Matthäi wrote: > could you fix this with the next upstream release by: > > a) Removing the .swf file This is done in git for the next release. -- +-DRD-+ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733375: [Mlt-devel] Bug#733375: mlt: FTBFS: producer_pango.c:28:31: fatal error: freetype/freetype.h: No such file or directory
On Mon, Dec 30, 2013 at 5:53 AM, Patrick Matthäi wrote: > Hi Dan, > > see below. This also should be fixed upstream to work with recent > freetype versions. > Thanks! > > Am 28.12.2013 19:12, schrieb David Suárez: >> Source: mlt >> Version: 0.9.0-2 >> Severity: serious >> Tags: jessie sid >> User: debian...@lists.debian.org >> Usertags: qa-ftbfs-20131226 qa-ftbfs >> Justification: FTBFS on amd64 >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build on >> amd64. >> >> On the new 2.5 version the headers are located at >> '/usr/include/freetype2/ftglyph.h' instead of >> '/usr/include/freetype2/freetype/ftglyph.h' like in previous versions. >> >> Relevant part (hopefully): >>> cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat >>> -Werror=format-security -DARCH_X86_64 -Wall -DPIC -O2 -pipe >>> -fno-tree-dominator-opts -fno-tree-pre -ffast-math -DUSE_MMX -DUSE_SSE >>> -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -pthread >>> -DARCH_X86_64 -Wall -DPIC -O2 -pipe -fno-tree-dominator-opts >>> -fno-tree-pre -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g >>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -pthread -I../.. >>> -DARCH_X86_64 -Wall -DPIC -O2 -pipe -fno-tree-dominator-opts >>> -fno-tree-pre -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g >>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -pthread `pkg-config >>> --cflags gtk+-2.0` `pkg-config --cflags gdk-pixbuf-2.0` `pkg-config >>> --cflags pangoft2` -D_FORTIFY_SOURCE=2 -c -o producer_pango.o >>> producer_pango.c >>> producer_pango.c:28:31: fatal error: freetype/freetype.h: No such file or >>> directory >>> #include >>>^ >>> compilation terminated. >>> make[3]: *** [producer_pango.o] Error 1 >> >> The full build log is available from: >>http://aws-logs.debian.net/ftbfs-logs/2013/12/26/mlt_0.9.0-2_unstable.log Assuming no regressions on our nightly build servers, this is fixed in git commit 4e96e01. -- +-DRD-+ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733375: [Mlt-devel] Bug#733375: mlt: FTBFS: producer_pango.c:28:31: fatal error: freetype/freetype.h: No such file or directory
On Mon, Dec 30, 2013 at 5:53 AM, Patrick Matthäi wrote: > Hi Dan, > > see below. This also should be fixed upstream to work with recent > freetype versions. > Thanks! > > Am 28.12.2013 19:12, schrieb David Suárez: >> Source: mlt >> Version: 0.9.0-2 >> Severity: serious >> Tags: jessie sid >> User: debian...@lists.debian.org >> Usertags: qa-ftbfs-20131226 qa-ftbfs >> Justification: FTBFS on amd64 >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build on >> amd64. >> >> On the new 2.5 version the headers are located at >> '/usr/include/freetype2/ftglyph.h' instead of >> '/usr/include/freetype2/freetype/ftglyph.h' like in previous versions. >> >> Relevant part (hopefully): >>> cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat >>> -Werror=format-security -DARCH_X86_64 -Wall -DPIC -O2 -pipe >>> -fno-tree-dominator-opts -fno-tree-pre -ffast-math -DUSE_MMX -DUSE_SSE >>> -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -pthread >>> -DARCH_X86_64 -Wall -DPIC -O2 -pipe -fno-tree-dominator-opts >>> -fno-tree-pre -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g >>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -pthread -I../.. >>> -DARCH_X86_64 -Wall -DPIC -O2 -pipe -fno-tree-dominator-opts >>> -fno-tree-pre -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g >>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -pthread `pkg-config >>> --cflags gtk+-2.0` `pkg-config --cflags gdk-pixbuf-2.0` `pkg-config >>> --cflags pangoft2` -D_FORTIFY_SOURCE=2 -c -o producer_pango.o >>> producer_pango.c >>> producer_pango.c:28:31: fatal error: freetype/freetype.h: No such file or >>> directory >>> #include >>>^ >>> compilation terminated. >>> make[3]: *** [producer_pango.o] Error 1 >> >> The full build log is available from: >>http://aws-logs.debian.net/ftbfs-logs/2013/12/26/mlt_0.9.0-2_unstable.log >> What a major pain. This alone fails because we are using pkg-config --cflags pangoft2: diff --git a/src/modules/gtk2/producer_pango.c b/src/modules/gtk2/producer_pango.c index 4969dd2..ba902bd 100644 --- a/src/modules/gtk2/producer_pango.c +++ b/src/modules/gtk2/producer_pango.c @@ -25,7 +25,7 @@ #include #include #include -#include +#include #include #include #include Adding pkg-config --cflags freetype2 does not help on any of my other systems because of that old freetype subdirectory. So, I have to resort to this ugly hack because `pkg-config --cflags-only-I freetype2` (assuming it only ever outputs one -I) has a trailing space: diff --git a/src/modules/gtk2/Makefile b/src/modules/gtk2/Makefile index b4fb3ff..4a3f5cb 100644 --- a/src/modules/gtk2/Makefile +++ b/src/modules/gtk2/Makefile @@ -35,6 +35,7 @@ endif ifdef USE_PANGO OBJS += producer_pango.o CFLAGS += `pkg-config $(PKGCONFIG_PREFIX) --cflags pangoft2` +CFLAGS += `pkg-config --cflags-only-I freetype2 | sed 's/ *$$//g')`/freetype LDFLAGS += `pkg-config $(PKGCONFIG_PREFIX) --libs pangoft2` ifeq ($(targetos),Darwin) LDFLAGS += -liconv -- +-DRD-+ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710419: [Mlt-devel] Bug#710419: kdenlive: needs porting to use avconv executable (not ffmpeg)
On Thu, May 30, 2013 at 11:14 AM, Patrick Matthäi wrote: > Am 30.05.2013 22:08, schrieb Dan Dennedy: >>> are you aware of this issue? For myself, this is new! >>> >> >> Kdenlive is already compatible with avconv since version 0.9.4. So, if >> this is an upgrade request, then the justification makes perfect >> sense. MLT does not use libav/ffmpeg executables directly and is >> already compatible with both projects' libs. Or, are you just saying >> you are unaware of the libav fork? > > Ah, nice to know, thanks for the information! > I remember that kdenlive and/or mlt used the ffmpeg binary (in the > past). I currently have not access to my Linux desktops, so I can not > check the current status, so is there anything I have to change at the > most up to date mlt and kdenlive packages to support this transition? Not that I am aware of, but I maybe you want to hear from one of the regular kdenlive devs. Yes, it is still compatible with ffmpeg executable. The Config Wizard looks for various helpers, and it first searches for ffmpeg and if that is not found, searches for avconv. Also, the wizard is re-run upon first launch after an upgrade. Lastly, the paths are configurable in Settings. -- +-DRD-+ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710419: [Mlt-devel] Bug#710419: kdenlive: needs porting to use avconv executable (not ffmpeg)
On Thu, May 30, 2013 at 8:19 AM, Patrick Matthäi wrote: > Am 30.05.2013 18:02, schrieb Jonas Smedegaard: >> Package: kdenlive >> Severity: serious >> Justification: Renders (soon) the package unusable >> >> Kdenlive depends on ffmpeg executable for transcoding source material >> (and possibly other tasks as well). >> >> ffmpeg is targeted for removal, so kdenlive need adaptation to instead >> use avconv executable. >> >> - Jonas >> > > Hola mlt and kdenlive developers, > > are you aware of this issue? For myself, this is new! > Kdenlive is already compatible with avconv since version 0.9.4. So, if this is an upgrade request, then the justification makes perfect sense. MLT does not use libav/ffmpeg executables directly and is already compatible with both projects' libs. Or, are you just saying you are unaware of the libav fork? -- +-DRD-+ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693770: dvgrab: Does no longer work
It already works great with the new subsystem. In fact it was the first application to really work with it. Your source is simply wrong. Also the real porting effort went into libraw1394 2.0 and not the apps. On Wednesday, November 21, 2012, Erik Schanze (Debian) wrote: > Hi Dan, > > [Please keep at least 693770-forwar...@bugs.debian.org in > CC.] > > I'm the Debian Maintainer for dvgrab. > I have received a bugreport for it. > Since ieee1394 driver was removed from Linux 2.6.37 it > is not possible to use dvgrab any more. > > Unfortunately there is no new version since 2010. > > Are there plans to port dvgrab to new FireWire stack? > > Thank you in advance, > > Erik > > > > Am 20.11.2012 07:06, schrieb Matthias Urlichs: > > Package: dvgrab > > Severity: grave > > Justification: renders package unusable > > > > Linux 2.6.37 removed the ieee1394 driver. > > dvgrab does not work with the new firewire subsystem. > > It's therefore 100% useless and should be removed. > > > > -- System Information: > > Debian Release: wheezy/sid > > APT prefers testing > > APT policy: (700, 'testing'), (650, 'unstable'), (600, 'stable'), > (550, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 3.6-trunk-amd64 (SMP w/2 CPU cores) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8) > > Shell: /bin/sh linked to /bin/dash > > > > > > Freundlich grüßend, > > Erik > > -- +-DRD-+
Bug#438336: [Kino-dev] Kino in Debian
On Sun, Jan 10, 2010 at 12:54 PM, Stefan Richter wrote: > David Liontooth wrote: >> Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438336 is >> preventing kino from entering squeeze. I can see from the versions listing on the bug page that the problem is that this version of Debian does not have a recent enough version of libraw1394. You need at least version 2.0.0. >> I noticed Stefan Richter posting here -- is it really the case that kino >> can't use the new firewire stack? > > The newer (now not so "new" anymore) firewire kernel drivers work very > well for applications like Kino and dvgrab now. They actually did for Of course, there will still be situations where some hardware/device combinations work in one subsystem but not another due to subtle interoperability bugs. > quite a while now. But I at least did not push distributors to move to > the new drivers for reasons that were unrelated to Kino et al (IPv4, > DVB, audio support --- all solved in recent kernel releases now). > > We have some information about this topic, targeted towards > distributors/ packagers and advanced users: > http://ieee1394.wiki.kernel.org/index.php/Juju_Migration > > Furthermore, the release notes give a detailed view on which > improvements and fixes came in which release: > http://ieee1394.wiki.kernel.org/index.php/Release_Notes > http://ieee1394.wiki.kernel.org/index.php/Release_Notes_-_Libraries > > For a works-out-of-the-box experience, kernel 2.6.31 (or later) and udev > 144 or later are very much recommended. At these versions, proper > mechanisms and policies for user access to FireWire devices arrived in > mainline udev. (Somewhat late, sorry for that. Other rules which are > not part of mainline udev can achieve the same with older kernels, as > documented in the kernel wiki.) > -- > Stefan Richter > -=-==-=- ---= -=-=- > http://arcgraph.de/sr/ > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Kino-dev mailing list > kino-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kino-dev > -- +-DRD-+ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#289182: [Kino-dev] [schmitz@zirkon.biophys.uni-duesseldorf.de: Bug#289182: kino endianness issues on powerpc]
No movement. What is sickening is that I even have an iMac I could work on this, but I am already way overburdened with other tasks. As I like to remind people, I still have the rest of my life, so I might get around to it ;-) On Thu, 2005-02-17 at 21:14 -0500, Henry A. Leinhos wrote: > Hi, > > Has there been any movement regarding endian issues in Kino? Are there > any patches I can try to clean some up, or perhaps test? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
