#398: depcheck is sometimes scheduled as noarch ---------------------+------------------------ Reporter: kparal | Owner: Type: defect | Status: new Priority: minor | Milestone: Hot issues Component: tests | Keywords: Blocked By: | Blocking: ---------------------+------------------------ Generally the koji-bodhi watcher schedules both i386 and x86_64 architectures of depcheck:
{{{ # autoqa post-bodhi-update-batch --targettag f16-updates --arch x86_64 --arch i386 openssl-1.0.0f-1.fc16 --dryrun /usr/bin/atest job create --reboot_before=never --reboot_after=never -m *noarch -f /tmp/autoqa-control.le3exd post-bodhi-update- batch:upgradepath.noarch Keeping /tmp/autoqa-control.le3exd at user request /usr/bin/atest job create --reboot_before=never --reboot_after=never -m *x86_64 -d fc16 -f /tmp/autoqa-control.FscGAS post-bodhi-update- batch:depcheck.x86_64 /usr/bin/atest job create --reboot_before=never --reboot_after=never -m *i386 -d fc16 -f /tmp/autoqa-control._QiAVV post-bodhi-update- batch:depcheck.i386 Keeping /tmp/autoqa-control._QiAVV at user request }}}
But sometimes it might happen that the only new updated package is a noarch package. Then the watcher "optimized" the arguments by leaving out "--arch i386" and "--arch x86_64", therefore using the argument "--arch noarch" that is implied by default:
{{{ # autoqa post-bodhi-update-batch --targettag f16-updates rpmlint-1.0.0f-1.fc16 --dryrun /usr/bin/atest job create --reboot_before=never --reboot_after=never -m *noarch -f /tmp/autoqa-control.mlUFRG post-bodhi-update- batch:upgradepath.noarch Keeping /tmp/autoqa-control.mlUFRG at user request /usr/bin/atest job create --reboot_before=never --reboot_after=never -m *noarch -d fc16 -f /tmp/autoqa-control.zpet6Z post-bodhi-update- batch:depcheck.noarch Keeping /tmp/autoqa-control.zpet6Z at user request }}}
Unfortunately this doesn't work for depcheck. Depcheck is then scheduled as noarch test, therefore run on arbitrary machine, and the test result is also reported as "depcheck on noarch" into Bodhi.
We need to study this problem in detail and decide whether we should change the watcher (schedule both architectures?) or implement new features in the scheduling process (create a way for depcheck's control.autoqa to insist on running both architectures every time?).
This is not super-critical because even though we provide some invalid comments in Bodhi, we will probably schedule correct depcheck tests in the following runs and test the package again. But it is unpleasant nevertheless.