Bug 1697

I'm working on getting a good build for F15/rawhide. I've made quite a bit of progress but not quite there.

One thing the developer mentioned over at the avidemux forums was that the version of x264 was to old. 

The current version seems to be a git snapshot from July 2010. Is there a newer snapshot that's known to be good?

New build for F15/devel was successful.

http://buildsys.rpmfusion.org/build-status/job.psp?uid=9332

I downloaded all the files from here:

http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/avidemux/2.5.4-4.fc15/i686/

And tried to install them.

However I got an error about failed dependencies. The main problem seems to be that avidemux-libs can't find libADM5postproc.so and libADM5postproc.so.51 which then causes the rest of the chain to break.

I think the main avidemux rpm was supposed to have those libs, but that rpm is apparently empty:

[maxx@siamese Download]$ rpm -qpl avidemux-2.5.4-4.fc15.i686.rpm 
(contains no files)

maxx@siamese Download]$ sudo rpm -Uvh avidemux-*
error: Failed dependencies:
	libADM5avcodec.so.52 is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5avcodec.so.52(LIBAVCODEC_52) is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5avcore.so.0 is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5avformat.so.52 is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5avformat.so.52(LIBAVFORMAT_52) is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5avutil.so.50 is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5avutil.so.50(LIBAVUTIL_50) is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5postproc.so.51 is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5postproc.so.51(LIBPOSTPROC_51) is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5swscale.so.0 is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5swscale.so.0(LIBSWSCALE_0) is needed by avidemux-cli-2.5.4-4.fc15.i686
	libADM5avcodec.so.52 is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5avcodec.so.52(LIBAVCODEC_52) is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5avcore.so.0 is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5avformat.so.52 is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5avformat.so.52(LIBAVFORMAT_52) is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5avutil.so.50 is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5avutil.so.50(LIBAVUTIL_50) is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5postproc.so.51 is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5postproc.so.51(LIBPOSTPROC_51) is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5swscale.so.0 is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5swscale.so.0(LIBSWSCALE_0) is needed by avidemux-gtk-2.5.4-4.fc15.i686
	libADM5postproc.so.51 is needed by avidemux-libs-2.5.4-4.fc15.i686
	libADM5postproc.so.51(LIBPOSTPROC_51) is needed by avidemux-libs-2.5.4-4.fc15.i686
	libADM5swscale.so.0 is needed by avidemux-libs-2.5.4-4.fc15.i686
	libADM5swscale.so.0(LIBSWSCALE_0) is needed by avidemux-libs-2.5.4-4.fc15.i686
	libADM5avcodec.so.52 is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5avcodec.so.52(LIBAVCODEC_52) is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5avutil.so.50 is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5avutil.so.50(LIBAVUTIL_50) is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5postproc.so.51 is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5postproc.so.51(LIBPOSTPROC_51) is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5swscale.so.0 is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5swscale.so.0(LIBSWSCALE_0) is needed by avidemux-plugins-2.5.4-4.fc15.i686
	libADM5avcodec.so.52 is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5avcodec.so.52(LIBAVCODEC_52) is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5avcore.so.0 is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5avformat.so.52 is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5avformat.so.52(LIBAVFORMAT_52) is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5avutil.so.50 is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5avutil.so.50(LIBAVUTIL_50) is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5postproc.so.51 is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5postproc.so.51(LIBPOSTPROC_51) is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5swscale.so.0 is needed by avidemux-qt-2.5.4-4.fc15.i686
	libADM5swscale.so.0(LIBSWSCALE_0) is needed by avidemux-qt-2.5.4-4.fc15.i686

(In reply to comment #3)
> I downloaded all the files from here:
> 
> http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/avidemux/2.5.4-4.fc15/i686/
> 
> And tried to install them.
> 
> However I got an error about failed dependencies. The main problem seems to be
> that avidemux-libs can't find libADM5postproc.so and libADM5postproc.so.51
> which then causes the rest of the chain to break.
> 
> I think the main avidemux rpm was supposed to have those libs, but that rpm is
> apparently empty:

No, the main package is basically a meta-package since there are two interfaces, avidemux-qt4 and avidemux-gtk. It's supposed to be empty. 

  The missing files are actually in avidemux-libs, I'm not sure why it's not finding them. 

I saw this behavior under a mock chroot environment and assumed that it was because I was using mock to fake an F15 environment. Apparently it was telling me the truth.

I just checked and the F13 packages I built install fine in a Fedora 13 mock environment so this appears to be just affecting F15.

I have no explanation for this so I'll ask the devel mailing list for help.

Your shared libraries are not installed with execute (+x) permissions, and therefore the auto-provides extractor (at least the one on F15) fails to work on them.

If this permissions issue is also present in the F13/F14, this is a severe packaging bug also there (even if auto-provides work there), because this also breaks -debuginfo extraction, with 2 results:
1. the library will include debugging information in the main package, a big source of bloat,
2. the source files referenced by the debugging information will not be collected into the -debuginfo package.

As a quick hack, you can:
chmod +x %{_libdir}/*.so.*
at the end of %install, but this is something that should be fixed in the build system of the bundled FFmpeg. (See why bundled libraries suck? I think using the system FFmpeg should be a top priority, it'd also prevent this problem.)

Created attachment 617 [details]
avidemux_2.5.4-ffmpeg-permissions.patch

This patch will fix the problem at build system level (basically, you need to use install(PROGRAMS …) instead of install(FILES …) to install stuff with execute permissions).

Upstream probably uses Debian, which installs shared libraries without execute permissions (in fact, Debian requires that for their packages), but in Fedora, shared libraries MUST be installed WITH execute permissions or RPM will not handle them properly.

Created attachment 618 [details]
avidemux_2.5.4-ffmpeg-permissions.patch (upstreamable version)

This version of the patch takes CMake's CMAKE_INSTALL_SO_NO_EXE into account, which CMake has for the explicit purpose of handling this policy difference between Debian and everyone else. With this version of the patch, the shared libraries will be installed without execute permissions on Debian and with execute permissions on most other systems including Fedora.

(In reply to comment #5)
> If this permissions issue is also present in the F13/F14, this is a severe
> packaging bug also there (even if auto-provides work there), because this also
> breaks -debuginfo extraction, with 2 results:
> 1. the library will include debugging information in the main package, a big
> source of bloat,
> 2. the source files referenced by the debugging information will not be
> collected into the -debuginfo package.

These packages work fine in F13/F14 and have been for quite some time as I've been using avidemux for far longer than I've been the maintainer.

(In reply to comment #7)
> Created an attachment (id=618) [details]
> avidemux_2.5.4-ffmpeg-permissions.patch (upstreamable version)
> 
> This version of the patch takes CMake's CMAKE_INSTALL_SO_NO_EXE into account,
> which CMake has for the explicit purpose of handling this policy difference
> between Debian and everyone else. With this version of the patch, the shared
> libraries will be installed without execute permissions on Debian and with
> execute permissions on most other systems including Fedora.

I'll try this one out after the first round is done. I already implemented your first patch for testing under mock. It took a minute because I can apply the patch as is due to admFFmpegBuild.cmake already being modified by the AAC patch. 

There may be an easier way but I just used sed to replace all instances of install(FILES with INSTALL(programs and re-diffed it. 

> These packages work fine in F13/F14 and have been for quite some time

They "work" fine, but they're bloated by debuginfo inside the main package instead of separate debuginfo in -debuginfo, and the -debuginfo package lacks the source files needed to properly debug things.

> It took a minute because I can apply the patch as is due to
> admFFmpegBuild.cmake already being modified by the AAC patch.

You should be able to apply it as is. The AAC patch touches the other end of the admFFmpegBuild.cmake file, the patches should not conflict.

(Patches will only conflict if the context included in the patch is changed by the other patch. If the changed lines are more than 2 lines apart, it's safe to just apply both patches without rediffing.)

(In reply to comment #10)
> > These packages work fine in F13/F14 and have been for quite some time
> 
> They "work" fine, but they're bloated by debuginfo inside the main package
> instead of separate debuginfo in -debuginfo, and the -debuginfo package lacks
> the source files needed to properly debug things.

I didn't mean to indicate that there wasn't anything wrong, only to confirm the packaging bug.
 
> > It took a minute because I can apply the patch as is due to
> > admFFmpegBuild.cmake already being modified by the AAC patch.
> 
> You should be able to apply it as is. The AAC patch touches the other end of
> the admFFmpegBuild.cmake file, the patches should not conflict.

I'm not sure what happened. The first one didn't apply by rpmbuild but the second one did... 

(In reply to comment #3)
> I downloaded all the files from here:
> 
> http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/avidemux/2.5.4-4.fc15/i686/
> 
> And tried to install them.
> 
> However I got an error about failed dependencies. The main problem seems to be
> that avidemux-libs can't find libADM5postproc.so and libADM5postproc.so.51
> which then causes the rest of the chain to break.

The new builds are now available in buildsys. Please test them. I have verified that they do install in a F15 chroot environment.

* You forgot to commit the updated AAC patch. AAC is not going to work in the version you committed.
* You misspelled my name in the changelog.

* Your avidemux-2.5.4-x264_fix.patch contains the code part of the UI changes (the lines added to x264ConfigDialog.cpp), but not the UI part. I also think your change to x264Param.xsd is incorrect. (It's going to give value 0 to none, value 1 to blind, value 2 to simple and value 3 to smart, but the combobox expects value 0 to be none, value 1 to be blind or simple and value 2 to be smart.)

(In reply to comment #14)
> * You forgot to commit the updated AAC patch. AAC is not going to work in the
> version you committed.

Fixed

> * You misspelled my name in the changelog.
 
Dang dyslexic fingers. Fixed.

(In reply to comment #15)
> * Your avidemux-2.5.4-x264_fix.patch contains the code part of the UI changes
> (the lines added to x264ConfigDialog.cpp), but not the UI part. I also think
> your change to x264Param.xsd is incorrect. (It's going to give value 0 to none,
> value 1 to blind, value 2 to simple and value 3 to smart, but the combobox
> expects value 0 to be none, value 1 to be blind or simple and value 2 to be
> smart.)

Do you have any suggested code changes? Or should I just report it upstream as that's where the patch came from. 

I'm not sure about that xsdParam.xsd change.

But the original patch included this hunk:
--- avidemux_2.5.4.orig/plugins/ADM_videoEncoder/ADM_vidEnc_x264/qt4/x264ConfigDialog.ui	2011-03-12 12:04:53.100131791 +0200
+++ avidemux_2.5.4.orig/plugins/ADM_videoEncoder/ADM_vidEnc_x264/qt4/x264ConfigDialog.ui	2011-03-12 12:02:58.063666919 +0200
@@ -1131,12 +1131,12 @@ 
                 </item>
                 <item>
                  <property name="text">
-                  <string>Blind Offset</string>
+                  <string>Weighted References</string>
                  </property>
                 </item>
                 <item>
                  <property name="text">
-                  <string>Smart Analysis</string>
+                  <string>Weighted References + Duplicates</string>
                  </property>
                 </item>
                </widget>
which is missing from the patch you committed. If you don't want the UI changes, you should also drop the x264ConfigDialog.cpp hunk. Because now, in the patch you committed, all that it does is to rewrite the exact same entries which are already in the .ui file.

Actually, I think x264Param.xsd is probably right.

(In reply to comment #18)
> I'm not sure about that xsdParam.xsd change.
> 
> But the original patch included this hunk:
> ---
> avidemux_2.5.4.orig/plugins/ADM_videoEncoder/ADM_vidEnc_x264/qt4/x264ConfigDialog.ui
>        2011-03-12 12:04:53.100131791 +0200
> +++
> avidemux_2.5.4.orig/plugins/ADM_videoEncoder/ADM_vidEnc_x264/qt4/x264ConfigDialog.ui
>        2011-03-12 12:02:58.063666919 +0200
> @@ -1131,12 +1131,12 @@ 
>                  </item>
>                  <item>
>                   <property name="text">
> -                  <string>Blind Offset</string>
> +                  <string>Weighted References</string>
>                   </property>
>                  </item>
>                  <item>
>                   <property name="text">
> -                  <string>Smart Analysis</string>
> +                  <string>Weighted References + Duplicates</string>
>                   </property>
>                  </item>
>                 </widget>
> which is missing from the patch you committed. If you don't want the UI
> changes, you should also drop the x264ConfigDialog.cpp hunk. Because now, in
> the patch you committed, all that it does is to rewrite the exact same entries
> which are already in the .ui file.

I need to check again but I originally removed that hunk because it failed to apply and when I looked at it, it seemed to be already applied.

Now I look at the raw source and it looks like it does need to be applied...

I'm starting to wonder what I signed up for?!? :)

Ok, should be really fixed this time.

I tried out the 2.5.4-6.fc15 builds and they do install and so far they also work just fine.

Thanks for a great job!

Since there have been no other reports of problems I'm going to call this one fixed.