Re: repo missing package

[George Georgalis <george%galis.org@localhost>]

On Wed, Jan 8, 2020 at 5:17 PM Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> As for gating the release announcement, that isn't really reasonable,

okay, fine :) it's my first choice of package manager because it's
separate form the OS anyway :)

I think it was only (relatively) recently I started using
NetBSD/amd64/8.1/All and I didn't think about the consequences at all,
using 8.x_2019Q3 and/or pkgsrc is a better value for me.

> As I understand it, there is some kind of bad clock behavior in a NetBSD
> domU (under xen), and I think the issue is that one the clocks can go
> backwards slightly.  I am not sure this violates POSIX, but it seems
> rust fails if it detects this.  I can't find the PR that describes this.
>
> The relevant standard might be
>
>   https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html
>
> So if anybody wants to help, set up Xen, and in a NetBSD 8 domU, install
> pbulk and then try to build rust, and debug from there.
>
> This may be a useful clue (but it may not be):
>
>   https://github.com/longsleep/linux-pine64/issues/44

Clock management has had more issues in releases than any other
device, in my vmware and virtualbox experience. I think it stems from
RTC doesn't make sense in a VM, so it's hard to characterize expected
behavior, let alone support it, and inherit NTP at the same time...

thanks for the links. A patch for rust to test the monotonic clock vs
RTC might be an easy win, but if that fails I'd consider removing the
forward clock tests altogether, if that is actually a problem
(comparing timestamps in tests vs in operation), maybe a different
locking scheme could resolve the issue?

if xen vm clock counters are rolling backward, I'm sure there is a
very good and likely very complicated reason for it, if xen is not
using the monotonic api for vm timesource, I'm very curious why? If
the monotonic time source is moving backward, then I'm sure this will
be very interesting bug and would reconsider removing the rust clock
tests. ;-)








--
George Georgalis, (415) 894-2710, http://www.galis.org/