Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=522933 --- Comment #11 from Michael Schwendt <mschwendt@xxxxxxxxx> 2009-09-15 11:20:11 EDT --- >From the spec file diff: -%{_datadir}/pyicq-t +%{_datadir}/pyicq-t/data Now the directory %{_datadir}/pyicq-t is no longer included: $ rpm -qf /usr/share/pyicq-t/ file /usr/share/pyicq-t is not owned by any package It can also be seen in "rpm -qlv" or "rpmls" output. Basically you would need to make sure that for every file path a 'd' entry is present: $ rpmls -p /home/qa/tmp/rpm/RPMS/pyicq-t-0.8.1.5-4.fc11.noarch.rpm|grep ^d drwx------ /etc/pyicq-t drwxr-xr-x /usr/share/doc/pyicq-t-0.8.1.5 drwxr-xr-x /usr/share/pyicq-t/data drwxr-xr-x /usr/share/pyicq-t/data/www drwxr-xr-x /usr/share/pyicq-t/data/www/css drwxr-xr-x /usr/share/pyicq-t/data/www/images drwxr-xr-x /usr/share/pyicq-t/src drwxr-xr-x /usr/share/pyicq-t/src/chardet_utf drwxr-xr-x /usr/share/pyicq-t/src/langs drwxr-xr-x /usr/share/pyicq-t/src/legacy drwxr-xr-x /usr/share/pyicq-t/src/legacy/services drwxr-xr-x /usr/share/pyicq-t/src/services drwxr-xr-x /usr/share/pyicq-t/src/tlib drwxr-xr-x /usr/share/pyicq-t/src/web drwxr-xr-x /usr/share/pyicq-t/src/xdb drwxr-xr-x /var/run/pyicq-t drwx------ /var/spool/pyicq-t => Missing is: drwxr-xr-x /usr/share/pyicq-t [...] -touch %{buildroot}/etc/pyicq-t/config.xml +cp config_example.xml %{buildroot}/etc/pyicq-t/config.xml This doesn't achieve what you think it does (according to %changelog). The problem here is that the file is made a %ghost. This also means that somebody (a person or a program) must create it after package installation, or else it won't exist like normal files. [...] The new initscript no longer displays the service name: $ sudo service pyicq-t status (pid 47117) is running... $ sudo service pyicq-t status is stopped [...] Conclusively, just as with ordinary package reviews, after a package has been included in the Fedora Package collection, you are on your own with updates which bear a risk of introducing new problems. One can beat a package to death during review, and with the next update/upgrade some packagers still add stuff that won't pass an official review. You know where to find the packaging guidelines. You are willing to study them in order to make packages adhere to them. But the guidelines don't help with all sorts of problems. In particular, they don't cover run-time issues and lack of testing. So, if I approve your account for the packager group, you can request commit access as planned. Continue to be careful. Test your changes painstakingly. It should become more easy as you're two package maintainers. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review