Calling pinfo with e.g. 'pinfo gnus' results in 'Error: could not open info file'. Same for e.g. emacs or elisp. Or just open pinfo, navigate to e.g. gnus and try to open with Cursor Right.
Created attachment 249765 [details] `strace -f -o pinfo-gnus.strace pinfo gnus'
Looks like app-editors/emacs is the only package that installs info files into /usr/share/info/{EMACS_VERSION}/ in order to separate info files for specific versions. Let's have a word about how we can still open those.
Created attachment 249766 [details] `strace -f -o pinfo-gnus.strace pinfo gnus-1'
Nope, binutils and gcc also do that, and /usr/share/info/{EMACS_VERSION} is in INFOPATH. Looks like it fails only for Info manuals split into several files, whereas for single-file manuals like "cl" and "semantic" it works properly.
I did some debugging of pinfo with gdb. The problem is the following: Emacs generates split info files that are just named "gnus", "gnus-1", "gnus-2" etc. In the emacs ebuild, we rename them to "gnus.info", "gnus-1.info", "gnus-2.info" etc. However, the reference table in gnus.info will still look like this: gnus-1: 979 gnus-2: 300442 i.e. the file names appear there without the ".info" suffix. (We cannot simply patch this table because the numbers are character positions that would be shifted.) For both info included in Emacs and for standalone /usr/bin/info this don't matter, because they retrofit the filename with the .info suffix. Looks like pinfo doesn't do that. The relevant function in pinfo is "openinfo" in filehandling_functions.c. Now the question is if it should be fixed in emacs or in pinfo? The emacs ebuilds are renaming the GNU Info files since ages: <http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-editors/emacs-nogui/emacs-nogui-20.7-r1.ebuild?hideattic=0&revision=1.1&view=markup> I'll check if the renaming is still necessary. (It maybe a bit hard to find out why they did that change. It precedes both Bugzilla and ChangeLogs. ;-)
(In reply to comment #5) > Now the question is if it should be fixed in emacs or in pinfo? Well, though 'pinfo' fails, 'info' does not. ;) So the relevant difference should be searched and applied to pinfo.
Created attachment 249822 [details] gdb output Related problem: I've done some tests with extensionless Info files (like /usr/share/info/gnus or /usr/share/info/gnus.bz2), but pinfo-0.6.9 terminates with a segmentation fault. See attached gdb output. According to pinfo's NEWS file, they are supported: 0.5.0 Added support for infos not ending with `.info*' suffix And indeed, the previous version pinfo-0.6.8 works flawlessly with such files.
(In reply to comment #7) > Related problem: I've done some tests with extensionless Info files > (like /usr/share/info/gnus or /usr/share/info/gnus.bz2), but pinfo-0.6.9 > terminates with a segmentation fault. I've bisected the upstream repo. The breakage was caused by this commit: <http://svn.debian.org/wsvn/pinfo/?op=comp&compare%5B%5D=%2Fpinfo%2Ftrunk@178&compare%5B%5D=%2Fpinfo%2Ftrunk@179>
(In reply to comment #8) > (In reply to comment #7) > > Related problem: I've done some tests with extensionless Info files > > (like /usr/share/info/gnus or /usr/share/info/gnus.bz2), but pinfo-0.6.9 > > terminates with a segmentation fault. Ouch. Maybe that's cause for another bug report, but it's basically not a Gentoo problem (in the default configuration, you always get your info files compressed). > I've bisected the upstream repo. The breakage was caused by this commit: > <http://svn.debian.org/wsvn/pinfo/?op=comp&compare%5B%5D=%2Fpinfo%2Ftrunk@178&compare%5B%5D=%2Fpinfo%2Ftrunk@179> Thank you for your great analysis. Looks like that's a similar approach to a solution, namely that it works on Debian, so it ought to be the correct fix. (In reply to comment #6) > (In reply to comment #5) > > > Now the question is if it should be fixed in emacs or in pinfo? > > Well, though 'pinfo' fails, 'info' does not. ;) So the relevant difference > should be searched and applied to pinfo. tkinfo succeeds. tkman fails to find `gnus' as well. But tkman has more problems than just this one.
(In reply to comment #9) > > > Related problem: I've done some tests with extensionless Info files > > > (like /usr/share/info/gnus or /usr/share/info/gnus.bz2), but pinfo-0.6.9 > > > terminates with a segmentation fault. > > Ouch. Maybe that's cause for another bug report, but it's basically not a > Gentoo problem (in the default configuration, you always get your info files > compressed). Sorry, I shouldn't have said "extensionless" above. What I meant was "without .info extension". pinfo-0.6.9 doesn't find gnus.bz2 either (while 0.6.8 does). In fact, all other distributions that I've looked at (Debian, Fedora, OpenSuSE, Mandriva) install Emacs's Info files without the .info extension. Therefore I think that's the way to go for us. > tkinfo succeeds. tkman fails to find `gnus' as well. But tkman has more > problems than just this one. Texinfo documentation explicitly allows both: ,---- | There are two conventions for choosing the name: you can either remove | the extension (such as `.texi') entirely from the input file name, or, | preferably, replace it with the `.info' extension. `---- So programs that cannot handle both conventions should be fixed, IMO.
(In reply to comment #10) > > Ouch. Maybe that's cause for another bug report, but it's basically not a > > Gentoo problem (in the default configuration, you always get your info files > > compressed). > > Sorry, I shouldn't have said "extensionless" above. What I meant was "without > .info extension". pinfo-0.6.9 doesn't find gnus.bz2 either (while 0.6.8 does). Ah OK. > In fact, all other distributions that I've looked at (Debian, Fedora, OpenSuSE, > Mandriva) install Emacs's Info files without the .info extension. Therefore I > think that's the way to go for us. That's even more puzzling then - it was Debian's alioth upstream that changed this. 8-) The [URL] points to a Debian bug report where `pinfo texinfo' defaults to the man page because it cannot find an info file.
Created attachment 250365 [details, diff] pinfo-0.6.9-info-suffix.patch This should fix the issue from comment #7.
Even more upstream than [1]. Includes a patch. Has maintainer questioning why opening info files without .info filename extension would be useful. :) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496840
(In reply to comment #13) > Even more upstream than [1]. Includes a patch. Has maintainer questioning why > opening info files without .info filename extension would be useful. :) > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496840 With that patch on top of what we already have, it tries to look for paths like /usr/share/info/emacs-23/gnus.xz.info.bz2 when what I have is: /usr/share/info/emacs-23/gnus.info.bz2
That patch also tries to access() each file candidate, instead of using readdir() and comparing the filenames. So I guess my patch is better. :) @jer: Do you want to wait for a reaction from upstream?
To clarify, following our discussion on irc: We have two separate issues here, an emacs issue and a pinfo issue. - The first issue is that the emacs ebuilds used to install split info files under names like gnus-1.info while it should be either gnus-1 or gnus.info-1 (plus a compression suffix if necessary). This has already been taken care of in the emacs ebuilds. - The second (and IMHO the main) issue is the one from comment #7 and #311515 on alioth: pinfo doesn't find info files without .info extension. My patch attached in comment #12 should fix it.
(In reply to comment #16) > - The first issue is that the emacs ebuilds used to install split info files > under names like gnus-1.info while it should be either gnus-1 or gnus.info-1 > (plus a compression suffix if necessary). This has already been taken care of > in the emacs ebuilds. I don't think we should fix that. As the reporter and two more users of non-Debian systems confirmed, info files get installed without the filename suffix, and texinfo supports that so we should fix pinfo instead, as should UPSTREAM. > - The second (and IMHO the main) issue is the one from comment #7 and #311515 > on alioth: pinfo doesn't find info files without .info extension. My patch > attached in comment #12 should fix it. I have applied that in -r1. Thanks for the patch!
8930 open("/usr/share/info/emacs-23/gnus-1", O_RDONLY) = -1 ENOENT (No such file or dir ectory) 8930 open("/usr/share/info/emacs-23/gnus-1.gz", O_RDONLY) = -1 ENOENT (No such file or directory) 8930 open("/usr/share/info/emacs-23/gnus-1.Z", O_RDONLY) = -1 ENOENT (No such file or d irectory) 8930 open("/usr/share/info/emacs-23/gnus-1.bz2", O_RDONLY) = -1 ENOENT (No such file or directory) 8930 open("/usr/share/info/emacs-23/gnus-1.lzma", O_RDONLY) = -1 ENOENT (No such file o r directory) 8930 open("/usr/share/info/emacs-23/gnus-1.xz", O_RDONLY) = -1 ENOENT (No such file or directory)
Created attachment 252975 [details] strace -f -o pinfo-gnus.strace1 pinfo gnus
(In reply to comment #18) > 8930 open("/usr/share/info/emacs-23/gnus-1", O_RDONLY) = -1 ENOENT (No such > file or directory) > [5 similar messages deleted] This is with app-editors/emacs-23.2, I suppose? Please try with 23.2-r2 instead.
(In reply to comment #20) > (In reply to comment #18) > > 8930 open("/usr/share/info/emacs-23/gnus-1", O_RDONLY) = -1 ENOENT (No such > > file or directory) > > [5 similar messages deleted] > > This is with app-editors/emacs-23.2, I suppose? Please try with 23.2-r2 > instead. OK, that works. Fixed then.
