FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-02-2010, 12:36 PM
seth vidal
 
Default Package maintainers -- want test results by mail?

On Wed, 2010-06-02 at 08:25 -0400, Matthias Clasen wrote:
> On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote:
> > On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote:
> > > On 06/01/2010 10:43 PM, James Laska wrote:
> > > > Greetings package maintainers,
> > > >
> > > > Want to get notification of any breakage in your just-built koji
> > > > packages? This includes results of rpmlint [1],
> > >
> > > Unless rpmlint starts to use a massively cleaned up set of rules, its
> > > results are mostly noise.
> >
> > Which packages do you maintain where the output has become unmanageable?
>
> For myself, I really only think that the spell checks are intolerable.

I think a number of the checks are probably not useful - but I also
think we'll learn more about which ones as we get feedback from
packagers getting these emails.

I think the goal is, of course, to reduce the noise out and focus on
making sure the packagers know about the truly broken.

-sv


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 12:48 PM
Ralf Corsepius
 
Default Package maintainers -- want test results by mail?

On 06/02/2010 02:36 PM, seth vidal wrote:
> On Wed, 2010-06-02 at 08:25 -0400, Matthias Clasen wrote:
>> On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote:
>>> On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote:
>>>> On 06/01/2010 10:43 PM, James Laska wrote:
>>>>> Greetings package maintainers,
>>>>>
>>>>> Want to get notification of any breakage in your just-built koji
>>>>> packages? This includes results of rpmlint [1],
>>>>
>>>> Unless rpmlint starts to use a massively cleaned up set of rules, its
>>>> results are mostly noise.
>>>
>>> Which packages do you maintain where the output has become unmanageable?
>>
>> For myself, I really only think that the spell checks are intolerable.

Agreed, these are the most annoying ones.

> I think a number of the checks are probably not useful - but I also
> think we'll learn more about which ones as we get feedback from
> packagers getting these emails.

Well, then lets begin:

# rpmlint yum
yum.noarch: W: self-obsoletion yum-allow-downgrade < 1.1.20-0 obsoletes
yum-allow-downgrade
yum.noarch: W: self-obsoletion yum-basearchonly <= 1.1.9 obsoletes
yum-basearchonly
yum.noarch: W: self-obsoletion yum-plugin-allow-downgrade < 1.1.22-0
obsoletes yum-plugin-allow-downgrade
yum.noarch: W: self-obsoletion yum-skip-broken <= 1.1.18 obsoletes
yum-skip-broken
yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/pkgtag_db.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/sqlitesack.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/update_md.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/rpmUtils/updates.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/failover.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/packages.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/i18n.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/rpmtrans.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/__init__.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/rpmUtils/transaction.py 0644L
/usr/bin/python
yum.noarch: E: non-executable-script /usr/share/yum-cli/output.py 0644L
/usr/bin/python
yum.noarch: E: non-executable-script /usr/share/yum-cli/yummain.py 0644L
/usr/bin/python
yum.noarch: E: non-executable-script /usr/share/yum-cli/utils.py 0644L
/usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/metalink.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script /usr/share/yum-cli/callback.py
0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/repoMDObject.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/config.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script /usr/share/yum-cli/cli.py 0644L
/usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/rpmsack.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/Errors.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/rpmUtils/__init__.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/history.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/rpmUtils/arch.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/depsolve.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script /usr/share/yum-cli/yumcommands.py
0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/callbacks.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/sqlutils.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/rpmUtils/oldUtils.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/rpmUtils/miscutils.py 0644L /usr/bin/python
yum.noarch: E: non-executable-script
/usr/lib/python2.6/site-packages/yum/packageSack.py 0644L /usr/bin/python
1 packages and 0 specfiles checked; 31 errors, 5 warnings.

Or ...
# rpmlint binutils
binutils.x86_64: W: spelling-error %description -l en_US addr -> add,
adder, adds
binutils.x86_64: W: shared-lib-calls-exit
/usr/lib64/libbfd-2.20.51.0.2-20.fc13.so exit@GLIBC_2.2.5
binutils.x86_64: W: shared-lib-calls-exit
/usr/lib64/libbfd-2.20.51.0.2-20.fc13.so _exit@GLIBC_2.2.5
binutils.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libopcodes-2.20.51.0.2-20.fc13.so /lib64/libz.so.1
binutils.x86_64: W: no-manual-page-for-binary ld.bfd
binutils.x86_64: W: no-manual-page-for-binary ld.gold
binutils.x86_64: W: dangerous-command-in-%post rm
1 packages and 0 specfiles checked; 0 errors, 7 warnings.

...

> I think the goal is, of course, to reduce the noise out and focus on
> making sure the packagers know about the truly broken.
Agreed. IMO, for automated QA, we need a *fedora-specific* set of rules
which doesn't produce any bogus warning or error.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 12:49 PM
James Laska
 
Default Package maintainers -- want test results by mail?

On Wed, 2010-06-02 at 14:10 +0200, Ralf Corsepius wrote:
> On 06/02/2010 01:49 PM, James Laska wrote:
> > On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote:
> >> On 06/01/2010 10:43 PM, James Laska wrote:
> >>> Greetings package maintainers,
> >>>
> >>> Want to get notification of any breakage in your just-built koji
> >>> packages? This includes results of rpmlint [1],
> >>
> >> Unless rpmlint starts to use a massively cleaned up set of rules, its
> >> results are mostly noise.
> >
> > Which packages do you maintain where the output has become unmanageable?
>
> Noise is managable, but ...
>
> * Just have a look at the output rpm produces on any arbitrary packages.
> 90% of the output it produces is just (silly) noise.
>
> * Just have a look into most package reviews: Many of them suffer from
> churn on the (silly) noise rpmlint produces.

It's a *lint tool. So, depending on one's perspective, all lint tools
produce noise. If it's not useful to you, you can choose not to opt-in.
Also, if you don't [co-]maintain any packages, this won't be an issue.

> That's why I consider rpmlint's current ruleset not to be suiteable for
> automated QA.

Agreed, not all packages fit into a neat bucket. But if there are any
specifics you can highlight, and if you are interested in making the
output more meaningful to a package maintainer, we can start the
discussion of how to address the problem. If we never use rpmlint, it
won't get any better.

Some previously discussed ideas include ...

1. Blacklist - add support so maintainers can specify which results
to ignore
2. Only highlighting when rpmlint output regresses - this is
intended to help maintainers of unruly packages or packages
where rpmlint output has not been monitored/controlled since
initial packaging
3. Addressing the concerns raised by the package

Thanks,
James
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 12:54 PM
Matthias Clasen
 
Default Package maintainers -- want test results by mail?

On Wed, 2010-06-02 at 08:36 -0400, seth vidal wrote:

>
> I think the goal is, of course, to reduce the noise out and focus on
> making sure the packagers know about the truly broken.
>

Another useful goal might be to only emit errors/warnings for which we
can accompany the message with a link to the section in the packaging
guidelines that explains how to avoid the problem.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 01:09 PM
Kamil Paral
 
Default Package maintainers -- want test results by mail?

----- "seth vidal" <skvidal@fedoraproject.org> wrote:
>
> I just added autoqa-optout to fedorapeople.
>
> it does what you expect it to do and acts just like autoqa-optin

Just a minor remark... please add --help. Thanks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 01:13 PM
seth vidal
 
Default Package maintainers -- want test results by mail?

On Wed, 2010-06-02 at 09:09 -0400, Kamil Paral wrote:
> ----- "seth vidal" <skvidal@fedoraproject.org> wrote:
> >
> > I just added autoqa-optout to fedorapeople.
> >
> > it does what you expect it to do and acts just like autoqa-optin
>
> Just a minor remark... please add --help. Thanks

autoqa-optout

with no arguments

-sv


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 04:07 PM
Ville Skyttä
 
Default Package maintainers -- want test results by mail?

On Wednesday 02 June 2010, Matthias Clasen wrote:
> On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote:
>
> > Which packages do you maintain where the output has become unmanageable?
>
> For myself, I really only think that the spell checks are intolerable.

There have been some complaints about them. I don't personally think that
they're quite intolerable and the noise level should decrease over time as the
spell checker dictionaries used by Enchant evolve, but if there's clear
consensus that they cause more harm than good, they can be disabled in future
default rpmlint package configs. Until then, you can do for example:

# Disable Enchant spell check:
echo 'setOption("UseEnchant", False)' >> ~/.config/rpmlint

# ...and if you want the internal feeble spell checker msgs gone too:
echo 'addFilter("spelling-error")' >> ~/.config/rpmlint
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 04:24 PM
seth vidal
 
Default Package maintainers -- want test results by mail?

On Wed, 2010-06-02 at 08:54 -0400, Matthias Clasen wrote:
> On Wed, 2010-06-02 at 08:36 -0400, seth vidal wrote:
>
> >
> > I think the goal is, of course, to reduce the noise out and focus on
> > making sure the packagers know about the truly broken.
> >
>
> Another useful goal might be to only emit errors/warnings for which we
> can accompany the message with a link to the section in the packaging
> guidelines that explains how to avoid the problem.


sure. I think there are a number of things which are "wrong" but not
obviously a specific rule.

For example: Your package seems to have grown by 1.5GB.

or

Hmm - you had 300 provides in the last package, this one has 25000.

that seems _wrong_ but not clearly against any rule.


-sv.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 04:27 PM
seth vidal
 
Default Package maintainers -- want test results by mail?

On Wed, 2010-06-02 at 19:07 +0300, Ville Skyttä wrote:
> On Wednesday 02 June 2010, Matthias Clasen wrote:
> > On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote:
> >
> > > Which packages do you maintain where the output has become unmanageable?
> >
> > For myself, I really only think that the spell checks are intolerable.
>
> There have been some complaints about them. I don't personally think that
> they're quite intolerable and the noise level should decrease over time as the
> spell checker dictionaries used by Enchant evolve, but if there's clear
> consensus that they cause more harm than good, they can be disabled in future
> default rpmlint package configs. Until then, you can do for example:
>
> # Disable Enchant spell check:
> echo 'setOption("UseEnchant", False)' >> ~/.config/rpmlint
>
> # ...and if you want the internal feeble spell checker msgs gone too:
> echo 'addFilter("spelling-error")' >> ~/.config/rpmlint

I can personally see the advantage to having warning possible to disable
per-pkg/release by the package owners. So that various other powers that
be can see what's being filtered out - but so the packager doesn't get
annoyed by things which are not useful.

heck - I could even see making it so the optin dir could have a 'filter'
file with the filters in it - but I think that's a bit much engineering
for a first run at things. Especially when the goal is to have a results
database with better accounting of this info.

-sv


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 05:25 PM
Matt McCutchen
 
Default Package maintainers -- want test results by mail?

On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote:
> Well, then lets begin:
>
> # rpmlint yum
> yum.noarch: W: self-obsoletion yum-allow-downgrade < 1.1.20-0 obsoletes
> yum-allow-downgrade
[...]
> yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash
> yum.noarch: E: non-executable-script
> /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python
[...]
> Or ...
> # rpmlint binutils
> binutils.x86_64: W: spelling-error %description -l en_US addr -> add,
> adder, adds
> binutils.x86_64: W: shared-lib-calls-exit
> /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so exit@GLIBC_2.2.5
> binutils.x86_64: W: shared-lib-calls-exit
> /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so _exit@GLIBC_2.2.5
> binutils.x86_64: W: unused-direct-shlib-dependency
> /usr/lib64/libopcodes-2.20.51.0.2-20.fc13.so /lib64/libz.so.1
> binutils.x86_64: W: no-manual-page-for-binary ld.bfd
> binutils.x86_64: W: no-manual-page-for-binary ld.gold
> binutils.x86_64: W: dangerous-command-in-%post rm
> 1 packages and 0 specfiles checked; 0 errors, 7 warnings.

Which of those messages do you consider noise and why? Most of them
look valid to me, though they are indeed nits.

--
Matt

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org