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=810010 --- Comment #7 from Thomas Spura <tomspur@xxxxxxxxxxxxxxxxx> 2012-04-12 08:00:51 EDT --- (In reply to comment #6) > Updated the URLs above with the changes recommended. I also checked out EPEL > and that seems to work as well. Great, looks much better now :) (A newline between every changelog and it would be fabulous :)) > 1. Apparently libgenders.so.0.3.0 calls exit(). This in case flex can't parse > the primary genders config file. So I don't blame them for this since the > entire library is useless in the condition the config file is wrong. It would be best to report that upstream and suggesting the same like "rpmlint -I": """ It is preferred for the library to return an actual error code and let the calling program decide how to handle the situation. """ > 2. There's a hardcoded library path in the spec %{_prefix}/lib/genders. This > is where the compat libraries live. The automake also has this same hard coded > library path and the files put there are old perl scripts. So I'm open for > suggestions on what the 'right' thing to do is with these files. Could go out > in %{_datadir}/%{name}? arch dependent files need to be in %{_libdir}/%{name}, but these are perl files, so %{_datadir}/%{name} would be correct from packaging point of view. BUT: It would be best to patch that directly and send it upstream and while looking at this, I found this in genders-1.18/compat/Makefile.am: """ # Don't use ${libdir}, the /lib is a legacy path that must be maintained gendlibdir = ${prefix}/lib/genders """ So it would be best, to just leave it in %{_prefix}/lib/genders as that is the forced path by upstream... > 3. EPEL build keeps complaining about having an unspecified group. However, > its not needed when I build it on Fedora. Should I care that much? I'd add the group "Development/Tools" for any non-lib package and to the libraries "Development/Libraries". Tools, because it's a helper tool for cluster administrators and I consider a cluster always as a kind of development going on. > Also to the initial review I don't have any 'informal reviews' not sure what > they'd be and where I'd get a link for them. Once you are sponsored to the packager group you can do reviews like explained here: http://fedoraproject.org/wiki/Package_Review_Process#Reviewer But to get sponsored, we need to see, that you are familiar with the guidelines. Here you have 2 possibilities: * Put several packages for review * Do 'informal reviews', that means, you can make comments to and improve other pending reviews (preferably one that doesn't require a sponsor, because I'll look to the review after you and can so directly approve it without needing to sponsoring someone immediately). Once you are sponsored to the packager group, you can directly approve other reviews yourself. More information about that is here: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Feel free to ask, when you have further questions. (Here or via mail) -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review