----------------------------------------
> Date: Thu, 9 Apr 2015 04:39:59 -0400
> From: kpa...@redhat.com
> To: qa-de...@lists.fedoraproject.org
> Subject: remedy for depcheck inferior architecture issue
>
> 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'm with 3 plus the note from 1.
John.
_______________________________________________
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
