Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=879568 --- Comment #2 from Michael Scherer <misc@xxxxxxxx> --- So, a few notes : %clean rm -rf %{buildroot} this part is no longer needed, rpm does it by default. So this is cleaner to not add this. See http://fedoraproject.org/wiki/Packaging:Guidelines#.25clean rm -rf %{buildroot} same as above, already done by rpm. See http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag Unless if you plan to have a package for RHEL 5 or similar, this can be removed, as weel as the BuildRoot tag in the header. %defattr(-,root,root,-) same, that's the default since a few version of rpm. This can be safely removed : http://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions Since there is no tarball, there is no need to have %setup %setup -q -c -T so you can remove %prep section all together ( even if rpmlint will complain ) Any package should have the license, and there is none. See http://fedoraproject.org/wiki/Packaging:LicensingGuidelines There is no reason why the license would GPLv2 ( since that's written nowhere ), and if this is GPL, you need to distribute the text of the license with it. While for this precise case of configuration file, this is a little bit weird ( and just done to show the process ), the same apply to a regular software. IE, the reviewer need to be able to why this is under the license written in the tag ( usually, there is a file with the source code, or there is note in the source code ), and the license should be present when installing the package. # Epoch incremented to 1 so that it is seen as an upgrade over xs-release-9 (XS-0.6) Epoch: 1 Usually, we try to avoid Epoch ( as this produce subtle interactions issues ), but for this one, why is xs-release using a different version number ( ie, if this was 9 before, why is it 6 now ) ? And I am not sure we should care about non fedora package. URL: http://wiki.laptop.org Source0: olpcxs.repo Source1: olpcxs-testing.repo we usually need to know where the file come from. While for this case, we can say they were written by the packager, usually, the url where to find them, or a comment explaining how to update the file should be added. ( again, this package is not really the best example, so I does not really make sense for this specific packages ) Finally, some of us ( me included ) use a tool called fedora-review ( https://fedorahosted.org/FedoraReview/ ) for reviewing packages ( see https://bugzilla.redhat.com/show_bug.cgi?id=869861 for a recent example review ). And this tool wrk best when the url to the package are directly downloadable. using dropbox force us to download the file by the browser to then run the tool. So if you could either use something else than dropbox, or put the direct link in the next review request ( if this exist, of course ), this would be better. Usually, after that, the reviewer wait for a new version of the spec and srpm with the correction of the issue noted. ( ie, just add a comment saying "I fixed this and this, and the new version of the spec is here, the new srpm is here" ) Then the spec is inspected again and checked against a checklist ( the part done by fedora-review tools ) and if there is more issues, explain them and wait again. until the package is seen as non suitable for Fedora ( due to unfixable issues such as license problem, etc ), or until the packager change his mind, or until the package is ready to be packaged, where the process continue. In your case, as you need a sponsor, there is another step, ie finding a sponsor. Hope this help -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review