Bug#320515: BITS_PER_LONG used unconditionally but defined only if __KERNEL__ is defined

[GOTO Masanori <gotom@debian.org>]

At Mon, 1 Aug 2005 17:38:17 +0200,
Adeodato Simó wrote:
> > Before applying a patch, I would like to hear why this bug affects
> > only sparc?
> 
>   No, it's not sparc-specific. What I meant is that, from a release
>   management point of view, it is preventing xorg-x11 from being a
>   candidate for testing, since (for different reasons over time, one of
>   them being the mentioned #318979) there has not been a successful
>   build of the package in SPARC yet. And this is blocking other packages
>   from doing their C++ ABI transition as well.
>
>   So, the bug is serious because it breaks compilation of other
>   packages, and the release team would wish (I believe) a quick solution
>   for the reason explained in the previous paragraph.
>
> > Looking at the following build log, I found linux-kernel-headers
> > 2.6.12.0-1 was used.  This means the bug #318979 is not related with
> > xorg-x11 FTBFS, I think.  If so, bumping up the severity of this bug
> > is clearly wrong.
> 
>   Again, sorry if my words were not clear enough. I was not talking
>   about an already existing FTBFS on sparc, but about a _future_ one,
>   when xorg-x11 would be retried in that arch with l-k-h 2.6.13+0rc3-1
>   (as you say, last time it was tried with still 2.6.12.0-1). But Eugene
>   Konev has stated that such retry _would_ fail, and I've asked the
>   X.org packagers for confirmation.

I still don't understand the actual point of your suggestion.  I just
want to know why #318979 causes FTBFS of xorg-x11.  Even if a bug
prevents xorg-x11 from the testing, whether lkh 2.6.13+0rc3-1 cannot
compile the future xorg-x11 on sparc or not, we should clear the
problem and what the actual bug is.  Could you explain me the problem
of xorg-x11?

Regards,
-- gotom