Bug#408256: i386 binNMU for asterisk-chan-capi please

[Lionel Elie Mamane]

On Fri, Feb 02, 2007 at 12:40:03AM -0800, Steve Langasek wrote:
> On Fri, Jan 26, 2007 at 10:52:27PM +0100, Lionel Elie Mamane wrote:

>> I have reasons to believe that the i386 build of asterisk-chan-capi
>> was hosed in some way, because several people report that the
>> package in the archive makes a segfault for them, but that the
>> exact same package compiled from Debian sources on their machine or
>> on the pkg-voip private autobuilders works fine.

>> Please schedule an i386 binNMU for asterisk-chan-capi through
>> wanna-build. Thanks.

> But the source of the hosing hasn't been identified?

The package is team-maintained. i386 is the architecture that was
uploaded with the sources. At this point, I hope that something was
hosed on the builder/uploader's personal machine, but we haven't heard
back from him yet.

Additionally, the packages in the archive works for me (in
production); I think I'm about the only team member that has hardware
on which the package works, but different hardware than what the bug
reporters have. So chasing down the problem is quite difficult.

> Which means there's no guarantee that this problem won't resurface
> later, even in an autobuilder environment.

> I've scheduled the binNMU so that we can fix the practical problem
> for users of the package,

Thanks.

> but I don't think this bug should be considered to be fixed at this
> point.

Theoretically you are right, but practically, I doubt it will achieve
anything. Remember that we cannot get a meaningful core file / stack
trace because rebuilding the package (be it with or without debugging
symbols) produces a package that works.

All I can imagine doing is rebuilding the package on the same machine
it was built on (Mark? You up to that? Maybe a normal build and a
debug,nostrip build?), have the bug reporters (who at this point do
not suffer from the bug anymore, because - hopefully - the binNMU will
fix it for them) try that package again.

Two possibilities:

 - It works. We can't even reproduce the bug, except with a specific
   binary that we cannot recreate from sources. Frankly, I'm clueless
   what to do next then.

 - It doesn't work. What do we do? Have Mark upgrade random packages
   (gcc, libfoo-dev, ...)  and the bugreporters try again, and loop
   that procedure ad nauseam?

   A lot of shots in the dark for no gain.

So we can tag it as "moreinfo", severity "important" (because, without
the severity inflation on my side to force this to be handled for
etch, that bug is important at most because architecture-specific) and
let it rot for a few years until it is irrelevant, fine. I fail to see
how this is an improvement over closing the bug under the
justification "Heisenbug, unreproducible, cannot be explained nor
investigated, reopen if you ever hit it again and we thus get a bit of
reproducibility".

-- 
Lionel