taskotron / task-rpmdeplint

#5 a race condition between downloading i386 and x86_64 packages
Closed: Fixed Opened by kparal.

Closed: Fixed
Reopen Issue

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).

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.

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.
Metadata
None
None
None
None
Low
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.