[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux



On Tue, 17 Oct 2017 at 15:46:27 +0100, James Clarke wrote:
> On 17 Oct 2017, at 15:12, Simon McVittie <smcv@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


Reply to: