[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)

On Sun, 2011-11-20 at 15:29 +0100, Matthias Klose wrote:
> On 11/19/2011 11:50 PM, Julien Cristau wrote:
> > On Sat, Nov 19, 2011 at 23:32:48 +0100, Ludovic Brenta wrote:
> > 
> >> retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998
> >> reassign 649307 src:gcc-4.6
> >> severity 649307 important
> >> forcemerge 649307 637236
> >> thanks
> >>
> >> Julien and everyone else, please stop filing FTBFS bugs automatically
> >> against gcc-4.6 or gnat-4.6.

They're not automatic, the package *is* failing to build, and that issue
should be documented.

>  We monitor the buildds and are aware of
> >> FTBFS, so these bugs are not useful for us and only take away some of
> >> our precious time for triaging.  Thanks.

Failures of other packages to build can't be blocked against "oh, the
maintainers will know about it".  Nor is anyone triaging said failures
going to automatically be aware that you know about the issue, what
progress (if any) has made towards resolving it, whether it's an issue
with GC{C,J} itself or a kernel or glibc issue, ...

In this particular case, it appears that the bug is actually in gcc and
that the gnat failure is a side-effect?  In that case, the bug should be
marked as affecting the gnat package, so it shows up in gnat's bug list.

I see Julien already added the affects, but if that had been done when
the bug was reassigned then it would have been visible in gnat-4.6's bug
list before a duplicate was filed and I suspect at least some of the
animosity in this exchange could have been avoided.

> > They may not be useful to you bug they're useful to everyone else.  Why
> > are you downgrading this bug?
> It's a buildd issue, which somebody needs to investigate.

The log of #637236, which Julien's report got merged with, implies that
someone *is* and has been investigating.

As a general note, marking what are otherwise RC bugs as important "so
that the package can migrate" isn't really appropriate, at least not
without discussion with the release team (at which point we can e.g.
tell britney to ignore the problems for a particular version).

> The "all port lights
> on green" attitude by the release team (not only for kfreebsd) doesn't help with
> this either.

If you have specific concerns about the viability of specific ports,
then raise them appropriately (and preferably in a constructive manner).
Making snide remarks and then complaining that nobody's listening to the
issues isn't helpful.



Reply to: