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 :)
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.
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.