Bug 1770566 - Review Request: gron - Make JSON greppable
Summary: Review Request: gron - Make JSON greppable
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: 31
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Neal Gompa
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-11-10 15:19 UTC by Lars Kiesow
Modified: 2020-01-27 11:26 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-01-27 11:26:09 UTC
ngompa13: fedora-review+

Attachments (Terms of Use)

Description Lars Kiesow 2019-11-10 15:19:04 UTC
Spec URL: https://data.lkiesow.io/rpm/gron/gron.spec
SRPM URL: https://data.lkiesow.io/rpm/gron/gron-0.6.0-1.fc31.src.rpm
Description: gron transforms JSON into discrete assignments to make it easier to grep for what you want and see the absolute 'path' to it. It eases the exploration of APIs that return large blobs of JSON.
Fedora Account System Username: lkiesow

Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=38884058
Copr repository: https://copr.fedorainfracloud.org/coprs/lkiesow/gron/

I'm maintaining gron (and some other packages) in Copr for a while but this is my first Fedora package and I'm looking for a sponsor.

Comment 1 Dusty Mabe 2019-12-08 02:01:26 UTC
Hi Lars,

Thanks for contributing this back to Fedora! I'm not a sponsor (i'll work on trying to get us one) but I have done a review. I'll post the review in a followup comment.

Before I post the review I think it's worth noting that our Golang package guidelines have now been published and are in the Fedora Documentation. I have to admit it's been a while since I looked at them myself and I'm impressed with how good it looks (lots of new macros to help packaging golang packages!). Some of the issues that are found in the review will probably be addressed if we update your spec to use the new macros.

Here is a link to the go guideline documentation: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
Here is a link to a simple example for a binary package (like this one): https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_simple_binary_package

Comment 2 Dusty Mabe 2019-12-08 02:02:20 UTC
Package Review

[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated

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

[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
[x]: License field in the package spec file matches the actual license.
     Note: There is no build directory. Running licensecheck on vanilla
     upstream sources. Licenses found: "Unknown or generated". 1 files have
     unknown license. Detailed output of licensecheck in
[x]: Package does not own files or directories owned by other packages.
     Note: Dirs in package are owned also by: /usr/share/doc/gron(locale,,
     to, C, Failed, set, defaulting), /usr/share/licenses/gron(locale,, to,
     C, Failed, set, defaulting)
[-]: %build honors applicable compiler flags or justifies otherwise.

It might be good to use %gobuild for this:


[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
[?]: Package is named according to the Package Naming Guidelines.

DWM: It looks like the golang guidlines have recently been published in
the Fedora Docs (they look really nice!). In there I think it says that
go packages must be named in a certain way. For us I think it would be
golang-github-tomnomnom-gron and then we can create a binary package with
the name `gron` as a subpackage:


I'll have to lean on one of our go packaging experts for advice here.

[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.
[!]: Useful -debuginfo package or justification otherwise.

There is no debuginfo package. Maybe one of our go experts can tell us what macro
we can use to generate those packages.

[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 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 %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[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
[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
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

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

[-]: 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.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.

Upstream doesn't publish signatures.

[-]: 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

Successfully built in koji on all architectures:

[!]: %check is present and all tests pass.

DWM: Optional: add a %check section for running tests as part of the build process.

[x]: Packages should try to preserve timestamps of original installed
[!]: Spec use %global instead of %define unless justified.
     Note: %define requiring justification: %define debug_package %{nil},
     %define repo github.com/tomnomnom/gron

DWM: Optional: Perhaps you can change these to %global: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_global_preferred_over_define

[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
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[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.

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

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

Checking: gron-0.6.0-1.fc32.x86_64.rpm
gron.x86_64: W: spelling-error Summary(en_US) greppable -> reparable
gron.x86_64: W: unstripped-binary-or-object /usr/bin/gron
gron.x86_64: W: no-manual-page-for-binary gron
gron.src: W: spelling-error Summary(en_US) greppable -> reparable
2 packages and 0 specfiles checked; 0 errors, 4 warnings.

DWM: For the rpmlint spelling errors.. Greppable isn't a word but it is a technical term
     so don't worry about it.

A few other items found by Dusty during review:

==== Go Packaging Guidelines ====


[!] Packages MUST have BuildRequires: go-rpm-macros. 

    This requirement is defined here:

    You can solve this by including the %gometa macro:

Comment 3 Neal Gompa 2019-12-08 02:08:08 UTC
Taking this review.

Comment 4 Neal Gompa 2019-12-08 03:07:20 UTC
Have you considered using "go2rpm" to generate this spec file? It produces Go packaging that is compliant with current packaging guidelines?

Comment 5 Dusty Mabe 2019-12-08 16:05:35 UTC
(In reply to Neal Gompa from comment #4)
> Have you considered using "go2rpm" to generate this spec file? It produces
> Go packaging that is compliant with current packaging guidelines?

wow! go2rpm is freaking awesome. Lars has been building this package in copr for over
a year. I don't think go2rpm existed then.

Lars I just tried this out. Here is what I did: 

I installed go2rpm and ran it with using the following commands:

$ sudo dnf install /usr/bin/go2rpm
$ mkdir go2rpm && cd go2rpm
$ go2rpm github.com/tomnomnom/gron -v 0.6.0

That creates a `golang-github-tomnomnom-gron.spec` that can be used to build an rpm. We probably
want to tweak it slighty to make a subpackage named `gron` so people can `dnf install gron`. Here's
a diff I applied to get that:

@@ -29,6 +29,12 @@
+%package -n gron
+Summary:       %{summary}
+%description -n gron 
@@ -47,7 +53,7 @@
+%files -n gron
 %license LICENSE
 %doc docs CHANGELOG.mkd README.mkd


Comment 6 Robert-André Mauchin 2019-12-08 21:22:37 UTC
Please use go2rpm and latest Guidelines:

# Generated by go2rpm 1
%bcond_without check

# https://github.com/tomnomnom/gron
%global goipath         github.com/tomnomnom/gron
Version:                0.6.0


%global common_description %{expand:
Make JSON greppable!}

%global golicenses      LICENSE
%global godocs          docs README.mkd CHANGELOG.mkd

Name:           gron
Release:        1%{?dist}
Summary:        Make JSON greppable

License:        MIT
URL:            %{gourl}
Source0:        %{gosource}

BuildRequires:  golang(github.com/fatih/color)
BuildRequires:  golang(github.com/mattn/go-colorable)
BuildRequires:  golang(github.com/nwidger/jsoncolor)
BuildRequires:  golang(github.com/pkg/errors)



%gobuild -o %{gobuilddir}/bin/gron %{goipath}

install -m 0755 -vd                     %{buildroot}%{_bindir}
install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/

%if %{with check}

%license LICENSE
%doc docs README.mkd CHANGELOG.mkd


Comment 7 Lars Kiesow 2020-01-03 23:49:18 UTC
Thanks for the helpful feedback and especially thanks for pointing me to go2rpm. That tool is really helpful and makes packaging go projects so much easier.
I've updated the specs and hopefully fixed all issues pointed out including the rpmlint notices except for the warning about the term `greppable` which is correct here as a technical term.

I've named the main package gron as suggested in the Golang Packaging Guidelines with the devel package containing the full go path, running with the same reasoning as the guideline [1]:

> Source packages that provide a well-known application such as etcd MUST be named after the application. End users do not care about the language their applications are written in. 

While you could argue how well-known gron is, users will definitely expect the name gron. Hence I did take a look at the etcd packaging and followed their lead in addition to the examples [2] from the guide.

New Spec URL: https://data.lkiesow.dev/rpm/gron/0.6.0-2/gron.spec
New SRPM URL: https://data.lkiesow.dev/rpm/gron/0.6.0-2/gron-0.6.0-2.fc31.src.rpm
New Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=40083094

Please let me know if anything else is missing.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_source_packages_src_rpm
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang_templates/#_minimal_binary

Comment 8 Dusty Mabe 2020-01-04 02:01:00 UTC
Thanks Lars!

I can't seem to access the spec file. Are those the right links?

Comment 10 Dusty Mabe 2020-01-05 04:56:02 UTC
The new spec seems to address any concerns I had!

Neal, anything you see that needs to be changed?

Comment 11 Neal Gompa 2020-01-06 06:50:04 UTC
Nope, it looks good to me!

Comment 12 Neal Gompa 2020-01-06 06:51:32 UTC
Package was generated through go2rpm, simplifying the review considerably.

- Conforms to packaging guidelines (go2rpm generated spec)
- license correct and valid
- as this is a package that provides an application, it installs binaries
- as this is a package that provides an API, it installs sources correctly
through devel subpackage


Comment 13 Neal Gompa 2020-01-06 06:53:17 UTC
I've sponsored you through, you may now go onto the next stage for packaging gron.

Welcome to the Fedora Packagers group!

Comment 14 Lars Kiesow 2020-01-06 23:18:23 UTC
Thanks, Neal! I will try to push forward from here and see if I can figure out everything I need.
I will make sure to be annoying and ask if I am struggling somewhere ;-)

Comment 15 Gwyn Ciesla 2020-01-13 13:51:47 UTC
(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/gron

Comment 16 Lars Kiesow 2020-01-17 23:01:02 UTC
A f31 build is now on Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d18e4b6803

Comment 17 Fedora Update System 2020-01-18 01:44:31 UTC
gron-0.6.0-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d18e4b6803

Comment 18 Fedora Update System 2020-01-27 11:26:09 UTC
gron-0.6.0-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, 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.