On Mon, 27 Mar 2006, Marc Lehmann wrote:

I never heard about the version tracking mechanism, where I can I learn
about it, and how can I use it e.g. from reportbug?

I was advised to resubmit bugs for newer kernel versions, maybe the
version tracking mechanism is new?

In any case, that would probably a great help to me (and others :)

I'm not sure how to do it from reportbug. Most of the bug manipulation is accomplished by emailing [EMAIL PROTECTED], more information is available at http://www.debian.org/Bugs/server-control. Basically, sending a message like this:

foung 123456 2.6.15-1
thanks

to [EMAIL PROTECTED] will mark that the bug 123456 has been also found in version of 2.6.15-1 of the package. You can include such a snippet at the top of your normal bug communication and just CC it to [EMAIL PROTECTED] Filing a new bug for every new version of the package containing it is *not* a good idea.

How do you propose how a user space application can bring the kernel
into a state where it cannot recover except by rebooting just by using a
published network API? Without a kernel bug being involved?

How would that be logically possible? GVPE might be buggy as hell as much
as we are concerned, but there is no way this canot be a kernel bug, too,
regardless of what triggered it. And it should be of no consequence that
gvpe isn't being packages with debian, unless debian suddenly gets the
official policy that bugs triggered by using third-party programs or doing
program development on debian are not to be reported against debian.

That makes zero sense.

Besides, gvpe doesn't do anything besides calling a shell script that in
turn calls ip, which I have explained in detail.

I'm willing to work on this bug and try to reproduce and hopefully
resolve it.

Its very easy to reproduce here without any special software.

It would help me a lot if you would
describe a simplest gvpe setup in which the bug can be reproduced, so that

As I wrote before, gvpe isn't required, I analyzed the problem and pointed
out that the neighbour cache keeps references to the network device when its
going down thatc annot be removed.

Ok, my fault again. I've missed this information in bug 338973.

Sorry if I sound a bit frustrated, but this bug is old, and likely close
to trivial to fix. It _obviously_ is a kernel bug. It is a bug in the
debian kernel, and I am frustrated of people wanting to close valid bug
reports just because its triggered by a non-debian program (as are a lot
of bugs), which is extremely deconstructive to improving debian or any
free software package.

I am a bit frustrated that I get the same questions over and over while
having provided enough info to exactly pinpoint the problem already.

I'm sorry it have come to that. We do look at the bugs whenever we have time to do that, and since there are too many of them, it involves making quick decision based on information immediately available in the bug. Since information about your bug has been now scattered over 4 different bug reports, I've clearly made some bad calls :-). I'll review the available information once again and hopefully we'll be able to finally move ahead with it.

Best regards,

Jurij Smakov                                        [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to