Description of problem: $ rpm -qf /usr/share/man/en_GB/ filesystem-3.1-2.fc18.x86_64 wesnoth-data-1.10.5-3.fc18.noarch Version-Release number of selected component (if applicable): wesnoth-data-1.10.5-3.fc18.noarch How reproducible: Always. Steps to Reproduce: 1. $ sudo yum install wesnoth-data 2. $ rpm -qf /usr/share/man/en_GB/ Actual results: /usr/share/man/en_GB/ is owned by wesnoth-data and filesystem: $ rpm -qf /usr/share/man/en_GB/ filesystem-3.1-2.fc18.x86_64 wesnoth-data-1.10.5-3.fc18.noarch Expected results: /usr/share/man/en_GB/ is owned by filesystem alone. Additional info: New bug per Bug 905379, Comment 7: Bug 905379 - Man-pages of wesnoth are in wrong directories and not gzipped
Fixed in rawhide, builds for f19 and f18 are coming. It's a big package. :)
wesnoth-1.10.6-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/wesnoth-1.10.6-4.fc19
wesnoth-1.10.6-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/wesnoth-1.10.6-4.fc18
There are some empty directories that are still owned by wesnoth-data: [joeblow@f18-test-1 tmp]$ rpm -qf /usr/share/man/en_GB/man1 filesystem-3.1-2.fc18.x86_64 [joeblow@f18-test-1 tmp]$ rpm -qf /usr/share/man/en_GB/man6 filesystem-3.1-2.fc18.x86_64 wesnoth-data-1.10.6-4.fc18.noarch [joeblow@f18-test-1 tmp]$ ls /usr/share/man/en_GB/man1 [joeblow@f18-test-1 tmp]$ ls /usr/share/man/en_GB/man6 [joeblow@f18-test-1 tmp]$ rpm -qa 'wes*' | sort wesnoth-1.10.6-4.fc18.x86_64 wesnoth-data-1.10.6-4.fc18.noarch The package doesn't have them, though: [joeblow@f18-test-1 tmp]$ rpm -ql westnoth-data | grep man1 [joeblow@f18-test-1 tmp]$ rpm -ql westnoth-data | grep man6 For testing, I first installed wesnoth-data from updates and then ran yum update on the new rpms: [joeblow@f18-test-1 tmp]$ sudo grep wesnoth /var/log/yum.log Jul 25 01:07:30 Installed: wesnoth-data-1.10.5-3.fc18.noarch Jul 25 01:07:36 Installed: wesnoth-1.10.5-3.fc18.x86_64 Jul 25 01:42:49 Erased: wesnoth-data-1.10.5-3.fc18.noarch Jul 25 01:42:51 Erased: wesnoth-1.10.5-3.fc18.x86_64 Jul 26 09:04:14 Installed: wesnoth-data-1.10.5-3.fc18.noarch Jul 26 09:04:20 Installed: wesnoth-1.10.5-3.fc18.x86_64 Jul 26 09:18:51 Updated: wesnoth-1.10.6-4.fc18.x86_64 Jul 26 09:19:36 Updated: wesnoth-data-1.10.6-4.fc18.noarch
[joeblow@f18-test-1 tmp]$ rpm -ql westnoth-data | grep man1 Should be [joeblow@f18-test-1 tmp]$ rpm -ql wesnoth-data | grep man1
Thanks for pointing that out: [joeblow@f18-test-1 ~]$ rpm -ql wesnoth-data | grep man1 | wc -l 0 [joeblow@f18-test-1 ~]$ rpm -ql wesnoth-data | grep man6 | wc -l 28
Package wesnoth-1.10.6-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing wesnoth-1.10.6-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13701/wesnoth-1.10.6-4.fc18 then log in and leave karma (feedback).
Here is a comprehensive test of man page and man directory ownership: $ rpm -qf $(rpm -ql wesnoth-data | grep /usr/share/man) | sort -u filesystem-3.2-13.fc19.x86_64 wesnoth-data-1.10.6-4.fc19.noarch
(In reply to Steve Tyler from comment #8) > Here is a comprehensive test of man page and man directory ownership: > > $ rpm -qf $(rpm -ql wesnoth-data | grep /usr/share/man) | sort -u > filesystem-3.2-13.fc19.x86_64 > wesnoth-data-1.10.6-4.fc19.noarch Based on this result, the bug state should be returned to ASSIGNED.
wesnoth-data-1.10.6-7 does not fix the man page ownership problem: # rpm -qf $(rpm -ql wesnoth-data | grep /usr/share/man) | sort -u filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch
I think it's this one: # rpm -qf /usr/share/man/man6 filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch The spec file has: %{_mandir}/man6 I know zero about spec files, but maybe that should be: %{_mandir}/man6/*
The spec file is listing all 28 man directories. This is going to break, if upstream adds translation number 29. Isn't there a more robust way to do this? Snippet from wesnoth.spec: http://pkgs.fedoraproject.org/cgit/wesnoth.git/plain/wesnoth.spec ... %{_mandir}/cs/* %{_mandir}/de/* %{_mandir}/en_GB/* %{_mandir}/es/* %{_mandir}/et/* %{_mandir}/fi/* %{_mandir}/fr/* %{_mandir}/gl/* %{_mandir}/hu/* %{_mandir}/id/* %{_mandir}/it/* %{_mandir}/ja/* %{_mandir}/lt/* %{_mandir}/man6 %{_mandir}/pl/* %{_mandir}/pt/* %{_mandir}/pt_BR/* %{_mandir}/ru/* %{_mandir}/sk/* %{_mandir}/sr/* %{_mandir}/sr@ijekavian/* %{_mandir}/sr@ijekavianlatin/* %{_mandir}/sr@latin/* %{_mandir}/tr/* %{_mandir}/uk/* %{_mandir}/vi/* %{_mandir}/zh_CN/* %{_mandir}/zh_TW/* ...
Created attachment 781344 [details] find-man-page-owners-1.sh shell script to find owners for all man pages in /usr/share/man Usage: $ ./find-man-page-owners-1.sh > man-page-owners-1.txt
Created attachment 781345 [details] man-page-ownership-4.txt This is a list of owners for each man page and man directory in a minimal system with wesnoth-data installed. The 28 man6 directories are all owned by wesnoth-data and filesystem: $ cat man-page-ownership-4.txt | grep wesnoth | grep filesystem | wc -l 28 $ cat man-page-ownership-4.txt | grep wesnoth | grep filesystem /usr/share/man/sr/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/en_GB/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/sr@ijekavian/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/it/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/cs/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/sr@ijekavianlatin/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/sk/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/hu/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/id/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/fi/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/pt/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/es/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/gl/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/pl/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/de/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/et/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/uk/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/ja/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/sr@latin/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/pt_BR/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/fr/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/lt/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/zh_CN/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/vi/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/tr/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/zh_TW/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch /usr/share/man/ru/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch
The 28 directories include /usr/share/man/man6: /usr/share/man/man6: filesystem-3.2-17.fc20.x86_64 wesnoth-data-1.10.6-7.fc20.noarch
This might work: %{_mandir}/man6/* %{_mandir}/*/man6/* How to create an RPM package SPEC file overview https://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview Examples from git: http://pkgs.fedoraproject.org/cgit/NetworkManager.git/tree/NetworkManager.spec %{_mandir}/man1/* %{_mandir}/man5/* %{_mandir}/man8/* http://pkgs.fedoraproject.org/cgit/coreutils.git/tree/coreutils.spec %{_mandir}/man*/* http://pkgs.fedoraproject.org/cgit/man-pages.git/tree/man-pages.spec %{_mandir}/man*/* %lang(en) %{_mandir}/en/man*/* http://pkgs.fedoraproject.org/cgit/man-pages-fr.git/tree/man-pages-fr.spec %{_mandir}/fr/man?/*
Created attachment 781375 [details] proposed wesnoth-1.10.6-6-man-page-ownership-1.patch Proposed patch to fix man page ownership. Disclaimer: This is completely untested.
Ok, the RPMs at http://fedorapeople.org/~limb/wesnoth/ have been updated.
(In reply to Jon Ciesla from comment #18) > Ok, the RPMs at http://fedorapeople.org/~limb/wesnoth/ have been updated. Thanks.
Created attachment 781653 [details] man-page-ownership-5.txt This looks good: No man files or directories have wesnoth and filesystem as owners. No man page directories are owned by wesnoth. There are 53 man page files owned by wesnoth. $ cat man-page-ownership-5.txt | grep wesnoth | grep filesystem | wc -l 0 $ cat man-page-ownership-5.txt | grep wesnoth | grep '^d' | wc -l 0 $ cat man-page-ownership-5.txt | grep wesnoth | grep -v '^d' | wc -l 53 $ cat man-page-ownership-5.txt | grep filesystem | wc -l 148
I was supposed to be checking with wesnoth-data, but the results are the same. Let me know when you start a koji build. $ cat man-page-ownership-5.txt | grep wesnoth-data | grep filesystem | wc -l 0 $ cat man-page-ownership-5.txt | grep wesnoth-data | wc -l 53
Excellent, I'll get this out. Thanks for your help!
wesnoth-1.10.6-7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/wesnoth-1.10.6-7.fc19
wesnoth-1.10.6-7.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/wesnoth-1.10.6-7.fc18
wesnoth-1.10.6-7.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
wesnoth-1.10.6-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.