If you use ntp, I would appreciate if you could test the transition to
ntpsec. ntpsec 1.2.1+dfsg1-5 has been uploaded to experimental and
cleared the NEW queue.
Bernhard Schmidt suggested and I used
1:4.2.8p15+dfsg-2~$(DEB_VERSION_UPSTREAM_REVISION) as the version for
the transitional
On Mon, 2022-01-24 at 08:08:16 +0100, Guillem Jover wrote:
> 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
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
>
Richard Laager wrote on 23/01/2022:
> 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
On Jan 23, Richard Laager wrote:
> 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
On Sun, 23 Jan 2022 at 15:12:49 -0600, 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
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,
On 1/20/22 8:04 AM, Thomas Goirand wrote:
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
On Thu, 20 Jan 2022 at 20:09:18 +0530, Pirate Praveen wrote:
> Do we really need a dummy package for upgrades to work?
Yes, we do need transitional packages.
> Can't ntpsec binary package just add Provides: ntp (=$source:Version) ?
No, apt won't automatically replace a real package "ntp" with a
2022, ജനുവരി 19 5:27:28 PM IST, Paride Legovini ൽ എഴുതി
>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,
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
On Jan 19, Paride Legovini wrote:
> 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.
I think that this would be better
Bernhard Schmidt writes:
> - Since NTS leverages X.509, how does it work with a broken clock on
> boot that is ticking outside of the certificate validity period?
I don't know how it is intended to work, but it seems pretty obvious
that NTS certificate validation must ignore the validity
On 1/19/22 3:13 PM, Bernhard Schmidt wrote:
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.
+1 that promoting NTS is orthogonal.
If the bigger problems below are solved,
* Richard Laager [220119 14:34]:
> 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
On 19.01.22 20:44, Stephan Seitz wrote:
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
On 19.01.22 20:34, Richard Laager wrote:
Hi Richard,
+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
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
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
Hi,
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
Am 19.01.22 um 13:07 schrieb Marc Haber:
On Tue, 18 Jan 2022 21:49:53 +0100, Michael Biebl
wrote:
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.
The Beef I have with chrony is that they
On Tue, 18 Jan 2022 21:49:53 +0100, Michael Biebl
wrote:
>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.
The Beef I have with chrony is that they just implemented the parts of
the
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
Am Di, Jan 18, 2022 at 23:16:46 +0100 schrieb Marco d'Itri:
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.
Besides from the fact that ntpsec is already packaged: Does chrony
support NTS?
[I'm the Debian ntpsec maintainer.]
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
Marco d'Itri wrote on 18/01/2022:
> On Jan 18, Michael Biebl wrote:
>
>> If "ntp" the binary package would become a transitional package that
>> installs chrony, that'd be fine with me if that eases the transition.
> I am not sure that this would be practical since they cannot share the
> same
On Jan 18, Michael Biebl wrote:
> I think Fedora prefers chrony instead of ntpsec.
Fedora even uses btrfs, so who cares. :-)
The interesting point is that RHEL switched to chrony for RHEL 7.
Also, I want to add that chrony is not just better as a client, but also
as a NTP server.
Am 18.01.22 um 19:44 schrieb Moritz Mühlenhoff:
Bernhard Schmidt wrote:
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
Bernhard Schmidt wrote:
> 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
Bernhard Schmidt wrote on 17/01/2022:
> ntpsec and ntp should be largely configuration compatible, so even a
> takeover of the binary package names might be practical.
I played a bit with ntpsec some time ago, I remember being very pleased
with it, and I think it can very well replace ntp in
On 1/17/22 21:13, Marco d'Itri wrote:
On Jan 17, Bernhard Schmidt 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
On Jan 17, Bernhard Schmidt 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.
--
ciao,
Marco
signature.asc
On Mon, Jan 17, 2022 at 05:01:10PM +0100, Bernhard Schmidt wrote:
> 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
>
On 17.01.22 17:01, Bernhard Schmidt wrote:
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
Hi,
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.
35 matches
Mail list logo
