From Fedora Project Wiki
(update depcheck description to the new depcheck)
(update to new depcheck)
Line 11: Line 11:
= Understanding Failures =
= Understanding Failures =


== Missing requirements ==
== Unsatisfied dependencies ==
Looking at an [http://taskotron-stg.fedoraproject.org/taskmaster//builders/x86_64/builds/7510/steps/runtask/logs/stdio example log], we see the following highlight:
Looking at an [https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/1446/steps/runtask/logs/stdio example log], we see the following excerpt:
<pre>
<pre>
not ok - $CHECKNAME for Bodhi update octomap-1.6.6-3.fc20 # FAIL  
not ok - depcheck for Bodhi update openstack-zaqar-2014.2-0.3.b3.fc21 # FAIL  
   ---
   ---
   arch: x86_64
   arch: i386
   details:
   details:
     output: |-
     output: |-
       Build octomap-1.6.6-3.fc20 failed depcheck
       Build openstack-zaqar-2014.2-0.3.b3.fc21 failed depcheck
       package octomap-octovis-devel-1.6.6-3.fc20.x86_64 requires liboctovis.so.1.6()(64bit), but none of the providers can be installed
       nothing provides python-oslo-utils needed by openstack-zaqar-2014.2-0.3.b3.fc21.noarch
 
       nothing provides python-oslo-utils needed by openstack-zaqar-2014.2-0.3.b3.fc21.noarch
<snip>
   item: openstack-zaqar-2014.2-0.3.b3.fc21
 
package dynamic-edt-3d-devel-1.6.6-3.fc20.i686 requires dynamic-edt-3d(x86-32) = 1.6.6-3.fc20, but none of the providers can be installed
       nothing provides /usr/sbin/ldconfig needed by dynamic-edt-3d-1.6.6-3.fc20.i686
   item: octomap-1.6.6-3.fc20
   outcome: FAILED
   outcome: FAILED
  summary: openstack-zaqar-2014.2-0.3.b3.fc21 into F21 testing
   type: bodhi_update
   type: bodhi_update
  ...
</pre>
</pre>


In this case, {{package|octomap}} requires the shared library {{filename|liboctovis.so.1.6}}.  At the time the test ran, the shared library {{filename|liboctovis.so.1.6.so}} was not provided by any available package.
This is a similar message that you should see when trying to install this package using {{package|dnf}}.


== "Not Found" errors ==
In this case, {{package|openstack-zaqar}} requires <code>python-oslo-utils</code>, but at the time the test ran, this was not provided by any available package.
Look at the following excerpt:
<pre>
SKIPBROKEN:  --> Package: erlang-js-0.5.0-2.fc15.x86_64 (f15)
  -->    Requires: libjs.so.1()(64bit)
  -->    Removing: js-1.70-13.fc15.x86_64 (f15)
  -->        libjs.so.1()(64bit)
  -->    Updated By: 1:js-1.8.5-6.fc15.x86_64 (pending)
  -->        Not found
</pre>
 
Build {{filename|erlang-js-0.5.0-2.fc15.x86_64}} has broken dependencies. It requires <code>libjs.so.1()(64bit)</code> which is provided by {{filename|js-1.70-13.fc15.x86_64}}. But the {{package|js}} package is about to be updated (as part of this or some other update request) to {{filename|1:js-1.8.5-6.fc15.x86_64}}. And the latter build does not provide <code>libjs.so.1()(64bit)</code>, thus it is marked as '''Not found'''.
 
Let's confirm:
<pre>
$ repoquery -q --provides js-1.70-13.fc15.x86_64  | grep libjs
libjs = 1.70-13.fc15
libjs.so.1()(64bit)
$ repoquery -q --provides js-1.8.5-6.fc15.x86_64  | grep libjs
libjs = 1.8.5-6.fc15
</pre>
 
As you can see, by updating the {{package|js}} package the dependencies of {{package|erlang-js}} would be broken and that it the reason why depcheck rejected this update.
 
== Conflicts ==
 
Errors caused by packages conflicting each other should be ignored at the moment. The problem lies in the current implementation of depcheck, in which we 'bend' yum into believing that all the packages are installed at once, and then let it run its depsolver. This means, that if two (or more) packages conflict each other, then yum refuses to install them, and so they get rejected.
<pre>
SKIPBROKEN: 1:grub-0.97-77.fc16.x86_64 from pending has depsolving problems
SKIPBROKEN:  --> grub conflicts with 1:grub2-1.99-2.fc16.x86_64
</pre>


= Fixing Failures =
= Fixing Failures =

Revision as of 07:46, 14 October 2014

What Is Depcheck?

Depcheck was created to detect package builds with broken dependencies. As the test matures, it will eventually be a part of the rel-eng process to prevent broken builds from being pushed to the testing or stable package repositories.

How Does Depcheck Work?

Depcheck uses libsolv to compute package dependencies of proposed updates and evaluates whether these dependencies are satisfied. Always the whole set of builds submitted to a certain repository (fedora, updates or updates-testing) is considered together -- even though Bodhi update should be completely standalone, depcheck will be able to find and resolve dependencies between individual updates, as long as they are submitted together (request to be pushed to the same repository at the same time).

Known deficiencies

At the moment, depcheck only decides whether each of the submitted builds is installable. This is equivalent to trying to install that build into a completely empty environment (no RPM packages pre-installed). If some other package build (that is already present in the target repository) gets broken as a result of this, that's not currently detected by depcheck.

Understanding Failures

Unsatisfied dependencies

Looking at an example log, we see the following excerpt:

not ok - depcheck for Bodhi update openstack-zaqar-2014.2-0.3.b3.fc21	# FAIL 
  ---
  arch: i386
  details:
    output: |-
      Build openstack-zaqar-2014.2-0.3.b3.fc21 failed depcheck
      nothing provides python-oslo-utils needed by openstack-zaqar-2014.2-0.3.b3.fc21.noarch
      nothing provides python-oslo-utils needed by openstack-zaqar-2014.2-0.3.b3.fc21.noarch
  item: openstack-zaqar-2014.2-0.3.b3.fc21
  outcome: FAILED
  summary: openstack-zaqar-2014.2-0.3.b3.fc21 into F21 testing
  type: bodhi_update
  ...

This is a similar message that you should see when trying to install this package using Package-x-generic-16.pngdnf.

In this case, Package-x-generic-16.pngopenstack-zaqar requires python-oslo-utils, but at the time the test ran, this was not provided by any available package.

Fixing Failures

Fortunately, the fixes for depcheck errors tend to be relatively straight-forward and tend to fall into one of two categories listed below.

  1. Problems caused by your package
    Examine any changes to Provides, Requires or BuildRequires in the spec file. Ensure correct spelling of all dependencies and confirm that any changed requirements do resolve for the appropriate release. If the dependencies of your package have not changed, it's possible that other packages no longer satisfy the dependencies as expected. Read below for further guidance.
    The command repoquery is helpful to track dependencies.
  2. Problems caused by other package(s)
    If your package failed because the dependencies of other packages changed (features they were providing changed or were removed), update the requirements of your package or consult with maintainers of the corresponding packages.

Other

Ignored builds

Sometimes, you'll encounter list of "ignored builds" in the report. First of all - do not be alarmed, it is not a wrong state (and we don't mark updates as FAILED if ignored builds occur). The ignored status usually means, that the update was probably changed, and more builds were added, and since we do some 'weird magic' with yum's database of installed packages, these are not recognized as updates, because these were tested in previous runs of Depcheck.

Getting Help

If you still don't understand why your update failed the test, if you think there's something wrong in our test or its documentation or if you have any other suggestions, please contact us.

Additional Information