Brian Burch wrote:

> Hi, Stefan. I thought you had lost interest in this bug because I 
> haven't heard anything for several months. I still have all my notes, 
> but couldn't get further without help.

Not as much lost interest as buried under a pile of various other stuff. This 
is quite unsatisfactory for the both of us but sadly the truth.

> Here is the current situation as far as I see it...
> 
> 1. The latest Intrepid kernel really does have the TCP/IP fix that 
> resolves my original problem.
>
> 2. The latest Hardy kernel is probably still broken - I have followed 
> your kernel fixes (especially TCP/IP) and haven't spotted anything that 
> looked relevant. However, I haven't run a test to confirm my beliefs 
> because....
>

That is as I remember the situation. We have tried a few changes backported 
from the upstream bug, but still had the issue. It has been quite a while but 
if I remember it correctly it was not only one patch but accumulated into a 
bigger series.

> 3. The bypass I reported with the bug definitely works with the latest 
> Hardy kernel, so my Hardy systems (I still have a couple) run fine with 
> my printer.

Which is at least something. It is not the best of solutions but at least 
allows you and likely affected to work.

> 4. Menno's problem does not sound like mine - if a print job was big 
> enough to stall, then it would never complete. Even a reboot would leave 
> the job queued and printing would hang again. Besides, he is using the 
> latest Intrepid kernel, where the bug is fixed (point 1 above).

My guess too. He actually pinpointed it quite well to a problem in cups by 
saying that the connection is opened but the time it takes to process the job 
results in a timeout.

> I think Menno should open a new bug report - perhaps stating that it is 
> definitely NOT a duplicate of 213081.

And against cups as the package.

> I'm not sure what to do about 213081. It is fixed in Intrepid, but it 
> was reported against Hardy which is an LTS release with another year or 
> so of life. I think the circumvention is fine - do you have a bug status 
> something like "bypass available"?

The problem is
a) Will we ever have the time to get to the bottom of the problem. It seems to
    be somewhere in the depths of the protocol stack.
b) Even if we found it, how simple is the fix? If it is hard to grasp the side
    effects it will be not applicable for SRU as it is not possible to tell
    whether it will break other things in that case. (Been there for another bug
    and still suffer from it)

> I agree with Leann's original thought that we shouldn't waste a lot of 
> time back-porting the Intrepid fix. I was prepared to research the code 
> differences, but I couldn't get the tools to work and Leann didn't reply 
> to my questions. If you think it is important enough to help me get 
> started, then I'll give it another try.

The tool for it would be git. You can get a log of changes or a diff for even 
subdirectories. The big problem is that, while all updates should usually fix 
something, it might only be part of the solution. So we probably talk about a 
series of patches where you have to have a good protocol background to 
understand what is going on.

Basically you could do:
apt-get install git-core
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
linux
cd linux
# Show all log entries that affected net/ipv4 between 2.6.24 and 2.6.27
git log v2.6.24..v2.6.27 net/ipv4
# Show the complete diff between 2.6.24 and 2.6.27 for net/ipv4
git diff v2.6.24..v2.6.27 net/ipv4
# if you have the commit number from fit log show that patch
git show <commit id>

But, as this is quite a lot of work and time is always scarce and Intrepid 
works, the question is whether the most pragmatic approach would be to put the 
workaround into the bug description well noticeable at the top. Close the Hardy 
task as "won't fix" (I don't like the sound of it myself but there is not much 
choice in there) and (if not already done so) "Fix released" for the trunk.