[Bug 226522] Merge Review: valgrind

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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=226522

--- Comment #5 from Jon Ciesla <limburgher@xxxxxxxxx> 2012-04-03 12:11:17 EDT ---
Good:

- rpmlint checks return:
valgrind.spec:24: W: unversioned-explicit-obsoletes valgrind-callgrind
The specfile contains an unversioned Obsoletes: token, which will match all
older, equal and newer versions of the obsoleted thing.  This may cause update
problems, restrict future package/provides naming, and may match something it
was originally not inteded to match -- make the Obsoletes versioned if
possible.

This should be fixed, or removed if no longer needed.

valgrind.spec:27: E: hardcoded-library-path in /usr/lib/libc.so
A library path is hardcoded to one of the following paths: /lib, /usr/lib. It
should be replaced by something like /%{_lib} or %{_libdir}.

This should be replaced by arch-specific requires on glibc-devel.

valgrind.spec:169: E: hardcoded-library-path in ../../lib/valgrind/$j
A library path is hardcoded to one of the following paths: /lib, /usr/lib. It
should be replaced by something like /%{_lib} or %{_libdir}.

Should be fixed.

valgrind.spec:368: W: macro-in-%changelog %{_prefix}
Macros are expanded in %changelog too, which can in unfortunate cases lead to
the package not building at all, or other subtle unexpected conditions that
affect the build.  Even when that doesn't happen, the expansion results in
possibly "rewriting history" on subsequent package revisions and generally odd
entries eg. in source rpms, which is rarely wanted.  Avoid use of macros in
%changelog altogether, or use two '%'s to escape them, like '%%foo'.

valgrind.spec:461: W: macro-in-%changelog %rip)
Macros are expanded in %changelog too, which can in unfortunate cases lead to
the package not building at all, or other subtle unexpected conditions that
affect the build.  Even when that doesn't happen, the expansion results in
possibly "rewriting history" on subsequent package revisions and generally odd
entries eg. in source rpms, which is rarely wanted.  Avoid use of macros in
%changelog altogether, or use two '%'s to escape them, like '%%foo'.

These are easily fixed.

valgrind.src: W: spelling-error %description -l en_US malloc -> mallow
The value of this tag appears to be misspelled. Please double-check.

Ignore.

valgrind.x86_64: W: incoherent-version-in-changelog 3.7.0-2 ['1:3.7.0-2.fc18',
'1:3.7.0-2']
The latest entry in %changelog contains a version identifier that is not
coherent with the epoch:version-release tuple of the package.

Fix.

valgrind.x86_64: W: obsolete-not-provided valgrind-callgrind
If a package is obsoleted by a compatible replacement, the obsoleted package
should also be provided in order to not cause unnecessary dependency breakage.
If the obsoleting package is not a compatible replacement for the old one,
leave out the Provides.

Fix or remove, see above.

Lots of unstripped binary or object warnings, and some statically linked
binaries, as well as shared lib without dep info. I'm assuming these should be
ignored, this being valgrind, but you should check them out to be sure.

valgrind.x86_64: E: incorrect-fsf-address /usr/share/doc/valgrind-3.7.0/COPYING
valgrind-devel.x86_64: E: incorrect-fsf-address
/usr/include/valgrind/vki/vki-s390x-linux.h
valgrind-devel.x86_64: E: incorrect-fsf-address
/usr/include/valgrind/pub_tool_libcsetjmp.h
valgrind-devel.x86_64: E: incorrect-fsf-address
/usr/include/valgrind/pub_tool_gdbserver.h
The Free Software Foundation address in this file seems to be outdated or
misspelled.  Ask upstream to update the address, or if this is a license file,
possibly the entire file with a new copy available from the FSF.

Fix if possible, or bug upstream.

Lots of dangling relative symlink errors that should probably be fixed.

valgrind.x86_64: W: no-manual-page-for-binary vgdb
Each executable in standard binary directories should have a man page.

valgrind.x86_64: W: no-manual-page-for-binary cg_diff
Each executable in standard binary directories should have a man page.

valgrind.x86_64: W: no-manual-page-for-binary valgrind-listener
Each executable in standard binary directories should have a man page.

valgrind.x86_64: W: no-manual-page-for-binary cg_merge
Each executable in standard binary directories should have a man page.

valgrind-devel.x86_64: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.

valgrind-openmpi.x86_64: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.

Fix if possible.

- package meets naming guidelines
- package meets packaging guidelines
- license ( GPLv2 ) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86_64)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file
- devel package ok
- no .la files
- post/postun ldconfig ok
- devel requires base package n-v-r 

So it looks like there isn't much to do, let me know if you want me to commit
any of it?

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review



[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]