[ntp:hackers] Tarballs

David L. Mills mills at udel.edu
Mon Apr 4 19:25:47 PDT 2005


Danny,

I take it your latest has/will show up at ntp-dev without my doing 
anything.I've spent the last four days seriously testing for livelocks 
and deadlocks and lockpicks and fixing tiny little inconsistencies that 
bedevil formal specification. Little things like: "there is no way we 
can get here, but if we did..."

Dave

Danny Mayer wrote:

> Dave,
>
> It turns out that the reason that it was not working on the Freebies was
> that I had just fixed that problem at least for IPv4 and you hadn't 
> gotten
> that latest version at the time you were testing it.
>
> It still seems to dissassociate itself from time to time (maybe 
> related to
> the NULLibg of dstadr) and I have yet to look into that. IPv6 is not able
> to join the IPv6 group for multicast yet on Freebies. I haven't checked
> on the suns yet, I probably should do that for a sanity check.
>
> Danny
>
> At 07:23 PM 4/2/2005, David L. Mills wrote:
>
>> Danny,
>>
>> As confirmed this moment, broadcast does NOT work at the backroom on 
>> FreeBSD howland; it DOES work on Solaris deacon. The prolog on 
>> howland shows broadcast enabled, as does whimsy. I don't know what is 
>> different on the two machines, but they were compiled from the same 
>> sources.
>>
>> For my purposes having one machine that does work in broadcast is 
>> okay for testing, but I wouldn't want this stuff to escape here until 
>> FreeBSD works.
>>
>> The snapshot stash is just fine; I thought you guys had moved off of 
>> louie, but that's still a good home. Maybe I didn't look hard 
>> enought, but I didn't see a pointer to louie (aka ftp.udel.edu) on 
>> the ISC pages. What makes me a little nervous is a blanket 
>> recommendation to "use the latest snapshot" as a workaround for a 
>> feature I known to be broken in what spins here.
>>
>> Dave
>>
>> mayer at gis.net wrote:
>>
>>> Dave,
>>>
>>> The current ntp-dev DOES work for IPv4 broadcast and multicast or at
>>> least
>>> it did as of last week when I fixed a configuration flag setting. As 
>>> far
>>> as I know it still works in the latest snapshot unless a change you 
>>> made
>>> in the last few days has broken it again. I would need to review your
>>> changes to be sure. Is Autokey also broken?
>>>
>>> We don't, of course, guarantee the quality and reliability of the
>>> snapshots
>>> or ntp-dev tree since that's the code under development. The snapshots
>>> are
>>> currently available at:
>>>
>>> http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/snapshots/ntp-dev/2005/04/ 
>>>
>>>
>>> (for April 2005). We create a new directory for each month and year and
>>> the snapshot tarballs are generated whenever the BK master source tree
>>> is updated. That way people don't necessarily need BK to get the latest
>>> code. These are, of course, not release code, but development code.
>>>
>>> Danny
>>>
>>> ----- Original Message Follows -----
>>>
>>>> Guys,
>>>>
>>>> In answer to a question about multicasting, Harlan advised a newsgroup
>>>> member to obtain the latest tarball, presumably the current ntp-dev 
>>>> snapshot, whatever that might be. The current ntp-dev I have here 
>>>> doesn't work in broadcast, presumably including multicast. I have 
>>>> repeatedly advised that the current ntp-dev is not releasable until
>>>> the  broadcast/multicast situation is fixed and until repairs can be
>>>> made so  the original Autokey functions are restored. I have had no
>>>> answers to  these advisories.
>>>>
>>>> In order to check if the current snapshot tarball was in fact viable,
>>>> I  found no tarballs at the ISC site other than what might be
>>>> obtainable  via Bitkeeper. Bitkeeper apparently requires user login,
>>>> which I will  not do as defense against identity theft.
>>>>
>>>> I have no answer to my previous post about the viability and 
>>>> availability of the latest ntp-dev. It is not releasable and will not
>>>> be  until the above problems have been resolved. If the tarballs are
>>>> not  accessable without requiring login, that is completely
>>>> unacceptable. If  necessary, I will publish tarballs of my own at our
>>>> UDel archive site. I  will only do that if I can defend the release as
>>>> fully functionable.
>>>>
>>>> Dave
>>>> _______________________________________________
>>>> hackers mailing list
>>>> hackers at support.ntp.org
>>>> https://support.ntp.org/mailman/listinfo/hackers
>>>
>>
>> _______________________________________________
>> hackers mailing list
>> hackers at support.ntp.org
>> https://support.ntp.org/mailman/listinfo/hackers
>




More information about the hackers mailing list