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=688315 --- Comment #6 from Chris Lalancette <clalance@xxxxxxxxxx> 2011-07-07 10:49:21 EDT --- (In reply to comment #4) > [ OK ] MUST: rpmlint must be run on every package > [ OK ] MUST: The package must be named according to the Package Naming > Guidelines > [ OK ] MUST: The spec file name must match the base package %{name} [...] > [ ?? ] MUST: The package must meet the Packaging Guidelines > > Possible fail, use of %define, guidelines say use of %global is preferred. (Did > gem2rpm do this?) Ruby packaging guidelines seem to be not applicable to gems; > is that correct? Right, I didn't know about that guideline. I'll update it. And yes, gem2rpm did do the %define. I think we really need to update gem2rpm to conform to some of these new requirements, but -ENOTIME. > > [ OK ] MUST: The package must be licensed with a Fedora approved license > and meet the Licensing Guidelines > [ FAIL ] MUST: The License field in the package spec file must match the > actual license > > Spec says GPLV2+ or Ruby. README.rdoc in the gem->data.tar.gz says MIT. Yep, good catch. Fixed. > > N.B. file timestamps in the gem (tar file) and the embedded data.tar.gz are > 1969-12-31. Tar on my f14 box is silent, tar on my f15 box whines. Hm, odd. On my system, both the SRPM and the gem file both have valid timestamps. I wonder what the deal there is. > > [ OK ] MUST: If (and only if) the source package includes the text of the > license(s) in its own file, then that file, containing the text of > the license(s) for the package must be included in %doc > [ OK ] MUST: The spec file must be written in American English. > [ OK ] MUST: The spec file for the package MUST be legible. > [ OK ] MUST: The sources used to build the package must match the upstream > source, as provided in the spec URL. Reviewers should use md5sum for > this task. If no upstream URL can be specified for this package, > please see the Source URL Guidelines for how to deal with this. > [ OK ] MUST: The package MUST successfully compile and build into binary > rpms on at least one primary architecture > [ N/A ] MUST: If the package does not successfully compile, build or work on > an architecture, then those architectures should be listed in the > spec in ExcludeArch. Each architecture listed in ExcludeArch MUST > have a bug filed in bugzilla, describing the reason that the package > does not compile/build/work on that architecture. The bug number MUST > be placed in a comment, next to the corresponding ExcludeArch line > [ OK ] MUST: All build dependencies must be listed in BuildRequires, except > for any that are listed in the exceptions section of the Packaging > Guidelines ; inclusion of those as BuildRequires is optional. Apply > common sense. > [ OK ] MUST: The spec file MUST handle locales properly. This is done by > using the %find_lang macro. Using %{_datadir}/locale/* is strictly > forbidden > [ N/A ] MUST: Every binary RPM package (or subpackage) which stores shared > library files (not just symlinks) in any of the dynamic linker's > default paths, must call ldconfig in %post and %postun. > [ N/A ] MUST: If the package is designed to be relocatable, the packager must > state this fact in the request for review, along with the > rationalization for relocation of that specific package. Without > this, use of Prefix: /usr is considered a blocker. > [ OK ] MUST: A package must own all directories that it creates. If it does > not create a directory that it uses, then it should require a package > which does create that directory. > [ OK ] MUST: A package must not contain any duplicate files in the %files > listing. > [ FAIL ] MUST: Each package must consistently use macros. > > use %{_mkdir}, %{_cp}, and %{_rm} instead of mkdir, cp, and rm respectively. > (Is this another gem2rpm bug?) Hm. https://fedoraproject.org/wiki/Packaging:Guidelines#Macros says: "Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, rm should be used in preference to %{__rm}, but %{__python} is acceptable." I left the rm, mkdir, and cp as-is based on that. > > [ OK ] MUST: The package must contain code, or permissable content. > [ OK ] MUST: Large documentation files must go in a -doc subpackage. (The > definition of large is left up to the packager's best judgement, but > is not restricted to size. Large can refer to either size or > quantity). > [ OK ] MUST: If a package includes something as %doc, it must not affect the > runtime of the application. To summarize: If it is in %doc, the > program must run properly if it is not present. > [ N/A ] MUST: Header files must be in a -devel package. > [ N/A ] MUST: Static libraries must be in a -static package. > [ N/A ] MUST: Packages containing pkgconfig(.pc) files must 'Requires: > pkgconfig' (for directory ownership and usability). > [ N/A ] MUST: If a package contains library files with a suffix (e.g. > libfoo.so.1.1), then library files that end in .so (without suffix) > must go in a -devel package. > [ N/A ] MUST: In the vast majority of cases, devel packages must require the > base package using a fully versioned dependency: Requires: %{name} = > %{version}-%{release} > [ N/A ] MUST: Packages must NOT contain any .la libtool archives, these must > be removed in the spec if they are built. > [ N/A ] MUST: Packages containing GUI applications must include a > %{name}.desktop file, and that file must be properly installed with > desktop-file-install in the %install section. If you feel that your > packaged GUI application does not need a .desktop file, you must put > a comment in the spec file with your explanation. > [ OK ] MUST: Packages must not own files or directories already owned by > other packages. The rule of thumb here is that the first package to > be installed should own the files or directories that other packages > may rely upon. This means, for example, that no package in Fedora > should ever share ownership with any of the files or directories > owned by the filesystem or man package. If you feel that you have a > good reason to own a file or directory that another package owns, > then please present that at package review time. > [ OK ] MUST: At the beginning of %install, each package MUST run rm -rf > %{buildroot} (or $RPM_BUILD_ROOT). > [ OK ] MUST: All filenames in rpm packages must be valid UTF-8. > [ ? ] SHOULD query upstream to include it. > [ N/A ] SHOULD: The description and summary sections in the package spec file > should contain translations for supported Non-English languages, if > available. > [ OK ] SHOULD: The reviewer should test that the package builds in mock. > > x86-64 and i386 tested. > > [ SKIP ] SHOULD: The package should compile and build into binary rpms on all > supported architectures. > [ SKIP ] SHOULD: The reviewer should test that the package functions as > described. A package should not segfault instead of running, for > example. > [ N/A ] SHOULD: If scriptlets are used, those scriptlets must be sane. This is > vague, and left up to the reviewers judgement to determine sanity. > [ N/A ] SHOULD: Usually, subpackages other than devel should require the base > package using a fully versioned dependency. > [ N/A ] SHOULD: The placement of pkgconfig(.pc) files depends on their > usecase, and this is usually for development purposes, so should be > placed in a -devel pkg. A reasonable exception is that the main pkg > itself is a devel tool not installed in a user runtime, e.g. gcc or > gdb. > [ N/A ] SHOULD: If the package has file dependencies outside of /etc, /bin, > /sbin, /usr/bin, or /usr/sbin consider requiring the package which > provides the file instead of the file itself. > [ ] SHOULD: your package should contain man pages for binaries/scripts. If > it doesn't, work with upstream to add them where they make sense.[34] I think the rest is fine. I've uploaded new versions of the package to the same place as the initial comment. Can you take a look? Once you are satisfied, the next step would be to change the fedora-review flag to +, but it seems like you are having trouble doing that. I would recommend emailing the bugzilla maintainers (bugzilla-owner@xxxxxxxxxx, I think) to see what the deal is. Thanks for the review, Chris Lalancette -- 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