A. nodejs-0.10.12 has been in updates-testing for a few days and should fix at least that part of the problem.

B.  I can't approve a package with precompiled JS without FPC approval, sorry.  JQuery has been blocked for too long on the same grounds, it would be unfair to do anything else.

Oh yes, I was going to ask your advice about this package.

I've actually deleted all of the minified JS in the %prep section, so as it stands there's no precompiled JS. But of course the minified scripts are fairly important so it's less than ideal to have a package without them.

The ideal thing to do is package google-closure-compiler and fix the build script to stop fetching external sources, but I'm not sure that's something I can get done within a reasonable time frame (particularly based on the comments from the Red Hat Satellite bugzilla). But of course if that's the only option, then that's the path I will take...

Would it be acceptable to minimize them differently than is done in the build scripts? For example, minify with just uglify-js and be done with it? That might result in poorer compression etc, but I'd guess that the end result for the user mostly won't be noticeable.

Thoughts?

(In reply to Jamie Nguyen from comment #2)
> Oh yes, I was going to ask your advice about this package.
> 
> I've actually deleted all of the minified JS in the %prep section, so as it
> stands there's no precompiled JS.

Please add some comments clearly indicating the minified code has been removed and that this is the only thing that would be build by the disabled %build section.  It wasn't immediately obvious to me that this was the only problem.

With everything explained properly, I should be able to approve this.

> But of course the minified scripts are
> fairly important so it's less than ideal to have a package without them.

Are they just there for the browser?

> The ideal thing to do is package google-closure-compiler and fix the build
> script to stop fetching external sources, but I'm not sure that's something
> I can get done within a reasonable time frame (particularly based on the
> comments from the Red Hat Satellite bugzilla). But of course if that's the
> only option, then that's the path I will take...

I looked at this. The Rhino issue Stanislav mentioned two years ago [1] is still very much a problem.  :-(

> Would it be acceptable to minimize them differently than is done in the
> build scripts? For example, minify with just uglify-js and be done with it?
> That might result in poorer compression etc, but I'd guess that the end
> result for the user mostly won't be noticeable.

If they're just needed for the browser, I'd suggest omitting them at this time.  I intend to propose real honest-to-God client-side JavaScript guidelines and a corresponding F20 Feature/Change/whatever in mid-July, and whatever ends up being hashed out with FPC should provide guidance with this and many other gotchas.  Who knows, we might even work out a compromise that allows the preminified scripts.  (Fat chance, but one can dream. ;-)

uglify-js and coffee-script currently aren't shipping minified JS either so this is definitely something I want to fix, I'd just rather do so in a way that is future-proof.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=725739#c4

(In reply to T.C. Hollingsworth from comment #3)
> Please add some comments clearly indicating the minified code has been
> removed and that this is the only thing that would be build by the disabled
> %build section.  It wasn't immediately obvious to me that this was the only
> problem.
> 
> With everything explained properly, I should be able to approve this.


Ah, sorry, my fault. I got lazy :(


> > But of course the minified scripts are
> > fairly important so it's less than ideal to have a package without them.
> 
> Are they just there for the browser?

Yes, only for the browser. The module is still useful without the minified scripts.


> I looked at this. The Rhino issue Stanislav mentioned two years ago [1] is
> still very much a problem.  :-(

:(


> If they're just needed for the browser, I'd suggest omitting them at this
> time.  I intend to propose real honest-to-God client-side JavaScript
> guidelines and a corresponding F20 Feature/Change/whatever in mid-July, and
> whatever ends up being hashed out with FPC should provide guidance with this
> and many other gotchas.  Who knows, we might even work out a compromise that
> allows the preminified scripts.  (Fat chance, but one can dream. ;-)

Heh, one can indeed dream ;)


> uglify-js and coffee-script currently aren't shipping minified JS either so
> this is definitely something I want to fix, I'd just rather do so in a way
> that is future-proof.

Agreed.

Spec URL: http://jamielinux.fedorapeople.org/grunt/nodejs-lodash.spec
SRPM URL: http://jamielinux.fedorapeople.org/grunt/SRPMS/nodejs-lodash-1.3.1-2.fc19.src.rpm

%changelog
* Thu Jun 27 2013 Jamie Nguyen <jamielinux> - 1.3.1-2
- add more comments

Sorry, I forgot about this and just noticed I hadn't finished it when I was tracking down the info about the Closure Compiler for the new JS work.  :-(


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed

Status: APPROVED

===== 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]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Unknown or generated". 2 files have unknown license. Detailed output of
     licensecheck in /home/fedora/patches/FedoraReview/977132-nodejs-
     lodash/licensecheck.txt
     
        MIT in LICENSE.txt -> OK
     
[x]: 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 uses nothing in %doc for runtime.
[x]: Package consistently uses macros (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]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[!]: Package is not known to require an ExcludeArch tag.

        Please add ExclusiveArch when importing to git.
        
[-]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 20480 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[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: There are rpmlint messages (see attachment).
[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 requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[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]: 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]: Packages must not store files under /srv, /opt or /usr/local

===== 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.

% npm -q view lodash version
1.3.1

[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: SourceX tarball generation or download is documented.
     Note: Package contains tarball without URL, check comments
        tarball download script provided -> OK
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[ ]: %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]: Fully versioned dependency in subpackages if applicable.
[x]: SourceX is a working URL.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: nodejs-lodash-1.3.1-2.fc20.noarch.rpm
nodejs-lodash.noarch: W: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 0 errors, 1 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint nodejs-lodash
nodejs-lodash.noarch: W: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
# echo 'rpmlint-done:'



Requires
--------
nodejs-lodash (rpmlib, GLIBC filtered):
    nodejs(engine)



Provides
--------
nodejs-lodash:
    nodejs-lodash
    npm(lodash)



Source checksums
----------------
http://registry.npmjs.org/lodash/-/lodash-1.3.1.tgz :
  CHECKSUM(SHA256) this package     : a1a5ffbf5df922984608392ec943409a1e78a11fb2a8a7218a2eafbe295b0a4b
  CHECKSUM(SHA256) upstream package : a1a5ffbf5df922984608392ec943409a1e78a11fb2a8a7218a2eafbe295b0a4b


Generated by fedora-review 0.4.0 (eaf16cd) last change: 2013-05-30
Buildroot used: fedora-rawhide-vanilla-x86_64
Command line :./try-fedora-review -b977132

(In reply to T.C. Hollingsworth from comment #6)
> Sorry, I forgot about this and just noticed I hadn't finished it when I was
> tracking down the info about the Closure Compiler for the new JS work.  :-(

Don't worry! Just the fact that you're taking any of my review requests at all is very helpful indeed, especially considering the fact that there a like a gazillion of them (plus the ones I've packaged but yet to post up...)

New Package SCM Request
=======================
Package Name: nodejs-lodash
Short Description: A low-level utility library delivering consistency and customization
Owners: jamielinux patches
Branches: f18 f19 el6
InitialCC:

Git done (by process-git-requests).

nodejs-lodash-1.3.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/nodejs-lodash-1.3.1-2.fc19

nodejs-lodash-1.3.1-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/nodejs-lodash-1.3.1-2.fc18

nodejs-lodash-1.3.1-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/nodejs-lodash-1.3.1-2.el6

nodejs-lodash-1.3.1-2.el6 has been pushed to the Fedora EPEL 6 testing repository.

nodejs-lodash-1.3.1-2.fc18 has been pushed to the Fedora 18 stable repository.

nodejs-lodash-1.3.1-2.fc19 has been pushed to the Fedora 19 stable repository.

nodejs-lodash-1.3.1-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/nodejs-lodash-1.3.1-3.el6

nodejs-lodash-1.3.1-3.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.