Spec URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons.spec SRPM URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons-0.9.6-1.fc10.src.rpm Description: The Gettext Commons project provides Java classes for internationalization (i18n) through GNU gettext. The lightweight library combines the power of the unix-style gettext tools with the widely used Java ResourceBundles. This makes it possible to use the original text instead of arbitrary property keys, which is less cumbersome and makes programs easier to read. Rpmlint output is clean. Please note that this is my first JAVA package.
Spec URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons.spec SRPM URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons-0.9.6-2.fc10.src.rpm Changelog: * Sun Aug 09 2009 Andrea Musuruane <musuruan> 0.9.6-2 - Created JAR alias
Created attachment 357233 [details] mock build log I can't generate any rpm for gettext-commons with mock (tested on fc10 and fc11)
Spec URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons.spec SRPM URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons-0.9.6-3.fc10.src.rpm Changelog: - Fixed javadoc generation
I will take this one. A full review is forthcoming. </Cherry-Pick>
OK, I've gone through the packaging guidelines and the reviewing guidelines... Please fix the following: I cannot install the javadoc subpackage because of line 35, which reads: Requires: %{name}-%{version}-%{release} It should instead read: Requires: %{name} = %{version}-%{release} You mix $THIS_STYLE and %{this_style} variables, which is bad form so the guidelines say. You can easily fix this by replacing all instances of $RPM_BUILD_ROOT with %{buildroot} This one is your choice, but by convention javadoc is installed into a versioned directory %{buildroot}%{_javadocdir}/%{name}-%{version} and then an unversioned symlink is made %{buildroot}%{_javadocdir}/%{name} to the versioned directory. (Just like you did with the jar file.) Other points: Have you sent the javadoc.patch upstream? Seems like one they could accept easily. If you have sent this upstream, please include a link the bug report in a comment. Once you've addressed these points, I'll give it another look and then probably you're ready to go. Thanks for your submission (and thanks for waiting patiently for someone to review it) :-)
Spec URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons.spec SRPM URL: http://www.webalice.it/musuruan/RPMS/reviews/gettext-commons-0.9.6-4.fc10.src.rpm Changelog: - Submitted javadoc patch upstream - Fixed javadoc package requires - Created javadoc directory alias
(In reply to comment #5) > Please fix the following: > > I cannot install the javadoc subpackage because of line 35, which reads: > Requires: %{name}-%{version}-%{release} > It should instead read: > Requires: %{name} = %{version}-%{release} Fixed. > You mix $THIS_STYLE and %{this_style} variables, which is bad form so the > guidelines say. You can easily fix this by replacing all instances of > $RPM_BUILD_ROOT with %{buildroot} AFAIK What I did is perfectly acceptable. I didn't use both $RPM_BUILD_ROOT and %{buildroot} - I only used the first. Moreover, all other macros are in the second style because they do not have an equivalent in the first syntax. You can find a great number of spec files that do the same in Fedora CVS. > This one is your choice, but by convention javadoc is installed into a > versioned directory %{buildroot}%{_javadocdir}/%{name}-%{version} and then an > unversioned symlink is made %{buildroot}%{_javadocdir}/%{name} to the versioned > directory. (Just like you did with the jar file.) Fixed. > Other points: > > Have you sent the javadoc.patch upstream? Seems like one they could accept > easily. If you have sent this upstream, please include a link the bug report in > a comment. Submitted upstream. > Once you've addressed these points, I'll give it another look and then probably > you're ready to go. Thanks for your submission (and thanks for waiting > patiently for someone to review it) :-) Thanks _a lot_ for the review :)
(In reply to comment #7) > (In reply to comment #5) > > You mix $THIS_STYLE and %{this_style} variables, which is bad form so the > > guidelines say. You can easily fix this by replacing all instances of > > $RPM_BUILD_ROOT with %{buildroot} > > AFAIK What I did is perfectly acceptable. I didn't use both $RPM_BUILD_ROOT and > %{buildroot} - I only used the first. > > Moreover, all other macros are in the second style because they do not have an > equivalent in the first syntax. > > You can find a great number of spec files that do the same in Fedora CVS. > Fair enough. I'm happy to rubber-stamp this now. APPROVED.
New Package CVS Request ======================= Package Name: gettext-commons Short Description: Java internationalization (i18n) library Owners: musuruan Branches: F-10 F-11 InitialCC:
cvs done with F-12 branch added.
gettext-commons-0.9.6-4.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gettext-commons-0.9.6-4.fc11
gettext-commons-0.9.6-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gettext-commons-0.9.6-4.fc10
Built. Closing.
gettext-commons-0.9.6-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
gettext-commons-0.9.6-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.