Description of problem: The help tags are missing from the latest vim-common package. Version-Release number of selected component (if applicable): vim-common-9.0.2105-1.fc39.x86_64 How reproducible: Always Steps to Reproduce: 1. Install vim-enhanced (or vim-X11) 2. Run vim (or vimx or gvim) 3. Type :help and press enter Actual results: E433: No tags file E149: Sorry, no help for help.txt Expected results: Vim should open its help page. Additional info: It seems the /usr/share/vim/vim90/doc/tags file is no longer packaged. Old package, expected result: $ dnf repoquery -l vim-common-2:9.0.1927-1.fc39.x86_64 | grep doc/tags\$ Last metadata expiration check: 0:07:59 ago on Mon 20 Nov 2023 02:35:15 PM. /usr/share/vim/vim90/doc/tags /usr/share/vim/vim90/pack/dist/opt/matchit/doc/tags New package, missing file: $ dnf repoquery -l vim-common-2:9.0.2105-1.fc39.x86_64 | grep doc/tags\$ Last metadata expiration check: 0:08:06 ago on Mon 20 Nov 2023 02:35:15 PM. /usr/share/vim/vim90/pack/dist/opt/matchit/doc/tags
Same issue here. As a workaround, I recreated the tags file by opening vim as root and running: :helptags /usr/share/vim/vim90/doc/
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Hi all, I'm sorry for inconvenience and thank you for reporting the issue! I examined the logs and found out this error - IMO it was ignored because the make command generating the error is nested in another target: cd ../runtime/doc; if test -z "" -a -f tags; then \ mv -f tags tags.dist; fi generating help tags # We can assume Vim was build, but it may not have been installed, # thus use the executable in the current directory. make[1]: Entering directory '/builddir/build/BUILD/vim90/runtime/doc' Makefile:17: Make_all.mak: No such file or directory make[1]: *** No rule to make target 'Make_all.mak'. Stop. make[1]: Leaving directory '/builddir/build/BUILD/vim90/runtime/doc' make: [Makefile:2350: installrtbase] Error 2 (ignored) cd ../runtime/doc; \ files=`ls *.txt tags`; \ files="$files `ls *.??x tags-?? 2>/dev/null || true`"; \ cp $files /builddir/build/BUILDROOT/vim-9.0.2105-1.fc38.ppc64le/usr/share/vim/vim90/doc; \ cd /builddir/build/BUILDROOT/vim-9.0.2105-1.fc38.ppc64le/usr/share/vim/vim90/doc; \ chmod 644 $files ls: cannot access 'tags': No such file or directory The problem is there are new files in the project, but they are not part of FileList file, which is used for generating source tarball, so the new files are missing from source tarball.
(In reply to Zdenek Dohnal from comment #3) > I examined the logs and found out this error - IMO it was ignored because > the make command generating the error is nested in another target: There are actually two errors from the `installrtbase` recipe: 1. `make vimtags` (line 2354) fails because of a missing `Make_all.mak`. That error is deliberately ignored because the recipe line is prefixed with a - character. No clue why the developers chose to do that. 2. `ls *.txt tags` (line 2357) fails with "No such file or directory". That one is ignored because it's in the middle of a semicolon-chained sequence of commands. The recipe line would need to start with `set -e` to abort at first error.
(In reply to Ingo van Lil from comment #4) > There are actually two errors from the `installrtbase` recipe: > > 1. `make vimtags` (line 2354) fails because of a missing `Make_all.mak`. > That error is deliberately ignored because the recipe line is prefixed > with a - character. Aha, thank you! Now I know :) > No clue why the developers chose to do that. I've looked into it deeper and IMO it is for cases when you build Vim with tiny features only, and tags would not work in that case. But instead of creating a specific target, upstream decided to ignore the error in this case. This construct is in Vim since 2004 based git history. > > 2. `ls *.txt tags` (line 2357) fails with "No such file or directory". > That one is ignored because it's in the middle of a semicolon-chained > sequence of commands. The recipe line would need to start with `set -e` to > abort at first error. Here it is probably the same reason as previous - it won't work with tiny set of features, so errors are ignored for this case. Either way, I sent fix upstream https://github.com/vim/vim/pull/13551 .
FEDORA-2023-eec2cdb7ed has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-eec2cdb7ed
FEDORA-2023-45cf2b4014 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-45cf2b4014
FEDORA-2023-ce3f7d4818 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ce3f7d4818
FEDORA-2023-eec2cdb7ed has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-eec2cdb7ed` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-eec2cdb7ed See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-45cf2b4014 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-45cf2b4014` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-45cf2b4014 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ce3f7d4818 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ce3f7d4818` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ce3f7d4818 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-45cf2b4014 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-eec2cdb7ed has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-ce3f7d4818 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.