* Faidon Liambotis <parav...@debian.org> wrote: > On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote: > > > > I suspect the buildd (schroeder in this case) has a 32bit userland and thus > > has > > a HOSTTYPE of "sparc" instead of "sparc64". I should be a one-line patch, > > but > > the only available sparc test machine (smetana) is sparc64 and so I don't > > have > > the ability to test this. It bothers me to make an upload simply to see if > > the > > sparc build machine will succeed. How would you handle this situation? > > The sparc Debian port is 32-bit userland, this has nothing to do with > the buildd. The (upcoming) sparc64 port will be a separate, 64-bit > userland port. It's currently residing on debian-ports.org and buildds > are already building new uploads; it seems liburcu 0.7.6-1 built fine > there: > http://buildd.debian-ports.org/status/package.php?p=liburcu&suite=sid > > Both schroeder and smetana have a 64-bit kernel, in fact I don't think > the sparc port has a 32-bit kernel at all anymore. smetana has all the > build dependencies to build liburcu on the sid chroot, if you want to > experiment. > > Note that this isn't something that has recently changed, so this > doesn't explain why sparc used to work with previous liburcu versions > but stopped working. This probably has something to do with a liburcu > upstream change, you should track this down.
On the buildd machines that I cannot test on, autoconf sets $host_cpu to 'sparc' instead of 'sparc64'. This caused me to assume they had a 32bit kernel. On the machine that I can test on (smetana), autoconf sets $host_cpu correctly to 'sparc64' - and so liburcu builds and runs fine there. The buildd machines are distinctly different from smetana. I had previously mapped 'sparc' to 'sparc64' to fix this, which caused everything to build successfully. But without testing, I didn't feel it was the correct thing to do, so I removed the patch. This is why the build stopped working - not due to upstream changes. Without access to one of those machines to test on, I have two options: 1. Re-enable the mapping of 'sparc' to 'sparc64' so the package builds successfully and hope that it executes properly. 2. Remove sparc from the supported architectures so that users will not risk installing a broken package. Option 2 seems the only reasonable choice to me, unless you have a better suggestion. -- Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
