[Bug 226546] Merge Review: wvdial

Fri Nov 27 15:38:01 UTC 2009

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 at 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.