Bug 1878902 - Review Request: naga - Simplified Java NIO asynchronous sockets
Summary: Review Request: naga - Simplified Java NIO asynchronous sockets
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Andy Mender
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1878903
TreeView+ depends on / blocked
 
Reported: 2020-09-14 20:44 UTC by Jerry James
Modified: 2020-10-05 16:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-05 16:34:46 UTC
Type: ---
andymenderunix: fedora-review+


Attachments (Terms of Use)

Description Jerry James 2020-09-14 20:44:46 UTC
Spec URL: https://jjames.fedorapeople.org/naga/naga.spec
SRPM URL: https://jjames.fedorapeople.org/naga/naga-3.0-15.20150330git054a930.fc34.src.rpm
Fedora Account System Username: jjames
Description: Naga aims to be a very small NIO library that provides a handful of java classes to wrap the usual Socket and ServerSocket with asynchronous NIO counterparts (similar to NIO2 planned for Java 1.7).

All of this is driven from a single thread, making it useful for both client (e.g. allowing I/O to be done in the AWT-thread without any need for threads) and server programming (1 thread for all connections instead of 2 threads/connection).

Internally Naga is a straightforward NIO implementation without any threads or event-queues thrown in, it is "just the NIO-stuff", to let you build things on top of it.

Naga contains the code needed to get NIO up and running without having to code partially read buffers and setting various selection key flags.

NOTE: The naga package was previously in Fedora.  This is a re-review due to it being absent for some months.

Comment 1 Andy Mender 2020-09-16 18:53:52 UTC
I don't have much experience with packaging Java stuff, but I see this has been sitting around for a while so I want to help.

Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=51604491

> Requires:       java-headless
> Requires:       javapackages-tools

The Java Packaging Guidelines mention also that a Requires on javapackages-filesystem should be added: https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_buildrequires_and_requires
> Requires:       javapackages-filesystem

> %package javadoc
> Summary:        Javadocs for %{name}
> Requires:       javapackages-tools

The guidelines mention that the %{name}-javadoc subpackage should be explicitly declared as noarch: https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_javadoc_installation

> %files
> %doc Echoserver.md Eventmachine.md Gotchas.md PacketReader.md README.md
> %{_javadir}/naga.jar
> %{_javadir}/naga-3_0.jar

No %license file added to the package and I see neither the old nor the new upstream have a license file in their source tree. Also, only the old upstream mentions that the license is MIT. Could you ask upstream to add a license file for the MIT license?

Also, a very minor thing, but you can use %{name} instead of "naga" :).

The rest of the review:

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

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


Issues:
=======
- This seems like a Java package, please install fedora-review-plugin-java
  to get additional checks
  Review: The plugin was orphaned 2+ years ago.
- Package does not use a name that already exists.
  Note: A package with this name already exists. Please check
  https://src.fedoraproject.org/rpms/naga
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/Naming/#_conflicting_package_names
  Review: it's fine, since it's an unretirement request.


===== MUST items =====

Generic:
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
     Note: Using prebuilt packages
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[!]: 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 %license.
[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", "Expat License". 27 files have unknown
     license. Detailed output of licensecheck in
     /home/amender/rpmbuild/SPECS/naga/naga/licensecheck.txt
     Review: Presumably yes.
[!]: License file installed when any subpackage combination is installed.
[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
[?]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
     Review: Yes, but as mentioned before, instances of "naga" 
     can be replaced with %{name}
[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]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 30720 bytes in 5 files.
     Review: naga-javadoc added as subpackage.
[x]: Package complies to the Packaging Guidelines
[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]: 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]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package must not depend on deprecated() packages.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[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

Java:
[x]: Bundled jar/class files should be removed before build

===== SHOULD items =====

Generic:
[x]: Reviewer should test that the package builds in mock.
[ ]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
     Review: mention in a commment before.
[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.
[x]: Patches link to upstream bugs/comments/lists or are otherwise
     justified.
     Review: If the supplied patches are related to particular BRs
     or tickets with upstream, it would be worth adding these to the SPEC as well.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: 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.
     Review: upstream provides some JUnit tests: 
     https://github.com/lerno/naga/tree/master/src/test/naga
     Not sure whether "ant" builds them and one could add them as a %check step?
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Fully versioned dependency in subpackages if applicable.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

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

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: No rpmlint messages.


Rpmlint
-------
Checking: naga-3.0-15.20150330git054a930.fc34.noarch.rpm
          naga-javadoc-3.0-15.20150330git054a930.fc34.noarch.rpm
          naga-3.0-15.20150330git054a930.fc34.src.rpm
naga-javadoc.noarch: W: spelling-error Summary(en_US) Javadocs -> Java docs, Java-docs, Avocados
naga.src:23: W: mixed-use-of-spaces-and-tabs (spaces: line 5, tab: line 23)
3 packages and 0 specfiles checked; 0 errors, 2 warnings.




Rpmlint (installed packages)
----------------------------
(none): E: no installed packages by name naga-javadoc
(none): E: no installed packages by name naga
0 packages and 0 specfiles checked; 0 errors, 0 warnings.



Source checksums
----------------
https://github.com/lerno/naga/archive/054a930d1f346eda5ac48edc4c51d60f811f1de9/naga-054a930d1f346eda5ac48edc4c51d60f811f1de9.tar.gz :
  CHECKSUM(SHA256) this package     : 027cfadb6856e125cc204f3736c7e7a7e269aa785bfa7040388df9bc77b8347c
  CHECKSUM(SHA256) upstream package : 027cfadb6856e125cc204f3736c7e7a7e269aa785bfa7040388df9bc77b8347c


Requires
--------
naga (rpmlib, GLIBC filtered):
    java-headless
    javapackages-tools

naga-javadoc (rpmlib, GLIBC filtered):
    javapackages-tools



Provides
--------
naga:
    naga

naga-javadoc:
    naga-javadoc

Comment 2 Jerry James 2020-09-25 15:54:31 UTC
(In reply to Andy Mender from comment #1)
> I don't have much experience with packaging Java stuff, but I see this has
> been sitting around for a while so I want to help.

Thank you, Andy!  I appreciate that.  Sorry for the delay replying to this.

> The Java Packaging Guidelines mention also that a Requires on
> javapackages-filesystem should be added:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/
> #_buildrequires_and_requires
> > Requires:       javapackages-filesystem

Right, it should have been javapackages-filesystem instead of javapackages-tools.  Fixed.

> The guidelines mention that the %{name}-javadoc subpackage should be
> explicitly declared as noarch:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/
> #_javadoc_installation

The wording is a bit unclear there.  It means that if the main package is architecture-specific, then the javadoc package must explicitly be marked as noarch.  In the case where the main package is noarch, all subpackages are implicitly noarch.  Either way, you get a noarch javadoc package.

> No %license file added to the package and I see neither the old nor the new
> upstream have a license file in their source tree. Also, only the old
> upstream mentions that the license is MIT. Could you ask upstream to add a
> license file for the MIT license?

Well, I can ask.  The last upstream activity was 5 1/2 years ago, so I'm not optimistic about the result.  In any case, all of the *.java files carry the full license at the top.

> Also, a very minor thing, but you can use %{name} instead of "naga" :).

"naga" is 4 character; "%{name}" is 7 :-).  I do use %{name} where it refers to the package.  I don't when referring to specific filenames.

New URLs:
Spec URL: https://jjames.fedorapeople.org/naga/naga.spec
SRPM URL: https://jjames.fedorapeople.org/naga/naga-3.0-16.20150330git054a930.fc34.src.rpm

Comment 3 Andy Mender 2020-09-26 17:52:15 UTC
> The wording is a bit unclear there.  It means that if the main package is architecture-specific, then the javadoc package must explicitly be marked as noarch.  In the case where the main package is noarch, all subpackages are implicitly noarch.  Either way, you get a noarch javadoc package.

Yes, I see now that the guideline about javadoc can be understood in a couple of ways: https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_javadoc_installation

Since the main package is noarch, I agree it's fine as it is now.

> Well, I can ask.  The last upstream activity was 5 1/2 years ago, so I'm not optimistic about the result.  In any case, all of the *.java files carry the full license at the top.

There is a couple of ways this can be handled covered here: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text

The thing is that a license file should be added independently of whether the source files contain a license text/comment or not, since it's an aspect of packaging. As a packager you *can* add the text of the MIT license as an extra file to the package, for instance taking the license text included in one of the source files.

Upstream inactivity is a different matter. I had a look at the GitHub timestamps again and most files were modified 6-12 years ago. I'd say the project is effectively dead, in which case responsibility for any bugfixes, improvements, etc. lies with the packager :(.

For now please add an extra MIT license file with the %license macro and contact upstream if possible.

Comment 4 Jerry James 2020-09-29 02:37:50 UTC
Upstream request for a license file: https://github.com/lerno/naga/issues/18

New URLs for the package with a license file included:
Spec URL: https://jjames.fedorapeople.org/naga/naga.spec
SRPM URL: https://jjames.fedorapeople.org/naga/naga-3.0-17.20150330git054a930.fc34.src.rpm

Comment 5 Andy Mender 2020-09-29 19:08:36 UTC
Alright, looks good.

I trigged some builds just in case:
COPR: https://copr.fedorainfracloud.org/coprs/andymenderunix/jmol/build/1689006/ (fails on armhfp for whatever reason)
Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=52471969 (clean)

Comment 6 Jerry James 2020-09-29 21:23:39 UTC
Thank you Andy.  That build failure on armhfp is a segfault in a futex call inside libpthread.  That can't possibly be the fault of naga, which contains no native code.  I'll cross my fingers and hope that doesn't happen on koji.

Comment 7 Fedora Update System 2020-10-01 18:48:34 UTC
FEDORA-2020-f28bd01371 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f28bd01371

Comment 8 Fedora Update System 2020-10-02 01:48:25 UTC
FEDORA-2020-f28bd01371 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-f28bd01371`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f28bd01371

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2020-10-05 16:34:46 UTC
FEDORA-2020-f28bd01371 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.