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=226546 --- Comment #2 from Michal Hlavinka <mhlav...@redhat.com> 2009-11-27 10:37:59 EDT --- 0) MUST: * MUST: rpmlint : $ rpmlint wvdial.spec wvdial-*.src.rpm x86_64/wvdial-* wvdial.x86_64: E: zero-length /etc/wvdial.conf wvdial.x86_64: E: non-readable /etc/ppp/peers/wvdial 0600 3 packages and 1 specfiles checked; 2 errors, 0 warnings. looks ok Legend: + = PASSED, - = FAILED, 0 = Not Applicable + MUST: The package must be named according to the Package Naming Guidelines + MUST: The spec file name must match the base package %{name}, in the format %{name}.spec + MUST: The package must meet the Packaging Guidelines + MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . - MUST(4): The License field in spec match the actual license + MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file must be included in %doc + MUST: The spec file written in American English + MUST: The spec file for the package is legible - MUST(6): The sources used to build the package must match the upstream source, as provided in the spec URL + MUST: The package successfully compile + MUST: All build dependencies must be listed in BuildRequires + MUST: The spec file handle locales properly 0 MUST: Every package which stores shared library files in any of the dynamic linker's default paths, must call ldconfig in %post and %postun + MUST: Packages does not bundle copies of system libraries + MUST: Package own all directories that it creates + MUST: Package does not list a file more than once in the spec file + MUST(2): Permissions on files must be set properly. Every %files section must include a %defattr(...) line + MUST(1): Package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT) + MUST: Package use macros consistently + MUST: Package contains code, or permissable content + MUST: Large documentation files must go in a -doc subpackage + MUST: If a package includes something as %doc, it must not affect the runtime of the application 0 MUST: Header files in a -devel package 0 MUST: Static libraries in a -static package 0 MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' 0 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 0 MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} + MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built 0 MUST: Packages containing GUI applications must include a %{name}.desktop file + MUST: Packages must not own files or directories already owned by other packages + MUST(1): At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) + MUST: All filenames in rpm packages must be valid UTF-8. [27] Comments: 1) Checking RPM_BUILD_ROOT != / is not necessary per Packaging Guidelines ( https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean ): > In the past, some packages checked that %{buildroot} was not / before > deleting it. This is not necessary in Fedora, .... rm -rf $RPM_BUILD_ROOT is enough 2) %attr in %files section is used too much %attr(0755,root,root) %{_bindir}/* %attr(0644,root,root) %{_mandir}/man1/* %attr(0644,root,root) %{_mandir}/man5/* these are default permissions, thus not required to explicitly add there 3) too much wildcards under %files section If upstream makes some changes in tarball and add/remove some files, this is not going to catch anything. It's good practice to list at least all files under %{_bindir}. This will let you know if there is any new/missing one. 4) License There is no license info in the package except COPYING - LGPL. This means License tag should be set to LGPLv2+ http://fedoraproject.org/wiki/Licensing : """A GPL or LGPL licensed package that lacks any statement of what version that it's licensed under in the source code/program output/accompanying docs is technically licensed under *any* version of the GPL or LGPL, not just the version in whatever COPYING file they include. Note that this is LGPLv2+, not LGPL+, because version 2 was the first version of LGPL.""" 5) Versioned requires ( https://fedoraproject.org/wiki/Packaging:Guidelines#Requires ) > First, if the lowest possible requirement is so old that nobody has a version > older than that installed on any target distribution release, there's no need > to include the version in the dependency at all. In that case we know the > available software is new enough. For example, the version in gtk+-devel 1.2 > dependency above is unnecessary for all Red Hat Linux distributions since (at > least) release 6.2. As a rule of thumb, if the version is not required, don't > add it just for fun. all 'ppp' versions (even in old RHELs) are newer than version specified, please remove it 6)Url and Source0 links does not work wget http://alumnit.ca/download/wvdial-1.61.tar.gz --2009-11-27 16:16:56-- http://alumnit.ca/download/wvdial-1.61.tar.gz Resolving alumnit.ca... 69.196.152.118 Connecting to alumnit.ca|69.196.152.118|:80... failed: Connection refused. wget 'http://alumnit.ca/wiki/?WvDial' --2009-11-27 16:17:30-- http://alumnit.ca/wiki/?WvDial Resolving alumnit.ca... 69.196.152.118 Connecting to alumnit.ca|69.196.152.118|:80... failed: Connection refused. 7) Missing info for patches https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment Every patch in spec file should contain a comment describing: * why is that patch used - bug number is enough * upstream information - was it sent upstream (and when)? taken from upstream? was it accepted/rejected? is this patch "fedora specific" ? please fix these issues, thanks -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
