https://bugzilla.redhat.com/show_bug.cgi?id=2007918
Frank Crawford <frank(a)crawford.emu.id.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?(jkadlcik(a)redhat.c
| |om)
--- Comment #7 from Frank Crawford <frank(a)crawford.emu.id.au> ---
New versions available here:
Spec URL:
https://download.copr.fedorainfracloud.org/results/frankcrawford/tuptime/...
SRPM URL:
https://download.copr.fedorainfracloud.org/results/frankcrawford/tuptime/...
(In reply to Jakub Kadlčík from comment #5)
Thank you for pinging me, I forgot.
> # Check for EPEL Python (python34, python36)
> %if 0%{?python3_pkgversion}
> BuildRequires: python%{python3_pkgversion}-devel
> %else
> BuildRequires: python3-devel
I've never seen this before. Is there any motivation for it? IMHO simply
BuildRequires: python3-devel
is good enough.
This is mostly for EPEL7, although technically could be for other systems, if
they decided to handle multiple Python3 releases. The biggest thing is that it
fixes on a particular version of Python3, in case they upgrade to a later one
at some point.
See
https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
> that essentially creates and initialises the tuptime DB with
its
> first entry. Doing it here ensures that the permissions, etc, are
> controlled, rather than being in a more random state.
Can you please put that as a comment in the spec file? I think it will
be useful for whoever is going to read that spec file in the future.
Added.
> %systemd_user_preun tuptime.service
I would expect %systemd_preun since there is %systemd_post in the
%post section.
I never noticed it was user and not system before.
That also corrects the other issue, which I believe was the same complaint,
just poorly worded. The actual test in Fedora-Review code is that the
scriptlet exists in all three states (%post, $preun and %postun).
--
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
https://bugzilla.redhat.com/show_bug.cgi?id=2007918