Bug#705037: FTBFS on sparc
On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote: Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. Yes, you raise an excellent point here. I will make this change. BTW, it also looks like upstream has a generic implementation (gcc.h) for barriers and atomic operations. They seem to be using this only for ia64 and not on unknown architectures (probably to be on the safe side), but it might just be okay on the rest of the architectures as well. If that's the case there's probably no need to actually disable liburcu everywhere else. But you should confirm this on a per-architecture basis with your upstream :-) Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705037: FTBFS on sparc
* 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=liburcusuite=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
Bug#705037: FTBFS on sparc
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=liburcusuite=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. Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. Yes, you raise an excellent point here. I will make this change. It would also help reverse deps (I maintain one of them) to actually know in which architectures they should limit the b-d on, since clearly an unrestricted one would just result into more build failures. Also a good point, thank you for the suggestions. Great, thanks, looking forward to these changes. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705037: FTBFS on sparc
On Mon, Apr 15, 2013 at 01:15:38PM -0400, Jon Bernard wrote: 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 think this is because the buildds set the personality to be 32-bit as to always build for 32-bit sparc ports, no matter the running kernel of the buildd. This is just an interpretation of the effect I'm seeing, I can't back this up with a pointer to the code :) I think using $host_cpu for what liburcu uses it is flawed in this sense (also, host? why not target?). I could be wrong though, I don't claim to be an expert on such things. I'd suggest contacting the porter people and in particular the sparc porters. 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. Yeah, I think this is the wrong way to go. The current sparc port only support 64-bit kernels, so it'd probably work on all cases, but it's not right to use 64-bit asm on a 32-bit userland port. Without access to one of those machines to test on, I have two options: I have access to schroeder and can assure you that there's no difference whatsoever between the two. But try running linux32 dpkg-buildpackage if you want to emulate this. BTW, configure.ac seems to make some assumptions about ARM optimization falgs; I'm unsure if these are correct for Debian, you should double-check if you haven't already. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705037: FTBFS on sparc
* Faidon Liambotis parav...@debian.org wrote: Package: liburcu Version: 0.7.6-1 Severity: serious Hi, Your package seems to be marked Architecture: any but seems to FTBFS on multiple architectures, some of them even release architectures. mipsel has already been marked as Not-For-Us. One of them is sparc which built for 0.6.7-1 but has failed on 0.7.6-1 since Jan 20th with: In file included from urcu/static/wfqueue.h:33:0, from wfqueue.c:25: ./urcu/uatomic.h:23:2: error: #error Cannot build: unrecognized architecture detected. This would prevent your package from entering testing, should the release happen and testing unfroze. From what I see, fixing sparc shouldn't be a big deal. kfreebsd-* which also FTBFS could be a bit less trivial to fix but still doable as a maintainer's job. 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? Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. Yes, you raise an excellent point here. I will make this change. It would also help reverse deps (I maintain one of them) to actually know in which architectures they should limit the b-d on, since clearly an unrestricted one would just result into more build failures. Also a good point, thank you for the suggestions. -- Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705037: FTBFS on sparc
Package: liburcu Version: 0.7.6-1 Severity: serious Hi, Your package seems to be marked Architecture: any but seems to FTBFS on multiple architectures, some of them even release architectures. mipsel has already been marked as Not-For-Us. One of them is sparc which built for 0.6.7-1 but has failed on 0.7.6-1 since Jan 20th with: In file included from urcu/static/wfqueue.h:33:0, from wfqueue.c:25: ./urcu/uatomic.h:23:2: error: #error Cannot build: unrecognized architecture detected. This would prevent your package from entering testing, should the release happen and testing unfroze. From what I see, fixing sparc shouldn't be a big deal. kfreebsd-* which also FTBFS could be a bit less trivial to fix but still doable as a maintainer's job. Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. It would also help reverse deps (I maintain one of them) to actually know in which architectures they should limit the b-d on, since clearly an unrestricted one would just result into more build failures. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
