There, I think I got it

[Thomas Bushnell BSG <tb@becket.net>]

So I think I got the bug, and it involved two interacting things, as
all good bugs do.

The KDE autoconf tests used by bbconf search for X libraries by doing
three things:
  Trying a plain compile with -lXt.
  Looking in a big list of possible library locations
  Running xmkmf

Test one fails on all archs.  No worry.  Test three wins anytime you
have the xutils package installed, which is why the package build
correctly so many places--any place ordinary users might do work.
Indeed, to see the bug happen, you have to have the X libraries
installed and *not* have xmkmf installed, because the bug is that on
some archs the second test fails.

And how does it fail?  Well, it uses a bogus KDE autoconf test which
notices that /lib64 exists, and assumes that every valid library
directory must have "64" at the end of its name.  So it looks through
its big list, but never sees the actual location of the libraries,
because it is adding "64" to all of them.  

One fix would be to Build-Depend on xutils, in order to pull in
xmkmf.  But that's gross.  As it happens, the configure script
supports a --disable-libsuffix option to turn off the bogus appending
of 64 to all library names.  Unfortunately, that option doesn't
actually work.  But "--enable-libsuffix=" with nothing after the =
(giving it an empty value) does work.  Blech indeed.

So I can now upload and hopefully put this stupid thing to rest.

And, for the record, my buildd probe didn't hurt any of the overloaded
buildds, because they didn't get to the package before my now fixed
package.

And, for the record, my buildd probe was very useful, in pointing me
at the role xmkmf (and the xutils package) was playing in covering up
the bug, and in confirming that my worries about package dependencies
not being installed were ill-founded.

Thomas