libHttpClient.Linux: remove problematic hwclock sync

[ScottMunroMS]

libHttpClient linux build have long included a "just-in-case" hwclock sync. I can't say with 1000% certainty but I believe this to be a mitigation for clock drift issues likely most impactful to local WSL dev environments.

removing this hwclock sync because it's not appropriate for cloud builds and for WSL local dev work it's not really a proper mitigation either. WSL doesn't have a hardware RTC so its sort of a convenient noop that some people have suggested has some positive impact but don't quite understand.

There may be better strategies force WSL clock sync in the future, but I don't believe they should negatively impact the core non-WSL cloud builds or other linux-first dev scenarios

[jhugard]

FYI, PR #965 contains a similar fix, but instead attempts to use hwclock, but ignores any failures. It also reduces compile times by skipping CURL docs installation. Might want to consider that as an alternate solution, or pick up the fix as part of that PR.

See this commit, but fair warning that other PR still isn't compiling under Linux.

[ScottMunroMS]

FYI, PR #965 contains a similar fix, but instead attempts to use hwclock, but ignores any failures. It also reduces compile times by skipping CURL docs installation. Might want to consider that as an alternate solution, or pick up the fix as part of that PR.

See this commit, but fair warning that other PR still isn't compiling under Linux.

Is this a suggestion that you've found the hwclock sync to be impactful to either your local environment or the cloud builds you're running? I'm inclined to just remove the hwclock sync since I've got a reasonably well-educated guess it wasn't added quite right and having the "try clock sync but gracefully fail" still has the opportunity for what I think is a totally unnecessary command to have unintended side effects.

if it's not definitely helping you, I'm willing to take the risk on behalf of libHttpClient maintainers to remove it (and if we need to add it back in in the future we can with the more graceful fallback)

[jhugard]

if it's not definitely helping you, I'm willing to take the risk on behalf of libHttpClient maintainers to remove it (and if we need to add it back in in the future we can with the more graceful fallback)

IDK one way or the other; it was there and the commit I linked simply adjusts it to have the least impact so that it would build under WSL. I suppose not having this might cause issues if clock drifts & the intermediate files aren't deleted between builds.

[jhugard]

if it's not definitely helping you, I'm willing to take the risk on behalf of libHttpClient maintainers to remove it (and if we need to add it back in in the future we can with the more graceful fallback)

IDK one way or the other; it was there and the commit I linked simply adjusts it to have the least impact so that it would build under WSL. I suppose not having this might cause issues if clock drifts & the intermediate files aren't deleted between builds.

To be clear, WSL doesn't have hwclock.

[jasonsandlin]

if it's not definitely helping you, I'm willing to take the risk on behalf of libHttpClient maintainers to remove it (and if we need to add it back in in the future we can with the more graceful fallback)

IDK one way or the other; it was there and the commit I linked simply adjusts it to have the least impact so that it would build under WSL. I suppose not having this might cause issues if clock drifts & the intermediate files aren't deleted between builds.

It should be alright to remove then. This build doesn't ship anywhere and is just to ensure the products that use LHC don't get build breaks.

[ScottMunroMS]

if it's not definitely helping you, I'm willing to take the risk on behalf of libHttpClient maintainers to remove it (and if we need to add it back in in the future we can with the more graceful fallback)

IDK one way or the other; it was there and the commit I linked simply adjusts it to have the least impact so that it would build under WSL. I suppose not having this might cause issues if clock drifts & the intermediate files aren't deleted between builds.

Roger. then I'm going to keep it as-is for now. I worry about building up build script tech debt from trying to over-emphasize the important of least impact in our build pipelines. Unlike lots of other things these scripts are run all the time so we'll get signal if there's a problem sooner than later.