[opensuse-packaging] rpmlint checks in Factory
Hi, There are new, considered to be experimental, checks for rpmlint diagnostics in Factory. So far, the following checks are enabled: arch-dependent-file-in-usr-share 590 infopage-not-gzipped 540 wrong-script-interpreter 533 arch-independent-package-contains-binary-or-object 499 library-without-ldconfig-postun 400 shlib-with-non-pic-code 223 files-duplicated-waste 100 summary-not-capitalized 63 spurious-executable-perm 50 devel-file-in-non-devel-package 50 wrong-file-end-of-line-encoding 1 Other checks are also perform and printed in the log file (autobuild only, opensuse buildservice will follow later), but they _do_ _not_ _matter_ right now. The number behind the check name above is the badness score that was assigned to it. if any build has a score above 1000, it is currently failed. There are some packages which might suffer from false positives of above checks. Please, in order to help clean that up, file a bugreport against me (dmueller@novell.com) mentioning package name and check that you consider false, and I'll fix it ASAP. About the warning only checks: If you encounter any of such checks that you feel are wrong, are not complying our best practices or are exceptions that should be suppressed, PLEASE tell me about it! Do not hack around them! So, if you have a failed build today, please look ONLY for '^E:' in the logfile to figure out why it was failed. Each line has a badness score besides it. Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller wrote:
Hi,
There are new, considered to be experimental, checks for rpmlint diagnostics in Factory. So far, the following checks are enabled:
...
devel-file-in-non-devel-package 50 ...
This is one too strict: There are -examples or -doc subpackages with example source files, which is perfectly valid IMHO (we don't want to put them into -devel directly in order not to bloat buildroots. Second, why sum the score for multiple instances of the same check? Right now a package with 20+ *.c files will fail :( Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michal Marek wrote:
Dirk Mueller wrote:
Hi,
There are new, considered to be experimental, checks for rpmlint diagnostics in Factory. So far, the following checks are enabled:
...
devel-file-in-non-devel-package 50 ...
This is one too strict: There are -examples or -doc subpackages with example source files, which is perfectly valid IMHO (we don't want to put them into -devel directly in order not to bloat buildroots.
Second, why sum the score for multiple instances of the same check? Right now a package with 20+ *.c files will fail :(
Also, what about excluding /usr/share/doc/** from the checks or degrading errors to warnings here? The /usr/lib/rpm/find-requires script also skips this path. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday, 23. May 2007, Michal Marek wrote:
Also, what about excluding /usr/share/doc/** from the checks or degrading errors to warnings here?
Some of the checks make sense even in %_docdatadir. For example, we don't want arch dependant binaries under %_docdatadir. (except if they're stored in an arch specific subdirectory, like the tex packages do right now). Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday, 23. May 2007, Michal Marek wrote:
This is one too strict: There are -examples or -doc subpackages with example source files, which is perfectly valid IMHO (we don't want to put them into -devel directly in order not to bloat buildroots.
You're right, I've also noticed it. Please file a bugreport so that I do not forget to fix the check.
Second, why sum the score for multiple instances of the same check? Right now a package with 20+ *.c files will fail :(
which package are you looking at? Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller wrote:
On Wednesday, 23. May 2007, Michal Marek wrote:
This is one too strict: There are -examples or -doc subpackages with example source files, which is perfectly valid IMHO (we don't want to put them into -devel directly in order not to bloat buildroots.
You're right, I've also noticed it. Please file a bugreport so that I do not forget to fix the check.
done: https://bugzilla.novell.com/show_bug.cgi?id=277317
Second, why sum the score for multiple instances of the same check? Right now a package with 20+ *.c files will fail :(
which package are you looking at?
swig of course ;-) But eg. kdevelop3 has the same problem. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller wrote:
Other checks are also perform and printed in the log file (autobuild only, opensuse buildservice will follow later), but they _do_ _not_ _matter_ right now.
Warnings that caught my eye are:
W: plib source-or-patch-not-bzipped plib-1.8.4-joystick.diff A source archive or file in your package is not bzipped (doesn't have the .bz2 extension). To bzip it, use bzip2.
Are we going to bzip2 all patches? I think it is necessary only for large ones ...
W: plib no-cleaning-of-buildroot %install You should clean $RPM_BUILD_ROOT in the %clean section and just after the beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT".
I read on some mailing list that cleaning of build root in install section is a security issue. Unfortunately, I cannot remember which list it was :( -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday, 23. May 2007, Pavol Rusnak wrote:
Are we going to bzip2 all patches? I think it is necessary only for large ones ...
No, this warning is going to be suppressed completely. actually it seems to be a bug that it is not. Please ignore this one.
W: plib no-cleaning-of-buildroot %install You should clean $RPM_BUILD_ROOT in the %clean section and just after the beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT".
Same reason, it is supposed to be suppressed (and it is if you use the rpmlint package of STABLE on your package). it only happens with rpmlint-mini. I'll suppress it ASAP. Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On May 23 11:21 Dirk Mueller wrote (shortened):
So far, the following checks are enabled:
arch-dependent-file-in-usr-share 590 infopage-not-gzipped 540 wrong-script-interpreter 533 arch-independent-package-contains-binary-or-object 499 library-without-ldconfig-postun 400 shlib-with-non-pic-code 223 files-duplicated-waste 100 summary-not-capitalized 63 spurious-executable-perm 50 devel-file-in-non-devel-package 50 wrong-file-end-of-line-encoding 1
...
The number behind the check name above is the badness score that was assigned to it. if any build has a score above 1000, it is currently failed.
I do not understand why the badness of different errors are added at all. I think one single error is either severe enough to let the build fail or not. E.g. why is it built with one arch-dependent-file-in-usr-share and one library-without-ldconfig-postun error but not with one wrong-script-interpreter error and one arch-independent-package-contains-binary-or-object error? I suggest to compare the badness value for each single error with a threshold but not sum up anything. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller
Other checks are also perform and printed in the log file (autobuild only, opensuse buildservice will follow later), but they _do_ _not_ _matter_ right now.
Working on a new package (that is: malaga), I'd like to get it right from the very beginning. malaga seems to be a three part package: malaga (tools) libs (libmalaga) devel I think the libs subpackage containing libmalaga should be named "libmalaga" instead of "malaga-libs". But there is still a warning: RPMLINT report: =============== W: libmalaga shlib-policy-name-error libmalaga7 Your package contains a single shared library but is not named after its SONAME. What does this mean? Do yout think it is better to add the version number to the name of the library subpackage? -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 29 May 2007, Karl Eichwalder said:
What does this mean? Do yout think it is better to add the version number to the name of the library subpackage?
Yes, that's the idea. http://en.opensuse.org/Shared_Library_Packaging_Policy explains it. It takes a few readings for it all to sink in. Will -- Desktop Engineer Interfaces and Applications Team --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Will Stephenson
On Tuesday 29 May 2007, Karl Eichwalder said:
What does this mean? Do yout think it is better to add the version number to the name of the library subpackage?
Yes, that's the idea. http://en.opensuse.org/Shared_Library_Packaging_Policy explains it. It takes a few readings for it all to sink in.
Thanks for both your help. The package is now ready to be checked in. %{name} is not understood by all checker scripts (I now expanded it on my own): updating package descriptions from db (malaga lib%{name}7-devel lib%{name}7) ERROR: package not found ERROR: package not found ...done malaga: checking descriptions ...ok, checking license ...ok lib%{name}7-devel: checking descriptions ...EMPTY, checking license Package lib%{name}7-devel does not seem to have a license entered in the package database. lib%{name}7: checking descriptions ...EMPTY, checking license Package lib%{name}7 does not seem to have a license entered in the package database. -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday, 29. May 2007, Karl Eichwalder wrote:
What does this mean? Do yout think it is better to add the version number to the name of the library subpackage?
yes, see http://en.opensuse.org/Shared_Library_Packaging_Policy Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Mittwoch, 23. Mai 2007, Dirk Mueller wrote:
There are new, considered to be experimental, checks for rpmlint diagnostics in Factory. So far, the following checks are enabled:
arch-dependent-file-in-usr-share 590 infopage-not-gzipped 540 wrong-script-interpreter 533 arch-independent-package-contains-binary-or-object 499 library-without-ldconfig-postun 400 shlib-with-non-pic-code 223 files-duplicated-waste 100 summary-not-capitalized 63 spurious-executable-perm 50 devel-file-in-non-devel-package 50 wrong-file-end-of-line-encoding 1
Can you add some explanation what these checks do? (code is also OK) I'm especially interested in spurious-executable-perm, but some of the others aren't self-explaining also. Regards, Christian Boltz -- Ausserdem bin ich ja zum Glück unkündbar... Sklaven werden verkauft und nicht gekündigt! ;-) [Thilo Alfred Bätzig in suse-linux] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday 01 June 2007 09:34:39 Christian Boltz wrote:
Hello,
on Mittwoch, 23. Mai 2007, Dirk Mueller wrote:
There are new, considered to be experimental, checks for rpmlint diagnostics in Factory. So far, the following checks are enabled:
arch-dependent-file-in-usr-share 590 infopage-not-gzipped 540 wrong-script-interpreter 533 arch-independent-package-contains-binary-or-object 499 library-without-ldconfig-postun 400 shlib-with-non-pic-code 223 files-duplicated-waste 100 summary-not-capitalized 63 spurious-executable-perm 50 devel-file-in-non-devel-package 50 wrong-file-end-of-line-encoding 1
Can you add some explanation what these checks do? (code is also OK)
I'm especially interested in spurious-executable-perm, but some of the others aren't self-explaining also.
Regards,
Christian Boltz
Hi Christian. See http://en.opensuse.org/Packaging/RpmLint#spurious-executable-perm Perhaps at the end of a build with rpmlint warnings or errors, a the reference to http://en.opensuse.org/Packaging/RpmLint should be given as I think a lot of people will ask about rpmlint errors. Best, Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (8)
-
Christian Boltz -
Daniel Bornkessel -
Dirk Mueller -
Johannes Meixner -
Karl Eichwalder -
Michal Marek -
Pavol Rusnak -
Will Stephenson