Bug 200722
| Summary: | Review Request: GraphicsMagick | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andreas Thienemann <andreas> |
| Component: | Package Review | Assignee: | Parag AN(पराग) <panemade> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | rdieter |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-11-27 13:38:11 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 163779 | ||
|
Description
Andreas Thienemann
2006-07-31 11:19:53 UTC
Offhand,
1. it appears
%{_includedir}/GraphicsMagick
dir is unowned.
2. in c++-devel subpkg:
Requires: %{name}-c++ = %{version}
Requires: %{name}-devel = %{version}
should be:
Requires: %{name}-c++ = %{version}-%{release}
Requires: %{name}-devel = %{version}-%{release}
thx, changes are incorporated at the original location FYI, whenever you make a change to the package, you ought to increment the Release tag and add a changelog entry accordingly. Ahhhhrgl. I thought we went over that topic often enough? Wasn't the consensus that bumping release numbers and changelogs during review is purely optional? It really doesn't serve as far as I can see, as the bugzilla entry contains more information then the changelog ever will. I don't know who you're referring to as "we", but IMO, the same rules that apply toward Fedora (Core/Extras) releases should be applied during reviews too. just IMHO, bumping release and adding changelogs is very usefull during reviews to me. It allows me to see that something was addressed and when. Some submitters have used -0.X during reviews and then bump release to -1 on import. I think thats fine if you are more comfortable with that... Any chance you could push our a new release with new release/changelog entries? Andreas, Is there any updates to package here? Otherwise i can go for Official Review. Oki had a look at packaging of this software and found that GraphicsMagick-devel
reporting files listed as twice. keep only
%{_includedir}/GraphicsMagick and remove other 2 lines starting with %{_includedir}.
Reupdate package by changing release tag.
Ping Package has been updated at the usual location. Please take a look. Review: + package builds in mock (development i386). + rpmlint is silent for SRPM and RPMS. + source files match upstream. f75d830ca623bf10385b3ad62c48437a GraphicsMagick-1.1.7.tar.bz2 + package meets naming and packaging guidelines. + specfile is properly named, is cleanly written + Spec file is written in American English. + Spec file is legible. + dist tag is present. + build root is correct. + license is open source-compatible. License text included in package. + %doc is small; no -doc subpackage required. + %doc does not affect runtime. + COPYING included in %doc. + BuildRequires are proper. + %clean is present. + package installed properly. + Macro use appears rather consistent. + Package contains code, not content. + no headers or static libraries. + .pc file present. + -devel,-c++, -c++-devel, -perl subpackages exists + as subpackages are packaging .so files post and postun called /sbin/ldconfig + no .la files. + no translations are available + Dose owns the directories it creates. + no duplicates in %files. + file permissions are appropriate. + perl subpackage followed perl packagaing. APPROVED. thx for the review, package is in cvs. owners.list entry is missing! |