launchpad-buildd

Depwait package fails build instead of returning to depwait if build-deps are uninstallable

Bug #495564 reported by Scott Kitterman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
launchpad-buildd
Triaged
High
Unassigned

Bug Description

I noticed this problem when some recent FTBFS on armel and sparc were fixed, I got a huge number of build failures on these arch from KDE packages that had been depwait. We do rely on the traditional behavior to avoid having to retry dozens of package/architecture combinations when we upload a new KDE version. This is very important to Kubuntu.

LaMont Jones (lamont)
Changed in launchpad-buildd:
status: New → Confirmed
assignee: nobody → LaMont Jones (lamont)
Revision history for this message
Robert Collins (lifeless) wrote :

Is this still an issue? Lamont being assigned > 1 year later suggests its fixed already..

Changed in launchpad-buildd:
status: Confirmed → Triaged
importance: Undecided → High
Revision history for this message
LaMont Jones (lamont) wrote :

Scott - is this still an issue? or is the bug possibly resolved already?

Changed in launchpad-buildd:
assignee: LaMont Jones (lamont) → nobody
Revision history for this message
William Grant (wgrant) wrote :

It is still an issue. It's also a non-trivial one.

Revision history for this message
Robert Collins (lifeless) wrote :

can you elaborate on the non trivial aspect?

Revision history for this message
William Grant (wgrant) wrote :

We would need to integrate a complete dependency resolver.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 495564] Re: Depwait package fails build instead of returning to depwait if build-deps are uninstallable

On Wed, Jan 4, 2012 at 2:36 PM, William Grant <email address hidden> wrote:
> We would need to integrate a complete dependency resolver.

Why? I mean, doesn't sbuild know 'I tried to install build-deps, and
they failed to install' : do we need to know *why* they failed to
install?

Revision history for this message
William Grant (wgrant) wrote :

Yes. If we don't know why, we can't work out when to automatically retry.

Revision history for this message
Robert Collins (lifeless) wrote :

On Wed, Jan 4, 2012 at 3:08 PM, William Grant <email address hidden> wrote:
> Yes. If we don't know why, we can't work out when to automatically
> retry.

In addition to whatever we have now, when any of the dependencies
(transitive) are changed, surely?

Revision history for this message
Julian Edwards (julian-edwards) wrote :

We can retry blindly without our own resolver, but it wastes precious build farm time. OTOH, checking build dependencies is already very expensive in the retry script. It's swings and roundabouts ...

Revision history for this message
Scott Kitterman (kitterman) wrote :

It's not free either way. The current system wastes a lot of developer time
monitoring and retrying builds that have failed rather than depwait.

Revision history for this message
Robert Collins (lifeless) wrote :

I believe this is a duplicate of bug 338858. Marking as such. If you disagree please un-dup it and supply a build log.

Revision history for this message
Scott Kitterman (kitterman) wrote :

This is not purely a duplicate of 338858. I've seen this when the build-dep is present in sufficient version, but just uninstallable. I think they are related issues, but not the same.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.