Spec URL: http://axilleas.fedorapeople.org/pkgs/rubygem-bootstrap-sass/rubygem-bootstrap-sass.spec SRPM URL: http://axilleas.fedorapeople.org/pkgs/rubygem-bootstrap-sass/rubygem-bootstrap-sass-2.3.2.0-1.fc20.src.rpm Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5587949 Description: Twitter's Bootstrap, converted to Sass and ready to drop into Rails or Compass Fedora Account System Username: axilleas rpmlint gives only: rubygem-bootstrap-sass.src: W: invalid-url Source1: rubygem-bootstrap-sass-2.3.2.0-test.tgz which I think is safe to ignore :)
I'm working on a review, but I have two questions. Bundling: It has a /vendor/ directory, that has the twitter bootstrap code in it. Normally this screams "bundling". But, this is what it says in the packaging guidelines "At this time JavaScript intended to be served to a web browser on another computer is specifically exempted from this but this will likely change in the future." https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries "Twitter" in the summary and description: I'm always nervous about putting a trademarked name in a summary and/or description. I liked what a previous review attempt had for theirs. https://raw.github.com/mojavelinux/rubygem-bootstrap-sass-rpm/master/rubygem-bootstrap-sass.spec Thoughts on either of these items?
(In reply to Troy Dawson from comment #1) > I'm working on a review, but I have two questions. > > Bundling: > It has a /vendor/ directory, that has the twitter bootstrap code in it. > Normally this screams "bundling". > But, this is what it says in the packaging guidelines > "At this time JavaScript intended to be served to a web browser on another > computer is specifically exempted from this but this will likely change in > the future." > https://fedoraproject.org/wiki/Packaging: > Guidelines#Duplication_of_system_libraries > I guess we could ship the vendor/assets/{javascripts,images} in the doc subpackage, since they provide the same files as Twitter's bootstrap. Or exclude them completely, although am in favor of the subpackage approach. As for the css, Twitter ships its files in less whereas bootstrap-sass is in sass, so I think it's safe to say that vendor/assets/stylesheets is not considered as duplicate. That's what this package is after all, right? > "Twitter" in the summary and description: > I'm always nervous about putting a trademarked name in a summary and/or > description. I liked what a previous review attempt had for theirs. > https://raw.github.com/mojavelinux/rubygem-bootstrap-sass-rpm/master/rubygem- > bootstrap-sass.spec > It is Twitter that introduced this framework and the title kinda distincts it from the classic bootstrap definition[0], but I guess the first thing that comes to mind when saying bootstrap in our geek world, is Twitter. So, picking a less "invasive" description is fine by me :) I just didn't know that we could use a description different than what is defined in the gemspec by upstream. On a separate note, I realized that Dan had included two patches in his spec, but I haven't checked if they are needed... [0] https://en.wikipedia.org/wiki/Bootstrapping
(In reply to Axilleas Pipinellis from comment #2) > (In reply to Troy Dawson from comment #1) > > I'm working on a review, but I have two questions. > > > > Bundling: > > It has a /vendor/ directory, that has the twitter bootstrap code in it. > > Normally this screams "bundling". > > But, this is what it says in the packaging guidelines > > "At this time JavaScript intended to be served to a web browser on another > > computer is specifically exempted from this but this will likely change in > > the future." > > https://fedoraproject.org/wiki/Packaging: > > Guidelines#Duplication_of_system_libraries > > > > I guess we could ship the vendor/assets/{javascripts,images} in the doc > subpackage, since they provide the same files as Twitter's bootstrap. Or > exclude them completely, although am in favor of the subpackage approach. > > As for the css, Twitter ships its files in less whereas bootstrap-sass is in > sass, so I think it's safe to say that vendor/assets/stylesheets is not > considered as duplicate. That's what this package is after all, right? > I believe you are correct. It isn't bundling if this is the package that is supposed to supply ... whatever it is we are bundling. (In this case, the Twitter bootstrap in Saas form.) > > "Twitter" in the summary and description: > > I'm always nervous about putting a trademarked name in a summary and/or > > description. I liked what a previous review attempt had for theirs. > > https://raw.github.com/mojavelinux/rubygem-bootstrap-sass-rpm/master/rubygem- > > bootstrap-sass.spec > > > > It is Twitter that introduced this framework and the title kinda distincts > it from the classic bootstrap definition[0], but I guess the first thing > that comes to mind when saying bootstrap in our geek world, is Twitter. So, > picking a less "invasive" description is fine by me :) I just didn't know > that we could use a description different than what is defined in the > gemspec by upstream. > You are correct again. Use Twitter in the summary if you wish, because as you said, this is the Twitter bootstrap, not some other bootstrap. As for the description being different than what is defined in the upstream gemspec. Yes, you can change it. Especially when the summary and description are the same. Feel free to expand the description, or shrink the summary. > On a separate note, I realized that Dan had included two patches in his > spec, but I haven't checked if they are needed... > Two patches and a sed to gemspec. I'm pretty sure the sed and the first patch are needed if this is going to go into EPEL and/or Fedora 18. I don't know about the second patch.
Hey Troy, sorry for the late response. I have sent an email with my concerns on ruby-sig[0], let our discussion continue there :) [0] https://lists.fedoraproject.org/pipermail/ruby-sig/2013-July/001387.html
So, it sounds like the consensus is to leave it bundled until the Javascript policies are finalized and approved. So, the question is. Do you want me to review this with what you have, or did you want to check the patches you mentioned in Comment 2?
I missed the comment Dan had written in his spec, that the patches are needed for distros with Sass < 3.2. We currently have 3.2.6-1 so that doesn't apply to our case. I would say you review this as is. I tested it again and it loads fine in irb. Again, if you feel I should change something in summary/description, do say so.
You can change the subject and/or description if you want to. That was just a personal preference item. I will review it as it is, which looks good.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= 1 - The bundled code is javascript, and so falls under the JavaScript Exception. ===== MUST items ===== Generic: [X]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [X-1]: Package contains no bundled libraries without FPC exception. [X]: Changelog in prescribed format. [X]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [X]: Package requires other packages for directories it uses. [X]: Package uses nothing in %doc for runtime. [X]: Package is not known to require ExcludeArch. [X]: Fully versioned dependency in subpackages, if present. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in rubygem- bootstrap-sass-doc ?? Yes there is [X]: Package complies to the Packaging Guidelines [X]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated". 7 files have unknown license. Detailed output of licensecheck in /home/quake/review/rubygem-bootstrap-sass/982679-rubygem- bootstrap-sass/licensecheck.txt [X]: License file installed when any subpackage combination is installed. [X]: Package consistently uses macro is (instead of hard-coded directory names). [X]: Package is named according to the Package Naming Guidelines. [X]: Package does not generate any conflict. [X]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [X]: Package must own all directories that it creates. [X]: Package does not own files or directories owned by other packages. [X]: Requires correct, justified where necessary. [X]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Each %files section contains %defattr if rpm < 4.4 [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: 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 is included in %doc. [x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package do not use a name that already exist [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Large documentation must go in a -doc subpackage. Note: Documentation size is 0 bytes in 0 files. [x]: Packages must not store files under /srv, /opt or /usr/local [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: No rpmlint messages. Ruby: [X]: Platform dependent files must all go under %{gem_extdir}, platform independent under %{gem_dir}. [x]: Gem package must not define a non-gem subpackage [x]: Gem package is named rubygem-%{gem_name} [x]: Package contains BuildRequires: rubygems-devel. [x]: Gem package must define %{gem_name} macro. [x]: Pure Ruby package must be built as noarch ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [X]: Final provides and requires are sane (see attachments). [X]: Package functions as described. [X]: Latest version is packaged. [X]: Package does not include license text files separate from upstream. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [X]: Package should compile and build into binary rpms on all supported architectures. [X]: %check is present and all tests pass. [X]: Packages should try to preserve timestamps of original installed files. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: Dist tag is present. [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: SourceX tarball generation or download is documented. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define. Ruby: [X]: Specfile should use macros from rubygem-devel package. [X]: Test suite of the library should be run. [x]: Gem package should exclude cached Gem. ===== EXTRA items ===== Generic: [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: rubygem-bootstrap-sass-2.3.2.0-1.fc20.noarch.rpm rubygem-bootstrap-sass-doc-2.3.2.0-1.fc20.noarch.rpm 2 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- # rpmlint rubygem-bootstrap-sass-doc rubygem-bootstrap-sass 2 packages and 0 specfiles checked; 0 errors, 0 warnings. # echo 'rpmlint-done:' Requires -------- rubygem-bootstrap-sass-doc (rpmlib, GLIBC filtered): rubygem-bootstrap-sass rubygem-bootstrap-sass (rpmlib, GLIBC filtered): ruby(release) ruby(rubygems) rubygem(sass) Provides -------- rubygem-bootstrap-sass-doc: rubygem-bootstrap-sass-doc rubygem-bootstrap-sass: rubygem(bootstrap-sass) rubygem-bootstrap-sass Source checksums ---------------- https://rubygems.org/gems/bootstrap-sass-2.3.2.0.gem : CHECKSUM(SHA256) this package : c3a590d613f563fa138224e89d3765fc3f34c6a99ebc8fdd80993e5094dca6fd CHECKSUM(SHA256) upstream package : c3a590d613f563fa138224e89d3765fc3f34c6a99ebc8fdd80993e5094dca6fd Generated by fedora-review 0.4.1 (b2e211f) last change: 2013-04-29 Buildroot used: fedora-rawhide-x86_64 Command line :/usr/bin/fedora-review -b 982679
APPROVED
New Package SCM Request ======================= Package Name: rubygem-bootstrap-sass Short Description: Twitter's Bootstrap, converted to Sass Owners: axilleas Branches: f19 InitialCC:
Git done (by process-git-requests).
rubygem-bootstrap-sass-2.3.2.1-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/rubygem-bootstrap-sass-2.3.2.1-1.fc19
rubygem-bootstrap-sass-2.3.2.1-1.fc19 has been pushed to the Fedora 19 testing repository.
rubygem-bootstrap-sass-2.3.2.1-1.fc19 has been pushed to the Fedora 19 stable repository.