[Bug 518546] Review Request: libva - VAAPI video playback acceleration

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=518546

--- Comment #55 from Jason Tibbitts <tibbs at math.uh.edu> 2010-11-23 18:31:14 EST ---
OK, let's take a look.  Seems to build OK; rpmlint says:

  libva.x86_64: W: no-manual-page-for-binary vainfo
It's nice to have manpages for binaries, but not essential.

  libva-devel.x86_64: E: useless-provides libva-devel
Packages automatically provide themselves; there is no point in doing it
manually.

  libva-devel.x86_64: W: no-documentation
Not a big deal.

  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-tpi-0.31.1.1.so.1.0.3 /lib64/libdl.so.2
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-compat.so.0.0.0 /usr/lib64/libva-x11-0.31.1.1.so.1
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-compat.so.0.0.0 /usr/lib64/libva-0.31.1.1.so.1
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-compat.so.0.0.0 /usr/lib64/libX11.so.6
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-compat.so.0.0.0 /usr/lib64/libXext.so.6
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-compat.so.0.0.0 /usr/lib64/libdrm.so.2
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-compat.so.0.0.0 /usr/lib64/libXfixes.so.3
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-glx-0.31.1.1.so.1.0.3 /usr/lib64/libXext.so.6
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-glx-0.31.1.1.so.1.0.3 /usr/lib64/libdrm.so.2
  libva.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/libva-glx-0.31.1.1.so.1.0.3 /usr/lib64/libXfixes.so.3
Those libraries are all linked against things they don't actually call.  This
isn't generally a big problem unless it causes additional dependencies or
forces libraries to be pulled into memory that otherwise wouldn't be there.  It
can usually be fixed by passing --as-needed into the linker.

I would anticipate this library being multilib, but it seems to me that the
vainfo executable will cause a conflict.  Am I wrong?  Seems better living in a
libva-utils package, honestly, but perhaps I've failed to properly understand
multilib.

It would be nice to have more explicit instructions for modifying the tarball. 
Otherwise the next person who has to do it risks letting the prohibited bits
back in.  I did a diff and of course it's huge due to different autotools
versions; I can't really figure out what changed.  There are even several files
in the new tarball that weren't in the old one.  It might be simpler just to
run the autotools as part of the build process.

I don't know if you intend to target RHEL4 or 5 with this, but if not you can
drop BuildRoot, %clean and the first line of %install.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.