Bug 593879
Summary: | Review Request: libvpx - VP8 Video Codec SDK | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tom "spot" Callaway <tcallawa> |
Component: | Package Review | Assignee: | Dennis Gilmore <dennis> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | adam, adel.gadllah, bjohnson, bnocera, cz172638, fedora-package-review, jeff, jsmith.fedora, mcepl, mcepl, notting, otte, pbrobinson, rdieter, tiagomatos, uraeus |
Target Milestone: | --- | Flags: | dennis:
fedora-review+
kevin: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvpx-0.9.0-5.fc12 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-05-24 19:32:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tom "spot" Callaway
2010-05-19 22:36:23 UTC
rpmlint /var/lib/mock/fedora-13-x86_64/result libvpx-utils.x86_64: W: no-documentation libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/vp8_scalable_patterns 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/twopass_vp8_encoder 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/decode_to_md5 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/vp8cx_set_ref 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/force_keyframe 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/example_xma 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/postproc 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/decode_with_drops 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/error_resilient 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/simple_vp8_encoder 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/ivfenc 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/simple_vp8_decoder 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/ivfdec 0775L libvpx-utils.x86_64: E: non-standard-executable-perm /usr/bin/vp8_set_maps 0775L libvpx.src: W: spelling-error %description -l en_US codec -> codex, code, codes libvpx.src:51: W: rpm-buildroot-usage %build DIST_DIR=%{buildroot} ./configure --target=generic-gnu --enable-pic --disable-optimizations --enable-debug libvpx.src:51: W: configure-without-libdir-spec libvpx.src: W: no-cleaning-of-buildroot %install libvpx.src: W: no-buildroot-tag libvpx.src: W: invalid-url Source0: http://webm.googlecode.com/files/libvpx-0.9.0.tar.bz2 HTTP Error 404: Not Found libvpx.x86_64: W: spelling-error %description -l en_US codec -> codex, code, codes 5 packages and 0 specfiles checked; 14 errors, 8 warnings. permissions we should fix i think that rather than doing the rename of the utils to /usr/bin/simple_vp8_decoder /usr/bin/simple_vp8_encoder /usr/bin/twopass_vp8_encoder we should name them /usr/bin/vp8_simple_decoder /usr/bin/vp8_simple_encoder /usr/bin/vp8_twopass_encoder which is consistent with some of the other included utils namely /usr/bin/vp8_scalable_patterns /usr/bin/vp8_set_maps upstream source matches sha256sum fedora/SOURCES/libvpx-0.9.0.tar.bz2 Download/libvpx-0.9.0.tar.bz2 a0096ac6859cfb61cf06dd9bc0a79a3333a4ec389ba311911d84df8ff2a1b9dc fedora/SOURCES/libvpx-0.9.0.tar.bz2 a0096ac6859cfb61cf06dd9bc0a79a3333a4ec389ba311911d84df8ff2a1b9dc Download/libvpx-0.9.0.tar.bz2 builds fine in mock SPEC is clear and legible Permissions fixed. Binaries renamed, as suggested. Also fixed some missing weak symbols in the shared library. New SRPM: http://www.auroralinux.org/people/spot/review/new/libvpx-0.9.0-2.fc13.src.rpm New SPEC: http://www.auroralinux.org/people/spot/review/new/libvpx.spec Does this need to go through legal? Maybe trivial point, but the GStreamer plugins for vp8 is currently looking for the header files in include/vp8. Maybe that is a 'cleaner' way of storing them than just dropping them in include. Sorry, I mean in include/vpx (In reply to comment #4) > Does this need to go through legal? It has been through legal, and there are no blockers at this time. New package: * Header files in include/vpx * pkgconfig file for libvpx * Optimized now (thanks to debian for figuring out how to glue the shared lib together) New SRPM: http://www.auroralinux.org/people/spot/review/new/libvpx-0.9.0-3.fc13.src.rpm New SPEC: http://www.auroralinux.org/people/spot/review/new/libvpx.spec (In reply to comment #8) > New package: > > * Header files in include/vpx > * pkgconfig file for libvpx > * Optimized now (thanks to debian for figuring out how to glue the shared lib > together) > > New SRPM: > http://www.auroralinux.org/people/spot/review/new/libvpx-0.9.0-3.fc13.src.rpm > New SPEC: http://www.auroralinux.org/people/spot/review/new/libvpx.spec # If/when we build an optimized version that uses the asm, we'll need this. # BuildRequires: yasm [...] %changelog * Thu May 20 2010 Tom "spot" Callaway <tcallawa> 0.9.0-3 - add pkg-config file - move headers into include/vpx/ - enable optimization Something does not look right here ;) Yep. That's definitely not right. Fixed in -4: New SRPM: http://www.auroralinux.org/people/spot/review/new/libvpx-0.9.0-4.fc13.src.rpm New SPEC: http://www.auroralinux.org/people/spot/review/new/libvpx.spec johanka:build$ LANG=C rpmbuild --rebuild RHEL6/libvpx-0.9.0-4.fc13.src.rpm Installing RHEL6/libvpx-0.9.0-4.fc13.src.rpm error: Failed build dependencies: php-cli is needed by libvpx-0.9.0-4.el6.x86_64 johanka:build$ Just curious: php-cli for video codec? Is it right? No, its not sane, but yes, it is correct. :) It uses php for the documentation. Apparently doxygen alone is not enough of a beast. Just wanted to note that I'm happy with the package, GStreamer builds fine, Youtube videos play and use as little CPU as they should. rpmlint /var/lib/mock/fedora-13-x86_64/result libvpx-utils.x86_64: W: no-documentation libvpx.src: W: spelling-error %description -l en_US codec -> codex, code, codes libvpx.src:56: W: configure-without-libdir-spec libvpx.src: W: no-cleaning-of-buildroot %install libvpx.src: W: no-buildroot-tag libvpx.src: W: invalid-url Source0: http://webm.googlecode.com/files/libvpx-0.9.0.tar.bz2 HTTP Error 404: Not Found libvpx.x86_64: W: spelling-error %description -l en_US codec -> codex, code, codes 5 packages and 0 specfiles checked; 0 errors, 7 warnings. I did download the source from the url and it matched rpmlint seems to have a bug Approved New Package CVS Request ======================= Package Name: libvpx Short Description: VP8 Video Codec SDK Owners: spot Branches: F-11 F-12 F-13 devel InitialCC: CVS Done libvpx-0.9.0-5.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libvpx-0.9.0-5.fc12 libvpx-0.9.0-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libvpx-0.9.0-5.fc13 libvpx-0.9.0-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libvpx-0.9.0-5.fc11 libvpx-0.9.0-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. libvpx-0.9.0-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. libvpx-0.9.0-5.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. Package Change Request ====================== Package Name: libvpx New Branches: el5 el6 Owners: spot Git done (by process-git-requests). Package Change Request ====================== Package Name: libvpx New Branches: epel7 Owners: spot (In reply to Jiri Kastner from comment #25) > Package Change Request > ====================== > Package Name: libvpx > New Branches: epel7 > Owners: spot Why are we requesting an epel7 branch for a package that is in main EL7 distro? Has the policy changed? (In reply to Peter Robinson from comment #26) > Why are we requesting an epel7 branch for a package that is in main EL7 > distro? Has the policy changed? mea culpa, i checked only koji for epel7 build |