output flushing error causing ugly output for autoremove

[Adam Conrad]

When I do a dist-upgrade, I get the following output:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... The following packages were automatically installed and are no longer required:
  libboost-thread1.55.0 librados2 librbd1 linux-headers-3.19.0-18 linux-headers-3.19.0-18-generic
  linux-image-3.19.0-18-generic linux-image-extra-3.19.0-18-generic
  linux-signed-image-3.19.0-18-generic
Use 'apt-get autoremove' to remove them.
Done
The following packages will be upgraded:
[...]

I assume it should look like this:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  libboost-thread1.55.0 librados2 librbd1 linux-headers-3.19.0-18 linux-headers-3.19.0-18-generic
  linux-image-3.19.0-18-generic linux-image-extra-3.19.0-18-generic
  linux-signed-image-3.19.0-18-generic
Use 'apt-get autoremove' to remove them.
The following packages will be upgraded:
[...]

This is a fairly recent regression, I think, though I haven't tested vivid to see if I'm right, I don't recall it overflowing that line before.

[David Kalnischkies (donkult)]

Yeah, relatively recent in its very visible form, but a relatively old problem in its cause.
Fixed in upstream git for a while, but thanks to diverting branches (abi-breakfree unstable and abi-breaking experimental) it hasn't reached a (non-experimental) release yet:
http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2a884c612b10b27f4be2cc6dd689bfe448d9361a

It is written as an abi break, but could be rewritten to not require one with some care (at least binary compatible, technically source compatibility breaks and theoretically its still a behavior change). I just decided against it at the time it was clear we would have to keep the diversion a little longer than originally planed and backported just the "absolutely needed" stuff. We could do it now, but I guess the time is better spent in stopping to semi-maintain two branches. Hence setting "fix commited" in anticipation of "fix released" soon [all while realizing that I might very well be the biggest blocker in this process with my perfectionism]