* Peter Eisentraut [EMAIL PROTECTED] [2007-06-17 01:14]:
What's the status with this?
There hasn't been any progress. However, from previous discussions it
seems that rdate is more appropriate for d-i than ntpdate, so I
suggest you simply close this bug report. I'm CCing debian-boot so
other
On Sat, Aug 19, 2006 at 08:50:09PM -0400, Rick Thomas wrote:
For countries with more than 1 timezone, I want to be able to set a
default
timezone for the system based on the offset between the system
clock and the
remote timeserver as well... :)
RFC 868
* Steve Langasek [EMAIL PROTECTED] [2006-08-23 01:14]:
RFC 868 (http://www.rfc-archive.org/getrfc.php?rfc=868) says that the
rdate protocol delivers time as a 32-bit binary integer in units of
seconds since midnight on January first 1900 GMT (time 1 is 12:00:01
am on 1 January 1900
* Frans Pop [EMAIL PROTECTED] [2006-08-19 16:47]:
Seems this could be worked around easily by just retrying a few
times if that error is returned (until it is fixed).
Yes.
Is there a time-out when it really cannot connect to a server?
Yes, that seems to work.
Installations are rare enough
* Peter Eisentraut [EMAIL PROTECTED] [2006-08-17 14:14]:
Can I assume that the d-i group settled on using either rdate or a
minimal sntp client rather than ntpdate?
I've tried rdate now. Here are my observations:
- It basically seems to work and is very small.
- Somtimes rdate doesn't
On Saturday 19 August 2006 15:50, Martin Michlmayr wrote:
- It basically seems to work and is very small.
Which is a big plus.
- Somtimes rdate doesn't work, but this applies both to busybox and
the stand-alone variant. I get errors like 69.25.96.13 did not
send the complete time
On Sat, Aug 19, 2006 at 04:47:44PM +0200, Frans Pop wrote:
We mainly need to determine how we are going to use rdate:
- for all installations;
- only for some (sub)arches like nlsu;
- only if difference between system date/time and rdate date/time is
greater than x.
Seems to me there
On Aug 19, 2006, at 2:52 PM, Steve Langasek wrote:
On Sat, Aug 19, 2006 at 04:47:44PM +0200, Frans Pop wrote:
We mainly need to determine how we are going to use rdate:
- for all installations;
- only for some (sub)arches like nlsu;
- only if difference between system date/time and rdate
On Sat, Aug 19, 2006 at 06:18:40PM -0400, Rick Thomas wrote:
On Aug 19, 2006, at 2:52 PM, Steve Langasek wrote:
On Sat, Aug 19, 2006 at 04:47:44PM +0200, Frans Pop wrote:
We mainly need to determine how we are going to use rdate:
- for all installations;
- only for some (sub)arches like
On Aug 19, 2006, at 6:59 PM, Steve Langasek wrote:
Using DHCP will only tell you what the
DHCP admin's preferred timezone setting is, which won't necessarily
match
and also doesn't give you any idea whether the user wants the
system's clock
to be set in UTC or not.
The proposed RFC
On Aug 19, 2006, at 2:52 PM, Steve Langasek wrote:
On Sat, Aug 19, 2006 at 04:47:44PM +0200, Frans Pop wrote:
We mainly need to determine how we are going to use rdate:
- for all installations;
- only for some (sub)arches like nlsu;
- only if difference between system date/time and rdate
On Sat, Aug 19, 2006 at 08:29:12PM -0400, Rick Thomas wrote:
On Aug 19, 2006, at 6:59 PM, Steve Langasek wrote:
Using DHCP will only tell you what the
DHCP admin's preferred timezone setting is, which won't necessarily
match
and also doesn't give you any idea whether the user wants the
On Aug 20, 2006, at 12:05 AM, Steve Langasek wrote:
The proposed RFC allows the dhcp administrator to tailor the response
based on the MAC address of the client. Most won't, but it should be
possible if you want to.
I think you're missing the point that the maintainer of the newly-
Can I assume that the d-i group settled on using either rdate or a
minimal sntp client rather than ntpdate?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Peter Eisentraut [EMAIL PROTECTED] [2006-08-17 14:14]:
Can I assume that the d-i group settled on using either rdate or a
minimal sntp client rather than ntpdate?
Sorry, I havent had time to try out rdate now. Please leave this bug
report open for now but don't do anything until you hear
On Sat, Jul 15, 2006 at 12:19:52AM +0200, Martin Michlmayr wrote:
Since I filed this bug, someone suggested that a tool other than ntp
might be better since it's smaller. Unfortunately, I cannot remember
the name right now. I'm CCing -boot so other people can comment, but
Perhaps you were
* Mark Brown [EMAIL PROTECTED] [2006-07-17 20:09]:
Since I filed this bug, someone suggested that a tool other than ntp
might be better since it's smaller. Unfortunately, I cannot remember
the name right now. I'm CCing -boot so other people can comment, but
Perhaps you were thinking of
On Jul 15, Martin Michlmayr [EMAIL PROTECTED] wrote:
Is this libcrypto dependency strictly needed (what for) or could the
udeb be built in a way that it's needed? libcrypto0.9.8-udeb appears
to be about a meg in size while ntpdate has less than 50K.
It's still very big. For d-i we should use
On Sun, Jul 16, 2006 at 11:19:17AM +0200, Marco d'Itri wrote:
On Jul 15, Martin Michlmayr [EMAIL PROTECTED] wrote:
Is this libcrypto dependency strictly needed (what for) or could the
udeb be built in a way that it's needed? libcrypto0.9.8-udeb appears
to be about a meg in size while
On Jul 16, Kurt Roeckx [EMAIL PROTECTED] wrote:
It's still very big. For d-i we should use a simpler SNTP-only client,
which would not be bigger than a few KB.
sntp was never part of the debian ntp package, and has license
problems so is removed in the current svn version. As it is in
the
On Sun, Jul 16, 2006 at 12:23:07PM +0200, Marco d'Itri wrote:
On Jul 16, Kurt Roeckx [EMAIL PROTECTED] wrote:
It's still very big. For d-i we should use a simpler SNTP-only client,
which would not be bigger than a few KB.
sntp was never part of the debian ntp package, and has license
* Kurt Roeckx [EMAIL PROTECTED] [2006-07-15 00:53]:
Because of recent changed I did (that haven't been commited yet),
ntpdate now depends on libcrypto, so the ntpdate-udeb would end
up with a dependency on libcrypto0.9.8-udeb. I hope that's not a
problem?
Is this libcrypto dependency
* Rick Thomas [EMAIL PROTECTED] [2006-07-15 01:48]:
Yeah, ntpdate will do the job, and it's a good bit smaller than the
full ntp-simple package.
The alternative you were thinking of *may* be chrony.
Maybe, although it seems that ntpdate is signiticantly smaller than
chron.
However, keep
On Sat, Jul 15, 2006 at 08:51:05PM +0200, Martin Michlmayr wrote:
* Kurt Roeckx [EMAIL PROTECTED] [2006-07-15 00:53]:
Because of recent changed I did (that haven't been commited yet),
ntpdate now depends on libcrypto, so the ntpdate-udeb would end
up with a dependency on
On Jul 15, 2006, at 2:51 PM, Martin Michlmayr wrote:
* Rick Thomas [EMAIL PROTECTED] [2006-07-15 01:48]:
Yeah, ntpdate will do the job, and it's a good bit smaller than the
full ntp-simple package.
The alternative you were thinking of *may* be chrony.
Maybe, although it seems that ntpdate
Martin Michlmayr wrote:
Since I filed this bug, someone suggested that a tool other than ntp
might be better since it's smaller. Unfortunately, I cannot remember
the name right now. I'm CCing -boot so other people can comment, but
unless there are great ideas, I'm still interesting in having
On Sat, 2006-07-15 at 23:53 +0200, Peter Eisentraut wrote:
I should also point out that the ntpdate program is deprecated upstream,
is no longer maintained, and no bugs are being fixed for it.
I've been telling people that for years, but upstream still hasn't made
it go away... and even if
* Peter Eisentraut [EMAIL PROTECTED] [2006-07-14 23:27]:
ntpdate doesn't set the hardware clock, so the only thing this would
achieve is having a good clock while the installer runs. Is that
useful?
Yes, otherwise we e.g. end up with a filesystem that was modified in
1970 and e2fsck will
On Sat, Jul 15, 2006 at 12:19:52AM +0200, Martin Michlmayr wrote:
* Peter Eisentraut [EMAIL PROTECTED] [2006-07-14 23:27]:
ntpdate doesn't set the hardware clock, so the only thing this would
achieve is having a good clock while the installer runs. Is that
useful?
Yes, otherwise we e.g.
NTP is something I know a bit about.
Yeah, ntpdate will do the job, and it's a good bit smaller than the
full ntp-simple package.
The alternative you were thinking of *may* be chrony.
Both implement enough of the network time protocol (NTP) to do what
you want.
However, keep in mind that
30 matches
Mail list logo
