[Piuparts-devel] problems with the new detect well known problems

[Dave Steele]

On Sun, Jun 1, 2014 at 5:41 AM, Holger Levsen <holger at layer-acht.org> wrote:
> Hi,
>
> so detect_well_known_problems doesnt seem to work as it should.
>
> First :
>
> piupartsm at pejacevic:/srv/piuparts.debian.org/master$ detect_well_known_errors
> Traceback (most recent call last):
> ImportError: No module named piupartslib
>
> Then,
>
> piupartsm at pejacevic:/srv/piuparts.debian.org/master$ cat sid/fail/stone_2.3.e-2+b1.kpr
> fail/stone_2.3.e-2+b1.log unclassified_failures.conf
> piupartsm at pejacevic:/srv/piuparts.debian.org/master$ grep "not owned" sid/fail/stone_2.3.e-2+b1.log
>   /root/.rnd     not owned
>
> In plain english: why isn't sid/fail/stone_2.3.e-2+b1.log being correctly
> detected as unowned_files_after_purge_error?

These both look like a misconfigured install - no module on the python
path, and no known-problems confs in the known_problem directory. I'm
seeing neither on my package-based install of current develop.

My test tree is way out of date, but I have a kpr for
stone_2.3.e-2+b1, with a non-unclassified entry. Is make processing
@sharedir@ properly?

> Third: looking at the code, I've seen that all those ISSUE=(0|1) definitions
> in known_problems/*.conf have become obsolete and should be removed.
> I just haven't done this as I dont want to interfere with already existing
> branches/commits.

ISSUE predates me. It looks like it has never been used. It's purpose
may be obsoleted by the WHEREs, which started to be added in 2011.
ISSUE looks like a a straightforward proxy for replacing the current
tpl name dependency in create_and_link_to_analyses(sp)(). I wouldn't
delete them until the integration of dwke into piuparts-report is
complete, and either WHERE or ISSUE is used to select tpl's (or
equivalent) for inclusion into the report.

-- 
"Le mieux est l'ennemi du bien" - Voltaire