On Tue, 17 Oct 2017 at 15:46:27 +0100, James Clarke wrote: > On 17 Oct 2017, at 15:12, Simon McVittie <s...@debian.org> wrote: > > I can't help wondering whether the non-Linux ports should configure their > > buildds to use the aptitude dependency resolver (as used in -backports) > > or the aspcud resolver (as used in experimental) to get out of this > > situation. Surely this can't be the first time this has happened? > > They could, but then the resolvers differ across architectures, and that will > likely cause its own set of confusing problems. I'm not aware of many cases > where using apt has been a problem like this, though I could be wrong.
The resolvers already differ between suites and cause different confusing problems, but I get your point. > > Can you point me to an example of buildd logs where the Linux build > > succeeded and !Linux builds failed as a result of this? > > OpenCV currently suffers from this[0] (hence why Mattia is Cc'ed). Thanks. Hmm, so the error is: sbuild-build-depends-opencv-dummy : Depends: libgtk-3-dev but it is not going to be installed which is amazingly helpful. Some versions of sbuild run a solver or dose-depcheck to try to work out why, but it looks like this one doesn't. This buildd appears to be running sbuild 0.65.2, which is oldstable. Is this a known issue on kFreeBSD? I would have assumed that porters would want to stay close to what the release architectures have, which is 0.73.0? The dependency chain: libgtk-3-dev Depends dconf-gsettings-backend | gsettings-backend dconf-gsettings-backend Depends dconf-service dconf-service Depends d-d-s-b | d-s-b so we already have two layers of "if you accepted the alternative you'd be fine". I thought sbuild's allergy to alternatives only extended as far as direct dependencies? > it's a shame > wanna-build's use of dose-builddebcheck doesn't match apt's behaviour) It is. If the buildd was running a newer sbuild, I think its log would at least explain the situation in more detail. smcv