From Fedora Project Wiki

Revision as of 11:56, 28 April 2010 by Jlaska (talk | contribs) (Minor template fix to get backreference to work)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


AutoQA detect false positives

Click for more information...

Status Contact Mentor Skills
IDEA nobody nobody python, searching best solutions, working with big data-sets
Description
Generally this task would be about going through all the false positives AutoQA reported and figuring a method how not to run into the issue again and how to detect, if something changes. AutoQA needs to filter out this issues and not report them.

Take a look at these issues (for example):

  • https://fedorahosted.org/pipermail/autoqa-results/2010-April/013933.html
    • add some black/white-list
    • "explicit-lib-dependency liberation-mono-fonts" thinks that liberation-mono-fonts is a library, but it is IMO OK to depend on the specific font
  • https://fedorahosted.org/pipermail/autoqa-results/2010-April/013903.html
    • see the "libgnome" issue - somebody could add names of all packages and their's files into the dictionary
    • problem "doc-file-dependency /usr/share/doc/gnome-python2-gnomevfs-2.28.1/async-xfer.py /usr/bin/env" could be reported directly as a bug. Could some Python-guy confirm that "/usr/bin/env python" was obsoleted by "/usr/bin/python"?
  • https://fedorahosted.org/pipermail/autoqa-results/2010-April/013908.html
    • migth ignore conflicts like this - like if I have conflicting basepackage-subpackage1-ver1 and basepackage-subpackage2-ver2 - I can determine, that the conflict is only theoretical, because if I have updated system, there will be only one of the packages.
  • https://fedorahosted.org/pipermail/autoqa-results/2010-April/013919.html
    • I do not know exactly what is the purpose of the test as the conflicts are valid properties of the rpm. On the other hand, file conflicts are bad. But take a look at the items found. It looks like there are just files moved from one sub-package to the another, like this (check different versions): libmlx4-devel-1.0-4.fc12.x86_64 libmlx4-static-1.0.1-5.fc12.x86_64 /usr/lib64/libmlx4.a or sub-package were renamed: openscada-Special-FLibSYS-0.6.4.1-9.fc12.x86_64 openscada-Special-FlibSys-0.6.4-4.fc12.x86_64 /usr/lib64/openscada/spec_FLibSYS.so
  • ...and more.