At 1165436878 time_t, Andreas Barth wrote:
I don't refuse to fix this issue - I just don't think the issue is bad
enough to let us wait with etch for a fix (or to remove the package from
etch). That's why I downgraded it, and didn't close it.
And I was not saying that you were refusing to fix
Hello Ana Guerrero!
You reported that tdb built for you. Did you build on sparc?
My blind initial analysis of this problem:
The problem seems to exists in the sparc detection code.
Spinlocks are enabled in debian/rules for sparc, but this doesn't catch
case $host_cpu in
* Andreas Henriksson ([EMAIL PROTECTED]) [061206 14:01]:
My blind initial analysis of this problem:
The problem seems to exists in the sparc detection code.
Spinlocks are enabled in debian/rules for sparc, but this doesn't catch
case $host_cpu in
sparc)
At 1165419876 time_t, Andreas Barth wrote:
It would be nice to know what $host_cpu is actually set to when building
on sparc.
That is why I asked the bug reporter for the full build log. In case we
don't get this more information, I would however propose to assume it
works ok on the
severity 400802 important
thanks
* Julien Danjou ([EMAIL PROTECTED]) [061206 17:35]:
Checking correctness of source dependencies...
Kernel: Linux 2.6.18-1-sparc64 sparc (sparc64)
[...]
checking build system type... sparc64-unknown-linux-gnu
checking host system type...
At 1165423320 time_t, Andreas Barth wrote:
* Julien Danjou ([EMAIL PROTECTED]) [061206 17:35]:
Checking correctness of source dependencies...
Kernel: Linux 2.6.18-1-sparc64 sparc (sparc64)
[...]
checking build system type... sparc64-unknown-linux-gnu
checking host system type...
* Julien Danjou ([EMAIL PROTECTED]) [061206 18:19]:
Yes, because the officiel buildd runs build with the program sparc32,
which runs program in 32bits mode.
There's no need to refuse to run with sparc64 since that's anyway
compiled in 32 bits mode.
FWIW, mozart had the same problem and
7 matches
Mail list logo
