[Piuparts-devel] Reviving piuparts-analyze and using the bts

[Mika Pflüger]

Hi,

I looked into piuparts-analyze and found out it hardly does what it
promises in its docstring. Following in the thread are two patches
to repair existing functionality in piuparts-analyze and one big
patch to add functionality to interact with the bts directly via
python-debianbts and possibly bts(1).

The problem with extract_errors as it was before is that it actually
extracts lots of lines containing the package version or even the apt
download speed so the extracted lines are worthless for comparing two
logs to determine if the detected errors were most likely the same. I
just rewrote it to behave basically like 'grep -i error', which is
pretty stupid as well, but at least it has a chance to detect if the
errors are most likely the same. I can't say how likely false positives
are, but I couldn't come up with a generic algorithm which is any
better.

extract_headers in turn didn't actually extract anything, which the
patch is fixing.

Note that these two patches alone actually change the behaviour of
piuparts-analyze quite a bit, as it suddenly does things it didn't
before as it was broken. If it finds a log in fail/ and bugged/ and
they have both the exact same errors, it will copy the headers from the
bugged log to the failed log before copying the failed log to bugged/.
Nothing of that worked before so some of the behaviour might come
unexpected. I don't even know if it is desired anymore.

The patch to query the bts about bugs filed with usertag 'piuparts' does
not actually abolish the bugged/ directory as the TODO wishes, as it
retains the heuristics to detect repeated uploads of packages with the
same bug. For that it again compares the failed log against bugged logs
for the same package and if the errors match, it assumes the new upload
didn't fix the old error and copies the headers of the logs around. It
also generates the 'bts found bugnr version' command to update the
version information in the bts, but at the moment it doesn't
automatically run it. I don't know if we really want to update
bugreports automatically.

I ran piuparts-analyze with all three patches against a local copy of
sid/ with all logs from bugged/ copied to fail/ and compared the result
against the current situation. The new behaviour detects some more
bugged logs, but also misses lots of logs currently in bugged. Partly
this is because the bugs were filed against an older version, in which
case you get warnings like:

dkimproxy/1.4.1-3: Maybe a bug was filed earlier: 618558 against dkimproxy/1.4.1-1 
dkimproxy/1.4.1-3: Maybe a bug was filed earlier: 618558 against dkimproxy/1.4.1-2

And then you have to update the bug reports by hand if they actually
match.
The rest which is not detected is probably due to bugs not usertagged
'piuparts' or errors in the previous bugged/ handling.

I have not yet touched piuparts-report to integrate the found bugs into
weg pages for better linking, but the changes would be somehow visible
as you see if something is in bugged/ or fail/. But I will need to
integrate the warnings from piuparts-analyze somehow into the website
as well. Will see where I get during debconf and how much time I find
afterwards.

Ideally, before a new version of a package which failed earlier is
tested, the bts should be queried if there is already a bug filed
against the old version, otherwise the auto-detection of repeated
uploads not fixing the bug does not work. I will try to think about
that, maybe I'll add a function analyze_logs(package) or something
to piupartslib and use that from piuparts and piuparts-analyze.

If you have any recommendations regarding the patch I am happy to
refactor it.

Cheers,

Mika


-- 
Own your own computer. Don't use Windows 7. <http://windows7sins.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20110729/0508244b/attachment.pgp>