Bug 15790

You've given no reason this should be added.  Anyway, I sync this package with Fedora and have no intention to maintain local customizations.  If you can convince Fedora to add it, then I will too.  You could file a bug in RedHat's bugzilla about it if there isn't one already.

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX

Sorry, I thought that the reason was clear. In order to use the kernel PPS option (using for example the pps modules pps_core and pps_ldisc (for serial port) ) chronyc must be compiled with the PPS option, which happens if the timepps.h include file is in the INCLUDE path (either in /usr/include/ or /usr/include/sys, or the equivalent places if you put a -I/path/to/include/ flag to gcc. )

Timing-gps devices are so cheap nowadays ($50)  that many are using them to drive the timing on their computers and computer networks. This is not really  possible with Mageia in the current state without having to recompile chrony. The only "local customization" is to have timepps.h installed on the computer that compiles chrony.
 That is also necessary, AFAIK with ntpd as well.

Status: RESOLVED => REOPENED
Resolution: WONTFIX => (none)

timepps.h does not exist in Mageia.

Status: REOPENED => RESOLVED
Resolution: (none) => WONTFIX

On Fedora/Debian/Ubuntu/....  timepps.h it is part of the pps-tools package, which Mageia has not ported over, but really should be there for anyone wanting to use the pps kernel modules ( which are there in Mageia). 
It could equally well be put into the chrony src.rpm and installed into /usr/include.

Status: RESOLVED => REOPENED
Resolution: WONTFIX => (none)

No, if it's a separate package, it's a separate package.

So, please explain why Fedora has pps-tools packaged and yet it's not a BuildRequires for chrony or ntpd for them.  Why haven't they enabled this?

Component: RPM Packages => New RPM package request
Assignee: luigiwalser => bugsquad
Summary: chrony is being compiled without PPS support => new package request: pps-tools

It does now
From https://apps.fedoraproject.org/packages/chrony/sources/spec

BuildRequires:  libcap-devel libedit-devel nss-devel pps-tools-devel
BuildRequires:  bison texinfo systemd-units

This is admittedly for the version chrony-2.0-1.fc23
(Note that the only thing in pps-tools-devel is installing timepps.h into /usr/include/sys)


Actually looking at the testing logs on fedora for 1.31.1
(https://kojipkgs.fedoraproject.org/packages/chrony/1.31.1/1.fc21/data/logs/i686/root.log)
I see that pps-tools-devel was a build requirement back in fedora 21 days as well. It seems that it was Mageia which removed it. (see line 6 )



DEBUG util.py:388:  Getting requirements for chrony-1.31.1-1.fc21.src
DEBUG util.py:388:   --> bison-3.0.2-3.fc21.i686
DEBUG util.py:388:   --> libcap-devel-2.24-7.fc21.i686
DEBUG util.py:388:   --> libedit-devel-3.1-12.20150325cvs.fc21.i686
DEBUG util.py:388:   --> nss-devel-3.18.0-1.fc21.i686
DEBUG util.py:388:   --> pps-tools-devel-0-0.10.20120407git0deb9c.fc21.i686
DEBUG util.py:388:   --> systemd-216-24.fc21.i686
DEBUG util.py:388:   --> texinfo-5.2-5.fc21.i686
DEBUG util.py:388:  ================================================================================
DEBUG util.py:388:   Package                   Arch    Version                         Repository
DEBUG util.py:388:                                                                             Size
DEBUG util.py:388:  ================================================================================
DEBUG util.py:388:  Installing:
DEBUG util.py:388:   bison                     i686    3.0.2-3.fc21                    build  651 k
DEBUG util.py:388:   libcap-devel              i686    2.24-7.fc21                     build   30 k
DEBUG util.py:388:   libedit-devel             i686    3.1-12.20150325cvs.fc21         build   33 k
DEBUG util.py:388:   nss-devel                 i686    3.18.0-1.fc21                   build  209 k
DEBUG util.py:388:   pps-tools-devel           i686    0-0.10.20120407git0deb9c.fc21   build   17 k
DEBUG util.py:388:   systemd                   i686    216-24.fc21                     build  5.1 M
DEBUG util.py:388:   texinfo                   i686    5.2-5.fc21

pps-tools-devel is a BuildRequires all the way back to Fedora 15 (chrony 1.25)
http://pkgs.fedoraproject.org/cgit/chrony.git/tree/chrony.spec?h=f15

A message from Lichvar, the maintainer of chrony on Fedora.

"> In Fedora we have that file in the pps-tools-devel package. It's
> required for building by three packages: chrony, ntp and gpsd.
"
"that file" being timepps.h

Summary: new package request: pps-tools => new package request: pps-tools--chrony on MGA does not support PPS

OK, we can indeed add this if the pps-tools package is imported into Mageia.  Note that this kind of change would only be done in Cauldron (after Mageia 5 branches).

Please refrain from adding any more comments in the Subject.  If/when pps-tools is packaged, we can also add it as a BR in ntp and chrony, and these bug comments will serve to document that.

Summary: new package request: pps-tools--chrony on MGA does not support PPS => new package request: pps-tools
Severity: normal => enhancement

Understood. Getting MGA5 out is the first priority. I will have included an attachment (when the attachment.cgi web page comes back up)  which is pps-tool-devel which is a no-arch package-- it contains only the timepps.h file the LGPL license and copyright
terms, all in text. It is this that would be needed.

For the tools themselves, which are useful for testing the pps behaviour of the modules,  that could wait and they are not critical.

Created attachment 6398 [details]
pps-tools-devel rpm needed for PPS support in chrony, ntp, and gpsd

This is an architecture independent rpm which supplies text files  timepps.h (and its license and copyright) for both i586 and x64.

An RPM is of no use to us.  A SPEC file adapted for Mageia (plus any needed sources other than the upstream source code) would be helpful.

No spec file needed. It is a noarch text only file. And the locations are precisely where Mageia would put them. 

Now one could bring in the whole of the pps-tools, package and make a .src package for that. If you would like me to do that, I can certainly do so, since it would differ only in minor features from the fedora one. And it would make both the pps-tools and the pps-tools-devel file. But as far as chrony, ntp and gpsd are concerned, only the noarch pps-tools-devel file is needed.

Created attachment 6404 [details]
pps-tools.spec file adapted from Fedora

I am not sure what version number to give it-- using the huge Fedora git number 20120407git0deb9c seems excessive-- so I set it to 0.

Just 0 as a version number is not ok, see https://wiki.mageia.org/en/Packaging_guidelines#Version_and_Release

Created attachment 6419 [details]
pps-tools.spec file with altered version and release number

That page is not much help in this case, where the only version number on the Fedora file IS 0. So I have made up a version number and put the git number into the release.

The page is totally relevant according to me since it explains what to do for pre-release versions from git.

It does not say what to do about the version number, which is what you objected to. I have now put on a release number as the git date, but you objected to a version number of 0 -- what version number would you suggest? 
I really do not know what the conventions are, and that page does not help as far as the version number is concerned. 
I cannot find any version number in Fedora (which uses version number 0)  or Debian. 
This is hardly "pre-release" as it has not changed it at least 3 years and is used as such universally, although apparently it does not have any offician release number. Anyway, if you could assign a version number that would make Mageia happy, that would be great.

There was a misunderstanding. I was only objecting to using 0 as the version, without the git revision in release. Version 0 + release made with %mkrel -c is fine.

Created attachment 6428 [details]
pps-tools.spec with version number 0

Reverted to 0 as version number and git reference as release as per Fedora release

cauldron for MGA6 is well into development and pps-tools and pps-tool-devel still do not seem to have been included. Just a reminder that it would really be very helpful to have these included in MGA6, so they can be BuildRequires for chrony and ntp.

Assigning this package request to all packagers collectively. On a voluntary basis, one of them might want to integrate it to the distribution and maintain it for bug and security fixes.

You might also want to join the packager team to maintain this piece of software: see https://wiki.mageia.org/en/Becoming_a_Mageia_Packager

Assignee: bugsquad => pkg-bugs

*** Bug 21123 has been marked as a duplicate of this bug. ***

Once again I try to resurrect  this request to include the pps-tools-devel package from Redhat/Fedora into Mageia, and make both chrony and ntpd have a BuildDepends on it. That package is a noarch package which supplies just one file, /usr/include/sys/timepps.h, which has not changed in a very long time. 
RFC2783 (March 2000) sec. 3.2 defines this file.

I'll try to build this package.

CC: (none) => kostuek

pps-tools and pps-tools-devel are in cauldron,

BuildRequires:	pps-tools-devel  can be added to chrony

CC: kostuek => luigiwalser

And add to ntpd and gpsd.

And also, Thank You.

(In reply to w unruh from comment #28)
> And also, Thank You.

You are welcome. Often, whinning bug reporters finish by volutering themselves as Mageia packagers. This time it didn't work ;-)

I have submitted chrony, ntp and gpsd to cauldron built against pps-tools-devel.
Please reported if it works or not (I don't have a gps time sync device)

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED
CC: (none) => lists.jjorge

Actually at one point I tried and managed to screw up and misunderstand the conventions Mageia has for numbering the submission. (See the discussion). On being pointed to the mainter requirements page, I was flummoxed by the requirements (get a mentor, join the maintainer discussion group, join a weekly group meeting in the middle of my work day, etc.) and all this for getting one file into /usr/include.
Anyway, again, thank you.