Bug#406064: i386 binNMU for asterisk-chan-capi please
Hi, 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. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406064: i386 binNMU for asterisk-chan-capi please
reassign 406064 asterisk-chan-capi severity 406064 serious severity 408256 serious merge 406064 408256 thanks This bug is by itself severity at most important because it touches only i386 and none of the other architectures, and only in some situations. However, I think that etch should not release with such a broken package and thus upgrade the severity to "serious" under the "in the package maintainer's opinion, makes the package unsuitable for release" clause. If it comes to that, I'd rather the package be removed from i386 (but no other architecture). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406064: i386 binNMU for asterisk-chan-capi please
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]
Bug#406064: i386 binNMU for asterisk-chan-capi please
On Fri, Feb 02, 2007 at 11:46:43AM +0100, Lionel Elie Mamane wrote: > 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. In that case, I think it would be reasonable to close the bug until and unless it reappears. > - 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? Er, no. At that point, we would want Mark to provide information about his build system so that others could try to duplicate it and reproduce the bug -- Mark changing packages on his system is the absolute last thing you'd want to happen if you actually want to pin the bug and know for sure whether it's a bug in your package's build-depends/conflicts! > 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) This is a wrong rationale. - we have no evidence that the bug is architecture-specific, we only know that only one of the binary packages was confirmed to be affected. - if *any* package in the archive is completely broken, that's still an RC bug, even if the binary packages for all other archs are usable. It is ok to downgrade this bug here based on the lack of information and the lack of concrete impact on the current set of binaries. > 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". There is an obvious course of investigation here -- find out whether Mark's system can still be used to reproduce broken binaries, and take it from there. Before that's been attempted, it's simply false to claim that it's unreproducible. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406064: Bug#408256: Bug#406064: i386 binNMU for asterisk-chan-capi please
On Monday 05 February 2007 21:53, Mark Purcell wrote: > I can't recreate my build environment from Oct 06. > > And I can't reproduce the bug, additionally I don't have the hardware to test. One theory though looking at the time line: asterisk-chan-capi (0.7.1-1) would of been built against asterisk (1:1.2.12.1.dfsg-1) Etch now has asterisk (1:1.2.13~dfsg-2) and asterisk-dev may not be version compatible between 1.2.12 & 1.2.13? This could explain why the binNMU of asterisk-chan-capi now works for etch, and would suggest that asterisk-chan-capi should perhaps have a strict version dependency against asterisk. Mark asterisk-chan-capi (0.7.1-1+b1) testing; urgency=low -- Debian/i386 Build Daemon Fri, 2 Feb 2007 00:43:31 -0800 asterisk-chan-capi (0.7.1-1) unstable; urgency=low -- Mark Purcell <[EMAIL PROTECTED]> Sun, 22 Oct 2006 20:49:40 +0100 asterisk (1:1.2.13~dfsg-2) unstable; urgency=low -- Mark Purcell <[EMAIL PROTECTED]> Mon, 6 Nov 2006 06:33:19 + asterisk (1:1.2.13~dfsg-1) unstable; urgency=high -- Mark Purcell <[EMAIL PROTECTED]> Wed, 25 Oct 2006 06:46:52 +0100 asterisk (1:1.2.12.1.dfsg-1) unstable; urgency=low -- Mark Purcell <[EMAIL PROTECTED]> Sun, 24 Sep 2006 14:45:58 +0100 pgpHNttxVswqH.pgp Description: PGP signature
