RPMLINT > rpmlintrc

[Sascha 'saigkill' Manns]

Hello Packagers,

i'm try to build my skrooge. The osc builds to the End. But i've 5
Messages in RPM-Lint.
One of them "kde4-skrooge.src:27: W: hardcoded-packager-tag Sascha" is
not removable (I think).
But for the other Messages i created an rpmlintrc-File. I includet it to
my spec-File as Source. But RPMLINT don't agree my File.

Can anyone help me?

I attached the rpmlintrc-File and my spec File to this Message. If
anyone would like to see it in my Repo: home:saigkill. In the
BuildService Repo my Package called "Skroogle". It was an typing Error
:-(

I'm very happy to hear any tips ...

[Dirk Müller]

Post by Sascha 'saigkill' Manns
But for the other Messages i created an rpmlintrc-File. I includet it to
my spec-File as Source. But RPMLINT don't agree my File.

I'm quite sure that the filter don't match because thats not the format that
the warnings are printed.

addFilter has to regexp match the warning that is printed to suppress it, e.g.

addFilter("kde4-skrooge.*useless-explicit-requires")


Greetings,
Dirk

[Sascha 'saigkill' Manns]

Post by Dirk Müller

Post by Sascha 'saigkill' Manns
But for the other Messages i created an rpmlintrc-File. I includet
it to my spec-File as Source. But RPMLINT don't agree my File.

I'm quite sure that the filter don't match because thats not the
format that the warnings are printed.
addFilter has to regexp match the warning that is printed to suppress it, e.g.
addFilter("kde4-skrooge.*useless-explicit-requires")

Thank you all for contributing. :-) I've seen, that my regxp was not
correct. Now the Package runs ... Thank you all...

[Philipp Thomas]

Post by Sascha 'saigkill' Manns
But for the other Messages i created an rpmlintrc-File. I includet it to
my spec-File as Source. But RPMLINT don't agree my File.

As Dirk already wrote, your rpmlintrc won't match. If you accept the
collaboration request I sent you, you'll get (aamong other things) a
rpmlintrc file that does match. BTW, warnings like those that message
catalogs aren't marked %lang should not be suppressed but rather fixed in
the sources.

Philipp

[Ludwig Nussel]

Post by Philipp Thomas
BTW, warnings like those that message
catalogs aren't marked %lang should not be suppressed but rather fixed in
the sources.

Actually no warnings should be suppressed at all IMO. They do not
fail the build after all. There is a reason to disable errors but
that can be achieved by modifying the badness score instead. That
way the package doesn't fail but one can still see the error/warning
in the log and have automated tools recognize it. A use case of that
is e.g. to be able to judge whether a transition that required
packaging changes in many packages is actually completed.
Maybe we should introduce a unsuppressable warning that warns about the
presence of a filter :-)

cu
Ludwig

[Dirk Müller]

Post by Ludwig Nussel
Maybe we should introduce a unsuppressable warning that warns about the
presence of a filter :-)

my initial idea was to make warnings starting with "suse-policy" or with
"suse-" unsuppressable.

Greetings,
Dirk

[Philipp Thomas]

Post by Ludwig Nussel
Actually no warnings should be suppressed at all IMO.

If there are useless warnings (example: KDE4 packages should require
%kde4_runtime_requires but that generates a "useless explicit requires"), I
tend to suppress them at least until its fixed.

Philipp

[Sascha 'saigkill' Manns]

Post by Philipp Thomas

Post by Ludwig Nussel
Actually no warnings should be suppressed at all IMO.

If there are useless warnings (example: KDE4 packages should require
%kde4_runtime_requires but that generates a "useless explicit
requires"), I tend to suppress them at least until its fixed.
Philipp

Thanks for explaining :-)

[Michal Vyskocil]

Post by Ludwig Nussel

Post by Philipp Thomas
BTW, warnings like those that message
catalogs aren't marked %lang should not be suppressed but rather fixed in
the sources.

Actually no warnings should be suppressed at all IMO.

There is a big exception from that rule - in case we distribute a program
without access to its source code (for example Sun/IBM Java). These packages
contains some issues in binaries like executable stack, or something else
which is unfixable for packager. So suppressing of this messages is useful
because it's easier found a packaging bugs in shorter rpmlint output.

But maybe autobuild team should create a whitelist of packages, which needs
the rpmlintrc and disable this functionality for the rest of them by default
(or only in openSUSE:.* projects).

Regards
Michal Vyskocil

[Ludwig Nussel]

Post by Michal Vyskocil

Post by Ludwig Nussel

Post by Philipp Thomas
BTW, warnings like those that message
catalogs aren't marked %lang should not be suppressed but rather fixed in
the sources.

Actually no warnings should be suppressed at all IMO.

There is a big exception from that rule - in case we distribute a program
without access to its source code (for example Sun/IBM Java). These packages
contains some issues in binaries like executable stack, or something else
which is unfixable for packager. So suppressing of this messages is useful
because it's easier found a packaging bugs in shorter rpmlint output.

Yet such information is valuable to know about a package. If a
binary package doesn't fulfil our standards why lie about it?
Of course flooding the log with stuff you can't fix anways isn't
optimal either. Maybe a summary of ignored errors would satisfy both
needs.

cu
Ludwig