(In reply to David Walser from comment #0)
> Ideally it would be nice to allow people to get out of the business of
> editing the packaged ntp.conf, and support using /etc/ntp.d like upstream
> does.  Our installer and drak tools would have to be adapted if we make this
> change.

According to Ubuntu, chrony can do this now too:
"Chronyd’s configuration can now be fragmented. Please see
/etc/chrony/conf.d/README for more information.
NTP sources can be specified in /etc/chrony/sources.d. Please see
/etc/chrony/sources.d/README for more information."

https://discourse.ubuntu.com/t/hirsute-hippo-release-notes/19221

'ntp' has no fixed maintainer, and given the wider nature of this request, assigning this globally.

Assignee: bugsquad => pkg-bugs

UP
Neoclust and I are working on replacing ntp with ntpsec.

CC: (none) => jean-pierre

Indeed this was handled last August it looks like.  Updated to 1.2.2 in January by me, and spec file fixes made by David Geiger in March.

TODO: document in Mageia 9 release notes
TODO: adapt Mageia installer to wrote to ntp.d and chrony/sources.d instead of ntp.conf or chrony.conf

Priority: Normal => release_blocker

(In reply to David Walser from comment #4)
> TODO: document in Mageia 9 release notes

-> Added keyword to this bug now.

> TODO: adapt Mageia installer to wrote to ntp.d and chrony/sources.d instead
> of ntp.conf or chrony.conf

-> now setting to installer, assigning tools

Source RPM: ntp-4.2.8p15-1.mga8.src.rpm => drakxtools
Component: RPM Packages => Installer
Keywords: (none) => FOR_RELEASENOTES9
CC: (none) => fri
Assignee: pkg-bugs => mageiatools

so this bug is fixed???

CC: (none) => mageia

I guess the TODO for installer in Comment 4 need to be done.
And then release notes.

(In reply to David Walser from comment #0)

This seems the only thing left to do:

> Ideally it would be nice to allow people to get out of the business of
> editing the packaged ntp.conf, and support using /etc/ntp.d like upstream
> does.  Our installer and drak tools would have to be adapted if we make this
> change.

Why is this a release blocker?

IMO it is too late to make nice-to-have changes to the installer.

CC: (none) => mageia

At the very least, the release notes still need to be updated.  As for the configuration change, no it's not absolutely necessary to be done now, but we have a good track record of kicking cans like this down the road and never actually handling them.  It should be a relatively easy change.

It may be a relatively easy change, but any change to the installer requires some hours of work to rebuild everything and test it thoroughly. But if you can find a willing volunteer before I start building the RC ISOs, fine. Given that nobody has cared enough to do the work in the 2 years since you created this bug report, I won't hold my breath.

I understand where you're coming from, but I think that's why these things tend to not get done.  During the vast majority of the development cycle, most of us just worry about updating packages and don't even look at these bugs, then at the last minute when we're trying to finalize a release, the bugs do get looked at and punted because we don't think we have time to fix them.

We need to get mga9 out, we can not keep some bug hostages.

If this from user perspective works like ntp did before (but is more secure) i think it is good enough.

Real nice Morgan.

Looks like we kick this can further to Mageia 10.

- If not, revert my flag change and get it done :)

When that is decided, what should we write in release notes for mga9?

Target Milestone: Mageia 9 => Mageia 10
Priority: release_blocker => High

At this point all that needs to be written is that ntpsec has replaced ntp.

Priority: High => release_blocker

(In reply to David Walser from comment #15)
> At this point all that needs to be written is that ntpsec has replaced ntp.

How is this handled during upgrade?

Will an installed mga8 ntp be kept or replaced?

Replaced.

Thanks

Now in
https://wiki.mageia.org/en/Mageia_9_Release_Notes#Replaced_on_upgrade

Keywords: FOR_RELEASENOTES9 => IN_RELEASENOTES9

I am landing late here, but since a long while, I have been using "chrony" on Mageia. So a drop of ntp would have been fine too.
We could also suggest its usage in the Mga9 release notes?

CC: (none) => eatdirt

Do you mean extending this note:

 ntp is replaced with ntpsec, mga#28922, for security.

to become:

 ntp is replaced with ntpsec, mga#28922, for security.  An alternative is to use chrony.

?

Yes, that would be good!

Updated rel notes

(In reply to Morgan Leijström from comment #22)
> Updated rel notes

Except that never happened apparently. The release notes just say
"Replaced on upgrade ntp is replaced with ntpsec, mga#28922, for security."

CC: (none) => unruh

(In reply to w unruh from comment #23)
> (In reply to Morgan Leijström from comment #22)
> > Updated rel notes
> 
> Except that never happened apparently. The release notes just say
> "Replaced on upgrade ntp is replaced with ntpsec, mga#28922, for security."

Why did you say that?

urpmq -pi ntpsec
Name        : ntpsec
Version     : 1.2.2
Release     : 5.mga9
Group       : System/Servers
Size        : 1595298                      Architecture: x86_64
Source RPM  : ntpsec-1.2.2-5.mga9.src.rpm
URL         : https://www.ntpsec.org/
Summary     : NTP daemon and utilities
Description :
NTPsec is a more secure and improved implementation of the Network Time
Protocol derived from the original NTP project.

urpmq --conflicts ntpsec
ntp
ntp-perl
ntpdate

Because I looked at what was apparently an old version of the release notes, where the suggestion to perhaps use chrony was not there. Looking again at the official release notes, that clause is there. Sorry I did not notice I was looking at an old version of the notes.

Where are we on this?
Bug is set as Mageia 10 release blocker.

Why does Mageia not just make chrony the default ntp program? It is well supported by M Lichvar, and has many advantages over ntp. The main difference is that chrony uses a adaptive linear regression to determine th e offset and the rate of the systemclock while ntp uses a feedback scheme. The former much more rapidly zooms into the system clock being in sync with the sources on startup and also ties the system clock much more tightly to the sources (sub microsecond system clock discipline with a GPS timing source (eg a cheap (<$100) gps/pps receiver)

We actually did (at least attempt to) switch the default to chrony, but that's not what this bug is about.  We still have ntp packaged, which should be replaced with ntpsec, which is what this bug is for.

(In reply to David Walser from comment #28)
> We still have ntp packaged

Is that true ? I cannot find it using rpmdrake. It seems only ntpsec is available.

I use ntpsec on all my mageia systems with version 9 already. 

So I'd propose to close that BR as fixed.

CC: (none) => bruno
Status: NEW => RESOLVED
Resolution: (none) => FIXED

I can still find ntp mentioned here:

https://gitweb.mageia.org/software/drakx/tree/perl-install/install/steps.pm#n707

sub configureTimezone {
    my ($o) = @_;
    install::any::preConfigureTimezone($o);

    if ($o->{timezone}{ntp}) {
        # We prefer chrony, but we'll deal with ntpd for the sake of upgrades
        my $pkg = install::pkgs::packageByName($o->{packages}, 'chrony');
        unless ($pkg && $pkg->flag_installed) {
            $pkg = install::pkgs::packageByName($o->{packages}, 'ntp');
            $o->pkg_install('chrony') unless $pkg && $pkg->flag_installed;
       }
    }

Shouldn't ntp be replaced by ntpsec ?

Yes, I think that's at least partly why this bug was still open, as integration with our installer and tools wasn't finished.

(In reply to David Walser from comment #28)
> We actually did (at least attempt to) switch the default to chrony, but
> that's not what this bug is about.  We still have ntp packaged, which should
> be replaced with ntpsec, which is what this bug is for.

But then there is no need to make the problems of integrating ntpsec into a "release stopper". But I also note that this has been defined as fixed.

I recently installed MGA9 on two machines, and it still asks if one wants to install ntpd to control the clocks. But of course  Mga9 was created 5 years ago. It might be useful to issue a 9.1 which updates 9. I for example had trouble because the MGA9 original kernel did not include a wireless driver for my Dell 9315 XPS13 laptop ( which is about 5 years old). That made it impossible to update the initial installation of Mga9, since the laptop only had wireless. 
This makes the MGA experience for anyone trying out MGA horrible, further oiling the slippery slope on which MGA seems to be on (fewer users which discourages the valiant volunteers who package MGA and encourages their dropout which causes delays in the release of the next version....). I really like Mageia.

(In reply to w unruh from comment #33)
> (In reply to David Walser from comment #28)
> > We actually did (at least attempt to) switch the default to chrony, but
> > that's not what this bug is about.  We still have ntp packaged, which should
> > be replaced with ntpsec, which is what this bug is for.
> 
> But then there is no need to make the problems of integrating ntpsec into a
> "release stopper". But I also note that this has been defined as fixed.

Actually this kind of bug absolutely needs to be marked as a release blocker.  Dropping a package can't be done post-release, and if we release a distro with a package, we are committed to support it.  So, as to the packaging aspect of replacing ntp with ntpsec, it needed to be a release blocker.  Also, as part of it was integrating it with the installer, that also requires it to be a release blocker.  So we just marked it as fixed because of the bug title, but even I hadn't bothered to read over the bug to remind myself why it was still open.

> I recently installed MGA9 on two machines, and it still asks if one wants to
> install ntpd to control the clocks. But of course  Mga9 was created 5 years
> ago. It might be useful to issue a 9.1 which updates 9. I for example had
> trouble because the MGA9 original kernel did not include a wireless driver
> for my Dell 9315 XPS13 laptop ( which is about 5 years old). That made it
> impossible to update the initial installation of Mga9, since the laptop only
> had wireless. 

Yes, I actually submitted the patch to change the default to chrony, and it looked correct, but when I tested it, it didn't appear to work.  I believe there's still another bug that's open for that reason.

> This makes the MGA experience for anyone trying out MGA horrible, further
> oiling the slippery slope on which MGA seems to be on (fewer users which
> discourages the valiant volunteers who package MGA and encourages their
> dropout which causes delays in the release of the next version....). I
> really like Mageia.

I agree.  A 9.1 is a great idea (or 9.2 if we already did that, which we might have, I don't remember).  We're sort of in a death spiral as a distro.  We keep losing people due to life, burnout, etc, slowing momentum, and we aren't getting enough fresh blood to pick up the slack, and like you said, the perception that we're dying is probably scaring people off.

I do not know that it is the perception that that Mageia is dying but rather finding that the installation has "gotyas" like not being able to update.

Do you have a link to that bug when you try to use chrony instead of ntp on the installation?

Bug 11092 was the main bug for chrony integration.  Bug 17091 references it too.