* 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
* 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 Janua
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 (http://www.rfc-archive
* 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 en
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-
instal
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 want
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 date
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 allow
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)arc
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 date
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 ther
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 tim
* 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 w
* 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
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]
* 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 thinki
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
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
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
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
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
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
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 hav
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 ntpda
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 libcrypto0.
* 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,
* 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 st
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 tha
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, otherwi
* 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
30 matches
Mail list logo
