Tim, All,
To track the recent handful of ftbfs for k3b, k9copy, kdmtheme, krusader due to scope/declaration issues that have surfaced, I have opened:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1119
That will provide a common point to work from.
On 07/20/2012 04:16 PM, David C. Rankin wrote:
Tim, All,
To track the recent handful of ftbfs for k3b, k9copy, kdmtheme, krusader due to scope/declaration issues that have surfaced, I have opened:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1119
That will provide a common point to work from.
The failure in k9copy and likely k3b is due to ffmpeg 0.11-1. Since the updates to ffmpeg contain potential security related fixes, I elevated the bug to a blocker for R14. See: http://ffmpeg.org/
I'm trying to figure out what needs to be fixed in k9copy. Any help appreciated.
On 07/23/2012 03:24 PM, David C. Rankin wrote:
On 07/20/2012 04:16 PM, David C. Rankin wrote:
Tim, All,
To track the recent handful of ftbfs for k3b, k9copy, kdmtheme, krusader due to scope/declaration issues that have surfaced, I have opened:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1119
That will provide a common point to work from.
The failure in k9copy and likely k3b is due to ffmpeg 0.11-1. Since the updates to ffmpeg contain potential security related fixes, I elevated the bug to a blocker for R14. See: http://ffmpeg.org/
I'm trying to figure out what needs to be fixed in k9copy. Any help appreciated.
cpp help needed:
Looking at the k9copy ftbfs, the problem seems to be that the AVFormatParameters struct has been dropped from /usr/include/libavformat/avformat.h. The error:
In file included from k9avidecode.cpp:12:0: k9avidecode.h:35:91: error: 'AVFormatParameters' has not been declared
Both AVFormatContext, and AVInputFormat are defined in /usr/include/libavformat/avformat.h, but AVFormatParameters is nowhere to be found. It used to be there:
http://ffmpeg.org/doxygen/0.6/structAVFormatParameters.html
How do I fix the code? A whole struct disappeared.
Along with the drop of AVFormatParameters it looks like 'av_open_input_file' is deprecated in favor of 'avformat_open_input'. Thankfully there are only 4 instances of this in k9copy (k9author/k9avidecode.h k9author/k9avidecode.cpp).
17:19 archangel:/dat_e/tmp/src/k9copy> grep -r av_open_input_file * k9author/k9avidecode.h:typedef int (*av_open_input_file_t)(AVFormatContext **, const char *,AVInputFormat *,int, AVFormatParameters *); k9author/k9avidecode.h: av_open_input_file_t av_open_input_file; k9author/k9avidecode.cpp: av_open_input_file = (av_open_input_file_t)dlsym(FormatHandle,"av_open_input_file"); k9author/k9avidecode.cpp: if (av_open_input_file(&m_FormatCtx, _fileName.utf8(), NULL, 0, NULL)!=0) {
How do you fix this? What is the lvalue and rvalue that need changing? The reason this is confusing is av_open_input_file seems to be used both as a name_t and by itself:
Experts - what say you? This will take an experienced eye.
On 07/23/2012 05:33 PM, David C. Rankin wrote: <snip>
Along with the drop of AVFormatParameters it looks like 'av_open_input_file' is deprecated in favor of 'avformat_open_input'. Thankfully there are only 4 instances of this in k9copy (k9author/k9avidecode.h k9author/k9avidecode.cpp).
17:19 archangel:/dat_e/tmp/src/k9copy> grep -r av_open_input_file * k9author/k9avidecode.h:typedef int (*av_open_input_file_t)(AVFormatContext **, const char *,AVInputFormat *,int, AVFormatParameters *); k9author/k9avidecode.h: av_open_input_file_t av_open_input_file; k9author/k9avidecode.cpp: av_open_input_file = (av_open_input_file_t)dlsym(FormatHandle,"av_open_input_file"); k9author/k9avidecode.cpp: if (av_open_input_file(&m_FormatCtx, _fileName.utf8(), NULL, 0, NULL)!=0) {
<snip>
Experts - what say you? This will take an experienced eye.
ffmpeg change also affects k3b:
17:47 archangel:/dat_e/tde/main/applications> grep -r av_open_input_file k3b/ k3b/plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp: int err = av_open_input_file( &d->formatContext, m_filename.local8Bit(), 0, 0, 0 );
errors that need fixing:
k3bffmpegwrapper.cpp: In member function 'bool K3bFFMpegFile::open()': k3bffmpegwrapper.cpp:82:84: error: 'av_open_input_file' was not declared in this scope k3bffmpegwrapper.cpp:131:63: error: 'dump_format' was not declared in this scope
(there are numerous other deprecation warnings in k3b...)
I'll work more with k3b in a bit. The k9copy ftbfs is the one I need the most help with right now.
ffmpeg change also affects k3b:
17:47 archangel:/dat_e/tde/main/applications> grep -r av_open_input_file k3b/ k3b/plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp: int err = av_open_input_file( &d->formatContext, m_filename.local8Bit(), 0, 0, 0 );
errors that need fixing:
k3bffmpegwrapper.cpp: In member function 'bool K3bFFMpegFile::open()': k3bffmpegwrapper.cpp:82:84: error: 'av_open_input_file' was not declared in this scope k3bffmpegwrapper.cpp:131:63: error: 'dump_format' was not declared in this scope
Does this help?
http://bugsfiles.kde.org/attachment.cgi?id=61237
Darrell
On 07/23/2012 09:44 PM, Darrell Anderson wrote:
Does this help?
http://bugsfiles.kde.org/attachment.cgi?id=61237
Darrell
Hey,
That looks promising :) Now if I can get past the vtable undefined references -- I'll give it a go :)
On Monday 23 of July 2012 22:24:20 David C. Rankin wrote:
On 07/20/2012 04:16 PM, David C. Rankin wrote:
Tim, All,
To track the recent handful of ftbfs for k3b, k9copy, kdmtheme, krusader due to scope/declaration issues that have surfaced, I have opened:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1119
That will provide a common point to work from.
The failure in k9copy and likely k3b is due to ffmpeg 0.11-1. Since the updates to ffmpeg contain potential security related fixes, I elevated the bug to a blocker for R14. See: http://ffmpeg.org/
I'm trying to figure out what needs to be fixed in k9copy. Any help appreciated.
The ffmpeg patch for k9copy is ready. I just was not sure replacing from cur_st->cur_dts to packet.dts. But as it turned out function readFrame have some other problems - causes the crash. So the function would need to fix, regardless of the ffmpeg patch.
Therefore I propose to push the ffmpeg patch as it is and repair of function readFrame to solve separately. Any objections, suggestions, comments, other better patches? ;)
Slavek --
The ffmpeg patch for k9copy is ready. I just was not sure replacing from cur_st->cur_dts to packet.dts. But as it turned out function readFrame have some other problems - causes the crash. So the function would need to fix, regardless of the ffmpeg patch.
Therefore I propose to push the ffmpeg patch as it is and repair of function readFrame to solve separately. Any objections, suggestions, comments, other better patches? ;)
k9copy no longer is maintained upstream, even for KDE4. Therefore go ahead and push what you have. :-)
Darrell
On 08/13/2012 05:21 PM, Darrell Anderson wrote:
k9copy no longer is maintained upstream, even for KDE4. Therefore go ahead and push what you have. :-)
Agreed.
I also put out a request on the suse-kde3 list to see if anyone had a patch for k9copy there as well. I don't expect a quick response... If k9copy is dead upstream, then we should become upstream for that code for tde. It is a good alternative to the other rippers that is quite handy.
Darrell, are you saying kde4 dropped it completely? Oh well, their loss. With the cups > 1.6 patch and the ffmpeg patch (when pushed), both R14 and 3513-sru should be building on current code again.
Do you have any other upstream pkg issues open at the moment? I'll try a build with the latest code tonight and see what happens.
Darrell, are you saying kde4 dropped it completely? Oh well, their loss. With the cups > 1.6 patch and the ffmpeg patch (when pushed), both R14 and 3513-sru should be building on current code again.
http://k9copy.sourceforge.net/web/index.php/en/news
We're on our own to maintain k9copy. The original intent of k9copy was to shrink/backup DVDs to single layer disks and that still works as intended.
Creating a Video DVD from an AVI or other video file needs attention. In my dream world we would extract devede features and add them to our version of k9copy. Then we would have a full featured DVD authoring tool that is native to TDE. :-)
Do you have any other upstream pkg issues open at the moment? I'll try a build with the latest code tonight and see what happens.
Upstream? I had problems building transcode (for k3b) because of the latest ffmpeg but I found a patch for that.
Otherwise just Trinity issues. I was prevented for a few weeks from building tdebase without HAL until stumbling across the patch discussed recently in this list. I can't build python-tqt because of the recent ABI/API changes. Without python-tqt installed I don't know whether I can build python-trinity. I haven't tried building anything else because of that breakage.
Slackware 14 is in release candidate status. Would be nice publicity for Trinity if I could announce shortly after the official release that I am running Slackware 14 and Trinity R14 Development/Beta. :-)
Darrell
On Tuesday 14 of August 2012 00:21:12 Darrell Anderson wrote:
The ffmpeg patch for k9copy is ready. I just was not sure replacing from cur_st->cur_dts to packet.dts. But as it turned out function readFrame have some other problems - causes the crash. So the function would need to fix, regardless of the ffmpeg patch.
Therefore I propose to push the ffmpeg patch as it is and repair of function readFrame to solve separately. Any objections, suggestions, comments, other better patches? ;)
k9copy no longer is maintained upstream, even for KDE4. Therefore go ahead and push what you have. :-)
Darrell
Pushed - into master and also into v3.5.13-sru.
Slavek --
On 08/13/2012 04:59 PM, Slávek Banko wrote:
The ffmpeg patch for k9copy is ready. I just was not sure replacing from cur_st->cur_dts to packet.dts. But as it turned out function readFrame have some other problems - causes the crash. So the function would need to fix, regardless of the ffmpeg patch.
The newer/older versions of the k9copy patch -- is that for systems with ffmpeg 0.11 (newer) and systems with ffmpeg < 0.11 (older)?
It isn't clear from the bug report what is being considered the "dividing line" between newer/older...
On 08/13/2012 06:14 PM, David C. Rankin wrote:
The newer/older versions of the k9copy patch -- is that for systems with ffmpeg 0.11 (newer) and systems with ffmpeg < 0.11 (older)?
It isn't clear from the bug report what is being considered the "dividing line" between newer/older...
Also, if you have good patches, even if I started the mess, don't worry about waiting for me to push, if it builds/works, it's good, I've been very busy lately and that will continue for the next few weeks. Thanks!
On Tuesday 14 of August 2012 01:14:45 David C. Rankin wrote:
On 08/13/2012 04:59 PM, Slávek Banko wrote:
The ffmpeg patch for k9copy is ready. I just was not sure replacing from cur_st->cur_dts to packet.dts. But as it turned out function readFrame have some other problems - causes the crash. So the function would need to fix, regardless of the ffmpeg patch.
The newer/older versions of the k9copy patch -- is that for systems with ffmpeg 0.11 (newer) and systems with ffmpeg < 0.11 (older)?
It isn't clear from the bug report what is being considered the "dividing line" between newer/older...
The patch contains a lot of conditions, according to many sub-versions - up to the current version 0.11. It is true that in the commit log will be better to mention specific version 0.11, rather than the generic "newer". For example: Fix build failures against ffmpeg up to version 0.11.
Slavek --
On 08/13/2012 06:38 PM, Slávek Banko wrote:
The patch contains a lot of conditions, according to many sub-versions - up to the current version 0.11. It is true that in the commit log will be better to mention specific version 0.11, rather than the generic "newer". For example: Fix build failures against ffmpeg up to version 0.11.
Slavek
Tested + sign-off. It builds fine with ffmpeg 0.11-1:
Targets (1): tde-k9copy-3.5.13_sru-2 Completed build of: applications/k9copy - Aug 13 23:07:42 -- Build took: 5 minutes
Great job!
-
Darrell Anderson -
David C. Rankin -
Slávek Banko