George Georgalis <geo...@galis.org> writes: > On Wed, Jan 8, 2020 at 3:38 PM Greg Troxel <g...@lexort.com> wrote: > >> The default URL is repointed, but you should still be able to get the >> previous branch. > > I have success using > http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0_2019Q3/All/ > > but my inquiry was for 'last successful packages' from amd64/8.1/All > ...would seem that's what I have now, however, is it a bug that the 8.1 > url is linked to 8.0_2019Q4 already? or perhaps Q4 announcement > should be gated with successful building of Q3 packages?
pkgsrc itself in 2019Q4 is actually ok; the problem was that rust failed on NetBSD's pkgbuild cluster. I built rust 1.39.0 on netbsd-8 (up to date stable) amd64 on December 19. As for gating the release announcement, that isn't really reasonable, because pkgsrc supports 23 operating systems, and on those many CPU architectures and multiple releases. This is just one of many cases, albeit arguably the most important from the NetBSD point of view. The announcement is simply an email that goes out. People start running bulk builds when they choose, and they finish at some point. In this case I was busy between branch-tagging (which is also end of freeze) and announcement (and we produce drafts and review them), so I did wait about 24h for the 8/amd64 build to finish, but only as a microoptimization to avoid people asking where those results were, not because I really consider announcement and builds finishing to be linked. 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