On Thu, 9 Apr 2015 04:39:59 -0400 (EDT)
Kamil Paral <kparal(a)redhat.com> wrote:
I see people asking on #fedora-devel or #fedora-admin about depcheck
inferior architecture issue [1] quite often. Most of them are very
confused. Last time I saw someone asking about this was tonight [2].
We're not able fix this easily, but I think we should finally at
least put some temporary measures to "work around" this issue and
stop confusing people that much, or least start explaining better
what this is and what it means. I have the following ideas:
1. In depcheck, detect if the output has "inferior architecture"
substring and add an explanatory note, like this:
not ok - depcheck for Bodhi update xforms-1.2.4-2.fc22 # FAIL
---
arch: x86_64
details:
output: |-
Build xforms-1.2.4-2.fc22 failed depcheck
package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32)
= 1.2.4-2.fc22, but none of the providers can be installed
xforms-1.2.4-2.fc22.i686 has inferior architecture
xforms-1.2.4-2.fc22.i686 has inferior architecture package
xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) =
1.2.4-2.fc22, but none of the providers can be installed
xforms-1.2.4-2.fc22.i686 has inferior architecture
xforms-1.2.4-2.fc22.i686 has inferior architecture **** PLEASE NOTE
****: This failure is most probably invalid, caused by a bug we
weren't able to fix yet:
https://phab.qadevel.cloud.fedoraproject.org/T366 . Please test you
package dependencies manually and if everything looks correct, ignore
this error. We're sorry for this inconvenience. item:
xforms-1.2.4-2.fc22 outcome: FAILED summary: xforms-1.2.4-2.fc22 into
F22 testing type: bodhi_update ...
2. Do not submit this result (I'm mostly concerned about Bodhi, but
there's no easy way to disconnect ResultsDB reporting from Bodhi
reporting, so it would affect both systems). That can be done by
filtering out "inferior architecture" CheckDetails at the end of the
depcheck run, before the final TAP is generated. We would print these
CheckDetails to stdout instead, so that the results would still be
visible in the log.
3. Alternatively to 2), Josef proposed setting these results to
ABORTED instead of FAILED. They would still show up in ResultsDB, and
they would be easy to search for (we'll need to fix T458, but we'll
need to fix that anyway). I've went through bodhi_comment_directive,
and I believe it will report the ABORTED outcome to Bodhi the same
way as any other outcome. I'd prefer either not to report ABORTED at
all, or least not send emails for them. But either way, saying
ABORTED is a bit less confusing than FAILED. And if we add the
explanatory note as suggested in 1), it could be a substantial
improvement. I think I prefer this to 2).
What do you think? Any better suggestions?
I like all three, to be honest - put a note in the logs, don't report
to bodhi and mark as ABORTED in resultsdb.
From what I've seen thus far, it's not a consistent failure but for
some reason, subsequent runs aren't updating bodhi and the bounceback
to PASS only shows up in resultsdb. Given that, I don't think that we
need to report the result to bodhi if it's a freak occurrence.
The other thing I'd like to do is start utilizing artifacts to store
repodata for at least affected runs. I've not been able to reproduce
the issue and I might get at least some more insight into what's going
wrong if I can get my hands on the generated repodata used during the
problematic runs.
I'm going to start working on some patches to grab that data and
assuming there are no objections here, handle "inferior architecture"
errors as follows:
- add note to result with similar wording to what Kamil listed above
- mark result as ABORTED
- make sure that it isn't reported to bodhi
Tim