Spec Name or Url: http://www.math.uh.edu/~tibbs/rpms/swaks/swaks.spec SRPM Name or Url: http://www.math.uh.edu/~tibbs/rpms/swaks/swaks-20050709.1-1.src.rpm Description: Swiss Army Knife SMTP: A command line SMTP tester. Swaks can test various aspects of your SMTP server, including TLS and AUTH. This package is about as simple as it gets. rpmlint says: W: swaks non-standard-group Utilities E: swaks no-signature At least one package in FC4 is in the Utilities group so I'm not sure why it's nonstandard, but I'll happily change if someone suggests an appropriate group. Note that this program alters its functionality depending on what Perl modules are installed. Technically no non-core modules are requred, but most of the functionality of the program is missing. I have elected to Requires: three modules which are already in Core+Extras (Net::DNS, Time::HiRes, Net::SSLeay).
(In reply to comment #0) > rpmlint says: > W: swaks non-standard-group Utilities > > At least one package in FC4 is in the Utilities group so I'm not sure why it's nonstandard, but I'll happily change if someone suggests an appropriate group. I found a list of valid groups at http://www.fedoraproject.org/wiki/RPMGroups From that list, Applications/Internet looks appropriate to me.
The list of groups used in FC-4 is nearly twice as long (51 groups) so that page must be out of date. I'll do some editing. In any case, Applications/Internet seems reasonable, although a having a 50K Perl script in the same group as Mozilla seems comical. http://www.math.uh.edu/~tibbs/rpms/swaks/swaks.spec http://www.math.uh.edu/~tibbs/rpms/swaks/swaks-20050709.1-2.src.rpm
> The list of groups used in FC-4 is nearly twice as long Doesn't say anything about whether it might be even more out-of-date or better to choose from. Unless FC offers a well-maintained list of official groups, the RPM Group tag is only old cruft which doesn't permit good and convenient classification of packages into groups. It seems to me some packagers have made up their own groups without adhering to any existing tree-like structure, creating new branches only if old branches become too crowded. E.g. Text Processing/Markup/XML is used, but "Text Processing" and "Text Processing/Markup" are not. This is a questionable decision.
I'm not sure how your comments relate to the review of the swaks package. Are you contesting the choice of the Applications/Internet group? If so, please feel free to suggest something more appropriate.
Jason, you've beaten me to it: I was going to submit swaks :) Thanks for this package submission. A few small comments: 1. I think that Source0 should be http://jetmore.org/john/code/swaks.%{version} not http://jetmore.org/john/code/swaks as presumably the latter always points to the latest version, making it invalid as new versions roll in. 2. In my own packaging of this I have the following deps in addition to the ones you have: - perl(MIME::Base64) - perl(Digest::MD5) - perl(Authen::NTLM) - perl(Authen::DigestMD5) Now, these aren't strictly required to be able to use swaks, but they are required to implement all of the advertised functionality, and without them you will get some fairly ungraceful errors when you try to do various things. Therefore, I think they should be deps. In fact, the reason why I didn't submit the swaks spec myself earlier is because one or two of the above (at least Authen::NTLM IIRC) are not currently in FC/FE so they need submitting first. This harks back to a discussion I initiated in Jan on fedora-extras-list about "optional" deps: http://marc.theaimsgroup.com/?l=fedora-extras-list&m=113683046628533 3. Does the package need a BR on /usr/bin/pod2man or is that one of the implicit prereqs?
His distribution is a bit unorthodox; I wasn't aware that I could grab a particular version. Fixed. Mime::Base64 and Digest::MD5 are both part of base perl and so it would be against the packaging guidelines to BuildRequire: them. (pod2man is part of perl as well.) As neither Authen::NTLM and Authen::DigestMD5 are in Core or Extras, requiring them would be a complete blocker. I can of course rebuild the package to require them if they ever make it into the distro. The program still works fine and is useful without them, so not including them is not a blocker as far as I can tell from my reading of the packaging guidelines. Updated spec and src.rpm are in http://www.math.uh.edu/~tibbs/rpms/swaks/
A few suggestions : - Remove "A" from the summary : "Command-line SMTP transaction tester" - Use "Buildarch:" insted of longer "BuildArchitectures:", as your headers will look nicer and all aligned :-) - You could use "install -D -p -m 0755 %{SOURCE0} etc." instead of mkdir/cp/chmod - No need to tag man pages as %doc, rpm does that by itself - The forced %attr for the script is redundant with the chmod from %install All the rest looks good. Let me know if you fix some of the above and I can then do a formal review.
Thanks for the comments. Updated spec: http://www.math.uh.edu/~tibbs/rpms/swaks/swaks.spec Updated SRPM: http://www.math.uh.edu/~tibbs/rpms/swaks/swaks-20050709.1-4.src.rpm
In case it wasn't clear, I addressed all five of your concerns with the updated package.
Review: - rpmlint clean - package and spec naming OK - package meets guidelines - license is GPL, matches spec - spec file written in English and is legible - source matches upstream - package builds OK on FC5 and in mock for rawhide (i386) - no explicit BR's needed nor present - no locales, libraries, sub-packages, or pkgconfigs to worry about - not relocatable - no directory ownership or permissions issues - no duplicate files - %clean section present and correct - macro usage is consistent - code not content - no large docs - docs don't affect runtime - no desktop file needed - package appears to work OK - no scriptlets Notes: NTLM Auth requires Authen::NTLM from the NTLM perl distribution, which does not (despite what the first sentence of the license terms says) appear to be free software and is hence unlikely to get packaged for Extras. Digest-MD5 Auth requires Authen::DigestMD5, which will be available in Extras shortly after someone approves Bug #191494 (hint ;-) ) Approved.
I added the Authen::DigestMD5 dependency, imported, built and requested branches. Thanks!
Package Change Request ====================== Package Name: swaks New Branches: el4 el5 el6 Owners: mmckinst InitialCC: tibbs I eamiled Jason about swaks in EPEL. He is not interested in maintaining the EPEL branches but is fine with me maintaining them.
(I'd prefer not to be CC'd on EPEL bugs, thanks.) Git done (by process-git-requests).
swaks-20100211.0-4.el4 has been submitted as an update for Fedora EPEL 4. https://admin.fedoraproject.org/updates/swaks-20100211.0-4.el4
swaks-20100211.0-4.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/swaks-20100211.0-4.el5
swaks-20100211.0-4.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/swaks-20100211.0-4.el6
swaks-20100211.0-4.el5 has been pushed to the Fedora EPEL 5 stable repository.
swaks-20100211.0-4.el4 has been pushed to the Fedora EPEL 4 stable repository.
swaks-20100211.0-4.el6 has been pushed to the Fedora EPEL 6 stable repository.
Package Change Request ====================== Package Name: fpdns New Branches: epel7 Owners: mmckinst
Git done (by process-git-requests).
typoed that last request. should've been for swaks not fpdns. Package Change Request ====================== Package Name: swaks New Branches: epel7 Owners: mmckinst