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-cr...@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) No. As a general thing, if you want to look into why something doesn't cross build, go check at our cross build quality assurance: http://crossqa.debian.net/src/chatty 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 identified). 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: https://bootstrap.debian.net/cross_all/chatty.html 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 (debian-cr...@lists.debian.org). Helmut
