The tc man page references tc-index man page but tc-index man page does not exist

[Jay R. Wren]

[Impact]

 * The man pages for tc make reference to a non-existent tc-index man page. Purely a typo that should have been tc-tcindex.

 * Purely a documentation fix, but nice to fix for an LTS release that has many years left to it.

[Test Case]

 * To see this issue, fire up a 16,04 image (I did so via lxd) and type:

   root@xi386# man tc | grep tc-index
                 Filter packets based on traffic control index. See tc-index(8).

, HOWEVER:

   root@xi386:~# man tc-index
   No manual entry for tc-index

* on a fixed system you should only see refereces to tc-tcindex, not tc-index:

   root@x1:~# man tc | grep tc-index
   root@x1:~# man tc | grep tc-tcindex
                 Filter packets based on traffic control index. See tc-tcindex(8).
          red(8), tc-route(8), tc-sfb(8), tc-sfq(8), tc-stab(8), tc-tbf(8), tc-tcindex(8), tc-u32(8),

[Regression Potential]

 * This is only a change to man pages, so any regression would be non-functional, but this fix is trivial to fix and verify, and the fix is exactly from the upstream.

[Hans Joachim Desserud (hjd)]

Thanks for taking your time to report this issue and help making Ubuntu better.

I confirm that this issue is still present in 4.9.0-1ubuntu1 on Ubuntu Zesty. The manpage still mentions tc-index but it is a dead link http://manpages.ubuntu.com/manpages/zesty/en/man8/tc.8.html. (As you mention, the tcindex manpage seems to exists.

[Nish Aravamudan (nacc)]

@hjd I'm not sure where you verified that this is still a problem in 17.04. The web page seems to be a regularly-generated thing and I don't believe it's reliable to use during a development release.

In an actual 17.04 environment, `man tc` refers to `man tc-tcindex`, which does exist. Presumably an upstream fix needs to be backported to 16.04 and 16.10.

[Jon Grimm (jgrimm)]

Low hanging fruit, I can probably get to this week; but feel free to poke me if anyone else wants it.

[Jon Grimm (jgrimm)]

From upstream:

https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=b08b5ff128874f94a1bc9dd8e178fa0e57c11c61

[Jon Grimm (jgrimm)]

cherrypicking for xenial SRU. As mentioned, zesty fixed already. I don't plan on fixing yakkety at this stage of its lifecycle and this is a really minor issue.

tc(8) manapage now reads:

..
       tcindex
              Filter packets based on traffic control index. See tc-tcindex(8).
..

[Jon Grimm (jgrimm)]

Added sponsors for upload assistance.

[Hans Joachim Desserud (hjd)]

>The web page seems to be a regularly-generated thing and I don't believe it's reliable to use during a development release.

Nish: sorry, I assumed the web page was automatically updated when a new package was uploaded. I see now that while it mentions zesty, the package version number is the same as in 16.10. Will check in a VM next time.

[Jon Grimm (jgrimm)]

Fixing version for xenial. Redid changelog with dep3changlog.

[Jon Grimm (jgrimm)]

Schooled in https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging and redid versions yet again.

[Brian Murray (brian-murray)]

Given that iproute2 is part of minimal and ubuntu-core this update will be sent to everybody, and I wonder if its really worth it given that this is only correcting a typo in the manpage.

[Jon Grimm (jgrimm)]

Hi there Brian, Yeah,I said as much ('nice to fix'). My only justifications are really that its low-risk/easy fix cherry-picked from upstream, on an LTS with lots of life left, and had a kindly user generated bug reporter; always nice to show some love to users willing to write a reasonable bug report. If the SRU team wants to nix that is their call ultimately.

[Michael Terry (mterry)]

I agree with Brian that this might not be worth fixing, but at the same time, there's 4 more years of 16.04 to go.

I've uploaded both the xenial and yakkety patches (I see that you had to fix yakkety too so that the versions upgraded nicely) to proposed. Let's see what the SRU team thinks.

[Robie Basak (racb)]

IMHO (wearing my ~ubuntu-sru hat), we can and should bundle this with some other iproute2 update. But users also get frustrated with the number of updates they receive, so I don't think it's worth doing this one on its own.

Let's see if any other ~ubuntu-sru comes by and disagrees. Otherwise, I propose to reject this from the queue the next time I come round to it, but we can leave the bug open so hopefully someone else preparing a different iproute2 SRU can bundle the fix.

[Steve Langasek (vorlon)]

Hello Jay, or anyone else affected,

Accepted iproute2 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/4.3.0-1ubuntu3.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Steve Langasek (vorlon)]

Hello Jay, or anyone else affected,

Accepted iproute2 into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/4.3.0-1ubuntu3.16.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Simon Déziel (sdeziel)]

Fix verified on Xenial with 4.3.0-1ubuntu3.16.04.1

[Simon Déziel (sdeziel)]

Fix verified on Yakkety with 4.3.0-1ubuntu3.16.10.1 as well.

[Launchpad Janitor (janitor)]

This bug was fixed in the package iproute2 - 4.3.0-1ubuntu3.16.04.1

---------------
iproute2 (4.3.0-1ubuntu3.16.04.1) xenial; urgency=medium

  * debian/patches/1004-tc.8-Fix-reference-to-tc-tcindex.8.patch:
    [PATCH] tc.8: Fix reference to tc-tcindex.8. Thanks to Phil Sutter
    <email address hidden>. LP: #1668813

 -- Jon Grimm <email address hidden> Fri, 10 Mar 2017 16:59:26 -0600

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for iproute2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package iproute2 - 4.3.0-1ubuntu3.16.10.1

---------------
iproute2 (4.3.0-1ubuntu3.16.10.1) yakkety; urgency=medium

  * debian/patches/1004-tc.8-Fix-reference-to-tc-tcindex.8.patch:
    [PATCH] tc.8: Fix reference to tc-tcindex.8. Thanks to Phil Sutter
    <email address hidden>. LP: #1668813

 -- Jon Grimm <email address hidden> Fri, 10 Mar 2017 16:59:26 -0600