* 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-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
