On 03/04/2013 04:03 PM, Nathan Scott wrote:
Is sorting the addresses something we should be doing (in the libpcp
native implementation)? Since NSPR has decided to, I guess there was a
very good reason, and having different behaviours between different
builds of PCP seems potentially problematic.
Well, it turns out that NSPR probably isn't sorting them either. After
making the switch to PR_GetAddrInfoByName (now pushed to pcpfans
brolley/nssmerge), NSPR now presents a single IPv6 address before the
first IPv4 one for test 273. I suspect it has more to do with the
underlying system calls. All of the advice I have read has indicated
that applications should just try the addresses in order without regard
to what they are. Whether the possibility of connecting via a different
address with different builds is a concern, my opinion would be no. If
the user wants to connect via a specific address, they should use that
address directly instead of a host name.
Re: test 430: It passes for me for NSPR builds and fails for native
builds with:
430 - output mismatch (see 430.out.bad)
128a129,130
> Restarting pmlogger for host "LOCALHOSTsuper" [dots] [process PID] done
> Latest folio created for CHECK
130a133,134
> Restarting pmlogger for host "LOCALHOSTsuper" [dots] [process PID] done
> Latest folio created for CHECK
[ ... etc. ...]
I didn't get a chance to look into it.
Its OK to defer some of those last IPv6 items to 3.6.12 too. Given
this release has taken awhile now, at this stage I think focussing on
getting something releasable would be ideal. Lets aim for a
merge-to-dev later today (my time, once down to zero QA fails), a day
or two there for Ken and others to sneak in some additional testing if
we're lucky, and for any of the remaining IPv6 work you're comfortable
adding still. Then begin release tagging, building/packaging/distro
updates, etc, towards the end of Wednesday or Thursday? cheers. -- Nathan
You're the boss!
Dave
|