Activity log for bug #615045

Date Who What changed Old value New value Message
2010-08-08 15:49:22 ooze bug added bug
2010-08-08 15:50:23 ooze affects ubuntu man-db (Ubuntu)
2010-08-08 15:50:23 ooze man-db (Ubuntu): status New Confirmed
2010-08-08 16:05:19 ooze tags regression-release
2010-08-09 14:57:15 ooze summary Cached (compressed) man pages are corrupted by conversion to UTF-8 Running catman makes man display junk data
2010-08-09 14:59:07 ooze description After running "sudo catman" to update the man page cache, the display of some man pages will be corrupted. Deleting the corresponding entries in /var/cache/man/cat[1-8]/ will bring back the original man pages. I can reproduce this problem with man-db 2.5.7-3, but not with previous 2.5.6-2. I feel that it can be related to the following change in 2.5.7-1: > - Always save cat pages in UTF-8 (closes: #446741). I see the following pipe being run: /usr/bin/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t ANSI_X3.4-1968//IGNORE | tbl | nroff -mandoc -Tascii | gzip -c7 | iconv -c -f ANSI_X3.4-1968 -t UTF-8//TRANSLIT This is very wrong because it tries to convert gzip-compressed data from ASCII to UTF-8! Oh noes! --- Original question by Thinboy00: Some man pages are appearing corrupt (i.e. if I type man foo at the terminal, I get a bunch of caret escaped characters and a few ascii characters). It looks as if man is reading the compressed data in /usr/share/man instead of uncompressing it first. I will soon attach a screenshot of the problem. The really confusing part, though, is that some man pages consistently appear corrupt and the others consistently appear correctly. I've tried the following, to no avail: mandb mandb -t mandb -c catman And yes, I did remember to use sudo on those. mandb -t said "whatis parse for /usr/share/man/[etc]:whatis parse for foo(x) failed" about some pages, but not every broken page (most of them appeared to be related to perl, but not all of them). Since whatis is working correctly, I find it hard to believe that's the problem. I also tried this: zcat /usr/man/man6/nethack.6.gz | less and it gave unformatted but readable output, even though man nethack doesn't work. I tried the same trick with slashem, which does work correctly for man, and the zcat trick worked too. I'm surprised their man pages behave differently since the pages themselves are practically identical. Is my copy of man broken? After running "sudo catman" to update the man page cache, the display of some man pages will be completely corrupted. Deleting the corresponding entries in /var/cache/man/cat[1-8]/ will bring back the original man pages. I can reproduce this problem with man-db 2.5.7-3, but not with previous 2.5.6-2. I feel that it can be related to the following upstream change in 2.5.7-1: > - Always save cat pages in UTF-8 (closes: #446741). I see the following pipe being run: /usr/bin/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t ANSI_X3.4-1968//IGNORE | tbl | nroff -mandoc -Tascii | gzip -c7 | iconv -c -f ANSI_X3.4-1968 -t UTF-8//TRANSLIT This is very wrong because it tries to convert gzip-compressed data from ASCII to UTF-8! Oh noes! == Regression details == Discovered in version: 2.5.7-2 (lucid), 2.5.7-3 (maverick) Last known good version: 2.5.6-2 (karmic) --- Original question by Thinboy00: Some man pages are appearing corrupt (i.e. if I type man foo at the terminal, I get a bunch of caret escaped characters and a few ascii characters). It looks as if man is reading the compressed data in /usr/share/man instead of uncompressing it first. I will soon attach a screenshot of the problem. The really confusing part, though, is that some man pages consistently appear corrupt and the others consistently appear correctly. I've tried the following, to no avail: mandb mandb -t mandb -c catman And yes, I did remember to use sudo on those. mandb -t said "whatis parse for /usr/share/man/[etc]:whatis parse for foo(x) failed" about some pages, but not every broken page (most of them appeared to be related to perl, but not all of them). Since whatis is working correctly, I find it hard to believe that's the problem. I also tried this: zcat /usr/man/man6/nethack.6.gz | less and it gave unformatted but readable output, even though man nethack doesn't work. I tried the same trick with slashem, which does work correctly for man, and the zcat trick worked too. I'm surprised their man pages behave differently since the pages themselves are practically identical. Is my copy of man broken?
2010-08-17 13:10:12 Colin Watson man-db (Ubuntu): status Confirmed Triaged
2010-08-17 13:10:17 Colin Watson man-db (Ubuntu): importance Undecided High
2010-08-17 13:13:40 Colin Watson man-db (Ubuntu): assignee Colin Watson (cjwatson)
2010-08-17 13:35:55 Colin Watson bug watch added http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593350
2010-08-17 13:35:55 Colin Watson bug task added man-db (Debian)
2010-08-17 14:04:37 Launchpad Janitor man-db (Ubuntu): status Triaged Fix Released
2010-08-17 14:15:13 Colin Watson nominated for series Ubuntu Lucid
2010-08-17 14:15:13 Colin Watson bug task added man-db (Ubuntu Lucid)
2010-08-17 14:17:24 Colin Watson man-db (Ubuntu Lucid): status New Triaged
2010-08-17 14:17:51 Colin Watson man-db (Ubuntu Lucid): importance Undecided High
2010-08-17 14:17:57 Colin Watson man-db (Ubuntu Lucid): assignee Colin Watson (cjwatson)
2010-08-17 14:19:46 Launchpad Janitor branch linked lp:ubuntu/man-db
2010-09-27 20:34:29 Colin Watson man-db (Ubuntu Lucid): milestone ubuntu-10.04.2
2010-09-30 12:41:51 Colin Watson description After running "sudo catman" to update the man page cache, the display of some man pages will be completely corrupted. Deleting the corresponding entries in /var/cache/man/cat[1-8]/ will bring back the original man pages. I can reproduce this problem with man-db 2.5.7-3, but not with previous 2.5.6-2. I feel that it can be related to the following upstream change in 2.5.7-1: > - Always save cat pages in UTF-8 (closes: #446741). I see the following pipe being run: /usr/bin/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t ANSI_X3.4-1968//IGNORE | tbl | nroff -mandoc -Tascii | gzip -c7 | iconv -c -f ANSI_X3.4-1968 -t UTF-8//TRANSLIT This is very wrong because it tries to convert gzip-compressed data from ASCII to UTF-8! Oh noes! == Regression details == Discovered in version: 2.5.7-2 (lucid), 2.5.7-3 (maverick) Last known good version: 2.5.6-2 (karmic) --- Original question by Thinboy00: Some man pages are appearing corrupt (i.e. if I type man foo at the terminal, I get a bunch of caret escaped characters and a few ascii characters). It looks as if man is reading the compressed data in /usr/share/man instead of uncompressing it first. I will soon attach a screenshot of the problem. The really confusing part, though, is that some man pages consistently appear corrupt and the others consistently appear correctly. I've tried the following, to no avail: mandb mandb -t mandb -c catman And yes, I did remember to use sudo on those. mandb -t said "whatis parse for /usr/share/man/[etc]:whatis parse for foo(x) failed" about some pages, but not every broken page (most of them appeared to be related to perl, but not all of them). Since whatis is working correctly, I find it hard to believe that's the problem. I also tried this: zcat /usr/man/man6/nethack.6.gz | less and it gave unformatted but readable output, even though man nethack doesn't work. I tried the same trick with slashem, which does work correctly for man, and the zcat trick worked too. I'm surprised their man pages behave differently since the pages themselves are practically identical. Is my copy of man broken? After running "sudo catman" to update the man page cache, the display of some man pages will be completely corrupted. Deleting the corresponding entries in /var/cache/man/cat[1-8]/ will bring back the original man pages. I can reproduce this problem with man-db 2.5.7-3, but not with previous 2.5.6-2. I feel that it can be related to the following upstream change in 2.5.7-1: > - Always save cat pages in UTF-8 (closes: #446741). I see the following pipe being run: /usr/bin/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t ANSI_X3.4-1968//IGNORE | tbl | nroff -mandoc -Tascii | gzip -c7 | iconv -c -f ANSI_X3.4-1968 -t UTF-8//TRANSLIT This is very wrong because it tries to convert gzip-compressed data from ASCII to UTF-8! Oh noes! == Regression details == Discovered in version: 2.5.7-2 (lucid), 2.5.7-3 (maverick) Last known good version: 2.5.6-2 (karmic) == SRU details == Impact: Preformatted manual pages ("cat pages") may be corrupted by running iconv after compression rather than before. This is a regression introduced upstream in man-db 2.5.7. Patch: Fixed upstream in http://bazaar.launchpad.net/~cjwatson/man-db/trunk/revision/1220 and backported trivially to Debian and Ubuntu Maverick. No problems reported. TEST CASE: Run 'sudo catman 1', then make sure you're using an 80-column terminal window (so that cat pages are used) and run 'LC_ALL=C man a2p'. The broken version will show binary garbage. To clear out cat pages to test the working version, run 'sudo rm /var/cache/man/cat*/*'. Regression potential: None seems likely, and the test case should be sufficient to catch misbuilds and the like. --- Original question by Thinboy00: Some man pages are appearing corrupt (i.e. if I type man foo at the terminal, I get a bunch of caret escaped characters and a few ascii characters). It looks as if man is reading the compressed data in /usr/share/man instead of uncompressing it first. I will soon attach a screenshot of the problem. The really confusing part, though, is that some man pages consistently appear corrupt and the others consistently appear correctly. I've tried the following, to no avail: mandb mandb -t mandb -c catman And yes, I did remember to use sudo on those. mandb -t said "whatis parse for /usr/share/man/[etc]:whatis parse for foo(x) failed" about some pages, but not every broken page (most of them appeared to be related to perl, but not all of them). Since whatis is working correctly, I find it hard to believe that's the problem. I also tried this: zcat /usr/man/man6/nethack.6.gz | less and it gave unformatted but readable output, even though man nethack doesn't work. I tried the same trick with slashem, which does work correctly for man, and the zcat trick worked too. I'm surprised their man pages behave differently since the pages themselves are practically identical. Is my copy of man broken?
2010-09-30 13:01:02 Colin Watson bug added subscriber Ubuntu Stable Release Updates Team
2010-09-30 13:01:19 Colin Watson man-db (Ubuntu Lucid): status Triaged In Progress
2010-10-05 13:20:14 Martin Pitt man-db (Ubuntu Lucid): status In Progress Fix Committed
2010-10-05 13:20:22 Martin Pitt bug added subscriber SRU Verification
2010-10-05 13:20:26 Martin Pitt tags regression-release regression-release verification-needed
2010-10-05 14:18:19 Launchpad Janitor branch linked lp:ubuntu/lucid-proposed/man-db
2010-10-15 13:54:41 Jean-Baptiste Lallement tags regression-release verification-needed regression-release verification-done
2010-10-18 06:17:43 Launchpad Janitor man-db (Ubuntu Lucid): status Fix Committed Fix Released
2011-08-11 12:32:55 Bug Watch Updater man-db (Debian): status Unknown Fix Released
2011-09-19 21:25:55 Ubuntu Foundations Team Bug Bot tags regression-release verification-done regression-release testcase verification-done