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 <mhlavink@xxxxxxxxxx> 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@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review