On Thu, Jun 30, 2011 at 16:46, Jakub Wilk <[email protected]> wrote: > * Felipe Sateler <[email protected]>, 2011-06-30, 15:37: >>>> >>>> >>>> https://buildd.debian.org/status/fetch.php?pkg=csound&arch=sparc&ver=1%3A5.13.0~dfsg-3&stamp=1298329817 >>>> >>>> https://buildd.debian.org/status/fetch.php?pkg=csound&arch=sparc&ver=1%3A5.13.0~dfsg-3.1&stamp=1309297483 >>> >>> This has happened several times during the past year. Smetana has always >>> been able to build csound, so this is clearly not a csound issue. I don't >>> think it is reasonable to file serious bugs against a package when gcc or >>> swig are segfaulting. >> >> Hmm sorry, this probably sounds more aggressive than I intended. What I >> mean is that I think these bugs should be addressed to gcc or swig since it >> is not csound that is failing to build, but rather gcc is segfaulting. I do >> not have the skills to try to debug why gcc is segfaulting on a particular >> buildd. > > Please don't take it personally. :) I filed the bug to increase visibility > of the problem, not to put blame on anyone.
No worries. I'm not venting at you either, but that I think the process is broken. This sort of bugs should not be filed against csound but rather the buildd or port maintainers, since a segfault somewhere in the toolchain is certainly not a bug in my package. I'm just frustrated that csound no longer seems to build at first try on sparc: https://buildd.debian.org/status/logs.php?pkg=csound&arch=sparc > > And yes, I tend to agree that does not really look like csound is at fault. > > Also note that this bug has no effect on testing transition, as the package > won't migrate anyway before it is built on sparc. I wonder if I should just ask for removal on sparc and ask it to be tagged not-for-us... Or alternatively, can csound be forced to always build on schroder? That buildd seems to build csound correctly. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
