Bug 2472

Here is a new version based on to the the new upstream 0.11.99
release:
Spec: http://jwrdegoede.danny.cz/gstreamer1-libav.spec
SRPM: http://jwrdegoede.danny.cz/gstreamer1-libav-0.11.99-1.fc19.src.rpm

*** Bug 2494 has been marked as a duplicate of this bug. ***

Assigning the review to myself.

*** Bug 2499 has been marked as a duplicate of this bug. ***

Spec: http://people.collabora.co.uk/~robswain/fedora/gstreamer1-libav.spec
SRPM: http://people.collabora.co.uk/~robswain/fedora/gstreamer1-libav-1.0.0-1.fc18.src.rpm

I've updated to the 1.0.0 release that was recently made. libav-0.8.3 is included and so a separate tarball is not needed there. All the patches have been integrated upstream pre-1.0 I believe so they have been removed. I also changed all the names from FFmpeg to libav as the module is now called gst-libav.

Here is the review:

 +:ok, =:needs attention, -:needs fixing

MUST Items:
[+] MUST: rpmlint must be run on every package.
[+] MUST: The package must be named according to the Package Naming Guidelines.
It matches Fedora name not the upstream tarball.
[+] MUST: The spec file name must match the base package %{name}
[+] MUST: The package must meet the Packaging Guidelines.
[+] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines.
[+] MUST: The License field in the package spec file must match the actual license.
[-] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
COPYING.LIB is not included in %doc
[+] MUST: The spec file must be written in American English.
[+] MUST: The spec file for the package MUST be legible.
[+] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL.
upstream gst-libav-0.11.99.tar.xz
8e6eef583ca22c2e1021a76c80ea3fb7  gst-libav-0.11.99.tar.xz
source gst-libav-0.11.99.tar.xz 
8e6eef583ca22c2e1021a76c80ea3fb7  gst-libav-0.11.99.tar.xz
[+] MUST: The package must successfully compile and build into binary rpms on at least one supported architecture.
Built on Fedora-18/x86_64
[+] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch.
[+] MUST: All build dependencies must be listed in BuildRequires
[+] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro.
[] MUST: Every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
[+] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review
[+] MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.
[+] MUST: A package must not contain any duplicate files in the %files listing.
[+] MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines.
[+] MUST: The package must contain code, or permissible content. This is described in detail in the code vs. content section of Packaging Guidelines.
Fine. It's for RPM Fusion.
[+] MUST: Large documentation files should go in a doc subpackage.
[+] MUST: If a package includes something as %doc, it must not affect the runtime of the application.
[+] MUST: Header files must be in a -devel package.
[+] MUST: Static libraries must be in a -static package.
[+] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).
[+] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
[+] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 
[+] MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec.
[+] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section.
[+] MUST: Packages must not own files or directories already owned by other packages.
[+] MUST: All filenames in rpm packages must be valid UTF-8.

SHOULD Items:
[+] SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
[+] SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
[+] SHOULD: The reviewer should test that the package builds in mock.
Tested with Fedora-18/x86_64
[+] SHOULD: The package should compile and build into binary rpms on all supported architectures.
[+] SHOULD: The reviewer should test that the package functions as described.
I don't have access to a Fedora 18 therefore I cannot test it
[+] SHOULD: If scriptlets are used, those scriptlets must be sane.
[+] SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
[+] SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
[+] SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
[+] SHOULD: Packages should try to preserve timestamps of original installed files.

Issues: 
1. COPYING.LIB is not included in %doc

2. Compile output is not verbose. I cannot check the CFLAGS used.

The description in the RPM should probably be updated, this plugin depends on libav and not ffmpeg so saying it provided provides FFmpeg-based plugins is not correct. So just like we don't refer to Inkscape as Sodipodi we shouldn't refer to libav as ffmpeg.

(In reply to comment #7)
> The description in the RPM should probably be updated, this plugin depends on
> libav and not ffmpeg so saying it provided provides FFmpeg-based plugins is not
> correct. So just like we don't refer to Inkscape as Sodipodi we shouldn't refer
> to libav as ffmpeg.

I did in mine. :)

(In reply to comment #5)
> Spec: http://people.collabora.co.uk/~robswain/fedora/gstreamer1-libav.spec
> SRPM:
> http://people.collabora.co.uk/~robswain/fedora/gstreamer1-libav-1.0.0-1.fc18.src.rpm
> 
> I've updated to the 1.0.0 release that was recently made. libav-0.8.3 is
> included and so a separate tarball is not needed there. All the patches have
> been integrated upstream pre-1.0 I believe so they have been removed. I also
> changed all the names from FFmpeg to libav as the module is now called
> gst-libav.

Added COPYING.LIB to %doc. Run ldconfig in %post(un). Run make with V=1 to provide verbose compile command output including CFLAGS. Updated to new upstream release 1.0.2:

Spec: http://people.collabora.co.uk/~robswain/fedora/gstreamer1-libav.spec
SRPM: http://people.collabora.co.uk/~robswain/fedora/gstreamer1-libav-1.0.2-1.fc18.src.rpm

(In reply to comment #6)
> Here is the review:
> 

Thanks for the review!

> 
> Issues: 
> 1. COPYING.LIB is not included in %doc
> 
> 2. Compile output is not verbose. I cannot check the CFLAGS used.

Both are fixed in my next version.

(In reply to comment #7)
> The description in the RPM should probably be updated, this plugin depends on
> libav and not ffmpeg so saying it provided provides FFmpeg-based plugins is not
> correct. So just like we don't refer to Inkscape as Sodipodi we shouldn't refer
> to libav as ffmpeg.

Fixed in my next version as well.

(In reply to comment #9)

> Added COPYING.LIB to %doc. Run ldconfig in %post(un). Run make with V=1 to
> provide verbose compile command output including CFLAGS. Updated to new
> upstream release 1.0.2:

Running ldconfig is wrong / not needed as these are plugins not libraries. Other then that
out specfiles are pretty much in sync :)

Here is my latest version:
http://jwrdegoede.danny.cz/gstreamer1-libav.spec
http://jwrdegoede.danny.cz/gstreamer1-libav-1.0.2-1.fc19.src.rpm

And here is the changelog:
* Sun Oct 28 2012 Hans de Goede <j.w.r.degoede@gmail.com> - 1.0.2-1
- Rebase to 1.0.2
- Included libav copy updated to 0.8.4
- Change the license to LGPLv2+, as the GPL only postproc plugin is no longer
  included
- Replace references to ffmpeg with libav (rf#2472)
- Add COPYING.LIB to %%doc (rf#2472)
- Run make with V=1 (rf#2472)

Andrea, can you perhaps also review the gstreamer1-plugins-bad-freeworld package ? See bug 2473, I'll happily swap another review for it.

Hans, these are the CFLAGS actually used:

-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic   -std=c99 -fomit-frame-pointer -fPIC -pthread -g -Wdeclaration-after-statement -Wall -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wstrict-prototypes -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=declaration-after-statement 

As you can see the first part is composed by the standard Fedora optflags. In the second part there are other flags. One in particular caught my attention: the "-O3" that overrides the "-O2". This is not permitted by Fedora Guidelines. 

(In reply to comment #11)
> Andrea, can you perhaps also review the gstreamer1-plugins-bad-freeworld
> package ? See bug 2473, I'll happily swap another review for it.

I can but later this week. Is it OK for you? If so, you can take #1798. Thanks!

Hi,

(In reply to comment #12)
> Hans, these are the CFLAGS actually used:
> 
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4  -m64 -mtune=generic   -std=c99 -fomit-frame-pointer
> -fPIC -pthread -g -Wdeclaration-after-statement -Wall -Wno-parentheses
> -Wno-switch -Wno-format-zero-length -Wdisabled-optimization -Wpointer-arith
> -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits
> -Wundef -Wmissing-prototypes -Wstrict-prototypes -O3 -fno-math-errno
> -fno-signed-zeros -fno-tree-vectorize -Werror=implicit-function-declaration
> -Werror=missing-prototypes -Werror=declaration-after-statement 
> 
> As you can see the first part is composed by the standard Fedora optflags. In
> the second part there are other flags. One in particular caught my attention:
> the "-O3" that overrides the "-O2". This is not permitted by Fedora Guidelines. 
> 

This is only the case for the included / bundled libav copy, not for the actual
gstreamer code. And I just double checked and rpmfusion's own ffmpeg packages
are build the same way. I guess this is a case of upstream knows best, as this
is quite performance sensitive code and upstream seems to go through
a great deal of trouble to get certain cflags passed and explictly disables
some problematic optimizations.

If you really believe this is an issue.  I belief the proper way forward with this
is to file a bug against the ffmpeg package, and if / when that gets fixed
I'll duplicate the fix in the gstreamer-ffmpeg and gstreamer1-libav packages,
in the mean time I would like to move forward with this review though.


> (In reply to comment #11)
> > Andrea, can you perhaps also review the gstreamer1-plugins-bad-freeworld
> > package ? See bug 2473, I'll happily swap another review for it.
> 
> I can but later this week. Is it OK for you? If so, you can take #1798. Thanks!

Yes that works for me. I'll go work on bug 1798 right away.

(In reply to comment #13)
> > As you can see the first part is composed by the standard Fedora optflags. In
> > the second part there are other flags. One in particular caught my attention:
> > the "-O3" that overrides the "-O2". This is not permitted by Fedora Guidelines. 
> > 
> 
> This is only the case for the included / bundled libav copy, not for the actual
> gstreamer code. And I just double checked and rpmfusion's own ffmpeg packages
> are build the same way. I guess this is a case of upstream knows best, as this
> is quite performance sensitive code and upstream seems to go through
> a great deal of trouble to get certain cflags passed and explictly disables
> some problematic optimizations.
> 
> If you really believe this is an issue.  I belief the proper way forward with
> this
> is to file a bug against the ffmpeg package, and if / when that gets fixed
> I'll duplicate the fix in the gstreamer-ffmpeg and gstreamer1-libav packages,
> in the mean time I would like to move forward with this review though.

I just opened bug #2560. Please add to the specfile that you are using the same flags used by the ffmpeg package as required by the Fedora Packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Compiler_flags

When ffmpeg maintainer will fix this issue, you need to act accordingly.

APPROVED!

Package CVS request
======================
Package Name: gstreamer1-libav
Short Description: GStreamer 1.0 libav based plug-ins
Owners: jwrdegoede
Branches: F-18
InitialCC:
----------------------
License tag: free

Not meaning to throw a wrench in the works or anything, but isn't it against policy to bundle the libav libraries in this package?

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

If I'm missing something, please feel free to ignore this.

(In reply to comment #16)
> Not meaning to throw a wrench in the works or anything, but isn't it against
> policy to bundle the libav libraries in this package?

Yes, but we're making a temporary exception for gstreamer-ffmpeg and gsrteamer1-libav,
because upstream is using libav not ffmpeg (which we ship), and they are sticking with
stable releases and for libav the libav-0.8.x releases are the latest stable, and they have
a significantly different API from ffmpeg-0.11 / 1.0 which we are shipping. Upstream
has already indicated they will fix gstreamer1-libav to work with the next stable libav
(which syncs it API more or less with the latest ffmpeg), when the libav people do
their first stable release in their next stable series. At this point we will switch back
to using system libs.

Thanks much for the explanation.

*** Bug 2566 has been marked as a duplicate of this bug. ***

Imported and build, thanks to all involved for the help !!