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@xxxxxxxxxxx> 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review