----- Original Message -----
> 2. I see that you're importing _check_already_commented
from
> bodhi_utils. That method is private. Should we change it to public?
Probably, yes. There's plenty of use cases for it outside of the
bodhi_lib module. But I wanted to keep this patch as self-contained as
possible, which meant avoiding changes outside of tests/depcheck.
I just proposed a patch changing this.
> PS: bodhi_post_testresult should automatically handle duplicate
> comment detection.
Yes, but in order to filter the 'accepted' builds out of the 'pending'
set, we need to check which ones already have 'PASSED' comments in
bodhi. Which means we need to check the comments before the test
starts
- this is separate from submitting new results at the end of the test.
Ah, you're right.
> 4. On the other hand, the depcheck script itself is extremely
> verbose:
>
http://kparal.fedorapeople.org/autoqa/depcheck.log
> Will the developers be able to identify the source of the dependency
> problem? Do we have any hints for them? In this case, the boost
> package
> failed the check.
There's not a clear-cut answer for this question (if there was, we
could
automatically fix it!) but looking for the section that says
'PACKAGENAME has depsolving problems' should help:
Great, that's exactly it. We should make this hint really visible
somewhere close to the results. Or we can expect a LOT of questions
from package maintainers.
boost-1.44.0-7.fc14.x86_64 from /boost-1.44.0-7.fc14.x86_64 has
depsolving problems
--> Package: boost-1.44.0-7.fc14.x86_64 (/boost-1.44.0-7.fc14.x86_64)
--> Requires: boost-random = 1.44.0-7.fc14
So where's boost-random? Well, it shows up in the IGNORE line, which
usually means there's already a newer version in the live repos.
Except in this case you've found a bug - boost-random isn't marked as
an
upgrade because it's an entirely new package (there's nothing to
compare
it to). But that doesn't mean we should drop it from the transaction!
I'll fix this in the updated patch.
Glad to help.
(On the other hand, I'm really not looking forward to the future
where I have to fully understand the depcheck code to make similar
fixes. Ouch:))
> This seems a little complicated for me. Why don't we simply
post
> test
> result to every update in the pending set? Our
> bodhi_post_testresult()
> method automatically cares about comment duplication.
That works for for bodhi comments, but if we still want to notify
maintainers directly - like by email - we'll need to handle that some
other way.
I see. If possible I would like to see using the standard approach
of 'bodhi_post_testresult()' for handling the bodhi comments. That
way it uses our global algorithm of filtering duplicates, setting
specific interval when to re-submit FAILED result, etc, and we can
change that globally and for all tests.
Of course for sending opt-in emails etc some manual corrections
may be necessary.
> If you need to convert NVR to Bodhi update object (or its title),
> this is the approach:
>
> >>> from fedora.client import BodhiClient
> >>> bodhi = BodhiClient()
> >>> update =
bodhi.query(package='sunbird-1.0-0.32.b3pre.fc14')
> >>> update['updates'][0]['title']
> 'sunbird-1.0-0.32.b3pre.fc14,thunderbird-3.1.6-2.fc14'
>
> (let's make a method for it in bodhi_utils).
Good call - do you want to do that, or should I include a second patch
that does this?
It is included in the proposed patch:
https://fedorahosted.org/pipermail/autoqa-devel/2011-January/001531.html
Thanks,
Kamil