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=543940 --- Comment #6 from Michal Nowak <[email protected]> 2010-01-27 07:52:15 EST --- There are two FAILs, go thru the text to find them. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > MUST: rpmlint must be run on every package. The output should be posted in > the review.[1] newman SPECS $ rpmlint libmpdclient.spec /home/newman/rpmbuild/SRPMS/libmpdclient-2.1-2.fc12.src.rpm /home/newman/rpmbuild/RPMS/i686/libmpdclient-2.1-2.fc12.i686.rpm /home/newman/rpmbuild/RPMS/i686/libmpdclient-devel-2.1-2.fc12.i686.rpm /home/newman/rpmbuild/RPMS/i686/libmpdclient-debuginfo-2.1-2.fc12.i686.rpm 4 packages and 1 specfiles checked; 0 errors, 0 warnings. > MUST: The package must be named according to the Package Naming Guidelines . OK > MUST: The spec file name must match the base package %{name}, in the format > %{name}.spec unless your package has an exemption. [2] . OK > MUST: The package must meet the Packaging Guidelines . OK > MUST: The package must be licensed with a Fedora approved license and meet > the Licensing Guidelines . OK > MUST: The License field in the package spec file must match the actual > license. [3] BSD in COPYING and sources > 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.[4] %doc AUTHORS COPYING README NEWS > MUST: The spec file must be written in American English. [5] Likely. > MUST: The spec file for the package MUST be legible. [6] OK > MUST: The sources used to build the package must match the upstream source, > as provided in the spec URL. Reviewers should use md5sum for this task. If no > upstream URL can be specified for this package, please see the Source URL > Guidelines for how to deal with this. Match. 67efa0c3d107c090ef277dfb3442d1e3 ../SOURCES/libmpdclient-2.1.tar.bz2 67efa0c3d107c090ef277dfb3442d1e3 /home/newman/libmpdclient-2.1.tar.bz2 > MUST: The package MUST successfully compile and build into binary rpms on at > least one primary architecture. [7] OK > 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. Each architecture listed in ExcludeArch MUST have a bug filed in > bugzilla, describing the reason that the package does not compile/build/work > on that architecture. The bug number MUST be placed in a comment, next to the > corresponding ExcludeArch line. [8] OK > MUST: All build dependencies must be listed in BuildRequires, except for any > that are listed in the exceptions section of the Packaging Guidelines ; > inclusion of those as BuildRequires is optional. Apply common sense. OK > MUST: The spec file MUST handle locales properly. This is done by using the > %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9] OK > MUST: Every binary RPM package (or subpackage) which stores shared library > files (not just symlinks) in any of the dynamic linker's default paths, must > call ldconfig in %post and %postun. [10] OK > MUST: Packages must NOT bundle copies of system libraries.[11] OK > MUST: If the package is designed to be relocatable, the packager must state > this fact in the request for review, along with the rationalization for > relocation of that specific package. Without this, use of Prefix: /usr is > considered a blocker. [12] OK > 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. [13] OK > MUST: A Fedora package must not list a file more than once in the spec file's > %files listings. [14] OK > MUST: Permissions on files must be set properly. Executables should be set > with executable permissions, for example. Every %files section must include a > %defattr(...) line. [15] OK > MUST: Each package must have a %clean section, which contains rm -rf > %{buildroot} (or $RPM_BUILD_ROOT). [16] OK > MUST: Each package must consistently use macros. [17] OK > MUST: The package must contain code, or permissable content. [18] OK > MUST: Large documentation files must go in a -doc subpackage. (The definition > of large is left up to the packager's best judgement, but is not restricted > to size. Large can refer to either size or quantity). [19] N/A > MUST: If a package includes something as %doc, it must not affect the runtime > of the application. To summarize: If it is in %doc, the program must run > properly if it is not present. [19] OK > MUST: Header files must be in a -devel package. [20] OK > MUST: Static libraries must be in a -static package. [21] OK > MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' > (for directory ownership and usability). [22] %files devel [...] %{_libdir}/pkgconfig/libmpdclient.pc But requirement on pkgconfig. FAIL > 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. [20] OK > MUST: In the vast majority of cases, devel packages must require the base > package using a fully versioned dependency: Requires: %{name} = > %{version}-%{release} [23] %package devel [...] Requires: %{name} = %{version} FAIL > MUST: Packages must NOT contain any .la libtool archives, these must be > removed in the spec if they are built.[21] OK > 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. If you feel that your packaged GUI application does not > need a .desktop file, you must put a comment in the spec file with your > explanation. [24] OK > MUST: Packages must not own files or directories already owned by other > packages. The rule of thumb here is that the first package to be installed > should own the files or directories that other packages may rely upon. This > means, for example, that no package in Fedora should ever share ownership > with any of the files or directories owned by the filesystem or man package. > If you feel that you have a good reason to own a file or directory that > another package owns, then please present that at package review time. [25] OK > MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} > (or $RPM_BUILD_ROOT). [26] OK > MUST: All filenames in rpm packages must be valid UTF-8. [27] OK SHOULD Items: Items marked as SHOULD are things that the package (or reviewer) SHOULD do, but is not required to do. > 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. [28] N/A > SHOULD: The description and summary sections in the package spec file should > contain translations for supported Non-English languages, if available. [29] N/A > SHOULD: The reviewer should test that the package builds in mock. [30] OK > SHOULD: The package should compile and build into binary rpms on all > supported architectures. [31] N/A > SHOULD: The reviewer should test that the package functions as described. A > package should not segfault instead of running, for example. N/A > SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, > and left up to the reviewers judgement to determine sanity. [32] N/A > SHOULD: Usually, subpackages other than devel should require the base package > using a fully versioned dependency. [23] N/A > 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. [22] N/A > 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. [33] N/A > SHOULD: your package should contain man pages for binaries/scripts. If it > doesn't, work with upstream to add them where they make sense.[34] N/A ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The rest is OK, will approve this when FAILs are fixed. -- 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 [email protected] https://admin.fedoraproject.org/mailman/listinfo/package-review
