On Wed, 9 May 2007 16:46:08 -0600 dann frazier <[EMAIL PROTECTED]> wrote:
> On Wed, May 09, 2007 at 11:01:36PM +0100, Neil Williams wrote: > > I can't see how this can be deemed "important" - perhaps the automated > > tool should be less paranoid. I built, tested and run gpe-timesheet ON > > amd64 and have done for the entire time it was waiting in NEW. > > > > There is no way that the automated message can claim that this "problem" : > > "will cause > > your package to segfault on architectures where the size of a pointer > > is greater than the size of an integer, such as ia64 and amd64." > > The scanner is automated, I manually write the messages and formulate > the patches. Then please consider moderating the claims of the message because this particular one is manifestly untrue. By all means claim a seg fault on ia64 but you cannot extrapolate that to amd64. > > That simply is not true. > > Are you sure? Yes. > Have you executed a code path that makes use of the > pointer returned by this function? Yes. (Checked and validated by gdb). > If you do, it should segfault > because your pointer has been truncated. If not, I'd be interested in > examining the problem further since this would be the first known > instance. Why am I not surprised? Automated tools are fine within their limits but always remember *why* lintian and linda support overrides - no automated tool is perfect. (I've written a few too.) > > It's a minor problem and a minor bug. If a real user can demonstrate a > > problem then that would be different but this automated tool is out of > > line. > > If its a codepath that is never going to be taken then sure, its minor > - feel free to downgrade. But in the majority of instances these bugs > are likely to cause segfaults and therefore deserve at least an > important severity (which isn't even release critical, mind you). Seg faults are always bugs but it is (IMHO) wrong to claim that all seg faults are important bugs. Over-generalising the issue will not help anyone. > I simply don't think its worth the effort of reviewing every potential > codepath to see how likely it is that a user will hit it because > there's no question that these issues are bugs and in most cases will > cause software to crash - So why in the message do you claim that it *WILL* cause a crash - why the absolute certainty when now you claim that it would in most cases? All I'm asking is that you moderate the message and the severity of the report to stop being all-encompassing about it. You need to accept that automated tools WILL fail at some point and at those points you need to include the possibility of a false positive / false negative by implementing a method that allows for exceptions. There is *always* an exception. > and they are typically very simple to > fix. And $deity forbid we fix an issue *before* a user hits it! No, I frequently fix issues before an upload - I'm using the package myself in nearly all cases. If something doesn't work, I'll fix it without needing a bug report. Indeed, I frequently do this with gpe-* and with my other packages. > In the ~2 years and ~200 bugs, you're the first maintainer to respond > rudely (and extremely rudely) about it. So criticising the purity of your automated tool is construed as rude? The automated tool you use is FLAWED. Your interpretation of the results is all-sweeping and over-zealous. Your opinion of the severity of the bugs is, IMHO, also over-zealous, probably coloured by your belief that the tool is without bugs. Sorry, it doesn't work that way. > I certainly don't see what's > so offensive about someone spending time examining your package for > potential problems and even providing you with a patch! The inspection is fine - the bug report contains an untruth. The package does NOT seg fault on amd64 and I have proof of this. Your accusation is without merit and deserves to be corrected. All I am asking is that you accept the possibility that your tool is NOT perfect and that you CANNOT assert (as the original report did) that this bug WILL cause a crash on amd64 when that is manifestly untrue! What is so wrong with that? gpe-timesheet isn't perfect, I know that. I will continue to fix problems and help upstream to make a better package but it is useful in situations where something the size of gnotime is simply uninstallable (e.g. Emdebian). > I hope you're > just having a bad day I was having a very good day actually - I got a lot of important and useful work done and I was able to document exactly where the remaining problems lay, make full notes about how these could be fixed and all in a civil and polite manner that informs without over-egging the problems or my proposed fixes. I am not perfect, neither is the automated tool used to make the false assertion at the start of this report. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpjrB7ICowYH.pgp
Description: PGP signature
