On Sun, Mar 26, 2006 at 02:21:19PM -0800, Jurij Smakov <[EMAIL PROTECTED]>
wrote:
> Ok, I have to apologize for not digging in BTS hard enough. In the future
> though please consider using the BTS version tracking feature to indicate
> that the problem is still present in the newer kernels, instead of filing
> a totally new bug. That way all the relevant information will be in one
> collected in one place.
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 :)
> >greater than the possible pride of having a (superficially) bug-free
> >package. The loss for other people who are suffering from the same or
> >similar bugs would be big.
>
> You have a point here, I agree. I shouldn't have suggested to close this
> bug. But the way I see it, you are the only person so far hitting it,
> while using one particular application, which is not packaged for Debian.
The version tracking doesn't help if you don't read my mails: ip _is_
packaged with debian, as is e.g. arp, which probably cna be used to
reproduce it, too (but I only described it with ip).
> Given that there are probably quite a few VPN/IP tunneling users out
> there, it raises questions about whether this application might be at
> fault (no offense intended, I know that you are the upstream author :-).
Ehrm :(
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.
> config option causes it. That'll hopefully give us some insight.
Its quite obvious to me.
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.
And its nothing personal, I just am a bit annoyed when people want to
close valid bugreports for no technical reason.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
