[Bug 1174030] Review Request: golang-github-appc-spec - Schema defs and tools for app container specification

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1174030
Bug 1174030 depends on bug 1174021, which changed state.

Bug 1174021 Summary: Review Request: golang-github-coreos-go-semver - Go 
semantic versioning library
https://bugzilla.redhat.com/show_bug.cgi?id=1174021

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |RAWHIDE



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1174021] Review Request: golang-github-coreos-go-semver - Go semantic versioning library

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1174021

Lokesh Mandvekar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2015-04-11 02:02:38



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1208738] Review Request: vera++ - A tool for verification, analysis and transformation of C++ source code

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1208738



--- Comment #15 from Taylor Braun-Jones  ---
(In reply to Raphael Groner from comment #13)

> > I did however hit a couple failing unit tests due to incompatibility with 
> > Lua
> > 5.3. I have simply disabled Lua support on Fedora > 22 for now. Upstream bug
> > report:
> > 
> > https://bitbucket.org/verateam/vera/issue/74/vera-segfaults-when-built-with-
> > lua-53#comment-17202574
> 
> You could use BR: compat-lua-devel as like for compat-lua / compat-lua-libs
> packages instead, they have 5.1.5 as version.

Thanks for the heads up, I hadn't thought to check for a compat- version of
lua. Unfortunately, it didn't solve the crash like I had hoped it would, so for
now I've left lua support disabled for Fedora > 22

> [!]: License field in the package spec file matches the actual license.
>  Note: Checking patched sources after %prep for licenses. Licenses found:
>  "BSL (v1.0)", "Unknown or generated". 45 files have unknown license.
>  Detailed output of licensecheck in /home/builder/fedora-
>  review/1208738-vera++/licensecheck.txt
> 
> ==> Please fix or clarify for the bundled cpptcl.
> Maybe you should unbundle into a separate package.
> See
> http://cpptcl.cvs.sourceforge.net/viewvc/cpptcl/src/LICENSE?revision=1.
> 1&view=markup
> The test sources should be okay without any license text.

I added the following comment above the License field:

# Bundled cpptcl package has a non-standard open source license - but more
# permissive than Boost so Boost is the "effective" license. See:
#
# https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ

> vera.ctest : Licensed under the Apache License, Version 2.0 (see
>inside the file for the complete license and copyright)
> 
> ==> Please add ASL 2.0 to License: and mention it in comment for the tests.
> http://www.apache.org/licenses/LICENSE-2.0.txt

Fixed

> [!]: Fully versioned dependency in subpackages if applicable.
>  Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
>  vera++-devel
> 
> ==> Please fix.

This must be a fedora-review bug - I have exactly this line for the devel
subpackage.

> [!]: Spec use %global instead of %define unless justified.
>  Note: %define requiring justification: %define enable_lua_support 1,
>  %define enable_lua_support 0
> 
> ==> Please fix.

Fixed.

> ==> Please fix. You can remove the shebang from all those files in the list
> because they won't be called directly.
> http://wiki.rosalab.ru/en/index.php/Rpmlint_Errors#non-executable-script
> Adjust this for tclsh:
> https://fedoraproject.org/wiki/
> Packaging_tricks#Remove_shebang_from_Python_libraries

Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1161099] Review Request: nodejs-wrappy - Callback wrapping utility

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1161099



--- Comment #13 from Parag AN(पराग)  ---
Yes we have a section on how to use npm registry tarballs but that I don't see
guidelines mandate to use only npm registry tarball while packaging nodejs
module. Its just a guideline that says npm registry tarball follows certain
archiving structure where parent directory is always named as package and not
by module's name-version format.

So if you still see we need to use npm registry tarball, we may need to change
guidelines to use wording from
The Source0 for such modules should be of the form
http://registry.npmjs.org//-/-.tgz. 
to
The Source0 for such modules must be of the form
http://registry.npmjs.org//-/-.tgz. 

I still not got how just changing the tarball from github to npm helped your
dependent modules test cases to work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1210826] Review Request: rubygem-pathspec - Use to match path patterns such as gitignore

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1210826



--- Comment #2 from Orion Poplawski  ---
So, pathspec doesn't ship a spec file in the gemfile.  Should I switch to
building from source for this then?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1210609] Review Request: perl-MojoX-JSON-RPC - Perl implementation of JSON-RPC 2.0 protocol for Mojolicious

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1210609

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2015-04-10 17:48:43



--- Comment #6 from Emmanuel Seyman  ---
Built for rawhide. Updates released for f22 and f21.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1208842] Review Request: gdouros-symbola-fonts - A symbol font

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1208842



--- Comment #6 from Alexander Ploumistos  ---
First review here:
https://bugzilla.redhat.com/show_bug.cgi?id=1201925

I can see now why people aren't anxious to review packages :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1201925] Review Request: gnome-shell-extension-touchpad-indicator - Minimalistic Touchpad management extension for the Gnome Shell

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1201925

Alexander Ploumistos  changed:

   What|Removed |Added

 CC||alex.ploumis...@gmail.com



--- Comment #1 from Alexander Ploumistos  ---
Hi,

This is an informal review and it is also my first, so in all likelihood, I
have missed something.

Your spec file looks good. You don't have any of the obsolete commands and
sections.

When I ran it through rpmlint there where only a few warnings concerning the
spelling of certain words - most of them highly debatable in my opinion:

gnome-shell-extension-touchpad-indicator.src: W: spelling-error Summary(en_US)
Minimalistic -> Minimalist, Minimalism, Animistic
gnome-shell-extension-touchpad-indicator.src: W: spelling-error %description -l
en_US minimalistic -> minimalist, minimalism, animistic
gnome-shell-extension-touchpad-indicator.src: W: spelling-error %description -l
en_US trackpoint -> track point, track-point, checkpoint
gnome-shell-extension-touchpad-indicator.src: W: spelling-error %description -l
en_US startup -> start up, start-up, upstart

Personally, I wouldn't bother.


All of the automatic checks ran by fedora-review were OK. Same for the things I
had to check by myself, except for one thing: the spec file states that the
license is GPLv2+, but licensecheck reported that convenience.js is under the
BSD license with the "no advertising" clause. 

https://fedoraproject.org/wiki/Licensing:BSD?rd=Licensing/BSD#3ClauseBSD

According to

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios

you should change the license line in your spec file to:

License:GPLv2+ and BSD

and it should be preceded by an explanatory comment, like this one:

# The entire source code is GPLv2+ except convenience.js, which is BSD

See the link above for more, it also states that the %files section should
contain a breakdown of the files grouped by license.

In the few tens of spec files I have read, not many people make use of
"c=%{commit}" or "d=%{_datadir}/gnome-shell/extensions/%{uuid}", they just
repeat things over and over again. Perhaps my sample is not statistically
significant and I really have no idea if seasoned packagers would consider it
elegant or lazy (I like it though).

Well done and I hope a proven packager will review your package as soon as
possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1210826] Review Request: rubygem-pathspec - Use to match path patterns such as gitignore

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1210826



--- Comment #1 from Ken Dreyer  ---
Package Review
==

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


Issues:
===
1. Currently the %files list has the entire "%{gem_instdir}" directory. This
means that CHANGELOG.md, LICENSE, and README.md ship in
/usr/share/gems/gems/pathspec-0.0.2/, but these are not marked as %doc. You can
use %{gem_libdir} instead:

  %dir %{gem_instdir}
  %license %{gem_instdir}/LICENSE
  %doc %{gem_instdir}/CHANGELOG.md
  %doc %{gem_instdir}/README.md
  %{gem_libdir}

2. %{gem_docdir} should go into a rubygem-pathspec-doc sub-package.

3. %exclude %{gem_cache}

4. Mind running the tests? You can do something like this for %check:

  %check
  pushd .%{gem_instdir}
rspec -Ilib spec
  popd

  This will BuildRequires: rubygem(rspec)


= 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.
[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.
[x]: Package is not known to require an ExcludeArch tag.
[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]: 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 uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
 beginning of %install.
[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.
[-]: Package uses %makeinstall only when make install' ' DESTDIR=... doesn't
 work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists
[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. Large could be size
 (~1MB) or number of files.
[x]: Packages must not store files under /srv, /opt or /usr/local

Ruby:
[x]: Platform dependent files must all go under %{gem_extdir_mri}, platform
 independent under %{gem_dir}.
[x]: Gem package must not define a non-gem subpackage
[x]: Macro %{gem_extdir} is deprecated.
[x]: Gem package is named rubygem-%{gem_name}
[x]: Package contains BuildRequires: rubygems-devel.
[x]: gems should require rubygems package
[x]: Gem package must define %{gem_name} macro.
[x]: Pure Ruby package must be built as noarch
[x]: Package does not contain Requires: ruby(abi).

= SHOULD items =

Generic:
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Avoid bundling fonts in non-fonts packages.
 Note: Package contains font files
[-]: 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).
[?]: 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.
[!]: %check is present and all tests pass.
[x]: Packages should try to preser

[Bug 1161099] Review Request: nodejs-wrappy - Callback wrapping utility

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1161099



--- Comment #12 from Zuzana Svetlikova  ---
I tried packaging two modules which are dependent on nodejs-wrappy and both
have failed at tests althought everything else seemed alright. When I built and
installed my own rpm, everything went fine, so I took a look at your package.

I rebuilt it from sources for el7, hence the macros. Feel free to delete the
scl macros and Group tag if you want.

You might want to (re)read this:
https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers

where you can find things like:

https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Using_tarballs_from_the_npm_registry

or 

https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Symlinking_Dependencies
(note the blue section)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1202146] Review Request: python-munkres - A Munkres algorithm for Python

2015-04-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1202146



--- Comment #8 from Fedora Update System  ---
python-munkres-1.0.7-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/python-munkres-1.0.7-1.el7

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review