Here's a false negative result: https://taskotron-dev.fedoraproject.org/artifacts/all/abb9c6cc-e75a-11e6-a77f-525400cb0b45/task_output/FEDORA-2017-1658dd0b1e.x86_64.log
results: - arch: x86_64 checkname: rpmdeplint item: FEDORA-2017-1658dd0b1e note: F25 testing outcome: FAILED type: bodhi_update Build libdrm-2.4.75-1.fc25 failed rpmdeplint package libdrm-devel-2.4.75-1.fc25.i686 requires libdrm(x86-32) = 2.4.75-1.fc25, but none of the providers can be installed package libdrm-devel-2.4.75-1.fc25.i686 requires libdrm(x86-32) = 2.4.75-1.fc25, but none of the providers can be installed
After inspecting the log: https://taskotron-dev.fedoraproject.org/artifacts/all/abb9c6cc-e75a-11e6-a77f-525400cb0b45/task_output/taskotron.log.gz I found the cause. We download i386 packages first, x86_64 later. This is to save some bandwidth, because due to multilib some i386 packages are also needed for x86_64 evaluation, and otherwise we'd have to download i386 packages twice. However, this might happen:
[libtaskotron:koji_utils.py:283] 2017-01-31 02:12:53 INFO Fetching 140 builds for tag: f25-updates-testing-pending
and
[libtaskotron:koji_utils.py:283] 2017-01-31 02:20:20 INFO Fetching 96 builds for tag: f25-updates-testing-pending
A push happened between i386 stage and x86_64 stage, so that we downloaded 140 builds initially but only 96 packages in the second stage.
I'm not really clear why we evaluated libdrm-2.4.75-1.fc25.x86_64 to be failed when we didn't download it at all (just the i386 bits), that might be another issue (or something related to mash).
libdrm-2.4.75-1.fc25.x86_64
The easiest way to solve this is probably to decouple the x86_64 execution from i386 execution (run it separately).
This ticket had assigned some Differential requests: D1171 D1178
The same problem of course affected multiple packages in this particular run, e.g. libmwaw-0.3.10-1.fc25.
libmwaw-0.3.10-1.fc25
This also happens if an update is modified/unpushed during the window between the first and second stage.
Seems to be happening quite frequently, probably several times per week (and often affects multiple packages when it happens).
D1178 has been pushed and seems to be working well. This problem has been therefore solved for #task-rpmdeplint. Closing the ticket. The problem is still valid for #task-depcheck, now we just need to finish #878 and get rid of depcheck.
Login to comment on this ticket.