a couple of years ago (in 2017) I stepped up to help bring src:ntp back
in shape because I needed it for work. All uploads since that time have
been made by me. An RFH bug had been open the whole time and just
recently got the first message for five years, which made me remember my plan.
Back then cleaning up the official ntp.org package in Debian was without alternatives, because ntpsec was not born yet and chrony did not have
any traction in the Debian world (as far as I could tell).
However, development for ntp.org is slow, upstream still using BitKeeper
is cumbersome, and even the testsuite needs to be fixes on some
architectures for new releases. Both ntpsec and chrony are (from my POV)
the better alternatives now. To a point where I would rather use chrony
for new deployments, but I'm shying away from not using my own work
anymore for the lack of real-life testing.
I could just step down as a maintainer/uploader and have the ntp
packaging bitrot, but this would be a large disservice to our users
(unless someone else continues to maintain it). I think another option
would be to migrate to one of the alternatives for Bookworm.
ntpsec and ntp should be largely configuration compatible, so even a
takeover of the binary package names might be practical.
What do you think?
I could just step down as a maintainer/uploader and have the ntp packaging bitrot, but this would be a large disservice to our users (unless someone else continues to maintain it). I think another option would be to migrate
to one of the alternatives for Bookworm.
What do you think?chrony is MUCH better since Debian 10, I agree that it should be the
On Jan 17, Bernhard Schmidt <berni@debian.org> wrote:
What do you think?chrony is MUCH better since Debian 10, I agree that it should be the preferred NTP client for when systemd-timesyncd is not enough.
You can definitely spend your time on something more fun and more
useful.
ntpsec and ntp should be largely configuration compatible, so even a
takeover of the binary package names might be practical.
However, development for ntp.org is slow, upstream still using BitKeeper
is cumbersome, and even the testsuite needs to be fixes on some
architectures for new releases. Both ntpsec and chrony are (from my POV)
the better alternatives now. To a point where I would rather use chrony
for new deployments, but I'm shying away from not using my own work
anymore for the lack of real-life testing.
I think Fedora prefers chrony instead of ntpsec.Fedora even uses btrfs, so who cares. :-)
If "ntp" the binary package would become a transitional package thatI am not sure that this would be practical since they cannot share the
installs chrony, that'd be fine with me if that eases the transition.
On Jan 18, Michael Biebl <biebl@debian.org> wrote:
If "ntp" the binary package would become a transitional package thatI am not sure that this would be practical since they cannot share the
installs chrony, that'd be fine with me if that eases the transition.
same configuration.
I have no objections if somebody wants to work on packaging ntpsec, but
I do not think that either ntp or ntpsec should be promoted over chrony nowadays.
I'd prefer making ntp a dummy package depending on ntpsec rather than
having src:ntpsec takeover bin:ntp.
ntpsec-ntpdate, and if I broke out ntpdig as suggested in bug#1003966, sntp -> ntpsec-ntpdig.
bin:ntp has always been a specific NTP implementation, I think
it's OK if it's replaced by an almost compatible fork, less OK if a completely different implementation is brought in instead.
I have no objections if somebody wants to work on packaging ntpsec, but
I do not think that either ntp or ntpsec should be promoted over chrony >nowadays.
On 1/18/22 11:21 AM, Paride Legovini wrote:
I'd prefer making ntp a dummy package depending on ntpsec rather than having src:ntpsec takeover bin:ntp.
If I understand correctly, you're suggesting src:ntp builds bin:ntp that
is a dummy package which depends on ntpsec?
Another option would be to have src:ntpsec build the bin:ntp dummy
package and remove src:ntp entirely.
Fwiw, I'm with Marco here: If systemd-timesyncd (a simple SNTP client
which is enabled by default) doesn't fit your needs, chrony is a great >alternative.
However, development for ntp.org is slow, upstream still using BitKeeper
is cumbersome, and even the testsuite needs to be fixes on some
architectures for new releases. Both ntpsec and chrony are (from my POV)
the better alternatives now. To a point where I would rather use chrony
for new deployments, but I'm shying away from not using my own work
anymore for the lack of real-life testing.
I could just step down as a maintainer/uploader and have the ntp
packaging bitrot, but this would be a large disservice to our users
(unless someone else continues to maintain it). I think another option
would be to migrate to one of the alternatives for Bookworm.
For people that want something more than systemd-timesyncd, e.g. to get
NTS, I think either are acceptable choices. It seems that the consensus
AFAICT other than systemd-timesyncd being installed by default we don't
have a "default" NTP daemon in Debian.
So we should most probably decide on a "default" and have all of them changed to $newdefault | time-daemon
As default both ntpsec and chrony are challengers.
And then there is the migration from src:ntp. I think only ntpsec wouldAgreed (as I stated already; just agreeing here again).
be an option here
sntp could depend on on the ntpdig package from #1003966, but it would probably need to carry a compatibility symlink
ntpdate and ntp could be transitional packages on the ntpsec
counterparts as well, but since ntpsec/ntpsec-ntpdate has
Conflicts/Replaces on the src:ntp binary packages it needs coordination.
For this reason building the transitional binaries from src:ntpsec would probably be easier.
+1, except that my position is we already have that answer:
systemd-timesyncd | time-daemon
As default both ntpsec and chrony are challengers.
For people that want something more than systemd-timesyncd, e.g. to get
NTS, I think either are acceptable choices. It seems that the consensus
for new installs is towards chrony over ntpsec. But I don't think we as
the distro need to push either over systemd-timesyncd. For people who
don't care, systemd-timesyncd should be fine.
Do you disagree on that point (that systemd-timesyncd is fine for people
who don't care about NTP)? If so, can you elaborate?
Sure.
How do we feel about this process then:
1. I split out ntpdig, as suggested in #1003966. This is presumably
ntpsec-ntpdig for consistency with the rest being ntpsec-*.
Maybe upload this at this step, to start the NEW process.
2. I create transitional binary packages in src:ntpsec:
ntp -> ntpsec
ntp-doc -> ntpsec-doc
ntpdate -> ntpsec-ntpdate
sntp -> ntpsec-ntpdig
with an sntp -> ntpdig symlink
3. Get a review from you (Bernhard) if you're willing?
4. Upload.
5. Then Bernhard requests ftpmasters remove src:ntp. Is that how
that works?
On 1/19/22 9:49 AM, Bernhard Schmidt wrote:
AFAICT other than systemd-timesyncd being installed by default we don't have a "default" NTP daemon in Debian.
I'm not sure how much more "default" it can be than installed by default. So I'd say we do have a default: systemd-timesyncd.
So we should most probably decide on a "default" and have all of them changed to $newdefault | time-daemon
+1, except that my position is we already have that answer:
systemd-timesyncd | time-daemon
Am Mi, Jan 19, 2022 at 13:34:13 -0600 schrieb Richard Laager:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus
Well, most people will use the default NTP server of the package and
don’t have a NTP server in their network.
And since Debian is trying to be as secure as possible, the default NTP server should be ntpsec with as much activated NTS entries as possible.
I agree we should have a look at this (either ntpsec or chrony, both do NTS), but I think this should be done completely independently of the ntp.org->ntpsec migration.
- AFAIK there is no pool.ntp.org (or similar) service only containing
NTS enabled timesources yet.
I don't know how it would work either,
since you need to verify the peer with a standard X.509 certificate and
you don't know the expected CN from a DNS RR
- Since NTS leverages X.509, how does it work with a broken clock on
boot that is ticking outside of the certificate validity period?
That's what I had in mind, but the other option:I think that this would be better since they are close enough that
Another option would be to have src:ntpsec build the bin:ntp dummy
package and remove src:ntp entirely.
also looks sensible to me after all. No strong opinion.
- Since NTS leverages X.509, how does it work with a broken clock on
boot that is ticking outside of the certificate validity period?
For people that want something more than systemd-timesyncd, e.g. to get
NTS, I think either are acceptable choices. It seems that the consensus
for new installs is towards chrony over ntpsec. But I don't think we as
the distro need to push either over systemd-timesyncd. For people who
don't care, systemd-timesyncd should be fine.
Do you disagree on that point (that systemd-timesyncd is fine for people
who don't care about NTP)? If so, can you elaborate?
Richard Laager wrote on 19/01/2022:
On 1/18/22 11:21 AM, Paride Legovini wrote:
I'd prefer making ntp a dummy package depending on ntpsec rather than
having src:ntpsec takeover bin:ntp.
If I understand correctly, you're suggesting src:ntp builds bin:ntp that
is a dummy package which depends on ntpsec?
That's what I had in mind, but the other option:
Another option would be to have src:ntpsec build the bin:ntp dummy
package and remove src:ntp entirely.
also looks sensible to me after all. No strong opinion.
Paride
Do we really need a dummy package for upgrades to work?
Can't ntpsec binary package just add Provides: ntp (=$source:Version) ?
On 1/19/22 20:34, Richard Laager wrote:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus for new installs is towards chrony over ntpsec. But I don't
think we as the distro need to push either over systemd-timesyncd. For
people who don't care, systemd-timesyncd should be fine.
Do you disagree on that point (that systemd-timesyncd is fine for
people who don't care about NTP)? If so, can you elaborate?
Well, could you elaborate why you didn't write "chrony is fine for
people who don't care"?
I fail to understand why you're having a
preference on systemd-timesyncd...
On 1/19/22 15:04, Bernhard Schmidt wrote:
On 19.01.22 20:34, Richard Laager wrote:
2. I create transitional binary packages in src:ntpsec:
I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch
(of 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's
bin:ntp package.
It might be technically possible to build a binary package with
different versioning, but even if it is: 1) I don't know how,
2. I create transitional binary packages in src:ntpsec:
I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's bin:ntp package.
It might be technically possible to build a binary package with different versioning
but even if it is: 1) I don't know how, and 2) I'm not sure
whether that's a good idea, especially compared to the alternatives.
It might be technically possible to build a binary package with different versioning, but even if it is: 1) I don't know how, and 2) I'm not sure whether that's a good idea, especially compared to the alternatives.I did it long ago, I think for kmod taking over module-init-tools: you
On 1/19/22 15:04, Bernhard Schmidt wrote:
On 19.01.22 20:34, Richard Laager wrote:
2. I create transitional binary packages in src:ntpsec:
I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's bin:ntp package.
It might be technically possible to build a binary package with different versioning, but even if it is: 1) I don't know how, and 2) I'm not sure whether that's a good idea, especially compared to the alternatives.
On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote:
On 1/19/22 15:04, Bernhard Schmidt wrote:
On 19.01.22 20:34, Richard Laager wrote:
2. I create transitional binary packages in src:ntpsec:
I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of
2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's bin:ntp package.
Bumping the epoch to 2 here is completely gratuitous and can make a mess
for ntpsec *and* potentially ntp iff upstream got to be improved and we wanted to reintroduce it in the future.
It might be technically possible to build a binary package with different versioning, but even if it is: 1) I don't know how, and 2) I'm not sure whether that's a good idea, especially compared to the alternatives.
Yes, this is the recommended method, that has been used in the past,
and which is mentioned in the dpkg FAQ. You can set arbitrary versions
via dpkg-gencontrol (or indirectly via dh_gencontrol).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 50:50:24 |
| Calls: | 6,649 |
| Calls today: | 1 |
| Files: | 12,200 |
| Messages: | 5,330,301 |