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?
[1]
https://phab.qadevel.cloud.fedoraproject.org/T366
[2]
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/56...