libjpeg detected for depwait but libkonq5-dev is the real reason

[Scott Kitterman]

Currently gwenview on armhf is in a depwait state at https://launchpad.net/ubuntu/+source/gwenview/4:4.7.90-0ubuntu1/+build/3026369. That URL says: Missing build dependencies: libjpeg-dev

This is, however, not correct. An examination of the build log reveals that soyuz is able to correctly resolve that build-dependency:

Package libjpeg-dev is a virtual package provided by:
  libjpeg8-dev 8c-2ubuntu5
  libjpeg-turbo8-dev 1.1.90+svn733-0ubuntu3

E: Package 'libjpeg-dev' has no installation candidate
libjpeg-dev is a virtual package provided by: libjpeg8-dev libjpeg-turbo8-dev E:
Using libjpeg8-dev (no default, using first one)

Later on, the true culprit appears:

The following packages have unmet dependencies:
 kde-sc-dev-latest : Breaks: libkonq5-dev (< 4:4.7.90) but 4:4.7.3-0ubuntu2 is to be installed
E: Unable to correct problems, you have held broken packages.

This is not just a cosmetic issue. kde-runtime (the source for libkonq5-dev) built hours ago, but his package is still depwait. My guess is that Soyuz is checking to see if libjpeg-dev has managed to appear to clear the depwait and, of course, it hasn't.

Once I hit retry manually, it started building (later failed for other reasons), so there is definitely a problem with Soyuz detecting when to come out of depwait and I think it's the mistake guess about why the depwait got started.

[Scott Kitterman (kitterman)]

Here's the build log from when it hit depwait.

[Robert Collins (lifeless)]

I was going to apologise for the noise, but I think actually this is agurably a dupe: I bet that if you had looked earlier, you would have seen both E: entries as depwaits, and the virtual package one isn't clearing because of bug 335913.

We could try to special case the detection of depwait causes, or we could just fix it to handle virtual packages properly. One stone, two birds.