severity 402920 normal thanks Pierre Habouzit ha scritto: > tag 402920 - unreproducible > clone 402920 -1 > severity -1 serious > retitle -1 mplayer do not support nostrip/noopt and is in C [violates policy > ยง10.1] > thanks > > On Wed, Dec 13, 2006 at 05:46:12PM +0100, A Mennucc wrote: >> severity 402920 normal >> tag 402920 unreproducible >> thanks >> >> Pierre Habouzit ha scritto: >>> Package: mplayer >>> Version: 1.0~rc1-2 >> your mplayer version is quite old; current one is 1.0~rc1-7 > > read the damn report, I did the report from another machine. sorry I > did not fixed that.
read your own damn reports yourself in all your reports, Version: 1.0~rc1-2 how am I supposed to know which versions you are using? >>> Severity: serious >> why? I checked into debian-policy 10.1 : >> http://www.debian.org/doc/debian-policy/ch-files.html >>> For this reason, it is recommended to support the >>> standardized environment variable DEB_BUILD_OPTIONS. >> DEB_BUILD_OPTIONS is a recommendation of policy, not a requirement. >> >> I also found out that "debug" is not in the list of options. >> See http://bugs.debian.org/157131 >> >> I will update that to 'noopt' > > admitedly, but that's not wrt the name of the option, It's just that > thtis is the sole way to have a debug build of mplayer, that is more > than useful to generate useful backtraces and debug informations. "sole way"? did you try compiling it with '-g' instead of '-g3' ? if you have a amd64 machine handy , did you try debugging on it? > you can feel free to consider this bug is not worth investigating, but I never said that I actually immediatly started compilation of a debug compilation takes 20minutes after 20minutes, I sent you a some gdm info , and proposed a quick hack to avoid any security risk then you come pissing me off saying that I do not want to address your bug > I may also consider that generating useful backtraces for you is not > worh the effort, and for the next bugs I'll just send stupid mails > "mplayer segfaults on foo" and let you deal with that alone. I just downgraded this bug because it is not a requirement of the policy > I do not care about the debug version a lot, I just wanted one with > debug symbols unstripped. But you're correct, you do not support > nostrip/noopt at all, and that's RC ! good catch. I do care about debugging issues. no it is not RC. RC is what the policy mandates, not what the policy recommends. >>> attach is the relevant build log part. >>> the build was done on an x86 box (not the one I report the bug from). >> I cannot rerpoduce this (and I tried on AMD64) > > maybe because, If you had read the bug report, you would have seen > that the machine I did the report from was not the machine I built the > package on. I did a build of the last package, with an x86 box. not an > amd64. > > givent that it's a register allocation failure it seems, that's no > wonder it works on amd64 that has plenty of'em available. this said, I still cannot reproduce it . So , please give me some time to find a way to reproduce it. And that means tomorrow evening. I cannot access an etch/i386 today a.
