Bug 1510565 - Review Request: ntpstat - Utility to print NTP synchronization status
Summary: Review Request: ntpstat - Utility to print NTP synchronization status
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pavel Zhukov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-07 16:49 UTC by Miroslav Lichvar
Modified: 2017-12-04 17:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-04 17:13:58 UTC
Type: ---
Embargoed:
pzhukov: fedora-review+


Attachments (Terms of Use)

Description Miroslav Lichvar 2017-11-07 16:49:14 UTC
Spec URL: https://mlichvar.fedorapeople.org/tmp/ntpstat.spec
SRPM URL: https://mlichvar.fedorapeople.org/tmp/ntpstat-0.4-1.fc28.src.rpm
Description:
ntpstat is a script which prints a brief summary of the system clock's
synchronisation status when the ntpd or chronyd daemon is running.
Fedora Account System Username: mlichvar

This is a split from the ntp package. The ntpstat utility was included in the ntp package for a very long time, but it never was in the upstream ntp code. It was recently rewritten as a shell script, which supports both ntp and chrony, so it now makes even less sense to keep it in the ntp package.

Comment 1 Artur Frenszek-Iwicki 2017-11-07 17:39:47 UTC
>Group:	Applications/System
The "Group:" tag shouldn't be used.
https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections

>%files
>%doc COPYING NEWS README
COPYING should probably be marked as %license instead of %doc.

Comment 2 Miroslav Lichvar 2017-11-08 08:29:17 UTC
Thanks, I'll fix that in the next release. Would you like to do a full review?

In order to not lose ntpstat after an upgrade, I was planning to add Recommends or Requires to the ntp package, but I'm wondering if there is not a better way. If ntpstat obsoleted the old ntp package and required "(ntp or chrony)", I suspect an upgrade could result in an installed ntp being replaced by chrony as the new requirement would be satisfied without ntp.

Comment 3 Pavel Zhukov 2017-11-14 17:11:19 UTC
I'll review it.

Comment 4 Pavel Zhukov 2017-11-19 09:45:35 UTC
(In reply to Miroslav Lichvar from comment #2)
> Thanks, I'll fix that in the next release. Would you like to do a full
> review?
> 
> In order to not lose ntpstat after an upgrade, I was planning to add
> Recommends or Requires to the ntp package, but I'm wondering if there is not
> a better way. If ntpstat obsoleted the old ntp package and required "(ntp or
> chrony)", I suspect an upgrade could result in an installed ntp being
> replaced by chrony as the new requirement would be satisfied without ntp.

What about: https://fedoraproject.org/wiki/Packaging:WeakDependencies#Real_life_example ?

Both chrony and ntp should provide some "service" and ntpstat should depend on this "service" and suggest chrony as preferred provider.

Comment 5 Miroslav Lichvar 2017-11-20 11:21:20 UTC
(In reply to Pavel Zhukov from comment #4)
> What about:
> https://fedoraproject.org/wiki/Packaging:WeakDependencies#Real_life_example ?
> 
> Both chrony and ntp should provide some "service" and ntpstat should depend
> on this "service" and suggest chrony as preferred provider.

What if a third package was added to fedora, which provided this service? ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc), but that's all.

If old ntp is installed, I think an upgrade should result in both new ntp and ntpstat installed. If chrony is not installed, the upgrade should not install chrony. If neither chrony or ntp is installed, it would be nice if installing ntpstat installed chrony as it is currently preferred over ntp, but it probably does not really matter.

Comment 6 Pavel Zhukov 2017-11-21 15:48:49 UTC
(In reply to Miroslav Lichvar from comment #5)
> (In reply to Pavel Zhukov from comment #4)
> > What about:
> > https://fedoraproject.org/wiki/Packaging:WeakDependencies#Real_life_example ?
> > 
> > Both chrony and ntp should provide some "service" and ntpstat should depend
> > on this "service" and suggest chrony as preferred provider.
> 
> What if a third package was added to fedora, which provided this service?
> ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc),
> but that's all.
Well it's theoretical question which applies for mysql example as well. 
There're few options:
1) Add support of the service to ntpstat
2) Add "Conflicts:" to either the service or ntpstat spec.
In any case As far as ntpstat suggests chrony It's safe. In other words user has to explicitly install ntpstat and "the service".

Well It may happen that ntp/chrony will change the API :) and will not be longer compatible with ntpstat etc. 
> 
> If old ntp is installed, I think an upgrade should result in both new ntp
> and ntpstat installed. 
Something like Enhances: ntpstat in ntp.spec? 

> If chrony is not installed, the upgrade should not
> install chrony.
Should be ok.

> If neither chrony or ntp is installed, it would be nice if
> installing ntpstat installed chrony as it is currently preferred over ntp,
> but it probably does not really matter.
Suggests: solves this

Comment 7 Miroslav Lichvar 2017-11-23 10:55:31 UTC
(In reply to Pavel Zhukov from comment #6)
> (In reply to Miroslav Lichvar from comment #5)
> > What if a third package was added to fedora, which provided this service?
> > ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc),
> > but that's all.
> Well it's theoretical question which applies for mysql example as well. 
> There're few options:
> 1) Add support of the service to ntpstat
> 2) Add "Conflicts:" to either the service or ntpstat spec.
> In any case As far as ntpstat suggests chrony It's safe. In other words user
> has to explicitly install ntpstat and "the service".

Wouldn't it better to just explicitly list the supported services in the ntpstat spec using a rich dependency, e.g. "Requires: (ntp or chrony)" ?

> > If old ntp is installed, I think an upgrade should result in both new ntp
> > and ntpstat installed. 
> Something like Enhances: ntpstat in ntp.spec? 

That does not seem to work. I created a testing repo with ntp which "enhances" ntpstat and also contains the new ntpstat package, but dnf seems to ignore it:

# dnf update --disablerepo=* --enablerepo=local
...
Upgrading:
 ntp                             x86_64                         4.2.8p10-4.nontpstat.fc28                          local                         670 k
 ntpdate                         x86_64                         4.2.8p10-4.nontpstat.fc28                          local                          85 k

I tried adding "Obsoletes: ntp < 4.2.8p10-4" to ntpstat.spec, expecting ntp would be dropped without replacement as chrony is installed, but the result was the same as before.

Comment 8 Pavel Zhukov 2017-11-23 12:05:33 UTC
(In reply to Miroslav Lichvar from comment #7)
> (In reply to Pavel Zhukov from comment #6)
> > (In reply to Miroslav Lichvar from comment #5)
> > > What if a third package was added to fedora, which provided this service?
> > > ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc),
> > > but that's all.
> > Well it's theoretical question which applies for mysql example as well. 
> > There're few options:
> > 1) Add support of the service to ntpstat
> > 2) Add "Conflicts:" to either the service or ntpstat spec.
> > In any case As far as ntpstat suggests chrony It's safe. In other words user
> > has to explicitly install ntpstat and "the service".
> 
> Wouldn't it better to just explicitly list the supported services in the
> ntpstat spec using a rich dependency, e.g. "Requires: (ntp or chrony)" ?
looks good for me. It's maintainer decision at the end :) 
Are you going to update spec or it'll be done after formal review?
> 
> > > If old ntp is installed, I think an upgrade should result in both new ntp
> > > and ntpstat installed. 
> > Something like Enhances: ntpstat in ntp.spec? 
> 
> That does not seem to work. I created a testing repo with ntp which
> "enhances" ntpstat and also contains the new ntpstat package, but dnf seems
> to ignore it:
> 
> # dnf update --disablerepo=* --enablerepo=local
> ...
> Upgrading:
>  ntp                             x86_64                        
> 4.2.8p10-4.nontpstat.fc28                          local                    
> 670 k
>  ntpdate                         x86_64                        
> 4.2.8p10-4.nontpstat.fc28                          local                    
> 85 k
> 
> I tried adding "Obsoletes: ntp < 4.2.8p10-4" to ntpstat.spec, expecting ntp
> would be dropped without replacement as chrony is installed, but the result
> was the same as before.
weird. maybe bug in libsolv?
Anyway I'll post formal review soon...

Comment 9 Miroslav Lichvar 2017-11-23 12:21:51 UTC
(In reply to Pavel Zhukov from comment #8)
> (In reply to Miroslav Lichvar from comment #7)
> > Wouldn't it better to just explicitly list the supported services in the
> > ntpstat spec using a rich dependency, e.g. "Requires: (ntp or chrony)" ?
> looks good for me. It's maintainer decision at the end :) 
> Are you going to update spec or it'll be done after formal review?

I've updated the spec and srpm:
https://mlichvar.fedorapeople.org/tmp/ntpstat.spec
https://mlichvar.fedorapeople.org/tmp/ntpstat-0.4-2.fc28.src.rpm

> > I tried adding "Obsoletes: ntp < 4.2.8p10-4" to ntpstat.spec, expecting ntp
> > would be dropped without replacement as chrony is installed, but the result
> > was the same as before.
> weird. maybe bug in libsolv?

I'm not sure. Maybe the obsoletes should be considered only if ntpstat is already installed? I guess the other option is to simply add "Requires: ntpstat" to ntp.

> Anyway I'll post formal review soon...

Thanks.

Comment 10 Pavel Zhukov 2017-11-29 21:54:15 UTC
Revuew is below. Few remarks:
1) You are using %makeinstall macros while Makefile is pretty simple and either make install prefix=%{DESTDIR}/%{prefix} can be used or Makefile patched to accept DESTDIR (upstream first). 
https://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_macro_should_not_be_used
2) Description should start with capitalized letter as normal English sentense


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

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



===== 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: "MIT/X11 (BSD like)", "Unknown or generated". 4 files have
     unknown license. Detailed output of licensecheck in
     /home/pavel/work/bugs/bz1510565/ntpstat/licensecheck.txt
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[!]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
     Note: %makeinstall used in %install section
[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.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[!]: Spec file is legible and written in American English.
[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]: 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 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]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[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]: Packages must not store files under /srv, /opt or /usr/local

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

Generic:
[x]: 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]: 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]: 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.
[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).


Rpmlint
-------
Checking: ntpstat-0.4-2.fc26.noarch.rpm
          ntpstat-0.4-2.fc26.src.rpm
ntpstat.noarch: W: spelling-error %description -l en_US synchronisation -> synchronization, synchronicity
ntpstat.noarch: W: spelling-error %description -l en_US ntpd -> DuPont
ntpstat.noarch: W: spelling-error %description -l en_US chronyd -> chronic
ntpstat.src: W: spelling-error %description -l en_US synchronisation -> synchronization, synchronicity
ntpstat.src: W: spelling-error %description -l en_US ntpd -> DuPont
ntpstat.src: W: spelling-error %description -l en_US chronyd -> chronic
2 packages and 0 specfiles checked; 0 errors, 6 warnings.




Rpmlint (installed packages)
----------------------------
ntpstat.noarch: W: spelling-error %description -l en_US synchronisation -> synchronization, synchronicity
ntpstat.noarch: W: spelling-error %description -l en_US ntpd -> DuPont
ntpstat.noarch: W: spelling-error %description -l en_US chronyd -> chronic
ntpstat.noarch: W: invalid-url URL: https://github.com/mlichvar/ntpstat <urlopen error [Errno -2] Name or service not known>
1 packages and 0 specfiles checked; 0 errors, 4 warnings.



Requires
--------
ntpstat (rpmlib, GLIBC filtered):
    (ntp or chrony)
    /bin/bash



Provides
--------
ntpstat:
    ntpstat



Source checksums
----------------
https://github.com/mlichvar/ntpstat/archive/0.4/ntpstat-0.4.tar.gz :
  CHECKSUM(SHA256) this package     : 1ededcbf55599c4388ff181c18a2b60ca214793059d77f9aadd26d6bc33284f8
  CHECKSUM(SHA256) upstream package : 1ededcbf55599c4388ff181c18a2b60ca214793059d77f9aadd26d6bc33284f8

Comment 11 Miroslav Lichvar 2017-11-30 16:01:00 UTC
Thanks for the review.

The Makefile doesn't support DESTDIR and the upstream is not interested in adapting autoconf+automake only to install a single shell script :). If %install used "make install prefix=...", the bindir and mandir variables wouldn't be set to %{_bindir} and %{_mandir}. I think that's why the %makeinstall macro exists.

Does that make sense?

To avoid starting with a lowercase character I'll change the description to:

This package contains a script which prints a brief summary of the system                                                                              
clock's synchronisation status when the ntpd or chronyd daemon is running.

Comment 12 Pavel Zhukov 2017-11-30 22:43:04 UTC
(In reply to Miroslav Lichvar from comment #11)
> Thanks for the review.
> 
> The Makefile doesn't support DESTDIR and the upstream is not interested in
> adapting autoconf+automake only to install a single shell script :). If
> %install used "make install prefix=...", the bindir and mandir variables
> wouldn't be set to %{_bindir} and %{_mandir}. I think that's why the
> %makeinstall macro exists.
> 
> Does that make sense?
I'm fine with it. But packaging guidelines asks for clarification. Looks good.
> 
> To avoid starting with a lowercase character I'll change the description to:
> 
> This package contains a script which prints a brief summary of the system   
> 
> clock's synchronisation status when the ntpd or chronyd daemon is running.

Ok. Please change the description in initial commit then.

Approved.

Comment 13 Miroslav Lichvar 2017-12-04 11:49:14 UTC
Thanks for the review!

To avoid the annoying warning when using %makeinstall I think it could be replaced with expanded "make install mandir=... bindir.... ".

Comment 14 Gwyn Ciesla 2017-12-04 14:28:57 UTC
(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/ntpstat


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