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=520479 Mattias Ellert <mattias.ellert@xxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|nobody@xxxxxxxxxxxxxxxxx |mattias.ellert@xxxxxxxxxxxx Flag| |fedora-review? --- Comment #5 from Mattias Ellert <mattias.ellert@xxxxxxxxxxxx> 2009-10-07 05:00:59 EDT --- Fedora review myproxy-4.8-3.fc11.src.rpm 2009-10-07 rpmlint results: myproxy-devel.x86_64: W: no-documentation myproxy-server.x86_64: W: non-standard-uid /var/lib/myproxy myproxy myproxy-server.x86_64: W: non-standard-gid /var/lib/myproxy myproxy myproxy-server.x86_64: E: non-standard-dir-perm /var/lib/myproxy 0700 myproxy-server.x86_64: W: incoherent-subsys /etc/rc.d/init.d/myproxy-server $prog 8 packages and 0 specfiles checked; 1 errors, 4 warnings. All fine. + OK - needs some work + package name follows naming guidelines + spec file name matches package name + The package license tag (NCSA and BSD) is a Fedoara approved license - In addition to the license tags stated - which corresponds to the license statements in the license files - the following source files contain license statements saying they are licensed under Apache license v 2.0: pubcookie.h, safe_id_range_list.[ch], safe_is_path_trusted.[ch] + License files in the sources are installed as %doc: LICENSE, LICENSE.netbsd, LICENSE.sasl + Specfile is written in legible English + Source matches upstream - and is the latest upstream version. $ md5sum myproxy-4.8.tar.gz src/myproxy-4.8.tar.gz 85f29d553bfec5fa5f2042440542524f myproxy-4.8.tar.gz 85f29d553bfec5fa5f2042440542524f src/myproxy-4.8.tar.gz + Package builds in mock (Fedora-11) + BuildRequires are sane + Library package calls ldconfig appropiately + No bundled system libraries - The package owns most directories it creates except /etc/grid-security I know this is a tricky one, since many exernal third party non-Fedora packages put files there - the IGTF CA packages in particular. But currently the only package that is in Fedora that owns this directory is the voms server which the myproxy server does not have a dependency on. + No duplicate files + File permissions are sane and all %files sections have %defattr + %clean clears buildroot + Specfile uses macros consistently + Package contains code + Documentation is in doc sub package + %doc is not runtime essential + Headers are in devel + No static libraries + .so symlink in devel + devel requires main with full version + No libtool archives + Package does not own other's files + %install clears buildroot + filenames are valid UTF8 So formally mostly OK Some additional comments: The %_initddir macro is (as you noticed) not available in RHEL4/5, but the older (now considered misspelled) %_initrddir macro is. You could use the following definition to define the new macro to the value of the old macro if the new macro is not available: %{!?_initddir: %global _initddir %{_initrddir}} The %define should be replaced by %global anyway - see https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define Since the package name (unlike the globus packages) does not contain any underscores, the %_name macro is not really needed for this package and the %name can be used instead. The main package rpm tags values are aligned on column 16, while the subpackage tag values are separated by a single space - except for the Group tag. I can see why you might want to do it differently for the main and the sub packages, but not really why you then treat the Group tag differently. The voms not available yet comment should be removed (the --with-voms option to configure is already there). Many of the %attr statements in the %files sections look redundant and seems to be covered by the %defattr. There is a missing empty line between two entries in the changelog. In Fedora 11 the autogenerated requires in the devel package from the pkg-config dependencies will be sufficient, but if you intend to put the package in EPEL these will not be present, and there will be no dependency that will drag in globus-gss-assist-devel package when installing myproxy-devel. Adding a requires on globus-gss-assist-devel in the devel package would help. $ rpm -q --requires -p myproxy-devel-4.8-3.fc11.x86_64.rpm /usr/bin/pkg-config libmyproxy.so.4()(64bit) myproxy = 4.8-3.fc11 pkgconfig(globus-gss-assist) >= 3 < This will not be there in EPEL rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 -- 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review