> kdeaddons > --------- > alpha - failed - libxine missing(?) > hppa - failed - libxine missing(?) > mips - failed - libxine missing(?) > mipsel - failed - libxine missing(?) > powerpc - failed - libxine missing(?) > s390 - failed - libxine missing(?) > sparc - failed - libxine missing(?) > > not sure what is wrong here it built on several archs but failed the > same way on the rest...
My first guess is that noatun might be built against libxine on those particular archs, which means that libtool looks for libxine.la when it builds the noatun plugins. In the particular plugin where kdeaddons is failing, the Makefile.am only has -lnoatun in addition to the usual KDE libraries. A quick grep in fact suggests that there's nothing at all in kdeaddons that could be dragging in libxine directly. An extension of this guess is that noatun might build in xine support if it happens to finds libxine on the system, but libxine-dev is not explicitly in the kdemultimedia build-depends. This would account for the fact that some archs have it and some don't, and the fact that it's not listed in the depends for kdemultimedia-dev. If this is true, presumably either (i) libxine-dev must be explicitly added to kdemultimedia build-depends and kdemultimedia-dev depends so that noatun always has xine support, or (ii) xine support must be explicitly disabled in noatun (hopefully through a configure flag, otherwise through a build-conflicts with libxine-dev) so that noatun never has xine support and no unexpected build-depends creep through to other packages. Of course this is all pure speculation - I haven't actually had a chance to downloaded the kdemultimedia sources and take a look. > quanta > ------ > m68k - failed - due to automake 1.4, wtf? This has been a long-standing problem hasn't it - I'll do a new upload with a build-conflicts on automake1.4. Ben.
