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

Re: [Debian-on-mobile-maintainers] Bug#996699: chatty: Cross-building fails to resolve libpurple-dev

Control: tags -1 - ftbfs upstream
Control: reasign -1 libpurple-dev
Control: retitle -1 convert libpurple-dev to Architecture: any
Control: affects -1 + src:bitlbee src:chatty src:pidgin-awayonlock src:pidgin-gnome-keyring src:pidgin-nateon src:purple-discord src:purple-lurch src:purple-matrix src:purple-mm-sms src:purple-rocketchat src:purple-xmpp-carbons src:purple-xmpp-http-upload src:telegram-purple
Control: user debian-cross@lists.debian.org
Control: usertags -1 + cross-satisfiability

On Wed, Oct 20, 2021 at 10:17:30AM +0200, Evangelos Ribeiro Tzaras wrote:
> On Sun, 2021-10-17 at 09:26 -0400, Travis Wrightsman via Debian-on-
> mobile-maintainers wrote:
> > Package: chatty
> > Version: 0.4.0-1
> > Severity: serious
> > Justification: fails to build from source
> > Tags: ftbfs upstream

We do not yet categorize cross build issues as ftbfs. In any case, cross
build issues are not release critical as Sebastian Ramacher pointed out.
Please refrain from filing cross build bugs without patches.

> > Chatty fails to cross-build due to a dependency resolution error for
> > the
> > libpurple-dev package.
> > 
> > I'm not sure this is a chatty-specific bug but I'm also not sure where
> > else to place it.
> I've just checked with another package which uses libpurple-dev (f.e.
> purple-matrix)  and ran (perhaps unsurprisingly) into the same issue
> when crossbuilding.

You nailed it.

> Possibly (probably?) related crossbuild failure in pidgin:
> https://salsa.debian.org/debian/pidgin/-/jobs/2035973#L1446 

No. That's a different and unrelated issue.

> CCing debian-cross in the hopes that someone can shed some light here
> :)

Very good. That was the right thing to do.

> More generally: What should be the next steps?
> I guess I could reassign this bug to the pidgin source package (as it
> provides libpurple-dev)?

This one is partially correct as I'll explain below.

> And open bugs to
> a) libxml-parser-perl
> b) libdevel-checklib-perl
> c) python3 (and/or all the packages that make python FTCBFS)


As a general thing, if you want to look into why something doesn't cross
build, go check at our cross build quality assurance:

We learn a couple of things there:
 * chatty doesn't have satisfiable cross-Build-Depends for any
   architecture and consequently has never been built.
 * There are no linked bug reports (at the time of this writing, but the
   usertagging should make this bug show up there soon).
 * The dependency issue is with libpurple-dev (as you correctly

crossqa uses dose to check dependency issues, so it can only see one of
many problems and the first issues it happens to see is with
libpurple-dev. To see the others, we check the bootstrap.d.n link:

Good news: It's libpurple-dev and libpurple-dev only.

Time to look into libpurple-dev, right?

It's an Architecture: all package and those can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign. So clear thing, we mark
it Multi-Arch: foreign and we're done, right? Unfortunately, not.
libpurple-dev Depends on libpurple0 (among other things) and quite
clearly, it exposes libpurple0. Since libpurple0 is
architecture-dependent and exposed by libpurple-dev, libpurple-dev
cannot be Multi-Arch: foreign. The thing is: When we issue a dependency
on libpurple-dev (for a particular architecture), we want a matching
libpurple0 (of the requested architecture). And this constraint cannot
be transferred through Architecture: all packages. That issue is known
as the "multiarch interpreter problem", because it happened with
interpreters first. In any case, the canonical solution to this problem
is to turn libpurple-dev Architecture: any. At that point the resolver
will pick the host architecture libpurple-dev and the dependency will
ensure that we also get the host architecture libpurple0.

If this leaves any questions, don't hesitate to ask


Reply to: