On Mon, 29 Sep 2014 15:54:37 +0400
Игорь Пашев <pashev.igor@gmail.com> wrote:
> Is it really a good idea to remove packages which FTBFS because of
> *internal compiler error*?
There's a comment and a link to the gcc upstream bug but the bug report
in Debian hasn't been tagged or cloned or reassigned to reflect this.
There is currently no way for the gcc maintainer to close this bug with
a gcc upload, no way for any automated check to know which package is
actually affected.
> Shouldn't GCC be removed instead? :-)
This would not appear to be an RC bug in gcc. As it apparently hasn't
been filed against gcc, I can't be sure what the gcc maintainer thinks
though.
In the absence of changes to the bug which would allow an automated
process to handle the actual issue, it would seem appropriate that the
automated removal blames the package, not the compiler. Therefore, to
fix the RC bug, work with the gcc maintainer to get it cloned,
reassigned, tagged etc. with an appropriate severity.
Independent of the compiler issue, your package FTBFS with the current
default compiler - either the package needs to be removed from testing
or the package needs a (temporary) patch to allow the build to complete.
BTW: there seems to be a different problem on armhf:
configure: error: in
`/«BUILDDIR»/open-axiom-1.5.0~svn3056+ds/build-tree': configure: error:
C preprocessor "/lib/cpp" fails sanity check See `config.log' for more
details dh_auto_configure: ../configure --build=arm-linux-gnueabihf
--prefix=/usr --includedir=${prefix}/include
--mandir=${prefix}/share/man --infodir=${prefix}/share/info
--sysconfdir=/etc --localstatedir=/var --disable-silent-rules
--libexecdir=${prefix}/lib/open-axiom --disable-maintainer-mode
--disable-dependency-tracking --with-lisp=sbcl --with-x --disable-gcl
returned exit code 1 make: *** [configure-stamp] Error 2
debian/rules:45: recipe for target 'configure-stamp' failed
https://buildd.debian.org/status/package.php?p=open-axiom&suite=unstable
So maybe the compiler error results from a bug elsewhere in the package
or is simply masking a bug elsewhere in the package. Either way, the
package does still have RC issues independent of the compiler. Fixing
those would be more useful than escalating to -devel when the
maintainer for the compiler hasn't even been asked what he thinks.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: PGP signature