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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
