Bug#320515: BITS_PER_LONG used unconditionally but defined only if __KERNEL__ is defined
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
> > 126.96.36.199-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 188.8.131.52-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